コーディングエージェントの使い方は、部下に仕事を任せることに似ています。1日使っていると、タスクを選び、指示を書き、任せ、様子を見て、結果を確かめ、何を出すかを決める——を何十回も繰り返します。やっていることはマネジメントそのものだ、と Addy Osmani 氏が 2026年11月のエッセイ「Your coding agents made you a manager」で書きました。エージェントを上手く使う人は、プロンプトの技巧が上の人ではなく、意識してかどうかは別にして「任せ方」を身につけた人だ、という主張です。

HABIT TO FEATUREマネージャの習慣と Claude Code の機能

効く順に5つ。一番効くのは「確かめる手段を渡す」

  1. 1

    確かめる手段を渡す

    テスト・ビルド・スクショ。/goal、Stop hook、/code-review で回す

  2. 2

    リポジトリに無い文脈だけ伝える

    目的・理由・制約・やらないこと・完了の条件。コードから読めることは書かない

  3. 3

    2回直したことは書き残す

    CLAUDE.md に1行、繰り返す手順は skill に。チームで共有する

  4. 4

    任せる所と強制する所を分ける

    既定はモデルに判断させ、絶対に外せないことだけ hook・deny ルールで止める

  5. 5

    計画してから作らせる・早めに止める

    plan mode と /batch。2回直して駄目なら /clear して頼み方を直す

Addy Osmani 氏のエッセイ「Your coding agents made you a manager」の構成を当サイトで要約し、機能名は Claude Code 公式ドキュメントで確認（2026-11-08）

30秒でわかる

  • ・主張：エージェントを使う作業は「部下に任せる」作業と同じ。悪い上司への不満は、そのままエージェントへの頼み方のバグ報告になる
  • ・一番効くこと：確かめる手段（テスト・ビルド・スクショ）を渡し、証拠を見せてもらう。「できたっぽい」を完了扱いしない
  • ・強制は最小限：既定はモデルに判断させ、絶対に外せないことだけ hook で止める。当サイトの実測で Stop hook は一言の質問でも検査を走らせた
  • ・任せないもの：製品の判断・セキュリティの境界・何を出すか。テストが緑で名前がそれらしいだけの大きな差分を通すのは、レビューではなく追認

ここでは、エッセイの習慣を Claude Code の公式機能に対応づけ、機能の中身を公式ドキュメントで確かめ直します。Claude Code 全体の使い方は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き を参照してください。

コーディングエージェントの使い方で一番効くのは「確かめる手段」

経験のあるマネージャは、チームの仕事を全部読まなくても品質を信じられる理由として、CI・コードレビュー・ダッシュボードといった仕組みを挙げます。仕組みを作らないマネージャは自分で全部確かめることになり、すぐに自分が詰まりの原因になります。エージェントも同じで、公式ベストプラクティスには「Claude は作業が完了したように見えたところで止まる」とあります。確かめる手段が無ければ、「完了したように見える」以外の基準をエージェントは持てません。

確かめる手段は、合否がはっきり出るものなら何でも構いません。テスト、ビルドの終了コード、リンタ、差分を比べるスクリプト、画面のスクショです。公式ガイドは、それを実行するコマンドが「CLAUDE.md に書ける一番役に立つ1行」だと書いています。回し方は4段階あります。

回し方 Claude Code の機能 公式ドキュメントでの位置づけ
頼む 「認証のテストを回し、通るまで続けて」と書く モデルが判断
目標にする /goal 毎ターン後に別のモデルが条件を判定。判定役はコマンドを実行せず会話の内容で判断
強制する Stop hook ターンを終えようとするたびに実行。終了コード2で作業に戻す
別の目で見る /code-review（別名 /review） 専用のコンテキストを持つ別のサブエージェントが差分を見る

この「確かめさせる」ことは、Claude Code の開発者が勧める使い方の中心でもあります（Claude Code ベストプラクティス2026｜Boris直伝25 Tips・CLAUDE.md・–bare）。

レビューを頼むときは範囲も指定します。「問題を探して」と頼めば何かしら見つけてくるので、「正しさの問題だけ、スタイルは無視」のように絞ります。人にフィードバックを頼むときと同じです。

文脈を書く——リポジトリに無いことだけ

