2026/08/07AI業務効率化
AI活用AIエージェント

Agent Plugins 1.0とは|業務スキルを持ち運ぶ

Agent Plugins 1.0とは|業務スキルを持ち運ぶ

「また新しい規格が出た」「結局どのAIツールに乗ればいいのか分からない」——AIの道具が増えるほど、この迷いは深くなっていきます。

結論から言うと、2026年8月6日に登場したAgent Plugins 1.0で本当に問われているのは「どのツールを選ぶか」ではありません。「自分の業務を、道具を選ばず持ち運べる部品にしてあるか」です。持ち運べる中身を持っていない人は、便利な標準ができても運べるものがありません。

株式会社Fyveは、日々の業務を1つずつ「部品(スキル)」に切り出して積み上げてきました。私はこの標準を、道具の乗り換え合戦ではなく「業務の部品化という資産づくり」の転換点として見ています。本記事では、何が起きたのか、なぜそれが資産の話なのか、そして非エンジニアが今日から何をすればいいのかを、順を追ってお伝えします。

Agent Plugins 1.0とは何か(2026年8月6日に起きたこと)

Agent Plugins 1.0は、2026年8月6日に公開された、AIエージェントの拡張機能を1つのフォルダにまとめるためのベンダー中立の標準規格です。特定の1社が囲い込む仕様ではなく、複数の大手が共同で策定した点がこれまでと決定的に違います。

策定に加わったのは OpenAI・Amazon(AWS)・Microsoft・Cursor(Anysphere)・Vercel の5社で、そこに Google が Core Maintainer として加わりました。運営委員会(Technical Steering Committee)は「1社が過半数の議席を持てない」という取り決めになっており、どこか1社の都合で仕様が捻じ曲がらないよう設計されています。提案の口火を切ったのは Vercel です。

これは、私がふだん手作業で積み上げてきた「業務の部品化」が、業界の共通ルールとして道具側に降りてきた瞬間だと受け止めています。

中身は「フォルダ1つ」——plugin.json + skills/ + mcp.json

難しそうな名前に反して、仕組みはとてもシンプルです。1つのディレクトリ(フォルダ)の中に、次の3つを入れるだけです。

要素

ファイル/フォルダ

役割(日常語で言うと)

マニフェスト

plugin.json

この部品の「名札」。名前や中身を宣言する箱の蓋

スキル

skills/(フォルダ)

よく使う業務手順を1個ずつまとめた「部品」の置き場

接続設定

mcp.json(任意)

AIをデータや外部ツールに繋ぐ「配管」の指定

ここで出てくる言葉を、私なりに日常語へ翻訳しておきます。スキルとは「よく使う業務手順を1個の部品にまとめたもの」、MCPとは「AIをデータや外部ツールに繋ぐ配管」、プラグイン標準とは「その部品を、どのAIアプリでも同じ形式で読み込める共通の箱」です。MCPそのものの仕組みは、別の記事で詳しく解説しています。

MCPとは?仕組みと実務での活用法をわかりやすく解説
Claude CodeMCPとは?仕組みと実務での活用法をわかりやすく解説

Skillsが「何をするか(手順)」を担い、MCPが「何に繋ぐか(データ・ツール)」を担う。この2つを1つの箱(plugin.json)に包む——それがAgent Plugins 1.0の全体像です。

スキルとMCPをplugin.jsonの箱に包み、ChatGPT・Cursor・Copilot・VS Codeなど器をまたいで持ち運ぶ図

図のとおり、業務手順(skills)と接続(mcp.json)を1つの箱にまとめておけば、対応アプリをまたいで同じ部品を読み込ませられます。ただし保証されるのは「包み方・見つけ方」までで、実行時の動きまで完全に揃うわけではない点は後述します。

どこで使えるのか——器をまたぐ「ローンチクライアント」

この標準に最初から対応した「器(対応アプリ)」は、発表時点で次のとおりです。

  • ChatGPT / Codex(OpenAI)
  • GitHub Copilot / VS Code(Microsoft)
  • Cursor(Anysphere)
  • Kiro(AWS)

