21 エージェント与えられた目標に向かって、自分で手順を組み立てて作業を進めるAIプログラム。質問に答えるだけのチャットAIと違い、「調べる→書く→確認する」を自律的に行う工学の階層 — プロンプトAIに渡す指示文のこと。「この機能を作って」「この文を直して」等からグラフまで5層の設計地図
2026年のLLM運用には5つの「○○エンジニアリング」が存在する。流行語の羅列ではなく、下の層が壊れた場所に上の層が生まれた積み上げ構造として理解すると、自分の環境のどの層が厚く・どの層が薄いかを診断できる。
5層の系譜
| 層 | 名称 | 何を設計するか | 生まれた理由（下の層の漏れ） |
|---|---|---|---|
| 1 | プロンプトエンジニアリング | 1回の依頼の言葉（役割・例・出力形式） | モデルの次トークンAIにとっての「文字数」のようなもの。AIは文章をトークンという小片に区切って処理する。課金や入力上限（コンテキストウィンドウ）はこの単位で数えられる予測は保証ゼロ。言葉で予測経路を狙い撃ちする必要があった |
| 2 | コンテキストエンジニアリング | ウィンドウに入る情報全部の選別 | ループ同じ処理の繰り返し、または一連の作業サイクルのこと。プログラミングではfor文等の繰り返し構造、開発では「計画→実装→検証」の反復サイクルを指すには記憶が要る。窓は有限で、全部入れるとノイズが予測を悪化させる |
| 3 | ハーネスエンジニアリング | モデルを包む実行プログラム（ツール定義・権限・失敗時処理・フック） | ツールは揃っても「仕事の進め方」が決まっていなかった。保証は会話の外（コンパイラ・テスト・フック）にしかない |
| 4 | ループエンジニアリング | Plan→Act→Review→Repeat の進行形状と停止条件 | ハーネスが整っても、計画・実行・検証のサイクルを誰が制御するかが未定だった |
| 5 | グラフエンジニアリング | レビューを別インスタンスに任せる構造 | 同一インスタンスの自己レビューは「自分と別フォントで同意するだけ」。作った本人には構造的に見えないミスがある |
出典: Prompt, harness, context, loop, graph: the jargon is a changelog（2026-08-14）・Prompt, Context, Harness, Loop: 4 Agent Layers — FutureAGI・codecentric による用語整理
各層の核心
層1: プロンプト — 予測の狙い撃ち
「You are a senior reviewer」のような役割指定は、訓練データのその役割の文章が集まる領域へ予測を誘導する動きをする。Chain-of-Thought や few-shot 例示もこの層。エージェント化しても毎ターンの入力は誰かが書いたプロンプトであり、この層の妙が全層に波及する。
層2: コンテキスト — 窓は予算
Karpathy の定義「次の一手のためにコンテキスト窓にちょうど良い情報を満たす繊細な技術」。重要な転回は窓を資源（予算）と見なす視点。CLAUDE.md・memory・検索結果・ツール定義・過去ターンはすべて予算の内訳であり、「全部入れる」は網羅ではなくノイズ。
層3: ハーネス — 保証は会話の外にしかない
モデル自身の自己疑念は、誤りを作ったのと同じ経路で動くため保証にならない。保証は説得できない存在（コンパイラ・テストランナー・フック・権限システム）が持つ。Claude Code とチャット窓が同じ重みで全く異なる性能を出すのはハーネスの差。
層4: ループ — 仕事に形を与える
計画を先に出させ、進行ゲートを設け、再試行の上限で人間に戻す。Anthropic の Building effective agents にある対比が有用: workflow = コードが工程を決める / agent = モデルが工程を決める。ループエンジニアリングはこのダイヤルを工程ごとに設定する作業で、「思ったよりコード側で決めたかった」箇所を発見する作業でもある。
層5: グラフ — 新鮮な目を意図的に呼ぶ
レビューをその場にいなかった別インスタンス（別セッションClaude Codeの1回の対話単位。起動から終了までの会話と作業状態のこと。長く使うと内容が混ざるため、トピックの区切りで新セッションに引き継ぐ運用をする・別モデル・別コンテキストのsubagent）に渡す。作成インスタンスはプランへの愛着を持っているため、構造的に自己レビューできないミスを捕捉できる。
ワークフロー一連の作業の流れ・手順の定義。GitHub Actionsでは自動実行の手順をこう呼ぶ vs エージェントの対比
| ワークフロー | エージェント | |
|---|---|---|
| 工程を決めるのは | コード（事前定義） | モデル（実行時に判断） |
| 向いている | 繰り返し可能・予測可能性が要る作業 | 工程を事前に書き下せない作業 |
| コスト予測 | しやすい | しにくい |
設計の実務は「まず workflow で書けないか検討し、判断が必要な分岐だけ agent にする」方向に倒すのが安定する。
自己診断: 自分の環境はどの層まで作り込めているか
層ごとに「実装設計や仕様を、実際に動くコードに作り込むこと。「実装済み」＝コードとして完成している状態の厚さ」を点検するチェックリスト。個人環境の実測例（2026-08-30時点・約120スキルClaude Codeで「特定の作業手順」をパッケージ化したもの。SKILL.mdに手順を書いておくと、対応する場面でAIがその手順を読み込んで従う。経験を再利用する仕組み/約50フックエントリ/durable cronクロン。Linuxで「毎日6時」「30分ごと」等の定期実行を予約する仕組み。予約実行の登録表（crontab）に書いて運用する 12件の構成）では以下のような分布になった:
| 層 | 点検項目 | 実測例の結果 |
|---|---|---|
| 1 プロンプト | 恒常ルール・検証ゲートの文言が体系化されているか | 中層（CLAUDE.md+include構造・memory蓄積） |
| 2 コンテキスト | 必要情報が自動供給されるか（SessionStart読込・層別ルール） | 厚め（handoff自動読込・パススコープrules） |
| 3 ハーネス | ガード・検証・記録・通知がフックで機械化されているか | 最厚（6イベント50エントリ・自作スクリプト自動実行できる小さなプログラム。手順を書いたテキストファイルの形をしている100+） |
| 4 ループ | 定期実行・タスクキュー待ち行列。依頼された処理を順番に並べて、前から順に消化していく仕組み・完了ゲートが回り続けているか | 厚い（durable cron＋Triage＋TDDテスト駆動開発。先にテストを書き、そのテストを通すようにコードを書く進め方。「何をもって正しいとするか」を最初に固定できるゲート） |
| 5 グラフ | 完了前に別インスタンスのレビューが常設で走るか | 薄い（レビューは依頼時のみ手動発火） |
💡 診断の使い方: 全層を均等に厚くする必要はない。一番壊れている層に投資するのが原則で、多くの個人環境は層3（フック）より層5（別インスタンスレビュー）が先に薄くなる。
層5の実装パターン（未整備ならここから）
- 他モデルレビュー: 完了前に別LLMへレビューを依頼する（本ガイド環境では multi-llm-review スキルが該当・依頼時のみの手動発火が弱点）
- fresh-context監査: セッションを跨いで、前セッションの成果物を文脈ゼロの新セッションに検証させる
- 別コンテキストのsubagent: 同一セッション内でも、実装者と検証者を別subagent（クリーンなコンテキスト）に分ける
- 常設化の要諦: 手動発火のままでは「省略しても気づかれない」ので、フックやループのゲートに組み込んで通らないと先へ進めない形にする
公式ドキュメントとの対応
各層に対応する公式ドキュメントの索引は第22章 公式ドキュメント索引を参照。監視cronが公式サイトの新規ページを毎日検出し、同章に自動追記する。
関連章: 第6章 メモリ（層2）・第5章 フック（層3）・第18章 ループシステム（層4）・第16章 外部参考資料