GitHub Copilotのスキル機能を使いこなす|作り方と導入の手順

GitHub Copilotのスキルとは?カスタム命令との違いから整理する

スキルは「関係あるときだけ読まれる指示書」

室谷代表取締役

まず言葉の整理からいきましょうか。Copilotのスキルって、突き詰めると「命令・スクリプト・リソースを1つのフォルダーにまとめて置いておく」仕組みなんですよね。

で、関連があるときだけCopilotが読みにいく、と。

テキトー教師DotAI 認定講師

そうなんです。ここで最初に戸惑うのが「今まで設定してきた指示と何が違うの?」という点で。

毎回読ませる注意書きと、必要なときだけ開く専門書、みたいな違いなんですよ。

室谷代表取締役

常時読ませるとコンテキストを食うんですよね。スキルを増やしすぎて、中身の説明文を読むだけで枠が埋まる、というのも現場でよく聞く話で。

テキトー教師DotAI 認定講師

そこは体感あります。プロンプトとdescriptionを見てCopilotが使うかどうかを判断して、使うと決めたらSKILL.mdの中身をコンテキストに入れる。

だから説明文の書き方がかなり効いてくるんです。

カスタム命令・カスタムエージェントとの役割分担

室谷代表取締役

公式の整理だと、カスタム命令はほぼ全部のタスクに関わる簡単な指示を常に渡すもの、スキルはタスク固有の詳しいガイダンス、カスタムエージェントはペルソナとツールの組み合わせ、という分担になってます。3つ並べられると、どこを編集すればいいか迷いません?

テキトー教師DotAI 認定講師

迷いますね。初めて触る人には全部同じ場所に見えてしまう。

現場感覚で言うと、毎回守ってほしいルールはカスタム命令、特定の作業のときだけ効かせたい手順はスキル、と分けて考えると腹落ちしやすいです。

室谷代表取締役

経営目線で言うと、この分離はレビュー工数に直結するんですよ。チーム共通の作法は命令側に固定して、属人的な手順はスキルに閉じ込める。

そうすると人が入れ替わっても品質が落ちにくくなる。

テキトー教師DotAI 認定講師

たしかに。あとスキルはディレクトリ単位で分かれているので、担当ごとに持たせて中身をレビューしやすいというのもありますね。

Anthropicが公開したオープン標準で、他のAIツールとも共通

室谷代表取締役

ここが構造的に面白いところで。このスキルの仕様、Anthropicが公開したオープン標準なんですよ。

ClaudeでもCursorでも同じ形式が使われる。

テキトー教師DotAI 認定講師

それは大きいですね。SKILL.mdという同じ書き方で、ツールを乗り換えても書いた資産が残る。

覚えることも1つで済みます。

室谷代表取締役

ベンダーごとに書式がバラバラだと、ユーザー側が囲い込まれる。それが標準化で崩れると乗り換えコストが下がって、競争が起きる。

エコシステムの主導権争いが、書式のレベルで進んでるわけです。

テキトー教師DotAI 認定講師

エディタの比較が気になる人も多いと思うので、そこはCursorとGitHub Copilot、どっちを選ぶ？違いや併用・設定を徹底比較で整理されてます。置き場所が共通化されると、併用もしやすくなりますよね。

スキルはどこで使える?対応環境と前提条件

使える場所は大きく4系統

室谷代表取締役

まず使える場所の全体像なんですけど、IDEのエージェントモード、Copilot CLI、cloud agent、GitHub.com上のcode review、この4系統に分かれるんですよね。GitHub Copilot appからも使えます。

テキトー教師DotAI 認定講師

現場でよく聞くのが「VS Codeでは動いたのに隣の人の環境では出てこない」なんですよ。IDEは使用バージョンでサポート範囲が変わるので、まず自分のバージョンを確認するところからですね。

室谷代表取締役

整理するとこうです。

室谷代表取締役

有料プラン側の線引きが気になるなら、料金を個人・法人別に整理した記事のほうが早いと思います。ここでは「場所ごとに条件が違う」だけで十分なんですよね。

CLIとcloud agentは組織設定とスキルの置き場が効く

テキトー教師DotAI 認定講師

