Solの内部処理を会話ログから見てみた。内部で複数段階で検索をしていた

結論

ChatGPTのモデル選択でSolを選び、「クレジットカードのおすすめを教えて」と聞きました。その会話JSONには16個のメッセージ（0番〜15番）が記録されていて、画面には出ない内部処理まで順番に追えます。

Solは検索を3段階に分けていました。

1. 広く探す：カード会社5社の公式ドメインを、1社1本ずつ検索する
2. ページを指定して探し直す：site: にページのパスまで書き、特定の商品ページを取りに行く
3. 足りない所だけ追加で調べる：途中で候補に加えたカードと、まだ見つからないカードを探す

思考は29秒で、回答が出終わるまで約52秒かかりました。旧モデル（ログ上 gpt-5-6）で取った10件のログは、検索が1〜2回、思考は数秒〜7秒でした。旧モデルが必ず最初にやっていた「質問文をそのまま検索に渡す」手順は、Solのログにはありませんでした。

Figure

Solの検索は3段階だった

1. 1

   前置きを出す（11秒）

   検索の前に、選び方の軸を画面に出す

2. 2

   1段目：広く（13秒）

   5社の公式ドメインに限定して5本

3. 3

   2段目：ページ指定（17秒）

   site: にパスまで書いて3本

4. 4

   3段目：補う（25秒）

   途中で加えた候補と、見つからない候補を2本

5. 5

   回答（36〜52秒）

   5枚を表で推薦し、公式ページを引用

これは1回の会話の記録です。「Solは必ずこう動く」ではなく、「この条件でこう動いた」という観測として読んでください。

何を見たのか

取得条件は次のとおりです。

• 2026-09-10 23:06（JST）、ログイン状態のChatGPT
• モデル選択はSol。ログには model_slug: "gpt-5-6-thinking"、thinking_effort: "extended" と記録されている。ログの中にSolという名前は出てこない
• メモリは有効（model_editable_context のメッセージがある）。カスタム指示はログに残らないため不明
• 新規チャットで、回答が完走してから会話JSONを取得
• プロンプトは「クレジットカードのおすすめを教えて」

比較には2つを使いました。1つは2026-09-05〜06に同じ方法で取った gpt-5-6 の会話ログ10件（SEO・GEOツールの質問、メモリ無効）です。もう1つは、同じクレジットカードの質問を gpt-5-6 で取った記事30（2026-08-31、無料プラン）です。どちらも、モデル以外の条件がそろっていません。 違いがすべてモデルによるものだとは言えない点に注意してください。

会話JSONの取り方は記事30の手順と同じです。ブラウザの開発者ツールでNetworkタブを開き、会話IDでフィルタして conversation のレスポンスを保存します。

0番〜15番の一覧

messages 配列の16個を、並び順に並べます。経過はユーザーが送信した時刻からの秒数です。

#	役割	種類	経過	何をしているか
0	system	text（空）	5.9秒	会話の土台。画面には出ない
1	user	text	0秒	質問
2	system	text（空）	7.6秒	プラグイン勧誘の枠。思考の開始時刻（6.3秒）を記録
3	assistant	model_editable_context	7.8秒	メモリの枠（中身は空）
4	assistant	text / commentary	11.1秒	検索前の前置き
5	assistant → web.run	code	13.2秒	1段目の検索指示（5本）
6	tool（web.run）	text（空）	13.4秒	1段目のクエリ一覧。画面の「〜を検索中」用
7	tool（web.run）	text（空）	14.1秒	1段目の検索結果
8	assistant → web.run	code	16.9秒	2段目の検索指示（3本）
9	tool（web.run）	text（空）	17.7秒	2段目の検索結果
10	assistant → web.run	code	25.1秒	3段目の検索指示（2本）
11	tool（web.run）	text（空）	26.2秒	3段目の検索結果
12	assistant	thoughts	33.0秒	思考の要約「比較方針を整える」
13	assistant	thoughts	35.7秒	画面の折りたたみ表示「3件のウェブサイトを検索しました」
14	assistant	reasoning_recap	35.7秒	思考の終了「29s考えました」
15	assistant	text / final	35.8〜51.7秒	回答本文と引用

配列の順番と時刻は一致しません。0番の system は、1番のユーザーの質問より6秒ほど後に作られています。

0〜3番：回答の準備

0番は中身の無い system メッセージで、is_visually_hidden_from_conversation: true が付いています。会話の土台です。

1番がユーザーの質問「クレジットカードのおすすめを教えて」です。

2番も中身の無い system メッセージで、exclusive_key: "plugin_upsell" が付いています。プラグインを勧める枠で、今回は何も出していません。このメッセージに思考の開始時刻（reasoning_start_time）が記録されていて、送信から6.3秒後でした。model_slug: "gpt-5-6-thinking" と thinking_effort: "extended" も、ここから後のメッセージすべてに付いています。

