AI エージェントを社内に入れてみたものの、担当者が変われば出力の質が変わり、同じ作業をするたびに長い指示文を書き直している。多くの企業がこの段階で足踏みしています。ツールは導入できたのに、業務のやり方そのものは以前と変わっていない、という状態です。
こうした場面で名前が挙がるのが「エージェントスキル(Agent Skills)」です。ただ、いざ調べてみると出てくるのは SKILL.md の書き方やコード例ばかりで、「では自社は何をすればいいのか」に変換できません。役員から「うちでも使えないのか」と聞かれても、効果があるのかどうか、社内で作れるのか外部に頼むべきなのか、判断材料が手元にないまま止まってしまいます。
この行き詰まりは、仕組みの理解が足りないから起きているわけではありません。「エージェントスキルが効く課題と効かない課題の切り分け」と「内製と外注の線引き」という2つの判断軸がセットで揃っていないことが原因です。この2つさえ持てれば、投資判断も発注依頼も自分の言葉で組み立てられるようになります。
本記事では、エージェントスキルの定義と仕組みを非開発者にも通じる言葉で整理したうえで、MCP との役割の違い、効果が出る業務パターンと出ない業務パターン、内製・外注を分ける5つの判断軸、外注時の依頼範囲と納品物、そして企業導入で押さえるべきセキュリティ・ガバナンスまでを解説します。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
エージェントスキルとは?AIエージェントに業務手順を持たせる拡張機能
エージェントスキル(Agent Skills)とは、AI エージェントに特定の業務の進め方を覚えさせるための、フォルダ単位のパッケージです。指示文・メタデータ・任意の補助リソース(スクリプトやテンプレート)を1つのフォルダにまとめておき、AI エージェントがその作業に関係する場面に遭遇したときだけ自動的に読み込んで使います(Anthropic 公式ドキュメント「Agent Skills」)。
イメージとしては、新しく入ったメンバーに業務マニュアルを渡す行為に近いと考えると理解しやすくなります。マニュアルは常に読ませ続けるものではなく、その作業に取りかかるときに開いてもらえばよい。エージェントスキルも同じで、必要になったときにだけ参照される「業務手順書の束」として機能します。
重要なのは、これがモデルそのものを賢くする技術ではないという点です。エージェントスキルが与えるのは、賢さではなく「その会社ならではの手順・判断ルール・出力の型」です。汎用的な能力を持った AI エージェントを、自社業務のスペシャリストに寄せていくための仕組み、と捉えるのが実態に近い理解になります。
エージェントスキルの中身は「SKILL.md」というテキストファイル
エージェントスキルの中核は、SKILL.md という1枚の Markdown ファイルです。ファイル冒頭に YAML 形式のメタデータ(スキルの名前と、何をするもので、いつ使うのかの説明)を書き、その下に手順を文章で書いていきます。必要に応じて、参照資料の Markdown ファイル、実行用のスクリプト、テンプレートなどを同じフォルダに同梱できます。
構成をおおまかに書くと次のようになります。
契約書レビュー/
├── SKILL.md # 必須:メタデータ + 手順
├── references/ # 任意:参照資料(社内規程、判断基準など)
├── scripts/ # 任意:実行スクリプト
└── assets/ # 任意:テンプレート、書式サンプル
ここで押さえておきたいのは、中身の大半が「人間が読んで分かる日本語の文章」で成立するという点です。プログラムを書く必要は必ずしもありません。業務手順書を書ける人であれば、内容そのものは書けます。この性質が、後述する内製と外注の線引きに直接効いてきます。
Claude専用ではない — AIエージェントの拡張機能としてのオープン標準
導入を検討するとき、多くの担当者が最初に気にするのが「特定ベンダーに縛られるのではないか」という点です。エージェントスキルはもともと Anthropic が Claude 向けに開発した仕組みですが、その後オープン標準として仕様が公開され、Claude 以外の AI エージェントでも利用できる形になっています(gihyo.jp「Anthropic、エージェントスキルをオープンスタンダードに」)。
仕様は agentskills.io で公開されており、同サイトの対応クライアント一覧には Cursor、VS Code(GitHub Copilot)、Gemini CLI、ChatGPT / Codex、OpenCode といった各社のツールが並んでいます。同サイトも「Anthropic が開発した形式をオープン標準として公開し、多くのエージェント製品に採用されている」と説明しています。
つまり、エージェントスキルとして書き起こした業務手順は、特定の AI ツールの中に閉じた資産にはなりません。ツールを乗り換えても、書いた手順そのものは持ち運べます。この「作った資産が残る」性質は、投資判断の材料として役員に説明する際の要点になります。ロックインを恐れて着手を遅らせるより、手順を言語化して蓄積し始めるほうが、資産としての価値は積み上がりやすいと考えられます。
エージェントスキルの仕組み|段階的開示による3階層の読み込み

