設計理念

エージェントによる開発支援が広がるなかで、私たちは一つの問いを考え続けてきました。ソフトウェア開発をどこまで自動化でき、その自動化をどこまで大きな規模に広げられるのか。CodeDAG は、この問いに対する私たちなりの答えです。その設計を支えるのが、次の八つの理念です。

• 進められる仕事を、指示待ちにしない。
• タスクはつなぎ、コンテキストは分ける。
• 定義したとおりに、実行する。
• やり直せるから、安心して任せられる。
• 手を離しても、制御は手放さない。
• 結果だけでなく、過程も見せる。
• エージェントには、実行も指揮も任せる。
• 異なる知性で、互いの盲点を補う。

進められる仕事を、指示待ちにしない

今も多くの開発者が、エージェントとのやり取りを一往復ずつ進めています。プロンプトを送り、作業が終わるのを待ち、結果を確認してから、次に何をするかを決める。この進め方は、コマンドラインで一つずつ指示を与えていた頃のコンピューターの使い方に似ています。やがてスクリプトによって、一連の手順をあらかじめ書き、つききりにならずに実行させられるようになりました。

CodeDAG は、エージェントを使った開発にも同じ発想を持ち込みます。続けて進められる仕事をワークフローとして定義し、あとはシステムに任せます。ワークフローを投入すると、タスクは依存関係に従って実行されます。複数のワークフローをキューに並べて順次実行することもできるため、人がその場を離れても開発を進められます。

もちろん、目標を探ったり方針を議論したりするように、その都度方向を調整したい場面では、対話しながら進める方法が適しています。そのうえで私たちは、可能な仕事には継続的な実行を選びます。先へ進めるためだけに、人が何度も戻ってくる必要をなくしたいからです。これが CodeDAG の出発点です。以降の設計上の選択はすべて、継続的な実行を安心して任せられるものにするためにあります。

タスクはつなぎ、コンテキストは分ける

継続的に実行する方法は一つではありません。一つのエージェントが長いセッションの中で複数のタスクを処理し、必要に応じてコンテキストを圧縮する方法もあれば、複数のエージェントがチームを組み、実行中に情報をやり取りする方法もあります。メインエージェントが進捗に応じてサブエージェントに仕事を割り当てることもできます。CodeDAG が選ぶのは、あらかじめ定義したワークフローの中で、一つのタスクに一つのエージェントセッションを割り当てる方法です。各セッションには、担当するタスクに集中できるよう、独立性と安定性を備えたコンテキストを用意します。タスク同士の接続と実行の順序は、オーケストレーションエンジンに任せます。

コンテキストを分けることは、タスク同士のつながりを断つことではありません。各タスクは新しいセッションで始まり、必要な上流の成果をコードや文書などの明示的な成果物として受け取ります。会話全体を引き継ぐ必要も、他のタスクから次々に届く、その場限りのメッセージに頼る必要もありません。ここでいう安定とは、タスクの目標と情報源の範囲が明確であることです。扱う情報は主にそのタスクの仕事に応じて増えるのであって、ワークフロー全体の履歴に合わせて膨らむわけではありません。

一つのエージェントにすべてを任せる方法は手軽です。しかし、以前のタスクから蓄積した無関係な情報や古い前提が、今のタスクに対する判断を妨げることがあります。コンテキストを圧縮すれば情報量は減らせますが、重要な制約が抜け落ちたり、結論だけが残って、その結論が成り立つ条件が失われたりするおそれがあります。エージェント同士のリアルタイムな議論から新しい発想が生まれる一方、互いに影響を与え続けることで、実行の不確実性も増します。ソフトウェア開発では、私たちは信頼性と安定性を重視します。そのために、タスクの構成により厳密な制約を設け、会話の流れをそのまま引き継ぐ便利さや、その場の議論から着想を得る機会の一部を手放します。素早い試行や自由な創作では、そこまでする価値はないかもしれません。それでも、大規模なソフトウェア開発では、タスクを疎結合にする利点がその負担を上回ると考えています。

定義したとおりに、実行する

コンテキストを分けただけでは、タスクをどうつなぐかは決まりません。メインエージェントが実行を別々のサブエージェントに任せても、仕事をどう分割するか、いつ各タスクを始めるか、結果を誰に渡すかは、進捗を見ながらその都度判断する必要があります。この方法は柔軟で、単純な仕事や、方向を変えながら進める探索に向いています。しかし、タスクと依存関係が増えるほど、同時に把握すべき関係や状態も増えていきます。モデルの注意力だけで全体を管理しようとすると、依存関係の見落としや実行条件の判断ミスが起こりやすくなり、実際の進行が当初の計画からずれていきます。

