- Published on
AI活用の開発で品質をどう担保する？リスクと確認すべき工程
要点 / TL;DR
AI活用の開発では、生成されたコードや成果物を人が確認する工程をあらかじめ決めておくことが品質担保の前提です。要件定義から受け入れテストまでの各工程で、AIの出力を誰がどの基準で見るかを決め、記録を残す運用が欠かせません。
この記事はAIの支援で作成し、人間が確認しています
- Authors
- Name
- MK1編集部
AI活用の開発で品質がぶれやすいのはなぜ？
AIを開発工程で使うと、コードの下書きやテストケースの作成など、これまで人が時間をかけていた作業を短くできます。一方で、出力は毎回同じとは限らず、もっともらしく見える誤りが混ざります。確認の工程を決めずに進めると、品質が担当者の経験に左右されます。
従来の開発でも、レビューやテストの基準を決めてチームで共有する必要はありました。AIを挟むと、生成物が正しいかを確かめる作業が新たに増えます。この作業をどの工程に置くかで、品質とスピードのバランスが変わります。AIに任せる作業と人が判断する作業を分けることが、品質管理の出発点です。
AI活用で起きやすい品質リスクとは？
AI活用の開発で起きやすいのは、動いてはいるものの意図が読めないコード、存在しない仕様やAPIを前提にした記述、テストの網羅性の低下です。いずれも成果物の見た目だけでは気づきにくいため、確認する観点を先に決めておきます。
| リスク | 起こりやすい場面 | 確認する観点 |
|---|---|---|
| 生成コードの意図が読めない | 実装 | 誰が何のために書いたコードかを説明できるか |
| もっともらしい誤り | 設計・実装 | 外部仕様や公式ドキュメントと突き合わせたか |
| テストの網羅性が下がる | テスト | 要件とテストケースの対応が取れているか |
| 入力データの取り扱い | 全工程 | 機密情報を外部サービスに送っていないか |
| 判断の根拠が残らない | 全工程 | プロンプトと出力、採らなかった案を記録したか |
生成AIに限らず、AI／MLのモデルを組み込む開発では、学習データや評価指標の妥当性も品質の一部になります。モデルの精度だけでなく、想定した入力に対して期待どおりに動くか、誤った入力のときにどう振る舞うかを確かめる工程が必要です。
工程ごとに確認すべきポイントは？
品質は、最後のテストだけで担保するものではありません。上流の工程で決めた前提が、後工程の確認項目に反映されているかを見ていきます。生成物をそのまま仕様書にせず、人の確認を挟む運用を決めておくことが前提です。
- 要件定義：AIを使ってまとめた要件が、業務の実態と合っているかを発注側が確認します。用語の定義や受け入れ条件が曖昧なまま進まないよう、要件の根拠と決定者を記録します。生成された文章をそのまま仕様書にしない運用もここで決めます。
- 設計：AIが提案した構成案を採用する場合も、採用理由と代替案を残します。外部システムとの接続仕様は公式ドキュメントで確認し、前提が変わったときの再確認手順を決めます。
- 実装：生成AIが書いたコードも、通常のコードと同じ基準でレビューします。誰が書いたかにかかわらず、意図と例外処理を説明できる状態にし、外部ライブラリの利用条件も確認します。
- テスト：テストケースをAIで作る場合は、要件との対応表を用意して抜けを確認します。自動化したテストは、判定基準が変わっていないかを定期的に見直します。テストデータに個人情報や機密情報を含めない運用も合わせて決めます。
- 受け入れテスト：発注側が実際の業務手順で操作し、期待どおりに動くかを確認します。AIが関与した箇所を把握したうえで、判定の基準を合意しておきます。確認した内容と結果は、保守運用で参照できる形で残します。
品質を担保する体制はどう作る？
体制づくりで先に決めるのは、AIの利用範囲と、レビューの責任者です。どの工程でAIを使ってよいか、生成物を誰が確認するかを取り決めておけば、確認漏れの余地が小さくなります。利用するツールが変わったときの再確認手順も、同じタイミングで決めておきます。
あわせて、プロンプトと出力、採用しなかった案を記録する運用を決めます。後から「なぜこの実装になったか」をたどれる状態にしておくと、保守運用の段階で仕様を確認する手間を抑えられます。品質保証（QA）の工程設計を外部に委ねる場合は、QA／テストの責任範囲と確認手順が提案に含まれているかを見ておくと、判断の材料になります。
セキュリティの観点では、入力してよい情報と外部サービスに送ってはいけない情報を分け、利用するツールごとにルールを決めておきます。安全な開発の考え方については、IPA（情報処理推進機構）が公開するセキュリティ対策の資料や、総務省の情報通信白書なども参考になります。
発注側は開発会社に何を確認すればよい？
発注側が確認したいのは、AIをどこで使い、どこを人が確認するかという分担です。成果物の出来だけでなく、確認の手順が提案に含まれているかを見ます。見積もりの内訳に、レビューやテストの工数が含まれているかも合わせて確認しておくと、後からの追加を避けやすくなります。
- AIを利用する工程と、利用しない工程の線引き
- 生成物のレビュー手順と、責任者の役割
- 利用するツールと、入力するデータの範囲
- テスト工程の責任範囲と、不具合が出たときの対応
- プロンプトや出力の記録を、どこまで提出できるか
- 工程の途中で利用方法を変える場合の、再確認の進め方
AIの機能を組み込む開発では、モデルの選定や評価の考え方も確認項目になります。どのモデルを選んだか、その評価を誰がどの基準で行うかは、着手前にすり合わせておくと後の認識のずれを減らせます。あわせて、運用開始後に精度の変化をどう監視するかも聞いておきます。
まとめ
AI活用の開発では、どの工程で人の確認を挟むかを先に決めておくことが、品質を保つうえでの土台になります。要件定義から受け入れテストまで、各工程で誰が何を確認するかを決め、記録を残す運用にします。ツールの導入だけで品質が決まるわけではなく、確認の手順をチームの仕事として組み込めるかがポイントです。
当社は2020年7月にベトナム・ハノイで設立し、日本企業向けのソフトウェア開発とDX支援に取り組んでいます。ISO取得に向けて、品質・情報セキュリティのプロセスを整備しているところです。AIを活用した開発の進め方や、確認工程の設計について相談したい場合は、お問い合わせからご連絡ください。
FAQ
AIが生成したコードは、そのまま使ってよいですか？
そのまま本番環境に取り込むのではなく、通常のコードと同じ基準でレビューする前提で扱います。意図と例外処理を説明できる状態か、外部仕様と食い違っていないかを確認します。
AIを使うと開発の品質は下がりますか？
使い方によって変わります。生成物を誰がどの基準で確認するかを工程ごとに決め、記録を残す運用にすれば、確認の抜けを抑えやすくなります。
テスト工程でAIを使うときの注意点は？
テストケースをAIで作る場合は、要件とテストケースの対応表を用意して抜けを確認します。自動化したテストは、判定基準が変わっていないかを定期的に見直します。
発注時に決めておくべきことは何ですか？
AIを利用する工程の範囲、入力してよいデータ、成果物の確認手順、記録の保管方法を着手前に合意しておきます。工程の途中で利用方法を変える場合の再確認の進め方も決めておくと、後からの行き違いを減らせます。
AIの利用状況はどう確認すればよいですか？
工程ごとに、プロンプトと出力、採用しなかった案の記録を提出してもらう方法が分かりやすいです。成果物だけでなく、確認の手順そのものが提案に含まれているかを見ます。
PoC（概念実証）の段階では何を確かめますか？
想定した入力に対して期待どおりに動くかと、その評価基準が業務の目的に合っているかを確かめます。モデルの精度だけでなく、確認と記録の手順が本番でも回るかを見ておきます。