· updated

【現場プロンプト】AI コードレビュー｜実戦5型 PR・差分・全文

PR レビューに毎週何時間も取られて、本来やりたい設計や顧客対応の時間が削られていませんか。社内コードの機密性、ツール乱立、プロンプトの作法——足踏みする論点が多すぎる領域でもあります。実際、ラッコキーワードの実測（2026 年 5 月時点）でも「AI コードレビュー」は月 390 人が検索しており、12 ヶ月で +196% の伸び方をしている領域です。私自身、Claude Code・Cursor・GitHub Copilot の 3 ツールを業務で毎日叩いており、社内の AI 活用推進では「コードレビューが最も実感を持てた領域」でした。

結論から言うと、AI コードレビューは「人間の最終チェックを外さない前提で」プロンプトとツールを使い分けるのが筋です。本記事では実戦プロンプト 5 型、主要 7 ツール、ローカル LLM、無料の始め方、チーム導入、全社推進、非エンジニア 5 ユースケースまで、現役の生成AIエンジニア視点で整理します。

とりあえず最短で 1 回試したい方は、プロンプト集と無料で始める手順から読み始めると、本日中に「最初の一歩」が踏めます。

AI コードレビューの基礎｜結論の分業構造・得意/不得意の地図

結論：人間の最終チェックを外さず、プロンプトとツールを使い分ける

AI コードレビューとは、LLM（ChatGPT や Claude などの言語予測装置。詳しくは LLM とは）にコードを読ませ、型・命名・論理・セキュリティ・可読性などの観点で指摘を書かせる行為です。営業時代の提案書を、先輩に渡す前に下読みしてもらう感覚に近いものです。

結論は「人間の最終チェックを外さない前提で、プロンプトとツールを使い分ける」——これが、Claude Code・Cursor・GitHub Copilot の 3 ツールを毎日叩き、社内で AI 活用を全社推進している私の、いちばん実用的な答えです。新製品が出てきても、まず次の 3 レイヤーのどこに住む道具かを確かめれば置き場所に迷いません。

  • プロンプト型 ＝ チャット画面に変更点や全文を貼って指示する基本形（Claude.ai / ChatGPT / Gemini チャット）
  • ツール型 ＝ エディタや GitHub に統合された専用レビュー機能（Cursor / Copilot Reviewer / CodeRabbit）
  • エージェント型 ＝ リポジトリ単位で自走する自律レビュー（Claude Code、Cursor Agent、Devin）

私の立ち位置も先に明かします。Claude Code ／ Cursor（MCP 含む）／ GitHub Copilot の 3 ツールは業務で毎日叩いて常用、CodeRabbit ／ Greptile ／ Devin ／ Aider の 4 ツールは本番未使用（手元で試した範囲）です。SERP 上位は「10 選」横並びが多いのですが、本記事は両者の関わり方を書き分けます。

なお AI コードレビューは人間レビューを完全に置き換える道具ではありません。AI が得意な形式知（型・命名・論理・セキュリティ・可読性）と、人間が判断する領域（ドメイン理解・チーム文化・曖昧仕様・最終承認）は別物で、マージは人間が責任を持つ運用が業界標準です（出典：末尾「出典」、GitHub 公式ブログ）。本記事は「絶対 X 倍速くなる／絶対ツール A が一番」とは言いません。判断軸は 2026 年 5 月時点の業務観察と公式情報がベースで、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて弁護士の方へ。本記事は親ハブ AI コーディングとは の BOFU スポーク（コードレビュー専門深掘り）です。

できること 5 つ・できないこと 3 つ｜AI と人間の分業マップ

ツール選びの前に、AI が「何ができて、何ができないか」を正直に整理します。

AI が得意な 5 領域（型・命名・論理・セキュリティ・可読性）

AI コードレビューがコンスタントに価値を出す領域は 5 つあります。

  1. 型（types）：型注釈の欠落、誤った型指定、Optional の扱いの抜け
  2. 命名（naming）：変数名・関数名・クラス名のチームルール違反、誤解を招く命名
  3. 論理（logic）：明らかな off-by-one エラー、null チェック忘れ、早期 return の欠落
  4. セキュリティ（security）：SQL インジェクション、XSS、ハードコードされた秘密情報、未エスケープのユーザー入力
  5. 可読性（readability）：1 関数が長すぎる、ネストが深すぎる、コメントとコードの食い違い

この 5 領域はすべて 「形式知化しやすい観点」 で、答えが比較的はっきりしておりコード本体だけ見れば判定できます。テキスト処理に強い LLM が淡々と「気になる箇所を 10 個」返してくれる体験は、業務で何度経験しても助かります。商談トークの台本を先輩に渡し、誤字・敬語の崩れ・矛盾を拾ってもらう感覚に近いものです。

AI が苦手な 3 領域（ドメイン理解・チーム文化・曖昧仕様）

逆に、AI がコンスタントに苦手な領域も 3 つあります。

  1. 業務ドメイン理解：「この銀行の与信判断ロジックは、この業界特有の慣習が前提です」「この医療システムは、HL7 FHIR の解釈がチーム独自です」のような領域
  2. チーム文化との整合：「うちのチームは、Service レイヤーをこう使い分けています」「テストファイルの命名はこの慣習で運用してきました」のような領域
  3. 曖昧仕様の解釈：「お客様の要望が変わった、この PR の意図は変更されている」「設計レビューの結論が、コード化されているか確認したい」のような領域

いずれも コードだけ読んでも答えが出ない領域 です。業務の慣習・チームの歴史・議事録・お客様との会話という「コードに書かれていない文脈」を持つ人にしか判断できない。「AI が全部やってくれる」という想定で運用すると、必ずこの 3 領域でつまずきます。

