Lean Analyticsを、AIとエージェント時代に合わせて見直す

• 2013年に刊行された Lean Analytics の中核フレームワーク（段階の把握、ビジネスモデルの理解、OMTM、ベンチマーク）は今なお有効だが、AI時代に合わせて具体的な指標の大半は再定義が必要
• AIプロダクトでは**価値到達時間（Time to Value）**が極端に短縮され、ユーザーは最初の試行で高品質な結果を期待し、失敗するとすぐに離脱する
• エンゲージメントは単に高い・低いではなく、時間が何に使われているか（悪戦苦闘、AIの作業、探索）を区別すべき方向性指標へと転換
• AIの確率的な出力特性により、品質が第一級の指標となり、評価ハーネス（eval harness）なしではプロダクトではなく「雰囲気（vibes）」にすぎない
• トークンベースの変動費構造により、パワーユーザーがかえって損失を生む可能性があり、アクティブユーザー基準の売上総利益の追跡と成果ベースの価格モデルが中核課題

---

Lean Analytics の核心原則まとめ

• Lean Analytics は4つの中核アイデアを基盤に構成される: 段階の把握、ビジネスモデルの理解、OMTM（One Metric That Matters）、ベンチマーク（lines in the sand）
• 5段階モデル: Empathy → Stickiness → Virality → Revenue → Scale の順で、あらゆるビジネスがたどる過程
  • 多くの起業家は自分の段階をごまかし、堅固な土台なしにホッケースティック成長を追い求める傾向があり、これはAI時代でも同じ
• 6つのビジネスモデルのアーキタイプ: SaaS、e-commerce、両面マーケットプレイス、ユーザー生成コンテンツ/コミュニティ、モバイルアプリ、メディア
  • この分類は古びているが、自社ビジネスがどう機能するかを把握するという原則自体は依然として重要
• OMTM: どの段階でも、どのビジネスモデルでも、集中すべき単一の指標が存在する
  • すべてを同時に直すことはできないため、何に取り組み、どう測定するかを特定するのに役立つ
• ベンチマーク（lines in the sand）: 次の段階へ進む資格を得たかどうかを示す基準
  • AIおよびエージェント製品では、指標と目標値が急速に変動している

AI時代でも変わらないこと

• 核心原則は変わらないが、今日構築されているビジネスは根本的に異なる
• AIがユーザーインターフェース、価格モデル、利益率などを変化させ、AIファーストおよびエージェント製品は利用のされ方自体が異なる
• 5段階モデルがなくなったわけではないが、各段階に疑問符が付く — 既存の指標と新しい指標を統合して各段階を再定義する必要がある

製品指標: 6つの重要な変化

• Shift 1: 価値到達時間（Time to Value）の崩壊

  • 従来のSaaSでは段階的なオンボーディングを経て価値を体験していたが、AI製品ではユーザーは即座に高品質な結果を期待する
    • 雑然とした文書を入れれば整った提案書を、スプレッドシートをアップロードすれば分析結果を、ワイヤーフレームのスケッチを入れれば動作するUIを期待する
    • 入力方法は多様でも期待は一貫している: 速く高品質な出力を、最初の試行で
  • 習熟到達時間（Time to Competency） も同時に崩壊する — 非技術ユーザーでも学習曲線なしに専門家レベルの成果物を作れる
    • 従来のアクティベーション曲線が学習曲線だったとすれば、今は1〜2回のインタラクションへと短縮される
  • これは好ましい一方で、ビジネスモデルには悪影響を及ぼす可能性がある: 1人がAIで3人分の仕事をこなせるなら、シート数、拡張売上、ACV曲線に打撃が及ぶ
    • 満足したユーザー、少ないシート — この緊張関係はShift 1で始まり、下流のあらゆる指標に波及する
  • 測定対象: 最初の有用な結果に至るまでの時間、1回の試行で有用な結果を得るユーザー比率（プロンプト・アップロード・スケッチを問わない）

