> For the complete documentation index, see [llms.txt](https://livlog-llc.gitbook.io/engineering-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://livlog-llc.gitbook.io/engineering-handbook/codexwoshitana/26-review-and-merge.md).

# 26. レビューと取り込み

## 目的

Codexが作成した差分を、人間が要件、設計、安全性、保守性の観点から確認し、採用できる変更だけを取り込みます。

## Codexの出力をそのまま信用しない

コードがコンパイルでき、テストが成功していても、要件に合わない、既存仕様を変える、運用できない、過剰に複雑である可能性があります。Codex自身の「完了しました」という報告は、レビューの代わりにはなりません。

レビュー前に、次を揃えます。

* 要件、設計、タスク、テスト計画
* 変更ファイル一覧と差分
* 実行したコマンドと結果
* 手動確認結果
* 実行できなかった確認
* 未決事項、仮定、既知の制約

## レビュー観点

```
- 要件を満たしているか
- 既存仕様を壊していないか
- 変更範囲が適切か
- 命名が既存ルールに合っているか
- エラーハンドリングがあるか
- テストがあるか
- ドキュメントが更新されているか
- Secretsが含まれていないか
- 不要な大規模リファクタリングがないか
```

加えて、変更内容に応じて次を確認します。

### API・Java

* RequestとResponseが既存契約に合うか
* Validation、HTTPステータス、例外形式が一貫しているか
* Entityを不用意に公開していないか
* トランザクションとDBアクセスが適切か

### DB

* 既存データ、NULL、既定値、制約を考慮しているか
* migrationの適用順序とロールバックが明確か
* 旧コードと新スキーマの展開順序に問題がないか

### フロントエンド

* ローディング、空、エラー、権限なしの状態があるか
* 既存画面、レスポンシブ表示、アクセシビリティを壊していないか
* API契約と表示が一致しているか

### セキュリティ・情報管理

* 認証と認可を混同していないか
* ログ、例外、画面へ機密情報を出していないか
* Secrets、APIキー、パスワード、トークンをコミットしていないか
* テストデータやスクリーンショットに個人情報がないか

## 差分の読み方

1. まず変更ファイル一覧を見て、想定外の範囲がないか確認する
2. 要件と設計に対応する差分を読む
3. 設定、依存関係、migrationなど影響の大きい変更を先に読む
4. 自動生成物を含め、不要な変更を確認する
5. テストが要件を検証しているか読む
6. 文書と実装の一致を確認する
7. コマンドを再実行し、必要な手動確認を行う

差分が大きすぎてレビューできない場合は、承認せず分割します。継続更新する機能では、現在仕様と変更履歴もレビュー対象に含めます。詳しくは「[29. 機能の継続更新](/engineering-handbook/codexwoshitana/29-continuous-feature-updates.md)」を参照してください。

## Codexによる補助レビュー

別の依頼として、Codexに差分レビューをさせることができます。その場合は、修正を同時に行わせず、まず指摘だけを出させます。

* 重大度
* 根拠となるファイルと箇所
* 発生条件
* 利用者または運用への影響
* 推奨する確認または修正

Codexの指摘には誤検知もあるため、人間がコードと要件を確認して採否を決めます。

## 取り込み

最終的なコミット、Pull Request、マージ、デプロイは人間の責任で行います。

1. レビュー指摘を解消する
2. 対象テストと既存テストを確認する
3. 文書、migration、運用手順を確認する
4. Secrets検査と差分確認を行う
5. 変更の目的、確認結果、残課題をPull Requestへ記載する
6. 人間が承認して取り込む
7. 必要に応じてリリース後の動作とログを確認する

## Codexに依頼すること

* 差分を要件と設計に照らしてレビューする
* 重大な問題から順に、根拠と発生条件を示す
* 不要な変更、過剰な抽象化、互換性破壊を指摘する
* Secretsや個人情報の混入候補を指摘する

## 人間が確認すること

* すべての差分を自分または担当者が読んだか
* テスト結果と未確認事項を把握しているか
* 指摘を機械的に採用せず、妥当性を判断したか
* 取り込みとリリースの責任者が明確か


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://livlog-llc.gitbook.io/engineering-handbook/codexwoshitana/26-review-and-merge.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
