AIエージェント構築、最初の一手は「作らない」判断｜Anthropic公式に学ぶ

AIエージェント構築とは、記憶・検索・ツールを持つ LLM (大規模言語モデル) を組み合わせて、業務の判断や作業を自動化する仕組みを作ることだ。しかし、最初にやるべきは、それを「作らない」と決めることかもしれない。

Anthropicのエンジニア、Erik Schluntz と Barry Zhang がまとめた指針「Building Effective Agents」の核心は、拍子抜けするほど素朴だ。Anthropic公式は、最もシンプルな解決策を見つけ、複雑にするのは性能向上が確認できたときだけにすべきだと述べている。彼らは実務経験から、多くの用途では検索や例示を足した 1 回の LLM 呼び出しで足りると断言している。

つまり、あなたが「AIエージェントを作りたい」と思ったタスクの多くは、そもそもエージェントを必要としていない可能性が高い。ここを見誤ると、覚えなくてよかったフレームワークの学習に時間を費やし、払わなくてよかった API コストを支払うことになる。

片づけたいのは仕事であって、複雑な仕組みではない。

その出発点になるのが Augmented LLM（拡張 LLM）だ。記憶・検索・ツールという 3 つの機能を持つ単一の LLM である。難しく聞こえるが、やることは単純だ。モデルに「必要な資料を探させる」「過去のやり取りを覚えさせる」「外部のツールを呼ばせる」だけだ。返金対応の問い合わせ返信、書類の下書き、社内文書からの回答生成——この規模の仕事なら、ここで完結することが多い。

では、いつ本格的なエージェントが必要になるのか。判断軸は 2 つだ。何ができて、何ができないかで整理すると次のようになる。

表が示すのは、エージェント化が「性能を上げる代わりに、レイテンシー (応答までの遅延) とコストを差し出す取引」である。自律的に動くエージェントは、予測しにくい多段のタスクにこそ効果的だが、その分、誤りが次のステップへ複利で積み上がり、非エンジニアには原因の特定が難しくなる。

そのため、公式はフレームワークを先に入れることを勧めない。むしろ「まず API を直接使って試し、フレームワークを使うなら内部動作を理解してから」と釘を刺す。抽象化は便利だが、内部が見えなくなり、つまずいたときの診断が難しくなるからだ。

この記事が相手にするのは、Python の設計パターンもフレームワークの選定基準も知らない業務担当者と開発初学者である。だから順番はこうなる。まずシンプルに始める。1 回の LLM 呼び出しで届かない範囲を見極める。そこで初めて、手順をコードで固定する「ワークフロー」と、手順を LLM に委ねる「エージェント」の分かれ道に立つ。

では、その「ワークフロー」と「エージェント」は具体的に何が違うのか。次で切り分ける。

「シンプルに始めて必要なときだけ複雑にする」という公式指針に沿って、問い合わせメールを分類し、種類ごとに一次回答の下書きを作るまでを組み立てます。いきなり自律エージェントを目指さず、Routing（振り分け）と Prompt Chaining（段階処理）という2つの基本ワークフローを組み合わせるのがこの例のねらいです。最後の送信だけは人間が承認する形にして、リスクを抑えます。

**手順1: まず1通を「そのまま」Claude に渡して土台を確認する**

いきなりワークフローを組まず、Augmented LLM（普通のClaudeに情報を持たせた基本形）で1通処理できるか確かめます。過去メール本文を貼り付けて分類だけ頼みます。

次の問い合わせメールを読んで「返金」「技術サポート」「一般問い合わせ」のどれか1つに分類してください。判断理由も1行で添えてください。
---
(ここにメール本文を貼り付け)

分類結果と理由が1つ返ります。ここで大きく外すようなら、分類の定義文（何を返金扱いにするか等）を先に固める必要があります。

**手順2: Routing パターンで「分類→専門フローへ振り分け」を明文化する**

公式の Routing パターンは、入力をまず分類してから専門タスクへ送る考え方です。分類の基準を箇条書きで固定し、迷ったときの既定の逃げ道も決めておきます。

