
提案書をAIに書かせると、きれいだけれど当たり障りのない文章になりがちです。原因は指示の量にあります。公式ヘルプには、プロンプトに含めるべき要素が7つ挙げられていて、そのまま提案書に使えました。
この記事では、Microsoftの公式ヘルプに書かれている内容だけを並べ、提案書を作る場面に置き直して整理します。内容は公式ページで確認したものです。仕様は更新されるため、運用を決める前には原典で最新の記載をご確認ください。なお、公式に記載のない部分は、実務の提案であることを本文で明示しています。
結論:白紙から書かせない
先に結論を置きます。「提案書を作って」だけで頼むと、どの会社にも出せる文章が返ってきます。それは指示が足りないからです。公式には、何を含めるべきかが具体的に列挙されています。それを埋めてから頼むだけで、出てくるものが変わります。
足りないのは文章力ではなく、前提
Microsoftの公式ヘルプには、こう書かれています。最良の結果を得るには、必要な結果を明確に説明するプロンプトを作成します。そして続きに、含めるべき詳細が並んでいます。対象ユーザー、目的、ソースマテリアル、形式、トーン、長さ、Copilotが従う必要のある制約などの詳細を含めます。7つあります。提案書が当たり障りのない仕上がりになるのは、このうち5つも6つも渡していないからです。文章の質を上げる工夫より、渡す情報を増やすほうが先に効きます。
要素を埋める作業が、提案の整理になる
もうひとつ、副次的な効果があります。7つの要素を埋めようとすると、自分が何を提案したいのかを先に決める必要が出てきます。対象ユーザーは誰か。この提案の目的は何か。根拠になる資料はどれか。ここが曖昧なまま書き始めていたことに、書き出してみると気づきます。プロンプトを整えることが、そのまま提案の整理になる。AIに渡す前の段階で、提案の輪郭が決まります。以降の節で、7つの要素と、公式に示されている構造を見ていきます。
渡す前に埋める7つ
埋める作業が、そのまま提案の整理になる。
公式が挙げている7つの要素
まず、7つを提案書の場面に置き直します。名前だけ見ると抽象的ですが、実際の案件に当てはめると一気に具体的になります。どれも数行で書ける内容なので、書き出しの前にまとめて埋めてしまうのがいちばん早いと思います。
対象ユーザーと目的を、先に書く
1つ目と2つ目が対象ユーザーと目的です。提案書なら、読むのが担当者なのか決裁者なのかで、書き方がまるで変わります。そして目的は、読んだ人に何をしてほしいかです。検討を始めてほしいのか、その場で決めてほしいのか、社内で回してほしいのか。ここから先は実務の提案になりますが、この2つを書くときに、相手の課題を自分の言葉で書いておくと精度が上がります。「コストを削減したい」ではなく、相手が実際に困っている場面まで書く。
ソースと制約は、忘れられやすい
3つ目のソースマテリアルは、根拠になる資料です。議事録、既存の提案書、先方からもらった資料。これを渡さないと、一般論で埋められます。7つ目の制約も見落とされがちです。Copilotが従う必要のある制約と書かれているとおり、してほしくないことを明示する欄です。まだ公開していない価格を書かない、競合の社名を出さない、断定を避ける。提案書では、書かない範囲を決めておくほうが事故が減ります。ここは社内の事情なので、AI側からは分かりません。
形式・トーン・長さで、出来上がりが決まる
残る3つは、仕上がりの見た目に効きます。形式は構造のことで、次の節で扱う「型」がここに入ります。トーンは言葉づかい。公式には絞り込みの例として暖かいトーンを使用しますという指示が挙げられており、あとから変えることもできます。長さは分量です。ここを指定しないと、たいてい長くなります。公式の絞り込み例にもこれを半分に短くしますがあります。先に指定しておけば、削る作業が減ります。提案書は枚数の目安が決まっていることが多いので、ページ数や文字数まで書いておくと手戻りがほとんどなくなります。
提案書の構造は、公式の例にある
ここが実務でいちばん使える部分です。公式が挙げているプロンプトの例のなかに、提案書の構造がそのまま書かれていました。自分で構成を考えて作る必要がありません。書かれているものを、そのまま借りてしまえます。
4つのセクションが例示されている
公式ヘルプの「コンテンツの作成」の項に、こうあります。ドキュメントの種類と希望する構造を指定します。そして例が示されています。背景、利点、リスク、次のステップを含む顧客概要の下書きを作成します。この背景・利点・リスク・次のステップという並びは、提案書の骨格そのものです。ドキュメントの種類と希望する構造を指定する、という指示の形もそのまま使えます。何を作るか、どう並べるか。この2つを書けば、構造が決まります。
「リスク」が入っているのが効く
4つの中で注目したいのがリスクです。提案書を書かせると、たいてい利点ばかりが並びます。読む側からすると、それは警戒の対象になります。リスクを自分から書いてある提案書のほうが、検討の土台に乗りやすい。公式の例に最初から含まれているので、構造を指定するときに落とさずに済みます。ここから先は実務の提案ですが、リスクの節には、対処もセットで書かせると資料として成立します。挙げるだけでは不安を残すだけになります。
「次のステップ」で、提案が動く
もうひとつが次のステップです。提案書の目的が「読んだ人に何かしてもらうこと」なら、最後に行動が書かれていないと止まります。よくあるのが、素晴らしい提案なのに読み終わったあと何をすればいいか分からない資料です。公式の構造には最初から入っているので、指定するだけで付きます。誰が、いつまでに、何をするか。ここまで書かせておくと、そのまま打ち合わせの議題になります。作る側の手間はほとんど変わらないのに、提案が次に進む確率は変わってきます。
既存の提案書を、型として使う
白紙から作るより速い方法も、公式に書かれていました。社内に過去の提案書があるなら、こちらのほうが実務的です。体裁を整える時間がまるごと減るので、締切が近い案件ほど効いてくる、実務的なやり方だと思います。
構造を保ったまま、中身を差し替える
公式ヘルプには、Copilotでできることの1つとして既存の形式と構造を再利用するが挙げられています。説明はこうです。テンプレートまたは既存のドキュメントから開始し、書式設定と構造を維持しながら新しいコンテンツを下書きします。つまり、見た目と並びはそのままで、中身だけ入れ替えることができます。社内で承認された体裁があるなら、それを崩さずに使えるということです。デザインを作り直す手間も、見出しを考える手間もなくなります。
公式が挙げている例
プロンプトの例も具体的です。既存の文書を再利用する:テンプレートまたは文書を再利用し、コンテンツのみを更新します。そして2つ挙げられています。発注書PDFの情報を使用して請求書に入力します。最新の試験製造データを使用して、規制当局の承認パッケージを更新します。どちらも、型は固定で、データだけが変わる作業です。提案書でも同じことができます。前回の提案書を開いて、今回の顧客の情報で更新する。構造を考える工程を飛ばせるのが大きい。
使い回しの注意点
ここから先は実務の提案です。既存の提案書を型にするとき、前の顧客の情報が残っていないかを必ず確認してください。社名や金額は目立つので気づきますが、本文の中に紛れた業界特有の言い回しや、前回だけの前提条件は残りがちです。あとの節で見るとおり、公式も確認すべき項目を挙げています。型として使うファイルは、固有の情報を抜いた「ひな形」を別に作っておくと安全です。1回作れば、以降ずっと使えますし、新しく入った人に渡す資料としてもそのまま機能します。
ソースの指し方が決まっている
根拠になる資料をどう渡すか。ここにも決まった操作がありました。本文にコピーして貼り付けるより、ファイルとして指定するほうが確実です。公式に、その手順が具体的に書かれていました。あわせて注意点もあります。
「/」で指定する
公式ヘルプの手順に、こうあります。特定のソースを使用するには、「/」と入力し、ファイルがある場合は選択します。スラッシュを入れると候補が出る形です。本文にコピーして貼るより短く済み、どのファイルを見たかも明確になります。議事録、前回の提案書、先方の資料。これらを指定してから書かせる。公式の別の例にも[ファイル名]に基づいてセクションを作成しますという書き方が挙げられていて、ファイルを指したうえで作業を指示する形が想定されていると分かります。
指定しなくても、探しにいく場合がある
もうひとつ知っておきたい挙動があります。公式には、Copilotは、ファイル、メール、会議、その他のMicrosoft 365コンテンツなどの関連する作業コンテキストを使用でき、利用可能な場合はWeb情報を使用することもできますとあり、続けてCopilotに特定のソースをポイントするか、プロンプトとアクセス許可に基づいて役に立つコンテキストを使用する場合もありますと書かれています。つまり、指定しない場合は、アクセス権の範囲で勝手に探すことがあるということです。意図しない資料が混ざる余地があります。
引用を付けさせることもできる
できることの1つとして引用の追加も挙げられています。参照元への引用を含むコンテンツを生成するようにCopilotに依頼しますという説明です。提案書に数字を載せるなら、どこから持ってきた数字かが分かる状態にしておくと、社内のレビューが早く終わります。あとから聞かれて調べ直す、という手戻りもなくなります。なお、秘密度についても記載があり、Copilotは、ドキュメントを保護するために、適切な秘密度ラベルを尊重して適用しますとされています。
一度で決めず、絞り込む
最初の出力が思ったものと違うとき、プロンプトを書き直して最初からやり直していないでしょうか。公式は、まったく別のやり方を推奨していました。こちらのほうが速く、しかも結果が安定する、合理的なやり方でした。
やり直すより、絞り込む
公式の提案に、こうあります。最初からやり直すのではなく、フォローアッププロンプトを使用して結果を絞り込みます。そして「結果を絞り込む」の項に説明があります。最初の応答は近いが、正しくない場合は、対象を絞った絞り込みを続行します。例も3つ示されていて、これを半分に短くします。暖かいトーンを使用します。このテーブルをインフォグラフィックとして視覚化します。どれも短い一文です。長い指示を書き直すより、短く足していくほうが早い。
1回に1つだけ頼む
関連する提案として、1つの明確な結果または正確な編集を求めますがあります。まとめて直そうとすると、どれが効いたか分からなくなります。短くする、トーンを変える、構造を変える。1回に1つ。結果を見てから次を決めると、狙ったところに着地します。公式の手順にも下書きを確認し、フォローアッププロンプトを使用して、保持、破棄、再生成、または改良を行いますと書かれていて、確認してから次の操作を選ぶ流れが前提になっています。
モデルの選択は、セッション内だけ
細かい点ですが、覚えておくと便利な記載があります。Copilot in Word が応答を生成するために使用するAIモデルを選択します。選択したモデルは、変更するかセッションを終了するまでアクティブなままです。つまり、選んだモデルはセッションを終えると元に戻ります。長い提案書を数日かけて作る場合、日をまたぐと条件が変わる可能性があります。結果の傾向が変わったと感じたら、モデルの選択を確認してみてください。同じ条件で比べるには、同じセッション内でやることになります。
出す前に確認する項目
最後に、提出前のチェックです。公式には確認すべき対象が名指しで挙げられていて、提案書にはそのすべてが含まれていました。ここを飛ばすと、社外に出てから困ることになります。最後まで手順として見ておきます。
5種類が名指しされている
公式ヘルプには、こう書かれています。Copilotは下書きコンテンツと提案された編集を生成します。詳細(特に事実、番号、引用、名前、ポリシーステートメント、その他の機密情報)を確認して検証します。挙げられているのは事実、番号、引用、名前、ポリシーステートメント、その他の機密情報です。提案書には、このすべてが入ります。金額、導入実績の件数、引用した調査、担当者名、自社の方針。全文を読み返すのではなく、この5種類を拾う。作業として回る形になります。
判断の責任は、出す側にある
続けて、こう書かれています。ドキュメントを共有する前に、Copilotで生成されたコンテンツを保持、変更、または削除するかどうかを決定する責任があります。当たり前のようですが、明記されている意味は小さくありません。AIが書いたから、は理由になりません。提案書は社外に出る文書なので、ここは特に効きます。社内でレビューを回すときも、生成物をそのまま回さず、一度自分で通読したうえで出すのが前提になります。
確認の観点は5つ
もう1つ、公式の提案に確認の観点が示されています。共有する前に、Copilotで生成されたコンテンツの正確性、完全性、トーン、スタイル、安全性を確認します。5つ挙げられています。正確性は事実が合っているか。完全性は抜けがないか。トーンとスタイルは、相手と自社に合っているか。そして安全性は、出してはいけない情報が含まれていないか。前の節で挙げた5種類を拾って、この5つの観点で見る。提出前の手順として、そのまま使えます。
まとめ
提案書をAIに書かせるとき、白紙から頼まないことが前提になります。Microsoftの公式ヘルプは、最良の結果を得るには、必要な結果を明確に説明するプロンプトを作成しますとしたうえで、対象ユーザー、目的、ソースマテリアル、形式、トーン、長さ、Copilotが従う必要のある制約などの詳細を含めますと書いています。7つあります。この要素を埋める作業が、そのまま提案の整理になります。
構造も公式の例にあります。ドキュメントの種類と希望する構造を指定しますとされ、例として背景、利点、リスク、次のステップを含む顧客概要の下書きを作成しますが挙げられています。白紙から作らないなら、テンプレートまたは既存のドキュメントから開始し、書式設定と構造を維持しながら新しいコンテンツを下書きしますという方法もあります。資料の指定は「/」と入力し、ファイルがある場合は選択しますです。
直すときは、最初からやり直すのではなく、フォローアッププロンプトを使用して結果を絞り込みます。そして1つの明確な結果または正確な編集を求めます。最後に確認です。詳細(特に事実、番号、引用、名前、ポリシーステートメント、その他の機密情報)を確認して検証しますとあり、観点として正確性、完全性、トーン、スタイル、安全性が挙げられています。7つ渡して、5種類を拾い、5つの観点で見る。これが手順になります。
よくある質問(FAQ)
提案書が当たり障りのない内容になります
Microsoftの公式ヘルプには、プロンプトに対象ユーザー、目的、ソースマテリアル、形式、トーン、長さ、従う必要のある制約などの詳細を含める、と書かれています。7つの要素のうち渡せていないものがないかをご確認ください。
提案書の構成は、どう指定すればよいですか
公式ヘルプには、ドキュメントの種類と希望する構造を指定する、とあり、例として「背景、利点、リスク、次のステップを含む顧客概要の下書きを作成します」が挙げられています。この4つは提案書の骨格としてそのまま使えます。
過去の提案書を使い回せますか
公式ヘルプには、既存の形式と構造を再利用する方法として、テンプレートまたは既存のドキュメントから開始し、書式設定と構造を維持しながら新しいコンテンツを下書きする、と書かれています。前の案件の固有情報が残っていないかは、ご自身でご確認ください。
根拠の資料はどう渡しますか
公式ヘルプには、特定のソースを使用するには「/」と入力し、ファイルがある場合は選択する、と書かれています。また、参照元への引用を含むコンテンツを生成するように依頼することもできるとされています。
出力が思ったものと違うときはどうしますか
公式の提案には、最初からやり直すのではなく、フォローアッププロンプトを使用して結果を絞り込む、とあります。例として「これを半分に短くします」「暖かいトーンを使用します」といった短い指示が挙げられています。
提出前に何を確認すればよいですか
公式ヘルプには、詳細、特に事実、番号、引用、名前、ポリシーステートメント、その他の機密情報を確認して検証する、と書かれています。また、共有する前に正確性、完全性、トーン、スタイル、安全性を確認する、とも記載されています。
原典で記載を確認する
機能と手順は更新されます。運用を決める前に、Copilot in Word の効果的なプロンプトを作成する(Microsoft Support)で最新の記載をご確認ください。