• Shift 2: アクティベーション（Activation）はもはや決定打ではない

  • 従来のSaaSでアクティベーションは決定的（deterministic）なイベントだった — ユーザーが定められたステップを完了すれば予測可能な結果が出た
  • AI製品では、アクティベーションファネルの全ステップを完了しても不十分な結果を受け取ることがある
    • ダッシュボード上ではアクティベーション済みと表示されても、実際にはそうではない状態だ
  • アクティベーションは二値のゲートではなく、品質で重み付けされたイベントである
  • Nir EyalのHookedモデル（トリガー → 行動 → 可変報酬 → 投資）は依然として当てはまるが、AIループでは行動の両側に変動性が存在する
    • ユーザーは設計者が想定しない方法で製品を試し、結果の品質も変動する — 単一ループに2つの変動要因がある
  • 複合的で多段階のアクティベーションはAI製品でも有効だ — コンテキストの接続、参考資料のアップロード、テンプレート構成など、設定が初回実行の品質を高める場合にはむしろ効果的である
    • 核心的な変化は「アクティベーションが短くなった」ことではなく、ステップ完了が価値提供を保証しないことだ
  • 測定対象: 従来のファネル完了指標とあわせて、Shift 1の初回品質シグナルを並行して追跡する — ファネルはステップ完了を、品質シグナルは実際に価値が提供されたかを示し、ダッシュボード上で並べて表示すべきである

• Shift 3: エンゲージメントは方向性の指標

  • 従来の常識では、製品内の滞在時間が長いほどよい — 長いセッション、高いDAU、深い機能利用が投資家向け資料に含まれていた
  • AIでは、エンゲージメントの増減ではなくユーザーの時間が何に使われているのかが重要な問いになる
    • 悪戦苦闘の時間（再生成、再プロンプト、有用な結果を得るための入力調整） = 悪いエンゲージメント、失敗がエンゲージメントとして装われたもの
    • AIがユーザーの代わりに作業している時間（スプレッドシート操作、提案書作成、文書レビュー） = 良いエンゲージメント、AIの労働を示す
    • 探索・創作の時間（ブレインストーミング、アイデア創出、デザインの反復） = 良いエンゲージメント、従来の直感がそのまま当てはまる
    • ユーザー時間ゼロで作業完了 = エージェント・自動化製品における理想的な結果
  • GitHub Copilotは提案受諾率を主要指標として見ており、業界全体では約**27〜30%**の水準にある
    • これは従来のSaaSにはなかったKPIで、「ユーザーがとどまったか」ではなく**「AIの作業が有用だったか」**を直接測定する

• Shift 4: スティッキネス（Stickiness）は障壁ではなくフロー（Flow）

  • 従来のスティッキネスは頻度のゲーム（DAU/MAU、再訪、習慣ループ）であり、Andrew ChenはDAU/MAUの限界を指摘していた — エピソディックだが高価値な製品や、週次リズムのツールには不向きである
  • AIはDAU/MAUをなくしはしないが、既存の限界を増幅する
  • 2つのことが同時に起きる:
    • ユーザーは従来の単機能SaaSツールよりもAI製品により多様な作業を期待する — ユーザーごとのタスク多様性（task diversity per user） が、これまでになかった成長ベクトルになる
    • スティッキーなAI製品とは、ユーザーを閉じ込める障壁ではなく作業フローの中に存在するものだ — Trace Cohenの「Moats are dead. Long live canals」という概念と一致する
      • 「堀は排除によって拡張し、運河はスループットによって拡張する」
  • 測定対象:
    • タスク多様性 — ユーザーが製品を本来の範囲外のユースケースへ拡張しているかどうか
    • 統合の深さ — ユーザーのツールやデータソースが製品にいくつ接続されているか
    • トリガー多様性 — ユーザーを再訪させる要因が1つか複数か
    • ワークフローチェイニング — 製品が他ツールへハンドオフしているか、または他ツールからハンドオフを受けているか
  • 人間が主なユーザーでなくなると、従来のDAU/MAUは問題のある指標になる
  • 代替の広がり（replacement breadth） という追加指標: 顧客が製品を採用した際に置き換えた隣接ツール・サブスクリプション・手動プロセスの数
    • その答えが0なら迂回可能な小さな運河であり、意味のある数値ならあらゆるものが通る経路である

