AI Native 開発への挑戦

by gtnao

Slide 1

Slide 1 text

AI Native 開発への挑戦 primeNumber inc. - Kenta Suzuki (CTO) - Naotaka Nakane (Head of CTO Office)

Slide 2

Slide 2 text

鈴木健太 Kenta Suzuki CTO, primeNumber inc. 最近の活動： CARTA CTO の鈴木健太さんと鈴木健太CTO対談「鈴木健太 AI ラジオ」で検索

Slide 3

Slide 3 text

1. 既存プロダクト開発 2. 新規プロダクト開発既存・新規プロダクト開発それぞれの AI Native 化について、ご紹介します。 NEW 7 years old

Slide 4

Slide 4 text

1. 既存プロダクト開発 2. 新規プロダクト開発既存・新規プロダクト開発それぞれの AI Native 化について、ご紹介します。 NEW 7 years old

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© primeNumber.Inc primeNumber のソフトウェア開発 AI Native 化の現在地 SWEチーム概況 ● SWE 16名 ● 4チーム Before (2025/5) After (2025/10) 1.28 3.58 LEVEL0 LEVEL1 LEVEL2 LEVEL3 LEVEL4 BEFORE: med: 1, avg:1.28, max: 3 AFTER: med: 3.65 avg:3.58, max: 4 ソフトウェアエンジニアの AI Native レベル(※自社策定) の変化 2025/5から AI Native 化プロジェクトを開始。2025/10末時点の状況 AI が書くコードの割合 90% 開発スピードの変化 ※体感値 x 1.5 AI主導で人間はレビューコード補完などでAI活用

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© primeNumber.Inc 7年間開発を続けてきたプロダクトには、暗黙知がはびこる ● 「このコードは今風だから参考にしていい」「こっちは古いから真似しないほうがいい」 ● サービス層・ディレクトリ構成の“なんとなくの決まり” ● 「Controller のテストは request spec で書こう」 ● React component / UI コンポーネントの“お作法” 理由1: 暗黙知が存在する（ナレッジ）暗黙知をAIが理解できず、正しいコードを生成できない  

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© primeNumber.Inc TIPS: ナレッジは AI に書かせるやったこと - Claude Code にコードを書かせてみてダメだったら - 「こう実装しほしかったけど、何がCLAUDE.mdに書いてあれば良かった？」を AI に考えさせる - CLAUDE.mdを改善させる - 人間向けのドキュメントがある場合 - 既存の wiki（例：DBテーブル追加ルール）を AI に読ませる - 既存コードも読ませて、「OpenAPI 実装ルール」などを CLAUDE.md に書かせる AIが読むドキュメントは、AIに書いてもらう  

Slide 14

Slide 14 text

© primeNumber.Inc TIPS: 過去のインシデントログはナレッジの宝庫インシデントログからナレッジを作る手順 1. 過去PR＋事象を AI に読ませて、「この事故を防ぐための実装ガイドラインは？」と聞く 2. AIにガイドライン案を書かせる 3. 個別事案に寄りすぎていれば抽象化させる 4. ガイドラインで、PRをレビューさせる（コンテキストクリア忘れずに） 5. うまくいくまで、繰り返し [参考] AIレビューでインシデントを未然に防ぐ仕組みづくり過去のドキュメント文化が、AI Native化を加速させる  

Slide 15

Slide 15 text

© primeNumber.Inc 発展: ライブラリアップデートのリスク判断をAIにやらせるライブラリアップデートのインシデントから得たナレッジを元に、AIでコードレビューを実施 - GitHub Actions 上で Claude Code を動かす - dependabot の PR を自動でリスク評価最終判断は人間だが、調査プロセスを AI がサポート   dependabot が作成するPRを自動レビュー

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© primeNumber.Inc 具体的にやったこと(例): ● ReactのComponent名・prop名をAIが誤解しない名前にリネーム AI に合わせてコードベースを変えると言っても、現実的にはコードベースを抜本的に変えられないので、できるところからやる AIが間違えにくい設計が重要 = 余計なコンテキストを渡さなくて良い ※Rubyにおいても、全てのコードにAIを活用して型をつけるプロジェクトが進行中（まもなく完遂）型がある領域（TypeScript）は変更しやすいので、AIに合わせやすい  

Slide 18

Slide 18 text

© primeNumber.Inc いきなり「全部AIにやらせる」は破綻するので、時間x頻度でプロセスを棚卸しした ● PR の概要欄を埋めるのに時間がかかる ● migration 作成とレビューがパターン化している ● dependabot のライブラリアップデートレビューが重い理由3: AIが扱える粒度にプロセスが分解されていないどこからAI化するか？ → まずは「棚卸し」から → この辺りをターゲットに AI 化を進めた影響度 x 頻度でマッピング

Slide 19

Slide 19 text

