Back to index

GPT-5.5で変わる、プロンプトの書き方

GPT-5.5の登場以来、以前のモデルと大きく変わったのは、プロンプトの役割です。

以前は、AIをうまく動かすために「手順」を細かく書くことが重要でした。これからは、AIに任せる仕事の「目的」「制約」「成功条件」を明確にすることが重要になります。

企画、営業、管理部門、開発、リサーチなど、知的作業をAIに渡す人にとって、この変化は小さくありません。プロンプトは、便利な質問文ではなく、AIに仕事を委譲するための業務設計書に近づいています。

先に結論

GPT-5.5時代のプロンプトは、命令文から契約書へ変わります。

観点 5.5以前の書き方 5.5以後の書き方
中心思想 AIを手順通りに動かす AIに成果物の条件を渡す
書くべき内容 作業順、確認順、出力順 目的、背景、制約、判断基準
良いプロンプト 細かく漏れなく指示する 任せる範囲と守る条件が明確
悪いプロンプト 指示不足で曖昧 指示過多で過剰拘束
人間の役割 操作者 依頼者、レビュー者、意思決定者

要するに、AIに「どう作業するか」を逐一教えるより、何を達成すれば成功かを渡すほうが成果が安定します。

OpenAIの公式ガイドでも、GPT-5.5はGPT-5.2やGPT-5.4の単純な置き換えではなく、新しいモデルファミリーとして調整すべきだと説明されています。古いプロンプトを丸ごと移植するのではなく、プロダクトや業務の契約を守れる最小のプロンプトから始め、必要に応じて深さ、詳しさ、出力形式を調整する、という考え方です。

なぜ書き方が変わるのか

モデルが弱い時代は、AIに自由度を与えると、論点が飛んだり、形式が崩れたり、前提を勝手に置いたりしました。

そのため、プロンプトは細かい操作マニュアルになりがちでした。

まず市場規模を調べてください。
    次に競合を3社挙げてください。
    次に各社の強みと弱みを書いてください。
    最後に表にしてください。
    不明点があれば質問してください。
    ステップバイステップで考えてください。
    

この書き方は悪くありません。ただし、GPT-5.5以後では、過剰に細かい手順が逆に品質を下げることがあります。

理由は単純です。モデルがより強く指示に従うため、古い指示、重複した指示、矛盾した指示まで丁寧に守ろうとするからです。

これからは、最初から長いプロンプトを書くのではなく、短く始めて、失敗した箇所だけ制約を足すほうが実務的です。

特に重要なのは、手順を削る代わりに「停止条件」を入れることです。AIに自由度を与えるなら、どこまで調べたら十分か、どの状態なら回答してよいか、何が足りなければ質問すべきかを決めておく必要があります。

基本形は5つだけでよい

GPT-5.5以後のプロンプトは、次の5要素で十分です。

要素 書くこと 実務での意味
Goal 何を達成したいか 最終成果物と意思決定の目的
Context 背景、前提、対象読者 業界、顧客、現場制約、利用場面
Constraints 守る条件、やらないこと 予算、期間、信頼できる情報範囲
Output 出力形式、粒度、長さ 表、論点メモ、提案骨子、役員向け要約
Evaluation 良い回答の条件 判断可能性、根拠、リスク、次アクション

テンプレートにすると、こうです。

Goal:
    何を達成したいかを書く。

    Context:
    背景、対象、前提、読者を説明する。

    Constraints:
    守るべき条件、使ってよい情報、やってはいけないことを書く。

    Output:
    形式、長さ、粒度、必要な表や箇条書きを指定する。

    Evaluation:
    良い回答の条件を定義する。
    

ポイントは、手順ではなく成功条件を定義することです。

長い作業を任せる場合は、ここにStoppingを足します。

Stopping:
    意思決定に必要な論点、根拠、不明点、次アクションが揃ったら、それ以上の調査を広げずに回答してください。
    不足情報が結論を変える場合だけ、最小限の確認質問をしてください。
    

例1: 競合分析

5.5以前の書き方

あなたは事業戦略に詳しいアシスタントです。
    まず競合を5社調べてください。
    次に各社のサービス、価格、強み、弱みを整理してください。
    その後、当社との違いを比較してください。
    最後に表にしてください。
    足りない情報があれば質問してください。
    

このプロンプトは、作業順は明確です。しかし、何の意思決定に使うのかが曖昧です。

