行政機関における生成AIの調達と利活用を規律するガイドラインが第2.0版へと改定され、AWSは調達チェックシートの各要件に対するサンプル回答を公開しました。行政向けにAIを提供する開発現場では、要件を満たしていることを技術的に説明できる状態を作ることが求められます。本記事では改定の要点を整理したうえで、AWS上に生成AI機能を構築する開発リーダーやエンジニアが実装の判断に使えるよう、ガードレール、ログ監査、アクセス制御を軸としたガバナンス実装の勘所と段階的な導入手順を解説します。なお要件と個別サービスの厳密な対応づけは公開資料の範囲を超えるため、ガイドラインが求める観点に対してAWSの一般的な機能でどう応えられるかという視点で読み進めてください。

ガイドライン第2.0版で広がった適用範囲とガバナンス体制

今回のガイドラインの正式名称は「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」第2.0版です。デジタル庁のニュースとAWSの記事で一致しており、公開日は2026年6月12日です。初版にあたる第1.0版は令和7年、すなわち2025年5月27日に策定されました。施行スケジュールも押さえておく必要があります。本体の施行は2026年9月1日ですが、AIガバナンスの枠組みについては2026年7月1日から先行して適用されます。開発計画を立てる際は、この二つの時期を分けて考えると設計に落とし込みやすくなります。

第1.0版からの最も大きな変化は適用範囲の拡大です。従来はテキスト中心でしたが、第2.0版では入力側にテキストと音声、出力側にテキスト、画像、音声が含まれるようになり、AIエージェントも射程に入りました。マルチモーダルなアプリを構築している開発者にとっては、対象となる機能が一気に広がったことを意味します。体制面では各府省にAI統括責任者を新設し、生成AIの利活用把握とガバナンス、リスク管理を総括する役割が置かれました。あわせてISMAPの活用、システム監査、権限管理、ログ取得に関する記載が拡充されており、技術要件としてもログと権限まわりの重要度が増しています。

AWSが公開した調達チェックシートへのサンプル回答を読み解く

AWSは、Amazon Bedrockを活用したオープンソースの生成AIアプリ実装であるGenUを利用した場合を想定し、調達チェックシートの各要件に対するサンプル回答をAppendix-3としてPDFで公開しました。この資料は立場によって使い方が変わります。政府機関の職員であれば、応札企業の提案とAWSのサンプル回答を照合し、データ保護や有害情報の制御といった重要要件の技術的な実現可能性を客観的に評価する材料として使えます。提案側のパートナー企業であれば、提案書を作成する際の技術構成や実装方法を検討する参考資料になります。

GenU自体は、チャット、RAG、文書生成、翻訳など多様なユースケースに対応し、従量課金でスモールスタートできる点が特徴です。AWSによれば最短10分でデプロイが完了するとされており、検証環境を素早く立ち上げたい場面と相性が良いといえます。ただし注意したいのは、要件のカテゴリは記事本文で列挙される一方、どのAWSサービスがどの要件に対応するかという具体的な紐付けはAppendixのPDF側にある見込みだという点です。したがって本記事でも、厳密な対応表を断定するのではなく、各観点に対して一般的な機能でこう応えられるという整理にとどめます。

ガードレールとデータ保護で要件に応える

偽誤情報の出力防止、有害情報の制御、個人情報の保護、データの所在といった観点には、Amazon Bedrock GuardrailsとBedrockのデータ保護機能を組み合わせて応えられます。GuardrailsのContent filtersは、Hate、Insults、Sexual、Violence、Misconduct、Prompt Attackの各カテゴリで入力と出力に含まれる有害なテキストや画像を検出しフィルタします。カテゴリごとに強度を設定できるため、行政サービスの性質に合わせた調整が可能です。Sensitive information filtersを使えば、社会保障番号や生年月日、住所といった個人情報をブロックまたはマスクでき、カスタムの正規表現によるパターン検出も設定できます。

