AIがコードを書くようになると、つい「じゃあ開発は全部速くなるんでしょ」と思いますよね。気持ちは分かる。炊飯器のボタンを押したらカレーまで完成してほしい、あの感じです。でも、askenの事例はそこにきれいなブレーキをかけました。
食事管理アプリ「あすけん」を運営するaskenは、PdM主導でAIにコードを書かせる「バイブコーディング」を取り入れ、「動くPRD」を作りました。ところが、AIおまかせ記録の本番実装は通常2人月の想定が6人月に膨らみました。それでも同社が得た価値は小さくない。今回の本題は、AIで本当に短くなるのは実装時間そのものではなく、何なのかです。
食事管理アプリ「あすけん」がバイブコーディングで新機能を試作する新たな開発プロセスを確立。その過程では通常2人月の開発が6人月まで膨らむという想定外の工数増に直面。この壁をどう乗り越え、新たな開発手法は現場にどのような利益をもたらしたのか。（1/2 ページ）
今回の登場人物
- ITmedia AI＋: 今回の入口記事を報じた媒体です。askenの開発チームとPdMが、AIをどう現場に入れたかを詳しく伝えています。
- asken: AI食事管理アプリ「あすけん」を開発・運営する日本企業です。食と健康のサービスをやっていて、今回の実験の当事者です。
- PdM: プロダクトマネージャーのことです。何を作るか、誰の課題をどう解くかをまとめる役割で、いわば「機能の設計図を描く人」です。
- バイブコーディング: AIにコードを書かせながら試作を進めるやり方です。人が全部を手で打つより速い場面がありますが、雑に使うと後で片付けが大変です。部屋を一瞬で散らかせる才能だけ高いルンバ、みたいなことも起きます。
- 動くPRD: PRDはプロダクト要求仕様書です。普通は文書ですが、askenは実際に動くプロトタイプと利用ログ、アンケート、PdMのコメントをまとめたものを「動くPRD」と呼びました。つまり「読む仕様書」ではなく「触れる仕様書」です。
- あすけんラボ: askenが作った試作用の専用基盤です。本番に近い認証やAPIを使いながら、ユーザーが実際に触れる形でプロトタイプを公開できます。
- 非機能要件: 機能そのもの以外の品質条件です。例えば速さ、監視しやすさ、保守しやすさ、安全性など。表では元気に動いていても、裏でゼーゼーしていたらここが弱い、という話です。
何が起きたか
ITmedia AI＋の記事によると、askenは従来、デザインツール上のモックアップをユーザーに見せて感想を集めていました。ただ、その方法だと実際の生活の中で機能を使った感触までは確かめにくく、リリースしても反応が伸びないことがあったといいます。
そこで同社は、PdMがAIコーディングツールを使って試作品を作り、ユーザーに実際に使ってもらうやり方へ進みました。専用基盤の「あすけんラボ」を用意し、AIに食事内容を話しかけたり文章で入れたりすると、AIがメニューを判別して記録を作る「AIおまかせ記録」の検証に使ったわけです。
この試作から育った情報を、askenは「動くPRD」と呼びました。文書だけで仕様を説明するのでなく、実際に触れる試作品にユーザーの反応やPdMの意図まで重ねる。なるほど、会議で10回説明するより、1回触ってもらった方が早い場面はあります。
ただし、ここで話が終われば「AIで爆速でした」で拍手して帰れるんですが、現実はそう甘くありません。askenは、この動くPRDをそのまま本番に流用できるのではと考えた結果、通常2人月ほどの開発が6人月に膨らんだといいます。
ここが本題
中心問いへの答えを先に言うと、AIがコードを書く時代に本当に短縮されるのは、キーボードを打つ時間そのものより、「この機能は本当に作る価値があるのか」を確かめるまでの距離です。別の言い方をすると、実装前の不確実性と、部門どうしのすれ違いを減らす時間です。
入口記事でaskenの担当者は、「労働時間が減ったわけではない」と話しています。ここ、かなり大事です。AIを入れたのに総労働時間がそのまま、あるいは一時的に増えるなら、「AIで時短」という分かりやすい看板は外れます。
それでも価値があるのは、試作品の段階で「これは刺さらないから本番開発に渡さない」と判断できるからです。つまり、短くなるのは実装作業そのものではなく、外れくじに本気で人手を突っ込む時間なんです。これ、地味だけどかなり大きい。派手なショートカットではなく、ムダな遠回りを減らす感じですね。
なぜ工数はむしろ増えたのか
ITmediaの記事でaskenは、工数増の理由をかなり具体的に話しています。LLMのAPI応答速度が目標を下回ったこと、ログやメトリクス、トレーシングがなく監視やエラー調査がしにくかったこと、そして保守しにくいコードで中身の把握に時間がかかったことです。
要するに、試作品としては役に立っても、本番運用に必要な筋肉が足りなかった。文化祭の出し物としては盛り上がるけど、毎日営業する店としてはレジも在庫表も防火管理も足りていない、みたいな話です。
ここで効いてくるのが、機能要件と非機能要件の違いです。動くPRDは「何ができるか」をかなり前に進めます。ユーザーも社内も、使えば魅力が分かる。でも「どれくらい速く動くか」「障害時に追えるか」「半年後に直しやすいか」までは自動で保証してくれません。
askenはこの反省から、動くPRDをそのまま本番コードとして見るのではなく、要件定義と基本設計の材料として扱う方向へ寄せました。AIで試作品を解析し、機能要件の把握を効率化しつつ、非機能要件の定義や設計は従来の手法で進める。つまり「AIが作ったから全部近道」はやめて、「AIで早く見えたものを、人間がちゃんと本番化する」に切り替えたわけです。
短くなったのは「ムダ打ち」
では、askenが実際に縮めたのは何か。いちばんしっくりくるのは、本番開発に入る前のムダ打ちです。
動くPRDがあると、PdM、エンジニア、デザイナーの会話が変わります。記事では、PdM自身がClaude CodeとAWS Documentation MCPを使ってインフラ構成のたたき台を作れたことで、インフラエンジニアとの議論がしやすくなったとされています。これまで「こういうの作りたいんですけど、ええと、雰囲気としてはですね……」で始まっていた会話が、「これが今の試作です。ここが詰まっています」に変わる。議論の解像度が一段上がるんです。
しかも、あすけんラボでうまくいかなかったものは、本番開発に回さない判断ができます。担当者が言う通り、これは確度の低い機能に本気の開発工数を入れずに済むということです。ロードマップを前に進める、という表現は少しビジネスっぽいですが、要は「当たりそうな球だけ打席に立たせやすくなる」ということです。全部フルスイングしてから三振を数えるより、だいぶ健全です。
さらに、時間だけでなく心理的なコストも減っています。記事では、時間をかけて作った機能がユーザーに使われないことが減り、精神的に楽になったとも説明されています。開発の話でメンタルを軽く見ると危ないんですが、これは普通に重要です。誰だって、何週間も作って「使われませんでした」はしんどいですからね。
日本の読者にとっての意味
この話が日本の読者にとって大事なのは、「AIで開発が速くなるか」という雑な二択をやめる材料になるからです。特に日本企業では、AI導入の議論が「何人月減るの」「何人減らせるの」に寄りがちです。でもaskenの事例は、そこだけを見ると本質を取り逃がすと示しました。
本当に変わるのは、企画と開発の間の壁かもしれません。文書だけでは伝わりにくかった機能の価値を、試作品で先に見せる。試してもらって、刺さらなければ早く引く。刺さるなら、そこから本番品質へ上げる。この順番が回るなら、企業にとってのAI活用は「実装の省力化」だけではなく、「意思決定の精度を上げる装置」になりえます。
逆に言うと、AIが書いたコードをそのまま本番へ流し込めば勝ち、とはならないわけです。そこを勘違いすると、2人月が6人月になる。数字が急に教育的なんですよね。かなり痛い授業料です。
まとめ
askenの事例が示したのは、AIで短くなるのは実装時間そのものではなく、本番開発に入る前の不確実性、見極め、そして部署どうしのすれ違いだということです。
動くPRDは、魔法の完成品ではありません。むしろ、本番に必要な品質を省略すると手戻りは大きくなる。でも、試作品を通じてユーザーの反応と社内の合意形成を前に進められるなら、ムダな本番実装を減らせる。AI時代の開発で短くなるのは「書く時間」より先に、「これ作る意味ある？」で迷う時間なのかもしれません。