AI事業開発の進め方｜90日で売上創造の循環を作る4ステップ

AI事業開発は、半年〜1年のPoCでは成立しない。書籍『AI収益進化論』が提示する AX for Revenue Loop は、90日サイクルで4ステップ（AI Sprint → Plateau Detection → PI Injection → 収益構造の再設計）を回し続ける実装メソドロジーである。本記事は各ステップの設計と運用方法、3つの前提条件、3つの落とし穴を示す。

AIは効率化から、収益の創造へ。この移行を実装可能な形に落とし込んだものが、AX for Revenue Loop である。本記事は、AI事業開発を「どう進めるか」を問う経営者・事業責任者向けに、90日サイクルで回す4ステップの設計と運用を体系的に整理する。

なぜAI事業開発は「90日サイクル」でなければ機能しないのか

AI事業開発を半年〜1年のPoC（概念実証）として進めた場合、ほぼ確実に頭打ちが訪れる。McKinsey の State of AI 2025 は、AIを少なくとも1業務機能で常用する企業が88%に達した一方、全社スケールに到達した企業は約3分の1に留まり、EBIT影響を実感する企業は39%、そのうちEBITの5%以上をAI起因と認識する企業はわずか6%だと整理する。世界中の経営層がAIに投資しているのに、事業の収益構造に届いていない。BCG の AI Radar 2025（n=1,803）も、経営層の75%がAIをトップ3の戦略的優先事項に挙げる一方、AIから significant value を得ている企業は25%に留まると報告する。

この乖離は、サイクル設計の問題でもある。半年〜1年のPoCは、仕様を確定してから検証する設計であり、Completion Cost Collapse（完成品構築コストの崩壊）が起きた後の時代には合っていない。生成AIとAIコーディングの跳躍によって、完成品をぶつけて市場の反応を取りに行く時間軸（Ship-as-Validation）が成立した今、90日で仮説検証を一巡させる設計が現実的な選択肢になる。

AX for Revenue Loop は、効率化AIの延長線で組まれた半年〜1年サイクルとは別の射程に立つ方法論である。効率化AIによる業務改善の取り組み（AI受託開発の延長領域）は、それ自体として正しい仕事であり否定すべきものではない。一方、収益進化AI、すなわち「まだ存在しない型を作る」領域（効率化AIと収益進化AI）に踏み込むためには、別のサイクル設計が要求される。90日サイクルは、その別の射程に踏み込むための時間軸である（麻生要一『AI収益進化論』第7章）。

AX for Revenue Loop とは何か ── 90日4ステップ循環構造の全体像

AX for Revenue Loopとは、書籍『AI収益進化論』が提示するAI事業開発の中核方法論である。4つのステップで構成される。

1. AI Sprint：AIを使い倒して性能水準まで到達する
2. Plateau Detection：頭打ちの景色を認める
3. PI Injection：人にしか持ち得ない知性を注入する
4. 収益構造の再設計：事業の質的変容を定着させる

最大の特徴は、4ステップが「直線」ではなく「循環」する構造である点にある。Step 4 の収益構造の再設計は、次のサイクルのStep 1 の起点となり、新たな仮説検証が始まる。1サイクル90日 × 年4サイクル × 3〜5年で、12〜20回のループ実装が積み重なる。

90日という時間軸は、経営判断可能な最短サイクルとして設計されている。これより短いと、Sprint の反復回数が確保できず、性能水準まで到達しない。これより長いと、市場の変化と経営判断のリズムから外れる。なお、この4ステップ構造はAX for Revenue Loop 実装の手順でも詳述されているが、本記事は各ステップの設計と運用方法に集中する。

なお、AX for Revenue Loop が完全な形（Step 1〜4）で適用されるのは、プロフィットセンター型テーマ（営業活動、マーケティング、商品・サービス開発、顧客接点運営等）に限られる。コストセンター型テーマ（議事録AI化、経理処理AI化等）では、Step 1〜2 で完結し、Step 3〜4 は構造上存在しない（コストセンター型テーマとプロフィットセンター型テーマの違い）。本記事は、プロフィットセンター型テーマでの実装を主に想定して整理する。

