AIスキルの移植はフォルダのコピーで終わります｜Claude用のスキルをCopilotがそのまま読む

AIに自分専用の仕事のやり方を覚えさせる「スキル」を作り始めた人が、必ず当たる質問が3つあります。「このサービスに縛られるのでは」「PCを買い替えたらどうなるのか」「チームに配りたいがどうすればいいのか」の3つです。

この3つは別々の問題に見えて、実体を知ると同じ1つの話になります。スキルの正体は SKILL.md というMarkdownファイルが入ったフォルダです。だから移行はフォルダをコピーする。配布は同じフォルダを相手に渡す。他のサービスへの持ち出しも、置き場所を変えるだけです。

しかも書き換えすら要らない組み合わせがあります。GitHub が2025年12月18日に出した告知には「すでにリポジトリの .claude/skills に Claude Code 用のスキルを置いているなら、Copilot がそれを自動的に拾う」と書かれています。Claude 用に書いたものを、ファイルを1つも動かさずに別の会社のエージェントが読みます。

この記事では、自分のスキルがどこにあるかを突き止める手順から始めて、PC移行と配布のやり方、他サービスへの持ち出しで書き換えが要る部分までを扱います。macOS と Windows で事情が違うところ、そして「Windows ではドット始まりのフォルダは実は最初から見えている」という、よく誤って書かれている点も整理します。

いちばん時間を割いたのは、配る前に落とすものです。顧客名、APIキー、社内固有の前提。GitGuardian の2026年のレポートによれば、AIエージェント関連の設定ファイルから公開GitHubに24,008件の秘密情報が露出し、うち2,117件が調査時点でまだ有効でした。ここは一般論ではなく、実際に起きていることとして扱います。

作り込む前に手が止まる、3つの不安

AIに自分専用の仕事のやり方を覚えさせる「スキル」という仕組みがあります。実体は SKILL.md というMarkdownファイルが入ったフォルダなので、コピーできますし、他人にも渡せます。移行も配布も他サービスへの持ち出しも、やることは「フォルダを置く」の1つだけです。

私も業務ごとにいくつか作ってきました。そして作り始めた人から同じ質問を3種類、繰り返し見かけます。

ひとつめは「このサービスに縛られるのでは」。時間をかけて作り込んだあとで乗り換えたくなったら、全部やり直しになるのではないか、という不安です。

ふたつめは「PCを買い替えたらどうなるのか」。せっかく育てたものが新しいマシンで消えるなら、あまり本気で作る気になれません。

みっつめは「チームに配りたいがどうすればいいのか」。自分だけが便利になっても仕方がないので、同僚に渡したい。でも渡し方が分かりません。

この3つは、別々の問題に見えます。1つめはベンダーの話、2つめは自分の環境の話、3つめは組織の話です。ところがスキルの実体が何なのかを知った瞬間に、3つとも同じ1つの話になります。ここが面白いところで、答えを1つ覚えるだけで3つとも片付いてしまいます。

実体は、Markdownファイルが入ったフォルダです

スキルは特別なバイナリでも、クラウド上のどこかに保存された設定でもありません。SKILL.md という名前のテキストファイルが1つ入ったフォルダです。中身は普通のMarkdown、つまり見出しや箇条書きが書けるだけのテキストです。

Agent Skills の公式仕様では、最小構成がこうなっています。

skill-name/
├── SKILL.md          # 必須。設定と指示を書く
├── scripts/          # 任意。実行させたいコード
├── references/       # 任意。参照させたい資料
└── assets/           # 任意。テンプレートなど

必須なのは SKILL.md 1枚だけです。残りは必要なら足す、という位置づけです。

テキストファイルだと分かると、できることが一気に決まります。コピーできます。USBメモリにも入ります。メールにも添付できます。他人に渡せます。中身を開いて読めます。Git（ファイルの変更履歴を記録・共有する仕組み）に載せれば、どこをいつ変えたかも追えます。

つまり、さきほどの3つの不安への答えは全部同じになります。PCの移行はフォルダをコピーする。配布は同じフォルダを相手に渡す。他のサービスへの持ち出しも、置き場所を変えるだけです。

この事実を知っているかどうかで、スキルへの投資判断が変わります。ロックインされると思っている人は作り込みません。作り込まないから効果が出ず、効果が出ないから使わなくなる。この順番で離脱していく人が、どうやらかなり多いようです。もったいない話だと思います。

「オープン標準です」はベンダーの宣伝文句ではありません

とはいえ「他のサービスでも使えます」という説明を、そのサービスの営業資料で読んでも信用しづらいものです。なので公式ドキュメントの記述をそのまま引きます。

まず Anthropic 側。Claude Code の公式ドキュメントにこう書かれています。

Claude Code skills follow the Agent Skills open standard, which works across multiple AI tools.

（Claude Code のスキルは Agent Skills オープン標準に従っており、複数のAIツールをまたいで機能します）

次に、まったく別の会社である Microsoft 側。VS Code の公式ドキュメントにこうあります。

Agent Skills is an open standard that enables portability across different AI agents.

（Agent Skills はオープン標準であり、異なるAIエージェント間での可搬性を可能にします）

同じページには、こうも書かれています。

Skills you create are portable and work across any skills-compatible agent.

（あなたが作ったスキルは可搬であり、スキル対応のあらゆるエージェントで機能します）

2社が別々の公式ドキュメントで同じことを書いている、というのが重要な点です。片方の宣伝ではありません。

この標準そのものは agentskills.io というサイトで公開されていて、由来もはっきり書かれています。

The Agent Skills format was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products.

（Agent Skills 形式はもともと Anthropic が開発し、オープン標準として公開され、増え続けるエージェント製品に採用されてきました）

執筆時点（2026年8月）で、このサイトには対応クライアントとして44の製品が掲載されています。Claude Code、OpenAI Codex、Gemini CLI、GitHub Copilot、VS Code、Cursor といった主要どころが並んでいます。

いちばん強い証拠は、GitHubの告知文です

抽象的な「標準です」という話より、具体的な1文のほうが説得力があります。GitHub が2025年12月18日に出した公式の変更履歴に、こう書かれています。

If you’ve already set up skills for Claude Code in the .claude/skills directory in your repository, Copilot will pick them up automatically.

（もしすでにリポジトリの .claude/skills ディレクトリに Claude Code 用のスキルを置いているなら、Copilot がそれを自動的に拾います）

読み飛ばしやすい一文ですが、書いてある内容はなかなかのものだと思います。Claude 用に書いたスキルを、ファイルを1つも動かさずに、GitHub Copilot が読みます。フォルダ名すら .claude のままです。移植という作業が、そもそも発生しません。

