プロンプトはもう古い？ プロンプト → コンテキスト → ハーネス → ループ、AIエンジニアリングの4層

用語が整理されたのは、この数年

4つの層は、順に必要になって順に名前がついた。整理のしかたには諸説ある。以下の年表は先のAI Builder Clubの記事の整理で、時期はあくまで目安。

順序としては、コンテキスト → ハーネス → ループの3段が、プロンプトの上に積み上がった形で語られる。

codecentricのBenjamin Font Peraは、2026年7月の記事で3つを次のように定義している。

• コンテキストエンジニアリングは「AIモデルに、次のタスクに必要な正しい情報を与える規律」。関係あるものを選び、関係ないものを意図的に外すところまでを含む
• ハーネスエンジニアリングは「コーディングエージェントを囲むガードレール — ツール、スキル、MCPサーバー、システムプロンプト、フック、サンドボックス、可観測性」
• ループエンジニアリングは「人間がターンごとにプロンプトを打たずに、AIエージェントを繰り返し起動し、補助エージェントを生成し、結果を検証し、自分自身に供給し直すシステム」

同記事は「各層は前の層の上に成り立ち、土台を飛ばすと不安定になる」とも書いている。ここは実感と合う。

ループの定義に「補助エージェントを生成し」が入っているのは、見落とされやすいところ。ループ層はもともと複数のエージェントが動く前提で定義されている。あとで触れる。

「Agent = Model + Harness」

ハーネスについては、ThoughtworksのBirgitta Böckelerが2026年4月に書いた記事の整理がいちばん使いやすいと思っている。

Agent = Model + Harness

モデル以外の全部がハーネスだ、という切り方。そのうえでハーネスを2種類に分けている。

• Guides（フィードフォワード制御） — エージェントの振る舞いを予期して、動く前に方向づける
• Sensors（フィードバック制御） — 動いた後に観測して、自己修正させる

そして、よく設計されたハーネスの目的をこう書いている。

最初から正しくやれる確率を上げること、そして、多くの問題が人の目に届く前に自己修正されるフィードバックループを提供すること

「前に効かせるか、後で効かせるか」という軸は、そのまま設計の分類として使える。

ハーネスだけで順位が変わった、という実証

「モデル以外の全部」と言われても効果が想像しにくいところだが、分かりやすい例が2026年2月に出ている。

LangChainのチームが、コーディングエージェントのベンチマークTerminal Bench 2.0で、スコアを52.8%から66.5%へ、順位を30位から5位へ上げた。モデルは同じものに固定したまま。直したのはシステムプロンプトと道具と中間処理だけ、と本人たちが書いている（LangChain, "Improving Deep Agents with harness engineering", 2026-02-17）。

同じモデルでも、囲い方で結果が変わる。 「Agent = Model + Harness」は比喩ではなく、実際に効く分解だった。

拡大

なぜプロンプトだけでは足りなくなったのか

理由は単純で、1回の応答で終わらなくなったから。

エージェントが10分間ひとりで動くなら、その10分のあいだに読むもの、触れる道具と踏めない地雷、いつ止まるかを、事前に決めておく必要が出てくる。1往復なら、おかしくなったら次の発言で直せばよかった。ひとりで動く時間が伸びるほど、直せるタイミングが減る。

プロンプトは今もその中心にあるが、プロンプトに書けるのは「何をしてほしいか」だけ。「何を読ませるか」「何をさせないか」「いつ止めるか」は別の場所に書くしかない。

冒頭に引いた言い方に戻ると、プロンプトは表現の問題を解く道具。「どう言えば伝わるか」は解ける。でも「その仕事に必要な事実がそもそも手元にない」という状態は、言い方を工夫しても解けない。

人を雇うときには当然やっていること

これも読んで納得した整理だった。人に仕事を頼むときと比べると、何を省いているかが分かる。

新しく人に入ってもらうとき、依頼はする（プロンプト）。資料も渡す（コンテキスト）。そのうえで、重要な仕事ならチェックリストを渡し、節目で確認を入れ、成果を検証する。

エージェントに対しては、この後半をまるごと省いていることが多い。人には当然やっている段取りを、相手がAIというだけで省いている、というのがハーネス層とループ層が指しているものだ。

4層を、決めることと効くタイミングで分けるとこうなる。

拡大

上に行くほど、人が見ていない時間が長くなる。 下の層は1往復で直せる。上の層は、直せるタイミングが来る前に走り切ってしまう。層が増えたのは、この「見ていない時間」が伸びたぶんを埋めるためだ。

なぜ自己申告に委ねられないのか ── 3つの失敗モード

上の図を「そういう整理もあるね」で終わらせないために、実証のほうを先に置く。