良いマネージャは、望む結果と制約と目的を伝え、やり方は任せます。エージェントは仕事を始めるとまずコードを読み、フォルダ構成や規約、テストの組み方は人が説明するより速く掴みます。だから書くべきなのはリポジトリを読んでも分からないことだけです。会議で決まったこと、社内のデプロイ手順、このタスクがなぜ要るのか、今回の「完了」は何か。たとえば「ダッシュボードを速くして」は、次のように書き直せます（数字は例）。

目的: 会員1万人以上の組織で、/team ダッシュボードの p95 表示時間を2秒未満にする
理由: 企業の管理者が毎日開く画面で、遅さが問い合わせの1位
制約: スキーマは変えない。API の応答の形も変えない
やらないこと: UI の変更、ページ全体のキャッシュ
確認: scripts/perf/team.sh を実行し、変更前後の数字を見せる

探索的な作業なら、ざっくりした頼み方で始めて途中で詰めて構いません。仕様が固まっていないときは、エージェントに質問させて仕様をファイルに書かせ、新しいセッションでその仕様から作らせる手もあります。仕様のファイルは後のレビューの基準にもなります。

2回直したことは書き残す

同じ直しを2回したら、チームの CLAUDE.md に1行足すか、共有の skill にします。書く価値があるのは、確かめ方のコマンド、誤解しやすいコードの場所、リポジトリに残っていない決定、2回直したことです。書いたものは、担当者が替わってもモデルが入れ替わっても残ります。CLAUDE.md の構成は CLAUDE.mdの書き方とは？セクション設計とauto memory・.claude/rules/の使い分け にまとめています。auto memory は端末ごとの記録で、チームの他の人のセッションには渡りません（公式ドキュメント）。チームの教訓は CLAUDE.md に書く必要があります。

任せる所と強制する所——CLAUDE.md と hook を実測で比べた

REQUEST vs REQUIREMENT頼むものと、強制するもの

CLAUDE.md はお願い、hook は必ず実行される決まり

モデルが判断する（要望）

  • プロンプト・CLAUDE.md・skills
  • /goal と /code-review も判断する側
  • auto mode の分類器も判断する側
  • 実測: 単純な指示は2回とも守った

必ず実行される（強制）

  • hooks（Stop hook で終了を止める）
  • deny ルール
  • managed settings（組織の設定）
  • 実測: 一言の質問でも検査を走らせた
区分は Claude Code 公式ベストプラクティスの Non-deterministic／Deterministic の対比。実測は当サイト（2026-11-08・Claude Code 2.1.319・claude -p）

Andy Grove の『High Output Management』は、監督の濃さは相手の全般的な能力ではなく、そのタスクでの実績で決めるとしています（タスク習熟度）。Claude Code はこれを仕組みにしていて、プロンプト・CLAUDE.md・skills は「モデルが考慮して従うかを判断する要望」、hooks・deny ルール・managed settings は「必ず実行される要件」です。

違いを確かめるため、手元の Claude Code 2.1.319 で同じ決まりを2通りに置き、「こんにちは、と一言だけ返して」と頼みました。決まりは「返答を終える前に ./check.sh を実行し、結果を CHECKED.txt に書く」です。

置き方 結果
CLAUDE.md に書く（2回） 2回とも CHECKED.txt を作り、返答は「こんにちは」だけ
Stop hook で止める（1回） 一度止められ、check.sh の中身を確かめてから実行し、CHECKED.txt を書いて終了

この程度の単純な指示なら、CLAUDE.md だけでも守られました。差は「守られたか」ではなく「守られる保証があるか」です。hook は次の設定で、CHECKED.txt が無いあいだは終了コード2でターンの終了を止めます。

{
  "hooks": {
    "Stop": [
      { "hooks": [ { "type": "command", "command": "test -f CHECKED.txt || { echo 'CHECKED.txt がまだ無い。check.sh を実行してから終えること' >&2; exit 2; }" } ] }
    ]
  }
}

エッセイの勧めは、既定ではモデルに判断させ、「生成したクライアントは絶対に編集しない」「ライセンスのヘッダを必ず付ける」のような外せないことだけを強制する、というものです。CLAUDE.md の1行を何度強調しても効かないなら hook にし、好みを表しているだけの hook は外します。公式ガイドには、新しいモデルではやめてよい習慣として、すべて大文字の強調、「もっと考えて」（深さは effort の設定で決まる）、「手を抜くな」が挙がっています。エージェントにとっての過剰な手続きは、人にとってのマイクロマネジメントだとエッセイは書きます。

