読み込み中
このレッスンの内容このレッスンを終えると、次のことができるようになります
  • 組織全体およびロールごとに、モデルのデフォルトとエフォートの上限を設定する
  • ロールを通じてグループにサーフェスを付与する
  • 各グループがどのサーフェスを利用できるか、いつ段階的に導入するかを決定する

これは5つの決定事項のうち2番目、「アクセス」です。グループの作成は完了しました。次に、さまざまなClaudeサーフェスへのアクセスをグループに付与します。サーフェスとは、メンバーがClaudeを利用する場所のことで、Claude Enterprise契約には複数のサーフェス(例:Claude chat、Claude Cowork、Claude Code、Claude for Microsoft 365)が含まれる場合があります。

ほとんどのClaude Enterprise契約では、契約が対象とするすべてのサーフェスを組織側でオンにできます。その後、誰が利用できるかはロールによって決まります。組み込みロールのメンバーは、オンになっているすべてのサーフェスを利用できますが、カスタムロールのメンバーは、付与された場合にのみサーフェスを利用できます。ここでの作業は、すべてを一度にオンにするのではなく、ロールアウト戦略が求めるタイミングでサーフェスがグループに届くように、誰にどれを、いつ付与するかを決めることです。この決定の前に、2つの仕組みを理解しておく必要があります。付与がどのようにグループに届くか、そしてこれらのサーフェスが動作するモデルです。

アクセスの付与方法

グループがサーフェスを利用できるかどうかは2つの層によって決まり、両方が許可している必要があります。

  • 組織全体のトグルが上限となります: 各サーフェスには組織全体に対するオン/オフの切り替えがあります。オフの場合、ロールが何を許可していても、誰もそのサーフェスを利用できません。
  • ロールへの付与が、その上限の下で誰がアクセスできるかを決めます: サーフェスが組織全体でオンになったら、それを利用すべきグループに紐づくロールに付与します。サーフェスをグループのロールに付与すると、そのグループのカスタムロールのメンバー全員がそれを利用できるようになります(レッスン5)。ロールに付与しなければ、そのグループはそのサーフェスへのアクセスを得られません。

以下のインタラクティブ ウィジェットは、この連鎖を端から端まで示しています。メンバーはグループに属し、そのグループに適用されたロールがアクセスをオンにします。

読み込み中

Claude Codeも他のサーフェスと同じ付与の仕組みを取ります。組織全体でオンにし、それを利用するグループのロールに付与します。ただし、エンジニアリング環境内で動作するため、他のサーフェスにはない境界設定も伴います。

これらの境界はClaude Codeのマネージド設定に存在し、通常はあなたではなく、各チームのリポジトリを把握しているプラットフォームリードやエンジニアリングリードが記述します。そのため、Claude Codeをグループに付与する際は、どのグループに付与するかをあなたが決め、プラットフォームリードがグループごとにアクセス可能なファイル、コマンド、ネットワーク接続先を設定します。これらのマネージド設定では、Claude Codeのデフォルトモデルを固定することもできますが、利用可能なモデル自体は、組織設定のModelsページで引き続き管理されます。

モデル:グループの会話が動作する基盤

対応するすべてのサーフェスにおいて、新しい会話はすべてデフォルトモデルで開始され、そのデフォルトはあなたが管理します。初期設定ではAnthropicのデフォルトに従い、モデルのリリースや廃止に伴って更新されます。選択したモデルが特定の製品で利用できない場合、その製品は推奨モデルにフォールバックします。

自分でデフォルトを設定するには、組織のデフォルトを選択します。

  • 変更するまで、モデルのリリースを経ても維持されます。Owner、Primary Owner、またはIdentity & Access権限を持つカスタムロールが設定できます。
  • メンバーは自分の会話内でモデルを切り替えることができます。その選択は、組織のデフォルトを変更するまで次の会話にも引き継がれ、変更するとその選択はリセットされます。
  • カスタムロールは独自のデフォルトモデルを持つことができ、そのメンバーに対しては組織のデフォルトを上書きします。
  • 組織またはロールに対して、デフォルトモデルと併せてデフォルトのエフォートレベルを設定でき、ベータ設定により新しい会話はすべてそれらのデフォルトで開始されます。

また、メンバーが利用できるモデルと、選択できるエフォートの量を制限することもできます。エフォートとは、モデルが応答にどれだけの作業量を費やすかを表し、エフォートが高いほど消費するトークンも多くなります。どちらの制限も2つのレベルで機能します。組織全体では、各モデルを全員に対してオン/オフし、全メンバーに適用されるエフォートの上限を各モデルに設定します。カスタムロールは、そのモデルの上限を超えて許可することはできません。ロールごとには、さらに絞り込むことができます。カスタムロールにモデルのサブセットを与えると、そのメンバーはピッカーにそれらのモデルのみが表示されます(Haikuモデルは常に利用可能で、オフにすることはできません)。また、各モデルで選択できる最高エフォートレベルに上限を設定できます。ロールレベルの制限はカスタムロールにのみ適用されます(レッスン5)。モデルの選び方とモデルのエフォートに関するリソースは、Claude Academyで確認できます。

