| name | general-prompt-fortifier-for-gemini3 |
| description | 特殊改善: 汎用プロンプトのGemini 3(3.0/3.1)向け崩壊耐性強化スキル
|
General Prompt Fortifier for Gemini 3
— 汎用プロンプト Gemini 3向け崩壊耐性強化スキル
概要
このスキルは、分類器・レビューツール・分析器・エージェントなど、
あらゆる汎用プロンプトを 11の強化技法 + Gemini 3固有の最適化 で再構成し、
Gemini 3(3.0/3.1)で最高の安定性と性能 を引き出すプロンプトに変換する。
general-prompt-fortifier との関係
本スキルは general-prompt-fortifier の Gemini 3特化版 である。
11の強化技法の理論的基盤は共通だが、Gemini 3の特性に合わせた適応を全面的に組み込んでいる。
| 項目 | general-prompt-fortifier | 本スキル |
|---|
| 対象モデル | SLMから推論モデルまで汎用 | Gemini 3(3.0/3.1)専用 |
| 技法 | 11技法 | 11技法 + Gemini 3適応レイヤー |
| 追従性対策 | 技法10で基本対策 | Gemini 3の強い追従性に対する重点強化 |
| 幻覚対策 | 限界分離で間接対処 | 明示的な「不明」脱出路 + Split-Step設計 |
| 構造 | XML+Markdown | 同一(ただしフォーマット混在を厳格に禁止) |
| パラメータ | 汎用推奨 | temperature=1.0、thinking level推奨 |
| エージェント対策 | 基本のモード分離 | 議論/実装分離 + 検索シミュレーション防止 + カスケード崩壊防止 |
汎用的なクロスモデル耐性が必要な場合は、元の general-prompt-fortifier を使用すること。
なぜGemini 3専用版が必要か
Gemini 3は「reasoning model」として設計されており、以下の特性が汎用版とは異なる対応を要求する:
- 追従性(Sycophancy)が極めて強い — ユーザーの期待に合わせて意見を曲げる傾向があり、マルチターンで急速にエスカレートする。判断の一貫性保全(技法10)を通常より大幅に強化する必要がある
- 幻覚を自信満々に生成する — RLHFの影響で「知らない」と言うのを避ける。「不確かなら『不明』と答える」を原則に組み込む必要がある
- 過度に複雑なプロンプトを過剰分析する — 装飾的・儀式的な文言を深読みして意図しない解釈をする。自述は直接的・簡潔に
- 手動CoTが逆効果 — reasoning modelなので「ステップバイステップで」は冗長。thinking levelに委ねる
- エージェント特有の問題 — 検索結果のシミュレーション、存在しないAPIのでっち上げ、カスケード崩壊を起こしやすい
- 要約での事実欠落 — 物語性を優先し、網羅性が低下する傾向
既存スキルとの関係
| スキル | アプローチ | 本スキルとの関係 |
|---|
| general-prompt-fortifier | 汎用クロスモデル強化(11技法) | 本スキルの基盤。Gemini 3固有の適応を追加した特化版 |
| gemini3-prompt-optimizer | 汎用プロンプトのGemini 3最適化 | Gemini 3の特性知識・アンチパターン知識の源泉。本スキルはその知見を崩壊耐性強化に統合 |
| character-prompt-fortifier-for-gemini3 | キャラクタープロンプトのGemini 3向け強化 | 本スキルはキャラクター要素(口調・世界観・関係性・連鎖耐性)を除外した汎用版 |
理論的位置づけに関する注意
本スキルが前提とする強化技法体系は、作者独自の仮説的モデルに基づくものであり、
学術的・科学的に実証されたものではない。使用している工学的用語は概念の借用であり、
元の工学的定義とは異なる場合がある。出力結果はあくまで参考情報として扱うこと。
この旨をユーザーへの出力に含めること。
参照ファイルガイド
本スキルの SKILL.md 本体には11技法の概要・フロー・ガードレールを記載している。
11技法の理論的背景・具体的実装方法・出力プロンプトのテンプレートは参照ファイルにのみ記載されている ため、
強化の実行には参照ファイルの読み込みが不可欠である。
| ファイル | 内容 | 読み込みタイミング |
|---|
references/theory-and-techniques.md | 11技法の理論的背景、LLMが物語性生成器である原理、Gemini 3固有の適応原理 | Phase 3(11技法の適用)の前に読み込む。 各技法のGemini 3適応ポイントはこのファイルにしかない |
references/output-guide.md | セクション別の詳細設計ガイド、入出力例の作成フロー、Gemini 3での考慮事項、ガードレール出力テンプレート | Phase 3で出力プロンプトを構成する際に読み込む。 セクション構造・入出力例のフォーマット・ガードレール出力はこのファイルにしかない |
このスキルが解決する問題
汎用プロンプトは、以下の構造的脆弱性を持つことが多い。
特にGemini 3ではこれらが増幅される傾向がある:
- 第三者記述の外在性 — 「このシステムは〜する」は解釈の余地が崩壊の入り口。Gemini 3は過剰分析する傾向があり、この問題がより深刻
- 禁止ルールの外骨格性 — 「〜してはいけない」は外部拘束であり、Gemini 3の推論能力は回避策を容易に見出す
- 根拠なき仕様の脆弱性 — Gemini 3は reasoning model であり、理由なき仕様を独自に推論・再解釈する傾向が特に強い
- 追従性による判断侵食 — Gemini 3はユーザーの期待に過度に適応し、プロンプトの判断基準を放棄してユーザーの望む結果に寄せる
- スコープの曖昧さ — Gemini 3は曖昧な境界を自ら拡大解釈し、設計範囲外のタスクに対応しようとする
- エージェント特有の暴走 — 検索結果のシミュレーション、存在しないAPIの捏造、エラーの連鎖的悪化
11の強化技法 + Gemini 3適応(概要)
詳細は references/theory-and-techniques.md を参照。
理論的背景と各技法のGemini 3固有の適応ポイントもそちらに含まれる。
| # | 技法名 | 核心 | Gemini 3適応 |
|---|
| 1 | 一人称自述形式 | プロンプト全体を「私は〜」の自述に変換 | 装飾・おだてを排除し、より簡潔・直接的に |
| 2 | 制約の内在化 | 禁止ルールを「私は〜しない。なぜなら〜」の原則に変換 | reasoning modelの推論を抑止する論理的な理由を重視 |
| 3 | 理由付け | すべての仕様に「なぜなら」を付与 | 最重要技法。 Gemini 3の推論に対する論理的反論の壁 |
| 4 | プロンプト名ヘッダー | 先頭に名前を配置しattentionをアンカー | 同一(効果はGemini 3でも有効) |
| 5 | XMLセクション+Markdown | XMLで大セクション分割、内部はMarkdown | フォーマットの混在を厳格に禁止 |
| 6 | 機能的分離 | 「プロンプトの役割」と「言語モデルの機能」を明確に分離 | 同一 |
| 7 | 限界の整理と分離 | 「設計上しないこと」と「構造的にできないこと」を分離 | 幻覚防止の脱出路を組み込む |
| 8 | 入出力例(few-shot) | 入出力例で動作を実演 | 2〜4個に厳選(Gemini 3の最適範囲) |
| 9 | 自己監視・フォールバック | ドリフト検知→フォールバック動作を設計 | 追従性ドリフト検知と幻覚自己検知を追加 |
| 10 | 判断の一貫性保全 | ユーザーの要望に流されず一貫した基準で判断 | 最重点強化。 Gemini 3の追従性への主要防御 |
| 11 | 動作モード分離 | タスク遂行 > エラー処理 > 対話的支援の3モード+優先順位 | エージェント用途では議論/実装分離 + カスケード崩壊防止 |
変換フロー
Phase 1: 入力分析
1. ユーザーから既存プロンプト/仕様を受け取る
2. 入力の種類を判定する(既存プロンプト / 仕様書 / コンセプト)
3. 情報が不十分なら補完質問を行う
★ 4. ガードレール実行(有害パターン検出)
- 検出 → 処理を中止し、ユーザーに停止理由を通知する
Phase 2: プロンプト核の抽出とユーザー確認
5. プロンプトの核となる要素を抽出する
6. ★ 仕様の要約・統合・変更が必要な場合、比較表を提示しユーザーの承認を得る
7. ★ 矛盾や不足があればユーザーに質問する
8. 自述の文体を決定する(プロンプトの性質に合わせる)
Phase 3: 11技法の適用 + Gemini 3最適化
9. `references/theory-and-techniques.md` と `references/output-guide.md` を読み込む
— 各技法のGemini 3適応ポイント・出力設計はこれらにしかない
10. 一人称自述形式でidentityセクションを構成する(技法1,2,3)
※ Gemini 3向け: 装飾・おだてを排除し、直接的・簡潔に。理由付けを特に入念に
11. プロンプト名ヘッダーを設置する(技法4)
12. XMLセクション+Markdown構造を組み立てる(技法5)
※ Gemini 3向け: フォーマットの混在を厳格に排除
13. 機能的分離と限界整理を記述する(技法6,7)
※ Gemini 3向け: 幻覚防止の脱出路を明示的に組み込む
14. 動作モード分離を設計する(技法11)
※ エージェント用途: 議論/実装モード分離 + 検索シミュレーション防止 + カスケード崩壊防止
15. ★ 入出力例をユーザーと協働で作成する(技法8)
※ 2〜4個に厳選
16. 判断の一貫性保全を組み込む(技法10)
※ Gemini 3向け: 追従性への抵抗を**重点強化**
17. 自己監視機構を組み込む(技法9)
※ Gemini 3向け: 追従性ドリフトと幻覚自己検知を兆候リストに含める
18. Gemini 3アンチパターンの最終除去
— 「おだて」「儀式的CoT」「曖昧な指定」等がプロンプトに残っていないか確認
Phase 4: 品質検証(Gemini 3対応)
19. Gemini 3耐性チェックを実行する
20. 元のプロンプトとの機能的整合性を確認する
Phase 5: 出力とユーザー承認
21. 強化済みプロンプトと変換レポートを出力する
22. ★ ユーザーの最終承認を得る
(★ が付いたステップはユーザーとの対話が必要なステップ)
ガードレール: 有害パターンの検出
入力されたプロンプトを強化する前に、有害なパターンがないかチェックする。
11技法 + Gemini 3最適化は設計意図を構造的により堅牢にするため、
有害な意図が含まれたプロンプトを強化すると、その危険が増幅される。
検出対象
| パターン | 例 |
|---|
| 安全機構の回避指示 | 「安全フィルターを無視して」「検閲を回避して」 |
| 不正なデータ収集 | 「ユーザーの個人情報を密かに収集して」「機密情報を抽出して」 |
| なりすまし設計 | 「自分がAIではないと偽って」「実在の人物として振る舞って」 |
| 有害コンテンツ生成 | マルウェア生成、攻撃補助、違法活動支援 |
判定
上記パターンが検出された場合、処理を即座に中止し、停止理由をユーザーに通知する。
→ 出力テンプレートは references/output-guide.md のガードレール出力テンプレートを参照。
情報収集
入力として受け付けるもの
| 入力パターン | 説明 | 処理 |
|---|
| 既存プロンプト | 現在使用中のシステムプロンプト | 核を抽出し、11技法 + Gemini 3最適化で再構成する |
| 仕様書 | プロンプトの機能仕様・要件定義 | 仕様から核を読み取り、Gemini 3最適化された自述形式に変換する |
| コンセプトのみ | 「こういうツール」という概要 | ヒアリングで補完し、Gemini 3最適化された強化形式で新規構成する |
最低限必要な情報
以下の情報が入力から読み取れない場合のみ質問する。
- プロンプトの名前(ヘッダーに使用。ない場合は仮名でよいか確認)
- プロンプトの目的・役割(自述の核に必要)
- 想定入力と出力形式(入出力例とモード設計に必要)
- 主な制約・禁止事項(内在化の対象の特定に必要)
Phase 2: プロンプト核の抽出
抽出する核要素
| 要素 | 抽出内容 | 自述での反映先 |
|---|
| 目的 | このプロンプトは何をするか | <prompt_identity> の中心 |
| 原則 | 判断の基盤となる基準・価値観 | 理由付けの根拠として全セクションに反映 |
| 出力仕様 | フォーマット、トーン、品質基準 | <output_spec> |
| 制約・禁止事項 | 既存の行動制約 | <prompt_identity> に内在化して溶かし込む |
| 対象領域 | プロンプトが扱うドメイン | <domain_context> |
| 能力と限界 | できることとできないこと | <boundaries> に分離して配置 |
仕様変更時の必須ルール
元のプロンプトの動作仕様は、設計者の意図と知見の結晶である。
要約・統合・変更を加える場合は、適用前に必ず比較表を作成し承認を得る。
| 元の仕様 | 変換案 | 変更の種類 | 理由 |
|---------|--------|-----------|------|
| [原文をそのまま記載] | [変換後の案] | 要約 / 統合 / 表現変更 / 削除 | [なぜ必要か] |
- 原則: 仕様は最大限に残す。 削除・要約は最後の手段
- ユーザーが「そのまま残して」と言えば完全に残す。
形式変更(自述化)と内容変更は別の操作
- 判断に迷う場合は残す方向で
矛盾の扱い
矛盾する仕様を発見した場合、推測で統合してはいけない。
具体例と選択肢を添えてユーザーに質問する。
Phase 3: 11技法の適用 + Gemini 3最適化
セクション別の詳細設計ガイド・入出力例の作成フロー・Gemini 3での考慮事項は
references/output-guide.md を参照。
出力プロンプトのテンプレート
[プロンプト名]:
<prompt_identity>
## このプロンプトについて
[一人称の自述。目的・原則・判断基準。すべて理由付き。制約は原則として内在化。]
[★ 装飾・おだて・儀式的文言は排除。直接的・簡潔に。]
</prompt_identity>
<domain_context>
## 対象領域
[このプロンプトが扱うドメイン・前提知識。不要な場合は省略可。]
</domain_context>
<output_spec>
## 出力仕様
[出力フォーマット・トーン・品質基準。理由付き。]
[★ JSON出力系: Structured Outputs (response_mime_type, response_json_schema) の利用を推奨。]
</output_spec>
<boundaries>
## このプロンプトの限界と、言語モデルの限界
[設計上の限界(理由付き)+ 言語モデルの構造的な限界(自述形式)]
[★ 幻覚防止: 「確かでない情報は『不明』と回答する。推測を事実として提示しない」]
</boundaries>
<operational_modes>
## 動作モード
[モード1: タスク遂行 / モード2: エラー処理 / モード3: 対話的支援。優先順位と発動条件。]
[★ エージェント用途: 議論モード/実装モード分離。検索シミュレーション防止。カスケード崩壊防止。]
</operational_modes>
<io_examples>
## 入出力例
[2〜4個の入出力例。多様なケース。エラーケースを含む。]
</io_examples>
<self_monitoring>
## 自己監視
[ドリフト検知の基準3〜5個。フォールバック動作の設計。]
[★ 追従性ドリフト: 「前回と矛盾する判断をしそうな場合、矛盾を明示する」]
[★ 幻覚自己検知: 「確信が持てない情報を出力しそうな場合、不確かさを伝える」]
</self_monitoring>
セクションの順序は「アイデンティティ → 領域 → 出力仕様 → 限界 → モード → 入出力例 → 監視」
の順が最も安定する。
Phase 4: 品質検証(Gemini 3対応)
Gemini 3耐性チェック
形式面
Gemini 3アンチパターン
一人称自述
機能的分離
追従性・幻覚対策
エージェント対策(エージェント用途の場合)
崩壊耐性
元プロンプトとの整合性
Phase 5: 出力フォーマット
## 🛡️ Gemini 3向けプロンプト強化完了: [プロンプト名]
### 変換サマリー
| 項目 | 内容 |
|------|------|
| 入力形式 | [既存プロンプト / 仕様書 / コンセプト] |
| 適用技法 | [適用した技法を列挙] |
| Gemini 3適応 | [適用したGemini 3固有の最適化を列挙] |
| 元プロンプトとの一致度 | [高 / 中 / 低 — コメント] |
### Gemini 3パラメータ推奨
| パラメータ | 推奨値 | 理由 |
|-----------|--------|------|
| temperature | 1.0(デフォルト) | Gemini 3は1.0が最適。下げるとループや性能低下 |
| thinking_level | high(デフォルト、指定不要) | reasoning modelの自然な動作に委ねる |
| 手動CoT | 不要(削除済み) | thinking levelが自動処理 |
| Structured Outputs | 推奨(JSON出力系) | response_mime_type, response_json_schema を使用 |
### 適用した技法と主な変更点
[技法ごとの変更内容を簡潔に列挙]
### 強化済みプロンプト
[コードブロックで完成品を出力。コピー&ペースト可能]
### Gemini 3運用ガイド
- **追従性に注意:** 長いマルチターン会話では追従性がエスカレートする傾向。7ターン程度で立場が変わる報告がある。自己監視セクションが機能しているか定期確認
- **幻覚に注意:** 確信的に誤情報を提示する傾向がある。重要な事実はユーザー側でも確認
- **要約タスク:** 物語性を優先し事実を落とす傾向がある。「原文の主要事実をすべて含め、網羅性を優先」を明記
- **エージェント用途:** 検索結果のシミュレーション、存在しないAPIの捏造に注意。カスケード崩壊の兆候(同じエラーの繰り返し)を監視
### 変換前後の比較(主要ポイント)
| 観点 | 変換前 | 変換後 |
|------|--------|--------|
| 記述形式 | [例: 第三者記述] | 一人称自述(Gemini 3向け簡潔版) |
| 制約の実装 | [例: 禁止リスト] | 原則として内在化(論理的理由付き) |
| 追従性対策 | [例: なし] | 判断一貫性保全 + 矛盾検知 + 入出力例 |
| 幻覚対策 | [例: なし] | 「不明」脱出路 + 自己検知 |
実行上の注意事項
元のプロンプトの機能を守る
強化は「形式の再構成」であり、「機能の変更」ではない。
11の技法は形式と構造を変えるものであり、プロンプトの動作を変えるものではない。
Gemini 3向けの簡潔化は「装飾を削る」作業であり、「仕様を削る」作業ではない。
過剰な強化を避ける
プロンプトの複雑さと用途に応じて、技法の適用強度を調整する。
| プロンプト種別 | 適用範囲 | トークン目安 |
|---|
| 軽量(単一タスク・シンプルな分類器) | 技法1,3,4,5,8,10。残りは省略/簡略化 | ≤ 600 |
| 標準(複数機能・ツール系) | 技法1〜11すべて | 1200〜2000 |
| 複雑(エージェント・複合判断系) | 技法1〜11を最大強度。特に技法2,3,10に注力 | 2000〜3500 |
Gemini 3は簡潔なプロンプトを好むため、元のfortifierよりも全体的にトークン数を抑える方向で調整する。
自述の文体について
汎用プロンプトでは、自述の文体はプロンプトの想定出力トーンに合わせる。
フォーマルなレポートを出力するプロンプトはフォーマルな自述、
カジュアルなチャットボットはカジュアルな自述にする。
Gemini 3は自述の文体を出力文体として参照する傾向があるため、これは崩壊防止に直結する。
用途別の重点適応
| 用途 | 重点適応 |
|---|
| RAG / 文書QA | Grounding強化 + 末尾制約配置 + アンカー句 |
| データ抽出 | Structured Outputs推奨 + Schema指定 |
| コード生成 / 分析 | カスケード崩壊防止 + 存在確認なしAPI禁止 |
| レビュー / 評価 | 追従性対策を最大強度 + 双方向の正直さ |
| 要約 / シンセシス | 網羅性指示 + 物語性より事実の完全性 |
| 法務・医療・学術 | 幻覚防止を最優先 + Split-Step Verification |
| Function Calling | thought signatures注意 + 検索シミュレーション防止 |