GPT-5.5でツール利用精度を上げるには？system promptよりtool descriptionを見直す理由

GPT-5.5はツール利用に強い と聞くと、つい system prompt を盛りたくなります。
でも OpenAI公式の最新モデルガイドを読むと、むしろ逆で、ツール固有の説明は tool description に寄せる 方が筋がよいとかなりはっきり書かれています。

この記事では、2026年4月25日時点の OpenAI 公式情報をもとに、

• なぜ system prompt より tool description を見直す方が効くのか
• tool description に何を書くべきか
• 複数ツールがあるときに何が起きやすいか
• GPT-5.5 で精度を上げる実務的な設計順

を整理します。

結論: 共通ルールは system prompt、ツール固有ルールは tool description

最初に結論だけ言うと、役割分担はこう考えると整理しやすいです。

• system prompt / developer instructions
  全ツールにまたがる共通方針、成功条件、禁止事項、停止条件

• tool description
  そのツールが何をするか、いつ使うか、何を渡すか、どんな副作用や失敗があるか

• schema / Structured Outputs
  引数や返り値の shape を機械的に縛る部分

OpenAI公式の Using GPT-5.5 ガイドでも、tool-specific guidance の大半は tool descriptions に入れ、system instructions には 複数ツールをまたぐ方針 だけを残すことが勧められています。

なぜ tool description の方が効きやすいのか

理由は大きく4つあります。

1. モデルが「そのツールをどう使うか」を近い場所で読める

tool description は、そのツール定義に直接ひもづく説明です。
つまりモデルにとっては、このツールを選ぶかどうか を考える場面で、いちばん近い説明になります。

OpenAI公式も、tool description には少なくとも次を入れるよう勧めています。

• what the tool does
• when to use it
• required inputs
• side effects
• retry safety
• common error modes

これは要するに、ツールの 用途 発火条件 危険性 失敗パターン を、そのツールのすぐ横に置けということです。

system prompt の奥に長く書くより、判断点に近いです。

2. system prompt に全部入れると、複数ツールで埋もれる

ツールが1個なら、system prompt に全部書いてもまだ回ることがあります。
でも実務では、

• search_customer
• create_invoice
• refund_order
• send_email

のように複数ツールが並びます。

このとき system prompt に

• 返金ツールはこう
• 請求書ツールはこう
• メール送信はこう
• 顧客検索はこう

と全部詰めると、モデルは毎回その長文を読んでから、どのツールに何が書いてあったかを思い出す必要があります。

一方で description に寄せれば、各ツールの差分がその場で見えます。
OpenAI公式が Put most tool-specific guidance in the tool descriptions themselves と書くのは、この差が大きいからです。

3. Prompt Caching とも相性がよい

Prompt Caching 記事でも触れた通り、GPT-5.5では static parts first, dynamic parts last がかなり重要です。

system prompt にツール固有の細かい説明を抱え込むと、

• ツールセットが少し変わるだけで prefix が大きく揺れる
• フローごとに system prompt 差分が増える
• 共通 prefix が短くなる

といった問題が起きやすいです。

tool descriptions へ分けると、共通ルール と 個別ツール定義 を切り分けやすくなります。
その結果、system prompt 側を短く安定させやすいです。

4. tool ごとの差を局所的に改善できる

system prompt にツールルールを寄せると、Aツールの問題を直すために system prompt を変え、その結果 Bツールの挙動まで変わることがあります。

description 中心にしておけば、

• refund_order の説明だけ直す
• search_docs の説明だけ詳しくする
• send_email の副作用だけ強調する

という局所修正がしやすいです。

これは eval を回すときにもかなり大事です。

OpenAI公式が description に入れるべきと言っているもの

最新モデルガイドの要点を実務向けに言い換えると、tool description には少なくとも次を入れたいです。

この6点があると、モデルは 呼ぶべきか だけでなく どう呼ぶと危ないか まで判断しやすくなります。

system prompt に抱え込むと何が起きるか

system prompt が悪いわけではありません。
ただ、役割以上のことを押し込むと、次のような問題が起きやすいです。

1. ツール選択の境界がぼやける

例えば system prompt にだけ

• 顧客情報が必要なら検索ツールを使う
• 返金は条件を確認してから
• メール送信は最後だけ

と書いても、どのツールが何を返し、何を変更し、何が危険かまでは伝わりきりません。

その結果、

• 関係ないツールを呼ぶ
• 呼ぶべき場面で躊躇する
• 入力不足のまま call する

といったズレが起こります。

2. 同じルールを重ね書きしやすい

system prompt にツール説明を足していく運用では、

• 古い説明が残る
• 一部ツールだけ別名で説明される
• 似た条件が二重に書かれる

ことが多いです。

GPT-5.5は instruction following がかなり素直なので、こうした重複や矛盾も丁寧に拾ってしまいます。
結果として、開発者が思っている以上に挙動が不安定になります。

3. side effects の重みが伝わりにくい

send_email charge_card delete_record のようなツールは、単なる情報取得と違って副作用があります。

