AI駆動開発において、生成コードが間違っているかどうかの判断は、非常に重要なことです。
どれだけ考えた仕様書.mdファイルを作成しても、抜け漏れは起こり得ます。エンタープライズで使う製品であっても、必ずしも完璧なコードを出力するとは限りません。
人の検品は、いまだに必要なフェーズです。
ところでAI駆動開発において、生成されたコードが間違いっていることをどう捉え、どのようにアプローチしていくのでしょうか？
それらを3つのポイントから述べていきます。
- 従来のシフトレフト（前倒し）より、さらに前へ
- ClaudeやCodex、IBM Bobが、モードを採用した理由
- プロトタイプや実装の「ドラフト」を爆速で作るツールとする
改めて、これからのAI駆動開発を進めるために、進めるアプローチを考えていきましょう。
ClaudeやCodexの生成AIのコードが「間違っていて当然」という認識を再度持つ
直近のAI駆動の開発ツールに対して、私たちはなぜか強い信頼を寄せています。驚くほど速いコーディング、自然言語による会話、その結果出力されるコード。
これらの結果が、私たちに「AIが作るコードは正確で速い」というバイアスを植え付けています。
例えば、たったこれだけでUIから、ダッシュボード、その分布を作るアプリケーションが作成されてしまいます。
UIから渡されたCSVを分析して、その結果を出力するダッシュボードを作成して.
ところで、この中身をしっかりと検証しているでしょうか？ダッシュボードに表示されているデータがどういうロジックで分析され、ダッシュボードとして作成されているのか、実は知らないまま驚いている可能性があります。
これが自分の中で使うだけのちょっとしたシステムなら問題ないでしょう。ですが、世の中に出す製品、コードだった場合、このコードの「正しさ」や「抜け漏れ」をしっかりと検証する必要があります。
改めて、私たちはAIの作成するコードが間違っている可能性がある。という前提で話を進めるべきなのです。でなければ、Vibeコーディングの騒ぎと同じ轍を踏むことになってしまいます。
セキュリティやテストのシフトレフトとAI駆動開発のシフトレフト
シフトレフトとは、フェーズをさらに前に倒すことです。
例えば、アジャイルやDevOpsの動きによって、短期スパンで回る開発サイクルの動きが活発化しました。今までのウォーターフォール開発では、後半の工程でセキュリティ検証などのテストを行うのですが、それではサイクルに追いつきません。
そのボトルネックを解消するため、開発の段階にセキュリティの要素を組み込もうという動きが起こります。リスクを早い段階で潰すことは手戻りを減らすだけではなく、品質をより高めるアプローチとして定着しています。
では、AI駆動開発におけるシフトレフトとはなにを指すのでしょうか？
もちろん、コード生成のさらに前のフェーズへ注力をシフトすることです。AI駆動開発の効果的な部分は人間より遥かに速いスピードでコード開発が行われることです。
アジャイルやDevOpsと同じように、コード開発のサイクルが早まることで、今度は人のレビューがボトルネックとなりました。これには、検証も含まれています。
つまりコード開発の前のフェーズである、要件定義の段階に、セキュリティ的な考えやテスト、そもそもの仕様、エラーハンドリングを盛り込む必要があります。
しかしそれだけではありません。
- 自社における安全なコードの基準
- 仕様の境界条件
- テストコードの評価条件
- 期待される出力
- 暗黙の了解
これらをできるだけ詰め込まなくてはいけません。
また、コンテキストが膨大になっていても、巨大なアプリケーションの作成をすると、整合が取れなくなります。AIが理解できる単位まで、分解した設計をしなければならないのです。
ClaudeやCodex、IBM Bobが、モードを採用した理由
これまでは、1つのチャットにすべてを詰め込んで覚えさせようとしたり、条件を定義して同じチャットのなかで一気に作業して欲しい命令を書いていました。
しかし、それまでのコンテキストが混ざってしまうことや、本当に必要な内容を取りこぼしてしまうといったデメリットがあります。
これを受けて、ClaudeやCodex、IBM Bobでは、個別のモードを用意しており、CodeやPlan、Askモード、にすることで、状態を外部からコントロールする仕組みをとっています。
モードを分けるとどうなるのかという点は、明確です。個別のモードで専業させることができます。仕様を分析することが必要な時には、専用のモードを利用する。コーディングを行う時には、Codeを利用するといった、非常にシンプルな動きです。
これはシフトレフトの考え方とも相性が良く、要件定義、仕様書の作成、設計という段階において、条件を洗い出すことに集中できます。
〇〇駆動開発のひとり歩き
- テスト駆動開発
- ドメイン駆動開発
- 仕様駆動開発
- AI駆動開発
多くの〇〇駆動開発が生まれています。しかし、なぜそれを選んだのか、希薄になっているかも知れません。例えば、テスト駆動開発を選んだとしても、テストを通れば良いという考え方では、意味のないテストコードを量産するだけで解決できてしまいます。
AI駆動開発でも注意しなければなりません。要件を丸投げすれば、コード生成は行われます。しかし、コードを書かせることが目的になっている場合、生成された膨大なコードの整合性やセキュリティリスクを誰もレビューできなくなってしまいます。
結果として、AIによるブラックボックスの完成です。
AIの立ち位置を知って、「ドラフト」を爆速で作るパートナーにする
各AIエージェントの立ち位置を理解しましょう。
- Claude：広く深く文脈を読み、綺麗に組み立てる
- Codex：最適なコードを、一発で速く書き、動かす
- IBM Bob：一気通貫にの開発、ガバナンスを重視
Claudeは文脈理解に優れています。また、Claude Mythosの件もあり、今後の界隈を大きく変えてしまう可能性を秘めています。
CodexはOpenAI産ということもあり、PC操作やツール実行まで自走して爆速でタスクを片付けることを得意としています。
IBM Bobは、企業・個人利用できます。コンプライアンスとセキュリティを遵守しながら最新システムを組み立てます。
この3つを取り上げたのは、それぞれが強みを持っているからです。Claudeは汎用性が高いことだけではなく、文脈の理解に強いため、仕様の深掘りが可能です。Codexは動作確認などに優れており、検証に役立ちます。IBM BobはマルチLLMでClaudeを利用することもでき、さらにセキュリティとガバナンスに優れます。
どれかひとつにこだわるのではなく、各々の強みを理解して、使い所を見極めることで、AI駆動開発はより良いステージに向かいます。
個人で利用すること、企業で利用すること、あるいはその両方かも知れません。アプローチとしては、開発フェーズの上流をいかに必要なだけ洗い出すか、それを反映するかです。
まとめ：シフトレフトを理解しつつ、開発パートナーを選ぶ
今回は、シフトレフトの話から、なぜモード採用がされたのか、そして各ツールの持つ強みを整理しました。
シフトレフトの動きはすべてのツールで起きています。そんな中、ただ爆速でコードを書いてくれることだけに目を奪われず、コードの正しさを保証しなければなりません。
それはエンジニアとしての仕様理解が試される場でもあり、これからの開発スピードと学習内容をおさらいすることになります。また、AIが決められることには限界があり、人間の意思決定がどうしても必要です。
AIによって開発がすべて自動化されても、シフトレフトした部分では、人間が役割を保証する必要があります。AIによるブラックボックス化したレガシーコードを生み出さないためにも、Vibeコーディングの問題を再発させないためにも、改めて、AIエージェントへのアプローチが必要となるでしょう。