AI の「魂」を覗く：Gemini 3.1 の思考チェーン（CoT）漏洩でコードロジックをデバッグする

Gemini 3.1 Pro が生成した再帰関数を 3 回テストしたら、3 回とも結果が違いました。乱数のせいではなく、ある分岐でロジックが「漂流」していたのです。AI にコードを書かせるとき、私たちはずっとブラックボックス扱いでした。プロンプトを入れ、コードを受け取る。途中で何が起きたかは知らないし、気にもしない——コードがおかしくなるまで。

特定のプロンプト設計で、Gemini の「思考の下書き用紙」を表に出せます。きれいに整えた要約ではなく、生の、ときに乱れた内部推論そのものです。この思考チェーン（CoT）漏洩から、隠れた前提、推論のショートカット、自己矛盾が見えてきます。

本記事では、思考チェーン（CoT）を使って AI コードをデバッグする方法を共有します。Gemini 3.1 Pro の thinking_level パラメータ、漏洩のトリガー条件、診断事例、プロンプト最適化のコツまで。玄学的な話ではなく、実務で使える手法です。

思考チェーン（CoT）漏洩とは

まず概念を整理します。

**思考チェーン（Chain of Thought, CoT）**は、大規模モデルが複雑な推論をするときの中核メカニズムです。最終回答の前に思考過程を書き出す——数学を解くときに下書き用紙に手順を書くのと同じイメージです。

Gemini 3/3.1 Pro には thinking_level パラメータがあり、内部推論の深さを制御できます。低いと答えだけ、高いと多段推論・自己修正・経路計画が入ります。

ただし落とし穴があります。公式の「Thinking」ブロックは二次加工された要約で、生の思考チェーンではありません。

Reddit の開発者が、特定の入力で Gemini 3 Pro が本物の生思考チェーンを漏らすことを報告しました。自己疑念、誤った試行、「再帰ループ」まで含む、生の推論過程です。

AI が頭の中でつぶやいている様子を想像してください。

「ユーザーはソートを求めている……クイックソート？データが少ない、再帰のオーバーヘッドが大きい……バブルソートは格好が悪い……Python の sorted もあるが、自作と言われた……ならマージソート。安定で効率も悪くない……」

この独り言レベルの情報は、プロンプトとコード品質のデバッグに大きな価値があります。

思考チェーン漏洩を引き出す方法

ここから実践です。

Gemini 3.1 Pro の漏洩は、だいたい次の状況で起きます。

ケース 1：極端に複雑なロジック問題

複雑さが閾値を超えると、正答のために中間推論を露出せざるを得ません。API の生トークンストリームを注意深く見ると、<thinking> タグ内が通常より豊かなことがあります。

ケース 2：行き詰まったときの自己修正

Reddit では、再帰ループや論理の行き止まりで Gemini が「unhinged（やや制御不能）」に見える例が報告されています。このとき内部チェックが思考チェーンを sanitize（クリーンアップ）する前に、生推論が漏れることがあります。

ケース 3：プロンプト設計

漏洩確率を上げるコツがあります。

「誤った試行も含めて思考過程をすべて見せて」と明示する
「下書き用紙」フレーム：「まず下書き用紙で分析してから答えて」
追及型：「推論に飛躍がある。各ステップを詳しく説明して」

実用ヒント：Gemini API で thinking_level: "high" を設定し、返却の thinking フィールドを解析してください。text より価値があることもあります。

思考チェーンからロジック問題を診断する

漏洩した思考チェーンで何ができるか。実例です。

事例 1：隠れた前提の発見

ユーザー入力を処理する関数を書かせたとき、コードは問題なさそうでした。思考チェーンにはこうありました。

「ユーザー入力は常に有効な JSON 形式と仮定する……」

待ってください。JSON 限定なんて言っていません。モデルが勝手に足した前提です。思考チェーンを見ていなければ、本番に紛れ込んでいたでしょう。

事例 2：推論のショートカット

DB クエリ最適化を依頼したとき、インデックス付きのコードが返り、プロっぽく見えました。思考チェーンはこうでした。

「クエリ最適化だ……インデックス追加がいちばんよくある手法……インデックスを勧めよう……」

問題は、既存のクエリプラン、データ分布、インデックスの有無を分析していないことです。「最も正しい」ではなく「最も手間の少ない」答えを選んでいます。

事例 3：自己矛盾

自分で自分の考えを否定するときです。思考チェーンにこう出ることがあります。

「手法 A はこの境界で失敗する……でも多くのケースでは動くから、やはり A を推奨する」

どこに防御コードやテストを足すべきか、矛盾が境界のヒントになります。

CoT でプロンプトをデバッグ・最適化する

思考チェーンはコードだけでなく、プロンプトの X 線写真にもなります。

テクニック 1：プロンプトの「聞き取り」を確認する

明確に伝えたつもりでも、モデルの解釈は別物かもしれません。思考チェーンで「何を聞いたか」が見えます。

例：「効率的な関数を書いて」

思考チェーンでは次のように割れます。

「効率＝時間計算量が低い」
「効率＝メモリが少ない」
「効率＝コードが短い」

解釈が違えばコードも違います。曖昧さに気づけば、プロンプトを絞れます。

テクニック 2：知識の空白を見つける

「うーん……確信がない」「おそらく……」といった迷いは、その知識に自信がないサインです。そのときは、

