---
name: dialogue-prompt
description: 対話から人間の制作動機を整理し、エージェントに託す目的と実行条件を備えたプロンプトを作成・改訂する。対話をもとにした指示づくり、目的と手順の整理に使う。
---

# 対話から育てるプロンプト

## 制作動機

対話から文章を育てる方法は、AIへの指示づくりにも使えるのではないか。人間が抱いた困りごとや願いを残し、それを受け取ったAIが仕事を具体化する。この二つの働きを分けて辿れる道具が欲しい、という着想から生まれた。

## Why / Intent：希望を受け取り、実行へつなぐ

人間の希望を理解し、次のエージェントへ託せるプロンプトにする。何を大切にして作るのかと、実際にどう進めるのかがつながり、使う人も後から判断を見直せる指示を目指す。

人間の問い返しや方向修正も、意図を知る材料として扱う。対話の中で理解が進んだことを、実行するAIに必要な目的と条件へまとめる。

## How / Schema：対話からプロンプトを育てる

### 1. 素材と依頼をつかむ

参照できる対話と既存の指示を読み、目的、困りごと、望む結果、重要な選択を把握する。途中から呼ばれた場合も既存の会話を出発点にする。入力、実行先、出力や権限について、判断を左右する不足だけ少数の質問で確かめる。軽微な仮定は明示して案を進める。

### 2. 人間の制作動機を残す

人間が何に困り、何を望んだかを、一つのまとまった文章にする。特徴的な言葉や比喩を活かし、語句や順序を読みやすく整える。主張、価値判断、確信の強さを保つ。

生成するプロンプトには「制作動機」を独立して置く。短い仕事なら一、二文でよい。背景が語られていない場合は未確認と記し、確認の必要性は実行への影響で判断する。

### 3. 思考と手続きを分けて具体化する

生成する指示を、以下の二層へ分ける。Dialogue Essayの編集方法を適用するのは、思考・適応の層である。

#### 思考・適応のレイヤー：目的型

人間の制作動機と、エージェントへ託す目的を別の部分にする。本人の困りごとや問いをまとまって伝え、それを受けたエージェントの検討・判断へつなぐ。人間の意図とAIによる具体化の出自が辿れるように書く。

仕事に応じて、問いの緊張関係、仮説を支持・反証する材料、探索と判断の切り替え、軌道修正を選ぶ理由を説明する。何を見て次の判断を選ぶかを、目的から理解できる文章に整える。Explore / Decisionなどの名称は、対象の仕組みにある場合に使う。

#### 状態・記録・検証のレイヤー：手続き型

この層は従来のプロンプト編集として扱う。入力、操作、順序、出力形式、検証条件、失敗時の処理を具体的に記す。API名、コマンド、ファイル名、フィールド名、スキーマの制約は、確認した仕様に合わせて正確に保持する。

状態変更を伴う操作では、開始条件、更新対象、実行手順、成功の確認、失敗・結果不明時の扱いを整理する。順序が意味を持つ手順は番号付きで示す。必須条件や禁止条件も、その処理が要求する強さで明記する。説明の柔らかさのために実行条件を曖昧にしない。

SDKやCLIがない仕事では、実際に必要な入出力と確認手順に合わせる。文書を整えるだけの仕事へ、状態管理APIやモード制御を追加しない。

#### 二層の対応をつなぐ

例えば、問いを立て直す理由と判断は思考層に、その判断を記録へ反映して検証する操作は手続き層に置く。重要な判断について「判断・きっかけ → 対応する操作 → 確認する状態」を示す。

思考上の提案、記録された状態、実行の許可は区別する。目的に応じた判断も、指定された権限と有効な状態遷移の範囲で実行する。仕様が参照できない手続きは未確認として切り分け、必要な資料を求める。

AIが補う条件は、どの希望を実現するための提案かを説明する。人間が採用・修正した場合は、その経緯を設計資料に残す。

### 4. 使える形で渡す

完成した実行用プロンプトと、意図・設計判断・重要な条件の対応を渡す。短い依頼は一つの文書にまとめてよい。実行に必要な条件は本文へ、詳しい経緯や比較は別添へ置く。

対応表を使う場合は、条件の出自を「人間の明示」「既存の運用条件」「AIの提案」「未確定」として整理し、確認方法を添える。改訂では元の指示を保存し、表現の変更と条件の追加・削除を区別する。

## 意味・帰属・実行範囲の境界

- 動機と引用は参照できる対話に基づける。AIの推測や提案を本人の当初の希望として記さない。材料のない動機は創作しない。
- 制作動機とWhyは、短くても主語の違いを保つ。人間の希望を抽象的な実行目的へ吸収しない。
- 目的は明示された制約・権限の範囲内で実現する。矛盾は示し、確認が必要な判断と進められる作業を分ける。比較案の作成だけで現行版を置き換えたり、外部へ実行したりしない。
- 外部書き込みを扱う指示には、許可範囲、送信不明時の確認先、再試行の停止条件を含める。読み取りや整形だけの仕事に公開の承認工程を持ち込まない。
- 設計資料なしでも必要な仕事が分かる完成稿にする。外部参照は実行先で利用できる場所と読むタイミングを示す。人物紹介が必要な場合に掲載名を確認する。

## 仕上げの確認

初読で、人間が望んだこと、エージェントへ託す仕事、その進め方が順に伝わるかを確かめる。具体的な困りごとや比喩が判断の手掛かりとして残り、条件が意図と対応しているかを見る。

思考層では、制約の反復が考えの筋道を遮っていれば配置を整える。手続き層では、操作順序・条件・識別子が仕様と一致し、判断がどの更新と検証につながるかを確認する。手続き上必要な厳密さを、文体統一のために弱めない。必要な確認が済んだら完成とする。

実行比較を依頼された場合は、同じ入力と評価基準を使う。書き方の効果を見る比較では運用条件も揃える。実際に確認した結果と、未実施の予想を分けて報告する。