Pipe Input（パイプ・インプット）

ターミナルで縦棒（｜）を見たことはあるが、Claude Codeにデータを流し込めると知らない人向け

料理ブログを運営していると、サイトのビルドが失敗したログ、公開前の文章の差分、長い設定ファイルの中身を、Claude Codeにそのまま見てもらいたい場面が出てきます。そのたびにファイルを開いてコピーして、ターミナルのClaudeに貼り付けて…という往復が地味に面倒です。

この往復をまるごと省くのがパイプ入力です。縦棒（｜）という記号でファイルの中身をそのままClaudeに流し込み、返ってきた答えをそのまま別の道具へ流す。手でコピペしなくても、コマンド同士をホースでつなぐように直結できます。

噛み砕くと

パイプは、台所のホースをイメージすると分かりやすいです。蛇口から出た水を、コップに手で汲んで運ぶのがコピペ。蛇口とコップをホースで直結して、ひねった瞬間に水が流れていくのがパイプです。

左側のコマンドが出した結果が水。縦棒（｜）がホース。右側のClaudeがコップ。間に人の手が一切入りません。

これがけっこう効きます。

しかも流れは一方向だけじゃありません。Claudeが出した答えを、さらに右側の別の道具へ流すこともできます。「ファイルの中身 → Claude → 整形する道具」と、3つ4つのコマンドを数珠つなぎにできるのがパイプの強みです。

大事な前提：流し込む側 claude -p を知っている状態で読む

このページのコマンドは、Claude Code がインストール済み・ログイン済みの状態が前提です。まだなら先にインストールと認証を済ませてください。

パイプ入力の主役は claude -p という叩き方です。これは画面で会話するのではなく、コマンド1回で質問して答えだけ受け取る使い方を指します。料理でいえば、店員と相談せずに券売機でポンと注文するイメージです。

この -p の細かい仕様そのものは別エントリ（claude-p）に分けてあります。ここでは「その claude へ縦棒でデータを流し込む」一点に集中します。

公式ドキュメントはこう言い切っています。

Non-interactive mode reads stdin, so you can pipe data in and redirect the response out like any other command-line tool.

「会話なしモードは入力を読み取るので、ほかのコマンドと同じようにデータを流し込み、答えを流し出せる」という意味です。Claudeを、特別扱いせず普通のコマンドの一員として扱える、ということですね。

「料理レシピ投稿サイト」を例に、実際の流し込みを見る

料理レシピ投稿サイトを運営している前提で、3つの場面を順に動かします。どれも頭の中で再現できるように、打つ内容とClaudeの反応を並べます。

ステップ1: ビルドが失敗したログを流し込む

レシピサイトを公開しようとしたら、ビルドが赤いエラーで止まりました。エラーの中身は build-error.txt という名前で書き出されています。これを開いて読むのが普通ですが、長くて何が原因か分かりません。

そこで、ファイルの中身をそのままClaudeへ流し込みます。

$ cat build-error.txt | claude -p 'このビルドエラーの根本原因を簡潔に説明して'

cat build-error.txt が「ファイルの中身を画面に出す」コマンド。その出た中身を縦棒でClaudeへ渡し、Claudeが原因を日本語で1〜2行に絞って返してくれます。コピペは1回もしていません。

ステップ2: 答えをそのままメモに書き出す

返ってきた説明、その場で読み流すと忘れます。なので答えを画面に出すかわりにファイルへ流し出します。

$ cat build-error.txt | claude -p 'このビルドエラーの根本原因を簡潔に説明して' > 原因メモ.txt

右端の > は「左の結果を画面ではなくファイルへ書き込め」という記号です。これで 原因メモ.txt に原因がそのまま保存されます。公式ドキュメントが載せている英語の原文がこちらです。

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

同じことを英語でやっているだけなので、一次ソースと照らして確認できます。

ステップ3: 公開前の文章の差分を校正にかける

