ガバメントクラウドで生成AIを使う3条件｜ISMAP登録・規制要件・契約関係の判断フロー【2026年5月版】

「ガバメントクラウドで生成AIを使いたい。でも、どこまでが許されて、何を満たせば本番投入できるのか、判断基準がはっきりしない」——自治体や省庁向けのシステムに関わるインフラエンジニアから、最近こうした相談が増えています。

行政分野の生成AI活用は、技術的に動くかどうかよりも先に、規制要件と契約上の縛りをクリアできるかが入口になります。ここを読み違えると、PoC（実証実験）までは進んだのに本番に渡せず、最悪の場合は契約解除という事態にまで発展しかねません。

この記事では、ガバメントクラウド上で生成AIを使う際に必ず押さえるべき3つの条件を、ISMAP（政府情報システムのためのセキュリティ評価制度）登録・規制要件・契約関係という観点から、オンプレ経験者にもわかりやすく整理します。技術検証の進め方ではなく、「使ってよいかどうかを判断するフロー」に焦点を絞って解説します。

なぜ「使えるか」より先に「使ってよいか」なのか

オンプレミス環境でアプリケーションを構築してきたエンジニアにとって、生成AIを業務に組み込む発想は自然なものです。技術的には、APIを叩けば文章要約も問い合わせ対応も実装できます。

ところが行政分野では、この「技術的に動く」と「制度的に使ってよい」のあいだに大きな隔たりがあります。民間企業のシステムなら、社内ルールと利用規約を確認すれば導入判断ができますが、ガバメントクラウドは国が整備する共通基盤であり、調達仕様書という形で要件が文書化されています。仕様書に書かれた条件を満たさないサービスは、たとえ性能が優れていても採用できません。

デジタル庁は2025年5月27日に「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（DS-920）」を公表し、行政機関が生成AIを調達・利用する際の考え方を体系化しました。さらに、ガバメントクラウド整備のための調達仕様書には、生成AI機能に関する固有の条件が項番74から79にわたって明記されています。

つまり行政分野では、設計やコスト試算に入る前に「制度の関門を通過できるか」を見極める必要があるのです。オンプレ案件で言えば、サーバーを発注する前に情報セキュリティ規程の適合性を確認するのと同じ感覚ですが、行政ではその比重がはるかに重くなります。

条件1: 生成AI機能をISMAP対象言明範囲に含める

最初の関門がISMAPです。ISMAP（Information system Security Management and Assessment Program）は、政府が求めるセキュリティ要求を満たしたクラウドサービスをあらかじめ評価・登録しておく制度で、各府省庁はこの登録リストから調達することが原則とされています。

ここで重要なのが「言明範囲（スコープ）」という考え方です。あるクラウドサービスがISMAPに登録されていても、その登録が及ぶ範囲は事業者が言明したサービス・機能に限られます。基盤となる仮想マシンやストレージがISMAP対象でも、後から追加された生成AI機能が言明範囲の外であれば、その生成AI機能は「ISMAP登録済み」とは扱われません。

デジタル庁の令和8年度募集の調達仕様書では、提案時点で生成AI機能がISMAP対象言明範囲の外にある場合、令和10年（2028年）3月末までにその機能をISMAP対象言明範囲に含めて更新する必要があるとされています。これが条件1の核心です。基盤だけでなく、使いたい生成AI機能そのものが評価対象に入っているかを確認しなければなりません。

オンプレ経験者向けに言い換えると、サーバーOSの脆弱性対応が済んでいても、後から入れたミドルウェアが監査対象外なら、そのミドルウェアは「安全性が確認されたもの」とは見なされない、という関係に近いものです。スコープの線引きを見誤ると、全体が登録済みだと思い込んで判断を誤ります。

ここで実務的に注意したいのが、生成AI機能は更新サイクルが速いという特性です。クラウド事業者は新しいモデルや機能を頻繁に追加します。ある時点でISMAP対象言明範囲に含まれていた機能が、新バージョンに切り替わった際にいったん範囲外として扱われる、といった動きも起こりえます。一度確認したから安心ではなく、利用するバージョンや機能が現在も言明範囲の内側にあるかを、定期的に確認する運用が求められます。

確認の実務では、ISMAPポータルで公開されているクラウドサービスリストと、その事業者が公表する言明範囲の情報を突き合わせます。基盤サービスと生成AI機能が別々のサービスとして登録されている場合もあるため、サービス名だけで判断せず、自分たちが使う具体的な機能名・APIまで掘り下げて確認することが大切です。

条件2: 経過期間中の利用制限と規制要件を満たす

2つ目の条件は、ISMAP対象言明範囲に含めて更新されるまでの経過期間における利用制限です。

調達仕様書では、生成AI機能がISMAP対象言明範囲に含まれて更新されるまでの間、その機能の利用には一定の制限がかかるとされています。「将来的にスコープに入れる予定だから今すぐ本番で自由に使ってよい」とはならない点に注意が必要です。経過措置の期間中は、扱えるデータの種類や用途に制約が課されると理解しておくべきです。

