Tsuzura

AI生成コードをレビューする

AIが生成した一件のコード変更について、AIへ渡した情報と権限、対象版、差分、検証結果、依存関係を確認します。利用できる場合は公開コードとの一致表示も確かめ、次の行動を判断します。

公開日
更新日

AIが生成したコードは、見た目が整っていても、そのまま採用できるとは限りません。要件と違う処理、対象外のファイル変更、弱められたテスト、不要な権限が含まれる可能性があります。確認するのはAIの説明ではなく、最終的な変更内容と、その変更を確かめた証拠です。

コードレビューは、変更したコードを読み、要件、設計、検証結果、影響範囲に照らして、次へ進めてよいかを人が判断する作業です。この記事では、一件のAI生成変更について、確認済みと未確認を分け、次の四つから結論を選びます。

  • 採用する
  • 修正後に再確認する
  • 要件・設計へ戻す
  • 保留して担当者へ相談する

この四分類は、外部規格の正式な承認状態ではなく、本記事の記録方法です。確認項目を埋めても、欠陥や脆弱性がないことは保証できません。

この記事は、要件と受入条件、一件に分けた実装タスク、Gitで確認できる変更差分がある状態を対象にします。Gitの操作、テストの選び方、設計原則、コードアーキテクチャ、公開判断は、それぞれの専用記事で扱います。

レビューは、次の順で進めます。

  1. AIへ渡した情報と、AIに与えた権限を確認する
  2. レビューする変更と版を固定する
  3. すべての差分と処理の流れを確認する
  4. 検証結果とテスト自体を確認する
  5. 依存関係、公開コードとの一致、秘密情報などを確認する
  6. 判断できない項目があれば止める
  7. 四つの判断から一つを選び、根拠と次の行動を記録する

詳細な一覧は、今回の変更に該当する部分を確認するために使います。自分で判断できない項目は推測で埋めず、担当者へ渡します。

AI生成コードをレビューする理由

テストに合格したこと、Gitへコミットしたこと、コードを採用したこと、本番へ公開したことは別の状態です。どこまで終わったのかを分けないと、未確認の変更が次の工程へ進みます。

状態 分かること それだけでは分からないこと
テストに合格した そのテストに定めた判定上は合格した 要件の抜け、未実行の条件、欠陥や脆弱性がないこと
コミットした 選んだファイル内容がGitの履歴へ記録された 内容の正しさ、レビュー完了、公開可否
レビューした 対象版について、人が変更と証拠を確認した 未確認とした範囲、公開環境での動作
採用した 判断者が、次の工程へ渡してよいと決めた 公開準備、運用準備、将来の変更の安全性
公開した 変更後のサービスを対象利用者が使える状態にした 障害が起きないこと、復旧できること

ISTQBのソフトウェアテスト基礎資料は、テストで欠陥の存在を示せても、不存在や正しさを証明できないと説明しています。GitHubのAI生成コードレビューガイドも、ビルドやテストの後に、要件、設計、既存の構成、解くべき問題との一致を人が確認するよう示しています。

基礎となる品質基準は、生成した主体によって変えません。人が書いた変更と同じ要件、設計、セキュリティ、保守性の基準を適用します。そのうえで、AIの作業報告と実際の差分が一致するか、AIがテストや設定まで変えていないかを追加で確認します。

レビューで作るもの

レビューの成果は「確認済み」という一語ではありません。対象版、確認した証拠、指摘、未確認事項、結論、次の行動を対応づけた記録です。

レビューする人と、採用を決める人は同じ場合もあります。別の人が決める場合は、誰がどこまで確認し、誰が残る影響を受け入れたかを分けて残します。

AIへ渡す情報と権限を確認する

AIを補助レビューに使う場合は、レビュー対象を送る前に、AIが読める情報と実行できる操作を確認します。AIを使わず人だけでレビューする場合も、実装時にAIへ渡した情報と権限を記録します。

実装時とレビュー補助時で使うAI、送信情報、権限、設定が異なる場合は、一つの記録へまとめません。利用場面、利用日時、コードを生成またはレビューした会話や作業を分け、AIの利用ごとに同じ記録欄を作ります。

