はじめに
クラウドエース株式会社 CTO室 akane です。
ハーネスの整備やループエンジニアリングなど、AI エージェントを使ったソフトウェア開発では、「いかにエージェントを自走させるか」が注目されています。
人間が逐一指示しなくても、エージェント自身が考え、実装し、テストし、修正し、仕事を完結させてほしい。
では、エージェントは何に向かって自走すればよいのでしょうか。
エージェントの自律性がどれだけ高くなっても、作ってほしいものの「あるべき姿」が曖昧であれば、必ずしも人間が意図した方向へ進んでくれるとは限りません。
弊社では、AI 駆動開発において、この「あるべき姿」を表現する仕組みとしてソフトウェア DNA という考え方を取り入れています。
そして私は最近、このソフトウェア DNA とクラウドエージェントの組み合わせが非常に有効であると感じています。
この記事では、
- AIDD における「探索」と「収束」
- ソフトウェアの「あるべき姿」を定義するソフトウェア DNA
- 私が最近実践している AIDD の進め方
- 自然言語からコードへ収束させる際の課題
- クラウドエージェントの「自己完結力」
- ソフトウェア DNA とクラウドエージェントをどう組み合わせるか
について整理します。
AIDD における「探索」と「収束」
まず、弊社における AI 駆動開発、AIDD（AI-Driven Development）の考え方から説明します。
AI コーディングの文脈では、Vibe Coding と SDD（Spec Driven Development）というアプローチがあります。
弊社では、この 2 つをそれぞれ「探索」と「収束」という観点から捉えています。
Vibe Coding は「探索」
弊社では、Vibe Coding の目的を「要件や仕様を正しく実装すること」ではなく、要件や仕様そのものを発見することとして捉えています。
ソフトウェア開発において、最初からすべての仕様を決められるわけではありません。
たとえば UI・UX では、実際に画面を作り、それを見たり操作したりして初めて「こちらの方が使いやすい」「この導線では分かりにくい」と判断できることがあります。
他にも
- 想定している方式で性能要件を満たせるのか
- 外部 API が期待どおりに動作するのか
- ドキュメントに書かれていない部分が実際にはどう動くのか
といったことは、実際に作って動かしてみなければ分からない場合があります。
このように、未知のものを実装を通じて発見していく動きを、弊社では「探索」と捉えています。
SDD は「収束」
一方、SDD については、確定した要件や仕様から逸脱せず、意図した状態へコードを近づけていくものとして捉えています。
すでに「こう作る」と決まっているのであれば、AI に自由な発想を求める必要はありません。
決まった仕様に対して実装を近づけていく。
これが「収束」です。
探索と収束は二者択一ではない
実際のソフトウェア開発では、探索と収束のどちらか一方だけを選択するわけではありません。
ソフトウェアの根幹に関わる仕様のように、初期段階でかなり明確に決められるものもあります。
一方で、開発を進める中で新たな未知が見つかり、探索が必要になることもあります。
実際に作って初めて、
「ここは仕様として決める必要があった」
と気付くこともあります。
つまり、実際の開発では、
探索によって未知を発見し、決まったものを収束させる。必要になれば再び探索し、また収束させる。
このように、探索と収束を状況に応じて行き来しながら、徐々に意図したソフトウェアへ近づけていくことになります。
つまり、AIDD において重要なのは「探索と収束のグラデーションを乗りこなすこと」だと考えています。
では、この探索と収束をどうやってつなげるのでしょうか。
ここで登場するのが「ソフトウェア DNA」です。
「あるべき姿」を刻むソフトウェア DNA
弊社では、ソフトウェアのあるべき姿や決め事を定義したファイル群を「ソフトウェア DNA」と呼んでいます。
具体的には、
- 要件
- 仕様
- 設計
- ユースケース
- 用語
- アクター
など、ソフトウェアを作るうえで必要となるさまざまな決め事を表現します。
重要なのは、ソフトウェア DNA が単なる設計ドキュメントではなく、その時点においてソフトウェアがどうあるべきかを表現するものだということです。
確定した仕様、たとえば RFP に記載された内容や、ステークホルダーとの間で合意された事項は DNA へ定義します。
そして、探索によって新たに分かったことも DNA へ反映します。
そのうえで、DNA に記述された「あるべき姿」へコードを収束させます。
整理すると、基本的なアプローチは次の 3 つです。
- 決定事項 → ソフトウェア DNA に定義する
- 探索結果 → ソフトウェア DNA に反映する
- ソフトウェア DNA → コードへ収束させる
ソフトウェア DNA の 3 つのレイヤー
ソフトウェアを構成する決め事は、すべて同じ速度で変化するわけではありません。
そのため、変化速度に応じて DNA を大きく 3 つのレイヤーで整理しています。
Layer 1：普遍的で、ほとんど変わらないもの
ソフトウェアにおける憲法のようなものです。
Layer 2：全体に効き、ゆっくり変わるもの
全体設計や方針などが該当します。
Layer 3：局所に効き、頻繁に変わるもの
開発の中で頻繁に変化していく要件や例外などが該当します。
さらに、同じレイヤーの中でも、それぞれの決め事の安定度は異なります。
そのため、「安定したもの」「進化中のもの」「ドラフトのもの」といったステータスによって区別して管理します。
これにより、ソフトウェアのあるべき姿を明文化しながらも、それを固定化せず、開発の進展に応じて継続的に更新できます。
これが弊社における基本的な AIDD です。
ただし、このような方針、アプローチは存在するものの、これを具体的に開発の現場でどう実践するのかについては、現在も模索中であり、決定的な方法があるわけではありません。
ここからは、その中で私自身が最近どのように実践しているかを紹介します。
私が最近行っている AIDD の進め方
新規ソフトウェアを開発するケースを例にします。
私は最初に、ChatGPTやClaudeのような汎用的な LLM インターフェースを使い、
- 最適な実現アプローチ
- アーキテクチャ
- 技術スタック
などを調査・整理します。
必要であればDeep Researchのような機能も利用し、まずはコアとなる外部仕様を整理します。
この段階で最初からコーディングエージェントを中心に使わないのは、私自身の体感として、汎用的な LLM インターフェースの方が Web 上の情報を広く調査しながら考えを整理する用途に向いている（Web グラウンディング性能が高い）と感じているためです。
コアとなる外部仕様を整理したら、それをソフトウェア DNA へ落とし込みます。
ここからはコーディングエージェントを中心に作業します。
弊社には、AIDD を実践するためのディレクトリ構成やルール、Skill などを含むテンプレートリポジトリがあり、そこへコア外部仕様を DNA として定義していきます。
考えを整理・具体化する随所で grill-me を使う
ここで私が重要だと感じているのが、ソフトウェア開発の中で、自分の考えや意図を整理・具体化するさまざまな場面で grill-me（grilling） という Skill を使うことです。
grill-me は、ユーザーとの対話を繰り返しながら、考えている内容や意図を掘り下げ、曖昧な部分や考慮できていなかった観点を洗い出すための Skill です。
私は、実装方針を整理するときや、実装計画を作成するときなど、人間が考えていることを明確にし、その後のエージェントの作業に必要な前提や判断を具体化する場面で広く使用しています。
たとえば、DNA に記述された内容が曖昧であれば、コードへ収束させる段階で LLM がその空白を推測し、自由解釈によって埋めることになります。同様に、実装計画に曖昧さや考慮漏れがあれば、実装段階でエージェントが判断を補うことになります。
そのため、実装そのものに入る前のさまざまな段階で問いを繰り返し、人間側の意図や判断、まだ明確になっていない論点を可能な限り表面化させることが重要だと考えています。
自分が認識・把握できていないことには答えない
ただし、grill-me で問いを繰り返していると、自分では答えられない質問も出てきます。
そうした問いに対して、推測やその場の判断で無理に答えるのではなく、なぜ答えられないのかに応じて、次のアクションを変えるようにしています。
私は、こうした質問を大きく 3 種類に分けています。
- 理解できない
- 自分では決められない
- 実装しないと分からない
「理解できない」のであれば、その問いについて別セッションで深掘りします。
コーディングエージェントのSide Chatsのような仕組みを使えば、メインの作業コンテキストを汚さず、その論点だけを掘り下げられます。
「自分では決められない」のであれば、ステークホルダーに確認すべき質問として整理します。
そして「実装しないと分からない」のであれば、探索事項として Backlog、つまり探索チケットにします。
この 3 つに共通しているのは、
自分が認識・把握できていないことには、無理に答えない
ということです。
分からないことや、自分では判断できないこと、実際に試さなければ分からないことを曖昧なまま進めてしまうと、その後の DNA 作成や実装方針の整理、実装計画、実装といった工程で、自分が意図しない方向へ進んでいくことになり得ます。
そのため、答えられない問いが出てきたときには無理に回答するのではなく、「理解を深める」「ステークホルダーに確認する」「探索する」といった適切なアクションへつなげるようにしています。
すべての問いにその場で答えてエージェントを先へ進ませることより、人間側で認識・判断できていることと、まだできていないことの境界を明確にしたうえで、次の工程へ進むことが重要だと考えています。
コアとなるDNAを作った後の進め方
ここまで説明してきた、最初にコアとなる外部仕様を整理し、grill-meを使いながら曖昧な点や考慮できていない点を洗い出し、必要に応じて「理解を深める」「ステークホルダーに確認する」「探索する」といったアクションにつなげながら、コアとなるDNAを作っていくところまでが、開発の初期段階で私が行っている具体的な進め方です。
コアとなるDNAをある程度作った後は、基本的には先ほど説明した弊社のAIDDの考え方に沿って開発を進めます。
ただし、ここから先も必ず
探索 → DNAの更新 → 収束
という順番を繰り返すわけではありません。
開発を進める中で新たな不確実性や、実際に試さなければ分からないことが出てきたのであれば、再び探索を行い、その結果をDNAへ反映します。
一方で、すでに内容が明確になっているのであれば、探索を行う必要はありません。新たに決まった内容をそのままDNAへ反映し、コードへ収束させることもあります。
収束を進めた結果、それまで認識できていなかった論点が見つかれば、必要に応じて探索やステークホルダーへの確認に戻ることもあります。
このように、コアとなるDNAを作った後は、その時点で必要な探索・DNAの更新・収束を行き来しながら、ソフトウェアの「あるべき姿」と実装を徐々に近づけていきます。
人間がレビューする対象の重心が変わった
このような開発を行うようになってから、レビューする対象の重心も少しずつ変わってきました。
以前であれば、PR が上がってくると、その実装コードそのものを詳細に確認することに大きな時間を使っていました。
現在も実装コードのレビューは行いますが、それ以上に、
ソフトウェアの「あるべき姿」が DNA へ正しく表現されているか
を見ることを重視しています。
自分の意図が DNA へ正しく落とし込まれている。
その DNA に対してコードが収束している。
つまり、実装コードそのものだけを見るのではなく、「意図 → DNA → 実装」という一連の整合性を確認することへ、レビューの重心が移ってきたということです。
この構造を作れるのであれば、人間がレビューすべき対象も少しずつ変わってくるのではないかと感じています。
ただし、ここで新たな問題が発生します。
「DNA が正しければ、コードも必ず正しくなるのか？」
という点です。
DNA からコードへ「収束」させるときに残る 2 つの不確実性
ソフトウェア DNA は、基本的には自然言語で記述されています。
そして収束では、その自然言語を LLM が解釈し、コードへ変換します。
ここには大きく 2 つの不確実性が残ります。
1. DNA にない部分を LLM が自由解釈する
1 つ目は、DNA には明記されていないものの、実装上は何らかの判断をしなければならない部分です。
たとえば、あるエラー ケースについて DNA に何も記載されていなかったとしても、実装上は何らかの挙動を決めなければならないことがあります。
そのとき、LLM は自分なりに解釈して穴を埋めます。
その実装が技術的には正しくても、人間が意図していたものとは異なるかもしれません。
先ほど説明した grill-me による深掘りは、この自由解釈が発生する余地を小さくするためにも有効です。
ただし、どれだけ DNA を詳細にしても、自由解釈を完全になくすのは難しいと考えています。
そのため、収束後には、
「DNA に明記されていない部分について、何を自由解釈したのか」
を確認できる仕組みが必要になります。
2. 自然言語からコードへの変換にはランダム性がある
もう 1 つは、自然言語を LLM が解釈してコードへ変換する以上、一定のランダム性が伴うことです。
同じ DNA を渡したとしても、常に 100％同一で正しい実装が生成されるとは限りません。
弊社のテンプレートリポジトリには、これらの問題を確認するための health-check という Skill があります。
ここでは主に、
- 実装コードが DNA に準拠しているか
- DNA にない内容を自由解釈していないか
をチェックします。
これによってリスクを一定下げることはできます。
ただし、自然言語からコードへ変換している以上、それだけで完全に決定論的な収束を実現できるわけではありません。
自然言語の DNA とテストによる決定論的な DNA
この問題に対して、私はテストが重要になると考えています。
ソフトウェア DNA に記述された内容のうち、テストで表現できるものを、可能な限りテストとしても表現する。
そうすれば、テストとして記述できた範囲については、DNA と実装の整合性を決定論的に確認できます。
もちろん、DNA のすべてをテストへ落とし込めるわけではありません。
そのため私は、
- ドキュメントによって、自然言語で「あるべき姿」を定義する
- テストによって、決定論的に「あるべき姿」を検証する
という 2 本の構造で収束させるのがよいのではないかと考えています。
個人的には、これを DNA の二重らせんのように捉えています。
1 本目が、ドキュメントとして表現された DNA。
もう 1 本が、その DNA のうちテスト可能なものを表現したテストファイル。
この 2 つによって、自然言語の柔軟性と、テストの決定論的な性質の両方を使いながら、コードを「あるべき姿」へ近づけていくイメージです。
ここまでが、ソフトウェア DNA についての話です。
ここから、クラウドエージェントとの関係を考えます。
なぜ、クラウドエージェントなのか
最近、クラウドエージェントを推奨する発信を目にする機会が増えてきました。
私自身も、以前はCursorを使ったローカル開発が中心でしたが、最近では開発の 8 割以上でクラウドエージェントを利用しています。
これは単に、エージェントを動かす場所がローカルからクラウドへ変わったというだけではありません。
私自身の開発スタイルも、人間とエージェントが対話しながら一緒に作る形から、ある程度まとまった仕事をエージェントへ委譲し、できるだけ自己完結してもらう形へ重心が移ってきました。
では、なぜクラウドエージェントを使うのでしょうか。
この記事では便宜上、
クラウド上に用意された独立した実行環境で、エージェントが開発作業を行う仕組み
を「クラウドエージェント」と呼びます。
クラウドエージェントの利点は複数ありますが、私が感じている一番の強みは「自己完結力」です。
ここでいう自己完結力とは、
人間やローカル PC へ逐次依存せず、環境準備から実装、実行、検証、修正までを、可能な限りエージェント自身で閉じられること
です。
この自己完結力を支えている要素として、大きく 3 つあると考えています。
1. 独立した実行環境を持っている
まず大きいのが、エージェント自身が独立した開発環境を持っていることです。
たとえばCursor Cloud Agentsでは、独立した VM 上に、
- Repository
- Runtime
- Dependencies
- Tools
- Secrets
- Network Access
などを含む開発環境を用意できます。
そのためエージェント自身が、
依存関係を導入する
→ コマンドを実行する
→ アプリケーションを起動する
→ ビルド・テストする
→ 結果を確認する
→ 修正する
というサイクルを、自分の環境内で回すことができます。
また、その環境がローカル PC から隔離されていることも重要です。
一時ファイルを生成したり、パッケージを追加したり、開発サーバーや Docker コンテナを立ち上げたりしても、基本的にはエージェント専用の環境内で行われます。
これによって、人間が普段使用しているローカル環境へ直接影響を与えずに、エージェントへ比較的大きな裁量を渡しやすくなります。
ただし、ローカル環境から隔離されていることと、クラウド上の実行環境が安全であることは別の話です。
クラウドエージェントがコードを扱い、Secrets やネットワークアクセスを利用できる環境になる以上、Secrets の管理や権限制御、ネットワーク制御など、エージェントにどこまでアクセスを許可するかというセキュリティ設計は別途必要になります。
もちろん、ローカルでも分離・隔離するための仕組みを用意すれば、同様の環境を実現することはできます。
そのため、「ローカルエージェントではできない」という違いではありません。
ただしローカルでは、その隔離環境の構築や、依存関係、リソース、作業領域などの管理を人間側で考慮する必要があります。
一方、クラウドエージェントでは、独立した実行環境そのものがサービスの一部として提供される。
ここが大きな違いだと感じています。
2. 人間の継続的な操作を前提としない
もう一つ重要なのが、クラウドエージェントが、人間の継続的な操作を前提としない実行形態であることです。
CursorはCloud Agentsについて、ユーザーの操作なしで実行でき、ローカルエージェントよりも長時間のタスクを担えると説明しています。さらに、クラウドではエージェントが途中で停止しても、人間が確認に戻るまで何時間もそのまま待ち続ける可能性があるため、より自律的に動くよう促しているとしています。
つまり、クラウドエージェントは単にローカルエージェントをクラウド上で動かしているだけではなく、人間が常に隣で状況を確認し、都度介入することを前提としないため、できる限り自分で判断し、作業を継続できる設計となっています。
独立した開発環境と、人間の継続的な介入を前提としない設計。
この 2 つが組み合わさることで、クラウドエージェントはタスクを自己完結しやすくなると捉えています。
3. PR レビューから修正までを自動化する仕組みがある
自己完結性を支えるもう一つの要素が、PR を起点とした自動化です。
たとえばDevinでは、Devin ReviewとAuto-Fixによって、PR をレビューし、検出した問題に対するコード変更を提案・適用できます。
Cursorでは、Bugbotが PR をレビューして問題を検出し、Bugbot AutofixがCloud Agentを起動して修正を行う仕組みがあります。
重要なのは、単に「1 回のエージェントセッションでレビューと修正ができる」ということではありません。
PR の作成・更新やレビュー結果といった外部イベントを起点として、エージェントが再び動き出せることです。
ローカルエージェントでも、一度のセッション内でレビューして修正することはできます。
一方で、未来の PR 更新やレビュー完了を待ち、そのタイミングで再び作業を始めるには、人間の介入や別途オーケストレーションが必要になります。
クラウドエージェントの周辺には、こうしたイベントを起点としてレビュー、修正、再実行を人間が逐一介入せずに続けるための仕組みが提供されています。
私はこれも、クラウドエージェントの自己完結力を高める重要な要素だと考えています。
ソフトウェア DNA × クラウドエージェント
ここで、ソフトウェア DNA とのつながりが出てきます。
クラウドエージェントは、以前からある程度自己完結して機能を作りきることができました。
しかし、以前の私はクラウドエージェントをそれほど多く使っていませんでした。
理由は、
「何を作ってほしいのか」を十分に渡す方法がなかった
からです。
エージェント自身に実装力があり環境もあるが、目指す先が曖昧なため意図したものが作られない、といったケースが多かったです。
一方、ソフトウェア DNA では、
「このソフトウェアは、どうあるべきなのか」
をファイルとして表現します。
ここで、
- 向かうべき「あるべき姿」をソフトウェア DNA が与える
- そこへ向かって仕事を閉じる自己完結力をクラウドエージェントが持つ
という組み合わせが成立します。
そのため、ソフトウェア DNA が存在することを前提としてクラウドエージェントの自己完結性を組み合わせることは、非常に相性が良いのではないかと考えています。
特に、AIDD における「収束」をクラウドエージェントに担わせることは有効だと感じています。
仕様や設計がかなり明確で、DNA に目指すべき状態が表現されている。
その状態であれば、人間との細かなラリーを挟まず、クラウド上で実装・実行・検証・修正を繰り返してもらいやすくなります。
つまり、
「あるべき姿」が明確であるほど、自己完結できる仕事としてエージェントへ渡しやすくなる
ということです。
すべてをクラウドエージェントに任せればよいわけではない
ここまでクラウドエージェントを推してきましたが、すべての仕事をクラウドへ移すのがよいとは考えていません。
ローカルエージェントの方が向いている作業もあります。
私は、ローカルとクラウドを二者択一として考えるのではなく、
その仕事にどの程度、人間との対話や介入が必要なのか。どの程度、エージェント自身で完結できるのか。
という度合いで捉えるのがよいと考えています。
grill-me のような長い対話はローカル優位
一つが、grill-me のように、人間とエージェントが何度も対話を繰り返す作業です。
grill-me を使って仕様や設計を詰めていると、数十ターンにわたってラリーすることがあります。
多いときには 50 ターン以上になることもあります。
これは品質というより、コスト面の問題と捉えています。
私はクラウドエージェントにおいては主にDevinを使っていますが、このように会話だけを複数ターン続ける用途では、Cursorなどローカルで動かすエージェントと比較して、コストパフォーマンスが悪く感じることがあります。
クラウドエージェントは、「何かを実装して、実行して、検証する」という仕事に大きな強みがあります。
逆に、まだ実装へ進まず、人間との対話そのものが中心になっている段階では、ローカルエージェントの方が優位なケースが多いと考えます。
UI・UX の調整も人間の介入が多い
UI・UX も、現時点ではローカルエージェントを使うことが多い領域です。
UI 開発では、
画面を作る
→ 人間が見る
→ 操作する
→ 修正を指示する
→ もう一度見る
というラリーが頻繁に発生します。
もちろんクラウドエージェントでも、スクリーンショットを撮る、ブラウザを操作する、動画を残すといったことは可能です。
しかし、人間が数十秒・数分単位で画面を確認して細かく方向修正し続けるのであれば、その都度クラウド上で確認結果を待つより、手元で直接操作できた方が速いケースが多いです。
また、Cursorには、実際の画面を直接指し示して UI 修正を指示できるDesign Modeといった UI 開発に特化した機能もあります。
こうした点を加味すると、UI・UX 周りのように人間との対話や確認が頻繁に発生する作業については、対話型、つまりローカルエージェントの方が向いていると考えています。
「どちらのエージェントか」ではなく「どんな仕事か」で考える
そのため、
-
grill-meのような、人間との対話ラリーが多い仕事 - UI・UX のような、人間の確認と判断が頻繁に必要な仕事
はローカルエージェント寄り。
一方、
- 仕様が明確
- あるべき状態を DNA に表現できている
- エージェント自身で実装・実行・検証できる
といった仕事は、クラウドエージェント寄りです。
なお、探索だからローカル、収束だからクラウド、と単純に分けるものではありません。
探索でも、実装・検証までエージェント自身で進められるものはクラウドに任せられます。一方、UI・UXのように人間の確認や方向修正が頻繁に必要なものは、ローカルの方が向いています。
一方収束は、DNAによって「あるべき姿」が明確になっているため、基本的にはクラウドエージェントと相性がよいと考えています。
つまり、探索か収束かではなく、人間の介入がどの程度必要か、エージェント自身でどの程度完結できるかで使い分ける、という考え方です。
まとめ
AI エージェントの能力が上がり、より大きな仕事を任せられるようになるほど、「エージェントをどう自走させるか」が重要になります。
しかし、自走できることと、正しい方向へ進むことは別です。
エージェントへ大きな裁量を渡すのであれば、その前に、
何を目指すべきなのか
ソフトウェアがどうあるべきなのか
を表現する必要があります。
その役割を担うのが、弊社で取り組んでいるソフトウェア DNA です。
そして「あるべき姿」を DNA として明確にできるほど、自己完結力の高いクラウドエージェントへ仕事を渡しやすくなるのではないかと、私は考えています。
この記事で伝えたかったことを、最後に 3 つにまとめます。
- 探索と収束のグラデーションを乗りこなす
- AI を自走させるなら、ソフトウェアの「あるべき姿」をソフトウェア DNA に刻む
- 自己完結できる仕事をクラウドエージェントへ
AI エージェントが今後さらに自律的になっていくほど、「エージェントをどう動かすか」ではなく、「どこへ向かわせるか」を定義することがより重要になってくるでしょう。
関連資料
弊社における AIDD の考え方やソフトウェア DNA については、以下のコラムで詳しく紹介しています。
ご興味のある方は、是非ご一読ください。
Discussion