人間レビューとの分業マップ

ここまでをまとめると、AI と人間の分業は次のように整理できます。

  • AI に任せる（一次レビュー）：型・命名・論理・セキュリティ・可読性の機械的チェック → 速さで人間を凌駕する
  • 人間が判断する（最終レビュー）：ドメイン理解・チーム文化・曖昧仕様・最終承認 → AI に渡せない領域
  • 両者で重ね合わせる（中間）：テスト網羅性・パフォーマンス・依存ライブラリの妥当性 → AI が叩き台、人間が裁定

私自身、PR レビューの最初の 5 分は AI に「型・命名・論理・セキュリティ・可読性で気になる箇所を 10 個」と頼んで叩き台を出させ、残りの時間で「ドメインとチーム文化の観点で本当に大丈夫か」を自分の目で見ています。この「AI 一次 + 人間最終」の構造が、以降の章の前提です。

ツール選定と実践｜7 ツール俯瞰・選び方・プロンプト集・無料/ローカル

主要 7 ツール俯瞰｜業務常用 3 ツール vs 公開情報整理 4 ツール

主要 7 ツールを 業務で常用している 3 ツール と 本番では使っていない 4 ツール に分けて並べます。関わり方をはっきりさせておくと、読み手が判断しやすいはずです。

業務常用 3 ツール——Claude Code / Cursor / GitHub Copilot

私が業務で毎日叩いて常用している AI コードレビュー兼支援ツールは、Claude Code・Cursor・GitHub Copilot の 3 つです。

Claude Code（Anthropic 公式の CLI 型エージェント） は、ターミナルから claude で起動し、フォルダ単位で対話・自走作業を依頼できます。@変更ファイル で差分を渡し「型・命名・論理・セキュリティ・可読性で気になる 10 箇所」と頼むスタイルが定着。設定ファイル CLAUDE.md でリポジトリのルール・前提を渡せ、プロンプトのテンプレ化と相性がよいです（Claude Code 使い方・始め方）。

Cursor（VS Code ベースの AI 統合エディタ） は、チャット・補完・差分レビューを 1 画面に集約。Cursor Rules でリポジトリ固有ルールを渡せる仕組みは CLAUDE.md と思想が近い。書きながら気になった差分をその場でチャットに投げる運用が定着しています。Cursor MCP（Model Context Protocol）経由で GitHub / Postgres / Slack などを参考データとして渡せるのも便利です（Cursor 使い方）。

GitHub Copilot は、エディタ補完・Copilot Chat・Copilot Code Review を含む統合製品です。補完で次の数行を予測、Chat で数十行を点検、という使い方を日常的にしています。Copilot Code Review（PR 自動レビュー）は組織契約プランで利用範囲が変わるため、最新の機能・料金は GitHub 公式（github.com/features/copilot）で事前確認を。

私なりの使い分け：

  • Claude Code ＝ ターミナルでフォルダ単位の自走レビュー（夜中・週末の大きめリファクタリング）
  • Cursor ＝ 書きながらその場でチャットレビュー（業務時間中の小さな差分の即時点検）
  • GitHub Copilot ＝ エディタ補完＋数十行の説明（予測補完と簡単な相談）

チーム規模・言語・レビュー文化で振れるので、あくまで個人の運用例としてご参照ください。

公式情報で整理する 4 ツール——CodeRabbit / Greptile / Devin / Aider

ここからは 本番では使っていない 4 ツール です。公式情報・短時間の手元検証・周囲の話をもとに、3 ツールとは書き分けて紹介します。

  • CodeRabbit——GitHub / GitLab の PR に自動でレビューコメントを書き込む SaaS。OSS 向け Free tier あり。コードベース全体を読み込んで観点コメントを構造化して返す設計のようで、「叩き台を Bot に作らせる」運用と相性がよさそうです（公式：coderabbit.ai）。
  • Greptile——リポジトリ全体を理解した上で PR レビューする SaaS。コードベースのグラフを内部構築し、PR の影響範囲を AI に渡してからレビューさせるアプローチとの紹介を見かけます。コードベース理解が強み（公式：greptile.com）。
  • Devin——Cognition Labs の自律型コーディングエージェント。実装・テスト・PR 作成までを担当範囲とする「もっと広いエージェント」。レビュー単体での費用対効果はユースケース次第、というのが公開情報を見た印象です（公式：devin.ai）。
  • Aider——ローカル LLM 連携が特徴の CLI 型 OSS。Claude Code に思想が近く、ローカル LLM で動かしたい個人開発者向けの選択肢、というのが私の理解です。

7 ツール比較表（料金感・統合先・PR / 差分 / 全文型の対応）

7 ツールの俯瞰です。料金は必ず公式で確認してください。数字は 2026 年 5 月時点の概観目安です。

ツール私の使用状況統合先PR レビュー型差分型全文型料金感（2026/5 時点目安）
Claude Code業務で常用ターミナル / CLAUDE.md◎◎◎Pro $20/月 〜
Cursor業務で常用エディタ / Cursor Rules○◎○Hobby 無料 / Pro $20/月 〜
GitHub Copilot業務で常用エディタ / GitHub PR◎◎△OSS Free / Pro $10/月 〜
CodeRabbit本番では未使用GitHub PR◎◎○OSS Free / 有料プランあり
Greptile本番では未使用GitHub PR◎○◎有料
Devin本番では未使用独立 UI○△◎月額固定（高額帯）
Aider本番では未使用ターミナル / OSS○◎○OSS（LLM API 別）

