title: 寝てる間にAIが仕事を終えていた——テキストファイル1枚で実現する自律型開発
tags: ClaudeCode, AI, 自動化, 開発環境, AI駆動開発
寝てる間にAIが仕事を終えていた——テキストファイル1枚で実現する自律型開発
朝、パソコンを開いたら仕事が終わっていた。
昨夜テキストファイルに指示を書いて保存した。それだけだ。コードのリファクタリング、テストの追加、ドキュメントの更新。全部、寝ている間にClaude Codeが片付けていた。
嘘みたいだが、本当の話だ。
人間がボトルネックだった
自分は非エンジニアだ。コードは一行も書けない。それでもClaude Codeを使ってゲームを作っていた。ハクスラ系のローグライクRPGを、AIに全部書かせて。
ただ、毎回ターミナルに張り付いて指示を出す作業がきつかった。タスクが一つ終わるたびにAIが止まる。「次はどうしますか？」と聞いてくる。こっちが指示を出さないと何も進まない。
しかも聞いてくる内容が些末だった。「AとBどちらがいいですか？」——非エンジニアの自分がAIより正しい判断を下せるとは思えない。お前が決めろ、と何度思ったかわからない。
ゲームを作って、記事を書いて、投稿して。全部手動。仕事しながらだから時間もない。毎回パソコンの前に座って指示を出し続けるのは、単純に面倒すぎた。
ウィンドウ5枚の地獄
最初はコマンドプロンプトを3〜5個開いて、並列で作業を回そうとした。
疲れる。頭も疲れる。たまに間違えてウィンドウを閉じる。「このウィンドウじゃなくてあっちを閉じるはずだったのに」——大事なセッションが消える。再開しようにも、どのレジュームがどのスレッドに繋がるのかわからない。
視覚的に複数のエージェントを管理する仕組みが欲しかった。tmuxを導入し、マルチエージェントの管理を試みた。Twitterで見つけた「将軍システム」も取り入れた。自分でも「Kings Landing」という独自システムを構想した。王の下に評議会があり、その下に実行部隊がいる。人間に聞かなくてもエージェント同士で相談して完結する世界。
結果、複雑になりすぎた。Claude Codeから「シンプルにした方がいい」とアドバイスされる始末だ。AIに設計をダメ出しされる非エンジニア。笑えない。
テキストファイルに書いて保存するだけ
散々回り道した末にたどり着いたのが、拍子抜けするほど単純な仕組みだった。
テキストファイルにやってほしいことを書く。保存する。あとは放置。裏でファイルの変更を監視するスクリプトが動いていて、変更を検知したらClaude Codeに内容を渡して実行させる。結果は別のファイルに記録される。
やりたいことを instructions.md に日本語で書く。保存する。翌朝 status.md を開く。終わっている。それだけの話だ。
たとえば夜、こう書いて寝る。
src/以下の全ファイルにリントチェックをかけて、警告があれば修正。ドキュメントの不足しているdocstringを追加。未使用の依存関係があれば報告。
朝起きて status.md を見ると、何が修正されて、テストが何件パスして、何が報告されているかが全部書いてある。
大事なのは速度じゃない
正直に言う。人間がやった方が早い作業も多い。ボタンひとつクリックすれば終わることを、AIは遠回りしてやる。CAPTCHAが出たら詰む。ブラウザ操作も人間の方が確実に速い。
でも速度の問題じゃなかった。
人間の時間を拘束しないことに価値がある。 外で遊んでいる間、寝ている間に、業務が実行されて完了している。その事実が重要だった。手が遅くても、こちらの時間をゼロにできるなら十分だ。
正直、完全な成功とは思っていない
ここで大げさに「革命だ」と言うつもりはない。
AIに長時間勝手に動いてほしいとずっと思っていた。寝ている間に全部終わる世界。最初からその発想はあった。みんなそこに至ると思う。
だが実際にやってみると、なかなかうまくいかなかった。エージェントが途中で落ちる。意図と違う方向に暴走する。環境構築にトークンを大量消費して、肝心の作業に使うリソースが足りなくなる。週の使用量の半分を環境構築に溶かしたこともある。
自律実行について「成功した」と胸を張れる状態にはまだない。 これは正直な自己評価だ。
ただ、手動で毎回指示を出していた頃と比べれば確実に楽になった。完璧ではないが、方向は合っている。
効率について、ひとつ疑問がある
これだけトークンを使うということは、裏側でそれだけの計算資源が動いているということだ。電力も食う。
生産の量は増える。速度も上がる。だが生産効率は？ 人間が飯を食って自分の手と頭で作った方が、実は資源効率としては優れているのかもしれない。
個人の単位では確実に楽になる。会社の単位でも効率化は進む。だが人類全体の資源効率として、AIにすべてを任せることが正解なのかは、まだわからない。 使い込んでいるからこそ感じる疑問だ。
所感
テキストファイルに書いて保存するだけ。仕組みとしてはそれだけだ。
非エンジニアの自分にとって、これが一番しっくりくる形だった。コマンドを覚える必要もない。設定ファイルをいじる必要もない。日本語で「これやって」と書いて保存するだけ。
やりたかったのは、自分がいなくてもAIが動き続ける世界だ。完全にはたどり着いていない。でも近づいてはいる。
裏側：実装の詳細
ここからは技術的な話。後からClaude Codeに聞いて「こういう仕組みだったのか」と知った部分も多い。興味がある人だけ読めばいい。
ファイル監視スクリプト（claude-watch.sh）
核になるのはこれだけだ。ファイルのハッシュ値を5秒ごとにチェックして、変わっていたらClaude Codeに渡す。
#!/bin/bash
# claude-watch.sh
# ファイル変更を検知してClaude Codeを自動実行するデーモン
# inotifyではなくポーリングを採用したのは、
# どのLinux環境でも動くことを優先したため
WATCH_DIR="${1:-.}"
INSTRUCTIONS="$WATCH_DIR/instructions.md"
STATUS="$WATCH_DIR/status.md"
POLL_INTERVAL=5
LAST_HASH=""
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}
if [ ! -f "$INSTRUCTIONS" ]; then
echo "# 指示を書いてください" > "$INSTRUCTIONS"
log "Created $INSTRUCTIONS"
fi
log "Watching $INSTRUCTIONS (poll: ${POLL_INTERVAL}s)"
while true; do
if [ -f "$INSTRUCTIONS" ]; then
CURRENT_HASH=$(md5sum "$INSTRUCTIONS" | cut -d' ' -f1)
if [ "$CURRENT_HASH" != "$LAST_HASH" ] && [ -n "$LAST_HASH" ]; then
log "Change detected. Executing..."
echo "## 実行中 ($(date '+%Y-%m-%d %H:%M:%S'))" > "$STATUS"
# --print: 対話モードではなく結果を標準出力に返す
PROMPT=$(cat "$INSTRUCTIONS")
RESULT=$(claude --print "$PROMPT" 2>&1)
cat > "$STATUS" << EOF
## 実行完了 ($(date '+%Y-%m-%d %H:%M:%S'))
### 指示内容
$(cat "$INSTRUCTIONS")
### 実行結果
$RESULT
EOF
log "Execution complete. Results in $STATUS"
fi
LAST_HASH="$CURRENT_HASH"
fi
sleep "$POLL_INTERVAL"
done
instructions.mdの書き方
指示は具体的かつ検証可能にする。「いい感じにして」は通らない。
# 良い例
## タスク: APIエンドポイントの追加
- src/api/routes.py に GET /api/users/:id を追加
- レスポンス形式: { "id": int, "name": str, "email": str }
- 存在しないIDの場合は404を返す
- tests/test_api.py にテストを追加
- 完了後、pytest を実行してパスすることを確認
CLAUDE.mdとの連携
プロジェクトルートに CLAUDE.md を置いておくと、Claude Codeが自動的に読み込む。コーディング規約やディレクトリ構成を書いておけば、instructions.mdでは「何をするか」だけ書けばいい。「どうやるか」はCLAUDE.mdのルールに従ってAIが判断する。
セットアップ
# 作業ディレクトリを作成
mkdir -p ~/claude-workspace
cd ~/claude-workspace
# claude-watch.shを配置して実行権限を付与
chmod +x claude-watch.sh
# バックグラウンドで起動
nohup ./claude-watch.sh ~/claude-workspace > watch.log 2>&1 &
常駐させたければsystemdサービスにもできる。
# /etc/systemd/user/claude-watch.service
[Unit]
Description=Claude Code File Watcher
After=network.target
[Service]
Type=simple
ExecStart=/home/user/claude-workspace/claude-watch.sh /home/user/claude-workspace
Restart=always
RestartSec=10
[Install]
WantedBy=default.target
注意点
冪等性を意識する。ファイル変更のたびに実行されるので、同じ指示が二度走っても壊れないように書く。instructions.mdにAPIキーやパスワードを直接書かない。大量のタスクを詰め込むとClaude Codeの実行時間制限に引っかかる。大きなタスクは分割する。
自分のトークン消費パターンを確認したい方へ
Token Checkupで5つの質問に答えるだけでトークン消費の診断ができる。Hook Selectorで最適なhookセットも分かる。
🚀 cc-safe-setupがProduct Huntに登場 — Claude Codeの安全hookを一発でインストール。701 hooks / 56セクションのSurvival Guide / 無料ツール7個。upvoteで応援お願いします！
📖 トークン消費に困っているなら → Claude Codeのトークン消費を半分にする——800時間の運用データから見つけた実践テクニック（¥2,500・第1章無料）| Ko-fi $17
📖 AIで事業を回す実体験を全記録 → Claude Code×個人事業 800時間の全記録（¥800・第2章まで無料）
📖 非エンジニアがClaude Codeで事業を回した全記録（¥800） — $800のAIコストで¥6,000を稼ぐまでの失敗と改善。第2章まで無料
⚠️ Opus 4.7緊急情報（2026年4月17日）
Opus 4.7のauto mode安全分類器がOpus 4.6にハードコードされている問題が発覚。3日間で23件以上のデータ損失。さらにv2.1.100以降、APIコールごとに約20,000トークンが見えない場所で追加課金されている問題も判明（#46917、GitHub上196件のリアクション）（50GB永久消失含む）。4倍のトークン消費も報告されている。対策: npx cc-safe-setup --opus47（Survival Guide / Safety Scanner）
📊 2026-05-05 Path D (Hybrid Stack) の実例 — 利用者の集まりの場で観測: ある利用者が月 200 ドルの上位の枠から月 30 ドルの直接の API + 模型の振り分けに移行して、 6.7 倍の費用削減を実測で報告 (Reddit r/ClaudeAI 5/5 投稿)。 1 日の作業の内訳は 40% がファイル読みと文脈走査 / 25% が試験と雛形 / 20% が形式整え / 15% が硬い推論で、 上位の模型が必要なのは 15% だけ。 残り 85% は中位の模型 (Sonnet) で同じ結果が出る。 自律の運用の費用は、 振り分けの仕組み (上位の模型を 15% / 中位の模型を 85%) で 6.7 倍下げる経路がある。 Migration Playbook 第 6 章 (Path D) の中核の主張への直接の補強 (5/8 配信の第 2 版に取り込み予定)。
6月15日の billing 変更との関係
本記事の自動の作業 (テキストファイル1枚で実現する自律型開発) は、 内部で claude -p または Agent SDK の呼び出しの経路を活用する場合、 2026年6月15日の Anthropic の課金の経路の分割の対象に該当する可能性が高い。
Anthropic の公式の billing 文書で articulate された変更:
claude -p(一回完結の経路) と Claude Agent SDK の呼び出しは、 対話の Claude Code とは別の credit bucket (Pool 2) に route される予定。
本日 (2026-05-24) は残り22日。 自動の作業の経路を業務で運用する利用者は、 6月15日の前に次の3件の確認を推奨:
- 自分の plan の Pool 2 の月額の credit の上限 (Pro: $20、 Max 5x: $100、 Max 20x: $200)
- 自動の起動の頻度 × 1回あたりの平均トークン × 並列の数の見積もり
- 月額の credit の枯渇の経路 (extra usage の有効化の有無の判定)
無料の見積もりの道具:
- June 15 Pool 2 Estimator — 過去30日の使用量から6/15以後の月額の予測
-
June 15 Readiness Audit — 10問で readiness の score (0-100) を取得
詳細な決定の枠組みは Migration Playbook 第2版 (19米ドル、 241頁、 5/22発売) で、 留まる / 切り替える / 混在 の3経路の判定の入力。
関連の素材
明日5月22日に新刊の事例集 Claude Code Claim-Verify Handbook ($19) を発売します。 道具が「成功した」 「比較した」 「設定された」 と主張する一方で実態が乖離していた事例を GitHubの起票の集まりから130件 (本文15件+付録D 115件) 整理した本で、 14件の防衛の手順と5件の自動の点検の道具と一緒に提供しています。 自律型開発は道具の自己報告に依存する場面が多く、 主張と実態の乖離の検証の規律は基本の土台です。 試し読みのGist (約16,000字、 章1の全件) は こちら。
予防 hook の集まりは cc-safe-setup (MIT、 745件以上の hook、 30,000件以上のインストール)。 月額の継続の媒体 CC Safety Lab (¥500/月、 Ko-fi) は毎月の事故の整理を配信。