レシピ記事を書き直しました。公開前に誤字だけチェックしたい。変更点（差分）を縦棒でClaudeへ流し、誤字チェッカー役をやらせます。

$ git diff main | claude -p "あなたは誤字チェッカー。差分内の誤字をファイル名:行番号の形で報告して。それ以外は何も返さないで"

git diff main が「いまの文章と、公開済みの文章の違い」を出すコマンド。その違いだけがClaudeに渡るので、レシピ全文を見せる必要がありません。

ここで初心者がやりがちな勘違いを1つ。「Claudeにファイルを読む許可を与えないと中身を見られないのでは」と思いがちですが、逆です。縦棒で流し込んだ中身は、許可なしでもそのまま読めます。公式ドキュメントもこう書いています。

Piping the diff means Claude doesn't need Bash permission to read it

「差分を流し込めば、Claudeはそれを読むためのBash許可を必要としない」。流し込み方式は、よけいな許可を渡さずに中身だけ見せられる、という利点があるわけです。

ステップ4: 今度は出す側。Claudeの答えから欲しい所だけ抜く

ここまでは「左からClaudeへ流し込む」入力側でした。今度は逆に「Claudeから右の道具へ流し出す」出力側を見ます。

プロジェクトの要約を、機械で扱いやすい形（JSON）でもらい、その中の本文部分だけを jq という道具で抜き出します。

$ claude -p "このプロジェクトを要約して" --output-format json | jq -r '.result'

--output-format json という指定を後ろに足すと、Claudeは答えを整理された形で返します。その返事を縦棒で jq へ流し、.result（本文の入っている場所）だけを取り出す。流れは「Claude → jq」で、さっきと向きが逆です。

公式の英語原文も併記します。

claude -p "Summarize this project" --output-format json | jq -r '.result'

ステップ5: 入りと出を同時に。差分を流し込み、答えを整形して受け取る

入力側と出力側は同時に使えます。公式ドキュメントは、GitHubの変更点を流し込みつつ、セキュリティ観点でレビューさせ、答えを整理された形で受け取る例を載せています。

gh pr diff "$1" | claude -p --append-system-prompt "You are a security engineer. Review for vulnerabilities." --output-format json

左の gh pr diff がGitHub上の変更点を出し、それをClaudeへ流し込み（入力側）、答えを --output-format json で整理して受け取る（出力側）。1行の中に入りと出が両方入っています。レシピサイトの変更レビューにもそのまま転用できます。

ステップ6: 答えにいくらかかったかを記録する

毎日この流し込みを回すなら、1回ごとの費用が気になります。--output-format json で受け取った答えの中には、1回の呼び出しにかかった金額（total_cost_usd）とモデルごとの内訳が入っています。

公式ドキュメントはこう説明しています。

the response payload includes total_cost_usd and a per-model cost breakdown, so scripted callers can track spend per invocation

つまり管理画面を毎回見にいかなくても、1回ごとの費用を答えと一緒に拾えるわけです。料理ブログを自動で回す仕組みに組み込むとき、地味に効いてきます。

つまりパイプ入力は何をしてくれるのか

• やってくれる: ファイルの中身やコマンドの結果を、コピペなしでそのままClaudeへ渡す。Claudeの答えを別の道具やファイルへそのまま流す
• やってくれない: 流し込めるのは1回ぶんのデータだけ。流し込んだ内容をClaudeが勝手にファイルへ保存し続けたりはしない
• 意味が薄い場面: 画面でじっくり何往復も会話したいとき。それは普通の対話起動や multi-turn-conversation の出番で、1発勝負の流し込みは噛み合いません

使いどころ3シナリオ（料理ブログで再現）

シナリオ1: 公開直前、ビルドが赤く止まったとき

