目次

Claudeを使っていて手が止まったとき、まず出た文言をそのまま検索する。ところが検索してもほとんど何も出てこない——そういう文言がいくつかある。たとえばこれらだ。

The model returned no content because the response was blocked by content filtering
The response was blocked by the provider's content filter
Streaming response ended before any complete data was received
Could not locate the Claude CLI on PATH
Connection to Claude's response was lost. Claude may still be working

これらに共通するのは、「Claudeを使っていて出たのに、Claudeの公式ドキュメントを探しても見つからない（ように見える）」という点だ。理由ははっきりしている。いま画面に出ている文言を書いたのが、あなたが思っているプログラムとは限らないからだ。

Claudeを呼ぶ経路はもう1本ではない。ターミナルの claude、IDEの拡張、OpenCode のような別のエージェント、GitHub Copilot 経由——そのどれもが失敗したときの言い方を自分で決めている。同じ出来事でも、文言は書いた層ごとに違う。

本記事は個別の原因を一から解説する記事ではない。「その文言を書いたのは誰か」を特定し、正しい解説記事へ振り分けるための入口だ。詳細は既存の記事に譲り、ここでは出どころの特定だけを扱う。一次情報で確認できたことと、できなかったことは分けて書く。

結論から
① 最初の一手
公式カタログで照合する

Claude Codeは自分が出す文言を公式に一覧化している。完全一致するかどうかで、書いた層が絞れる。原因を推理する前にこれをやる。

② 落とし穴
名指しが外れる

第三者ツールの文言は原因を名指しするが、その名指しが実際と違う実例が公開Issueに記録されている。文言を信じて直すと別の場所を直すことになる。

③ 見た目で判別できない
5本中2本は公式だった

冒頭に並べた5つを実際に照合したところ、2つはClaude Code公式のエラーリファレンスに載っていた。文言の雰囲気では層は当てられない。

1. まず最初にやること——公式カタログで完全一致を探す

原因を推理する前にやることがある。その文言がClaude Code自身の語彙かどうかを確かめることだ。

Claude Codeには公式のエラーリファレンスがあり、Claude Codeが画面に出す文言が網羅的に列挙されている。認証、レート制限、コンテキスト超過、ネットワーク、ストリーミング、MCP、プラグイン——どれも実際の表示文字列そのままで並んでいる。だから「自分が見た文字列がそこに載っているか」は、推測ではなく照合で決められる。

結果A
完全一致した

Claude Code本体か、公式が「起動元が出す」と分類している文言。公式の説明と対処がそのまま使える。冒頭の5つのうち2つがこれだった。

結果B
似ているが一致しない

別のプログラムが言い換えた可能性が高い。言い換えの過程で原因の名指しが足されていることがあるので、その名指しを鵜呑みにしない。

結果C
影も形もない

その文言はあなたが使っているツールの語彙だ。探すべきはAnthropicの資料ではなく、そのツールのリポジトリとIssueになる。

「Claude」と書いてあってもAnthropicの文言とは限らない。 文中にClaudeやmodelという語があるのは、そのツールがClaudeを呼んでいるからであって、文言をAnthropicが書いた証拠ではない。逆に、Anthropic製のプログラムが出しているのに公式カタログの本体側には無い、という組み合わせもある（第5章）。

2. エラー文言を書いているのは4つの層のどれか

Claudeを使う経路を分解すると、失敗したときに文字列を書きうる場所は4つある。どの層が書いたかで、読み方も、対処の当たる先も変わる。

層①
モデルを提供するバックエンド

Anthropic APIのほか、Amazon Bedrock、Google Vertex AI、GitHub Copilotのゲートウェイなど。HTTPステータスとJSONの error.message がそのまま画面に出ることが多い。

例：Output blocked by content filtering policy

層②
Claude Code本体

CLIが自分で判断して付ける注記。公式エラーリファレンスに逐語で載っているのがこの層の目印で、意味と復帰手順が文書化されている。