しかもこの告知の日付を見ると、もう少し面白いことが分かります。Anthropic が Agent Skills をオープン標準として公開した日と、同じ日なのです。Anthropic のエンジニアリングブログの冒頭に、こう追記されています。

Update: We’ve published Agent Skills as an open standard for cross-platform portability. (December 18, 2025)

（更新。プラットフォームをまたぐ可搬性のために、Agent Skills をオープン標準として公開しました。2025年12月18日）

標準を公開したその日に、別の会社の製品が対応を発表しています。事前に話が通っていたのだろうな、と想像がつく並びです。

この記事で持ち帰ってもらうもの

以降のセクションで、次の順に進みます。

1. 自分のスキルが実際にどこにあるのかを突き止める手順（macOSとWindowsで違います）
2. PC移行と配布のやり方。この2つが同じ操作であること
3. 配る前に落とすもの。ここが一番事故が起きやすい場所です
4. 他のサービスへ持ち出すときに、そのまま動く部分と書き換えが要る部分
5. プロジェクト機能との違い

なお、まだスキルを1本も作っていないという方は、先にClaudeでフィードバックスキルを作る手順を読んでいただくと、この記事の話が具体的になります。作ったけれど効いているか分からない、という方にはAIスキルの評価データはもう手元にありますが対応します。作る、測る、配る、の3点セットの「配る」が本記事です。

まず自分のスキルがどこにあるかを突き止める

移行も配布も「フォルダをコピーする」で終わる、と書きました。ところが実際にやろうとすると、最初の一歩でつまずきます。そのフォルダがどこにあるのか分からないからです。

置き場所は4種類あり、個人用のスキルは ~/.claude/skills/<スキル名>/SKILL.md にあります。macOS では Finder で Command + Shift + G を押してこのパスを入力すれば開きます。Windows ではエクスプローラーのアドレスバーに %USERPROFILE%\.claude\skills と入力してください。

作った本人でも場所を答えられないことがあります。スキルを作るときはAIに指示して作ってもらうことが多く、自分でファイルを開いていないからです。

置き場所は4種類あります

Claude Code の公式ドキュメントに、置き場所の一覧が表で載っています。原文の説明はこうです。

Where you store a skill determines who can use it:

（スキルをどこに保存するかで、誰が使えるかが決まります）

先頭の ~（チルダ）はホームフォルダを意味する記号です。macOS なら /Users/あなたのユーザー名、Windows なら C:\Users\あなたのユーザー名 に読み替えてください。

個人で使うスキルはほぼ ~/.claude/skills/ にあります。まずここを見れば見つかります。プロジェクトごとに分けたスキルは、そのプロジェクトのフォルダの中の .claude/skills/ です。

同じ名前のスキルがあると、どれが勝つのか

配布するときに効いてくるので、先に書いておきます。同名のスキルが複数の場所にあるとき、どれが使われるかは決まっています。公式ドキュメントの記述です。

When skills share the same name across levels, enterprise overrides personal, and personal overrides project.

（複数のレベルで同じ名前のスキルがある場合、enterprise が personal を上書きし、personal が project を上書きします）

順番を書き出すと、組織 → 個人 → プロジェクトの順に強く、プロジェクトが最下位です。

ここは直感に反すると思います。私も最初は逆だと思い込んでいました。リポジトリにコミットして共有したスキルは、そのプロジェクトを開いている以上いちばん優先されそうなものです。でも実際は、相手が同じ名前の個人スキルを持っていたら、そちらが勝ちます。

チームに配ったスキルが「なぜかこちらでは前のまま動く」と言われたら、まずこれを疑ってください。相手の ~/.claude/skills/ に同名のスキルが残っています。

なお、以前は /コマンド名 を作るのに .claude/commands/ にファイルを置く方式がありました。これはスキルに統合されています。公式ドキュメントの記述です。

Custom commands have been merged into skills. A file at .claude/commands/deploy.md and a skill at .claude/skills/deploy/SKILL.md both create /deploy and work the same way. Your existing .claude/commands/ files keep working.

（カスタムコマンドはスキルに統合されました。.claude/commands/deploy.md というファイルと .claude/skills/deploy/SKILL.md というスキルは、どちらも /deploy を作り、同じように動きます。既存の .claude/commands/ のファイルはそのまま動作し続けます）

古い方式で作ったものが手元にあっても、捨てる必要はありません。ただし同じ名前で両方あった場合はスキルが勝ちます。

macOSでフォルダを開く

ここからOS別です。macOS のほうが少し面倒なので先に扱います。

macOS の Finder は、名前が半角ドットで始まるフォルダを標準では表示しません。.claude もドットで始まるので、ホームフォルダを開いても見当たりません。

いちばん確実なのは、表示設定を触らずにパスを直接指定して開く方法です。Finder を開いた状態で Command + Shift + G を押すと「フォルダへ移動」の入力欄が出ます。ここに次のように打ってEnterです。

~/.claude/skills

このショートカットは Apple の公式ショートカット一覧に載っています。

Shift-Command-G: Open a Go to Folder window

（Shift-Command-G。「フォルダへ移動」ウインドウを開く）

使い方もAppleの公式ガイドに説明があり、~ がホームフォルダを意味することも書かれています。表示設定を変えなくても、この方法なら一発で開けます。

ホームフォルダ自体を開きたいときは Shift + Command + H です。これも同じ公式一覧に「Open the Home folder of the current macOS user account」と載っています。

隠しファイルをまとめて表示したい場合は、Finder で Command + Shift + .（ピリオド）を押すと表示と非表示が切り替わります。ただしこのショートカットは、私が確認した範囲では Apple の公式ショートカット一覧に記載が見当たりませんでした。動くことは確認していますが、公式の手順としては先ほどの Command + Shift + G を使うほうが確実です。

ターミナルを使う方は、次の1行でも同じフォルダが Finder で開きます。

open ~/.claude/skills

open コマンドの説明は macOS に同梱されているマニュアル（ターミナルで man open と打つと読めます）にあり、「ファイルのアイコンをダブルクリックしたのと同じように開く」と書かれています。

Windowsでフォルダを開く

ここで、よく見かける説明を1つ訂正しておきます。私自身、しばらく間違って覚えていた部分です。

「先頭がドットのフォルダは標準では見えないので、隠しファイルの表示設定をオンにしてください」という手順をよく見かけます。macOS ではその通りです。でも Windows では、.claude フォルダは最初から普通に見えています。

理由は、Windows の「隠す」という仕組みが macOS と違うからです。Windows では隠しかどうかは FILE_ATTRIBUTE_HIDDEN というファイルの属性で決まります。Microsoft の公式リファレンスにこう定義されています。

