行政AX基盤とは何か｜4機能で構成される実装環境の定義と設計原則

行政AX基盤とは、行政AXを支える実装環境の総称である。データ機能・AI制御機能・利用者接点機能・監査機能の4機能で構成される。ネットワークとAI制御を混同してはいけない。クラウド利用や外部委託を行っても、行政の判断責任は移らない。

行政AX基盤は、4機能で構成される実装環境であり、ネットワーク層とAI制御層を明確に区別するAlphaDrive独自の体系である。

自治体の現場では、AI導入をめぐって「LGWAN上に置けば安全」「政府認定サービスを選べば大丈夫」という議論が広がりつつある。これらの整理は入口としては正しい。しかし、それだけでは行政AXの実装環境として不十分である。本稿は、行政AX基盤の定義と設計原則を、書籍『AI収益進化論』第10章および行政AXホワイトペーパー第5章に基づいて整理する。

行政AX基盤が生まれた背景

自治体のAI導入において、二つの誤解が広がりつつある。

一つ目は「LGWAN上にAIを置けば安全である」という誤解である。LGWANは通信の分離を担う仕組みであり、AIの出力の妥当性や判断の設計を担うものではない。ネットワーク構成が正しくても、AIが誤った出力を返す可能性は残る。

二つ目は「認証取得済みのサービスを使えば安心である」という誤解である。認証は事業者側の管理体制の証明であり、行政側の判断責任を代替するものではない。

これら二つの誤解は、いずれも「ネットワーク構成」と「AI制御」を混同することから生じている。行政AX基盤は、この混同を構造的に防ぐために設計された実装環境である。

書籍『AI収益進化論』第10章では、民間企業向けにfour-layer-architecture（4層プロダクト・アーキテクチャ）が体系化された（麻生要一『AI収益進化論』第10章）。行政AX基盤は、その設計思想を行政・自治体の実装文脈に特化した形で構築したものである。自治体DXが10年近く整備してきた情報セキュリティ対策の上に、AI時代固有の設計要件を追加する形で位置付けられる。これは対立ではなく、DXが築いた土台の上にAXが積み上がる関係にある。

行政AX基盤の定義 ―― 4機能で構成される実装環境

行政AX基盤は、以下の4機能で構成される実装環境である。

1. データ機能
2. AI制御機能
3. 利用者接点機能
4. 監査機能

これら4機能は、それぞれ独立した設計対象である。LGWAN上の閉域ネットワーク環境そのものを行政AX基盤と呼ぶわけではない。ネットワーク構成は、これら4機能の一部の実装条件にすぎない。

重要な原則は、ネットワーク構成とAI制御は別のレイヤーで設計される、という点である。どのネットワーク構成を選ぶかという判断は、どの情報を扱うか・どのAI利用を認めるか・どこで人が判断するかという設計を代替しない。

4機能の詳細 ―― 何を、どう扱うか

(1) データ機能

データ機能は、行政保有情報の分類とアクセス制御を担う。情報の機密性を公開情報・準機密・機密・個人情報に分類し、情報ごとの利用範囲・保存地域・保存期間を設定する。「どの情報をAIに渡してよいか」の判断構造を、事前に設計しておく機能である。

現行の情報公開制度・個人情報保護制度との整合が前提となる。データ機能は、これらの制度を回避するためではなく、これらの制度を運用可能な形でAI利用に接続するために存在する。

(2) AI制御機能

AI制御機能は、AI利用の権限設計・出力検証・停止条件の明示を担う。誰が、どのAIに、何をさせられるかの権限設計。出力の妥当性・偏り・機密漏洩リスクの検証。何が起きたらAI利用を停止するかの条件設計。これらを事前に定義しておく。

最も重要な設計原則は、「AIが判断する領域」と「人が判断する領域」を明確に分けることである。AIが自律的に判断してよい範囲を、行政の責任で事前に確定させる。AIに任せておけば大丈夫、という設計は成立しない。

(3) 利用者接点機能

利用者接点機能は、職員・住民との対話インターフェースを担う。AIとの対話における表示・入力の設計、住民向けサービスでのAI利用の明示、利用者が判断を求められる局面の明示などを含む。

住民向けサービスでAIを利用する場合、「これはAIが作成した内容である」等の表示原則を持つ。利用者が誤解しない形で、AIの利用範囲を可視化する。

