T:0のエンジニアが語る：AI会計はなぜ推測に終始するのか？総勘定元帳が結論だけを記録し、経緯を捨て去ったからだ
T:0（Airwallex傘下）のエンジニアErikによる論考：総勘定元帳にどれほど高速なAgentを繋いでも、推測することしかできない。複式簿記は本来、算術によって検証可能な「オントロジー」を備えている。ソフトウェアによって失われたリンクを復元して初めて、AIは証拠を指し示しながら「なぜ」に答えられるようになる。
過去2年間、市場にはAI会計プロダクトが次々と登場し、そのプロダクトページには判で押したような文句が並んでいる。総勘定元帳にAgentを組み込み、照合作業を数日から数分へ短縮し、変動分析（残高が変動した理由の説明）を自動下書きし、「数週間ではなく数時間で決算を完了」、手作業の9割以上を自動化する、といった具合だ。
先日、クロスボーダー決済企業Airwallex（空中雲匯）傘下のフィンテック子会社T:0が非公開ベータを終え、米国スタートアップ向けに提供を開始した。T:0のエンジニアリングチームメンバーであるErik（@eya0）は、X上で長文記事『Why Every AI Accountant Fails, and Why Palantir Knew First』を公開した。
既存のAI会計プロダクトが「なぜ」に答えられない原因は、モデルの能力不足ではなく、その足元にあるソフトウェアによって平坦化された総勘定元帳にある。会計は500年前に誕生した当初からオントロジー（複式簿記）を備えていた。誤っていたのは、大半のソフトウェアがそれを無視し、転記の瞬間にリンクを破棄して結論の一覧表だけを残したことだ。
これはT:0チームによるプロダクトおよびアーキテクチャに関する記事であり、顧客事例や効果の数値はベンダー自身の主張である。筆者は、政府や大企業向けデータプラットフォームを提供する米国ソフトウェア企業Palantirの「オブジェクト／リンク／アクション」フレームワークを援用し、なぜ元帳の基盤をまず修復しなければ財務においてAIが信頼できる回答を出せないのかを論じている。
総勘定元帳は「結末」だけを記録し、「物語」を捨て去った
この判断を理解するには、まず会計ソフトウェアの基底にある総勘定元帳（General Ledger、GL）が実際にはどのような姿をしているかを把握する必要がある。
複式簿記の基本ルールは極めてシンプルだ。すべての取引は少なくとも2箇所に記録され、一方が借方、もう一方が貸方となり、両者の金額は必ず一致しなければならない。どの現代的なエンタープライズリソースプランニング（ERP、SAP、NetSuite、QuickBooksなど）を開いても、総勘定元帳の本質は日付、勘定科目、借方、貸方、摘要が並ぶフラットな明細表であり、時に数百万行にも及ぶ。
仕訳の1行1行は、すべてある物語の結末である。その物語の経緯や取引経路は、元帳の中には一切残されていない。
Erikは記事の中で、年間サブスクリプション請求の具体的な事例を挙げている。
この 4,120 ドルのサブスクリプションは、総勘定元帳にこのように一歩一歩記録される
-
3 月 14 日
請求書発行：顧客が 4,120 ドルの年間サブスクリプションを契約。資金は未受領で、サービスも未提供。
借売掛金4,120.00 貸繰延収益4,120.00繰延収益（Deferred Revenue）：請求済みだがサービスは未提供のため、顧客に対する負債として計上。中国の会計基準では通常「契約負債」と呼ばれるが、本稿では米国基準の呼称を踏襲する。
-
3 月 18 日
顧客入金：資金はまず決済プロセッサー（Stripe 等）に留まり、会社の銀行口座には未着金。
借プロセッサー・クリアリング4,120.00 貸売掛金4,120.00プロセッサー・クリアリングは中継勘定：資金がプロセッサーにある時に計上され、銀行に送金された時に振り替えられ、入出金で相殺されて残高ゼロとなる。
-
3 月 21 日
プロセッサー支払い：この入金と他の 40 件をまとめて 1 回の決済支払いとして会社に送金。手数料 123.60 を差し引き、純額 3,996.40 が一括で銀行に着金。
借銀行預金3,996.40 借手数料123.60 貸プロセッサー・クリアリング4,120.00この 1 件のみを見た場合：4,120.00 − 123.60 = 3,996.40。
3 つの日付、7 行の仕訳、5 つの勘定科目。借方合計 12,360.00、貸方合計 12,360.00。
図1：左は総勘定元帳における孤立した7行、右はつながりを持った同一の取引。
1つのビジネスイベントが、総勘定元帳の中では互いに孤立した7行の仕訳へと分解される。約1週間にわたり、3つの日付に跨がり、5つの勘定科目に分散する。すなわち売掛金、繰延収益、プロセッサー・クリアリング、手数料、銀行預金である。支出側の1ドル1ドルも同様で、コーポレートカードの引き落としから2つの口座から資金調達される給与支払いまで例外ではない。図1の右側にはこの1本の収入ラインのみを描いているが、完全なマップは請求書、給与、コーポレートカード、送金、株式など、総勘定元帳全体を網羅する。
物語の残りの部分は、元帳の外に散らばっている。決済プロセッサー、請求システム、銀行取引明細、データウェアハウスなどだ。これこそが月末決算が存在する理由である。1つのチームが結論から物語を逆算し、監査では第2のチームがさらに高いリスクと少ない背景情報の中で同じ作業を繰り返す。
いま、この平坦な総勘定元帳に最先端の大規模言語モデルを接続し、CFOが真に気にかけている問いを投げかけてみる。
「今月、なぜ繰延収益が変動したのか？」
T:0チームによれば、彼らはこのテストを実施したという。総勘定元帳をエクスポートしてフロンティアモデルに渡し、同じ質問を3回尋ねたところ、自信に満ち、流麗に書かれた、しかし互いに矛盾する3つの回答が返ってきた。これはモデルの能力が足りないからではなく、答えがデータの中にそもそも存在しないからだ。総勘定元帳は結論を記録しているが、つながりを捨ててしまっている。フラットな総勘定元帳だけで業務を説明するようAIに求めるのは、映画のエンドロールの出演者リストだけを手がかりに完全なプロットを推論させようとするようなものだ。流暢で文法的に正しく、一見もっともらしい文章は得られるだろうが、それは単なる推測にすぎない。
業界の解法：より高速な簿記係
冒頭に挙げたプロダクトの背後にあるエンジニアリングは本物であり、照合、下書き作成、決算のスピードは確かに向上した。
しかしT:0チームの実直な反応は、「それがどうしたというのか？」であった。
この種のプロダクトはいずれも、総勘定元帳の現状——平坦な結論のリストと、互いに対話しないバラバラのソースシステム——を所与のものとして受け入れ、その上に超高速なAgentを配置したにすぎない。Agentによるデータの「考古学的発掘」は確かに高速化した。照合も速くなり、下書きも速くなり、決算も速くなった。だが、何が知り得るのかという根本は何も変わっていない。
データモデル自体が「なぜ」に答えられないのであれば、その上に乗るAgentも答えられない。より流暢に推測できるようになっただけだ。そして、流暢に語られる推測こそ、CFO、監査人、取締役会が決して受け入れられないものである。
足が速くなった簿記係も、依然として簿記係にすぎない。天井はモデルにあるのではなく、基盤にある。
財務においてAIに信頼できる回答を出させるには、まず足元の基盤を修復しなければならない。そして基盤の修復こそ、Palantirが名を馳せた理由である。
Palantirは一体何を理解したのか
オントロジー（Ontology、本体）という言葉は、かつては哲学やデータベースの教科書に属していたが、今やCEOたちが決算説明会で口にするようになった。Palantirのデモにおけるロジックは一貫している。AIが失敗するのはモデルが弱いからではなく、足元に立つべき強固な基盤がないからだ。したがって、AIを意思決定に関与させる前に、組織のデジタルツインを構築する必要がある。存在するオブジェクト、オブジェクト間のリンク、オブジェクトを変化させるアクションを定義し、互いにつながりのない生のテーブルの山ではなく、このモデルの上でAIを動作させるのである。
神秘性を剥ぎ取れば、オントロジーの概念は至ってシンプルであり、3つの基本構成要素しかない。
- オブジェクト（Objects）：ビジネスにおける名詞。航空機、貨物輸送、発注書など。これらはテーブルの1行ではなく、属性とライフサイクルを持ったエンティティである。
- リンク（Links）：名詞同士の関係。この貨物輸送があの発注書を履行した、この部品があの航空機に属している、といった関係である。
- アクション（Actions）：制御された動詞。明確に定義され、監査可能な操作であり、これらだけがオブジェクトの状態を変更し、ソースシステムへ書き戻すことを許される。
筆者は、これこそがPalantirが巨大なビジネスを築き上げた鍵だと指摘する。型付けされたオブジェクトと実在する関係の上で推論するモデルの回答には現実の根拠があるが、生のテーブルの上で推論するモデルはもっともらしい文章を生成することしかできない。モデル自体はコモディティ化しつつあり、真の堀はモデルの足元にあるセマンティック層にある。
しかし、Palantirのビジネスにおける難所は、顧客ごとに世界がまったく異なる点にある。航空機は貨物輸送ではなく、患者でもない。日常業務におけるオントロジーは極めて個別的（Bespoke）であり、顧客ごとに選択を下さなければならないため、Palantirは顧客ごと、オブジェクトごとにエンジニアを派遣してゼロからモデリングを行う必要がある。
会計は生まれながらにしてオントロジーを備えている
1494年、ルカ・パチョーリ（Luca Pacioli）は『算術、幾何、比および比例全書』（Summa de arithmetica, geometria, proportioni et proportionalita）を出版し、当時のヴェネツィア商人が用いていた簿記手法を記録した。現代の視点で見れば、彼が記したのはデータ構造の定義（Schema）そのものである。個々の経済事象は特定の型の仕訳として記録され、借方と貸方は必ず一致し、仕訳は決済イベントへと結びつき、取引間を数珠つなぎに連結する。複式簿記は単なる記帳の慣例にとどまらず、オントロジーそのものであり、本番環境で最も長期間稼働し続けているシステムとさえ言える。
Palantirの顧客とは異なり、会計のオントロジーは完全に標準化されている。T:0がQuickBooksからSAPに至る主要ERP 7社のオブジェクトモデルを調査したところ、どのシステムにも共通する30余りのオブジェクトが存在することが判明した。請求書（Invoice）、貸方票（Credit Memo）、入金（Payment）、返金（Refund）、前受金（Prepayment）、仕入請求書（Bill）、支払い（Payout）、給与支払い（Payroll Run）などである。各ベンダーが互いに模倣したわけではない。オブジェクトが一致するのは、それらが現実のビジネスイベントに対応しており、ビジネスの姿はどこであっても大差ないからだ。名詞は何百年も前にすでに確定している。
さらに、会計をPalantirがモデリングしてきたあらゆる領域と明確に分かつ特徴がもう1つある。会計において、リンクは証明可能だということだ。
日常業務のオントロジーにおいて、「この貨物輸送はあのサプライヤーに関連している」というのはモデリング上の決定であり、有用ではあってもモデラーのアサーション（断定）に属する。一方、会計においては、ある返金は確実に特定の入金に対応し、ある入金は確実に特定の請求書を消し込む。マップ全体が、至る所で借方と貸方が一致するという鉄則を満たさなければならない。これはマップ全体が最初から内包している完全性検証であり、後世の人々が「データ検証」という言葉を発明する500年も前から存在していた。他の領域ではオントロジーを構築した後にそれが正しいことを祈るほかないが、会計は自己照合の仕組みを元から備えている。AIにとって、この違いは決定的に重要だ。アサーションで構築されたオントロジーの上ではモデルの根拠が正しいと信じるしかないが、証明可能なオントロジーの上では検証が可能になる。
このことは、現代の会計ソフトウェアの現状をいっそう奇妙なものに浮き彫りにする。オントロジーは目の前にあり、古く、標準化され、算術的に検証可能であるにもかかわらず、その上に真に構築されたシステムが存在しない。ERPはオブジェクトを保存するが、転記の瞬間にリンクを破棄してしまう。仕訳とは、物語が息絶える場所なのだ。
そこでT:0は、これとは正反対のアプローチでシステムを構築した。
コネクテッド・アカウンティング・マップ（Connected Accounting Map）
T:0の出発点はただ1つ、「物語を残すこと」である。財務諸表上のすべての数字は、各オブジェクトと各リンクを通り抜け、それを最初に引き起こしたビジネスイベントまで遡ることができる経路の終点であるべきだ。T:0はこれを「コネクテッド・アカウンティング・マップ」（Connected Accounting Map）と呼んでいる。
筆者は記事の中で、このマップはすでに本番環境で稼働しており、Reddit、GoodRx、Vimeo、MasterClassなどの財務チームのために毎年数十億件の会計レコードを生成していると述べている。
注記：これらの顧客名や「毎年数十億件のレコード」という記述は筆者のこの記事にのみ現れるものであり、Airwallexのプレスリリース、T:0 CEOのローンチブログ、公式サイトには記載されていない自社主張である。T:0が公表している資料におけるターゲット顧客は米国のスタートアップ企業とされている。
このマップは3つの要素で構成されている。
オブジェクト（Objects）
システムに入るすべての経済イベントは、システムが理解可能な標準オブジェクトに変換される。請求書、入金、返金、支払い、仕入請求書、給与支払い、銀行取引などである。どのソースシステムから入ってきても、同種のイベントは同一の形状を持つ。各レコードは自分が何であるか、誰が関わっているか、ライフサイクルのどの段階にあるかを自覚している。
これは当たり前のように聞こえるが、実行するのは極めて重労働だ。オントロジーは標準的であっても、現実のシステムにあるデータは統一されていない。最も典型的な例が「deposit」という単語である。
- QuickBooks：銀行へ送る準備が整った顧客からの入金のまとまりを指す。T:0は「顧客入金のバッチ」と解釈する。
- NetSuite：未請求の状態で顧客が先に支払った資金（前受金）を指す。T:0は「請求書との対応待ちの前受金」と解釈する。
- 商業銀行の明細書：入金されたあらゆる現金を指す。T:0は「確認待ちの銀行取引」と解釈する。
1つの単語が互いに無関係な3つのイベントを表し、3種類の異なる会計仕訳に対応する。「deposit」の解釈を誤れば、マップは顧客の前受金を他人の銀行明細に結びつけてしまい、下流のあらゆる結論が密かに狂い、誰もそれに気づかない。だからこそ、この作業はデータ取り込み時にソースシステムごとに個別に行い、いかなるAIが登場するよりも前に完了させておく必要がある。マップを既存システムの上に後から被せることはできない。
リンク（Links）
すべてのオブジェクトは、関係性をデータとして保持する。この入金があの請求書を消し込んだ。今回のプロセッサー決済支払いはこれら41件の入金を一括送金し、41件の手数料を差し引いた。この返金は特定の引き落としを取り消し、その引き落としは特定の契約に対応している、といった具合だ。
元帳の支出側でも全く同一のロジックが貫かれる。仕入先への支払いがベンダー請求書を消し込み、資金移動が給与支払いの原資となり、銀行取引が資金の着金を確定させる。
図2：入金と出金の2つのチェーンは同じ形状をしており、すべての接続線は双方向に照合可能。
図2の下段は資金流出を示しており、構造は収入側と同様にベンダーと仕入請求書から始まり、最終的に銀行取引に行き着く。中間の3ステップの仕訳は以下の通りである。
- 請求書明細：借方 費用、貸方 買掛金
- 請求書支払：借方 買掛金、貸方 請求書支払クリアリング
- 支払流出：借方 請求書支払クリアリング、貸方 銀行
「請求書支払クリアリング」は、前述のプロセッサー・クリアリングと同様、資金が移動中にある際に用いられる中継勘定であり、支払時に計上され、銀行からの引き落とし時に振り替えられ、正常であれば入出金で相殺されて残高ゼロとなる。これと同じ構造は給与、コーポレートカード決済、立替経費精算、社内資金移動にも現れる。
図の最下部には、各接続線をどのように照合するかが示されている。収入側では、入金＝請求書残高、支払い＝入金合計−手数料合計。支出側では、請求書支払＝請求書総額。両側とも最終的に銀行着金＝決済純額を満たし、至る所で借方と貸方が一致する。
3月の4,120ドルのサブスクリプション事例に戻ろう。T:0において、それはもはや7行の散在した仕訳ではなく、契約 → 請求書 → 顧客入金 → 支払い → 銀行取引明細という完全なパスとなる。人間もマシンも、このパスを双方向に辿ることができる（図1右側の起点は注文 Order と表記）。この入金に伴う123.60ドルの手数料は支払いに紐づき、各仕訳はそれを生成したオブジェクトとつながったままだ。逆方向に辿ることもできる。銀行の入金から出発し、まずその支払いに含まれる41件の入金を展開し、該当する4,120ドルの顧客入金を特定し、さらに請求書と契約へと遡ることができる。
1 行の仕訳から逆引き調査：7 行の仕訳はそれぞれどの業務オブジェクトに紐づいているか
- 契約 / 注文ビジネスの起点、仕訳は生成しない
- 請求書発行
- 請求書（請求書明細）借 売掛金 · 貸 繰延収益
- 入金がこの請求書を消し込む
- 顧客入金借 プロセッサー・クリアリング · 貸 売掛金
- この入金が支払いにまとめられる
- 支払い借 銀行預金 · 借 手数料貸 プロセッサー・クリアリング同バッチで 41 件の入金、41 件の手数料
- 支払いが銀行取引明細によって確認される
- 銀行取引照合アンカー、仕訳は生成しない
会計がリンクに求める要件は「証明できないものはつながない」ことだ。支払額が一致しない場合や、入金に対応する請求書が見つからない場合、マップは推測を交えず、ギャップを記録して明確にアラートを出す。財務の領域では、もっともらしいリンクよりも誠実なギャップのほうが遥かに価値が高い。
アクション（Actions）
オブジェクトとリンクが世界を描写し、転記ルールが世界を変える。T:0におけるすべての仕訳はルールから生成される。この種のオブジェクトが特定の条件下で出現した際、リンクされたオブジェクトを参照し、仕訳を記録する。転記の段階で場当たり的な判断を下すことはなく、「普段はこうしている」という曖昧さもない。同じイベントが入力されれば、出力される帳簿は毎回完全に一致する。
これは会計上の判断が消失したことを意味するのではなく、判断があるべき場所へ移ったことを意味する。毎月何千もの取引の中で見えない形で場当たり的に繰り返すのではなく、人間が慎重に一度だけ判断を下し、誰でも読めるルールとして記述するのだ。AIが判断そのものをどのように変えるかについて、原著者は別の記事で論じると述べている。
ここがAIの介入ポイントであり、同時に境界線が引かれる場所でもある——読み取りと書き込みの厳格な分離だ。
- 読み取り側：AIはマップ全体を自由に探索し、質問への回答、レポートの下書き、異常値の調査、変動の説明を行うことができる。導き出されるすべての結論は、辿ったパスを伴って検証可能である。
- 書き込み側：AIは設計のみを担当し、決して実行はしない（the AI designs, it never executes）。転記ルールの提案、新規ベンダー支出の分類の提案、ポリシーを実行に移すワークフローの下書きを行うことはできる。しかし、すべての提案は人間のレビューを経てルール化され、決定論的エンジンに引き渡されて実行されなければならない。AIは提案を生成するのであって、数値を生成するのではない。数値は算術からしか生まれない。
図3は両者を並べて対比させたものである。オブジェクトの行において、Palantirは顧客ごとにゼロからモデリングする必要があるが、会計のオブジェクトは業界共通である。リンクの行において、Palantirの接続線はモデラーのアサーションによるが、会計の接続線は算術的に照合可能である。アクションの行において、Palantirはソースシステムへ書き戻す制御された操作であるのに対し、T:0ではAIが転記ルールを設計し、決定論的エンジンがそれを実行する。
図3：Palantirの運用オントロジーとT:0の会計マップの項目別対比。
マップ上のAgentに何ができるのか
リスト上のAgentは昨日のプロセスを高速化することしかできない。一方、マップ上のAgentは従来のプロセスでは不可能だったことを成し遂げられる。しかも筆者によれば、Agentの発言はすべて辿ったマップと突き合わせて検証できるため、人間の監視なしで実行可能だという。Agentに真の責任を委ねることを可能にしているのは、マップによるAgentへの制約そのものである（なお、この自律的な運用は読み取り側の調査と検証に限定されており、元帳への書き込みには依然として人間が承認したルールが必須である点に留意されたい）。筆者によれば、以下の5項目のうち最初の4項目はT:0のAIにおいて現在稼働している機能であり、5項目目は今後の開発方針であるという。まず全体像を俯瞰する。
- 変動分析：以前は2つの残高の差を見てストーリーを創作していたが、マップ上では接続線を辿って背後にある具体的な契約や請求書を調査できる。
- 照合：以前は総勘定元帳と銀行明細を1件ずつ突き合わせていたが、マップ上ではすでに存在する予測値と照合・確認する。
- 監査：以前は手作業でサンプリングして全体を推計していたが、マップ上では年間を通じて全件を網羅的に走査する。
- 決算：以前は月末に集中的に辻褄を合わせていたが、マップ上では常に決算完了済みの状態が維持される。
- 仮説検証（What-If）：本物の元帳のブランチ上で新条項の影響を算出する。現時点では未実装。
変動分析：「なぜ」は自由作文ではなくクエリになった
現在のAIによる変動分析（2つの期間の勘定残高を比較し、変化の理由を説明する作業）の多くは、ナラティブに基づく推測に依存している。モデルは2つの残高の差額を見て、その差額に関するストーリーを書き上げるのだ。
マップ上では、なぜ繰延収益が変動したのかをT:0に尋ねても、ストーリーをでっち上げることはなく、接続線を辿って走査する。たとえば、214件の契約が予定通り履行されて売上計上され、12件に変更が生じ、3件の返金によって過去の計上が取り消された、といった結果を提示する。支出側も同様で、「なぜクラウドコストが40%増加したのか」と尋ねれば、もっともらしい文章を返すのではなく、背後にある具体的なベンダー請求書やカード取引へと直接分解する。AIが追跡するのはデータとして存在するチェーンであり、導き出される結論にはすべて証拠が付随する。証拠とは、AIが辿ったパスそのものだからだ。
照合：マッチングそのものが不要になる
銀行照合が存在するのは、総勘定元帳と銀行が互いを知らない見知らぬ同士のようなものであり、誰かが仲介して引き合わせる必要があるからだ。「銀行照合が90%高速化」というのは、この波のプロダクトが最も好む宣伝文句である。
しかしT:0において、その引き合わせはとうの昔に完了している。プロセッサー決済支払い、請求書支払、給与資金移動など、各ノードは銀行に現れるはずの取引明細を、金額、口座、時間枠に至るまで正確に事前予告する。3月のあの支払いは、銀行に着金する前からいくら入金されるかがすでに明示されており、そのうち当該サブスクリプションに帰属する額は3,996.40ドルであることが分かっている。銀行明細が取り込まれた際に行われるのは、マップ内にすでに存在する予測値の確認であり、ゼロからのマッチングではない。残るごくわずかな真の例外については、どのリンクが途切れたのか、マップが予測していたものは何か、実際に届いたものは何かという完全なコンテキストを携えてAgentが1件ずつ調査する。より速くマッチングできるのは単なる機能にすぎず、マッチング自体が不要になることこそがアーキテクチャである。
監査：サンプリングから全件網羅的な走査へ
監査においてサンプリングが行われるのは、あらゆる数値の発生源を手作業で遡るコストが高すぎ、1件1件検証することが不可能なため、たとえば60件を手作業で抽出して全体を推計せざるを得ないからだ。
T:0では、すべての数値が最初から来歴を伴っており、検証はグラフ走査（トラバーサル）へと変わる。銀行取引明細書の任意の入金から、その中に含まれる個々の支払いを分解し、それぞれの請求書や契約まで遡ることができる。人間が60件をサンプリングして推計するのではなく、Agentが年間を通じてマップ全体を継続的に走査し、辿ったパスを添えて発見事項を報告する。監査は年に一度の発掘作業ではなく、システムが常に維持し続ける特性となる。
決算：もはや「名詞」ではなくなる
月末決算が存在するのは、バラバラのシステムが徐々に乖離していくため、定期的に無理やり辻褄を合わせなければならないからだ。
元帳のリンクが継続的に維持されていれば、ある意味で常に決算が完了している状態となり、決算は耐え忍ぶべき一大突貫工事ではなく、単なる確認のチェックポイントに変わる。T:0の自社発表によれば、マップを導入した財務チームは決算所要時間を90%短縮したという。記事中では、決算を6日から3日へと半減させた企業の事例も紹介されている。市場が「数週間ではなく数日で決算」と喧伝する中、真のゴールは「決算（Close）」がもはや特別なイベントとしての名詞ではなくなることだ。
OpenAIの財務チームもゼロデイ決算を目標に掲げており、現在も構築を進めている。『OpenAI CFOが語る、AIで財務チームを変革する方法——2つの目標、5つの教訓、そしてそのまま使えるスコアカード』を参照。
仮説検証（What-If）：実元帳のブランチ上で未来をシミュレーション（未実装）
コネクテッド・マップはすでに起きた世界を記録すると同時に、コードのようにブランチ（Fork）を作成することも可能にする。
筆者の構想によれば、AIに仮説を提示した際、AIは妄想に走るのではなく、実在するイベント履歴をフォークし、異なる収益認識方針、契約構造、価格モデルを適用し、決定論的エンジンにブランチ上で現実世界を再生させて、2つの世界間の差異（Diff）を出力する。新しい契約条件の下で帳簿がどうなるかを、表計算ソフトでモデリングするのではなく、実際の取引データ上で直接算出するのだ。会計は古くから過去を記録する学問であったが、フォーク可能なマップは会計を未来のリハーサルを行うツールへと変貌させる。
これら5つの項目を振り返ると、いずれもAIのケイパビリティであり、モデルのケイパビリティではないことがわかる。モデルは他社と同じものを使っており、違いはモデルが立っている足場にある。最も賢いAgentであっても平坦な元帳の上に置けば推測するしかなくなるが、マップの上に置けば知ることができるのだ。
3つの教訓
厳密さが求められる金融シナリオにおいてAIの実装を真剣に検討しているチームに向けて、T:0は3つの教訓をまとめている。
- オントロジーは標準的だが、データは混沌としている。T:0は当初、難所はAIにあると考えていたが、実際はそうではなく、正規化こそが難所であった。7つのERP、十数個の決済プラットフォームのそれぞれが、500年続く同一のオブジェクトを異なる方言へと仕立て上げている（前述のdepositがその例だ）。近道は存在せず、見過ごされたエッジケースは、最終的に誰かの帳尻が合わない数字となって跳ね返ってくる。
- 金融の領域において、確率論的に成立するリンクはリンクが存在しないことよりも有害である。AI業界は通常95%の信頼性に慣れ親しんでいる。レコメンデーションシステムにはそれで十分かもしれないが、監査においては致命傷となる。高い確率で正しいリンクは、遅かれ早かれ誰かの収益の数字の中で一度は誤りを犯し、その一度の発見がシステム内の他のすべてのリンクに対する信頼を失墜させる。T:0のアプローチは、リンクは証明されるか、さもなければ存在しないかのどちらかであり、欠落は一目で分かるように表示するというものだ。信頼は利息のように積み上がるが、一度の不履行が長年の蓄積を帳消しにしてしまう。
- AIは推論の弁舌ではなく、パスの提示によって信頼を勝ち取る。財務責任者、監査人、取締役会は、AIの説明が論理的に聞こえるからといって信用することはない。彼らが信じるのは証拠だけだ。監査の検証に耐え得るAIの結論は、マップのパスに対応づけられる結論だけである。すなわち、これらのオブジェクト、これらのリンク、このルール、この仕訳という対応関係だ。すべての答えを遡源できる基盤を整えて初めて、信頼は盲目的なギャンブルではなく、確認可能な検証作業となる。
結語
業界は競うように、より賢いAgentを同じように陳腐な総勘定元帳の上に載せようとしている。筆者は、この競争は方向を見誤っていると考える。モデルがもたらすのは表現の流暢さであり、マップがもたらすものこそが真実である。そして会計において、真実そのものがプロダクトの価値のすべてなのだ。
筆者によれば、Palantirは組織がAIを信頼に足るものにするためにオントロジーを中心にデータを再構築する意欲があることを証明したが、その代償として顧客ごとに手作業でオントロジーを組み上げなければならなかった。会計には最初から突貫工事のチームなど不要である。そのオントロジーは1494年以来目の前に存在し、業界全体で共通しており、自己検証のメカニズムを内包しながら、ソフトウェアがそれを真摯に扱う日をただ待っていたのだ。
T:0の自己定義こそ、まさにそのソフトウェアである。より賢い簿記係ではなく、すべての数字が自らの来歴を記憶している帳簿と、それをようやく読み解くことができるAIの組み合わせだ。
Palantirはオペレーションに対してオントロジーの価値を示したが、T:0はそれを財務に対して示そうとしている。