AIエージェント設計の5レイヤー — プロンプト・コンテキスト・ハーネス・ループ・グラフは競合しない

TL;DR

• 2026 年に入ってから「もうプロンプトエンジニアリングではない、次は◯◯エンジニアリングだ」という言い回しが半年おきに更新されている。この「次は」という接続詞が誤解の元である。
• プロンプト／コンテキスト／ハーネス／ループ／グラフは、互いを置き換える競合概念ではない。それぞれ設計している対象が違う。1 回の指示、判断時に持つ情報、道具と権限、反復と停止、工程の分岐と並列——別の場所を設計している。
• 積み重なりの方向は下から上。上のレイヤーは下を捨てるのではなく、下を内側に含んで設計範囲を広げる。だからグラフを組んでもプロンプトは必要で、各ノードの中に相変わらずプロンプトがある。
• 「ループの次はグラフ」も厳密には誤り。LangChain 自身が「ループは単純なグラフにすぎない。ループエンジニアリングはグラフの代替ではなく、その簡略版である」と述べている。
• 5 つのコアレイヤーの周囲に、スペック／スキル／ツール／メモリとリトリーバル／Eval とオブザーバビリティ／セーフティ・権限／インテントという 7 つの横断領域がある。実務でハマるのはたいていこの横断側で、特に Eval と停止条件が抜けている。
• 学ぶ順番には現実的な最短経路がある。グラフは最後。最初から 5 体のエージェントを作る必要はない。
• 元記事に対する補足は 3 点。LangChain の 4 段目の正式名称、Agent Skills はすでにベンダー横断のオープン標準、「新人社員」の比喩が 1 か所だけ崩れること。

元記事について

このレイヤー整理は @ai_ai_ailover が 2026 年 7 月 26 日に X の長文記事フォーマットで公開した「非エンジニアでもわかる、AI エージェント設計の教科書」がベースになっている。36 万ビューと広く読まれた記事で、「コンテキスト・ハーネス・ループ・グラフ」までを初心者向けに一気に通す構成になっている。

このブログでは個別のレイヤーを何度か扱ってきた。

• 土台のハーネスエンジニアリング
• その上のプロンプトからループへ
• グラフエンジニアリング入門
• 動的ワークフローで組むグラフエンジニアリング 14 ステップ

今回はそれらを一枚の地図に並べて、どのレイヤーがどこを担当しているのかを確定させる話になる。

元記事は OpenAI / Anthropic / LangChain / IBM の一次情報を頻繁に引いている。この記事では引用元が実在し、記述内容が一致するかを全件確認したうえで、元記事が触れていない補足を最後にまとめた。

全体像

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

そして図の最下段に書いた掛け算が、この記事の実質的な結論になる。

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

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

なおこの 6 因子はコア 5 レイヤーと 1 対 1 対応しているわけではない。コアと横断をまたいで「成果に効く因子」を並べたものだと読んでほしい。

「新人社員」に置き換えると全部つながる

元記事の一番の功績は、この比喩を全レイヤーに一貫適用したことである。AI を「非常に頭がいいが、今日入社した社員」だと考える。

この表を持っていると、「◯◯エンジニアリングとは何か」を毎回考え直さずに済む。その流行語が会社のどの部分の話をしているのかを当てるだけでいい。

ただし 1 か所だけ、この比喩が効かない場所がある（後述）。

1. プロンプトエンジニアリング — 1 回の指示を設計する

OpenAI はプロンプティングを「モデルに入力を与えるプロセス」と定義し、プロンプトを単なる文章ではなくテストとレビューの対象になるアプリケーションコードのように扱うことを推奨している。

悪い指示と良い指示の差は、要素の数で説明できる。

悪い例：
  ADHDを改善する方法について記事を書いて。

良い例：
  ADHDの診断を受けたばかりの成人向けに、生活上の困りごとを軽減する
  30日ロードマップ記事を作成してください。
  - 根拠：心理学・行動科学・医療機関の公開情報に基づくこと
  - 禁止：医療行為や服薬について断定すること
  - 初日は5分以内で実行できる内容にし、徐々に難易度を上げる
  - 各日に「目的／具体的行動／失敗時の代替案／振り返り項目」を書く

良いプロンプトの構成要素は 6 つに整理できる。目的・対象者・背景・制約・出力形式・評価基準である。