長く走らせたときに繰り返し現れる崩れ方を、Anthropicのエンジニアリング記事が挙げている（Prithvi Rajasekaran, "Harness design for long-running application development", 2026-03-24）。そこに書かれているものを、こちらで3つに整理し直したのが次の図だ。

拡大

名前の出どころを分けておく（図と同じ順で）。「一発でやろうとしすぎ」に元記事は名前を与えていないが、単体で全部やらせると途中で崩れ、工程を分けて渡すと持つ、という形で書かれている。「コンテキスト不安」は元記事の用語（context anxiety）で、コンテキストの上限が近いと思うと切り上げにかかる、という観察だ。「勝利宣言バイアス」は元記事では self-evaluation leniency — 自分の成果物を聞かれると、出来がよくなくても自信ありげに褒める — と呼ばれている。3つのうち2つは、こちらで付けた呼び名だ。

3つとも、モデルを賢いものに替えても消えない。 構造的に出るものだからだ。そして3つとも、4層のどこかが受け止める場所を持っている。

層を積むのは流行に合わせるためではなく、この3つが実在するから、という順序で理解したほうが腹に落ちる。

境界は「モデルの自己申告に委ねてよいか」で切れる

線引きに迷ったとき、いちばん使えた基準がこれだった。

「今回はここまでで十分です」とモデルが言うのは、プロンプト層の仕事だ。それを信じてよいかを決めるのはループ層で、判断材料は自己申告ではなく、実行して合否の出るものになる。

この線を引かないと、ループは「モデルが終わったと言うまで回るループ」になる。止まる保証がない。似た話がハーネス層にもあって、「本番環境を消してよいか」は、その場のモデルの判断に任せる種類の問いではない。判断をモデルに委ねない領域を決めるのがハーネス層の役割だ。

ループの失敗モードは、品質ではなく費用

もう1つ、ループ層を触る前に知っておきたい指摘がある。これも同じAI Builder Clubの記事から。

検証器の弱い無人ループは、悪い答えを1つ出すのではない。一晩中、トークン価格で、悪い答えを出し続ける

ループ層の怖さは「間違えること」ではなく、間違いに気づかないまま回り続けることだ。人が見ていない時間が長いほど、被害は品質ではなく請求に出る。

だから、ループを回すときの前提は2つになる。合否を機械で判定できること。そして、上限を先に決めておくこと。 回数・時間・費用のどれかに天井がないループは、動かしてはいけないものだと考えている。

前提が変わっている ── AIは1体で動かない

4層の整理でいちばん実務に効く含意は、ここだと思う。

ループの定義には「補助エージェントを生成し」が入っている。つまり複数のエージェントが役割を分けて動くことが前提になっている。これは効率の話ではなく、構造上そうしないと成り立たないからだ。

理由が2つある。

1つ目。コンテキストは有限で、しかも汚れる。 1体に全部やらせると、設計の議論も、実装の試行錯誤も、失敗ログも、同じ場所に積み上がる。後半になるほど最初に決めたことが埋もれる。役割を分けると、それぞれが独立したコンテキストを持つので、この汚染が起きない。

2つ目。生成した本人は、自分の成果物を正しく評価できない。 同じセッションの中で「レビューして」と頼むと、自分が書いた理由をそのまま正当化する方向に働く。検証を別の役に立て、成果物と満たすべき条件だけを渡す（生成の経緯は渡さない）ようにすると、結果が変わる。

「AIが自律的に動く」という言い方も、実態としてはチームが自律的に回ることを指している。1体が賢くなって勝手に働く、という絵ではない。

ただし、層を足すほど良くなるわけではない

積み上がるものだが、毎回全部を使うものではない。

単発で30分以内に終わる仕事にループ層を持ち込むと、ゴールを定義し、合否条件を書き、状態を管理するコストのほうが大きくなる。役割を分けるのも同じで、独立したコンテキストを持つということは、共有されていない前提が増えるということでもある。

層は道具であって、目的ではない。 当たり前に見えるが、実際にはここで一度失敗した。

この整理を、自分たちの運用にあてはめてみた話だ。

4層のうち、どこから手をつけたか

結論から言うと、コンテキスト層から入った。

やったことは単純で、日次ログ・意思決定記録・学び・タスクの4つを置き、「作業の区切りで前者、判断したら後者」という更新タイミングだけを決めたことだ。加えて、セッション開始時にそれらを自動で読み込ませ、「読んでから始めてください」ではなく読んだ状態で始まるようにした。

以下は数字で測っていないので、感触として書く。効いたのは、同じ説明を繰り返さなくなったことだ。翌日の最初の数分が「前回何をしていたか思い出す時間」でなくなった。

