第三者プロバイダー経由でもAnthropicへ送られますか？

公式コマンドリファレンスでは、第三者プロバイダー経由またはAnthropic認証情報がない場合、ローカルのfeedback-bundlesへ保存され、利用者が転送します。

【2026年最新】Claude Code SendFeedback導入ガイド

Claude CodeのSendFeedbackツールをチーム導入する方法を解説。feedbackDraftsの3設定、レビュー手順、機密情報を送らない運用、監視との切り分けまで実装例つきで整理します。

更新日：2026年8月27日

結論：Claude CodeのSendFeedbackは、不具合を自動送信する機能ではありません。Claudeが報告案をキューに追加し、利用者が/feedbackで内容と添付範囲を確認・編集してから送る仕組みです。チーム導入では、個人任せにせず、feedbackDraftsのモード、機密情報の除外、製品フィードバックと社内インシデントの切り分けを先に決めるのが安全です。

要点1：feedbackDraftsはnotify、quiet、offの3種類。公式設定リファレンスでは既定値はnotifyです。
要点2：報告はレビュー画面を経由します。会話履歴のどこまで含めるかを確認し、同意してから送信します。
要点3：機密情報を含む障害はSendFeedbackだけで処理せず、社内のインシデント管理、監査ログ、OpenTelemetryと分離します。

対象読者：Claude Codeを開発チームへ配布するテックリード、Platform Engineering、SRE、情報システム、セキュリティ担当者。

この記事でできること：設定例、レビュー手順、5つの報告テンプレート、運用チェックリストを使って、チーム向けの最小ルールを作れます。

最初に決めるべきことは「SendFeedbackを有効にするか」ではなく、何をAnthropicへの製品フィードバックとして扱い、何を社内だけで処理するかです。ここが曖昧だと、再現に必要な情報が足りない報告と、逆に情報を載せすぎた報告が同時に増えます。

2026年8月26日付のClaude Code公式changelogでは、セッション内で問題が起きたとき、Claudeがレビュー用のフィードバック案を作れるSendFeedbackツールが追加されました。同じ更新で、機能はfeedbackDrafts設定により無効化できることも案内されています。この記事は、この公式仕様を業務導入向けに分解した実装パターンです。特定企業の導入実績や効果測定値を示す記事ではありません。

SendFeedbackの判断軸は「起票・確認・送信先」の3つ

SendFeedbackを理解するときは、AIがどこまで自動化するかを3段階に分けると迷いません。Claudeが行うのは主に「起票案の作成」です。利用者は「確認」を担当し、接続方式に応じて「送信」またはローカル保存へ進みます。

起票：Claudeが報告案をキューに置く

公式changelogの説明は「something goes wrong in a session」のときにClaudeが報告案を作る、というものです。したがって、すべてのエラーを機械的に外部送信するログ転送機能ではありません。セッションの文脈から、再現条件、期待した動作、実際の動作などを下書きにまとめる補助機能として捉えるのが正確です。

この違いは重要です。ログ転送だと思って導入すると、監視要件を満たせません。一方、完全な手入力フォームだと思うと、Claudeが持っているセッション文脈を報告案へ反映できる利点を逃します。

確認：`/feedback`で編集・送信・破棄を選ぶ

Claude Code公式コマンドリファレンスによると、/feedbackを引数なしで実行すると、Claudeが作成したフィードバック案のキューを開けます。利用者は、案をレビューし、編集し、送信し、または破棄できます。新しい報告をその場で作る選択肢もあります。

このレビュー工程を、形式的な「OKボタン」にしてはいけません。少なくとも、秘密情報、顧客名、内部URL、未公開コード、認証ヘッダー、環境変数、会話履歴の範囲を確認します。送信可否の最終判断は人が持つ、という設計です。

送信先：接続方式によって外部送信かローカル保存かが変わる

公式コマンドリファレンスでは、Anthropicのファーストパーティ接続でサインインしている場合、同意後の報告はAnthropicへ送られます。第三者プロバイダーを使う場合、またはAnthropicの認証情報がない場合は、~/.claude/feedback-bundles/配下のローカルアーカイブへ保存され、利用者が必要に応じて転送します。

