道具の結果をAIに全部渡さない｜費用と取りこぼしを減らす

「配信の結果を見てほしいと頼んだら、5千件の明細がそのまま返ってきて、要約が途中で切れました」「同じ問い合わせを2回しただけで、費用が跳ね上がります」——社内の道具をAIにつないだ直後に、必ずと言っていいほど出てくる相談です。道具の作りが悪かったわけではありません。本当は、道具が返してきた結果を、絞らずにそのままAIに読ませていることに原因があります。呼ぶ回数ではなく、返ってきた分量のほうが効いてくるからです。この記事では、結果をコードの中で受けて、絞ってから渡す形は何が違うのかを、手順に沿ってまとめます。

道具の結果を、そのままAIに読ませていないか

社内の道具をAIから呼べるようにすると、最初はうまく動きます。問題が出るのは、返ってくる件数が増えたときです。100件のときは要約が返っていたのに、5千件になった途端に、途中で切れた答えが返る。あるいは、返ってきてはいるが明細の真ん中あたりの数字だけが抜け落ちている。担当者から見ると、AIが急に賢くなくなったように見えます。

実際に変わったのは賢さではなく、渡している分量です。道具を呼ぶ設計の解説は、たいてい「どう呼ばせるか」までを扱います。どの業務を1つの道具として切り出すか、説明文をどう書くか、渡す項目をどう決めるか。ここは重要ですが、その先に返ってきたものをどこで受けるのかという設計が残っています。既定では、返ってきた結果はまるごと会話に載ります。

この記事が扱うのは、その一点です。呼び方は変えません。変えるのは、返ってきた結果の置き場所です。会話に載せるのではなく、いったんプログラムの中で受け取り、絞ってから数行だけ会話に載せる。同じ道具、同じ問いのまま、結果の通り道だけを変えるという話だと考えてください。

一度返ってきた結果は、次の往復でも一緒に運ばれる

なぜ分量が効くのかは、やり取りの仕組みを見ると分かります。AIとのやり取りは向こう側に保存されていないので、往復のたびに、それまでの会話を全部送り直しています。つまり1回目に載った5千件の明細は、2回目にも3回目にも一緒に送られます。1回重いものを載せると、その重さが会話の終わりまで続くということです。

提供元が2025年11月に公開した技術記事に、分かりやすい例が出ています。ある置き場から議事録を取り出して、別の仕組みに登録する、という仕事です。この形だと、議事録の全文が文脈を2度通ります。取り出したときに1度、登録するときにもう1度。2時間の会議の議事録なら、それだけで5万単位を超えることがある、と書かれています。ここでいう単位とは、AIが文字を置き換えて数える数え方のことです。

人が同じ作業をするときのことを考えると、違いがはっきりします。議事録を別の場所へ移すだけなら、中身を最初から最後まで読み上げたりはしません。必要な箇所だけ見て、あとはそのまま運びます。AIに読ませなくても運べるものを、読ませてしまっている。これが、費用と取りこぼしの両方の出どころです。

同じ記事には、会話から外したときの変化の大きさが数字で出ています。道具の説明を全部先に読ませたうえで結果も会話に載せる形から、必要なものだけをコードの中で呼ぶ形に変えた例で、15万単位が2千単位になった——およそ98.7%の削減、と報告されています。ここには道具の説明の量を減らした効果も混じっているので、そのまま自社に当てはめる数字ではありません。説明の本数を絞る話は別の論点なので、この記事では結果の側だけを扱います。それでも、会話に何を載せるかで桁が変わるという感覚は持っておいて損がありません。

起きること（1）費用は呼んだ回数ではなく、返ってきた分量で増える

1つ目に起きるのが、費用の増え方が予想と合わなくなることです。「1日に何回呼ぶか」で見積もっていると、実績と合いません。単価が掛かるのは回数ではなく分量だからです。1回の呼び出しで5千件返す道具は、10件返す道具の500倍の重さを会話に持ち込みます。

提供元の開発者向けの公式ドキュメントには、この差が具体的に書かれています。10本の道具を直接呼ぶと、それらをコードの中でまとめて呼んで要約だけを返す場合の、およそ10倍の分量を使う、という記述です。あわせて、実運用の通信のうち道具の定義が10本から49本含まれる要求では、コードで受ける形にすると典型で20%から40%の削減になる、とも書かれています。

