Claude Codeの組織ポリシーを確認する

結論：statusとdoctorを同じ環境で実行し、適用状態を記録する

一次情報はAnthropic公式のv2.1.261リリースノートです。組織ポリシーの内容や管理方法は契約・管理設定に依存するため、一般的な認証エラーと混同しません。あわせて公式Claude Code settingsと、社内の管理者向け設定を公開直前にreadbackします。

診断結果を4つの層に分ける

層	確認する問い	次の判断
version	v2.1.261以降か	古い端末を先に更新・再実行
identity	誰の組織・workspaceで認証したか	アカウントと対象組織を照合
policy	Organization policyが読めたか	高リスク操作を保留し管理者へ通知
network	proxyが必要なendpointを通すか	proxyログと許可経路を確認

この表の目的は、画面に表示された一行を万能な診断結果にしないことです。例えばログインが成功していても、proxyが組織ポリシーのendpointを通していなければ、端末側で期待する制御が確認できないことがあります。未読込の理由を消して再試行するのではなく、時刻、version、端末、network pathを一緒に保存します。

切り分け手順：安全な順に7ステップ

1. Claude CodeのversionとOS、実行場所、対象repositoryを記録します。
2. 現在のログイン主体と組織・workspaceを管理者の台帳と照合します。
3. 同じ端末・同じnetworkで/statusを実行し、Organization policyの行を保存します。
4. claude doctorを実行し、policyの未読込理由と他の診断結果を分けます。
5. proxyやTLS inspectionを使う場合、対象endpointが許可経路に含まれるか管理者と確認します。
6. 設定変更後は一度に一項目だけ変え、同じ2つの診断を再実行します。
7. policyが期待どおり読み込まれたことを確認してから、read-only以外の作業を段階的に再開します。

診断ログを共有するときは、token、cookie、個人情報、repositoryの秘密情報を削除します。エラー全文をそのまま貼るのではなく、発生時刻、version、組織、proxyの変更、再現条件を最小限の記録へまとめます。解消しない場合は、認証を何度も繰り返すより管理者にendpointとpolicy配布状態を確認してもらいます。

診断結果は端末単位だけでなく、利用者・組織・ネットワーク単位でも比較します。同じ利用者が別networkで成功するならproxy経路の差を、同じnetworkで複数端末が失敗するなら配布設定やendpointの差を疑います。比較表にはversion、OS、ログイン時刻、policy表示、proxy経路、次の対応者を記載し、原因確定前に「認証不良」と断定しないようにします。

管理者側では、ポリシーの正本、配布先、更新日時、例外承認、rollbackを台帳で管理します。doctor出力は台帳の代替ではありませんが、配布した制御が端末へ届いたかを検証する観測点になります。未読込の端末だけを個別修正すると再発するため、proxy変更や設定配布の履歴と診断結果を結び付けます。

企業運用：未読込の時に止める操作を決める

組織ポリシーが権限やデータ保護の前提になっているなら、未読込を単なるwarningとして扱わない方が安全です。read-onlyの診断、ローカルの差分確認、既存テストの実行など影響の小さい作業と、外部送信、秘密情報に触れる操作、production変更を分類します。前者は管理者の確認中に許可できる場合がありますが、後者は適用状態が戻るまで保留します。

既存のログイン切り分けは認証状態、権限設定は実行操作、監査ログは判断記録を扱います。Organization policyの表示はこれらを置き換えず、適用されるべき管理制御が端末へ届いているかを確認する入口です。運用台帳には、policy未読込時のowner、停止範囲、再開条件をあらかじめ書きます。

再開の承認は「エラーが消えた」だけでなく、「どのpolicyがいつ適用されたかを説明できる」ことを条件にします。例外端末を認める場合は、対象者、期限、代替制御、再診断日時を明記し、恒久的な抜け道にしません。診断の一行を保存して終わりにせず、適用状態と高リスク操作の停止範囲を運用台帳へ反映します。

ポリシー配布の変更をリリースとして扱うなら、変更前後のstatusとdoctor、代表端末のnetwork条件、管理者の承認を一緒に残します。適用確認が取れない利用者へは、影響の小さい調査だけを許可し、外部送信や本番変更を再開しない運用ができます。障害が復旧した後も、再発時の連絡先と停止範囲を更新してください。

チェックリスト：診断を完了扱いにする条件

versionが対象範囲か／対象組織とworkspaceが一致するか／statusを保存したか／doctorを保存したか／policyの読込状態が説明できるか／proxyとTLSの経路を管理者が確認したか／秘密情報を除いて共有したか／高リスク操作の停止条件があるか／再開者と日時を決めたか、を確認します。

よくある質問

Organization policyが表示されないと使えませんか？

表示だけで可否を決めません。versionが古い可能性、認証主体、設定、proxy経路を順に確認します。組織の必須制御が前提なら、管理者が適用状態を確認するまで高リスク操作を保留します。

proxyを変えれば直りますか？

許可すべきendpointとTLSの扱いは組織ごとに異なります。推測でproxyを無効化せず、管理者と経路を確認し、一項目ずつ変更して再診断します。

診断結果をチャットへ貼ってよいですか？

tokenやrepository情報が含まれる可能性があります。秘密情報をマスキングし、必要なメタデータだけを管理経路へ共有します。

公式情報と無料診断

表示追加は公式リリースノート、設定の考え方はAnthropic公式settingsで公開直前に確認します。Miraigentの無料診断では、組織ポリシー、proxy、権限、再開条件を業務の停止基準へ落とし込めます。