4ステップの設計と運用方法

ステップ①｜AI Sprint ── AIを使い倒して性能水準まで到達する

目的： AIに大量のデータと議論を投入し、対象業務領域での性能水準まで到達させる。

起点： AI受託開発の「仕様確定後に開発」とは逆の発想に立つ。仕様自体を Sprint で発見・書き換えていく。発注時点で仕様が固まっていることは、Sprint の前提ではない（AI事業開発とAI受託開発の違い）。

方法論： 10〜50回の反復で、新しいデータの取得と投入、プロンプトと運用設計の書き換えを繰り返す。1回あたり1〜2日で1反復を回す前提で組む。反復のたびに「何が見えたか」「次に何を試すか」を言語化し、次の反復に持ち越す。

設計要素：

• テーマ選定：プロフィットセンター型テーマか、コストセンター型テーマか
• 期間設定：2〜4週間を1Sprint の標準とする
• 参加者編成：AXアーキテクト + 実務メンバー + 経営層
• 反復回数の目安：10〜50回（テーマの複雑さに応じる）

発散と収束の設計： Sprint の前半は議論を発散させ、AIに投入するデータと問いの幅を広げる。後半は1つの方向に収束させ、性能水準を測定可能な状態に追い込む。発散だけでは Sprint が終わらず、収束だけでは AIの可能性を取り逃がす。

落とし穴： 1〜2回の試行で「AIは使えない」と判断してしまう／反復を続ける制限時間内の持久力を組織が許容しない／参加者が AIに食わせるデータを「整った社内文書」だけに絞ってしまう。

出力： 性能水準まで到達したAI活用プロトタイプ／そしてその先に必ず現れる Plateau（頭打ち）の景色。

詳細はAI Sprintとは何かを参照。

ステップ②｜Plateau Detection ── 頭打ちの景色を認める

目的： AI Sprint で到達した性能の頭打ち（Plateau）を認め、次のステップに進む経営判断を行う。

起点： AI Sprint を続けても性能が上がらない地点が必ず訪れる。これは AlphaDrive 固有の現象ではなく、世界中で観測されている構造である。Gartner は、2027年末までに40%超の Agentic AI プロジェクトがキャンセルされると予測し、その理由を「不明確なビジネス価値」「不十分なリスク統制」「コスト増大」に整理している。Plateau は、AI事業開発の例外ではなく標準的な到達点である。

方法論： Plateau を「失敗」ではなく「次のステップへの境界線」として認識する。経営層と事業責任者が率直に向き合い、「効率化の延長線では、もうこれ以上は伸びない」と認める作業が中心となる。データ分析作業より、覚悟の作業の比重が大きい（麻生要一『AI収益進化論』第7-3章）。

4類型の認識： Plateau Detectionの現場では、Plateau が4つの類型に分かれる。Type A（既存業務領域での性能頭打ち）、Type B（投資配分の限界）、Type C（市場構造由来の伴走能力不足型）、Type D（領域誤認＝AIを持ち込む場所を間違えた状態）である。書籍が段階3で整理する4症状（PoC地獄／ROI定義困難／ベンダー依存／現場との断絶）は、特に Type C の臨床所見として再整理される。

落とし穴： Plateau に達したことを「失敗」と判断して撤退する／Plateau を認めず Sprint を延々と続ける／Plateau の景色を経営層が見ようとせず、現場に「もっと頑張れ」と差し戻す。

出力： Plateau の構造分析／PI Injection への移行判断、または別テーマへの再着手判断。

Plateau はテーマ単位で発生する現象であり、会社全体が一斉に Plateau に達するわけではない（AXFR-OS Knowledge Pack v1.0 §3）。

ステップ③｜PI Injection ── 人にしか持ち得ない知性を注入する

目的： AIが学習データを持ち得ないPI（Primal Intelligence）を発掘し、AIに注入する。PI = Field Intelligence + Crazy Intelligence の2要素で構成される。