もう1つ、精度と費用を同時に見た測定も公開されています。道具を75本持つ案件管理のエージェントの評価で、コードで受ける形を有効にしたところ、請求される入力の分量が約38%減り、正答率は変わらなかったという結果です。分量を減らすと質が落ちる、という思い込みが必ずしも成り立たないことを示しています。

提供元が2025年11月に公開した別の技術記事にも、近い数字が出ています。複雑な調べ物を任せた場合に、43,588単位だったものが27,297単位になった、およそ37%の削減という報告です。ここで注目すべきは削減率そのものより、削減の出どころが「返ってきたものを会話に載せなかったこと」に集中している点です。指示文を短くしたわけでも、モデルを替えたわけでもありません。通り道を変えただけで、この桁の差が出ています。

起きること（2）真ん中が読み落とされ、上限に当たれば途中で切られる

2つ目と3つ目は、費用ではなく答えの中身に出ます。長い材料を渡すと、真ん中に置かれた情報は読み落とされやすくなります。5千件の明細を丸ごと渡した場合、先頭と末尾は拾われても、中ほどの数十件は無かったのと同じ扱いになることがあります。返事は返ってくるので、落ちたことに気づけないのがこの問題の厄介なところです。

3つ目は上限です。一度に扱える分量には上限があり、道具の出力が大きいと、渡る前に機械的に切り詰められます。実際の数字を見ておくと感覚が持てます。社内の道具をつなぐ取り決め（MCP）に沿った道具について、あるコーディング支援の公式ドキュメントでは、出力が1万単位を超えると警告が出て、既定の上限は2万5千単位と定められています。環境変数で変えられ、道具の側で注記すれば文字数の上限を最大50万文字まで引き上げられる、とも書かれています。

問題は、切り詰めが機械的だということです。どこが大事かを判断してから切っているわけではありません。決められた分量に達したところで打ち切るので、たまたま後ろにあった重要な行が消えます。上限を引き上げれば解決するように見えますが、上限を上げれば費用が上がり、真ん中の読み落としも増えます。上限との付き合い方ではなく、渡す分量そのものを減らすほうが筋がよい、という結論になります。

コードで受けるとは、どういうことか

形は単純です。AIが小さなプログラムを書き、その中で道具を呼びます。返ってきた結果はプログラムの変数に入り、会話には載りません。プログラムの中で絞ったり数えたりして、最後に出力した数行だけが会話に載ります。公式ドキュメントの言葉を借りれば、コードから呼んだ道具の結果は文脈に足されず、足されるのは最後のコードの出力だけ、ということです。

同じドキュメントに、分かりやすい例が載っています。20人分の経費が上限を超えていないかを確かめる仕事です。従来の形では20回の往復が必要で、そのたびに明細が文脈に積み上がります。コードで受ける形なら、1本のプログラムが20回引き当てて、上限を超えた人だけを返します。数百キロバイトが数行になる、と書かれています。

仕組みとしては、道具の定義に「コードから呼んでよい」という印を付けることで有効になります。ただし前提があります。プログラムを走らせる場所、つまり隔離された実行の場所が要ります。資源の制限と監視も要ります。直接呼ぶ形にはなかった手間が、実行の場所の用意という形で増える点は、導入の判断材料として最初に把握しておくべきところです。

この形には、費用とは別の副産物があります。中間の結果が実行の場所に留まり、会話に出ていかないことです。提供元の記事は、この性質を情報の扱いの観点から挙げています。氏名や連絡先を含む名簿を片方の仕組みから取り出して別の仕組みへ渡す場合、従来の形では中身がいったん会話に載ります。コードで受ける形なら、載るのは「何件処理したか」だけです。取引先の審査で、どのデータがモデルに渡っているかを聞かれる場面が増えている企業では、この差が説明のしやすさに直結します。

利点（1）絞る：配信結果の集計で

1つ目の利点は、絞れることです。メール配信の結果を例にします。5千件の明細が返るとして、実際に見たいのは「開封していない件数」「反応があった上位10件」「前月より落ちた施策」くらいのはずです。コードの中で条件に合う行だけを残し、件数と上位10件だけを会話に載せます。5千行が12行になります。

提供元の技術記事にも同じ趣旨の例があります。1万行の表を処理して、関係のある5行だけを返す、という書き方です。ここで大事なのは、絞った結果だけでなく絞る前の件数も一緒に返すことです。「5,132件から12件に絞った」と書いてあれば、読む側は元の規模を踏まえて判断できます。件数を省くと、12件が全体なのか一部なのかが分からなくなります。

