Claude Opus 5.5がCopilotに登場｜対象プランと確認点【2026年9月】

最終更新：2026-09-23（日本時間）

GitHubのChangelogでClaude Opus 5.5のCopilot対応が告知されたのは2026年9月22日だ。翌日の時点で見るべきなのは、単純な「最強モデルが追加された」というニュースだけではない。現場では、契約プランに含まれるのか、どの画面で選べるのか、管理者が止めていないか、使った分の費用をどこで確認するのかが、導入判断を分ける。

しかも、Copilotでの提供とAnthropicのAPIでの提供は同じモデル名を共有していても、利用契約と請求画面が同じになるわけではない。仕様を理解せずに「APIが1MTokあたりいくらだから、Copilotの1回も同じ」と置き換えると、予算説明も利用者への案内も不正確になる。

この記事では、GitHubとAnthropicの公式ページで確認できる範囲を基準に、対応プラン、モデルピッカー、段階展開、管理ポリシー、料金の読み方、モデル仕様、移行時の注意、向く仕事と向かない仕事を一つの判断手順にまとめる。実際の顧客事例や未実施の検証数値は扱わず、本文中の具体的な進め方はすべて「想定シナリオ」として示す。

Claude Opus 5.5がGitHub Copilotに追加された意味

GitHub Changelogの発表日は2026年9月22日。GitHubの公式発表では、Claude Opus 5.5をagentic coding、long-running agentic tasks、knowledge workに使えるモデルとしてCopilotへ追加したと説明している。ここでいう追加は、Anthropicのサービスを別に契約してCopilotへ手動接続するという意味ではなく、GitHub Copilotの対応モデルとして選択肢に入ったという意味だ。

「追加された」と「全員が今すぐ使える」は別

この発表から読み取れる事実は二つある。一つは、GitHubがCopilotのモデルピッカーからOpus 5.5を選べる対象を明示したこと。もう一つは、rollout will be gradual、つまり段階展開だと明記したことだ。したがって、対象プランを持っているのに、ある製品の画面でまだ表示されない状態は、発表内容と矛盾しない。

利用者がまず切り分けるべきなのは、モデルの性能評価ではなく提供経路だ。Copilotのどの製品を使っているか、個人契約か組織シートか、組織ポリシーがあるか、段階展開がアカウントに届いているかを分けて確認する。モデルを選べない状態で、API向けの設定や別サービスの契約を追加しても、Copilotのモデルピッカーは変わらない。

ウォーターマークについて先に知っておく

GitHubは、Claude Opus 5.5のテキスト出力にテキストのウォーターマークが付くと案内している。同時に、そのウォーターマークは意味・品質・可読性を変えず、トークンやコストを増やさないとも説明している。文章の見た目に関する社内ルールがある場合は、導入前に実際の社内レビュー基準と照合すればよいが、GitHubの説明を超えて検出精度や著作権上の効果を推測してはいけない。

Anthropicの発表には、Opus 5.5がOpus 5に対して典型的なワークロードで40%低コスト、出力生成で30%以上高速という説明もある。また、Fable 5.1水準の性能を多くの仕事で示すという位置づけもある。ただし、これらはAnthropicが提示する主張であり、Copilot上の全利用者の体験や請求額を保証する数値ではない。社内資料では「Anthropic発表による」と出典を付け、Copilotの実請求や自社の処理時間と混同しない。

なお、Opus 5をClaude Codeで使い分ける観点は、Claude CodeのOpus 5使い分け完全ガイドにも整理している。CopilotとClaude Codeは同一の操作画面ではないが、「タスクの性質に応じてモデルを選ぶ」という考え方は、Copilotでの選択にも応用できる。

対応プランとモデルピッカーの対象画面

GitHub Changelogが明示しているClaude Opus 5.5の対象プランは、Pro+、Max、Business、Enterpriseだ。この記事でいう「対象」は、GitHubが発表文で利用可能と記載した範囲を指す。別のプランについて、表示されない理由を価格や機能から推測して断定することはしない。

四つのプランを同じ言葉で扱わない

