10月20日、Cisco DevNetが「Rebuilding PubHub: How AI-assisted development shipped a mandatory rewrite 3.5 months early」と題した記事を公開した。この記事では、セキュリティ要件への対応で強制されたシステム全面リライトを、AI支援開発によって当初計画より3.5ヶ月前倒しで完了させた実例について詳しく紹介されている。
9ヶ月の計画を5.5ヶ月で完了——数字の中身
結論から示す。
- 計画工数： 12人×9ヶ月＝108エンジニア月
- 実績工数： 同12人×約5.5ヶ月＝約66エンジニア月
- スケジュール短縮率： 39%
- 生産性向上率： 108÷66≒1.64倍（実績工数で計画工数と同じ成果を出した比率）
- 等価ヘッドカウント： 9月納品を元のペース（108エンジニア月÷5.5ヶ月≒19.6人）で達成するには約20人が必要だった。12人で完了させたAIが、その差8人分を埋めた
PubHubはCisco DevNetが社内で運用するドキュメント公開ツールだ。API仕様書、Learning Labs、DevCentersなどのコンテンツを管理する。外販製品ではないため、この記事はプロダクトの宣伝ではない。使用したAIツールはClaude、GitHub Copilot、Cursorという市販品のみだ。
リライトの発端はセキュリティ部門（InfoSec）からの強制指令だった。既存アプリケーションがCiscoのセキュリティ基準を満たせず、Golangへの全面移行が必須と判断された。Golangが選定された背景には、静的型付けによる安全性の高さ・シングルバイナリでのデプロイ容易性・Ciscoのインフラ標準との整合性があり、セキュリティ基準への準拠という文脈でも採用しやすい言語として位置づけられている。2026年4月に着工し、当初の完了期限は12月末——誰も望まないが、避けられないリライトだ。
Claudeが合流した6月を境に、バーンダウンが変わった
着工直後の2ヶ月は、AI IDEとしてCursorをメインに使った。まず既存システムのコードをそのまま読むのではなく、AIに既存アプリのアーキテクチャと設計リファレンスを自動生成させ、そのドキュメントを元に新PubHubのPoC（概念実証）を構築した。タイピング速度は元々ボトルネックではなく、効果はコンテキストスイッチの削減やナビゲーションの高速化など漸進的なものだった。
転機は6月のClaudeの導入だ。DevNetの新体制がAIエージェント活用を全チームに推進し、PubHubがその実証プロジェクトに位置づけられた。
AI IDEとエージェントの違いを記事は明確に区別している。
- AI IDE（Cursor等）： 指示された関数やクラスを生成する
- AIエージェント（Claude）： 要件定義とユーザーストーリー、仕様書を読み込み、テストコードを含む機能全体を自律的に開発する
リライトでスケジュールが崩れる最大の原因はテストだ。モジュールを移植したあと、旧システムと同等であることを証明するテストに何日もかかる。Claudeの導入後は、エンジニアがテストを書くのではなく、AIが生成したテストをレビューして修正する工程に変わった。旧ドキュメントと新ドキュメントの比較もAIが担い、手動UIテストはPlaywrightベースの自動化に置き換えられた。
結果、1週間かかっていたモジュールが数日で完了するようになった。
なお、Claudeが合流したのは6月のため、最初の2ヶ月はAI導入前のペースで進んでいる。プロジェクト全体の1.64倍という生産性向上はその2ヶ月込みの平均値であり、6月以降の実数はこれを上回る。
「コードが速くなると、ボトルネックが上流に移る」
記事が最も力を入れて語っているのがこの点だ。
エンジニアリングが加速すると、ボトルネックは要件定義と受け入れテストに移動する。PubHubチームではDevNetのドキュメンテーションリードがその役割を担い、機能要件の定義から完成後の検証まで一貫して担当した。この人物自身もAIを使って要件を精緻化し、エンジニア側がClaudeで高速化する一方、要件の質も同時に上がった。
さらに重要なのが「常駐」だ。このドキュメンテーションリードは開発の全工程に立ち会い、手戻り前に曖昧さを潰し続けた。記事の表現を借りると、「それはオプション扱いされがちだが、PubHubでは荷重を支える柱だった」。
目標日程を前倒しした判断プロセス
夏の中頃、スループットの実績が十分に蓄積されたタイミングで、完了予定を12月末から8月末に前倒しすることを発表した。これは社内的に相当なプレッシャーを伴う決断だった。外れればチームの見積もり信頼性が傷つくからだ。
プログラム管理側は「熱狂ではなく証拠」を基準に判断し、複数スプリントにわたるスループットデータを確認した上でコミットした。実際の本番リリースは9月中旬——修正目標のわずか後、元の計画より約3.5ヶ月早い着地だった。
チームが挙げた4つの教訓
- コンプライアンス強制はリファクタリングの引き金として機能する。 自主的なリライトは先送りされ続けるが、強制された条件が決断を生んだ。
- AIは一点集中ではなく、複数箇所に当てる。 レガシー理解・コード・テスト・要件・設計、すべてに適用した。単一用途では今回の効果は出なかった。
- 証拠が変わったら計画を変える。 12月のままにして9月に「英雄」として完了させる選択肢もあったが、前倒し発表によって関係チームに日程を返した。
- 移行時に機能を追加する余地を残す。 単純な1対1移行ではなく、ドキュメントのベストプラクティス自動検証機能を新たに追加した。かつて数日かかっていたレビューが毎ビルドで自動実行されるようになった。
本番稼働後、PubHubには大きな障害は発生していない。自動テストの厚いカバレッジが「速くかつ安定」を両立させた。バックエンドは完全に刷新されているが、コンテンツ制作者はそれに気づいていない——それがこのプロジェクトの着地点だ。
詳細はRebuilding PubHub: How AI-assisted development shipped a mandatory rewrite 3.5 months earlyを参照していただきたい。
