SaaS製品UIに埋め込まれたAI Copilot

GitHub Copilotは、それを持つ開発者が毎日使用します。

Notion AIは、執筆プロセスに組み込んだユーザーによってほぼすべてのドキュメントセッションで開かれます。

これらはAIを思い出して使うものではありません。Workflowに織り込まれたAIです。ユーザーはコードを書いており、コードが完成します。ユーザーはドキュメントを書いており、段落が続きます。AIと関わるという決断はありません。すでにそこにあります。

これが埋め込みCopilotパターンです。SaaSで最も高い維持率への影響を持つAI機能カテゴリです。

Copilotトリガーマトリックス

CopilotトリガーマトリックスはいつCopilotがアクティベートするかを決定するデザインFrameworkです。マトリックスは2つの次元をマッピングします。トリガータイプ（明示的: ユーザーが意図的にAIを呼び出す対暗黙的: AIがコンテキストに基づいて提案を継続的に表示する）と信頼度レベル（高: AIがユーザーの意図について強いシグナルを持つ対中程度: AIが部分的なシグナルを持つ）です。高信頼度の暗黙的なトリガー（GitHubCopilotのライン補完）がターゲット状態です。ゼロ摩擦、常に存在。高信頼度の明示的なトリガー（Notionのスラッシュコマンド）は、制御が適切なより豊富な機能に対して機能します。中程度の信頼度の暗黙的なトリガーはノイズを生み出し、ユーザーが提案を無視するよう訓練します。中程度の信頼度の明示的なトリガーは、品質が検証される前の新しいAI機能にとって安全な出発点です。

埋め込みCopilotとは

埋め込みAI Copilotは製品の主要なWorkflow面の内部に存在します。ユーザーが開かなければならないサイドバーではありません。メインインターフェースの上にフロートする独立したAIパネルではありません。ユーザーが質問するために行くヘルプウィジェットでもありません。

ACE FrameworkのWorkflow Copilot Patternはこれを正確に説明しています。ユーザーの現在のコンテキストを取り込み（Ingest）、意図を分析し（Analyze）、提案を生成し（Generate）、人間の承認で実行し（Execute）、繰り返します。AIがすでにWorkflowの中にあるため、インタラクションはWorkflowの速度で行われます。

ヘルプウィジェットのチャットボットはCopilotではありません。ナビゲーションの「AI」をクリックするとポップアップするモーダルはCopilotではありません。Copilotは作業が行われている場所のInlineに位置し、ユーザーが作業中を離れずにアクセスするためにコンテキストの中で提案を追加します。

違いは摩擦です。埋め込みCopilotは摩擦がありません。ボルトオンのAIツールはコンテキストの切り替えを必要とします。これがほとんどのユーザーが使用を止めるポイントです。

重要なファクト: 埋め込みAI Copilotの採用

• GitHub Copilotは2025年初頭までに1,500万人以上のユーザーに達し、Fortune 100企業の90%に利用されています。Copilotを使用する開発者は制御されたテストでタスクを55%速く完了します（Second Talent、2025年）
• Microsoft 365 Copilotの職場採用率は35.8%で、アクセス権を持つ従業員の10人中4人未満が実際に使用しており、コンテキストの切り替えなしにWorkflowで実行されるボルトオンAIと埋め込みAIのギャップを示しています（ALM Corp、2026年）
• 複数のプロダクトチームからの事例証拠では、「有用と感じる」提案の受け入れ率のしきい値を70%としており、それ以下ではユーザーがCopilotを「邪魔」と報告し、70%以上ではユーザーが「自分が何を考えているかわかっている」と報告します

埋め込みが維持率に重要な理由

ソフトウェア製品における習慣形成はシンプルなルールに従います。行動を繰り返すのが容易であるほど、習慣が速く形成されます。

埋め込みCopilotはAIを使用する摩擦をほぼゼロまで低下させます。ユーザーはAIを開くことを決断する必要がありません。別の画面にナビゲートする必要もありません。AIに助けを求める良い瞬間かどうかを考える必要もありません。AIはすでにそこで、作業中に提案を提供しています。

