AI Skillを社内配布する方法｜GitHub・Box・ZIPの安全な使い分け

AI Skillを非エンジニアを含む社内へ安全に配布し、日々の更新から停止までを管理するにはどうすればよいかという悩みがあります。全員がアクセスできる場所にファイルをそのまま置いてしまうと、作成途中の不完全なファイルを利用者が誤って使ってしまったり、誰が変更を認めたのかという記録が追えなくなったりする危険があります。

この問題を解決するには、Skillを編集・更新する場所と、利用者が受け取る配布先を明確に分けることが重要です。具体的には、編集の記録を残すGitHub、完成品を安全に配るBox、複数のファイルをまとめるZIP、そして利用者の手元へ取り込むImportという四つの役割を使い分けます。

例えば、作成者がGitHubで入力や編集を行い、人が承認した完成品をZIPファイルという生成物にしてからBoxへ置き、利用者が自分の画面でダウンロードしてImportの操作を行うという手順を整えます。

これらの手順において、プログラムに任せる範囲には安全のための制約を設けます。利用者の手元にあるAIやインストーラーは、指定されたファイルの取得、決まった場所への配置、そして正しく動くかどうかの検証だけを担います。

一方で、誰にファイルを配るかという公開範囲の決定、内容の安全性を確かめる人の承認、ファイルに含めてはいけない秘密情報の管理、そして不要になったSkillの廃止判断は、AIに代行させずすべて人が画面で確認して担います。

本記事を読むことで、これら四つの役割をどのように組み合わせるかを知ることができます。自社の状況に合う編集・更新場所や安全な配布経路、誰にどこまでの権限を持たせるか、そして新しい版への更新や問題が起きたときの復旧方法を具体的に決められるようになります。

AI Skillの編集・更新場所と配布先を分ける
GitHub・Box・ZIP・Importの役割を比較する
公開範囲と変更権限を最小化する
APIキーと実行権限をSkillから外す
版番号・更新・廃止・復旧を一つの台帳で追う
5人で試してから部署へ広げる
よくある質問
調査手法について

AI Skillの編集・更新場所と配布先を分ける

AI Skillを組織内で安全に配布し、更新や停止まで管理するには、Skillを編集・更新する場所と、利用者が受け取る完成品の配布先を明確に分けることが記事の結論です。一つの共有フォルダにすべてのファイルを置いた場合、作成中の不完全なファイルを利用者が誤って使ってしまう危険があります。

また、誰がいつ変更を加え、誰がその変更を認めたのかという記録を追うことが難しくなります。

例えば、営業提案書作成Skillを社内で配布する場合を考えます。SkillはSKILL.mdを必須とするディレクトリとして作成し、必要に応じてscripts、references、assetsを含めます。このとき、allowed-toolsという設定は実験的であり、環境によって動作に違いが出るため注意が必要です。

このSkillのディレクトリを管理して配布する際は、役割に応じて置き場所を4つに分けます。

第一に、GitHub上の編集・更新場所です。ここはSkillを作成し、編集する担当者が作業途中のファイルを保存して、変更の記録を残す場所です。

第二に、承認済みの状態を示すGitHubのRelease機能です。作成が終わった段階で人が内容を確認して承認を行います。GitHubではタグを基にリリースノートと配布資産をまとめられるため、この機能を使って完成版の配布用ファイルをつくります。

第三に、Boxなどの配布フォルダです。GitHubでつくられた完成版の配布用ファイルを、業務部門の利用者がダウンロードできるように配置します。利用者はこのフォルダから、人が承認した安全なファイルだけを取得します。

第四に、利用者のインストール先です。利用者がBoxの配布フォルダから取得したファイルを、自身のパソコンなどの環境に配置します。

このような構成において、AIやインストーラーはファイルの取得、配置、動作の確認といった作業を担います。一方で、どの範囲の利用者にファイルを公開するかという判断、完成品としての承認作業、秘密情報の管理、そしてSkillの使用を廃止するかどうかの決定は、すべて人が担います。

この構成をとることで、作成、承認、配布、利用の各段階を整理し、安全に管理対象を制御できます。

GitHub・Box・ZIP・Importの役割を比較する

AI Skillを管理する際、自社に合う仕組みを選ぶために、GitHub、Box、ZIP、そしてAI製品の機能であるImport（取り込み）の四つの役割を比較します。これらは、編集・更新、利用希望者への配布、そして実際の導入という三つの用途に割り当てられます。