例：Streaming response ended before any complete data was received

層③
起動元プログラム（IDE拡張・ラッパー）

Claude Codeを起動しようとして失敗した側が出す。公式リファレンスはこれを「Wrapper and IDE errors」として独立の章に置き、Claude Code自身ではなく起動元のプログラムが印字するものと説明している。

例：Could not locate the Claude CLI on PATH

層④
第三者クライアント

Claudeをモデルとして呼ぶ別のエージェント。文言はそのプロジェクトが独自に書いており、公式カタログには存在しない。原因の名指しを含むことが多いが、外れることがある。

例：The response was blocked by the provider's content filter

この4層のうち、いちばん誤読しやすいのが層④だ。層①〜③は「起きたこと」を述べる傾向が強いのに対し、層④の文言はしばしば「なぜ起きたか」まで言い切る。ところがその断定は、そのツールが下した推定にすぎない。次章はその実例を扱う。

3. 「content filter」と出たとき、それは誰のフィルタか

冒頭に挙げた5つのうち2つは、どちらも「コンテンツフィルタにブロックされた」と述べている。ここが特に取り違えやすい。Claudeを使っているからといって、止めたのがAnthropicのフィルタとは限らないからだ。

3-1. The model returned no content because the response was blocked by content filtering

🟡 出どころ（観測どまり）： この文字列を逐語で確認できた一次情報は、GitHub自身のリポジトリにあるgithub/copilot-cli の Issue #3348だけだった。表題が「Repeated 'The model returned no content because the response was blocked by content filtering' on legitimate technical reasoning turns」で、文字列がそのまま入っている。ただし本文は投稿者が取り下げており、メンテナの技術的な回答も付いていない。ステータスは closed as not plannedだ。GitHubの公開ドキュメントにこの文字列そのものは見当たらない。したがって本記事は「GitHub Copilot CLIで報告された文言である」以上のことは主張しない。

一方で、✅ 確実に言えることがひとつある。GitHubの公式ドキュメント「Hosting of models for GitHub Copilot」は、Claudeを使う場合について次のように明記している。

「Claudeを使用する場合も、入力プロンプトと出力補完は引き続きGitHub Copilotのコンテンツフィルタを通過する——公開コードとの一致（該当する場合）についてのフィルタと、有害・不快な内容についてのフィルタである」

つまりCopilot経由でClaudeを使っているとき、出力を止めうるフィルタはGitHub側にも存在する。同じページはさらに、Copilotで使えるClaudeモデルのホスティング先を「Amazon Web Services, Anthropic PBC, and Google Cloud Platform」と説明している——Anthropicのapi.anthropic.comを直接叩いている構成とは限らないということだ。

だから対処が変わる。 Anthropic APIやClaude Codeで直接出る Output blocked by content filtering policy は、既存の著作物の再現を止める出力フィルタが主因で、対処は「逐語コピーをさせない」方向に寄せる（→ Output blocked by content filtering policyの原因と対処）。ところがCopilot経由の場合、GitHubが自ら「公開コードとの一致」も見ると書いている。既存コードに似た出力を作る作業なら、そちらで止まっている可能性がある。同じ「content filtering」という語でも、見ている対象が同じとは限らない。

切り分け方は1つで足りる。同じプロンプトを、ターミナルの claude（Anthropicに直接つながる経路）でも走らせてみる。そちらでは通るのにCopilot CLIだけ止まるなら、止めているのはAnthropicのフィルタではない。逆に両方止まるなら、モデル提供元側の判断である可能性が高い。

3-2. The response was blocked by the provider's content filter

✅ 出どころ（確認済み）： この文字列はOpenCode（オープンソースのコーディングエージェント）のものだ。リポジトリ anomalyco/opencode のIssue #35736に、この文言が逐語で報告されている。

