©KAKEHASHI inc. プロダクトを育てるように 生成AIによる開発プロセスを育てよう 2026年04月09日 もっち(松本 明紘) 【AI駆動開発】AI自走環境構築・運用スペシャル #1 

株式会社 カケハシ(2023年2月〜現在) ● 新規プロダクト、AI在庫管理 ● バックエンドに軸足を置くテックリード もっち(X: @mottyzzz) 松本 明紘 自己紹介 

生成AIにより開発スピードは劇的に変化した ● 生成AIによるコード生成が日常になった ● 以前なら数日かかっていたことが、数時間で形になる コードレビューが 速度的にも心理的にもボトルネック 

コードレビューによって担保してきたもの 4 ● 定性的なコードの”良さ” ● 知識共有によるメンタルモデルの獲得・理解 コードレビューによって コードをチームのものにしてきた 

アプローチ 5 ● 生成AIの自律性をより高めて、 価値提供のリードタイムを短くすること ● 生成AIによるコードレビュー品質を これまで以上に高めること ● 知識共有、メンタルモデル醸成の場を コードレビュー以外にプロセスとして設計すること 

AI-人間の関係モデル 6 https://x.com/takuro_n/status/1917762108672074046?s=20 ここを目標として進める 

進め方 7 ● ツールも考え方もまだまだ変化が多い ○ 実際、本日紹介する取り組みも1か月後には変わってる可能性 ● HOTLを目指すにしても 最初から開発の全てがそうなることはない ● 変化に適応するために、 チームとして開発プロセスを明確に育てていく ● 個人情報を扱うような本番環境の操作などは 本取り組みのスコープ外 

プロダクトを育てるように 生成AIによる開発プロセスを育てよう 

大事にしてきたもの 9 ● プロダクト ● チーム データ分析やふりかえりによって、 フィードバックループを回すことで進化させてきた 

大事にしてきたもの 10 ● プロダクト ● チーム ● 生成AIによる開発プロセス プロダクトやチームの進化の中に暗黙的に入ってい た開発プロセスのカイゼンを、明確に育てる対象と することで適応を進める 

生成AIによる開発の流れの中にも下記を適用する 11 ● 検証可能な小さなユーザーストーリー、そしてタスク ○ 生成AI自身が自身の結果を検証しながら進める ○ 人間が生成AIの結果を検証可能な状態にしておく ● ふりかえりによるフィードバックループ 

前提 12 ● スクラム ● ユーザーストーリーを中心とした開発 ○ 直接利用者に影響のない開発だとしても、 開発チームをユーザーとして実施 ● 本日紹介する取り組みで活用しているツール ○ Jira ○ Claude Code 

ユーザーストーリー、タスクの構造 13 プロダクト ロードマップ フェーズ (エピック) ユーザー ストーリー 設計 タスク フェーズ (エピック) ユーザー ストーリー 実装 タスク ユーザー ストーリー ユーザー ストーリー 設計 タスク 実装 タスク タスク タスク タスク タスク ・・・ ・・・ ・・・ PR PR PR PR PR PR PR PR 

ユーザーストーリー、タスクの構造 14 プロダクト ロードマップ フェーズ (エピック) ユーザー ストーリー 設計 タスク フェーズ (エピック) ユーザー ストーリー 実装 タスク ユーザー ストーリー ユーザー ストーリー 設計 タスク 実装 タスク タスク タスク タスク タスク ・・・ ・・・ ・・・ PR PR PR PR PR PR PR PR 

小さいユーザーストーリー、タスク 15 ● リファインメントをモブで実施。 その中で、概要設計、タスク分割まで行う ● ユーザーストーリーやタスクを分割する過程で、 開発チーム内のメンタルモデルを作る ● 小さくすることで、必要な理解の負担を低減、 タスクの種類ごとのアプローチの選択をしやすくする 

開発の進めかた 16 プロダクト ロードマップ フェーズ (エピック) ユーザー ストーリー 設計 タスク フェーズ (エピック) ユーザー ストーリー 実装 タスク ユーザー ストーリー ユーザー ストーリー 設計 タスク 実装 タスク タスク タスク タスク タスク ・・・ ・・・ ・・・ PR PR PR PR PR PR PR PR 

実行計画の作成とタスク分割 17 ● 実行計画の作成 ○ Jiraのチケットに結果とQ&A履歴を記録 ○ 完了の定義と検証方法も合わせて記録 ● タスク分割 ○ PRが小さくなるようにタスクを分割する ○ 特に、設計(と呼んでいるもの)は、 生成AIが実行はほぼ行うが、人間による意思決定を入れるもの ■ OpenAPIスキーマ、DBスキーマの変更 

実行計画 タスク 記録、検知、カイゼンのフィードバックループ 実行計画スキル (execution-plan) 実装スキル (implement) 小さな ユーザース トーリー (Jira) 実行計画 タスク (Jira) コード セルフレビュー スキル (implement、 refine-loop) ガイドライン 過去のプラ ン結果 ガイドライン レビュー ガイドライン 保存した 実行計画 Lint、単体テ スト、結合テ スト レビュー指摘 とその対応 方法 チームレビュー マージ (デプロイ) Pull Request レビュー指摘 とその対応 方法 完成 レビュー ガイドライン ヒューマン レビュー ポイント ガイドライン ふりかえり スキル (task-retrospective) 実行計画時 の不足情報 

