Ultracode：AIがコーディングチームを率いる時代、人間に残るものは何か

TL;DR Ultracodeは「深度推論」と「自動チーム編成」をひとつのスイッチに束ねた。AIが自らタスクを評価し、ステップを分解し、数十から数百の分身を平行展開して戦わせる。機械が「いかに分業するか」まで学んだ今、人間の価値はより核心的な二つへと押し出されていく。このことは計算リソースを使い込む価値があるのか？完成した成果物が、なぜ「これでいい」と言えるのか？

しばらく前、Claude Codeを開いたとき、メニューの最下部に新しい選択肢を見つけた。Ultracodeだ。試しにそのモードをオンにして、厄介なコードの収束作業を投げ込み、あとは何もせず、ただ画面を眺めてその動きを見届けた。

従来のAIのように命令を受け取るや否や突き進むわけではなかった。まず時間をかけていくつかの分岐したバージョン履歴を照合し、ファイルのコンフリクトがないことを確認してから、もっとも安全なマージ経路を落ち着いた判断で選んだ。続けてミラーの同期、履歴の記録、その日の作業ログの補完。画面には「almost done thinking」という表示が繰り返し現れた。一連の処理が終わって気になったのは、仕上がりの美しさではなく、作業の「かたち」が変わったことだった。それは多くのエンジニアよりも慎重に振る舞っていた。

キャプション：複雑なバージョン収束作業をUltracodeに委ね、全過程で介入しなかった。AIは自らバージョンを照合し、マージロジックを選択し、ミラーを更新し、ログを補完した。

技術の表面の下：深度推論と動的分業

まず一点を明確にしておく。UltracodeはAIを「少し長く考えさせる」だけのものでも、新たなモデルでもない。Claude Codeの一つの動作モードであり、2026年5月末にOpus 4.8とともにリリースされた（公式ドキュメントはこちら）。スイッチをオンにすると、システムは同時に二つの歯車を回す。

1. 極限推論強度（xhigh）：コードに手を加える前に、あらゆる潜在的リスクとアーキテクチャの境界を頭の中でシミュレーションし尽くすよう、モデルに強制する。
2. 自動ダイナミック編成（dynamic workflow）：AIがタスクの規模を自ら評価し、分解する価値があるかを判断したうえで、作業を割り振る。

肝心なのは第二点が条件付きであることだ。タスクが十分に大きく、かつ切り分けられる場合にのみ分身を起動する。タスクの性質が本質的に逐次的であれば（私が投げた収束作業のように、一つのrebaseを十のエージェントに同時に担わせることはできない）、AIは素直に一歩一歩こなしていく。同じスイッチでも、問題によって異なる戦略が自動的に生まれる。画面を眺めながら最初に読み取ったシグナルはそこだ。Ultracodeはオンになっていたが、使うために使っていなかった。

タスクが十分に大きければ、AIは自らエージェント小隊を組む

タスクの規模が大きくなると、Ultracodeは真の力を発揮する。同一のセッション内でスクリプトをその場で書き上げ、数十から数百の「サブエージェント」を引き出して、それぞれがコードの一塊を担う。

さらに精妙なのは検証の仕組みだ。対抗的検証（adversarial validation）と呼べるもので、一群のエージェントが異なる角度から問題に攻め入り、別の一群が前者の導いた結論を専門に反駁する。両陣営がシステム内部で攻防を繰り返し、答えが収束して穴が見つからなくなるまで続く。

これは研究室の理論ではなく、すでに現実に起きたことだ。

📊 実戦データ：Bunのプログラミング言語移植

Bun（著名なJavaScript実行環境）の作者Jarred Sumnerが、極端な事例を公開している。この仕組みを用いて、Bunのコアに近い百万行のコードをZigからRustへ移植したのだ。

かつてこれは、ベテランエンジニアのチームが数クォーターを費やしても完遂できるか分からない作業量だった。この仕組みを使えば、十日以内にマージ可能な成果が出る。（Sumnerはこれをあくまで実験と位置づけており、既存のZig版を置き換えるものではないとも述べている。）

自分の核心競争力だと思っていたものが、Claudeの組み込み機能になった

この機能を目の当たりにして、心中は複雑だった。まさにこの「マルチエージェント協調」を、自分自身がつい最近苦労して手作りしたばかりだったからだ。