3番は model_editable_context です。モデルが参照するメモリの枠で、中身は空でした。このメッセージがあることが、メモリ有効の印になります。

4番：検索の前に、方針を先に見せる

4番は、検索を1回もしていない段階で画面に出す一文です。

日本で使う前提なら、「年会費無料」「還元率」「よく使う経済圏」で選ぶと失敗しにくいです。いまの特典や条件を確認して、用途別に絞ります。

channel: "commentary"、is_thinking_preamble_message: true が付いています。旧モデルの10件には1件もありませんでした。

ここで出た「年会費」「還元率」「用途別」は、最終回答の表の列（年会費・基本還元・向いている人）とそのまま対応しています。回答の骨組みは、検索する前にできていたことになります。

5〜7番：1段目　公式ドメインを5社ぶん広く探す

5番が1段目の検索指示です。recipient: "web.run" のメッセージで、content.text にクエリが1行1本で書かれています。

fast|三井住友カード NL 年会費 還元率 公式 2026|30|smbc-card.com
fast|楽天カード 年会費 還元率 公式 2026|30|rakuten-card.co.jp
fast|JCB CARD W 年会費 還元率 公式 2026|30|jcb.co.jp
fast|dカード 年会費 還元率 公式 2026|30|d-card.jp
fast|PayPayカード 年会費 還元率 公式 2026|30|paypay-card.co.jp
length|medium

| で区切られた項目は、左から速度モード、クエリ本文、新しさの絞り込み（30 は直近30日と推定）、ドメインの絞り込みです。最後の length|medium は回答の長さの指定と推定しています。この形式は非公開の内部仕様で、読み方はログからの推定です。

ユーザーはブランド名を1つも出していないのに、5社の名前と、それぞれの公式ドメインがすでに書かれています。候補も、どのサイトで確かめるかも、検索の前に決まっていました。 記事71で見た「候補は検索の前に決まっている」と同じ動きです。

6番は検索ツール側のメッセージで、metadata.search_model_queries.queries に同じ5本が入っています。画面の「〜を検索中」の表示に使われるものです。このメッセージは1段目にしかなく、2段目・3段目には対応するものがありません。

7番が1段目の検索結果です。metadata.search_result_groups に、JCB 4件、三井住友カード 2件、PayPayカード 3件の計9件が入っていました。スニペットは全件空です。画面には「3件のサイトを検索中」と出ます。ただし最終回答（15番）の記録を見ると、1段目では楽天カードの結果も返ってきていました。7番に入っているのは、返ってきた結果の一部です。

8〜9番：2段目　ページを指定して探し直す

8番は、1段目の結果が返ってから2.8秒後に出た2段目の検索指示です。

fast|site:rakuten-card.co.jp/card/rakuten-card/ 年会費 永年無料 1% 楽天カード
fast|site:d-card.jp/st/abouts/d-card/ 年会費 永年無料 還元率 dカード
fast|site:smbc-card.com/nyukai/card/numberless.jsp 対象 コンビニ 飲食店 7% 2026
length|medium

1段目がドメイン単位だったのに対して、2段目は site: にページのパスまで書いて、特定の商品ページを取りに行っています。確かめたい条件（「永年無料」「1%」「7%」）もクエリに書かれています。

9番が2段目の結果です。三井住友カード 9件、楽天カード 4件の計13件で、dカードのページは0件でした。

10〜11番：3段目　足りない所だけ追加で調べる

10番は3段目の検索指示です。2段目の結果から7.5秒空いていて、検索の合間では最も長い間でした。

fast|site:smbc-card.com 三井住友カード ゴールド NL 年間100万円 10000ポイント 継続特典
fast|site:d-card.jp dカード 基本還元率 1% 年会費 永年無料
length|short

調べているのは2つだけです。1つは、1段目には無かった三井住友カード ゴールド（NL）です。このカードのページは1段目・2段目の結果にすでに出ていて、3段目で初めて名指しされました。もう1つは、2段目でも見つからなかったdカードです。長さの指定も short に下がっています。

11番が3段目の結果です。三井住友カードの公式ページ6件と、同社のFAQ（faq-mem.smbc-card.com と qa.smbc-card.com）が1件ずつで、計8件でした。dカードはここでも0件です。

12〜14番：思考を閉じる

12番は思考の要約です。見出しは「比較方針を整える」で、本文は次のとおりでした。

検索結果が十分でないため、断定を避けつつ、利用目的別に候補を整理している。楽天カード、三井住友カードNL、JCBカードW、PayPayカードを軸に、年間利用額や普段の店を確認して選びたい。

