AIREITERClaude が "almost done thinking" のままで、何か壊れたのではないかと心配しているなら — 壊れていません。そのステータスは、Claude が extended thinking（推論モード）に入っていることを意味します。つまり、書き始める前に回答を組み立てているのです。これが数秒、場合によっては 20〜30 秒続くのは正常です。正常ではないのは、何も返ってこないまま数分待たされることです。これらは別々の問題であり、このガイドではそれぞれを切り分けて、解決方法を示します。
「ほぼ考え終わった」ということの実際の意味
「Almost done thinking」は、Claudeがextended reasoningの処理を実行している間に表示されるラベルです。モデルは、すぐにトークンごとに応答する代わりに、「thinking」トークンの予算を使って計画を組み立て、その後に見える回答を生成します。これは、Claude Codeの「thinking with high effort」やClaudeアプリの推論インジケーターの背後にあるのと同じ仕組みです。
これを読む最も明確な方法は、このフレーズが エラー ではなく、進行状況 を示すサインだということです。ある r/ClaudeCode のスレッド では、拡張推論の一時停止について「Claude が実行前に計画しているのであって、サーバーの問題ではない」と表現しています。ですから、claude almost done thinking が表示されたとき、モデルは動作しています。唯一の問題は、それが 長すぎる のかどうかです。
おおよその目安として：
数秒から約30秒の思考 → 正常です。特に難しい推論やコーディングのタスクでは一般的です。
数分間まったく出力がなく、それが繰り返される → 何か問題があります。以下の修正に進んでください。
なぜこんなに時間がかかるのか（または完全に停止しているのか）
遅さと完全なハングには異なる原因があります。遅いケースは次の3つによって引き起こされます:
拡張思考の深さ。 さっと調べるだけの場面でも、Claude は必要以上に多くの推論を行う傾向があります。つまり、本来そこまで考える必要のない質問に対しても、強く「考え込んで」しまうのです。
順次的なツール呼び出し。 エージェント的な利用（Claude Code）では、実時間の大半はモデルの推論ではなく、ツール呼び出しに費やされます。Claude Code のレイテンシに関するある分析では、各ファイルの読み込み、検索、テスト実行は、同期的な往復としておおよそ 300〜800ms かかると測定され、デフォルトでは並列実行されないと指摘されています。そのため、あいまいなプロンプトが 10 回以上の探索的な呼び出しを引き起こすと、本格的な作業が始まる前に、それらの往復時間が積み重なって 10 秒以上になります。
コンテキストの肥大化。 会話の全履歴は毎ターン、モデルに再送信されます。セッションが長くなるにつれて、応答は遅くなり、品質も低下します。前述の分析でも、セッションがコンテキストウィンドウの約 60% を超えると、目立った速度低下が見られたとされていますが、正確な閾値は変動します（会話の奥深くに埋もれた詳細を見失う「中ほどで迷子になる」効果です）。
本当のハングは別の障害です。追跡されているClaude Codeの問題（#32526）では、新しいセッションが「thinking」で止まり、決して出力を生成しないと説明されています。エラーもなく、単純な「hello」に対しても同様です。一方で、以前から開いていたセッションは問題なく動き続けます。この報告は、PreToolUseフックが多数、複数のMCPサーバー、80以上の登録済みスキル、そしてカスタム（Bedrock）プロバイダーという重い構成から来ています。もし1トークンも返ってこないなら、それは遅いのではなく、ハングだと考えてください。
修正方法
簡単な対処法（まずはこちらをお試しください）
/clearで会話を破棄し、最初からやり直します — コンテキストの肥大化に対する最速の対処法です。/compactでコンテキストを要約して縮小します。これは設計上、情報が失われることに注意してください。重要なものは先にファイルに保存しておきましょう。セッションを再起動するか、まだ応答している古いセッションに戻ります — ハングしたときに多くのユーザーが行き着く回避策です。
労力レベルを調整する
最も見落とされがちな速度のレバーはeffortです。Claudeは高い／最大の推論にデフォルトで傾きがちですが、タスクに応じて effort を合わせることで、通常の作業では品質を落とさずに大きな速度向上が得られます。実用的なチートシート：
タスク | 工数 | 理由 |
|---|---|---|
簡単な検索、要約、整形 |
| 深い推論は不要；ほぼ即時 |
標準的なコーディング、下書き作成 |
| バランスが良い |
アーキテクチャ、難しいデバッグ、数学 |
| 待つ価値がある |
不透明さが気になる場合（Claude はデフォルトで思考の詳細を非表示にします）、Claude Code は思考の要約を表示できるので、少なくとも何をしているのかを確認できます。
本当に詰まっていて、単に遅いだけではないとき
出力がゼロの場合、それは深さではなく、ハングです:
起動時の読み込みを減らす — 追加の
PreToolUseフック、未使用の MCP サーバー、スキルを一時的に無効化してから、セッションを再開します。プロバイダーを確認する — カスタムモデル ID とゲートウェイ（Bedrock など）は、多くのフリーズ報告で見られます。
--verbose付きで実行し、実際に何をしているかを確認します。ファイル読み取りが長く連続している場合は tool-call の問題を示し、tool call がないまま最初の応答が遅い場合は latency か context を示します。
高度編: API から思考を制御する
アプリでは思考の制御に限りがあります。APIならその制御を直接行えます — そして、予測可能なレイテンシーが必要な場合の実用的な解決策です。上のチートシートにある同じ努力レベルはAPIパラメータであり、拡張思考を完全にオフにすることもできます:
message = client.messages.create(
model="claude-opus-4-6",
max_tokens=4096,
thinking={"type": "adaptive"}, # Claude がどれだけ考えるかを判断
output_config={"effort": "low"}, # low | medium | high | max — 深さの上限を設定
# または、拡張思考を完全にスキップするには:
# thinking={"type": "disabled"},
messages=[{"role": "user", "content": "..."}],
)現在のClaudeモデル（Opus 4.6以降）では、固定のトークン予算を設定するのではなく、effort level（low は素早い作業向け、max まで）を設定するか、extended thinkingを完全に無効にします。これはアプリが隠しているのと同じレバーで、あなたが制御するパラメータとして公開されています。（現在の参照については公式のextended-thinkingドキュメントを参照してください。パラメータ名はSDKのバージョン間で変更されることがあるため、使用中のものを確認してください。）
Anthropic互換のエンドポイントであれば、これらの呼び出しを発行できます。公式APIでも、上記のリクエストが変更なしで動作するAIReiterのような互換ミラーでも構いません。どちらを使うかは、それほど重要ではありません。重要なのは、思考の制御はAPIレイヤーにあり、アプリ側ではそれを公開していないという点です。
Claude は「悪くなっている」のですか？
これは、「why is claude almost done thinking forever」という検索の背後に潜む疑問であり、正直に言うと、答えはたいてい「永久にそうなるわけではない」です。認識される劣化の大部分は、デフォルト動作の変更、つまり thinking budgets のサーバー側調整や、アップデートで展開された保守的なデフォルト設定に起因しており、モデル自体が賢くなくなったわけではありません。これについてはコミュニティ内でかなり議論がありますが、繰り返し出る結論は同じです。体験は、制御を取り戻せば回復します。つまり、effort level を設定し、肥大化したセッションをクリアし、構造化されたプロンプトを与えることです。今週 Claude の調子が悪く感じるなら、壊れていると結論づける前に、この3つを変えてみてください。
よくある質問
「ほぼ考え終わった」というのはどういう意味ですか？
つまり、Claude は拡張推論モードで動作しており、回答を書き始める前に計画を練っているということです。これは通常の進行状態であり、エラーではありません。問題を示すのは、いつまでも解決しない場合だけです。
Claudeはなぜ考えるのにそんなに時間がかかるのですか？
通常の3つの原因: 高いデフォルトの effort レベル、agentic セッションでの遅い逐次 tool 呼び出し（各 ~300–800ms）、そして肥大化した context window。effort レベルを下げ、tool 呼び出しの回数を減らし、context をクリアすることでそれぞれ改善できます。
Claude は考えるのが行き詰まることはありますか？
はい — 動作の遅さとは異なります。新しいセッションが「thinking」で止まり、出力が返ってこないことがあり、これは多くの場合、重い hook/MCP/skill の設定やカスタムプロバイダーに関連しています。セッションを再起動するか、正常に動作しているセッションに戻ってください。
Claude が応答を最後まで出し切らない — どうすればいいですか？
ハングとして扱ってください: /clear するか再起動し、起動時の負荷を削減し、プロバイダーを確認してください。停止しているのではなく遅いだけなら、effort レベルを下げてコンテキストを縮小してください。
Claudeをもっと速く考えさせることはできますか？
はい。通常のタスクでは、effort を low/medium に設定し、セッションは短く保ち、完全に制御したい場合は、より低い effort レベルまたは extended thinking を無効にして API を呼び出してください。