このレッスンでできるようになること
Grokへの依頼は、長く書けば伝わるとは限りません。必要な情報が少なく、どの状態になれば完成かが明確な依頼の方が、結果を確認しやすくなります。このレッスンでは、曖昧な相談を、目的、材料、制約、出力、確認点に分けて組み立てます。題材は、社内で使うFAQの下書きです。最後には、初めて読んだ人でも同じ作業を頼める依頼文を作ります。
1．目的を相手の行動で書く
「FAQをいい感じに作る」では、何のための文章なのか分かりません。「参加者が開始時刻と参加方法を自分で確認できるFAQを作る」と書けば、必要な質問を選びやすくなります。誰が読んで何を判断するのかを、最初の一文に入れてください。
目的を決めると、不要な情報も見えてきます。参加方法を知りたい人に長い背景説明を読ませる必要はありません。一方、途中参加が可能かなど、読者が迷う点は残す必要があります。情報量を増やすことと、役に立つことを分けて考えます。
2．使う材料と使わない推測を明示する
次に、回答の根拠となる材料を渡します。日時、会場、対象者、費用、問い合わせ先など、確定した情報を短いメモに整理します。資料が複数ある場合は、どれが最新で、どれを優先するかも指定します。資料の数が多いほど、読み取り方の指示が重要になります。
材料にない質問への扱いも決めます。「不明と書き、主催者に確認する項目へ分ける」と伝えれば、完成したように見える架空の回答を減らす方針になります。ただし、その指示で誤りがなくなると保証されるわけではないので、人が根拠を照合します。
例として、会場がオンラインとだけ決まっている場合、特定の会議サービス名を補わないようにします。サービス名が後で変わる可能性もあり、推測した名前を参加者が信じてしまうと案内の訂正が必要になるからです。
3．制約は理由と優先順位を付ける
制約には、文字数、文体、避ける表現、してよい操作の範囲があります。すべてを同じ重さで並べるより、「事実の保持を文字数より優先する」と順位を付けます。短くするために必要な条件を消してしまう失敗を避けやすくなります。
矛盾する条件も点検します。「全項目を説明し、100文字以内で詳しく書く」のように両立しにくい依頼では、何を優先するか人が決める必要があります。Grokに矛盾を指摘してもらう使い方も有効ですが、指摘がないことを、矛盾がない証拠とは扱わないでください。
4．出力形式は使う場所から決める
FAQをWebへ載せるなら質問と回答の組、管理表へ移すなら列名を決めた表が便利です。メール本文として使うなら、箇条書きを多用しない短い文章の方が読みやすい場合もあります。形式を指定する目的は、見た目を整えることだけでなく、後で転記する手間を減らすことです。
ただし、細かすぎる形式を最初から固定すると、内容の不足に気付きにくくなります。まず必要な質問がそろっているか確認し、その後で掲載用の形に整える二段階も使えます。機械で読むデータの場合は、見た目が表になっているだけでは不十分なので、APIコースで構造や検証方法を学びます。
5．良い例と悪い例を一つずつ示す
文体や判断基準が伝わりにくい場合は、短い対比例を添えます。「録画は配布します」は未確定情報を断定する悪い例、「録画配布の有無は主催者へ確認してください」は今回の条件に合う例です。違いが一目で分かる例は、抽象的な注意を何度も重ねるより確認しやすくなります。
例を多く入れすぎると、今回の材料と参考例の事実が混ざることがあります。参考例は例であると明記し、固有名詞や金額を本番に流用しないようにします。依頼文の中でも、入力資料と説明用の例を別の段落に置きましょう。
6．一つずつ改善して差を測る
回答が期待と違ったら、目的、材料、制約、形式のどこに原因があるか考えます。質問が読者に合わないなら目的、事実が抜けるなら材料の渡し方、長すぎるなら形式や文字数を見直します。毎回全部を変えると、どの変更が効いたのか分からなくなります。
同じ入力で条件を一つだけ変え、前後の回答を比べます。文字数が減っても必要情報が消えていれば改善ではありません。事実が保たれ、使う人が次の行動を取れるかで判断します。この記録を残すと、次の仕事にも使える依頼文へ育てられます。
実践課題と完了チェック
自分の曖昧な依頼を一つ選び、五つの要素へ書き直してください。入力不足ならどうするか、どの条件を優先するかも加えます。結果を確認する人が、合格と不合格を見分けられる基準を三つ書ければ完了です。依頼文は一度で完成させる必要はありません。実際の回答から不足を見つけ、少しずつ改善するための設計図として使いましょう。
