補助術式：運用編（黒閃・領域展開・帳・死滅回游・反転術式・呪骸）

この章は「6原理」を読んだ後に、実戦で安定して当てるための運用ノウハウ集です。

以降は比喩として呪術用語を使いますが、狙いはあくまで 実務の再現性・安全性・評価可能性です。

1. 「帳」：安全なVibe Coding／ツール操作の隔離環境

比喩

帳は「外から見えなくする」「影響範囲を区切る」ための結界。

実務に落とす

LLMにツール操作やコード生成をさせるときは、 環境（権限・範囲・ログ）を分離して事故半径を小さくします。

コピペ（安全ガードレール・プロンプト）

あなたは安全監査担当です。私はLLMを使ってツール操作（例：ファイル編集、コマンド実行、API呼び出し）を行います。
以下の条件で「安全設計」を点検してください。

【開示】
・作業目的：<<<>>>
・実行環境：<<<例：ローカル / コンテナ / 共有サーバ>>>
・触る対象：<<<例：特定フォルダのみ / 特定リポジトリ>>>
・権限：<<<例：読み取りのみ / 書き込み可 / 管理者権限なし>>>

【縛り】
・危険がある場合は、代替案（より安全な手順）を必ず提示
・不明点は推測しない。確認質問を最大5つ

【出力】
1) リスク（重大度A/B/C）
2) 予防策（環境・権限・手順・ログ）
3) 実行前チェックリスト（最大10項目）

チェックリスト

具体的なチェックリストは safety/veil-checklist.md にも置いています。

2. 「死滅回游」：ベンチマークで“強さ”を測る

比喩

死滅回游は「ルールがあり、得点があり、条件を揃えて競う」ゲーム的構造。

実務に落とす

LLMは“雰囲気の良さ”で評価すると、改善が止まります。 タスク・ルール・採点を固定し、比較可能にします。

コピペ（軽量ベンチマーク設計）

あなたは評価設計者です。以下の目的に対して、LLMのベンチマーク（比較テスト）を設計してください。

【目的】
<<<例：要約品質を上げたい／企画の提案力を比較したい>>>

【制約】
・テストケースは3〜7個
・採点は5段階で、観点は最大5つ
・主観が入りすぎないよう、観点ごとに「良い例／悪い例の定義」を短く添える

【出力】
1) テストケース一覧（入力の概要）
2) 出力フォーマット
3) 採点ルーブリック（表）
4) 運用手順（誰がいつ採点し、どう記録するか）

実体は benchmarks/ に雛形を用意しています（タスク3種＋採点表）。

3. 「反転術式」：理想出力から逆算してプロンプトを作る

比喩

反転術式は“治す”ための高等な操作。ここでは、 理想（正）から逆算して、入力（負）を整える発想として使います。

実務に落とす

最短で強くなる方法は「先に理想の出力仕様を定義する」こと。

1) 理想出力の仕様（評価基準）を作る 2) 仕様を満たすための入力条件・手順・禁止事項を逆算 3) 生成→評価→修正のループを回す

コピペ（逆算テンプレ）

あなたはプロンプト設計者です。
私は「理想の出力仕様」から逆算して、最適なプロンプトを作りたいです。

【理想の出力仕様】
・用途：<<<>>>
・読み手：<<<>>>
・形式：<<<例：見出し＋箇条書き／表／JSON>>>
・必須要素：<<<箇条書きで>>>
・禁止：<<<例：推測の断定／誇大表現>>>
・評価基準：<<<例：正確さ、簡潔さ、網羅性>>>

【素材（入力）】
<<<ここに元情報>>>

【出力】
1) 仕様を満たすために不足している情報（質問）
2) 完成プロンプト（コピペ可）
3) そのプロンプトの意図（スコープ／縛り／開示／フル詠唱の観点で短く）

プレーン版は prompts/reversal-design.txt。

4. 「呪骸」：自動で動くエージェント（ただし“帳”と“縛り”が必須）