FILE_ATTRIBUTE_HIDDEN 2 (0x00000002) The file or directory is hidden. It is not included in an ordinary directory listing.

（ファイルまたはディレクトリが隠しである。通常のディレクトリ一覧には含まれない）

名前がドットで始まるかどうかは関係ありません。ドットで始まる名前を隠す慣習は、もともとUnix系のシェルのものです。

これを裏づける材料が Git の公式ドキュメントにあります。core.hideDotFiles という設定項目の説明です。

(Windows-only) If true, mark newly-created directories and files whose name starts with a dot as hidden. If dotGitOnly, only the .git/ directory is hidden, but no other files starting with a dot. The default mode is dotGitOnly.

（Windows専用。trueにすると、ドットで始まる名前の新規ディレクトリとファイルを隠しとしてマークする。dotGitOnly なら .git/ ディレクトリだけが隠され、他のドット始まりのファイルは隠されない。既定モードは dotGitOnly）

Windows専用のこの設定が存在すること自体が、「Windowsは放っておくとドットファイルを隠さない」ことの裏返しの証明になっています。そしてGitは既定で .git だけに隠し属性を付けるので、隠れているのは .git だけです。.claude も .gitignore も .vscode も、エクスプローラーで普通に見えます。

なので Windows の手順はこうなります。エクスプローラーを開いて、アドレスバー（Ctrl + L か Alt + D でフォーカスが移ります）に次を打ってEnterです。

%USERPROFILE%\.claude\skills

%USERPROFILE% は「自分のユーザーフォルダ」を指す環境変数で、Microsoft の公式リファレンスでは %SystemDrive%\Users\%USERNAME% に展開されると定義されています。アドレスバーはこの変数を展開してくれます。Win + R（ファイル名を指定して実行）に同じパスを打っても開きます。

このやり方は変な裏技ではありません。Microsoft 自身が、隠しフォルダにあるOutlookのデータを扱うサポート記事で「表示設定を変えるより、パスを直接打つのが手っ取り早い」という案内をしています。

もし何かの理由で隠しファイルの表示自体を切り替えたい場合、Windows 11 の手順はMicrosoft の公式ページにあります。英語版の原文はこうです。

Open File Explorer from the taskbar. Select View > Show, then select Hidden items to view hidden files and folders.

（タスクバーからエクスプローラーを開きます。「表示」から「表示」を選び、「隠しアイテム」を選ぶと隠しファイルと隠しフォルダーが表示されます）

日本語のWindows 11では「表示」→「表示」→「隠しファイル」にチェックを入れる、という操作になります。なおこのページの日本語訳は機械翻訳が崩れていて「非表示のアイテム」という項目名が出てきますが、実際の日本語UIにそのラベルはありません。画面上で探すときは「隠しファイル」を見てください。

VS Codeで開く場合

エディタで直接開きたい場合、VS Code なら .claude フォルダは何もしなくても表示されます。VS Code が既定で非表示にしているのは .git .svn .hg .DS_Store Thumbs.db の5つだけで、公式ドキュメントにもこう書かれています。

By default, VS Code excludes some folders from showing in the Explorer view, such as .git. Use the files.exclude setting to configure rules for hiding files and folders from the Explorer view.

（既定では、VS Code はエクスプローラービューの表示から .git などいくつかのフォルダーを除外します。files.exclude の設定を使うと、どのファイルやフォルダーを隠すかのルールを設定できます）

コマンドラインが使える方なら、次の1行でスキルのフォルダをそのままVS Codeで開けます。

code ~/.claude/skills

ここまでで、自分のスキルがどこにあるかは分かりました。次はそれを運ぶ話です。

PC移行も他人への配布も、フォルダをコピーするだけ

場所が分かったので、運びます。PCを買い替えるときは ~/.claude/skills/ を新しいPCの同じ場所に置く。他人に配るときは、そのフォルダを相手に渡して同じ場所に置いてもらう。この2つは操作としてまったく同じで、違うのは行き先が自分のPCか他人のPCかだけです。

3人以上に配るならGitのリポジトリ（変更履歴つきでファイルを共有する置き場）に入れて、各自に取得してもらう形になりますが、それも「フォルダを置く」の延長でしかありません。ここが記事の背骨にあたる部分です。

PCを買い替えるとき

やることは1つです。古いPCの ~/.claude/skills/ を、新しいPCの同じ場所に置く。以上です。

手順として書き下すとこうなります。

1. 古いPCで ~/.claude/skills を開く（開き方は前のセクションのとおり）
2. その skills フォルダごとコピーする。USBメモリでも、クラウドストレージでも、zipにしてメール添付でも構いません
3. 新しいPCで ~/.claude/ を開き、そこに skills フォルダを置く
4. 新しいPCでAIを起動する。スキルの一覧に出てくれば成功です

3で ~/.claude/ フォルダがまだ無い場合は作ってください。Windows のエクスプローラーでドット始まりのフォルダを新規作成できないという話が昔ありましたが、Windows 10 のバージョン1903以降とWindows 11では普通に作れます。うまくいかない古い環境なら、コマンドプロンプトで mkdir .claude と打つのが早いです。

コピーする対象について補足します。~/.claude/ の中には skills 以外のものも入っていることがあります。全部持っていっても構いませんが、最低限必要なのは skills フォルダだけです。逆に、そこに認証情報やセッションの記録が入っている場合もあるので、中身を確認せずに丸ごとクラウド共有フォルダに置くのは避けてください。この話は次のセクションで詳しくやります。

他人に配るとき

配布も同じ操作です。渡したいスキルのフォルダを相手に渡して、相手の ~/.claude/skills/ に置いてもらう。

自分のPC間で運ぶか、他人のPCに運ぶかの違いしかありません。だから「移行の手順」と「配布の手順」を別々に覚える必要がありません。覚えることが1つで済むというのは、地味ですが効きます。

ただし配布のときだけ増える工程があります。渡す前に中身を見るという工程です。自分のPC間なら中身が何であれ問題ありませんが、他人に渡すなら話が変わります。次のセクションがまるごとこの話です。

チームで共有するならGitに置く

3人以上に配るなら、手渡しではなくGitのリポジトリに置いて、各自に git clone（リポジトリの中身を自分のPCに複製するコマンド）してもらうのが素直です。理由は配りやすさではなく、更新が回るからです。

手渡しだと、スキルを直したときに全員に配り直す必要があります。誰が古いバージョンを持っているか分からなくなります。Gitに置けば、各自が git pull（更新分を取り込むコマンド）を打つだけで最新になりますし、誰がいつ何を変えたかも残ります。

