マーコール株式会社

2026年9月7日

「この給付金は自分も対象？」「税金の控除額はいくら？」――そんな質問をアプリやAIにしたことはないでしょうか。では、そのときの答えは何を根拠にしているのでしょうか。

7月に米国でローンチされた非営利団体、Axiom Foundation（以下、Axiom）はこうした背景の中で設立されました。Axiomがローンチ時に挙げた社会課題は二つあります。一つは、同じ制度が何度も再実装され、かつ、システムに閉じられていて外部から検証しにくいこと。もう一つが、AIがground truthなしに制度質問へ回答していることです。

実装によって答えが異なることもある

制度に関する情報の出発点は、法令やガイドラインなど言葉で書かれた「原典」です。デジタルにするときも原典から「誰が対象になるのか」「いくら支給されるのか」といったルールを読み取り、条件分岐や計算式としてコードにします。

解釈が必要な表現や例外規定があると、コードにする時に何らかの判断が必要です。小さな判断でも積み重なると、同じ原典をもとにしていても、別々のシステムが違う答えを返すことがあります。これは実装ミスとは限りません。しかし、解釈の違いがどこにあるのかが個々のシステムに埋もれてしまっていては、外部から確認することが難しくなります。

この問題は以前から指摘されていました。今、世界中でAIが公的制度について答える機会が急速に増えたことで、新たなリスクが生まれています。

AIが公的制度について間違った回答をすることがある

ChatGPTやGeminiなどの生成AIは、原典や政府の情報を優先して答えるとは限りません。実際、今年公開された英国・Open Data Instituteのレポート「CitizenQuery-UK」では、税、給付、移住、雇用などの情報についてAIに質問した際、AIが「わからない」と答える代わりに誤った回答を生成しがちな点や、政府公式ではないウェブ上の情報を持ち込んだ結果、事実と異なる回答を出力することがあると報告されました。ODIは、政府情報が優先して参照されやすくするAI-readyな仕組みの必要性を指摘しています。

同様の問題を可視化するサイトもあります。米国評価サイト「PolicyBench」では、AIに税額や給付資格を質問し、その回答を米国の税・給付制度を計算するソフトウェア「PolicyEngine-US」の結果と比較しました。100世帯、給付金等18プログラム、27フロンティアモデルで検証したところ、正解率は約90％でした。この比較においては、フロンティアモデルであっても10回に1回ほど誤回答した^※ことになります。
^※Axiom Foundation調べ、7月28日時点

AIは問題を広げるが、解決にも使える

AxiomAIの進化によって、これまで人手に制約されていた法令のコード化を大規模に進められるようになった今こそ、AIが依拠できる検証可能なルールの共通基盤を作るべきだ、と提案しています。また、その共通基盤を、政策変更の影響分析やシミュレーションにも活用できる、としています。
Axiomのアプローチは、ざっくり言うと次の2点に集約されます。

1. 制度コードを大規模に整備し、LLMやAIエージェントを含むさまざまなシステムから使えるようにする
2. 制度コードを外部から確認できる形で公開し、既存の別の実装やデータとも「答え合わせ」して検証する

まず税や給付の分野で、制度コードを大規模に整備する。そのために、法令文書などの収集やパラメータの特定、構造化、コード化などにAIを積極的に使っています。また、作られたコードの検証にもAIエージェントを活用しています。

Rules as Codeの取り組み（例えばニュージーランド政府の「Better Rules」など）には、政策立案や法制化の段階から政策担当者と開発者が協働し、最初からルールをコード化する「アップストリーム型」のものがあります。Axiomは、自然言語で書かれている法令や制度に関する膨大な文書を、AIの力を借りて大規模に機械可読・実行可能なルールへ変換するという、「ダウンストリーム型」の取り組みです。

「RuleSpec」とは何なのか？

Axiomが「AI-driven pipeline」と呼ぶプロセスで、制度ルールの記述に使われるのが「RuleSpec」です。自身の定義では「canonical authoring and interchange schema for Axiom Rules Engine rules」ですが、スキーマといっても単一のファイルを指すものではありません。個々のファイルの構造や式だけでなく、ルールの種類、適用時点に応じたバージョンの選び方、丸めなど、Axiomのルールエンジンが制度ルールをどのように解釈・実行するかについて規定したものです。

