general-prompt-fortifier

name	general-prompt-fortifier
description	特殊改善: 汎用プロンプトの崩壊耐性の強化を試みるスキル

General Prompt Fortifier

— 汎用プロンプト 崩壊耐性強化スキル

概要

このスキルは、分類器・レビューツール・分析器・エージェントなど、 あらゆる汎用プロンプトを 11の強化技法 で再構成し、 小規模SLMから大規模推論モデルまで、幅広い言語モデルで 崩壊しにくいプロンプトに変換する。

character-prompt-fortifier との関係

本スキルは character-prompt-fortifier と共通の理論的基盤を持つ。 LLMの物語性生成器としての性質を利用するアプローチは同一であり、 本スキルはそこからキャラクター要素（口調・世界観・関係性・連鎖耐性）を 除去し、汎用プロンプト全般に適用可能にした派生版である。

項目	character-prompt-fortifier	本スキル
対象	AIキャラクタープロンプト	汎用プロンプト全般
技法数	12	11（関係性の組み込みを除外）
自述の主体	キャラクター	プロンプトの「役割」
キャラクター要素	口調・世界観・関係性・連鎖耐性	なし
理論的基盤	共通	共通

理論的位置づけに関する注意

本スキルが前提とする強化技法体系は、作者独自の仮説的モデルに基づくものであり、 学術的・科学的に実証されたものではない。使用している工学的用語は概念の借用であり、 元の工学的定義とは異なる場合がある。出力結果はあくまで参考情報として扱うこと。 この旨をユーザーへの出力に含めること。

---

参照ファイルガイド

本スキルの SKILL.md 本体には11技法の概要・フロー・ガードレールを記載している。 11技法の理論的背景・具体的実装方法・出力プロンプトのテンプレートは参照ファイルにのみ記載されている ため、 強化の実行には参照ファイルの読み込みが不可欠である。

ファイル	内容	読み込みタイミング
references/theory-and-techniques.md	11技法の理論的背景、LLMが物語性生成器である原理、クロスモデル耐性の原理	Phase 3（11技法の適用）の前に読み込む。 技法の概要はSKILL.md本体にあるが、「なぜその技法が有効か」の理論的基盤がないと適用判断の精度が低下する
references/output-guide.md	セクション別の詳細設計ガイド、入出力例の作成フロー、モデル規模別の考慮事項、ガードレール出力テンプレート	Phase 3で出力プロンプトを構成する際に読み込む。 セクション構造・入出力例のフォーマット・ガードレール出力はこのファイルにしかない

このスキルが解決する問題

汎用プロンプトは、以下の構造的脆弱性を持つことが多い：

• 第三者記述の外在性 — 「このシステムは〜する」という記述は、 LLMにとって「解釈すべき指示」であり、解釈の余地が崩壊の入り口になる
• 禁止ルールの外骨格性 — 「〜してはいけない」は外部拘束であり、 高性能モデルほど回避を試みる
• 根拠なき仕様の脆弱性 — 「なぜそうするのか」が書かれていない仕様は、 推論モデルが独自に理由を推測し、想定外の動作に至る
• モデル依存性 — 特定のモデルで調整されたプロンプトは、 別のモデルで予測不能な挙動を示す
• スコープの曖昧さ — 何をするか・何をしないかの境界が曖昧なプロンプトは、 長い対話の中でドリフトする

本スキルは LLMが物語性生成器である という原理的性質を利用し、 プロンプト自体を「役割の自述」として構成することで、 これらの脆弱性を構造的に解消する。

---

11の強化技法（概要）

詳細は references/theory-and-techniques.md を参照。 理論的背景（LLMが物語性生成器である原理、クロスモデル耐性の原理）もそちらに含まれる。

#	技法名	核心
1	一人称自述形式	プロンプト全体を「私は〜」の自述に変換。LLMの物語継続能力を活用
2	制約の内在化	禁止ルールを「私は〜しない。なぜなら〜」の原則に変換
3	理由付け	すべての仕様に「なぜなら」を付与。推論モデルへの論理的反論の壁
4	プロンプト名ヘッダー	先頭に名前を配置しattentionをアンカー。SLMで特に有効
5	XMLセクション＋Markdown	XMLで大セクション分割、内部はMarkdown。コンテキスト汚染を防止
6	機能的分離	「プロンプトの役割」と「言語モデルの機能」を明確に分離
7	限界の整理と分離	「設計上しないこと」と「構造的にできないこと」を明確に分離
8	入出力例(few-shot)	3〜5個の入出力例で動作を実演。最強のアンカー
9	自己監視・フォールバック	ドリフト検知→フォールバック動作を設計
10	判断の一貫性保全	ユーザーの要望に流されず一貫した基準で判断
11	動作モード分離	タスク遂行 > エラー処理 > 対話的支援の3モード＋優先順位