• Shift 5: 品質が第一級（First-Class）の指標になる

  • Shift 2と同じ根本原因: AI出力は決定的ではなく確率的である — この変化はSaaSのプレイブックから受け継いだあらゆる指標に波及する
  • 従来は、機能が動くか動かないかだった — デプロイ後に計測して次へ進めばよかった
  • AIの現実: 出力は属性ではなく分布 — 80%良い製品と95%良い製品は、ユーザーにはまったく別物として感じられる
  • Klarnaの事例: 2024年にAI専用のカスタマーサポートを導入した後、AIが700人の相談員の業務を担っていると主張したが、2025年半ばにCEOが公に撤回し、人間の採用を再開した
  • 脆さ（brittleness） — 品質が自社で所有していないモデル、ほとんど制御できない統合、上流プロバイダーのアップデートによって、サイレントに劣化する可能性がある
    • チームがコードに触れていなくても品質は低下しうる — 新しいリスクのカテゴリーだ
  • 防御策: 実際のプロンプトに対してモデル間の比較評価を行い、すべてのモデルに同じevalを実行して劣化と改善を検知する
  • 測定対象:
    • 高評価率（thumbs-up rate） と 再生成率（regenerate rate） が主要シグナル
    • evalハーネスのスコアをリテンションのように時系列で追跡し、利用しているすべてのモデルに適用する
    • コホート別の品質分布 — 新規ユーザーとパワーユーザーでは製品体験が異なり、多くのチームはこの差を測定していない
  • Alistair Crollの見方では、Lean Startup時代のMVPが最も危険な仮説を検証する最小実験だったとすれば、AI時代にはevalスイートこそがMVPである — 「改善を自動化して測定できる最小の行動セット」

• Shift 6: AIに対する信頼と安心感が先行指標

  • 技術的な習熟度は常に重要だったが、AIでは技術そのものに対する安心感のレベルが変数となり、すべての下流指標に影響する
  • Gallupの2026年2月の調査（米国の従業員23,717人）: AI採用者と非採用者を分けるのはツールへのアクセス性ではなく、AIを有用で倫理的であり、自分のワークフローに適していると見なしているかどうかである
  • Stanford 2026 AI Index Report: グローバルの従業員採用率は58%、米国は28.3%で、Singaporeの61%、UAEの54%に大きく後れを取っている
    • 同じ製品が劇的に異なるユーザー集団の上に存在しうるが、ほとんどのチームはこれを測定していない
  • B2Bでは、AIネイティブなユーザーとAIに慎重なユーザーの間でアクティベーション・スティッキネス・タスク多様性の曲線が有意に異なる可能性がある
    • AIネイティブなユーザーはツールを拡張し、想定されていない方法でプロンプトし、セッション当たりでより多くの価値を得る
    • AIに慎重なユーザーは用心深くツールを十分に使わず、「これは自分には合わない」と静かに結論づける
    • 単一コホートとして測定すると、平均値が実際の物語を隠してしまう
  • B2Cでは、伴侶、メンタルヘルス支援、友情、感情的ウェルビーイングの製品が実際のカテゴリーとして浮上している

• Stanfordのデータ: グローバル回答者の52%がAIコンパニオンに期待感を示し、SingaporeとIndonesiaでは80%超

  • この文脈では、価値創出はユーザーの継続的な参加・対話・感情的相互作用の意思で測定される
  • 信頼は単一の概念ではなく、少なくとも4つの独立した次元から成る:
    • 出力への信頼（正確性・有用性）、データ処理への信頼（プロンプトの行き先）、セキュリティへの信頼（悪用・漏えいの可能性）、信頼性への信頼（依存したときに困らないか）
  • 測定対象:
    • AIへの安心感コホート別の採用・アクティベーション曲線
    • 受諾率（accept rate） — AIへの安心感コホート別に分析すると、信頼構築の速度を把握でき、絶対値よりも曲線の傾きが重要
    • オーバーライド率（override rate） — ユーザーがAIの結果を書き直し・編集する頻度で、低下は信頼上昇のシグナル
    • 感情的に親密なB2C製品: セッションの深さ、センシティブな機能の復帰率、相互作用の質的トーン
    • データ・セキュリティ懸念のシグナル: 機能のオプトアウト、"これはどこに行くのですか?"というサポートチケット、センシティブな入力の回避利用

ビジネスモデル指標: 3つの重要な変化

