8090 のビジネスモデルを読み解く — Software Factory を核にした AI ネイティブ IT サービス企業と、日本で同じ構造を組み立てるならどう考えるか

8090 Solutions は、Chamath Palihapitiya が共同創業者兼 CEO として直接率いる米カリフォルニア州レッドウッドシティ拠点のスタートアップです。2026 年 6 月 29 日に Salesforce Ventures 主導で 1 億 3,500 万ドルのシリーズ A を発表し、同じタイミングで Chamath が Facebook 退社以来となるフルタイムの経営職に復帰して CEO に就いた、というニュースで名前を見た人も多いと思います。

一見「AI コーディング支援 SaaS」に見えますが、公式サイト・プレスリリース・SEC Form D・CEO 自身の発言を順に読み合わせていくと、実態はかなり違います。8090 は、自社の AI 開発基盤 Software Factory を武器に、規制産業の大企業向けにシステムを「設計・構築・ホスト・保守」する AI ネイティブな IT サービス（受託開発＋マネージドサービス）企業です。月額 200 ドルのセルフサーブ SaaS も併売していますが、収益と信用の中核は年 100 万ドルからの Enterprise 案件と、EY との提携にあります。

本稿では、前半で 8090 のビジネスモデルを公開資料から整理し、最後のセクションで、同じ構造を日本で作るならどこから手を付けるかを考えます。日本語での展開・国内パートナーは現時点では確認できません。

「AI コーディング SaaS」ではなく「AI ネイティブな IT サービス」である

シリーズ A のプレスリリースは、Software Factory が 8090 自身のエンタープライズ・デリバリー事業を支えている（powers）と明記しています。顧客となるのは医療・保険・ライフサイエンス・製造・金融・政府といった、変更コストが高く監査要件の厳しい業種です。公開されている事例も、Greenfield な新規開発ではなく、旧システムの解読と置き換えに寄っています。

CMS（米メディケア・メディケイド・サービスセンター）: 1,800 万行を超える COBOL・Assembly から業務ルールを平易な英語に抽出する ClaimsCore 案件。公式サイトでは「10 万件超」、シリーズ A のプレスリリースでは「40 日で 30 万件超」と数字に揺れがあります。
BISSELL: 7,000 件超の部品申請のうち 81.4% を自動承認するワークフローで、年間コストを半分に。トップページでは「1 万件超の部品名」という数字も使われています。

成果数値はいずれも 8090 自身の発表で、第三者の独立検証はありません。CMS 案件については 8090 側も「複数の請負業者の 1 社にすぎない」と注記しており、CMS 本体の刷新は HealthEdge（11.5 億ドル）と Peraton（8.26 億ドル）が受注しています。

ここで重要なのは、競争相手がどこにいるかです。シート課金 200 ドルは GitHub Copilot Business の 19 ドルや Devin Pro の 20 ドルのおよそ 10 倍で、個人開発者向けの価格ではありません。年 100 万ドルの Enterprise はアクセンチュアや TCS、Infosys 等の SI・コンサルの価格帯で、1 社あたりの売上が大きい代わりに人手を要します。8090 が狙っているのは、AI コーディングツール市場ではなく、兆ドル規模の IT サービス・レガシー刷新市場です。

Software Factory は SDLC のコントロールプレーン

Software Factory 自体の設計を見ると、「コードを書く AI」ではなく、「人間と複数の AI エージェントが同じ文脈で作業するための統治・調整レイヤー」という位置付けが徹底されています。Introduction は Software Factory を「SDLC をオーケストレーションする AI ネイティブなプラットフォーム」と説明しており、本稿ではこの層を SDLC のコントロールプレーンと捉えます。

主な構成要素は次の 5 つです。

構成要素	役割
Requirements	ビジネス意図を平易な英語で記述し、エージェント支援で精緻化する
Blueprints	技術設計・アーキテクチャ判断を人間が読める技術仕様として記録し、Editor がエージェントの提案を採用・却下する
Work Orders	実装タスクを分割し、MCP 経由で Cursor・Claude Code・Codex などのコーディングエージェントへ渡す
Tests	要件と検証を紐づける。独立したモジュールではなく、オン・オフを切り替えられる機能として扱われる
Feedback	利用者の声をトリアージして開発項目化する

これらを 1 つの知識グラフで結び、要件・設計・コード間のドリフトを Drift Bot が検知します。コード生成そのものは Cursor・Claude Code・Codex 等の外部エージェントに任せる BYOA（Bring Your Own Assistant）方式で、特定モデル・特定ハーネスへの依存を避ける設計になっています。推論モデルも Anthropic・OpenAI・Google・xAI・Fireworks AI・Groq の 6 社をサポートし、管理者が組織設定で利用するモデルを有効化します。

