9月1日、Checklyが「Rewriting a Node.js Service in Go With AI Agents」と題した記事を公開した。日次9200万メッセージを処理するプロダクションサービスをAIエージェントを用いてNode.jsからGoへ書き直し、稼働Pod数を70%削減した実録だ。コードの大半はエージェントが一晩で生成した約1万3000行——その裏側にある設計判断を詳しく紹介する。
「エージェントに書かせる」前に人間がやるべきこと
この書き直しで最も重要な教訓は、AIエージェントがコードを書き始める前の準備にある。
Checklyが構築したテストハーネスがその核心だ。エージェントが生成したコードの「正しさ」を、人間のレビュワーではなく自動テストで担保する仕組みである。
ハーネスの設計方針は以下の通りだ：
- ブラックボックステスト：テスト対象のコードや言語に一切依存しない
- ゴールデンファイル：旧システムの出力をファイルに記録し、新実装がバイト単位で一致するかを検証する
- 非決定的フィールドの型チェック：UUIDやタイムスタンプは
<uuid>や<timestamp>として記録し、型チェックは継続する - リアルな境界サービス：PostgreSQLはエミュレーターではなく実コンテナを使用する
- **Playwright + Docker Compose + Toxiproxy**：ネットワーク断などのインフラ障害シナリオも網羅する
テストケースの入力データは自社のデータレイクから生成した。24時間分のアカウント・グループ・チェック設定と結果アウトカムをClickHouse（オープンソースの列指向分析データベース）に投入し、ユニークなシナリオに「折りたたむ」ことで現実的な入力を作り上げた。コードカバレッジは**90〜100%**を目標とし、不足箇所はエージェント自身にレポートを読ませて追加テストケースを提案させた。
エージェントの実行：一晩で約1万3000行
ハーネスが整ったところで、Claude Code（Anthropicが提供するターミナル上で動作するAIコーディングエージェント。なお記事中で言及される「Fable」はCheckly社内でのプロジェクトコード名）に指示を与えた。内容は「入力キューからデータを消費し、メッセージを処理し、データベース・キャッシュ・キューに書き出すGoサービスを構築せよ」というシンプルなものだ。旧実装は参照用として提供し、合格基準はテストハーネスの通過のみとした。
エージェントは一晩で約1万3000行のアプリケーションコードを生成し、月額200ドルのサブスクリプション内のトークン使用量に収まった。なお、同じ指示でOpusを使った先行試行では品質基準を満たさず破棄している。
最初の本番投入で踏んだ地雷
ローカル環境のインフラが本番と一致していなかったことで、リトライ処理のバグが発生した。
ローカルではチェック種別のみで3つのキューにルーティングしていたが、本番では優先度やホスティングタイプも含めてリージョンあたり18種類のキューにルーティングされる。ハーネスがローカルのトポロジーを前提としていたため、エージェントもその前提でリトライロジックを実装してしまった。
この失敗から得た原則は明確だ：
- ハーネスの環境は本番にできる限り近づけること
- すべての境界サービスを最小単位まで洗い出すこと（キュー1本、DBテーブル1枚単位で）
- インフラへの前提は推測せず、明文化して検証すること
ハーネスを本番トポロジーに合わせて修正し、ローカル専用のコードブランチをすべて削除した。その後、リトライモジュールを人間の監督のもとでリファクタリングし、翌日には内部アカウント（全体負荷の約3%）での処理を再開した。
段階的なカスタマー移行
移行は意図的に保守的な戦略をとった。フィーチャーフラグで旧デーモンから新デーモンへトラフィックを切り替え、以下の順序でコホートを移行した：
- 無料アカウント（トライアル・ホビイスト）
- 月次有料アカウント
- エンタープライズアカウント
各コホートを切り替えた後、24〜48時間監視してから次のコホートへ進んだ。移行期間中はCIが旧・新両方のデーモンに対してハーネスを実行し、どちらかが失敗したプルリクエストはブロックする体制をとった。
バグが出た際の修正サイクルも明確だ：ハーネスで再現 → 修正 → CI＋デプロイ。所要時間は約1時間。顧客が気づいたバグは軽微なエッジケースのみで、移行に気づいた顧客はほぼいなかった。
結果：Podが70%削減
本番移行の成果は数字に出た：
- 稼働Pod数が70%削減
- データベース負荷が軽減
- 本番インシデントはゼロ
GoのコンパイルエラーとデータベースのNull制約が、JavaScriptでは実行時まで気づけなかったバグを事前に検出した。型システムの強さがエージェントコーディングとの相性のよさにもつながったと記事では指摘している。
この事例が示す本質は、「AIエージェントがコードを書く」という部分より、「エージェントが書いたコードを信頼できるか検証する仕組みを先に作る」という設計判断にある。テストハーネスが先にあったからこそ、一晩で生成された1万3000行のコードをプロダクションに投入できた。言い換えれば、エージェントの生産性は人間が敷いたレールの品質に依存する——この点が、今後AIを活用したリライトを検討するチームにとって最も参考になる知見だろう。
詳細はRewriting a Node.js Service in Go With AI Agentsを参照していただきたい。
