Claude Code・Cursor・Codex併用で1日の判断を400回から40回にした、ハーネス3層設計の実測
正直に書くと、私は1日に400回くらいAcceptボタンを押していた時期があります。Claude Code、Cursor、Codexの3つを併用しはじめた2026年初頭の話です。夕方にはコードが頭に入らなくなり、それでも惰性でEnterを押し、押した瞬間にやらかしに気づき、リバートし、もう一回押す。「人間がステアリング、エージェントが実行」とOpenAIが書いていたあの軽快なやつとは、明らかに違う何かをやっていました。
それから半年かけて、ハーネスの3層を本気で設計したら、1日の判断回数の自己計測値はだいたい40回まで落ちました。10分の1です。仕事量は減っていません。むしろ書いている記事数もコミット数も増えました。減ったのは「決める回数」だけです。
この記事では、その3層の中身を、Vohs 2008とDanziger 2011という決断疲労の一次資料に紐づけながら分解します。グラフの形に自信があるとは言いません。再現性論争のあるテーマだという話は後半でちゃんと書きます。それでも「決断回数を減らすと夕方の自分が戻ってくる」という感触は、半年間の運用で何度も裏取りされました。
学術的な前提: Vohs 2008とDanziger 2011を読み直す
設計の話に入る前に、決断疲労という前提を一次資料で確認しておきます。孫引きでこの話をするのはやめましょう、というのが私の最初の自戒です。
Vohsらの2008年論文 “Self-Regulation and Personality” は、被験者を2群に分けた実験を報告しています。グループAは多数の製品ペアから繰り返し選ばされる。グループBは同じ製品群を「評価するだけ」で、選ぶ作業はしない。その後、両群に苦い飲み物を飲み続ける課題と数学テストを課したところ、選択を強いられたグループAのほうが、後続課題で成績も持続時間も落ちました。読んだ情報量は両群でほぼ同じ、違うのは「決めたかどうか」だけです (Vohs et al. 2008)。
もうひとつ、はるかにわかりやすい実証がDanzigerらの2011年PNAS論文です。イスラエルの仮釈放委員会で、ベテラン判事8名が50日間に下した1,000件超の判断を分析したところ、セッション開始直後の承認率は約65%。それがセッション末ではほぼ0%まで落ち、食事休憩を挟んだ直後にまた65%付近へ戻る。同じ判事が、同じ法律で、似た案件を扱っているのに、です (Danziger et al. 2011)。
ここまでは強烈な話なのですが、誠実に書くべきこともあります。Danzigerには直後に反論論文が出ました (Weinshall-Margel & Shapard 2011)。事件の並び順が交絡している可能性があり、効果量はかなり過大評価されているのではないか、という議論です。背景理論のego depletionは2016年前後の大規模再現研究で効果量が小さいと示され、いまも論争中です。
だから私が支持しているのは「燃料が物理的に減る」モデルではなく、もっと弱い「判断列が長く続くと後続の自己制御は下がる傾向がある」という形です。グラフの形には自信が持てないけれど、夕方の自分がポンコツになる感触は本物。期待させて燃料の話をしぼませてすみません。しぼんだ残骸こそ運用に使えます。
そして、ここからが本題です。判事が休憩で復活するなら、エンジニアの解は「判断列そのものを設計で短くする」ことになります。
1日の判断回数を実際に数えてみた
設計に入る前にひとつワークがあります。あなたが今日、AIエージェントに対してaccept / reject / 修正 / 再プロンプトのいずれかをした回数を、10刻みでざっくりカウントしてみてください。10秒で十分です。
私が初めて数えたときは、体感100回くらいだろうと思っていたものが、実測で250回でした。2.4倍ハズしていました。Anthropic Skillsとhooksを併用する前の私の上限値は400回前後で、これは1ヶ月続けば月8,000〜10,000回の判断列になります。判事の50日で1,000件と並べると、こちらは月で1桁多いことになります。
判事の判断1件は社会的責任を伴う重い判断ですし、私のAcceptは業務判断にすぎないので単純比較はできません。ただ、arXivの “Towards Decoding Developer Cognition in the Age of AI Assistants” (2025) はこう書いています。AI提案を読むには、AIの論理を逆引きして自分のメンタルモデルに再マッピングする必要があり、この検証サイクルを1日に数十〜数百回繰り返すと注意が断片化する。1回のAcceptは単純な二択ではなく、「他人の論理を解釈し、自分のものに統合し、安全だと判定する」という多段の認知作業の塊だ、と。判事より軽いが、判事より回数が多い。負荷の総量はどっちが重いか、簡単には言えません。
私の出発点は400回でした。ハーネスの3層を入れて40回まで削るのが、この半年の運用ログです。
第1層: 制約 — 判断が発生する状況そのものを削る
3層のうち、効果が一番大きかったのは制約層でした。私のログでは400回→160回の削減はほぼここでした。
制約層に置いたのは具体的に3つです。
ひとつめは AGENTS.mdとCLAUDE.mdの併用 です。Claude Codeだけだったときは ~/.claude/CLAUDE.md をプロジェクトルートに置いて済ませていたのですが、CursorとCodexを併用しはじめると同じ規約を2回書くハメになり、Cursorだけが古い規約で動く事故が起きました。AGENTS.mdを正本にし、CLAUDE.mdからそれをincludeする形に直してから、ツール間の挙動ずれが激減しました。Cursor、Cline、Codexがいずれも参照するデファクトの名前として2026年に入ってAGENTS.mdが定着したのも追い風でした。
ふたつめは 「触ってはいけないリスト」の明文化 です。私の運用では、エージェントがやらかした失敗を全部AGENTS.mdの禁止リストに足していきます。リネームしてはいけないファイル名、削除してはいけないディレクトリ、変更してはいけないAPIシグネチャ、触ってはいけない外部サービス連携。やらかしの累積がそのままハーネス品質になります。これだけで「気を利かせた」変更による事故が8割減りました。
みっつめは 質問の予防 です。AGENTS.mdに「このプロジェクトの目的」「テストの動かし方」「ローカル起動コマンド」を先回りで書いておく。質問されてから答えるのではなく、質問が出る前に答える。これだけで頻出の対話判断が消えます。私の体感だと「このコードベースの命名規則は何ですか」「テストはどう実行しますか」のような起動時質問は、ほぼゼロになりました。
CLAUDE.mdは無限に伸ばせる気がしますが、長くなるほどコンテキストを食い、重要な情報が埋もれます。私の運用基準は1ファイル200行以内、超えたら詳細を別ドキュメントに逃がしてCLAUDE.mdからは参照する、です。「最新版だけが正しい」状態を維持して、古い情報は削る。
第2層: 観測 — 何が起きているかを後から見られる状態にする
400回→160回まで来たところで止まりました。理由は単純で、自分が「いま何回判断しているか」を知らなかったからです。観測がない状態で制約だけ足しても、効いているかどうかが判断できません。
観測層に入れたのは3つです。
ひとつめは Claude Codeの判断ログ取り です。claude --print のverbose出力をjsonlで保存して、Acceptイベントを単純にgrepでカウントするだけのスクリプトを書きました。最初は週次でしたが、デイリーにしてからやっと「制約Aを足したら判断が3割減った」のような因果が見えるようになりました。
ふたつめは Hooks経由のイベント計装 です。2026年に入って整備が進んだClaude CodeのHooks v2は25種類のイベントを公開していて、PreToolUse PostToolUse SessionStart などにフックを刺せます。私はここに判断カウンタの記録を仕込んでいます。Hooksの設計次第で「人間が承認した回数」「自動承認に逃がした回数」「拒否した回数」を別レコードで取れるので、削減の内訳が分解できます。
みっつめは Telegram通知でその場フィードバック です。判断回数が前日比で増えたら通知が飛ぶ。これが地味に効きました。「今日いつもより重い」と通知が来ると、夕方に重い判断を切ることを思い出せます。Danzigerの判事は休憩で復活していましたが、私は通知で休憩を思い出します。
観測を足すと、制約のうちどれが効いているかが見えるようになり、その結果として制約の質が上がります。3層は順序が重要で、制約→観測→自動化、という順番でないと自動化したものを観測する装置がなく、制約が緩いまま機械が暴走します。
第3層: 自動化 — 「判断しなくてもよい場面」を機械化する
160回→40回までの最後の落差は自動化でした。
Claude Code Skillsと、Claude Codeの “auto mode” の組み合わせがここを担っています。Anthropicの2026年5月のブログ記事 How we built Claude Code auto mode は、auto modeを「two-stage classification」として設計したと書いています。最初の fast filter がほとんどのツール呼び出しを安全判定し、不確実なものだけ deeper analysis に escalate する。判定の閾値は人間側で設定でき、機微な操作は承認ゲートに残せる。
私の使い方は次のとおりです。read-only系のツール（Read、Grep、Glob、Bash内の git status など）は無条件で自動承認。Editは「テストファイルなら自動」「実装ファイルなら承認」を Skill 経由で分岐。Bashは「許可リスト方式」で頻出コマンドだけ通し、それ以外は承認。rm や git push --force 系は触らない。
ここで重要なのは、auto modeの導入は判断を「省く」のではなく「事前ルール化する」操作だ、という捉え方です。事前にYesと決めたものはAccept時に判断が発生しません。Noと決めたものは自動で却下されます。判断は「ルールを設計する瞬間」に集約され、それ以外の時間は実装に使えます。
cronも自動化の道具です。私の場合は記事の品質チェックを朝のcronで回し、結果をTelegramで受け取り、明確なFailのときだけ修正セッションを開きます。Pass/Fail判定そのものは人間が見ていません。判断ではなく「結果を眺める時間」に変わっています。
半年運用したあとに残った数字
数字を並べておきます。すべて私の自己計測で、社内サンプル数も同じ生活パターンの私1人なので、雑な数字として読んでください。
開始時(2026/01) 現在(2026/06) 変化
1日の判断回数 (平均) 403 41 -90%
Acceptボタン押下回数 312 18 -94%
Reject後の再プロンプト 54 9 -83%
ツール承認ダイアログ 37 14 -62%
夕方のセッション継続率 4割 8割 +2倍注目してほしいのは最後の行です。判断を減らすのは「夕方にもまだ動ける」状態を保つためです。判事の話に戻ると、午前に重い判断を片付けるのが解だったわけですが、私の場合は「重い判断そのものを午後にも残さない」のがゴールでした。
ego depletionが燃料モデルだったか動機モデルだったかは、いまだに学術側で揺れています。それでも運用側の現象として、判断列が短くなったら夕方の私が戻ってきたのは事実です。グラフの形がガソリンメーターでも動機曲線でも、エンジニアにとっての処方箋は同じです。判断列そのものを設計で短くしてください。
自分のハーネスを診断する5項目
最後に、自分のハーネスを点検する5項目を置きます。今日のセッションを終える前に手元のリポジトリで確認してみてください。
- AGENTS.mdが200行以内に収まっているか
- AGENTS.mdに「触ってはいけないリスト」が10件以上書かれているか
- 過去1週間でエージェントから受けた頻出質問のうち、半分以上がAGENTS.mdで答えられるか
- 自分が1日に押したAcceptの回数を、ログから数字で答えられるか
- read-only系ツールが自動承認に逃がせる設定になっているか
5項目のうち3つ以上がNOなら、ハーネスはまだ「使う」フェーズです。5つYESなら「操る」フェーズに入っています。判事の承認率を午後3時に守るのは構造的に難しいですが、ハーネスを設計して判断列を1/10にするほうは、自分の手で動かせます。
私の判断回数はまだ40回で、これより下にはなかなか落ちません。残りの40回は本当に人間が決めるべき判断だと思っているので、ここから先は「数を減らす」のではなく「ひとつあたりを丁寧にやる」に切り替えています。あなたの40回はもっと少ないかもしれないし、もっと多いかもしれません。ただ、最初の400回を40回にする落差は、ほぼ全員にとって設計可能だと私は思っています。
ハーネスの3層（制約・観測・自動化）を体系的に解剖した本を出しています。Vohs 2008とDanziger 2011の決断疲労を起点に、AGENTS.mdとCLAUDE.mdの設計、6つの構成要素、Hooksとオーケストレーション、cron経由の運用までを通しで扱った ハーネスエンジニアリング — AIを「使う」から「操る」へ です。この記事は本の “実測ログ” 側だけを切り出したものです。
この記事は役に立ちましたか？