Microsoft Copilotを普段のチャットでは問題なく使えているのに、Copilot Notebooks（Copilotノートブック）に切り替えた途端、回答の精度が下がったように感じたり、少し前に伝えた条件を反映しなくなったりすることがあります。特に、データベースのテーブル定義や仕様書を読み込ませてSQLを生成する用途では、存在しないカラムを使う、JOIN条件を間違える、以前指定したルールを無視するといった問題が目立ちやすくなります。
しかし、これは単純に「ノートブックにするとCopilotのAI性能が低下する」と考えるより、Copilot Notebooksが参照情報を限定した「スコープされたワークスペース」として設計されていることを理解すると対策しやすくなります。この記事ではMicrosoftの公式情報をもとに、Copilotノートブックで回答がおかしく感じる原因と、DB設計情報を使ったSQL生成の精度を改善する実践的な方法を解説します。
Copilotノートブックで「急に精度が落ちた」と感じるのはなぜ？
まず押さえておきたいのが、通常のCopilot ChatとCopilot Notebooksでは、情報の扱い方が同じとは限らないという点です。
MicrosoftはCopilot Notebooksを、コンテンツや情報源を集約し、それらを基にCopilotが文脈を理解して回答する「scoped workspace（スコープされたワークスペース）」として説明しています。つまりノートブックでは、追加した参照情報を中心に回答を生成することが重要な特徴です。
Microsoftの説明では、Copilot Notebooksは基本的にノートブックへ追加した参照情報を利用します。OneDrive全体、メール、Teamsのチャットなどを無条件ですべて参照する仕組みではありません。そのため、通常のチャットと同じ感覚で「Copilotなら前提を全部分かっているだろう」と考えて使うと、期待した回答との差が生まれることがあります。
[参照] Microsoft Support：How Microsoft Copilot Notebooks works
「前のチャットを忘れた」ように見える理由
Copilot Notebooksで特に注意したいのは、チャット履歴と、ノートブックに明示的に追加した参照情報を同じものとして考えないことです。長いやり取りの途中で一度伝えた重要条件を、その後のすべての生成で確実に維持してくれることを前提にすると、SQL生成のような厳密性が必要な作業では不安定になりやすくなります。
例えば最初の会話で「論理削除されたレコードは必ず除外する」「orders.user_idとusers.idをJOINする」と伝え、その後何十回もSQLを生成させる使い方を考えてみます。重要なルールを会話の中だけに置くより、DB定義やSQL作成ルールをノートブックの参照情報やカスタム指示として明示したほうが、Copilotが必要な前提へアクセスしやすくなります。
MicrosoftはCopilot Notebooksにカスタム指示を設定する機能も案内しています。繰り返し守らせたいルールは、毎回のプロンプトだけに依存させず、カスタム指示として設定する方法が有効です。
[参照] Microsoft Support：Provide custom instructions for your Microsoft Copilot Notebook
DBのテーブル情報からSQLを書かせるなら「参照情報の設計」が重要
SQL生成では、Copilot自身の一般的なSQL知識だけでなく、自社DB固有のスキーマをどれだけ正確に渡せるかが結果を大きく左右します。テーブル名、カラム名、型、主キー、外部キー、リレーション、NULLの扱い、論理削除ルールなどが曖昧であれば、AIは不足部分を推測するしかありません。
例えば「ユーザーごとの先月の売上を出すSQLを書いて」という依頼だけでは、Copilotにはusersとordersの関係や、売上として参照すべきカラムが分かりません。DBにsales_amountが存在するのか、total_priceなのか、注文確定日がcreated_atなのかcompleted_atなのかも不明です。
そこで、参照用ドキュメントには少なくとも「テーブル名」「カラム名」「データ型」「主キー」「外部キー」「テーブル間の関係」「業務上重要なカラムの意味」を記載しておくとよいでしょう。
| テーブル | 主要カラム | 意味・ルール |
|---|---|---|
| users | id | ユーザーID・主キー |
| orders | user_id | users.idへの外部キー |
| orders | total_price | 注文金額 |
| orders | completed_at | 注文確定日時 |
| orders | deleted_at | NULL以外は論理削除済み |
さらに「売上集計ではdeleted_at IS NULLを必須とする」「売上日はcompleted_atを基準とする」といった業務ルールまで書いておくことが重要です。DDLだけでは分からない情報こそ、AIによるSQL生成では大きな差になります。
参照ファイルを増やしすぎれば良いわけではない
Copilotに多くの情報を与えれば与えるほど精度が上がると思いがちですが、ノートブックでは「必要な情報を選んで渡す」という発想が重要です。Microsoftの公式情報では、Copilot Notebooksには参照情報の上限や、グラウンディングに利用される参照数についての仕様があります。
2026年6月更新のMicrosoft Supportでは、Microsoft Copilotユーザーは300を超える参照を追加できる一方、グラウンディングに使われるのは最大300件と説明されています。また、SharePointフォルダーやサイトのような共有場所を追加した場合には、プロンプトに関連するファイルが選択されます。確実に利用したい特定のファイルについては、Microsoftもそのファイルを直接ノートブックへ追加する方法を案内しています。
[参照] Microsoft Support：Add references to your Microsoft Copilot Notebook
したがって、SQL生成用ノートブックに社内資料を片っ端から追加するより、SQL生成に必要なDB仕様を少数の分かりやすい資料へ整理するほうが管理もしやすくなります。古いDB仕様書や廃止済みテーブルの資料が残っている場合は、参照から外すことも検討しましょう。
SQL生成用のCopilotノートブックはこう構成すると使いやすい
実務では、SQL生成専用のノートブックを作り、参照情報を用途ごとに整理すると扱いやすくなります。例えば次のような構成です。
- 01_database_schema：テーブル、カラム、データ型、PK、FK
- 02_relationships：テーブル間のリレーション
- 03_business_rules：論理削除、ステータス、売上計上などの業務ルール
- 04_sql_rules：使用DB、SQL方言、命名規則、禁止事項
- 05_sql_examples：社内で正しいと確認済みのSQL例
例えばSQLルールには「DBMSはPostgreSQL」「SELECT *は使用しない」「論理削除テーブルではdeleted_at IS NULLを付ける」「JOINには必ず明示的なON条件を書く」「存在が確認できないカラムを推測で使用しない」といった内容を記載します。
こうしておけば、毎回長いプロンプトでDBのルールを説明する必要が減ります。また、SQL生成のための資料と別案件の議事録などが混在しにくくなるため、ノートブックの目的も明確になります。
プロンプトにも「参照情報だけを使う」という制約を入れる
参照情報を整理したら、次はプロンプト側を改善します。SQL生成では単に「SQLを書いて」ではなく、何を根拠として、分からない場合にどうするかまで指定すると安全性を高められます。
例えば、次のような指示です。
ノートブックに登録したDB定義と業務ルールを参照してSQLを作成してください。DB定義に存在しないテーブル名・カラム名は推測で作らないでください。必要な情報が不足している場合はSQLを完成させず、不足している情報を列挙してください。使用するテーブルとJOIN条件を説明した後にSQLを出力してください。
この方法のポイントは、AIに「分からなくても何か答える」ことを求めず、情報不足なら情報不足と判断させることです。SQLでは、もっともらしい誤答より「このカラムが不明です」と返してもらったほうが実務上は安全です。
生成前にスキーマを確認させる方法も有効
複雑なSQLの場合は、いきなり完成したSQLを書かせるのではなく、段階を分ける方法もあります。まず「この要件を実現するために使用するテーブル、カラム、JOIN条件を参照資料から列挙してください」と依頼します。
その回答を確認した後に「確認したテーブルとカラムだけを使ってSQLを作成してください」と依頼すれば、存在しないカラムや誤ったJOINを早い段階で発見しやすくなります。特に本番DB向けのクエリや複雑な集計SQLでは、この一手間に大きな意味があります。
カスタム指示には「毎回守ってほしいこと」を入れる
Copilot Notebooksのカスタム指示を利用できる環境なら、会話の途中で忘れてほしくないルールを設定しておくと便利です。Microsoftによれば、ノートブックにはCopilotがプロンプトへ応答するときに従う指示を設定できます。
SQL用途なら「このノートブックはPostgreSQL用」「スキーマにない情報を推測しない」「SQLを生成する前に使用テーブルを確認する」「不明点があれば質問する」「DELETE・UPDATEを生成する場合は注意点を示す」などが候補になります。
一方、案件ごとに変化する検索条件や期間、今回だけ必要な出力形式まで固定ルールへ詰め込む必要はありません。恒久的なルールはカスタム指示、DB固有の知識は参照資料、その都度変わる要件はプロンプトと役割を分けると管理しやすくなります。
それでも回答がおかしいときのチェックポイント
Copilotノートブックの回答品質に問題がある場合は、AIそのものを疑う前に、入力されているコンテキストを順番に確認すると原因を切り分けやすくなります。
- 必要なDB定義ファイルがノートブックの参照に追加されているか
- 古いスキーマと新しいスキーマが混在していないか
- テーブル間のリレーションが資料に明記されているか
- DDLだけでは分からない業務ルールが記載されているか
- 重要なファイルを共有フォルダー任せにせず直接参照へ追加しているか
- 毎回守るべきルールをカスタム指示に設定しているか
- プロンプトで存在しないカラムを推測しないよう指示しているか
- 一度に大量の要件を渡さず、スキーマ確認とSQL生成を段階的に行っているか
また、不要になった参照はノートブックから削除できます。Microsoftも、不要な参照を取り除くことでノートブックをフォーカスされた最新の状態に保てると案内しています。
[参照] Microsoft Support：Remove a reference from your Microsoft Copilot Notebook
まとめ：Copilotノートブックは「記憶力」よりコンテキスト設計を意識する
Copilotノートブックで回答が急に悪くなったように感じる場合、単純にAIが「バカになった」と考えるより、ノートブックがどの情報を参照して回答しているのかを確認することが重要です。Copilot Notebooksは、追加した参照情報を中心に回答を生成するスコープされたワークスペースとして設計されています。
特にSQL生成では、テーブル定義を大量に読み込ませるだけではなく、主キー・外部キー・リレーション・論理削除・業務ルールなどを整理し、AIが判断しやすい形で参照情報を用意することが精度改善につながります。
実務では、「DB固有の知識は参照資料」「毎回守るルールはカスタム指示」「今回の検索条件はプロンプト」という3層に分けると扱いやすくなります。さらに、存在しないテーブルやカラムを推測させない指示を加え、複雑な処理では「使用するテーブルとJOIN条件の確認→SQL生成」の順に進めることで、もっともらしい誤ったSQLを減らせます。
なお、Copilot Notebooksの仕様や利用できる機能は更新される可能性があります。業務利用ではMicrosoftの公式ドキュメントで最新仕様を確認しつつ、生成されたSQLをそのまま本番環境で実行せず、必ず内容・実行計画・対象データを確認してから利用することをおすすめします。
コメント