(4) 監査機能

監査機能は、ログの保存・説明可能性の担保・異議申立て経路の設計を担う。誰が、いつ、何を、どう使ったか。判断の根拠を後から追える構造。利用者・住民が疑問を持った場合の対応ルート。議会報告・監査のための構造化。

行政AXの信頼性は、AIの性能ではなく、行政目的・責任・リスク・成果を説明できることで生まれる。監査機能は、assessment-separation-from-appraisalの思想と同様に、可視化と説明可能性を担保するための設計対象である。

4機能は「順次実装する段階」ではなく、「並列に機能する構造」である。どれか一つでも欠けると、行政AX基盤は成立しない。「まずデータ機能から」という段階設計ではなく、4機能を同時並行で設計する。

ネットワークとAI制御は別問題 ―― 中核規律

本稿の中核メッセージの一つは、ネットワーク構成とAI制御が別のレイヤーで設計される、という原則である。

「LGWAN上にAIを置けば安全になる」は誤りである。LGWAN上でも、AI制御機能の設計は別途必要である。ネットワーク層は通信の分離を担い、AI制御層は出力の管理と判断の設計を担う。両者は独立した設計対象である。LGWANの中でも、AIが誤った判断を返す可能性はゼロにならない。

「βモデルなら行政AXができる」も誤りである。βモデル（自治体情報セキュリティ対策の3層分離モデルの一形態）は、ネットワーク構成の話であり、AI制御の話ではない。βモデル上でも、AI出力の検証・停止条件・判断の設計は別途必要となる。

「αモデルとβモデルを使い分ければ大丈夫」も誤りである。ネットワーク構成の選択は、AI制御の設計を代替しない。どのネットワーク構成を選んでも、4機能の設計は行政の責任で行われる。

各団体のネットワーク構成を前提に、案件ごとの「情報分類・利用目的・権限・人の判断」を組み合わせて設計する。これが行政AX基盤の運用原則である。

クラウド・委託でも行政の責任は残る

もう一つの中核メッセージは、クラウド利用や外部委託を行っても、行政の判断責任は移らない、という原則である。

認証取得や事業者説明は「入口条件」であり、「判断責任の代替」ではない。ISMS認証・政府認定サービス・SOC2レポート等は、事業者側の管理体制の証明として重要である。しかし、それらは行政が判断すべき事項を肩代わりしない。

認証取得済みのサービスを利用する場合でも、以下の項目は行政が個別に判断する。

• データの学習利用の有無・範囲
• 保存地域と再委託の可否
• モデル変更時の対応
• ログ提供の範囲
• 事故報告の枠組み
• データ返却・削除の条件
• サービス終了時の移行計画
• 契約変更・料金改定時の対応

これらは事業者が説明する事項であるが、判断は行政が持つ。「認証は入口、判断は行政」の原則を、行政AX基盤の運用全体で維持する。詳細は行政AXで扱う関連論点として位置付けられる。

行政AX出島との関係 ―― 静的な基盤、動的な出島

行政AX基盤と行政AX出島（行政AX出島）は、両輪の関係にある。

行政AX基盤は、4機能で構成される静的な実装環境である。「何を、どう安全に扱うか」の設計対象である。

行政AX出島は、基盤の上に、段階的な運用ルールを乗せた「動く仕組み」である。「どの案件を、どの限定条件で、どの期間で実証するか」の運用対象である。

基盤なしに出島は動かない。基盤があっても、出島の運用設計がなければ、実装は進まない。両者が揃うことで、行政AXの実装が現場で機能し始める。

案件選定の5つの軸 ―― 基盤の運用への接続

行政AX基盤を運用する際、「基盤を選ぶ前に、案件の統治条件を決める」順序が重要である。

案件選定の5つの軸は、目的（何のためにAIを使うか）・影響（誰にどう影響するか）・情報（どの情報を扱うか）・判断（どの局面で人が判断するか）・責任（責任を誰が持つか）である。これら5軸を明示した上で、行政AX基盤の4機能を組み合わせる。

「基盤があるから、なんでもAIで回せる」ではない。案件ごとに5軸を判定し、基盤の4機能を案件に応じて設定する。この順序を守ることで、基盤の実装が形骸化することを防げる。

民間版『4層プロダクト・アーキテクチャ』との対応