「◎・○・△」は公式情報や手元検証をもとにした私なりの印象です。コードベース・言語・運用文化で振れるので、「ツールを選ぶ前の地図」としてご参照ください。

ツールの選び方｜機密性・統合先・料金など 5 つの判断軸

ツール選定の判断軸は 5 つ。個人開発・5-10 人チーム・全社展開で軸が変わります。

  • 機密性（最優先）——社内コードを外部 SaaS（CodeRabbit / Greptile 等）に送れるか。送れない金融・医療・公共系なら、AWS Bedrock 経由 Claude / Google Vertex AI 経由 Gemini / ローカル LLM（Ollama + Code Llama / DeepSeek Coder 等）が候補です（ローカル LLM・AWS Bedrock）。
  • 統合先——エディタなら Cursor / Copilot、ターミナル/フォルダ単位なら Claude Code / Aider、GitHub PR 自動コメントなら CodeRabbit / Greptile / Copilot Code Review。既存のレビュー文化に合わせて選びます。
  • 料金——個人の月数千円ならどれでも収まります。5-10 人なら Cursor Pro / Copilot Business / Claude Pro のシート単価合算、全社ならボリュームディスカウントや Bedrock 従量課金の合算が判断材料に（Claude 料金プラン、最新は公式で確認）。
  • 言語対応——主要言語（Python / TypeScript / Go / Java / Ruby / Rust / C# 等）はどのツールも及第点以上。社内 DSL や COBOL / Fortran / PL/SQL 等のレガシーになると得意・不得意が出ます。
  • チーム規模——個人は無料枠で十分。5-10 人は Cursor Rules / CLAUDE.md / プロンプト集の共有・更新が論点に。全社はガバナンス・計測・ガイドライン・教育という別軸が立ち上がります（チーム導入・全社推進）。

実戦プロンプト集 5 型｜PR / 差分 / 全文 / セキュリティ / パフォーマンス

本記事のいちばん厚い章です。業務で使う 5 型のプロンプトテンプレート をコード例つきで整理します。コード片はすべて抽象化レベル 2（業務固有名を出さない仮想例）です。Cursor Rules（Cursor の設定ファイル）／CLAUDE.md（Claude Code が起動時に読むルール集）／OWASP Top 10（Web セキュリティリスクの代表 10 種）が前提語です。

すべての型に共通するコツが 4 つあります。

  1. リポジトリの前提を先に伝える（言語・フレームワーク・チーム規約）
  2. レビュー観点を明示する（型 / 命名 / 論理 / セキュリティ / 可読性 のどれか、複数可）
  3. 出力フォーマットを指定する（重要度 High / Medium / Low の 3 段階、観点別 1 行 1 指摘など）
  4. Cursor Rules や CLAUDE.md にテンプレ化して使い回す（毎回ゼロから書かない）

この 4 つを意識するだけで、返答の質が体感で大きく変わります。商談前に「会社情報・議事録・想定論点」を整理してから先輩に同席依頼を出すのと同じ作法です。

PR レビュー型プロンプト（全体俯瞰）

PR（Pull Request）全体を俯瞰してもらう型です。「変更の意図と影響範囲」を最初に AI に把握させるのがコツ。

# あなたの役割
あなたはこのリポジトリのシニアエンジニアです。これからお渡しする Pull Request を、
以下のルールに従ってレビューしてください。

# リポジトリ前提
- 言語：TypeScript（Node.js 20）
- フレームワーク：Next.js 14 + Prisma
- チーム規約：CLAUDE.md / Cursor Rules を参照

# レビュー観点（優先順）
1. 型の整合性（Optional / Nullable の扱い）
2. 命名規約（チーム規約に準拠しているか）
3. 論理エラー（off-by-one / null チェック忘れ等）
4. セキュリティ（OWASP Top 10 の観点）
5. 可読性（関数長・ネスト・コメントの整合）

# 出力フォーマット
- 重要度 High / Medium / Low の 3 段階で分類
- 各指摘は「ファイル名:行番号 / 観点 / 一文の指摘 / 修正案」の 4 要素
- 最後に「人間が必ず確認すべき箇所」を別枠で 3 つ列挙

# Pull Request
（ここに差分または変更ファイル全文を貼り付け）

このテンプレートを CLAUDE.md に置いておくと、@CLAUDE.md PR レビューお願いします と頼むだけで毎回安定した観点で返ってきます。

差分指摘型プロンプト（変更行に絞る）

差分（diff）に絞ったレビュー が欲しいときの型です。レビュー時間が限られているとき・大規模 PR の一部だけ見てほしいときに使います。

# あなたの役割
あなたはこのリポジトリのシニアエンジニアです。これからお渡しする差分を、
変更行のみに焦点を絞ってレビューしてください。

# レビュー観点
- 変更行で導入されたバグの可能性
- 変更行と既存コードの整合性（呼び出し元・呼び出し先への影響）
- 変更行のテストカバレッジ（不足していないか）

# 出力フォーマット
- 「変更行番号 / 一文の指摘 / 影響範囲」の 3 要素
- 指摘がない行はスキップして OK
- 最後に「テストが不足している領域」を 1〜3 個に絞って提示

# 差分（git diff の出力を貼り付け）
（ここに git diff の出力を貼る）

Cursor のチャットで叩くと、エディタ上の差分に即時返答が得られます。差分が 100-300 行程度のときに最も効果が高い印象です。

全文レビュー型プロンプト（新規ファイル向け）

新規追加・丸ごとリファクタリングしたファイルを 全文レビュー にかけたいときの型です。

# あなたの役割
あなたはこのリポジトリのシニアエンジニアです。これからお渡しするファイルを、
新規ファイルとして全文レビューしてください。

