Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

午後二時に差分が五つ同時に届きました
こういう環境が実際に売っているのはモデルではありません
隔離の部分は今日gitだけで試せます
ボトルネックは消えずに場所を移します
だから見るべきは生成機能ではなく選別機能です
五つが似ていれば五倍読んでひとつを得ます
このプロジェクトの現在の状態をありのままに書くと
ツールを入れる前に今週やってみる実験
まとめと出典

午後二時に差分が五つ同時に届きました

同じイシューに対してエージェントを五つ同時に回しました。20分後に五つのブランチができ、それぞれ300行から900行のあいだの変更が入っています。アプローチは三つが似ていて二つが違います。テストは四つが通り、ひとつが落ちます。

ここで起きることはたいていこうです。五つを全部読むのに二時間かかります。二時間後にひとつを選びますが、選んだあとで残りの四つの良かった部分が惜しくなります。それで少しずつ移し替えているうちに、結局六つ目のバージョンを手で作ります。生成にかかった20分は確かに減り、そのあとに付いた二時間半はもともとなかった時間です。

この記事は、その二時間半がどこから来るのかについての話です。

こういう環境が実際に売っているのはモデルではありません

Orcaは、この流れを正面から狙ったツールです。リポジトリの説明は自らを、並列エージェントの群れを扱うためのADEだと紹介し、どのCLIエージェントであれユーザー本人の購読で回すと明かします。つまりモデルを売る製品ではありません。

READMEが最初に掲げる機能は並列ワークトリーです。プロンプトひとつを複数のエージェントに撒き、それぞれを隔離されたgit worktreeに入れ、結果を比べて勝ったものをマージすると書かれています。残りの機能も同じ方向です。差分の各行にコメントを付けてエージェントへ返す、GitHubとLinearのイシューをアプリのなかで開いてそのままワークトリーを作る、リモートサーバー上のワークトリーをSSHで繋ぐ、ブラウザでUI要素をクリックしてそのHTMLとCSSと切り取ったスクリーンショットをプロンプトに入れる。

一覧を並べてみると共通点が見えます。この製品が売っているのはコードを作る能力ではなく、作られたものを人が引き受けられる表面です。隔離、比較、コメント、マージ。まさにレビューと統合の道具です。

隔離の部分は今日gitだけで試せます

並列エージェントで最初に痛むのは、ひとつのディレクトリを複数で触る状況です。これはgitの基本機能で解決します。以下は実際に実行して確認したコマンドです。

# リポジトリの中で、ブランチを新しく作りながら別のディレクトリを付ける
git worktree add -b try/a ../wt-a
git worktree add -b try/b ../wt-b

git worktree list
# /path/main-repo  2072b5c [main]
# /path/wt-a       2072b5c [try/a]
# /path/wt-b       2072b5c [try/b]

各ディレクトリはファイルツリーとビルド成果物が完全に分離されており、.git のオブジェクトストアはひとつを共有します。リポジトリを五回クローンするのと結果は似ていますが、ディスクとフェッチ時間ははるかに少なく済みます。

片付けるときに引っかかる地点がひとつあります。

git worktree remove ../wt-a
git branch --list
# * main
#   try/a      <- ワークトリーは消したがブランチは残っている
# + try/b      <- プラス表示は別のワークトリーが掴んでいるという意味

ワークトリーを消してもブランチはそのまま残ります。実験ブランチが溜まる原因はたいていここです。そしてプラス表示が付いたブランチは別のワークトリーがチェックアウト中なので、こちらから改めてチェックアウトできません。並列で回していれば必ず出会う制約なので、あらかじめ知っておくほうが良いところです。

ボトルネックは消えずに場所を移します

隔離を解決すると次の壁が出てきます。生成が五倍速くなっても、読む人は一人です。

この関係は待ち行列理論の一行で整理できます。システムのなかに平均して留まる仕事の数をL、到着率をラムダ、平均滞在時間をWとすると、LはラムダとWの積です。裏返せばWはLをラムダで割った値です。

エージェントを五つに増やすということは、ラムダを五倍に上げることです。レビューの処理能力がそのままなら、システム内のL、すなわちレビュー待ちの差分の在庫が積み上がります。在庫が積み上がれば、各差分の滞在時間Wが伸びます。滞在時間が伸びた差分は、そのあいだにベースブランチが動いて衝突が生まれ、また直さねばならず、また列に並びます。

数字がなくても結論は明確です。レビュー能力を一緒に上げなければ、並列化は完了速度ではなく在庫を増やします。午後二時の二時間半はここから来ます。

だから見るべきは生成機能ではなく選別機能です

この観点で見直すと、並列エージェントのツールを選ぶときに問うべき質問が変わります。同時に何個回せるかではなく、五つのうち四つをどれだけ安く捨てられるかです。