つまり、同じ設定ファイルを配っても、全員が同じ送信経路になるとは限りません。Bedrock、Vertex AI、Microsoft Foundryなどを含む複数の接続方式が混在する組織では、まず認証経路を棚卸ししてください。

`feedbackDrafts`の3モードを使い分ける

設定はnotify、quiet、offの3種類です。公式設定リファレンスではスコープはUserまたはManaged、既定値はnotifyとされています。共有プロジェクトの便利設定というより、個人または組織管理のプライバシー・テレメトリ設定として扱います。

値	動作	向いている運用	注意点
`notify`	Claudeが案をキューに置くと、入力欄の上にカードを表示	小規模パイロット、機能を周知したい導入初期	通知を障害アラートと誤認しない説明が必要
`quiet`	カードを出さずに案を作成。フッターの件数と`/feedback`から確認	操作を邪魔せず、必要時にまとめてレビューするチーム	キューを確認する担当と頻度を決めないと放置される
`off`	SendFeedbackツール自体を除外し、Claudeが案を作れないようにする	厳格な閉域運用、外部送信前審査が必須の組織	社内の不具合報告導線を別に用意する

個人検証では`notify`から始める

一人で挙動を確認する段階では、既定のnotifyが分かりやすい選択です。報告案が作られたタイミングを見逃しにくく、どの程度の情報が下書きに入るのかを観察できます。ただし、カードが表示されたことと、外部へ送信されたことは同義ではありません。レビューと同意が残っています。

{
  "feedbackDrafts": "notify"
}

チームの通常運用では`quiet`を検討する

開発中の集中を妨げたくない場合はquietが候補です。公式仕様では、Claudeは案を作りますがカードを表示せず、キュー数をフッターに示します。週次のツール改善会などで担当者が/feedbackを開き、再現性のあるものだけを送る運用に向きます。

{
  "feedbackDrafts": "quiet"
}

設定ファイルのスコープと優先順位は、Claude Code settings.json設定ガイドも参照してください。

機密性が高い環境では`off`と社内窓口を組み合わせる

外部送信が原則禁止のリポジトリ、顧客データへアクセスする端末、セキュリティ審査前の環境では、Managed settingsでoffに固定する選択が妥当です。ただし、単に止めるだけでは製品不具合が共有されなくなります。社内Issue、チケットシステム、セキュリティ窓口など、代わりの報告経路を必ず案内します。

{
  "feedbackDrafts": "off"
}

一時的に1セッションだけ無効化する場合、公式設定リファレンスはCLAUDE_CODE_SEND_FEEDBACK=0を案内しています。

CLAUDE_CODE_SEND_FEEDBACK=0 claude

チーム導入を6手順で進める

ここからは、開発組織での導入順序です。前置きのポリシー文書を何週間も作るより、対象を限定したパイロットで報告内容を観察し、その結果から設定を固めます。

手順1：対象バージョンと公式仕様を固定する

SendFeedbackの追加は2026年8月26日付の公式changelogで確認できます。運用手順書には、確認日、対象バージョン、参照URLを記載してください。Claude Codeは更新頻度が高いため、「最新版なら同じはず」とせず、ロールアウト時点の仕様を残します。

claude --version
# 出力を導入記録へ貼り、公式changelogの確認日も記録する

本記事は2026年8月27日に公式ドキュメントを確認しています。以後の変更はClaude Code changelogで再確認してください。

手順2：接続方式とデータ境界を一覧化する

端末ごとに、Anthropicファーストパーティ、クラウドプロバイダー経由、認証なしのどれかを記録します。そのうえで「外部送信可」「ローカル保存のみ」「機能無効」の3区分を決めます。リポジトリ名だけでなく、端末やワークスペースの接続方式が判断材料です。

開発者IDまたは端末グループ
Claude Codeの認証経路
扱うデータ分類
SendFeedbackのモード
社内チケットの起票先
外部送信の承認者または判断基準

