オフショア開発のAI品質を担保する4層の手順｜発注側の実務

オフショア開発を委託しているベンダーから、「生成AIを活用して開発スピードを上げます。その分、単価も抑えられます」という提案を受けた。見積の数字は確かに魅力的だけれど、納品されたコードを見ても、どの部分を人が書き、どの部分をAIが生成したのかは判別できない。提案書に書かれているのは「AIを活用」という一文だけで、どのモデルを、どの工程で、どこまで使うのかが読み取れない。こうした状況に直面している情報システム部門の方は少なくないはずです。

やっかいなのは、AI活用を全面的に断るという選択肢が現実的ではなくなってきていることです。オフショア開発の単価は上昇傾向にあり、ベンダー側にとってAI活用は競争力を保つための必然になりつつあります。一方で発注側は、社内でコードを読める人が1〜2名しかいない、外部の第三者検証を毎回入れる予算もない、という制約の中にいます。それでも稟議では上長から「品質はどう担保するのか」と問われます。断ることも、任せきることもできない板挟みが、この問題の本質です。

この板挟みを解くうえで出発点になるのは、「納品されたコードからAIの痕跡を見抜く」という発想を捨てることです。生成されたコードを事後的に見分けようとしても、発注側のリソースでは勝ち目がありません。代わりに必要なのは、AIがどこでどう使われるのかを、発注の時点で検証可能な状態にしておくという考え方です。品質は納品時に検査するものではなく、契約・仕様・レビュー・検収という発注プロセスの各段階に、あらかじめ確認可能な要求事項として埋め込んでおくものになります。

本記事では、オフショア開発においてベンダーがAIを使う前提で、発注側が品質を担保するための手順を「可視化（契約）→ 仕様 → レビュー → 受け入れ」の4層に整理して解説します。AI生成コードで実際に起きる品質問題の類型から始めて、契約に盛り込むべき条項、レビュー要員が1〜2名でも機能する仕組みの作り方、検収時に測るべき指標までを扱います。最後に、次回のベンダー打ち合わせでそのまま提示できる確認項目のリストとしてまとめます。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

オフショア開発でAI活用が広がる背景と、品質担保が難しくなる理由

まず、なぜ今この問題が発生しているのかを整理します。ここを押さえておくと、上長や経営層に対して「担当者の勉強不足ではなく、開発の構造が変わったために従来の検収方法が効かなくなっている」と説明できるようになります。

ベンダー側がAI活用を提案する事情

オフショア開発の目的は、かつての「コスト削減」から「開発リソースの確保」「信頼できる開発パートナー探し」へと軸足が移っています（出典: オフショア開発白書2025年版、オフショア開発.com）。委託先国としてはベトナムが4割強のシェアで首位を維持していますが、現地エンジニアの人件費は上昇を続け、円安も重なって「安いから海外に出す」という前提は崩れつつあります。

この状況でベンダーが取りうる手段は、単価を上げるか、同じ単価でより多くのアウトプットを出すかの二択です。生成AIによるコード生成は後者を実現する手段として位置づけられており、日本向けオフショアベンダーの多くが「AI駆動開発」を差別化要素として打ち出しています。つまりAI活用の提案は、特定のベンダーの思いつきではなく、市場構造から生じている流れだと理解しておく必要があります。

AI駆動開発でオフショアの分業構造がどう変わるか

従来のオフショア開発は、日本側が仕様を作り、ブリッジSEが翻訳・調整し、現地のエンジニアが実装するという分業でした。工数の大半は実装が占め、品質管理も「実装されたコードをレビューし、テストする」ことを中心に組み立てられていました。

AI駆動開発が入ると、この配分が変わります。実装そのものはAIが担う割合が増え、人間の仕事は「AIに何をどう作らせるかを定義すること」と「出力を検証すること」に寄っていきます。実装工数が減る分だけ、仕様定義と検証の比重が上がるわけです。ここで見落とされやすいのが、その負荷の一部が発注側にも移るという点です。仕様の曖昧さはこれまで現地エンジニアの経験や、ブリッジSEの確認によって吸収されてきましたが、AIは曖昧なまま「それらしく動くもの」を出力してしまいます。

従来のオフショア品質管理が効かなくなる3つの前提崩れ

