Google Engineering Practices完全解説：GitHubで公開されたGoogleのコードレビュー指針を読み解く

2026年5月、Googleが社内エンジニアリング標準を公開した google/eng-practices リポジトリがX（旧Twitter）で広く注目を集めた。「GOOGLE OPENED THE VAULT（Googleが金庫を開けた）」という表現で拡散されたこの情報は、コードレビューの指針をGoogleがどのように体系化しているかを外部から初めて体系的に確認できる機会を提供している。

このドキュメントはGoogleの 全エンジニアに適用される 規範であり、単なる推奨事項ではない。2つのガイド——レビュアー向けとCL著者向け——が連携して、コードレビューのあり方を網羅的に定義している。

AI自動化ツールを活用した開発効率化の全体像は AI自動化ツール完全ガイド2026｜ノーコードからコードまで徹底比較 をご覧ください。

Google Engineering Practicesとは：なぜGoogleはコードレビュー指針をGitHubで公開したのか

google/eng-practices は、Googleのエンジニアリング・プラクティスに関するドキュメントを収録したGitHubリポジトリである。2019年に公開されてから継続的に更新されており、2026年時点でApache License 2.0のもとで誰でも参照・活用できる。

リポジトリに含まれるコンテンツは現在、主に「コードレビュー開発者ガイド（Code Review Developer Guide）」に集中している。このガイドは2つの独立した文書で構成される。

• レビュアーガイド（How to Do a Code Review）: コードを審査する側の行動規範
• CLオーサーガイド（The CL author’s guide）: コードを提出する側の行動規範

この2文書は独立して読めるが、互いを前提として設計されており、「全体として1つの完全なドキュメントを構成している」とリポジトリのREADMEに記されている。Googleは両方の視点を一貫させることで、コードレビューの摩擦を最小化している。

リポジトリの構造

google/eng-practices/
├── review/
│   ├── reviewer/          # レビュアーガイド
│   │   ├── index.md       # 概要
│   │   ├── standard.md    # コードレビューの基準
│   │   ├── looking-for.md # 何を見るか
│   │   ├── navigate.md    # CLの読み方
│   │   ├── speed.md       # スピード
│   │   ├── comments.md    # コメントの書き方
│   │   └── pushback.md    # 反論への対処
│   └── developer/         # CLオーサーガイド
│       ├── index.md       # 概要
│       ├── cl-descriptions.md  # CLの説明文
│       ├── small-cls.md        # 小さなCL
│       └── handling-comments.md # コメントへの対処
└── README.md

各ファイルは独立したトピックを扱いながら、全体として一貫した体系を形成している。

CLとLGTMを理解する：Googleが使う独自用語の体系

eng-practicesを読む前提として、Googleが使う特有の用語を理解しておく必要がある。

CL（Changelist）

CL（チェンジリスト） はGoogleの社内用語で、バージョン管理システムに対する「1つの自己完結した変更」を指す。GitHubユーザーには「Pull Request（PR）」と説明するとわかりやすい。ただし概念上、CLはPRよりも厳密に「完結した単位」であることが求められる。

Googleのガイドラインでは、1つのCLが「1つのことだけを行う」ことを理想としている。大きな変更は複数のCLに分割し、それぞれが独立してレビュー・マージできる状態が望ましい。

LGTM（Looks Good To Me）

LGTM はコードレビューの承認表現として世界中の開発者が使う略語だが、Googleではこれが正式な承認プロセスの一部として機能する。レビュアーがLGTMを付与することは、「このCLをコードベースにマージしてよい」という宣言であり、単なる曖昧な称賛ではない。

ガイドラインでは「残コメントがあってもLGTMを出せる」ケースも定義している。レビュアーが「著者がコメントを適切に処理する確信がある」場合、未解決のコメントが残った状態で承認を出すことも許容される。

コードヘルス（Code Health）

コードヘルス はeng-practicesの中心概念であり、「コードベースの長期的な健全性」を意味する。Googleの判断基準は常に「このCLはコードヘルスを向上させるか」に帰着する。一時的に完璧でなくても、総合的な健全性が改善するなら承認する——これがGoogleの根本原則だ。

コードレビューの黄金律：「コードヘルス向上」を判断基準にする理由