あなたは問い合わせの振り分け係です。以下の基準で1つに分類してください。
- 返金: 返金・キャンセル・請求金額の相談
- 技術サポート: 動かない・エラー・使い方の質問
- 一般問い合わせ: 上記に当てはまらないもの
判断に迷う場合は「一般問い合わせ」にしてください。
出力は分類名のみ。

分類名が1語で返ります。「迷ったら一般」と決めておくと、無理に断定して誤送信するのを防げます。

**手順3: 種類ごとに Prompt Chaining で「下書き→自己チェック」の2段階にする**

回答ドラフトは一度に完成させず、公式の Prompt Chaining（段階を踏ませる）で品質を安定させます。まず下書きを作らせます。

これは「技術サポート」に分類された問い合わせです。
次の方針で一次回答の下書きを作ってください。
- 確認できていない事実は書かない
- 不明点は相手に質問する形で残す
- 署名や送信はしない（下書きのみ）
---
(メール本文)

下書きが1本返ります。この時点では送らず、次のチェックに回します。

**手順4: 同じ連鎖の中で下書きを点検させる**

生成した下書きをそのまま次のプロンプトに渡し、問題がないか点検させます。段階を分けることで「作る役」と「見直す役」を切り離せます。

次の一次回答ドラフトを点検してください。
- 事実と断定できない記述が混ざっていないか
- 相手を不快にさせる表現がないか
- 金額・日付など未確認の情報を勝手に書いていないか
問題があれば指摘し、修正版のドラフトを出してください。
---
(手順3のドラフト)

指摘リストと修正版ドラフトが返ります。一度に「完璧な回答を書いて」と頼むより、見落としが減ります。

**手順5: 送信の直前だけ人間が承認する（Human-in-the-loop）**

公式指針では、取り消せない操作の直前に人間の承認を置くことを勧めています。メール送信は取り消しにくい操作なので、ここは自動化しません。Claude には「下書きまで」を担当させ、担当者が内容を読んでから自分の手で送信します。

この区切りを守ると、分類ミスや不適切な文面がそのまま外部に出る事故を防げます。まずはこの範囲だけを回し、精度が安定してから並列チェックなど複雑なパターンを足すかどうか検討すれば十分です。

境目は一行で引ける。手順を決めるのがコードなら、それはワークフローだ。手順を決めるのが LLM なら、それはエージェントとなる。AI エージェント構築を検討する際、まずこの線引きを押さえておきたい。

前回、1回の呼び出しで届かない仕事の見極めまで来た。次はその先の分かれ道だ。同じ「LLMを組み合わせる」でも、指揮者が誰かで設計はまるで変わる。ワークフローとエージェントの違いは、機能の優劣ではなく、手順を紙に書けるかどうかで決まる。

返金対応を例に取ろう。「金額を確認する→規約を照合する→承認可否を判定する→返信文を作る」。この順番を毎回そのまま踏めるなら、経路はコードに固定できる。LLM は各ステップの中身 (文章生成や判定) だけを担い、どこへ進むかは人間が書いた手順が決める。これがワークフローだ。予測しやすく、同じ入力なら同じ道を通る。

対してエージェントは、順番そのものを LLM に委ねる。GitHub に上がった不具合報告の対応を想像してほしい。どのファイルを読むか、何を直すか、テストを走らせるか——サブタスクは事前に書き出せない。届いた報告を読んでから、その場で計画を立てる。だからエージェントは柔軟だが、途中の判断がずれると、その誤りが次のステップに複利で積み上がる。

Anthropic の指針が、いきなりエージェントに飛びつくなと繰り返すのはここだ。手順を紙に書けるなら、まずワークフローを選ぶ。AI エージェント構築のワークフローには、Anthropic 公式が示す業務によく効く 5 つの型がある。仕様の名前より、それで何が済むかで並べる。

選び方はこう考える。作業を「決まった段取り」に分解できるなら上の 3 つのどれか、分解できず現場を見てから決める作業なら Orchestrator-Workers、正解が一発で出ず反復が要る作業なら Evaluator-Optimizer が近い。

