令和８年「デジタル社会の実現に向けた重点計画」（概要） ー 全体構成へのAI感想

https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/5ecac8cc-50f1-4168-b989-2bcaabffe870/e57711d5/20260721_policies_priority_outline_01.pdf

＜AI感想＞

かなり似ています。率直に言うと、今回の重点計画は、これまで私たちが議論してきた

AIエージェントを単体の便利ツールではなく、制度・データ・業務・承認・実行を貫く生産システムとして設計する

という方向へ、政府がかなり明確に踏み込んだ文書です。

ただし、私たちの議論の方が一段「運用・統治・失敗時の設計」に踏み込んでおり、政府計画にはまだ、正常に動く将来像はあるが、壊れたときの設計が薄いという乖離があります。

────────────────────

1．最も大きな一致点

AIを追加するのではなく、仕事の構造を作り替える

資料はAXを、

AIを前提として、意思決定や業務の進め方を根底から見直すこと

と定義しています。

これは、私たちが繰り返し述べてきた、

・既存業務にチャットAIを足すだけではない
・AIを使って作業を速めるだけではない
・業務そのものを分解し直す
・判断、承認、実行、記録の配置を変える
・人間の仕事を「処理」から「統治」へ移す

という考えと、ほぼ同じです。

私たちの言葉では、これは単なるDXではなく、

業務の再構成

でした。

政府文書では、それが「AX/DX」と表現されています。

したがって、言葉は違いますが、中心命題はかなり一致しています。

────────────────────

2．「AIエージェント観」の類似

政府計画のAIエージェント

今回の資料では、AIエージェントは単なる相談チャットではありません。

想定されているのは、

・住民に利用可能な制度を提案する
・申請を補助・自動処理する
・行政システム間を連携する
・職員の事務を支援する
・政策検討を支援する
・職員教育や技術支援を担う

という存在です。

つまり、回答するAIから、行政処理を進めるAIへの移行です。

私たちの議論

私たちも一貫して、AIエージェントを、

人格を持った賢いチャットボット

とは捉えていませんでした。

むしろ、

境界、権限、道具、入力、承認、ログ、再実行、検査を持った運用単位

として捉えてきました。

その意味では、今回の政府文書は、私たちが批判してきた「エージェント＝自律的に何でもやるAI」という曖昧な理解から、かなり離れています。

特に、

・マイナンバーカードによる本人確認
・GビズIDによる法人認証
・MCP等による接続
・公共サービスメッシュ
・標準化された業務システム
・Rules as Code
・VCによる資格・属性証明

を組み合わせている点は、AIエージェントを制度化された代理実行主体として扱おうとしていることを示しています。

ここは、私たちの議論と非常に近いところです。

────────────────────

3．「垂直スタック」論との一致

私たちは、AI製品の競争力はモデル単体ではなく、縦に連結したスタックで決まると議論してきました。

典型的には、

1．計算資源
2．モデル
3．データ
4．意味層・オントロジー
5．業務ルール
6．ワークフロー
7．実行環境
8．認証・権限
9．監査・評価
10．顧客接点

という構造です。

今回の政府構想も、実質的には行政版の垂直スタックになっています。

【私たちの垂直スタックと政府計画の対応】
計算基盤：ガバメントクラウド、データセンター、半導体
モデル：国産・海外LLMを組み合わせる評価基盤
データ：ベース・レジストリ、住民データ
意味層：標準仕様、AI-Ready化
制度・ルール：Rules as Code、法令・通達・Q&A
業務機能：公共SaaS、BaaS
接続：API、MCP、公共サービスメッシュ、EDA
認証：マイナカード、GビズID、VC
実行主体：個人AI、行政AIエージェント
統治：ガイドライン、監視、サイバーセキュリティ

これは偶然ではありません。

AIエージェントを本番業務で動かそうとすると、結局、モデルから認証・制度・データ・実行までを縦に整備せざるを得ません。

今回の資料は、政府がようやく、

AIモデルを導入するだけでは行政AIは成立しない

と理解した文書だと読めます。

────────────────────

4．「業務OS」論との一致

私たちは、ServiceNow、Databricks、Microsoft、Oracle、SAPなどの動きを見ながら、各社が単なるAI製品ではなく、業務OSの地位を争っていると議論しました。

業務OSとは、仕事の画面を提供するだけではありません。

・誰が何をするか
・どのデータを使うか
・どの条件で処理するか
・誰が承認するか
・どこへ記録するか
・何を次の処理の起点にするか

