ここまで来れば、Claude Enterpriseの導入に向けた具体的な意思決定は、すでに決定済みか、あるいはパッケージ化されて担当者の手元にあるはずです。このレッスンでは、あなたの意思決定をPlutoのものと並べて見比べ、いずれか1つを変更した場合に何が連鎖的に起こるかを検討し、規制対象機能の答えがどのように一貫性を保っているかを振り返ります。
あなたの5つの答え
振り返ると、レッスン1でのPlutoの目標は、四半期末までにすべての事業部門が日常業務でClaudeを使用している状態にすること（各部門の週次アクティブ利用率で測定）であり、かつPayments & Trustからセキュリティエスカレーションが一件も発生しないことでした。右側の列（「目標との結びつき」）は、Plutoの各答えをこの目標に照らして読み解いたものです。
コンパニオンを開き、表を下へたどりながら各意思決定についての自分の記入内容を見直してください。この表は、コンパニオンの意思決定記録に、比較のためPlutoの答えを記入したものと対応しています。
| 意思決定 | Plutoの答え | 目標との結びつき |
|---|---|---|
| 1・構造とアイデンティティ レッスン4・5 | ・組織は1つ ・組織図に沿ったグループに加え、部門横断のEngineeringグループ ・専用のpayments-engグループ | 組織を1つにすることで、5つの部門すべてを1つのロールアウトと1つの利用プールにまとめられます。payments-engグループは、2つ目の組織を作ることなく、規制対象機能の設定を分離します。 |
| 2・アクセス レッスン6・7 | ・すべてのグループにClaude ChatとClaude Cowork ・Claude Codeはまず EngineeringとPlatformに（payments-engは可視性レポートが整うまで待機） ・コネクタはグループごとにスコープ設定、payments-engは読み取り専用 | ChatとCoworkをすべての部門に展開することで、Claudeがあらゆる部門の日常業務に組み込まれます。Claude Codeと書き込み権限のあるコネクタをpayments-engに対して保留することで、採用への影響を大きく抑えつつ、エスカレーションなしという制約を守ります。 |
| 3・ガバナンス レッスン8 | ・ほとんどのグループはオープンビルド、レビュー付きで共有 ・Payments & Trustは承認優先 | オープンビルドにより、通常の4部門はうまくいったものを広められます。承認優先のレビューにより、Payments & Trustのカスタマイズがエスカレーションの原因になることを防ぎます。 |
| 4・支出 レッスン9・10 | ・組織全体の上限 ・典型的な利用量に合わせたグループ上限 ・最初の利用状況レビュー後、グループ平均を大きく上回るごく一部のPlatformエンジニアに対するメンバー単位の例外設定 ・中位クラスのデフォルトモデル ・支出上限とリクエストの月次レビュー | 典型的な利用量に合わせた支出上限により、メンバーが一時停止されることなく作業を続けられるため、採用が妨げられません。月次レビューでは、支出が増加した際に上限だけでなく設定そのものを見直します。 |
| 5・可視性 レッスン11・12 | ・既存のセキュリティレビューへのCompliance API連携 ・オブザーバビリティスタックへのテレメトリ送信 ・組織全体の保持期間を、Payments & Trustが求めるより短い期間に設定 ・採用状況をグループ単位で確認 | メンバーが参加する前から記録が取られているため、Payments & Trustからの問い合わせにはエスカレーションではなく証拠で応えられます。グループ単位での確認により、四半期末までに各部門が順調かどうかが分かります。 |
あなたの答えがPlutoと異なる場合、それはあなたの組織ならではの特性が表れている部分です。その違いを、レッスン1で書いたロールアウトの目標までたどってみてください。その意思決定を説明するのが難しいと感じたら、ステークホルダーに共有する前にもう一度見直す価値があります。
連鎖を予測する
構造が最初に来て、他の意思決定はその設定を構造が定義するグループに紐づけ、可視性はそのすべてを横断して読み取ります。各設定が何であるかが分かった今、このマップにはもう1つの使い道があります。それは、ある設定を変更したときに、その下で何が変わるかを予測することです。
例えばPlutoでグループを1つ追加すると、そのグループの誰かが稼働を始める前に、サーフェスの付与（レッスン6）、コネクタのスコープ（レッスン7）、上限（レッスン9）、ダッシュボードのフィルタ（レッスン12）が必要になります。
以下のインタラクティブウィジェットは、1つの変更を意思決定マップ全体に通し、その変更がどこから始まり、どこまで波及するかを示します。
規制対象機能：5つの例外ではなく、1つの姿勢
規制対象機能を抱えている場合、このセクションは、その5つの答えが5つの別々の例外ではなく、1つの姿勢として成り立っているかを確認するものです。PlutoのPayments & Trustが、その実例です。
- 構造：そのメンバーは専用のグループに属しているため、ユニオンルールにより、自分のグループのロール以上の権限は付与されません（レッスン5）。
- アクセス：隣接するグループと同じサーフェスですが、Claude Codeは可視性レポートが整うまで保留され（レッスン6）、コネクタは読み取り専用です（レッスン7）。
- ガバナンス：承認優先です。一方、Plutoの他の部分は自由にビルドし、グループ内で共有しますが、それを超える範囲にはレビュー担当者が付きます（レッスン8）。
- 支出：他のグループと同様のサイズのグループ上限で、増額リクエストはすべて承認前に確認されます（レッスン9）。
- 可視性：Plutoの組織全体の保持期間が短い方に設定されている理由はこのグループにあり、Compliance APIが有効で、セキュリティレビューには指名された閲覧者がいます（レッスン11）。
これらの項目を、コンパニオンの中で1つのまとまりとして読み直してください。特別な仕組みを持たず、通常のシステムを通じて扱われる1つのグループ――それがうまくいく理由です。組織全体が規制対象である場合、このまとまりがあなたのベースラインになります。
リソースを整える
ある意思決定についてキックオフ前にもう一度確認が必要なとき、このコースのすべての設定の背後にある記事は、次の2つのコレクションのいずれかにあります。
- Team and Enterprise plans（新しいタブで開きます）：Team・Enterprise管理者向け記事の全セットで、どの意思決定についても読み直すことができます。
- Admin management（新しいタブで開きます）：今あなたが見直している設定の背後にあるハウツー記事です。
レッスンの演習
あと3つのステップで、コンパニオンをステークホルダーキックオフに持っていくロールアウト計画へと仕上げます。
- 元に戻しにくい設定を見直す： コンパニオンのレッスン13チェックリストにある4項目（ドメインの所有権確認、組織の数、グループマッピング、保持期間）それぞれについて、決定済みか、決定期限付きで担当者の手元にあるかを確認してください。
- 未解決の項目を片付ける： まだ未解決の意思決定それぞれについて、何が障害になっているか、解消するために何が必要か、決定期限はいつかを書き出してください。担当者の名前だけでは計画とは言えません。これらのいずれもない未解決項目は、ロールアウトが止まる原因になります。
- 計画の順序を決める： コンパニオンには順序（構造、次にアクセス、ガバナンス、支出、可視性を有効化し、その後グループ単位で本番稼働）が記載されています。各ステップに担当者と開始日を設定してください。
→ これをワークアロードコンパニオンのレッスン13セクションに記録してください。
ダウンロード
次は何か
最後のレッスンでは、新しいサーフェスが登場したときに何が起こるか――どの答えがそのまま引き継がれ、どの意思決定をもう一度やり直す必要があるか――を扱います。