06. Geminiで使用するプロンプトの基本 | Cloud AI エンジニア入門ガイド

Geminiに聞いてみたけど、ぼんやりした答えしか返ってこなかった。この不満のほとんどは、モデルの性能ではなく指示の書き方が原因です。

プロンプト（prompt） は、モデルへ渡す指示文のことです。組み立てる型と、それを改善していく手順を扱います。

この章の全体像として、4つの要素、例を見せる、反復して直す、資料は先、質問は後の4つを番号順に並べ、曖昧な答えを具体的な答えに変えられるようになることを示した図

シリーズ目次／前章: 05. Geminiを使い始める：画面・プラン・準備／次章: 07. Geminiのマルチモーダル機能

Open Table of contents

この章のねらい
短い指示でうまくいかない理由
4つの要素で組み立てる
例示（few-shot）
反復して直す
大きな仕事の分割
資料を添えるときの順序
よくある失敗と対処
要点
参考資料

この章のねらい

プロンプトを4つの要素に分けて組み立てられるようになる
例示（few-shot）の効果と、やりすぎたときの副作用を理解する
一度で完成させようとせず、少しずつ直していく進め方を身につける
よくある失敗パターンを避けられるようになる

短い指示でうまくいかない理由

モデルはもっともらしい続きを作る仕組みでした（第3章）。指示が曖昧なら、曖昧な指示に対してもっともらしい答えが返ってきます。つまり、平均的で当たり障りのない文章です。

【曖昧な指示】
新商品の紹介文を書いて。

【返ってくるもの】
誰に向けたものか、何文字か、どんな媒体かが分からないので、
一般論としての紹介文（=誰にも刺さらない文章）

要るのはモデルを賢くすることではありません。答えの候補を絞る材料を渡すことです。

4つの要素で組み立てる

公式の設計指針でも、明確な指示と前提と制約と出力形式を与えることが勧められています。実用的には、次の4要素で考えると組み立てやすい。

役割・タスク・文脈・出力形式の4要素が揃うことで曖昧さが減る構造の図

要素	書くこと	例
役割	誰として答えるか	「BtoBソフトウェアのマーケティング担当として」
タスク	何をしてほしいか	「新機能の紹介文を書いて」
文脈	前提・材料・制約	「読者は情報システム部門の管理職。既存顧客向け」
出力形式	長さ・構造・書き方	「300字以内。見出しなし。数字は本文中に1つ入れる」

先ほどの例を書き直すと、こうなります。

BtoBソフトウェアのマーケティング担当として、新機能の紹介文を書いてください。

【読者】既存顧客の情報システム部門の管理職
【伝えたいこと】設定作業が従来の半分の手順で終わるようになった
【避けたいこと】「革新的」「圧倒的」のような誇張表現
【形式】300字以内、見出しなし、本文の最後に問い合わせへの一文

4要素すべてを毎回書く必要はありません。足りていない要素だけを足してください。

例示（few-shot）

公式ドキュメントは、プロンプトには常に例を含めることを推奨するとしています。言葉で条件を説明するより、望ましい出力を1つ見せるほうが速くて正確です。これをfew-shot（少数例示） と呼びます。

次の形式で、社内向けの障害報告を1行にまとめてください。

【例】
入力: 3月2日 14時ごろから経費精算システムに繋がらないとの連絡が複数
出力: 3/2 14:00頃〜 経費精算システム接続不可（影響範囲: 全社／状況: 調査中）

【本番】
入力: 昨夜から一部拠点で勤怠打刻が反映されない事象を確認
出力:

例示のときに気をつける点は3つあります。

注意点	理由
形式を完全に揃える	例と出力の形が違うと、モデルはどちらに従うか迷う
種類の違う例を混ぜる	似た例ばかりだと応用が利かない
例を増やしすぎない	例の細部に引きずられ、かえって融通が利かなくなる

3つめが見落とされます。10個も例を並べると、モデルは例に無い状況で立ち往生する。2〜3個で足ります。

例の数を変えたときに何が起きるかを、並べて示します。

例なし・例を2から3個・例を10個以上という3つの場合を並べ、例なしでは書式がばらつき、多すぎると融通が利かなくなることを示した図

反復して直す

上手な人ほど、最初から完璧なプロンプトを書こうとしません。短く投げて、返ってきたものを見て直す。この進め方です。