AIへ渡す情報を確認する

クラウド側で処理するAIコーディングツールは、開いているファイルだけでなく、プロジェクト構造や端末の出力を提供者へ送る場合があります。OWASPのAIコーディング向けガイドは、送信される文脈を確認し、秘密情報を含むファイルを対象から外すよう勧めています。.gitignoreはGitの対象を決める設定であり、AIによるファイル読取りを止める設定ではありません。

次を確認してから、リポジトリ、差分、動作記録、テスト結果をAIへ渡します。リポジトリとは、コード、設定、文書をまとめて版管理する場所です。

  • AIツールと提供者
  • 製品、契約プラン、組織用のアカウントや作業場所
  • AIへ送られるファイル、差分、会話、端末出力
  • 利用目的と組織の規則
  • 入力情報を回答生成以外に利用するかと、機械学習へ使う条件
  • 保存期間、削除条件、管理者設定
  • 契約、利用規約、プライバシーポリシーの参照先

日本の個人情報取扱事業者について、個人情報保護委員会の注意喚起は、個人情報の入力が特定した利用目的の達成に必要な範囲かを確認するよう示しています。本人の同意なく個人データを入力する場合は、提供者が応答生成以外へ利用するか、機械学習へ使うかも確認対象です。

実データが不要なら、実在する人や顧客の値を含まないテスト用データへ置き換えます。一部を伏せても個人を識別できる可能性が残るデータは、安全に送信できる匿名データとして扱いません。秘密情報の値や、生の個人・顧客データをレビュー票へ転記せず、アクセス制限された確認記録の参照先だけを残します。

保存期間、削除条件、法人向け契約、管理者設定は、本記事で追加する確認項目です。個人情報保護委員会の資料が、この四項目を一律の法的要件として示しているわけではありません。確認できても、個別案件が適法であること、保存されないこと、学習へ使われないことを保証するものではありません。

AIの権限と実行済みの操作を確認する

AIがコードを読むだけなのか、ファイル変更、コマンド実行、ネットワーク接続までできるのかを分けます。MCPやコネクタは、AIへ外部ツールやサービスを接続する仕組みです。使っている場合は、接続先と権限も確認します。

OWASPのExcessive Agencyに関する資料は、AIエージェントへ必要最小限の機能と権限だけを与えるよう示しています。削除、送信、公開、権限変更などの影響が大きい操作は、実行前に対象を示して人の承認を取り、接続先でも認可します。

利用したAIについて、次を記録します。

  • ツール、提供者、モデル、バージョン
  • 読み取れる場所と書き込める場所
  • 実行できるコマンド
  • 接続できるネットワーク、MCP、コネクタ、外部サービス
  • AIが使うアカウントと権限の参照先。資格情報の値は書かない
  • 実際に変更したファイル、実行したコマンド、通信、外部操作の記録先
  • 人が事前に承認した操作、対象、承認者

OpenAIのCodex公式ガイドでは、サンドボックスが技術的に可能な操作範囲を、承認設定が承認判断を必要とする地点を制御します。Auto-reviewの公式ガイドによると、承認要求の送り先は設定により利用者または別のレビュー用AIとなります。

現在の設定と送り先を確認します。これはCodex固有の仕組みです。他の製品では、対応する権限制御を公式資料で確認します。自然言語で「変更しない」と指示しただけでは、技術的な制限になりません。本記事でいう高影響操作の承認と、コードを採用する最終判断は人が行います。

送信範囲または権限を確認できない場合は、AIを使ったレビューを始めません。秘密情報や個人・顧客データを除けない場合も送信を止め、プライバシー、契約、セキュリティの担当者と再開条件を決めます。

レビュー対象を固定する

レビューは、どの変更を確認するかを決めてから始めます。AIとの会話履歴だけでは、対象版を固定できません。実際の要件、Gitの比較起点、結果の版、変更ファイルをそろえます。

開始前にそろえる情報

