AIコーディングエージェントを本気で回し始めると、最初に驚くのは性能ではない。
「こいつ、いつ帰るんだ？」
昼に調査させる。夕方に実装させる。夜にテストさせる。深夜にバグを投げる。翌朝見ると、まだ何か直している。
人間の職場なら空気が変わる。夜勤、残業、交代要員、引き継ぎ、疲労、管理。ところがAI側は、料金プランと利用枠の範囲なら、深夜2時でも「今日はもう帰ります」とは言わない。
そして大量に使うと、もっと妙なことが起きる。
一週間分の利用枠を、一週間かけずに溶かす。
最初は「前よりずっと持つ。余裕だな」と思う。数日後、画面の向こうから事実上の「もう今週は働きすぎです」が飛んでくる。
労務管理の概念が消えたと思ったら、サーバー側に新しい労基署がいた。
0. 結論：見るべきは労働時間ではなくスループット
「AIが1日12時間動いた」と聞くと、人間の12時間労働と比較したくなる。
でも重要なのは時間ではない。
見るべきなのは、
- 何件調査したか
- 何ファイル変更したか
- 何回テストしたか
- 何件の異常を潰したか
- 何件が本番まで通ったか
- 何件が途中で詰まったか
である。
AIは同じ12時間でも、検索、比較、修正、テストを高速で何周も回せる。だから「12時間しか動いていない」ではなく、その12時間で何人日分の処理を通したかを見る方が実態に近い。
1. 24時間営業が怖い理由は、夜勤が安いからではない
AIは昼でも夜でも、基本的には同じ利用枠の中で動く。
人間なら24時間営業にすると、夜勤、割増、シフト、引き継ぎ、採用、欠勤対応が増える。AIではその多くが消える。
つまり異常なのは「夜も働く」ことではない。
昼も夜も同じ装置がそのまま走れることだ。
しかも人間のように「今日は疲れたので判断品質が落ちる」が起きにくい。もちろんAIにも失敗はあるが、それは眠気ではなく、コンテキスト不足、誤推論、仕様理解不足、ツール失敗など別の故障モードになる。
2. 利用枠が増えると、なぜか仕事量も増える
面白いことに、利用上限が大きくなると、人は節約しなくなる。
小さい枠では「これは自分でやろう」と思っていた作業まで、AIに投げるようになる。
調査だけのつもりが、 調査→実装→テスト→修正→再テスト→ログ確認→追加修正、 まで一気に任せる。
すると「前の10倍くらい使える」と感じたはずなのに、数日で使い切る。
これは性能不足ではない。
供給量が増えた結果、需要側の仕事も膨張したのである。
高速道路を広げたら渋滞が戻ってくる、誘発需要のAI版だ。
3. 5時間ごとに回復するなら、待ち時間は「停止」ではなく「バッファ」になる
仮に一定時間ごとに利用枠が回復するなら、完全停止と考える必要はない。
回復待ちの間に、
- 新しい異常を記録する
- 再現条件を整理する
- ログを貯める
- 修正候補を優先順位づけする
- 次に投げるタスクをまとめる
そして枠が戻ったら一気に処理させる。
これで運用は、リアルタイム対話からバッチ処理型の工場へ変わる。
人間側は「AIが休んでいる」と感じるが、実際には待ち行列が育っているだけである。
4. 高品質モードは「常用」より「詰まり時の設計会議」
上位の高品質エージェントや推論モードは、1回の依頼で利用枠を大きく消費することがある。
ただし、だから無駄とは限らない。
本当に詰まったとき、
- 原因候補を網羅する
- 依存関係を整理する
- 修正順序を決める
- 再発防止策を設計する
- 監視項目を決める
といった計画設計を任せるなら、消費量が大きくても価値が出る。
普段の軽い変更まで最上位モードで殴る必要はない。
通常モードで進む。 ↓ 詰まる。 ↓ 高品質モードで原因分解と計画を作る。 ↓ 通常モードへ戻して実装を流す。
このエスカレーション構造が、かなり自然である。
高級な外科医を毎回の絆創膏交換に呼ぶ必要はない。でも、どこを切ればいいか分からない時には呼ぶ価値がある。
5. 本当のボトルネックは「AIの労働時間」から別の場所へ移る
AIが速くなるほど、遅い場所が目立つ。
典型的には、
生成 → 保存 → 変換 → 配信 → 本番反映 → 検証
の途中に一か所でも詰まりがあると、その前段がいくら速くても意味がない。
100本作って99本が本番に出るなら、1本は在庫化する。
これが毎回起きるなら「たまに失敗」ではない。
製造工程の歩留まり不良である。
AI工場では、モデル性能より先に「配管」が問題になる瞬間が来る。
6. 「記事が出ない」は、記事生成AIの問題とは限らない
記事が出ない時に、つい「生成に失敗した」と考えたくなる。
しかし実際には、
- 生成は成功した
- ファイル保存で失敗した
- メタデータ不整合で弾かれた
- 翻訳工程で止まった
- publication queueに入らなかった
- 配信後の検証で落ちた
- 本番にはあるが一覧に出ていない
など、故障箇所はいくらでもある。
だから必要なのは「出た／出ない」だけではない。
各工程に件数カウンターを置く。
生成 120 → 保存 120 → 配信投入 118 → 本番確認 116
なら、どこで4件消えたかが見える。
失敗は起きてもいい。黙って消えるのが一番まずい。
7. 24時間AI工場で重要なのは「自動復旧」
人間が毎回ログを見て再投入するなら、それはまだ半自動である。
理想は、
- 欠損を検知
- 対象IDを隔離
- 原因カテゴリを記録
- 再試行可能なら再投入
- 再失敗したものだけ人間または上位AIへ昇格
である。
これならAIの利用枠が戻った瞬間に、重要な異常から再処理できる。
「全部もう一回やる」ではなく、壊れたものだけ戻す。
これが工場っぽさを一段上げる。
8. 人間の役割は減るが、ゼロにはならない
AIが長時間働けても、人間が不要になるわけではない。
むしろ人間の仕事は、
- 何を重要とみなすか
- どこまで失敗を許すか
- 何を自動化しないか
- 品質と速度のどちらを優先するか
- どの異常を上位AIへ渡すか
という制御設計へ移る。
AIが作業者なら、人間は工場長というより「ライン設計者」に近い。
しかも一番大事なのは、ずっと監視することではない。
監視しなくても異常が見える仕組みを作ることである。
9. 最後に：AIの働きすぎより、働いた成果が詰まる方が怖い
数日で週次利用枠を使い切るのは、かなり激しい使い方だ。
でも本当に怖いのは、利用枠を使い切ることではない。
大量に処理したのに、
- 途中で消える
- 本番に出ない
- 欠損が見えない
- 同じバグを何度も直す
- 高品質モードを雑用で消費する
ことである。
24時間AI工場の最適化は、「もっと長く働かせる」では終わらない。
通常処理は安く速く。詰まりは高品質モードで解く。失敗は必ず見えるようにする。直せる失敗は自動で戻す。
ここまで来ると、AIを使っているというより、AIが働ける製造ラインを設計している。
そして最後に残る問いは、たぶんこれだ。
「AIはまだ働ける。でも配管の方が先に死んでない？」