eng-practicesのレビュアーガイドの冒頭は、コードレビューの核心原則を1文で表現している。

“Reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.”

「コードヘルスを確実に向上させる状態になったら、たとえ完璧でなくてもCLを承認することをレビュアーは優先すべきだ」

この原則は一見シンプルだが、現場での適用は複雑な判断を要する。

完璧主義の罠を避ける

多くのレビュアーが陥る問題は「完璧なコードでないと承認できない」という思考パターンだ。しかしGoogleは明示的にこれを否定する。

ガイドラインは「完璧なコードというものは存在しない、あるのは『より良いコード』だけだ」と述べている。細部のポリッシュを要求するあまりに前進を阻害することは、チーム全体の生産性を損なう。

技術的事実はスタイルより優先される

設計や実装について意見の相違がある場合、Googleでは次の優先順位を適用する。

1. 技術的事実とデータ が最優先（ベンチマーク、仕様、既知のバグ）
2. スタイルガイドの定め が次に優先（スタイルガイドは絶対的権威）
3. エンジニアリング原則に基づく設計判断 が続く
4. 個人の好みや意見 は最低優先度

レビュアーが技術的根拠なしに「私のやり方が好きだ」と主張する権利はない。複数のアプローチが技術的に同等である場合、著者の選択を尊重することがガイドラインの方針だ。

レビュアーガイド全解説：7つの観点・ナビゲーション・スピードの原則

7つのレビュー観点

eng-practicesのレビュアーガイド「What to Look For In a Code Review」では、コードを審査する際に確認すべき7つの観点を定義している。

ガイドラインは「割り当てられたすべてのコード行をレビューすること」を明示的に求めている。変更差分だけでなく、変更箇所の文脈（前後のコード）も確認することが重要だ。

CLのナビゲーション：3段階アプローチ

大規模なCLを前に途方に暮れる経験は多くのレビュアーが持つ。eng-practicesは「どの順番でコードを読むか」という問題に対して明確な3段階を定める。

ステップ1：全体の変更を把握する

まずCLの説明文（description）を読み、変更の目的と範囲を理解する。ここで「この変更そのものが不適切」と判断した場合は、コードを詳しく読む前に礼儀正しくフィードバックを返す。部分的なコメントを大量に出した後で根本的な方向性を否定するのは、著者の時間を無駄にする。

ステップ2：主要ファイルを先に読む

論理的変更が最も多く含まれる「主要ファイル」を特定して先に読む。これにより、後から読む小さな変更の文脈が明確になる。もし主要ファイルを特定できないほどCLが大きい場合は、著者に分割を依頼することが推奨される。

ステップ3：残りのファイルを順次確認する

主要な設計上の問題がないことを確認した後で、コードレビューツールが提示する順番に沿って残りのファイルを確認する。テストファイルを実装より先に読むと、意図された機能が明確になるためレビュー効率が上がる。

コードレビューのスピード：なぜ「1営業日以内」なのか

多くのチームで「レビューが遅い」という不満が生じる。Googleのガイドラインはこの問題を組織的な観点から分析している。

個人の速度よりチームの速度を最適化する

コードレビューの速度に関してGoogleが最優先するのは、個々の開発者の作業速度ではなく「チーム全体がプロダクトを生み出す速度」だ。1人のレビュアーが邪魔されずに集中作業を維持することより、チーム全体のフロー（流れ）を維持することが重要とされる。

最大1営業日ルール

ガイドラインは「コードレビューリクエストへの返答は最大1営業日以内」という明確な上限を定めている。理想は受信後できるだけ早い返答だが、コンテキストスイッチのコストを考慮して「集中作業の自然な切れ目」に確認することを推奨している。

遅いレビューが引き起こす問題として、ガイドラインは3つを挙げる。

1. チーム生産性の低下 — 変更がマージされないことで後続の作業が滞る
2. 著者のフラストレーション増大 — 「レビューが厳しすぎる」という不満の実態は多くの場合「レビューが遅すぎる」問題
3. コード品質の低下 — 遅いレビューは手戻りを恐れた「質より速さ」への圧力を生む

反論（Pushback）への対処

「自分のコードを批判されること」に対して感情的な反応を示す著者は珍しくない。eng-practicesはこの状況に対する具体的な対処法を定めている。

