DeNAが推進する「AIジャーニー」。全社的な盛り上がりの裏側で、プロダクト開発の最前線ではどのような変化が起きているのでしょうか。今回は、ヘルスケア事業本部で kencom の開発を担う平子さんと刀禰さんに、現場主導で進めてきたAI活用の軌跡を伺いました。

──まずは、お二人の経歴や現在の具体的な仕事内容について教えてください。

平子 裕喜（以下、平子）： 私は2013年に新卒で入社し、今年13年目になります。最初は Mobage のバックエンドエンジニアをしていたのですが、徐々にマネジメントや採用・育成に関わることが多くなりました。現在はヘルスケア事業本部で kencom というプロダクトのエンジニアリングマネージャー（EM）を務める傍ら、アジャイルコーチや採用リード、そしてAI推進の役割なども担っています。

刀禰 有紀彦（以下、刀禰）： 私は2024年に新卒入社し、平子さんと同じヘルスケア事業本部の kencom 開発部署で主にバックエンドの開発に携わっています。直近ではAIを活用した新機能の開発に企画段階から関わり、開発・設計を担当しました。

「3ヶ月が3日に」——オンボーディングと日々の変化

──ヘルスケア部門でのAI活用について、どのような成果が出ているのでしょうか。

刀禰： 一番分かりやすいのはオンボーディング（新メンバーの立ち上がり）ですね。

まず、僕らが開発している kencom は、自治体さんや健保さんごとに仕様が違ったり、マイクロサービスが複雑に絡み合っていたりと、かなり大規模で難解なシステムです。以前は、新しいエンジニアがコードベースを理解して一人で手を動かせるようになるまで3〜4ヶ月かかるのが普通で、私も配属されてから理解するまでそれくらいの時間がかかりました。

ところが、最近来たインターン生は、2週間のうち最初の3日ぐらいでもうキャッチアップを終えました。コード品質もレビューで少しやりとりすればマージできる品質のものを出してきて、オンボーディングが本当に早く短くなったと感じてます。

──3ヶ月が3日に。一体どのようなツールをどう使ったのでしょうか。

刀禰： 全体を Devin で把握し、ピンポイントな部分を Cursor で実装するという2つのツールの使い分けです。Devin はリポジトリの全体像を俯瞰して把握しているので、まず実装したい機能の壁打ちをします。その上で、既存の API はどうなっているのかといった部分は、Cursor で調べ自分でも確認して実装をしてもらいました。これは AI がなければ不可能だったスピード感です。

──キャッチアップ以外、たとえば日々の業務にも変化はありますか。

刀禰： はい。実装面に限らず、仕様の維持などの面でも変化があります。kencom は 2C のサービスに見えて、実は 2B2C というサービスで、自治体や健康組合と契約しているので問い合わせが頻繁に来ます。その度にエンジニアが調査をしていると業務が滞ってしまう課題がありました。そこを Devin によって仕様書を正しく保つことで解決する取り組みを進めています。

具体的には、Devinにコードの変更内容を読ませて、仕様書を自動でアップデートさせる取り組みをしています。常に仕様書を正しく保ち、「ビジネスサイドの人がエンジニアに聞かなくても、最新の仕様書を見れば解決する」という状態を目指しています。エンジニアは Devin が書いたドキュメントをチェックして Approve するだけとなり、エンジニアが本来集中すべき開発に時間を割けるようになりつつあります。

平子： Devin を利用する大きなメリットとして、AI 活用の方法がチームの集合知になるというものがあります。個人がAIを活用するだけだと局所最適化が起こり、チームの中での仕組みになりません。他には Slack や ウェブの UI で AI を使用でき、馴染みがあるユーザーインターフェイスが提供されていることも大きいです。AI 活用を広めていく上で、エンジニアだけではなく開発に関わる人全員が AI を使える環境を整備することが重要だと思っています。Devin の利用人数は100人ほどで、おそらく全社の中で1番だと思います（編集者注: 2025年12月時点）。

失敗を乗り越えた「10%の投資」と、AI時代のエンジニアの責任

──最初からこれほどスムーズに活用できていたのでしょうか。