そしてこのIssueこそが、本記事がいちばん伝えたい実例だ。表題を訳すとこうなる——「Vertexプロバイダのエラー（404、ソケット断、stop_reason:refusal）が、すべて同一の『blocked by content filter』として表面化する」。

実態1
404 NOT_FOUND

設定したリージョンにそのモデルが存在しない。Issueの例は claude-opus-4-8@default。これはただの設定ミスで、フィルタとは何の関係もない。

実態2
ソケット断・接続リセット

長時間セッション中にVertex APIとの接続が切れた場合。ネットワークの事象であって、出力の中身は判定すらされていない。

実態3
本物の拒否

HTTP 200で返りつつ stop_reason: refusal と安全カテゴリ（Issueの例は cyber）が付いている場合。この1つだけが文言どおり。

3つのうち文言が正しいのは1つだけだ。にもかかわらず画面には同じ文が出る。これが層④の文言を鵜呑みにしてはいけない理由である——「フィルタにブロックされた」と読んで表現を穏当に書き直しても、実態が404ならいつまでも直らない。直すべきはモデルIDとリージョンの設定だ。

同じリポジトリには、Issue #35643「コンテンツフィルタが出力をブロックしても、生成分の料金は請求される」も上がっている。どちらも記事執筆時点でオープンだ。

🟡 確認できなかったこと： OpenCodeのソースコードのどこでこの文字列が組み立てられているかは、Issueに記載がなく特定できなかった。Issueは過去の部分的な修正としてPR #31745に言及しているが、3つの失敗すべてを見分けられるようにはなっていないというのが報告の趣旨である。

いま試す順序はこうなる。①設定しているモデルIDとリージョンが実在の組み合わせか確認する ②同じプロンプトで再現するか、それとも散発的かを見る（散発的なら接続side） ③生のレスポンスが取れるなら stop_reason を見る。③で refusal が出ていて初めて、内容の問題として扱ってよい。

4. Streaming response ended before any complete data was received——これはClaude Code本体の文言だった

ここからは、第三者ツールの文言に見えて実際にはClaude Code公式の語彙だった2つを扱う。

✅ 確認済み： この文字列はClaude Code公式エラーリファレンスに項目として存在する。そして公式の説明は、多くの人が想像する内容とは違う。

「APIはレスポンスヘッダを返したが、レスポンスボディにClaude APIのメッセージが入っていなかった」

つまり「途中まで来て切れた」ではない。「中身がひとつも来なかった」である。Streaming と ended という語のせいで、応答が流れている最中に断線した話だと読んでしまいやすいが、公式の定義はヘッダだけ返ってボディが空、という状態を指している。ここを取り違えると、切断対策を延々と試すことになる。

公式が案内している対処は2手だ。①もう一度送る——元のメッセージは会話に残っているので、長いプロンプトを貼り直す必要はなく try again と入力すれば足りる。②毎回同じなら、ネットワーク・プロキシ・プロバイダのゲートウェイを疑う——公式は「Unable to connect to API」の項へ誘導している。

この読み方を裏づけるのが近くに並んでいる兄弟の項目だ。公式リファレンスには API returned an empty or malformed response（ヘッダは成功を示しているのに、ボディが有効なClaude APIメッセージではない）があり、さらに Bedrock streaming response has content-type "..."; expected "application/vnd.amazon.eventstream" という、ゲートウェイが返した中身の型が違うことを名指しする項目まである。この一群はいずれも「200は返ってきたが、中身がClaudeの応答ではない」系統だ。

中身が1つも来なかった側

Streaming response ended before any complete data was received
API returned an empty or malformed response

疑うのは経路。企業プロキシ、TLS終端、APIゲートウェイ、Bedrock／Vertexの前段にある中継。→ ネットワーク・プロキシ・TLS証明書エラーの記事へ

出力が出たあとで切れた側

Connection lost mid-response
The response stopped arriving

