Agent Plugins 1.0.0が公開｜AIエージェントのスキル資産は持ち出せるのか

AIエージェントの導入で最初に決めるべきなのは、どのツールを使うかではない。そこで作った設定を、後から別のツールへ持って行けるかである。

2026年8月10日、AIエージェント向けのパッケージ仕様「Agent Plugins 1.0.0」が公開された。公式サイトによれば、これは異なるAIエージェント間でスキルとMCPサーバの設定を可搬にするためのパッケージ形式である。

仕様が定めるパッケージの構造は、報道および公式サイトの記載によれば次の通りである。plugin.json がプラグインを識別し、対象とするAgent Pluginsのバージョンを示す。skills/ ディレクトリにAgent Skills仕様に従うコンポーネントを格納する。mcp.json に、stdio、Streamable HTTP、またはHTTP+SSE形式のMCPサーバを記述する。

公式サイトの記載では、初期の技術運営委員会のCore Maintainersとして Amazon、Cursor、Microsoft、OpenAI、Vercel が挙げられている。報道によれば、対応を表明しているのはGitHub Copilot、Visual Studio Code、Cursor、ChatGPTおよびCodex、AWS Kiro、Googleである。開発は公開で行われ、提案や技術的な決定は公開されるとされている。新機能の提案はGitHub Discussionsから始まり、実装者の支持を必要とする。将来の拡張として、ファイルシステムのアクセス制御、ユーザー承認フロー、暗号化署名が検討されているという。

**発注側の中堅企業にとって、この動きが持つ意味は一点に集約される。**AIエージェントを社内に導入した会社が、そこで蓄積した業務知識の資産を、ツールを変えても持ち出せる可能性が出てきたということである。逆に言えば、これまでは持ち出せない前提だった。

この記事を読むべき人

• AIエージェントやAIコーディングツールの社内導入を検討している中堅企業
• すでに特定のツールを使い始めており、社内向けの設定を蓄積している会社
• ベンダーからAIエージェント基盤の提案を受けている経営者
• 過去にシステムのベンダーロックインで苦労した経験がある会社
• MCPという言葉を提案書で見かけたが、内容を確認していない会社

「スキル」とは何が資産になるのか

議論の前提として、ここで言う「スキル」が何を指すのかを押さえておく必要がある。技術的な定義ではなく、経営上何が資産になるのかという観点で説明する。

AIエージェントを業務で使うとき、汎用の状態のままでは自社の業務に役立たない。自社の業務手順、判断基準、用語、禁止事項を教える必要がある。この「教えた内容」が、文書やファイルの形で蓄積される。

具体的には、次のようなものが含まれる。

• 自社の見積もり作成の手順と、確認すべき項目
• 顧客対応で使ってよい表現と、避けるべき表現
• 社内の申請フローと、承認が必要になる条件
• 自社の商品構成と、組み合わせの制約
• 過去の失敗事例から導かれた確認項目

**これらは、業務を知っている人が時間をかけて言語化したものである。**そして、言語化する作業そのものが最も費用のかかる部分になる。ツールの利用料より、この作業の人件費のほうが大きい。

**したがって、資産として守るべきなのはツールの契約ではなく、この言語化された内容のほうである。**そして従来、この内容は各ツールが独自の形式で保持しており、別のツールへ移すには作り直しが必要だった。

MCPが何を意味するか

もう一つの構成要素であるMCPについても、経営上の意味を押さえておきたい。

MCPは、AIエージェントが外部のシステムやデータに接続するための接続方式を定めた取り決めである。**業務で使う場合、AIエージェントは単独では役に立たない。**自社の基幹システム、顧客データ、ファイルサーバ、社内の検索といった外部の資源に接続して初めて業務が回る。MCPは、この接続の方法を共通化するものである。

Agent Pluginsが mcp.json として接続設定を含めているということは、「何に接続するか」の設定も、パッケージとして持ち運べる対象になっているということである。

ここから2つの論点が出る。

**論点1：可搬性が高まる。**接続設定を作り直さずにツールを変えられる。