従来のオフショア品質管理は、次の3つの前提の上に成り立っていました。AI活用によってこれらが同時に崩れます。

3つ目が本記事の中心テーマです。1つ目と2つ目は「レビューが追いつかない」という量の問題ですが、3つ目は「そもそも何を検証すべきかが分からない」という質の問題であり、契約と体制の設計でしか解けません。

なお、AI活用以前からあるオフショア開発特有のリスク（仕様伝達のずれ、時差やコミュニケーションコスト、ベンダーロックイン等）については、オフショア開発の基礎と失敗パターンで整理しています。本記事はそれらの上に積み上がるAI固有の論点に絞って解説します。

AI生成コードで起きる品質問題の3類型

次に、実際にどのような品質問題が起きるのかを類型化します。ここで整理する3類型は、後半で扱う4層モデルの各層が「何を潰すのか」を対応づけるための共通言語になります。

類型1｜仕様の行間を読み違えたコード

人間の開発者は、仕様書に書かれていないことを経験で補完します。「この項目は既存の顧客マスタと同じ桁数だろう」「月末締めの処理だから月跨ぎの考慮が要るだろう」といった判断です。生成AIはこの補完を行いません。正確に言えば、補完はしますが、その根拠は学習データ上の一般的なパターンであって、発注元の業務実態ではありません。

結果として生まれるのが、「一見すると仕様書どおりに動くが、業務上の例外ケースで破綻するコード」です。テストケースも仕様書から生成されている場合、テストは通ってしまいます。検収時に気づけず、本番運用が始まってから月次処理で発覚する、というのが典型的な発現パターンです。

類型2｜例外処理とセキュリティが抜けたコード

生成AIが出力するコードの「動作する率」は非常に高くなっています。一方で、動作することと安全であることは別問題です。100を超える大規模言語モデルを対象にした調査では、構文的に正しいコードを出力する割合が95%を超える水準に達している一方、安全な実装と安全でない実装の選択肢がある場面で、45%のケースで安全でない方が選ばれたという結果が報告されています（Veracode 2025 GenAI Code Security Report）。同調査では、AIが生成したコードの脆弱性密度は人間が書いたコードの2.74倍に達するとも指摘されています。

「動くコードを作る能力」と「安全なコードを作る能力」の差は縮まっておらず、むしろ広がっているというのがこの調査の含意です。発注側から見ると、動作確認だけで検収してしまうと、この差がそのまま自社の運用リスクとして残ります。

類型3｜動くが引き継げないコード

3つ目は保守性の問題です。生成AIは出力するコードの構造や書き方が毎回異なるため、同一プロジェクト内でも実装スタイルが揺れます。命名規則が統一されない、同じ処理が複数箇所に重複して実装される、必要以上に抽象化された層が挟まる、といった状態が起きやすくなります。動作には問題がないため検収は通りますが、数か月後に改修しようとした段階で「読み解くのに時間がかかりすぎる」という形で顕在化します。

秋霜堂株式会社では、海外に発注されて構築された品質管理システムを、前任者が不在でドキュメントも残っていない状態から引き継ぎ、初期調査から改善対応までを継続的に実施した経験があります（アパレル品質管理システムの改善事例）。このときの初期フェーズの工数は機能追加ではなく、現状の挙動を把握し直す調査に費やされました。AI生成コードで実装スタイルが揺れた成果物は、これと同種のコストを将来に先送りしていることになります。安く早く納品されたコードの対価を、数年後の改修見積で払うという構図です。

なぜバグ検出密度では見抜けないのか

従来のシステム開発では、ソースコード量あたりのバグ件数（バグ検出密度）やテスト密度を、類似プロジェクトの統計値と比較して品質を評価する手法が広く使われてきました。AI活用開発ではこの指標が機能しにくくなります。

NTTデータの解説によれば、その理由は3つあります。第一に、動作は同じでも書き方が異なり、可読性・保守性・例外処理に問題が潜んでいる場合があること。第二に、生成AIは出力するコード量や構造が毎回異なるため、コード量に依存する指標を統計値と比較しにくいこと。第三に、生成AIがどのような誤りをどの程度含むかを事前に予測しにくいことです。代替として、密度に依存しない「観点カバレッジ」や「DDPモニタリング」といった手法が挙げられています（生成AIを使って開発したソフトウェアの品質保証｜NTTデータ）。