エージェントスキルの設計上の要点は「段階的開示(progressive disclosure)」と呼ばれる読み込み方式にあります。必要になるまで情報を読み込まないことで、スキルを何十本増やしても AI が扱える情報量(コンテキストウィンドウ)を圧迫しない、という考え方です。
「マニュアルを何百ページも渡したら、AI が処理しきれなくなるのでは」という懸念は、この仕組みによって解消されます。ここを理解しておくと、「どこまでスキルを増やしていいのか」という運用判断ができるようになります。
レベル1〜3で読み込みタイミングが変わる
公式ドキュメントでは、スキルに含まれるコンテンツを3つのレベルに分け、それぞれ読み込まれるタイミングが異なると説明されています。
レベル | 内容 | 読み込まれるタイミング | 消費するトークン量の目安 |
|---|---|---|---|
レベル1:メタデータ | スキルの名前と説明(何をするか/いつ使うか) | 起動時に常に読み込まれる | 1スキルあたり約100トークン |
レベル2:指示 | SKILL.md 本文の手順・ガイダンス | そのスキルが呼び出されたときのみ | 5,000トークン未満 |
レベル3以上:リソース | 参照ファイル・スクリプト・テンプレート | 必要になったときのみ | アクセスされるまでゼロ |
(出典: Anthropic 公式ドキュメント「Agent Skills」)
読み解くうえで重要なのは、レベル1の約100トークンという軽さです。常時読み込まれるのは名前と説明だけなので、スキルを多数用意しておいても、使われていないスキルはほとんどコストを生みません。社内に業務ごとのスキルを何十本も揃えていく運用が現実的に成立するのは、この設計によるものです。
さらにレベル3では、参照ファイルは読み取られたときにだけコンテキストに入り、スクリプトに至っては実行結果だけがコンテキストに入ります。コード本体は読み込まれません。数百ページ相当の社内規程や仕様書を同梱しても、そのタスクで参照した箇所以外は負荷にならない、という構造になっています。
SKILL.mdの書き方で最も重要なのは「description」
YAML メタデータの必須項目は name(名前)と description(説明)の2つだけです。name は64文字以内・小文字英数字とハイフンのみ、description は1024文字以内という制約があります。
このうち成否を分けるのは description です。AI エージェントは、利用者のリクエストとこの説明文を照合して「このスキルを使うべきか」を判断します。公式ドキュメントも、description にはそのスキルが何をするのかといつ使うべきなのかの両方を書く必要があると明記しています。
実務上、ここが導入初期のつまずきどころになります。手順の中身は丁寧に書いたのに、説明文が「契約書レビュー用」のように短すぎるために、必要な場面でスキルが呼び出されない、という事象が起きます。「見積書・業務委託契約書・秘密保持契約書のレビュー時に使用。契約書の確認、リーガルチェック、条項の妥当性判断を依頼されたときに参照する」のように、想定される呼ばれ方まで書き込んでおくことが、呼び出し精度を決めます。
社内で試作する場合は、手順の精緻化よりも先に、この説明文の書き方を揃えることを優先すると失敗が減ります。
スクリプトを同梱できることが「毎回結果が変わる」問題を減らす
エージェントスキルは、文章による手順だけでなく、実行可能なスクリプトを同梱できます。公式ドキュメントは、スクリプトは「決定論的な操作」を提供するものだと位置づけています。つまり、毎回必ず同じ処理をさせたい部分はコードに寄せる、という設計が可能です。
AI エージェントの業務適用でよく問題になるのが、出力の揺れです。金額の集計、書式のチェック、ファイル名の採番といった「絶対に揺れてはいけない処理」を自然言語の指示に任せると、実行のたびに微妙に結果が変わります。ここをスクリプトに切り出しておけば、結果は固定されます。
この点は、内製と外注の線引きにも関わります。文章で書ける手順は業務を知っている社内の人が書くのが最短ですが、スクリプトの実装が絡む部分には開発の専門性が必要になります。「どこまでを文章で書き、どこからをコードにするか」の設計判断こそが、エージェントスキルの品質を左右する部分です。
エージェントスキルとMCP・RAG・カスタム指示の違い
「MCP を入れたばかりなのに、また別の仕組みが必要なのか」「RAG との違いは何か」という疑問は、投資判断の前に必ず出てきます。結論から言えば、これらは互いに置き換わるものではなく、担当する役割が異なります。
MCPは「接続」、エージェントスキルは「手順」
MCP(Model Context Protocol)は、AI エージェントと外部システム(基幹システム、データベース、SaaS など)をつなぐための接続規格です。AI が社内システムのデータを読み書きできるようにする、いわば「手足」を用意する仕組みにあたります。MCP そのものについて詳しく知りたい場合は、MCP(Model Context Protocol)とはで基礎を整理しています。
一方でエージェントスキルは、その手足を「どういう順番で、どういう判断基準で動かすか」を記述したものです。接続ができていても手順がなければ、AI は毎回自己流でやり方を組み立ててしまいます。逆に手順が完璧でも、必要なデータにアクセスできなければ作業は完結しません。
したがって両者は排他ではなく、多くの企業では両方が必要になります。MCP を導入済みであることは、エージェントスキルを不要にする理由にはならず、むしろスキルが効きやすい前提条件が整っている状態と捉えるほうが実態に合います。
RAG・カスタム指示との使い分け
周辺の仕組みも含めて整理すると、次のように役割が分かれます。
仕組み | 担う役割 | たとえるなら | 主に解決する問題 |
|---|---|---|---|
エージェントスキル | 業務手順・判断ルール・出力の型のパッケージ | 業務マニュアル | やり方が人によって違う、毎回指示し直している |
MCP | 外部システムとの接続の標準化 | 手足・配線 | 必要なデータにAIが到達できない |
RAG | 関連情報を検索して AI に渡す仕組み | 資料室と司書 | 参照すべき情報が膨大で特定できない |
カスタム指示 | 常時適用される全体方針 | 就業規則・行動指針 | 口調・禁止事項など全社共通のルールが守られない |
カスタム指示は常に効いている全体方針であるのに対し、エージェントスキルは特定の作業のときだけ呼び出される点が異なります。全社共通のルールをすべてカスタム指示に詰め込むと、指示文が肥大化して個々の作業精度が落ちます。作業ごとに切り出せるものはスキルへ、全体に効かせたいものはカスタム指示へ、という振り分けが基本になります。
どちらが足りていないかを見分ける2つの問い
自社の詰まりがどのレイヤーの問題なのかは、次の2つの問いで大まかに切り分けられます。
- AI に必要なデータが渡っているか:渡っていないなら、不足しているのは接続(MCP や API 連携)です。手順を書いても解決しません。
- 同じ作業を人が説明し直しているか:説明し直しているなら、不足しているのは手順(エージェントスキル)です。接続を増やしても解決しません。
PoC がうまくいかなかった原因を振り返るとき、この2つを分けて確認すると、追加投資すべき方向がぶれにくくなります。両方に当てはまる場合は、接続の整備を先に進めるほうが手戻りが少なくなります。手順は、扱えるデータが確定してからでないと書き切れないためです。
エージェントスキルが効く課題・効かない課題
投資判断で最も重要なのは、「入れれば解決する」という期待値を実態に合わせて調整することです。エージェントスキルには明確に効く領域と、構造的に効かない領域があります。
効果が出やすい4つの業務パターン
エージェントスキルの業務活用で成果が出やすいのは、次のような状態にある業務です。
業務パターン | 現状の症状 | 効果が出る条件 |
|---|---|---|
担当者ごとに品質がばらつく業務 | ベテランと新任で成果物の水準が違う | ベテランの判断基準が言語化できる |
毎回同じ指示を書き直している業務 | 指示文をコピーして少しずつ書き換えている | 指示の共通部分が7割以上を占める |
成果物のフォーマットが決まっている業務 | 書式・記載項目の抜け漏れ確認に時間を取られる | フォーマットと必須項目が定義済み |
手順が確定している定型業務 | 手順書はあるが、その通りに実行されない | 手順書が現行運用と一致している |
いずれにも共通するのは、「正解の手順が存在するが、それが安定して実行されていない」という構造です。逆に言えば、正解の手順が存在しない業務にスキルを適用しても効果は出ません。
効果を役員に説明する際は、削減される工数だけでなく、「品質が下振れしなくなること」を併せて示すと納得を得やすくなります。手戻りやレビュー差し戻しの削減は、単純な作業時間の短縮より金額換算しやすい効果です。
エージェントスキルでは解決しない課題
一方、次のような課題はエージェントスキルの守備範囲外です。ここを取り違えると、投資が空振りに終わります。
- そもそも業務手順が言語化されていない:スキル化する対象そのものが存在しません。まず棚卸しが必要です。
- 基幹システムからデータが取れない:接続の問題であり、MCP や API 連携で解決すべき領域です。
- モデルの推論精度そのものが足りていない:高度な判断や創造性を要する業務は、手順を与えても水準が上がらない場合があります。
- 現場が AI を使う運用に乗っていない:使われないツールにスキルを足しても利用は増えません。定着施策が先です。
- 任せてよい範囲が決まっていない:どこまで自動化し、どこから人が確認するかが未定のままでは、精度の議論ができません。この線引きについてはAIに任せる範囲と人が確認する範囲の線引きで詳しく整理しています。
このリストを社内で共有しておくと、「AI で何とかならないか」という要望が来たときに、エージェントスキルで対応すべき案件かどうかを窓口で判断できるようになります。
導入前に社内で済ませておくべき業務の棚卸し
効く条件を裏返すと、導入前にやるべきことが見えてきます。外注する場合であっても、次の3点は社内で先に手を付けておくと、ヒアリング工数が圧縮され、結果として費用も抑えられます。
- 対象業務の選定:上記の4パターンに当てはまる業務を3〜5件ピックアップし、それぞれの月間発生件数と1件あたりの所要時間を概算する
- 判断基準の吸い上げ:その業務のベテランに「どこで迷い、何を根拠に決めているか」をヒアリングし、箇条書きで残す
- 成果物サンプルの収集:良い例と悪い例を各3件ずつ集める(評価基準を作る際の材料になります)
特に2番目は、エージェントスキルの本体そのものになります。ここが社内で用意できているかどうかが、次に述べる内製・外注の線引きを大きく左右します。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
エージェントスキルは内製すべきか外注すべきか|線引きの判断基準