書籍『AI収益進化論』および WP-01 で体系化された民間版4層プロダクト・アーキテクチャと、行政AX基盤には対応関係がある（麻生要一『AI収益進化論』第10章）。

民間 4層プロダクト・アーキテクチャ	行政AX基盤の対応
攻めの層（顧客対応・新サービス）	行政AX出島の「速く出す層」で扱う
境界の層（認可・APIゲートウェイ）	行政AX基盤の「AI制御機能」
前線の守りの層（既存アプリ・業務システム）	自治体DXで整備した業務システム
奥の守りの層（顧客DB・決済系）	行政保有の機密情報・個人情報（データ機能の守り側）

対応する部分は、「守るべきものを別レイヤーで扱う」基本構造と「攻めの層と守りの層を分離する」設計原則である。

異なる部分は、行政特有の情報分類の厳格性（公開情報・準機密・機密・個人情報の区分が民間より多層）と、監査機能の重み（民間より議会・住民・監査への説明対象が多層）である。行政AX基盤は、民間版の設計思想を継承しつつ、行政特有の要件を織り込んだ形で構築される。

よくある質問

Q1. LGWAN上にAIを置けば、それが行政AX基盤になるのか

なりません。LGWANは通信の分離を担うネットワーク構成であり、行政AX基盤の4機能（データ・AI制御・利用者接点・監査）の一部の実装条件にすぎません。LGWAN上でも、AI出力の検証・停止条件・判断の設計・監査のための構造化は別途必要です。ネットワーク構成とAI制御は独立した設計対象であり、混同してはいけません。

Q2. 政府認定サービスやISMS認証取得済みのサービスを使えば、それで行政AX基盤と言えるのか

言えません。認証は事業者側の管理体制の証明であり、行政側の判断責任を代替するものではありません。認証取得済みのサービスを利用する場合でも、データの学習利用範囲・保存地域・再委託の可否・モデル変更時の対応・ログ提供範囲・事故報告の枠組み等は、行政が個別に判断する必要があります。「認証は入口、判断は行政」が原則です。

Q3. 中小規模の市町村でも、行政AX基盤を整備できるのか

整備できます。行政AX基盤は、大規模なシステム投資を前提とする概念ではありません。4機能の設計原則は、団体規模に関わらず適用可能です。中小規模の市町村では、公開情報型の行政AX出島（行政AX出島）から始め、実績を積みながら段階的に基盤を拡張する運用が現実的です。ネットワーク構成は各団体の既存環境を前提に設計します。

Q4. 民間版『4層プロダクト・アーキテクチャ』と行政AX基盤は何が違うのか

基本構造は共通しています。「守るべきものを別レイヤーで扱う」「攻めの層と守りの層を分離する」という設計原則は、民間版と行政版で共有されます。異なる部分は、行政特有の情報分類の厳格性（公開情報・準機密・機密・個人情報の多層構造）と、監査機能の重み（議会・住民・監査への説明対象が多層）です。行政AX基盤は、民間版の設計思想を継承しつつ、行政特有の要件を織り込んだ形で構築されます。

Q5. なぜネットワーク構成とAI制御を、これほど強く区別するのか

両者を混同すると、行政AXの実装が構造的に失敗するからです。ネットワーク構成だけを整えて「安全になった」と判断すると、AI出力の検証・判断の設計・監査の構造化が欠落したまま実装が進みます。その結果、AIが誤った判断を返しても検知できず、責任の所在が曖昧になります。ネットワークは「通信の分離」を担い、AI制御は「出力の管理と判断の設計」を担う。両者を独立した設計対象として扱うことが、行政AXの信頼性の基盤となります。

---

行政AX基盤は、4機能で構成される実装環境である。ネットワーク構成とAI制御は別のレイヤーで設計され、クラウド・委託を行っても行政の判断責任は残る。この整理を維持することが、行政AXが「AI丸投げ」ではなく「行政能力の変革」として機能する条件となる。AIが人の可能性をひらく社会に向けた、行政側の実装基盤である（麻生要一『AI収益進化論』第11章）。

関連する論点は、行政AX（行政AXの全体像）、行政AX出島（動的な運用の仕組み）、AXアーキテクト（設計を担う人材像）で扱う。民間版の設計思想は、書籍『AI収益進化論』第10章および WP-01 を参照。

発行: 株式会社アルファドライブ