Building Effective Agentsを読み直す — WorkflowとAgentの5+1パターン

元記事に付いた注記と、いま読む価値

2024年12月19日に公開された「Building Effective Agents」は、AnthropicのErik S.とBarry Zhangが書いたエージェント設計の入門記事です。数十のチームと協力した経験から、成功した実装は複雑なフレームワークではなく、単純で組み合わせやすいパターンで作られていたと報告しています。

注意したいのは、元記事の冒頭に注記が加わっている点です。「記事で述べたツール環境の多くは2024年12月以降に変わった」とあり、現在のやり方としてClaude Managed Agentsの構築記事とドキュメントへの案内が付いています。個別のツールや製品の記述は古くなりうる一方、読み直す価値が残るのは設計の考え方のほうです。

具体的には、「ワークフロー」と「エージェント」の境界、5つのワークフローパターン、ツール設計の作法の3点です。Claude Codeのように、エージェントを日常的に使う環境が普及したいまは、自分の使うツールを構成要素の言葉で読み解く物差しにもなります。

WorkflowとAgentを混同しないための定義

元記事は、どちらも含めて「エージェント的システム」と呼び、そのうえで設計上の区別を置いています。

定義の裏には「単純な解から始める」という姿勢があります。元記事は、エージェント的なシステムは性能と引き換えに遅延とコストを差し出す構成になりやすく、多くの用途では、単発のLLM呼び出しに検索(retrieval)と文脈内の例(in-context examples)を足すだけで足りると述べています。そもそもエージェント的システムを作らない、という選択肢まで含めて検討するわけです。

フレームワークとの距離の取り方

元記事は、実装を楽にするものとして次の4つを挙げています。

• Claude Agent SDK
• AWSのStrands Agents SDK
• Rivet(ドラッグ&ドロップで組むGUIのワークフロー構築ツール)
• Vellum(複雑なワークフローを組んで試すGUIツール)

LLMの呼び出し、ツール定義の解析、呼び出しの連結といった低レベルの作業が楽になる反面、抽象化の層が増えてプロンプトと応答が見えにくくなり、デバッグしづらくなります。単純な構成で足りる場面で複雑さを足したくなる点も、弱点として挙げられています。

勧めているのは、まずLLMのAPIを直接使うことです。多くのパターンは数行のコードで書けるうえ、フレームワークを使う場合も中身のコードを理解したうえで使うよう求めています。「内部で何が起きているかの思い違い」が、顧客のよくある失敗の原因だと書かれています。

基本要素になる「拡張されたLLM」

ワークフローもエージェントも、土台にあるのは検索・ツール・メモリーで強化したLLM(augmented LLM)です。元記事の時点でも、モデルは自分で検索クエリを作り、使うツールを選び、何を覚えておくかを決められるとされています。

実装で意識する点は2つです。用途に合わせて機能を作り込むことと、LLMにとって使いやすく文書化されたインターフェースにすることです。接続の一例として、当時公開されたばかりのMCP(Model Context Protocol)が挙がっています。

文脈の持たせ方はAnthropic Context Engineering論が詳しく、取り出しの精度そのものはContextual Retrievalの前処理で上げられます。以降のパターンは、どの呼び出しもこの拡張された能力を持つ前提で読みます。

5つのワークフローパターンを状況から選ぶ

5つのパターンは、課題の形から逆引きできます。左の列から自分の状況に近いものを探してください。

プロンプトチェイニング

複数のLLM呼び出しを順につなぎ、各呼び出しが前の出力を処理します。途中にプログラムによる検査(gate)を挟み、道筋から外れていないかを確かめられます。

入力 → LLM① → [gate] → LLM② → [gate] → LLM③ → 出力

狙いは、各呼び出しを易しい課題にして、遅延と引き換えに精度を上げることです。元記事の例は、マーケティング文を作ってから別の言語に翻訳する流れと、文書の骨子を作り、基準を満たすか検査してから本文を書く流れです。

ルーティング

入力を分類し、専門化した後続の処理へ振り分けます。1種類の入力に合わせて最適化すると他の入力の性能が落ちる問題を、関心の分離で避けられます。

入力 → 分類 ┬→ 一般質問の処理
            ├→ 返金依頼の処理
            └→ 技術サポートの処理

分類は、LLMでも従来の分類モデルやアルゴリズムでも構いませんが、正確にできることが前提です。もう1つの使い道がコストの調整で、元記事は易しくよくある質問をClaude Haiku 4.5のような小さなモデルへ、難しく珍しい質問をClaude Sonnet 4.5のような高性能なモデルへ送る例を挙げています。

並列化

LLMが同時に作業し、出力をプログラムで集約します。変種は2つあります。