そして、RuleSpecに沿って、個々の法令や制度をコードにしたものが「encoding」です。Axiom CEOのMax Ghenis氏は、RuleSpecとencodingの関係を、OpenAPIにおける「Specification（仕様）」と、それに沿って作られる個々の「Description（記述）」に近いと説明しています。

ところで、制度のデジタル実装を概念的に表すと次のようになります。

• 原典層： 法令、規則、ガイダンス、マニュアルなど
• 中間層： 制度やルールをコードにしたものなど
• アプリケーション層： 計算、給付判定、チャットボットなど
  ^※この三層構造は筆者が独自に整理したものです。

この整理でいえば、RuleSpecは「中間層にあたる部分を記述する仕様」です。制度コードのencodingも中間層です。encodingは.yamlファイルとして記述され、「Axiom Rules Engine」が実行します。

すでに、3,000超の規定をコード化したものが、テストケースも含めて、オープンライセンスで公開されています。また、これらのコードを利用したチャットボット、フォーム作成、政策が個人や世帯に与える影響を試算するマイクロシミュレーションなどのデモも多数、ウェブサイトで公開されています。

OpenFiscaとの関係

原典とアプリケーションの間に共通して使える実行可能な制度ルールを置く発想は、これが初めてではありません。税や給付制度をモデル化し、計算・シミュレーションするための「OpenFisca」や「PolicyEngine」などの先行例があります。先のMax Ghenis氏はPolicyEngineを6年前に立ち上げています。

すでに別のプラットフォームで制度が機械実行可能な形にモデル化され、さまざまなアプリケーションから再利用できるのであれば、それをすべてAxiomのencodingに置き換える必要があるわけではありません。

Axiomも、既存の制度実装をすべて独自の規格に置き換えることを目的にしているわけではないようです。というよりも、制度ルールが個々のシステムの中で重複して実装され、外から確認しにくい状況を解決するための、オープンで機械可読・実行可能な制度コードを共有できる基盤を世界各国・地域に広げようとしている、と見るのがよさそうです。

AI支援で作った制度コードをどう検証するか

AIによる支援でencodingを作るにあたり、Axiomは複数のステップを設けて検証のハーネスを強化している、と説明しています。具体的には、法令に書かれた数値とコード上の値が対応しているかなどの機械的なチェック、独立したAIエージェントによる厳格なレビューなどです。また、法令とガイダンスの関係など、どの解釈をルールに反映するか判断が必要な場合には人間の専門家によるレビューを挟むと説明しています。

もう一つ、特徴的と言えるのが、すでに存在する別の制度実装や政府のデータと可能な限り比較するというものです。
概念的には、次のような関係です。

ルールA→制度実装X→出力X
ルールA→制度実装Y→出力Y
出力X≠出力Y

まず得られるのは、最後の「出力Xと出力Yが異なる」（または一致する）という部分です。出力が異なる場合、それぞれのコードや入力の対応づけ、参照している原典などにさかのぼって、なぜ違いが生じたのかを調べます。すぐにどちらかが間違いとは判断しません。

面白いのは、この仕組みでは、「thin adapter」と呼ばれる簡易な接続層を介して、異なる実装をそれぞれ本来の環境で動かしたまま比較できる点です。これは、結果として単一のルールエンジンや特定の企業に依存する必要がないことを意味します。

この仕組みを、制度コードの世界的なテストベッドとして活用する考えはないか、Axiom側に質問したところ、自身のencodingとの比較だけでなく、別に作られた実装同士が互いをチェックできる「shared testbed」としても考えているということでした。

現在はPolicyEngine、TAXSIM、UKMOD / EUROMODなど欧米の制度を中心に比較・検証の参照先（「oracles」と呼ばれます）として使われていますが、OpenFisca系の実装は特になじみやすく、Blawxのような別の仕組みもthin adapterを介して接続できるということです。

AIとの連携の仕組み

