Spotify Xirp：コーディングエージェントの司令塔

1つのリポジトリで1つのコーディングセッションだけを開いているなら、新しい司令塔は必要ありません。ターミナル、1つのエージェント、整理されたGitブランチで十分です。

Codexが機能を実装し、Claude Codeがバグを調査し、Geminiが別案を並行して検証し始めると、状況は急に分かりにくくなります。どのエージェントが承認を待っているのか。変更はどのブランチにあるのか。どのセッションがどのプロジェクトに属するのか。そして、2つのエージェントが同じcheckoutを同時に変更するのをどう防ぐのか。

Xirpが解決しようとしているのは、まさにこの問題です。Spotifyが提供していますが、音楽、プレイリスト、Spotifyアプリとは関係ありません。XirpはAIコーディングエージェントを扱うmacOSアプリで、プロジェクト、永続ターミナル、Git worktree、ファイル、ルール、skillを1つの画面にまとめます。

一見すると新しいAI IDEですが、それだけでは正確ではありません。Xirpは独自の言語モデルを持たず、Codex、Claude Code、Geminiを置き換えません。Macにすでにインストール、設定されているエージェントを整理するアプリです。

Xirpとは何か

SpotifyはXirpをagentic development environmentと呼んでいます。より平易に言えば、複数のローカルなコーディングエージェントセッションを管理するグラフィカルな操作画面です。

セッションとは、エージェントが動作する永続ターミナルです。ローカルプロジェクトと専用Git worktreeに結び付けることも、プロジェクトなしで起動することもできます。作成時にCodex、Claude Code、Geminiから選び、目標を記述し、既存checkoutと新しいworktreeのどちらで作業するかを決めます。

Xirpは各ベンダーのネイティブCLIを引き続き利用します。認証情報、モデル、サブスクリプション、権限、固有設定は各エージェント側に残ります。Xirpをインストールしても、Claude、Codex、Geminiへのアクセス権や追加のモデル枠が得られるわけではありません。

Xirpは現在ベータ版で、macOSのみをサポートします。オープンソースではなく、Spotifyのプロプライエタリソフトウェアです。登録には業務用メールアドレスが必要で、FAQによるとGmail、Yahoo、Outlook.comなどの個人用アドレスは受け付けられません。

Xirpで実際にできること

実用性は派手な1つのボタンから生まれるのではなく、現在は分散している複数の作業を1か所にまとめることから生まれます。

プロジェクトと永続セッション

プロジェクトはまずMac上のローカルフォルダです。1つのGitリポジトリ、Gitを使わないフォルダ、複数リポジトリを含む親フォルダを登録できます。Xirpはそれをセッションの作業ディレクトリとして使います。

ターミナルの状態は保持されます。アプリを閉じても、後で開いてセッションを続行できます。プロジェクト概要には現在と過去のセッション、関連ブランチ、worktreeが表示されます。エージェントが作業中か、入力待ちか、終了したかを示すステータスがあり、注意が必要なときは通知を受け取れます。

派手ではありませんが、日常では有用です。3つ、5つとタスクが並行すると、問題はエージェントがコードを書けるかではなく、どのエージェントが何をしていて、結果がどこにあるかへ変わります。

同じcheckoutではなくGit worktreeを使う

Xirpは新しいセッション用に、独立したブランチと作業ディレクトリを持つGit worktreeを作成できます。複数のエージェントが、同じcheckout内の同じファイルを同時に書き換えずに1つのリポジトリで作業できます。

Worktreeは衝突を魔法のように消しません。2つのブランチが同じ関数を別々に変更すれば、後で理解して解決する必要があります。Worktree外への意図しない変更も自動的には防げません。分離は作業を整理しますが、code review、テスト、ブランチ保護の代わりにはなりません。

片付けるとき、Xirpはセッション、worktree、ブランチを別々に扱います。ターミナルを閉じただけで、未コミットの変更を含むcheckoutまで削除されてはならないため、妥当な設計です。

ターミナル、ファイル、Git、複数エージェントを1画面に表示

セッション画面は対話型ターミナルです。ネイティブCLIと同様に応答、権限承認、エージェントコマンドの実行ができます。さらに、ファイル検索と編集、diff、ブランチ、commitの確認、正しいworktreeでの外部エディタやターミナルの起動も可能です。

Grid viewは複数の稼働中ターミナルを並べます。2つのセッションが作業し、3つ目が判断を待つような場面で特に便利です。元の流れを残したまま、会話をforkして別の方法を試すこともできます。

ドキュメントによれば、セッション中に別のインストール済みエージェントへ切り替えられます。作業ディレクトリとプロジェクト状態は維持されます。ただし、Xirpはエージェント固有の設定を変換しません。Claude CodeからCodexへ切り替えても、すべての設定が同じように機能するとは限りません。

ルールと再利用可能なskill

