『国・地方ネットワークの将来像』の施策による効果を最大化するグラビス・アーキテクツの取り組み

　COVID-19パンデミックは、行政システムが抱える構造的な課題を浮き彫りにした。象徴的な出来事としては「特別定額給付金」の支給における混乱があげられる。当時、国と地方自治体のシステムは分断されており、マイナポータル経由で取得した申請データをダウンロードしても自治体側のシステムと連携できず、結局、目視により住民基本台帳と突合し、システムに手入力していた。そのため、紙ベースの申請と同じ手間が必要になった上、手入力によるヒューマンエラーが重なり給付遅延となった。技術立国を自任してきたわが国としては、諸外国との大きな差に衝撃を受け、マスメディアは『デジタル敗戦』と揶揄した。

　この事態を重く受け止めた政府は、行政システムの抜本的な構造改革へと舵を切るべく2021年9月にデジタル庁を発足した。「誰一人取り残されない、人に優しいデジタル化」をミッションとし、「すべての行政手続きがスマートフォンで60秒以内に完了する社会（以下、『スマホで60秒』と記す）」という具体的な政策目標を打ち出した。そして、体系的な施策の遂行においてリーダーシップを発揮し、現在ではスマホで引越し手続、確定申告、パスポート申請、年金、医療費等の情報閲覧が可能となっている。また、2026年度の本格化を控えたオンライン行政サービスにより『スマホで60秒』のサービスが拡がりつつある。

　一方、オンライン行政サービスを提供する自治体側を見ると、中小自治体の多くは『デジタル敗戦』当時のIT環境（三層分離のαモデル）のままとなっている。既に総務省は、αモデルの課題を踏まえてβ、βダッシュモデルを提示しているものの、境界型セキュリティであるαモデルからゼロトラストアーキテクチャであるβ、βダッシュモデルへの移行は、多大なコストが必要なこと、ITに精通した人材が必要なこと等により実現には至っていない。

　総務省は、この状況を鑑み、クラウドサービスを限定的に活用できるαダッシュモデルを提示した。それにも関わらず、インターネット接続やID管理の移行、契約形態の違い等の不安と現行を踏襲したいという想いが強いためか、移行は限定的と伺っている。しかし、多くの自治体が利用しているマイクロソフトOffice2016/2019/2021は、2025年から2026年の秋に、Windows 10 LTSCモデルは2027年初頭にサポートが終了する。また、オンプレミス利用の最新版であるOffice及びWindowsのLTSCモデルを採用しても2029年にはサポートが終了する。代替候補となるGoogle Workspace等もクラウド利用が前提となっている。

　したがって、『国・地方ネットワークの将来像』が目標とする2030年を待っていると、システムのサポート切れ期間が発生してしまう。さらに、仮に2030年まで待ったとしても、最終的に自治体自らがクラウドのIT環境を整備することになれば、その時点から急遽移行検討を進めなければならない。また、次節で取り上げる『2040年問題』やオンライン行政サービスからの電子申請のトランザクションの増加を踏まえると、より早いタイミングでクラウドへの移行による働き方改革の第一歩を踏み出すことが重要となる。

　日本は、世界でも類を見ないスピードでの少子高齢化と人口減少が進んでいる。国立社会保障・人口問題研究所の推計によると、日本の総人口は、2008年の1億2,808万人をピークに減少の一途を辿っており、2040年には1億1,283万人にまで減少すると予測されている。さらに深刻なのは労働力の枯渇である。2025年から2045年までの20年間で、生産年齢人口（15〜64歳）は、約1,478万人という規模で減少する見込みである。この「人口減」を自治体経営の視点で見た場合、「人手不足」だけではなく「税収減」というインパクトがある。

　また、1971年から1974年頃に生まれた団塊ジュニア世代が全て65歳以上となる2039年頃を経て、2042年から2043年頃には高齢者人口がピーク（約3,950万人）に達し、医療・介護・福祉分野に係る財政支出が増加する。さらに、高度経済成長期に整備された道路、橋梁、上下水道、公立学校等の社会インフラが一斉に更新時期を迎えて財政を圧迫する。つまり「人口増と税収拡大」を前提としたこれまでの行政システムでは到底対応できない状況にある。
以上を踏まえると、限られた人的リソースで持続可能な自治体経営を行うにはITを活用した業務の高度化・効率化が必須であり、その着手が後手になるほど『2040年問題』の深刻度は増すことになる。

