よく混同される 3 つのレイヤーに関する実践ガイド
ほとんどの人は AI エージェントをひとつのものとして語ります。
しかし、実際はそうではありません。
エージェントがおもちゃレベルのデモを超えて、ファイル、API、ドキュメント、顧客、本番コードに触れるようになると、それはもはや単なる「モデルへのプロンプト」ではありません。
あなたはシステムを設計しているのです。
そしてそのシステムにおいて、以下の 3 つの概念がよく混同されます。
- エージェントハーネスエンジニアリング
- ループエンジニアリング
- グラフエンジニアリング
これらはすべて同じモデルの周りに存在します。
すべてが信頼性に影響を与えます。
そして、確かにどれもループを含むことがあります。
しかし、それらが解決する問題は異なります。
これらを混同すると、間違ったレイヤーをデバッグすることになります。
30 秒でわかる答え
簡潔に言うと、こうです。
- ハーネスエンジニアリングは、モデルを動かす環境を構築する
- ループエンジニアリングは、作業とフィードバックの繰り返しサイクルを設計する
- グラフエンジニアリングは、ワークフローのトポロジーを明示的にする
良いメンタルモデルは次の通りです。
環境 → フィードバック → フロー
- ハーネスはモデルにツール、メモリ、制御、ワークスペースを与える
- ループは作業の再試行、チェック、改善の仕方を決める
- グラフは次にどのステップが許可されるかを定義する
これが違いです。
なぜ今これらの用語が重要なのか
生のモデルだけでは、実際の作業を自力で行うことはできません。
モデルは以下のことができません。
- セッションをまたいでプロジェクトの状態を維持する
- 安全にツールを呼び出す
- ブラウザを操作する
- 権限を強制する
- 失敗した作業を再試行する
- 出力品質を検証する
- タスクを専門家に振り分ける
- 適切なタイミングで停止する
これらはすべて、モデルの周囲のシステムに由来します。
エージェンティックソフトウェアが成熟するにつれて、実用的なスタックが現れています。
- ハーネスはモデルに動作条件を与える
- ループは作業を反復可能かつ検証可能にする
- グラフは複雑なワークフローを明示的かつ制御可能にする
これらを別々のレイヤーとして捉えると、AI アーキテクチャに関する多くの混乱が消えます。
本格的なハーネスに通常含まれるもの
- コンテキスト注入
モデルが動作する前に見るもの：
- 指示
- 検索された知識
- 会話の状態
- メモリ
- ポリシー
- タスク固有のルール
- アクション面
モデルが実行できること：
- API 呼び出し
- ブラウザ操作
- シェルコマンド
- コード実行
- MCP ツール
- データベース
- カスタム関数
- 永続性
時間を超えて維持されるもの：
- ファイル
- チェックポイント
- セッション状態
- 進捗ログ
- git 履歴
- 長期記憶
- 実行制御
実行の管理方法：
- リトライ
- タイムアウト
- 予算
- モデル選択
- サブエージェントの生成
- 承認ゲート
- 安全性とガバナンス
システムを安全に保つもの：
- 最小権限
- 分離
- 許可リスト
- 機密情報の取り扱い
- 人間による承認
- 可観測性
デバッグを可能にするもの：
- トレース
- ツールの入出力
- 状態遷移
- レイテンシ
- コスト
- 評価結果
ハーネスエンジニアリングが重要な理由
2 つのチームが同じモデルを使っても、まったく異なる結果を得ることがあります。
なぜでしょうか？
それは、あるチームはモデルに以下を与えるからです。
- クリーンなツール
- 安定した状態
- 構造化されたメモリ
- 明確な権限
- 観測可能な実行
そして、別のチームは以下を与えます。
- 曖昧なプロンプト
- 散らかったツール
- ノイズの多いコンテキスト
- メモリなし
- 検証なし
モデルは同じかもしれません。
しかし、動作条件は同じではありません。
ハーネスエンジニアリングは、エージェントが以下の状況にある場合に重要です。
- 適切な機能にアクセスできない
- セッション間でコンテキストを失う
- 環境間で一貫性のない動作をする
- 監査できない
- 権限が多すぎる
- 中断後にクリーンに復旧できない
モデルが確実に動作できない場合、最初に確認すべきはハーネスです。
2. ループエンジニアリング
その概要
ツールを使うすべてのエージェントには、すでに小さな組み込みループがあります。
- モデルを呼び出す
- 結果を観察する
- ツールを実行する
- 観察結果をフィードバックする
- 完了するまで繰り返す
ループエンジニアリングは、その動作の周りに意図的に追加のサイクルを設計するときに始まります。
単なる「もう一度聞く」ではありません。
単なる「リトライ」ではありません。
しかし、実際の作業とフィードバックのシステムです。
良いループの構造
トリガー
何が新しいサイクルを開始するのか？
- ユーザーリクエスト
- テストの失敗
- 新しいドキュメント
- スケジュール実行
- Webhook
- 評価者のフィードバック
目標
どのような特定の条件に到達しようとしているのか？
「改善し続ける」ではありません。
実際のターゲットです。
状態
次のサイクルは何を知る必要があるのか？
- 現在のドラフト
- 前回の試行
- ツールの結果
- エラー
- 進捗状況
アクションポリシー
エージェントは何を許可されているのか？
- 編集
- 委任
- ツール呼び出し
- トークン消費
- ファイル書き込み
- PR 作成
証拠
それが機能したかどうかをどうやって知るのか？
- テスト
- スキーマ検証
- 引用
- 差分
- メトリクス
- レビュアーの承認
フィードバック
何が正確に失敗したのか？
フィードバックはコンパクトで実行可能であるべきです。
停止ルール
いつ終了するのか？
- 成功
- タイムアウト
- 予算枯渇
- 最大リトライ回数到達
- 回復不可能な失敗
- 人間へのエスカレーション
ループエンジニアリングにおける最も重要な原則
**自信に基づいてループするな。
証拠に基づいてループせよ。**
「エージェントが完了したと言った」ことは停止条件ではありません。
実際の停止条件は次のようになります。
- テストが通る
- スキーマが検証される
- 引用が解決される
- レビュアーが承認する
- ポリシーチェックがクリーン
それがループエンジニアリングです。
ループエンジニアリングが単なるプロンプトエンジニアリングではない理由
プロンプトは、呼び出し中にモデルが何をするかを指示します。
ループは、呼び出し後にシステムが何をするかを定義します。
これには以下が含まれます。
- 結果をどのようにチェックするか
- 失敗にどう反応するか
- 進捗をどう永続化するか
- 継続するかどうかをどう決定するか
- どう終了するか
プロンプトは応答を改善します。
ループはプロセスを改善します。
これは非常に異なるエンジニアリング問題です。
3. グラフエンジニアリング
その概要
グラフエンジニアリングは、ワークフローの構造を明示的にします。
それは異なる問いに答えます。
「エージェントは何をすべきか？」だけでなく、 「次に何が起こることが許されるのか？」
グラフエンジニアリングでは：
- ステップはノード
- 遷移はエッジ
- 分岐は明示的
- 並列作業は明示的
- 結合は明示的
- リトライは明示的
- 人間による割り込みは明示的
グラフはシステムの制御マップになります。
グラフエンジニアが実際に設計するもの
ノードの境界
何が属するか：
- 決定論的な関数
- LLM 呼び出し
- 専門エージェント
- 人間によるレビューステップ
状態スキーマ
各ノードが読み書きできるもの。
ルーティング条件
どの証拠がジョブを動かすか：
- 前方
- 後方
- 横方向
- エスカレーションへ
並行性
何が並行して実行でき、何が待たなければならないか。
サイクルと出口
リトライが許可される場所、許可される回数、停止方法。
耐久性
チェックポイントが発生する場所と、中断後にワークフローが再開する方法。
グラフが価値を持つとき
グラフは、プロセスに以下が含まれる場合に価値があります。
- 意味のある分岐
- 承認
- 専門家への引き継ぎ
- 並列作業
- 回復パス
- 明示的な制御ポイントを持つ複数ステップのワークフロー
仕事が単に以下のような場合、グラフはあまり役に立ちません。
「1 つのエージェントにいくつかのツールを与えて、作業させる。」
その場合、堅牢なハーネスといくつかのループで十分かもしれません。
グラフは明確さを追加しますが、構造も追加します。
構造を早すぎる段階で入れすぎると、システムが脆くなる可能性があります。
3 つのレイヤーがどのように連携するか
あなたが調査・出版エージェントを構築しているとしましょう。
これは以下を行う必要があります。
- トピックをスコープする
- ソースを収集する
- 引用をスクリーニングする
- レポートをドラフトする
- 法務レビューを通過する
- 承認後にのみ公開する
レイヤーのマッピングは次のようになります。
ハーネス
提供するもの：
- ブラウザアクセス
- 検索ツール
- ファイルワークスペース
- メモリ
- 引用
- 承認
- トレース
- モデルルーティング
ループ
処理するもの：
- 証拠が弱い場合のソース取得の再試行
- 引用失敗の修正
- 採点チェックの実行
- 市場が変化したときの作業のリフレッシュ
グラフ
パスを制御するもの：
- スコーピング
- リサーチ
- スクリーニング
- 統合
- ドラフト作成
- レビュー
- 公開
リリース前には人間のゲートがあります。
だからこそ、3 つのレイヤーは互換性がありません。
それらは連携しますが、同じものではありません。
修正を選ぶ前に障害を診断せよ
実用的なルールは次のとおりです。
エージェントが動作できない場合は、ハーネスを修正せよ
例：
- ツールアクセスがない
- 状態が古い
- メモリが弱い
- 権限が悪い
- 可観測性がない
エージェントはほぼ動作するが信頼性が低い場合は、ループを修正せよ
例：
- 初稿は近いが弱い
- 成功が一貫しない
- リトライが制御不能
- 完了の証明がない
プロセス自体が複雑な場合は、グラフを修正せよ
例：
- 多くの専門家
- 承認
- 分岐ロジック
- 並列パス
- 構造化された引き継ぎ
よくある間違い
1. グラフを早すぎる段階で構築する
チームは、作業が実際にどのように振る舞うかを見る前に、巨大なワークフローを図に描くことがよくあります。
より良いアプローチ：
- シンプルなハーネスから始める
- トレースを収集する
- 安定したパターンを見つける
- 制御に値するものだけを形式化する
2. 同じモデルに安全策なしで作成と採点をさせる
自己レビューは役立つことがありますが、同じ盲点を共有します。
推奨：
- 可能な限り決定論的なチェックを使用する
- 別のレビューアコンテキストを使用する
- 外部評価者を使用する
- 影響の大きいアクションには人間の承認を求める
3. 「試し続ける」をループとして使う
それはループ設計ではありません。
それは制御不能なコスト漏れです。
すべてのループには以下が必要です。
- 測定可能な目標
- 実際の証拠
- リトライ制限
- エスカレーションルール
4. ハーネスを引き出しのジャンク置き場として扱う
ツールが多ければ、自動的にエージェントが良くなるわけではありません。
ツールが多すぎると、以下が発生します。
- 選択ミス
- ノイズの多いコンテキスト
- 弱い信頼性
- 広いリスク面
良いハーネスは混雑していません。
それは正確です。
5. オーケストレーションの失敗をモデルのせいにする
モデルは以下を補うことはできません。
- 壊れた API
- 古い状態
- 欠落した終了条件
- 曖昧なツールスキーマ
- 目に見えない障害モード
障害を所有するレイヤーを修正してください。
シンプルなプロダクションチェックリスト
ハーネス
- ツールは狭く、文書化されているか？
- 状態は永続的か？
- 権限は最小限か？
- オペレーターは一時停止、検査、再開できるか？
- トレースは可視か？
ループ
- 成功を証明する証拠は何か？
- 失敗時に返されるフィードバックは何か？
- リトライは何回許可されているか？
- 停止ルールは何か？
- 予算が尽きたらどうなるか？
グラフ
- どのパスが決定論的でなければならないか？
- 何が並行して実行できるか？
- 人間のゲートはどこにあるか？
- どの状態が共有されるか？
- 回復パスはどこから始まるか？
評価
- 実際のトレースを再生できるか？
- バージョンを比較できるか？
- 改善を実際の変更に帰属できるか？
運用
- コストを追跡しているか？
- レイテンシは？
- 障害率は？
- 介入率は？
- 本番でのタスク成功率は？
違いを覚える最も簡単な方法
もし一つだけ覚えるなら、これを覚えてください。
- ハーネスエンジニアリングはモデルを運用可能にする
- ループエンジニアリングは作業を反復可能かつ検証可能にする
- グラフエンジニアリングは実行パスを明示的かつ制御可能にする
どれも他のものを置き換えるものではありません。
完璧なグラフも、弱いハーネスを救うことはできません。
強力なハーネスも、良いループがなければ依然としてお金を無駄にします。
そして、きれいなループも、分岐や承認がアドホックなコードに隠れていると、管理が難しくなります。
信頼性の高いエージェントシステムは、3 つのレイヤーすべてが意図的に設計されたときに現れます。
それが実際のアーキテクチャスタックです。
最後に
人々は、AI エージェントのブレークスルーはモデルだと言い続けています。
本番環境では、それはめったに本当の差別化要因ではありません。
差別化要因は、モデルの周囲のシステムです。
- モデルを動作させるハーネス
- モデルを改善させるループ
- モデルを制御下で動作させるグラフ
それが、おもちゃのエージェントを実際のシステムに変えるものです。
ここまで読んだなら：
- ブックマークしてください。
- Follow @LunarResearcher (LunarResearcher をフォロー)
- Follow my Substack (私の Substack をフォロー)
- Follow my Private Telegram Channel (私のプライベート Telegram チャンネルをフォロー)
