コピーされても生き残るエージェントの条件
コピーされても生き残るエージェントの条件
競合が自分のエージェントをコピーした。プロンプトも同じ、モデルも同じ、機能も同じ。なのにユーザーが離れなかった。なぜか？
1. 「コピーを防ぐ」は問いが間違っている
エージェント市場において、プロンプトのコピーは驚くほど簡単だ。システムプロンプトを抽出する手法はすでに広く知られており、同じモデルAPIを呼び出すのに参入障壁など存在しない。競合があなたのエージェントを分析し、似たプロンプトを書き、同一のモデル上に載せるまでにかかる時間は、長くても数日だ。機能をひとつリリースすれば、2週間以内に似たものが3つは出てくる。
だから多くの人が「どうやってコピーを防ぐか」を考える。プロンプトを暗号化する、独自モデルをファインチューニングする、特許を取る。しかし、この問い自体が罠だ。防壁を築くのに費やすエネルギーは大きく、その壁は結局突破される。ソフトウェアの歴史が繰り返し証明してきた事実だ——機能はコピーされる。
本当の問いは別のところにある。「コピーをどう防ぐか」ではなく、**「コピーされた後もなぜユーザーが残っているのか」**だ。
機能の差別化がmoatになり得ない理由は単純だ。エージェントの機能とは結局、プロンプトとモデルとツール呼び出しの組み合わせであり、この三つはすべて公開された素材だ。ChatGPTプラグインが登場したとき、数百もの「PDF要約エージェント」が溢れ出た。機能は同一だった。生き残ったものと消えたものの差は、機能ではなかった。
では何が違いを生むのか？コピー品とオリジナルの間でユーザーが体感する差はどこから来るのか？この文章はその構造を掘り下げる。結論を先に言えばこうだ——コピーを防ごうとするな。コピーしても無意味な構造を作れ。
2. 「もう自分に合わせてくれているから」
行きつけのカフェがある。ドアを開けるとバリスタが顔を上げて「今日もアイスアメリカーノですか？」と聞いてくる。こちらはうなずくだけでいい。メニューを見る必要も、サイズを伝える必要も、氷の量を説明する必要もない。あの一言が省いてくれるのは5秒の時間ではない。「ここは自分を知っている場所だ」という感覚だ。
ある日、家の前に新しいカフェがオープンしたとしよう。内装もきれいで、豆も同じブランドで、値段も似ている。メニューは事実上同じだ。しかし実際に行ってみると、微妙に居心地が悪い。自分が欲しいものを一から説明しなければならない。「アイスアメリカーノ、トールサイズ、氷少なめで。」間違ってはいない。ただ、これを毎回繰り返さなければならないという事実が疲労になる。結局、足は行きつけの店に戻る。コーヒーの味がおいしいからではなく、そこのほうが楽だから。
エージェントでもまったく同じことが起きる。
競合があなたのエージェントをコピーした。プロンプト構造も持っていき、同一のモデルを使い、機能リストも漏れなく揃えた。見た目では区別がつかない。しかしユーザーが実際に使ってみると、何かが違う。オリジナルのエージェントは、コードレビューを頼めばdiff形式で要点だけを指摘してくれたのに、コピー品は冗長な説明から始まる。オリジナルは「短く」と言わなくても、すでに短く答える術を知っていた。コピー品は知らない。
この差はプロンプトから来るのではない。コンテキストの蓄積から来る。
エージェントがユーザーとやり取りする中で積み重なっていくものがある。このユーザーはbullet pointを好むのか文章形式を好むのか。説明が長いと苛立つのか、詳しいほど喜ぶのか。コードを渡すときコメントが欲しいのか、クリーンなコードだけが欲しいのか。こういったことは明示的にプロンプトに書かれない。ユーザー本人も自分の好みを正確に説明できない。しかし使い続けるうちに、エージェント側にそのパターンが蓄積されていく。
Claude Codeを例に挙げてみよう。最初に使ったときは、いちいち指示しなければならなかった。「韓国語で答えて」「ファイル全体を見せずに修正箇所だけ見せて」「コミットメッセージは英語で。」一ヶ月ほど経つとCLAUDE.mdにこうした好みが整理されており、エージェントは自分が言う前にすでに自分のやり方で動いていた。誰かが自分のCLAUDE.mdをコピーしていくことはできる。しかしそのファイルが作られるまでの試行錯誤——自分が「これは違う」と修正し、「こっちのほうがいい」と確認した数十回のフィードバック——は持っていけない。ファイルはコピーされるが、そのファイルが自分に合っている理由はコピーされない。
これが最初のmoatの核心だ。プロンプトはコピー可能だが、コンテキストはコピー不可能だ。
コンテキストとは単なる「ユーザープロフィール」のような静的データではない。生きた適応の記録だ。このユーザーが先週どんなミスをして今週は何をより確認すべきか、特定のライブラリを使うとき繰り返すパターンがあるから似たリクエストにはそれを先に提案すべきか。こうしたコンテキストは時間が経たなければ蓄積されず、インタラクションを通じてのみ形成される。競合がコードを丸ごと持っていっても、この部分は空欄のまま残る。
新しいエージェントは自分を知らない。同じエンジンを積んでいても、自分を知らないツールは汎用的に振る舞うしかない。汎用的であるということは間違わないという意味だが、ぴったり合うわけでもないという意味だ。ユーザーが「これは自分のツールだ」と感じる瞬間は、間違わないときではなくぴったり合ったときだ。
結局、ユーザーが離れない最初の理由は単純だ。離れる理由がないからではなく、**もう一度説明するのが面倒だから。**新しいエージェントに自分を一から教えるコスト——switching cost——は思ったより大きい。そしてこのコストは、オリジナルを長く使うほど大きくなる。時間がmoatになる。
3. フィードバックフライホイール — 時間が作る堀
前章で、コンテキストは複製不可能であることを確認した。では、そのコンテキストはいったいどうやって蓄積されるのか？ 勝手に生まれるものではない。そこには構造がある。その構造をflywheelと呼ぶ。
フライホイールのループはシンプルだ。エージェントがアウトプットを出す → ユーザーが反応する（修正、承認、あるいは無視） → エージェントがその反応からパターンを学習する → 次のアウトプットが改善される。 このサイクルが一周するたびに、エージェントは少しずつ正確になり、ユーザーは少しずつ説明する量が減っていく。回転が速くなるほど摩擦は減る。これがflywheelが「慣性」を持つと言われる理由だ。
ここでよく混同される概念がある。会話履歴とフィードバックフライホイールは別物だ。会話履歴はセッションに紐づいている。ウィンドウを閉じれば終わりだ。次に新しい会話を開けば、エージェントはまた白紙の状態に戻る。一方、フライホイールが生み出す蓄積はセッションを超えて存在する。昨日のフィードバックが今日のアウトプットを変え、先月の失敗パターンが今月の判断を矯正する。履歴が短期記憶だとすれば、フライホイールが積み上げるのは長期記憶だ。
具体的に、この蓄積はどんな形をとるのか？ ユーザーごとの選好モデルがある — この人は簡潔な回答を好み、あの人は根拠も一緒に見たがる。ドメイン判断の履歴がある — このコードベースではORMの代わりにraw SQLを使うのがチームコンベンションで、エラー処理は必ずearly returnパターンに従う。失敗と成功のパターンDBがある — 前回このアプローチでテストが壊れ、その前はこの方法でレビューを通過した。これらが集まると、単なる「設定」ではなく一つのプロファイルになる。そのユーザー、そのチーム、そのドメインに最適化された判断体系。
三つの事例で、この構造が実際にどう機能するのかを見てみよう。
Claude Codeのmemory。「テストコードでDBをモックするな、実際のテストDBを使え」と一度言う。するとそれ以降のすべてのセッションで、エージェントはテストを書く際に実DBへの接続をデフォルトにする。二度言う必要はない。ここに「コミットメッセージは英語で」「TypeScript strictモード基準で型チェックして」「PR説明には変更理由を先に書いて」といったフィードバックが一つ、また一つと積み重なる。数百個になれば、それはもはや設定ファイルではない。そのユーザーだけの開発スタイルプロファイルだ。コードをどう構造化するか、どんなパターンを嫌うか、レビューで何を重視するかまでが含まれる。新しい競合ツールが現れて「うちもmemory機能ありますよ」と言うことはできる。機能は同じかもしれない。しかし空のmemoryと6ヶ月分のフィードバックが蓄積されたmemoryは、まったく別の代物だ。
SpotifyのDiscover Weekly。 毎週月曜日、Spotifyはユーザーごとに30曲のプレイリストを作ってくれる。推薦アルゴリズム自体は論文で公開されており、似たようなcollaborative filteringを実装するのは難しくない。実際にApple Music、YouTube Music、Tidalのいずれも類似の推薦機能を持っている。ところが、Spotifyから他のサービスに乗り換えた人たちが口を揃えて言うことがある。「レコメンドがありきたりになった。」アルゴリズムが劣っているからではない。7年以上蓄積された聴取履歴 — どの曲を30秒でスキップし、どの曲をリピート再生し、どのジャンルを金曜の夜だけ聴くのか — このデータがないからだ。新しいサービスのレコメンドは「新人レベル」にリセットされる。技術は複製できるが、時間が作ったデータは複製できない。
GitHub Copilotのコードベース学習。 チームが6ヶ月間Copilotを使いながら蓄積してきたものがある。このリポではaxiosの代わりにkyを使うこと、エラー型は必ずカスタムのAppErrorクラスを継承すること、テストファイルの命名は*.spec.tsではなく*.test.tsであること。Copilotはコードベースのパターンとチームコンベンションを学習した状態で提案を出す。ここで競合ツールが登場して「コード自動補完の精度95%」を謳ったとしよう。チームが実際に切り替えてみると、提案されるコードが微妙にチームのスタイルと合わない。axiosをimportし、Errorを直接throwし、ファイル名を.spec.tsにする。一つずつ直すことはできる。だが、この矯正をまた6ヶ月続けなければならないという事実が、切り替えを躊躇させる。機能の優劣ではなく、蓄積の差がユーザーを引き留める。
三つの事例に共通点が見える。Claude Codeは個人開発者のスタイルを、Spotifyは消費者の嗜好を、Copilotはチームのコンベンションを蓄積する。ドメインは異なるが構造は同じだ。アウトプット → 反応 → 学習 → 改善、このループが繰り返されるほど代替コストは上がっていく。
競合が今日同じものを作っても、6ヶ月分の蓄積データは金では買えない。サーバーを増やしても、モデルを大きくしても、エンジニアを増員しても、時間を圧縮する方法はない。フライホイールはゆっくり回り始めるが、いったん回り出すと加速し続け、その慣性そのものが堀になる。機能は一晩で複製されるが、フライホイールが生んだ慣性は一晩では複製されない。
4. 深い統合 — 乗り換えの痛みが作る堀
フライホイールが「時間」が作る堀だとすれば、ここで語るのは「深さ」が作る堀だ。性質が異なる。時間の堀は蓄積が作り、深さの堀は接続が作る。
エージェントが一つのツール（tool）として存在する場合を考えてみよう。チャット欄に質問を入れれば答えが返ってくる。便利だ。ところがある日、もっと優れたエージェントが現れた。何をすればいいか？ ブックマークを変えればいい。既存のチャット欄を閉じて、新しいチャット欄を開く。以上。乗り換えコストはほぼゼロに近い。データもなく、接続もなく、切り離すべきものが何もないからだ。ツールは独立して存在し、独立して交換される。
では別の状況を想像してみよう。エージェントはもはやチャット欄ではない。ワークフローの**連結組織（connective tissue）**になっている。
具体的なシナリオがある。チームメンバーがSlackにメッセージを残す — 「決済モジュールでタイムアウトエラーが断続的に発生しています。」エージェントがこのメッセージを検知する。内容をパースしてJiraにバグチケットを自動生成する。優先度は過去の類似イシューのパターンを見てP2に設定する。関連するコード領域を特定して担当開発者にコードレビューをトリガーする。開発者が修正PRを上げると、エージェントが変更内容を要約し、テスト結果とともに元のSlackスレッドに返信する — 「修正完了。タイムアウト閾値を3秒から10秒に調整。テスト通過。」この流れは一つの機能ではない。Slack、Jira、GitHub、CI/CDを貫く一本のパイプラインだ。エージェントはそのパイプラインの中心で、各システムをつなぎ合わせる接着剤（glue）の役割を果たしている。
この状態で「もっと優れたエージェント」が現れたとしよう。自然言語理解能力が20%優れ、応答速度が2倍速い。乗り換えたい。ところが乗り換えるには何をしなければならないか？ Slack連携を新たに設定しなければならない。Jiraのプロジェクトごとのチケット生成ルールを再定義しなければならない。コードレビューのトリガー条件を移行しなければならない。CI/CDパイプラインとの接続を再構成しなければならない。通知チャンネルとメンションルールを再マッピングしなければならない。そしてこれらすべてが以前のようにスムーズに回るか検証しなければならない。検証期間中、チームのワークフローは不安定になる。チケットが漏れ、通知が見当違いの場所に飛び、レビューがトリガーされない隙間が生じる。
乗り換えの代償が「不便」レベルではなく「業務麻痺」レベルになる。だから移行しない。20%賢いエージェントがあっても、すでに四つのシステムを貫通してチームの日常を支えている接着剤を剥がす痛みのほうが大きいからだ。
ここでツール（tool）と接着剤（glue）の違いが鮮明になる。ツールは一つの地点で価値を生む。「質問すれば答える」「コードを入れればレビューする」。接着剤は地点と地点の間で価値を生む。システムAのアウトプットをシステムBのインプットに変換し、その結果をシステムCに渡す。ツールの価値はそのツール自体の品質に依存するが、接着剤の価値は接続されたシステムの数と深さに依存する。ツールはより良いツールが出れば交換される。接着剤はより良い接着剤が出ても剥がしにくい — 貼り付いている面積が広すぎるからだ。
だからこそ、エージェント製品を作る人に贈れる最も実践的なアドバイスはこれだ。機能ではなく接着剤（glue）を作れ。 一つのことをうまくこなすエージェントを作るのはスタートに過ぎない。そのエージェントがユーザーの既存システムの間に入り込み、なくなれば流れが途切れる存在にならなければならない。接続が深まるほどswitching costは指数関数的に増大する。一つのシステムと接続されたエージェントの乗り換えコストが1だとすれば、四つのシステムを貫通するエージェントの乗り換えコストは4ではなく4の二乗に近い — 接続間の依存関係まで一緒に移行しなければならないからだ。
フライホイールがユーザー個人のコンテキストを積み上げて離脱を防ぐなら、深い統合は組織のワークフローを包み込んで離脱を防ぐ。一方は「自分をもう一度教え直すのが嫌だから」離れられず、もう一方は「これをもう一度つなぎ直すのが嫌だから」離れられない。二つの堀が同時に機能するとき、複製は本当に意味を失う。
5. 二つのmoatが出会うとき — 複製不可能の完成
ここまで二つのmoatを別々に見てきた。フィードバックflywheelが生み出す時間のmoat、深い統合が生み出す深さのmoat。それぞれ単独でも強力だ。しかし、この二つが別個に存在する場合と、一つのシステムの中で結合される場合とでは、まったく異なる話になる。
結合の構造はこうだ。flywheelが回るほど、エージェントはユーザーのワークフローをより深く理解するようになる。どの状況でどのシステムに作業が引き渡されるのか、どの段階でボトルネックが生じるのか、チームメンバー間のコミュニケーションがどんなパターンで流れるのか。この理解が蓄積されると、エージェントは単に「連携している」レベルを超えて、「より深い統合」を提案できるようになる。「Slackでこのタイプのメッセージが来たらJiraチケットを作るのではなく、まず関連するPRがあるか確認して、すでに修正中ならSlackにステータスを返信するのはどうでしょう？」といった提案だ。この提案は、ワークフローを長く観察してきたエージェントにしかできない。新規ツールには不可能だ。
逆方向も機能する。統合が深いほど、エージェントが触れるコンテキストデータは豊かになる。チャット画面の中だけでユーザーを観察するエージェントは、「この人が何を聞いているか」しかわからない。しかし、複数のシステムを貫通しglueとして機能するエージェントは、「この人がどう働いているか」を知っている。このデータがflywheelに供給されれば、学習の速度と精度がともに上がる。flywheelが加速する。
整理するとこういう循環だ。flywheel → ワークフロー理解の深化 → より深い統合の提案 → より豊かなコンテキスト収集 → flywheelの加速。 好循環だ。時間が経つほどmoatは広がる一方である。ここで決定的な非対称性が生まれる — 競合が今日すぐにより優れたモデルとより速い応答速度を引っ提げて現れても、この循環が生み出した蓄積に追いつくには同じ時間を投資しなければならない。 技術格差は資本で縮められるが、時間格差は時間でしか縮められない。
では、この二つのmoatのうち片方しか持たない場合はどうか。現実の反例を見てみよう。
データはあるが統合がない場合 — Notion AI。 Notionはユーザーのデータを膨大に保有している。議事録、プロジェクト文書、個人メモ、チームWiki。AI機能はこのデータをもとにかなり賢く動作する。ユーザーがNotionに多く書き込むほど、AIはより正確な回答ができるようになる。
問題は統合の不在だ。Notion AIはNotionの中でしか動作しない。ドキュメント内で質問し、ドキュメント内で回答を受け取る。エージェントがSlackに通知を送ったり、Jiraチケットを作ったり、GitHub PRをトリガーしたりはしない。ワークフローのglueではなく、一つのアプリに閉じ込められた補助機能だ。だからユーザーがNotionのドキュメントをConfluenceに移すと決めたら、exportボタン一つでデータは抜け出せる。AIが積み上げてきたコンテキスト？ 一緒に消える。Notionの外では何も途切れないから。連携しているものがなければ、切れるものもない。データがどれだけ豊富でも、そのデータがワークフローの複数の地点を貫通していなければ、ユーザーを引き留める力は弱い。
統合はあるが学習がない場合 — 初期のZapier AI。 Zapierは統合の王だ。数千のアプリを連携し、ワークフロー自動化においてここまで深く入り込んだサービスは珍しい。「Gmailに特定の件名のメールが届いたら → Slackチャンネルに通知 → Google Sheetsに記録 → Trelloにカード作成。」こうしたパイプラインが数十個絡み合っているチームでZapierを剥がすのは相当な苦痛だ。深さのmoatは確かにある。
しかし初期のZapier AIにはflywheelがなかった。ユーザーごとの学習が不在だった。同じ種類の自動化を繰り返し設定しても、AIが「前回こうされたので、今回もこのパターンにしましょうか？」と提案することはなかった。毎回ゼロからだった。だから、より賢い自動化ツール — make.comやn8nのAI機能 — が登場したとき、ユーザーたちはマイグレーションの苦痛を覚悟してでも移る動機が生まれた。統合のmoatが乗り換えを困難にはしたが、「ここにいくら長くいても良くならない」という認識が乗り換えの決断を可能にした。長く使っても良くならないツールへの忠誠心には限界がある。
二つの事例が示しているのは明確だ。データだけではユーザーを囲い込めない — 統合がなければデータは容易に流出する。統合だけではユーザーを繋ぎ止められない — 学習がなければ、より良い代替の前で乗り換えの苦痛を甘受する理由が生まれる。moatが本当のmoatになるには、二つの軸がともに必要だ。時間が積み重なるほど正確になる学習、そしてその学習がワークフローの隅々に浸透し剥がせなくする統合。この二つが合わさったとき、はじめて複製不可能の構造が完成する。
6. 複製を防ごうとするな
最初の問いに戻ろう。競合があなたのエージェントを複製した。プロンプトも同じ、モデルも同じ、機能も同じ。なのにユーザーは離れなかった。なぜか。
答えは一文だ。複製品には時間がなく、連携がないからだ。
プロンプトはテキストファイルだ。コピーするのに1秒あれば足りる。モデルはAPIだ。キーを発行すれば誰でも呼び出せる。機能はコードだ。十分なエンジニアがいれば再現できる。しかし、6ヶ月間ユーザーとやり取りしたフィードバックが形作った判断体系はコピーできない。四つのシステムを貫通しチームの日常に浸透したconnective tissueは、キー一つで置き換えられない。複製品は機能的には同一だが、構造的には空っぽだ。空の殻が6ヶ月分の慣性に勝つことは起こらない。
だから逆説的な結論に到達する。複製を防ぐことにエネルギーを使うな。プロンプトを暗号化し、コードを難読化し、特許を出願することに費やす時間はmoatを生まない。そのエネルギーを別のところに使え。ユーザーが使うほど正確になるflywheelを設計し、エージェントがワークフローのglueになるよう統合の深さを広げろ。複製を防ぐ壁はいずれ破られるが、複製しても意味のない構造は破る必要自体がない。攻撃者が城壁を越えたのに、城の中には何もない — 本当の価値は壁の中の物ではなく、城の中を流れる時間と関係にあるのだから。
開発者であれ起業家であれ、エージェント製品を作っているなら自らに問うべき質問は一つだ。あなたのエージェントは使うほど良くなるか？ ユーザーのワークフローに浸透しているか？ どちらも違うなら、あなたのmoatはない。