XirpはAGENTS.mdやCLAUDE.mdなど、対応するグローバルおよびプロジェクト指示ファイルを表示します。また、対応フォルダから再利用可能なskillを検出します。Skillにはリリース確認、移行、固定の検証手順などを記述できます。

これは見た目以上に重要です。ローカルルールを知らないエージェントは、構文上は正しくてもリポジトリの規約に反するコードを書くことがあります。Xirpはルールの質そのものを改善しませんが、プロジェクトに関連する指示と反復手順を見つけやすくします。

現実的なワークフロー

Webアプリに大きな更新が必要だとします。依存関係の更新、既存バグの調査、ドキュメントの修正が必要です。Xirpでは3つのセッションに分けられます。

• Codexが専用worktreeで依存関係を更新し、テストを実行する。
• Claude Codeが2つ目のブランチでバグを分析する。
• Geminiが関連ドキュメントを確認するか、代替案を検討する。

3つのターミナルはGrid viewに表示され続けます。Git画面は各ブランチが変更したファイルを示します。エージェントが承認を待っていても、複数のターミナルを探し回る必要はありません。その後、結果を個別にレビュー、テスト、統合できます。

Xirpが役立つのはこの場面です。最初のエージェントよりも、3番目、5番目、10番目の並行作業を管理します。Spotifyは紹介記事で50以上の並行セッションと、社内で実行された36,000以上のセッションに言及しています。これはSpotify環境におけるベンダーの数字であり、独立した生産性調査ではありません。

並列数を増やしても自動的に生産性が上がるわけではありません。エージェントごとに成果、質問、競合、コストが増えます。10セッションを開始すれば、10の作業状態を理解し責任を負う必要があります。Xirpは負荷を可視化しますが、なくしません。

Spotify Portalが追加するもの

XirpはSpotify Portalなしでも機能します。永続ターミナル、ローカルプロジェクト、worktree、Grid view、ファイル、Git、skill、ルールは単体アプリの機能です。

Portalは組織レイヤーを加えます。サービス、依存関係、所有者、その他のメタデータを含むソフトウェアカタログを保持します。WorkspaceにはWiki、技術判断、リンク、タスク、メンバー、過去のセッションを集約できます。Xirpはカタログ項目やWorkspaceからセッションを開始し、MCP経由で関連コンテキストを提供できます。

これは大規模組織の既知の問題に対応します。エージェントはリポジトリを見られても、上流サービスの所有者、設計判断の理由、別チームが記録済みの制約を自動的には知りません。

Portalはすべての文書を最初のpromptに詰め込まず、必要なときにコンテキストを提供できます。セッション後、履歴を手動でWorkspaceへアップロードし、チームメンバーや将来のエージェントが再利用できます。

これはXirpで最も戦略的に興味深い部分ですが、整備されたメタデータ、権限、文書に最も依存する部分でもあります。古いカタログは信頼できる組織知を生みません。エージェントに古い情報を自信満々に与えるだけです。

小規模チームにはPortalが過剰な場合があります。一方、多数のリポジトリ、変化する責任、繰り返される重複作業を抱える組織には、共有コンテキストレイヤーが実際の価値を持ちます。

セキュリティ：ローカルはオフラインを意味しない

Spotifyは、ローカルプロジェクトの登録でファイルがPortalへアップロードされないと明記しています。XirpはMac上のフォルダを使い、セッションのアップロードは手動で開始します。

ただし、コーディング全体がオフラインになるわけではありません。選択したエージェントは自身の設定に従い、OpenAI、Anthropic、Googleなどのモデル提供者と通信します。送信されるprompt、コード片、ツール結果はネイティブ設定次第です。Xirpのローカル管理はこのデータフローを変えません。

セッションアップロードにはチャット以外も含まれる

Spotifyによれば、アップロードには会話全体、ツール呼び出し、ファイル変更、エージェントのreasoning、ファイルパスが含まれます。コード片や、セッション中に処理したあらゆる情報が入る可能性があります。

特に重要なのは、Xirpがアップロード前にsecret、認証情報、個人情報、機密情報を削除しないことです。利用者が履歴を確認し、問題のあるセッションを送らないようにする必要があります。

本番利用では少なくとも次のルールを設定します。

• 個々のタスクに必要な権限だけをエージェントへ与える。
• 自律モードやpermission bypassは明確に制限された環境でのみ使う。
• リスクの高い作業には独立した破棄可能なworktreeを使う。
• Portalへ送る前にtranscript内のsecretと顧客データを確認する。
• Xirpと別に、ブランチ保護、テスト、code review、secret scanningを維持する。

Worktreeは同じcheckoutでの意図しない重複を防ぎますが、shellコマンド、ネットワークアクセス、Macの権限に対するセキュリティ境界ではありません。それらは各エージェントのsandboxと承認制御に依存します。

ローカルデータとテレメトリ

