AIエージェント設計の5レイヤー

プロンプト／コンテキスト／ハーネス／ループ／グラフは競合概念ではなく、設計対象が異なる積み重なるレイヤー

概要

2026 年に入り「もうプロンプトエンジニアリングではない、次は◯◯エンジニアリングだ」という言い回しが半年おきに更新されているが、この「次は」という接続詞が誤解の元になっている。プロンプト／コンテキスト／ハーネス／ループ／グラフは互いを置き換える競合概念ではなく、設計対象が違うだけの積み重なるレイヤーである。上のレイヤーは下を捨てるのではなく、下を内側に含んで設計範囲を広げる。

5つのコアレイヤー

一番下がモデル（頭脳）で、その上に積み上がるものはすべて「モデルの外側」を設計する技術である。

レイヤー	設計対象	「新人社員」の比喩
プロンプト	1 回の指示	社員に渡す 1 回の依頼文
コンテキスト	判断時に持つ情報	社員の机の上に置く資料
ハーネス	道具・権限・作業環境	オフィス、備品、社内ルール
ループ	反復と停止	作業・確認・修正を回す業務サイクル
グラフ	分岐・並列・承認経路	部署・担当者・承認経路を含む組織図

成果を決める掛け算

成果＝モデルの能力 × 仕様の明確さ × コンテキストの質 × ツールの使いやすさ × 検証ループの強さ × 安全設計

掛け算なので、どれか一つが 0 に近いと全体が 0 に近づく。仕様が曖昧なら高性能モデルは「間違ったものを高速で」作り、検証と停止条件がなければ自律エージェントは失敗を反復する。

各レイヤーの要点

1. プロンプトエンジニアリング

OpenAI はプロンプトを、単なる文章ではなくテストとレビューの対象になるアプリケーションコードのように扱うことを推奨している。良いプロンプトの構成要素は目的・対象者・背景・制約・出力形式・評価基準の 6 つ。初心者が最も落としやすいのが評価基準で、「良い出力とは何か」を先に言語化していないと改善したかどうか判定できない。

プロンプトには書き方を磨いても越えられない壁がある（最新情報がない／自社データがない／道具がない／自動検証がない）。この 4 つがそのまま上位 4 レイヤーの存在理由になっている。

2. コンテキストエンジニアリング

Anthropic はコンテキストエンジニアリングを「推論時に AI へ渡される情報全体を選び、維持すること」と定義している。「たくさん渡せば正確になる」は誤りで、LLM には有限のアテンション予算 (attention budget) があり、新しいトークンを入れるたびに予算が減る。Transformer は n トークンに対して n² のペア関係を張るため、コンテキストが伸びるほど個々の関係を捉える力が薄まる。

良いコンテキスト設計とは「望む結果を出す確率を最大化する、可能な限り小さい高シグナルなトークン集合」を探すこと。実務では選ぶ・並べる・圧縮する・分離する・更新するの 5 動作に落ちる。

3. ハーネスエンジニアリング

OpenAI はハーネスを「モデルの周囲にある完全な契約 (the full contract around the model)」と定義している。指示・ツール・ルーティング・出力要件・検証を含む。

実務で最も刺さる指摘は、AGENTS.md / CLAUDE.md に書いただけでは守られないという点。これらは方針を伝えるコンテキストであって強制力のある設定ではない。

指示ファイルに「絶対に外部ファイルを削除するな」と書くことと、システム上、本当に削除できない権限にすることは別である。

文章でお願いするのがプロンプト。仕組みとして守らせるのがハーネス。 詳細はハーネスエンジニアリングを参照。

4. ループエンジニアリング

IBM はループエンジニアリングを「ユーザー定義のゴールに向けて、人間の介入を最小限にしながら AI エージェントを反復的に導くループを設計する実践」と定義し、中核サイクルを Goal → Action → Observation → Adjustment の 4 段として整理している。

LangChain はさらに、コアのエージェントループの周囲にループを積み増せるとして 4 段のループスタックを提示している。