CodeDAG では、こうした取り決めを実行前にワークフローファイルに記述し、エンジンがその定義に従って実行します。各タスクがどの結果に依存し、どの条件を満たせば先へ進めるかを、あらかじめ決めておきます。同じワークフローを事前に確認し、繰り返し実行し、実践を踏まえて改訂できます。実行のたびに、メインエージェントがその場で段取りを組み直す必要はありません。タスクと依存関係が増えれば、スケジューリングの仕事量は増えますが、エンジンが従う規則は変わりません。一つのエージェントが把握できる範囲を超える規模でも、記述された依存関係と実行条件はエンジンが一つずつ適用します。モデルが注意を向けきれないために、定義どおりの実行が崩れることはありません。

この正確さと再現性のために、私たちは柔軟性の一部を手放します。タスクの構造は事前に定義し、実行中もその構造に従います。その場の判断でノードを自由に追加・削除することはできません。ただし、固定するのはタスク間の関係であって、タスク内でエージェントが行う一つひとつの判断ではありません。仕事をどう進めるかは、引き続きタスクエージェントに委ねます。CodeDAG が想定しているのは、あらかじめ全体の進め方を設計し、システムに確実に実行させる価値があるほど複雑な仕事です。

やり直せるから、安心して任せられる

タスクの境界が明確でも、実行の段取りが正確でも、エージェントは間違えます。安心してワークフローを大きくするには、局所的な失敗を局所的に処理できる余地が必要です。一つの不適切な変更で全体が取り返しのつかない状態になるのなら、人が毎回、実行前に確認しなければなりません。それでは、継続的な実行も、人の絶え間ない確認に依存したままです。

そのため CodeDAG は、各タスクのコード変更をデフォルトで分離します。並列に動くタスクは、それぞれ専用のワークスペースとブランチで実行されます。同じファイルを同時に変更しても、どの変更がどのタスクによるものかを追跡できます。順番に実行するタスクにも個別のブランチを用意し、上流の結果を取り込んでから作業を始めることで、受け継いだ変更と、そのタスク自身の変更を区別します。分離の主な目的は、変更をタスク単位で取り消せるようにすることです。同時に、依存し合わないタスクを並列に実行できるため、全体の効率も上がります。

タスクの結果が承認される前なら、不要な変更は破棄できますし、タスク開始前のクリーンベースラインからやり直すこともできます。承認された結果は、依存関係に従って下流のタスクへ渡され、統合ブランチにマージされます。最終的にメインブランチへマージするかどうかは、オーケストレーターが判断します。この仕組みにより、ワークフローの一部で試行錯誤ができ、取り返しのつかない事態を避けるためだけに、途中で何度も人の確認を挟む必要が減ります。

デフォルトを決めることは、どちらの負担を引き受けるかを決めることでもあります。Claude Code Dynamic Workflows は、サブエージェントがデフォルトで同じチェックアウトを共有し、必要に応じて分離を有効にする方式を採ります。対して CodeDAG は、デフォルトで分離しつつ、ワークスペースを共有する選択肢も残しています。分離を選べば、ブランチ管理と結果のマージは複雑になります。私たちはその負担を、ツールの設計と実装で引き受けます。CodeDAG がブランチの管理とマージを担うことで、ユーザーは操作や管理の負担を大きく増やさずに、やり直せる安心を得られます。

手を離しても、制御は手放さない

やり直せるからといって、問題への対処を実行が終わるまで待つ必要はありません。自動化や継続的な実行を選んでも、実行中の制御を諦める必要はないはずです。どこで確認を挟むかを決め、問題に気づいたときには介入できる。そのためだけに、常に付き添う必要はないと考えています。

制御には、あらかじめ組み込むものと、必要になった時点で行うものがあります。ワークフローには、エージェントによるレビューをタスクとして組み込んだり、重要な箇所に手動レビューのゲートを設けたりできます。結果を検証してから、先へ進めるかどうかを判断するためです。想定外の状況では、ワークフローや個々のタスクを一時停止・再開し、必要なら実行を中断したり、タスクのセッションに追加の指示を送ったりできます。確認する場所を事前に決めることと、途中で介入する手段を残すことは、両方とも必要です。後者があれば、設計時点ですべての問題を予見しておく必要はありません。

モデルが進歩し、ワークフローの設計が改善されれば、人による検証や臨時の介入は減っていくと期待しています。ただし、介入の頻度が減ることと、介入する能力を失うことは別です。長い間、人が手を加えずに動かせるワークフローでも、必要なときに介入できる手段は残しておくべきです。いざというときに制御できるからこそ、普段は安心して任せられます。

結果だけでなく、過程も見せる

適切に制御するには、まず状況が見えていなければなりません。エージェントが実行中だと分かるだけでも、最終結果だけを見ても、介入が必要かどうかを判断できないことがあります。今何をしているかをリアルタイムで把握でき、結果に至った経緯を後からたどれることが重要です。