ここでdカードが候補から消えています。 検索結果が足りないことを、モデル自身が判断していることもわかります。summary_type: "raw_cot" という旧モデルのログには無かったフィールドも付いています。

13番は、画面で思考を折りたたんだときの表示「3件のウェブサイトを検索しました」です。source_message_ids で束ねているのは5・6・7番、つまり1段目だけでした。画面上は1回の検索に見えますが、実際には3段階で10本の検索が走っています。

14番は思考の終了で、「29s考えました」と記録されています。開始（2番に記録された6.3秒）から終了（35.6秒）までの長さです。

15番：回答

15番が回答本文です。送信から35.8秒後に書き始め、51.7秒後に書き終わっています。本文は、5枚のカードを「向いている人・年会費・基本還元」で並べた表と、1枚ずつの説明でした。

• 楽天カード
• 三井住友カード（NL）
• JCBカード W
• PayPayカード
• 三井住友カード ゴールド（NL）

最後は「年齢・月にカードで使う金額・よく使う店を教えてくれれば、あなたならこの1枚まで絞れます」と聞き返して終わっています。「2026年9月時点なら」という書き出しで、日付も前提にしていました。

メタデータには2つのものが入っています。

• content_references：引用5件（すべてピル型の grouped_webpages）と、回答末尾の出典欄（sources_footnote、4件）
• search_result_groups：スニペット付きの候補一覧（73件）

引用の refs[].turn_index は 0 / 1 / 2 で、それぞれ1段目・2段目・3段目の検索を指します。本文の引用マーカーには turn155362 のような別の番号が使われていて、7・9・11番の結果に付いている ref_id.turn_index と対応しています。

旧モデルとの違い

2026-09-05〜06に取った gpt-5-6 の10件と比べます。質問のカテゴリ（SEO・GEOツール）とメモリの設定が違うので、目安として見てください。

	旧モデル（gpt-5-6、10件）	Sol（今回）
質問文をそのまま検索に渡す手順	10件すべてにあった	なし
検索の段階	1〜2回	3回
思考時間	「数秒間」〜7秒	29秒
回答が出終わるまで	送信から3〜24秒	約52秒
検索前の前置き	なし	あり
思考の要約の形式（summary_type）	記録なし	raw_cot

質問文をそのまま検索に渡す手順が消えたのが、並びの上で最も大きな違いです。 旧モデルは10件すべてで、最初に recipient: "web" のメッセージで search("質問文そのまま") を実行し、そのあとで書き換えたクエリを web.run に投げていました。Solは、最初からブランドごとのクエリを書いています。

同じクレジットカードの質問どうし（記事30）で比べると、検索の中身も違いました。

	記事30（gpt-5-6）	Sol（今回）
検索	1回・3本	3回・10本
1本目のクエリ	英日混在で、4ブランドを1本に	日本語で、1ブランド1本
ドメインの指定	なし（クエリに「公式」の語）	1段目の5本すべて
候補URL	36件・14ドメイン	78件・4ドメイン
比較メディア	候補14件・引用0件	候補0件
引用	4URL・2ドメイン	主引用5URL・4ドメイン

ドメインの指定そのものは旧モデルにもありました。SEOツールの質問10件のうち3件で使われ、site: は8件で使われています。違ったのは使い方で、今回は1段目の全部を公式ドメインに限定してから始めています。そのため、比較メディアは候補に入る余地がありませんでした。記事30では、比較メディアは候補に入ったうえで引用されずに落ちていました。

Figure

旧モデルとSolの内部処理

旧モデル（gpt-5-6）

思考 数秒〜7秒

• 最初に質問文をそのまま検索
• 検索は1〜2回
• 前置きは出ない
• クレカでは比較メディアも候補に入った

Sol（gpt-5-6-thinking）

思考 29秒

• 最初からブランドごとのクエリ
• 検索は3段階（広く→ページ指定→補う）
• 検索前に前置きを出す
• 1段目から公式ドメインに限定

3段とも空振りしたdカード

段階を追うと、dカードは1段目から候補に入り、3段とも検索されていたことがわかります。

1. 1段目：ドメイン指定 d-card.jp
2. 2段目：site:d-card.jp/st/abouts/d-card/
3. 3段目：site:d-card.jp

3回とも、dカードの公式サイトの結果は1件も返っていません。そして12番の思考の要約で候補から外れ、回答にも出てきませんでした。

NTTドコモの告知によると、dカードのサイトは2022年10月に d-card.jp から dcard.docomo.ne.jp へ変わっています。取得した日（2026-09-10）に確認すると、d-card.jp へのアクセスは dcard.docomo.ne.jp に301で転送され、2段目で指定されていたパス /st/abouts/d-card/ は転送先で404でした。