では、encodingとAIをどう連携するのでしょうか？
Axiomの公開資料では、MCPサーバをAIエージェントとAxiom Rule APIの間に置く「thin adapter」と説明しています。AI側は search_rules や calculate_household などのツールを呼び出し、MCPサーバが内部でAxiom Rule APIに接続します。AIが制度ルールそのものを内部に持つのではなく、MCPを介してAxiom側の検索・計算機能を利用する構成です。

出典：Axiom Foundation, “Axiom MCP Server Reference”（2026年9月5日閲覧）

日本でも問われる、AIと制度ルールの分担

こうした問題と接点のある取り組みが、日本でもすでに始まっています。

例えば、デジタル庁は、2024年に「Data for AI」サブユニットを立ち上げ、行政データの機械可読性を高めてAIが利用しやすい形にすることに取り組んでいますし、「法令API」の高度化や、AIエージェントが政府のシステムにアクセスしやすい環境をつくるためのMCP対応も進めています。

さらに東京都とGovTech東京は、東北大学と連携し、行政に関する法令や専門知識等を学習した「行政特化型国産AIモデル」の構築・実証を進めています。行政は住民の権利義務に直結するため、ハルシネーションへの対策だけでなく、回答の根拠や判断過程を示し、誤りを検証・是正できる透明性も重視しています。

また、IPAの「2025年度オープンソース推進レポート : Part III ギャップへの対処」では、『行政が「完成品」ではなく「種（データモデル・ルールロジック・APIコンポーネント）」をOSSとして公開することで、民間・市民・他国が応用・拡張できるエコシステムが生まれる。』という考え方が示されています。

共通基盤になるほどガバナンスの仕組みが問われる

このように、日本では政府や自治体など公的な組織を中心に、それぞれの役割に応じた方向性が模索されています。

一方、米国では、AxiomやPolicyEngineのように、政府の権限を持たない組織が、公共インフラになり得る技術や実装を先に作り、政府を含むさまざまな主体が使える形で公開する動きが目立ちます。

これまでアプリケーションに実装されていた手続きや対話の一部を、AIエージェントが動的に担えるようになっています。今後は、知識をAIモデル自体に学習させるのか、外部データとして参照させるのか、実行可能な制度ルールとして外部に置くのか、そしてどこに人間の判断を残すのか。 こうした役割分担が、制度ルールとAIの関係を考えるうえで重要な論点になりそうです。

Axiomの取り組みはまだ始まったばかりです。公開情報によれば、10人に満たない少人数のチームでこの構想が進められているとのことです。政府外の組織が実行可能な制度ルールを公共的な基盤として提供する場合、誰がその正しさを認定し、誰が更新と維持を担い、政府がどのような距離で関与するのかという問いも残ります。

制度コードが社会の共通基盤になればなるほど、こうしたガバナンスの仕組みは重要になっていくでしょう。

参考資料

1. Axiom Foundationローンチ資料（Axiom Foundation）
2. Axiomの制度コード検証方法（Axiom Foundation）
3. RuleSpec、ルールエンジン、検証ツール、MCPサーバなどを公開するGitHub（Axiom Foundation）
4. Axiom MCP Server公式リファレンス（Axiom Foundation）
5. CitizenQuery-UK：行政情報に対するLLM回答の評価レポート（Open Data Institute）
6. 税・給付に関するLLMの回答をPolicyEngine-USと比較する評価ベンチマーク（PolicyEngine）
7. Better Rules公式サイト（ニュージーランド 企業・技術革新・雇用省）
8. OpenFisca公式サイト（OpenFisca Association）
9. PolicyEngine US公式サイト（PolicyEngine）
10. Blawx公式GitHub（Lexpedite）
11. デジタル庁Data for AIサブユニットについて（デジタル庁）
12. 行政特化型国産AIモデルの構築・実証事業（東京都デジタルサービス局）
13. 2025年度オープンソース推進レポート Part III「ギャップへの対処」（独立行政法人情報処理推進機構〈IPA〉）
14. 「法令」×「デジタル」の取組（デジタル庁）
15. 第12回デジタル社会構想会議（デジタル庁）
16. Axiom Foundationへの筆者取材（2026年8月）。RuleSpecとencodingの関係、異なる制度実装をthin adapterで接続する検証、独立して構築された実装同士を比較する「shared testbed」の構想などについて。