SKILL.md はただのテキストなので、Gitの差分表示がそのまま効きます。「この判断基準はいつ、なぜ足されたのか」がコミット履歴から読めるようになります。これは思っていた以上に効きました。スキルは一度書いて終わりではなく育てるものなので、育った経緯が残っていると、後から入った人の理解が早くなります。

置き方は2通りあります。

ひとつは、共有したいスキルをプロジェクトのリポジトリの .claude/skills/ に入れてコミットする方法です。そのプロジェクトを clone した人には自動的に入ります。プロジェクト固有のスキルならこれが一番自然です。

もうひとつは、スキル専用のリポジトリを立てる方法です。各自が好きな場所に clone して、そこから ~/.claude/skills/ へ配置します。プロジェクトをまたいで使うスキルはこちらです。

後者のとき、コピーではなくシンボリックリンク（実体は別の場所にあって、そこへの参照だけを置く仕組み）を使う手もあります。Claude Code はこれに対応していて、公式ドキュメントにこう書かれています。

A <skill-name> entry in the enterprise, personal, or project locations can be a symlink to a directory elsewhere on disk. Claude Code follows the symlink and reads SKILL.md from the target directory, and if the same target is reachable from more than one location, Claude Code loads the skill once.

（enterprise、personal、project の各場所にあるスキル名のエントリは、ディスク上の別の場所へのシンボリックリンクにできます。Claude Code はリンクをたどってリンク先の SKILL.md を読みます。同じリンク先が複数の場所から到達できる場合でも、スキルは1回だけ読み込まれます）

リンクにしておくと、git pull した内容がそのまま反映されます。コピーだと毎回コピーし直しになるので、更新が頻繁なら検討する価値があります。ただし最初の1歩としてはコピーで十分です。動くものを先に作ってから、面倒になったらリンクに変える、くらいの順番で構いません。

モノレポの場合

1つのリポジトリに複数のパッケージが入っている構成の場合、パッケージごとにスキルを持たせられます。同じ公式ドキュメントの記述です。

Skills also load from nested .claude/skills/ directories below your working directory. When Claude reads or edits a file in a subdirectory, skills from that subdirectory’s .claude/skills/ become available. This lets a monorepo package provide its own skills that apply when working on that package, even if the session started at the repo root.

（作業ディレクトリより下の階層にある .claude/skills/ ディレクトリからもスキルが読み込まれます。Claude がサブディレクトリのファイルを読んだり編集したりすると、そのサブディレクトリの .claude/skills/ にあるスキルが利用可能になります。これにより、セッションがリポジトリのルートで始まっていても、モノレポの各パッケージが自分専用のスキルを提供できます）

このケースでは、同名でも上書きされずに両方が生き残り、apps/web:deploy のようにディレクトリ名で修飾された名前が付きます。前のセクションで書いた「同名なら上書き」のルールとは挙動が違うので、混同しないでください。

同期されない場所があります

ここは移行のときに引っかかるので、明示しておきます。

Claude には、ブラウザで使う claude.ai、開発者向けのAPI、そしてターミナルで使う Claude Code という3つの入口があります。この3つの間でスキルは自動同期しません。公式ドキュメントの記述です。

Custom Skills do not sync across surfaces. Skills uploaded to one surface are not automatically available on others

（カスタムスキルはサーフェス間で同期しません。ある入口にアップロードしたスキルが、自動的に他の入口で使えるようになることはありません）

同じページには、共有の範囲についてもこう書かれています。

claude.ai: Individual user only. Each team member must upload separately.

（claude.ai は個人ユーザーのみ。チームメンバーはそれぞれ個別にアップロードする必要があります）

つまり claude.ai でスキルを使っている場合、組織で一括配布する仕組みは執筆時点では用意されていません。全員が自分でアップロードします。Claude Code ならファイルシステム上のフォルダなので、ここまで書いてきたコピーやGitでの配布が効きます。

チーム配布を考えているなら、この違いは事前に把握しておいたほうが計画が狂いません。

配る前に落とすもの

ここが一番事故が起きる場所です。そして日本語の解説記事でほとんど触れられていない場所でもあります。

自分用に作ったスキルには、他人に渡してはいけないものが混ざります。落とすべきものは、顧客名や案件名などの固有名詞、APIキーやパスワード、そして自分の部署でだけ成り立つ社内固有の前提の3種類です。自分だけが読むつもりで書いたので、混ぜた自覚がありません。

GitGuardian の2026年のレポートによれば、AIエージェント関連の設定ファイルから公開GitHubに24,008件の秘密情報が露出し、うち2,117件が調査時点でまだ有効でした。一般論ではなく、実際に起きていることです。

どのくらい起きているのか

一般論として「気をつけましょう」と書いても行動は変わらないので、数字を出します。

セキュリティ企業の GitGuardian が毎年出している調査にState of Secrets Sprawl 2026というレポートがあります。公開されているGitHubのコミットを走査して、APIキーやパスワードがどれだけ漏れているかを数えたものです。

2025年の1年間で、公開GitHubのコミットに新しく追加されたハードコードされた秘密情報は約2,865万件、前年比34%増でした。レポートの原文です。

28.65 million new hardcoded secrets were added to public GitHub commits in 2025 alone, a 34% increase year over year and the largest single-year jump we’ve recorded.

（2025年だけで2,865万件の新しいハードコードされた秘密情報が公開GitHubのコミットに追加されました。前年比34%増で、私たちが記録した中で単年としては最大の増加です）

前年の2025年版レポートでは2024年分が23,770,171件でしたから、増え続けています。GitHub 自身も別の集計で「2024年だけで3,900万件超を検出した」と述べています。検出の仕組みも対象範囲も違う別々の調査なので数字は一致しませんが、桁の感覚としてはどちらも同じ方向を指しています。

ここまでは一般的な話です。この記事に効いてくるのは、同じレポートのAI関連の数字です。

AIサービス関連の秘密情報の漏洩は、2025年に1,275,105件、前年比81%増でした。そして、AIエージェント向けの設定ファイルについてこう書かれています。

we identified 24,008 unique secrets exposed in MCP-related configuration files across public GitHub, including 2,117 unique valid credentials.

（公開GitHub全体のMCP関連の設定ファイルから、24,008件のユニークな秘密情報を特定しました。そのうち2,117件は有効な認証情報でした）

MCPはAIエージェントを外部ツールにつなぐ仕組みで、その設定ファイルというのは、この記事で扱っているものと同じ「AIに渡すための手元のテキストファイル」です。そこから2万4千件が公開リポジトリに露出していて、2千件超が調査時点でまだ生きていた、という話です。

