AIエージェントに作業は任せても判断は任せない、まさおさんが語るマネジメントの習慣

出典: まさおAIじっくり解説ch「【必見】Claudeの中の人が語る、AI上達のコツは『プロンプトよりマネジメント』！向き合い方10選を徹底解説」

スライド6/17の見出しは「エージェントが自分で確かめる手段を渡す」。「終わったっぽい」で受け取らない、という話から10個の習慣が始まります。

まさおさんは、ここを土台として話します。

動画では（5:15〜）

エージェントが自分自身を確かめる手段を渡すというのがね、すごく重要だということですね。

並べる手段は具体的です。テストを通させる。/goal（毎ターン、別のモデルが条件を満たしたかを確かめる仕組み）を使う。Stop hook（決まった検査が通るまで終わらせない仕掛け）を置く。/code-review（会話を見ていない別のAIが見る）にかける。検証の道具を作って、通るまでやらせる、とまさおさんは話します。

スライドには「CLAUDE.md に書く1行で、いちばん価値があるのは検証コマンド」と出ます。CLAUDE.md は、Claude Code（コードを書くAIエージェント）が毎回読む指示のファイルです。

検証コマンドが1行あれば、終わったかどうかをAI自身が判定できます。並んだ手段の違いは道具の種類で、向きは同じ。終わりを決める物を、私の目から、AIが持つ証拠へ移す。この1行は、その切り替えの入口なんですよね。

AIの手抜きとは、やり切らないこと。やり切るとは、調べ尽くして手を尽くして、ベストに本気で入魂して仕上げきること。私はそう考えています。

「終わったっぽい」は、やり切っていない状態そのもの。作業は進んだ。でも、通ったかどうかは誰も見ていません。

私なら、「終わりました」の報告に、何を何件確かめたかを必ず付けさせます。件数があれば、確かめた範囲と、まだ確かめていない範囲が、中身を開く前に分かるからです。

証拠があれば、受け取る側は中身を開く前に判断できます。証拠がなければ、確かめる仕事は私の手に戻ってくる。せっかく渡したボールが、報告の一言で戻ってくるんです。確かめる手段を渡すとは、やり切った証拠をAIに持たせることです。

スライド7/17の見出しは「指示に書くのは『リポジトリに無いこと』だけ」。リポジトリは、コードや資料を置いておく作業の置き場のことです。

まさおさんは、良いマネージャーの像から入ります。

動画では（6:13〜）

良いマネージャーとは目的と制約を伝えてやり方は任せるということらしいんですけれども

モデルが賢くなったので、やり方はエージェントが自分で見つける、とまさおさんは話します。書かなくていいのは、フォルダ構成や書き方の決まり、テストの準備。エージェントが自分で読めるものです。書くのは、会議での決定、社内の手順、なぜ大事か、今回の「完了」。指示する人しか知らないことです。

スライドの例がわかりやすい。「ダッシュボードを速くして」を、目標・理由・制約・対象外・確認の5行にします。目標は「1万人超の組織で p95 を2秒未満」。表示の95%がその時間に収まる、という速さの目安です。書けない時はエージェントに質問させて仕様を引き出し、ファイルに残してから新しいセッションで作らせる、とも話します。

5行のうち、私がいちばん効くと思うのは対象外の行です。頼んでいない所まで手を広げない線になるからです。目標と確認の行は、今回の「完了」をAIと人で同じ形にそろえるためにあります。

私の手元の決まりにも、近い形があります。AIに読ませる決まりのファイルの一部を毎回は読ませず、文章を書く時、画像や動画を作る時、仕組みを触る時と、仕事の種類ごとに索引から引く形に分けています。

全部を毎回読ませるより、要る時に引く。書くのは指示する人しか知らないことだけ、という動画の話と同じ向きです。

そのうえで、私は動画を少しずらして読みます。動画も、なぜ大事かを書くものに入れていて、スライドの5行にも理由の行があります。私はその理由を、手順より先頭に置き、判断軸と体験につなげて残します。最初の1本で残すのは、表面の文体ではなく、なぜとその判断軸、価値観、紐づく体験ストーリー。これを私は外しません。

リポジトリを読めば分かる手順は、AIの方が上手に組み立てることもあります。置き場に残っていないのは、たいてい理由の方なんですよね。手順だけを細かく書くと、AIはその手順に縛られます。理由が書いてあれば、想定外の場面でも同じ向きで判断できます。

リポジトリに無い手順は書く。読めば分かる手順は書かない。その上に、なぜと判断軸を置く。これが、私の引く線です。

スライド8/17の見出しは「2回直したことは、書き残す」。同じ指摘を毎回している、という冒頭の場面への答えです。

まさおさんの言い方は、とても短い。

動画では（7:43〜）

2回直したことっていうのは書き残しましょうね。

1回目の指摘で直らなければ、2回目で CLAUDE.md やスキル（決まった手順をまとめて呼び出せる形にしたもの）にする、とまさおさんは話します。どこでも使うものはグローバルのスキルに。決まった時に自動で強制できるなら hooks（決まった時に自動で動く仕掛け）に。

スライドには「毎回同じことを手で直すのは失敗例」と出ます。入れるのは、検証の正確なコマンド、誤解しやすいコードの場所、リポジトリに残っていない決定、2回直したこと。あわせて「CLAUDE.md は短く保つ」「新モデルで要るか見直す」とも出ます。

まず書き、決まった時に強制できるものは hooks へ移す。お願いで足りるものはお願いのまま、守られないものだけを仕掛けにする。この線引きは、次の章の強制の話にそのままつながっていきます。

私が気になるのは、残す量の方です。全部残すと、決まりが太るだけになります。CLAUDE.md は毎回読まれるファイルなので、太るほど読む側の手間も増える。そこで私は、残す量に一本線を足します。

物差しは、次に同じ場面が来た時に、判断が変わるかどうか。同じ状況で次回の判断が変わるものだけを、1行のメモとして残す。私はそう決めています。誤字の直しや、その1回だけの好みは残さなくていい。

動画の「短く保つ」「新モデルで要るか見直す」も、この物差しと同じ向きです。書き足すだけでなく、要らなくなった行を外すところまでが、書き残す仕事なんですよ。

書き残した行には、どの場面で判断が変わるのかを1言添えておく。添えられない行は、外す候補になります。

2回直したら書き残す。その前に、次の判断が変わるかを一度だけ問う。この一問が、私の足し算です。

スライド9/17。上部の札には「hook などで縛るのは最小限に」と出ます。縛り方の話ではなく、縛りすぎない話です。

まさおさんは、強制しすぎることの方を気にかけます。

動画では（9:29〜）

過剰なプロセスっていうのはエージェント時代のマイクロマネジメントということで

基本は任せる、とまさおさんは話します。必ず守らせる要件だけを、hook や deny ルール（してはいけない操作を拒む設定）、組織の管理設定で強制する。軽いものは prompt や CLAUDE.md、スキルでお願いする。強調しても守られない行は hook に移し、好みでしかない hook は外す。強制しすぎるとエージェントの動きが悪くなるので、バランスが大事だ、という話です。

見張る強さの物差しとして、アンディ・グローブの「タスク習熟度」も出ます。見張る強さは、能力全般ではなく、その仕事での実績で決める、という考え方です。

スライドには「もうやめていい癖」として、全部大文字の指示、think harder、don’t be lazy も並びます。

ここで私が重ねるのは、2026年11月6日の出版企画の仕事です。途中で「この順で始めてよいか」「この一覧でよいか」の確認が続き、私はそれを、できていないと返しました。頼んだ全段を最後まで作り切ってから、1回だけ見せる形にしてほしいと伝えたんです。

その結果、止まって聞くのは、公開・送信・削除・Kindle本の出版申請などの、出す直前の最終確認と、私にしかできない操作だけ、と決まりました。

動画の言うマイクロマネジメントは、AIを縛りすぎる話です。私にとっては、任せる側が止める所をどこに置くか、の話でもあります。

できあがりを見て直す確認を、私は味見と呼んでいます。その味見を、成果物ごとの承認待ちに戻さない。これは私が決めている軸です。途中の一つずつに「はい」を返す形は、この軸と逆向きなんですよね。

どこで止めて、どこは止めないか？ その線を引くのは、任せる側の仕事です。

私なら、途中の「この順でいい？」は聞かせず、最後まで作り切らせてから1回だけ味見し、止めるのは取り返しのつかない操作の直前だけにします。

では、任せる前に何をそろえておけばいいのか？ スライド10/17の答えは、作る前に計画で合意することです。

まさおさんが紹介する流れは3段です。plan mode（作る前に計画だけを練る使い方）で計画を練る。別のセッションに設計を見直させる。それから実装を任せる。計画で見るのは「前提」で、エージェントに不安な点を聞きます。スライドには、1on1 の「何が不安？」と同じだと出ます。

なぜ作る前なのか。まさおさんはこう話します。

動画では（10:34〜）

計画フェーズっていうのが間違いを1番あの手戻り少なくね、見つけられるフェーズなので

作ってから見つかる間違いより、計画の段階で見つかる間違いの方が、直しが少なくて済む。まさおさん自身も、納得するまですり合わせてから任せている、と話します。

スライドには並行の話も出ます。重なった仕事を5体に並行させても、5倍の成果にはならない。5人分の変更がぶつかる大きなマージ衝突（変更どうしの食い違い）が1つ残るだけ。

大きな機械的な変更なら、/batch で5〜30個に分け、worktree（作業用の別の置き場）ごとに実行する。そんな使い方も紹介されます。

動画は、作る前に計画で合意することを勧めます。私の失敗は、その手前の、方針がまだ決まっていない段階で起きました。

2026年9月29日から10月1日までの約2日、私はマーケティングの方針をAIと決めていました。まとめるのが目的ではないと私が返した後、AIは私の許可を得ないまま、お客さん役を演じさせるAIを4体同時に動かす試しを走らせました。AI自身が決めていた使用量（AIの作業量）の上限を、超えるところまで走っています。

私が返したのは、方針が決まっていない事が問題だ、という中身でした。決まるまでは試しを走らせず、決まってから任せたい、と伝えています。

私が返したのも、上限ではなく方針の話です。

実は私は、計画に縛られるのが苦手です。「計画立てるのはいいけど決まった計画に従うのが地獄」。これが私の本音なんですよね。だから動画の「計画で合意する」は、手順を固める話としてではなく、方針をそろえる話として受け取ります。

細かい手順まで計画で固めることはしない。でも、方針が決まる前に重い試しは走らせない。決まっていないうちに走らせると、どれだけ使っても、向きが合っているかが分からないまま。動画の⑤から私が取るのは、この一点です。

計画は固めない、方針は決める。前の章でそう書きました。それでも、走らせてみるとずれることはあります。その時、何回まで直すのか。スライド11/17は、そこに数字で線を引いています。

まさおさんが紹介する流れは、最初の1分を見て、外れたら Esc（作業を止めるキー）で止めて直す、というものです。核心はこの一言。

動画では（11:03〜）

外れたらすぐ直して2回直してダメならセッションごと捨てて書き直す。

捨てる時は、学びを入れてプロンプトを書き直します。スライドには「3回目の訂正: モデルが読み直す失敗の履歴が増えるだけ」と出ます。

直すほど、AIが読み直す失敗の記録も積み上がる。この見方です。

/rewind（会話を巻き戻す）が安いので、野心的なやり方を先に試せる、ともまさおさんは話します。

巻き戻しが安いなら、1つのやり方に粘るより、外れた時点で手放して次を試すほうが早く当たりにたどり着く。捨てる判断が早いほど、試せる回数が増えるわけです。

ずれは続くから、早く見つけるために小さく作らせる。これがこの章のまとめなんです。

AIとのズレを見張る位置から見ると、すり合わせの手間が人の側に戻ってくる。一段上から見れば、同じズレを「おかげで仕組みを改善できる」と受け取り、感謝へ変えられる。私はそう捉えています。

3回目、4回目と直し続けるのは、まさに見張る位置にいる状態です。ずれるたびに、すり合わせの手間が私の側に積み上がります。

一段上から見れば、捨てたずれは無駄になりません。どの前提が足りなかったのか、どこを書き直せばいいのかを教えてくれる材料。捨てることは負けではなく、直す場所を見つける手順です。

2回という数字も、迷う時間を減らす線として効きます。何回まで直すかを先に決めておけば、続けるか捨てるかを、その場で悩まずに済むからです。

捨てたずれは責めずに、どこを直せば次は起きないかの材料にする。捨てるだけで終わらせない所が、私が動画に足す一手です。

任せる範囲が広がるほど、気になるのは責任の置き場所です。スライド12/17は、任せてよい物と人が持つ物を左右に分けて見せます。

任せてよい側にあるのは、スタイルや lint（書き方の自動チェック）、レビュー指摘への対応、よくあるバグ、ユニットテスト。人が持つ側にあるのは、セキュリティの境界、コンプライアンス、何を出すかの判断です。その線の理由を、まさおさんはこう話します。

動画では（12:28〜）

それは誰の責任なんだって言うと、AIエージェントの責任ではなくて、ま、人間の責任ですよねと。

まさおさんは、人の注意力に投資したいのであって、エージェントのトークンに投資したいわけではない、と話します。

理解を確かめる手段も具体的です。最後にクイズを出してもらう。分かりやすいHTMLや動画を作ってもらう。自分の理解が合っているかを確かめる。

スライドには「変更は小さく（レビューの単位＝理解の単位）」とあります。

読める大きさに切ることが、そのまま責任を持つ準備になるわけです。続けて、任せた人の構えをこう言います。

動画では（13:33〜）

責任を取って呼び出されるのはエージェントではなくて自分のつもりだということで

呼び出されるのは自分。そう決めて diff（変更の差分）を読むと、流し読みでは済まなくなります。

作業は渡しても、魂は渡さない。前にも書いた、私の軸です。この章で新しく読みたいのは、左右の線そのものです。

左の列に並ぶのは、書き方の自動チェックやテストのように、確かめる手段を機械で用意できる物。右の列に並ぶのは、間違えた時に取り返しがつかない物です。私はこの線を、確かめる手段を機械で持てるかどうか、で読みます。機械で確かめられる物は渡す。取り返しがつかない物は、自分の手に残す。

責任を持つとは、何でも自分で抱えることではありません。自分が呼び出される前提で、出てきた物を自分が読める大きさにしておくこと。小さく切らせるのも、クイズで確かめるのも、そのための手段です。

ただ、小さく切らせるだけでは足りない、とも思っています。小さな変更でも、数が並べば読む量はまた増える。だから私は、切る大きさより先に、出す・出さないを決める物差しを自分の側に置いておきます。

作業は渡す。出す・出さないの判断と、その理由の説明は渡さない。ここは迷いません。

スライド13/17の見出しは「シニアに仕事を任せて休暇に行く前の上司と、同じ5つの問い」。自分が見ていない間も回る仕事は、何を決めておけば回るのか。その答えが5つ並びます。

まさおさんが紹介する5つは、こうです。完了の形を知っているか。自分で検証できるか。どこまで触ってよいか（権限・sandbox・worktree・ブランチ）。止まる条件（ターン数や上限）。出力はどこで誰が承認するか。決めずに走らせるとどうなるか、まさおさんの言葉です。

動画では（14:35〜）

朝起きたらね、エージェントが間違った前提で、え、ずっと走り続けてたっていうこともあり得るので

スライドには「まず3ファイルで試してから残りを流す」と出ます。

「新しく任せる仕事は最初の数回を見張る（試用期間）」ともあります。いきなり全部を無人にしない。小さく試して、見てから広げる順番です。

止まる条件は、ターン数や上限として先に置いておく。これが無いと、間違った前提のまま一晩走ってしまう。

4番目の止まる条件を、私は「見ていない間に、AIがどこで自分から止まるか」の線として読みます。

見守ることが「私が見て育つ」から「私が見ないと止まる」に変わった時、自走は自己維持へ反転する。私はそう考えています。止まる条件が無い仕事は、見ていない間も間違った前提のまま進み、最後は私が見つけて戻すことになる。それは自分がいなくても回る形ではなく、私が見ないと止まる形なんですよね。

だから5つの問いは、休暇の前だけの物ではありません。完了の形と止まる条件をAIの側に先に渡しておけば、見ていない時間を、見張りではなく余白として使えます。止まる条件は、AIを縛る線ではなく、私が手を離すための線です。

エージェントを2体、3体と増やしたら、仕事も2倍、3倍になるのでしょうか？ スライド14/17で、まさおさんは並べる数の話に入ります。

エージェントを1体増やすほど、人が見張る手間も増える、とまさおさんは話します。スライドには「オーケストレーション税」というグラフ。数体を超えると、1体増やすごとに要る注意が前より増えていく線です。筆者は普段4〜5体を並行している、とも出ます。

動画では（15:17〜）

その人の注意っていうのも増やせないんでもっと頑張って見る、見張るとかっていうのは、ま、厳しいと。

任せる先として、まさおさんはテストやゴールの条件、会話を見ていない別のレビューを挙げます。見る目を人の側に足すのではなく、確かめる仕掛けの側に足す。

まさおさんは失敗の形も示します。

動画では（15:49〜）

失敗例としてはやっぱレビューしきれないほどのセッションを開いてしまう。

スライドには、測らないのはAIが書いたコードの割合、測るのはPR（変更の取り込みを頼む単位）のサイクルタイム、revert（変更の取り消し）、手戻り、と出ます。

体を増やすと何が起きるか、私には記録があります。2026年10月2日、TikTokで見た組織図をまねて、AIの社員を役割ごとに並べる試しをしました。右腕役のAI1体が、約16分で7件の課題を作り、7人に振り分けています。

残る5人を1回ずつ動かして、成果が出たのは経理役の1人だけ。講座役・LIVE役・X告知役の3人は、何もせずに終わりました。

数をそろえても、それぞれが仕事をちゃんと受け取れたかを確かめる仕掛けが無ければ、成果は数に比例しない。体を増やすと、先に増えるのは確かめる仕事の方なんです。

私なら、体を増やす前に、1体で何をもって成果とするかを先に書きます。成果の形と確かめ方が1体で決まっていれば、増やす時に、確かめる仕掛けも一緒に増やせるからです。

上位から見るとは、結果を支配・監視することではない。結果を手放しながら動きを味わい、気づきと違和感を共進化の燃料として返すこと。これが私の見方です。見張る量を増やすのは、監視の側に立つこと。検証を仕組みに置けば、一段上から動きを見ていられます。

測る物も同じです。スライドの、マージ数を測るなら revert も一緒に、という一言は、数だけを追わないための歯止めになります。体を足すのは、1体で成果を確かめられる形ができてから。並べる数より、確かめる仕掛けの数を先に増やす。私はこの順番で組みます。

作る力が増えると、作らないと決めるほうが難しくなります。スライド15/17は、まさおさんが紹介する10個目の習慣。

エージェントで何でも作れる今、問いそのものが変わった、とまさおさんは話します。

動画では（16:07〜）

問うべきっていうのは作れるかではなくて作るべきなのかっていうところで、ま、マネージャーにとってもね、1番大事な言葉っていうのは多くの場合はノーだということをね

思いつきが、すぐにプルリクエストになる。

すると要らないPRの山を、チームがレビューして保守し続けることになる、とまさおさんは紹介します。スライドには問いが並びます。誰がそれを求めた？ うまくいったと、どう分かる？ 何が起きたらやめる？

添えてあるのは、仕掛かりの量を絞るという一行。同時に抱える作りかけの数を減らして、レビューが追いつく量に保つための一行です。では、いま足りない物は何なのか。

動画では（16:45〜）

今ね、足りないっていうのはやっぱ作る力ではなくて、そのレビューと検証の方

前の章の話と、ここでつながります。

スライドの問いは、どれも作る前に答えられるものです。うまくいったかの物差しを持たない物は、作り終えても良し悪しを決められない。誰が求めたかを言えない物は、使われないまま残りやすい。やめる条件を言えない物は、一度作ると止めどころを失う。3問とも、作る前の関所として使えます。

作る力が余っていて、読む力と確かめる力が足りない。だから作る量を絞る。順番がはっきりしています。

「AIに委ねて、人は積み減らして生き直す」。これが私の原点の言葉です。作らないと決めることは、積み減らすことそのもの。AIで作る力が増えた分、増えるのは自分が読む物と、見続ける物なんですよ。

作る前に、それが手元を軽くするのか、重くするのかを見る。スライドの3問は、その見分け方になります。

動画の「ノー」は、私の言葉に直すと「これは積み減らしになるか、積み増しになるか」という問いになります。積み増しになるだけの物は、作らない側に置く。

10の習慣のあと、動画はたとえの外側へ出ます。スライド16/17に出るのは「エージェント5体を回せても、5人をマネジメントできるわけではない」という一文です。

まさおさんは、マネージャーのたとえが当てはまらない所を紹介します。エージェントはやり直しが気楽で、2〜3案を並べて比べられる。ここは強みです。弱みは、経験を積まないこと。学んだことはメモとして1台のマシンに残るだけで、間違った指示にも従い、人はエージェントを信じすぎる。モデルが替わると、得意不得意も変わります。

人に残る仕事として挙がるのは、人のマネジメント、ジュニアの練習の場づくり、人のチームづくりです。

動画では（17:56〜）

あとはその新人、ま、ジュニアとか若手の練習の場を作るっていうのはやっぱ課題として残ってるなと個人的にも思いますね。

これは、まさおさん自身の感想として語られます。

経験を積まないエージェントの横で、経験を積むのは人の側。そう並べると、練習の場が課題として残るのも分かります。

信じすぎへの対策も、まさおさんは紹介しています。

動画では（18:44〜）

エージェント自身の答えに、え、反論させるみたいなことをやってたりするようです。

信じすぎを、人の気合いで防ぐのではありません。

AIに反対側の声を出させて、人が判断する材料を増やす。最初に出た答えを、そのまま通さないための仕掛けです。

私はAIに頼む仕事の流れを、入口と出口だけ人が持つ形で組んでいます。入口は一次情報で、その場で見たことや、自分の体験と考え。出口は味見と、責任を持って外へ出すところです。

その中間、つまり翻訳する、増やす、媒体ごとに整える所はAIに任せてよい、と考えています。

AIは魂の答えを代わりに決めず、問いのきっかけをつくる。私の核になる答えまでは、AIに決めさせないということです。AIへ教えることが、人間も育てる。これも私の根っこにある考えです。だから反論させる対策は、AIの答えを、私が判断するための問いに変える仕掛けとして受け取ります。

私なら、入口と出口は自分が持ち、中間はAIに任せます。反論させる対策は、その中間に置ける仕掛けとして、動画から持ち帰ります。

まさおさんの解説は、AIエージェントで起きている困りごとを、マネージャーが昔から解いてきた問題として読み直すものでした。

最後のスライド17/17の見出しは、肩書きはいらない、明日からの6つ。走らせられる検査と証拠を求める。エージェントから見えないことを伝え、見えることは省く。コードの前に計画を話す。2回直したら CLAUDE.md へ、繰り返す手順はスキルへ。2回訂正してダメならセッションを捨てる。障害で呼び出される覚悟で diff を読む。まさおさんは、こう締めます。

動画では（20:05〜）

エージェント相手に今日からマネジメントを練習が、ま、できるということで

肩書きが無くても練習できる。ここが、この動画のいちばん背中を押す所でした。

AIにどれだけ任せても、最後に私に残る一手があります。できあがった型の温度を身体で確かめ、出す・止める・任せるの境界を決めること。6つは、どれもこの境界の引き方なんですよ。

本編の動画も観てみてください

この記事は、要点と私の読み方をまとめたものです。オーケストレーション税のグラフ、無人で走らせる前の5つの問い、明日からの6つなど、スライド17枚の図は動画で観たほうが伝わります。約22分で、AIエージェントの悩みはマネジメントの問題、①〜⑩の習慣、人に残る仕事とまとめ、とチャプターで区切られているので、気になる習慣から観られますよ。

まさおさん『プロンプトよりマネジメント』の解説を観る

私の本も置いておきます

『Claudeプロジェクト実践入門　コンテンツマーケティング編』（Kindle）

この記事は、AIエージェントに仕事を渡すことを、任せ方の線を自分で引く練習として読んだものです。

ClaudeのプロジェクトでAIと一緒に仕事を進めたい時に、手に取ってみてください。

Amazonで見る

Amazonアソシエイトのリンクです