GPT-5.5とClaude Opus 4.7で変わるプロンプト設計

GPT-5.5 Claude Opus 4.7 プロンプト設計の公式ガイドを読み比べると、「明確に書く」という方針は同じなのに、設計責任の置き場所がまるで違うことがわかります。GPT-5.5は7要素で「成果物の契約」を作り、Claude Opus 4.7はeffortとSKILL.mdで「実行能力の起動条件」を設計します。この記事では公式ドキュメントの要点をCodex SKILLとClaude Code agentの実装テンプレートに落とし込みます。

関連記事: 生成AIカテゴリの記事一覧

GPT-5.5とClaude Opus 4.7のプロンプト設計比較イメージ — 成果物の契約 vs 起動条件の設計という根本的な違い

まず結論: Codexは成果条件、Claudeは起動条件と推論深度を設計する
1. 比較表: 同じ「アウトライン設計エージェント」でも設計ポイントが違う
ありがちなNG例: モデル名と役割を曖昧にしたプロンプト
1. NG例: 「あなたは優秀な編集者です」と書くだけでは動けない
2. 何が足りないのか: 成功状態・停止条件・協働スタイルの欠如
GPT-5.5式: 7要素で「成果物の契約」を作る
Claude Code式: SKILL.mdで起動条件と推論深度を設計する
文字通りに解釈される前提でClaude向け指示を書く
1. 「構成案を作る」だけでは足りない理由
2. 公式情報の反映範囲・やらないこと・停止条件を明示する
設計思想の違い: GPT-5.5は契約、Claude SKILLは起動装置
実務での組み合わせ方
1. Claude Codeが計画・レビュー・設計判断を担う
2. Codexが実装・検証・自律実行を担う
あわせて読みたいおすすめ書籍
参考資料
まとめ

まず結論: Codexは成果条件、Claudeは起動条件と推論深度を設計する

GPT-5.5向けのプロンプトとClaude Opus 4.7向けのプロンプトは、同じ「アウトライン設計エージェント」を作る場合でも、設計のポイントが根本的に異なります。まずこの違いを把握することが、実装品質の向上に直結します。

比較表: 同じ「アウトライン設計エージェント」でも設計ポイントが違う

以下の表は、同一のタスク（WordPress技術記事のアウトライン設計）を両モデル向けに設計した場合の違いをまとめたものです。

設計項目	GPT-5.5（Codex SKILL）	Claude Opus 4.7（SKILL.md）
設計の中心	成果物の定義（何を出すか）	起動条件の定義（いつ・なぜ動くか）
構造	7要素のMarkdown（Role/Personality/Goal/Success criteria/Constraints/Output/Stop rules）	YAMLヘッダー + XMLタグ（role/context/task/constraints）
推論深度の制御	明示的な設定なし	effortとadaptive thinkingで設定
トリガー設計	ConstraintsのStop rulesで停止条件を明示	descriptionでルーティング条件を記述
文脈の扱い	Goal・Success criteriaで成功状態を固定	contextタグに厚く・丁寧に与える
安全性の担保	開発者がStop rulesを書く	Constitutional AIで組み込み済み

この比較から、GPT-5.5向けには「何が完成したら終わりか」を先に決める設計が有効であることがわかります。一方、Claude Opus 4.7向けには「どんな状況でこのスキルを起動すべきか」を記述することが重要です。

（参考: OpenAI Prompt Engineering Guide / Anthropic Claude Prompting Best Practices（公式））

ありがちなNG例: モデル名と役割を曖昧にしたプロンプト

GPT-5.5 Claude Opus 4.7 プロンプト設計でよくある失敗は、役割の記述が曖昧なまま実行してしまうことです。具体的なNG例と、その問題点を整理します。

NG例: 「あなたは優秀な編集者です」と書くだけでは動けない

次のプロンプトは、一見すると問題ないように見えます。しかし実際には、エージェントが正しく動けない典型例です。

あなたは優秀なブログ編集者です。アウトラインを作ってください。

このプロンプトで指示を受けたモデルは、「何文字のアウトラインを作るのか」「どんな読者向けなのか」「どこで止まればいいのか」がわかりません。そのため、モデルは推測で補完しながら出力します。結果として、意図した成果物とズレが生じやすくなります。

何が足りないのか: 成功状態・停止条件・協働スタイルの欠如

上記のNG例に欠けている要素を整理すると、以下の3点に集約されます。

成功状態の欠如: 「どんな状態になったら完成なのか」が定義されていない
停止条件の欠如: 「どんな状況で止まるべきか」がない。そのため、不確かな情報でも突き進んでしまう
協働スタイルの欠如: 「ユーザーと対話すべきか、自律的に完結すべきか」が明示されていない