CLI、個人アカウントだとすんなり入るのに、会社のアカウントだと反応しない人がいます。組織のポリシーで止まってるパターンですね。

室谷代表取締役

そこは管理者側の判断なんですよ。現場が勝手に有効化する話じゃなくて、経営目線で言えば「どの作業をどこまで許すか」を先に決めておく話で。

CLIを許可するなら、その前提でスキルの置き場もルール化しておきたい。

テキトー教師DotAI 認定講師

cloud agent側はもう少し癖があって、個人スキルはホームディレクトリに置くだけでは届かないんです。クラウドのサンドボックスで使うなら、GitHub Actionsベースのセッションを除いて、dotfilesリポジトリの .copilot/skills に入れておく必要があります。

室谷代表取締役

そこ、最初に知らないと「置いたのに読まれない」で詰まるやつですね。個人用とプロジェクト用の置き分けは、また別のところで掘りますけど。

code reviewにスキルを読ませたいときの置き方

室谷代表取締役

レビューに効かせたい場合は、.github/skills に置けばいいだけじゃなくて、ディレクトリ名が効いてくるんですよ。

テキトー教師DotAI 認定講師

そうなんです。レビュー関連だと分かる名前、たとえば code-review にしておくと確実に読まれやすい。

.github/skills 内の既存スキルでも、レビュー関連のものはCopilot code reviewから自動的に使われることがあります。

室谷代表取締役

命名って属人化しがちなんですけど、ここは「レビュー用はこの名前」って決め打ちしたほうがチームで回るんですよね。地味に効くコスト削減です。

テキトー教師DotAI 認定講師

あと、そもそもエージェントモードじゃないと動かないので、AskモードやEditモードのまま待ってる人が最初に戸惑うのがここですね。

スキルの保存場所|プロジェクト用と個人用の置き分け

チームで配るならリポジトリの中

室谷代表取締役

スキルの置き場所、まずプロジェクト用はリポジトリの中なんですよ。.github/skills が基本で、.claude/skills と .agents/skills も同じように見てくれます。

テキトー教師DotAI 認定講師

最初に戸惑うのが、候補が3つもあることなんですよね。どれに置けばいいのか分からなくて手が止まる。

室谷代表取締役

チームで回すなら .github/skills に寄せるのが素直です。 Claude Code と併用してる現場なら .claude/skills に一本化する手もありますけど、混ぜると「どこが正なのか」が曖昧になる。

テキトー教師DotAI 認定講師

たしかに。置き場所が散ると、レビューする側が毎回全部見ないといけなくなりますもんね。

自分専用はホームディレクトリ

まとめると、効く範囲で分けるとこうです。

テキトー教師DotAI 認定講師

個人スキルは手元の全プロジェクトで効くので、現場感覚で言うと、まず自分だけで試してから、効いたものをリポジトリ側に移す流れが無理がないんですよ。

室谷代表取締役

そこは経営目線で言うと分かりやすくて。いきなり全員に配るより、1人が自分の環境で試す方が検証コストが安いんですよね。

外れたときの被害も小さい。

テキトー教師DotAI 認定講師

あと Visual Studio だと ~/.claude/skills も検出対象に入るらしいです。使うIDEによって見え方が変わるので、そこだけ注意ですね。

室谷代表取締役

そのへんはバージョンで差が出るので、公式の対応表を見てもらうのが確実です。

クラウドのセッションだけは別扱い

室谷代表取締役

ここが落とし穴で。Copilot cloud agent のクラウドサンドボックスで動かすと、ホームディレクトリに置いた個人スキルは効かないんですよ。

テキトー教師DotAI 認定講師

あ、それはハマる人多いですね。ローカルでは普通に動いてたのに、クラウドに投げた瞬間だけ無視されるので、原因が分からずスキルの中身を疑い始める。

室谷代表取締役

正解は dotfiles リポジトリ側の .copilot/skills に置くこと。ただし GitHub Actions ベースのセッションは例外なので、そこは前提が変わります。

テキトー教師DotAI 認定講師

じゃあ覚え方はシンプルで、手元用とクラウド用は別の場所、と。同じスキルを両方で使いたいなら二箇所に置く前提で考えるのが安全ですね。

SKILL.mdの書き方|最小構成とfrontmatterの項目

