Claude Code 設定：ツール出力の上限を引き上げる方法

Claude Code 設定の要点

この2つの設定項目は、2026年9月4日にリリースされた Claude Code 2.1.261 で追加されました。対象は限定的です。コマンド自体は実行され、必要な情報も出力されているのに、モデルへインラインで届く量が足りない場合に使います。

これはトークン数ではなく、文字数の上限です。受け渡し口の幅を広げる設定だと考えると分かりやすいでしょう。口を広げれば Claude は一度に多くのログを受け取れますが、通過した行はすべてセッションの領域を消費します。

まず、欠けた出力を回収する

最初から上限を増やす必要はありません。まずログ全体を回収し、欠けた情報がどこにあるかを確認します。そのうえで、その種類のコマンドに広いインライン領域が本当に必要かを判断してください。

正常終了したコマンドでは、Claude Code はデフォルトで約30,000文字をインライン送信します。それを超えると、Claude には冒頭の短いプレビューと、セッションディレクトリに保存された出力ファイルのパスが渡されます。そのパスを読み取るか検索するよう Claude に依頼してください。同種の処理を行うたびにログ全体をセッションへ流し込むより、通常はコンテキストを節約できます。

コマンドが失敗した場合は挙動が異なります。出力が長すぎると、Claude が受け取るのは先頭と末尾を合わせた約10,000文字の抜粋で、結果には保存先のファイルパスが含まれません。必要なスタックトレースが中央にあるなら、出力全体を既知のファイルへ保存しながら再実行します。

# Baseline: run the command normally and observe where its inline result stops
npm test

# Recovery for a failing run: keep the whole log at a path Claude can inspect
mkdir -p .claude/logs
test_status=0
npm test > .claude/logs/test-full.log 2>&1 || test_status=$?
wc -c .claude/logs/test-full.log
tail -n 120 .claude/logs/test-full.log
printf 'test exit code: %s\n' "$test_status"

これで .claude/logs/test-full.log が正本になります。ファイル全体をチャットへ貼り付ける代わりに、失敗したテスト名、例外、スタックトレースをこのファイル内で検索するよう Claude に依頼します。元の終了コードも、確認できる証拠として残ります。

バックグラウンドへ移行したコマンドは、書き込み先のファイルをすでに通知します。Anthropic は現在 TaskOutput を非推奨としており、その出力パスを Read で読む方法を推奨しています。多くの場合、このほうが素直にログを回収できます。

必要最小限の設定だけを変える

同じ正常終了コマンドがデフォルトの範囲を常に超え、より多くの内容を毎回必要とするなら、bashOutputMaxChars だけを引き上げます。まず60,000文字に設定すれば、128,000文字の上限を丸ごと受け入れずに、デフォルトのインライン許容量をおよそ2倍にできます。

{
  "bashOutputMaxChars": 60000
}

問題に合った適用範囲のファイルへ、このオブジェクトを記述します。

Claude Code がどのファイルを読み込んだかは、/status を実行して確認します。その後、同じコマンドを再実行し、wc -c の結果と指定値を比較してください。ログがまだ大きければ、正常終了時には再びプレビューと保存先ファイルのパスが渡されます。

バックグラウンドタスクには、代わりに taskOutputMaxChars を使います。指定範囲は同じく4,000〜128,000文字です。完了したバックグラウンドタスクが上限を超えた場合、Claude が受け取るのは直近の文字列です。そのため、履歴全体を調べる確実な場所は引き続き出力ファイルになります。

どちらの設定も、従来の対応する環境変数より優先されます。bashOutputMaxChars があれば、Claude Code は BASH_MAX_OUTPUT_LENGTH を無視します。taskOutputMaxChars があれば、TASK_MAX_OUTPUT_LENGTH を無視します。両方の仕組みを混在させると切り分けが難しくなるため、設定元は1つに統一してください。

コンテキストの負担は消えず、場所が変わる

