GPT-5.5 / 5.4 向けに積み上げた system prompt を、そのまま GPT-5.6 へ持ち込むと、指示の矛盾やトークン増、過剰な確認要求が表に出やすくなります。
📑目次
OpenAI の Prompting guidance for GPT-5.6 は、長い手順スクリプトより次を勧めています。
- lean な system prompt
- 認可境界の明示
text.verbosity/ pro mode / Programmatic Tool Calling（PTC）の使い分け
本記事は公式 docs を一次根拠に、Tech Times・rmax.ai・gihyo.jp・Qiita など独立ソースで補完し、移行チェックリストと比較表に落とします。読者はチェックリストを自環境の代表タスクに当て、まずは検証環境で小さく始め、合格条件を満たしてから本番へ進めてください。
内部 coding-agent の数値レンジは directional（方向性の目安） であり、自アプリの代表タスクで測る前提です。採用前に検証環境で小さく始めて baseline を取り、公開サンプル数値をそのまま KPI にしないでください。
何が変わったか — 長い手順プロンプトが負債になりやすい理由
結論
結論から言うと、GPT-5.6 では「ステップを全部書いておけば安全」という設計が、必ずしも効きません。
モデル側の意図理解と multi-step の積極性が上がる一方、矛盾した MUST/NEVER や冗長な例が残っていると、厳密に満たそうとして不安定になり得ます。
モデル文脈（Sol / Terra / Luna）
gihyo.jp の報道では、2026-07-09 前後に GPT-5.6 の Sol（flagship）/ Terra（バランス）/ Luna（高速・低コスト）が一般提供の文脈で整理され、API では gpt-5.6 が Sol へルーティングされる、とされています。
developer 向けに重要なのはモデル名そのものより、移行時に reasoning 設定を現行と1段階下で比較するという運用です。
残すもの・注意点
公式が残すよう促しているのは、次の4点です。
- domain context
- hard constraints
- approval boundaries
- success criteria
全ステップの処方は減らせます。Tech Times は、旧モデル向けのパッチ指示が積み重なると「矛盾した契約」になり、現行モデルほど厳密に従おうとして品質が落ち得る、と整理しています。移行前にパッチ履歴を棚卸しし、矛盾する MUST/NEVER を解消してから同じ eval で再測定してください。
注意点は明確です。
- 公式が示す評価スコア改善やトークン削減レンジは、内部 coding-agent のサンプルであり、製品保証ではありません
- モデル差し替えと prompt 大改修を同時に行うと、何が効いたか切り分けできません
lean system prompt — 削るもの・残すもの・検証の進め方
lean 化の目的と公式レンジ
lean 化の目的は「短くすること」ではなく、成果条件と権限だけを残し、効かない指示を落とすことです。
公式の内部サンプルでは、leaner system prompts により次のレンジが示されています（workload 依存・directional）。
- 評価スコア: おおよそ 10–15% 改善
- 総トークン: 41–66% 削減
- コスト: 33–67% 削減
進め方
運用上の進め方は、次のように段階を分けます。
- いま合格している prompt と tool 定義をベースラインとして固定する
- ルール・サンプル・ツール定義を 小さな塊ごとに 外す
- 外したあと、同じ評価セット を再度回す
- 同じ趣旨の文を system 内で二重に置かない
- 今回のタスクと無関係なツールはモデルから見えない状態にする
- 残すのは、実測で差が出たフォーマット指定やスタイルに限る
残す軸と削り候補
残す軸:
- 利用者が見る成果物の定義
- 成功判定
- 停止条件
- 安全と権限
- 状況に応じた tool routing
- 必須スキーマと validation
削り候補:
- 同趣旨の繰り返し
- 効果のない口調指定
- 差の薄いサンプル
- 用途外ツール
- ツール説明の重複
| 観点 | 手続き型（旧寄り） | lean / 契約型（GPT-5.6 向け） |
|---|---|---|
| 指示の中心 | ステップ列・MUST/NEVER の蓄積 | outcome・成功条件・権限・停止 |
| ツール | 全部載せて汎用指示 | タスク関連のみ・説明は短く正確 |
| 長さ制御 | 「簡潔に」を system に連発 | text.verbosity + タスク固有要件 |
| 変更方法 | モデル更新と同時に一括改変 | 1 グループずつ削除して同一 eval |
| 期待効果 | 手順遵守のつもり | トークン/コスト減と品質改善の可能性（directional） |
出典:
日本語の二次解説（note / Zenn など）でも、「手続きの長さより制約と完了条件」に寄せる整理が目立ちます。
ここでの実務判断は、eval なしの一括削除はしないことです。
認可境界と prompts-as-contracts — 自律を許す範囲を1か所に書く
公式 compact policy
GPT-5.6 は multi-step で積極的に動くため、認可レベルを曖昧にすると、安全な作業まで毎回確認を求めたり、逆に外部 write まで進んだりします。本番投入前に検証環境で認可境界を1か所に書き、外部 write / 破壊的操作は runtime の confirmation を必須にしてください。破壊的操作は限定する方針で進め、未検証なら導入を見送ってください。
公式の compact policy はおおよそ次の層です。
- 回答・説明・レビュー・診断・計画: 調査と報告。変更要求がなければ実装しない
- 変更・構築・修正: in-scope のローカル変更と non-destructive validation は確認なしで可
- 外部 write / 破壊的操作 / 購入 / スコープ拡大: confirmation 必須
prompts-as-contracts の考え方
「ask first」「do not mutate」を連打すると、本来許可すべき安全作業まで止まります。許可済みの安全作業と要確認操作を compact policy で分け、停止条件を明示してから検証環境で小さく始めてください。
契約要素
rmax.ai の独立分析は、prompt を手順プログラムではなく behavioral contract として扱う枠組みを提案しています。揃える要素は次のとおりです。
- outcome
- success
- authority
- evidence
- validation
- output structure
- stop & escalation
不変条件（secrets 非開示など）とポリシー（いつ検索するか）と preference（文体）を混ぜない、という分離も有用です。改修時はまず不変条件だけ残し、ポリシーと preference を別枠へ移してから再評価してください。
権限表（例）
| アクション種別 | 既定ポリシー（例） | プロンプトで書くこと | ランタイム側 |
|---|---|---|---|
| 読み取り・分析 | 許可 | 対象と報告形式 | 監査ログ |
| in-scope ローカル変更 | 変更要求時に許可 | スコープ境界 | 差分レビュー |
| non-destructive 検証 | 許可 | 許可するテスト種別 | タイムアウト |
| 外部 write / 破壊 / 購入 | 要確認 | 何が外部か | 承認ゲート |
| スコープ拡大 | 要確認 | 拡大の定義 | チケット化 |
出典と runtime 境界
出典:
- OpenAI Developers
- rmax.ai — Prompts as contracts（2026年7月時点）
高影響操作では prompt 文言だけでは足りず、runtime の allow/deny/approve を独立させる、という解釈は rmax 側の合成であり、公式そのものではありません。
APIレバー — verbosity・reasoning・pro mode・PTC の使い分け
text.verbosity
長さの既定は text.verbosity（low / medium / high）に寄せ、タスク固有の必須項目は prompt に残します。
広い「Be concise」は、GPT-5.6 では不要か短すぎることがあります。短い回答でも、結論・根拠・重要な caveat・次アクションの優先順位は明示できます。
reasoning.effort と pro mode
reasoning.effort は none〜max。5.5 / 5.4 からの移行では、現行設定と 1 段階下 を代表タスクで比較します。
pro mode は別 slug ではなく reasoning.mode: "pro" で、困難タスク向けに model work を増やして単一最終回答を返します。
- routine / 高頻度: standard が向く
- prompt: outcome-focused のままで構わない（「もっと考えろ」は不要）
Programmatic Tool Calling（PTC）
Programmatic Tool Calling（PTC）は、filter / join / aggregate など bounded な中間処理向けです。全面適用の前に、中間処理だけ PTC に切り semantic 判断は残す境界を決めてください。
向く場面と direct に残すもの
次の段階は direct tool call を残します。PTC 切替後は最終 message と承認フローが欠落していないかを必ず確認してください。
- semantic judgment
- 承認
- 引用や native artifact の保持
両方あるときに明示する項目
Qiita の実務メモも、公式と同型の分岐を示しています。両方ある場合は、次を明示します。
- PTC 対象ステージ
- 許可ツール
- 出力 schema
- concurrency / retry / stop
- direct に残す仕事
評価時は program_output と最終 assistant message を 両方 見ます。
レバー比較と出典
| レバー | 向く場面 | 向かない場面 | 確認指標 |
|---|---|---|---|
| lean system prompt | 指示が厚く矛盾し始めたエージェント | eval なしの一括削除 | 成功率・トークン・コスト |
| text.verbosity | 既定の長さを統一したい | 必須項目がタスク毎に激変 | 省略率・必須項目欠落 |
| reasoning.effort | 難易度に応じた探索 | 常時 max 固定 | 品質/latency 曲線 |
| pro mode | 高価値の難タスク | 高頻度 routine | 追加 model work 対品質 |
| PTC | 大量中間結果の縮小 | 毎回判断が変わる連鎖 | program_output と最終 message |
出典:
- OpenAI Developers
- Qiita（2026年7月時点）
移行チェックリストとよくある失敗
読後にそのまま実行できる手順は次のとおりです。
- 現行で合格する prompt / tool set をスナップショットした
- 代表タスクの評価観点（正答・必須証拠・禁止行動）を文書化した
- 指示 / 例 / 無関係ツールを1グループずつ削り、毎回同じ eval を回した
- outcome / success / 権限 / 停止 / 出力 schema を1か所に集約した
- MUST/NEVER を真の不変条件だけに減らした
- PTC 対象ステージと direct を残す条件を明示した
- reasoning effort と pro mode を独立に A/B した
- cache write / read と総トークンを計測した（cache write は uncached input の 1.25× に注意）
よくある失敗:
- モデル更新と prompt 大改修を同時実施する（次は片方ずつ実施し、同じ eval で切り分ける）
- 評価なしの一括削除（次は1グループずつ削除して再評価する）
- PTC を「効率」だけで全面適用する（次は bounded な中間処理に限定して試す）
program_outputだけ見て最終 message の欠落を見落とす（次は最終 message・承認・成果物も併せて確認する）
関連記事:
- OpenAI GPT-5.6発表：Sol/Terra/Lunaの3モデルと政府限定プレビュー
- OpenAI GPT-5.6、政府承認20社限定プレビュー開始 — Sol/Terra/Lunaの段階的展開
- GPT-Liveとは？フルデュプレックス音声と委譲設計を公式情報で整理
よくある質問（FAQ）
まとめ — 今日からやる移行順
まず OpenAI 公式の GPT-5.6 prompt guidance を読み、示されている数値は directional と理解してください。
次に、本記事のチェックリストを上から実行し、比較表で PTC / verbosity / pro mode を選びます。
次アクション:
- 代表タスクを3本以上用意する
- before/after の成功率・トークン・コストを記録する
- 残す指示セットをリポジトリの正本にする
Sol / Terra / Luna の位置づけや GA 文脈は gihyo.jp の GPT-5.6 報道 も参照できます。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す