株式会社リソース・シェアリング スポンサードサーチ
GitHub CopilotやCursor、ChatGPTなどのAIコーディングツールは、開発の現場に急速に浸透しています。2023年以降、「AIを活用して社内ツールを作った」「開発会社がAIでコストを下げた」という話を経営者からよく聞くようになりました。AIがコードを自動生成する時代になり、「誰でも開発を依頼しやすくなった」ことは確かです。
しかし、「AIで作ったシステムが本番で想定外の動作をした」「セキュリティの問題が後から発覚した」「ユーザーが増えたら急激に遅くなった」という声も増えています。これらの問題には共通した原因があります。
それは、AIが生成したコードは、性能、信頼性、セキュリティ、運用性、ユーザビリティなど、システム全体の品質や特性を規定する、非機能要件が抜け落ちやすいからです。
つまり、AIは実装する力は持っていますが、品質基準を自分で定義する力は持っていません。
この記事では、AIプログラミングで見落とされがちな非機能要件を6つの観点で整理し、発注者・IT担当者が確認すべき対策を解説します。
機能要件と非機能要件とは？
システム開発における要件は、大きく「機能要件」と「非機能要件」の2種類に分けられます。
- 機能要件とは「システムが何をするか」です。「商品をカートに入れて購入できる」「会員登録ができる」「月次売上レポートを自動集計する」といった、システムの機能そのものを指します。
- 非機能要件とは「機能（何をするか）以外の、性能・信頼性・セキュリティ・運用性・ユーザビリティなど、システム全体の品質や特性を規定する要件」です。画面表示速度・稼働率・データ保護などが該当し、安定稼働とユーザー満足度に直結します。
| 区分 | 問い | 定義 | 例 |
|---|---|---|---|
| 機能要件 | 何ができるか | システムが行うべき処理・動作 | 商品購入・会員登録・CSV出力 |
| 非機能要件 | どのように動くか | システムの品質・特性・制約 | レスポンス速度・稼働率・セキュリティ・耐障害性 |
機能要件はユーザーが画面で確認できるため、発注者も検証しやすく、AIも生成しやすいです。
問題は非機能要件です。「エラー時にどう動くか」「高負荷時に何が起きるか」などは、通常の動作確認では見えてきません。
非機能要件が見落とされると何が起きるか。
「処理が遅くて使えない」「アクセスが集中したら落ちた」「セキュリティの欠陥が後から発覚した」という問題が本番稼働後に噴き出します。発覚後の改修コストは、事前に定義していた場合の数倍〜数十倍に膨れ上がることがほとんどです。
非機能要件の6大項目（IPA「非機能要求グレード」）
IPA（独立行政法人 情報処理推進機構）が公開している非機能要求グレードは、システム発注者が非機能要件を定義するための実践的な業界標準ガイドラインです。以下の6項目で構成されています。
| 項目 | 定義 | 具体例 |
|---|---|---|
| 可用性 | システムを安定して利用し続けられる能力。稼働率や障害発生時の対応レベルを規定する | 稼働率99.9%・障害復旧2時間以内 |
| 性能・拡張性 | 処理速度（レスポンス）や、データ量・アクセス増に対する許容度と将来の拡張性 | 画面表示2秒以内・同時接続1万人・データ増加への対応計画 |
| 運用・保守性 | システム監視・バックアップ・バックアップ復旧・メンテナンスのしやすさ | 自動バックアップ・監視アラート・障害復旧手順の整備 |
| 移行性 | 旧システムから新システムへデータを安全かつ円滑に移行する能力 | データ移行計画・切り戻し手順・移行テストの実施 |
| セキュリティ | 不正アクセス・情報漏洩・改ざん防止など、情報資産を守る能力 | 通信の暗号化・アクセス権限管理・改ざん検知 |
| システム環境・エコロジー | サーバー室の物理環境（耐震・温度・湿度）や、省電力化などの環境負荷への配慮 | 耐震・温度・湿度管理・消費電力目標・環境負荷基準 |
IPAの6項目はシステム開発全般に適用できる汎用的な分類です。AIプログラミングでは、これらの標準的な分類に加えて、AI固有のリスクが新たに生じます。
この記事で取り上げる6項目は、IPAの分類を参照しつつ、AIプログラミング特有の失敗パターンが顕在化しやすい観点に絞って再構成したものです。
| IPA分類 | この記事での扱い |
|---|---|
| セキュリティ | セキュリティ（学習データ漏洩・生成コードの脆弱性） |
| 可用性 | 可用性・信頼性（ハルシネーション・外部APIのダウン） |
| 性能・拡張性 | 性能・拡張性（推論時間・コスト爆発） |
| 運用・保守性 | 運用・保守性（ログ管理・AI品質の評価） |
| 移行性 | データ移行・整合性（モデルアップデートによる挙動変化） |
| （AI固有・IPAに該当なし） | 著作権・コンプライアンス（AI生成物の権利・規制対応） |
「システム環境・エコロジー」はシステム開発全般において重要ですが、AIプログラミング固有のリスクが特に高い観点ではないため、この記事では取り上げていません。代わりに、AIならではのリスクとして「著作権・コンプライアンス」を6項目目に加えています。
なぜAIは非機能要件を漏らしやすいのか
AIがコードを生成するとき、最も力を発揮するのは「与えられた要件を満たす実装を作る」という部分です。「ユーザーからデータを受け取り、DBに保存する」という処理を指示すれば、その処理は動きます。
しかし、「そのデータに悪意ある入力が含まれていたらどうするか」「100人が同時にアクセスしたらどうなるか」「このAPIが停止したときに代替手段は何か」という問いは、指示に含まれない限り、AIから自発的には出てきません。
AIは優秀な「実装者」ですが、「品質の仕様書を自分で書く設計者」ではないのです。発注者・IT担当者側が非機能要件を事前に定義して指示に含めるか、実装後に検証する体制を整えておく必要があります。
AIを使った開発が速くなったからこそ、品質定義が甘いまま本番稼働になるリスクも高まっています。「動くものができた」という確認だけで完結してしまうと、後から大きな問題が噴き出します。
AIプログラミングで漏れがちな非機能要件6選
ここでは、AIプログラミングで特に漏れやすい非機能要件の6項目について、具体的なリスクと確認すべきポイントを詳しく見ていきます。
1. セキュリティ（機密情報・入力フィルタ）
AIプログラミングにおけるセキュリティ上のリスクは、3つの方向から生じます。
1つ目は「AIにデータを渡す際のリスク」です。
生成AIのAPIを使って開発する場合、入力したデータが学習に使われる可能性があります。顧客情報・社内の機密データ・個人情報を含むプロンプトをそのままAIに送ってしまうと、情報漏洩につながるリスクがあります。特にChatGPT APIなど外部サービスを使う場合は、利用規約を確認し、「入力データが学習に使用されない契約（ゼロデータリテンション）」に対応しているかを確認することが重要です。
実際の事例：2023年、Samsungのエンジニアが機密のソースコードや会議録をChatGPTに入力し、デバッグや要約を行わせたことで、そのデータがOpenAI側の学習データに取り込まれるリスクが発生しました。
2つ目は「生成されたコードのセキュリティ品質」の問題です。
AIは動作するコードを素早く生成しますが、プロンプトインジェクション（悪意ある入力によってシステムを誤動作させる攻撃）への対策や、SQLインジェクション対策、XSS（クロスサイトスクリプティング）対策が抜け落ちていることがあります。AIは「動く最短経路」を選ぶため、セキュリティ強化のための追加処理は後回しになりがちです。
3つ目は「ソフトウェアサプライチェーン攻撃に対する脆弱性」です。
AIがコードを生成する際、外部のライブラリやパッケージを利用するコードを提案することがあります。しかし、AIは推奨するパッケージが最新の安全なバージョンかどうか、あるいはそのパッケージ自体が悪意ある改ざんを受けていないかを検証しません。攻撃者が正規パッケージに似た名前の偽パッケージを公開する「タイポスクワッティング」や、正規パッケージそのものに悪意あるコードを混入させる「依存関係ハイジャック」は、AIが生成したコードを通じて開発者が気づかないまま取り込んでしまうリスクがあります。AIを活用した開発スピードの向上は、こうした依存関係の精査を省略しがちにするという副作用も持っています。
実際の事例：月間9500万ダウンロードを超えるAIライブラリ「LiteLLM」がマルウェアに汚染されていた事件が判明しました。pipでインストールしただけで、SSHキーやAWSの認証情報が外部に流出する仕組みが仕込まれていました。
トレンドマイクロ：AIゲートウェイがバックドアに：LiteLLMサプライチェーン侵害の内幕
発注者として確認すべき点
- 入力データのサニタイジング（マスキング・フィルタリング）は実装されているか
- API利用規約でデータの取り扱いを確認しているか（学習利用の可否）
- OWASP Top 10（Webアプリケーションの主要脆弱性）に基づくセキュリティチェックを実施しているか
- AIが提案したライブラリ・パッケージのバージョンと安全性を確認しているか
- 依存パッケージの脆弱性スキャン（SCA：ソフトウェアコンポジション解析）を導入しているか
2. 可用性・信頼性（ハルシネーション・外部APIのダウン）
AIを組み込んだシステムで特有のリスクが、ハルシネーション（AIが事実と異なる内容を自信を持って回答する現象）と、外部AIサービスのダウンリスクです。
ハルシネーションが起きたとき、「誰が責任を取るのか」「どのように訂正するのか」を事前に定義しておかないと、誤った情報がシステム上で拡散されます。例えば、顧客向けチャットボットが誤った商品情報や法律解釈を自信を持って回答した場合、企業の信頼を大きく損ないます。
また、ChatGPTやClaudeなどの外部APIは100%稼働を保証していません。API障害が発生した際に「システム全体が停止する」設計になっていると、業務に甚大な影響が出ます。「AIがなければ何もできない」状態は、ビジネスリスクです。
実際の事例：Air Canadaのチャットボットが誤った払い戻しポリシーを案内し、2024年2月にカナダの民事裁判所が企業責任を認定しました。「チャットボットの発言であっても会社は責任を負う」という先例となった事件です。
実際の事例：実際の事例：Anthoropicで2026年3月2日に、世界的大規模障害が発生し、Claude.aiおよびAPI、さらにターミナル操作用AI「Claude Code」が断続的に停止しました。これにより、AIと対話しながらコードを書くフローに依存していた開発現場で「AIがいないとコードが書けない」という生産性危機が発生しました。
発注者として確認すべき点
- AIの回答に「参考情報として提示し、正確性を保証しない」という注記や、回答根拠（参照ソース）の表示は設計されているか
- 外部AIサービスがダウンした際のフォールバック（代替動作・手動対応への切り替え）は定義されているか
- AIが答えられない場合（不確かな回答）は、人間オペレーターにエスカレーションする仕組みがあるか
3. 性能・拡張性（推論時間・コスト爆発）
AIを使ったシステムでは、利用者が増えるほどコストが急増するリスクがあります。
生成AIのAPIは、呼び出し回数とトークン数（処理する文字量）に応じた従量課金が基本です。開発テスト段階では少人数での利用なのでコストが見えにくいですが、本番稼働でユーザーが増えると、月額のAPI費用が想定の10倍・20倍になることもあります。
また、大規模言語モデルの推論（回答生成）には時間がかかります。ユーザーが「3秒以上待つとページを離脱する」というデータがある中、AIが回答を生成するのに5〜10秒かかる設計になっていると、UXに深刻な影響が出ます。「レスポンスの目標値」が要件として定義されていない開発は、後から大きな問題になります。
実際の事例：AI開発ツールのReplitは、AI機能を積極的に拡充した結果、推論コストの急増により粗利益率が36%からマイナス14%に急落しました。テスト段階では少人数利用のためコストが見えにくく、本番スケールで初めて問題が顕在化した典型例です。
発注者として確認すべき点
- APIのコスト試算は行われているか（想定ユーザー数 × 1回の呼び出しコストで月額試算）
- レスポンスの目標値（例: 3秒以内）は要件として定義されているか
- 同じ問い合わせに対してAPIを何度も呼ばないキャッシュ機能は実装されているか
- 月額コスト上限のアラート設定・緊急停止の仕組みはあるか
4. 運用・保守性（ログ管理・AI品質の評価）
AIを活用したシステムで最も見落とされやすいのが、「本番稼働後の監視と評価」の設計です。
通常のシステムでも、エラーログの保存や監視設定は重要です。AIを組み込んだシステムでは、それに加えて「AIへの入力（プロンプト）と出力（回答）のログ保存」が必要です。AIの品質問題（誤った回答・意図しない動作）の原因を調査するには、当時の入力と出力の記録が不可欠だからです。ログがなければ、「どの入力が問題を引き起こしたか」を特定できません。
また、AIの精度は一定ではありません。モデルのアップデートや入力パターンの変化によって、同じシステムでも回答品質が変動します。「AIが正しく動いているか」を継続的に測定・改善するパイプラインがなければ、品質の劣化に気づかないまま運用を続けることになります。
実際の事例：2024年11月20日のGPT-4oアップデート後、file_search機能を使うワークフローで深刻な品質劣化が発生しました。ログや定期的な品質評価の仕組みがなかった開発者は、ユーザーからの苦情が届くまで異変に気づけなかった事例がOpenAIのコミュニティに多数報告されています。
発注者として確認すべき点
- プロンプトと回答のログは保存されているか（トラブル調査のため）
- エラー発生時にアラートが届く監視設定はされているか
- AIの精度を定期的に評価する仕組み（テストケースと評価指標）はあるか
- 開発会社との契約に「AI品質の定期レポート提出」が含まれているか
5. データ移行・整合性（モデルアップデートによる挙動変化）
AIモデルは定期的にアップデートされます。OpenAIのモデルバージョン変更やAnthropicのモデル更新など、モデルが変わると同じ入力に対する回答が変わる可能性があります。
これは、AIを使って過去のデータを分類・変換した結果が、モデルアップデート後に再処理したものと一致しなくなる「データの一貫性問題」を引き起こします。例えば、「AIで商品説明文を自動生成していたが、モデルが変わったら文体や内容が変わってしまった」「AIで分類した顧客データのカテゴリが、再処理後に異なる結果になった」といった問題が実際に起きています。
また、AIを活用した既存システムから新システムへの移行時に、「AIが生成したデータをそのまま引き継いでよいか」という整合性の問題も生じます。
実際の事例：OpenAIは2025年7月にGPT-4.5 APIを廃止し、GPT-4.1への移行を強制しました。モデルが変わると同じプロンプトでも出力が変わるため、本番稼働中のシステムの動作確認・プロンプト調整・出力品質の再検証が多数の開発者に発生しました。
発注者として確認すべき点
- 使用するAIモデルのバージョンは固定されているか（自動アップデートで挙動が変わらないか）
- モデルをアップデートする際は、旧モデルとの比較テスト（A/Bテスト）を実施する体制があるか
- AIが生成したデータは、どの時点のどのモデルで生成したものかが記録・管理されているか
6. 著作権・コンプライアンス
AIが生成したコードやコンテンツが、既存の著作物を模倣・複製している可能性があります。GitHub Copilotがオープンソースコードをそのまま出力した事例のように、AIのトレーニングデータに含まれるコードを「再現」してしまうリスクは現実に存在します。
ビジネス利用において著作権侵害が発覚した場合、法的リスクだけでなく、システムの作り直しという実害も生じます。特に受託開発では、成果物の著作権帰属が曖昧なケースも多く、「AI生成物の権利は誰のものか」という問いに対して、契約上の取り決めが不十分なことがよくあります。
また、業界・業種によっては、AI活用に関するコンプライアンス要件が存在します。金融機関では金融庁のAIガイドラインへの対応、医療・ヘルスケア分野では医療機器規制への注意が必要です。AI活用が「規制に抵触しないか」を事前に法的視点で確認しておく必要があります。
実際の事例：2022年に提訴されたGitHub Copilot著作権訴訟では、AIがオープンソースコードを学習・再出力する行為が著作権・ライセンス違反にあたるかが争われています。2024年7月にDMCA請求は棄却されたものの、オープンソースライセンス違反の主張は継続中です。AI生成コードの権利問題は法的に決着していない領域であることを示す事案です。
発注者として確認すべき点
- 生成されたコードに著作権侵害チェックを実施しているか
- 使用するAIサービスの利用規約で「ビジネス利用・商用利用」が明示的に許可されているか
- 業界固有の規制（金融・医療・教育など）への対応は事前に確認されているか
- AI生成物の権利帰属（誰が著作権を持つか）が開発契約で定義されているか
非機能要件の漏れを防ぐ3つの方法
ここまで6つの非機能要件とリスクを紹介しました。「発注者側がすべてを把握するのは難しい」と感じた方もいるかもしれません。ここでは、現実的に漏れを防ぐための3つのアプローチを紹介します。
方法1：「非機能要求グレード」でチェックリストを作る
記事の前半で紹介したIPA（独立行政法人 情報処理推進機構）の非機能要求グレードは、無料で公開されている業界標準のガイドラインです。6項目すべてについて「稼働率は何%か」「同時接続数の上限は何人か」といった具体的な数値目標を設定するためのフォーマットが用意されています。
このガイドラインをベースに「自社のシステムでは何が特に重要か」を発注前に整理すると、開発会社との認識合わせに活用できます。すべての項目を満たす必要はありません。「このシステムで特に重要な観点はどれか」を3〜4項目に絞り、具体的な数値目標とともに要件定義に組み込むことがポイントです。
方法2：AIに「意地悪な質問」をする
開発依頼にAIを活用するなら、リスク洗い出しにもAIを使うことができます。非機能要件の漏れを防ぐには、システム仕様を固める段階で、AIに対して以下のような「ワーストケース質問」を投げかける方法が有効です。
例えば:
- 「このシステムで起きうる最悪のセキュリティ事故は何ですか？」
- 「この機能が停止したとき、業務にどんな影響が出ますか？」
- 「利用者が10倍に増えたとき、何が壊れますか？」
- 「このシステムを悪用しようとしたら、どんな方法がありますか？」
- 「このAPIが使えなくなったとき、代替手段はありますか？」
こうした質問をAIにぶつけると、見落としていたリスクが可視化されます。開発会社への発注前に、自社でAIとのディスカッションを行う「事前リスクチェック」として活用できます。コストはゼロで、30分もあれば主要なリスクを洗い出せます。
方法3：受け入れ検収の条件にセキュリティ診断と性能測定を含める
機能要件は「ボタンが動く」「データが保存できる」と画面で確認できます。しかし非機能要件は、通常の動作確認では問題が見えてきません。セキュリティの脆弱性も、性能の限界も、ログの不備も、本番稼働後に初めて発覚するケースがほとんどです。
発注者が取れる最も実効性の高い対策は、「検収条件に非機能要件の確認を明示的に含めること」です。契約・発注書の段階で以下を要件として定義しておくと、開発会社は最初から非機能要件を意識して実装を行います。
- セキュリティ診断の実施と結果レポートの提出（OWASP Top 10ベース、または第三者診断）
- 性能測定の実施と結果の提出（想定同時接続数でのレスポンスタイム計測）
- ログ・監視設定の確認（プロンプト・回答ログの保存設定、アラート設定の動作確認）
- AI利用規約・著作権チェックの確認書の提出
非機能要件は、検収条件に明記して初めて機能します。発注書・契約書の段階で上記を「納品物の一部」として定義しておくことが、最も確実な対策です。
AIは「実装者」──品質保証の責任者は人間である
AIは非常に優秀な「実装者」です。コードを書くスピード、量、機能的な正確性において、人間を大幅に超えるケースが増えています。
しかし、AIは「品質基準を自分で設定する品質保証の責任者」にはなれません。セキュリティ要件、可用性目標、コスト上限、著作権への配慮──これらはすべて、人間が価値判断をして定義するものです。
機能要件（何ができるか）はAIが生成してくれます。しかし非機能要件（どのような品質で動くか）は、人間が定義しなければ必ず漏れます。AIを使った開発が速くなったからこそ、品質定義が甘いまま本番に出てしまうリスクも高まっています。
この記事で紹介した6つの非機能要件は、「AIに任せる前に人間が確認すべきこと」の出発点です。完璧なチェックリストを作ることが目的ではなく、「うちのシステムでは何が特に重要か」を意識して発注・開発に臨むことが大切です。
なお、「AIでゼロからシステムを作る」のではなく、CS-Cartが公式にリリースしているCS-Cart 国際版のようなパッケージを活用する場合は、セキュリティパッチの適用・パフォーマンスの最適化・コンプライアンス対応のアップデートが継続的に提供されるため、非機能要件の多くをパッケージ側に委ねることができます。「どこまで自分で作り、どこをパッケージやツールに任せるか」という選択自体が、品質リスクを管理するための戦略の一つです。
AIを活用したシステム開発の要件定義支援から、非機能要件のレビュー、品質チェック体制の構築まで、弊社ではITコンサルティングとして伴走型でサポートしています。「AIで開発しているが、品質面に不安がある」「発注前に要件の抜け漏れを確認したい」という方は、お気軽にご相談ください。
AI時代だからこそ、戦略は人と一緒に考えることが、最初の一歩です。
開発やコンテンツ生成はAIが担える時代になりました。しかし、何を作るか・どこを目指すかという問いに答えるのは、依然として人の仕事です。
DX推進や新規事業の立ち上げで壁にぶつかる企業の多くは、ソリューションの導入や社内人材への丸投げに終始し、課題の本質が言語化されないまま進んでしまっています。
経営とITの両方を理解した人間が、経営者と並走しながら要求定義・要件定義の段階から一緒に考える。AIはこのプロセスを補助できますが、主役にはなれません。
まだ課題が言語化できていない段階からでも、遠慮なくご相談ください。一緒に考えます。
AIが生成できないのは「実績と信頼」
ECサイトやマーケットプレイスサイトはCS-Cart国際版（公式）という選択肢
AIはコードを書けます。しかし、長年の実運用で磨かれたロジックや、世界中の事業者が検証したセキュリティを、プロンプト一つで再現することはできません。
CS-Cart国際版（公式）は、自社EC・越境EC・BtoB EC・マーケットプレイスに対応した豊富な実績ある機能をパッケージとして提供しています。
構築コストを抑えながら、堅牢なECサイトを立ち上げることができます。
スポンサードサーチ