もう1つ、レポートには次の数字もあります。

Claude Code-assisted commits showed a 3.2% secret-leak rate, versus a 1.5% baseline across all public GitHub commits.

（Claude Code が支援したコミットの秘密情報漏洩率は3.2%で、これに対し公開GitHubの全コミットのベースラインは1.5%でした）

2倍強です。ただしレポートは、この数字の直後に釘を刺しています。

it should not be read as a simple tool failure. Developers remain in control

（これを単純なツールの失敗と読むべきではありません。開発者が主導権を持っています）

私もこの但し書きに同意します。ツールが秘密情報を作り出しているわけではありません。手を動かす速度だけが上がって、確認する工程が元の速度のまま取り残されている。そういう話だと思います。

だとすると対策は、道具を疑うことではありません。手順に「配る前に見る」を1つ足すだけです。

落とすもの3種類

自分用のスキルから抜くべきものは、経験上この3つに分かれます。

顧客名・案件名などの固有名詞

スキルには判断基準を書きます。判断基準を具体的にしようとすると、実例を入れたくなります。「A社の案件ではこう判断した」と書くのが一番伝わるからです。そして書いた実例には、社名も担当者名も案件名もそのまま入っています。

社内の別部署に渡すだけならまだしも、社外や公開リポジトリに出た瞬間に守秘義務の問題になります。個人情報保護委員会も生成AIの利用について注意喚起を出していて、事業者向けに「あらかじめ本人の同意を得ずに個人データを含むプロンプトを入力し、それが応答結果の出力以外の目的で取り扱われる場合、個人情報保護法違反となる可能性がある」と述べています。スキルファイルはAIに読ませる前提のテキストなので、この注意の射程に入ります。

対処は、実例を業種と状況だけに抽象化することです。「A社」を「製造業の既存顧客」に置き換えても、判断基準としての機能はほとんど落ちません。

APIキー・パスワード・トークン

「このAPIを叩くには次のキーを使う」という手順を書いているうちに、勢いで実物を貼ってしまう事故です。書いた本人は「あとで消す」と思っていて、そのまま忘れます。

これがGitGuardianの数字が示していることそのものです。手順を書く場所と認証情報を置く場所を最初から分けておくと、そもそも混ざりません。

社内固有の前提

これは見落としやすい種類です。「金曜の締切に間に合わせる」「部長承認が要る案件は除く」といった、自分の部署でだけ成り立つ条件です。

秘密ではないので漏れても事故にはなりません。ただ、受け取った側の環境では成立しません。相手はその前提が間違っていることに気づかないまま、ずれた判断をAIに繰り返させることになります。

漏洩と違って警告も出ませんし、誰も困っていることに気づきません。発見が遅れる分、こちらのほうがやっかいな気がしています。

配る前のチェックリスト

渡す直前に、SKILL.md と同梱ファイルを開いて次を見てください。5分で終わります。

1. 実在する会社名・製品名・人名が書かれていないか
2. 案件番号・契約番号・社内システムの識別子が書かれていないか
3. APIキー、パスワード、トークン、接続文字列が書かれていないか
4. 社内ネットワークでしか届かないURLやサーバー名が書かれていないか
5. 自分の部署でだけ成り立つ前提が、条件として書かれていないか
6. scripts/ や references/ の中も同じ目で見たか

6番を忘れがちです。SKILL.md だけ確認して安心してしまいますが、同梱したスクリプトや参照ファイルにも同じものが入っています。Anthropic の公式ドキュメントも、受け取る側への注意としてこう書いています。

Review all files bundled in the Skill: SKILL.md, scripts, images, and other resources.

（スキルに同梱されたすべてのファイルを確認してください。SKILL.md、スクリプト、画像、その他のリソースです）

渡す側も同じ範囲を見る必要があります。

手作業に自信がないなら、検出ツールを1本かけておく手もあります。gitleaks は無料で使えて、dir というコマンドを指定するとGitの管理下にないフォルダもそのまま走査できます。~/.claude/skills/ を直接指定して確認できるので、この用途には合っています。

GitHubに置く運用なら、GitHub 自身のシークレットスキャン機能が公開リポジトリでは無料で動きます。秘密情報を含む変更を送信する前に止めてくれる push protection という機能もあります。

ただしツールは補助です。ツールが検出できるのは形が決まっているもの、つまりAPIキーのような文字列です。顧客名も社内前提も検出できません。目で見る工程は省けません。

「出力から除く」と「ファイルから消す」は別の話です

ここが混同されやすいので、はっきり分けます。

スキルの中に「出力に固有名詞を含めないこと」と書いておく、という対処があります。これ自体は正しい指示です。AIが生成する文章から社名が消えます。

ただし、それは出力の話です。スキルファイル本体に書いてある社名は1文字も消えません。

相手に渡すのはファイルそのものです。相手はそれをテキストエディタで開けます。開けば、判断基準の実例として書いてある「A社」がそのまま読めます。出力フィルタは出力にしか効きません。ファイルの中身には効きません。

言われれば当たり前なのですが、混同している状態だと「対策済み」と思い込んでチェック工程を飛ばします。順番としては、まずファイルから消す。それとは別に、必要なら出力の指示も書く。この2つは目的が違う別々の作業です。

受け取る側も同じことをします

配布の話をすると片方向になりがちですが、逆もあります。他人が作ったスキルを受け取ったときは、自分が確認する側です。

VS Code の公式ドキュメントは、共有スキルの使い方の手順として「リポジトリで探す → 自分のフォルダにコピー → SKILL.md をレビューして自分用に調整する」を挙げたうえで、こう注意しています。

Always review shared skills before using them to ensure they meet your requirements and security standards.

（共有されたスキルは、自分の要件とセキュリティ基準を満たしているか確認するため、使う前に必ずレビューしてください）

Anthropic 側はもう少し踏み込んだ表現をしています。

Skills give Claude new capabilities through instructions and code, which also means a malicious Skill can direct Claude to invoke tools or execute code in ways that don’t match the Skill’s stated purpose.

（スキルは指示とコードによってClaudeに新しい能力を与えます。これは裏を返せば、悪意あるスキルが、そのスキルが標榜する目的とは異なる形でツールを呼び出したりコードを実行したりするようClaudeに指示できる、ということでもあります）

スキルは指示だけでなくスクリプトを同梱できます。便利さと危うさは同じ性質から来ています。OWASP が公開しているLLMアプリケーションのリスク一覧でいえば、LLM01 Prompt Injection、LLM02 Sensitive Information Disclosure、LLM03 Supply Chain の3つがここに関係します。特に3つめは「配布物経由で汚染が広がる」という話なので、スキルを配る・受け取るという行為そのものが該当します。

