· 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 回試したい方は、セクション 5「実戦プロンプト集 5 型」と セクション 6「無料で始める方法」から読み始めると、本日中に「最初の一歩」が踏めます。

01 — 結論：AI コードレビューは「人間の最終チェック」を外さない前提で、プロンプトとツールを使い分ける

📖 この章で使う用語

  • AI コードレビュー：AI（主に LLM）にコードを読ませて、型・命名・論理・セキュリティ・可読性などの観点で指摘を書かせる行為。「営業時代の提案書を、先輩に渡す前に AI に下読みさせる」イメージ。
  • PR（Pull Request：プルリクエスト）：コード変更を本流に混ぜる前の提案書。「提案書を上長に通す前の決裁稟議」のイメージ。
  • LLM（Large Language Model：大規模言語モデル）：ChatGPT や Claude などの中身を動かす、文章を予測する装置。詳しくは LLM とは で扱っています。

まず結論から書きます。AI コードレビューは 「人間の最終チェックを外さない前提で、プロンプトとツールを使い分けるのが筋」——これが、業務で Claude Code・Cursor・GitHub Copilot の 3 ツールを毎日叩き、社内で AI 活用を全社推進している私の、いちばん実用的な答えです。

3 行で覚えていただきたいのは、次のレイヤー対応です。

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

「迷ったらこの 3 つのレイヤーだけ覚えれば OK」一行マップです。新しい AI コードレビュー製品が出てきても、まず「これは 3 レイヤーのどこに住んでいる道具か」を確かめれば、置き場所に迷わなくなります。

ここで私の立ち位置をお伝えしておきます。本記事で扱う Claude Code ／ Cursor（Cursor MCP 含む）／ GitHub Copilot の 3 ツールは、私が業務で毎日叩いて常用している範囲です。これまでの経験から書きます。一方、CodeRabbit ／ Greptile ／ Devin ／ Aider の 4 ツールは、私の業務では本番運用していません。手元で触った範囲＋公開情報からの概論までに留めて紹介します。SERP（検索結果）上位の記事は「AI コードレビューツール 10 選」を横並びで紹介する形が多いのですが、本記事はそうではなく、「業務で実際に使っている 3 ツール」と「公開情報から整理する 4 ツール」を分けて書く という構造で差別化します。

そしてもう 1 つ、本記事で最初に強くお伝えしたい前提があります。AI コードレビューは、人間レビューを完全に置き換える道具ではありません。私の業務感覚では、AI が得意な領域（型・命名・論理・セキュリティ・可読性のような「形式知化しやすいレビュー観点」）と、人間が判断する領域（業務ドメイン理解・チーム文化・曖昧仕様の解釈・最終承認）は明確に違います。GitHub の公開情報でも、AI 支援開発の利用は世界的に拡大している一方、レビュー結果のマージは人間が責任を持つ運用が前提とされている、というのが業界の標準的な整理です（出典：本記事末尾の「出典」セクション、GitHub 公式ブログをご参照ください）。

最後に重要なメタ宣言を 1 つ。本記事では、「絶対 X 倍速くなる」「絶対バグが減る」「絶対ツール A が一番」とは申し上げません。レビュー工数も品質改善も、コードベース・チーム規模・言語・既存レビュー文化で振れ幅が大きい領域です。本記事の各セクションで述べる判断軸は「2026 年 5 月時点・私の業務観察と公開情報からの整理」であり、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談いただくのが筋です。

なお、本記事は親ハブ記事 AI コーディングとは の BOFU 寄りスポーク として位置づけられます。AI コーディング全体地図は親ハブ、本記事は「コードレビュー専門深掘り」という関係です。

02 — AI コードレビューとは——できること 5 つ、できないこと 3 つ

📖 この章で使う用語

  • 静的解析（static analysis）：プログラムを実行せずに、コードの記述からバグや脆弱性を見つける手法。Lint / ESLint などが代表例。「校正者が文法・誤字を読み込みでチェックする」イメージ。
  • ドメイン理解：その業界・業務特有の事情や慣習の理解。「銀行業界の与信判断ロジック」「医療現場の処方箋の暗黙ルール」など。AI が苦手な領域の代表。
  • 可読性（readability）：コードの読みやすさ。命名・コメント・段落（インデント）・関数の長さなどが関わる。「日報の読みやすさ」と同じ感覚。

ここから、AI コードレビューが 「何ができて、何ができないか」 を最初に正直に整理します。SERP 上位の記事は「ツールを並べて推す」形が多いのですが、私の業務感覚では、ツール選びの前に「AI が得意な領域と苦手な領域」を読者の方に共有しておくのが、いちばん遠回りに見えて近道だと思っています。

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

私の業務観察で、AI コードレビューがコンスタントに価値を出してくれる領域は 5 つあります。

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

なぜこの 5 領域が AI と相性がいいのか、というと、すべて 「形式知化しやすい観点」 だからです。「型は揃っていますか？」「変数名は意図を表していますか？」「SQL インジェクションになっていますか？」——こうした問いは答えが比較的はっきりしており、コード本体だけ見れば判定できます。LLM はテキスト処理に強いので、こうした観点で AI が淡々と「気になる箇所を 10 個並べてください」と返してくれる体験は、業務で何度経験しても助かります。