　グラビス・アーキテクツでは、こうした自治体が抱える課題への有効な支援施策を検討するために、政策目標『スマホで60秒』を実現するIT Enablers（IT施策）と関連施策を可視化するBDN（Benefit Dependency Network）による分析を試みた。

　BDNは、英国クランフィールド大学の研究者が考案した手法で、英国の公共政策・公共部門における政策決定に活用されている。その狙いは、IT投資やデジタル施策を展開する一方で、政策目標との関連性や貢献度が不明瞭であるというジレンマを解決することにある。まさに、今の自治体の課題を俯瞰する上で適切な手法と考えられる。またBDNは、政策目標（Strategic Objectives）から、その実現がもたらす便益（Expected Benefits）、便益に伴う業務上の変化（Business Changes）、その変化を促進する関連施策（Enabling Changes）に結びつけ、最終的にIT施策を抽出する。これは通常のプランニングの流れであるが、これを逆にIT施策から政策目標へと遡ると、何故、そのIT施策が必要かを簡潔に説明できる。

　図1に『スマホで60秒』を実現するBDNを示す。なお、有効な支援施策を検討するために、これまでの国の施策のうち「概ね完了」した施策は濃い緑、「進行中」は薄い緑、2025年度中の「着手開始」は薄いオレンジとし、各施策の進捗状況を青のボックス内に記載した。また、オンライン行政サービスのメリットを享受する住民側と、サービスを提供する自治体側の国の施策を対比するため、上半分を住民の便益、下半分を自治体の便益に係る施策を配置した。

　図中の上半分が緑色で繋がっているのは、マイナポータルのぴったりサービスによって一部のオンライン住民サービスが実現していることを示している。一方、下半分に着目すると、２つのIT Enablersが完了しているものの、上半分にあるスマホJPKIや標準準拠システムのクラウド化といった実装レベルではなく、構想・ガイドラインの提供に留まっている。そのため、自治体の便益を発現するまでの連鎖に至っていない。したがって、下半分の連鎖を緑色に変えていく施策を実装レベルで実現することが有効な支援施策と考えられる。次節では、その支援施策を紹介する。

　コストを共同で負担する仕組みとしては、既に共同調達が採用されている。総務省の共同調達のダッシュボード（総務省｜自治体DXの推進｜都道府県を中心とした自治体システムの共同調達に関するダッシュボード）によると、2025年4月30日の時点で292件の実施が確認できる。なお、共同調達では、投資効率を高めるためより多くの自治体の参加が重要となる一方、サービス仕様の合意にあたっては参加が多いほど合意が長期化するといったジレンマに陥る。施策１では、その解決にあたりクラウドの特徴を活かしたコンセプトを設定している。

①段階的な機能向上やサービスレベルの選択肢の提供
　オンプレミスでは、ハードウェア・ソフトウェアの仕様合意を以てコストが確定し、確定後は後戻りができないことから合意が長期化していた。そこで施策１では、クラウドサービスのメリットを活かし、最小限の機能でスモールスタートし、段階的に機能を向上することで合意形成のハードルを下げる。あるいは、スタート段階で複数のサービスレベルの選択肢を提示し、要件に合う選択肢に参加するという形態も想定している。

②柔軟な共同調達グループの組成
　オンプレミスでは、物理的なシステムの保守や監査のため、地理的に近い広域自治体の行政区域内である必要があった。そのため、参加自治体の数も行政区域内の自治体数が上限となっていた。これに対し施策１では、行政区域内外に関わらず他の都道府県の自治体も参加可能なコンセプトを取り入れる。

③調整事務の支援
　共同調達の合意にあたっては、参加自治体間での多くの協議事項が発生する。そこで施策１では、これらの手続きによるリードタイムを最小限にすべく予めチェックリストや代替案の準備を想定している。