加えて、DS-920ガイドラインが示す生成AI固有の留意点も無視できません。生成AIは入力したデータが学習に使われる可能性、出力に誤りが含まれるハルシネーション、機微情報の漏えいリスクといった、従来のクラウドサービスにはない固有の論点を持ちます。行政データは個人情報や機密性の高い情報を多く含むため、これらのリスク評価を済ませることが規制要件として求められます。

実務上のチェックポイントを整理します。

・データの取り扱い: 入力データが事業者側のモデル学習に使われない契約になっているか
・利用範囲の制限: 経過期間中に許される用途・データ区分が明確か
・出力の検証体制: 生成結果を人がチェックする運用フローが設計されているか
・ログと監査: 誰がいつ何を入力・出力したかを追跡できるか

これらは「技術的に実装できるか」ではなく「制度的に求められているか」という観点で、本番投入の前提条件になります。

条件3: 契約関係と「契約解除」というペナルティを理解する

3つ目は契約関係です。ここが行政案件特有のシビアな部分になります。

調達仕様書では、令和10年（2028年）3月末までに生成AI機能をISMAP対象言明範囲に含めて更新できなかった場合、契約解除となると明記されています。これは単なる努力目標ではなく、期限を伴う契約上の義務です。事業者側にとっては、期限までにISMAP対応を完了させられなければ、ガバメントクラウド全体の提供契約を失うリスクを負うことを意味します。

利用する自治体・省庁側のエンジニアから見ても、この契約構造は重要です。今は使える生成AI機能が、事業者のISMAP対応が間に合わなければ将来的に使えなくなる、あるいはサービス自体が撤退する可能性をはらんでいるからです。生成AI機能を業務フローの中核に据える設計をする場合、その機能のISMAP対応ロードマップを事業者に確認しておくことが、リスク管理として欠かせません。

オンプレ環境であれば、ハードウェアの保守契約が切れてもサーバー自体は動き続けます。しかし行政クラウドでは、制度要件への不適合が契約解除に直結し、サービス提供そのものが止まりうる。この違いを理解しておかないと、移行計画の前提が崩れます。

もう一点、契約関係で見落としやすいのが、複数の事業者の機能を組み合わせて使うケースです。基盤はA社、生成AIはB社のサービスを連携させる構成では、それぞれのISMAP対象状況と契約条件を個別に確認しなければなりません。一方が条件を満たしていても、もう一方が経過措置の制限下にあれば、組み合わせ全体としては本番投入できない、という事態が生じます。連携アーキテクチャを描く前に、構成要素ごとの制度適合を洗い出しておくことが必要です。

加えて、調達は単年度で完結するものではなく、複数年にわたる運用を前提とします。契約期間中に制度側の要件が更新される可能性も視野に入れ、要件変更時の対応をどちらが負担するかを契約段階で整理しておくと、運用フェーズでの認識のずれを防げます。行政案件では「決めたときの条件」だけでなく「条件が変わったときの取り決め」まで含めて契約を読むことが、長期運用の安定につながります。

3条件を一気に判断するフロー

ここまでの3条件を、本番投入前の判断フローとして表に整理します。実際の案件では、上から順に確認していくと判断の抜け漏れを防げます。

確認ステップ	確認内容	NGなら
1. ISMAP登録	使いたい生成AI機能がISMAP登録サービスに含まれるか	基盤のみ登録なら本番不可
2. 言明範囲	その生成AI機能がISMAP対象言明範囲の内側か	範囲外なら経過措置の対象
3. 経過措置の期限	令和10年3月末までにスコープへ含める計画があるか	計画なしは将来利用不可
4. 利用制限	経過期間中の用途・データ区分の制約を満たすか	制約超過なら用途を絞る
5. 規制要件	DS-920が求めるデータ取り扱い・出力検証を満たすか	未対応なら運用設計を追加
6. 契約条件	事業者のISMAP対応ロードマップを契約上確認したか	不明なら依存設計を回避

この6ステップを通過して初めて、コスト試算や具体的な実装設計のフェーズに進めます。逆に言えば、どこか1つでもNGが残っている状態でアーキテクチャを固めると、後戻りのコストが膨らみます。判断フローを先に通すことが、結果的に手戻りを減らす近道になります。

民間クラウドとの違い：責任分界とデータの扱い

オンプレからクラウドへ移行した経験を持つエンジニアなら、責任共有モデルという考え方に馴染みがあるはずです。クラウド事業者がインフラの物理層やハイパーバイザーを守り、利用者がOSより上のレイヤーとデータを守る、という分担です。

行政クラウドで生成AIを扱う場合、この責任分界に「制度適合の確認責任」という層が加わります。民間であれば、利用者はサービスを選び、利用規約に同意すれば導入できます。しかし行政では、選んだサービスがISMAPの言明範囲に入っているか、経過措置の制限に抵触しないか、契約条件に整合しているかを、利用者側でも確認する責任が発生します。事業者任せにはできない領域です。

データの扱いも民間とは前提が異なります。民間サービスの多くは、入力データを品質改善やモデル学習に二次利用する規約を設けています。行政データは個人情報保護や情報公開の制度が背景にあり、二次利用を前提にできません。生成AIに入力する時点で、そのデータがどこに保存され、誰がアクセスでき、学習に使われないことが契約上担保されているかを確認する必要があります。

