こんにちは。クラウドエース第一開発部のタンマイです。 AIと対話しながら試作品を作ると、「本当はこうしたかった」という発見が生まれます。ただ、その発見がチャットや担当者の記憶に残るだけでは、次の実装で同じ意図が守られるとは限りません。 こうした発見や合意を次の開発へ引き継ぐために、クラウドエースが提唱しているのが「ソフトウェアDNA」です。ソフトウェアの「あるべき姿」を決めごととして残し、実装が意図から外れていないかを確かめるための基準にします。 本記事では、AI駆動開発の全体像から一歩踏み込み、ソフトウェアDNAに何を残し、どう整理し、開発の中で使い続けるのかを紹介します。 目次 Toggle ソフトウェアDNAとはバイブコーディングと仕様駆動開発をつなぐ役割ソフトウェアDNAに何を記録するのか三つのレイヤーと安定度で決めごとを整理する仮想例：社内申請システムで考えるソフトウェアDNAソフトウェアDNAを使ったレビューと品質確認書いて終わらせないための運用ソフトウェアDNAで変わる、人の役割まとめ：試したことを、次に使える決めごとへ ソフトウェアDNAとは ソフトウェアDNAとは、クラウドエースが提唱する、ソフトウェアの「あるべき姿」を要件・仕様・設計などの決めごととして整理し、開発の基準として使い続けるための考え方です。決めごとは、AIと人間が参照できるファイルとして管理します。 特徴は、記録して終わりにしないことです。実装が決めごとに沿っているかを確認し、新しい発見や合意があれば更新する。開発を続ける中でも、判断の基準として活用します。 DNAという名前に込めた、あるべき状態を守る発想 ソフトウェアDNAで重要なのは、ソフトウェアの「あるべき状態」を決めごととして残すことです。何を守り、何を修正すべきかを判断するには、その基準となる状態が明らかになっている必要があります。 そのため、DNAに残すのは「現在のコードがどう動くか」だけではなく、「どう動くべきか」です。動いているプログラムにも、意図しない振る舞いや仮の対応はあり得ます。現状をそのまま正しいものとするのではなく、あるべき状態に照らして実装を確かめます。 仕様書の代わりではなく、仕様を使い続ける考え方 要件定義書や設計書と、ソフトウェアDNAは対立するものではありません。既存の文書に書かれた合意事項も、開発の基準として参照・更新されるなら、DNAの内容になり得ます。 違いを考える際は、文書の名前よりも使い方に注目すると分かりやすくなります。実装前に読むだけなのか、変更やレビューのたびに照合するのか。新しい種類の資料を増やすことではなく、決めた内容が開発に反映され続ける状態を目指します。 チャットの履歴と、採用した決めごとを分ける AIとのチャットは、検討の経緯をたどる材料です。ただし、試しに出した案、却下した案、採用した案が同じ会話に混在することもあります。履歴が残っているだけでは、どれを現在の前提にすべきかが曖昧です。 そこで、検討の過程と、採用した決めごとを分けて考えます。会話を丸ごと保存することと、DNAを整えることは同じではありません。次の作業を始める人やAIが、採用済みの内容と検討中の案を見分けられる形にします。 参考：クラウドエース公式note「探索と収束を『同じ仕組み』で回す」 バイブコーディングと仕様駆動開発をつなぐ役割 ソフトウェアDNAは、試して発見する「探索」と、決めた内容に実装を近づける「収束」で共有する基準です。クラウドエースでは、バイブコーディングを探索、仕様駆動開発を収束という観点から捉えています。 両者は、どちらか一方を選ぶ関係ではありません。まだ分からないことを試し、分かったことを決めごとにする。その決めごとを実装と照合することで、試行錯誤を積み上げていきます。 要素 クラウドエースでの捉え方 開発での役割 バイブコーディング 探索 動くものを試しながら、要件や仕様を発見する ソフトウェアDNA あるべき状態を示す決めごと 発見や合意を残し、以降の開発の基準にする 仕様駆動開発 収束 決めごとに沿うよう、実装を具体化・修正する 探索の成果を「作って終わり」にしない 探索で持ち帰りたいのは、試作品だけではありません。使ってみて分かった業務上の例外や、採用すべき振る舞いも成果です。それらを次の開発で使える決めごとに変えるところまでを考えます。 例えば、画面を試して「この確認操作は不要だ」と分かったなら、その理由や適用条件も整理します。見た目だけを直して終えると、別の画面を作る際に同じ議論を繰り返しかねません。得られた学びが次の判断に使える状態を作ります。 実装の途中でも、探索へ戻れるようにする 探索と収束は、前半と後半に分かれた一方向の工程ではありません。実装中に新しい疑問が見つかれば、試作や関係者への確認に戻ります。そこで分かったことを反映して、再び実装を整えます。 そのため、DNAを一度作った後に変更を認めない運用では、この考え方を生かせません。一方で、すべてを自由に変えてよいわけでもありません。守るべき内容を共有しつつ、新しい発見を取り込む道筋を残しておくことが必要です。 最初から決まっていることは、そのままDNAに残す すべての決めごとを、バイブコーディングで発見する必要はありません。依頼時点で明確な要件や、関係者と合意済みの業務ルールは、探索を挟まずDNAへ反映できます。 例えば、利用対象者がすでに決まっているなら、そこを改めて試して決め直す必要はありません。探索するのは、まだ判断材料が足りない部分です。「まず必ず試作品を作る」という手順ではなく、分かっていることと分かっていないことに応じて進め方を選びます。 参考： クラウドエース公式note「Vibe Coding と Spec Driven Development」 クラウドエース公式note「問題は『真ん中』にある」 クラウドエース公式note「『冒険』としての探索」 ソフトウェアDNAに何を記録するのか ソフトウェアDNAの中心は、何を実現するか、どう振る舞うか、どのような構造や方針で作るかという決めごとです。要件・仕様・設計に加え、用語、利用者の役割、具体的な利用場面なども整理の対象になります。 ただし、情報を詰め込むだけでは、実装に使える基準にはなりません。ここでは記載内容を考える際の観点を示します。固定の必須項目ではなく、プロジェクトの判断に必要な情報を選ぶための整理です。 要件・仕様・設計のつながりを明らかにする 要件・仕様・設計は、同じ内容を言い換えて三度書くものではありません。実現したい目的、それを満たす具体的な振る舞い、実現を支える構造や制約として整理すると、関係が見えやすくなります。 例えば「操作ミスを減らしたい」という要件だけでは、必要な実装を判断しきれません。どの操作を防ぐのか、どの条件で許可するのかまで具体化し、その制御をどこで行うかを設計します。目的と実装上の判断をたどることが大切です。 用語と利用者の役割をそろえる 同じ言葉が同じ対象を指すように、用語と利用者の役割をそろえます。例えば「担当者」が申請した本人なのか、処理を受け持つ人なのかで、画面や権限の解釈は変わります。 登場する人やシステムの役割は、開発ではアクターと呼ばれます。誰が、何を、どの場面で行うのかを具体的にすると、機能名だけでは見えなかった条件も整理できます。身近な業務用語ほど、開発に関わる全員が同じ意味で使っているかを確かめたいところです。 判断理由を残し、変更時に参照できるようにする 採用した仕様だけでなく、なぜその仕様にしたのかも残しておくと、変更時の判断材料になります。仕様の文面だけでは、守りたい業務上の目的まで読み取れない場合があるためです。 例えば「申請後は金額を変更できない」という決めごとには、確認した内容と記録を一致させたい、といった理由が考えられます。理由が分かれば、別の方法で同じ目的を満たせるかも検討できます。単に禁止事項を増やすのではなく、その判断が必要だった背景を残します。 分からないことを、推測で仕様にしない 答えられない問いは、無理に埋めず、次に必要な行動へ分けます。業務部門に確認しないと決められないことと、実際に動かさないと分からないことでは、解消する方法が異なるからです。 不明な内容をもっともらしい仕様にしてしまうと、その後の実装は誤った前提に沿って進みます。「誰に確認するか」「何を試すか」が分かる形で未確定事項を残し、合意済みの内容とは区別します。空欄をなくすことより、判断できていない範囲を明らかにすることを優先します。 参考：クラウドエース技術ブログ「ソフトウェアDNAとクラウドエージェントのススメ」 三つのレイヤーと安定度で決めごとを整理する ソフトウェアDNAは、変わりやすさと適用範囲に応じて整理します。システム全体で守る原則と、試しながら変える個別機能の仕様を、同じ扱いにしないためです。 クラウドエースの既存コラムでは、原則レベル、プロジェクトレベル、ゾーンレベルの三階層で紹介しています。さらに、内容がどれだけ合意・確定しているかという安定度を組み合わせます。レイヤーと安定度は、別の軸です。 レイヤー 主な対象 変化の捉え方 原則レベル システムを壊さないための基本原則 不変の前提として管理する プロジェクトレベル システムの目的、全体設計、標準・規約 全体に適用し、比較的ゆっくり変わる ゾーンレベル 業務機能ごとの要件・仕様・例外 探索を通じて変更されることが多い 抽象度ではなく、変更の影響で置き場所を考える レイヤーを分けるときは、文章が抽象的か具体的かだけで判断しません。どこまで適用される決めごとか、変更した場合にどの範囲へ影響するかを見ます。 例えば、具体的な命名規則であっても、プロジェクト全体に適用するなら全体のルールです。一方、ある画面だけの表示条件は局所の決めごととして扱えます。こうして整理すれば、一つの画面を試し直す作業と、全体方針の変更を混同せずに検討できます。 同じレイヤーでも、合意の状態は分ける 同じ業務機能の仕様でも、合意済みの部分と検討中の部分は混在します。その違いを表すのが安定度です。公式noteでは、安定したもの、進化中のもの、ドラフトのものを区別する考え方が示されています。 例えば、利用対象者は合意済みでも、操作手順は試している最中かもしれません。どちらも同じ機能に関係しますが、変更の扱いは異なります。ひとまとまりの文書に書かれているからといって、すべて確定済みと扱わないことが必要です。 Stableは、関係者との合意が反映された状態 この考え方におけるStable（安定）は、関係者と合意し、開発の前提として安定した状態を指します。開発チーム内だけでなく、内容によってはお客様や現場部門との合意も含まれます。 ただし、合意済みの仕様が将来も変わらないとは限りません。変更が必要になったときは、既存の合意を踏まえて判断し、新しい内容を共有します。こっそり書き換えることも、見直しを一切認めないことも避け、何を基準に開発するかをそろえ直します。 参考： クラウドエース流のAI駆動開発とソフトウェアDNAの三階層 クラウドエース公式note「探索と収束を『同じ仕組み』で回す」 仮想例：社内申請システムで考えるソフトウェアDNA ソフトウェアDNAの役割は、試作品での気付きを、次の実装でも守れる決めごとに変える場面で見えてきます。画面を直すだけでなく、その変更の根拠を残し、実装を確認するところまでつなげます。 ここでは、社内申請システムを作る仮想例で考えてみましょう。以下の業務ルールや記載内容は、説明のために設けた例です。クラウドエースの実際の社内制度や、標準テンプレートを示すものではありません。 試作品で見つけた疑問を、その場で仕様にしない 最初の試作品では、申請者がいつでも内容を編集できたとします。利用部門に触ってもらうと、「確認を始めた後に金額が変わったら、何を確認したのか分からなくなる」という指摘が出ました。 ここで、AIに編集ボタンを消すよう頼むだけでは、業務ルールは決まりません。申請のどの時点から編集を止めるのか、間違えた場合はどうするのか。試作品が示した疑問を整理し、業務を判断できる人に確認する必要があります。 採用する業務ルールを、理由とともに残す 確認の結果、「下書きは編集できる。提出後は編集できない。修正が必要なら、承認前に申請を取り下げる」というルールを採用したとします。これを、採用理由と併せてDNAへ残します。 理由は、承認者が確認する内容を提出時点で固定するためです。さらに、ここでいう取り下げは削除ではなく、提出を取り消す操作だと定義します。同じ「取り下げ」という言葉でも、記録を消すのか残すのかでは実装が変わるため、意味をそろえておきます。 決めた内容を、実装とテストの観点に分ける 次は、決めごとを満たしているかを確かめます。この例なら、下書きは変更できること、提出後の変更は拒否されること、取り下げ可能な状態が定義どおりであることが確認対象です。 編集ボタンを隠しただけで、画面を経由しない更新要求を受け付けるなら、「提出後は編集できない」という仕様を満たしません。表示だけではなく、データを更新する処理でも条件を守る設計が必要です。DNAの一文を、見た目と実際の振る舞いの両方で確認します。 ルールが変わったら、関係する箇所を一緒に見直す 運用の検討中に、「差し戻された申請は、元の記録を残して修正できるようにしたい」という新しい要望が出たとします。これは、画面の変更だけでなく、申請の状態や履歴の扱いを見直す話になります。 関係者と合意したら、DNAに条件を追加し、実装とテストも更新します。一方、承認済みの内容は変更できないという既存の決めごとを残すなら、その条件も確かめます。新しい要望への対応と、従来守っていた内容の確認をセットで進めます。 ソフトウェアDNAを使ったレビューと品質確認 ソフトウェアDNAがあっても、生成されたコードが必ず意図どおりになるわけではありません。決めごとに沿っているかに加え、書かれていない部分をどのように補ったかも確認する必要があります。 レビューでは、コードの差分だけでなく、人の意図、DNAの記述、実装のつながりを見ます。どこでずれたのかが分かれば、コードを直すべきなのか、決めごとを補うべきなのかを判断できます。 決めごとへの準拠と、AIの解釈を分けて確認する 確認したいのは、明記されたルールへの違反だけではありません。明記されていない条件を、AIがどう判断したかも対象です。仕様に反していなくても、人が望んでいない振る舞いになっている可能性があるためです。 クラウドエースの公式noteでは、この二つを分けるレビュー方式としてSLIR（Semantic Lint & Interpretation Review）を紹介しています。AIを使った準拠の確認と、人による解釈の検討を組み合わせる考え方です。コードを読む必要がなくなるという意味ではなく、判断が必要な箇所を見つけるための整理です。 テストで検証できる決めごとを増やす 文章だけでなく、テストで表せる条件も用意すると、実装との一致を確かめる手段が増えます。例えば「提出後の金額変更を拒否する」という条件なら、更新要求に対する結果を確認するテストとして表現できます。 クラウドエースの技術ブログでは、自然言語のDNAと、テストによる検証を組み合わせる方向性が提案されています。ただし、テストが確かめるのは記述した条件の範囲です。テストが通ったことだけで、仕様自体の妥当性や品質全体が保証されるわけではありません。 ずれの原因を見極め、コードか決めごとを直す DNAと実装にずれがあったときは、コードを戻すのが適切か、決めごとを更新すべきかを判断します。実装が誤っている場合もあれば、新たな業務上の事情をDNAへ反映できていない場合もあるからです。 また、すぐに直せないずれを残す判断もあり得ます。公式noteでは、収束を予防・治療・共存という観点で整理しています。共存は放置ではありません。影響を許容できるかを判断し、回避策や残る課題を見える形にして管理する考え方です。 参考： クラウドエース公式note「AI生成コードのレビューは『コード』ではなく『解釈』を見る」 クラウドエース公式note「『健康管理』としての収束」 関連記事：ソフトウェアDNAとクラウドエージェントのススメ 書いて終わらせないための運用 ソフトウェアDNAを開発に生かすには、内容だけでなく、参照・更新・合意の流れを決める必要があります。適切な仕様が書かれていても、使われなかったり、変更が反映されなかったりすれば、実装を確かめる基準にはなりません。 運用を考える際は、ファイルを増やすことよりも、「いつ読むか」「いつ直すか」「誰が判断するか」を具体的にします。既存の開発手順の中で、決めごとを扱う場面を明確にしていきます。 AIが参照する場所と、更新するタイミングを決める DNAは、コードとともに管理するファイルとして残し、作業に必要な内容へたどり着ける状態にします。保存しただけでAIが必ず読むと考えず、実装やレビューで何を参照させるかを明確にします。 運用例として、公式noteでは、探索で得た決めごとを変更の統合前にDNAへ反映する方法を紹介しています。自分たちの開発でも、仕様変更が発生したときに、コードだけでなくDNAの更新を確認する場面を設けると、更新漏れを見つけやすくなります。 誰が何を決めるかを明らかにする AIが案を作れることと、その案を採用してよいことは別です。業務ルール、設計方針、運用上の例外について、それぞれ誰が判断するかを決めておきます。 例えば、開発担当者だけでは変更できない業務ルールがあるなら、確認先を明確にします。関係者が同じ言葉を使っていても、理解や優先順位が違うことはあります。DNAの更新を単なる文章修正として扱わず、必要な合意を開発に反映する作業として捉えることが大切です。 既存システムでは、現状と正式な決めごとを分ける 既存システムに取り入れる場合は、コードや資料から読み取った内容を、そのまま正しい仕様と決めつけないようにします。現在の振る舞いには、古い要件や一時的な対応が残っているかもしれません。 例えば、一つの機能を対象に、現在の処理、残っている合意事項、担当者が期待する動作を照合します。一致しない部分は確認事項として分け、守るべき内容を整理します。現状を説明する作業と、今後の基準を決める作業を区別するのが出発点です。 参考： クラウドエース公式note「探索と収束を『同じ仕組み』で回す」 クラウドエース公式note「何故か遅くなるAI駆動開発」 ソフトウェアDNAで変わる、人の役割 ソフトウェアDNAは、人の判断を不要にするための仕組みではありません。何を採用し、何を守り、何を変更してよいかを、人が判断したうえでAIへ渡すためのものです。 クラウドエースでは、AI駆動開発における人の役割を、コードを書くことだけではなく、要件や設計を選び、決め続けることとして捉えています。判断をDNAに残すことは、業務への理解と技術的な検討を開発につなげる営みでもあります。 AIに任せるほど、業務と技術の判断が必要になる 何を作るべきかを決めるには、業務の事情と技術上の制約の両方が必要です。望ましい画面であっても、権限やデータの整合性を保てなければ、そのまま採用するわけにはいきません。 反対に、技術的に整った設計でも、現場の業務に合わなければ目的を果たせません。どちらかをAI任せにするのではなく、判断材料を集めて選び、その理由を残す。ソフトウェアDNAを扱う場面では、こうした設計や合意形成の力が問われます。 文書を完成させるより、開発で使って磨く 具体的な実践方法は、クラウドエースでも模索を続けています。2026年9月公開の技術ブログでも、決定的な進め方があるわけではないと説明しています。どの現場にも当てはまる完成済みの手順という位置付けではありません。 DNAの運用を考えるときは、文書量より、次の担当者が判断に使えるかを確かめます。繰り返し迷う判断や、変更時に守るべき条件から整理し、実装やレビューで使って不足を直す。文書を完成させることより、開発に役立つ状態を保つことに目を向けます。 参考：クラウドエース公式note「コードを書かない、という選択」 まとめ：試したことを、次に使える決めごとへ ソフトウェアDNAは、クラウドエースが提唱する、要件・仕様・設計などの決めごとを開発の基準として使い続けるための考え方です。試作で得た発見や関係者との合意を残し、実装と照合し、必要に応じて更新します。 まずは一つの機能について、「何が決まっているか」「何が未確定か」「実装は決めた内容に沿っているか」を確かめてみてください。試した成果を一度きりにせず、次の開発へ引き継ぐ。その積み重ねが、ソフトウェアDNAの役割です。 Tanmay Bagwe主にフルスタックWebアプリ開発を担当し、フロントエンドからバックエンド、Google Cloudを活用した実装まで幅広く経験。現在はサイバーセキュリティやネットワーク領域にも注力している。
