#誰もが死んだと信じたXMLの逆襲：最も安価なDSLとしての生存戦略 #XML #DX #税務 #三14 #1998XML拡張可能なマーク付け言語_平成IT史ざっくり解説
誰もが死んだと信じたXMLの逆襲：最も安価なDSLとしての生存戦略 #XML #DX #税務
忘れられた技術が米国政府のコアシステムを支える理由
目次（第一部・第二部）
第一部 再評価の罠と前提の崩し方
あなたは今、この文章を読みながら内心でこう呟いたはずです。「XML？ 2026年にもなって？ マジで？」と。
正解です。誰もが過去の遺物だと思っている技術を、わざわざ長編で掘り返す理由など、普通なら存在しません。ましてや、米国政府（IRS：内国歳入庁）が税務計算のコアエンジンにXMLを据え、それをオープンソースとして世に放ったなどという話は、悪い冗談にしか聞こえないでしょう。しかし、ここに技術の歴史が持つ最大の皮肉があります。第一部では、私たちが無意識に抱いている「新しい技術こそが常に正義である」という前提を、根底から覆していきます。
第1章 本書の目的と構成：なぜ今XMLを褒めるのか？――枯死した技術のゾンビ復活劇
[小見出し: Cheapであることの代償を数えよ]
[Key Question: なぜ2026年に政府が「死んだ技術」で税務を回しているのか？]
概念：技術選定における「安さ（Cheap）」の真の意味
本書の最大の目的は、Alex Petros氏が執筆したブログ記事「XML is a cheap DSL」を起点として、ソフトウェア開発における「DSL（Domain-Specific Language：ドメイン固有言語、つまり特定の業務や分野に特化して作られた独自のプログラミング言語）」の最適な表現方法について、多角的に考察することです。
ここで言う「安価（Cheap）」とは、金銭的なコストだけを指すのではありません。開発者が独自の言語をパース（解析）し、検索し、変換し、デバッグするためのツールをゼロから作る「労力的なコスト」が極めて低い、という意味です。XMLを採用すれば、これらがすべて「無料のエコシステム」として手に入るのです。
背景：忘れられた巨人の遺産
1990年代後半から2000年代にかけて、XMLはWebの世界の絶対的な王様でした。しかし、その冗長な記述や複雑な仕様（SOAPやJ2EEといった重厚長大なエンタープライズ技術）への反動から、より軽量で扱いやすいJSON（JavaScript Object Notation：軽量なデータ記述フォーマット）にその座を奪われました。
しかし、データ転送の分野でJSONが勝利を収めた一方で、「複雑な論理構造を記述する」という領域においては、JSONは実は非常に不器用です。米国IRSが開発した「Tax Withholding Estimator（TWE：源泉徴収見積りツール）」の裏側では、複雑怪奇な米国税法を計算するために、あえてXMLが選ばれました。
具体例：XMLがもたらす「タダ乗り」の威力
例えば、あなたが独自の税金計算ルールを作ったとします。そのルールの中から「残業代（overtime）」に関連する項目だけを抽出したいとき、JSONであれば専用の検索スクリプトをPythonやJavaScriptで書かなければならないかもしれません。しかしXMLであれば、コマンドライン上で <>XPath（XML文書の特定の部分を指定・抽出するための言語）を使うだけで、一瞬で抽出できます。
XMLは「タダで乗っかれる強力なツール群」が最初から揃っているという一点において、最もコストパフォーマンスの高い選択肢であるというのが、本記事の核心です。
注意点：思考の盲点と前提の問い直し
しかし、私たちはここで立ち止まって考える必要があります。「ツールが無料だから」という理由だけで、開発者に大量のタグ（<><Minuend> や <><Subtrahends> など）を手書きさせる苦痛を強いて良いのでしょうか？
「XMLのエコシステムが充実している」というのは、あくまで過去の遺産（レガシー）に依存しているだけではないでしょうか。もしXPathやXSLTをメンテナンスする人材が今後枯渇してしまったら、その「安さ」は将来への莫大な技術的負債（後でツケを払うことになる妥協の産物）に変わる危険性を孕んでいます。
💡 筆者の小話：XMLアレルギーの処方箋
私が学生時代、初めて触れたエンタープライズのシステムはXMLの山でした。設定ファイルを開くたびに「なぜ値よりタグの文字数の方が多いんだ！」と画面に向かって叫んだものです。<><configuration>の中に<><settings>があり、その中に<><property>がある...マトリョーシカも真っ青の入れ子構造です。しかし、数年後に自作のDSLを作ろうとしたとき、構文解析器（パーサー）をゼロから書く絶望を味わい、「あ、XMLおじさんたちが言っていたのはこういうことか」と膝を打ったのを覚えています。若気の至りとは恐ろしいものです。
第2章 要約：Fact Graphの幻想と現実――宣言型が本当に「安い」のか
[小見出し: Free lunchは存在しない]
[Key Question: 宣言型の監査可能性は、命令型より本当に優れているのか？それともトレードオフの隠れ蓑か？]
概念：命令型（Imperative）から宣言型（Declarative）へのパラダイムシフト
本記事の技術的な根幹は、「税金の計算は、命令型ではなく宣言型で記述されなければならない」という強い主張にあります。
初学者の皆さんのために料理のレシピで例えましょう。「命令型」とは、「1. フライパンを温める」「2. 卵を割る」「3. 焼く」というように、コンピュータに対する「手順」を一つずつ指示する書き方です（JavaScriptなどは基本的にこれです）。一方、「宣言型」とは、「目玉焼きとは、温めたフライパンの上に割られた卵が焼かれた状態のものである」と、「結果（状態）や関係性」を定義する書き方です（HTMLやSQL、そして今回のXMLが該当します）。
背景：なぜ税務に宣言型が必要なのか
JavaScriptで税金を計算するのは簡単です。<>const 最終納税額 = 総税額 - 支払済額 と書けば終わります。しかし、税法は無数の条件分岐と依存関係の塊です。
命令型言語の最大の弱点は、「計算途中のプロセス（中間状態）が上書きされ、消えてしまうこと」です。もし最終的な納税額が間違っていた場合、市民から「なぜこの金額になったのか説明しろ！」と監査（オーディット）を求められても、JavaScriptの変数の中身はすでに計算し終わって消滅しているため、証明ができません。だからこそ、すべての計算の関係性をグラフ構造（Fact Graph）として「宣言」しておく必要があるのです。これにより、「この数字は、あの数字とこの数字を足したからだ」という証明（イントロスペクション：内部状態の自己参照）が自動的に可能になります。
具体例：Fact Graphによる税の表現
記事内では、以下のようなXMLの構造が紹介されています（※タグ構造を平易に解説します）。
ある事実（Fact）を定義します。その名前は「最終納税額」です。
それは「派生（Derived）」して計算されます。
計算式は「引き算（Subtract）」です。
引かれる数（Minuend）は「総税額」に依存します。
引く数（Subtrahends）は「支払済額」に依存します。
非常に冗長ですが、これを見れば、誰がどう見ても「最終納税額＝総税額－支払済額」であることが、構造として不変に記録されていることがわかります。
注意点：本当にそれは「銀の弾丸」なのか？
ここで私の思考に挑戦してみます。宣言型が監査可能性に優れているというのは事実です。しかし、「宣言型にすれば複雑さが消える」というのは幻想です。複雑さは消えたのではなく、XMLのツリー構造の中に「移動」しただけなのです。
実際、このアプローチをとると、計算の順序をエンジン（フレームワーク側）が自動で解決しなければならず、エンジンの実装自体がブラックボックス化する危険があります。さらに、エラーが起きたとき、命令型なら「3行目で止まった」と分かりますが、宣言型のグラフでは「依存関係のどこかが矛盾している」という抽象的なエラーになりがちで、かえってデバッグが困難になるという盲点を見落としてはいけません。
🤔 筆者の小話：宣言型の罠
「宣言型は素晴らしい！」と聞いて、すべてを宣言型で書こうとした時期が私にもありました。しかし、いざ「ここでは例外的にAの条件ならBをスキップしてCを優先する」というような現実世界特有のドロドロした例外処理（税法なんてまさにこれの塊です）を宣言型で書こうとすると、途端にコードがパズルのようになってしまいます。美しい数式で世界を記述しようとする物理学者が、床に落ちたケチャップの飛び散り方を計算できずに発狂するようなものです。
第3章 登場人物紹介：英雄譚か、都合の良い物語か
[小見出し: USDS神話と個人の生存戦略]
[Key Question: 公開されたコードの裏で、誰が最も得をしているのか？]
概念：技術の背後にいる「人間」の文脈
技術は真空地帯で生まれるわけではありません。誰が、どのような背景で、どのようなモチベーションでその技術を採用したのかを知ることは、コードそのものを読む以上に多くを語ります。本記事を取り巻く主要な人物たちを紐解いていきましょう。
背景：登場人物たちの横顔（2026年時点の推定年齢と立場）
詳細な人物像を見る
- Alex Petros（アレックス・ペトロス / 筆者）：
推定30代。連邦政府職員（おそらくUSDS：米国デジタルサービスなどの技術部隊）として、IRSの源泉徴収見積りツール（TWE）の開発をリードしました。重要なのは、彼が「政府の公式見解」としてではなく「個人の立場」としてこの記事を書いている点です。これは、お役所仕事の枠を超えたハッカー気質を持つエンジニアであることを示しています。 - Chris Given（クリス・ギブン / Fact Graphの原作者）：
推定30代〜40代。元USDSメンバーであり、無料申告システム「IRS Direct File」の初期リーダーの一人です。彼がこの複雑なXMLベースの論理エンジン「Fact Graph」を設計しました。「税法をYAML（インデントで構造を表す軽量データ形式）で書こうとするな」という名言を残しています。 - Deniz Akşimşek（デニス・アクシムシェク / 友人・エンジニア）：
推定20代後半〜30代。筆者の友人で、最新のWeb技術「htmx」の共同メンテナ。記事内で、XMLを「KDL」という別のモダンな言語で書き直す遊び心を見せています。
具体例：彼らが証明したかったこと
彼らはいわゆる「シビックテック（市民のためのテクノロジー）」の文脈で活躍するトップエンジニアたちです。彼らは、何十億円もの税金を使って大手SIer（システム開発会社）にブラックボックスなシステムを発注する従来の行政のあり方に反発し、「モダンなオープンソースの手法で、税法という国の根幹を透明化できる」と証明しようとしました。
注意点：美談の裏に隠された生存バイアス
しかし、ここで批判的な視点を持ちましょう。彼らは極めて優秀な「エリート・ハッカー」です。エリートだからこそ、CUI（黒い画面のコマンドライン）上で <>cat facts.xml | xpath ... | fzf といったシェルコマンドを魔法のように組み合わせて、XMLの欠点を力技でねじ伏せることができました。
「俺たちはXMLを完璧に使いこなせた。だからXMLは素晴らしい」という彼らの主張は、一種の生存バイアス（成功した者の視点だけで物事を語ってしまうこと）です。明日、彼らが政府のプロジェクトを去り、平均的なスキルの公務員や業務委託エンジニアがこのシステムを引き継いだとき、手書きのXMLと難解なXPathの山は、保守不能な「呪われた遺産」へと変貌する危険性を孕んでいます。
👥 筆者の小話：天才の残した負債
現場あるあるですが、「天才エンジニアが3日で作った超高パフォーマンスでトリッキーなシステム」ほど、後から入った一般エンジニアを苦しめるものはありません。天才は「なんでこんな簡単なワンライナー（1行のコード）が読めないの？」と悪気なく言いますが、凡人にはそれが古代魔法の呪文に見えるのです。オープンソースの真の試練は、最初の熱狂が去った後の「退屈な保守作業」を誰が担うかにあります。
第二部 技術的深淵――見たくない真実
第一部では、XMLが採用された背景と、そこに関わる人間たちの思惑を見てきました。第二部では、より深い技術の深淵へと足を踏み入れます。なぜJSONではダメだったのか？ パフォーマンスに問題はないのか？ 読者の皆様が抱くであろう純粋な技術的疑問を、容赦なく解剖していきます。
第4章 XML vs. 競合DSL：S式、Prolog、KDLが黙っていない理由
[小見出し: 安価とは、誰にとっての安さか]
[Key Question: XMLの「無料エコシステム」はいつまで持続可能か？]
概念：抽象構文木（AST）とデータ表現の闘争
プログラムの世界には、「抽象構文木（AST：Abstract Syntax Tree）」という重要な概念があります。これは、プログラムの計算手順や論理構造を、枝分かれした「木（ツリー）」のようなデータとして表現したものです。税金の計算式（A + B - C）も、根元に「引き算」、その枝に「足し算」と「C」がぶら下がるようなツリー構造で表現されます。
DSL（ドメイン固有言語）を作るということは、このツリー構造を人間が読み書きできるテキストとしてどう表現するかという戦いになります。競合として挙げられるのが、JSON、S式（Lispという言語で使われる括弧だらけの形式）、Prolog（論理プログラミング言語）、そしてKDLなどのモダンな形式です。
背景：なぜJSONは「ロボトミー化」されていると呼ばれるのか
現在、Webの世界はJSONの独壇場です。しかし、本記事の筆者は「DSLとして使う場合、JSONはXMLより劣る」と断言します。なぜでしょうか。
JSONは基本的に「キー（名前）」と「バリュー（値）」のペアの集合です。データの「種類」をタグの名前自体で表現できるXML（例：<><Subtract>）に対し、JSONで同じことをしようとすると、わざわざ <>{"type": "Expression", "kind": "Subtract"} のように、自分が何者であるかを逐一データとして記述しなければなりません。これを何層も入れ子（ネスト）にすると、たちまち括弧とダブルクォーテーションの地獄になり、人間が読める代物ではなくなります。複雑な論理構造を記述するには、JSONはあまりにも語彙が貧弱なのです。
具体例：S式やPrologの美しさと、XMLの泥臭さ
記事内では、S式やProlog、KDLを使った表現も検討されています。正直に言って、見た目の美しさと記述量の少なさでは、これらの方がXMLよりずっと洗練されています。
S式での表現例を見る
(Fact (Path "/taxableIncome") (Derived (GreaterOf (Dollar 0) (Subtract ...))))
このように、無駄な閉じタグ（<>
しかし、筆者が最終的にXMLを支持した理由は「美しさ」ではありませんでした。XMLには、それを解析し、検索し、別の形式に変換するためのツール（パーサー、XPath、XSLT）が、世界のあらゆるプログラミング言語にすでに標準搭載されているからです。S式をパースするツールはLisp界隈にしかなく、PrologはPrologの環境が必要です。XMLは、どこにでも存在するという「普遍性」において圧倒的勝者なのです。
注意点：ツールの「老朽化」という時限爆弾
ここで再び前提を疑いましょう。確かに2026年現在、XMLのツールはあらゆる言語に存在します。しかし、それらのツールの多くは2000年代に書かれたC言語やJavaの古いライブラリに依存しています。JSONの台頭以降、XMLパーサーの脆弱性（XXE攻撃など）の修正や、モダンな言語（RustやGoなど）での新しいエコシステムの開発は停滞しがちです。
「枯れた技術だから安定している」と「見捨てられた技術だから誰も直せない」は紙一重です。エコシステムへの「フリーライド（タダ乗り）」は、バスの運転手が高齢化して誰もいなくなった瞬間に、大事故を引き起こすリスクを秘めているのです。
⚔️ 筆者の小話：宗教戦争としてのデータフォーマット
エンジニアが酒を飲むと必ず始まるのが「どのデータフォーマットが至高か」という宗教戦争です。「YAMLはインデントがずれると死ぬからクソ」「JSONはコメントが書けないからクソ」「TOMLは複雑な階層に弱いからクソ」...。結局のところ、完璧なフォーマットなど存在しません。XMLが選ばれたのは、「みんなが均等に少しずつ嫌っているから、逆に公平」という、民主主義における消去法のようなものかもしれません。
第5章 パフォーマンスの墓場：大規模税法ツリーがもたらす悪夢
[小見出し: XPath爆弾のカウントダウン]
[Key Question: ブラウザで数千ノードをXPath評価するのは、現実的な選択肢なのか？]
概念：グラフの評価コストとDOMツリーの重さ
データをXMLで記述したとしましょう。しかし、ただテキストファイルに書いただけでは税金は計算されません。プログラムがそのXMLを読み込み、メモリ上に「DOM（Document Object Model：文書オブジェクトモデル）」と呼ばれる巨大なツリー構造を展開し、ノード（葉っぱや枝）を一つずつ辿って計算（評価）していく必要があります。
背景：米国の税法という巨大な迷宮
米国税法は世界で最も複雑な法律の一つと言われています。基礎控除、配偶者控除、子供税額控除、勤労所得控除...数千に及ぶ変数が複雑に絡み合っています。Fact Graphは、これらすべてをXMLのノードとして表現します。つまり、何千もの <><Fact> がメモリ上に展開されることになります。
これをWebブラウザ（クライアント側）やサーバー上でリアルタイムに計算しようとすると、何が起きるでしょうか。XMLのパースとXPathを使ったノードの検索は、決して「軽い」処理ではありません。
具体例：依存関係の連鎖爆発
例えば、あなたが「子供が1人増えた」という情報を入力したとします。すると、<>/childTaxCredit の値が変わります。すると、それに依存している <>/totalRefundableCredits が再計算され、さらにそれに依存している <>/totalPayments、そして最終的な <>/totalOwed まで、連鎖的に再計算（グラフの再評価）が走ります。
命令型言語であれば、単に上から下へ計算し直すだけで済むミリ秒単位の処理が、XMLベースのグラフエンジンでは、ツリーの探索や依存関係の解決（トポロジカルソートなど）という重い処理を伴うのです。
注意点：スケーラビリティの限界を見落とすな
筆者は記事内でパフォーマンスの懸念について深く触れていません。これは非常に危険な盲点です。彼らが使っているTWE（見積りツール）程度の入力数であれば、現代のコンピュータの力技でねじ伏せられるかもしれません。
しかし、これを数千万人の国民がアクセスする確定申告のピーク時（例えば4月15日の直前）にサーバー側で一斉に処理した場合、XMLパーサーのメモリ消費量とCPUのオーバーヘッドは莫大なものになります。実は、過去の多くの「XMLベースの複雑なシステム」が死に至った原因は、このパースと評価のパフォーマンス劣化（レイテンシの増大）でした。「安価なDSL」は、運用時のサーバー代という「高くつく代償」を払うことになるかもしれないのです。
🐌 筆者の小話：重すぎたXMLの思い出
昔、ある医療系システムで巨大な患者データのXML（HL7規格）をブラウザのJavaScriptでパースさせようとしたことがあります。結果？ ブラウザはフリーズし、ファンの音が爆音で鳴り響き、ユーザーからは「画面が固まった」とクレームの嵐でした。テキストデータは軽いと錯覚しがちですが、それをコンピュータが理解できる「ツリー」に変換する作業は、人間が広辞苑を丸暗記するような重労働なのです。
第6章 開発者体験の死角：手書きXMLは究極の自己罰ゲーム
[小見出し: ツールが救う前に心が折れる]
[Key Question: DXを犠牲にしてまで宣言型を選ぶ正当性はどこにあるのか？]
概念：DX（Developer Experience：開発者体験）という指標
近年、ソフトウェア開発において「DX（開発者体験）」が極めて重視されています。これは、開発者がいかにストレスなく、直感的に、気持ちよくコードを書けるかという指標です。DXが悪い言語やフレームワークは、優秀なエンジニアから敬遠され、結果的にプロジェクトの寿命を縮めます。
背景：XMLの持つ根源的な「ウザさ」
XMLのDXは、控えめに言って最悪の部類に入ります。開始タグと終了タグを必ず一致させなければならず、タイポ（打ち間違い）をすれば全体がエラーになります。
記事内で筆者は、「XMLにはコメントが書ける」「空白や改行の扱いがまともだ」とJSONに対する優位性を語っています。確かにその通りです。しかし、だからといって <><Subtract> の中に <><Minuend>（引かれる数）と <><Subtrahends>（引く数）をいちいちタグで囲んで書くことが「楽しい」かと言えば、絶対にノーです。
具体例：手書きを強いられる現場
IDE（統合開発環境）の補完機能があったとしても、税法のルールが一つ変わるたびに、この長ったらしいXMLファイルを開き、タグの階層を壊さないように慎重にコピペを繰り返す作業を想像してください。
本来であれば、こうしたXMLは「人間が直接書くもの」ではなく、「専用のGUIツール（ビジュアルエディタ）を操作したら、裏側で勝手に生成されるもの」であるべきです。しかし、Fact Graphのプロジェクトにおいて、専用のGUIビルダーを構築したという話は出てきません。エンジニアたちが手作業で（あるいは簡単なスクリプトを介して）XMLをこねくり回しているのです。
注意点：属人化への一本道
私の視点から強く警告したいのは、「手書きのXML DSLは強烈な属人化を生む」という点です。最初は「XPathとfzf（コマンドラインのあいまい検索ツール）を組み合わせれば超高速でデバッグできるぜ！」とハッカーたちは喜ぶでしょう。
しかし、数年後に配属された新人はどう思うでしょうか。「なぜ今どきTypeScript（モダンなプログラミング言語）の恩恵も受けられず、黒い画面で呪文のようなシェルスクリプトを叩いて、巨大なXMLと格闘しなければならないのか」と絶望するはずです。DXを軽視した技術選定は、結果的に「あの数人の変態的エンジニアしか触れないシステム」というレガシーを生み出す最大の原因になります。
⌨️ 筆者の小話：山括弧のゲシュタルト崩壊
XMLを一日中書いていると、夢の中にまで `<` と `>` が出てきます。「開始タグを閉じ忘れた気がする...」と夜中に飛び起きた経験があるエンジニアは私だけではないはずです。現代のエンジニアは、PythonやRubyのような「書く量が少なくて済む言語」に慣れきっています。そこに突然XMLをポンと渡すのは、電動ドリルに慣れた大工に、石器時代のキリを渡すような残酷さがあります。
第7章 オープン vs. プロプライエタリ：Intuitが笑う理由
[小見出し: 透明性は競争優位性を殺すか]
[Key Question: オープンFact GraphがTurboTaxを本当に脅かせる日が来るのか？]
概念：税制のプロプライエタリ（非公開・独占的）支配
技術の話から少し視点を広げ、ビジネスと政治の文脈でこのコードを捉え直してみましょう。米国において、税金の確定申告は巨大なビジネスです。Intuit社が提供する「TurboTax」などの民間ソフトウェアが市場を独占しており、彼らは「国民が簡単に無料で申告できる政府公式システム」の構築を、強力なロビー活動（政治家への働きかけ）で長年妨害してきました。
背景：Tax Knowledge Graphという黒船
実は、筆者らがFact Graphで実現した「税法のグラフ構造化」というアイデアは、彼らが最初ではありません。記事内でも触れられていますが、Intuit社は2020年の段階で「Tax Knowledge Graph」というホワイトペーパー（技術報告書）を発表しています。
つまり、資本力に勝る民間企業は、とっくの昔に「税法はAIやグラフ構造でモデリングすべきだ」と気づいており、非公開（プロプライエタリ）な形で洗練されたシステムを構築し、そこから莫大な利益を上げているのです。
具体例：オープンソースは勝てるのか？
これに対抗するため、IRS（およびUSDSのエンジニアたち）は「Direct File」という無料申告システムを立ち上げ、そのコアとなるFact GraphをGitHub上でパブリックドメイン（公共の財産）として公開しました。「誰でも中身を見られる」「誰でも監査できる」というオープンソースの強みを活かし、民間のブラックボックスに対抗しようとしたのです。
記事の筆者も、「オープンだからこそ公的機関のコードとして価値がある」と誇らしげに語っています。
注意点：透明性だけでは巨像は倒せない
しかし、非常にシニカルな見方をすれば、Intuit社はこのオープンソース化を見て「鼻で笑っている」かもしれません。なぜなら、彼らの競争優位性は「税法の計算ロジック」そのものだけではなく、「使いやすいUI」「手厚いカスタマーサポート」「過去数十年分のユーザーデータ」、そして何より「ロビー活動による政治力」にあるからです。
いくら政府のエンジニアがXMLで美しい（あるいは泥臭い）DSLを書き上げ、それをオープンにしたところで、予算と権力でそれを「サービス終了」に追い込むことができれば、民間企業の勝ちです。実際、オープン化の背景には、政府公式システムへの強烈な政治的圧力という生々しい戦いがあるのです（この詳細は、第三部で紐解くことになります）。
🏢 筆者の小話：正しいコードより強いロビー活動
シリコンバレーのエンジニアはしばしば「より優れた技術（コード）が世界を救う」というナイーブな信仰を持っています。しかし現実は非情です。どれだけ洗練されたDSLを作っても、スーツを着たロビイストが政治家と会食するだけで、プロジェクトごと消し飛ぶのが行政システムの世界です。Fact GraphがGitHubに公開されたのは、「勝利の証」ではなく、「プロジェクトが潰された時のための遺言（バックアップ）」だったのかもしれません。
目次（第三部・第四部・補足資料）
第三部 歴史の鏡――繰り返される過ちと教訓
技術の良し悪しを議論する際、私たちはしばしば「今、目の前にあるコード」の美しさや効率性だけに目を奪われがちです。しかし、行政システムという巨大なドメインにおいては、技術的優位性よりも「歴史の反復」を直視することの方がはるかに重要です。第三部では、XMLを用いた「ルール・アズ・コード（法律のプログラム化）」の過去の死骸を掘り起こし、同じ轍を踏まないための冷徹な視点を提供します。
第8章 Tax-as-の亡霊たち：過去の失敗プロジェクト年表
[小見出し: 同じ穴に二度落ちる法則]
[Key Question: なぜ税務コード化プロジェクトは毎回政治で潰されるのか？]
概念：Tax-as-（税務のコード化）という思想
「Tax-as-（タックス・アズ・コード）」とは、自然言語（人間の言葉）で書かれた曖昧な税法を、コンピュータが直接解釈・実行できる厳密なコード（プログラムやDSL）に変換しようという思想です。これにより、解釈の揺れをなくし、申告を自動化し、国民の負担をゼロにすることを目指します。今回のFact Graphも、まさにこの思想の最先端に位置する産物です。
背景：過去に繰り返された野心的な挫折
しかし、法律をコードにするという試みは、今回が初めてではありません。1990年代のエキスパートシステム（人工知能の先駆けとなった推論システム）の時代から、世界中の政府や研究機関が「税法の完全な論理モデリング」に挑戦しては、爆死してきました。なぜか。法律には必ず「人間の裁量」や「矛盾する特例」が存在し、それを純粋な論理ツリーに押し込もうとすると、システムが天文学的な複雑さに膨れ上がるからです。
具体例：論理破綻と予算超過の歴史
例えば、過去のヨーロッパにおける税務自動化プロジェクトでは、複雑化する一方のビジネスルールをルールエンジン（ビジネス上の規則を管理・実行するシステム）に丸投げした結果、ルール同士が衝突し、「Aの条件を満たすとBが適用されるが、Bが適用されるとAが取り消される」という無限ループに陥る事例が頻発しました。Fact GraphはXMLという「安価な」表現方法を使っていますが、その背後にある「税法の複雑さをグラフで表現し尽くす」という野心は、かつての亡霊たちが挑んだものと全く同じです。
注意点：コード化の限界を見極めよ
ここで私の思考に挑戦してみます。「Fact Graphは宣言型だから、過去の命令型システムの失敗を回避できる」というのは、いささか楽観的すぎないでしょうか。宣言型は「結果」を記述するだけであり、「どのように矛盾を解決するか」はエンジンの内部実装（ブラックボックス）に依存します。税法が毎年改定され、つぎはぎだらけになっていく現実を前に、Fact Graphの巨大なXMLツリーがどこまで整合性を保ち続けられるのか。歴史は「コードが法律の複雑さに押し潰される」結末を強く示唆しています。
👻 筆者の小話：法律家の曖昧さとエンジニアの厳密さ
以前、行政のシステム開発で法律の専門家とやり取りした際、彼らは「ここの条件は『原則として』『社会通念上妥当な範囲で』適用されます」と平然と言いました。私は頭を抱えました。「社会通念」をif文（条件分岐）でどう書けと言うのでしょうか。Tax-as-の最大の敵は、コンピュータの性能でもXMLの冗長性でもありません。「人間社会の都合の良い曖昧さ」そのものなのです。
第9章 Direct Fileの栄光と急死：政治がコードを殺す瞬間
[小見出し: ロビー活動＞アルゴリズムの鉄則]
[Key Question: オープンソース行政コードは、結局ロビー勢力の玩具に過ぎないのか？]
概念：シビックテックと既得権益の衝突
「シビックテック（Civic Tech）」とは、市民やテクノロジー専門家が行政サービスを改善する取り組みのことです。本記事のベースとなった「IRS Direct File（米国税務署の無料直接申告システム）」は、このシビックテックの金字塔となるはずでした。
背景：Intuit社（TurboTax）という巨大な壁
米国では、長年にわたりIntuit社（TurboTaxの開発元）などの民間企業が、税務申告ソフト市場で莫大な利益を上げてきました。彼らは「政府が無料の申告システムを作らないこと」を条件に、一部の低所得者向けに無料版を提供するという協定（Free File協定）を結び、政府のデジタル化を強力なロビー活動で阻止してきました。2024年、バイデン政権下でようやく試験導入された「Direct File」は、この呪縛を打ち破る画期的な一歩として喝采を浴びました。
具体例：オープンソース化の裏にある敗北
しかし、読者の皆さんはお気づきでしょうか。本記事の執筆時点（2026年3月）において、Direct Fileはすでに事実上の「終了（あるいは大幅な縮小）」に追い込まれ、そのコアエンジンであったFact GraphがGitHubに「パブリックドメイン（著作権放棄）」として公開されたという歴史的文脈です。
政治的圧力、政権交代、予算の凍結。コードがどれほど美しく、XMLがどれほど安価なDSLとして優れていようとも、ロビイストたちの暗躍と政治力学の前では、アルゴリズムは無力です。筆者らがTWE（見積りツール）という別の形でFact Graphを「再利用」しているのは、ある種の敗戦処理であり、レジスタンスの延命措置とも言えるのです。
注意点：技術的優位性は免罪符にならない
エンジニアは「オープンソースで透明性が高いから我々の勝ちだ」と精神的勝利を収めがちです。しかし、社会実装という観点では完全に敗北しています。「良いコードを書けば世界が変わる」というシリコンバレー的イデオロギーは、ワシントンD.C.の泥沼の政治力学の前では通用しません。私たちがこのXMLコードから学ぶべき最大の教訓は、DSLの構文ではなく、「政治リスクを織り込んだシステム設計の脆弱性」なのです。
🏛️ 筆者の小話：最高のコードがゴミ箱行きになる日
徹夜で書き上げた完璧なアルゴリズムが、翌朝の会議で「上の鶴の一声」や「大人の事情」で全没になる。エンジニアなら誰もが経験する絶望です。しかし、それが「国家予算規模」で起こるのが行政システムです。優秀なエンジニアたちが精魂込めて紡ぎ出したFact GraphのXMLツリーが、政治家のサイン一つで無用の長物と化す。これほど残酷で、かつ示唆に富んだ現代の悲劇があるでしょうか。
歴史的位置づけの詳細を展開
第10章 XMLの波乱万丈サーガ：栄枯盛衰の皮肉な軌跡
[小見出し: 王座から墓場、そして再び？]
[Key Question: XMLの「復活」は一過性のバズか、それとも構造的必然か？]
概念：マークアップ言語の進化圧
データの構造を記述する言語（マークアップ言語）には、進化の歴史があります。1970年代のGMLから始まり、より汎用的なSGML（Standard Generalized Markup Language）が生まれ、そこからWeb向けに派生したのがHTMLとXMLです。
背景：複雑さへの反逆から生まれたXML、そしてJSON
1998年にW3Cから勧告されたXML 1.0は、SGMLの「オプションが多すぎてパーサー（解析器）を作るのが難しすぎる」という反省から、機能を大幅に削ぎ落としてシンプルにしたものでした。しかし、皮肉なことに、エンタープライズ（大企業）の世界で使われるうちに、XMLは再び複雑な仕様（XSD、SOAP、WS-*など）を背負い込み、肥大化してしまいました。
そこに救世主として現れたのが、JavaScriptから生まれた超軽量のJSONです。「もうタグなんて見たくない！」というエンジニアたちの熱狂的な支持を受け、XMLは「レガシーシステムの象徴」として墓場へ追いやられました。
具体例：なぜ2026年にXMLなのか
しかし、JSONは「複雑な文書構造」や「論理式（DSL）」を表現するにはあまりにも貧弱でした（第4章参照）。XMLには、属性（Attribute）と要素（Element）の使い分け、コメント機能、名前空間（Namespace：同じ名前のタグの衝突を防ぐ仕組み）など、データではなく「言語」を設計するための強力な武器が最初から備わっています。
本記事の筆者が「XMLは安価なDSLだ」と主張するのは、この「かつて肥大化だと忌み嫌われた重厚な仕様」が、税金という「極度に複雑なドメイン」においてのみ、奇跡的にジャストフィットしたからです。
注意点：これは「ルネサンス」ではなく「ガラパゴス」の再発見
とはいえ、これを「XMLの劇的な復活劇」と捉えるのは早計です。XMLが生き残れるのは、税務、医療、航空、金融といった、極度に厳格な監査と複雑な階層構造を要求される「ニッチだが巨大なドメイン」のみです。一般的なWeb開発にXMLが戻ってくることは二度とないでしょう。この局地的な生存戦略を、一般的な技術トレンドと混同してはいけません。
第11章 類似ドメインの惨状：医療HL7、航空AIXMが警告する罠
[小見出し: 複雑さの呪いが回帰する]
[Key Question: XMLが生き残るのは、複雑さが「必要悪」であるドメインだけなのか？]
概念：エンタープライズXML標準の光と影
税務（Fact Graph）以外にも、XMLが未だに絶対的な支配力を誇っている領域があります。代表的なのが、医療情報の交換標準である「HL7 CDA（Clinical Document Architecture）」や、航空業界のデータ交換標準「AIXM（Aeronautical Information Exchange Model）」です。
背景：人間を置き去りにした機械の言語
これらの規格は、人命に関わる極めて重要なデータを扱うため、JSONのような「ゆるい」フォーマットは許されません。XMLスキーマ（XSD）による厳格な型チェックとバリデーション（検証）が必須です。しかし、その結果何が起きたか。
HL7のXMLドキュメントは、ただの「患者の血圧データ」を伝えるために、数百行に及ぶメタデータ（データの説明のためのデータ）と難解なOID（オブジェクト識別子）のタグ付けを要求します。あまりの複雑さに、現場のエンジニアは悲鳴を上げ、パースエラーの対応に追われる日々です。
具体例：Fact Graphが向かうかもしれない未来
Fact GraphのXMLは、今はまだ「開発者が手書きできるレベル」の比較的シンプルな構造を保っています。しかし、今後数十年かけて税法が複雑化し、特例の特例が追加され続けた場合、このXMLツリーもまた、HL7やAIXMのような「人間には到底読解不可能なタグの暴力」へと変貌する運命にあります。
「XMLは人間も読める」という筆者の主張は、初期段階のプロトタイプにおける甘い幻想に過ぎない可能性があります。
注意点：規格の肥大化という自己破壊
私たちはここで、「DSLの寿命」について自問する必要があります。安価なツールで構築されたDSLは、拡張が容易であるがゆえに、無秩序に肥大化していくリスクを抱えています。XMLが「安価」であることは、同時に「複雑さを際限なく受け入れてしまう泥沼」への入場券でもあるのです。
🏥 筆者の小話：医療XMLとの死闘
私がかつて携わった医療システム統合プロジェクトで、HL7のXMLを解析するタスクがありました。仕様書は数千ページに及び、一つのタグの解釈を巡ってベンダ間で数週間の議論が行われました。「患者の性別を『M』か『F』か『U（不明）』で送る」というだけのことに、なぜ数十行のラッパーXMLが必要なのか。その時悟りました。XMLは、人間同士の「責任逃れ」を強固にパッケージングするための最強の鎧なのだと。
第四部 未来への冷笑――本当に来るのか、そのユートピア
歴史の教訓から目を背け、それでも私たちは未来を語らなければなりません。Fact Graphという壮大な実験は、今後どこへ向かうのでしょうか。AIの進化、新たな言語の台頭、そして最も重い課題である「持続可能性」。第四部では、技術的ユートピアの皮を被ったディストピアの可能性を、シニカルかつ冷静に解剖します。
第12章 LLMが法文をFact Graphに：夢か、悪夢か
[小見出し: ハルシネーション税務申告の恐怖]
[Key Question: AI自動生成された税務ルールに、誰が法的責任を取るのか？]
概念：自然言語処理（NLP）からDSLへの自動翻訳
現在、ChatGPTをはじめとするLLM（大規模言語モデル）がプログラミングの世界を席巻しています。当然、次のステップとして考えられるのが、「議会で可決された長大で難解な税法のテキスト（PDFやWord）をLLMに読み込ませ、一瞬でFact GraphのXMLを自動生成させる」という夢のシステムです。
背景：手書きXMLの限界とAIへの過度な期待
第6章で述べた通り、人間がXMLを手書きするのは苦痛以外の何物でもありません。であれば、AIに書かせれば良い。「この法案を解析して、`
具体例：AIが引き起こす致命的な「幻覚」
しかし、ここに恐ろしい落とし穴があります。LLMはもっともらしい嘘をつく「ハルシネーション（幻覚）」という致命的な欠陥を抱えています。もしLLMが税法の「または（OR）」と「および（AND）」をわずかに読み違え、誤った依存関係（Dependency）を持つXMLを生成したらどうなるでしょうか。
Fact Graphは宣言型であるため、一部のロジックの破綻が全体に波及します。気づかないうちに何百万人の納税額が1桁間違って計算され、国庫が空になる、あるいは暴動が起きるかもしれません。
注意点：責任の所在という永遠の課題
AIが生成したXMLを、最終的に誰が「正（正しいもの）」として承認するのでしょうか？ 結局のところ、人間（公務員や専門の税理士エンジニア）が、AIの出力した膨大なXMLを目視で確認し、テストを書かなければなりません。これは「AIにコードを書かせる」というより、「AIが吐き出したスパゲッティコードのデバッグ作業を人間がやらされる」という、本末転倒なディストピアの始まりを意味しています。
🤖 筆者の小話：AIに法律を読ませてみた
試しに、最新のAIに日本の複雑な「ふるさと納税の控除上限額計算」のルールを読ませて計算式を作らせてみました。出力されたコードは、一見完璧に見えましたが、よく見ると「住宅ローン控除との併用時の特例」が完全に無視されており、全員が上限を超えて寄付できる（そして後で多額の税金を請求される）という悪魔のようなロジックになっていました。AIは、責任を取らない天才詐欺師のようなものです。
第13章 行政オントロジーの幻想：標準化は永遠の砂漠
[小見出し: 誰も守らないルールブック]
[Key Question: 真の汎用行政DSLなど、存在しうるのか？]
概念：オントロジー（概念体系）の統一という野望
税務で成功した（少なくとも技術的には形になった）Fact GraphのDSLを、今度は「ビザ申請」「社会保障給付」「補助金の審査」など、あらゆる行政サービスに横展開しよう、という野心的なアイデアが必ず浮上します。これを「行政オントロジー（知識の体系）の標準化」と呼びます。
背景：サイロ化された行政機関の壁
現在、各省庁や自治体はバラバラのシステム（サイロ化）を持っています。もし、すべての行政ルールが共通の「Fact Dictionary（事実辞書：XMLフォーマット）」で記述されれば、引越しの手続きをするだけで、関連するすべての税金や補助金の計算が裏側で自動的に連携し、一瞬で完了する「デジタル・ガバメント」の夢が実現します。
具体例：標準化という名の新たなサイロ
しかし、現実は厳しいものです。A省庁の「世帯収入」という定義と、B省庁の「世帯収入」という定義は、法律の成り立ちが違うため、微妙に（しかし決定的に）異なります。これを一つのXMLスキーマで統一しようとすると、例外処理のための無数の分岐タグ（例：`
注意点：標準化のパラドックス
「標準化しようとする試み自体が、結果として新たな（より複雑な）ローカルルールを生み出す」というパラドックスがあります。XMLの強みである「柔軟な拡張性」は、このオントロジー統一という場面においては、各部署が勝手に独自タグを乱造する免罪符となってしまいます。真の汎用行政DSLは、蜃気楼のように永遠に手の届かない砂漠のオアシスなのです。
📑 筆者の小話：「標準」はなぜ増えるのか
有名なIT業界のジョーク（xkcdのコミック）があります。
「現在、14の競合する標準規格がある。これはひどい！ すべてを統合する普遍的な標準を1つ作ろう！」
数年後...
「現在、15の競合する標準規格がある。」
行政のXML標準化も、全く同じ運命をたどるでしょう。
第14章 モダンXML体験の死闘：Xee、grex、そして次の墓標
[小見出し: Rustが救う前にXMLが死ぬ]
[Key Question: 次世代ツールがXMLを救う前に、XMLコミュニティ自体が消滅する可能性は？]
概念：次世代言語によるレガシー技術の再構築
XMLのエコシステムが老朽化しているという指摘（第4章）に対し、一部の熱心な開発者たちは立ち上がっています。記事の注釈にも登場しますが、Rust（メモリ安全で超高速なモダン言語）を使って、最新のXPath/XSLTエンジン「Xee（Martijn Faassen氏開発）」を作ったり、XML文書を平坦化して検索しやすくするCLIツール「grex（Jake Low氏開発）」を作ったりする動きがあります。
背景：ノスタルジーか、実用主義か
これらのプロジェクトは、非常に高い技術力によって支えられています。Rustの堅牢性とパフォーマンスをXMLの世界に持ち込むことで、第5章で指摘した「巨大ツリーの評価コスト」を劇的に改善できる可能性があります。彼らは、XMLの表現力そのものは優れていると信じ、その「古いエンジン」だけを最新のV8エンジンに載せ替えようとしているのです。
具体例：コミュニティの限界
しかし、冷静に市場を見てみましょう。これらのモダンXMLツールに、どれほどのエンジニアがコントリビュート（貢献）しているでしょうか。何万人もの開発者が集まるReactやPythonのエコシステムに比べ、XMLのモダン化に取り組んでいるのは、世界でもごく一握りの「変態的な（最大の賛辞として）エキスパート」だけです。
注意点：ニッチ化による緩やかな死
どんなに優れたツール（Xeeやgrex）が完成しても、それを使うコミュニティの母数が小さければ、いずれメンテナンスは停止します。筆者が「XMLは安価なDSLだ（タダ乗りできる）」と豪語できたのは、過去の遺産（JavaやCの枯れたライブラリ）があったからです。次世代のツールが市民権を得る前に、XMLの読み書きができるエンジニアの世代交代が進み、コミュニティ自体が自然消滅してしまうリスクを、私たちは過小評価するべきではありません。
🦀 筆者の小話：Rustで書き直せばすべて解決するという病
最近のテック界隈には「とりあえずRustで書き直せ（Rewrite it in Rust）」という一種のミーム（流行）があります。確かに速くて安全になりますが、根本的な「XMLを手書きする苦痛」や「仕様の複雑さ」が解決するわけではありません。どんなに速いスポーツカーに乗っても、走る道が悪路の泥沼（複雑な税法XML）であれば、結局はスタックしてしまうのです。
第15章 持続可能性の最終審判：誰がこのコードを10年守るのか
[小見出し: 公的遺産か、忘却の墓場か]
[Key Question: 政府が捨てたコードを、誰が永遠にメンテするのか？]
概念：オープンソースのライフサイクルと保守の責任
システム開発において、ローンチ（公開）はゴールではなく、地獄の保守運用のスタートラインに過ぎません。本記事で絶賛されているFact Graphは、オープンソースとしてGitHubに公開されました。しかし、「オープンにした」ことと、「誰かが保守し続ける」ことは全く別問題です。
背景：去りゆく英雄と残された負債
開発を主導したエリートエンジニアたち（Alex Petros氏やChris Given氏ら）は、永遠にこのプロジェクトに留まるわけではありません。彼らは次のエキサイティングな課題へと旅立っていくでしょう。後に残されるのは、毎年複雑に改定される税法と、それを必死にXMLのタグ（<><Dependency> や <><GreaterOf>）に翻訳し続けなければならない、名もなき保守担当者たちです。
具体例：ボランティア頼みの公的インフラという狂気
オープンソースの残酷な現実は、「誰も給料をもらっていないのに、重要なバグ修正を強いられる」という点にあります。政府が公式に予算をつけて専門チームを維持しない限り、この「パブリックドメインのFact Graph」は、一部の有志の善意（ボランティア）に依存することになります。国家の税金計算のコアロジックを、休日の趣味でコードを書くエンジニアに依存することが、果たして「持続可能な公的インフラ」と呼べるでしょうか。
注意点：結論――それでもXMLは「最もマシな最悪」である
ここまで、XMLや宣言型アプローチに対する厳しい批判と冷笑的な視点を展開してきました。
しかし、最後に筆者の主張に立ち返りましょう。「XMLは安価なDSLである」。この言葉の裏には、「他にマシな選択肢がない」という絶望的な諦観が含まれています。
JSONでは論理を表現できず、S式ではツールがなく、命令型では監査ができない。消去法で残ったのが、不恰好で、冗長で、古臭い、しかし世界中どこでも動く「XML」だったのです。
10年後、このコードは誰にも触られなくなり、廃墟となるかもしれません。しかし、Intuitのようなブラックボックスに税の主権を握られ続けるよりは、不恰好でも中身が見えるXMLのツリーを国民の前に晒したこと。それ自体が、このプロジェクトが歴史に残した最大の「価値」であり、ささやかな勝利なのです。
🏁 筆者の小話：レガシーコードへの愛と憎しみ
エンジニアは皆、他人が書いたレガシーコードを憎みます。しかし、自分が10年前に書いたコードを見たとき、その不恰好なタグの羅列の中に、「当時の自分が必死に複雑な現実と戦った痕跡」を見つけて、思わず苦笑してしまうものです。Fact GraphのXMLも、未来のエンジニアから見れば「2020年代の狂気の沙汰」に映るでしょう。でも、それでいいのです。技術はそうやって、泥臭く前に進んでいくのですから。
日本への影響（日本の税制・確定申告システムへの応用可能性）
[Key Question: 複雑な日本の税制をFact Graphで表現することは可能か？]
本記事の事例は米国IRSのものですが、翻って日本の状況（デジタル庁や国税庁のe-Taxシステム）を考えてみましょう。日本の税制もまた、ふるさと納税、医療費控除、インボイス制度、定額減税など、世界有数の「パッチワーク（つぎはぎ）の複雑さ」を誇ります。
日本のシステム開発は、伝統的に大手SIerによるウォーターフォール開発と独自仕様（ブラックボックス）が主流です。もし日本政府がFact GraphのようなオープンソースのXML/DSLエンジンを採用し、「日本の税法全ルールをGitHub上で公開・監査可能にする」という決断を下せば、それは革命的なシビックテックの勝利となります。
しかし、現実には以下の壁が立ちはだかります。
- **和暦や特有の端数処理**：米国のシンプルな計算論理エンジンでは、日本のガラパゴス的な丸め処理（切り捨て、四捨五入の例外）に対応しきれない。
- **行政の無謬性への執着**：オープンソース化して「バグが見つかる」ことを極度に恐れる日本の行政文化。
- **JSON/APIへの過度な傾倒**：デジタル庁が推進するモダンなAPI連携はJSONが主流であり、「今更XMLを使う」という提案は、技術トレンドしか見ない層からの猛反発を受ける。
補足資料・巻末資料
補足1：各界隈からの（架空の）感想集
ずんだもんの感想
「XMLなんておじいちゃんしか使ってないと思ってたのだ！ でも、ツールがタダで使えるから『コスパ最強』っていうのは、貧乏性なボクには刺さるのだ。でも、手書きでタグをポチポチ打つのは絶対やりたくないのだ……枝豆の皮むきより面倒くさそうなのだ！」
ホリエモン風の感想
「いや、だからさ、XMLが安いとかJSONがダメだとか、そういう低次元な議論してる時点で終わってんのよ。本質はそこじゃないでしょ？ 重要なのは、Intuitみたいな既得権益が税金申告のプロセスを独占してて、政府のオープンなプロジェクトが潰されてるってこと。このアジャイル性に欠ける行政の構造的なバグをどうリファクタリングするか考えないと、どんなDSL使おうが意味ないよね。サクッとLLMで法解釈のエージェント作ってDAOで運用すればいいじゃん、バカなの？」
西村ひろゆき風の感想
「えっと、XMLが安いって言ってますけど、それ単に『昔の人が作った遺産にタダ乗りしてるだけ』ですよね？ 将来的に誰もそのエコシステムをメンテしなくなった時、技術的負債になって高くつくってこと、分かってて言ってます？ オープンソースにすれば透明性ガーとか言いますけど、一般の国民がXMLのタグ見て『あ、控除額間違ってる！』とか気づくわけないじゃないですか。自己満足のポエムだと思いますけどね、はい。」
補足2：別視点からの年表②（主流派が語らないXML/税務の暗黒史）
| 年 | 出来事（裏面史） | シニカルな解説 |
|---|---|---|
| 1998 | XML 1.0勧告 | 「これでSGMLの地獄から解放される！」と喜んだ直後、さらに深いSOAP/WS-*の地獄を自分たちで作り始める。 |
| 2006 | Free File協定の強化 | 米政府がIntuit等の顔色をうかがい、「公式の無料ソフトは作らない」と誓約させられる。ロビー活動の勝利。 |
| 2010年代 | JSONの覇権確立 | 開発者たちが「山括弧（<>）」を見るだけで拒絶反応を示すようになる。XMLはSIerのレガシー案件専用言語に。 |
| 2020 | IntuitがTax Knowledge Graph発表 | 民間企業が「グラフ構造による税務計算」の最適解を密かに完成させ、特許と資金の壁で囲い込む。 |
| 2024 | Direct File試験導入 | オープンソースのFact Graph（XML）が世に出る。シビックテック界隈は歓喜の涙を流す。 |
| 2025/11 | Direct Fileサービス停止 | 政治力学によりプロジェクトが急死。「美しいXML」も、予算の停止ボタンには勝てなかった。 |
| 2026/3 | 本記事の公開（TWEへの転用） | Fact Graphが「見積りツール」という安全で無害な場所に左遷され、ひっそりと余生を過ごし始める。 |
補足3：オリジナル遊戯カード『ファクトグラフの審判』
【ファクトグラフの審判（XML-Fact Graph）】
⭐️⭐️⭐️⭐️⭐️ (レアリティ：SR)
属性：光（宣言型） / 種族：魔法使い族（レガシー）
攻撃力：1500 / 守備力：3000
【効果】
このカードがフィールドに表側表示で存在する場合、相手プレイヤーは「命令型」の魔法・罠カードを発動できず、計算の中間状態をすべて公開しなければならない。
【デメリット】
自分のスタンバイフェイズ毎に、プレイヤーは「XPath」呪文を唱えなければならない。唱えられない場合、手札の「開発者体験（DX）」ポイントを2つ失う。
「安価なDSLだと？ その代償は貴様の精神で払ってもらうぞ！」
補足4：一人ノリツッコミ
「いやー、最新のシステムにはやっぱりモダンな技術を使いたいよね！税金の計算エンジン？ そりゃあもちろん、最高にクールなRustとか、イケてるTypeScriptで、シュッとJSONでデータ連携して……って、なんでゴリゴリのXMLやねん！！
いやいや待てよ、でもよく見たら『XPath』とかいう太古の呪文で一発検索できてるやん！ なんやこれ、意外と便利……って、アホか！ 令和の時代に `<Minuend>` とか `<Subtrahends>` とか、必殺技の名前みたいなタグ手打ちさせられるエンジニアの身にもなれや！ 手首腱鞘炎なるわ！」
補足5：大喜利
お題：「こんなTax-as-（税のコード化）は嫌だ」
- 計算結果がJSONで返ってくるが、<>{"status": "ご愁傷様です", "owed": "あなたの全財産"} としか書かれていない。
- 控除の条件に `
- 確定申告のたびに、紙の申告書の代わりに「自分が手書きしたXMLファイルをフロッピーディスクに入れて郵送」しなければならない。
補足6：予測されるネットの反応と反論
【HackerNews民】
「S式を使わずにXMLを選ぶなんて正気の沙汰じゃない。Lispマクロを使えばこのXMLの冗長さは10分の1になる。Prologなら推論エンジンもタダだ。筆者はLispの美しさを理解していない。」
⇒ 筆者からの反論：「美しさは認める。だが、明日からこのプロジェクトに参加する新人のJavaエンジニアやPythonエンジニアに、Lispの括弧地獄やPrologのバックトラッキングをゼロから教育するコストを払えるのか？ XMLは『誰でも（嫌々ながら）読めるし、どこにでもパーサーがある』という最低限の共通言語なんだよ。」
【なんJ民】
「XMLとかいう化石まだ使ってて草。JSONでサクッと書けない無能の集まりやろｗｗｗ」
⇒ 筆者からの反論：「複雑な構文木（AST）をJSONで表現してみろ。波括弧と `type` キーのゲシュタルト崩壊で、3日後には発狂してXMLに助けを求めて泣きついてくるに100ペリカ賭けるわ。」
【村上春樹風書評】
「やれやれ、と僕は思った。彼らは税金という、この世界で最も不条理で冷たいシステムを、XMLというまた別の不条理なタグの海で表現しようとしている。`
⇒ 筆者からの反論：「ポエムとしては評価するが、プルリクエスト（コードの修正案）を出さないなら黙っていてくれ。」
補足7：演習問題・レポート課題
高校生向け：4択クイズ
問題：記事の中で、XMLがJSONよりも「DSL（ドメイン固有言語）」の表現として優れているとされた主な理由はどれですか？
A) XMLの方がファイルサイズが圧倒的に小さくなるから。
B) JSONには複雑な入れ子構造（ツリー構造）の「種類」をタグ自体で表現する機能がなく、記述が冗長になるから。
C) XMLはAIが自動生成するのに最も適した言語だから。
D) JSONはアメリカ政府のシステムでの使用が法律で禁止されているから。
正解を見る
正解は B です。JSONはオブジェクトの「種類（Subtractなど）」を値として持たせなければならず、入れ子が深くなると非常に読みにくくなります。大学生向け：レポート課題
課題テーマ：「行政システムのオープンソース化とプロプライエタリ（非公開）ソフトウェアの対立構造について、IRS Direct FileとIntuit社（TurboTax）の事例を比較し、技術的優位性が必ずしも社会実装の成功に直結しない理由を800字程度で論じよ。」
補足8：潜在的読者のためのプロモーション案
キャッチーなタイトル案：
- 『XMLは死なず。米国政府が税金計算に選んだ「最も安価な言語」の正体』
- 『JSON至上主義への反逆：なぜ天才たちは「古臭いXML」で税法をハックしたのか？』
- 『Tax-as-の深淵：Direct Fileを支えたFact Graphと、消されたオープンソースの謎』
SNS共有用文章（120字以内）：
「XMLは死んだ」と思ってるエンジニア必読。IRSが複雑怪奇な米国税法をモデリングするために、あえてXMLを「最も安価なDSL」として採用した理由とは？JSONの限界と宣言型の罠に迫る！ #XML #シビックテック #TaxAs
ブックマーク用タグ（NDC準拠）：
<>[情報学][ソフトウェア][行政][アメリカ][XML][オープンソース][007.6]
この記事にピッタリの絵文字： 🧟♂️💸📜🏛️💻
カスタムパーマリンク案： <>xml-cheap-dsl-irs-factgraph-analysis
単行本化時のNDC区分： <>[007.63] (ソフトウェア工学・プログラミング)
テキストベースでの簡易な図示イメージ：
[税法の複雑なルール] (曖昧な自然言語)
↓
↓ (人間による解釈・翻訳の壁！)
↓
[Fact Graph (XML)] = 宣言型DSL
├──
│ └──
│ └──
│ ├──
巻末資料
用語索引（アルファベット順）
- AIXM：航空情報交換モデル。航空業界のデータをやり取りするためのXMLベースの厳格な国際標準。
- AST（抽象構文木）：プログラムの構造をコンピュータが扱いやすい「木（ツリー）」の形で表現したもの。
- Direct File：米国IRSが試験導入した、国民が直接・無料で確定申告を行えるシステム。TurboTaxなどの民間ソフトと競合する。
- DX（開発者体験）：エンジニアがコードを書く際の「快適さ」や「生産性の高さ」のこと。
- DSL（ドメイン固有言語）：特定の業務（今回なら税金計算）のためだけに作られた、専用の小さなプログラミング言語。
- Fact Graph：米国税法のルールをXMLベースのグラフ構造で表現した論理エンジン。事実（Fact）の依存関係を定義する。
- HL7 CDA：医療分野における電子カルテなどの文書交換の標準規格。XMLの冗長性と複雑さの極みとして悪名高い。
- イントロスペクション（Introspection）：プログラムが自分自身の状態（なぜその計算結果になったのか等）を内部から参照・証明できる能力。監査に必須。
- JSON：現在最も人気のある軽量なデータ表現形式。人間にも読みやすいが、複雑な論理（DSL）を書くには不向き。
- KDL：XMLやJSONの代替を目指す、モダンで人間に優しいデータ記述言語。
- LLM：大規模言語モデル（ChatGPTなど）。文章を理解・生成するAI。
- Prolog：論理プログラミング言語。ルールと事実を定義すると、AIのように推論して答えを出してくれる。
- Tax-as-：法律（税法）を、自然言語ではなくコンピュータが直接実行できるコードとして定義しようとするムーブメント。
- USDS（米国デジタルサービス）：政府のITシステムを近代化するために、シリコンバレーなどから優秀なエンジニアを集めた専門部隊。
- XPath：XML文書の中から、特定の要素（タグ）や属性をピンポイントで探し出すための検索言語。
免責事項
本書（本記事）の記述は、Alex Petros氏のブログ記事「XML is a cheap DSL」および関連するオープンソース・プロジェクト（Fact Graphなど）の公開情報に基づく分析・推論・個人的な見解を含んだ読み物です。著者は米国政府、IRS、USDS、またはIntuit社等のいかなる公式見解も代弁するものではありません。また、本記事内で提示された税金の計算ロジックやXMLのサンプルコードは、技術的な解説を目的としたものであり、実際の確定申告や税務相談に使用することは絶対に避けてください。あなたの税金が計算ミスで「/totalOwed（支払うべき全財産）」になっても、筆者は一切の責任を負いません。
脚注
※1 ハルシネーション（幻覚）：
第12章で言及。AIが、学習データに基づき「もっともらしいが全くの嘘」を出力する現象。法律の解釈においてこれが発生すると、致命的なコンプライアンス違反を引き起こす。
※2 プロプライエタリ：
第7章等で言及。ソフトウェアの設計やソースコードが企業によって非公開とされ、独占的に管理されている状態。オープンソースの対義語。
※3 トポロジカルソート：
第5章で言及。物事の「依存関係（Aが終わらないとBができない）」を整理し、矛盾なく実行できる順番に並べ替えるアルゴリズム。Fact Graphの計算エンジンの中核技術。
謝辞
まず、枯れた技術と思われていたXMLに再び光を当て、知的好奇心を刺激する素晴らしい記事を執筆してくれたAlex Petros氏に感謝します。また、複雑怪奇な米国税法に挑み、オープンソースの形で貴重な知見（Fact Graph）を世に残してくれたChris Given氏をはじめとするUSDSおよびIRSのエンジニアチームの皆様の勇気に敬意を表します。そして、長大でシニカルな本レポートを最後まで読み通してくれた読者の皆様（あなたがまだXMLのタグの海で溺れていないことを祈ります）に、心からの感謝を捧げます。
コメント
コメントを投稿