AIで作ったシステムを誰がレビューする？中小企業の第三者チェック項目

AIにコードを書かせ、外部ベンダーに仕上げてもらった。画面は動き、デモも通った。しかし社内には、要件が足りているか、誰の権限で何ができるか、止まったらどこへ連絡してどう戻すかを判断できる人がいない。この状態で必要なのは、もう一度作り直すことではなく、確認する人と確認範囲を分けることです。

作った本人は、決めた仕様と実装のつながりを最もよく知っています。一方で、決める前の思い込みまで共有しているため、「通常はこの値が入る」「管理者だけが触る」「失敗したら再実行すればよい」といった前提を疑いにくい。結果として、要件の前提、権限、失敗時の戻し方が確認から抜けやすくなります。これは能力の問題ではなく、同じ人が作成と評価を兼ねると生じる視点の偏りです。

NISTのAI RMF Coreも、開発を直接担当していない内部専門家や独立評価者を定期的な評価へ関与させる考え方を示しています。第三者を入れる目的は、作った人を採点することではありません。社内の業務知識と、開発者とは異なる確認視点を組み合わせることです。

レビューは5層に分ける

「一通り触って問題なかった」では、何を確認済みとしたのか残りません。次の5層に分けると、経営者や業務責任者でも質問を作れます。

1｜目的・要件・完了条件

最初に見るのは画面ではなく、何を終わらせるシステムかです。たとえば見積作成なら、下書きの生成で完了なのか、承認・送付・保存まで含むのかを決めます。通常時だけでなく、値引き、入力不足、承認却下、二重送信などの例外も書きます。要件漏れの判定は技術だけではできません。現場担当が「この流れで仕事が完了するか」を確認します。

AI導入時に抜けやすい前提は中小企業のAI導入が失敗する3パターンと回避策でも整理しています。

2｜入力データ・個人情報・権限

どのデータを入れ、どこへ保存し、誰が閲覧・更新・削除できるかを一覧にします。顧客名、連絡先、契約情報を扱うなら、テスト環境へ本物の個人情報をそのまま入れていないかも確認します。一般社員、責任者、退職者、外部委託先の各アカウントで操作し、見えてはいけない案件やボタンが見えないことを確かめます。

AIがメール送信やデータ更新まで行う場合は、必要最小限の機能と権限に絞ります。OWASPのExcessive Agencyは、過剰な機能・権限・自律性を原因として挙げ、高影響の操作には人の承認を求めています。送信、削除、金額確定などは、AIが候補を作っても最後の実行は担当者が承認する形を検討します。

3｜AI出力の検証・サニタイズ

AIの文章が自然かだけでなく、その出力が次の処理でどう使われるかを見ます。金額や商品コードなら許容する型・桁・選択肢に合うかを検証し、HTML、メール、データベース操作などへ渡す文字列は利用先に応じて無害化します。OWASPのImproper Output Handlingは、LLM出力を下流の部品やシステムへ渡す前の検証、サニタイズ、適切な扱いが不足する危険を指摘しています。

NISTの生成AIプロファイルは、既知の正解データとの比較に加え、人による監督、自動評価、入力内容のレビューなど複数の方法で、出力の正確性・品質・信頼性を評価する考え方を示しています。請求金額や契約条件のように間違いの影響が大きい項目は、正解例との自動照合と担当者確認を重ねます。

4｜エラー・ログ・再実行・切り戻し

通信切断、AIサービスの応答なし、入力不足、連携先の拒否を意図的に起こします。そのとき利用者に何が表示され、処理がどこまで進み、誰がログを見られるかを確認します。再実行で申請や送信が二重にならないか、誤更新したデータをどの時点へ戻せるか、復旧窓口と連絡方法が決まっているかも対象です。「エラーになりました」で止まるなら、運用できる状態とはいえません。

5｜運用担当・引継ぎ・変更履歴

毎日の確認者、アカウント追加者、障害の一次窓口、外部サービス変更を追う人を役割名で決めます。担当者が休んだ場合の代理も必要です。さらに、いつ、誰が、何を、なぜ変えたかを変更履歴へ残します。AIの指示文、利用モデル、連携項目、権限を変えたら、影響するテストを再度実行します。引継ぎで残すべき情報はAIで作ったツールの引き継ぎリスクも参考になります。

