model

変更前

組織のポリシーで使用が禁止されているモデルであっても、CLI上のモデルピッカーや --model フラグなどで選択できてしまう可能性がありました。

変更後

組織で構成されたモデル制限が反映されるようになり、制限されたモデルを選択した際には「組織の設定により制限されています」というメッセージが表示されます。

ユーザーへの恩恵

管理者が意図した通りのモデル利用を徹底でき、誤って高コストなモデルや未承認のモデルを使用してしまうことを防げます。

変更前

フルスクリーン（TUI）モードのメニュー操作はキーボードのみに制限されており、マウスでの直感的な選択ができませんでした。

変更後

権限の承認プロンプトや /model、/config などの選択メニューにおいて、マウスでのクリック選択が可能になりました。

ユーザーへの恩恵

キーボードから手を離してマウスを使用している際でも、スムーズに選択操作を行えるようになり利便性が向上します。

変更前

非インタラクティブモード（-p）で実行した際、モデルがターンを生成せずに終了すると、その会話を --resume で再開しようとしても「会話が見つかりません」というエラーが発生していました。

変更後

モデルの応答が空の場合でも会話履歴が正しく記録されるようになり、後から正常にレジュームできるようになりました。

ユーザーへの恩恵

スクリプト実行や自動化の過程で失敗したり応答がなかったりしたセッションでも、その時点からやり直すことが可能になります。

変更前

JSONスキーマ指定時やワークフロー実行において、モデルが正常な出力後も不必要にツールを呼び出し続けたり、継続ターンで構造化データが返らなくなったりすることがありました。

変更後

ツール呼び出しのループが防止され、フォローアップのターンにおいても一貫して検証済みの構造化データが返されるようになります。

ユーザーへの恩恵

プログラムから Claude Code を呼び出す際の挙動が安定し、不必要なトークン消費を抑えつつ正確な JSON データを取得できます。

変更前

使用しているモデルが非推奨になった際や、内部で新しいモデルに切り替わった際に、ユーザーがそれに気付きにくい状態でした。

変更後

標準エラー出力（stderr）やエージェントのfrontmatter設定において、モデルのステータスに関する警告が明示的に表示されるようになります。

ユーザーへの恩恵

常に最新かつ最適なモデルを使用しているかを把握でき、モデルの更新に伴う挙動の変化に素早く対応できます。

変更前

SDKやヘッドレスモードで使用している際、認証が必要なMCPサーバーが本来不要な「認証用スタブツール」をモデルに提示してしまうことがありました。

変更後

モデルが不適切なツールを呼び出さないよう、環境に応じて適切なツールのみを公開するように制御を強化しました。

ユーザーへの恩恵

自動化スクリプトやAPI経由での利用時に、モデルの混乱や誤動作を防ぎ、実行の信頼性が向上します。

変更前

モデルを切り替えた直後に /recap（会話の要約）を実行したり、会話のブランチを作成したりすると、新しく選択したモデルではなく、切り替え前の旧モデルが内部的に使用されていました。

変更後

モデル変更のステータスが即座に反映され、要約の生成や新しい会話ブランチの開始時にも指定した通りの最新モデルが適用されます。

ユーザーへの恩恵

モデルを切り替えた意図通りの推論能力やコスト効率を、次のアクションからすぐに享受できるようになります。

変更前

~/.claude ディレクトリやその中の settings.json が多重のシンボリックリンク（相対パス含む）で構成されている場合、設定変更時にファイルが見つからないエラー（ENOENT）が発生していました。

変更後

複雑なシンボリックリンク構成であっても、設定ファイルのパスを正しく解決して書き込めるようになりました。

ユーザーへの恩恵

ドットファイルの管理ツール（dotfilesなど）で設定をカスタマイズしているユーザーでも、エラーなく設定変更を行えます。

変更前

パーミッションの設定では、ツール名全体を許可または禁止することしかできず、特定のモデルの使用や特定の引数での実行を細かく制限することが困難でした。

変更後

Agent(model:opus) のようにツール名とパラメータを組み合わせた指定が可能になりました。ワイルドカード（*）もサポートされており、より柔軟なアクセス制御が実現します。

ユーザーへの恩恵

「Opus モデルのサブエージェントだけを禁止する」といった高度なセキュリティポリシーやコスト管理ルールを、環境に合わせて精密に設定できるようになります。

変更前

説明なしでバグ報告が送信できてしまったり、GitHub の Issue タイトルが適切に生成されず、モデルの内部的なエラー文言がそのまま使われたりすることがありました。

変更後

送信前に具体的な説明が求められるようになり、適切なタイトルで Issue が作成されます。

ユーザーへの恩恵

より具体的で整理されたバグ報告が可能になり、開発チームによる問題の把握と修正がスムーズに行われるようになります。

変更前

モデルが過負荷の際に予備のモデルに切り替える「フォールバック設定」をしていても、コンテキストを要約して整理する「圧縮処理」の段階ではその設定が無視されてエラーになることがありました。

変更後

圧縮処理中も設定したフォールバックチェーンが適用され、メインモデルが利用不可の場合でも代替モデルで処理を継続します。

ユーザーへの恩恵

高負荷時でも会話の文脈を維持するための整理処理が止まらず、セッションの中断を最小限に抑えることができます。

変更前

管理者がモデルを制限していても、特定の環境変数の操作や高速モードの切り替えによって制限を回避できる可能性がありました。

変更後

許可リスト（availableModels）のチェックが厳格化され、あらゆる経路からの未許可モデルの使用がブロックされます。

ユーザーへの恩恵

組織のポリシーやコスト管理に沿ったモデル運用を確実に徹底できるようになります。

変更前

以前は、管理者が availableModels で利用可能なモデルを制限していても、「デフォルト(Default)」設定のモデルはこの制限を受けず、サブスクリプションに応じた最新モデルが使用される場合がありました。また、ユーザーやプロジェクト単位の設定で、管理者が定めた許可リストにモデルを自由に追加できてしまうという課題もありました。

変更後

新しい enforceAvailableModels を有効にすると、デフォルトモデルも許可リストに従うよう制限されます。不許可のモデルがデフォルトに指定されている場合はリスト内の最初の許可モデルにフォールバックされるほか、ユーザー側での許可リストの拡張も禁止されます。

ユーザーへの恩恵

組織の管理者は、開発者が使用できる AI モデルを厳格に制御できるようになります。これにより、特定のモデル以外の利用を禁止するコンプライアンス要件の遵守や、想定外のモデル利用によるコスト発生を確実に防ぐことが可能です。

変更前

/model ピッカーにおいて、デフォルト設定がどのモデルファミリー（Opus や Sonnet など）を指しているのかが隠れてしまい、ユーザーが現在どのモデルを使用しようとしているのか直感的に分かりづらい状態でした。

変更後

各プランやアカウントの種類（API 従量課金など）に応じて、Opus や Sonnet が明示的に個別の行として表示されるようになり、モデルの選択肢が明確化されました。

ユーザーへの恩恵

自分が契約しているプランで利用可能な最適なモデルを迷わずに選択できるようになり、意図しないモデルの使用を防げます。

変更前

環境変数で特定のモデルバージョンを指定していても、UI 上のラベルが固定値のまま変わらず、実際に使用されているモデルと表示が一致しないことがありました。

変更後

ピッカー上の表示が設定された環境変数の内容を正しく反映するようになり、使用中のモデルバージョンが正確に表示されるようになりました。

ユーザーへの恩恵

表示と実態の乖離がなくなるため、正しいバージョンで動作していることを自信を持って確認しながら作業できます。

変更前

