Insights·2026-08-22

エージェント一つにツールは何個までつけてよいか

Anthropic の認定試験が挙げた三つ目のエージェント・アンチパターンは、一つのエージェントにツールをつけ続けることです。発表スライドの基準線は四つか五つ、発表者が口頭で言ったのは一つか二つでした。どちらで取っても、その線を越えると推論の質が落ち、ツール選択が不安定になります。だからツールベルトを大きくする代わりにエージェントを割り、一つが一つのことだけをするようにします。そして検証を担うクリティック・エージェントには主張と根拠だけを渡し、思考過程はわざと外します。理由はグループシンクです。

툴 벨트를 키우지 말고 에이전트를 쪼갠다 — 명령과 단계를 담은 요약 도식

ここで言うツールとは何か

まず用語から。AI エージェントにおけるツールとは、モデルが自力ではできないことを代わりにやってくれる外側の機能です。ウェブを検索し、ファイルを読み、データベースに問い合わせ、メールを送る、といったものです。

いまこうしたツールをつける標準的な方法が MCP(Model Context Protocol)です。設定ファイルにサーバーを数行足せばツールが増える構造なので、つけるための労力がほぼゼロ。だから増え続けます。

しかしツールをつけるというのは、リストを長くするだけの話ではありません。つけたツールの名前と説明と引数の仕様が、毎回すべてモデルに読み込まれます。ツールが二十個なら、二十冊分の説明書が会話の前に敷かれた状態で始まるようなものです。

そしてモデルはそのリストから毎回一つを選ばなければなりません。選ぶものが増えれば、人と同じように選択が揺らぎます。

基準線 — 四つか五つ、あるいは一つか二つ

この数字は発表で二度出てきますが、値が違いました。スライドに書かれた基準線はツール四つか五つ、発表者が口で言ったのは一つか二つです。

どちらで取っても方向は同じです。その線を越えると推論の質が落ち、ツール選択が不安定になります。ここでの「不安定」はエラーになるという意味ではなく、同じ依頼に対して毎回違うツールを選んだり、見当違いのツールを選んだりすることが増えるという意味です。

数字を正確に覚える必要はありません。実務で使える形に直せばこうなります。「このエージェントがこの会話で実際に使うツールだけが残っているか?」一度も使われないツールが半分なら、すでに線を越えています。

大工のたとえ — なぜ割るほうが勝つのか

発表で出たたとえが正確です。家に大工を呼んだら、その人が配管工具と木工工具と電気工具を全部持って現れて「自分は何でもできる」と言う。

その人は呼びたくないでしょう。まともな大工が欲しかったのですから。何でもできるというのは、何か一つが特別に上手いという意味ではありません。

だから処方は「ツールベルトを大きくせず、エージェントを割れ」です。一つが一つのことだけをするようにして、その仕事に必要なツールを一つか二つだけ渡します。関数は一つのことだけをすべきだという関数型プログラミングの古い規則が、そのまま移ってきた形です。

コードを書かない人にも使いどころがあります。カスタム GPT やプロジェクトを作るとき、一つにすべての役割を詰め込まず、「資料調査用」「下書き作成用」「レビュー用」を別々に作る。同じ話です。

おまけでついてくるもの — サブエージェントの文脈をメインに漏らさない

エージェントを割ると自然についてくる利点が一つあります。各エージェントが仕事をしながら積んだ途中経過が、メインの会話に流れ込まないことです。

これが重要なのは、コンテキストがトークンでトークンがお金だからです。しかしもっと重要な理由が別にあります。コンテキストが多いほどモデルが混乱して答えが不正確になります。

だからサブエージェントにはその仕事を解くのに必要なものだけを渡し、返ってくるときも結果だけを受け取ります。過程はその中に置いてきます。

クリティック・エージェント — 検証させるのに、渡すものを減らす

発表で最も印象的だったコードがこれでした。先行する作業結果を検証するために作ったクリティック・エージェントなのに、渡すのは主張(claim)と根拠(evidence)のちょうど二つだけ。

その判断に至るまでの思考過程はわざと外します。検証を任せた相手に情報を減らして渡すわけで、最初は逆に見えます。

理由はグループシンクでした。複数のエージェントを集めて互いに話させると、一つの結論に収束してしまいます。発表者のたとえはこうです。パーティーで全員がピザを食べたがっていて自分だけ違うとき、場を壊したくなくて合わせてしまう。エージェントもそう動きます。

先行するエージェントがどの経路でその結論に至ったかを見せると、検証者はその経路を歩いて同じ結論に着きます。それは検証ではなく追認です。だから結論と根拠だけを渡し、「これで合っているか」を新たに判断させます。

人の組織でクロスレビューをさせるとき、原案担当者の結論メモを一緒に渡さないのと同じ理屈です。

今日やってみること一つ

いま使っているエージェントやカスタム GPT、MCP の設定を開いて、ついているツールの数を数えてみてください。

五つを超えているなら、そのうち半分はこの一か月一度も使われていない可能性が高い。その半分を外して同じ仕事をさせてみてください。ツールを選ぶ精度が目に見えて変わります。

外すのが惜しければ消さずに別のエージェントへ移します。検索とウェブ読み取りは調査用エージェントへ、ファイルの読み書きは作成用エージェントへ、という具合に分けます。

次回は四つ目のアンチパターンです。モデルがなぜ止まったかを見ずに答えから使うと、どこで静かに間違うのかという話です。