必要な情報 確認する内容 ない場合
変更目的 今回一つだけ解く問題 タスクを分け直す
要件と対象外 何を満たし、何を変えないか 要件の判断者へ戻す
受入条件 何をもって完成とするか 合格を判断しない
実装タスク 変更範囲、停止条件、検証方法 AIへ再依頼する前に補う
比較起点 変更前のコミットまたは対象版 どこからの変更かを確認する
結果の版 レビューするコミットや成果物 対象版を作り直す
変更一覧と差分 追加、変更、削除、未追跡のファイル Git変更記録へ戻る
実行環境 検証に使った環境、設定、主要な版 結果の適用範囲を未確認にする
リポジトリの規則 ビルド、テスト、設計、承認の決まり README等を確認する

OpenAIの同じCodex公式ガイドは、変更のない開始状態、作業用のブランチ、差分中心の変更、小さなコミット、対象を絞った検証、人による差分確認を勧めています。他のAIコーディングツールでは、利用できる権限制御と版管理の方法を個別に確認します。

一件に絞れない場合は止める

機能追加、無関係な整理、依存関係の更新、設定変更が一つの差分へ混ざると、指摘と判断を一つの理由へ結び付けにくくなります。AIに渡す実装タスクの切り方へ戻り、別の目的は別の変更へ分けます。

分けると途中状態が壊れる場合は、同時に必要な理由と、まとめて確認する範囲を記録します。理由を説明できないまま、変更量だけを見てレビューを続けません。

変更全体と処理の流れを確認する

AIの作業報告は、確認対象を探す手掛かりです。報告に書かれていない変更がないことの証拠にはなりません。Gitが示す全変更を一件ずつ確認します。

OWASPのAIコーディング向けガイドは、AIの要約だけでなく全差分を確認するよう示しています。対象外ファイル、依存関係を固定するファイル、テスト、ビルド、自動検査、公開設定も対象です。

ファイルの種類ごとに確認する

CIは、変更のたびにビルドやテストを自動実行する仕組みです。デプロイは、変更を対象環境へ反映する作業です。

変更対象 確認すること 停止する状態
実装コード 変更目的、処理、失敗時の動作 意図を説明できない
テストコード 追加、削除、除外、期待結果の変更 合格しやすくするだけの変更がある
依存関係の定義 追加・削除・版変更と固定内容 実在、出所、必要性を確認できない
設定 開発・検証・本番のどこへ作用するか 既定値や対象環境が不明
データベース変更 構造、既存データ、適用順、失敗時の扱い 安全な確認環境や担当者が不明
ビルド・CI 実行するコマンド、権限、ネットワーク利用 不明な取得処理やシェル実行がある
デプロイ定義 公開先、権限、利用者への影響 本番へ作用する可能性を判断できない
文書 利用方法、設定、運用手順との一致 コードだけ変わり必要な説明が古い
生成ファイル 生成元、再生成方法、直接編集の可否 生成元と結果の対応が不明

ファイル名だけで判断しません。テスト用に見えるファイルがビルド時に実行されたり、設定ファイルが本番の権限を変えたりすることがあります。リポジトリの仕組みを確認し、何がそのファイルを読むかを追います。

削除と対象外変更を先に見る

追加行だけでなく、削除された処理、テスト、入力検証、権限確認、エラー処理も読みます。GitHubの同じレビューガイドは、存在しないAPI、無視された制約、削除または省略されたテスト、意図と異なる処理を確認候補として挙げています。これは発生頻度を示す一覧ではありません。今回の差分で該当するかを確かめるために使います。

許可していないファイルが変わっている場合は、AIに理由を説明させるだけで採用しません。要件とリポジトリの実装を確認し、必要なら変更目的へ追加します。不要なら差分から外し、もう一度すべての変更を確認します。

入力から外部作用まで追う

変更した処理がどこから呼ばれ、何を読み、何を変え、何を返すかを追います。Googleのコードレビューガイドは、設計、利用者に対する機能、複雑さ、テストを確認し、必要に応じて周辺ファイルやシステム全体を見るよう示しています。

