AIエージェントのツール：まとめる上限と作らないツールを先に書く
ツールをまとめてよいのは人が途中で見なくてよい操作だけで、残りは作らないツールとして書きます。
この記事の要点
- まとめてよいのは、途中で人が見なくてよい操作だけ
- 取り消せない操作は、ほかの操作と同じツールに畳み込まない
- ツール表に「作らないツール」の欄を足し、代わりの済ませ方も書く
- ツールを足す依頼は、保守の範囲の外で見積もり直す
全体像図を準備中
目次
途中で人が見なくてよい操作だけをまとめる
A&Aの考え方
AIエージェントのツールとは、AIが自分で手順を選んで仕事を進めるときに、途中で呼び出す機能のことです。複数の操作を一つのツールにまとめてよいのは、途中で人が見なくてよい操作だけです。
出典に基づく事実
AIのClaudeを開発するAnthropicは、エージェント向けのツールの作り方を書いた技術記事を出しています。同じ資源を持った人が仕事を区切って解くのと同じやり方で、エージェントも解けるようにするのがツールだ、と書かれています。
出典に基づく事実
同じ記事は、ツールを使えば、途中の出力に使われるはずだった分、モデルが読む量も減らせる、と書いています。既存のソフトの機能や、それを外から呼び出す窓口（API）をただ包んだだけのツールは、よく見られる誤りとして挙げられています。
出典に基づく事実
ツールが多すぎたり重なっていたりすると、エージェントが効率のよい進め方から逸れることがある、とも書かれています。重なりは、できることを減らすのではなく、選び方を乱すものとして書かれています。
A&Aの考え方
どの工程をそのまま渡し、どの工程をまとめ直すかは、別の記事に書きました。この記事を書いているAutomate & Augment（A&A）の「AIエージェントの外注見積もり：既存APIを渡すか道具を作り直すか」です。
A&Aの考え方
ここで扱うのは、その先の問いです。まとめる判断は、どこで止まるのか。A&Aは、この上限を、その操作の途中で人が見る必要があるかどうかで決めます。
A&Aの考え方
人が見なくてよい操作だけなら、一つのツールにまとめても、人が止める場所は減りません。見る必要がある操作をまとめた瞬間に、止める場所がツールの中に隠れます。
仮想例
たとえば、請求の問い合わせに答えるエージェントを受託で作るとします。担当者は今、契約の内容、請求の履歴、過去のやり取りの三つを開いてから返事を書いています。
仮想例
この三つを読む操作は、どれも途中で人が見る必要がありません。顧客に何かが起きるわけでもありません。三つの呼び出しは、一つのツールにまとめられます。
取り消せない操作は、同じツールに畳み込まない
A&Aの考え方
取り消せない操作は、ほかの操作と同じツールに畳み込みません。返金の実行、顧客への送信、在庫の確定がこれにあたります。ここが、人が止める場所だからです。
A&Aの考え方
先ほどの例では、契約と請求と履歴をまとめて読むツールを一つ作り、返金の実行は別のツールに残します。読むところまでを一息にし、実行だけを外に出す切り方です。
A&Aの考え方
取り消せるかどうかで実行の線を引く考え方は、A&Aの「AIに実行まで任せる線引き：金額ではなく、取り消せるかで決める」に書きました。ここでは、任せると決めた後の切り方を扱います。
出典に基づく事実
技術記事は、エージェントが誤る型を四つ挙げています。まちがったツールを呼ぶ、正しいツールをまちがった値で呼ぶ、呼ぶツールが少なすぎる、返ってきた結果の扱いを誤る、の四つです。
A&Aの考え方
A&Aは、この自然な区切りに、人が止める場所も入ると読みます。出典は、操作を取り消せるかどうかについては述べていません。この線の引き方はA&Aの読みです。
A&Aの考え方
まとめることには、逆の費用もあります。一つにまとめた操作は、途中で止められません。部分的なやり直しもできません。
A&Aの考え方
だから、まとめる判断はこの費用を払ってよい所で止めます。払ってよいのは、途中で人が見なくてよい操作だけです。
| 操作 | 扱い | 理由 |
|---|---|---|
| 契約の内容を読む | まとめる | 途中で人が見る必要がない |
| 請求の履歴を読む | まとめる | 途中で人が見る必要がない |
| 過去のやり取りを読む | まとめる | 途中で人が見る必要がない |
| 返金を実行する | 別のツールに残す | 取り消せない |
| 請求書を発行する | 作らないツールに置く | 取り消せない。担当者が今の画面から出す |
ツール表には「作らないツール」の欄を足す
A&Aの考え方
ツール表には、作るツールだけでなく「作らないツール」の欄を足します。まとめる上限を決めた結果は、作らないと決めた操作の側に出るからです。
出典に基づく事実
技術記事は、少数の考え抜かれたツールを、特定の重要な業務に絞って作り、そこから広げることを勧めています。どのツールを作り、どれを作らないかを選ぶ手間は、あとで効いてくる、とも書かれています。
A&Aの考え方
A&Aは、受託ではこの「作らない」が口頭で消えると考えています。打ち合わせで作らないと言っても、納品物の仕様には作ったツールしか残らないからです。
A&Aの考え方
足す欄は四つです。作らないツールの名前、代わりの済ませ方、作らない理由、そして作るとしたら要るものです。代わりの済ませ方が空の行は、作らないと決めた行ではなく、まだ決めていない行です。
仮想例
たとえば先ほどの請求の例では、請求書を発行する操作を、作らないツールの側に置きます。代わりの済ませ方は、下書きを出し、担当者が今の画面から発行することです。
仮想例
理由は、取り消せない操作だからです。作るとしたら、発行の取り消し手順と、誰が押すかの取り決めが要ります。この二つが決まるまで、行は作らない側に置いたままにします。
出典に基づく事実
同じ技術記事は、関連するツールを、名前の先頭に共通の語を付けてまとめること（名前空間）が、多数のツールの境界を区切る助けになる、と書いています。サービスごと、資源ごとに先頭の語を付ける例が挙げられています。
A&Aの考え方
A&Aは、この先頭の語を、顧客にも見せる名前として使えると読みます。顧客のシステムごとに先頭の語をそろえると、どのツールがどのシステムに触るかが、表を見ただけで分かります。
ツールを足す依頼は、保守の範囲の外で見積もる
A&Aの考え方
納品の後に来る「この操作もできるように」という依頼は、保守の範囲の外で見積もり直します。ツールを一つ足す話に見えて、実際にはまとめる上限を引き直す作業だからです。
A&Aの考え方
足した操作が取り消せない操作なら、すでにあるツールの切り方も変わります。読むところまでを一息にしていたツールから、その操作を外に出し直すことになります。
出典に基づく事実
AIエージェントを業務に組み込む製品を提供するLindyという会社があります。その技術責任者のLuiz Scheidegger氏は、Anthropicが公開する事例ページで、モデルを選んだ理由を話しています。
A&Aの考え方
A&Aは、込み入った仕事ほどツールの呼び出しが難所になる、という話だと読みます。同じページにある成長率や生産性の数値は、定義と母集団が書かれていないため、小さな受託の見込みには使いません。
A&Aの考え方
作らないツールの表があると、追加の依頼は、表のどの行を作るか、という話になります。行には理由と、作るとしたら要るものが、すでに書いてあります。
A&Aの考え方
そこから、検収条件と保守の範囲を一緒に決め直せます。表に無い操作が来たときは、まず行を足し、上限の判定をやり直します。
A&Aの考え方
A&Aは、ツールの粒度と、納品後の不具合件数や保守工数の関係を測っていません。ツールの個数の目安も示しません。ここで言えるのは、決めた線を書き残す場所を作るところまでです。
まとめ
A&Aの考え方
ツールをまとめてよいのは、途中で人が見なくてよい操作だけです。取り消せない操作は、ほかの操作と同じツールに畳み込みません。
A&Aの考え方
ツール表には「作らないツール」の欄を足し、代わりの済ませ方、作らない理由、作るとしたら要るものを書きます。
A&Aの考え方
納品の後に来る追加の依頼は、その表の行として扱い、保守の範囲の外で見積もり直します。
ツールをまとめてよいのは、途中で人が見なくてよい操作だけです。取り消せない操作は、ほかの操作と同じツールに畳み込みません。ツール表には「作らないツール」の欄を足し、代わりの済ませ方、作らない理由、作るとしたら要るものを書きます。納品の後に来る追加の依頼は、その表の行として扱い、保守の範囲の外で見積もり直します。
よくある質問
作らないツールを先に書くと、できない受託先だと思われませんか。
行には、代わりの済ませ方を必ず書きます。できないという記述ではなく、どう済ませるかの記述になります。作るとしたら何が要るかも同じ行にあるので、顧客はその場で足すかを決められます。
ツールは何個までにすべきですか。
個数の目安は示しません。出典も個数ではなく、少数から始めて広げる順序を勧めています。決めるのは数ではなく、まとめてよい操作の範囲です。
既存のAPIをそのまま渡してはいけないのですか。
一つの操作で済み、返る情報が少ない工程なら、そのまま渡して構いません。この記事が扱うのは、まとめると決めた後にどこで止めるかです。渡すか作り直すかの決め方は、別の記事に書きました。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Writing effective tools for AI agents
Anthropic · 2025-09-11
確認日 2026-10-25 - Lindy empowers teams to scale with AI Agents powered by Claude
Anthropic · undated case-study page; no visible publication date
確認日 2026-10-25