Anthropic は workflow と agent を分けて考える。あなたの読み方はどちらに近いか?
2024 年 12 月に Anthropic が発表した「Building Effective Agents」は、AI エージェントを作る人向けのガイドだ。冒頭で「workflow」と「agent」という 2 つの言葉を分け、そのあと、まず使える中で一番シンプルなやり方から始めること——場合によっては agentic なシステムをまったく作らないことさえ含めて——を勧め、それでは足りないときにだけ、整理された 5 つの workflow パターンのどれかに手を伸ばすよう提案する。そのパターンの 1 つでは、もう一回の LLM 呼び出しがレビュアーの席に座る。このノートはそのパターンについて、そして残りの 4 つがあなたに何を読ませることになるかについて書く。
ガイドが主張すること
Erik S. と Barry Zhang がこの記事を書いたのは、LLM でどうシステムを作るか決めようとしているエンジニア向けだ。まず、こういう定義から始まる。
“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.”
(Workflow とは、LLM とツールがあらかじめ決められたコードの経路にしたがってオーケストレーションされるシステムだ。一方 agent は、LLM が自分自身のプロセスとツールの使い方を動的に決め、タスクをどう成し遂げるかをみずから制御し続けるシステムだ。)
そのあと、彼らのアドバイスは控えめに始まる。
“When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.”
(LLM を使ってアプリケーションを作るとき、私たちはまず可能な限りシンプルな解決策を見つけ、必要なときだけ複雑さを増やしていくことを勧める。これは、agentic なシステムをまったく作らないことを意味する場合もある。)
より多くの構造が必要なとき向けに、彼らは 5 つの workflow パターンを説明している:prompt chaining(タスクを一連の呼び出しに分割し、ステップの間に任意でチェックを挟む)、routing(ルーティング)、parallelization(並列化)、orchestrator-workers(1 つの LLM がタスクを複数の部分に分け、複数の worker LLM に渡し、その結果をまとめる)、そして evaluator-optimizer。最後のこのパターンについて、原文はこう書いている。
“In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop.”
(evaluator-optimizer workflow では、1 回の LLM 呼び出しが応答を生成し、もう 1 回の呼び出しがループの中で評価とフィードバックを行う。)
Anthropic はこのガイドのなかで MarsDawn にはまったく触れておらず、どんな Markdown ツールも勧めていない。このガイドの透明性の原則と「チェックポイント」という言葉については、「Anthropic はエージェントに透明性を求めた。では誰がそれを読むのか?」がすでにくわしく扱っているので、このノートでは繰り返さない。人によるコードレビューについての一文も、本来の文脈(コーディングエージェントに特化した付録)とともに、あの記事で扱っている。
ここから先は、私たちの解釈であって、Anthropic の主張ではない
Anthropic は、workflow が終わったあと最終的な出力を誰がチェックするかについては書いていない。そもそもこの記事全体が文書についてのものではなく、作る人向けのアーキテクチャの決め方についてのものだ。とはいえ、この 5 つのパターンが、あなたに読ませることになるファイルの種類は同じではない。prompt chaining と routing は、たいてい目に見えない配管のようなもので、何かがあなたのところに届くとしても、それはこの連鎖の最後の呼び出しの出力にすぎず、ほかの単発の応答と変わらない。Orchestrator-workers は違う:あなたのコーディングエージェントが内部でこのパターンを使っているなら、フォルダに落ちてくるのは、複数の worker の呼び出しを orchestrator がつなぎ合わせて組み立てた 1 つの文書かもしれず、そのうち 1 つの worker の担当箇所にあるミスは、全体としてなめらかに読める要約のなかに埋もれて見逃されやすい。
Evaluator-optimizer は特に立ち止まる価値がある。もともと人間のレビュアーが座っていたかもしれない位置に、このガイドはもう一回の LLM 呼び出しを置いているからだ。これは一種のミスを安く捕まえる正当な方法ではあるが、結局はモデルが、与えられた基準にしたがって別のモデルをチェックしているにすぎない——このシリーズのほかの著者たちも、モデルが自分自身や別のモデルの成果を判定することについて、同じ懸念を口にしている。このガイドは、人が evaluator の判定をもう一度確かめるべきだとはどこにも書いておらず、そのこと自体について立場を取っていない。もしあなたがこの一連のプロセスの返してきたものを最後に読む立場なら、「ループが通した」ことと「私が確認した」ことは同じ文ではない——手元のファイルが両方の場合でまったく同じに見えたとしても。
MarsDawn が助けになるところ、ならないところ
MarsDawn は、あるファイルがどの workflow パターンから生まれたのかを知らないし、中に AI モデルもない——自前で evaluator のステップを走らせることもなければ、Anthropic が描いたその評価がきちんと仕事をしたかどうかを教えてくれることもない。MarsDawn がしているのは:サイドバー(「表示 ▸ サイドバーを表示」、⌃⌘S)のアウトラインタブが、orchestrator が組み立てた長いファイルの見出しを一覧にし、クリックするとそこへジャンプする。ソースとレンダリングされたページは並んで表示され(⌘2)、一緒にスクロールし、Mermaid の図や KaTeX の数式もソースのままではなく描画される。読んでいる途中でエージェントがファイルを書き換えても、MarsDawn は再読み込みしつつ、あなた自身に未保存の編集がなければ、読んでいた位置を保つ。「編集 ▸ 参照をコピー」(⌥⌘C)は、いまいる場所を docs/plan.md:42 の形でコピーし、そのままエージェントとのチャットに貼り付ければいい。
試してみる
MarsDawn は Mac App Store で配信中です。無料の marsdawn コマンドラインツールは今日から使えます:
brew install redtear1115/tap/marsdawn
アプリなしで Markdown を PDF に書き出せます。
コマンドライン · 購入前に:MarsDawn ができないこと
次に
- このガイドの透明性の原則とチェックポイントについての、より詳しい話:「Anthropic はエージェントに透明性を求めた。では誰がそれを読むのか?」
- エージェントの出力が一般になぜ読みにくいか:「エージェントが返してくるものを読む」
- シリーズに戻る:「編集者の読書ノート」
出典
- Erik S. と Barry Zhang、「Building Effective Agents」、Anthropic、2024 年 12 月 19 日:https://www.anthropic.com/engineering/building-effective-agents(2026-09-26 に取得・引用)