Claude Opus 5.5 実践活用ガイド：タスク指示から成果物の検収まで

Claudeを大規模なコード修正や複雑なタスクに利用する際、作業を細切れに分割し、何度も「続けていいですか？」と確認したり、「深く考えて」と念押ししたりする使い方が定着していました。本来は脱線を防ぐための工夫でしたが、自律的な連続実行力が向上したOpus 5.5では、かえってスムーズに進むはずの作業を分断してしまう原因になります。

Anthropicの公式ガイドでは、旧世代からの変化として次の3点が挙げられています。Opus 5.5は複数ステップにおよぶ長時間タスクを旧世代より進めやすくなったこと、回答ごとに必要な思考量をモデル自身が判断すること、そして完了時に「何を行い、何を発見し、人間に何を求めているか」をより明確に整理して報告するようになったことです。そのため、ステップごとに細かく指示を出すよりも、開始時にタスクの全体像、完了の定義、中断すべき条件を明確に伝え、実行中に必要な追加要件を補足し、終了時に証拠と成果物を検証するアプローチが効果的です。

ただし、「自律的に任せる」ことには明確な境界線があります。データの削除、強制プッシュ（force-push）、リポジトリ外のファイル変更など、取り返しのつかない操作については、中断ルールや手動での承認プロセスを維持する必要があります。また、モデルが完了を報告した場合でも、テスト結果やコードの変更点、未確認事項のチェックは欠かせません。

Opus 5.5の基本性能や価格設定については解説記事をご参照ください。本稿では、実務タスクで最大限の成果を引き出すための具体的な運用手順を解説します。

あわせて読みたい Opus 5.5 を知る：性能、使用例、料金 公開時の解説では、コーディング、画像理解、文章作成での実力と、性能とコストの関係を整理しています。モデルを把握してから、このガイドの手順を試せます。 モデル紹介を読む →

1. コアマインドセットと初回利用時に試すべき3つのこと

Opus 5.5を使いこなすための最大のポイントは、小手先のプロンプト技術を増やすことではなく、非効率な人間側の介入を減らすことにあります。最初のセッションでは、Anthropicが推奨する以下の3つをまず試してみてください。

1. タスク全体を一括で渡し、ゴールを明確にする：1つのメッセージ内でタスクの全体目標、何をもって完了とするかの基準、どういう状況で作業を止めて人間に尋ねるべきかを明示し、あとは自律的に実行させます。
2. 「深く考えて」などのプロンプトを削除する：Opus 5.5は各回答の前に自動で深い思考プロセスを実行し、必要な計算量を自身で判断します。手動で思考を促す指示を追加する必要はありません。
3. 長時間のタスク終了時は、まず「自分に求められている判断」を確認する：実行が終わったら、ログを漫然と読むのではなく、モデルが提示している判断事項やブロッカー（作業停止要因）をまず確認します。確認待ちの項目がないことを確かめてから、変更内容の要約を精読します。

2. プロンプトの設計：全体像の伝達と制約条件の指定

タスクを開始する際は、従来の対話スタイルをアップデートする必要があります。Anthropicの説明によると、Opus 5.5の旧世代モデルに対する最大の強みは、大規模コードベースにおけるエンドツーエンドのリファクタリングからテスト通過までといった、複数ステップにわたる複雑なエンジニアリング作業にあります。

1. 「全体像」「完了基準」「中断条件」を一度に伝える

• アクション：タスク全体を1つのプロンプトにまとめ、一度に指示します。何をもって「完了（Finish line）」とするのか、どのような状況で中断して人間に質問すべきかを明確に定めます。
• 効果的な理由：初期テスターからのフィードバックによると、Opus 5.5は人間の介入が少ない状態でも、プログラミングタスクを数時間にわたって継続実行できます。明確なゴールが設定されていれば、目標達成まで自律的にデバッグを繰り返します。また、完了基準が具体的であれば、人間側も作業後に正しく完了したかを確実に検証できます。
• 実践例（Claude Code向け）：

Migrate the payment endpoints from the old client to the new one.
Done means: every endpoint uses the new client, the old client is
deleted, and the test suite passes.
Stop and ask me only if a test fails for a reason you can't explain.

構造の解説：

1. 全体のタスク：決済エンドポイントを旧クライアントから新クライアントへ移行する。
2. 完了基準（Done means）：すべてのエンドポイントが新クライアントを利用していること、旧クライアントのコードが完全に削除されていること、テストスイートがすべてパスすること。
3. 中断条件（Stop and ask）：テストが失敗し、かつその原因が説明できない場合に限って作業を止めて質問する。