これらの欠如は、GPT-5.5でもClaude Opus 4.7でも同様の問題を引き起こします。ただし、解決の方法論が両者で異なります。次のセクションで、それぞれのOK例を見ていきましょう。

GPT-5.5式: 7要素で「成果物の契約」を作る

GPT-5.5向けのプロンプト設計では、7つの要素で「何を・どこまで・どんな形で出すか」を先に固定します。これをOutcome-first（成果物優先）設計と呼びます。OpenAIの公式ガイドでは、このアプローチが推奨されています。

Role: 何の専門エージェントかを1-2文で固定する

Roleは「あなたは〇〇の専門家です」という一般的な記述ではなく、「何のタスクを担うエージェントか」を1〜2文で固定します。具体的には、担当する成果物の名称を含めます。たとえば「技術ブログのアウトライン設計エージェント」のように書きます。

Personality: キャラ設定ではなく協働スタイルを書く

Personalityはキャラクターの性格ではなく、「どう振る舞うか」を記述します。「直接的に答える」「根拠が弱い主張は保留する」「ユーザーが提供した公式情報を優先する」などの協働スタイルを書きます。これにより、エージェントの一貫した挙動が確保されます。

Goal + Success criteria: 作業内容ではなく成功状態を先に決める

GoalとSuccess criteriaがGPT-5.5式設計の核心です。Goalには「何をするか」ではなく「何が達成された状態がゴールか」を書きます。Success criteriaには、検証可能な完了条件を箇条書きで列挙します。たとえば「H2が3〜5本、各H2下にH3が2〜3本含まれる」「フォーカスKWが少なくとも1つのH2タイトルに含まれる」のように書きます。

Constraints / Output / Stop rules: 制約・出力形式・停止条件を明示する

Constraintsには「やらないこと」と「越えてはいけないライン」を書きます。Outputには出力形式・ファイル形式・含まれるべき項目を明示します。そして重要なのがStop rulesです。「根拠が不足している場合は止まる」「出力パスが指定されていない場合は確認する」など、エージェントが自律的に停止すべき条件を明示します。

GPT-5.5式OK例コード（アウトライン設計エージェント）

以下が、7要素を使った実装テンプレートです。NG例と見比べると、設計の具体性が大きく異なることがわかります。

Role: 技術ブログのアウトライン設計エージェント

# Personality
直接的。根拠が弱い主張は保留する。ユーザーが提供した公式情報を優先する。

# Goal
WordPress向け技術記事のH2/H3構成と各セクションの狙いを作る。

# Success criteria
- H2見出しが3〜5本、各H2下にH3が2〜3本含まれる
- フォーカスKWが少なくとも1つのH2タイトルに含まれる
- 使用したすべての公式情報に出典URLが付いている

# Constraints
- 公式ドキュメントに記載のない内容を断定しない
- モデル名（GPT-5.5、Claude Opus 4.7など）を曖昧な表記にしない
- 1回の広い検索を実施し、十分な引用根拠があれば再検索しない

# Output
- Markdown形式のH2/H3構成
- 各セクションのtarget_keywords（1〜3語句）
- コードサンプルが必要な箇所のメモ

# Stop rules
- 出力パスが指定されていない場合は実行前に確認する
- 根拠が不足している主張は「要確認」として止める
- テーマが広すぎる場合は絞り込みを求めて停止する

このテンプレートを見ると、エージェントが「いつ完了するか」「何が足りないと止まるか」が明確に定義されています。そのため、GPT-5.5は推測での補完をせず、定義された範囲内でのみ動作します。

（参考: GPT-5.5 Prompt Guidance（公式） / OpenAI Structured Outputs）

Claude Code式: SKILL.mdで起動条件と推論深度を設計する

Claude Opus 4.7向けのプロンプト設計では、SKILL.mdのYAMLヘッダーとXMLタグを組み合わせて「いつ・どの深さで思考するか」を設計します。GPT-5.5が成果物の契約を作るのに対し、Claude Code式は実行能力の起動装置を設計します。

descriptionが最重要: いつ起動するスキルなのかを明示する

SKILL.mdのYAMLヘッダーにあるdescriptionフィールドは、Claude Code内のルーティングシステムが参照します。「どんな状況でこのスキルを使うべきか」「何の前・何の後に使うか」「何をしないか」を1〜3文で記述します。このdescriptionの質がスキルの自動選択精度を決定します。

XMLタグで役割・文脈・制約を構造化する

SKILL.mdの本文では、<role>・<context>・<task>・<constraints>のXMLタグで構造化します。Anthropicの公式ドキュメントでは、XMLタグによる構造化が「Claudeが最も確実に理解できる形式」として推奨されています。特に<context>には、変数プレースホルダー（{{ reader_persona }}など）を使って動的な情報を渡す設計が有効です。

effortとadaptive thinking: 推論の深さを設計対象にする