GitHubは、変更の記録を残すため、作成中のファイルである編集・更新場所に向いています。

Boxは、完成したファイルを組織内で安全に配布する場所として役立ちます。BoxのEditorは編集やアップロード、削除、共有が可能であり、Viewerは閲覧とダウンロード中心の権限です。そのため、作成者がEditorとなり、利用者がViewerとなるように権限を分けることで、配布用のファイルを保護できます。

ZIPは、Skillを動かすために必要な複数のファイルを一つにまとめる形式です。利用者がBoxなどからダウンロードする際の配布の手間を減らします。

Importは、利用者が手元の環境にファイルを導入し、AIに読み込ませるための手段です。例えば、ChatGPTはSkillのアップロードや共有、インストール、管理者権限を提供しますが、デスクトップとWeb、モバイルの追加経路は分かれており、自動同期しない場合があります。

また、Claude Codeでは、個人用やプロジェクト用、プラグインなど、Skillの置き場所によって読み込まれる範囲が変わります。

これらの役割を踏まえ、自社ではどの組み合わせを選ぶかを組織の状況に合わせて四つの例で比較します。

第一に、技術チームが利用する場合です。編集・更新から配布までをGitHubで統一します。利用者はGitHubから直接ファイルを取得し、手元のAI製品に読み込ませます。AIがファイルの配置と検証を担うため、操作に慣れている利用者は手軽に最新版を導入できます。

第二に、非エンジニアが中心の部署へ配布する場合です。Skillの編集・更新はGitHubで行い、人が承認した完成品だけをZIPファイルにしてBoxへ置きます。利用者はBoxからZIPをダウンロードして解凍し、ChatGPTなどのImport画面からファイルをアップロードします。

ここでもAI製品がファイルの取得と配置、検証を担いますが、誰にBoxのViewer権限を渡すかという公開範囲や、Skillに秘密情報を含めないための管理は人が行います。

第三に、数人で短期間の試験利用をする場合です。大掛かりな仕組みを作らず、人が内容を確認して承認したZIPファイルをチャットやメールで直接渡し、各自の環境へ導入します。試験終了後のSkillの廃止判断も人が行い、不要になったファイルを利用者の環境から取り除くようにします。

第四に、複数のAI製品を使っている組織の場合です。Skillを編集・更新するGitHubリポジトリは一つにまとめ、配布用のZIPを作成します。利用者は同じZIPを受け取りますが、ChatGPTとClaude Codeそれぞれの仕様に合わせてファイルを指定の場所に配置します。

AIはファイルの読み込みと検証を行いますが、どの製品で使わせるかの判断や完成品の承認は人が行います。

このように、用途に応じて管理の対象を具体的な経路へ割り当てることで、安全で使いやすい配布体制をつくることができます。

公開範囲と変更権限を最小化する

AI Skillを配る経路を決めた後は、誤って関係のない人にファイルを公開したり、無断で内容が変更されたりすることを防ぐ設定が必要です。誰にどこまでの操作を許可すればよいか、役割に応じて権限を最小限に絞り込みます。

権限は大きく分けて、所有者、編集者、承認者、利用者の四つの役割で考えます。

Skillを編集・更新するGitHubの組織リポジトリにはRead、Triage、Write、Maintain、Adminがあり、Adminは削除を含む機密操作が可能。そのため、すべての管理を担う所有者にはAdminを割り当てます。

Skillを作成して修正する編集者には、Writeなどの限られた権限だけを渡します。このとき、編集者が独断でファイルを完成品として書き換えないように制限をかけます。GitHub rulesetはブランチやタグへの変更、削除、名称変更を制御できる。この機能を使って、完成品をまとめる重要なブランチを保護します。

編集者が設定画面から修正の提案という形で入力を行い、承認者がその内容を画面で確認して許可することで、承認された内容がGitHub上のファイルへ反映されます。

完成品を配る場所であるBoxでも、権限を分けて設定します。Boxはコラボレーターのアクセス変更、所有権移転、削除、自動期限を扱える。この特徴を活かして、配布を担当する管理者を編集ができるEditorに設定し、利用者は閲覧とダウンロードだけができるViewerにします。

利用者はViewer権限で指定のフォルダへアクセスし、配布されたZIPファイルをダウンロードする操作だけを行います。これにより、利用者が誤ってファイルを消したり書き換えたりする事故を防ぎます。

