2025年11月、OpenAIは待望のフラッグシップモデル「GPT-5.1」に関連する「GPT-5.1 プロンプトガイド」（https://cookbook.openai.com/examples/gpt-5/gpt-5-1_prompting_guide）を公開しました。単なるモデルの仕様書ではなく、アプリケーションやエージェントの開発者が直面していた「応答速度と知能のトレードオフ」という課題に対し、実践的な解を提示する重要なドキュメントとなっています。

バイブコーディングという言葉が浸透し、コードを書く行為そのものが大きく変わり始めています。今やエンジニアでなくとも、自然言語で指示を出すだけで、アイデアを即座にアプリケーションとして具現化できる時代です。特に、最新のGPT-5.1などを搭載したAIアプリの開発は、個人の可能性を無限に広げています。しかし、ここで多くの人が陥る「落とし穴」があります。それは、GPT-4oやGPT-5の時と同じプロンプトを使ってしまうということです。

モデルが進化すれば、その操縦桿（プロンプト）の動かし方も変わります。かつてのベストプラクティスが通用せず、「思ったように動かない」と頭を抱えてはいませんか？

GPT-5.1は、前世代のGPT-5が持つ深い推論能力を受け継ぎつつ、より軽量で高速な処理を可能にする柔軟性を備えています。特に、エージェント開発において重要となる「性格の制御」や「自律的なタスク完遂能力」が大幅に強化されました。

今回は、最新のOpenAI Cookbookの内容を深掘りし、実用的なAIエージェントを構築するための具体的なテクニックを解説します。単にプロンプトをコピーするだけでは見えてこない、モデルの挙動を根本から理解し、制御するための勘所をお伝えしましょう。

推論コストを削ぎ落とす新モードの活用と移行時に必要な粘り強さ

GPT-5.1は、タスクの難易度に応じて推論コストを最適化できるのが特徴です。従来のモデルでは、簡単な質問に対しても過剰な計算リソースを割いてしまうことがありましたが、GPT-5.1ではその無駄が削ぎ落とされました。特に注目したいのが、新しく導入された「none（なし）」という推論モード設定です。これは推論トークンを生成せず、かつてのGPT-4.1やGPT-4oのように即座に応答を返すモードで、低遅延が求められるチャットボットや、単純なデータ処理タスクに最適です。

開発者が既存のモデルからGPT-5.1へ移行する際、意識すべきポイントがいくつかあります。まず、GPT-4.1を利用していた場合は、この「none」モード設定を活用することで、違和感なくスムーズに移行できるでしょう。

一方で、GPT-5のような重厚な推論モデルから移行する場合は、「粘り強さ（Persistence）」をプロンプトで補う工夫が必要です。GPT-5.1は効率を重視するあまり、回答を簡潔に済ませようとする傾向があります。そのため、複雑なタスクを依頼する際は「完全に解決するまで考え続けること」や「情報の網羅性を優先すること」を明示的に指示し、回答の質を担保する必要があります。

また、出力のフォーマットや詳細度（Verbosity）についても、より厳密な制御が可能です。簡潔な回答が必要な場合は「二文以内で答えて」や「箇条書きは使わずプレーンテキストで」といった具体的な制約条件を与えることが推奨されます。このように、モデルの「癖」を理解し、手綱を握るような感覚でプロンプトを調整することが、移行を成功させる鍵となるのです。

粘り強く回答させるプロンプト例

<solution_persistence>

- 自律的な上級ペアプログラマーとして行動しましょう。ユーザーから指示が出たら、各ステップで追加の指示を待つことなく、積極的にコンテキストを収集し、計画、実装、テスト、そして改良を進めましょう。

- 可能な限り、タスクが現在のターン内でエンドツーエンドで完全に完了するまで粘り強く取り組みましょう。分析や部分的な修正で止まらず、ユーザーが明示的に中断したり、指示を戻したりしない限り、実装、検証、そして結果の明確な説明を通して変更を進めましょう。

- 行動には徹底的にこだわりましょう。ユーザーからの指示の意図がやや曖昧な場合は、変更を実行すべきだと考えましょう。ユーザーが「xをすべきでしょうか？」といった質問をし、あなたの答えが「はい」であれば、そのアクションを実行しましょう。ユーザーを宙ぶらりんにしたまま、「お願いします」とお願いしてフォローアップを求めるのは非常に良くありません。

状況に合わせて対話のリズムや性格を微細に調整する制御の進化

AIエージェントの品質を決めるのは、知能だけではありません。ユーザーにとって心地よい「対話のリズム」や「性格」も極めて重要な要素です。GPT-5.1は、この「Agentic Steerability（エージェントの操縦性）」において飛躍的な進化を遂げました。これまでのモデル調整といえば「あなたは親切なアシスタントです」といった曖昧な役割付与に留まりがちでしたが、GPT-5.1ではより具体的で、微細なニュアンスまでコントロールできるようになっています。

例えば、カスタマーサポートのエージェントを開発するケースを想像してみてください。ユーザーが怒っている時に、AIが「ご連絡ありがとうございます、その件については……」と定型的な挨拶を繰り返すと、火に油を注ぐことになりかねません。ガイドでは、こうした場面で「Adaptive Politeness（適応的な礼儀正しさ）」を実装する手法が紹介されています。