発注側の実務に翻訳すると、次のようになります。「バグが何件出たか」ではなく「どの観点を、どこまで確認したか」を検収の合意事項にするということです。この考え方は、のちほど扱う受け入れ基準の設計に直結します。

発注側が押さえる品質担保の4層モデル

ここからが本題です。前段で整理した3類型を、発注プロセスのどの時点で、誰が、どのように潰すのかを4つの層に配置します。

4層モデルの全体像

重要なのは、第1層がなければ他の3層は空回りするという関係です。どのツールが、どの工程で、どのデータに触れるのかが不明なままでは、レビューで重点を置くべき箇所も、検収で確認すべき観点も決められません。逆に、第1層で経路が見えていれば、限られたレビュー要員をどこに投じるかを合理的に決められます。

どの層から着手すべきか

すでに進行中のプロジェクトで、契約を今から巻き直すのが難しい場合もあります。優先順位の目安は次のとおりです。

1. 契約更新・追加発注のタイミングが近い場合: 第1層から着手します。次回の契約・注文書に条項を追加するのが最も低コストです。
2. 契約変更が当面できない場合: 第3層（レビューの仕組み化）から着手します。CI上の品質ゲートは契約書を変えなくても、開発運用の合意事項として導入を打診できます。同時に第4層の受け入れ基準を文書化し、次の検収から適用します。
3. すでに検収直前の場合: 第4層に絞ります。受け入れ基準を今から追加することはベンダーとの摩擦を生むため、「テスト観点表の提出」と「脆弱性スキャン結果の共有」の2点に絞って依頼するのが現実的です。

いずれの場合も、次の契約更新時に第1層へ戻ることを前提に計画してください。第1層を飛ばしたまま第3層・第4層だけを厚くすると、発注側の工数だけが増え続けます。

第1層｜AI利用を可視化する契約条項の作り方

この層が本記事の核心です。目的は「AIの使用を制限すること」ではなく、使われ方を後から確認できる状態にすることです。制限は関係悪化とコスト増を招きますが、可視化は双方にとって説明可能性を高める投資になります。

条項の検討にあたっては、経済産業省が公表している「AIの利用・開発に関する契約チェックリスト」が参考になります。AI利活用に関する契約を、汎用的なAIサービスを利用する「利用型契約」と、カスタマイズ型・新規開発型の「開発型契約」に大別したうえで、ユーザ・ベンダ間の契約条項を確認項目として整理した資料です（出典: 経済産業省「AIの利用・開発に関する契約チェックリスト」、2025年）。あわせて、総務省・経済産業省のAI事業者ガイドラインも、AIの開発者・提供者・利用者それぞれが取るべき対応の枠組みとして参照できます。

使用AIツール・モデルの申告と変更通知を求める

最初に入れるべきは、使用するAIツールとモデルの事前申告です。具体的には次の項目を、見積提示時または契約締結時に書面で提出してもらいます。

• 使用するAIコーディング支援ツールの製品名とバージョン
• 背後で利用されるモデルの提供元（例: どの事業者のどのモデルか）
• 利用する工程（要件整理・設計・実装・テストコード生成・レビュー支援のどれか）
• 適用する範囲（全モジュールか、特定領域に限定するか）
• 上記を変更する場合の事前通知義務と、通知の期限

ここで押さえるべきポイントは、ツール名だけでは不十分だという点です。同じ製品でも設定によって背後のモデルや送信先が変わることがあり、「どの製品を使うか」の申告だけでは経路が特定できません。モデルの提供元と、契約プラン（法人向けプランか、個人向けプランか）まで確認してください。

監査権を入れて「どこで動いたか」を後から確認できるようにする

申告だけでは実態との乖離を検知できません。そこで、開発期間中および検収後の一定期間について、AI利用状況の開示を請求できる権利を定めます。請求の対象としては次のようなものが考えられます。

• 使用ツールの管理コンソール上の利用ログ（対象期間・利用者・送信量の集計）
• モジュール単位でのAI関与度の申告（全面生成・部分生成・人手実装の区分）
• 外部AIサービスへの送信対象から除外した情報の範囲

すべてを毎回請求する必要はありません。重要なのは「請求できる」と契約に書いてあることです。行使しない権利であっても、条項の存在自体がベンダー側の運用を規律します。あわせて、開示請求に応じる際の窓口と、応答期限（例: 請求から10営業日以内）まで定めておくと形骸化を防げます。

