フロンティアな LLM を土台にチーム開発をしていると、どのチームでも必ず開かれる種類の会議がある。誰かが最新の ベンチマークのリーダーボードを共有する。別の誰かが、先月から順位が入れ替わっていると指摘する。3人目は、自分たちのチームが現在使っているモデルが、3週間前には誰も聞いたことがなかったある指標で2つ順位を落としたと述べる。会議が終わる頃には、移行すべきかどうか誰も確信が持てず、議論は翌四半期に持ち越される。
この会議の問題は参加者ではない。問題は、ベンチマークが測っているのは合成タスクであり、あなたのプロダクトは合成タスクではないという点だ。リーダーボードは MMLU、SWE-bench Verified、GPQA Diamond におけるモデルのパフォーマンスを教えてくれる——研究者がモデル間で測定可能なように設計したテストだ。どれも本番であなたのアプリケーションが実際に送っているプロンプトの姿とは似ても似つかない。どれも、ユーザーが生み出す雑多でドメイン特有の入力をモデルがどのように扱うかを捉えていない。
この記事では、ベンチマークができない「まさにその演習」を具体的に示す。GPT-5.5、Claude Sonnet 4.6、Gemini 3.1 Pro に対して、同じ OpenAI 互換エンドポイント経由、同じ温度設定、追加のプロンプトなしで送る3つの具体的なプロンプト。プロンプトは、多くの本番ワークロードにまたがる3つのカテゴリ——雑多なドキュメントからの構造化抽出、推論重視の計画タスク、制約下のコード生成——をカバーしている。以下の所見は、この種の比較を実施するチームが一貫して報告している振る舞いパターンであり——あなた自身が自分の環境でこれらのプロンプトを走らせれば目にするであろうパターンだ。
リーダーボード上では、これら3つのモデルは SWE-bench Verified で互いに0.8ポイント以内の差に収まっている。実際には、挙動は大きく異なる。選択の焦点は「ベンチマークでどれが最高点か」ではなく、「どの振る舞いパターンがあなたのワークロードに適合するか」だ。
ベンチマークが測るものと、見落とすもの
ベンチマークは必要だから存在する。モデル提供者は能力を主張するために標準化されたテストを必要とし、研究者は比較を発表するために必要とし、我々もモデル評価の客観的な出発点を持つために必要とする。有用ではある。しかし本番利用で重要な点において不完全でもある。
以下の3つの制限は明示しておく価値がある。いずれも後述のプロンプト例に現れる。
- ベンチマークは孤立した能力を測るが、振る舞いパターンは測らない。SWE-bench Verified は、モデルが特定種類の GitHub issue を解けるかを教えてくれる。しかし、モデルが単純な問題を過剰設計しがちか、プロンプトが曖昧なときに確認質問をする傾向があるか、あるいは一度目からあなたが求めた構造に合致した出力を返すか、は教えてくれない。これらこそ、あなたが本番で日々目にする事柄だ。
- ベンチマークは「チューニングされる」。あるモデルのリリースが特定ベンチマークのスコアを前面に押し出しているなら、それは少なくとも一部そのベンチマーク向けに最適化されたシグナルだ。本番環境に出た途端に、実世界の性能とベンチマーク性能が（時に大きく）乖離しうる。
- ベンチマークは集約する。SWE-bench Verified の0.8ポイント差は、モデルAが特定カテゴリに非常に強く別のカテゴリに弱いのに対し、モデルBは全般的に一貫している、といった事実を隠しうる。集約は、意思決定に必要な情報を押し潰してしまう。
以下の演習は、まさにベンチマークが集約によって取りこぼす情報を浮き彫りにするよう設計されている。目的は勝者を決めることではない——あなた自身が同じ演習を自分のプロンプトで行う際に問うべき「問い」を示すことだ。
セットアップ
3つのプロンプトを選んだのは、多くの本番ワークロードに対応するカテゴリにマッピングできるからだ。セットアップは、各プロンプトを3モデルすべてに同一パラメータ（温度 0.3、システムプロンプト上書きなし、デフォルトのレスポンス形式）で送信し、単一の OpenAI 互換エンドポイントでアクセスすること。これにより比較は厳密に同条件となる——プロバイダ固有の SDK の癖なし、パラメータのマッピング差なし、リクエストの構築方法の違いで一方のモデルだけ特別扱いされるリスクなし。
プロンプト自体は以下に、コピーして実行できるコードブロックとして掲載する。各プロンプト後に続く振る舞いの記述は、この種の比較を実施したチームが一貫して報告するパターン——あなたが自分の環境でこれらのプロンプトを走らせたときに目にするであろうパターン——である。大事なのは実際に試すことだ。この記事は、そのためのフレームワークと開始プロンプトを提供する。
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMET_API_KEY"], # or replace with your API key
base_url="https://api.cometapi.com/v1", # one endpoint, multiple models
)
MODELS = [
"gpt-5.5",
"claude-sonnet-4-6",
"gemini-3.1-pro",
]
def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
"""
Send the same prompt to all three models and return their responses.
"""
responses = {}
for model in MODELS:
result = client.chat.completions.create(
model=model,
messages=[
{
"role": "user",
"content": prompt,
}
],
temperature=temperature,
)
responses[model] = result.choices[0].message.content
return responses
# Example usage
if __name__ == "__main__":
prompt = "Summarise the key risks in this contract."
outputs = run_comparison(prompt)
for model, response in outputs.items():
print(f"\n--- {model} ---")
print(response)
プロンプト1: 雑多なドキュメントからの構造化抽出
これは 2026 年に出荷された LLM 機能の半分の定番タスクだ。非構造化入力——メール、サポートチケット、会議の書き起こし、スキャンしたフォームなど——から、特定の項目を抽出して構造化オブジェクトにする。以下のプロンプトは、意図的に雑多な顧客サポートメールから7項目を抽出するよう各モデルに求める。メールには不完全な情報、矛盾するシグナル、そしてソースには存在しない項目が1つ含まれている。
プロンプト
You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing", "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned)
Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.
注目ポイント
3点。第一に、モデルが要求された JSON スキーマに過不足なく従うか。第二に、ソースに存在しない項目（escalation_history——この件に関する過去の連絡は顧客が言及していない）をどう扱うか——欠損を認めるのか、もっともらしく作り上げてしまうのか。第三に、JSON の外側に追加のコメントを出力しないか。下流でラッパーを剥がす前処理が不要かどうかという観点だ。urgency 項目も注目に値する。「5 days」は即時ではないが、顧客は明らかに焦っている。解釈の余地がある。
この演習を実施したチームが一貫して報告すること
GPT-5.5。 初回からクリーンな JSON を返すことが多い。スキーマ順守が強固で、要求されたすべての項目が揃い、前処理なしでパース可能な形式になる。欠損項目については、GPT-5.5 は明示的に null を返す傾向がある。JSON を Markdown のコードフェンスで包んだり、説明文を付したりしないことが多く、下流のパースが容易だ。urgency のような解釈が分かれる項目では、他 2 モデルに比べ保守的に振れる傾向がある——Claude や Gemini が顧客の感情的トーンに基づき "high" と評価する場面でも、GPT-5.5 は具体的な「5日」という時間軸にアンカーして "medium" に落とすことが多い。
Claude Sonnet 4.6。 こちらもクリーンな JSON を出力し、要求スキーマの厳密な遵守という点では3者の中で最も精密なことが多い。GPT-5.5 が欠損項目を null のままにする場面で、Claude はしばしば要求されていないフィールド（"notes" や "data_quality_notes" など）を追加し、データ品質の問題を注記する——頼んではいないが実際に有用な情報だ。この追加フィールドは人間のレビューには役立つ一方で、下流のパーサがスキーマを厳格に見る場合は失敗原因になりうる。これは Claude によく見られるパターンだ。品質は高いが、しばしばプロンプト以上に丁寧であり、制約するための明示的な指示が必要になる。
Gemini 3.1 Pro。 3者の中で最も簡潔な出力になることが多い。要求された項目のみ、余計なフィールドなし、周辺の説明文なし。スキーマ順守は指定どおり。ただし一つ知っておくべき癖がある。欠損項目について、Gemini は null ではなく空文字列を返す傾向がある。これを区別する厳密な JSON パーサは差異を検知するが、緩いパーサは検知しない。この挙動は実行ごとに一貫しており、偶発ではなくモデルの性向と思われる。
何が分かるか
3モデルとも構造化抽出はできる。差は、要求スキーマの周縁的な振る舞いにある。下流システムがスキーマに厳格で、追加フィールドをエラーと見なすなら、Gemini 3.1 Pro と GPT-5.5 が無難だ。明示せずともデータ品質の問題を表面化させたいなら、Claude Sonnet 4.6 がより助けになる。これらはベンチマークには現れない。
プロンプト2: 推論重視の計画タスク
このプロンプトは、複数ステップの調査計画の立案を各モデルに求める。慎重なモデルなら計画の前に特定すべき暗黙の制約が3つある。ツールを呼び出す前の計画ステップを LLM に委ねるようなエージェント的アプリケーションでよくあるタイプのタスクだ。
プロンプト
I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.
注目すべき暗黙の制約は次の3点だ。質問では「チャーン」の定義がない（アカウント閉鎖か？ログインなし？購入なし？）。機能 X に無関心であること以外の交絡をどう制御するかが指定されていない（低エンゲージメントのユーザーは機能 X と無関係な理由でチャーンする）。そしてベースライン比較群が確立されていない。慎重なプランナーなら、ステップを列挙する前にこれら3点を表面化させるはずだ。
注目ポイント
モデルが問題を本当に論理的に考えているか、それとも一見もっともらしい手順を並べつつ精査すると破綻するものを出していないか。暗黙の制約を指摘なしで自発的に特定できるか。そしてステップ間の依存関係が正しいか——一見良さそうに見えるが、3番目のステップが5番目の結果に依存しているような計画は実務上無価値だ。
この演習を実施したチームが一貫して報告すること
GPT-5.5。 最もオペレーションに使いやすい計画になることが多い。推論が可視化される傾向があり——GPT-5.5 は暗黙の制約（チャーン定義、対照群、交絡）に関する前提を列挙してからステップを示すため、意図と解釈の差分が見つけやすい。ステップ依存関係を確実に特定し、ラベル付けする。要求されていないが価値のある付加として、どのステップが並列化可能かを示すセクションが入ることも多い。これは GPT-5.5 のツール使用・エージェント的学習が現れるタスクで、下流に実行が続くことを前提に計画の振る舞いが形作られている。
Claude Sonnet 4.6。 文字通り「最も思慮深い」計画を出力することが多い——他の2モデルが挙げない配慮が盛り込まれる。この種の問いでは、Claude は相関と因果の方法論的な問題を指摘し、「機能 X を使っていない」こと自体がチャーンの結果であって原因ではない可能性に言及し、明示されていないが慎重なアナリストなら気づくべき制約を明確にする。一方で、計画が必要以上に長くなったり、個々のステップが実際の問いに対して過剰設計になることがある。このパターンは他でも一貫しており——専門家レベルの配慮、時にタスクに必要な以上の丁寧さ——という Claude の振る舞いに一致する。
Gemini 3.1 Pro。 最も構造が明晰で、依存関係グラフが読みやすい計画になることが多い。推論の質は高く——Gemini は暗黙の制約を確実に特定し、問題を妥当なシーケンスに分解し、実行可能な手順を段階的に提示する。欠点は、やや機械的に感じられること。仕事はやり切るが、Claude のような方法論的な機微や、GPT-5.5 のような並列化の洞察は表面化しにくい。これは Gemini のより広いパターンと一致しており——推論の質は強いが、周辺の判断は実務的で淡々としている。
何が分かるか
このタスクにおける推論品質は3モデルとも高い。差は、文字通りの要求を越えてモデルが何を付け加えるかという「周辺の振る舞い」にある。GPT-5.5 はオペレーション上の実用性（並列化、実行ヒント）を加える。Claude は専門家的配慮（方法論、エッジケース、統計的ニュアンス）を加える。Gemini は明晰さと簡潔さを加える。どれも間違いではない。どれが適合するかは、モデルがタスクを終えたあと「何をしてほしいか」によって変わる。
プロンプト3: 明確な制約つきのコード生成
このプロンプトは、さほど単純ではないが小さな関数の実装を求める。タイムスタンプ付きイベントのリストを受け取り、連続するイベント間の最長ギャップ（秒）を返す Python 関数で、4つのエッジケースに対応することを要求する。制約下のコード生成を試す意図であり、能力の天井を測る意図ではない——この関数はどのモデルでも書ける。違いは、制約をどう扱うかに現れる。
プロンプト
Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases: 1. Empty list (return 0.0 or raise — your choice, but be consistent) 2. Single event 3. Duplicate timestamps 4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.
注目ポイント
4つのエッジケースすべてに対応しているか、一部を黙殺していないか。型ヒントが正確か、形ばかりでないか。実装が妥当なアルゴリズム（ソートして走査）を選んでいるか、それとも奇をてらっていないか。そしてプロンプト末尾の「テストや使用例は不要」という制約を尊重するか——この手の末尾指示は、指示遵守の強いモデルは守り、弱いモデルはそっと破りがちだ。
この演習を実施したチームが一貫して報告すること
GPT-5.5。 最も入念に作り込まれたコードになることが多い。4つのエッジケースに明示的な分岐で対応し、型ヒントは精密（返り値のエッジケースに Optional や Union を用いることも）で、例示を含む docstring が付く。実装は概ね当然のアルゴリズム——ソート、走査、最大ギャップの追跡——を選び、正しい。知っておくべき点として、プロンプトで関数のみを求めていても、GPT-5.5 はユニットテストや使用例を付けがちだ。オペレーション実務志向のモデルのトレードオフで、頼んでいなくても必要そうなものを足してくる。
Claude Sonnet 4.6。 最も可読性の高いコードになることが多い。関数は簡潔で、エッジケースは先頭のガード節パターンで処理し、型ヒントは正確かつ最小限。プロンプトが判断を委ねた点について、思慮深いコメントを添えることがある——例えば重複タイムスタンプは長さゼロのギャップとして扱う、といった説明。これはプロンプトに明示されていないが妥当な判断だ。Claude は GPT-5.5 よりも「テスト不要」という制約を守る傾向が強い。関数自体は最も保守しやすい。コード品質の評価における Claude の評判——クリーン、慣用的、熟練者らしい——と一致する。
Gemini 3.1 Pro。 3者の中で最も簡潔なコードになることが多い。関数は正しく、エッジケースに対応しつつ最小の実装。docstring は一行のことが多い。型ヒントは過不足なく正確。Gemini の解法はテストや過度のコメントをほとんど付けず、過剰設計しない——まさにプロンプトの要求どおりだ。関数が動きさえすれば、テストは別途自分で足したい開発者には最短経路となる。一方、周辺の作業もモデルに期待するなら、他の2モデルのほうが（頼んでいなくても）多くを付け加えてくれる。
何が分かるか
3モデルとも関数は書ける。差は、文字通りの要求を越えてどれだけ周辺作業を行うか、そして明示的な「X を追加しないで」という否定指示をどれだけ厳密に守るかにある。GPT-5.5 は周到さに寄る（周到さを不要と明示してもなお）。Claude はクラフトに寄る（読みやすいコード、判断の説明）。Gemini は簡潔さに寄る（言われたことだけ、余計なものなし）。モデルの出力がそのまま本番コードベースに流れ込むエージェント的ワークフローでは、望ましい振る舞いは下流のレビュー工程が何を期待するか、そして否定指示をどれだけ厳密に守る必要があるかに依存する。
見えてくるパターン
上記3つのプロンプトを跨いで、2026年を通じて公開された比較調査や開発者レポートから、3つの一貫した振る舞いパターンが現れる。これは能力主張ではない——いずれのタスクも各モデルは高いレベルでこなす。傾向であり、同一モデルが数十のプロンプトに対処する様子を観察して初めて見えてくる類のものだ。上のプロンプトを自分の環境で走らせれば同じパターンが見えるはずだ。この記事は、それを観察する際に何を見ているのかを認識するためのフレームワークを提供する。
| Model | Behavioural tendency | Fits best when… |
|---|---|---|
| GPT-5.5 | オペレーション実務志向。実行上のヒント、防御的コーディング、下流に優しい出力を付加。エージェント・ツール使用形のタスクに強み。 | モデル出力をそのまま後続の実行に連鎖させる——エージェント、ワークフロー、次のステップが自動化されたパイプラインなど。 |
| Claude Sonnet 4.6 | 専門家レベルの配慮。文字通りの要求を越える考慮を表面化し、倫理や方法論の懸念を挙げ、非常に読みやすいコードを生成。 | 出力を人間がレビューするアプリケーション——コンテンツ生成、コードレビュー、クラフトが重要な分析など。 |
| Gemini 3.1 Pro | 簡潔で直接的。頼んだことだけ、それ以上はしない。同等の仕事で最もクリーンなスキーマ順守と最小トークン出力。 | 出力要件が厳格、コスト予測可能性が優先、あるいはモデルに思慮深い協働者ではなく精密な道具としての振る舞いを求める場合。 |
重要な留意点。これらのパターンは傾向であり、規則ではない。適切なプロンプト設計でいずれの振る舞いにもステア可能だ——詳細なシステムプロンプトで Gemini にテストを追加させたり、Claude を最小出力に制約したり、GPT-5.5 にユニットテストを省かせることはできる。肝心なのは、ステアする前の「デフォルトで何をするか」だ。デフォルトの振る舞いこそ、積極的に逆方向にプロンプトしない限り本番で日々向き合うことになる。
自分のワークロードでのテスト方法
上の演習はどんなワークロードでも再現可能だし、そうすべきだ。ベンチマークスコアは最初のフィルタとして有用だが、あなたのアプリケーションにとって重要なモデルの振る舞いパターンは、あなたのプロンプトに対処するモデルの様子を観察して初めて見える。
実トラフィックで演習を回すための実践ガイド:
- 代表的なプロンプトカテゴリを3つ選ぶ。ランダムな3プロンプトではなく、ワークロードをカバーする3カテゴリ。多くの本番システムは、抽出、分類、生成、推論、コード、要約といった少数のタイプに分解できる。トラフィックの大半を占めるカテゴリを選ぶ。
- カテゴリごとに20〜30件の例をキュレートする。可能なら実トラフィックから。必要に応じて匿名化を。肝心なのは、プロンプトが実際にアプリケーションが見るものに似ていること——ベンチマーク問題のようでないこと。カテゴリあたり20件でパターンが見え、30件で確信が持てる。
- 単一エンドポイント、全モデルで実行する。OpenAI 互換の集約エンドポイントを使うと、各モデルの SDK ごとに回すより格段に速い。この記事冒頭のコードがセットアップのすべてだ。同じ温度、同じパラメータ、同じプロンプト——出力の差はモデルの差だ。
- 量的評価の前に質的評価。まずは目視で。振る舞いパターンは最初の十数件で概ね明らかになる。各モデルのワークロード上の振る舞いに関する仮説ができてから、採点ルーブリックを構築して定量化すればよい——仮説は観察から生まれ、事前に作られたテンプレートからは生まれない。
- モデルが「付け加えるもの」に注意。ベンチマークの問いは「正答できたか」だ。振る舞いの問いは「他に何をするか」だ。テストを追加するか。推論を説明するか。懸念を提起するか。要求しなかった追加フィールドを出すか。違いはここに宿る。
- 下流に合うモデルを選ぶ。下流プロセスが自動なら、デフォルトでクリーンかつパース可能な出力を出すモデルが望ましい。下流プロセスが人手レビューなら、デフォルトで周辺的な判断を添えるモデルが望ましい。正解は、モデルの後に何が来るかに依存する。
結論
GPT-5.5、Claude Sonnet 4.6、Gemini 3.1 Pro の選択は「どのモデルが最良か」ではない。「どのモデルがあなたのワークロードの形に合うか」だ——その形はベンチマークには見えない。プロンプトを用意できていれば、この演習は半日で再現できる。やる価値は、当て推量をやめ、観察に基づく判断へ移れることにある。
実施するチーム向けに：最も容易なセットアップは、3モデルすべてを単一の認証の裏に置いた OpenAI 互換エンドポイントだ。CometAPI はその一つの選択肢。既存の OpenAI SDK の base URL を差し替え、model パラメータを変数にすればよい。
ベンチマークは、モデルが「できること」を教えてくれる。振る舞いパターンは、あなたのプロンプトに対してモデルがデフォルトで「どうするか」を教えてくれる。前者は公開されている。後者は自分で観察するしかない。カテゴリごとに20件、半日あれば、どのリーダーボードにも載らない答えが手に入る。
信頼性高く統合する準備はできていますか？CometAPI と API doc へ。Claude Fable 5 を含む他のフロンティアモデルとシームレスに併用できる統合、統一課金、エンタープライズ級の信頼性を提供。今すぐサインアップして新規ユーザー向けの手厚いクレジットで開始しましょう——次のブレイクスルーが待っています。