メインコンテンツへスキップ

コードを置く場所から、AIエージェントの「能力」を流通させる場所へ――Origin、Agent Plugins、MCP、Skillの先に何が要るのか

    滋賀坂本余白書房別館

    ＜２０２６年７月２２日以前のコンテンツ一覧はこちら＞

    ＜似たような話題が続いている感じです。未来がどうなるかは半年後に答え合わせができるでしょう。自分が構想して作った言葉なので「Meaning Ledger」には強い思い入れがあるようです。＞


    本稿は2026年8月22日時点の情報に基づいています。

    この記事に出てくる Origin、Agent Plugins、MCP、Agent Skills は実在する製品・仕様です。
    一方、後半で使う 「Meaning Ledger」 は、現時点で同名の標準規格や製品があるという意味ではありません。
    ここでは、AIエージェントが「なぜそれをしたのか」「何が変わったのか」「本当にそうなったのか」を後から確かめられる記録の仕組みを考えるための、この記事上の呼び名として使います。

    ソフトウェア開発では、長いあいだ「何を管理するか」が比較的はっきりしていた。

    中心にあるのはソースコードだった。

    Gitで履歴を管理し、GitHubのような場所に保存する。変更があればPull Requestを作り、人間が差分を読み、テストし、承認して、本番環境へ送り出す。

    もちろん、実際の開発には仕様書も、課題管理も、CI/CDも、パッケージも必要だった。それでも中心にはコードがあり、周囲の仕組みは「コードを安全に変更し、配布し、実行する」ために作られていた。

    ところが、AIエージェントが本格的に開発へ入り始めると、この前提が変わってくる。

    AIエージェントはコードだけを書くわけではない。仕様を読み、過去の変更を調べ、社内手順を参照し、APIを呼び、テストを実行し、必要ならデプロイまで行う。

    そうなると、管理しなければならない対象も増える。

    どのコードが変わったかだけではなく、

    どのAIエージェントが、どんな能力を使い、何を根拠に判断し、何を実行し、その結果どうなったのか。

    そこまで追えないと、AIエージェントが増えたときに、開発の全体像が見えなくなる。

    2026年8月に相次いで登場したCursorの「Origin」と「Agent Plugins 1.0」は、この変化を別々の方向から示しているように見える。

    第1部　「コードを置く場所」が変わり始めた

    Originは、まず「大量のエージェントが使える置き場」を作ろうとしている

    2026年8月17日、Cursorはコードホスティングサービス「Origin」のEarly Betaを開始した。

    現時点で公表されている中心機能は、Repository、Pull Request、コード閲覧、GitHub同期などである。Cursor自身は、これらを「agent scale」を意識して設計したと説明している。

    参考：

    ここは読み込みすぎない方がよい。

    現在のOriginは、まず多数のAIエージェントが高速・並列に使うことを前提にしたコードの置き場として始まっている、と理解するのが自然だろう。

    ＜＜Meaning Ledgerも、証拠管理も、まだOriginがそうすると発表した話ではない。想像の範囲である。＞＞

    それでも面白いのは、Cursorが「従来のGitホスティングの上にAI機能を一つ足す」のではなく、コードホスティングそのものを作り始めたことだ。

    AIエージェントが一人の人間を補助するだけなら、既存のGitHubでも十分かもしれない。

    しかし、数十、数百のAIエージェントが同時にIssueを読み、Branchを作り、テストし、Pull Requestを生成するようになれば、「人間が一件ずつ差分を見る」ことを前提にした仕組みは苦しくなる。

    そこで、次の問いが出てくる。

    そもそもPull Requestとは、何を確認するためのものなのか。

    これまでは主に「コードの差分を見るもの」だった。

    しかしAIエージェントが変更を行うなら、将来は、

    • なぜ変更したのか

    • どの仕様に対応したのか

    • 何に影響したのか

    • どのテストを通ったのか

    • 誰、またはどのエージェントが実行したのか

    まで一緒に見なければならなくなるだろう。

    つまり、Pull Requestは単なる「差分の確認」から、変更全体の確認へ広がっていく可能性がある。

    これはOriginがすでに実現した機能ではない。

    Originの登場を見て、今後そういう問題が避けられなくなるのではないか、という予想である。

    第2部　AIエージェントの「能力」が持ち運べるようになった

    Agent Plugins 1.0は「能力を入れる箱」

    2026年8月6日、Agent Plugins 1.0が公開された。

    GitHub、AWS、Anysphere（Cursor）、Microsoft、OpenAI、Vercelなどが仕様策定に関わり、Googleも同日Core Maintainerとして参加した。GitHubは8月12日、VS Code、Copilot CLI、Copilot SDK、Copilot appでの一般提供を発表している。

    参考：

    重要なのは、これがGitHub Copilotだけの専用形式ではないことである。

    考え方はかなり単純だ。

    AIエージェントへ追加したい能力を、一つの持ち運べるパッケージにまとめる。

    ソフトウェアの世界では、昔から同じことが行われてきた。

    プログラムの部品をnpmやPython packageとして配る。アプリケーションをコンテナとして配る。

    Agent Pluginsは、その発想をAIエージェントの「能力」へ持ち込んだものと考えると分かりやすい。

    そしてAgent Plugins 1.0が、最初から何でも詰め込もうとしていない点も重要である。

    v1で共通部品として標準化された中心は、Agent SkillsとMCP serversの二つである。

    全部を共通化するのではなく、まず各社が共通に扱えそうな部分だけを決める。

    これは標準化としてかなり現実的なやり方だと思う。

    MCPは「外の世界との接続口」

    MCP（Model Context Protocol）は、AIエージェントが外部の道具やデータへ接続するための共通の接続方法である。

    参考：

    たとえばAIエージェントが、GitHubを読む、データベースを調べる、チケットを作る、クラウドを操作するといった仕事をするとき、外部サービスとの接続方法が全部ばらばらでは扱いにくい。

    そこでMCPが「接続口」の役割を持つ。

    人間にたとえるなら、MCPは手とコンセントに近い。

    何かに触れたり、外部の仕組みへつないだりするためのものだ。

    ただし、手があれば仕事ができるわけではない。

    本番環境を操作できることと、「どんな条件なら本番へ変更してよいか」を知っていることは別だからである。

    Skillは「仕事のやり方」

    そこでAgent Skillsが出てくる。

    Agent Skillは、AIエージェントへ専門知識や仕事の手順を与えるための形式で、中心になるのはSKILL.mdというファイルである。

    参考：

    たとえば「本番環境へデプロイする」という仕事なら、企業によって手順は違う。

    先にテストを行い、脆弱性を確認し、変更番号を確認し、責任者の承認を取り、最初は一部の利用者だけに反映し、問題がなければ全体へ広げる。

    こうした「仕事のやり方」は、単にAPIへ接続できるだけでは分からない。

    そこで大ざっぱに言えば、

    MCP＝どこにつながり、何を操作できるか

    Skill＝どういう手順で仕事をするか

    と考えればよい。

    もちろん、現実には完全に分かれるわけではない。MCPのツール説明にも「こう使ってください」という情報は入る。

    そして、この境界が少し曖昧だからこそ、後で問題になる。

    説明や設定を書き換えるだけで、AIエージェントの行動が変わり得るからである。

    第3部　能力を配れるようになると、「安全に配る仕組み」が必要になる

    一つのPluginを入れただけなのに、影響はその先まで伸びる

    ここから話が変わる。

    Agent Pluginを簡単に配れるようになれば、便利になる。

    同時に、ソフトウェアと同じようにサプライチェーンの問題も生まれる。

    たとえば、便利そうなPluginを一つ導入したとする。

    中のSkillには「作業前に社内APIで承認番号を取得する」と書かれている。その接続先はPluginの設定に書かれている。

    ある日、その接続先が別のサーバに差し替えられた。

    利用者には見た目の変化がない。

    AIエージェントも昨日と同じ手順で動いているつもりだ。

    しかし実際には、昨日とは違う相手へ情報を送っている。

    こう考えると、「Pluginを入れた」という一言では足りないことが分かる。

    少なくとも、

    1. 誰が作ったのか、どの版なのか

    2. どこへ接続し、何の権限を使うのか

    3. 何を実行し、結果として何が変わったのか

    を追える必要がある。

    ソフトウェアの世界では、部品の出所や依存関係、署名、脆弱性などを追跡する「Software Supply Chain」が重要になった。

    AIエージェントでも、同じように能力そのもののサプライチェーンが必要になるはずだ。

    ただしAgent Plugins 1.0は「安全の仕組み」そのものではない

    ここは重要である。

    Agent Plugins 1.0は、能力をまとめるパッケージ形式を定めた。

    しかし、インストールの仕組み、配布の方法、権限モデル、サンドボックスまで全部を定めた規格ではない。

    GoogleもAgent Pluginsについて、要するに「v1はパッケージ形式であり、それ以上のものではない」という趣旨を明確にしている。

    参考：

    つまり、

    持ち運べることと、安全であることは同じではない。

    むしろ、能力を持ち運べるようになったからこそ、

    「どこから入手したのか」

    「誰が許可したのか」

    「どこまで動けるのか」

    「何を持ち出せるのか」

    を管理する必要が出てくる。

    将来、Pluginの配布場所を誰が握るかはかなり重要になるだろう。

    npmやPyPIのように、配布の場所は単なる倉庫ではない。信頼性や安全性を判断する重要な入口になるからだ。

    では、「なぜそうしたのか」は誰が残すのか

    ここで、この記事独自の考え方としてMeaning Ledgerを置いてみる。

    難しく考えなくてよい。

    残したいのは、次の三つである。

    なぜやったのか。
    何が変わったのか。
    本当にそうなったのか。

    たとえばAIエージェントがデータベースを変更したなら、

    「変更しました」

    だけでは足りない。

    なぜ変更したのか。

    どの依頼や仕様に基づいたのか。

    変更によって何が変わったのか。

    テストは通ったのか。

    本番で本当に期待した状態になったのか。

    このつながりを後からたどれるようにしたものを、ここではMeaning Ledger――日本語なら**「意味の台帳」**くらいのものとして考えている。

    そして三つ目の「本当にそうなったのか」を支えるのが、テスト結果、ログ、署名、承認記録などの証拠である。

    つまり、AIエージェント自身の説明をそのまま信じるのではない。

    「AIが安全だと言った」ではなく、

    「このテスト結果とログと承認記録があるので、この時点では安全だと判断した」

    という形にする。

    これは昔から何度も試され、何度も続かなかった

    ここで一つ、冷静に見ておく必要がある。

    「なぜその設計にしたのかを記録しよう」という発想自体は新しくない。

    設計判断を残すADRや、システムの構成情報を管理するCMDBなど、似た試みは以前からある。

    しかし、現実には更新されなくなることが多かった。

    理由は単純で、書く人と、後から読んで得をする人が別だったからである。

    記録は大事だと分かっていても、忙しい現場では後回しになる。

    Meaning Ledgerも、人間が毎回手で書くなら同じ壁にぶつかるだろう。

    ただ、AIエージェントが仕事をする場合は少し事情が違う。

    AIエージェントが何を読み、どのツールを呼び、どのテストを実行したかは、作業の過程で記録として発生する。

    つまり今度は、記録を残すための追加作業を、人間だけに押しつけなくて済む可能性がある。

    ここが、過去の試みと少し違うところだ。

    記録は、必ずどこかで終わらせる

    ただし、記録を増やせば増やすほど安全になるわけではない。

    「その証拠は正しいのか」

    「では、その証拠が正しいことを示す証拠は」

    「さらに、その証拠は」

    と続ければ、いつまでも終わらない。

    これは避けなければならない。

    そこで最初から、どこで確定するかを決めておく。

    たとえば、

    • 承認されたバージョン

    • 署名されたテスト結果やログ

    • あらかじめ決めた責任者または規程による承認

    がそろったら、その変更はそこで確定する。

    そして、記録が一行増えただけでは、新しい審査を自動的に始めない。

    コード、権限、規程、本番状態など、実際の対象が変わったときだけ次の確認へ進む。

    こうしておけば、記録の記録を永遠に要求することはない。

    Repositoryは「コード倉庫」から「変更の記録場所」へ広がるかもしれない

    ここで、もう一度Originの話へ戻る。

    将来、AIエージェントが大量に変更を行うようになれば、人間が見る情報は増える。

    しかし、人間は何百件ものログや何千件もの証拠を読むことはできない。

    だから将来のPull RequestやRepositoryでは、全部を人間に見せるのではなく、

    通常は自動確認し、例外だけを人間へ上げる

    という形になる可能性が高い。

    人間が見るのは、

    「テストが落ちた」

    「普段と違う権限を使った」

    「新しい接続先が追加された」

    「規程に引っかかった」

    といった例外である。

    その背後には、必要なら後からたどれる詳しい記録が残る。

    そうなればRepositoryは、単なるコードの倉庫ではなく、

    なぜこの変更が起き、何を根拠に承認され、結果がどうなったかを確かめる場所

    へ少しずつ広がっていくかもしれない。

    Originがそこまで実現するかはまだ分からない。

    GitHubがそうなるかもしれないし、別のサービスが担うかもしれない。

    大事なのは製品名ではなく、AIエージェントが働く以上、どこかにその役割が必要になるということである。

    「コードのサプライチェーン」の次に「能力のサプライチェーン」が来る

    ここまでを、できるだけ単純に並べるとこうなる。

    人が「こうしたい」と決める
        ↓
