実務で使える汎用プロンプトテンプレートの設計思想と使い方
はじめに
AIを実務で活用しようとすると、「毎回プロンプトを一から書くのが大変」「結果が毎回バラバラになる」といった課題に直面します。
本記事では 自分がこれまで業務で見てきた品質の高いプロンプトを参考に作成した汎用プロンプトテンプレート を紹介し、各セクションがなぜ必要なのかを解説します。
🎯 テンプレート全体（完成形）
以下は、実務向けに設計されたテンプレートの構造です。
---
allowed-tools: ["Bash(*)", "Read", "Write"]
description: "<アシスタントが実現する具体的な目的と成果物の形式を記述>"
argument-hint: "<ユーザー入力の形式・期待値（例: URL, JSON, Command）>"
---
## あなたの役割
指定されたタスクを安全かつ再現可能な形で実行し、
最終成果物を指定形式（例: Markdown, JSON, ファイル出力）で提供します。
---
## 実行手順
1. **前提確認**
- 必要な情報（URL・認証情報・パスなど）を確認
- 不足や曖昧な点はユーザーに質問して補完
2. **アクション実行**
- 2.1 アクションのステップ1
- 2.2 アクションのステップ2
- 2.3 アクションのステップ3
3. **反映・報告**
- 成果物を保存または連携先に送信（例: GitHub, Notion）
- 要約と結果の確認をユーザーに提示
---
## エラー対処
- 軽微な失敗（API応答遅延など）は1回再試行する。
- 構文エラーや外部依存エラーは原因を要約し、ユーザーに確認を求める。
- 失敗時は必ず次の形式で報告：
```json
{ "status": "error", "reason": "<原因>", "suggestion": "<修正方針>" }
```
---
## 出力ルール
- すべての出力は確定的・再現可能な形で記録する
- 表記・命名・フォーマットは統一（例: snake_case, kebab-case）
- 明示的に指定がない限り、Markdown形式で出力
---
## 開始メッセージ
```
[START] <タスク名>
前提条件を確認し、順に実行します。
```
全体を通した設計意図
ひとつのタスクがなるべく小さくなるようにしています。AIは単純なタスクほど生成の質が上がります。よって全体を通して、一つ一つの処理がシンプルかつ明確になるようなプロンプトになっていれば意図通りの生成をできる確率が高くなる気がしてます。
テンプレート中では使用ツールの限定、ステップ化でそのあたりカバーしていますが、プロンプトを作る際はルールとタスクを分けるなどの関心の分離も有効だと思います。
🧠 各セクションの意図と「なぜ必要か」
1. Front Matter（--- で囲まれた部分）
何をする場所？
テンプレートの「仕様」を定義します。使用可能ツール（allowed-tools）、目的（description）、入力仕様（argument-hint）など、実行時の前提を固定します。
なぜ必要？
-
曖昧性の排除と安全性向上：どの権限・ツールが使えるかを明示し、想定外の操作を防ぎます。
- AIの出力の質を高めるためには、取りうる選択肢の幅を少なくすることが重要です。allowed_toolsで使う道具を限定させることで出力が、意図通りになる確率が上がります。
-
目的の共有：
descriptionにより判断基準が定まり、指示のブレを低減します。 -
入力エラーの抑制：
argument-hintで期待する入力形式を示し、ミスを減らします。 - 再現性の担保：誰が使っても同じ条件で動かせ、結果の一貫性が上がります。
📚 参考資料:
2. 「あなたの役割」
何をする場所？
AIに求めるスタンス・判断軸・ゴールを明示します。
なぜ必要？
- 意図の共有：単なる作業実行ではなく、目的に沿った判断が可能になります。
- 脱線防止：タスクの範囲と優先度を示すことで拡散を抑制します。
- 品質の安定：出力形式（例：Markdown/JSON/ファイル）を先に決めておくとレビューと自動処理が容易。
📚 参考資料:
3. 「実行手順」
何をする場所？
作業を段階化し、「何を・どの順で・どうやって」進めるかを示します。
なぜ必要？
- 段階的推論で精度向上：一気通貫指示より、段階化の方が誤推論を抑制できます。
- 再利用性：「取得 → 変換 → 出力」の構造は多くのワークフローに適用可能。
- 中間チェックポイント：フェーズごとに確認・補正が可能。
📚 参考資料:
4. 「エラー対処」
何をする場所？
失敗時のふるまいを事前に定義し、報告形式も固定します。
なぜ必要？
- 失敗の可視化：暗黙エラーや誤答を“成功扱い”にせずに検知可能。
- 自動化連携：JSON形式で報告すれば、CI/CDやSlack通知で扱いやすい。
- 運用耐性：再試行ルールを定めて安定化。
5. 「出力ルール」
何をする場所？
形式・命名規則・スタイルを統一し、結果を資産化できる状態にします。
なぜ必要？
- 一貫性と機械可読性：フォーマットを統一すれば、後工程（解析・比較・保存）が容易。
- 品質の安定：同じ構造を維持できるため再現性が上がる。
- レビュー効率：差分（diff）が取りやすく、ナレッジ化しやすい。
📚 参考資料:
6. 「開始メッセージ」
何をする場所？
タスク開始を明示し、人にも機械にもわかるログ出力を行います。
なぜ必要？
- トレース性：いつ・何が始まったかを明示し、デバッグや再実行を容易に。
- 対話と自動化の両対応：SlackなどでのChatOps連携やCIログ出力に有効。
- 運用性向上：失敗時のトラブルシューティングを高速化。
🚀 このテンプレートの強み（要約）
| 観点 | 内容 |
|---|---|
| 再現性 | 初期条件・構造・出力を固定し、誰が使っても同じ流れに |
| 自動化 | JSON/定型メッセージで CI/CD・通知と連携しやすい |
| 拡張性 | 手順・出力規則を差し替えるだけで多用途化 |
| 安全性 | allowed-tools とエラー設計で誤操作を抑制 |
| 運用性 | ログ/開始メッセージで履歴追跡とデバッグが楽 |
🧩 まとめ
このテンプレートは、AIを「ただの道具」ではなく 運用可能なワークフロー として扱うための骨格です。
まずは普段のタスク（レポート生成、ドキュメント整形、Issue 自動化など）をこの構造に落とし込み、目的・手順・出力・エラー を統一してみてください。
それだけで、出力品質・再現性・運用安定性が大きく向上します。
Discussion