この3つの完了基準は、それぞれ個別に検証可能な成果物に対応しています。エンドポイントごとに新クライアントへの切り替えを確認し、リポジトリ内に旧クライアントが残っていないことを確認し、最後にテストスイートの実行結果をチェックします。テストが失敗し原因が特定できない場合、モデルは「コードを修正した」と勝手に完了扱いにするのではなく、失敗の状況と調査した手がかりを人間に提示して判断を仰ぐ必要があります。

図A：1つのプロンプトでタスク全体、完了基準、中断条件を明示する（Anthropic公式サンプル）

2. 「深く考えて」（think hard / think step by step）を完全に削除する

• アクション：プロンプト、システムプロンプト、プロジェクト設定などから、think carefully（慎重に考えて）や think step by step（ステップバイステップで考えて）といった記述をすべて削除します。
• 効果的な理由：Opus 5.5は思考プロセスが組み込まれており、回答生成前に必要な思考の深さを自動で判断します。Anthropicのチャットプロダクトにおける検証では、「think carefully」の指示を削除したところ、品質の明確な低下を招くことなく回答の開始が早くなった事例が報告されています。ただし、これは特定のテストに基づく観察結果であり、あらゆるタスクで一律に高速化することを保証するものではありません。
• 思考量の制御方法：
  • 単純な質問に手短に答えてほしい場合は、プロンプトに Answer directly（端的に回答して）と直接指示します。
  • Claude Codeターミナルでは、全体の思考深度を調整したい場合、システムの effort（計算リソースの投入度）パラメータを設定して制御できます。

3. 実行中の追加指示はEnterキーでそのまま送信する

• アクション：ターミナルでタスクが実行開始された後に追加の制約や考慮事項を思い出した場合、実行を中断して最初からやり直す必要はありません。ターミナルにそのまま追加の指示を入力してEnterキーを押します。
• 効果的な理由：Opus 5.5による長時間のタスクはやり直しのコストが高くなります。Claude Codeは、モデルが作業を行っている最中でも追加のメッセージを受け付けられるように設計されています。
• 実践例：モデルが作業を継続している最中に直接入力します：Also keep the old endpoint names as aliases.（これまでの古いエンドポイント名もエイリアスとして残してください）。

4. デザイン系タスク：「使ってほしくないスタイルの除外リスト」を指定する

• アクション：Webページ、フロントエンドUI、Artifactなどのデザイン生成を依頼する際は、避けてほしい具体的なデザインパターンや視覚的要素をリストアップします。
• 効果的な理由：デザインに関する明確な指針がない場合、Opus 5.5はありがちなデフォルトのスタイルに偏りがちです。「平凡なデザインを避けて」「一般的な見た目にしないで」といった抽象的な指示を出しても、別のデフォルトスタイルに切り替わるだけに終わることが多いため、具体的なネガティブリスト（禁止リスト）を渡すほうが確実です。
• 実践例：

Build a personal website with placeholder content.
Don't use a cream or off-white background, italic accent words in
headings, numbered "01 / 02 / 03" section labels, monospace labels, or
pill-shaped buttons.

指示の意味：「ダミーコンテンツを含む個人個人用Webサイトを作成してください。クリーム色やオフホワイトの背景、見出し内の斜体による強調、"01 / 02 / 03" のようなセクション番号表記、等幅フォントのラベル、カプセル型の角丸ボタンは使用しないでください。」

• フォローアップ：出力された代替スタイルを確認します。まだ意図と異なる要素が残っている場合は、新たに現れた好ましくない特徴を除外リストに追加して再生成させます。

3. Claude Code での長時間タスク運用

ターミナルツールのClaude Codeでは、長時間のタスクを実行すると進捗の報告が過剰になったり、重要な操作の手前で判断に迷って止まったりすることがあります。あらかじめ明確なルールと権限設定を行っておくことで、安定した自律実行が可能になります。

1. CLAUDE.md の設定：自律推進と中断の境界線を定義する

用語解説：CLAUDE.md はClaude Codeが参照できるプロジェクト指示ファイルであり、リポジトリ全体に適用したいコーディング規約や作業ルールを記載するのに適しています。

