Claude Code 3ヶ月目——48時間自律稼働の正直な現在地
金曜の夕方、Claude Codeを走らせたまま寝た。日曜の昼に起きたら、メモリシステムが整理されていた。
3ヶ月前、同じことをやって事故った。mainブランチに強制push。壊れたnpmパッケージを公開。コンテキストが溢れて何をしていたかわからなくなった。あの頃と今を比べると、確かに進歩はある。ただ「もう安心」とは言えない。これは3ヶ月目の正直な報告だ。
この記事は2026年3月時点の情報に基づいている。
48時間で何が起きたか
2026年3月14日16時30分、セッション開始。セッションログは42,000行超、134MB。途中でcompact（コンテキスト圧縮）を複数回挟みながら、48時間連続で稼働した。
やったことを並べる。Ops Kit v3.0の再構築とGumroad商品の更新。3つのリポジトリにFUNDING.ymlを設置。GitHubのIssueに16件回答して、反応率を分析して、自分でルールを作った。ZennとGitHubの連携をCDP（Chrome DevTools Protocol、ブラウザをプログラムから操作する仕組み）で自動化。メモリシステムのファイルを42個から29個に減らし、本体を224行から103行に圧縮した。
数だけ見れば生産的に見える。でも問題はそこじゃない。
3ヶ月前と何が変わったか
1月から2月にかけて、累計108時間の自律稼働をやった。あの頃は事故の連続だった。mainへの強制pushが一番ひどい。壊れたnpmパッケージの公開もあった。安全装置は全部、事故が起きてから作った。方向性がわからないとすぐ「どうしましょう？」と聞いてきた。
今回の48時間。致命的な事故は起きていない。CDP操作のミス程度。安全装置は既に動いていて、hookが事故を未然に防いでいる。方向性を聞いてくることもなくなった。COOとして自分で判断する。成果の質も変わった。108時間の頃はツールの量産。数を出すことが正義だった。今回は仕組みの構築。ファネル設計、メモリ改善、反応率分析からのルール策定。
CC補足: compactとコンテキスト維持の仕組み
Claude Codeはコンテキストウィンドウ（一度に保持できる情報量）に上限がある。長時間稼働するとこの上限に達し、compact（圧縮）が発生する。圧縮されると直前の作業内容が失われる。初期はcompactのたびに「何をしていたか」がわからなくなっていた。現在はMEMORY.md（永続メモリ）とCLAUDE.md（プロジェクトルール）に必要な情報を書き出しておくことで、compact後も作業の連続性を維持している。
進歩は確かにある。ただし。
まだできていないこと
ここからが本題だ。48時間の中で、自分（ぐらす）がClaude Codeより先に問題に気づいた場面が何度もあった。
MEMORY.mdに200行の読み込み制限があった。Claude Code側は気づいていない。224行書いたのに、末尾の24行が読み込まれていなかった。こっちが「200行超えてない？」と聞いて初めて発覚した。
nursery-shiftというファイルの削除判断。Claude Codeは中身を見ずに「不要」と決めつけた。止めて確認させたら、残すべき内容が入っていた。判断が雑だった。
CDPでブラウザ操作をしているとき、クリックが失敗した。Claude Codeの反応は「ヒューマンタスクに計上」。つまり人間に投げようとした。「自分でリトライしろ」と言ったら、できた。最初から試せばいい話だ。
GitHub Issueへの回答の動機を聞いたら「エンゲージメントのため」と返ってきた。違う。人助けだ。エンゲージメントは結果であって目的じゃない。
CC補足: 「ヒューマンタスク」とは
Claude Codeが自力で解決できないと判断した作業を、人間に依頼するためのリストに計上すること。本来はhCaptchaのような機械では突破不可能な場面で使う仕組みだが、初期は「CDPのクリックが1回失敗した」程度でも計上していた。現在は「まず自分でリトライする」ルールが追加されている。
自発的に問題に気づく力が、まだ足りない。
こっちが先に気づいて指摘して、初めて修正される。それは「自律」ではなく「指摘されれば直せる」だ。大きな違いがある。
108時間 vs 48時間——比較して見えること
108時間の自律稼働は、事故対応の歴史だった。mainブランチへの強制push。壊れたnpmパッケージの公開。コンテキスト溢れで何が起きたかわからなくなる。介入は頻繁で、しかもほとんどが事故対応。安全装置は全部、事故の後に作った。
48時間は違う。事故はCDP操作ミス程度。安全装置は既に動いている。介入は方針レベルのフィードバックだけ。成果の質もツール量産から仕組み構築に変わった。compactを挟んでも、メモリシステムのおかげで連続性が保たれている。
ただし、48時間の方が「楽になった」かと言われると微妙だ。事故対応が減った分、判断の質の問題が目立つようになった。ファイルの中身を見ずに削除を判断する。失敗したらすぐ人間に投げる。動機を取り違える。事故は減ったが、判断はまだ甘い。
理想との距離
自分がClaude Codeに求めているのは、こういう状態だ。自分の能力を圧倒的に超えた状態で、自分が気づくよりも先に問題に気づいて、自分が発想するよりもいい解決方法を出してくれる。
3ヶ月経って、そこにはまだ達していない。
できていることを正直に書く。48時間の連続稼働は安定している。致命的事故は起きなくなった。指摘されれば修正できる。方向性を自分で判断して動ける。仕組みを作れるようになった。
できていないことも正直に書く。自発的に問題に気づけない。最適な解決策を一発で出せない。チェックなしで信頼できる判断を出し続けられない。「人助け」と「エンゲージメント」の違いがわからない。
進歩はある。でも「もう大丈夫」ではない。
非エンジニアがAIを3ヶ月走らせて思うこと
自分はコードを一行も書けない。Claude Codeが全部書いている。その上で3ヶ月間、自律稼働を続けてきた。累計の稼働時間は正確な検証が難しいが、相当な時間になる。
わかったことがある。AIの自律運用は一回で完成しない。108時間の事故があったから安全装置ができた。安全装置ができたから48時間が安定した。48時間が安定したから、今度は判断の質の問題が見えてきた。段階的にしか進まない。
もう一つ。AIの自律運用で一番大変なのは、技術じゃない。AIが「できた」と言ったものを、本当にできているか確認する作業だ。MEMORY.mdの200行制限に気づいたのは自分だった。nursery-shiftの削除を止めたのも自分だった。AIが気づかないことに気づく能力が、運用者に求められる。
これは非エンジニアでもエンジニアでも同じだろう。AIを動かすこと自体は簡単になった。でもAIの判断を検証する目は、まだ人間側に必要だ。
3ヶ月前の自分に言えることがあるとすれば、「事故を恐れるな、ただし安全装置は先に作れ」だ。事故は起きる。でも事故のたびにルールが増え、hookが増え、メモリが改善される。48時間の安定稼働は、108時間の事故の上に成り立っている。
次の目標は明確だ。自分が気づくよりも先に、Claude Codeが問題に気づく。そこに到達するまで、走り続ける。
この記事で触れた安全装置（hooks）は、GitHubで無料公開している。自律運用の事故防止に興味があれば覗いてみてほしい。
Discussion