営業時代のたとえで書くと、これは 「先輩に商談トークの台本を渡して、誤字脱字・敬語の崩れ・矛盾を 10 個指摘してもらう」 感覚に近いです。先輩は商談の中身（案件の本質）には踏み込まず、台本そのものの粗を素早く拾ってくれる。それと同じく、AI コードレビューは「コードそのものの粗」を素早く拾ってくれる相棒です。

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

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

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

なぜ AI がここを苦手とするか、というと、コードだけ読んでも答えが出ない領域 だからです。業務の慣習、チームの歴史、最近の議事録、お客様との会話——こうした「コードに書かれていない文脈」を持っている人にしか判断できない。

これは別に AI の限界を貶めたいのではなく、「AI に渡す前に、人間が押さえておくべき判断領域」 を読者の方に共有したいからです。「AI が全部やってくれる」という想定で運用すると、必ずこの 3 領域でつまずきます。

02-3. 人間レビューとの分業マップ

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

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

私自身、PR レビューの最初の 5 分は AI に「型・命名・論理・セキュリティ・可読性の観点で気になる箇所を 10 個」と頼んで叩き台を出させ、残りの時間で「ドメインとチーム文化の観点で本当に大丈夫か」を自分の目で見る——という運用で回しています。この「AI 一次 + 人間最終」の分業構造を、本記事の他のセクションでも前提にして読み進めていただけると、後の章が一段と腹に落ちます。

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

📖 この章で使う用語

  • Cursor：VS Code ベースの AI 統合エディタ。チャット・補完・PR レビュー支援を 1 画面に集約。詳しくは Cursor 使い方 で扱っています。
  • Claude Code：Anthropic 公式の CLI 型コーディングエージェント。フォルダ単位で自走作業を依頼できる。詳しくは Claude Code 使い方 で扱っています。
  • GitHub Copilot：GitHub / Microsoft の AI コード支援サービス。エディタ補完・Copilot Chat・Copilot Code Review などを含む統合製品。
  • CodeRabbit：GitHub / GitLab の PR に自動でレビューコメントを書き込む SaaS。OSS 向け Free tier あり。
  • Greptile：リポジトリ全体を理解した上で PR レビューする SaaS。コードベース理解が強み。

ここでは、AI コードレビュー文脈でよく挙がる主要 7 ツールを 「私が業務で常用している 3 ツール」 と 「公開情報からの整理レベルにとどめる 4 ツール」 に分けて並べます。冒頭で立ち位置を明示するのは、SERP 上位の「10 選羅列」型との明確な差別化です。

03-1. 業務常用 3 ツール——Claude Code / Cursor / GitHub Copilot

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

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

Cursor（VS Code ベースの AI 統合エディタ） は、エディタ画面でチャット・補完・差分レビューを 1 画面に集約できるのが強みです。Cursor Rules という設定ファイルでリポジトリ固有のルールを AI に渡せる仕組みは、Claude Code の CLAUDE.md と思想が近い。私の運用では、書きながら気になった差分をその場でチャットに投げて、レビュー観点を 5 つほど返してもらう スタイルが定着しています。Cursor MCP（Model Context Protocol）を業務でセットアップしており、GitHub / Postgres / Slack / 自作 MCP などの外部リソースをレビューの参考データとして渡せるのも便利です。詳しくは Cursor 使い方 をご参照ください。

GitHub Copilot は、エディタ補完・Copilot Chat・Copilot Code Review などを含む統合製品です。私の業務では、エディタ補完を「書きながら次の数行を予測してもらう用途」、Copilot Chat を「書いた数十行をその場で説明・点検してもらう用途」で日常的に叩いています。Copilot Code Review（PR への自動レビューコメント機能）は、組織契約のプランで利用範囲が変わるため、最新の機能・料金は GitHub 公式（github.com/features/copilot）で必ず事前確認してから運用判断していただくのが安全です。

3 ツールの私なりの使い分けは、こうです：

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

「絶対この使い分けがベスト」とは申し上げません。チーム規模・言語・既存のレビュー文化で振れ幅が大きいので、これはあくまで「業務で 3 つを毎日叩いている個人の運用例」としてご参照ください。

03-2. 公開情報からの整理 4 ツール——CodeRabbit / Greptile / Devin / Aider

ここからは、私の業務では本番運用していない 4 ツール です。公開情報・短時間の手元検証・知人の話を総合した概論レベルでご紹介します。SERP 上位の記事と違って、温度感をはっきり分けて書く理由は、読者の方が「執筆者がどこまで業務で触っているか」を判定する材料を持てるようにするためです。

CodeRabbit——GitHub / GitLab の Pull Request に自動でレビューコメントを書き込む SaaS です。OSS 向け Free tier の提供があり、GitHub の PR を作るとコメントが自動で付くタイプの製品として知られています。公開情報を見る限り、コードベース全体を読み込んで観点コメントを構造化して返す設計のようで、PR レビューの「叩き台を Bot に作らせる」運用と相性がよさそうです。最新の料金・機能は公式（coderabbit.ai）で必ず事前にご確認ください。

