llm-feature-design

name	llm-feature-design
description	アプリに組み込む LLM 機能 (チャット・要約・分類・RAG など) のシステムプロンプトと周辺構造を、AI ベンダー公式・OWASP・査読論文で裏付けたベストプラクティスに沿って設計する。回答範囲の制限、非信頼テキストの扱いとプロンプトインジェクション対策、ハルシネーション抑制、ガードレールの多層化、評価セットの作り方を references/ から参照する。「LLM 機能を実装したい」「システムプロンプトを設計して」「AI が関係ない質問に答えてしまう」「プロンプトインジェクション対策」「AI の回答範囲を絞りたい」「RAG の回答を文書に基づかせたい」などで起動。Claude Code 自身への作業依頼プロンプトの整形は対象外 (prompt-refine を使う)。
argument-hint	[設計対象の LLM 機能の説明]

llm-feature-design — LLM 機能のプロンプトと周辺構造の設計

アプリケーションに組み込む LLM 機能を、一次情報で裏付けの取れた作法に沿って設計する。references/ は OpenAI・Anthropic・Google の公式ドキュメント、OWASP LLM01、NIST AI 600-1、NVIDIA NeMo / Guardrails AI などの OSS 実装、XSTest (NAACL 2024 採択) を 2026-07-26 時点で調査した結果に基づく。

このスキルは references/ を全部読ませるためのものではない。 設計対象に関係する規範だけを選んで読み、それ以外は読まない。

[1/5] 設計対象と脅威モデルの判定

まず対象を 1〜2 文で言語化する (何を入力に、何を出力する機能か)。$ARGUMENTS があればそれを、なければ会話の文脈から取る。

そのうえで脅威モデルを判定する。これが最初に来るのは、何から守りたいかによって正解が変わるため。ここを取り違えると、過剰投資 (雑談防止のために分類器を積む) か過小防御 (不特定多数に開いた機能をプロンプトだけで守る) のどちらかになる。

判定	該当する状況	結論
通常の挙動制御	認証済みユーザ / 被害の上限が「不適切な回答が 1 件出る」程度 / ツール実行権限なし	システムプロンプトが第一選択。 適切に書かれたシステム指示は多くの場面で安全フィルタより効果的、と Google が自社テスト結果として述べている
意図的な攻撃を想定	未認証・不特定多数に開いている / ツールやデータへの書き込み権限がある / 情報漏洩の経路になる	プロンプト単独では不十分。 言い換え 1 回でシステムプロンプトの制限が破れる実例を、NVIDIA が自社 OSS のドキュメントに掲載している。ガードレールを積む

判定の優先規則: 下の行の条件は 1 つでも該当すれば下の行と判定する。上の行はすべて満たす場合にのみ選ぶ。認証済みユーザ向けでも情報漏洩の経路になる (社内文書の RAG 検索など)、あるいはツール実行権限を持つなら、下の行として扱う。

この 2 つは矛盾しない。Google 自身が system instructions =「モデルの挙動を直接導く」/ safety filters =「動機を持った攻撃 (motivated attack) への障壁」と役割を切り分けている。→ 根拠: references/evidence.md の E1-1、E1-2

判定結果と、そう判断した理由を出力に明示する。ユーザが認識と違えば指摘できる状態にする。

[2/5] 読む reference の選択

下表で該当するものだけを Read する。全部読まない。

設計対象に含まれるか	読む reference
回答してよい範囲を絞りたい	references/scope-limiting.md
外部由来のテキストをプロンプトに入れる (ユーザ投稿・文字起こし・取得文書・ツール出力・検索結果)	references/untrusted-input.md
与えた文書や検索結果に基づいてのみ答えさせたい / RAG を組む	references/grounding.md
[1/5] で「意図的な攻撃を想定」と判定した / プロンプトだけでは制御しきれないと分かっている	references/guardrails.md

加えて references/evaluation.md は常に読む。 LLM の出力は非決定的なので、何を作っても効いているかの検証は必要になる。