© primeNumber.Inc 単純な実装プロセスは短くなるが、PRを出す品質まで持っていくためにはコードを読み取って（まずは疑って）理解する必要があり、むしろ時間がかかるようになってしまう AIの実装プロセスを分解して、人間の認知負荷を下げる設計含めてAIが実装することで、人間だけ実装しているときには存在しなかった、AI が書いたコードを理解するコストが発生設計 + 実装時間設計・実装人間だけ人間+AI 実装理解 + 修正設計実装理解修正人間+AI こうしたいいきなりAI が実装

Slide 20

Slide 20 text

© primeNumber.Inc AIの実装プロセスを分解して、人間の認知負荷を下げる人間の開発プロセス 1. 問題を理解してざっくり設計 2. コードの当たりどころを決める 3. タスクを分解する 4. 実装する 5. 自分で見直す 6. 全体を通してレビューする（最終確認） AI+人間の開発プロセス 1. まず markdown で作業書を作成させる - 作業方針 - 設計案 - タスク分解 2. 人間が作業書をレビューし、必要なら直接修正 3. その上で、タスクごとにコードを書かせる 4. タスクごとに実装をレビューする 5. 全体をレビューするコードという平面情報よりも、構造化された自然言語の作業書の方がレビューコストが低いそこで実装されたものは、概ね自分の意図したコードになるのでレビューコストが下がる  

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

© primeNumber.Inc 3. チームごとに AI Champion を置く ● チームごとに触っている領域は違う ● 各チームに AI Native 推進役（AI Champion）を配置 ● 彼らと一緒に全体を底上げ ○ SlackのAI専用チャンネルや、全体定例で事例共有 primeNumberで重要だった4つのポイント 4. ショック療法：AI Native Day ● 「自分では一切コードを書かず、AI だけに書かせる日」 ● ハッカソン的ではなく、通常の業務をAI だけでやるという制約が重要

Slide 24

Slide 24 text

© primeNumber.Inc (まとめ) 既存プロダクト開発のAI Native化が進まない4つの理由 AIが理解しやすいようにコードベースを整え、ナレッジを整備 AIに手伝ってもらいながら、組織で進める理由こうする 1. 暗黙知が存在する（ナレッジ） ① 泥臭くナレッジ増やす ② AIにナレッジを書かせる 2. AIが理解しづらいコードベースになっている（アーキテクチャ） ① AIに合わせてコードベースを変更する (できるとことから) 3. AIが扱える粒度に開発プロセスが分解されていない（プロセス設計） ① 開発プロセスを棚卸しする ② 人間の実装プロセスにAIをあわせる 4. AI Native を進める「体制」が整っていない（組織） ① 技術のトップがちゃんとAI開発やる ② ゴールを設定 ③ AI Champion ④ ショック療法 

Slide 25

Slide 25 text

© primeNumber.Inc AIが理解しやすいコードベースを整え、ナレッジ整備の適用ソフトウェア開発のAI Native 化の知見は、あらゆるAIプロダクトに適用できる ● AI が理解しやすいデータ構造を整える ● データに関するナレッジを貯める ● その整備プロセスを AI で回す「データ × AI 」の領域でも、同じ構造です。 Data Warehouse Lake Mart データの説明ナレッジを整備データを整える (アーキテクチャ)   AI  

Slide 26

Slide 26 text

1. 既存プロダクト開発 2. 新規プロダクト開発既存・新規プロダクト開発それぞれの AI Native 化について、ご紹介します。 NEW

Slide 27

Slide 27 text

27 naotaka nakane (@gtnao) primeNumber inc. Head of CTO Office ● 2018/11 primeNumberにジョイン ● TROCCOの開発に7年間従事 ● アーキテクチャカンファレンス2024登壇 ○ 「PaaSとSaaSの境目で信頼性と開発速度を両立する〜TROCCO®のこれまでとこれから〜」 ● 2025/08より新規Webサービスの開発中

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 2025年夏ゼロイチでのWebサービス開発に取り組むことになった

Slide 30

Slide 30 text

30 Agentic Codingの波に世界が包まれる中今「技術選定/アーキテクチャ決定」をゼロから行うならどうするか

Slide 31

Slide 31 text

31 AI Native化が進まない4つの理由ナレッジアーキテクチャプロセス設計組織 AIに渡すべき知識とルールが形式知化されていない AIが理解しづらいコードベースになっている AIが扱える粒度に開発プロセスが分解されていない AI Nativeを進める体制が整っていない ✅既存プロダクト開発と同様に、都度切り出していけば良い ✅少人数の体制なのであまり問題にならない？？〜前半の発表から引用〜

Slide 32

Slide 32 text