# レビュー観点
1. 単一責任原則の遵守（関数・クラスが 1 つの責務に絞られているか）
2. 命名（変数名・関数名が意図を表しているか）
3. テスト容易性（依存注入・副作用の局所化）
4. 既存リポジトリとの整合（類似機能の重複がないか）

# 出力フォーマット
- リファクタリング推奨箇所を「Before / After」コード片で 3〜5 つ提案
- 既存リポジトリにある類似機能を推測し、ファイル名候補を 3 つ挙げる

# 対象ファイル
（ここにファイル全文を貼る）

Claude Code でフォルダ単位に叩く運用と相性がよく、@新規ファイルパス と @CLAUDE.md を組み合わせてリポジトリの文脈ごと渡せます。

セキュリティ特化型プロンプト（脆弱性検出）

OWASP Top 10 の観点で セキュリティ特化 のレビューをかける型です。Web アプリの新機能を出す前のセルフチェックに有効。

# あなたの役割
あなたはセキュリティエンジニアです。これからお渡しするコードに対して、
OWASP Top 10（2021 年版）の観点で脆弱性を点検してください。

# 点検観点（OWASP Top 10 から該当しそうなものを優先）
- A01: 認可制御の不備（Broken Access Control）
- A02: 暗号化の不備（Cryptographic Failures）
- A03: インジェクション（SQL / NoSQL / コマンド）
- A07: 認証の不備（Identification and Authentication Failures）
- A09: ログ・モニタリング不足

# 出力フォーマット
- 検出した脆弱性を「OWASP カテゴリ / 該当行 / 一文の説明 / 修正案コード片」の 4 要素で
- 重要度 High / Medium / Low の 3 段階
- 「人間のセキュリティ担当者に必ず再確認すべき箇所」を別枠で列挙

# 対象コード
（ここに対象コードを貼る）

AI の脆弱性検出は 「叩き台」 にすぎません。見落としも誤検知も確実にあるため、リリース判断は必ず社内のセキュリティ担当者・必要に応じて第三者診断ベンダーの確認を経てください。

パフォーマンス特化型プロンプト（実行速度・メモリ）

ボトルネック調査のための パフォーマンス特化 レビューの型です。

# あなたの役割
あなたはパフォーマンスエンジニアです。これからお渡しするコードに対して、
実行速度・メモリ使用量の観点でボトルネック候補を抽出してください。

# 点検観点
- N+1 クエリ（DB アクセス回数の不必要な増加）
- ループ内の重い処理（API 呼び出し、ファイル I/O）
- メモリリーク候補（クロージャ・グローバル変数）
- 不要な同期処理（並列化の余地）

# 出力フォーマット
- ボトルネック候補を「該当行 / 想定される影響 / 改善案」の 3 要素で
- 影響度 High / Medium / Low の 3 段階
- 改善案は「概算でどの程度速くなるか」の仮説も併記
- 「実測しないと判断できない箇所」を別枠で 3 つ挙げる

# 対象コード
（ここに対象コードを貼る）

パフォーマンスは 「実測こそ正義」 の領域です。AI の推測は方向性として参考にしつつ、必ず実測（プロファイラ・ベンチマーク）で裏取りを。

プロンプトを Cursor Rules / CLAUDE.md にテンプレ化する運用

5 型を 毎回ゼロから書かない のが定着の鍵です。私は CLAUDE.md に次のセクションを置いています。

## レビュー用プロンプト集

### PR レビュー型
（05-1 のテンプレ全文）

### 差分指摘型
（05-2 のテンプレ全文）

### 全文レビュー型
（05-3 のテンプレ全文）

### セキュリティ特化型
（05-4 のテンプレ全文）

### パフォーマンス特化型
（05-5 のテンプレ全文）

起動時に CLAUDE.md が自動で読まれるため、PR レビューしてください、@変更ファイル.ts と書くだけでテンプレが裏で適用されます。Cursor では .cursor/rules/review-prompts.md のような分割ファイルが落ち着きました。5-10 人チームでは プロンプト集をリポジトリに共有し全員が同じ観点でレビューできる のが大きな利点です。

無料で始める方法｜5 ツールの Free tier と最初の 30 分

「まず無料で 1 回試したい」方向けに、Free tier の境界線と最初の 30 分の動線を整理します。料金・無料枠の条件は時期で変動するため、必ず公式で確認してください。

無料で試せる 5 ツールの境界線（2026 年 5 月時点目安）

  • Claude.ai Free：Anthropic 公式チャット。回数制限あり。コードレビューの「とりあえず触ってみる」用途には十分（claude.ai）
  • Cursor Hobby（無料プラン）：Cursor の無料プラン。エディタ補完・チャット回数制限あり（cursor.com）
  • GitHub Copilot Free（OSS / 学生 / 教員向け）：OSS リポジトリ・学生・教員には Free プランあり（github.com/features/copilot）
  • Claude Code 新規無料クレジット：新規ユーザーへの初期クレジット付与（最新は anthropic.com で要確認）
  • CodeRabbit OSS 向け Free tier：OSS リポジトリには Free 利用枠あり（coderabbit.ai）

境界線は公式で必ず最新を確認してください。

最初の 30 分動線（Cursor で 1 PR レビュー試す手順）

Cursor を例にした動線です（Claude.ai / Claude Code でも近い手順で試せます）。

  1. 0-5 分：cursor.com から Cursor をダウンロード・インストール、Hobby プランで登録
  2. 5-10 分：適当な OSS リポジトリ（または練習用リポジトリ）を Cursor で開く
  3. 10-15 分：ファイルを開き、Cmd + L（Mac）でチャットを開く
  4. 15-20 分：PR レビュー型プロンプトを貼り付け、最後に対象ファイル全文を貼る
  5. 20-30 分：返ってきた指摘を High / Medium / Low で 1 件ずつ吟味し、同意するか判断