• Pro+：個人利用の中で、より高度なモデルや利用量を確認する層。自分の契約アカウントでモデルピッカーを確認する。
• Max：個人利用で継続的にエージェント作業を行う層。利用可能表示と、利用量・予算の画面を分けて確認する。
• Business：組織のシートと管理設定が関係する層。利用者の画面だけでは可否を決められない。
• Enterprise：組織のモデルポリシー、契約上の運用、監査や予算のルールを合わせて確認する層。

Pro+とMaxでは、契約した個人アカウントでサインインしているかが重要になる。BusinessとEnterpriseでは、同じメールアドレスに見えても、個人側のCopilotと組織側のCopilotで適用条件が違うことがある。組織リポジトリで作業しているなら、個人契約のモデル選択を見て判断せず、所属組織の案内と管理設定を確認する。

GitHubが列挙するモデルピッカーの面

発表文では、次の面でモデルピッカーから選択できると記載されている。すべてが同じUIという意味ではなく、製品ごとのモデル選択箇所にOpus 5.5が展開されるという読み方が安全だ。

• Visual Studio Code
• Visual Studio
• Copilot CLI
• GitHub Copilot coding agent
• GitHub Copilot app
• github.com
• GitHub Mobile on iOS and Android
• JetBrains IDEs
• Xcode
• Eclipse

対象面が多いからこそ、「VS Codeで見えたので組織全体で解禁された」「github.comで見えないので契約対象外だ」と一つの画面から全体を推定しない。作業場所ごとに、アカウント、組織、モデルポリシー、展開状況が同じかを確認する。

関連する既刊との読み分け

Opus 5の1Mコンテキストやeffortの考え方を先に整理したい場合は、Claude Opus 5の使い方とeffort設定のガイドが前提知識になる。ただし、そこで説明されるClaude.ai、Claude Code、APIの選択手順を、そのままGitHub Copilotの画面操作や料金へ置き換えてはいけない。今回の論点は、Copilotに追加された提供経路である。

段階展開でモデルが見えないときの切り分け

GitHubはOpus 5.5のロールアウトを段階展開と明記している。したがって、2026年9月23日にモデルピッカーへ出ない場合の結論は、まず「まだそのアカウントまたはその面に届いていない可能性がある」だ。段階展開と管理者による制御を一緒に扱わないことが、切り分けの出発点になる。

利用者が確認する順番

1. 契約プラン：自分がPro+、Max、Business、EnterpriseのどれでCopilotを利用しているかを、契約・アカウント画面で確認する。
2. サインイン先：個人アカウントと組織アカウントを取り違えていないか、対象リポジトリを所有する組織と現在の利用先が一致するかを確認する。
3. 対象面：GitHubが列挙するモデルピッカーのどの面で見ているかを記録する。VS Codeで見えないことと、github.comで見えないことを同じ障害として扱わない。
4. 組織のモデルポリシー：BusinessまたはEnterpriseなら、管理者がClaude Opus 5.5を無効にしていないか、既定モデルの有効化を止めていないかを確認する。
5. 段階展開：上記に問題がなければ、GitHubが案内する「check back soon」の意味を踏まえ、一定期間を置いて同じ条件で再確認する。

ここでいう「一定期間」は、この記事で勝手に日数を指定しない。GitHubの展開状況はアカウントや製品面で変わり得るため、表示されない状態に対して「何時間待てば必ず出る」と約束できる公式根拠がないからだ。

管理者が確認するモデルポリシー

GitHubの発表によると、Copilot BusinessとCopilot Enterpriseの管理者は、Copilot settingsのmodel policyからClaude Opus 5.5へのアクセスを管理できる。default model enablementでは、新しいモデルが自動的に有効になる設定がある一方、管理者がグローバル既定をオフにしている場合や、このモデルを明示的に無効にしている場合は扱いが変わる。

管理者は、利用者から「表示されない」と問い合わせを受けたとき、個別の開発環境だけを疑う前に、組織のモデルポリシーを確認する。確認結果を「組織として許可」「組織として不許可」「ポリシーは許可だが段階展開待ち」に分けて伝えると、利用者が無関係な再設定を繰り返さずに済む。

想定シナリオ：Businessの開発者にだけ表示されない

Businessの利用者がVS Codeのモデルピッカーを開いてもOpus 5.5が見えない状況を想定する。管理者はまずmodel policyで個別モデルの無効化と既定モデルの扱いを確認し、利用者は組織アカウントでサインインしているかを確認する。ポリシーが許可で、対象プランも一致しているなら、段階展開による未表示としてGitHubの最新案内を確認する。原因が確定していないのに「アプリを再インストールすれば解決する」と案内するのは避ける。