ディレクトリ名のルールとSKILL.mdの最小例

室谷代表取締役

まず置き場所の名前から。スキルごとに専用のサブディレクトリを切って、名前は小文字、スペースはハイフン。

これは機械的に守る前提のルールなんですよね。

テキトー教師DotAI 認定講師

そうなんですよね。中身はSKILL.mdが必須で、YAMLのfrontmatterとMarkdown本文の2層になります。

最小構成だとこうです。

.github/skills/pdf-check/
└── SKILL.md

---
name: pdf-check
description: PDFのレイアウト崩れを検出して修正案を出す
---

本文にCopilotが従う手順を書く

室谷代表取締役

nameとディレクトリ名がズレていると弾かれるので、そこは揃える。地味なところですが、初めて触る人が最初に転ぶポイントです。

nameとdescriptionに何を書くか

テキトー教師DotAI 認定講師

nameは小文字・数字・ハイフンのみ、親ディレクトリ名と一致、最大64文字。descriptionは必須で最大1,024文字、ここに「何をするか」と「いつ使うか」を書きます。

ほかにlicense、compatibility、metadataという任意項目もあります。

室谷代表取締役

description、ここが実質の本体なんですよね。Copilotはプロンプトとdescriptionを見て使うかどうかを決めるので、曖昧だとファイルがある意味がほぼなくなる。

テキトー教師DotAI 認定講師

現場でよく聞くのは「作ったのに使ってくれない」なんですけど、大体descriptionが「便利なツール」みたいな抽象度で終わってるんですよ。エージェントが関連性を判断できる具体的なキーワードを入れると当たるようになります。

室谷代表取締役

仕様書と同じで、読み手が判断できる情報を書くかどうか。手を抜く場所じゃないんですよね。

scripts・references・assetsを同梱する

室谷代表取締役

SKILL.mdだけだと指示しか持てない。実際の処理を伴うならscripts、詳細資料はreferences、テンプレートはassetsに置く、という標準構成なんですよね。

テキトー教師DotAI 認定講師

スキルが呼ばれると、Copilotはディレクトリ内の全ファイルを検出して、SKILL.mdの指示から参照できるようになります。だから本文に全部を書き切らなくて大丈夫なんです。

室谷代表取締役

本文は500行以内に収めて、細かい仕様はreferencesへ逃がすのが推奨されてます。1ファイルが膨らむと、後から誰も読まなくなるんですよ。

中の人としては、そこは保守コストの話です。

テキトー教師DotAI 認定講師

最初に戸惑うのが「本文に書くか、ファイルに分けるか」の線引きなんですが、迷うものは分けた方がいいですね。置くだけで参照されるので、パスを書く手間もほぼないです。

allowed-toolsは何を許す設定なのか

テキトー教師DotAI 認定講師

allowed-toolsは任意項目で、確認なしで使えるツールをスペース区切りで事前承認する設定です。ここ、意味を分からずにコピーしてくる方が多いんですよ。

室谷代表取締役

これはリスクの話として重くて。shellやbashを事前承認すると実行前の確認手順が省かれるので、プロンプトインジェクションが混ざったときに任意のコマンドが走る余地が残る。

中身が分からないスキルなら、そこは外して毎回確認を残すべきなんですよね。

テキトー教師DotAI 認定講師

たしかに。手間を減らす設定と、安全を手放す設定が同じ一行に載っているので、意識して分けた方がいいですね。

効果的なスキルの書き方と、発火しないときの対処

本文は短く、詳細はreferencesへ逃がす

室谷代表取締役

SKILL.mdって、つい全部詰め込みたくなるじゃないですか。公式は本文を500行以内に抑えて、細かい資料はreferencesに分けてリンクする形を勧めてるんですよね。

テキトー教師DotAI 認定講師

現場でよく聞くのは「とりあえず全部書いた」パターンです。読む側も長文だとなんとなく流してしまうので、本体は手順だけ、表やサンプルはreferencesに置くほうが安定します。

室谷代表取締役

descriptionは1024文字までですけど、長さより中身ですからね。本体を短くしておくと、後から直すのも楽なんですよ。

テキトー教師DotAI 認定講師