5.5以後の書き方

Goal:
    B2B SaaSの新規参入可否を判断するために、競合環境を整理し、参入余地と初期ポジショニング案を出してください。

    Context:
    対象は日本市場の中堅企業向け業務SaaSです。読者は事業責任者と投資判断者です。目的は詳細な市場レポートではなく、次の検討会で意思決定できる材料を作ることです。

    Constraints:
    - 信頼できる公開情報に基づいてください。
    - 不明な情報は推測せず「不明」と書いてください。
    - 価格、顧客規模、差別化要素、販売チャネルを分けて整理してください。
    - 競合が強すぎる場合は、参入しない判断も選択肢に含めてください。

    Output:
    1. 競合比較表
    2. 参入余地の評価
    3. 勝ち筋がある場合の初期ポジショニング案
    4. 追加調査すべき論点

    Evaluation:
    読者が「参入する、しない、保留」のどれかを議論できる状態になっていること。

    Stopping:
    参入判断に必要な根拠と不明点が揃ったら、追加調査を広げずに結論を出してください。
    

違いは、AIに「調査して表にする」ではなく、「意思決定に使える競合分析を作る」と渡している点です。

例2: 役員向け提案書

5.5以前の書き方

以下のメモをもとに、役員向けの提案書を作ってください。
    わかりやすく、説得力のある文章にしてください。
    見出しをつけて、箇条書きも使ってください。
    

この依頼では、読みやすい資料は出るかもしれません。しかし、役員が知りたい論点に刺さるとは限りません。

5.5以後の書き方

Goal:
    役員会でAI投資の承認を得るため、投資判断に必要な論点だけに絞った提案骨子を作ってください。

    Context:
    対象企業は売上500億円規模の製造業です。現場ではAI活用のPoCが複数ありますが、本番展開に進めていません。役員は技術詳細よりも、投資対効果、リスク、責任体制を重視します。

    Constraints:
    - 技術用語は必要最小限にしてください。
    - 「AIを導入すべき」という結論ありきにしないでください。
    - 投資する場合、しない場合、段階導入する場合を比較してください。
    - 数字がない箇所は仮説と明記してください。

    Output:
    役員向け提案骨子として、次の順で出してください。
    1. 経営課題
    2. 投資判断の選択肢
    3. 各選択肢のメリット、リスク、前提
    4. 推奨案
    5. 次の90日で決めるべきこと

    Evaluation:
    役員が「何を承認すべきか」「何を保留すべきか」を判断できること。
    

多くの実務では、情報量よりも判断可能性が重要です。GPT-5.5以後のプロンプトでは、この判断可能性を成功条件として明示します。

例3: 会議メモの要約

5.5以前の書き方

以下の会議メモを要約してください。
    重要なポイントを箇条書きにしてください。
    アクションアイテムも出してください。
    

この書き方でも要約はできます。ただし、会議の種類によって必要な要約は違います。

5.5以後の書き方

Goal:
    プロジェクトオーナーが次回会議までに動けるよう、意思決定、未決事項、担当アクションを分けて整理してください。

    Context:
    これは基幹システム刷新プロジェクトの週次会議です。読者はプロジェクトオーナー、PMO、ベンダー責任者です。

    Constraints:
    - 発言者の意見と決定事項を混ぜないでください。
    - 決まっていないことを決定事項として書かないでください。
    - 担当者と期限が不明なアクションは「要確認」としてください。
    - リスクは影響範囲と緊急度を添えてください。

    Output:
    次の表で出してください。
    | 区分 | 内容 | 担当 | 期限 | リスク/補足 |

    Evaluation:
    読者が次回会議を待たずに、今日動くべきことを判断できること。
    

会議要約は、短くすることが目的ではありません。意思決定と実行を前に進めることが目的です。

例4: 調査依頼

5.5以前の書き方

生成AIの最新トレンドを調べて、重要なポイントをまとめてください。
    できるだけ詳しくお願いします。
    

このプロンプトはよくありますが、範囲が広すぎます。結果として、総花的なトレンドまとめになりがちです。

5.5以後の書き方