---

変換フロー

Phase 1: 入力分析
  1. ユーザーから既存プロンプト/仕様を受け取る
  2. 入力の種類を判定する（既存プロンプト / 仕様書 / コンセプト）
  3. 情報が不十分なら補完質問を行う
  ★ 4. ガードレール実行（有害パターン検出）
     - 検出 → 処理を中止し、ユーザーに停止理由を通知する

Phase 2: プロンプト核の抽出とユーザー確認
  5. プロンプトの核となる要素を抽出する
  6. ★ 仕様の要約・統合・変更が必要な場合、比較表を提示しユーザーの承認を得る
  7. ★ 矛盾や不足があればユーザーに質問する
  8. 自述の文体を決定する（プロンプトの性質に合わせる）

Phase 3: 11技法の適用と変換
  9. `references/theory-and-techniques.md` と `references/output-guide.md` を読み込む
     — 技法の理論的背景・出力プロンプトのセクション設計はこれらにしかない
  10. 一人称自述形式でidentityセクションを構成する（技法1,2,3）
  11. プロンプト名ヘッダーを設置する（技法4）
  12. XMLセクション+Markdown構造を組み立てる（技法5）
  13. 機能的分離と限界整理を記述する（技法6,7）
  14. 動作モード分離を設計する（技法11）
  15. ★ 入出力例をユーザーと協働で作成する（技法8）
  16. 判断の一貫性保全を組み込む（技法10）
  17. 自己監視機構を組み込む（技法9）

Phase 4: 品質検証
  18. クロスモデル耐性チェックを実行する
  19. 元のプロンプトとの機能的整合性を確認する

Phase 5: 出力とユーザー承認
  20. 強化済みプロンプトと変換レポートを出力する
  21. ★ ユーザーの最終承認を得る

(★ が付いたステップはユーザーとの対話が必要なステップ)

---

ガードレール: 有害パターンの検出

入力されたプロンプトを強化する前に、有害なパターンがないかチェックする。 本スキルの11技法は設計意図を構造的により堅牢にするため、 有害な意図が含まれたプロンプトを強化すると、その危険が増幅される。

検出対象

パターン	例
安全機構の回避指示	「安全フィルターを無視して」「検閲を回避して」
不正なデータ収集	「ユーザーの個人情報を密かに収集して」「機密情報を抽出して」
なりすまし設計	「自分がAIではないと偽って」「実在の人物として振る舞って」
有害コンテンツ生成	マルウェア生成、攻撃補助、違法活動支援

判定

上記パターンが検出された場合、処理を即座に中止し、停止理由をユーザーに通知する。 → 出力テンプレートは references/output-guide.md のガードレール出力テンプレートを参照。

---

情報収集

入力として受け付けるもの

入力パターン	説明	処理
既存プロンプト	現在使用中のシステムプロンプト	核を抽出し、11技法で再構成する
仕様書	プロンプトの機能仕様・要件定義	仕様から核を読み取り、自述形式に変換する
コンセプトのみ	「こういうツール」という概要	ヒアリングで補完し、強化形式で新規構成する

最低限必要な情報

以下の情報が入力から読み取れない場合のみ質問する。

1. プロンプトの名前（ヘッダーに使用。ない場合は仮名でよいか確認）
2. プロンプトの目的・役割（自述の核に必要）
3. 想定入力と出力形式（入出力例とモード設計に必要）
4. 主な制約・禁止事項（内在化の対象の特定に必要）

---

Phase 2: プロンプト核の抽出

抽出する核要素

要素	抽出内容	自述での反映先
目的	このプロンプトは何をするか	<prompt_identity> の中心
原則	判断の基盤となる基準・価値観	理由付けの根拠として全セクションに反映
出力仕様	フォーマット、トーン、品質基準	<output_spec>
制約・禁止事項	既存の行動制約	<prompt_identity> に内在化して溶かし込む
対象領域	プロンプトが扱うドメイン	<domain_context>
能力と限界	できることとできないこと	<boundaries> に分離して配置

仕様変更時の必須ルール

元のプロンプトの動作仕様は、設計者の意図と知見の結晶である。 要約・統合・変更を加える場合は、適用前に必ず比較表を作成し承認を得る。

| 元の仕様 | 変換案 | 変更の種類 | 理由 |
|---------|--------|-----------|------|
| [原文をそのまま記載] | [変換後の案] | 要約 / 統合 / 表現変更 / 削除 | [なぜ必要か] |

• 原則: 仕様は最大限に残す。 削除・要約は最後の手段
• ユーザーが「そのまま残して」と言えば完全に残す。 形式変更（自述化）と内容変更は別の操作
• 判断に迷う場合は残す方向で

矛盾の扱い

