この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。Microsoft公式資料を2026年10月20日に確認し、架空データで試せるプロンプトと確認手順を作成しました。Copilot画面での実行は行っていません。検証ステータス：📘 公式情報確認済み・プロンプト実行未確認
対応環境・できること・制限事項（公式確認：2026年10月20日）
| 項目 | 本例の対象と範囲 |
|---|---|
| 製品・入口 | 職場向けMicrosoft Copilot Chat（旧称Microsoft 365 Copilot Chat）。Web版の通常チャットを想定 |
| アカウント・契約 | 組織で利用を許可された職場アカウント。自分の契約と管理者設定で利用可能か確認する。個人用Copilotは本例の対象外 |
| 追加契約・課金 | Officeアプリ内の追加機能や、従量課金のエージェントは本例で使わない。追加契約が必要な機能まで利用できると解釈しない |
| 入力・保存場所 | 架空のテキストを直接貼り付ける。ローカルパス、OneDrive、SharePoint、受信箱は接続しない |
| 試す操作 | 入力した文章の参照・整理・比較・下書き作成。内容は人が原文と照合する |
| 本例の対象外 | ファイル検索、文書の直接編集・移動・削除、メール送信、業務システムへの登録 |
| 上限・提供状態 | プレビュー機能を前提にしない。入力長・回数・地域・画面差の数値や実機ビルドは未確認。長い入力は区切り、利用可否は画面で確認する |
| 情報管理 | 最初は架空データのみを使う。業務情報への拡大は組織の許可と情報区分を確認する。指示文だけをアクセス制御やWeb検索停止の保証にしない |
案内文をFAQへ変えると、必要な情報を探しやすくなります。一方で、答えを短くする過程で「事前申請が必要」「対象は貸出品だけ」といった条件が消えることがあります。Copilot Chatでは、質問と回答に加えて、適用条件と根拠を残す形で下書きを作ります。
架空の備品貸出案内を質問へ変える
この例は、三行の架空案内から作るFAQです。規程や法律の解釈を求めるものではありません。ファイルをアップロードせず、案内文をテキストとして貼り付けます。試行では事前知識を使わせず、文面から答えられる範囲を限定します。
以下の架空案内だけを使ってFAQを作ってください。 列は、質問／回答／適用条件・例外／根拠行。 同じ質問の言い換えで件数を増やさないでください。 答えが本文にない質問は、回答を創作せず「案内の管理者へ確認」にします。 回答だけを読んでも条件が分かるようにしてください。 L1：貸出用タブレットは、利用日の3営業日前までに予約してください。 L2：当日の空きがある場合も、担当窓口への事前確認が必要です。 L3：充電器はタブレットと一緒に返却してください。私物の充電器は対象外です。 必ず含める質問：当日でも借りられますか／充電器だけ返してよいですか／休日も受け取れますか。
「当日でも借りられる」とだけ答えたら条件の脱落です。空きがあることと担当窓口への事前確認が必要です。また、休日の受取りは案内に書かれていません。一般的な窓口営業時間を推定して答えさせないようにします。
短い回答と正確な回答を両立させる
FAQでは、質問へ直接答える文章が望まれます。しかし「はい」「いいえ」だけでは、実際の行動に必要な条件が残りません。「当日分は空きと窓口への事前確認が必要です」のように、結論と条件を同じ回答へ置きます。
| 質問 | 期待する回答の骨格 | 要確認点 |
|---|---|---|
| 当日でも借りられるか | 空きがあり、担当窓口へ事前確認した場合に検討できる | 借用の確約にはしない |
| 充電器だけ返してよいか | 貸出用はタブレットと一緒に返却 | 私物の扱いを混ぜない |
| 休日も受け取れるか | 案内だけでは判断できず、管理者へ確認 | 営業時間を作らない |
この表は照合用の期待例です。実際のチャット出力ではありません。回答に条件を入れると少し長くなりますが、条件を別の欄に押し出しすぎると、回答だけを転載した際に誤解が生じます。短くする範囲を人が決めます。
「三営業日前」も重要です。単に「三日前」と書き換えると、休日を挟んだときに意味が変わります。この案内だけでは営業日のカレンダーが分からないため、具体的な予約締切日までは計算しません。日付計算を追加するなら、別途営業日情報が必要です。
答えられない質問を残す価値
FAQ作成で埋まらなかった質問は、失敗の一覧ではありません。案内の不足を発見する材料になります。休日の受取り、故障時の連絡先、延長手続など、利用者が自然に疑問に思うことが本文にないなら、管理者へ追加を相談できます。
ただし、AIが挙げた疑問をすべて案内へ追加する必要はありません。実際に問い合わせが多いもの、誤解が事故につながるもの、利用開始に必須のものから優先します。FAQを長くしすぎると、読者が必要な答えへたどり着けなくなるためです。
質問の言い換えも整理します。「当日借りられるか」と「予約なしで利用できるか」は似ていますが、前者は日程、後者は手続の話です。同じ回答でよいかを確認し、根拠が異なる場合は無理に統合しません。件数より検索意図のまとまりを見ます。
条件を一つ変えて、回答の変化を見る
L2を「当日の貸出しは行いません」に置き換えて、新しい会話で同じ依頼をします。期待する変化は、当日借用の回答が不可になることです。L1の通常予約やL3の充電器返却条件は、そのまま残ります。
変更前の「空きがあれば」という情報が新しいFAQへ混ざっていないかを確認します。同じ会話で更新を続けると、旧版の条件が残る場合があります。改訂時は版番号と本文全体を渡し、どの版だけを根拠にするか指定すると照合しやすくなります。
同じ質問を二回試した際、表現が違うだけなら問題とは限りません。条件、可否、確認先が同じかを見ます。文字列の完全一致を正解にすると、自然な言い換えまで誤りとして数えてしまいます。評価対象は回答の意味です。
原文の矛盾をFAQで隠さない
古い案内が混ざると、一方に「当日可」、他方に「当日不可」とあることがあります。この場合は、多数決や文章の新しそうな印象で選ばせません。更新日と承認版が分からなければ、矛盾のある箇所として管理者へ戻します。
例外条件が長い場合も、都合のよい部分だけ抽出しないようにします。「ただし」「原則」「対象外」「別途」の語がある文を確認し、回答の対象がどこまでかを読みます。単語の存在だけで機械判定はできませんが、見直す場所の目印にはなります。
FAQへ変換すると説明の順番が変わるため、原文の段落にあった前提が抜けやすくなります。たとえば冒頭に「貸出用」と書かれているのに、個々の回答から消えると、私物まで対象と読めます。各回答を単独で読んで確認する工程を置きます。
回答を探しやすくする質問名を選ぶ
原文に忠実な回答でも、質問が利用者の言葉と違えば見つけてもらえません。「予約手続の例外」より「当日でも借りられますか」のように、実際に聞かれそうな表現を候補にします。質問名は読みやすく変え、回答の条件は元の案内へ結び付けたままにします。
検索のための言い換えを付ける場合、別の回答を増やすより、同じ回答へ誘導する関連語として管理する方法があります。内容がほぼ同じFAQを複数作ると、改訂時に一つだけ更新されて食い違う原因になります。質問の数を増やすことが目的にならないようにします。
回答を一画面に収める必要がある場合も、例外条件を削る代わりに、詳細へ進む導線を検討します。ただしリンク先が実在し、利用者が閲覧できることを確認します。AIが生成した、ありそうな手続ページのURLをそのまま掲載してはいけません。
FAQの試用では、案内を読んでいない人に質問だけを見せ、期待した答えへたどり着けるかを確認できます。答えを見つけた後に、当日利用の条件を説明できるかを聞けば、発見しやすさと理解しやすさを別々に評価できます。
問い合わせが減らなかった場合は、文章が悪いとすぐ判断せず、置き場所や検索方法も見ます。回答の正確さ、質問の言葉、公開場所はそれぞれ別の改善点です。Copilotに文章を何度も長くさせる前に、どこで利用者が迷ったかを記録します。
公開前に管理者が確認する
架空例で形を試した後、実際の案内を使う場合は入力先の承認と情報範囲を確認します。窓口名や内線番号を含む案内なら、公開用FAQへそのまま出せるかも別途判断します。内部向けの文章を整理したことだけで、外部公開の許可が生じるわけではありません。
完成したFAQは、案内の管理者が内容を確認し、対象の版と確認日を記録します。元文書が変わったら、根拠行を手掛かりに関連する質問を洗い出します。質問ごとに出典が残っていれば、FAQ全体を最初から書き直さずに済む場合があります。
運用では、答えられなかった問い合わせも記録します。既存FAQで解決できたか、条件が分からなかったか、案内自体に情報がなかったかを分けると、文章の改善と業務ルールの確認を混同せずに進められます。
FAQの完成度は、回答数ではなく、利用者が迷わず正しい行動を選べるかで決まります。答えの根拠、適用条件、確認先を残せば、短い質問形式でも情報を落としにくくなります。AIが埋められなかった欄は、管理者が確認すべき場所として活用できます。
公式情報・一次情報
製品の範囲と入力方法は公式資料を参照しています。架空データ、プロンプト、期待例、点検表は本記事の検証案であり、Microsoftが保証する出力例ではありません。