著者に有効な主張があれば認める

レビュアーが間違いを犯す可能性は常にある。著者がコードに最も近い存在として、レビュアーが気づいていない制約やトレードオフを認識していることも多い。著者の反論がコードヘルスの観点から妥当であれば、素直に認めて次に進む。

「後で直す」の約束を信じない

著者が「次のCLで直します」と答えることはよくあるが、ガイドラインは「緊急事態でない限り、その場で修正を要求すること」を推奨している。研究によると、「後で直す」というクリーンアップは実際にはほとんど行われない。

CLオーサーガイド：レビューを通すための3つの技術

技術1：優れたCLの説明文を書く

CLの説明文（description）は恒久的な公開記録として機能する。将来の開発者がコードベースを検索する際に頼ることになる重要なドキュメントだ。

最初の1行が最も重要

CLの1行目は「簡潔・命令形・変更内容を正確に表す」完全な文でなければならない。この行はバージョン管理システムの履歴に単独で表示されるため、それだけで意味が伝わる必要がある。

# 悪い例（情報量が少なすぎる）
Fix bug
Fix build
Add patch
Moving code from A to B

# 良い例（変更と理由が明確）
rpc: remove size limit on RPC server message freelist
Introduce a common API for managing queue capacity limits
Refactor UserStore to use dependency injection for testability

本文はコンテキストを提供する

1行目の後、本文では「何を変えたか」より「なぜ変えたか」を説明する。解決する問題、選択したアプローチの理由、既知の制約をすべて記述する。バグ番号・ベンチマーク・設計ドキュメントへのリンクも有効だ。

技術2：CLを小さく保つ

google/eng-practices の中で最も具体的なアドバイスの1つが「小さなCL」に関する指針だ。

小さいCLが持つ5つの利点

1. レビュアーが「5分を複数回」確保しやすい（30分の連続時間より）
2. レビュアーがより丁寧に確認し、多くの問題を発見できる
3. 問題が見つかった場合の手戻りコストが小さい
4. ロールバックが容易（大きなCLはロールバック時の競合が多い）
5. マージの優先度を上げやすい

「小さい」の定義

ガイドラインは厳密な行数制限を設けていないが、おおよその目安として「約100行が合理的で、1000行は通常多すぎる」と述べている。ただし最終的な判断はレビュアーの判断に委ねられており、変更の性質や分散度合いによって異なる。

CLを分割する具体的な戦略

# スタック型（推奨）
# CL1: 抽象レイヤーを追加する
# CL2: CL1の上に実装を追加する（CL1のレビュー中に開始）
# CL3: テストを追加する

# ファイル別分割
# CL1: バックエンドの変更（レビュアーA）
# CL2: フロントエンドの変更（レビュアーB）

# 機能別分割（垂直分割）
# CL1: ユーザー登録フォームの追加
# CL2: バリデーションロジックの追加
# CL3: エラーハンドリングの追加

技術3：レビューコメントへの対処

コードレビューのコメントを受け取った著者がすべきこととすべきでないことを、ガイドラインは明確に定めている。

感情的に反応しない

怒りを感じながらコードレビューのコメントに返答することは禁じられている。ガイドラインは「怒りを感じたら返答する前に少し間を置くこと」と述べている。もしレビュアーの態度が継続的に非建設的であれば、直接個人的に話し合うか、マネージャーにエスカレーションすることを推奨している。

コードで明確にすることを優先する

レビュアーが「このコードが理解できない」とコメントした場合、最初の対応はレビューツール上で説明することではなく、コードそのものを明確にすることだ。コードレビューツール上の説明は将来の読者には届かない。

不同意を協調的に表明する

著者はレビュアーの意見に反論する権利を持つ。ただし「あなたは間違っている」ではなく「このアプローチには次のトレードオフがあります。別のアプローチより優れていると考える理由は○○です」という形で、根拠を示しながら議論する。

コードレビューコメントの書き方：Nit・FYI・Considerの使い分け

レビュアーが書くコメントの「重要度」を明示することは、著者が何に集中すべきかを明確にする上で重要だ。eng-practicesはコメントの分類ラベルを定義している。

ラベルによるコメントの分類

