はじめに

こんにちは。プロダクト開発部部長の村上です。

「askenのエンジニアの方、初めてお会いしました」——セミナーやカンファレンスで、こう声をかけられることが何度もありました。「あすけん」というサービスは知っていただけている一方で、それを作っているエンジニア組織のことは、ほとんど知られていない。それが正直な実感でした。

ですが私たちは、社外から見ても面白い挑戦をしているという自負があります。2026年2月のDevelopers Summit 2026（デブサミ2026）では、弊社PdM・伊藤とエンジニア・岩間によるセッション「Vibe Coding起点での新機能開発で「あすけん」が乗り超えた壁～PdM&エンジニアの新たな共創プロセス～」が、公募賞1位（同率）・ベストスピーカー賞7位をいただきました。AIを使った開発のリアルが、社外の方々にも響いた手応えがありました。

だからこそ、私たちが日々どんなことに挑んでいるのかを、きちんと言葉にして届けていきたい。そして、askenエンジニア組織の知名度をもっと上げていきたい。そう考えた私たちは、毎月、組織の試行錯誤の記録をお届けすることにしました。第1回となる今回は、私たちが目指しているエンジニアリングのビジョンについてお話しします。

「AI Native」というビジョン

AIを「便利なツールとして使う」段階は、もう通り過ぎたと感じています。次に問うべきは、AIを前提に、組織のあり方も、プロダクトのあり方も、どう作り変えるかです。開発の現場ではエンジニアの働き方そのものが変わり、プロダクト側では、ユーザーに届けられる価値そのものが変わろうとしています。

この流れの中で、私たちも「AI Nativeな開発組織へ進化する」をビジョンとして掲げています。この言葉だけだと、だいぶ抽象的で「そらそうだよね」という感じだと思います（笑）。なので、もう少し具体的にします。これは、2つの方向を同時に変えていくことを意味します。ひとつは、プロダクトが届ける価値そのものをAIで変えること。もうひとつは、開発の進め方を変えることです。

前者は、AIを組み込むことで「あすけん」独自の新しい価値を作り出すこと。後者の象徴が、PRD（プロダクト要求仕様）を渡せば、プロダクトが出力される——そんな開発のあり方です。冒頭で紹介したデブサミのセッションでお話しした「動くPRD」は、まさにこの方向を向いた実践のひとつです。プロダクトの中身も、開発のやり方も、AIを前提に作り直す。それが私たちの言う「AI Native」です。

この記事では、まず私たちが目指している状態を具体的に語り、その上で、そこへ至るために実際に何をやってきたかを共有します。

私たちが目指す2つの到達像

① プロダクトへのAI活用で、「あすけん」独自の新しい価値を作る

なぜ、プロダクトの価値そのものをAIで変えるのか。

私たちが届けたいのは、毎日の健康管理を「もっとラクに、もっと自分好みに」できる体験です。健康管理は、続けることがいちばん難しい。記録はつい面倒になり、アドバイスは誰にでも当てはまる一般論になりがちです。

AIの進化は、ここを根本から変えられる可能性を持っています。記録する・ふりかえる・自分に合った提案を受け取る——その一つひとつを、これまでより圧倒的にラクに、そして一人ひとりに寄り添った体験へと進化させられる。だからこそ私たちは、AIを「あすけん」の中核に組み込んでいきます。到達像は、ユーザー一人ひとりが「記録も、振り返りも、自分に合った提案も、あすけんとともに続けられるのが当たり前」という体験を、毎日ストレスなく受け取れている状態です。これを実現するために、弊社が持つ様々なデータにAIを組み合わせ、あすけんならではの新しい価値を創出していきます。その第一歩として、2026年内に順次リリースを予定している新機能をあすけんプレミアム機能拡充のお知らせでご紹介しています。あわせてご覧ください。

新しいAIモデルは次々と登場しており、私たちも常に情報収集を続けています。ただ、「とにかく賢いモデルを使えばいい」というわけではありません。プロダクトの体験として成立させるうえで重要になるのが、精度・レイテンシー・コストのバランスです。

