🧭 5つのAIエンジニアリングを2軸3階層で整理する - Prompt / Context / Loop / Harness / Graph

AIエージェントの記事を読むと「◯◯エンジニアリング」が次々に出てきます。Prompt、Context、Loop、Harness、Graph。どれも「次はこれだ」と書いてあります。

しかし5つは競合していません。1つのシステムに重なった、別々の設計関心です。

この記事は、筆者が過去に書いた5本の解説記事を並べ直し、それぞれの特徴と違いを整理します。結論を先に言うと、5つに共通するのは「目的達成のためにLLMをどう制御するか」という問いであり、違いは制御の粒度と主な設計対象の2軸で説明できます。

整理日: 2026-08-18
対象: Prompt / Context / Loop / AI Harness / Graph Engineering の5概念

用語の関係だけ知りたい方は「概要」と「統一軸」を読んでください。自分の実装がどの層にいるか判定したい方は「3階層のハーネス」から「外側の構造例」を読んでください。この整理を疑いたい方は「反証・限界・適用条件」から読んでください。

概要

この記事の結論

扱う5つの概念

それぞれの詳細は元記事に譲り、この記事は関係の整理に集中します。

全体像

先に地図を示します。以降の章で、この図の各要素を順に説明します。

1つの外ハーネスが複数の実行単位（中＋内＋モデル）を運行する。層と層の間でループが回り、実行単位どうしのつながりがグラフを成す。

図の要素は次のとおりです。

読み方は2つです。

• ハーネスは器、ループは器の間の動きです。 外が起動し、中が選択肢を制約し、内でモデルが選びます。成果と終了コードは逆に、内から外へ返ります
• Context Engineering だけは、どの層にも属しません。 全層を貫いて、最終的にモデルへ入る情報を決めます。理由は「Context Engineering は層をまたぐ」で説明します

なぜ混乱するのか

用語が5つあることが問題なのではありません。同じ語が出典によって別の層を指していることが問題です。3つの具体例を示します。

1. Loop Engineering は出典によって外と内が逆になる

これが最も混乱を生みます。

前者では Loop Engineering は「コンテキストとプロンプトを包含する最上位層」と位置づけられます。後者では「graph の node の内部で継続するもの」と位置づけられます。

同じ「Loop Engineering」という語が、正反対の層を指している。

どちらも間違っていません。 ループという語が、実行単位の異なる2つの反復を同時に指しているだけです。この記事が loop を3段階に割るのは、この曖昧さを解消するためです。

2. harness が指す範囲は、出典と日常用法でズレる

AI Harness Engineering の論文（arXiv:2605.13357）は、harness を次のように定義しています。

• プロンプトでもエージェントフレームワークでもない
• foundation-model agent を包む 実行層（runtime substrate） である
• context / tools / project memory / task state / observability / failure attribution / verification / permissions を媒介する11の責務を持つ
• 成熟度は H0（タスク記述とファイルのみ）から H3（観測と検証まで）の4段階

境界の引き方が2箇所あります。

つまり論文の harness は、モデル自体も、CIやスケジューラのような起動側も含みません。その中間にある「モデルへの入力を組み立て、道具を登録し、権限を切り、記録を取る層」を指しています。

一方、日常の会話で「ハーネス」と言うとき、多くの場合はエージェントを起動して回す仕組み全体を指します。論文の定義のほうが狭い、というズレがここにあります。

3. Context Engineering はすべてを含むように読める

Context Engineering の解説は「モデルに渡すものすべてを設計する」と説明されます。この定義は正しいのですが、範囲が広すぎて他の概念との境界が消えます。

実際、モデルを呼び出す経路に限れば、ループもハーネスもグラフも、最終的にモデルへ渡る情報に影響します。だから「全部コンテキストエンジニアリングだ」という主張は成立してしまいます。成立してしまうがゆえに、設計の役に立ちません。

混乱の構造

3つの例に共通するのは、語が指す実行単位が明示されていないことです。