• Shift 1: 成功タスクあたりのコストが新しいCAC計算になる

  • 従来のSaaS: CAC、LTV、粗利は顧客ごとに比較的安定しており、規模が大きくなるほどコストは低下し、ユーザー追加の限界費用はほぼゼロ
  • AIの現実: パワーユーザーが実際にコストを発生させる — トークンは変動費であり、定額サブスクリプション + ヘビーユーザー = アカウントあたりマイナスマージン
    • SaaSのLTV曲線は成立せず、利用量が増えるほどユニットエコノミクスが悪化する逆方向の構造
  • 測定対象: アクティブユーザーあたりの粗利（課金ユーザーではなくアクティブユーザーベース）、成功タスクあたりのコスト、売上に対するモデルコスト比率、パワーユーザーの限界費用対限界収益
  • IntercomのFin: シート課金ではなく成功した解決ごとに$0.99 — 成果ベースの価格設定により、AI製品の実際の運用コストに数学的に正直なモデル
  • ElevenLabsは初日から従量課金を採用し、AnthropicとOpenAIはコンシューマー向けサブスクリプション経済と公然と格闘している
  • 価格設定と指標が変動するコンピュートコストを反映していなければ、視界がない状態に等しい

• Shift 2: 価格設定が製品を決める

  • 従量課金・成果ベース課金はまだ初期段階にあり、ハイブリッドモデル（低い月額固定 + 使用量 + 超過分）が大半のAI製品の最終形になる可能性が高い
  • 価格モデルはユーザーに成功の定義を伝える — 基礎となるユニットエコノミクスと一致していなければならず、不一致ならマージンの消耗か成長の制約（あるいはその両方）を招く
  • 「月額$20でAIクエリ無制限」と「成功結果ごとに$0.99」は、単に価格モデルが違うだけではなく、ユーザー視点ではまったく別の製品
    • 前者は「自由に試してほしい、学習コストはこちらが負担する」
    • 後者は「あなたが勝つときだけ、私たちも勝つ」
  • これまで多くのPMは価格設定を深く考える必要がなかったが、AIネイティブPMは価格を製品設計の中核として扱わなければならない
  • AI機能は従来のSaaS機能とは異なり、実行コストが安くない — 高価なのにユーザー価値が大きくないAI機能は、全体を台無しにしかねない

• Shift 3: 実験はもはや虚栄指標ではない

  • AIベースの製品開発によってデプロイ速度が爆発的に向上 — 機能リリースコストが崩壊
  • より速くリリースしながら実際の実験をしないなら、それは**「バイブ・スタッフィング(vibe-stuffing)」** — 証拠がないのに、できるからという理由で機能を追加する行為
    • ほとんどの機能は価値を生み出せず、製品とコードベースを肥大化させ、ユーザーの認知負荷を増やす
  • すべてのAI機能には利用のたびに継続的な呼び出しコストが発生する — 推論は無料ではない
    • バイブ・スタッフィングによる膨張は単なる複雑性ではなく、利用量に応じて複利的に増える税金
    • AI時代のプロダクト肥大化はマージンキラー
  • 堅牢な実験が唯一の防御策であり、Lean Analyticsの価値はむしろ高まっている
    • 指標の選択、仮説の作成、プレッシャーテスト、次の行動を決める規律が、学習するチームと単にリリースするだけのチームを分ける
  • 有用なフィルター: すべての実験についてリリース前の仮説と意思決定基準を記録する — そうでなければ、それは実験ではなくリリースだ
  • 測定対象: 四半期ごとの実験数、リリース前に記録された仮説、データに基づく機能の廃止、運用中の機能あたりコスト（使われているかどうかだけでなく、運用コストが正当化されるかどうか）

• 価値密度(Value Density)

  • 3つのビジネスモデル変化を貫く原則: Ben Murray（The SaaS CFO）の表現によれば、「SaaSがマージン効率の話なら、AIは価値密度の話であり、コンピュート1ドルあたりどれだけ多くのアウトプット・生産性・労働を代替できるかを最適化すること」
  • ICONIQ 2026年1月レポート: スケーリング段階のAI B2B企業では推論が売上の**23%**を占め、AI粗利率は2026年平均52%（2024年の41%から上昇したが、成熟したSaaSの70〜90%には届かない）
  • Bessemer: AIファースト企業の粗利率は50〜60%
  • Jason Lemkin: 「成長するほどより多くの推論が必要になり、製品品質を落とさずにそれを減らすことはできない」
  • 価値密度を測る3つの比率（それぞれ独立して動く）:
    • タスクあたりの提供コスト — 成功した成果物を生み出すのに、トークンとコンピュートにいくらかかるか
    • コンピュート1ドルあたりの獲得売上 — 変動費 + マージンを賄えるだけの課金ができているか
    • コンピュート1ドルあたりユーザーに届けた価値 — 大半のチームが見落とす指標であり、診断を機能させるには3つすべてを測定しなければならない

未来: ループから離れる人間

