1. 前回のおさらい
半年ほど前、このブログで GSD（Get Shit Done）について書いた。Claude Code の上に乗せるコンテキストエンジニアリングの層で、フェーズ分割・原子的コミット・専門サブエージェントによって、AI 駆動開発の「作る」段階を一段引き上げてくれる——そういう内容だった。
当時の私は GSD の手応えに興奮していた。ただ、記事の結びはこう書いている。「本番投入はまだ」。
作れることと、それを本番に乗せて運用し続けることは別だ、と当時から薄々感じていたのだと思う。3か月経って、その勘は正しかった。ただし、思っていたのとは少し違う形で。
—
2. 本番でのフェーズ完了の意味
半年でいくつか前進した。住所の生活利便性をスコアリングする MCP サービス liveability.jp は、Phase 1 から 13 まで完走し、v1.4 として GA（一般公開）に至った。
VPS 上で常時稼働し、外部から接続できる状態になった。前回「まだ」と書いたものが、一応「動いている」ところまで来た。
ところが、GA からしばらく経ったある日、Claude Desktop からの MCP 接続がエラーを返し始めた。Phase 13 で「Gate 1（実接続）PASS」を確認していた、まさにそのエンドポイントである。
診断していくと、原因は1つではなかった。別レイヤの問題が3層に重なっていた。
- アプリ層のバグ： 内部で二重書き込みが起きていた
- デプロイ手順の罠： プロセスマネージャに環境変数が注入されていなかった
- 依存ミドルウェアの消失： 接続先のデータベースがそもそも居なくなっていた
厄介だったのは、おそらく Phase 14 のどこかから静かに壊れたまま、しばらく誰も気づかなかったという点だ。
ここで「本番」という言葉の意味が、作っていた頃と変わったことに気づいた。GSD のフェーズ完了は「そのフェーズで作ったものが、その瞬間に動くか」は確かめてくれる。
だが「その後も動き続けているか」は管理範囲の外にある。
「コードが書けた、は、サービスが動いている、と同じではない。」 フェーズが完了した瞬間と、本番が今この瞬間に健全であることは、別の事柄なのだ。
これは GSD の欠陥ではない。GSD は「作る」に焦点を当てたフレームワークで、原因も GSD 自体とは無関係なところにあった。境界を知らなかったのは、こちら側の設計の問題である。
—
3. コスト感覚
第1記事を書いたとき、私はほとんどコストの話をしていなかった。作るコストの見積もりはできても、「常時動かし続ける」コストは想像の外にあったからだ。
半年で見えてきたのは、コストには3種類あるということ。
- API のコスト： 複数の AI を並行して回していると、ここが思ったより伸びる。一度、エージェントの自動実行が上限（スペンドキャップ）に当たって止まったこともあった。
- インフラのコスト： VPS の月額。常時稼働させる以上、止められない固定費になる。
- 人間のコスト： これが一番見えにくい。今回のような障害対応に取られる自分の時間は、どの見積もりにも入っていなかった。
ついでに言うと、「ローカル LLM を自前で動かせばトークン代を抑えられるのでは」という誘惑も生まれてくる。中古の Mac Studio や M4 Pro Mac mini を物色する時間も、立派なコストだ。
結論はシンプルだ。**作るコストより、運用コストのほうが読みにくい。** そして読みにくいコストほど、最初に向き合っておく価値がある。
4. 複数AIの分業
第1記事は Claude Code 単独で回す前提で書いていた。半年後の現実は、複数の AI を役割分担で動かす体制になっている。
- 戦略・設計：クー（Claude）。方針を立て、構成を詰める。
- レビュー・セカンドオピニオン： レイ（GPT 系）。別の頭で叩く。
- 主要な実装： Atlas（Claude Code）。
- 量の実装： Codex のチーム。
- 進行管理（PM）： 別ツールに任せる。
なぜ分けるのか。単一の AI で回していると、自分の出力を自分で疑えない。盲点がそのまま本番に流れる。だから、本番反映や契約まわりのような取り返しのつかない判断は、クーとレイで二重チェックする運用にした。
ただし分業は銀の弾丸ではない。AI 同士のあいだには引き継ぎロスが生まれる。それを埋めるために、複数 AI が共有できる非揮発の記憶層（Vault と、AI 間の受け渡し用の VaultBridge）と、セッションごとの3行サマリー（決定事項・次アクション・未解決）を用意することになった。
「分業のコストを払ってでも、単一 AI の盲点を避けたい」——今のところそういう判断をしている。
—
5. 結論
3か月前の「本番投入はまだ」は、慎重すぎたのではなく、正しい慎重さだった。
GSD は「作る」を確実に強くしてくれる。だが「運用する」は、フレームワークの外側で自分が設計しなければならない領域だった。
フェーズが完了してもシステムは壊れる。むしろ、フェーズが完了してからが運用の始まりだ。
作ることに比べて、運用は地味で、終わりがなく、コストが読みにくい。それでも、「本番」と名乗る以上は、そこを引き受けるしかない。半年かけて学んだのは、結局そういうことだった。
—
6. 次の課題
正直に言えば、運用基盤はまだ整っていない。次にやるべきことは見えている。
- 障害対応の手順書（RUN-BOOK / INCIDENT-LOG）の整備： 今回は手探りで直した。次は手順から入れるようにする。
v1.4 を本番運用し続ける前提として、これは必須。 - 「静かに壊れる」を検知する監視：Phase 14 以降ずっと壊れていた可能性に、しばらく気づけなかった。気づける仕組みがいる。
- v1.4 の残作業： API キー発行まわり、レート制限、公開ドキュメント。
- 次のサービスへの反映： 今まさに進めている別プロジェクトには、最初から運用レイヤを設計に含める。同じ学びを二度払いしたくない。
半年後、また続きを書けたらと思う。今度は「運用してみて、監視を入れてわかったこと」になるはずだ。