• アクション：プロジェクトの CLAUDE.md に簡潔なルールを記述し、どのような場合に自律的に次のステップへ進み、どのような場合に必ず作業を止めて人間に確認すべきかを定義します。
• 効果的な理由：Opus 5.5は長時間の作業中、ユーザーに進捗を共有しようとする傾向があります。ルールが設定されていないと、「次の作業内容だけを報告して止まる」「続けていいか尋ねてくる」「作業を止める必要のない選択肢を提示する」といった不要な中断が発生します。停止条件を明文化することで、スムーズな進行を維持できます。
• 推奨設定コード（プロジェクトルートの CLAUDE.md に配置）：

When a step doesn't need my input, keep going. Put status notes in the
same message as your next action.
Stop and ask only when you can't continue without me, or before anything
destructive: deleting data, force-pushing, or changing anything outside
this repository.

ルールの解説：

• 自律推進（Keep going）：人間の入力が不要なステップであれば、そのまま次のアクションを実行する。現在の進捗ステータスは、次のアクションと同じメッセージ内にまとめて出力する。
• 一時停止と確認（Stop and ask）：人間の判断なしでは進められない場合、または破壊的な操作（データの削除、Gitの force-push、リポジトリ外のファイル変更）を行う直前に限って作業を一時停止し、確認を求める。

図B：CLAUDE.md のルール定義：自律推進と一時停止の基準

• 中断と権限に関する注意点：
  • タスクが途中で Want me to continue?（作業を続けますか？）と尋ねてきた場合は、単に continue と返答すれば進みます。この確認が頻発する場合は、上記のルールが設定されていないか、指示が十分に反映されていない可能性があります。
  • モデルに自律権を与える場合でも、破壊的コマンドに対するターミナルの手動承認プロンプト（Permission prompts）は必ず有効にしておく必要があります。リスクの高い操作を実行前に人間が承認できる状態を維持してください。
  • ペアプログラミング向けのバリエーション：密に確認を取りながら進めたい場合は、CLAUDE.md に「作業開始前に1行で計画を提示し、完了後に簡潔なまとめを提示する」といった対話スタイルを指定することも可能です。Opus 5.5はそのような運用スタイルにも柔軟に適応します。

2. 大規模な調査・リファクタリング：サブエージェント（Subagents）の並列実行と厳格な証拠確認

• アクション：広範なコードベースにわたる監査、移行、コードレビューを行う際は、Opus 5.5に複数の並列サブエージェントを立ち上げさせ、メインモデルが全体の集約と証拠の検証を担当するように指示します。
• 背景と仕組み：初期テスターの運用例として、長時間のコード監査や移行タスクにおいて、Opus 5.5自身に並列サブエージェントを統括させる手法があります。メインエージェントがタスクを分割・割り振り、各サブエージェントが担当するサブディレクトリや個別サービスを自律的に調査します。

Audit every service in services/ for the retry bug in the linked issue.
Give each service to its own subagent. When a subagent reports back,
check its evidence before you accept it.
Finish with one table: service, affected yes or no, and the evidence.

指示の意味：「関連イシューに記載されているリトライ処理のバグについて、services/ 配下の全サービスを監査してください。各サービスを独立したサブエージェントに割り振って調査させてください。サブエージェントから報告が上がってきたら、提示された根拠コードを検証した上で承認してください。最終結果は、サービス名、影響の有無（yes/no）、具体的な証拠コードの3列のテーブル形式で1つにまとめて出力してください。」

図C：サブエージェントへタスクを分散し、メインエージェントが証拠を検証して集約する（図中の4つのサブエージェントは例示）

3. タスクリストを独立したファイルに保存し、コンテキスト圧縮から保護する

• アクション：長時間の実行が予想されるタスクでは、進捗チェックリストをローカルファイル（TASKS.md など）に書き出して更新させます。進捗を確認したいときは、ターミナルのログを遡るのではなく、そのファイルを直接確認します。
• 効果的な理由：

  仕組みの解説（コンテキストウィンドウの圧縮）：長時間のタスクを実行すると、大量のターミナル出力やコード検索ログによってコンテキストウィンドウ（Context Window）が圧迫されます。容量がいっぱいになると、Claude Codeは古い対話履歴を自動的に要約・圧縮します。ターミナル上の出力だけに頼っていると、要約時に細かなToDoが抜け落ちてしまうリスクがありますが、ローカルディスク上のファイルに保存されたチェックリストは圧縮の影響を受けずに残ります。これにより、人間もモデルも常に残タスクを正確に把握できます。