捨てる費用を下げる方法は三つです。第一に、読む前に機械が先に落とすようにします。各ワークトリーでテストとリントを自動で回し、落ちたものをレビュー対象から外すことで、ツールがなくてもスクリプトでできます。第二に、比較を横に並べます。五つを順番に読めば前のものを忘れますが、同じファイルの五つのバージョンを横に並べて見れば差だけが残ります。第三に、直した点を人がまた移し替えなくて済むようにします。差分の上にコメントを付けてそのままエージェントへ返す機能が必要な理由がこれです。先ほど見たOrcaの機能一覧が、まさにこの三つに集中しています。

言い換えると、こういうツールの価値はエージェントを複数回すところにはありません。それはターミナル五つでもできます。価値は四つを捨てる費用を下げるところにあります。

五つが似ていれば五倍読んでひとつを得ます

ここでもう一段入るべきものがあります。ファンアウトが情報を与えるには、候補どうしが違っていなければなりません。同じプロンプトを、同じコンテキストで、同じモデルに五回投げれば、たいてい大同小異の答えが五つ出てきます。すると読む費用は正直に五倍なのに、得られる情報はひとつ分です。先ほどの午後二時の場面で三つが似ていた理由は、たいていこれです。

多様性を作る軸は三つです。ひとつ目はプロンプトです。同じ要求を投げる代わりに、アプローチを釘付けにして分けます。ひとつには既存の抽象を再利用させ、ひとつには新しいモジュールを作らせ、ひとつには最小の変更だけをさせる、という具合です。こうすれば比較が実装の趣味ではなく設計選択の比較になります。ふたつ目はコンテキストの範囲です。ある候補には関連ファイルだけを与え、ある候補にはテストとイシューまで与えます。三つ目は実行主体です。

Orcaが特定のモデルに縛られず、ターミナルで動くCLIエージェントなら何でも繋ぐと明示した点は、三つ目の軸で意味があります。異なるエージェントは既定のプロンプトと道具の使い方の癖が違うので、同じ要求にも違う形の答えを出します。ただしこれは製品が可能にしてくれる軸にすぎず、実際に多様性を設計するのは依然として人の仕事です。

このプロジェクトの現在の状態をありのままに書くと

誇張しないために、確認した事実だけを書きます。リポジトリは2026年3月17日に作られ、ライセンスはMIT、主要言語はTypeScriptです。デスクトップはmacOS、Windows、Linuxに対応すると表示されており、HomebrewのキャスクとAURパッケージが案内されています。モバイルの同伴アプリは、iOSはApp StoreとTestFlight、AndroidはリポジトリのリリースにアップされたAPKで配布されます。

READMEは自ら毎日デプロイすると書いており、だから機能一覧は常に遅れているのでリリースノートが本当の一覧だと案内します。私はこの文を長所であり警告でもあると読みます。作られて半年に満たないデスクトップアプリが毎日デプロイされるということは、昨日動いていたものが今日は違う動きをしうるという意味でもあります。確認した時点で開いているイシューは3千件を超えます。人気のあるリポジトリでこの数字自体が欠陥を意味するわけではありませんが、成熟度を代わりに語ってくれるわけでもありません。

まとめると、このツールは使えるかどうかを他人が代わりに判断してくれる段階にはありません。チームのコードが入る環境なので、導入するならその判断は自分でしなければなりません。

ツールを入れる前に今週やってみる実験

インストールせずにワークフローだけを先に試す方法があります。実際にお金がかかるのはツールではなくレビューなので、レビューのほうから測ればよいのです。

# 1) 同じイシューでブランチを三つ切る（エージェントを三つ回すか、人が三回試すか）
for n in a b c; do git worktree add -b try/$n ../wt-$n; done

# 2) 人が読む前に機械が先に落とす
for n in a b c; do
  ( cd ../wt-$n && npm test >/dev/null 2>&1 && echo "PASS $n" || echo "DROP $n" )
done

# 3) 生き残ったものだけ、ファイル単位で横に並べて見る
git diff try/a try/b -- src/

そして二つを記録します。生き残った候補からひとつを選ぶのに実際に何分かかったか、そして選んだあとに別の候補から手で移し替えたコードがあったか。後者があったなら、そのチームではファンアウトはまだ得になっていません。移し替えた瞬間に、五つ作った理由が消えるからです。

この測定を一週間やってみるだけで、ツールを買うかどうかではなく、何個まで撒くのが自分のチームに合うのかを数字で言えるようになります。たいていその数字は五より小さいところです。

まとめと出典

並列エージェント環境は生成スループットを売っているように見えますが、実際に売っているのは選別と統合の道具です。そしてその道具が必要な理由は、生成が安くなるほどボトルネックがレビューへ移っていくからです。ツールを選ぶ前に自分のチームのレビュー処理能力をまず測るほうが、順序としては合っています。

stablyai/orcaリポジトリ — 機能一覧、対応エージェント、インストール経路、ライセンス。この記事のOrcaに関する記述はすべてリポジトリのREADMEとリポジトリのメタデータから直接確認したものです。
git worktree公式文書 — ワークトリーの追加、一覧、削除の正確な動作
本文のgitコマンドはgit 2.50.1で実際に実行して出力を確認しました。npm test の入った最後の例はプロジェクトごとに違うので、そのまま実行してはいません。