この構図を図にすると、Software Factory が「上」で、既存の AI コーディングエージェントや既存の IDE・Git・ERP は「下」に置かれ、Software Factory が意図・設計の層を押さえる形になります。

flowchart TD
    BIZ[ビジネス部門] -->|自然言語の要件| REQ[Requirements]
    REQ --> BP[Blueprints]
    BP --> WO[Work Orders]
    WO -->|MCP| IDE[Cursor / Claude Code / Codex]
    IDE --> CODE[(GitHub / GitLab リポジトリ)]
    CODE --> KG[(Knowledge Graph)]
    REQ --> KG
    BP --> KG
    KG -->|Drift Bot| REQ
    CODE --> TEST[Tests]
    TEST --> FB[Feedback]
    FB --> REQ
    KG -->|MCP| ERP[(既存 ERP)]

Chamath は X の投稿で「スロップ（粗悪品）を速く作れるツールは山ほどある。我々のアプローチはその正反対だ」と書いており、監査証跡・トレーサビリティという規制産業向けの訴求を前面に出しています。

収益は月 200 ドルと年 100 万ドルの二階建て

8090 の収益モデルは、公式ドキュメントの Usage と Ry Walker の調査で確認できる 2 本と、顧客向けの AI トークン従量で成り立っています。

収益源	価格・課金	対象
Software Factory セルフサーブ	1 ユーザー月額 200 ドル＋トークン従量。閲覧専用シートは無料。50 席超は営業対応	先進的な社内エンジニアリング組織、中規模開発チーム
8090 Enterprise	年 100 万ドルから、個別見積もり。設計・構築・ホスト・保守まで一括	医療・保険・金融・製造・政府等の大企業
AI トークン利用料	プロバイダ料金を基礎に従量課金。セルフサーブでは 20% のプラットフォームフィー	全顧客

セルフサーブで 50 席を埋めても年間 12 万ドル程度にしかならないのに対し、Enterprise は 1 社で 100 万ドル以上を取る設計で、平均契約額（ACV）の差が 1 桁近くあります。シリーズ A のブログで Chamath は「最も厳しい顧客を相手にすることで、最終的には SMB や個人創業者にも価値のあるプレイブックとネットワーク効果を Software Factory に組み込む」と書いており、サービスで稼ぎつつ製品化して SaaS へ移行する services-to-software 型の戦略と読めます。Dealroom の記事も、エンタープライズ向けのプレイブックを誰もが使える製品にまとめる方向性として紹介しています。

Enterprise 案件の経済は、Palantir 型のフォワードデプロイモデルに近い構造です。8090 のエンジニアが顧客チームに入り込んで Software Factory 上で業務システムを組み立て、完成後もホスティングと保守を通じて本番運用の責任を 8090 が負います。この点を、ツールベンダーとの違いとして売っています。

EY.ai PDLC という流通チャネル

直販だけでは Enterprise セグメントは広がりにくく、ここで EY との提携が販売チャネルとして働きます。2026 年 3 月 18 日に発表された EY.ai PDLC は、EY 自身のソフトウェア開発プロセスを 8090 Software Factory に載せ、EY US の数万人規模のコンサルタントに展開する計画です。EY 内部のユースケースでは「開発生産性 70% 向上、デリバリー速度 80 倍、自動テストカバレッジ 95% 超」と主張していますが、独立検証はありません。

GTM をまとめると、次の 4 本足になります。

創業者主導のブランド・コンテンツ: Chamath の X 投稿、All-In ポッドキャスト、Substack に依存
エンタープライズ直販: 「1 ワークフローから始めて全体に広げる」ランド＆エクスパンド型。公共部門・連邦政府プログラムを強化
SI・コンサル経由のチャネル: EY.ai PDLC を筆頭に、将来 Salesforce の販売網も使える可能性
PLG 要素: セルフサーブ登録、無料の View シート、Cursor・Claude Code・Codex との MCP 連携

8090 にとって EY は「競合ではなくチャネル」です。AI でコンサル市場が縮むという前提に立つなら、既存の巨大 SI を敵に回すよりも、彼らを Software Factory のリセラーとして取り込むほうが整合します。

AI コストとサービス業比率という 2 つのリスク

公開情報で最もはっきり書かれているリスクは、AI 推論コストの増加です。Chamath は 2026 年 3 月 5 日の X 投稿で、2025 年 11 月以降に AI コストが 3 倍超になり、年間 1,000 万ドル超のペースへ向かっている一方で「生産性や売上にはそれに見合う伸びがまだ見えない」と書いています。同じ投稿で「Cursor から移行する必要がある。Claude Code に比べて高すぎる」とも書いており、Business Insider はこれを Cursor から離れる方針として報じています。