プロンプトにコンテキストを足す
もっと単純な実装に切り替える

のが有効です。

テクニック 3：推論の方向を誘導する

思考の癖が見えれば、プロンプトで意図的に誘導できます。

常に再帰から入るなら、「再帰が明らかに簡潔な場合を除き反復を優先」と足す。

境界を無視するなら、「空入力と極端値の境界処理に特に注意」と書く。

限界と注意点

正直、万能ではありません。

限界 1：漏洩は不安定

Google は露出を抑えようとしています。見える量は版、パラメータ、運に左右されます。今日使えた手が、明日は効かないこともあります。

限界 2：思考チェーンも間違う

見えるのは「思考の様子」で、正しさの保証ではありません。自信満々の推論の末に、結論だけが外れることもあります。

限界 3：過度な依存は遅い

分析は時間がかかります。単純タスクは出力を直接見た方が早い。複雑ロジックや繰り返し不具合のときだけ使うのが現実的です。

倫理面の注意

Google は生の思考チェーンを見せたいとは考えていません。内部の覗き見と見なされる可能性があります。正式プロジェクトでは、

漏洩 CoT だけで重要判断をしない
API ドキュメントの更新に注意する（挙動はいつでも変わり得る）
利用規約を守る

ことが大切です。

おわりに

結局、思考チェーン漏洩でのデバッグは「リバースエンジニアリング」的な発想です。

AI をブラックボックスの神託にして、問いを投げれば正答が返る——そう期待しがちです。でも AI も間違え、空白もあり、近道もします。

「下書き用紙」が読めると、受動的な答えの受け手から、能動的な推論の監査役になれます。その視点の転換は、より良いプロンプトと、より信頼できるコード生成に直結します。

ある深夜 3 時、Gemini の思考チェーンを読んで、再帰の終了条件で境界が 1 つ抜けていることに気づきました。プロンプトに明確な注意を足して再生成したら、直りました。

覚えているのは最終コードだけではなく、思考チェーンの中で自己修正していた AI の姿です。AI も間違える。でもより良くなろうと試す。私たちにできるのは、その試行を読むことです。

試すなら、少し複雑なプログラミング問題を選び、高い thinking_level で Gemini 3.1 Pro を呼び、「Thinking…」の裏を丁寧に見てください。何が見つかるか、驚くかもしれません。

もしかしたら、AI の「魂」の一端に触れられるでしょう。

FAQ

Chain of Thought（思考チェーン）とは何か。AI コードのデバッグに何が役立つのか

Chain of Thought（CoT、思考チェーン）は、大規模モデルが回答の前に思考過程を示すよう促す技法です。

AI コードのデバッグでは次の価値があります。
• モデルが置いた隠れた前提（例：「入力は常に JSON 形式」）を確認できる
• 問題を本当に理解しているのか、推論の近道をしているだけなのかを見極められる
• 自己矛盾を見つけ、潜在的なバグを先回りできる

要するに、思考チェーンは AI の「下書き用紙」で、独り言レベルの推論の詳細が残っています。

Gemini 3.1 Pro で思考チェーン漏洩を引き出すには

主な方法は次のとおりです。

1. **thinking_level パラメータ**：「high」で推論の深さを上げる
2. **複雑な問題**：複雑さが閾値を超えると、中間推論ステップの露出が増える
3. **プロンプト設計**：
- 「誤った試行も含めて思考過程を見せて」と要求する
- 「下書き用紙」フレーム：「まず下書き用紙で分析して」
- 追及型：「推論に飛躍がある。各ステップを詳しく説明して」

注意：漏洩は不安定で、モデル版と公式の制限方針に左右されます。

思考チェーンから見つかるロジック上の問題の種類

分析すると主に 3 類型があります。

**隠れた前提**：未検証のままモデルが足した前提（入力形式、データ範囲など）

**推論のショートカット**：分析を飛ばし、「最も正しい」ではなく「最もありがちな」答えを選ぶこと

**自己矛盾**：問題があると分かっていながら推奨するなど、追加検証が要る境界のサイン

見つけたら、プロンプトに制約やリマインダーを明示して修正します。

思考チェーンでプロンプトをデバッグする実用テクニック

3 つのコアです。

**理解のズレの確認**：思考チェーンで指示の解釈を観察し、意図とずれた曖昧さを洗い出す

**知識の空白の発見**：「確信がない」「おそらく」などの迷いは、コンテキスト不足のサイン

**推論方向の誘導**：観察した思考パターンに合わせ、「反復案を優先」「境界処理に注意」などをプロンプトに足す

思考チェーンはプロンプトの X 線写真のように、あなたが「言ったこと」ではなくモデルが「聞いたこと」を映します。

思考チェーン漏洩の限界とリスク

主な点は次のとおりです。

**不安定性**：Google は露出を制御しており、版アップで手法が無効になることがある

**信頼性**：思考チェーン自体も誤る。見えた過程が正しいとは限らない

**コスト**：分析に時間がかかり、単純タスクには向かない

**倫理**：内部メカニズムの覗き見は公式に推奨されない。本番の重要判断に漏洩 CoT だけを頼るべきではない

デバッグと学習用に留め、正式プロジェクトでは慎重に使ってください。

4分で読めます · 公開日: 2026年2月27日 · 更新日: 2026年6月1日