組織のモデルデフォルトを更新したり、モデルを制限したりする主な理由は2つあります。

  • 支出: モデルはトークンの使い方が異なるため、実行コストも異なります。最も高性能なモデルは、通常、日常的な作業を行うには最もコストがかかる選択肢です。ヘルプセンターの記事「利用量と長さの制限の仕組み」では、これらの制限がプランやモデルによってどう異なるかを解説しています。ほとんどのメンバーは新しいタスクを開始する際に表示されるモデルをそのまま使うため、デフォルトが支出の大部分を左右し、モデル制限はグループがやり取りごとに使える支出の上限を定めます。レッスン10では、両方を支出レバーとしてさらに詳しく扱います。
  • タスクへの適合性: 例えば、コーディングチームは最も高性能なモデルを出発点とすることでより多くの成果を得られる一方、日常的な文書作成を行うチームにはそこまでの性能は必要ないかもしれません。デフォルトはロールごとに設定できるため、各グループはその業務に適したモデルから開始でき、制限によって、大きな恩恵を得られないグループのピッカーからコストの高いモデルを除外できます。

Plutoのサーフェス

Plutoの目的は日常的な幅広い利用であるため、すべてのグループにClaude chatとClaude Cowork を付与します。Claude Codeは、日常業務がコードを書くことであるEngineeringとPlatformに付与されます。Payments-engは、Plutoの可視性レポートが整うまでClaude Codeを待つことになり、これによりPlutoの制約——Payments & Trustからのセキュリティエスカレーションを発生させない——が維持されます。残りのサーフェスは、業務上の必要に応じてグループごとに段階的に導入されます。

以下のインタラクティブ ウィジェットは、Plutoのグリッドを段階的に埋めていき(まず幅広いサーフェス、次に専門的なサーフェス)、まだオンにできない1つの付与のところで止まり、その理由を示します。

読み込み中

1 · あなたの決定事項

各グループはどのサーフェスを利用できるのか、そしていつ段階的に導入するのか?

2 · 選択できる選択肢

この決定は機械的なルールというより、判断によるものです。主な考慮事項は2つあります。

  • そのサーフェスがグループの日常業務を変えるかどうか: 契約がたまたまカバーしているものではなく、グループが必要とし、実際に使うものに基づいて付与します。
  • ロールアウトの目的がサーフェスの保留を求めているかどうか: メンバーにアクセスを与える前に1つのチームでClaudeを試験導入する場合や、グループがサーフェスを得る前にレビューを待つ場合などです。
選択肢選ぶべき場面意味と影響
まず幅広く、必要な場合に専門的なものをロールアウトの目的がサーフェスの保留を求めておらず、専門的なサーフェスを必要とするのが一部のグループの日常業務だけである場合。ほとんどのメンバーが最初の価値を得られる汎用サーフェスを付与します。専門的なサーフェスを保留することで、決して使わないグループのために境界設定を行う手間を省けます。
試験導入してから拡大するロールアウトの目的が、メンバーにアクセスを与える前に1つのチームでClaudeをテストすることを求めている場合。試験導入グループのみにサーフェスを付与し、そこから拡大します。試験導入から得られた学びが幅広いロールアウトの形を決め、他のグループは目的が拡大を指示するまで待ちます。
レビューの後に段階的導入制約(ロールアウトの目的の後半部分)により、グループはレビューが完了するまでサーフェスを待たなければならない場合。付与は単にレビュー完了後に段階的に導入されます。グループはその時点でサーフェスを得ます——グループが待っている間、制約は維持されたままです。

3 · 後で変更する場合

後からサーフェスを付与するのは簡単です。いつでも追加できるロール設定だからです。コストがかかるのは逆方向、つまり取り上げることです。あるサーフェスを中心にワークフローを構築してきたグループは、作業の途中で頼りにしていたツールを失うことになり、それを取り消すことは、そのメンバーと共に管理しなければならない変更になります。

セットアップ リソース

決定を下したら、組織のロールを通じて各サーフェスを付与します。Claude Codeを付与するグループについては、同時にプラットフォームリードを巻き込み、アクセスが付与されるタイミングで境界設定も準備できているようにしてください。

レッスン演習

各グループについて、初日に利用できるサーフェスと、後で段階的に導入するサーフェス、そしてその理由を記録してください。Claude Codeを付与するすべてのグループは別途リストアップしてください。その付与には、プラットフォームリードのための境界設定タスクが伴います。

プラットフォームリードと予算責任者に持っていくべきもの: プラットフォームリードには、Claude Codeを付与するグループのリストと、各グループのコードが触れる範囲を。予算責任者には、ロールごとのデフォルトモデルを設定する場合の事前通知を。これが支出設定(レッスン10)の出発点となるためです。

→ これをワークアロング コンパニオンのレッスン6セクションに記録してください。

ダウンロード

  • Work-along companion (Word)

    The editable Word version of the rollout plan you fill in lesson by lesson.

    ダウンロード
  • Work-along companion (PDF)

    The same rollout plan as a fillable PDF.

    ダウンロード

次のステップ

これでグループはサーフェスに到達できるようになりました。次の問いは、Claudeがメンバーに代わって何にアクセスできるかです。つまり、組織のツールから読み取り、操作を行うことを可能にするコネクタです。次のレッスンでは、コネクタがメンバーに対して機能するかどうかを決める3つのゲートと、ツールごとに決める価値のある1つの制御——読み取り専用か読み書き可能か——について扱います。