絞る条件そのものは、AIに毎回決めさせません。この点は後の節で詳しく触れますが、条件を毎回AIが決めると、同じ問いに対して違う答えが返るようになります。条件は人が決めて固定し、変えるときは記録を残します。

利点（2）数える：名簿の突合で

2つ目は、数えられることです。2つの名簿を突き合わせて、重複・欠け・表記のゆれを洗い出す作業を考えます。片方が3,200件、もう片方が2,900件あるとき、両方を会話に載せて数えさせると、数が回ごとに揺れます。AIは数えるのが得意な仕組みではないからです。長い一覧になるほど、この揺れは大きくなります。

コードの中で数えれば、揺れません。同じ入力に対して同じ数が返ります。会話に載せるのは、重複が何件、片方にしか無いものが何件、表記のゆれが疑われる組み合わせが何件、そして目視が要る例を数件。この形にすると、人が見るのは数件で済みます。

数える処理をコードに移すと、副次的な効果もあります。同じ条件で毎回同じ数が出るので、前月と比べられるようになります。会話の中で数えていた頃は、数が揺れるので比較そのものが成り立ちませんでした。定例の報告に載せる数字は、ここを移してから作るほうが安全です。

利点（3）つなぐ：順位の一覧と広告の実績で

3つ目は、複数の道具の結果を突き合わせられることです。検索順位の一覧と広告の実績を、対象の頁や語で突き合わせたいとします。従来の形だと、順位の一覧を会話に載せ、広告の実績も会話に載せ、その上でAIに突き合わせさせることになります。両方を丸ごと載せた時点で、上限にも費用にも当たります。

コードの中なら、突き合わせは機械の仕事です。両方を取り出し、鍵になる項目でつなぎ、動きのあった行だけを残します。会話に載るのは、順位が上がって広告の反応も上がった10行、といった要約です。つないだ途中の表は会話に出しません。人とAIが担うのは、その10行を見て「なぜ動いたのか」を立てる部分です。

つなぐ処理を移すときに気をつけるのは、鍵の決め方です。頁の住所でつなぐのか、語でつなぐのか、識別の番号でつなぐのか。ここを曖昧にしたままAIに任せると、つなぎ方が回ごとに変わって、結果が再現しません。鍵は人が決めて、コードに書き込みます。

待ち時間の面でも差が出ます。コードの中では、互いに関係のない呼び出しを同時に走らせられます。公式ドキュメントも、コードから呼べる道具は同時に走らせる書き方ができる、と説明しています。順位の一覧と広告の実績のように片方の結果を待つ必要がない取り出しは、同時に投げれば待ち時間が重ならない。会話の往復で1本ずつ呼んでいた頃は、道具の応答時間がそのまま足し算になっていました。ここは費用ではなく、担当者の体感に効く部分です。

効く仕事と、効かない仕事は測定で分かれている

ここまで利点を並べましたが、全部の呼び出しをこの形に替えるのは間違いです。公式ドキュメントには、効かない場合がはっきり書かれています。厳密に逐次で、前の結果をAIが読んでから次を決める仕事では、往復を省けないので効果が出ません。呼び出しが少なく結果も小さい場合、とくに会話の最初の往復では、実行の場所を立ち上げる手間のほうが上回ります。

数字も公開されています。逐次で1回か2回だけ道具を呼ぶ形の評価では、点数は変わらず、費用が約8%増えたという結果です。逆に、問い直しと絞り込みが中心になる検索系の評価では、平均で11%成績が上がり、入力の分量が24%減ったと報告されています。同じ仕組みでも、仕事の形によって結果が反対を向きます。

仕事の形とは別に、そもそも使えない条件もあります。公式ドキュメントによれば、この形には2026年1月の版以降のコード実行の道具が必要で、答えの形を厳密に固定する指定とは併用できません。道具を名指しして強制的に呼ばせる指定もできず、定義の中に自分自身を参照する入れ子がある道具は対象にできません。使えるかどうかは、道具の側の作りで先に決まってしまうので、業務の候補を選ぶ前に、対象の道具がこの条件を満たすかを確かめておきます。