セルフサーブ側はトークン代に 20% のプラットフォームフィーを乗せて顧客に転嫁していますが、Enterprise の固定価格契約では 8090 自身の原価になります。コスト急増が粗利をどこまで圧迫しているかは、外からは確認できません。

もう 1 つの構造的な論点は、人員比例のサービス収入に対して、ベンチャー型のリターンが本当に描けるかです。AI Enablement Insider は率直に「Chamath はコンサルタントになった」「1 億 3,500 万ドルのシリーズ A はサービス業として前例がない」と書いていますし、HackerNoon は「開発会社（dev shop）だ」と表現しています。

長期の企業価値を決めるのは、売上成長率そのものより次の 3 点だと読めます。

Enterprise 案件 1 件あたりの投入エンジニア工数がどこまで減るか
同一業界の次案件で Blueprint・テスト・エージェントスキル・業務ルールをどこまで再利用できるか
AI トークン費用を顧客へ転嫁できるか、またはモデルルーティング・キャッシュで原価率を下げられるか

逆に言えば、8090 が「サービス案件で蓄積した知識を、Software Factory を介して SaaS の限界費用ゼロに近い形へ転換」できたときに、はじめて今回のシリーズ A のバリュエーションが正当化されます。

競合との位置取り

同じカテゴリ名を複数社が使い始めているため、整理しておきます。

会社	主戦場	価格	8090 との違い
GitHub Copilot	IDE 一体型 AI 開発	Business 月 19 ドル、Enterprise 月 39 ドル	GitHub と Microsoft の既存顧客基盤を通じた販売網を持つ。8090 は Copilot を置き換えず、要件・設計の層を上から押さえる
Cursor・Claude Code・Codex	エージェント型コードエディタ	個人・チーム向け低価格	8090 は MCP でこれらを「下請け」として呼び出す
Factory.ai	Droid 型コーディングエージェント	個人 20〜200 ドル、法人は商談	Factory はエージェント実行側がより中心。8090 は組織横断の統治
Devin / Cognition	自律コーディングエージェント	Pro 月 20 ドル、Max 月 200 ドル、Teams・Enterprise あり	Devin は「デジタルエンジニア」色。8090 は複数エージェント・複数ロール間の工程統制
Harness	CI/CD・AI delivery ガバナンス	Enterprise 商談	Harness は commit → production、8090 は intent → requirements
Moderne	大規模リファクタリング	Enterprise 商談	Moderne は構造化コード変換、8090 は業務ルール抽出と新規構築まで
アクセンチュア・Infosys・TCS 等	SI・IT アウトソーシング	人月課金	8090 が価格帯と提供範囲で直接競合する相手。少人数 × AI で成果責任を負う方向で差別化

8090 が 200 ドル/ユーザー/月を正当化できるかは、「要件・設計・監査・組織知識まで含めて 1 つの基盤に乗せる価値」を顧客が認めるか次第です。Microsoft や GitHub がこの上位層へ侵食してきた場合には、distribution の差で押し切られる可能性もあります。

日本で同じ構造を組み立てるならどう考えるか

ここからは、8090 の設計思想を踏まえて、日本で同じようなモデルを作るなら何から始めるかを考えます。

日本側の前提条件は、米国市場と 3 つの点で違います。

自然言語の層が日本語: Requirements・Blueprints・Work Orders が日本語で書かれ、業務ルールや仕様書も日本語で、LLM の精度・レイテンシ・コストが英語とは異なります。
SIer の商慣行が人月中心: 見積は人月、契約はウォーターフォール前提の多段階、成果物の責任範囲も個別に詰める、という文化が根強いです。
レガシーが COBOL／メインフレーム／独自パッケージの混在: 経産省が DX レポートで「2025 年の崖」として指摘した通り、金融・保険・公共の基幹は依然として大型 COBOL・メインフレームと国産パッケージの組み合わせです。

このうえで、8090 と似た構造を組むなら、おおむね次のような設計になると考えます。

ターゲットは規制産業の基幹刷新に絞る

セルフサーブ型の AI コーディング支援は、GitHub Copilot や Cursor、Claude Code など海外勢の価格・性能に正面から張り合うのは現実的ではありません。日本版 Software Factory が狙うべきなのは、米 8090 と同じく、兆円規模のレガシー保守・刷新市場のほうです。

想定セグメントとしては次が候補です。

地方銀行・生命保険・損害保険の勘定系・契約管理
医療保険・DPC・レセプト・電子カルテ
製造業のメインフレーム帳票・MES・PLM
公共（自治体、独法、省庁）の基幹業務

いずれも「監査・コンプライアンス」「ベンダーロックイン」「人材の高齢化」の 3 条件が揃っており、Software Factory 型の「意図から監査証跡まで繋げる」訴求が、監査証跡を求める調達要件に合います。

価格体系は人月商習慣に並走させる

