はじめに
こんにちは！cherieといいます。AIとの開発はもはや当たり前となっていますが、続ける中で浮き彫りとなる課題も多々あるかと思います。今回は、そんな課題について少し考えてみたので共有させてください。この記事は、SDDをはじめとするAI時代の駆動開発論や、多くの記事、議論を参考にして制作しました。
AIとの開発を初めてしばらくは、まさに魔法のような開発体験で興奮が治まりませんでした。作りたいものを伝えるだけで形になっていくのをみていると、自分の能力が高まったと錯覚します。
しかし、エラーが重なったり、「完成しました」と嘘をつかれたり、実装方針をAIに委ねる回数が増えるにつれて、自分が作ったはずのアプリが自分のものではないかのように思えてくるのです。
これは、駆け出しエンジニアとしての自分の価値を脅かされるような気持ちでした。
何より、楽しくありませんでした。AIの提案を選ぶだけでは、所有感も楽しさも失われます。かといって自分で実装を進めれば、開発は遅れ、「AI時代にこの方法が正しいのか」という悩みがつきまといます。
コーディングを自力でできるようになることも、AIの進歩を考えると価値があるとは限らない。AIの進歩が自分の成長より速ければ、私は必要とされないのではないか。
AIが進化する速度から逆算して、自分の価値を再定義すること。それは私にとって、単なるスキルアップではなく、エンジニアとして生き残るための『生存戦略』でした。
AIを高度に使いこなすというのはその価値の一つだと思います。
そこで、AIとの開発の課題を見つめ直し、自分なりに改善しようと思い立ちました。
AI駆動開発の本質的な問題
AI駆動開発の課題は、すでに多くのエンジニアが直面しています。
理解できないコードが積み重なっていく。^[1] 自分が書いたはずのコードなのに、「作者なのに初見」という感覚。AIが自信満々に嘘をつき、^[3] コードが劣化していく。生成されたコードのレビューに膨大な時間がかかる。^[1]
これらは表面的な症状に過ぎません。
本質的な問題は、『コードを書くこと』と『メンタルモデルを構築すること』が分離してしまったことにあります。
従来、コードを書く行為そのものが、設計を考え、判断し、理解を深める一連のプロセスでした(少なくとも、アジャイル的な開発においては)。しかしAI時代、この一体性が崩れました。
この構造変化により、理解の欠如、所有感の喪失、レビューの困難といった症状が生まれているのです。^[1]^[2]^[3]
この問題を掘り下げる
この構造変化は、具体的にどのような問題を引き起こすのでしょうか。
責任の曖昧化
「誰が何を決めたのか」が不明になります。
従来、コードを書いた人間は、すべてのコードを自分の言葉で説明できました。なぜなら、自分で書いたからです。しかしAI駆動開発では、実装を担うのはAIです。
AIが生成したコードのすべてをチェックするのは難しいため、曖昧な部分が増えていきます。「ここは理解しているが、この部分は詳しく見ていない」という状態が当たり前になります。責任の範囲が、徐々に不明瞭になっていくのです。
方針と実装の乖離
人間がアーキテクチャや設計原則を決めても、AIが実装時に行う無数の小さな判断により、意図と異なるシステムが生まれます。
CI/CDは動くことを保証します。テストは仕様を満たすことを保証します。しかし、意図通りであることは誰も保証しません。
背景情報の即時消失
AIとの対話履歴は散逸します。
「なぜこの方法を選んだのか」「なぜ他の方法を捨てたのか」という意思決定の背景は、対話が終われば失われます。コードだけが残り、コンテキストは消えます。
1週間後、自分が書いたコードを見返しても、「なぜこうしたか」を思い出せません。
そして、この情報の喪失は、改善の構造を弱くします。どのような指示が効果的だったのか、どこで失敗したのか。それらが蓄積されず、毎回同じ試行錯誤を繰り返すことになります。
理解の速度を超えるコーディング
AI時代、実装は瞬時です。
しかし、理解の速度は変わりません。
1分で生成されたコードを理解し、レビューするのに1時間かかります。この非対称性が、AI駆動開発の根本的な問題です。
コーディングの速度が理解の速度を超えた今、レビューという行為だけで品質を担保するのは無理があります。
従来のレビューは、バグの発見だけでなく、設計意図の最終確認やチーム内の知識共有の場でもありました。しかし、AIが次々とコードを生成する環境では、人間がそのすべてを読み解き、文脈を同期させることは不可能です。
ボトルネックは実装から「決断・合意形成」へと完全に移動しました。 実装後のコードを見てから方針の誤りに気づくコストは、AI時代においてより破壊的になります。
「実装してから直す」のではなく、「決断してから実装させる」。 この順序を徹底し、意思決定の質を高めることこそが、AI時代の開発において最も重要なエンジニアの職能の一つになると私は考えています。
既存手法の限界
これらの課題に対して、既存の手法(コメント、ドキュメント、ADR、SDD等)は部分的な解決を提供しますが、本質的な問題—人間が理解を保ちながら決断し、その責任を明確にする仕組み—を解決していません。
私たちの信念
では、どう解決すべきでしょうか。その前に、私たちが何を信じているかを明示したいと思います。
1. 人間の価値は、選択と責任にある
AIが実装を担う時代、エンジニアの価値は意思決定にある。選択し、責任を負うことが、人間のアイデンティティである。
2. 理解なき実装に価値はない
理解は、レビューではなく、決断から生まれる。AIが書いたコードを人間が理解していなければ、改善もイノベーションも生まれない。
3. AI時代の新たな開発体系を確立するべきだ
従来の開発手法の延長では、この構造変化に対処できない。AI協働のための新しいパラダイムが必要である。
そして、AI駆動開発もエンジニアリングであるべきだ。再現可能で、検証可能で、コードで管理できるべきである。
CDDとは何か
CDD(Commitment-Driven Development) は、人間の決断を記録し、それを軸にAIと協働する開発手法です。
CDDは以下の原則に基づいています。
原則1: 人間の理解の速度を超えない
AIはコードを瞬時に生成できますが、人間が理解できる速度には限界があります。
理解が追いつかないまま開発を進めれば、「動くが説明できないコード」が積み重なります。人間が理解を保ちながら進める速度で開発をします。
原則2: コンテキストを失わない
「なぜこの方法を選んだのか」「なぜ他の方法を捨てたのか」という意思決定の背景は、対話が終われば失われます。
コンテキストを永続化することで、いつでも意図を確認できます。
原則3: AIをコントロール可能にする
人間がアーキテクチャを決めても、AIの無数の小さな判断により、意図と異なるシステムが生まれます。
AIの動作をコントロール可能にし、人間の意図した通りの実装を実現します。
原則4: 問題を分解可能にする
障害や問題が発生したとき、原因を特定できなければ改善できません。
人間の決断が誤っていたのか、AIの実装が誤っていたのか、ワークフローの問題なのか。問題を分解し、真因を特定できるようにすべきです。
決断の記録: cdd.md
CDDでは、cdd.mdというファイルに決断を記録します。
記録する内容:
- Goal: 何を達成するか
- Context: 前提・制約・背景
- Selection: 何を選んだか、なぜ選んだか
- Rejections: 何を捨てたか、なぜ捨てたか
- Residual Risk: わからないこと、残存リスク
cdd.mdは、決断の粒度に応じて柔軟に配置できます。
プロジェクト全体に関わる決断(アーキテクチャ、セキュリティ方針等)は、CDD/ディレクトリに配置します。機能やモジュールごとの決断は、そのコードと同じディレクトリに配置(Colocation)します。
重要なのは、必要な粒度で決断を記録できることです。すべてを記録する必要はありません。プロジェクトの性質・フェーズ・品質要求に応じて、記録すべき決断を選択できます。
cdd.mdの柔軟性:
cdd.mdの形式は固定されていません。
Goal、Context、Selection、Rejections、Residual Riskという基本構造はありますが、意図を正確にAIに伝えるために必要なものは何でも追記すべきです。
プロトタイプであれば、大まかな方針だけで十分かもしれません。しかしプロダクションコードでは、厳密な受け入れ要件、関数シグネチャ、エッジケースの扱い、テスト方式など、AIが意図通りに実装するために必要な制約を明確に書く必要があります。
重要なのは、「なぜそう決めたか」というコンテキストを形にすることです。AIに対して過不足なく意図を伝えられるなら、フォーマットは自由に調整してかまいません。
決断には、Decision Statusがあります。
- [DRAFT]: 検討中
- [REVIEW]: レビュー待ち
- [DECIDED]: 決定済み
[DECIDED]に変更する行為が、人間の明示的な責任の引き受け(Commitment)となります。
同期的な意思決定: モブワーク
理解の速度を超えないために、チーム内で同期的に意思決定を行います。[5]
実装後の非同期レビューではなく、実装前のモブワークで意思決定に力を割くべきです。AIと人間がリアルタイムに対話しながら、選択肢を洗い出し、比較検討し、その場で決断を確定させます。
これにより、手戻りを減らし、実装後のレビュー負荷を軽減できます。レビューは自動化の力を大いに借りればいいのです。
この過程で、cdd.mdが完成します。cdd.mdは単なるドキュメントではなく、理解を構築する過程の記録です。
AIのコントロール: 宣言的ワークフロー
人間が決断を記録したら、AIがその決断に基づいて実装します。
人間の決断を制約として、AIの動作を宣言的ワークフローで定義します。
- どのエージェントを使うか
- どのような検証を行うか
- どの条件で人間にエスカレーションするか
これにより、AIを用いた開発をより高度にコントロール可能にします。
品質の担保: 決断に対する適合性の検証
「レビューに頼らないなら、どうやって品質を担保するのか?」
CDDでは、単に「エラーがないこと」ではなく、 「実装が人間の決断(Commitment)に従っているか」 を検証したいと考えています。
例えば、「認証にはJWTを使う」と決断したなら、実際にJWTが使われているか、意図しないセッション方式が混入していないかを確認できる仕組みが必要です。
また、型エラーやテスト失敗が多発した場合、それが「AIの実装能力の限界」なのか「人間の決断の曖昧さ」なのかを切り分けられるようにしたいと考えています。
さらに、不具合が起きたとき、その原因となった決断を特定できるように、決断とコードを紐づける仕組みも重要だと考えています。
4つの原則の実現
CDDは、これらの仕組みにより、4つの原則を満たします。
- 理解の速度を超えない: 同期的な構築により、理解を保ちながら進める
- コンテキストを失わない: cdd.mdで決断の背景を永続化
- AIをコントロール可能にする: cdd.mdで与えるコンテキストを管理し、宣言的ワークフローで動作を制御
- 問題を分解可能にする: 決断とコードの紐づけで真因を特定
おわりに
CDDについて説明してきました。最後に、改めて考えたいことがあります。
AIの進化が私たちの成長を追い越していく時代において、エンジニアの価値はどこにあるのでしょうか。
CDDは、AI駆動開発において、人間が理解と責任を保ち続けるための方法論です。
実装はAIに任せます。しかし、「なぜそれを作るのか」「なぜその方法を選んだのか」という問いには、人間が答え続ける必要があります。
それがなければ、私たちは単なるAIのオペレーターに過ぎません。
CDDは、人間がシステムに対する主導権を保つための試みです。
CDDは、まだ実験段階です。現在、CLI toolを製作中です。
より具体的な方法論については次回の記事公開でお伝えできればと思います。
議論の収まりが見えないAI駆動開発論に対して、一石を投じたいという思いでこの記事を執筆しました。
様々なご意見をいただけると、大変嬉しく思います。
参考文献
[3] バイブコーディングという地獄