Codex CLIにVimの「.」リピートが来た──rust-v0.150.0が明かす「multi-agent v2」という内部呼称

OpenAIのコーディングエージェントCodexのCLI版が、rust-v0.150.0(2026年8月26日19:37 UTC公開)で新機能とバグ修正の両方を含むアップデートを出した。GitHub公式リリースノートを確認すると、キーボード操作の細かい改善と並んで、「multi-agent v1」「multi-agent v2」という2つの内部システムがCodexの中に存在することが、コミット一覧の記述から読み取れる。

3行まとめ

1. Vimモードで直前の編集を「.」キーで繰り返せるようになり(#40521)、パーミッションモードを循環切替するキーバインドも追加された(#39873)
2. Amazon Bedrockモデルでの会話圧縮とマルチエージェント互換性の不具合が修正された(#39804・#39825)。修正内容は「Bedrockモデルにはmulti-agent v1を使う」という後方互換的な対応
3. コミット一覧には「Track multi-agent v2 spawn calls in analytics」(#39722)など、multi-agent v2に関する変更が複数含まれており、Codexが次世代のマルチエージェント実行システムを開発中であることが示唆されている

Vimモードの「.」リピートとパーミッションモード切替

New Features欄に挙げられている変更の1つが、キーボード操作性の改善だ。

Bind shortcuts to cycle permission modes, and use . in Vim mode to repeat your last edit. (#39873, #40521)

（パーミッションモードを循環切替するショートカットを割り当て、Vimモードでは「.」キーで直前の編集を繰り返せるようになった）

Vimのdotリピート(直前の変更操作をもう一度実行するコマンド)は、Vimユーザーにとって基本的な操作の1つで、Codex CLIのVimモードがこれをサポートしていなかったことが、この修正のIssue番号(#40521「Add dot-repeat to Vim mode」)から分かる。パーミッションモードの循環切替キーバインドは、Issue #39873「Add keybindings for cycling TUI permission modes」に対応する。

Amazon Bedrockでの不具合修正

Bug Fixes欄には、Amazon Bedrockモデル利用時の不具合修正が挙げられている。

Fixed conversation compaction and multi-agent compatibility for Amazon Bedrock models. (#39804, #39825)

（Amazon Bedrockモデルにおける会話圧縮とマルチエージェント互換性を修正した）

この2件のIssue番号をリリースノート末尾のフルコミット一覧で確認すると、それぞれ次のように記述されている。

#39804 Use multi-agent V1 for Amazon Bedrock models #39825 Use Responses compaction for Amazon Bedrock

（#39804 Amazon BedrockモデルにはmultiagentV1を使うようにする / #39825 Amazon Bedrock向けにResponses圧縮を使うようにする）

「multi-agent V1を使う」という表現は、Codexの中に少なくとも2世代のマルチエージェント実行システムが存在し、Bedrockモデルでは新しい方(V2とみられる)が正しく動かないため、古い方(V1)にフォールバックする対応を取ったことを示している。

コミット一覧に散らばる「multi-agent v2」

同じフルコミット一覧をmulti-agentで検索すると、V2に関連するとみられる変更が他にも見つかる。

#39722 Track multi-agent v2 spawn calls in analytics #40477 Reload Multi-Agent V2 children through their parent #40585 Track remaining multi-agent v2 tools in analytics

（#39722 multi-agent v2のspawn呼び出しを分析用にトラッキング / #40477 Multi-Agent V2の子プロセスを親経由でリロードする / #40585 multi-agent v2の残存ツールを分析用にトラッキング）

これらのコミットメッセージは、それぞれ1行の要約のみで、multi-agent v2が具体的にどう動くシステムなのかは説明されていない。ただし「spawn calls」「children」「parent」という言葉から、複数のサブエージェントを親プロセスが生成・管理する仕組みであること、そして「V1で回避」対応が必要になるほど、V2が実験的な段階にあることがうかがえる。

「なぜV1に戻したか」はPR本文に明記されていた

コミットメッセージの1行だけでは分からなかった「なぜBedrockでmulti-agent v1に戻す必要があったのか」について、該当PR #39804をGitHub APIで直接開くと、「Why」という見出しの下に理由が明記されていた。

Amazon Bedrock does not support the response items required by multi-agent V2.

（Amazon Bedrockは、multi-agent V2が必要とするレスポンス項目をサポートしていない）

「What changed」欄には、対応の中身も書かれている。

Normalize Bedrock model catalogs to advertise MultiAgentVersion::V1.

（Bedrockのモデルカタログを正規化し、MultiAgentVersion::V1を通知するようにした）

MultiAgentVersion::V1という表記から、Codexの内部コードには複数のバージョンを持つ列挙型(Rustのenum)MultiAgentVersionが存在し、モデルプロバイダごとにどのバージョンのマルチエージェント実行系を使うかをカタログとして管理していることが分かる。

multi-agent v2が公開する5つのツール名

関連PRを追加で3件、GitHub APIで直接開いて本文を確認した。PR #39722「Track multi-agent v2 spawn calls in analytics」の本文には、multi-agent v2の中核ツールとしてspawn_agentの名前が出てくる。

Emit started and completed collaboration tool events for multi-agent v2 spawn_agent calls, including failed invocations.

（multi-agent v2のspawn_agent呼び出しについて、開始・完了時のコラボレーションツールイベントを発行する。失敗した呼び出しも含む）

さらにPR #40585「Track remaining multi-agent v2 tools in analytics」の本文には、spawn_agent以外の関連ツール名が列挙されている。

Record collaboration tool analytics for send_message, followup_task, interrupt_agent, and list_agents, including receiver attribution, duration, failures, and interrupted calls.

（send_message・followup_task・interrupt_agent・list_agentsについて、送信先の紐付け・所要時間・失敗・中断された呼び出しを含むコラボレーションツールの分析データを記録する）

この2件のPR本文を合わせると、multi-agent v2が公開しているとみられるツール(関数)名は次の5つになる。これはコミットメッセージの1行要約だけでは分からなかった情報で、PRの本文まで開いて初めて確認できた。

PR #40477「Reload Multi-Agent V2 children through their parent」の「Why」欄には、アーキテクチャに関する説明もある。

Multi-Agent V2 children are owned by their parent at runtime. Resuming an unloaded child directly could rebuild it from caller-provided settings instead of the parent's current authority.

（Multi-Agent V2の子エージェントは、実行時には親エージェントに所有されている。アンロードされた子を直接再開させると、親が現在持っている権限設定ではなく、呼び出し元が渡した設定から再構築されてしまう可能性がある）

「親エージェントが子エージェントを所有し、権限設定も親経由で管理する」という記述から、multi-agent v2が単純な並列実行ではなく、親子関係を持つ階層的なエージェント管理システムとして設計されていることがうかがえる。

なお、GitHub Releases API(直近100件)をmulti-agent v2という文字列でリリース本文横断検索すると、確認できた最も古い言及はrust-v0.147.0(2026年8月7日公開)の「Support leaf models in multi-agent v2」(#36892)だった。「leaf models(末端のモデル)」という表現からも、親(root)と子(leaf)からなる階層構造を前提にした設計であることが読み取れる。

リリースノート本文とコミット一覧、両方を読む必要がある理由

Codexのリリースノートは、上位に「New Features」「Bug Fixes」の要約セクションを置き、末尾に約190件のフルコミット一覧を並べる構成になっている。今回のmulti-agent v2の存在は、要約セクションだけを読んでも分からない。「Amazon Bedrockでマルチエージェント互換性を修正した」という1行の裏に、「なぜV1に戻す必要があったのか」という文脈は、末尾のコミット一覧を横断的に検索して初めて見えてくる。

同じフルコミット一覧には、他にも実装の断片が見える。「Guardian」という名前の付いた変更(#39738「Honor Guardian runtime settings from model defaults」、#40028「Log Guardian V2 classification results」など)が多数含まれており、こちらも「Guardian V1/V2」という2世代のシステムが存在することを示唆している。ただしGuardianが何を指すかについては、本記事の範囲では確認していない。

当サイトでの既存Codex記事との関係

当サイトでは、OpenAIがCodexに導入した「banked resets」というレート制限の繰越機能や、Codexのハーネス・エージェントループの仕組みを扱ってきた。今回のmulti-agent v2は、これらの記事で扱った機能とは別の、まだ正式発表されていない開発中の仕組みである点が異なる。公式のアナウンスやドキュメントでmulti-agent v2という名称が説明されている様子は、Zenn・Qiita検索、および本記事執筆時点でのGitHubリポジトリ内検索でも確認できなかった。

PR本文までは開いたが、実際のdiffとコードは読んでいない

当初この記事はrust-v0.150.0のリリースノート本文とコミット一覧のみを一次ソースにしており、コミットメッセージのタイトル(1行要約)から先には確認できていなかった。今回、関連する4件のプルリクエスト(#39804・#40477・#39722・#40585)をGitHub API経由で個別に開き、「Why」「What changed」といった本文の説明文までは確認できた。ただし、これらのPRが実際に変更したコードの差分(diff)そのものや、レビューコメントでのやり取りまでは読んでいない。そのため、MultiAgentVersionという列挙型が具体的にどんな値を取りうるか(V1・V2以外にも存在するか)、spawn_agentなどの5つのツールが実際にどんな引数・戻り値を持つ関数として実装されているかは、依然として確認できていない。Guardianと呼ばれる別システムの中身についても、この記事の範囲では追加調査していない(Guardian V2については別記事で確認した内容がある)。

自分自身はCodex CLIのVimモードやBedrock連携を実際に使ったことがなく、この記事はリリースノートの読み込みのみに基づいている。

感想・指摘はコメント欄へ。