Agent プラットフォームの人質になるのは、もうやめよう

月曜の朝。あなたは、同じ仕事を4回目に教えている。

1つ目のエージェントは、あなたの好みをよく覚えた。だが、そのメモはあなたのマシンの中、そのエージェント自身のメモリファイルに、その独自形式で眠っている。2つ目はプロセス全体を自社のクラウドで回し、見事にこなした。だが、その履歴は当該アカウント、当該プロダクトの中にしか存在しない。3つ目はまた別の断片を、ひとつのワークスペースの範囲でだけ覚えている。そして今、目の前に開いている4つ目——今期の「当然のアップグレード」——は何も知らない。空白のチャット欄。あなたは、また最初から説明する。

陰謀ではない。どのエージェントも、設計どおりに振る舞っているだけだ。学んだものを手元に留めておけば、あなたは戻ってくる。だが、あなたの仕事の蓄積は、今どこにあるのか。好みは、あるベンダーのメモリストアに。タスク履歴は、別のベンダーのクラウドに。チームのルールは、3つの方言で、3つのフォルダ規約のもとに3回書かれている。ロックインは、モデルでは決してなかった。モデルは交換可能で、あなたも交換し続けている。人質はモデルではない。人質は、引き出し1つずつに分散して握られた、あなたのデータだ。

人質の仕組み：3つの引き出し

正確に言おう。この業界は、一枚岩に閉じているわけではない。そして、正直な版の問題は、標語版より厄介だ。静かだからである。

