冒頭は記事のために生成したイメージ映像です。実機、実在施設、観測データを示すものではありません。
一つのAI Agentと長く仕事をしていると、乗り換えが怖くなる。
この会話には、こちらの意図が伝わっている。すでに試した失敗も知っている。どの案を捨て、何を大切にしたかも積み上がっている。
新しいmodelが出た。速い。安い。別の仕事では、とても優秀だった。
それでも切り替えられない。
「また最初から全部説明するのか」と思うからだ。
ここで見落としやすいことがある。私たちが守りたいのは、そのAIそのものだろうか。それとも、AIと進めてきた仕事の状態だろうか。
2026年8月、Spotifyが公開したXirpは、この問いへかなり正面から答えた。
modelは交代していい。仕事の途中経過まで、一緒に退職させなければいい。
Spotifyは、AI選びより先に「持ち運べる仕事場」を作った
SpotifyはXirpを、vendor-neutralなagentic development environmentと説明している。
Claude Code、Gemini CLI、Codexなど、複数のcoding agentを同じ作業環境から扱う。50を超える並行sessionを管理し、各sessionは独立したGit worktreeで動く。途中でtoolやmodelを替えても、working stateを引き継げるという。
ポイントは、「どのAIが一番賢いか」を決め打ちしていないことだ。
深い設計に向くmodel。単純な修正を安く速く終わらせるmodel。新しく登場し、昨日までの首位を入れ替えるmodel。仕事に合わせて動力を替えられる。
Spotifyは、そのために動力ではなく、仕事場を固定した。
さらに同社のPortalと接続すると、componentの構造、依存関係、owner、architectural decisionなどを、Agentがsession開始時に参照できる。終了後のtranscriptやmetadataはPortalへ戻り、次の人やAgentが再開するための材料になると説明している。
Spotifyによれば、Xirpは社内の数千人のengineerに使われ、36,000を超えるsessionを扱った。もっとも、これはSpotify自身による導入報告で、独立監査された比較試験ではない。
また、「full working state」が具体的に何を含み、harness間でどう変換され、どれほど情報を失うのか。公開記事だけでは、そのformatや欠落率まで確認できない。
それでも、Xirpが示した設計思想には価値がある。
特定modelへの忠誠ではなく、仕事の状態を組織側に持つ。
三つのAIは、同じようには「覚えて」いない
Claude Codeにも、Codexにも、Gemini CLIにも、sessionを続ける仕組みはある。
Claude Codeは会話をlocal transcriptとして保存し、resumeやbranchができる。projectの指示にはCLAUDE.mdを使い、repository単位のauto memoryも持つ。session中にmodelを替えることもできる。
Codexはthreadを再開、分岐できる。repositoryに置いたAGENTS.mdなどをinstructionとしてcontextへ取り込み、再開時にmodelを明示的に替える仕組みも公式実装から確認できる。
Gemini CLIもproject単位でsession historyを保存し、resumeできる。GEMINI.mdを階層的なproject contextとして読み込み、model変更やGit worktreeによる並行作業も扱う。（2026年9月28日確認：個人向けの無料・Pro・Ultra経路は6月18日にAntigravity CLIへ移行した。有料APIキーやGemini Code Assist Standard／Enterprise経由のGemini CLIは続いているため、利用経路は最新の公式案内で確認したい。）
よく似ている。
けれど、同じではない。
保存場所も、instruction fileの名前も、memoryの読み込み方も、tool callのschemaも違う。Claudeのsession IDをCodexへ渡せば、そのまま続きが始まるわけではない。Geminiのmemoryを別製品が同じ重みで解釈する保証もない。
同じtoolの中でmodelを替えることと、別harnessへ仕事を移すことも、分けて考えた方がいい。
前者は、同じ会話履歴とtool環境を別のmodelが読み直せる場合がある。後者は、会話の役割、system instruction、権限、tool definitionまで変わり得る。
session continuityは製品機能。仕事のcontinuityは運用設計である。
2026年8月20日時点の公式ドキュメント確認に基づく仕様比較。session/in-context memoryの話で、model学習の話ではない。 図を大きく開く
持ち運べるものと、持ち運べないもの
AI Agentとの仕事を、大きく三層に分けると見えやすい。
一層目──その場のsession
会話、toolの呼び出し、直前の推論を支えるsummary、model固有のmemory、provider側のcache。
これは作業中の呼吸を作る大切な層だ。ただし、製品やmodelに強く結びつく。exportできる会話があっても、別harnessが同じrole、同じtool、同じ優先度で再生できるとは限らない。
二層目──目に見える作業状態
file、diff、branch、commit、test結果、生成物、issue、公開URL。
これは比較的持ち運びやすい。
Git worktreeは、複数のAgentが同じrepositoryで作業してもfile変更をぶつけにくくする。Gitの公式仕様が守るのは、branchやworking treeの状態であって、AIの会話ではない。
だからこそ強い。Claudeの気分も、Codexの記憶形式も知らずに、次のAgentはdiffを読み、testを再実行し、commitから現在地を確認できる。
三層目──組織が所有する正本
何を達成したいか。どの仕様が正しいか。なぜこの設計を採用したか。誰がownerか。何をしてはいけないか。何が終われば公開できるか。
この層を、一つの長いchatの中だけに置くと、modelを替えるたびに会社の記憶まで引っ越すことになる。
repository、decision record、catalog、issue tracker、検証台帳。人間と複数のAgentが読める場所へ置けば、modelはそこから必要な情報を取り直せる。
AIを替えても仕事を失わない会社は、AIの記憶力が高い会社ではない。AIの外に、帰る場所がある会社だ。
本文が提示する編集的な整理(概念モデル)。層ごとに持ち運びやすさが異なる。 図を大きく開く
Portabilityは、人格のクローンではない
ここは、期待を上げすぎない方がいい。
同じ資料をClaude、Codex、Geminiへ渡しても、同じ答えにはならない。
modelごとに学習、語彙、推論の癖が違う。harnessごとにsystem instruction、tool、permission、compactionの仕方が違う。あるAgentが「重要」と感じた一文を、別のAgentは背景情報として軽く扱うかもしれない。
会話を要約して渡せば、細かな判断の重みや、何度も失敗してようやく得た感覚が薄くなる。これはsemantic lossである。
だから、portabilityの成功条件を「前のAIとまったく同じになる」に置いてはいけない。
目標はもっと実務的だ。
別の知性が、推測で穴を埋めず、最初の安全な一手を選べること。
同じ人格を再現するのではない。同じ目的地へ向かう航海を、別の操舵手へ渡せるようにする。
決定・未解決事項・次の一手を一つの荷物へまとめる比喩です。AIの内部状態や人格をそのまま移す映像ではありません。 記事の論点を描いた生成概念映像です。
「vendor-neutral」でも、別のlock-inは残り得る
Xirpは、modelやcoding agentを替えられることをvendor neutralityとして掲げている。
これは大きな前進だと思う。
ただし、model lock-inが減れば、すべての依存が消えるわけではない。
組織のcontext、session history、skill、rule、MCP設定が、orchestration platform固有の形式にだけ蓄積すれば、今度はそのplatformから離れにくくなる。
XirpやPortalについても、公開情報だけでは、蓄積した文脈をどの形式でexportできるか、別基盤へどこまで移せるかを評価できない。
だから「複数modelに接続できるか」だけでなく、次も見たい。
採用判断と成果を、人間が読めるformatで取り出せるか。
repositoryや既存の正本をauthorityとして参照できるか。
sessionを削除した時、派生したmemoryやindexも追跡できるか。
別platformへ移る時、最低限のhandoffを再構成できるか。
接続先が多いことと、仕事の所有権が自社にあることは、同じではない。
全部保存すれば安心、でもない
では、すべての会話、すべてのtool log、すべての失敗を保存し、次のAIへ全部読ませればいいのか。
そう単純でもない。
Anthropicはcontext engineeringの解説で、contextを有限の注意資源として扱い、目的に効くhigh-signalな情報へ絞ることを勧めている。長くなるほど、古いlogや矛盾した指示が焦点を曇らせる可能性がある。
compactionにも限界がある。冗長なtool出力を落とせる一方、後で重要になる微妙な経緯まで消すことがある。
必要なのは、保存するか捨てるかの二択ではない。
Raw archive──証拠や復旧のために、アクセスを絞って残す。
Curated canon──採用判断、正しい仕様、再利用する知見だけを昇格する。
Task context──今回の仕事に必要なものだけを、都度読み込む。
保存量と、modelへ投入する量を分ける。
continuityは、会話を無限に長くすることではない。必要な時に、必要な記憶へ戻れることだ。
Transcriptは、組織知である前に機密情報かもしれない
sessionの共有には、もう一つ大きな境界がある。
会話履歴には、promptだけでなく、toolの入力と出力が入る。local path、error log、顧客名、内部URL、databaseの断片。場合によってはtokenやcookieに近い情報が紛れる。
Spotifyは、Xirpのsession transcriptとmetadataがPortalへ戻ると説明している。組織全体の再利用には強い。一方で、共有範囲、保存期間、削除、redaction、監査を同時に設計しなければ、便利なmemoryが大きな情報集積地になる。
特にcredentialとpermissionは、「文脈」として運んではいけない。
秘密情報をhandoffへ書き写すのではなく、移行先のAgentへ必要な権限だけを再付与する。前のsessionで許された操作が、次のAgentでも当然に許されると思わせない。
知識は運ぶ。権限は境界で結び直す。
別のAgentへ仕事を渡す、最小の八点
立派なmemory platformがなくても、今日から始められる。
別model、別harness、別の人へ仕事を渡す時、最低限これだけを残す。
Mission──誰へ、どんな価値を届ける仕事か。
Success conditions──何が揃えば完了か。test、review、公開条件も書く。
Current state──終わったこと、未完了、blockerを分ける。
Decision ledger──何を採用し、なぜそうしたか。却下案は再発防止に必要な分だけ。
Authority map──仕様、一次情報、正本、ownerはどこか。
Artifact pointers──repository、branch、worktree、commit、file、URL。
Verification receipts──実行したcommand、result、timestamp、hash、canonical URL。
Risk and next action──秘密情報を除き、次の一手と人間の承認が要る境界を書く。
これを、会話の最後に長い感想として書くだけでは弱い。
次のAgentが見つけられる場所へ置く。できればversion管理する。事実が変われば更新し、古い判断には日付を付ける。最初の一手は、handoffを信じ切ることではなく、receiptから外部状態を確かめることにする。
内部でどの情報をどの正本へ昇格し、どのAgentへどこまで見せるか。その細かなrecipeは、組織ごとの競争力になる。
けれど、一般原則は難しくない。
Agentの頭に仕事を預けきらない。Agentが読み戻せる場所へ、仕事を置く。
一番好きなAIを、一生使う必要はない
AIとの協働には、相性がある。
相談しやすいmodel。大胆に前へ進めるmodel。細かな検証が得意なmodel。長時間の作業を任せやすいmodel。
気持ちよく仕事ができる相手を、大切に使えばいい。
ただし、そのmodelが値上げした時。挙動が変わった時。障害が起きた時。もっと適したmodelが現れた時。会社の仕事まで人質に取られてはいけない。
良いmodelには、惜しみなく働いてもらう。
そして、そこで得た判断、成果、失敗、検証は、組織へ戻す。
次のAIは、前のAIと同じではない。
同じでなくていい。
仕事の地図と現在地さえ残っていれば、別の知性と、同じ目的地へ向かえる。
今日からできるaction plan
いま一番長く続いているAgent taskを一つ選び、会話を見ずに「目的・現在地・次の一手」を説明できるか確認する。
上のPortable Context Minimum Kitを、repositoryまたは管理された正本へ一枚だけ作る。
secret、顧客情報、個人情報を除き、別のmodel/harnessへ渡す。
最初にtest、diff、URLなどの外部状態を再確認させる。
再説明が必要だった箇所だけをkitへ足す。会話全文を貼って解決しない。
参照した主な一次情報
Spotify Portal — What we've learned scaling AI coding agents at Spotify, 2026-08-10
Spotify Engineering — Coding Is No Longer the Constraint, 2026-06-03
Anthropic — Effective context engineering for AI agents, 2025-09-29
注記：Xirpの対応harness、並行session、working state継承、社内採用数、Portal連携の効果はSpotifyの2026年8月10日時点の公式説明に基づくvendor claimである。公開情報からは、harness間で移行するcontextの完全なschema、欠落率、独立benchmark、別orchestratorへのexport可能性までは確認できない。Claude Code、Codex、Gemini CLIの仕様は2026年8月20日時点で確認し、各製品内のresume/model切替と、製品を跨ぐportabilityを区別して記述した。
