Anthropicのエンジニアが「2ヶ月間キーボードを使わずAIエージェントだけでコードを書き続けた」という話が話題になっている。ツールとプロンプトだけで構成されたシンプルなエージェントが、コードの生成からコミットまで自律的にこなした実例だ。
この記事でわかること：
- ワークフローとエージェントの違い
- エージェントを作るべきかどうかの判断基準
- Anthropicが現場から導き出した5つのワークフローパターン
- 本番エージェントを支える設計の3原則
- ツール設計で失敗しないためのポイント
ワークフローとエージェントの違いから始める
Anthropicは自社のエンジニアリングブログで、両者の違いを明確に定義している。ワークフローとは、LLMとツールが事前定義されたコードパス上で動作するシステムのこと。一方、エージェントはLLMがプロセスとツールの使い方を動的に決定し、タスクの達成方法をみずから制御するシステムを指す。
この違いは実装の方針に直結する。「とりあえずエージェントで」と飛びついてしまうと、コストと待機時間が上がるだけで成果が伴わないことがある。Anthropicは「できるだけシンプルな解決策を探し、必要なときだけ複雑さを加える」を基本方針としている。
エージェントを作るべきかどうかを判断する4つの問い
エージェントの開発に踏み切る前に、次の4点を確認するよう勧めている。
タスクの複雑性 — ディシジョンツリーをすべてあらかじめ書き出せるなら、エージェントより明示的なワークフローの方がコスト効率が高い。エージェントは「何をすべきかが曖昧な問題領域」で真価を発揮する。
タスクの価値 — エージェントの探索にはトークンコストがかかる。1タスクあたりの予算が数円程度の高スループットな処理なら、ワークフローの方が現実的だ。コストより結果を優先できるユースケースに向いている。
クリティカルな能力の有無 — コーディングエージェントなら「コードを書ける」「デバッグできる」「エラーから回復できる」の3点が前提になる。ボトルネックがあれば致命的にはならないが、コストと待機時間に直接響く。
エラーのコストと発見のしやすさ — エラーが重大で発見しにくいほど、エージェントに自律的に動かせる範囲は狭まる。読み取り専用アクセスやヒューマン・イン・ザ・ループを設けることでリスクを下げられるが、スケール能力とのトレードオフが生じる。
Anthropicが現場で見つけた5つのワークフローパターン
完全自律のエージェントを作る前に、まずこれらの組み合わせで多くのユースケースに対応できる。
プロンプトチェイニング
タスクを連続したステップに分解し、各LLM呼び出しが前の出力を受け取る形で進む。中間ステップにチェックを挟むことで、処理が正しい方向に進んでいるか確認できる。「精度を上げるためにレイテンシを払う」設計で、文書の下書き→条件チェック→本文執筆のような直線的なフローに向く。
ルーティング
入力を分類して適切な後続タスクに振り分ける。問い合わせの種類（返金依頼、技術サポート、一般質問）によって異なるプロンプトとツールセットにルーティングすることで、全体の品質を落とさずに特化できる。軽いタスクはClaude Haiku 4.5、難しいタスクはClaude Sonnet 4.5へ振り分けるコスト最適化にも応用できる。
並列化
LLMが同時並行でタスクをこなし、結果をプログラム的に集約する。セクショニング（独立したサブタスクを同時処理）と投票（同じタスクを複数回実行して信頼性を高める）の2形態がある。コードの脆弱性を複数の視点からレビューするなど、単一の呼び出しでは見落としが出やすい用途で有効だ。
オーケストレーター・ワーカー
中央のLLMがタスクを動的に分解し、ワーカーLLMに委任して結果をまとめる。並列化と構造は似ているが、サブタスクが事前に定義されていないのが本質的な違いだ。「どのファイルをどう変更するか」が入力によって変わるコーディングエージェントや、複数ソースを横断する情報収集タスクに向く。
エバリュエーター・オプティマイザー
1つのLLMが応答を生成し、別のLLMがフィードバックを与えるループを繰り返す。評価基準が明確で、反復改善に価値があるケースに効果的だ。文学翻訳や複数回の検索が必要な複雑なリサーチタスクに実績がある。
本番エージェントを支える設計の3原則
パターンを組み合わせて実装するときに、Anthropicが一貫して強調しているのが次の3点だ。
シンプルさを維持する — 環境・ツールセット・システムプロンプトの3要素で構成されたエージェントの基本形をまず完成させる。早期に複雑さを持ち込むと反復速度が落ちる。「複雑さを加えるのは、それが成果を明らかに改善するときだけ」が鉄則だ。
透明性を優先する — エージェントの計画ステップを明示的に出力させること。ブラックボックスにしてしまうと、予期しない挙動の原因を追いにくくなる。
エージェント・コンピューターインターフェース（ACI）を丁寧に設計する — ヒューマン・コンピューターインターフェース（HCI）と同じくらいの労力をACIの設計に注ぐべきだとAnthropicは言う。SWE-benchのエージェント開発では、全体のプロンプトよりもツール設計に多くの時間を費やした。
ツール設計で失敗しないためのポイント
ツールはエージェントの能力を直接左右する。設計時に意識すべき点を挙げる。
モデルが「思考する余地」を与えること。コードを書き始める前にトークンを使って考えられる形にする。パラメータ名や説明文は、ジュニアエンジニア向けのdocstringを書くくらい丁寧に仕上げる。似たツールが複数あるほど、各ツールの境界線を明確にする必要がある。
相対パスでの失敗は典型的な罠だ。Anthropicの実装でも、エージェントがrootディレクトリから移動した後に相対パスでミスが続いた。ツールの引数を絶対パス必須に変えただけで問題が解消した。「間違えにくくする設計」（ポカヨケ）を意識することで、本番での誤操作を減らせる。
ツールの挙動を理解させる別のアプローチとして、Claudeにシステムプロンプト全体を渡して「この指示に曖昧な点はあるか？」と問いかける方法がある。エージェントの視点からツールの不備を見つけるのに役立つ。
エージェントの視点に立つ
Barry Zhangは「エージェントの視点に立つ」練習を勧めている。コンピューターユースエージェントなら、静的なスクリーンショットと簡単な説明だけを受け取ってタスクをこなすことになる。ツールを実行している3〜5秒間、エージェントは結果が見えない。次の画面が表示されたとき、何が起きたかを初めて知る。
この「目を閉じて操作する」感覚を実際に体験することで、エージェントに何が必要かが見えてくる。画面解像度、推奨アクション、制約の明示。自分がエージェントなら何があれば動けるかを考えることが、システムプロンプトとツール設計を改善する最短経路だ。
今後の課題
Anthropicのエンジニアが「常に考えていること」として挙げているのが次の3点だ。予算認識の強化（コスト・レイテンシ・トークン量の観点でエージェントを制御する手段）、自己進化するツール（エージェントが自分のツールの使い勝手を自律的に改善できる仕組み）、そしてマルチエージェント協調の実用化（非同期通信や役割分担を前提とした設計パターンの確立）。
シングルエージェントが汎用化していくか、複数エージェントによる協調が主流になるかはまだ見えていない。いずれにしても「エージェントに与える自律性が高いほど有用になるが、コスト・レイテンシ・エラーのリスクも上がる」という原則は変わらない。設計の出発点は常に「本当にエージェントが必要か」という問いにある。