Git 研修【MIXI 26新卒技術研修】#2

本スライドは、MIXIの2026年度新卒向け技術研修で使用された資料です。
　
MIXI 2026新卒技術研修
『Git 研修』
　
───────────────────────────────
※皆様へのお願い※ 資料・動画・リポジトリのご利用について
───────────────────────────────
公開している資料や動画は、是非、勉強会や社内の研修などにご自由にお使いいただければと思いますが、以下のような場でのご利用はご遠慮ください。
- 受講者から参加費や授業料など金銭を集めるような場での利用
（会場費や飲食費など勉強会の運営に必要な実費を集める場合は問題ありません）
- 出典を削除または改変しての利用

Transcript

1. MIXI 26新卒技術研修 チーム開発とGitでAI活⽤ ©MIXI
2. 講師紹介 太⽥ 理⽃ おおた りと 2024年度新卒⼊社 デジタルエンターテインメントオペレーションズ本部 モンスト開発部 クライアント2グループ 業務: C++、Unity、モンストアウトゲーム開発 など 趣味: ダーツ、エンタメ全般 得意なこと: 漫画のセリフクイズ、ご飯沢⼭⾷べる 苦⼿なこと: ⾷欲の我慢 好きなGitコマンド: git ©MIXI commit --amend 22
3. 本講義について ⽬次 • Git / GitHubを⽤いたチーム開発のノウハウ • GitでAI活⽤ ©MIXI 3
4. Git / GitHubを用いたチーム開発のノウハウ ©MIXI
5. Q. そもそもなぜ Git が⽣まれたのか ©MIXI
6. Q. そもそもなぜ Git が⽣まれたのか A. Linuxを開発するため ©MIXI
7. Git 誕生秘話 1991〜2002年 Linux はメーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料の VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux はフリーソフトなのに 非フリーソフトの BitKeeper を 利用してよいのでしょうか。」 みんな 「...」 Linux のパパ Linus Torvalds 氏 「BitKeeper の使用に反対意見が あるなら代わりの VCS を教えて ください。」 他にも 色々あったよ 詳しくは Git 略史で 調べてね 2005年 大人の事情で色々あって「 BitKeeper」が有料化されてしまった Linux のパパ Linus Torvalds 氏 「他の VCS 探さないといけません。 でも BitKeeper しか Linux を扱えません。 もう VCS 自作します！」 2005年〜現在 ©MIXI Linux と Git のパパ Linus Torvalds 氏 「2週間でできました！」 Git 「Linux 並に大きなソフトウェアを 大人数で開発するために生まれました」 Git は多くのプロジェクトで使用されている 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 7
8. Git 誕生秘話 1991〜2002年 Linux はメーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料の VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux はフリーソフトなのに 非フリーソフトの BitKeeper を 利用してよいのでしょうか。」 みんな 「...」 Linux のパパ Linus Torvalds 氏 「BitKeeper の使用に反対意見が あるなら代わりの VCS を教えて ください。」 他にも 色々あったよ 詳しくは Git 略史で 調べてね 2005年 大人の事情で色々あって「 BitKeeper」が有料化されてしまった Linux のパパ Linus Torvalds 氏 「他の VCS 探さないといけません。 でも BitKeeper しか Linux を扱えません。 もう VCS 自作します！」 2005年〜現在 ©MIXI Linux と Git のパパ Linus Torvalds 氏 「2週間でできました！」 Git 「Linux 並に大きなソフトウェアを 大人数で開発するために生まれました」 Git は多くのプロジェクトで使用されている 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 8
9. Git 誕生秘話 1991〜2002年 Linux はメーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料の VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux はフリーソフトなのに 非フリーソフトの BitKeeper を 利用してよいのでしょうか。」 みんな 「...」 Linux のパパ Linus Torvalds 氏 「BitKeeper の使用に反対意見が あるなら代わりの VCS を教えて ください。」 他にも 色々あったよ 詳しくは Git 略史で 調べてね 2005年 大人の事情で色々あって「 BitKeeper」が有料化されてしまった Linux のパパ Linus Torvalds 氏 「他の VCS 探さないといけません。 でも BitKeeper しか Linux を扱えません。 もう VCS 自作します！」 2005年〜現在 ©MIXI Linux と Git のパパ Linus Torvalds 氏 「2週間でできました！」 Git 「Linux 並に大きなソフトウェアを 大人数で開発するために生まれました」 Git は多くのプロジェクトで使用されている 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 9
10. Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • • • ©MIXI 高速な merge と checkout 分散型 branch 10
11. Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • • • 高速な merge と checkout 分散型 branch Git の merge と checkout はかなり高速 特に「履歴の遠さ」は merge や checkout の時間に影響を与えない ※ 「Git の内部構造」で詳しく話しています ©MIXI 11
12. Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • • • 分散バージョン管理システム (分散型) リポジトリの全履歴を含めた 完全なコピーをローカルに持つ 高速な merge と checkout 分散型 branch ローカル・バージョン管理システム ローカルのみのシンプルな VCS Local Computer File Version Database Server 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Computer A File Computer B Central VCS Server Version Database File メリット： 単純で理解しやすく個人開発に適している デメリット： チーム開発に適してない メリット： チーム作業の管理と共有がしやすい デメリット： 単一障害点になる＆変更の競合が起きうる Clone 同期 Version Database Clone 同期 Computer A Computer B File File Version Database Version Database メリット： 障害に強い＆柔軟なチーム開発ができる デメリット： 運用次第で非効率なチーム開発になる 参考：バージョン管理に関して ©MIXI 12
13. Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • • • 分散バージョン管理システム (分散型) リポジトリの全履歴を含めた 完全なコピーをローカルに持つ 高速な merge と checkout 分散型 branch ローカル・バージョン管理システム ローカルのみのシンプルな VCS Local Computer File Version Database Server 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Computer A File Computer B Central VCS Server Version Database File メリット： 単純で理解しやすく個人開発に適している デメリット： チーム開発に適してない メリット： チーム作業の管理と共有がしやすい デメリット： 単一障害点になる＆変更の競合が起きうる Clone 同期 Version Database Clone 同期 Computer A Computer B File File Version Database Version Database メリット： 障害に強い＆柔軟なチーム開発ができる デメリット： 運用次第で非効率なチーム開発になる 参考：バージョン管理に関して ©MIXI 13
14. Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • • • 分散バージョン管理システム (分散型) リポジトリの全履歴を含めた 完全なコピーをローカルに持つ 高速な merge と checkout 分散型 branch ローカル・バージョン管理システム ローカルのみのシンプルな VCS Local Computer File Version Database Server 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Computer A File Computer B Central VCS Server Version Database File メリット： 単純で理解しやすく個人開発に適している デメリット： チーム開発に適してない メリット： チーム作業の管理と共有がしやすい デメリット： 単一障害点になる＆変更の競合が起きうる Clone 同期 Version Database Clone 同期 Computer A Computer B File File Version Database Version Database メリット： 障害に強い＆柔軟なチーム開発ができる デメリット： 運用次第で非効率なチーム開発になる 参考：バージョン管理に関して ©MIXI 14
15. Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • • • 高速な merge と checkout 分散型 branch branch 機能のおかげで大人数で並行して開発を進めることができる ※ Basic Git 研修「ブランチの使用」「Git の内部構造」で詳しく話しています しかし、無秩序な branch 運用には問題点がある • 様々な branch でコンフリクトが発生してしまう ◦ 複雑なコンフリクトの解消に失敗してバグが混入する可能性がある • どの branch にどの機能が実装されているのかわからない ◦ 最新版がどれかわからなくなってしまう 大規模なチーム開発を効率的に行うために、 branch 運用には いくつかの方法論がある！ 1番有名なのが 『Git Flow』 ©MIXI 15
16. Git の特徴 Git は大きなソフトウェアを大人数で開発するためにある Git 以前の VCS に比べて Git には次の特徴がある • • • 高速な merge と checkout 分散型 branch branch 機能のおかげで大人数で並行して開発を進めることができる ※ Basic Git 研修「ブランチの使用」「Git の内部構造」で詳しく話しています しかし、無秩序な branch 運用には問題点がある • 様々な branch でコンフリクトが発生してしまう ◦ 複雑なコンフリクトの解消に失敗してバグが混入する可能性がある • どの branch にどの機能が実装されているのかわからない ◦ 最新版がどれかわからなくなってしまう 大規模なチーム開発を効率的に行うために、 branch 運用には いくつかの方法論がある！ 1番有名なのが 『Git Flow』 ©MIXI 16
17. Git Flow とは ブランチ戦略の一つ。分散型だが、集中型。 feature develop release hotfix main → 集中型の「管理のしやすさ」を分散型に導入 → チームでリモートリポジトリ(GitHub, BitBucket, GitLab, etc…)を1つに決めて常にそれを正とみなす → メイン branch： main, develop (無期限) → サポート branch：feature, release, hotfix (有期限) ©MIXI 参考：A successful Git branching model 17
18. Git Flow とは ブランチ戦略の一つ。分散型だが、集中型。 feature develop release hotfix main → 集中型の「管理のしやすさ」を分散型に導入 → チームでリモートリポジトリ(GitHub, BitBucket, GitLab, etc…)を1つに決めて常にそれを正とみなす → メイン branch： main, develop (無期限) → サポート branch：feature, release, hotfix (有期限) 余談：複数リモートリポジトリ状態もあるよ 例1 GitHub ができる前から Git 使っている OSS は 自前の Git サーバと GitHub を両方使っていたり する(git log 残すためとか) 例2 fork したリポジトリを、fork 元のリポジトリに 追従したい時に複数リポジトリを扱う場合がある 例3 もう片方はバックアップ用 ©MIXI 参考：A successful Git branching model 18
19. Git Flow： main と develop main と develop は無限のライフタイムを 持つメイン branch。 • • ©MIXI feature develop release hotfix main develop ◦ 基本的にこの branch で開発する。 main ◦ develop branch が安定してリリースする準備が できたら全ての変更を main ブランチに merge する ◦ 変更が main に merge されるたびに新しい リリース tag を打つ ◦ main の先頭が常にプロダクトの最新のリリース になる 参考：A successful Git branching model 19
20. Git Flow：feature feature は複数人で develop を開発するため のサポート branch。 • • • ©MIXI feature develop release hotfix main 1機能＝1 feature で develop から branch を切る ◦ 複数機能＝1 feature はデメリットが多い ▪ どの機能がどの branch にあるか把握し ずらい ▪ 差分が大きくなってコンフリクトしやすい ▪ 機能単位で revert しずらい ◦ 大きい機能開発の場合は feature からさらに feature を切る 機能の開発が終われば develop に merge する 機能の開発がうまくいかなければ破棄する ◦ 実験・実証は feature で実施する 参考：A successful Git branching model 20
21. Git Flow：release release は develop から main へ merge する 「準備」のためのサポート branch。 • • • • • ©MIXI feature develop release hotfix main release は develop から branch を切る 安定した release は develop と main に merge する チームによっては staging と呼ぶかも 具体的な「準備」の内容はプロジェクトによる ◦ 新規実装を凍結して bugfix のみに使う ◦ version 表記やタイムスタンプを更新する release で新規機能を追加しないようにする (新規機能追加は develop から切った feature で！) 参考：A successful Git branching model 21
22. Git Flow：hotfix hotfix は本番環境で発生したバグの内、 緊急性の高いものを即座に対処するための サポート branch。 • • • ©MIXI feature develop release hotfix main hotfix は main から branch を切る ◦ develop 以外で唯一 main から切られる branch 安定した hotfix は develop と main に merge する hotfix から main を更新した場合は、patch バージョンをあ げることが多い ◦ 1.2 → 1.3 ではなく、1.2 → 1.2.1 参考：A successful Git branching model 22
23. Git Flow：まとめ Git Flow は長期的な開発サイクルと厳密な ルールを持つ。全体像は右図。 feature develop release hotfix main 大体のチームでは Git Flow をそのままではなく ちょっとアレンジして使っている。 組織やリポジトリの特性などから適したものを 選びましょう。 ©MIXI 参考：A successful Git branching model 23
24. Git Flow：カスタム例 Git Flow は長期的な開発サイクルと厳密な ルールを持つ。全体像は右図。 feature develop release hotfix main 大体のチームでは Git Flow をそのままではなく ちょっとアレンジして使っている。 組織やリポジトリの特性などから適したものを 選びましょう。 ©MIXI 参考：A successful Git branching model 24
25. GitHub の機能について ©MIXI
26. GitHub の機能 GitHub は Git をチームで使うにあたって便利な機能がいっぱいある 基本的な機能はリポジトリのトップページのタブでまとめられている ©MIXI 26
27. GitHub の機能 ① Project Management でプロジェクト・タスク管理をしつつ、 ② Collaborative coding で開発し、 ③ CI/CD and DevOps で開発工程を自動化＆開発と運用を円滑に回す ④ その他 ©MIXI 参考：GitHub Docs 27
28. 開発で大活躍する GitHub 機能 ① Project management 目的：作業の計画、アイデア、フィードバック、タスク、バグ、過程を追跡する ©MIXI 28
29. 開発で大活躍する GitHub 機能 ① Project management 目的：作業の計画、アイデア、フィードバック、タスク、バグ、過程を追跡する ©MIXI 29
30. 開発で大活躍する GitHub 機能 ① Project management Issueにはsub-issueを紐づけることも可能です ©MIXI 30
31. 開発で大活躍する GitHub 機能 ① Project management sub-issueはタスクリストのような使い方や、 issueの細分化などの用途で使えます ©MIXI 31
32. 開発で大活躍する GitHub 機能 ① Project management issueからbranchを作成したり、 branchを紐づけることも可能です ©MIXI 32
33. 開発で大活躍する GitHub 機能 ① Project management 目的：作業の計画、アイデア、フィードバック、タスク、バグ、過程を追跡する Projects アジャイルやスクラム開発でよく使うタスク管理ツール • 作業の進捗状況を可視化 • 優先度やマイルストーン、ストーリーポイントを管理 様々なレイアウトがある • Team Planning • Feature release • Kanban • Bug tracker • Iterative development • Product launch • Roadmap • Team retrospective ©MIXI 画像引用：GitHub Issues/Projects/ビューのカスタマイズ 33
34. 開発で大活躍する GitHub 機能 ② Collaborative coding 目的：変更が merge される前のレビューとフォローアップをする Q. なぜ「Merge Request」ではなく「 Pull Requests」？ ©MIXI 34
35. 開発で大活躍する GitHub 機能 ② Collaborative coding 目的：変更が merge される前のレビューとフォローアップをする Q. なぜ「Merge Request」ではなく「 Pull Requests」？ A. Linux 開発の名残。 特定の branch や fork 元のリポジトリに「私の作業を取り込んでください」と依頼 できる機能だから。「 Pull = 取り込み」 Linux 開発で、Linus のもつメインのリポジトリに自分の作業内容を取り入れてほしいとき 「このブランチにあるものを取り込んでください」とお願いしていたことが由来。 ※ git request-pull というコマンドもあるくらい Developer Linux の開発者 「私の作業を Linus 氏の メインリポジトリに 取り込んでください。」 ©MIXI Pull Request コードレビュー Reviewer Linux と Git のパパ Linus Torvalds 氏 「承知しました。レビューします。」 レビュー結果OK：「OKなので取り込みます。」 レビュー結果NG：「ここを直して欲しいです。」 35
36. 開発で大活躍する GitHub 機能 ③ CI/CD and DevOps 目的：リポジトリ内でイベントが発生した時のワークフローを実行する GitHub Actions とは GitHub が提供している、ビルド、テスト、デプロイのパイプライン自動化のための 継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォーム Actions を使うメリットたくさん！ • • • • ©MIXI GitHub 上にあるコードをそのまま使用し、他のサービスと連携させる必要がなく簡単に導入し使用できる エコシステムが充実している パブリックリポジトリは無料で使用できる Hook したいイベントとワークフローを書いたyaml を .github/workflows/ に配置すると 勝手に走ってくれる ◦ GitHub で公開されている actions/starter-workflows にたくさんの yaml 例がある 36
37. 開発で大活躍する GitHub 機能 ④ その他 • Security ◦ ◦ ◦ ◦ • Insights ◦ • リポジトリの活発度を様々な指標で確認できる ▪ 時系列で commit 数や差分の量がグラフ化されている ▪ メンテ具合がわかりやすい（新しいライブラリやツールの導入検討に便利） Settings ◦ ©MIXI Security policy … 脆弱性報告の手順をユーザーに示す Security advisories … 非公開で脆弱性について議論・対策し、解決後は公開できる Dependabot alerts … 脆弱性のある依存関係を使用していれば検出しアラートを飛ばす Code scanning alerts … コードをスキャンして隠された脆弱性を検出する リポジトリの設定を変える ▪ デフォルト branch の変更、merge に関するルール設定、etc… ▪ (重要) Branch protection rules (直 push 禁止や force push 禁止) ▪ (注意) private → public の変更、オーナー権限の委譲、リポジトリの削除 37
38. 他の開発手法 他にもチーム開発を効率的に行うために、シンプルな運用で理解がしやすく、 頻繁にデプロイを行う手法もある。 • • ©MIXI GitHub Flow 軽量のブランチベースのワークフロー トランクベース開発 細かく頻繁にリリースする開発手法 etc… 38
39. 10分休憩 ©MIXI
40. GitでAI活用 ©MIXI
41. 目次 • git worktree×AI を活⽤した並⾏開発 • ©MIXI CodeReview×AI を活⽤した品質管理 41
42. git worktree×AI を活⽤した並⾏開発 ©MIXI
43. git worktree とは 1つのリポジトリから複数の作業ディレクトリを同時 に使える仕組みです。 ©MIXI 43
44. git worktree とは ざっくりイメージ 通常のGit： • • 1リポジトリ = 1作業ディレクトリ ブランチ切り替えすると、作業中の内容も切り替わる git worktree： • • ©MIXI 1リポジトリ = 複数の作業ディレクトリ それぞれ別のブランチを同時に開ける 44
45. git worktree とは 何が嬉しいか 例えば • main で作業中に、急ぎで hotfix を触りたい → checkoutすると作業が汚れる or stashが必要 worktreeならhotfixを同時に開ける • • ©MIXI ディレクトリA：main ディレクトリB：hotfix 45
46. git worktree とは よくある使いどころ • • • 複数ブランチを並行で作業 レビュー用に別ブランチを開く ビルドや検証を別ディレクトリで回す 基本コマンド git worktree add ../hotfix-branch hotfix これで • • ©MIXI ../hotfix-branch に新しい作業ディレクトリができる hotfix ブランチにチェックアウトされる 46
47. git worktree とは ポイント • • • ©MIXI .git は共有される（軽い） ブランチは「同時に 1つのworktreeでしかチェックアウトできない」 ◦ repo / ディレクトリA → main ◦ repo / デイレクトリB → main← ❌ 削除も簡単 ◦ git worktree remove ../hotfix-branch 参照: git-worktree Documentation 47
48. AI活⽤の説明ですが、 今回はClaude Code CLI を使⽤する前提で話をします。 ©MIXI
49. git worktree × AI # feature-ABC という名前の worktree で Claude を開始する # 新しいブランチで .claude/worktrees/feature-ABC/ を作成する claude --worktree feature-ABC # 別の worktree で別のセッションを開始する claude --worktree hotfix-ABC # ランダムな名前で worktree を⾃動⽣成する claude --worktree # セッション中に Claude に「work in a worktree」または「 start a worktree」 を依頼することで自動開始もできる 複数のタスクに同時に取り組む場合、各 Claude セッションがコードベースの独自のコピーを 持つ必要があります。そうしないと変更が衝突します。 worktreeを使用することで、 Claude が 1 つの worktree で機能に取り組んでいる間に、 別の worktree でバグを修正でき、どちらのセッションも相互に干渉しません。 ©MIXI 参照: code.claude.com/docs/ja/common-workflows 49
50. CodeReview × AI を活⽤した品質管理 ©MIXI
51. CodeReview × AI レビューに AIを活用していきましょう！ 例えば以下のような観点でレビューをしたいとします。 プロンプト： この実装が仕様を満たしているか確認して プロンプト： この変更が影響しそうな箇所を洗い出して プロンプト： このコードに対して不足しているテストケースを挙げて ©MIXI 51
52. CodeReview × AI Claude Code Skillsを作成する # .claude/skills/code-reviewer/SKILL.md --name: code-reviewer description: コードレビュースキル --# レビュー観点 - この実装が仕様を満たしているか - この変更が影響しそうな箇所を洗い出し - このコードに対して不⾜しているテストケースを挙げる ## 概要 これらの観点でレビューを⾏ったあと、点数をつける ©MIXI 参照: code.claude.com/docs/ja/skills 52
53. CodeReview × AI CLAUDE.mdを作成する # CLAUDE.md - コードレビュー、提案、説明、ドキュメント作成は全て⽇本語で⾏う - コードコメントは⽇本語で記述する - 技術的な議論や問題分析は⽇本語で実施する のようにプロジェクト固有のドキュメントを作成しましょう。 ©MIXI 参照: code.claude.com/docs/ja/memory 53
54. CodeReview × AI 作成した Skillsを使用すると複数の観点で レビュー依頼を一度で出せます。 プロンプト： /code-reviewer 実行結果： SkillsとCLAUDE.mdを読み解いて、レビューを返してくれる ©MIXI 参照: code.claude.com/docs/ja/skills 54
55. CodeReview × AI Claude Code Actionを設定し、 GitHub上で自動レビューをする # .github/workflows/claude-review.yml name: Claude PR Review on: pull_request: types: [opened, synchronize, reopened] permissions: contents: read pull-requests: write issues: write jobs: review: runs-on: ubuntu-latest timeout-minutes: 20 steps: - name: Run Claude review skill uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} prompt: | /review-spec-impact-test Review the current pull request. Analyze the diff and surrounding code. Post the review in Japanese as PR comments or a review summary. claude_args: | --max-turns 6 --model claude-sonnet-4-6 ©MIXI 参照: code.claude.com/docs/en/hooks-guide 55
56. CodeReview × AI Claude Code Actionを設定し、 自動でリポジトリ固有の情報を更新する # CLAUDE.md # レビュー観点 - この実装が仕様を満たしているか - この変更が影響しそうな箇所を洗い出し - このコードに対して不⾜しているテストケースを挙げる … 以下のようなレビューコメントがついたとき private な変数には_ （アンダースコアプレフィックス）をつけてほしいです ©MIXI 参照: code.claude.com/docs/en/hooks-guide 56
57. CodeReview × AI Claude Code Actionを設定し、 自動でリポジトリ固有の情報を更新する # CLAUDE.md # レビュー観点 - この実装が仕様を満たしているか - この変更が影響しそうな箇所を洗い出し - このコードに対して不⾜しているテストケースを挙げる - private な変数には_ （アンダースコアプレフィックス）をつけていること PRがマージされたタイミングを hookし、 CLAUDE.mdを更新しレビュー情報を蓄積させましょう。 参考：ClaudeによるコードレビューをAgent Skillsで育てる（DocBase : mixi2チーム） ©MIXI 参照: code.claude.com/docs/en/hooks-guide 57
58. まとめ AI活用の加速により、エンジニアとして、 コードを読むスキル がより必要になっています。 また、今回の講義では活用法をいくつか紹介しましたが、 AIに操作させていい gitコマンドは人間が適切に設定する 必要があります。 例：Claude Code Permissions 是非自チームの AI環境を整えてください！ ©MIXI 参照: code.claude.com/docs/en/permissions 58
59. ©MIXI