• Sectioning: 課題を独立した部分に分け、並行して処理する
• Voting: 同じ課題を複数回走らせ、多様な出力を得る

課題 ┬→ LLM-A ┐
     ├→ LLM-B ┼→ 集約 → 結果
     └→ LLM-C ┘

観点が複数ある課題では、観点ごとに別の呼び出しへ任せるほうが、LLMが各側面に集中できて性能が上がりやすいと説明されています。Sectioningの例は、ユーザーの質問に答える呼び出しと、不適切な依頼を検査する呼び出しを別にするガードレール、そして観点ごとに評価を分ける自動評価です。

Votingの例は、複数のプロンプトでコードの脆弱性を見つけて、1つでも指摘したら旗を立てる使い方です。投票の閾値を変えれば、誤検出と見逃しのバランスも調整できます。

Claude Codeでの並列実行の具体例は、サブエージェント並列パターンにあります。

オーケストレーター・ワーカー

中央のLLMが課題を動的に分解してワーカーLLMに委ね、結果を統合します。形は並列化に似ていますが、決定的な違いは柔軟性です。サブタスクが事前に決まっておらず、入力に応じて統括役が決めます。

統括LLM ─ 分解 ┬→ ワーカー1 ┐
               ├→ ワーカー2 ┼→ 統括LLM(統合)
               └→ ワーカー3 ┘

元記事が挙げる適用先は、毎回複数のファイルに複雑な変更を加えるコーディング製品と、複数の情報源を集めて分析する検索課題です。変更すべきファイルの数や中身が課題しだいで変わるので、事前に分解できません。この型をClaude Researchに適用した設計は、マルチエージェント研究システムにあります。

評価者・最適化者

1つのLLMが応答を生成し、別のLLMが評価とフィードバックを返す、というループです。向いているかどうかの目安は2つあります。人間が指摘すると応答が目に見えて良くなること、LLMにも同じ種類の指摘ができることです。人間の書き手が推敲を重ねる過程に近いと説明されています。

生成LLM → 応答 → 評価LLM ┬→ 合格 → 出力
                          └→ 指摘 → 生成LLMへ戻る

元記事の例は、翻訳者LLMが最初は拾えないニュアンスを評価者LLMが指摘する文学翻訳と、追加の検索が要るかを評価者が決める複雑な検索です。

エージェントは「ループと環境のフィードバック」で動く

エージェントは、人間からの指示か対話で始まり、課題が明確になったら自律的に計画と実行を進めます。必要なら途中で人間へ情報や判断を求めます。

実装自体は単純で、LLMが環境のフィードバックを受けながらツールを使うループにすぎません。だからこそ、ツール群とその文書を明確に練ることが重要だとされています。向く課題は、必要なステップ数が予測しづらく、固定の経路を書き込めないオープンエンドな問題です。多くのターンを動くことになるため、LLMの判断にある程度の信頼が要ります。

トレードオフも明記されています。自律性は高いコストとエラーの累積につながるので、サンドボックス環境での十分なテストと、適切なガードレールが勧められています。元記事自身の例は、説明文だけからSWE-benchの課題を解くコーディングエージェントと、Claudeがコンピューターを操作して課題を進めるcomputer useの参照実装です。

ツール設計はエージェントの使い心地を決める

元記事のAppendix 2では、ツールの定義を、全体のプロンプトと同じ注意を払って設計するよう求めています。理由は、同じ操作でも指定の仕方が複数あり、LLMにとって書きやすさが大きく違うからです。

差分(diff)で書くにはチャンクヘッダーに変更行数を先に書く必要があり、コードをJSONに入れるにはMarkdownより改行や引用符のエスケープが増えます。人間のソフトウェア開発では見た目の違いにすぎないこうした差が、LLMには難しさの差になります。

人間向けのインターフェース(HCI)に注ぐのと同じだけの労力を、エージェント向けのインターフェース(ACI、Agent-Computer Interface)にも注ぐ、というのが元記事の経験則です。具体的には次のとおりです。

• モデルの立場に立つ。説明とパラメータだけで使い方が明らかかを見る。良い定義には、使用例・エッジケース・入力形式の要件・他のツールとの明確な境界が含まれる
• パラメータ名や説明を、新人開発者に渡す優れたdocstringのつもりで見直す。似たツールが多いときは特に重要になる
• ワークベンチで多数の入力例を試し、モデルの間違い方を見て直す
• poka-yoke(ポカヨケ)。引数の設計を変え、間違えにくくする

実例として、SWE-bench用のエージェントを作った際は、全体のプロンプトよりツールの最適化に多くの時間を割いたと書かれています。エージェントがルートディレクトリを離れた後で、相対パスを使うツールがミスを起こしたため、常に絶対パスを要求する形に変えたところ、モデルはこの方法を完璧に使ったそうです。