正常終了コマンドの上限をデフォルトの約30,000文字から60,000文字へ増やすと、結果全体が収まる場合は、別途ファイルを読む手順を省けます。一方で、セッションには直ちに最大約30,000文字が追加される可能性があります。128,000文字に設定すると、許容範囲はデフォルトの正常終了コマンド枠の4倍を少し超えます。

増えた文字数をトークン数や料金へ正確かつ一律に換算する方法はありません。ソースコード、JSON、文章、Unicode ではトークン化のされ方が異なり、課金や利用枠もモデルとアカウント経路によって変わるからです。実務では、次の基準で考えるのが簡単です。

• 省略された中央部分に Claude が繰り返し必要とする情報がある場合だけ、上限を引き上げます。
• 保存ファイルを1回絞り込んで検索すれば解決するなら、デフォルトのままにします。
• 大量ログを調べる作業が終わったら、プロジェクト固有の例外値を下げます。
• 1回だけコマンドが切れたことを理由に、両方の設定を引き上げないでください。

これは、Claude Code スキルのコンテキスト消費を減らす方法と対になる考え方です。スキルのメタデータは作業開始前にコンテキストを使い、ツール出力は作業中に入ってきます。一方を直しても、もう一方の問題は解決しません。

効果が見込める7つのワークフロー

1. モノレポのテスト結果

大規模なテストスイートを実行するリリースエンジニアは、正常終了してもパッケージごとの結果や警告がデフォルトのインライン範囲を超えることがあります。そのリポジトリで bashOutputMaxChars を引き上げれば、結果が指定値に収まる限り、最初の応答でサマリー全体を確認できます。リリース確認のたびに追加でファイルを読む手間を減らせるのが利点です。

2. バックグラウンドで動く統合環境

プラットフォームチームでは、Claude が別の作業をしている間も、ローカルサーバー、エミュレーター、統合環境をバックグラウンドタスクとして動かし続けることがあります。taskOutputMaxChars を引き上げると、タスクを確認した際に Claude が受け取れる直近の出力が増えます。上限超過後は新しい文字が優先されるため、タスク全体のファイルは引き続き重要です。

3. コンパイラとリンターの警告を一括確認

アプリケーションチームでは、ビルド自体は成功しても数千件の警告が出ることがあります。正常終了コマンドの枠を広げれば、通常のプレビューでは範囲外になるパッケージの警告も確認できます。警告の積み残しを整理していて、軽いセッションより完全な結果を優先したい場面で効果を発揮します。

4. データベース移行のドライラン

データエンジニアがドライランを正常に完了すると、予定されているすべてのスキーマ操作が出力される場合があります。範囲を限定したうえで移行計画をインラインに収めれば、Claude は関連する変更を1つの結果内で比較できます。ただし、ログからシークレットや本番環境の識別子を除外していることが前提です。

5. 依存関係とライセンスの監査

セキュリティエンジニアが受け取る正常終了のインベントリは長く、検出事項が中央部分に散らばることがあります。リポジトリ単位で Bash の上限を広げれば、1回の監査セッションで範囲内のレポート全体を確認できます。プレビューの外にあったという理由だけでパッケージを見落とすリスクを減らせます。

6. 不安定なテストの調査

QA エンジニアが断続的な失敗の前後関係を正確に追いたくても、失敗コマンドの結果には先頭と末尾の抜粋しか表示されません。Bash の設定値を引き上げても、失敗時のこの挙動は変わりません。再実行の結果を既知のファイルへ保存し、狭い時間帯やテスト名に絞って検索すれば、セッションを埋めずに証拠を残せます。

7. 出力の多いコードジェネレーター

開発者がジェネレーターを実行したとき、作成またはスキップされたファイルをすべて確認するため、正常終了レポート全体が一度だけ必要になることがあります。調査中だけローカル設定で枠を広げ、終了後に削除できます。一度きりの例外をチームの恒久的なデフォルトにせず、生成された変更を整理して監査できる方法です。