新レシピ50件を一気に公開しようとしたら、ビルドが長いエラーで止まりました。エラーログをスクロールして原因を探すのは時間の無駄です。cat build-error.txt | claude -p '根本原因を簡潔に' で、長いログをまるごと流し込んで原因だけ1〜2行で受け取る。焦っている公開直前ほど、この一発が効きます。

シナリオ2: 投稿前のレシピ文を誤字チェックにかけたいとき

レシピは分量や手順の誤字が致命的です。「砂糖大さじ2」が「大さじ20」になっていたら事故になります。書き直した差分だけを git diff main | claude -p "誤字チェッカーとして報告して" で流し込めば、変更した所だけを集中チェックできます。レシピ全文を毎回見せるより速く、見落としも減ります。

シナリオ3: サイトを自動で回す仕組みに組み込みたいとき

毎晩、その日に投稿されたレシピをまとめて要約し、翌朝のメルマガ用ファイルに書き出したい。claude -p "今日のレシピを要約して" --output-format json | jq -r '.result' の形なら、Claudeの答えから本文だけを抜いて、そのまま次の処理へ流せます。人が画面を見ていなくても、台所のホースのように水が流れ続ける構成にできます。

初心者が踏みやすい落とし穴

• -p を省くと対話モードで起動する。cat build-error.txt | claude と -p なしで打つと、流し込んだ中身は最初の入力として読まれますが、そのまま画面の対話モードが立ち上がって入力待ちになります。スクリプトで一発実行して終わらせたいなら、必ず -p '質問文' をセットで付けます。
• 巨大なファイルを丸ごと流すとエラーで止まる。Claude Code v2.1.128の時点で、縦棒で流し込める入力は10MBまで。超えると、はっきりしたエラーメッセージを出し、成功を表す0ではなく「失敗」を示す終了コードで止まります。自動化スクリプトに組み込んでいるなら、この合図を見て後続の処理を止められます。公式ドキュメントが明記している上限です。
• 10MBを超えそうなら、流し込みをやめてファイルの場所を伝える。大きいデータは一度ファイルに書き出し、プロンプトの中で「このファイルの場所を見て」と伝える方式へ切り替える。公式も「write the content to a file and reference the file path」と推奨しています。
• 縦棒（｜）と書き出し記号（>）を混同する。｜は次のコマンドへ渡す、>はファイルへ書き込む。向きと役割が別物なので、入れ違えると答えが消えたように見えます。
• 答えをそのまま jq に流したのに中身が取れない。--output-format json を後ろに足し忘れると、答えが整理された形で返らず、jq が読めません。出す側のパイプは「json指定とセット」と覚えるのが安全です。
• 会話を続けたいのに毎回流し込んでしまう。流し込みは基本1発勝負。続けて深掘りしたいなら別の続け方（continue系）が要ります。何往復もしたい話を全部パイプでやろうとすると噛み合いません。
• 流し込んだ秘密の情報がそのまま渡る点に無自覚。設定ファイルや顧客リストを軽い気持ちで流し込むと、その中身がまるごとClaudeへ渡ります。流す前に「これ見せていい中身か」を一拍考える癖をつけたほうがいいです。

書き方

cat ファイル名 | claude -p '質問'
コマンド | claude -p '質問' --output-format json | jq -r '.result'

やってみるとこうなる

入力

cat build-error.txt | claude -p 'このビルドエラーの根本原因を簡潔に説明して' > 原因メモ.txt

出力例

原因メモ.txt に、ビルドエラーの原因が1〜2行で書き出される。画面には何も出ず、ファイルだけが作られる。--output-format json を足した場合は、答えの中に total_cost_usd（1回の費用）も入る。

関連項目

• claude -p（クロード・ピー）
• --bare（ベア）
• --allowedTools（アロウドツールズ）
• Context Window（コンテキストウィンドウ）
• Multi-turn Conversation（マルチターン・カンバセーション）
• Effective Prompting（エフェクティブ・プロンプティング）

公式ドキュメント

https://code.claude.com/docs/en/headless