AIサービスの「デモ」決めていませんか？発注前に確認すべき21項目

こんにちは、ゼノクリース合同会社の齋藤です。このコラム記事では、企業の AI 活用や AI の最新情報について紹介しています。
今回は、生成 AI を「発注する側」、つまり外部の事業者から AI 製品やサービスを買って導入する側の話をします。

９月 1 日、政府の生成 AI 調達の基準が変わります

デジタル庁は 2026 年 6 月 12 日、行政の進化と革新のための生成 AI の調達・利活用に係るガイドラインの 2.0 版を策定しました。政府の各府省庁が生成 AI を調達・利活用するときのルールを定めた文書で、概要資料によれば、2026 年 9 月 1 日から適用が始まります（AI ガバナンスの枠組みの対象は 7 月 1 日から先行）。

政府向けの文書ですが、民間企業にも関係します。理由は 2 つあります。

ひな形として使えるから：生成 AI を発注するとき、「何を確認し、何を要求すべきか」をゼロから書ける会社は多くありません。国が整理した項目を借りて、自社に要る・要らないを判断するほうが早く、抜けも減ります。

発注先が同じだから：官公庁に生成 AI を納めている事業者は、同じ製品を民間にも売っていることが少なくありません。デジタル庁が政府職員向けの生成 AI 利用環境「源内」で使う国産モデルとして2026 年 5 月に契約した 5 社（NTT データ、ソフトバンク、NEC、富士通、Preferred Networks）は、いずれも同じモデルを法人向けにも提供しています。2026 年 7 月時点で職員が選べる海外モデルも、Claude と Amazon Nova です。政府のチェック項目に答えられる事業者とそうでない事業者の差は、民間向けの見積書や提案にもそのまま表れます。

国が用意した、確認すべき 21 項目

ガイドラインには「調達チェックシート」という付属資料があり、発注時に事業者へ確認すべき評価観点が 21 項目並んでいます。全部を覚える必要はありません。自社の発注書に写せそうなものがどれか、探しながら眺めてみてください。

組織要件（事業者の会社としての体制）

1. AI 事業者ガイドライン共通の指針の遵守
2. AI ガバナンスの構築
3. AI 業界や最新技術等の動向の把握
4. 情報セキュリティインシデント・生成 AI システム特有のリスクケース発生時の対応
5. 関係者への生成 AI に関する教育・リテラシー向上

開発・運用工程要件（つくり方・運用のしかた）

6. データの取扱い
7. アウトプットの品質保証
8. ベンダーロックインの回避
9. 生成 AI モデルのアップデートの考慮
10. 文化的・言語的考慮
11. 環境への配慮

生成 AI システムの基本機能要件（製品そのものの性質）

12. 有害情報の出力制御
13. 偽誤情報の出力・誘導の防止
14. 公平性と包摂性
15. 目的外利用への対処
16. 個人情報、プライバシー、知的財産
17. セキュリティ確保
18. 説明可能性
19. ロバスト性
20. データ品質
21. 検証可能性

名前だけでは中身が分からないものもあります。たとえば 17 のセキュリティ確保には、細工した指示を紛れ込ませて AI を不正に動かす攻撃（プロンプトインジェクション）への対策が含まれます。気になる項目があれば、原典の別紙 3 に要求事項と対策例まで書かれているので、そこを読むのが早いです。

※ 出典：デジタル庁「調達チェックシート（生成 AI システム用）」（前掲ガイドライン 2.0 版・別紙 3、2026 年 6 月 12 日策定）。項目名は同シートの評価観点をそのまま引いています。

※ 原典では、各要求事項が「基本項目」「任意追加項目（加点項目）」などに区分されています。たとえば 10 の文化的・言語的考慮と 11 の環境への配慮は加点項目です。21 項目すべてを一律に必須と考える必要はありません。

※ 本記事は 2026 年 8 月 15 日時点の内容です。項目は今後の改定で変わる可能性があるため、最新版は原典をご確認ください。

AIサービスのデモで分かるのは「うまくいった 1 回」だけです

導入を検討すると、たいていの場合は事業者の営業担当の方がデモ（実際に動く画面を見せてもらう場）を用意してくれます。では、この 21 項目のうち、そこで何を判断できるのでしょうか。

まず、デモで手応えが取れるものがあります。日本語が自然か、業務の流れに乗るか、AI の出力だと分かる表示が画面に出るか。この辺りは 30 分の実演でも見えます。

