2時間の自律動作 - Opus 4.5で実践するエージェント開発
良いツールは働き方を変える。
数ヶ月前まで、エージェントに2時間の自律動作をさせるには、かなり限定的なタスクが必要だった。明確に定義されたリファクタリングや、コードベース全体のlintエラー修正など。それでもたまに成功する程度で、普段は10〜15分が限界だった。
Claude Opus 4.5で変わった。今週、フロントエンドからバックエンドまでのE2E機能実装を、Plan Modeといくつかのツールを使って任せた。1〜2時間、自律で動き続けた。以前なら大量のプロンプトエンジニアリングが必要だったタスクが、そのまま動く。しかも結果が良い。
本当にゲームチェンジャーだと思う。そして、これは止まらない。
バブルなのか？
「AIバブル」という声をよく聞く。確かに期待が先行している部分もある。でも、エンジニアとして実際にモデルを使っていると、改善は確実に続いていると感じる。
自分が注目しているのは2つの指標。
知能：ARC
多くのベンチマークは暗記力を測っている。ARCは違う。「その場で学習し推論する能力」を測る。つまり、本当の意味での知能。ここでも大きな進歩があり、Opus 4.5も好成績を出している。
自律性：METR
エージェントが人間の介入なしに働ける時間。METRの測定によると、これが指数関数的に伸びている。
Opus 4.5のMETR結果はまだ公開されていない。でも、自律性を示す面白い例がある。Opus 4.5がポケモンをプレイするTwitch配信だ。最小限のハーネスで、何時間も自律で判断し続けている。見てみると、モデルの実力がわかる。
なぜこの2つが重要か
知能と自律性が上がると、エンジニアの役割が変わる。コードを書く人から、エージェントを指揮するオーケストレーターへ。
考えてみてほしい。同じ知能を持つ2人のエンジニアがいる。1人は自分で1つのタスクに取り組む。もう1人は10個のエージェントに並行でタスクを委譲する。レバレッジが全然違う。
しかもLLMはスケールする。APIを叩けばいい。夜中に複数のタスクを走らせて、朝起きたら結果を確認する。自律時間が6時間になれば、これが現実になる。
自分はこういうモデルで生産性を考えている：
スループット = (N × T × S) / (1 + H)
- N = 並行エージェント数
- T = 自律動作時間
- S = 成功率
- H = 人的オーバーヘッド
エージェントの自律性が上がるほど、委譲できるタスクが増える。そして、この自律性を活用できるかどうかが、エンジニアの生産性の差になる。
Opus 4.5といくつかのツールのおかげで、これが現実的になってきた。
では、実際にどうやっているか。
N（並行数）を上げる：Vibe Kanban
まず並行数。複数のエージェントを同時に動かしたい。
でも、同じブランチで複数のエージェントを動かすとどうなるか。お互いのコードを上書きする。テストが干渉する。エンジニア同士でも同じ問題が起きるから、ブランチを分ける。エージェントも同じ。
Git Worktreeという解決策
Git worktreeを使うと、同じリポジトリの複数のブランチを、別々のフォルダで同時にチェックアウトできる。各エージェントが自分専用のコードベースを持てる。
さらに、ポートを分ければ、複数バージョンのアプリを同時に起動できる。エージェントAはポート3000で機能Aをテスト、エージェントBはポート3001で機能Bをテスト。完全に独立。
料理で例えると、同じキッチンで5人が同時に料理するのと、5つの独立したキッチンで料理するのの違い。後者のほうが効率的。
問題：手動管理は辛い
でも、git worktreeを手動で管理するのは辛い。ブランチ作成、ディレクトリ切り替え、どのworktreeで何をやってたか...コンテキストスイッチのコストが高すぎる。
Vibe Kanban
Vibe Kanbanはこれを解決してくれた。
- Kanban UIでタスク管理
- Worktreeの作成・切り替えが自動
- PCを再起動しても状態が保持される
- コードレビュー・QAのインターフェース内蔵
これで複数タスクを並行で進められるようになった。
でも、並行で動かせても、各エージェントがすぐ止まって質問してくるなら意味がない。自律時間を伸ばす必要がある。
T（自律時間）を伸ばす：Plan Mode
正直、以前のPlan Modeはあまり使わなかった。Sonnet 3.5の頃は、自分でタスク分解したほうが良い結果が出た。
でも今のPlan Modeは別物。
モデルとハーネスの両方が進化した
重要なのは、モデル（Opus 4.5）だけでなく、ハーネス（Claude Code）も進化したこと。
AnthropicはClaude Codeを自社でdogfoodingしている。自分たちで使って、そのフィードバックをモデルとハーネスの両方に反映する。このポジティブフィードバックループがある。
結果、Plan ModeはOpusのエージェント能力をフルに活用できるようになった。Anthropicのエンジニアも積極的に使っている
何が変わったか
- 複数のサブエージェントで並行にコードを探索
- AskUserQuestionで設計上の重要な判断について質問してくる
- 質問の質が良い。本当に聞くべきことを聞いてくる
本当に感心したのは質問の質。設計上の重要な判断にちゃんとフォーカスしている。
なぜ自律時間が伸びるか
- 自動でコンテキストをprime（準備）してくれる
- プランはローカルにmdファイルで保存される
- compaction時も計画が参照される → 長いタスクでも継続できる
結果、1時間以上の自律作業が安定して可能になった。その間、別のタスクに取り組める。
ただ、長く動いても成功率が低いと意味がない。やり直しになるだけ。
S（成功率）を上げる：Skills & Plugins
成功率を上げるには2つのアプローチがある。
エージェントにエージェントをレビューさせる
最終的な検証は人間がやる。でも、コードレビュー自体はエージェントに委譲できる。
生成する側と批評する側を分ける。LLM as Judgeと同じ考え方で、実際にうまく機能する。
Anthropicのpr-review-toolkitはまさにこれ。複数のエージェントが並行で、セキュリティ、コード品質、テストなど観点ごとにレビューする。品質がかなり高い。おすすめ。
エージェントに知識を教える：Skills
もう1つは、エージェントに「どうやればいいか」を教えること。
エージェントが何かできなかったとき、Skillを書く。次回から、そのSkillを参照して同じ問題を解決できる。
例えば：
- このAPIのデバッグ方法
- このアプリのテスト方法
- 特定のエラーの対処法
cursor rulesに似ているが、もっと具体的なタスク向け。
良いのは、一度Skillを書けば全てのエージェントが自動で使えること。チームメンバーに教える必要がない。知識共有が自動でスケールする。新しいエンジニアが入っても、エージェントが同じ品質で動く。
AnthropicはSkillsを発表し、マーケットプレイスも公開している。すでに高品質なものが揃っている。自分で書く前に、まず公式を見てみるといい。
でも、ツールを揃えても、まだ人間の専門知識は必要。エージェントは文脈を知らずにアーキテクチャ決定をしてしまうことがある。
H（人的介入）を減らす：Closed Feedback Loop
ここが一番重要かもしれない。
毎回の質問は「ミス」
エージェントが質問してくるたびに、こう考える：これはミスだ。あなたがボトルネックになっている。
だから、質問が来るたびに考える：なぜエージェントは自分でできなかったのか？
大体はツールで解決できる
よくある理由：
- エージェントがアプリをテストできない
- エージェントがその情報にアクセスできない
- エージェントがその操作を実行できない
これらは大体、ツールで解決できる。MCPサーバーを使えば、エージェントに能力を与えられる。あなたの代わりに行動させる。
例えば：
- デバッグが必要？ → 自分でWebサイトをクリックしてログを確認する代わりに、エージェントにブラウザを操作させる
- DBの確認が必要？ → エージェントにDBアクセスを与える
- 依存ライブラリの実装を調べたい？ → エージェントにgit cloneさせる
- Issue作成やPR作成？ → GitHub CLIを使わせる
もちろんリスクはある。本番DBへのアクセスをMCPで与えるのは危険だ。ツールを与えるほど、エージェントができることが増える。でもその分、間違ったときの影響も大きくなる。
トレードオフを理解した上で判断する。ツールを与えれば、AIがあなたの代わりに行動できる。あなたがボトルネックでなくなる。中断が減る。
おすすめのMCPサーバー
Playwright MCP: エージェントがブラウザを操作できる。QA、デバッグ、動作確認。これは必須。
GitHub CLI: エージェントがリポジトリを検索、Issue作成、PR作成できる。
Context7: パッケージのドキュメントを検索できる。「このライブラリの使い方は？」をエージェントが自分で調べられる。
試してみてほしいのがcompound-engineering-plugin。これらのMCPサーバーが設定済み。セットアップの手間が省ける。
おわりに
Opus 4.5は本当に次のレベル。
自動化が進む中で、エンジニアの役割は変わるが、なくならない。むしろ、エンジニアリングスキルとアーキテクチャの先見性は今まで以上に重要になる。
課題はエージェントファーストなコードベースをどう作るか。エージェントを単に動かすだけでなく、自律的に力を発揮できる構造を設計する。アーキテクチャとデザインの両方で、新しいアプローチが必要になる。
でも、まだ確立されたガイドラインはない。未知の領域を開拓している状態。実験と適応を繰り返しながら、技術と人間の創意工夫のバランスを探っていく。
この数ヶ月でコーディングエージェントがどれだけ改善されたかは本当に印象的だった。
まずは試してみてほしい。コードベースをエージェントファーストに最適化する。Plan Mode + Opus 4.5を使ってみる。Vibe Kanbanで並行作業を試す。体験すると、見えてくるものがある。
3〜6ヶ月後、さらに賢いモデルが出たとき、何ができるようになるか。エンジニアとして、今はとても面白い時代だと思う。
Discussion