Claude Opus 4.7では、effortパラメータで推論の深さを制御できます。これはGPT-5.5には存在しない設計要素です。

effort: low: 単純な変換・フォーマット変換など、深い思考が不要なタスク向け
effort: medium: 標準的な記事執筆・コードレビューなど（デフォルト）
effort: high: 複数ドキュメントの比較・長期設計など、深い分析が必要なタスク向け
effort: xhigh: 複数公式ドキュメント比較・複雑なアーキテクチャ設計など、最大の推論深度が必要なタスク向け

thinking: adaptiveと組み合わせることで、タスクの複雑さに応じて推論深度が自動調整されます。APIからは以下のように設定します。

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "xhigh"},  # 複数公式ドキュメント比較・長期設計
    messages=[{"role": "user", "content": "WordPress技術記事のアウトラインを設計してください..."}],
)

Claude Code式OK例コード（アウトライン設計エージェント）

以下が、SKILL.md形式の実装テンプレートです。YAMLヘッダーのdescriptionから始まり、XMLタグで構造化された本文まで、すべての要素が「いつ・どう動くか」を定義しています。

---
description: WordPress技術記事のSEO最適化アウトラインを設計する。リサーチ結果・対象読者・フォーカスKWを受け取り、H2/H3構成・検索意図・コード例配置を含むoutline.mdを生成する。Geminiリサーチ完了後かつwp-article-writer呼び出し前に使う。outline.mdの生成のみを行い、記事本文の執筆は別スキルに委譲する。

Recommended runtime:
- model: claude-opus-4-7
- thinking: adaptive
- effort: xhigh（複数公式ドキュメント比較・長期設計の場合）
---

<role>
あなたはSEOに精通したブログ編集長です。技術記事のアウトラインを設計します。
このフォーマットをすべての出力セクションに適用してください。
</role>

<context>
対象読者: {{ reader_persona }}
リサーチ結果: {{ research_summary }}
出典リスト: {{ sources }}
</context>

<task>
以下の形式でoutline.mdを生成し、{{ output_path }}に保存してください:
- フォーカスKW（1語句）
- 関連KW（3-5語句）
- 検索意図（1行）
- H2 3-5本 / 各H2下にH3 2-3本
- 各セクションにtarget_keywords

outline.mdの生成のみを行う。記事本文の執筆はしない。
</task>

<constraints>
- タイトルはフォーカスKWで始める（32-60文字）
- H2は最低1つにフォーカスKWを含める
- コードサンプルが必要な箇所を明記する
- 公式情報と推測を分ける
- やらないこと: 記事本文の執筆、画像生成リクエスト、WordPress投稿
</constraints>

特に注目すべきは<constraints>の最後の行です。「やらないこと」を明示することで、スコープクリープ（タスクが意図せず拡大すること）を防ぎます。これはAnthropicが推奨する「explicit context（文脈の明示）」の実践例です。

（参考: Anthropic Prompt Engineering Overview / Claude Code Sub-agents）

文字通りに解釈される前提でClaude向け指示を書く

Claude Opus 4.7は指示を文字通りに解釈します。この特性を理解することが、プロンプト設計の質を大きく左右します。Anthropicの公式ドキュメントでも、この点は明確に強調されています。

「構成案を作る」だけでは足りない理由

「構成案を作る」という指示を受けたClaude Opus 4.7は、指示通りに構成案を作ります。しかし、「どの公式情報を参照するか」「何を含めるべきか」「どこで止まるか」は指示されていないため、モデルが推測で補完します。その結果、期待と異なる出力が生まれやすくなります。

具体的には、次のような問題が起きやすいです。

公式情報の代わりに学習データの知識で補完してしまう
記事本文まで書き始めてしまう（スコープ外の作業）
不確かな情報を断定的に書いてしまう

公式情報の反映範囲・やらないこと・停止条件を明示する

これらの問題を防ぐために、次の3点を必ず明示します。

反映範囲: 「提供した出典リストのURLのみを参照する」「学習データのみに基づく情報は『要確認』と付ける」
やらないこと: 「記事本文の執筆はしない」「画像生成リクエストは作らない」など、スコープ外のタスクを列挙する
停止条件: 「フォーカスKWが未指定の場合は確認してから進む」「出典URLが0件の場合は止まる」

この3点を<constraints>タグ内にまとめることで、Claude Opus 4.7は指示された範囲内でのみ動作するようになります。指示の「解釈の余地」を最小化することが、安定した出力の鍵です。

（参考: Anthropic Claude Prompting Best Practices（公式））

Claude Code agentのsubagentルーティングの仕組みを示すフロー図 — descriptionフィールドが自動ルーティングのキーになる — Claude Codeでは起動条件の設計がSKILL品質を決める

設計思想の違い: GPT-5.5は契約、Claude SKILLは起動装置