用途に合わせて適切なモデルを選択できること。 汎用モデル／OSSモデル／独自モデルを使い分け、精度とコスト効率の最適化を続けています。
最適なアーキテクチャを模索し続けること。 機能ごとに、単一のモデル呼び出しで完結させるか、複数のステップに分けて精度を取りにいくか——そうした構成の判断を、体験の質とコストに突き合わせて選び続けています。
AIが活用できる形にデータを磨き上げること。 AIが使いやすく、かつプライバシーにも配慮したデータ整備を進めています。

どれか一つに振り切れば成立する話ではありません。ユーザーが毎日心地よく使える体験にするには、この3つのバランスを取り続ける地道な作業が要ります。

② Agenticな開発で、開発の進め方そのものを変える

なぜ、開発の進め方そのものを変えるのか。

2025年以降、AI Agentの進化は凄まじく、エンジニアリングのやり方そのものを変えつつあります。弊社でもエンジニア全員が Claude Code や Devin を中心に活用し、アウトプットの量は大きく向上しました。

ただ、今のやり方には限界も見えています。既存プロセスの一部分ずつをAIに委ねている状態で、工程の継ぎ目では人間がボトルネックになっている。AIのポテンシャルを、まだ活かしきれていません。

目指すのは、チームメンバーに仕事を任せるように、Agentに仕事を任せること。人間は方針を決め、実行はAIに委ねる。これが実現すれば、アウトプットの量が増え、検証できる価値仮説の数も増えるため、プロダクトの成長速度を大幅に高められます。私たちは、ここへ最速でたどり着きたい。今までの開発のやり方をアンラーンする必要はありますが、エンジニア自身も新しいプロダクト開発の形を自らの手で作っていく経験を積めます。だからこそ弊社のメンバーは皆、楽しみながらこの課題に向かっています。

現時点で私たちが描く到達像は、PRDを起点に、Agentが自律してデプロイまでやり切る状態です。その方向感での、26年度の到達目標は以下です。

エンジニアがPRDをAgentにインプットし、対話しながら要件・アーキテクチャなどの基本方針をFIXする
そのFIXした情報を起点に、設計・コーディング・テストはAgentが自動でやり切る
人間は、Agentのアウトプットをサマリレベルでレビューし、デプロイに進む

では、この到達像に向けて、私たちは実際にどこまで来たのか。①と②は両輪ですが、一度に語り尽くせる話ではありません。今回はまず②「開発の進め方」の現在地に絞り、①のプロダクトへのAI活用については、回を改めて書いていきます。

現在地と、次に越える壁

この到達像は、机上のスローガンではありません。25年度、全エンジニアへのツール導入（Claude Code / Devin / Cursor）から始めた取り組みは、AI活用が「当たり前」になる段階を経て、25年度1〜3月期（2026年1〜3月）のリリースPRD数が前年同期比4.6倍に達するところまで来ました（組織面の改善も並行した複数施策の合わせ技ではあります）。その過程で得たのは、「抽象的なゴールでは、組織は同じ方向を向けない」という学びです。「どういう状態になっていたら達成と言えるか」を状態目標として言語化し、チームごとにテーマを分担して推進する体制へ切り替えました。この1年の試行錯誤の詳細は、別の記事で改めてお届けします。

そして今期。ほとんどのチームで、設計・コーディング・コードレビュー・UT（ユニットテスト）はほぼAIが出力し、人間はそのレビューに回るところまで来ました。到達像を具体的に言語化したことで方向感の共通認識が生まれ、その効果がチームの動きに表れています。

進め方は段階的です。先ほどの到達像のうち、まず設計・コーディング・テストの自動化を固め切り、その次に、PRDを起点とした要件・基本方針のFIXの自動化へ、という順で進めています。設計、コーディング、テストが安定して回っていなければ、要件のFIXをつないでも「PRDを渡せば出力される」状態にはならないので土台から固めています。

