AI時代における開発生産性と進化可能性を高める技術戦略 / AI DevEX Conference 2026

2026-07-23 「AI DevEX Conference 2026」の登壇資料です。

Transcript

1. 時代における開発生産性と 進化可能性を高める技術戦略 AI Shodai Suzuki @SoartecL AI DevEX Conference 2026 2026.07.23 © MOSH Inc.
2. 鈴⽊翔⼤ X @SoartecL 株式会社 技術戦略 エンジニア組織 趣味 OSS Orvalメンテナ MOSH VP of Technology
3. のビジネス MOSH
4. ヨガ・フィットネス 養成講座・スクール クリエイター ヘルス・ウェルネス 育児・子育て オンラインサロン・ コミュニティ メイク・ ビューティー
5. オールインワンプロダクト
6. 今日話すのはAIツールの使い方ではない AI時代に競争力を生み続ける技術戦略 この数年間の試行錯誤から得た学びを共有 今日話すこと
7. 生産性向上によって生まれた余剰を 何に再投資しますか？
8. アジェンダ 1 生産性から価値への転換 2 進化可能性を実現する 技術戦略 3 AI 時代の開発競争力
9. 生産性の定義 生産性の標準的な定義は、労働者一人当 たりの平均生産量“ “ 引用: 「技術⾰新と不平等の1000年史 上 」 P.44
10. による生産性の変化 AI 高品質なプロトタイピング 開発フェーズの時間短縮 開発コストの低下 ソフトウェア開発のプロセスの変化 開発組織の考え方や人数
11. プロダクトマネジメント の課題もより顕著に
12. ビルドトラップ 実際に生み出された価値ではなく、機 能の開発とリリースに集中してしまって いる状況” プロジェクトはSQCDと作業のかた まり プロダクトは成長に向けてアウトカ ムを実現し成功に至るまでプロジェ クトを繰り返す “ 引用: 「プロダクトマネジメント」 P.1
13. 価値とは？ 顧客が価値を認めるのは、自分たちの問 題が解決したり、要望やニーズが満たさ れたりしたときだけです。” 価値は交換システムの循環 顧客が価値を認めた時だけビジネス 側に価値を返してくれる お金、データ、知識資本 本質的にプロダクトやサービス自体 に価値はない 価値があるのは顧客やユーザの問題 を解決したりニーズを叶えたりする こと “ 引用: 「プロダクトマネジメント」 P.10
14. 認知負荷と逆品質 プロダクトの変化量増加 メンタルモデルの再構築 ユーザーの認知負荷増加 ユーザーのワーキングメモリは変わ らない このギャップがユーザー体験の悪化 に繋がる 狩野モデルの逆品質化 アウトプットとアウトカムの反比例 引用: 「狩野モデルとは？5つの「品質」や、導入するメリット・注意点を解説」https://service.shiftinc.jp/column/10933/
15. で 量が増えるがMeasureが追いつかない 検証されない機能が増える ユーザー体験の逆品質化 機能は充足しているが価値は増えない・体験が悪化 AI Build だけの最適化では不十分 Build
16. システム思考 システムの一部を最適化するとシステム 全体は必ず劣化する” 複数の変数が連鎖するフードバック ループシステムとして捉える 部分最適ではなく全体最適が重要 “ 引用: 「リーンスタートアップ」P182
17. 大量⽣産が問題なのではない 複数の変数を同時に捉えていないことが問題 検証がされずビルドが連続している状況が問題 ビルドトラップの本質は「検証されないこと」 作る量と価値は別の話 作っただけでは価値にならない
18. 複数の変数を同時に コントロールするための検証
19. ループ BML 「リーンスタートアップ」で解説さ れているBuild・Measure・Learnの サイクル 製品を最適化するフィードバック ループ たくさんの物を効率的に作ることで はなく、持続可能な事業の構築方法 を短時間で学ぶ AIはBuildを代替し高速化するが Measureは代替しない
20. 計測による学び 不確実性と言う土壌において進捗を的確 に図る方法である。” Build → Measure → LearnのMeasure が無ければ的確な進捗はない 構築と計測はセット 価値維持は継続的な実験でしか成立し ない “ 引用: 「リーンスタートアップ」P.56
21. 生産性向上だけではなく 計測とデータによる学びを含めた 開発ループを高速に回す
22. ソフトウェア要求 ソフトウェア製品の長期的なライフサイ クルの中で必要となるのは、新しいアイ デアの高速の探求、状況の変化やユーザ の問題への高速な応答、スケールした状 態で開発者が速度を出すことの実現であ る。“ ソフトウェアは複合的な要因が絡ん だ環境下での速度が要求される 組織の長期的成功はアイデアをユー ザに迅速に届けることと、ユーザの フィードバックに迅速に反応できる 組織能力 “ 引用: 「Googleのソフトウェアエンジニアリング」 P.585
23. 価値を生み続けるために 速度を出し続けるには？
24. アジェンダ 1 生産性から価値への転換 2 進化可能性を実現する 技術戦略 3 AI 時代の開発競争力
25. 進化可能性という解 進化可能性を加えると言う事は、システ ムが進化していく中で、他の特性を保護 すると言うことを意味している” 時間や要求の変化に適応しながら、 重要なアーキテクチャ特性を腐敗さ せずに保護する 状況に適応した偶発的な複雑さに適 応していくのではなく、最終状態に 対し漸進的・誘導的に進化する 短期の視点と長期の視点 あらゆる状況に予測可能ではなく進 化可能を取り入れる “ 引用: 「進化的アーキテクチャ」 P.7
26. 進化可能性をどう作るか？
27. リアーキテクチャは3年前からスタート 当時はcopilotのサジェストが出る程度 まだコードは人が書いていた 当初から分散・独立性を重視 人を中心とした並列開発設計 一方で技術選定にも加味し始めていた AIが学習するデータ量、推論要素の量など 進化可能性の歴史的背景
28. 特に重要な要素7選
29. ①マイクロサービス化
30. 機能 顧客管理機能 売上管理機能 アプリケーション共通基盤 決済基盤 契約プラン 管理基盤 メッセージ 配信基盤 通知基盤 ②アプリケーション共通基盤
31. 通知基盤
32. 機能 フロントエンド バックエンド 共通基盤 共通基盤 ③フルスタックTSとモノレポ
33. マイクロサービス管理のディレクトリ構成 マイクロサービスとの 親和性 で管理 コード管理ポリシーの再利⽤ OpenAPIを一元管理し自動生成のタ イミングを担保 IFの不整合を排除 AIエージェントでの網羅的なコンテ クスト収集が可能 1リポジトリの中で並行開発が可能 Bun workspace
34. ④機能単位でのソースコード分離 引用: 「https://feature-sliced.design/docs/get-started/overview」
35. フロントエンドのディレクトリ構成 高凝集、疎結合 Feature-Sliced Design ※1 バックエンドのディレクトリ構成 引用: 「https://feature-sliced.design/docs/get-started/overview」 ※2 引用: 「https://kentcdodds.com/blog/colocation」 ※1 機能単位でロジックを凝集化、機 能間は疎結合に co-location ※2 コード知識を集約することでの認 知負荷低減とメンテナンス性向上 スコープと影響範囲が明確 AIエージェントがコンテキストを 網羅的に把握 並行開発がしやすい
36. 推論範囲を限定する 扱うコンテキストを小さくする 決定論を増やす 変更の影響範囲を局所化する 高凝集・疎結合によって並列開発を可能にする 部分的に進化できる構造を作る 共通する設計思想
37. ⑤開発ごとに独立したプレビュー環境
38. storybook のプレビュープレビュー環境の起動 プレビュー環境 の単位で起動 マージ・クローズで自動停⽌ 一定時間経過で⾃動停⽌ 単一のステージング環境共有では並 行開発・検証が間に合わない 開発しながら社内公開しフィード バックサイクルを高速化 常時150程のプレビュー環境が起動 PullRequest アプリケーションのプレビュー環境の起動 実際に起動しているタスク数
39. OpenAPI API 通知基盤 サーバー Orval Orval fetch API zod msw zod ⑥スキーマ駆動開発
40. スキーマ駆動開発 OpenAPI Orval Orval fetch API zod msw zod 各サービスのIFをOpenAPIで定義 ソースコードを自動⽣成 client/server間の不整合を解消 package内にclientが出力される ので依存先の明示になる インテグレーションと依存関係管理 の問題に対応 API定義変更と依存するclientの 更新タイミングを強制的に一致さ せる
41. 契約による設計 スキーマがない場合、破壊的変更を把握 するために、テストでさらに多くの作業 をしなければならないことを、覚えてお いてください。” スキーマがサービス間の契約になる E2Eテストを回避する シナリオ網羅は非現実的 安定したE2E構築は難易度が高い 0.1%でFalkyなテストが100 集まったら同時実行では約 9.5%の確率で失敗する 独立デプロイ可能性の低下 “ 引用: 「マイクロサービスアーキテクチャ」 P. 158
42. 自動⽣成ソースコードの集計 ソースコード自動⽣成 自動生成は決定論 AI時代だからこそ決定論的に生成 できるものは自動生成する MOSHでは以下がOpenAPIを元に自 動生成されてる 2,397機能 APIクライアント・サーバー MCPツール定義 14,118ファイル 588,297行のソースコード
43. ⑦ガードレールと規約
44. ガードレール強化は 早ければ早いほど良い！！
45. 当然基本的なLinter, formatter, typecheckerなどは元々入れてたの で独自のカスタムルールを共有
46. デザインシステム UI コンポーネントの修正例 デザインシステム構築とプロダクト の機能開発が同時進行 整備が間に合っていないコンポーネ ントは後追いで修正 67の共通コンポーネントが存在 細分化すると221 デザインシステム準拠違反を検出す るカスタムBiomeルール8つ
47. 対応ルール数 スキーマ DB “@soartec-lab/prisma-strongmigrations” OSS エラーメッセージのサンプル 引用: 「https://github.com/soartec-lab/prisma-strong-migrations」 というツールを とし て自作 Prisma + PostgreSQL向けに特化し たマイグレーション安全性チェック Prismaが発行するSQLにリス ク・規約との不整合があった場合 にエラー処理する e.g 安全なカラム削除に誘導 人に加えてAIエージェントが自律的 に修正する事を前提に作成 39のルールが定義
48. Lint 実行時間 OpenAPI を選定 実行時間が2秒で高速 MOSHでは以下のルールを追加 カスタムルール 10個 カスタムプラグイン 7個 管理しているOpenAPIの量 path数: 359 schema object数: 201 ファイル数合計: 561 行数合計: 40,916 導入時の違反数3650(!!) Redocly CLI Linter 導入時の感想
49. 進化可能性はPlatformの積み重ね によって作られる
50. と切り離して考えていた 進化可能性が効果的なAI活用とも 繋がっていた AI
51. 要素 との親和性・効果 AI ① マイクロサービス化 影響範囲を限定し、推論対象を⼩さくできる サービス単位でコンテキスト収集を最適化し精度向上を実現 ② アプリケーション共通基盤 技術的な複雑性を基盤へ集約し、扱う実装を単純化 推論が難しい横断的な関心事を分離し、価値開発へ集中できる ③ フルスタックTypeScript + モノレポ リポジトリ全体を横断したコンテキスト収集 複数サービスを並列に開発可能で機能単位で並⾏開発が容易 ④ 機能単位でのソースコード分離 機能ごとの責務・スコープが明確になり、影響範囲を把握しやすい 複数エージェントによる並行開発・レビューが容易 ⑤ 開発ごとの独立したプレビュー環境 独立した検証環境を提供 並行開発・高速開発でも検証が競合せず、フィードバックを高速化 ⑥ スキーマ駆動開発 契約（Schema）が強力なコンテキストになる 決定論的なコードを⾃動⽣成し、推論すべき範囲を削減 ⑦ ガードレール・規約 自⼰修正・⾃⼰解決を支援 実装品質のばらつきを抑制し、自律的な開発を促進 との親和性・効果まとめ AI
52. に加えてAIの進化に合わ せてさらに強化したポイント Platform
53. Linter コンテキスト管理 AIレビュー Skill・hooks作成による標準化 e.g. ブランチPush前のセルフレビュー強制 前日マージPRの規約違反のリカバリBot マイクロサービス・Feature-Sliced Design・co-location による疎結合・高凝集 エージェントハーネスの強化 AI
54. によるSlopや破壊も影響範囲を 制限しコントロールする事で 可逆性を高めて一定許容 AI
55. 機能の疎結合による制御
56. 一方で、影響範囲を制限できない インターフェースは人が重点的 にレビュー
57. ・Backend・DBの3層の繋ぎ目であるイ ンターフェースは人がレビュー Frontend - Backend間はOpenAPIスキーマ Backend - DB間はPrisma・DBスキーマ 層を跨ぐので影響範囲が大きい。非可逆性が高い。 人のレビューをサポートするためにLinterを強化 Redocly CLIのカスタムプラグイン @soartec-lab/prisma-strong-migrations 決定論的に対処できるものはLinterに任せる SPA = Frontend 人が重点的にレビューする箇所
58. ガードレールを強化した中での影響 範囲のコントロールと人の重点的な レビューを棲み分け
59. 進化可能性への投資は競争力につな がったのか？
60. アジェンダ 1 生産性から価値への転換 2 進化可能性を実現する 技術戦略 3 AI 時代の開発競争力
61. デプロイ数43倍 PR マージ数の推移 年間の変化 デプロイ43倍 9倍 → 2.4倍 → 2倍 エンジニア人数は3.5倍 10 → 35人 人数の増加に伴い、組織の課題や マネジメントの複雑性も増加 人数増加だけではない圧倒的なデプロ イ数の増加 AI活用でマージPRが4倍になった開発 ユニットも発生 開発ユニットはエンジニア3〜5人 3
62. ランディングページ作成機能 マルチプロダクト拡張 直近一年の変更: 13の新機能 ビジュアルエディターを扱う複雑 なUIを持つ機能を含む 11の既存機能リニューアル ホーム画面など影響範囲が広い機 能を含む 6の共通基盤開発 決済、通知、トラッキング、プラ ン管理、メッセージ配信、テナン ト管理
63. 自社AIエージェント機能 新パラダイムの開発 自社AIエージェント MCP公開 MCP 公開
64. 人がデザイン AI 出力の品質向上 AI 生成
65. 進化可能性はプロダクト開発の効率化だけではなく様々 な領域の進化を可能にした 開発速度 組織のスケール 新しい技術の導入 新しい価値提供 新しい開発プロセス 進化可能性が生んだ効果
66. 進化可能性はAIによってさらに強 力な競争戦略になった
67. 生産性向上と競争戦略
68. 生産性の向上 生産性はAIとPlatformの両輪 必ずしもAIエージェントハーネス だけではない 複数の要素の積み上げ AI活用そのものは当たり前 AIを使っているだけでも自然と進 化の恩恵が受けられる 生産性をさらに向上させるためには 自分たちでコントロールする領域で あるPlatformへの投資が必要
69. による生産性向上そのものは当たり前 差別化にはならない 重要なのは生産性向上による余剰の使い道 AI による生産性向上と競争戦略 AI
70. 生産性の分岐構造
71. これまでは高い生産性を持つ組織だけが生産性向上後に 何へ再投資するかという問いに直面していた AIによって多くの組織で生産性が向上 その結果「生産性向上→ 余剰→ 次に何へ投資するか」と いう問いは多くの開発組織が直面するものになった AI は生産性を民主化したのと同時に、高い生産性を持つ 組織が先に経験していた問いも民主化した によってこの問いは一般化した AI
72. 冒頭の問いの再掲: 生産性向上によって生まれた余剰を 何に再投資しますか？
73. 私の答え: AI活用の生産性向上で生まれた余 剰を消費ではなく未来の生産性と進 化可能性を生む仕組みに再投資する
74. による生産性向上を再投資する 複利構造を持つ技術資産を構築でき るかがAI時代の開発競争力を決める AI
75. 計測・検証に対してのAI活用 量ではなく価値の生産性向上 人のクリエイティビティと標準化 「生産性 = 一人当たりの平均生産量」における個人のバラツキ ハーネスをガチガチに組んだ結果、人の工夫の余地が減る、あ るいは足かせになってしまう懸念 低い基準に合わせてガードレール設計すると膨大になる CI速度やコストなどに跳ね返る ドメイン知識の蒸留 振る舞いと知識の凝集、カプセル化をAIは⾒過ごしがち 残された課題
76. は生産量を底上げした 価値は複数の変数が複雑に関わる 計測と適応による実験には進化可能性が必要 進化可能性はPlatfromの積み上げ 進化可能性はAIとも高い親和性を持つ AI によって多くの組織の生産性が底上げされたと同時 に、高い生産性をもつ組織が抱える問いに直面する 問いに対する私の答えは、複利構造を持つ技術資産を構 築できるかがAI時代の開発においての競争力を決める AI まとめ
77. おわり