社内確認と外部第三者レビューの役割分担

外部の第三者だけでは「この見積を送ってよいか」という自社の判断基準は決められません。逆に社内だけでは、ログや権限設定が確認可能な状態かを判断しにくいことがあります。主担当を分け、最終判断は共同で行います。

外部へ頼む前に、どこまでを自社で決め、何をレビューしてもらうかを明記します。支援先の見極め方はAI導入支援会社の選び方で確認できます。

レビュー前に渡すもの

資料がないまま「全部見てください」と頼むと、画面を触った感想で終わります。完成度は問いません。分からない箇所を「未決」と書いたうえで、次の6点を同じ版で渡します。

• 要件：対象業務、利用者、通常フロー、例外、完了条件
• 画面：URL、画面一覧、主要操作が分かる画像
• テストデータ：正常例、空欄、長文、重複、権限外の例
• 権限一覧：役割ごとの閲覧・登録・更新・削除・承認の可否
• エラー時手順：停止、連絡、ログ確認、再実行、切り戻しの順番
• 変更履歴：変更日、変更者、理由、影響範囲、再テスト結果

経済産業省のAI事業者ガイドライン第1.2版は、AI開発者・提供者・利用者の各主体に関する事項と、経営層によるAIガバナンスの構築・モニタリングに関する資料をまとめています。小さなシステムでも、「作る側だけの話」にせず、利用する会社の判断と運用を資料へ残すことが出発点になります。

第三者レビューで保証できないこと

第三者レビューは、品質保証の証明書でも、事故をゼロにする約束でもありません。限られた時間、渡された資料、用意したテスト条件の中で、見落としを減らす活動です。次のことまでは保証できません。

• 試していない入力や利用状況で不具合が起きないこと
• 将来のAIモデル、外部API、法令、社内業務の変更へ自動で追随すること
• すべての攻撃、内部不正、誤操作を防げること
• AIの出力が常に正確で、偏りや不適切な表現を含まないこと
• 障害から必ず目標時間内に復旧できること

レビュー報告には「問題なし」だけでなく、確認した版、テスト条件、見つかった問題、未確認項目、残るリスク、次回の再確認条件を残します。経営者は、その残ったリスクを受け入れるか、機能や権限を減らすか、公開を延期するかを判断します。

来週やること：実際の1件を正常系と失敗系で流す

来週は、テスト画面を眺めるのではなく、実際に日常で起きる申請、見積、問い合わせのいずれか1件を選びます。本物の個人情報を使わず、実データと同じ項目を持つテストデータを用意してください。

1. 完了条件を1行で書く。例として「申請が承認され、申請者へ通知され、履歴を検索できる状態」とする
2. 正常系を流す。入力、AI処理、担当者確認、承認、通知、保存まで進め、各時点の担当と記録を確認する
3. 結果を照合する。元データ、AI出力、画面表示、送信内容、保存内容が一致するかを別の人が見る
4. 失敗系を流す。必須項目を空欄にする、権限のない人で開く、連携先を一時的に使えない条件にする、同じ操作を再実行する
5. 戻せるか確かめる。二重登録や誤送信がないかを見て、停止、ログ確認、修正、再実行または切り戻しを手順書どおりに行う
6. 差分を記録する。想定と違った箇所、担当不明の箇所、直す人と期限、再テスト条件を変更履歴へ追記する

この1件で止まるなら、公開前に直せます。通った場合も「安全が証明された」とはせず、確認できた条件を残して次の例外へ進みます。

外部へ相談するときの伝え方

「AIで作ったので不安です」だけでは、確認範囲が広がります。「見積作成フローについて、権限、AI出力の検証、二重送信、切り戻し、引継ぎをレビューしてほしい。要件とテストデータは渡せる」と伝えてください。どの資料が不足し、どの順で確認するかを具体的に返せる相手なら、相談を進めやすくなります。

よくある質問