以前のこと、といってもほんの二ヶ月前だが、AIの異なるウィンドウをチーム協働に近い形で機能させるために、役割を明確に分割した流れを作っていた。Chatが検索と戦略判断を担い、Coworkが統合と実行を担い、Codeがコードと技術検証を担う。各フェーズの間は、ドキュメントと記憶システムで状態を同期させ、情報の断絶・重複・矛盾を防いでいた。

この分業は一種のハーネスエンジニアリング（harness engineering）だ。問題をAIに投げるだけでなく、AIを制約し、誘導し、分業させ、引き継がせ、検証するための作業システムを設計することだ。

これが独立した働き手としての自分の堀だと思っていた。

Ultracodeはその堀を直接埋めた。かつて人間の綿密な計画、手動の隔離、慎重なウィンドウ切り替えによってようやく成立した高度な協調技術が、今やソフトウェアの底層に組み込まれた一つの普通のボタンになった。これが意味することは一つだ。「AIを手動で編成する」という技術的アドバンテージは、もはやゼロになった。

実行力が無料になった後、何が希少になるのか

ツールがもっとも脳を使う「分業と編成」を引き受け、しかもそのコストはオープンエンドで（上限を設けず、答えが安定するまで走り続ける）、人間の立ち位置は一段階後ろへ押し出された。

「どう分解するか、どう割り振るか」はもはや考える必要がない。機械の方が速く、うまいからだ。このとき人間が真に問われるのは、自動化できない二つのことだ。

• 計算リソースの判断：目の前のこの問題を徹底的に解くことは、スイッチを押して、収束するまで不確かな量の計算リソースを使い尽くす価値があるか？
• 成果物を見極めるセンス：数百のエージェントが論理的に厳密で構造的に壮大な成果物を提出したとき、それをなぜ信頼できるのか。その範囲と検収基準をどのように定義するのか。

検収の本質はセンスだ。自分がまず「よい」とはどういうことかを深く知っていなければ、機械が吐き出した数万行のコードの中から、どこがおかしいか、何を残し、何を切るべきかを一目で見抜くことはできない。

以前に〈人天已死〉の中で論じたように、AIが実行の閾値を下げた後、成果物の質は「どれだけ時間を投じたか」から「いかに問題を定義し、タスクを配分し、品質を管理するか」へと移行し、人間は作業員からプロジェクトマネージャーへと移動する。Ultracodeはその線のさらに一歩先だ。「タスクの配分」という行為まで、ツールが自分でやり始めている。だから手元に残るのは、より純粋な判断だ。判断する量が減ったのではなく、判断の位置が「実行の細部」から「動かす価値があるか、そして走り終わった後にどう信じるか」へと移った。この二つの問いに自動化は役に立たない。それらは本質的に価値の取捨選択であり、演算ではないからだ。

結語：真の堀

Ultracodeが画面上でその収束作業を走り終えるのを眺めながら、頭に浮かんだのは「人間は取って代わられるのか」という問いではなかった。こういう問いだった——機械が編成・実行・デバッグを引き受け、大量のコードの移植まで直接こなせるようになった今、人間が手の中に握り続けるべき能力とは何か。

答えはおそらく、より速い操作でも、より熟練した実行でもない。それらの能力は急速に自動化に吸収されている最中だからだ。今日それは百万行近いコードの処理を担える。明日、引き受ける範囲はさらに広がるだろう。かつて「実行優位」を誇りとした個人やチームは、この新しい現実を改めて理解しなければならない。純粋な実行力の重要性は、際限なく圧縮されていく。

しかしこれは必ずしも悪いことではない。それは私たちに、何が単なる忙しさで、何が本当に価値ある能力なのかを、改めて区別させる。

最後に残るのは判断力とセンスだと思う。

判断力とは、何をするに値し、何をするに値しないかを知ることだ。センスとは、ある物事がどの程度まで仕上がれば本当によくできたといえるかを知ることだ。この二つはツールの更新で自動的に生まれるものではなく、スイッチを押したからといってすぐに手に入るものでもない。それらは実際の経験から、犯した失敗から、見てきた悪い設計から、引き受けてきた困難な取捨選択から、そして長い時間をかけて積み上げた識別能力から来る。

機械は速く走り、できることはどんどん増えていく。しかし最後には、やはり人間が管理しなければならない瞬間がある。この仕事はする価値があり、このやり方は正しい、と。その能力こそが人間の堀だ。