「Claude Codeを会社として導入したい」と決めた直後に止まるのは、技術の良し悪しではなく論点の多さだ。契約はTeamかEnterpriseか、権限はどこまで絞るか、顧客のコードを扱っていいか、情シスへの説明はどう書くか、展開は誰から始めるか——これが同時に湧いて、どこから手をつけるべきか分からないまま止まる。公式ドキュメントは管理者向けに、導入時の決定事項を順序立てて整理している。この順序に沿って、何を決め、どこで判断に迷いやすいかを整理する。

全体像：公式が示す5つの決定事項

公式ドキュメントは、組織がClaude Codeを導入する際の決定を次の順序で並べている。

決定事項決めること
①APIプロバイダの選択どこで認証し、どう課金されるか（Team/Enterprise・Console・クラウド経由）
②設定の配布経路組織のポリシーを開発者の端末へどう届けるか（管理コンソール・MDM・ファイル配布）
③何を強制するか許可する/禁止するツール・コマンド・MCPサーバー、サンドボックスの範囲
④利用状況の可視化利用量・コストをどう追跡するか
⑤データ取り扱いの確認保持期間・学習利用の有無・コンプライアンス体制

①はTeam・Enterpriseの選び方で、②③は権限設計の記事で、④は効果測定の記事で、⑤は稟議で聞かれる4つの質問と情報漏洩対策チェックリストでそれぞれ深掘りしている。この5つは技術的な設定項目の決定順序であって、「導入プロジェクトとして何をすべきか」の全体像ではない点に注意がいる。公式は別途Claude Enterprise Administrator Guideという導入・展開のプレイブックも用意しているが、こちらは本セッションでは内容を直接確認できていない。

技術的な5決定の外側に、実際にはもう2つの論点が入ってくる。誰から使い始めるか（管理者主導と現場主導、どちらで進めるか）と、導入後に誰が設定・ルールを更新し続けるか（「定着しない」理由はオーナー不在にある）だ。公式ドキュメントの5決定はどれも「一度設定すれば終わる」技術的な作業だが、この2つは継続的な人の仕事で、技術設定を全部終えても自動的には埋まらない。

適用条件と例外：会社の形で優先順位が変わる

5つの決定事項に取り組む順序は、会社の状況によって変わる。

社内に統制の要件（SSOでのアクセス即時遮断、監査ログの保存義務など）が既にある会社は、①のプロバイダ選択で実質的にEnterprise一択になり、残りの検討は「何を強制するか」の設計に重心が移る。

2〜10人規模の受託開発企業は、①はTeamでほぼ即決できる一方、顧客のコードを扱う以上、顧客のコードをClaude Codeに読ませていいかの整理が公式ドキュメントの5決定には出てこない固有の論点として先に来る。

既存のAWS・GCP・Azure契約でコンプライアンス体制を揃えている会社は、①がBedrock・Google Cloud’s Agent Platform・Microsoft Foundry経由になり、公式ドキュメントも明記しているとおり、Claude Code on the WebやRemote Controlなど一部機能だけはクラウド経由の認証情報では使えずTeam/Enterpriseの席が別途要る、という例外が生じる。

例外として、5決定を全部終えても解決しない論点がある。 利用規程の文面（生成AIの利用規程に何を書くか）や、組織の判断基準そのものを言語化したCLAUDE.md（ハーネスとは何か）は、公式ドキュメントが扱う技術的な設定項目の外側にあり、自社で作る以外にない。

自社で判断する基準

5つの決定事項を順に検討するより先に、まず2つを自問した方が近道になる。統制機能（SSO・監査ログ・管理設定の一括配布）が今の時点で必須か——必須ならEnterprise、そうでなければTeamか個人契約の検証から始められる。もう一つ、顧客のコードや社外秘情報を扱う前提か——扱うなら契約形態の検討と並行して、データの保持期間とZero Data Retentionの対象範囲を先に確認しておく必要がある。

この2つの答えが出れば、残りは公式ドキュメントの順序どおりに決めていける。ただし、技術的な設定が終わった時点で「導入した」と見なさないことが重要だ。展開の進め方と、導入後の継続運用の担当——この2つは公式ドキュメントの決定事項には含まれない、会社側で引き受けるしかない仕事として最後まで残る。

自社の状況でどこから着手すべきか整理したい場合は、パイロット・構築のフェーズで一緒に検討できる。まずは30分の無料診断から相談してほしい。