AI Agent の自律性：Claude と Cursor をシニアエンジニアのように働かせる

**先に結論：**AI Agent の自律性は、検証能力と一緒に高めるべきです。Claude や Cursor に、目標、範囲、権限、停止条件、必要な証拠、人間へエスカレーションする条件を渡します。この作業契約こそが、agent を単に速いだけでなくシニアらしく動かす鍵です。

元記事は Addy Osmani が Elevate に公開した 「Agentic Autonomy Levels」 です。公開日は 2026 年 7 月 3 日。

この記事は逐語訳ではありません。Claude Code、Cursor、Codex のような coding agent が、ある時は新人アシスタントのように見え、別の時はシニアエンジニアのように見える理由を、普通の言葉で分解します。

答えは単に「モデルが賢くなったから」ではありません。

大事なのは agent skills です。つまり、AI に目標、境界、触ってよい範囲、完了条件、証拠、停止条件、人間に相談すべき場面を持たせることです。

日常のたとえで言うと、こうです。

• 初級アシスタントは「やってみます」と言う。
• 慣れたアシスタントは「やりました。確認してください」と言う。
• シニアエンジニアは「目標はこれ、範囲はこれ、リスクはこれです。検証はここまで通っています。残る判断は人間が決めるべきです」と言う。

Addy の記事の価値は、この違いを実践できる「自律性レベル」として整理しているところにあります。

図 1：自律性は勲章ではありません。レベルが高いほどよい、という話ではなく、行動の自律性、オーケストレーション、リスク、巻き戻しやすさ、証拠の質を一緒に見る必要があります。

一言でいうと

Claude/Cursor をシニアエンジニアのように動かすには、魔法の prompt を探すより、会話を「エンジニアリングの運用システム」に変える必要があります。

目標 → 範囲 → 権限 → 実行 → 検証 → 証拠 → 人間の判断

Addy が指摘している変化は、prompting から operating への移行です。

以前の問いはこうでした。

AI にどう指示すれば、よいコードを書いてくれるのか？

これからの問いはこうです。

このタスクにはどの程度の自律性がふさわしいのか？ その自律性を正当化する証拠は何か？

この文章をどう読むべきか

この種の記事は、読み方を間違えやすいです。

「Level 5」「Agent 工場」「1000 個の agent」だけを覚えると、派手な部分に引っ張られます。本当に学ぶべきなのは、AI の自律性を、制御でき、検証でき、巻き戻せるエンジニアリング上の選択にすることです。

分けて読むなら、こうです。

つまり、この文章はトレンド記事ではなく、チェックリストとして読むのがよいです。

Claude/Cursor に作業を渡す前に、目標、境界、証拠、停止条件を定義できているか？

6 段階：補完から Agent 工場まで

Addy は agent の自律性を 0 から 5 までに分けています。やさしく言うと、こうです。

ここで一番大事なのは、高いレベルが常に良いわけではない、ということです。

支払い、セキュリティ、本番データに触る作業なのに、テストもロールバックも独立レビューもなければ、レベル 5 は危険です。逆に「100 個の文書タイトルをルール通りに整える」ような作業なら、ルールとサンプリング検査があれば高い自律性でも合理的です。

原則はシンプルです。

自律性レベルは、野心ではなく検証システムに合わせる。

シニアらしさは作業契約から生まれる

シニアエンジニアは「これを良くして」と言われて、いきなり思いつきで変更しません。まず依頼を、検証できる作業契約に変えます。

Claude/Cursor に重要な作業を渡す時も同じです。

図 2：agent を信頼しやすくするのは、形容詞の多い prompt ではありません。目標、範囲、権限、停止条件、証拠、エスカレーション、予算が明確な契約です。

このテンプレートが使えます。

目標：ほしい結果。単なる作業内容ではない。
範囲：変更してよいファイル、モジュール、ページ、システム。
非目標：今回やらないこと。
権限：実行してよいコマンド、依存関係、外部サービス、DB、書き込み。
停止条件：何を満たしたら成功か。何が起きたら止めるか。
証拠：テスト、ログ、スクリーンショット、diff、再現手順、指標。
エスカレーション：どんな不確実性なら人間に聞くか。
予算：時間、token、試行回数、並列 agent 数の上限。

たとえば、こう書くよりも、

ホームページを速くして。

こう書いた方がよいです。

目標：モバイルの Lighthouse performance を 90 以上にする。
範囲：ホームページと直接使われているコンポーネントだけを変更する。デザインシステムは変えない。
権限：ファイル読み取り、コード変更、既存テストと build の実行は可。新しい依存関係は入れない。
停止条件：Lighthouse 90+、npm run build 成功、主要な見た目が変わらないこと。
証拠：変更ファイル、build 出力、性能の前後比較、スクリーンショット。
エスカレーション：機能削除、API 変更、キャッシュ戦略の追加が必要なら先に聞く。
予算：最大 2 回の試行。

agent がシニアらしく見えるのは、タスクの中にエンジニアリング判断が埋め込まれているからです。

要約より証拠

Addy の記事で特に重要なのは、agent の要約を review の代わりにしてはいけない、という点です。

AI は要約が得意です。しかし要約は証拠ではありません。

信頼できる証拠とは、たとえば次のようなものです。

• テストが通っている
• 型チェックが通っている
• lint が通っている
• スクリーンショットが期待通り
• ログで問題を再現できる
• diff が依頼範囲に収まっている
• reviewer agent または人間 reviewer がリスクを確認している

覚えやすい基準があります。

agent が「完了しました」と言うだけなら、高い自律性とは言えません。
独立した証拠で正しさを示せるなら、自律性を上げる余地があります。