CodeDAG は、ワークフローとタスクの状態に加え、エージェントの全出力、ツール呼び出し、状態メッセージを含むリアルタイムログを提供します。タスクのネイティブセッションに入って、実際のやり取りを確認することもできます。実行記録は振り返りや監査に使えます。どの段階で問題が生じたのか、タスクに必要な情報が欠けていなかったかを調べる手がかりになります。実行過程が見えることは、今介入すべきかを判断する助けになるだけでなく、次のワークフロー改善にもつながります。

将来、モデルの能力が向上して人の介入がほとんど必要なくなっても、私たちは詳細な観察と制御の手段を残します。自動運転が進歩すれば、ブレーキやハンドルを使う機会は減るでしょう。しかし、それは取り外す理由にはなりません。システムが複雑になるとしても、必要なときに人が介入でき、何が起きたかを後から検証できる仕組みを、自動化の安全を支える備えとして維持します。

エージェントには、実行も指揮も任せる

ワークフローの定義、実行の観察、必要な介入を、すべて人が担う必要はありません。ここまで述べてきた正確さは、確定したワークフローをどう実行するかについてのものです。ワークフローを作る段階の自律的な判断まで制限するものではありません。人がワークフローを書いてもよいですし、エージェントが目標を理解し、タスクを分割し、依存関係を設計して、自分の計画を明示的な実行手順にしてもかまいません。エージェントには、個々のタスクの実行だけでなく、人に代わるオーケストレーションも任せられます。

オーケストレーションエージェントの仕事は、ワークフローの投入で終わるとは限りません。許可された範囲内で、CodeDAG の観察・制御機能を使い、進捗の追跡や結果の検証を続けられます。必要に応じてやり直しを調整し、実行に介入し、後続の仕事を組み立て、目標の達成まで管理できます。定義済みのワークフローはエンジンが実行し、計画と管理はオーケストレーションエージェントが継続して担う。そうすることで、人が一つひとつの進行を見守る必要はなくなります。

一見すると、これはメインエージェントがサブエージェントに直接仕事を割り当てる方法と似ています。どちらも計画と調整をエージェントが担う点は同じです。ただし、直接割り当てる場合は、どのタスクを始め、どの結果を待ち、その結果を次のタスクにどう渡すかを、メインエージェントが会話の中で毎回判断しなければなりません。CodeDAG を使う場合は、これらの取り決めをワークフローに記述します。依存関係に従ったタスクのスケジューリング、ブランチによる分離、結果の集約は、エンジンが担います。オーケストレーションエージェントは、観察と制御の手段を備えた正確な実行システムを使って、実行状況を確かめ、判断し、必要に応じて介入します。

道具の活用によって、人はより大きな規模で仕事をまとめ、実行できるようになってきました。オーケストレーションのための道具も、エージェントに同じ力を与えられると考えています。一つの会話の中だけでは調整しきれない規模の仕事を、管理できるようにする力です。正確な実行システムは、エージェントの自律性と対立するものではありません。むしろ、その計画や判断をより多くのタスクに反映できるようにし、人が自分で段取りを組み、調整しなければならない仕事を減らします。

異なる知性で、互いの盲点を補う

エージェントが実行だけでなくオーケストレーションも担うようになると、ソフトウェア開発の自動化はさらに進み、その規模も大きくなります。一方で、人が直接確認できる部分の割合は小さくなっていきます。システム自体の制約に加えて、ほかに誰がエージェントの仕事を検証し、その判断を確かめられるでしょうか。私たちの答えは、異なる能力や視点を持つ別のエージェントです。

CodeDAG が単一のエージェントハーネスやモデルに依存しないのも、そのためです。ユーザーはタスクに合った実行者を選べますし、同じワークフローの中で Claude Code と Codex に仕事を分担させ、互いにレビューさせることもできます。一つのエージェントの判断を、最終結論にする必要はありません。別のエージェントが違う角度から検証し、その判断の前提を問い直し、見落とされた問題を見つけられます。

相互検証の価値は、エージェントの数だけでなく、判断の違いにあります。明確なタスクの境界を保ちながら、協力すると同時に、互いの結論を疑うことができます。それぞれが独立して判断を形成し、その後に成果物を突き合わせて検証する。そうすれば、早い段階で互いの考えに引きずられず、異なる視点を保てます。コンテキストの独立性は、実行を安定させるだけでなく、独立した検証の余地も残します。結果を一つずつ確かめる役割を、人だけが担う必要はなくなります。

複数のハーネスやモデルを支えるには、連携と保守のコストがかかります。それでも私たちは、ユーザーが仕事に合った実行者と検証者を選べる自由を保ちます。多様性には、単なる分業以上の価値を期待しています。異なるエージェントの能力、視点、限界が互いに作用することで、それぞれが単独で働く場合を上回る成果につながる可能性があります。人の注意がすべての工程に行き届かなくなっても、システムによる制約と、異なるエージェント同士の検証を組み合わせれば、より大きな規模の継続的な開発を支えられます。