Claudeに「時間」を与える実行・自動化編〜モデル選択・セルフランナーと、正直な振り返り〜

はじめに：計画編からの続き

こんにちは、くりメガネです。株式会社センシンロボティクスでロボット運用支援ツールの開発とスクラムマスターを担当しているソフトウェアエンジニアです。

この記事は、Claude CodeのようなAIコーディング支援を日々使っている、あるいはこれから開発の進め方に組み込んでいきたいエンジニアに向けて書いています。前回の記事「Claudeに『過去』を与える」の続編である「時間」テーマの後編で、実行・自動化編です。

前編の 計画編 では、スプリントから今この瞬間まで、粒度を変えながら計画を立てて転がす部分を扱いました。共通の見積もりの土台に実績を自動でため、スプリントで合意し、週でレビューに出せる塊まで割る。朝に順番を確定し、瞬間ではペースを見る。そこまでが計画編の骨格です。

この実行・自動化編で扱うのは、立てた計画を実際に手を動かす作業へ移す部分です。具体的にはこの4つを、仕組みとして書きます。

起動時に3つの判断をまとめて効かせる「司令塔」
難易度・トークン残量・推論の深さ（effort）でモデルを選ぶ考え方
承認のない計画では実装させない「plan必須ゲート」
人手なしで安全に進められる作業を夜間に無人で進める「セルフランナー」

そして最後に、正直に言うとまだ仕組みにできていないことと、導入前の2週間と直近の2週間で働き方を表すいくつかの数字が実際どう変わったのかを、数字のまま出します。良いことだけでなく、道半ばの部分も隠さずに書きます。

起動時の司令塔：3つの判断をまとめて行う

計画編で作った計画は、置いてあるだけでは動きません。セッションを起動するたびに、その計画を実際の作業へ結びつける必要があります。そこを受け持つのが、起動用のラッパーコマンド（claude を直に叩く代わりに呼ぶ薄い入口）です。起動のたびに、次の3つの判断をまとめて行います。

タスク選択：today-planが朝に書き出した今日の計画（計画編の plan.md）から「今日やる」ものを出して選ばせます
計画との突き合わせ：選んだ作業に承認済みの計画があるか探します。無ければ、いきなり実装させず後述のplanモードで起動します
モデル決定：後述の方針で、難易度とトークンの残り枠に応じてモデルを決めて起動します

呼び出し自体は、起動ラッパーにサブコマンドを渡すだけの薄いものです。

# 今日の計画から1件選び、planゲートとモデル選択を通して起動する
cc-launch start

大事なのは、判断材料が無いときは普通に起動する（安全側に倒す）ことです。計画が見つからない、残量が取れない、といった場合に止まってしまうと、かえって手が止まります。材料があるときだけ賢く振る舞い、無ければ素直に立ち上がる。この割り切りで、日々の入口として気軽に使えるようにしています。

難易度・残量・effortでモデルを選ぶ

モデルは作業の途中で切り替えられないので、起動時に決めます。判断の軸は3つです。作業の難易度、トークンの残り枠、そして推論の深さ（effort）です。

軸1：難易度でティアを選ぶ

まず作業の難しさで、基準になるモデルのティア（性能の段階）を選びます。主力はOpusに置き、通常の実装・レビュー対応・計画づくりまでをOpusで回します。軽い定型作業だけ、より軽いティアへ落とします。

ティア	使いどころ
Haiku	短い要約・整形・一覧化
Sonnet	仕様が明確で一方向な作業
Opus	通常の実装・レビュー対応・複雑な判断・計画の策定

軸2：残量で、必要なら1段下げる

次に、トークンの残り枠を掛け合わせます。利用枠は一定時間で回復しますが、その回復までに枯らしてしまうと日中の作業が止まります。そこで、使いすぎたぶんだけ軽いティアへ寄せます。この「格下げのはしご」は設定に持たせています。

{
  "model_ladder": ["haiku", "sonnet", "opus"],
  "weekly_downgrade_at": 90,
  "hard_floor_model": "sonnet",
  "never_downgrade_tasks": ["plan", "review"]
}