料金はCopilot内課金とAnthropic APIを分けて読む

料金の説明で最も重要なのは、同じClaude Opus 5.5でも、Copilot内の利用とAnthropic APIへの直接利用は請求主体と表示方法が異なるということだ。

GitHub Changelogが言っていること

GitHubは、Claude Opus 5.5を「provider list pricingに基づくusage-based billing」で請求すると案内し、詳しい情報はGitHub CopilotのModels and pricingへ誘導している。これは、Copilotの利用量に応じた課金の仕組みを確認せよという意味であり、Copilot内の1回あたりの請求額やAIクレジット換算を、この記事で勝手に決められるという意味ではない。

社内の予算表では、少なくとも次の四つを別欄に置く。

• Copilotの契約プランと対象ユーザー
• Copilotで選んだモデルと利用した製品面
• GitHub側に表示されるusage-based billingの利用量・予算・請求情報
• Anthropic APIを別に契約している場合のAPI利用量・請求情報

「provider list pricing」という言葉を見て、Anthropic APIの公開単価をそのままCopilotの請求書へ転記しない。GitHubがどの画面で、どの単位で、どの契約に対して表示するかを、その組織の請求・利用量画面で確認する。Copilot単体の換算価格が確認できない状態では、「未確認」と書くのが正しい。

Anthropic APIの公開価格は別の基準

AnthropicのClaude Platform Docsでは、Claude Opus 5.5の通常のAPI価格を入力$4 / MTok、出力$20 / MTokと示している。MTokは100万トークンを表す。これはAnthropic APIの公開リスト価格であり、GitHub Copilotを契約した利用者に対して、そのまま同額が請求されることを意味しない。

この二つを説明するときは、次のように書き分ける。

• Anthropic API：公式Platform Docsに入力$4／MTok、出力$20／MTokとある。
• GitHub Copilot：GitHub Changelogはprovider list pricingによるusage-based billingと説明する。Copilot内のOpus 5.5単体価格は、GitHubの現行Models and pricing、契約、利用量画面で確認する。

この書き分けなら、APIで独自にアプリを作るチームと、Copilotで開発支援を使うチームの費用を比較する際にも、請求境界が崩れない。逆に、API価格だけを使って「1回のCopilot利用は何円」と算出するのは、入力・出力トークン、キャッシュ、Copilotの換算ルールが確定していない限り根拠不足になる。

想定シナリオ：予算申請で数字を一つにまとめない

開発部門が翌月のAI予算を申請する場面を想定する。Copilot利用分はGitHubのusage-based billingと利用量画面を根拠にし、APIを使う検証環境があるならAnthropicの入力・出力MTok単価を別欄に置く。両方を合算する場合も、どのサービスのどの画面から拾った数字かを注記する。Opus 5.5のCopilot単価が未確認なら、その欄は「GitHubの契約・請求画面で確認」とし、推定値で埋めない。

GitHubのプランや追加利用の扱いは変わる可能性があるため、契約条件はGitHub Copilotの公式Plans & pricingで確認する。この記事は、そのページにある表示を代替する料金表ではない。

1Mコンテキストと移行時の仕様変更を確認する

Claude Opus 5.5そのものの基礎仕様は、GitHubのプラン説明ではなくAnthropicのClaude Platform Docsで確認する。公式Overviewに記載された要点は、モデルID claude-opus-5-5、コンテキストウィンドウ1Mトークン、最大出力128Kトークン、Adaptive thinking常時オン、既定effortmediumだ。

Copilot利用者が仕様から読み取れること

1Mトークンは、長いリポジトリ文脈、複数の設計資料、長時間のエージェント作業を一つの作業文脈に置きやすいという意味で、Opus 5.5の位置づけと整合する。ただし、1Mまで入ることと、毎回1Mを投入することは別だ。不要な資料を詰め込めば、レビュー対象がぼやけ、利用量の管理も難しくなる。

最大出力128Kトークンも、毎回その量を返すという約束ではない。タスクの指示、ツールの結果、停止条件、利用面の制約によって実際の出力は変わる。画面に表示される応答量や処理時間を、仕様値から一律に予測しない。