GovCloud リージョンを使用する際、システムが誤って標準リージョン用のプレフィックスを付与してしまい、モデル ID の不一致により API リクエストが失敗していました。

変更後

GovCloud リージョンに対して正しい「us-gov」プレフィックスが適用されるようになり、政府系クラウド環境でも Bedrock モデルを正常に利用できるようになりました。

ユーザーへの恩恵

GovCloud を利用する制約の厳しい環境のユーザーでも、エラーを気にすることなく Claude Code を活用できるようになります。

変更前

複数のプロジェクトや設定で Claude を使い分けている場合、バックグラウンドで動作するセッションが、本来意図しない別のセッションの設定を引き継いでしまうリスクがありました。

変更後

バックグラウンドセッションの環境変数が分離され、各セッションが独立して正しいプロバイダー設定やエイリアスを使用するようになります。

ユーザーへの恩恵

異なるプロバイダーやゲートウェイを併用していても、バックグラウンドでの作業が常に正しい設定で実行されるため、セキュリティと一貫性が向上します。

変更前

管理ポリシーなどで特定のモデルの使用が制限されていても、UI 上で制限対象のモデルがデフォルトのアドバイザーとして選択された状態になり、エラーの原因となっていました。

変更後

ダイアログを開く際に、許可リストと保存済み設定を照合し、利用可能なモデルのみが選択候補として適切に扱われるようになりました。

ユーザーへの恩恵

組織のポリシーに反するモデルを誤って使用しようとしてエラーに遭遇する手間が省け、スムーズにアドバイザー機能を活用できます。

変更前

以前は、Amazon Bedrockなどのサードパーティプロバイダーで100万トークンのコンテキストウィンドウを有効にする際、モデルIDの末尾に [1m] を手動で付与する必要がありました。しかし、Fable 5のような最新モデルではこのサフィックスが適切に処理されず、モデル名の不一致が発生する場合がありました。

変更後

Fable 5モデルについては、デフォルトで100万トークンのコンテキストがサポートされていることをシステムが認識し、モデル名から [1m] サフィックスを自動的に除去して正規化するようになりました。

ユーザーへの恩恵

モデル名の指定を手動で行う際の設定ミスや混乱が解消されます。ユーザーはモデルの仕様を気にすることなく、常に最適なコンテキストウィンドウ設定で開発を進めることができます。

変更前

OpenTelemetry を通じてコード行数に関する統計を取得する際、どの AI モデルがその操作に関わったかというコンテキスト情報が含まれていませんでした。

変更後

メトリックに model 属性が付与されるようになり、モデルごとのコード生成量や修正量の詳細な分析が可能になりました。

ユーザーへの恩恵

組織の管理者が、Opus や Sonnet といった各モデルの利用効率やアウトプットを、より正確な定量データとして可視化できます。

変更前

エージェントをバックグラウンドで起動する際、モデル選択の UI 表示が不正確で、選択できないはずのモデルが候補に挙がることがありました。

変更後

組織のポリシーに沿ったモデルのみが正しく表示されるようになり、入力補助の表示も自然な形式に修正されました。

ユーザーへの恩恵

バックグラウンドタスクの開始時に、利用できないモデルを選択してエラーになる手間を省き、意図したモデルを迷わず指定できます。

変更前

管理者が availableModels 設定で使用可能なモデルを制限していても、一部の機能経由では制限対象外のモデルが指定できてしまう漏れがありました。

変更後

サブエージェントやアドバイザー機能を含むすべての箇所で allowlist が厳格に適用されるようになり、ポリシー遵守が徹底されます。

ユーザーへの恩恵

企業のコンプライアンスやコスト管理の観点から特定のモデルに限定して利用させたい場合、設定が確実に機能するようになります。

変更前

バージョン指定された特定のモデル ID を許可リストに入れると、UI 側で 1M コンテキスト対応の Opus や Sonnet の行が表示されなくなる不具合がありました。

変更後

詳細な ID 指定時でも 1M コンテキストのオプションが正しく認識され、UI に表示されるようになりました。

ユーザーへの恩恵

大規模なコードベースを扱うために 1M コンテキストを活用しつつ、モデルバージョンを固定して運用したいユーザーの利便性が向上します。

変更前

Bedrock で実際には利用できないモデルが候補に表示され、選択すると裏側で意図しないモデルに切り替わったり、表示上の選択マークが重複したりしていました。

変更後

Bedrock で有効なモデルのみが正確にリストアップされ、選択状態の管理も適正化されました。

ユーザーへの恩恵

環境に依存するモデルの有無を意識することなく、確実に利用可能なモデルだけを選択して作業を継続できます。

変更前

設定変数に [1M] を含めていると、システム側でさらにサフィックスが追加され、無効なモデル ID (例: [1M][1m]) になってしまうことがありました。

変更後

サフィックスの付与ロジックが改善され、常に正しい形式で API リクエストが送信されるようになりました。

ユーザーへの恩恵

環境変数によるモデルのカスタマイズを行う際、ID の重複付与による接続エラーを気にせず設定できます。

変更前

opusplan を利用してプランモードと実行モードを切り替える際、権限があるユーザーでもプランニング時に 1M コンテキストの広大な履歴を活かせない制限がありました。

変更後

プランモードでの Opus 実行時にも 1M コンテキストが正しく適用されるようになり、opusplan[1m] エイリアスでの挙動も最適化されました。

ユーザーへの恩恵

巨大なプロジェクトの設計やリファクタリングの計画を立てる際、コンテキスト不足に悩まされることなく Opus の高度な思考を利用できます。

変更前

プロジェクト独自のワークフローのみを Claude に実行させたい場合でも、常に標準搭載のスキルがコンテキストに含まれていました。

変更後

この設定を有効にすることで、Claude が組み込み機能ではなく、プロジェクトで定義した特定のルールやスキルのみを優先して使用するように制限できます。

ユーザーへの恩恵

AI の挙動をより厳格に制御し、組織固有の標準フローのみに従わせたい場合に役立ちます。

変更前

1M コンテキスト（Extended Context）対応モデルを使用している場合でも、標準モデルと同じ厳しい制限で警告が出てしまい、情報の集約を阻害していました。

変更後

より大きなコンテキストを扱えるモデルでは、より多くのルールを CLAUDE.md に記述しても不必要な警告が出なくなります。

ユーザーへの恩恵

大規模なプロジェクトのルールを、モデルの能力をフルに活かして管理できるようになります。

変更前

メインモデルが利用できない場合、手動でモデルを切り替える必要がありました。また、フォールバックモデルの指定は一部の非対話型モードに限られていました。

変更後

fallbackModel 設定により、優先順位をつけた最大3つの予備モデルを自動で試行できます。対話型セッション中もこの自動切り替えが機能するようになります。

ユーザーへの恩恵

APIの過負荷や障害が発生しても、手動で設定を変更することなく作業を継続できるため、開発の生産性が維持されます。

変更前

デフォルトで思考機能が有効なモデルにおいて、設定に関わらず思考プロセスが常に実行されてしまう場合がありました。

変更後

環境変数やCLIフラグ、設定画面から思考機能を明示的にオフにできるようになり、思考プロセスをスキップして直接回答を得ることができます。

ユーザーへの恩恵

思考時間を短縮して素早く回答を得たい場合や、トークン消費を抑えたい場合に、柔軟に動作をコントロールできます。

変更前

レート制限や認証エラー以外のサーバーエラーが発生すると、その時点で処理が中断されていました。

変更後

予期しないサーバーエラーが発生した際、設定されたフォールバックモデルで1回リトライを試みることで、エラーを回避できる可能性が高まります。