こちらは画面に出た分は残るし、continue で続きから再開できる。→ Connection lost mid-responseの記事へ

5. Could not locate the Claude CLI on PATH——公式が「起動元が出す」と分類している文言

✅ 確認済み： この文字列も公式エラーリファレンスに載っている。ただし置かれている場所が重要で、「Wrapper and IDE errors」という独立の章にある。公式はこの章を、Claude Code自身ではなく起動元のプログラムが印字するエラーと説明している。

公式の定義は「起動元のプログラムが、システムのPATH上に claude コマンドを見つけられなかった」。対処として案内されているのは次の2つだ。

  • 再インストールする。 インストーラが claude をPATHに追加する
  • PATHにインストール先を入れる。 macOS／Linuxでは通常 ~/.local/bin か /usr/local/bin、Windowsでは通常 %APPDATA%\Anthropic\Claude\bin か C:\Program Files\Anthropic\Claude\bin

ところが——実際に画面に出る文言は、公式カタログの見出しより長いことがある。anthropics/claude-codeのIssue #80087には、VS Code拡張が出した実物が逐語で記録されている。

Could not locate the Claude CLI on PATH. Launching by name in a PowerShell terminal would run a 'claude' from the open folder instead of the installed CLI, so the launch was blocked. Make sure the Claude CLI's install directory is on your system PATH (not only your PowerShell profile), then restart VS Code and try again.

後半は拡張が独自に足した説明だ。検索してもヒットしないのはこのためで、検索するなら先頭の1文だけにするのが正しい。これは層③の文言全般に言えることで、起動元は公式の見出しに自分の事情を接ぎ木する。

🟡 Issue #80087が報告している中身（未確定を含む）： 報告者はWindows 11で、ターミナルの claude は正常に動くのに拡張だけが失敗すると述べている。v2.1.212では動作し、v2.1.214とv2.1.217で再現したため、v2.1.214で入った回帰ではないかと推定している。原因としてWindowsの where.exe の出力の扱い（ユーザー名に非ASCII文字が含まれる環境）が疑われているが、これは報告者の推定であって確定した原因ではない。Issueは記事執筆時点でオープンで、回避策として拡張をv2.1.212に固定する方法が挙げられている。

切り分けはこの1行で足りる。ターミナルで claude --version を打つ。そこで版が表示されるのに拡張だけ失敗するなら、壊れているのはCLIではなく、起動元が見ているPATHだ。エディタをアイコンから起動した場合、そのプロセスが受け取るPATHはログインシェルが組み立てたPATHとは別物になりうる。インストール自体が済んでいない場合の話はcommand not foundの記事にまとめてある。

6. 出どころを特定できなかった文言と、自分で突き止める4手

冒頭の5つのうち1つ——Connection to Claude's response was lost. Claude may still be working——については、🔴 出どころを特定できなかった。本記事はここで名前を挙げない。

調べた範囲と結果は書いておく。Claude Code公式エラーリファレンスの全項目を通しで当たったが、この文字列は無かった。Remote Control（手元のセッションをスマホやブラウザから続ける機能）の公式ドキュメントも全文を当たったが、やはり無かった。公式で語感が近いのは Connection lost mid-response と Couldn't reconnect to your Remote Control session の2つで、どちらとも文字列は一致しない。

したがって層としては③か④のいずれかだが、どのツールが書いたのかは確認できていない。「Claude may still be working（Claudeはまだ動いているかもしれない）」という言い方は、文言を書いた側がClaudeを走らせている当人ではない——別のプロセスや別のマシンを外から見ている——ことを示唆するが、これは🟡 語法からの推測であって裏は取れていない。

こういう場合に読者が自分で決着をつけられる手順を置いておく。これは前章までの全ケースにそのまま使える。

手順1
どこに描画されたか見る

Claudeの応答の流れの中に混ざって出たのか、それともその外側の枠・通知・パネルに出たのか。外側なら、書いたのは層③か層④だ。

