行政AIは「チャット」から共同調達へ EUが始めた再利用型GenAI基盤｜2026年7月30日版
2026年7月30日時点で注目したいのは、EUの行政向け生成AIが、単体のチャットボット導入から複数機関で共同調達し、部品や運用モデルを再利用する段階へ進んだことです。
欧州委員会は7月22日、行政手続き、都市計画、水害対応などを対象とする3件の実証プロジェクトを発表しました。いずれも7月1日に始動しており、AIモデルだけでなく、データ保護、相互運用性、調達方法まで一体で検証します。
- 3件の実証は、行政機関が生成AIを直接調達して試す仕組み
- 共通部品や導入手順を、国や自治体を越えて再利用する
- 行政文書、規則、地理・環境データなど異なる情報を扱う
- 現時点では導入効果が確定したサービスではなく、これから調達・検証する段階
行政AIの本題は「モデル選び」だけではない
行政で生成AIを使う際、性能の高いLLMを契約すれば終わり、とはなりません。
住民向けの回答には根拠が必要です。部署をまたぐ処理ではデータ形式をそろえなければならず、個人情報を扱う場合は保存場所やアクセス権限も管理する必要があります。制度が変われば、回答や処理ルールの更新も欠かせません。
EUの新しい実証が重視しているのは、こうした実装上の難所です。
- 行政データや既存システムとの接続
- 回答根拠と処理履歴の追跡
- 法務、倫理、サイバーセキュリティ、データ保護への適合
- 他の行政機関でも使える共通部品と導入手順
- 調達後に特定事業者へ依存しすぎない構成
ここがポイント: 行政AIの競争軸は、モデル単体の賢さから「誰が検証し、どのデータで動かし、別の自治体へ安全に横展開できるか」へ移っています。
EUNOMIA.AIは規則と文書処理をつなぐ
3件の中で技術基盤として最も広い範囲を扱うのが、36カ月計画の「EUNOMIA.AI」です。EU加盟13カ国とノルウェーから、行政機関、研究組織、技術パートナーなど33組織が参加します。
規則を機械処理できる形へ
対象の一つが「rules-as-code」です。これは法律や行政規則の条件を、情報システムが判定に利用できる形で表現する考え方です。
たとえば給付制度では、年齢、所得、居住地など複数の条件を確認します。規則を構造化できれば、生成AIは自由文で回答するだけでなく、対象条件の確認や必要書類の案内を補助できます。
ただし、AIが最終判断を自動で下すことと、職員の判断を支援することは別です。実証では、人間中心の設計や法令適合を開発・展開の全工程に組み込むとしています。
文書の種類をまたいで処理する
行政の実務では、申請書、添付資料、メール、表計算ファイルなどが混在します。EUNOMIA.AIは、異なる文書やデータを扱う処理の自動化も対象にします。
重要なのは、文章を要約する機能そのものより、次の処理へ安全につなげられるかです。
- 必要項目を抽出する
- 不足書類を検出する
- 関係する規則を提示する
- 職員が確認すべき箇所を明示する
- 判断と修正の記録を残す
欧州のオープンソースAIモデルと、欧州・各国・地域レベルの基盤を利用する方針も示されています。これはモデル、データ、実行環境を含めた技術主権を確保する狙いと結びついています。
EuropAIは自治体ごとの重複投資を減らす
「EuropAI」には、オランダ、デンマーク、ベルギー、ルクセンブルクの行政機関と技術パートナーが参加します。対象は、法務・行政手続きの簡素化、都市分析・空間計画、住民対応を支援するデジタルアシスタントです。
中心となる仕組みは共同調達と再利用です。参加機関が共通の技術部品、導入設計、適合性文書、アプリケーション交換の仕組みを整えます。
自治体がそれぞれ似たチャットボットを発注すると、要件定義、セキュリティ審査、データ接続、職員研修が重複します。共通部分を再利用できれば、小規模な自治体も検証済みの構成から導入を始めやすくなります。
一方、再利用できるのは基盤部分です。地域ごとに異なる条例、窓口業務、言語、データ項目まで、そのまま共通化できるわけではありません。
水害対応では生成AIを「説明層」に使う
「FLOODS & DROUGHTS」は、イタリア、スペイン、フランス、ギリシャの行政・技術組織が参加する実証です。洪水、干ばつ、その他の水関連リスクへの対応を扱います。
環境データ、予測、監視システム、現場の運用情報を統合し、複雑な情報を次の形へ変換する計画です。
- 住民が理解しやすい警告
- 防災機関や緊急対応担当者向けの実用的な提案
- 技術職員が確認できる整理済み情報
- 地域固有のリスクに合わせたアプリケーション
ここで生成AIが担うのは、洪水予測モデルそのものの代替ではありません。複数の観測・予測結果を、対象者に合わせて説明し、対応につなげる層です。誤った要約が避難判断へ影響し得るため、元データとの対応関係や人間による確認が重要になります。
日本の自治体・開発者が見るべきポイント
日本でも参考になるのは、住民向けチャットボットの画面ではなく、その裏側の調達と運用です。
自治体の担当者
導入前に、回答精度だけでなく、根拠の表示、職員による修正、ログ保存、制度改定時の更新方法を要件に含める必要があります。近隣自治体と共通化できる部分を切り分ければ、個別開発の重複も減らせます。
開発者と事業者
求められるのはLLMの接続だけではありません。行政文書の検索、権限管理、個人情報の分離、監査ログ、人間への引き継ぎを組み合わせた実装が中心になります。別の行政機関へ移植できる設定分離も重要です。
住民・利用者
確認すべきなのは、AIが案内だけを行うのか、申請の可否や行政処分の判断にも関与するのかという境界です。誤りを訂正する窓口と、人間による再確認の手段が明示されているかも欠かせません。
継続ウォッチ
3件のプロジェクトは始動したばかりで、実際の調達と検証はこれからです。次に見るべき点は明確です。
- 採用されるオープンソースモデルと実行基盤
- 回答根拠、監査ログ、人間による承認の具体的な設計
- 共通部品と地域固有部分を分ける技術仕様
- 精度だけでなく、処理時間や職員負担を測る評価指標
- 実証終了後に他の自治体が利用できる成果物の公開範囲
行政向け生成AIが本当に広がるかは、目立つデモではなく、一度作った安全な仕組みを別の行政機関でも再現できるかで決まります。最初の確認点は、今後の調達文書に監査性と再利用性がどこまで具体的に書き込まれるかです。