Agent Plugins 1.0は、AIエージェントの機能（スキル、MCPサーバー、コマンド、ルール）を一つのインストール可能なプラグインにまとめる、オープンでベンダー中立な標準です。一度作れば、ツールごとに作り直すことなくさまざまなツールで動かせます。2026年8月、GitHubはVS Code、Copilot CLI、Copilotアプリ、そしてそのSDKで、すべてのCopilotプランを対象にこの標準を全面的にサポートすると発表しました。経営者にとっての直接的な意味は、チーム向けにAIツールをカスタマイズするために費やす時間と費用が、もはや単一のプラットフォームに人質に取られなくなるということです。
実際にはどんな問題を解決するのか？
この二年間で、AIツールは単なるチャット画面から、ファイルを読み、社内システムを呼び出し、実際の作業手順を実行するエージェントへと進化しました。こうしたエージェントを自社向けにカスタマイズするには、三つのものを与える必要があります。自社の業務の進め方を説明する文書化された指示、MCPサーバーを通じた社内システムへの接続、そして権限を超えた行動を防ぐルールです。
問題は、ツールごとにこれらすべてを独自の形式で求められていたことでした。チームがあるツール向けにカスタマイズを書いても、一年後に会社がより速い、あるいはより安いツールへの移行を決めると、その成果物はすべて移植できず、書き直しが必要だと判明します。これは単なる技術的な面倒ではありません。ベンダーを変えるたびに繰り返される現実のコストであり、多くの企業が無駄を恐れて本格的なカスタマイズを先送りしている理由でもあります。
プラグインには実際に何が含まれるのか？
この標準に沿ったパッケージは、形がシンプルで明確に定義されています。構成要素は次のとおりです。
- plugin.jsonマニフェスト：プラグイン名とバージョン番号を記載したもので、更新と追跡を可能にするのはこのファイルです。
- スキルフォルダー：自社で繰り返し発生する業務を、自社が望むやり方でどう進めるかをエージェントに伝える、文書化された指示を収めます。
- mcp.jsonファイル：エージェントを実際のシステム、つまり在庫、顧客データベース、請求に接続するMCPサーバーを定義します。
- ツール固有の拡張：独立した名前空間に置かれるため、特定のベンダーが独自機能を追加しても、共通部分は移植可能なまま保たれます。
共通部分とベンダー固有の部分を切り分けたことが、この設計で最も賢い点です。どのプロバイダーも独自機能で差別化することを妨げられず、あとで考えを変えたとしてもすべてを失う必要はありません。
なぜ開発者だけでなく経営者が気にかけるべきなのか？
本当の違いはガバナンスにあります。この標準はオープンライセンスのもとで公開の場で開発されており、Amazon、Microsoft、OpenAI、Cursor、Vercelの代表者からなる技術運営委員会が監督しています。競合する企業同士が一つの形式で合意するということは、その形式が一回の製品サイクルを超えて生き残るというシグナルであり、どこか一社が顧客を囲い込もうとする試みではないことを示しています。
これが重要なのは、今日AIを導入する際の最大のリスクが技術面ではなく契約面にあるからです。今日選んだプロバイダーが値上げをしたり、依存しているサービスを終了したり、品質が変わったりするかもしれません。オープン標準はこうしたリスクをなくすものではありませんが、撤退コストを下げてくれます。そして低い撤退コストこそが、手元にある最も強力な交渉カードなのです。
サウジアラビアの企業にとって何を意味するのか？
2026年が王国で「人工知能の年」に指定されたことを受け、多くの企業が何年ものデモを経て、本格的な試行の段階に入りました。私たちが繰り返し目にするのは、ある企業がチーム向けにサブスクリプションを購入したものの、何もカスタマイズせず、世界のことは何でも知っているのに自社のシステムについては何も知らない汎用アシスタントで終わってしまうというパターンです。本当の価値はサブスクリプションではなく、カスタマイズから生まれます。
移植可能な標準が整ったことで、カスタマイズの判断ははるかにリスクの低いものになりました。企業は承認フローを説明する社内プラグインを作成し、エージェントを請求システムや受注管理システムに接続し、チーム全体に配布できます。来年別のツールに移ったとしても、その投資が有効なまま残ると確信できるのです。
ただし、一つ重要な点に注意してください。パッケージが移植可能だからといって、データへのアクセスが許されるようになるわけではありません。エージェントを社内システムに接続するプラグインは、引き続き個人データ保護法（PDPL）の対象となります。エージェントが何を読み取れて何を読み取れないのかを正確に定め、それを文書化しなければなりません。
今週から始められる実践ステップ
- 現在のカスタマイズを棚卸しする。チームが指示、接続、ルールとして実際に何を作ってきたかを書き出し、それぞれが現在どこにあるかを把握します。
- 繰り返し発生する一つの業務から始める。すべてを一度に移行しようとせず、目に見えて時間を取られている日々の業務を一つ選び、一つのプラグインとしてパッケージ化します。
- 配布の前に権限を設定する。BusinessプランとEnterpriseプランには、どのプラグインを許可するか、どの承認済みソースからのものを許可するかを管理する一元設定が含まれています。利用が広がってからではなく、広がる前に設定してください。
- 移植できるものとできないものを文書化する。共通部分はツール間で移せますが、ツール固有の拡張は移せない場合があります。移植性を前提に約束をする前に、その限界を把握しておきましょう。
要するに、業界は競合する形式が乱立する状態から共通の形式へと移りつつあり、今こそAIのカスタマイズへの投資が賭けではなく計算された判断になる段階だということです。Origamiでは、こうしたプラグインと、お客様の実際のシステムとの接続を構築しており、所有権と柔軟性がベンダーではなくお客様の側に残るよう、最初から設計しています。
出典
- Agent Plugins 1.0のサポートに関するGitHubの公式発表：github.blog
- 標準の公式サイトと技術運営委員会：agent-plugins.org
- 1.0.0仕様の本文：agent-plugins-spec
よくある質問
Agent Plugins 1.0とは、ひと言で言うと何ですか？
AIエージェントのスキル、MCPサーバー、ルールを一つのインストール可能なプラグインにまとめる、オープンでベンダー中立な標準です。一度作れば、ツールごとに作り直すことなく複数のツールで動作します。
すでに構築したものを変更する必要はありますか？
いいえ。GitHubは、新しいバージョンを対象としていない既存のプラグインも引き続きサポートされ、移行の強制はないと述べています。そのため、次に作るプラグインから段階的に移行できます。
これによって単一ベンダーへの依存はどう減るのですか？
プラグインの共通部分は異なるツール間で動作するため、あるプロバイダーから別のプロバイダーへ移る際のコストが下がります。すべてのリスクがなくなるわけではありませんが、乗り換えの判断が全面的な作り直しから限定的な移行へと変わります。
この標準は顧客データの保護までカバーしていますか？
いいえ。この標準が統一するのはパッケージ形式だけで、いかなる権限も付与しません。エージェントが自社システムから何を読み取れるかを定め、個人データ保護法（PDPL）を遵守することは引き続き自社の責任であり、権限設定と一元管理の設定によって徹底する必要があります。