ユーザーへの恩恵

一時的なAPI側の不具合による作業の中断を減らし、安定した実行環境を提供します。

変更前

設定ファイルを書き換えても、バックグラウンドで動いている管理プロセス(デーモン)が古い設定を保持しており、意図しないモデルで作業が開始されることがありました。

変更後

新しいセッションを開始するたびに最新の settings.json が読み込まれ、指定通りのモデルが確実に使用されるようになりました。

ユーザーへの恩恵

設定変更が即座に反映されるため、常に最新のコスト効率や性能のバランスを保ちながら自動作業を任せられます。

変更前

Bedrock等でオートモードが無効な際、モデル自体が非対応であるかのような誤解を招くエラーメッセージが表示されていました。

変更後

CLAUDE_CODE_ENABLE_AUTO_MODE 環境変数による明示的なオプトインが必要であることを正しく案内するように変更されました。

ユーザーへの恩恵

設定方法が明確になり、使い慣れたクラウド環境でオートモードを有効にするまでの手順に迷わなくなります。

変更前

モデルの能力不足でultracodeが実行できない時、設定が無効であるかのような不正確なエラーが表示されていました。

変更後

モデルのサポート状況を正しく判定し、非対応モデルではultracodeを選択肢から除外、または適切な理由を表示します。

ユーザーへの恩恵

モデルの性能制限とツールの設定不備を混同することがなくなり、トラブルシューティングが容易になります。

変更前

CLI以外のインターフェース（SDK等）を使用している際も、適用できないCLIコマンド入力を促す不適切なヘルプが表示されていました。

変更後

実行コンテキストに応じて、SDKの設定方法など適切な解決策を提示するようにメッセージが改善されました。

ユーザーへの恩恵

CLI以外の開発環境から利用しているユーザーが、エラー時に適切な対処法をすぐに見つけられるようになります。

変更前

既に最新の Opus 4.8 などを使用しているのに、アップデートを促す不要なメッセージが出て混乱を招いていました。

変更後

通知の正確性が増し、モデル選択画面でもモデルの特性（説明文）が直接確認できるようになります。

ユーザーへの恩恵

モデル選択時の迷いがなくなり、現在のモデルが最適かどうかを直感的に判断できます。

変更前

特定の古いモデルバージョンでファストモードを強制するために環境変数を使用する必要があり、設定が分散して管理が煩雑でした。

変更後

モデルの選択とファストモードの切り替えが、標準的なスラッシュコマンドによるUI操作に一本化されました。

ユーザーへの恩恵

環境変数を気にすることなく、最新のOpus 4.7/4.8と過去の4.6を同一の操作体系で使い分けることができます。

変更前

一律に推論努力を最大化する設定を使っていると、Haikuなどの軽量モデルに切り替えた瞬間に、未対応パラメーターの送信によってリクエスト自体がエラーになっていました。

変更後

モデルごとに努力レベルの対応状況を判別し、未対応の場合は自動的にパラメーターを省略してリクエストを送るようになりました。

ユーザーへの恩恵

設定を気にせず柔軟にモデルを切り替えて作業でき、開発のリズムがエラーによって中断されることがなくなります。

変更前

コストを意識して開発しているユーザーにとって、デフォルト設定を選んだ場合にどの程度の料金がかかるのかが一部の画面で不透明になっていました。

変更後

現在のモードに基づいた正確な価格情報が常にモデル選択時に提示されるようになりました。

ユーザーへの恩恵

モデル選択時のコスト予測が確実になり、意図しない予算超過を防ぎながら開発を進められます。

変更前

特定のモデル（Opusなど）を使い続けたい場合、新しいセッションを開始するたびに選択し直す手間がありました。

変更後

お気に入りのモデルが永続的に選択された状態になり、一時的な変更と恒久的な変更を使い分けることができます。

ユーザーへの恩恵

モデル選択の手間が省け、自分の作業スタイルに合わせた「マイデフォルト」で即座に開発を開始できます。

変更前

挙動の変更に伴い、古いキーバインド設定のままだと意図したショートカットが動作しなくなる可能性がありました。

変更後

最新の機能割り当てに合わせた設定名に変更することで、引き続き自分好みの操作体系を維持できます。

ユーザーへの恩恵

内部的な仕様変更を把握でき、スムーズに新バージョンへ移行できます。

変更前

スキル実行中に、意図しないツールの使用（例：特定の操作中にファイル削除ツールを呼ばせないなど）をきめ細かく制御することが困難でした。

変更後

スキルごとに利用可能なツールのセットを制限できるため、モデルが特定のワークフローに集中し、より安全かつ正確に動作するように定義できます。

ユーザーへの恩恵

カスタムコマンドの挙動をより厳密に制御でき、エージェントによる誤操作や不要なツール呼び出しのリスクを軽減できます。

変更前

モデルが過負荷などで利用できない際、特に非対話型のスクリプト実行中にリクエストが失敗し、作業が中断されてしまうことがありました。

変更後

代替モデルへ自動的にフォールバックするため、一時的なサービス停止時でもエージェントの作業が止まることなく進行します。

ユーザーへの恩恵

長時間かかる自動タスクや CI 上での実行において、モデルの可用性に左右されにくい堅牢なワークフローが構築できます。

変更前

セッション中に /model でモデルを切り替えると、その設定が永続的に保存され、次回以降の全ての新規セッションにも意図せず反映されてしまっていました。

変更後

一時的な切り替えと恒久的なデフォルト設定（d キーで設定）が明確に分離されました。現在の作業に合わせてモデルを試し、必要に応じて基本設定を変更できるようになりました。

ユーザーへの恩恵

「今回は Opus で深く考えさせたい」といった一時的な要望と、「普段は Sonnet を使いたい」という日常的な設定が衝突しなくなり、設定ミスによる意図しないトークン消費やコスト増加を防げます。

変更前

VS Code や JetBrains の UI 上でモデルを切り替えても、実際には起動時のモデルが使われ続けるなど、設定の反映に一貫性がない不具合がありました。

変更後

IDE からの動的なモデル変更指示が即座に、かつ確実にエンジンへ適用されるようになりました。

ユーザーへの恩恵

GUI と CLI の設定が常に同期され、UI で選択した通りのモデルで AI が回答してくれるようになります。

変更前

あるプロジェクトでモデルを切り替えた後に別のプロジェクトの古いセッションを再開すると、以前のモデルではなく、直近で使ったモデルが強制適用されてしまうことがありました。

変更後

各セッションが中断時のモデル設定を記憶し、再開時にそのモデルを復元するようになりました。

ユーザーへの恩恵

各タスクに最適なモデルを個別に選んでいた場合、再開するたびにモデルを戻す手間がなくなり、過去のコンテキストに一貫性が保たれます。

変更前

クラウドプロバイダー経由で利用しているユーザーにおいて、最新の長大なコンテキストウィンドウを持つモデルオプションが表示されない、あるいは選択できない状態でした。

変更後

Bedrock/Vertex 環境でも 100万トークンの広大なコンテキストを持つ Opus モデルが正しく選択可能になりました。

ユーザーへの恩恵

大規模なリポジトリの全コードを読み込ませるような、高度で大規模な解析タスクが再びクラウド経由でも実行可能になります。

変更前

プロキシや特定のクラウド環境において、本来コストの低い Haiku で実行すべきバックグラウンド処理（タイトル生成など）が、意図せずメインの重いモデルで実行されてしまうことがありました。

変更後

利用可能な API キーや設定に応じて、最も効率的なモデル（Haiku）を優先的に選択してサイドクエリを実行するロジックが強化されました。

