深夜1時。画面に「このコマンドを許可しますか？」が出ている。何回目かはもう数えていない。内容をろくに読まずにYを押した。
まずいな、と思ったのは翌朝だった。承認疲れ、というやつだと思う。数が多すぎて、僕は一つひとつを読むのをやめていた。全部を確認するのは、何も確認していないのと同じだ。
だから減らした。減らして、そのあとに「じゃあ、どこに残すのか」を考え直した。この記事は後半の話が中心だけど、前半（減らし方）にもちゃんと答えます。そこを飛ばして設計論だけ語られても困るので。
まず、承認は普通に減らせる
Claude Codeの承認プロンプトは、設定ファイルに許可ルールを書けば出なくなる。プロジェクト直下の `.claude/settings.json` に、こう書く。
{
"permissions": {
"allow": [
"PowerShell(Get-ChildItem *)",
"PowerShell(Get-Content *)",
"PowerShell(Test-Path *)",
"PowerShell(Select-String *)",
"Read(./src/**)"
]
}
}書式は `ツール名(パターン)` で、`*` が使える。対話中に許可ダイアログが出たときも、その場で「今後は聞かない」を選べば同じことが起きる。
コツは、読み取り系をまとめて許可に入れること。ファイルを見る、探す、存在を確認する。この手の操作は何回やっても何も壊れないので、ここで止められる意味がない。
僕の場合、読み取り系を許可に入れた時点でプロンプトの大半が消えた。残ったのは「書く」「消す」「外に出す」の3種類だけ。ここまでは、他の記事に書いてあることとだいたい同じだと思う。
そして、その先に `–dangerously-skip-permissions` がある。全部許可。名前からして脅してくる。
「全部許可」にした日、僕がやめたのは確認だった
全自動が怖い理由として語られるのは、だいたい「AIが暴走したらどうする」だ。
でも、僕が実際に踏んだのはそっちじゃなかった。
たとえばWindowsで動かすスクリプトが、BOMなしで生成されて実行が壊れたことがある。原因が分かるまで小一時間、なんで動かないんだと画面をにらんでいた。別の日には、退避したはずの古い定義ファイルが残っていて、機械がそっちを読みに行きかけた。中身が数ヶ月前の内容だったので、気づかずに進んでいたら判断の前提ごと古くなっていた。
どちらも、やり直せた。ファイルを直せば終わりだし、参照先を切り替えれば済む。だから正直、そこまで怖くない。
怖いのは、このやり直せる失敗と、やり直せない操作が、同じ承認プロンプトの列に並んでいることのほうだ。10回続けて「ファイルを書き換えていいか」を聞かれたあと、11回目に「この注文を出していいか」が来る。10回Yを押した指は、11回目もYを押す。
減らすだけの設計だと、この11回目が消える。
判断基準は1つでいい — 「その操作は、取り消せるか」
線をどこに引くかで迷ったら、僕は毎回これに戻る。
> その操作は、あとから取り消せるか？
下書きの生成は何度失敗してもやり直せる。可逆だ。境界は要らない。株の売買は取り消せない。不可逆だ。境界が要る。
微妙に見えるのが「公開」で、これは判定を間違えやすい。記事は消せるし、投稿も削除できる。技術的には取り消せる。でも一度読まれた文章は「なかったこと」にはできない。だから不可逆側に倒す。
整理するとこうなる。
| 操作 | 取り消せるか | 承認 |
|---|---|---|
| ファイルの読み取り・検索 | 何も変わらない | 不要 |
| 下書きの生成・書き換え | 取り消せる（履歴・バックアップ） | 不要 |
| ローカルでの計算・スクリプト実行 | だいたい取り消せる | 不要 |
| 文章を世に出す | 読まれた事実は消えない | 要 |
| 商品の出品・仕入れ | 金が動く | 要 |
| 株の売買 | 取り消せない | ゲートを置かない |
やり直せる工程は自動化してどんどん回す。やり直せない工程の前には、人間の確認を置く。製造業の設計だと当たり前にやっていることで、僕は本業で毎日この考え方を使っている。なぜか個人のAI活用になると、この当たり前がまるごと抜け落ちる。
僕が残した線は5本だけ
エージェントは15体動かしている。投資の監視から、リサーチ、下書きの準備まで。それに対して、線は5本しか引いていない。
① 株の売買 — ここは承認ゲートですらない
正確に書く。投資の売買は「承認したら機械が実行する」ゲートではない。機械に発注する経路そのものを作っていない。 証券会社につなげば技術的には売買させられるけれど、つないでいない。
エージェントにできるのは、価格を取ってきて、損切りラインとの乖離を計算して、僕のスマホに通知するところまで。発注は100%僕が自分の手でやる。ゲートが「押せば進む扉」だとすると、ここは扉のない壁だ。5本のうちいちばん硬い。
② 文章を世に出す操作
下書き・レビュー・修正までは自動で回る。公開ボタンだけ、僕が押す。
③ 出品の公開と、仕入れ
物販は在庫を持った瞬間に金が減りうる。出品の下書きまでは自動で、公開の手前で止まる。
④ エージェント自身の定義ファイルの書き換え
これは説明が要る。うちのチームは自分の実行結果を記録して、「この定義をこう直したい」と提案してくる。提案までは自動、反映は僕の承認後。
自分で自分のルールを書き換えられる機械は、放っておくと自分に都合よく緩くなる。ここを開けたら、他の4本の意味がなくなる。
逆に言うと、この4本以外は全部自動で進む。読み取り、計算、比較、下書き、通知。ここまでは全部エージェントの仕事だ。夜のうちに勝手に調べて、朝には判断材料が揃っている。ここは正直すげーと思う。
境界を絞っているから、僕の仕事は「承認するかどうかの判断」だけに圧縮される。平日1時間しか触れない兼業には、これがいちばん効いた。
5本目は承認じゃない — 「止まらなくなる」ほうを止める
残る1本は性質が違う。人間の承認ではなく、機械が止まらなくなるのを防ぐ上限値だ。
記事の下書きは、レビュー担当のエージェントが採点して、点が低ければ書き直しに差し戻す仕組みになっている。放っておくと、書く側と直す側が延々とやりとりを続けうる。だから再レビューは1本につき2回まで、と決めてある。それを超えたら機械の中で回さずに、僕に判断が上がってくる。
自動化の失敗は「動かない」より「止まらない」ほうが怖い。 動かなければ気づくが、止まらないものは裏で走り続ける。ここも本業のフェイルセーフ設計と同じで、正常系より異常系の設計に時間を使うべきところだと思っている。
不可逆な操作は、人間のほうがミスる
今月の半ば、一度切った銘柄に押し目で入り直そうとして、僕は注文の種別を間違えた。逆指値で置くつもりが指値で出してしまい、意図していない位置で即約定。その1回で約18万円が消えた。
制御設計を10年やってきて、変更点に潜むリスクを事前に潰す側にいる人間が、自分の証券口座で発注種別を取り違える。
これは「機械は間違えるが人間は間違えない」という話じゃない。逆で、どちらも間違える前提でフェイルセーフを先に置く、という話だ。承認を1枚挟んだところで、その人間（僕）は寝不足の朝に注文種別を取り違える。
30代の半ばで、働き方そのものに行き詰まった時期がある。意志で乗り切ろうとして、乗り切れなかった。それ以来、僕は「気をつける」で解決する設計を信用していない。気をつけて直るなら、そもそも困っていない。
だから、承認の手前に「そもそも一発では実行できない構造」を置く。損切りも同じ考え方で、僕は事前に逆指値を置く。判断力が落ちている瞬間の自分を、あてにしない。この考え方の実装は損切りを逆指値で「仕組み」にする方法に書きました。
実装 — 設定ファイルとHooksで線を固定する
考え方だけだと運用に落ちないので、実際の書き方を置いておく。
ルールは3つのファイルに分かれている
| ファイル | 置き場所 | 性格 |
|---|---|---|
| `~/.claude/settings.json` | ホーム | 自分の全プロジェクト共通 |
| `.claude/settings.json` | プロジェクト直下 | チームで共有する前提（Gitに乗る） |
| `.claude/settings.local.json` | プロジェクト直下 | 自分専用（Git管理外） |
権限ルールはこれらをマージして効く。上書きではない。
そして、ここが肝心なところ。
> 優先順位は deny > ask > allow。
denyに書いたものは、allowに何が書いてあっても通らない。境界を固定したいなら、allowを削るんじゃなくてdenyに書く。
deny に書く
僕がホーム側のファイルに置いているのは、たとえばこれだけ。
{
"permissions": {
"deny": [
"Bash(rm -rf /*)",
"Bash(rm -rf ~*)"
]
}
}地味だけど、これはallowをどれだけ広げても効き続ける。「うっかり全部許可にした未来の自分」への保険になっている。
`ask` も同じ書式で使える。allowで自動化しつつ、特定のパターンだけ毎回確認したいときはここに入れる。
条件つきで止めたいならHooks
設定ファイルのルールは「このツールのこのパターン」までしか見ない。もっと細かい条件で止めたいなら、Hooksを使う。ツールが実行される前に自前のスクリプトを挟める仕組みだ。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/guard.sh"
}
]
}
]
}
}呼ばれたスクリプトが、こういうJSONを標準出力に返すと、その実行は止まる。
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "取り消せない操作なので人間が実行します"
}
}`permissionDecision` には `allow` / `deny` / `ask` が書ける。「この条件のときだけ人間に聞く」を機械の側に強制させられるので、僕は自分の記憶に頼りたくない部分をここに寄せている。
ついでに、たまに棚卸しする
対話中に「今後は聞かない」を押した分は、`.claude/settings.local.json` にどんどん溜まっていく。放っておくと、いつの間にか許可リストがふくらんでいる。
僕は週に一度、このファイルを開いて中身を眺めることにしている。増えていること自体は悪くない。眺めていないことがまずい。
任せない領域を決めると、任せる領域が広がる
逆説的だけど、これがいちばん伝えたいことかもしれない。
「売買は一切任せない」と先に決めたから、僕は監視や計算を安心してエージェントに丸投げできるようになった。最悪の事故が境界で止まる保証があると、それより手前の自動化は思い切れる。
正直に書くと、僕は順番を間違えていた。最初は全チームを一斉に自動化することに専念していて、どこが危ないのかを自分でも把握できていなかった。だから全部がなんとなく怖くて、結局どれも任せきれていなかった。線を5本に絞れたのは、1チームずつ回して「どこが本当に不可逆なのか」を実地で見たからで、最初から設計図があったわけじゃない。
今もトライ&エラーの途中で、毎週どこかしら直している。だから「これが正解です」とは書けない。
ただ、これからAIエージェントに仕事を任せようとしている人に、最初の一歩だけ言えるとしたら——自動化の範囲を考える前に、「これだけは任せない」を先に一行で決める。 僕の場合それが「金が動く引き金は人間が引く」だった。
あなたの一行は、たぶん違う言葉になる。それでいい。
なぜこんな仕組みを作っているのか、種銭づくりから投資までの全体の話は種銭づくりから投資までの全記録【宣言編】に書いています。
本記事は筆者個人のシステム設計・投資手法の記録であり、特定銘柄の売買を推奨するものではありません。投資判断はご自身の責任で行ってください。
—
15体をどう組んだかは、noteに全部出しました
この記事は線の引き方までです。実際にどんなエージェントを何体、どういう役割分担で組んだのか——定義ファイルの現物、キューでのデータ受け渡し設計、そしてやめた自動化の記録は、有料noteにまとめました。うまくいった話より、そっちのほうが役に立つと思っています。
コメント