Adaptive thinkingが常時オンで、既定effortがmediumという点は、旧モデルの「thinkingを明示的にオン／オフする」運用と違う。CopilotのモデルピッカーでOpus 5.5を選んだだけで、Anthropic API向けのthinking設定が画面に現れると考えない。Copilot側のUIに表示される項目と、Platform DocsにあるAPI仕様を分けて読む。

公式Migration Guideが挙げる破壊的変更

Anthropicの公式移行ガイドは、Claude Opus 5からClaude Opus 5.5へMessages APIの実装を移す場合の変更点を説明している。Copilotの利用者が全員コードを書き換えるという話ではないが、Copilotの背後に独自のAPI連携、ルーター、ツール実行基盤を持つ組織は確認対象になる。

• thinkingの無効化・旧形式の明示的有効化：Opus 5.5ではthinkingを従来の方式で無効化または有効化する指定がサポートされず、該当するリクエストはエラーになる。深さの調整は公式が案内するeffortの考え方で移行する。
• 強制ツール利用：tool_choiceの強制指定であるanyやtoolはサポートされず、該当する呼び出しはエラーになる。ツールを必ず使う前提のルーターは、公式ガイドを基に設計を見直す。
• thinking blockの結び付き：thinking blockはモデルと会話に結び付く。モデル切替やフォールバックを行うアプリケーションでは、別モデルへそのまま渡せるとは仮定せず、公式の互換性説明を確認する。
• ツール間テキストの扱い：ツール呼び出しの間に返るテキストがthinking blockとして扱われ、既定の表示ではテキストが空になる場合がある。そこを進捗表示として配信していた実装は、表示が静かにならないか確認する。
• computer use：公式ガイドは、Claude APIとGoogle Cloudで以前のcomputer_20251124ツールが受け付けられない変更も説明している。この記述をGitHub Copilotのすべての面へ拡張せず、該当するAPI経路を持つ場合だけ確認する。
• モデル名：Opus 5から移行するAPI実装では、モデル名をclaude-opus-5-5へ更新する。クラウド各社のモデルIDは公式の提供先ドキュメントに従う。

この章で大切なのは、Copilotの画面でモデルを選ぶ作業と、独自API実装の移行作業を混ぜないことだ。前者の利用者はモデルポリシーと請求を確認し、後者の開発者はMigration Guideのリクエスト互換性を確認する。両者を同じチェックリストにすると、不要なAPI設定変更を利用者へ求めることになる。

モデルID、effort、1Mコンテキストを含む仕様の背景は、Claude PlatformのOpus 5.5公式Overviewで確認できる。破壊的変更は、同ページからリンクされる公式Migration Guideを原文として扱う。

向いている仕事と、あえて使わない仕事

GitHubはOpus 5.5の用途としてagentic coding、長時間のエージェントタスク、knowledge workを挙げている。ここから実務の線引きを作るときは、「最も高性能だから常に選ぶ」ではなく、作業の長さ、判断の難しさ、文脈の量、レビューの責任を見て判断する。

向いている仕事

• 複数ファイルにまたがる設計・実装：変更箇所が一つではなく、既存仕様との整合、テスト、移行順序を同時に検討する仕事。
• 長時間のデバッグ：ログ、変更履歴、設定、再現条件を順番に照合し、途中で仮説を更新する仕事。
• 大きなリポジトリの監査：命名や単純な検索だけでなく、複数モジュールの依存関係、例外処理、テストの抜けをまとめて見る仕事。
• 知識作業：複数の社内資料や設計文書を横断し、根拠付きで論点を整理する仕事。機密情報の持ち込み可否は組織規程を先に確認する。
• 失敗からの復帰が必要なエージェント作業：一度の応答で終わらず、エラーの内容を読んで次の確認へ進む仕事。

あえて別のモデルや通常の手順を選ぶ仕事

• 短い定型修正：タイプミス、既知のフォーマット統一、明確な一箇所の文言変更など、判断がほぼ決まっている仕事。
• 大量の単純処理：入力と出力の形が固定され、深い探索よりもコストと処理量の予測が優先される仕事。
• 最終承認が人にある仕事：契約、法務、セキュリティ、公開文書など、モデルに判断を委ねず、候補整理だけをさせる仕事。
• 情報の持ち込みが許可されない仕事：コンテキストが大きくても、社内規程や契約で外部サービスへの入力が禁止されていれば使わない。