週の利用量が閾値を超えたら、はしごを1段だけ下ります。ただし下限はSonnetまでで、それより下の定型ティアには落としません。そして 難所は下げません。曖昧で複雑な作業を節約目的で軽いティアにやらせると、手戻りが増えて結局は高くつくからです。だから計画の策定やレビュー対応は、格下げの対象から外しています。

軸3：effort（推論の深さ）は難所ほど深く

3つめの軸が effort、つまり1手あたりどれだけ深く考えさせるかです。同じティアでも、浅く速く答えさせるか、じっくり考えさせるかを変えられます。考え方はティア選びと同じで、定型作業は浅く、難所は深くします。整形や一覧化を深く考えさせても得るものは小さく、逆に設計判断を浅く済ませると抜けが出ます。残量が細ってきても、難所の深さだけは削らない、という優先順位です。

正直に言うと：選び分けはまだ「半分手動」

この3軸の選び分けは、まだ完全には自動化できていません。残量にあわせたティアの格下げは仕組みで効かせていますが、難易度とeffortの見立ては、起動時に手で指定することも多いのが実情です。完全な自動運用と言い切れる段階ではなく、そこへ寄せている途中です。利用枠の閾値やはしごも、運用しながら少しずつ見直しています。

必ずplanモードで：人間の出番を2か所に集める

この仕組みの背骨は、**「実装の前に、必ず計画を立てて承認を得る」**ことです。planモードとは、実装の前に計画だけを立てて承認を得るモードのことです。承認済みの計画が無いまま実装を始めようとすると、警告が出て止まります。承認された計画があってはじめて、Claudeは手を動かします。

仕組みは単純で、ファイルを書き換えようとする操作の直前に割り込んで、承認印を確認するだけです。

{
  "require_approved_plan": true,
  "gate_on": ["Edit", "Write"],
  "approve_on": "ExitPlanMode"
}

Edit や Write（ファイルの編集・作成）に入る直前で、承認済みの計画があるかを確認します
無ければ警告を出して、いったん止めます
planモードを抜けた時点で、その計画に承認印を押します。以降の実装は、その印を根拠に進みます

これによって、人間の出番が 2か所に集約されます。計画の承認と、成果物のレビューです。一手ずつの実装を見張る代わりに、入口で「この計画で進めていいか」を判断し、出口で「できたものが要件を満たすか」を確認する。間はAIに任せる、という分担です。

黄色は人間の判断ポイント、青はAIが主体で動くところです。実装と検証を分けているのは、「動いた」と「仕様を満たした」を別に確かめるためです。

あわせて、時刻でも区切りをつけます。平日の遅い時間以降は、後述のセルフランナーに任せることを提案し、人の入力を伴わない自動処理はそのまま通します。夜は人が張り付く時間ではないので、判断の要る作業は翌日へ、手放しで進められる作業は夜のうちに、という切り分けです。

寝ている間に働かせる：セルフランナー

「人手なしで安全に進められる」独立した作業は、キューに積んでおくと、決めた時間枠で一区切りずつ進みます。自分で起きて走るので、ここでは「セルフランナー」と呼んでいます。仕組みは、前回「過去」を与える記事で書いた夜間の自動収集と同じ発想で、短いセッションを何度も無人で回すものです。

定時に自分で起き上がる

鍵はmacOSの定時起動（LaunchAgent。指定時刻にコマンドを起動するmacOSの仕組み）です。設定は要点だけ抜き出すとこれだけで、毎時 :00・:15・:30・:45（15分間隔）に起動します。

<key>StartCalendarInterval</key>
<array>
    <dict><key>Minute</key><integer>0</integer></dict>
    <dict><key>Minute</key><integer>15</integer></dict>
    <dict><key>Minute</key><integer>30</integer></dict>
    <dict><key>Minute</key><integer>45</integer></dict>
</array>

