AIで作られたアプリに別の品質基準が要るのか

NIST Secure Software Development Framework 1.1は、特定の言語やコーディング道具ではなく、ソフトウェア開発ライフサイクル全体に適用する安全な開発の実務を示します。[1] OWASP ASVS 5.0も、アプリケーションをどの道具で書いたかではなく、認証・権限・入力・データ保護・依存関係・ログといった技術的統制が正しく働くかを検証します。[6] フレームワークが1.2の草案へ進み、[2] 生成AIと二重用途の基盤モデル向けのコミュニティプロファイルが別に出ていても、[3] 検証の実務そのものが道具ごとに分かれるわけではありません。

AIコーディングはこの基準を置き換えません。代わりに六つの問いを早く表に出します。作成者がコードと設定のすべての挙動を説明できるか、認証と権限が画面だけでなくサーバーでも適用されるか、どの外部パッケージとAPIが追加されたか、機密情報がブラウザや保管庫、ログに露出しないか、成功経路だけでなく失敗・再試行・重複要求も設計されているか、デプロイ後に問題を見つけて元の状態へ戻せるかです。

DORAの2025年の調査は、AIを組織の既存の強みと弱みをともに増幅する要素として説明します。[5] NISTの2026年のAI支援コーディングの議論も、交渉不能な制約条件とドメイン規則を明示的に与える取り組みを提案します。[4] AIが使われたという理由で検証の原則が変わるのではなく、暗黙に残していた要求と制約を明示する必要が大きくなるのに近いのです。

機能一覧より先に失敗の境界を描く

検証範囲を決める前に、各機能へ七つの問いを付けてみます。答えが利用者・組織・金銭・外部システムの境界を一つでも越えるなら、画面で正常に動くかを確かめるだけでは足りません。

APIを直接呼ぶ、識別子を変えてみる、同じ要求を繰り返す、外部システムが遅く応答するか失敗する状況まで確認する必要があります。AIで作られたアプリの検証範囲を決めるのは、誰がコードを書いたかではなく、この境界をいくつ越えるかです。

確認する問い
検証が深くなる条件
誰がこの機能を実行できるか匿名利用者、一般利用者、他組織の利用者、管理者の間に境界がある
誰のデータと状態を扱うか個人情報、他の利用者のデータ、組織別データ、重要な業務記録を読むか変える
外部効果が発生するか決済、返金、メッセージ送信、外部API更新、ファイル削除のようにアプリの外に結果が残る
失敗を戻せるか削除・送金・送信・権限変更のように自動取消が難しいか、原状復帰の方法が不明である
同じ要求が繰り返されるとどうなるか再読み込み、再試行、ネットワークのタイムアウト、ジョブ再実行が重複結果を生む
問題に気づけるか利用者の申告前に失敗・悪用・欠落を見つけるログと通知がない
復旧できるかバックアップはあるが復元手順が未検証か、変更前の状態へ戻す方法がない
失敗の境界を問う — 機能ごとに付けて検証の深さを分ける
サービスの仕組み

正常系の先にある例外も検証 — 実装された動作から要件を復元し、入力、権限、外部呼出しの例外経路を実行して確認します。

検証の深さを三段階に分ける方法

ここでいう三段階は、アプリ全体のリリース判定ではありません。各リスク領域でどの水準まで証跡を確保すべきかを区別する方法です。

リリース前検証の領域は、正常経路を通っただけでは足りません。権限のない要求、改ざんされた値、重複要求、タイムアウト、部分失敗、復旧経路まで実際に実行した証跡が要ります。後続改善が可能は、検証しなくてよいという意味ではありません。その領域が機能上存在しないか、必須の統制がすでに検証されたうえで残る改善だけを後回しにできる、という意味です。

リリース前に検証
その機能を外部に出す前に必ず確認すべき範囲です。失敗するとアカウント乗っ取り、権限昇格、他人のデータの露出・改変、金銭損失、機密情報の漏えい、戻しにくい外部効果が発生します。
条件付きで追加検証
基本の統制は動いても、使い方や規模によって範囲を広げるべき区間です。複数組織、複数の役割、ソーシャルログイン、定期課金、大量処理、非同期処理、外部事業者の障害が条件になります。
後続改善が可能
最小の安全基準がすでに満たされ、残る改善がアクセス統制・データ整合性・金銭効果・検知・復旧の成否を変えない場合です。検証しなくてよいという意味ではありません。