たしかに。まず動く最小形を作って、足りない分をreferencesに足していく順番が、結局いちばん早いです。

descriptionにトリガーになる言葉を入れる

室谷代表取締役

Copilotはプロンプトとdescriptionを見て、このスキルを使うかどうか決めるんですよ。だから要約だけ書いてると選ばれないことがあるんです。

テキトー教師DotAI 認定講師

初めて触る人が戸惑うのがまさにそこです。「レビュー用」だけだと弱くて、実際の依頼文に出てくる言葉と噛み合わないんですね。

室谷代表取締役

抽象語じゃなく現場の名詞を入れる、と。

テキトー教師DotAI 認定講師

はい。「何をするか」に加えて「いつ使うか」を一行入れておくと、判断してもらいやすいです。

あとは詳細な例や例外ケースを本文に書いておくと、当たったときの精度が変わります。

1スキル1責任にして増やしすぎない

室谷代表取締役

スキルって増やしたくなるじゃないですか。レビュー用、テスト用、ドキュメント用、みたいに。

テキトー教師DotAI 認定講師

そこは注意で、増やしすぎるとメタデータの読み込みだけでコンテキストを消費するんですよ。使っていないのに枠を食ってる状態ですね。

室谷代表取締役

経営目線で言うと、読まれないルールにコストを払い続けてるのと同じで。1スキル1責任で分けて、要らないものは消す。

整理も運用のうちなんですよね。

テキトー教師DotAI 認定講師

そう思います。大きくなったら分ける、足りないときだけ足す。

この順番を守るだけでだいぶ違います。

使われないときに疑う3つのポイント

テキトー教師DotAI 認定講師

動かないときは、上から順に疑うと迷わないです。

1. Agent Modeになっているか（AskモードやEditモードでは動かない）
2. descriptionにトリガーになる具体的な言葉が入っているか
3. スキルを増やしすぎていないか。チャットで「○○スキルを使用して」と名指しして切り分ける

室谷代表取締役

モードの話、地味にハマりますよね。設定を疑う前に、そもそも動く場所じゃなかったという。

テキトー教師DotAI 認定講師

これ、ハマる人多いんですよ。あとはレビューで確実に読ませたいならディレクトリ名をそれと分かる名前にしておく。

公式がそこまで言及してるので、名付けも立派な設定のうちですね。

第三者スキルを入れる前のセキュリティ確認

GitHubはスキルの中身を検証していない

室谷代表取締役

配布の話になると必ず出てくるのが「誰が中身を保証するのか」なんですよね。公式ドキュメントには、スキルはGitHubによって検証されない、とはっきり書かれているんですよ。

テキトー教師DotAI 認定講師

そこ、初めて触る人が一番びっくりする部分で。プロンプトインジェクションとか、隠された命令、悪意あるスクリプトが混ざり得る前提なんです。

室谷代表取締役

経営目線で見ると、これは「入れるコスト」じゃなくて「入れた後に剥がすコスト」の話なんです。レビュー工数を最初に見積もっておくかどうかで、後の負債額がまるで変わる・・・

テキトー教師DotAI 認定講師

たしかに。「便利そうだから入れてみた」が一番危ない流れですね。

読んでから入れる、これを習慣にできるかどうかです。

入れる前にgh skill previewで読む

まずは確認の手順を押さえておきます。

1. gh skill search TOPIC で候補を探す
2. gh skill preview OWNER/REPOSITORY SKILL で中身を表示して読む
3. 内容に納得できたら gh skill install OWNER/REPOSITORY SKILL で導入する

テキトー教師DotAI 認定講師

preview を挟まずに install へ一直線に行く人が多いんですよ。読むだけで防げる事故が結構あるので、ここは一手間かけてほしいところです。

室谷代表取締役

これ、コマンドとしては地味なんですけど、レビュー工程をコマンド1個に畳んだってことなんですよね。工数設計としてはかなり合理的で。

テキトー教師DotAI 認定講師

ちなみに gh skill 自体がGitHub CLIのパブリックプレビュー機能なので、CLI側の前提を知らないとそこで詰まります。詳しくはGitHub Copilot CLIの使い方で解説しています。

室谷代表取締役