**論点2：接続先の管理が重要になる。**設定が可搬になるということは、その設定が意図せず広がる可能性もあるということである。誰かが作ったプラグインに、想定していない接続先が含まれていた場合、それを取り込んだ環境からその接続先へアクセスが発生する。

**論点2は、将来の拡張として挙げられている「ファイルシステムのアクセス制御、ユーザー承認フロー、暗号化署名」が扱おうとしている領域と重なる。**現時点の1.0.0では、これらは検討中とされている。したがって、可搬性を活かすなら、取り込むプラグインの中身を確認する運用が併せて要る。

Anthropicが名を連ねていないことをどう読むか

報道では、Agent Skills仕様を提唱したAnthropicが、Agent Pluginsの初期の技術運営委員会に含まれていない点が指摘されている。この事実の評価は、発注側にとって実務的な意味を持つ。

**まず、事実として確認できることを整理する。**公式サイトに記載されたCore MaintainersはAmazon、Cursor、Microsoft、OpenAI、Vercelである。Anthropicの名前は、本稿執筆時点で確認した公式サイトの記載には含まれていない。この状況が今後どう変化するかについて、本稿では推測しない。

**発注側が押さえるべきなのは、標準が完全には統一されていない状態にある、という一点である。**そして、この状態は珍しいことではない。技術の標準は、複数の陣営が並存する期間を経て収斂することも、並存したままになることもある。

**この状況で採るべき判断は、「勝ちそうな標準を当てる」ことではない。**当てられないからである。代わりに採るのは、どちらに転んでも自社の資産が失われない形にしておくという判断である。具体的な方法は次節で述べる。

資産を守るための3つの原則

標準の行方に賭けずに資産を守る方法は、実のところ古典的である。AIエージェントに固有の話ではなく、システム発注全般で有効な原則がそのまま当てはまる。

**原則1：中身をテキストで持つ。**業務手順や判断基準を言語化した内容は、**特定のツールの中だけに置かない。**社内の文書管理の場所に、通常のテキストファイルとして原本を持つ。ツールへはそこから取り込む形にする。これだけで、ツールを変えても内容は残る。

**原則2：作った内容の所有関係を契約で明確にする。**ベンダーに構築を依頼した場合、**その過程で作られた設定やプロンプトの内容が誰のものかを契約に書く。**書かれていなければ、契約終了時に持ち出せるかどうかが曖昧になる。

**原則3：接続先の一覧を自社で持つ。**AIエージェントがどの外部資源に接続しているかを、自社の文書として管理する。ツールの設定画面を見なければ分からない状態にしない。

**原則1が最も効果が大きく、最も実行しやすい。**そして、実行されていない会社が最も多い。**理由は、ツールの中で編集するほうが楽だからである。**楽な方を選び続けた結果、資産がツールの中に閉じ込められる。

発注要件にどう書くか

ベンダーにAIエージェントの構築を依頼する場合、要件として書いておくべき項目を挙げる。技術的な指定ではなく、発注側の権利と成果物の形式に関する記述である。

**5行目は、現時点では確定的なことが書けない領域である。**だからこそ「協議事項とする」という形で残しておく。何も書かないと、標準への対応が追加開発として扱われる余地が生まれる。

**3行目も見落とされやすい。**AIエージェントが何に接続しているかは、導入時には明確でも、運用の中で追加されていく。追加のたびに文書を更新する運用がなければ、1年で実態が分からなくなる。

過去のロックインと、今回の違い

システムのベンダーロックインは新しい問題ではない。過去に経験した会社であれば、今回の構造との違いを押さえておくと判断しやすい。

**従来のロックインは、システムそのものが移せないことだった。**特定のベンダーの製品で作られたシステムは、別の製品へ移すのにシステムの作り直しに近い作業が必要になる。移行の費用が高いから移れない、という構造である。

**今回論点になるのは、性質がやや異なる。**AIエージェントに与える業務知識の記述は、それ自体はテキストであり、技術的には移せる。移せないのは、その内容が特定のツールの内部形式で保持されている場合や、ツールの機能に依存した書き方になっている場合である。