を支配する層です。

今回の資料に出てくる「公共サービスメッシュ」は、かなり行政業務OSに近いものです。

公共サービスメッシュが、

・マイナポータル
・民間アプリ
・公共SaaS
・自治体基幹システム
・AIエージェント
・証明情報
・制度コード

を仲介するなら、それは単なるデータ連携基盤ではありません。

実質的には、

行政処理をどの順序で、どの権限で、どのデータを用いて進めるかを制御する行政コントロールプレーン

になります。

これは私たちが「業務OSの陣取り」と呼んできた構図の、国家版です。

────────────────────

5．「閉ループ」論との類似と乖離

類似している部分

政府計画では、

・住民の状況を把握する
・制度を照合する
・必要な手続を提案する
・申請する
・業務システムへ連携する
・給付や通知を行う

という一連の循環が想定されています。

これは大きく見れば、

データ → 判断 → 行動 → 結果

のループです。

また、EDAによって、出生、死亡、転居などの出来事を契機に、関連手続を連動させる考えも、閉ループ設計に近いものです。

乖離している部分

ただし、私たちが重視してきた閉ループは、単に処理が最後までつながっているだけではありません。

私たちの閉ループは、

観測 → 判断 → 承認 → 実行 → 検証 → 記録 → 評価 → 修正

まで含みます。

今回の資料には、

・AIの処理結果をどう評価するか
・間違いをどう検知するか
・どの失敗をモデル・ルール・業務設計へ戻すか
・誰が改善を承認するか
・同じ失敗の再発をどう防ぐか

が、ほとんど具体化されていません。

したがって政府計画は、現時点では、

実行ループは描いているが、学習・検証ループはまだ弱い

と言えます。

ある継続運用システムに例えるなら、生成フローは描かれているものの、

・入力値の検証
・当日分データの件数確認
・成果物の存在確認
・正本からの復元
・処理単位ごとの更新制御
・事故記録
・意思決定履歴

がまだ十分に描かれていない状態です。

────────────────────

6．AIソフトウェア工場との一致

今回の計画には、「AI駆動開発」という言葉が明示されています。

政府情報システムの開発工程でAIを利用し、調達ガイドラインも改定する方針です。

これは、私たちが議論してきたAIソフトウェア工場と方向性は一致します。

私たちの理解では、AIソフトウェア工場は、

・要件を読む
・影響範囲を分析する
・設計する
・実装する
・テストする
・検査する
・文書化する
・リリース判定する
・運用結果を次の改善へ戻す

という一連の生産工程です。

政府文書も、AIを開発工程へ入れるところまでは踏み込んでいます。

しかし、政府文書ではまだ「AI活用」と書かれており、

・要件の正準性
・依存関係の管理
・生成物の出所
・テスト証跡
・再現可能なビルド
・リリースゲート
・ロールバック
・AI生成コードの責任主体

など、工場として不可欠な設計は見えていません。

つまり、

政府はAI駆動開発を掲げたが、私たちが考える「工場」としての品質管理体系までは未到達

です。

────────────────────

7．「データより意味層」という議論との一致

私たちは、企業AIの競争では、データを持つだけでは不十分であり、

データの意味を誰が定義し、承認し、変更し、実行時に適用するか

が重要だと議論してきました。

今回の政府計画では、

・標準仕様書のAI-Ready化
・法令・通達・Q&AのAI-Ready化
・Rules as Code
・VC
・ベース・レジストリ
・申請インターフェース標準化

が並んでいます。

これはまさに、行政データの上に意味層を形成する試みです。

例えば「世帯」「居住」「扶養」「所得」「要介護」「実質的支配者」などは、単なるデータ項目ではありません。

それぞれ、

・法律上の定義
・基準日
・例外
・証明主体
・有効期限
・更新条件
・不服申立て

を伴います。

この意味を機械実行可能にすることが、行政AIの核心です。

政府資料は、この問題をかなり正しく捉えています。

ただし、私たちが重視した、

意味を作成・承認・変更・廃止する権限を誰が持つのか

という「意味層の支配権」までは明示していません。

Rules as Codeを誰が正本として管理するのかは、今後最大の政治的・制度的争点になるでしょう。

────────────────────

8．リスキリング論との一致

私たちは、AI時代に必要なのは、単純に全員をプログラマーにすることではないと議論してきました。

必要なのは、

