claude -pにログを渡すと10MB上限で止まる — 絞り方と代替

claude -pにパイプで渡せる標準入力は10MBまでです。超えるとClaude Codeはエラーを出し、0以外の終了コードで止まります。大きなログを丸ごとcatで流し込む運用は、ある日ログが育った時点で壊れます。

ここでは、止まったときの見分け方、ログを先に絞る手順、ファイルパスで渡す切り替え、上限を超える前に検知するスクリプトを順に説明します。

10MBを超えるとどうなるか

公式のヘッドレス実行のページには、次の注記があります。パイプした標準入力は10MBが上限で、超えると明確なエラーと0以外の終了ステータスで終了します。大きな入力は、内容をファイルに書き出してプロンプトでそのパスを指すよう案内されています。

エラー文言そのものは、このページには載っていません。スクリプト側は文言に頼らず、終了コードで判定するのが安全です。

cat build-error.txt | claude -p 'concisely explain the root cause of this build error' > output.txt

上の形が公式の例です。build-error.txtが10MB以内なら動き、超えると止まります。

標準入力が読めないときとは別の挙動

似た名前の挙動が、同じページにもう1つあります。標準入力を読めない場合、たとえば起動元のプロセスが接続を切っていたときは、警告を標準エラーに出し、コマンドラインのプロンプトだけで続行します。

前者は止まるので気づきます。後者は止まらずにログ抜きで答えが返ってくるため、CIの出力に警告が混ざっていないかも見ておく価値があります。

上限に当たる前に確かめる

まず手元のログが何バイトあるかを測ります。wc -cならmacOSとLinuxのどちらでも同じ書き方で動きます。

wc -c < build.log

10MBは10,485,760バイトとも1,000万バイトとも読めます。公式は「10MB」としか書いていないため、境界ぎりぎりの入力は避けて、数MBに収めるつもりで絞るのが現実的です。

パイプラインの終了ステータスは、付けないと最後のコマンドの値だけになり、前段の失敗が見えなくなります。スクリプトの先頭でset -o pipefailを付けると、前段の失敗がパイプライン全体の失敗として残ります。ただし、パイプの各コマンドは並行して動くので、前段が空の出力で終わってもClaudeの起動そのものは止まりません。空の入力を避けたいときは、抜粋をいったんファイルに書き、[ -s ファイル ]で空でないことを確かめてから渡します。

ログを先に絞る方法

上限を避ける最も確実な手は、Claudeに渡す前に減らすことです。サイズの話だけではありません。原因に関係のない行が多いほど、読ませる量も増えます。

末尾だけ渡す

ビルドの失敗は、多くの場合ログの終わりに出ます。

tail -n 2000 build.log \
  | claude -p 'このビルド失敗の根本原因を3行で説明して'

行数は目安です。足りなければ増やします。

エラー周辺だけ抜く

grepの前後行オプションで、エラー行とその文脈だけを取り出します。

grep -n -B5 -A15 -E 'ERROR|FATAL|Traceback' app.log \
  | head -n 3000 \
  | claude -p 'これらの抜粋から、最初に起きた異常とその原因を挙げて'

headで打ち切っているのは、エラーが大量に出たログで抜粋まで膨らむのを防ぐためです。最初の異常が一番有用なことが多いので、末尾ではなく先頭側を残しています。

時間窓で切る

障害の時刻が分かっているなら、その前後だけにします。systemdのログならjournalctlの時刻指定が使えます。

journalctl -u myapp --since "2026-10-27 09:50" --until "2026-10-27 10:10" \
  | claude -p '09:55前後の障害の原因を、ログの行を引用して説明して'

ファイルに書かれたログで、各行が2026-10-27T09:55:01のようなISO形式の時刻で始まっているなら、awkの文字列比較で窓を切れます。

awk '$1 >= "2026-10-27T09:50" && $1 <= "2026-10-27T10:10"' app.log \
  | claude -p '09:55前後の障害の原因を説明して'

ISO形式は辞書順と時系列が一致するので、この比較で足ります。時刻の書式が違うログでは、先に形式をそろえる必要があります。

コンテナのログは発生源で絞る

ファイルに落とす前の段階なら、コマンド側の時間・行数オプションが使えます。

docker logs --since 30m --tail 3000 myapp 2>&1 \
  | claude -p '直近30分の異常とその原因を挙げて'
 
kubectl logs deploy/myapp --since=30m --tail=3000 \
  | claude -p '直近30分の異常とその原因を挙げて'

docker logsは標準エラー出力を別に流すため、2>&1でまとめてからパイプに渡します。巨大なログを一度ファイルに吐いてから絞るより、最初から窓を切るほうが速く済みます。

重複を件数に畳む

同じ警告が何万行も続くログなら、sort | uniq -cで件数に畳む手もあります。ただし順序情報が消えるので、時系列が要る調査には向きません。件数の多い警告を知りたいときに限って使います。

絞っても大きいログは分割して要約を集める

時間窓を切っても数十MBが残る調査では、ファイルパスに頼らず、分割して1つずつ要約させる手があります。各チャンクを10MB未満に収め、チャンクごとの要約だけを最後に1回渡す2段構成です。

mkdir -p /tmp/chunks
split -l 20000 big.log /tmp/chunks/part_
for f in /tmp/chunks/part_??; do
  claude -p 'このログ断片の異常な行を、行の引用つきで箇条書きにして' \
    < "$f" > "$f.summary" || echo "失敗: $f" >&2
done
cat /tmp/chunks/part_*.summary \
  | claude -p '各断片の要約をもとに、最初の異常と根本原因を説明して'