次にハーネス層。ここはBöckelerのGuides / Sensorsの分類がそのまま使えて、動く前に止めるもの（危険なコマンドのブロック）と、動いた後に気づかせるもの（指示ファイルが太りすぎていないか）に分けて設計した。

先に入れてよかったのはSensorsのほうだった。「太ったら知らせる」だけの仕組みは、書くのが小さくて、外しても実害が出ない。Guides（動く前に止める）は、間違って止めると作業が進まなくなるので、慣れてからのほうが安全だった。

役割を分けて、いちばん変わったところ

検証役を別に立てたことだ。

同じ相手に「書いて」と「見て」を両方頼んでいたときは、レビューが実質機能していなかった。別の役に、成果物と条件だけを渡すようにしてから、指摘の質が変わった。何をどう頑張ったかを知らない相手に見せたときに残るものが、実際に残っているものだ。

これは規模に関係なく効く。1人でやっていても、役割は分けられる。

ループ層は、いまも選んで使っている

複数セッションにまたがる、手戻りコストの高い仕事にだけ使っている。判断基準は1つで、合否が機械で判定できるか。判定できない仕事にループを持ち込むと、結局は人が見張ることになる。

具体的な組み方は2本目に書いた。→ AIエージェント構築基盤をつくった

潮流に合わせて層を作ったが、使われなかった

いちばん正直に書いておきたいのはこれだ。

ループ層の仕組みを一式そろえたあと、起動実績がゼロという実測が出た。そこから「不要」と判断して、記録上は全撤去を決めた。

その後、判断が覆った。責任者から「撤去候補ではない。むしろ積極的に使いたい」という意思表示があったためだ。

実測は正しかった。誤ったのは、そこから「不要」を導いたことだった。起動実績がゼロだった実際の原因は、機能が不要だったからではなく、使う場面を運用側から提案していなかったからだ。撤去を決めた記録は、利用意図を確認しないまま結論を出していた。

→ 使われていない機能を見つけたときの分岐は2つある。 不要だから使われていないのか、使う場面を誰も提示していないから使われていないのか。前者だと決めつけると、作った資産を自分で捨てる。

このとき「期限つき存置」にはしなかった。同じ延長を3回繰り返すのは同じ失敗の反復になるためだ。代わりに運用側の提案責任を置いた — ループ層が適する条件に当てはまる仕事を認めたら、着手前に提案する、という形だ。

層の名前を覚えることと、使い分けられることは別

もう1つ、進行中の課題として。

4層そろっていると、単発30分の仕事にもループ層を持ち出したくなる。ゴールを書き、合否条件を定義し、状態を管理して、結局そのほうが遅い。

いまはループの起動側に「使わない条件」を書いて、適用判断を先にさせている。ただしこれは判断を委ねているので、ハーネス層のように機械では止まっていない。層が増えるほど、使い分けの判断コストが増える。 用語が整理されたことと、うまく使えることのあいだには、まだ距離がある。

下から順に、1つずつが素直だ。

1つ目はコンテキスト層。 日次ログと意思決定記録の2つを置いて、「区切りで前者、判断したら後者」とだけ決める。ファイル2つとルール1行で始められて、次のセッションの立ち上がりが変わる。

2つ目はハーネスのSensors側。 「基準を外れたら気づかせる」だけの仕組みから入る。動く前に止めるGuidesより先にSensorsから入ると、失敗しても実害が出ない。

役割を分けるのは、1体で回らなくなってからで十分だ。ただし例外が1つあって、検証役だけは早めに分けたほうがいいと思っている。生成した本人に自分の成果物を評価させないのは、規模に関係なく効く。

ループ層は最後。 前提として、合否を機械で判定できるかを先に確かめておきたい。判定できない仕事に停止条件を持たせようとすると、結局は人が見張ることになる。

最後に ──「モデルが悪い」と言う前に

読んだ中でいちばん引っかかったのが、この指摘だった（AI Builder Club, 前掲）。

「モデルが悪い」という不満の大半は、層の取り違えである

うまくいかないとき、いちばん手が伸びるのはモデルを替えることだ。でも実際の詰まりどころは、必要な情報を渡していない（コンテキスト層）、検証していない（ハーネス層）、止め方を決めていない（ループ層）のどれかであることが多い。

4層を覚える実利は、ここだと思う。問題を「モデルの質」に丸めず、どの層の問題かを言い当てられるようになる。 言い当てられれば、直す場所が決まる。

そして、4層をどう積むかの具体は、次の記事に書いた。

→ AIエージェント構築基盤をつくった — チームで動き、自律で回る土台をテンプレートにする