AI時代の竹槍開発をやめろ｜Codexで開発が進む人と地獄コードになる人の違い
メタ情報
- 想定キーワード:
- Codex バグ 直らない
- AI 開発 バグ 修正できない
- AI コード 地獄
- AI 開発 設計 必要
- Codex 使い方 開発
- AIに仕様書を渡す
- AI 開発 ログ 設計
- バグチェックリスト 作り方
- AI時代 竹槍開発
- AIアプリ開発 失敗
「AIに頼んでもバグが直らない」は本当か
「AIにいくら指示してもバグが直らない」
「結局エンジニアに依頼することになる」
「AIで作ったコードが地獄になる」
こういう話は、今後かなり増えると思う。
ただし、それは必ずしも「AIが使えない」という話ではない。
むしろ多くの場合、問題はAIそのものではなく、AIに渡す前提が足りないことにある。
目的が曖昧。
仕様がない。
ログがない。
再現手順がない。
バグチェックリストがない。
どこまでできていて、どこから壊れているのか分からない。
何をもって完成とするのかも決まっていない。
この状態でAIに、
いい感じに直して。
ちゃんと動くようにして。
バグを全部潰して。
デザインを良くして。
と投げても、AIは迷子になる。
これはAI開発ではなく、AI時代の竹槍開発である。
AIが弱いのではなく、地図がない
AIは、コードを書くことは得意になってきている。
既存コードを読ませる。
機能を追加させる。
バグの原因を探させる。
テスト観点を出させる。
リファクタリング案を出させる。
PRの差分を見させる。
こうした用途ではかなり使える。
しかし、AIは魔法ではない。
地図がない場所で、目的地も不明なまま、
「とにかくいい感じに進んで」と言われても困る。
人間のエンジニアでも同じである。
仕様がない。
ログがない。
再現手順がない。
何が正解か分からない。
既存コードがぐちゃぐちゃ。
テストもない。
この状態では、人間でもAIでも苦しい。
だから、AI開発で重要なのは、AIに作らせることそのものではない。
AIが迷子にならないように、先に地図を作ることである。
0から1で作るなら、まず商材設計が必要
アプリやWebサービスをAIで作る時、いきなりコードを書かせると危ない。
最初に必要なのは、商材設計である。
つまり、
- 誰の問題を解決するのか
- どんな悩みを解消するのか
- 何を提供するのか
- どこでお金を取るのか
- 無料部分と有料部分は何か
- 競合と何が違うのか
- 何ができればMVPなのか
- 何ができなくても初期版として許容するのか
を決める。
ここが曖昧なまま開発に入ると、AIはどんどん機能を足してしまう。
結果、何のためのサービスか分からないものができる。
AIに必要なのは、コードを書く前の目的である。
概要設計を作る
商材の方向性が決まったら、次に概要設計を作る。
概要設計では、全体像を決める。
たとえば、
- 画面一覧
- ユーザー導線
- 機能一覧
- データの流れ
- ログインの有無
- 保存するデータ
- 外部API
- 課金導線
- 広告導線
- 管理画面
- 通知
- エラー時の挙動
- 権限
- 対応端末
- 初期リリースの範囲
ここを先に作る。
概要設計がないと、AIは部分的には正しいコードを書けても、全体としてバラバラなものを作りやすい。
画面ごとには動く。
でも導線がつながらない。
保存先が揃っていない。
ログイン状態の扱いが違う。
エラー処理が統一されない。
課金や広告の位置が後付けになる。
こうして地獄コードが育つ。
詳細設計を作る
概要設計の次は、詳細設計である。
詳細設計では、機能ごとに以下を決める。
- 入力
- 処理
- 出力
- 状態管理
- 保存先
- バリデーション
- エラー処理
- 空欄時の挙動
- 通信失敗時の挙動
- 連打時の挙動
- 戻るボタン時の挙動
- 権限拒否時の挙動
- 既存データが壊れていた時の挙動
- 初回起動時の挙動
- 再起動後の挙動
- 成功条件
- 失敗条件
これを作ると、AIへの指示が一気に具体的になる。
「アラーム機能を作って」ではなく、
アラーム作成画面では、時刻、曜日、動画URL、スヌーズ有無を入力する。
保存時に空欄チェックを行う。
保存後は一覧へ反映する。
通知権限がない場合は権限案内を出す。
アプリ再起動後も設定が残る。
鳴動中は重複通知を出さない。
のように書ける。
この状態なら、AIはかなり動きやすい。
ログ設計を最初から入れる
AI開発でかなり重要なのが、ログである。
バグが起きた時に、
なんか動かない。
たまに変になる。
どこかで落ちる。
iOSだけおかしい。
広告が一瞬出て消える。
だけでは、AIも人間も直しにくい。
だから最初からログを取る設計にする。
たとえば、
- どの画面を開いたか
- どのボタンを押したか
- どの処理が走ったか
- どのAPIを呼んだか
- APIレスポンスは何だったか
- 保存処理は成功したか
- 読み込み処理は成功したか
- 権限状態は何だったか
- エラーコードは何だったか
- ユーザー操作の順番
- 状態遷移
- 処理開始時刻と終了時刻
これを残す。
ログがあれば、バグは「なんか変」ではなくなる。
画面AでボタンBを押した時、処理Cは走っている。
しかし保存Dが失敗している。
エラーコードはEである。
その結果、画面Fに反映されていない。
ここまで分かれば、AIに投げやすい。
ログはAI開発の命綱である。
バグチェックリストを作る
次に、バグチェックリストを作る。
AIに実装させる前、または実装後に、以下のような観点をチェックする。
- 空欄で保存したらどうなるか
- 同じボタンを連打したらどうなるか
- 通信失敗時はどうなるか
- ログイン切れ時はどうなるか
- 端末の権限が拒否されたらどうなるか
- アプリを再起動したらどうなるか
- データが0件の時はどう表示するか
- 文字数が多すぎる時はどうなるか
- 戻るボタンを押したらどうなるか
- 別画面へ移動して戻ったらどうなるか
- タイムゾーンや日付変更に対応しているか
- iOS/Android/Webで差分がないか
- 課金・広告・通知が失敗した時の挙動はあるか
- 既存データとの互換性はあるか
このチェックリストがあると、AIにこう投げられる。
以下のバグチェックリストに対して、現在の実装で未対応のものを洗い出してください。
重大度をHigh/Middle/Lowで分類し、修正方針を出してください。
これをやると、AIは単なる実装者ではなく、テスト観点出し・品質管理の補助になる。
「できていない前提」で網羅させる
AIに指示する時は、最初からこう考えた方がよい。
たぶん抜けている。
たぶん未定義がある。
たぶん矛盾がある。
たぶん例外処理が足りない。
だから、AIには実装だけでなく、レビューもさせる。
たとえば、こう投げる。
この仕様には抜けがある前提で、未定義、矛盾、例外、バグりそうな箇所、ログ不足、テスト不足をすべて洗い出してください。
これがかなり効く。
AIは、明確な問いを与えると、かなり多くの観点を出せる。
ただし「いい感じにして」では出ない。
「何が足りないかを探せ」と明示する必要がある。
AIで詰む人と進む人の違い
AIで開発が詰む人は、だいたいこうなる。
- 思いつきで実装を頼む
- 仕様を作らない
- ログを取らない
- バグの再現手順がない
- テスト観点がない
- 直したいことが曖昧
- 毎回違う前提で指示する
- AIの出力を確認せず積み増す
- 壊れたらまたAIに丸投げする
結果、コードは増える。
でも何が正しいか分からない。
どこで壊れたか分からない。
修正すると別の場所が壊れる。
これが地獄コードである。
一方、AIで進む人はこうする。
- 商材設計を作る
- 概要設計を作る
- 詳細設計を作る
- ログ設計を入れる
- バグチェックリストを作る
- 未定義を洗い出させる
- 受け入れ条件を決める
- 実装後にログとチェックリストで確認する
- 変更理由を残す
この違いは大きい。
AIに作らせるかどうかではなく、AIに渡す地図があるかどうかで決まる。
デザインは別物として扱う
AI開発でよく混ざるのが、実装とデザインである。
Webやアプリの機能実装は、仕様があればかなり進む。
しかし、
- なんか良い感じのデザイン
- SaaSっぽい雰囲気
- 高級感
- 信頼感
- 余白の美しさ
- ファーストビューの説得力
- ブランドらしさ
- イラストの一貫性
のような領域は、AIに丸投げするとズレやすい。
これはAIが完全に無理というより、判断基準が曖昧だからである。
デザインをAIに頼むなら、参考サイト、配色、フォント、余白、ターゲット、NG例、競合、目的、CTA、視線誘導を渡す必要がある。
「いい感じにして」では難しい。
ここでも結局、前提と判断基準が必要になる。
AIは魔法ではなく、工程に入れるもの
AI開発で重要なのは、AIを魔法扱いしないことである。
AIは、
- 要件定義の壁打ち
- 概要設計の整理
- 詳細設計の補完
- 未定義の洗い出し
- 実装
- バグ原因の推定
- ログ設計
- テスト観点出し
- リファクタリング案
- ドキュメント作成
に使える。
つまり、AIは開発工程の中に入れるものだ。
思いつきで丸投げするものではない。
AIに作らせるのではなく、AIが迷子にならない工程を作る。
これができる人は、Codexでもかなり進む。
これができない人は、AIに作らせても地獄コードになりやすい。
まとめ：コードを書く前に、AIが検証できる地図を作れ
AIにバグ修正を頼んでも直らない。
その原因は、AIの性能だけではない。
多くの場合、AIに渡す前提が足りない。
目的がない。
仕様がない。
ログがない。
再現手順がない。
バグチェックリストがない。
未定義が洗い出されていない。
完成条件がない。
この状態でAIに「直して」と言っても、AIは迷子になる。
だから、AI時代に必要なのは、コードを書く前の設計である。
- 商材設計
- 概要設計
- 詳細設計
- ログ設計
- バグチェックリスト
- 未定義洗い出し
- 受け入れ条件
これらを作ってからAIに投げる。
そうすれば、AIはかなり強い。
AI開発で大事なのは、AIに丸投げすることではない。
AIが検証できる地図を作ることだ。
AI時代の竹槍開発をやめよう。
FAQ
AIにバグ修正を頼んでも直らないのはなぜですか？
仕様、再現手順、ログ、期待結果、実際の結果が不足していることが多いです。AIは推測で直すことはできますが、前提が曖昧だと別のバグを生む可能性があります。
CodexやAIで開発を進めるには何が必要ですか？
商材設計、概要設計、詳細設計、ログ設計、バグチェックリスト、未定義洗い出し、受け入れ条件があると進みやすくなります。
AIで作ったコードは地獄になりやすいですか？
使い方次第です。仕様やログなしで思いつき実装を積み重ねると地獄になりやすいですが、設計と検証を先に作ればかなり使えます。
デザインもAIでできますか？
ある程度はできますが、「いい感じにして」だけではズレやすいです。参考サイト、ターゲット、配色、余白、CTA、NG例など、判断基準を渡す必要があります。