「向かない」は「品質が低い」という意味ではない。短い作業に大きなモデルを割り当てると、必要以上の利用量やレビュー負担になり得るため、業務設計上の適合性が低いという意味だ。モデルの切り替えを許可する組織では、簡単な作業は既定モデル、判断が重い作業はOpus 5.5という役割分担を試す。Copilotの実際の課金や利用量は、必ずGitHub側の表示で判断する。

想定シナリオ：大規模変更の前に成果物を定義する

複数モジュールにまたがる変更を依頼する場面を想定する。最初から「全部直して」と投げるのではなく、対象範囲、変更しない範囲、完了条件、確認すべきテスト、停止して人に聞く条件を文章にする。1Mコンテキストを理由に関連資料を無制限に入れるのではなく、必要な資料の一覧を先に作る。Opus 5.5は判断を補助するもので、マージ、公開、契約上の承認を自動で代替するものではない。

モデルの役割分担をさらに比較したい場合は、Opus 5とFable 5.1の使い分け記事を参照できる。ここでも、別サービスの料金や操作方法をCopilotへ直輸入せず、判断軸だけを自社のポリシーに合わせて使う。

長時間タスクを安全に進める作業設計

Opus 5.5を選んだ後に重要なのは、モデルを信頼して作業を丸投げすることではなく、長時間の作業をレビュー可能な単位に分けることだ。GitHubの発表は長時間のエージェント作業を用途として挙げるが、具体的な成功率や完了時間を保証しているわけではない。作業の設計と人の確認点は利用者側で決める必要がある。

開始前に固定する四つの境界

1. 対象境界：対象リポジトリ、ディレクトリ、ブランチ、触れてはいけないファイルを明示する。
2. 変更境界：実装、テスト、ドキュメント、設定のうち、今回どこまで扱うかを分ける。
3. 検証境界：静的確認、テスト、差分レビュー、セキュリティ確認の順番を決める。実行できない検証は「未実行」と残す。
4. 停止境界：仕様が不足した場合、破壊的変更が見つかった場合、権限や秘密情報に触れる場合に停止して人へ戻す。

途中経過を「完了」と取り違えない

長いタスクでは、エージェントが計画を出した段階、ファイルを編集した段階、テストが通った段階、レビューを終えた段階が異なる。画面に長い説明が表示されたことは、変更が正しいことの証明ではない。差分、テスト結果、未解決の警告、実行していない項目を別々に確認する。

また、Migration Guideにあるthinking blockやツール間テキストの扱いは、独自の進捗表示を作る場合に影響する。Copilotの画面で見えるテキストを、APIの内部ブロック構造と同一視しない。Copilot利用者は画面上の差分と結果を確認し、APIを経由する開発者はレスポンスのblock typeを公式仕様に従って扱う。

完了条件を人間が読める言葉にする

「実装した」だけでは完了条件にならない。変更対象、確認済みのテスト、未確認のケース、レビュー担当、戻し方が揃って初めて、組織で扱える成果物になる。モデルに求める返答にも、変更ファイルの一覧、判断の根拠、残課題、確認コマンドの結果を含めるよう指示する。ただし、実行していない結果を実行済みと書かせない。

管理者が導入前に確認するチェックリスト

BusinessとEnterpriseでは、利用者が「モデルを見つける」だけでなく、組織が「許可し、監督し、費用を説明できる」状態を作る必要がある。以下はGitHubの発表内容を起点にした運用チェックであり、管理画面の具体的な名称や表示は契約・更新で変わり得るため、実画面と照合する。

アクセスとポリシー

• 対象シートがPro+、Max、Business、Enterpriseのどれに該当するかを確認する。
• Business／EnterpriseのCopilot settingsでmodel policyを確認する。
• default model enablementを組織としてどう扱うか決める。
• Claude Opus 5.5を明示的に無効化していないかを確認する。
• 新しいモデルを自動有効化する場合の承認・周知ルールを決める。
• 利用者の問い合わせ窓口と、表示されないときの切り分け担当を決める。

費用と情報管理

