Claude Codeの/feedbackが無効 — 組織ポリシーの対処と代替

Claude Codeで/feedbackを打つと/feedback is disabled by your organization's policyと返り、ダイアログが開かない。この表示は、組織のポリシーが製品フィードバックを許可していないことを示します。/bugと/shareを打っても同じです。

不具合を伝える手段は残っています。GitHubのissueに自分で書けば、Anthropicに届きます。ただし、issueは誰でも読める公開の場です。コード・トランスクリプト・社内情報は書かないでください。

似た名前のメッセージがほかに2つあり、原因も対処も違います。以下では見分け方から順に説明します。

3つのメッセージは「どこで止まったか」が違う

フィードバック周りで見かける文言は3種類あります。止まった場所が違うので、対処もそれぞれ別です。

1つ目はダイアログすら開きません。2つ目は書いた内容が送信で弾かれたときの文言です。3つ目はセッション品質アンケートに「Yes」と答えた後の共有失敗を指します。

組織ポリシーで無効のときは何が起きているか

全文は次の形です。

/feedback is disabled by your organization's policy. To report a bug, open an issue at https://github.com/anthropics/claude-code/issues. Issues are public, so leave out anything confidential.

文頭のコマンド名は、実際に打ったものに変わります。/bugを打てば/bug is disabled …です。後半の案内文が付かず、最初の1文だけで出ることもあります。

この文言はv2.1.302で変わりました。v2.1.302より前はContact your organization admin to enable it.(組織の管理者に有効化を依頼してください)で終わっていました。古いバージョンの手順書やスクリーンショットに、この旧文言が残っていることがあります。

無効化に使われる環境変数

環境変数DISABLE_FEEDBACK_COMMAND=1は、/feedbackとClaudeが下書きするフィードバックを無効にします。/bugと/shareも同じ経路で止まります。v2.1.212より前は/bugと/shareが/feedbackの別名だったため、どの名前でも止まっていました。旧名DISABLE_BUG_COMMANDも受け付けられます。

なお、どの設定がこのメッセージを出すのかは、エラーリファレンスには書かれていません。自分の環境で原因を探すなら、まずシェルの環境変数を見ます。

claude --version
env | grep -E 'DISABLE_(FEEDBACK|BUG)_COMMAND'

何も出なければ、個人の環境変数ではなく、組織側の設定が原因の可能性が高まります。その場合はユーザー側で解除できないので、管理者に確認することになります。

使っている接続先によっても、見え方が変わります。データ使用のページの表では、/feedbackの報告はClaude APIでは既定でオン、Google Cloud・Amazon Bedrock・Microsoft Foundryなどでは既定でオフと書かれています。サードパーティ接続でフィードバックが使えないときは、組織の設定だけでなく、この既定値も疑う価値があります。

VS Code拡張では、v2.1.229以降の/bugが拡張機能自身のフィードバックダイアログを開きます。ターミナルのCLIと画面が違うため、「無効と出る」「出ない」の比較は、同じ入口どうしで行ってください。

代わりの報告手順

報告はGitHubのissueで行います。次の情報を添えると、受け取る側が再現しやすくなります。

• claude --versionの出力
• エラーメッセージの全文(固有名や社内パスは伏せる)
• 再現手順を数行
• 使っている接続先(Anthropic直・Amazon Bedrock・Google Cloud・Microsoft Foundryなど)

トランスクリプトは添付しないでください。/feedbackが通常送る会話履歴には、コードも含まれます。issueは公開なので、同じ内容を貼ると外に出ます。

issueを立てる前に、次の3つも試せます。

1. claude doctorを実行する。インストールの読み取り専用診断です
2. セッション内で/doctorを実行する。設定の問題を見つけて修正できます
3. status.claude.comで障害の有無を見て、GitHubの既存issueを検索する

Couldn't send feedbackは理由の続きを読む

Couldn't send feedbackで始まるメッセージは、ダイアログで送信した報告が届かなかったことを示します。Claudeが作った下書きの送信にも出ます。コロンの後ろに理由が続くので、そこで分岐します。

組織の拒否なら、同じ報告は何度送っても同じ答えになります。再送を繰り返さず、issueに切り替えるのが早道です。Claudeが作った下書きは、拒否されてもキューに残ります。不要なら破棄できます。

3つの拒否系の文言は、ユーザー側で確かめられることが違います。

