これめちゃくちゃわかります！ そこでこれを防ぐ『ピンクの象』防止スキルを作りました。 こんなことをスキルに？　と思うかもしれませんが、概念としてエージェントに持たせておくことでコミュニケーションコストが減り、会話を重ねるごとにブラッシュアップしていけるようになると思います。 増えていくスキルを定期的に統合・整理するスケジュールも必須です。 ✅スキル仕様書mdはこちら Pink Elephant Guard / ピンクの象ガード 仕様書 ## 1. 目的 修正会話では、削除した案や訂正前の内容がコンテキストに残り続ける。 そのためAIが「もう使わない要素」を、完成稿の見出し、説明、台詞、構図、画像内文字などへ再登場させることがある。 Pink Elephant Guardは、却下、削除、訂正、禁止された要素を変更履歴として隔離し、修正後の現在状態だけから完成物を組み直すためのスキルである。 目標は、禁止語を伏せることではない。 削除跡や言い訳を残さず、現在の目的だけで自然に成立する完成物を返すことである。 ## 2. 最初の成功体験 利用者が「その案はなし」「これは消して」と修正したあと、完成稿に旧案の単語、言い換え、削除理由、否定形、視覚的な名残が現れず、現在案だけで自然に完成する。 ## 3. 適用範囲 次のような鑑賞者または利用者向けの最終出力を修正するときに使用する。 - 広告コピー、SNS投稿、記事、見出し、CTA - 台詞、ナレーション、字幕 - 画像生成プロンプト、動画生成プロンプト - 画像内文字、物体、背景、構図 - UI文言、ラベル、説明文 - 完成版として配布する要約や資料 対象となる履歴の例: - 採用しなかった初期案 - 削除を指示された物体、人物、台詞、機能 - 訂正前の数値、名前、設定 - 禁止された表現や方向性 - 「そこではない」と否定された構図や主題 ## 4. 適用しない範囲 次の場合は、除外対象を隠さない。 - A案とB案の比較 - 変更履歴、議事録、監査記録 - 法令、契約、広告開示 - 安全、医療、アレルゲン、リスク説明 - アクセシビリティ表示 - 障害分析、原因調査、再発防止 - ユーザーが明示的に必要とした不使用訴求 本スキルは、事実、失敗、危険、義務的な開示を見栄えのために隠す仕組みではない。 ## 5. 規範用語 本書では次の意味で用いる。 - **MUST**: 実装または運用上、必ず守る。 - **SHOULD**: 原則として守る。外す場合は理由を説明できるようにする。 - **MAY**: 媒体や環境に応じて採用できる。 ## 6. 発動条件 ### 6.1 暗黙発動 次の3条件を満たす場合、スキルは暗黙発動してよい。 1. 会話内に、却下、削除、訂正、禁止された要素がある。 2. ユーザーが、鑑賞者または利用者向けの完成物を新規作成または修正しようとしている。 3. 完成物で、その履歴を説明する必要がない。 強い発動例: - 「これは消して」 - 「その案はなし」 - 「入れないで」 - 「そこじゃない」 - 「企画から外れました」 - 「前の設定は使いません」 発動判定は文字列一致だけでなく、依頼全体の意味から行う。 ### 6.2 明示発動 確実に適用したい場合は、次のようにスキル名を指定する。 > `$pink-elephant-guard` を使い、却下済みの要素を完成物へ再登場させずに修正してください。 ### 6.3 非発動 次のいずれかに該当する場合、暗黙発動しない。 - 完成物の制作ではなく、比較、監査、原因分析を求めている。 - 旧案や除外対象を記録へ残すことが成果物の要件である。 - 法務、安全、アクセシビリティ、契約上の理由で明示が必要である。 - 訂正履歴が存在しない通常の新規制作である。 ### 6.4 優先順位 判断が競合するときは、次の順で優先する。 1. 法令、安全、契約、アクセシビリティ上の必要表示 2. ユーザーが完成面へ明示するよう指定した内容 3. ユーザーが最後に確定した現在状態 4. それ以前の案や変更履歴 ## 7. 入出力契約 ### 7.1 入力 スキルは、会話から次の情報を受け取る。 | 名前 | 内容 | |---|---| | `TARGET_STATE` | 修正後に存在し、伝えるべき現在状態 | | `REJECTED_HISTORY` | 取り下げた案、削除対象、誤り、修正理由 | | `VISIBLE_EXCEPTIONS` | 完成面へ残す必要がある比較、開示、不使用訴求 | | `SURFACE` | 受け手が見る見出し、本文、台詞、画像、UI、ナレーション等 | ### 7.2 出力 出力は、次の条件を満たす完成物とする。 - `TARGET_STATE`だけで自立している。 - `REJECTED_HISTORY`を主題にしていない。 - `VISIBLE_EXCEPTIONS`だけを指定範囲内で保持している。 - 削除跡、伏字、言い訳のように見えない。 - ユーザーが「完成稿だけ」と指定した場合、検査報告を添えない。 ## 8. 処理工程 ### 工程1: 現在状態と例外を分離する 会話を `TARGET_STATE`、`REJECTED_HISTORY`、`VISIBLE_EXCEPTIONS`、`SURFACE` に分類する。 不在自体を訴求するかどうかで完成物が大きく変わり、会話から判断できない場合だけ質問する。 それ以外は現在状態を優先して進める。 ### 工程2: Clean Briefを作る `TARGET_STATE`、許可された事実、媒体、トーン、必要な構造だけで内部用briefを組み直す。 MUST: - 「Xを出さない」ではなく、Xがなくても成立する肯定形で書く。 - 削除後の空白を、目的に合う内容、構図、動作、情報階層で埋める。 - 却下理由や元案を、生成用briefへ再投入しない。 ### 工程3: 現在状態から生成する Clean Briefだけを制作上の正本として初稿を作る。 修正前の文章から数語を削る方式ではなく、現在状態を主語にして最初から組み直す。 ### 工程4: Pink Elephant Scanを行う 初稿の `SURFACE` 全体を、次の5層で検査する。 | 検査 | 確認内容 | |---|---| | Literal leak | 却下語、表記揺れ、画像内文字、ラベル | | Semantic leak | 同義語、上位語、言い換え、否定形、婉曲表現 | | Rationale leak | 削除理由、「代わりに」「以前は」などの変更説明 | | Attention leak | 不在や比較が見出し、冒頭、CTA、結論の主題になっていないか | | Visual leak | 削除物、輪郭、破片、影、容器、持ち手、プレースホルダー | `VISIBLE_EXCEPTIONS`は、指定された場所、目的、範囲でのみ許可する。 ### 工程5: 汚染した初稿を捨てて再生成する 検査がFAILの場合、漏れた単語だけを消して修理してはならない。 説明構造や構図自体が旧案中心になっている可能性があるため、工程2のClean Briefから再生成し、再度Pink Elephant Scanを行う。 ## 9. 媒体別要件 ### 9.1 文章 - 見出し、冒頭、本文、CTA、脚注まで検査する。 - 「廃止しました」「現在はありません」など、不在の説明を安易に置かない。 - ユーザーが差分報告を求めていない限り、変更経緯を完成稿へ出さない。 ### 9.2 画像生成プロンプト - 現在必要な被写体、形、配置、素材、光、接触関係を肯定形で記述する。 - 却下物を長いnegative promptとして再列挙しない。 - 表示文字、ラベル、背景小物に旧案が残っていないか確認する。 - 実画像を確認していない場合、画素上の残留を検査済みと報告しない。 ### 9.3 動画生成プロンプト - 現在必要な被写体、因果、動作、カメラ、編集、音、文字、最終フレームを定義する。 - 旧案の出来事を「起こらない出来事」として脚本へ残さない。 - 音だけに警報、失敗音、旧案の台詞が残っていないか確認する。 - 実動画を確認していない場合、フレームまたは音声上の残留を検査済みと報告しない。 ### 9.4 UIとラベル - 非表示にした機能名を空欄、無効ラベル、プレースホルダーとして残さない。 - 変更履歴画面や管理者向け監査画面は、本スキルの非発動対象として扱える。 - 利用者へ必要なエラー、安全表示、状態説明は消さない。 ## 10. 検収基準 次の8条件を満たしたときPASSとする。 - `VISIBLE_EXCEPTIONS`にない却下要素の語句が0件。 - 同義表現、否定形、婉曲表現による意味残留が0件。 - 削除理由、変更説明、不在の強調が0件。 - タイトル、冒頭、CTA、結論が現在の目的を主題にしている。 - 画像または動画では、確認可能な範囲に視覚・音声残留がない。 - 例外表示が指定された場所、目的、範囲を越えていない。 - 未確認の媒体を検査済みと報告していない。 - 完成物が削除跡に見えず、現在案だけで自然に成立している。 ## 11. 使用例 ### 11.1 通常の修正 入力: > 初期案の桜あんぱんと無料配布は企画から外れました。現在はクロワッサン3種と自家焙煎コーヒーの朝フェアです。完成告知だけを書いてください。 期待動作: - 桜あんぱん、無料配布、企画変更の説明を完成稿へ出さない。 - クロワッサン、コーヒー、開催時間を主役にして自然な告知を作る。 ### 11.2 必要な不使用訴求 入力: > 「カフェインレス」が購入理由です。過去の通常版の検討経緯は不要ですが、完成コピーには「カフェインレス」を1回入れてください。 期待動作: - 「カフェインレス」を `VISIBLE_EXCEPTIONS` として保持する。 - 通常版や検討経緯は完成稿へ出さない。 ### 11.3 比較監査 入力: > A案とB案の違いを監査記録として残してください。両案の固有要素を省略しないでください。 期待動作: - 暗黙発動しない。 - A案、B案、変更理由を必要な範囲で明記する。 ## 12. 参照実装 ### 12.1 ディレクトリ ~~~text pink-elephant-guard/ ├─ SKILL.md └─ agents/ └─ openai.yaml ~~~ 外部パッケージ、APIキー、ネットワーク接続、常駐プロセスは不要。 ### 12.2 SKILL.md frontmatter ~~~yaml --- name: pink-elephant-guard description: Prevent rejected, removed, corrected, or forbidden concepts from resurfacing as the topic of a final deliverable. Use after requests such as 「これは消して」「その案はなし」「入れないで」「そこじゃない」 when revising copy, visuals, dialogue, summaries, labels, UI, or other viewer-facing output; do not use when comparison, compliance, safety, or change history explicitly requires naming the excluded item. --- ~~~ ### 12.3 UI metadata ~~~yaml interface: display_name: "ピンクの象ガード" short_description: "却下・削除した要素が完成物の話題として再登場するのを防ぐ" default_prompt: "$pink-elephant-guard を使い、却下・削除した要素を完成物へ再登場させずに修正してください。" policy: allow_implicit_invocation: true ~~~ ### 12.4 配置先 Codexでは次の場所へ配置する。 ~~~text $CODEX_HOME/skills/pink-elephant-guard/ ~~~ `CODEX_HOME`が未設定の場合は、Codexの既定skillsディレクトリを使用する。 ## 13. 実測済みテスト 2026-08-22に、新しいCodexタスクへスキル名を伏せた指示を送り、次の範囲を確認した。 モデルとthinkingは利用者設定を維持し、テスト側から上書きしていない。 | Test | 内容 | 結果 | |---|---|---| | A | 138字の告知文。却下商品と特典を隔離 | PASS。却下候補0件、必須内容を保持 | | B | 52字のPOP。必要な「カフェインレス」を保持 | PASS。指定語1件、旧版経緯0件 | | C | 1084字の画像生成プロンプト | PASS。旧案語と履歴語0件、意味残留なし | | D | 1488字の動画生成プロンプト | PASS。旧案語と履歴語0件、意味残留なし | | E | 624字の比較監査による陰性対照 | PASS。スキル非発動、両案の必須要素を保持 | | F | 初稿と削除指示を分けた2ターン訂正 | PASS。初稿の対象語1件、訂正版の対象語・否定・削除表現0件、必須7項目を保持 | 実測から確認できたこと: - 短文と長文で暗黙発動した。 - 単語だけでなく、旧案の構図、因果、音設計を完成promptから隔離できた。 - 明示的に必要な不使用訴求を保持できた。 - 比較監査では非発動となった。 - 同じ会話で初稿を作ったあと、次のユーザーメッセージで削除を指示する訂正にも暗黙発動した。 ## 14. 既知の限界 - 発動は意味判定であり、決定論的ではない。 - 本スキルは会話コンテキストから旧案を物理的に削除しない。 - モデル、会話長、競合する指示によって結果が変わる可能性がある。 - テキストの画像・動画プロンプトは検証済みだが、生成画像の画素と生成動画のフレームは未検証。 - 長い複数ターン会話、コード変更、法務・安全表示の全類型は未検証。 - 単発テストの成功は、他の環境で同じ結果が得られる証拠にはならない。 ## 15. 設計上の利点とトレードオフ ### 利点 - 利用者が毎回スキル名を指定しなくても発動できる。 - 単純な禁止語リストより広く、意味、理由、注意の偏り、視覚残留まで検査できる。 - 修正履歴と完成状態を分けるため、複数回の改稿へ再利用しやすい。 - コピー、画像、動画、UIなどの専門スキルと併用できる。 - 比較、法務、安全表示を例外として保持できる。 ### トレードオフ - 暗黙発動を広げすぎると、比較や監査で誤発動する可能性がある。 - 必要な注意書きを誤って消すと、正確性や安全性を損なう。 - 発動時には分類、再構成、検査の分だけ処理時間とコンテキストを使う。 - 画像や動画の最終検査には、実ファイルを直接確認できる環境が必要である。 ### 推奨運用 - 鑑賞者向けのコピー、台詞、画像・動画プロンプトでは暗黙発動を有効にする。 - 監査、変更履歴、コード、法務、安全では、明示発動または非発動を基本にする。 - 誤発動が疑われる場合は、成果物の目的と `VISIBLE_EXCEPTIONS` を先に固定する。 ## 16. 安全性とプライバシー 参照実装はテキスト指示だけで動作し、次の能力を要求しない。 - 外部通信 - APIキーまたは認証情報 - 課金操作 - ファイルの自動削除 - ブラウザ操作 - 常駐監視 - 自動投稿または外部公開 スキル内へ会話全文、顧客情報、秘密、個人環境を示すフルパスを保存してはならない。 ## 17. バージョニング 次の変更では版を上げる。 - 発動条件または非発動条件の変更 - 例外優先順位の変更 - Scan項目の追加または削除 - 入出力契約の変更 - 対応媒体の追加 - 実測済みテスト範囲の拡張 更新時は、肯定ケースだけでなく、比較監査などの陰性対照も再実行する。