• GitHubのusage-based billingで何が記録されるかを、現行のModels and pricingと組織の請求画面で確認する。
• 利用量、予算、追加利用の扱いを、CopilotとAnthropic APIで別々に記録する。
• Opus 5.5のCopilot単体価格を未確認のまま、APIの$4／$20を社内単価として流用しない。
• 機密コード、個人情報、顧客データを入力してよい範囲を既存のAI利用規程で確認する。
• 出力のウォーターマークについて、社内文書のレビュー・公開手順に必要な説明を加える。意味、品質、可読性、トークン、コストに関するGitHubの説明を超える効果は断定しない。

導入判定の記録

管理者は「有効／無効」の二択だけでなく、日付と対象面を残す。2026年9月23日にVS Codeで表示されなかったことが、段階展開の途中なのか、組織ポリシーで止めたのか、個人と組織を取り違えたのかで、次の対応は変わる。記録には契約プラン、対象面、サインイン先、ポリシー確認結果、請求画面の確認者を含めると説明しやすい。

利用者が使い始める前に確認するチェックリスト

利用者側は、モデルが見えた瞬間に大きなタスクを投入するのではなく、まず選択状態と作業境界を確認する。CopilotのUIは製品ごとに異なるため、以下では特定のボタン名や未確認のショートカットを指定しない。

開始前

1. 現在のCopilot契約プランと、作業対象の組織を確認する。
2. モデルピッカーに「Claude Opus 5.5」が表示され、選択後も表示状態が変わっていないかを確認する。
3. 作業対象、変更範囲、触れてはいけない情報、レビュー担当を入力前に整理する。
4. 単純作業にまでOpus 5.5を使う必要があるか、利用量と品質の両面から判断する。
5. 結果をそのままマージ・公開しないという承認手順を確認する。

作業中

• 大きな変更は計画、実装、テスト、差分レビューに分ける。
• モデルが不確かな仕様を断定したら、根拠となるファイルや文書を示させる。
• ツール実行やファイル変更の結果を、説明文ではなく差分と実行結果で確認する。
• 会話が長くなったときは、何が決定済みで何が仮説かを整理する。
• 秘密情報、認証情報、顧客データを貼り付ける前に、組織の規程へ戻る。

終了時

• 変更ファイル、差分、テスト結果、未実行の検証、残課題を一覧にする。
• モデルの回答と人間の承認を別の記録として残す。
• Copilotの利用量・請求画面を確認する。未反映の利用量をゼロと解釈しない。
• 次の担当者が再現できるよう、採用した前提と戻し方を記録する。

そのまま使える5つのレビュー・画面チェック

以下は、CopilotでOpus 5.5を選択した後に、作業の品質と説明責任を確認するためのコピー用文面だ。いずれも特定のCLIフラグやAPI設定を要求しない。各文面は想定シナリオとして使い、実際の差分・画面・利用量と照合する。

想定シナリオ1：変更前の計画レビュー

複数ファイルを変更する前に、対象範囲と停止条件を明確にする。

想定シナリオ：既存リポジトリの複数ファイル変更を始める前のレビュー

次の作業について、実装を始める前に整理してください。
1. 変更対象のファイルと、変更しないファイル
2. 既存仕様から読み取った前提と、その根拠
3. 仕様が不足していて人に確認すべき点
4. 変更後に確認すべきテスト、差分、互換性
5. 途中で停止して承認を求める条件
不明な点は推測で埋めず、「未確認」と分けてください。

想定シナリオ2：差分の影響範囲レビュー

編集後に、要求された変更と偶発的な変更を分ける。

想定シナリオ：複数ファイルの差分をレビューする

この差分を、要求に直接必要な変更と、意図せず含まれた可能性がある変更に分けてください。
各項目について、対象ファイル、変更理由、既存機能への影響、追加確認が必要な点を示してください。
差分から確認できないことは断定せず、確認方法だけを提示してください。
最後に、レビュー担当者が承認前に読むべき順番を示してください。

想定シナリオ3：エラー復帰のレビュー

長時間の作業でエラーが出たとき、同じ操作を繰り返す前に仮説を整理する。

想定シナリオ：ツール実行またはテストが失敗した後の切り分け

失敗した操作、表示されたエラー、直前の変更を分けて整理してください。
原因候補を優先順位付きで示し、それぞれを確認するために必要な観測を挙げてください。
確認できていない原因を事実として扱わないでください。
破壊的な変更、秘密情報へのアクセス、仕様変更が必要になる場合は、そこで停止して人の承認を求めてください。