起動されるのは薄いシェルスクリプトです。キューから着手可能な1件を確保し、選んだモデルとeffortでClaude Codeをheadless（-p。対話なしのワンショット実行）で1セッションだけ立ち上げます。

# キューから1件を確保し、選んだモデル・effortでheadless実行する
claude -p "$PROMPT" --permission-mode auto --model "$MODEL" --effort "$EFFORT"

キューに積む1件の形

キューへの追加は、専用のスキルを正本にしています。稼働中のセッションがキューを自分の作業コピーで上書きしないよう、直接の手編集は避け、追加はスキル経由に一本化しています。積む1件はこんな形です。「いつから着手してよいか」「いつまでに（締切）」「何をもって完了か（DoD。Doneとみなす条件）」「どう確認するか」を持たせておくのがポイントです。

{
  "task_id": "sample-001",
  "next_step": "下書きの続きを実装する",
  "dod": "ブラウザ自動テストが通ること",
  "verify": "テストを実行し、画面が仕様どおり表示されるか確認",
  "schedule": { "timezone": "Asia/Tokyo", "startable_at": "2026-07-19T19:00", "deadline": "2026-07-20T08:00" },
  "model": "opus",
  "status": "pending"
}

schedule は着手できる時間帯を絶対時刻で持ちます。startable_at を過ぎるまで着手せず、deadline を過ぎたら期限切れとして扱います。この例なら、7月19日の夜19時以降に着手し、翌20日の朝8時を締切にします。startable_at を省けばすぐ着手可、deadline を省けば無期限です。

安全に回すための仕掛け

無人で走らせるので、暴走しない仕掛けをいくつも入れています。

多重起動しない：前の実行がまだ生きていれば起動をスキップします（ロックファイルで見張ります）
時間で打ち切る：1回の実行は枠の少し手前で切り上げ、利用枠の枯渇を避けます
1区切りだけ進める：一度に全部やろうとせず、下書きのプルリクエストに着地させて止まります。曖昧で判断が要る作業は無理に進めません
未完はきちんと戻す：時間切れと本当の失敗を区別し、失敗が続く作業は自動で止めて人に知らせます

完了と未完は、状態を書き戻すコマンドで区別しています。

done  … DoD を満たしたら「完了」として記録する
defer … 未完・判断待ちなら「理由 / 次の一歩 / 推奨モデル」を申し送りに残して次へ回す

defer で申し送りを残すのが、この仕組みの肝です。無理に完了扱いにせず、「なぜ止まったか」「次に何をすればよいか」を次のセッション（や翌朝の自分）へ手渡します。夜間や隙間に簡単な作業が進むぶん、日中の自分はレビューという「人にしかできないこと」に集中できます。

同じ土台で、仕組み自身も手入れする

このセルフランナーは、日々のタスクを進めるだけでなく、仕組み自身の棚卸しにも同じ土台を使っています。週の利用枠がリセットされる少し前になると、キューの先頭に「この1週間を振り返って、スキルや設定の改善案を出す」自己改善のジョブを一度だけ差し込みます。判断材料が揃わないときは何もしない（安全側に倒す）ので、通常のタスク消化を邪魔しません。

余った枠を捨てずに、翌週に向けた見直しへ回す。日々の実行と、仕組みの改善とを、同じキューと同じ定時起動の上に載せているわけです。

正直に言うと、まだ仕組みにできていないこと

ここまで良いことを並べましたが、うまく仕組みにできていない部分がいくつもあります。読者が同じ仕組みを作るときにつまずくであろう順に、正直に並べます。各項に「今どう対処しているか」と「今後の宿題」をセットで書きます。

1. 完了の定義を、ゴールから正しく分解できていない

一番の難所がこれです。たとえば完了条件を「ローカル環境で起動できること」に設定したとします。するとClaudeは、起動コマンドがエラーなく立ち上がったことだけを確認して「完了」と判断してしまいます。実際には画面が開けていなかった、という失敗です。

正しくは、こう置くべきです。「ブラウザの自動テスト（Playwright。ブラウザ操作を自動化するツール）で、デザイン（Figma。デザイン共有ツール）どおりに仕様を満たすことを確認できること」。何をもって「できた」とするかを、AIが手を抜けない粒度まで具体的に書く必要があります。