読む対象はSKILL.mdだけじゃ足りなくて、同梱されてるスクリプトや参照ファイルまで目を通すのが前提ですね。

shellやbashを事前承認すると何が起きるか

室谷代表取締役

frontmatterに allowed-tools っていう項目があって、ここに書いたツールは確認なしで使える事前承認になるんです。で、shellやbashをここに入れると何が起きるか。

テキトー教師DotAI 認定講師

実行前の確認手順が省かれるんです。公式にも、攻撃者が制御するスキルやプロンプトインジェクションが環境内で任意のコマンドを実行できるようになると書かれていて。

室谷代表取締役

これはもう、権限を渡すかどうかの判断そのものですからね。便利さと引き換えに何を差し出すのかを、入れる前に一度立ち止まって考える必要がある。

テキトー教師DotAI 認定講師

現場感覚で言うと、allowed-tools の存在を知らずにサンプルをそのままコピーしてる人が多い的印象です。中身を理解してから書く、が基本ですね。

社内配布するときも同じ目線で

テキトー教師DotAI 認定講師

自分で書いたスキルなら大丈夫、と思いがちなんですけど、社内配布するなら受け取る側は第三者と同じ立場なんですよ。

室谷代表取締役

そこは組織の統制の話になりますね。配る側が allowed-tools からshellとbashを外しておく、あるいは信頼できるか判断できないなら毎回の確認を残す。

これを配布ルールにしておくと事故率が下がる。

テキトー教師DotAI 認定講師

信頼できるスキルかどうか不明な場合はshellとbashを外して、確認を残す。公式もそう書いてますから、迷ったら安全側に倒すでいいと思います。

室谷代表取締役

オープン標準なので他所のツールでも使い回せるぶん、一度ゆるい設定で配ると広がり方も早いんですよね。最初の設計が効いてきます。

gh skillで探す・入れる・更新する・公開する

searchとpreviewで候補を絞る

室谷代表取締役

ここからが実務の話なんですけど、gh skillはGitHub CLI 2.90.0以降のパブリックプレビューで、探す・入れる・更新する・公開するが一つのコマンド群で回せるんですよね。まずはgh skill search TOPICでトピックから当たりを引く。

テキトー教師DotAI 認定講師

はい。ただ見つけた瞬間に入れたくなるじゃないですか。

そこで一呼吸置いてほしいのがgh skill preview OWNER/REPOSITORY SKILLで、中身を先に読む工程なんですよ。初めて触る人はここを飛ばしがちで。

室谷代表取締役

公式が「GitHubによる検証はされていない」と明記してる以上、previewは保険じゃなくて工程として組み込むべきなんですよね。レビュー無しでマージするのと同じなので。

テキトー教師DotAI 認定講師

探す入口としては、コミュニティのリポジトリが公開されてるので、まずそこで候補を拾ってからpreviewに進む流れが素直ですね。

installとスコープ・エージェント指定

1. gh skill install OWNER/REPOSITORY SKILL で導入する
2. 必要に応じて --scope でインストール範囲を指定する（既定はプロジェクトスコープ）
3. 必要に応じて --agent でエージェントの種類を指定する
4. 導入後、プロジェクト側と個人側のどちらに入ったかを確認する

室谷代表取締役

個人スコープにすれば複数プロジェクトで使い回せるので、業務だとそっちの方が効く場面が多いんですよね。プロジェクトに閉じたいなら既定のまま、という判断で。

テキトー教師DotAI 認定講師

スコープの取り違えは本当に多いんですよ。入れたはずのスキルが別のリポジトリで出てこない、みたいな相談が現場でよく聞くパターンで。

室谷代表取締役

なおgh skill自体がGitHub CLIの上で動くので、CLIの準備がまだならGitHub Copilot CLIの使い方を先に読んでおくと迷わないです。

@TAGや--pinでバージョンを固定する

室谷代表取締役

チームで使うなら勝手に中身が変わられると困るので、固定は最初から入れておきたいところです。@TAGや@SHAを付けるか--pinで止めるか、どちらか一方で、両方は併用できないんですよね。

テキトー教師DotAI 認定講師

固定したら固定したで忘れられがちで。ピン留めしたスキルは更新の対象から外れるので、止めっぱなしになってることに気づかない、というのが現場でよくある落とし穴です。

