グラレコ
上のグラレコは、この記事で扱う GPT-6.1 Sol のプロンプティングガイドの要点を1枚にまとめたものです。何が変わったのか、プロンプトの基本構造、reasoning effort の選び方、コーディング・エージェント・computer use の書き方、長いコンテキストとキャッシュの設計、そして移行の流れまでを8つのブロックに並べています。細かい話は本文で1つずつ見ていくので、まずは全体の地図としてざっと眺めてみてください 🗺️
はじめに
GPT-6.1 Sol は、OpenAI の GPT-6 ファミリーに加わった Sol クラスの新モデルです（元記事によると、公開日は 2026年9月29日です）。API のモデル ID は gpt-6.1-sol で、公式のモデルページでは「Near-Astra performance for complex work at a lower cost（複雑な仕事で Astra に近い性能を、より低いコストで）」と紹介されています。価格は GPT-6 Sol と同じ入力 $2 / 出力 $10（100万トークンあたり）のまま、キャッシュ入力は $0.20 から $0.10 に下がりました。
2026年9月30日、プロンプト生成ツールを提供している PrompTessor のブログに「How to Prompt GPT-6.1 Sol: Best Practices, Reasoning, and Examples」（Rizki Murtadha 著、2026年9月30日）というガイドが掲載されました。reasoning effort の選び方から、用途別のプロンプト例10本、よくあるミス、GPT-6 Sol からの移行手順までをまとめた、かなりボリュームのある記事です。
この記事では、そのガイドの内容を日本語で整理し直して紹介します。ガイド全体を貫くメッセージは、次の一文に集約されています。
GPT-6.1 Sol 向けの良いプロンプトは、台本（script）というより契約書（contract）のように機能するべきです。
手順を一つひとつ指示する「台本」ではなく、ゴール・境界・検証・止めどころを取り決める「契約書」として書く、という考え方です。この記事もこの軸に沿って進めます 📜
この記事でわかること 📌
- GPT-6.1 Sol の位置づけと、GPT-6 Sol から変わった点（
none廃止・ツール呼び出しは Responses API 必須・キャッシュ値下げ） - 「契約書型」プロンプトの9つの構成要素と、タスクのリスクに応じた使い分け
- reasoning effort（
low〜max）の選び方と、会話の途中で effort を変えるconfiguration_update - コーディング、エージェント、ツール／MCP、computer use、PDF、長文コンテキスト、Structured Outputs、検証、キャッシュの各場面のプロンプト設計
- 用途別テンプレート10本の要点と、よくある10のミス
- GPT-6 Sol から移行するときの8ステップ、Astra との使い分け、プロンプトの評価のしかた
想定読者は、OpenAI API（特に Responses API）でエージェントやコーディング支援、業務自動化を作っている開発者の方です。すでに GPT-6 Sol を本番で使っていて、6.1 Sol への切り替えを検討している方には特に役立つ内容になっています。
GPT-6.1 Sol とは：ファミリーの中での立ち位置 🌞
まずはモデルの立ち位置から押さえておきます。OpenAI の「Using GPT-6」ガイドでは、GPT-6 ファミリーを次の3つに分けて紹介しています。
| モデル | 公式の一言紹介 | 向いている仕事 |
|---|---|---|
| GPT-6 Astra | Highest intelligence（最高の知性） | 最も負荷の高い推論・コーディング・専門業務 |
| GPT-6.1 Sol | Balanced speed, cost, and intelligence（速度・コスト・知性のバランス） | 複雑な仕事を、Astra に近い性能かつ低コストで |
| GPT-6 Luna | Fastest and most cost-effective（最速・最安） | 焦点の絞られた大量処理タスク |
以前のファミリー構成では、Sol の枠には GPT-6 Sol が入っていました。今回それが GPT-6.1 Sol に置き換わった形です。価格帯を並べると、次のような位置関係になります。
この図のポイントは、6.1 Sol が「真ん中」でありながら、上の Astra にかなり寄せてきているという点です。入力・出力のトークン単価は Astra の5分の1のまま、複雑なコーディングや computer use、専門的なドキュメント作業で Astra に近づくことを狙ったモデルになっています。
元記事では、OpenAI の発表として次のようなベンチマーク結果が紹介されています（いずれも元記事が紹介する OpenAI の発表値で、この記事では一次情報を直接確認できていません）。
- DeepSWE v1.1: GPT-6 Sol のベストスコアを 6.4 ポイント上回り、しかもより低い reasoning effort で達成
- AutomationBench（営業・マーケ・サポート・経理・人事などのツールをまたぐ業務ワークフロー）: medium effort で GPT-6 Sol から 4.8 ポイント向上
- OSWorld 2.0 オフラインセット（computer use）: max effort で 7 ポイント向上
- 事実性の評価（わざと誤りを誘う難しいプロンプト集）: low effort で「事実誤りを1つ以上含む回答」の割合が 11.4% から 7.7% に低下
元記事自身も「特定の評価設定での結果であり、すべての本番ワークロードが同じだけ改善する保証ではない」と念を押しています。事実性の評価についても、OpenAI が「これらのプロンプトは典型的な利用を代表するものではない」と明記していることが紹介されています。数字はあくまで「伸びた領域の目安」として受け取っておくのがよさそうです 📊
提供状況
API では gpt-6.1-sol として利用できます。ChatGPT では Work と Codex で利用でき、通常の Chat の会話では使えません（OpenAI の Codex Models ページに「In ChatGPT, GPT-6.1 Sol, GPT-6 Sol, and GPT-6 Luna are available in Work and Codex. They aren't available in Chat.」と記載があります）。
同じページによると、ローンチ時の提供対象は Plus・Pro・Business・Enterprise・Edu プランで（Codex はデスクトップアプリと CLI、ChatGPT Work は Web とモバイル）、Free と Go は対象外です。Enterprise と Edu では、管理者が有効にするまでオフになっています。Codex CLI からは、次のようにモデルを指定して使えます。
codex --model gpt-6.1-sol
codex exec -m gpt-6.1-sol "Review the current changes"
GPT-6 Sol から何が変わったか 🔄
ここがこのガイドで一番大事な前提です。元記事は冒頭で「GPT-6.1 Sol は、マイナーバージョンが上がっただけの GPT-6 Sol ではない」と書いています。性能が上がっただけでなく、ランタイムの前提がいくつか変わっているからです。
公式ドキュメントと照合したうえで、変更点を表にまとめました。
| 項目 | GPT-6 Sol | GPT-6.1 Sol |
|---|---|---|
| reasoning effort |
none / low / medium / high / xhigh / max
|
low / medium / high / xhigh / max（none と minimal は非対応） |
| デフォルトの effort | medium |
medium |
| ツール呼び出し | Responses 推奨。Chat Completions での function calling は none のときのみ |
Responses API が必須（Chat Completions はツールなしのリクエストのみ） |
| 入力 / 100万トークン | $2 | $2 |
| キャッシュ入力 / 100万トークン | $0.20 | $0.10 |
| 出力 / 100万トークン | $10 | $10 |
| コンテキストウィンドウ | 1,050,000 | 1,050,000 |
| 最大出力 | 128,000 | 128,000 |
| ナレッジカットオフ | 2026年4月20日 | 2026年4月30日 |
📝 元記事の比較表では、GPT-6 Sol のデフォルト effort が「Configuration-dependent（設定次第）」となっていますが、OpenAI の GPT-6 Sol モデルページ には
medium（default）と明記されています。この記事では公式の値を採用しました。
表を見ると、価格・コンテキスト・最大出力はほぼそのままで、プロンプトの書き方や運用に効いてくる変更は「effort の選択肢」「ツール呼び出しの API」「キャッシュ単価」の3点だとわかります（ナレッジカットオフも10日ほど新しくなっています）。この3つを図にすると次のようになります。
元記事はここから、とても実務的な教訓を引き出しています。
移行で学ぶべきことは「すべてのプロンプトを長くする必要がある」ということではありません。ランタイムの前提が変わったということです。
たとえば、GPT-6 Sol で速度のために none を使っていたアプリは、モデル ID を書き換えただけでレイテンシもコストも挙動も変わります。ツールを使っているなら API の移行がセットで必要になります。逆に、古いモデルのクセを補うために書き足してきた細かい手順指示は、6.1 Sol では簡略化できるかもしれません。元記事が「既存の設定をそのままコピーするのではなく、再評価すべき」と繰り返しているのはこのためです。
プロンプト設計に効くスペック 📐
元記事は「プロンプティングに関係するスペック」として、仕様を一覧にしています。公式のモデルページで補足しながら整理するとこうなります。
| 項目 | 値 |
|---|---|
| モデル ID | gpt-6.1-sol |
| コンテキストウィンドウ | 1,050,000 トークン |
| 最大入力トークン | 922,000 トークン（公式モデルページ） |
| 最大出力トークン | 128,000 トークン |
| ナレッジカットオフ | 2026年4月30日 |
| 入力モダリティ | テキスト・画像（音声・動画は非対応） |
| reasoning effort |
low / medium（デフォルト）/ high / xhigh / max
|
| Structured Outputs | 対応 |
| function calling | Responses API 経由で対応 |
| 使えるツール（Responses API） | web search、file search、image generation、code interpreter、hosted shell、apply patch、skills、computer use、MCP、tool search |
| ファインチューニング | 非対応 |
「1.05M コンテキスト」という数字が目立ちますが、1回のリクエストで入れられる入力の上限は 922,000 トークンです。残りは出力側のぶんと考えておくと混乱しにくいです。
もう1つ大事なのが、長いコンテキストの料金境界です。入力が 272K トークンを超えると、そのリクエスト全体の入力・キャッシュ料金が2倍、出力料金が1.5倍になります。
境界を超えた「超えた分だけ」ではなく、リクエスト全体が割増になるのがポイントです。元記事が「1.05M のコンテキストウィンドウは、手持ちのドキュメントを全部のリクエストに入れてよいという許可ではない」と書いているのは、この料金体系を踏まえてのことです 💸
料金まわりは公式モデルページにもう少し細かい記載があるので、補足しておきます。
- キャッシュ入力は、通常の入力単価の 5%（$0.10）
- キャッシュ書き込みは、通常の入力単価の 1.25 倍（$2.50）
- Batch と Flex は Standard より 50% 安い
- Fast モードは Standard の 2 倍
- Regional processing（地域処理）は、利用できる場合 10% 上乗せ
- EU データレジデンシーでは Fast モードが使えない
基本構造：プロンプトは「台本」ではなく「契約書」📜
ここからが本題のプロンプト設計です。元記事は、複雑なタスク向けのプロンプトの骨組みとして、次の9つの要素を挙げています。
| 要素 | 書くこと |
|---|---|
| OUTCOME（成果） | 何を達成しなければならないか |
| CONTEXT（文脈） | どの事実・ファイル・記録・制約が関係するか |
| BOUNDARIES（境界） | 何が起きてはいけないか |
| TOOLS（ツール） | 使える機能は何か。何を自動で使ってよく、何に承認が要るか |
| DECISION RULES（判断ルール） | 曖昧さ・データ欠損・矛盾をどう扱うか |
| SUCCESS CRITERIA（成功条件） | 何を満たせばタスク完了か |
| VERIFICATION（検証） | 結果を受け入れる前に何を確認するか |
| STOP / ESCALATE（停止・エスカレーション） | いつ止まる・聞く・人に戻すか |
| OUTPUT（出力） | 最終的にどんな成果物を返すか |
各要素の関係を図にすると、次のような流れになります。
この図で見てほしいのは、「どうやるか（手順）」を書く欄がないことです。書くのはゴール、境界、判断のルール、完了と検証の条件、止めどころです。元記事の冒頭にある「結果・境界・使える証拠・ツール・検証ルール・停止条件を明確に定義し、そのうえで効率的な道筋を選ぶ余地をモデルに与える」という一文が、この構造の狙いをよく表しています。
全部の要素を毎回書く必要はない
元記事は、ここで大事な注意を添えています。
これらのセクションを、すべてのプロンプトに機械的に追加しないでください。
単純なコーディングタスクなら、成果・文脈・制約・テスト・出力だけで足ります。一方で、外部の状態を変えられる「ツールを使う本番エージェント」には、境界をもっと明示的に書く必要があります。プロンプトの構造は、固定のテンプレート長ではなく、タスクのリスクと複雑さに合わせる、というのが元記事の結論です。
元記事が挙げているのは「単純なタスク」と「外部の状態を変えるエージェント」の両端だけなので、その間の段階も含めて筆者なりに整理すると、次のようになります。
「全部入りのテンプレートを作って、毎回それを埋める」という運用はよく見かけますが、このガイドの考え方とは少し違います。リスクの低いタスクに9要素を全部書くと、プロンプトが長くなるだけで、かえって大事な指示が埋もれてしまいます。
まずはこの形から
元記事の「Quick Answer」では、ほとんどの複雑なタスクの出発点として、次の8セクションの形を紹介しています。日本語に訳すとこうなります。
GOAL（ゴール）
達成したい結果を書く。
CONTEXT（文脈）
モデルが必要とする情報だけを渡す。
CONSTRAINTS（制約）
要件・境界・禁止事項を定義する。
TOOLS（ツール）
使えるツールと、それをいつ使うべきかを説明する。
SUCCESS CRITERIA（成功条件）
正しい結果が満たすべきことを定義する。
VERIFICATION（検証）
証拠・ツールの結果・テスト・元資料との照合を求める。
STOP / ESCALATE（停止・エスカレーション）
いつ止まる・聞く・エスカレーションするかを説明する。
OUTPUT（出力）
最終成果物の形式と詳しさを指定する。
見出しは英語のまま使っても、日本語にしても構いません。大事なのは「何を書くべき欄なのか」が揃っていることです ✍️
reasoning effort の選び方 🎛️
GPT-6.1 Sol の reasoning effort は5段階です。元記事は、それぞれの「出発点としての使いどころ」を次のように整理しています。
| effort | 出発点として向いている用途 |
|---|---|
low |
コストやレイテンシに敏感な推論、範囲の決まった抽出、素直なコード変更、単純なツール判断 |
medium（デフォルト） |
コーディング・分析・ツール利用・業務ワークフロー・一般的な本番利用のバランスの良い出発点 |
high |
難しいデバッグ、複雑な計画、曖昧な証拠、複数ステップのエージェントワークフロー |
xhigh |
非常に難しい非同期の推論、コードベースの深い調査、複雑なリサーチやオーケストレーション |
max |
レイテンシとコストより品質が優先される、まれな最難関タスク |
OpenAI 公式の Model selection ガイドにも、モデルと effort の組み合わせごとの目安があります。6.1 Sol に関係する部分を抜き出すと、こうなります。
- GPT-6.1 Sol · Medium: 複雑な技術作業や、修正を重ねる前提の連携した成果物（coordinated deliverables）
- GPT-6.1 Sol · Extra high: 磨き込んだ成果物、つながりのあるビジュアルシステム、矛盾する証拠からの意思決定
推奨の進め方：medium から始めて、測ってから動かす
元記事のおすすめは、とてもシンプルです。
- モデルのデフォルトである
mediumから始める - コストやレイテンシが気になるなら
lowをベンチマークする - 評価セットで測定可能な改善が見えたときだけ、
high/xhigh/maxに上げる
この図で特に大事なのは、一番下の「改善がなければプロンプト側を見直す」という分岐です。元記事には「effort を上げれば本番の品質が自動的に上がると思い込まないでください」という注意があります。その根拠として挙げられているのが、先ほどの DeepSWE の結果です。6.1 Sol は、6 Sol のベストスコアをより低い effort で上回ったと紹介されています。
reasoning effort は「最大を既定にするもの」ではなく、本番のパラメータとしてベンチマークするものとして扱いましょう。
元記事のこの一文は、そのまま運用ルールとしてチームに貼っておけるくらいわかりやすいと思います 🙂
会話の途中で effort を変える：configuration_update
元記事には出てきませんが、effort の運用でぜひ知っておきたい公式機能があります。GPT-6 ファミリーで使える configuration_update です。
たとえば「最初の計画は low でざっと作り、障害モードの分析だけ high で深く考えてほしい」というケースを考えます。リクエストごとに reasoning.effort を書き換えると、プロンプトのプレフィックスが変わってキャッシュが効きにくくなります。configuration_update を使うと、リクエストレベルの reasoning.effort は固定したまま、次の応答以降の effort だけを変えられます。
公式の Reasoning ガイドにある例を、モデル ID だけ 6.1 Sol に置き換えて示します。
import OpenAI from "openai";
const client = new OpenAI();
const model = "gpt-6.1-sol";
const first = await client.responses.create({
model,
reasoning: { effort: "low" },
input: "Draft a database migration plan.",
});
const next = await client.responses.create({
model,
reasoning: { effort: "low" }, // リクエストレベルの設定は変えない
previous_response_id: first.id,
input: [
{ type: "configuration_update", reasoning: { effort: "high" } },
{
role: "user",
content: "Analyze the failure modes and propose rollback steps.",
},
],
});
console.log(next.output_text);
流れを図にすると、次のようになります。
使うときの注意点も、公式ドキュメントからいくつか拾っておきます。
- 対応しているのは、GPT-6 ファミリーの標準のシングルエージェントモードで、変えられるのは reasoning effort だけです
- 更新は、別の
configuration_updateで上書きされるまで、以降の応答に適用されます -
configuration_updateを2つ連続して並べると、API が拒否します - 自動 compaction や自動 truncation とは併用できません（明示的な
compaction_triggerは使えて、その後に新しいconfiguration_updateを入れ直します） - レスポンスの
reasoning.effortには、更新後の値ではなく、リクエストレベルの値が表示されます
none がもう使えない件 ⚠️
元記事が「GPT-6 Sol との最も重要な違いの1つ」として強調しているのが、none の廃止です。公式の Using GPT-6 ガイドにも「GPT-6 Astra と GPT-6.1 Sol は none をサポートしない。GPT-6 Sol と GPT-6 Luna はサポートする」と明記されています。
reasoning_effort: "none" を使っていたアプリの移行先は、「同じ挙動で、モデル名だけ新しくなる」ではありません。公式の移行ガイドでは、none の代わりに low を使うよう書かれています。元記事はそこからもう一歩進めて、low から始めたうえで代表的なタスクで結果を比較し直すことを勧めています。
📝 元記事は「
noneやminimalを使っていたワークロード」とまとめて書いていますが、GPT-6 Sol の effort の選択肢にはminimalはありません。minimalは GPT-6 より前のモデルから移行してくるケースの話です（公式の移行ガイドも「既存のリクエストがminimalを使っているならlowから始めて比較する」という書き方になっています）。
none → low は、推論トークンが発生するようになるという意味で、地味に大きな変化です。元記事は、大量処理のアプリでは次の項目をエンドツーエンドでテストし直すよう勧めています。
- エンドツーエンドのレイテンシ
- トークン使用量
- ツール呼び出しの回数
- タスク成功率
- 成功したタスク1件あたりのコスト
最後の「成功1件あたりのコスト」は、このガイドに何度も出てくる大事な指標です。単価が安くても、失敗してリトライしたり人がレビューし直したりするなら、トータルでは高くつくからです。
用途別のプロンプト設計 🧰
ここからは、元記事が用途別に紹介しているプロンプトの書き方を順に見ていきます。プロンプト例は、元記事のテンプレートを日本語に訳して要約したものです。
コーディングとデバッグ 🧑💻
元記事は、コーディングを「6.1 Sol の改善が最もはっきりしている領域の1つ」と位置づけています。そのうえでのアドバイスは、目標の挙動と検証の基準は定義する。でも実装のステップを細かく指示しすぎない、というものです。
元記事の例は、「アクセストークンの期限切れ後に、有効なリフレッシュトークンが拒否される認証の不具合を直す」というタスクです。要点を日本語でまとめると、次のような構成になっています。
ゴール:
アクセストークン期限切れ後に、有効なリフレッシュトークンが
拒否される認証のリグレッションを修正する。
文脈:
- Next.js アプリケーション
- 認証コードは /src/auth と /src/api にある
- 既存の公開 API の挙動は後方互換を保つ
- 必要がない限り DB スキーマは変えない
進め方:
- 編集の前に関連コードとテストを読む
- 根本原因を特定する
- 最小限で一貫した修正を選ぶ
- 既存のヘルパーやパターンを再利用する
- テストを通すためにセキュリティチェックを弱めない
検証:
- 関連する認証テストを先に実行する
- リグレッションテストを追加・更新する
- 必要なら型チェックと lint を実行する
- 実行できなかったテストは報告する
返すもの:
1. 根本原因 2. 変更ファイル 3. 変更内容 4. 実行したテストと結果 5. 残るリスク
ポイントは3つあります。
- 「テストを通すためにセキュリティチェックを弱めない」のように、やりがちな近道を明示的に禁止しています
- 「実行できなかったテストは報告する」で、検証できなかったことを隠させないようにしています
- 返すものに「残るリスク」が入っていて、完了報告が楽観的になりすぎないようにしています
大きなリポジトリでのデバッグについては、元記事は「失敗と証拠を定義したうえで、探索をいつ止めるかを伝える」ことを勧めています。証拠から仮説を立て、検証し、違っていたら仮説を修正する、というループです。
この図の「再現できない」側の出口が、地味ですが大事です。元記事のテンプレートには「障害を再現できない場合は、最も有力な仮説と、次に必要な診断上の証拠を返す」とあります。終わり方を決めておかないと、モデルは推測で修正を入れてしまうかもしれません。「デバッグ中に無関係なコードをリファクタリングしない」という一文も、地味に効く指示です 🔍
エージェントワークフロー 🤖
元記事は、エージェント向けのプロンプトについて「役割とタスクだけでは足りない」と書いています。例として挙がっているのは、サポート案件を処理するエージェントです。構成要素を日本語でまとめると次のようになります。
| セクション | 内容（要約） |
|---|---|
| GOAL | サポート案件を正確かつ効率的に解決する |
| AVAILABLE CONTEXT | チケット履歴、顧客レコード、注文状態、現行ポリシー |
| TOOLS |
get_customer、get_order、search_policy、create_refund_request、update_ticket
|
| TOOL POLICY | 現在の状態が必要なら読み取りツールを使う／アカウントやポリシーの事実を推測しない／新しい情報がないのに同等のツール呼び出しを繰り返さない／書き込み後は可能なら新しい状態を取得して確認する |
| AUTHORITY | 自動で進めてよいもの・承認が要るものを分ける（下図） |
| VERIFICATION | 完了前に最終的なアカウント／注文状態を確認し、回答が確認済みの状態と一致しているか、未解決の不確実性がないかを見る |
| STOP / ESCALATE | 必要な権限がない、顧客の本人確認が曖昧、ポリシーの証拠が矛盾、試行が繰り返し失敗、のいずれかで質問・エスカレーション |
この中で一番参考になるのが AUTHORITY（権限） の切り分けです。図にすると次のようになります。
「読む」「下書きする」は自動でよく、「お金や権利が動く」ものは承認、「判断の前提が崩れている」ときは止まる、という3層になっています。ツールの一覧を渡すだけだと、モデルは「何を呼べるか」はわかっても、「いつ呼んでよいか」「どこで止まるべきか」はわかりません。この3層を書いておくと、エージェントの振る舞いがかなり読みやすくなります。
ツール・MCP・Responses API 🔧
公式モデルページにある通り、GPT-6.1 Sol のツール呼び出しには Responses API が必須です。Chat Completions は、ツールを使わないリクエストでのみサポートされます。元記事に載っている最小構成のコードは次の通りです。
const response = await client.responses.create({
model: "gpt-6.1-sol",
reasoning: { effort: "medium" },
input: "Analyze the incident and use the available tools when needed.",
tools: [/* ツール定義 */],
});
元記事がここで強調しているのは、ツールの品質は、プロンプト設計とツール設計の両方で決まるという点です。do_action のような曖昧な名前のツールより、get_order、search_policy、create_refund_request、verify_refund_status のように具体的な名前の方が、モデルに多くの情報を与えられます。
役割分担を図にするとこうなります。
プロンプトはポリシーを定義し、ツールスキーマは能力を定義する。
元記事のこの整理は、とてもわかりやすいと思います。MCP でつないだシステムについても、「権限や実行のルールは、可能な限りプロンプトの外に置く」ことが勧められています。プロンプトで「〇〇はしないでください」と頼むより、そもそもランタイムでできないようにしておく方が確実だからです。
computer use 🖱️
元記事は、computer use のタスクを「通常のテキストプロンプトとは違う。あらゆるアクションが環境を変えるから」と説明しています。例として挙がっているのは、Web アプリでプロジェクトの締め切りを10月15日に更新するタスクです。要点はこうなります。
- やってよいこと: アプリ内の移動、現在のプロジェクト設定の確認、締め切りフィールドの編集
- やってはいけないこと: メンバーの変更、課金の変更、削除やアーカイブ、必要のない通知の送信
- 確定の前に: 編集対象が正しいプロジェクトか、新しい日付が10月15日かを確認する。外部への通知が発生するなら、止まって承認を求める
- 確定の後に: 該当プロジェクトを開き直し、保存された締め切りが10月15日になっていることを確認して、確認済みの結果を報告する
状態遷移で表すと、次のような流れです。
この図のポイントは、「確定」で終わらずに「開き直して確認」を挟んでいることです。ボタンを押したことと、値が保存されたことは別物です。後で出てくる「よくあるミス」にも「試みたアクションを成功とみなす」が入っていて、ガイド全体を通して繰り返し強調されています ✅
PDF と複雑なドキュメント 📄
元記事によると、6.1 Sol は表・チャート・図・細かい注記を含む専門的な PDF のベンチマーク（GDP.pdf）で強い結果を出したそうです。ただし、元記事は「大きなコンテキストがあるだけでは、根拠のある回答は保証されない」とも書いています。
ドキュメント分析のプロンプトで中心になるのは、**証拠のルール（Evidence rules）**です。
- 事実の主張は、渡したドキュメントだけを根拠にする
- 明示的な記述と、計算・推論を区別する
- チャートや表を使ったときは、該当するセクションや表を示す
- 欠けている値を一般知識で埋めない
- ドキュメントが答えを裏づけないなら「ドキュメントでは裏づけられません」と言う
そして、回答ごとに「答え・証拠・計算（あれば）・不確実性のメモ」を返させます。「答えがわからないときの言い方」まで指定しておくと、もっともらしい作り話を防ぎやすくなります。
長文コンテキスト 📚
1.05M トークンのコンテキストについて、元記事の基本ルールは明快です。
最大のコンテキストではなく、関連するコンテキストを送る。
長いプロンプトには、指示の矛盾、事実の重複、古い記録、レイテンシとコストの増加、シグナル対ノイズ比の低下といったリスクがあります。加えて、先ほど見た 272K の料金境界もあります。
元記事は、長いプロンプトを次の4層に分けて並べることを勧めています。
変わらないものを前に、変わるものを後ろに置く、という並べ方です。これはそのまま、後で出てくるプロンプトキャッシュの効きやすさにもつながります。
Structured Outputs 🧾
アプリケーションが機械可読なオブジェクトを必要とするなら、「JSON で返してください」と文章で頼むのではなく、Structured Outputs を使うのが元記事の推奨です。役割分担としては、プロンプトは意味（セマンティクス）に集中し、スキーマの強制はランタイムに任せる、という形になります。
元記事の例はインシデントの分類です。
インシデントを分類してください。
ルール:
- severity はエンジニアリングの難しさではなく、ユーザーへの影響を表す
- 証拠が不十分なら "unknown" を選ぶ
- インシデント記録に存在する証拠だけを列挙する
「severity が何を意味するか」「迷ったときにどの値を選ぶか」のような、スキーマでは表現しきれない判断基準をプロンプトに書く、というのがポイントです。
検証と事実性 🔎
元記事によると、OpenAI の事実性評価では、6.1 Sol（low effort）で「事実誤りを1つ以上含む回答」の割合が 6 Sol の 11.4% から 7.7% に下がったそうです。ただし、元記事はここで次のように釘を刺しています。
実務上の教訓は「もう検証は不要」ではありません。
重要な判断や証拠に敏感なタスクでは、引き続き「主張をどう根拠づけるか」をプロンプトで伝える必要があります。元記事の検証チェックリストを日本語にすると、こうなります。
最終化する前に:
- 結論に大きく影響する主張を特定する
- 各主張を、渡された資料またはツールの結果と照合する
- 観察した事実と推論を区別する
- 解消できていない矛盾を報告する
- 欠けているフィールドを埋めるために値を作らない
最後の「値を作らない」は、Structured Outputs と組み合わせるときに特に効きます。スキーマに必須フィールドがあると、モデルはそれを埋めようとするからです。null や unknown を許すスキーマにしておき、プロンプトでも「わからないなら作らない」と伝える、という両輪がおすすめです。
プロンプトキャッシュ 💰
6.1 Sol のキャッシュ入力は $0.10 / 100万トークンで、6 Sol の $0.20 の半額です。キャッシュ書き込みは $2.50 / 100万トークン（通常入力の 1.25 倍）です。
キャッシュを効かせるための並べ方として、元記事は「静的なプレフィックス」と「動的なサフィックス」に分けることを勧めています。
青い部分（静的プレフィックス）がリクエスト間で同じであるほど、キャッシュヒットが増えてコストが下がります。先ほどの configuration_update も、「effort を変えたいけれどプレフィックスは変えたくない」というこの文脈で効いてくる機能です。
📝 公式の移行ガイドには「
prompt_cache_retentionをprompt_cache_options.ttl: "30m"に置き換える」という項目もありますが、これは GPT-5.5 以前から移行する場合の話です。GPT-6 Sol から 6.1 Sol への移行では、キャッシュのパラメータ自体を変える必要はありません。
用途別テンプレート10本の早見表 🗂️
元記事の後半には、そのまま出発点として使えるテンプレートが10本載っています。全部を転載すると長くなるので、それぞれの「核になる指示」を表にまとめました。
| # | 用途 | 核になる指示（要約） |
|---|---|---|
| 1 | 複雑な機能実装 | 公開 API の互換性維持／既存の設計と命名に従う／不要な依存を増やさない／編集前に最小の実装を特定／新しい挙動のテストを追加 |
| 2 | バグ調査 | すぐにパッチを当てない。まず根本原因と証拠を示して仮説を検証し、それから最小で安全な修正。証拠が足りなければ推測せず次の診断ステップを返す |
| 3 | コードベース移行 | 現在の挙動を保つ／対象範囲の非推奨の使い方を除去／無関係なモジュールは移行しない／移行後にもう一度非推奨の使い方を検索する |
| 4 | ツールを使うリサーチ | 情報源の優先順位（公式・一次 → 権威ある技術文書 → 信頼できる二次報道）／結論ごとに日付と不確実性を示す／判断が変わらなくなったら調査を止める |
| 5 | computer use | 許可された操作と禁止事項を列挙／最終アクションの前にアカウント・対象・値を確認／後で画面を開き直して保存状態を確認 |
| 6 | 複雑な PDF 分析 | ドキュメントの証拠のみ使用／セクション・ページ・表・チャートを引用／計算は元の事実と分けて示す／推論は推論とラベル付け |
| 7 | 業務ワークフロー | 判断の前に現在の状態を取得／十分な最小のアクションを使う／新しい証拠なしに同じアクションを繰り返さない／書き込みの成功を確認してから完了報告 |
| 8 | 長文コンテキストの統合 | 情報源が矛盾したときの優先順位（承認済み最新仕様 → 現行ポリシー → 最近の決定 → 古い履歴文書）／矛盾を黙って調停しない |
| 9 | 構造化データ抽出 | 明示された値を忠実に写す／スキーマが求めるときだけ正規化／欠損値を推測しない／単位は変換指示がない限り元のまま |
| 10 | 本番インシデント分析 | ログ・メトリクス・トレース・デプロイ履歴・ランブックを使う／明示的な承認なしに破壊的操作・再起動・ロールバックをしない／承認後のアクションでは復旧を確認 |
10本を並べてみると、共通するパターンが見えてきます。
- 止めどころが書いてある（「判断が変わらなくなったら止める」「証拠が足りなければ次の診断ステップを返す」）
- やりがちな過剰行動を禁止している（無関係な移行・リファクタリング、繰り返しの呼び出し、黙った調停）
- 完了の前に検証させている（再検索、開き直し、書き込みの確認、復旧の確認）
例として、2番のバグ調査テンプレートを日本語にするとこうなります。
{BUG} を調査してください。
証拠:
{ERRORS}
{LOGS}
{REPRODUCTION_STEPS}
すぐにパッチを当てないでください。
まず最も可能性の高い根本原因を特定し、裏づけとなる証拠を示し、その仮説を検証してください。
そのうえで最小限の安全な修正を行い、元の失敗が起きなくなったことを確認してください。
証拠が不十分な場合は、推測せずに次の診断ステップを返してください。
短いテンプレートですが、「すぐ直さない → 仮説を検証 → 最小の修正 → 元の失敗の消失を確認 → 足りなければ止まる」という契約がきちんと入っています 📝
よくある10のミス 🙅
元記事の「Common Mistakes」は、そのままチェックリストとして使える内容です。NG と、その代わりにどうするかを対比で整理しました。
| # | ありがちな書き方・運用（NG） | 理由・代わりにどうするか（OK） |
|---|---|---|
| 1 | GPT-6 Sol の設定を再テストせずにコピーする |
none の廃止だけでも移行テストをする理由になる。代表的なタスクで再テストする |
| 2 | ツールを使うワークフローに Chat Completions を使う | ツールが絡むなら Responses API を使う |
| 3 | プロンプトを直す前に effort を上げる | 曖昧なタスクは max にしても曖昧なまま。先にプロンプトを直す |
| 4 | コンテキストが大きいからとナレッジベースを丸ごと送る | 大きなコンテキストは「能力」であって「検索戦略」ではない。関連する情報だけを選んで渡す |
| 5 | 実装のステップを全部書く | 道筋そのものが重要なときだけ、道筋を指定する |
| 6 | ツールを渡すだけでツールポリシーを書かない | ツール一覧は「何を呼べるか」しか伝えない。「いつ呼ぶか」を書く |
| 7 | 試みたアクションを成功とみなす | 外部の状態が変わるなら、アクション後の検証を必須にする |
| 8 | スキーマを強制せずに JSON を頼む | 機械可読な構造に依存するなら Structured Outputs を使う |
| 9 | 現在と過去の文脈を優先順位なしで混ぜる | 文書が矛盾したとき、どれが勝つかを伝える |
| 10 | トークン単価だけを見る | 成功したタスク1件あたりのコストで見る。リトライと人のレビューも含める |
どれも当たり前に見えますが、3番の「effort を上げる前にプロンプトを直す」と、4番の「大きなコンテキストは検索戦略ではない」は、新しいモデルが出たときについ忘れがちなポイントだと思います（スペック表の数字が大きいと、どうしても全部入れたくなりますよね）。
GPT-6 Sol からの移行8ステップ 🚚
元記事は、移行の手順を8つのステップにまとめています。公式の移行ガイドと照らし合わせながら見ていきます。
-
モデル ID を変更する:
gpt-6-sol→gpt-6.1-sol -
reasoning effort を移行する:
none→lowにして再評価。low/medium/high/xhigh/maxはそのまま - ツール呼び出しを Responses API に移す: Chat Completions で function calling をしているなら、ツールのワークフローを Responses に移行
-
サンプリング系のパラメータを見直す: 公式の移行ガイドでは、effort が
none以外のときはtemperature、top_p、top_logprobsを削除するよう書かれています。さらに Chat Completions ではlogprobsも、Responses ではincludeのmessage.output_text.logprobsも削除します。6.1 Sol はnoneを使えないので、非推論モデルのような制御を持ち込まないようにします - プロンプトの長さを再ベンチマークする: 過去の指示をすべて残すのではなく、プロダクトとしての「契約」から書き直す。ランタイムの強制と重複している指示や、もう挙動を変えない指示は削る
- ツールポリシーを再テストする: ツール選択・引数・リトライ・承認の境界・停止・書き込み後の検証を確認
-
コストとレイテンシを再テストする:
lowとmediumでエンドツーエンドの性能を測ってから、以前の設定が最適かを判断する - 安くなったキャッシュ入力を活かす: 長い固定プレフィックスを再利用しているなら、キャッシュ単価の値下げの効果を測る
5番の「プロンプトの長さを再ベンチマークする」は、意外と見落とされやすいステップです。新しいモデルに移るときは「足す」方向ばかり考えがちですが、元記事は「もう挙動を変えない指示を削る」ことも移行作業の一部として扱っています。古いモデルのクセを補うために書いた指示が、新しいモデルではノイズになっていることもあるからです ✂️
GPT-6.1 Sol と GPT-6 Astra の使い分け ⚖️
最後に、上位モデルの Astra との比較です。価格はこうなっています（100万トークンあたり）。
| モデル | 入力 | キャッシュ入力 | 出力 |
|---|---|---|---|
| GPT-6.1 Sol | $2 | $0.10 | $10 |
| GPT-6 Astra | $10 | $1 | $50 |
入力と出力の単価は5倍、キャッシュ入力は10倍の差があります。公式の Model selection ガイドは、6.1 Sol を「財務結果から取締役会向けプレゼンを作る」「製品概要から Web サイトを作る」のようなコストが気になる複雑なプロジェクトで検討するよう勧め、「同じタスクで Astra と比較して、品質とコストのトレードオフを評価する」ことを推奨しています。
元記事によると、科学研究の最難関タスクでは、OpenAI は引き続き Astra を推奨しているそうです（ローンチ時の比較で、Terminal-Bench Science 0.1 では Astra が最高スコアだったと紹介されています）。一方で、多くのコーディング・computer use・専門業務では、6.1 Sol が別のコストと品質のトレードオフを提供するので、ベンチマークする価値がある、というのが元記事の見立てです。
判断の流れを図にすると、次のようになります。
比較するときの指標として、元記事は次の項目を挙げています。
- タスク成功率
- 推論の質
- ツール呼び出しの正確さ
- レイテンシ
- 出力トークン数
- リトライ率
- 人によるレビューが必要になった率
- 成功したタスク1件あたりの総コスト
ここでも最後に来るのは「成功1件あたりのコスト」です。単価だけを見ると 6.1 Sol が圧倒的に安く見えますが、Astra で1回で終わる仕事が 6.1 Sol では3回リトライと人のレビューが要る、ということなら話は変わります。逆もまたしかりです。結局は自分のワークロードで測るしかない、というのが両方のガイドに共通する結論です。
プロンプトの評価と改善のしかた 🧪
ガイドの締めくくりは、プロンプトのテストと最適化です。元記事は冒頭でこう書いています。
1つの回答を読んで「良くなったように見える」で判断して、プロンプトを最適化しないでください。代表的な評価セットを作りましょう。
ワークロードごとに測るべき指標は、次のように整理されています。
| ワークロード | 測る指標 |
|---|---|
| コーディング | タスク完了、通過したテスト、リグレッション、不要に変更されたファイル、完了までの時間 |
| エージェント | ツール選択、引数、不要なツール呼び出し、承認ルールの順守、リトライ回数、最終状態の正しさ |
| ドキュメント分析 | 根拠づけ、表・チャートの解釈、計算の正確さ、裏づけのない推論 |
| computer use | 完了、間違った対象へのアクション、意図しない副作用、検証の成功、人の介入 |
そして改善の進め方は、一度に変えるのは1つの変数だけです。
複数の変更を同時に入れると、どれが効いたのかわからなくなります。地道ですが、1つずつ変えて評価する方が結局は早道です。元記事は「最終的な応答だけでなく、実行経路全体を評価する」ことも強調しています。最終回答が正しくても、途中で不要なツール呼び出しを10回していたら、本番ではコストとレイテンシに跳ね返ってくるからです 🔁
📝 元記事の最後には、PrompTessor 自身のツール（プロンプト生成・分析・最適化）を使った改善フローの紹介があります。あわせて「PrompTessor は API レベルの制御を置き換えるものではない。ツールの認可・状態・承認・スキーマ・実行・キャッシュ・可観測性は、引き続きアプリケーションのランタイムで強制すべき」とも書かれていて、ここはツールを問わず大事な指摘だと思います。
まとめ 🌅
GPT-6.1 Sol は、Sol クラスの価格（入力 $2 / 出力 $10）を保ったまま、複雑なコーディング・computer use・専門的なドキュメント作業・業務エージェントで Astra に近づくことを狙ったモデルです。同時に、none の廃止、ツール呼び出しの Responses API 必須化、キャッシュ入力の値下げという、ランタイムの前提の変化も伴っています。
このガイドを読んで一番持ち帰りたいのは、冒頭の「プロンプトは台本ではなく契約書」という考え方です。手順を細かく書く代わりに、ゴール・境界・判断ルール・完了条件・検証・止めどころを取り決めて、道筋はモデルに選ばせる。そして、その契約がうまく機能しているかを、effort もプロンプトも「成功1件あたりのコスト」で測りながら調整していく。新しいモデルが出るたびにプロンプトを長くしていく方向とは、少し逆の発想になっています。
GPT-6 Sol から移行する方は、まず移行8ステップの①〜④（モデル ID・effort・Responses API・サンプリング系パラメータ）を片付けて、代表的なタスクで low と medium を比べるところから始めてみてください。そのうえで、今のプロンプトに「もう挙動を変えていない指示」が残っていないかを見直すと、6.1 Sol らしい書き方に近づいていけると思います 🙌
なお、この記事では元記事のテンプレートを要約して紹介しました。各テンプレートの英語の原文は元記事にまとまっているので、実際にプロンプトへ組み込むときは元記事もあわせて参照してください。GPT-6 ファミリー全体（特に Astra）の公式プロンプティングガイドについては、別記事「GPT-6 のプロンプティング術とは？」で解説しています。
参考
- How to Prompt GPT-6.1 Sol: Best Practices, Reasoning, and Examples — PrompTessor ブログ（Rizki Murtadha、2026年9月30日）。この記事の元記事
- GPT-6.1 Sol モデルページ — OpenAI 公式。仕様・価格・対応ツール
- Using GPT-6 — OpenAI 公式。ファミリー概要、制限事項、移行クイックスタート
-
Reasoning — OpenAI 公式。reasoning effort と
configuration_update - Model selection — OpenAI 公式。モデルと effort の選び方
- Codex Models — OpenAI 公式。Codex / ChatGPT Work での提供状況
- GPT-6 Sol モデルページ — OpenAI 公式。移行元モデルの仕様
- Introducing GPT-6.1 Sol — OpenAI 公式発表（ベンチマーク結果の出典として元記事が参照）