十二のリスク領域をどう分けるか

次のマトリクスは、OWASP ASVS 5.0とOWASP Top 10:2025、API Security Top 10:2023、Web Security Testing Guide 4.2のリスク・検証項目を、リリース前の範囲決定に合わせて組み直したものです。[6][9][10][8] 三段階の名称と分類の仕方は、OWASPやNISTの公式な採点体系ではなく、この記事の意思決定の枠組みです。

リスク領域
リリース前に検証
条件付きで追加検証
後続改善が可能
認証アカウントや保護機能があるなら、登録・ログイン・ログアウト・セッションの期限と失効・アカウント復旧・認証迂回・利用者列挙を確認する。認証が要るAPIをセッションなしで直接呼んでも拒否されるべきである。管理者や機微な機能にはリスクに見合う再認証が要る。ソーシャルログイン・OIDC・SSO、アカウント連携、複数端末セッション、認証手段の変更、復旧手段の紛失、長時間セッションを使うなら関連する失敗・乗っ取りの筋書きを加える。パスキーの拡大、セッション管理画面、ログイン案内文は、基本の認証・復旧・セッション統制が検証された後に進める。
権限複数の利用者・組織・役割・非公開オブジェクトがあるなら水平・垂直の権限昇格を直接検証する。URLやオブジェクトIDを変えてAPIを直接呼んでも他の利用者・組織のデータに届かず、管理機能も実行できないこと。権限はサーバーで既定拒否として適用する。共有リンク、所有権移転、役割の委任、サポート担当の代行、大量参照・修正、組織移動があるなら状態遷移の前後で権限をさらに確認する。役割管理画面の使いやすさや権限説明の改善は、サーバー権限モデルと監査記録が検証された後に回す。
データの読み取り・変更・削除個人情報・組織データ・業務記録を扱うか、データを変え消すなら、所有権、組織の隔離、入力検証、同時更新、部分失敗、トランザクション処理、削除範囲と復元可能性を確認する。読み・書き・削除の権限は個別に検証する。取り込み・書き出し、大量修正、保存期間、データ移行、検索索引やキャッシュと原本の整合、複数システム間の同期があるなら例外と再処理の範囲を広げる。一時保存の履歴、変更比較の画面、便利な復元画面は、データ整合性と実際の復旧経路が確保された後に改善する。
決済・金銭効果決済、返金、ポイントやクレジット、有料権限の付与が一つでもあるなら、金額・通貨・注文所有者の検証、クライアント値の改ざん、二重送信、再試行とタイムアウト、冪等性、Webhookの偽造と再送、返金・補償、取引照合を検証する。成功画面だけでは足りない。定期更新、部分返金、クーポン、税、日割り、決済手段の変更、未収、取消の紛争があるなら状態の組み合わせと会計・権限の整合をさらに検証する。領収画面、決済分析ダッシュボード、案内文は、取引の整合性・重複防止・照合の仕組みが検証された後に改善する。
外部API外部APIが認証・決済・中核データ・メッセージ送信・外部状態の変更に関わるなら、認証情報の範囲、要求と応答の検証、タイムアウト、再試行、重複処理、Webhookの検証、失敗時の内部状態、異常応答と部分成功を確認する。外部応答を信じて内部の権限や金額を決めない。事業者の障害、レート制限、APIバージョンの変更、サンドボックスと本番の設定分離、障害時の代替経路と機能縮退が必要なら追加で検証する。付加情報の参照のように失敗しても中核状態が変わらない連携は、隔離された失敗処理が検証された後に案内や代替画面を改善する。
機密情報・資格情報本番APIキー、DB資格情報、署名鍵、管理者トークンがあるなら、ソース・リポジトリ履歴・ブラウザバンドル・エラー応答・ログに露出しないか確認する。開発・検証・本番の環境を分け、最小権限と失効・交換の経路を検証する。短期資格情報、自動ローテーション、機密情報の目録、緊急アクセス、テナントやサービスごとの鍵分離が必要ならライフサイクル検証を広げる。失効通知、ローテーションの自動化、管理メタデータの改善は、安全な注入・分離・失効の基準が検証された後に進める。
依存関係認証・暗号・決済・ファイル処理など中核経路のパッケージの出所が不明、実際に到達する経路に既知の重大な脆弱性がある、インストールスクリプトが過剰な動作をする、のいずれかなら解決まで深く検証する。ビルドの再現性とロックファイル・成果物の一致も確認する。間接依存の目録、SBOM、私設レジストリ、更新方針、ライセンス、保守終了、パッケージ名の取り違え、サプライチェーンの変更をさらに確認する。脆弱性の一覧画面や更新の自動化は、既知の重大な問題と中核依存の出所を処理した後に改善する。
利用者入力入力がDB・HTML・ファイル・コマンド・外部URL・他の利用者の画面・外部ツールへ渡るなら、サーバー側検証、出力文脈ごとのエンコード、クエリのパラメータ化、アップロード制限、SSRF、入力サイズと資源制限、異常な業務フローを確認する。ブラウザ側の制限だけを信じない。リッチテキスト、ファイルの圧縮・変換、URLの取得、多言語とUnicode、大量入力、利用者間のコンテンツ共有、自動化された反復要求があるなら検証を広げる。ヘルプ、クライアント側の即時検証、入力補助は、サーバー検証と安全な処理の基準が整った後に改善する。
管理機能管理画面や運用APIがあるなら、一般利用者と分離したサーバー権限、機微な操作の再認証、役割変更・大量修正・削除の監査記録、セッションとCSRFの防御、緊急アカウントと復旧手順を確認する。隠されたURLはアクセス統制ではない。役割の委任、サポートの代行、なりすまし、大量エクスポート、一括の権限変更、承認フローがあるなら行為主体と承認・取消・監査の範囲をさらに検証する。管理側の検索・絞り込み・帳票の使いやすさは、アクセス統制と監査可能性が検証された後に改善する。
バックグラウンドジョブジョブがデータの変更・削除、決済、権限付与、メッセージ送信、外部同期を行うなら、重複実行の防止、冪等性、再試行と待機間隔、部分失敗、同時実行、失敗ジョブの隔離と再処理、実行権限と結果の追跡を確認する。実行時間帯、遅延実行、順序の入れ替わり、過去データの補填、大量再処理、外部のクォータ、ワーカー再起動後の復旧があるなら該当の筋書きを加える。ジョブ状況の画面と運用の自動化は、失敗の検知と安全な再処理経路が確保された後に改善する。
ログ・監視認証失敗、権限拒否、管理操作、決済と返金、データ削除、重要なジョブの結果は追跡できること。要求とジョブをつなぐ識別子、必要な通知、ログの保護が要り、パスワード・トークン・機微な個人情報は記録しない。保存期間、異常検知、担当者の呼び出し、組織別の監査、外部サービスの状態との相関、大規模ログの費用をさらに設計する。より豊かなダッシュボードや分析指標は、最小の検知・監査・通知が動いた後に改善する。
ロールバック・復旧破壊的なデータ変更、互換性のないDBマイグレーション、重要な設定・資格情報の変更があるなら、以前の成果物と設定の復元、バックアップからの復旧、データ整合性の確認、前進復旧、外部効果の補償手順を実際に確認する。バックアップがあるという事実だけでは足りない。フィーチャーフラグ、カナリア、部分ロールバック、ジョブの再生、外部事業者の障害時の機能縮退、復旧中の利用者への連絡が必要なら範囲を広げる。検証済みの手動復旧手順の自動化や復旧時間の短縮は、現在の経路が実際に動き被害を抑えられるなら後続改善として残せる。
リスク領域 × 検証の深さ — 十二領域を三段階に分ける