# Nit（細かい指摘）— 技術的に正しいが非強制
Nit: 変数名 `data` より `userData` の方が意図が明確です。

# Optional / Consider（任意）— 提案として提示
Optional: ここでearly returnを使うと、ネストを1レベル減らせます。

# FYI（情報提供）— 今回は対応不要だが知っておくべき
FYI: このパターンは今後廃止予定のAPIを使っています。将来の対応を検討してください。

# [強制コメント] — ラベルなしは原則として修正必須
この関数はスレッドセーフではありません。並行アクセスが想定されるため、同期機構を追加してください。

コードではなく、コードについてコメントする

ガイドラインの重要な原則として「人ではなくコードについてコメントする」がある。

# 悪い例（著者を主語にした批判）
「なぜあなたはここでスレッドを使ったのですか？」

# 良い例（コードを主語にした技術的議論）
「この並行処理モデルはパフォーマンス上の利益なしに複雑さを増しています。
シングルスレッドの実装との比較ベンチマークはありますか？」

肯定的なフィードバックも重要

多くのレビュアーが忘れがちなのが、良い実装への肯定的なフィードバックだ。eng-practicesは明示的に「優れたアルゴリズム、優秀なテストカバレッジ、得られた洞察など、良い仕事を認めること」を推奨している。理由は2つある。

1. 開発者のモチベーション維持
2. 「なぜこのアプローチが良いのか」の知識共有

GitHub/GitLabチームへの適用：Google流コードレビュー文化の導入手順

google/eng-practices はGoogleの社内ツール（Critique等）を前提に書かれているが、GitHubやGitLabを使うチームでも直接適用できる。

ステップ1：PR テンプレートでCL説明文の文化を定着させる

Google式のCL説明文の書き方をPRテンプレートとして定義することで、チーム全体に習慣として定着させられる。

<!-- .github/PULL_REQUEST_TEMPLATE.md -->
## 変更の概要（What & Why）
<!-- 1行目: 簡潔な命令形の文で変更内容を要約 -->
<!-- 本文: 解決する問題・選択したアプローチの理由・制約 -->

## テスト方法
<!-- この変更をどのように検証したか -->

## チェックリスト
- [ ] コード変更に対応するテストを追加した
- [ ] 既存のテストが通ることを確認した
- [ ] ドキュメントの更新が必要な場合は更新した
- [ ] このPRは1つのことだけを変更している（複数の目的がある場合は分割）

ステップ2：レビュースピードのSLAを設定する

Googleの「1営業日以内の初回返答」ルールを参考に、チーム独自のSLA（サービスレベル合意）を設定する。

• 初回レビュー開始: PRオープンから24時間以内
• コメントへの返答: 次の営業日中
• マージまでのサイクル: 原則3回以内のイテレーションで完了

ステップ3：コメントラベルの慣例を確立する

Nit:, FYI:, Optional:, [Blocking] などのラベルをチームの慣例として定め、CONTRIBUTING.md またはコードレビューガイドラインとして文書化する。

Googleの方法論と一般的なアプローチの比較

よくある失敗パターンと対処法

失敗1：設計問題を後から指摘する

コードの細部をすべてレビューした後で「そもそもこのアプローチは間違っている」と指摘するのは著者の時間を無駄にする。Google流は「全体を把握してから詳細へ」という順序を守ることで防ぐ。

失敗2：すべてのコメントをブロッカーとして扱う

Nit: ラベルなしのコメントはすべてマージブロッカーとして著者に受け取られる。重要でない指摘に Nit: を付けるだけで、著者がどこに集中すべきかが劇的に明確になる。

失敗3：「後で直す」を許容しすぎる

「後で直す」という慣行が蔓延すると、技術的負債が積み上がる。Google流は「緊急事態でなければその場での修正を要求する」という明確な方針を持つ。

AI自動化を活用した類似の生産性改善事例として、Postgres LLMで「INSERTするだけでLLM処理」を実現するトリガー型OSS や youtube-automation-agent解説：5エージェント構成でYouTube投稿を完全自動化するOSS も参考になる。

参照ソース

• google/eng-practices — GitHub
• Google Engineering Practices Documentation — 公式サイト
• The Standard of Code Review — eng-practices
• Speed of Code Reviews — eng-practices