読むといっても難しいことではありません。テキストです。5分あれば読めます。「知らないフォルダのファイルを消す」「外部のURLにデータを送る」といった、そのスキルの目的と関係のない動作が書かれていないかを見れば十分です。

組織として配布の仕組みを作る段階になると、誰が承認するかという話になります。そこは情シスがAIエージェントの許可をどう判断しているかで扱っているので、そちらを参照してください。

他のサービスへ持ち出す

3つめの不安、「このサービスに縛られるのでは」に戻ります。ここで具体的な話をします。

結論を先に書くと、VS Code と GitHub Copilot は書き換えも移動も不要でそのまま読みます。OpenAI Codex と Gemini CLI はフォルダを置く場所だけ変えます。書き換えが要るとしたら SKILL.md の冒頭に書く設定欄の書き方くらいで、それも最初から標準に合わせておけば起きません。

なお、以下の仕様はすべて執筆時点（2026年8月）に公式ドキュメントで確認したものです。この分野は動きが速いので、実際に作業される際はリンク先の原文で最新を確認してください。

そのまま動く部分

調べていていちばん驚いたのは、書き換えが一切要らない組み合わせがあることでした。

VS Code と GitHub Copilot は、スキルを探す場所として次を見ます。公式ドキュメントの表です。

.claude/skills/ と ~/.claude/skills/ が入っています。Claude 用に置いた場所を、そのまま見に行きます。

だから Claude Code でスキルを作った人がやることは、ゼロです。VS Code を開けば Copilot が拾います。前のセクションで引いた GitHub の告知が「Copilot will pick them up automatically」と書いているのは、この表のことです。

設定も基本的に不要です。chat.useAgentSkills という設定が有効化のスイッチですが、既定値が true なので、通常は何も触らずに使えます。別の場所も見てほしい場合は chat.agentSkillsLocations で追加できます。モノレポでサブフォルダを開いている場合は chat.useCustomizationsInParentRepositories を有効にすると親リポジトリのスキルも見つかりますが、こちらは既定で無効です。

置き場所を変えれば動く部分

他のサービスは、フォルダ名が違います。中身は同じなので、置く場所を変えるだけです。

OpenAI Codex は .agents/skills を見ます。公式ドキュメントによれば、作業ディレクトリからリポジトリのルートまで各階層の .agents/skills を走査し、加えてホームフォルダの ~/.agents/skills も見ます。ChatGPT 側については別の公式ヘルプにこう書かれています。

OpenAI Skills follow the Agent Skills open standard, so you can download them from one product and install them in another.

（OpenAI のスキルは Agent Skills オープン標準に従っているので、ある製品からダウンロードして別の製品にインストールできます）

Gemini CLI は ~/.gemini/skills/ を見ますが、公式ドキュメントによれば ~/.agents/skills/ も別名として扱われます。ドキュメントの書き出しはこうです。

Based on the Agent Skills open standard, a “skill” is a self-contained directory that packages instructions and assets into a discoverable capability.

（Agent Skills オープン標準に基づき、「スキル」とは、指示とアセットをまとめて発見可能な機能にした自己完結型のディレクトリです）

Google は公式のスキルリポジトリも公開しています。

Gemini のブラウザ版でもスキルを扱えますが、条件が付きます。公式ヘルプによれば、執筆時点では Gemini Spark 限定で、有料プラン（Google AI Pro または Ultra）と個人アカウントが必要です。さらに欧州経済領域、ナイジェリア、スイス、英国では利用できないと明記されています。日本からは使えますが、対象地域は変わる可能性があるので確認してください。

なお Gemini には「Gems」という別の機能があります。名前が似ていますが Skills とは別物なので、混同しないでください。

まとめると、フォルダ名の対応はこうなります。

同じ実体を複数の場所から見せたいなら、前のセクションで触れたシンボリックリンクが使えます。1箇所を正本にして、各サービスの場所からそこへリンクを張る形です。

書き換えが要る部分

「そのまま動く」と書きましたが、完全な互換ではありません。引っかかる可能性がある箇所を挙げます。

frontmatter の厳しさが違う

SKILL.md の冒頭には、frontmatter（ファイルの先頭に置く設定欄）としてYAML形式でメタデータを書きます。YAMLは name: 値 のように項目名と値を並べるだけの書き方なので、見た目は難しくありません。

標準の仕様では name と description の2つが必須です。name には制約があり、1〜64文字で、使えるのは小文字の英数字とハイフンだけです。先頭と末尾にハイフンは置けず、ハイフンを連続させることもできません。そして親ディレクトリ名と一致している必要があります。

ところが Claude Code は緩めていて、公式ドキュメントに「All fields are optional」と書かれています。name を書かなければフォルダ名が使われ、description を書かなければ本文の最初の段落が代わりに使われます。

つまり Claude Code だけで動かしているうちは、frontmatter を書かなくても動いてしまう。そして他のサービスに持っていったときに、必須項目が無いと言われる可能性があります。移植でつまずくとしたら、まずここだろうなと思います。

対処は簡単です。最初から標準の厳しいほうに合わせて書いておく。name と description を明示して、name はフォルダ名と揃える。これだけで移植時のトラブルはほぼ消えます。

呼び出し方が違う

/スキル名 で呼ぶのか、別の記号なのか、そもそも自動で選ばれるのかは、サービスごとに違います。中身は動きますが、呼び出しの操作は覚え直しになります。

独自拡張は移植先で無視される

Claude Code の公式ドキュメントは、標準と独自拡張を明示的に分けて書いています。

Claude Code extends the standard with additional features like invocation control, subagent execution, and dynamic context injection.

（Claude Code は、呼び出し制御、サブエージェント実行、動的なコンテキスト注入といった追加機能で標準を拡張しています）

この3つの拡張機能は標準の外側にあるので、他のサービスでは効きません。裏を返せば、拡張機能を使っていなければ移植で失われるものはありません。

AGENTS.md との関係

似た話として AGENTS.md という別の仕組みがあります。プロジェクトのルートに置いて、そのリポジトリで作業するAIエージェント全般に前提を伝えるファイルです。公式サイトは「エージェント向けのREADME」と説明していて、必須項目は無く、ただのMarkdownだとしています。

ここで注意点を1つ。この2つは別レイヤーの規格として並存しているだけで、連携している関係ではありません。私が確認した範囲では、agents.md のサイト本文に Agent Skills への言及は1つもありませんでした。「AGENTS.md と Agent Skills が連動している」といった説明を見かけたら、疑ってください。