仕事の形	コードで受ける効き方	見分け方
同じ引き当てを多数に繰り返す	強く効く	件数分だけ往復が発生している
返る分量が大きく、絞る余地がある	強く効く	返ってきた明細を人は読んでいない
調べ物のように問い直しが続く	効く	絞り込みが工程の中心にある
前の結果をAIが読んでから次を決める	効かない	往復そのものが判断の連鎖になっている
呼び出しが少なく、結果も小さい	効かない	1回で十数行しか返らない
結果の生データを人が毎回見る	向かない	画面に出す前提の一覧を返している

どこまでコードに任せてよいか

任せる範囲は、機械的に決まる処理かどうかで線を引きます。任せてよいのは、並べ替え・件数の集計・合計・重複の除去・書式の統一・鍵での突合です。これらは入力が同じなら出力も同じで、誰が見ても検算できます。むしろAIに任せないほうが結果が安定します。

任せないのは、取捨の基準です。何を残して何を捨てるかは業務の判断であり、機械的には決まりません。「反応が落ちた施策」の落ちたとは何%からなのか、「重要な問い合わせ」の重要とは何なのか。ここをAIに決めさせると、同じ問いで違う結果が返ります。基準は人が決めて、文書とコードの両方に残します。

基準をコードに書き込むことには、もう1つ意味があります。人が決めた基準が形として残るということです。担当者が替わっても、どういう基準で絞っていたのかを読めば分かります。会話の中で毎回AIに決めさせていると、基準はどこにも残りません。コードに移すのは効率の話であると同時に、判断の記録を残す話でもあります。

線引きに迷ったら、その処理の結果を人が検算できるかどうかで判断してください。件数の集計は、元の一覧を数えれば合っているか確かめられます。取捨の基準は、確かめようがありません。基準が妥当かどうかは業務の目的に照らして議論するしかなく、その議論の場に出せる形で残っていることが条件になります。検算できる処理はコードへ、議論が要る判断は人へ。この線であれば、担当者が替わっても引き直されません。

AIに判断させない：絞り込みの条件は人が先に決めて固定する

繰り返しになりますが、ここが運用上いちばん外してはいけない線です。絞り込みの条件を毎回AIに決めさせない。条件は先に人が決めて、固定します。変えるときは版を上げ、いつ誰が何のために変えたかを残します。条件が動くと、先月の数字と今月の数字を比べられなくなるからです。

あわせて、根拠を返させます。絞った結果の数行には、元の件数・使った条件・除外した件数を必ず添えます。「5,132件のうち、開封済みかつ反応ありの条件で12件」と書いてあれば、読む側が条件の妥当性を判断できます。数字だけを返すと、その数字が何を意味するのかを確かめる手段がなくなります。

• 道具の結果は文字列として返る。外部から来た内容がそのままコードとして解釈される危険がある、と公式ドキュメントが注意している
• 外部の窓口や利用者の入力を経由した結果は、コードで扱う前に形を検証する
• 保留中の呼び出しは約4分でタイムアウトし、コードの中でエラーになる。時間のかかる道具は、待ち時間の上限を先に確認しておく

マーケ業務のどこに置くか

マーケティングの実務で、最初に替える候補ははっきりしています。配信結果の集計、名簿の突合、検索順位の一覧、広告の実績の抽出。いずれも件数が多く、返ってきた明細を人が読んでいない仕事です。読んでいないものを会話に載せているのですから、載せる意味がありません。

最初の1本の選び方は、3つの問いで決まります。返ってくる件数がいちばん多いのはどれか。週に何度も呼んでいるのはどれか。返ってきた結果を人が見ずに次の処理へ渡しているのはどれか。この3つに当てはまるものが、替えたときの効きがいちばん大きい呼び出しです。

逆に、替えないほうがよいものもあります。1件だけ引いて画面に出す問い合わせ、担当者が生の一覧を毎回見たい仕事、月に1回しか呼ばない仕事。手間が回収できません。全部を替えるのではなく、重い1本から替える。これは効率の話であると同時に、直すべき箇所を1つに絞ることで、効果を測れるようにする話でもあります。

導入の手順

進め方は4工程です。いきなり全体の設計を変えず、1本ずつ替えて、そのつど測ります。

この順番で進めると、効かなかったときに戻せます。全体を一度に替えると、効かなかった原因がどこにあるのか分からなくなり、結局そのまま使い続けることになります。

実務仕様の一覧

運用に入る前に、道具1本ごとに決めておく項目を並べます。ここで扱うのは道具そのものの仕様ではなく、コードの中で受けたあと、会話へ何をどう返すかの決めごとです。道具が何を返すかは呼ばせる側の設計で決まっていますから、その手前の設計はそのまま使います。下の項目が空欄のまま動き出すと、あとから直すのに手間がかかります。