もう少し噛み砕く。Prompt Chaining は一度に全部を頼まず工程を割る型で、レポート作成や書類レビューのように「まとめて頼むと雑になる」仕事の品質を安定させる。Routing はまず入力を分類し、専門フローへ送る型だ。問い合わせを返金・技術・一般に仕分けてから答えると、ひとつのプロンプトで全部さばくより精度が上がる。

Parallelization は同じ対象を複数の視点で同時に走らせる。ひとつの文書を法務・セキュリティ・ブランドの 3 方向からレビューし、結果を突き合わせる「投票」で結論の信頼性を高める使い方が分かりやすい。ここまでの 4 つは、経路が最初から見えている。手順を書き出せた時点で、あなたはもうエージェントを避けられている。

手順を紙に書けたなら、それはエージェントではなくワークフローの仕事だ。

残る 2 つは、経路が動く。Orchestrator-Workers は親の LLM がサブタスクをその場で作り、複数の子に割り振る。これは不具合対応のように、開けてみるまで何をすべきか分からない作業向きだ。Evaluator-Optimizer は生成役と採点役をループさせ、基準を満たすまで書き直させる。マーケコピーの磨き込みが典型で、「もう一声」を自動で繰り返す。

注意したいのは、この 5 つを覚えることが目的ではない点だ。どれも Augmented LLM (ツールや検索を外付けして拡張した LLM) を積み木のように組んだだけで、巨大な専用フレームワークは要らない。手元の仕事をひとつ思い浮かべ、段取りを声に出してみる。すらすら言えたらワークフローだ。言葉に詰まって「やってみないと分からない」なら、そこで初めてエージェントの検討に入る。

型は決まった。しかし、非エンジニアがいざ AI エージェント構築に取り組み始めると、同じ場所で足が止まる。次は、そのつまずきの外し方を扱う。

足が止まる場所は、だいたい決まっている。AIエージェント構築でつまずくポイントを順に外していく。

まず、フレームワークを先に入れて詰まるケースだ。「有名なライブラリを入れておけば安心だろう」と最初にインストールするが、いざ動かない場面で、自分のコードのどこが悪いのか、ライブラリの内部が悪いのか切り分けられなくなる。抽象化の層が厚いほど、中で何が起きているかが見えないからだ。回避策は公式が明言している。まず API (アプリ同士が機能をやり取りする窓口) を直接呼んで動かし、フレームワークを使うなら内部動作を理解してから使用することだ。遠回りに見えて、これが一番早い。

次に、自律ステップをまたぐエラーについて。多段のタスクで途中の判断がひとつずれると、その誤りが後続に積み上がり、最後まで走らせてから「なぜこうなった」と原因を探すことになる。AIエージェント (自律的にタスクをこなす AI プログラム) の失敗が厄介なのは、失敗の場所が一点ではなく連鎖として広がる点にある。だから長く走らせる前に、各ステップで環境の実データを取り、進捗を確認する。そして、暴走を防ぐための停止条件——最大の実行回数などを先に決めておく。ここを決めておけば、間違ってもコストと時間が青天井にはならない。

三つ目は、ツールの過剰設計だ。「あれもこれもできたほうがいい」と機能を盛ると、モデルはどのツールを使えばいいか迷い、かえって非効率な手を選ぶ。Anthropicのツール設計に関する記事でも、似た機能や重複したツールがモデルの判断を鈍らせると指摘されている。回避策は引き算だ。そのタスクに本当に要るツールだけを渡す。名前と説明を、人間が読んで一発で用途が分かる粒度にする。ツールが少ないほど、モデルの選択は素直になる。

機能を足すほど賢くなるのではない。要るものだけ渡したとき、選択は素直になる。

四つ目は、並列化のコストに関することだ。同じ対象を複数の視点で同時に走らせると精度は上がるが、その分トークン消費も API 料金も、待ち時間も、単発の呼び出しより大きく膨らむ。速さのつもりで並列化したのに、支払いが増えていたという落とし穴がある。回避策は目的で使い分けることだ。結論の信頼性が欲しい重要な判断だけ並列にし、日常の処理は単発で回す。並列化は「常時オン」ではなく「ここぞ」で使う道具だと考えておく。

