今週リリースされたもの
2026年8月6日、Agent Plugins 1.0.0がリリースされ、Google Developers Blogで発表されました。これは、Agent SkillsとMCPサーバーを、それぞれ固定された場所を持つポータブルなディレクトリ構造にバンドルするパッケージフォーマットです。支援企業のリストは非常に興味深いものです。Amazon、Cursor、Microsoft、OpenAI、Vercelが名を連ね、Googleがコアメンテナーとして参画しています。サポートはすでにAgents CLI（Antigravity、Gemini CLI、Claude Code、Cursorをカバー）やData Agent Kitに及んでおり、互換性のあるクライアントのリストはagent-plugins.orgで管理されています。
解決される課題は、発表の中で率直に述べられています。「プラグインの作成者は、すべてのクライアントにリーチすることと、各クライアントの強みを活かすことのどちらかを選択せざるを得ない状況に置かれるべきではない。」 目標は、プラグインのコンポーネントが「互換性のある任意のクライアント間でポータブルに利用可能になること」です。
そして、記憶について考えているすべての人にとって重要な一文が登場します。仕様書は自ら境界線を引いています。Agent Plugins v1は「パッケージフォーマットであり、それ以上のものではない。インストールメカニズム、配信プロトコル、権限モデル、サンドボックス要件、信頼性や出所の検証、ユーザーエクスペリエンスは一切定義しない」としています。
これは批判ではありません。スコープを絞り込んだからこそ、仕様がリリースできたのです。しかし、スコープ外のリストを読んで、そこに載ってすらいないものに注目してください。記憶や永続的な状態（ステート）は除外されているのではなく、最初から議論の対象にすらなっていません。このフォーマットは「能力（ケイパビリティ）レイヤー」を標準化するものであり、能力レイヤーは蓄積された「コンテキスト」とは別物です。
研究も同じ方向を示しています。SkillOpt: Executive Strategy for Self-Evolving Agent Skills（arXiv 2605.23904、2026年5月22日提出、8月5日に業界ニュースで取り上げられた）というプレプリントでは、スキル文書を、凍結されたエージェントのためのトレーニング可能な外部状態として扱っています。オプティマイザーモデルが、スコア化されたロールアウトを単一のスキルファイルに対する制限付きの追加/削除/置換編集に変換し、その編集はホールドアウト検証スコアを厳密に改善する場合にのみ受け入れられます。6つのベンチマーク、7つのターゲットモデル、3つの実行ハーネス（直接チャット、Codex、Claude Code）にわたり、著者らは評価された52のすべての（モデル、ベンチマーク、ハーネス）セルにおいて、彼らの手法が最高または同等であったと報告しています。これにより、GPT-5.5のスキルなしの平均精度が、直接チャットで+23.5ポイント、Codexループ内で+24.8ポイント、Claude Code内で+19.1ポイント向上しました。
注目すべきは、この「転移」の結果です。最適化されたスキルアーティファクトは、さらなる最適化を行うことなく、モデルの規模を超えて、CodexとClaude Codeの実行環境間で、さらには類似の数学ベンチマークへと移動させても、その価値を維持します。あるハーネスでトレーニングされた手順は、別のハーネスでも機能し続けるのです。
これが定説となる前に、2つの注意点があります。これは査読前のプレプリントです。また、論文は2026年5月のものであり、8月という日付は報道が広まった時期であって、研究が発表された時期ではありません。今週本当に新しいのはパッケージングの標準化であり、SkillOptは、標準化されようとしているものが実際に転移可能であるという証拠です。
なぜスキルは記憶ではないのか
一方は一般的であり、他方はあなたのものである
スキルは再現可能な手順をエンコードします。だからこそ転移するのです。「スプレッドシートの破損した参照を監査する方法」において、どのスプレッドシートか、どの会社か、どの四半期かには一切依存しません。具体的な情報を取り除けば、公開可能なものが出来上がります。パッケージフォーマットが想定しているのは、まさにそのようなものです。
記憶とは具体的な情報です。あなたの勘定科目表、強制している命名規則、失敗時に200を返すベンダーのAPI、3月に下した決定とその背後にある理由などです。これらが他の誰かにとって役立つ形は存在しませんし、一度作成してインストールできるような形もありません。それはあなたの業務からキャプチャされる必要があり、成長し続けるものです。
一方は作成されるものであり、他方は蓄積されるものである
スキルは意図的に作成され、固定されます。レビューし、バージョン管理し、1.1をリリースすることができます。それは作成者が存在するアーティファクトです。
記憶には「作成する瞬間」がありません。業務の副産物として生成されます。ここでの修正、あそこでの決定、午後6時に発見された制約などです。つまり、失敗のモードがまったく異なります。スキルは「間違っていること」で失敗しますが、記憶は「そもそも記録されないこと」で失敗します。パッケージフォーマットは後者の問題を解決できません。なぜなら、パッケージ化するものがまだ存在しないからです。
スキルはエージェントに「方法」を教え、記憶だけが「ここでのルール」を教える
ここで混同が生じると、大きなコストがかかります。十分に最適化されたコードレビューのスキルをエージェントにインストールすれば、エージェントはコードをうまくレビューするでしょう——ただし、一般論としてです。エージェントは欠落しているNullチェックを指摘しますが、上流の奇妙な仕様のために、あなたのチームがアダプターレイヤーでそのパターンを意図的に許容していることを見落とします。手順は優れていましたが、コンテキストが欠けていたのです。
開発チームはこの結果を「スキルの調整が必要だ」と解釈し、スキルを繰り返し修正します。しかし、スキル自体に問題はありませんでした。欠けているのは、「ここでは、このように行います。理由はこうです」と伝えるレイヤーです。これが、ドキュメントに対する検索（RAG）が記憶と同じではない理由でもあります。アダプターレイヤーに言及しているドキュメントを見つけることと、エージェントが既定の決定事項を把握していることは同じではありません。
ポータビリティはギャップを縮めるのではなく、より顕著にする
ここには、少し直感に反する結果があります。Claude Code、Cursor、Codexなどの間でスキルを移動させるのが簡単になればなるほど、実際に移動する頻度が高くなります。そして、移動するたびに知識側はゼロにリセットされ、能力側だけがそのまま引き継がれます。この標準規格は、スタックの半分から摩擦を取り除きます。しかし、触れていないもう半分のレイヤーこそ、あなたが蓄積するのに6ヶ月かかった部分なのです。
人々が試みること
プロジェクトのコンテキストをスキルの中に含める。 明白なアプローチであり、破綻するまでは機能します。しかし、これを行うと、スキルを公開できなくなり、プロジェクト間でバージョン管理できなくなり、決定が変更された瞬間に古くなってしまいます。また、共有することもできなくなりますが、それではパッケージフォーマットの目的が失われてしまいます。
指示ファイルにすべてを詰め込む。 AGENTS.md、CLAUDE.md、.cursor/rulesなどは、常時適用されるルールの格納場所として本当に適しています。Cursorの公式ドキュメントがルールを500行未満に抑えることを推奨しているのには、もっともな理由があります。指示ファイルはすべてのタスクで読み込まれるため、リクエストごとのコスト（税金）になります。これらはルールのためのものであり、蓄積された記録のためのものではありません。
クライアントごとに1つの巨大なプラグインを作成する。 一部のチームは、コンテキストを組み込んだツールごとのバンドルを維持することでポータビリティを解決しようとします。これは、同じ知識のコピーが3つ存在し、それぞれが乖離していくことを意味し、誰も移動できない1つのコピーがある状態よりも悪質です。
各セッションの開始時に再説明する。 一般的な方法ですが、徐々に劣化していきます。木曜日に手入力する説明は、月曜日のものよりも短くなります。なぜなら、記憶を頼りに要約しており、例外事項などの細かい部分は面倒で省かれがちだからです。
各ツールの組み込み記憶機能に任せる。 合理的であり、機能が存在する場合は有効にする価値があります。落とし穴は、これらのストレージがツールごと、通常はマシンごとに独立しており、エクスポートできないことです。そのため、プラグイン仕様が解決しようとしたのとまったく同じ問題が、標準規格がまだ存在しない1つ下のレイヤーで再発することになります。
解決策：スキルを配信し、コンテキストを維持する
意図的にレイヤーを分割し、それぞれにふさわしいストレージを割り当てます。
スキルはプラグインに格納します。クリーンかつ一般的に作成し、コードベースやクライアントを特定できるような情報を一切含めないようにし、バージョン管理を行い、新しいフォーマットを使って今期使用しているあらゆるハーネスに移植できるようにします。それがこのフォーマットの目的であり、現在実際に機能しています。
コンテキストは、単一のツールから独立し、すべてのツールが読み取れる記憶レイヤーに格納します。巨大な指示ファイルにするのではなく、業務で生成されたドキュメント、決定事項、制約事項を保持し、すべてのリクエストで読み込むのではなく、関連性があるときだけ検索されるストアにします。MemoryLakeは、この分割の片側のために構築されています。エージェントがMCPまたはAPIを介して読み取る単一のストアであるため、ハーネスを切り替える際も、組織の知識を再構築するのではなく、設定項目を1つ変更するだけで済みます。
率直な境界線が1つあります。記憶レイヤーは、エージェントに読み取った内容を強制的に従わせるものではありません。アテンションや指示への追従はモデルの振る舞いであり、いかなるストレージレイヤーもコンプライアンスを保証することはできません。記憶レイヤーが変えるのは、関連するコンテキストが必要な瞬間に、利用可能かつ簡潔な状態で提供されるという点です。コンテキストが欠落していたり、ファイルが肥大化してモデルがその中間部分を無視するようになったりするのを防ぎます。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。環境変数やシークレットマネージャーに保管してください。Agent Plugins v1は権限モデルを明示的に定義していないため、パッケージバンドルに埋め込んだ資格情報を保護する仕組みは標準規格には存在しないことに注意してください。
ステップ 2: 最初の記憶をアップロードする
具体的な情報を持つドキュメント、画像、ファイルを投入します。アーキテクチャの決定事項、理由が記載された規約ドキュメント、クライアントの概要、ポストモーテム（事後分析）などです。可能な限り、要約ではなくソース自体をアップロードしてください。これらはまさに、共有可能なプラグインに含めることができない素材であり、だからこそ独自の格納場所が必要なのです。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のAIエージェントに、MCPまたはAPIを介して記憶へのアクセスを許可します。プラグインはすでに固定の設定場所を持つMCPサーバーをバンドルしているため、記憶レイヤーはスキルが使用するのと同じ配線に組み込まれます。能力レイヤーと知識レイヤーは、異なるストアから、同じドアを通って到達します。
実務における変化
インストールしたスキルは、まるであなたのチームが作成したかのように動作し始めます。同じ一般的な手順が、規約や例外を検索可能なコードベースに適用されるため、コードレビューのスキルは、チームが意図的に許容しているアダプターレイヤーのパターンを指摘しなくなります。
ツールの切り替えが、双方向で非常に低コストになります。フォーマットがスキルを移動させ、コンテキストはそもそもツール内に存在しなかったため移動します。エージェントのセットアップの両半分が同時にポータブルになったのはこれが初めてであり、CodexとClaude Codeを並行して実行する際に、同じ規約のコピーを2つ維持する必要がなくなる実用的な理由です。
指示ファイルが小さくなります。蓄積された記録の格納場所が確保されれば、AGENTS.mdは肥大化するアーカイブではなく、常時適用されるルールの短いリストに戻ります。これはコスト面でもコンプライアンス面でも優れています。なぜなら、500行のルールファイルはモデルのアテンションが不均一になる原因だからです。
そして、スキルが共有可能になります。現在、ほとんどのチームはコンテキストがスキルに溶接されているため、社内スキルを公開できません。レイヤーを分離すれば、スキルはその構造上、公開可能になります。
スキルと記憶を分離するためのベストプラクティス
「競合他社もこれを使用できるか？」テストを適用する
スキルを作成したら、同業他社がそれをそのままインストールして恩恵を受けられるかを自問してください。もし「はい」であれば、それはスキルです。一般性を保ち、パッケージ化してください。もし「いいえ」であれば、それはスキルの服を着たコンテキストであり、新しいバージョンをリリースすることなく更新できる記憶レイヤーに属します。
指示ファイルは記録ではなくルールのために維持する
すべてのリクエストで読み込まれるものは、短く、命令形であり、安定している必要があります。決定事項、履歴、参照資料は、オンデマンドでクエリされるストアに属します。これらを混同すると、すべてのタスクでコストがかかるにもかかわらず、必要な情報が含まれていないファイルが出来上がってしまいます。
スキルはバージョン管理し、記憶には日付を付与する
スキルは作成されたアーティファクトであるため、セマンティックバージョンが割り当てられます。記憶のエントリは決定の記録であるため、発効日が割り当てられます。置き換えられた決定事項も読み取り可能な状態を維持しなければ、前四半期の業務を解釈できなくなります。異なる失敗モードに対して、異なるストレージ管理を適用します。
記憶の標準化を待たない
MCPはエージェントがツールにアクセスする方法を標準化し、Agent Pluginsは能力がパッケージ化される方法を標準化しました。ポータブルなユーザー記憶に関する同様の合意は存在せず、プラグイン仕様自体のスコープ声明でも、それを試みていないことが明記されています。MCPまたはAPIを介して任意のクライアントが読み取れるストアを選択することが、現在利用可能な解決策であり、将来的にどのような標準が登場したとしても生き残る方法です。
結論
8月6日は真のマイルストーンでした。6つのベンダーがスキルとMCPサーバーの単一のパッケージフォーマットに合意したことで、エコシステムがツールごとに分断されるのを防ぐことができます。そして、仕様書自体の境界声明は、発表の中で最も有用な一文です。それはパッケージフォーマットであり、それ以上のものではありません。つまり、あなたの具体的な情報を保持するレイヤーは、最初からスコープに入っていなかったのです。
したがって、これらを2つの異なる問題として扱ってください。スキルはクリーンかつ一般的に作成し、標準規格にその配信を任せます。蓄積された記録（決定、規約、理由）は、エージェントが読み取り、あなたが編集できるストアに保管し、たまたま使用しているハーネスよりも長生きさせます。能力レイヤーはポータブルになりました。知識レイヤーをポータブルにするかどうかは、依然としてあなた次第であり、それこそが構築に6ヶ月を要したもう半分の要素なのです。