過去のレビュー知見をSkillsで資産化した話

Transcript

1. 1 © PKSHA Technology Inc. 1 © PKSHA Technology Inc. 開発者のためのClaude Code Skills お悩み解消会 過去のレビュー知⾒をSkillsで 資産化した話 株式会社PKSHA Technology AIバックオフィス開発部 AIコワーカー開発グループ Senior Software Engineer 伊礼 恭⼠ 2026年05⽉12⽇
2. 2 © PKSHA Technology Inc. 伊礼 恭⼠(いれい やすし) @irys33 (株)PKSHA Technology AI Knowledge & Communication カンパニー Senior Software Engineer • ⾼専専攻科を卒業後、⼤⼿通信キャリアに⼊社。AIエンジニ アとして、機械学習モデルの開発からプロダクト開発まで幅 広く経験。2024年8⽉にPKSHAへ⼊社。現在、⾃社AI SaaS 「PKSHA AI ヘルプデスク」におけるドキュメント管理‧RAG 基盤「KnowledgeBase」開発チームのリーダーを担当しつ つ、新規プロダクトの「PKSHA AI コワーカー」の開発を担 当。 PROFILE
3. 3 © PKSHA Technology Inc. 01 / PROBLEM AI コーディング時代の「レビュー律速」 Codex / Claude Code / Devin の普及で コード⽣成量は急増。⼀⽅、レビューは依然として⼈間ベース。 結果：PR量が増加した結果、レビューが開発のボトルネックに 観点のバラつき レビュアーごとに指摘の粒度‧観点が異な る 知⾒の埋没 過去PRに有⽤なコメントがあるが、検索 しづらい オンボの難しさ 新メンバーが「お作法」をキャッチアッ プしにくい
4. 4 © PKSHA Technology Inc. 02 / APPROACH 各リポジトリに「構造化レビューガイドライン」を置く REVIEW_POINTS.md # Principles # Severity # Scoping rules # Review areas # - Correctness # - Security # - Performance... # Appendix 01 ⼈間とAIの共通⾔語 ⼈はチームの「お作法」として、AIは指⽰書として同じMarkdownを 参照する 02 過去PRの資産化 属⼈化していたレビュー知⾒を、エビデンス付きの形式知に変換 03 継続的な差分更新 ⼀度作って終わりではなく、⽇々の知⾒でアップデートし続ける 注）プロンプトではなくMarkdownにした理由：バージョン管理できる / ⼈もAIも読める / リポジトリと⼀緒に育てられる
5. 5 © PKSHA Technology Inc. 03 / PIPELINE 5つの Skill でパイプラインを構成 GitHub API PR / Reviews PR コメント CSV pr-review-comments .md (ノイズ除去済み) REVIEW_POINTS .md ① pr-review-analyzer gh CLI で PR レビューコメントを収集 → CSV化 ② review-csv-guideline-extractor 100⾏チャンクでコンテキスト制約を回避しつつノイズ除去 ③ create-review-points テンプレ + コメントログ + コードベース構造から⽣成 継続運⽤ ④ update-review-points セッション中の知⾒で既存ガイドラインを差分更新 ⑤ review-review-points ガイドライン⾃体の品質をチェック
6. 6 © PKSHA Technology Inc. 04 / STRUCTURE ⽣成される REVIEW_POINTS.md の構造 過去PRから⽣成されるガイドラインは、8つのセクションで構成される 1 Principles レビューの基本⽅針 2 Review flow ドキュメントの使い⽅ 3 Severity Blocker / High / Medium / Low 4 Scoping rules 変更タイプごとの適⽤判定 5 Review areas 領域別のチェックリスト 6 Integration リポジトリ横断の影響 7 Comment format レビューコメントの書き⽅ 8 Appendix 過去PRから抽出した頻出問題 → 「5. Review areas」を次のスライドで掘り下げる
7. 7 © PKSHA Technology Inc. Review areas：並列レビューを可能にする領域分離 REVIEW_POINTS.md > 5. Review areas を展開すると… Review areas 1 Correctness 全変更 2 Security 認証 / 外部I/O 3 Performance ホットパス 4 Architecture 構造変更 5 Lang / FW ⾔語別 6 Tests テストコード 7 Operability 運⽤ / 監視 05 / DESIGN → 各領域に Scoping rule を持たせ、PR review bot が領域ごとに 並列で⾃動レビュー できる構造に
8. 8 © PKSHA Technology Inc. 06 / LESSON Skill は「育てる」前提：実⾏→観察→修正のループ 実例：review-csv-guideline-extractor BEFORE CSV全体を⼀括処理 → コメント数が多いリポジトリでコンテキスト⻑を超過 / 失敗 AFTER 100⾏チャンクで逐次処理 → Skillのワークフローにチャンク処理ステップを追加して解消 メタなプロセス 1 実⾏ Skillを呼んで動かす 2 失敗観察 どこで詰まったかを⾒る 3 Skill 修正 ワークフローを書き換える ↻ Skill は⼀度書いて終わりじゃない。 Commit して育てる「資産」
9. 9 © PKSHA Technology Inc. 07 / RETROSPECTIVE 複数リポジトリに展開してみて 良かった点 ✓ 参照ポイントの明確化 「何を⾒るべきか」がリポジトリごとに揃った ✓ オンボーディングが容易 新メンバーに固有の観点を伝えやすくなった ✓ エビデンスベースの納得感 PRコメント由来のため「根拠ある指摘」になる 限界 / 注意点 ! コメント量への依存 PR コメントが少ないリポジトリでは質が下がる ! 定期的な⾒直しが必要 コードベースの変化に追従する仕組みが要る ! ⽣成は出発点にすぎない チームでのレビュー‧調整は必須
10. 10 © PKSHA Technology Inc. TAKEAWAYS 持って帰ってほしいこと 01 属⼈化に困ったら、まず過去 PR を眺める ガイドラインの「種」は、すでにチームのレビューコメントの中にある 02 Skill は雑に始めて、育てる 1個⽬で型さえできれば、改善ループは Claude Code との対話で回せる 03 領域を切れば、並列レビューに繋がる 詳しくは Zenn 記事へ / @irys33 / PKSHA Technology ( https://zenn.dev/pksha/articles/430e08bbbd6faf ) 「⼈が読むドキュメント」と「PR review botへの指⽰」を同じMarkdownに同居させる
11. 11 © PKSHA Technology Inc.