この「間違えにくくする」発想は、ツール定義に落とすと次のように書けます。名前・説明・入力スキーマはClaude APIのツール定義の項目で、例のツールは説明用に作ったものです。

{
  "name": "read_file",
  "description": "ファイルの内容を返す。pathは必ず絶対パスで指定する(/で始まる)。相対パスは受け付けない。ディレクトリの一覧には使わない(list_dirを使う)。",
  "input_schema": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "読み込むファイルの絶対パス。例: /workspace/src/main.py"
      }
    },
    "required": ["path"]
  }
}

説明文に「絶対パスだけ」「他のツールとの境目」を書き込んでいる点が、元記事の「使用例・入力形式・他ツールとの境界」に対応します。

ツール定義の書き方はエージェント向けツールの書き方で掘り下げられています。ツール設計の関連記事としては、Code execution with MCPやAgent Skills実践もあります。

実践の2領域 — どんな仕事がエージェントに向くか

元記事のAppendix 1は、エージェントが特に価値を出す領域として、カスタマーサポートとコーディングを挙げています。共通する条件は4つで、会話と行動の両方が要ること、成功の基準が明確なこと、フィードバックのループが作れること、人間の監督を意味のある形で組み込めることです。

カスタマーサポートは、おなじみのチャットの形に、ツール連携で機能を足したものです。会話の流れに沿いつつ、顧客データ・注文履歴・ナレッジベースの記事を引き、返金やチケット更新のような操作もプログラムで処理できます。成功はユーザーが定義する「解決」で測れ、解決した分だけ課金する従量制を取る企業もあると書かれています。

コーディングは、コードの正しさをテストで検証でき、テスト結果をフィードバックに反復でき、問題の空間が構造化されていて、出力の質を客観的に測れる点で、エージェントと相性が良い領域です。実装の面では、SWE-bench Verifiedの実際のGitHub課題を、プルリクエストの説明だけから解けるようになったと書かれています。

ただしテストで機能は検証できても、システム全体の要件に合うかどうかは人間のレビューが欠かせないとも述べています。

Claude Codeはこの枠組みでどう読めるか

Claude Codeのドキュメントは、課題に取り組む流れを「コンテキストの収集」「行動」「結果の検証」の3つの段階からなるagentic loopと説明しています。段階は混ざり合い、ツールは全体を通じて使われます。コードベースへの質問ならコンテキスト収集だけで済み、バグ修正なら3つの段階を何度も回ります。

次の一手は前のステップで得た情報から決める、とあるので、元記事の「ループと環境のフィードバック」の定義にそのまま当てはまります。

委譲の面でも対応が見られます。サブエージェントは自分のコンテキストウィンドウで動き、ツール呼び出しは親の文脈に入らず、終わると要約が返ります。親が分解して任せ、結果だけを受け取る形は、オーケストレーター・ワーカーに近い構造です。ただしこれはドキュメントの記述を元記事の語彙で読み替えたもので、Anthropicがそう分類しているわけではありません。

使い方はサブエージェントガイドに、複数セッションを並べる構成はClaude Codeマルチセッションにあります。

もう1つ、ドキュメントが示す構図が、モデルとツールの関係です。エージェントのループを動かすのは推論するモデルと行動するツールで、Claude Codeは、ツールを供給しモデルが見る文脈を管理する外側の層だと説明されています。この外側の層をagentic harnessと呼んでいます。元記事が「ツールと文書を練る」ことに重点を置いた理由が、この分担からも見えてきます。

元記事から現在までに変わったこと

元記事が参照先に挙げたClaude Managed Agentsは、いまではドキュメントのある製品として存在します。概要ページではベータ版とされ、長時間動くタスクや非同期の作業向けの、Anthropicの管理する基盤上で動く構成済みのエージェントハーネスと説明されています。元記事の注記は、現在の方法としてこの製品の構築記事とドキュメントへ案内しています。フレームワークの組み合わせではなく、Anthropicが運用する基盤の側から入る道が示されているわけです。製品の全体像はManaged Agentsにあります。

長時間動くエージェントの実装論は、Harness Designが扱っています。元記事がサンドボックスでの十分なテストとガードレールを勧めた背景にある、自律性とコストの問題は、長時間の運用で一段と重くなります。

現在の元記事でも、中心的な主張は同じです。単純なパターンから始め、測定して反復し、結果が確かに良くなるときだけ複雑さを足すという筋です。

まとめ

元記事の3原則は、設計をシンプルに保つこと、計画の段階を明示して透明性を優先すること、ツールの文書化とテストでACIを作り込むことです。迷ったら、単発の呼び出しで足りるかを最初に確かめ、足りないときだけ、課題の形に合うパターンを1つ足してください。