今回の変更に該当する経路を、次の順で確認します。

  1. 入力はどこから来るか
  2. 形式、範囲、必須項目をどこで検証するか
  3. 誰であるかと、何をしてよいかをどこで確認するか
  4. 業務上の条件と計算をどこで扱うか
  5. データベース、ファイル、一時保存領域、動作記録へ何を残すか
  6. 外部API、メッセージ、メール、通知へ何を送るか
  7. 利用者や呼出元へ何を返すか
  8. 失敗、時間切れ、重複実行、途中終了で何が残るか

外部作用とは、コードの実行によってリポジトリ外の状態が変わることです。データベースの更新、外部APIへの送信、メール送信、一時保存領域の更新、公開環境の設定変更などが該当します。

OWASPのセキュアコードレビュー資料は、自動ツールを補助として使い、人が変更部分、既存の安全対策、信頼できる範囲が変わる境界、外部連携、データの流れを確認する方法を示しています。

責務、依存方向、既存の契約に合うか分からない場合は、ソフトウェア設計原則とコードアーキテクチャの記録へ戻ります。今回の変更だけでは決められない設計判断を、レビュー中の推測で確定しません。

検証結果とテスト自体を確認する

ツールによる自動確認は、実行した版と条件に対する証拠です。「全部通った」という説明だけでは、対象版、実行環境、未実行の検査、テスト自体の変更が分かりません。

GitHubのAI生成コードレビューガイドは、ビルドまたはコンパイル、既存テスト、警告・エラー、静的解析から確認を始めるよう示しています。NISTのSecure Software Development Framework v1.1は、安全な記述基準に基づくレビュー・分析の結果を記録し、脆弱性の発見とセキュリティ要件への適合確認に必要なテストの種類と範囲を決め、その結果を記録する実務を示しています。

検証ごとに証拠を分ける

ビルドは、配布または実行できる成果物を作る処理です。コンパイルは、書いたコードを実行可能な形式などへ変換する処理です。Lintは、決めた記述規則や問題候補を機械的に調べます。静的解析は、コードを実行せずに不具合や安全上の問題候補を調べます。

確認 記録するもの 合格でも残る確認
ビルド・コンパイル 対象版、コマンド、環境、結果 要件や処理内容の正しさ
型検査 ツールと版、対象範囲、エラー 型で表していない業務条件
Lint 規則、対象範囲、警告 設計、権限、データの流れ
静的解析 規則、検出事項、人の判断 未対応の問題、実行時の挙動
テスト テスト名、環境、期待結果、実結果 未実行条件、テスト自体の妥当性

結果は「合格」「失敗」「未実行」「該当なし」に分けます。該当なしには理由を書きます。ツールがないことや、コマンドが分からないことは未実行です。

テスト自体を読む

テストも変更されたコードです。正しい処理を確認しているか、壊れた実装では失敗するか、意味のある期待結果を持つかを読みます。Googleの同じコードレビューガイドは、テスト自体が正しく、役立つ内容であるかを人が確認するよう示しています。

次の変更があれば、テスト合格だけで進みません。

  • テストが削除された
  • テストを飛ばす設定や、対象外にする設定へ変わった
  • 期待結果が実装に合わせて弱くなった
  • エラーを無視するようになった
  • もともと実際の接続先を確認していたテストが、代替処理だけを使う形へ変わった
  • 変更の影響上必要な接続条件を確認していない
  • AIが実装と安全上重要なテストを同時に作り、別の確認がない

OWASPのAIコーディング向けガイドは、削除または弱められたテストを確認するよう示しています。安全上重要な領域では、AIが同時に作ったコードとテストだけを根拠にせず、独立した検証を加えます。

修正後は、指摘した箇所が直ったことと、周辺へ悪影響がないことを分けて確認します。前者は修正確認、後者は回帰確認です。範囲の選び方はテストの種類と選び方で扱います。

依存関係と重要な影響を確認する

依存関係は、変更したコードが利用するパッケージ、ライブラリ、外部サービスなどです。秘密情報、権限、利用者データ、外部通信、データベース、ビルド、公開設定とともに、影響を理解できる担当者が確認します。

依存関係を確認する

