カスタマイズのガバナンス

これは5つの意思決定のうち3番目、ガバナンスです。Claudeが到達できる範囲はすでに決定しました。ここからは、Claudeの動作を変えるカスタマイズと、その変更が組織全体にどのように波及しうるかについて学びます。Skills、共有セットアップ、そして組織がClaudeに与える常時有効なガイダンスは、いずれも異なる階層で同じ1つの問いに答えるため、ここに位置づけられます。すなわち、あるメンバーが設定した内容のうち、どれだけが他のメンバーに届くのか、という問いです。

ユーザーのカスタマイズと組織の指示

このレッスンでは、3種類のカスタマイズを取り上げます。以下のセクションでそれぞれを詳しく説明したうえで、それらがどこまで広がるかを左右する方針（誰が作成・共有・拡大できるかを定める組織のルール）を取り上げます。

1. Skills とプラグイン

   Skillとは、タスクに応じてClaudeが読み込む、指示・スクリプト・リソースをまとめたフォルダです。実際には、ワークフローをパッケージ化することで、Claudeが毎回同じように実行できるようにします。たとえば、法務チームが自分たちのプレイブックに沿って実行する一次契約レビュー担当者、自社の文体で書く要約フォーマッター、あるいは自社のテンプレートに沿ったインシデント事後分析などです。Skillがあれば、Claudeはすでに自社の慣習を把握しているため、会話のたびに誰かがそれを説明し直す必要はありません。

   プラグインは、Skillを他のコンポーネント（コネクタ、サブエージェント）とバンドルし、ツールキット全体を一度にインストールできるようにします。Skillとプラグインは同じ方針の対象となるため、このレッスンの以降では、このファミリーをまとめて「カスタマイズ」と呼びます。プラグインは、メンバーが所属するグループに含まれていないコネクタや機能を付与することはできません。あくまで、すでに存在するものを組み合わせて動作します。

2. プロジェクト

   プロジェクトとは、独自のコンテキストとファイルを持つワークスペースであり、そこで作業するすべてのメンバーに対して永続します。プロジェクト共有の設定は、あるメンバーが構築したプロジェクトを組織内の他のメンバーと共有できるかどうか、そしてどの範囲まで共有できるかを決定します。「パブリックプロジェクト」をオフにすると、すべてのパブリックプロジェクトが非公開になり、そのプロジェクトに追加されていなかった人はアクセスできなくなります。新たにプロジェクトを公開することは誰にもできなくなりますが、特定の個人やグループとの共有は引き続き可能です。グループとのプロジェクト共有はベータ版であるため、表示される粒度は組織によって異なる場合があります。この設定自体が方針の選択となります。

3. 組織の指示

   組織の指示とは、対応するサーフェス上でメンバーとClaudeとの会話に含まれる一連のガイダンス、すなわち組織の常時有効なコンテキストです。これを使って、Claudeに恒常的な事実や恒常的な指示を与えることができます。たとえば、自社が何者でどのような組織構造を持つか、顧客向け文章のトーン、あるいはClaudeが社内資料を引用する際には必ず出典文書を明記するといった、すべてのセッションに適用されるルールなどです。Plutoの例は、このレッスンの後半で紹介します。

カスタマイズにガバナンスが必要な理由

カスタマイズを共有できることは、メンバーがClaudeを使って作業する体験に実質的な価値をもたらします。あるメンバーが構築したSkillは、チームがすでに実践しているワークフローを形式化できるため、より統一された形で広がり、多くの場合、より速く、より高品質になります。メンバーはまた、Claude以前には存在しなかったワークフローを構築し、それを組織全体に拡大することもできます。

その裏返しが乱立です。ガバナンスがなければ、組織には数十もの似たようなSkillが乱立したり、レビュー済みだと思い込んだチームに未検証のワークフローが広がったり、プロジェクトを組織全体に共有したことで機密データがアクセス可能になったりする恐れがあります。ガバナンスとは、この広がりを意図的なものに保つための仕組みであり、誰にカスタマイズの作成と拡大を許可するかを決めることこそがその核心です。

ガバナンスは、突き詰めると3つの問いに集約されます。

