Agentic Workflows: 1 つの言葉が正反対の 2 つの設計を指す。違いはループを誰が持つか
Anthropic の分類と GitHub の製品では、この言葉が指す範囲が食い違っています。だからラベルを見ても設計については何もわかりません。判断基準は 1 つです。作業が終わったことを LLM 自身の申告ではなく外部のチェックで確認できるときに限り、LLM に舵を渡す、という基準です。
目次
GitHub の Agentic Workflows のドキュメントには、同じサイトのどの定義よりも設計について多くを語る一文があります。
Decisions cannot override retry limits, budgets, deadlines, or
nonrecoverable failures.同じサイトの定義は逆の方向を向いています。GitHub は Agentic Workflows を次のように説明しています。
Agentic workflows are AI-powered automation that can understand context,
make decisions, and take meaningful actionsそして、固定の if-then ルールで動く自動化と対比しています。これが一般的な意味、つまり「AI が決める」です。一方、Anthropic の「Building effective agents」は、ワークフローという言葉をほぼ正反対の意味で使っています。モデルが計画を決めない構成のことです。同じ言葉が正反対の 2 つの設計を指しているわけです。GitHub の製品をよく読むと、Anthropic ならエージェントと呼ぶものに、Anthropic が推奨にとどめている制限を既定でオンにしたものだとわかります。しかもモデルはその制限に逆らえません。
情報を運んでいるのはラベルではありません。誰かが agentic と呼ぶジョブについてチームが知るべきことは、もっと狭く機械的です。次のステップを決めるのは誰か。作業が終わったと決めるのは誰か。そして、作業が正しいかをモデル以外の何かが確かめているか。後の 2 つは別の問いで、混乱の多くはこれを 1 つの問いとして扱うところから生まれます。
Anthropic のいうワークフローとエージェント
Anthropic の 2024 年 12 月のエッセイは、両者を agentic systems という 1 つの傘の下に置き、その内側に線を引いています。
Workflows are systems where LLMs and tools are orchestrated through
predefined code paths. Agents, on the other hand, are systems where
LLMs dynamically direct their own processes and tool usage, maintaining
control over how they accomplish tasks.ざっと読むと「モデルが台本に従う」か「モデルが主導する」かの区別に見えます。ところが、ワークフローに分類されたパターンはこの読み方に合いません。プロンプトチェーン、ルーティング、並列化は予想どおりで、経路は固定され、モデルは各ステップを埋めるだけです。しかし orchestrator-workers もワークフローに入っていて、そこでは中心となるモデルがその場でタスクを分解し、ワーカーモデルに割り振り、戻ってきた結果をまとめます。サブタスクが何かを決めるのはモデルです。evaluator-optimizer もワークフローで、これはループです。ある呼び出しが生成し、別の呼び出しが評価し、それを繰り返します。
つまり、モデルが判断することは 2 つの山を分ける基準ではありません。orchestrator-workers ではモデルがサブタスクを選びますが、周りの役割(分解、委任、統合)はコードで固定されています。evaluator-optimizer では評価役の判定がもう 1 ラウンドを求めることがありますが、ループを書いたのはあなたで、ラウンド数に上限を付けられます。パターンがエージェントの山に入るかどうかを決めるのは、誰かが組んだ構造の空欄を埋めるのではなく、モデルがプロセスそのものを指揮しているかどうかです。作業の完了を誰が宣言してよいかは別の問いで、両方の山を横断します。
GitHub Agentic Workflows: 既定で上限付きの、Anthropic でいうエージェント
Anthropic の定義に従えば、GitHub Agentic Workflows (gh-aw) はエージェントです。YAML の frontmatter 付きの Markdown に自然言語で指示を書くと、gh aw compile がそれを通常の GitHub Actions のロックファイルに変換します。実行時にはエンジン(ドキュメントには GitHub Copilot、Claude Code、OpenAI Codex、Google Gemini、Pi が挙がっています)が指示を読み、ツールを使ってタスクを進めます。run の中では、何を読み次に何をするかをエージェントが決めます。
GitHub が付け加えたのは、Anthropic のエッセイが助言にとどめた部分です。エッセイは、制御を保つためにエージェントには最大反復回数のような停止条件を設けるのが一般的だと述べています。gh-aw ではこれが frontmatter の既定値です。エージェントのステップの timeout-minutes は既定で 20、max-turns は別の値を設定しない限り 1 回の run のモデル応答とツール呼び出しを 500 に制限し、AI Credits の予算も既定で有効です。エージェントのジョブはリポジトリに対して既定で読み取り専用の権限しか持たず、推奨される書き込み手段は宣言済みの safe outputs(Issue の作成、コメントの追加、プルリクエストの作成)で、適用前に検証されます。直接の書き込み権限もありますが、自分で選んで有効にする別の信頼境界です。冒頭の一文はこの文脈で読むものです。経路はモデルが持ち、その経路の長さ、触れてよい範囲、変更がサンドボックスを出るときの形はハーネスが持ちます。
これらの制限はどれも、run を終わらせるか、できることを狭めるものです。run が仕事を果たしたかどうかを示すものは 1 つもありません。タイムアウトは出口であって、判定ではありません。
Agentic Workflows の終わり方は 3 つ、チェックと呼べるのは 1 つだけ
正常に終わるループの終わり方は 3 つあります。コードパスが尽きる場合。パイプラインに 5 つの段階があり、5 番目が終わった、というものです。外部のチェックが通る場合。テストが通り、スキーマが検証され、レコードが元データと一致した、というものです。そして、モデルが「終わった」と言う場合です。(強制終了、つまりタイムアウト、予算切れ、キャンセルは 4 つ目の種類で、ログには成功ではなく未完了として残すべきです。)
作業についての証拠になるのは 2 つ目だけです。1 つ目はプログラムが終わったことを示すだけで、これは結局、終了コードの話です。以前にも書いたとおり、終了はプロセスが自分について書いた要約であって、判定ではありません。3 つ目は、モデルが自分の出力をどう見ているかを示すにすぎません。マルチエージェント構成では、これは実行されてもいない作業についてエージェントが成功を報告するというおなじみのケースで、設計段階で備えるべき協調の失敗の 1 つです。Claude Managed Agents のワークフローの run も、同サービスのドキュメントで同じことを示しています。スレッド上の作業が失敗していても、run は completed で終わることがあります。
つまり、ここには別々のダイヤルが 2 つあります。ループを誰が持つかで、ミスがどこまで大きくなりうるかが決まります。終わりを何がチェックするかで、そのミスに気づけるかが決まります。Anthropic が 2025 年 6 月に公開したマルチエージェントのリサーチシステムの記事は、1 つ目のダイヤルがうまくいかなかった例を示しています。初期のエージェントは単純なクエリに 50 個のサブエージェントを立ち上げ、十分な結果が得られた後も検索を続けました。これは行き過ぎで、上限とスケーリングのルールで対処できます。Anthropic はプロンプトに労力の目安を書き込んで直しました。予定どおりに止まったのに答えが間違っている run は、これとは別の失敗です。そちらは 1 つ目のダイヤルでは捕まえられません。
Anthropic のステップ数基準と、同じエッセイの付録にある基準
エージェントを選ぶべき場面について、エッセイの基準はこうです。
Agents can be used for open-ended problems where it's difficult or
impossible to predict the required number of steps, and where you
can't hardcode a fixed path.正しいのですが、決め手ではありません。ステップ数が予測できないのに、終わりをモデルに任せるべきではないタスクはたくさんあります。「完了」が判断であり、後工程で誰もそれを見直さないものはすべてそうです。
より良い基準は同じエッセイの、エージェントが実際に機能する領域を扱った付録にあります。コーディングエージェントが効果的な理由として、こう書かれています。
Code solutions are verifiable through automated tests; Agents can
iterate on solutions using test results as feedback; The problem space
is well-defined and structured; and Output quality can be measured
objectively.これはステップ数についての主張ではありません。モデル以外の何かが終わりを確認できる、という主張です。付録は扱う 2 つの領域のどちらについても同じことを言っていて、役に立つ領域には明確な成功基準があるとしています。それでも Anthropic は、テストはテストした範囲しかカバーしないので、解決策がより広い要件に合っているかについては人間のレビューが引き続き重要だと付け加えています。その範囲内であれば、コーディングエージェントが 3 ターンで終わっても 40 ターンかかっても、ループを渡すのは妥当です。ただし付録が明言していない条件が 1 つあります。テストがエージェントの書き込み範囲の外にあることです。自分を採点するテストを編集できるエージェントは、また自分で自分をチェックしているだけです。そしてチェックが拘束できるのは自分がカバーする経路だけで、これはどのハーネスのゲートにもある同じ限界です。gh-aw の読み取り専用の権限と safe outputs が実現しているのは、まさにこの「テストを書き込み範囲の外に置く」ことです。エージェントは変更を提案できますが、自分を評価するものをこっそり書き換えることはできません。
では、2 つ目のモデルを判定役にする場合、つまり evaluator-optimizer の評価役はどうでしょうか。外部のチェックとしてどこまで数えられるかは、ワーカーとどれだけ違う失敗の仕方をするかで決まります。別のモデル、別のコンテキスト、自分で推測した基準ではなく渡された基準が条件です。ワーカーのコピーがワーカーを採点しても、同じ盲点を共有し、情報ではなく自信を足すだけです。
本番の Agentic Workflows: 終わりをチェックできない限り、ループはコードに置く
ここから、誰かが agentic と呼ぶジョブに対する私の既定の考え方が出てきます。これは、ループを渡すのがいつ正当化できるかについての好みであって、いつ必要かについての主張ではありません。チェック可能で経路がわかっているタスクなら、普通のスクリプトでもかまいません。
モデルの外にあり、モデルが書き込めない何か(テスト、バリデータ、信頼できる元データとの突き合わせ、出力を実際に読むゲート担当の人間)が作業の完了をチェックできるなら、モデルにループを持たせてかまいません。出口はモデルの申告ではなくそのチェックに結び付け、gh-aw と同じように外枠をコードで決めます。期限、ターン数の上限、予算、狭い書き込み経路です。上限はコストを抑えます。正常な終了に意味を持たせるのはチェックです。
モデルの外に終わりをチェックできるものがないなら、ループはコードに置きます。状態と遷移をテストできるプログラムとして書き、リトライと上限を付け、その中の判断のポイントでモデルを呼びます。このチケットを分類する、これらのフィールドを抽出する、この返信の下書きを作る、この 2 つのレコードが同じものかを判定する、といった具合です。それで結果が検証されるわけではありません。下書きした返信は未チェックのままです。得られるのは上限です。コードのループの中では、モデルは 1 つのステップの中で間違えることはあっても、ステップを飛ばすことも、10 個追加することも、ジョブの終了を宣言することもできません。だからエラーは 1 回の呼び出しの大きさにとどまり、それが起きた場所にはログ上の名前があります。
この区別をぼやかすのが、モデルが計画を書き、コードがそれを実行するケースです。Claude Managed Agents の dynamic workflows はこの方式で、エージェントがファンアウトをプログラムとして書き、サーバーがそれを実行します。コードのループに見えますが、「尽きる」コードパスはモデルが書いたものなので、1 つ目の終わり方がいつの間にか 3 つ目になっています。そこで自分で設定できる外枠はセッションの予算だけで、それはセッション作成時、つまり計画が存在する前に付けられます。
ここまでの話は、「agentic」という言葉の定義が決まっていなくても成り立ちます。誰かに Agentic Workflows を求められたら、役に立つ返答は、特定の 1 つのジョブについての 2 つの問いです。夜中にこれが動き、モデルが「終わった」と言ったとき、それを何がチェックするのか。何もチェックしないなら、何がそれを止めるのか。
01 / ディスカッション
コメント欄はありません。議論は X で行っています。
02 / ほかの記事
Anthropic の always-on エージェントガイド: ワーカーが死んだとき inbox、タイマー、outbox は何をするのか、SQLite で検証
ガイドが触れていない障害処理の大半は、1 つの手に行き着きます。すべての起動を inbox イベントにし、データベースが 2 度目の保存を拒むキーを付けることです。リトライされた Webhook、タイマーの再実行、承認の回答とその期限切れは、どれもこの 1 つの制約で扱えます。リース、リトライ、outbox にはもう少し手が要ります。
MCP サーバーの作り方 2026 年版: TypeScript のファクトリー 1 つで両方のプロトコル世代に対応し、SDK の HTTP ハンドラーが開発者に残す部分
ファクトリー 1 つで、両方のトランスポートと両方の世代のクライアントに対応できます。テスト実行では、SDK のハンドラーは偽造した Origin に 200 で応答し、クライアントがキャッシュの基準にできる鮮度の期間も返しませんでした。Inspector は、新しいハンドシェイクを指定するまで古いハンドシェイクしか確認しませんでした。追加すべき 2 つのガード、設定すべきキャッシュヒント、そして最初のサーバーで省いてよいものを説明します。
セルフホスト版 Claude Managed Agents: サーバーは自分のものになり、何も報告しない失敗も自分のものになる
セルフホストにすると、トランスクリプトの管理は自分の手に移り、運用も一緒についてきます。Anthropic の差分リストには、作業が止まっている、捨てられている、あるいは別のモデルが答えているのに、サーバーが成功を返すか何も返さないケースが並んでいます。そのリストの各行こそが、デプロイの受け入れテストです。