手順2
素の claude で再現する

同じ作業をターミナルの claude で走らせる。再現しないなら、その文言はそのツールのもの。再現するなら層①か層②に降りていく。

手順3
公式カタログで完全一致を探す

公式エラーリファレンスをブラウザ内検索する。検索語は先頭の1文だけにする——後半は起動元が接ぎ木していることがある（第5章）。

手順4
そのツールのIssueを検索する

公式に無ければ、探す先はAnthropicの資料ではない。使っているツールのリポジトリのIssueを文字列で検索する。本記事の出どころ特定もこの方法で行った。

7. 対応表——文言から行き先へ

ここまでの結論を1枚にまとめる。「書いたのは誰か」の欄が、その文言をどこまで信じてよいかを決めている。

画面に出た文言 書いたのは 実際に起きていること 行き先
The model returned no content because the response was blocked by content filtering 🟡 層④
GitHub Copilot CLIで報告された文言		 出力がフィルタで止まっている。ただしGitHub側のフィルタでありうる（公開コードとの一致も見る） 出力フィルタの記事
The response was blocked by the provider's content filter ✅ 層④
OpenCode		 3通りある——モデルIDの404／接続断／本物の拒否。文言どおりなのは3番目だけ 第3章の切り分け
Streaming response ended before any complete data was received ✅ 層②
Claude Code本体（公式）		 ヘッダは来たがボディが空。途中で切れたのではない。経路（プロキシ・ゲートウェイ）を疑う ネットワーク・プロキシの記事
Could not locate the Claude CLI on PATH ✅ 層③
起動元（公式が明記）		 起動元が見ているPATHに claude が無い。CLI自体は健全なことが多い command not foundの記事
Connection to Claude's response was lost. Claude may still be working 🔴 特定できず
公式カタログには無い		 未確定。公式で語感が近いのは Connection lost mid-response 第6章の4手 ／ 近い公式文言の記事

表を横に読むと、層④の2行だけが「実際に起きていること」の欄で揺れているのが分かる。層②と層③は公式に定義があるので揺れない。この差が、そのまま「文言をどこまで信じてよいか」の差だ。

8. 確定していること／していないこと

✅ 一次情報で確認できた
  • Streaming response ended… と Could not locate the Claude CLI on PATH はClaude Code公式エラーリファレンスに項目として存在する
  • 公式は後者を「Wrapper and IDE errors」に置き、起動元のプログラムが印字するものと説明している
  • 前者の意味は「ヘッダは返ったがボディにClaude APIのメッセージが無い」——途中断ではない
  • OpenCodeのIssue #35736が、404・接続断・本物の拒否が同一文言になると報告している
  • GitHub公式が、Claude利用時も入出力がGitHub Copilotのコンテンツフィルタを通ると明記している
🟡 報告はあるが未確定
  • The model returned no content because… の出どころ。逐語で確認できたのはgithub/copilot-cliのIssue #3348の表題だけで、本文は取り下げられている
  • Issue #80087が挙げるVS Code拡張の回帰の原因（where.exe の出力の扱い）は報告者の推定
  • OpenCodeのどのコードがこの文言を出すかはIssueに記載がない
  • 「Claude may still be working」が別プロセスを見ている側の言い方だ、というのは語法からの推測
🔴 確認できなかった
  • Connection to Claude's response was lost… をどのツールが出しているか。公式エラーリファレンスにもRemote Controlの公式ドキュメントにも無かった
  • GitHub Copilot CLIのあの文言に対するGitHub側の技術的な説明（Issue #3348はclosed as not plannedで、メンテナの回答が付いていない）
  • OpenCodeの2件のIssueに対する修正の完了（記事執筆時点でいずれもオープン）

