はじめに
4月15日にGemini公式プロンプトガイドの記事を書いたとき、正直、表面しか理解できていなかった。
ここ最近はどのAIを使うにしても、ChatGPTのカスタム指示やGeminiのGem、ClaudeのProjectsといった「カスタムAI的な機能」を使うことが増えていた。おかげで自分でゼロからプロンプトを考える機会がめっきり減っていた。
そんな状態でSkyworkに調査資料を作ってもらい、改めて読み込んでみたら——
- 「あ、Geminiには全然違う使い方があった」
- 「というか、AIごとに“正解の型”が違ったのか」
と気づいた話を今回は書きます。
完璧に使いこなせているわけではなく、あくまで「途中経過」のレポートです。同じように「なんとなくプロンプトを書いていた」という方に、少しでも参考になれば。
第1章:そもそも「構造化プロンプト」とは何か
普段、AIへの指示をどう書いているだろうか。
「ブログ記事を書いて」「要約して」「アドバイスをちょうだい」——こういった書き方は、いわゆる「非構造化プロンプト」と呼ばれる。伝えたいことはわかるが、AIにとっては「どの範囲で」「誰向けに」「どんな形で」答えるべきかが曖昧なままだ。
構造化プロンプトとは、この曖昧さを排除するために「役割・背景・指示・出力形式」を整理して伝える手法のこと。AIが「考えるべき範囲」を明示的に絞り込むことで、出力の精度と再現性が大きく上がる。
Googleの公式ドキュメントでも、Geminiに対してはこの構造化プロンプトが推奨されている。その理由が、Geminiの内部動作にある。
|
💡 ポイント |
|
AIへの指示は、「ざっくりお願いする」より「仕様書を渡す」感覚が正解。 |
|
構造があるほど、AIは「何を・誰向けに・どう答えるか」を絞り込める。 |
なぜGeminiは「構造がある指示」に強く反応するのか
Geminiをはじめとする大規模言語モデルは、入力された情報の「どこに注目するか」を確率的に判断しながら回答を生成している。このとき、情報がバラバラに書かれていると、モデルは「何が重要か」を自分で判断しなければならない。
構造化プロンプトを使うと、この「判断コスト」をモデルに丸投げせず、設計者(=私たち)が代わりに果たしてあげることになる。専門用語では「コンテキスト・アンカリング」と呼ばれ、モデルの注意を必要な制約や情報に固定させる効果がある。
特にGeminiは、提供されたコンテキストを非常に重く評価する傾向があるとされており、「何を伝えるか」より「どう整理して伝えるか」の影響が大きい。
|
💜 Hiroroのひとこと |
|
正直に言うと、これを読んで「だから返答の質にムラがあったのか」と思った。 |
|
同じ内容を聞いているはずなのに、ある日はいい回答が来て、ある日はズレた返答が来る。 |
|
「なんとなく伝えていた」ことが、そのまま「なんとなくの結果」につながっていたんだと気づいた。 |
第2章:Geminiに効く「4つの型」全解説
Googleの公式ガイドでは、効果的なプロンプトを構成する4つの要素が示されている。「ペルソナ」「タスク」「コンテキスト」「フォーマット」だ。
以下の比較表を見てほしい。
|
構成要素 |
役割 |
具体例(OK) |
NG例 |
|
ペルソナ |
誰として答えるかを決める |
「Google Cloud専門のSREエンジニアとして」 |
「親切に答えて」 |
|
タスク |
何をするか(動詞で始める) |
「以下の3点を箇条書きで分析して」 |
「いい感じにまとめて」 |
|
コンテキスト |
背景・材料を渡す(冒頭に置く) |
「以下のブログ記事のデータを前提に」 |
(何も渡さず質問だけする) |
|
フォーマット |
出力の形を指定する |
「Markdownの表形式で出力して」 |
(形式を何も指定しない) |
① ペルソナ——誰として答えさせるか
ペルソナとは、AIに「どのような専門性・立場・語り口で答えるか」を設定する部分だ。
「親切に答えて」「プロとして」という抽象的な設定より、「Google Cloud専門のSREエンジニア」「副業初心者向けのブログライター」のように具体的に役割を与えるほど、回答の語彙・深度・トーンが変わってくる。
AI副業やブログ執筆においては、「読者層に合った専門家」のペルソナを設定するだけで、出力の質感が一段上がる実感がある。
② タスク——何をやらせるか(動詞で始める)
タスクは「実際に何をしてもらうか」の指示だ。重要なのは、「分析して」「要約して」「作成して」のように動詞で明確に始めること。
さらに、複雑な依頼の場合はひとつの大きな指示にまとめるより、「まず〇〇して、次に△△し、最後に□□してください」とサブタスクに分解するほうが精度が上がる。Geminiは段階的な指示に対して、論理的に処理してくれる傾向がある。
③ コンテキスト——どんな背景・材料を渡すか(冒頭に置く)
コンテキストは「AIが判断の根拠にすべき情報や背景」を渡す部分だ。
ここで覚えておきたいのが「コンテキストはプロンプトの冒頭に置く」というルールだ。Geminiは提供されたコンテキストの内容を指示そのものより優先して反映する特性があるため、最初に読み込んだ情報が回答に強く影響する。
|
💜 Hiroroのひとこと |
|
これを知って、実際に試してみた。 |
|
いつもは「〜を書いて。参考に以下のデータを見て」と後ろにデータを付けていたのを |
|
「以下のデータを前提にしてください→(データ)→それをもとに〜を書いて」という順番に変えた。 |
|
回答の精度が明らかに変わった。順番ひとつで違いが出るとは思っていなかった。 |
④ フォーマット——どんな形で出してもらうか
フォーマットとは、回答の出力形式を指定する部分だ。「Markdownの表形式」「箇条書きで3点」「メール本文の形で」など、最終的にどう使うかに合わせた形式を指示する。
特にブログ記事の構成案やSNS投稿文を作ってもらう場合、フォーマットを指定するだけで「そのままWordPressに貼れる状態」で返ってくることが増える。
第3章:XMLタグで情報を「仕切る」と何が変わるのか
4要素を整理しても、「指示」と「データ」が同じ文章の中に混在していると、AIはどこまでが指示でどこからがデータなのかを判断しなければならない。
これを解決するのが、XMLタグを使った情報の分離だ。Googleの公式ドキュメントでも、以下のような形が推奨されている。
|
XMLタグ構造の基本例 |
|
<context> |
|
私はAI副業ブログを運営する45歳のブロガーです。 |
|
読者は副業初心者の30〜50代です。 |
|
</context> |
|
<task> |
|
以下のテーマで記事の見出し構成案を3パターン作成してください。 |
|
テーマ:NotebookLMを使ったブログ記事作成 |
|
</task> |
|
<format> |
|
各パターンに大見出し3つ、小見出し各2つ。 |
|
箇条書き形式で出力してください。 |
|
</format> |
タグを使うことで、AIは「ここからここまでが背景情報」「ここからが実行すべき指示」と明確に区別して処理できるようになる。
また、外部からの悪意ある命令をプロンプト内に埋め込む「プロンプト・インジェクション」への対策としても、タグによる区分けは有効とされている。
|
⚠️ 制作メモ |
|
この章はSkyworkで作成した調査資料をもとに整理しています。 |
|
公式ドキュメントではXMLタグの使用が推奨されており、理論上の有効性は記載されていますが、 |
|
実際の効果については私自身でまだ本格的な検証中です。 |
|
「試してみたら確かに変わった」という体験が出たら、改めてレポートします。 |
第4章:Gemini 3が「答える前に考える」って本当?
Gemini 3シリーズには「ダイナミック・シンキング」と呼ばれる機能が搭載されている。簡単に言えば、回答を生成する前に「内部で思考プロセスを走らせる」という仕組みだ。
これによって、複雑な依頼に対してより精度の高い回答が得られるようになった一方、タスクの難しさによって回答にかかる時間や精度が変わってくる。
thinking_levelの4段階
APIレベルでは「thinking_level(思考レベル)」というパラメータで、AIがどれほど深く考えるかを制御できる。以下の表にまとめた。
|
レベル |
適した作業の例 |
特徴 |
|
HIGH |
複雑な記事構成・複数条件の分析・コード検証 |
深く考える。回答が遅くなる場合あり |
|
MEDIUM |
一般的なブログ記事・Q&A対応・通常の要約 |
精度とスピードのバランス型 |
|
LOW |
単純な感情分析・定型文作成・短い返答 |
速度優先。シンプルなタスク向け |
|
MINIMAL |
分類タスク・ごく短い返答(Flash系モデル専用) |
最小コスト。思考をほぼ省略 |
|
💡 ポイント |
|
Geminiが遅いと感じるときは、複雑な問いに対して深く考えてくれているサインかもしれない。 |
|
難しい依頼ほど、「深く考える」ための時間が必要——人間と同じ理屈だ。 |
なお、この思考レベルの設定はAPIを使う開発者向けの機能であり、通常のGemini.google.comやGemini Appでは意識する必要はない。ただし「なぜGeminiの回答速度に差があるのか」を理解する上でのヒントになる。
|
💜 Hiroroのひとこと |
|
正直、最初は「思考レベルって何?」という感じだった。 |
|
でも「タスクの難しさに合わせてAIの考え方を調整できる」と理解したら、 |
|
指示の出し方を見直すきっかけになった。 |
|
難しいことをお願いするときは、それに見合った「丁寧な指示の設計」が必要なんだと気づいた。 |
|
これはAPIに限らず、普通に使う場面でも意識できることだと思う。 |
第5章:プロンプトの「配置ルール」を知るだけで精度が上がる
4要素がわかっても、プロンプト内の「情報の順番」を間違えると効果が半減することがある。Googleの公式ガイドでは、以下の順番が最適とされている。
- ① コンテキスト(背景・材料)→ まず読み込ませる
- ② タスク(何をするか)→ 次に目的を伝える
- ③ 制約・フォーマット → 最後に条件を付け加える
特に重要なのが「ネガティブ制約(禁止事項)は最後に書く」というポイントだ。「〜を含めないで」「〜は絶対に書かないで」といった制約を後ろに置くと、モデルが回答を生成する直前に読み込む情報として残るため、読み飛ばしが起きにくくなる。
Before/After:実際の比較
以下の比較を見てほしい。同じ依頼でも、構造の有無でこれだけ違う。
|
❌ Before(改善前) |
✅ After(改善後) |
|
ブログ記事を書いて。テーマはAI副業。 |
【コンテキスト】私はAI副業ブログを運営する45歳の個人ブロガーです。読者は30〜50代の副業初心者です。【ペルソナ】あなたはSEOに詳しいブログライターです。【タスク】以下のテーマで2000字程度の記事構成案を作成してください。テーマ:AI副業の始め方【フォーマット】大見出し3つ、各見出しに小見出し2つ、箇条書き形式で出力してください。 |
スプリット・ステップ検証——「まずできるか確認させる」発想
AIが回答を自信満々に作ってくれても、前提情報が不足していると的外れな内容になることがある。それを防ぐための手法が「スプリット・ステップ検証」だ。
具体的には、いきなり実行させるのではなく「まずこの作業に必要な情報や条件が揃っているか確認してください。揃っていない場合は、何が足りないかを教えてください。確認できたら実行してください」という形で、確認ステップを先に挟む。
|
💡 ポイント |
|
一発で答えさせるより、「確認→実行」の2段階にするほうが、精度が上がることがある。 |
|
特に複雑な依頼や、前提条件が多い作業で効果的。 |
第6章:AI副業・ブログ運営への応用——コピペテンプレート集
ここまでの内容を、実際のブログ運営・AI副業の場面に落とし込んだテンプレートを3つ紹介する。そのまま使ってもらって構わない。
テンプレート①:ブログ記事構成案の依頼
|
コピペ用テンプレート①(ブログ記事構成) |
|
<context> |
|
私は[あなたのブログジャンル]のブログを運営しています。 |
|
読者は[読者層]です。 |
|
</context> |
|
<persona> |
|
あなたはSEOに詳しいブログライターです。 |
|
</persona> |
|
<task> |
|
以下のテーマで記事の構成案を作成してください。 |
|
テーマ:[テーマを入力] |
|
</task> |
|
<format> |
|
大見出し3〜4つ、各見出しに小見出し2つ。 |
|
読者が「読んでみたい」と思える言葉を使ってください。 |
|
出力は箇条書き形式で。 |
|
</format> |
テンプレート②:X投稿文の作成依頼
|
コピペ用テンプレート②(X投稿文) |
|
<context> |
|
私はAI副業ブログを運営するブロガーです。 |
|
以下のブログ記事のURLと要旨をもとに投稿文を作ってください。 |
|
記事URL:[URL] |
|
記事の要旨:[3行程度で記事の内容を記入] |
|
</context> |
|
<task> |
|
この記事を紹介するX(旧Twitter)投稿文を3パターン作成してください。 |
|
</task> |
|
<format> |
|
各140文字以内。 |
|
ハッシュタグは3つ(#AI副業 #生成AI活用 #Gemini活用 などから選ぶ)。 |
|
URLは本文に含めず「URLは返信欄に記載」と書いてください。 |
|
</format> |
テンプレート③:リサーチ依頼
|
コピペ用テンプレート③(リサーチ依頼) |
|
<context> |
|
私はAI副業・生成AIの活用についてブログを書いています。 |
|
以下のテーマについて記事を書くための情報収集をしています。 |
|
テーマ:[テーマを入力] |
|
</context> |
|
<task> |
|
このテーマについて調査し、以下を整理してください。 |
|
1. 基本的な概要(初心者にわかる説明) |
|
2. 代表的な活用例(3〜5つ) |
|
3. 注意点や限界(正直に) |
|
4. 参考になりそうなキーワードや情報源 |
|
</task> |
|
<format> |
|
見出しごとに箇条書きで整理してください。 |
|
わかっていないことや不確かな情報は明示してください。 |
|
</format> |
まとめ:「なんとなくの指示」からの卒業
今回整理した内容を振り返ると、Geminiへの指示で押さえておくべきポイントはシンプルだ。
- 4要素(ペルソナ・タスク・コンテキスト・フォーマット)を意識して書く
- コンテキストはプロンプトの冒頭に置く
- XMLタグで「指示」と「データ」を仕切る
- 禁止事項・フォーマット指定は最後に書く
- 複雑な依頼は「確認→実行」の2段階にする
Gemini 3には「答える前に考える」という仕組みが備わっており、私たちの指示の「設計の質」がそのまま回答の質につながってくる。
完璧な指示を最初から書く必要はない。「型を意識して書く」というだけで、確実に変化が出てくる。私自身、まだ試している途中だ。
|
💜 Hiroroのひとこと |
|
カスタムAI機能に頼り切っていたここ数カ月、 |
|
「プロンプトを自分で設計する」という感覚が薄れていたと思う。 |
|
今回これを整理して、改めてプロンプト設計の面白さを感じた。 |
|
次のGemini Notebooks(NotebookLM連携)の記事では、 |
|
この「構造化プロンプト」の考え方をどう活かすかも合わせて書いてみたい。 |
|
🔵 次回予告 |
|
次回(5月5日予定): |
|
「GeminiにNotebooksが加わったことで何が変わったのか」 |
|
——NotebookLMとの連携で何ができるようになったのか、初心者目線で整理します。 |