これらの仕組みにおいて、利用者の環境へファイルを配置したり、正しく動くか検証したりする作業はAIやインストーラーが自動で行います。しかし、どの範囲の利用者にViewer権限を渡して公開するかの決定、変更内容の承認、そして不要になったSkillの廃止判断は、AIに任せることなく必ず人が行います。

APIキーと実行権限をSkillから外す

利用者のアクセス権を設定するだけでなく、配るファイルの中身と、それが動いたときに影響が出る範囲を制限する必要があります。そのためには、Skillのファイルへ入れてはいけないものを知り、安全な境界を引くことが重要です。

Skillへ入れてはいけない代表的なものは、外部のシステムと連携するためのAPIキーなどの秘密情報です。もし配布するファイルの中に秘密情報を入れてしまうと、ファイルを受け取ったすべての人がその情報を使えるようになってしまいます。秘密情報の管理はAIに任せず、必ず人が行います。

Skillを編集・更新するGitHubでは、秘密情報が含まれていないかを探すsecret scanning、操作の記録を残すaudit log、そして大切なファイルを書き換えから守るブランチ保護を組み合わせることで、情報が漏れることを防ぎます。

具体例として、会社のデータを探すSkillを利用者のパソコンへ配る場合を考えます。このとき、作成したSkillのファイルには検索のやり方だけを書き、データへアクセスするためのAPIキーは含めません。APIキーは、利用者が使う手元の環境側へあらかじめ入力しておき、Skillが動くときにそれを読み込む仕組みをつくります。

さらに、ファイルを配置して動かすインストーラーやAIの操作範囲を狭くすることも大切です。これは、利用者やその代わりに動くプログラムに対し、担当する仕事に必要な最小限の権限だけを与える原則に基づきます。

安全を守る仕組みとして、インストーラーやAIには、人が画面で確認して承認したZIPファイルを指定の場所から取得すること、それを決められた専用フォルダへ新しく配置すること、そして配置したファイルが正しく動くか検証することだけを許します。

インストーラーが勝手に別のフォルダのファイルを書き換えたりする操作を制限することで、万が一のときに影響が出る範囲を抑えられます。

不要になったSkillの利用を停止するという廃止判断や、内容の承認、誰にどこまで使わせるかという公開範囲の決定は、人が行います。このように、秘密情報をファイルから外し、プログラムの操作範囲を切り離すことで、安全にSkillを利用できます。

版番号・更新・廃止・復旧を一つの台帳で追う

初回配布を安全に行った後は、全員が最新版を正しく使っているかを継続して確認する運用が必要です。そのために、版番号や更新、廃止、そして問題が起きたときの復旧を一つの台帳で管理します。

全員が最新版を使っているかを確認するために、スプレッドシートなどの台帳に記録を入力します。

例えば、版番号であるv1.2.0に対して、タグと配布資産を結び付けるGitHub ReleaseのURL、Boxに置いた同名のZIPファイル、AI製品内で共有された版、利用者が更新を確認した日、そして古い版の利用を停止した日を、一行で結んで記録します。管理者はこの台帳を画面で確認することで、配布の進行状況を正確に把握できます。

この運用において、AIやインストーラーは、指定された場所から新しいZIPファイルを取得し、利用者の環境へ配置し、期待通りに動くか検証する作業だけを担います。一方で、どの範囲の人に新しい版を公開するかの決定、内容が安全かどうかの承認、古い版を廃止する判断、そしてファイルに含めない秘密情報の管理は、すべて人が行います。

もし新しい版に不具合が見つかった場合は、安全に動いていた前の版へ戻す操作を行います。Boxは同名ファイルの更新を版として保持し、過去版の参照と復元ができるため、管理者が画面操作で一つ前のZIPファイルを復元という形で生成物として用意し、利用者がそれを再取得します。なお、Boxで保存できる版数は契約によって異なります。

このようにして、人が安全を確認したファイルだけを配布対象にすることで、運用中の事故を防ぎます。

5人で試してから部署へ広げる

台帳の準備ができたら、いきなり部署全体へ広げるのではなく、まずは少人数で最初の配布を検証します。これは、事前の設計が正しいかどうかを、実際の端末と利用者、そして不具合が起きた際の復旧操作を通じて確かめるためです。