起点： Plateau の壁は、AIが学習データを持っていない領域にこそ存在する。Sprint をどれだけ反復しても、AIが学習していない情報は AIから出てこない。AIに見えない領域に、経営者と現場が降りていく作業が必要になる。

方法論：

1. Human Areaでの Field Intelligence の発掘（顧客との対話、現場の観察、商談・懇親会、業界の暗黙知）
2. Crazy Intelligence の取り込み（とっぴな発想、業界外からのアイデア、エキセントリックな視点）
3. 発掘した PI のデジタル化（言語化・構造化・記録）
4. AIへの注入（Knowledge層とInstruction層の書き換え）

絞り込みの原則： PI Injection で探すべきは、なんでもかんでもの Crazy や Field ではない。「これまで見過ごされてきたが、じつは大きな可能性を秘めたアイディアや現場情報」だけである（麻生要一『AI収益進化論』第7-4章）。経営者のセンスで何が金脈候補かを選び取る作業が中心となる。

落とし穴： FI を「市場調査」「業界レポート」で代替しようとする／CI を排除して論理的整合性だけで進めようとする／経営者が現場に降りず、現場の Field が経営者まで上がってこない（信頼関係問題）／業務工程に組み込まずに発掘で終わってしまう。

出力： AIに注入された PI／AIの性能の質的進化（次のレベルへの突破）／次の Sprint の起点となる新たな仮説。

なお、PI Injection の具体的な実装手順（FI をどの順番でAIに投入するか等）は、自社固有の FI の質と、調達される CI の組み合わせに最適化されるため、一般化された手順は機能しない。実装支援を必要とする場合は、個別の対話で設計する領域となる。

ステップ④｜収益構造の再設計 ── 事業の質的変容を定着させる

目的： AI Sprint と PI Injection で得られた成果を、収益構造そのものの再設計として組織に定着させる。

起点： 個別プロジェクトの成果を、事業構造の再設計まで昇華させない限り、Loop は完成しない。Sprint と PI Injection で見えた N=1 の兆しを、繰り返し再現可能なモデルに変換する作業が必要になる。

方法論：

1. 収益進化の3パターンの判定 ──「誰に・何を・どう売るか」のうち、少なくとも一つが非連続に書き換わったか
2. 既存事業との接続/分離の設計 ── 既存事業の進化として組み込むか、別事業として分離するか
3. 組織体制の再設計 ── CAXOの関与、AXアーキテクトのアサインメント、KPI・予算・評価制度の書き換え

3つのパターン： ①「誰に」の非連続書き換え（対象市場の拡張）、②「何を」の非連続書き換え（プロダクト価値の構造転換）、③「どう売るか」の非連続書き換え（収益化方式の転換）。複数同時に起こることもある。

重要な区別： 業務再設計や KPI 再定義は、Plateau 内の連続的な改善であり、ここで言う収益進化（収益構造の再設計）ではない。Step 4 は、事業の組み立て方そのものを書き換える行為として整理される。

落とし穴： 個別プロジェクトの成果で満足してしまう／収益構造の再設計まで踏み込まず、効率化の山に戻ってしまう／事業部長レベルで止まり、経営者が判断に関与しない。

出力： 新たな収益構造／次の90日サイクルへの問い（次の Sprint の起点）／組織に蓄積された Loop 回しの経験。

4ステップが「循環」する理由 ── なぜ単発で終わらないのか

AX for Revenue Loop の核心は、4ステップが循環する点にある。Step 4 の収益構造の再設計は、次のサイクルの Step 1 の起点になる。再設計された収益構造のもとで、新たな仮説検証が始まり、新たな Plateau が現れ、新たな PI Injection が要求される。

単発のAI導入（直線構造）では、AI事業開発は完成しない。1回 Loop を回しただけで「AI事業開発が終わった」と判断するのは、収益進化の山を1合目で「登頂した」と判断するのと同じ構造的誤りに陥る。

90日サイクルを繰り返すことで、3〜5年後に「収益構造が継続的に進化する組織」が形成される。1サイクル90日 × 年4サイクル × 3〜5年 = 12〜20回のループ実装。この蓄積が、書籍が効率化AIと収益進化AIの二分法で示した「収益進化AI」を組織能力として定着させる。