Goal:
    日本の大企業が2026年度に生成AI投資を増やすべき領域を判断するため、実務導入に影響するトレンドだけを整理してください。

    Context:
    読者は経営企画部門です。関心は技術そのものではなく、業務改革、コスト構造、人材、ガバナンスへの影響です。

    Constraints:
    - ニュースの羅列にしないでください。
    - 技術トレンド、業務インパクト、経営判断への示唆を分けてください。
    - 不確実性が高い論点は、確度を「高・中・低」で示してください。
    - すぐ投資すべき領域と、様子を見る領域を分けてください。

    Output:
    1. 経営に効くトレンド上位5つ
    2. 各トレンドの業務インパクト
    3. 投資判断への示唆
    4. 追加で検証すべき問い

    Evaluation:
    読者が次年度のAI投資テーマを3つに絞れること。
    

「最新トレンドをまとめる」ではなく、「投資テーマを絞るためにまとめる」と書く。ここが大きな違いです。

「深く考えて」は毎回書かなくてよい

以前は「step by stepで考えてください」と書くことがよくありました。

ただし、GPT-5.5以後では、すべての依頼で深い推論を強制する必要はありません。簡単な整形や要約で毎回深く考えさせると、出力が長くなり、余計な前提や説明が増えます。

特にチャットで使う場合は、「とにかく深く考えて」と毎回書くより、どの論点で慎重に判断してほしいのかを明示するほうが実用的です。たとえば、投資判断、契約リスク、優先順位づけのように、結論が分かれる部分だけ丁寧に扱わせます。

タスク 書き方の目安
メール文面の整形 不要
会議メモの分類 軽く条件を指定すれば十分
投資判断、戦略比較、リスク評価 必要
法務、医療、財務など高リスク領域 根拠、前提、不確実性の明示が必要

必要なときだけ、次のように書けば十分です。

判断が分かれる論点については、結論、根拠、前提、不確実性を分けて示してください。
    ただし、内部の思考過程を長く説明するのではなく、読者が検証できる判断材料として整理してください。
    

実務者向けのチェックリスト

GPT-5.5以後のプロンプトを書くときは、次の順で確認するとよいです。

  1. この依頼は、どの意思決定に使うのか
  2. 読者は誰か
  3. AIに任せてよい範囲はどこまでか
  4. 使ってはいけない情報や推測は何か
  5. 最終出力は、表、論点メモ、提案骨子のどれか
  6. 良い回答の条件は何か
  7. 不明点をどう扱うべきか
  8. どこまでやったら止めるべきか

特に重要なのは、3つ目です。

AIに任せる範囲を広げるほど、制約と評価基準を明確にする必要があります。逆に、制約が曖昧なまま自由度だけを上げると、もっともらしいが使いにくいアウトプットになります。

まとめ

GPT-5.5で変わるのは、プロンプトのテクニックではありません。AIとの仕事の分担です。

これからのプロンプト力は、うまい言い回しではなく、業務を定義する力です。

これは、多くの職種で本来求められてきた仕事に近い変化です。課題を定義し、制約を整理し、判断可能な成果物に落とす。その能力が、そのままAI時代のプロンプト設計力になります。

特別章: APIで使う場合だけ意識すること

ここまでの内容は、ChatGPTのような画面でAIを使う人にもそのまま使えます。

一方で、APIを使ってアプリケーションや社内ツールに組み込む場合は、プロンプトだけですべてを制御しようとしないことも重要です。

制御したいこと プロンプトに書くこと API側で調整すること
目的、制約、成功条件 書く 書かない
出力の長さ 目安を書く text.verbosityなどで調整
思考の深さ 必要な判断条件を書く reasoning.effortなどで調整
ツール利用 使ってよい範囲を書く ツール設定で制御
厳密な出力形式 目的と利用場面を書く Structured Outputsで検証する
長い共通指示 安定した方針だけを書く prompt cachingを意識して前方に置く

プロンプトは、仕事の契約です。APIのパラメータは、働き方の設定です。この2つを分けて考えると、プロンプトは短く、保守しやすくなります。

たとえばJSONの項目を厳密に守らせたい場合、すべてを自然文で長く説明するより、API側のStructured Outputsを使うほうが安定します。長い共通プロンプトを何度も使う場合は、変わらない指示を前に、ユーザーごとに変わる文脈を後ろに置くと、prompt cachingの効果も得やすくなります。

また、現在日付を毎回system promptに入れる必要は基本的にありません。業務上のタイムゾーン、会計年度、制度適用日などが重要なときだけ、明示すれば十分です。

参考

© 2026 Keith Chen. All rights reserved.