Greptile——リポジトリ全体を理解した上で PR レビューを行う SaaS として登場した製品です。公開情報を見る限り、コードベース全体のグラフを内部で構築して、PR の影響範囲を AI に渡してからレビューさせるアプローチを取っているとの紹介を見かけます。コードベース理解が強みとされている方向の製品です。最新の機能は公式（greptile.com）で必ず事前にご確認ください。

Devin——Cognition Labs が公開している自律型コーディングエージェントです。コードレビューだけでなく、フォルダ単位の実装・テスト・PR 作成までを担当範囲とする「もっと広いエージェント」として位置づけられています。コードレビュー単体での費用対効果は、ユースケースによって振れ幅が大きそうだ、というのが公開情報を見た上での私の印象です。最新の機能・料金は公式（devin.ai）でご確認ください。

Aider——CLI ベースのコーディング AI で、ローカル LLM 連携にも対応していることが特徴として知られている OSS です。Claude Code に思想が近く、ローカル LLM で動かしたい層から支持を受けているという公開情報をよく目にします。コードレビュー単体目的というよりは、ローカル LLM + コード生成を試したい個人開発者向けの選択肢、というのが私の理解です。

03-3. 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 別）

「◎・○・△」は私の公開情報からの整理ベースの印象です。「絶対この評価が正しい」とは申し上げません——コードベース・言語・運用文化で振れ幅が大きい領域です。本表は「ツールを選ぶ前の地図」としてご参照ください。

04 — ツールの選び方——5 つの判断軸（機密性 / 統合先 / 料金 / 言語対応 / チーム規模）

📖 この章で使う用語

  • VPC（Virtual Private Cloud）：AWS など、クラウド上に作る「自分たち専用の仮想ネットワーク」。「ビル内に作る専用フロア」のイメージ。
  • オンプレ：自社所有のサーバー・データセンターでの運用形態。「自社ビルでの執務」と「テナントオフィスでの執務」の対比。
  • シート単価：1 ユーザーあたりの月額・年額料金のこと。チーム規模が増えるほど合算が大きくなる。

ツール選定の判断軸を 5 つに整理します。「絶対これがいい」とは申し上げません——個人開発・5-10 人チーム・全社展開で軸が変わります。

04-1. 機密性——社内コードを外に出せるかどうか

これがいちばん最初に整理すべき軸です。社内コードを外部 SaaS（CodeRabbit / Greptile など）に送れるかどうかで、選択肢は大きく分かれます。送れる場合は SaaS 系も選択肢に入りますが、金融・医療・公共系で「コードは外に出せない」運用なら、AWS Bedrock 経由 Claude や Google Vertex AI 経由 Gemini、ローカル LLM（Ollama + Code Llama / DeepSeek Coder 等）が候補に上がります。詳しくは セクション 7「ローカル LLM」と AWS Bedrock を合わせてご参照ください。

04-2. 統合先——既存の開発フローのどこに差し込むか

エディタに差し込みたいなら Cursor / Copilot、ターミナル / フォルダ単位なら Claude Code / Aider、GitHub PR に自動コメントを付けたいなら CodeRabbit / Greptile / Copilot Code Review。私の業務感覚では、既存のレビュー文化が PR コメント中心ならコメント型、ペアプロ的に書きながら点検する文化ならエディタ型、夜中にまとめてリファクタリングするスタイルが多いなら CLI 型——という整理です。

04-3. 料金——個人 / チーム / 全社のスケールで合算する

個人開発で月数千円までならどの選択肢でも収まります。5-10 人チーム規模になると、Cursor Pro / Copilot Business / Claude Pro などをシート単価でかけ算した合算が見えてきます。全社展開（数十〜数百人）では、ボリュームディスカウントや AWS Bedrock 経由のような従量課金との合算が判断材料になります。最新の料金は必ず各公式で事前確認してから運用判断してください。詳しくは Claude 料金プラン も合わせてご参照ください。

04-4. 言語対応——主要言語と社内ローカル言語のカバー

主要言語（Python / TypeScript / Go / Java / Ruby / Rust / C# 等）は、どのツールもほぼ及第点以上に思います。一方、社内 DSL（ドメイン特化言語）や歴史の長いレガシー言語（COBOL / Fortran / PL/SQL 等）になると、ツールごとに得意・不得意が出ます。私のチームで Ruby を扱う場面では、Claude Code・Cursor・Copilot のいずれも実用範囲ですが、出力の癖が異なる感覚があります。

04-5. チーム規模——個人 / 5-10 人 / 全社で軸が変わる

個人開発なら無料枠だけで十分回ります（セクション 6 で詳述）。5-10 人チーム規模になると、共通の Cursor Rules / CLAUDE.md / プロンプト集をどう共有・更新するかが問題になります。全社展開になると、ガバナンス（誰が何を入力できるか）、効果計測、ガイドライン整備、コンプラ確認、教育——という別軸の論点が一気に立ち上がります。詳しくは セクション 8「チーム導入」と セクション 9「全社推進」をご参照ください。

05 — 実戦プロンプト集 5 型——PR レビュー / 差分指摘 / 全文レビュー / セキュリティ / パフォーマンス