**この違いは、対策の難度に直結する。**従来のロックインは、後から解消しようとすると移行費用が発生した。今回の構造は、最初から原本を自社で持つ運用にしておけば、費用をかけずに回避できる。

**ただし、逆も言える。**原本を自社で持たないまま蓄積を続けると、蓄積が増えるほど移せなくなる。**移せない理由が「費用」ではなく「作り直しに要する人の時間」になるため、見積もりにも現れない。**気づいたときには、数百時間分の言語化の成果がツールの中にある、という状態になる。

**したがって、AIエージェントの導入では、最初の設計時点で原本の置き場所を決めることの費用対効果が、従来より高い。**後から直すコストが、費用ではなく時間として現れるためである。

「まだ様子見でよいか」への答え

標準が固まっていない段階で、導入を待つべきかという判断がある。結論としては、待つ理由と待たない理由の両方があり、自社の状況で分かれる。

**待つ合理性がある場合。**大規模な投資を伴う基盤の構築を検討している場合、標準の動向を見てから決める意味はある。構築費用が大きいほど、作り直しの損失も大きい。

**待たない合理性がある場合。**業務知識の言語化そのものは、どの標準が勝っても無駄にならない。むしろ、この作業には時間がかかるため、早く始めるほど有利である。

したがって、実務的な進め方は次のようになる。

**進め方1：業務知識の言語化から始める。**ツールの選定より先に、自社の業務手順と判断基準をテキストで書き出す。**この作業は、AIを使わなくても価値がある。**新人の教育資料としても、業務の標準化の材料としても使える。

**進め方2：小さく試す。**特定の業務、特定の部署に限定して、既存のツールで試す。大規模な基盤の構築は後回しにする。

**進め方3：投資判断は、効果が確認できてから行う。**試した結果で効果が見えた領域に絞って、本格的な構築を検討する。

**この進め方を採ると、標準の動向に関わらず前に進める。**そして、標準が固まった時点で、蓄積した言語化の成果を持ち込める。

業務知識の言語化から始めるための手順

進め方1で述べた作業を、具体的にどう進めるかを示す。

**手順1：対象の業務を1つ選ぶ。**繰り返し発生し、判断基準が存在し、担当が複数いる業務が適している。見積もり作成、問い合わせ対応、書類のチェックなど。

手順2：その業務の熟練者に、判断の理由を言葉にしてもらう。「なぜこの見積もりは通して、こちらは差し戻すのか」。熟練者は理由を言語化していないことが多いため、聞き手が問いを重ねる必要がある。

手順3：出てきた判断基準を、条件と結果の形で書く。「〇〇の場合は△△する」という形式に揃える。曖昧な表現が残る箇所が、AIに任せられない領域を示している。

**手順4：例外と、判断がつかない場合の扱いを書く。**ここが最も重要で、最も抜ける。判断がつかない場合に人へ戻す条件を書いておかないと、AIが誤った判断を続ける。

**手順5：書いた内容を、その業務を知らない人に読ませる。**理解できない箇所が、書かれていない前提の所在である。

**この5手順で得られる文書は、AIエージェントに与える材料であると同時に、業務の標準化の成果物でもある。**そして、どのツールを使うことになっても再利用できる。AI導入の投資として、最も確実に回収できる部分がここである。

よくある質問

Q. Agent Pluginsは、いま使い始めるべきか。 A. 仕様が公開されたばかりの段階であり、対応するツールも拡大の途中である。**本稿執筆時点で、これを前提に基盤を組む判断には慎重であるべきだと考える。**一方、この仕様が想定している「設定を可搬にする」という発想を、自社の運用に取り入れることには待つ理由がない。

Q. MCPで外部システムに接続することのリスクは。 A. AIエージェントが接続先のデータを読み書きできるようになるため、接続先の権限設計が重要になる。読み取り専用でよい接続に書き込み権限を与えていないか、必要な範囲を超えたデータに到達できないかを、接続ごとに確認する必要がある。