次に、デモでは見えないけれど、資料を出してもらえば裏が取れるものがあります。1 から 5 までの組織要件は、体制図や規程、教育の実施記録で確認できます。6 のデータの取扱いや 16 の個人情報の扱いは、契約書と仕様書に落ちてくる話です。

困るのはその先です。機能として備わっていること自体は、デモでも資料でも確認できます。しかし、その機能が入力を変えても、何度繰り返しても同じように働くかどうかは、どちらからも出てきません。私が見積もりや技術選定に関わるとき、デモが終わったあとに宿題として残るのが、次の 3 つです。いずれも「製品そのものの性質」に関わる項目です。

• 18. 説明可能性（なぜその答えになったのかを示せるか）
• 19. ロバスト性（AI の出力の安定性）
• 21. 検証可能性（後から記録で確かめられるか）

共通するのは、「一度うまくいった」では答えにならないことです。30 分のデモで見た 1 回の成功が、100 回目も同じ品質で返ってくるかどうかは、原理的にその場では分かりません。

３つを「その場で聞ける質問」に翻訳する

抽象的な項目のまま投げると、事業者も抽象的にしか答えられません。私は次のように聞き方を変えています。

• 説明可能性：「なぜその出力になったのかを、どのくらいまで詳しく示せますか？」
• ロバスト性：「同じ入力を繰り返したとき、また言い回しを変えたときに、出力がどれくらいブレるかを測っていますか？」
• 検証可能性：「いつ・何を入力し・何が返ったかの記録を、後から第三者が確かめられる形（監査ログなど）で残せますか？」

説明可能性については、示すのは参照した文書名までなのか、判断の過程まで残るのか、製品によってまったく違います。ロバスト性のほうは、「測っていません」と返ってきても構いません。振れ幅の分からない道具を業務に埋め込むことになる、と分かるだけでも前進です。検証可能性は、監査や事故の原因調査の際に効いてきます。その AI サービスを採用した後に、社内でどのくらい使われているかの効果測定に使える場合もあります。

契約書に書くべきは「事故が起きたとき」の話です

3 つ目に挙げた検証可能性は、製品が記録を残せるかだけでは足りません。残っている記録を、事故のときに実際に出してもらえるか。ここから先は契約の話になります。

ガイドラインには、契約時の確認項目をまとめた「契約チェックシート」もあります。入力した内容が AI の学習に使われるかどうか、AI が作った成果物の権利が誰のものになるかなど、どれも重要ですが、実務で大事になってくるのは「インシデント（事故・トラブル）が起きたときの事業者の対応義務」だと思います。概要資料には、そこに「原因を特定するための情報やデータの提供を含む」と明記されています。

事故が起きてから「記録を出してください」と頼んでも遅いことがあります。何をどこまで出せるかは、契約と製品仕様で先に決まっているからです。契約書に一行、「原因調査に必要なログを、請求から◯営業日以内に提供する」と入れておくだけでも、事故が起きた日の動き方は変わります。

もう一点、各府省庁向けの利用ルールのひな形には、不特定多数に提供されていて、利用規約に同意するだけで使い始められるタイプ（約款型）のクラウドサービスでは、原則として要機密情報（漏えいすると支障が出る情報）を扱えないという記述があります。「どんな形で提供されるサービスか」は使い勝手の話ではなく「どこまでの情報を入れてよいか」を決める条件でもあります。

まとめ

私も開発をお手伝いしてるので手前味噌ですが、こうした発注側の問いに、製品としてどう答える形があるかの一例が、GMOプライム・ストラテジーの GMO AI RAG です。社内の文書を AI に参照させて回答させる仕組み（RAG）の法人向けサービスで、部門やチームごとに参照範囲とアクセス権を分ける「情報コレクション」を持ち、用途に応じて複数の AI モデル（社外のクラウド型・社内で動かすローカル型）を選べること、自社の設備内で完結させるオンプレミス運用にも対応することが説明されています。以前の回で取り上げたベンダーロックインと透明性の観点からも、選択肢を残せる構成です。

GMOプライム・ストラテジーでは、こうした企業の AI 基盤づくりから運用までを支援するサービスを提供しています。ぜひご活用いただき、AI 活用のきっかけにしてみてください！

• GMO AI RAG（AI モデルの選択、オンプレミス稼働、「情報コレクション」による権限管理）
• 法人向け RAG「GMO AI RAG」提供開始（既存ストレージとの連携などを含む主な特長）