簡潔な指示と自動検証が支えたAsanaのテスト基盤刷新

何が起きたか：2週間で完了したフロントエンド・テスト基盤の刷新

ワークマネジメントツールを提供するAsanaは、フロントエンドのテストスイート全体を刷新しました[1]。テストスイートとは、ソフトウェアが正しく動作するか検証する自動テストの集合を指します。Asanaは旧来のテストライブラリであるEnzymeから、React Testing Library（RTL）への移行を実施しました[1]。

EnzymeはReact向けのテストユーティリティです。コミュニティによる支援が失われ、新しいReactとの相性が悪くなっていました[10]。また、Enzymeはユーザーの実際の操作ではなく内部の実装詳細に結びついたテストを促す傾向がありました[10]。一方でRTLは、ユーザー視点の振る舞いを検証する設計を促すテストライブラリです[9]。

Asanaは2022年からこの移行に着手していました[1]。しかし、従来の進め方では完了までに複数のエンジニア年を要し、なお約5年かかる見込みでした[1, 3]。今回の移行では新機能の開発ではなく、コードベースからEnzymeを完全に除去することを完了条件としました[2, 14]。

AsanaはOpenAI Codexのコーディングエージェントを活用しました[4]。その結果、エンジニアリング作業量として約1.5週間、暦上の期間としては2週間で全ファイルの移行を完了させました[3, 4]。

数字の背景：「5年で600万ドル」と「2週間で1.2万ドル」の正確な意味

この事例では「5年が2週間に短縮された」「600万ドルの費用が1.2万ドルで済んだ」という数字が注目を集めています[4, 7]。しかし、これらの数字の前提を正確に整理する必要があります。

まず「5年」という期間は、過去に5年間作業し続けた実績ではありません。従来の移行ペースを維持した場合に、完了まであと約5年かかるという残存期間の見積もりです[5, 6]。これに対し「2週間」は、今回のプロジェクト開始から完了までの暦上の所要期間を示しています[6]。

エンジニアリング作業量としては約1.5週間とされていますが、人月や人週のような厳密な工数計算の内訳は公表されていません[6]。2週間の間にはエージェントの昼夜稼働や人間の朝夕レビューが含まれるものの、待機時間やCIの実行時間などの詳細な時間配分も開示されていません[7]。

費用面でも前提の違いが存在します。「約600万ドル」は、専任シニアエンジニア3人を約5年間配置した場合の仮想的な人件費見積もりです[8]。これはサンフランシスコ・ベイエリアにおけるエンジニア1人あたりの年間費用（約35万〜45万ドル）をもとに試算されたものです[8]。なお、この試算にはそのエンジニアが製品開発を行えないことによる機会費用は含まれていません[8]。

一方で「約1.2万ドル」は、モデル利用料の約1.1万ドルとインフラ費用の約1,000ドルを合算した直接費用です[7]。ここには人間のエンジニアがレビューや進行管理に費やした人件費は含まれていません[7]。また、Codex実施時の人間チームの総人数も公表されておらず、確認できるのはレビューを担当したエンジニアの記述のみです[5, 8]。

このように、600万ドルと1.2万ドルは人件費試算とAI直接費用という異なる性質の数字です。これらを直接比較して厳密な費用対効果（ROI）を算出することはできませんが、プロジェクトの期間とコストを大幅に抑えた方向性を示しています[8]。

なぜ今実現できたか：シンプルな指示と強固な検証ループ

今回の移行が成功した要因は、複雑な指示体系ではなく、シンプルなプロンプトと自動検証環境の組み合わせにありました[9]。プロンプトとは、AIモデルに実行させたい処理を伝える指示文です。

Asanaは当初、タスクのチケット分割や作業メモの作成、サブエージェントの起動、RTL規約の詳細な指示などを試みました[9]。しかし、これらはかえって結果を悪化させました[9]。最終的に効果を発揮したのは、わずか5文で構成された単純なプロンプトでした[3, 9]。

指示の内容は、特定のディレクトリを対象範囲として指定し、Enzymeを利用しているファイルをRTLへ移行し、指定のテストコマンドを実行するという簡潔なものでした[1, 3]。移行しやすいファイルから着手するよう指定した点も特徴です[14]。

EnzymeとRTLの間には機能の一対一の対応関係がありません[15]。そのため、機械的な一括置換ではなく、テストの意図に応じた判断が求められます[15]。Codexはリポジトリ内に蓄積されていた既存のRTLヘルパーやコード規約、実例を読み取ることで、詳細な指示がなくとも適切な移行コードを生成しました[4, 14]。