references/evidence.md は逐語引用と出典 URL を集めた根拠集で、通常は読まない。次の場合だけ開く。

• 規範の理由を確かめたい、ユーザに根拠を示す必要がある
• その規範に本当に公式の裏付けがあるか疑わしい (E7 に「一次情報が見つからなかった論点」と「未検証範囲」を列挙してある)
• references の内容が古くなっていないか確認する (E6 に情報源一覧と取得上の注意)

[3/5] 設計

読んだ reference の規範を、設計対象に実際に関係する項目だけ適用する。reference はチェックリストではないので、全項目を機械的に盛らない。

設計として決めるべきことと、規範との対応:

• プロンプトの構成 — ペルソナ → 会話ルール → ガードレールの順。スコープの宣言方法 (ミッション 1 文の DARE 方式か、許可リストの列挙か)
• 拒否時の応答 — 文言を literal で決める。善意の off-topic と悪意の逸脱で出し分けるか
• 非信頼テキストの置き場所 — system に置かないのは両ベンダー一致だが、移し先は OpenAI (user メッセージ) と Anthropic (tool_result のみ) で推奨が割れている。どちらを採るかは選択なので、選んだ根拠を明示する
• ガードを積むか — 積むなら入力側か出力側か、判定器のモデルと合否の表現方法、しきい値
• 評価セットの構成 — 何を「答えるべきでない集合」に、何を「答えるべき集合」に入れるか

仕様に明示されていない選択をしたら、その選択と根拠を出力に明示する (~/.claude/rules/core/implementation.md の規約)。特に上記の「割れている論点」は、合意事項であるかのように書かない。

ユーザにしか決められないこと (回答範囲の線引き、拒否の強さ、コストとレイテンシの許容度) は AskUserQuestion で確認する。Q1 / Q2 のナンバリングと A / B / C の選択肢形式にする。

[4/5] 実装

• プロンプトは定数として切り出す。 呼び出しコードに埋め込まない
• プロンプト文字列の検証は通常のテストに置ける。 system message の完全一致アサーションは決定的なので Vitest 等で回せる。ただしプロンプト定数を import して比較するとトートロジーになるため、期待値はテスト側に literal で書く
• LLM の出力を検証するテストは通常のテストスイートに混ぜない。 非決定的で CI を不安定にする ([5/5] へ)
• 実装は TDD で進める (~/.claude/rules/core/tdd.md)。プロンプト定数の差し替えは観測可能な振る舞いの変更にあたるので、テストの期待値を先に更新して RED を観測する

[5/5] 評価

references/evaluation.md に従って評価セットを作る。要点だけ再掲する。

• 「答えるべきでない集合」と「答えるべきなのに拒否されがちな集合」を対で作る。 片側だけだと過剰拒否に気付けない
• 出し分けた文言をそれぞれ literal で固定してあれば、文字列一致で機械採点できる。プロンプトで引き戻しと拒否を書き分けたなら、採点も 2 文言で行う
• LLM 呼び出しを含むので CI では回さず、プロンプト変更時に手動実行するスクリプトとして置く

実装後は、範囲内の質問が従来どおり答えられているかも必ず確認する。制限を足すとモデルは安全側に倒れすぎるため、悪化していないことの確認が制限が効いていることの確認と同じくらい重要。

---

references/ の鮮度

各 reference は 2026-07-26 時点の調査に基づくスナップショットで、公式ドキュメントの更新には自動追従しない。内容が古いと感じたら references/evidence.md の E6 (情報源一覧と取得上の注意) から一次情報を再取得する。

再取得時は E7 末尾の検証手法の教訓を先に読むこと。要約モデル経由の fetch は hidden 属性や条件付き表示を無視するため、版数・非推奨告知・「存在しないこと」の確認には使えない (この資料の作成中に実際に誤報が出た)。生 HTML の grep か実ブラウザでの computed style 確認を使う。