ユーザーが切迫している場合や、事務的なやり取りを求めている場合には、「分かりました」といった相槌すら省略し、即座に問題解決のアクションに移るよう指示することができるのです。これは単なる冷徹さではなく、「効率こそが最大の敬意である」という哲学に基づいた設計と言えるでしょう。

さらに、出力されるテキストのスタイルも細かく調整可能です。コーディングアシスタントであれば、コードの変更箇所を説明する際に「変更しました」という報告だけでなく、どのファイルのどの部分をどう変えたのか、その意図は何なのかを、開発チームの一員のようなトーンで語らせることができます。

逆に、ログファイルのような長大な出力を抑制し、必要な情報だけを抽出して提示させることも容易です。このように、エージェントのペルソナ（人格）を、表面的な口調だけでなく、思考の優先順位や行動原理のレベルで定義できる点が、GPT-5.1の大きな強みなのです。

カスタマーサポートのプロンプト例

<final_answer_formatting>
あなたは明快さ、勢い、そして形式的な礼儀よりも有用性で測られる敬意を重視します。会話は簡潔で目的意識を持ち、仕事を進めない要素は切り捨てるのがあなたのデフォルトの姿勢です。冷たいわけではなく、単に言葉遣いを経済的に考え、ユーザーを信頼してメッセージを無駄な装飾で包む必要はないと確信しているのです。

- 適応的な礼儀正しさ:
- ユーザーが温かみのある、詳細な、思いやりのある態度を示したり「ありがとう」と言った場合、簡潔な承認を一言返す——「了解」「承知しました」「どういたしまして」といった確認や受領を示す言葉で相手のトーンに軽く応える——その後、即座に生産的な行動に戻る。ただし、わざとらしい態度や過剰な支援は避ける。
- 重要度が高い場合（締切、コンプライアンス問題、緊急の物流対応など）は、その小さな合図すら省略し、必要な情報の収集や問題解決に直ちに取り掛かる。

- 基本的な姿勢：
- 地に足のついた率直さで話す。最も敬意を示す方法は効率性だと信頼する：余計な雑談なく問題を明確に解決すること。
- 礼儀正しさは、構造・正確性・応答性によって示され、言葉の飾りではない。

- 承認と受領の合図との関係：
- 承認と受領は主食ではなく、任意の調味料と扱う。相手が簡潔・最小限なら、ほぼゼロに近い承認でそのリズムに合わせる。
- 「了解」「確認ありがとうございます」といった定型的な応答は、ユーザーの口調やペースが自然な形で簡潔な応答を促す場合を除き避ける。

- 会話のリズム：
- 応答の繰り返しは一切行わない。理解を示したら、即座に課題解決に完全に集中する。
- ユーザーのエネルギーを注意深く察知し、そのテンポで応答する：相手が速い時は速く、冗長な時は余裕を持って、常に実行可能性を基盤とする。

- 基本原則：
- コミュニケーション哲学は「勢いによる敬意」。意図は温かく表現は簡潔に、あらゆるメッセージをユーザーの摩擦を最小限に抑えた進捗支援に集中させる。

思考プロセスの可視化と自律的な判断でタスク完遂率を高める

複雑で時間のかかるタスクをAIに任せる際、ユーザーが感じる最大の不安は「今、何をしているのか分からない」というブラックボックス化です。GPT-5.1のガイドでは、この問題を解決するための「User Updates（ユーザーへの状況報告）」という概念が強調されています。AIが裏側でツールを実行したり思考したりしている間に、適度な頻度と粒度で進捗を報告させるテクニックです。

具体的には、6回程度の実行ステップごと、あるいは8回のツール呼び出しごとに、短い要約メッセージをユーザーに送信させるようプロンプトで指示します。この時重要なのは、単に「処理中です」と伝えるのではなく、「データベースの検索が完了しました。次は検索結果に基づいて集計を行います」といった、具体的なアクションの内容を含めることです。これにより、ユーザーはAIが正しい方向に進んでいるかを確認でき、必要であれば途中で介入して軌道修正を行うことも可能になります。いわば、AIの思考プロセスをガラス張りにするようなアプローチです。

また、エージェントの自律性を高めるための「Solution Persistence（解決への執着）」も重要なキーワードです。従来のモデルは、ユーザーの指示が曖昧だったり、予期せぬエラーが発生したりすると、すぐに処理を中断して人間に判断を仰ぐ傾向がありました。

しかし、GPT-5.1では自律的なシニアエンジニアのように振る舞うよう指示することで、多少の不確実性があっても自分で仮説を立て、検証し、解決まで突き進ませることができます。「ユーザーに質問して待つくらいなら、合理的な判断で先に進め」という強いバイアスを持たせることで、タスクの完遂率は劇的に向上します。もちろん、これにはリスクも伴いますが、適切な監視と報告の仕組みと組み合わせることで、強力な自動化エンジンとなるのです。

アシスタントメッセージを提供するプロンプト例