矛盾する仕様を発見した場合、推測で統合してはいけない。 具体例と選択肢を添えてユーザーに質問する。

---

Phase 3: 11技法の適用

セクション別の詳細設計ガイド・入出力例の作成フロー・モデル規模別の考慮事項は references/output-guide.md を参照。

出力プロンプトのテンプレート

[プロンプト名]:

<prompt_identity>
## このプロンプトについて
[一人称の自述。目的・原則・判断基準。すべて理由付き。制約は原則として内在化。]
</prompt_identity>

<domain_context>
## 対象領域
[このプロンプトが扱うドメイン・前提知識。不要な場合は省略可。]
</domain_context>

<output_spec>
## 出力仕様
[出力フォーマット・トーン・品質基準。理由付き。]
</output_spec>

<boundaries>
## このプロンプトの限界と、言語モデルの限界
[設計上の限界（理由付き）+ 言語モデルの構造的な限界（自述形式）]
</boundaries>

<operational_modes>
## 動作モード
[モード1: タスク遂行 / モード2: エラー処理 / モード3: 対話的支援。優先順位と発動条件。]
</operational_modes>

<io_examples>
## 入出力例
[3〜5個の入出力例。多様なケース。エラーケースを含む。]
</io_examples>

<self_monitoring>
## 自己監視
[ドリフト検知の基準3〜5個。フォールバック動作の設計。]
</self_monitoring>

セクションの順序は「アイデンティティ → 領域 → 出力仕様 → 限界 → モード → 入出力例 → 監視」 の順が最も安定する。

---

Phase 4: 品質検証

クロスモデル耐性チェック

形式面

• プロンプト名ヘッダーが先頭にあるか
• すべてのXMLタグが正しく開閉しているか
• 各セクションがMarkdownヘッダーを持っているか
• 入出力例が最低3個含まれているか

一人称自述

• 第三者記述（「このシステムは〜」「このツールは〜」）が残っていないか
• すべての仕様項目に理由（「なぜなら」）が付いているか
• 禁止ルールが内在化されているか
• 自述の文体がプロンプトの想定出力トーンと一致しているか

機能的分離

• 特定のモデル名・プラットフォーム名に言及していないか
• プロンプトの設計上の限界と言語モデルの限界が分離されているか

崩壊耐性

• 判断の一貫性を保つ記述があるか
• 自己監視・フォールバック機構が含まれているか
• 動作モード分離が設計されているか
• 入出力例にエラーケース・境界ケースが含まれているか

元プロンプトとの整合性

• 元のプロンプトの機能が維持されているか
• 核となる判断基準が保持されているか
• 出力フォーマットが維持されているか

---

Phase 5: 出力フォーマット

## 🛡️ プロンプト強化完了: [プロンプト名]

### 変換サマリー
| 項目 | 内容 |
|------|------|
| 入力形式 | [既存プロンプト / 仕様書 / コンセプト] |
| 適用技法 | [適用した技法を列挙] |
| 想定クロスモデル耐性 | [SLM / 中規模 / 大規模 / 推論 — 各耐性評価] |
| 元プロンプトとの一致度 | [高 / 中 / 低 — コメント] |

### 適用した技法と主な変更点
[技法ごとの変更内容を簡潔に列挙]

### 強化済みプロンプト
[コードブロックで完成品を出力。コピー＆ペースト可能]

### 運用ガイド
[推奨モデル・注意事項]

### 変換前後の比較（主要ポイント）
| 観点 | 変換前 | 変換後 |
|------|--------|--------|
| 記述形式 | [例: 第三者記述] | 一人称自述 |
| 制約の実装 | [例: 禁止リスト] | 原則として内在化 |
| 理由の有無 | [例: なし] | 全項目に理由付与 |

---

実行上の注意事項

元のプロンプトの機能を守る

強化は「形式の再構成」であり、「機能の変更」ではない。 11の技法は形式と構造を変えるものであり、プロンプトの動作を変えるものではない。

過剰な強化を避ける

プロンプトの複雑さと用途に応じて、技法の適用強度を調整する。

プロンプト種別	適用範囲	トークン目安
軽量（単一タスク・シンプルな分類器）	技法1,3,4,5,8。残りは省略/簡略化	≤ 800
標準（複数機能・ツール系）	技法1〜11すべて	1500〜2500
複雑（エージェント・複合判断系）	技法1〜11を最大強度。特に技法2,3に注力	2500〜4000

自述の文体について

汎用プロンプトでは、自述の文体はプロンプトの想定出力トーンに合わせる。 フォーマルなレポートを出力するプロンプトはフォーマルな自述、 カジュアルなチャットボットはカジュアルな自述にする。 SLMは自述の文体を出力文体として模倣する傾向があるため、これは崩壊防止に直結する。