#	ループ	役割
1	エージェントループ	モデルがツールを繰り返し呼びタスクを完了させる
2	検証ループ	出力をルーブリックで採点し、基準未満ならフィードバック付きで差し戻す
3	イベント駆動ループ	スケジュール・Webhook・新規ファイル等で自動起動する
4	ヒルクライミングループ	過去の実行ログを分析し、ハーネス自体を改善する

停止条件のほうが開始条件より重要である。「よくなるまで繰り返せ」だけでは、同じ修正を反復し、費用を使い続け、別の場所を壊す。修正は最大 3 回まで／3 回連続でスコアが上がらなければ人間に確認／予算・処理時間の上限を超えたら停止、といった条件を明示する。

5. グラフエンジニアリング

複数の工程・AI・ツール・人間の確認ポイントをノードとエッジの関係として設計する。詳細はグラフエンジニアリングを参照。

「ループの次はグラフ」は厳密には誤りで、LangChain 自身が「ループは単純なグラフにすぎない。ループエンジニアリングはグラフの代替ではなく、その簡略版である」と述べている。ループとは DAG ではなく閉路をもつ有向グラフであり、グラフの各ノードは依然としてループである。

7つの横断レイヤー

5 つのコアレイヤーの周囲に、全段にかかる横断領域が 7 つある。実務でハマるのはたいていこちら側で、特に Eval と停止条件が抜けていることが多い。

横断レイヤー	何を設計するか
スペック	何が完成したら仕事が終わるか（受け入れ条件）
スキル	繰り返す手順を再利用可能な形で保存する
ツール	AI が現実へ働きかける手段と、その境界
メモリとリトリーバル	何を保存し、いつ取り出すか
Eval とオブザーバビリティ	品質を測る基準と、何が起きたかの記録
セーフティ・権限	失敗しても事故にならない境界
インテント	条件が衝突したときの優先順位

スペックエンジニアリング

プロンプトが「今から何をするか」なら、スペックは「何が完成したら仕事が終わるか」を定義する。AI に長時間の仕事を任せるほど最初の仕様書の重要度が上がる。含めるべきは目的／対象者／完成物／必要な機能／必要でない機能／制約／品質基準／受け入れ条件／例外処理／禁止事項／参照資料／人間が確認する場所。

よくある誤解

よくある言い回し	実際
プロンプトエンジニアリングは終わった	各ノードで渡すプロンプトは依然必要。プロンプトだけで全部解く時代が終わった
コンテキストが大きければ全部入れてよい	入れる能力と正しく選ぶ能力は別。効くのは関連性・鮮度・優先順位
`AGENTS.md` に書けば必ず守る	指示ファイルはコンテキストにすぎない。禁止は権限・サンドボックス・フックで実装する
AI に自己評価させれば十分	同じ前提のまま自己評価すると同じ見落としを繰り返す
エージェントを増やすほど性能が上がる	伝達ミス・費用・待ち時間・管理対象も増える
自律型 AI なら人間は不要	責任は移らない。重要な判断・最終承認・例外対応は人間の仕事

「新人社員」の比喩が崩れる場所

この比喩は全体像の把握に有効だが、1 か所だけ効かない。新人社員は昨日の仕事を覚えているが、エージェントは既定ではセッションを越えて何も覚えていない。だから人間の職場に存在しない「メモリエンジニアリング」というレイヤーがわざわざ必要になる。比喩に頼りすぎると、この最も設計コストが高い部分を見落としやすい。

詳細: エージェントメモリのロックイン

学ぶ順番

グラフは最後でよい。最初から 5 体のエージェントを作る必要はない。1 体の AI と 1 つの検証ループから始め、1 つのループで管理しきれなくなったときにグラフへ拡張する。Anthropic も「成功しているエージェントシステムの多くは、必要以上に複雑なフレームワークではなく単純で組み合わせ可能なパターンを使っている」と述べている。