実務上は、以下の3つの問いに答えられる状態を作っておくと判断がぶれません。

・データの保存場所: 入力・出力データが国内リージョンに保持され、海外に転送されない構成か
・二次利用の有無: 入力内容が事業者のモデル改善に使われない契約になっているか
・削除と保持: データの保持期間と削除の手段が制度要件に沿っているか

これらは技術的なスペック表だけでは判断できず、契約書と仕様書を突き合わせて初めて確定します。

現場での進め方：PoCから本番への橋渡し

3条件を理解したうえで、実際の案件をどう進めるか。現場の流れに沿って整理します。

まず、検証フェーズと本番フェーズで扱うデータを明確に分けることです。技術検証の段階では、本番データや機微情報を使わず、ダミーデータや公開情報で動作を確かめます。この範囲なら経過措置の利用制限の内側で進められるケースが多く、制度判断を待たずに技術的な手応えをつかめます。

次に、本番投入を判断する前のタイミングで、先ほどの6ステップの判断フローを正式に通します。ここで事業者に対してISMAP対象言明範囲の現状と、令和10年3月末に向けたロードマップを文書で確認します。口頭の説明ではなく、契約書や提案書に落とし込まれた形で押さえることが、後のトラブル回避につながります。

最後に、生成AI機能への依存度を設計に織り込みます。契約解除やサービス撤退の可能性をゼロにはできない以上、その機能が使えなくなったときに業務が止まらない代替経路を用意しておく。たとえば、生成AIによる自動応答が止まっても人手の運用に切り替えられる設計にしておけば、制度リスクが業務リスクに直結しません。

この進め方の利点は、技術検証を止めずに制度判断を並行して進められる点にあります。制度の関門があるからといって検証を後回しにすると、技術的な実現性とコスト感の把握が遅れ、結局プロジェクト全体が停滞します。検証と判断を分けて同時に走らせるのが、行政クラウドで生成AIを扱う際の現実的な進め方です。

本記事のまとめ

ガバメントクラウドで生成AIを使う際の3条件を、改めて整理します。

第一に、使いたい生成AI機能がISMAP対象言明範囲に含まれているかを確認すること。基盤の登録と機能の登録は別物です。第二に、スコープ更新までの経過期間における利用制限と、DS-920が求める規制要件を満たすこと。第三に、令和10年3月末という期限と契約解除というペナルティを前提に、事業者のISMAP対応ロードマップを契約上で確認すること。

行政分野の生成AI活用は、技術検証よりも先にこの判断フローを通すことが本質です。性能やコストの議論はその後で構いません。むしろ、制度の関門を先に押さえておくほうが、PoCを止めずに本番へ渡せる確率が上がります。

クラウドの設計・運用については、姉妹サイトLinuxMaster.JPでもLinuxサーバー構築の基礎を解説しています。クラウドセキュリティの基礎を深めたい方はSecurityMasters.TOKYOもあわせてご覧ください。

よくある質問（FAQ）

Q1. ガバメントクラウドの基盤がISMAP登録済みなら、その上の生成AIも自動的に使えますか？

いいえ。基盤のISMAP登録と、生成AI機能のISMAP対象言明範囲は別の話です。基盤が登録されていても、生成AI機能が言明範囲の外なら、その機能は経過措置の対象として利用に制限がかかります。

Q2. 令和10年3月末という期限は、利用者側が守るべき期限ですか？

直接的にはクラウドサービス事業者がISMAP対象言明範囲を更新する期限です。ただし、間に合わなければ契約解除につながるため、利用者側もその機能を中核に据える設計をする前に、事業者の対応計画を確認しておくべきです。

Q3. PoCの段階でも、この3条件をすべて満たす必要がありますか？

PoCの目的と扱うデータによります。本番データや機微情報を扱わない技術検証であれば、経過措置の制限の範囲内で進められる場合があります。ただし本番投入を見据えるなら、早い段階で3条件の判断フローを通しておくほうが手戻りを防げます。

Q4. DS-920ガイドラインと調達仕様書は、どちらを優先して読むべきですか？

両方を押さえるのが理想ですが、入口としてはDS-920で行政の生成AI調達・利活用の全体的な考え方を理解し、そのうえで調達仕様書の具体的な条件（項番74～79）を確認する順序がわかりやすいです。

Q5. 民間クラウドで使えている生成AIサービスを、そのままガバメントクラウドに持ち込めますか？

同じサービスでも、ガバメントクラウド上で使うにはISMAPの言明範囲に含まれているかが前提になります。民間で問題なく使えていても、行政利用では制度の関門を別途通過する必要があります。

Q6. 契約解除のリスクは、利用者の運用に実際どんな影響を与えますか？

事業者のISMAP対応が間に合わず契約解除に至れば、その生成AI機能やサービスが利用できなくなります。業務フローの中核に組み込んでいた場合、代替手段への移行が必要になるため、依存度の高い設計は避けるか、移行計画を併せて準備しておくのが安全です。