Xirpは標準でローカル状態を~/.xirpに保存します。Spotifyは任意の利用テレメトリを仮名化されたものと説明し、prompt、コード、ファイルパス、自由記述を含まないとしています。設定またはXIRP_TELEMETRY=0で無効にできます。

これは前向きな説明ですが、Xirpはプロプライエタリソフトウェアです。オープンソースと違い、実装全体を公開コードで検証できません。組織は画面だけでなく、契約条件、データフロー、保存、接続したエージェントの権限も評価すべきです。

Xirpが向いている利用者

Xirpは、時々コーディングエージェントを開くだけの全員に必要なアプリではありません。価値は調整すべきセッション、リポジトリ、人の数に大きく左右されます。

判断基準は簡単です。ターミナルのタブ、ブランチ名、通常のタスクリストで足りるなら、Xirpは追加レイヤーです。複数エージェントが別々のworktreeで動き、全体像を失い始めたなら、実在する問題に対応しています。

導入と現在の制限

SpotifyはApple siliconおよびIntel Mac向けのダウンロードと、ターミナル用インストールスクリプトを提供しています。curl | sh形式のインストーラーは、実行前に内容を確認するか、アプリを直接ダウンロードすべきです。

導入後の主な手順は次のとおりです。

1. 業務用メールでSpotify Technologyアカウントを作成する。
2. 必要なエージェントCLIを別々にインストール、認証し、権限を設定する。
3. Xirpにローカルプロジェクトを登録する。
4. 最初の実作業ではメインcheckoutでなく新しいworktreeを使う。
5. 目標と完了条件を明確に記述する。
6. 統合またはPortalアップロード前に変更とtranscriptを確認する。

ベータ版には明確な制限があります。WindowsとLinuxは未対応で、サーバーモードやSSH経由のリモートセッションもありません。transcriptの自動アップロードは未対応で、対象Workspaceセッションは手動共有です。画面と挙動は短期間で変わる可能性があります。

製品ページは現在ベータアクセスと無料Portalトライアルを案内しています。これは恒久的な無料提供や将来のチーム価格を約束するものではありません。モデルのサブスクリプションに加え、Portalライセンス、管理、レビュー、保存セッションの扱いも計算に入れる必要があります。

この記事の根拠と限界

この記事ではXirpを本番のマルチエージェント環境で実際にテストしていません。機能とセキュリティ情報は公式文書、FAQ、製品ページ、Spotifyの紹介記事に基づき、2026年8月25日に確認しました。

したがって、安定性、リソース消費、速度、実際の時間短縮について確かな評価はできません。ベータ中は画面、対応エージェント、Portal機能が急速に変化する可能性があります。

結論

Xirpは、コーディングエージェントを1つずつではなく並行作業者として使い始めたときに現れる問題へ対応します。永続ターミナル、Git worktree、状態表示、diff、Grid viewは個別には革命的ではありません。しかし、エージェント向け画面にまとめることで日常作業を大きく整理できます。

より大きな狙いはSpotify Portalとの接続です。サービス、所有者、設計判断、過去のセッションが本当に保守され、必要なときに利用できれば、エージェントは毎回ゼロから始めずに済みます。単なるモデル選択機能より興味深い点です。

リスクもこの接続にあります。完全なtranscriptはcommitよりはるかに多くを漏らす可能性があります。Worktreeは危険なshellコマンドを防ぎません。ローカルプロジェクトだけでは、エージェントがモデル提供者へ送るデータも分かりません。

私自身、すでにこの負荷を強く感じています。Codexでは複数のプロジェクトが動き、隣にはターミナルが開き、Hermes Agentも作業し、受信箱には質問と承認依頼が増えています。すべてが並行し、最後には注意を求めてきます。同時に文脈、優先順位、結果を頭に置く必要があり、ときには精神的な燃え尽きのように感じます。

仕事は速くなっただけでなく、より多くの並行ストリームから届くようになりました。少し前までボトルネックは1つのタスクを速く終えることでした。今は5つの実行中タスクを再び1本の流れに戻すことです。プロジェクト、セッション、質問、承認、結果に分かりやすい作業フローがなければ、得た速度自体が負担になります。

多くのベンダーとオープンソースプロジェクトが、この新しい調整問題に取り組んでいます。Xirpは1つの方法で、Buzzは別の方法です。Buzzは人、複数プロジェクト、複数エージェントを1つの空間にまとめようとします。最近、Buzzの考え方と共有ワークスペースについて詳しく書きました。

1セッションだけを使う個人開発者には、ネイティブCLIがより直接的でしょう。Mac上で複数のエージェント、ブランチ、プロジェクトを並行して管理する人はXirpに注目すべきです。Spotifyがより優れたエージェントを作ったからではなく、既存エージェントの調整自体が独立したツール問題になっているからです。

それでは、また。
Joe

FAQ