また、検証ループの存在が品質を担保しました。Asanaは「コードベースからEnzymeを無くす」という明確な受け入れ条件を設定しました[2, 10]。そして、型チェック（静的な型整合性の確認）、lint（コード規約違反の自動検出）、テスト、CI（継続的インテグレーションによる自動ビルド・テスト環境）を活用しました[2, 10]。これらの仕組みがエージェントの変更ミスを即座に検出するフィードバックループとして機能しました[2, 10]。

実運用の仕組み：並列エージェントと人間による全件レビュー

Asanaは自律的なAI任せにするのではなく、人間の監視を組み込んだパイプラインを構築しました[16]。作業の実行にあたっては、最大4体のCodexコーディングエージェントを並列で稼働させました[2, 4]。各エージェントには異なるディレクトリ、またはコードベースの別コピーが割り当てられました[2, 4]。エージェントは昼夜を問わず作業を進めました[7]。

人間のエンジニアは朝と夕方の1日2回進捗を確認しました[2, 8]。Codexが作成したプルリクエスト（変更提案）に対して、抜き取りではなくすべての変更をレビューして承認しました[2, 8]。自動検証で機械的な誤りを排除し、最終的な妥当性を人間が確認する体制が敷かれました[2, 16]。

何が変わるか：ボトルネックはモデルからリポジトリ環境へ

Asanaの報告によると、運用のボトルネックはAIモデルの推論能力ではなく、開発環境側にありました[11]。実務で直面した主な障害は、Enzymeを推奨する古い内部文書や、不安定な開発ツールでした[10, 11]。

具体的には、lintの処理に10分以上かかるケースや、ローカル環境とCI環境の間でチェック結果が一致しない問題が発生しました[8, 11]。エージェントがスムーズに作業を進めるためには、リポジトリのインフラ環境を整える必要がありました[11]。

AIエージェントにとって、コードベースの外部にある暗黙知やドキュメントは参照できません[14]。そのため、テストヘルパーやコーディング規約、良質な実装例をリポジトリ内に整理しておくことが、エージェントを機能させる前提条件となります[4, 14, 15]。

なお、今回の移行に関するテスト成功率の推移や失敗件数、移行後の不具合発生数などは公表されていません[8, 9]。また、移行後のビルド時間やアプリの実行性能に関する定量的なデータも開示されていません[9]。

Asanaは、RTLの採用によって実装詳細ではなく振る舞いを検証するテストモデルへ移行できたという質的な評価を示しています[9]。現時点で立証されているのは、検証ループと全件レビューを経て移行を完了したという事実です[9, 16]。

誰に影響するか：エンジニアの役割変化と長期技術負債への向き合い方

この事例は、開発組織における役割分担や技術負債へのアプローチに変化をもたらします。

現場のエンジニアにとっては、業務の重心が変化します。テストコードを1行ずつ手作業で書き換える実装作業から、目標を定義し、検証環境を構築し、エージェントの生成結果を評価・承認するオーケストレーターへの移行が進むと解釈されています[4, 12]。採用においても、単純な実装要員を確保すること以上に、CI環境の整備やテスト設計、エージェントの出力を正しく評価できる能力が重視される可能性があります[13]。

技術責任者（VPoEやCTO）にとっては、長期的な技術負債の解消方針が変わります[13]。従来は数年単位の工数が見込まれて着手を断念していた大規模な移行やリファクタリング（コードの再構築）について、完了条件と検証環境を整えた上で、短期間のエージェント実験を通じて実現性を再評価できるようになります[12, 13]。Asana自身も、従来は数年を要すると考えていた他の移行や性能課題へのエージェント適用を検討しています[12]。

エンドユーザーへの影響としては、現時点で直接的なUIや操作性の改善が確認されたわけではありません[13]。しかし、テストが内部実装に依存しにくくなったことで、将来的なReactのバージョン更新や新機能の追加を安全に進めやすくなる間接的な効果が期待されます[10, 13]。

ただし、この成果をすべての開発タスクにそのまま当てはめることはできません[13, 16]。今回のテスト移行は、問題がディレクトリ単位に分解可能で、受け入れ条件が明確であり、自動検証環境が揃っていたからこそ短期間で完遂できました[1, 2, 13]。仕様が曖昧なタスクや横断的な設計判断が求められるプロジェクトでは、同様の効果が得られない可能性がある点に留意が必要です[16]。