五つ目が、非エンジニアには最難関の設計判断——Human-in-the-loop (要所で人間が承認する仕組み)、人間の承認ポイントをどこに置くかだ。取り消せない操作、たとえば送信・削除・支払いの直前に人間の確認を挟むほど安全になる。しかし、挟みすぎれば自動化の意味が薄れ、少なすぎれば事故が起きる。ここに万能の正解はない。目安として、「間違えても取り消せる操作」は任せ、「取り消せない操作」の手前に一枚だけ承認を置く。この線引きだけ守れば、安全と手間のバランスは大きく崩れない。

最後に、モノリシック設計についてだ。「何でもこなす巨大なエージェントを1つ」作ろうとする発想は、高い確率で失敗する。役割が渾然一体だと、どこが悪いか分からず、直すたびに全体が揺れる。公式が勧めるのは逆で、機能を分割した小さなエージェントの組み合わせ——Minimal footprint (最小限の権限だけを与える設計思想)、必要最小限の権限と、取り消せる操作を優先する設計だ。ひとつの部品が担う仕事を小さく保てば、壊れた場所も、直す場所も、はっきりする。

六つを貫くのは、ひとつの姿勢だ。安全側に倒すこと、見えるところで動かすこと、最小から始めることだ。これは臆病さではなく、遠回りを避けるための近道である。AIエージェント構築の落とし穴を先に知っていれば、同じ穴を二度は踏まない。ここまでの回避策を手に、次は自分の業務のどこに当てはめるかを具体的に広げていく。

明日、自分の担当業務のどれに当てはめるかを考える。ここまで整理した型を、実際の3つの仕事に適用し、AIエージェント構築の勘所を掴んでみる。

問い合わせ対応から始める。返金・技術・一般が混ざって届く窓口を、ひとつのプロンプトで処理しようとすると、どの種類にも中途半端な答えが返る。このため、Routing (入力を種類ごとに振り分ける手法) を活用する。まず入力を種類ごとに分類し、それぞれの専門フローへ送ってから回答を得る。返金には返金の、技術には技術の言葉を持つ担当を割り当てる感覚だ。仕分けの一手間を先に置くだけで、種類ごとの回答が噛み合い、ブレが減る。

書類レビューは別の型が適している。契約書やリリース文を1回の呼び出しで「全部チェックして」と頼むと、視点が混ざり見落としが出る。そこで Parallelization の Voting (複数の判定を突き合わせ多数決で決める方式) を使う。法務・セキュリティ・ブランドの3方向から同じ文書を同時にレビューさせ、結果を突き合わせて多数決で結論を出す。ひとりの目で通すより、独立した複数の目で見て票を数えるほうが、見落としの穴が埋まる。

レポート作成は工程を分ける。市場分析や月次報告を「まとめて書いて」と一度に頼むと、構成も根拠も雑になりがちだ。そこで Prompt Chaining (処理を複数段に連鎖させる手法) を使い、「下書き→点検→最終化」と段階を踏ませる。こうすることで、各工程が前工程の粗を拾い、品質が安定する。人間がレポートを書くときの手順を、そのまま機械に踏ませるだけと考えてよい。これらがそのまま、明日から検討に入れるAIエージェント構築の活用事例になる。

並列化は速さの道具ではない。信頼性が要る一点にだけ差す道具だ。

3つの例に共通するのは、いずれのAIエージェント構築も巨大な専用フレームワークを必要としない点だ。手元の仕事の段取りを声に出し、それが「種類で分かれる」なら Routing、「複数の目で見たい」なら Parallelization、「工程で割れる」なら Prompt Chaining。まずそのひとつを、費用の上限と進捗の見どころだけ決めて小さく回してみる。精度が確かに上がったと確認できてから、次の型を追加すればよい。

- Anthropic「Building Effective AI Agents」 - Anthropic「Writing effective tools for AI agents—using AI agents」