新しいパッケージや版変更がある場合は、マニフェストとロックファイルを確認します。マニフェストは利用する依存関係を宣言するファイルです。ロックファイルは、解決した版や間接的な依存関係を記録・固定するためのファイルで、記録内容は開発環境によって異なります。

次を記録します。

  • パッケージが実在し、公式の配布元とソースを確認できるか
  • 今回の要件に必要か
  • 直接使うか、別の依存関係から入るか
  • 追加または変更された版
  • 保守状況と既知の脆弱性を確認した場所
  • 利用許諾条件を組織の規則で確認したか

GitHubのDependency Review資料は、マニフェストとロックファイルの差分から、直接・間接の依存関係と既知の脆弱性を確認する機能を説明しています。検出範囲は、対応する開発環境、設定、既知の脆弱性情報に限られます。合格しても、未知の問題や利用許諾条件への適合は証明しません。

パッケージ、API、利用許諾条件を確認できない場合は、インストールや実行へ進まず保留します。個別の適否はこの記事で判断せず、組織の担当者または専門家へ渡します。

生成コードの公開コード一致と利用条件を確認する

依存パッケージの利用許諾条件とは別に、AIが出力したコード自体も確認します。利用したAIに公開コードとの一致を示す機能がある場合は、一致した範囲、候補URL、表示された利用許諾条件を記録します。候補URLを開き、元のリポジトリにあるLICENSE、README、対象ファイルの著作権表示や帰属表示を確認します。

GitHub Copilotのコード参照機能は、条件を満たす一致について候補ファイルのURLと、見つかった場合のライセンス名を示します。ただし、利用者が書いたコード、変更済みの候補、GitHub外または非公開リポジトリのコードは照合対象外です。検索用の索引にも更新間隔があります。

文化庁の「AIと著作権に関するチェックリスト＆ガイダンス」は、AI生成物を利用する前に既存の著作物との類似性を確認し、生成に用いた指示などの生成過程を確認できる状態にしておくことを、業務利用者向けのリスク低減策として挙げています。

一致表示がないことだけで、出所や利用条件に問題がないとは判断しません。一致が表示されても、侵害が確定したとは判断しません。公開コードとの一致を調べる機能が利用できない場合も、それだけで保留にはしません。利用したAIサービス、組織の利用条件、生成時の記録を確認し、機能で検出できない範囲を未確認として残します。

一致候補が表示されたのに、利用許諾条件、著作権表示、帰属表示の扱いを決められない場合は保留し、組織の担当者または専門家へ渡します。この確認や文化庁の資料は、個別案件の適法性や免責を保証するものではありません。

秘密情報とアプリケーションの権限を確認する

実際のアクセスに使えるパスワード、トークン、APIキーが、差分、テスト用データ、設定、動作記録へ含まれていないか確認します。値をレビュー記録へ写しません。OWASPのSecrets Managementガイドは、秘密情報をソースコードや平文の動作記録へ含めず、必要な人やシステムだけが利用し、失効・更新方法を用意するよう示しています。

実際に使える秘密情報がリポジトリへ入った場合は、担当者へ連絡して直ちに失効または更新します。秘密値を含んだ状態での送信、ステージ、コミット、プッシュを止め、露出範囲と履歴除去の要否を判断します。GitHubの機密情報除去ガイドは、秘密情報を先に失効または更新し、その後に履歴除去の要否を判断するよう説明しています。履歴を書き換えるだけでは、複製や既に使われた可能性へ対応できません。

アプリケーションの権限が変わる場合は、利用者だけでなく、ビルド、CI、デプロイが使う権限も確認します。新しく読めるデータ、書き込めるデータ、実行できる操作、ネットワークの接続先を比較します。

データと外部作用を確認する

次のいずれかが変わる場合は、影響を確認できる担当者を加えます。

  • 個人情報、顧客データ、決済情報の読取りや保存
  • 本人確認または操作権限の判断
  • データベースの構造、既存データ、削除処理
  • 共有する一時保存領域の識別方法、保存内容、有効期限
  • 動作記録へ残すデータ
  • 外部API、メール、通知、処理待ち行列への送信
  • ビルド・CIから実行する処理とネットワーク接続
  • 本番設定、デプロイ、利用者へ変更を広げる制御

