最近のAI開発ツールは、「どのLLMが一番賢いか」から、「複数のLLMやcoding agentをどう組み合わせるか」に関心が移ってきている。

その文脈で最近話題になっているのが、OpenRouter、Sakana AI Fugu、agmsg、そして h5i だ。

ただし、これらは同じ問題を解いているわけではない。

ツール	一言でいうと	実行場所	解いている問題
OpenRouter	モデル/APIルーティング	SaaS/API	どのモデル・プロバイダに投げるか
Sakana AI Fugu	学習されたマルチエージェント指揮モデル	SaaS/API	複雑なタスクをどう分解・委譲・統合するか
agmsg	エージェント間メッセージ transport	ローカル/SQLite	Claude Code、Codex、Gemini CLI などをどう会話させるか
h5i	監査可能なサンドボックス型ワークステーション	ローカル/Git/worktree	複数 coding agent を conflict なく走らせ、検証済みの一つを merge するにはどうするか

この記事のまとめ: OpenRouter はモデルを選ぶ。Fugu はagentを指揮する。agmsg はagent同士を会話させる。h5i は、手元のrepoで複数agentを安全に走らせる。

OpenRouter：モデル選択をAPIの裏側に逃がす

OpenRouter は、複数のLLMを単一APIから扱うためのルーティング層である。公式ドキュメントでは、単一エンドポイントから多数のモデルへアクセスし、fallback や費用効率のよい選択を扱うと説明されている。([Documentation][1])

重要なのは、OpenRouter が model routing と provider routing を分けている点だ。つまり「どのモデルで答えるか」と「そのモデルをどのプロバイダから呼ぶか」を別の問題として扱う。([OpenRouter Blog][2])

これは実用上かなり強い。アプリケーション側は OpenAI-compatible なAPIを叩くだけで、モデル変更やコスト最適化をある程度抽象化できる。

ただし、OpenRouter が解いているのは基本的に API call のルーティング問題 である。ローカルのGit repositoryで Claude Code と Codex を同時に動かしたとき、ファイル衝突やbranch汚染をどう防ぐかは別問題として残る。

Sakana AI Fugu：マルチエージェントを一つのモデルAPIにする

Sakana AI Fugu は、OpenRouter より一段上の抽象にいる。

Fugu は、複数モデルを動的にオーケストレーションするマルチエージェントシステムを、単一のモデルAPIとして提供するものだと説明されている。([sakana.ai][3]) 技術報告でも、Fugu 自体が user query を理解し、動的にタスクの分解及びと割り当てを行うオーケスト (指揮者) ラモデルであるとされている。([arxiv.org][4])

つまり Fugu は、単に「どのモデルに投げるか」ではなく、「どう分解し、誰に任せ、どう統合するか」を扱う。

これはかなり自然な進化だ。現実の開発タスクは、単一の質問応答では終わらない。設計、実装、テスト、レビュー、修正、再検証がある。Fugu は、そのような複雑なタスクをAPIの裏側でagent teamに分担させる方向だと言える。

ただし、Fugu も基本的には SaaS/API である。ユーザーから見ると「賢い単一API」として使えるのが強みだが、ローカル開発環境で実際に複数agentがファイルを書き換えるときの衝突管理までは別の層の問題になる。

agmsg：agent同士を会話させる最小transport

ここで面白いのが agmsg である。

agmsg は、Claude Code、Codex、Gemini CLI、Copilot CLI などの CLI coding agent を、同じ環境で会話させるための Bash + SQLite ベースの小さなツールである。([Product Hunt][5])

この発想はとてもよい。実際、Claude の出力を Codex に貼り、Codex の返答を Claude に貼り返す、という「人間がメッセンジャーになる」作業はすぐに発生する。agmsg はそこを小さく切り出して、agent同士の通信路にする。

ただし agmsg は意図的に薄い。公式GitHub でも、SQLite はlogの順序を保証するが、turn-taking はtransportではなく protocol-level の問題だと説明されている。([GitHub][6]) また、runaway loop の停止条件も transport ではなく prompt/protocol 側の責務である。([GitHub][6])

つまり agmsg は「会話の床」を作る。だが、その上で誰が作業をclaimするのか、どのpatchを採用するのか、どのagentの作業を検証するのか、sandboxをどう分けるのか、という問題は上位層に残る。

h5i：会話だけでなく、作業場そのものを分ける

h5i は、単なるagent chatではない。また、OpenRouter のようなモデルAPI aggregatorでもない。Fugu のように、オーケストレーション自体をSaaSのモデルとして提供するものでもない。h5i が解いているのは、もっとローカルで、もっと開発現場に近い問題である。

たとえば、同じrepoに対して Claude Code と Codex を同時に走らせたいとする。これは強い。Claude は設計がよく、Codex は別の実装案を出すかもしれない。片方が見逃したテスト失敗を、もう片方が見つけるかもしれない。しかし、同じ作業ディレクトリで雑に走らせるとすぐ壊れる。

ファイルが衝突する
branch が汚れる
dev server の port が被る
片方のagentがもう片方の変更を上書きする
agent同士が早すぎる段階で互いの出力を見て、独立性が崩れる
最後にどのpatchをmergeすべきか分からない

これを解決するために、h5i は、各agentに独立した h5i env、つまり sandboxed worktree を与える。公式サイトでも、h5i は複数の coding agent に separate sandboxes、sealed submissions、neutral verifier を与え、結果をrepo内にversionedに残すと説明されている。

ここが agmsg との大きな違いである。agmsg は agent 間の message transport を提供する。h5i は message に加えて、agent ごとの作業場、独立試行、相互レビュー、検証、merge までを扱う。

4つをstackとして見る

この4つは、競合というよりAI agent stackの別レイヤーだと見ると分かりやすい。

OpenRouter は、モデル呼び出しの交通整理をする。
Fugu は、複雑なタスクを複数agentにどう分担させるかを学習・推論する。
agmsg は、agent同士の会話を提供する。
h5i は、会話・相互レビューに加えてだけでなく、各agentの作業場を分け、検証可能な形で一つの結果に収束させる。

まとめ

OpenRouter は、モデルとproviderを選ぶ。
Sakana AI Fugu は、複数agentを指揮する。
agmsg は、agent同士の会話transportを作る。
h5i は、Claude Code や Codex をローカルのレポジトリでコンフリクトなく並列実行するための sandboxed workspace を作る。

この違いを押さえると、h5i の立ち位置はかなり明確になる。

h5i は単なる監査ツールではない。むしろ最初の価値は、ローカルで複数のcoding agentを安心して走らせられること だ。

その上で、h5i msg によるagent間handoff、sandboxed worktree、neutral verifier、Gitに残る実行証跡が組み合わさる。結果として、複数agentの試行をただの混沌ではなく、review可能な開発プロセスに変えられる。

AI coding の未来は、単一の最強モデルだけではなく、複数agentの並列実行に向かっていると思う。そのとき必要になるのは、SaaS上の賢いオーケストレーションだけではない。

手元のrepositoryで、ClaudeとCodexを同時に走らせても壊れない。agent同士が必要な情報をhandoffできる。最後に検証済みの一つだけをmergeできる。h5i は、まさにその local-first な実行基盤を狙っている。