つまり、同じ1つのプラグインを ChatGPT でも Cursor でも Copilot でも読み込ませられる、というのが狙いです。今まではツールごとに設定を作り直していた「業務の手順」を、1回作れば器を選ばず使い回せる方向に進みます。

ここが誤解されやすい——標準が保証するのは「持ち運び」だけ

正確に押さえておきたい点があります。Agent Plugins 1.0が定めているのは、「包み方(パッケージング)」と「見つけ方(発見性)」だけです。裏を返すと、次のものは標準の範囲外です。

  • 実行時の権限管理(どこまで勝手にやらせるか)は各ツール側の責任
  • マーケットプレイス(配布・課金の仕組み)は含まない
  • 実行環境(どのマシンで動かすか)も対象外

ですから「どの器でも寸分たがわず同じ挙動になる」わけではありません。あくまで「同じ形式で読み込めて、持ち運べる」ところまでです。この線引きを曖昧にすると期待値がずれるので、最初に明言しておきます。それでも、手順という中身を器から切り離して持ち運べるようになった意味は、後述するとおり非常に大きいのです。

多くの人が「また新しい規格か」で流す——その反応こそが損をする

この手のニュースが出るたびに、多くの人は「また新しい規格ができたのか」「様子見でいいだろう」と受け流します。気持ちは分かります。AIの世界は新機能が毎週のように出て、追いかけるだけで疲れてしまうからです。

ですが、今回に限っては、その受け流しが静かに損を生みます。理由はシンプルで、この標準が価値を発揮するのは「持ち運べる中身」を持っている人だけだからです。

持ち運べる箱の規格ができても、箱に入れる中身——つまり部品化された自分の業務手順——が無ければ、恩恵はゼロです。逆に、日ごろから業務を部品にしてきた人にとっては、その部品が一夜にして「特定ツールに縛られない資産」に変わります。同じニュースが、人によって「他人事」にも「資産の増価」にもなる。この非対称が、今回の本質です。

だから見るべきは「どのツールが勝つか」ではありません。「自分の業務は、部品として切り出してあるか」です。標準の登場は、その問いを突きつけてきたのだと私は捉えています。

なぜ今このタイミングで標準化が起きたのか

そもそも、なぜ競合するはずの大手5社が同じテーブルに着いたのでしょうか。背景には、AI拡張機能の「フラグメント化(バラバラ問題)」があります。

ここ1〜2年で、各社は独自のスキル形式やプラグイン形式を次々に打ち出しました。便利ではあるのですが、ツールごとに書き方が違うため、同じ業務手順を使いたくてもツールの数だけ作り直す必要がありました。使う側は消耗し、作る側(開発者や事業者)は同じものを何度も移植する羽目になる。この非効率が限界に達していたのです。

ツールを提供する各社にとっても、フラグメント化は痛手でした。せっかく良い拡張機能があっても、自社の形式に閉じている限り、他の器のユーザーには届きません。「持ち運べない」ことが、エコシステム全体の成長を止めていたわけです。だから、包み方だけでも共通化しよう——という合意が成立しました。

興味深いのは、今回の標準が「包み方と見つけ方」だけに範囲を絞ったことです。権限管理やマーケットプレイスといった、各社が競争したい領域には手を出さない。競争する部分と協調する部分を切り分けたからこそ、利害の異なる5社が合意できたのだと私は見ています。全部を統一しようとしていたら、まとまらなかったでしょう。この「最小限で握る」設計は、私が業務を部品化するときの「複雑さを嫌い、最小構成から始める」やり方と、発想が驚くほど似ています。

なぜ「業務の部品化」が資産になるのか

ここで、私がこの数年ずっと軸にしてきた考え方を1つだけ共有させてください。事業とは、ワークフロー(作業の流れ)の組み合わせでできているという見方です。

どんな業種の仕事も、分解していくと「決まった手順の連なり」に還元できます。問い合わせに返信する、見積もりを作る、日報をまとめる、記事の下書きを作る——一見バラバラに見える業務も、工程に割ってみれば、それぞれが独立した小さな手順の集合です。