これはエンゲージメントパターンを完全に変えます。ボルトオンのAIツールでは、使用は意図的で断続的です。ユーザーは助けが必要だと判断したときにAIに行きます。これは習慣に発展しない低頻度のパターンを生み出します。

埋め込みCopilotでは、使用は周囲的で連続的です。AIは常にバックグラウンドで実行されています。ユーザーは提案が有用なときは受け入れ、そうでないときは無視します。時間が経つにつれて提案はWorkflowの通常の部分になり、それなしで作業すると遅く感じ始めます。

これが埋め込みCopilotの維持率への影響が、サイドバーAIまたはモーダルAIとは本質的に異なる理由です。AIが優れているわけではありません。埋め込みが習慣形成の摩擦しきい値を下げるのです。Stanford HAI AI Index 2025では、AIが一貫して生産性を高め、低スキルと高スキルの作業者間のギャップを縮小する傾向があることを示しており、これが多様なチームを管理するエンタープライズの購買担当者に対して埋め込みCopilotを守りやすくする価値提案です。

強い採用を持つ例

GitHub Copilotは埋め込みCopilotのベンチマークです。開発者が最も集中した作業時間を過ごすコードエディタのInlineに位置します。開発者がタイプすると、Copilotはカーソルの直前に灰色の半透明テキストとして表示される補完を生成します。受け入れのインタラクションは1回のキー押し（Tab）です。拒否は何もせず入力を続けることです。

デザインはほぼ摩擦がありません。モーダルなし。パネルなし。執筆フローの中断なし。開発者は提案を受け入れるかそうでないかで、いずれにせよ書き続けます。インタラクションコストがほぼゼロで価値の提供が即座であるため、習慣が形成されます。

Notion AIは同じロジックを書くことに適用します。ユーザーがすでに作業しているドキュメントの内部に存在します。「/」コマンドはドキュメントを離れずにAIオプションを表示します。Inlineの生成、Inlineの書き直し、Inlineの要約です。ドキュメントWorkflowにNotion AIを組み込んだユーザーは、それなしで書くことが手間に感じ始めると報告しており、これが習慣が形成されたサインです。

LinearのAIはイシューの作成と管理に埋め込まれています。開発者がイシューを作成すると、Linear AIは自由形式の説明から構造化されたイシューを生成し、プロジェクトのコンテキストに基づいて関連するラベルと担当者を提案し、スパースなイシューのテキストを追加の詳細で充実させることができます。WorkflowはイシューManagementです。AIはそのWorkflow内でInlineアシストします。

Stripe SigmaのAIアシストはデータ分析にCopilotパターンを適用します。Sigmaの主要なWorkflowはStripeのトランザクションデータに対してSQLクエリを実行することです。AIは、ユーザーが英語でほしいものを説明すると、クエリインターフェースにInlineでSQLクエリを生成します。以前はSQLを書けなかった非技術系ユーザーが自分のデータを探索できるようになりました。埋め込みとは、AIが必要なまさにその瞬間に利用可能であることを意味します。ユーザーがクエリインターフェースに座って何をタイプするかを考えているときです。

Figma AIはデザイナーが作業セッション全体を過ごすデザインキャンバスの内部に存在します。デザインのバリエーション、オートレイアウトの提案、コンポーネントの命名、altテキスト生成はすべてデザイナーがキャンバスを離れずにInlineで行われます。

5つの例すべてでのパターン: AIはWorkflow面の中にあり、隣接しているわけではありません。挿入ポイントは主要な作業が行われる場所です。インタラクションは低摩擦で、シンプルな承認/拒否または呼び出しコマンドです。しかし失敗パターンも同様に一貫しています。

Copilotが失敗する原因

埋め込みCopilotの失敗パターンは一貫しています。