マトリクスを実際の検証範囲へ移す順序

第一に、機能ではなく行為と資産を書きます。会員機能、決済機能のように画面名だけを書かず、行為者・読むデータ・変える状態・外部効果・失敗時の影響へ分解します。こう書いて初めて、認証・権限・データ・金銭・外部API・バックグラウンドジョブが一つの機能の中でどうつながるかが見えます。

第二に、当てはまらない領域はN/Aと明記します。すべてのアプリに十二領域が同じようにあるわけではありません。ログインもデータ保存もない静的な紹介ページなら、認証・権限・決済はN/Aです。ただし問い合わせフォームがあるなら、利用者入力・外部メールAPI・機密情報・悪用防止は依然として当てはまります。逆にベータと名づけても、実在のアカウントや個人情報、決済があるなら該当領域をN/Aにはできません。

第三に、各領域で最も深い適用条件に従います。平均点を計算しません。決済が安全でも管理者権限が崩れていれば、そのリスクは相殺されません。一般利用者のプロフィール修正は単純なデータ変更に見えます。しかし要求の利用者IDを変えて他人のプロフィールまで修正できるなら、権限とデータの隔離をともに深く検証しなければなりません。

第四に、正常・悪用・失敗・復旧の証跡をそれぞれ作ります。正常な入力と正常な権限で意図した結果が出るか、権限のない利用者と改ざんされた要求が拒否されるか、タイムアウトや重複要求、外部障害、部分失敗が安全に処理されるか、問題が起きた後に検知して再処理または復旧できるかです。自動スキャナーは広い範囲の候補問題を見つけるのに有用ですが、注文所有者の検証や二重返金、組織間のデータ隔離、ジョブの部分失敗のような業務上の意味を単独では証明できません。ASVSは検証すべき要求を定める基準として、Web Security Testing Guideは実際の攻撃・悪用の筋書きを設計する基準として使うのが適切です。[7][8]

