Agent SkillはAI時代の「持ち運べる業務手順書」になるか――共通仕様と互換性の落とし穴

記事

IT・テクノロジー

2026/07/16 21:38

概要

AIを替えるたび、同じ説明や長いプロンプトを作り直していないでしょうか。Agent Skillは、業務の手順・判断基準・参考資料をひとまとめにし、必要なときだけAIに読み込ませる仕組みです。OpenAI、GitHub、Googleが共通形式への対応を示す一方、「Skill」と呼ばれる機能がすべて互換とは限りません。この記事では、持ち運べる部分と製品固有の部分を分け、安全に最初の1本を作る手順を整理します。

AIエージェントを使う時間が増えるほど、気になってくることがあります。それは、便利な指示ほど特定のチャットやツールに閉じ込められてしまうことです。

「この案件では最初に何を確認するか」「どの資料を根拠にするか」「どこで人に確認を戻すか」。こうした仕事のコツは、モデルの能力そのものではありません。自分やチームが積み上げた業務知識です。

その知識を、毎回の会話で説明する代わりに、再利用できる形へまとめる考え方がAgent Skillです。

Agent Skillは、プロンプト集より一段深い

Agent Skillsの仕様では、Skillは最低限SKILL.mdを含むフォルダーです。そこには、どんな作業で使うかを示す名前と説明、そして作業手順を書けます。必要に応じて、参考資料、テンプレート、スクリプトも同じフォルダーへ同梱できます。Agent Skills Specification

つまり、Skillは「よく使う命令文の保存場所」ではありません。次のような部品をひとまとまりにする、業務手順書のパッケージです。

部品：発動条件／例：「月次レポートを作るとき」「契約書レビューを依頼されたとき」部品：手順／例：情報を集める、事実確認する、下書きを作る、承認を求める部品：判断基準／例：数値の出典がない場合は保留する、公開前は人が確認する部品：参考資料／例：用語集、ブランドガイド、社内ルール部品：成果物／例：Markdown原稿、チェックリスト、レビューコメント

長い手順を毎回すべて読み込ませると、関係のない作業にも余計な文脈を抱え込ませてしまいます。Agent Skillsでは、最初は名前と短い説明だけを見せ、該当する仕事のときに詳細を読み込む「段階的な読み込み」が想定されています。説明文の最適化ガイド

この構造は地味ですが重要です。AIがSkillを選べるかどうかは、モデルの賢さだけでなく、「いつ使う手順なのか」を説明文で明確に書けるかにも左右されます。

いま、共通形式として広がり始めた

2026年7月時点で、少なくともOpenAI、GitHub、GoogleはAgent Skillsのオープン形式への対応を公式に案内しています。

OpenAIは、ChatGPTのSkillsがAgent Skillsオープン標準に従い、別の製品でダウンロード・インストールできると説明しています。SkillsはCodexやAPIでもサポート対象です。OpenAI Help Center

GitHub Copilotも、Agent Skillsをオープン標準として扱い、プロジェクト用・個人用のSkillを利用できます。プロジェクト内の.github/skills、.claude/skills、.agents/skillsなどが配置場所として案内されています。GitHub Docs

Googleも、ADKのSkillについて同じ形式を使い、互換エージェント間で利用できることを説明しています。Google Developers Blog

ここで大切なのは、「AIの乗り換え先を完全に自由にする魔法」ではなく、業務知識を特定のモデルだけに閉じ込めないための共通の土台が育ち始めている、と捉えることです。

「Skill」という名前だけでは、互換性を判断できない

AI製品の発表ではSkillという言葉をよく見かけます。Oracleは2026年7月14日、VS Code、CLI、Codex、Claude Codeなどを使ってエージェントアプリケーションを構築する「AI Studio Skill」を発表しました。Oracle公式発表

AppleもXcode 27で、カスタムSkill、MCP、Agent Client Protocolに対応すると発表しています。Apple公式発表