今の対処：キューの1件ごとに dod と verify を必ず書かせ、「起動確認だけ」を完了条件に置かないようレビューしています
今後の宿題：ゴールから完了条件を機械的に分解する部分は、まだ人が書いています。ここを支援する仕組みが要ります

2. そもそもテストの足場が前提になる

上の話は、動作を確認する足場、つまりユニットテストやブラウザ自動テストの存在が前提です。足場が無いと、AIは「動いた」を頼りに実装を進め、既存の挙動を静かに壊しかねません。

今の対処：足場が薄い領域はセルフランナーに載せず、日中に人が見ながら進めています
今後の宿題：任せられる範囲を広げるには、まずテストの足場を厚くする作業が要ります。仕組み側だけでは解けません

3. 時間の厳守は、まだ達成できていない

計画編・実行編を通して「働き方の数字は結果としてついてくる」と書きましたが、時間の厳守そのものは達成できていません。後述の振り返りのとおり、拘束時間は縮んだものの、長い時間になる日は残っています。

今の対処：ペースの警告と、落とす・繰り越す候補の提示までは出しています
今後の宿題：警告が出ても押し切ってしまう日があります。何を諦めるかの判断を、もっと早い時点で促す工夫が要ります

4. 任せる範囲を広げる律速は、人間側の指示の精度

夜間に細切れで無人実行を回す仕組み自体は、動くようになりました。ですが朝にキューの結果を開くと、「惜しい」「なぜか途中で止まっている」が一定数残ります。原因を辿ると、多くはAI側の能力不足ではなく、渡した指示の粗さに行き着きます。とくに効くのが受入条件（AC。何をもって「できた」とするか）の定義で、これは宿題1と地続きです。受入条件が曖昧なほど、AIは「一応動く」で手を止め、人間が翌朝それを作り直すことになります。

つまり、任せられる範囲を広げる律速は、AIの賢さよりも人間側の指示の精度と設計力にあります。ここに対して、いま次の3つで対処しています。

レビューの重心を、コードの逐行から「テストケースの妥当性」へ寄せる。実装より先にテスト観点（何を確かめれば仕様を満たすと言えるか）をAIに出させ、人間はその妥当性をレビューします。観点さえ合意できれば、実装とその自動テストはAIに任せ、テストが通ることで担保します。逐行で追うより、抜けを早く確実に見つけられます
設計は、最初から完璧を求めない。まず動くコードに落とし、運用で違和感が出た箇所を直す、という進め方に寄せています。前もって全部を設計し切るより、手戻りは小さく収まります。ただしセルフレビュー（AI自身の一次レビュー）は外せません。人間のレビュー前に一度AIに自分の変更を批判させる工程は、粗い実装をそのまま通さないための最低ラインです
役割で分ける。整形・規約・定型の指摘はリンターとCI、そしてAIに任せ、人間はロジックと設計判断に時間を使います。機械に任せられる指摘で人間のレビュー時間を消費しないための線引きです
今の対処：実装前にテスト観点を出させて人間が妥当性をレビューする流れと、AIによるセルフレビューを、任せる作業の手順に組み込んでいます
今後の宿題：受入条件を漏れなく引き出す部分は、まだ人間の問いの立て方に依存します。ゴールから受入条件とテスト観点を機械的に導く支援が要ります

5. 完全自動運転は、あくまで最終手段

「全部を無人で回せばよいのでは」と考えたくなりますが、そうはしていません。第一に、曖昧な作業まで自動で回すとトークンのコストがかさみます。第二に、最終的にはレビューが律速で、作るスピードだけ上げても全体は進みません。

今の対処：無人で回すのは「人手なしで安全に進められる」独立した作業だけに絞り、判断の要る作業は人の出番に残しています
今後の宿題：任せられる範囲は少しずつ広げますが、完全自動運転は目的ではなく最終手段だと考えています。人の判断を要所に効かせる形を保ちます

