エージェント — 種別ごとにできること
セッションの種別は 11 個で、うち 9 個はコーディングエージェントを動かす(または動かす
想定の)種別です。lcpp と muse は managed 専用で Terminal(CLI)経路を一切持ちません(該当行の
脚注を参照)。shell と ssm はエージェントのいない端末です。「素の shell セッションでも
これは効くの?」は実際に問われるので、表に入れています。
✓ = 対応、— = 非対応 / 該当なし。
| 機能 | claude | codex | opencode | copilot | cursor | kiro | agy | lcpp | muse | shell | ssm |
|---|---|---|---|---|---|---|---|---|---|---|---|
| マネージド実行(端末なし) | — | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | ✓ | — | — |
| ターミナル(CLI)実行 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | —⁹ | —⁹ | ✓ | ✓ |
| 実行中のチャットミラー | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | — |
| 停止中の履歴表示(読み取り専用) | ✓ | ✓ | ✓ | ✓ | —³ | ✓ | ✓ | ✓ | ✓¹² | — | — |
| 起動時のモデル選択 | ✓ | ✓ | ✓ | ✓¹ | ✓²² | ✓²² | ✓ | ✓¹⁹ | ✓¹⁴ | — | — |
| reasoning effort 指定 | ✓ | ✓ | ✓ | ✓ | —² | —⁵ | —² | — | ✓ | — | — |
| Plan モード | ✓ | ✓ | ✓ | ✓²¹ | ✓ | — | — | ✓ | — | — | — |
| コンテキスト使用量ゲージ | ✓ | ✓ | ✓ | — | — | ✓ | — | ✓ | ✓ | — | — |
| 画像貼り付け | ✓ | ✓ | ✓⁶ | — | — | — | ✓ | — | ✓ | — | — |
| 会話を新しいセッションへ複製 | ✓ | ✓ | ✓ | ✓ | — | — | — | ✓ | ✓ | — | — |
| 過去の発言からの分岐 | ✓ | ✓²⁰ | ✓²⁰ | ✓ | — | — | — | ✓ | ✓ | — | — |
| 権限確認のスキップを選べる | ✓ | — | — | ✓ | ✓ | ✓ | ✓ | ✓ | —¹³ | — | — |
| スキル / コマンドのピッカー | ✓ | ✓ | ✓ | —⁴ | ✓ | —⁴ | —⁴ | —⁴ | ✓⁴ | — | — |
| 別セッションへの引き継ぎ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | — |
| git worktree で起動 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — |
| 定時実行(無人実行) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | — | — |
| チャットブリッジ(Discord / Slack) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | ✓ | — | — |
| アシスタントチャットとして利用 | ✓ | ✓ | ✓ | — | ✓⁷ | — | ✓ | — | ✓¹¹ | — | — |
| 使用量 / 残量チップ | ✓ | ✓ | — | ✓ | — | — | ✓ | — | ✓¹⁵ | — | — |
| エージェントへの指示が届く | ✓ | ✓ | ✓ | ✓ | —⁸ | ✓ | ✓ | ✓¹⁰ | ✓¹⁶ | — | — |
| 連携(MCP)サーバーが届く | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓¹⁸ | ✓¹⁷ | — | — |
| Agent Fleet のメモリを共有する(af のメモリツール) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | — | — |
| エージェント自身のメモリを版管理できる | ✓ | ✓ | — | — | — | — | — | — | — | — | — |
| RTK(トークン節約) | ✓²³ | ✓²³ | ✓²³ | ✓²³ | — | — | ✓²³ | — | — | — | — |
| 子セッションを起こす・ほかのセッションへメッセージを送る | ✓²⁴ | ✓²⁴ | ✓²⁴ | ✓²⁴ | ✓²⁴ | ✓²⁴ | ✓²⁴ | ✓²⁴ | ✓²⁴ | — | — |
| 画像スタジオに付けられる | ✓²⁵ | ✓²⁵ | ✓²⁵ | ✓²⁵ | ✓²⁵ | ✓²⁵ | ✓²⁵ | ✓²⁵ | — | — | — |
¹ copilot のモデル一覧はプラン依存。Free は「Auto(Copilot が選ぶ)」のみ。
² cursor と agy は reasoning effort をモデル名に畳み込んでいるので、別の指定が無い。
³ cursor のマネージド実行はローカルに転写を残さないため、停止中の cursor セッションには表示するものがありません。実行中のミラーは動き(ツールの出力は簡略表示)、ターミナル(CLI)で 動かせば読める履歴が残ります。kiro は逆に、マネージドでも読める転写を残します。
⁴ ピッカーが並べるのは「CLI 自身が発見して起動できるもの」で、copilot / kiro / agy /
lcpp にはその機構が確認できていません(lcpp はそもそも CLI を駆動しないので、自前で
発見するものがありません)。リポジトリ内の別規約の SKILL.md ツリーに書かれたスキルは、
注入方式でこれらにも渡ります。
この行で muse だけは別の仕組みです。muse は自分のプロトコルに一覧を持っているので、
ピッカーが出すのは走っているセッション自身の答えで、Muse Code 同梱のスキル、
プラグインのスキル、~/.config/muse/skills に置いたあなた自身のもの、そして作業コピーの
.agents/skills/ が並びます。選ぶと名前の文字列ではなくスキルの呼び出しとして送られ、それが実行の
条件です。一覧はセッションに属するので走っているセッションが要り、それ以前と停止中は
これまでどおり注入方式が残ります。
⁵ kiro は effort のフラグを受け付けますが、モデル毎のピッカーは出していません。
⁶ opencode の画像貼り付けは、プロバイダのキーの先にあるモデル次第。
⁷ cursor のアシスタントは読み取り専用で動きます。
⁸ Cursor は User Rules を Cursor アカウント側に持ち、ローカルにユーザー単位の 置き場がありません。指示を受け取れない唯一の種別です(設定の一覧には理由付きで 出ます)。
⁹ lcpp(ADR 0093 の自前 llama.cpp ハーネス)と muse(Meta の Muse Code)は、設計として Terminal(CLI)経路を一切持ちません。lcpp はパネルに置くベンダー CLI が無く、この プロセス自身が in-process で持つ managed runtime しかありません。muse には CLI が ありますが、そのセッションプロトコルがパネルに映る以上のものを既に運ぶので、Agent Fleet は そちらを駆動します。どちらの kind も、driver を指定せずにセッションを作ると、(失敗する Terminal の起動を試みるのではなく)既定で Managed になります。
¹⁰ lcpp は指示を書き込む先の CLI を持ちません。代わりにハーネス自身が fleet/利用者 本人/プロジェクトの各指示層を読み、毎ターン system prompt に折り込みます。⚙設定 → 「エージェントへの指示」の lcpp の行が本人の層のオン/オフで、実行中のセッションにも次の ターンから効きます。
ログインの仕方
Section titled “ログインの仕方”| 種別 | ログイン |
|---|---|
| claude | OAuth。ブラウザで承認し、表示されたコードを貼り戻す。接続後はアカウントのメールとプランが出る。 |
| codex | ChatGPT サブスク(device code。事前に ChatGPT の「セキュリティ」で device-code 認証を有効にする)か、OpenAI の API キー。 |
| opencode | 2 段構え。「opencode を使う」(オフのあいだは鍵もログインも無視・既定オフ)と、「opencode.ai への課金」(使わない(自分の鍵だけ)/ 無料モデルのみ / Go(定額)/ Zen(従量))。後者は opencode.ai の使い方だけを決め、自分でつないだプロバイダのモデルはどれを選んでも残る。キーは使いたい LLM プロバイダの API キーを env として保存(プリセットで env 名が入る・複数登録可)。 |
| copilot | 専用のログインは無い。GitHub を git プロバイダとして接続すると接続済みになり、GitHub を切ると一緒に切れる。そのアカウントに Copilot サブスク(Free 含む)が要る。 |
| cursor | 承認リンクをブラウザで開いて承認するだけ(貼り戻すコードは無い)。Cursor アカウントが必要で、API キーでは接続できない。 |
| kiro | device flow。確認コード付きのリンクを開いて承認(Builder ID / Google / GitHub 等)。API キーでは接続できない。CLI が大きいので、焼き込んでいない配備では初回にオンデマンド導入される。 |
| agy | エージェント設定のカードからログインする。 |
| lcpp | 不要。配備のエンジンにログインは要らない。カードには 「llama.cpp を使う」(電源。オフにすると起動導線から消え、どの経路の起動も拒まれる)と 「自分の接続先」(URL・任意の API キー・「接続を確認」)があり、後者は配備のエンジンの代わりに自分のネットワークの llama-server へセッションを向ける。 |
| muse | 一度だけ 「Muse Code を導入」(約 299 MB をホームへ)、その後 「Meta アカウントでログイン」(ブラウザで承認。貼り戻すコードは無い。サブスク契約の経路)か 「API キーを使う」(従量課金。キーを保存すると保存済みのアカウントのログインは消える)。 |
| shell | 該当なし。 |
| ssm | ワークスペースの AWS SSM 接続を使う。 |
ミラーに出る状態
Section titled “ミラーに出る状態”| 種別 | 状態 |
|---|---|
| claude | 進行中… / 質問あり / プランあり / 許可待ち / 入力待ち |
| codex | 進行中… / 質問あり / プランあり / 入力待ち |
| opencode | 進行中… / 質問あり / 入力待ち |
| copilot | 進行中… / 許可待ち / 入力待ち |
| cursor | 進行中… / 許可待ち / プランあり / 入力待ち |
| kiro | 進行中… / 質問あり / 入力待ち |
| agy | 進行中… / 質問あり / 許可待ち / 入力待ち |
| lcpp | 進行中… / 入力待ち |
| muse | 進行中… / 質問あり / 入力待ち |
ターミナル(CLI)のセッションの cursor がコマンドの承認で止まるのは、権限確認で許可を 求める設定にしたときか plan モードで起動したときだけで、ビルドの判断で止まるのは plan 起動の ときだけです。ミラーは状態を出しますがカードは描かないので、ターミナルで答えてください。 待っている間はどこから送ったテキストも断られます。これは、メニューが Enter を「実行」「ビルド」として 受け取ってしまうためです。
kiro は、待っているツールの承認を許可待ちではなく 質問あり として出します。 lcpp のツールの承認と質問はミラーにカードとして出ますが、その間も状態は進行中…のままです。 muse はツールの承認を求めないので(脚注 13)、許可待ちにはなりません。
利用上限でターンが止まると、claude・マネージドの codex・muse は時刻付きの 制限解除待ち に なり、上限が解けると自分で再開します。claude と codex は、上限が予告より早く解けると再開を前倒しし、 その間に自分でターンを終えると予約を取り消します。セッションを停止しても取り消されません。ターンが終わったあとも、そのターンが始めた作業がまだ 動いていると、claude・マネージドの codex・agy・muse は 入力待ち · BG 実行中 と出ます。
shell と ssm は会話が無いので状態モデルも通知もありません。
会話を持つ種別の停止中セッションは、どれも再開できます。ただし claude・codex・opencode・copilot・cursor・kiro・ agy・lcpp・muse は、起動時の作業フォルダが消えていると再開できません(shell はホームに戻って再開します)。 セッションを止める・再開するを参照してください。
ターンの停止と、実行中に送ったメッセージ
Section titled “ターンの停止と、実行中に送ったメッセージ”キューが残っているときに「停止」がどう働くかは 送る内容を待たせる・ターンを止めるにあります。 ここには、種別ごとの違いを書きます。
マネージド
- ターンの実行中に送ったメッセージ。 codex と muse ではキューに入れず、エージェントが実行中のターンにすぐ 取り込むので、ふつうは止める必要がありません。それでも止めた場合、メッセージはそのターンと一緒に終わり、 次のターンは会話の中でそれを見ます。送信待ちの今すぐ送るも同じです。それ以外の種別は、メッセージを受け付けて 実行中のターンの後に処理します。
- 受け渡しの途中で停止が届いたとき。 codex と muse では、エージェントがそのメッセージを始めた時点で確実に止めます (lcpp は Agent の中で動くので、同じように止まります)。copilot・cursor・kiro・opencode では best effort で、 止まる前に最初の一歩が進むことがあります。
- 質問の取り消しでターンが止まるのは codex だけです。ほかの種別は、質問に「断った」と答えるだけで、キューには触れません。
ターミナル(CLI)
「停止」は、その CLI がターンを止めるキー(Esc、opencode は Esc 2 回、cursor と copilot は Ctrl+C)を送ります。 cursor と copilot の Ctrl+C はターンが実行中のときだけ送り、そうでなければ「実行中ではない」と返します。 ターンの実行中に打ったプロンプトを各 CLI がどう扱ったかを、CLI ごとに 1 回ずつ測った結果が次の表です。 観察した結果であって約束ではなく、CLI の更新で変わることがあります。
| CLI | キューにある間に停止 | キューにある間にペインが閉じた |
|---|---|---|
| claude | ターンが止まり、キューのプロンプトが次に実行される | キューのプロンプトは失われる |
| codex | ターンが止まり、キューのプロンプトが次に実行される | それでも実行される(codex の裏のプロセスがペインより長く残る) |
| opencode | 「停止」は Esc を 0.5 秒ほど空けて 2 回送る(Esc 1 回では中断の準備だけ)。ターンが止まり、キューのプロンプトが次に実行される | それでも実行される(opencode の裏のサーバーがペインより長く残る) |
| cursor | 「停止」は Ctrl+C を送る。ターンが止まり、プロンプトは CLI の欄に送られないまま残る(Esc だけだとキューのプロンプトが取り消され、ターンは走り続ける) | CLI を再開しても戻らず、実行もされない |
| kiro | ターンが止まり、キューのプロンプトが次に実行される | CLI を再開しても戻らず、実行もされない |
| copilot | 「停止」は Ctrl+C を送る。ターンが止まり、キューのプロンプトは消える(Esc ではターンは止まらない) | CLI を再開しても戻らず、実行もされない |
| agy | 測っていない(「停止」は従来どおり Esc 1 回を送り、応答でキーが未測定だと伝える) | 測っていない |
別のセッションからターミナル(CLI)のセッションへのメッセージも同じ規則に従い、送り手には次のように返ります。
- claude のセッションがターンの途中でメッセージを受けると、送り手には「届いた」ではなく「キューに積まれた」と返ります。 claude はそれをメモリにしか持たないので、ターンが終わる前にペインが終了する(セッションの停止・アーカイブ・再作成)と失われます。
- CLI を起動して 3 分未満の claude のセッション(たとえば送信で再開したばかりのもの)へのメッセージは、
starting待ちの 「キューに積まれた」として返ります。起動中の claude に打ち込んだ文は失われることがあるので、メッセージは預かり、 ペインが入力待ちのまま約 45 秒落ち着いてから届けます。 - cursor のセッションの CLI が送信時にメッセージを拒んだ場合(たとえばプランで使えないモデル)も同じ形で返り、 CLI のエラー文が添えられます。メッセージは入力欄に残るだけで実行されないので、送り手には再送しないよう伝わります。
- cursor のセッションの入力欄に、送られていない文(CLI が前に拒んだプロンプトや書きかけ)が残っていると、 メッセージは断られます。そのまま送ると cursor が 2 つを 1 つのプロンプトとして実行するためです。送り手には、 先にペインでその文を送るか消してもらうよう伝わります。
別のエージェントへ移す
Section titled “別のエージェントへ移す”移動(別のセッションやエージェントに引き継ぐ)には移動元と 移動先の 2 つの立場があり、種別によっては片方にしかなれません。
| 種別 | 移動元として | 移動先として |
|---|---|---|
| claude | ✓ | ✓ |
| codex | ✓ | ✓ |
| opencode | ✓ | ✓ |
| copilot | ✓ | ✓ |
| cursor | ✓(停止中のマネージドを除く) | —(未検証) |
| kiro | ✓ | ✓ |
| agy | ✓ | ✓ |
| lcpp | ✓ | —(引き継ぎファイルを読めない) |
| muse | ✓ | ✓ |
| shell / ssm | — | — |
- 停止中のマネージドの cursor セッションは移せません。 会話は動いていたエージェントの中に しか無かったので、引き継ぎファイルを書く材料が残っていません。
- cursor は移動先に出ません。 マネージドのドライバー経由で引き継ぎファイルを読めることを 確認するまでは選べません。
- lcpp は移動先に出ません。 lcpp のファイル操作のツールは作業フォルダの外のパスを拒み、 引き継ぎファイルはその外にあるためです。
- 移動先は必ず別の種別です。同じ種別で続けたいときは、分岐できる種別ならセッションを分岐して ください。shell と ssm には引き継ぐ会話がありません。
エージェント自身のメモリ
Section titled “エージェント自身のメモリ”スイッチ 「セッションに Agent Fleet のメモリを使わせる」 (メモリの使いかたを設定する)が、各種類が自分で持つメモリに何をするかを下の表にまとめます。
| 種別 | スイッチがオンの間 | Agent Fleet のメモリへの取り込み | オフにしたときの書き戻し |
|---|---|---|---|
| claude | 新しいセッションとアシスタントのチャットは Claude Code の自動メモリをオフにして動く | ✓(バックグラウンドで取り込む) | ✓ |
| codex | codex の features.memories をオフにし、スイッチをオフにすると元の値に戻す |
— | — |
| muse | 新しいホストは Muse Code 自身のメモリをオフにして起動する | muse から取り込む で 1 回 | — |
| ほかの種類 | 何も変えない | — | — |
claude: 「API キー」経路
Section titled “claude: 「API キー」経路”claude のセッションは、経路を明示して開始できます(ターミナル(CLI)のみ)。anthropic-api は、 設定 > 接続 > エージェント > OpenCode カード > API キー(Anthropic プリセット)に保存した Anthropic API キーで従量課金として動きます。anthropic-subscription はこのワークスペースの claude.ai ログインで動きます。 経路を指定しないセッションは従来どおりです。
- CLI は環境の API キーについて、キーごとに一度「Detected a custom API key in your environment ·
use this API key?」と尋ねます。anthropic-api のセッションは CLI を起動する前にこれへ答えを書き込む
(CLI が Yes のときに自分で記録するのと同じく、キーの末尾 20 文字を
.claude.jsonに記録する)ので、 この問いで止まることも、claude.ai ログインへ黙って切り替わることもありません。 - claude.ai のログインは CLI から読めるままなので、バナーに「Both claude.ai and ANTHROPIC_API_KEY set」と 出て、そのセッションでは claude.ai のコネクタが無効になります。想定どおりで害はありません。 セッションが使う資格情報は API キーです(ヘッダーは「API Usage Billing」)。
- 実行中に設定ファイルを編集しても、セッションは経路から外れません。起動時に、経路を上書きしうる変数
(エンドポイント、認証トークン、クラウドプロバイダの切替、
apiKeyHelper、もう一方の経路の資格情報)を、 Agent Fleet が書き込める中で最優先の層(CLI の起動フラグ層)で空に固定します。次の 2 つは、固定できないのでセッションを止めて守ります: managed 設定ファイル(CLI の文書では起動フラグ層より上とされる。ここでは未測定)と、anthropic-api セッションでANTHROPIC_API_KEYを設定する設定ファイル (キー自体はコマンドラインに載せません)。 - Amazon Bedrock。 3 つ目の経路は、設定 > AWS プロファイル/SSM で「モデルのルート」の印を付けたプロファイルで
claude を Amazon Bedrock 上で動かします(Amazon Bedrock のルート)。まだ提供していません。
実機での受け入れ確認を待っており、それまでは運用者がその確認のために
AF_CLAUDE_BEDROCK_ROUTE=1を設定した ワークスペースでだけ選べます(Control Plane ではAF_WS_CLAUDE_BEDROCK_ROUTE=1で、次のワークスペース起動で届きます。動作中のワークスペースは Stop → Start が要ります)。選べる場合は、モデルのルート で Amazon Bedrock を選び、プロファイルを選びます。リージョンは任意で、空ならプロファイル自身のものです。Bedrock の モデル ID は必須で、Bedrock の表記どおりのモデル ID かシステム推論プロファイル ID(anthropic.…、us.anthropic.…など。opusやclaude-…、ARN は不可)を入れます。claude はその ID だけで起動する(--modelとANTHROPIC_*_MODELの変数)ので、 サブエージェントも同じ ID を使い、ほかのモデルへ切り替わることはありません。セッションには AWS の資格情報が渡りません。ワークスペースのルートゲートウェイが各モデル呼び出しに署名し、セッションが持つのは、自分の プロセスからだけ使え、セッションとともに終わる bearer だけです。CLI のヘッダーは「Amazon Bedrock」になります。拒否された 呼び出し(プロファイルの印がない・編集された・削除された、確認がまだ、SSO のサインインが必要)は、理由とともにすぐ失敗し (「AWS authentication failed」または「API Error: 503」の下に出ます)、再試行されません。AWS_BEARER_TOKEN_BEDROCK、CLAUDE_CODE_SKIP_BEDROCK_AUTH、awsAuthRefresh、awsCredentialExportを設定する設定ファイルがあると起動は拒否されます。 CLI のほかのプロバイダ切替・エンドポイント・資格情報を設定する設定ファイルでも同じく拒否されます。セッションは、 作成した時点のプロファイルに結び付きます。後からプロファイルのアカウント・ロール・サインイン・リージョンを編集すると、 そのセッションをもう一度開始することは拒否されます。新しいセッションを始めてください。使用量はモデル呼び出しごとに 1 回、 ゲートウェイが Amazon Bedrock・従量課金として記録します。 - キーのアカウントの残高が尽きると(「Credit balance is too low」)、ターンはその文面で失敗します。 セッションは「残高上限」状態にはなりません。アカウントに入金してメッセージを送れば届きます。 claude.ai 組織の利用額上限は従来どおりセッションを止めたままにします。
- 利用枠の上限で API 経路へ切り替えて続ける。 anthropic-subscription の claude セッションが利用枠の上限で 止まる(上限のリセット待ち)と、リセットを待たずに続けるための API ルートで続ける バンドが出ます。 出るのは、anthropic-subscription 経路で開始したセッション(経路を指定していないセッションには出ません)が 利用枠(ウィンドウ)の上限で止まったときだけです。利用額の上限(残高上限)は、待っても API 経路でも解消しないので 出ません。保存済みの anthropic-api キーで起動できることも条件です。確認の画面に費用の注意が出ます。API 経路は トークン単位の従量課金で、プロンプトキャッシュが引き継がれないことがあるため、最初の返信は遅く、高くなることがあります。 代わりの方法として claude.ai の利用クレジット設定へのリンクも出ます。この設定はそのログインのすべてのセッションに 影響し、Agent Fleet が変更することはありません。確定すると、Agent Fleet は予約済みの自動再開を取り消し、 元のプロセスを止め、新しい経路を保存してセッションを起動し直したうえで、「続けて」のメッセージを、あなたが入力したのと 同じ形で 1 件送ります。以降のターンは anthropic-api(従量課金)として記録され、それ以前のターンは元の経路のままです。 途中で失敗すると、Agent Fleet は切り替えを元に戻します(サブスクリプション経路へ戻し、再開を取り直します)が、 バンドは元に戻ったとは言い切りません。切り替えが完了しなかったことと Agent の詳細を示し、元に戻す処理が片付くまで、 セッションは入力を受け付けません。切り替えへの応答が届かなかったとき(タイムアウトや接続切れ)は、結果は不明と伝えます。 再読み込みして、セッションがどの経路かを確認してください。「続けて」のメッセージはセッションへ渡しますが、入力された ことは確認できないので、そのことをバンドが伝えます。渡した結果の応答が失われたときは、すでに待ち行列にあるかも しれないので、もう一度送る前に確認するよう伝え、先にワークスペースを切り替えたときは送りません。予約済みの再開をすぐに取り消せなかったときもバンドが伝えます。 取り消しは再試行され、先に実行された再開は無視されます。利用クレジットの設定は続けるもう 1 つの方法ですが、 枠を超えたぶんはやはり API 料金で課金されます。切り替えは一方向で、元の経路へ戻す操作はありません(新しいセッションを始めるか、移してください)。
opencode: Amazon Bedrock ルート
Section titled “opencode: Amazon Bedrock ルート”opencode も、設定 > AWS プロファイル/SSM で「モデルのルート」の印を付けたプロファイルを使って Amazon Bedrock で動かせます
(上の claude の bedrock ルートと同じ仕組みです)。まだ選べません。独自の実機での受け入れ確認を待っており、それまでは運用者が
その確認のために AF_OPENCODE_BEDROCK_ROUTE=1 を設定したワークスペースでだけ選べます(Control Plane では
AF_WS_OPENCODE_BEDROCK_ROUTE=1 で、次のワークスペース起動で届きます。動作中のワークスペースは Stop → Start が要ります)。
claude 用のスイッチでは開きません。
- ターミナル(CLI)専用です。 マネージドの opencode セッションは、ほかのマネージドセッションと 1 つの opencode サーバを 共有していて、セッションごとのルートを持てません。そのためマネージドでの起動にはこのルートが出ず、マネージドへの切り替えも 拒否されます。
- 選べる場合は、モデルのルート で Amazon Bedrock を選び、プロファイル(リージョンは任意)を選んでから、 amazon-bedrock/… のモデルを 1 つ選びます。このルートではモデルの一覧にそれだけが出て、選ぶまで開始できません (opencode 自身の既定モデルはこのルートにありません)。ルートを選ばないときは、これらのモデルは一覧に出ません。
- セッションは、ワークスペース共有のサーバではなく、自分のペインの中に専用の opencode サーバを立てて動き、AWS の資格情報は 渡りません。ルートゲートウェイがモデル呼び出しごとに署名し、セッションが持つのは、自分のプロセスからだけ使えて セッションの終了とともに無効になるベアラーだけです。セッションの中で選べるのは Amazon Bedrock のモデルだけで、 タイトルもセッションのモデルで作られます。
- 拒否された呼び出し(プロファイルの印が外れた・編集や削除された・確認がまだ・SSO のサインインが必要)は、理由とともに
すぐ失敗し、再試行されません。opencode の設定ファイル(あなた自身のもの、または作業コピーの
opencode.json[c]や.opencode/opencode.json[c])がenabled_providersを設定していると、ルートのプロバイダ固定を上書きしてしまうので、 起動は拒否され、動作中のセッションは止まります。 - 使用量はモデル呼び出しごとに 1 回、ゲートウェイが Amazon Bedrock・従量課金として記録します。これらの呼び出しについての opencode 自身のコスト表示は使いません。
どれを選ぶか
Section titled “どれを選ぶか”すでに払っている契約で選ぶのが確実です。Anthropic のアカウントなら claude、 ChatGPT や OpenAI API なら codex、複数プロバイダの API キーを切り替えたいなら opencode、GitHub Copilot のサブスクがあるなら copilot、Cursor のプランがあるなら cursor、AWS Builder ID(や Kiro プラン)なら kiro、Meta アカウント(や Meta の Model API キー)があるなら muse。ベンダーのアカウントがいらないモデルを使いたいなら lcpp です。 組織の engine(またはネットワーク上の llama-server)で動くので、サインインも契約の上限もありません。
どれも会話表示・ミラーからの回答・他エージェントへの引き継ぎに対応します。実際に 決め手になりやすい差は、コンテキストゲージ(claude / codex / opencode / kiro / lcpp / muse)、 画像貼り付け、そしてマネージド実行が要るかどうかです。Codex と opencode は セッションごとのプロセスを持たないので、数を並べても重くなりません。
lcpp: 実機計測で分かったこと
Section titled “lcpp: 実機計測で分かったこと”lcpp(ADR 0093)はベンダーのホスト型 API ではなく、自前の llama.cpp エンジンの
インスタンスを動かします。16 回の実機走行で、最初のセッションの前に知っておくべき
実際の費用が分かりました。
- 最初のターンは分単位で待ちます。 エンジンのインスタンスが止まっていると、 真のコールドスタートにおおよそ 3.5〜7 分かかります(多くは 4〜5 分帯に収まり、 1 件は 302 秒でタイムアウトしました)。セッションが固まっているのではなく、 インスタンスを購入して起動している時間です。2 回目以降のターンは、インスタンスが 温かいままなら速く返ります。
- 文脈窓は 8000 トークン以上を選んでください。 窓 3500 では、一部のモデル ファミリーが圧縮を連続で発火させ、ハーネスが無限に回り続ける代わりに意図的に 停止します。Gemma と Qwen3-Coder の両方で再現しました。窓 8000 ではどちらも 問題なく完走し、窓 24000 では圧縮自体が起きません。この停止は設計どおりの 動作であり、不具合ではありません。
- 同じ課題でもファミリーによってターン数が大きく違います。 同じ窓でも 費用差は数倍に及びます。ある実測の課題(小さなプロジェクトの 5 か所の 不具合修正+想起の質問 1 問)では、Qwen3.8 が 29〜30 ターン、Gemma-4 が 63 ターン、GPT-OSS が 95 ターン、Qwen3-Coder が 164 ターン(Gemma-4・Qwen3-Coder はどちらも窓 8000)でした。4 つとも正しく完走しており、差は正しさではなく 費用です。
- 動作を確認したモデルファミリーは Qwen3・GPT-OSS・Gemma の 3 つ(4
チェックポイントで確認)。
llama-3.1-8b-instruct-q4_k_mは動きません: このエンジンのビルドには Llama 専用の tool call パーサが無く、tool call の 構文解析が失敗します。目録にあるモデルがどれも同じように動くわけではないので、 確認済みのファミリーを選んでください。 - モデルの入れ替えにインスタンスの入れ替えは要りません。 最初の 1 回を除き、 同じエンジン上で別のモデルへ切り替えてもコールドスタートは発生しませんでした。 高くつくのは最初の購入だけです。
lcpp には Terminal(CLI)経路が一切ありません。上の脚注 9 のとおり、動くのは
Managed だけです。
muse: Agent Fleet からは見えないもの
Section titled “muse: Agent Fleet からは見えないもの”Muse Code は、Agent Fleet にもある機能を自前でいくつか持っています。muse のセッションの 中ではそれらがそのまま動きますが、Agent Fleet の側からはほとんど見えません。使うのは構いませんが、 Console に出る情報は Muse Code 自身よりずっと少ないと分かったうえで使ってください。
- muse のセッションが自分で入れる予約実行。 muse のセッションは、プロンプトを自分の
タイマーに載せて、あなたがいないところで後から走らせることができます。これは Muse Code
の予約であって Agent Fleet の予約ではありません。Console の予約実行の一覧には出ず、
Agent Fleet からは取り消せず、一覧も削除もそのセッション自身にしかできません(本人に
頼んでください)。予約が発火するとミラーに
scheduledFireという 1 行が出るので、走ったことは 分かります。発火するのはそのセッションが動いている間で、繰り返しの予約は 7 日で 自動的に期限切れになります。Agent Fleet からこの機能を止めることもできません。これは、Muse Code にその設定が無く、そのツールを外せる唯一の制御は連携(MCP)のツールを(Agent Fleet が セッションに渡しているものも含めて)まとめて外してしまうからです。上の表の「定時実行 (無人実行)」の行は Agent Fleet 自身の予約の話で、これとは別ものです。 - muse のセッション同士のメッセージと、そこで使われる名前。 Muse Code はセッション間 メッセージと、セッション名の登録簿を自前で持っていて、どちらも利用者ごとにホーム ディレクトリへ置かれます。Agent Fleet はそのどちらにも繋がっていません。その経路で送られた メッセージはミラーにも会話にも通知にも出ませんし、その登録簿の名前は Console が表示する セッション名とは別ものです。あるセッションから別のセッションへ話しかけたいときは、ミラーに 出る Agent Fleet 自身のセッション間メッセージを使ってください。
- muse が持つ、あなたの muse 会話の一覧。 1 つのワークスペースの muse セッションは
Muse Code のストアを 1 つだけ共有するので、Muse Code 自身のセッション一覧はセッション単位
ではなく利用者単位です。実測でも、ある muse セッションが、自分とは無関係の muse セッションの
会話を一覧に出しました。Agent Fleet は自分が始めていない muse の会話を出すことは決して
ありませんが、セッション自身は Muse Code 自前のコマンドや
read-sessionスキルから他の 会話に届きます。
この表に無いもの
Section titled “この表に無いもの”- Rovo Dev はさらに別の種別として調査しましたが、実装していません。
- ドライバのデバッグ中にしか効かない種別ごとの癖は
docs/build/へ。
エージェントはあなたの代わりにコマンドを実行し、ファイルを編集し、push します。 定時実行では無人で、権限確認をスキップするモードでは都度尋ねずに、これらを行います。
shellとssmは送った文字列をそのまま実行します。バックアップを取り、最小権限の資格情報を使い、 承認ゲートに頼ってください。
¹¹ muse を起動メニューやアシスタントの相手として出すには、2 つが揃っている必要が あります:Muse Code はプロプライエタリでイメージに含まれないのでオンデマンドでの導入が要り(Muse Code の接続カードから・約 299MB がホームに入ります)、かつログイン済みであることです。未認証の セッションは仕事を受け取ったうえで毎ターン失敗します。アシスタントとしての muse は 1 ターンを 1 回のヘッドレス実行で答え、会話を覚えています。続けて尋ねれば前のターンを踏まえて返します。 そして「答える」だけで「する」ことはありません。Agent Fleet はこのターンをシェル・ファイル書き込み・ Web ツールを切って走らせており、実測 2 回、ファイルを書くよう頼んだチャットターンはツールを 1 度も呼ばず何も書きませんでした。
¹² Agent Fleet は muse の会話を進行中に自分の側へ書き写すので、停止中のセッションでも 履歴が見えます。Muse Code 自身のセッションファイルは読める転写ではなく内部形式の実行時 ログなので、ここでは出典になりません。
¹³ muse のセッションはツールの承認を一度も求めません。スキップする対象が無いので選べませんが、
この行の「—」は、機能が無いという意味ではなく安全側が薄いという意味です。Muse Code
自身のサンドボックスは Workspace のコンテナの中では構築できず(コンテナのセキュリティプロファイル
が拒否します)、そのサンドボックスを切るフラグはセッションのファイルシステムとローカル網の制限も
一緒に外します。結果、どのツール呼び出しも承認を考える前にポリシーで許可されます。実測では、muse
のターンが作業コピーの外にあるファイルを確認なしで書きました。よって muse のセッションはこの
コンテナに対して shell と同じ届き方をするものとして扱い、上の警告はそのまま当てはまると読んで
ください。
¹⁴ Muse Code には contributor モードがあり、オンの間は会話(セッション間のメッセージを含む)が Meta の製品改善に使われることがあります。Agent Fleet は会話を扱う muse を起動するたびに、このモードを明示して 渡します。設定 › エージェント › Muse Code › 動作 の contributor モード でオンにしない限り オフです。各セッションは作成時のモードを、停止・再開や Agent の再起動をまたいでも保ち、 フォーク・作り直しでも引き継ぎます。設定の変更は、以後に作成するセッションと、次回以降の アシスタントチャット・AI 補助に反映されます。セッションが自分でこの設定をオンにすることはできず、 オンにできるのは Console からの変更だけです。
Muse Code 1.3 では、同じ選択がどのモデルにも並ぶ「-contributor」版として提供され、しかもその版が
Muse Code 自身の既定でした。いまもその版を一覧に出すホストでは、Agent Fleet が代わりに選ぶことは
ありません。既定のまま起動したセッションは、その条件が付かない最新のモデルで動き、選びたい人の
ために contributor 版もピッカーに残してあります。既定のモデルと reasoning effort(none〜ultra)も
同じ 動作 設定で選びます。
アシスタントチャットも同じ扱いで、選ぶ場所は 設定 › AI です。推奨のままならその条件が付かない最新の モデルで動き、一覧そのものが読めないときは Muse Code の既定で黙って走らせず、そのターンを断ります。
¹⁵ muse のチップは、稼働中の muse セッションが最後に観測した値です。Agent Fleet の側から 取りに行ける数字ではありません。Muse Code は自分の使用量をセッションプロトコルで報告し、それが 届くのはターンが終わったあとです。このワークスペースで muse をまだ動かしていない間、チップは 「—」=「まだ観測が無い」を出します(使用量ゼロではありません)。1 つ目の利用枠の長さは提供元が決める ため(実測では 5 時間)、行の名前は「現在の利用枠」にしてあります。 最後の観測値は Agent の再起動をまたいで残ります(ディスクに保存され、記録したときと同じアカウントにだけ 復元されます)。ただし、再起動の時点でリセット時刻を過ぎている利用枠は、数値ではなく「—」(古い値)で表示されます。
¹⁶ Muse Code は個人のルールを ~/.config/muse/AGENTS.md の 1 ファイルに置く作りで、
ワークスペースの方針とあなた自身の指示の両方がそこへ行きます。Agent Fleet は印付きの 2 ブロックと
して書き、それ以外はそのまま残すので、あなたが自分で書いたルールは消えません。ワークスペースの
トピックファイルは別経路で、~/.config/muse/skills/ 配下のスキルとして届きます。セッションは
作業コピーを信頼した状態で動くので、リポジトリ自身の AGENTS.md も読まれます。なお Muse Code は
AGENTS.md と CLAUDE.md を足し合わせではなく優先順位として扱い、両方あると AGENTS.md を
使って他方は飛ばしたと言います。
¹⁷ muse は、連携サーバーを設定ファイルに書いてもらう代わりに、セッションの開始時に Muse Code へ 手渡す kind です(もう 1 つは lcpp です。脚注 18)。つまりサーバーの組み合わせをワークスペース全体で 1 つに揃える必要が なく、セッションごとに変えられます。ここから 2 つ。追加したサーバーが効くのは、そのあとに 起動したセッションからです(稼働中のセッションは渡された組み合わせのまま)。そして各サーバーが 起動するのはセッションを開いた時ではなく最初のターンが走る時なので、立ち上げ直後のセッションは まだ何も繋がっていないように見えます。どのサーバーも「任意」として渡すので、起動に失敗しても 失うのはその連携だけで、セッションそのものは動きます。
¹⁸ lcpp にも設定ファイルはありません。ベンダー CLI を駆動しないので、有効にしたサーバーは 毎ターンの開始時に読み直され、Agent Fleet 自身が接続します。したがってサーバーを足したり 外したりすると、すでに開いているセッションでも次のターンから効きます(再起動は要りません。 ここが muse との違いです。脚注 17)。接続できないサーバーがあっても失うのはそのターンの そのツールだけで、ターン自体は動きます。失敗は毎ターンではなく会話に 1 度だけ記録されます。 ツールを動かしているのが Agent Fleet 自身であることの帰結がもう 1 つあります。 連携サーバーのツールは、どれも実行前に許可を求めます。これは、MCP の仕様には「このツールは読むだけ」 と機械的に判定する手段が無いためです。
¹⁹ lcpp のモデル一覧はあなた自身の llama.cpp サーバーのものなので、ベンダー CLI のような 「ツールに任せる」項目がありません。選ぶまで起動は待ちます。この種別ではどれを選ぶかが費用の 判断です: ある実測ベンチマークでは同じ作業がファミリーによって 29 ターンと 164 ターンに分かれ、 どちらも正しく完了しました。後からモデルを替えてもインスタンスを買い直しません(上の 「lcpp: 実機計測で分かったこと」)。
²⁰ codex と opencode が分岐できるのはマネージド実行のときだけです(CLI の起動コマンドには分岐点を渡す方法がないため。 lcpp と muse は常にマネージドです)。例外として、共有サーバーに接続した opencode 2 のターミナル(CLI)セッションも分岐できます (共有サーバーが分岐点を受け取れるため)。専用サーバーのターミナルセッションでは使えません。
²¹ copilot の Plan モードは起動時に設定し、マネージドの設定から切り替えることもできます。
²² cursor のモデル一覧は、ログインしているアカウントで使えるモデルそのものです(ライブ取得)。既定で始めた新しいセッションは、CLI 自身が前回使った・設定しているモデルに関係なく Auto で起動します(Cursor の Free プランでも使えます)。特定のモデルを使うときは明示的に選んでください。ターミナルのセッションを再開したときは、その会話に記録されたモデルを引き継ぎます。kiro は Free プランでも named モデル(Auto、Claude Sonnet / Haiku ほか)を選べます。
²³ RTK は、エージェントが実行するコマンドを書き換えて、出力で消費するトークンを減らす仕組みです。
⚙設定 →「エージェント」でエージェントごとにオン/オフでき、ワークスペースのイメージに
rtk が無いときは何も起きません。効き方は違います。claude・opencode・copilot は、シェルコマンドを実行前に
書き換えるフックかプラグインを持つので、毎回効きます(copilot は変更後に始めたセッションから)。
codex と agy にはコマンドを書き換える手段が無く、Agent Fleet は「rtk を使ってね」という指示ブロックを
足すだけです。使うかどうかはエージェント次第(ベストエフォート)です。cursor・kiro・lcpp・muse に RTK の設定は
ありません。この行はコードと突き合わせて検査されています。ドライバが RTK の仕掛けを持つ種別に印が付きます。
²⁴ どちらも既定でオフのオプトイン設定です(設定 › エージェント › セッション)。セッションが子を起こす・メッセージを
送るのは Agent Fleet 自身の MCP サーバーのツールで、それは「連携(MCP)サーバーを受け取る」行に印のある
種別すべてに渡ります。そのためこの行はその行に連動し、検査も同じコード上の項目に結び付けてあります。
受ける側はこの行の種別すべてです。子はこの 9 種別のどれでもよく、メッセージの宛先にもなれます
(停止中なら先に再開します)。shell と ssm はどちらも不可です。送られた文字列がコマンドとして
実行されてしまうためです。
²⁵ スタジオのエージェントのセッションは、どちらの実行方式でも付けられます。ただし、スタジオのツールに 「自分はどのセッションか」を伝えられないエージェントは別です。opencode はマネージド(1 つのサーバーを フォルダ内の全セッションが共有するため、書き込みがどのセッションのものか区別できません)、 copilot・cursor・kiro もマネージド(セッション名をまだ伝えられません)で、この 4 つはターミナル(CLI)でだけ 付けられます。claude と agy はマネージドが無いのでもともとターミナル(CLI)だけです。codex はどちらの方式でも付けられ、 lcpp(マネージドのみで、ターミナル(CLI)はありません)はマネージドで付けられます。muse は戻れるターミナル(CLI)が無く、 マネージドも同じ理由で断られるため、いまは付けられません。付けられるかどうかはコードと突き合わせて検査されています。 スタジオのセッションは既定で worktree 付きで、Console でオフにできるのはターミナル(CLI)のセッションと lcpp だけです。