• 「作りすぎ(Build-too-much)」が新たなオーバーフィッティング

  • 作ることがあまりにも簡単になり、ユーザーが吸収できる以上、あるいはデータが裏づける以上のものをリリースしてしまう危険
  • Alistair Croll: AIは削除を強いていた摩擦を取り除いた — 古いコードは書き直しコストのために、古い機能は構築コストのために残っていたが、今では何も整理されなくなった
    • フォールバックが**「見えない耐力壁」**として蓄積し、AI生成テストは望ましい動作の検証ではなく自己通過に最適化される
    • 「削除は維持より危険に感じられ、摩擦がなければすべてが残る」
  • 追加と同じくらい慎重に削除を測定するPMが勝つ

• エージェントがユーザーであるとき

  • Claudeエージェントが人間の代わりにUIなしで製品を使うとき — 誰がユーザーなのか、アクティベーション・セッション長・エンゲージメントが何を意味するのかが不明確になる
  • 実務的な対応: エージェントトラフィックを別コホートとして計測する — user-agent文字列やAPIパターンなどで「人間がUIを操作する」と「エージェントがAPIを呼び出す」を区別する
    • 行動が異なり、成功基準も異なり、1つの指標に混ぜると両方にとって間違った答えになる
  • Rob Mayの**HX(Harness Experience)**という概念: 過去30年間、UXは人間に正しいボタンをクリックさせてきたが、自律エージェントはそれをすべて飛ばしてしまう
    • 「ファネルが壊れたのではなく、無関係になった」
    • HXはエージェント群を操縦・信頼・監査する人間のためのデザインレイヤー — ユーザーはドライバーではなくディレクター
    • クリックやコンバージョンではなく、結果・監督・介入を測定する

• 発見可能性(Discoverability)と再利用(Reuse)

  • 2つの問題、1つの根本原因: 自社が所有していないAIが製品を使うかどうかを決める
  • 発見可能性: ユーザーがChatGPTに「メキシコ旅行の計画を手伝って」と頼むと、ChatGPTがExpedia、Booking、Kayakの中から選ぶ — ユーザーではなくAIがツールを選択する
    • 30年間、流通は人間が見つけて選ぶようにすることだったが、エージェント世界ではAIの選択ロジックのために競争することになる
  • 再利用: ユーザーがCanvaを有料購読し、ChatGPTアプリをインストールしていても、ChatGPT経由でデザインを依頼すると、毎回AIがCanvaを呼ぶかどうかを決める
    • 顧客を「所有」していても、実際に価値が発生する瞬間を所有しているわけではない — 新たなプラットフォームリスク
  • 追跡対象: 「製品を所有または支払っているユーザー」と「AIが実際に呼び出したユーザー」の間のギャップ
    • AIが30日間呼び出していない有料購読者は、直接ログインしていない購読者よりも危険だ

• エージェント対エージェント製品

  • 製品が他者のエージェントと協調するエージェントネットワークであるとき — OMTM、スティッキネス、チャーンの意味はまだ不明確
  • Hookedモデルの4段階すべてに、5年前には存在しなかった問いが付随する:
    • AIがトリガーするときトリガーの意味、AIが行動するとき行動の意味、報酬を経験しない存在にどう報酬を与えるか、前のループの記憶がない、または完全な記憶を持つシステムにおいて投資が適用されるかどうか

今日からすぐに始めるべきこと

• エンゲージメント指標の監査: 「エンゲージメントが上下しているか」ではなく、「ユーザーの時間が何に使われているか」を問う — 悪戦苦闘の時間は、失敗がエンゲージメントとして包装されたもの
• コホート別の品質ビューを追加: 新規ユーザーとパワーユーザーの出力品質を分けて測定 — 差が予想より大きい可能性があり、オンボーディング改善のポイントを正確に示す
• アクティブユーザー当たりの売上総利益を確認: 課金ユーザーではなくアクティブユーザー基準 — 最良のユーザーが最高の資産なのか最大の負債なのかを、現在のダッシュボードでは把握できていない可能性
• エージェントトラフィックの別個計測を開始: 現在は2%だとしても、トラフィックの形が変わる前に ベースラインの確保 が必要
• evalハーネスを構築: AIが望ましい作業を実行しているかを体系的に評価できなければ、それは製品ではなく「勘（vibes）」
• 機能のビルド方法を評価: 厳密な実験を実行しているのか、それとも製品をバイブ・スタッフィングで殺しているのかを点検