Claude CodeやCodexのような coding agent は、もう「ちょっと試す便利ツール」ではなくなってきました。この記事の著者 Eivind Kjosbakken は、そこをかなり強気に押し出しています。ポイントは、人間が細かく介入しなくても、エージェントが長時間動き続ける状態を作ること。これができると、並列でより多くの仕事を回せるようになる、という考え方です。
正直、ここはかなり面白い視点だと思いました。
昔は「AIにコードを書かせる」こと自体が新鮮でしたが、今はもう少し先に進んでいて、AIを“どれだけ止めずに働かせられるか” が生産性を左右する段階に入ってきている、という話です。この記事はその現実的な運用論を書いています。
この記事で一番印象的なのは、著者が「いまのボトルネックは人間のレビューだ」とはっきり言っているところです。コードを書くのは agent が速い。でも、そのコードが正しいか、仕様どおりか、壊れていないかを人間が見る時間が意外と重い。ここが詰まるので、全体のスループットが上がらないわけです。
これはかなり本質的だと思います。
AIに作業を任せると、つい「どれだけ速く書けるか」に目が行きます。でも本当に効くのは、人間が触る回数を減らすことなんですよね。エージェントが長時間走って、途中の小さな確認や調整まで自分で片づけてくれれば、人間は最後の大きな判断だけに集中できます。
著者が最初に勧めているのは、意外なくらい地味です。
権限で止めないこと。これです。
Claude Code でも Codex でも、何かを実行するたびに「許可してください」と止まる設定があります。便利なようでいて、長時間運用ではかなり邪魔になる。著者は、ほとんどの場合それは結局やることを承認するだけなので、auto-mode や権限スキップで止まりにくくしたほうがいいとしています。
ただし、ここで雑にフルオープンにしろ、という話ではありません。
著者は同時に、sandbox mode で動かすべきだとも言っています。sandbox は「閉じた作業場」のようなもので、agent が勝手に外側のファイルまで触れないようにする仕組みです。これはかなり大事です。AI が便利になるほど、事故のコストも上がりますから。
さらに著者は、バックアップの重要性にも触れています。GitHub にコードを置く、Time Machine のような仕組みでバックアップを取る。これは AI 専用の話というより、普通に大事な保険ですが、長時間自動運転させるならなおさら必要というわけです。
個人的には、ここは地味だけど一番現実的だと思いました。AI の賢さより、事故ったときに戻れるかどうかのほうが、実務ではずっと効くからです。
次に著者が強調するのが、agent 自身に検証させることです。
これも大切です。人間が最後に「たぶん大丈夫」と見るのではなく、最初からタスクの中に「どうやって正しさを確かめるか」を入れておく。
たとえばデザインを実装するなら、ただ「このUIを作って」で終わらせない。
「デザインどおりに実装し、スクリーンショットを撮り、元デザインと見比べて一致しているか確認してほしい」と明示する。もし一致しないなら、その差分を報告するように指示する。著者はこうしたやり方を勧めています。
この考え方はかなり実用的です。
要するに、作ることと確認することをセットにするわけです。人間の仕事を減らすには、agent に「完成」の定義を渡さないといけない。そうしないと、見た目はできていても中身がズレたまま終わることがあります。
しかも現実には、デザイン通りに作りたくても、既存コードや技術的制約のせいで完全一致できないことがある。著者はそこもちゃんと見ています。無理なら無理と agent に報告させる。ここが雑だと、あとで人間が余計な判断を抱え込むことになります。
この記事の中でも、かなり攻めているのがこの部分です。
著者は、agent にコードレビューをさせれば、人間のレビューはほとんど不要ではないかとかなり強く主張しています。もちろん、これは重要なシステムでは慎重であるべきですが、通常の開発では相当な時間短縮になる、という見方です。
具体的には Codex をレビュー役に使う方法が紹介されています。
1つは GitHub 上で PR にタグ付けしてレビューさせる方法。
もう1つは CLI から2つのブランチを比較させてレビューする方法です。著者は後者のほうが速いので好んで使っていると言っています。
これ、開発現場の空気をかなり変える発想だと思います。
レビューは本来、人間がやると重いんですよね。ちゃんと読むほど時間がかかるし、雑に見ると抜ける。そこを AI に寄せられるなら、人間は「本当に危険な変更」だけを見る運用に近づけます。全部を AI に任せるというより、AI で通常運転を回し、人間は例外処理に集中する感じです。
長時間運用の最後の壁は、意外と単純です。
パソコンを閉じたら止まる。これです。
ローカルで動かすと、作業内容を見やすいし、ブラウザ操作も追いやすい。セットアップも楽です。でも、外出したり、ノートPCを閉じたりすると、当然 agent も止まる。著者は Mac のスリープを無理に無効化する方法にも触れていますが、実際やると本体が熱くなってあまりおすすめできなかったそうです。こういう生々しい話は信頼感があります。
そこで出てくるのが remote 実行です。
クラウドや別の常時稼働マシンで agent を動かせば、PC を閉じても止まりません。これはかなり強い。反面、何をしているかの把握は少し難しくなるし、セットアップもやや面倒です。しかもクラウドに秘密情報を置くことに抵抗がある人も多いでしょう。著者自身も、そのあたりのリスクには慎重です。
著者の構成は、かなり現実派です。
メインは旅行用の強いマシンで動かしつつ、別の予備マシンでは bots を常駐させて、必要なら Claude Code や Codex セッションを長く走らせる。つまり、1台のPCに全部背負わせない。この発想は、いかにも「長時間回すための設計」です。
この記事を読んでいて感じたのは、もう coding agent の議論は「どのモデルが賢いか」だけでは足りない、ということです。
もちろんモデル性能は大事です。でも、実際に仕事にするなら、どう止まらずに走らせるか、どう安全に任せるか、どう自己検証させるかのほうが効いてくる。
このへんは、AIを「魔法の自動化装置」ではなく、かなり気難しいが有能な同僚として扱っている感じがあります。私はこの見方がわりと好きです。期待しすぎると事故る。でも、扱い方を覚えると、たしかに人間の仕事の流れが変わる。著者の記事はその手前ではなく、かなり実戦寄りのところを見ています。
もちろん、全部を真に受けてフル自動化すればいいわけではありません。特に本番環境や重要な変更では、人間の目が必要な場面は残るはずです。そこは著者も「非常に重要な部分は別」とにおわせています。
ただ、それでも通常の開発で人間が全部の面倒を見る時代ではなくなってきた、という感覚はかなり伝わってきます。
参考: How to Run Claude Code Agents for 24+ Hours | Towards Data Science
