Notes.2026年4月27日AI14 min

Claude Opus 4.7 で「往復型」から「委任型」へ

こんにちは！つつです！

2026年4月16日にリリースされた Claude Opus 4.7 は、単なるモデルのアップデートにとどまらない変化をもたらしています。これまでのAIへの仕事の渡し方の前提が、静かに崩れはじめている——今回はその話です。

AIに仕事を頼むとき、あなたはどんなふうに指示を出していますか。

「まず○○をやってみて」「できたら確認するから止まって」「次は△△の部分を直して」——そういった往復のやりとりで、少しずつ成果物を作り上げていく。最初はそれが丁寧な使い方のように感じられますよね。僕も最初はそう思っていました。

でも、Opus 4.7 のベストプラクティスを読んで、この「小刻みに確認する」スタイルこそが、むしろ能力を引き出せていない状態だとわかってきました。

何が変わったのか

AIへの仕事の渡し方が変化する様子。左側に「細かく往復する人間とAI」、右側に「ゴールと完了基準を渡して委任する人間とAI」。章扉的な対比イラスト。

Opus 4.7 の公式ベストプラクティスには、こんな記述があります。

Because Claude Opus 4.7 is more autonomous than prior models, specifying the task, intent, and relevant constraints upfront in the first human turn helps maximize autonomy and intelligence while minimizing extra token usage.

— Anthropic 公式ベストプラクティス（出典）

「最初の1ターンで全部伝えると、一番うまく動く」——4.7の力を引き出すには、これが出発点になります。

思考転換1: ペアプログラミング型から委任型へ

往復型（ペアプログラミング型）: 「この関数を作って」→「エラー処理を追加して」→「テストも書いて」と会話を重ね、30点→50点→80点と積み上げる。毎回のやりとりでコンテキストが積み重なり、最終的には疲弊する。

委任型（Opus 4.7 向け）: 最初から「ゴール / 制約 / 完了基準」の3点を揃えて渡す。AIが実装・テスト込みで一気に完成させる。人間は節目の確認だけに集中できる。

「どこに向かうか（Goal）」「どう作るか（Constraints）」「何が達成されていれば完了か（AC）」の3点セット——これが Opus 4.7 を使いこなす入口になります。

思考転換2: 「制約」と「完了基準」は別物だと理解する

**Constraints（制約）**は「どう作るか」のルールです。「フォントサイズは16px以上」「既存のデータ型は変更しない」「外部ライブラリは追加しない」といった、実装の縛りを指します。

**AC（完了基準）**は「何が達成されていれば終わりか」の判定基準です。「テストが全件グリーン」「APIレスポンスが500ms以内」といったアウトカムの条件になります。この2つを分けて書くことで、AIは自分が今どのゴールを目指しているかを把握しながら動けます。

思考転換3: 「節目確認」に切り替える

Opus 4.7 ではACにチェックポイントを組み込む方法が推奨されています。コーディングなら「各モジュールの実装後にテストを走らせ、結果を報告してください」とACに書いておく——プロセスを逐次確認するのではなく、成果物の節目で評価するスタイルへの切り替えが、長時間の自律タスクをうまく回すコツです。

思考転換4: Effort Level を使い分ける

Opus 4.7 には「どのくらい深く考えるか」を調整する effort パラメータがあります。5段階あり、コーディングや複雑な推論タスクには xhigh（エクストラハイ）が新設されました。Claude Code では /effort xhigh を設定するだけで有効になります。

Effort Level	向いているタスク
`low`	短い・スコープが狭い・速度優先
`medium`	コスト重視で多少の精度低下を許容
`high`	大半のインテリジェンス重視タスク
`xhigh`	コーディング・エージェント系タスク（新設）
`max`	最高精度が必要な特殊タスク（過剰思考注意）

max は一部のタスクで「考えすぎ」になる傾向があるとのこと。コーディング用途では xhigh を基本にして調整するのが推奨です。また Stop Hook を設定しておくと、AIが完了判断時に自動で npm test などを実行してくれます。テストが通るまで「完了と言わない」状態で動く——委任型スタイルを支える重要な仕組みです。

思考転換5: 指示を文字通りに受け取るモデルへ

Claude Opus 4.7 interprets prompts more literally and explicitly than Claude Opus 4.6. It will not silently generalize an instruction from one item to another, and it will not infer requests you didn't make.

4.6 は「たぶんこういう意味だろう」と少し外挿してくれる面がありましたが、4.7 はより文字通りに動きます。「なんとなく全体に反映して」より「第2章以降の全見出しに適用して」と書く習慣が、このモデルでは効いてきます。

プロジェクトのルートに CLAUDE.md を置いておくと、Claudeが起動するたびに読み込む「共通の指示書」として機能します。毎回のプロンプトに Goal / Constraints / AC を書き直す代わりに、一度 CLAUDE.md に定義してしまえば会話のたびに書き直す必要がなくなります。

設計図を持った建築家とAIロボットが一緒に建物の設計図を広げて確認している俯瞰イラスト。毎回の口頭指示ではなく共有の設計書を基点に動く様子を表す章扉的なイラスト。温かみのある色調

## このプロジェクトのルール

### Goal
ユーザー向けのToDoアプリのフロントエンド実装

### Constraints
- TypeScript strict mode を必ず有効にする
- 外部ライブラリは package.json に記載のもののみ使う
- コンポーネントのファイルは src/components/ 配下に置く

### Acceptance Criteria
- `npm test` が全件グリーンであること
- TypeScript エラーがゼロであること
- ESLintエラーがゼロであること

「ACのないタスクはAIに委任できない」

ACのないタスクはAIに委任できない。明確な完了条件がないまま仕事を渡すと、AIはどこで「終わり」とするかを自分で判断することになり、「やり過ぎ」や「やり足りず」の原因になる。

ソフトウェア開発における「テストなしのリファクタリング」と同じ構造です。動いてはいるけれど、壊れているかどうかがわからない。まずは小さいタスクで「Goal / Constraints / AC」の3点セットを書く練習から始めてみてください。慣れると「このACは何にすればいい？」という問い自体が、タスク整理の助けになっていきます。

まとめ

従来スタイル	Opus 4.7 向けスタイル
30点ずつ確認しながら進める	最初にGoal/Constraints/ACを揃えて渡す
プロセスを管理する	成果物の節目で評価する
指示の外を読んでくれる期待	指示は文字通りに解釈される
途中で軌道修正	Stop Hookで自己チェックを走らせる

このシフトが腹落ちすると、AI活用の悩みの多くが「モデルの問題」ではなく「指示の設計の問題」だったとわかってきます。まずは /effort xhigh の設定から試してみてください。

参考リンク