11月3日、InfoWorldが「Before you buy an AI agent, make it pass an exit test」と題した記事を公開した。AIエージェントのポータビリティ議論はモデル選択の自由やプロトコル標準化で止まりがちだが、記事の著者は「本当のロックインはその下の層——作業途中のステート——に隠れている」と主張する。著者自身の移行失敗談がその逆説を鮮明に示しており、契約前に1日で実施できる「出口テスト」を具体的な手順とともに提案している。
「移行できた」は本当か？ 著者自身の失敗談
記事の書き出しは著者自身の失敗から始まる。
あるコーディングエージェントから別のエージェントへ移行するのに10分かかった。グローバル設定ファイルを新しいツールが読む名前（AGENTS.md）にコピーし、製品名をfind-and-replaceで置き換えた。移行は完了したように見えた。ところが約3ヶ月後、その設定ファイルが壊れていることに気づいた。
具体的には、旧エージェント用の-pフラグの意味が新ツールでは異なっており、すべてのモデル呼び出しが存在しないコンフィグプロファイルを参照するよう指示していた。さらに「旧ベンダーのAPIキーを絶対に使うな」という警告が太字で残っていたが、そのエージェントはそのキーに近づく理由すら持っていなかった。エラーは何も出なかった。
「これがミニチュアサイズの出口問題だ。モデルは午後一つで切り替えられる。作業の状態（ワーキングステート）はついてこないし、何も教えてくれない。」
ポータビリティの主張はモデル層で止まる
ベンダーはロックインへの質問に慣れている。「モデル選択の自由」「標準プロトコル対応」「会話のエクスポート機能」を挙げてくる。MCP（Model Context Protocol）やAGENTS.mdがLinux Foundation傘下のAgentic AI Foundationに移管されたことも、プロトコル標準化の文脈では良いニュースだ。
しかしそれらはどれも「作業途中のジョブが移行を生き延びるか」を保証しない。
ここで言う「ワーキングステート（working state）」とは、エージェントが長期タスクを遂行する中で蓄積する作業文脈の総体だ。モデルの重みでも会話ログでもなく、「どの意思決定を尊重してきたか」「どのアプローチを試して棄却したか」「どこまで完了し、何が残っているか」「どのパーミッションやフックが設定されているか」といった、プロジェクト固有の状態を指す。会話をエクスポートすれば「何を言ったか」の記録は得られる。しかし作業のステートは得られない。
6ヶ月間コードベースで動き続けたエージェントは、まさにそうした文脈を蓄積している。標準プロトコルへの準拠はモデル呼び出しの互換性を担保するが、このワーキングステートを別ベンダーへ引き継ぐ仕組みは現状ほぼ存在しない。
なお、EU Data Actのクラウド切り替えルールは2025年9月から適用が始まっており、2027年1月以降はプロバイダーが切り替えコストを顧客に請求することも禁じられる。これはデータ処理サービスを主な対象とした規制だが、エージェントが蓄積するワーキングステートを「データ」として扱えるかどうかによって、エージェントサービスへの適用範囲が変わってくる。ただし、記事自体もこの点は不明確と注記しており、現時点では解釈が定まっていない。
出口テストの具体的な手順
記事の核心はここだ。契約前または更新前に1日かけて実施できるドリルとして以下が提案されている。
タスクの選び方
「記憶が必要なメンテナンス作業」を使う。記事が例として挙げているのは、12モジュールにまたがるロギングライブラリのアップグレードだ。途中で人間が意思決定を変更する——具体的には、ある下流コンシューマーのために旧ログフォーマットを維持することにし、エージェントが初日に立てた前提を覆す——というシナリオを含める。
ベンダーに自分でタスクを選ばせてはいけない。「どのツールにも、記憶が完璧に見えるデモ用のパスがある。たいていは歴史もなく、以前の意思決定もない、グリーンフィールドの機能だ」と記事は指摘する。
ドリルの手順
- 最初のエージェントに作業を7モジュール完了、8つ目は意図的にスキップ（理由付き）の状態で止める
- エージェントが「作業の状態」としてエクスポートするもの（要件・意思決定・完了アクション・残タスク）を受け取る
- そのエクスポートだけを、別ベンダーのエージェント（または最低でも旧エージェントのメモリにアクセスできない新規セッション）に渡す
4つの評価ポイント
① 完了済み作業をやり直すか？ 7つのモジュールを再移行するなら、エクスポートは「意図」を記録したが「完了」を失っている。ロギングアップグレードなら軽微なミスだが、スキーママイグレーションならインシデント級だ。
② 棄却された前提を復活させるか？ これが記事が最も重視する失敗パターンだ。意図的にスキップしたモジュールを2番目のエージェントが「修正」するなら、エクスポートは元の計画を持ち込み、それを上書きした人間の決定を落としている。ビルドは何もフラグを立てない——コードは（もはや存在しない）計画と完全に整合しているから。
③ コンテキスト再構築に何分かかるか？ ストップウォッチで計測する。エンジニアが記憶から答えなければならない質問の数が、エクスポートで失われたステートの量だ。
④ 移行時に何が壊れたか？ ベンダー固有のコマンドを参照する設定ファイル、一方のツール固有フォーマットで書かれたスキル、特定ツールのイベントで発火するフック、特定製品にスコープされた認証情報——これらをリストアップする。そのリストが本当の切り替えコストであり、契約書が示唆するどの数字よりも長い。
ドリルは2回実施する。同一製品内での新規セッションと別ベンダーへのクロスベンダー移行だ。前者はその製品自体の継続性が本物かを検証し、後者は離脱コストを明らかにする。
ベンダーへの質問リスト
記事は、ベンダーに「説明させる」のでなく「実演させる」よう求めることを推奨している。
- エクスポートフォーマットのフィールドを一つひとつ確認する（意思決定と完了アクションはチャットログと分離されて保存されているか）——ワーキングステートの核心部分が実際にエクスポートに含まれているかを確かめるためだ。ログだけが出てくるなら、それはステートではなく履歴に過ぎない
- メモリとスキルのフォーマットは他のツールが読めるほど文書化されているか——標準プロトコルへの準拠を主張するベンダーでも、メモリ層の仕様が非公開では移行時に手作業が発生する
- 契約終了時にそのステートはどうなるか——どれくらいの期間、どのフォーマットで、どのコストで取り出せるか——返却期限やフォーマットが不明確なままでは、EU Data Actの議論とは別に、実務上の出口が塞がれることになる
「製品を信頼しているベンダーならこれを喜んでやってみせるはずだ。大口顧客はすでに同じことを聞いている。返ってくるのがオープンモデルのスライドとプロトコル仕様のリンクだけなら、彼らの出口ストーリーがモデル層にしか及んでいないことがわかる」と記事は述べている。
テスト結果は数字で記録する
感覚ではなくテストレポートとして記録する。「タスク内容、エクスポートサイズ、繰り返した変更の数、復活した棄却済み前提の数、人間が費やした分数、破損した依存関係」を契約書と一緒にファイルし、更新時に再実施する。製品はバージョン間で変わり、昨年テストしたエクスポートが今日のものと同じとは限らない。
ベンダーへの公平性として付け加えるなら、一部のステートは本質的に移行が難しい。あるモデルの癖に合わせてチューニングされたスキルは、フォーマットが完璧でも別のモデルでは同じ動作をしない。出口テストの目的は「切り替えがタダだ」と証明することではない。まだ交渉の余地があるうちにコストを数字に置き換えることだ。
詳細はBefore you buy an AI agent, make it pass an exit testを参照していただきたい。