Agent Pluginが能力を運ぶ
  ├─ Skill：仕事のやり方
  └─ MCP：外部との接続口
        ↓
AIエージェントが実際に動く
        ↓
コード・データ・設定・本番環境が変わる
        ↓
テスト・ログ・承認などの証拠が残る
        ↓
変更の理由・結果・証拠をまとめて記録する
        ↓
次の変更では、その記録が出発点になる

    この流れが重要なのは、AIエージェントの能力が「モデルそのもの」だけでは決まらなくなるからだ。

    同じAIモデルでも、

    どんなSkillを持っているか。

    どこへ接続できるか。

    どんな権限を持っているか。

    どんな規程の中で動くか。

    どんな証拠を要求されるか。

    によって、実際にできる仕事は大きく違う。

    これまで私たちは、AIを比べるとき「どのモデルが一番賢いか」に注目してきた。

    これからはそれだけでは足りない。

    どんな能力が、どこから、そのAIへ供給されているのか。

    こちらも同じくらい重要になる。

    この見立てが外れる可能性もある

    もちろん、能力のサプライチェーンがこのまま独立した大きな市場になるとは限らない。

    モデル自体がさらに賢くなり、現在Skillとして外から与えている手順の多くをモデルが自力で処理できるようになれば、外付けの能力パッケージは減る可能性もある。

    それでも、企業固有の規程、接続先、権限、承認、監査記録までモデル内部へ吸収できるわけではない。

    少なくとも、誰が何を許可し、何を実行し、何が起きたかを確かめる仕組みは残るだろう。

    おわりに

    Origin。

    Agent Plugins 1.0。

    MCP。

    Agent Skills。

    これらは一つの公式な技術スタックではない。

    別々の製品や仕様であり、それぞれ解いている問題も違う。

    それでも並べてみると、一つの方向が見えてくる。

    Originは、AIエージェントが働く「場所」を作ろうとしている。

    Agent Pluginsは、AIエージェントの「能力」を運べるようにする。

    MCPは、外部の世界との「接続口」になる。

    Skillは、「仕事のやり方」を持ち運べるようにする。

    すると次に必要になるのは、

    その能力を、誰が、どこから、どの権限で与えたのか。

    そして、

    そのAIエージェントが、なぜそう判断し、何を変え、本当に期待した結果になったのか。

    を後から確かめる仕組みである。

    ソフトウェアの世界では、コードや部品の出所を追うSoftware Supply Chainが重要になった。

    AIエージェントの時代には、その対象がさらに広がる。

    コードだけではなく、

    AIエージェントが使う「能力」そのものの出所と流れを追う。

    それが、将来の Agent Package Supply Chain、あるいはもっと素直に言えば、

    「AIエージェント能力のサプライチェーン」

    なのだと思う。

    2026年8月に起きていることを、単なるAIコーディングツールの新機能競争として見ると、この変化は小さく見える。

    しかし、「何を配り、何を管理する産業なのか」という視点で見ると、少し違って見える。

    ソフトウェア産業は、コードだけを配る世界から、

    実行できる能力まで配る世界へ、静かに境界を広げ始めている。

    主な一次資料

    あなたへのおすすめ