このうち初心者が最も落としやすいのが最後の評価基準だ。Anthropic も、プロンプトを改善しはじめる前に、まず成功条件と、それを実際にテストする方法を定義せよと案内している。「良い出力とは何か」を先に言語化していないと、そもそも改善したかどうか判定できない。

プロンプトだけでは越えられない壁

ただしプロンプトには、書き方をどれだけ磨いても越えられない壁がある。

• モデルが最新情報を持っていなければ、命令の上手さで最新情報は出てこない
• 自社の商品情報を渡していなければ、自社独自の提案はできない
• 検索・ファイル操作・計算・メール確認の道具がなければ、説明はできても実行はできない
• 1 回目の出力が誤っていたとき、自動で検証して直す仕組みがなければ、人間が毎回指示を出し続ける

この 4 つが、そのまま次の 4 レイヤーが存在する理由になっている。

2. コンテキストエンジニアリング — 判断の瞬間に何を知っているか

Anthropic は Effective context engineering for AI agents で、プロンプトエンジニアリングを「指示の書き方」、コンテキストエンジニアリングを「推論時に AI へ渡される情報全体を選び、維持すること」として明確に区別している。コンテキストにはシステム指示、ツール定義、MCP 経由の外部データ、会話履歴までが含まれる。

プロンプトが「何をしてほしいか」なら、コンテキストは「何を知った状態でやってほしいか」である。

「たくさん渡せば正確になる」は間違い

このレイヤーで最も多い失敗が、関係ありそうな資料を全部入れることだ。直感的には情報量が多いほど賢くなりそうに見える。

だが Anthropic は、LLM には有限のアテンション予算 (attention budget) があり、新しいトークンを入れるたびにこの予算が減ると説明している。Transformer は n トークンに対して n² のペア関係を張るので、コンテキストが伸びるほど個々の関係を捉える力が薄く引き伸ばされる。コンテキストサイズと注意の集中には構造的な緊張関係があるわけだ。

したがって良いコンテキスト設計とは、「望む結果を出す確率を最大化する、可能な限り小さい高シグナルなトークン集合」を探すことになる。実務ではこの 5 動作に落ちる。

1. 選ぶ — 今の作業に必要な情報だけを選ぶ
2. 並べる — 重要なルール、今回の依頼、参考資料を理解しやすい順に配置する
3. 圧縮する — 長い会話や資料を要約し、重要部分だけ残す
4. 分離する — 調査・執筆・校正を分け、不要な情報を同じ場所に混ぜない
5. 更新する — 古い情報や誤ったメモを残し続けず、現状に差し替える

コンテキストパックという運用単位

非エンジニアでも使える実装が、仕事ごとに「コンテキストパック」をフォルダとして作ることだ。

article-project/
├── brief.md          # 今回の記事の目的
├── audience.md       # 読者像
├── style-guide.md    # 文体と禁止表現
├── source-policy.md  # 情報源のルール
├── good-examples/    # 過去の優良記事
├── research/         # 今回の調査結果
└── current-draft.md  # 現在の原稿

ポイントは、毎回すべてを貼り付けないこと。「最初に brief.md と style-guide.md を読み、必要になったときだけ research/ を参照する」と指示する。必要な情報を必要な瞬間にだけ読み込ませる——これが Anthropic の言う段階的な情報取得の考え方と一致する。

3. ハーネスエンジニアリング — 道具・ルール・権限・作業環境

英語の harness には馬具、安全帯、制御装置といった意味がある。モデルが頭脳なら、ハーネスは頭脳を現実の仕事につなぐ身体と作業環境だ。

OpenAI は cookbook の Agent Improvement Loop で、ハーネスを「モデルの周囲にある完全な契約 (the full contract around the model)」と定義している。指示、ツール、ルーティング、出力要件、検証を含むものだ。実践事例は Harness engineering: leveraging Codex in an agent-first world にまとまっている。

含まれるものを列挙すると、プロンプトを書く技術よりかなり広い概念であることがわかる。

• システムプロンプト、AGENTS.md / CLAUDE.md
• 検索・計算・ファイル操作などのツール、MCP や外部サービスとの接続
• 作業用ファイルとフォルダ、サンドボックス
• 読み取り・書き込み権限、ネットワークアクセス
• 会話や作業状態の永続化、中断後の再開
• エラー時の再試行、ログとトレース
• テスト、評価基準、人間の承認ポイント

同じモデルなのに製品によって能力が違って見える理由