Denied topicsでは望ましくないトピックを定義してブロックでき、Contextual grounding checksではRAGにおける根拠のない応答、いわゆるハルシネーションを検出してフラグを立てられます。これらはモデルの推論に組み込むだけでなく、ApplyGuardrail APIを使えばモデルを経由せず独立して適用することも可能です。データ保護の面では、Bedrockのデータは転送時も保存時も常に暗号化され、AWS KMSの顧客管理キーによる暗号化も選択できます。AWSの公式ドキュメントでは、顧客のコンテンツはベースモデルの改善に使用されず、オプトインしない限りモデルプロバイダーと共有されないと説明されています。さらにデフォルトで入出力を保存しないゼロデータ保持のモデルも用意されており、保持モードをnoneに設定した状態で保持を要するモデルを呼び出すと、そのリクエストはブロックされエラーを返します。

ログ監査とアクセス制御で説明可能性を担保する

ログの取得、監査、説明可能性、アクセス制御といった観点には、複数のサービスを役割分担させて応えます。Bedrockのmodel invocation loggingは、呼び出しのログとモデルへの入力、出力、メタデータを収集する機能です。対象となる操作はConverse、ConverseStream、InvokeModel、InvokeModelWithResponseStreamで、出力先は同一アカウントかつ同一リージョンのCloudWatch LogsとAmazon S3です。両方へ同時に出力でき、SSE-KMSによる暗号化も構成できます。この機能はデフォルトで無効なので、明示的に有効化する必要がある点を見落とさないようにしてください。呼び出したプリンシパルはidentity.arnとして自動的に記録され、100KBまでの入出力はインラインに、それを超える分はS3への参照として保存されます。

集計や調査を行う際は、S3側ではAthenaやOpenSearch、CloudWatch側ではLogs Insightsを利用できます。ここで役割の違いを明確にしておくことが重要です。CloudTrailはAPI操作の証跡を記録するもので、入出力そのものを記録するmodel invocation loggingとは目的が異なります。両者を併用することで、誰がいつ操作したかと、何が入力され何が出力されたかの両面を追跡できます。アクセス制御にはIAMを使い、最小権限の原則に基づいてBedrock、ログ基盤、KMSキーへの権限をロール単位で絞り込みます。加えてAWS Configでログの有効化状態や暗号化設定といった構成の逸脱を継続的に評価します。国民が利用するサービスでは生成AIによる出力である旨を表示し、grounding checkと監査ログを組み合わせることで説明可能性を担保できます。

段階的に導入するためのチェック手順を整える

ここまでの要素は一度に導入しようとすると負荷が高いため、段階を分けて積み上げていくことをおすすめします。効果を定量的に断定することは避け、あくまで実装を進めるための骨子として次の順序を提案します。

1. 最初に最小権限の設計を行い、IAMでBedrock、ログ基盤、KMSキーへのアクセスをロール単位で最小化します。identity.arnを手がかりに利用者を追跡できる状態を作ります。
2. 次にガードレールを適用し、Content filters、Sensitive information filters、Denied topics、grounding checksを用途別に設定します。RAGでは根拠と関連性の閾値を調整します。
3. 続いて入出力ログの取得と監査を整え、model invocation loggingを有効化したうえで、CloudTrailによるAPI操作の証跡を別途取得します。
4. そのうえで構成の継続監視を行い、AWS Configでログの有効化や暗号化、公開バケットの禁止などを評価して逸脱を検知します。
5. データ保護の層では、KMSの顧客管理キーによる暗号化と保持モードの制御、利用リージョンの選択によるデータレジデンシー制御を組み合わせます。
6. コンプライアンスの証跡としては、AWS Artifactから第三者監査レポートを取得し、ISMAP関連の裏付けを提示できるように準備します。
7. 最後にインシデント対応を整備し、ログやConfigの検知を起点として、権限の剥奪やガードレールの強化、モデルの切り替えといった手順をあらかじめ用意しておきます。

これらのステップは一巡して終わりではなく、要件やリスクの変化に応じて繰り返し見直すものです。開発現場では、まず小さく有効化して監査ログとConfigの評価結果を確認しながら、少しずつ統制を厚くしていく進め方が現実的です。