split -lは行数で切るので、1行がとても長いログではチャンクが想定より大きくなります。wc -c /tmp/chunks/part_*で最大のチャンクが10MBに収まっているか確かめてください。チャンクが多いと、その分だけ呼び出し回数と費用が増える点も織り込んでおきます。

絞りきれないときはファイルパスで渡す

絞った後でも大きいとき、またはClaudeに自分で探させたいときは、ログを渡すのをやめて、場所を教えます。公式が案内している切り替えがこれです。

claude -p 'logs/app.log の 09:50〜10:10 の範囲を読み、障害の原因を説明して' \
  --allowedTools "Read"

--allowedTools "Read"は、読み取りを許可プロンプトなしで通すための指定です。公式のbareモードの例も、Readを事前承認して非対話実行を完了させています。

パスで渡すと、標準入力の上限は関係なくなります。代わりに、Claudeがファイルをどう読むかに結果が左右されます。巨大なファイルをそのまま指すと、必要な箇所に届くまで読み進める手間がかかります。パスで渡す場合も、プロンプトで時間帯やキーワードを添えて、見るべき範囲を狭めておきます。

2つの渡し方の使い分け

公式のビルドスクリプトの例は、git diff mainをパイプで渡す理由を「Claudeが差分を読むのにBashの権限が要らなくなる」と説明しています。パイプには、権限設定を小さく保てる利点があります。サイズに余裕があるうちは、パイプのままが手軽です。

上限を越えそうなら自動でパスに切り替える

CIのように、ログの大きさが日によって変わる環境では、手で判断できません。サイズを測り、閾値を超えたらパス渡しに回すスクリプトにしておきます。次は公式の記述を元にした組み立て例で、閾値や文面は用途に合わせて変えてください。

#!/usr/bin/env bash
set -euo pipefail
 
log="$1"
limit=$((8 * 1024 * 1024))   # 10MBに対して余裕を持たせる
size=$(wc -c < "$log")
 
if [ "$size" -le "$limit" ]; then
  claude -p 'このログの根本原因を説明して' < "$log"
else
  # 大きいので末尾だけ抜いてパスで渡す
  tail -n 5000 "$log" > /tmp/log-tail.txt
  claude -p '/tmp/log-tail.txt を読んで根本原因を説明して' \
    --allowedTools "Read"
fi

閾値を8MBにしているのは、境界の解釈差を避けるためです。スクリプトは終了コードを見て失敗を検知できます。claude -pは成功時に0、失敗時に0以外で終わるため、ifや||で分岐できます。

上のスクリプトはset -eなので、claude -pが失敗するとその場で終了します。通知やリトライを挟みたいなら、呼び出しを||でつなぎます。

if ! claude -p 'このログの根本原因を説明して' < "$log" > result.txt; then
  echo "claude -p が失敗しました(終了コード $?)" >&2
  # ここで通知を送る、または tail 抜粋に切り替えて再実行する
  exit 1
fi

if !の中ではset -eが効かないので、失敗時の後処理を自分で書けます。ただし$?は!で反転した後の値になるため、元の終了コードを残したいときはclaude -p ... || rc=$?の形にしてrcを参照します。

再現性を上げるなら --bareを足す

CIでは、ホストごとに入っているフックやプラグインの違いで結果がぶれます。スクリプト用途には--bareが推奨モードです。フックやMCPサーバー、自動メモリー、CLAUDE.mdを読み込まず、起動も速くなります。

注意点が1つあります。bareモードはOAuthの資格情報を読みません。サブスクリプションのログインではなく、ANTHROPIC_API_KEYなどの設定が必要です。ログイン切れで落ちる別の原因はclaude -pがOAuth session expiredで失敗する原因で扱っています。

絞った効果を費用で見る

--output-format jsonを付けると、応答にtotal_cost_usdが入ります。同じログを絞る前と後で流して比べれば、絞り込みがどれだけ入力を減らしたかを数字で見られます。この値はクライアント側の推計で、実際の請求とは差が出ることがあります。

tail -n 2000 build.log \
  | claude -p '根本原因を説明して' --output-format json \
  | jq '{cost: .total_cost_usd, answer: .result}'

費用の上限を設けたい場合は、Claude Codeの--max-budget-usdでAPI課金額に上限を設けるが参考になります。

つまずきやすい点

• 全体をcatしたまま運用している: ログが小さい間は動きます。育ったある日にだけ失敗するので、障害時ほど動かないスクリプトになりがちです。
• パイプの前段で失敗している: pipefailを付けると、grepの失敗がパイプライン全体の失敗として残ります。空の入力での呼び出し自体は防げないので、grep -cで件数を確かめるか、抜粋をファイルに書いて-sで空でないことを確認してから渡します。
• パスで渡して許可で止まる: -pは非対話なので、許可プロンプトに答える人がいません。--allowedToolsで読み取りを通しておきます。
• 途中で打ち切られた応答を成功と見なす: ターン数の上限--max-turnsに当たるとエラー終了します。終了コードを見ていれば拾えます。ターン数の設定はCLAUDE_CODE_MAX_TURNSと--max-turnsの違いにあります。

claude -pの基本オプションを押さえ直したいときは、claude -pオプションとはが出発点になります。

まとめ

10MBの上限は、ログが小さいうちは見えません。末尾、エラー周辺、時間窓のどれかで先に減らし、それでも大きいときだけファイルパスに切り替える。この順にしておくと、入力が膨らんだ日にも止まらず、読ませる量も抑えられます。