MCPツールの返答が長すぎて、AIが本題を忘れる。現場では珍しくありません。検索結果を丸ごと返すツール、巨大なログを吐く監視ツール、数百件のレコードを返す社内検索。どれも単体では正常でも、同じ会話に積み重なると判断に必要な文脈を圧迫します。
OpenAIが2026年9月1日に公開したCodex 0.152.0では、MCPツールごとにoutput_token_limitを設定できるようになりました。地味な更新ですが、AIに社内業務を任せるなら、かなり実務的です。ツールの権限だけでなく「返答をどこまで会話へ持ち込むか」も管理できるからです。
何が変わったのか
公式リリースによると、各MCPツールに出力トークンの上限を設定し、セッションを再開した後も同じ切り詰めルールを適用できます。プラグイン側と利用者側のポリシーが重なる場合は、より厳しい上限が採用されます。承認ポリシーとは別に扱われるため、「実行してよいか」と「結果を何文字までAIに渡すか」を分けて設計できます。
実装元のPull Requestでは、通常のツール出力だけでなく、ツール実行後のフック応答や再開セッションにも同じ予算を引き継ぐと説明されています。設定の読み込み、スキーマ検証、ポリシー統合、上限を超えた場合の切り詰めもテスト済みです。
ここまでは公式情報です。以下は、この変更を会社の運用へ落とすときの私の解釈です。
「全部渡す」は安全策ではない
AIに判断材料を多く渡せば精度が上がる、と考えがちです。実際には、長い出力ほど良いとは限りません。必要な3行が5万行のログに埋もれれば、モデルは周辺情報にも注意を使います。会話の上限に近づけば圧縮が入り、最初に伝えた判断基準が薄くなることもあります。
社内検索なら、本文を50件返すより「候補10件のタイトル、更新日、該当箇所」まで返し、必要な文書だけ次の呼び出しで取得するほうが扱いやすい。監視ログなら、生ログを全部流すのではなく、異常行と前後数行、集計値、元ログの保存先を返す。出力制限は情報を捨てる仕組みではなく、会話へ載せる情報と正本に残す情報を分ける手綱です。
ツール別に上限を決める
一律の上限は雑です。ツールの役割に合わせて決めます。
- 顧客・案件検索：候補一覧と一致理由だけを返す。原文は選択後に取得する
- ログ監視：エラー要約、発生時刻、件数、代表例、元ログの場所を返す
- 規程・契約検索：該当条文は省略しすぎず、文書名と版、ページ位置を必ず残す
- 集計ツール：明細を並べず、合計と差分、例外行、再計算に使った条件を返す
上限を小さくしすぎると、引用や例外条件が途中で切れます。特に契約、会計、セキュリティの確認では、短さより根拠の再現性が優先です。切り詰めが起きた事実を利用者に見せ、元データへ戻れるリンクや識別子を残す必要があります。
導入前に見る4項目
- 通常時の出力量
代表的な入力を数件流し、返答量の中央値と最大値を測ります。 - 切れてはいけない情報
文書名、更新日、金額、例外条件、エラーコードなど、末尾に追いやられても残す項目を決めます。 - 二段階取得の有無
一覧取得と詳細取得を分けられないツールは、上限設定だけで使い勝手が悪化します。 - 正本の保存先
会話に入れなかった原文を、どこで再確認できるかを明記します。
最初の対象は、返答が長くなりやすいMCPツールを3つで十分です。検索、ログ、一覧取得のどれかを選び、上限を変えながら「必要な根拠が残るか」「次の判断に進めるか」を確認します。トークン削減率だけをKPIにすると、短いが使えない返答になります。再呼び出し回数と、人が原文へ戻った回数も一緒に見たほうが実態をつかめます。
出力制限と承認は別物
output_token_limitは、ツールの出力を会話へ入れる量を制御する設定です。ツールが何へアクセスできるか、更新や送信を実行してよいか、機密情報を返してよいかまでは決めません。
最低でも、アクセス権限、実行前承認、出力上限、監査ログを別々に持たせます。大量出力を短くしただけで、安全になったと判断するのは危険です。逆に、権限設計だけを固めても、巨大な返答で会話が崩れれば業務品質は落ちます。
私はこの更新を、MCPの「静音化」と捉えています。AIへ道具を増やす段階から、必要な結果だけを返す段階へ進むための設定です。まず1つの長すぎるツールを測り、一覧と詳細を分ける。そこから始めるのが現実的です。