手順3：Managed settingsで組織既定を配る

公式設定ではfeedbackDraftsのスコープにManagedが含まれます。組織で統一したい場合は、利用者ごとの手作業ではなく管理設定から配布します。たとえば、全社はoff、検証グループだけquietという段階導入にすると、挙動を把握しやすくなります。

管理設定の設計は、Claude Code全社ガバナンスとManaged settingsで、モデルやスキルの統制と合わせて整理しています。

手順4：報告前の除外チェックを定型化する

レビュー担当者の注意力だけに依存しないよう、報告前チェックを短い定型にします。最低限、次を確認します。

APIキー、トークン、Cookie、Authorizationヘッダーがない
顧客名、個人名、メールアドレス、内部ホスト名がない
未公開コードを必要以上に含めていない
再現に不要な会話履歴を選んでいない
画面キャプチャに別タブや通知が写っていない
社内インシデント番号を外部向け本文へ混ぜていない

Claude Codeの権限モデルや安全境界は、公式SecurityとClaude Code安全強化アップデート解説も確認してください。

手順5：再現情報を最小セットでそろえる

役に立つ報告は長い報告ではなく、再現可能な報告です。環境、操作、期待値、実際の結果、頻度、回避策をそろえます。逆に、リポジトリ全体や長い会話履歴を貼っても、問題箇所が特定できなければ情報量だけが増えます。

項目	書く内容	書かない内容
環境	OS、ターミナル、Claude Codeバージョン、接続方式	端末名、社内ドメイン、個人名
再現手順	最小の操作列、再現用の匿名サンプル	本番データ、顧客ファイル
期待値	仕様や通常動作として期待した状態	推測だけの内部実装
実際の結果	エラー文、発生タイミング、頻度	無関係な全ログ
回避策	再起動、設定変更など試したこと	検証していない断定

手順6：送信後の社内記録を残す

外部送信したら、送信日時、担当者、概要、社内Issue、含めた情報の範囲を記録します。報告本文をそのまま広範囲へ再共有する必要はありません。監査で必要なのは、誰が何を判断し、どの経路へ出したかを追跡できることです。

利用状況やツール実行の継続監視はSendFeedbackではなく、Claude Codeのログ・監視・可観測性ガイドを使って別系統で設計します。

報告品質をそろえる5つの入力テンプレート

以下はClaudeに報告案の整理を依頼するときのテンプレートです。SendFeedbackの送信を自動化する命令ではありません。出力を確認し、機密情報を削除してから/feedbackで扱ってください。

テンプレート1：最小再現手順を抽出する

このセッションで発生した問題について、製品フィードバック用の最小再現手順を整理してください。
出力項目は「環境」「事前条件」「操作手順」「期待した結果」「実際の結果」「再現頻度」「試した回避策」です。
顧客名、個人名、内部URL、秘密情報、未公開コードは削除または一般化してください。
推測と確認済み事実を分けてください。
不足している情報があれば、最初に質問してから作業を開始してください。

テンプレート2：長いログから必要箇所だけ抜く

次のログから、問題の再現に必要な行だけを抽出してください。
前後の文脈は各エラーの直前・直後に限定し、APIキー、トークン、Cookie、メールアドレス、絶対パスのユーザー名部分をマスクしてください。
削除した情報の種類を末尾に一覧化し、削除前の値は表示しないでください。
原因は断定せず、「観測事実」と「仮説」に分けてください。
不足している情報があれば、最初に質問してから作業を開始してください。

テンプレート3：バージョン差分を切り分ける

この不具合がバージョン差分に関連するか確認するため、比較表を作ってください。
列は「Claude Codeバージョン」「OS」「ターミナル」「設定差分」「再現したか」「補足」です。
未検証の組み合わせは「未検証」と書き、推測で埋めないでください。
外部へ共有できない設定値はキー名だけ残し、値を<redacted>に置き換えてください。
不足している情報があれば、最初に質問してから作業を開始してください。

テンプレート4：期待値の根拠を明確にする