ユーザーへの恩恵

不必要なコストの発生を抑えつつ、バックグラウンドでの要約や整理機能を最適なスピードで利用できます。

変更前

バックグラウンドで開始されるエージェントの権限モードやモデル、努力レベルを一括で制御する手段が不足していました。

変更後

--permission-mode, --model, --effort, --dangerously-skip-permissions がエージェントビューでも有効になりました。

ユーザーへの恩恵

大量のタスクを投入する際に、一度のフラグ指定で全セッションの挙動（承認の有無や賢さ）を統一できます。

変更前

バックグラウンドで動いているエージェントが、モデルの制限などでエラーになった際、代替モデルへの切り替えができず失敗していました。

変更後

フォールバック用のモデル設定が維持されるため、メインモデルが利用不可でも代わりのモデルで作業を継続します。

ユーザーへの恩恵

長時間の無人作業の完遂率が向上し、モデルの過負荷による中断を回避できます。

変更前

バックグラウンドで動作するエージェントセッションを開始する際、ディレクトリの追加指定や詳細な MCP 設定、パーミッションモードなどをコマンドラインから個別に制御することが困難でした。

変更後

claude agents コマンドに --settings や --mcp-config、--permission-mode などの豊富なフラグが追加され、起動時にセッションの挙動を細かくカスタマイズできるようになりました。

ユーザーへの恩恵

メインセッションと同様の柔軟な設定をバックグラウンドタスクにも適用できるため、複雑なプロジェクト環境での並列作業がよりスムーズになります。

変更前

リモート環境からモデル変更を行った際、不要な「モデル設定」のパンくずリストが履歴に重複して記録され、会話の流れが見づらくなっていました。

変更後

モデル変更リクエストが整理され、履歴には必要な変更情報のみが記録されるようになりました。

ユーザーへの恩恵

後から会話履歴を見返した際、いつどのモデルに切り替えたかが明確になり、ログの可読性が向上します。

変更前

ANTHROPIC_SMALL_FAST_MODELが設定されていないサードパーティプロバイダー環境で、サイドクエリが利用不可能なHaiku IDを送信してエラーになることがありました。

変更後

適切なHaikuモデルが指定されていない場合、自動的にメインループで使用しているモデルにフォールバックして処理を継続します。

ユーザーへの恩恵

プロバイダー固有のモデル設定を細かく調整しなくても、バックグラウンドでの調査や要約機能が安定して動作するようになります。

変更前

ANTHROPIC_BASE_URLを使って独自のゲートウェイ経由で接続している場合、名前生成用のHaikuモデルが認識されず、ジョブ名が未設定のままになることがありました。

変更後

Haikuが利用できない場合はメインモデルを使用して名前を生成するため、常に分かりやすい名前がジョブに付与されます。

ユーザーへの恩恵

独自のAPIプロキシ環境でも、各ジョブが「何をしていたか」を一目で把握できるようになり、管理性が維持されます。

変更前

複数のターミナルでClaude Codeを動かしている際、片方でモデルを変更すると、無関係なもう一方のセッションのコンテキスト管理(自動圧縮)の挙動が変わってしまうバグがありました。

変更後

各セッションの設定変更が独立して管理されるようになり、意図しない設定の「染み出し」が解消されました。

ユーザーへの恩恵

複数のタスクを異なる設定で並列実行する際の信頼性が向上し、各セッションがそれぞれのコンテキストを正しく維持できます。

変更前

表示されるトークン数がモデルの実態と乖離していたり、細かい数値で表示されていて直感的に把握しにくい場合がありました。

変更後

使用しているモデルの計算方式に基づいた正確な推定値が、読みやすい丸められた数値で表示されます。

ユーザーへの恩恵

コンテキスト制限に近づいている際の判断がより正確になり、トークン節約の計画が立てやすくなります。

変更前

環境変数でデフォルトモデルを変更していても、ピッカーの表示上は標準のデフォルト(Sonnetなど)が表示されたままでした。

変更後

実際の動作設定とピッカーの表示が一致し、現在どのモデルがデフォルトとして機能しているか正しく把握できます。

ユーザーへの恩恵

モデル設定の誤認を防ぎ、意図した通りのモデルで作業している確信を持てます。

変更前

BedrockやVertex AIなどの環境でopusエイリアスを使用している際、選択肢に不必要な重複行が現れることがありました。

変更後

UIが整理され、現在選択中のモデルが正しく、かつシンプルに表示されます。

ユーザーへの恩恵

モデル選択時の視認性が向上し、操作ミスを防げます。

変更前

サードパーティのAPIプロバイダーを利用している際、古いOpusモデルを選択しようとしても、システムが誤ってデフォルト設定のモデル（Sonnetなど）として処理してしまっていました。

変更後

プロバイダー側のモデル定義が正しく識別されるようになり、レガシーなOpusモデルを明示的に選択して利用することが可能になりました。

ユーザーへの恩恵

特定の古いモデルが必要なタスクにおいて、意図しないモデルが使用されることを防ぎ、期待通りのモデルで推論を実行できるようになります。

変更前

実際に使用されているモデルと、ステータス画面に表示されるモデル情報が一致しないケースがありました。

変更後

サブスクリプション層や設定に基づく正しいデフォルトモデルがステータス画面に表示されるようになりました。

ユーザーへの恩恵

どのモデルを使用して対話しているかを正確に把握できるようになり、安心してツールを利用できます。

変更前

独自のLLMゲートウェイを使用している場合、モデルの一覧取得が常に自動で行われていました。

変更後

環境変数を明示的に設定した場合のみ、ゲートウェイのエンドポイントから利用可能なモデルの一覧を取得するようになります。

ユーザーへの恩恵

意図しないエンドポイントへのリクエストを防ぎ、セキュリティやネットワーク要件に合わせた柔軟な設定が可能になります。

変更前

スキルをモデルやメニューから隠す、あるいは特定の条件下でのみ有効にするといった個別のオーバーライド設定が正しく反映されない問題がありました。

変更後

offで完全に隠す、user-invocable-onlyでユーザーのみ実行可能にする、name-onlyで説明を折り畳むといった制御が確実に行えるようになります。

ユーザーへの恩恵

多数のスキルがある場合でも、重要なものだけをモデルに見せることでコンテキストを節約し、作業効率を高めることができます。

変更前

/clearやコンパクションの後にモデル設定を変更すると、実際には問題がない場合でもキャッシュに関する警告が表示されることがありました。

変更後

設定変更時のキャッシュ状態の判定が正確になり、不要な警告でユーザーを混乱させることがなくなります。

ユーザーへの恩恵

警告表示に煩わされることなく、タスクに応じて最適なモデルや推論効率（effort）をスムーズに切り替えられます。

変更前

モデル選択メニューにおいて、同じモデルが重複して表示されたり、バージョン番号付きの長い名称で表示されていて分かりにくい部分がありました。

変更後

メニューが整理され、最新の Opus モデルが簡潔なエイリアス名で表示されるようになりました。

ユーザーへの恩恵

使用したいモデルを迷わず選択できるようになり、インターフェースの透明性が向上します。

変更前

100万トークンの広大なコンテキストを扱えるモデルを使用している際、設定されたコンパクション（圧縮）しきい値が小さいと、まだ余裕があるにもかかわらず「プロンプトが長すぎます」というエラーが発生していました。

変更後

コンパクションの計算ロジックが修正され、モデルの真の限界までコンテキストをフル活用できるようになりました。

ユーザーへの恩恵

大規模なコードベースを扱う際のセッションの中断を減らし、より長い対話を安定して継続できます。