ただし、これらの公開発表だけからは、それぞれがAgent Skills仕様に準拠しているかまでは確認できません。名前が同じでも、保存形式、権限、接続できるツール、配布方法は別物かもしれません。

持ち運びを前提にするなら、導入前に次の3点を確認しましょう。

SKILL.mdと必要なリソースを、その製品が読み込めるか。使いたいスクリプトやツールへの権限を、その環境で安全に付与できるか。参照するデータや認証情報が、移行先でも同じ条件で扱えるか。

共通仕様に含まれるallowed-toolsは実験的な項目で、対応状況は実装ごとに異なります。ここが「ファイルをコピーしたら同じ結果になる」と言い切れない理由の一つです。Agent Skills Specification

Skill、MCP、エージェントは役割が違う

この3つは一緒に語られがちですが、考える対象が違います。

仕組み：エージェント／考える問い：誰が判断して進めるか／たとえば：依頼を分解し、必要な作業を進めるAI仕組み：Skill／考える問い：どう進めるか／たとえば：月次レポート作成の手順、例外、完了条件仕組み：MCP／考える問い：何につなぐか／たとえば：売上DB、カレンダー、文書保管先、検索ツール

MCPは、AIアプリケーションを外部のデータやツールへ接続するためのオープンな仕組みです。Model Context Protocol

たとえば「月次レポート作成Skill」があっても、売上データを取得する接続先や、その閲覧権限がなければ作業は完了しません。Skillは手順を持ち、MCPは接続口を提供し、エージェントが状況に応じて両者を使います。

この役割分担が分かると、AI導入で起きやすい混乱を避けやすくなります。手順の問題をMCPで解決しようとしたり、データ連携の問題をSkillの文章だけで解決しようとしたりしなくてよくなるからです。

最初の1本は「狭く、安全に」作る

最初から万能な営業支援Skillや全社横断Skillを作る必要はありません。むしろ、失敗しても影響が小さく、成果を確認しやすい作業を選ぶのがおすすめです。

たとえば、次のような作業です。

会議メモを決めた形式で要約し、未決事項を抽出する調査メモを出典付きでMarkdownに整えるリリースノートから社内向けの変更要約を作る問い合わせ下書きを作り、送信前に必ず人へ確認を戻す

設計は、次の5ステップで十分です。

1. 発動条件を一文で決める

「文章を整えるとき」のような広い条件ではなく、「外部公開するリリースノートを日本語で要約するとき」のように、対象と成果物を絞ります。

2. 入力と成果物を固定する

入力は何か、出力はどの形式か、必須項目は何かを書きます。ここが曖昧だと、AIはもっともらしい別の仕事を始めます。

3. 例外と人への確認点を先に書く

数値に出典がない、個人情報を含む、送信や公開を伴う。こうした場合は止まり、何を確認すべきかを出力するようにします。「止まる条件」は、AIを任せるための設計です。

4. 権限は最小限にする

Skillにスクリプトや外部接続を含める場合、必要以上の権限を与えないことが大切です。GitHubも、外部Skillにはプロンプトインジェクションや悪意あるスクリプトが含まれる可能性があるとして、インストール前に内容を確認するよう注意しています。GitHub Docs

5. 同じ入力で複数回試す

AIの出力は毎回完全には同じになりません。1回うまくいっただけで完成とせず、典型例・失敗しやすい例・例外を含む入力で繰り返し試します。Skillは「書いて終わり」ではなく、業務手順と同じく更新する資産です。

外部Skillを入れる前のチェックリスト

作成者、配布元、更新日を確認したかSKILL.mdだけでなく、同梱スクリプトと参照ファイルも読んだか実行コマンド、ネットワーク接続、外部サービスへの書き込みがあるか把握したか読み取り専用の環境で試せるかバージョンを固定し、更新時に差分を確認できるか個人情報、顧客情報、秘密情報を外部へ送らない設計になっているか

OpenAIも、アップロードするSkillはスキャンするものの、スキャンだけで利用可否を判断せず、利用者自身が内容と出所を確認するよう案内しています。OpenAI Help Center