第4章 Level 2：コパイロット型 ── AIがコンテキストを読んで能動的に動く
Level 1 との違い
Level 1のAIは受動的だ。ユーザーが書き始めると補完する、ユーザーが質問すると回答する。
Level 2のAIは能動的だ。ユーザーの現在の状態・過去のアクション・プロジェクト全体を理解した上で、ユーザーが求める前に次のアクションを提案する。
Level 1：「次の単語は何か？」を予測する
Level 2：「今この状況でユーザーが次に必要なことは何か？」を推論するこの違いは実装の複雑さに直結する。Level 1はローカルなコンテキスト（直前の数百トークン）で動く。Level 2はユーザーのプロジェクト・ドキュメント・ワークフロー・過去の行動履歴という広いコンテキストを持つ必要がある。
ただし最終的な実行は依然として人間の承認を必要とする。これがLevel 3との違いだ。
代表的なプロダクト
Notion AI（Notion）
コンセプト：ドキュメントの中にAIアシスタントが統合されており、ページの内容・構造・目的を理解した上でコンテンツの生成・要約・改善・翻訳を行う。
AIの動き：
- ドキュメント編集中に
SpaceキーでAIを呼び出し、「続きを書いて」「要約して」「トーンを変えて」を自然言語で指示 /AIブロックで自動更新コンテンツを埋め込む（例：毎朝チームの直近タスクを要約するブロック）- 2026年2月リリースの Custom Agents では、Slack・メール・カレンダー・Linear・Figma・HubSpotなどと連携し、トリガーベースで自律実行も可能（これはLevel 3に近づいている）
生み出す価値：
- ドキュメント作成の白紙恐怖（blank page problem）の解消
- ミーティングノートの自動要約による情報消化コスト削減
- 多言語コラボレーションの摩擦低下
設計の工夫：
- AIは「ページの中の市民」として扱われる（別タブへの遷移が不要）
- 生成結果は即座に編集可能（受け入れるか修正するかユーザーがコントロール）
- 「AIブロック」という概念で、AIが生成したコンテンツと人間が書いたコンテンツを区別する
GitHub Copilot Chat（GitHub / Microsoft）
コンセプト：コードベース全体を文脈として持つAIアシスタント。「この関数の意味は？」「このバグの原因は？」「テストを書いて」に対して、コードベースへの深い参照付きで回答する。
AIの動き：
- エディタのサイドバーに常駐し、ユーザーの選択コード・カーソル位置・ファイル全体を文脈として持つ
- 「このコードのどこが遅いか分析して」「このAPIのエラーハンドリングを追加して」という複合的な質問に答える
- エージェントモードでは、複数ファイルを自律的に変更するが、変更前にユーザーが計画を確認できる
生み出す価値：
- コードレビューの高速化
- 新規参加者のコードベース理解コスト削減
- TDDサイクルの加速（テストを先に書くコストの低下）
設計の工夫：
@workspace、@file、@terminalというスコープ指定でAIが参照する情報を制御- 変更提案はdiff形式で表示（何が変わるか一目瞭然）
- カスタムインストラクションでチーム固有のコーディング規約をAIに教える
Figma AI（Figma）
コンセプト：デザインツールの中にAIが統合されており、既存デザインの文脈を理解した上でコンポーネント生成・レイアウト提案・プロトタイプ拡張を行う。
AIの動き：
- デザインファイルの構造・コンポーネントライブラリ・デザインシステムを理解した状態で指示を受ける
- 「このカードコンポーネントのモバイル版を作って」「このフォームを簡素化して」という自然言語指示
- UI to Codeで、既存デザインから動作するReactコードを生成する
生み出す価値：
- デザイナーのプロトタイピング速度向上
- デザイン→開発のハンドオフ摩擦削減（UIからコードへの直接変換）
- デザインシステムの一貫性維持
設計の工夫：
- 既存デザインシステムの変数・カラートークン・コンポーネントを優先して使用する（一貫性の担保）
- 生成されたコンポーネントは即座に編集可能なFigmaオブジェクト（ロックされない）
- 変更はUndo可能（破壊的でない）
Microsoft 365 Copilot（Microsoft）
コンセプト：Word・Excel・PowerPoint・Outlook・TeamsにAIが統合。仕事のコンテキスト（メール・会議・ドキュメント・カレンダー）を横断的に理解した「仕事のコパイロット」。
AIの動き：
- Outlookで：「この長いメールスレッドを3行で要約して」「この返信ドラフトを作って」
- Teams会議で：リアルタイムで議事録作成・アクションアイテム抽出・欠席者向けサマリー
- Excelで：自然言語でのデータ分析指示（「売上の前年比をグラフ化して」）
- PowerPointで：Word文書からスライドデッキを生成
生み出す価値：
- 情報過多の緩和（Inbox Zeroへの支援）
- 会議の生産性向上（リアルタイム議事録）
- クロスアプリのコンテキスト活用（「先週のミーティングで決まったことを今週のメールに反映して」）
設計の工夫：
- Microsoft Graph（ユーザーのメール・カレンダー・ドキュメント全体）をコンテキストとして活用
- 生成物はすべて「編集可能な草稿」として扱われる
- セキュリティラベルに基づいたアクセス制御（機密データをAIが参照しすぎない）
Level 2 の設計原則
原則1：コンテキストの深さが品質を決める
Level 2の価値はローカルなコンテキスト（1ファイル・1段落）から広いコンテキスト（プロジェクト全体・組織全体）に拡張することで生まれる。しかし広すぎるコンテキストは「何でも知っている幻想」を生む。
実際には、コンテキストウィンドウには限りがある。どの情報を優先して文脈に入れるか（コンテキストエンジニアリング）が品質を決定的に左右する。
graph LR
A["狭い文脈<br/>（現在行のみ）"] --> B["中程度の文脈<br/>（現在ファイル）"]
B --> C["広い文脈<br/>（プロジェクト全体）"]
C --> D["組織文脈<br/>（メール・会議・ドキュメント）"]
A -.->|"精度高・汎用性低"| A
D -.->|"汎用性高・精度維持が難しい"| D原則2：承認の粒度をタスクに合わせる
Level 2の承認は「提案全体を受け入れる／拒否する」だけではなく、部分的な採用・修正を自然に行えることが重要だ。
Notionで「続きを書いて」と頼んで生成された段落を、半分だけ使って半分は書き直す——これが快適に行えるかどうかが、Level 2のUX品質を決める。
原則3：AIの生成物を「草稿」として明示する
ユーザーが「AIが生成したもの」と「自分で書いたもの」を区別できることが重要だ。Figmaの生成コンポーネント、GitHubのdiff表示、Notionの「AIが生成しました」表示——これらはすべて「これはまだ確定前の草稿です」という認知を維持するための設計だ。
この区別が崩れると、AIの生成物を十分に検証せず採用する「過信バイアス」が生まれる。
Level 2 の価値生成メカニズム
Level 2の価値は単純な時間節約を超えている。
フロー状態の維持：コードを書いている・文章を書いているときの集中状態（フロー）を、「次何をすべきか」という判断中断なしに維持できる。
ジュニアからシニアへの知識移転：「この状況でどう書くか」という暗黙知をAIが代替することで、経験の浅いユーザーがより高品質なアウトプットを出せる。
組織知識のアクセス民主化：Microsoft 365 Copilotが示すように、「あのミーティングで誰が何を言ったか」「先月の売上がどうだったか」を自然言語で聞いてアクセスできることは、情報の民主化だ。
Level 2 に潜む罠
罠1：コンテキスト収集の過剰なプライバシーリスク：広いコンテキストを持てばAIは賢くなるが、「AIが自分のメール全部を読んでいる」という感覚はユーザー信頼を損なう可能性がある。コンテキスト範囲の透明性と制御性が必要だ。
罠2：「承認の形骸化」：提案の品質が上がるほど、ユーザーは深く考えずに承認するようになる。特にビジネスロジックを含む変更に対して、Approveボタンを押すだけの習慣が定着すると、Level 2は「AIが実質的にLevel 3の自律実行をしているが人間が思考停止で承認している」状態になる。
罠3：コンテキスト汚染：大量の文脈を与えると、AIは関連性の低い情報に引きずられた提案を出すことがある。「組織全体のメールを見ているから、今書いているコードが過去の似たバグと関連していると勘違いする」ようなケースだ。
次章では、AIが実際にアクションを実行するLevel 3に移る。