引き出し1：あなた自身が書くファイル。 Claude Code は CLAUDE.md（と AGENTS.md）を読む。Codex は AGENTS.md を読むが、独自の階層化と上限がある。Cursor は .cursor/rules/*.mdc を読み、ルールがいつ適用されるかについての独自の frontmatter セマンティクスを持つ。Copilot は .github/copilot-instructions.md を読む。これらはローカルファイルで、大半はあなたのリポジトリにあり、あなたの蓄積の中で最も持ち運びやすい層だ。しかし「持ち運べる」と「共有できる」は違う。ベンダーごとに名前が違い、置き場所が違い、形式が違い、読み込み規則が違う。あるエージェントへの指示を別のエージェントへ移す作業は、毎回、翻訳になる。

引き出し2：プラットフォームがあなたの代わりに蓄えるもの。 この層は、あなたが書いたものではなく、持ち出すこともできない。Claude Code の Auto memory——あなたの訂正や好みについて自ら書き留めたノート——は、1台のマシンの中、そのプロジェクトフォルダに、他では読めない形式で保存される。Codex にも同じ仕組みがあり（オプトイン）、OpenAI 自身のドキュメントはその生成物を「generated state」と呼び、~/.codex/memories/ に置かれ、Codex だけが呼び出せると説明する。OpenAI の家の中ですら、ChatGPT のメモリと Codex のメモリは別々のストアだ。GitHub の Copilot Memory は GitHub のプラットフォーム側にあり、Copilot 自身の画面からしか読めず、概念ドキュメントによれば、使われないエントリは28日で自動削除される。Grok はすべてをあなたの xAI アカウントのクラウドに置く。チャット履歴、学習した好み、パーソナライズ。アプリ間で同期され、エクスポートはアカウント全体のダウンロード1回きりだ。Devin のクラウドセッション、Playbooks、組織の知識は Cognition のプラットフォームに住む。そして Cognition が Knowledge 機能を廃止したとき、ユーザーが蓄えたノートは、ベンダーの日程とベンダーの判断で移行された。Manus はあなたのタスクを自社のクラウドサンドボックスで実行し、記録と成果物はあなたの Manus アカウントに残る。API 経由のアップロードファイルは48時間で削除される。

引き出し3：仕事そのもの。 指示とメモリの下に、本当に大切なものがある。仕事の記録——リードとその状態、タスクと担当者、下書き、承認、結果——だ。エージェントが自社プラットフォームの中で仕事をこなすと、その状態はプラットフォームの内部に生まれる。セッションの書き起こし、タスクリスト、サンドボックスのファイルシステム。あなたが去るとき、手元に残るのは書き起こしだけだ。検索でき、構造化され、今も動いている「状態」は、置いていかれるか、蒸発する。

3つの引き出しに共通するのは、悪意ではない。どのプラットフォームも「場所」であり、あなたの仕事は、エージェントがたまたま住んでいる場所に蓄積する。 エージェントを替えて失うのは、モデルではない。蓄積だ。

7つのプラットフォームを、一覧する

ここで公正な反論をひとつ。ファイルの層は、確かに収束しつつある。AGENTS.md は今や Linux Foundation 傘下の Agentic AI Foundation が管理するオープンフォーマットで、Codex、Cursor、Copilot、Devin が読む。SKILL.md —— Agent Skills フォーマット —— も同様に広く採用された。あなたが手で書くものは、旅ができるようになりつつある。プラットフォームが代わりに蓄えるものは、まだ旅ができない。 引き出しは残り、仕事はその中に住み続けている。

模式図——同じ問いへの2つの答え：仕事はどこに住むのか？

答えは、1枚の図に収まる

エージェントのそれぞれに「場所」であれと求めるのは、やめよう。場所は自分の側に置き、すべてのエージェントにそこを訪れさせる。

模式図——ひとつのプール、すべてのエージェント。製品UIではない。

プールは Busabase のワークスペースであり、その中身は意図的に地味だ。4種類、すべてあなたのもの。

• Skills（スキル） ——方法を、一級のノードとして。プールの中の Skill は常駐する作業標準であり、接続したどのエージェントも、動く前に同じものを読む。Playbooks はすべての Skill と各ノードのカスタムプロンプトを1つのカタログに集める。「ここではこれはどうやるのか」は、今日来た手が誰であれ、同じ場所で調べられる。
• アプリとコード ——データの上に建つ AirApp。あなたのチームが朝に開くフォローアップのボードは、エージェントが夜に更新するものと同一のオブジェクトだ。アプリは誰かのフロントエンドの中にはなく、データと一緒に住む。
• データベース——レコード ——仕事そのものを、型つきレコードとして。担当者、ステータス、リレーションを持つ。リードは書き起こしの中の1行ではなく、レコードだ。その状態は、あなたも、人も、次のエージェントも、検索できる。
• 構造化コンテキスト ——常駐の方針を保持するドキュメント（誰が対象か、何を決して約束しないか）と、物事の意味とつながりを示すリレーション。新しいエージェントは、チャットログからあなたの世界を推測しなくて済む。（物自体——会社、連絡先、取引——には、やがて明示的な意味の層が加わる。オントロジーであり、現在開発中で、まだ提供されていない。）

ではエージェントは？ つなぐだけだ。Agent Skill、MCP、OpenAPI、CLI、あるいは ACP セッション経由で。プールには組み込みモデルはなく、お気に入りもない。エージェントは、自らのローカルスキルディレクトリをワークスペース内の Skill ノードに向けさせることさえできる。その場合、従う方法はプールの原本であり、自ら保持するフォークではない。エージェントの書き込みはすべて Change Request として届く。差分、著者、履歴を持つ提案だ。だからプールの蓄積はガバナンスの下で進み、声の大きい者の順にはならない。アーキテクチャはこれだけだ。エージェントは手であり、プールは記憶であり、ルールであり、記録である。手は交換される。プールは残る。

切り替えを、実演する

同じ1週間を、プールでやり直してみよう。（これは手順の実演であり、顧客事例ではない。注目点は「何をしなくて済むか」だ。）

月曜日、Claude Code がリードのフォローアップを担う。プールのドキュメントから ICP を読み、フォローアップの Skill に従い、返信の下書きをリードのレコードに載せ、送信は同じレコードに記録され、書き込みはチームが確認できる Change Request として残る。水曜日、あなたは Codex を試している。同じワークスペースに接続する——セットアップはスキルファイル1つ——フォローアップの継続を頼む。Codex が読むのは、同じレコードだ。どのリードが待っているか、何がすでに送られたか、常駐の方針が何と言うか、前のエージェントが何をし、なぜそうしたか。月曜の説教は要らない。そもそも説教などなかったからだ。文脈は月曜のチャット欄には決してなかった。プールにあった。金曜日、チームメイトが、あるリードが止まっている理由を尋ねる。誰も書き起こしを開かない。レコードには状態があり、履歴には書き込みがあり、Change Request には誰が何を承認したかがある。

手が替わったものは何か。モデル、インターフェース、請求書だ。替わらなかったものは何か。データ、ルール、文脈、履歴、そしてその上に建つアプリだ。仕掛けはこれで全部であり、それが成立するのは、それらが一度もエージェントの内部に保存されなかったからにほかならない。

魔法で消えないものも、正直に

宣言は、正直さなしには腐る。プールへ移しても、プラットフォームがすでに蓄えたメモリは取り込めない。どのベンダーもそのエクスポートを提供していない——それこそがこの記事の論点そのものだ。プールは、あなたのレコードとルールから蓄積を始め、以後、その蓄積はあなたのものになる。プラットフォーム固有の便利さも置いていく。エージェントが自らメモリを書く心地よさは本物だが、プールのモデルでは、その学習はレビュー可能な場所に着地しなければならない。経験レコードとして記録され、レビューを経て Skill へ昇格する。ひとつのツールの中で静かに複利化するのではなく。リポジトリ内のファイル規約も引き続き重要だ。リポジトリの AGENTS.md とプールの Skill は従兄弟であって、代替ではない。そしてワークフロー実行の話は、いつもどおり調整済みのものだ。ランタイムの初版は今日すでに在り（手動起動、またはレコード変更時の起動）、フィールド値トリガー、スケジュール、Webhook ヘッダー、承認者ピッカーが、今まさに届きつつある一括分だ。

プールは、より大きなプラットフォームではない。それはひとつの決断だ。蓄積——エージェントをあなたにとって有用にする、まさにそのもの——は、あなたが所有する場所で、あなたが検査できる形式で、あなたが定めた権限のもとで、複利化すべきだ、という決断。Busabase はオープンソースで、コマンド1つでセルフホストできる。プールはあなたのマシンの上に住める。それこそが要点だ。その出発点については「自分のデータベース」に、記憶とルールの層そのものについては「Supabase と Busabase の違い」に書いた。

FAQ

AGENTS.md を全面的に標準化すれば、それで済むのでは？ 済まないが、やるべきだ。それが最もよく旅をする層であり、この表は半分、その推奨でもある。だが AGENTS.md が運べるのは引き出し1だけ——あなたが書いた指示——だ。プラットフォームが蓄えたメモリ、実行の履歴、仕事そのものの構造化された状態は運べない。ファイルは標準化せよ。ただし、ファイルを資産全体と取り違えるな。

Busabase もまた、次のロックインになるのでは？ 最も当然の問いであり、検証可能な答えがある。Busabase はオープンソースで、Postgres（または組み込み PGlite）の上で動き、コマンド1つでセルフホストできる。プールはあなたのノートPCにも、あなたのサーバーにも置け、中のレコード、ドキュメント、Skill は、あなたがエクスポートし、検査できる。この記事が全員を測る物差しで、Busabase も測ってほしい。蓄積はどこに住み、誰がそれを取り上げられるのか。設計目標は、賃貸ではなく主権だ。長編は「エージェントのためのソブリンAI」にある。

お気に入りのエージェントを手放す必要はある？ ない。それが要点だ。Claude Code には得意な仕事をさせ、来期は Codex を試し、素早い質問は Grok に聞けばよい。プールは忠誠を求めない。求めるのはひとつだけだ。今日働いている手が誰であれ、あなたのレコードの上で、あなたのルールの下で働き、状態を、明日の手が見つけられる場所に残すこと。

エージェントは変わり続ける。プールまで、変わる必要はない。

来期には、より良いエージェントが出る。価格変更も、機能の廃止も、買収もあるだろう。Devin のユーザーはすでに目撃した。プロダクトの改名と、メモリシステムの途中での廃止を。どれも醜聞ではない。若い市場の、通常の天気だ。醜聞なのは、会社の働く記憶を、その天気に吹かれるままの場所に住まわせ続けることだ。

だから——エージェントプラットフォームの人質になるのは、もうやめよう。エージェントは全員、残していい。勝者が誰であれ。スキルも、アプリも、データベースも、文脈も、あなたの名前のついたひとつのプールへ移し、現在と未来のすべてのエージェントに、そこへ接続させよう。

• まずはプールそのものから：「自分のデータベース」——コマンド1つでセルフホスト
• プールの中の枠組み：「Supabase と Busabase：記憶とルールの層」
• プールの中の仕事がワークフローとして編成される理由：「企業の原子単位はワークフローである」
• コード：github.com/busabase/busabase · ドキュメント：busabase.com/docs