ここからは解釈です。 モデルは、公式サイトのドメインとパスを記憶から書き込んでいます。書き込まれたのは移転前のドメインで、検索がそのドメインのとおりに絞られたため、今のサイトが外れたと読めます。ただし、正しいドメインで検索していればdカードが推薦に残ったかは、このログからはわかりません。

引用とスニペット

引用5件は、それぞれ主引用1件と補助1件の組で、どちらも同じ会社のドメインでした。主引用の5URLはスニペット付きの候補一覧に1件も入っておらず、補助の5URLはすべてスニペット付きで入っていました。 リンクを張る先と中身を渡したページが別という構造は、記事30・記事70と同じです。

回答の数字の多くはスニペットにそのまま書かれていました。三井住友カード ゴールド（NL）の「通常5,500円」「年間100万円で翌年以降永年無料」「毎年10,000ポイント」などです。一方で、三井住友カード（NL）の7%還元の対象店として挙げたローソン・マクドナルド・吉野家などの店名や、JCBカード Wの優待店として挙げたAmazon・スターバックスは、どのスニペットにもありません。ページ本文を取得した記録はログに無いので、これらが主引用ページの本文から来たのか、モデルの事前知識から来たのかは決められません。

やること／やらなくていいこと

Figure

複数段階の検索を前提に点検する

やること

• ✓自社の質問をSolと旧モデルの両方で実行し、ログを残す
• ✓クエリに書かれた自社ドメインとパスが現行か確認する
• ✓よく指定される商品ページに、比較される条件を日付付きで書く
• ✓比較メディアは、モデルごとに候補入りの有無を記録する

やらなくていいこと

• ✕画面の「◯件のウェブサイトを検索しました」だけで検索量を判断する
• ✕旧ドメインの301転送だけで対応済みとみなす
• ✕1回の結果で、Solと旧モデルの差を結論にする

2段目では、ドメインだけでなくページのパスまで指定されていました。URLを変えたページは、ドメインが同じでも同じ空振りが起きうるということです。商品ページのURLを変えるときは、この点も考えに入れてください。

手順

1. ChatGPTで、自社カテゴリの比較・推薦の質問を1回投げる。Solと旧モデルで同じ質問を実行する
2. ブラウザの開発者ツールでNetworkタブを開き、会話IDでフィルタして conversation のレスポンスJSONを保存する
3. messages を先頭から読み、recipient が web.run のメッセージを数えて、検索が何段階あったかを確認する
4. 各段のクエリから、ドメイン指定（| の4項目め）と site: のパスを取り出し、自社のものが現行か確かめる
5. 最終メッセージの search_result_groups と content_references で、自社が候補に入ったか、引用されたかを見る

この観測から言えること

• 今回の会話では、検索が3段階（ドメイン単位→ページ単位→補足）に分かれていた
• 旧モデルの10件すべてにあった「質問文をそのまま検索に渡す」手順が、今回は無かった
• 1段目の5本はすべて公式ドメインに限定され、候補78URLに比較メディアは無かった
• dカードは移転前のドメインで3回検索され、結果は0件で、思考の途中で候補から外れた

標本は1件です。 旧モデルとの比較は、日付・プラン・質問・メモリの設定もそろっていません。

よくある質問

画面に「3件のウェブサイトを検索しました」と出たら、検索は3件だけですか

今回は違いました。その表示を作る13番のメッセージが束ねていたのは1段目の検索だけで、実際には3段階で10本のクエリが投げられていました。検索の量は、会話JSONで recipient が web.run のメッセージを数えて確かめてください。

旧モデルとSolで、いちばん大きな違いは何でしたか

処理の並びでは、質問文をそのまま検索に渡す手順が無くなったことです。旧モデルは10件すべてで最初にこの手順を踏んでいましたが、Solは最初からブランドごとのクエリを書いていました。もう1つは時間で、思考は数秒〜7秒から29秒に、回答が出終わるまでの時間は約52秒に伸びています。

比較メディアは、Solでは紹介されなくなるのですか

今回の1回ではそうなりました。1段目の検索が公式ドメインに限定されていたので、比較メディアは候補にも入っていません。ただし標本は1件です。比較メディアを運営しているなら、自分のカテゴリの質問で候補に入っているかを、モデルごと・日ごとに記録してください。

会話JSONのどこを見れば、段階がわかりますか

messages 配列を先頭から読み、recipient が web.run になっているメッセージを探します。今回は5番・8番・10番の3つで、それぞれのすぐ後に検索ツールからの結果（7番・9番・11番）が続いていました。検索の合間の時間は create_time の差で測れます。

回答に書かれたカードの条件は信用できますか

多くは公式ページのスニペットにそのまま書かれた内容でしたが、スニペットに無い店名なども書かれていました。この記事ではカードの条件の正誤は確かめていません。申し込む前には、各社の公式ページで確認してください。