一方の製品は質問に文章で答えるだけ。もう一方はファイルを読み、検索し、コードを書き、テストを実行し、失敗したら直す。この差はモデルの知能ではなくハーネスの差である。OpenAI も Codex の中核を、単なるエージェントループではなくスレッド管理・永続化・設定・認証・ツール実行を含むものとして説明している。

AGENTS.md に書いただけでは守られない

ここが実務で最も刺さる指摘である。AGENTS.md や CLAUDE.md は重要だが、それだけではハーネスは完成しない。これらは主にプロジェクトの方針や参照先を伝えるコンテキストであって、強制力のある設定ではない。

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

行動を確実に止めたいなら、フックや権限制御といった別の仕組みが必要になる。OpenAI のハーネスエンジニアリング事例でも、巨大な AGENTS.md にすべてを詰め込むのではなく、短い AGENTS.md を目次として使い、詳細は構造化されたドキュメント群に分けるという設計が採られている。

文章でお願いするのがプロンプト。仕組みとして守らせるのがハーネス。

4. ループエンジニアリング — 反復と、何より停止条件

IBM は What Is Loop Engineering? でループエンジニアリングをこう定義している。

ユーザー定義のゴールに向けて、人間の介入を最小限にしながら AI エージェントを反復的に導くエージェンティックワークフロー（＝エージェントが自律的に反復する作業の流れ）、すなわちループを設計する実践。

そしてその中核サイクルを Goal → Action → Observation → Adjustment の 4 段として整理している。

従来は、人間自身がこのループの制御装置をやっていた。「記事を書いて」→「出典が足りないから調べ直して」→「構成が悪いから直して」→「初心者向けになっているか確認して」→「結論を修正して」。

ループエンジニアリングは、この人間の役割を仕組みに置き換える。

1. 原稿を作る
2. 出典チェックを行う。不合格なら調査工程へ戻す
3. 文章チェックを行う。不合格なら執筆工程へ戻す
4. すべて合格したら終了

ループは 4 階層に積める

LangChain は The Art of Loop Engineering で、コアのエージェントループは最初の 1 段にすぎず、その周囲にループを積み増せるとして、4 段のループスタックを提示している。

4 段目が重要で、AI が仕事を反復するだけでなく、AI の働き方そのものを改善する外側のループが存在する。OpenAI も cookbook で Agent Improvement Loop を公開している。実トレースから始め、人間とモデルのフィードバックを足し、それを再利用可能な eval に変え、得られた証拠から次のハーネス変更を提案させるという改善フライホイールだ。

停止条件のほうが開始条件より重要

ループ設計で最も重要なのは、開始条件ではなく停止条件である。「よくなるまで繰り返せ」だけでは、同じ修正を反復し、費用を使い続け、別の場所を壊す。

• すべての必須項目に合格したら終了
• 修正は最大 3 回まで
• 3 回連続でスコアが上がらなければ人間に確認
• 引用元が確認できない主張は削除
• 外部公開・送信・削除は人間の承認が必要
• 予算または処理時間の上限を超えたら停止

ループの目的は無限に考えさせることではなく、測定可能なゴールに安全かつ効率的に近づけることだ。

5. グラフエンジニアリング — 分岐・並列・承認経路

グラフエンジニアリングは、複数の工程・AI・ツール・人間の確認ポイントをノードとエッジの関係として設計することである。LangGraph はエージェントワークフローを 3 要素で表現している。

• State（状態） — 現在どこまで進んでいて、何が判明しているかを記録したデータ
• Nodes（ノード） — 仕事をする場所。決定論的なコード、単一の LLM 呼び出し、あるいは内部に独自のループを持つエージェントまるごと
• Edges（エッジ） — 次にどこへ進むかを決める接続。ノードの結果や現在の State に応じた条件分岐も含む

ループとグラフは対立しない

「ループの次はグラフ」という言い方をよく見るが、厳密には誤りである。LangChain は 3 Years of Graph Engineering with LangGraph で、この点を正面から否定している。

ループは単純なグラフにすぎない。ループエンジニアリングはグラフの代替ではなく、グラフの簡略版である。実際、LangChain フレームワーク自体が LangGraph の上に構築されており、単純なエージェントループはグラフ抽象の上で動いている。