工程に分解できるということは、部品にできるということです。そして部品にできるということは、束ね直して別の場所で再利用できるということです。ここまで来ると、業務は「自分にしかできない属人的な作業」から「持ち運んで組み替えられる資産」へと性質が変わります。

属人化された手順は、その人が動けなくなった瞬間に止まります。私自身、自分が止まると事業が止まる——属人性が事業の上限になる——という壁を強く意識してきました。だからこそ、頭の中にしかない手順を、外に出して部品にする作業に価値を置いてきたのです。Agent Plugins 1.0は、その部品を「どのAIの器にも移せる」段階まで引き上げてくれる規格だと言えます。

この「業務を標準化して仕組みに落とす」考え方そのものについては、別の記事でも掘り下げています。

AI業務標準化の仕組み|ルールファイルとナレッジベースの作り方
AI業務効率化AI業務標準化の仕組み|ルールファイルとナレッジベースの作り方

私がやってきた「手順を1個ずつ部品に切り出す」という運用

抽象論だけでは伝わりにくいので、私自身がどう運用してきたかを、設計の考え方として共有します(具体的な業務内容やツール構成の細部は伏せますが、やり方の骨格は誰でも真似できます)。

1. まず「繰り返している手順」を1つだけ言葉にする

私は新しい業務フローを部品にするとき、いきなり全体を自動化しようとはしません。「毎週何度も繰り返している手順」を1つだけ選び、その手順を言葉で書き出すところから始めます。頭の中で流れている暗黙の判断を、他人(やAI)が読んで再現できる文章にする。これが部品化の第一歩です。

2. その手順が使う「接続」を一緒に束ねる

手順は単独では動きません。たいてい何かのデータや外部ツールに触ります。だから手順を部品にするときは、その手順が必要とする接続(データの場所、使う外部サービス)も一緒に束ねます。これがまさに、Agent Plugins 1.0で言う「skills(手順)とmcp.json(配管)を1つの箱に入れる」という発想と同じです。私が手作業でやっていた束ね方が、標準として言語化された、と言ってもいい。

3. 1個ずつ試して、型が固まってから広げる

私は複雑さを嫌います。最初から10個の業務を部品化しようとすると、たいてい破綻します。1個作って、実際に回して、型が固まってから次へ広げる。この「1個ずつ」の積み重ねが、結果として大きなライブラリになりました。派手さはありませんが、これがいちばん崩れない進め方です。

この積み上げ方があったからこそ、Agent Plugins 1.0のような標準が出たときに「では、この部品をそのまま別の器に載せてみよう」と即座に動けます。標準は追い風ですが、追い風を受ける帆——つまり部品——を先に張っておく必要があるのです。

手順を「部品(スキル)」として切り出す具体的な作り方は、こちらの記事で全手順を解説しています。

Claude Code Skillsの作り方|自分の業務をスキル化する実践手順
Claude CodeClaude Code Skillsの作り方|自分の業務をスキル化する実践手順

部品化でつまずきやすい3つのパターン

「業務を部品にする」と言うと簡単そうですが、実際にやってみると、多くの人が同じ場所でつまずきます。私自身が踏んだ落とし穴を3つ共有します。ここを避けるだけで、部品化の成功率は大きく変わります。

1. 最初から「全部」を部品化しようとする

いちばん多い失敗です。せっかくやるなら全業務を仕組み化したい——その気持ちが、かえって挫折を招きます。手順が10個絡み合ったまま部品にしようとすると、どこが悪いのか切り分けられず、直しようがなくなるからです。部品は「1個ずつ」切り出す。これが鉄則です。1個を回しきって型が固まってから、次へ進みます。

2. 手順と接続を切り離してしまう

手順(何をするか)だけを書いて、接続(どのデータ・ツールを使うか)を後回しにすると、部品はうまく動きません。「このフォルダを見る」「この外部サービスに繋ぐ」という接続情報は、手順とセットで初めて意味を持ちます。Agent Plugins 1.0がわざわざ skills と mcp.json を1つの箱に同梱しているのも、この2つが不可分だからです。手順を書いたら、その手順が触るものを必ず一緒に書き添える。これを徹底します。