使い分けとしては、リポジトリ全体の前提を書くのが AGENTS.md、特定の作業の手順を書くのがスキル、という整理になります。

標準になった経緯

余談ですが、この状況は最初から見えていたわけではありません。

Anthropic の公式スキルリポジトリに「異なるLLMプロバイダで使うにはスキルをどこに置けばいいのか」という質問が2025年12月に立っています。当時の結論は「共通の置き場所は無い。可搬なのはフォーマットであって、パスではない」でした。

そこで2026年3月に、あるユーザーがこう書いています。

If it gets adopted by even one other tool, it becomes the de facto standard.

（他のツールが1つでも採用すれば、事実上の標準になる）

この投稿は Anthropic の公式回答ではなく、コミュニティの一般ユーザーの意見です。なので公式見解として扱うべきではありません。ただ、そこで書かれた予測は当たりました。VS Code と GitHub Copilot が .claude/skills を読み、OpenAI と Google が標準への準拠を公式に明記しました。執筆時点で agentskills.io に掲載されている対応クライアントは44あります。

「1つでも採用したら」という条件は、ずいぶん余裕をもって満たされたことになります。半年でこう動くとは、当時の投稿者も思っていなかったのではないでしょうか。

配ったスキルが相手の手元で実際に使われるかどうかは、また別の問題です。技術的に配れることと、組織に定着することは違います。この論点は配布ではなくforkさせる設計へで扱っているので、配布の計画を立てる前に読んでおくと遠回りが減ります。

プロジェクト機能との違いと、これからの見通し

移行と配布の話が済んだので、最後に隣接する疑問に答えておきます。「プロジェクトにファイルを入れるのと何が違うのか」です。

公式ドキュメントの記述で比べると、差ははっきりしています。プロジェクト機能は参照させる資料の置き場で、スキルはそれに加えてスクリプトを同梱して実行させられます。参照させたい資料があるならプロジェクト機能、判定や整形を毎回同じ結果にしたいならスキル、という使い分けになります。

Claude にも ChatGPT にも「プロジェクト」という機能があり、ファイルをアップロードして参照させられます。GPTs や Gems も似た形です。では、こうしたプロジェクト系の機能とスキルの差は、どこから来るのでしょうか。

参照させる場所か、実行させる場所か

公式ドキュメントの記述だけを並べると、差はかなりはっきりしています。

Claude のプロジェクト機能について、公式ヘルプは「独自のチャット履歴とナレッジベースを持つ自己完結型のワークスペース」と説明しています。アップロードしたファイルの扱いについては、別のヘルプ記事にこうあります。

Claude uses a project knowledge search tool to retrieve relevant information from your uploaded documents

（Claude はプロジェクトナレッジの検索ツールを使って、アップロードされたドキュメントから関連情報を取得します）

検索して取得する、と書かれています。実行するとは書かれていません。私が確認した範囲では、プロジェクトに置いたファイルを実行する旨の記述は公式ドキュメントに見当たりませんでした。

対してスキルは、公式ドキュメントがはっきり書いています。

Code: Executable scripts (fill_form.py, validate.py) that Claude runs using bash, providing deterministic operations without loading their code into context

（コード。Claude が bash を使って実行する実行可能スクリプト。コードをコンテキストに読み込むことなく、決定的な処理を提供します）

「決定的な処理」というのがポイントです。Anthropic のエンジニアリングブログは、なぜコードを同梱するのかをこう説明しています。

Large language models excel at many tasks, but certain operations are better suited for traditional code execution.

（大規模言語モデルは多くのタスクに優れていますが、ある種の処理は従来のコード実行のほうが適しています）

具体例で考えると分かりやすいと思います。「この単語が含まれていたら必ず差し戻す」という判定を、文章での指示だけでやらせると、たまに見逃します。同じ入力を渡しても、回答が揺れます。同じ判定をスクリプトに書いて実行させれば、毎回同じ結果になります。

この「たまに揺れる」がどこまで許容できるかが、使い分けの分岐点になる気がしています。

つまり使い分けはこうなります。参照させたい資料を置きたいならプロジェクト機能。判定や整形を毎回きっちり同じにしたいならスキル。

紛らわしいもの

GPTs には Code Interpreter という機能があり、Pythonを実行できます。「じゃあ同じでは」と思うところですが、公式の説明を読むと別の話です。OpenAIのヘルプにはこう書かれています。

ChatGPT writes and runs Python code in a stateful Jupyter notebook environment.

（ChatGPT が Python のコードを書き、状態を保持する Jupyter Notebook 環境で実行します）

主語は ChatGPT です。その場で書いたコードを実行する機能であって、事前に用意して検証済みのスクリプトを毎回同じように走らせる話ではありません。その場で書くということは、書かれるコードが毎回変わりうるということでもあります。

決定性がほしいなら、この違いは無視できません。

トークンの消費のしかたも違います

もう1つ、実務で効いてくる差があります。スキルは全部を読み込みません。段階的に読みます。公式ドキュメントの表を要約するとこうなります。

Claude Code の公式ドキュメントは、この性質を常時読み込まれる設定ファイルと対比して説明しています。

Unlike CLAUDE.md content, a skill’s body loads only when it’s used, so long reference material costs almost nothing until you need it.

（CLAUDE.md の内容と違い、スキルの本文は使われるときにだけ読み込まれます。そのため長い参照資料も、必要になるまではほとんどコストがかかりません）

スクリプトについてはさらに徹底していて、実行してもコード自体は読み込まれず、出力だけがトークンを消費します。100行のスクリプトを走らせても、消費するのは「検証OK」の数トークンだけ、ということです。

なので「スキルを増やすとコンテキストを圧迫するのでは」という心配は、少なくとも増やす段階では当たりません。増えるのは1つあたり約100トークンの説明文だけです。

とはいえ1本のスキルが太っていくと話は別です。公式ドキュメントは SKILL.md の本文を500行以下に保つよう推奨していて、超えるなら分割せよと書いています。分割の考え方はスキル設計をメダリオンアーキテクチャで整理するのほうが主題なので、そちらに譲ります。

これから起きそうなこと

executable なテキストが標準化された、というのが2025年末から2026年にかけて起きたことでした。ここから先は予想混じりですが、2つの方向が見えます。

ひとつは、スキルが職務経歴のような扱いになる方向です。個人が持ち運べる形で仕事のやり方が記述されているので、転職やチーム異動のときに持っていけます。逆に、会社としては「うちの判断基準」をスキルとして整備しておけば、人が入れ替わっても引き継げます。引き継ぎ書がテキストである以上に、実際に動く形で残る、という違いは大きいと思います。