つまりループとは DAG（非巡回グラフ）ではなく、閉路をもつ有向グラフである。グラフエンジニアリングは「1 つのループでは足りなくなったときに手を伸ばすもの」であって、グラフの各ノードは依然としてループだ。

グラフにする意味と、しない方がよい場合

1 つの AI に全部任せると、調査した本人が自分の間違いを見つけられない、途中の情報が混ざる、といった問題が出る。そこで工程を分ける。

設計の勘所は 1 つに集約できる。

• 確実性が必要な場所は経路を固定する — 請求、削除、公開、契約は、決められた経路と人間の承認を通す
• 創造性が必要な場所は裁量を渡す — 調査方法や文章表現のように正解が一つでない部分は AI に任せる

一方で、複雑なグラフはそれ自体で優秀になるわけではない。工程が 1 つしかないのに 5 体の AI を使えば、費用と待ち時間が増えるだけだ。AI 同士の伝言で情報が変形することもある。Anthropic も「成功しているエージェントシステムの多くは、必要以上に複雑なフレームワークではなく単純で組み合わせ可能なパターンを使っている」と述べている。

**最初は 1 体の AI と 1 つの検証ループから始める。**1 つのループで管理しきれなくなったときに、グラフへ拡張する。

横断レイヤー（スペック・スキル・ツール・メモリ・Eval・権限・インテント）— 実務でハマるのはこちら側

5 つのコアレイヤーの周囲に、全段にかかる横断領域が 7 つある。

スペックエンジニアリング（完成条件）

プロンプトが「今から何をするか」なら、スペックは「何が完成したら仕事が終わるか」を定義する。AI に長時間の仕事を任せるほど、最初の仕様書の重要度が上がる。

含めるべき項目は、目的／対象者／完成物／必要な機能／必要でない機能／制約／品質基準／受け入れ条件／例外処理／禁止事項／参照資料／人間が確認する場所。

悪い仕様：
  使いやすい家計簿アプリを作って。

良い仕様：
  スマートフォン向けの家計簿Webアプリを作る。
  - ユーザーは支出の金額、日付、カテゴリ、メモを登録できる
  - 月別の合計とカテゴリ別の割合を表示する
  - 初回利用者が説明を読まずに入力できるUIにする
  - データ削除時は確認画面を表示する
  - ログイン、銀行連携、家族共有は今回の対象外とする
  - 完成条件：必須機能のテストが全通過、スマートフォン幅でレイアウト崩れなし

OpenAI が公開した長時間タスクの事例でも、成功を支えたのは 1 つの巧妙なプロンプトではなく、明確な目標と制約、受け入れ条件付きのマイルストーン、実行手順、継続的な検証、監査ログの組み合わせだったと説明されている。プロンプトの文章力より、こちらの方が結果に効くことがある。

スキルエンジニアリング（再利用可能な手順）

繰り返し使う業務知識や手順を、AI が必要なときに読み込める形で保存する。OpenAI は Agent Skills を「指示、参考資料、任意のスクリプトをまとめ、Codex がワークフローを安定して実行するための仕組み」と説明している。Anthropic も Skills を同様のフォルダとして定義し、AI が最初から全部読むのではなく**名前と説明だけを見て必要なスキルだけを読み込む「段階的開示 (progressive disclosure)」**を行う点を強調している。

article-writing/
├── SKILL.md
├── references/
│   ├── writing-style.md
│   ├── source-policy.md
│   └── banned-expressions.md
├── scripts/
│   ├── count_characters.py
│   └── check_links.py
└── assets/
    └── article-template.md

SKILL.md に書くのは、どんな依頼で起動するか／最初に何を確認するか／どの順番で作業するか／何を必ず検証するか／どの資料を参照するか／完成時に何を報告するか。同じ説明を毎回やり直さなくてよくなるのが価値である。

ツールエンジニアリング（現実へ働きかける手段）

MCP では、AI が外部システムを操作する機能を「ツール」として公開でき、名前・説明・入力スキーマが設定される。ツールエンジニアリングは接続数を増やすことではない。

• AI が正しいツールを選べる名前にする
• 何ができて何ができないかの境界を明確にする
• 入力項目を曖昧にしない
• 結果を必要以上に長く返さない（トークン効率）
• 失敗理由を AI が理解できる形で返す
• 読み取りと書き込みを分ける
• 危険な処理には承認を要求する