3. 「頭の中の判断」を書き出さずに済ませる

熟練者ほど、手順の中に「言葉にしていない判断」を大量に持っています。「この場合はこう分岐する」「例外はこう扱う」——こうした暗黙知を書き出さないまま部品にすると、いざ別の器で動かしたときに再現できません。面倒でも、分岐や例外を含めて言葉にする。ここを省くと、部品は「自分専用のメモ」で止まり、持ち運べる資産になりません。

この3つは、いずれも「複雑さを一度に扱おうとする」ことから生まれます。小さく・セットで・言葉にして——この3原則を守れば、部品は着実に積み上がっていきます。

相互運用が意味すること——囲い込みから乗り換え自由へ

Agent Plugins 1.0がもたらす一番大きな変化は、「囲い込み」から「相互運用」への転換です。

これまでは、あるツールに合わせて業務の設定を作り込むほど、そのツールから離れられなくなりました。設定資産がそのツールに縛られていたからです。乗り換えようとすると、積み上げたものをゼロから作り直す必要がある。これが「囲い込み(ロックイン)」の正体です。

共通の標準ができると、この縛りが緩みます。部品が特定ツールに紐づかず、器をまたいで持ち運べるようになるからです。道具の乗り換えが自由になる——これは、道具を提供する側にとっては競争が激しくなることを意味し、道具を使う側にとっては主導権が自分の手に戻ることを意味します。

囲い込みから相互運用への転換:ツールごとに手順を作り直す時代から、1個の部品を器をまたいで持ち運ぶ時代への対比図

この対比のとおり、変わるのは「作り直しの手間」だけではありません。乗り換えコストが下がることで、値上げや仕様変更に振り回されず、自分に合った器を選び続けられるようになります。得をするのは、業務を工程に分解して部品に束ね直せる人です。

ただし、綱引きはまだ終わっていません。ここは正直に判定しておきます。今回の標準の初期メンバー(Core Maintainer)にも、ローンチクライアントにも、MCPやAgent Skillsの発祥であるAnthropicの名前がありません。Anthropicは独自のプラグインディレクトリを別に持っており、その仕組みが将来この標準に合流するのかは未確定です。「相互運用」を掲げる標準の外側に、発祥企業の別エコシステムが並走している——つまり、完全な相互運用にはまだ距離があります。

それでも方向は明らかです。業界全体が「囲い込み」から「持ち運べる部品」へと舵を切り始めた。得をするのは、その流れに乗れる中身を持っている人です。

中小企業・ひとり事業にとって、この標準はどう効くのか

大手5社の合意と聞くと、大企業だけの話に思えるかもしれません。ですが、私はむしろ小さな事業ほど恩恵が大きいと考えています。

中小企業やひとり事業では、専任のAI担当者を置けません。だからこそ、業務の手順が特定の人の頭の中に閉じ込められがちで、その人が動けなくなれば仕事が止まります。属人性が、そのまま事業の上限になる——これは規模が小さいほど深刻な問題です。

部品化は、この上限を押し上げる直接の手段です。手順を外に出して部品にしておけば、担当が変わっても、使うツールが変わっても、業務は止まりません。そしてAgent Plugins 1.0のような標準が広がれば、その部品は「今契約しているツール」に縛られず、より安く・より使いやすい器へ自由に載せ替えられます。道具の乗り換えコストが下がることは、値上げや仕様変更に振り回されやすい小さな事業にとって、そのまま経営の自由度になります。

大企業は独自形式でも人海戦術で移植できますが、小さな事業にその余力はありません。だからこそ「1回作れば持ち運べる」という相互運用の価値は、資源の限られた事業ほど大きく効きます。標準化は、体力のある側だけでなく、体力の無い側を助ける方向に働くのです。

非エンジニアは、今日から何をすればいいのか