• 実践プロンプト：Keep a checklist in TASKS.md. Tick each item when it’s done, and add anything new you find.（TASKS.md にチェックリストを維持し、完了した項目にチェックを入れ、新しく発見したタスクがあれば随時追記してください）。

4. 成果物の検収とレビュー：ブロッカーの確認からコード・分析の精査まで

長時間のタスクが完了した際、膨大な実行ログを最初からすべて読み通す必要はありません。以下の手順で効率的に結果を検収できます。

1. まず「自分の判断が必要な事項」（Blocked on me）を確認する

• アクション：作業完了報告が表示されたら、まずモデルが人間の判断を待っている項目（技術的な選択肢の決定や、アーキテクチャ変更の承認など）がないかを最優先で確認します。ブロックされている項目がないことを確かめてから、変更内容の本文を読み進めます。
• 効果的な理由：Opus 5.5の特徴の一つとして、平易で簡潔な言葉（Plain language）で報告を行う傾向があります。作業まとめでは「何を行ったか」「何を発見したか」「人間に何を求めているか」が明確に区別されて提示されます。
• フォーマットの固定化テクニック：プロジェクトの CLAUDE.md で報告フォーマットを指定しておくことも有効です。例えば次のように設定します：End every run with three headings: Blocked on me, Changed, Found.（各実行の最後には、必ず「Blocked on me（確認待ちのブロッカー）」「Changed（変更内容）」「Found（新発見・気づき）」の3つの見出しで出力すること）。

2. 人間によるレビューの前に、Diff / PR をモデル自身にセルフレビューさせる

• アクション：チームメンバーにコードレビューを依頼する前に、Opus 5.5に対して現在のブランチの差分（Diff）やPull Requestを対象とした重点的な事前レビューを実行させます。
• テスターのフィードバックとメリット：

  テスターの評価：初期テスターの報告によると、Opus 5.5は最も低い計算リソース設定（lowest effort）であっても、最高設定にした旧世代のOpus 5より多くのバグを発見し、誤検知（フォールスポジティブ）も少なかったとされています。また、平易で自然な文章を生成するため、作成されるPRの説明文も人間が読みやすいものになります。

• 実践プロンプト：

Review the diff on this branch against main.
List only problems you'd block the merge for. For each one, give the
file and line, why it's wrong, and how to show it fails.

指示の意味：「このブランチの main に対する差分（diff）をレビューしてください。マージをブロックすべき重大な問題点のみをリストアップしてください。該当する問題ごとに、対象ファイル名と行番号、何が問題であるか、そしてそのバグを再現・確認する方法を明記してください。」

3. 分析・調査タスク：「見つからなかった情報 / 確認できなかった点」の明記を義務付ける

• アクション：コードの技術調査、市場分析、技術選定などを依頼する際は、調査しても判明しなかった盲点を明記するよう指示します。
• 効果的な理由：エンジニアリングや研究の現場では、「何が見つからなかったか」「何が裏付けられなかったか」が明記されていなければ、どの結論を慎重に扱うべきか判断できません。
• 共通の追加指示：プロンプトの末尾に次の一文を付け加えます：Mark anything you couldn't confirm, and say where you looked.（確認できなかった事項があればその旨を明示し、どこを探したかも併せて記載してください）。この指定はClaudeのリサーチレポート作成でもClaude Codeの調査でも同様に有効です。

5. Claude アプリでの日常業務の進め方

Web版やデスクトップ版のClaudeアプリを利用する際は、まずモデルセレクターで確実にOpus 5.5が選択されていることを確認してください。

1. 図表やUI：書き起こさずスクリーンショットをそのまま添付する

• アクション：アーキテクチャ図、フローチャート、データダッシュボード、カレンダーのキャプチャなどは、文字で説明したり数値を書き写したりせず、画像を直接アップロードします。
• 効果的な理由：Anthropicの説明によると、Opus 5.5は図表やフローチャート、スクリーンショットの認識精度がOpus 5よりも向上しており、特別な前処理なしでそのまま読み取れます。また、矢印がどのボックスを結んでいるか、2つのフロー図間で何が変わったか、カレンダー上で予定がいつ始まっていつ終わるかといった、ダイアグラム内の空間的な位置関係も正確に把握します。
• 質問例：画像を添付した上で直接質問します：Which of these services call the billing API directly?（これらのサービスのうち、billing APIを直接呼び出しているのはどれですか？）。

2. 長文ドキュメントや計画書：記述の自己矛盾を検出させる

