こんにちは、primeNumberです。
11月21日にベルサール羽田空港開催された、システム基盤となるアーキテクチャをテーマにした「アーキテクチャConference 2025」。primeNumberはブース出展に加えて取締役執行役員CTOの鈴木健太さんとHead of CTO Officeの中根直孝さん、イノベーション本部の廣瀬智史さんが登壇しました。
この記事では鈴木さんと中根さんの2人によるセッション「AI Native開発への挑戦 〜既存プロセスをどうAI化し、成果につなげたか〜」の内容をお伝えします。
セッションの前半は、CTOの鈴木さんが既存のプロダクト開発におけるAI Native化を、後半は中根さんが今年から携わっている新規プロダクト開発でのAI Native化についてそれぞれprimeNumberの取り組みを語りました。
AI Navive化が進まない「4つの理由」とその対策
鈴木さんはまずprimeNumberのAI Native化の現在地について説明。2025年5月から進めたAI Native化プロジェクトは、2025年10月末時点でAIで各コードが90％を締め、開発スピードも体感地で1.5倍まで向上、エンジニアのAI Naviveレベルも向上しています。
こうした自社でのAI Nativeへの取り組みを経て、既存プロダクト開発でAI Native化が進まない理由として鈴木さんは「暗黙知が存在する（ナレッジ）」「AIが理解しづらいコードベースになっている（アーキテクチャ）」「AIが扱える粒度に開発プロセスが分解されていない（プロセス設計）」「AI Native を進める「体制」が整っていない（組織）」の4つを指摘。この課題に対してどこが難しく、primeNumberはどのように対処してきたかについて語りました。
暗黙知については「長年開発を続けてきたときには暗黙知がはびこるが、その暗黙知によってAIが意図するコードを生成してくれない」と指摘。その対策としては、ひたすらAIにコードを書かせて修正を繰り返すことで「愚直にナレッジを増やす」ことが重要だと説明。「地味だがこのフェーズを頑張った結果、今ではナレッジ追加の頻度はかなり減った」との成果を示しました。
一方で「ナレッジを人が書くのも時間がかかる」ため、「AIに書かせたコードは何がダメなのかをAIに感がさせる」というTIPSも披露。長寿命プロダクトのコードのフィードバックをひたすらAIに繰り返させる、過去にドキュメントが蓄積したインシデントのログからAIにガイドラインを書かせるといった事例を示し、「過去のドキュメント文化がAI Native化を加速させる」と語りました。
AIでインシデントを防ぐ話についてはこちらのブログもご覧ください。
理由の2つ目である「AIが理解しづらいコードベース」については、「ナレッジを増やし続けても必ずしもAIが読んでくれるわけではない。AIに合わせてコードベースを変えていく必要がある」と説明。「抜本的にコードベースを変えるのは難しいが、できるところから進めていくのが良い」との考えを示しました。
3つ目の理由であるプロセス設計においては、「AIにコードを書かせると、これまでには存在しなかった『AIのコードを自分で読む』という時間が長くなる」との課題を指摘。そのためAIの実装プロセスを分解し、人間が理解しやすいようにして認知負荷を下げるのが重要としました。
最後の理由である組織については「AIツールを配布しただけで終わっていないか」との課題を投げかけた上で、primeNumberでは「技術トップがAIで開発「AI Nativeのゴールを設定」「チームごとにAI Native推進役（AI Champion）を置く」「自分で一切コードを書かずAIに書かせるショック療法として『AI Native Day』を実施」といった取り組みを紹介。
AIが理解しやすいようコードベースを整え、ナレッジを整備しながら組織で進めることが重要であり、ソフトウェア開発のAI Native化の知見ははあらゆるAIプロダクトに適用できると締めくくりました。
AI時代の新規プロダクト開発におけるアーキテクチャ決定のポイントを解説
鈴木さんの発表を受けて、中根さんは今夏から取り組んでいるWebサービスの新規開発とAI活用の経緯を説明しました。
中根さんは「今、技術選定やアーキテクチャ決定をゼロから行うならどうするか」との課題を立てた上で、前半で鈴木さんが掲げた「AI Native化が進まない4つの理由」について、「少人数の体制なのでプロセス設計や組織はあまり問題にならない」と説明。
一方、ナレッジについては「暗黙知も新規プロジェクトでは関係ないと思われるかもしれないが、AIでコードを書いていると新しい書き方と古い書き方が数週で生まれる」と指摘、その対策として常に暗黙知が生まれない仕組みを考える必要があるとしました。
また、アーキテクチャに関しては「AIが書くコードはある意味信頼がおけない」との課題を示し、「AIコーディングで信頼性と開発速度を両立するためには、AIが間違いに自律的に気付けるアーキテクチャが重要になる」との考えを示しました。
具体的なアーキテクチャ選定について、TROCCOではRuby on Railsを始めとしてさまざまな技術を利用していますが、Webサービスである以上JavaScriptは必須であるといった理由からNext.jsをあまり迷うことなく採用。
バックエンドについてもRailsやGo、Next.jsといった選択肢がある中で、バックエンドとフロンドエンドがシームレスであり、TypeScriptやReact自体は普段から書いているので慣れているといったメリットからNext.jsを採用。Next.jsの知見自体は社内に少ないものの、「そこはAIに壁打ちしながら頑張る」との考えを示しました。
データベースは経験のあるMySQLという選択肢もあった一方で、「マルチテナントサービスにおけるセキュリティ担保の課題からPostgreSQLのRLS（Row-Level Security）に興味があった」と説明。
こうした初めての技術スタックを使いこなすためには「腹落ちするまで徹底的にAIと対話するのが重要」と中根さんは指摘。一方で「最初のアーキテクチャの意思決定は人間が行ったほうがいい。大量にコードを書くわけではないので、AIに任せるデメリットよりも自分でやるメリットのほうが大きい」と付け加えました。
新規開発におけるAI Native化のもう1つの課題である暗黙知については「AIにコードを書かせる場合は規約やルールを厳しめに設けたほうがいい」とのTIPSを紹介。コーディング規約や命名などは「人間にとってうっとうしいくらい厳しめにしておいたほうが今の時代では有用では」との考えを示しました。
ルールの設け方については「まず自分の経験に従ったうえでAIと壁打ちするといい」と説明。「AIを重視しすぎて人類が築いてきたプラクティスをないがしろにしては元も子もない」と、AIと人間を「両睨み」することの重要性を説きました。
こうした設計をしっかりやっていくと、簡単なfeatureの追加は「秒で終わるようになる」と中根さんはそのメリットを指摘。負債が表面化するまでの時間が短くなっており、「2週間に1回程度でリファクタリングだけをする日を設けている」との対策を紹介しました。
最後に中根さんは「この資料を作成している間にも新たなAIエージェントの機能が登場しており、瞬間的に最善なAIの活用を追求し続けるのは難しい」との状況を示した上で、「どんなAIの変化に対しても価値となる部分を整備することが重要 」と説明。「今回の発表で繰り返している通り壁打ち役としてのAIの価値は大きく、新しい取り組みをする際にはAIを生かして積極的に挑戦するといい」とのAIの活用を勧めました。
今回の登壇資料は下記からご覧いただけます。
primeNumberでは既存プロジェクトも新規プロジェクトも、どちらもAI Nativeを軸に開発を進めています。AI Naviveを含めたprimeNumberの開発体制に興味を持った方はぜひご連絡ください。