決める項目	決め方の目安	空欄にすると起きること
1回あたりの上限件数	会話に載せるのは数十行まで。超える分はコードの中で集計する	上限に当たって機械的に切り詰められる
戻す項目	見出しの数を絞り、元の件数と使った条件を必ず添える	数字の意味が確かめられなくなる
失敗したときの戻り方	何回まで再試行するか、諦めたときに何を返すかを書く	無言で空の結果が返り、原因が追えない
エラーの残し方	エラーの中身をそのまま記録に残す。要約して捨てない	同じ失敗が再現できず、原因が特定できない
記録に残す項目	呼んだ道具・元の件数・絞った件数・使った条件・所要時間	効果を測れず、広げる判断ができない
待ち時間の上限	道具側の応答時間を測り、上限の内側に収まるか確認する	保留中の呼び出しが時間切れになる

この表は、道具を作る側ではなく運用する側が持つ一覧です。作る側の仕様書と混ぜると更新されなくなるので、別の場所に置いて、道具を1本増やすたびに行を足していきます。見直しの周期も先に決めておきます。つないでいる道具の仕様は、こちらの都合と関係なく変わります。返ってくる項目が増えれば1回あたりの分量も増えるので、四半期に一度、上限件数と戻す項目が実態に合っているかを確かめる時間を取ってください。

失敗の型

実際に起きやすい失敗を並べます。どれも「効率化したはずが、かえって分からなくなった」という形で表れます。

• 絞りすぎて根拠が消える：結論の数行だけを返し、元の件数も条件も残さない。読む側は正しさを確かめられない
• コードが増えて誰も直せない：呼び出しごとに別々のコードが増え、書いた人しか分からなくなる。戻す形をそろえ、置き場所を1つにする
• エラーの中身が捨てられる：失敗を「取得できませんでした」の1行に丸めてしまい、原因が追えない。エラーはそのまま記録に残す
• 全部を一度に替える：効かない仕事まで替えて、費用が増える。逐次で1、2回しか呼ばない仕事では費用が増えた測定もある
• 条件をAIに決めさせ続ける：同じ問いで違う答えが返り、前月との比較が成り立たなくなる

最初の1つと最後の1つは、同じ根から出ています。絞る作業が見えなくなることです。絞ったこと自体は正しくても、絞り方が残っていなければ、その数字は検算できません。

測る数字

最後に、効いているかどうかを判断する数字を3つに絞ります。1つ目は1回あたりの分量です。会話に載った入力の分量を、替える前と後で比べます。件数ではなく分量で見るのは、費用がそこで決まるからです。

2つ目はやり直しの回数です。絞りすぎると、人が「元の一覧も見せて」と追加で頼むことになります。追加の依頼が増えていれば、絞りが強すぎるか、戻す項目が足りていません。分量が減ってもやり直しが増えていれば、差し引きで損をしています。

3つ目は答えが変わった件数です。同じ問いを3回投げて、返る数字が同じかどうかを見ます。会話の中で数えていたときは揺れていた数字が、コードに移して揺れなくなっているはずです。揺れが残るなら、まだ判断の一部がAIの側に残っているということなので、どの処理が残っているかを探します。この3つを替える前後で1週間ずつ測れば、広げてよいかどうかは数字で決まります。

まとめ

AIに社内の道具を呼ばせたあと、返ってきた結果をそのまま会話に載せていると、費用は呼んだ回数ではなく分量で増え、真ん中の情報は読み落とされ、上限に当たれば機械的に切り詰められます。結果をコードの中で受ければ、絞る・数える・つなぐが機械の仕事になり、会話に載るのは要約の数行だけになります。公式に公開されている測定でも、道具を多く持つ環境では請求される入力が約38%減って正答率は変わらず、道具の定義が10本から49本の要求では典型で20%から40%の削減という数字が出ています。ただし万能ではありません。逐次で1、2回しか呼ばない仕事では費用が約8%増えたという測定もあります。だから全部を替えず、返る件数と呼ぶ回数を掛けていちばん重い1本から替え、戻す形を先に決め、1週間測ってから広げます。そして絞り込みの条件はAIに毎回決めさせず、人が決めて固定し、元の件数と使った条件を必ず添えて返す。ここを守るかどうかで、効率化が検算できる形で残るか、誰も確かめられない数字が増えるだけになるかが分かれます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。