• アクション：長大なプロジェクト計画書、評価レポート、スライド資料などを読み込ませ、文中における自己矛盾の検出を指示します。
• 効果的な理由：Opus 5.5は細部への着眼力が高くなっています。Anthropicの社内テストでは、長文の計画案から日付と曜日の不一致を発見したり、プレゼン資料内で図表の数字と本文の説明の食い違いを捉えたりした事例が紹介されています。
• 実践プロンプト：Check this deck for anything that contradicts itself: numbers, dates and names. Quote each problem and say where it is.（このスライド資料内で、数字、日付、名称などに自己矛盾がないかチェックしてください。問題箇所を引用し、どこにあるかを明記してください。）

3. 粗いアウトラインではなく、完成された成果物ファイルの出力を求める

• アクション：データレポート、スケジュール表、ドキュメントなどが必要な場合は、概要や骨子だけでなく、そのままエクスポートして使える完成形式のスプレッドシートやドキュメントを直接要求します。
• 効果的な理由：Anthropicによると、Opus 5.5が生成するスプレッドシートや文書は、外部に共有する前に人間が手直ししなければならない箇所がOpus 5と比べて少なくなっています（ただし、用途に応じた最終確認は推奨されます）。
• 実践例：Make this a spreadsheet I can share: one row per vendor, with columns for cost, contract end date and owner.（共有可能なスプレッドシート形式にしてください。1ベンダーにつき1行とし、費用、契約終了日、担当者の列を含めてください）。

4. 長い対話で回答が遅くなった場合：プロジェクト指示で「回答済みの内容は確定とみなす」と宣言する

• 発生する事象：長いセッションの途中で短い質問を追加した際、モデルの思考時間が不自然に長引くことがあります。公式の説明では、短い質問を処理する過程で、過去の回答を最初から見直しにいってしまうことが一因とされています。
• 解決策：プロジェクトのカスタム指示（Project instructions）に次の宣言を追加します。

Once you have answered something, treat that answer as done. Focus on
what I'm asking now, and don't go back over an earlier answer unless I
ask about it or point out a problem with it.

指示の意味：「一度回答した内容については確定事項として扱ってください。現在尋ねている内容に集中し、私が以前の回答について質問したり問題を指摘したりしない限り、過去の回答を再検討しないでください。」

• 例外事項：長大な一連の複合分析やリサーチタスクでは、このルールを設定しないでください。深い考察を要する作業では、後続のステップで前のステップの偏りや誤りを動的に修正する必要があるためです。

6. セーフティフラグの対処と速度の調整

Anthropicの説明によれば、Opus 5.5はリリース当初からFableレベルのバイオ・サイバーセキュリティ保護ポリシーを搭載した最初のOpusモデルです。高い水準でリスクを防ぐ一方で、日常的な正当な開発作業が誤ってセーフティフィルターに検知（フラグ付け）されてしまうケースもあります。その仕組みを理解しておくことで、作業の中断を回避できます。

1. 切り替えの仕組み：フラグが検知されるとどうなるか？

• 発生する事象：ClaudeアプリおよびClaude Codeでは、メッセージがセーフティフラグに該当すると判定された場合、多くのケースでは旧世代の別モデルに自動で切り替わり、処理が継続されます。
• 許可される範囲と誤検知：
  • 明確に許可されているタスク：ソースコード内のセキュリティ脆弱性の探索などは正当な作業として明確に許可されています。
  • 一般的な問い合わせ：健康や教育に関する一般的な日常の質問も通常どおり利用可能です。
  • 誤検知とチューニング：公式の説明によると、現在のセーフティ機構は正当な開発操作を誤検知してしまう場合があり、誤判定を減らすための継続的な改善が行われています。

2. モデルが切り替わった場合の対処法

Claude アプリ（Web版 / デスクトップ版）：

• 画面表示：回答の冒頭に Switched to...（……に切り替わりました）という通知が表示されます。この回答は旧モデルによって生成されており、以降の対話もデフォルトでその旧モデルに留まります。
• 対処手順：
  1. モデルを戻す：画面上部のモデルセレクターを手動でクリックし、Opus 5.5を再選択します。注意点：セーフティチェックは過去の会話履歴全体、アップロードされたファイル、検索結果を含めてスキャンします。フラグの原因となった内容が履歴に残っていると再発しやすいため、新しい会話（New chat）を開始するのが確実です。
  2. 自動切り替えを無効化する：勝手にモデルを切り替えられるのを防ぎ、検知時に自分で判断したい場合は、Settings（設定）→ Capabilities（機能）→ Switch models when a message is flagged（メッセージがフラグされたときにモデルを切り替える）をオフにします。オフにしておくと、フラグ検知時に選択肢が記載されたダイアログが表示されて一時停止します。