　BPO（Business Process Outsourcing）は、民間企業及び一部の自治体で既に採用されているスキームである。ただし、既存のBPOは、汎用業務の代行とそれに必要なIT基盤の構築・運用が対象となっている。一方、施策１は、既存のBPOの役割に加え、以下のような業務の高度化・効率化に係るCoE機能も提供する。

　①チェンジマネジメント
　②ITロードマップの策定
　③ITガバナンスの維持・ITアセットの管理
　④内部事務システムのクラウド移行支援
　⑤市民向けサービスの構築支援

　なお、グラビス・アーキテクツは、大手コンサルティングファームやシステム・インテグレーター、ITベンダー出身のコンサルタントだけでなく、行政職出身のコンサルタントが在籍することから、これらのCoE機能の提供が可能である。また、現在、IT基盤の構築・運用にかかるリソースの拡充や、業務の高度化・効率化に資するSaaS提供に向けてビジネスパートナーと協議を進めている。

　BPOサービスパッケージを構成するコンポーネントは図2のとおりである。また、ゼロトラストアーキテクチャ（ZTA）を想定した将来の機能アーキテクチャは図3のとおりである。なお、これらを物理アーキテクチャへと具体化するために、下記の２つを重要課題として位置付けている。

①統合ID基盤
　ITサービスの全体像を意識しないまま施策毎に調達を進めた場合、住民サービスにおいてIDが乱立し、住民側でオンライン行政サービス毎のIDとパスワードを記憶するという不便さが発生する。そのため、本来の狙いである住民のWell-BeingやQoLを高めるどころか、低下を招くことになる。また、自治体側においても、複数のIDが乱立すると一人のユーザが単一のIDで識別されるZTAの基本が成立せず、将来的にβダッシュモデルへ移行し、働き方改革、業務の高度化・効率化を実現する上での足かせとなる。したがって、施策１では、統合ID基盤の物理アーキテクチャの検討を重要課題として位置づけている。
　一方、ITサービス全体のTCOを下げるためには、SaaSをカスタマイズせずに利用する必要がある。そのため、統合ID基盤の検討にあたっては、１つのIdPで全てを統一するのではなく、信頼の起点となるプライマリIdPを定めた上で、SaaSにIdPがバンドルされている場合にはプライマリIdPと連携できる柔軟な仕組みが必要となる。特に、共同調達を考慮すると単一のテナント内に複数の自治体が参加することから、自治体間の情報統制の観点からクラウド・グループウェアのコンポーネントで採用するIdPは必須となる。そのため、当該IdPとプライマリIdPとの連携は必須事項となる。

②AI基盤
　AIエージェントを構成する要素は様々な定義がある。ただし、用語は異なるものの、概ね1)LLM（Large Language Model）による推論/計画を行うレイヤー、2)ナレッジベースを提供するレイヤー、3)オーケストレーションやプランニングを行うレイヤー、そして4)アクション実行する基盤を提供するレイヤーと整理できる。また、AI基盤は、これらの全てのレイヤーにおける情報統制を図るとともに、公平性・透明性・プライバシー保護等の責任あるAIの原則を実装する機能が必要となる。したがって、AIエージェントの導入にあたっては、こうした全体像を意識しないまま施策毎に調達を進めた場合、野良AIエージェントのアクションが重篤なリスクをもたらす危険性がある。したがって、施策１ではAI基盤の具体化も重要課題として位置づけている。

　図1のBDNにおける「業務・手続きの自動化促進」に対し、施策2ではAIエージェントの導入支援を行う。具体的には、AI Readyな業務プロセスへのBPRの検討と、その結果に基づくAI基盤へのAIエージェントの実装支援を行う。なお、施策2は、個別の業務の支援だけではなく、施策１のBPOサービスパッケージのCoEの機能にも含める予定である。

　以下では、内部事務システム（バックオフィス）とオンライン行政サービス・窓口DX（フロントヤード）に係るAI Readyな業務プロセスへのBPRの考え方を紹介する。

