OpenAIのApp Serverに日本の税務がつながる日を考える。事務所が推論コストゼロでAI窓口を配れる世界
OpenAIのApp Serverに日本の税務がつながる日を考える。事務所が推論コストゼロでAI窓口を配れる世界
前の記事で、OpenAIがライバルAnthropicのClaude Code上で自社モデルを動かす手順を自ら公開した件と、その裏にあるCodex App Server（Codexのハーネスをサードパーティ製品に組み込むための公式プロトコル）を整理した。この記事はその続きで、「この仕組みの先に何があるのか」をClaude Codeと議論した内容を、思考実験としてまとめたものになる。事実と推測を分けながら書く。特に自分の本業である日本の税務にこの仕組みがつながったらどうなるかを、図で整理しておきたい。
前提: App Serverの何が新しいのか
事実関係を2つだけおさらいする。
第一に、Codex App ServerはCodexのエージェント実行ランタイムを自社以外の製品に組み込むための公式プロトコルで、OpenAI自身が「Unlocking the Codex harness」というブログで設計経緯を公開している。もともとCodex CLIやVS Code拡張を動かす内部インターフェースだったものを、外部の開発者に開いた。
第二に、認証には「Sign in with ChatGPT」が組み込まれていて、利用はエンドユーザー自身のChatGPTプランの枠に載る。つまりCodexを組み込んだアプリの開発者は、推論コストを負担しなくてよい。ユーザーが自分のサブスクを持ち込む形になる。
この2つを組み合わせると、「AIエージェント入りのアプリを、AIの原価ゼロで配れる」という、アプリ開発の前提を変える構図が出てくる。
OpenAIが組み立てている5層
なぜOpenAIがここまで開放するのかは、同社が組み立てている垂直スタックの中に置くと見通しが良くなる。AppleがiPhoneで作った「ハード＋ID＋配布＋データ＋課金」の5層スタックと対応させると、部品が既に揃いつつあることがわかる。
| 層 | Appleの部品 | OpenAIの部品（2026年前半時点） |
|---|---|---|
| デバイス | iPhone | Jony Ive氏のio買収（約65億ドルと報道）で専用デバイス開発中 |
| アイデンティティ | Apple ID | Sign in with ChatGPT |
| 配布 | App Store | ChatGPT内アプリ（Apps SDK）と Codex App Server |
| データ | iCloud | ChatGPTのメモリ・会話履歴 |
| 課金 | App Store手数料 | サブスク＋エコシステムからの手数料（形成中） |
Appleの歴史から類推すると、収益化の本命はユーザー向けの値上げではなく、エコシステムが固まった後の「通行料」——アプリ内課金の手数料やコマースのテイクレート——になる可能性が高い。iPhoneの値上げではなくApp Storeの30%で稼いだのと同じ形だ。
ここから先は思考実験になる。この配布層に、日本の税務がつながったらどうなるか。
接続の形は2つある
税務アプリとOpenAIエコシステムの接続には、方向が逆の2形態がある。
形1はChatGPT内アプリ型だ。freeeやマネーフォワードのような税務SaaSが、ChatGPTの中にアプリを出店する。納税者側の体験はこうなる。2月のある晩、「今年の確定申告やっといて」と一言。ChatGPTは会話履歴から、その人が今年転職したこと、子どもが生まれたこと、夏に親の医療費を相談していたことを知っている。会話の中で税務SaaSのアプリを呼び出して銀行・カード連携データと突き合わせ、「医療費控除の整理が必要です。ふるさと納税の限度額が2万円残っています」まで自然に出てくる。ユーザーはSaaSの画面をほぼ見ない。
この形で起きるのは、税務SaaSのUIの価値が溶けることだ。SaaSは「会話から呼ばれる計算エンジン＋法令準拠の責任主体」に後退し、顧客接点はOpenAIが握る。しかも決定的なのはデータの非対称で、SaaSが持っているのは取引データだけだが、ChatGPTは生活文脈——家族構成の変化、引っ越し、通院——を持っている。控除の「発見」は取引データより生活文脈から生まれるので、入口の会話を握る側が、いちばん価値のある「気づき」の部分を取る。
形2がApp Server型で、こちらは向きが逆になる。税務SaaSや税理士事務所が、自社のアプリの中にCodexのエージェントランタイムを組み込む。顧客接点は自社に残り、OpenAIは組み込みエージェントの供給者になる。
形2を掘り下げる: 事務所が推論コストゼロでAI窓口を配れる
形2は税理士事務所の視点で見ると、脅威ではなく武器になりうる。構図を図にするとこうなる。
流れを言葉にすると次のようになる。
- 顧問先は事務所の顧問先ポータルに「Sign in with ChatGPT」でログインし、質問や資料アップロードをする
- ポータルには事務所の税務ナレッジ・運用ルール・料金表が搭載されていて、その文脈でエージェントが動く
- エージェントの実体はApp Serverで組み込んだCodexハーネスで、エージェントループ・履歴・承認フローはプロトコルが面倒を見る
- 推論はOpenAIのバックエンドで実行され、課金は顧問先自身のChatGPTサブスク枠を消費する
ポイントは費用構造だ。従来この種の「顧問先向けAI窓口」を作ろうとすると、事務所がAPIの従量課金を負担する必要があり、顧問先が使えば使うほど事務所の原価が膨らんだ。App Server型では推論コストがユーザー持ち込みになるので、事務所は原価ゼロで「うちの事務所のナレッジで24時間答えるAI窓口」を顧問先に配れる。資料の収集・リネーム・仕訳データの突合のような、いま事務所側がAIエージェントで内製しているワークフローを、顧問先側の入口に置けるようになる。
その先の構造: SaaSは「帳簿データ基盤」に縮退するかもしれない
形2の世界を事務所の側から突き詰めると、もう一段先の構造変化が見えてくる。ここは完全に自分の見立てになる。
いまの構造では、会計事務所と税務申告の間にフル機能の税務SaaS——マネーフォワードやfreee——が挟まっている。仕訳入力の画面、ワークフロー、帳簿、申告連携が一体になった「全部入り」で、画面は人間が見て操作する前提で作られている。そして正直に言えば、開発は遅く、使いづらい。
エージェントが実務を担うようになると、この「人間向けの画面」の部分がまるごと要らなくなる。事務所としてはSaaSの画面を挟まず、エージェントに直接やらせたい。ただし会計データの置き場は必要で、そこはOpenAIが出してくれる領域ではない。だとするとSaaSに残る役割は、「複式簿記が正しく記録でき、監査証跡が残る帳簿」というデータ基盤に絞られていく。要件定義のしっかりした台帳がひとつあればよくて、その上のUIとワークフローは、事務所が配るエージェントアプリの側が担う。
この構造になると、会計事務所自身がアプリケーションを出す道も開ける。App Server型なら推論コストは顧問先持ち込みなので、事務所規模でも配れてしまう。ただし現実には、申告だけでなく労務や経費精算といった周辺領域まで吸収しないと業務が完結しないので、一足飛びには行かないだろう。それでも方向としては、全部入りSaaSのUIは「人間の目」のためにあった中間物で、エージェントの時代に残るのは台帳と証跡だけ——という見立てを持っている。
エコシステムの完成形: 機能を「足す」から、機能を「組む」へ
では帳簿データ基盤の上に何が乗るのか。周辺領域を誰が吸収するのかを考えると、エコシステムの完成形が見えてくる。
いまのSaaSは、1社のベンダーが機能を追加し続けることで製品を便利にしていくモデルだ。記帳、経費精算、労務、請求書、申告——機能が増えるほど製品は大きく重くなり、事業者は使わない機能も含めて月額を払う。
ChatGPTのストアとApp Serverのエコシステムが完成したときに起きるのは、この逆回転だと思っている。ベンダーや個人開発者が機能を個別のアプリとして切り出してストアに出品し、事業者は必要な機能だけを選んで組み合わせる。記帳エージェントはA社製、経費精算は個人開発者製、年末調整はまた別のベンダー——という構成が普通になる。課金はユーザーのChatGPTサブスクの中で完結し、OpenAIがアプリストアのように手数料を取ってベンダーに分配する。
これはスマホで一度起きたことの再演でもある。「全部入り」の端末からApp Storeの「必要なアプリだけ入れる」への転換と同じ構造で、違いは組み合わせの主体が人間ではなくエージェントになることだ。事業者が「うちの業務はこの構成で」と言えば、エージェントがストアから機能を選んで組み、共通の帳簿データ基盤に読み書きする。バンドルの価値だった「機能間の連携」は、エージェントが機能同士を橋渡しすることで置き換わる。そしてこの形なら、前の記事で見た5層スタックの課金層——エコシステムからの手数料——がそのまま完成する。OpenAIが赤字でも配布を開放し続ける理由は、この完成形から逆算すると腑に落ちる。
アプリとアプリは、どうつながるのか
この絵に対してすぐ浮かぶ疑問がある。機能単位のアプリを組み合わせると言っても、年末調整アプリは労務アプリから給与データを取ってこないと動けない。ベンダー同士が互いのデータ仕様を知らなければ接続できないはずで、業界全体でデータ規格を統一するのは過去の歴史を見ても相当に厳しい。どうやってつなぐのか。
答えの核心は、「事前の規格統一」が「実行時の意味理解」に置き換わることだと思っている。従来のAPI連携で規格統一が必要だったのは、人間の開発者が両側の仕様書を読んで、フィールドの対応付けコードをあらかじめ書いておく必要があったからだ。エージェントの世界では、各アプリは自分の機能の入出力スキーマ（データの型）と自然言語の説明を公開するだけでよい。それを読んで「労務アプリのこの出力フィールドは、年末調整アプリのこの入力に対応する」と解釈し、実行時にデータを変換して受け渡すのはエージェントの仕事になる。接続コードは事前に書かれない。この「アプリが自分の使い方を機械可読な形で自己記述する」仕組みは、MCP（Model Context Protocol）として既に業界標準になっていて、ChatGPTのアプリの仕組み（Apps SDK）もこの上に作られている。
ソースコードの心配については、公開されるのはインターフェース（スキーマと説明）だけで、実装はベンダーのサーバー側で動く。エージェントから見えるのは「何を入れると何が返るか」であって、中の計算ロジックやデータやノウハウは見えない。真似できるのはインターフェースの設計だけで、これは今のSaaSがAPIを公開しているのと同じ守り方だ。ただし競争の質は変わる。エージェントは複数のアプリを使い比べて、結果の悪いものをためらいなく乗り換えるので、差別化はインターフェースではなく実行品質——精度、速度、そして証跡の信頼性——に移っていく。
もうひとつ、会計にはこの世界と相性のいい事情がある。複式簿記という500年ものの「データ標準」が既にあることだ。アプリ同士が網の目のように直接つながる必要はなく、どのアプリも最終的には仕訳という統一形式で帳簿データ基盤に書き込めばいい。前のセクションで「残るのは台帳と証跡」と書いたが、接続の観点から見ても、帳簿はアプリたちの共通の合流点——ハブ——として機能する。
弱点も書いておくと、エージェントの解釈ミスがそのまま接続ミスになる。「課税支給額」と「総支給額」の取り違えのような、人間の経理担当者でも間違える意味の揺れは、エージェントも間違えうる。だからこそ「どのアプリのどのデータを、どう解釈して帳簿に書いたか」の監査証跡が生命線で、帳簿データ基盤の要件定義が何より重要だという話に戻ってくる。
税務SaaSのジレンマと、税理士に残る価値
接続の話から入口の話に戻ろう。形1と形2の2形態を並べると、日本の税務SaaSは前の記事で書いたAnthropicと同じジレンマに立たされることがわかる。ChatGPT内に出店（形1）すれば入口では勝てるが顧客接点を失う。出店しなければ、生活文脈を握った入口に「気づき」の部分を取られていく。自社でAIを抱えて対抗するか、OpenAIの配布網に乗るか。Claude Codeというハーネスを握られたOpenAIが取った「開放して既定の選択肢になる」という答えを、今度は日本のSaaSが自分の問題として解くことになる。
税理士の側はどうか。記帳代行・資料収集・突合のような作業は、どちらの形態でもエージェントに吸われていく。残るのは、判断責任（税務代理・書面添付）、グレーゾーンの意思決定、税務調査対応、そしてAIの出力を疑って検証する目だ。日々AIエージェントの出力を突き合わせながら使っている感覚で言うと、この「検証する目」の部分が職業の中心になっていくのだと思う。
日本特有の摩擦が3つある
この世界観がそのまま実現するかというと、日本には固有の摩擦が少なくとも3つある。
第一に税理士法だ。税務代理・税務書類の作成・税務相談は税理士の独占業務で（税理士法2条・52条）、無償でも無資格者は業として行えない。AIが個別具体的な税務相談に答えることがどこまで「税務相談」に当たるかは既にグレーゾーンで、この種のアプリが普及するほど日税連と国税庁の論点になる。皮肉なことに、これは税理士にとって制度の堀として働く。申告代理と判断責任はAIに渡せない建付けになっている。
第二にデータ主権だ。国民の課税情報や金融データが米国企業の会話メモリに蓄積される構図を、金融庁・国税庁がそのまま容認するとは考えにくい。e-Taxやマイナポータルとの接続点を誰が持つかを考えても、OpenAI直結ではなく、間に国内のSaaSか税理士が挟まる形が現実解になるだろう。
第三に責任の所在だ。AIが控除を見落とした、AIの判断が誤っていた——その責任をアプリ提供者・SaaS・ユーザーの誰が負うのか。ここでも「責任を取れる資格者」の価値が残る。
ロックインはどの層に効くのか: 開発者と一般ユーザーで正反対
最後に、この議論の途中で自分の理解が一段深まった点を書いておく。当初「ベンダー側に会話履歴やメモリが溜まり、それがスイッチングコストになる」という説明を受けて、そこには懐疑的だった。自分の業務コンテキストは手元のリポジトリにあるからだ。CLAUDE.md、作業メモ、セッションログ、ルールファイル——効いている文脈資産は全部ローカルのファイルで、ベンダー側には溜まっていない。クラウド側の会話データには保持期間があり、訓練利用を拒否すれば消えていく前提の設計だ。だから開発者は、モデルを環境変数1本で替えられるのと同じように、文脈ごと乗り換えられる。
議論の結果、この直感は正しくて、ただし層によって答えが逆になるという整理に落ち着いた。
開発者の文脈はファイルという持ち運び自由な形式で存在していて、囲い込みが効かない。だからOpenAIは開発者に対して、囲い込みではなく開放——ハーネス不問、App Server、サブスク持ち込み——で「既定の選択肢」の座を取りに行く。一方、一般ユーザーはローカルにファイルなど持たない。「AIが自分の家族構成も仕事も覚えている」という状態はベンダーのサーバー側にしか存在せず、持ち出す手段も習慣もない。メモリの重力が効くのはこちら側で、ChatGPT本体の堀はここにある。
税務の思考実験に戻すと、この区別はそのまま当てはまる。形1（ChatGPT内アプリ型）が強いのは、一般ユーザーの生活文脈という「持ち出されないデータ」を握っているからだ。形2（App Server型）で事務所側に残せるのは、顧客接点と事務所のナレッジ——つまり事務所にとってのローカルファイルに相当する資産だ。どちらの世界でも、自分の文脈資産をどこに置くかが交渉力を決める。
まとめ
- Codex App ServerとSign in with ChatGPTの組み合わせは、「AIエージェント入りのアプリをAI原価ゼロで配れる」という配布の仕組みで、OpenAIが組み立てる5層スタック（デバイス・ID・配布・データ・課金）の配布層にあたる
- 日本の税務がつながる形は2つ。ChatGPT内アプリ型は顧客接点と生活文脈をOpenAIが握り、税務SaaSは計算エンジンに後退する。App Server型は顧客接点とナレッジが事務所・SaaS側に残り、推論コストは顧問先のサブスク枠に載る
- 税理士事務所にとって形2は、原価ゼロの「事務所ナレッジ搭載AI窓口」という武器になりうる。一方で記帳・突合はどの形でもエージェントに吸われ、判断責任とAIの出力を検証する目に価値が凝縮していく
- その先では、全部入りの税務SaaSは「複式簿記の記録と監査証跡が残る帳簿データ基盤」に縮退し、人間向けのUIとワークフローは事務所が配るエージェントアプリに移る可能性がある
- エコシステムの完成形は、機能単位のアプリをストアから選んで組み合わせる世界。課金はサブスク内で完結し、OpenAIが手数料を取ってベンダーに分配する。スマホのApp Storeの再演で、組み合わせの主体だけが人間からエージェントに替わる
- アプリ間の接続は「事前の規格統一」ではなく「実行時の意味理解」で成立する。アプリはスキーマと説明だけを公開し（実装は見せない）、変換と受け渡しはエージェントが担い、結果は複式簿記という既存のデータ標準で帳簿に合流する
- 税理士法の独占業務・データ主権・責任の所在という日本固有の摩擦があり、OpenAI直結ではなく国内SaaSか税理士が間に挟まる形が現実解になりそうだ
- ロックインは層で効き方が正反対になる。文脈資産がローカルファイルにある開発者は囲えないから開放で取り、文脈資産がベンダー側メモリにしかない一般ユーザーはメモリの重力で囲う。自分の文脈資産をどこに置くかが交渉力を決める