「期待した動作」の根拠を整理してください。
公式ドキュメント、changelog、実際に確認した過去バージョンの挙動を分け、URLと確認日を付けてください。
公式情報で確認できない内容は「チーム内の期待」または「仮説」と明記してください。
架空の仕様、存在しないIssue番号、未確認のリリース日は作らないでください。
不足している情報があれば、最初に質問してから作業を開始してください。

テンプレート5：送信前の機密情報レビューを行う

以下のフィードバック案を、外部送信前の情報セキュリティ観点でレビューしてください。
検査対象は、認証情報、個人情報、顧客情報、内部URL、未公開コード、契約情報、脆弱性の悪用手順です。
問題箇所は値を再掲せず、行番号と情報の種類だけを指摘してください。
安全な一般化案を提示し、最終的な送信可否は人間が判断する前提にしてください。
不足している情報があれば、最初に質問してから作業を開始してください。

SendFeedbackと監視・インシデント管理を混ぜない

SendFeedbackは、Claude Code製品へ改善材料を届けるためのレビュー付き報告導線です。稼働監視、セキュリティ検知、社内SLA、顧客影響の追跡を代替しません。

製品フィードバックに向く情報

再現可能なUIやCLIの不具合
公式仕様と異なる挙動
特定バージョンで発生する回帰
誤解しやすい表示や操作フロー
改善要望と、その要望が必要になる具体的な場面

社内インシデントとして先に扱う情報

本番障害、顧客影響、データ破損
認証情報の露出や漏えい疑い
不正アクセス、権限逸脱、脆弱性悪用の疑い
法務・契約・規制に関わる事象
復旧時刻や社内SLAを追う必要がある事象

これらは、まず組織のインシデント対応手順へ載せます。外部への製品フィードバックが必要でも、封じ込め、証拠保全、影響範囲の確認を先行させます。SendFeedbackの案に機微情報を含めない形へ一般化できてから、別途レビューします。

OpenTelemetryで継続的に見る情報

Claude Code公式のMonitoringドキュメントでは、OpenTelemetryを通じて利用量、コスト、ツール活動をエクスポートできると説明されています。メトリクス、イベント、任意の分散トレースは、組織全体の傾向を見るための経路です。

公式Quick startは、メトリクス確認にclaude_code.session.count、ログのみの構成確認にclaude_code.user_promptイベントを例示しています。何も届かない場合はclaude --debugでOTelエクスポートエラーを確認するよう案内しています。これは製品改善案の作成とは目的が異なります。

目的	主な道具	責任者	保持する情報
製品不具合の報告	SendFeedback、`/feedback`	利用者またはツール管理者	匿名化した再現情報
本番障害の対応	社内インシデント管理	サービスオーナー、SRE	影響、時系列、復旧判断
利用状況の把握	OpenTelemetry、管理API	Platform、FinOps、管理者	メトリクス、イベント、コスト
監査証跡	監査ログ、社内台帳	セキュリティ、内部統制	操作主体、時刻、判断履歴

監査ログの設計は、Claude Code監査ログAPI対応ガイドも合わせて確認すると、報告と監査を混同しにくくなります。

実装例：リポジトリに報告ポリシーを置く

feedbackDrafts自体はUserまたはManaged設定ですが、チームの判断基準や匿名化手順はリポジトリ内で共有できます。設定値と説明文を分離するのがポイントです。

推奨するファイル構成

repo/
├── .claude/
│   └── CLAUDE.md
├── docs/
│   ├── claude-code-feedback-policy.md
│   └── incident-response.md
└── scripts/
    └── check-feedback-draft.sh

CLAUDE.mdには短い原則だけを置き、詳細な承認フローや連絡先はdocs/へ分けます。連絡先や内部URLを外部送信用のテンプレートへ混ぜないようにしてください。

`CLAUDE.md`に置く最小ルール

## Product feedback policy
- SendFeedback drafts are suggestions, not automatic submissions.
- Never include secrets, personal data, customer identifiers, internal URLs, or unpublished source code.
- Review and edit every draft in /feedback before sending.
- Production incidents and security events must follow docs/incident-response.md first.
- If the correct disclosure path is unclear, do not send externally.