振り返り：導入の前後で、数字はどう動いたか

仕組みの効果を、いくつかの数字で振り返ります。導入前の2週間と、直近の2週間を比べます。数字は正直に、良かった点も道半ばの点もそのまま出します。

出典は、自分のPCに残る作業記録（勤怠の打刻・作業ごとの時間記録）と、GitHubのプルリクエストの履歴です。いずれも平日ぶんを集計しました。前後で使えるデータの期間がそろう指標だけを選び、次の5つに絞って並べます。

指標	導入前の2週間	直近の2週間
労働時間（拘束、中央値）	約11.1時間	約9.2時間
プルリクエスト作成→マージのリードタイム（中央値）	約127時間	約20時間
夜間（22時以降）に生成されたプルリクエストの割合	約4%	約33%
連続して同じ作業に集中できた時間（中央値）	約39分	約97分
プルリクエストあたりのレビュー往復数（中央値）	約7回	約2.5回

読み取れる方向は、記事で書いてきた3つと重なります。

無理をしない方向：一日の拘束時間（始業から最後の作業終了まで）の中央値が縮みました。長い時間になる日が減った方向です
人間の出番がレビューへ寄る方向：夜間に無人で生成されるプルリクエストの割合が上がり、作る作業が夜と無人側へ移りました。リードタイムが大きく縮んだのも、日中の自分がレビューと引き取りに回れるようになったことと符合します
計画が動く方向：同じ作業に連続して集中できる時間が伸び、レビューの往復数が減りました。細切れの割り込みが減り、レビューに出せる塊で動けている方向です

ただし、正直に言うべき注意点があります。

各指標ともサンプルが少なく（10営業日前後）、日ごとのばらつきも小さくありません
プルリクエスト系は全リポジトリ合算で、夜間に無人生成されたぶんも含みます。件数そのものより、速さや割合の変化として見るべき数字です
レビュー往復数には、自動レビューのbotによる往復も混じっています
そもそもこれらの数字は多くの要因で動くので、この数字だけで因果は証明できません。「仕組みを入れたら、こう動いた」という以上のことは主張しません

効いたと考えているのは、どれか1つの数字を直接縛ったことではなく、その手前の土台づくりです。計画の承認を経由させて思いつきの着手を止めたこと、レビューを早めに前倒ししたこと、見積もりを継続的に補正したこと、そして実績を自動でためる土台を整えたこと。数字の変化は、これらの副次的な結果として現れている可能性が高い、と見ています。

なお、この実績の自動記録は、見積もり精度の向上のためだけに使っています。データは自分のPC内で管理し、外部へは送りません。勤怠監視や労務管理が目的ではなく、自分の計画を自分で守るための材料です。「実績を自動でためる」という言葉は監視のように聞こえがちなので、ここははっきりさせておきます。

おわりに：人にしかできないことに、時間を使う

計画編で立てた計画を、この実行・自動化編では実際の作業へ移してきました。起動時に3つの判断をまとめ、難易度・残量・effortでモデルを選び、承認のない計画では実装させず、夜間には安全な作業を一区切りずつ進める。そうやって、限られたトークンの中で、品質を落とさずにその週の仕事を進めます。

そして、この時間の仕組みは、前回の「過去」を与える仕組みと組み合わさると力を増します。過去のインシデントやレビュー指摘、チームのコーディング作法がAIから参照できるからこそ、任せた実装が チームの作法を守り、意図や背景を汲んだものになります。時間の仕組みが「いつ・どれだけやるか」を決め、過去の仕組みが「どう作るのが正しいか」を支える。 この2つがそろって、人間が計画の承認と成果物のレビューに集中する分担が現実になります。

まだ道半ばの部分は、振り返りと宿題の節に正直に書いたとおりです。それでも、人間の出番を計画の承認と成果物のレビューという2か所に寄せていく方向は、間違っていないと感じています。AIに時間を与えるというのは、突き詰めると「人が人にしかできないことに時間を使えるようにする」ことなのだと思っています。