したがって、整理に必要なのは新しい用語ではありません。実行単位を明示する軸です。

統一軸 — 制御の粒度と設計対象

5つの概念は、次の2軸で区別できます。1つは順序を持つ尺度、もう1つは種類です。

軸1: 制御の粒度

何を1つの制御単位として扱うかです。5段階に分けます。

1. 1回のモデル呼び出し
2. 1ターン（呼び出しと観測の1往復）
3. 1セッション（1つのゴールに向かう連続した文脈）
4. 1プロセス実行（起動から終了コードを返すまで）
5. 複数の実行単位（独立に起動、失敗、再開しうるものの集合）

軸2: 主な設計対象

粒度が近くても、主に何を設計しているかが違えば別の概念です。

5概念にプロットすると以下のようになります。

5概念は左下から右上へ階段状に並ぶ。Loop と Harness は粒度が重なるため、設計対象の軸がないと分離できない。

図にすると、2軸が必要な理由が見えます。粒度だけでは Loop と Harness を分離できません。どちらも1ターンから1プロセス実行までにまたがるためです。分けているのは設計対象で、一方は反復を、もう一方は実行基盤を扱っています。

3階層のハーネス

3階層は、誰がその層の資産を作り、持ち運べるかで引きます。制御が効く実行スコープは、結果としてこれに対応します。

この境界で、コーディングエージェントは内側です。hooks や skills の「差し込み口の機構」はエージェントが提供するので内側、そこへ「差し込む中身」はユーザーが書くので中間です。socket と plugin の関係と同じです。CLAUDE.md や skills を別のエージェントへ移植できるのは、中間層の資産がエージェントの外にあるからです。

ここで、隣接するものとの境界を明示します。

この区別により、arXiv:2605.13357 の harness は内ハーネスと中ハーネスの双方にまたがると位置づけられます。論文の11責務には、ランタイム側の機構（context manager、tool registry）と、ユーザーが書く資産（project memory、task state）の両方が含まれるためです。

3段階のループ

反復は1種類ではありません。3つの階層それぞれに、別の反復があります。

• 内側では、モデルが tool を呼び、結果を見て、また呼びます
• 中間では、ゴールに達したか判定し、達していなければ自分にまたプロンプトを出します
• 外側では、実行が終わったあと、基準値に到達していなければまた起動します

この3つは1周の長さも、止め方も違います。以降はそれぞれを内ループ・中ループ・外ループと呼びます。階層の名前をそのまま使うので、対応を覚え直す必要はありません。

3段階を分ける実益は、終了の決め方をどこに書くべきかが決まることです。

その際、終了の決め方は3種類に分かれます。混ぜると事故になります。

ループとハーネスは同じ階層の表裏

同じ階層に、動き（ループ）とそれを支える器（ハーネス）があります。

この対応は1対1ではありません。 1つの器が複数の粒度に効きます。例えば hook スクリプトは PreToolUse のようなターン粒度のイベントと、SessionStart / Stop のようなセッション粒度のイベントの両方に差し込めます。逆に、中ループは資産を差し込まずランタイム内で完結させることもできます。

各概念の特徴と違い

2軸と3階層をふまえて、5概念を横並びで比較します。

列を右へ行くほど、扱う不確実性が増えます。 プロンプトは1回の出力品質だけを心配すればよいのに対し、グラフは「独立に失敗しうる複数の実行単位をどう合流させるか」まで心配する必要があります。

逆に言えば、右の概念が左を不要にすることはありません。グラフの node の中では相変わらずプロンプトが動いています。ループの中のずさんなプロンプトは、ずさんな作業を速く大量に生産するだけです。

中ハーネスの実装例

3階層のうち、中間は手元ですぐ確かめられます。 エージェントの差し込み口に、自分が差し込んでいる資産がそれです。

中ハーネスの実体は、次の6つの振る舞い契約に整理できます。エージェントをまたいで維持したいのは、資産のファイルそのものではなく、この契約です。

