整備して終わりにしない - CI/CD + CL でハーネスを育てる仕組み 合わせる

Transcript

1. 整備して終わりにしない CI/CD + CL でハーネスを育てる仕組み - と称して ⼈とAIのレビューから、ハーネスを育て続ける取り組みの実例を紹介 TomohiroYamada（Findy） © Findy Inc. 1
2. とり急ぎ、⾃⼰紹介から やまだ （TomohiroYamada / @YamadaMuscle） （Findy在籍 / カンファレンスサービスの開発） • フルスタックエンジニア（現在はruby、reactで複数リポジトリを横断で開発） • 好きなツール: Claude Code とダンベル 󰝯 • 好きなこと: AI と 筋トレ 💪 半世紀ぶりの技術系の登壇なので多分緊張してます > < © Findy Inc. 2
3. 本⽇お話する内容 01 ハーネスは「整備して終わり」ではない（⾃戒を込めて） 整備して終わりにしないために、改めてハーネスと、そのアプローチ整理の話 02 ハーネスを育てる上で「学び⽅」を仕組み化した実例 継続的に学び続ける仕組み（CL）をCI/CD に乗せて、各リポジトリへ配る仕組みの話 © Findy Inc. 3
4. 01 ｜ ハーネスは「整備して終わり」ではない（⾃戒を込めて） 整備して終わりにしないために、改めてハーネスと、そのアプローチを整理する © Findy Inc. 4
5. まず釈迦に説法、 基本的なハーネスを整えるだけで開発体験は劇的に上がる 整備する前 整備した後 毎回コンテキストや規約を説明し直す ☺ → CLAUDE.md / rules → ⽂脈‧規約‧設計を渡さなくても理解している 👌 規約‧整形から外れたまま気づかない ☺ → hooks → 規約‧整形の崩れを⾃律的に対応してくれる 🙌 毎回の作業に躓く、失敗を繰り返す ☺ → Skills / subagent → 定型作業をまるっと任せ、躓かず完遂してくれる 🫶 → 整備で負担が減り、開発体験は劇的に上がる。 多くの開発組織でも出来ているはず ☺ © Findy Inc. 5
6. だがしかし、 整備して終わりになっていないだろうか ハーネスの指⽰‧設定系を整備した: CLAUDE.md‧rules‧Skills‧hooks、全部整えた 💪 AIエージェントを導⼊した。負担が減り、開発速度も上がった 💪💪 でも、整備しても そこから先は勝⼿には賢くならない 👀 整備した後につまずいた過ちは、次のPRでもその次のPRでも、何度でも繰り返す。例えば ‧微妙な間違い‧規約外れ … 何度直しても再発し、レビューで毎回拾う ‧同じ⼿戻り … PRごとに、同じやり取りを繰り返す ‧不要な⼀般論を述べる … その場限りの指摘で、本質的なレビューに届かない 開発者は成⻑してもAIは勝⼿に成⻑しないから。成⻑しないとAIの能⼒は錆びつき、信頼が失われる 😔 → なぜか？ 整備は始まりで、書き終えた時点からまた負債化が進んでいく。学ぶ仕組みがないから © Findy Inc. 6
7. じゃあ、 ハーネス整備しよう！と⾔ってもハーネスも⾊々ある 種類も内容も様々。例えば馴染みある内容を3つの領域に区別すると 個⼈‧ツール領域 例 Claude Code / Codex / Cursor / LLMモデル / に紐づく個⼈設定やプロンプト、 ローカルSkills 等 特徴：進化が速い。明⽇にはベストプラクティスが変わる領域（fableも3⽇で追悼式） リポジトリ領域 例 CLAUDE.md / .claude/rules / hooks / また設計原則 や ドメイン知識 等 特徴：⽇々リポジトリの成⻑と共に固有の開発ドメイン増えていく領域 共通基盤領域 例 組織利⽤の仕組み、CI/CD共通ワークフロー / AIレビュー / タスク管理 / 計測 / セキュリティ 等 特徴：組織的に活⽤されて効果に再現性が必要な領域 © Findy Inc. 7
8. しかも、 領域ごとに育て⽅が違う アプローチも画⼀的じゃない。それぞれの領域に適した向き合い⽅がある。 個⼈‧ツール領域 例 Claude Code / Codex / Cursor / LLMモデル / 個⼈設定 / ローカルSkills 等 育て⽅：変化が速いので、新しいツールや機能を素早くキャッチして柔軟に取り込む リポジトリ領域 例 CLAUDE.md / .claude/rules / また設計原則 や ドメイン知識 等 育て⽅：⼀般論じゃないドメイン知識含め、チームに最適化した判断基準を深く磨き込む 共通基盤領域 例 組織的に利⽤している仕組み、CI/CD共通ワークフロー / AIレビュー‧計測 / 学習候補抽出 / 安全装置 等 育て⽅：汎⽤的で再現性⾼く‧計測可能な仕組みを、丁寧に整備する 個⼈は変化に柔軟であり、リポジトリはドメイン深掘り、共通基盤は汎⽤的で再現性ある仕組みを考える © Findy Inc. 8
9. 本⽇は 「共通基盤領域」に設けた仕組みの実例を紹介します 明⽇から真似できる継続的なハーネス改善 と謳えるくらいには導⼊しやすい取り組みです。多分 💪 個⼈‧ツール領域 例 Claude Code / Codex / Cursor / モデル / 個⼈設定 / ローカルSkills 育て⽅：変化が速いので、新しいツールや機能を素早くキャッチして柔軟に取り込む リポジトリ領域 例 CLAUDE.md / .claude/rules / また設計原則 や ドメイン知識 等 育て⽅：⼀般論じゃない固有ドメインがある。最適化した判断基準を深く磨き込む 共通基盤領域 例 組織的に利⽤している仕組み、CI/CD共通ワークフロー / AIレビュー‧計測 / 学習候補抽出 / 安全装置 等 育て⽅：全体波及するので、汎⽤的で再現性⾼く‧計測可能な仕組みを、丁寧に整備する 今⽇ここ © Findy Inc. 9
10. 02 ｜ ハーネスを育てる上で「学び⽅」を仕組み化した実例 継続的に学び続ける仕組み（CL）をCI/CD に乗せて、各リポジトリへ配る仕組みを紹介 © Findy Inc. 4
11. まず、 CI/CD + CL の「CL」についての解説 CLは Continuous Learning。 各リポジトリで⽇々の誤り‧不整合を拾い、次に活かす学習の仕組みを指す。 ※ モデルの再学習の事ではなく、説明のための造語、コンティニュースラーニング。 CI Continuous Integration は コードを継続的に統合 CD Continuous Delivery は 価値を継続的に届ける CL Continuous Learning（造語）は 判断基準‧知識を継続的に学ぶ 今回は学ぶ仕組みをなぜ CI/CD機構に乗っけたか？ CI/CDはデリバリの最終関⾨で全コード変更が必ず通る場所。全ての開発物をオープンからマージまでの全てのコードの品質や状態、 ⼈の判断など、学習のために必要な要素を漏れなく拾うことが出来る開発の共通項、かつ各リポジトリに連携しやすいので狙いを定めた。 ※もちろんCLを置く場所はCI/CDに固定する必要はなく、組織ごとの環境やハーネスを組む対象に合わせて仕掛けを機能させやすい対象を選ぶべき。 → CI/CDに学ぶ仕組みを設ける。── では、何を‧どのように学ぶ？ © Findy Inc. 11 ➕
12. 今回の学ぶ仕組みの実例は AIレビュー能⼒を上げるための学習について解説 ⼈から判断基準を学び、次から AI ⾃⾝が指摘できるようにする。 © Findy Inc. 11.5
13. 何を‧どのように学ぶ？ ── AIのレビュー能⼒を上げるための継続的学習について、4ステップを解説 ① 学ぶ ハーネスが持ってない知識や判断基準を⾒つけ、AIが気づける状態にする ② 測る ⽬的（レビュー負荷↓）に紐づく指標で効果を確認する ③ 配る 学ぶ仕組みを全リポジトリへ（GitHub Actions の共通化） ④ 磨く 各リポジトリの伸び‧つまずきを⾒て、再現性あるものを全体へ循環させる © Findy Inc. 12
14. ①学ぶ 何学ぶ、 各リポジトリのCI/CD上で何を学ぶのか？🏫 Where｜どこから学ぶか  ‧PR上で ⼈間が関わった⾏動から学ぶ Why｜ ⼈から学ぶ、AI の⾏動は学ばない ‧例えばAIが指摘できている = AIの能⼒範囲内で教え直しても限界効果が⼩さい ‧AIが認知できる出⼒を⾃分にフィードバックする循環は改善につながらない。⼈間が関わった内容にこそ ハーネスに渡せていない 固有の判断基準 がある How｜どう扱うか  ‧その学びを⾔語化させ、AIが認識可能な状態にする。（※claude.md、rulesや、またhooksなど⼿段は⾊々） → 学ぶのは「AIがまだ気づけない判断基準」。 ── 学びの⽅の具体の例を次へ © Findy Inc. 13 What｜学ぶ中⾝  ‧AIがまだ気づけてない「知識」や「判断基準」... 例えば、以下のようなもの ‧正しいコード作法‧規約、コードの実装順序、コードにないドメイン知識
15. ①学ぶ どう学ぶ、 ⼈の⾏動を学習する例 => ⼈の指摘をruleに還元する 1 抽出 マージされたPRを対象にする。 （マージ直後でも定期でも可） › 2 分類 AI‧⼈それぞれの 有効/無効な指摘を区別 › 3 策定 AIが逃した⼈の有効な指摘から ルールを策定する › 4 反映 検証(※)して、PRを出す。 有効なルールを反映する 反映後から、同様の指摘を AI ができるようになる ※ 検証（A/B simulation）  ‧マージされたPRは正解のコード。それを導くための不⾜ruleを追加するが、肥⼤化するとAIの判断が難しくなるので無条件に追加しない。 ‧PRがマージされた状況を再現し策定したルールを盛り込んだ状態で再度レビューさせる → ⼈が⾏った指摘が出てくれば「有効」とみなす。 → ⼈の有効な指摘をAI が気づけるルールに変えてコミット、AIレビュー能⼒向上した ── では、その効果をどう測る？ © Findy Inc. 14
16. 何を‧どのように学ぶ？ ── AIのレビュー能⼒を上げるための継続的学習について、4ステップを解説 ① 学ぶ ハーネスが持ってない知識や判断基準を⾒つけ、AIが気づける状態にする ② 測る ⽬的（レビュー負荷↓）に紐づく指標で効果を確認する ③ 配る 学ぶ仕組みを全リポジトリへ（GitHub Actions の共通化） ④ 磨く 各リポジトリの伸び‧つまずきを⾒て、再現性あるものを全体へ循環させる © Findy Inc. 15
17. ②測る どう測る、 学びの効果の測定⽅法 指標はゴールに紐づけて継続して観測可能 とする。これが無いと効果を計れず、学習のための学習に陥る（勉強した⾃⼰満⾜） CI上で測れるものは⾊々ある（候補）：コードの内容∕⼈のレビュー量∕指摘数∕指摘の有効数 ‧無効数∕各種リードタイム∕コスト∕カバレッジ etc... ハーネス整備の効果を確認する上で指標は⼀つではないが、「今回AIレビュー能⼒を上げる」のゴールの本質が 「⼈のレビュー負荷を下げる」 であるなら以下２つをみるのが良い 👀 1. ⼈のレビュー負荷を減らす 指標：⼈のレビュー指摘数が減る 2. AIの適切なレビュー指摘が増えている 指標：AIレビュー指摘が採⽤されている%が⾼い → 学びの効果を可視化する。 ── 実際のサンプルを記載 © Findy Inc. 16
18. 計測のダッシュボードサンプル — 直近30⽇（匿名リポA の実例） ruleの整備と紐づいてAIの有効指摘が上がり、人のレビュー指摘が減った。また、その状態が継続して維持できているのがわかる。 © Findy Inc. 17
19. 計測のダッシュボードサンプル — 直近30⽇（匿名リポA の実例） ruleの整備と紐づいてAIの有効指摘が上がり、人のレビュー指摘が減った。また、その状態が継続して維持できているのがわかる。 © Findy Inc. 17
20. 計測のダッシュボードサンプル — 直近30⽇（匿名リポA の実例） ruleの整備と紐づいてAIの有効指摘が上がり、人のレビュー指摘が減った。また、その状態が継続して維持できているのがわかる。 © Findy Inc. 17 ※ 各数値については後から取得可能な項⽬も多いが、マージされたタイミングでアーティファクトに保存すると後から取得が容易になる（GitHub Actions のワークフローにおいてジョブの実⾏によっ て⽣成される内容を保存し再利⽤するための機能。ビルドの成果物やテスト結果、 AIの実⾏ログなど様々な情報を保存することが出来る）
21. 何を‧どのように学ぶ？ ── AIのレビュー能⼒を上げるための継続的学習について、4ステップを解説 ① 学ぶ ハーネスが持ってない知識や判断基準を⾒つけ、AIが気づける状態にする ② 測る ⽬的（レビュー負荷↓）に紐づく指標で効果を確認する ③ 配る 学ぶ仕組みを全リポジトリへ（GitHub Actions の共通化） ④ 磨く 各リポジトリの伸び‧つまずきを⾒て、再現性あるものを全体へ循環させる © Findy Inc. 18
22. ③配る どう配る、 CLの各リポジトリ展開と保守の負担を下げる仕組み 仕組みの展開と保守は⼿間がかかる。 Composite Action / Reusable Workflow（GitHub Actions）で効率よく届ける 展開：使ってもらう 各リポジトリに設定をコピペ → 書式がズレる‧腐る → ワークフローに uses で機能を取り込む 共通リポジトリの実装を参照して呼ぶ 保守：修正を取り込んでもらう 直すたびに全リポジトリへ配り直す → 更新は Dependabot が⾃動でPRを作成 共通リポジトリを直せば全体に効く ※ Composite Action＝複数ステップを束ねた部品 ∕ Reusable Workflow＝ジョブ群ごと再利⽤。 → 使ってもらう、直して反映の負担を下げる ── 導⼊時の設定サンプルを次に記載 © Findy Inc. 19
23. どう配る、 利⽤するリポジトリに、数⾏の追加で CLを波及出来る ① 既存ワークフローを⾜し、有効機能をtrueに設定する jobs: claude-pr: uses: Findy/ci-cd-cl/...@<SHA> with: execute_review: true execute_pr_summary: true execute_pr_learning_on_merge: true secrets: anthropic_api_key: ${{ secrets... }} → ② そのリポジトリに有効機能にした機能が⼀式で乗る CI AIレビュー CI PR要約 CL 学び（rule化） CL 効果の計測 ③ 共通リポの改善が、全リポジトリへ⾃動波及 Repo A Repo B Repo C … 全体 更新も Dependabot で⾃動。 リリースを検知 → 各リポへ更新PR、利⽤側は確認だけ。 → 数⾏で展開でき、更新も⾃動。── （CIやCLのサンプル機能を次ページへ） © Findy Inc. 20 ③配る
24. 実際の機能サンプルの利⽤イメージ © Findy Inc. 21 CL 計測 CL 学び
25. 実際の機能サンプルの利⽤イメージ CI AIレビュー © Findy Inc. 21 CI PR要約
26. 何を‧どのように学ぶ？ ── AIのレビュー能⼒を上げるための継続的学習について、4ステップを解説 ① 学ぶ ハーネスが持ってない知識や判断基準を⾒つけ、AIが気づける状態にする ② 測る ⽬的（レビュー負荷↓）に紐づく指標で効果を確認する ③ 配る 学ぶ仕組みを全リポジトリへ（GitHub Actions の共通化） ④ 磨く 各リポジトリの伸び‧つまずきを⾒て、再現性あるものを全体へ循環させる © Findy Inc. 22
27. 最後に、 配る → それを観測して共通基盤を磨く💪 ④ 磨く 共通基盤 各リポジトリの改善状況を⾒て、 再現性ある機能や修正を追加‧検証‧更新。 伸び‧つまずき‧⼯夫を、全体へ循環させる。 ①配る → ← 観測 （循環） 各リポジトリ 配られた仕組みで回し続ける ② 学ぶ‧改善 ⼈の指摘から、ルール（判断基準）を育てる ③ 測る ⽬的に紐づく指標で、効果を確認する ↻ この「学ぶ → 測る」を、各リポジトリが回し続ける ⼀つのリポジトリの伸び‧つまずき‧⼯夫を学べる。それを、共通基盤が再現性ある形にして全体へ循環させる。 © Findy Inc. 23 ④磨く
28. ④磨く 例として、 現場のニーズを拾い、共通基盤の機能として横展開する 各リポジトリで出た「こうしたい」を、再現性ある機能にして全体へ配り直す。（以下はCI/CD＋CLに関わる改善群） 「特定の条件だとうまく動かない」 → (CL改善) 基本機能そのものを修正 「rule が膨張する。制約を設けたい」 → (CLI改善) rules の lint を導⼊ 「コードの把握が⼤変。要約がほしい」 → (CLに通ずるCI改善) PR要約機能を追加 「Sentry のトリアージ‧調査を助けたい」 → (CLに通ずるCI) 調査（トリアージ）機能を追加 「単体PRでなく複数PRから学ばせたい」 → (CL改善) 週次の学習機能を追加 → ⼀つの現場の困りごとが、全部で使える機能になる ☺ © Findy Inc. 25
29. まとめ 整備して終わりにしないために、継続的に数字で観測し、 改善を続ける仕組みを考え、ハーネス負債 を⽣み出さない取り組みが⼤切。 まずは可視化、そして改善の循環を整える。 最後に整えてからどれぐらい時間が経っているか確認して、学びを⽌めない仕組みや⽂化を育てていきましょう💪 © Findy Inc. 24
30. 最後に、 ひとつだけ宣伝させてください © Findy Inc. 1
31. 本⽇は 「共通基盤領域」に設けた仕組みについてでしたが 個⼈‧ツール領域 例 Claude Code / Codex / Cursor / モデル / 個⼈設定 / ローカルSkills 向き合い⽅：新しい仕組みや機能を素早くキャッチして、取り込む（アンテナ⾼く） リポジトリ領域 例 CLAUDE.md / .claude/rules / 設計原則 / ドメイン知識 向き合い⽅：このドメインに最適化した判断基準を、深く磨き込む 共通基盤領域 例 CI / AIレビュー / 観測 / 学習候補抽出 / 安全装置 向き合い⽅：汎⽤的で再現性⾼く‧計測可能な仕組みを、丁寧に整備する 今⽇ここ © Findy Inc. 9
32. 個⼈‧ツール領域も活発ですよね（というか激動） 個⼈‧ツール領域 例 Claude Code / Codex / Cursor / モデル / 個⼈設定 / ローカルSkills 向き合い⽅：新しい仕組みや機能を素早くキャッチして、取り込む（アンテナ⾼く） リポジトリ領域 例 CLAUDE.md / .claude/rules / 設計原則 / ドメイン知識 向き合い⽅：このドメインに最適化した判断基準を、深く磨き込む 共通基盤領域 例 CI / AIレビュー / 観測 / 学習候補抽出 / 安全装置 向き合い⽅：汎⽤的で再現性⾼く‧計測可能な仕組みを、丁寧に整備する © Findy Inc. 9 今⽇ここ プロンプトエンジニアリングが時代遅れと⾔われ、fableが爆誕が3⽇後に追悼式となったり、エディタもzed etc ...
33. そんな悩みに、Findy AI＋ あります 弊社内⽥より、少し後のお時間で簡単に紹介もあるので是⾮聴いてください！！ © Findy Inc. 1 整備の悩み：モデルの変化に伴って変えていくことが求められるが、（課題）対応するの⼤変 活⽤の悩み：頑張って整備をしても、（課題）使われなかったら意味がない、、