ここまで来れば AI コードレビューの 第一歩 です。

無料 → 有料に踏み出すタイミング

無料枠で 1〜2 週間試して、次のいずれかを感じたら有料プランを検討してよいと思います。

  • 回数制限に毎日当たる（チャット回数・補完回数の上限に届く）
  • 応答モデルの精度に物足りなさを感じる（無料プランのモデルは精度が下がる場合あり）
  • PR レビューの定型運用に組み込みたい（業務時間中の安定運用には有料プランが落ち着く場面が多い）
  • チーム共有が必要になる（チーム機能・組織アカウントは有料プランで提供されることが多い）

私は Claude Pro / Cursor Pro / GitHub Copilot を併用しています（Claude 料金プラン）。

ローカル LLM｜社内コードを外部に出せない場合の選択肢

「社内コードを外部 SaaS に送りたくない」「金融・医療・公共系で機密性が厳しい」方向けに、ローカル LLM の選択肢を整理します。Ollama（ローカルで LLM を動かす OSS ランタイム）／Code Llama（Meta のコード特化 LLM）／DeepSeek Coder（日本語コメントにも比較的強いコード特化 LLM）／量子化（モデルの軽量版変換）が前提語です。

前提：ローカル LLM は手元で試した範囲で触っており本番では使っていません。本格導入時は社内情シス・法務・コンプラ部門の事前確認と、OSS LLM の最新動向の公式確認を必ず。

なぜローカル LLM か（プライバシー・コスト・学習目的）

主な動機は 3 つあります。

  1. プライバシー / 機密性：社内コードを外部に送らない運用。金融・医療・公共・防衛系で必須となる場面
  2. コスト：API 従量課金を避けたい。長期・大量利用で API コストが膨らむ場合の代替
  3. 学習目的：LLM の中身を触って理解したい、量子化・ファインチューニングを試したい

逆に、現時点で 苦手 な領域もあります。

  • モデル精度：フロンティアモデル（Claude Opus / GPT-4 系列 / Gemini Ultra 等）と比べると精度が下がる場面がある
  • 運用負担：GPU マシン・量子化済みモデルの管理・アップデート対応の工数が大きい
  • 応答速度：ローカル GPU 性能依存で、最新 API より速度・スループットが劣る場面が多い

Ollama で Code Llama を動かす最小手順（Mac M シリーズ前提）

個人検証で試した最小手順です。本番推奨ではなく 感触を掴むための最小動線 としてご覧ください。

# 1. Ollama を Mac にインストール（Homebrew 経由）
brew install ollama

# 2. Ollama サーバーを起動
ollama serve &

# 3. Code Llama 7B（量子化版）をダウンロード
ollama pull codellama:7b

# 4. 簡単なコードレビューを試す（標準入力経由）
cat << 'PROMPT' | ollama run codellama:7b
あなたはシニアエンジニアです。次の TypeScript コードを、
型・命名・論理の 3 観点でレビューしてください。

function getUser(id) {
  const user = db.users.find(u => u.id == id);
  return user;
}
PROMPT

Mac M シリーズ（M1〜M4）ならメモリ 16GB 以上で 7B モデルは動きます。13B / 34B はメモリ要件・推論速度ともに敷居が上がります。Python から呼ぶ場合は Ollama の REST API（デフォルトポート 11434）か専用クライアントを使います（仕様は ollama.com）。なお、レビューに限らず補完・VSCode（Continue 拡張）連携まで含めた実用度は VSCode×Ollama のローカル LLM コーディングで切り出して整理しています。

業務常用 API（Claude / ChatGPT / Bedrock 経由）への踏み出し

個人検証の感触では、ローカル LLM だけで業務本番を回すのは 2026 年 5 月時点ではまだ運用負担が大きい 印象です。社内コードを外に出せない要件があるなら、次の中間策が現実的です。

  • AWS Bedrock 経由 Claude ＝ IAM・VPC 内通信・監査ログを AWS に集約しつつフロンティアモデルを叩く
  • Google Vertex AI 経由 Gemini ＝ GCP 組織契約配下で Gemini を叩く
  • Azure OpenAI Service ＝ Azure 組織契約配下で GPT 系を叩く

詳しくは AWS Bedrock で扱っています。組織のクラウド契約・コスト・コンプラ要件で振れる領域です。

組織への導入と展開｜チーム 5 ステップ・全社推進の事例

チーム導入の進め方｜試行・ガイドライン・文化・計測・定着化の 5 ステップ

5-10 人チームで導入する 現実的な 5 ステップ を業務体感ベースで整理します（抽象化レベル 2、具体名は出しません）。前提語は パイロット（小規模試行）／CI（変更を自動テストする仕組み。GitHub Actions 等）／ガイドライン（行動規範の明文化）です。

ステップ 1：小さく試す（1 PR で試行）

「全チーム展開」と構えると失敗します。まず 1 人 1 PR が定着します。

  • 自分の手持ち PR を 1 つ選ぶ
  • PR レビュー型プロンプトを叩く
  • 返ってきた指摘を「同意する／しない／ドメイン判断が必要」の 3 つに仕分け
  • 1 週間後に「同意した指摘の比率」を振り返る

最初の 1 ヶ月はこの個人運用を 3〜5 人並列で回し、各自が型を作るのが定着の早道でした。

ステップ 2：ガイドライン整備

