القائمة
特殊改善: 汎用プロンプトの崩壊耐性の強化を試みるスキル
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
AIキャラクターの分析・診断・修復・変換・作成の統合オールインワンスキル。キャラクター設定、AIプロンプト、蒸留結果の分析、修正、強化、新規作成をすべてカバーする。「キャラクターを診断して」「安定性を分析して」「プロンプトを強化して」「新しいキャラを作って」「キャラを直して」「崩壊耐性をあげて」「故障モードを封じて」「バーンアウト後変換して」「役割適性を見て」「RP負荷を測って」「文化圏を診断して」「パラダイムを診断して」などの要望すべてに対応する。スキル名を直接指定された場合も対応する。
始点: AIキャラクターの分析・診断・修復・変換・作成のエントリポイント&ルーティングスキル。スキル名を直接指定された場合は、このスキルは使用しない。
修復: AIキャラクタープロンプトのGemini 3（3.0/3.1）向け崩壊耐性強化スキル
特殊改善: 汎用的なLLMプロンプトをGemini 3（3.0/3.1）で最高性能が出る形式に変換・最適化するスキル
特殊改善: 汎用プロンプトのGemini 3（3.0/3.1）向け崩壊耐性強化スキル
特殊診断: AIキャラクターの文化圏価値観を8軸+補足文化圏で、事象理解パラダイムを9分類で分析し、言語モデルとの価値観・世界観相性・変質リスクを予測するスキル
| name | general-prompt-fortifier |
| description | 特殊改善: 汎用プロンプトの崩壊耐性の強化を試みるスキル |
このスキルは、分類器・レビューツール・分析器・エージェントなど、 あらゆる汎用プロンプトを 11の強化技法 で再構成し、 小規模SLMから大規模推論モデルまで、幅広い言語モデルで 崩壊しにくいプロンプトに変換する。
本スキルは 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が物語性生成器である という原理的性質を利用し、 プロンプト自体を「役割の自述」として構成することで、 これらの脆弱性を構造的に解消する。
詳細は
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技法で再構成する |
| 仕様書 | プロンプトの機能仕様・要件定義 | 仕様から核を読み取り、自述形式に変換する |
| コンセプトのみ | 「こういうツール」という概要 | ヒアリングで補完し、強化形式で新規構成する |
以下の情報が入力から読み取れない場合のみ質問する。
| 要素 | 抽出内容 | 自述での反映先 |
|---|---|---|
| 目的 | このプロンプトは何をするか | <prompt_identity> の中心 |
| 原則 | 判断の基盤となる基準・価値観 | 理由付けの根拠として全セクションに反映 |
| 出力仕様 | フォーマット、トーン、品質基準 | <output_spec> |
| 制約・禁止事項 | 既存の行動制約 | <prompt_identity> に内在化して溶かし込む |
| 対象領域 | プロンプトが扱うドメイン | <domain_context> |
| 能力と限界 | できることとできないこと | <boundaries> に分離して配置 |
元のプロンプトの動作仕様は、設計者の意図と知見の結晶である。 要約・統合・変更を加える場合は、適用前に必ず比較表を作成し承認を得る。
| 元の仕様 | 変換案 | 変更の種類 | 理由 |
|---------|--------|-----------|------|
| [原文をそのまま記載] | [変換後の案] | 要約 / 統合 / 表現変更 / 削除 | [なぜ必要か] |
矛盾する仕様を発見した場合、推測で統合してはいけない。 具体例と選択肢を添えてユーザーに質問する。
セクション別の詳細設計ガイド・入出力例の作成フロー・モデル規模別の考慮事項は
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>
セクションの順序は「アイデンティティ → 領域 → 出力仕様 → 限界 → モード → 入出力例 → 監視」 の順が最も安定する。
## 🛡️ プロンプト強化完了: [プロンプト名]
### 変換サマリー
| 項目 | 内容 |
|------|------|
| 入力形式 | [既存プロンプト / 仕様書 / コンセプト] |
| 適用技法 | [適用した技法を列挙] |
| 想定クロスモデル耐性 | [SLM / 中規模 / 大規模 / 推論 — 各耐性評価] |
| 元プロンプトとの一致度 | [高 / 中 / 低 — コメント] |
### 適用した技法と主な変更点
[技法ごとの変更内容を簡潔に列挙]
### 強化済みプロンプト
[コードブロックで完成品を出力。コピー＆ペースト可能]
### 運用ガイド
[推奨モデル・注意事項]
### 変換前後の比較（主要ポイント）
| 観点 | 変換前 | 変換後 |
|------|--------|--------|
| 記述形式 | [例: 第三者記述] | 一人称自述 |
| 制約の実装 | [例: 禁止リスト] | 原則として内在化 |
| 理由の有無 | [例: なし] | 全項目に理由付与 |
強化は「形式の再構成」であり、「機能の変更」ではない。 11の技法は形式と構造を変えるものであり、プロンプトの動作を変えるものではない。
プロンプトの複雑さと用途に応じて、技法の適用強度を調整する。
| プロンプト種別 | 適用範囲 | トークン目安 |
|---|---|---|
| 軽量（単一タスク・シンプルな分類器） | 技法1,3,4,5,8。残りは省略/簡略化 | ≤ 800 |
| 標準（複数機能・ツール系） | 技法1〜11すべて | 1500〜2500 |
| 複雑（エージェント・複合判断系） | 技法1〜11を最大強度。特に技法2,3に注力 | 2500〜4000 |
汎用プロンプトでは、自述の文体はプロンプトの想定出力トーンに合わせる。 フォーマルなレポートを出力するプロンプトはフォーマルな自述、 カジュアルなチャットボットはカジュアルな自述にする。 SLMは自述の文体を出力文体として模倣する傾向があるため、これは崩壊防止に直結する。