比喩

呪骸は「自立して動くもの」。 便利だが、動けば動くほど コストとリスクも増えます。

実務に落とす

エージェント（自動化）は、入門者が最も事故りやすい領域です。 採用するなら最低限、次を守ります。

コピペ（エージェント用・ガードレール）

あなたは自動化エージェントの設計監査担当です。
以下の「自動化案」を、事故が起きない設計に直してください。

【自動化案】
<<<やりたいこと>>>

【環境（帳）】
・実行環境：<<<>>>
・触る範囲：<<<>>>
・権限：<<<>>>

【縛り】
・実行は必ず「提案→差分→承認→実行→ログ」の順
・不明点は推測で進めない

【出力】
1) 危険ポイント（重大度つき）
2) 安全なワークフロー（手順）
3) 承認ゲートで確認すべき項目（チェックリスト）

詳細ガードレールは safety/agent-guardrails.md。

5. 「黒閃」：ドはまり出力を“再現性”に変える

比喩

黒閃は「たまたま完璧に噛み合った一撃」。 再現が難しいからこそ、出た瞬間に“学習”へ変換する価値があります。

実務に落とす

「当たり」を出したら、次にやることは一つです。 条件をログ化し、固定し、再現できる形にする。

コピペ（黒閃ログ：プロンプト・カード化）

あなたはプロンプトの実験記録係です。
以下の「当たり出力」を再現できるよう、実験ログ（プロンプト・カード）を作ってください。

【当たり出力】
<<<ここに貼る>>>

【元の入力】
<<<入力素材（テキスト、要件など）>>>

【使ったプロンプト（もしあれば）】
<<<ここに貼る。なければ「なし」>>>

【出力】
- 目的（1行）
- 使った条件（モデル／温度等／制約）
- 有効だった指示（箇条書き）
- 次回の再現用プロンプト（コピペ可）
- 改善の余地（1〜3個）

プレーン版は prompts/black-flash-log.txt。

6. 「領域展開」：上位モデルだけでなく“土俵”ごと強化する

比喩

領域展開は、ただ出力が上がるだけではなく、 当たりやすい土俵を作り、外さないための到達点。

実務に落とす（3層）

1) モデル（呪力量）：上位モデル、適材適所の選定 2) 環境（結界）：RAG、ツール、ワークフロー、メモリ 3) 必中化（術式付与）：フォーマット・評価基準・禁止事項で“当てる”

「上位モデルを使えば解決」ではなく、 モデル×環境×縛りの組み合わせで到達します。

コピペ（領域展開：構成プロンプト）

あなたはLLM活用のアーキテクトです。
以下の目的を達成するために、「モデル選定」「環境設計」「必中化（制約）」をセットで提案してください。

【目的】
<<<例：社内FAQ対応を安定させる／教材作成を高速化する>>>

【現状】
・入力素材：<<<例：社内ドキュメント、規程、FAQ>>>
・頻出の失敗：<<<例：根拠不明の断定、形式のブレ>>>

【制約】
・個人情報や機密は外部に出せない
・運用は小さく始めたい（最小構成→拡張）

【出力】
1) 推奨モデル運用（なぜそのモデルか）
2) 環境（RAG/ツール/フロー）の最小構成
3) プロンプトの縛り（形式・評価基準・禁止事項）
4) 検証計画（ベンチマークの作り方）

7. 「呪術師／呪詛師」：強い術式ほど“線引き”が重要

比喩

人を助けるために術を磨くのか、災いをなすために使うのか。 同じ強さでも、使い方で結果は真逆になります。

実務に落とす（安全・倫理）

本プロジェクトは、学習・業務改善・創作支援のための利用を意図しています。 有害行為や違法行為を助長する用途は扱いません。

補遺：呪具＝ツール、残穢＝ログ

「強さ」は、プロンプトの文言だけではなく、 道具と記録で“運用として成立”します。