1. カスタマイズは実行時に何を行うことが許されるのか？
2. 誰がそれを作成でき、誰がそれを使用できるのか？
3. それを構築したメンバーから他のすべての人へ、どのように広がっていくのか？

カスタマイズは実行時に何ができるか

Skillが実行時に何を行えるかは、機能（capability）に依存します。コードを実行するSkillもあれば、ウェブを検索するSkill、ファイルを読み込むSkillもあります。Skillは、それが必要とする機能がオンになっている場合にのみ実行されます。そのため、ある機能を有効にする際は、その機能と、それを必要とするチームが頼りにするSkillの両方のトグルを合わせて確認してください。Skillにはコード実行が必要です。組織設定で「Cloud code execution and file creation」設定（一部のコンソールでは依然として「Code execution and file creation」と表示されます）と「Skills」の両方をオンにしなければ、メンバーはそもそもSkillを使用できません。Skillが依存する機能を組織全体でオフのままにしておくと、財務チームが求めるSkill（たとえばリサーチ要約ツール）はまったく利用できなくなります。

誰が作成・使用できるか

メンバーがSkillを作成・使用できるかどうかは、組織全体の設定です。これは、特定のグループに紐づくのではなく、グループの上位に位置づけられる数少ない設定の1つですが、カスタムロールの「Create skills」機能が誰が構築できるかを決め、その共有機能が誰が共有できるかを決めます。ただし、配布はグループに紐づけることができます。プラグインにバンドルされたSkillは特定のグループに割り当てることができ、そのグループだけがそれを見ることができます。

他のメンバーへどのように広がるか

Skillがどのように広がるかは、4つの独立した配布コントロールによって統制されており、これらが方針を構成します。

1. Owner provisioning（オーナーによるプロビジョニング）：Ownerがアップロードしたスキルは、すべてのメンバーのSkill一覧に届き、デフォルトで有効になります（メンバーは自分用にオフに切り替えることができます）。これらを追加・削除できるのは、Owner、およびロールの「Libraries」が「Can manage」に設定されている人のみです。
2. Skill sharing（Skill共有）（組織がSkillの設定を行っていない限り、デフォルトでオン）：メンバーは、自分が作成したSkillやプラグインを特定の同僚と直接共有でき、共有された側はそれを使用できますが編集はできません。
3. Share with groups（グループとの共有）（デフォルトでオフ）：メンバーは、「Share resources with this group」がオンになっているグループ全体に対して、Skillやプラグインを共有できます。
4. Publishing（公開）（「Off」「Requires review」「Open」のいずれか）：メンバーはSkillやプラグインを組織ライブラリに提出し、そこから組織全体に届く可能性があります（レビュー時に、承認者が全員に届けるか特定のグループに届けるかを選択します）。「Off」の場合、メンバーは提出できませんが、Ownerは組織全体向けにSkillを直接追加できます。「Requires review」の場合、各提出とその後の各バージョンは、Owner、またはロールの「Libraries」が「Can manage」に設定されている人による承認を待ちます。自分自身の提出を承認することは誰にもできません。「Open」の場合、提出はレビューなしで公開できます。組織内で誰もPublishingの値を選択していない場合はデフォルト値が適用されます。デフォルト値はすべての組織で同じではないため、自社がどの値になっているか確認してください。

Plutoのガバナンス

Plutoは分割された方針を運用しています。ほとんどのグループのメンバーは自由に構築し、グループ内で共有しますが、グループを超えて広がるものはすべて、そのグループの指名されたレビュー担当者を経由します。Payments & Trustはより厳格に運用されており、そこで構築されたものは承認されるまで一切共有されません（承認先行）。これはPlutoがレビュー担当者とポリシーを通じて徹底しているルールです。カスタムロールを使えば、1つのグループのメンバーについてSkill共有とプロジェクト共有をオフにすることもでき、このようなルールの一部を製品側に持たせたい場合に利用できます。Plutoの組織の指示には、Pluto自身、その5つの事業部門、そして顧客向け文章における自社のハウススタイルが明記されています。内容は次のとおりです。「あなたはPlutoを支援しています。Plutoは5つの事業部門（Retail、B2B、Payments & Trust、Platform、Ops）を持つフィンテック企業です。顧客向けの文章は、Plutoのハウススタイルに沿って、平易かつ簡潔にしてください。」