機密度でデータと作業を分ける

オフショア開発のセキュリティ設計は、従来「誰がアクセスできるか」を軸に組み立てられてきました。AI活用が入ると、ここに「どこへ送信されるか」という軸が加わります。設計思想を含む仕様書、本番相当のデータ、顧客情報を含むログなどが、開発者の手元から外部のAIサービスへ渡る経路が生まれるためです。

現実的な設計は、情報の機密度で作業を3階層に分ける方法です。

そのうえで、入力データの学習利用の可否、事業者側でのデータ保持期間、契約終了時の消去義務を条項に落とします。「学習に使わない設定であること」をベンダーの善意に委ねず、契約プランの証跡（管理画面のスクリーンショット等）で確認するところまでを運用に含めてください。

AI生成物の権利帰属と第三者権利侵害時の責任分担

AI生成コードには、権利関係の論点が残ります。実務上、発注側が押さえておくべきは次の3点です。

1. 成果物の権利帰属: AIが生成した部分を含め、納品物の権利が発注側に移転することを明記する。生成物の著作物性そのものの議論に踏み込まず、契約上の移転・利用許諾として整理するのが実務的です。
2. 第三者権利の非侵害保証: 納品物が第三者の著作権・特許権等を侵害しないことの表明保証と、侵害が判明した場合の対応（代替実装・費用負担）を定める。
3. オープンソースライセンスの取り扱い: AI生成コードに特定のライセンス下のコードが混入するリスクに備え、使用ライブラリとライセンスの一覧（SBOM）の提出を求める。これは第4層の検収項目とも連動します。

契約前に投げるべき確認質問リスト

条項の文面を詰める前に、まず口頭で確認しておくと状況が把握できる質問です。ベンダーの回答の具体性そのものが、体制の成熟度を測る材料になります。

• どのAIツールを、どの工程で使っていますか。開発者ごとに任せている部分はありますか。
• そのツールの契約プランは法人向けですか。入力内容の学習利用はオフになっていますか。
• 再委託先やフリーランスのメンバーがいる場合、同じルールが適用されていますか。
• AIが生成したコードは、人手でレビューしてからコミットされる運用になっていますか。レビュー記録は残りますか。
• 弊社から提供する仕様書や設計資料を、AIツールに入力する運用はありますか。ある場合、どの範囲までですか。
• 過去の案件で、AI生成コードに起因する不具合が発生した事例と、その際の対応を教えてください。

最後の質問への回答が「発生していません」で終わる場合は注意が必要です。相応の規模でAIを活用していれば何らかの手戻りは起きているはずで、事例を語れるベンダーの方が、検証プロセスが機能していると考えられます。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

第2層｜AIが行間を読めない前提で仕様の解像度を上げる

第2層は、先に整理した類型1（仕様の行間を読み違えたコード）を潰す層です。ここでの主役は発注側です。

AIが補完しない3種類の前提

生成AIが補完しない前提は、大きく3種類あります。

既存システムとの整合: 稼働中のシステムの内部仕様、既存テーブルの制約、過去の経緯で残っている例外的な実装ルールは、学習データには存在しません。「既存の受注テーブルに合わせる」という一文では、AIは一般的な受注テーブルの形を推測して実装します。

業務上の例外ケース: 月末月初の締め処理、年度跨ぎ、休日の扱い、取引先ごとの個別ルールなど、業務側の担当者にとっては当たり前でも、仕様書に書かれていないことが多い領域です。ここが類型1の最大の発生源になります。

非機能要件: 想定同時接続数、レスポンスタイムの許容値、ログの出力粒度と保持期間、障害時のリカバリ手順。これらは明示しない限り実装に反映されません。「動く」ことだけが満たされたコードが出てきます。

発注側が用意すべき成果物と粒度の目安

上記の前提を明文化するために、発注側が用意する（またはベンダーに作らせて承認する）成果物の目安です。

仕様を機械可読な形式で渡すと、ベンダー側でその仕様を起点にコードを生成できるため、解釈のばらつきが減ります。この考え方は仕様駆動開発と呼ばれ、仕様駆動開発と要件定義の違いで詳しく整理しています。