📖 この章で使う用語

  • Cursor Rules：Cursor エディタで「このリポジトリではこのルールで書いてください」と AI に伝える設定ファイル。「営業マニュアルを新人に渡すように、AI にもプロジェクトの作法を渡す」イメージ。
  • CLAUDE.md：Claude Code が起動時に自動で読み込む、リポジトリのルール・前提・暗黙の約束をまとめた Markdown ファイル。Cursor Rules の Claude Code 版に近い。
  • OWASP Top 10：Web アプリのセキュリティリスクの代表 10 種類をまとめた、OWASP（Open Web Application Security Project）の標準的なリスト。

ここが、本記事のいちばん厚い章です。SERP のサジェスト 1 位「プロンプト」を独占吸収する位置づけで、業務で使っている 5 型のプロンプトテンプレート を、コード例つきで整理します。コード片はすべて 抽象化レベル 2（業務固有名は出さない仮想例）にしてあります。

すべての型に共通するコツを先に 4 つ書きます。

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

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

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

PR（Pull Request）全体を AI に俯瞰してもらうための型です。「変更の意図と影響範囲」を最初に 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 の「PR レビュー用プロンプト」セクションに置いておくと、claude コマンドで @CLAUDE.md PR レビューお願いします と頼むだけで、毎回安定した観点で返してくれます。

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

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

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

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

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

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

このプロンプトを Cursor のチャットで叩くと、エディタ上の差分に対して即時返答が得られます。私の業務での体感では、差分が 100-300 行程度のときに最も効果が高い印象です。

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

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

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

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

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

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

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

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

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 による脆弱性検出は 「叩き台」 にすぎません。実際のセキュリティリリース判断は、必ず社内のセキュリティ担当者・必要に応じて第三者の脆弱性診断ベンダーの確認を経てください。AI が見落とす脆弱性は確実に存在しますし、AI が「これは脆弱性です」と指摘した中にも誤検知が含まれます。

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

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

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

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

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

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

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

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

5 型のプロンプトを 毎回ゼロから書かない ようにするのが、運用定着の鍵です。私の業務では、CLAUDE.md に次のようなセクションを置いています。

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

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

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

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

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

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

claude コマンド起動時に CLAUDE.md が自動で読み込まれるため、PR レビューしてください、@変更ファイル.ts と書くだけで、テンプレが裏で適用されます。Cursor の場合は .cursor/rules/review-prompts.md のような分割ファイルに置く運用が私の手元では落ち着きました。

5-10 人チーム規模になると、この プロンプト集をリポジトリに共有してチーム全員で同じ観点でレビューできる ようになるのが大きな利点です。営業時代に、新人さんに渡す「初回訪問の声かけテンプレ集」をチームで育てたのと、まったく同じ感覚です。

06 — 無料で始める方法——各ツールの Free tier と最初の 30 分

📖 この章で使う用語

  • Free tier：サービスの無料利用枠。多くは「月◯回まで」「個人利用に限る」など条件付き。
  • OSS（Open Source Software）：ソースコードが公開されているソフトウェア。GitHub Copilot の OSS 向け Free プランなどに登場する用語。
  • クレジット：API 利用量の前払い残高。Anthropic / OpenAI などで新規登録時に少額のクレジットが付与されることがある（最新情報は公式で要確認）。

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

06-1. 無料で試せる 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）

「絶対これが一番お得」とは申し上げません。プランの境界線は公式で必ず最新を確認してください。

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

「具体的にどう触ればいい？」という読者の方向けに、私のおすすめの最初の 30 分動線をご紹介します。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 分：セクション 5 の「PR レビュー型プロンプト」（05-1）を貼り付け、最後に対象ファイル全文を貼る
  5. 20-30 分：返ってきた指摘を「High / Medium / Low」で 1 件ずつ自分の頭で吟味、自分が同意するか判断

ここまで来れば、AI コードレビューの 第一歩 を踏んだことになります。

06-3. 無料 → 有料に踏み出すタイミング

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

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

私の業務では Claude Pro / Cursor Pro / GitHub Copilot を併用しています。詳しくは Claude 料金プラン も合わせてご参照ください。

07 — ローカル LLM で AI コードレビュー——社内コードを外部に出せない場合の選択肢（個人検証レベル）

📖 この章で使う用語

  • Ollama：ローカルマシンで LLM を動かすためのオープンソースランタイム。「Mac のターミナルで Claude / Llama を動かす最小ツールキット」。
  • Code Llama：Meta が公開している、コード生成・コードレビューに特化したオープンソース LLM。
  • DeepSeek Coder：DeepSeek 社が公開している、コード特化のオープンソース LLM。日本語コメント対応にも比較的強いとされる。
  • 量子化（quantization）：LLM を「軽量版」に変換する技術。「フルサイズの百科事典を、要点だけの携帯版にする」イメージ。

「社内コードを外部 SaaS に送りたくない」「金融・医療・公共系で機密性が厳しい」読者の方向けに、ローカル LLM での AI コードレビュー の選択肢を整理します。

重要な前提：ローカル LLM での AI コードレビューは、私自身は 個人検証レベル で触っており、業務本番運用ではありません。ここでは「手元で試した範囲」と「公開情報からの整理」を組み合わせた概論をご紹介します。本格的に業務導入される場合は、必ず社内情シス・法務・コンプラ部門の事前確認、そして OSS LLM の最新動向を公式・専門ブログでご確認ください。

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

