Agent Deck: 複数のAIコーディングセッションを一つのTUIで管理

一画面に集める対象

Agent DeckはAIコーディングエージェント用の端末セッションマネージャーです。READMEではClaude、Gemini、OpenCode、Codexなどを一つのTUIに集め、実行中、待機中、完了済みの状態を切り替える用途を掲げています。グループ化、検索、fork、Git worktree、コスト追跡が同じ入口に並びます。

これはエージェント本体やモデルを置き換える製品ではありません。複数のプロセスと作業場所を見渡す操作層です。対応ツールの細かな起動引数、認証状態、端末互換性は環境に依存し得るため、READMEの対応表だけで挙動を断定しない読み方が必要です。

採用前の記録ではasheshgoplani-agent-deck-deep-analysisのリリース、実行環境、入力、出力を固定します。画面やREADMEの印象ではなく、コマンドの終了コード、生成されたファイル、ネットワーク接続、エラー時の復帰を確認します。正常系だけでなく、設定値を欠かせた場合、権限を持たない場合、途中でプロセスを止めた場合も試します。観察結果は人が読めるメモと機械的なログの両方に残し、次の更新で同じ手順を再実行できる形にします。

導入を決める前に、asheshgoplani-agent-deck-deep-analysisが触れる範囲を一覧化します。読み取りだけか、ファイル変更や外部接続も行うかを分け、許可した範囲を越えた記録がないかを確認します。依存するランタイムと補助サービスの版を保存し、更新前後で差分を比較します。失敗したときに残るログの場所、利用者が元の状態へ戻す方法、削除や無効化の手順が説明できなければ、本番の対象には広げません。

この確認では、asheshgoplani-agent-deck-deep-analysisにない機能を推測で補いません。READMEに記載された入口から小さな入力を与え、期待する応答と実際の応答を比べます。未記載の挙動は未確認として残し、数値や互換性を一般化しません。

導入経路と対象OS

公式の簡易導入は`curl -fsSL https://raw.githubusercontent.com/asheshgoplani/agent-deck/main/install.sh | bash`で、その後`agent-deck`を起動します。Homebrewのtap、`go install github.com/asheshgoplani/agent-deck/cmd/agent-deck@latest`、clone後の`make install`も記載されています。macOS、Linux、WindowsのWSLが対象です。

リリースはv1.15.0が最新の素材情報です。mainから取得するインストーラーは更新時に内容が変わるため、組織の導入ではスクリプトを保存して差分を確認します。アンインストールには通常の対話モードと、バイナリだけを消してセッションを残す`--keep-data`があります。

セッションをコマンドで組み立てる

最初は`agent-deck add . -c claude`で現在のディレクトリをClaudeのセッションとして登録します。`agent-deck session fork my-proj`は対応セッションを複製し、`session send`の`--message-file`は複数行の依頼を渡します。停止またはエラーの登録を片付ける`session remove`でも、READMEはトランスクリプトを保持すると説明しています。

MCPは`agent-deck mcp attach my-proj exa`、スキルは`agent-deck skill attach my-proj docs --source pool --restart`という形でセッション単位に接続します。管理対象、再起動の有無、作業ブランチをコマンド履歴に残すと、画面上の状態とGitの状態を取り違えにくくなります。

worktreeとConductorの役割

Agent Deckの価値は、同じ端末で多数の作業を眺めることだけではありません。READMEはGit worktree、グループ、検索、forkを作業の分離手段として挙げています。worktreeを使う場合でも、依頼するエージェントが別ブランチを本当に見ているか、生成物の書き込み先がどこかを確認する必要があります。

Conductorは端末の外からセッションを制御する経路として紹介されています。スマートフォンからの操作を含む機能範囲、認証や公開方法の細部はREADMEの該当ドキュメントに委ねられています。外部公開を前提にせず、まずローカルTUIで停止、再開、ログ確認を試すのが現実的です。

新規セッションのキー変更

v1.9.55以降、新規セッションダイアログのNameとBranch欄でEnterを押すと送信ではなく次の欄へ進みます。作成にはCtrl+Sを使い、最後に選んだツールはダイアログが記憶します。以前の挙動が必要なら`[ui].new_session_enter_advances = false`を設定します。

この変更は単なるショートカットの差ではなく、既存の手順書や自動操作に影響します。バージョン固定後、空の検証リポジトリで名前、ブランチ、既定ツールを入力し、Ctrl+Sで作成されたセッションの作業ディレクトリを確認します。入力を省略した場合の既定値は、実機で記録するまで断定しません。

向く運用と検証の順序

十数個のリポジトリでエージェントを走らせ、待機中の依頼を検索し、作業を分けて再利用したい人には適しています。一方、1つのプロジェクトを手動で編集するだけなら、TUIの登録情報と別プロセスを管理する負担が先に立ちます。MITライセンスは再利用条件を示しますが、各エージェントの権限を広げるものではありません。

導入時はv1.15.0を指定し、`agent-deck add . -c claude`、`session fork`、`session remove`を順に検証します。次に`agent-deck web`が`http://127.0.0.1:8420`だけで待ち受けること、MCP接続の設定、worktreeのブランチを確認します。セッションを削除した後にtranscriptが残るかも、再現可能な観察項目です。

複数セッションを試すときは、各セッションのリポジトリ、ブランチ、起動したエージェント、待機状態を表にして保存します。fork後に同じtranscriptを参照していないか、worktreeの絶対パスが重ならないかを確認します。Web UIを使う場合は127.0.0.1以外へ公開せず、停止したセッションをremoveした後に履歴が読めることを確認します。

編集部の結論

Agent Deckは複数リポジトリでエージェントを並行稼働させる開発者向けです。単一セッションだけなら管理層を増やす意味は薄く、まずv1.15.0を隔離環境に入れ、セッション作成、fork、worktree、停止後の削除とWeb UIの接続先を確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes