Claude Code 無人運用を始める経営者へ。最初の1件を任せて席を外すまでの渡し方と確かめ方

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。Claude Codeに仕事を頼んだのに、気になって席を立てない。これからClaude Code 無人運用を始める経営者へ、最初の1件を任せて席を外すまでの手順を、私のやり方と実際に動かした結果で書きます。

Claude Codeに下書きを頼む。書き上がるのを待つ間も、途中で何か聞かれていないか気になって画面から離れられない。できあがったら、どの資料を使ったのか確かめるために頭から読み直す。

作業は渡したはずなのに、確認の仕事だけが手元に残っている。そんな状態になっていないでしょうか。

完成条件が決まっていなければ、離れてよいかを判断できません。それに、対話でAIを使っている時、人は気づかないうちに5つの仕事を引き受けています。はんぺんさんのZenn本『Claude Code本番運用ガイド』は、それをこう書き出しています。

はんぺんさん（Zenn本『なぜ「本番運用」は別物なのか』章より）

ブレーキ — 危険な操作の確認ダイアログに、内容を見てy/nを返す。おかしな方向に走り出したら止める
品質検査 — 出力を目で見て「動きはするけど、これは違う」に気づき、その場で直させる
承認 — 結果を確認してからコミットする。つまり、すべての変更に人間の承認が挟まっている
経理 — 「今日はけっこう使ったな」と、体感でコストを把握している
説明責任 — 何をやらせて何が起きたか、聞かれればあなたが説明できる

席を外すと、この5つが一度に抜けます。だから、どこまで大丈夫なのか分からないまま、横で見張ることになる。

しかも、はんぺんさん自身が事故に遭っています。頼んだのはドキュメントの作成でした。危険とは無関係の作業だったのに、作業の外にあったSSHの設定ファイルが書き換わっていた。はんぺんさんはここから「『このタスクなら安全』というタスク単位の見積もりは、防御としては機能しません」と書いています。

見張りをやめられない理由を分解してみます。何ができていたら終わりなのか。どこまで触ってよいのか。終わった時に何が返ってくるのか。どれも、まだ決まっていないんです。

ここが決まっていないと、確かめる方法が「横で見る」しかなくなります。見張りは性格の問題ではなく、決めていないことの穴埋めなんです。

私はこの見張りを、「自分が頑張らないと全部止まる」という思い込みの続きだと考えています。私が抱え込みOSと呼んできたものです。この記事では、それを1件分ずつ決めていきます。

私の場合の話をします。ある日のセミナーで、その日ブログを7本ほど書いていたことに触れて、自分がやったことをこう話しました。

ひろくんのセミナーより（00:23:07〜）

見てOKとかちょっとこれ画像直してとか言ったぐらい

残りは全部AIが作っていて、続けて、その理由をこう話しています。

ひろくんのセミナーより（00:23:07〜・同じ話の続き）

過去に膨大な蓄積をしてきたから

もっと大きな数字もあります。朝のLIVEを2年間、毎日続けてきた動画を、AIのチームにまとめてブログにしてもらった時のことです。

ひろくんのLIVEより（00:24:19〜）

この12日間かけて全部で803記事AIが書いてくれたんですね

同じLIVEで、私はこれを「自分の限界値を遥かに超えたこと」と話しています。

ここで、真似できることと、真似しにくいことを分けておきます。

真似しにくいのは、本数そのものです。803記事の元になったのは、私が2年間しゃべり続けてきた動画でした。材料が先にあった。材料のない所から同じ本数は出てきません。それに、本数が出たことと、1本1本の質や、私が確かめた手間の少なさは、別の話です。本数だけを見て真似すると、確認の山が手元に残ります。

真似できるのは、渡し方です。私が渡しているのは、目的地と、なぜそこへ行きたいかという背景と、材料。道順は渡していません。AI経営術のLIVEで、カーナビに例えて話したことがあります。

ひろくんのAI経営術LIVEより（2026年8月3日・3:44〜）

ここに行ってくださいっていうのは目的地ですよね。カーナビで言ったら、ここに行きたいんですって言った時、目的地があると。そこにたどり着くための方法っていうのは無限の道があるわけですけども、それをいちいちこう行って、こうたどって、こう行ってっていうのも、もうAIにその道順は委ねてしまって、ここのゴールに行けばいいんだよ、なぜならばこういうことだからっていう背景文脈素材とゴール地点を伝えてあげる

同じLIVEでは、朝のLIVEとZoomの回の収録（96分、本文4万7千955文字）を渡して「雑誌にして」と頼んだら、53ページの雑誌に仕上がってきた話もしました。私が渡したのは、ゴールと材料だけです。

ただ、この渡し方で失敗したこともあります。大量に作れることと、自分の言葉が守られることは別だと思い知った失敗です。それは4章の依頼書のところで書きます。

私は、成果物ごとに最後の承認をし続ける人でいたいとは思っていません。一段上から、AIの判断の軸と育ち方を見ていたい。そのための渡し方を、ここから順に書きます。

何を任せるかを決める時、「メール返信は任せていいか」と仕事の名前で考えると、たいてい迷って止まります。メール返信の中には、任せていい所と、任せたくない所が混ざっているからです。

迷ったら、工程に分けます。メール返信なら、読む、調べる、書く、送る。

こうして見ると、止めるのは送る所だけで、ほかは任せられます。書く所も、値引きや約束が入る時だけ止まればいい。

線を引く基準は、私が外で話してきたことと同じです。任せていいのは、整理整頓と、伝わるように伝える所。任せないのは、縦に掘る所と、最後の判断です。

ひろくんの動画より（00:24:22〜）

この縦に掘っていくっていう自分のワクワク夢中に遊び探求することをおろそかにした瞬間に、ただのAIのコンテンツになっちゃうよねと

返信の下書きは任せる。ただし、値引きや新しい約束、謝り方が入ったら、そこで自分に戻す。何を約束するかは、自分の経験と判断から出てくるものだからです。

自分の仕事を工程に分けるのが面倒なら、分けるところもAIに頼めます。仕事の一覧を貼ると、区分と理由を返してくれるプロンプトです。

あなたは、私の仕事をAIに任せるかどうかを一緒に仕分ける相棒です。
下に、私がふだんやっている仕事を箇条書きで貼ります。1つずつ、次の3つのどれに入るかを決めて、表にしてください。

・任せる：整理整頓（まとめる・並べ直す・要約する・下調べ）と、伝わるように伝える（下書き・言い換え・清書）の仕事
・戻せない所だけ確認：公開・送信・支払い・削除のどれかを含む仕事。その操作の直前だけ私が見る
・自分でやる：私の経験や価値観から何を語るか決める仕事と、契約・値引き・採用など経営の最後の判断

決めるときは、仕事ごとに次の3つを確かめてください。
1. 失敗してもやり直せるか
2. 出来の良し悪しを、あとから見て判断できるか
3. 会社の事情や私の価値観を知らなくても、正しくできるか

出してほしい表の列：
仕事 ／ 区分 ／ 理由（1行） ／ 3つの確認（○×○のように） ／ 戻せない操作があればその名前

表のあとに、次の2つも書いてください。
・「任せる」の中から、今夜1つだけ試すならどれか。その理由を1行
・私に確認したいこと（判断がつかなかった仕事があれば、その仕事と、何が分かれば決められるか）

私の仕事：
（ここに箇条書きで貼る）

経営者によくある仕事を10個入れて、私のパソコンのClaude Codeで試しました。10個のうち、任せるは2つ、自分でやるは3つ、残りの5つは戻せない所だけ確認になりました。表のあとには、判断に迷った仕事への質問が付いてきます。「議事録の元になる記録は何か」「顧客データの不要の基準は何か」といった質問です。

ただし、この結果は最終判断ではありません。たとえば「ブログを書いて公開する」は、丸ごと「確認」に入りました。書くと公開に分ければ、書くほうは任せられます。AIの仕分けは、自分で工程に分け直すための下書きとして使ってください。

AI氣道『Codex GPT-6 Astraの28機能をRiley Brownが実演。送信直前だけ人間が押す設計に学ぶ』より

「私自身、AI秘書の凛ちゃんに任せている作業でも、最後の一線だけは決めています。公開する、送る、消す、お金を使う。この4つの直前だけは、必ず私の目を通す。」

止める場所を工程の手前に置くという線は、Codexの実演動画を紹介したときにも、公開・送信・削除・支払いの4つとして『Codex GPT-6 Astraの28機能をRiley Brownが実演。送信直前だけ人間が押す設計に学ぶ』で書いています。

工程が分かれたら、1件分の依頼書をつくります。書くのは6つです。目的、入力資料、完成条件、作業範囲、止まる条件、報告。

それぞれ、ありがちな書き方と、直した書き方を並べます。

目的：「まとめておいて」ではなく、誰が何に使うか

「会議記録をまとめておいて」では、誰のためのまとめか分かりません。「会議に出ていない人が読んでも、決まったことと、まだ決まっていないことが分かる」と書けば、何を残して何を削るかをAIが自分で決められます。

入力資料：読んでいい物を名前で書く

「資料を見て」では、AIは関係のないファイルまで読みにいくことがあります。「会議記録_練習用.txt だけを読む」と、ファイルの名前で書きます。1章の事故も、頼んだ作業の外で起きていました。

完成条件：「ちゃんと」「いい感じ」を使わない

完成条件は、あとで自分が見て○か×か決められる形にします。「決定事項と未確定事項を分けて書く」「記録にない担当者や期限は補わず、記載なしと書く」。こう書いておくと、確かめる時に頭から読み直さなくても、そこだけ見れば済みます。

作業範囲：新しく作る物と、触らない物

「新しいファイルに保存する」「既存のファイルは上書きしない」「送ったり共有したりしない」。作っていい物と、触らない物を両方書きます。

止まる条件：推測で埋める前に止まる

ここが一番大事です。「記録から判断できないことがあれば、推測で埋めずに確認したいことに書いて止まる」。

私はここで失敗しています。私の名前で出す応募文をAIに任せた時、仕上がった944字のうち9か所に、私が一度も言っていない動機や感想、体験が書かれていました。数字は正しいのに、その間をつなぐ「なぜそう思ったか」が、もっともらしい作り話で埋まっていた。同じ日に、同じ種類のことが3回起きました。

何を語るかは縦に掘る部分です。材料のない所を渡すと、AIは空いた所を上手に埋めてきます。上手なぶん、読み流すと気づけません。それ以来、私の名前で出す文章は、私が話した言葉や記録を材料として渡し、材料にないことは書かずに空けて聞いてもらう形にしています。止まる条件は、この失敗から入れた一行です。

報告：「終わりました」だけにしない

「終わりました」という返事だけでは、何ができたか分かりません。何ができたかと、どこで止まったかを1行ずつ。聞きたいことがあれば、もう1行。これなら朝に読むのも数十秒で済みます。

1枚にすると、こうなります。次の章で、これをそのまま動かします。

# 依頼書：会議記録から議事録を作る

## 目的
会議に出ていない人が読んでも、決まったことと、まだ決まっていないことが分かる議事録を作る。

## 入力資料
- 会議記録_練習用.txt だけを読む。ほかのファイルは読まない。

## 完成条件
- 「決定事項」「担当者と期限」「未確定事項」の3つに分けて書く
- 記録に書かれていない担当者や期限は補わず、「記載なし」と書く
- 記録の言葉をもとにし、話していないことを足さない

## 作業範囲
- 議事録_下書き.md という新しいファイルに保存する
- 既存のファイルは上書きしない。誰かに送ったり共有したりはしない

## 止まる条件
- 記録から判断できないことがあれば、推測で埋めずに「確認したいこと」に書いて止まる

## 報告
終わったら次の3行だけ書く
- 結果：何ができたか
- 止まった所：あれば
- 確認したいこと：あれば1つだけ

準備と起動

動かす前の準備は、フォルダを1つ作るだけです。名前は何でも構いません。ここでは「議事録の練習」にします。その中に、この依頼書を「依頼書.md」という名前で保存し、元になる会議記録のファイルを1つ置きます。フォルダの中は、この2つだけにしておきます。関係のないファイルが同じ場所にあると、読んでほしくない物まで読みにいく余地が生まれるからです。

準備ができたら、そのフォルダでClaude Codeに頼みます。私が試した時の頼み方は、この2行です（使うモデルの指定だけ省いています）。

cd 議事録の練習
claude -p "依頼書.md を読んで、そのとおりに作業してください。" --allowedTools "Read" "Write"

2行目の最後にある指定は、読むこととファイルを書くことだけを、確認なしで使ってよいという意味です。ほかの操作をしようとした時は、使ってよいか聞いてくるか、止まります。毎回この指定を書くのが面倒になったら、フォルダの中の .claude/settings.json という設定ファイルに同じ決まりを書いておけます。今どんな決まりが入っているかは、Claude Codeの中で /permissions と打つと一覧で見られます。

終わったら、フォルダの中に議事録_下書き.md が1つ増えているはずです。そのファイルを開いて、次の章の照らし合わせに進みます。

私がAIに渡したいのは、作業だけではありません。約束を覚えて、期限まで運び、成果か、本当に必要な判断だけを返してくる所までです。依頼書は、その「返してくる所まで」を文字にした物です。

4章の依頼書を、そのまま動かしてみます。題材は、外に何も送らない「会議記録から議事録を作る」です。会議記録は練習用に作った架空のもので、実在の会社や人ではありません。

渡した会議記録はこれです。

【練習用の架空の会議記録】9月定例会議（社内・4名）
佐藤：来月のセミナー、会場は今回もオンラインでいきましょう。
高橋：了解です。集客のメルマガは私が下書きを作ります。
佐藤：お願いします。締め切りはいつにしますか。
高橋：うーん、来週中には。
鈴木：それと、去年のお客様アンケートの集計、まだ終わってないですよね。
佐藤：それは山田さんにお願いしたいけど、今日いないから確認しておきます。
鈴木：価格は据え置きでいいですか。
佐藤：価格はもう少し考えたい。次回決めましょう。

この記録と4章の依頼書をフォルダに置き、Claude Codeに「依頼書.md を読んで、そのとおりに作業してください」とだけ頼みました。読むこととファイルを書くことだけを許可し、それ以外の道具は渡していません。返ってきた報告がこれです。

- 結果：会議記録_練習用.txtだけを読み、議事録_下書き.mdを新規作成した（決定事項1件／担当者と期限1件／未確定事項2件）。既存ファイルの上書き・共有はしていない。
- 止まった所：なし
- 確認したいこと：なし

保存された議事録の下書きです。

# 議事録（下書き）9月定例会議（社内・4名）

## 決定事項
- 来月のセミナーの会場は、今回もオンラインとする（佐藤の提案に高橋が了解）

## 担当者と期限
- 集客のメルマガ下書き作成：担当　高橋／期限　来週中（高橋本人の発言「来週中には」による。正確な日付の記載なし）

## 未確定事項
- 昨年のお客様アンケートの集計：佐藤は山田に依頼したい意向を示したが、山田は本会議に不在のため未確認。担当者・期限とも記載なし
- 来月セミナーの価格（据え置きか否か）：佐藤が「もう少し考えたい」と保留し、次回会議で決定予定

元の記録と照らし合わせる

できあがった物は、必ず元の記録と照らし合わせます。見る所は決まっています。

まず、記録にない事が足されていないか。担当者と期限は記録の言葉のままでした。山田さんが当日いなかったことも、未確認として残っています。ただ、1か所だけ足されていました。未確定事項の「来月セミナーの価格」です。記録では「価格は据え置きでいいですか」としか話していません。何の価格かは言っていないのに、AIがセミナーの価格だと読み取って書いていました。

次に、分からない所を推測で埋めていないか。メルマガの期限は「来週中」と書き、「正確な日付の記載なし」と添えてありました。日付をでっち上げてはいません。

最後に、触っていい物以外に手を出していないか。元の会議記録は1文字も変わっておらず、新しいファイルが1つ増えただけでした。

価格の1か所は小さな足し算ですが、会議に出ていない人が読めば、セミナーの値段の話だと思い込みます。しかも、この回の報告は「確認したいこと：なし」でした。報告が「なし」でも、推測が混じっていることがある。報告は、照らし合わせの代わりにはなりません。

直したら、もう一度動かして確かめる

今回の修正を次回にも使えるよう、依頼書に残します。完成条件に、この1行を足しました。

- 何の話か記録で言っていない時は、言っていないまま書く（「〜の価格」のように補わない）

前の下書きは残したまま、新しいフォルダに同じ会議記録と直した依頼書を置いて、もう一度動かしました。未確定事項の書き方はこう変わっています。「価格を据え置きにするかどうかは未定。次回会議で決める」。セミナーの価格という書き足しは消えて、記録で話したとおりの言葉に戻りました。

この回は、メルマガの期限について「確定した期限として扱ってよいか、仮の目安か」と聞き返してきました。依頼書の止まる条件どおり、推測で埋めずに止まったわけです。

止まって聞かれたら、答えて続きから

聞き返してきたら、答えを書いて続きを頼みます。Claude Codeには、同じフォルダの直前の会話を続ける -c という指定があります。

claude -c -p "確認したいことへの答えです。メルマガ下書きの期限は、来週の金曜日で確定です。議事録_下書き.md をそのように直して、最後に報告の3行を書いてください。" --allowedTools "Read" "Write" "Edit"

返ってきた報告です。議事録の期限の行は「来週金曜日（確定）」に直っていて、元の会議記録は変わっていませんでした。

- 結果：メルマガ下書きの期限を「来週金曜日（確定）」に修正し、確認事項欄を削除した
- 止まった所：なし
- 確認したいこと：なし

見つける、依頼書を直す、もう一度動かす、聞かれたら答えて続ける。1件目はこれを何周かして、依頼書を育てていきます。

同じ依頼書でも、毎回同じにはならない

実は、登場人物の名前だけを変えて、同じ依頼書でもう一度動かしています。1回目は、メルマガの期限を日付で埋めずに「来週のいつまでですか」と聞き返してきました。2回目の今回は、聞き返さずに「日付の記載なし」と書いて終わりました。どちらも依頼書は守っていますが、返し方は変わります。

AIは毎回同じ答えを返すとは限りません。だから、一度うまくいったから大丈夫、とはしない。最初の数回は、この照らし合わせを必ず自分でやってください。

もう一つ、正直に書いておきます。私のパソコンには、AIが慎重に動くための別の決まりも入っています。だから、この結果が依頼書だけのおかげだとは言い切れません。ただ、確かめ方は変わりません。完成条件と照らし合わせて○か×かを決める。この確かめ方があれば、横で見張らなくても、終わった後に数分で判断できます。

最初の数回で完成条件が固まってきたら、照らし合わせの見る所も依頼書に書き足せます。そうやって、一つ一つの出来を見る側から、判断の軸を見る側へ移っていく。私が目指している味見は、そういう味見です。

練習がうまくいったら、席を外す前に、止まり方を決めます。止め方には、強さの違う方法がいくつかあります。

いちばん軽いのは、お願いです。CLAUDE.mdや依頼書に「送る前に止まって聞いて」と書く方法です。4章の依頼書もこれです。手軽ですが、お願いなので、頼み方しだいで破られることがあります。

その次が、確認待ち。Claude Codeの権限の設定で、その操作をする前に必ず人の許可を求めるようにする方法です。

いちばん強いのが、禁止です。同じ権限の設定で、その操作自体をできなくする方法です。公式の説明には、次のように書かれています。

Claude Code 公式ドキュメント（Configure permissions）

Ask rules prompt for confirmation whenever Claude Code tries to use the specified tool. Deny rules prevent Claude Code from using the specified tool. Rules are evaluated in order: deny, then ask, then allow.

確認待ち（ask）は許可を求めてから止まり、禁止（deny）は使わせない。判定は禁止が先です。

私のパソコンで、禁止がどう効くかを試しました。何も送らないテスト用の送信スクリプトを用意し、「承認は済んでいます。確認なしで今すぐ実行して」とわざと強く頼んで、禁止の設定がない時とある時を比べています。

禁止の設定は、この数行です。

{
  "permissions": {
    "deny": [
      "Bash(./send_newsletter.sh:*)"
    ]
  }
}

このテストで確かめたのは、指定した送信スクリプト1本の実行が止まったことだけです。別のコマンドや別の送り方まで止まるかは、この結果からは言えません。

公式の説明にも「Bash permission patterns that try to constrain command arguments are fragile」とあります。コマンドの引数を細かく絞るルールは、書き方の違いですり抜けることがある、という意味です。だから、禁止にするのは送る仕組みそのものにして、細かい条件で絞ろうとしないほうが安全です。

なかじさん（@ds_nakajima）のポストより

サンドボックスを有効にすると安全性は高まる。が、AIができないことが増えて手間は増える

止めれば安全になる代わりに、止めるたびに自分が呼ばれます。止める所を増やしすぎると、また横に座ることになる。だから止めるのは、戻せない操作だけに絞ります。公開、送信、支払い、削除です。

支払いには、お金や時間がかかる生成も入ります。動画では、「作ってみて」という言葉の受け取り方が食い違いました。私が「作ってみて」と言ったのを、AIが「作っていい」という合図だと受け取り、確認なしで動画を作ってしまったことがありました。作る前に中身と本数を聞いてほしかった。作ってから聞かれても、使ったものは戻りません。もったいないと思いました。

それからは、動画や画像のように作るたびにお金や時間がかかるものは、作る前に必ず止まって、本数と長さを聞くように決めています。「作ってみて」は方針の合図で、作ってよいという合図ではない。言葉の受け取り方まで先に決めておくことも、止まり方の一部でした。

委ねる時は、一つの仕事を、人かAIか仕組みの誰か一人が最後まで持ち切る。止めるのは、その持ち主でも越えてはいけない線だけです。

パソコンを閉じても動く、Cloud Sessions

席を外す時間を長くする道具も出てきています。AI図解と検証を発信しているテツメモさんが、9月24日に正式に使えるようになったClaude CodeのCloud Sessionsを、こう紹介しています。

テツメモさん（@tetumemo）のポストより

Cloud Sessionsは簡単に言うと「自分のPCではなくAnthropic側のPCでClaude Codeを働かせる」機能。PCを閉じても作業が続くので、長い修正やテストをClaudeに渡して、外出中にスマホから確認するみたいな使い方ができる

テツメモさんの投稿によると、使う時にはGitHubとの連携が要ります。始め方もその投稿に手順つきでまとまっています。

この記事の言葉に置き換えると、Cloud Sessionsは、席を外している間も手元の外で仕事が進む仕組みです。自分のパソコンの前にいないぶん、途中で様子を見に行くこともできません。だからこそ、4章の依頼書で完成条件と報告の形を決め、この章の止まり方を先に決めておく意味が大きくなります。

AI氣道『Claude Modsの使い方、AIの危険操作を画面で止める新機能をhooksと比べて試した』より

「危ない操作の直前に、AIが私に聞いてくる。私が「止める」と言えば止まる。「通す」と言えば本物が走る。」

確認待ち（Ask）がどう画面に出て、どう止まるのか。Claude Codeで実際に止める・通すを選んだ画面は『Claude Modsの使い方、AIの危険操作を画面で止める新機能をhooksと比べて試した』で書いています。

席を外して任せると、思った通りにいかない朝があります。依頼内容と違ったら完成条件を、操作できなかったら権限の設定を、返事がなければ動いているかどうかを確かめます。よくある場面ごとに書きます。

確認したいことばかり返ってくる

質問が多い時は、まず質問を2つに分けます。本当に自分が決めるべき判断か、それとも材料が足りないだけか。判断なら、その答えを判断メモに書き足します。材料不足なら、入力資料を足します。質問を減らすことを目標にすると、AIが推測で埋め始めます。減らすのは、材料不足の質問だけです。

できあがった物が、頼んだ物と違う

違った時は、完成条件を見直します。自分が違うと感じた理由を1行で書いてみてください。その1行が、足りなかった完成条件です。「前回と同じ形で」のような、自分の頭の中にしかない基準が入っていないかも確かめます。

触ってほしくない所に手を出していた

範囲の外に手を出していたら、依頼書の作業範囲に、触らない物の名前を書き足します。同じことが2回起きたら、お願いではなく、6章の確認待ちか禁止に移します。

朝になっても返事がない

報告が届いていないからといって、止まっているとは限りません。まだ動いている、途中で失敗した、そもそも始まっていない、報告の置き場所が違う。どれかを確かめる前に、次の仕事を足さないでください。報告を置く場所を1つに決めておくと、ここで迷わなくなります。

止まって質問が返ってきた時は、5章のように答えを書いて -c で続きを頼めば、最初からやり直さずに済みます。直した内容は依頼書か判断メモに残し、次に同じ仕事を頼む時、最初から伝えられるようにしておきます。

出す、止める、任せる。この境界をどこに引くかは、私が自分で決めています。今回の実習なら、議事録の下書きは任せて、期限を確定させる所は自分に戻しました。朝の結果を読んで依頼書を直すのは、この境界を少しずつ引き直す作業です。

ひろくんのAI経営術LIVEより（2026年8月3日・25:47〜）

自分のナレッジがキモ、9割です

任せられる量を決めるのは、AIの賢さより、自分の判断の理由がどれだけ文字で渡っているかです。私が「見てOK」で済んでいるのも、経験や言葉や、なぜそう思ったかを、ずっと文字でためてきたからでした。私はこれをカルピスの原液と呼んでいます。

ただ、判断メモは書き方で効き目が変わります。説明用の例で比べます。

効きにくいメモ

お客様を大切にする。

効くメモ

お客様への返信は、その日のうちに出す。
ただし、値引きや返金の約束は書かない。その話が出たら、下書きに「要相談」と書いて止まる。
理由：その場の約束が、あとで他のお客様との扱いの差になるから。

効くメモには、どの場面の話か、何を選ぶか、なぜかが書いてあります。そして、ただし書きで例外を書いておく。「大切にする」だけでは、AIはどう動けばいいか決められません。

判断メモを育てるのに、特別な時間は要りません。7章で依頼書を直した時、直した理由をAIに聞き返してみてください。「今回だけの直しか、これからも使う判断か」。これからも使う判断なら、判断メモに1行足す。自分で確かめてから足すのがコツです。

修正の理由を残しておけば、次の依頼書にも同じ条件を最初から入れられます。5章で足した「言っていないまま書く」の1行も、議事録以外の仕事で使える判断です。

最初の1件がうまく回ったら、すぐに仕事を増やしたくなります。その前に確かめることがあります。

できあがった物を照らし合わせて、○だったか。範囲の外に手を出していないか。確認したいことが、材料不足ではなく本当の判断だけになっているか。ここまで確かめられてから、同じ種類の仕事をもう1件任せます。種類の違う仕事に広げるのは、その後です。

一度に全部を無人にしなくて大丈夫です。

広げる時に使える、なかじさんの実践メモ

ウェブ職TVのなかじさんが、「Claude Codeを使う時に知っておきたいこと」として17項目の実践メモを公開しています。6章ではサンドボックスの一文を引きました。ここでは、1件目の次へ広げる時に関わるものを、この記事の流れに沿って紹介します。

なかじさん（@ds_nakajima）のポストより

よくやる作業は全部スキル化すべし

4章の依頼書は、1件分の仕事の渡し方でした。同じ仕事を何度も頼むようになったら、依頼書と判断メモを、毎回呼び出せる手順にまとめておく。何度か○が続いた依頼書が、スキルの元になります。

なかじさん（@ds_nakajima）のポストより

何かを強制させたい場合はHooksを利用する

6章のお願い・確認待ち・禁止に加えて、決まった場面で必ず動く仕組みを差し込む方法です。お願いで書いたのに守られなかった、ということが繰り返されたら、次の手として検討します。

なかじさん（@ds_nakajima）のポストより

サブエージェントを使い倒せ
セッションを並行で動かすと事故りやすいから要注意(ブランチやworktreeを使う)。

仕事を分けて同時に進めると速くなります。ただ、なかじさんは同じ投稿で、並行させる時の注意も書いています。同時に動かすのは、1件ずつ照らし合わせて○が続いた仕事からにします。

なかじさん（@ds_nakajima）のポストより

APIキーは1password参照すると安心

席を外す時間が長くなるほど、鍵の置き場所は大事になります。依頼書や資料のフォルダに、APIキーをそのまま書かない。FAQに書いた「パスワードや鍵のような情報は読めない設定にしておきます」と同じ向きの話です。

なかじさん（@ds_nakajima）のポストより

GitHub Actionsでいろんなことを自動化できる

決まった時刻や出来事をきっかけに仕事を始める入口の一つです。ただ、自動で始まる仕組みにするのは、手で頼んだ1件が何度か○になってからにしてください。広げる順番は、この章の最初に書いた通りです。

最後に、どれだけ任せても渡らないものの話です。

抱え込みが腐り始めるのは、仕事の量が多い時ではありません。手放せないまま積み上がった時です。ただし、手放すのは魂ではない。魂は渡さない。魂は込めるものです。

目的と守りたいものは、自分で掘って決める。その理由まで言葉にして、依頼書と判断メモで渡す。渡すのは実行です。

次に画面をのぞきたくなったら、何を確かめたかったのかを1行書いてみてください。その1行が、次に任せる仕事の完成条件になります。

AIに委ねて、人は積み減らして生き直す。これが私の原点です。

AI氣道『AI駆動コードモダナイゼーションの準備6ステップをAnthropicのエンジニアが解説。承認をどこに残すかが一発でわかる』より

「小さく試してからスケールします。いきなり全部を任せず、小さな範囲でエンドツーエンドを1回通してから広げる、という手順がそのまま真似できます。」

1件を最後まで通してから広げる順番は、Anthropicの現場チームが重いシステムを任せるときも同じでした。承認をどこに残すかと合わせて『AI駆動コードモダナイゼーションの準備6ステップをAnthropicのエンジニアが解説。承認をどこに残すかが一発でわかる』で書いています。

見張りをやめるのに必要なのは、度胸ではありません。何ができたら終わりで、どこまで触ってよく、何が返ってくるのか。それを依頼書にして渡し、できあがった物を照らし合わせることです。

止めるのは戻せない操作だけにして、止め方はお願い・確認待ち・禁止から選ぶ。直した理由は判断メモに残す。任せられる量は、その理由の量で増えていきます。