具体例として、合計5人で試験導入を行う場合を考えます。役割は、全体の権限を管理する所有者、内容を確かめるレビュー担当、ZIPファイルを配る配布担当、そして異なるパソコン環境を持つ利用者2名です。この5人で、ファイルの取得、導入、実行、更新、そして旧版への復旧までを一通り確認します。

試験の手順として、まず所有者とレビュー担当がGitHubの画面で入力された変更案を読み、問題がないことを人が承認します。次に配布担当が、承認された内容をZIPファイルという生成物にしてBoxへ置きます。このとき、APIキーのような秘密情報がファイルに入っていないかの確認は必ず人が行います。

ChatGPTのアップロードスキャンは人のレビュー、組織ポリシー、判断を置き換えないため、機械による検査だけでなく、人が責任を持って内容を確かめる制約を設けます。

続いて、2名の利用者がViewer権限でBoxの画面を開き、ZIPファイルを取得して手元のAI製品へ導入します。この導入において、AIやインストーラーは指定されたファイルの取得、決まった場所への配置、そして正しく動くかどうかの検証だけを担います。

人の代理で動くプロセスにも最小権限を適用するという原則に沿って、プログラムが勝手に別の操作をしないよう範囲を制限します。

実行できた後は、新しい版への更新と、古い版への復旧を試します。配布担当が新しい版のZIPファイルをBoxへ配置し、利用者がそれを取得して更新されるかを検証します。その後、不具合が起きたと仮定して、一つ前の版のZIPファイルを再取得して配置し、元の状態へ戻せるかを画面で確認します。

この試験利用を通じて、誰に公開するかの決定、安全性の承認、秘密情報の管理、そして不要になった版の廃止判断という重要な役割を、AIではなく人が担えているかを確かめます。5人で一連の操作とルールの確認を終えた後、少しずつ公開範囲を広げることで、部署全体へ安全に展開できます。

よくある質問

Q1. GitHubを使わずにSkillを配布することはできますか。

数人で短い期間の試験利用をする場合などに可能です。例えば、人が内容を確認して承認したZIPファイルという生成物をチャットやメールの画面で直接渡し、各自の環境へ導入します。このとき、AIやインストーラーがファイルの取得、配置、検証を担いますが、誰に公開するかの決定や、利用後の廃止判断は必ず人が行います。

Q2. Boxだけで編集・更新と配布を行うことはできますか。

はい、可能です。管理者が編集やアップロード、削除、共有が可能なEditorとして編集・更新用のファイルを置き、利用者を閲覧とダウンロード中心のViewerに設定して画面から取得させます。Boxは同名ファイルの更新を版として保持し、過去版の参照と復元ができる機能を使いますが、どの版を完成品とするかの承認や公開範囲の決定は人が行います。

Q3. 利用者がZIPファイルを導入する際、安全性をどう確認しますか。

利用者の代わりに動くプロセスへ担当業務に必要な最小限の権限だけを与える原則に従い、AIやインストーラーには指定場所からのファイル取得、配置、動作の検証だけを許可する制約を設けます。ZIPファイルの中身が安全かどうかの確認や承認は機械に任せず、人が責任を持って事前に行います。

Q4. APIキーはどのように管理すればよいですか。

APIキーのような秘密情報は、配布するファイルには含めないという制約を守ります。ファイルの作成時に人が確認して取り除き、利用者が手元の環境へ直接入力して読み込ませる仕組みをつくります。Skillを編集・更新するGitHubでは秘密情報を探すsecret scanningなどの漏えい防止機能を組み合わせることができますが、最終的な秘密情報の管理は人が行います。

Q5. 新しい版が出たとき、利用者の環境に更新の通知は届きますか。

自動では通知や更新がされない場合があります。ChatGPTはデスクトップとWeb、モバイルの追加経路が分かれており、自動同期しない場合があります。また、Claude Codeでは個人やプロジェクトなどSkillの置き場所によって読み込み範囲が変わります。そのため、人が台帳で版を管理し、利用者が新しいファイルを取得してAIに再配置させる画面操作が必要です。

Q6. 新しい版で不具合が起きたとき、どうやって古い版へ戻せばよいですか。

台帳の記録に基づいて、一つ前の版のZIPファイルを復旧させます。Boxを使っている場合は過去版の参照と復元ができるため、管理者が画面操作で旧版を生成物として用意します。ただし保存版数は契約で異なるという制約があります。その後、利用者が手動で古いファイルを取得し、AIに配置と検証をさせます。古い版へ戻すかどうかの判断は人が行います。