生成AIにお願いしてみたけれど、返ってきた回答を読んで、
「間違ってはいないけど、ほしかったのはこれじゃないんだよな…」
と思ったこと、ありませんか？
こういうズレを減らしたいときは、何をしてほしいかに加えて、目的や前提も伝えるのがコツです。
例えば、誰かに「資料を作って」とだけ頼まれても、ちょっと困りますよね…
「誰向け？」「何のため？」「何ページくらい？」
と聞きたくなるはずです。
生成AIへの依頼でも、同じように情報を添えてみましょう。
この記事では、情報を整理する「5W1H」と、いつものプロンプトに少し足すだけで試せる7つのコツを紹介します！🙌
💡 まず覚えるなら、この3つ！
- 目的：何に使うの？
- 前提：誰向け？ 何を知っている？
- 形式：どんな形で返してほしい？
全部を細かく書く必要はありません。まずは足りない情報を一つ添えるところから始めてみてください。
🗺️ プロンプトは「お願い＋道案内」
「何をしてほしいか」が行き先だとすると、目的・前提・形式は、そこまでの道案内です。
もちろん、短い質問で済む場面もあります。
ただ、回答を読んで「なんか違うな」と感じたときは、言い回しを変える前に、判断に必要な情報が抜けていないかを見直してみましょう。
🔎 何を書けばいいか迷ったら「5W1H」
「目的や前提を伝えるのは分かった。でも、具体的に何を書けばいいの？」
そんなときに使えるのが、5W1Hです。
学校や仕事で聞いたことがあるかもしれませんね。「誰が・何を・いつ・どこで・なぜ・どのように」という、情報を整理するための考え方です。
これを、生成AIへのお願いにも使ってみましょう。
| 項目 | プロンプトで伝えること | 例 |
|---|---|---|
| Who：誰が・誰に | 自分の立場や、回答を届ける相手 | Gitの基本操作を覚えたばかりのエンジニア向け |
| What：何を | やってほしい作業や成果物 | ブランチ運用の説明資料を作る |
| When：いつ | 対象期間、使うタイミング、時間の条件 | 来週の勉強会で、10分間の説明に使う |
| Where：どこで | 使う場所、媒体、実行環境 | 社内Wikiに掲載する |
| Why：なぜ | 目的や、解決したい困りごと | チームのブランチ運用を理解してもらう |
| How：どのように | 出力形式、文体、進め方 | Markdownで、操作例を交えて説明する |
例えば、「Gitについて説明して」というお願いに、5W1Hの情報を足してみます。
😕 改善前
Gitのブランチ運用について説明してください。
😊 改善後
Gitのブランチ運用を説明する資料を作ってください。
【Who：誰向け】
Gitの基本操作を覚えたばかりの、
新しく入ったメンバー向けです。
【What：何を】
以下のチームルールをもとに、
作業開始からプルリクエスト作成までの流れを説明してください。
【When：いつ】
来週の勉強会で使います。
10分で説明できる分量にしてください。
【Where：どこで】
社内Wikiに掲載します。
開発ではGitHubを使っています。
【Why：なぜ】
メンバーがチームのルールを理解し、
迷わず作業を始められるようにするためです。
【How：どのように】
Markdownで、見出しと番号付きの手順を使ってください。
簡単なコマンド例も添えてください。
【チームルール】
（ここに実際のブランチ運用ルールを貼り付けます）
こうして並べてみると、「誰向けかが抜けていた」「使う場所を伝えていなかった」と気づきやすくなります。
ただ、毎回この長さで書くのは大変ですよね。必要な情報がそろっていれば、普通の文章にまとめても大丈夫です。
新しく入ったメンバー向けに、
チームのGitブランチ運用を説明する資料を作ってください。
来週の10分間の勉強会と社内Wikiで使います。
メンバーが迷わず作業を始められるように、
以下のチームルールをもとに、作業開始から
プルリクエスト作成までを説明してください。
Markdownの番号付き手順にして、
簡単なコマンド例も添えてください。
チームルール：
（ここに貼り付けます）
💡 5W1Hは、全部埋めなくても大丈夫
例えば、文章の言い換えを頼むだけなら、「いつ」「どこで」は必要ないかもしれません。
「この情報があると、回答が変わりそうかな？」を目安に、必要なものだけ添えてみましょう。
⚠️ 足りない事実は、無理に埋めない
チームのルールや使用環境が分からないときは、想像で書かず、確認するか「不明」と伝えましょう。
また、「最新の情報で」と書くだけでは、回答が最新であることは保証されません。必要な場合は、対象の日付を指定して、出典も確認してください。
ここからは、5W1Hで整理した情報を、実際のお願いにどう使うか見ていきましょう。
1. 🎯 「何に使うか」まで伝える
最初のコツは、お願いに用途を添えることです。5W1Hでいうと、主に「Why」に当たります。
例えば「Dockerについて説明して」だけだと、入門向けなのか、業務で使う人向けなのかが分かりません。
😕 改善前
Dockerについて説明してください。
😊 改善後
Dockerを初めて使うWebエンジニア向けに、
チームの勉強会で使う説明文を作ってください。
最初に「Dockerで何ができるか」を説明し、
その後にイメージとコンテナの違いを、
簡単な例を使って説明してください。
「勉強会で使う」と分かるだけでも、どんな内容が必要か伝えやすくなります。
💡 迷ったら、この一文を足してみよう
「この回答は、〇〇に使います。」
メールの下書き、勉強会の資料、自分の理解のため……。用途を一つ書くだけでも、依頼が具体的になります。
2. 👤 「初心者向け」を、もう一歩具体的にする
「初心者にも分かりやすく」は便利な言葉ですが、初心者にもいろいろな人がいますよね。
プログラミング自体が初めての人と、Pythonは書けるけれどWeb開発は初めての人では、必要な説明が変わります。
そこで、知っていること・知らないことを分けて伝えてみましょう。
😕 改善前
REST APIを初心者向けに説明してください。
😊 改善後
REST APIについて説明してください。
私はPythonの基本文法は理解していますが、
HTTPやWeb開発の経験はありません。
専門用語は初めて出てきたときに説明し、
簡単なリクエスト例を添えてください。
「自分がどこまで分かっているか」を添えると、知っている話が延々と続いたり、いきなり難しい話になったりするズレを減らしやすくなります。
3. 🧭 条件が多いときは、優先順位をつける
「短くしてほしい。でも詳しく。しかも初心者向けで！」
つい、全部お願いしたくなりますよね。
ただ、条件によっては両立が難しいこともあります。そんなときは、何を一番大切にしたいかも伝えておきましょう。
😕 改善前
このお知らせを、短く、詳しく、
分かりやすく書き直してください。
😊 改善後
以下のお知らせを、社内向けに書き直してください。
条件：
- 300〜500字を目安にする
- 結論を最初に書く
- 日付と対応期限は必ず残す
- 丁寧だけれど、堅すぎない文体にする
文字数に収まらない場合は、
日付と対応期限を残すことを優先してください。
元のお知らせ：
（ここに貼り付けます）
「短さよりも、必要な情報を残してほしい」と分かると、削ってよい部分を判断しやすくなります。
⚠️ 文字数の指定は、最後に確認しよう
文字数を指定しても、ぴったり守られるとは限りません。投稿欄などに厳密な制限がある場合は、出力後に文字数を数えて確認しましょう。
4. 📦 回答の「入れ物」を指定する
内容はよさそうなのに、長い文章が返ってきて、結局自分で表に整理し直した……。
そんなときに効くのが、出力形式の指定です。
使いたい形を、最初に伝えておくのがポイントです。
😕 改善前
この3つの案を比較してください。
😊 改善後
以下の3つの案を比較してください。
Markdownの表で、以下の列を使ってください。
- 案
- メリット
- デメリット
- 向いている状況
表の後に、今回の条件に一番合う案と、
その理由を3文以内で書いてください。
比較する案：
（ここに3つの案を貼り付けます）
今回の条件：
（予算、期限、重視することなどを書きます）
例えば、こんな指定が使えます。
| やりたいこと | 添えると便利な指定 |
|---|---|
| 記事を書く | 見出し構成、想定読者、長さ |
| 選択肢を比べる | 表の列、比較する観点 |
| 手順を知る | 番号付きの手順、各手順の確認方法 |
| コードを作る | 言語、実行環境、入力と期待する出力 |
「何を答えるか」と「どんな形で答えるか」をセットにすると、回答を使うまでの手間を減らせます。
5. 🎨 好みの雰囲気は、短い例で見せる
「自然な感じで」「親しみやすく」と伝えても、思っていた雰囲気と違うことがあります。
文体の好みって、言葉だけで説明するのが難しいんですよね。
そんなときは、短い参考例を見せると伝えやすくなります。
😕 改善前
パスワード再設定の案内文を、
親しみやすい感じで書いてください。
😊 改善後
パスワード再設定の案内文を作ってください。
以下の例のように、短く、やわらかい文体にしてください。
文体と長さだけを参考にし、内容は流用しないでください。
参考例：
「設定を変更したら、最後に保存してください。
次回から、新しい設定でご利用いただけます。」
参考例を渡すときは、「文体だけ」「構成だけ」のように、どこを参考にしてほしいかも添えておくと安心です。
💡 「こうしてほしい」を見せる
「機械っぽくしないで」だけでなく、
「読者に話しかける文体で、短い具体例を添えて」のように、ほしい表現を伝えてみましょう。
6. 🪜 大きなお願いは、少しずつ進める
長い記事や複雑な実装を、一度に完成させたくなることもあります。
でも、完成してから「そもそも方向が違った」と気づくと、直すのが大変です。
まずは構成や方針を出してもらい、確認してから次へ進むと、修正しやすくなります。
😕 改善前
Gitのブランチ運用について、
初心者向けの記事を全部書いてください。
😊 改善後
Gitのブランチ運用について、記事を書きたいです。
読者は、Gitの基本操作を覚えたばかりのエンジニアです。
まずタイトル案を3つと、見出し構成を作ってください。
各見出しには、扱う内容を1〜2文で添えてください。
構成を確認してから、本文の作成に進みます。
記事作成なら、こんな流れで進められます。
一度に渡す情報を増やすだけでなく、途中で方向を合わせることも、プロンプトを使うコツです。
7. 🔧 修正するときは「どこを、どう変えるか」
最初の回答が少し違っていても、そこで終わりにする必要はありません。
追加のお願いで調整していきましょう。
ここでも、「もっとよくして」より、直したい場所と直し方を伝えるのがおすすめです。
😕 改善前
もっと分かりやすくしてください。
😊 改善後
「イメージとコンテナの違い」の説明が、
少し抽象的に感じます。
Dockerの簡単な操作例を一つ追加し、
その例の中で、イメージとコンテナが
それぞれ何に当たるか説明してください。
ほかの見出しと説明は、そのまま残してください。
「残してほしい部分」も伝えると、気に入っていた内容まで変わってしまうのを防ぎやすくなります。
📋 コピペして使えるプロンプトの型
ここまでの内容を、5W1Hを使った型にまとめました。
毎回すべて埋めなくても大丈夫です。必要な項目だけ使ってみてください。
【What：お願い】
何をしてほしいか：
【Why：目的】
何に使うか：
解決したい困りごと：
【Who：読み手・立場】
誰向けか：
すでに知っていること：
【When：時期・時間】
対象の日付や期間：
使うタイミング：
説明や作業に使える時間：
【Where：場所・環境】
掲載する媒体：
使用するツールや実行環境：
【How：形式・条件】
出力形式：
長さや文体：
必ず含めたいこと：
避けたいこと：
一番優先したいこと：
【参考情報】
元の文章、データ、参考例など：
【情報が足りない場合】
結果に大きく影響する情報が不足していれば、
先に質問してください。
軽微な不足は、仮定を明記して進めてください。
短い依頼なら、これくらいでも十分です。
〇〇をしてください。
目的は△△です。
□□向けに、箇条書きでまとめてください。
💡 長いプロンプトを書けばよい、というわけではありません
大切なのは、回答を作るために必要な情報がそろっていることです。
まずは短く頼んでみて、ズレがあったら前提や条件を足していく方法でも大丈夫です。
⚠️ 最後に、回答の確認も忘れずに
プロンプトを工夫すると、ほしい回答に近づけやすくなります。
ただし、読みやすい回答と、正しい回答は別です。
数字や日付、引用、最新の仕様などは、必要に応じて公式情報と照らし合わせましょう。コードも、実際に動かして確認することが大切です。
⚠️ 「正確に答えて」と書くだけでは、正確さは保証されません
特に、次の内容は確認してから使いましょう。
- 数字、日付、固有名詞、出典
- 最新のサービス仕様や料金
- コードの動作やAPIの使い方
- 医療や法律など、誤りの影響が大きい情報
パスワードやAPIキー、個人情報、社外秘の情報を入力する場合も、利用するサービスと所属組織のルールを確認してください。
🌱 まずは、いつものお願いに一文足してみよう
いきなり長いプロンプトを書く必要はありません。
「誰向けか」を足す。
「何に使うか」を足す。
「表で返してほしい」と伝える。
まずは、そのくらいからで大丈夫です。
何を書けばいいか迷ったら、5W1Hを見ながら「回答に影響しそうな情報が抜けていないかな？」と確認してみましょう。
回答を読んで「ここが違うな」と感じたら、そこを具体的に伝えて、少しずつ調整していけばOKです。
次に生成AIを使うときは、いつものお願いに
「この回答は、〇〇に使います」
を一文足してみてください。そこから試してみると、違いを確かめやすいはずです。🙌