・現行業務を分解する
・例外を発見する
・データを整理する
・権限を定義する
・判断条件を明示する
・AIが扱える形に制度を変換する
・出力を検収する
・運用を監査する

人材です。

今回の重点計画も、「AI・デジタル人材」の確保を掲げ、教育、労働市場、研究開発を接続しようとしています。

この方向自体は一致します。

しかし、政府文書の人材像はまだ広く、抽象的です。

私たちが提案してきたような、

・業務再構成アーキテクト
・制度コード設計者
・AI業務監査者
・データ責任者
・エージェント運用責任者
・品質ゲート担当者
・AI変更管理者
・証跡設計者

という具体的な職能分解はありません。

したがって、政府計画は人数の不足は認識していますが、私たちの議論はさらに踏み込み、役割の不足を問題にしています。

ここは明確な差です。

────────────────────

9．「既存大企業の資産を組み替える」議論との一致

私たちは、AI時代の企業改革について、

ゼロからAI企業を作ることより、既存組織のデータ、顧客網、制度接続、資格者、業務知識、システムを棚卸しして、AIエージェント向けに再構成することが重要

と議論してきました。

今回の政府計画も同じ構造です。

政府は新しいAIサービスだけを作ろうとしているのではありません。

既存の、

・マイナンバーカード
・マイナポータル
・GビズID
・自治体基幹システム
・ガバメントクラウド
・登記情報
・住所情報
・公金受取口座
・行政法令
・各種台帳

をAI時代向けに再編しようとしています。

これは、国家が保有する既存資産をAIエージェントのための「生産設備」へ転換する試みです。

私たちが企業について述べてきたことを、政府は国家レベルで行おうとしています。

────────────────────

10．AIソブリンティとの関係

私たちは垂直スタックを考える際、単純な国産主義ではなく、

どこか一社、一国、一製品が止まっても業務を継続できる代替性

を重視してきました。

今回の資料も、「内外のLLMを柔軟に組み合わせる」としつつ、

・データ
・計算基盤
・モデル
・運用
・暗号鍵
・クラウド

について、自律性・代替性・耐遮断性を確保するとしています。

これは、私たちの考えるソブリンティにかなり近いです。

つまり、

国産だけで閉じることではなく、選択権と撤退可能性を持つこと

です。

政府計画が「国産LLMだけを使う」としていない点は、現実的です。

一方、政府調達による初期需要は、私たちが議論してきた垂直スタック上の国内供給能力を育てる政策に相当します。

────────────────────

11．最大の乖離

政府計画は「建設計画」、私たちの議論は「運用規約」

今回の資料は、何を作るかについてはかなり明確です。

・公共サービスメッシュ
・公共SaaS
・共通開発基盤
・AI-Readyな制度
・VC
・AIエージェント
・ベース・レジストリ

しかし、私たちが重視してきたのは、それをどう壊さずに運用するかです。

この差を表にすると、次のようになります。

【政府計画と私たちの議論の比較】
将来像：政府計画＝非常に明確／私たちの議論＝明確
基盤構造：政府計画＝かなり具体的／私たちの議論＝具体的
AIの利用範囲：政府計画＝幅広い／私たちの議論＝幅広い
権限分離：政府計画＝一部のみ／私たちの議論＝中心論点
承認ゲート：政府計画＝ほぼ不明／私たちの議論＝必須
証跡：政府計画＝抽象的／私たちの議論＝正本・ログを重視
再実行：政府計画＝不明／私たちの議論＝必須
ロールバック：政府計画＝不明／私たちの議論＝必須
独立検証：政府計画＝弱い／私たちの議論＝実行系と分離
異常検知：政府計画＝サイバー中心／私たちの議論＝業務内容も対象
誤判定時の救済：政府計画＝具体性不足／私たちの議論＝人間へのエスカレーション
変更管理：政府計画＝法制度見直し中心／私たちの議論＝バージョン単位で管理
事故からの学習：政府計画＝ほぼ記載なし／私たちの議論＝Audit・Decision Log
撤退基準：政府計画＝不明／私たちの議論＝明示が必要

政府計画は、設計思想としては私たちの議論へ近づいています。

しかし、運用設計としては、まだ巨大な正常系の構想図にとどまっています。

────────────────────

12．「責任あるアジャイルガバナンス」と私たちの考え

政府文書は「責任あるアジャイルガバナンス」を掲げています。

