サイバーエージェント の開発者ブログに掲載されたこの記事は、グループ会社 GOODROID で共通基盤と AI 活用推進に携わる Unity エンジニアによるものである。記事は、社内の Unity クライアント基盤ライブラリ 2 つのコーディングを、人間がコードを一切書かない段階まで AI コーディングエージェントによる 仕様駆動開発 に移行した経緯を説明し、アンチパターンに陥った 1 度目の試みと、それを改善するために著者が整えた 2 度目の試みを比較している。
ワークフローは cc-sdd をベースにしていた。人間が AI とともに要件、設計、タスクの各ドキュメントを作成し、エージェントがそれに基づいて実装する。著者が試行の対象に基盤コードを選んだのは、ほぼ 1 人で書かれていてチーム内の調整コストを避けられることと、既存のコードと経験があるため正確な仕様を書ける見込みが高いことが理由だった。
要点
- 1 度目の試みは、31 ファイル・4,040 行の画面遷移ライブラリを対象に、単一の大きな仕様を用いた。
design.mdだけで 256KB・5,200 行あった。Claude Code の/contextで測定すると、3 つの仕様ドキュメントが標準のコンテキストウィンドウの 73% を占め、自動コンパクション用に確保された領域を含めると 90% 近くに達したため、実装が始まるとコンパクションが頻繁に発生した。 - 著者は仕様実装コマンドを 17 ステップにまで拡張していた。ボット認証から始まり、セルフレビュー、テスト、プルリクエスト、MCP 経由での人間のレビュー待ち、マージまでを含む。頻繁なコンパクションのもとでエージェントはステップを飛ばし（テストの実行を省く、途中で完了を宣言するなど）、その対策のたびにルールやメモリが追加されて状況はさらに悪化した。記事はこれを コンテキスト肥大化ループ と呼んでいる。
- 記事は 1 度目の試みから生じたさらに 4 つの問題を挙げている。1 つの大きな仕様が実装される間、人間の待ち時間が長くなったこと。トークン消費が契約上の上限に達し、並行して走らせられる作業ラインの数が制限されたこと。ワークフローが大きくなるにつれてテストの実行が確率的になり、テストが通っていないままプルリクエストがマージされたこと。そして厳しい権限設定のもとで権限確認のプロンプトによって作業が止まり、並列度が上がるほどそれが悪化したことである。
- 2 度目の試みは、92 ファイル・8,145 行のデータライブラリを対象に、作業を技術的な境界に沿って 21 の仕様に分割した。仕様ドキュメントの平均は 977 行、331 行、228 行で、1 つの仕様一式が占めるのはコンテキストウィンドウの約 17% だった。
- 常駐コンテキストは最小限に抑えた。CLAUDE.md、メモリ、ルールには約 30 行の一次ルールだけを置き、ワークフローの詳細は必要に応じて読み込むプレイブックに移し、一次ルールが無視されないようにフックを用いた。
- Claude Code をメインエージェント、Codex をサブエージェントとしてプロバイダをまたいで動かした。これは マルチモデルオーケストレーション であり、著者は実装におけるトークン効率が向上したと報告している。
- エージェントが実行するテストを 決定論的な品質ゲート に置き換えた。テストは設計時に人間とともに確定させ、マージ前に
SubagentStopフックと GitHub Action によって全件実行する。これにより、レビューでテストの合格を確認する必要がなくなった。 - エージェントは権限確認のプロンプトなしで（「YOLO 環境」）、自作した 2 コンテナ構成の Docker 環境の中で動かした。外部へのアクセスを持たないサンドボックスと、最小限の許可リストに含まれるドメインだけを Squid でプロキシするゲートウェイから成る。専用の最小権限アカウントを使い、組み込みの Web 検索とフェッチは無効化し、検索は審査済みの MCP サーバーとプロキシを通じてのみ提供した。著者が既存の隔離環境を使わずに自作したのは、それらがマルチモデル構成や望む通信制限に対応していなかったためである。
- 新たなボトルネックは人間によるレビューだった。1 か月で 790 件のプルリクエストがあり、そのうち 426 件は人手でレビュー・対応した。著者は、これが回ったのは好条件（1 人での開発、既存コード、明確な要件）があったからにすぎないと述べている。
- 著者の結論は次のとおりである。仕様の粒度が最も重要であること。品質保証は決定論的であるべきこと。常駐コンテキストは最小限にすべきこと。マルチモデル構成はスループットを上げる有効な手段であること。そして YOLO 環境は権限を安全に最大化するための基盤であること。
背景
この記事は、1 人の開発者が担当する 2 つの基盤ライブラリについての 1 人のエンジニアの経験談であり、記事中の数値（コンテキストウィンドウに占める割合、プルリクエストの件数）は著者自身の測定によるものである。著者は、人手を介さないワークフロー完走率の低下など一部の効果は測定ではなく体感で判断したと断っている。また、隔離された Docker 環境の構築は Unity エンジニアにとって馴染みのないスキルであり、チーム全体への展開を難しくするかもしれないとも指摘している。