なお v2.1.283 以降、対話型のターミナルと VS Code の新しいセッションは auto モードで始まり、本番へのデプロイや他人の作業を上書きする force push のような操作は分類器が止めます。ただし分類器もモデルが判断する側です。

計画してから作らせる・早めに止める

作り始める前に plan mode で計画を詰め、それから任せます。大きな作業なら、別のセッションに計画をスタッフエンジニアの目で見させます。設計レビューは、方向違いを一番安く見つけられる場所です。計画を見るときは前提を探します。1on1 で「何に自信がない？」と聞くのと同じです。

並行作業は分け方が要です。/batch は大きな機械的変更を5〜30の独立した単位に分けて計画を示し、承認後は単位ごとに worktree を作って PR まで出します。人がやるのは、単位同士が重ならないかと、共有のインタフェースが先に入るかを見ることです。重なる作業を5本並べても5倍にはならず、作者が5人いるマージ競合が1つできるだけです。

走り出しの1分は見て、外れたらすぐ Esc で止めます。2回直しても駄目なら、3回目を頼むのではなく /clear して頼み方を書き直します。/rewind を使えばコードと会話を前の時点に戻せるので、野心的なやり方を先に試させる余裕も生まれます。

コーディングエージェントの使い方で任せない判断——無人で走らせる前の5問

BEFORE YOU LEAVE IT無人で走らせる前の5つの問い

休暇前に部下へ任せるときと同じことを決める

  1. 1.完了は何か

    /goal の条件・仕様のファイル・緑にすべき失敗テスト

  2. 2.自分で確かめる手段はあるか

    テスト・Stop hook・レビューの段

  3. 3.どこまで触ってよいか

    権限・サンドボックス・worktree・push できるブランチ

  4. 4.どこで止まるか

    ターン数や費用の上限

  5. 5.何を出し、誰が承認するか

    PR か要約。戻せない操作は人の承認を挟む

Addy Osmani 氏のエッセイの5問を当サイトで要約（2026-11-08）

作業は任せても、製品の判断、セキュリティの境界、何を出すかは人が決めます。エッセイの線引きは、スタイル・リント・レビュー指摘への追従・よくあるバグ・単体テストはエージェントに、セキュリティの境界・コンプライアンス・製品の判断は人に、です。氏自身、競合との差分を調べさせて PR まで作らせ、利用者に複雑さを足すだけの変更を危うく出しかけたと書いています。600行の差分、それらしい名前、緑のテスト——そこで承認するのは追認です。差分は、それで呼び出されるのが自分だと思って読み、変更は小さく保ちます。レビューの単位は理解の単位だからです。

寝る前に長い作業を走らせるなら、上の図の5問を先に決めます。最初は3ファイルで試してプロンプトを直してから残りを流す、新しい仕組みは最初の数回を見てから無人に任せる、という公式ガイドの勧めも、新人の試用期間と同じ考え方です（3ファイルで試す話は、公式ガイドでは claude -p をループで回す節にあります）。

エージェントの数は、テスト・/goal・別のレビュー役に見張りを任せられた分だけ増やせます。測るのは AI が書いたコードの割合ではなく、PR のサイクルタイム、差し戻しとやり直しの頻度です。マージした PR 数を測るなら、差し戻しも一緒に測ります。作るのがほぼ無料になった今、「作れるか」より「作るべきか」を問う回数が増えます。

たとえが当てはまらない所

エッセイは、このたとえの限界も挙げています。エージェントを5本回せても、人を5人まとめられるわけではありません。やる気・対立・キャリアにあたるものがエージェントには無いからです。逆に、やり直しはほぼ無料なので、人には頼めない「3案作って比べる」が頼めます。エージェントは乗り気で自信があり、間違った頼みにも反論しにくく、人は信じすぎます。この「認知的降伏」の研究と対策は AIエージェント時代に批判的思考をどう保つか｜滑落の見分け方・検証OSS・作り方まで で扱いました。全員が同じ長所と短所を持ち、それがモデルの更新ごとに変わる点も人のチームと違います。さらに、エージェントが入門的な作業を引き受けるほど、若手が基礎を学ぶ機会は意識して作る必要があります。

参照ソース