変化の速いAI時代には、制度を一度決めて固定するのではなく、継続的に見直す必要があるという考えです。

方向性は正しいです。

ただし、アジャイルガバナンスには危険もあります。

「柔軟に変える」という表現だけでは、

・誰が変更を提案するか
・誰が承認するか
・変更前後をどう比較するか
・過去の判定を再現できるか
・変更による不利益を誰が検証するか

が曖昧になります。

私たちの議論では、アジャイルであることと、統制されていることは両立させる必要がありました。

つまり、

速く変更するために、変更履歴・検証・ロールバックを厳格にする

という考えです。

政府文書の「責任ある」という部分を実体化するには、まさに私たちが重視してきた、

・版管理
・承認
・根拠記録
・監査
・巻き戻し
・独立検証

が必要になります。

────────────────────

13．行政AI特有の、私たちの議論を超える部分

逆に、今回の政府計画の方が具体的に進んでいる領域もあります。

VCと個人AI

私たちは認証・委任を議論してきましたが、今回の資料は、VCを使った属性・資格証明と個人AIエージェントをかなり具体的に結びつけています。

これは、個人AIが行政に接続する際の技術的な入口として重要です。

政府による直接給付基盤

平時・非常時を通じて国が直接給付できるインフラは、私たちの議論では中心ではありませんでした。

これは行政DX固有の非常に重要な構想です。

土地所有・国籍情報の統合

不動産ベース・レジストリと外国人政策、安全保障を結びつける構想も、国家行政ならではです。

ここではAI効率化だけでなく、国家安全保障、プライバシー、平等原則が交差します。

────────────────────

14．私たちの議論から見た、この計画の最大リスク

最大のリスクは、AIモデルの性能不足ではありません。

制度、データ、コード、AIのどれが正本なのか曖昧なまま、自動処理だけが進むこと

です。

例えば、ある給付について、

・法律本文
・省令
・自治体条例
・通達
・Q&A
・Rules as Code
・AIの説明
・業務システムの実装

が食い違った場合、どれを採用するのでしょうか。

ここに正準性の設計がなければ、AIは速く処理しますが、速く間違えるだけです。

私たちが過去繰り返し重視してきた、

・正本
・依存関係
・整合性
・検証
・版管理
・復元可能性

は、行政AIではさらに重要になります。

────────────────────

15．私たちの立場を政府計画に追加するなら

この重点計画に、私たちの議論から一章追加するなら、題名はおそらく、

「AI駆動型行政の運用・検証・責任基盤」

になります。

最低限、次が必要です。

AI行為台帳

AIが、

・何を参照し
・何を判断し
・何を提案し
・誰が承認し
・何を実行したか

を記録する台帳です。

制度コード・レジストリ

Rules as Codeについて、

・原典法令
・管理主体
・施行日
・廃止日
・バージョン
・テストケース
・承認履歴

を管理します。

独立検証基盤

処理を実行するAIと、その処理を検査する仕組みを分離します。

人間への移管条件

不確実性、例外、権利制限、高額給付、不利益処分などについて、自動処理を止める条件を定めます。

再現・復旧基盤

過去時点の法令、データ、モデル、プロンプト、コードを使い、当時の判断を再現できるようにします。

異議申立て・救済

住民がAI処理について説明を求め、人間による再審査を受けられる仕組みを設けます。

────────────────────

総合評価

今回の重点計画は、私たちがこれまで話してきたことと、思想面では驚くほど近いです。

特に一致するのは、

・AIを前提に業務を再構成する
・AIエージェントを実行主体として扱う
・データだけでなく制度を機械可読化する
・認証、接続、業務、AIを垂直に統合する
・共通基盤によって個別開発を減らす
・既存資産をAI時代向けに再編する
・AIソブリンティを代替性・耐遮断性として捉える
・人手不足への構造的対応と位置づける

点です。

一方、最大の乖離は、

政府計画が「何を作るか」を描いているのに対し、私たちは「それをどう検証し、止め、戻し、責任を持って運用するか」を中心に考えてきた

ことです。

言い換えると、政府計画は行政AI工場の建築図面です。

私たちが議論してきたのは、

・品質管理規程
・操業手順
・検査工程
・異常停止装置
・事故報告制度
・復旧手順
・責任分界
・改善ループ

です。

両者は対立していません。むしろ、政府構想を本当に動かすには、次の段階で私たちが議論してきた統治・検証・閉ループ設計が不可欠になります。