変更前

Amazon Bedrock を使用する際、特定のリージョンを指定していても、モデル名が誤ってグローバルプレフィックスとして解決され、接続エラーの原因となることがありました。

変更後

設定された AWS リージョンに基づいて、適切なリージョンプレフィックスを持つモデル識別子が正確に選択されるようになります。

ユーザーへの恩恵

Bedrock 環境でのセットアップがより確実になり、モデルが見つからないといったエラーを防止できます。

変更前

Anthropic互換のゲートウェイを使用している場合でも、/modelコマンドのピッカーには組み込みのモデルエイリアスやデフォルトのモデルしか表示されませんでした。

変更後

ゲートウェイが提供する/v1/modelsエンドポイントからモデルリストを動的に取得し、ピッカーに表示できるようになりました。

ユーザーへの恩恵

プロキシやカスタムゲートウェイ経由で利用可能な特定のモデルを、モデル名を手入力することなく選択メニューから簡単に選べるようになります。

変更前

モデルが並列実行のレスポンスとして存在しないツール名を返した場合、Agent SDKが適切にエラー処理できず、そのまま処理が停止してしまうことがありました。

変更後

不正なツール名が含まれている場合でもハングせず、適切にエラーを検知して制御を維持できるようになりました。

ユーザーへの恩恵

モデルの予期せぬ出力に対する堅牢性が向上し、自動化スクリプトやツール開発においてAgent SDKをより安定して利用できます。

変更前

Bedrockの推論プロファイル機能を使用している場合、モデルが思考（reasoning）に対応していても、その強度を調整するインターフェースが表示されませんでした。

変更後

ARN指定時でも適切に思考レベルの設定オプションが表示され、APIリクエストにも output_config.effort が正しく含まれるようになりました。

ユーザーへの恩恵

AWS環境でBedrockを利用しているユーザーも、タスクの複雑さに応じてモデルの思考の深さを柔軟に調整できるようになります。

変更前

会話中にモデルを切り替えていたとしても、履歴をエクスポートする際に、出力結果には現在設定されているデフォルトのモデル名が誤って記載されていました。

変更後

エクスポートされた履歴に、各ターンで実際に推論に使用されたモデルが正確に反映されるようになります。

ユーザーへの恩恵

過去のやり取りを振り返る際やトークン使用量を分析する際に、どのモデルによる回答だったのかを正確に把握できるようになります。

変更前

カスタムの ANTHROPIC_BASE_URL を使用している際、モデルピッカーに表示される内容が Anthropic 標準のままになり、組織独自のモデル設定が反映されないことがありました。

変更後

ANTHROPIC_DEFAULT_*_MODEL_NAME などの環境変数で指定したカスタムの名称や説明が、モデル選択画面に正しく表示されるようになりました。

ユーザーへの恩恵

社内プロキシやゲートウェイを介して特定のモデル構成を運用している開発者が、自分たちの環境に適した正しいモデル情報を確認して選択できます。

変更前

クラウド上のリモート環境に接続すると、自分のPC側のデフォルトモデル設定が接続先の設定で書き換えられてしまうことがありました。

変更後

リモート接続がローカルの永続的な設定に干渉しないように保護されました。

ユーザーへの恩恵

リモートとローカルの作業を切り替えても、好みのモデル設定が維持されます。

変更前

プロジェクト側でモデルが指定されていると、ユーザーが /model で変更しても再起動時にリセットされてしまうことがあり、また現在のモデルがどこで定義されたものか不明確でした。

変更後

手動で選択したモデルが優先的に保持され、さらに「プロジェクト設定による固定」か「管理設定による固定」かが明示的に表示されます。

ユーザーへの恩恵

好みのモデルを使い続けるための再設定の手間が省け、現在の動作環境がどの設定に基づいているかを一目で把握できます。

変更前

テレメトリデータにおいて、どのコマンドから実行されたかや、モデルの「思考の深さ（Effort）」がコストにどう影響しているかを詳細に分析することが困難でした。

変更後

コマンド名やソース、および effort 属性が各イベントに付与され、組織レベルでの詳細な利用状況の可視化が可能になります。

ユーザーへの恩恵

開発チーム全体での Claude Code の利用効率やコストパフォーマンスを、より正確なデータに基づいて最適化できます。

変更前

特定のプロバイダーや古いモデルで、新しい機能であるEffort設定が不適切に送信され、通信エラーが発生することがありました。

変更後

接続先のモデルがサポートしている機能を自動判別し、適切なパラメータのみを送信するように改善されました。

ユーザーへの恩恵

Google Vertex AIなどの外部プラットフォーム利用時でも、予期せぬエラーで作業が止まることがなくなります。

変更前

以前のモデル（Sonnet 4.6など）では思考レベルの選択肢が限られており、Opus 4.7のデフォルトかつ推奨される思考の深さを指定する専用のレベルが存在しませんでした。

変更後

Opus 4.7専用のxhighレベルが追加され、コーディングやエージェントとしてのタスクに最適な、速度と推論能力の高度なバランスを簡単に選択できるようになりました。

ユーザーへの恩恵

Opus 4.7の能力を最大限に引き出す設定がデフォルトとなり、複雑な開発タスクにおいて、過剰なトークン消費を抑えつつ最も精度の高い推論結果を得られるようになります。

変更前

カスタム設定ディレクトリを使用している場合にパス表示が正しくなかったり、再設定時に以前選択したモデルが引き継がれず、設定の手間が大きくなっていました。

変更後

設定ウィザードが現在の環境をより正確に反映し、大規模なコードベースに必要な1Mコンテキストの有効化も簡単に行えるようになりました。

ユーザーへの恩恵

クラウドプロバイダー経由での利用開始や設定変更がより迅速かつ確実になり、特に大規模プロジェクトでのセットアップが楽になります。

変更前

Claudeがファイルを修正した直後に「古いエラー情報」を参照してしまい、既に解決したはずの問題をもう一度調査しようとする無駄な思考が発生していました。

変更後

編集後は最新のコードに基づいた診断結果が正しくモデルに渡されるようになり、無駄な再読み込みや重複した修正作業がなくなりました。

ユーザーへの恩恵

タスクの進行が早くなり、無駄なトークン消費を抑えながらより正確な修正が行えるようになります。

変更前

AIが提案したコードをIDEのdiff画面でユーザーが手動で微調整しても、その「修正後の内容」がAI側に正しく伝わらず、会話の文脈に齟齬が生じることがありました。

変更後

IDE上で行われた編集内容をWriteツールが検知し、ユーザーによる変更が含まれていることをモデルにフィードバックしてから最終的な適用が行われます。

ユーザーへの恩恵

人間とAIが協力してコードを作り上げるプロセスがより正確になり、AIがユーザーの意図を汲み取った上で次の提案を行えるようになります。

変更前

AIによる自動実行を禁止している特定のスキル（デプロイなど）を、チャットの入力途中で手動呼び出ししようとすると正しく認識されないバグがありました。

変更後

どのような入力タイミングでも、明示的なスキル呼び出しが確実に実行されるように修正されました。

ユーザーへの恩恵

「特定の操作は必ず自分の手で実行したい」というルールが徹底され、AIとの連携における信頼性が向上します。

変更前

モデルはビルトインの特殊なワークフローコマンドを直接認識できず、ユーザーが手動でコマンドを入力して指示する必要がありました。

変更後

エージェントがSkillツールを通じて自律的に適切なスラッシュコマンド（/init、/security-review等）を選択し、実行できるようになりました。

ユーザーへの恩恵

