よくある誤解：Opus 5.5を使いこなすには、「慎重に考えて」「ステップごとに考えて」といった文をプロンプトに足せばよい、という見方があります。Anthropicの公式ガイドが勧めているのは逆です。Opus 5.5は回答前に適応的思考を行うため、儀式的な思考指示を削り、代わりにタスク全体・観測できる完了条件・停止して人に確認する条件を先に渡します。
2026年10月5日時点の直答：Opus 5.5のClaude Code運用で重要なのは、プロンプトを長くすることではありません。完了の定義、承認境界、進捗を残すファイル、証拠付きレビューを一つの運用として設計することです。長時間動けるモデルだからこそ、「どこまで自走し、どこで止まるか」を明文化する価値が上がりました。
- 依頼時は「何をするか」だけでなく「何をもって完了とするか」を書く
- CLAUDE.mdには継続条件と停止条件を対で置き、権限設定は別に維持する
- 長い作業はタスクファイルへ残し、終了時は未決定・承認待ちを先に確認する
- 最初の導入検証は、外部副作用がなくテストで判定できる仕事から始める
Anthropicは2026年9月22日、Claude 5.5ファミリー最初のモデルとしてOpus 5.5を発表し、同日にAddy Osmani氏による「Getting the most out of Opus 5.5 in Claude and Claude Code」を公開しました。製品仕様やベンチマークだけではなく、長い実行をどう任せ、途中でどう方向修正し、最後に何を確認するかまで踏み込んだ実務ガイドです。
これは「優秀なモデルへ切り替えれば運用設計が不要になる」という話ではありません。むしろ、モデルが長く動けるほど、曖昧な完了条件や広すぎる権限の影響も大きくなります。ここでは公式情報だけを事実の土台にし、Claude Codeを使う日本の開発・AIエージェントチームが何を変えるべきかを整理します。
公開されたのは万能プロンプトではなく「長時間実行の作法」
公式ガイドの主題は、新しい呪文や特殊なプロンプト構文ではありません。最初のセッションで試すこととして示されたのは、タスク全体を渡す、完了状態と停止条件を書く、「think carefully」に相当する文を外す、終了後はClaudeが人に求めている判断を先に読む、という一連の仕事の渡し方です。
AnthropicのOpus 5.5発表は、長時間のエージェント型コーディングや複雑な知識労働を主要用途として挙げています。一方、Opus 5.5モデル概要では、適応的思考が常時有効で、思考の深さはeffortで調整する仕様が説明されています。つまり、旧来の保存済みプロンプトに「よく考えて」を積み重ねるより、タスクの境界と判定方法を更新する方が筋のよい対応です。
APIをOpus 5から移行する場合には互換性上の変更もあるため、Claude Codeの使い方だけでなく実装差分も確認してください。料金・モデルID・API変更点は、AIgent LabのClaude Opus 5.5 APIの変更点と移行手順で別に整理しています。
公式ガイドの7策を日本の現場向けに読み替える
| 公式ガイドの要点 | Claude Codeでの実践 | 企業運用で追加する観点 |
|---|---|---|
| タスク全体を渡す | 小分けの指示を何度も送らず、対象範囲を最初に示す | 対象外のディレクトリやシステムも明記する |
| 完了条件を定義する | テスト通過、旧実装の除去、差分確認などを列挙する | 完了報告ではなく証拠を受け入れ条件にする |
| 思考を促す定型句を削る | 簡単な質問は直接回答を求め、深さはeffortで調整する | 保存済みプロンプトと共通ルールを棚卸しする |
| 実行中に追加要件を渡す | 長い処理を最初からやり直さず、稼働中に補足する | 変更要求を記録し、当初の受け入れ条件も更新する |
| 停止条件を明文化する | 入力なしでは進めない時と破壊的操作の前だけ止める | 外部送信・本番変更・個人情報を承認対象に加える |
| 大きな仕事を分割する | 監査や移行をサブエージェントへ分け、親が根拠を確認する | 担当範囲を分離し、同じファイルの同時編集を避ける |
| 結果を検査する | 人間の前にレビューを行い、未確認事項も出させる | モデルの自己申告だけを完了証拠にしない |
ここで大切なのは、個々のテクニックをばらばらに導入しないことです。「完了条件だけ詳しいが、停止条件がない」「サブエージェントへ分けたが、親が証拠を確認しない」状態では、長時間実行の利点がそのまま運用リスクになります。
入口を変える：完了条件と停止条件を先に置く
公式ガイドは、タスク全体と「doneの状態」を一つのメッセージで示すよう勧めています。日本のチームで使うなら、対象範囲、完了条件、検証方法、停止条件、対象外をひとまとまりにすると、レビュー時にも意図を追いやすくなります。
次は、公式例の考え方を日本語の実務向けに組み替えた設定例です。特定のリポジトリや業務へそのまま適用せず、対象と承認者を置き換えてください。
タスク：決済クライアントの移行対象を洗い出し、対象範囲の実装を更新する。
完了条件：対象一覧が確定し、旧クライアント参照がなく、指定テストが通り、変更ファイル一覧を提示できる。
検証方法：検索結果、テスト結果、差分レビューの根拠を残す。
継続条件：既存コードとテストから判断できる作業は続行する。
停止条件：仕様の選択が必要、テスト失敗の原因を説明できない、削除・外部送信・本番変更が必要な場合は確認する。
対象外：リポジトリ外の設定、認証情報、請求設定には触れない。適用先：Claude Codeの最初の依頼。注意：本番環境で使用する前に、必ずテスト環境で動作確認してください。
「全部直して」のような目的だけの依頼では、モデルが合理的だと判断した範囲と、人間が意図した範囲がずれる余地があります。完了条件は成果物の名前ではなく、観測できる状態で書きます。「移行を完了する」ではなく、「対象一覧、旧参照ゼロ、テスト結果、変更差分がそろう」と表すのがポイントです。
長時間実行はCLAUDE.mdとタスクファイルで支える
Opus 5.5が長く仕事を続けられても、会話のスクロールだけで進捗を追うのは不安定です。公式ガイドは、CLAUDE.mdに「入力が不要なら進む」「続行不能または破壊的操作の前で止まる」といった短いルールを書き、長い作業のチェックリストをTASKS.mdのようなファイルへ残す方法を紹介しています。コンテキストが圧縮されても、ファイルに残した未完了項目は読み直せます。
入力がなくても安全に判断できる手順は、そのまま続ける。
途中報告だけで止まらず、次の実行と同じメッセージで状況を知らせる。
次の場合は停止して確認する。
・要件または優先順位の選択が必要
・削除、force push、リポジトリ外の変更が必要
・外部送信、本番反映、認証情報へのアクセスが必要
・テスト失敗の原因を根拠付きで説明できない適用先：プロジェクトのCLAUDE.md。注意：これはモデルへ渡す文脈であり、強制的なアクセス制御ではありません。Claude Codeの公式権限ドキュメントは、許可・確認・拒否のルールをClaude Code側で実施すると説明しています。停止ルールを書いたからといってpermission promptを外してはいけません。本番環境で使用する前に、必ずテスト環境で動作確認してください。
CLAUDE.mdやAGENTS.mdの読み込み範囲、優先関係を確認したい場合は、Claude CodeのAGENTS.md対応と設定も参照してください。運用ルールは長文化しすぎず、常に必要な内容だけを置き、個別作業の手順は依頼文や専用ファイルへ分ける方が保守しやすくなります。
大きな監査は分け、証拠を集めてから統合する
監査、移行、広いコードレビューでは、公式ガイドはサービスや領域ごとにサブエージェントへ分け、親エージェントが各報告の証拠を確認してから結果を統合する例を示しています。ここでの主役は「並列化」ではなく、「受け入れ前の確認」です。
企業で適用する際は、担当領域、利用できるツール、編集可能なパス、返却形式をサブエージェントごとに限定します。同じファイルを複数担当へ同時に編集させるより、調査担当は読み取り専用、実装担当は対象ファイルを限定、レビュー担当は初見で差分を確認、と役割を分ける方が衝突を減らせます。
公式のClaude Codeサブエージェント文書でも、サブエージェントは独立したコンテキストと個別のツール権限を持つ仕組みとして説明されています。したがって「分ければ正確になる」とは限りません。親へ戻す報告には、対象、判定、根拠ファイル、該当行、未確認範囲をそろえ、証拠がない断定を受理しない運用が必要です。
終了報告より先に「人間待ち」を読む
長い実行の最後に文章量が増えると、変更内容の要約から読み始めたくなります。公式ガイドは、まずClaudeがユーザーへ求めている判断や承認を確認し、その後に変更・発見事項を読むよう勧めています。最終報告の見出しをCLAUDE.mdで固定する方法も示されています。
終了時は次の順で報告する。
1. 人間の判断・承認が必要な項目
2. 実際に変更したファイルと理由
3. 実行した検証と結果
4. 確認できなかったこと、調べた場所
5. 残っている作業適用先：長時間実行の終了形式。注意：「テスト済み」「完了」と書かれていても、それ自体は検証結果ではありません。コマンド出力、差分、対象ファイル、再現手順など、受け手が追える証拠を確認してください。本番環境で使用する前に、必ずテスト環境で動作確認してください。
人間レビューの前段では、差分に対して「マージを止める問題だけ」「ファイルと行」「問題になる理由」「失敗を再現する方法」を出すレビューを依頼できます。さらに、調査系タスクには「確認できなかったことと、どこを探したか」を必須にすると、もっともらしい空白を見逃しにくくなります。
日本企業では自律性より先に承認境界を決める
Opus 5.5の価値を「人が見なくても長く動くこと」だけで評価すると、導入判断を誤ります。企業では、動かしてよい範囲と、人間の確認なしでは実行してはいけない範囲を先に分ける必要があります。典型的には、ファイルの読み取り、テスト、静的解析は自動実行の候補になります。一方、データ削除、force push、外部への送信、公開、決済、本番反映、認証情報の利用は承認対象です。
もう一つ見落としやすいのが、セーフガードによるモデル切り替えです。公式ガイドによると、フラグされたメッセージの多くは旧モデルへ切り替わり、Claude appsやClaude Codeの作業はそのモデルで継続します。Claude Codeではモデル通知を確認し、必要に応じて/modelで選択し直し、設定は/config、誤判定の報告は/feedbackを使います。会話中のファイルや検索結果も判定対象になり得るため、最後の入力だけを見て原因を決めつけないことが重要です。
社内の検証票には、開始時に選んだモデルだけでなく、終了時の実モデル、effort、権限モード、停止・承認の発生、変更範囲、テスト結果、未確認事項を残すとよいでしょう。これはAnthropicの定型様式ではなく、公式ガイドの確認項目を企業運用へ落とし込んだ構成例です。
導入は5段階の小さな検証から始める
最初から横断的なリポジトリ移行や本番運用を任せる必要はありません。公式の「明確なfinish line」「危険な操作の前で停止」「結果をレビューする」という考え方から逆算すると、最初の検証には、外部副作用がなく、結果をテストで判定でき、失敗しても元へ戻しやすい仕事が向いています。
- 代表タスクを選ぶ：実業務に近いが、本番や外部サービスへ変更を出さないタスクを一つ選びます。
- 受け入れ条件を先に作る：対象範囲、通すテスト、変更禁止範囲、必要な証拠を人間が定義します。
- 運用契約を渡す：完了条件、継続条件、停止条件を依頼文とCLAUDE.mdへ分けて記載します。
- 実行と別に検査する：変更を行うセッションとは別の視点で差分レビューをかけ、人間が最終判断します。
- 差分を比較する：作業時間だけでなく、修正回数、レビューで見つかった問題、未確認事項、承認回数を記録します。
| 記録項目 | 見るポイント | 合格の考え方 |
|---|---|---|
| 完了条件 | 開始前に観測可能な形で定義できたか | 実行後の自己申告ではなく、事前条件で判定できる |
| 変更範囲 | 対象外へ触れていないか | 差分一覧と指定範囲が一致する |
| 検証証拠 | テスト、静的解析、再現手順が残っているか | 第三者が結果を追える |
| 人間レビュー | 保守性、セキュリティ、要件適合を確認したか | マージ判断と指摘が記録されている |
| 未確認事項 | 確認不能を隠していないか | 調べた場所と残る不確実性が分かる |
effortは高ければ常に得、とは限りません。Opus 5.5公式プロンプトガイドは、既定のmediumから始め、自社の評価セットで他の水準と比較するよう案内しています。品質差を測れないまま高いeffortへ固定するのではなく、タスク別に必要性を確認してください。
速さは使い分ける：対話と無人実行を同じ設定にしない
Fast modeは別モデルではなく、同じOpusを低遅延で返すための構成です。Claude CodeのFast mode公式文書では研究プレビューとされ、対話的な反復やライブデバッグに向く一方、標準モードより単価が高く、長い自律タスクやコスト重視の処理には標準モードが向くと説明されています。Claude Codeでは/fastで切り替えます。
2026年9月28日には、AnthropicがSonnet 5.5をOpus 5.5の高速・低コストな補完モデルとして公開したこともClaude公式リリースノートで確認できます。したがって、全タスクを一律にOpus 5.5へ寄せるより、複雑な長時間作業、対話的な修正、定型処理を分け、自社の品質基準とコスト条件でルーティングを決める方が現実的です。
モデル選択やAuto-Compactを含む設定の確認には、Claude Code /config完全ガイドが役立ちます。特に長いセッションでは、モデル名、fast mode、effort、コンテキスト圧縮の有無を結果と一緒に残してください。
つまずきやすい3つの運用と修正
失敗1：自走させるために承認を全部外す
❌ CLAUDE.mdに「止まらず最後まで進める」とだけ書き、削除や外部変更の確認まで外す。
⭕ 入力不要な作業は続ける一方、不可逆操作・外部副作用・権限外の変更は停止条件にし、Claude Code側のpermission ruleも維持する。
なぜ重要か：モデルへの指示と、ツールが実際に許可する操作は別物です。自律性を上げる変更と安全装置を外す変更を混同しないでください。
失敗2：完了報告をそのまま完了証拠にする
❌ 「テストは通りました」「移行は完了しました」という最終文だけで受け入れる。
⭕ テスト出力、差分、旧参照の検索結果、未確認事項をそろえ、別のレビューと人間確認を通す。
なぜ重要か：説明が明快になることと、結果が正しいことは同義ではありません。長時間実行では、最後の要約から元の作業へ追跡できることが重要です。
失敗3：大きな仕事を分割しただけで安心する
❌ サブエージェントの報告を集め、そのまま一つの結論として提出する。
⭕ 各担当の対象範囲と証拠を親が検査し、重複・未調査・矛盾を解消してから統合する。
なぜ重要か：並列化は調査量を増やしますが、判定の正しさを自動的に保証しません。証拠を受け入れる責任は統合側に残ります。
コミュニティの反応が示す期待と警戒
Hacker Newsの該当スレッドは、2026年10月5日の確認時点で231 points、155 commentsでした。数値は変動するため、モデル評価の根拠ではなく、議論の広がりを示す取得時点のスナップショットとして扱う必要があります。
肯定的な投稿では、長時間のCI改善を任せ、多数の変更案を得たという体験が共有されました。一方、その直後には「速くなっても保守しにくい構成になっていないか」という反論があり、高レベルの目標だけでは過剰設計やセキュリティ上の懸念が残ったという別の体験も出ています。これらは利用者の自己申告であり、再現性を確認した性能データではありません。
それでも、実務上の示唆は公式ガイドと重なります。測定できるゴールでは長時間実行を任せやすい一方、評価基準が曖昧な設計判断では人間の誘導とレビューが多く必要です。Opus 5.5の自律性が高まったから監督を減らすのではなく、監督を「逐次指示」から「事前の境界設計と事後の証拠確認」へ移す、と捉える方が適切です。
よくある質問
Opus 5.5にも「慎重に考えて」と書くべきですか？
公式ガイドは、その種の定型句をプロンプトや保存済み指示から外すよう勧めています。Opus 5.5では適応的思考が常時有効です。簡単な回答が必要なら直接答えるよう依頼し、思考の深さはeffortで調整します。
CLAUDE.mdに停止条件を書けば危険な操作を防げますか？
それだけでは不十分です。CLAUDE.mdはモデルが参照する指示で、アクセス制御そのものではありません。削除、外部送信、本番変更などはClaude Codeのpermission rule、権限モード、必要に応じたhookでも制御してください。
サブエージェントは常に使った方がよいですか？
いいえ。大規模監査や複数領域の移行など、独立して分けられる仕事に向きます。小さな修正まで分割すると、受け渡しと統合の負担が増えます。使う場合も、親が各結果の根拠を確認する工程を省かないでください。
Fast modeは長い自律タスクにも向きますか？
公式文書では、Fast modeは人が各応答を見ながら進める対話的な作業向けです。長い自律タスクやコストを重視する処理には標準モードが適しています。研究プレビューのため、利用条件は実行前に公式文書で再確認してください。
セッション中に別モデルへ切り替わったか確認できますか？
フラグされたメッセージでは、旧モデルへの切り替え通知が表示される場合があります。Claude Codeでは通知と/modelを確認し、必要に応じて選択し直します。実務の検証記録には開始時だけでなく終了時のモデル状態も残してください。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Getting the most out of Opus 5.5 in Claude and Claude Code — Anthropic / claude.dev、2026年9月22日公開（参照日：2026年10月5日）
- Introducing Claude Opus 5.5 — Anthropic、2026年9月22日公開（参照日：2026年10月5日）
- Claude Opus 5.5 model overview — Anthropic公式ドキュメント（参照日：2026年10月5日）
- Prompting Claude Opus 5.5 — Anthropic公式ドキュメント（参照日：2026年10月5日）
- How Claude remembers your project — Claude Code公式ドキュメント（参照日：2026年10月5日）
- Configure permissions — Claude Code公式ドキュメント（参照日：2026年10月5日）
- Speed up responses with fast mode — Claude Code公式ドキュメント（参照日：2026年10月5日）
- Claude release notes — Anthropic公式ヘルプ（参照日：2026年10月5日）
- Getting the most out of Opus 5.5 in Claude and Claude Code — Hacker News。コミュニティ反応の確認にのみ使用（参照日：2026年10月5日）
要点の整理
Opus 5.5の使いこなしは、長いプロンプトを書く技術ではなく、仕事の受け渡しを検証可能にする技術です。タスク全体と完了条件を先に示し、CLAUDE.mdで継続と停止の境界を決め、タスクファイルに進捗を残し、最後は証拠付きレビューで受け入れます。
まずは、外部副作用がなく、テストで成功を判定できる一つの仕事を選んでください。そこで「完了条件」「停止条件」「未確認事項」「人間レビュー」を記録できれば、次に広げるべき仕事と、まだ人が握るべき判断が見えてきます。
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
この記事はAIgent Lab編集部がお届けしました。