仕様の精度を上げるほど発注側工数が増えるトレードオフ

ここは正直に書きます。第2層を厚くすると、発注側の工数は確実に増えます。「AI活用で工数が減る」という提案を受けたのに、自社の要件定義工数が増えるという逆転が起きます。

このトレードオフをどう見積もるかですが、判断材料は「増えた自社工数」と「防げた手戻り工数」の比較になります。仕様の曖昧さに起因する手戻りは、実装完了後に発覚するため、修正コストは要件定義段階の数倍から数十倍に膨らみます。加えて、AI活用によって実装スピードが上がると、曖昧な仕様のまま大量のコードが生成され、手戻りの規模も比例して大きくなります。

稟議で説明する際は、「AI活用によって削減される実装工数の一部を、自社の仕様定義工数に振り替える」という構図で提示すると理解を得やすくなります。総額としての削減効果は提案時の数字より小さくなりますが、そこを織り込まないまま進めると、削減されたはずのコストが手戻りとして後から請求される結果になります。

第3層｜レビューを人数ではなく仕組みで回す

第3層は、類型2（例外処理・セキュリティの欠落）と類型3（保守性の低下）を潰す層です。「独立した品質保証担当を置きましょう」という一般的な助言は、レビュー要員が1〜2名の組織には適用できません。ここでは、置けない前提での設計を扱います。

考え方はシンプルで、機械が決定論的に判定できるものは機械に任せ、人間は判断が必要な領域だけを見るという切り分けです。

自動で落とす領域

以下は、CI（継続的インテグレーション）上の通過条件として設定できる項目です。これらを満たさないコードは、そもそもレビュー対象にしないという運用にします。

これらを発注側が自前で構築する必要はありません。ベンダー側のCIに設定してもらい、その通過を納品の前提条件として合意するのが現実的です。発注側は結果レポートの提出を受けるだけで済みます。契約変更を伴わない開発運用ルールとして導入できるため、第1層の契約巻き直しが難しい場合の着手点にもなります。

閾値の設定で注意したいのは、テスト網羅率を高く設定しすぎないことです。網羅率を追うと、意味のないテストが大量生成される副作用が起きます。AI活用時はテストコード自体も生成されるため、この副作用が出やすくなります。網羅率は「極端に低い箇所を検出する」ための下限として使い、品質の証明としては次に述べる観点ベースの確認を使い分けてください。

人間が厚く見る領域の選び方

自動化で落としきれないのは、「仕様との整合」と「業務上の妥当性」です。限られた人手をここに集中させます。優先度の判断軸は、不具合が起きたときの影響の大きさです。

• 最優先: 認証・認可の実装、課金・決済処理、個人情報を扱う処理、外部システムとの連携部分
• 次点: 締め処理・集計処理など、誤りが後から発覚しやすくデータ修復が困難な箇所
• サンプリングで可: 画面表示、入力チェック、内部向けの管理機能

最優先領域については、AI生成の有無にかかわらず全量を人手で確認します。逆に、サンプリングで可とした領域は「全体の1〜2割を抜き取り、そこで問題が見つかったら範囲を広げる」という運用にします。全件を薄く見るより、重要な箇所を確実に見る方が検出力は高くなります。

レビュー指摘の記録が次のプロジェクトの資産になる

レビューで見つかった指摘は、単発の修正依頼で終わらせず、記録として蓄積してください。指摘の傾向は、次の2つの用途で効きます。

1つは、仕様の弱点の特定です。同じ種類の解釈違いが繰り返されるなら、それは実装側の問題ではなく、発注側が渡している仕様の書き方に原因があります。第2層にフィードバックする材料になります。

もう1つは、ベンダーの検証プロセスの実態把握です。人手のレビューを経ずにコミットされたコードには、「動作はするが規約から外れている」「例外処理が定型的に欠けている」といった特徴的な傾向が出ます。指摘の内容が特定パターンに偏る場合は、第1層で定めた監査権を行使して、運用実態を確認する判断材料になります。納品物からAI利用を直接見抜くことはできませんが、指摘の傾向という間接的な手がかりからは、体制の実態を推し量ることができます。

第4層｜受け入れ基準とテストでAI生成コードを検収する