Workflowを中断するモーダルベースのAI。 「AIアシスト」というラベルのボタンが全画面モーダルを開き、ユーザーがプロンプトを記入し、その後主要なインターフェースにコピーアンドペーストしなければならない結果を返します。これは誤解を招く名前を持つボルトオンAIツールです。使用ごとに3回のコンテキストの切り替えが必要で、すぐに疲弊します。

すべてのアクションに明示的なプロンプティングが必要なAI。 ユーザーがコンテキストに応じて提案を表示するのではなく、すべての提案のためにAIを呼び出さなければならない場合、摩擦は使用が断続的になるほど高くなります。CopilotはWorkflowの永続的な部分ではなく、時々開くツールになります。

一貫して低品質の提案。 これが最も重要な失敗モードです。AIの提案が有用な場合より間違いや役に立たない場合の方が多い場合、Copilotはユーザーがそれを無視するよう訓練します。そしてユーザーが提案を無視する習慣を身につけると、品質が改善しても逆転は非常に難しくなります。SaaS AI failure modesでは、埋め込みAIが一貫してパフォーマンス不足のときに起こる信頼崩壊の全パターンを記録しています。

品質しきい値が重要です。いくつかのプロダクトチームからの事例証拠では、「有用と感じる」ための受け入れ率のしきい値が約70%とされています。それ以下では、ユーザーはCopilotが「邪魔」と感じると報告します。70%以上では、ユーザーは通常Copilotが「自分が何を考えているかわかっている」と報告します。受け入れ率が60%と75%の違いが、オフにされる機能と習慣的になる機能の違いです。

「GitHub Copilot、Notion AI、Linear AI、Figma AIはすべて1つの構造的特徴を共有しています。AIは主要な作業が行われる面に存在します。サイドバーではありません。モーダルでもありません。ヘルプウィジェットでもありません。「チームが毎日AIを使用している」と「チームがAIを一度試した」の違いは、AIがコンテキストの切り替えを必要としたかどうかにほぼ全て依存しています。」（Rework Analysis、2025年）

「品質がローンチ時にしきい値を下回っていたためにAIの提案を無視する習慣を身につけたユーザーは、品質が改善した後でもその習慣を逆転させることは非常に難しいです。信頼しきい値は主要なWorkflowに埋め込む前に超える必要があります。後ではありません。限定的なベータ版を実行し、広範な埋め込みの前に受け入れ率を測定してください。」（Rework Analysis、2025年）

埋め込み対ボルトオンAI: 採用パターン比較

出典: McKinsey AIソフトウェア開発研究2025、Stanford HAI AI Index 2025、GitHub Copilot採用データ2025

Rework分析: Microsoft 365 Copilotの採用率（35.8%）対GitHub Copilotの採用率（アクティブライセンスホルダーの80%以上が毎日使用）は同じパターンを逆に示しています。M365 Copilotは独立したインターフェースからアクセスし、ほとんどのWorkflowでコンテキストの切り替えが必要です。GitHub CopilotはコードエディタのInlineです。どちらもリソースが豊富なチームからの世界クラスのAI製品です。採用のギャップは品質ではなく配置です。埋め込みCopilotのデザインを評価するチームは、トリガーと配置戦略にコミットする前に、この比較を採用目標ベンチマークとして使用すべきです。

トリガーデザインの問題

埋め込みCopilotのコアデザインの決定の1つは、AIがいつアクティベートするかです。2つのアプローチがあります。明示的と暗黙的です。

明示的なトリガーはユーザーが意図的にAIを呼び出すことを必要とします。ドキュメントの「/」コマンド、コードエディタのキーボードショートカット、右クリックのコンテキストメニューオプション。ユーザーが尋ねます。AIが応答します。

明示的なトリガーは信頼の構築に安全です。ユーザーはAIがいつ関与しているかを正確に知っています。バックグラウンドで実行されて彼らが求めていないアウトプットを生成する周囲のAIはありません。AI品質へのユーザーの信頼がまだ確立されている製品では、明示的なトリガーはユーザーがインタラクションを制御し、段階的に信頼を構築できます。