Claude Code（ターミナル環境）：

• 画面表示：ターミナル上に旧モデルへ切り替わった旨の通知が表示され、そのモデルでセッションが継続されます。
• 対処手順：
  1. /model コマンドを実行し、手動でOpus 5.5に戻します。
  2. Esc キーを素早く2回押す（Esc Esc）と、直前に送信したメッセージを呼び出して編集・再送信できます。
  3. /config コマンドを使用して、フラグ検知時にモデルを自動で切り替えるかどうかの設定を変更できます。
  4. 通常のコード操作に対する誤検知であることが明らかな場合は、/feedback コマンドを実行してフィードバックを送信できます。

3. 回答内で内部の推論プロセスをそのまま再現させない

• アクション：プロンプト、システムプロンプト、プロジェクト指示から、「内部の思考・推論プロセスを回答内で完全に出力・再現させる（reproduce internal reasoning in the reply）」といった要求を削除します。
• 理由：内部推論の出力を求めるリクエストはセーフティフラグの対象となりやすく、モデルから回答を拒否される要因になります。
• 代替の質問方法：判断の理由を知りたい場合は、要約した説明を求めます。例：Explain why you chose this approach in three sentences.（このアプローチを選択した理由を3文で簡潔に説明してください）。

4. 高速な対話レスポンス：必要に応じて Fast モードを利用する

• 適した利用シーン：Claude Codeで頻繁にやり取りを行い、1回ごとの返答をすぐに確認して次の指示を出したい場合は、Fastモード（Fast Mode）の利用を検討してください。
• 技術的背景とコスト：FastモードはResearch Preview（研究プレビュー）として提供されています。実行されているのは同一のフルサイズOpus 5.5モデルですが、レスポンスの生成速度が向上します。ただし、利用にはアカウント側で追加使用枠（extra usage）の有効化が必要であり、トークンあたりの単価も通常モードより高額になります。
• 有効化の方法：Claude Codeターミナルで /fast と入力することでオン/オフを切り替えられます。

全プロセスセルフチェックリスト

長時間の開発や複雑なタスクを開始する前に、以下のチェックリストで準備状況を確認してください。

図D：Opus 5.5 導入・実行全プロセスチェックリスト

1. プロンプト作成と準備（Asking）

• [ ] プロンプトに明確な「完了基準（Done means...）」が含まれているか？
• [ ] プロンプトや共通設定から "think hard" や "step by step" などの不要な文言を完全に削除したか？
• [ ] デザインやフロントエンド関連の依頼で、具体的な「使ってほしくないスタイルの除外リスト」を指定したか？
• [ ] 図表、フローチャート、カレンダーなどの情報について、手打ち入力ではなく元のスクリーンショットを直接添付したか？

2. Claude Code での長時間タスク実行（Long runs in Claude Code）

• [ ] CLAUDE.md に「自律して進める条件」と「破壊的変更の前に必ず停止して確認する条件」を設定したか？
• [ ] 破壊的コマンドに対する手動承認プロンプト（Permission prompts）が有効になっているか？
• [ ] 大規模なコード監査や移行において、並列サブエージェント（Subagents）へのタスク分割を指示したか？
• [ ] 進捗チェックリストをローカルファイル（TASKS.md など）に保存して更新するよう指示したか？

3. 成果物の検収とレビュー（Checking）

• [ ] タスク完了後、レポート内の「人間の判断待ち（Blocked on me）」の項目を最優先で確認したか？
• [ ] 人間によるレビューの前に、Diff / PR の不具合をモデル自身にセルフレビューさせたか？
• [ ] 調査・分析タスクにおいて、「確認できなかった点」「見つからなかった情報」の明記を指示したか？

4. セーフティフラグへの対応と復旧（Flags）

• [ ] モデルが切り替わった際に、Opus 5.5へ戻す手順（モデルセレクターや /model）を把握しているか？
• [ ] 設定または /config で、フラグ検知時の自動モデル切り替え設定を好みの挙動に調整したか？
• [ ] 回答本文内で「内部の推論プロセスをそのまま出力させる」指示を出していないことを確認したか？