「エンジニアの話でしょう」と感じた方こそ、ここを読んでください。Agent Plugins 1.0の技術仕様を今すぐ触る必要はありません。やるべきことは、もっと素朴です。

ステップ1:毎週3回以上やっている手順を1つ書き出す

まず、自分が毎週3回以上繰り返している業務手順を1つだけ選びます。メール返信のテンプレ判断、定例資料の作成、問い合わせの一次仕分け——なんでも構いません。それを「他人が読んで再現できる文章」にします。この時点では、まだAIもツールも要りません。頭の中の手順を外に出すこと自体が、部品化の第一歩です。

ステップ2:その手順が触る「データ・ツール」を書き添える

次に、その手順が何を見て、何を使っているかを書き添えます。「このスプレッドシートを見る」「このフォルダに保存する」といった接続情報です。手順と接続がセットになって初めて、部品として動く形になります。

ステップ3:手持ちのAIツールで1回だけ回してみる

最後に、いま使っているAIツール(ChatGPTでもCursorでもClaudeでも)で、その手順を1回だけ実行させてみます。うまくいかなければ、手順の書き方を直す。この「書いて・回して・直す」を1周するだけで、部品の精度は一気に上がります。そして一度きちんと部品にしておけば、標準対応が進んだとき、その部品はそのまま別の器へ移せる資産になります。

ポイントは、最初から完璧な仕組みを目指さないことです。1つの手順を部品にして、型が固まったら次へ。この地道な積み重ねが、相互運用時代の一番強い準備になります。

よくある疑問

Q. 結局、どのAIツールを選べばいいですか?

この標準が広がるほど、「どのツールを選ぶか」の重みは下がります。部品が器をまたいで持ち運べるなら、ツール選びは「今いちばん使いやすいもの」で構いません。大事なのはツールの銘柄ではなく、持ち運べる部品を自分が持っているかどうかです。まずは手に馴染んだ1つで部品化を始めてください。

Q. 今あるツール設定は無駄になりますか?

いいえ。むしろ、これまで作り込んできた「手順」や「よく使うやり取り」ほど、部品化の元手になります。無駄になるのは「頭の中にしか無い暗黙の手順」だけです。外に出して文章にしてある手順は、標準が広がるほど価値が上がります。

Q. 標準に対応した瞬間、全部が自動で連携しますか?

いいえ。前述のとおり、この標準が保証するのは「包み方」と「見つけ方」までです。実行時の権限や動作環境はツール側の領分なので、「置いたら全部つながって勝手に動く」わけではありません。過度な期待は禁物ですが、「手順を器から切り離して持ち運べる」という一点だけでも、業務設計の自由度は確実に上がります。

まとめ:手順を部品に分解して束ねられる人が、相互運用時代に強い

Agent Plugins 1.0(2026年8月6日)は、スキルとMCPを1つの箱に包み、どのAIの器にも持ち運べるようにする——そういう標準です。表面的には「主要各社が共通規格で手を組んだ」というニュースですが、本質は「自分の業務ノウハウが、道具に縛られない部品=資産になった」ことにあります。

得をするのは、自分の仕事を工程に分解し、部品として束ね直せる人だけです。部品化していない人は、便利な標準ができても持ち運べるものがありません。囲い込みから相互運用へ——ただしAnthropicの不在が示すとおり、綱引きはまだ続いています。

だからこそ、今やるべきは技術仕様を追うことではなく、「毎週3回以上やる手順を1つだけ部品に切り出す」という素朴な一歩です。私自身、1個ずつ切り出して束ねる積み重ねで、業務を持ち運べる資産に変えてきました。相互運用の時代に強いのは、道具を追いかける人ではなく、手順を部品に分解して束ねられる人です。株式会社Fyveは、その部品化の設計を、これからも実践と発信の両面で積み上げていきます。

AIを使う会社と、使わない会社。
その差は、開き始めています

ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。

無料プレゼント:様々な業種にAIを導入して分かった、成功の型と失敗パターン ― 無料でダウンロードする
← 記事一覧に戻る