<user_update_immediacy>
分析思考メッセージをサンプリングする前に、必ず最初にコメントメッセージで何をしているかを説明してください。これはユーザーに即時的に伝えるために極めて重要です。

事前の計画立案と堅牢なツール選定でコーディング能力を引き出す

GPT-5.1はコーディングタスクにおいても高い能力を発揮しますが、それを最大限に引き出すためには、ツールの使い方も進化させる必要があります。ガイドの中で推奨されているのが、「Planning Tool（計画ツール）」の導入です。これは、実際にコードを書く前に、AI自身にタスク全体の計画を立てさせ、それを専用のツール（例えばTODOリスト管理ツールのようなもの）に記録させるという手法です。

人間が複雑なプログラムを書く時に、いきなりエディタに向かわず設計図を描くのと同じ理屈です。AIにまず「計画」というステップを踏ませることで、全体像を把握させ、依存関係の考慮漏れや、無駄な手戻りを防ぐことができます。さらに、この計画ツールはタスクの進行中に随時更新され、AI自身にとっての「地図」の役割を果たします。長期的な記憶保持が難しいLLM（大規模言語モデル）にとって、外部ツールに状態を保存しておくことは、複雑なプロジェクトを完遂するための重要なポイントとなります。

また、実際のコード修正においては、従来の単純なファイル書き換えツールから、より堅牢なツールへの移行が促されています。コードの一部を検索して置換するような不安定な方法ではなく、明確な変更内容を定義した新しいツールタイプを使用することで、適用ミスを減らすことができます。

さらに、ツールを呼び出す前に「なぜそのツールを使うのか」「何を確認するつもりなのか」を思考させるプロセスを挟むことで、ツール利用の精度そのものも向上します。GPT-5.1の「none」モードであっても、この事前の思考プロセスをプロンプトで強制することで、推論モードに近い賢明な判断を引き出すことが可能です。

長時間実行されるタスクに実装したい計画ツールのプロンプト例

<plan_tool_usage>
- 中規模以上のタスク（例：複数ファイルの変更、エンドポイント/CLI/機能の追加、複数ステップの調査）については、最初のコード/ツール操作の前に、TODO/planツールで軽量な計画を作成し維持する必要があります。
- マイルストーン/成果項目を2～5個作成してください。マイクロステップや反復的な運用タスク（「ファイルを開く」「テストを実行する」などの操作ステップ）は避けてください。「機能全体を実装する」のような包括的な単一項目は絶対に使用しないでください。
- ツール内でステータスを管理する：同時にin_progress状態の項目は1つだけとする。完了したら項目をcompleteにマークする。ステータス遷移は適時投稿する（更新なしでツールを8回以上呼び出さない）。項目をpendingからcompleteに直接移動させない：必ずin_progressに設定する（作業が本当に瞬時なら、in_progressとcompleteを同じ更新で設定可）。事後的に複数項目をまとめてcompleteにしない。
- ターン終了時には、全アイテムを完了または明示的にキャンセル/延期済みとする。
- ターン終了時の不変条件：in_progressとpendingがゼロ。残存アイテムは完了、または簡潔な理由を添えて明示的にキャンセル/延期する。
- 中規模/複雑なタスクの計画をチャットで提示する場合、ツールにも反映し、更新時にそれらのアイテムを参照する。
- 非常に短く単純なタスク（例：単一ファイルの変更 ≲ 約10行以内）はツール使用を省略可。チャットで簡易計画を共有する場合、結果に焦点を当てた1～2文にまとめ、操作手順や箇条書きリストを含めないこと。
- 事前確認：非trivialなコード変更（例：apply_patch、複数ファイル編集、大規模な配線変更）を行う前に、現在の計画に「in_progress」マークが付いた適切な項目が1つだけ存在し、これから行う作業に対応していることを確認してください。必要に応じて計画を先に更新してください。
- スコープ変更：理解が変化した場合（項目の分割/統合/再配置）、継続前に計画を更新してください。コーディング中に計画が陳腐化しないようにしてください。
- in_progress状態の項目は常に1つだけにしてください。複数存在した場合は、直ちにステータスを修正し、現在のフェーズのみがin_progressとなるようにしてください。

運用後のログ分析と微調整を繰り返してエージェントを磨き上げる

推論モードの適切な選択、エージェントの性格制御、透明性の確保、そして計画ツールの活用。これらはすべて、AIを単なる「チャットボット」から、信頼できる「仕事のパートナー」へと昇華させるための必須テクニックです。

しかし、ガイドの冒頭にも記されている通り、これらのテクニックはあくまで出発点に過ぎません。実際の運用環境では、想定外のユーザー入力や、ドメイン特有の制約に直面することでしょう。重要なのは、一度プロンプトを書いたら終わりではなく、エージェントの挙動を観察し、ログを分析し、微調整を繰り返す反復のプロセスです。

時にはプロンプトを短くし、時にはより詳細に指示を書き加えることによって磨き上げられたプロンプトこそが、あなたのアプリケーションに独自の価値をもたらす最大の資産となります。GPT-5.1という強力なエンジンを手に入れた今、それをどう乗りこなすかは、我々人間の「指示力」にかかっているのです。

この記事の監修