短く頼んで出力を読み、惜しい点を1つ選んで足し、同じ会話で言い直すループの図

一度に1つだけ直してください。長さも語り口も内容も同時に変えると、何が効いたのか分からなくなります。

（1回目）議事録から決定事項だけ抜き出して。
　↓ 長すぎた
（2回目）箇条書きで5項目以内にして。
　↓ 誰が決めたか分からない
（3回目）各項目の末尾に担当者名を括弧で付けて。

それと、同じ会話の中で直すほうが効率的です。新しい会話を始めると、それまでの前提をもう一度説明することになります。

満足いく形になったら、その指示はGemsとして保存できます（第9章）。毎回書き直す手間がなくなります。

大きな仕事の分割

複雑な依頼を一度に投げると、どこかが抜けます。公式の指針でも、タスクの分割が勧められています。

（悪い例）
この100ページの資料を読んで、要約して、課題を洗い出して、
対策案を作って、経営会議用のスライド構成にして。

（良い例）
① まず章ごとに3行で要約して
② その要約から、課題だと読み取れる箇所を列挙して
③ 列挙した課題のうち、コストに関わるものだけ対策案を出して
④ ③をもとにスライド5枚分の構成を作って

分割の利点は精度だけではありません。途中で間違いに気づけることのほうが効きます。①の要約が的外れなら、そこで直せば残りは無駄になりません。

一括で頼んだ場合と分けた場合を、並べて比べます。

左に要約から資料作成までを一度に依頼した場合、右に4段階へ分けた場合を並べ、分けたほうが途中で間違いに気づけることを示した図

資料を添えるときの順序

長い資料を貼るときは、資料が先、質問が最後です（第4章）。

[議事録の全文]

上記の議事録から、期限が明記されているタスクだけを
「担当者 / 内容 / 期限」の表にしてください。期限がないものは除外してください。

除外してください、のような否定形の指示は、肯定形と組み合わせると確実になります。期限が明記されているものだけを含めてください、期限がないものは除外してください。同じことを両側から書くわけです。

よくある失敗と対処

失敗	何が起きているか	対処
一般論しか返らない	文脈が足りない	読者・目的・制約を書く
毎回書式がばらつく	出力形式の指定がない	例を1つ見せる
嘘の出典が混ざる	検索していないか、生成で補われた	出典リンクを開いて確認する（第13章）
途中から指示を無視する	会話が長すぎて枠から落ちた	新しい会話で前提を書き直す
こちらの誤りに同調する	同意しやすい傾向がある	「反対の立場から批判して」と明示的に頼む
やたら長い	長さの指定がない	文字数か項目数で上限を指定する

症状ごとに、原因と対処をひと組にして並べます。

一般論しか返らない・書式がばらつく・嘘の出典が混ざる・指示を無視する・誤りに同調する・やたら長いという6つの失敗について、それぞれの原因と対処を並べたカード形式の図

最後の同調には補足が要ります。自分の仮説をぶつけて、おっしゃるとおりです、と返ってきても、それは検証結果ではないかもしれません。重要な判断では、わざと逆の立場で検討させてください。

この案の弱点を3つ挙げ、それぞれが致命的になる条件を書いてください。
賛成意見は書かないでください。

要点

曖昧な指示には曖昧な答えが返る。役割、タスク、前提、出力形式の4要素で候補を絞る
言葉で説明するより、望ましい出力例を1〜3個見せるほうが速く正確
一度に1つだけ直し、同じ会話の中で反復する
大きな依頼は段階に分割し、途中で誤りに気づけるようにする
資料は先、質問は最後。否定形の指示は肯定形と組み合わせる

参考資料

Gemini API ドキュメント「Prompt design strategies」 https://ai.google.dev/gemini-api/docs/prompting-strategies — 指示・文脈・制約・例示・分割の指針（基準日: 2026-08-04）
Gemini API ドキュメント「Long context」 https://ai.google.dev/gemini-api/docs/long-context — 長い資料での質問配置
Gemini API ドキュメント「Text generation」 https://ai.google.dev/gemini-api/docs/text-generation — システム指示の役割

シリーズ目次／前章: 05. Geminiを使い始める：画面・プラン・準備／次章: 07. Geminiのマルチモーダル機能