事業開発の Loop と人材育成の循環は、両輪として実装される。Loop を回す担い手が育っていなければ、Loop は止まる。担い手だけが育って Loop が回っていなければ、能力は事業に接続しない。

AX for Revenue Loop を実装するための3つの前提条件

前提①｜AXアーキテクトの存在

4ステップを回す担い手として、ビジネスアーキテクト能力 × AI能力を併せ持つAXアーキテクトが必須である。外部受託ベンダーだけでは Loop を回せない。Loop は社内の事業と一次情報に深く接続して回るプロセスのため、社内側にAXアーキテクトが存在しないと構造的に成立しない。

なお、AXアーキテクトは社内に最初から存在している必要はない。発掘・育成・自走化のプロセスを通じて立ち上げる前提で組む。

前提②｜経営層（CAXO）の関与

90日サイクルでの経営判断、テーマ選定、アサインメント、予算配分に経営層の関与が必須である。「半年後に成果報告」ではなく「90日ごとに経営判断」を許容する経営体制が、Loop を回す前提条件となる。

書籍は、Step 4 の収益構造の再設計について「経営者本人が必ず関与する。事業部長レベルでは踏み込めないことが多い」と整理する（麻生要一『AI収益進化論』第7-5章）。AI Transformation を統括する責任を負うCAXO（Chief AI Transformation Officer）が、Loop の各サイクルの判断に関与する体制を組む必要がある。

前提③｜領域選別の理解（3領域モデル）

AX for Revenue Loop は「AX Area」（AIで進化する業務領域）で回す方法論である。DX Area（業務のデジタル化が主目的の領域）や Human Area（AIで進化しない関係構築・経営判断等の領域）に Loop を持ち込もうとすると、構造的に機能しない（領域誤認）。

Loop を始める前に、自社の業務領域のどこが AX Area にあたるかの選別が必要となる。この選別を飛ばすと、Step 1 の AI Sprint がそもそも空回りする。

AX for Revenue Loop の落とし穴と回避策

落とし穴①｜Step 1 AI Sprint を「PoC」と同じものと誤解する

PoC（概念実証）は、仕様確定後の検証である。仕様が決まった状態で、その仕様が動くかどうかを試す。AI Sprint は、仕様自体を反復のなかで発見するプロセスである。両者を混同すると、Sprint が PoC 化してしまい、頭打ちが訪れない（仕様が固定されているため、性能の頭打ち＝Plateau ではなく、仕様の頭打ちで終わる）。

回避策：Sprint の前提として「仕様は Sprint のなかで書き換えられる」ことを参加者全員に明示する。発注時点で仕様を固めない設計を取る。

落とし穴②｜Step 2 Plateau Detection を省略する

Plateau を認めずに Sprint を延々と続けると、PI Injection に進めない。「もっとAIを頑張れば突破できる」という思考停止に陥り、Sprint の反復だけが積み重なる。Plateau の景色を経営判断として認める勇気が、Loop を次に進めるための分岐点となる。

回避策：Sprint の終了基準を事前に設計する。「反復30回で性能が頭打ちなら、Plateau と判定して次のステップへ」のように、判定基準を経営層と合意しておく。

落とし穴③｜Step 3 PI Injection を市場調査で代替する

PI は、Human Area での顧客対話・現場観察・とっぴな発想からしか発掘されない。市場調査・業界レポート・ベンチマーク調査では PI Injection は成立しない。これらは「すでに言語化された情報」であり、定義上 PI ではないからである。

回避策：PI Injection のサイクルに、必ず経営者本人が現場に降りる時間を組み込む。商談同席、顧客訪問、現場での観察、社外の異分野との対話を Loop の活動として明示的に位置付ける。詳細はPI Injectionとは何かを参照。

関連する AX for Revenue の概念

本記事と関連する記事として、以下が公開されている。