最後の層は検収です。ここでの原則は、基準を検収時に作らないことです。納品物を見てから「これでは受け取れない」と伝える交渉は、双方にとってコストが高くつきます。基準は契約時または着手時に合意しておきます。

検収前に合意しておく受け入れ基準の項目

AI活用を前提とした場合に、通常の受け入れ基準へ追加すべき項目は次のとおりです。

先に触れたとおり、バグ件数や密度はAI活用開発では品質の指標として機能しにくくなります。「テスト項目を何件消化したか」ではなく「どの観点を確認したか」を合格条件に据え替えるのが、この層の要点です。

受入テスト（UAT）そのものの進め方や、発注者側が果たす役割の全体像については、テスト工程における発注者の役割で解説しています。本記事の内容は、その一般的な進め方に対してAI活用時の追加観点を重ねるものとして位置づけてください。

保守性を検収時に測る方法

保守性は主観になりやすく、検収基準に落としにくい項目です。実務で使える方法として、「引き継ぎ可能性テスト」があります。

やり方は単純で、納品物のうち代表的な機能を1つ選び、ベンダーの説明なしで、その機能に小さな仕様変更を加える場合の改修見積を出してもらうというものです。見積を出すのは、実装したメンバー以外の第三者（社内の別担当者、または別ベンダー）です。

• 見積が短時間で出せる → 構造が追える状態にある
• 「まず調査に数日必要」という回答になる → 実装の意図が読み取れない状態にある

後者の場合、その調査工数こそが、将来の改修のたびに繰り返し発生するコストです。検収時にこれを検知できれば、ドキュメントの追加や構造の整理を納品条件として交渉できます。運用開始後に気づいた場合、交渉の余地はほぼ残っていません。

検収後に問題が出た場合の取り決め

どれだけ検収を厚くしても、すべてを検知することはできません。特に類型1（仕様の行間の読み違い）は、実際の業務データが流れて初めて発覚することが多い問題です。そのため、検収後の取り決めを第1層の契約に戻して定めておきます。

• 契約不適合責任の期間（納品後何か月間か）と、その期間内の修正費用の負担
• 「仕様書に明記がなかった業務例外」に起因する不具合を、契約不適合として扱うか、追加開発として扱うかの線引き
• セキュリティ脆弱性が事後に判明した場合の対応期限と費用負担
• 第三者の権利侵害が判明した場合の対応（代替実装の実施と費用負担）

2つ目の線引きは、AI活用時に特に揉めやすい論点です。AIは仕様書の記載範囲で実装するため、「書いていなかったことは実装されていない」状態が増えます。事前に線引きの原則（例: 既存システムの挙動として自明なものは仕様書記載の有無を問わず契約不適合として扱う）を合意しておくと、事後の交渉が短く済みます。

レビュー要員が1〜2名でも回る体制のつくり方

4層モデルを実際に回すための役割分担を整理します。ここが最後の関門で、「やるべきことは分かったが、自社の人数では無理だ」という壁に対する答えになります。

ブリッジSEの役割はどう変わるか

従来のブリッジSEは、言語と文化の翻訳者であり、仕様の伝達と進捗の調整が主な仕事でした。AI駆動開発が入ると、この役割の比重が変わります。

翻訳という作業自体は、機械翻訳やAIによる支援で相当程度カバーできるようになりました。代わって重要度が上がるのが、仕様の曖昧さを検出する役割です。発注側が渡した仕様を読み、「この記述ではAIが誤解釈しうる」「業務例外の記載が抜けている」と指摘して発注側に差し戻す。この一次スクリーニングが機能すると、類型1の発生を上流で止められます。

ベンダー選定や体制協議の際は、ブリッジSEに「翻訳ができるか」ではなく「仕様の穴を指摘してくれるか」を期待値として伝えてください。この期待値のずれは、契約後に「言われたとおりに作りました」という応答が返ってくる形で表面化します。

発注側担当者の時間の使いどころ

レビュー要員が1〜2名の場合、その時間の使い方を次の順で組み替えます。

1. 基準の設定（着手前に集中投下）: 第1層の契約条項、第2層の仕様、第3層の品質ゲート項目、第4層の受け入れ基準。ここに時間を使うと、以降の工数が減ります。
2. 高リスク領域の全量レビュー（実装期間中）: 認証・課金・個人情報・外部連携。ここだけは人数に関係なく全量を見ます。
3. サンプリング検査（実装期間中）: それ以外の領域は抜き取り。問題が見つかったときだけ範囲を広げます。
4. 結果レポートの確認（納品時）: 自動化された品質ゲートの結果レポートを確認します。これは読むだけなので短時間で済みます。

