株式会社リソース・シェアリング スポンサードサーチ
AIを活用したシステム開発の普及とともに、新しいタイプの失敗が増えています。
それは「速く作れたが、思った動作をしなかった」という失敗です。
AIが速くコードを書くほど、仕様の誤りやテストの漏れが後から発覚するリスクが高まります。
今回は、ITコンサルティングの現場で見てきた実態をもとに、発注者として確認すべき3つのチェック体制を整理します。
「AIで開発しています」は、安心材料にならない
「AIを活用してシステムを開発しています」と言われたとき、多くの方が「速く・安く作れそう」と感じます。
実際、開発スピードが上がることは事実です。しかし、速く作れることと正しく動くことは、別の評価軸です。
AIは、指示された仕様通りに動くコードを速く書きます。しかし、指示に含まれていないことは実装されません。
AIでのプログラミングをする前のシステム開発では、経験豊富なエンジニアが途中で「この仕様、おかしくないですか？」と気づいて補完してくれる場面がありました。
長年の現場経験からくる開発ノウハウから「この業務フローなら、こういった例外ケースが必ず発生する」という判断が、発注者が明示していない仕様の穴を埋めていたのです。
しかし、AIにはその経験則を自動で反映する機能はありません。「常識的にこうなるはず」という暗黙の期待は、AIに期待することはできず、仕様書に書かれていないことは、存在しないも同然です。
さらに、開発が速くなるほど「確認を省略する空気」が生まれます。
プロトタイプが早期に動き始めると、「今さら仕様を変えるのか」という心理的抵抗が生じ、問題の発見が遅くなるほど、修正コストは膨らみます。
「AIを活用しています」という言葉は「速く作れます」を意味します。しかし、「正しく作れます」かどうかは、別の確認が必要です。
AI活用開発で頻発する3つの品質リスク
では具体的に、AI活用開発ではどのような品質リスクが生じやすいのか。
弊社が長年、プロジェクトの現場を見てきたからこそ見えるパターンを3つに整理します。
リスク1 要件漏れ：企業固有のルールがシステムに反映されない
AIは、一般的なビジネスロジックについては、幅広い知識を持っています。
例えば、ECサイトに必要な機能は何か、受注管理システムの標準的な業務フローはどうなるか、といった問いには、精度の高い答えを返します。
しかし、あなたの会社固有の商習慣や、特定の顧客にだけ適用される例外ルールは、明示的に伝えなければ実装されません。
実際のシステム開発では、こうした企業固有のルールが大量に存在します。
受注管理システムを構築するケースを見てみると、以下のようなルールが漏れることがあります。
- 「特定の代理店経由の注文は、手数料の計算方法が通常と異なる」
- 「年度末の注文については、在庫引き当ての優先順位を通常と変える」
- 「法人顧客と個人顧客で、請求書の記載項目が異なる」
- 「特定の商品カテゴリは、受注後に社内承認フローが必要」
これらはその企業にとっては、当然知っているべき要件です。しかし、AIへの指示にこれが含まれていなければ、仕様としては存在しないものとなってしまいます。
AIが生成した仕様書は、きれいに整ったものが出力され、標準的な受注管理機能としては完璧そうに見えます。
ところが、この会社の受注管理として必要な機能としては不完全なものになってしまっている、そういう状況が起きやすいのです。
リスク2 想定漏れ：複雑な条件下で矛盾が露呈する
AIが生成した仕様は、シンプルなケースでは完璧に動作しますが、複数の条件が絡み合う状況で、予期しない矛盾が生じることがあります。
越境ECのシステムを例に考えてみましょう。
複数の通貨での決済を行う多通貨決済と、受注した商品を顧客のために確保し、実在庫から差し引いて「販売可能在庫（有効在庫）」を管理する在庫引き当ての処理を同時に行う場合、次のような問題が起きることがあります。
- 顧客が注文を確定したとき、在庫は押さえられている
- しかし決済が完了するまでの間に、為替レートが変動する
- 決済完了時点のレートで金額を確定すると、表示価格と実際の請求額がずれる
こうした組み合わせの問題は、各機能を単体でテストしても発見されず、実際に複数の処理が同時発生する本番環境になって初めて表面化します。
もう一つ例を挙げると、在庫の二重購入問題があります。
複数の顧客が同じ商品をほぼ同時に注文した場合、在庫が1個しかないのに2件の注文が通ってしまう、という状況は、同時実行制御が適切に実装されていないと起きます。
AIが生成するコードは、1件の注文処理としては正しいロジックを書きます。しかし、同時に複数の注文が来たとき、という状況を明示的に指示しなければ対応されないことがあります。
リスク3 テスト漏れ：正常系は完璧だが異常系が弱い
AIはテストコードも自動生成が可能ですので、テストを自動化することは効率化につながります。しかし、AIが生成するテストには傾向があります。
それは、うまくいく場合（正常系）のテストは充実しますが、うまくいかない場合（異常系）のテストが薄くなりやすいのです。
正常系とは、たとえば「商品を選んで、カートに入れて、決済して、注文完了画面が表示される」という一連の流れが正しく動くかを確認するテストです。
正常系とは、たとえば「商品を選んで、カートに入れて、決済して、注文完了画面が表示される」という一連の流れが正しく動くかを確認するテストで、異常系とは、問題が起きたときの挙動を確認するテストです。
具体的には次のようなケースが対象になります。
決済・通信の異常系
決済が途中でタイムアウトした場合に注文がどう処理されるか、外部の在庫管理システムへのAPI接続が失敗した場合にどう対応するか、ネットワーク障害が発生した場合にデータの整合性が保たれるか、を確認します。
同時処理・負荷の異常系
同じ商品への注文が同時に大量に来た場合にデータが正しく処理されるか、複数ユーザーが同じレコードを同時に更新しようとした場合に整合性が保たれるか、を確認します。
境界値・入力値の異常系
入力値が最大文字数・最大金額などの限界値のとき正しく処理されるか、想定外の文字や形式が入力されたときにシステムが適切に対応するか、を確認します。
正常系テストが100%通っていても、異常系が未検証のシステムは、本番環境で想定外の障害を起こします。しかも異常系の問題は、普通に使っているときは起きないため、テスト環境では発見されにくく、運用が始まってから突然、問題が露呈します。
なお、「何を作るか（要求定義）」の考え方についてはAIがコードを書く時代だからこそ、「何を作るか」が経営者の仕事になるで、「要件定義の進め方」については要件定義は「合意形成」だ。AI時代に、誰に何を依頼すべきかで詳しく解説しています。本記事と合わせてご覧ください。
なぜこれらのリスクは「見えにくい」のか
3つの品質リスクを整理しましたが、これらには共通の特徴があります。
それは、問題が表面化するのが遅い、ということです。
AIの出力は「整っているように見える」
AIが生成した仕様書やコードは、見た目が綺麗に整っています。
また、非常に論理的な構成で書かれており、一般的なベストプラクティスに沿っています。そのため、「これは本当に問題ないのだろうか」という疑問を持ちにくい、綺麗なアウトプットとして出てきます。
一方、人間が書いた仕様書や設計書には、書き方のクセや論理の飛躍、説明不足の箇所が出ます。それが「ここは要確認」というシグナルになっていた側面があります。
AIが作成するアウトプットにはそうした「ほころび」が見えにくいため、問題があってもスルーされやすいのです。
問題が表面化するのは本番稼働後が多い
さらに、要件漏れ・想定漏れ・テスト漏れの問題は、開発中やテスト中には発見されにくく、本番稼働後に顕在化するケースが多くあります。
理由は単純で、本番環境では、想定外の使い方や想定外のデータ量、想定外のタイミングが必ず起きるからです。
開発環境・テスト環境では、きれいなデータが入力され、決められたシナリオ通りにテストします。しかし実際のユーザーは、設計者が想定しなかった操作をしますし、実際の業務では、例外ケースが必ず発生します。
さらに、本番稼働後に問題が発覚した場合、その修正コストは開発段階で発見した場合と比べて大幅に増加します。
クライアントへの影響、業務の停止、データの不整合、これらへの対応も必要になってきます。
品質を守るために必要な3つのチェック体制
では、これらのリスクをどう防ぐか。
AIを活用した開発において品質を担保するためには、3つの「確認する役割」が必要です。
1. 仕様の妥当性チェック：ビジネスゴールとの整合確認
AIが生成した要件仕様が、ビジネスゴールを本当に満たしているかを確認する役割です。
「仕様書に書いてある仕様を満たしているか」ではなく、「この業務フローで現場が実際に使えるか」を検証することが重要です。これは、発注者のビジネスを理解した上で、「この仕様に○○のケースは含まれているか」「△△の例外処理はどうなっているか」を確認する必要があります。
この役割を担うためには、ITの技術知識だけでなく、業務設計やコンサルティングの経験を持つ人材でなければなりません。AIが生成した仕様書を読んで、ビジネス上の落とし穴を指摘できるかどうかが問われます。
ここで重要なのは、「AIが正しく作っているか」を確認するのではなく、「AIが正しいものを作るための指示になっているか」を確認することです。問題の多くは、AIの能力不足ではなく、指示の曖昧さから生まれます。
2. テスト仕様のチェック：異常系・例外ケースの検証
AIが生成したテストコードが、正常系だけでなく異常系・境界値・例外ケースを適切にカバーしているかを確認する役割です。
前述の通り、AIが生成するテストは正常系に偏りがちです。「このシステムでどんな異常が起きうるか」は、ビジネスの実態を知っていなければ想定できません。つまり、技術的な知識と業務の理解の両方が必要になってきます。
テスト仕様のチェックで確認すべき観点は、次の通りです。
網羅性の確認
正常系だけでなく、異常系・境界値・例外ケースのテストが設計されているかを確認します。
「うまくいく場合」だけでなく「問題が起きた場合」の動作が検証されているかが重要です。
ビジネス影響の確認
テストが落ちたとき、それがビジネスにどう影響するかを理解した上でテスト設計がされているかを確認します。
決済・在庫・顧客データなど、影響が大きい領域のテストが十分かどうかに着目します。
実環境との乖離確認
テスト環境と本番環境の差異（データ量・同時アクセス数・外部連携の有無など）が考慮されているかを確認します。
3. プロジェクト全体の管理（PM/PMO）
開発スピードが上がるほど、プロジェクト全体の管理は複雑になります。
AIで各タスクの処理速度が上がると、プロジェクト内のタスク数が増えます。また、確認が必要な成果物の量も増え、意思決定が必要なポイントが増えます。
これらを整理し、「今プロジェクトがどこにいて、ビジネスゴールに向かっているか」を常に確認するのがPM（プロジェクトマネージャー）やPMO（プロジェクトマネジメントオフィス）の役割です。
PM/PMOが果たす具体的な役割を挙げると、次のようなものがあります。
- 各工程の成果物がビジネスゴールと一致しているかの確認
- 仕様変更が発生したとき、影響範囲の特定と関係者への共有
- リスクの早期発見と対応策の検討
- 発注者（経営者・事業責任者）への定期的な状況報告
特にAI活用開発では「AIが速く作り続ける」ため、全体の整合性を確認する機会が少なくなりがちです。PM/PMOが全体を俯瞰し、定期的に立ち止まって確認する機会を作ることが重要です。
AI時代の開発パートナーに「何を確認すべきか」
ここまで読んでいただいた方には、AI活用開発の「速さ」だけを評価することの危うさが伝わったと思います。
では実際にシステム開発を発注する際、パートナーに何を確認すればよいのでしょうか。
「AIを使えますか？」から「AIの出力を検証できますか？」へ
AI活用開発が普及するほど、「AIを使って開発できます」という能力は標準化されていきます。
以前は差別化要素だったことが、当たり前になっていくのです。
一方で価値が上がっているのは、「AIが作ったものを正しく検証できる」能力です。仕様の妥当性チェック、テスト仕様のチェック、PM/PMOによる管理。これらを適切に行えるかどうかが、発注者にとって重要な選定基準になっていきます。
開発パートナーを選ぶ際の確認事項として、以下のような問いが有効です。
- 「AIが生成した仕様に対して、どのようなチェックを行いますか？」
- 「テストはどの範囲まで実施しますか？異常系・例外ケースの確認はどう行いますか？」
- 「プロジェクト中、発注者に対してどのタイミングでどのような報告を行いますか？」
- 「仕様の漏れや問題が発覚した場合、どのように対応しますか？」
これらに対して具体的に答えられるパートナーは、「速く作る」だけでなく「正しく作る」体制を持っていると判断ができます。
発注者として「確認する仕組み」を持つ
もう一点、発注者側の準備についても触れておきます。
どれだけ優れたパートナーに依頼しても、発注者が「自社の業務を正確に伝えられているか」「要求事項に抜け漏れがないか」を確認する仕組みを持っていなければ、品質リスクはゼロにはなりません。
特に重要なのは、「現場を知っている担当者がプロジェクトに関与できているか」という点です。
システムの仕様を確認するとき、経営者や事業責任者だけではなく、実際に業務を行っている現場担当者が「このシステムで本当に仕事ができるか」を確認する機会を作ることが、品質リスクを大幅に下げます。
「AIを活用しているから任せておけば大丈夫」ではなく、「AIを活用しているからこそ、発注者として確認すべき点がある」という意識を持つことが、AI時代のシステム開発では重要です。
AIは打ち出の小槌ではない
AIは、万能の打ち出の小槌ではありません。
そのため、AIでの開発プロジェクトでは、以下のことが重要になります。
- AIで開発が速くなるほど、仕様の誤りに気づかないまま進む「速さの罠」が生まれる
- AI活用開発で頻発するリスクは「要件漏れ」「想定漏れ」「テスト漏れ」の3つ
- これらは「AIの出力が整って見える」ため発見されにくく、本番稼働後に表面化しやすい
- 品質担保には「仕様の妥当性チェック」「テスト仕様チェック」「PM/PMO管理」の3つのチェック体制が必要
- パートナー選びは「AIを使えますか？」より「AIの出力を検証できますか？」で判断する
「速く作れる」時代だからこそ、「正しく作れているか」を確認する体制の価値が上がっています。システム開発の発注者として、この視点を持つことが、AI時代のプロジェクト成功につながるのです。
AI時代だからこそ、戦略は人と一緒に考えることが、最初の一歩です。
開発やコンテンツ生成はAIが担える時代になりました。しかし、何を作るか・どこを目指すかという問いに答えるのは、依然として人の仕事です。
DX推進や新規事業の立ち上げで壁にぶつかる企業の多くは、ソリューションの導入や社内人材への丸投げに終始し、課題の本質が言語化されないまま進んでしまっています。
経営とITの両方を理解した人間が、経営者と並走しながら要求定義・要件定義の段階から一緒に考える。AIはこのプロセスを補助できますが、主役にはなれません。
まだ課題が言語化できていない段階からでも、遠慮なくご相談ください。一緒に考えます。
AIが生成できないのは「実績と信頼」
ECサイトやマーケットプレイスサイトはCS-Cart国際版（公式）という選択肢
AIはコードを書けます。しかし、長年の実運用で磨かれたロジックや、世界中の事業者が検証したセキュリティを、プロンプト一つで再現することはできません。
CS-Cart国際版（公式）は、自社EC・越境EC・BtoB EC・マーケットプレイスに対応した豊富な実績ある機能をパッケージとして提供しています。
構築コストを抑えながら、堅牢なECサイトを立ち上げることができます。
スポンサードサーチ