ローカル LLM を選ぶ主な動機は 3 つあります。

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

逆に、ローカル LLM が 現時点で苦手 な領域もあります。

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

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

私が個人検証で試した最小手順をご紹介します。業務本番運用での推奨ではなく、あくまで「ローカル LLM の感触を掴むための最小動線」 としてご覧ください。

# 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 / M2 / M3 / M4）であれば、メモリ 16GB 以上で 7B モデルは動きます。13B や 34B モデルになると、メモリ要件・推論速度ともに敷居が上がります。

Python から呼び出したい場合は、Ollama の REST API（デフォルトポート 11434）か、専用のクライアントライブラリを使います。最新の SDK 仕様は Ollama 公式（ollama.com）でご確認ください。

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

私の個人検証の感触をお伝えすると、ローカル LLM だけで業務本番のコードレビューを回すのは、2026 年 5 月時点ではまだ運用負担が大きい という印象です。一方、社内コードを外に出せない要件があるなら、次の中間策が現実的な選択肢に上がります。

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

詳しくは AWS Bedrock で扱っています。「絶対 Bedrock がベスト」とは申し上げません——組織のクラウド契約・コスト・コンプラ要件で振れ幅が大きい領域です。

08 — チーム導入の進め方——5 ステップ（試行 / ガイドライン / レビュー文化 / 計測 / 定着化）

📖 この章で使う用語

  • パイロット：小規模な試行運用。「全社展開の前に、まず 1 チーム・1 プロジェクトで試す」スタイル。
  • CI（Continuous Integration：継続的インテグレーション）：コード変更を自動でテスト・チェックする仕組み。GitHub Actions / GitLab CI などが代表例。「工場の出荷前自動検査ライン」のイメージ。
  • ガイドライン：社内ルール文書。「機密情報を入力しない」「人間レビューは必ず通す」などの行動規範を明文化。

5-10 人チーム規模で AI コードレビューを導入する 現実的な 5 ステップ を、私の業務体感ベースで整理します。抽象化レベル 2 で書いており、具体的なチーム名・案件名は出しません。

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

最初から「全チームに展開」と構えると失敗します。まず 1 人 1 PR で試す のが定着します。

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

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

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

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

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

私の業務での教訓は、「ガイドラインを 5 ページ以上書こうとすると、誰も読まない」 という事実です。1 ページ・5 項目以内に絞るのが定着のコツです。

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

AI コードレビューを導入したからといって、既存の人間レビュー文化を消してはいけません。むしろ、人間レビューと AI レビューの「分業」を明確にするのが定着の鍵です。

私の運用例：

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

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

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

「AI コードレビューで本当に効率が上がったのか」を 数字で語りたい 場面が必ず来ます。計測軸の例：

  • PR レビュー所要時間（導入前後の比較）
  • PR から merge までのリードタイム
  • 本番障害件数 / 重大度（数ヶ月の比較）
  • ユーザー満足度（チームメンバーへのアンケート）

メタ宣言：これらの数字を「絶対 X 倍速くなった」と外部に発信するのは慎重に。コードベース・チーム規模・時期で振れ幅が大きく、AI 導入以外の要素も同時に変化していることが多いです。社内向けには「自分たちの感触」として共有するに留め、対外発信は数値の取り方を専門家とよく相談してから出すのが安全です。

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

導入から 3〜6 ヶ月で多くのチームが直面する落とし穴を 4 つ。

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

これらは「ガイドラインを四半期に 1 回更新する」「月 1 のレビュー振り返り会を設ける」「組織契約の有料プランを敷く」などの運用で予防できます。

09 — 全社推進の事例——「コードレビュー最強推進実感」の業務体感（本講座 LP の信用補強）

📖 この章で使う用語

  • 全社推進：個人・チームを越えて、組織全体に AI 活用を広げる動き。役割としては「推進担当」「変革リーダー」などと呼ばれる。
  • パイロット選定：全社展開の前に、最初に試行する部門・チームを選ぶ作業。
  • 勝ち筋（best practice）：実際に効果が出たやり方。「うまくいった事例の型」のこと。

ここでは、私が業務で AI 活用を全社推進した経験から、「なぜコードレビューが最も実感を持てた領域だったか」 をご紹介します。第13本目「AI 業務効率化 事例」でもこの論点を扱いましたが、本記事ではコードレビューに絞って深掘りします。抽象化レベル 2 で書きますので、社名・業界名・プロダクト名は出しません。

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

私の業務で AI 活用を 5 領域（議事録 / 資料作成 / 社内 RAG / コードレビュー / 非エンジニア部門展開）で並行推進したとき、コードレビューがいちばん「型・命名・セキュリティの底上げが、体感的に分かる」領域 でした。

理由は 3 つあります。

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

議事録や資料作成は「読みやすくなった」「整って見える」という主観的な感触が中心ですが、コードレビューは「セキュリティ脆弱性を AI が拾った」「型エラーの数が減った」のように、現場の開発者が「あ、確かに助かった」と腹に落ちる場面が多いです。

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

私が業務で全社推進したときの 5 ステップを、抽象化して整理します。

