GPT-5.1 API reasoning_effort / verbosity の使い方を完全解説
2025年11月12日、OpenAIは GPT-5.1 をリリースしました。
GPT-5.1 は8月に発表された GPT-5 を改良したモデルであり、現在の ChatGPT を含む OpenAI 社のフラッグシップモデルです。
今回はこの GPT-5.1 を API から利用し、実際に GPT-5 とどのような差異があるのかを、検証していきます。
GPT-5.1 については、以下の記事で解説しています。あわせてこちらもご覧ください。
株式会社 Digeonは、GPT-5を法人でご利用いただけるサービスである「ENSOUチャットボット」を提供しています。
無料ですぐに使えるフリープランのご利用開始はこちらから👇
GPT-5.1 API で提供されるモデル
今回の GPT-5.1 のリリースで提供されるようになったモデルは、 gpt-5.1 のみです。
GPT-5 API では、以下の3つのモデルがサポートされていましたが、執筆時点の2025年11月18日では、この1つのモデルのみがリリースされています。
- gpt-5
- gpt-5-mini
- gpt-5-nano
そして今回の gpt-5.1 は、 gpt-5-mini や gpt-5-nano の代替ではなく、 gpt-5 を置き換えるフラッグシップモデルとして提供されることが明記されています。
GPT-5.1 API の主な変更点
GPT-5.1 の API は、リリースの翌日には OpenAI API と Azure AI Foundry で利用できるようになりました。
API としてどのようなモデルや機能が提供されているかについては、 OpenAI API 公式ドキュメント で記載されています。
reasoning_effort: none による推論の高速化
GPT-5.1では、 reasoning_effort というパラメータにおいて、 none を設定できるようになりました。
このパラメータは、推論モデルの推論の長さ・深さを指定するパラメータで、以下のような種類があります。
reasoning_effort | 概要 |
|---|---|
none | GPT-5.1で新たに追加され、デフォルト値は |
minimal | 推論が実行される中で最も推論が短時間で完了する。 |
low | minimalの次に推論が短時間で完了する。 |
medium | GPT-5 の時点ではデフォルトであった値で、通常の推論モデルとしての推論をサポートする。 |
high | 最も推論に時間をかける。 |
reasoning_effort は GPT-5 のリリース時に API で提供され始めたパラメータです。
当時はデフォルトで medium が設定されるようになっていたのですが、個人的な所感では low にしたとしてもレイテンシが気になることが多々ありました。
ひとつのモデルで様々な用途に使えるモデルを、という直近の OpenAI 社の方針から、推論なしで instant に返答できるサービスを提供するために、この none の設定が GPT-5.1 で追加されたのではないかと考えています。
verbosity で出力されるトークン数を制御
verbosity というパラメータで出力されるトークン数を、`high`, medium, low で制御できます。
このパラメータ自体は GPT-5 でもサポートされており、主だった変更はありません。
ただし、今回の GPT-5.1 では、 reasoning_effort に none を設定できるようになったことから、より簡潔に高速に回答させやすくなった、という背景から記載されているように考えられます。
また他の背景としては、 GPT-5 シリーズのモデルは、従来利用されていた temperature のパラメータが利用できなくなっており、その代わりに verbosity を使いなさい、という理由でこの説明があったのかもしれません。
いずれにしても、 GPT-5 シリーズで制御パラメータが、パラメータ感の強いものから、人間が理解しやすい「推論強度」「冗長性」というものに変わったというのは、人間的にはありがたい話です。
GPT-5.1 API で新たに利用できるツール
GPT-5.1 では、以下の新たなツールが利用できるように、トレーニングされています。
apply_patch: コーディング特化のツールで、差分を意識した変更を行えるツールshell: コーディング特化のツールで、シェルコマンドを提案できる
今回のリリースで提供されたツールはいずれもコーディング用途向けであり、特に OpenAI 社が提供する Codex でのユースケースを、そのまま API としても提供し始めたというイメージでしょうか。
apply_patch 差分ベースで安全にコードを編集
apply_patch は、既存コードに対して「差分（diff）」で変更を適用するためのツールです。
ファイル全体を書き換えるのではなく、必要な行だけを最小限変更する、という動きをします。
特徴
- 差分（diff）単位でコードを編集
- プロジェクト内の他ファイルやコードスタイルを考慮して修正
- 既存コードを大きく壊さず、ピンポイントな修正に向いている
- Git の diff と相性がよく、PR 自動生成などにも活用しやすい
どんなときに使うか
- 既存プロダクトのバグ修正・軽微な仕様変更
- 「このファイルのここだけ直したい」が明確なとき
- CI / CD で AI にパッチを提案させたいとき
reasoning_effort: none と組み合わせれば、高速なコード修正ボットとしても使いやすくなります。
shell 安全にシェルコマンドを生成
shell は、自然言語から安全なシェルコマンドを生成するためのツールです。
rm -rf / のような危険なコマンドを避けつつ、正しい構文の CLI を提案してくれます。
特徴
- bash / zsh などで実行可能なコマンドを構文的に正しく生成
- 破壊的な操作を避ける安全志向の設計
git,docker,grep,findなどのコマンド群に広く対応- 「〜したい」という自然言語から、具体的な 1 行コマンドへ変換
どんなときに使うか
- 環境構築やログ調査用のコマンドをサッと作りたいとき
- DevOps・インフラ系の手順をコマンドレベルまで自動化したいとき
- 本番環境で「危険なコマンドを打ちたくない」場面でのダブルチェックとして
実際に GPT-5.1 の API を TypeScript で試す
それでは、実際に GPT-5.1 の API を TypeScript で検証してみます。
reasoning_effort: none を試す
reasoning_effort を none と low でどのように回答内容と応答速度が変わるのかを検証します。
今回は以下のプロンプトで、それぞれのレスポンスを検証しました。
あなたはシニアソフトウェアアーキテクト兼 SRE です。以下の要件を満たす、オンプレミスとクラウドを跨るハイブリッドなログ収集・分析基盤のアーキテクチャを設計し、ステップバイステップで理由を説明した上で、日本語で最終案をまとめてください。
要件:
* マイクロサービスが 100+ 存在し、それぞれが毎秒数千行のログを出力する
* 一部のログは PII を含み、保存や転送に制約がある
* 監査用に 7 年間の保存が必要だが、コストも最適化したい
* 障害発生時には 5 分以内に根本原因分析を開始できること
* 開発チームが独自メトリクスやトレースも後から追加できる拡張性があること
出力フォーマット:
1. 前提と制約条件の整理
2. 候補アーキテクチャ案を 2〜3 個列挙し、それぞれのメリット・デメリットを比較
3. 最終的に採用するアーキテクチャの構成（コンポーネント図のテキスト表現を含む）
4. 運用・監視・セキュリティの観点からのチェックリストこの実行結果は以下のとおりとなり、応答速度自体に若干の差異があるものの、そこまで大きな差にはならないようです。
reasoning_effort | 応答速度（sec） | 出力文字数 |
|---|---|---|
none | 111.55 | 12,527 |
low | 128.95 | 11,927 |
回答本文の主な差異としては、どちらも十分に問いには答えられており、その設計方針や考え方がやや異なるという印象です。
最終的なまとめセクションのみを以下に記載します。
--- reasoning_effort: low ---
### まとめ
- ログ・メトリクス・トレースの収集を OpenTelemetry に統一し、
軽量エージェント（Fluent Bit / OTel Collector）→ Kafka → Loki/Mimir/Tempo → S3 というパイプラインを
オンプレ・クラウド両方に展開する ハイブリッド可観測性基盤 を採用する。
- PII / 監査ログはオンプレ内で完結し、マスキング済みのサマリのみクラウドに転送。
- 長期保存はオブジェクトストレージ主体とし、オンプレ/クラウド両方で 7 年保存要件を満たしつつ、ホットデータ期間を短くすることでコスト最適化。
- Kafka によるバッファリングと Loki/Mimir/Tempo による統合可視化で、障害発生から 5 分以内に RCA を開始できる運用を実現。
- チームは OTel SDK を用いて独自メトリクス/トレースを容易に追加でき、将来的なツール追加・変更にも耐えられる拡張性を確保する。
--- reasoning_effort: none ---
### まとめ
- PII とコンプライアンス制約、オンプレ資産、クラウドのスケールと分析力を両立するために、**オンプレを起点とした Kafka ベースのログ集約＋二重系（オンプレ OpenSearch & クラウド分析基盤）**というハイブリッド案を採用しました。
- 直近 90 日程度はオンプレ OpenSearch で高速検索し、5 分以内の RCA を保証します。
- 90 日以降〜7 年はクラウドオブジェクトストレージ中心に保管し、Athena 等で必要時に検索することでコストを最適化します。
- PII はオンプレでマスク/トークナイズした上でクラウドへ送出し、フルデータはオンプレに限定することでコンプライアンス要件に対応します。
- ログ・メトリクス・トレースは OpenTelemetry を軸に統合し、各開発チームが後から独自メトリクスやトレースを容易に追加できる拡張性を確保します。low のまとめ
OTel + Loki/Mimir/Tempo + S3 という モダンな observability パイプラインを採用し、オブジェクトストレージを主体としてコストメリットがあり、将来的なツールの変更に強いことが挙げられます。
none のまとめ
Kafka + OpenSearch（オンプレ）＋ S3/Athena（クラウド）という 実務寄りハイブリッドログ基盤を採用し、枯れた技術スタックを使うという方針に差異があります。
また回答の主な方針として、 low は「どのスタックどのパイプラインか」、 none は「どんな運用・ポリシーで回すか」に軸足がある、という差異があります。
verbosity を切り替える
次に verbosity のパラメータ設定による応答の差異を確認します。
verbosity が low と medium の比較は以下のとおりです。
verbosity | 応答速度（sec） | 出力文字数 |
|---|---|---|
low | 4.31 | 221 |
medium | 6.98 | 268 |
この比較の実行結果は以下の通りであり、実際に verbosity により、出力文字数とレイテンシーを制御できていることがわかります。
[low] レイテンシ: 4.31 sec
[low] メッセージ:
マイクロサービスは、アプリケーションを「小さなサービスの集合」に分割し、それぞれを独立して開発・デプロイできるアーキテクチャです。
一方モノリスは、画面・ロジック・データ処理などが一つの大きなアプリケーションとしてまとまっている構成です。
マイクロサービスは変更や拡張に強い反面、サービス間通信や運用が複雑になりがちです。
モノリスは構造がシンプルで小規模開発に向きますが、規模が大きくなると変更の影響範囲が広がりやすくなります。
[medium] レイテンシ: 6.98 sec
[medium] メッセージ:
マイクロサービスは、アプリケーションを「ユーザー管理」「決済」「検索」などの小さなサービスに分割し、それぞれを独立して開発・デプロイできるアーキテクチャです。
一方モノリスは、画面・ビジネスロジック・データアクセスなどが一つの大きなアプリとしてまとまっている構成です。
モノリスは構造がシンプルで小規模開発では扱いやすい反面、規模が大きくなると変更やデプロイの影響範囲が広くなりがちです。
マイクロサービスはスケールしやすくチームごとの独立開発に向いていますが、サービス間通信や運用が複雑になるというトレードオフがあります。今回の比較用に、実行したコードは以下の通りです。
import OpenAI from "openai";
type Verbosity = "low" | "medium";
async function callWithVerbosity(verbosity: Verbosity) {
if (!process.env.OPENAI_API_KEY) {
throw new Error("環境変数 OPENAI_API_KEY が設定されていません。");
}
const client = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
});
const prompt =
"あなたは日本語が得意なソフトウェアエンジニアです。" +
"次のテーマについて、初心者にも分かりやすい短い解説文を 3〜5 文程度で書いてください。" +
"\n\n" +
"テーマ: マイクロサービスとモノリスの違い";
const start = Date.now();
const response = await client.responses.create({
model: "gpt-5.1",
input: prompt,
text: { verbosity },
});
const end = Date.now();
const elapsedMs = end - start;
const elapsedSec = elapsedMs / 1000;
const text = response.output_text;
return {
verbosity,
elapsedSec,
text,
};
}
async function main() {
try {
const low = await callWithVerbosity("low");
const medium = await callWithVerbosity("medium");
console.log(`[low] レイテンシ: ${low.elapsedSec.toFixed(2)} sec`);
console.log("[low] メッセージ:");
console.log(low.text);
console.log(`[medium] レイテンシ: ${medium.elapsedSec.toFixed(2)} sec`);
console.log("[medium] メッセージ:");
console.log(medium.text);
} catch (err) {
console.error("エラーが発生しました:", err);
process.exitCode = 1;
}
}
void main();まとめ
GPT-5.1 は、GPT-5 を置き換えるフラッグシップモデルとして gpt-5.1 単体で提供され、より実運用を意識したアップデートになっています。
reasoning_effort と verbosity によって「どれくらい深く考えるか」「どれくらい長く話すか」を人間にわかりやすい形で制御できるようになり、ユースケースごとのチューニングがしやすくなりました。
検証では、複雑なアーキテクチャ設計タスクに対して none / low を比較し、レイテンシや回答スタイルに違いがある一方で、どちらも要求を満たす品質で応答できることが確認できました。
短時間でざっくり案が欲しい場面では none、じっくり検討したい設計タスクでは low〜medium といったように、SLO や使い方に応じた使い分けが現実的です。
ENSOUチャットボット GPT-5.1 対応へ
ENSOUチャットボット でも、GPT-5.1のメリットをいち早くお届けできるよう、順次対応を進めていきます。
GPT-5.1への対応が完了次第、ご契約中の企業向けに段階的に提供を開始します。
最新モデルを活用し、応答速度と精度の両立により業務プロセス最適化を支援します。
無料ですぐに使えるフリープランのご利用開始はこちらから👇
ご相談、無料トライアルは、以下からお問い合わせください👇
サービス紹介資料をこちらからダウンロードいただけます👇