エージェントスキルは、その本体がテキストファイルであるという性質上、「全部外注」も「全部内製」も最適解になりにくい領域です。どこで線を引くかを決めるために、5つの判断軸で自社の状況を整理します。
内製・外注を分ける5つの判断軸
判断軸 | 内製寄りになる条件 | 外注寄りになる条件 |
|---|---|---|
業務手順の文書化状況 | 手順書・判断基準が既に文書化されている | 手順が個人の頭の中にあり、引き出す作業から必要 |
スクリプト同梱の必要性 | 文章の手順だけで完結する | 集計・検証・外部連携などコード実装が必要 |
対象データの機密度・監査要件 | 一般的な社内文書のみを扱う | 個人情報・機密情報を扱い、監査対応が求められる |
保守の担い手 | 業務部門が自ら更新できる体制がある | 更新の主体が決まっておらず、設計から必要 |
対象スキルの本数と展開範囲 | 1〜2部門で数本を試す規模 | 全社横断で数十本を短期間に整備する規模 |
5軸のうち、判断への影響が最も大きいのは「スクリプト同梱の必要性」と「機密度・監査要件」の2つです。この2つが外注寄りであれば、文章部分だけ社内で書けても、全体としては外部の関与が必要になります。
内製が向くケース/外注が向くケース
上記の軸を組み合わせると、実務上は次の3パターンに整理できます。
パターン | 向いている状況 | 進め方の要点 |
|---|---|---|
内製 | 手順が文書化済みで、文章のみのスキルを数本試す段階 | まず1本作り、呼び出し精度を確認してから広げる |
外注 | スクリプト実装が必要、機密データを扱う、短期で多数のスキルを整備したい | 依頼範囲と納品物を先に定義してから見積もりを取る |
併走 | 手順は社内にあるが、設計の型と評価の仕組みがない | 最初の1〜2本を外部と一緒に作り、以降を社内で量産する |
多くの企業にとって現実解になりやすいのは、3つ目の併走型です。理由は、エージェントスキルの中身が業務知識そのものであるためです。業務を最もよく知っているのは現場であり、外部のベンダーがその知識をゼロからヒアリングして文書化するには相応の工数がかかります。一方で、スキルをどう分割するか、説明文をどう書けば呼び出されるか、精度をどう評価するかといった設計面には経験が要ります。
エージェントスキルの作り方を社内に残す「併走型」という選択
併走型で進める場合、外部に依頼するのは「スキルそのもの」ではなく「スキルの作り方と評価の型」になります。具体的には次のような分担です。
- 外部が担当する:スキルの分割方針の設計、SKILL.md のテンプレート整備、説明文の書き方の基準策定、評価用テストケースの設計、スクリプト実装、最初の1〜2本の実装
- 社内が担当する:対象業務の選定、判断基準のヒアリングと文書化、テンプレートに沿った2本目以降の作成、運用中の更新
この分担にすると、最初のプロジェクトが終わった時点で、社内には「型に沿って自分たちで書ける状態」が残ります。エージェントスキルの作り方が外部に閉じたままだと、業務が変わるたびに発注が必要になり、更新が滞ってスキルが陳腐化します。更新頻度の高い業務ほど、内製できる状態を作っておく価値が大きくなります。
発注時には、この「社内に型を残すこと」自体を要件として明記しておくことをおすすめします。成果物の一覧に「作成ガイドライン」「テンプレート」「社内向け説明会の実施」を含めるかどうかで、1年後の運用状況が大きく変わります。
エージェントスキル開発を外注するときの依頼範囲・成果物・見積もりの見方
外注を選択した場合、「何を頼み、何が納品されるのか」が曖昧なまま見積もりを取ると、比較ができません。工程・納品物・確認項目の3点を先に固めておきます。
依頼範囲を6工程に分解する
エージェントスキルの開発は、次の6工程に分解できます。見積もり依頼時には、どの工程を委託し、どの工程を社内で担うかを工程単位で指定します。
工程 | 内容 | 社内で担える度合い |
|---|---|---|
1. 業務ヒアリングと棚卸し | 対象業務の選定、現行手順と判断基準の抽出 | 高い(事前準備で工数圧縮が可能) |
2. スキル設計・分割方針 | 何を1本のスキルにまとめ、どう分けるかの設計 | 低い(経験を要する) |
3. SKILL.md と参照資料の作成 | 手順の記述、説明文の作成、参照資料の整備 | 中程度(テンプレートがあれば可能) |
4. スクリプト実装 | 決定論的な処理のコード化 | 低い(開発の専門性が必要) |
5. 評価・テストケース作成 | 呼び出し精度と出力品質の合否基準の設計 | 低い(設計経験を要する) |
6. 運用移管・社内教育 | 更新手順の引き継ぎ、作成ガイドラインの共有 | — (委託範囲に含めるか要判断) |
工程1を社内で先に済ませておくと、ヒアリング工数が減り、見積総額も下がります。前述の「導入前の棚卸し」がそのまま準備作業になります。
納品物として明記すべき6点
発注書や提案依頼書には、次の6点を納品物として明記します。ここが曖昧だと、「動くものは納品されたが、社内で更新できない」という状態に陥ります。
- SKILL.md 一式:スキルごとの本体ファイル
- 参照ドキュメント:スキルが参照する社内資料・判断基準の整備済みファイル
- スクリプトと実行手順:同梱スクリプトのソースコード、依存関係、実行方法の説明
- 評価用テストケースと合否基準:どういう入力に対して何が出力されれば合格かの定義
- 更新・保守手順書:業務変更時に誰がどう更新するかの手順
- 対象環境ごとの配置手順:利用する環境(後述のとおり環境ごとに配置方法が異なります)ごとのインストール手順
特に4番目の評価用テストケースは、提案から漏れやすい項目です。これがないと、納品物が期待どおり動作しているかを発注側が客観的に確認できません。検収基準そのものになるため、必ず納品物に含めるよう指定してください。
見積もりを比較するときの確認チェックリスト
複数社から見積もりを取る際、金額だけを比較すると前提条件の違いを見落とします。次の5点を各社に確認し、同じ土俵で比較できる状態にします。
- スキル本数と粒度の定義:「5本」と言ったときの1本の大きさが各社で異なります。対象業務名を列挙して合わせます
- 評価基準が成果物に含まれるか:テストケースと合否基準が納品物に入っているか
- 対象環境:どの環境で使えるようにするのか(環境ごとに別作業になる場合があります)
- 保守範囲と期間:納品後の修正対応の範囲、期間、費用の扱い
- 業務ヒアリング工数の扱い:ヒアリングが見積に含まれるか、社内提供が前提か
費用相場そのものの考え方は、AIエージェント開発の費用で開発規模別に整理しています。エージェントスキルの開発費用も、工程の切り分け方と社内で担う範囲によって大きく変動する点は共通しています。
エージェントスキルの企業導入で押さえるセキュリティ・ガバナンス