Anthropic も、エージェントの性能は与えられたツールに大きく依存し、ツール名・機能の境界・返却するコンテキスト・トークン効率・説明文の設計が重要だと述べている。性能が低い AI に見えても、実際にはツールの説明が悪くて正しい機能を選べていないだけということがある。

メモリとリトリーバル（保存と取り出し）

メモリは保存場所、コンテキストは今この瞬間に渡されている情報で、別物である。過去の情報を毎回全部コンテキストへ入れることはできないので、長期に保存して必要な分だけ取り出す。

メモリ側で設計するのは、何を記憶するか／誰についての記憶か／いつ記憶し、いつ読み出し、いつ更新し、いつ削除するか／事実と推測をどう区別するか／古くなった情報をどう扱うか。Claude Code の場合、各セッションが新しいコンテキストから始まるため、CLAUDE.md のような人間が書く持続的指示と、AI 自身が残す自動メモリを組み合わせて知識を引き継ぐ設計になっている。

リトリーバル側は、大量の保存情報から今回の質問に関係する部分を検索して取り出す技術だ。設計項目は、資料の分割単位／メタデータ（タイトル・日付・著者）／新旧の区別／質問の書き換え／取得件数／似ているが無関係な資料の除外／出典と回答の結び付け。

Eval とオブザーバビリティ（測る／記録する）

AI の厄介な性質は、同じ指示でも毎回まったく同じ結果になるとは限らないことだ。「一度うまくいった」は仕組みの完成ではない。

数値で判定できるものはプログラムで確認し、文章の自然さのように数値化しにくいものは評価用 AI や人間がルーブリックで採点する。ここで重要な注意がある。

執筆した AI 自身に「自分の記事は完璧ですか」と聞くだけでは不十分である。

同じ AI が同じ前提のまま自己評価すると、同じ見落としを繰り返す。別のモデル、別の指示、機械的チェック、人間の確認を組み合わせる。

オブザーバビリティは「何が起きたか」を観察可能にすること。OpenAI はトレースによってモデル呼び出し、ツール呼び出し、ガードレール、エージェント間の引き継ぎを記録でき、そのトレースを評価することでツール選択・ルーティング・指示違反といった問題を発見できると説明している。Eval が「よかったか」を測る仕組みなら、オブザーバビリティは「何が起きたか」を確認する仕組みで、両方ないと失敗の原因がわからない。

セーフティ・権限エンジニアリング

AI が文章を作るだけなら被害は小さい。だがメール送信、ファイル削除、DB 更新、購入、コード実行まで行うようになると権限設計が必要になる。基本は最小権限だ。

• 読む必要しかない AI に書き込み権限を与えない
• 特定フォルダしか使わない AI にマシン全体へのアクセスを与えない
• 外部通信が不要ならネットワークアクセスを切る
• 送信・公開・購入・削除には人間の承認を入れる

OpenAI の Codex でも、sandbox_mode や approval_policy の設定で、作業領域外への書き込みやネットワークアクセスに承認を要求できる。安全設計とは、AI が間違えても事故にならない環境を作ることである。

インテントエンジニアリング（衝突時の優先順位）

仕様書の条件をすべて満たせない場合、AI は何を優先すべきか。速度と正確性、売上と顧客満足、面白さと事実の正確さ、顧客の依頼と会社の安全ルール——この優先順位を明文化するのがインテントエンジニアリングだ。

1. 人の安全と法令順守
2. 事実の正確性
3. ユーザーの明示的な目的
4. 読みやすさ
5. 処理速度
6. コスト削減

これがないと、AI は目の前の数値だけを最適化する。「問い合わせを減らせ」と命令した結果、顧客が問い合わせに到達できない画面を作るかもしれない。「滞在時間を伸ばせ」と命令した結果、必要以上に文章を長くするかもしれない。AI に仕事を任せるほど、作業手順だけでなくどんな判断をよしとするかを設計する必要が出てくる。

初心者はどの順番で学べばよいか

すべてを一気に学ぶ必要はない。現実的な順番はこうなる。

Eval（第 3 段階）がスキルやツールより先に来ているのが重要である。測れないものは自動で良くならない。

プログラミングをしない人向けのテンプレート

上の考え方を 1 枚にまとめると、こうなる。プロンプト、コンテキスト、スペック、ループの発想を同時に導入できる。要点は、参照情報・作業手順・評価基準・反復条件・停止条件・権限の 6 項目が入っていることだ。

# 目的
この仕事によって最終的に実現したいことを書いてください。

