目次を表示する

AIプロダクト統合のレベル分類

第2章 レベル分類の名付けと体系 ── 誰が、どう整理してきたか

第2章 レベル分類の名付けと体系 ── 誰が、どう整理してきたか

統一された分類がない理由

AIプロダクト統合のレベル分類には、業界共通の標準が存在しない。自動車の自動運転にはSAE J3016という国際規格があるが、AIプロダクトに相当するものは2026年時点でまだない。

代わりに、異なる文脈・目的から複数の分類が生まれ、互いに影響しあいながら収束しつつある。本章ではそれらを整理する。

主要な分類フレームワーク

1. SAEレベルの転用：自律性軸による分類

最も直感的な転用は、自動運転のSAEレベルをAIエージェントの自律性に適用するものだ。AI Native Dev（Tessl）、Swarmia などが採用している。

レベル名称制御の主体代表プロダクト
0No Automation人間がすべて従来のIDE
1AI AssistantAIが提案、人間が実行GitHub Copilot（補完）、ChatGPT
2Partial AutomationAIが実行、人間が常時監視Claude Code、Cursor Composer
3Conditional Autonomy定義された範囲でAIが自律、例外のみ人間Devin、GitHub Copilot Agent
4High AutonomyAIがほぼ自律、稀に人間が介入一部の自律エージェント（構築中）
5Full Autonomy人間の介入なし理論的（未実現）

特徴：シンプルで直感的。「制御責任の所在」という単一軸が明確。 弱点：開発ツールコンテキストで生まれており、エンタープライズ・SaaSプロダクトへの適用が難しい場合がある。

2. Copilot → Agent → Autonomous：役割軸による三段階

Microsoftを中心に広まった分類で、特にエンタープライズ文脈でよく使われる。

graph LR
    CP["Copilot<br/>（コパイロット）<br/>提案・補助"]
    AG["Agent<br/>（エージェント）<br/>特定タスクの自律実行"]
    AU["Autonomous<br/>（自律型）<br/>目標ベースの継続実行"]

    CP -- "人間が常に承認" --> AG
    AG -- "例外のみ人間" --> AU

    style CP fill:#d4edda,stroke:#28a745
    style AG fill:#cce5ff,stroke:#004085
    style AU fill:#f8d7da,stroke:#721c24

Copilot：AIがコンテキストを理解し、次のアクションを提案する。ユーザーは提案を受け入れるか無視するか選ぶ。最終実行は常に人間。

Agent：AIが特定プロセス・タスクを担当し、自律的に実行する。人間は目標を設定し、結果を評価する。Microsoftの定義では「エージェントはCopilot時代のアプリだ」。

Autonomous：AIがビジネス目標を理解し、それを達成するための計画・実行・調整を継続的に行う。人間は方針と境界のみを設定する。

特徴：プロダクトポジションとして使いやすい。「うちのプロダクトはCopilotです」「Agentです」が一言で言える。 弱点：Agentの定義が広すぎる（GitHub Copilot AgentもSierraも同じ「Agent」になる）。

3. Karpathyのソフトウェア三世代論：パラダイム軸

Andrej Karpathy の分類は自律性ではなくプログラミングパラダイムに着目している。

世代名称「プログラム」の形式例
1.0Software 1.0人間が書く明示的なコード従来のアプリ
2.0Software 2.0ニューラルネットのウェイト画像認識モデル埋め込み
3.0Software 3.0自然言語プロンプトLLMベースのプロダクト全般

Karpathyの視点では、GPTのような基盤モデルに「英語でプログラムを書ける」のが最大のイノベーションだ。これはツールの種類ではなく、ソフトウェア開発のパラダイムシフトを示す。

特徴：歴史的文脈が明確で、「なぜ今起きているのか」を説明しやすい。 弱点：実装上の具体的な設計指針に落としにくい。

4. Microsoftの成熟度モデル：組織成熟軸

Microsoft Copilot Studioの成熟度モデル は、テクノロジーではなく組織能力の成熟度を分類する。

レベル名称状態
100Initial実験的・場当たり的
200Repeatable初期パターンが出始める
300Defined正式に定義・文書化・ガバナンスあり
400Capableエンタープライズ計画に組み込まれた
500EfficientAgent-first企業として完全動作

特徴：CTO・CDO向けのロードマップとして使いやすい。「今どこにいて、次にどこへ」が分かる。 弱点：プロダクト設計の具体的ガイダンスにはならない。

本シリーズが使う分類

上記のフレームワークは互いに矛盾しないが、目的が異なる。本シリーズでは、プロダクト設計の観点から最も実用的な4レベル分類を使う。設計上の断絶点（誰が実行責任を持つか）に着目して引いた線だ。

graph TD
    subgraph L1["Level 1：補完・提案型"]
        L1a["AIがテキスト・候補を生成<br/>人間が選択・実行<br/>例: Copilot補完、Gmail Smart Reply"]
    end

    subgraph L2["Level 2：コパイロット型"]
        L2a["AIがコンテキストを理解して積極的に提案<br/>人間が承認・修正・棄却<br/>例: Notion AI、GitHub Copilot Chat"]
    end

    subgraph L3["Level 3：監督付き自律実行型"]
        L3a["AIが複数ステップを自律実行<br/>人間が事前計画を承認・事後結果をレビュー<br/>例: Claude Code、Devin、Agentforce"]
    end

    subgraph L4["Level 4：ガードレール付き自律型"]
        L4a["AIが継続的に自律稼働<br/>ポリシーの範囲内で完結、例外のみエスカレーション<br/>例: Sierra、Intercom Fin、Glean Agents"]
    end

    L1 --> L2 --> L3 --> L4

    style L1 fill:#d4edda,stroke:#28a745,color:#155724
    style L2 fill:#cce5ff,stroke:#004085,color:#004085
    style L3 fill:#fff3cd,stroke:#856404,color:#533f03
    style L4 fill:#f8d7da,stroke:#721c24,color:#491217

この分類の切り口は「設計上の最も重要な問い」に対応している。

  • L1 vs L2の違い：AIは受動的か能動的か。ユーザーが呼び出して初めて動くか、コンテキストを読んで自ら提案を出すか。
  • L2 vs L3の違い：AIは提案するだけか、実行するか。ユーザーの承認がアクション前に必要か後でよいか。
  • L3 vs L4の違い：人間の監視はタスク単位か、ポリシー単位か。毎回結果を確認するか、境界さえ設定すれば任せきりか。

次章からこれらを一段ずつ深掘りする。