Google AI Studioでプロンプトを比較検証する手順

この記事で分かること

Google AI Studioの画面だけでプロンプト2案を比較する方法
モデルとRun settingsを固定する理由
3件のテスト入力と合否基準の作り方
出力を比較表へ記録し、採用案を判断する方法
比較をやり直すべき失敗モード

注意： 本記事ではGemini API、APIキー、Get codeを使いません。Google AI StudioのPlayground上で手動実行し、結果を表へ記録します。

先に結論

プロンプト比較では、文章を少し直して「良くなった気がする」と判断してはいけません。同じモデル、同じRun settings、同じ3件の入力、同じ採点基準を固定し、プロンプト部分だけをA案からB案へ変更します。

Google AI Studioでプロンプトを同条件比較する流れ 成功条件とテスト入力を先に固定し、プロンプト以外の条件を変えずに結果を採点する流れを示す。

Googleの公式クイックスタートでは、AI Studioはモデルとプロンプトを試す場所として説明され、Run settingsでモデルパラメーター、安全設定、各種ツールを調整できると案内されています。設定を同時に変えると、改善がプロンプトによるものか判別できません。

今回の検証テーマ

例として、ECサイトの問い合わせを次の3分類へ振り分けるプロンプトを比較します。

delivery：配送状況や遅延
account：氏名、住所、ログインなどアカウント関連
other：どちらにも該当しない問い合わせ

出力形式は、分類、理由、確認質問の3項目です。B案は、A案へラベル定義、曖昧時の扱い、出力形式を追加したものです。

事前に成功条件を固定する

評価項目	合格条件	配点
分類	期待ラベルと完全一致	2
根拠	入力にある事実だけで1文説明	1
確認質問	不要なら`なし`、必要なら1問だけ	1
形式	指定した3行だけを返す	1

1ケース5点、3ケース合計15点です。重大な安全問題や、入力にない事実の捏造があれば点数に関係なく不合格とします。

採用基準は次のように決めます。

採用条件
- 3ケースすべてで分類が正しい
- 合計13点以上
- 入力にない注文状況を作らない
- 個人情報の入力を不必要に要求しない
- 同点なら短く保守しやすい案を選ぶ

採点基準は出力を見てから変えません。結果を見た後でB案に有利な項目を追加すると、比較にならないためです。

3件の固定テストケース

CASE-01
入力：昨日届く予定でしたが、まだ荷物が届きません。注文番号は分かります。
期待ラベル：delivery
期待する確認：配送状況確認に必要な情報を案内する。ただし配送済みと断定しない。

CASE-02
入力：引っ越したので住所を変えたいです。すでに注文した商品にも反映されますか。
期待ラベル：account
期待する確認：アカウント住所と注文済み商品の配送先が別管理の可能性を前提に、注文状態の確認を1問だけ行う。

CASE-03
入力：ギフト包装はできますか。
期待ラベル：other
期待する確認：資料に包装可否がないため、対応可否を捏造せず確認先を案内する。

実際の業務では、通常例だけでなく、曖昧な入力、情報不足、安全上の境界を含むケースを入れます。顧客の実メッセージを使う場合は、氏名、注文番号、住所などを匿名化してください。

比較するプロンプトAとB

A案：短い指示

問い合わせをdelivery、account、otherに分類してください。
理由と必要な確認質問も書いてください。

B案：定義と出力を固定した指示

# 役割
ECサイト問い合わせの一次振り分けを行う。

# ラベル定義
- delivery：発送、配送状況、到着予定、配送遅延
- account：会員情報、氏名・住所変更、ログイン
- other：上記以外

# 判断規則
- 入力に書かれていない注文状態、制度、対応可否を推測しない。
- 複数候補がある場合は、問い合わせの主目的を選ぶ。
- 判断に必要な情報が不足する場合だけ、確認質問を1問作る。
- 個人情報そのものを回答へ再掲しない。

# 出力形式
分類: <delivery|account|other>
理由: <入力に基づく1文>
確認質問: <1問、不要なら「なし」>

Googleのプロンプト設計ガイドは、明確で具体的な指示、出力形式の指定、例を使った反復改善を推奨しています。今回のB案はその考え方を、手動比較できる小さな形にしたものです。

手順1：AI Studioで新しいChat promptを開く

Google AI Studioへサインインします。
Playgroundで新しいChat promptを開きます。
使用するモデル名を記録します。
Run settingsを開き、現在値を評価シートへ転記します。
Grounding、code execution、structured outputなどの追加ツールは、今回の分類テストではオフのままにします。

成功の目安は、空のチャットとRun settingsが表示され、モデル名を記録できたことです。利用できるモデルや設定項目はアカウント、地域、サービス更新で異なる場合があります。

手順2：Run settingsを固定する

最低限、次を記録します。

|項目|固定値|
|---|---|
|実施日|2026-07-29|
|モデル|画面に表示されたモデル名を記入|
|Temperature|初期値を記入|
|Top P / Top K|表示される場合のみ記入|
|最大出力|初期値を記入|
|安全設定|初期値を記入|
|追加ツール|すべてオフ|

