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を十のエージェントに同時に割り振ることはできない）、黙って一歩一歩こなしていく。同じスイッチでも、問題が異なれば自動的に異なる戦略が生まれる。画面を見つめながら最初に読み取ったシグナルはそこにある——Ultracodeはオンになっていたが、使うために使おうとはしなかった。

タスクが十分に大きければ、AIが自らエージェントチームを編成する

タスクの規模が大きくなって初めて、Ultracodeは本来の力を発揮する。同一セッション内でスクリプトを生成し、数十から数百の「サブエージェント」を展開して、それぞれがコードの一部を並列に処理する。

さらに精妙なのが検証の方法だ——対抗的な検証である。一方のエージェント群が異なる角度から問題に攻め込み、もう一方のグループが前者の結論を専門的に論駁する。この攻防がシステム内部で繰り返され、答えが収束して穴がなくなるまで続く。

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

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

Bun（著名なJavaScript実行環境）の作者Jarred Sumnerは、極端なケースを公開している。このメカニズムを用いて、Bunのコア部分（約100万行のコード）をZigからRustへ移植したのだ。

かつてこれは、ベテランエンジニアのチームが数四半期かけても必ずしも完遂できない規模の作業だった。今やこのメカニズムで、10日以内にマージ可能な結果が得られた。（Sumnerは、これはあくまでも一つの実験であり、既存のZig版を置き換えるものではないかもしれないと述べている。）

自分の核心的な競争力だと思っていたものが、Claudeの標準機能になった

この機能を見たとき、私は複雑な心境だった。なぜなら、この「マルチエージェント協調」をつい最近、苦労して手動で構築したばかりだったからだ。

かつて——といっても2ヶ月前のことだ——AIの異なるウィンドウをチーム協働に近い形で動かすため、プロセスをいくつかの明確な役割に分解していた。Chatが検索と戦略判断を担い、Coworkが統合と実行を担い、Codeがプログラムと技術的な検証を担う。各フェーズ間では、ドキュメントとメモリシステムを通じて状態を同期させ、情報の断絶・重複・競合を防いでいた。

この分業は一種のハーネスエンジニアリングだ。AIに問題を投げ込むだけでなく、AIを制約・誘導・分業・引き継ぎ・検証できる作業システムを設計することだ。

かつて私はこれが独立した働き手としての堀だと思っていた。

Ultracodeはその堀を直接埋めた。かつては人間が綿密に計画を立て、手動で隔離し、慎重にウィンドウを切り替えることでしか成立しなかった高度な協調技術が、今やソフトウェアの基盤にある普通のボタンになった。これが意味することは一つ——「AIを手動で編成するスキル」の技術的優位性は、すでに消滅した。

実行力がタダになったとき、希少になるのは何か？

最も頭を使う「分業と編成」をツールが引き受け、しかもコストがオープンエンド（上限なしで、答えが安定するまで走り続ける）であるなら、人間の立ち位置は一歩後退する。

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

• 計算リソースの判断：目の前の問題を徹底的に解くことは、スイッチを押してエージェント群に不確定な計算リソースを消費させるに値するか？
• 成果物のセンス：数百のエージェントが論理的に緻密で規模の大きなアウトプットを提出したとき、それをどう信頼するか。範囲と検収基準をどう定めるか？

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

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

結語：本当の堀

Ultracodeがあの仕上げ作業を画面で走り終えるのを見届けながら、私の中に浮かんだのはより具体的な問いだった。機械が編成・実行・デバッグを引き受け、大量のコード移植を直接完了させるようになったとき、人間が手に握り続けるべき能力とは、いったい何か？

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

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

最後に残るのは、判断力とセンスだ。判断力とは、何をすべきで何をすべきでないかを知ること。センスとは、何かをどこまで仕上げれば本当に「成し遂げた」と言えるかを知ることだ。この二つはツールのアップグレードで自動的に生まれるものではなく、スイッチひとつで即座に手に入るものでもない。それは本物の経験から、犯した失敗から、見てきた悪いデザインから、難しい取捨選択から、そして長い時間をかけて蓄積された弁別能力から生まれる。

機械は速く走り、できることはますます増えていく。しかし「やるべきか否か」「正しくできているか否か」は、依然として人間が見届けなければならない。それこそが、埋めることのできない堀だ。