個人運用を 1 ヶ月続けたら、チームでガイドラインを 1 ページ書く ステップです。最低限の論点は次の 4 つ。

  1. 機密情報の扱い：何を入力していいか／だめか
  2. 使用ツールの絞り込み：標準を Claude Code / Cursor / Copilot のどれにするか
  3. 人間レビューの責任分担：AI 出力は叩き台、最終判断は人間と明文化
  4. プロンプト集の置き場所：CLAUDE.md / Cursor Rules / Wiki のどこか

教訓は 「5 ページ以上書くと誰も読まない」。1 ページ・5 項目以内が定着のコツです。

ステップ 3：レビュー文化との混ぜ方

既存の人間レビュー文化を消してはいけません。分業を明確にするのが定着の鍵です。

  • PR 作成者：AI に一次レビューをかけ、ほぼ全件を一度通読してから人間レビューに出す
  • 人間レビュアー：ドメイン・チーム文化・最終承認に集中（形式観点は最低限）
  • CI：自動テストとリンターで別軸の検証を回す

「AI が一次、人間が最終、CI が並行」の 3 層構造だと、工数削減と品質底上げが両立しやすいです。

ステップ 4：効果計測の論点

「本当に効率が上がったのか」を 数字で語りたい 場面が必ず来ます。計測軸の例：PR レビュー所要時間（導入前後）／merge までのリードタイム／本番障害件数・重大度（数ヶ月比較）／チームメンバーの満足度アンケート。

ただしこれらを「絶対 X 倍速くなった」と対外発信するのは慎重に。AI 導入以外の要素も同時に変化しており、社内向けの「感触の共有」に留める方が誠実です。

ステップ 5：定着化の落とし穴

導入 3〜6 ヶ月で直面しやすい落とし穴が 4 つ。

  1. プロンプトが古びる：ライブラリ更新・規約変更で CLAUDE.md が現実とズレる
  2. AI 出力の通読省略：慣れて指摘を読み流す（最大のアンチパターン）
  3. ガイドライン違反の常態化：機密情報の入力が散発する
  4. 無料枠依存のリスク：個人の無料プラン使い回しが組織コンプラ違反に

「ガイドラインを四半期に 1 回更新」「月 1 の振り返り会」「組織契約の有料プラン」で予防できます。

全社推進の事例｜コードレビューが最も実感を持てた理由と 5 ステップ

私が AI 活用を全社推進した経験から、「なぜコードレビューが最も実感を持てた領域だったか」 を紹介します（抽象化レベル 2、社名・業界名は出しません）。

なぜコードレビューが「最も実感を持てた領域」だったか

5 領域（議事録 / 資料作成 / 社内 RAG / コードレビュー / 非エンジニア展開）を並行推進したとき、コードレビューがいちばん底上げを体感できた 領域でした。理由は 3 つ。

  1. 観点が形式知化しやすい：型・命名・セキュリティは正解／不正解がコードで判定しやすい
  2. 既存の PR レビュー文化と接続しやすい：「もう 1 人のレビュアー」として組み込むだけで定着する
  3. 効果が見える：PR ごとに指摘件数・採用件数を数えれば感触が言語化できる

議事録や資料作成は「整って見える」という主観が中心ですが、コードレビューは「脆弱性を AI が拾った」「型エラーが減った」のように開発者が腹に落ちる場面が多いです。

全社推進 5 ステップ（型としての事例）

  • ステップ 1：パイロット選定——AI 親和性の高い 1 チームを選ぶ（技術導入に前向き、PR レビュー文化があり、リーダーが協力的）。最初から全展開しない。
  • ステップ 2：勝ち筋共有——1 ヶ月後、うまくいったプロンプト・ツール設定・運用ルールを Wiki / Notion / Slack でドキュメント化。
  • ステップ 3：非エンジニア部門への展開——隣接領域（議事録要約・資料作成・RAG 検索）への展開を並行し「会社全体で AI を使う雰囲気」を醸成（AI 業務効率化 事例）。
  • ステップ 4：効果計測——3〜6 ヶ月で所要時間・障害件数・満足度を控えめに計測。対外発信は慎重に。
  • ステップ 5：継続化——四半期に 1 回、ガイドライン更新・プロンプト見直し・新ツール評価会を設ける。AI 領域は半年で景色が変わります。

既公開「業務事例」記事との役割分担

本記事と AI 業務効率化 事例 は役割が違います。

  • 業務事例 記事 ＝ 5 領域（議事録 / 資料作成 / RAG / コードレビュー / 非エンジニア展開）× 5 職種の 俯瞰マトリクス
  • 本記事 ＝ コードレビュー 専門深掘り（プロンプト集 5 型・主要 7 ツール・ローカル LLM・全社推進 5 ステップ）

全体俯瞰なら業務事例記事へ、コードレビュー深掘りなら本記事へ、という二段構えです。

リスクと安全運用｜5 リスク・三段安全網・失敗 5 パターン

リスクと注意点｜機密性・著作権・品質・スキル・脆弱性と三段安全網

本記事の YMYL 最厚章 です。押さえるべきリスク 5 つと安全網を整理します。記述は業務観察と公式情報がベースで、最終判断は社内の情シス・法務・コンプラ部門、必要に応じて弁護士の方へ。前提語は AI 任せきり（出力をそのままコミットする運用）／プロンプトインジェクション（悪意あるプロンプトで AI を狂わせる攻撃）／BAA（HIPAA 準拠ベンダー利用時の業務委託契約）です。

機密性リスク——社内コードを外部に出す境界線