# 対象者
完成物を利用する人と、その人の知識レベルを書いてください。

# 完成物
何を、どの形式で、どの程度の量で作るかを書いてください。

# 参照情報
必ず参照する資料、優先する情報源、参照してはいけない資料を書いてください。

# 制約
文字数、期限、文体、使用可能なツール、禁止事項を書いてください。

# 判断の優先順位
条件が衝突した場合に、何を優先するかを書いてください。

# 作業手順
1. 必要な資料を確認する
2. 不足情報を調査する
3. 作業計画を作る
4. 初稿を作る
5. 評価基準で検査する
6. 不合格箇所だけを修正する
7. 再検査する

# 評価基準
完成物が満たすべき条件を、確認可能な形で書いてください。

# 反復条件
不合格の場合は、問題の原因を特定し、該当工程へ戻ってください。
修正前後の違いを記録してください。

# 停止条件
すべての必須基準に合格したら終了してください。
修正は最大 3 回までとしてください。
3 回で合格しない場合は、未解決点と必要な人間判断を報告してください。

# 権限
読み取り可能な場所、書き込み可能な場所、人間の承認が必要な処理を書いてください。

# 最終報告
完成物に加え、参照した資料、実行した検査、残っている不確実性を報告してください。

このテンプレートが「よい文章を書いて」と頼むだけの依頼と決定的に違うのは、完成の判定と、止め方まで書いてあるところである。

よくある誤解 — 早見表

本文で扱った内容を、流行しがちな言い回しの側から引ける形にまとめておく。

元記事のファクトチェックと補足

元記事は一次情報の引用が多いので、主要な帰属について引用元が実在し、記述内容が一致するかを確認した。結果は以下のとおり。

「グラフエンジニアリング」という呼び名が 2026 年 7 月に急速に広がった新語である一方、ノードとエッジでワークフローを設計する考え方自体は新しくないという整理も、LangChain の説明（当該記事は 7 月 22 日公開で、冒頭が「‘Graph engineering’ surfaced this weekend」）と一致する。

そのうえで、元記事が触れていない補足を 3 点。

1. LangChain の 4 段目は正式には「ヒルクライミングループ」 元記事は 4 段目を「改善ループ」と訳しているが、LangChain 自身の呼称は Hill climbing loop（ハイフンなし）である。意味は同じだが、原典を検索するときは正式名称の方が当たる。

2. Agent Skills は特定ベンダーの機能ではなく、すでに共通フォーマット 元記事は OpenAI と Anthropic の Skills を別々に紹介しているが、実態としては SKILL.md を核とする Agent Skills 形式が agentskills.io のオープン標準として整理されている。OpenAI 自身も Codex のドキュメントで「Skills build on the open agent skills standard」と明記している。対応実装は Claude Code、Codex、GitHub Copilot、VS Code、Cursor、Goose、Amp、OpenCode ほか多数。「どちらのベンダーに乗るか」ではなく、書いたスキルは持ち運べると理解した方が実務的である。

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

まとめ

これからの AI 活用では、プロンプトだけを上手に書く人よりも、AI が正しく働ける仕組み全体を設計できる人が強くなる。コア 5 レイヤーと 7 つの横断領域の担当範囲は、冒頭の図と「新人社員」の表に戻れば引ける。

そして冒頭の掛け算に戻る。**掛け算のどこか一つを空欄にしたまま、上のレイヤーへ進んでも成果は伸びない。**測っていなければ改善できず、止め方を決めていなければ反復が止まらない。

2026 年以降に重要なのは、プロンプトを捨てることではない。プロンプトを、コンテキスト・ハーネス・ループ・グラフの中へ正しく組み込むことである。

参考リンク

• Effective context engineering for AI agents — Anthropic
• Building effective agents — Anthropic
• Writing effective tools for agents — Anthropic
• Harness engineering: leveraging Codex in an agent-first world — OpenAI
• Unlocking the Codex harness: how we built the App Server — OpenAI
• What Is Loop Engineering? — IBM
• The Art of Loop Engineering — LangChain
• 3 Years of Graph Engineering with LangGraph — LangChain
• Graph API overview — LangChain Docs
• Build an Agent Improvement Loop with Traces, Evals, and Codex — OpenAI Cookbook
• ExecPlans — OpenAI Cookbook
• Build skills — OpenAI Codex
• Agent Skills open standard — agentskills.io