暗黙的なトリガーは、ユーザーが明示的に尋ねなくても、AIがコンテキストに基づいて提案を継続的に表示します。GitHub Copilotは暗黙的です。タイプすると提案が表示されます。提案を求めませんでした。AIがこれが提供する良い瞬間だと判断しました。

信頼されると暗黙的なトリガーはより価値が高くなります。AIはユーザーが尋ねることを考えるときだけでなく、継続的にユーザーの代わりに作業しているからです。しかし間違った瞬間に低品質の提案を生み出す暗黙的なトリガーは押しつけがましく、ユーザーがシステムを信頼しないよう訓練します。

選択はWorkflowとAIの品質レベルによります。ユーザーの意図についてAIが強いシグナルを持つ高頻度で明確に定義されたWorkflowでは、暗黙的なトリガーが機能します。あまり構造化されていないWorkflowまたは初期段階のAI機能では、品質が向上する間は明示的なトリガーが安全です。

多くの製品はハイブリッドを使用します。高信頼度の瞬間には暗黙的な提案、より複雑または曖昧なリクエストには明示的な呼び出しです。Linearはこれを実行しています。AIはラベルと担当者を自動的に提案します（暗黙的、高信頼度、誤りのコストが低い）。一方でイシューの充実には明示的な呼び出しが必要です（低い信頼度、誤りのコストが高い）。

埋め込みの精度しきい値

主要なWorkflow面の永続的な部分としてAIを埋め込む前に、チームはAIの品質が埋め込みが助けになるかどうかのしきい値にあるかどうかを正直に評価すべきです。

重要な指標は提案の受け入れ率です。ユーザーが変更なしに受け入れるAI提案の割合は何%ですか？

70%以上: Copilotはコラボレーターのように感じます。ユーザーは提案を有用として受け入れ、それを期待し始めます。

50〜70%: CopilotはユーザーがSelectiveに関与するツールです。習慣的ではありませんが、維持するほど十分に有用です。

50%未満: Copilotはシグナルよりも多くのノイズを生み出しています。ユーザーは提案を無視するパターンを発展させ、品質が改善した後でも逆転が難しくなります。

広範な埋め込みの前に限定的なベータ版でCopilotを実行してください。受け入れ率データは、スケールするか最初に修正するかを示します。そして強い品質でスケールすると何が起きるかを理解する価値があります。

データフライホイール

埋め込みCopilotは他のAI機能が持たないシグナルを生成します。すべての提案に対するダイレクトなユーザーフィードバックです。

ユーザーが提案を受け入れると、それが肯定的なシグナルです。受け入れる前に提案を変更すると、変更データが好んだものを示す部分的なシグナルです。提案を拒否すると、その特定のコンテキストのその特定のアウトプットに関する否定的なシグナルです。

このフィードバックループは、何千人ものユーザーと何百万もの提案にわたって継続的に実行され、トレーニングデータになります。プロダクトチームはこれを使用してモデルをファインチューニングし、検索コンテキストを改善し、対処する特定の失敗モードを特定できます。AIソフトウェア開発に関するMcKinseyの研究では、この継続的なフィードバックサイクルがAI埋め込み製品対機能ボルトオンアプローチのコアな差別化要因の1つとして説明されており、フィードバックループを早期に計測するチームが改善をはるかに速く複利で積み重ねています。

これが埋め込みCopilotが時間とともに複利で成長するデータフライホイールです。各ユーザーインタラクションがフィードバックを生み出します。フィードバックがモデルを改善します。より良いモデルがより高い受け入れ率を生み出します。より高い受け入れ率がより多くの使用とより多くのフィードバックを促進します。ユーザーが製品にいる限りサイクルが継続的に実行されます。

ボルトオンのAIツールは同じレートまたは品質でこのシグナルを生成しません。週に1回AIパネルを開いてアウトプットを生成するユーザーは、それを使用するかしないかですが、セッションレベルのデータは少ないです。すべてのアクティブセッションで実行される埋め込みCopilotは、桁違いに多くのフィードバックを生成します。これが品質をはるかに速く改善できる理由です。