全成果物を人手で確認するという方針は、AI活用によって成果物量が増える前提では成立しません。「全件を薄く見る」から「基準を決めて重点箇所を確実に見る」への切り替えが、少人数体制の唯一の解になります。

段階的にAI活用範囲を広げる進め方

最後に、AI活用の範囲そのものをコントロールする方法です。全面的に許可するか禁止するかの二択にせず、段階的に広げます。

第1段階（低リスク領域から）: 定型的な変換処理、ユーティリティ関数、テストコードの雛形など、不具合が起きても影響が限定的な領域に限定して許可します。この段階で、品質ゲートの通過状況とレビュー指摘の傾向を観測します。

第2段階（中リスク領域へ拡大）: 第1段階で問題が出なければ、画面実装や内部向け機能へ範囲を広げます。このとき、拡大の条件をあらかじめ決めておくと判断がぶれません（例: 直近3か月で重大度「高」の指摘が0件であること）。

第3段階（範囲の見直し）: 認証・課金・個人情報を扱う領域は、最後まで人手実装またはセルフホスト環境に限定したまま維持するのが無難です。ここを開放する判断は、ベンダーの検証体制が十分に確認できてからにします。

この段階的な進め方は、ベンダーに対しても説明しやすい形です。「AIを信用していない」ではなく「実績を確認しながら範囲を広げる」という提示になるため、関係を損なわずに導入できます。

まとめ｜次の打ち合わせで確認する項目

オフショア開発におけるAI活用の品質担保は、納品されたコードを見抜く技術ではなく、AI利用が検証可能な状態を発注時点で作る設計の問題です。最後に、4層モデルを次回のベンダー打ち合わせでそのまま使える確認項目として再構成します。

第1層 可視化（契約）

• 使用するAIツール・モデル・利用工程・適用範囲を書面で提出してもらう
• ツールの契約プランと、入力データの学習利用の有無を確認する
• 再委託先・フリーランスメンバーへの同ルールの適用状況を確認する
• 利用状況の開示を請求できる権利と、応答期限を契約に定める
• 機密度で作業を3階層に分け、高機密領域での外部AIサービス利用を禁止する
• 成果物の権利帰属、第三者権利の非侵害保証、SBOM提出を条項に含める

第2層 仕様

• API仕様・データモデル・業務例外一覧・処理フロー・非機能要件を明文化する
• 業務例外は業務担当者と洗い出し、仕様書に書き切る
• 自社の仕様定義工数が増えることを稟議の前提に織り込む

第3層 レビュー

• 静的解析・規約チェック・テスト網羅率・脆弱性検査・ライセンス検査・秘密情報検査をCIの通過条件にしてもらう
• 通過レポートの提出を納品の前提条件として合意する
• 認証・課金・個人情報・外部連携は全量を人手で確認し、それ以外はサンプリングにする
• レビュー指摘を記録し、仕様の弱点とベンダーの運用実態を把握する材料にする

第4層 受け入れ

• テスト観点表の提出を求め、バグ件数ではなく観点の網羅を合格条件にする
• 脆弱性スキャン結果・SBOM・保守引き継ぎ資料の提出を受け入れ基準に含める
• 代表機能で第三者に改修見積を出させ、引き継ぎ可能性を確認する
• 契約不適合の期間と、「仕様書に記載がなかった業務例外」の扱いを事前に線引きする

すべてを一度に導入する必要はありません。次の契約更新が近いなら第1層から、当面は契約を変えられないなら第3層と第4層から着手してください。上長への説明としては、「AI活用を受け入れる代わりに、可視化と検収の要求を追加する」という交換条件の形で提示すると、コストと品質の両面で筋の通った提案になります。

発注前・発注中・完了後の各フェーズで確認すべき項目を体系的に整理した資料として、システム開発 完全チェックリストをご用意しています。本記事の4層モデルとあわせて、社内の検収プロセスを見直す際にご活用ください。

オフショア開発の品質管理体制や、AI活用を前提とした契約条項の整理についてご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からのご相談も承っています。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。