実行計画 タスク 現時点での人間の介入度合い 実行計画スキル (execution-plan) 実装スキル (implement) 小さな ユーザース トーリー (Jira) 実行計画 タスク (Jira) コード セルフレビュー スキル (implement、 refine-loop) ガイドライン 過去のプラ ン結果 ガイドライン レビュー ガイドライン 保存した 実行計画 Lint、単体テ スト、結合テ スト レビュー指摘 とその対応 方法 チームレビュー マージ (デプロイ) Pull Request レビュー指摘 とその対応 方法 完成 レビュー ガイドライン ヒューマン レビュー ポイント ガイドライン ふりかえり スキル (task-retrospective) 実行計画時 の不足情報 現時点： Q&Aに答える、結果の確認・修正 目標： 同じ（精度を上げて判断の頻度を下げ る） 現時点： ほぼ何もしない 目標： ほぼ何もしない 現時点： 人が最終決定を行う (レビュー効率自体は上がっている) 目標： 人がレビューすべきときだけ エスカレーション(その精度を上げる) 現時点： 人がやる 目標： 同じ 現時点： 人がカイゼンの起 票の意思決定 目標： 自動的にカイゼン も進む 

それらを支えるスキル 20 スキル 説明 アウトプット refinement 大きめの開発スコープ定義から、ユーザーストーリーやタスク分 割を支援 Jiraのユーザーストーリー候補、タスク候補 execution-plan ユーザーストーリーから実行計画を立てて、小さなPRになるよ うにサブタスク分割 Jiraのユーザーストーリーに追記 ● 実行計画 ● 検証/テスト計画 ● 計画時のQ＆A結果 implement 実装計画をもとに実装を進める。 人間がレビューすべきかをガイドラインに基づき判断する(実験 中) PR Jiraのチケットに計画時に不足していた情報を記録 refine-loop セルフレビュー、改善を複数回繰り返す (変更後の)PR code-review guideline-review コードのレビュー、ガイドラインに沿っているかのレビュー コードレビュー結果 review-respond レビューに対する対応を行う (変更後の)PR、レビュー指摘への返信 task-retrospective 実行計画、実装時の記録、レビュー結果から、ふりかえりを行い、 ガイドラインへの追加やLintの追加、不足していたテストの追加 などを洗い出しカイゼンの提案を行いチケットにする カイゼンのJiraチケット check-task PR、Jiraのチケットなどから次に何をすべきかの優先度を判断 してNext Actionを提案(HOTLへの準備) Next Action 

ふりかえりによるフィードバックの例 21 ● 基本的には、作り込みの品質を上げるようにフィードバックさせている ● 計画時の検査・テスト観点の洗い出しの精度向上 ○ 境界条件を入れる観点自体はあったが、 現状の実装やQ&Aを通して境界条件を明確化するプロセスをスキルに追加 ● 運用後を見据えたオブザーバビリティの向上 ○ 計画時からログをどう出すかも洗い出せるようにスキルの追加 ● ガイドラインからルールへ ○ OpenAPIスキーマに記載しているAPI仕様の書くべき項目を ガイドラインから、カスタムLintにして厳格化 

どれだけフィードバックループを回せるようにしたとしても 22 ● 生成AIは隣のコードを真似するため、”悪い”状態のも のがあると、それが指数関数的に増えていく ● 現状のコードが”良い”状態になっているのが前提 

ガイドライン、ルール、その他の仕組み 23 ● ガイドライン ○ DBの設計方針 ○ APIの設計方針 ○ 共通ライブラリ化の方針 ○ エラーハンドリング ○ ログ出力 ○ レイヤー設計、モジュラーモノリスの分割基準 ○ リクエストコンテキスト設計 ○ ヒューマンレビューポイント ○ テスト方針 ○ GitHub Actionsの構造化設計 ○ ユビキタス言語 ● Lint ○ これまでよりも厳し目のルール設定 ○ 参照関係のチェック ○ ユビキタス言語チェック(チャレンジ中) ● 単体テスト、結合テスト ○ レイヤーごとにテストカバレッジ(C1)の指標化 ● スキーマ駆動をベースにした SDD ○ OpenAPIスキーマ＋API仕様でコード生成 ● APIテスト ○ Gharkin記法で仕様の理解容易性向上 ● レビューガイドラインの観点 ○ ガイドラインを守っているか ○ テスト品質 ○ トランザクション、ロック ○ 境界条件 ○ OpenAPI仕様と実装の一致 ○ パフォーマンス ○ コードのわかりやすさ、コード品質 ○ SQL最適化 ○ TypeScript品質 ○ セキュリティ 

すべての前提となっている徹底的な構造化 24 ● モジュラーモノリス×クリーンアーキテクチャ ● テスト容易性の向上 ● DBのテーブルごとにオーナーとなるモジュールを決め て、それ以外からの直接アクセスを禁止して変更の影 響範囲を最小化 ● モジュールごと、レイヤーごとのガイドライン、ルー ルを整備しやすくする 

まとめ 25 ● フィードバックループを設計するによって 生成AIの開発プロセスを育てていく ● 生成AI自身にふりかえりに必要な情報の記録、 ふりかえりの実施、カイゼン提案までやってもらう ● 粒度を小さくすること、区切りを用意することで、 HIC→HITL→HOTLへの変化をしやすくする 

ありがとうございました カケハシの技術に関連する情報を 発信しています！ 𝕏 @kakehashi_dev 是非フォローもお願いします！ 26 

©KAKEHASHI inc. プロダクトを育てるように 生成AIによる開発プロセスを育てよう 2026年04月09日 もっち(松本 明紘) 【AI駆動開発】AI自走環境構築・運用スペシャル #1