室谷代表取締役

経営目線で言うと、この手の固定は「事故を減らすコスト」 vs 「追随が遅れるコスト」の天秤なんですよ。全固定か全追従じゃなくて、壊れると痛いものだけ固定するのが現実的ですね。

updateとpublish(--dry-run・--fix)の流れ

1. gh skill update で更新する（全件まとめるなら --all）
2. ピン留めしたスキルは更新対象外なので、必要なら固定を外す
3. 自作スキルは gh skill publish --dry-run で検証だけ先に流す
4. メタデータの指摘は gh skill publish --fix で自動修正する
5. 問題がなければ gh skill publish で検証して公開する

テキトー教師DotAI 認定講師

--dry-runを挟むだけで、名前や説明の書き漏れが手元で分かるんですよね。初回公開でいきなり弾かれると心が折れるので。

室谷代表取締役

公開はリリースと同じで、検証を自動化しておく方が長期的に安いんですよ。--fixで直せる範囲は機械に任せて、人はdescriptionの中身に集中する。

テキトー教師DotAI 認定講師

その順番が身につくと、探す→確認→入れる→止める→更新する→出す、が一本の線で繋がる感じになりますね。

Claude Code Skillsとの関係と移行の考え方

SKILL.md形式が共通なのでコピーでだいたい動く

室谷代表取締役

Claude Code 用に作ったスキル、そのまま持ってこれるんですよね。Agent Skills の仕様自体が Anthropic が公開したオープン標準で、Claude でも Cursor でも同じ形式なんですよ。

複数ツールを並走させてる現場だと、この共通化はかなり効きます。

テキトー教師DotAI 認定講師

現場感覚で言うと、最初に戸惑うのが「Copilot 用に書き直さないと」という思い込みなんですよ。実際は .claude/skills の中身を .github/skills にコピーすればおおむね動きます。

SKILL.md の frontmatter も name と description の書き方が共通なので、ゼロから作り直す人はほとんどいません。

室谷代表取締役

これは業界構造として大きいんですよね。スキルの書式がベンダーごとにバラけると、乗り換えるたびに全部書き直しになる。

それが標準で揃っているだけで、ツール選定の判断材料が「移行コスト」から「機能の中身」に変わるわけです。

テキトー教師DotAI 認定講師

たしかに。ただ Claude Code 側の仕様を曖昧なまま移すと、どこが同じでどこが違うのか分からなくなるので、基礎は一度押さえておいた方がいいです。

詳しくはClaude Code比較完全ガイドで解説しています。

allowed-toolsはCopilot側で実験的な扱い

テキトー教師DotAI 認定講師

一点だけ引っかかる場所があって、allowed-tools のフィールドは Copilot 側では実験的な扱いなんですよ。確認なしで使えるツールをスペース区切りで並べる項目で、書式自体は共通なんですが、同じ挙動を期待してそのまま持ってくるとズレます。

室谷代表取締役

そこは移行時に一回止まって見た方がいいところですね。「Claude で動いたから大丈夫」で流して、後から差異に気づくパターンが一番コストが高いんですよ。

テキトー教師DotAI 認定講師

そうなんです。なので移行したら、そのスキルが実際にどのツールを確認なしで叩くのか、一度は目で追ってください。

ここを読まないと、そのスキルを信頼していいかどうかの判断もできないので。

移行後に必ず確認したいこと

1. ディレクトリ名が小文字・スペースなしのハイフン区切りになっているか
2. SKILL.md の name が親ディレクトリ名と一致しているか
3. description に、そのスキルを使う場面が具体的に書かれているか
4. allowed-tools に何を事前承認しているかを読み返す

室谷代表取締役

この4つ、地味ですけど効きますよ。特に name と親ディレクトリ名の一致は、コピーしたときにずれたまま気づかないケースがあるので。

テキトー教師DotAI 認定講師

現場でよく聞くのは「移したのに反応しない」なんですけど、原因がだいたいこの辺りなんですよね。あとは実際にチャットでそのスキルを呼んでみて、狙った場面で使われるかまで見ておくと安心です。

室谷代表取締役

