# Copilotへの初回プロンプト:資料アップロード時に使う認識合わせ

## 使い方

1. 以下の3つのMarkdownファイルをダウンロードし、Copilotのチャットに添付する
   - `情報活用基盤_技術検証まとめ.md`(技術検証の詳細な結論・比較パターン・コスト・次のアクションまでを含む、最も網羅的な資料)
   - `やさしい解説_情報活用基盤の仕組み.md`(専門知識がなくても分かる、平易な説明。LLMの前提、Cortex Agent/Searchのたとえ話)
   - `検証の道筋.md`(なぜこの順番で検証し、何が考えを変えたかという、思考の経緯)
2. 下記のプロンプトを、そのまま最初のメッセージとして送る
3. Copilotの返答(理解内容の要約)を確認し、認識のズレがあれば訂正する
4. そのやり取りが済んでから、実際の資料作成の壁打ちに入る

---

## プロンプト本文(コピーして使用)

```
これから、私がSnowflake上で行った「情報活用基盤」という構想の技術検証について、
まとめた資料を3つ添付します。まずこれらを読み込んで、内容を理解してください。

【資料の構成と役割】
1. 情報活用基盤_技術検証まとめ.md
   → 技術検証の本体。何を検証し、何が分かり、何が未検証か、比較検討した
     実装パターン、コストの考え方まで、最も詳細で網羅的な資料。
2. やさしい解説_情報活用基盤の仕組み.md
   → 専門知識がない同僚にも伝わるよう、たとえ話を使って書いた平易な説明。
     「なぜAIチャットの土台部分はSnowflakeに任せてよく、タグ設計や指示文の
     設計だけが自分たちの仕事になるのか」を伝えることが目的。
3. 検証の道筋.md
   → 検証を進めた実際の順番と、何が次の疑問を生んだかという、思考の経緯。
     結論だけでなく、どうやってその結論にたどり着いたかを補足するもの。

【この資料群の背景】
私はCanon生産本部の企画センターで、企画業務担当者がAIチャットの中で
相談や資料作成を完結でき、そこで生まれた暗黙知(進め方のコツ、リスク回避の
知見など)を自動的に蓄積・共有できる基盤を作れないか、という構想を持っています。
今回の3資料は、その構想がSnowflake上で技術的に実現可能かを検証した記録であり、
完成したシステムの仕様書ではありません。実現可能性の検証と、今後議論すべき
論点の洗い出しが目的です。

【これから一緒にやりたいこと】
この検証結果を、私が所属するチームの同僚に共有するための発表資料を、
一緒に作っていきたいと考えています。ただし、いきなりスライドを作り始める
のではなく、まず以下を順番に確認してください。

1. 3つの資料を読んだ上で、あなたが理解した内容を、章立てのレベルで
   要約して私に提示してください(理解のズレがないか、先に確認したいため)
2. その後、次の質問を私に投げて、発表資料の方向性を一緒に固めてください
   ・想定する聴衆は誰か、どのくらいの技術的前提知識を持っているか
   ・発表の時間や場の性質(定例会議での共有か、意思決定を求める場か)
   ・発表を通じて、聴衆にどんな行動や反応を期待するか
     (例:タグ設計についての議論を始めたい、予算承認を得たい、等)
3. 方向性が固まってから、初めて構成案(スライドの章立て)を提案してください

いきなり全部を一度にやろうとせず、上記の順番で、一つずつ確認しながら
進めてください。まずは資料を読んだ理解内容の要約から始めてください。
```

---

## このプロンプトの設計意図

### なぜ「資料の役割」を明示しているか
3つの資料は目的も詳細度も異なる。Copilotがこれを区別せずに扱うと、平易な説明用の比喩(新人スタッフ、プロの司書など)を技術資料の文脈で使ってしまったり、逆に検証の経緯にある「転換点」を見落として、結論だけを無味乾燥に要約してしまったりする可能性がある。役割を先に伝えておくことで、後の壁打ちで「どの資料のどの位置づけの話をしているか」を、栄さんとCopilotの双方が意識しやすくなる。

### なぜ「理解内容の要約」を最初に求めているか
これは、資料をきちんと読み込めているかどうかを、栄さん自身がすぐに検証できるようにするためのチェックポイントである。長い資料を渡した直後にいきなり成果物(スライド構成)を作らせると、読み違いや読み飛ばしがあっても気づきにくい。要約という軽い成果物を先に出させることで、大きな手戻りを防ぐ。

### なぜ「いきなり構成案を出すな」と指示しているか
発表資料の質は、内容そのものよりも「誰に」「何のために」話すかによって大きく変わる。この前提を確認せずに構成案を作らせると、聴衆の技術理解度に合わない資料や、目的(議論を始めたいのか、承認を得たいのか)とズレた資料ができあがるリスクがある。栄さんが今回の一連の検証で実践してきた「まず目的を明確にしてから動く」という進め方を、Copilotとの壁打ちにもそのまま適用する形にしている。

### なぜ、複数の質問を一度に聞かせているか
聴衆・時間・目的という3つの前提は、互いに影響し合う(例えば聴衆が非技術者なら、時間配分も目的の立て方も変わる)。バラバラに1つずつ聞かれるより、まとめて聞かれて一度に答えた方が、栄さん側の手間も少なく、Copilot側も一貫した前提のもとで構成を考えられる。

---

## 補足:資料をアップロードする際の注意

- Copilotの種類(Microsoft 365 CopilotのチャットUIか、Copilot Studioで作ったカスタムアシスタントか)によって、一度に読み込めるファイルサイズや、添付できるファイル形式(.md非対応でテキストに変換が必要な場合など)に制限があることがある。もし`.md`の添付でエラーが出る場合は、拡張子を`.txt`に変えて試すか、本文をそのままコピーしてチャットに貼り付ける方法に切り替えるとよい
- 資料が3つとも長いため、Copilotが「途中までしか読めていない」状態で応答してしまうことがある。理解内容の要約を確認する際、目次(章立て)がすべて正しく言及されているか、特に念入りに確認することを推奨する