プロジェクトの初期化やコードレビューなどの定型的な高度なタスクを、Claudeに任せるだけで自動的に最適なツールを使って完遂してくれます。

変更前

セッション途中で/modelを使用して切り替えると、意図せず全履歴のトークンが再消費され、コストや時間がかかることが分かりにくい状態でした。

変更後

モデル切り替え時に、次のレスポンスがフルヒストリーの読み込み（アンキャッシュ状態）になる旨の警告が表示されるようになりました。

ユーザーへの恩恵

予期せぬトークン消費や待ち時間の増加を事前に把握し、モデル切り替えのタイミングを適切に判断できます。

変更前

インフェレンスプロファイルの検出中に、リージョンに合わない不正なモデルID（us.*など）が設定ファイルに書き込まれてしまうことがありました。

変更後

プロファイル検出の完了を適切に待機し、正しいモデルIDが永続化されるようになりました。

ユーザーへの恩恵

AWS環境でのリージョン設定に関するトラブルが減り、安定してBedrock上のモデルを利用できるようになります。

変更前

Vertex AI を使用する場合、環境変数や設定ファイルをユーザー自身が手動で構成する必要があり、初期セットアップのハードルが高くなっていました。

変更後

CLIの初期画面からウィザード形式で設定を進められるようになり、GCPプロジェクトの選択からモデルの固定までを対話的に完了できます。

ユーザーへの恩恵

複雑な環境変数の知識がなくても、Google Cloud 環境で Claude Code を素早く確実に使い始めることができます。

変更前

新しくリリースされたモデルやカスタムモデルを使用している際、最大思考レベルの設定ができない制限がありました。

変更後

モデルの種類に関わらず、対応している場合には常に最大の思考リソースを割り当てられるようになりました。

ユーザーへの恩恵

常に最新のモデル性能を引き出し、より複雑な問題解決に AI を活用できます。

変更前

Amazon Bedrockを使用する場合、AWS SDK向けの認証情報やリージョンの環境変数などを手動で設定する必要がありました。

変更後

ログイン画面からウィザード形式でAWS認証、リージョン選択、資格情報の検証、モデルのピン留めまでを一貫して設定可能になりました。

ユーザーへの恩恵

AWS環境でのセットアップが大幅に簡略化され、複雑な設定ミスを防いでスムーズに開発を開始できます。

変更前

/cost コマンドの出力は主にAPIユーザー向けで、サブスクリプションユーザーにとっては詳細な利用傾向を把握しにくい状態でした。

変更後

モデルごとの使用量やプロンプトキャッシュの効果が詳細に表示されるようになり、トークンの消費パターンが可視化されます。

ユーザーへの恩恵

どのモデルでどれだけ効率的にキャッシュが効いているかを確認でき、作業スタイルの最適化やコスト管理に役立ちます。

変更前

モデルが ok:false を返した際にフックが予期せずエラーになったり、ツール実行をブロックすべき場面で継続されてしまう不具合がありました。

変更後

Stopイベントの判定が正確になり、プロンプト型フックによるワークフローの中断制御が意図通りに機能するようになります。

ユーザーへの恩恵

フックを利用した自動化プロセスの信頼性が向上し、特定の条件下で処理を確実に停止させることが可能になります。

変更前

オートモード（auto mode）で操作が拒否された際、プログラム的に介入して修正を促したり、特定の条件下で再試行を許可したりする柔軟な手段がありませんでした。

変更後

拒否イベントをトリガーにフックを実行できるようになり、拒否理由に基づいてモデルに指示を出し直すなどの動的な制御が可能になりました。

ユーザーへの恩恵

安全性を保ちつつ、誤検知による中断を自動でリカバーさせることができ、オートモードでの作業の自律性が高まります。

変更前

Autoモード（研究プレビュー）において、AIの操作がセキュリティポリシー等で拒否された場合、AIがその理由を理解して別の方法でリトライすることが困難でした。

変更後

このフックを利用して {retry: true} を返すと、AIに操作が拒否されたことを伝え、安全な代替案を自律的に考案させることが可能になります。

ユーザーへの恩恵

AIが一度の拒否で止まってしまうことを防ぎ、ユーザーが手動で指示し直す手間を省きながら、タスクの完了率を高めることができます。

変更前

複数のプロジェクトで同時に Claude Code を開いている際、片方のモデル変更がもう一方の表示に影響を与え、実際に使用しているモデルを誤認するリスクがありました。

変更後

セッションごとの状態管理が厳密になり、現在操作しているインスタンスのモデル情報が常に正しく表示されます。

ユーザーへの恩恵

並行作業中でも「どのAIモデルに指示を出しているか」を正確に把握でき、意図しないモデル使用を防止できます。

変更前

BedrockやVertex AIなどの外部プロバイダーを利用する際、特定のモデルバージョンを固定すると、Claude Codeがそのモデルの思考（Thinking）能力や推論レベルを正しく認識できない場合がありました。また、モデル選択画面での表示名を変更することもできませんでした。

変更後

環境変数 ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL_SUPPORTS でモデルの能力を明示的に上書きできるようになりました。また、_MODEL_NAME や _DESCRIPTION 変数を使用して、/model ピッカーに表示される名前や説明を自由にカスタマイズ可能です。

ユーザーへの恩恵

社内のLLMゲートウェイ経由や特定の推論プロファイルを使用している場合でも、Claudeの高度な推論機能を確実に有効化でき、かつユーザーが識別しやすい名前を付けて運用効率を高めることができます。

変更前

スキルを実行する際、セッション全体の思考レベル設定がそのまま適用されるため、特定の高度なタスクを実行するたびに手動でレベルを切り替える必要がありました。

変更後

スキルの定義ファイル（SKILL.md など）のフロントマターで effort レベルを事前に設定できるようになり、実行時に自動で最適な思考深さが選択されます。

ユーザーへの恩恵

「コードレビューは high」、「簡単な挨拶は low」のように、タスクの性質に合わせて最適な推論リソースを自動配分でき、速度と精度のバランスを最適化できます。

変更前

特定の API エラーが発生した際、エラー処理のフック自体が新たなエラーを引き起こし、処理が止まらなくなる不具合がありました。

変更後

エラー発生時のループ検知と処理フローが改善され、無限ループに陥ることなく安全に停止するようになりました。

ユーザーへの恩恵

予期せぬエラー発生時でもリソースやトークンの浪費を防ぎ、安定した動作が保証されます。

変更前

特定の MCP サーバーをパーミッションで deny に設定していても、Claude がその存在を認識してしまい、実行に失敗する無駄な試行をしていました。

変更後

拒否されたツールはモデルに送られる前に完全に削除されるようになり、Claude は許可されたツールのみを認識します。

ユーザーへの恩恵

無駄なツール呼び出しが減り、モデルの判断の正確性とレスポンス速度が向上します。

変更前

社内プロキシや独自のゲートウェイ経由でモデルを利用している場合、標準のメニューからそれらを選択できるように設定するのが困難でした。

変更後

環境変数を通じて、自分たちのインフラに合わせた任意のモデル名と説明をメニューに追加できるようになりました。

ユーザーへの恩恵

企業独自のモデルエンドポイントなどを Claude Code から直接選びやすくなり、社内標準としての展開が容易になります。

変更前

Haikuモデル（Claude 3 Haikuや3.5 Haikuなど）を使用してClaude Codeを実行する際、ベータ機能を利用するための ANTHROPIC_BETAS 環境変数を設定しても、システム側でサイレントに無視されていました。

変更後

Haikuモデルを使用する場合でも ANTHROPIC_BETAS ヘッダーが正しくAPIリクエストに反映されるようになりました。

