Claude Opus 4.7で変わる、長時間コーディングタスクの任せ方

Anthropic は 2026年4月16日に Claude Opus 4.7 を一般提供しました。発表では、難しいソフトウェアエンジニアリング、長時間タスク、指示追従、自己検証の改善が強調されています。

強いモデルが出ると、つい「より大きな仕事を丸投げできる」と考えたくなります。ただ、実務では逆です。モデルが強くなるほど、任せる側には明確な完了条件と検証条件が必要になります。

任せるタスクを「長い」ではなく「閉じた」にする

長時間タスクに強いモデルでも、開いたタスクは崩れます。

悪い依頼:

• 「このアプリを改善して」
• 「テストをいい感じに増やして」
• 「技術負債を整理して」

良い依頼:

• 「ログイン失敗時のUXを、既存のエラーハンドリング方針に合わせて修正。対象はauth配下のみ。既存テストを更新し、失敗ログを報告」
• 「billingモジュールの未テスト分岐を3つ特定し、最小のユニットテストを追加。実装変更は禁止」
• 「deprecated APIの呼び出し箇所を一覧化。修正案は出すが、編集はしない」

重要なのは、時間の長さではなく境界です。触ってよい範囲、触ってはいけない範囲、完了の証拠を先に決めます。

1. 1
   境界を決める

   対象ファイル、禁止範囲、完了条件を先に書く。
2. 2
   反論させる

   前提の弱い点と失敗しそうな点を実装前に出させる。
3. 3
   小さく実装する

   閉じたタスク単位で差分を作らせる。
4. 4
   レビューする

   ログ、テスト、変更範囲を人間が確認する。

強いモデルほど「反論」を歓迎する

Anthropicの発表では、Opus 4.7が難しい作業で一貫性を保ち、自分の出力を検証する方向が示されています。こうしたモデルには、単に実装させるだけでなく、計画段階で反論させる使い方が向いています。

プロンプトに次の1文を入れるだけで、無理な実装の早期発見に効きます。

実装前に、前提の弱い点、失敗しそうな点、先に確認すべきファイルを短く列挙してください。

— レビュアーとして使うプロンプト例

強いモデルを「従順な作業者」として使うより、「作業前に設計の穴を見つけるレビュアー」として使う方が、長いタスクでは効きます。

レビューは省略しない

モデルが自己検証できるようになっても、人間のレビューが不要になるわけではありません。むしろ、レビュー観点を固定化しやすくなります。

• 仕様にないフォールバックを足していないか
• エラーを握りつぶしていないか
• テストが実装に都合よくなっていないか
• 変更範囲が依頼した境界を超えていないか
• 実行ログと最終報告が一致しているか

長時間タスクの品質は、モデル性能だけでなく、レビューリストの質で決まります。

出典

• Anthropic: Introducing Claude Opus 4.7