以下のインタラクティブウィジェットでは、1つのSkillが構築・レビュー・公開のループをたどる様子を確認できます。方針を切り替えて（ほとんどのグループ向けのPlutoの自由な構築とレビュー済みの拡散、Payments & Trust向けの承認先行）、レビューゲートがどこに位置するかを確認してください。

1 · あなたの意思決定

カスタマイズの方針：メンバーはどれだけ自由にSkill、プラグイン、プロジェクトを作成・共有できるのか、そして1つの方針が組織全体をカバーするのか？

2 · 選択できる方針

ここでは、ほとんどの企業が共有する単一の方針というものは存在しません。方針は、自社がすでに自社の人材が構築するツールをどのように扱っているかに沿ったものになります。ほとんどのケースは、次の3つの方針でカバーできます。

3 · 後で変更する場合

ほとんどの方針設定は自由に元に戻せます。1つを変更すれば、その時点から適用され、取り消し作業は発生しません。ただし、2つの方向性は対等ではありません。緩めることは無償です。構築と共有をより多く許可すれば、メンバーの裁量が広がります。厳しくする方向は慎重に扱うべきであり、2つの設定は正反対の挙動を示します。「パブリックプロジェクト」をオフにすると、すでに存在するものにも影響が及びます。パブリックプロジェクトは非公開になり、後でオンに戻しても非公開のままです。一方、Publishingをより厳格な設定にしても、すでに公開されているものは削除されず、Ownerが削除するまで組織ライブラリに残り続けます。そのため、よく使われているSkillを新しいルールに照らして見直し、基準を満たさないものは削除してください。

設定リソース

決定を下したら、作成・共有の設定、コード実行、プロジェクト共有、組織の指示は、いずれも組織設定（Organization settings）にあります。

• Skillとは何か？：方針を設定する前に知っておくべき、メンバー側から見たSkillの内容と動作。
• 組織向けにSkillをプロビジョニング・管理する：Skillの作成、有効化、統治方法。ここで設定する組織全体の共有設定とPublishing設定を含みます。
• プロジェクトとは何か？：プロジェクトが何であり、何を保持するか。どこまで共有すべきかを判断するための情報です。
• プロジェクトの公開範囲と共有を管理する：組織設定にあるプロジェクト共有の設定。
• 組織のプロジェクト共有を制御する：「Share projects」や「Public projects」をオフにすると何が起こるか、そしてロールごとにプロジェクト共有を設定する方法。
• 組織の指示を設定する：指示がどこにあるか、誰が設定できるか、そして文字数制限について。
• Claude Enterprise consumption guide：組織の指示に関するセクション。すべての会話が持つ恒常的なガイダンスについて。
• 組織でClaude Coworkを使ってワークフローを拡大する：拡大された共有が実際にどのようなものかを、Claudeチュートリアルライブラリから紹介します。

レッスンの演習

ガバナンスオーナーとセキュリティ責任者に持参すべきもの：選択した方針、カスタマイズが組織全体に広がる前のレビュー担当者とその対象グループ、そしてコード実行を誰に対してオンのままにするか。方針の設定が自分一人の裁量でない場合、これが彼らへの説明資料になります。

方針を記録する前に、すでに答えられる3つの問いに照らして確認してください。

1. 3つの方針のうち、自社が現在、自社の人材が構築するツールをどのように扱っているかに最も合致するのはどれか。また、規制対象のグループで、他よりも厳格な方針が必要なところはあるか？
2. 方針にレビューゲートがある場合、レビュー担当者は誰で、どのグループを対象とするか？
3. 組織の指示には何を記載すべきか。自社が何者であるか、そしてClaudeが従うべき基準について、すべての会話が持つべき2〜3行とは何か？

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

次のステップ

これで、メンバーは設定した範囲内でカスタマイズを構築・共有できるようになりました。次のモジュール「Spend（支出）」では、その活動にかかるコストに焦点を当てます。組織全体で支出上限がどこに設定されているか、そしてメンバーがその上限に達したとき、誰がそれを管理するのかを扱います。