ここで重要なのは、この6契約が製品共通である一方、差し込み口の場所と読み込み規則は製品ごとに違うことです。ファイル名も、階層の優先順位も、連結かマージか上書きかも揃っていません。特に hooks は最も移植しにくい部分です。

移植という営みが成立すること自体が、境界の証明になっています。中ハーネスの資産がエージェントの外にあるから、エージェントを差し替えても資産を持ち運べます。 内ハーネス（ランタイム）は製品と一緒に入れ替わり、中ハーネス（資産）は残る。この分離が3階層の境界そのものです。

6製品（Claude Code、Codex CLI、GitHub Copilot CLI、Antigravity CLI、Grok Build、Cursor Agent CLI）を対象に、この差分を具体的に比較した記事を別に書いています。

• Claude Code や Codex などのコーディングエージェントをまたいで同じ動きをさせる拡張設計 - 6製品比較

中ハーネスを設計するとは、製品名の設定ファイルを書くことではなく、この6契約を決めてから各製品へ変換することです。移植の成否は「同じファイルを読めたか」ではなく「同じ入力に対して許容範囲内の行動になったか」で判定します。

Graph Engineering が足したもの

Graph Engineering は、3階層のうち外側に位置します。複数の実行単位の関係を、暗黙のループから明示的なグラフへ引き上げます。

主要な構成要素は3つです。

ループは消えません。 node の内部で継続します。Graph Engineering が扱うのは、ループ間の依存、受け渡し、ゲート、合流です。

外側でこれを明示する実益は、次の4つが可能になることです。

1. 再開: どこまで終わったかが state に残るため、途中から再開できる
2. 監査: どの node が何を根拠に次へ進んだかを後から追える
3. 並列: 独立した branch を同時に走らせ、合流点で待ち合わせられる
4. 段階的承認: 人間の承認を node として置き、そこで止められる

Context Engineering は層をまたぐ

「結局すべてコンテキストの話ではないか」という指摘は、半分正しく、半分間違っています。

その前に、混同しやすい2つを分けます。

「従属変数」と呼べるのは後者です。設計活動そのものは、どの層にも従属しません。

正しい部分

モデルを呼ぶ node に限れば、すべての層が runtime context を動かしています。

• プロンプトは、その1回の内容を決める
• 中ハーネスは、どの規約と道具が読まれるかを決める
• 中ループは、何回積み増すかを決める
• 外側のグラフは、どの node にどの state が渡るかを決める

収束先が同じなので、Context Engineering はどの層とも接続します。

間違っている部分

収束先が同じことと、扱う制約が同じことは別です。 Context Engineering の語彙では説明できないものがあります。

したがって、Context Engineering は3階層のどれかに属す概念ではありません。全層を縦に貫く横断的な設計関心です。全体像の図で階層の外に置いたのは、上位でも下位でもなく直交するためです。

外側の構造例

外側は最も語られない層です。そこで、筆者が運用している自動化基盤の構造を紹介します。

4つの部品

外側から内側へ起動が降り、成果物と終了コードが外へ戻る。

この構造から見えること

5つの概念が1つのシステムに同居しています。 どれか1つを選ぶ設計判断は発生しませんでした。発生したのは「この制御をどの層に置くか」という判断だけです。

例えば次のような割り振りになります。

この構造を全体像へ重ねると、4つの部品がそれぞれの層に収まります。

反証・限界・適用条件

反証1: 既存概念の再命名にすぎない

最も強い批判です。Graph Engineering に対しては「loop も graph も有用なパターンだが、古典的な workflow、state machine、分散システムの再命名でもある」という反論が公開されています。長期的な価値は topology ではなく、worker、function、trigger、queue、trace といった substrate 側にある、という主張です。

この批判は、本記事の3階層モデルにもそのまま当たります。 内側・中間・外側という分割は、OSレイヤやミドルウェアの議論で繰り返し使われてきた形です。新しい発見ではありません。