ユーザーへの恩恵

軽量で高速なHaikuモデルをメインまたはサブエージェントとして利用している環境でも、最新のベータ機能や実験的なプロンプトキャッシュ機能を確実に有効化できるようになります。

変更前

モデルの思考の深さ（努力量）を調整するには、環境変数の設定や設定ファイルの編集、あるいは/modelコマンドの奥にある設定を変更する必要がありました。

変更後

/effortコマンドを使用して、チャットインターフェースから直接「low」「medium」「high」のレベルを切り替えられるようになりました。

ユーザーへの恩恵

単純な作業には低い努力量で高速に、複雑な設計には高い努力量でじっくりと考えさせるなど、タスクの性質に合わせてパフォーマンスとコストを瞬時に最適化できます。

変更前

モデル拡張コンテキストを使用している非常に長いセッションで特定のスキルを実行しようとすると、実際には余裕があるにもかかわらずコンテキスト不足のエラーが発生する場合がありました。

変更後

スキルの呼び出しにおけるコンテキスト計算ロジックが修正され、大規模なコードベースを対象にした作業でも安定してスキルを実行できるようになりました。

ユーザーへの恩恵

超巨大なプロジェクト全体をコンテキストに入れながら、カスタムスキルを制限なく活用した開発が可能になります。

変更前

モデルを切り替えても画面上部の表示が変わらないため、実際にどのモデル（Sonnet 4.6 や Opus 4.6 など）が動作しているか不安になることがありました。

変更後

モデル変更が即座にヘッダー表示へ反映され、現在アクティブなモデルを正確に把握できるようになりました。

ユーザーへの恩恵

意図したモデルが正しく選択されていることを視覚的に確信できるため、安心して作業を継続できます。

変更前

サブエージェントの設定で詳細なモデルバージョンを指定しても無視されることがあり、期待した性能のモデルが起動しない場合がありました。

変更後

サブエージェントの設定で、メインセッションと同じように正確なモデルIDを使用して、特定の用途に最適なモデルを確実に割り当てられるようになります。

ユーザーへの恩恵

タスクごとに最適なモデルを確実に使い分けることができ、精度の向上やコストの最適化を正確に制御できるようになります。

変更前

サブエージェントに opus や sonnet を指定しても、クラウドプラットフォームの制約により意図せず古いモデルが使用されることがありました。

変更後

各プロバイダーでのモデルエイリアス解決が修正され、常に最新の Claude 4.6 (Sonnet/Opus) などの指定したスペックが正しく適用されます。

ユーザーへの恩恵

サブエージェントが本来の推論能力をフルに発揮できるため、複雑なタスクの解決精度が向上します。

変更前

フックを使用するたびに余分なメッセージがコンテキストに蓄積され、トークン消費が増大したりモデルの精度に影響したりしていました。

変更後

内部的なリマインダー挿入ロジックが改善され、コンテキストがクリーンに保たれるようになりました。

ユーザーへの恩恵

フックを多用してもコンテキストウィンドウが圧迫されにくくなり、長時間の対話でも一貫した性能が維持されます。

変更前

回答の生成が始まった後は思考レベルの調整ができず、意図に合わない場合は一度中断してやり直す必要がありました。

変更後

/model コマンドと同様に生成中でも動的に変更可能になり、思考プロセスをリアルタイムに制御できます。

ユーザーへの恩恵

回答の詳しさに応じて柔軟に思考の深さを切り替えられるため、効率的に最適な出力を得られます。

変更前

特定の企業プロキシ環境や一部の最新モデルの組み合わせにおいて、リクエストが不正と判定され通信できないことがありました。

変更後

VS Code拡張機能の通信リクエストヘッダーが修正され、ネットワーク制限のある環境でも安定して利用可能です。

ユーザーへの恩恵

利用環境を選ばず、常に最新モデルの能力をVS Code上でフルに活用できます。

変更前

サブエージェントを呼び出す際、特定の呼び出しにおいて一時的に異なるモデル（例：推論に優れた Opus など）を使用する柔軟性が欠けていました。

変更後

Agent ツールの引数として model パラメータが再び利用可能になり、呼び出しごとに最適なモデルを指定できるようになりました。

ユーザーへの恩恵

基本は高速な Sonnet を使いつつ、難解なタスクのサブタスクのみ Opus に任せるといった、コストと精度の細かな調整が可能になります。

変更前

Claude が処理を実行している最中に現在のモデルを確認しようと /model を入力しても、応答が返ってこない状態でした。

変更後

Claude の動作状況に関わらず、/model コマンドによるモデル情報の表示が即座に反映されるようになりました。

ユーザーへの恩恵

回答を待っている間でも、現在どのモデルが使用されているかをいつでも確認できるため、モデル切り替えの判断がスムーズになります。

変更前

Windows の Git Bash などを使用している際、パス形式の差異によって Claude が自身のカレントディレクトリを誤認し、既に許可済みのコマンドでも再確認を求めてくることがありました。

変更後

OS ごとのパス形式の差異が吸収され、不要なパーミッション確認が行われなくなりました。

ユーザーへの恩恵

Windows 環境での開発体験が向上し、無意味なプロンプトによる中断がなくなります。

変更前

Amazon Bedrock のカスタム推論プロファイルなど、標準的な命名パターンから外れるモデル識別子を使用すると、モデルが対応していない effort (推論の試行回数) パラメータが送信され、API エラーが発生していました。

変更後

モデル識別子が標準的な Claude の命名規則に一致しない場合は、互換性のないパラメータの送信を避けるようロジックが修正されました。

ユーザーへの恩恵

Bedrock などのクラウドプロバイダー経由で Claude を利用する際、カスタム設定や特定のプロファイルを使用しても、予期せぬパラメータエラーで作業が中断されることがなくなります。

変更前

設定ファイルに旧バージョンのモデル名が記載されていると、起動するたびに「最新モデルへの更新」通知が表示され、ユーザーにとってノイズになっていました。

変更後

モデルの自動アップグレード処理と通知ロジックが整理され、不必要な繰り返し通知が表示されないようになりました。

ユーザーへの恩恵

起動時の不要な通知に邪魔されることなく、常に最新モデル（Opus 4.6）を最適な状態で利用できます。

変更前

最新のモデル性能を期待してバージョンを指定しても、実際には古いバージョンのモデルが呼び出されていました。

変更後

モデル名の解決ロジックが更新され、指定に応じて適切な現行モデルが使用されるようになりました。

ユーザーへの恩恵

Claudeの最新かつ最高性能の推論能力を、混乱なく確実に活用できるようになります。

変更前

これまでは、プランに関わらずデフォルトの思考レベルが一律であったか、あるいは詳細な調整が明示的に行われていませんでした。

変更後

Max/Teamユーザーのデフォルトがmediumに設定され、標準的なタスクにおいて十分な推論品質を維持しつつ、より迅速な応答が得られるようになります。

ユーザーへの恩恵

速度と精度の「スイートスポット」がデフォルトになることで、ユーザーは設定を意識することなく、効率的に高品質なコード生成や問題解決を行えるようになります。

変更前

Opus 4や4.1といった旧バージョンのモデルが利用可能で、特定の環境ではこれらが固定して使用されていました。

変更後

旧バージョンが廃止され、より高性能なOpus 4.6へ集約されます。

ユーザーへの恩恵

最新の推論能力と「思考レベル」調整機能を備えたOpus 4.6へ自動でアップグレードされるため、手動で設定を更新する手間なく、常に最高性能のOpusモデルを利用できます。

変更前