なぜ Claude/Cursor は急に強く見えるのか

多くの人は AI coding で二つの段階を経験します。

最初は驚きます。数秒で大量のコードが出てくるからです。

次に失望します。だいたい動くけれど、境界条件が弱い、範囲が曖昧、別の部分が壊れる、ということが起きるからです。

Addy のモデルはこの落差を説明します。最初に見たのは生成能力です。しかしエンジニアリングに必要なのは閉ループ能力です。

シニアエンジニアの仕事は、コードを書くことだけではありません。

1. 文脈を理解する。
2. 目標を定義する。
3. 変更範囲を絞る。
4. 最小で検証可能な変更をする。
5. チェックを走らせる。
6. diff を読む。
7. リスクを説明する。
8. 止め時を知る。

Claude、Cursor、Codex のような agent も、このループの中に置かれて初めて本当に役に立ちます。そうでなければ、ただ速くコードを出すだけです。

並列化は「窓をたくさん開くこと」ではない

Addy が強調している通り、レベル 4 と 5 では、単体 agent の賢さよりも、複数 agent をどう管理するかが重要になります。

これは小さな開発チームを運営するのに似ています。

5 人のエンジニアに同じファイルを同時に触らせ、同じ曖昧な問題を解かせたら、スピードではなく衝突が増えます。

よい並列作業には条件があります。

• 各 agent のタスク切片が明確。
• 各 agent の作業領域が隔離されている。
• 各 agent の完了条件が別々に定義されている。
• 各出力が review キューに入る。
• 最後に証拠と意思決定を統合する人またはシステムがある。

図 3：レベル 5 は「AI に好き勝手させる」ことではありません。タスクがキューに入り、管理 agent が割当て、作業 agent が独立実行し、検証ゲートが証拠を確認し、人間は例外を判断する、という制御されたループです。

よくある 4 つの失敗

Addy の反パターンを、より日常的な言葉で言い換えるとこうなります。

1. 自律性をステータスにする

「うちは Level 5 です」と言っても意味は薄いです。大事なのは、その検証システムが Level 5 に耐えられるかです。

2. 権限の洗浄

毎回承認するのが面倒になり、agent に広すぎる権限を与える。短期的には楽ですが、長期的には危険です。

3. 要約を review の代わりにする

agent が「修正しました」と言っても、修正された証拠にはなりません。テスト、diff、画像、ログ、リスクを見ます。

4. Agent チームごっこ

たくさん agent を起動しているのに、分解、連絡、統合、検収をすべて人間が手作業でやっている。これはオーケストレーションではなく、混乱を増やしているだけです。

週末に試せる 3 つの実験

これは週末に試すにはよいテーマです。ただし、月曜の朝にいきなり本番で試すものではありません。

実験 1：低リスクのタスクに作業契約を書く

README の整理、テストを 1 つ追加、見た目の小さな bug 修正など、実害が出にくいタスクを選びます。まだ AI に編集させず、目標、範囲、非目標、リスク、証拠に分解させます。タスクが明確になるだけで、agent の出力はかなり安定します。

実験 2：証拠パックを要求する

Claude/Cursor が作業を終えたら、要約だけで受け取らないようにします。固定フォーマットで出させます。

• 何を変えたか
• なぜ変えたか
• どの検証を走らせたか
• どんなリスクが残るか
• どこに人間の判断が必要か

これは「何をしたか要約して」より、ずっと役に立ちます。

実験 3：読み取り専用の並列作業を試す

2 つの agent を起動します。ただし読み取りだけにします。たとえば 1 つは性能ボトルネックを調べ、もう 1 つはテストの穴を探す。最後に自分で結論を統合します。merge conflict を起こさずに、並列調査の価値を体験できます。

最初に試さない方がよいもの：

• 複数 agent に同じファイル群を同時編集させる。
• 支払い、認可、ログイン、本番 DB を最初の実験にする。
• 承認が面倒だからといって広すぎる権限を渡す。
• 「AI が完了と言った」ことを完了扱いにする。

練習する価値があるのは、この 6 つです。

1. 先に自律性レベルを選ぶ。補助、監督付き、範囲付き、目標駆動、並列のどれか。
2. 作業契約を書く。目標、範囲、非目標、権限、停止条件、証拠、予算。
3. いきなり変更させず、先に計画を出させる。
4. 重要なステップごとに、説明ではなく証拠を求める。
5. リスクが高いほど権限を小さくし、ロールバックを明確にする。
6. 複数 agent を使うなら、起動前に所有範囲を決める。

使いやすい prompt はこれです。

まだコードを変更しないでください。まずこのタスクを次の形に分解してください。
1. 目標
2. 範囲
3. 非目標
4. リスク
5. 検証に必要な証拠
6. 推奨する自律性レベル
7. 私に確認すべき質問

私が確認した後で、実装を始めてください。

目的は AI を従順にすることではありません。エンジニアリングモードに入れることです。

結論

AI coding の未来は、人間をエンジニアリングから外すことではありません。

シニアエンジニアの働き方を、再利用できるシステムとしてエンコードすることです。

シニアエンジニアの価値は、コードを書く速さだけではありません。リスクを管理し、問題を分解し、完了を定義し、事実を検証し、適切なタイミングで相談し、続けるべきでない時に止まれることです。

Claude/Cursor が役に立つようになるのは、このエンジニアリング動作を身につけた時です。

次に AI coding tool が頼りなく見えたら、モデルだけを疑う前に、こう問い直してみてください。

私はこの agent に、シニアエンジニアが期待する作業環境を渡しているだろうか？