スキルと​プラグインで、​社内の​作業手順を​標準化する​観点

手順を「配る」なら、先に決めることがあります

Skillを配れるようになると、個人の工夫が組織の標準になり得ます。便利な反面、「誰が書いた手順が標準になるのか」「間違いがあったとき誰が直すのか」を決めないまま配ると、古い手順や、人によって違う手順が社内に残り続けます。

ここでは、Skillとプラグインで作業手順を標準化するときの観点を、考え方として整理します。Skillそのものの説明は「毎回ゼロから説明していませんか」、なぜ共有の単位が変わったのかは「チャットボットを配る時代から、手順を配る時代へ」にあります。

何をSkillにするか：頻度と、手順の固定度で決める

最初に決めるのは、どの業務をSkillにするかです。全部を手順書にする必要はありません。基準は2つです。

図1Skill化の優先度

手順がまだ人によって違う手順を言葉で書けるよく発生する

まず手順を揃える相談から

最優先でSkill化する

たまに発生する

今は見送る

余裕があればSkill化する

「よく起きる」×「手順を書ける」から始める。書けないものは、先に人間側の手順を整える

判断基準が人の頭の中にしかない仕事は、Skillにする前に、まず「どう判断しているか」を言葉にする作業が必要です。ここを飛ばすと、AIが手順どおりに動いても、期待した出力になりません。

プラグインにまとめる単位

Skillは1つの手順です。プラグインは、Skillに加えて外部サービスへの接続などを束ねる、配布の単位です。公式のヘルプでは、Claudeのプラグインはskills・hooks・sub-agents・MCP serversをまとめたもの、ChatGPTのプラグインはskillsとappsなどを束ねたものと説明されています。

図2プラグインに束ねるもの

ひとつの業務・ひとつの役割

• Skill手順・判断基準・出力の型
• 外部サービスへの接続資料置き場や社内ツールなど、手順が触れる先
• 追加の仕組み（Claude）自動で動くhooksや、役割を分けたサブエージェント

束ねる単位は「ツール別」ではなく「業務別」。誰が何のために入れるかで決める

束ね方の目安は、「同じ人たちが、同じ業務で一緒に使うもの」です。たとえば専門商社の蒼月トレーディング（架空の会社です）の営業部なら、「商談報告の作成」という業務に、報告書の手順のSkillと、社内の案件管理への接続を一つにまとめる、というイメージです。

置き場所と配布：どこから、誰に届けるか

配布の方法も、各社が管理機能を用意し始めています。Claudeでは、組織の管理者が「Plugins & skills」から、ZIPのアップロードまたはプライベートなGitHubリポジトリとの同期で、組織専用のマーケットプレイスを作れます。ChatGPTでは、ワークスペース管理者がプラグインの導入を設定画面で管理し、Skillsは共有や公開を管理者が権限で分けられます。

図3手順が社内に届くまで

1. 01書く担当者がSkillを作る。試しに自分で使う
2. 02置く社内のリポジトリや管理画面など、決めた場所に置く
3. 人承認する内容と影響範囲を確認する人が、版を承認する
4. 04配る全員・部門別・希望者のみ、のいずれかで届ける
5. 05直す使われ方を見て、新しい版を出す

「置き場所は一つ」「承認者は決まっている」。この2点が、標準化の土台

権限と承認：誰に任せ、どこで止めるか

Skillは文章ですが、プラグインにはAIが動かす外部接続や自動処理が入ることがあります。Claudeのヘルプでも、hooksやサブエージェント、MCPサーバーは利用者のPC上で動くため、「Required（必須）」に設定する前に、管理者が内容を確認するよう案内されています。

権限で見るべき観点は、次の3つです。

• 誰が作れるか。 全員が作れてよいのか、一部の担当者だけか
• 誰が配れるか。 個人間の共有と、組織全体への公開を分けられるか（ChatGPT・Claudeともに、共有と公開の権限を分けて設定できると説明されています）
• どの接続に触れてよいか。 読むだけか、書き込みや送信までか

更新と版管理：「直した人」ではなく「承認された版」を配る

手順は、使いながら直すものです。そのため、いつの版が標準なのかを決めておく必要があります。Claudeの管理機能では、承認された版が組織で使われ、作成者がその後に編集しても、新しい版が提出・承認されるまで反映されないと説明されています。

図4標準を保つ更新サイクル

1. 01使う現場で使い、ズレや不足を見つける
2. 02直す担当者が手順を書き換えて提出する
3. 人承認する確認者が内容を見て、新しい版にする

承認された版だけが全員に届く。古い版に戻す手段も残しておく

失敗パターン：標準化がうまくいかないとき

図5よくある失敗の型

1. 01
   作りすぎて、誰も把握していないSkillが増え、同じ目的のものが重複する。一覧と担当者がいない
2. 02
   descriptionが曖昧で、呼ばれない「いつ使うか」が具体的でないと、AIが選んでくれない
3. 03
   承認者がいなくて、古いまま残る直す人はいても、確認して配り直す人がいない
4. 04
   権限を広げすぎる接続先の範囲を決めないまま、全員に必須配布する

失敗の多くは、AIの性能ではなく、運用の担当と手順が決まっていないこと

僕自身、共有用のSkillを置くGitHubリポジトリを用意して、どれを公開し、どれを手元に残すかを見直しています。標準化を進めるときは、書くことより、置き場所と範囲を決めることのほうに時間を取られる、というのが実感です。

Skillが取り違えられないようにする

Skillが増えると、次に起きるのが「取り違え」です。別のSkillが呼ばれる、呼ぶはずのSkillが呼ばれない、という状態です。

AIがSkillを選ぶときに見ているのは、各Skillの名前と description（説明文）です。公式のガイドでも、descriptionは「100個以上あり得るSkillの中から正しいものを選ぶ」ための決め手と説明されています。つまり、取り違えを防ぐ入口は、まず説明文の書き分けです。

よく聞くのが、「説明文の中にHTMLやXMLのようなタグを入れて、呼ばれ方を制御できないか」という工夫です。結論から言うと、これは頼れる方法ではありません。Anthropicの公式ガイドでは、name と description に「XMLタグを含められない」とされています。タグではなく、ふつうの文章で「いつ使う」「何には使わない」を書き分けるほうが、公式の方針に沿っています。

図6取り違えを防ぐ3つの手当て

Skillの取り違え防止

• 書き分けるいつ使うか、対象は何か、依頼者が使う言葉は何かを、説明文に書く
• 切り分ける名前の付け方、プラグイン単位、明示呼び出しのみの設定で、そもそも競合させない
• 確かめる似た依頼を何本か投げて、呼ばれ方を見る。説明文を変えたらもう一度

「呼ばれるはず」と思い込まない。似た依頼で試して、結果を見てから直す

取り違えを減らす近道は、Skillを増やしすぎないことです。1つのSkillは1つの仕事にして、似た目的のSkillは1つにまとめるか、役割をはっきり分けます。OpenAIのドキュメントにも、1つのSkillは1つの仕事に絞る、という趣旨の案内があります。