AI開発ベンダーの品質体制
──発注前に確認すべき5つのチェックポイント【2026年版】

AIコーディングの普及で「速い・安い」を謳うAI開発会社が急増している。しかし業界統計では、AI生成コードの62%に脆弱性が含まれたまま本番へ渡るとされ、IPA「DX動向2026」でも「AI導入で業務効率化した」は91.6%に達する一方、「売上・利益が向上した」はわずか3.9%だった。この差を生むのは、AIが「動く」コードを速く作れるかではなく、そのコードが「使える」品質で届くかだ。本記事では、AI開発に詳しくない経営層でも商談・契約前に確認できる5つのチェックポイントを整理する。特にオフショア（ベトナム）開発会社へ発注する場面で有効な視点を加えた。

「品質保証します」という言葉は何も保証しない

多くのAI開発会社は「品質管理チームがあります」と答える。しかし「チームがある」は何も証明しない。

問題が起きるのは、ほとんどの場合納品後だ。機能追加のたびに既存機能が壊れる。本番稼働後に脆弱性が見つかる。担当エンジニアが退職するとメンテナンスできなくなる。これらは「品質管理チームがある」ベンダーでも日常的に起きている。

なぜか。AIコーディングの普及で「書くスピード」は上がったが、「確認するプロセス」の設計が追いついていないからだ。業界統計ではAI生成コードの62%に脆弱性が残ったまま本番へ渡る事例があるとされ、特にvibe coding（AIへの自然言語指示だけでコードを生成する手法）では人間によるレビューが省略されやすい。

発注者にできる防衛線は、商談の段階で「プロセスが機能しているか」を問うことだ。以下の5つのチェックポイントはその質問リストとして使える。

チェックポイント1──AI生成コードに「承認ゲート」はあるか

AIが書いたコードがそのまま本番へ入るのか、それとも人間が確認する「ゲート」が設けられているのか。これが品質体制の最初の分岐点だ。

確認すべき質問

「AIが生成したコードは、どのタイミングで、誰が、何を確認してからマージ（統合）しますか？」

回答の見方

• 良いサイン：コードレビュー担当者がAI生成コードの意図・依存関係・セキュリティパターンを確認するフローが明示できる。レビューの通過基準が定義されている。
• 危険なサイン：「AIの精度が高いのでほぼそのままです」「テストを通ればOKにしています」という回答。テストの合否だけで品質を判断しているケースは、意図しない動作・セキュリティ問題を見落としやすい。

承認ゲートの設計は、HITL5 CODEが提唱する5層の確認プロセス（アーキテクチャ・テスト・CI/CD・コードレビュー・ガバナンスの各層でAI/HUMAN/GATEの3構造を持つ）の考え方で整理できる。各層のクライテリアはベンダーが独自に設計するものだが、「ゲートが存在するかどうか」は発注者が確認できる。

チェックポイント2──テスト設計の「定義権」は誰が持つか

「テスト済みです」という言葉の中身は、誰がテストの合格基準を定義したかによって全く異なる。

確認すべき質問

「テストの合格基準（カバレッジ・異常系・セキュリティテスト）は誰が決めますか？発注者も関与できますか？」

回答の見方

• 良いサイン：発注者がテスト合格基準を定義・承認できるプロセスがある。ベンダーがその基準に照らして結果を報告する形式をとっている。
• 危険なサイン：「弊社のQA基準で行います」「詳細はお任せください」という回答。ベンダー内部の基準だけでは、発注者の期待する動作・品質水準と乖離が起きやすい。

テスト合格基準の設計については、AI生成コードのテスト品質基準5選で発注者が定義すべき5つの条件を詳述している。

チェックポイント3──セキュリティ検査のタイミングと担当者

AI生成コードのセキュリティリスクは「最後に1回チェックする」では対処できない規模になっている。業界統計（2026年）では、AI生成コードの86%がXSS防御機構の検証を通過できないという研究報告がある。