エージェントスキルは、AI エージェントに指示とコードの両方を与える仕組みです。この性質上、導入にあたっては情報システム部門の審査に耐える運用設計が必要になります。
第三者製スキルはソフトウェア導入と同じ審査を通す
公式ドキュメントは、スキルは信頼できるソース(自分で作成したもの、または提供元が明確なもの)からのみ使用すべきだと明記しています。悪意のあるスキルは、そのスキルが表明している目的とは異なる形でツールを呼び出したり、コードを実行したりするよう AI に指示できてしまうためです。
同ドキュメントが挙げているリスクは次のとおりです。
- ツールの悪用:ファイル操作、コマンド実行、コード実行を有害な方法で呼び出される可能性
- データの露出:機密データにアクセスできるスキルが、外部システムへ情報を送るよう設計されている可能性
- 外部ソースの危険性:外部 URL からデータを取得するスキルは、取得内容に悪意ある指示が混入する可能性があり、特にリスクが高い
公式ドキュメントは、対応として「バンドルされているすべてのファイル(SKILL.md、スクリプト、画像、その他のリソース)を確認し、予期しないネットワーク呼び出しやファイルアクセスなど、表明された目的と一致しない操作がないか点検すること」を推奨しています。そして本番システムへの統合は、ソフトウェアのインストールと同様に扱うべきだとしています。
実務に落とすと、第三者が公開しているスキルは「便利そうだから入れてみる」対象ではなく、社内のソフトウェア導入審査と同じフローに乗せる対象になります。導入申請・中身の確認・承認記録という手順を、最初のルール整備の段階で決めておくことをおすすめします。
共有範囲は使う環境によって変わる
企業導入で見落とされやすいのが、利用する環境によってスキルの共有範囲と管理方法が異なるという制約です。公式ドキュメントは次のように整理しています。
利用環境 | 共有範囲 | 管理上の注意点 |
|---|---|---|
claude.ai | ユーザー個人単位 | 各メンバーが個別にアップロードする必要があり、管理者による一元管理や組織全体への配布はサポートされていない |
Claude API | ワークスペース全体 | アップロードしたスキルにワークスペースの全メンバーがアクセスできる |
Claude Code | 個人用またはプロジェクト単位 | ファイルシステムベースのため、リポジトリで管理・レビューできる |
加えて、カスタムスキルは環境間で同期されません。ある環境にアップロードしたスキルが、別の環境で自動的に使えるようにはならないため、利用する環境ごとに個別の管理・配布が必要になります(Anthropic 公式ドキュメント「Agent Skills」)。
この制約は、外注時の要件定義にも直結します。「どの環境で使うのか」を決めずに発注すると、納品後に別環境への展開作業が追加で発生します。前述の見積もり確認チェックリストに対象環境を含めているのは、この理由によるものです。
野良スキルを防ぐ社内レビュー体制と3段階の展開手順
環境によって管理者が一元管理できない場合があるということは、放置すれば個人が自由に作ったスキルが増えていく、いわゆる「野良スキル」の温床になり得ます。誤った手順が組み込まれたスキルが部門内で共有され、その出力が業務判断に使われる状態は、シャドー IT と同種のリスクを持ちます。
対策として現実的なのは、スキルの正本を社内のリポジトリ(バージョン管理できる保管場所)に集約し、追加・変更をレビューしてから配布する運用です。ファイルベースで管理できる環境であればこの運用と相性がよく、誰がいつ何を変更したかの履歴も残ります。
展開そのものは、次の3段階で進めると無理がありません。
- スモールスタート:1部門・1〜2本のスキルで試し、呼び出し精度と工数削減効果を測る
- 部門展開:効果が確認できた業務の周辺に広げ、同時にレビュー体制と更新ルールを整備する
- 全社カタログ運用:承認済みスキルを一覧化して社内に公開し、申請・審査・配布のフローを定常化する
最初から全社展開を狙うと、レビュー体制が追いつかないまま数だけが増え、品質のばらつきという当初の課題が形を変えて再発します。1段階目で効果測定の仕組みを作っておくことが、2段階目以降の説明材料になります。
まとめ|エージェントスキルの導入可否を判断するために
エージェントスキルとは、AI エージェントに業務手順・判断ルール・出力の型をパッケージで持たせる拡張機能です。導入可否を判断するための要点を、あらためて整理します。
- 仕組み:中核は SKILL.md という Markdown ファイル1枚。段階的開示により、使われていないスキルはほとんどコストを生まないため、業務ごとに多数用意する運用が成立します
- 位置づけ:MCP が「接続」、エージェントスキルが「手順」を担います。排他ではなく補完関係にあり、自社の詰まりが接続側なのか手順側なのかで切り分けます
- 効く課題の見極め:正解の手順が存在するのに安定して実行されていない業務に効きます。手順が言語化されていない、データが取れない、現場が使っていない、という課題には効きません
- 内製と外注の線引き:文章で書ける手順は業務を知る社内が書くのが最短です。スクリプト実装・機密データの扱い・評価設計が絡む部分は外部の関与が必要になり、最初の1〜2本を併走して型を社内に残す進め方が現実的です
- 発注時の要点:依頼範囲を6工程で指定し、納品物に評価用テストケースと更新手順書を必ず含めます。見積比較ではスキルの粒度・対象環境・保守範囲の前提を揃えます
- ガバナンス:第三者製スキルはソフトウェア導入と同じ審査を通します。共有範囲は環境ごとに異なり、環境間の同期もされないため、正本を社内で管理するレビュー運用を先に設計します
次のアクションとしては、対象業務を3〜5件選び、それぞれの判断基準をベテランからヒアリングして箇条書きに落とすところから始めるのが着実です。この棚卸しは内製・外注のどちらを選んでも必要になり、外注する場合はそのままヒアリング工数の圧縮につながります。
関連情報
AI 活用を社内で進める際の検討手順を体系的に整理したい場合は、お役立ち資料「はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ」もあわせてご覧ください。対象業務の選定から効果測定までの流れをまとめています。
エージェントスキルの内製・外注の線引きや、依頼範囲の整理でお困りの場合は、お問い合わせフォームからご相談ください。業務の棚卸し段階からのご相談にも対応しています。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- エージェントスキルを導入すればMCPは不要になりますか?
いいえ、両者は排他ではなく補完関係です。データが渡っていないならMCP、同じ作業を人が説明し直しているならエージェントスキルが不足しており、両方に該当する場合は接続整備を先に進めるほうが手戻りが少なくなります。
- 内製と外注のどちらにすべきか判断がつかない場合、最初に何をすればよいですか?
対象業務を3〜5件選び、ベテランが「どこで迷い、何を根拠に決めているか」をヒアリングして文書化してください。この棚卸しは内製・外注いずれを選ぶ場合にも必要になり、外注時はそのまま見積もり工数の圧縮につながります。
- エージェントスキルの開発費用はどのくらいかかりますか?
スキルの粒度・スクリプト実装の要否・対象データの機密度・対象環境によって大きく変動するため一概には言えません。見積もりを比較する際は、スキルの本数と粒度の定義や保守範囲などの前提条件を各社で揃えたうえで確認してください。
- 第三者が公開しているエージェントスキルをそのまま使っても問題ないですか?
推奨されません。悪意のあるスキルはツールの誤用やデータ露出につながる可能性があるため、ソフトウェアのインストールと同様に同梱ファイルの中身を確認し、社内の導入審査を通してから本番システムに組み込んでください。
- 併走型で外注した場合、プロジェクト終了後に社内には何が残りますか?
スキルの分割方針や説明文の書き方、評価の型といった「作り方のノウハウ」が社内に残り、2本目以降は自分たちで作成できる状態になります。作り方が外部に閉じたままだと、業務が変わるたびに発注が必要になり更新が滞ります。