Q. ベンダーから「当社の基盤を使えばすべて解決する」と提案されている。 A. 提案の是非は内容によるが、確認すべき点は明確である。**その基盤で作った業務知識の内容を、契約終了後に持ち出せるか。**持ち出せる形式は何か。持ち出しに費用がかかるか。この3点への回答が曖昧な提案は、資産が相手側に残る構造になっている可能性がある。

Q. 社内にAIに詳しい人がいない。判断できるか。 A. 本稿で挙げた原則と要件は、いずれもAIの技術知識を必要としない。**「作ったものは自社のものか」「別の場所へ移せるか」「何に接続しているか」。**この3つは、システム発注の一般的な確認事項である。

Q. 業務知識の言語化に、どれくらい時間がかかるか。 A. 業務によるが、1つの業務について熟練者との対話を数回、文書化を含めて数週間というのが一つの目安になる。**ただし、この時間は「AIのための準備」ではなく、業務の標準化そのものに費やされる時間である。**AI導入を見送っても、成果は残る。

Q. 標準が統一されなかった場合、どうなるか。 A. 複数の形式が並存する状態が続く。その場合でも、原本をテキストで持っていれば、必要な形式へ変換する作業で対応できる。閉じ込められて出せない状態と、変換が必要な状態では、負担が大きく異なる。

AIエージェント導入の要件を整理したいとき

AIエージェントの導入は、ツールの選定より前に、**何を任せ、何を任せないかを決める作業が本体になる。**そして、その過程で作られる業務知識の記述こそが、後から効いてくる資産になる。

自社の業務のどこにAIエージェントを適用でき、どこは適用すべきでないかを整理したい場合は、AI導入アセスメントで受け付けている。実際の構築や、既存システムとの接続まで含めて相談したい場合はAIエージェント導入の相談、AI活用全般の設計から扱いたい場合はAI開発・活用の相談が該当する。

既にベンダーから提案や見積もりを受け取っていて、契約条件や成果物の範囲を第三者の視点で確認したい場合も、お問い合わせから相談できる。

なお、エージェント間の連携方式とロックイン回避の論点はA2A・MCPのベンダーロックインとRFP記載項目、MCPを含む要件の書き方はAIエージェントのRFPにMCP・A2A要件をどう書くかで別途扱っている。本稿は、設定資産の可搬性という一点に絞っている。

参照した情報

• Agent Plugins 公式サイト（version 1.0.0 specification）: https://agent-plugins.org/
• Agent Plugins 仕様リポジトリ: https://github.com/agentplugins/agent-plugins-spec
• Publickey「『Agent Plugins 1.0.0』発表、異なるAIエージェント間でもスキルやMCPサーバ設定が共通化へ。マイクロソフト、OpenAI、AWS、Googleらがサポート」（2026年8月10日）: https://www.publickey1.jp/blog/26/agent_plugins_100aimcpopenaiawsgoogle.html

パッケージの構造（plugin.json、skills/、mcp.json）、初期の技術運営委員会のCore Maintainers（Amazon、Cursor、Microsoft、OpenAI、Vercel）、提案が公開のGitHub Discussionsから始まり実装者の支持を必要とする点は、上記の公式サイトの記載に基づく。対応表明しているツールの一覧、将来の拡張として検討されている項目（ファイルシステムのアクセス制御、ユーザー承認フロー、暗号化署名）、およびAnthropicが初期のCore Maintainersに含まれていない点は、上記の報道および公式サイトの記載に基づく。

**仕様の公開日について、公式サイト上では明示的な日付の記載を確認できていない。**本稿では、上記報道の掲載日である2026年8月10日を公開に関する報道の日付として扱っている。**本仕様は公開されたばかりの段階であり、対応するツールや仕様の内容は今後変化し得る。**資産を守る3原則、発注要件の5項目、進め方の3段階、業務知識の言語化の5手順は、GXOが発注側の実務に合わせて整理したものであり、Agent Pluginsの仕様やその策定者の見解ではない。標準の今後の動向については、本稿では予測を行っていない。