「ChatGPTに頼んだのに、出てきた成果物をそのまま使えなかった」——業務でAIを使い始めた人が最初にぶつかる壁です。
原因の多くはモデルの性能ではなく、プロンプトが「指示」の粒度で書かれていることにあります。人間同士なら「いい感じにまとめて」で通じますが、LLMは前回の文脈も社内の暗黙知も持っていません。結果として、毎回フォーマットが変わり、前提を勝手に補完し、結局すべて手で直すことになります。
本記事では、実務で再現性のある成果物を出すための 「入力・制約・出力」の設計フレームワーク（ICOフレーム）、コピペで動く実践テンプレ3本、そしてそれを自動化パイプラインに組み込む際のアーキテクチャを解説します。
特定のモデル・機能に依存しない書き方にしているため、ChatGPT / Claude / Gemini のいずれでもそのまま使えます。
第1章：なぜ多くのプロンプトは実務で使えないのか
実務で失敗するプロンプトには、共通する3つの型があります。
1-1. 出力形式が毎回変わる
「箇条書きでまとめて」とだけ書くと、見出しの深さ、記号、並び順が毎回変わります。1回目は使えても、2回目に別の形式が返ってきて、後工程（コピペ・表計算への転記・レビュー）が破綻します。
1-2. 前提をAIが勝手に補完する
「新製品の告知文を書いて」と依頼すると、AIはターゲット・価格・提供時期を"もっともらしく"埋めます。これは単なるハルシネーションではなく、空欄を埋めるように動く仕様だからです。埋めてほしくない空欄は、明示的に「不明な点は不明と書け」と指示する必要があります。
1-3. 「いい感じに」の解像度不足
人間の「いい感じ」は、社内の過去資料・上司の好み・業界慣行の集合体です。LLMはそれを知らないので、平均的な無難な文章に落ちます。平均的な文章は、平均的な成果しか生みません。
つまり、プロンプトは「お願い」ではなく 仕様書 として書く必要があります。ソフトウェア開発で曖昧な要件定義が手戻りを生むのと同じ構造です。
第2章：成果物のブレをゼロにする「入力・制約・出力」の設計フレームワーク
実務で使っているのは、次の3ブロックに分けて書く方法です（ICOフレーム）。
| ブロック | 役割 | 書くこと |
|---|---|---|
| Input | 何を材料にするか | 素材、読み手、目的、役割（ペルソナ） |
| Constraint | 何をしてはいけないか | 文字数、トーン、禁止表現、推測の扱い |
| Output | どう返すか | 形式（JSON/Markdown表）、見出し構造、必須項目 |
2-1. Input：材料と読み手を固定する
- 素材は本文に貼る（参照させたい資料は「これが唯一の根拠」と明示する）
- 読み手を「誰が、何を知っていて、何を決めるのか」まで書く
- 役割は「あなたは編集者です」程度では弱い。「〇〇業界の提案資料を10年レビューしてきた」のように判断基準を持つ役にする
2-2. Constraint：禁止事項を箇条書きにする
制約は文章で書かず、箇条書きのチェックリストにします。LLMは箇条書きの各項目を個別に参照しやすいためです。
- 素材に書かれていない事実を追加しない。不明点は「要確認」と出力する
- 数値・固有名詞は素材の表記をそのまま使う
- 1文は60字以内、体言止めを使わない
- 誇張表現（絶対・必ず・誰でも）を使わない
2-3. Output：機械的に検証できる形にする
出力は「読みやすい」より「検証できる」を優先します。表やJSONにすると、抜け・重複・型の不一致をプログラムで検出できます。
- 見出し構造を固定する（H2は3つ、各H2にH3を2つ、など）
- 必須項目を列挙する（担当・期限・根拠）
- 可能ならJSON Schemaを渡す
2-4. 仕上げに「自己レビュー1回」を挟む
生成→検証→修正のループを、1つのプロンプト内で完結させます。
出力後、以下の観点で自己レビューし、問題があれば修正版のみを再出力してください。
1. Constraintの各項目に違反していないか
2. Outputの必須項目がすべて埋まっているか
3. 素材にない事実を追加していないか
これを入れるだけで、手戻りが体感で半分以下になります。
第3章：【コピペで即動く】実務効率化プロンプト厳選3本
テンプレ1：会議メモ → タスクJSON（構造化抽出）
# 役割
あなたはプロジェクト管理を専門とするPMです。
# 入力
以下は会議の議事メモです。このメモに書かれている内容だけを根拠にしてください。
<minutes>
{{MEETING_MINUTES}}
</minutes>
# 制約
- メモに書かれていないタスクを追加しない
- 担当者が不明な場合は "未定"、期限が不明な場合は null とする
- 決定事項と検討中の事項を混同しない
# 出力
以下のJSONのみを出力してください（前後に説明文を付けない）。
{
"decisions": [{"content": "", "evidence": "メモの該当箇所を引用"}],
"tasks": [{"title": "", "owner": "", "due": "YYYY-MM-DD or null", "priority": "high|mid|low", "evidence": ""}],
"open_questions": [""]
}
出力後、tasksの各項目について「メモのどこに根拠があるか」を自己確認し、
根拠が示せない項目は削除してから最終出力してください。
evidence（根拠の引用）を必須にしている点がポイントです。根拠を書かせると、AIが"それらしいタスク"を作る余地が減り、人間のレビューも一瞬で済みます。
テンプレ2：箇条書きメモ → 提案書ドラフト（構成→本文の2段階生成）
長文を一発で書かせると、後半が薄くなります。構成だけ先に出させ、確認してから本文を書かせるのがコツです。
# 役割
あなたはBtoB提案書の構成設計が得意なコンサルタントです。
# 入力
<facts>
{{FACTS}}
</facts>
読み手: {{AUDIENCE}}
意思決定してほしいこと: {{DESIRED_DECISION}}
# 制約
- factsにない実績・数値を創作しない
- 読み手の懸念（コスト・工数・リスク）に必ず1節を割く
- 1節あたり300〜400字
# 出力（第1段階）
H2見出し5つと、各節で書く内容を1行で示した「構成案」のみを出力してください。
本文はまだ書かないでください。
---（構成を確認したら、続けて実行）---
上記の構成案で確定です。各節を300〜400字で執筆し、
冒頭に100字の要約、末尾に「次のアクション」を3項目置いてください。
テンプレ3：成果物のセルフレビュー（品質ゲート）
自動化パイプラインでは、生成物をそのまま次工程に流すのが一番危険です。公開・送信の直前に挟むレビュー用プロンプトです。
# 役割
あなたは厳格なレビュアーです。書き手の意図を汲まず、基準のみで判定します。
# 入力
<draft>{{DRAFT}}</draft>
<rules>
{{RULES}}
</rules>
# 出力
各ルールについて PASS / FAIL を判定し、FAILには該当箇所の引用と修正案を付けてください。
最後に「公開可否: OK / 要修正」を1行で出力してください。
# 制約
- 好みの指摘はしない。rulesに書かれた基準のみで判定する
- FAILが0件でも、改善提案は最大3件までに留める
このゲートを入れると、人間のレビューは「OKか要修正か」の判断だけで済み、確認コストが大幅に下がります。
第4章：自律型AIエージェントへの組み込みと自動化アーキテクチャ
ここまではチャット上での使い方でした。実務では、これを関数にしてパイプラインに組み込みます。
4-1. プロンプトをテンプレート変数化する
プロンプトはコードと同様にバージョン管理します。変数は {{...}} で明示し、埋め忘れをテストで検出できるようにします。
PROMPT_VERSION = "v3"
TEMPLATE = """...{{MEETING_MINUTES}}..."""
def build_prompt(minutes: str) -> str:
if not minutes.strip():
raise ValueError("minutes is empty")
return TEMPLATE.replace("{{MEETING_MINUTES}}", minutes)
4-2. 出力をスキーマで検証し、1回だけ自動リトライする
LLMの出力は確率的です。検証エラーを例外で止めるのではなく、修正指示として返すのが安定運用の鍵です。
from pydantic import BaseModel, ValidationError
class Task(BaseModel):
title: str
owner: str
due: str | None
priority: str
evidence: str
class Extraction(BaseModel):
decisions: list[dict]
tasks: list[Task]
open_questions: list[str]
def extract(minutes: str, call_llm, retries: int = 1) -> Extraction:
prompt = build_prompt(minutes)
for _ in range(retries + 1):
raw = call_llm(prompt, temperature=0)
try:
return Extraction.model_validate_json(raw)
except ValidationError as e:
# エラー内容をそのまま修正指示に変換する
prompt += (
"\n\n前回の出力はスキーマ違反でした。違反内容:\n"
f"{e}\n修正したJSONのみを再出力してください。"
)
raise RuntimeError(f"schema validation failed: {PROMPT_VERSION}")
temperature=0（または最小値）にしても完全な決定性は得られないため、リトライとログは必須です。失敗時はプロンプトと検証エラーを保存しておくと、テンプレ改善のサイクルが回ります。
4-3. パイプライン全体の構成
[トリガー] 会議終了 / ファイル更新 / 定時cron
↓
[入力正規化] 文字起こし・文字数制限・個人情報の除去
↓
[生成] ICOフレームのプロンプト（テンプレ1）
↓
[検証] スキーマ検証 → 失敗時は1回だけ自動リトライ
↓
[人間ゲート] テンプレ3でレビュー → 要修正なら差し戻し
↓
[出力] タスク登録・通知・実行ログの保存
4-4. 自動化で必ず入れる3つの安全装置
- 冪等性：同じ入力でタスクが二重登録されないよう、入力ハッシュをキーにする
- 人間ゲート：外部送信・公開・金額が絡む操作は必ず承認を挟む
- コスト上限：1実行あたりのトークン上限を設定し、超過時は停止して通知する
おわりに
本記事の要点は4つです。
- プロンプトは「お願い」ではなく「仕様書」として書く
- Input / Constraint / Output の3ブロックに分ける
- 出力は機械的に検証できる形（JSON・表・固定見出し）にする
- 自動化するなら、スキーマ検証・リトライ・人間ゲートをセットで設計する
この4点だけで、AIの成果物は「使える/使えない」から「そのまま流せる」に変わります。
実務でのテンプレ運用や、非エンジニア向けに噛み砕いた手順は以下にまとめています（無料の記事一覧です）。