こんにちは、Lena がやって来ます~ Claude Code Opus 5.5 は、すでにアクティブであると仮定するのではなく、明示的に選択するモデルの 1 つです。理由は簡単です。opus エイリアスはすべてのプロバイダーで同じ方法で解決されるわけではなく、再開された Claude Code セッションは以前に使用していたモデルで再び開かれる可能性があります。
そのため、有意義なテストを行う前に、Claude Code が実行中と表示するモデル、操作を許可したリポジトリ、そして試用を評価するための結果という三点を確認しておきたいと思います。
証拠メモ: Anthropic 2026 年 9 月 22 日に Opus 5.5 を発表。 9 月 24 日に現在のドキュメントを確認しました。ここには Claude Code がインストールされていないため、以下の演習は再現可能な手順であり、完成したモデル テストではありません。
アクセスを確認し、Claude Code を更新します
以下から始めます:
claude --version
Anthropic によると、Opus 5.5 には Claude Code v2.1.280 以降が必要です。インストールが古い場合は、次を実行します。
claude update
その後、再度バージョンを確認してください。インストールの動作がおかしい場合は、再インストールやモデル設定の変更を繰り返すよりも、次のステップとして claude doctor を使用する方が有効です。
モデルの入手可能性は、Claude Code のアカウントによっても異なります。対象となる有料クロード プラン、コンソール アカウント、またはサポートされているクラウド プロバイダーを介したアクセスが必要です。無料の Claude.ai アカウントだけでは十分ではありません。
ここでも組織設定が重要です。 Opus 5.5 が単に表示されない場合は、ローカルの Claude Code インストールが壊れていると考える前に、アカウント、プロバイダー、および管理対象モデルの制限を確認します。
セッションに Opus 5.5 を選択します
現在のモデル ピッカーを使用する
Claude Code 内に次のように入力します。
/model
次に、Opus 5.5 を探します。
Anthropic の Claude Code モデル構成ガイド では、ピッカーに 2 つのわずかに異なる動作を提供します。
sは、保存されたデフォルトを変更せずに現在のセッションを切り替えます。- Enter を押すとモデルが選択され、将来のセッションのために保存されます。
試しに使うならsが良いと思います。私は、普段使用しているモデルを黙って変更する評価セッションを望んでいません。
次のように入力することもできます。
/model claude-opus-5-5
これで選択範囲が保存されます。
見逃されやすい詳細が 1 つあります。opus はエイリアスであり、バージョン ピンではありません。
執筆時点では、これは Anthropic の API、AWS の Claude Platform、Amazon Bedrock、および Google の Agent Platform の Opus 5.5 にマッピングされていますが、Microsoft Foundry ではまだ別の方法で解決されています。演習の目的が特に Opus 5.5 を評価することである場合は、別名を信頼するのではなく、完全なモデル名を使用します。
CLI で完全なモデル名を使用する
Anthropic の API に対する新しいセッションの場合:
claude --model claude-opus-5-5
これにより、保存されたデフォルトを書き換えることなく、その起動にモデルが適用されます。
クラウドの導入は、あまり整理整頓されていない可能性があります。プロバイダーによっては、Anthropic のプレーンなモデル文字列ではなく、推論プロファイル ARN、デプロイメント名、またはプロバイダー固有のモデル バージョンが相当する場合があります。その場合、プロバイダー構成はテスト設定の一部であり、無視できる実装の詳細ではありません。
どのモデルがアクティブであるかを確認する
モデルを選択した後、次を実行します。
/status
これは私が信頼できる小切手です。アクティブなモデル、バージョン、アカウントが表示され、設定されたステータス行でもモデルを公開できます。
Claude Code にモデルの使用を要求することと、そのモデルでセッションが実際に開始されたことを証明することはまったく同じではないため、この区別は重要です。組織の許可リスト、プロバイダーの構成、フォールバック、再開されたセッションはすべて、この想定を複雑にする可能性があります。
/status が予期しないものを示した場合は、そこで停止し、最初に選択を修正します。私は、その書き方、コーディング動作、または以前のセッションで記憶されているラベルからモデルを特定しようとはしません。
モデル名と一緒にプロバイダーも記録します。 2 つのセッションでは、その下にある異なるプロバイダー デプロイメント ID に解決しながら、人間が判読できる類似のモデル名を表示できます。
小さくて可逆的なリポジトリ タスクを 1 つ与えてください
最初のテストでは、機能のビルドは避けます。
使い捨てリポジトリ、またはシークレット、本番認証情報、顧客データのない安全なテスト ブランチを使用します。まず作業ツリーを確認します。
git status --short
次に、リポジトリの通常のローカル テスト コマンドを実行します。開始状態が正常であることがわかったら、ブランチを作成します。
git switch -c trial/opus-5-5
これにより、Git ブランチがセキュリティ境界であるかのように装うことなく、明確な比較ポイントが得られます。
役に立つ最初の概要は次のようになります。
「指定された関数の空の入力に対する回帰テストを 1 つ追加します。テストが失敗した場合にのみ実装を変更します。その関数とテスト ファイルのみをタッチします。依存関係は追加せず、ネットワークも使用せず、コミットまたはプッシュする前に停止します。既存のローカル テスト コマンドを実行し、変更されたファイルと結果をレポートします。」
実行する前に、一般的な参照を実際のパス、正確な関数名、既知のテスト コマンドに置き換えます。
このタスクは意図的に退屈なものです。それは便利です。
最初のモデル チェックでは、モデルが印象的な実装を発明できるかどうかよりも、スコープを尊重し、既存のテスト構造に気づき、必要な最小限の変更を加え、停止するように指示した場所で停止するかどうかを重視します。
許可プロンプトを有効にして、タスクに実際に必要なものだけを承認します。
テスト結果だけでなく、差分も確認してください
Claude Code が完了したら、以下を検査します。
git status --short
git diff --check
git diff
Git の 最新の差分ドキュメント では、これらの比較が何を示しているかを正確に説明していますが、重要なレビューは依然としてあなたに属します。つまり、モデルは許可したファイルにアクセスしましたか、変更は実際に概要と一致していますか?
ここでの 1 つの罠は、プレーン git diff では追跡されていないファイルが表示されないことです。きれいに見える差分を他に何も表示されていない証拠として扱うのではなく、それらを個別に確認してください。
次に、ローカル テスト コマンドを自分で実行し、終了ステータスを記録します。
テストに合格することは有用な証拠ですが、それだけでは十分ではありません。モデルは要求されたテストに合格しても、不必要なファイルを作成したり、合意された範囲外のものを編集したり、概要で明示的に除外されている依存関係を導入したりする可能性があります。
トライアルがレビューに耐えられなかった場合は、実験に関係するファイルのみを復元し、新しく作成されたファイルを検査して削除し、開始ブランチに戻ります。
コードを破棄した場合でも、テスト出力は保持してください。失敗したトライアルは、モデルが範囲を無視した箇所や概要の指定が不十分だった箇所を示すため、クリーンなデモよりも有益であることがよくあります。
EvoX コード レビューの場合、私が持参する成果物はシンプルです。ブランチ名、実際の差分、テスト ログです。ローカルの EvoX マテリアルはリポジトリ レビューをサポートする場合がありますが、それは自動 Claude Code セッション ハンドオフを意味するものではありません。
通常のモデルに戻る
テストで s または --model を使用した場合は、オーバーライドせずに新しい Claude Code セッションを開始し、/status を再度実行します。
/model で Enter キーを押した場合は、通常のモデル (またはデフォルト) を選択して Enter キーを押すと、選択内容が再び保存されたデフォルトになります。
プロジェクトと組織の設定はユーザーレベルの設定を上書きできるため、リセットが機能したと仮定するのではなく、新しいセッションを確認します。
後でトライアルを再開する場合も同様です。再開された Claude Code セッションでは、以前のセッションに関連付けられたモデルが復元される場合があります。
よくある質問
組織管理者は、ユーザーが Claude Code で選択するモデルを制限できますか?
はい。管理された availableModels 設定とエンタープライズ コントロールにより、モデル ピッカーに表示される内容を制限できます。
Opus 5.5 が管理環境に存在しない場合は、ローカル インストールのトラブルシューティングを行う前に管理者に確認してください。
ユーザーのグローバルデフォルトを変更せずに、プロジェクトで Opus 5.5 を固定できますか?
はい。プロジェクトの .claude/settings.json では以下を指定できます。
"model": "claude-opus-5-5"
これは、共有プロジェクト設定をチームの他のメンバーとレビューする必要があるものの、リポジトリが 1 つのモデルで意図的に標準化されている場合に役立ちます。
1 回限りの評価の場合は、グローバルなデフォルトが変更されていないため、やはり --model を好みます。
古い Claude Code セッションを再開すると、元のモデルは保持されますか?
Anthropic の API を使用する場合、多くの場合、そうです。
例外もあります。廃止されたモデル、組織の制限、明示的な起動オーバーライド、プロバイダー固有の展開動作により、セッション再開時に実際に利用できる内容が変更される可能性があります。
そのため、再開されたテストの開始時にも /status が属します。
Opus 5.5 と他のクロード モデルでは使用制限はどのように異なりますか?
Anthropic は、Pro、Max、および Team プランの 5 時間の使用制限を引き上げることを発表しましたが、すべてのワークロードに明確に適用される普遍的な「モデルあたり X タスク」という数値はありません。
自分のアカウントに付与されている手当を確認するには、/usage を使用します。 2 つのモデルが同じピッカーで使用できるという理由だけで、その許容量を同じように消費するとは思いません。
Opus 5.5 は、サポートされているすべてのクラウド プロバイダーから入手できますか?
Anthropic は、独自のプラットフォームである AWS、Google Cloud、Microsoft Foundry をリストに挙げています。
これは、すべてのアカウント、リージョン、展開、または組織が自動的にアクセスできることを意味するわけではありません。プロバイダーの名前も異なり、opus エイリアスはどこでも Opus 5.5 に解決されるわけではありません。
実際に比較するには、出力の判断を開始する前に、プロバイダー デプロイメント識別子と /status に示されているモデルの両方を確認してください。
以前の投稿:
- 制限付きリポジトリ タスクを中心に別の Claude Code ワークフローを構築したい場合は、Obsidian Claude Code vault-to-code workflow で、制御されたコンテキストを取得し、それをコードに適用し、チェックを実行し、レビュー後にのみ書き戻す方法を示します。
- より強力な推論設定が実際にリポジトリ作業を改善するかどうかを評価するために、Muse Spark 1.3 エージェント推論 は、固定コーディング タスクの下で完了品質、介入、待ち時間、およびタスク コストを比較します。
- コーディング エージェントの作業をレビュー可能に保つことが主な関心事である場合、T3 コード レビュー は、リポジトリ スコープ、セッション コントロール、差分検査、および 1 つのコーディング サーフェスに関する人間によるハンドオフに焦点を当てます。