もうひとつは、配布ではなく共同編集が普通になる方向です。今はまだ「作った人が配る」という一方向のモデルですが、Gitに置いてある以上、受け取った側が直して戻せます。実際にそういう運用をしている事例は増えてきています。

どちらにしても前提になるのは、実体がテキストであることです。バイナリだったらこうはなりません。

調査そのものをスキルにする

最後に、私たちが作っているものの話を少しだけ。

スキルを配る運用を始めると、次に出てくるのは「調べ物の型も共有したい」という要求です。市場調査でも競合調査でも、うまい人は決まった手順を踏んでいます。それを言語化してスキルにできれば、チーム全員が同じ深さで調べられるようになります。

ただ、調査の型をスキルにするだけでは足りない部分があります。調べた結果が個人の手元に散らばると、次に調べる人がまたゼロから始めるからです。

私たち Deskrex が開発している Snorbe は、調べた内容をナレッジグラフとして貯めていくリサーチAIエージェントです。JPO、EPO、Google Patents、arXiv、PubMed、Semantic Scholar といった専門データベース群に、クエリの書き方を覚えずに自然な日本語のまま投げられます。

そして調べた内容がワークスペースに残り、次の調査で参照されます。同じテーマを続けて掘るほど、前回の記憶が効いてくる構造です。

スキルが「手順を持ち運ぶ」仕組みだとすれば、こちらは「調べた結果を蓄積して共有する」側です。フォルダをコピーして終わりではなく、配ったあとに育つ状態を作りたいなら、この2つは組み合わせて考える価値があると思います。

まずは1本、自分の調査手順をスキルに書き出してみてください。書き出せた時点で、それはもうコピーできる資産になっています。

よくある質問

Q1. スキルのファイルは結局どこにありますか

個人で使うスキルは ~/.claude/skills/<スキル名>/SKILL.md にあります。~ はホームフォルダのことで、macOS なら /Users/ユーザー名、Windows なら C:\Users\ユーザー名 です。プロジェクトごとに分けたスキルは、そのプロジェクトのフォルダの中の .claude/skills/ です。

macOS では Finder で Command + Shift + G を押して ~/.claude/skills と入力すると開きます。Windows ではエクスプローラーのアドレスバーに %USERPROFILE%\.claude\skills と入力してください。

Q2. Windowsでも隠しファイルの表示設定をオンにする必要がありますか

必要ありません。Windows で「隠し」かどうかを決めているのは FILE_ATTRIBUTE_HIDDEN というファイル属性であって、名前がドットで始まるかどうかではありません。そのため .claude フォルダはエクスプローラーで最初から普通に見えています。

隠れているのは .git フォルダだけです。これは Git が既定で隠し属性を付けているためで、Git の公式ドキュメントにある core.hideDotFiles の説明（既定値が dotGitOnly）がその根拠になります。表示設定が必要なのは macOS の Finder のほうです。

Q3. PCを買い替えるとき、何をコピーすればいいですか

~/.claude/skills/ フォルダを、新しいPCの同じ場所に置くだけです。USBメモリ、クラウドストレージ、zipにしてメール添付、どの方法でも構いません。新しいPCに ~/.claude/ フォルダがまだ無ければ作ってください。

~/.claude/ の中には認証情報やセッションの記録が入っていることもあるので、中身を確認せずに丸ごと共有フォルダへ置くのは避けてください。必要なのは skills フォルダだけです。

Q4. Claude用に作ったスキルを他のサービスでも使えますか

使えます。Agent Skills はオープン標準として公開されていて、執筆時点（2026年8月）で agentskills.io に44の対応クライアントが掲載されています。

VS Code と GitHub Copilot は .claude/skills/ と ~/.claude/skills/ を探索先に含んでいるため、書き換えも移動も不要でそのまま読まれます。OpenAI Codex は .agents/skills、Gemini CLI は ~/.gemini/skills/ または ~/.agents/skills/ を見るので、こちらはフォルダを置く場所だけ変えます。

引っかかりやすいのは frontmatter です。標準では name と description が必須で name は親ディレクトリ名と一致する必要がありますが、Claude Code はこれを任意にしています。最初から標準の厳しいほうに合わせて書いておくと移植時に困りません。

Q5. チームに配る前に何を確認すればいいですか

SKILL.md と同梱ファイルを開いて、次の5点を見てください。実在する会社名・製品名・人名。案件番号や社内システムの識別子。APIキーやパスワード。社内ネットワークでしか届かないURL。自分の部署でだけ成り立つ前提条件。

scripts/ や references/ の中も同じ目で確認してください。SKILL.md だけ見て安心してしまう事故が起きやすい場所です。

Q6. スキルに「出力から固有名詞を除く」と書いておけば安全ですか

安全にはなりません。それは出力に対する指示であって、スキルファイル本体に書いてある社名や案件名は消えないからです。

相手に渡すのはファイルそのものです。相手はテキストエディタで開いて中身を読めます。まずファイルから消す作業と、必要なら出力の指示も書く作業は、目的が違う別々のものだと考えてください。

Q7. スキルとプロジェクト機能は何が違いますか

公式ドキュメントの記述で比べると、プロジェクト機能は参照させる資料の置き場です。Claude のプロジェクトは「project knowledge search tool を使って関連情報を取得する」と説明されていて、置いたファイルを実行するという記述はありません。

スキルは指示に加えてスクリプトを同梱でき、それを実行させられます。「この条件なら必ず差し戻す」のような決定的な処理は、文章での指示より確実になります。しかもスクリプトのコードはコンテキストに読み込まれず、出力だけがトークンを消費します。

参照させたい資料があるならプロジェクト機能、判定や整形を毎回同じにしたいならスキル、という使い分けになります。

Q8. スキルを増やすとコンテキストを圧迫しませんか

増やす段階ではほとんど影響しません。起動時に読み込まれるのは各スキルの名前と説明だけで、公式ドキュメントによればスキル1つあたり約100トークンです。本文は呼び出されたときに初めて読まれ、同梱ファイルは実際に必要になるまで読まれません。

影響が出るのは1本のスキルが太ってきたときです。公式ドキュメントは SKILL.md の本文を500行以下に保つよう推奨しています。超えたら分割を検討してください。

調査手法について

こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot

調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。

また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。

ご利用をご希望の方は、こちらよりお申し込みください。

また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。

冨田到

市場調査やデスクリサーチの生成AIエージェントを作っています 仲間探し中 / Founder of AI Desk Research Agent @deskrex , https://deskrex.ai

www.deskrex.ai/