このデータを取得するためのテレメトリインフラは、埋め込みアーキテクチャの開始時から設計される必要があります。どのシグナルを取得していますか？どのようにラベル付けしていますか？フィードバックはモデルのトレーニングまたはファインチューニングパイプラインにどのように戻りますか？プロダクト内AIのテレメトリループでは、このフィードバックアーキテクチャを実際にどのように計測するかについて解説しています。

埋め込みのデザインパターン

SaaS製品UIにAI Copilotを埋め込むための4つの確立されたデザインパターンがあります。

ゴーストテキストのInline提案。 AIはカーソルの直前に灰色の半透明テキストとして表示される補完を生成します。Tabで受け入れ、入力を続けることで拒否します。これはGitHub Copilotパターンで、テキストとコードの構成Workflowに最適化されています。非常に低摩擦。提案が短くてコンテキスト的に明確なときに最もよく機能します。

スラッシュコマンドパネル。 コンテンツ面で「/」をタイプすると、通常のコマンドと並んでAIオプションを持つコマンドパレットが開きます。Notionはこれを使用しています。ユーザーはドキュメントを離れずにコンテキストでAIを呼び出しますが、呼び出しは明示的です。明示的な制御が適切な豊富なAI機能（生成、書き直し、要約）に適しています。

コンテキスト対応サイドバー。 ドキュメント内のユーザーの現在の選択や場所に対して、関連するAIの提案で応答するサイドバーです。サイドバーは永続的で目立たないものです。より大きなUI面から恩恵を受ける、より複雑なAI機能（ドキュメント分析、クロスリファレンスルックアップ）に適しています。

自然言語コマンドバー。 プレーン英語の指示を受け入れ、適切なAI機能にルーティングするコマンドパレットです。「先ほど説明したログインバグのイシューを作成して」または「最後の3つのミーティングノートをアクションアイテムにまとめて」。LinearとNotionはどちらも、より複雑なリクエストのための第2レイヤーのインタラクションとしてこのパターンを使用します。

正しいパターンはWorkflowの頻度、AIアウトプットの複雑さ、ローンチ時のAI品質へのユーザーの信頼レベルによります。しかしパターンを選択することは簡単な部分です。より難しい部分は、どのWorkflowに埋め込むかを知ることです。

Copilotにはワークフロー思考が必要

成功した埋め込みCopilotを構築するプロダクトチームは1つの特徴を共有しています。まずWorkflowについて考え、次にAIがどのようにそれに合うかを決定します。

問題は「どのAI機能を追加すべきか」ではありません。「ユーザーのWorkflowのどこで摩擦が最も高く最も頻繁で、どのAI介入がその摩擦を最も直接的に削減するか？」です。

機能から始めて、それを置く場所を探すと、モーダルAI、サイドバーAI、コンテキストの切り替えが必要な機能が生まれます。Workflowから始めて、AIがその中でどこかに位置するかを尋ねると、ユーザーが毎日戻ってくる埋め込みCopilotが生まれます。

これら2つのアプローチ間の維持率の違いは測定可能で大きいです。ユーザーが存在を覚えていることが必要なAI機能は良くても断続的な使用を生み出します。主要なWorkflow面に埋め込まれたAIは、代替品よりも製品を粘着性の高いものにする毎日の習慣を生み出します。

---

関連リンク:

• Workflow Copilot Pattern: 埋め込みCopilotのインタラクションモデルを定義するACE Frameworkパターン
• AI Features as Product: Where to Add Them: Copilot埋め込みに適切なWorkflow面の特定方法
• Telemetry Loops for In-Product AI: Copilotを時間とともに改善するデータフライホイールの計測
• AI Onboarding Flows in SaaS Products: Copilot機能がOnboardingとアクティベーションにどのように接続するか
• SaaS AI Failure Modes: 埋め込みAIが一貫してパフォーマンス不足のときの信頼崩壊パターン