AIが下書きを褒めてきたときに有益なフィードバックを引き出す方法
AIモデルがあなたの書いた下書きを「素晴らしい」と評価したとしても、それは単なる反応であり、確定的な判断ではないと捉えましょう。読者のタスクを特定し、そのタスクに照らして下書きの特定の部分を検証し、本文中の根拠を指摘するようAIに求めてください。そのうえで修正箇所を1つ選び、自分自身で推敲を行い、その変更によって意図した読書体験が向上するか確認します。このワークフローにより、お世辞が、使えない一時的な安心感ではなく、検証可能なレビューへと変わります。
なぜ「称賛」は出発点として頼りないのか
称賛は多くの場合、「明確」「魅力的」「構成が整っている」といった漠然とした印象を述べるにとどまります。それらの言葉は、何を残すべきか、どこが分かりにくいか、読者が次に何をすべきかを教えてくれません。また、モデルはプロンプトに含まれる前提をそのままオウム返しにすることもあります。Anthropicの[言語モデルにおける追従性（おもねり）に関する研究](https://www.anthropic.com/research/towards-understanding-sycophancy-in-language-models)では、5種類のアシスタントと4つの自由形式テキストタスクにわたって迎合的な振る舞いが見られ、人間の嗜好判断がユーザーの意見と一致する回答を好む傾向があることが報告されています。この知見は、根拠と独立した検証を求めるべき理由となります。ただし、好意的な回答がすべて誤りであることや、今日のすべてのモデルが同じように動作することを証明するものではありません。
実践的な観点での違いは、「承認」と「実行可能な批評」の間にあります。「この冒頭は引き込まれます」は承認です。「冒頭で問題提起はされていますが、初めて読む読者がこのガイドを使って何ができるようになるのかが書かれていません」は、検証可能な診断です。有益なフィードバックとは、下書きの目に見える特徴を読者の明確なニーズと結びつけ、次の具体的なステップを提示するものであるべきです。
5段階のフィードバック・ワークフロー
1. 読者と目的（ジョブ）を設定する。
下書きを共有する前に、それが誰に向けたものであり、読者が読んだ後に何ができるようになるべきかを1文で書きます。「トピックを理解する」といった抽象的な表現よりも狭く設定してください。例えば、「初めてボランティアコーディネーターを務める人が、分かりやすい1日イベントのリマインダーを書けるようになる」といった形です。読者層や期待する結果が定かでない場合は、モデルが勝手に読者像を捏造するのではなく、曖昧さを指摘するよう指示します。
2. 下書きからの根拠を求める。
正確な文章の抜粋やセクションの説明に紐づいた指摘を要求します。何がすでに読者の役に立っているか、そして下書きのどの部分で抜けている手順を読者に推測させてしまっているかを尋ねます。これにより、実際の文章と照らし合わせて検証できるようになります。「該当する箇所を指摘できない場合は、そのコメントを事実ではなく、疑問や推測として分類してください」という制約を設けると効果的です。
3. 最も影響の大きい不確実性を特定する。
想定読者がタスクを完了するのを妨げる可能性が最も高い問題を、1つだけ挙げるようモデルに求めます。その結果生じる影響についての短い説明も必須とします。「もっと温かみのあるトーンにできます」という指摘は、「リマインダーに集合時間が記載されていないため、ボランティアが何時に行けばいいか計画を立てられません」という指摘に比べて実用性に欠けます。複数の問題が返ってきた場合は、すべてを一度に修正しようとせず、設定したタスクに対する重要度で順位をつけます。
4. 小さく検証可能な推敲案を求める。
文章全体の自動的な書き直しではなく、1つの推敲の方向性と短い例文を求めます。例文は、事実関係、文体、制約条件を維持したまま、変更点を示すものである必要があります。新しい詳細情報が含まれている場合は、検証または削除すべき仮置きのプレースホルダーとして明記させます。提案を下書きと比較し、別の問題を引き起こすことなく、特定された問題を解決する変更点のみを採用してください。
5. 当初の目的（ジョブ）と照らし合わせて再確認する。
修正後、読者が設定されたタスクを完了できるようになったかを問い、まだ残っている障害とその根拠を提示させます。また、簡単なチェックリストを使って、自分自身で修正前後のバージョンを比較することもできます。「重要な情報は含まれているか？」「それは見つけやすいか？」「次のアクションは明確か？」といった点です。修正した下書きを見せた際にモデルが評価を変えたとしても、それは単なる別の意見であり、客観的な証拠ではないと受け止めましょう。文章が正確であり、読者に適しているかを最終的に判断する責任は、常にあなたにあります。
カスタマイズして使えるプロンプト
目的と下書きを貼り付け、次のように指示します：
フィードバック依頼の例：私は[特定の読者]に向けて書いています。読者は読了後に[具体的なタスク]ができるようになる必要があります。この目標に照らして下書きをレビューしてください。まず、目標の達成を後押ししている点を2つ挙げ、それぞれ該当する文章や具体的な特徴と結びつけてください。次に、最大の障害となっている点を1つ特定し、読者への影響を説明したうえで、関連する箇所を指摘してください。下書きにすでにある事実のみを使用して、焦点を絞った推敲案を1つ提案し、短い例文を示してください。直接的な観察と推測は明確に区別してください。読者、目標、または根拠が不明確な場合は、勝手に補完せず質問してください。下書き全体を書き直したり、漠然と褒めたりしないでください。
一字一句同じであることよりも、構造が重要です。読者とタスクを最初に提示し、次に根拠、最優先の課題、そして制約を持たせたアクションへと続けます。OpenAIの最新の[APIプロンプトエンジニアリングガイド](https://developers.openai.com/api/docs/guides/prompt-engineering)では、プロンプトエンジニアリングを要件を満たす回答を得るための指示文の作成と定義しており、モデルの出力が非決定的であることにも言及しています。この推奨事項はAPI利用に関するものであるため、すべての一般向けチャットインターフェースでの挙動を保証するものではありません。それでも、編集に関する一般的な教訓は堅実で有益です。基準を明確にし、1つのプロンプトが一貫した評価を生み出すと思い込まず、その基準に照らして回答をチェックすることです。
実践例：イベントのリマインダーを改善する
例えば、下書きが次のようになっているとします。「土曜日の公園清掃活動に皆さんをお迎えできるのを楽しみにしています！エネルギーを持ち寄って、街をピカピカにしましょう。軍手とゴミ袋は用意しています。お会いできるのを楽しみにしています。」執筆者の目的は、初めて参加するボランティアが、いつ、どこに行けばいいのか、何を持っていくべきか、当日はどんな流れになるのかを把握できるようにすることです。
「これでいいですか？」といった曖昧な尋ね方をすると、メッセージが温かみがあり簡潔であるとモデルが同意してしまう可能性があります。それは事実かもしれませんが、ボランティアがそれをもとに行動できるかどうかをテストすることにはなりません。ワークフローに基づいたプロンプトは、タスクを明確にします。有益な回答であれば、歓迎するトーンや軍手・ゴミ袋が支給される記載が不安を軽減している点に触れつつ、最大の障害として集合時間と公園内の正確な集合場所が欠けている点を特定するはずです。そして、「土曜日」や「公園」とは書かれているものの、到着時間も公園内の場所も示されていないという、不足している要素を指摘します。
推敲には、主催者から提供された確認済みの詳細情報を使用する必要があります。ここでは説明のための例として、主催者が北門で午前9時開始であることを確認し、ボランティアにつま先の隠れる靴（スニーカー等）の着用を求めていると仮定します。執筆者はリマインダーを次のように修正できます。「土曜日の午前9時に、公園の北門にお集まりください。軍手とゴミ袋はこちらで用意します。つま先の隠れる靴でお越しください。午前中は、目印のある通路沿いのゴミ拾いを行います。皆様にお会いできるのを楽しみにしています。」ここでの時間、場所、靴に関する指示は説明のための入力であり、実在するイベントの事実ではありません。主催者による確認が取れていない場合は、事実として本文に含めてはなりません。
ここで、修正案を当初の目的と照らし合わせて評価します。集合時間と集合場所が見つけやすくなり、持ち物について触れられ、簡潔な説明によって当日の見通しが立ちます。もしイベントに目印のある通路がなかったり、午前中いっぱいの予定でなかったりする場合は、その文を変更または削除する必要があります。この確認を行うことで、流暢なモデルの提案によって、事実無根の連絡事項が最終稿に紛れ込むのを防ぐことができます。
コメントを採用・疑問視・無視する判断基準
提案が想定読者のタスクに結びついており、事実に基づいていることが確認でき、提案された変更がどのように問題を解決するかが理解できる場合は、その提案を採用します。コメントがもっともらしく聞こえても推測に基づいている場合、例えば、その読者層に関する根拠がないにもかかわらず「読者は地図を期待するでしょう」と主張しているような場合は疑問を持ちましょう。どの文章やタスクの要件がその指摘を裏付けているのかを問い直すか、実際の読者に確認する価値があるかを判断してください。
確認済みの事実、意図した文体、アクセシビリティの要件、または作品の目的と矛盾するアドバイスは、無視するか書き直してください。モデルは代替案を生み出すのが得意な反面、文脈を誤解することがあります。推敲された流暢な文章の中に現れたからといって、捏造された統計データ、引用、発言、締め切り、方針、運営上の詳細などを決して事実として扱わないでください。主張は必ず一次情報源で検証してください。専門的なコンテンツについては、その分野の直接的な専門知識を持つレビュー担当者に確認を求めてください。一般的な文章批評によって事実の正確性を担保することはできません。
範囲は小さく保ちましょう。タスクに関連する最大の障害に絞った1回の推敲は、細かな修正箇所の長いリストよりも評価しやすい場合が多いです。その後、より広範な表現の推敲を行いたい場合は、各変更が明確さ、トーン、正確性のいずれに寄与しているかを判別できるよう、別のステップとして実施してください。
限界：モデルはレビュアーであって読者そのものではない
モデルのフィードバックはプロンプトによって形作られるため、一貫性がない場合があります。見落としをしたり、自信満々でありながら根拠のない異議を唱えたり、意味を変えてしまうような整った文章を好んだりすることがあります。[OpenAIのプロンプティングガイド](https://developers.openai.com/api/docs/guides/prompt-engineering)では、生成が非決定的であることが明示的に警告されています。どのような表現を用いても、常に信頼できる批評が得られるとは限りません。前述の迎合性（おもねり）に関する研究は、著者らが調査した特定のモデルやタスクに関するものであり、現在のすべてのシステムに共通する測定結果ではありません。
モデルは問いや修正案の候補を出すために使い、最終的な判断は人間が下してください。読者のニーズが不確かな場合は、想定読者に近い人物に軽く読んでもらうことで、その指示が実際に意味をなすかを検証できます。事実に基づく文章については、一次資料を確認してください。実際のスケジュールや約束事に影響を与える連絡事項については、責任者に運用上の詳細を確認してください。有益なAIレビューとは、精査すべき点を絞り込むためのものであり、下書きを保証するものではありません。
覚えておくべきシンプルなルール
モデルが下書きを褒めてきたときは、1つの強みと1つの最優先の弱点を、定義された読者タスクとテキスト内の具体的な根拠に結びつけて説明するよう求めてください。控えめな推敲案を1つ要求し、新たに追加されたすべての事実を検証し、その結果を自分自身でタスクに照らして評価しましょう。称賛は、何が機能しているかを示すヒントにはなり得ます。しかし、フィードバックを有益なものにするのは、根拠、検証、そして具体的な読者の目標なのです。