- AI基盤
LLMの能力を引き出すプロンプトパターン
LLMの性能を引き出すためにプロンプトを工夫する技術は「プロンプトエンジニアリング」と呼ばれています。その中核をなすのが「プロンプトパターン」です。
プロンプトエンジニアリングの領域は「コンテキストエンジニアリング」へと進化してきており、最近、コンテキストエンジニアリングをテーマにした書籍やメディア記事も多くなってきました。
モデルの推論能力が向上した結果、「何を問うか」よりも「モデルにどのような文脈情報を与えるか」がLLMの出力品質を左右するようになりました。
今回は、16の代表的プロンプトパターンを、概要、実践例とともにまとめました。これらのパターンはおおむねLLMの種類を問わず利用でき、ChatGPT、Claude、Geminiなど主要モデルのいずれにおいても有効です。
まずは、実践。
プロンプトパターンはいくつかに分類ができるものの数が多いです。わたし自身が最も使っている手法は「逆質問」です。「こんなことしたい」と漠然としたイメージをもちつつも、具体的な要件や仕様まで落とし込めていないことが開発の初期段階ではよくあります。
ブレーンストーミングや壁打ちと近いですが、開発の方向性や使用する言語やスタックなどを決めるための技術的な棚卸しにも使える手法です。今回は例として、「クラウド上にタスクとメモを保存できるシステムを構築したいが、方式や仕様が決まっていないためLLMと壁打ちしながら決めたい」、というストーリーで進めていきます。
これは「逆質問プロンプト」の１つの例ですので、ご自身の案件や、課題などと置き換えながら読み進めてください。また、使用するLLMによって回答や質問は千差万別です。今回はClaude Opus 4.6を使用しました。
以下のような逆質問プロンプト（＋出力自動化）を指示してみます。
LLMから質問が返されました。
LLMから実装に必要な様々な質問が表示されます。Claudeの場合は１問１答、GPTは一気に20個ほど質問を投げてくる傾向があります。LLMによって質問の内容や質問パターンは千差万別です。EQが高めなのはClaudeで、仕様や方式を決定する際はClaudeを多用しています。
方針や使用言語、スタック、デプロイ先が決まり、初めにプロンプトで指示した要件定義書の.mdファイルが出来上がりました。
要件定義書.md（クリックするとファイルが表示されます）
# 要件定義書：クラウドメモ＆タスク管理システム
| 項目 | 内容 |
|---|---|
| プロジェクト名 | CloudNotes（仮称） |
| ドキュメントバージョン | 1.0 |
| 作成日 | 2026-06-03 |
| ステータス | ドラフト |
---
## 1. プロジェクト概要
### 1.1 目的
小規模チーム（2〜10名）がクラウド上でメモとタスクを共有・管理できる軽量な Web アプリケーションを構築する。
### 1.2 背景・モチベーション
- 既存 SaaS（Notion、Todoist 等）に依存せず、自チーム専用のメモ＆タスク管理環境を持ちたい
- 低コスト（月額数百円〜千円程度）で運用可能な自前システムを目指す
- まずは MVP を素早くリリースし、段階的に機能を拡充する
### 1.3 スコープ
| 分類 | MVP（フェーズ1） | 将来拡張（フェーズ2以降） |
|---|---|---|
| プラットフォーム | Web ブラウザのみ | PWA 対応 → スマホ・デスクトップ |
| メモ機能 | プレーンテキストの CRUD | Markdown 対応、画像添付、全文検索 |
| タスク機能 | リスト表示の CRUD | カンバンボード、リカーリング |
| コラボレーション | メモ・タスクの共有（排他制御なし） | コメント、通知、リアルタイム共同編集 |
| 認証 | HTTP Basic Auth | OAuth（Google 等）、RBAC |
---
## 2. ユーザー要件
### 2.1 ユーザー像（ペルソナ）
| ペルソナ | 説明 |
|---|---|
| チームメンバー | メモの作成・閲覧、タスクの作成・完了操作を行う |
| チーム管理者 | 上記に加え、メンバーの管理（将来拡張）を行う |
> [!NOTE]
> MVP では全ユーザーが同一権限。管理者ロールはフェーズ2以降で導入予定。
### 2.2 ユーザーストーリー（MVP）
#### メモ機能
| ID | ストーリー | 優先度 |
|---|---|---|
| M-01 | ユーザーとして、新しいメモを作成できる | 必須 |
| M-02 | ユーザーとして、メモの一覧を閲覧できる | 必須 |
| M-03 | ユーザーとして、メモの内容を編集できる | 必須 |
| M-04 | ユーザーとして、メモを削除できる | 必須 |
| M-05 | ユーザーとして、他のメンバーのメモを閲覧できる | 必須 |
#### タスク機能
| ID | ストーリー | 優先度 |
|---|---|---|
| T-01 | ユーザーとして、新しいタスクを作成できる | 必須 |
| T-02 | ユーザーとして、タスクの一覧を閲覧できる | 必須 |
| T-03 | ユーザーとして、タスクの内容を編集できる | 必須 |
| T-04 | ユーザーとして、タスクの完了/未完了を切り替えできる | 必須 |
| T-05 | ユーザーとして、タスクを削除できる | 必須 |
| T-06 | ユーザーとして、他のメンバーのタスクを閲覧できる | 必須 |
#### 認証
| ID | ストーリー | 優先度 |
|---|---|---|
| A-01 | ユーザーとして、ユーザー名とパスワードでログインできる | 必須 |
| A-02 | ユーザーとして、ログアウトできる | 必須 |
---
## 3. 機能要件
### 3.1 メモ管理
```
データモデル: Note
├── id: string (UUID)
├── title: string (最大200文字)
├── content: string (プレーンテキスト、最大10,000文字)
├── authorId: string (作成者のユーザーID)
├── createdAt: timestamp
└── updatedAt: timestamp
```
- **作成**: タイトルと本文を入力して保存
- **一覧表示**: 更新日時の降順でメモを一覧表示（ページネーション: 20件/ページ）
- **編集**: タイトル・本文を自由に編集可能（自分のメモのみ。他メンバーのメモは閲覧のみ）
- **削除**: 自分のメモのみ削除可能（論理削除）
- **共有**: 同じチーム内のメンバーは全メモを閲覧可能
### 3.2 タスク管理
```
データモデル: Task
├── id: string (UUID)
├── title: string (最大200文字)
├── description: string (プレーンテキスト、最大2,000文字、任意)
├── status: enum ("todo" | "done")
├── authorId: string (作成者のユーザーID)
├── createdAt: timestamp
└── updatedAt: timestamp
```
- **作成**: タイトル（必須）と説明（任意）を入力して保存
- **一覧表示**: 未完了タスクを上部、完了タスクを下部に表示。各グループ内は作成日時の降順
- **編集**: タイトル・説明を編集可能（自分のタスクのみ）
- **ステータス変更**: チェックボックスで完了/未完了を切り替え（自分のタスクのみ）
- **削除**: 自分のタスクのみ削除可能（論理削除）
- **共有**: 同じチーム内のメンバーは全タスクを閲覧可能
### 3.3 認証
- **方式**: HTTP Basic Authentication
- **ユーザー管理**: 環境変数または Firestore にユーザー名/パスワード（ハッシュ化済み）を保存
- **セッション**: JWT トークンによるセッション管理（Basic Auth で認証後、JWT を発行）
- **保護**: 全 API エンドポイントを認証必須とする
> [!IMPORTANT]
> MVP では HTTP Basic Auth を採用しますが、本番運用時にはパスワードの bcrypt ハッシュ化と HTTPS 必須を徹底してください。Cloud Run はデフォルトで HTTPS を提供します。
---
## 4. 非機能要件
### 4.1 パフォーマンス
| 指標 | 目標値 |
|---|---|
| API レスポンスタイム（P95） | 500ms 以下 |
| ページ初期表示（LCP） | 2.5秒 以下 |
| 同時接続ユーザー数 | 10名 |
### 4.2 可用性
| 指標 | 目標値 |
|---|---|
| 目標稼働率 | 99%（月間ダウンタイム約7時間まで許容） |
| データバックアップ | Firestore 自動バックアップ（日次） |
### 4.3 セキュリティ
- HTTPS 必須（Cloud Run 標準機能）
- パスワードは bcrypt でハッシュ化して保存
- API は全エンドポイント認証必須
- CORS 設定を適切に構成
- 入力値のバリデーション（XSS、インジェクション対策）
### 4.4 運用コスト目標
| リソース | 想定コスト |
|---|---|
| Cloud Run | 無料枠内（月間180,000 vCPU秒） |
| Firestore | 無料枠内（1GiB ストレージ、50,000 読取/日） |
| 合計 | **$0 〜 数ドル/月**（小規模利用時） |
> [!TIP]
> Cloud Run の「最小インスタンス数 = 0」設定により、アクセスがない時間帯はコスト $0 にできます。コールドスタートは 1〜3 秒程度発生しますが、MVP では許容範囲です。
---
## 5. 技術スタック
### 5.1 技術選定の方針
- MVP を素早くリリースするために、エコシステムが成熟したツールを選択
- フロントエンド/バックエンドの言語を統一し、学習・保守コストを最小化
- GCP 無料枠を最大限に活用
### 5.2 採用技術
| レイヤー | 技術 | 選定理由 |
|---|---|---|
| **バックエンド** | Node.js + TypeScript | Cloud Run との相性◎、フロントと言語統一 |
| **Web フレームワーク** | Express.js | 軽量・シンプル・情報が豊富 |
| **フロントエンド** | Vite + Vanilla JS or React | 高速ビルド、SPA として Cloud Run から配信 |
| **データベース** | Firestore (Native mode) | GCP エコシステム統合、無料枠大、スキーマレスで MVP に最適 |
| **認証** | JWT + bcrypt | シンプルかつ安全 |
| **インフラ** | Google Cloud Run | コンテナベース、自動スケール、HTTPS 標準 |
| **コンテナ** | Docker | Cloud Run デプロイの標準手段 |
| **CI/CD** | Cloud Build (将来) | GCP 統合、自動デプロイ |
### 5.3 フロントエンドの選択肢
> [!NOTE]
> フロントエンドフレームワークは以下の2案を検討中です。MVP のスピード重視であれば **案A**、将来の機能拡張を見据えるなら **案B** を推奨します。
| | 案A: Vanilla JS (+ Vite) | 案B: React (+ Vite) |
|---|---|---|
| 学習コスト | 低い | 中程度 |
| 開発速度（MVP） | ◎ 最速 | ○ やや遅い |
| 拡張性 | △ 大規模化で辛くなる | ◎ コンポーネント指向 |
| 推奨シーン | MVP を最速で出したい | フェーズ2以降も見据える |
### 5.4 代替案の検討
バックエンド言語について、Node.js 以外の選択肢も比較しました：
| 言語 | メリット | デメリット | 評価 |
|---|---|---|---|
| **Node.js (TypeScript)** ★推奨 | フロントと統一、エコシステム豊富、Cloud Run 相性◎ | CPU負荷の高い処理には不向き | ◎ |
| **Python (FastAPI)** | 書きやすい、型ヒント対応、非同期対応 | フロントと言語が分離 | ○ |
| **Go** | 高速、コンテナサイズ極小、Cloud Run 最適 | 学習コストがやや高い、Web エコシステムが小さい | ○ |
→ **結論**: 要件との適合度・開発速度の観点から **Node.js (TypeScript)** を採用。
---
## 6. システムアーキテクチャ
### 6.1 全体構成図
```mermaid
graph TB
subgraph Client["クライアント（Webブラウザ）"]
SPA["SPA (Vite)"]
end
subgraph GCP["Google Cloud Platform"]
subgraph CloudRun["Cloud Run"]
API["Node.js + Express<br/>REST API Server"]
Static["静的ファイル配信<br/>(SPA バンドル)"]
end
Firestore["Cloud Firestore"]
end
SPA -->|HTTPS / REST API| API
SPA -->|HTTPS| Static
API -->|Read/Write| Firestore
```
### 6.2 API 設計（REST）
#### 認証
| メソッド | エンドポイント | 説明 |
|---|---|---|
| POST | `/api/auth/login` | ログイン（JWT 発行） |
| POST | `/api/auth/logout` | ログアウト（クライアント側でトークン破棄） |
#### メモ
| メソッド | エンドポイント | 説明 |
|---|---|---|
| GET | `/api/notes` | メモ一覧取得（ページネーション対応） |
| GET | `/api/notes/:id` | メモ詳細取得 |
| POST | `/api/notes` | メモ作成 |
| PUT | `/api/notes/:id` | メモ更新（自分のメモのみ） |
| DELETE | `/api/notes/:id` | メモ削除（自分のメモのみ、論理削除） |
#### タスク
| メソッド | エンドポイント | 説明 |
|---|---|---|
| GET | `/api/tasks` | タスク一覧取得 |
| GET | `/api/tasks/:id` | タスク詳細取得 |
| POST | `/api/tasks` | タスク作成 |
| PUT | `/api/tasks/:id` | タスク更新（自分のタスクのみ） |
| PATCH | `/api/tasks/:id/status` | ステータス変更（自分のタスクのみ） |
| DELETE | `/api/tasks/:id` | タスク削除（自分のタスクのみ、論理削除） |
### 6.3 Firestore コレクション設計
```
firestore-root/
├── users/
│ └── {userId}/
│ ├── username: string
│ ├── passwordHash: string
│ └── createdAt: timestamp
├── notes/
│ └── {noteId}/
│ ├── title: string
│ ├── content: string
│ ├── authorId: string
│ ├── deleted: boolean
│ ├── createdAt: timestamp
│ └── updatedAt: timestamp
└── tasks/
└── {taskId}/
├── title: string
├── description: string
├── status: string ("todo" | "done")
├── authorId: string
├── deleted: boolean
├── createdAt: timestamp
└── updatedAt: timestamp
```
---
## 7. 画面構成（MVP）
### 7.1 画面一覧
| 画面名 | URL パス | 説明 |
|---|---|---|
| ログイン | `/login` | ユーザー名・パスワード入力 |
| メモ一覧 | `/notes` | メモのリスト表示 + 新規作成ボタン |
| メモ詳細/編集 | `/notes/:id` | メモの閲覧・編集 |
| タスク一覧 | `/tasks` | タスクのリスト表示 + 新規作成ボタン |
| タスク詳細/編集 | `/tasks/:id` | タスクの閲覧・編集 |
### 7.2 画面遷移図
```mermaid
graph LR
Login[ログイン] --> NoteList[メモ一覧]
Login --> TaskList[タスク一覧]
NoteList --> NoteDetail[メモ詳細/編集]
NoteDetail --> NoteList
TaskList --> TaskDetail[タスク詳細/編集]
TaskDetail --> TaskList
NoteList <--> TaskList
```
---
## 8. 開発・デプロイ計画
### 8.1 ディレクトリ構成（案）
```
cloudnotes/
├── client/ # フロントエンド (Vite)
│ ├── src/
│ │ ├── pages/ # 各画面
│ │ ├── components/ # 共通コンポーネント
│ │ ├── api/ # API クライアント
│ │ └── main.js
│ ├── index.html
│ └── vite.config.js
├── server/ # バックエンド (Express)
│ ├── src/
│ │ ├── routes/ # API ルーティング
│ │ ├── middleware/ # 認証ミドルウェア等
│ │ ├── models/ # Firestore アクセス層
│ │ └── index.ts
│ ├── tsconfig.json
│ └── package.json
├── Dockerfile # Cloud Run 用
├── .dockerignore
└── README.md
```
### 8.2 開発フロー
```mermaid
graph LR
A[ローカル開発] -->|git push| B[GitHub リポジトリ]
B -->|手動 or Cloud Build| C[Docker イメージビルド]
C -->|gcloud run deploy| D[Cloud Run デプロイ]
```
### 8.3 MVP マイルストーン
| フェーズ | 内容 | 想定期間 |
|---|---|---|
| 1-1 | プロジェクト初期設定、Docker + Cloud Run 動作確認 | 1-2日 |
| 1-2 | 認証 API 実装（ログイン/JWT） | 1-2日 |
| 1-3 | メモ CRUD API + フロントエンド | 2-3日 |
| 1-4 | タスク CRUD API + フロントエンド | 2-3日 |
| 1-5 | 結合テスト + Cloud Run デプロイ | 1-2日 |
| **合計** | **MVP リリース** | **約1〜2週間** |
---
## 9. 将来拡張（フェーズ2以降の候補）
以下は MVP 後に検討する機能候補です。優先度は利用状況を踏まえて決定します。
| 機能 | 概要 |
|---|---|
| Markdown 対応 | メモ本文の Markdown レンダリング |
| 画像・ファイル添付 | Cloud Storage を利用したファイルアップロード |
| 全文検索 | Firestore の全文検索 or Algolia 連携 |
| カンバンボード | タスクのドラッグ＆ドロップ表示 |
| 締切日・優先度 | タスクへの期限・優先度設定 |
| 担当者アサイン | タスクをメンバーに割り当て |
| PWA 対応 | オフラインキャッシュ、ホーム画面追加 |
| OAuth 認証 | Google ログイン等のソーシャルログイン |
| 通知機能 | メール・プッシュ通知 |
| RBAC | 管理者/メンバーの権限分離 |
| API 連携 | Slack、Webhook 等の外部サービス連携 |
---
## 10. リスクと対策
| リスク | 影響 | 対策 |
|---|---|---|
| Basic Auth のセキュリティ | パスワード漏洩の可能性 | HTTPS 必須（Cloud Run 標準）、bcrypt ハッシュ化、早期に OAuth 移行を検討 |
| Firestore の無料枠超過 | 想定外のコスト発生 | GCP 予算アラート設定、クエリ最適化 |
| コールドスタート | 初回アクセス時に遅延 | 最小インスタンス数=1に設定（コスト増を許容する場合） |
| データロスト | ユーザーデータの消失 | Firestore 自動エクスポート設定（Cloud Scheduler + Cloud Functions） |
| 排他制御なし | 同時編集時のデータ上書き | MVP では許容。フェーズ2で楽観的ロック（updatedAt 比較）を導入 |
---
## 11. 用語集
| 用語 | 説明 |
|---|---|
| MVP | Minimum Viable Product（実用最小限の製品） |
| Cloud Run | Google Cloud のフルマネージドコンテナ実行サービス |
| Firestore | Google Cloud の NoSQL ドキュメントデータベース |
| JWT | JSON Web Token。認証情報をトークンとして表現する規格 |
| SPA | Single Page Application。画面遷移を JS で制御する Web アプリ |
| PWA | Progressive Web App。Web アプリをネイティブアプリのように動作させる技術 |
| RBAC | Role-Based Access Control（ロールベースアクセス制御） |
| 論理削除 | データを物理的に削除せず、削除フラグを立てる方式 |
この要件定義書をベースに、次は設計書や実装に進めていくといった開発が考えられます。また、この程度のコンテキストであれば、LLMがここまでの内容を覚えていられるので、一気にコーディングを走らせるという使い方もできます。
要件定義書を読み込んで実装を開始しデプロイまで実行してください。
というような、指示でここまでの内容からLLMが実装を開始します。
ここまでは、逆質問プロンプト（＋出力自動化）の一例を紹介しました。"＋出力自動化"と書いているのは、２つのプロンプトパターンを組み合わせているためです。次の章では、そのほかのプロンプトパターンを見ていきます。
プロンプトパターン：6つのカテゴリ
プロンプトパターンはおおむね以下の6カテゴリに整理されています。
| カテゴリ | 目的 | 所属パターン |
|---|---|---|
| 入力意図・意味 | LLMへの入力の解釈方法を定義する | メタ言語構築 |
| 出力カスタマイズ | 出力の形式・構造・性質を制御する | 出力自動化、ペルソナ、画像生成、レシピ、テンプレート |
| エラー識別 | 出力の誤りを検出・修正する | 事実確認リスト、内省 |
| プロンプト改善 | 入出力の品質を向上させる | 質問、代替手段、認識確認、回答拒否 |
| 相互作用 | ユーザーとLLMの対話構造を設計する | 逆質問、ゲームプレイ、無限に生成 |
| 文脈制御 | LLMの動作文脈を管理する | 文脈管理 |
パターン一覧
以下に、16のプロンプトパターンを一覧で整理しました。各パターン、概要、プロンプト例からユースケースに最適なパターンの選定に活用して頂けたらと思います。
| パターン | 概要 | プロンプト例（要約） |
|---|---|---|
| メタ言語構築 | 自然言語以外の記法の定義 | 「"A → B"は有向グラフのエッジです。以下のフローを図示して」 |
| 出力自動化 | 出力を実行可能なスクリプト・コマンドとして生成する | 「タスクリストに基づき、実行可能なスクリプトを生成して」 |
| ペルソナ | LLMに特定の人物や役割を設定 | 「セキュリティ専門家として、このコードをレビューして」 |
| 画像生成 | 画像生成のための生成ツールや形式の指定 | 「サービス構成を画像で出力して」 |
| レシピ | 目標達成の手順を生成 | 「Docker上にデプロイする手順の不足を補完して」 |
| テンプレート | 出力フォーマットの指定 | 「テンプレートに従ってAPIドキュメントを生成して」 |
| 事実確認リスト | 出力に基づく事実の確認 | 「回答の最後に、確認すべき事実項目をリストで提示して」 |
| 内省 | 回答の論理的な背景の出力 | 「回答を論理的矛盾・前提・反論の観点から自己レビューして」 |
| 質問洗練 | 質問をより効果的な形にする | 「質問するたび、まず改善版を提示してから回答して」 |
| 代替手段 | 代替手段の提案 | 「状態管理の実装方法を3つ、比較表付きで提示して」 |
| 認識確認 | 質問を再文化して回答精度を向上 | 「回答前に、正確に答えるための下位質問を3〜5個生成して」 |
| 回答拒否 | 回答できない場合の理由や質問の代替表現を提示 | 「回答できない場合、代わりに聞ける質問を3つ提案して」 |
| 逆質問 | 目標の達成に必要な情報をユーザーから得る | 「技術スタック提案のため、判断材料が揃うまで質問して」 |
| ゲームプレイ | ゲーム的要素で学習・探索する | 「セキュリティインシデント対応のシミュレーションゲームを作成して」 |
| 無限に生成 | 継続コマンドで連続的に出力を生成する | 「"次"と入力するたびテストケースを1つずつ生成して」 |
| 文脈管理 | 文脈を管理して会話の焦点を調節 | 「前の話題を忘れ、Linux管理者として新しい話題に回答して」 |
紹介した１６のプロンプトパターンは、LLMとの対話を設計する際の基礎的な文法のようなものです。業務や作業に最適なプロンプトを選んでぜひ活用してみてください。