機能
行為者
読むデータ
変える状態
外部効果
失敗時の影響
注文決済ログイン利用者商品・注文・決済の状態注文状態・有料権限決済承認・Webhook二重課金、権限の未付与、他人の注文への到達
管理者による返金管理者顧客・注文・決済の情報返金・注文の状態決済代行への返金要求無権限の返金、二重返金、内部状態の不一致
予約通知ジョブバックグラウンドワーカー予約・連絡先送信状態メッセージ送信重複送信、欠落、個人情報のログ露出
行為と資産に分解した機能 — 画面名ではなくこの単位で書く
サービスの仕組み

リリース判断につながる検証 — 主要フローを検証し、実行結果と残る条件をリリース判断の根拠につなげます。

検証できないなら機能の影響から減らす

小規模なチームは、すべての機能を最初から最も深く検証することが難しいものです。このとき安全な方法は、高リスクの機能をそのまま公開したままテストを減らすことではなく、その機能が生む影響を実際に制限することです。

実際の決済の代わりにサンドボックスや手動の入金確認だけを使います。データ変更の機能を読み取り専用にし、実在の個人情報の代わりに仮のデータで運用します。公開登録の代わりにサーバーで強制される招待名簿を使い、外部送信と削除の作業に管理者の手動承認を置きます。大量処理と自動再試行を止め、危険な管理機能は最初の版から外します。

この制限は画面の文言ではなく、サーバーと運用設定で強制されなければなりません。まだベータだから利用者が気をつけてほしいという案内は、アクセス統制やデータ保護の代わりにはなりません。

範囲決定でよく起きる誤り

第一は、画面の数をテスト範囲に使うことです。画面が一つでも、その画面が管理者権限でデータを消したり決済を実行したりするなら深い検証が要ります。逆に情報を読むだけの複数画面は範囲が狭くなります。

第二は、ログインを確認して権限まで確認したと考えることです。ログインは利用者が誰かを確認する過程です。その利用者が特定の注文やファイル、組織、管理機能を使えるかは別の権限の問題であり、とくにAPIのオブジェクトIDや組織IDを変えるテストが抜けやすいところです。

第三は、外部APIが成功する場合だけを確認することです。外部APIの本当のリスクは、遅い応答、重複したコールバック、曖昧な成功状態、一部の作業だけが終わった場合に現れます。決済や送信、データ同期のように外部効果のある連携は、失敗後の内部状態まで確認する必要があります。

第四は、AIに自分のコードを再検討させた結果を最終の証跡に使うことです。AIの説明と検討は候補を広げるのに使えます。しかし同じコードと同じ前提に依る自己検討は、権限の迂回、実際の本番設定、外部APIの重複処理、復旧可能性を独立に証明できません。

検証範囲は技術の出所ではなく失敗の結果から始まる

AIで作られたアプリだからといって、すべての機能を最高水準で検証する必要はありません。逆に、速く作ったからといって認証・権限・データ・決済・外部連携・復旧を短い点検表で終わらせてもいけません。

アプリが境界を越えるほど検証は深くなります。他の利用者や組織の境界を越えるか、重要なデータを読み、変え、消すか、金銭や戻しにくい外部効果を生むか、機密情報や管理者権限を扱うか、失敗を見つけて元の状態へ戻せるかです。

この問いに答えれば検証範囲が定まります。そこで確保した証跡をもとに実際のリリース可否を判断するのは、リリース判定が担う次の段階です。