• 方法論の全体像：AX for Revenue Loop とは何か／AX for Revenue Loop 実装の手順
• 各ステップの深掘り：AI Sprint／Plateau Detection／PI Injection／収益構造の再設計
• Plateau の構造：Plateau 4類型／Plateau Type C／段階3の4症状
• PI と関連概念：PI（Primal Intelligence）／Field Intelligence／Crazy Intelligence
• 収益進化の構造：収益進化の3パターン／効率化AIと収益進化AI／2つの山モデル
• 時代背景：Completion Cost Collapse／Ship-as-Validation／AI Orchestration／Full-Product Launch
• 担い手と体制：AXアーキテクト／CAXO
• 領域選別：領域誤認／Human Area／100倍化
• AI事業開発カテゴリの関連記事：AIの事業開発に強い会社の見極め方／AI事業開発とAI受託開発の違い
• 人材育成プロセスとの並列構造：AI時代の人材育成の進め方

よくある質問

Q1：90日サイクルは厳守すべきか？短くても長くてもダメなのか？

90日は標準値であり、絶対値ではない。テーマの性質によっては60日や120日もありうる。重要なのは、半年〜1年の長いサイクルでは、Sprint の反復回数を確保しつつ経営判断のリズムと噛み合わせることが難しい点にある。逆に30日では Sprint の反復が不足し、Plateau まで到達しないまま終わる。経営判断の頻度と Sprint の反復回数の両方を確保できる時間軸が、結果として90日前後に落ち着くことが多い。

Q2：AX for Revenue Loop は、何人規模のチームで回すのか？

1サイクルを回すコアチームは、AXアーキテクト1〜2名、実務メンバー2〜4名、経営層1名の合計5〜7名が標準である。これより大規模になると、90日サイクルでの意思決定速度が落ちる。これより小規模になると、Sprint と PI Injection の作業負荷を担いきれない。なお、コアチームの外側に、現場の協力者・経営層全体・社外の対話相手などが取り囲む構造になる。

Q3：AI Sprint と AI PoC は何が違うのか？

PoC は仕様確定後の検証である。仕様が決まった状態で、その仕様が動くかどうかを試す。AI Sprint は、仕様自体を反復のなかで発見・書き換えていくプロセスである。PoC が「決まったものを試す」のに対し、Sprint は「まだ決まっていないものを Sprint のなかで決めていく」。両者を混同すると、Sprint が PoC 化してしまい、頭打ちが Plateau ではなく仕様の頭打ちで終わる。詳細はAI Sprint とは何かを参照。

Q4：AX for Revenue Loop は、効率化AIの取り組みにも適用できるのか？

部分的に適用可能だが、構造が異なる。コストセンター型テーマ（議事録AI化、経理処理AI化等）では、Step 1（AI Sprint）と Step 2（Plateau Detection）で完結し、Step 3（PI Injection）と Step 4（収益構造の再設計）は構造上存在しない。やり切ったら次のテーマに移行する運用となる。プロフィットセンター型テーマ（営業活動、商品開発、顧客接点運営等）では、Step 1〜4 すべてが展開される。詳細はコストセンター型テーマとプロフィットセンター型テーマの違いを参照。

Q5：AX for Revenue Loop を実装するために、まず何から始めるべきか？

3つの前提条件のうち、自社にどれが欠けているかの整理から始めるのが現実的である。AXアーキテクトが社内に存在しないなら、発掘・育成の設計から。経営層の関与体制が組まれていないなら、CAXO 機能の設計から。領域選別ができていないなら、自社の業務領域のどこが AX Area にあたるかの整理から。3つすべてが揃っている前提で Step 1 から始める企業は、実務上ほとんど存在しない。Loop の前段として、前提条件の整備から始めることが多い。

---

発行：株式会社アルファドライブ

AlphaDrive は、260社を超える大企業の事業創出と、23,800を超える事業プロジェクトの伴走を通じて、AI Transformation for Revenue（収益進化AIシステム）の方法論を体系化してきた。本記事は、書籍『AI収益進化論』（麻生要一、株式会社Ambitions、2026年5月）第7章を理論的支柱とする。