エラー出力を捨てる意図で実行されたコマンドによって、意図せず nul という不要なファイルがカレントディレクトリに作成され、リポジトリが汚れる不都合がありました。

変更後

環境に応じた適切なヌルデバイスへのリダイレクトが行われるように修正され、余計なファイルが作られることはなくなりました。

ユーザーへの恩恵

Windows 環境での開発時に、AI が生成する「ゴミファイル」に悩まされることなく、クリーンな作業環境を維持できます。

変更前

「/model」コマンドを実行しても、現在どのモデルがアクティブになっているかがメニュー上で明確に示されていませんでした。

変更後

「/model」コマンドのメニューに、現在選択されているモデルが表示されるようになりました。

ユーザーへの恩恵

現在アクティブなモデルを簡単に確認できるようになり、モデルの切り替えや管理が容易になります。

変更前

モデルピッカーでは、モデルID(例: claude-sonnet-4-6)が表示されていましたが、どのバージョンか分かりにくい場合がありました。

変更後

モデルピッカーに「Sonnet 4.5」のような分かりやすいラベルが表示され、新しいバージョンへのアップグレードが促されるようになりました。

ユーザーへの恩恵

モデルの選択が容易になり、常に最新または推奨されるモデルバージョンを利用しやすくなります。

変更前

以前は、Claude Code SDKの利用者は、どのモデルが「エフォートレベル」の調整をサポートしているか、どのようなエフォートレベルが利用可能か、またはアダプティブシンキングをサポートしているかといった情報をプログラム的に検出できませんでした。これにより、モデルの機能を最大限に活用するためのカスタムアプリケーション開発が困難でした。

変更後

今回の追加により、SDKモデル情報にsupportsEffort(エフォートレベルサポートの有無)、supportedEffortLevels(サポートされるエフォートレベルのリスト)、およびsupportsAdaptiveThinking(アダプティブシンキングサポートの有無)といったフィールドが提供されるようになりました。これにより、SDK利用者はプログラム的にモデルの推論能力に関する詳細な情報を取得できます。

ユーザーへの恩恵

SDKを利用してClaude Codeを統合する開発者は、各AIモデルの推論機能に関する情報を取得し、ユーザーインターフェースや自動化ロジックに動的に反映できるようになります。これにより、より高度でモデルの特性を活かしたアプリケーションを構築し、ユーザーに最適なモデル選択肢を提供できるようになります。

変更前

多数のカスタムスキルをインストールすると、Claude Codeの組み込みスラッシュコマンド(/help、/modelなど)がオートコンプリートの候補リストから消えてしまい、発見や利用が困難になっていました。

変更後

多数のユーザー定義スキルがインストールされている場合でも、組み込みスラッシュコマンドがオートコンプリートドロップダウンに正しく表示されるようになりました。

ユーザーへの恩恵

組み込みコマンドの発見性が向上し、ユーザーはClaude Codeの基本機能をより容易に利用できるようになりました。これにより、ツールの使い勝手が向上しました。

変更前

チームメイトをスポーンする際、.claude/agents/*.md に定義されたカスタムエージェントの model フィールドが無視され、意図したモデルが使用されない問題がありました。

変更後

チームメイトスポーン時にカスタムエージェントの model フィールドが正しく適用されるようになりました。

ユーザーへの恩恵

カスタムエージェントのモデル設定がチームメイトのスポーン時に反映されるようになり、エージェントチームの挙動をより細かく制御できるようになりました。

変更前

会話のコンパクションが発生すると、プランモードの設定が失われ、モデルが実装モードに移行してしまう問題がありました。これにより、プランに基づいた正確な実装が妨げられていました。

変更後

コンパクション後もプランモードが維持されるようになりました。これにより、モデルはプランニングモードから実装モードへ切り替わることなく、プランに基づいた作業を継続できます。

ユーザーへの恩恵

コンパクション後もプランモードが維持されるため、開発者は計画に基づいた作業を中断なく進めることができ、コード生成の正確性と効率が向上しました。

変更前

サードパーティのLLMプロバイダー(AWS Bedrock, Google Vertex AIなど)経由でClaude Codeを利用しているユーザーも、モデルセレクターにAnthropic APIの料金情報が表示され、実際の利用料金と異なる誤解を招く可能性がありました。

変更後

サードパーティプロバイダーを利用するユーザーのモデルセレクターから、Anthropic APIの料金表示が削除されました。これにより、ユーザーは自身の契約しているプロバイダーの料金体系に基づいた正確な情報を確認できるようになります。

ユーザーへの恩恵

自身の利用環境に応じた正確な情報のみが表示されるようになり、料金に関する混乱がなくなります。これにより、ユーザーは安心してClaude Codeの費用を管理できます。

変更前

API会話履歴に予期しない「(no content)」というテキストブロックが表示され、トークンが無駄に消費されたり、モデルが混乱したりする可能性がありました。

変更後

API会話履歴に表示される不要な「(no content)」テキストブロックの問題が修正されました。

ユーザーへの恩恵

トークンの無駄遣いがなくなり、モデルの応答の精度が向上し、会話履歴がクリーンになりました。

変更前

セッション中に/modelコマンドを実行しても、すぐにモデルが切り替わらず、キューに入れられて実行されるまで待機する必要がありました。

変更後

/modelコマンドは実行キューに入れられず、即座にモデルが切り替わるようになりました。

ユーザーへの恩恵

モデルの切り替えが迅速になり、対話的な作業中にスムーズにモデルを変更できるようになりました。

変更前

設定やコンテキスト確認のためのオーバーレイ画面を表示している際、操作中にウィンドウが意図せず閉じてしまうことがありました。

変更後

各コマンドのオーバーレイ画面の表示安定性が向上し、操作中に不意に閉じることがなくなりました。

ユーザーへの恩恵

設定変更やステータス確認の作業を中断されることなく、確実に行うことができます。

変更前

ツール実行前のPreToolUseフックは、モデルに渡す追加情報を提供できませんでした。

変更後

PreToolUseフックは、ツールの実行前にモデルにadditionalContextとして追加情報を提供できるようになりました。

ユーザーへの恩恵

これにより、フックはツールの実行前にモデルに追加のコンテキストを提供できるようになり、よりインテリジェントな意思決定や、フックによるツール実行の制御が可能になります。

変更前

ローカルスラッシュコマンドを実行する際、/model や /theme などで、モデルやテーマの選択 UI が一瞬表示されて消えることがありました。

変更後

ローカルスラッシュコマンド実行時に、モデルやテーマの選択 UI が一瞬表示されて消える現象を修正しました。

ユーザーへの恩恵

コマンド実行時の UI のちらつきがなくなり、よりスムーズで快適な操作感を提供します。

変更前

メインセッションで設定したクロスリージョン推論のオプションが、新しく起動したサブエージェントに正しく引き継がれず、特定のリージョンに制限された権限環境でエラーになっていました。

変更後

すべてのサブエージェントが親セッションの推論設定を正しく共有するようになり、分散リージョン環境でも安定して動作します。

ユーザーへの恩恵

グローバルな AWS インフラを利用しているエンタープライズユーザーも、サブエージェント機能を確実に利用できます。

変更前

サードパーティプロバイダー経由で軽量モデルを指定した際、UI 上でどのモデルが現在アクティブであるかが正しく表示されない混乱がありました。

変更後

すべてのプロバイダーにおいて、指定されたモデル別名と実際の表示が一致するようになりました。

ユーザーへの恩恵

自分がどのモデルを使用しているかを常に確信を持って確認でき、意図しない高コストなモデルの使用などを防げます。