この記述は、Claudeに最終判断を委ねるものではありません。セッション中に報告案を作る場合の禁止事項を明示し、人のレビューを前提にします。

簡易スキャナーで危険な文字列を見つける

次は送信可否を自動判定する完成品ではなく、レビュー前にありがちな秘密情報パターンを見つける補助スクリプトです。誤検知と見逃しがあるため、検出ゼロでも人の確認は省略しません。

#!/usr/bin/env bash
set -euo pipefail
file="${1:?usage: check-feedback-draft.sh DRAFT.txt}"

patterns=(
  'Authorization:'
  'Bearer[[:space:]]+[A-Za-z0-9._-]+'
  'api[_-]?key[[:space:]]*[:=]'
  'BEGIN (RSA|OPENSSH|EC) PRIVATE KEY'
  'https?://[^[:space:]]+\.internal'
)

found=0
for pattern in "${patterns[@]}"; do
  if grep -Eni "$pattern" "$file"; then
    found=1
  fi
done

if [[ "$found" -ne 0 ]]; then
  echo "Review required: possible sensitive data detected" >&2
  exit 1
fi

echo "No configured pattern matched. Human review is still required."

実際の組織では、秘密情報検知製品、DLP、リポジトリ固有の命名規則と組み合わせます。検出した値をログへ再出力しない設計も必要です。

導入確認コマンド

# 1. バージョン確認
claude --version

# 2. Claude Code内で設定診断
# /doctor

# 3. フィードバック案のキューを開く
# /feedback

# 4. 1セッションだけ無効化して比較
CLAUDE_CODE_SEND_FEEDBACK=0 claude

公式Troubleshootingは、設定や拡張、コンテキスト利用を自動確認する手段として/doctorを案内しています。Claude Code自体が起動しない場合は、シェルからclaude doctorを使います。

セキュリティレビューで見る7項目

「レビュー画面があるから安全」とは限りません。安全性は、送信前に何を見るかを運用へ落とせるかで決まります。

データ分類：公開、社内限定、機密、厳秘のどれかを判定する。
最小化：再現に不要な履歴、ファイル、ログを外す。
匿名化：個人、顧客、端末、内部サービスを一般名詞へ置き換える。
秘密情報：キー、トークン、Cookie、秘密鍵、接続文字列を除外する。
脆弱性情報：公開前の脆弱性は通常の製品フィードバックと分け、適切な開示窓口を確認する。
同意範囲：レビュー画面で選ばれた会話履歴や添付を確認する。
記録：送信者、時刻、概要、社内Issueとの対応を残す。

Claude Code公式Securityでは、Manual modeが読み取り中心から始まり、編集やコマンド実行時に許可を求める権限ベースの考え方を説明しています。SendFeedbackでも同じく、AIが案を作ることと、人が外部送信を承認することを分けるのが基本です。

よくある失敗パターンと回避策

失敗1：カード表示を自動送信と誤解する

❌「通知カードが出たので、セッション全体がすでに送られた」と説明する。

⭕「Claudeが報告案をキューへ追加した。/feedbackでレビューし、利用者が送信または破棄する」と説明する。

UIの通知とデータ送信を分けて教育すると、過度な不安と無警戒の両方を避けられます。

失敗2：全社員へ既定値のまま一斉展開する

❌ 認証経路やデータ分類を確認せず、全端末をnotifyで運用する。

⭕ 検証グループを限定し、接続方式、下書き内容、レビュー負荷を確認してからManaged settingsを決める。

既定値は製品の一般的な初期値であり、各組織の情報管理基準を自動的に満たす保証ではありません。

失敗3：本番障害をSendFeedbackだけで処理する

❌ 顧客影響のある障害を製品フィードバックへ書いて終わる。

⭕ 先に社内インシデントを起票し、封じ込めと復旧を進める。製品側の不具合が関係する場合のみ、匿名化した最小再現を別途レビューする。

SendFeedbackには、当番呼び出し、復旧タイマー、社内SLA、顧客連絡の機能はありません。