それでも整理する価値があるとすれば、次の2点です。

1. 用語の混乱によって、実務者が自分の問題をどの層で解くべきか判断できない状態が実在する
2. 3階層は結論ではなく判定手順として使える。新しい理論を提供するものではない

反証2: 3階層は本記事の独自拡張である

繰り返しになりますが、この3分割はどの出典にも存在しません。

「論文が3階層を定義している」と読まないでください。定義しているのは筆者です。

反証3: 構造例は検証できない1事例である

「外側の構造例」は匿名化した参照構造であり、読者が検証する手段がありません。一般性の主張でもありません。

検証可能な裏づけは中間層だけです。6製品の拡張ポイントは公式ドキュメントで確認できます。外側の記述は型の提示として読んでください。

適用条件: 層を分けるべきでない場合

3階層は常に必要ではありません。次の場合は分けないほうが速く進みます。

外側を作る主な動機は「人間が見ていないこと」です。 見ているうちは、成否判定も再試行も人間が担えます。

なお、明示グラフの動機は並列だけではありません。1回の仕事の中でも、長期の再開、人間承認、決定的処理と非決定的処理の混在があれば、明示する価値があります。

この記事の限界

• 一次資料の主張は、筆者の既存記事を経由した整理です。原典の細部は各記事と原典URLを参照してください
• 各製品の拡張ポイントは更新が速く、記載時点の情報です

まとめ

5つの関係

• 5つは競合しません。1つのシステムに重なった、別々の設計関心です
• 共通する問いは「目的達成のためにLLMをどう制御するか」です
• 違いは制御の粒度と主な設計対象の2軸で説明できます
• Context Engineering だけは階層に属さず、全層を縦に貫く横断的な関心です

いま扱っている問題を切り分けるチェックリスト

層は排他ではありません。1つの実行では、ターンもセッションもプロセスも順に発生します。したがって「どの層か」を1つに決めるのではなく、いま困っていることがどの関心に属すかを切り分けます。

該当するものすべてにチェックを付けてください。

1. 何を変えようとしているか

2. 制御がどこで効いているか

規約を読んだモデルが選ぶ場合、内側と中間の両方が該当します。その場合は「どこまでを規約で縛り、どこからモデルに委ねるか」が設計点です。

3. 完了シグナルと強制上限が、スコープごとに揃っているか

強制上限が空欄の行があれば、そこが暴走の入口です。 なお、成果物を見て成否を判定する仕組みは終了後の評価であり、この表の停止条件とは別に用意します。

4. 状態、再開、権限、予算を誰が保証しているか

誰も保証していない項目があれば、それが次に設計すべきものです。項目ごとに担い手が違います。

外部保証がすべて明示グラフを必要とするわけではありません。 依存の宣言だけならスケジューラで足ります。グラフが要るのは、状態を型付きで受け渡し、途中から再開したいときです。

用語が5つあることに悩む必要はありません。いま困っていることがどの関心に属すかを言えれば十分です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNS でのシェアをいただけると励みになります！

参考リンク

本記事が整理した5記事

• プロンプトエンジニアリングの進化 - 人間中心からAIエージェントへ
• Context Engineering入門：AIに何を渡すかをシステムとして設計する
• AI Harness Engineering入門：エージェントを包む実行層を契約として設計する
• Loop Engineering入門：AIコーディングエージェントを動かすシステムを設計する
• Graph Engineering入門：AIエージェントのループを明示グラフへ変える

中ハーネスの実装例

• Claude Code や Codex などのコーディングエージェントをまたいで同じ動きをさせる拡張設計 - 6製品比較

一次資料

• Josh C. Simmons, We Are Entering the Graph Engineering Phase
• iii, Loops, Graphs, and the Layer That Matters
• Anthropic, Building effective agents
• arXiv:2605.13357, AI Harness Engineering: A Runtime Substrate for Foundation-Model Software Agents
• arXiv:2604.11378, From Agent Loops to Structured Graphs