【2025/12/17 の アプデ版】AI Coding の次は何を目指すべき？組織で整備していくべき AI インフラ_1217

Transcript

1. ©2017-2025 kikagaku, Inc. All Rights Reserved. 1 AI Coding の次は何を目指すべき？ 組織で整備していくべき AI インフラ 2025/12/17
2. ©2017-2025 kikagaku, Inc. All Rights Reserved. 2 自己紹介 • 株式会社キカガク • 普段は Next.js, NestJS, PostgreSQL など • 最近は社内 AX 化の推進担当 • ２人の子どもに囲まれコーディングしてます • Zenn 主催の AI Agent Hackathon で受賞しました @tetsuro_b（石橋鉄朗）
3. ©2017-2025 kikagaku, Inc. All Rights Reserved. 3 会社紹介
4. ©2017-2025 kikagaku, Inc. All Rights Reserved. 4 会社紹介
5. ©2017-2025 kikagaku, Inc. All Rights Reserved. 5 アジェンダ １ ３ 2025 年の AI まわりを振り返り 弊社の取り組みの実例紹介 ２ 本日の登壇テーマのきっかけとなる課題の共有
6. ©2017-2025 kikagaku, Inc. All Rights Reserved. 6 ©2017-2025 kikagaku, Inc. All Rights Reserved. 6 2025 年を振り返ろう
7. ©2017-2025 kikagaku, Inc. All Rights Reserved. 7 2025 年を振り返ろう
8. ©2017-2025 kikagaku, Inc. All Rights Reserved. 8 ©2017-2025 kikagaku, Inc. All Rights Reserved. 8 実装は驚愕のスピードで進化している では、価値提供までのスピードも上がっている？
9. ©2017-2025 kikagaku, Inc. All Rights Reserved. 9 実装が早くなっても価値提供のスピードは上がらない ・小さなバグ改修、新規プロダクトは劇的にスピードが上がっている ・既存のプロダクト開発では… リ リ ー ス 作 業 • PR が増えたことでリリー スの頻度が増えた • = PR レビューやその他に 使う時間が相対的に減る • ※ リリーストラブルによる 対応も増える レ ビ ュ ー • レビュー自体の工数はそこ まで変わっていない • ※ AI レビューは大幅な工 数削減に繋がりにくい • むしろ PR が増えたことに より、レビュー待ちの時間 が増えた • commit するスピードと量 が上がった • それと比例して CI を通す タイミングも増えた • 結果的に 1 日の中で CI を 待つ時間が増えた CI（Test, Lint）
10. ©2017-2025 kikagaku, Inc. All Rights Reserved. 10 ツール（LLM）の進化はすべての課題を解決しない • AI ツールや LLM は私たちが何も努力しなくても日々進化していく • コーディングのスピードや品質はこれからも上がり続ける • しかし、LLM の性能向上の恩恵を受けない部分は勝手に進化しない • = その部分こそがボトルネックになりうる箇所で組織で改善していくべき課題 「コーディング 10 → 11 に上げる努力」は引き続き + 「それ以外を 5 → 8 に上げる努力」に注力する 要件定義 設計 実装 レビュー リリース
11. ©2017-2025 kikagaku, Inc. All Rights Reserved. 11 ©2017-2025 kikagaku, Inc. All Rights Reserved. 11 実装以外の工程にどうアプローチしていくか
12. ©2017-2025 kikagaku, Inc. All Rights Reserved. 12 組織で整備していくべき AI インフラ ▪ 本日の登壇テーマ AI Coding の次は何を目指すべき？組織で整備していくべき AI インフラ レビューが不要になる最強エージェント作りました！ 要件定義漏れなくやれる最強エージェント作りました！ デザイン一発生成できる最強エージェント作りました！
13. ©2017-2025 kikagaku, Inc. All Rights Reserved. 13 実装以外の工程にどうアプローチするか こんなスーパーエージェントの話じゃないです （期待してた方いましたらごめんなさい） 本日は弊社の実例を交えながら 「AI 時代だからこそ、愚直にやっていくべきなんじゃないか」 みたいなことを話していきます AI インフラ = AI の進化を組織で最大限享受するための体制整備
14. ©2017-2025 kikagaku, Inc. All Rights Reserved. 14 組織で整備していくべき AI インフラ 1 2 3 4 デザイナーコミュニケーション 各種 CI コードレビュー リリース 要件定義 設計 実装 レビュー リリース 1 2 3 4 どの組織にも転用できる考え + 弊社の取り組みも紹介 運用 ５ ５ 運用
15. ©2017-2025 kikagaku, Inc. All Rights Reserved. 15 ©2017-2025 kikagaku, Inc. All Rights Reserved. 15 デザイナーコミュニケーション
16. ©2017-2025 kikagaku, Inc. All Rights Reserved. 16 デザイナーコミュニケーション ▪ 課題 • 要件定義もコーディングもエンジニアの作業は加速し続けている • その中間に位置するデザイナー領域においてはエンジニアほどの進化がない • 進化がない = 精度高く生産性が上げられるツールがない • モックアップレベルは加速しているが…（エンジニアの 2025 初頭のよう） デザイナーのアウトプットスピードの向上 = プロダクトの価値提供スピードを上げる要因になりえる 要件定義 デザイン 実装
17. ©2017-2025 kikagaku, Inc. All Rights Reserved. 17 コードの垣根を超えたエンジニアとデザイナーの協業 ▪ デザイナーも Cursor を使える環境整備 • Cursor のカスタムコマンドで環境構築 → アプリ起動を自動化 • Cursor を使うことでモックアップの爆速化 • 従来の「持ち帰り→ FB → 修正…」の所要時間を短縮 • 最近は Figma Make も良いようで、あわせて検証中 • https://zenn.dev/kikagaku/articles/f96c2f24c24151 ▪ デザイナーが PR を出せる環境整備 • デザインシステム改修時の反映は Devin を使いデザイナーが行う • 従来エンジニアに指示を出していた先が Devin に置き換わるイメージ • これまではエンジニア側のリソース調整をしたうえでの反映になっていたがスピード感持ってより 統一感のあるプロダクトデザインを提供可能に • デザイナーチームだけで 15 個のプロダクト改善(PR)を出した月も。
18. ©2017-2025 kikagaku, Inc. All Rights Reserved. 18 誰もが PR を出せる文化作り Devin, Chromatic を活用し実装＆レビューコストを抑え PR を作成する体制を整えている 要望 実装 デザイナー レビュー デプロイ 修正 （ローカル環境） エンジニア マーケター Devin Chromatic デザイナー マーケター レビュー依頼
19. ©2017-2025 kikagaku, Inc. All Rights Reserved. 19 コードの垣根を超えたエンジニアとデザイナーの協業 詳細は Speaker Deck にも記載しております！ https://speakerdeck.com/tetsuro_b/tesainamomakemoprwochu-su-ensiniakarabu-miji-rukai-fa- wen-hua-toaiwoshi-tutashi-zu-mitukuri
20. ©2017-2025 kikagaku, Inc. All Rights Reserved. 20 【2025/12/11】Cursor ビジュアルエディタがでた！ Cursor が Figma みたいに進化した！ ますます、デザイナーとコードの距離が近くなっていく。 https://cursor.com/ja/blog/browser-visual-editor
21. ©2017-2025 kikagaku, Inc. All Rights Reserved. 21 ©2017-2025 kikagaku, Inc. All Rights Reserved. 21 各種 CI
22. ©2017-2025 kikagaku, Inc. All Rights Reserved. 22 各種 CI の改善 ▪ 課題 • AI はエディタから Lint や型エラーを都度汲み取って直してくれない • AI にそれらのエラーを伝えるには CLI でのコマンド実行が必須 • AI Coding ではコマンドの実行回数が従来よりも多いため「コマンドの実行回数 x 時間」が 生産性に顕著に現れる = これまで以上に CI のスピードが重要 • Claude Code の hooks で都度実行もできるが実行時間が長いとつらい… • （極論、コード生成都度実行しても支障がないレベルを目指したい） 実装 CI 実装 CI 実装 どれだけ AI Coding でアウトプットスピードが上がっても CI の待ち時間が長いと全体の時間は短縮されずらい
23. ©2017-2025 kikagaku, Inc. All Rights Reserved. 23 各種 CI の改善 ▪ Jest → Vitest • CI 実行時間が約半分になった（8min 前後 → 4min 前後） • レビュー修正後の再レビュー依頼の待ち時間も削減 • Zenn にも弊社のメンバーが書いた記事があります！ • https://zenn.dev/kikagaku/articles/testing-framework-jest-to-vitest ▪ Knip • 不要な export があれば CI 実行時に教えてくれる • エラーになったら CI が落ちる • → AI によるゴミ関数がリポジトリに増えていくのを防ぐ • https://github.com/webpro-nl/knip
24. ©2017-2025 kikagaku, Inc. All Rights Reserved. 24 各種 CI の改善 ▪ ESLint/Prettier → Biome（検証段階） • 一部のカスタムルールが Biome に移行しずらい説があるので既存 repo ではまだ試せていない • 公式サイトには Prettier と比較して最大で 35 倍と記載がある • 世間のブログを読んでいるとそれ以上の結果も見かけたりする • 新規の環境では Biome の採用を積極的に進めている ▪ Feature-Sliced Design（検証段階） • フロントエンドのディレクトリ設計の１つ • 各レイヤーの依存関係のチェックやディレクトリ構成のルール化 • → AI による無秩序なファイル生成を防ぐ • https://github.com/feature-sliced/steiger
25. ©2017-2025 kikagaku, Inc. All Rights Reserved. 25 ©2017-2025 kikagaku, Inc. All Rights Reserved. 25 コードレビュー
26. ©2017-2025 kikagaku, Inc. All Rights Reserved. 26 コードレビューの改善 ▪ 課題 • AI Coding によって生成されるコード量＆PR 数が増えた • その分、人間のレビュー負担が増加。結果、レビュー渋滞が発生 • 各種 AI レビューツールもあれど一般的なレビューコメントも割合も多い • 単純に「AI レビューツールの導入 = レビュー工数の削減」とまでは言いづらい ▪ レビュー部分をどう改善していくか 主に以下の２軸でコードレビューは改善していく • AI 時代におけるレビュー観点の再整理 • ツールでのアプローチ
27. ©2017-2025 kikagaku, Inc. All Rights Reserved. 27 AI 時代におけるレビュー観点の再整理 ▪ AI 時代だからレビューしなくてもいい項目はあるか？ • ほぼない。これまで同様にコードの質やテストの中身は重要 ▪ AI にはできないレビュー観点はあるか？ • レビューしなくてもいい部分を探すのではなく、 • AI にレビューを任せられる部分はどこだろうか？ • では、人間にしかできない部分はどこなんだろうか？ • と考えるべきでは。
28. ©2017-2025 kikagaku, Inc. All Rights Reserved. 28 ツールでのコードレビューへのアプローチ ▪ Devin によるコードレビュー • Devin によるコードレビューを入れたりしています • diff だけ見てレビューするのではなくリポジトリのドキュメントなど参照してからレビューしてくれる • コスト面でも人数毎の課金ではないので Devin を既に使っていたら導入しやすい • ローカルでも各種 AI ツールで実行できるように整備 ▪ Devin によるレビュー修正 • レビューではなくレビュー修正にも Devin を活用しています • PR に特定のラベルを付けたらレビューコメントに応じて Devin が自動でレビュー修正済みの PR 作成 • レビューワーはレビューコメントと PR をレビューイに投げるみたいな運用もできるので、PR 増加に 伴うレビュー修正渋滞も緩和できる • = マージまでのスピードアップに貢献
29. ©2017-2025 kikagaku, Inc. All Rights Reserved. 29 ツールでのコードレビューへのアプローチ ▪ PR 複雑度評価の導入 • レビュー前に CI でのコードレビューと同時に、 PR 複雑度の評価も行っている ★ 目的 • PR サイズ = レビュー工数に直結するため、 PR 都度、適切な PR サイズかチェックして意識づけ ★ 仕組み • レビュー前に Devin の API でセッション起動 • PR の diff に対してレビューを実施
30. ©2017-2025 kikagaku, Inc. All Rights Reserved. 30 チーム体制でのコードレビューへのアプローチ ▪ レビュワーを１名 → ２名へ • とにかく PR の数が多いので１つの PR が渋滞すると「子 PR, 孫 PR, 孫々 PR….」 のようにレビュー待ちの PR が渋滞しがちで、かなり生産性に支障をきたす • １人が MT などで拘束されて手が空かない瞬間ができると、この状況になりやすい • レビュワーもレビュー渋滞のを見てたら自分の PR のレビュー修正が遅れて、他の 人の PR にも影響が出始めるなんてことあるある。 • レビュワーを２名してどちらかが爆速で PR レビューを実施 • 結果、特定のチームでは PR のマージまでのリードタイムが 24 時間以内に
31. ©2017-2025 kikagaku, Inc. All Rights Reserved. 31 ©2017-2025 kikagaku, Inc. All Rights Reserved. 31 リリース
32. ©2017-2025 kikagaku, Inc. All Rights Reserved. 32 リリースの改善 ▪ 課題 • AI Coding によってマージされる PR が増加 = リリース時の QA 工数の増加 • AI Coding によって浮いた時間が結局リリース工数、加えてリリース増加に伴うトラブル対 応への工数に一部置き換わっているようにも見える • リリース作業自体をなくす or 完全 AI 自動化は現実的ではないので改善していく必要性あり • （CI/CD の整備は大前提）
33. ©2017-2025 kikagaku, Inc. All Rights Reserved. 33 リリースの改善 ▪ リリース手順書の自動作成 • リリース前にマージ PR に記載された QA 項目をリリース手順書に転記する作業が存在 • GitHub MCP を活用してその手順を自動化（5-10 分 → 1-2分 に削減） ▪ E2E テストの徹底した整備 • 既存機能の改修も増えたことで既存機能のデグレードの QA も都度手作業で実施する機会増 • 結果的にリリース工数の増加につながってしまっているので E2E 強化チームを作り急速に 整備した
34. ©2017-2025 kikagaku, Inc. All Rights Reserved. 34 ©2017-2025 kikagaku, Inc. All Rights Reserved. 34 運用
35. ©2017-2025 kikagaku, Inc. All Rights Reserved. 35 運用 ▪ パッケージの更新対応を Devin に任せて自動化する • 基本は Renovate を使っているが、どうしても型エラー等でスムーズにマージできないケースも • CI のエラーをトリガーに Devin が起動しエラーの調査＆対応 • これまでは人の手で修正していたが、約 6 割ほどが Devin により自動修正されている • 詳細は Zenn に記載：https://zenn.dev/kikagaku/articles/d5e100fa2a6b36 ▪ プロダクトテンプレートの作成 • AI で爆速実装できる今、PoC でプロダクトを立ち上げる機会も増えてきた • アプリケーションコード 〜 CI/CD までセットになったリポジトリテンプレートを作成 • → 新規にプロダクトを立ち上げるハードルを下げ、価値検証までのリードタイムを高速化
36. ©2017-2025 kikagaku, Inc. All Rights Reserved. 36 運用 ▪ 運用におけるスクリプト実行を徹底的に減らす • データの修正や特例対応など何かとスクリプト実行が必要なケースが多い • スクリプトの実行には以下のようなデメリットがある ・本番環境への操作となるため２人以上で同期的に実施 → ２人の時間を奪う ・開発者しか実行できないため、開発部隊への負担増加 • スクリプト実行が必要なケースは徹底的に社内アプリへ機能実装をする ・AI 時代以前では社内アプリの機能でも実装コストが高かったので、仕方なくスクリプトを 書くしかなかったが、AI により実装コストが激減したので実装の意思決定をしやすくなった • 結果、開発部での問い合わせ対応工数が 3-4 割減り開発に避ける時間が増えた
37. ©2017-2025 kikagaku, Inc. All Rights Reserved. 37 まとめ • AI Coding だけに注力していては全体の生産性はあがらない • = 価値提供までのスピードは上がっていかない • どこを改善すれば AI Coding のアウトプットスピードをフル活用できるか考えることが重要 要件定義 設計 実装 レビュー リリース
38. ©2017-2025 kikagaku, Inc. All Rights Reserved. 38 採用情報 株式会社キカガクでは様々なポジションでエンジニアを募集中です！ Zenn もやっているので求人とあわせてみていただけたらうれしいですー！ https://findy-code.io/companies/958/jobs https://zenn.dev/p/kikagaku
39. ©2017-2025 kikagaku, Inc. All Rights Reserved. 39 参考資料 • コードの90%をAIが書く世界で何が待っているのか @r-kagaya （https://speakerdeck.com/rkaga/what-awaits-us-in-a-world-where-90-percent-of-the-code-is- written-by-ai） • AIの自律開発を目指して 〜Cursorを用いたドキュメント管理〜 @nambu （https://speakerdeck.com/gonambu/aiming-for-autonomous-development-of-ai）