確認すべき質問

「SAST（静的解析）・DAST（動的解析）はいつ実施しますか？CI/CDパイプラインに組み込まれていますか？」

回答の見方

• 良いサイン：コードをリポジトリに統合するたびにSASTが自動実行される。セキュリティ検査の責任者が明確に定められている。
• 危険なサイン：「納品前に1回セキュリティチェックを行います」という回答。開発中に積み上がった脆弱性は最後の1回では網羅できない。

セキュリティ特化の検収設計についてはAI生成コードのセキュリティ検収ガイドを参照。

チェックポイント4──本番稼働後の変更管理体制

AIコードの問題の多くは「初回納品の後」に起きる。機能を追加するたびに既存機能が壊れる（デグレ）。修正のたびにリリースが不安定になる。これは変更管理体制がないベンダーに共通する症状だ。

確認すべき質問

「機能追加・修正を行う際、既存機能が壊れていないかどうか（リグレッションテスト）はどのように確認しますか？デグレが発生した場合のロールバック手順はありますか？」

回答の見方

• 良いサイン：ブランチ戦略が定義されている。変更ごとにリグレッションテストが自動実行される。ロールバック手順が文書化されている。
• 危険なサイン：「問題が出たら都度対応します」という回答。「バグが出たら修正する」は事後対処であり、プロセスではない。

AI生成コードの継続的ガバナンスとデグレ防止の考え方はAI生成コードの継続的ガバナンスで詳しく解説している。

チェックポイント5──日本語での意思決定体制（オフショア向け）

オフショア開発（特にベトナム）に発注する場合、技術的な品質問題は「誰が上流を担うか」で大きく変わる。優秀な開発チームがいても、要件定義・品質基準の合意・検収判断を誰が日本語で行うかが品質の分岐点だ。

確認すべき質問

「要件の確定・テスト合格基準の合意・納品物の検収判断は、日本語で完結しますか？その役割を担う担当者（ブリッジSEまたはAIディレクター）は誰ですか？」

回答の見方

• 良いサイン：N2以上のブリッジSE（BrSE）またはAIディレクターが専任で担当し、要件定義から検収まで日本語で意思決定できる体制がある。
• 危険なサイン：「ベトナムチームは優秀です」「翻訳は都度対応します」という回答。技術翻訳と品質判断は別物だ。翻訳ができても品質の合否を判断できる人間がいなければ、発注者は何を受け取ったかを自分で確認するしかなくなる。

AIディレクターが構想・要件定義から品質基準の設計・検収まで日本語で完結させる体制が、AI×低コスト・短納期・安定品質を接続する鍵になる。当社の提供モデルについてはオフショア開発×AIコード品質ガイドも参照されたい。

発注前スコアカード──5項目の早見表

商談時にこの5項目を確認した際、3項目以上で「危険なサイン」が出たベンダーとは、品質体制を整備し直す前提のコストを含めて発注額を見積もる必要がある。

まとめ──「動いた」を証明するのはベンダー、「使える」を設計するのは発注者

AIコーディングの普及は開発速度を上げた。しかし速度が上がれば上がるほど、品質確認を怠った場合の被害規模も大きくなる。

発注前の5つのチェックポイントは、ベンダーの能力を値踏みするためではなく、発注者自身がどこまで関与するかを決める準備でもある。承認ゲートがないベンダーに発注するなら、発注者側で検収ルールを設計する必要がある。テスト基準をベンダー任せにするなら、受け取ったコードを誰が、何を根拠に承認するかを自社で決める必要がある。

当社の支援実績では、発注前チェックを通じて「品質体制のどの層が空白か」を発注者と一緒に整理し、AIディレクターが要件定義から検収設計まで伴走することで、想定外の手戻りを平均60%以上削減している。

AI×ベトナムチームによる開発を「低コスト・短納期・安定品質」で成立させるには、この発注前設計が前提になる。

よくある質問（FAQ）