背景タスクの出力を取りたい時に「TaskOutput」を使い続けてる人向け
新規実装では基本使わない。既存スクリプトや古い手順書にTaskOutput呼び出しが残っているのを見つけた時、「これは置き換え対象です」と判断するために知っておく。30分かかるテスト、長時間ビルド、devサーバー起動など背景タスクの出力を取りたい場面では、TaskOutputではなく「/tasksで背景タスク一覧から出力ファイルの場所を確認」して「Readで読む」に切り替える。
背景で走らせている長時間コマンドの出力を取りに行く時、昔の癖で「TaskOutput」を打ってる人向けの整理です。これは公式tools-referenceの一覧表で (Deprecated) と明記された、もう推奨されていないツール。
公式の案内は短くて、「Prefer Read on the task's output file path」の一行。つまり「背景タスクが吐いた出力ファイルを Read で読め」が現代の作法です。
噛み砕くと
背景タスクというのは、Claude Codeに「これ裏で走らせといて、私は別の作業続けるから」と言って投げる長時間処理のこと。30分かかるテスト一式、ファイル変更を見張る watch ビルド、ローカルのdevサーバー起動なんかが典型例です。
昔は、その裏で走ってる処理の出力を取りたい時、専用ツール「TaskOutput」をID指定で叩いていた。今は違う。Claude Code側が背景タスクの出力を勝手にファイルに保存していて、そのファイルを Read で読めば終わり、になりました。
「専用窓口に並ぶ」から「共用ロッカーから自分で取り出す」に変わったイメージです。
大事な前提:もう新規で覚える必要のないツールです
このページにたどり着いた人の半分くらいは、たぶん「TaskOutputって何?覚えるべき?」を確認しに来てると思う。答えは「覚えなくていい」。
公式tools-reference一覧表で (Deprecated) マーカーが付いた以上、Claude Code側がいつ呼び出しを止めても文句は言えません。これから書く実演ステップも「現代の作法」が主で、TaskOutput の旧来の呼び出しはおまけ扱いにします。
「30分テストを裏で走らせて、途中経過を確認したい」を例に手順を見る
具体的なシーンを置いてみます。プロジェクトのテスト一式が約30分かかる。Claudeに「テスト走らせといて、私は別のファイル直してる」と頼んで、途中で「いま何個成功してる?」を確認したい場面です。
ステップ1: テストを背景で走らせる
Claudeに普通に頼みます。
npm run test:all を裏で走らせて。私は別の作業続けるから
Claudeは Bash ツールを run_in_background: true で叩いて、コマンドを背景に回します。この時点でClaudeは別の作業を進められる状態。
ステップ2: 途中経過を聞いてみる
10分後、私はClaudeにこう聞きます。
さっきのテストの途中経過見たい
ここで「TaskOutput を叩く」が旧来の発想。現代の作法は次のステップ。
ステップ3: 背景タスク一覧から出力ファイルの居場所を確認する
Claudeは /tasksで背景タスク一覧を見ます。/bashes でも同じものが出ます。一覧には各タスクの状態(実行中/終了)と、出力ファイルの場所が出てきます。
ここで初心者がやりがちな勘違いがあります。一覧に出てくる場所を見て「ここに自分で cat しに行かなきゃ」と身構えること。違います。Claudeに場所を渡せば Claude が Read で読みます。
ステップ4: Read で出力ファイルを読む
Claudeは Read ツールでその場所を開いて、現時点までに吐かれた出力をそのまま見ます。テストフレームワークが進捗を都度ファイルに追記するタイプなら、「いま120/300個成功、3個失敗」みたいな状況が読めます。
Claudeから私への返答はこんな感じになる。
10分時点で 120/300 成功、失敗 3、進行中 177。
失敗してるのは auth.test.ts の3ケース全部です。
これ既存バグか、私のさっきの変更が原因かは終わってから確認しましょう。
ステップ5: 終わった後の最終出力もRead
30分経ってテストが終わったら、同じ出力ファイルを Read で再度読めば、最終結果が全部入ってる。TaskOutput でID指定して取りに行く必要は、もうない。
つまり TaskOutput は何をするのか
- やること: 背景タスクのIDを指定して、その時点までの出力を返す(旧来の用途)
- やらないこと: 出力のリアルタイム監視は Monitor の仕事。タスクリスト管理系の TaskCreate・TaskGet・TaskList・TaskUpdate(旧 TodoWrite の後継)や、背景タスク停止の TaskStop との連携も別ルート
- 意味が薄い場面: 全部。公式が
Read推奨と書いた以上、新規で使う理由は基本ありません。既存スクリプトに残ってる呼び出しを順次置き換えていくのが現実的
使いどころ3シナリオ(具体題材で再現)
シナリオ1: 30分テストの途中経過を見る
料理ブログのバックエンドを作っていて、レシピAPIのテスト一式が30分かかるとします。「裏で走らせといて、私はフロント直してる」を頼んだ後、20分時点で「いま何個成功してる?」と聞く。Claudeは /tasks で出力ファイルの場所を確認し、Read で開いて「240/300成功、失敗5」みたいな現状を返します。TaskOutput は出てきません。
シナリオ2: dev サーバーのエラーログを後から振り返る
家計簿アプリを開発中、Claudeに npm run dev を裏で起動してもらい、フロントとAPIを行き来する。1時間後に「さっきの起動から、500系エラーって出てた?」と聞く時。Claudeは出力ファイルを Read で開いて、ログから 500 系をgrepすれば終わる。リアルタイムで監視したかったなら Monitor、後から振り返るだけなら Read、というのが現代の住み分けです。
シナリオ3: OSSをclone直後、長いビルドを裏で回したい
GitHubから家計簿アプリのOSSをcloneして、依存解決+初回ビルドが20分かかるとします。Claudeに「裏でビルド走らせといて、その間にREADMEを読み解いてフォルダ構成を教えて」と頼む。20分後、ビルドが終わったかを Claudeが /tasks で確認し、必要なら Read で出力ファイルから失敗ログを抜く。ここでもTaskOutput は要りません。
初心者が踏みやすい落とし穴
- TaskOutput を新規実装で呼ばない。公式が
(Deprecated)と明示した以上、いま動いていても将来予告なく消える可能性があります。新規実装ではReadを使う、で固定していい - タスク系の TaskCreate・TaskGet・TaskList・TaskUpdate・TaskStop とは別系統。名前が似てるので混同されやすいけど、前者の TaskCreate / TaskGet / TaskList / TaskUpdate は「セッション内のタスクリスト管理(旧 TodoWrite の後継4ツール)」、TaskStop は「背景 Bash タスクを停止する」もの。TaskOutput はその TaskStop と同じく背景 Bash タスク周りだが、出力取得の旧窓口。TaskOutput でタスクリストの中身を取ろうとしても何も得られない、というのは両系統に共通
- 「途中経過をリアルタイムで欲しい」なら TaskOutput でも Read でもない。公式の Monitor ツールが正解です。Monitorは背景コマンドの各出力行を即時にClaudeへフィードバックするので、「ログにエラーが出た瞬間にClaudeが反応する」みたいな使い方ができる。Readは「終わった後のファイルを開く」もの、Monitorは「動いてる最中のストリーミング」と覚えるといい
- 30,000文字超の自動ファイル化を知らない。Bashの出力が30,000文字を超えると、Claude Codeはセッション側で自動的に出力ファイルに保存し、Claudeにはその場所と先頭プレビューを渡します(上限15万文字)。だから出力が長くなろうが、Claudeは Read でいつでも全文を取りに行けます。TaskOutputで吸い上げる発想自体、この仕組みを知らない時代の癖です
- 「TaskOutput が動かない!」と慌てる前に Claude Code 自体のバージョンを確認。Deprecated として残っているうちは呼べる前提ですが、エラーが返ってきたなら呼び出し自体が無くなった可能性がある。その時は素直に
/tasks+ Read に切り替える - ストリーミング欲しさで Read を1秒ごとに叩くのは筋が悪い。それは Monitor ツールがやることです。Read連打は出力ファイルの読み直しになるだけで、Claude Codeの内部リソースを無駄に食う
書き方
旧来: TaskOutput(task_id) を叩いて、そのIDの背景タスクが吐いた出力を取得(非推奨)。
新推奨: /tasks / /bashesで背景タスク一覧と出力ファイルの場所を確認 → Read でその場所を読む。
やってみるとこうなる
入力
/tasks で背景タスク一覧を出してから、目当ての出力ファイルの場所をRead する流れ。例: 「さっき裏で走らせたテストの途中経過を見たい」とClaudeに頼むだけで、Claude側が自動で /tasks → Read の順に動いてくれる。
出力例
Readで出力ファイルを開いた時に返ってくる中身の例:
[10:32] Running 300 tests in 12 files...
[10:42] 120/300 passed, 3 failed, 177 in progress
[10:42] FAIL auth.test.ts > login flow > should reject invalid password
[10:42] FAIL auth.test.ts > login flow > should reject expired token
[10:42] FAIL auth.test.ts > signup flow > should validate email format
このページに出てきた言葉
- Deprecated(非推奨)
- 公式が「もう使うのやめてね」と宣告した状態。今すぐ動かなくなるわけではないが、新規実装で使うべきではなく、将来予告なく消える可能性がある
- 背景タスク
- Claude Codeに「裏で走らせといて」と頼んだ長時間コマンド。テスト実行、ビルド、devサーバー起動など、終わるまで待つと会話が止まる処理を裏に回して並行で進めるためのもの
- 出力ファイル
- 背景タスクが画面に吐くはずだった文字列をファイルとして保存したもの。Claude Codeは出力が30,000文字を超えると自動でファイルに書き出して、その場所をClaudeに教える(上限15万文字)
- /tasks / /bashes
- 背景タスク一覧を見るコマンド。状態確認、停止、出力ファイル場所の取得ができる
- Read(リード)
- Claude Codeにファイルを開かせるためのツール。テキスト・画像・PDF・Jupyterノートブックを扱える
- Monitor(モニター)
- 背景コマンドの各出力行が出るたびClaudeに即時フィードバックするツール。Readとは違って「動いてる最中のストリーミング」用