外部 SaaS（CodeRabbit / Greptile / クラウド API 経由の Claude / ChatGPT 等）に送る場合、何を送ってよく、何を送ってはいけないか を社内ガイドラインで明文化します。

  • 送ってはいけない例：個人情報（PII）／クレジットカード情報／認証トークン／業務秘密のアルゴリズム
  • 慎重に扱う例：顧客固有の業務ロジック／社内 DSL／競合に知られたくない設計判断
  • 比較的安全な例：OSS のコード／一般的なフレームワーク使用例／設定ファイル（秘密情報を除く）

契約・規約・業界規制で振れる領域です。社内法務とよく相談してから運用してください。

著作権リスク——学習データ・出力責任

AI 出力コードの 著作権の扱い はベンダー・モデル・規約で異なります。

  • 入力した自社コードの権利：学習データに使うか。多くは「使用しない」と明記されているが最新規約は要確認
  • 出力コードの権利：第三者の著作物（OSS ライセンス違反コード等）混入時の責任の所在
  • 生成 AI の著作物性：日本の現行法（2026 年 5 月時点）では出力そのものに著作権が認められない場面が多い、というのが文化庁見解の一般的な整理（出典：末尾「出典」、文化庁資料）

最終判断は社内法務・必要に応じて弁護士の方へ。

品質低下リスク——AI 任せきりの危険

AI 出力をそのままコミットする「AI 任せきり」は最大のアンチパターンです。理由は、誤検知（バグでない箇所をバグと指摘）／見落とし（ドメイン・文化・曖昧仕様を拾えない）／ハルシネーション（存在しない関数・API・パッケージ名を断定）の 3 つ。AI 出力は必ず人間が 1 度通読してからコミット に統一しています。

スキル劣化リスク——自分で書けなくなる感覚

「ずっと AI に書かせると自分で書く力が衰える」感覚は私自身も実感しています（AI コーディング の劣化章も参照）。対策は、週に 1 度 AI を使わない時間を作る／AI 出力を必ず通読する／基礎学習を継続する。

脆弱性リスク——AI 生成コードの脆弱性

AI 生成コードに 脆弱性が紛れ込む 場面は確実にあります。入力検証の欠落（ユーザー入力をそのまま SQL / シェル / HTML へ）／古い API の使用／存在しない・タイポされたパッケージ名の提案（プロンプトインジェクションの温床）。対策は AI 出力後に人間レビュー + 静的解析 + 脆弱性スキャン の 3 段重ねです。

三段安全網——人間レビュー必須・公式確認・法務委ね

5 リスクを通底する 三段安全網 を改めて明文化します。

  1. 人間レビュー必須：AI 出力は叩き台、最終判断は人間の責任
  2. 公式情報の事前確認：ライブラリ・モデル・規約・最新リリースは公式で必ず確認
  3. 最終判断は社内法務へ：機密性・著作権・契約・規制の解釈は社内法務、必要に応じて弁護士へ

「AI が便利だからこそ、人間の判断を最後に必ず通す」 という構えが、長く運用する土台になります。

失敗パターン 5 つ｜任せきり・プロンプト雑・スキップ・機密投入・未計測

典型的な失敗 5 パターン と予防策を並べます。

  1. AI 任せきり（最大のアンチパターン）——出力を読まずにコミット（リスク章で詳述）。予防＝通読してからコミットをルール化、PR 説明欄に「AI レビュー受け／通読済み」チェックを置く。
  2. プロンプトが雑——「見てください」だけで投げると質が安定しない。予防＝5 型のプロンプト集を CLAUDE.md / Cursor Rules にテンプレ化。
  3. 人間レビューのスキップ——AI が「大丈夫」と言ったから飛ばす。予防＝AI 一次 + 人間最終 + CI 並行の 3 層構造を崩さない。
  4. 機密情報の投入——社内コード・個人情報・認証トークンを外部 SaaS に投入。予防＝送ってはいけない情報のリスト明文化、.env 等の自動マスク設定、四半期 1 回の研修。
  5. 効果計測の放置——半年経っても「うまくいっているか分からない」。予防＝月 1 の振り返り会、所要時間の週次グラフ化、四半期 1 回の定性アンケート。

実運用ではここに書いていないパターンも出てきます。自分のチームの失敗を四半期に 1 回ドキュメント化して共有する のが近道です。

最初の一歩｜非エンジニアの関わり方・ロール別 7 日プラン

コードが読めなくても、AI に「一次安全チェック」を頼める

「エンジニアではないけど、AI コードレビューに関わる場面はあるのか？」——あります。共有されたコード片を AI に貼って「安全か／明らかな誤りはないか」を一次チェックし、専門家への確認を本当に怪しい箇所だけに絞る という関わり方です。非エンジニアがぶつかる「コードに触れる瞬間」を 3 つ挙げます。

  • 共有された Excel マクロ・スクリプトを開く前に確認——VBA を AI に貼って「不審な動作・外部通信・ファイル書き込みはないか」を一次確認し、情シスへの問い合わせを懸念のある箇所だけに絞れます（ソースは Excel の Alt + F11）。
  • 自分のサイトの埋め込みコードを確認——Google Analytics / SNS シェアボタンのコードを「何をしているか／個人情報の流出懸念はないか」と確認。用語が不安なら「初心者向けに説明して」と頼めば学習も AI 相手にできます。
  • 学習中・記事執筆中のコードを「レビュー師匠」にする——「改善点を初心者向けに 3 つ」「構文的に正しいか」を 24 時間聞けます。ただし 指摘を鵜呑みにせず、最後は自分で動かして確かめる（ハルシネーションがあるため。AI コーディング の学習章も参照）。

共通するのは「AI に渡す前に、何を聞きたいかを 1 行で書く」という作法です。

学習・導入の最初の一歩｜ロール別 7 日プラン