年 100 万ドル（約 1.5 億円）の Enterprise 最低価格は、国内の 1 次請け・大型案件とそう遠くない水準で、既存のウォーターフォール案件の延長で売れる値付けです。ただし日本では、相当規模の案件でも「月額のマネージドサービス契約」より「フェーズごとの検収ベース契約」のほうが通りやすいのが現実です。

8090 のモデルを国内で動かすなら、最初から以下の二層にしておくと、既存の調達フローと衝突しにくくなります。

要件定義・設計フェーズ: 時間課金（人月）＋ Software Factory 利用料
構築・運用フェーズ: 月額マネージド料金＋従量 AI 利用料＋ SLA

Requirements と Blueprints が Software Factory 内に蓄積されるので、フェーズ境界で成果物が「文書 PDF」ではなく「構造化された知識グラフ」として引き継がれる点が、国内 SIer の多段階契約との相性では利点になります。

チャネルは Big 4 と大手 SIer の両取りを考える

8090 の EY 提携は、「コンサルの流通網を敵に回さない」という意思決定で、EY の既存案件に Software Factory を載せて売る経路になっています。日本で類似の立ち位置を作るなら、候補は次の 3 系統です。

EY Japan・デロイトトーマツ・PwC Japan・KPMG Japan の Big 4 系。EY は本家 PDLC と直接連動させやすい
NTT データ・野村総合研究所・日立・富士通・NEC・BIPROGY 等の国産大手 SIer。すでに持っている基幹案件のモダナイズに乗せる
業界特化 SIer・コンサル（金融・医療・公共）: ドメイン知識と Software Factory の組み合わせで入り込む

いずれにしても、「Software Factory を自分たちのデリバリーに組み込むと、人月のまま売上を増やしつつ粗利が改善する」というストーリーを、相手の PL で説明できる形にしておく必要があります。

言語・LLM・インフラの選択で避けられない論点

日本語環境で動かすときに、Software Factory 型のアーキテクチャには次の論点が追加で乗ります。

要件・設計の日本語品質: Requirements と Blueprints は日本語で書かれるので、Claude、GPT、Gemini の各最新世代など、日本語性能の高いモデルを前提にする必要があります。日本語の要件・設計を処理する精度とコストはモデルごとに違うため、モデルを切り替えられる構成の必要性は米国より高くなります。
データ主権・金融 FISC・医療 3 省 2 ガイドライン: FISC 安全対策基準、医療情報システムの安全管理に関するガイドライン、政府情報システム向け ISMAP などに合わせたインフラ選定（AWS 東京・大阪、Azure Japan East、さくらインターネットのガバメントクラウド領域）が、Enterprise 案件の必須条件になります。
コード・プロンプトの学習利用条件: 米 8090 の規約ではユーザーコンテンツをモデル改善に使える条項がありますが、金融・公共の調達では「学習に利用しない」契約（案件によってはゼロデータリテンション）が必要です。製品の初期からこの条項を Enterprise 側で選べる形にしておく必要があります。

どこから始めるか

ゼロから日本版 Software Factory を立ち上げるとすれば、現実的なのは「自社の受託案件で先に Software Factory 相当を使い倒し、そこから製品化する」順序です。8090 自身も Software Factory で自社の Enterprise デリバリーを回しており、ドッグフーディングが製品精度を決めます。

具体的には、次の順で積み上げるのが素直です。

自社で請けている 1〜2 本の基幹刷新案件を、Requirements → Blueprints → Work Orders → Tests → Feedback の構造に沿って運用する。既存の Jira・Backlog・Notion に機能を足すのではなく、知識グラフを中心に組み直す
MCP サーバーを書き、Cursor・Claude Code・Codex から Work Order を実行できるようにする。IDE は現場の好みに任せる
2〜3 業界に閉じた Blueprint テンプレートと評価データを溜める。ここで業界別の再利用率が立ち上がる
Big 4・国産 SIer と組み、相手のデリバリー組織から Software Factory を呼べるチャネルを作る

逆に、順序を入れ替えて「製品を先に出して、受託で売る」からスタートすると、評価データも業界プレイブックも手元にないまま人月商流に押し戻されやすいです。8090 は CMS・BISSELL 等のレガシー刷新案件の実績を示したうえでシリーズ A を調達しています。

デイリースタンドアップやチームミーティングで議題にするなら、「どの案件を先行事例にするか」「どの業界で最初の Blueprint テンプレートを作るか」「Big 4 と国産 SIer のどちらを先に口説くか」の 3 点を具体化すると、2026 年中のロードマップに乗せやすいと思います。

以上、8090 のビジネスモデルを一次情報から整理し、同じ構造を日本で組み立てるなら何から始めるかを考えた、現場からお送りしました。

サイト内検索