刀禰： 全社的なAI活用推進の前から、ヘルスケア部門ではコーディングエージェントの導入を始めていました。導入自体は、2024年、8月ごろだったと思います。しかし、初期ではナレッジも限られ利用できるモデルに制約もあるという状況で、エージェントがソースコードを破壊してしまうことも多かったです。というのも、kencom ではリアーキテクチャが進行中で、複数のリポジトリを跨いだり、相互の関係性を定義しないといけない等の制約条件があり、当時のモデルの能力だとコンテキストウィンドウに限界がありました。コーディングエージェントは全然使えない、という印象を持っていた時期もありました。そこから「エージェントという仕組みがダメ」なんじゃなくて「モデルの性能がボトルネック」なんだという仮説を立て、コツコツと実験しながら試行錯誤してきました。モデルの進化により、ようやくまともに使えるようになりました。

──組織としてAI活用を定着させるために、新たに始めたこともあると伺いました。

平子： 2025年4月に「ワーキンググループ（WG）」を立ち上げました。隔週金曜日、つまり全工数の10%に相当する1日を完全にブロックして、業務改善だけに充てるというルールです。

──工数の10%を割くというのは、かなり思い切った決断ですね。

平子： 個人の試行錯誤だけで終わらせては局所最適化に留まります。日々のタスクに追われていると、業務改善はスイッチングコストがかかったり、推進者の調整コストがかかったりするため後回しにされてしまいます。そのような面倒を取っ払うために、組織として「この時間は改善に使う」と明確にしました。この WG にはエンジニアだけでなく PdM も巻き込んで、負債解消、開発フローと生産性の革新、デザインシステムの応用などを進めています。

刀禰： 普段別のチームで分かれて業務をするメンバーが、WG では横断的に集まります。チームごとにAI活用の仕方が違うので、一緒に開発してみると違いが見えておもしろいです。1日しっかり時間を取って成果を出そうっていうところで集中してやれています。

──最後に、AI がこれほど浸透した先で「人間の役割」はどう変わるとお考えですか。

平子： エンジニアとしてどう思考し、どう振る舞うか、たとえば仕様書駆動、テスト駆動開発（TDD）を取り入れるなど、エンジニアが成熟したプロセスやメンタルモデルを取り入れることの重要性がより上がっていると思います。AI は使用者の思考や行動をトレースします。つまり、自分たちが優れたエンジニアにならないと AI は良い仕事をしてくれないわけです。部門内で基礎研修などを行い、ソフトウェア工学や業界先端の開発手法、そのもととなる考え方をチームの共通知にしていくことが重要です。逆に懸念として、思考を止めて AI の生成したものを鵜呑みにし始めると成長阻害になり得ます。AI がなぜその出力に至ったのか背景の考え方、メタ的な問いかけを AI にしていきながら紐解く。AI 自体を自分のコントロール下に置くことが重要だと思ってます。そうじゃないと、ただ AI の利用料金だけが浪費されますよという状況になりかねません。

刀禰： 責任を負うのは人間のエンジニアです。「AI がやったので自分は悪くない」とは言えず、AI に任せていい場所とダメな場所の区別が重要です。細かい修正は AI に任せて人間がチェックして「良さそう」で良いですが、テーブル設計など大規模な機能改修とか新しい機能を作る時の土台となる設計の部分は人間が重点的に見るべきだと思います。これを AI に丸投げすると、たとえば後でテーブルのスキーマが全然ダメだったってなると手戻りが大きくなってしまいます。

平子： 今後は、今までやってきたことがより小人数で回せるようになってくると思います。一人一人が企画者であり、実装者であり、サービスの責任者である状況が現実味を帯びている。そうなった時にプロダクトをどう分割すべきか、働く人を減らしていく方がいいのか、といった痛みを伴う戦略も含めてリスクヘッジしていく必要があります。個人のチャレンジを推奨できる組織文化や財政状況を作っていきたいです。

まとめ

本日は、DeNAヘルスケア部門における AI 活用の最前線を、平子さんと刀禰さんにお話を伺いました。AI の進化が加速する時代のエンジニアの役割は、AI に仕事をさせることではなく、AI の出力を吟味して最終的な責任を負うことへとシフトしています。また、個人の AI 活用に留まらないよう、チームとしての AI の活用方法をどう集合知に変えていくかという視点が、組織での AI 活用を推進し根付かせる鍵となりそうです。

編集: 佐竹航希