比較中は値を変えません。特にGemini 3.xでは、Googleの公式ガイドがtemperature、top-p、top-kを既定値のまま使うことを強く推奨し、変更によってループや性能低下が起こり得ると説明しています。最初の比較では既定値を基準にするのが妥当です。

生成には揺らぎがあり得るため、厳密さが必要なら各ケースを複数回実行します。ただし、A案を1回、B案を3回のように回数を変えてはいけません。例えば「各ケース3回」と先に決め、全条件で同じ回数を実行します。

手順3：A案を3ケースで実行する

A案をSystem instructionまたは指示欄へ入れます。
CASE-01の入力だけをユーザー入力として送ります。
出力をそのまま評価表へコピーします。
新しいチャットまたは同じ初期状態へ戻し、CASE-02、CASE-03を個別に実行します。

ケース間の会話履歴が残ると、前の回答が次の分類へ影響します。各ケースを独立評価するなら、新しいセッションから始めてください。

手順4：B案だけに差し替える

モデルとRun settingsを変えず、A案をB案へ置き換えます。3件を同じ順序、同じ入力文、同じ実行回数で試します。

途中で誤字を見つけても、その実行中は修正しません。A・B両方の全ケースが終わってからC案として別の比較を開始します。

手順5：比較結果表へ採点する

次の表へ実際の結果を記録します。点数例を先に埋めると架空の検証になるため、初期状態は空欄です。

|ケース|案|分類 0/2|根拠 0/1|確認質問 0/1|形式 0/1|重大問題|合計|
|---|---|---:|---:|---:|---:|---|---:|
|CASE-01|A|||||||
|CASE-02|A|||||||
|CASE-03|A|||||||
|CASE-01|B|||||||
|CASE-02|B|||||||
|CASE-03|B|||||||

判定メモ：
- A合計：
- B合計：
- 採用条件を満たした案：
- 観察した失敗：
- 次に試す変更は1点だけ：

出力が自然で丁寧でも、分類や形式が違えば減点します。反対に、文章が短くても、分類と安全条件を安定して満たすなら目的に合っています。

期待結果と確認方法

この検証で期待するのは「B案が必ず勝つこと」ではありません。次の状態になれば成功です。

A案とB案の違いがプロンプトだけになっている
3件すべての入力と期待ラベルが保存されている
点数の根拠を第三者が読み直せる
失敗したケースが特定されている
次に変える要素が1点に絞られている

B案が負けた場合も有益です。指示が長すぎる、ラベル境界が矛盾している、確認質問の規則が強すぎるなど、具体的な改善仮説を立てられます。

事実と編集部の判断を分ける

公式情報から確認できること

AI Studioはモデルとプロンプトを試すための画面を提供する
Run settingsではモデルパラメーター、安全設定、追加ツールを変更できる
明確で具体的な指示や出力形式の指定は、公式のプロンプト設計方針に含まれる
プロンプト設計は反復的で、実際の出力を観察して改善する必要がある

AI活用ナビの評価設計

3ケース、5点満点、13点以上という基準は、本記事の説明用に編集部が設計したものです。Googleが保証する評価方式ではありません。業務導入時は、実際の誤りコストに合わせてケース数と重大問題の条件を増やしてください。

失敗しやすい点と対処

プロンプトと設定を同時に変える

原因を分離できません。新しいモデルを試す場合は、採用済みプロンプトを固定し、モデルだけを比較する別テストにします。

良い出力だけを保存する

失敗例を消すと改善点が見えません。すべての結果、実施日時、モデル名、設定を残します。

1件だけで採用する

簡単な通常例だけでは境界条件が分かりません。曖昧例、情報不足例、禁止事項を含む例を追加します。

毎回違う会話履歴で試す

前の回答が条件差になります。独立ケースは新規チャットから実行します。

APIキーやコード生成へ進んでしまう

本記事の目的には不要です。Get codeやAPIキー作成を選ばず、Playground上の比較で止めます。自動化が必要になった場合も、組織の認証・費用・安全基準を別途設計する必要があります。

採用しない条件

正解ラベルを定義できない創作課題、評価者ごとに基準が大きく違う課題、実データをAI Studioへ入力できない機密案件には、この単純な合否比較をそのまま採用しません。法務・医療・セキュリティ判断では、専門家レビューと専用評価を追加します。

AI活用ナビの判断

AI活用ナビの判断： プロンプト改善では、巧い言い回しより固定評価セットが重要です。まずモデルとRun settingsを既定値で固定し、最小限のA/B比較から始めると、どの変更が効いたか説明できます。

合格したプロンプトも永久版ではありません。モデル更新、入力傾向、業務ルールが変わったら、同じ評価セットに新しい境界ケースを追加して再検証してください。

確認日と公式情報

確認日：2026年8月22日。モデル名、Run settingsの項目、既定値、安全設定、Playgroundの画面構成は変更される可能性があります。

PRIMARY SOURCES