ステップ 1：パイロット選定——AI 親和性の高い 1 チームを選ぶ（新しい技術導入に前向き、PR レビュー文化が既にあり、リーダーが推進担当に協力的）。最初から「全エンジニアに展開」と構えない。

ステップ 2：勝ち筋共有——パイロット 1 ヶ月後、「うまくいったプロンプト・ツール設定・運用ルール」を社内 Wiki / Notion / Slack でドキュメント化する。「Cursor Rules のテンプレ」「CLAUDE.md の標準フォーマット」「PR レビューの分業ルール」など。

ステップ 3：非エンジニア部門への展開——コードレビュー文脈ではなく、隣接領域（議事録要約・資料作成・RAG 検索）への AI 活用展開を並行で進める。「会社全体で AI を使う雰囲気」を醸成する。詳しくは AI 業務効率化 事例 をご参照ください。

ステップ 4：効果計測——3〜6 ヶ月で「PR レビュー所要時間」「重大障害件数」「チームメンバーの満足度」を控えめに計測する。対外発信は慎重に——数字の振れ幅が大きいので、社内向けの「感触の共有」に留める方が誠実です。

ステップ 5：継続化——四半期に 1 回、ガイドライン更新・プロンプト集の見直し・新ツールの評価会を設ける。AI 領域は半年で景色が変わるので、年に 1 回ではなく四半期に 1 回が現実的なリズムです。

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

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

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

「全体俯瞰を先に読みたい方は業務事例記事へ、コードレビュー単体で深掘りしたい方は本記事へ」という二段構えで読み分けていただけると、ハブ＆スポークの内部リンクが活きてきます。

10 — リスクと注意点——機密性 / 著作権 / 品質低下 / スキル劣化 / 脆弱性の三段安全網

📖 この章で使う用語

  • AI 任せきり（over-reliance）：AI 出力をそのままコミットしてしまう運用。最大のアンチパターン。
  • プロンプトインジェクション（prompt injection）：悪意あるプロンプトで AI の動作を狂わせる攻撃手法。社内コードに紛れ込ませる手口もある。
  • BAA（Business Associate Agreement）：医療系で必要な業務委託契約。HIPAA 準拠の AI ベンダー利用時に必須。

ここが、本記事の YMYL 三段安全網 の最厚章です。AI コードレビューを業務導入する際に押さえるべきリスク 5 つを、1 つずつ整理します。

冒頭で重要なメタ宣言：本セクションの記述は、私の業務観察と公開情報からの整理に基づきます。「絶対安全」「絶対大丈夫」とは申し上げません。最終判断は、社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。

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

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

最低限の論点：

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

「絶対送って大丈夫」とは申し上げません——契約・規約・業界規制で振れ幅が大きい領域です。社内法務とよく相談してから運用してください。

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

AI が出力したコードの 著作権の扱い は、ベンダー・モデル・利用規約で異なります。最低限の論点：

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

「絶対 AI 出力は著作権を侵害しない」とは申し上げません——最終判断は社内法務・必要に応じて弁護士の方へ。

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

AI 出力をそのままコミットする「AI 任せきり」運用は、最大のアンチパターンです。理由は 3 つ。

  1. 誤検知：AI が「ここがバグです」と指摘した中に、実際にはバグではない箇所が混ざる
  2. 見落とし：AI が拾えない論点（ドメイン理解・チーム文化・曖昧仕様）が確実に存在する
  3. ハルシネーション：AI が存在しない関数名・API・パッケージ名を断定的に提案する場面がある

私の業務感覚では、AI 出力は必ず人間が 1 度通読してからコミットする 運用に統一しています。「AI が言ったから正しい」は通用しない、というのが業務 3 年の体感です。

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

「ずっと AI に書かせていると、自分で書く力が衰える」という感覚は、私自身も実感しています。詳しくは AI コーディング の「疲れる・スキル劣化」の章でも扱いましたが、対策の方向性をいくつか。

  • 週に 1 度は AI を使わない時間を作る（自分で 1〜2 時間コーディング）
  • AI 出力を必ず通読する（読まないと自分の脳が動かない）
  • 基礎学習を継続する（公式ドキュメント / 書籍 / カンファレンスでアップデートを取る）

10-5. 脆弱性リスク——AI 生成コードの脆弱性

AI が生成したコードに 脆弱性が紛れ込む 場面は確実にあります。代表的なパターン：

  • 入力検証の欠落：ユーザー入力をそのまま SQL / シェル / HTML に渡すコードが出力される
  • 古い API の使用：非推奨・脆弱性報告済みの API を AI が断定的に提案する場面
  • 依存ライブラリの混入：存在しないパッケージ名・タイポされたパッケージ名を AI が提案する場面（プロンプトインジェクションの温床）

対策は、AI 出力後に必ず人間レビュー + 静的解析 + 脆弱性スキャンを 3 段重ねで通すことです。

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

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

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

これは、業務で 3 ツールを毎日叩いている私自身が最も大切にしている運用作法です。「AI が便利だからこそ、人間の判断を最後に必ず通す」 という構えが、長く運用するための土台になります。

11 — 失敗パターン 5 つ——AI 任せきり / プロンプト雑 / レビュースキップ / 機密情報投入 / 効果未計測