安全に再現できる検証環境がない場合、本番操作で動作確認しません。必要な権限、データ、連絡先、復旧方法を本番公開前の確認とWebサービスの最低限の運用設計へ渡します。

判断できない場合は止める

変更を理解できない状態は、採用不可と断定する状態ではなく、判断材料が不足した状態です。説明、証拠、専門性がそろうまで保留します。

Googleのコードレビューガイドは、変更を理解できない場合は説明を待つよう示しています。プライバシー、セキュリティ、同時実行などを判断できない場合は、その領域を判断できる人を加えます。

停止する条件

本記事では、次の事項について影響を判断できない場合、または組織の規則が専門レビューや承認を求める場合に、結論を確定せず担当者へ渡します。

  • 変更目的、要件、受入条件が確定していない
  • 比較起点またはレビュー対象版が分からない
  • 変更を一つの目的として説明できない
  • 対象外の変更や削除の理由が分からない
  • 処理の呼出元、データ、権限、外部作用を追えない
  • 必要な検証が未実行で、実行方法または環境が分からない
  • 秘密情報、個人情報、決済、本人確認、操作権限へ影響し、必要な担当者または確認範囲を特定できない
  • 依存関係の出所、利用許諾条件、既知の問題を確認できない
  • 公開コードとの一致が表示された範囲の利用許諾条件、著作権表示、帰属表示を確認できない。または、利用したAIサービスと組織の利用条件を確認できない
  • 本番や外部サービスへ作用しない形で再現できない
  • 自分の専門範囲では影響を判断できない

止めるときは、未確認事項、確認に必要な情報、担当者、再開条件を記録します。「あとで確認する」だけでは、次の工程へ渡しません。

四つの判断を記録する

確認結果を、次の四つへ分けます。これはTsuzuraの編集上の整理です。組織に承認状態がある場合は、その状態へ対応づけます。

判断 選ぶ条件 次の行動
採用する 必須の要件と受入条件を満たし、必要な証拠がそろい、未解決の必須修正がない 次の工程へ対象版とレビュー記録を渡す
修正後に再確認する 変更目的は妥当だが、直せる必須修正や失敗した検証がある 修正範囲と再確認項目を一件にして戻す
要件・設計へ戻す 解く問題が違う、変更自体が不要、受入条件が決められない、構造上の判断が必要 要件または設計の判断者が、再実装か破棄を決める
保留して相談する 情報、証拠、環境、権限、専門性が不足している 担当者と再開条件を決める

指摘を三つに分ける

指摘 意味 採用との関係
必須修正 要件、受入条件、セキュリティ条件、組織規則を満たさない 解消するまで採用しない
改善候補 今回の採用条件ではないが、保守性や明確さを改善できる 任意か、別タスクにするかを記録する
未確認 情報や判断者が不足し、合否を決められない 保留して再開条件を決める

Googleのコードレビュー方針は、技術的事実とデータを個人の好みより優先し、必須でない改善を必須修正と区別し、合意できない判断を責任者へ渡す実務を示しています。これはGoogle固有の方針です。法令、契約、セキュリティ要件、組織の承認規則を緩める根拠にはしません。

要件、受入条件、権限、安全性、外部作用に未確認があれば採用せず、保留します。公開コードとの一致候補が表示された場合は、その範囲の利用条件も確認します。利用したAIサービスと組織の利用条件を確認できない場合も保留します。それ以外の改善候補を残して採用する場合は、採用を決める権限がある人が影響を確認し、担当者と見直し条件を記録します。

修正を選んだ場合は、指摘した箇所だけでなく、影響範囲に合う回帰確認も指定します。修正後の再確認では、元のレビュー記録を上書きしません。新しい対象版、元の指摘からの差分、再実行した確認、判断日を別の記録または履歴行に残し、元の判断へつなぎます。要件・設計へ戻す場合は、コードの細部を直し続けず、決め直す問いと判断者を明示します。

AI生成コードのレビュー記録を作る

レビュー記録は、Git変更記録やテスト結果をコピーする場所ではありません。それぞれの参照先と、判断に使った部分を対応づけます。

