AIによる自動開発の理想と現実
「全部丸投げ」は、どこまで可能になったのか
「作りたいシステムを説明したら、AIが設計し、プログラムを書き、テストして、そのまま完成させてくれる」
AIによる自動開発には、そんな理想があります。
実際、現在のAIはかなりのところまで進んでいます。画面を作る、データベースを設計する、不具合を直す、テストを追加する。以前なら何日もかかった作業を、数十分から数時間で進められることも珍しくありません。
しかし、ここで注意したいのは、「速く作れること」と「意図どおりのものを、常に正しく作れること」は別だという点です。
AI自動開発の現実的な姿は、何でも任せられる魔法の箱ではありません。
非常に仕事が速く、幅広い知識を持つ一方で、渡された情報の範囲でしか判断できず、成果物には必ず確認が必要な実務担当者
このように捉えた方が、実態に近いでしょう。
理想と現実の間にある5つの壁
1. AIが一度に把握できる情報には限りがある
AIには「コンテキスト」と呼ばれる作業領域があります。これは、人間でいえば、その瞬間に机の上へ広げて確認できる資料の範囲です。
どれだけ大きな机でも、システムの全仕様、過去の判断、顧客との会話、既存コード、テスト結果を無制限に置くことはできません。会話や作業が長くなると、古い情報を要約したり、必要な情報を選び直したりする必要が出てきます。
しかも、単に大量の情報を与えればよいわけでもありません。情報が増えるほど、重要な指示が埋もれたり、細部を正確に思い出せなくなったりすることがあります。Anthropicの公式資料でも、コンテキストはAIの「作業記憶」に相当し、長くなるほど正確性や想起性能が低下し得ると説明されています。Anthropic：Context windows
2. 新しいセッションでは、前回の理解がそのまま残るとは限らない
多くのAI開発ツールでは、セッションが変わると新しい作業領域から始まります。メモリー機能やプロジェクト用の指示ファイルによって過去の情報を引き継げますが、それは人間の担当者が持つ経験を丸ごと再現するものではありません。
実際、Claude Codeの公式資料でも、各セッションは新しいコンテキストから始まり、プロジェクトの指示ファイルや外部メモリーで知識を引き継ぐ仕組みだとされています。Anthropic：How Claude remembers your project
つまり、「前回説明したから分かっているはず」ではなく、重要な設計方針や禁止事項、テスト方法などを、AIが毎回参照できる形で残す必要があります。
3. 曖昧な指示には、AIなりの“もっともらしい答え”を選ぶ
システム開発では、正解が一つではない場面が数多くあります。
たとえば、「使いやすい画面にしてほしい」「管理者が承認できるようにしてほしい」「セキュリティにも配慮してほしい」という依頼だけでは、具体的な動きは決まりません。
- 誰が管理者なのか
- 一度承認した内容を取り消せるのか
- 承認前に通知するのか
- 間違って削除した場合に戻せるのか
- どこまで操作履歴を残すのか
こうした選択肢が未定のままなら、AIは作業を止める場合もあれば、一般的と思われる案を選んで先へ進む場合もあります。その判断が依頼者の意図と一致する保証はありません。
AIが勝手に間違えたように見えても、実際には、人間側の指示に判断材料が足りなかったというケースも少なくありません。
4. AIの生成は確率的で、100％同じ品質にはならない
一般的なプログラムは、同じ条件なら同じ結果を返します。一方、生成AIは候補の中から確率的に回答を組み立てます。同じ指示でも、表現や実装方法が変わることがあります。
OpenAIも、LLMの出力は非決定的であり、モデルの更新によって挙動も変わり得るため、継続的な評価が必要だと説明しています。OpenAI：Model optimization
これは創造性や柔軟性の源でもありますが、業務システムの品質管理では弱点にもなります。「前回うまくいったから、今回も必ず同じようにうまくいく」とは限らないからです。
5. 動いたことと、正しいことは同じではない
画面が表示された。ボタンを押せた。エラーが出なかった。
それだけでは、正しいシステムとはいえません。
計算結果が一部の条件でずれる、他人のデータが見える、同じ処理が二重登録される、通信障害時にデータが消えるなど、普段の操作だけでは見つからない問題があります。
AIはテストも作れますが、そのテスト自体がAIと同じ思い込みに基づいていれば、誤った仕様を「正しい」と確認してしまう可能性があります。
必要なのは、AIを信じることではなく、間違えても止まる仕組み
では、AIによる自動開発は危険なので使うべきではないのでしょうか。
答えは逆です。
AIの特性を理解したうえで、品質を個人の注意力ではなく、工程全体で守る仕組みを作れば、開発速度と品質を両立しやすくなります。
重要なのは、「AIに間違えないようお願いする」ことではありません。
AIが間違えることを前提に、間違いが次の工程へ流れないようにすること
そのためには、次のような多重の確認が必要です。
1. 指示を「要望」ではなく「完了条件」にする
「ログイン機能を作って」だけでなく、正常時、入力ミス時、権限がない場合、連続失敗時、退職者の扱いなど、どの状態になれば完成なのかを決めます。
また、重要な選択肢をAIに勝手に決めさせず、実装前に方針を提示させ、人間が承認する工程も有効です。
2. プロジェクトのルールを外部に記録する
設計方針、用語、禁止事項、過去の判断、テスト方法を、会話の中だけでなく文書や設定ファイルとして残します。
AIのメモリーに期待するのではなく、誰が作業しても同じルールを読み直せる状態にすることが重要です。これは人間の担当交代にも有効です。
3. 一度に大きく作らず、小さく区切る
大規模な変更を一度に任せると、何が原因で問題が起きたのか分かりにくくなります。
「計画を作る」「一つの機能を実装する」「テストする」「確認してから次へ進む」という小さな単位に分ければ、AIも情報を整理しやすく、人間も変更内容を確認しやすくなります。
GitHubも、AIに渡す作業を小さく分け、個別に実装・検証できる単位にする考え方を紹介しています。GitHub：Spec-driven development with AI
4. 静的チェックとHookで、守るべきルールを自動化する
静的チェックとは、システムを実際に動かさなくても、書き方の誤り、型の不一致、危険な処理、秘密情報の混入などを機械的に調べる仕組みです。
Hookは、「ファイルを変更したら整形する」「登録前に検査を実行する」「危険な操作は止める」といった確認を、決められたタイミングで必ず動かす仕組みです。
AIの判断に「検査を忘れないで」と頼むのではなく、検査を通らなければ先へ進めないようにします。Anthropicも、HookはLLMの判断に依存せず、決めた処理を必ず実行するための仕組みとして案内しています。Anthropic：Automate actions with hooks
5. GitHubとCI/CDを“関所”にする
AIが変更したプログラムを、そのまま本番へ反映させてはいけません。
GitHub上で変更内容を記録し、自動テスト、セキュリティ検査、人間または別のAIによるレビューを通し、すべてに合格したものだけを統合します。GitHubには、レビュー承認や必須チェックを通過しなければ変更を統合できない保護機能があります。GitHub：Managing a branch protection rule
本番反映後も、一部の利用者だけに先行公開する、異常があれば以前の状態へ戻すといった仕組みを用意します。
6. テストは件数ではなく、失敗の種類で設計する
1000件を超えるテストケースがあることは、大きな安心材料になり得ます。ただし、1000件すべてが似た確認なら、同じ盲点を1000回通過するだけです。
テストは、少なくとも次の観点に分ける必要があります。
- 通常の操作が正しく完了するか
- 入力ミスや上限値・空欄に耐えられるか
- 権限のない人が操作できないか
- 外部サービスの停止や通信障害に耐えられるか
- 過去に直した不具合が再発していないか
- 複数機能を組み合わせても矛盾しないか
- 実際の利用者の業務手順を最後まで完了できるか
さらに、AIが作ったコードとテストを別の視点で確認するため、抜き打ちテストや、意図的に異常な条件を与えるテストも必要です。
7. 重要な判断には人間を残す
金銭、個人情報、契約、権限、データ削除など、失敗時の影響が大きい変更は、人間の承認を必須にします。
OpenAIも、AIエージェントの成果は本番反映前に人間が確認し、AIレビューは人間の代替ではなく追加のレビューとして使うことを推奨しています。OpenAI：Introducing upgrades to Codex
非エンジニアが確認すべきこと
発注側がプログラムの細部を理解する必要はありません。しかし、次の質問には答えられる状態にしておくべきです。
- AIが判断に迷ったとき、誰に確認するのか
- 完成したと判断する条件は何か
- 自動的に実施される検査には何があるか
- AIが作ったテストを、誰がどのように確認するか
- 個人情報、金銭、権限に関する変更は誰が承認するか
- 本番で問題が起きた場合、どのように検知して元に戻すか
- AIが行った変更と判断の履歴が残るか
「AIを使っています」という説明よりも、これらに具体的に答えられる会社の方が、品質管理の成熟度は高いといえます。
AI自動開発で変わるのは、責任ではなく仕事の配分
AIによって、人間が一行ずつプログラムを書く時間は確実に減っていきます。一方で、何を作るのかを定義すること、選択肢を判断すること、リスクを想定すること、品質を証明することの重要性は、むしろ高まります。
理想は「人間が何もしなくてよい開発」かもしれません。
しかし、現時点で目指すべき現実的な姿は、次のようなものです。
人間が目的と基準を決め、AIが高速に実行し、機械的なガードレールと多重チェックが品質を守り、重要な判断だけを人間が引き受ける。
AI自動開発の成否を分けるのは、どのAIを使うかだけではありません。
AIが間違える可能性を前提に、どこまで確認工程を設計できているかです。
AIに丸投げする時代ではなく、AIが安全に自動化できる環境そのものを設計する時代が始まっています。
