Claude Codeのsystem prompt変更を毎回検証する

結論：指示文を反復する時だけsnapshotをoffにして比較する

一次情報はClaude Code公式changelogの2.1.267と、公式CLI referenceです。changelogはこのオプションの目的をsystem promptのfresh renderingとして説明し、CLI referenceは起動オプションの位置づけを確認する正本です。指示文の変更による品質向上、速度、料金の具体的な保証は公式情報から断定しません。

snapshot onとoffを比較する

状態	挙動	向く用途
通常	会話に記録されたsystem promptを再利用	同じ条件で継続する通常session
off	各リクエストでsystem promptをfreshに描画	指示文の反復、差分検証
別session	新しい会話条件として開始	変更の影響を独立に測る

ここでいうsnapshotは、業務で保管しているプロンプト原本や判断ログを自動保存する仕組みではありません。原本の管理場所は別に用意し、変更ID、差分、承認者を記録します。offを有効にしたからといって、どの指示文が使われたかを後から推測できるとは限らないためです。

比較では、入力とツール、モデル、権限、確認者をそろえます。system promptだけを変更したいのに、session、モデル、MCP、project settingsまで変えると原因が追えません。変更を一件ずつ切り出し、結果だけでなく拒否、確認要求、tool利用、エラーも記録します。

検証手順：指示文の変更を7ステップで再現する

1. Claude Codeのversion、model、provider、project、実行者、確認時刻を記録します。
2. 現在のsystem promptを原本として識別できる名前とhashで管理し、機密値をログへコピーしません。
3. 通常状態で代表的な入力を一件実行し、出力、tool呼び出し、確認要求、所要時間を保存します。
4. 差分を一つだけ加えた指示文を検証用の変更としてレビューし、変更理由と期待する挙動を書きます。
5. claude --system-prompt-snapshot offで同じsession条件を起動し、同じ入力を実行します。
6. 変更前後を、正確さだけでなく禁止事項、停止条件、人間確認、出力形式で比較します。
7. 採用・却下・再試験を決め、採用する場合は原本、version、適用scope、rollbackを台帳へ戻します。

指示文の検証は「回答がよくなったか」だけでは足りません。業務では、顧客情報を出さない、承認前に送信しない、情報不足なら質問する、危険な操作を止める、といった境界の維持が重要です。通常ケース一件が改善しても、停止条件が弱くなったなら採用しません。

企業運用での使い分けと再現性

system promptを頻繁に更新するチームでは、subagent指示をファイル化する方法と原本の管理場所を分けて考えます。ファイル化は配布とreviewに役立ちますが、offはsessionごとのfresh renderingを選ぶオプションです。変更を配ったことと、次のリクエストへ反映されたことを別々に確認します。

権限や安全境界は指示文だけに置きません。Claude Codeの権限設定、managed settings変更の承認、hookやMCPの設定を組み合わせます。promptが誤っても、送信、ファイル変更、外部通信を人間確認やdeny ruleで止められる構造にします。

料金と制限について、公式changelogはfresh renderingの挙動を説明しますが、専用料金や一定の速度・品質を保証していません。provider、model、session長、ツール利用が変われば結果も変わります。通常運用へ採用する前に、同じ業務サンプルで利用量、完了時間、修正時間、確認者の負担を実測します。

offを本番で使う場合は、適用対象を限定します。例えばprompt開発者だけがstagingで使い、承認済みpromptを通常設定で展開する方法です。全利用者のsessionへ突然適用すると、結果の差分がprompt変更によるものか、fresh renderingによるものか追いにくくなります。実行フラグ、prompt version、出力の保存先を一組にしてください。

チェックリスト：snapshotをoffにする前に

□2.1.267以降か　□変更対象のpromptを識別できるか　□機密情報を記録していないか　□model・provider・projectを固定したか　□通常状態の基準結果があるか　□変更は一件だけか　□offのsessionを明示したか　□tool・権限・停止条件を比較したか　□採用承認者を決めたか　□通常設定へ戻せるか

結果が毎回変わる時は、prompt以外の差分を探します。モデルaliasの解決、project settings、MCP接続、外部データ、時刻、ランダム性、入力の整形を並べ、固定できないものは「変動要因」として記録します。snapshot offを使っていることを理由に、検証不能な結果を品質改善として採用しないことが大切です。変更IDと実行条件を必ず紐づけます。採用後も見直し日を設定します。担当者が変わっても同じ手順を再現できる記録を残してください。

よくある質問

offなら変更したsystem promptが必ず反映されますか？

公式の説明は各リクエストでfreshに描画することです。適用する原本、scope、version、起動方法を確認し、実行時の条件を記録してください。

通常sessionの過去の回答を修正できますか？

できません。過去の記録を変更する機能ではないため、変更前後を別の検証として保存します。

指示文の変更で権限確認を省略できますか？

省略できません。prompt、permissions、managed settings、hooksを別の制御として設計し、危険操作や外部送信は独立した確認で止めます。

公式情報と無料診断

仕様は公式changelogと公式CLI referenceを公開直前にreadbackしています。Miraigentの無料診断では、prompt原本、検証条件、権限、人間確認、rollbackを業務フローへ整理できます。