記録の共通ルール

  • 空欄のまま完了にしない
  • 確認した項目は「確認済み」とする
  • 関係しない項目は「該当なし」とし、理由を書く
  • 分からない項目は「未確認」とし、担当者と再開条件を書く
  • 秘密値、生の個人・顧客データ、資格情報を転記しない
  • 要件、受入条件、権限、安全性、外部作用が未確認なら、結論は「保留して相談」にする
  • 公開コードとの一致候補が表示された範囲の利用条件、または利用したAIサービスと組織の利用条件を確認できない場合も「保留して相談」にする
  • AI利用は実装時とレビュー補助時を分け、利用したAIごとに「AIへ渡した情報」と「AIの権限と実行」の欄を複製する

最初と最後に記入する欄

レビューを始める前に、次の四点を固定します。

  1. 変更目的と受入条件
  2. 比較起点とレビュー対象版
  3. 全変更の参照先
  4. リポジトリの規則とAI利用記録の参照先

差分、処理、検証、影響を確認した後に、必須修正、未確認、四つの判断、判断者、次の行動を記入します。途中で結論を先に決めません。

空欄のレビュー記録

# AI生成コードのレビュー記録

## 記入状態

- 空欄: [なし / あり]
- 該当なしとした項目・理由:
- 未確認項目・担当者・再開条件:

## 対象

- 変更目的:
- 関連する要件:
- 受入条件:
- 対象外:
- 実装タスクの参照先:
- Git変更記録の参照先:
- 比較起点:
- レビュー対象版:
- 実行環境:
- リポジトリ規則の参照先:
- レビューした人:
- 採用を判断する人:

## AIへ渡した情報

- 利用場面: [実装 / レビュー補助]
- 利用日時:
- コードを生成またはレビューした会話・作業の参照先:
- AIツールと提供者:
- 製品・契約プラン・組織用のアカウントや作業場所:
- モデル・バージョン:
- 送信した情報: [ファイル / 差分 / 動作記録 / テスト結果 / その他 / なし]
- 利用目的:
- 組織規則・契約・管理設定の参照先:
- 回答生成以外の利用・学習条件: [確認済み / 未確認 / 該当なし（理由）]
- 保存・削除条件: [確認済み / 未確認 / 該当なし（理由）]
- 秘密値の除去: [確認済み / 未確認]
- 個人・顧客データ: [なし / テスト用の架空データ / 加工したデータ / 実データ / 未確認]
- プライバシー・契約の判断者:
- AI利用の判断: [利用可 / 送信せず相談 / 未確認]

## AIの権限と実行

- 読み取れる範囲:
- 書き込める範囲:
- コマンド実行権限:
- ネットワーク接続先:
- MCP・コネクタ・外部サービス:
- AIが使うアカウントと権限の参照先:
- サンドボックス・承認設定:
- 実際に変更したファイルの参照先:
- 実行したコマンドと結果の参照先:
- 実際の通信・外部操作の参照先:
- 人が承認した操作・対象・承認者:
- 設定された権限と実際の操作の差:

## 変更全体

- 変更ファイル一覧の参照先:
- 追加:
- 変更:
- 削除:
- 対象外変更: [なし / あり / 未確認]
- テスト変更: [なし / あり / 未確認]
- 依存関係の変更: [なし / あり / 未確認]
- 設定・ビルド・CI・デプロイ変更: [なし / あり / 未確認]

## 要件と処理

- 要件との一致: [確認済み / 不一致 / 未確認]
- 入力と検証:
- 本人確認・操作権限:
- 業務処理:
- 保存・一時保存・動作記録:
- 出力と外部作用:
- 失敗時の動作:
- 既存設計との一致: [確認済み / 不一致 / 未確認]

## 検証証拠

| 確認 | 状態 | 対象版・環境 | 記録先 | 未実行・該当なしの理由 |
|---|---|---|---|---|
| ビルド・コンパイル | 合格 / 失敗 / 未実行 / 該当なし | | | |
| 型検査 | 合格 / 失敗 / 未実行 / 該当なし | | | |
| Lint | 合格 / 失敗 / 未実行 / 該当なし | | | |
| 静的解析 | 合格 / 失敗 / 未実行 / 該当なし | | | |
| テスト | 合格 / 失敗 / 未実行 / 該当なし | | | |

