AI企業はなぜ儲からないのか──「AI×形式検証」が変える収益の構造
AIの性能は飛躍的に向上している。それでも、AIを開発・提供する企業が、その価値に見合う利益を獲得できるとは限らない。なぜか。私は、その理由の一つはAI企業が顧客に提供する価値と、顧客が実際にその価値を利益に変える仕組みが、別々の企業の手にあることだと考えている。そして、この構造を変える有力な選択肢が「AI×形式検証」ではないか。
▼関連するプレスリリース（日本発形式検証技術"責任OS"）
「AIが役立つ」と「AI企業が儲かる」は違う
例えば物流企業に、配送計画を最適化するAIを提供するとしよう。AIが優れた計画を生成しても、それだけで配送コストは下がらない。既存の配送網に組み込まれ、荷主や現場の条件を満たし、実際に採用・実行されて初めて利益改善につながる。つまり、AI企業が技術を提供しても、利益を実現するまでの重要な工程は顧客側に残る。さらに、顧客が利益を得たとしても、その一部が自動的にAI企業の売上や利益になるわけではない。価格設定、契約、競争環境にも左右される。2026年のMcKinseyの調査では、回答者の80％がAIによる自分自身の生産性向上を報告した一方、AIが所属組織のEBIT（利払前・税引前利益）にプラスの影響を与えたと回答したのは37％だった。これは顧客企業側の自己申告調査であり、AI提供企業の利益率を示す数字ではない。しかし、生産性の改善と企業全体の利益改善は別の段階にあることを示している。[1]
経済学が示す「補完資産」の問題
この問題は、AIの登場以前から研究されてきた。David Teeceは1986年の論文で、優れた技術を生み出した企業が必ずしも利益を獲得するわけではなく、製造、販売、顧客接点などの**補完資産（complementary assets）**を持つ企業に利益が帰属する場合があると論じた。[2]この視点をAIに当てはめると、問題が明確になる。AIのモデルだけではなく、業務データ、運用ノウハウ、既存システム、顧客との調整、実行能力がそろって初めて価値が生まれる。ところが、その多くはAI提供企業の外側にある。2025年に発表されたEricssonの事例研究は、この問題をAI事業の現場から裏付けている。社内文書や34人へのインタビューに基づく同研究は、新規のAI事業で利益を得る際に、顧客データへのアクセス、必要能力の確保、価値の説明・回収が課題になると分析した。[3]興味深いのはEricssonの対応だ。AIの分析結果を提示するだけでなく、標準化したインターフェースを通じて顧客ネットワークの変更まで行うクローズドループの自動制御を組み合わせ、個別調整への依存を減らそうとした。[3]これは形式検証の導入事例ではない。しかし、AIの「提案」だけを売るのではなく、提案を現実の業務で使える状態まで一体で提供することの経営的な重要性を示している。さらに2026年10月、Rahul KapoorとManav Rajは、AIによる価値創出を、AI提供者と利用企業が補完機能を組み合わせる「エコシステム」の問題として整理した。利用企業がどの組み合わせを選ぶか、提供企業がどこまで補完機能を自社で担うかが、価値創出と利益獲得を左右する。[4]AI企業は、何を顧客に委ね、何を自社の商品に取り込むべきなのか。 ここが重要な経営判断になる。
「AI×形式検証」は何を自社の商品にできるのか
ここで形式検証が登場する。形式検証とは、仕様や条件を数学的・論理的に定義し、対象の仕組みがそれらを満たすか確認する技術である。もちろん、証明できるのは定義された仕様と前提の範囲に限られる。AIの判断を業務に組み込む際には、「判断がもっともらしいか」だけでなく、次のような問題がある。
その判断は、契約や業務上の制約を満たしているか。
必要な証拠や承認がそろっているか。
条件が満たされない場合に、実行を止められるか。
これらのうち形式化できる条件については、形式的な検証と実行認可の仕組みを組み合わせることで、AIの提案を採用可能な判断へ変える工程を製品化できる。重要なのは、形式検証が直接利益率を引き上げる、という話ではない。従来は顧客の個別判断や調整に依存していた「AIを採用・実行してよいか確認する工程」の一部を、AI企業側が共通の技術として提供できるという点である。なお、単純な条件照合と形式検証は同義ではない。形式検証は、定義した仕様に対する性質を数学的に確認する技術であり、個別判断の条件照合や実行認可とは役割が異なる。
共同配送で考える
AIが複数の荷主を組み合わせた効率的な配送計画を提案したとする。しかし、既存の荷主との契約条件、費用負担の上限、許容する配送時間帯などを満たしていなければ、その案は採用できない。AIの最適化結果がどれほど優秀でも、実行前の確認が別途必要になる。そこで、条件を機械判定可能な形で定義し、AIが生成した計画がそれを満たすかを検証する。満たさなければ実行認可を出さず、条件の見直しや人の確認へ戻す。この構造なら、AIは計画を生成し、検証機構は定義済みの条件への適合を確認し、業務システムはその結果に応じて実行を制御する。実際の配送が計画どおりに完了することや、必ず利益が増えることまで証明するわけではない。それでも、導入時に毎回発生する採用判断の一部を標準化する価値は大きい。
検証を「商品」にする先行例はすでにある
この考え方は、純粋な構想にとどまらない。AWSの「IAM Access Analyzer」は、利用者が作成したアクセス権限ポリシーについて、指定したセキュリティ基準への適合をデプロイ前に自動推論で確認するカスタムポリシーチェックを、有料のAPIとして提供している。公式料金例では、1,000回のチェックが2米ドルとされている。[5]AWSの研究チームは、複数種類のアクセス制御ポリシーを横断して検証する再利用可能な形式モデルが、複数のAWSアプリケーションで利用されていることも報告している。[6]これはAIの業務判断を保証するサービスそのものではない。AWSの検証サービスがどの程度の利益を生んでいるかも公開資料からは分からない。ただし、検証機能を共通化し、利用回数に応じて課金できることを示す具体的な商用事例である。AIの判断に対する検証も、同様に共通化できる部分と顧客固有の条件を切り分けられれば、個別開発だけに依存しない基盤型の事業を構想できる。
さらに、AI自身が形式検証の利用範囲を広げ始めている
もう一つ重要な変化がある。形式検証は従来、高度な専門知識と多くの作業を必要とする技術だった。しかしAIが、その作業を支援し始めている。2026年11月10日、Google DeepMindは「AlphaProof Code」を発表した。人間が関与して仕様を定め、AIエージェントが生成したLeanの証明をLeanのカーネルで検査することで、Signalの暗号実装の主要な性質を、一定の仮定の下で機械語レベルまで検証した。報告された証明コードは約650万行に及ぶ。[7]また、LLMを組み込んだシステムについて、形式的な行動制約を監査し、実行時に監視・介入する研究も進んでいる。[8]これらは形式検証がすべてのAIシステムで必須だと証明したものではない。それでも、AIが形式検証を扱えるようになることで、検証技術を産業の共通基盤に近づけられる可能性は、以前より具体的になっている。
AI企業の利益の取り方を変えられるか
AI企業は月額課金や従量課金でも収益を得られる。しかし、顧客が導入・利用を継続する理由は、実際の業務上の価値に左右される。しかし成果は、顧客側の業務改革、現場の実行、データの質などに左右される。「AI×形式検証」の統合提供には、もう一つの選択肢がある。AIによる改善成果だけを売るのではなく、AIの判断を条件付きで採用・実行するための共通基盤そのものを売るのである。例えば、検証基盤のライセンス、検証・認可APIの利用料、業務システムへの組み込み料などが考えられる。AIによる削減額を毎回証明しなければ対価を設定できない、という構造から一歩離れられる可能性がある。もちろん、顧客が対価を払うかどうかは別問題だ。十分に重要な業務課題があるか、既存のテストやルールチェックで代替できないか、顧客固有の仕様策定に費用がかかりすぎないか。ここを実証しなければ、形式検証を組み合わせただけで収益性が高まるとは言えない。それでも、方向性は明確だ。AI企業が顧客に依存していた価値実現の一部を、自社が提供できる製品へ変える。 その手段の一つが、形式検証と実行制御の統合である。
結論──AI時代のインフラとは何か
AIの性能を上げる企業は今後も増えるだろう。しかし、AIが優れた判断を生み出せることと、その判断を企業が責任を持って実行できることの間には、依然として距離がある。その距離を埋める技術には、特定のAIモデルや産業だけに閉じない価値がある。形式検証は、すべての業務に必要な万能技術ではない。しかし、重要な判断について**「何を満たせば採用できるか」「何が満たされなければ実行してはいけないか」を機械的に確認する仕組み**は、AIが産業に深く組み込まれるほど重要になる可能性がある。私たちが「AI×形式検証」を事業の中心に据える理由も、そこにある。AIそのものを売るだけでなく、AIを産業の中で使える状態にする仕組みを売る。形式検証がAI時代のインフラになり得ると考えるのは、そのためである。
一次文献・原資料
以下はいずれも、原著論文、研究機関による原資料、またはサービス提供者の公式資料。本文中の番号に対応する。
McKinsey & Company (2026), The state of AI in 2026: On the road to ROI（2026年8月25日、調査報告）。原資料
David J. Teece (1986), Profiting from Technological Innovation: Implications for Integration, Collaboration, Licensing and Public Policy, Research Policy, 15(6), 285–305. 原論文・DOI
Mats O. Pettersson, Joakim Björkdahl & Marcus Holgersson (2025), Profiting from AI: Evidence from Ericsson’s Pursuit to Capture Value, California Management Review, 67(4). 原論文・オープンアクセス
Rahul Kapoor & Manav Raj (2026), Value creation and capture in artificial intelligence-enabled ecosystems, Strategic Entrepreneurship Journal（2026年10月13日オンライン公開）。原論文・DOI
Amazon Web Services, AWS IAM Access Analyzer pricing（カスタムポリシーチェックの機能と公式料金）。公式料金ページ
Lee Barnett et al. (2025), Modeling the AWS Authorization Engine, Formal Methods in Computer-Aided Design (FMCAD 2025). 研究機関の原資料
Swarat Chaudhuri et al. (2026), AlphaProof Code: Verifying Signal’s Security at the Machine-Code Level（2026年11月10日公開）。原論文
Parand A. Alamdari, Toryn Q. Klassen & Sheila A. McIlraith (2026), Formal Methods Meet LLMs: Auditing, Monitoring, and Intervention for Compliance of Advanced AI Systems. 原著論文
補助的な一次文献：
Erik Brynjolfsson, Daniel Rock & Chad Syverson (2021), The Productivity J-Curve: How Intangibles Complement General Purpose Technologies, American Economic Journal: Macroeconomics, 13(1), 333–372. AIなどの汎用技術が価値を発揮するための補完的投資を論じた原論文。原論文・DOI
Hyunjin Kim & Dahyeon Kim (2026), Mapping AI into Production: A Field Experiment on Firm Performance（INSEADワーキングペーパー）。515社を対象に、AIの適用先を発見する課題と業績への影響を調べた実験研究。研究機関の原資料
※本記事の「AI×形式検証による顧客依存の縮小・収益化」は、これらの一次文献と事業事例から導いた事業仮説であり、その収益性自体が実証済みだと主張するものではない。
コメント