想定シナリオ4：長文脈の根拠レビュー

多くの資料を投入した後に、回答の根拠が本当に対象資料にあるか確認する。

想定シナリオ：複数の設計資料・議事録・コードを横断して回答を確認する

回答に使った根拠を、資料名またはファイル名と該当箇所に対応づけてください。
根拠が見つからない主張、資料同士で矛盾する主張、推測による補完を分けてください。
資料にない事実を追加せず、判断が必要な点は担当者への確認事項として列挙してください。
結論より先に、根拠の不足と矛盾を示してください。

想定シナリオ5：完了前の人間レビュー

マージや公開の直前に、モデルの説明ではなく成果物を点検する。

想定シナリオ：変更を人間が承認する前の最終チェック

次の順番で最終確認を支援してください。
1. 要求された変更がすべて差分にあるか
2. 要求されていない変更が混ざっていないか
3. テストや検証のうち、実行済みと未実行は何か
4. 互換性、セキュリティ、個人情報、公開範囲の懸念は何か
5. 人間の承認なしにマージまたは公開してはいけない理由
確認できない項目は「確認不能」と明記し、完了扱いにしないでください。

五つの文面は、Opus 5.5の能力を称賛するためのものではなく、長いコンテキストと長時間作業をレビュー可能にするためのものだ。会社の規程に合わせて対象ファイルや承認者を具体化する場合も、実際に存在する名称だけを加える。

導入時に起きやすい失敗パターン

失敗パターン1：対象プランだけで表示を断定する

失敗：Pro+、Max、Business、Enterpriseのどれかだから、全製品面で今すぐ使えると案内する。
改善：GitHubが段階展開と明記しているため、契約プラン、対象面、サインイン先、model policyを分けて確認する。未表示は未表示のまま記録し、対象外と断定しない。

失敗パターン2：Business／Enterpriseで利用者に再設定を繰り返させる

失敗：利用者のIDEだけを初期化し、組織のモデルポリシーを見ない。
改善：管理者がCopilot settingsのmodel policy、既定モデルの有効化、個別モデルの無効化を確認する。利用者の画面で解決できない権限の問題を、利用者の操作ミスにしない。

失敗パターン3：API価格をCopilot単価として掲載する

失敗：Anthropic APIの入力$4／MTok、出力$20／MTokを、そのままCopilotの一回あたり料金として説明する。
改善：API公開価格とCopilotのprovider list pricingによるusage-based billingを別欄に置く。Copilot内の単価が確認できない場合は「GitHubの契約・請求画面で確認」とし、数字を補わない。

失敗パターン4：1Mコンテキストへ資料を無制限に詰め込む

失敗：入る量が大きいからという理由だけで、関連性の低いログや資料まで投入する。
改善：対象範囲、資料の優先順位、根拠の出し方、情報持ち込みの可否を先に決める。長文脈は整理された入力を代替しない。

失敗パターン5：Opus 5.5の名前だけをAPI実装へ置換する

失敗：モデル名だけを変更し、thinking、強制ツール利用、thinking block、ツール間テキストの扱いを確認しない。
改善：API経路がある場合は公式Migration Guideの破壊的変更を項目ごとに照合し、テストとフォールバックを確認する。Copilotの画面利用者には、独自API設定の変更を求めない。

失敗パターン6：モデルの出力を承認の代わりにする

失敗：長い計画や自信のある説明を、差分・テスト・権限確認の代わりにする。
改善：変更ファイル、実行済み検証、未確認の懸念、承認者を分ける。契約・法務・公開・セキュリティの判断は担当者へ戻す。

よくある質問

Q1. Claude Opus 5.5はCopilot FreeやProでも使えますか？

GitHub Changelogが明示している対象プランはPro+、Max、Business、Enterpriseだ。FreeやProについて、この記事がOpus 5.5の利用可否を追加で断定することはしない。契約プランと現在のモデルピッカーを確認し、最新のGitHub公式Plans & pricingを参照する。

Q2. モデルピッカーに表示されないのは設定ミスですか？