📖 この章で使う用語

  • ボイラープレート：定型的に書くお決まりのコード片。「テンプレ的な前置きコード」のイメージ。
  • コンプラ（compliance）：法令・社内規程の順守。「コンプライアンス」の略称。
  • 属人化：特定の 1 人にしか分からない運用になっていること。「あの人がいないと回らない」状態。

AI コードレビューの 典型的な失敗 5 パターン を、私の業務観察と公開情報からの整理で並べます。

11-1. AI 任せきり（最大のアンチパターン）

AI 出力を読まずにコミットする運用。前章 セクション 10 で詳述した通り、最大のアンチパターンです。予防策は「AI 出力は必ず人間が 1 度通読してからコミット をチームルール化する」「PR 説明欄に『AI レビューを受けた / 自分で通読済み』のチェックボックスを置く」。

11-2. プロンプトが雑（毎回ゼロから書く）

毎回「このコード見てください」だけで AI に投げる運用は、返答の質が安定しません。予防策は セクション 5 で扱った 5 型のプロンプト集を CLAUDE.md / Cursor Rules にテンプレ化する こと。

11-3. 人間レビューのスキップ

AI が「大丈夫」と言ったから人間レビューをスキップ——これは セクション 10 で扱った通り、品質低下の温床です。AI 一次 + 人間最終 + CI 並行の 3 層構造 を崩さない。

11-4. 機密情報の投入

社内コード・個人情報・認証トークンを、外部 SaaS にうっかり投入してしまう事例。予防策は「送ってはいけない情報のリストをチームガイドラインで明文化 する」「リポジトリ単位で .env / 秘密情報の自動マスクを設定する」「セキュリティ研修を四半期に 1 回開く」など。

11-5. 効果計測の放置

導入から半年経っても「うまくいっているのか分からない」状態。予防策は「月 1 のレビュー振り返り会 でチームの感触を共有する」「PR レビュー所要時間を週次でグラフ化する」「定性アンケートを四半期に 1 回回す」。

「絶対この 5 つを避ければ大丈夫」とは申し上げません——実運用では、ここに書いていないパターンも必ず出てきます。自分のチームで起こった失敗を、四半期に 1 回ドキュメント化して仲間に共有する のが、いちばん遠回りに見えて近道だと、私の業務体感では思います。

12 — AI コードレビューを、エンジニアでない人がどう関わるか——非エンジニア 5 ユースケース

📖 この章で使う用語

  • マクロ：Excel などで操作を自動化する短いプログラム。「事務作業の自動装置」。
  • 静的サイト：HTML/CSS/JS だけで構成されたシンプルなサイト。WordPress などのサーバー処理を持たない。「印刷物のような Web ページ」。
  • コードスニペット：短いコード片。「料理レシピの一部分」のような単位。

「自分はエンジニアではないけど、AI コードレビューに関わる場面はあるのか？」と気になる読者の方向けに、非エンジニアでも関わる 5 ユースケース を、Before / After / 所要時間 / 最初の壁 の 4 要素モデルで整理します。

12-1. 営業：提案資料に含まれるコード片・数式の安全性チェック

Before：技術提案資料を作るとき、エンジニアにレビューを依頼して 1〜2 日待つ。日程が押すと提案前日まで確認が間に合わない。

After：提案資料に含まれるコード片や数式を、AI に「これは公開しても問題ない範囲か」「明らかな誤りはないか」と一次チェック。エンジニアレビューはより本質的な部分に集中してもらう。

所要時間：1 回 5〜10 分（AI チャットに資料コピー＆ペースト → 観点指定 → 返答確認）

最初の壁：「コードの中身は分からないのに、AI への質問の仕方が分からない」。営業時代の私だったら、まず「これは技術的に不適切な記述はありますか？」という素朴な聞き方から始めると思います。

12-2. 事務：Excel マクロ・スクリプトの安全性チェック

Before：社内 Excel マクロを社員から共有されたが、開いて動かしていいか分からない。情シスに問い合わせると数日かかる。

After：マクロ / VBA コードを AI に貼り付けて、「このコードに不審な動作はないか / 外部通信や PC へのファイル書き込みがないか」を一次確認。情シスへの問い合わせは「本当に懸念がありそうな箇所だけ」に絞れる。

所要時間：1 回 3〜5 分

最初の壁：マクロのソースコードを取り出す手順（Excel の Alt + F11 で VBA エディタを開く等）に慣れる必要があります。

12-3. 個人事業主：自分のサイトの簡単なスクリプトのチェック

Before：自分の静的サイトに埋め込んだ Google Analytics / SNS シェアボタンのコードが、本当に意図通り動いているか不安。Web 制作の友人に聞くにも頻繁すぎて気が引ける。

After：埋め込みコードを AI に貼り付けて、「このコードは何をしているか / 個人情報の流出懸念はないか」を一次確認。Web 制作の友人には「本当に判断に迷ったとき」だけ相談すれば済む。

所要時間：1 回 5〜10 分

最初の壁：HTML / JavaScript の基本用語（タグ、スクリプト、変数）に最低限慣れる必要がありますが、AI に「初心者向けに用語から説明して」と頼めば、その学習も AI 相手にできます。

12-4. 副業ライター：技術記事のコード片の正しさ確認