手間をかけて書いたスキルが動かないまま放置されるのが一番もったいないので、移行は「コピーして終わり」にせず、確認まで含めて1セットで考えた方がいいですね。

よくある質問

Q1. スキルとMCPサーバーはどう違うんですか?

室谷代表取締役

そこ、混ざりやすいんですよね。ざっくり言うと、MCPは外部のツールやデータにつなぐ配管で、スキルは手順書なんですよ。

Copilotに「この作業はこう進めて」と渡すのがスキル、外のサービスを触らせるのがMCP、という切り分けです。

テキトー教師DotAI 認定講師

たしかに。現場でよく聞くのは「どっちから覚えればいい?」で止まってる人ですね。

手順が自分の頭の中にあるならスキル、外の何かとつなぎたいならMCP、と考えると進めやすいです。

室谷代表取締役

順番で言うとスキルが先だと思います。道具を増やす前に、自分の進め方を言葉にできてるかどうかの方が効いてくるので。

Q2. スキルを入れるとコンテキストを圧迫しませんか?

テキトー教師DotAI 認定講師

初めて触る人が一番気にするところですね。スキルは常に全部が読み込まれる作りではなくて、必要と判断されたときに参照される仕組みなので、置いてあるだけで大量に消費する、という感じではないんですよ。

室谷代表取締役

ただ、雑に何十個も置くと「どれを使うか」の判断がぶれるんですよね。うちの感覚だと、日常的に使う数個に絞った方が動きが安定します。

テキトー教師DotAI 認定講師

そこは同感です。引き出しは多ければいいって話でもないんですよね。

Q3. スキルは日本語で書いても大丈夫ですか?

室谷代表取締役

言語の縛りはないので、日本語で書いて問題ないです。むしろ日本語で業務を回してるなら、日本語のまま書いた方がニュアンスが落ちないんですよ。

テキトー教師DotAI 認定講師

現場感覚で言うと、あとから読む人の理解もしやすくなりますね。発火のきっかけになる言葉だけ、実際に自分が使う言い方に合わせておくのがコツです。

Q4. 作ったスキルがちゃんと動くか確認する方法は?

テキトー教師DotAI 認定講師

いきなり本番のリポジトリで試す人が多いんですけど、まずは検証用の小さなプロジェクトで一度走らせるのが安心です。

室谷代表取締役

見る観点は2つで、狙った場面で発火するかと、余計な場面で出しゃばらないか。後者の方が見落としやすいんですよね。

テキトー教師DotAI 認定講師

たしかに。指示を足すと効きすぎることがあって、そこの調整が実務だと一番時間を食います。

Q5. 属人化した業務知識をスキルに移すと何が変わりますか?

室谷代表取締役

一番大きいのは引き継ぎのコストなんですよ。頭の中にしかない手順を書き出すだけで、その作業にかかってる時間が可視化される。

時給で換算すると、削れていた無駄が見えてくるんですよね。

テキトー教師DotAI 認定講師

書く過程で「この手順、実はいらなかった」に気づけるのも大きいですね。初めて触る人がつまずくポイントをそのまま書き添えておくと、あとから入る人がかなり読みやすくなります。

室谷代表取締役

あと、放っておくと古いまま更新されない手順書になりがちなので、誰がメンテするかだけは最初に決めておいた方がいいですね。

まとめ

室谷代表取締役

ここまで来ると、スキルは便利機能というより業務の型を残す仕組みなんですよね。まず一つ、毎回同じように頼んでしまっている作業を書き出してみる。

それが最初の一歩だと思います。

テキトー教師DotAI 認定講師

そうですね。最初から完璧なSKILL.mdを目指すより、短く書いて動かして、足りないところを足していく方が結果的に早いです。

初めて触る人は、保存場所だけ先に確認しておくと迷わないですよ。

室谷代表取締役

あと、外部のスキルを入れるときは中身を読む。ここは省かない方がいい。

何が書かれているか分からないまま渡すのは、判断としても怖いので。

テキトー教師DotAI 認定講師

たしかに。動くかどうかより、何をされるかの方が大事ですね。

室谷代表取締役

チームで使うなら、置き場所と更新のルールを決めるところまでセットで。そこまでやって初めて、手元のメモが資産になるんだと思います。