ワークマネジメントツールを提供する米Asanaは、OpenAIのAIコーディングエージェント「Codex」を使って、5年かかると見積もられていた技術的負債の解消を2週間で完了したと公表しました。かかった費用はモデルとインフラで約12,000ドル。従来の計画では約$6M（6 million ドル）相当の人員コストが見込まれていた作業です。世界で100万を超える組織が使うプロダクトを支える現場で、AIエージェントがどう運用されたのか。OpenAIが公開した導入事例から、実務の詳細を整理します。
何をしたか：古いテスト基盤の全面除去
対象となったのは、Enzymeという古いテストシステムの除去です。EnzymeはReactコンポーネントのテストに広く使われてきましたが、Asanaのコードベースでは老朽化して他の基盤更新の足かせになっており、「取り除きたいが、手作業では割に合わない」という典型的な技術的負債になっていました。人手で移行した場合の見積もりは5年分の作業量。優先順位を付けるたびに後回しにされてきた種類の仕事です。
Asanaのエンジニアリングチームは、この移行をCodexに任せる実験を行いました。進め方が具体的に公表されています。エンジニアは5文ほどの短いプロンプトで方針を指示し、Codexのエージェントを最大4体並行で走らせて、コードベース全体のテストを次々と新しい仕組みへ書き換えさせました。人間の役割は、書き換え結果のレビューと、エージェントが迷った箇所の軌道修正です。
結果として、移行の実作業は2週間（カレンダーベース）で完了しました。エンジニアが投じた工数は1.5週間分。見積もり5年の作業に対して、人間の関与はごくわずかで済んだことになります。
なぜテスト基盤の移行が5年もかかる見積もりになるのか、補足しておきます。テストコードはプロダクトの品質を守る防護柵で、数が膨大なうえ、一つひとつの書き換えに「動作が変わっていないことの確認」が伴います。新機能と違って売上に直結しないため、経営判断としても優先順位が上がりにくい。結果として、古い基盤が残り続け、基盤が古いせいで他の改善も遅くなるという悪循環に陥ります。Asanaの5年という見積もりは、この種の負債の典型的な重さを示しています。
Codexに任せた作業の性質も重要です。テストの書き換えは、変換のパターンが決まっており、成否をテストの実行結果で機械的に判定できる作業です。エージェントが書き換えを間違えれば、テストが落ちて分かります。この自己検証の仕組みがあるからこそ、複数のエージェントを並行で走らせても品質を保てました。人間のレビューは最後の関門として機能し、判定の大部分は自動化されていたと読めます。
公表されている結果
数字を整理します。従来見積もりは5年・約$6M（人員コストベース）。実績は2週間・約12,000ドル（モデルとインフラの費用）・エンジニア工数1.5週間分。単純な比較はできませんが、公表値だけを見ても、費用と期間の桁が変わっています。
AsanaのCTOであるAmritansh Raghav氏は、この結果について「もはや直せないと思っていた種類の負債が、直せる対象になった」という趣旨のコメントを寄せています。重要なのは、この事例が新機能の開発ではなく、後回しにされ続けた保守作業だという点です。派手さはないが確実に開発速度を蝕む負債の返済が、AIエージェントの得意分野として実証された形です。
Asanaは世界中の企業にワークマネジメントの基盤を提供しており、公式サイトによれば同社のミッションは組織横断の協働を支えることにあります。プロダクトの信頼性に直結するテスト基盤の刷新を、AIエージェント主導でやり切ったことは、同規模の他社にとっても参考値になります。
この事例が他社に与える影響は、経営層の意思決定の変化です。「5年かかるからやらない」と棚上げされてきた作業のリストは、どの会社にもあります。その見積もりの前提が変わったとすれば、棚上げリストを再点検する動機が生まれます。AsanaのCTOのコメントが示すのは、まさに「直せないと思っていたものが直せる対象になった」という認識の転換です。
指示の与え方も注目されています。エンジニアが書いたのは5文ほどのプロンプトでした。詳細な仕様書ではなく、方針を短く示してエージェントに委ねる。これは、対象作業のパターンが明確で、正誤の判定が自動化されている場合に成立する進め方です。逆にいえば、判定基準が曖昧な仕事に短い指示を出せば、成果物の品質は安定しません。プロンプトの長さではなく、判定基準の明確さが成否を決めます。
日本の実務者が参考にできる点
この事例は開発組織の話ですが、AI導入を検討するすべての実務者に共通する示唆があります。
第一に、AIエージェントに任せる仕事の選び方です。Asanaが選んだのは、ゴールが明確で、正解の判定が機械的にでき（テストが通るかどうか）、量が膨大な作業でした。創造性より根気が要る仕事ほどエージェント向きだという構図は、マーケティングでいえば大量ページのメタ情報整備、過去コンテンツの棚卸し、データクレンジングなどに置き換えられます。
第二に、人間の役割の設計です。Asanaのエンジニアは作業をしていません。方針を短く指示し、並行して走るエージェントの成果物をレビューする。この「指示とレビューに徹する」体制が、1.5週間という人間側工数を実現しています。AIに作業を渡すときは、人間の仕事を「作る」から「検品する」へ再定義できるかが成否を分けます。
第三に、費用対効果の測り方です。約12,000ドルという費用は、5年分の人件費見積もりと比べて初めて意味を持ちます。AI活用の投資判断では、「AIにかかる費用」単体ではなく、「同じ成果を人手で出した場合の費用」との比較で考える必要があります。後回しにしている作業の人件費見積もりを持っておくことが、判断の前提になります。
なお、この結果はAsanaのテスト基盤という条件がそろった対象での実績であり、あらゆる開発作業が同じ倍率で速くなるわけではありません。成功の背景には、成果を機械的に検証できるテストという領域特性があります。
この事例をどう読むか
公表された数値は印象的ですが、読み方には注意が要ります。5年という見積もりは、実際に5年かけて実行された結果ではなく、着手前の想定です。同様に約$6Mも人員コストベースの見積もりで、実支出ではありません。比較されているのは「想定」と「実績」であり、条件が完全に対等ではないことは踏まえておくべきです。
そのうえで、この事例の価値は倍率の大きさそのものよりも、対象の選び方にあります。パターン化された大量の書き換え作業で、成否を機械が判定でき、失敗しても本番サービスに影響しない領域。この3条件がそろう仕事は、開発以外の部署にも存在します。大量のデータ整形、規則の決まった文書の変換、フォーマット統一などが該当します。
自社の業務を棚卸しするとき、「AIにできそうか」ではなく「機械が正誤を判定できるか」を基準にすると、着手すべき対象が絞り込めます。Asanaの事例は、その基準の有効性を実績で示したものだと読めます。
出典と注記
この記事はOpenAIが公開した導入事例とAsanaの公式サイトのみを出典とし、期間・費用・体制の数値は原文の表記のまま記載しました（$6Mなどの略記も原文どおり）。移行の技術的な手順の詳細や、その後の保守状況は公表されていません。為替換算は行っていません。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。