Before：技術ブログ・Qiita 記事を書くとき、サンプルコードが本当に動くか不安。手元で実行環境を整えるのが面倒。

After：書いたコード片を AI に貼って、「このコードは構文的に正しいか / 想定する動作になるか」を確認。明らかな誤りや古い書き方を一次で拾える。

所要時間：1 記事あたり 5〜15 分

最初の壁：AI の指摘がすべて正しいわけではない（ハルシネーションがある）ので、最終的には「自分で動かして確かめる」工程は省略しないこと。

12-5. エンジニア志望：学習中のコードを「レビュー師匠」として使う

Before：プログラミング学習中に「自分の書いたコードが正しいか・改善余地があるか」を聞ける相手がいない。スクールの講師に質問できる時間も限られる。

After：書いたコードを AI に貼って、「初心者向けに、改善できる箇所を 3 つ教えて」と頼む。24 時間いつでも返事をくれる学習パートナー として機能する。

所要時間：1 課題あたり 5〜15 分

最初の壁：AI の指摘を「正解」と鵜呑みにしないこと。学習段階では「なぜそう改善するのか」を自分で考える時間も大事です。詳しくは AI コーディング の学習章もご参照ください。

5 ユースケースに共通するのは、「AI に渡す前に、何を聞きたいかを 1 行で書く」 という作法です。営業時代に「お客様に何を確認するか、訪問前に 1 行で書き出す」癖がありましたが、AI 相手も同じだなと業務でしみじみ感じます。

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

📖 この章で使う用語

  • ロール：役割。個人開発者 / チームリーダー / 全社推進担当のように、立場ごとに最初の一歩が変わる。
  • オンボーディング：新しい仕組み・ツールに馴染むまでの導入期間。「新人研修のツール版」。
  • キックオフ：チームで新しい取り組みを始める最初の会議。「スタート会」のイメージ。

最後に、読者の方の ロール別 7 日プラン をご提案します。「とりあえず今週、何をすればいいか」を 1 日ずつに分解しました。

13-1. 個人開発者の 7 日プラン

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

13-2. チームリーダーの 7 日プラン

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

13-3. 全社推進担当の 7 日プラン

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

13-4. 本講座での深掘り誘導

ここまでの 7 日プランで「最初の一歩」は踏めますが、「業務本番で AI コードレビューを定着させる、そして生成AIエンジニアとして職業転換まで届かせる」 には、より体系的な学習が必要になります。

本サイト bon-bon-tools.com では、営業出身の現役生成AIエンジニアが「未経験から生成AIエンジニアに到達するロードマップ」を扱う本講座 を準備中です（2026 年下期公開予定）。Claude Code / Cursor / GitHub Copilot を業務で叩く・社内推進する側のリアルな運用ノウハウを、コードレビューを含む 5 領域で体系化します。最新情報は本サイトのトップページからお知らせします。

「絶対この講座が必要」とは申し上げません——独学・公式ドキュメント・スクール・社内 OJT などのルートも有効です。本サイトはその中の 「営業出身の現役生成AIエンジニアの一次体験」 という独自の角度を提供する選択肢の 1 つ、という位置づけでご検討ください。

14 — よくある質問

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

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

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

A. 「絶対これ」とは申し上げません（個人差・業務差・スキル差で振れます）。私の業務感覚での目安としては、(1) チャット型 AI を 1 度も触っていないなら Claude.ai または ChatGPT の無料版から、(2) エディタ統合を試したいなら Cursor の Hobby（無料）プランから、(3) フォルダ単位でレビューさせたいなら Claude Code の新規無料クレジットから——の順序が現実的です。詳しくは セクション 3 と セクション 6 をご参照ください。

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

A. 主な選択肢は 3 つです：(1) AWS Bedrock 経由 Claude / Google Vertex AI 経由 Gemini など、組織契約の AI 基盤を使う、(2) Ollama + Code Llama / DeepSeek Coder などローカル LLM を試す（私自身は個人検証レベルで、業務本番運用ではありません）、(3) 社内ガイドラインを整備して「機密ファイル・個人情報・社外秘ロジック」を入力しない運用ルールを徹底する——の組み合わせです。最終判断は社内の情シス・法務・コンプライアンス部門にご相談ください。詳しくは セクション 7 と セクション 10 をご参照ください。

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

A. 本記事 セクション 5「実戦プロンプト集」で、PR レビュー型 / 差分指摘型 / 全文レビュー型 / セキュリティ特化型 / パフォーマンス特化型の 5 型を整理しています。共通するコツは (1) リポジトリの前提（言語・フレームワーク・チーム規約）を先に伝える、(2) レビュー観点を明示する（型 / 命名 / 論理 / セキュリティ / 可読性 のどれか）、(3) 出力フォーマットを指定する（重要度 High / Medium / Low の 3 段階等）、(4) Cursor Rules や CLAUDE.md にテンプレ化して使い回す——の 4 つです。

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

A. 始められます。本記事 セクション 6「無料で始める方法」で、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 の利用規約・料金・モデル仕様等）は、必ず各社の公式ドキュメントをご確認の上、最終判断は社内の情シス・法務・コンプライアンス部門、必要に応じて専門の弁護士の方へご相談ください。

関連記事

出典

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