失敗4：ログを全部添付すれば調査が速いと思う

❌ セッション全文、環境変数、巨大なデバッグログをそのまま含める。

⭕ エラー周辺、最小再現、バージョン差分、期待値の根拠に絞る。秘密情報は値を再掲せず削除する。

報告品質は情報量ではなく、再現性と安全性で評価します。

FAQ

Q1. SendFeedbackは報告を自動送信しますか？

自動送信する仕組みとして説明するのは不正確です。公式仕様では、Claudeが報告案をキューに追加し、利用者が/feedbackでレビュー、編集、送信、破棄を選びます。送信前の同意工程があります。

Q2. `feedbackDrafts`の既定値は何ですか？

2026年8月27日に確認した公式設定リファレンスではnotifyです。仕様は更新されるため、導入時に最新のSettings referenceを再確認してください。

Q3. チーム全体で無効化できますか？

feedbackDraftsはUserまたはManagedスコープで設定でき、offはSendFeedbackツールを除外します。組織で固定する場合はManaged settingsを使い、代替となる社内報告経路も用意してください。

Q4. BedrockやVertex AI経由でもAnthropicへ送られますか？

公式コマンドリファレンスでは、第三者プロバイダー経由またはAnthropic認証情報がない場合、報告はローカルの~/.claude/feedback-bundles/へ保存され、利用者が転送する方式です。実際の接続方式と最新仕様を管理者が確認してください。

Q5. SendFeedbackがあれば監査ログは不要ですか？

不要にはなりません。SendFeedbackは製品改善のための報告導線です。組織の利用状況、コスト、ツール活動、操作主体を追うにはOpenTelemetry、管理API、監査ログを別に設計します。

Q6. 機密情報を含む可能性がある場合はどうしますか？

外部送信を止め、組織のセキュリティ・インシデント手順へ切り替えてください。報告が必要なら、秘密情報と顧客情報を除去し、最小再現へ一般化した案を人がレビューします。判断できない場合は送信せず、所属組織の規程に従ってください。

参考・出典

Claude Code changelog — Anthropic / Claude Code公式（2026年8月26日付のSendFeedback追加を確認、参照日：2026年8月27日）
Claude Code Settings reference — Anthropic / Claude Code公式（feedbackDraftsの値・既定値・スコープ、参照日：2026年8月27日）
Claude Code Commands reference — Anthropic / Claude Code公式（/feedbackのレビュー・送信・保存経路、参照日：2026年8月27日）
Claude Code Security — Anthropic / Claude Code公式（権限ベースの安全設計、参照日：2026年8月27日）
Claude Code Monitoring — Anthropic / Claude Code公式（OpenTelemetryのメトリクス・イベント、参照日：2026年8月27日）
Claude Code Troubleshooting — Anthropic / Claude Code公式（/doctorとclaude doctor、参照日：2026年8月27日）

結論と次の一歩

SendFeedbackの導入で大切なのは、機能をオンにすることではなく、報告案を誰が確認し、どの情報を除外し、どの経路へ送るかを明文化することです。まずは機密性の低い検証リポジトリでnotifyを試し、下書き内容を観察してください。その後、通常運用をquietにするか、組織要件に合わせてoffにするかを決めます。

今日：接続方式とデータ分類を確認し、検証対象を1グループに絞る。
今週：/feedbackのレビュー手順と機密情報チェックをチームで試す。
今月：Managed settings、社内Issue、OpenTelemetry、監査ログの責任分界を文書化する。

あわせて読みたい：

チーム導入の設定とレビュー基準を整理したい方へ

Uravationでは、Claude Codeの個別指導・導入支援を通じて、設定ファイル、権限、監査、開発フローを実際のリポジトリに合わせて整理しています。まずは自社の接続方式とデータ境界を棚卸しし、必要な支援範囲をご相談ください。

Uravationへのお問い合わせ

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。生成AIとAIエージェントの業務導入、開発支援、研修に取り組む。著書『AIエージェント仕事術』（SBクリエイティブ）。X：@SuguruKun_ai