まとめるとこうなる。文言の見た目からは、それを書いた層は判別できない。冒頭の5つは全部「第三者ツールが書いたように見える」が、実際には2つが公式、2つが第三者、1つは不明だった。だから最初にやるのは原因の推理ではなく、公式カタログとの照合だ。1分で終わり、しかもその後の探し先を決めてくれる。

FAQ

Q1. Claudeを使っているのに、Anthropicのドキュメントを探しても文言が見つかりません。

その文言をAnthropicが書いていない可能性があります。Claudeをモデルとして呼ぶツール（IDE拡張、別のコーディングエージェント、Copilot経由の利用など）は、失敗したときの言い方をそれぞれ独自に決めています。まず公式エラーリファレンスで完全一致を探し、無ければ使っているツールのリポジトリのIssueを文字列で検索してください。

Q2. 「content filter」と出たら、Anthropicのフィルタに引っかかったということですか？

そうとは限りません。GitHubの公式ドキュメントは、Claudeを使う場合も入力プロンプトと出力補完がGitHub Copilotのコンテンツフィルタを通ると明記しています。またOpenCodeでは、フィルタと無関係な404やソケット断まで同じ「content filter」の文言で表示される事例がIssue #35736に報告されています。同じプロンプトをターミナルの claude でも走らせて、再現するかどうかで切り分けてください。

Q3. Streaming response ended before any complete data was received は接続が切れたということですか？

違います。公式エラーリファレンスの定義は「APIはレスポンスヘッダを返したが、ボディにClaude APIのメッセージが入っていなかった」です。途中まで届いて切れたのではなく、中身がひとつも来なかった状態を指します。まずもう一度送り（try again で足ります）、毎回同じならプロキシやゲートウェイなど経路を疑ってください。

Q4. ターミナルでは claude が動くのに、IDEの拡張だけ「Could not locate the Claude CLI on PATH」と出ます。

CLIではなく起動元の問題です。公式リファレンスはこの文言を「Wrapper and IDE errors」——Claude Code自身ではなく起動元のプログラムが印字するもの——として分類しています。エディタをアイコンから起動した場合、そのプロセスが受け取るPATHはログインシェルが組み立てたPATHとは別になりえます。Issue #80087のように拡張のバージョンによる回帰が報告されている例もあります。

Q5. 検索してもヒットしないのは、そのエラーが珍しいからですか？

文字列が長すぎるせいであることが多いです。層③の文言は、公式の見出しに起動元が独自の説明を接ぎ木していることがあります（第5章の実例では、公式の見出しは1文なのに実際の表示は4文ありました）。検索するのは先頭の1文だけにしてください。

Q6. 文言に書かれている原因を信じて対処してはいけないのですか？

層によります。公式カタログに完全一致する文言（層②・層③）は、意味と対処が文書化されているのでそのまま従って構いません。問題は層④です。OpenCodeのIssue #35736は、まったく違う3つの失敗が同じ「content filterにブロックされた」という文になると報告しています。実態が設定ミスなのに、文言を信じて表現を書き直しても永久に直りません。

Q7. 第三者ツールを使うのをやめれば済む話ですか？

そこまでする必要はありません。ここで問題にしているのはツールの良し悪しではなく、失敗したときの文言の出どころだけです。切り分けのときに一度だけ素の claude で再現を試す、という運用で足ります。どのツールを選ぶかという話はCursor・Claude Code・GitHub Copilot・Codexの比較を参照してください。

Q8. Connection to Claude's response was lost. Claude may still be working の直し方は？

本記事では出どころを特定できませんでした。Claude Code公式エラーリファレンスにもRemote Controlの公式ドキュメントにも、この文字列はありません。したがって書いたのは起動元か第三者クライアントのいずれかですが、どのツールかは確認できていないため、本記事は名前を挙げません。第6章の4手で自分の環境で特定してください。応答の途中で切れる事象そのものについては、公式で語感の近い Connection lost mid-response の記事が参考になります。

関連記事

参考にした一次情報