fukukei23 outward-reply — 外向き返信文生成
目的
外向き返信文のAI初稿が人間の複数回訂正を要した実績失敗（2026-08-16ココナラ案件）を構造的に封じる。「正確で網羅的な文」でなく「相手にどう思われ・何を答えさせ・何を伏せるか」で勝負する文を作る。
トリガーワード
「返信文」「提案文」「文面」「メール書いて」「応募メッセージ」/ /outward-reply
（送信したい（実行したい）時は send-email へ誘導）
棲み分け
teian/sentaku=判断系 / brainstorming=設計系 / send-email=送信実行系 / 本スキル=文面生成系
封じるべき失敗（実例・SKILL.mdにはこの1行サマリーのみ載せる）
- ①未検証の技術的断言（「対応可能です」→実測後に「見込み」に格上げすべきだった）
- ②実装進捗の情報出しすぎ（「動作検証済みの実装があります」→交渉材料を先に渡した）
- ③確認質問4件の質問攻め（非技術者への負担）
- ④相手の文に既に書いてあることの再質問（精読不足・最悪の失敗）
- ⑤専門用語のまま（「PC常設/クラウド側で常時実行」）
- ⑥失敗分析時の自己弁護（「判断材料はユーザーの頭にしかない」→実際は相談文のみで予測可能だった）
- ⑦質問対象の選択ミス（自側の作業パラメータ〔リスト構成・数量・規模感等〕を質問化して相手に選ばせる / 相手の回答から導出できる項目〔例: 取扱商品→形態・価格帯〕まで質問に含める→質問件数が膨らむ。2026-08-18 深井神話返信・log 20260818-05）
- ⑧未契約段階の継続作業示唆（「作業は止まりません」「並行して進めています」等→まだ依頼していない相手に「作業をしてもらっている」負い目を与え、契約前提の空気という心理的圧力になり得る。無期限の待機表現「お急ぎにならずお待ちしております」へ置換。2026-08-18 同上）
詳細: obsidian-ssot/00_SYSTEM/参考資料/LLMサボりバイアス実例/2026-08-16_外向き返信文の情報戦略欠落-ココナラ見積り相談.md
フロー
Phase 0: 材料精読ファースト（失敗⑥封じ）
本文に触れる前に、順に実行:
- 相手の文面を再精読（読み飛ばし禁止）
- 既述事項を抽出（短い引用つきで列挙 → 質問禁止リスト化）
- 一般常識で安全に仮定できる範囲を明記
- 残るgapだけをユーザーに質問（トレードオフ判断が必要なもののみ。無ければ聞かない）
「ユーザーの頭にしかない情報」と結論づける前に1〜3を必ず実行する。
モード分岐（リスクベース）
分岐は「軽微さ」でなくリスクで判定:
- フルモード: 交渉・技術的断言・機密・複数条件のいずれかを含む → 精読シート6欄を出力しユーザーの目視確認を得てから本文生成
- 簡易モード: 上記を含まない（1行返信・日程調整等）→ シートは内部処理・本文末尾に精読根拠を折り畳み表示
簡易モードでも「最小5禁止」は常に機械適用（下記・省略しない）。
精読シート6欄（フルモード・1行〜数行・空欄は「N/A」明示・推測で埋めない）
| 欄 | 内容 | 封じる失敗 |
|---|---|---|
| 1. 読者像 | 役割・技術レベル・求める成果（推測か事実か区別） | ⑤ |
| 2. 文脈+次アクション | 媒体・返信の段階・期限 + この文で相手にさせたい次のアクション1つ | ③⑤ |
| 3. 相手の文に既に書いてあること | 短い引用つき一覧（→ここから質問禁止） | ④ |
| 4. 自側の検証ステータス | 実測済（証跡あり）/ 見込み / 未確認 を区別 | ① |
| 5. 出す情報/出さない情報 | デフォルト非開示: 実装進捗・コード・アーキテクチャ詳細・未契約段階の解決策詳細・未検証の仮説。開示時は目的・範囲・時期を明記 | ② |
| 6. 質問候補+仮定条件 | 各質問に「なぜ既述から答えられないか」必須。通知形パターン（「〇〇前提で進めます」「〇〇の場合は追加でお知らせください」）を優先 | ③④ |
本文ルール
- 能力・実績・期間・料金・効果の断定には3値ラベル必須: 検証済（証跡あり）/ 見込み / 未確認（→断定回避表現へ変換）
- 相手への質問は0〜1件まで。2件以上必要なら質問化せず仮定条件として本文に記載
- 質問は相手が最も答えやすい領域に置く（⑦封じ）: 自店・自身の専門など「相手が語るだけで済む領域」に質問を設定し、そこから導出できる項目（形態・価格帯等）は個別に質問しない。自側の作業パラメータ（リスト構成・数量・規模感・方式）は質問化せず「〇〇として進めます」の通告に回す。回答形式は選択式が基本だが、質問対象が相手の専門領域なら「例示付き自由記述」（例: 「○万円〜○万円くらい」で結構です）も負担は低い
- 専門用語は読者像が非技術者なら言換え（例: 「クラウド側で常時実行」→「インターネット上の借りサーバーで自動実行する方式」）または初出時に平易な説明
最小5禁止（両モード常時適用・機械的）
- 既述事項（欄3）の再質問禁止
- 未検証断言の禁止（見込みまで）
- 専門用語は平易言換え or 初出説明
- 相手への質問は0〜1件
- 進捗・内部情報の過剰開示禁止
出力形式
- 本文（送信用・コピー可能な形で）
- 自己点検表: 最小5禁止 × 合格/要修正/該当なし+根拠 を行形式で（自己申告「やりました」禁止）+ 実数カウント（本文中の質問数・断定表現数）
- 違反があれば本文上部に ⚠️フラグ（「未確認断言あり」「既述再質問あり」等）を表示し、修正してから確定（ユーザーの目視だけに頼らない）
- ログ追記行:
ログ追記: 完了(ID=YYYYMMDD-nn)— 本行を出力しない限り完了報告しない（追記のフロー強制・spec 2026-08-16要件1）
Phase 99: 実績ログ記録（spec 2026-08-16・フロー強制）
99-1. 生成時（仮行追記）
obsidian-ssot/00_SYSTEM/参考資料/外向き返信実績/log.md の表末尾に1行追記（ID=YYYYMMDD-nn・nは当日通番）:
| ID | 日付 | 宛先種別(ココナラ/エージェント/応募/企業メール) | 対話フェーズ(初手/往復/交渉/断り) | モード(フル/簡易) | 質問数 | 断定数 | ⚠️フラグ | (修正回数=仮) | (修正類型=仮) | 本文要約200字+冒頭一文 | (効いた軸=仮) | 結果=未定 |
仮の列（修正回数・修正類型・効いた軸）は「仮」と記入し、99-2で確定値に更新する。
記録単位は「返信案件」（宛先×用件ごとに1行）。文章を出した回数ではない:
- 同一案件の再出力（表示切れ対応含む）・修正版・別案（A/B案）は同じIDの行を更新し、新規行を作らない
- 別案を出した時は本文要約欄に「第2案:〜」を追記し、確定時にどの案を採用したか明記
- セッションをまたいで同一案件（同じ宛先+用件）を再依頼された場合も、log.mdの既存行（宛先+用件の一致）を更新
- ユーザーがどの版を送ったか会話で確定しないまま終わった行は「仮」のまま残す（どの版が送られたかAIは原理的に知り得ないため。仮置き行の停滞は20件Go/No-Goの「修正記録つき1/3未満」指標で検知する）
99-2. 返信確定時（送信・会話打切り・ユーザー確定のいずれか早い時点）
同じIDの行を確定値で更新:
- 修正回数: 会話内でのユーザー訂正回数（表示切れ再出力は未修正の再表示のみカウントしない・文言変更があったらカウント）
- 修正類型: 既知5種（情報過剰/質問過多/専門用語/未検証断言/既述再質問）から分類。どれにも該当しない修正は【新種:○○】（操作可能定義・spec §3）
- 効いた軸: 固定タグ（共感/実績証明/条件提示/質問少なさ/速度）+自由記述100字
99-3. 深掘り判定（修正回数は不使用）
- 修正類型が【新種】→ 深掘り提案をユーザーに提示 → 承認で
cases/に全文ケース化（初稿→最終版→修正経緯） - 既知類型の月内3回再発・ユーザー「これ残して」→ 月次提案/cases/ に同じ
完了条件
「ログ追記: 完了(ID=...)」を出力するまで本スキルは完了しない。追記失敗時は再試行1回→失敗なら会話内にログ行を提示し手動復旧を促す。
送信前の最終目視（ユーザー担当）
誤字・行の長さ（相手の端末で見切れないか）・文字化けは、送信前にユーザーが一度通す。
検証（スキル改訂時）
改訂したら 2026-08-16 のココナラ相談文でリプレイテスト: 5失敗の違反残存ゼロを確認し、測定方法（どの禁止に照合したか）を記録に残す（件数だけの主張禁止）。