AI開発でも品質には人の確認が必要な理由
AIを使えば、コードを書く速度は大きく上がります。では、人が確認する必要は本当にあるのでしょうか。この記事では、AI開発で品質を保つために人の確認が欠かせない理由と、確認すべき場面、現実的な進め方を整理します。新規事業でシステム開発を検討している方が、発注や社内判断の際に確かめられる観点をまとめました。
AIで開発が速くなると、何が変わるのか
生成AIをはじめとするAIは、要件の整理、設計、コードの記述、テストの作成といった開発の各工程を支援できるようになりました。人が数日かけていた作業が短時間で形になることもあり、「開発は速く、手軽になった」という実感を持つ方も増えています。
ただし、速くなったのは主に「作る作業」です。システム開発の成果は、作った量ではなく、目的に合ったものが安全に動き続けているかで決まります。作る速度が上がると、確認の作業が相対的に重くなります。
「作る」と「確かめる」は別の仕事
開発には大きく分けて、次の二つの仕事があります。
- 作る：要件をもとに、設計し、コードを書き、動くようにする
- 確かめる：目的に合っているか、誤りがないか、安全か、運用に耐えるかを判断する
AIは前者をとても得意とします。一方で後者には、「何が正しいか」という基準が必要です。その基準は、事業の目的、利用者の状況、会社のルールなど、AIに渡されていない情報の中にあることが多くあります。
作る速度だけが上がり、確かめる体制が追いつかないと、誤りを含んだまま先へ進んでしまう危険があります。人の確認が必要になるのは、この非対称があるためです。
AIが作ったものに起きやすい問題
AIの出力は、見た目にはもっともらしく仕上がります。そのため誤りに気づきにくい点に注意が必要です。ここでは、起きることがある代表的な問題を挙げます。特定の製品の話ではなく、AIを使った開発全般に当てはまる傾向として整理します。
指示の解釈が、意図とずれる
AIは与えられた指示を、自分なりに解釈して実装します。指示が曖昧だと、もっともらしいけれど意図とは違う動きになることがあります。たとえば「会員は退会できる」と指示したとき、退会後のデータを即時削除するのか、一定期間残すのかは、事業のルールや法令対応によって変わります。AIは一般的な推測で補いますが、その推測が自社の事情に合っている保証はありません。
例外や境界の条件が抜ける
通常の操作では問題なく動いても、入力が空のとき、同時に複数の操作が行われたとき、通信が途中で切れたときなど、例外的な条件で不具合が出ることがあります。テストをAIが書く場合も、AIが思いついた範囲にテストが偏るため、事業上とくに重要な例外が拾われないことがあります。
安全面の配慮が不十分になる
認証、権限管理、個人情報の扱いなどは、誤りがあると事業全体に影響します。Webアプリケーションの代表的な脆弱性については、OWASP（Open Worldwide Application Security Project）が「OWASP Top 10」として主要なリスクをまとめています。また、IPA（情報処理推進機構）も、ウェブサイト運営者向けに「安全なウェブサイトの作り方」を公開しています。こうした公的・専門的な資料の観点に照らして確認する作業は、AIの出力に対しても必要です。
動くが、あとから直しにくい
動作する状態と、保守しやすい状態は別です。命名や構造に一貫性がなかったり、似た処理があちこちに散らばっていたりすると、機能を追加するたびに修正の範囲が広がります。新規事業のように、公開後に仕様が変わり続けるシステムでは、この点があとから効いてきます。
もっともらしい誤りが混じる
AIは、存在しない関数や設定を使ったコードを出力したり、実際には確認していない内容を「確認済み」のように述べたりすることがあります。見た目が整っているほど、人が読み飛ばしやすくなります。速度が上がった分、確認の手を抜かないことが重要です。
人の確認が必要になる三つの場面
問題が起きうることは分かっても、「どこを人が見るべきか」が曖昧では運用できません。人の確認が特に必要なのは、次の三つの場面です。
1. 何を作るかを決める場面
最初の判断は、目的と範囲の決定です。誰の、どんな課題を解決するのか。最初に実現する機能はどれか。あえて作らないものは何か。これらはAIが自動で正解を出せるものではなく、事業を担う人が決めることです。
AIは「作れるもの」を広げてくれます。そのぶん、何でも作れるように見えて、範囲が膨らみやすくなります。判断の軸を持つ人がいなければ、機能は増えても事業の中心がぼやけます。
2. 出てきたものが目的に合っているかを見る場面
AIが作ったものを、仕様書のとおりかどうかだけで確認しても十分ではありません。仕様書自体が、利用者の実際の動き方と合っていないことがあるためです。
実際に触ってみて、画面の流れが自然か、現場の人が迷わないか、想定していない使い方をされないか、といった点は、人が動くものを使ってはじめて分かります。ここは、動く実物を早い段階で確認するほど修正が小さくすみます。
3. 品質と責任の最終判断をする場面
公開してよいか。個人情報の扱いに問題はないか。障害が起きたときの影響範囲はどこまでか。こうした判断には、結果に対する責任が伴います。AIの出力が誤っていたときも、事業として責任を負うのは人と組織です。
そのため、最終判断は人が行い、その根拠を説明できる状態にしておく必要があります。「AIがそう出したから」は、社内の決裁でも利用者への説明でも理由になりません。
確認を無理なく続けるための進め方
人の確認が重要とはいえ、すべてを人が一行ずつ読むのは現実的ではありません。AIで速くなった利点を活かしつつ、確認を効率よく行う工夫が必要です。
小さく区切って、早く見る
大きなまとまりを一度に作って最後に確認すると、誤りが見つかったときの手戻りが大きくなります。機能を小さく区切り、区切りごとに動くものを確認すれば、ずれが小さいうちに直せます。AIは修正の反映も速いため、この短い確認の繰り返しと相性がよい面があります。
言葉ではなく、動くもので確認する
文章の仕様は、読む人によって解釈が変わります。画面が動き、操作でき、データが保存される状態で見ると、「ここは違う」という指摘が具体的になります。言葉だけで認識を合わせようとすると、完成後に食い違いが分かる事故につながりやすくなります。
確認の観点を先に決めておく
何を基準に確認するのかが曖昧だと、確認する人によって結果が変わります。たとえば次のような観点を、事前に整理しておくと確認が安定します。
- 目的に合っているか：解決したい課題に対して、必要な操作ができるか
- 正しく動くか：通常の操作と、例外的な操作のどちらも想定どおりか
- 安全か：権限、認証、個人情報の扱いに問題がないか
- 直しやすいか：構造が整理されていて、追加や修正を行いやすいか
- 説明できるか：なぜこの仕様や実装にしたのかを、あとから説明できるか
役割を分けて、点検の目を増やす
一人が作って、同じ一人が確認すると、見落としが残りやすくなります。人でもAIでも、作る役割と点検する役割を分けることで、誤りに気づく機会が増えます。たとえば、実装を行うAIとは別に、レビューを行うAIを置く方法があります。ただしその場合も、AI同士の確認だけで完結させず、最終判断には人が関わる形にしておくことが大切です。
記録を残す
決めたこと、変更した理由、確認した結果を記録しておけば、担当者が変わっても判断の根拠をたどれます。AIを使った開発は進みが速く、あとから経緯が分からなくなりやすいため、記録の習慣は品質の土台になります。
新規事業では、確認の重みがさらに増す
新規事業のシステム開発は、既存業務のシステムとは性質が異なります。ここでは、人の確認がとくに重要になる理由を整理します。
正解が最初から分からない
既存の業務なら、現行のやり方という比較対象があります。新規事業では、何が正解かが最初から決まっておらず、市場に出して反応を見ながら決まっていきます。そのため、「仕様書どおりに作れたか」だけでは品質を判断できません。事業の仮説に対して、そのシステムが検証の役に立つのかを、人が判断する必要があります。
決裁者と現場の判断材料が違う
新規事業では、経営陣（決裁者）と現場（立案者）が同じ目的を見ているのに、判断の材料や進める速度が違うために話が噛み合わないことがあります。ずれているのは目的ではなく、進め方であることが少なくありません。
企画書や文章だけで確認すると、同じ言葉から別の完成像を思い描いてしまいます。動く実物を共有して、同じものを見ながら話すことで、「何ができるのか」が具体的になります。AIで試作が速くなった今は、この確認を早い段階で行いやすくなったともいえます。
方向転換が前提になる
公開後に仕様が変わることを前提にすると、最初の設計や構造の品質が、その後の変更のしやすさを左右します。作るのが速いだけで確認が浅いと、変更のたびに修正範囲が広がり、検証のスピードが落ちます。速さを本当に活かすには、土台の確認が欠かせません。
新規事業全体の進め方は、新規事業のシステム開発の進め方｜構想から運用までの全体像でも整理しています。また、AIモデルの進化が開発にどう関わるかについては、Claude Sonnet 5.5の発表と新規事業への影響もあわせてご覧ください。
発注する側が確かめたいポイント
AIを活用した開発を外部に依頼する場合、「AIを使っているので速いです」という説明だけでは、品質がどう守られるのかが見えません。発注側が、次の点を確認しておくと判断しやすくなります。
- 何を作るかを決める役割を、誰が担うのか
- 出てきたものの品質を、誰がどの観点で確認するのか
- 動く実物を確認できるタイミングが、早い段階にあるか
- 設計やレビューの基準が、経験にもとづいて整理されているか
- 公開後の修正や機能追加を、どのような形で続けられるのか
これらに明確に答えられる会社であれば、AIを使うことで生まれる速度と、品質を守る仕組みの両方を期待しやすくなります。反対に、AIの利用を強調しながら、確認の方法が説明されない場合は、詳しく聞いてみる価値があります。
もう一つ、自社側でも決めておきたいことがあります。それは、自社内で最終的に判断する人と、その判断の基準です。外部に依頼する場合でも、何を作るかを決めるのは、事業を担う自社の人です。ここが曖昧なままだと、AIの速度は方向の定まらない作業を増やすだけになりかねません。
まとめ
AIによって開発の「作る」部分は速くなりました。しかし、目的に合っているか、安全か、責任を持って公開できるかという「確かめる」部分は、人の判断が中心であり続けます。AIの出力には、指示の解釈のずれ、例外条件の抜け、安全面の不十分さ、保守しにくさ、もっともらしい誤りが含まれることがあるためです。
人が確認すべき場面は、何を作るかを決める場面、出てきたものが目的に合っているかを見る場面、品質と責任の最終判断をする場面の三つです。確認を現実的に続けるには、小さく区切る、動くもので確認する、観点を先に決める、役割を分けて点検する、記録を残す、といった工夫が役立ちます。新規事業では正解が最初から分からないため、この確認の重みがさらに増します。
私たちJustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただけます。開発には、複数の専門AI（要件定義・設計・DB設計・実装・テスト・レビュー）がチームで進めるLEGAREA独自の基盤「LAF」を使い、人は「何を作るかを決めること」と「品質の最終判断」を担います。仕様が固まっていない段階でもご相談いただけますので、詳しくはJustFitのサービス紹介をご覧ください。