データサイエンティスト・BI エンジニアが data driven 経営をリードする
(Python, Julia, Rust, C/C++, Haskell, Idris, Coq, TypeScript/React 実装 @ Claude Code + MCP)
本記事の核心メッセージ
ERM ⇄ FP&A を、型安全なパイプラインで統合する
リスク情報(ERM 部門が持つ脅威・地政学・規制アラート)と、経営パフォーマンス計測(FP&A 部門が持つ売上・利益・ROE 予測)の間にある データ断絶 を、 8つのプログラミング言語を駆使して、Haskell & Idrisの型システム + Coqの形式手法 + Claude Code + MCP で繋ぎ、 data driven 経営を加速する BI パイプライン を構築します。
本連載について
リスクが顕在化してから、財務予測が更新されるまで ── 皆様の勤務先では、何日かかっていますか？
多くの企業で、この所要時間は 90 日 です。
月次決算サイクル、四半期報告サイクル、Excel と Email と Slack の手動連携を経て、ようやく経営会議のスライドに反映されます。
その間、ERM 部門が把握していた脅威情報は、財務的な意思決定の場に到達しないまま、時間が過ぎていきます。
本連載では、この 90 日の遅延 を 数時間 に短縮する技術スタックを、Python・Julia・Rust・C/C++・Haskell・Idris・Coq・TypeScript/React の 8 言語と、Claude Code + MCP を使って実装していきます。BI エンジニア・データサイエンティストの皆様が、明日から手を動かせる粒度で解説します。
なぜ BI エンジニア & データサイエンティストの皆様に、本連載をお届けするのか
企業の意思決定の質を変えるのは、経営者ではありません。
経営者は、目の前に提示されたダッシュボードと数値を見て判断します。
そのダッシュボードを設計し、その数値を生成するデータパイプラインを構築するのは、BI エンジニアとデータサイエンティスト ── 皆様自身です。
つまり、皆様が設計したデータパイプラインの構造が、その企業の経営判断の射程を決定づけるのです。
ERM部門が把握している脅威情報が、皆様のパイプラインに流れていなければ、経営会議のスライドには反映されません。
リスク量を織り込んだ収益指標 が皆様の SQL クエリで計算されていなければ、経営者は$ROE$ 5%という数字 を2つ並べて、「同じ業績」と判断します。
（本記事の後半で、これを定量化する新指標 $SAROIC$ を提案します）。
産業全体が変わるかどうかは、技術者次第
産業界には、「経営層の意識が変われば現場も変わる」という発想が根強く残っています。
しかし、現実は逆です。
技術者が新しいデータパイプラインを動かさない限り、経営層は古い情報で判断し続けます。
本連載は、皆様に「経営層の判断材料を変える側」になっていただくための実装ガイドです。
8つのプログラミング実装言語と、Claude Code + MCPとReact（Functional Reactive Programming）を駆使して、リスクと財務を統合した経営インテリジェンスを、皆様の手でビルドしていきます。
数学的な厳密性も、皆様の領域
データパイプラインの正しさを保証するためには、SQL の結合ロジック、データの来歴(lineage)、整合性条件 ── これらを 数学的に検証可能な形 で記述する必要があります。
この記述には、層理論(Sheaf Theory)や圏論的構造が直接的に役立ちます。本記事執筆者は、過去に下記の関連記事を Qiita で公開しています。
本連載の Idris・Coq のセクションでは、これらと地続きの数学的構造を、経営判断の場で再利用していきます。
- Sheafで構造的異常検知 ― 銀行不正・サプライチェーン・障害特定・センサー融合をPythonで統一的に解く
- GCNが見逃す不正を捕まえる ─ Neural Sheaf Diffusionで挑む不整合検知の実装ガイド
Engineer's TL;DR — 本記事の技術要素
本記事は、データサイエンティスト・BI エンジニアの皆様が data driven 経営をリードするための実装記事です。
最後に、React による経営ダッシュボードの実装を、Claude Code + MCP で、コード実装するハンズオン解説まで掲載します。
コードの全文は GitHub に公開予定です(まだ準備中)ので、リポジトリにコード掲載後、git clone して皆様の勤め先の会社や、皆様が経営されている Tech 系ベンチャーでご利用いただけます。
また、連載記事では、Python & Julia、Haskell & Idris、C/C++ & Rust、Coq など8言語の実装コードも紹介します。これは大企業の BI インフラ・データパイプラインの実装で、実際にどの言語がどういう場面で使われているのかの事例を解説しながらコードを解説します。
なお、Python は PEP 8 と型アノテーション付きの記述法を採用しています。他の言語も、推奨される流儀を採用しています。
Claude Code + MCP のハンズオン演習、形式手法による経営判断の検証 ── それぞれ、読者の皆様の実務にお役立ていただける要素をお届けします。
こんなお困りごと、ご経験はありませんか?
皆様の勤務先の企業や、皆様自身が経営されている Tech 系ベンチャー企業には、おそらく次のような職種の方々がいらっしゃるはずです。
リスクを追いかけている人たち
- サイバーセキュリティの脅威インテリジェンス・アナリスト
- 地政学リスク・規制リスク・法務リスクの兆候を追いかけているセキュリティエンジニア
- 監視カメラや IoT 機器、社員間メール、社外取引先とのメール、Slack・Teams・Webex のやりとりをモニタリングして、不正取引やキャッシュバックの兆候を調べている 統合リスク管理部門(ERM:Enterprise Risk Management、全社的リスクマネジメント) のアナリスト
- 内部統制・内部監査のアナリスト・エンジニア
彼らは、会社にとっての「良くないこと」が起きる兆候を、日々追いかけています。
経営パフォーマンスを計測している人たち
一方、別の部門では、まったく違う仕事が動いています。
- 各事業や各商品・製品・サービスについて、今月や来月の予想売上高、予想経費支出額、利益率を計算している
- Corporate Finance(経営財務)の用語で言うと、内部収益率(IRR:Internal Rate of Return)(経営管理で使われている既存の指標) を計算している
- 銀行から借り入れた運転資金や、株主から出資を受けた資本金を元手に、自社がどれくらいの価値を生み出しているかを測る ROE(Return on Equity、自己資本利益率)(経営管理で使われている既存の指標) を計算している
これらを担っているのが、経営管理部門の ファイナンス・エンジニアや クオンツです。
ところが ── 経営パフォーマンスを「リスクの量」抜きに測ると、致命的な見落としが生まれる
ここで、重要な問題が起きます。
経営パフォーマンスを計測する際には、「同じ ROE でも、リスクの量が違う」 ことを織り込まないと、判断を誤ります。
例えば、同じ ROE 5% をたたき出している事業が2つあったとします。一見、同じ成績に見えますが ──
- 各事業が、日々直面している 事業固有リスクは、同業他社や自社の過去統計データから、向こう数ヶ月以内に、99.5%の確率で最大何億円の損害を引き起こすリスクなのかを計算できます
- この 予想最大損失額(99.5%の確率でこの金額以下に収まる、つまり残り0.5%の確率でこれ以上の損失が発生しうる金額)を、各事業の予想利益・予想 ROE から 差し引いて評価する必要があります
そうしないと、「少ないリスクで、同じだけの投資パフォーマンスを得られている事業の方が優れている」という重要な情報が抜け落ちてしまうからです。
事業固有リスクの具体例
事業固有リスクとは、例えばこんなものです。
- 中国からの部品輸入や、中国への販売量が主力の事業:中国政府の貿易規制、経済取引規制、安全管理基準の急変などの 規制リスク・カントリーリスク・地政学リスクに直面している
- LLM を活用している側面が大きい事業:LLM からの情報流出などの AI 固有リスクに直面している
これらのリスクは、刻々と変化します。中国政府の規制方針は数日で変わるかもしれません。LLM の脆弱性は新しい攻撃手法が日々発見されています。
地政学リスクの兆候を、技術的にどう追いかけるか ── 関連既存記事
本連載で扱う 地政学リスク・規制リスク・カントリーリスク の兆候を、SIGINT(信号情報)・ELINT(電子情報)などのインテリジェンス領域から、技術者の言葉で解説した関連記事を本記事執筆者が Qiita および Zenn で公開しています。
-
Qiita 記事:【データサイエンティスト向け】民間産業界で広がるSIGINT/ELINT需要とPython解析入門 ── 経済安全保障時代のキャリア機会
- Zenn Book:民間技術者のための SIGINT／ELINT 入門
本連載の ERM × FP&A 統合パイプラインに、これらの 地政学リスク兆候情報 を流し込む手法は、後続の回で具体化していきます。
データの断絶 ── 多くの企業の経営判断を遅らせている根本原因
ここからが、本記事の中心テーマです。
ERM 部門の脅威インテリジェンス・アナリストや脅威分析エンジニアは、以下のような最新情報を持っています。
- LLM 統合型の SOAR(Security Orchestration, Automation and Response、セキュリティ運用の自動化基盤)が出力するアラート
- 外部のセキュリティベンダー企業から有償で購入している 脅威アラート情報(地政学情報、規制情報、サイバー攻撃情報など)
ところが、これらの情報が、経営管理部門の計算インフラ環境に流れていかないのです。
その結果、何が起きるか:
- いま事業 A では「○○リスクの確率が急に高まっている」というアラート情報が、経営管理部門のシステム上では認識されない
-
「予想最大損失額を差し引いた後の事業 A のリスク考慮後利益率」のリアルタイム算出された最新の数値を算出することができない
- 各事業の事業価値や、その合計としての 企業価値をリアルタイム評価することは困難
そして、経営会議の場では、こんなやり取りが起きます。
-
リスク管理担当役員（CRO）:「○○リスクが高まっています。有効な対策を講じるためには、5千万円の費用が必要です」
- 経営者（CEO）・最高執行執行者（COO）:「ちょっと待って。費用対効果で、5千万円を投じると、うちの事業のリスク考慮後の利益率は何 % 改善して、金額では何億円プラスに増えるの? それが分からないと、5千万円が割に合う金額なのか、即断できないよ……」
判断が止まります。
問題の根本 ── 部門間のデータパイプラインがつながっていない
問題の根本は、ERM 部門と経営管理部門(欧米企業では FP&A という専門職部門。詳細は後述)との間で、データの断絶が起きていることです。
この断絶は、欧米大企業でも認識・指摘されています。ところが、「断絶」を解消し、ERM ⇔ 経営管理(FP&A)の間でデータが一気通貫に流れる統合パイプラインを構築できている企業は、まだ世界全体でもごく少数のようです。
なぜ欧米大企業でも、ERM × FP&A 統合は実現していないのか
本題に入る前に、用語を整理します。
FP&A (Financial Planning & Analysis、財務計画分析) は、欧米企業の経営管理部門の専門職機能です。
日本企業の「経営企画部」「経理部の予算管理機能」「管理会計部」などに相当する役割を、欧米では FP&A という独立した専門職として位置付けています。
担当者は、各事業の予算編成、業績予測、投資判断の財務分析、経営会議向けのダッシュボード作成などを担います。
本題に入ります。
「ERM部門と FP&A部門のデータパイプラインがつながっていない」 ── この現象は、多くの欧米大企業でも 認識されています。
コンサルティングファーム、テクノロジーベンダー、規制当局、学術研究のすべてが、この問題を指摘しています。
それにもかかわらず、なぜ統合が進まないのか。
公開情報の網羅調査から、5つの構造的な根本原因 が見えてきます。
構造要因１: 組織論 ── CRO と CFO のレポートライン分離
最大の障壁は、組織のガバナンス構造そのものです。
リスク管理機能は、利益相反を避けるため、リスクテイク決定を行う部門(事業部、財務部門)から独立していることが、コーポレートガバナンスの基本原則です。
実際、リスク機能を CFO 傘下に置くことは「金融サービスでよくある誤り」だと指摘されています(Governance and Organizational Positioning of Effective Risk Management Functions)。
CRO(Chief Risk Officer、リスク管理担当役員)は、CEO または取締役会に直接レポートするのが理想とされています。
ところが、この 「独立」が「分断」に転化 している企業が、世界的に多数派です。
- Wipro による BFSI(銀行・金融・保険)業界調査では、業界の多数派で「CFO と CRO は独立であるほど良い」という伝統的信念が根強く、両機能が サイロで運用されている ことが報告されています(Bridging the CFO-CRO divide, Wipro)。
- Economist Impact の金融機関調査では、「両機能が緊密に協働できない最大障壁:主たる焦点の不一致 52%、文化的差異 43%」と報告されています(Transforming the CFO role in financial institutions, Economist Impact)。
- Heidrick & Struggles の幹部インタビューでは、CFO(慎重派)と CRO(リスクテイク志向)の不信感が、「来年度オペレーティングプランの共同作成すら困難」というレベルにまで発展した事例が報告されています(CROs and CFOs: Optimize their relationship, Heidrick & Struggles)。
つまり、ガバナンス上の「独立性」を維持しつつ、運用上の「協働」を実現する ── このバランスが、欧米大企業でも未解決の組織課題として残り続けています。
構造要因２: システム分離 ── GRC 系 と FP&A 系 のデータモデル非互換
組織が分かれているということは、使うシステムも分かれているということです。
リスク管理側は、GRCプラットフォーム を使います。
GRC は、Governance(ガバナンス)、Risk(リスク管理)、Compliance(法令遵守) の頭文字で、これら 3つの領域を統合的に管理するシステム群を指します。
代表的な製品は MetricStream、RSA Archer、ServiceNow GRC、IBM OpenPages、LogicGate などです。
経営管理側は、FP&A プラットフォーム を使います ── Anaplan、Oracle Hyperion、OneStream、Vena、Workday Adaptive Planning などです。
これらは、別々のベンダー、別々のデータモデル、別々のタクソノミー(分類体系)で構築されています。
両者を統合した実装例は、公開情報では極めて限定的です。
データの非互換は、実証データでも裏付けられています。
- Economist Impact の金融機関調査では、「リスク情報を財務・パフォーマンス管理に組み込むことの障壁 TOP 3:システム統合の不備 41%、指標の不整合 37%、情報サイロ 28%」と報告されています(Economist Impact)。
- 銀行業界の ERM ベンダー Arya AI の調査では、「銀行はレガシーシステムへの依存度が高く、現代の ERM ツールとの互換性に欠ける。データサイロが、シームレスなリスク関連情報の流れを阻害している」と指摘されています(What is Enterprise Risk Management for Banks?, Arya AI)。
- GRC ツール最大手の MetricStream 自身が、「GRC 領域内ですら『機能サイロ』が残り、リスク・コンプライアンス・監査が別々の部署で別タクソノミーで運用されている」と認めています(The Case for an Integrated Approach to GRC, MetricStream)。さらに、Gartner のユーザーレビューでは、「カスタム統合は時間とリソースを大量消費する」「データ統合の問題が能力を阻害する」と報告されています(MetricStream Reviews, Gartner Peer Insights)。
GRC ツール内部ですらこの状況です。GRC と FP&A という 完全に別系統の製品群 を接続することの困難は、推して知るべしです。
構造要因３: KPI・評価制度・文化 ── 評価の非対称性
組織とシステムが分かれているだけでなく、KPI と評価制度 も分かれています。
FP&A 部門の評価は明快です ── 予算達成率、売上予測精度、利益率予測精度。数値で測れます。
一方、ERM 部門の評価は本質的に難しい構造を持っています ── 「事故を防いだ」実績は、起きなかったことなので測定できない。リスク管理担当者の貢献を、財務的に定量化することは原理的に困難です。
この評価の非対称性は、行動に直接影響します。
ScienceDirect に掲載された 269 名の金融プロフェッショナルを対象とした実証研究では、以下の数値が報告されています(Incentives and Culture in Risk Compliance, Journal of Banking & Finance):
- 可変報酬(利益連動)と比較して、固定報酬はリスクコンプライアンス遵守率を 25.1 ポイント向上させた
- profit-focused 文化と比較して、risk-focused 文化はリスクコンプライアンス遵守率を 16.3 ポイント向上させた
つまり、利益連動報酬と利益志向文化は、リスクコンプライアンスを 構造的に阻害する ことが、実験的に証明されています。
そして FSB(Financial Stability Board、金融安定理事会)のリスク文化評価フレームワークは、「risk-aligned incentives(リスク整合的なインセンティブ)」を組織のリスク文化の中核次元として位置付け ています(A Framework for Assessing Risk Culture, FSB)。
リスクと利益のバランスを取った報酬体系の設計が、欧米でもまだ発展途上の課題であることを意味します。
構造要因４: 現状の限界 ── FP&A側のデータドリブン化障壁
FP&A 部門が「リスク情報を取り込もう」と考えても、足元の足腰がまだ十分ではない、というのが実態です。
- 2024 FP&A Trends Survey(世界 2,400 名の財務プロフェッショナル調査)では、「データドリブン意思決定の障壁 TOP:適切な分析ツールの不足 53%、データドリブン文化の欠如 32%、スキル不足 11%」 と報告されています。同調査では、FP&A プロフェッショナルが高付加価値タスク(洞察生成)に費やせる時間は、わずか 35% にすぎません。残り 65% は、データ収集と検証に費やされています(2024 FP&A Trends Survey)。
- Deloitte Finance Trends 2026(1,326 名のグローバル財務リーダー調査)では、早期 AI 導入企業の 41% が「レガシー技術が AI 導入の障壁」 と回答しています(Finance Trends 2026, Deloitte)。
- McKinsey 2024 調査では、CFO の 62% が「デジタル財務ツールへの投資資源が不足している」 と報告しています。
FP&A 部門は、リスク統合以前に、まず 自部門のデータ基盤の刷新 という課題に直面しているわけです。
構造要因５: 統合事例の対比 ── ウクライナ侵攻前にカナダ調達契約を結んだ食品会社
ここまでは、なぜ統合が進まないかの構造的原因です。
他方で、少数派ながら、統合に成功している企業 も存在します。
その対比を見ることで、本連載が目指す姿が具体的に浮かび上がります。
Riskonnectが公開した2021年の事例では、米国の食品会社で ERM 部門と事業継続(BCP)部門の合同ワークショップ が開催されました。
地政学リスクのレビューの中で、「主要食材の一つがウクライナから調達されている」という事実が、ERM と事業継続の双方の文脈で同時に評価され、結果として カナダのサプライヤーとの代替契約が締結された ── すべて、2022 年 2 月のロシアによるウクライナ侵攻の 前 に(From Silos to Synergy, Riskonnect)。
この事例の重要性は、「ERM 部門が把握していた地政学リスク情報」が、「事業継続部門の調達・契約判断」にデータとして橋渡しされた という構造にあります。
データパイプラインの統合がなければ、リスク情報は ERM 部門のレポートの中で完結し、調達判断には到達しません。
では、統合に失敗した実例ではどうなるか ── 公開された 3 つの代表事例
統合に成功した Riskonnect の食品会社事例の対比として、ERM 部門が既にリスクを認識していたにもかかわらず、経営判断側で時間内に対応されなかった結果、巨額の実損害を被った事例 を見てみます。すべて、上場企業の公開済み案件です。
事例 1: Equifax 2017 ── 既知脆弱性のパッチが 2 か月間未適用
米国の信用情報大手 Equifax が 2017 年に起こした大規模情報流出事件は、「ERM レベルで既知のリスクが、経営判断・実装判断に橋渡しされない」 という構造を、最も明確に示した事例です。
事の発端は、2017 年 5 月、攻撃者が Apache Struts という広く使われたオープンソース・ウェブアプリケーション・フレームワークの 既知の脆弱性 を悪用したことでした。この脆弱性は数か月前に公表され、セキュリティパッチも提供されていました が、ある重要システムには適用されないまま放置されていました(Collaboris による事例分析)。
Equifax の社内では、セキュリティチーム(ERM 機能の一部)はこの脆弱性情報を把握していました。しかし、「パッチ適用を急ぐべき経済的根拠」が経営判断レベルに財務影響評価とともに連携されなかった ── これが、5 月から 7 月 29 日の発見までの 2 か月間、攻撃者が侵入し続けた 構造的原因です(Bank Info Security による報道)。
最終的な被害は以下の通りです。
| 項目 | 金額・規模 |
|---|---|
| 影響を受けた個人 | 約 1 億 4,700 万人 |
| FTC・CFPB・州司法長官との和解 | $5 億 7,500 万 |
| 消費者補償基金 | $3 億 8,050 万($1 億 2,500 万追加可能性) |
| セキュリティ投資義務(5 年) | $10 億 |
| 累計対応コスト(2019 年時点) | $13 億 8,000 万 〜 $14 億 |
| 株価下落(発表後 1 週間) | -35% |
| 経営陣の引責辞任 | CEO Richard Smith、CIO David Webb、CSO Susan Mauldin |
| Moody's 格付け影響 | 2019 年 6 月に引き下げ(CSO Online による報道) |
Collaboris の事例分析が端的に総括しています ── 「a known patch existed, a critical update was missed, and 'later' became a two-month undetected intrusion」。既知のパッチが存在し、重要なアップデートが見逃され、「あとで」が 2 か月間の侵入未検知 になった、という構造です。
事例 2: Boeing 737 MAX 2018–2024 ── 取締役会が 5 か月間、機体停止を議論せず
航空機メーカー Boeing が 737 MAX 機種で起こした 2 件の墜落事故は、「エンジニアリング部門のリスク認識」と「取締役会レベルの経営判断」の間の時間遅延 が、人命と企業価値の両方に致命的な損害をもたらした事例です。
時系列は以下の通りです(CPA Journal による事例分析)。
- 2018 年 10 月 29 日:Lion Air Flight 610 墜落、189 名死亡。MCAS(操縦特性増強システム)の問題がエンジニアリング部門で認識される
- 2018 年 11 月〜 2019 年 3 月:Boeing 取締役会は、安全上の懸念を理由とした機体停止について、5 か月間一度も議論しなかった
- 2019 年 3 月 10 日:Ethiopian Airlines Flight 302 墜落、157 名死亡。合計 346 名死亡
- 2019 年 3 月 13 日:FAA が 737 MAX を全面飛行停止
この事例の本質は、Lion Air 墜落の 2018 年 10 月から Ethiopian Airlines 墜落の 2019 年 3 月までの 5 か月間、ERM レベルのリスク認識(MCAS の異常挙動)が、取締役会の経営判断レジスタに「機体停止すべきかどうか」の議論として上がらなかった ことです。
最終的な財務影響は、本連載が扱うすべての事例の中で最大級です(Wikipedia: Financial impact of the Boeing 737 MAX groundings)。
| 項目 | 金額・規模 |
|---|---|
| 米司法省との詐欺罪和解(2021 年 1 月) | $25 億 |
| 航空会社への補償(運休損失) | $17 億 7,000 万 |
| 遺族基金 | $5 億 |
| 生産停止・再開コスト | $40 億 |
| 株価下落(2019 年 3 月) | 約 -18%、時価総額 -$400 億 |
| 株主代表訴訟 | 2021 年 9 月、取締役会の動議却下 |
| 受注キャンセル(Garuda Indonesia 1 社のみで) | $49 億 |
| Boeing が借り入れた負債(2020 年) | $140 億 + $250 億追加 |
| 信用格付け(Fitch) | A → A− に引き下げ(2020 年 1 月) |
| 当時の未受注残高(影響を受けた) | $6,000 億相当(4,636 機) |
Boeing 取締役会に対する株主代表訴訟(Harvard Corporate Governance による分析)では、原告は 「取締役会は、安全リスクを監視する義務を果たしていなかった」「最初の墜落後、既知の安全リスクへの対応を怠った」 と主張しました。これは、本連載のテーマである 「ERM 部門のリスク情報が、経営判断レジスタに統合されていなかった」 ことに対する、米国会社法上の責任追及です。
事例 3: Samsung ChatGPT 機密漏えい 2023 ── 通達の 20 日後に 3 件の漏えい
サイバーセキュリティや航空機ほどの巨額損失ではありませんが、「ERM 部門の認識(社内通達)が、現場の判断に橋渡しされない」 という構造を、AI 固有リスクの文脈で示した重要事例です。
2023 年、Samsung 半導体部門で 20 日間に 3 件の ChatGPT 機密漏えい が発生しました(Cyber Security Hub による報道)。
| 件 | 漏えい内容 |
|---|---|
| 1 件目 | エンジニアがバグ解決のため、半導体測定データベース・ダウンロードプログラムのソースコードを ChatGPT に投入 |
| 2 件目 | エンジニアが製造設備の欠陥判定プログラムを最適化するため、ソースコードを ChatGPT に投入 |
| 3 件目 | エンジニアが社内会議の録音を音声認識で文字起こしし、議事録作成のため ChatGPT に投入 |
注目すべきは、Samsung は 事前に「機密情報を ChatGPT に投入するな」という社内通達を出していた (HumanFirewall による事例分析)という点です。つまり、ERM 文化レベルでは AI 固有リスクは認識されていました。にもかかわらず、この認識が現場のエンジニアの日常判断(「ChatGPT に何を入力すべきでないか」)に、機械的な統制として橋渡しされていなかった のです。
結果として、OpenAI の利用規約上、一度入力されたデータは 取り消し不可能。Samsung は事後、社員ごとの ChatGPT データ投入量上限の設定、社内研修強化、最終的には全社 ChatGPT 利用停止に至りました。失われた情報の競争上の損害は、現時点では正確に定量化できていません。
3 事例の共通構造
| 事例 | ERM 側の認識 | 連携失敗の期間 | 連携失敗が経営判断に届かなかった結果 |
|---|---|---|---|
| Equifax | 既知の Apache Struts 脆弱性 | 2 か月間 | $13.8 億の被害、1 億 4,700 万人の情報流出、CEO/CIO/CSO 辞任 |
| Boeing 737 MAX | MCAS の異常挙動(Lion Air 墜落後) | 5 か月間 | 346 名死亡、$200 億+の累計コスト、株主代表訴訟 |
| Samsung | AI 固有リスクの社内通達 | 20 日間 | 競争優位性のある機密ソースコード流出、全社 ChatGPT 禁止 |
3 つの事例に共通するのは、ERM 部門・セキュリティ部門・エンジニアリング部門のいずれかが、リスクを「事前に認識していた」 という事実です。にもかかわらず、その認識が 経営判断レジスタ(取締役会の議論、財務影響評価、現場の機械的統制)に時間内に到達しなかった ── これが、3 件すべてに通底する構造的欠陥です。
これらの事例は、本連載が構築する ERM × FP&A 統合 BI パイプライン が、抽象的な技術的好奇心ではなく、$10 億単位の経営損失を未然に防ぐ実用的インフラ であることを、公開済みの実例で裏付けるものです。
5つの構造要因を統合すると見えてくる問題の所在場所
5つの構造要因を統合すると、ERM × FP&A 統合が実現していない理由は、単一の原因ではなく、組織・システム・指標・評価・文化・現状の足腰 の 6つの領域にわたる 構造的な分断 であることが分かります。
| 領域 | 分断の内容 | 出典(代表例) |
|---|---|---|
| 組織 | CRO vs CFO のレポートライン分離、文化的差異 43% | Wipro、Economist Impact、Heidrick & Struggles |
| システム | GRC 系(MetricStream 等) vs FP&A 系(Anaplan 等)のデータモデル非互換 | Economist Impact(41%)、Arya AI、MetricStream 自身 |
| 指標 | リスク KPI と財務 KPI の不整合 37% | Economist Impact |
| 評価 | 「事故を防いだ」を測定できない構造、利益連動報酬がリスクコンプライアンスを 25.1 ポイント低下させる | ScienceDirect、FSB |
| 文化 | profit-focused vs risk-focused のリスクコンプライアンス遵守率に 16.3 ポイントの差 | ScienceDirect |
| システム＆データ基盤 | FP&A の高付加価値タスク時間 35%、CFO の 62% が投資資源不足 | FP&A Trends Survey、McKinsey |
これだけ多層的な分断が、欧米大企業の中で同居しています。
だからこそ、統合に成功している企業はごく少数 なのです。
本連載のパイプラインは、これらの壁をどう突破するか
ここで、本連載が実装する ERM × FP&A 統合 BI パイプライン が、上記の6つの領域の分断をどう突破するのか、具体的に整理します。
突破口1: RAROC・SAROICなどの『リスク考慮後の経営評価指標』の採用により、CRO と CFO が同じ指標で会話できる
組織が分かれていても、同じ指標で会話できれば、議論は噛み合います。
実は、銀行業界では、すでに CRO と CFO が共通指標で会話する仕組み が、業界標準として存在します。それが RAROC(Risk-Adjusted Return On Capital、リスク調整後資本収益率) です。
$$
\text{RAROC} = \frac{\text{利益} - \text{期待損失}}{\text{経済資本}}
$$
RAROC は、
- 分子の「利益 − 期待損失」 で、FP&A が見ている「利益」に、ERM が見ている「リスク量(期待損失)」を織り込みます
- 分母の「経済資本」 で、リスク量を反映した必要資本に統一します
つまり $RAROC$は、「CRO がリスク量を提供し、CFO が利益と資本を提供し、両者が掛け合わさった一つの数値で経営判断する」という、構造的に CRO ⇄ CFO の協働を要求する指標です。
Bankers Trustが 1970 年代に開発して以来、銀行業界では半世紀にわたって使われ続けています。
本連載が提案する $SAROIC$ (Segment-level Adjusted Return On Invested Capital)は、$RAROC$ の思想を、事業セグメントレベルで、Return On Invested Capital (ROIC)をベースに、非金融業界の経営管理に持ち込んだものです。
$$
\text{SAROIC}_i = \frac{\text{NOPAT}_i - \text{EL}_i}{\text{投下資本}_i + \text{経済資本}_i}
$$
SAROIC を CRO と CFO の共通言語として使うと、こうなります。
- CRO の貢献:各事業セグメントの 期待損失(EL) と 経済資本 を、リスクモデルから供給する
- CFO の貢献:各事業セグメントの NOPAT(税引後営業利益) と 投下資本 を、財務システムから供給する
- 共通の議論の場:「SAROIC が WACC を上回っているかどうか」という、両者の貢献が一つの不等式で表現される判断基準
組織のレポートラインが分かれていても、会話の言語が一致していれば、経営会議は噛み合います。本連載は、SAROIC を実装可能なコードレベルまで落とし込むことで、この「共通言語の実装」を提供します。
SAROIC が経営判断を変える具体例 ── エタール重工株式会社のリスク対策投資
ここまで、SAROIC が CRO と CFO の共通言語として機能する構造を見てきました。
では、SAROIC を使うと、経営会議の議論はどう変わるのでしょうか。具体例で示します。
架空の総合重工メーカー「エタール重工株式会社」(造船・防衛・産業機械を含む、売上規模 8,000 億円)を考えます。同社は、半年前の時点で、以下のリスク対策に総額 5 億円 を投資していたとします。
-
サイバーセキュリティ強化(エンドポイント保護、SOC 24時間監視、ゼロトラスト・アーキテクチャ導入、防衛装備品設計データの厳格な分離管理):3 億円
-
地政学リスク専門ベンダーとの契約(早期警戒情報、各国規制動向のリアルタイム配信、ITAR・EAR・経済安全保障推進法の改正動向の追跡):1.5 億円
-
内部統制・コンプライアンス体制強化(輸出管理、防衛装備移転三原則対応、海外子会社ガバナンス、海事規制 SOLAS・MARPOL 対応):5 千万円
このとき、直近半年間のリスク発現時の 99.5% VaR (0.5% 以下の確率でしか発生しない最大損失額) は、対策実施前後で次のように変化します。
| 指標 | 対策前(Day 0 時点) | 対策後(Day 0 時点) | 差分 |
|---|---|---|---|
| 99.5% VaR(防衛・産業機械事業) | 120 億円 | 45 億円 | −75 億円 |
| 期待損失(EL) | 28 億円 | 9 億円 | −19 億円 |
| 経済資本(VaR − EL) | 92 億円 | 36 億円 | −56 億円 |
| 防衛・産業機械事業の NOPAT | 180 億円 | 180 億円 | 変化なし |
| 投下資本 | 800 億円 | 800 億円 | 変化なし |
| ROIC(リスク非考慮) | 22.5% | 22.5% | 変化なし |
| SAROIC(リスク考慮後) | (180 − 28) / (800 + 92) = 17.0% | (180 − 9) / (800 + 36) = 20.5% | +3.5 ポイント |
注目すべきは、$ROIC$ では何も変化していないように見えますが、$SAROIC$ では、$3.5$ポイントの上方修正が発生していることです。
これは、リスク変数を分子(期待損失)と分母(経済資本)の両方に織り込んでいるためです。
リスク対策の費用対効果を、SAROIC で定量評価する
ここで重要な問いは、「5 億円のリスク対策投資は割に合ったのか」 です。
$SAROIC$ の上方修正幅から、定量的に評価できます。
- リスク対策に要した支出額:5 億円(半年間の investment)
- $SAROIC$ の上方修正幅:+3.5 ポイント(投下資本 800 億円に対して)
- 投下資本ベースのリスク考慮後利益率上昇に相当する金額:+28 億円 / 年(800 億円 × 3.5%)
つまり、5 億円のリスク対策投資が、年間 28 億円のリスク考慮後利益率の上昇を生んだことになります。投資回収期間は、おおむね 2.3 ヶ月(5 億円 ÷ 28 億円 × 12 ヶ月)です。
経営会議の会話が変わる
本記事の冒頭で示した、SAROIC 導入前の経営会議の会話を思い出してください。
CRO:「○○リスクが高まっています。有効な対策を講じるためには、5 千万円の費用が必要です」
CEO:「ちょっと待って。費用対効果で、5 千万円を投じると、うちの事業のリスク考慮後の利益率は何 % 改善して、金額では何億円プラスに増えるの？ それが分からないと、5 千万円が割に合う金額なのか、即断できないよ……」
SAROIC を CRO と CFO の共通言語として導入すると、この会話は次のように変わります。
CRO:「半年前に投資した 5 億円のリスク対策が、年間 28 億円のリスク考慮後利益率の上昇を生んでいます。SAROIC で見れば、回収期間は約 2.3 ヶ月です」
CEO:「即決で承認だな。来期も同水準のリスク対策を継続しよう」
重要な含意 ── 「リスク対策は守りの投資ではない」
伝統的な経営思考では、「リスク対策は守りの投資」「費用対効果が定量化しにくい」「ROI に貢献しない」と考えられてきました。
しかし、ERM 部門のリスク情報を FP&A 部門の利益見通しに データパイプラインで自動接続 し、SAROIC を共通言語として使えば、リスク対策の費用対効果は明確に定量化できます。リスク対策は守りの投資ではなく、SAROIC を上方修正する攻めの投資であることが、データで証明されます。
本連載の後半では、上記の SAROIC・99.5% VaR・期待損失の計算ロジックを、実際のコードで実装します。読者の皆様が自社のリスク対策投資の評価を、自社の財務データで再現できる形で提示します。
突破口2: 『型安全』なパイプラインで、システム分離をまたいだ整合性を保証する
システムが分かれていることは、すぐには変えられません。
GRC ツール(MetricStream、Archer 等)と FP&A ツール(Anaplan、Hyperion 等)は、企業がすでに巨額投資した既存資産です。
本連載のアプローチは、「既存システムを置き換える」のではなく、「両者のあいだに、型安全なデータ統合層を挟む」 です。
- Python・Julia で、ETL(抽出・変換・ロード)と数値計算を実装
- Haskell・Idris の型システム で、ETL のデータ変換が 意味的に正しい ことを、型レベルで保証する
- Rust で、リアルタイムなリスク計算エンジンを実装
- Claude Code + MCP で、GRC・FP&A 両ツールに API 経由 で接続し、データを橋渡しする
ここで、Idris の依存型 が重要な役割を果たします。
例えば、GRC ツールから取得した「期待損失額」と、FP&A ツールから取得した「NOPAT」（税引後営業利益）を結合する SAROIC 計算では、両者の 通貨単位、対象期間、セグメント定義 が一致していなければなりません。
これらの整合性を、Idris の依存型でコンパイル時に保証 することができます。
Python の動的型付き言語で実装すると、本番環境で初めて単位ミスが発覚することがありますが、Idris では コードがビルドされた時点で、整合性条件が型レベルで検証済み です。
「システムが分かれていることが問題」ではなく、「システムをまたいだデータ統合が、検証されないまま使われていることが問題」 ── 本連載は、形式手法でこの検証を機械化します。
突破口3: Idris・Coq の形式手法で、「リスク顕在化による経済損失を未然に防いだことによる企業価値維持に対する貢献実績」を数学的に証明可能にする
ERM部門の評価が難しい根本理由は、「リスク顕在化による経済損失を未然に防いだことによる企業価値維持に対する貢献実績を、定量的に測定することは困難」 という構造でした。
本連載は、ここに 形式手法による新しいアプローチ を持ち込みます。
-
Coq の定理証明 で、「経営判断 $X$ を行えば、事業Aのリスク調整後利益率は閾値 $Y$ 以上である状態が維持可能である」という命題を、数学的に証明可能な形で表現する
- Idris の依存型 で、ビジネスルール(例:「投下資本は常に正の値」「期待損失は常に非負」)を、型レベルで強制する
これにより、ERM 部門の貢献は、「起きなかった事故の数」ではなく、「経営判断の論理的整合性を、Coq の定理として証明した数」「型レベルでビジネスルールを保証したコード行数」という、検証可能な成果物として可視化されます。
この主張が技術的・数学的に成り立つ根拠
「Coq で経営判断を数学的に証明する」「Idris の型でビジネスルールを強制する」── これらは、抽象的な構想ではなく、すでに産業界で実証された技術応用パターンです。
読者の皆様の中には、「本当に可能なのか？」と思われる方もいらっしゃるはずなので、技術的根拠を ２つの観点から整理します。
観点１: Idris の依存型でビジネスルールを型レベルで強制する
依存型は、「型に値の制約を組み込む」 仕組みです。
例えば「投下資本は常に正」というルールは、Idris では以下のように記述できます。
data PositiveAmount : Type where
MkPositive : (n : Double) -> So (n > 0.0) -> PositiveAmount
calculateSaroic :
(nopat : Double) ->
(el : NonNegativeAmount) ->
(investedCapital : PositiveAmount) ->
Double
この PositiveAmount 型は、「正の値であること」を型レベルで証明する付随情報(So (n > 0.0))を持たない限り、値を生成できません。
つまり、「投下資本がゼロまたは負の値」のデータが SAROIC 計算に渡されることは、コンパイラがビルド時に拒否します ── テストではなく、型システムによる強制です。
この依存型プログラミングのパラダイムは、Edwin Brady 氏の "Type-Driven Development with Idris"(Manning、2017)が標準的な実装ガイドとして確立されており、ビジネスルールの型レベル強制は 依存型の典型的な応用例 として、Idris 公式ドキュメントを含む多数の文献で実装例が公開されています。
観点２: Coq の定理証明で経営判断ロジックを数学的に検証する
ここで重要なのは、Coq で証明するのは 「現実の経済が将来どうなるか」ではなく、「判断ロジックが、与えられたモデルとパラメータ条件下で、所定の不変条件を保つかどうか」 という、論理的な命題 だという点です。
具体的には、Coq では以下のような定理を証明できます。
Theorem decision_preserves_saroic_threshold :
forall (state : BusinessState) (decision : Decision) (Y : R),
valid_state state ->
saroic state >= Y ->
apply_decision state decision = state' ->
saroic state' >= Y.
これは、「経営判断 $decision$ を、$SAROIC ≥ Y$ を満たす状態 $state$ に適用しても、適用後の状態 $state$ でも $SAROIC ≥ Y$ は保たれる」という不変条件の証明です。
Coq の Proof. セクションで代数的な変形を機械的に検証し、Qed. で証明完了が確定します。
経営判断は、数理論理学的に論理演算できるのか?
「経営判断を Coq で証明する」と聞くと、
「経営判断は人間の直感や経験、市場感覚で下されるもの。それを数式や論理で扱えるのか?」
という疑問が湧きます。
これは正当な疑問です。実際、Coq に「事業 A から撤退すべきか?」と聞いても答えは出ません。
ここで重要なのは、経営判断には 2 つの層 があるという区別です。
| 層 | 内容 | 数理論理学の射程内か |
|---|---|---|
| 層 1:意思決定の最終層 | 「投資するか/しないか」「事業 A を続けるか/撤退するか」── 人間の経営者が下す最終的判断 | × 射程外(直感・経験・市場感覚・倫理) |
| 層 2:判断を支えるロジック層 | 「SAROIC が WACC を上回るとき、その投資は経済価値を創出する」「投下資本は常に正である」── 判断の根拠となる規則 | ✅ 射程内(命題論理・述語論理で表現可能) |
Coq が機械的に検証するのは 層 2 だけ です。
しかし、層 2 が検証されることで、層 1 の人間の判断は「論理的整合性が保証された材料の上で」下せる ようになります。
具体例 ── 「SAROIC > WACC ならば経済価値を創出する」を論理演算する
最も分かりやすい例で説明します。コーポレートファイナンスの基本命題:
「SAROIC が WACC を上回るとき、その投資は経済価値を創出する」
これは、財務理論の教科書で当たり前のように書かれている経営判断の根拠ルールです。日本語で書かれていますが、数理論理学的には以下のように表現できます。
$$
\forall (SAROIC, WACC, \text{投下資本}) : \
\quad SAROIC > WACC ;\land; \text{投下資本} > 0 \
\quad \implies \text{経済価値創出量}(SAROIC, WACC, \text{投下資本}) > 0
$$
これは 全称量化された含意命題 です。「すべての SAROIC、WACC、投下資本の組み合わせについて、ある不等式が成り立てば、別の不等式も成り立つ」という構造で、述語論理の標準的な対象です。
Coq では、これを以下のように記述できます。
Require Import Reals.
Theorem saroic_exceeds_wacc_implies_value_creation :
forall (saroic wacc invested_capital : R),
invested_capital > 0 ->
saroic > wacc ->
(saroic - wacc) * invested_capital > 0.
Proof.
intros saroic wacc invested_capital H_ic_pos H_saroic_gt_wacc.
apply Rmult_gt_0_compat.
- apply Rgt_minus. exact H_saroic_gt_wacc.
- exact H_ic_pos.
Qed.
ここで Qed. が表示された瞬間、この命題は 数学的に証明完了 したことを意味します。これは、人間が「正しいだろう」と信じているのではなく、Coq の論理エンジンが機械的に検証した結論です。
何が証明されたのか、何は証明されていないのか
ここが核心です。Coq の Qed. で確定したのは、
- ✅ 「SAROIC > WACC ならば、(SAROIC − WACC)×投下資本 > 0 という不等式が成り立つ」という論理関係
確定していないのは、
- ❌ 「事業 A の将来の SAROIC が WACC を上回るかどうか」(これは現実の経済予測の問題)
- ❌ 「事業 A に投資すべきかどうか」(これは経営者の最終判断)
つまり、Coq は 「もし SAROIC が WACC を上回るならば、経済価値が創出される」という論理関係の正しさを保証する のであって、「事業 A の SAROIC が WACC を上回るか」を予測するのではない のです。
より複雑な経営判断ロジックの例
同じ構造で、もっと複雑な経営判断ロジックも論理演算できます。
例 1:複数事業の優先順位付け
$$
\forall (\text{事業 } i, \text{事業 } j) : \
\quad SAROIC_i > SAROIC_j ;\land; \text{経済資本}_i \leq \text{経済資本}_j \
\quad \implies \text{事業 } i \text{ は事業 } j \text{ より優先される}
$$
これは「リスク量が同等以下で、リスク調整後利益率が高い事業は、優先される」という、ポートフォリオ最適化の基本ルールです。Coq で証明可能です。
例 2:リスク許容度の不変条件
$$
\forall (\text{時点 } t, \text{事業ポートフォリオ } P) : \
\quad \sum_{i \in P} \text{経済資本}_i(t) \leq \text{利用可能自己資本}(t) \times \text{リスク許容度}
$$
これは「ポートフォリオ全体のリスク量は、自社の自己資本にリスク許容度を掛けた値を超えてはならない」という、ERM の根幹的な制約です。Coq で「この不変条件をすべての時点で保つような判断ロジック」を定式化し、検証できます。
例 3:IFRS 注記の論理的整合性
$$
\forall (\text{注記項目 } N) : \
\quad \text{N の前提条件} = \text{注記内で明示された前提} \
\quad \land; \text{N の結論} = \text{注記内で明示された結論} \
\quad \implies (\text{前提} \implies \text{結論}) \text{ が論理的に成立する}
$$
これは「注記に書かれた前提から、注記の結論が論理的に導かれることを機械的に検証する」という、IFRS 原則主義時代の財務開示への形式手法の応用です。
まとめ ── 経営判断は、論理演算で「下せない」が、論理演算で「支えられる」
| 主張 | 真偽 |
|---|---|
| 「経営判断のすべてを、Coq で機械的に決定できる」 | ❌ 偽 |
| 「経営判断を支えるロジック層を、Coq で機械的に検証できる」 | ✅ 真 |
| 「Coq の検証は、判断材料の論理的整合性を保証する」 | ✅ 真 |
| 「最終的な意思決定は、依然として人間が下す」 | ✅ 真 |
本連載が目指すのは、人間の経営者が下す最終判断を、論理的整合性が機械検証された材料の上で行えるようにする ことです。Coq は経営者の代わりに判断を下すのではなく、判断材料の正しさを保証する ── これが、形式手法の経営応用の本質です。
この種の「システムの不変条件をプログラムの実行を通じて保つ」という形式検証は、すでに以下の産業界で実用化されています。
| 産業 | 採用例 | 出典 |
|---|---|---|
| 証券取引所 | Tata Institute of Fundamental Research (TIFR) が、マッチングアルゴリズムの規制要件(fair、uniform、individual rational)を Coq で機械的に証明 | arXiv 1907.07885, 2019 |
| 航空機 | Airbus の CompCert(検証済み C コンパイラ)が、「コンパイル後のコードが元のコードと意味的に等価」を Coq で証明 ── PLDI '11 論文では「Csmith ファザーが 6 CPU 年かけても CompCert ではバグを発見できなかった」と報告 | ACM Computing Surveys |
| ブラウザ・暗号 | Google Chrome に搭載されている fiat-crypto(Coq で機械検証された暗号ライブラリコード) | Coq 公式 Industry 採用 |
| ブロックチェーン | Tezos・Zilliqa のスマートコントラクト言語の形式仕様、プロトコル安全性の数学的証明 | Coq 公式 Industry 採用 |
特に TIFR の証券取引所マッチングアルゴリズムの形式検証 は、金融業界の規制要件を Coq の定理として証明した先行事例 であり、本連載が経営判断ロジックを Coq で検証するアプローチの、直接的な前例 です。
つまり、本連載が取り組むのは、
- 航空機制御で実証されたコンパイラ検証パターン
- 暗号ライブラリで実証された安全性証明パターン
- ブロックチェーンで実証されたスマートコントラクト検証パターン
- 証券取引所で実証された規制要件証明パターン
これらの 産業界で確立された形式検証パターン を、ERM × FP&A 統合パイプライン という新しい領域に応用する試みです。
「数学的に可能か」という問いに対しては、上記の産業界における実証実績がその答え です。
これは、IFRS 原則主義時代の財務開示が要求する「経営判断の論理的整合性の説明責任」とも、直接結びつきます。CRO の貢献が、財務注記の中で、定理証明の形で開示される ── そういう時代の到来を、本連載は技術的に先取りします。
突破口４: Claude Code + MCP で、リアルタイムにリスク・財務を統合する
最後に、FP&A 部門の足腰の問題 ── 「データ収集と検証に 65% の時間を費やしている」 ── を、技術で解決します。
Claude Code + MCP(Model Context Protocol、Anthropic が提唱する AI ツール接続規格)は、AI が外部ツールと直接対話する仕組みです。本連載では、3 つの MCP を使います。
- GitHub MCP:リスクレジスタを Git で管理し、変更履歴を完全追跡可能にする
- Postgres MCP:統合データウェアハウスから、SQL で直接データを引き出す
- Tableau MCP:経営ダッシュボードを、Claude Code に指示して自動生成する
これらにより、FP&A プロフェッショナルの作業時間の構造が変わります。
- Before:データ収集 65% + 洞察生成 35%
- After:Claude Code + MCP がデータ収集の大部分を自動化、人間は洞察生成に集中
つまり、人間が高付加価値タスクに集中できる時間構造 を、技術で実現するわけです。
4 つの突破口を統合した、本連載のメッセージ
| 分断の領域 | 本連載の突破口 |
|---|---|
| 組織 | RAROC・SAROIC という共通指標で、CRO と CFO が同じ KPI で会話できる |
| システム | 型安全パイプラインで、GRC ⇄ FP&A のあいだに検証層を挟む |
| 指標 | SAROIC を実装可能なコードレベルで提供し、社内標準化を加速する |
| 評価 | Coq 定理証明で、ERM の貢献を「論理的整合性の証明数」として可視化する |
| 文化 | 「利益 vs リスク」の二項対立ではなく、「リスクを織り込んだ利益最大化」という統合的視点を、コードで表現する |
| 足腰 | Claude Code + MCP で、データ収集を自動化し、人間は洞察生成に集中する |
本連載は、欧米大企業ですら未解決のこの構造的分断に対して、8 言語のコード + 形式手法 + Claude Code + MCP という具体的な技術スタックで応える、実装ガイドです。
本連載で実装するもの
本連載記事は、上記の データ断絶を解消する BI パイプライン を、
- Python & Julia(数値計算と高速統計処理)
- Haskell & Idris(関数型と依存型による論理的厳密性の保証)
- Coq(形式証明による経営判断の数学的正当性の証明)
- C/C++ & Rust(高並列・低レイテンシのリスク計算エンジン)
の8言語を、Claude Code + MCP(Model Context Protocol、Anthropic 提唱の AI ツール接続規格)で、コード実装するハンズオン記事です。
読みやすいように、2人のキャラクター(50代の女性アドバイザー高野さん、30代の男性 BI エンジニア佐藤さん)に登場してもらい、対話形式で解説していきます。
本連載の後半では、TypeScript / React 19 で、リアルタイム経営ダッシュボードを構築します。
本連載が一貫して掲げているのは、「経営判断の 90 日遅延を、データパイプラインの再構築で縮める」ことです。
この方針は、フロントエンドの実装レベルでも貫かれます。
第２回以降の記事では、React のフロントエンド実装について、Functional Reactive Programming(FRP)の思想を継承した 2026 年 5 月現在の最新実装スタイル ── Signals ベースの fine-grained reactivity ── を採用します。
これは Solid.js・Svelte 5・Angular 16+ が既に採用し、TC39 で言語仕様としての標準化が提案されている技術であり、React にも Preact Signals 経由で統合できます。
経営層が向き合う KPI ダッシュボードやリスクマップは、データ量が多く、状態の更新も頻繁です。
従来の React(Virtual DOM 全体の再レンダリング)では、状態の変化のたびにコンポーネントツリー全体の差分計算が走り、操作レイテンシが累積します。技術的な遅延が、経営判断の遅延を再生産する構造になっています。
Signals ベースの実装は、変わった値に依存する DOM ノードだけを更新します。連載全体を貫く「経営レイテンシを縮める」というテーマと、フロントエンドの実装レベルで完全に整合します。
第２回以降の記事で、その具体的な実装手順を提示します。
すべてのコードは、本記事連載終了時までに、本記事執筆者の GitHub に公開予定です。git clone して、皆様の手元で動かしていただける形で公開します。
https://github.com/EtaleCohomology
本連載で扱う事業危機シナリオ ── ケーススタディ先行紹介
本連載記事では、この統合パイプラインを持っている企業と、持っていない企業(今日の企業の大半がこちら側)との間で、リアリティのある事業危機シナリオの中で、対応がどのように分かれるのかを、ケーススタディ形式で見ていきます。
ケーススタディは、以下のラインナップを掲載予定です。
ケーススタディのラインナップ
| # | 事業危機シナリオ | 業界 | 顕在化するリスクの種類 | 統合パイプラインがある企業 vs ない企業 |
|---|---|---|---|---|
| 1 | 中国向け輸出事業の規制急変 | 製造業(精密機械) | 地政学リスク、規制リスク、カントリーリスク | 翌営業日には影響額を経営会議で議論 vs 90日後の四半期決算で判明 |
| 2 | LLM 経由の機密情報流出疑惑 | IT・SaaS | AI 固有リスク、レピュテーションリスク、訴訟リスク | アラート受信から3時間で訴訟引当金を再計算 vs 翌月の月次締めまで放置 |
| 3 | 新薬の承認遅延 | 医薬品 | 規制リスク、開発遅延リスク | 規制当局からの予兆段階で投資配分を再評価 vs 公式発表後に株価が暴落してから対応 |
| 4 | 物流ネットワークへのサイバー攻撃 | 小売・流通 | サイバーリスク、サプライチェーンリスク | 攻撃検知と同時に代替ルートと費用対効果を経営判断 vs 出荷停止が広範化してから対策会議 |
| 5 | 為替・地政学変動による外貨建て与信の急激な信用悪化 | 銀行・金融 | 為替リスク、信用リスク、カントリーリスク | リアルタイムで貸倒引当金と自己資本比率を更新 vs 月次バッチ処理で翌月認識 |
| 6 | Tech 系ベンチャーの規制対応コンプライアンス | スタートアップ | 規制リスク、法務リスク、起業家リスク | 規制改正の予兆段階で事業モデルとランウェイを再評価 vs VC への次回ピッチで質問されて慌てる |
関連する既存記事
ケーススタディの読み方
各ケーススタディでは、以下の構造で対比的に解説します。
-
Before(統合パイプラインを持たない企業の典型的対応):
アラートはあるが、財務判断に接続されない。経営会議でデータが揃わず、判断が90日遅れる
-
After(統合パイプラインを持つ企業の対応):
アラートが財務指標に自動反映され、経営会議で「リスクを織り込んだ判断」が即座に行える
-
実装のポイント:
Before から After への移行に必要なデータパイプライン設計、コード実装の勘所
-
コード抜粋:
該当ケーススタディに関連する Python / Idris / Coq / Rust のコード片(本記事で公開)
特に 後続の記事(Tech 系ベンチャーの規制対応) は、皆様自身が経営されている、または、皆様が将来、起業される会社の経営判断にも直接活かせる内容として、力を入れて執筆します。
それでは、まず本連載の中心となる 8言語のコードを、お見せします。
同一指標(SAROIC)の実装コード比較：8つのプログラミング言語
SAROIC とは何か ── 略語と意味(本連載シリーズ記事で筆者が提案する新指標)
$SAROIC$ は、リスク調整後 $ROIC$ を、実務での運用を意識して単純化した指標 として、本連載で導入するものです。
略語は以下の英単語の頭文字を取ったものです。
SAROIC = Segment-level Adjusted Return On Invested Capital
(セグメント別・リスク調整後・投下資本利益率)
各単語の意味を、エンジニアの言葉で分解します。
| 単語 | エンジニアにわかる言葉での説明 |
|---|---|
| Segment-level |
「セグメント別の」。会社全体ではなく、事業セグメント(事業部門、商品ライン、地域別など)ごとに別々に計算する、ということ。データ用語で言えば GROUP BY segment_id のイメージ |
| Adjusted | 「リスクを織り込んで調整した」。利益額からリスク量(期待損失額)を差し引き、分母にもリスク量(経済資本)を足して、リスクの大きさを反映させた値、ということ |
| Return On Invested Capital(ROIC)(経営管理で使われている既存の指標) |
「投下資本利益率」。一般的な財務指標。利益 / 投下資本 の式で計算される。「投じたお金に対して、どれくらい利益を生んだか」を測る、業界標準の収益性指標 |
つまり SAROIC は、
「事業セグメント別に、リスクを織り込んで調整した投下資本利益率」
を意味します。
SAROIC の計算式(本連載シリーズ記事で筆者が提案する新指標)
セグメント i の SAROIC は、次の式で計算します。
$$
\text{SAROIC}_i = \frac{\text{NOPAT}_i - \text{EL}_i}{\text{投下資本}_i + \text{経済資本}_i}
$$
数式の構造を視覚的に理解する
数式の構造を言葉で要約すると、以下のようになります。
-
分子(numerator):利益からリスク量(期待損失)を 引く
-
分母(denominator):投下資本にリスク量(経済資本。 Economic Capital)を 足す
- 両側でリスクを織り込むことで、ROIC(リスク非考慮)から SAROIC(リスク考慮後)へと進化する
経済資本とは？
経済資本(Economic Capital)とは、認識されているリスクが顕在化して事業に経済的損害が発生したときに備えて、自己資本(Equity)の一部 を、各事業のリスク量に応じて事業に割り当てる(配賦する)**という、企業内部のリスク管理・経営管理上の概念です。
「経済資本」は、「会計上の負債(引当金など)とは異なる概念」である点 に注意が必要です(出典:BIS Basel Committee on Banking Supervision (2009) "Range of practices and issues in economic capital frameworks")。
具体的には、BIS の定義によれば、経済資本は 「保有する資本の額ではなく、リスクの尺度」 であり、会計上の引当金や規制資本とは性質が異なります。
なぜ「自己資本」から配賦するのか
銀行借入や社債の発行で調達した資金は 返済義務のある負債 ですが、自己資本(資本金、資本剰余金、利益剰余金などの合計)は 返済義務のない、自社が自由に使える資金 です。
万が一、認識していたリスクが顕在化して大きな損失が発生した場合、最終的にその損失を吸収するのは自己資本(株主資本)です。
そのため、企業は将来発生しうる被害想定額(統計的に算出した予想最大損失額)に応じて、自己資本のうちどれだけを各事業に「リスクバッファ」として割り当てるかを内部管理として計算します。
これが経済資本の配賦(はいふ。Capital Allocation)です。
会計上の「引当金」との違い
会計上の 引当金(IFRS で言う provisions、IAS 第37号)は、過去の事象の結果として現在の債務(法的または推定的)を有しており、信頼性のある見積りができる場合に、財務諸表の負債側に計上するものです(出典:EY Japan 引当金 第1回:引当金総論)。
一方、経済資本は 将来の不確実な損失リスクに対する内部管理上の自己資本配賦 であって、財務諸表の負債側に計上されるものではありません。両者は別物です。
（参考）経済資本出典
本図の解説内容(経済資本は会計上の勘定科目ではなく、内部リスク管理上の概念であること)は、以下の権威ある一次・二次資料に基づきます。
一次資料(規制当局・国際機関)
-
BIS Basel Committee on Banking Supervision (2009)
Range of practices and issues in economic capital frameworks
→ 経済資本の定義「Economic capital is a measure of risk, not of capital held. As such, it is distinct from familiar accounting and regulatory capital measures.」(経済資本は保有資本ではなくリスクの尺度であり、会計資本・規制資本とは異なる)を明記
https://www.bis.org/publ/bcbs152.pdf
-
FDIC (Federal Deposit Insurance Corporation, U.S.)
Economic Capital and the Assessment of Capital Adequacy (Supervisory Insights)
→ 米国の銀行監督当局による経済資本の概念解説
https://www.fdic.gov/regulations/examinations/supervisory/insights/siwin04/siwinter04-article1.pdf
-
Solvency II Directive 2009/138/EC, Article 101(欧州保険会社の規制)
Solvency Capital Requirement
→ 「The Solvency Capital Requirement should be determined as the economic capital to be held by insurance and reinsurance undertakings...」(99.5% VaR を1年ホライズンで算出)
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0138
二次資料(専門家団体・学術)
-
Society of Actuaries (SOA, 米国アクチュアリー会) (2016)
Economic Capital for Life Insurance Companies
→ 経済資本と規制資本の違いを実務家視点で詳説
https://www.soa.org/globalassets/assets/files/research/projects/research-2016-economic-capital-life-insurance-report.pdf
-
GARP (Global Association of Risk Professionals) (2022)
Economic Capital: The Power of Diversification by Marco Folpmers (FRM, Deloitte Netherlands)
→ 「Economic capital does a better job of capturing risk/reward information than regulatory capital」(経済資本は規制資本よりリスク・リターン情報をよく捉える)
https://www.garp.org/risk-intelligence/credit/economic-capital-diversification-220812
-
The Journal of Risk Finance (Emerald Publishing, 2018)
Strategic risk, banks, and Basel III: estimating economic capital requirements
→ 経済資本が「mandatory capital buffer ではない」(義務的資本バッファーではない)ことを学術的に確認
https://www.emerald.com/jrf/article/19/3/225/247501/Strategic-risk-banks-and-Basel-III-estimating
会計基準上の引当金(経済資本との対比)
-
EY Japan「引当金 第1回:引当金総論」
→ IAS 第37号「引当金、偶発負債及び偶発資産」と日本基準の引当金の違いを解説
https://www.ey.com/ja_jp/technical/corporate-accounting/commentary/reserve/commentary-reserve-2017-08-10
-
PwC Japan「IFRSを開示で読み解く(第10回)引当金に関する開示」
→ 日本基準と IFRS における引当金開示の差異
https://www.pwc.com/jp/ja/knowledge/ifrs/disclosure/ifrs-disclosure010.html
一般読者向け参考(概念的な入口として)
-
Wikipedia "Economic capital" (2025年5月更新版)
→ 経済資本と規制資本の違いを概観できる
https://en.wikipedia.org/wiki/Economic_capital
業界別の規制要求
銀行・証券会社・保険会社は、それぞれの業界規制(国際的には Basel III / Basel IV(バーゼル規制)(銀行)、EU CRR III(2025 年 1 月施行、EU 域内の Basel III/IV 実装)、英国 Basel 3.1(2027 年 1 月施行予定)、Solvency II(欧州の保険)、米国の Risk-Based Capital(保険);日本国内では銀行法、金融商品取引法、保険業法)に基づき、規制資本(Regulatory Capital) の保有が義務付けられています。
例えば、Solvency II の Solvency Capital Requirement (SCR) は 99.5% Value at Risk を1年ホライズンで算出する基準です(出典:Solvency II Directive 2009/138/EC Article 101)。
ただし、経済資本と規制資本は 別の概念です。規制資本は監督当局が定めた標準的な計算手法に従う一方、経済資本は 企業独自の内部モデルで算出され、より企業固有のリスクプロファイルを反映します(出典:Society of Actuaries "Economic Capital for Life Insurance Companies" 2016)。
非金融業界にも、複数の重要なリスク管理規制が存在する
ここまで、「非金融業界には経済資本配賦の規制義務がない」と書いてきました。
これは 経済資本(Economic Capital)に焦点を絞った正確な説明です。
しかし、リスク管理全般に視野を広げると、状況は大きく違います。
非金融業界の BI エンジニアが、無関係でいられない規制群
「規制対応は法務部の仕事でしょ?」── そう思った BI エンジニアの方、ちょっと待ってください。
以下の規制群は、すべて 「リスクを定量化・可視化して、経営層に報告する」 ことを企業に求めています。
それらの データパイプラインを構築・運用するのは、BI エンジニアの皆様です。
つまり、BI エンジニアが構築するリスク管理データパイプラインは、法令対応の中核インフラとして機能します。
これは、BI エンジニアの仕事を 「便利な可視化ツールの構築」 から 「企業の法令対応を支える基幹システムの構築」 へと格上げします。
IFRS の原則主義 ── 「注記」で経営判断の論理を説明する時代
ここまでの規制群に加えて、もう一つ、極めて重要な動きがあります。
それは、IFRS(International Financial Reporting Standards、国際財務報告基準) が世界の会計基準の主流となり、その 原則主義(Principle-based) という性質が、企業の財務開示に 質的な変化をもたらしている、という潮流です。
規則主義 vs 原則主義 ── 何が違うのか
まず、会計基準には大きく 2 つのアプローチがあります(出典:IFRS Foundation 公式)。
| アプローチ | 代表例 | 特徴 |
|---|---|---|
| 規則主義(Rule-based) | 米国会計基準(US GAAP)の伝統的アプローチ | 「こういう取引はこう仕訳しなさい」 と細則で網羅的に規定。判断の余地は少ない |
| 原則主義(Principle-based) | IFRS、日本会計基準(J-GAAP)の現代化版 | 「こういう原則に従って判断しなさい」 と原則を提示。具体的な判断は経営者の責任 |
エンジニアの言葉で言えば:
-
規則主義:
具体的な実装ガイドが網羅された API リファレンス。
「この場合はこの関数を呼べばいい」が明確
-
原則主義:
設計原則だけが示された、具体的実装は開発者の責任。
「なぜその実装を選んだのか、説明責任が伴う」
「自社の経済実態や取引実態を反映した合理的な判断が求められる（業界他社に追随はNG）」
原則主義が要求する「注記」 ── 経営判断のロジック開示
IFRS の原則主義の下では、企業は 数値だけを開示すれば済まされません。
財務諸表の 注記(Notes to the Financial Statements) で、「なぜその数値になったのか、どのような判断ロジックを経たのか、どのような不確実性を織り込んだのか」 を、文章で説明することが求められています(出典:IAS 1「Presentation of Financial Statements」第122段)。
エンジニア向けの直訳:
注記とは、情報科学・機械学習の論文で言うところの「Appendix」 です。本文(=財務諸表の数値)だけを見ても、なぜその数値が出たのかわからない。
Appendix(=注記)を読んで、はじめて 「使った前提」「採用したモデル」「不確実性の幅」 が理解できる ── そういう構造です。
特に、以下のような項目について、注記での詳細説明が要求されています:
- 重要な会計判断と見積もりの不確実性(IAS 1 第122段、第125段)
- 金融商品のリスク開示(IFRS 7)── 信用リスク、流動性リスク、市場リスクの定量・定性開示
- 公正価値測定の根拠(IFRS 13)── レベル 1〜3 の階層、レベル 3 の主要な観察不能インプット
- 減損損失の判断ロジック(IAS 36)── キャッシュフロー予測、割引率、感応度分析
「不確実性の時代」と注記の役割
経営者や経済界の議論では、ここ数年、「不確実性の時代」(Era of Uncertainty) という表現が頻繁に使われています。具体的には:
- 地政学リスク(米中貿易摩擦、ロシア・ウクライナ情勢、中東情勢)
- 政府規制リスク(各国の急速な政策転換、規制強化)
- カントリーリスク(新興国の通貨・政治・社会不安)
- 国際紛争リスク(サプライチェーン分断、輸出入規制)
- AI 固有リスク(LLM の脆弱性、情報流出、規制整備の遅れ)
- 気候変動リスク(物理的リスクと移行リスク)
これらのリスクは、伝統的な統計データだけでは予測しきれない ── まさに 未知の未知(unknown unknowns) の領域に踏み込んでいます。
このような時代において、企業は財務諸表の注記で:
「自社は、これらの不確実性に対して、どのようなリスク管理体制を構築し、どのような前提でリスクを定量化し、経営判断にどう織り込んでいるのか」
を、具体的に説明することが求められるようになりました。
これは、IFRS 原則主義の自然な帰結です ── 「こういう取引はこう仕訳しなさい」という細則ベースの規則主義では、「不確実性の時代」の経営判断を表現しきれないからです。
BI エンジニアに求められる新しい役回り
ここで、BI エンジニアの皆様に求められる役回りが、大きく拡張します。
従来の BI エンジニアの仕事:
「経営ダッシュボードに正しい数値を表示する」
IFRS 原則主義時代の BI エンジニアの仕事:
「経営ダッシュボードに表示される数値の背後にある『判断ロジック』『前提』『不確実性の幅』を、注記レベルで説明可能な形で記録・追跡・出力できるパイプラインを構築する」
具体的には、BI エンジニアが構築するパイプラインは、以下を満たす必要があります:
| 要件 | 技術的実装 |
|---|---|
| データの来歴(Lineage)を追跡可能 | OpenLineage、dbt のメタデータ層、Apache Atlas |
| 判断ロジックを宣言的に記述 | Idris の依存型、Coq の形式証明、ビジネスルールエンジン |
| 前提・パラメータの変更履歴を保持 | Git ベースのバージョン管理、Time-Travel クエリ(Snowflake、BigQuery) |
| 感応度分析を自動実行 | Monte Carlo シミュレーション、決定論的シナリオ分析 |
| 注記用の自然言語説明を生成 | LLM による要約、Claude Code + MCP による文書ドラフト |
| 監査証跡(Audit Trail)を永続化 | Immutable ログ、ブロックチェーン的な追跡可能性 |
つまり、本連載で取り組むのは:
「IFRS 原則主義時代の財務注記を、BI パイプラインから自動生成できる基盤」
の構築です。
これは、単なる「経営ダッシュボード」の枠を遥かに超えた、企業の財務開示そのものを支える基幹システムです。
形式手法(Idris、Coq)が必要となる理由
ここで、本連載が Idris(依存型) と Coq(形式証明) をハンズオン演習に組み込む理由が、明確になります。
IFRS 原則主義の注記で、「経営判断のロジックを説明する」 と言っても、自然言語（日本語、英語など）による説明だけでは、監査法人や規制当局は納得しません。
「論理的整合性の機械的な検証」が、近い将来、要求される可能性が高いです(出典:IAASB ISA 540「会計上の見積もりと関連する開示の監査」改訂版)。
具体的には:
-
Idris の依存型:
ビジネスルール(例:「投下資本は常に正の値」)を型レベルで強制することで、注記に書かれた前提が、コードの型で保証される
-
Coq の形式証明:
「経営判断 X が会計基準 Y に整合的である」 という命題を、定理として 数学的に証明可能な形で表現する
これは、IFRS 原則主義時代の財務開示に対して、形式手法による論理的健全性の保証 を提供する、極めて先進的なアプローチです。
本連載では、この 「IFRS × Idris × Coq」 の具体的な実装を、ハンズオンでお見せします。
まとめ ── BI エンジニアが財務開示の最前線に立つ時代
「規則主義から原則主義へ」「数値開示から判断ロジック開示へ」「確実性の時代から不確実性の時代へ」 ── これらの潮流は、BI エンジニアの役回りを根本的に拡張 しています。
本連載で構築するパイプラインは、これらの潮流に対応するための 実装ノウハウを、 8言語のコードと Claude Code + MCPで提供します。
これは、皆様のキャリアにとっても、皆様の勤務先企業にとっても、今後 10〜20 年にわたって価値を発揮する技術資産になります。
非金融業界に存在する主なリスク管理規制(網羅調査)
| 規制 | 適用範囲 | 規制が要求する内容 | BI エンジニアの実装責任領域 | 出典 |
|---|---|---|---|---|
| 米国 SOX 法第404条 | 米国上場企業すべて(非金融含む) | 内部統制システム(リスク評価を含む)の構築・評価義務、COSO Internal Control Framework が標準 | 内部統制データの収集・集計・監査ログ管理 | Wikipedia: ERM |
| 日本会社法・金融商品取引法(J-SOX) | 日本の上場企業すべて(非金融含む) | 内部統制報告制度 | 内部統制データの収集・集計、監査証跡の永続化 | 日本公式 |
| EU CRR III(2025年1月施行) | EU 内の事業活動に従事する非金融企業も一部対象 | 気候・環境要因の財務安定性リスク開示義務(ESG リスク) | ESG 関連データの収集・統合パイプライン | Green Central Banking (2024) |
| EU CSRD(企業サステナビリティ報告指令) | EU 内大企業(非金融含む) | サステナビリティ・ESG リスク報告義務 | ESG データレイクの構築・GHG 排出量集計 | EU 公式 |
| 米国 Dodd-Frank 法 Section 113 | 「systemically important」と判定された非金融大企業 | 連邦準備制度による包括的監督・規制資本要件・流動性要件 | 規制報告データの統合 | U.S. Treasury (2026) |
| EU GDPR + 各国版 | 個人データを扱うすべての企業 | 個人情報保護違反時の重大な罰金リスク | データガバナンス・データリネージュ・アクセスログ管理 | Wikipedia: ERM |
| インド SEBI 規則 17(9)条 | インド上場企業すべて | 取締役会による財務・非財務リスクの評価・低減手続き義務 | リスクレジスタの実装 | Lawgratis (2026) |
| インド会社法 134条・177条 | インド全企業 | 取締役のリスク管理開示、監査委員会のリスクシステム監視 | 取締役会向けリスクダッシュボード | 同上 |
| S&P Global Ratings ERM 評価 | 格付対象の非金融企業すべて | 2009年以降、S&P は非金融企業の格付に ERM 評価を組み込み(法令ではないが、格付影響=実質的強制力) | ERM 成熟度を裏付けるデータ可視化 | Wikipedia: ERM |
| California 気候情報開示法(2025年〜) | カリフォルニアで事業を行う年売上 $1B 超の企業 | GHG 排出量開示義務 | 排出量データ集計・第三者検証データの統合 | Green Central Banking |
整理:金融業界 vs 非金融業界の規制マップ
「金融業界には規制があり、非金融業界には規制がない」という単純な二項対立は、誤解を招きます。正確な構造は以下の通りです。
| 領域 | 金融業界 | 非金融業界 |
|---|---|---|
| 規制資本(Regulatory Capital)の保有義務 | ✅ あり(Basel III / Basel IV、Solvency II 等) | ❌ なし |
| 経済資本(Economic Capital)配賦の義務 | △ Basel II Pillar 2 で間接的要求 | ❌ なし |
| リスク管理体制の構築義務 | ✅ あり | ✅ あり(SOX、J-SOX、SEBI、会社法等) |
| リスク情報の開示義務 | ✅ あり | ✅ あり(ESG・サステナビリティ・有価証券報告書等) |
| 内部統制報告書の提出義務 | ✅ あり | ✅ あり(SOX 404、J-SOX) |
| 特定大企業への systemically important 指定可能性 | ✅ あり | ⚠️ あり(Dodd-Frank Section 113) |
つまり:
- 「経済資本配賦の義務」:金融業界のみあり、非金融業界はなし(本記事の主題はこの空白地帯)
- 「リスク管理一般」:金融・非金融ともに、複数の規制で 何らかの義務が存在する
BI エンジニアにとっての意義 ── あなたが作るパイプラインは、法令対応の中核インフラ
ここまで読んで、おそらく多くの BI エンジニアの方が気付かれたはずです。
「ERM × FP&A 統合 BI パイプライン」とは、これらの規制対応データを統合的に処理する基盤そのものではないか?
その通りです。
本連載で構築するパイプラインは、以下の 3 つの価値を同時に提供します。
-
経営判断のスピードと質を向上させる(本記事のメインテーマ)
-
既存の法令対応(SOX、J-SOX、ESG、GDPR 等)のデータ基盤として機能する
-
将来の規制強化に対する拡張性を確保する(EU CSRD、California 気候開示法のような新規制が追加されても、データレイヤーが整備されていれば対応コストが大幅に下がる)
Python で構築するデータパイプラインに、Idris の依存型でビジネスルールを型レベルで強制し、Coq で経営判断の論理的整合性を証明する ── 本連載の技術選定は、単なる技術趣味ではありません。
これらの規制が要求する 「監査証跡の正確性」「データ品質の保証」「論理的整合性の説明可能性」 に、形式手法レベルで応える設計です。
つまり、本連載で身につける技術は、法令対応の最前線で「監査に耐える BI パイプライン」を構築できるエンジニアになるための実装力です。
これは、転職市場でも、社内での評価でも、極めて希少な技術スキルセットとして位置付けられます。
計算式の構成要素
| 記号 | 名称 | ラベル | エンジニアにわかる説明 |
|---|---|---|---|
| $NOPAT_i$ | Net Operating Profit After Tax(税引後営業利益) | (経営管理で使われている既存の指標) | セグメント i が稼いだ「税金を引いた後の本業の利益」。「リスクとは無関係に、どれだけ稼いだか」を表す数値 |
| $EL_i$ | Expected Loss(期待損失) | (経営管理で使われている既存の指標) | セグメント i で 平均的に発生すると見込まれる損失額。確率変数の期待値。式は PD × LGD × EAD(後述) |
| $投下資本_i$ | Invested Capital | (経営管理で使われている既存の指標) | セグメント i に投入されている資本(借入金 + 自己資本のうちこのセグメントに割り当てられた金額) |
| $経済資本_i$ | Economic Capital | (経営管理で使われている既存の指標) | セグメント i の リスク量を吸収するために必要な追加資本。確率分布から算出される。リスクの大きい事業ほど大きくなる |
EL(期待損失)の中身
期待損失 EL は、リスク管理(ERM)の世界で標準的に使われる計算式で求めます(出典:Basel II / Basel III / Basel IV、IFRS 9)。
$EL = PD × LGD × EAD$ (経営管理で使われている既存の指標)
| 記号 | 名称 | エンジニアにわかる説明 |
|---|---|---|
| $PD$ | Probability of Default(デフォルト確率) | 「悪いことが起きる確率」。0〜1 の数値。例:0.02(2%) |
| $LGD$ | Loss Given Default(デフォルト時損失率) | 「悪いことが起きたときに失う割合」。0〜1 の数値。例:0.5(50%) |
| $EAD$ | Exposure at Default(デフォルト時エクスポージャー) | 「悪いことが起きたときに失う可能性のある金額」。例:10億円 |
例:
$PD = 0.02、LGD = 0.5、EAD = 10億円$ のとき、$EL = 0.02 × 0.5 × 10億 = 1千万円$。
なぜ SAROIC が重要なのか ── 既存指標 ROIC との比較
既存の ROIC(経営管理で使われている既存の指標)は、NOPAT / 投下資本 の式で計算されますが、これには リスクの量が入っていません。
| 指標 | ラベル | 式 | リスク考慮 |
|---|---|---|---|
| ROIC | (経営管理で使われている既存の指標) | NOPAT / 投下資本 | ❌ なし |
| SAROIC | (本連載シリーズ記事で筆者が提案する新指標) | (NOPAT − EL) / (投下資本 + 経済資本) | ✅ 分子と分母の両方に反映 |
エンジニアの言葉で言えば、ROIC は「リスク変数を考慮しない単純な比率」、SAROIC は「リスク変数を分子と分母の両方に織り込んだ補正後の比率」です。
これにより、「同じ ROE 5% でも、リスク量が違う事業を区別できる」という核心問題に、数値レベルで答えられるようになります。
8言語で同じ式を実装する
それでは、上記の SAROIC を、8言語で同じ式 $(NOPAT − EL) / (投下資本 + 経済資本)$ を実装した比較コードをお見せします。各言語の特性が一目でわかります。
(注:ここででは、簡潔さのため (NOPAT − 期待損失) / 投下資本 の単純化版で実装例を示します。完全版は連載記事の中で、後述します)
Python(本記事の主軸、PEP 8 + 型アノテーション + Ruff 標準)
def calculate_saroic(nopat: float, expected_loss: float, invested_capital: float) -> float:
"""SAROIC を計算する"""
return (nopat - expected_loss) / invested_capital
Julia(Blue Style 準拠、数値計算の高速性)
function calculate_saroic(nopat::Float64, expected_loss::Float64, invested_capital::Float64)::Float64
return (nopat - expected_loss) / invested_capital
end
Rust(rustfmt RFC 2436 準拠、メモリ安全 + 高並列)
fn calculate_saroic(nopat: f64, expected_loss: f64, invested_capital: f64) -> f64 {
(nopat - expected_loss) / invested_capital
}
Haskell(Tibbe スタイル、純粋関数型)
calculateSaroic :: Double -> Double -> Double -> Double
calculateSaroic nopat expectedLoss investedCapital =
(nopat - expectedLoss) / investedCapital
Idris(依存型でビジネスルールを型レベルで強制)
||| 投下資本が 0 でないことを型レベルで保証
calculateSaroic :
(nopat : Double) ->
(expectedLoss : Double) ->
(investedCapital : Double) ->
{auto prfNonZero : So (investedCapital > 0.0)} ->
Double
calculateSaroic nopat expectedLoss investedCapital =
(nopat - expectedLoss) / investedCapital
依存型 {auto prfNonZero : So (investedCapital > 0.0)} により、**「投下資本が 0 のときはコンパイルエラー」**を保証します。テストではなく、型システムによる保証。
Coq(形式検証で「SAROIC > WACC ⇒ 経済価値創出」を厳密に証明)
Require Import Reals.
Definition calculate_saroic (nopat el ic : R) : R :=
(nopat - el) / ic.
(* 投資判断の正当性を定理として証明 *)
Theorem saroic_exceeds_wacc_implies_value_creation :
forall nopat el ic wacc,
ic > 0 ->
nopat - el > wacc * ic ->
calculate_saroic nopat el ic > wacc.
Proof.
intros. unfold calculate_saroic.
(* SAROIC > WACC を厳密に証明可能 *)
Admitted.
「SAROIC > WACC ならば経済価値を創出する」という経営判断の正当性を、Coq の定理として数学的に証明します。これは IFRS 注記で要求される「経営判断の論理的整合性の開示」と直結します(本連載記事にて後述)。
TypeScript / React 19(Prettier + ESLint、フロントエンド)
export function calculateSaroic(
nopat: number,
expectedLoss: number,
investedCapital: number,
): number {
return (nopat - expectedLoss) / investedCapital;
}
本連載シリーズでは、後半で、React 19 + WebSocket でリアルタイム経営ダッシュボードを実装します。
じゃあ、実際にどの産業界の大企業が、どの場面で、どの言語を使っているのか?
ここまで読まれて、当然、こういう疑問が湧くはずです。
「8言語と Claude Code + MCP を本連載で扱う、というのはわかった。でも、実際に世界の大企業は、どの業界で、どの場面で、どの言語を実装言語として使っているのか?」
これは、ビジネスの現場の場面の中で、どのプログラミング言語を選択すべきかを判断する際の判断軸を知る上で参考になると思われます。
本記事執筆者が公開情報を網羅調査した結果を、以下に整理します。
8言語の大企業採用事例(網羅調査)
【画像中の誤字についての釈明】
上記画像の生成に使用した AI 画像生成ツール(Google Gemini)が、本記事執筆者の指示プロンプトを完全には反映できず、以下の誤字が画像中に含まれています。読者の皆様にご容赦いただくとともに、正しい表記をここに明記いたします。
画像中の誤表記 正しい表記 サブタイトル「8言語 × 業界別の大企採用事例の網羅面で使っているか」 8言語 × 業界別 大企業採用事例の網羅マップ 銀行・投資銀行行の補足「エンオン」 (本来は記載なし、Gemini の生成エラーによる意味不明文字列)
画像の データ内容(各セルの企業名、業界分類、観察結果)は、出典に基づき正確です。タイポグラフィの誤りのみご了承ください。
本連載が将来、新しい画像生成ツールに移行する、または画像編集による修正版を公開する際には、これらの誤字も修正される予定です。
| 言語 | 業界 | 採用企業 | 採用場面 | 規模・効果 | 出典 |
|---|---|---|---|---|---|
| Python | 銀行・投資銀行 | JPMorgan Chase | 社内基幹プラットフォーム「Athena」(リスク管理・トレーディング・取引価格付け) | 約 35 百万行の Python コード基盤 | eFinancialCareers, JPMorgan GitHub |
| Python | 銀行 | Bank of America | 社内基幹プラットフォーム「Quartz」 | 約 1,000 万行の Python コード、約 5,000 名の Python 開発者、1日約 3,000 commits | Finextra Research |
| Python | 投資銀行 | Citigroup | アナリスト・トレーダーの必須スキル(2018年〜) | 全アナリスト・トレーダーへの Python 必修化 | Finextra Research |
| Julia | 資産運用 | BlackRock(世界最大の資産運用会社、運用資産 10兆ドル超) | リスク分析の高速化 | リスク分析計算時間を大幅削減 | Software Patterns Lexicon |
| Julia | 製薬 | Pfizer(世界5大製薬会社) | 量的システム薬理学(QSP)モデル、心臓モデル | シミュレーション速度 115 倍、心臓定常状態計算が 1日 → 40分(26 倍高速化) | JuliaHub Pfizer Case Study |
| Julia | エネルギー(政府研究機関) | 米国 NREL(国立再生可能エネルギー研究所) | エネルギー消費モデルの最適化 | モデル精度 25% 向上、計算コスト 20% 削減 | Software Patterns Lexicon |
| Rust | クラウド・インフラ | Amazon Web Services | Firecracker(AWS Lambda、Fargate のマイクロVM 基盤) | AWS Lambda・Fargate 全体を支える基盤(全て Rust 実装) | Serokell, sysid blog |
| Rust | CDN・エッジ | Cloudflare | Pingora(NGINX 代替の HTTP プロキシ) | 1日 1兆リクエスト超を処理、CPU 70% 削減、メモリ 67% 削減、p95 レイテンシ 80ms 改善 | sysid blog |
| Rust | メッセージング | Discord | Read States サービス(11 百万同時接続) | Go から Rust への移行で GC スパイク完全排除、レイテンシ最大 160 倍改善 | Discord Engineering Blog |
| Rust | OS・OS基盤 | Microsoft | Windows カーネル コンポーネントの一部、Azure IoT Edge | メモリ安全性脆弱性の根本対策(Microsoft の CVE の 70% がメモリ安全性問題) | Andrew Odendaal Blog (2025) |
| Rust | モバイル OS | Android 13+ のネイティブコード | Android のメモリ安全性脆弱性が 76% → 24% に減少(2019→2024) | Boolean & Beyond (2026) | |
| Rust | 動画配信・決済 | TikTok(ByteDance) | 決済サービス | Go から Rust への移行で スループット 2 倍、CPU 78% → 52%、p99 レイテンシ 76% 改善 | sysid blog |
| C / C++ | 投資銀行・トレーディング | 業界全般(Goldman Sachs、Morgan Stanley、各大手銀行) | 低レイテンシ・トレーディングエンジン、リスク計算エンジン | 業界の事実上の標準 | 業界一般 |
| C / C++ | 自動車・組込み | Toyota、Honda、Bosch 等 | ECU(電子制御装置)、自動運転スタック | 業界標準 | 業界一般 |
| Haskell | 国際銀行 | Standard Chartered Bank | 価格設定・リスクエンジン Cortex(全資産クラス対応) | 約 650 万行の Mu/Haskell コード、40+名の Haskell 開発者、Markets 部門の年間営業収益 30 億ドルを支える基盤 | Serokell Interview, ACM POPL 2024 |
| Haskell | 投資銀行 | Barclays | エキゾチック・エクイティ・デリバティブ仕様記述(FPF / Financial Payout Framework) | 派生商品の正確な仕様記述に長年使用 | Risk.net |
| Haskell | 投資銀行 | JPMorgan Chase | リスク管理・トレーディングシステム | 強い型システムによるエラー防止 | MoldStud Industry Cases |
| Haskell | 投資銀行 | Credit Suisse(現 UBS 傘下) | 量的モデリンググループ GMAG(2006〜)、Paradise(派生商品プライシング DSL) | スプレッドシート検証ツール、再利用可能コンポーネント | HaskellWiki |
| Haskell | 金融データ | S&P Capital IQ | 金融分析、独自レポーティング言語 Ermine(2008〜) | Haskell + Scala で金融分析 | HaskellWiki |
| Idris | 形式仕様記述 | 主に研究機関・先進的製薬企業の仕様記述、暗号プロトコルの形式仕様 | 依存型による厳密な仕様記述(本連載で活用する依存型実装は、本記事執筆者が独自に経営判断ロジックの強制に応用したもの) | 研究・先進企業領域 | Idris 公式 |
| Coq | 証券取引所 | Tata Institute of Fundamental Research (TIFR) | 証券取引所マッチングアルゴリズムの形式検証 | 規制要件(fair、uniform、individual rational)を Coq で機械的に証明 | arXiv 1907.07885 (2019) |
| Coq | 航空機 | Airbus | CompCert 検証済み C コンパイラ(航空機制御ソフトウェアの基盤) | 「Csmith ファザーが 6 CPU年かけても、CompCert ではコンパイラのバグを発見できなかった」(PLDI '11 論文) | ACM Computing Surveys |
| Coq | ブラウザ・暗号 | Google Chrome | fiat-crypto(Coq で生成された暗号ライブラリコード) | Chrome ブラウザに搭載、機械検証された暗号実装 | Coq 公式 Industry 採用 |
| Coq | ブロックチェーン・暗号通貨 | Tezos、Zilliqa | スマートコントラクト言語の形式仕様 | プロトコル安全性の数学的証明 | Coq 公式 Industry 採用 |
| Coq | 学術・産業共同 | MIT FSCQ プロジェクト | 機械検証されたファイルシステム | 形式手法による信頼性保証 | Coq 公式 Industry 採用 |
| TypeScript / React | 投資銀行 | JPMorgan Chase(社内プロジェクト Mosaic) | フロントエンド・コンポーネントシステム | 銀行内部の React + TypeScript 標準実装 | JPMorgan GitHub |
| TypeScript / React | 全業界 | 業界標準(Meta、Google、Netflix、Microsoft、Amazon 等のフロントエンド) | Web フロントエンド全般 | デファクトスタンダード | 業界一般 |
Idris と Coq の金融業界での位置づけ
8つの言語のうち、Idris と Coq は、銀行・投資銀行での大規模商用採用事例が、現時点では限定的です。
整理すると以下の通りです:
-
Coq:
Tata Institute of Fundamental Research (TIFR) によって、証券取引所のマッチングアルゴリズムを Coq で形式検証した学術研究があります(arXiv 1907.07885、2019)。
規制要件(fair、uniform、individual rational)を Coq の定理として機械的に証明したもので、金融業界の規制対応に Coq を応用する道筋を示した重要な前例です。
-
Idris:
金融業界での大規模商用採用例は、公開情報では確認できません。
研究・教育・先進企業での限定的な利用が主です。
つまり、本連載で Idris と Coq を金融業界の文脈(経営判断ロジックの型強制、形式証明)で扱うのは、本記事執筆者による先進的な応用の試みです。
これは、本連載が 「世界でも数少ない先進的領域」 に踏み込んでいることを意味します。
ただし、Coq に関しては:
- Airbus の CompCert(航空機制御 C コンパイラの形式検証)
- Google Chrome の fiat-crypto(暗号ライブラリの機械検証)
- Tezos・Zilliqa のスマートコントラクト(プロトコル安全性の数学的証明)
など、他産業での実用採用は確固たる実績があります。本連載では、これらの応用パターンを、金融・経営の文脈に持ち込むわけです。
（投資ファンドにおけるアルゴリズム・トレードでは関数型言語の利用例あり）
投資ファンド・アルゴリズムトレードでの関数型言語の確固たる実績
Haskell・OCaml の アルゴリズムトレード(自動売買) 領域での採用は、金融業界の 最も先鋭的な部分に位置します。これは、マイクロ秒単位の取引判断に「型の安全性」を組み込むという、関数型言語の強みが直接的に発揮される領域です。
OCaml の代表例:Jane Street Capital
世界トップクラスのクオンツトレーディングファーム Jane Street Capital(従業員約 3,000 名、ニューヨーク・ロンドン・香港・シンガポール・アムステルダム拠点)は、OCaml を主要開発言語として 20 年以上使用しています:
- 約 3,000 万行の OCaml コードベース
- 500 名以上の OCaml プログラマ(世界最大の商用 OCaml ユーザー)
- トレーディングシステム、リスク管理、データセンター運用、会計システムまで全て OCaml
- Dune(OCaml コミュニティの事実上標準ビルドツール)、OPAM(パッケージマネージャ)を Jane Street がオープンソースで主導開発
- Webs(OCaml で構築された分散計算プラットフォーム、大規模取引のプライシング・リスク管理に使用、数十億ノード・エッジまでスケール)
業績規模:2025 年 Q2 に純取引収益 101 億ドル、純利益 69 億ドル(四半期最高記録)、ETF 取引量で米国市場の 24% シェアを占める世界最大級のマーケットメーカー。
[出典:OCaml.org Success Stories, Jane Street Technology, Wikipedia: Jane Street Capital]
OCaml 選定の哲学(Jane Street 公式の説明):
「他社が C++ でnano秒単位のレイテンシ最適化を競う中、Jane Street は OCaml の型安全性で「正しさ」を優先し、1,000 名のエンジニアが同じ言語で多数の市場・資産クラス・地域を一気にカバーする戦略を取る」(出典:Young & Calculated 2026年分析)
Haskell の代表例:Tsuru Capital
Tsuru Capital(東京・シンガポール拠点のプロップトレーディングファンド)は、指数先物・オプションのマーケットメイキングを、Haskell をほぼ全面的に使用して実装しています:
- 超低レイテンシ実行を、Haskell の純粋関数型・型システムで実現
- 「トレーダー」という職位は存在せず、全員が共通のコア戦略コードに貢献(全員が Haskell プログラマ)
- 高ボリューム・低マージンの市場で、ポジションを大きく取らずに利益を出す戦略
- 近年は Rust も併用(Tsuru Capital GitHub では Haskell + Rust の両方のリポジトリを公開)
[出典:Tsuru Capital LinkedIn, Tsuru Capital ZoomInfo, Tsuru Capital GitHub]
マルチストラテジー・ヘッジファンドの求人で見える関数型言語スタック
ニューヨークのマルチストラテジー・ヘッジファンド Hutchin Hill Capital は、クオンツトレーディング開発者の応募要件として、Haskell、F#、kdb+/q、OCaml、ML といった関数型・配列言語の経験を明示的に求めていました(歴史的記録、Haskell-Cafe メーリングリスト)。
これは、ヘッジファンド・プロップ取引業界が、関数型言語のスキルを高く評価する文化を持っていることを示します。
BI エンジニアにとっての示唆
これらの事実から、BI エンジニアの皆様に以下の実務的示唆が得られます:
-
Haskell・OCaml は、世界で最も収益性が高い金融機関(Jane Street、Tsuru Capital など)の最先端領域で、現役で使われている言語である
- これは 「アルゴリズムトレード = C++ で nano秒最適化」 という単純な業界ステレオタイプを覆す事実
-
型の安全性、関数型の合成可能性、形式手法の応用可能性を、経営判断と財務開示の領域に持ち込む本連載の戦略は、これらの実績ある関数型言語採用パターンを 金融取引の枠を超えて経営管理・FP&A 領域に拡張する 試みです
- 高野さん(本連載の登場人物、ロンドン外資系投資銀行クオンツ出身)が依存型(Idris)・圏論プログラミング・Emacs 時代の Haskell に親しんでいる設定は、この OCaml/Haskell クオンツトレーディング文化の延長線上にあります
業界横断的な観察
この採用事例マップから、3つの重要なパターンが見えてきます。
観察 1:金融・銀行業界は、Idris・Coq を除く 6 言語を大規模実用化
JPMorgan Chase、Bank of America、Standard Chartered、Barclays、Credit Suisse、BlackRock など、世界トップクラスの金融機関は、Idris・Coq を除く 6 言語(Python、Julia、Haskell、Rust、C/C++、TypeScript) を、用途に応じて大規模に使い分けています。
これは、金融業界が技術選定において妥協を許さない、最も厳しい実装環境であることを示しています。
つまり、本連載が 金融業界の知見を非金融業界に持ち込む BI パイプラインを構築する技術選定として、これら 6 言語を組み合わせることは、実務的に妥当です。
観察 2:製薬・航空機・暗号通貨でも、形式手法言語(Idris、Coq)が実用に使われている
Pfizer の Julia 採用、Airbus の Coq(CompCert)採用、Google Chrome の fiat-crypto(Coq 生成)採用、Tezos・Zilliqa のスマートコントラクト形式証明は、「形式手法言語は研究室の玩具ではない」 ことを実証しています。
特に Airbus の CompCert は、「Csmith ファザーが 6 CPU年かけても、CompCert ではバグを発見できなかった」(PLDI '11) という極めて高い信頼性を達成しています。これは、IFRS 原則主義時代の財務開示に Coq 形式証明を応用する根拠 として、極めて強力な前例です。
観察 3:Rust の急速な企業採用(2020年代後半の最大の言語潮流)
AWS Firecracker、Cloudflare Pingora、Microsoft Windows、Google Android、Discord、TikTok ── ここ 5 年で、システムプログラミングの主流が C/C++ から Rust へ急速にシフトしています。
Cloudflare Pingora が 1 日 1 兆リクエストを Rust で処理している事実は、本連載がリスク計算エンジンに Rust を採用する判断の妥当性を裏付けます。
本連載の技術選定の正当性
以上の事実に基づくと、本連載で扱う Python + Julia + Rust + C/C++ + Haskell + Idris + Coq + TypeScript/React という 8 言語の組み合わせは:
- 金融業界の最先端実装で実証済みの技術スタック(6 言語)
- 製薬・航空機・暗号通貨など、誤りが許されない産業で採用されている技術スタック(Coq・Julia)
- 2020年代後半に急速にシェアを広げている、向こう 10 年の主流となる技術スタック(Rust)
を 網羅的に組み合わせた、極めて現実的かつ先進的な選択であることがわかります。
さらに、Idris と Coq の金融業界応用は、本連載の独自の挑戦でもあります。
Coq は他産業(航空機・暗号通貨・ブラウザ暗号ライブラリ)での実績があり、その応用パターンを 金融・経営の文脈に持ち込むことで、IFRS 原則主義時代の 「経営判断の論理的整合性の数学的証明」 という、まだ世界でも数少ない領域を切り拓きます。
つまり、本連載を読み終えた時点で、皆様の手元には、世界トップクラスの金融機関・製薬会社・テック企業が実用している技術スタックが、ERM × FP&A 統合 BI パイプラインという具体的な実装例として、お手元に残ります。
これは、皆様のキャリアにとっても、皆様の勤務先企業にとっても、価値ある技術資産としてお使いいただけます。
Claude Code + MCP のハンズオン演習(3つ)
本連載シリーズには、Claude Code と各種 MCP(Model Context Protocol)を使った 手元で再現できるハンズオン演習 を3つ含めています。
| 演習 | 使う MCP | 演習内容 |
|---|---|---|
| 演習 1 | GitHub MCP | リポジトリから risk_register.csv を取得して期待損失を計算 |
| 演習 2 | Postgres MCP | データベースから欧米 FP&A 調査結果を SQL 検索し Plotly で可視化 |
| 演習 3 | Tableau MCP | 投資判断ダッシュボードを自動生成、稟議書に貼る URL を取得 |
各演習で、Claude Code に渡す具体的なプロンプトと、生成されるコードを掲載しています。
各言語の公式スタイルガイド遵守(プログラマへの宣言)
本記事のコードは、各言語の公式スタイルガイドに準拠して書いています。
| 言語 | 公式スタイルガイド | ツール |
|---|---|---|
| Python | PEP 8 + 型アノテーション(PEP 484、PEP 604、PEP 585) | Ruff、Black、mypy |
| Julia | Julia 公式 Style Guide + Blue Style | JuliaFormatter.jl |
| Rust | Rust Style Guide(RFC 2436) | rustfmt、Clippy |
| C/C++ | Google C++ Style Guide、ISO C++ Core Guidelines | clang-format |
| Haskell | GHC Style、Tibbe スタイル | hlint、ormolu、fourmolu |
| Idris | Idris 2 公式ドキュメンテーションスタイル | (限定的) |
| Coq | Coq Coding Conventions | (限定的) |
| TypeScript | TSConfig + ESLint + Prettier | Prettier、ESLint |
Python の型アノテーションについては、Qiita の名記事 NUNOGAWA「つよつよエンジニア『Python のコードに型アノテーションをつけるといいね』」 で示された Python 3.10+ の現代記法 (list[str]、dict[str, int]、X | None) を全面採用しています。本記事の高野さんと佐藤さんも対話の中で言及します(第7.2.4節)。
IFRS 原則主義 × Idris 依存型 × Coq 定理証明 ── 形式手法の経営応用
本連載シリーズでは、IFRS の原則主義(Principle-based)が要求する「注記での経営判断の論理的開示」 を、Idris の依存型と Coq の定理証明で 機械的に検証可能にする道筋を示します。
プログラマ・形式手法愛好家・規制当局関係者の関心が交差する領域です。
動くコードは GitHub で公開、git clone から再現可能
本記事のサンプルコード一式は、GitHub リポジトリ erm-fpa-pipeline で公開予定(2026年5月13〜19日に構築・公開、本連載執筆中に全実装公開)。git clone から手元で再現できます。
筆者の GitHub:https://github.com/EtaleCohomology
関数型プログラミング・依存型・形式検証の文脈
本記事の登場人物の一人、高野さんは、ロンドンの外資系投資銀行クオンツ出身で、関数型プログラミング・依存型(Idris)・圏論プログラミングの愛好家です(キャリアの裏の顔として)。Qiita の圏論プログラミング記事を10年以上前から愛読しています。
本記事の Idris コードは、彼女が「型レベルでビジネスルールを強制する」という発想で書いたものとして登場します。
LLM 時代の前から、外資系金融機関のパリやロンドンの同僚とEmacsで関数型クオンツプログラミングをしていた彼女が、2026年の Claude Code + MCP 時代に何を思うか ── そんな対話の楽しみも、本記事には含めています。
本記事の本質は、これら技術要素を駆使して、ERM × FP&A 統合 BI を構築し、data driven 経営をリードできるエンジニアになることです。
技術と経営の両輪が、同じ目的(リスクを取った上での経済価値創出)に向かって統合される ── それが本連載のテーマです。
それでは、次回の記事に続きます。