AIネイティブな財務部門を作って分かったこと — OpenAI CFOの5つの教訓
2026年8月10日、OpenAI の CFO サラ・フライアが、社内の財務部門をAI前提に作り替えてきた経験を5つの教訓として公開した。
読んでみると、AIツールの紹介はほとんど出てこない。 書かれているのは、判断のために情報を組み立てる仕事をどう並べ替えたか、という話である。
掲げている目標は2つある。決算の締めに日数をかけない状態と、自動で更新され続ける予測である。 どちらもまだ到達していない、と本人が明記している。
出発点は、どこの経理とも変わらなかった
2年前に入社した時点では、猛烈な速度で成長する会社を小さな財務チームが支えている状態だった、と書いている。
そのときの仕事の中身が、日本の経理の現場とほとんど同じである。 締めと予測の更新には、情報を探し、何が変わったのかを説明し、判断材料を組み立てる手作業が残っていた。 世界で最も進んだAIツールを持っていながら、それを前提に財務をどう組み直すかは学んでいる途中だった、という書き方をしている。
ここが読みどころだと思う。 道具があることと、その道具に合わせて仕事の形が変わることは、別の出来事として起きる。
1. まず全員に配り、それから使う理由を作る
最初にやったのは、広くアクセスを配ることだった。 ただし配るだけでは足りず、実際の問題を持ち寄る場と組み合わせたときに価値が出た、と続く。
具体例として挙がっているのが、財務部門で開いたハッカソンである。 セールスエンジニアを招き、参加者には「変えたい仕事」を持ってきてもらった。
そこから生まれたのが IR-GPT だった。 投資家からの質問に答えるためにIRチームが使う、承認済みの資料を土台にしたカスタムGPTである。 調達や税務でも同じように作り始めた、とある。
この日の意味は、抽象的な能力が動く道具に変わったことだという。 繰り返し発生する作業を見つけ、その場で作り、同僚に試してもらい、直すところまでを1日でやった。 使い道を出したのは、その仕事に一番近い人たちだった。
現場からの提案と、経営が資源を集中させる領域。 この2つが出会うところに機会がある、というのがこの節の結論である。
2. 意思決定を起点に、業務全体を組み直す
財務チームは、判断材料を組み立てることに膨大な力を使っている。 予測のレビュー1回のために、最新のデータを探し、表計算を突き合わせ、差異を説明し、グラフを作り、文書にまとめ、それをスライドに直す。 分析はいずれ意思決定者に届くが、そこに至るまでにチームの時間の多くが消えている。
AIは仕事の単位を変える、と書いている。 元データから意思決定までの経路を、丸ごと設計し直せるようになる。
例として出てくるのが決算の締めである。 実績はあるシステムに、発注は別のシステムに、見越しは表計算ソフトに、差異の理由はメッセージのやり取りの中に埋もれている。 この描写は、日本の会計事務所や経理部が抱えている状態とそのまま重なる。
目指しているのは、承認済みの支出計画、元帳の実績、発注、見越し、取引明細が常時照合された状態である。 どの差異も、もとになった活動まで辿れる。 AIが説明の下書きを用意し、注意が要る例外を指摘する。 数値を検証し、判断を加え、最終的に承認するのは財務が担う。
この節でいちばん腑に落ちたのは、締めそのものが消えるわけではない、と断っている点だった。 消えるのは、期末が終わってから事業を組み立て直す慌ただしさのほうだと書いている。
照合された土台の上に、継続的に更新される予測が乗る。 統計モデル、営業の会話、取引先ごとの根拠、業務データ、財務の判断を1つの画面に集める。 新しい受注がまだ基準値に入っていなければ、その裏付けを示し、四半期や通期にどう効くかを見せる。 財務は前提を点検し、複数の筋書きを比べ、承認済みの予測を更新するかどうかを決める。
同じ画面が資本配分にも効く。 広告費がどこで回収できていて、どこで頭打ちになっているのか、次の1単位をどこに移すと何が起きるのかを見られるようになる。
節の結びは手順の話になっている。 結果の重い意思決定を1つ選び、そこから逆算する。 必要なデータ、道具、承認、受け渡しを書き出し、そのどこをAIが分析・調整・完了できるかを決める。
3. 財務の担当者が道具を作る側に回る
より大きな変化はここだ、と書いている。
OpenAI の調査として、財務職の専門的なAI利用のうち40%が伝統的な財務の外側の仕事で、22%がエンジニアリング寄りの作業だという数字が挙がっている。
チーム全員が ChatGPT と Codex でダッシュボードや道具を作っていて、仕事の中心が静的なExcelモデルとPowerPointから、事業のデータの上に載る画面へ移りつつある。 これらの道具は分析を先へ進め、追加の質問に答え、もとの情報が変われば自分も更新される。
具体例として挙がっているのが、広告事業を担当する同僚の話である。 その人はコードを書いた経験がなかった。 Codex を使って、月次の広告予測を週次と日次の計画に落とす道具を作った。 平日と休日を織り込み、複数の予測を比べ、すべての数字が承認済みモデルに紐づいたまま保たれる。
問題を理解している人が、解決策の形まで決められるようになった、という言い方をしている。 道具を作る過程そのものが、いつものやり方を問い直すきっかけにもなる。
財務チームの専門性が薄まるのではない。 専門性をより遠くまで運べるようになる、という結び方をしていて、この整理は使えると思った。
4. 速さには、責任の所在と統制を組み合わせる
IR-GPT からは統制についての教訓を得た、とある。
投資家からの質問に答えるには、過去の資料を横断して探し、回答を書き、整合性を確かめ、レビューを回す必要がある。 以前は数時間、ときに翌朝までかかっていた作業が、承認済みの情報を土台にすると数秒で十分な初稿になる。
ただし人の役割は中心にある。 IRチームが下書きを読み、判断と文脈を加え、投資家ごとに答えがぶれていないか確かめる。 AIが作業を速くし、結果は人が持つ。
そのうえで、CFOがIT部門やガバナンス部門と組んで決めるべきことが列挙されている。 どのデータにAIが触れてよいか、どの操作を取ってよいか、いつ承認が必要か、いつ上へ上げるか。 すべての出力は信頼できる情報源につながっていること。 すべての予測には説明が付いていること。 承認済みの基準値を変えるときは財務の承認を要すること。
費用の管理についても短く触れている。 「tokenmaxxing」の一時的な熱狂は過ぎ去り、いまでは使用上限、予算管理、役割ごとのアクセス権、モデルの振り分け、承認のしきい値を設定できる。 他の変動費と同じ規律で扱いながら、作って試す余地は残せる。
責任の所在がはっきりしているからこそ、速く動ける。 組み立てや照合が速くなったぶん、前提を疑い、事業に助言し、判断を下す時間が増える、という順序で書かれている。
5. 片付いた仕事の量で価値を測る
CFOには、業績に紐づいたAIの評価軸が要る。 席を増やしたことや使用量が増えたことは、ほとんど何も教えてくれない。 大事なのは、仕事がちゃんと片付いたかどうかと、実際にいくらかかったかである。
業務ごとに問う4つが挙がっている。
財務チームにとっての「意味のある仕事」は、予測が1本更新されること、差異が1つ説明されること、監査の依頼が1件片付くこと、取締役会の質問に答えが出ることだと具体化している。
締めの評価軸としては、所要日数、自動で照合できた取引の割合、人の確認が必要な例外の件数、差異を説明できるまでの時間。 予測の評価軸としては、精度、更新の頻度、新しい筋書きを1本作るまでの時間、そしてその予測が支えた判断の質。
最後の一文が実務的だった。 最も安いモデルが、最も経済的なモデルとは限らない。 より良いモデルが、少ない試行と少ない確認で信頼できる答えに届くなら、全体では安くつく。
では、何のシステムを使っているのか
記事にはシステム名が1つも出てこない。 気になったので OpenAI 自身の求人票を横断して読んでみたところ、輪郭が見えてきた。
先に読み方を決めておきたい。 求人票にツール名が出てくる箇所は、性格の違う2種類に分かれる。
1つは業務内容(In this role, you will)に名指しされているもので、入社後に実際に触る対象である。 もう1つは応募要件に「〜のようなツール」と例示されているもので、こちらは候補者に求める経験の幅にすぎない。 他社製品と横並びで並記されている場合、そこから自社の採用システムは読み取れない。
業務内容に名指しされているもの
| 領域 | システム | 根拠 |
|---|---|---|
| 会計・元帳 | Oracle Fusion | 経理マネージャー職の業務内容に「Business Systems チームと Oracle のワークフローおよび連携について密に協働する」。応募要件でもOracle Fusionを優先と明記 |
| 顧客・案件管理 | Salesforce | GTMプロセス職の業務内容に「取引先の親子構造、TAMの整合性、Salesforceの取引先データの健全性を保有する」。職務記述そのものがSFDC前提で書かれている |
応募要件に例示されているもの
| 領域 | 挙がる名前 |
|---|---|
| 調達の受付と購買ワークフロー | Zip |
| 出張・経費、法人カード | Navan、Brex、Concur |
| 外部人材の管理 | VNDLY |
| 契約・プライバシー | OneTrust |
| 請求・課金 | Stripe、Metronome |
| (他社製品との一般列挙) | Coupa、SAP、NetSuite、Jira、ServiceNow |
最後の行だけ扱いが違う。 これらは調達やERPを触った経験があることを示すための並記で、複数の他社製品と横並びに置かれている。 ここから「OpenAIはCoupaを使っている」とは読めない。
一方でZipは、確認した3つの調達職すべてで列挙の先頭に置かれていた。 Navan、Brex、VNDLYも複数の求人に繰り返し現れる。 確証ではないが、扱いの差ははっきりしている。
会計ソフトを置き換える話ではなかった
会計の記帳基盤はOracle Fusion、顧客側はSalesforce。 どちらもエンタープライズでは定番の製品で、自社開発ではない。
そう分かると、ゼロデイクローズの意味が具体的になる。 記事が「承認済みの支出計画、元帳の実績、発注、見越し、取引明細をつなぐ」と書いていたのは、Oracle Fusionの元帳、調達システムの発注データ、表計算に残る見越しといった、すでに別々に存在するものを常時照合された1つのビューに束ねるという意味になる。 会計ソフトを捨てて何かに乗り換える話ではない。
購買まわりの顔ぶれも示唆的である。 Zip、Navan、Brex、VNDLYはいずれも近年のSaaSで、巨大なERPの中に購買や経費を抱え込むのではなく、入口ごとに専用のツールを置いて後ろでERPにつなぐ構成になっている。 つなぎ目が増えるぶん、常時照合しておく必要も上がる。
日本の経理と会計事務所に引き寄せて読む
「ゼロデイクローズ」という言葉に飛びつく前に、この記事は順序のほうを見たほうがいいと思う。
日本の中小企業や会計事務所の現場には、そもそも常時照合された土台がない。 実績は会計ソフト、発注はメール、見越しはExcel、差異の理由は担当者の記憶の中にある。 図2の左側そのものである。
だからといって、この記事は「土台を作ってからAI」とは言っていない。 逆で、結果の重い意思決定を1つ選び、そこに必要な経路だけを整えろ、という順序になっている。 全社のデータ基盤を先に作る話とは、着手の場所が違う。
そのうえで、規模を問わず今日から使えるのは第5の測り方だと思う。 特にQ2の「人の時間・確認・やり直しまで含めていくらかかったか」は、AI導入の効果報告でいちばん抜けやすい。 生成にかかった費用だけを見て、出てきたものを人が直した時間を数えないと、たいていの試算は実態より良く出る。
承認の線引きも、税務や会計の実務では避けて通れない。 記事の書き方は「AIが作業を速くし、結果は人が持つ」で最後まで一貫していて、下書きを作らせる範囲と、最終責任を負う人を分けている。 この分け方は、そのまま事務所の内部規程の言葉にできる。
締めの一文として、著者は自分がいつも言っていることを引いている。 見えないものには、なれない(you can't be what you can't see)。 AIで何ができるかをチームに受け入れてほしいなら、まずそれがどんな姿かを見せる必要があり、CFOにとってはそれが自分自身から始まる、と結んでいる。
出典
→ What building an AI-native finance function taught me(Sarah Friar, OpenAI, 2026-08-10)
システム名の裏取りに使った求人票(2026-08-12時点の掲載内容)。
→ Accounting Manager, San Francisco(OpenAI 採用ページ)