## 依存関係

- 追加・変更した依存関係:
- 公式配布元・ソース:
- 直接・間接:
- 版と固定記録:
- 保守状況・既知の脆弱性の確認先:
- 利用許諾条件の確認: [確認済み / 未確認 / 該当なし（理由）]

## AI生成コードの公開コード一致と利用条件

- コードを生成した会話・作業と記録の参照先:
- 公開コード一致機能: [利用可能 / 利用不可 / 未確認]
- 一致表示: [なし / あり / 未確認]
- 一致した範囲と候補URL:
- 利用許諾条件・著作権表示・帰属表示の確認結果:
- 機能で検出できない範囲:
- AIサービスと組織の利用条件: [確認済み / 未確認]
- 組織規則または専門担当の確認: [確認済み / 未確認 / 該当なし（理由）]
- 残る未確認と担当者:

## 影響の大きい変更

- 秘密情報: [なし / あり / 未確認]
- アプリケーションの権限: [変更なし / 変更あり / 未確認]
- 個人・顧客データ: [変更なし / 変更あり / 未確認]
- データベース: [変更なし / 変更あり / 未確認]
- 外部通信・送信: [変更なし / 変更あり / 未確認]
- ビルド・公開経路: [変更なし / 変更あり / 未確認]
- 確認した担当者と範囲:

## 指摘

| 場所 | 指摘 | 種類 | 影響 | 証拠 | 必要な対応 | 状態 |
|---|---|---|---|---|---|---|
| | | 必須修正 / 改善候補 / 未確認 | | | | 未対応 / 対応済み / 保留 |

## 判断

- 結論: [採用 / 修正後に再確認 / 要件・設計へ戻す / 保留して相談]
- 判断理由:
- 元のレビュー記録（再確認の場合）:
- 元の指摘からの差分と再実行した確認:
- 残る未確認:
- 残る影響を受け入れた人:
- 次の行動:
- 担当者:
- 期限または再開条件:
- 判断日:

AIに任せる範囲

AIは、変更一覧の整理、要件と差分の対応候補、処理経路の候補、未確認事項の抽出を補助できます。検査を実行する機能があり、権限で許可されたAIコーディングツールでは、決めたツールによる自動確認も実行できます。

最初は読取りと報告だけを依頼します。修正は別の一件として渡すと、レビュー前後の差分を分けやすくなります。

人は、AIの報告と実際の差分が一致するかを確認します。要件の意味、必須修正、担当者を加える必要性、秘密情報への対応、残る影響、四つの判断は人が決めます。AIに自分の変更を説明、修正、承認まで一括で任せません。

完了条件

次の条件がそろった範囲だけを、レビュー済みとして次の工程へ渡します。

  • 一件の変更目的、受入条件、対象版が固定されている
  • AIへ渡した情報と、AIの権限・実行済み操作を確認した
  • すべての変更と対象外変更を確認した
  • 要件と処理経路を確認した
  • 検証結果を合格、失敗、未実行、該当なしに分けた
  • テスト自体の変更を確認した
  • 依存関係を確認した
  • 利用可能な公開コード一致機能と、表示された一致候補を確認し、検出対象外と残る未確認を記録した
  • 秘密情報、権限、データ、外部作用を確認した
  • 必須修正と未確認を分けた
  • 四つの判断から一つを選んだ
  • 判断理由、担当者、次の行動を記録した

採用した変更は、レビュー記録と対象版を本番公開前の確認へ渡します。修正する場合は、修正内容と再確認項目を一件の実装タスクへ戻します。保留または要件・設計へ戻す場合は、判断が終わるまで公開候補にしません。

レビュー中に、処理の実行場所、ブラウザへ届くデータ、共有キャッシュの条件を説明できない場合は、SSR・CSR・SSG・ISRの選び方へ戻って判断票を作ります。

出典