はじめに
AIに仕事を頼むとき、指示を全部書こうとして手が止まることはないでしょうか。書き漏らした条件は、AIが推測で埋めます。その推測が、出力のズレとして返ってきます。
ゴールシークプロンプトは、この困りごとへの一つの答えです。指示を書き切る代わりに、AIから質問してもらい、足りない情報を対話で埋めます。
この記事では、仕組み、コピーして使えるテンプレート、実際の対話の進み方を順に紹介します。
要点
- ゴールシークプロンプトは、最終ゴール（成果物）を先に示し、足りない情報をAIに質問させて埋める手法です。
- 通常は「人が条件を全部書く」のに対し、ゴールシークは「AIが条件を聞き出す」方式です。
- 型は3つ（プロンプト生成型・3点セット型・伴走型）に整理しました。目的に合わせて選べます。
- 実例では、AIが質問だけを先に出し、回答を成果物や計画に反映しました。
ゴールシークプロンプトとは
定義
達成したい最終ゴール（成果物）を先に示し、そこに至るために必要な情報をAI側から質問させ、対話で埋めていくプロンプト手法です。
通常のプロンプトでは、人が条件をできるだけ書き込んでからAIに渡します。ゴールシークでは、ゴールだけを渡し、足りない条件はAIが聞いてきます。
名前の由来
名前は、Excelの「ゴールシーク」機能に由来します。目標とする値を決め、そこから逆算して入力値を求める機能です。プロンプトでも、ゴール（成果物）から逆算して必要な入力を洗い出させます。
AIプロンプトエンジニアの林駿甫（ハヤシシュンスケ）氏が広めた手法で、「シュンスケ式ゴールシークプロンプト」と呼ばれることもあります。
出典: ゴールシークプロンプト：ChatGPTを「優秀な相棒」に変える魔法のプロンプト術（林駿甫氏のnote）
なぜうまくいくのか
成果物は「決めるべき項目のかたまり」と見ることができます。たとえばGitブランチ運用のドキュメントなら、運用モデル、ブランチ名の規則、マージの条件、問い合わせ先などです。
人が最初に全項目を書こうとすると、考慮漏れが残りやすくなります。ゴールシークでは、項目の洗い出しをAIに任せます。AIは成果物の種類に応じて、必要な情報を推定して質問できます。
- 考慮漏れが減ります。
- 答えながら、自分の考えが整理されます。
- 往復が増えるため、1回で終わる指示より時間はかかります。
基本の流れ
流れは5ステップです。
- ゴールの具体化（何を作りたいか、成果物の形を示します）
- 変数の特定（AIが、成果物に必要な情報を洗い出します）
- 変数への質問（AIが質問し、人が答えます）
- フィードバックで修正（答えを反映した案を見て、直したい点を伝えます）
- 成果物の作成（条件が揃ったら、AIが成果物を作ります）
往復の回数は、タスクの複雑さや最初に渡す情報量で変わります。質問が多いときは、「重要な質問を3つまでにしてください」のように上限を指定します。
最も手軽な入口は、次の基本形です。
〇〇を作りたいです。必要な情報を1つずつ質問してください。全て揃ったら成果物を作成してください。
3つの型とテンプレート
目的別に、3つの型に整理しました。
| 型 | 特徴 | 向いている場面 |
|---|---|---|
| プロンプト生成型 | ゴール専用のプロンプトをAIに書かせる | 繰り返し使うプロンプトを作りたいとき |
| 3点セット型 | 毎回「改訂案・改善提案・質問」を出させる | 成果物を育てながら進めたいとき |
| 伴走型 | 質問から計画づくり、見直しまで進める | 目標達成の計画を立てたいとき |
型1: プロンプト生成型
成果物を直接作らせず、成果物を作るための専用プロンプトをAIに書かせます。生成されたプロンプトを新しい会話で使うと、AIが質問から始めてくれます。
次のテンプレートの {} を、自分のゴールと成果物に置き換えて使います。
ゴールは、{達成したいこと}。
成果物は、{成果物の形式}。
このゴールを達成するためのプロンプトを作成してください。プロンプトには次の要素を含めてください。
---
#前提条件
#成果物の詳細
#変数の定義とゴール設定
#ゴールを達成するためのステップ
#ユーザーへの確認事項
#例外処理
#フィードバックループ
#成果物の生成
---
作成するプロンプトは、最初の応答では確認事項の質問だけを出力して回答を待ち、回答がそろってから成果物を作る構成にしてください。
成果物として、プロンプトを書き出してください。
「最初の応答では確認事項の質問だけを出力して回答を待ち」の1文が要です。これがあると、生成されるプロンプトが、質問して待つ作りになります。
型2: 3点セット型
毎回「改訂案・改善提案・質問」を出力させる型です。たたき台を見ながら、何が決まり何が未定かを追えます。
あなたは私のゴール達成を支援する優秀なアシスタントです。
【ゴール】ここに達成したい目的を書く（例：初心者向けにSEO記事の構成案を作る）
このゴールを達成するために、以下の3つを出力してください。
1. 改訂案：現時点の情報で作成した成果物のたたき台
2. 改善提案：品質を上げるために追加・修正すべき点
3. 質問：ゴールを具体化するために私に確認したいこと
私が質問に回答したら、その内容を反映して1〜3を更新してください。
私が「完了」と伝えるまで、このやりとりを繰り返してください。
回答はすべて日本語で、分かりやすく整理して出力してください。
型3: 伴走型
目標達成の計画づくりに向く型です。質問、計画、見直しの3段階で進めます。
# ゴール
3か月以内に、TypeScriptで社内向けの簡単な在庫管理Webアプリを1人で作り、チームで使い始める。
# 進め方
このゴールから逆算して、計画づくりと実行を伴走してください。次の順で進めます。
1. 質問: 計画を立てるのに足りない情報（現状・使える時間・制約・完了の基準など）を、5つ以内の質問にしてください。答えやすいよう、選択肢か回答例を添えてください。今回は質問だけを出力し、私の回答を待ってください。
2. 計画: 回答をもとに、ゴールから逆算した中間目標、期間ごとのやることリスト、つまずきそうな点と対策を出してください。
3. 見直し: 以後、私が進捗や困りごとを報告するたびに、計画を修正してください。
# ルール
- 分からない点は推測で埋めず、質問するか、仮の前提として明示してください。
- 回答は日本語で、簡潔に整理してください。
「ゴール」の1行は、自分の目標に書き換えて使います。数字と期限を入れると、計画が具体的になります。
実例
実例はgpt-6-lunaで実行しました。結果は実行のたびに変わります。回答は例として用意したものです。長い出力は折りたたみ、省略箇所は「（中略）」「（以下略）」で示します。
実例1: 型1でGitブランチ運用ドキュメントを作る
型1に入力する
型1の {} を、次のように埋めました。残りの部分はテンプレートのままです。
ゴールは、社内の新人エンジニア向けに「Gitのブランチ運用ルール」を説明する1ページの社内ドキュメントを作ること。
成果物は、Markdown形式のドキュメント。
（以下略）
専用のプロンプトが生成される
AIは、8つの要素に沿った専用プロンプトを書き出しました。「ゴールを達成するためのステップ」の1番目と、「ユーザーへの確認事項」に、質問だけを出して待つ手順が入っています。
生成されたプロンプトの抜粋
# ゴールを達成するためのステップ
1. **最初の応答では、確認事項の質問だけを出力してください。**
- 挨拶、前置き、説明、仮の文書、提案は出さないでください。
- 次の「ユーザーへの確認事項」を番号付きで質問してください。
- 回答しやすいよう、可能なら箇条書きや記入例を添えてください。ただし、質問以外の文章は加えないでください。
2. ユーザーの回答を確認し、各変数に反映してください。
3. 回答が不足している場合や矛盾している場合は、解決に必要な追加質問だけを出力し、回答を待ってください。この段階でも文書はまだ作成しないでください。
（中略）
# ユーザーへの確認事項
最初の応答では、以下を番号付きの質問として提示してください。
1. このドキュメントの対象となる新人エンジニアの経験レベルを教えてください。Gitの基本操作を知っている前提でよいですか？
2. 対象のリポジトリや開発形態を教えてください。例：Webアプリ、モノレポ、複数チームで共有するリポジトリなど。
3. 採用しているブランチモデルを教えてください。例：GitHub Flow、Git Flow、独自ルール。未定の場合は「未定」と回答してください。
（以下略）
新しい会話で使う
生成されたプロンプトを、新しい会話にそのまま貼ります。AIの返答は、12個の質問だけでした。
AIの質問12個
1. このドキュメントの対象となる新人エンジニアの経験レベルを教えてください。Gitの基本操作を知っている前提でよいですか？
2. 対象のリポジトリや開発形態を教えてください。例：Webアプリ、モノレポ、複数チームで共有するリポジトリなど。
3. 採用しているブランチモデルを教えてください。例：GitHub Flow、Git Flow、独自ルール。未定の場合は「未定」と回答してください。
4. 使用するブランチの種類と、それぞれの役割を教えてください。例：`main`、`develop`、`feature/*`、`release/*`、`hotfix/*`。
5. ブランチ名の命名規則を教えてください。例：`feature/チケット番号-短い説明`。
6. ブランチ作成からマージまでの標準的な手順を教えてください。例：どのブランチから派生させ、どのブランチへマージするか。
7. Pull Requestの作成・レビュー・承認に関するルールを教えてください。例：必要な承認者数、レビュー前に通すチェック。
8. マージ方法と、マージ後のブランチの扱いを教えてください。例：squash mergeを使う、作業ブランチを削除する。
9. リリースや緊急修正に専用のブランチ運用ルールはありますか？
10. Gitホスティングサービス、CI、ブランチ保護など、記載すべきツールや制約はありますか？
11. 文体、社内用語、必ず強調したい注意点があれば教えてください。
12. 未定・不明な項目について、推奨案を提示して「要確認」と明記してよいですか？それとも、文書には含めず確認事項として残しますか？
回答する
1. はい。Gitの基本操作（clone・commit・push・pull）は知っている前提です。
2. 社内向けWebアプリで、5人のチームで1つのリポジトリを共有しています。
3. GitHub Flowです。
4. main（常にデプロイ可能）、feature/*（機能追加・修正）、hotfix/*（本番の緊急修正）の3種類です。
5. feature/課題番号-短い説明、hotfix/課題番号-短い説明 です。
6. mainから作成し、PRを経てmainへマージします。
7. 1名以上の承認と、CIのテスト通過が必須です。
8. Squash mergeです。マージ後、作業ブランチはリモートもローカルも削除します。
9. 本番の緊急修正だけ hotfix/* を使います。流れは feature と同じです。
10. GitHubを使っています。mainにはブランチ保護があり、直接pushできません。
11. です・ます調。困ったら Slack の #dev-help で聞く、と必ず入れてください。
12. 不明な項目はありません。
完成したドキュメント
回答がそろったところで、AIは初めてドキュメントを出力しました。
完成したドキュメントの抜粋
# Gitのブランチ運用ルール
## 基本方針
このリポジトリでは **GitHub Flow** を採用します。`main` は常にデプロイ可能な状態に保ち、変更は作業ブランチで行って Pull Request（PR）を通じて取り込みます。`main` への直接 push はできません。
## ブランチの種類
| ブランチ | 用途 |
|---|---|
| `main` | 常にデプロイ可能な状態を保つブランチです。 |
| `feature/*` | 機能追加や通常の修正に使います。 |
| `hotfix/*` | 本番の緊急修正に使います。 |
## ブランチ名
課題番号と短い説明を付けます。
```text
feature/課題番号-短い説明
hotfix/課題番号-短い説明
```
（中略）
## 注意点・困ったとき
- `main` に直接 push しないでください。
- PRの承認やCIの通過前にマージしないでください。
- ブランチの切り方やマージ時の判断に迷った場合は、Slack の `#dev-help` で相談してください。
ポイント
- 型1に書いた「最初の応答では質問だけを出す」という指定が、生成されたプロンプトに引き継がれています。新しい会話の最初の返答は、質問だけでした。
- 完成物には、回答した条件がそのまま反映されています。
- 一度作った専用プロンプトは、別のチームやリポジトリでも、質問に答え直すだけで使い回せます。
実例2: 型3で3か月の開発計画を立てる
入力は、型3のテンプレートをそのまま使いました。
質問
AIの最初の返答は、5つの質問だけでした。計画の分かれ目になる経験、時間、機能、制約、完了の基準を尋ねています。各質問には回答例が付いていました。
AIの質問5つ
1. **TypeScript／Webアプリ開発の経験はどのくらいですか？**
例：実務経験あり／個人開発の経験あり／学習中／ほぼ初めて
2. **3か月間、週に何時間くらい開発に使えますか？**
例：週5時間／週10時間／週20時間以上。忙しい時期があれば、それも教えてください。
3. **在庫管理で必要な機能や扱うデータは決まっていますか？**
例：品目・数量の登録と更新、入出庫履歴、検索、CSV出力など。未定なら「まだ未定」で大丈夫です。
4. **利用環境や社内の制約はありますか？**
例：利用人数、社内認証の要否、使えるクラウド・データベース、扱うデータの制限など。不明な点は「不明」としてください。
5. **3か月後に「チームで使い始めた」と判断する基準は何ですか？**
例：主要機能が動く試作版を数人が利用／全員が利用でき、既存の表計算から移行／運用手順やバックアップも整備
回答
1. 学習中です。TypeScriptは入門書を一通り読みました。Webフレームワークは未経験です。
2. 週5〜10時間です（平日夜と土曜）。
3. 品目の登録・更新・削除、入出庫履歴、検索が必要です。現状はExcelで約300品目を管理しています。
4. 利用者は倉庫担当の6人です。社内のログインはGoogle Workspaceです。ほかの制約は特にありません。
5. 6人全員がPCから使え、Excelから移行できた状態です。
計画
回答を受けて、AIは時間の見積もり、仮の前提、中間目標の表、完了の基準を出しました。つまずきそうな点と対策も付いていました。
計画の抜粋（つまずきそうな点と対策は省略）
## 3か月の計画（12週間）
週5〜10時間なので、合計60〜120時間を想定します。最初から機能を増やしすぎず、**品目管理・入出庫履歴・検索・Excel移行・6人での利用開始**に絞ります。
### 仮の前提
- 社内で利用が認められたクラウド環境を使えること。未確認なら、**最初の週に確認**します。
- 技術構成は、学習コストを抑える案として **TypeScript＋React（Vite）＋Supabase** を仮置きします。Google Workspaceログインやデータ保管に社内規定がある場合は、それを優先して変更します。
- 品目の削除は履歴を残すため、データを完全削除せず「アーカイブ」にします。在庫数は直接書き換えるのではなく、入庫・出庫の記録から管理します。
## 中間目標とやること
| 期間 | 中間目標 | やること |
|---|---|---|
| **1週目** | 仕様と利用環境を確定 | Excelの列・入力ルールを確認。入出庫の扱い、検索条件、品目の削除ルールを決める。利用可能なクラウド、Google Workspace認証の設定可否を確認する。 |
| **2〜3週目** | 開発環境と基本画面が動く | Reactと必要なTypeScriptを学びながら、画面・データベースを作成。品目一覧、検索、登録・更新を実装する。 |
| **4〜5週目** | 入出庫と履歴が使える | 入庫・出庫の登録、履歴表示、現在庫の算出を実装。入力ミスや在庫不足への対処も加える。 |
| **6〜7週目** | 社内利用できる形にする | アーカイブ、Google Workspaceログイン、利用者制限を実装。PCでの画面を整え、基本的な操作テストを行う。 |
| **8〜9週目** | Excelから移行できる | Excelデータの重複・表記ゆれ・数量を整理し、取り込み用データを作る。少量で試し、約300品目を取り込んで照合する。 |
| **10週目** | 6人で試用 | 倉庫担当者に実データで使ってもらう。操作の迷い、検索しにくさ、入力ミスなどを集め、重大な問題を優先して修正する。 |
| **11〜12週目** | 移行と利用開始 | Excelとの最終照合、バックアップ・復旧方法の確認、簡単な操作手順の作成を行う。6人のアカウントで利用できることを確認して切り替える。 |
### 完了の基準
- 6人全員がPCからログインできる。
- 約300品目を移行し、主要な品目・数量をExcelと照合済み。
- 品目の登録・更新・アーカイブ、入出庫記録、履歴確認、検索ができる。
- 利用者が操作手順を見て基本操作でき、データのバックアップ方法が決まっている。
（以下略）
進捗を報告して、計画を見直す
ここからが、型3の「見直し」です。次のように報告しました。
進捗報告です。1週目の確認が終わり、Supabaseの利用とGoogleログインの設定は社内で認められました。ただ、本業が忙しく、2〜3週目は予定の半分しか時間が取れませんでした。来週以降も同じくらい忙しそうです。計画を見直してください。
AIは、使える時間を再見積もりし、機能を必須・簡略化・後回しに分けて、計画を組み直しました。
見直し後の計画の抜粋
確認ありがとうございます。**Supabase利用とGoogleログインが承認済み**なのは大きな前進です。一方、今後も週2.5〜5時間程度と仮定すると、残り約9週間で使えるのは**約22〜45時間**です。3か月以内の利用開始は狙いつつ、機能を絞り、まず安全に使える最小版を完成させる計画に変更します。
## 見直し後の優先順位
**必須：** Googleログイン、品目の登録・更新、入出庫、検索、Excelからの移行、6人での動作確認
**簡略化：** 削除は完全削除でなくアーカイブ。検索は品目名・コードなど基本項目に限定。画面の装飾や高度な検索は後回し。
**後回し：** CSV出力、細かな権限設定、分析・レポートなど
## 残り9週間の計画
| 期間 | 目標 | 作業 |
|---|---|---|
| **4〜5週目** | 品目管理の基本を完成 | Supabaseのテーブル作成、品目一覧・検索・登録・更新を実装。小さな範囲で一連の操作を確認。 |
| **6〜7週目** | 入出庫を記録できる | 入庫・出庫の記録と履歴表示を実装。在庫数の更新と、在庫不足など最低限のエラー処理を確認。 |
| **8週目** | チーム利用の入口を整える | Googleログインを設定し、6人が使えることを確認。アクセス制御を設定し、誤操作時に履歴が残ることを確認。 |
| **9〜10週目** | Excel移行の準備と試行 | Excelの列やデータの不整合を確認。少量で取り込みを試し、数量・品目の照合方法を決める。 |
| **11週目** | 全件移行と利用者テスト | 約300品目を取り込み、Excelと照合。倉庫担当者に基本操作を試してもらい、重大な問題だけ修正。 |
| **12週目** | 利用開始 | 最終照合、簡単な操作手順とバックアップ方法の確認を行い、6人で利用開始。 |
（以下略）
ポイント
- 最初の返答は質問だけで、計画を先に出しません。回答を受けてから、計画を作ります。
- 分からない点は、技術構成などを「仮の前提」と明示して進めます。
- 計画は作って終わりではありません。進捗を報告すると、使える時間に合わせて組み直されます。
うまく使うコツ
| つまずき | 原因 | 対処 |
|---|---|---|
| 質問が抽象的で答えにくい | ゴールの背景が足りない | ゴールに、業界・読者・用途などの背景を添えます |
| 質問が多すぎて疲れる | ゴールが大きすぎる | ゴールを分割します。または「質問は3つまで」と上限を指定します |
| いつまでも成果物に近づかない | ゴール自体が固まっていない | いったんAIを離れて、紙などに考えを書き出して整理します |
| 回答が分からない質問が出る | 自分の側に情報がない | 「分からないので、見つけ方も含めて提案してください」と答えます |
| 完成物が自分の運用に合わない | AIが一般的な内容を当てはめている | 完成物を読み、自分の運用に合うか確認してから使います |
他のプロンプト手法との使い分け
日本でよく知られたプロンプトの型に、深津式と七里式があります。まず、それぞれの概要を紹介します。
深津式プロンプト
note株式会社CXOの深津貴之氏が2023年に紹介した型です。「命令書」「制約条件」「入力文」「出力文」の4つに分けて書きます。最初にAIの役割と条件を決めておくことで、回答のぶれを抑えます。
#命令書：
あなたは{プロの編集者}です。
以下の制約条件と入力文をもとに、{最高の要約}を出力してください。
#制約条件：
・文字数は{300文字程度}。
・{小学生にも分かる言葉で}書く。
#入力文：
{要約したい文章}
#出力文：
役割・条件・入力を整理して伝える型なので、要件が明確なときに使いやすい型です。
出典: 公開！「マーケター版ChatGPT汎用プロンプト」 note深津氏が直伝（日経クロストレンド）
七里式プロンプト
七里信一氏が提唱する型で、「8+1の公式」と呼ばれます。前提条件、読み手と書き手の設定（ペルソナ）、参考情報、出力形式、文体など8つの要素で指示を組み立てます。「+1」は、出てきた成果物に追加で指示を出して精度を上げる工程です。
#前提条件：（タイトル、依頼者、前提知識、目的と目標）
#ペルソナ設定：（読み手と書き手の属性）
#参考情報：（回答の材料になる情報）
#名詞と動詞：（何をすべきか）
#形容詞と副詞：（どの程度・どのように）
#出力形式：（箇条書き、段落構成など）
#出力フォーマット：（参考にする文章構造）
#文体指定：（言葉のスタイルやトーン）
出力を見たら、+1として「もっと具体例を増やして」のような追加指示を重ねて仕上げます。項目が多い分、出力のぶれを抑えやすい型です。
出典: プロンプトの極意（七里信一公式ブログ）、『生成AIプロンプトエンジニア検定公式テキスト＆問題集 改訂版』
3つの手法の比べ方
ゴールシークは、これらと競合するものではありません。向いている場面が違います。
| 手法 | 特徴 | 向いている場面 |
|---|---|---|
| ゴールシークプロンプト | AIが質問して情報を引き出す。対話で進む | 要件が曖昧な段階 |
| 深津式プロンプト | 命令・制約・入力・出力を構造化して書く | 出力の形式を厳密に指定したいとき |
| 七里式プロンプト | 8+1の公式で、前提条件・ペルソナ・出力形式などを細かく指定する | 出力のぶれを抑えたいとき |
要件が曖昧な段階はゴールシークで固め、固まった要件を深津式などで清書させる使い分けができます。
まとめ
- ゴールシークプロンプトは、ゴールを先に示し、足りない情報をAIに質問させて対話で埋める手法です。
- 型は、専用プロンプトを作るプロンプト生成型、成果物を育てる3点セット型、計画を立てる伴走型の3つです。
- 型1・型3では、「最初は質問だけを出して回答を待つ」という指定が、うまく動かすための要です。
- 完成物は、自分の運用に合うかを確認してから使います。
- 要件が曖昧ならゴールシーク、明確なら深津式のように、場面に応じて使い分けます。