- Asanaが「5年かかる」と見積もっていた作業を、AIエージェントで2週間で終わらせた
- 費用は約9億円の見積もりに対して、実際は約180万円(モデル・インフラ費)
- 指示はたった5文。最大4体のエージェントが、それぞれ別のコードのコピーで並列作業した
- 人間のエンジニアは1日2回進捗を見て、提案された変更をすべてレビューした
- 日本の「2025年の崖」問題にも直結する、技術的負債の返し方が変わる話
「直したいけど、直す時間がない」。エンジニアなら誰もが抱えるこの悩みを、Asanaは2週間で片づけました。しかも費用は約180万円。同じ作業を人手でやると5年・約9億円という見積もりだったものです。何が起きたのか、そして日本の会社にも使える話なのかを整理します。
5年の見積もりが、2週間で終わった
2026年8月、OpenAIがAsana(アサナ)の事例を公開しました。
Asanaは、チームの仕事を管理するクラウドサービスの会社です。Facebook共同創業者のダスティン・モスコビッツらが2008年に立ち上げ、日本でもサイバーエージェントやSmartNewsなどが使っています。
そのAsanaが抱えていたのが、Enzyme(エンザイム)という古いテスト用の道具でした。これを取り除く作業は「最低でも5年かかる」と社内で見積もられていた大仕事です。
ところが実際にかかったのは、エンジニアの手を動かした時間で1.5週間、カレンダー上で2週間。使ったのはOpenAIのCodex(コーデックス)というAIコーディングエージェントです。
数字だけ見ると信じがたい話ですが、なぜこれが可能だったのかには、はっきりした理由があります。
Enzymeという「触れない地雷」
テストコードは、そう簡単に捨てられない
そもそもEnzymeとは何でしょうか。
これはReactというウェブ画面を作る技術のために作られた、テスト用のライブラリ(部品集)です。書いたプログラムが正しく動くかを自動で確認するために使われます。
問題は、Enzymeがすでに活発なメンテナンスから外れていたこと。開発が止まった道具を使い続けると、その道具が新しい環境に対応しなくなります。
Asanaの場合、Enzymeがフロントエンド(利用者が見る画面側)を新しくするときの足かせになっていました。Reactを新しいバージョンに上げたくても、Enzymeで書かれたテストが動かなくなるからです。
なぜ人手だと5年もかかるのか
ではEnzymeをやめて、後継のReact Testing Libraryに移せばいい——そう思いますよね。
しかし、これが難物です。EnzymeとReact Testing Libraryは、テストの考え方そのものが違います。
Enzymeは「部品の中身が正しいか」を見る作りで、React Testing Libraryは「利用者から見て正しく見えるか」を見る作りです。機械的に置き換えられず、1つ1つ書き直す必要があります。
大企業の画面には、こうしたテストが何千、何万と積み上がっています。1件あたり10分で済んだとしても、数万件なら気の遠くなる話です。だから「5年」という見積もりが出てくるわけです。
そして、この手の作業には誰も手を挙げません。新機能を作れば評価されますが、テストの書き換えは何も新しいものを生まないからです。技術的負債が10年放置される理由は、たいていここにあります。
5文のプロンプトと、4体の並列エージェント
やり方はシンプルだった
Asanaがやったことは、驚くほど簡素です。
まず、たった5文のプロンプト(AIへの指示文)を書きました。何百ページもの仕様書ではありません。
次に、最大4体のコーディングエージェントを同時に走らせました。ポイントは、それぞれが別々のコードのコピーの中で作業したことです。
同じ場所を4人でいじれば衝突しますが、コピーを4つ用意して分担すれば、お互いを邪魔しません。倉庫の在庫整理を4人でやるとき、同じ棚に群がるのではなく棚を分けるのと同じ発想です。
人間は「捨てなかった」
ここが最も重要な部分です。
担当エンジニアは1日2回、進捗を確認しました。そして、AIが提案した変更をすべてレビューして承認しました。
つまり、これは「AIに丸投げしたら勝手に終わっていた」という話ではありません。人間が判断の責任を持ち、AIが手数を担当する。この役割分担が成立したから成功したのです。
AIコーディングの成功事例を読むときは、ここを見落とさないようにしたいところです。
9億円が180万円に:コスト構造が変わった
金額を並べると、変化の大きさがはっきりします。
- 従来の見積もり:最低5年、約600万ドル(1ドル150円換算で約9億円)
- 実際にかかった費用:約1万2000ドル(同換算で約180万円)
- 期間:5年 → 2週間(エンジニアの実作業は1.5週間)
金額でおよそ500分の1、期間でおよそ130分の1です。
ただし、この180万円はモデル利用料とインフラ費用を指します。レビューしたエンジニアの人件費や、事前の設計にかけた時間は別です。それでも桁が2つ以上変わったのは事実でしょう。
そして本当に効いてくるのは、金額そのものより「やる価値があるかの判断が変わる」ことです。
9億円かかる改修は、経営会議で却下されます。180万円なら、部長の裁量で試せます。Asana自身も、他の移行作業や書き直し、性能改善など「年単位でかかると思って諦めていた課題」にエージェントを試し始めたと述べています。
Codex以外の選択肢は?主要エージェント比較
「うちもやってみたい」と思ったとき、道具はCodexだけではありません。2026年時点の主要な選択肢を整理します。
- OpenAI Codex:クラウドで複数タスクを走らせる形が得意。個人向けは月20ドルのPlusから200ドルのProまで。2026年4月にトークン単位の課金へ移行し、GPT-5.5系のモデルを採用しています
- Claude Code:ターミナル(黒い画面)で動くタイプ。長い文脈を扱えるため、大規模なリファクタリング(構造の作り直し)に強いと評価されています
- Cursor:エディタに組み込まれた形。日々のコード編集を書きながら直すのに最も手触りが良いタイプです
- Devin:最も自律性が高く、タスクを投げて結果だけ見るという非同期の使い方を想定しています
実務では「重い改修はClaude Code、日常編集はCursor、PRレビューの自動化はCodex」のように併用する現場も多いようです。
Asanaの事例で重要なのは、実は道具の名前ではありません。「並列で走らせる」「コピーを分ける」「人間が全部レビューする」という進め方のほうです。この型は、どのエージェントでも再現できます。
日本企業にとっての意味:「2025年の崖」との関係
この話、日本にとっては他人事ではありません。
経済産業省は2018年のDXレポートで、古いシステムを刷新できないと2025年以降に最大で年間12兆円の経済損失が生じる可能性を指摘しました。いわゆる「2025年の崖」です。
その2025年を過ぎた調査では、崖を「完全に乗り越えられた」と答えた企業はわずか7%。約4割が依然として深刻な課題を抱えているとされています。
崖の正体は、Asanaが直面したものと構造的に同じです。直す価値はわかっているが、人手と年月が足りないから誰も着手しない——この一点に尽きます。
身近な例で考えてみましょう。ある製造業の情報システム部門に、20年前に作られた生産管理システムがあるとします。作った人はもう社内にいません。仕様書もありません。動いてはいるので誰も触りません。
あるいは、地方の信用金庫で、帳票を出すためだけに古いバージョンのソフトが残っているケース。セキュリティ更新が止まっているのに、置き換えの見積もりが3億円と出て話が止まる、という光景です。
小売チェーンの本部で、店舗別の売上集計をExcelマクロが担っていて、作った担当者が退職して以来「怖くて誰も直せない」というのも同じ構図でしょう。
Asanaの事例が示したのは、こうした案件の見積もりの前提が変わりつつあるということです。3億円で止まっていた話が、まず数十万円の実験から始められるかもしれません。
真似する前に知っておきたい3つの落とし穴
1. テストがない現場では再現しにくい
Asanaがうまくいった大きな理由は、作業対象がテストコードそのものだったことです。
変更が正しいかを機械的に判定できる状態だったため、AIの成果をすぐ検証できました。逆に、テストがまったくない古いシステムでは「AIが直したものが正しいか」を確かめる手段がありません。
最初の一歩は、移行そのものより検証できる状態を作ることかもしれません。
2. レビューする人が必ず要る
1日2回の確認と全件レビューを、Asanaは省きませんでした。
AIが100件のコードを書けば、レビューすべき100件が生まれます。書く速度は上がりますが、確認する速度は人間のままです。ここが新しいボトルネック(詰まりどころ)になります。
3. コードを外部に出せるかを先に確認する
金融や医療、公共分野では、ソースコードを外部のAIサービスに送ること自体が規程で難しい場合があります。
技術の問題より先に、社内規程と契約条件の確認が実務上の関門になりがちです。試す前に、情報システム部門と法務に一度相談しておくと手戻りが減ります。
よくある質問(FAQ)
Q1. 本当に人間はほとんど何もしていないのですか?
いいえ。指示文の設計、1日2回の進捗確認、そして提案された変更の全件レビューは人間が担当しています。手を動かす部分をAIが引き受けた、という理解が正確です。
Q2. 約180万円という費用には何が含まれますか?
公表されているのはモデル利用料とインフラ費用の合計です。エンジニアの人件費は含まれません。とはいえ実作業が1.5週間なので、人件費を足しても従来見積もりとの差は大きいままです。
Q3. 個人開発や小さい会社でも同じことができますか?
規模は小さくなりますが、考え方は使えます。Codexなら月20ドルのプランから試せますし、Claude CodeやCursorにも同等の機能があります。まずは影響範囲が狭く、テストで検証できる部分から始めるのが安全です。
Q4. 日本語のコードコメントや設計書でも通用しますか?
主要なコーディングエージェントは日本語の指示・コメントを扱えます。ただし公開されている成功事例の多くは英語圏のものです。日本語ドキュメントが多い環境では、小さな範囲で試して精度を確かめてから広げるのが現実的でしょう。
Q5. AIエージェントが増えるとエンジニアの仕事は減りますか?
今回の事例では、むしろこれまで着手できなかった仕事が実行可能になりました。Asanaは他の移行や性能改善にも展開すると述べています。仕事の中身が「書く」から「決める・確かめる」に寄っていく、と見るのが自然です。
まとめ
- Asanaは5年・約9億円と見積もっていたEnzyme撤去を、2週間・約180万円で完了した
- 指示は5文、最大4体のエージェントが別々のコードのコピーで並列作業した
- エンジニアは1日2回確認し、変更を全件レビューしている(丸投げではない)
- 金額より重要なのは「やるかどうかの判断基準が変わった」こと
- 日本の「2025年の崖」は7%しか越えられておらず、同じ構図の課題が大量に眠っている
- 再現の鍵は道具の名前ではなく、並列・分離・全件レビューという進め方
まずは自社で「高すぎて諦めた改修リスト」を1枚書き出し、その中でテストが書ける対象を1つ選んでみてください。