設定ファイルの構成に慣れていない場合は、より広い範囲を扱う Claude Code セットアップガイドで、細かな調整を始める前にツール全体の位置づけを確認できます。

開発する価値があるもの

最有力：コンテキストを考慮したログブローカー

AI コーディングチーム向けに、ローカルで動くコマンドラッパーを開発します。生ログを必ず保存し、文字数を計測し、重要な範囲を索引化したうえで、パスを含む簡潔なマニフェストを返す仕組みです。同じ情報が繰り返し参照される場合に限り、コマンドごとのインライン上限を提案します。

周辺需要は小さいものの、商機は明確です。米国のキーワードデータでは、log analyzer の月間検索数は320、検索意図はトランザクショナル、クリック単価は$60.95と推定されています。既存のオブザーバビリティ予算からも、ログ処理に買い手がいることが分かります。Better Stack の料金表では、ログ、トレース、メトリクスを合わせた40 GBのバンドルが年払いで月額$25、AI SRE チャットは100万トークンあたり$5です。これらの製品が扱う仕事はより広範ですが、チームがログから情報を見つけるために費用を払っている証拠になります。

販売可能な最小構成は、クロスプラットフォームのラッパー、ローカルのログディレクトリ、文字カウンター、失敗箇所のインデックス、Claude が必要な部分だけ読めるレポートです。課題は信頼性にあります。ビルドログには認証情報、顧客データ、非公開のパスが含まれる可能性があるため、ローカル優先の保存方式と明確なマスキングルールは付加的な仕上げではなく、製品の中核です。単なる JSON の編集ではなく、設定変更の背景にある反復的な判断そのものを解決するため、これが最も有望です。

ニッチな機会：テスト証跡パッカー

一般的なテストフレームワークを実行し、手を加えていないログを保存したうえで、失敗したテスト名、スタックトレースの範囲、詳しく調べるためのファイルパスを短い証跡マップとして Claude に渡すアダプターを開発します。1つの大量出力スイートによって同じ切り分け作業が毎日発生しているなら、QA チームや開発者体験チームが対価を払う余地があります。

test failure analysis の米国での月間検索数は推定20、競合性は低く、キーワード難易度は11です。単独の幅広い SaaS として売り出すには需要が足りませんが、ログブローカーの特化機能、あるいは高コストなテストスイートを抱えるチーム向けの有料ツールとしては十分な根拠になります。

MVP に必要なのは、2〜3種類のテストランナー用アダプター、決定論的な生ログ保存、抽出した証拠と元の行を並べて確認できる画面です。課題は形式のばらつきです。Jest、Pytest、Gradle、独自ランナーでは失敗の表現が異なり、自信過剰な抽出処理が Claude に必要な手掛かりを削るおそれがあります。生ファイルは、いつでも1回の読み取りで参照できる状態にしておく必要があります。

この設定では解決できないこと

この設定で Claude のメッセージ数や週間利用枠が増えることはなく、モデルのコンテキストウィンドウも拡張されず、ツール使用回数の上限も回避できません。変更されるのは、ローカルの Claude Code にある2つの結果経路で、インライン文字列をどう扱うかだけです。

また、無制限の出力が安全になるわけでもありません。Claude Code が保存する正常終了コマンドの出力は64 MiBを超えると切り詰められ、ストリーミング出力が5 GBを超えるとコマンドは強制終了されます。さらに重要なのは、128,000文字のインライン結果が有用な会話コンテキストを圧迫し得ることです。最大値は安全柵であり、推奨値ではありません。

クラウドセッションには、適用範囲に関する落とし穴が1つあります。クラウド側が読むのはコミットされた .claude/settings.json であり、自分のマシンにあるユーザー設定ファイルやローカル設定ファイルは読みません。クラウドセッションへ届くのは、サーバーで管理された組織設定だけです。値が無視されているように見えたら、再変更する前に /status を確認してください。

自社のテスト環境やログ基盤に合わせ、コンテキストを意識した開発ワークフローを構築したい場合は、AI プロダクションシステムをご覧ください。