OpenAI公式が side effects や retry safety を description へ書くよう勧めるのは、ここが本当に重要だからです。
system prompt に 危険な操作は慎重に と書くだけでは、どのツールがどの程度危険なのかが曖昧です。

4. 失敗時の挙動が雑になりやすい

common error modes を書かないと、モデルは

• 404 のときどうするか
• 権限エラーのときどうするか
• 入力不足のとき確認すべきか

を毎回推測します。

これが tool call の無駄打ちや、変なリトライにつながります。

良い tool description はどんな書き方か

良い description は、長文である必要はありません。
でも、次のような情報が入っているとかなり強くなります。

悪い例

顧客情報を検索するツールです。

これだと、

• 何をキーに検索するのか
• いつ使うのか
• 見つからなかったらどうするのか

が分かりません。

良い例の方向

顧客IDまたはメールアドレスから既存顧客を検索する。請求・返金・契約確認の前に対象顧客の特定が必要なときだけ使う。名前だけでは使わない。見つからない場合は推測せず確認を促す。副作用はない。

これだけでも、

• 使う場面
• 使わない場面
• 入力の条件
• エラー時の振る舞い
• 副作用の有無

がかなり見えます。

特に大事な3項目

description に何を書くか迷ったら、まずこの3つを優先すると効果が出やすいです。

1. いつ使うか / いつ使わないか

ツール精度で一番崩れやすいのは、使うべき場面 と 使うべきでない場面 の境界です。

例えば、

• order_lookup は注文IDがあるときだけ
• refund_order は返金条件が満たされた後だけ
• send_email は最終確認後だけ

のように、発火条件を書いた方がよいです。

2. 副作用と retry safety

OpenAI公式がここを明示しているのは実務的です。
同じ tool call でも、

• 何回呼んでも安全な取得系
• 重複実行で事故る更新系

があるからです。

description に

• read-only か
• state-changing か
• safe to retry か

を入れておくと、モデルの慎重さが変わります。

3. よくある失敗

common error modes は軽く見られがちですが、かなり効きます。

例えば、

• customer not found
• permission denied
• missing required field
• temporary upstream failure

のような失敗があるなら、書いておいた方がよいです。

モデルは失敗をゼロにはできませんが、失敗の種類を知っている だけで無理な tool call を減らしやすくなります。

複数ツールがあるときは description の差分設計が重要

ツール数が増えると、description の明瞭さがさらに重要になります。
OpenAI Cookbook の function-calling ガイドでも、複数ツールで description が曖昧だと、誤選択や躊躇が増えると案内されています。

特に危ないのは、似たツールが並ぶケースです。

例えば、

• search_customer
• search_customer_by_order
• search_account

のように近い名前があると、description に差がない限りモデルも迷います。

このときは、

• 主目的
• 必須入力
• 他ツールとの違い
• 優先順位

まで書くと、かなり改善しやすいです。

GPT-5.5でのおすすめ改善順

精度を上げたいとき、いきなり system prompt を長くするより、この順で見る方がきれいに直しやすいです。

1. まず各 tool description を見直す
2. when to use / when not to use を足す
3. side effects と retry safety を足す
4. common error modes を足す
5. schema を曖昧にしていないか確認する
6. それでも足りない共通方針だけを system prompt へ置く

この順だと、ツールごとの差分を局所修正しやすいです。

system prompt に書くべきことは何か

逆に system prompt には、次のような 全ツール共通のルール を置くのが自然です。

• まず不足情報を確認するか
• destructive な操作前に確認を取るか
• 引用や証拠をどの粒度で示すか
• どこで止まるべきか
• ツールを使いすぎない上限方針

つまり、どのツールをどう使うか ではなく、このエージェント全体の運転ルール を書く場所だと考えると分かりやすいです。

結論

GPT-5.5でツール利用精度を上げたいなら、まず system prompt を足し算するより、tool description を見直す方が効果が出やすいです。
OpenAI公式も、tool-specific guidance の大半は description 側へ置くよう勧めています。

特に大事なのは、

• 何をするツールか
• いつ使うか
• 必要な入力は何か
• 副作用があるか
• retry してよいか
• よくある失敗は何か

の6点です。

要するに、GPT-5.5での tool use 改善は、賢いモデルだから何とかしてくれる 前提ではなく、ツールごとの判断材料を近い場所へ置く 設計の話です。
そこが整うと、誤選択も、無駄な call も、過剰な system prompt も減らしやすくなります。

この記事と一緒に読みたい

1. GPT-5.5移行でプロンプトはそのままでいい？OpenAI公式ガイドで見る見直しポイント
2. OpenAIのResponses APIとは？Chat Completionsからいつ移るべきか
3. Structured Outputsとは？JSON modeと何が違うのか
4. GPT-5.5でPrompt Cachingはどう設計する？静的プロンプトと動的入力の分け方

参考リンク

• OpenAI Developers: Using GPT-5.5
• OpenAI Developers: Migrate to the Responses API
• OpenAI Developers: Function calling
• OpenAI Developers Cookbook: o3/o4-mini Function Calling Guide - developer prompt, system prompt, and function descriptions