　自治体の内部事務は、一般に財務会計、人事給与、庶務事務、文書管理、電子調達等のシステムを業務プロセスに従って職員が操作することで完結する。例えば、物品・サービスの調達にあたっては、財務会計システムで予算残額、科目、執行可能性を確認し、庶務事務システムにより品目、概算金額、理由、予算科目を申請し、その決裁後に電子調達システムにより見積取得、入札、落札業者を決定する。そして、文書管理システムで見積書・仕様書、及び契約書の作成・保存をし、契約金額の確定後、支出負担行為として財務会計システムで予算をコミットすることで完了する。

　なお、現在の内部事務システムは、個別に最適化され、オンプレミスで稼働している。最適化されているが故、毎年の制度改正による義務的改修において、軽微な変更であっても高額な改修コストが発生している。また、全システムがパッケージ化されていれば問題ないが、分離調達のケースではシステム間の連携の改修にも多大な工数が発生し、最悪の場合、職員がオフラインで連携するという手間が発生する。

　こうした課題に対してAI Readyな業務プロセスでは、個々のシステムを業務に必要なデータを保存・提供するクラウド上のMCP（Model Context Protocol）サーバ、あるいは自律的判断が必要なものはAIエージェントとして公開し、職員とのインターフェースとなるAIエージェントがこれらをオーケストレーションすることで解決を図る。なお、職員とのインターフェースとなるAIエージェントは、自然言語による問合せを咀嚼してMCPサーバやAIエージェントと対話することで、柔軟性のある分析・判断の支援が可能となる。また、自治体特有の業務ルールを正確に理解する仕組み（Markdownファイル）や職員によるチェック（Human-in-the-Loop）を要求する仕組みを提供することでサービスレベルの維持も可能となる（図4）。

　施策2では、こうしたAIエージェントの活用を前提とした内部事務システムのBPRを行う。

　従来の行政サービスは、紙の申請書に必要事項を記入して窓口に提出し、当日または後日、窓口、又は郵送で結果を受け取る流れとなる。住民にとっては、窓口への物理的な移動や待ち時間が必要となることが、サービスを受ける上での足かせとなっている。また、自治体側では、紙の申請書を目視で確認した上でシステムに手入力し、稟議を回すという作業が必要となる。

　これに対してオンライン行政サービスでは、マイナポータルやスマホJPKIのプラットフォーム事業者、サービスプロバイダー事業者が提供するスマホアプリを利用して本人確認（公的個人認証）を行い、スマホから必要なデータを入力し、それが直接、自治体のシステムと連携する流れにより完結することを目指す。また、スマホを持たない住民であっても、マイナンバーカードを窓口でスキャンすることで申請に必要な情報の殆どは書かずに済み、不足する項目のみ窓口の職員と対話で申請が完了する窓口DX・フロントヤード改革を目指している。

　なお、国が主導する全国共通の行政サービス（年金・確定申告等）に関しては概ね完成しているうえ、デジタル庁が公共SaaSとして給付支援システム等の共通機能を提供している。一方、自治体独自の施策を実施するためには、フロントヤードの開発（スマホアプリ、窓口DX SaaS等）とバックヤードとなる自治体のシステムと連携がポイントとなる。また、多様な行政サービスの利用や提供には、AIエージェントの活用が効果的であるため、その導入にあたってのBPRも必要となる。例えば、総務省の資料によると、コールセンターでFAQレベルの対応を行うAIエージェントを活用することで、問合せをした住民の自己解決を促すことで職員の負担を50%削減する効果が得られている。なお、住民サービスについては秘匿性の高い個人情報を取扱うことから、三層分離モデルを意識した上でのAIエージェントの適切な配置が必要となることから、BPRに加え高度なITと自治体のIT環境の知見が求められる。

　施策2では、こうした制約を踏まえたオンライン行政サービス・窓口DXのBPRを行う。

　本稿では、パーソナライズ化されたオンライン行政サービスの提供によって地域の魅力を高める施策の推進にあたり、サービスを提供する自治体職員がストレスのないIT環境に移行し、業務を高度化・効率化することを狙いとした２つの施策を紹介した。これらの施策は、クラウドサービスでの実装を前提としており、フィードバックによる改善を継続的に行うことを想定している。本稿に対する忌憚のないフィードバックをいただけると幸甚である。