ループは、次に何を実行するかという決定をブラックボックスの中に隠してしまいます。
エージェントループがリトライ、エスカレーション、または次に進むかを決定するたびに、その決定はモデル自身の推論の中で行われ、あなたには見えず、事後に監査することもできず、モデルの生の出力を再読して正直に説明していることを期待する以外に検査する方法はありません。グラフは、その同じ決定を明示的にします。文書化します。実行が始まる前から検査可能にします。
これは小さな違いではありません。これは、2026 年 4 月に発表された、エージェントシステムをどのように構築すべきかを再定義した実際の arXiv 論文の背後にある実際の議論であり、このコースがこれ以上進む前に、あることについて正直になる価値があります。この論文の著者自身が、これは未実装の設計であり、実際に約束された利益を提供できるかどうかは、未解決の経験的な問題であると明確に述べる公正性の免責事項を含めています。このコースは、その注意点を含めて、このフレームワークを正直に教えます。なぜなら、まだ大規模に証明されていない、実際に厳密に議論された提案を理解することは、それが確定した事実であると偽るよりも有用だからです。
このコースを終えるまでに、あなたはグラフエンジニアリングが実際に何であるか、なぜそれがループの上のレイヤーとして存在するのか、このフレームワーク内のすべてのグラフが依存する 3 つのコミットメント、そして最初のグラフを構築する方法、そして現在の証拠がどこにあり、どこにないかについての正直な説明を理解するでしょう。
ループが天井に達する理由
グラフがなぜ存在するかを理解するには、ループが正確にどこで十分ではなくなるのかを理解する必要があります。
ここで重要なエージェント的な意味でのループは、エージェントがタスクを試み、結果を観察し、次に何をするかを決定し、何らかの条件が満たされるまで繰り返すサイクルです。これは、非常に多くのタスクで驚くほどうまく機能します。しかし、構造的には、最も重要な瞬間、つまり次に何が起こるかという決定において、ブラックボックスになります。
ループのエージェントが失敗したステップをリトライすることを決定するとき、その決定は、モデルが自身のコンテキストを推論し、選択肢を生成することから生まれます。決定が起こる前にそれを検査することはできません。結果を観察できるのは事後だけです。エージェントが同じ失敗するアプローチを 5 回連続でリトライし、毎回コストを消費しても、ループの構造はそれを防ぎませんでした。リトライするという決定は、モデル自身の判断の内部に完全に存在し、外部のチェック可能なルールには存在しなかったからです。
これは、たまに無駄なリトライが発生しても意味のあるコストがかからない、リスクの低い安価なタスクでは問題ありません。しかし、長期間、高コスト、またはリスクの高い作業、まさにエージェントシステムがますます信頼されるようになっているタスクのカテゴリでは、実際の責任になります。この論文の核心的な議論は、エージェントシステムがより重要な作業を引き受けるにつれて、「次に何を実行するか」の不透明さが許容可能なブラックボックスではなくなり、実際にエンジニアリングで直接対処する価値のある障害点になり始めるということです。
グラフとは実際には何か
このフレームワークにおけるグラフは、モデルの暗黙的な次のステップの決定を、実行開始前に定義された明示的な構造に置き換えます。
エージェントが不透明なコンテキストウィンドウ内で「リトライすべき」または「エスカレーションすべき」と推論する代わりに、グラフは、どの状態が存在するか、どの状態間の遷移が有効か、そして各遷移をトリガーする特定の条件を事前に定義します。エージェントは依然として各状態内で実際の作業を行います。しかし、プロセス全体の形状を目に見えない形で決定することはもうありません。
このようなグラフを通る任意の単一ターンを記述する 5 つの動きの構造は、次のとおりです。計画、実行、回復、エスカレーション、繰り返し。計画は、タスクが定義されたシーケンスに分解される場所です。実行は、エージェントが現在のステップの作業を実際に行う場所です。回復は、実行が失敗したときに何が起こるかであり、その場しのぎのリトライではなく、定義されたプロトコルに従います。エスカレーションは、グラフが自動回復を試み続けるのではなく、制御を人間に委ねる明示的で定義されたポイントです。繰り返しはサイクルを閉じ、計画の次のステップに移動します。
ループから何が変わったかに注目してください。これら 5 つの動きのそれぞれは、単一のモデル呼び出し内で静かに行われる決定ではなく、定義された遷移を持つ、グラフ内の名前付きで検査可能な状態になりました。
3 つのコミットメント
このフレームワーク内のすべてのグラフは、3 つの特定のコミットメントに依存しています。これら 3 つを深く理解することは、特定の実装の詳細よりも、グラフエンジニアリングという分野の実際の核です。
コミットメント 1: 不変の計画
実行計画は実行中に変更できません。計画が生成されロックされると、その実行の間、1 つの固定バージョンとして存在します。エージェントは、ループ内のエージェントが改訂の外部記録なしで頻繁に行うように、実行の途中で気付いたことに基づいて、静かに自身の計画を修正することはできません。
これは制限的に聞こえますが、その意図があります。制限こそが要点です。実行中に自由に自身の計画を修正できるエージェントこそ、事後に行動を監査することが不可能になるエージェントです。なぜなら、後でレビューする計画は実際に従われた計画ではなく、計画が終了時までに漂流したものだからです。計画をロックすることは、実際の柔軟性を実際の検査可能性と交換することです。そのトレードオフは無料ではなく、すべての場合において厳密な改善として扱うのではなく、正直に検討する価値があります。元の計画が想定していなかった本当に新しい状況は、不変の計画によって、自由に適応できるループよりも悪く処理されます。このコミットメントは、このフレームワークが対象とするタスクのカテゴリでは、予測可能性と監査可能性が最大限の適応性に勝るという意図的な賭けです。
コミットメント 2: 分離されたレイヤー
計画、実行、回復は、3 つすべてが同じ連続した推論プロセス内で行われる、1 つの絡み合ったループではなく、3 つの独立したレイヤーに存在します。
計画レイヤーは、コミットメント 1 からの不変の計画を生成し、それ以外は何もしません。ステップを実行したり、障害を処理したりしません。実行レイヤーは、定義されたステップを実行し、結果を報告します。失敗した場合に何が起こるかを決定するのではなく、何が起こったかのみを報告します。回復レイヤーは、失敗レポートを受け取り、定義されたプロトコルを適用します。新しい作業を直接実行するのではなく、すでに発生したことにどのように対応するかを決定するだけです。
この分離は、検証ループにおいてビルダーをジャッジから分離するのと同じ原理を意図的に反映しています。つまり、作業を生成する役割は、その作業を評価または決定する同じ役割であるべきではありません。なぜなら、2 つを一緒にすると、チェックを意味のあるものにする独立性が損なわれるからです。ここでは分離は 2 つではなく 3 つですが、根底にある推論は同じです。つまり、計画、実行、回復をすべて 1 つの未分化なプロセス内で行うシステムは、これら 3 つの機能のいずれかを独立して意味のある形で監査することはできません。なぜなら、後でレビューするトレースでは、それらが実際に明確に区別されることが決してないからです。
コミットメント 3: 厳格なエスカレーション
回復は、無期限にリトライして何かが最終的にうまくいくことを期待するのではなく、固定されたプロトコルに従います。
これは、実際の停止条件のないループを悩ませるトークン吹き飛ばし障害モードに最も直接的に対処するコミットメントです。厳格なエスカレーションプロトコルは、許可される回復試行の正確な回数、回復試行が成功または失敗したと見なされる正確な内容、そして定義された制限に達した瞬間に何が起こるか（制御を人間に委ね、同じ失敗したアプローチのさらに別の創造的なバリエーションを試みない）を事前に定義します。
70 の実際のシステムを対象としたこの論文の分析では、エージェントループの実装の大部分が回復試行に正式な制限をまったく持たず、つまり、問題が発生したときの実際の動作は、人間が事前に実際にレビューして承認したルールではなく、その瞬間にモデルがたまたま決定したものによって決定されていたことがわかりました。厳格なエスカレーションは、その特定のギャップを直接埋めます。
最初のグラフを構築する
これらを実際に構築するための実践的なパスを以下に示します。3 つのコミットメントを、概念的に理解するだけでなく、実装できるものに変換します。
まず、コードやプロンプトを書く前に、紙の上で状態を明示的に定義します。典型的なタスクの場合、これは通常、少なくとも次のようになります。計画、ステップ N の実行、障害からの回復、エスカレーション済み、完了。各状態について、システムがその状態にある間に正確に何が起こるか、そしてそこから遷移を引き起こす正確な条件を書き留めます。
計画生成ステップは、その出力が固定されたバージョン管理されたアーティファクトであり、システムの残りの部分が静かに編集できる生きているドキュメントではないように記述します。これのシンプルで実用的なバージョンは、計画を個別のステップの番号付きリストとして生成し、各ステップに明示的な成功基準を設定し、そのリストを実行の残りの間読み取り専用として扱うことです。そこから逸脱する真の必要性がある場合は、静かな内部改訂ではなく、人間への明示的なエスカレーションをトリガーする必要があります。
実行レイヤーは、結果（合格、不合格）を具体的な詳細とともに報告するだけで、次に何が起こるかについて自分で決定を下すことは決してないように構築します。これは、検証ループのビルダーの役割を正確に反映しており、作業を生成して正直に報告しますが、リトライするかどうかを決定する役割でもあるわけではありません。
回復レイヤーは、明示的で番号付けされたプロトコルで構築します。特定の代替アプローチを 1 つ試みます。それが失敗した場合は、2 番目の異なる特定のアプローチを試みます。それも失敗した場合は、エスカレーションします。プロトコルは、事前に読んだ人間が各段階でシステムが正確に何を行うかを予測できるように十分に具体的である必要があり、「適切な回数修正を試みる」のような漠然とした指示ではありません。
エスカレーション状態は、そこに到達することが実際の目に見えるイベントであり、静かにログに記録されて忘れられるものではないように配線します。人間は、何が試みられ、各試行がなぜ失敗したかの完全な履歴とともに通知される必要があります。これは、一般的に検証ループの停止条件に推奨されるのと同じ規律です。
このフレームワークが本当に役立つ場面と、そうでない場面
グラフエンジニアリングの限界について正直であることは、それをあらゆる状況においてループよりも普遍的なアップグレードとして扱うよりも有用であり、論文自体もこのよりバランスの取れた枠組みを支持しています。
グラフは、問題が発生する可能性のある領域が事前に十分に理解されているタスク、監査可能性が最大限の適応性よりも重要なタスク、そして暴走する無制限のリトライサイクルのコストが、計算コストまたは悪い結果が実際のユーザーや実際のシステムに到達した場合の結果のいずれかにおいて、実際に高額になるタスクに実際に役立ちます。
グラフは、障害の形状を事前に有意義に予測できない、そしてシステムの価値がまさに誰も予期しなかったことへの対応を即興で行う能力にある、真にオープンエンドで探索的なタスクには適していません。新しい情報が出現するにつれて適応的な再計画を本質的に必要とするタスクに対して計画を不変にロックすることは、そもそもそのタスクをエージェントで自動化する価値を生み出した正確な能力を犠牲にします。
正直で防御可能な立場、そして論文の著者自身が取る立場は、これはあらゆる場合においてループの厳密に優れた代替品ではなく、深く理解する価値のある実際のトレードオフであるということです。適応性が監査可能性よりも重要な場合はループを使用します。逆の場合はグラフを使用します。ほとんどの実際のシステムは、いずれかを恒久的なデフォルトとして採用するのではなく、両方のパターンを利用可能にし、タスクごとに意図的に選択することで恩恵を受けます。
実例：グラフ構造化コード移行
5 つの動きの構造と 3 つのコミットメントを具体化するために、これらが実際の一般的なタスク、つまりコードベース全体にわたるレガシーモジュールの新しいフレームワークバージョンへの移行にどのように適用されるかを示します。
計画状態は、開始時に 1 回実行されます。モジュールを分析し、変更が必要なすべてのファイルを特定し、移行ステップの固定された番号付きリストを作成します。各ステップには明示的な成功基準があります。たとえば、ステップ 4 は、更新されたファイルがコンパイルされ、そのファイルの既存のテストスイートが変更なしで合格した場合に成功します。この計画はロックされます。これは、実際にはコミットメント 1、不変です。
実行状態は、計画のステップを順番に処理します。各ステップについて、計画で定義された特定の変更を適用し、結果（合格または不合格）を、実際のコンパイラ出力またはテスト結果を証拠として添付して報告します。自己評価の「正しく見える」ではありません。これは、コミットメント 2 の実行レイヤーであり、失敗した場合に何が起こるかについての決定から厳密に分離されています。
ステップが失敗すると、グラフは回復に遷移します。これは、その場しのぎのリトライではなく、定義されたプロトコルに従います。試行 1：同じ変更をより狭いスコープで再適用し、ファイルのどの部分がコンパイルエラーを引き起こしたかを正確に特定します。最初の試行が失敗した場合の試行 2：この特定の種類の障害に対して文書化された代替移行パターンにフォールバックします。これは、毎回新しく発明するのではなく、既知の修正の小さなライブラリから引き出されます。両方の定義された試行が失敗した場合、グラフはエスカレーション済みに遷移します。これはコミットメント 3、厳格なエスカレーションであり、3 回目の即興の試行ではありません。
エスカレーション済み状態は、完全な履歴（どのステップが失敗したか、両方の回復試行が何を試みたか、および各試行の特定のエラー出力）を添付して、人間に直接通知します。人間は、エージェントがその間ずっと同じ壊れたアプローチをループ内で静かにリトライし、なぜの記録もなくコストを消費していたことを後日発見するのではなく、完全なコンテキストでこの特定の失敗をレビューします。
繰り返しは、成功したステップのサイクルを閉じ、グラフをロックされた計画の次の項目に移動し、リストが使い果たされるまで続け、その時点で実行は完了に達します。
これを、構造化されていないループとして実行される同等のタスクと比較して、何が得られるかに注目してください。リトライするかどうか、どのように、いつ諦めるかというすべての決定は、実行が開始される前からグラフの定義された構造に表示されており、後でトランスクリプトを読んでモデルが何を考えていたかを推測することによってのみ発見できるわけではありません。コードレビュー担当者、またはコンプライアンス監査担当者は、グラフの定義だけを見て、システムがすべての障害シナリオで正確に何を実行できるかを、実行を監視することなく知ることができます。
グラフエンジニアリングとループエンジニアリング：どちらをいつ使うか
両方のパターンが実際に文書化されており、それぞれに真の強みがあることを考えると、特定のタスクに対してどちらかを選択するための実践的な決定フレームワークを以下に示します。どちらかを恒久的なデフォルトとして扱うのではありません。
タスクが真に探索的であり、何が問題になる可能性があるかを事前に予測できず、予期しないことへの対応を即興で行うモデルの能力がまさに依存している能力である場合は、ループを使用します。研究タスク、根本原因が開始時に真に不明であるオープンエンドのデバッグ、および厳格な構造が出力を積極的に損なう創造的な作業は、すべてグラフの監査可能性よりもループの適応性を好みます。
タスクが事前に十分に理解されており、起こりそうな障害モードを実際に列挙でき、無制限で監査されていないリトライサイクルのコストが実際に高額になる場合、そして人間のレビュー担当者（コンプライアンスチーム、セキュリティ監査担当者、または単に本番インシデントをデバッグする将来の自分自身）が、完全な実行トランスクリプトを再読することなく、システムが正確に何を実行できたかを検査する必要がある場合は、グラフを使用します。移行、金融取引、規制対象データに触れるもの、および障害が誰にも気づかれずに何時間も悪化する可能性がある長時間実行される無人エージェント作業は、すべてループの柔軟性よりもグラフの構造を好みます。
これら 2 つのパターンは、単一のより大きなシステム内で相互に排他的ではありません。一般的な実用的な設計では、外側のレベルでグラフを使用し（全体的なタスク構造とその停止条件）、一方で、特定の 1 つのステップを実装する方法を理解するという真に探索的なサブタスクのために、単一の実行状態内でループを実行できるようにします。これにより、最も重要なレベル（システムが実行できることの全体的な形状）でグラフの監査可能性を獲得しながら、真の即興が実際に価値があるレベル（1 つの限定された作業の詳細）でループの適応性を維持できます。
グラフを信頼する前にテストする
グラフ構造化システムを実際の何かに依存する前に、3 つのコミットメントに特化して設計されたストレステストを実行します。各コミットメントには、ずさんに実装された場合に静かに失敗する独自の方法があるためです。
不変の計画コミットメントをテストするには、実行の途中で、システムが自由に推論している場合に「明らかに正しい」次のステップがロックされた計画から逸脱するシナリオを意図的に構築します。システムが、静かに計画を自分で適応させるのではなく、実際に人間にエスカレーションすることを確認します。静かに適応させる場合、コードがどのように構造化されているかに関係なく、計画は実際には不変ではありませんでした。
分離されたレイヤーのコミットメントをテストするには、実行レイヤーの障害レポートに、次に何が起こるべきかについての決定の痕跡が含まれていないかどうかを確認します。中立的な合格または不合格のレポートに埋め込まれた「これはおそらく別のアプローチが必要」などのフレーズがないか確認します。実行レイヤーがすでに回復について意見を形成している場合、回復レイヤーからの分離は実際にはなく、単に名前が変更されただけです。
厳格なエスカレーションをテストするには、定義された回復試行では修正できない障害をシステムに意図的に与え、定義された制限で、未定義の 3 番目のアプローチを試みるのではなく、きれいにエスカレーションすることを確認します。これは、真に解決不可能なタスクに対するループの停止条件をテストすることのグラフエンジニアリング版であり、同じクラスの静かに高価な障害を捕捉します。
これらの 3 つのターゲットテストに加えて、ループベースの代替手段では通常きれいに得られない特定のメトリックを実際の使用状況で追跡します。実行がエスカレーション済み状態に達する率を、各回にどの特定の回復試行が失敗したかで分類します。特定の同じ回復ステップで常にエスカレーションするグラフは、そのステップの定義されたプロトコルが調整を誤っていることを示しており、基礎となるタスクが一律に難しいわけではないことを示しています。これは、ループに停止条件トリガーを追跡することで得られるのと同じ診断値ですが、ここでは障害ポイントが不透明なトランスクリプト内の推測された瞬間ではなく、名前付きで検査可能な状態であるため、より詳細に利用できます。
最初のグラフを構築するときのよくある間違い
最初のグラフ構造化システムを構築する際に、人々が繰り返し直面するいくつかの特定の間違いがあります。それらを事前に知っておくことで、後で実際のデバッグ時間を節約できます。
計画を名目上のみ不変として扱う。 紙の上では計画をロックしながら、実行レイヤーが実際には静かにそこから逸脱することを許可すると、両方の世界の悪いところを引き継ぎます。実際の適応性も、実際の監査可能性もありません。なぜなら、トレースが、レビューするロックされた計画と一致しなくなるからです。
構築が速く感じられるという理由で、3 つのレイヤーを 1 つに再統合する。 実行レイヤーに回復も決定させ、コミットメント 2 の分離をスキップするという誘惑は、フレームワークの実際の目的を無効にします。計画、実行、回復が真に独立していない場合、あなたはグラフの語彙を身につけたループを構築したのであり、実際のグラフではありません。
プロトコルとは言えないほど曖昧な回復プロトコルを書く。 「適切な数の代替アプローチを試みる」は、厳格なエスカレーションプロトコルではなく、グラフエンジニアリングの言語を使用して説明されているだけで、無制限のループと同じ障害モードを持つソフトな指示です。実際のプロトコルは、試行の特定の数と、それぞれの特定の条件を指定します。
適合性の正直な評価をスキップする。 グラフエンジニアリングがより新しく、より厳密に聞こえるフレームワークであるという理由だけで、タスクが実際にトレードオフの恩恵を受けるからではなく、真にオープンエンドで探索的なタスクのためのグラフを構築すると、ループよりも構築が難しく、実際の仕事ではループよりも劣るシステムが生成されます。
証拠の正直な状態
このコースが冒頭で述べた注意点で締めくくります。なぜなら、それはほとんどの技術的な記事よりもここで重要だからです。上記で説明した 3 つのコミットメントは、実際の、注意深く推論された提案であり、ループが静かに失敗する場所を正確に特定するために 70 の実際のシステムに対して分析されました。著者自身の明確な声明によると、それらはまだ本番環境で大規模に約束された利益を提供することが検証されていません。
これはフレームワークを無価値にするものではありません。これは、実際に有望な設計であり、意図的に理解し実験し、理論的な議論が自動的に実践に変換されると想定するのではなく、自分の結果を正直に追跡する価値があります。このコースを使用してグラフ構造化システムを構築する場合、最も価値のあることは、それが対象とする特定の障害モード（無制限のリトライ、未検出の実行中の計画ドリフト、監査されていない回復決定）を実際に削減するかどうかを、実際の使用状況に対して測定することです。理論的に説得力があるからといって改善を想定するのではありません。
よく練られたフレームワークを、無批判に採用する確定した事実ではなく、テストする仮説として扱うというその規律自体が、このコースの根底にある実際のメタスキルです。グラフエンジニアリング、ループエンジニアリング、この急速に変化する分野における名前付きのプラクティスはすべて、名前と論文があるからといって純粋に採用するのではなく、適切に学び、自分の結果に対して正直にテストする価値があります。
実際の実装と結果が実際に現れ始めたら、このフレームワークの更新については、@cyrilXBT をフォローしてください。