一方で、課題もはっきり見えています。大きくは二点です。

UTから先のE2E（End-to-End）テストは、まだ人手が中心。 アプリ・バックエンド・インフラを結合した検証は、その多くを人が行っているのが現状です。単体テストと違い、複数レイヤーをまたいだ状態の再現やテスト環境の準備コストが大きく、Agentに任せ切るための土台づくりがこれからだからです。
工程が、まだ作業ごとに分断されている。 個々の工程の自動化は進んだ一方で、工程から工程への継ぎ目では、いまも人が判断を挟んで橋渡ししています。到達像①で「今のやり方の限界」として挙げた、継ぎ目で人間がボトルネックになる構図がまだ残っており、「PRDを渡せば出力される」という地続きの状態には届いていません。

ここが、次に越えるべき壁です。

エンジニアの役割は、これからどう変わるか

もう少し先の、未来の話もしておきます。

Agentに仕事を任せるスタイルは、遠からずスタンダードになる——私たちはそう見ています。そうなったとき、エンジニアが直接コードを書く場面は少なくなっていくはずです。

その世界線で、エンジニアの役割はこう変わると予想しています。

Agentの成果が最大化されるよう、ハーネスやプロセスをメンテナンスする。 良い出力を引き出す環境設計そのものが、エンジニアの仕事になります。
PdMのようにプロダクト価値を定義し、仮説検証を自ら回す。 「何を作るべきか」を見極め、検証する力の比重が増していきます。
AIをプロダクトの価値へと変換する。 到達像①で挙げた、用途に応じたモデルの選択、精度・レイテンシー・コストを見据えたアーキテクチャの判断、AIが活用できる形へのデータの磨き上げ——これらをユーザー体験に落とし込める人材の重要性は、さらに増していきます。

ただ、ひとつ強調しておきたい前提があります。AIはあくまで、ソフトウェアエンジニアリングの力を「増幅」する道具だということです。コードを書く量が減っても、Agentの出力の良し悪しを見極め、設計を判断し、より良い方向へ導けるのは、ソフトウェアエンジニアリングの土台を持つ人だけです。

設計やアーキテクチャはもちろん、テスト戦略や、DevOps・CI/CDといった「どう作り、どう届けるか」の知識も欠かせません。むしろAgentにデプロイまで任せる世界では、こうした開発プロセス全体への理解こそが、良いハーネスや任せ方を設計するための前提になります。AIを使いこなすほど、この土台の深さがそのまま成果の差になって表れる。だからこそ私たちは、AI活用の推進と同じ熱量で、エンジニアリングの基礎を磨き続けることを大切にしています。

もっとも、この予測も現時点のものであり、状況が変われば役割の描き方も更新していきます。ただ、予測が外れること自体は恐れていません。目指す方向を自分たちの言葉で持っていること——それが、変化に最速で適応するための条件だと考え、現場のメンバーとディスカッションしながら言語化を続けています。

まとめ

この記事の要点を整理します。

askenエンジニア組織が掲げるビジョンは、AI Nativeな開発組織への進化。「プロダクトが届ける価値そのもの」と「開発の進め方そのもの」の2軸を、AIを前提に作り変えることを意味します。
今回中心に取り上げた②開発の進め方では、PRDを起点にAgentが自律してデプロイまでやり切る状態を目標に掲げています。すでに設計・コーディング・テストの多くをAIが出力する段階まで来ており、残る壁は工程の分断です。
ここまで来られたのは、抽象的なスローガンではなく具体的な「状態目標」を言語化し、チームごとにテーマを分担して課題に向き合ってきたから。その先で、エンジニアの役割そのものも変わっていきます。

挑戦はまだ始まったばかりです。これから定期的に、askenエンジニア組織の試行錯誤を、うまくいった話も、つまずいた話も、テックブログで発信していきます。次回以降は、現場のエンジニアたちも書き手として加わっていきます。ぜひ、また読みにきてください。