5年かかる作業を2週間で終わらせた：AsanaがAIコーディングで実現したこと

AsanaがOpenAIのCodexを使い、5年かかると見積もられていた作業を2週間で終わらせた。この話が技術者コミュニティで広がっているのは、単に「速かった」からではありません。プロジェクトの前提そのものが変わった事例として注目されているからです。この記事では、何が起きたのか・なぜそれが重要なのか・非エンジニアの会社員にとって何を意味するのかを整理します。

何が起きたのか

Asanaは、プロジェクト管理ツールとして世界中の企業に使われているSaaSサービスです。その開発チームが長年先送りにしてきた技術的な宿題がありました。フロントエンド（画面側）のテストコードを、古いフレームワーク「Enzyme」から「React Testing Library」へ移行する作業です。テストコードとは、ソフトウェアが正しく動くかどうかを自動で確認するプログラムのこと。これが古いままだと、新機能を追加するたびに問題が起きやすくなります。

Asanaの開発チームはこの移行作業を「あと5年かかる」と見ていました。理由は単純で、テストコードの量が膨大なうえ、書き換えは機械的な作業の繰り返しが多く、エンジニアが本来やりたい仕事とは言いにくい。優先度が上がらないまま、ずっと後回しになっていた案件です。それをCodexを使って2週間で完了させた、というのが今回の話です。

5年と2週間の差はどこから生まれたか

CodexはOpenAIが開発したAIコーディングエージェントで、コードを読んで・理解して・書き換えるところまでを自律的に行えます。今回のAsanaのケースでは、エンジニアが「こういう形式に変換してほしい」という指示を与えると、Codexが既存のテストコードを解析し、新しい書き方に変換していく作業を大量並列で処理しました。

人間が同じ作業をすると、1ファイルずつ読んで・意図を理解して・書き換えて・動作確認するサイクルを何百回も繰り返す必要があります。疲れるし、ミスも出る。Codexはそのサイクルを並列で回せるため、時間が劇的に短縮されます。5年という見積もりは「エンジニアが他の仕事をしながら少しずつ対応する」前提でしたが、Codexを使えば「集中して一気に片付ける」が現実的な選択肢になります。

類似のパターンは他でも出てきています。下の表は、AIコーディングツールが適用されやすい作業の種類と、従来の所要時間の目安をまとめたものです。

これらに共通するのは「パターンが決まっていて量が多い」という特徴です。人間にとっては退屈で時間のかかる作業ほど、AIコーディングツールとの相性が良い傾向があります。

エンジニアじゃない自分には関係ない話か

「テストコードの移行なんて、自分の仕事には関係ない」と思うかもしれません。ただ、この話が示しているのはもう少し広い変化です。

社内のシステム部門やIT部門が「あの改修は半年後になります」「リソースが空いてから対応します」と言い続けてきた案件が、AIコーディングツールの導入で急に動き出す可能性があります。たとえば、営業部門で使っている社内ツールのUIが使いにくいまま放置されている場合。これまでは「開発工数がないから」という理由でずっと後回しだったものが、Codexのようなツールを使えば短期間で改善できるかもしれません。

40代の管理職で、部門横断のシステム改修を何年も要望し続けている方は、「AIコーディングで工数を圧縮できないか」という切り口で情報システム部門と話してみる価値があります。予算の問題ではなく工数の問題だったとすれば、状況が変わっている可能性があるからです。

「技術的負債」という言葉が会社の意思決定に絡んでくる

少し補足しておくと、Asanaが今回解消したような「古いコードを新しい形式に直す作業」は、エンジニアの世界で「技術的負債」と呼ばれます。借金と同じで、放置すると利子が膨らむ。古いコードのまま新しい機能を追加し続けると、どこかで全体が動かなくなるリスクが高まります。

多くの会社のシステムは、この技術的負債を抱えたまま運用されています。基幹システムが古すぎてクラウド移行できない、特定の担当者しかメンテできない、といった話は日本企業でもよく聞きます。ChatGPTの使い方ガイドでも触れているように、AIツールは「定型業務の自動化」という文脈で語られることが多いですが、今回のAsanaの事例は「技術的負債の解消」という、もう少し根の深い問題にも適用できることを示しています。

これはIT部門だけの話ではなく、「なぜうちのシステムはいつも改修が遅いのか」という疑問を持つ全ての会社員にとって、背景を理解するうえで重要な変化です。

この事例が示す「AIの使いどころ」

Asanaのケースで注目したいのは、Codexが「新しいものを作った」わけではない点です。すでにあるコードを、より良い形式に変換した。つまり、ゼロから何かを生み出す用途ではなく、「既存のものを整理・変換する」用途でAIが機能したということです。

この考え方は、エンジニア以外の仕事にも当てはまります。たとえば30代の経理担当者が、過去5年分のExcelフォーマットをバラバラな状態から統一形式に変換する作業を抱えているとします。これも「パターンが決まっていて量が多い」典型例です。AIを使った変換・整理の作業は、コードだけでなくデータや文書にも応用できます。プロンプトの書き方ガイドを参考にしながら、自分の業務でどこに「変換・整理」の作業が眠っているかを棚卸しするのが、実践への最初の一歩になります。

まとめ

Asanaの事例は「AIが速い」という話ではなく、「5年先送りにしていた判断が2週間で覆る」という話です。プロジェクトの前提が変わると、組織の意思決定も変わります。技術的負債の解消が現実的な選択肢になれば、IT部門の優先度の付け方も変わるし、現場からの改善要望の通りやすさも変わってくるかもしれません。あなたの会社で「ずっと後回しにされている改修」は、どこにありますか。