• Feedback has not been enabled for your organizationとcustom data retention policies: どちらも組織への文言です。ユーザー側で変えられる設定は無く、報告先をissueに切り替えるのが現実的です。
• the sign-in this session uses is not allowed to send feedback: セッションが使うログイン・トークン・APIキーが送信を許されていない状態です。/statusで、どの認証が使われているかを見られます。別のログインで試すかどうかは、その結果で判断します。
• the server did not accept the credentials this session usesも同じ系統で、確認先は同じく/statusです。

v2.1.281より前には別の落とし穴がありました。Remote ControlのStopや緊急の別セッションからのメッセージがダイアログを開いている間に届くと、以降の送信がすべて失敗します。古いバージョンなら、ダイアログを閉じて開き直せば直ります。

Couldn't share the transcriptはサイズと経路の問題

Couldn't share the transcript.は、セッション品質アンケート("How is Claude doing this session?")の後に出る共有確認で「Yes」と答えた場合の文言です。評価の回答自体にはトランスクリプトは含まれず、共有は別の任意の手順です。

共有には8 MiBの上限があります。長いセッションでは、Claude Codeが次の順で中身を削りながら再試行します。

1. 最後のリクエストのモデル設定
2. 構造化された会話
3. サブエージェントのトランスクリプト

最後まで削っても送れないとき、またはネットワークやサーバーの失敗で止まったときに、このメッセージになります。サードパーティ接続(Bedrockなど)・Claude apps gatewayのセッション・Anthropicの認証情報が無い環境では、アップロードの代わりにローカルアーカイブを保存します。この場合は、アーカイブを書き込めなかったことを意味します。

対処は/feedbackで説明を添えて送り直すことです。他のリクエストも失敗するなら、通信環境の問題を先に疑います。

このメッセージが出たなら、フィードバックは無効ではない

公式のデータ使用のページには、フィードバックが組織ポリシーで無効な組織、ゼロデータ保持の組織、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを設定した環境では、このトランスクリプト共有の確認が表示されないとあります。そのため、Couldn't share the transcript.が出た環境では、フィードバックの経路そのものは閉じていないと読めます。/feedbackが使える可能性が高く、まず試す価値があります。

なお、サードパーティ接続やAnthropicの認証情報が無い環境では、/bugの報告が~/.claude/feedback-bundles/のローカルアーカイブに書き出されます。このファイルは自動では送られず、自分で転送する仕組みです。

管理者が止める範囲を決めるときの対応表

組織側でフィードバック関連を止めたい場合、スイッチは複数あり、止まる範囲が違います。

CLAUDE_CODE_SEND_FEEDBACK=1は、アカウントがすでに権限を持つ場所で下書きを有効にするだけです。DISABLE_FEEDBACK_COMMANDなど他の無効化スイッチは、これで上書きできません。

/feedbackだけ止めて、アンケートは残す構成もできます。逆に、アンケートだけ消して/feedbackを使えるようにしておくこともできます。ユーザーに「なぜ報告できないのか」と聞かれたときのために、無効化した旨と代替先(GitHub issue)を社内に伝えておく選択肢があります。

全員に同じスイッチを配るなら、管理設定のenvキーにDISABLE_FEEDBACK_COMMANDを書く経路があります。envは複数の管理ソースにまたがって変数ごとに統合されます。配られた先でどの管理ソースが効いているかは、各自のClaude Codeで/statusを開き、Setting sourcesの行で確かめられます。個人のシェルに環境変数が無いのに無効と出る環境では、この管理側の経路が原因の候補になります。

各スイッチの詳細は、feedbackDraftsを無効化してフィードバック下書きを止めるとfeedbackSurveyRateでアンケートを減らす・止めるにあります。通常時の送り方はClaude Codeのバグ報告とフィードバックの送り方が扱っています。

テレメトリ全般を止める環境では、フィードバック系もまとめて影響を受けます。その仕組みはDISABLE_TELEMETRYでテレメトリを止める手順で確認できます。

まとめ

問い合わせ先は、止めているのが誰かで変わります。自分のシェルにDISABLE_FEEDBACK_COMMANDが残っていれば自分で外せますし、無ければ/statusのSetting sourcesで管理ソースを確かめたうえで、管理者に相談する流れになります。どちらの場合も、当面の報告はGitHubのissueで足ります。issueは公開なので、トランスクリプトとコードは載せないでください。

Couldn't send feedbackは続く理由の文、Couldn't share the transcript.は8 MiBの上限と通信を見ます。