必ずしもそうではない。GitHubは段階展開と説明しているため、対象プランでもまだ表示されない可能性がある。まず契約プラン、サインイン先、対象面、Business／Enterpriseのmodel policyを順番に確認し、問題がなければGitHubの案内を再確認する。

Q3. BusinessやEnterpriseの管理者は何を操作しますか？

GitHubの案内では、Copilot settingsのmodel policyでClaude Opus 5.5へのアクセスを管理する。既定モデルの有効化を組織としてどう扱うか、グローバル既定をオフにしていないか、個別モデルを無効にしていないかを確認する。画面のラベルは更新され得るため、現行UIで照合する。

Q4. APIの$4／$20をCopilotの料金として使えますか？

使えない。$4／MTokはAnthropic APIの入力価格、$20／MTokは出力価格としてPlatform Docsに掲載された公開価格だ。GitHub Copilotはprovider list pricingに基づくusage-based billingと説明されており、Copilot内の単価・換算をAPI価格から推測してはいけない。

Q5. 1Mコンテキストならリポジトリ全体を毎回渡せますか？

1Mトークンは公式仕様上のコンテキストウィンドウであり、何でも投入すべきという推奨ではない。関連資料を選び、機密情報の扱いを確認し、根拠が追える範囲で入力する。利用量や応答の実際の挙動は、Copilotの利用面とタスクによって確認する。

Q6. Adaptive thinkingをオフにできますか？

AnthropicのPlatform Docsでは、Opus 5.5のAdaptive thinkingは常時オンで、オフにできないと説明されている。深さを調整する仕組みとして既定effort mediumが記載されているが、Copilotの画面に同じ設定があるとは限らない。API実装なら公式Migration GuideとOverviewを確認する。

Q7. Opus 5から移行すると必ずコード変更が必要ですか？

Copilotのモデルピッカーで選択するだけの利用者と、Messages APIを直接呼び出す実装者を分ける必要がある。後者はモデルID、thinking、強制ツール利用、thinking block、ツール間テキストなどの破壊的変更を確認する。前者にAPIコードの変更を求める話ではない。

Q8. どんな作業から試すのが安全ですか？

人間が差分と結果を確認でき、停止条件を定めやすい作業から始める。複数ファイルの設計レビューやテスト追加の計画など、成果物と根拠を確認できる単位が向く。顧客データ、秘密情報、公開直前の変更を、検証なしで丸ごと委ねるのは避ける。

Q9. ウォーターマークで出力の品質や料金は変わりますか？

GitHubは、テキストのウォーターマークが意味・品質・可読性を変えず、トークンやコストも増やさないと説明している。これを超えて検出や権利関係の効果を推測せず、社内の公開・レビュー規程に沿って扱う。

まとめ：表示・課金・仕様を分けて確認する

Claude Opus 5.5のGitHub Copilot対応で、最初に覚えるべき答えは「Pro+、Max、Business、Enterpriseが公式の対象プラン」ということだ。ただし、利用開始の実務はそこでは終わらない。GitHubが列挙するモデルピッカーの面、段階展開、Business／Enterpriseのmodel policy、Copilotのusage-based billingをそれぞれ確認する必要がある。

料金は、GitHubのprovider list pricingによるCopilot内課金と、Anthropic APIの入力$4／MTok・出力$20／MTokを分ける。1Mトークン、128Kトークン、Adaptive thinking常時オン、既定effort medium、モデルID claude-opus-5-5はAnthropic Platform Docsの仕様だが、Copilotの画面や請求の表示をAPI仕様から推測する根拠にはならない。

大きなコンテキストと長時間エージェント作業は、計画、差分、テスト、承認の手順と組み合わせて初めて業務に使える。表示されないときは、対象外と決めつける前に、プラン、アカウント、対象面、組織ポリシー、段階展開を分けて確認する。この順番なら、利用者にも管理者にも、何を確認済みで何が未確認かを説明できる。

著者プロフィール

佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計約6万部）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

次の3アクション

1. 自分のCopilotプランと、利用したい製品面のモデルピッカーを確認する。
2. Business／Enterpriseなら、管理者にmodel policyと既定モデルの扱いを確認し、表示状態を記録する。
3. Copilotの利用量・請求とAnthropic APIの料金を別々に確認し、最初の作業は差分と検証結果を人間が読める範囲に限定する。

Uravationへのお問い合わせ・無料相談はこちら