32 AI Native化が進まない理由（ナレッジ/アーキテクチャ）ナレッジ（暗黙知の防止）アーキテクチャ非決定的なAIによるコーディングにおいて、信頼性と開発速度を両立するためには？新規プロダクトには暗黙知はない？ Agentic Codingにより、時が加速し新しい/古い書き方が数日/数週間で生まれてくる世界線常に目を光らせ、暗黙知が生まれない仕組みを考える必要がある AIが間違いに自律的に気付けるアーキテクチャ決定的なレイヤーで信頼性を担保するアーキテクチャを考える必要がある

Slide 33

Slide 33 text

33 「アーキテクチャ」について考える

Slide 34

Slide 34 text

34 TROCCOの技術スタックおさらい

Slide 35

Slide 35 text

35 TROCCOの技術スタックおさらい（バックエンド） ● 2018年当時在籍のエンジニアの得意な技術スタック ● ゼロイチで新規サービスを速度重視で開発するなら、 Railsは当時第一候補の一つだったと思う ● バックエンド実装で静的型付けが無いのはやはり辛い ○ 開発に携わる人数増 ○ Agentic Codingの台頭で顕著に

Slide 36

Slide 36 text

36 TROCCOの技術スタックおさらい（バック-フロント） ● RailsとReact間の繋ぎ込みにOpenAPIを導入 ● YAMLからTSの型を自動生成 ● YAMLを利用したRailsのテストも一部導入 ● 型安全性の課題 ○ TSの認識する型とRailsの実装の細かいズレ ○ 対応できてないAPI ● 一つの画面を作るにもボイラープレートが多い ● AIに任せるためには上記２点は課題

Slide 37

Slide 37 text

37 言語/フレームワーク選定（フロントエンド） ● Webサービスである以上、JavaScriptは必須 ● 2025年現在、Reactベースであれば、Next.jsが第一候補として上がるのは一般的に間違いない ○ 他のフレームワーク（Remixなど）を試し切る時間はなかった ○ 明確な理由がない限り、AIの学習量が多いと思われるデファクトの技術を選んでおくことのメリットが大きいあまり迷うことなく決定

Slide 38

Slide 38 text

38 問題はバックエンド

Slide 39

Slide 39 text

39 言語/フレームワーク選定（バックエンド） 3つの候補が上がる引き続きRailsでAPIサーバを書く GoなどRuby以外の静的型付け言語でAPIサーバーを書く Next.jsのServerAction/APIで TypeScriptでバックエンドの処理を書く他

Slide 40

Slide 40 text

40 言語/フレームワーク選定（バックエンド） Pros 自分を含めて慣れている新たに学ぶことの必要がない Cons 型安全性の課題が解決できない他 Pros 静的型付け Cons 社内に知見が少ないフロントエンド連携は APIスキーマを別途定義しながら進める必要 Pros バックエンド/フロントエンドのシームレスな型の恩恵 TypeScriptやReact自体は普段から皆書いている (フロント/バックエンドがチームとして分かれていない) Cons Next.js自体の知見は社内に少ない → AIに壁打ちしながら頑張る

Slide 41

Slide 41 text

41 言語/フレームワーク選定（バックエンド） Pros 自分を含めて慣れている新たに学ぶことの必要がない Cons 型安全性の課題が解決できない他 Pros 静的型付け Cons 社内に知見が少ないフロントエンド連携は APIスキーマを別途定義しながら進める必要 Pros バックエンド/フロントエンドのシームレスな型の恩恵 TypeScriptやReact自体は普段から皆書いている (フロント/バックエンドがチームとして分かれていない) Cons Next.js自体の知見は社内に少ない → AIに壁打ちしながら頑張る採用 ac3

Slide 42

Slide 42 text

42 データベースは？

Slide 43

Slide 43 text

43 データベース選定 ● 会社として慣れているMySQLをそのまま選択しても良かったが… ● マルチテナントサービスにおけるセキュリティ担保への課題から、 PostgreSQLのRLS（Row-Level Security）への興味 Agentic Codingの流れが加速する中で AIが書くソースコードレベルより低い決定的なレイヤーでクリティカルな事故を防げることの魅力

Slide 44

Slide 44 text

44 RLSの利用時の工夫 ● いくつか検討したが、最も型の恩恵が自然に得られそうなPrismaを選択 ● ORMとしてPrismaを採用したが、prisma-client generatorを自作して、tenant_idを持ったテーブルに関して、自動でRLSのDDLがmigrationファイルに追記されるように ○ （prisma-client generatorは現時点では安定版ではないので注意） ○ generatorの実装もAIの力を借りて一瞬で（100行ほどで実装できる） ● ダブルチェックとして、CIで全てのテーブルに制約がかかっているかをチェック ● 管理系の画面などではRLSのBypassも必要 ○ 利用を最小限にとどめ、Linterでimportを制限するなど（検討中）

Slide 45

Slide 45 text