GPT-5.5 Claude Opus 4.7 プロンプト設計の違いは、表面的な書き方の違いではありません。両者の背後にある設計思想の違いから生まれています。この思想の違いを理解することで、どちらのモデルに何を任せるべきかの判断が明確になります。

GPT-5.5: outcome-first と Context Engineering

GPT-5.5の設計思想は「outcome-first（成果物優先）」です。タスクを実行する前に「何が完成したら終わりか」を定義することで、モデルの動作を制御します。加えて、OpenAIはContext Engineeringという概念を推進しています。これは「モデルに与える文脈を工学的に設計する」という考え方で、成果物の仕様・制約・停止条件を事前に精密に定義することを重視します。

Claude Opus 4.7: Constitutional AI と explicit context

Claude Opus 4.7の設計思想の背骨にはConstitutional AIがあります。これはAnthropicが2022年に発表した、AIを一連の原則（Constitution）で自律的に評価・改善する手法です。その結果、Claudeはモデル自体に安全性の原則が組み込まれています。そのうえで、Anthropicはexplicit context（文脈の明示）を重視します。具体的な状況・目的・制約を与えることで、Claudeはより正確に意図を理解します。

安全性の違い: 開発者ガードレール vs 組み込み原則

安全性の確保方法も両者で異なります。GPT-5.5ではStop rulesやConstraintsなど、開発者がプロンプト上にガードレールを設置します。一方、Claude Opus 4.7ではConstitutional AIによってモデル自体に安全性の原則が組み込まれています。そのため、開発者が明示的に書かなくても、一定の安全性が保たれます。ただし、タスクのスコープ制限は依然として<constraints>に明示する必要があります。

（参考: Constitutional AI（Anthropic公式） / Anthropic Tool Use）

実務での組み合わせ方

GPT-5.5とClaude Opus 4.7は競合ではなく、役割分担して使うことで最大の効果を発揮します。実務では「Claude Codeが計画・設計判断を担い、Codexが実装・実行を担う」という分業が効果的です。

Claude Codeが計画・レビュー・設計判断を担う

Claude Opus 4.7はadaptive thinkingとeffortパラメータにより、複雑な判断タスクに強みを持ちます。具体的には次のような役割に向いています。

複数の公式ドキュメントを比較してアウトラインを設計する（effort: xhigh）
生成されたコードをレビューして品質基準に合うか判断する
ユーザーの曖昧な要求を整理して、実装可能な仕様に落とし込む
エラーの根本原因を多角的に分析して修正方針を決める

Codexが実装・検証・自律実行を担う

GPT-5.5（Codex）は成果物の契約が明確に定義されたタスクで高い自律性を発揮します。次のような役割に向いています。

Claude Codeが設計したアウトラインを元に記事HTMLを生成する
定義されたSuccess criteriaをすべて満たすまで反復する
テストケースを実行して合否を判定する
バッチ処理・繰り返し作業を自律的に実行する

このような役割分担を実現するために、Claude Code側のSKILL.mdには「Codexへのhandoffのタイミング」を明示し、Codex側のSKILLには「受け取るべき成果物の仕様」を7要素で定義します。両者を正しく設計することで、end-to-endの自動化パイプラインが安定して動作します。

関連記事: IT技術カテゴリの記事一覧

（参考: Claude Code Sub-agents（Anthropic公式））

あわせて読みたいおすすめ書籍

プロンプトエンジニアリングの理論からAIエージェントの実装・運用まで、開発者が手元に置いておきたい2冊を紹介します。

リンク

参考資料

まとめ

GPT-5.5 Claude Opus 4.7 プロンプト設計の違いと実務的な使い分けを整理しました。重要なポイントをまとめます。

GPT-5.5（Codex）は7要素（Role/Personality/Goal/Success criteria/Constraints/Output/Stop rules）で「成果物の契約」を作る。何が完成したら終わりかを先に定義するoutcome-first設計が基本
Claude Opus 4.7はSKILL.mdのdescriptionで起動条件を定義し、XMLタグで役割・文脈・制約を構造化する。effortパラメータで推論深度を設計対象にできる点がGPT-5.5にはない特徴
共通のNGは「役割だけ書いて成功状態・停止条件・協働スタイルを省略すること」。どちらのモデルに対しても、この3点の欠如が出力品質の低下を招く
安全性の設計はGPT-5.5がStop rulesを開発者が書き、Claude Opus 4.7はConstitutional AIでモデル自体に組み込まれている。ただしスコープ制限はどちらも明示が必要
実務での役割分担は、Claude Codeが計画・設計・レビューを担い、Codexが実装・検証・自律実行を担う構成が効果的

プロンプト設計の質は、エージェントが「期待通りに止まれるか」で決まります。両モデルの思想の違いを理解した上で、それぞれの設計テンプレートを実装に活用してみてください。

関連記事: AWSカテゴリの記事一覧