ロール別 7 日プラン——「今週、何をすればいいか」を 1 日ずつに分解しました。

個人開発者の 7 日プラン

  • Day 1：Cursor を cursor.com からダウンロード、Hobby 登録、練習用リポジトリを開く
  • Day 2：PR レビュー型プロンプトを Cursor チャットに貼り、自分のコードを 1 回レビュー
  • Day 3：差分指摘型プロンプトを試す
  • Day 4：セキュリティ特化型プロンプトを試す
  • Day 5：Claude.ai Free を試し、Cursor との返答の違いを実感
  • Day 6：.cursor/rules/ に PR レビュー用プロンプトをテンプレ化
  • Day 7：振り返り（同意した指摘の比率・驚いた指摘・役立たなかった指摘をメモ）

チームリーダーの 7 日プラン

  • Day 1：個人運用を 1〜2 週間先行で試す（上記を圧縮版で）
  • Day 2：チームの 2〜3 人に「個人運用を 1 ヶ月試す」依頼
  • Day 3：最初の 30 分動線をメンバーに共有
  • Day 4：Slack / Notion に試行スレッドを作る
  • Day 5：1 週間後の振り返り会の日程を確保
  • Day 6：CLAUDE.md / Cursor Rules の標準テンプレ案を 1 ページ書く
  • Day 7：感触をヒアリングし、ガイドライン 0.1 版を起案

全社推進担当の 7 日プラン

  • Day 1：エンジニア部門リーダーと「パイロット候補チーム選定」会議
  • Day 2：候補チームリーダーと「3 ヶ月パイロット計画」キックオフ
  • Day 3：情シス・法務に「外部 AI SaaS への入力ガイドライン」相談
  • Day 4：パイロット計画書を 1 ページにまとめ経営層に共有
  • Day 5：使用ツール・プロンプト集・ガイドライン素案を共有
  • Day 6：効果計測の軸を 3 つに絞る（所要時間 / リードタイム / 満足度）
  • Day 7：3 ヶ月後の中間振り返り会の日程を確保

本講座での深掘り誘導

7 日プランで「最初の一歩」は踏めますが、業務本番で定着させ、生成AIエンジニアとして職業転換まで届かせる にはより体系的な学習が必要です。本サイト bon-bon-tools.com では、営業出身の現役生成AIエンジニアが 「未経験から生成AIエンジニアに到達するロードマップ」を扱う本講座 を準備中です（2026 年下期公開予定）。最新情報はトップページからお知らせします。独学・公式ドキュメント・スクール・社内 OJT も有効で、本サイトは「営業出身の一次体験」という独自の角度を提供する選択肢の 1 つです。

よくある質問

Q1: AI コードレビューを導入すれば、人間レビューは不要になりますか？

A. 「絶対不要」とは申し上げません。AI が得意な領域（型・命名・論理・セキュリティ・可読性）と、人間が判断する領域（ドメイン理解・チーム文化・曖昧仕様・最終承認）は明確に違います。「人間の最終チェック」を外さない前提で工数を削減し、品質の底上げを支える道具という整理が正直なところです。詳しくは結論とリスクと注意点を。

Q2: どのツールから始めればいいですか？

A. 「絶対これ」とは申し上げません（個人差・業務差で振れます）。目安は (1) チャット型 AI 未経験なら Claude.ai / ChatGPT 無料版、(2) エディタ統合を試したいなら Cursor Hobby、(3) フォルダ単位なら Claude Code 新規無料クレジット——の順序です。詳しくは7 ツール俯瞰と無料で始める方法を。

Q3: 社内コードを外部に送りたくありません。どうすればいいですか？

A. 主な選択肢は 3 つです：(1) AWS Bedrock 経由 Claude / Google Vertex AI 経由 Gemini など組織契約の AI 基盤、(2) Ollama + Code Llama / DeepSeek Coder などローカル LLM（私は個人検証レベル）、(3) 社内ガイドラインで機密ファイル・個人情報・社外秘ロジックの入力禁止を徹底——の組み合わせです。最終判断は社内の情シス・法務・コンプラ部門へ。詳しくはローカル LLMとリスクと注意点を。

Q4: AI コードレビューのプロンプトはどう書けばいいですか？

A. 本記事の実戦プロンプト集で、PR レビュー型 / 差分指摘型 / 全文レビュー型 / セキュリティ特化型 / パフォーマンス特化型の 5 型を整理しています。共通のコツは (1) リポジトリの前提を先に伝える、(2) レビュー観点を明示する、(3) 出力フォーマットを指定する、(4) Cursor Rules や CLAUDE.md にテンプレ化して使い回す——の 4 つです。

Q5: 無料で AI コードレビューを始められますか？

A. 始められます。無料で始める方法で、Claude.ai Free / Cursor Hobby / GitHub Copilot Free（OSS 向け）/ Claude Code 新規無料クレジット / CodeRabbit OSS 向け Free tier の 5 つを整理しています。料金は変動するため、最新は各公式（anthropic.com / cursor.com / github.com/features/copilot 等）でご確認ください。

訂正・お問い合わせ

本記事の内容に誤り・古い情報・追加情報のご提案などありましたら、send@bon-bon-tools.com までご一報ください。事実誤認は速やかに訂正し、訂正履歴を本セクション末尾に追記する運用です。なお、AI コーディングおよび AI コードレビューに関する公式情報（Anthropic / OpenAI / Google / GitHub / Cursor / AWS の利用規約・料金・モデル仕様等）は、必ず各社の公式ドキュメントをご確認の上、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。

関連記事

出典

新しい記事のお知らせを受け取る → 登録（準備中）