45 初めての技術スタックのハードル ● Next.jsもPostgreSQL(RLS)もPrismaも、プロダクションレベルで初めて触る技術スタックだった ● 新しく触る技術の仕様、プラクティスを、腹落ちするまで徹底的にAIと対話する ● AIに壁打ちができることで、初めて触る技術を選択するハードルが低くなっている ● 最初からAIに任せないことが重要 ○ AIと対話するが、アーキテクチャの意思決定は人間が行う ○ 一例）Claude Codeを使わずWebのClaudeを使って聞くといいかも ■ すぐにコードを書かず、対話だけに徹することを強制的に制限 ○ 自分で手を動かして、初期構築のコマンドや、ディレクトリ/ファイルの作成をする ■ 最新のドキュメントを人間が目で見て進める ■ さほど大変でもないので、AIに任せないことのデメリットが少なくメリットが多い

Slide 46

Slide 46 text

46 暗黙知の防止について考える

Slide 47

Slide 47 text

47 規約で縛る ● できる限りコーディング規約を厳しめに設ける ● AIは、明示的に指示をしないと、既存のコードとの整合性に重みをおいて実装することが苦手 ● 放っておくとバラバラの実装になり、数週間ほどで手がつけられなくなる 1 2 3 コーディング規約を考え、日々ブラッシュアップする命名や引数のルールやディレクトリ設計など人間にとっては少々鬱陶しいくらいに決める Docsにとりあえず起こす AIが守ってくれないという課題はあるが、将来的なAIの発展も考え存在すること自体が重要できるところからLintを縛るディレクトリの責務を決めてimport（依存関係）の制限を行う eslint-plugin-unicornとeslint-plugin-perfectionistなどの厳しめのプラグインを設定している

Slide 48

Slide 48 text

48 ルール（例） ※ あくまで、あるタイミングで採用していた例にすぎず、推奨するものではありません。各層間での依存ルールを定義。Prisma（DBへのアクセス）をできる層を限定。

Slide 49

Slide 49 text

49 ルール（例） ※ あくまで、あるタイミングで採用していた例にすぎず、推奨するものではありません。各層ごとに、命名/引数のルールを統一する。

Slide 50

Slide 50 text

50 ルール（例） ※ あくまで、あるタイミングで採用していた例にすぎず、推奨するものではありません。しっくりこなかったら AIと壁打ちして考え直して AIに一気に修正させる

Slide 51

Slide 51 text

51 どういったルールを設けるべきか ● 自分の経験にまず従う ● その上でAIと「壁打ち」をする ● AIにとっての「リーダブルコード」が語られがち ○ 人間が読みやすいコードとAIが読みやすいコードは別なのでは？という問い ● 興味深くはあるが、裏打ちされた根拠は少なく、枯れてない ● AIを重視しすぎて、人類が築いてきたプラクティスを蔑ろにしては元も子もない ○ 両睨みが大事 ref: twada「AI時代のソフトウェア開発を考える」

Slide 52

Slide 52 text

52 負債が表面化するまでの時間 ● 前述のベースの部分の設計をしっかりやると、各featureの追加が秒で終わるようになる ○ ※ 既存開発に比べて制約が少ないため ● ある程度レビューもしていれば（Vibe Codingでなければ）、すぐさま崩壊はしない ○ しかしながら、無意識に通常よりレビュー時に目が滑っている ● 2週間くらいするとちょっと辛くなってくる ○ 「適当な実装により生産性が逆転するのは1ヶ月→3、4日に」 ■ 実感するところが大きい ○ ref: fukabori.fm「AIコーディングの現在地 w/ twada」 ● とりあえず、2週間に一回リファクタリングだけをする日を設けている

Slide 53

Slide 53 text

53 まとめ ● この資料を作成している間（10月某日）にも、各社のAIエージェントの機能が登場してきた ○ 例）Claude Skills ○ 正直、普段の仕事をしつつその瞬間に最善なAIの活用を追求し続けるのは難しい ● どのようなAIの変化に対しても価値となる部分を整備 ○ アーキテクチャ/ナレッジ（ルール） ○ 余裕が生まれたときに定期的にDeepDiveしてみる ● フィードバックループの高速化を感じる日々 ○ 今回話したことに取り組み始めたのは8月半ば、執筆時点が10月後半なので、2ヶ月半でこのような学びが得られる ● 壁打ち相手としてのAIの価値を評価して、新たな取り組みの際には積極的な挑戦をしよう ○ ただし、重要な意思決定は、（AIとの対話を元に）自らの手で行う

Slide 54

Slide 54 text

54 We are hiring! primeNumberではプロダクトづくりに携わるさまざまな職種を絶賛募集しております！ https://herp.careers/v1/primenumber

Slide 55

Slide 55 text

55 Thank you! ブース出展しております Xのフォロー画面をブースで展示していただいた方にオリジナルプリングルズ配布中！ https://x.com/primeNumberinc