AIに計算をさせてはいけない——デジタル庁が7.5万件の行政データで見せた「境界線の設計」
デジタル庁が公開した7.5万件の行政手続データを自然言語分析するMCP実装。なぜAIに直接計算させず、条件指定だけに絞るのか。地方製造業で25年生産管理をしてきた視点から、破綻しないAI活用の設計思想を紐解きます。
月曜日の朝、膨大なExcelシートの数字を前にして、ため息をついた経験のある人は少なくないはずです。
「この列の空白は、実績ゼロという意味なのか、それとも未入力なのか」 「前任者が作った計算式の分母には、どのセルが含まれているのか」
地方の工場で25年間、生産管理と工程設計をやってきた私にとって、それは日常そのものでした。データの定義が曖昧なまま走る現場は、いくら気合を入れても必ずどこかで計算ミスや出荷遅延という摩擦を起こします。
最近、社内データやオープンデータを「AIにそのまま読み込ませて分析させよう」という試みが急速に増えています。プロンプトにファイルを添付して、「この中から売上の傾向を分析して」「オンライン化率を計算して」と指示を出す。一見すると魔法のように答えが返ってきますが、よく検算してみると、AIが都合よく数値を丸めていたり、欠損値を勝手にゼロとみなしていたりする。
そんななか、2026年8月にデジタル庁が公開したオープンソースの実装（administrative-procedures-mcp）を目にしたとき、私は強い静かな手応えを覚えました。
国の26府省庁が所管する行政手続データ、約7万5,000件。この膨大なオープンデータを、AI（LLM）と自然言語で対話しながら分析できるようにする技術検証プロジェクトです。
しかし、この実装で最も注目すべきなのは、「AIがどれだけ賢く答えてくれるか」ではありません。むしろその正反対です。
「AIには、絶対に計算をさせない」
この冷徹なまでの境界線設計こそが、現場で壊れないシステムを作るための急所でした。
AIに計算を委ねた瞬間に、現場の数字は崩壊する
多くの人がやりがちなAI活用の失敗パターンは、AIを「万能の電卓」として扱ってしまうことです。
7万5,000行もある調査データのCSVをそのままAIのチャット画面に投げ込み、「府省庁ごとのオンライン率を集計して」と頼む。するとAIは、それらしい円グラフやパーセンテージを淀みなく返してくれます。
しかし、ここには致命的な罠が潜んでいます。
まず、トークン上限の問題です。7.5万件の生データは、到底一度のコンテキストウィンドウに収まりきりません。収まったとしても、LLMの本質は「次に来る確率の高い言葉を予測する言語モデル」であって、1円のズレも許されない厳密な算術演算器ではないのです。
さらに深刻なのが、「データの文脈の誤読」です。
今回デジタル庁が扱った「行政手続等の棚卸調査」を例に挙げてみましょう。調査シートの数値列には、空欄（null）のセルが多数存在します。 人間であれば、「この空欄は、実績がゼロだったのか？ それとも未調査で件数不明なのか？」と疑念を持ちます。しかし、生データを渡されたAIは、往々にして空欄を勝手に「ゼロ」と解釈し、全体の分母に組み込んで平気な顔で平均値を割り出してしまうのです。
デジタル庁の開発チームは、この構造的リスクを極めて早い段階で切り離しました。
アーキテクチャの役割分担は、極めて明快です。
- ユーザーの問いかけを受け取る: 「結婚したときに必要な手続は？」「省庁ごとのオンライン率は？」
- AI（LLM）の役割: ユーザーの質問意図を解釈し、検索条件や集計の軸（所管府省庁、手続類型など）という「パラメータ」の組み立てだけに専念する。
- MCPサーバー（プログラム）の役割: 組み立てられた条件を受け取り、サーバー側のエンジン（PolarsやDuckDB）で厳密にフィルタリングと加重平均を計算する。
- 結果の返却: 正確な計算結果、データ欠損の注意事項、充填率を添えてユーザーに提示する。
言葉の解釈という「曖昧さに強い領域」はAIに任せ、四則演算とデータ突合という「厳密さが求められる領域」は従来の決定論的プログラムにやらせる。
工場に例えるなら、熟練の職人に工程計画の段取りだけを考えさせ、ネジ締めや切削の精密加工は狂いのない専用治具とNC工作機械に任せるようなものです。この役割分担が成立して初めて、ビジネスや行政で使える「再現性のある精度」が担保されます。
7.5万件を3.2MBに収める——泥臭いデータの下ごしらえ
このプロジェクトの設計図を眺めていて、もう一つ唸らされた点があります。それは、表舞台のAI技術よりも、その手前にある「データ構造の軽量化とメタデータ定義」に対する徹底したこだわりです。
国の行政手続の悉皆調査データは、元々は約14MB（14,317KB）のExcelファイルでした。38〜39列におよぶ項目が並び、国交省、厚労省、農水省など縦割りの省庁から集められた巨大なスプレッドシートです。
デジタル庁の実装では、この元データをまず Apache Parquet（パルケ） という列指向の圧縮バイナリ形式へと変換しています。
その結果どうなったか。 データ容量はわずか 3.2MB（3,203KB）、元データの約22%（77.6%の容量削減）にまでスリム化されました。
Parquet形式の利点は、単にファイルが小さくなることだけではありません。ファイルの末尾（フッター）に、スキーマ情報や総行数などのメタデータが最初から書き込まれている点にあります。
そのため、システムを起動するたびに数万行のデータをメモリ上に展開する必要がありません。ユーザーから「国交省の手続だけ見せて」というクエリが飛んできた瞬間にだけ、必要な列・必要な行だけを遅延ロード（Lazy Load）して瞬時に集計する。
Raspberry Pi 5のような小型で安価なローカル環境であっても、わずか10秒足らずでセットアップが完了し、サクサクと動作する秘密はここにあります。
最新の巨大なクラウドインフラや法外なGPUサーバーをぶん回すのではなく、枯れたオープンフォーマットと適切なアーキテクチャで手元の端末を軽く動かす。この合理主義的な佇まいは、現場でリソースの制約と戦ってきた技術者として、深く共感する部分です。
意味の定義がなければ、AIは動けない
しかし、データを圧縮してプログラムに計算させるだけでは、まだ半分です。 「AIが不適切な絞り込み条件を作ってしまうこと」をどう防ぐかという問題が残ります。
デジタル庁の実装が提示したもう一つの重要な処方箋が、dataset.yaml による意味定義層（セマンティック・レイヤー）の導入でした。
国際的な統計データ標準であるSDMXの思想を参考に、調査データの項目一つひとつに「機械可読な役割」が割り振られています。
たとえば、手続を分類するコード。
dataset.yaml の中では、「手続類型」という項目に対して許容される値（コードリスト）が厳密に定義されています。
- 1: 申請等（申請、届出その他）
- 2-1: 申請等に基づく処分通知等
- 3: 縦覧等
- 4: 作成・保存等
こうして定義を固定しておくことで、AIが勝手に「類型A」「タイプ2」といった存在しない分類記号を捏造して集計をかけようとするミスを物理的に遮断できます。
さらに秀逸なのが、数値項目に対する解釈上の注意書き（notes）の自動注入です。
「オンライン手続件数」という項目には、あらかじめ以下のような注釈が埋め込まれています。 「null（欠損）は、件数不明を意味する」
この注釈が、AIが検索結果をユーザーに返す際のコンテキストに自動で付与されます。 「現在のオンライン利用実績は〇〇件ですが、全体の約3割の手続は件数不明として集計対象外になっています」という但し書きを、AIが嘘偽りなく添えられるようになるのです。
製造現場の帳票でも全く同じでした。 「空欄は、加工していないのか、不良品で破棄したのか、それとも数え忘れなのか」。記号の定義ルールを標準作業手順書（SOP）として明文化しておかない限り、新人オペレーターは必ず勘違いをします。
AIに対しても、全く同じ配慮が必要だったということです。 魔法の知能として接するのをやめ、「極めて有能だが、前提知識ゼロの新人作業員」として扱い、明確な作業規定（yaml）を渡してあげる。それが、システムを自律稼働させるための前提条件です。
自由は、根性ではなく「設計」で手に入れる
このデジタル庁の実装を試しながら、私は改めて確信しました。
世間では「AIエージェントが人間の仕事を丸ごと奪う」「プロンプトひとつで全てが自動化される」といった派手な言葉が飛び交っています。しかし、本当に業務を自動化し、自分の時間や選択肢を取り戻している人たちは、決してそんな夢物語に頼っていません。
彼らがやっているのは、驚くほど地道で実直な「境界線の設計」です。
- どこまでをAIの言語解釈に任せるか
- どこからを厳密な計算プログラムで防衛するか
- どんなデータ形式で手元のマシンを最軽量に保つか
- 人間のルールをどうやって機械可読なファイルに落とし込むか
この切り分けさえロジカルに設計できていれば、高額なエンタープライズツールを契約しなくても、手元のPCとオープンプロトコル（MCP）だけで、驚くほど堅牢で正確な自動化パイプラインが組み上がります。
かつて私が地方の工場で、泥臭くExcelマクロを組み、生産ラインのボトルネックを図面上で潰していた頃。 「もっと頑張って残業しろ」という精神論に抗う唯一の武器は、工程を分解してルール化する「設計の力」でした。
AI時代になっても、本質は何一つ変わっていません。
満員電車に揺られながら、終わらない日々の業務に追われているとしたら。 必要なのは、がむしゃらな努力ではなく、「どこをAIに渡し、どこを仕組みで縛るか」を冷静に見極める、たった数枚の設計図です。
自由は、根性ではなく設計で手に入れる。 そのための確かな足がかりが、今回デジタル庁が公開した小さなオープンソースのリポジトリの中に、静かに息づいています。