第3章 Level 1：補完・提案型 ── AIが候補を出す、人間が選ぶ

2026/04/26

第3章 Level 1：補完・提案型 ── AIが候補を出す、人間が選ぶ

定義と特徴

Level 1はAIプロダクト統合の出発点だ。AIは候補・補完・提案を生成するが、実行は常に人間が行う。

Level 1 の基本構造

ユーザーが入力
    ↓
AI が候補を生成（複数または1つ）
    ↓
ユーザーが選択・採用・無視
    ↓
ユーザーが実行（送信・保存・実装）

AIが「誤った候補」を出しても、ユーザーが無視すれば副作用は生まれない。これがLevel 1の最大の安全特性だ。

設計上の核心的な問い：ユーザーが求める前にAIが動いてよいか（プロアクティブ提案）、それとも明示的に呼び出された場合のみ動くか（リアクティブ生成）。この二択がLevel 1内でのUXのバリエーションを生む。

代表的なプロダクト

Gmail Smart Reply / Smart Compose（Google）

コンセプト：受信メールの内容から返信候補を自動生成し、ワンタップで送信できる。

AIの動き：メールの本文・件名・スレッド文脈を解析し、「Thanks, that works for me.」「Sounds good!」のような短い返信候補を3つ提示する。ユーザーはタップするか無視するかを選ぶ。

生み出す価値：

モバイルでのメール返信摩擦を激減させる
返信率の向上（特に短い確認メール）
「何を書けばいいか迷う」という認知コストの削減

設計の工夫：

候補は3つ提示する（多すぎず少なすぎず）
候補はあくまで短文。長文を代替しようとしない
否定的な文脈には否定的な候補を出さない（感情的リスクを回避）
ユーザーが採用した文体・語彙からパーソナライズが進む

sequenceDiagram
    participant U as ユーザー
    participant M as メール受信
    participant AI as Smart Reply Model

    M->>AI: メール本文・文脈を送信
    AI->>U: 候補3つを提示（UI下部に表示）
    U->>U: 無視してゼロから書く
    Note over U: または
    U->>M: 候補をタップして送信

GitHub Copilot インライン補完（GitHub / Microsoft）

コンセプト：コードを書きながら、次に書くであろうコードをAIがリアルタイムで灰色表示する。Tabキーで採用、無視すれば消える。

AIの動き：カーソル位置・周辺コード・ファイル全体・コメントから、次の1行〜複数行を予測して提案する。1秒未満で候補を表示し、ユーザーが書き続けると再予測する。

生み出す価値：

ボイラープレートコードの入力時間を大幅短縮
見慣れないAPIの正確な使い方を「補完しながら学ぶ」
「次の行は何を書くべきか」という認知コストの削減
GitHub Octoverse 2025によれば、平均で開発者コードの46%がAI生成

設計の工夫：

Tabキー一発で採用というフリクションレスなUX（採用コストが限りなくゼロ）
灰色表示という「提案中」の視覚的言語（採用する前は確定していない）
補完がうまくいかない場合のフォールバック：提案が出なければ普通に書けばよい
コンテキストウィンドウを最適化してレイテンシを最小化（100ms以内を目標）

Grammarly（Grammarly Inc.）

コンセプト：文章を書きながら、文法・スペル・スタイル・明確さの問題をリアルタイムで検出し、修正案を提示する。

AIの動き：文章全体の構造・語調・目的を解析し、単純な誤りから語調の一貫性、メール冒頭の印象まで多層的な提案を行う。各提案には理由が添えられる。

生み出す価値：

ノンネイティブ英語話者のプロフェッショナルな文章品質担保
ライティングを通じたユーザーのスキル向上（理由付きの提案）
組織ブランドの文体統一（Grammarly Business機能）

設計の工夫：

提案の優先度付け（必須修正・推奨修正・任意修正の区別）
各提案に「なぜそう直すのか」の説明を添える（教育的効果）
「文章全体のスコア」という俯瞰視点の提供
ユーザーが拒否した提案は学習してパーソナライズ

Perplexity AI（Perplexity AI Inc.）

コンセプト：検索エンジンの代替として、質問に対してリアルタイムのWeb情報を統合したまとまった回答を生成し、引用元を明示する。

AIの動き：ユーザーの質問を理解し、複数のWebソースを検索・読み込み・統合した上で、引用付きの回答を生成する。ユーザーはその回答を読んで判断・検証する。

生み出す価値：

複数のWebページを読み漁る手間の削減
回答の信頼性を引用で検証可能にする
学術・リサーチユースケースでの信頼性

設計の工夫：

引用のホバー表示（回答文中の番号にカーソルを当てると元記事が見える）
「どのソースから情報を取ったか」の明示（ブラックボックス排除）
「関連する質問」の自動提案（探索の連鎖を促進）
2026年2月に「Model Council」機能追加：複数モデルの回答を並べて比較できる

Level 1 に共通する設計原則

原則1：採用コストをゼロに近づける

提案を採用するコストがゼロに近いほど、AIの価値が最大化される。Gmail Smart Replyのタップ一発、CopilotのTab一発がその極致だ。採用に何クリックもかかる設計は、提案を「邪魔なもの」に変える。

原則2：却下コストもゼロに近づける

逆に、提案を無視・却下するコストも最小化する。Copilotの補完は書き続けるだけで消える。この「消しやすさ」がLevel 1の安全性の根幹だ。「なんとなく提示されたけど違った」が完全にノーコストである。

原則3：提案の信頼性を視覚的に示す

灰色のテキスト、下線、番号付き引用——Level 1プロダクトは「これはまだ確定していない候補だ」という視覚的言語を持つ。確定済みのコンテンツと提案候補が混在すると認知混乱が起きる。

原則4：文脈の範囲を明示または最小化する

AIが何を見て提案を生成したかが不透明だと、なぜその提案が出たのかがわからずユーザーが不安を感じる。引用リンク（Perplexity）、「現在のファイル」（Copilot）のような文脈の明示、あるいは文脈を狭く限定することで予測可能性を高める。

Level 1 プロダクトの価値生成メカニズム

flowchart TD
    A["ユーザーの認知コスト削減<br/>（次の言葉を考えない）"]
    B["入力摩擦の削減<br/>（タイプ量が減る）"]
    C["品質向上<br/>（普段は気づかない改善）"]
    D["学習効果<br/>（提案から正しい表現を知る）"]

    A --> V["価値"]
    B --> V
    C --> V
    D --> V

    V --> R["採用率・継続使用率の向上"]
    V --> T["信頼の蓄積"]

Level 1の価値は「ユーザーが何かをできるようになる」というより「ユーザーがより少ない労力で同じことをできる」だ。そのため**採用率（Accept Rate）**が主要KPIになる。GitHubはCopilotの補完採用率を公開しており、これがプロダクト品質の直接指標となっている。

Level 1 に潜む罠

罠1：提案の多すぎによるノイズ化：提案が頻繁すぎると、ユーザーは提案を無意識に「却下する習慣」を持つ。このとき良い提案も見逃される。Google Smart Composeが3候補に絞っているのはこのためだ。

罠2：確証バイアスの増幅：AIの提案はトレーニングデータの傾向を反映する。「最もよくある返し方」が常に提案されると、ユーザーがよりありきたりな文章を書くよう誘導される。

罠3：非採用データの収集失敗：採用されなかった提案からも学ぶべきだが、「無視された」ことを適切にデータ収集しないと、なぜ採用されなかったのかがわからない。

次章では、Level 1がより能動的になったLevel 2「コパイロット型」に移る。