セキュリティコードレビューの進め方｜外注コードを検証する5ステップ

「委託先のエンジニアが書いたコードは、どうやってセキュリティを検証していますか」。エンタープライズ顧客との取引開始やISMSの更新審査で、この問いに答えられずに固まってしまった経験はないでしょうか。セキュリティコードレビューという工程があることは知っていても、社内に脆弱性を判定できる人がいなければ、実際には誰も検証していない状態が続きます。

やっかいなのは、これが「外部エンジニアを信用していない」という話ではないことです。むしろ日々の仕事ぶりには満足していて、疑う理由はどこにもない。それでも「セキュリティ上の問題はありません」と自社の名前で言い切ることはできない。この居心地の悪さが、多くの発注担当者を悩ませています。

一方で、外部委託先を経由した攻撃は、もはや例外的なリスクではありません。IPA の「情報セキュリティ10大脅威 2026」では、「サプライチェーンや委託先を狙った攻撃」が組織向けの第2位に挙げられており、2019年の初選出から8年連続でランクインしています（IPA 情報セキュリティ10大脅威 2026）。委託先のコードを誰も見ていない状態は、そのまま自社のリスクになります。

ただし、解決策は「全部のコードを専門家に見てもらう」ことではありません。現実的な予算と体制のなかで、どこを見て、何を記録すれば発注者としての説明責任を果たしたと言えるのか。その線引きさえ持てれば、社内に専門家がいなくてもレビュー工程は回り始めます。

本記事では、外部エンジニアが書いたコードに対するセキュリティコードレビューの進め方を、レビュー範囲の絞り込みから静的解析と目視レビューの分担、指摘票の運用、証跡の残し方まで5ステップで解説します。あわせて、発注担当者が自分で確認できる観点・エンジニアに質問すれば検証できる観点・専門家でなければ判定できない観点を3層に仕分けたチェックリストと、社内に判定できる人がいない場合の選択肢も整理します。

セキュリティコードレビューとは｜品質レビューとの違いと確認範囲

セキュリティコードレビュー（セキュアコードレビュー）とは、ソースコードを人の目やツールで読み、脆弱性につながる実装がないかを検証する工程です。動いているシステムを外から攻撃して弱点を探す手法とは異なり、コードの中身そのものを確認するため、ホワイトボックス型の検証と呼ばれます。

はじめに、本記事の守備範囲を明示しておきます。本記事が扱うのはコードレビュー全般ではなく、セキュリティ観点に絞ったレビューです。可読性・保守性・テストの有無といった品質全般のレビューをどう依頼し、どう品質を担保するかについては、外部エンジニアのコードレビューを依頼する方法と品質担保の仕組みで扱っています。品質レビューの体制づくりから着手したい場合は、そちらを先にご覧ください。

そのうえで、この工程が何を見て、何を見ないのかという守備範囲をはっきりさせるところから始めましょう。範囲が曖昧なままだと、「やったつもり」なのに肝心な部分が抜けている、という状態になりがちです。

品質コードレビューとセキュリティコードレビューは何が違うか

多くの開発現場で日常的に行われているコードレビューは、品質を目的としたレビューです。仕様どおりに動くか、読みやすいか、保守しやすいか、テストは書かれているか、といった観点でコードを確認します。

セキュリティ観点のソースコードレビューは、目的がまったく異なります。ひとことで言えば、品質レビューが「意図したとおりに動くか」を見るのに対し、セキュリティレビューは「意図しない使われ方をされたときに壊れないか」を見ます。

重要なのは、品質レビューを丁寧にやっているからといってセキュリティ上の問題が見つかるわけではない、という点です。仕様どおりに動くコードでも、管理者しか触れないはずの機能に一般ユーザーがURLを直接叩けば到達できる、という認可漏れは残ります。実際、OWASP がまとめた OWASP Top 10:2025 でも、Webアプリケーションの最重要リスクの第1位は「Broken Access Control（アクセス制御の不備）」であり、これは正常系のテストでは表面化しにくい類の問題です。

IPA のセキュア・プログラミング講座では、ソースコードレビューを「下読み」「成熟度点検」「機能点検」「脆弱性点検」の4段階に整理しています（IPA セキュア・プログラミング講座 ソースコードレビュー）。このうち脆弱性点検はチェックリストに基づいて実施する独立した段階であり、機能点検（バグ検出）とは別に時間を取る前提で設計されています。品質レビューのついでに済ませられる作業ではない、と理解しておくとよいでしょう。

外部委託では「第三者の目」が抜けやすい

同じ IPA の資料では、望ましいレビュー体制として、開発者本人による見直しと第三者によるレビューの両方を実施することを挙げています。開発者本人が見直すことでコードを書く力そのものが上がり、第三者が見ることで思い込みによる見落としを拾える、という考え方です。

ところが外部エンジニアに実装を委託している体制では、この「第三者の目」が構造的に抜け落ちやすくなります。

• 業務委託エンジニアが1名体制の場合、レビュアーが存在せず、自分で書いたコードを自分で承認する形になる
• 社内エンジニアが1〜2名しかいない場合、レビューに割ける時間がなく、承認ボタンを押すだけの形式的な手続きになる
• 複数の外部エンジニアがいても、それぞれ担当領域が分かれていて相互にコードを読む機会がない
• 発注担当者はコードを読めないため、レビューが行われているかどうか自体を確認できない

この状態では、外部エンジニアの技術力がどれだけ高くても、人間である以上避けられない見落としを拾う仕組みがありません。つまり問題は個人の能力ではなく、体制の設計にあります。だからこそ、発注側が「レビューという工程が存在するか」を確認し、なければ組み込むという役割を担う必要があります。

脆弱性診断・ペネトレーションテストとの位置づけの違い

セキュリティに関する検証手段には、コードを読むレビューのほかに、稼働中のシステムに対して外部から擬似的な攻撃を行う脆弱性診断やペネトレーションテストがあります。

両者は代替関係ではなく、見つかるものが違う補完関係にあります。診断を受けたからコードレビューは不要、という判断は抜けを生みます。この使い分けについては、のちほど「脆弱性診断・ペネトレーションテストとの違いと使い分け」で判断表とあわせて整理します。ここではまず、セキュリティコードレビューは「実装の誤りを、動かす前に、コードの中で見つける工程」だと押さえておいてください。

発注側がセキュリティレビューに踏み込めない3つの理由

必要性は分かっている。それでも動けない。この状態には、はっきりした理由があります。ここでは典型的な3つの詰まりを言語化し、それぞれ本記事のどこで解消するかを対応づけます。「自分の会社だけがだらしないのではないか」という感覚は、いったん脇に置いて構いません。

社内に脆弱性を判定できる人がいない

最も根本的な壁がこれです。コードを開いて処理の流れを追うことはできても、その実装が脆弱かどうかを判定するには、攻撃手法の知識が要ります。SQLインジェクションという語を知っていることと、目の前のクエリ組み立て処理が安全かを判定できることは、まったく別のスキルです。

さらに厄介なのは、外部エンジニアに「セキュリティは大丈夫ですか」と聞いても、返ってくるのは自己申告だという点です。相手に悪意がなくても、自己申告は検証にはなりません。かといって、判定できない立場から突っ込んだ質問をするのは気が引ける、という心理的なハードルもあります。

この詰まりは、「発注担当が自分で確認できる観点」と「エンジニアに質問すれば検証できる観点」を分けて整理することで、かなりの部分が動かせるようになります。のちほど3層のチェックリストとして提示します。

全コードを見るのは非現実的で、優先順位の基準がない

仮に判定できる人を確保できたとしても、数万行のコードを全部レビューするのは現実的ではありません。工数も費用も膨らみますし、毎回のリリースで実施することはまず不可能です。

そこで「重要なところだけ見る」という話になりますが、今度は何が重要かの基準がありません。基準がないまま「気になったところ」を見ると、レビューの範囲が担当者の勘に依存し、抜けが生じても気づけません。取引先に説明する場面でも、「重要そうなところを見ました」では通用しません。

必要なのは、誰が見ても同じ範囲が選ばれる、説明可能な絞り込み基準です。本記事では「影響度 × 変更頻度」という2軸を提案します。

指摘した後の修正責任・費用の扱いが決まっていない

3つ目は、技術ではなく契約と関係性の問題です。レビューで問題が見つかったとして、その修正は誰の負担で行うのか。追加費用が発生するのか、無償で直してもらえるのか。ここが決まっていないと、指摘そのものが揉め事の種になりかねません。

結果として、「指摘したら関係が悪くなるかもしれない」「追加費用を請求されるかもしれない」という懸念が先に立ち、レビューに踏み込めなくなります。実際には、これは事前合意の欠落が原因です。発注時にレビュー工程の存在と指摘の扱いを合意しておけば、指摘は詰問ではなく、合意済みの手順を実行しているだけになります。この点は「レビューを契約と受け入れ手順に組み込む」で扱います。

セキュリティコードレビューの進め方5ステップ

ここからが本題です。社内にセキュリティ専任者がいない前提で、発注側が回せるセキュリティコードレビューの進め方を5つのステップに分けて説明します。

各ステップでは「発注側がやること」と「外部エンジニアに依頼すること」を分けて記載します。すべてを自社で抱え込む必要はなく、発注側の役割は「工程を設計し、実施されたことを確認し、記録を残す」ことにあると考えてください。

ステップ1: レビュー範囲を「影響度 × 変更頻度」で絞る

最初にやるべきは、レビュー対象の絞り込みです。ここを飛ばして「とりあえず全部見よう」とすると、必ず途中で息切れします。

絞り込みの軸は2つです。

影響度: そのコードが壊れたとき、何が漏れるか・何が乗っ取られるかで判断します。優先度が高いのは次の領域です。

• 認証（ログイン、パスワードリセット、セッション管理、多要素認証）
• 認可（権限チェック、他人のデータへのアクセス制御、管理者機能）
• 決済・課金（金額計算、外部決済サービスとの連携、返金処理）
• 個人データの取り扱い（登録・参照・出力・削除、CSVエクスポート）
• 外部連携（API連携、ファイルアップロード、Webhook受信）

変更頻度: 直近で何度も書き換わっている箇所は、それだけ人の手が入っており、想定漏れが混入しやすい領域です。Gitの変更履歴を見れば、コードが読めなくても更新回数は把握できます。外部エンジニアに「直近3か月で変更が多かったファイル上位20件」を出してもらうだけでも十分です。

この2軸で、影響度が高く、かつ変更頻度も高い領域を最優先のレビュー対象とします。多くのサービスでは、この条件に当てはまるのはコード全体の1〜2割程度に収まります。

ここで大切なのは、対象外にした領域も「対象外と判断した」という記録を残すことです。見ていない部分があること自体は問題ではありません。問題は、見ていない部分がどこなのかを誰も把握していないことです。範囲を明示して記録すれば、それは説明できる状態になります。

• 発注側がやること: 影響度の高い領域を業務観点で列挙し、優先順位を決める
• 外部エンジニアに依頼すること: 列挙した領域に対応するファイル・ディレクトリの特定、変更頻度の集計

ステップ2: 静的解析（SAST）で機械的に洗い出す

範囲が決まったら、まずは機械にかけます。SAST（静的アプリケーションセキュリティテスト）は、ソースコードを実行せずに解析し、脆弱性につながるパターンを検出するツールです。人が読むより圧倒的に速く、見落としもありません。

導入時に発注側が決めておくべきことは次の4点です。

1. 対象言語とリポジトリ: 使用している言語・フレームワークに対応したツールを選びます。複数リポジトリがある場合はどこまでを対象にするかを決めます
2. 実行タイミング: 手動実行だと形骸化します。CI（継続的インテグレーション）に組み込み、プルリクエストのたびに自動実行される状態を目指します
3. 重大度のしきい値: 検出結果のうち、どのレベル以上を必ず対応するかを決めます。一般には Critical / High を必須対応、Medium 以下は判断に委ねる、といった線引きにします
4. 誤検知の扱い方: 誤検知と判断した場合の記録方法を決めます。「なぜ問題ないと判断したか」を1行でも残しておくと、後から見返せます

そして最も重要なのが、SAST の限界を理解しておくことです。SAST はコードとして明示されている問題を検出する仕組みであるため、次のような問題は検出できません（SAST（静的アプリケーションセキュリティテスト）とは？仕組み・メリット・限界から、ソフトウェア開発における正しい活用…）。

• 環境変数や設定ファイルの誤り
• 認証・認可の設計そのものの誤り
• 外部サービスとの連携に起因する問題
• 業務ロジックの抜け穴、想定外の操作手順

つまり、「静的解析ツールを導入したのでセキュリティは大丈夫です」とは言えません。ツールは網の目が細かい第一段階のフィルタであり、その網では捕まえられない種類の問題が確実に残ります。ここを人の目で埋めるのが次のステップです。

• 発注側がやること: 導入判断、しきい値の決定、検出件数と対応状況の把握
• 外部エンジニアに依頼すること: ツールの選定案の提示、CIへの組み込み、検出結果の一次仕分け

ステップ3: 目視レビューでセキュアコーディングの実装判断を確認する

SAST が拾えない領域を、人が読んで確認します。ここで見るのは、セキュアコーディングの原則が実際の実装判断に反映されているか、という点です。

優先度の高い確認観点を、発注側でも把握しやすい5つに絞って整理します。

このうち依存ライブラリについては、OWASP Top 10:2025 で「Software Supply Chain Failures（ソフトウェアサプライチェーンの不備）」が新設カテゴリとして第3位に入っており、外部から取り込むコンポーネントの管理が単独の重要リスクとして位置づけられています。自社で書いたコードだけを見ていても不十分だ、という認識が必要です。

入力検証と認可チェックは、フロントエンド側だけで実装されているケースが少なくありません。画面上でボタンを隠していても、リクエストを直接送れば処理が通ってしまう、という実装は珍しくないため、「サーバー側で検証しているか」を明示的に確認してください。

• 発注側がやること: 観点リストの提示、確認結果の受領と記録
• 外部エンジニアに依頼すること: 各観点に対する実装方針の説明と、該当するコード箇所の提示

ステップ4: 指摘を「指摘票」にして重大度・対応期限・対応区分を合意する

見つかった問題を口頭やチャットで伝えるだけでは、対応の抜けが起きますし、記録も残りません。指摘は必ず一覧の形にします。難しいツールは不要で、スプレッドシート1枚で十分です。

指摘票に含める項目は次のとおりです。

ポイントは「対応区分」に受容という選択肢を明示的に置くことです。指摘が出たものをすべて即座に直す必要はありません。影響範囲が限定的で、修正コストが見合わないものは「リスクを認識したうえで現状を受け入れる」と判断してよいのです。ただし、その判断を誰がいつ行ったかを記録することが条件です。

この「受容」という区分があることで、レビューは現実的に回るようになります。すべて直さなければならないと考えると、指摘を出すこと自体が怖くなり、結果としてレビューが機能しなくなります。

重大度の定義も、あらかじめ言葉で決めておきましょう。たとえば「Critical = 個人情報が第三者に閲覧される可能性がある」「High = 権限を越えた操作ができる」といった具合に、自社の業務に照らして書いておくと、判断のぶれが減ります。

• 発注側がやること: 指摘票のフォーマット用意、重大度の定義、対応区分の最終判断
• 外部エンジニアに依頼すること: 指摘内容の技術的な説明、修正方針と工数の見積り

ステップ5: 再レビューと証跡の保管

修正が入ったら、その修正が本当に問題を解消しているかを再度確認します。修正時に別の問題を作り込むことは珍しくないため、修正コミットに限定した再レビューを行い、指摘票の「対応結果」欄を埋めます。

そして最後に、証跡を保管します。これが、冒頭の「委託先のコードはどう検証していますか」という問いに答えるための材料になります。

残すべき証跡は次の5点です。

1. レビュー範囲: どの領域を対象にし、どこを対象外としたか（ステップ1の判断記録）
2. 実施日と実施者: いつ、誰が実施したか
3. 使用したツールと設定: SAST のツール名、対象範囲、重大度のしきい値
4. 指摘票: 検出された指摘と、それぞれの対応区分・対応結果
5. 判断の根拠: 受容と判断したものについて、その理由

この5点が揃っていれば、「セキュリティ上の問題は一切ありません」とは言えなくても、「この範囲を、この方法で、この基準に沿って検証し、結果をこう扱いました」とは説明できます。監査や取引先が求めているのは、多くの場合、完璧さの証明ではなく、管理された工程が存在することの証明です。

保管場所は、開発ツール内ではなく、担当者が変わっても辿れる場所（社内の共有ドライブやドキュメント管理システム）にしてください。外部エンジニアとの契約が終了した後にアクセスできなくなる場所は避けます。

• 発注側がやること: 証跡の保管、保管場所と保管期間の決定
• 外部エンジニアに依頼すること: 再レビューの実施、修正内容の記録

発注側が使うセキュリティレビュー観点チェックリスト（3層仕分け）

セキュリティレビューの観点リストは、検索すればいくらでも出てきます。しかし、その多くはエンジニアが読むことを前提に書かれており、発注担当者が手に取っても「これは自分に確認できるのか」が判断できません。

そこでここでは、セキュリティレビューのチェックリストを (A) 発注担当が自分で確認できる観点 / (B) 外部エンジニアに質問すれば検証できる観点 / (C) セキュリティ専門家でなければ判定できない観点 の3層に仕分けて提示します。自分にできることとできないことが分かれば、「何もできない」から「ここまではできる」に変わります。

なお、ここで扱うのはあくまでセキュリティ観点の確認項目です。可読性・テスト・ドキュメントといった品質全般の確認項目とは目的が異なるため、両方を1枚のチェックリストに混ぜないことをおすすめします。

発注担当が自分で確認できる観点

コードの中身を判定できなくても、事実として確認できることは意外に多くあります。以下は、検索機能や画面操作、履歴の閲覧だけで確認できる項目です。

最後の「管理者機能へのアクセス」は、実際に手を動かして確認できる数少ない項目です。検証環境で、権限の低いアカウントを使って管理者向けの画面URLを直接入力してみてください。これはアクセス制御の不備を発注担当者自身が発見できる、もっとも簡単な方法のひとつです。実施する際は、必ず本番環境ではなく検証環境で、外部エンジニアに事前に伝えたうえで行ってください。

外部エンジニアへの質問で検証する観点

次の層は、自分では判定できないが、質問すれば確認できる観点です。ここで大切なのは、質問の仕方です。「セキュリティは大丈夫ですか」と聞けば「大丈夫です」としか返ってきません。自己申告で終わらせないためには、根拠の提示を求める形にします。

この質問群には共通の構造があります。「対策していますか」ではなく、「どこで、どうやっているか」を聞くことです。実装していれば具体的な場所を示せますし、示せない場合は実装されていないか、本人も把握していないかのどちらかです。どちらであっても、それ自体が重要な情報になります。

質問は詰問ではありません。「監査で聞かれるので、答えられる形で教えてほしい」と背景を添えれば、多くのエンジニアは協力的に応じてくれます。むしろ、こうした質問が来ることを前提に実装するようになれば、品質は自然に上がっていきます。

専門家でなければ判定できない観点

一方で、どれだけ質問を工夫しても、発注担当者では判定できない領域があります。これを無理に自社で抱え込もうとすると、時間だけがかかって結論が出ません。次の観点は、専門知識を持つ人に見てもらう前提で切り分けてください。

• 認可モデルの設計そのものの妥当性: 個々のチェックが書かれていても、権限の設計自体に穴があるケース。役割の定義とデータの所有関係が複雑になるほど判定が難しくなります
• 暗号の使い方: 暗号化していること自体は確認できても、アルゴリズムの選択、鍵の管理方法、初期化ベクトルの扱いといった実装の妥当性は専門領域です
• 業務ロジック起因の抜け: 「割引を複数回適用できてしまう」「特定の順番で操作すると承認をスキップできる」といった、コード単体では正しく見えるが組み合わせると破綻する問題
• セッション管理と認証フローの実装: トークンの有効期限、失効処理、多要素認証の実装は、細部の誤りが致命的な影響につながります
• 外部連携における信頼境界の設計: 外部APIから受け取ったデータをどこまで信頼するか、という設計判断

これらは「うちには判定できる人がいないので、外部に見てもらう領域」として明示的にリスト化しておきましょう。判定できないことを認識して外部に委ねるのは、放置とはまったく違います。この選択肢については、のちほど「社内に判定できる人がいない場合の3つの選択肢」で具体的に扱います。

脆弱性診断・ペネトレーションテストとの違いと使い分け

「脆弱性診断を受けているので、コードレビューは不要では」という質問をよく耳にします。結論から言えば、両者は見つかるものが違うため、片方だけでは抜けが生じます。

見つかるものが違う（実装の誤りと、稼働環境の穴）

セキュリティコードレビューは、コードの中身を読んで実装の誤りを探します。動かさなくても実施でき、まだリリースしていない機能でも検証できます。一方、脆弱性診断は稼働しているシステムに外部からリクエストを送り、実際に反応する弱点を探します。

たとえば、管理者機能に権限チェックが書かれていないという実装の誤りは、コードレビューなら確実に見つかります。一方、それが外部から到達可能かどうかは、ネットワーク構成やアクセス制限にも依存するため、診断でしか確定しません。逆に、まだ社内公開していない開発中の機能に潜む問題は、診断の対象になりません。

実施タイミングの使い分け

現実的な運用としては、次のように組み合わせるのが基本形です。

予算に制約がある場合の優先順位としては、まず静的解析を CI に組み込み、次に影響度の高い領域だけ目視レビューを回す形から始めるのが現実的です。脆弱性診断は費用が発生するため、対外的な要求（顧客からの要請、認証取得）が生じたタイミングに合わせて計画する、という判断もありえます。

診断そのものの依頼先選定や費用の考え方については、脆弱性診断の外注で詳しく整理しています。

レビューを契約と受け入れ手順に組み込む

ここまでの内容を実行できたとしても、それが担当者の善意と気合いに依存している限り、長続きしません。人が代わればなくなりますし、忙しい時期には省略されます。

レビューを「やろうと思ったときにやること」から「発注プロセスに埋め込まれた工程」に変える。これが、説明責任を継続的に果たすための最後のピースです。

発注時に合意しておく5項目

新しい委託契約を結ぶとき、あるいは既存契約を更新するときに、次の5項目を合意しておきます。契約書の条文でも、発注書の付属仕様書でも、議事録でも構いません。文書として残っていることが重要です。

IPA が公開している「情報システム・モデル取引・契約書（第二版）」でも、システムに実装すべきセキュリティ仕様は、発注者とベンダーが協議して決めるものとして位置づけられています（IPA 情報システム・モデル取引・契約書（第二版））。セキュリティ要件を発注側が示さず、あとから「当然やってくれていると思った」と主張するのは、契約上も無理があります。

修正費用の負担については、指摘の性質によって扱いが変わります。合意した要件を満たしていない実装であれば無償修正、要件になかった追加対策であれば別途見積り、という切り分けが基本になります。この線引きを事前に決めておけば、指摘のたびに交渉する必要がなくなります。契約上の責任範囲を細かく詰める必要がある場合は、法務の確認を受けることをおすすめします。

受け入れ（検収）判定にレビュー結果をどう反映するか

合意した内容は、受け入れ時の判定基準にも接続させます。ここが曖昧だと、「動いているから受け入れる」という従来の運用に戻ってしまいます。

判定の考え方はシンプルです。

• Critical の未解決指摘がある: 受け入れを保留する
• High の未解決指摘がある: 対応期限と担当を明記したうえで、条件付きで受け入れる
• Medium 以下: 指摘票に記録し、次回以降の対応計画に載せたうえで受け入れる
• 指摘票そのものが存在しない: レビューが実施されていないため、受け入れ判定の前提を満たしていない

最後の項目が実は最も重要です。「指摘がゼロ」と「レビューをしていない」はまったく違う状態ですが、記録がなければ区別がつきません。指摘票の提出そのものを受け入れの必要条件にしておけば、レビュー工程が省略されることを防げます。

なお、レビューで繰り返し同じ種類の指摘が出る場合は、個別の修正ではなく、外部エンジニアと実装方針そのものを共有し直したほうが効率的です。作り込みの段階で防ぐアプローチについては、外部エンジニアへのセキュリティ教育で扱っています。

生成AIで書かれたコードが混ざる前提での追加合意

2026年現在、外部エンジニアが生成AIを活用してコードを書くことは一般的になっています。IPA の「情報セキュリティ10大脅威 2026」でも、「AIの利用をめぐるサイバーリスク」が組織向けの第3位に初選出されました。レビューの前提が変わってきていると考えたほうがよいでしょう。

生成AIが書いたコードそのものが危険だという話ではありません。問題は、次のような性質にあります。

• もっともらしく見える: 構文的に整っていて読みやすいため、レビューで違和感を持ちにくい
• 文脈が反映されにくい: 自社固有の権限モデルや業務ルールは、AIには分かりません。汎用的には正しいが、自社の設計とはずれている実装が生まれます
• 書いた本人の理解が浅い場合がある: 「なぜこの実装にしたのか」を説明できないと、レビューで根拠を確認する手段が失われます
• 依存ライブラリの選択が古い可能性がある: 学習時点の情報に基づいた、更新の止まったライブラリが提案されることがあります

そこで、発注時に次の3点を追加で合意しておくことをおすすめします。

1. 利用の可否と申告: 生成AIの利用を認めるか、認める場合はどの範囲か。利用した場合に申告を求めるか
2. 秘密情報の取り扱い: 自社のソースコード・個人データ・認証情報を外部のAIサービスに入力してよいか。禁止する場合は具体的に明記する
3. 成果物の説明責任: 生成AIを使った場合でも、実装内容と選択理由を説明できる状態にすること

これらを事前に決めておけば、レビューの場で「なぜこの実装にしたのですか」と聞いたときに、説明が返ってくる状態を保てます。生成AIを使った外注コードの品質と責任の考え方については、生成AIで書かれた外注コードの品質と責任で詳しく整理しています。

社内に判定できる人がいない場合の3つの選択肢

3層仕分けの (C) に分類した「専門家でなければ判定できない観点」を、どう埋めるか。社内に人がいないことを前提に、現実的な選択肢を3つ挙げます。

いずれの選択肢にも共通する原則が1つあります。レビュアーと実装者を分けることです。実装した本人が自分のコードをレビューしても、思い込みは検出できません。誰に頼むにせよ、この分離だけは守ってください。

レビュー専任の外部エンジニア・技術顧問を薄く確保する

実装を担当している外部エンジニアとは別に、レビューだけを担当する外部エンジニアを月数時間から確保する方法です。

• 向いているケース: 継続的に開発が動いていて、リリースのたびにレビューが必要な場合
• 稼働量の目安: 影響度の高い領域に絞れば、月4〜8時間程度から始められます。リリース頻度が高い場合は増やします
• メリット: 自社のコードベースと業務を理解した人が継続的に見るため、回を重ねるごとに精度が上がります。指摘の背景も説明してもらえます
• 注意点: 実装担当エンジニアと利害関係のない人を選ぶこと。同じ会社の所属だったり、紹介元が同じだったりすると、指摘が甘くなる可能性があります

技術顧問という形で契約すれば、レビューだけでなく実装方針の相談にも応じてもらえるため、指摘が減っていく効果も期待できます。副業・複業のかたちで参画してもらえば、フルタイムで雇用するより低コストで専門性を確保できます。

相互レビューが成立する人数・体制を契約要件にする

実装を担当する外部エンジニアを2名以上の体制にし、相互にコードをレビューすることを契約要件に含める方法です。

• 向いているケース: 開発規模が一定以上あり、もともと複数名体制を検討している場合
• メリット: 追加のレビュー費用が実質的に開発費に含まれるため、コスト効率がよい。実装者どうしなので、指摘が具体的で修正も速い
• 注意点: 2名が同じ会社・同じチームから来ている場合、相互チェックが形式化するおそれがあります。プルリクエストの承認記録を発注側が定期的に確認し、承認だけでコメントがない状態が続いていないかを見てください
• 限界: 実装者どうしのレビューは、実装の誤りには強いものの、設計そのものの妥当性や暗号の扱いといった専門領域までは踏み込めないことがあります

この方法は、1人体制のときに生じるセルフレビュー問題を構造的に解消できるという点で、費用対効果が高い選択肢です。契約時に「コードレビューは実装者以外が行い、承認記録を残す」と明記するだけで実現できます。

専門ベンダーにスポットで依頼する

セキュリティ専門の事業者に、期間や範囲を区切ってセキュリティコードレビューを依頼する方法です。

• 向いているケース: 大きなリリース前、顧客からセキュリティ要求が来たとき、認証取得の準備段階など、対外的な根拠が必要な場面
• 依頼範囲の切り出し方: 全コードではなく、ステップ1で絞り込んだ第1優先の領域だけを対象にします。「認証・認可・決済まわりのコードレビュー」といった形で範囲を明示すると、見積りも精度が上がります
• 費用感の考え方: 対象となるコードの行数と機能数で見積られることが一般的です。範囲を絞ることが、そのまま費用のコントロールになります
• メリット: 第三者の専門機関が実施したという事実は、取引先や監査に対する説明力が高くなります
• 注意点: 単発で終わると、その後の変更部分はカバーされません。スポット依頼で洗い出した問題の傾向を、日常のレビュー観点に取り込む前提で計画してください

3つの選択肢は排他ではありません。日常は相互レビューと静的解析で回し、年1回だけ専門ベンダーに見てもらう、という組み合わせが現実的です。重要なのは、判定できない領域を「誰が、いつ見るか」を決めて空白にしないことです。

まとめ｜セキュリティコードレビューを今日から始める順番

セキュリティコードレビューは、全コードを専門家に見てもらう大がかりな取り組みではありません。範囲を決め、機械にかけ、人が要点を見て、記録を残す。この4つの動作を回すだけで、「誰も検証していない」状態からは抜け出せます。

最後に、明日から着手できる順番を4ステップに圧縮して整理します。

1. 影響度の高い領域を1つ決める: 認証・認可・決済・個人データ・外部連携のうち、自社で最も影響が大きいものを1つ選びます。全部やろうとしないことが、続けるための条件です
2. その領域のレビュー観点を3層に仕分ける: 自分で確認できること・エンジニアに質問すること・専門家に任せることを紙に書き出します。ここまでで、社内でできる範囲が見えます
3. 次回の発注時に合意5項目を入れる: レビュー対象範囲、実施主体、重大度の定義、対応期限、未解決指摘の扱い。契約更新のタイミングを逃さないでください
4. 指摘票と証跡のフォーマットを用意する: スプレッドシート1枚で構いません。範囲・実施日・実施者・指摘・対応区分・判断根拠が入っていれば十分です

この4ステップを1領域で回してみると、思ったより負荷が小さいことに気づくはずです。そこから対象領域を1つずつ広げていけば、無理なく守備範囲が広がります。なお、セキュリティ以外の観点も含めてレビュー体制そのものを整えたい場合は、外部エンジニアのコードレビューを依頼する方法と品質担保の仕組みとあわせてご覧いただくと、品質全般とセキュリティの両輪で設計できます。

冒頭の「委託先のコードはどう検証していますか」という問いに対して、完璧な答えを用意する必要はありません。「この範囲を、この方法で、この基準に沿って検証し、結果をこう扱っています」と説明できること。それが、発注者としての説明責任を果たすということです。範囲を明示して記録に残す。今日からできるのは、そこからです。

関連情報

外部エンジニアとの体制設計や品質管理の進め方をまとめてご覧になりたい方は、外部エンジニアのマネジメントガイドをご覧ください。レビュー工程を含む発注フローの整理にご活用いただけます。

レビュー体制の設計や、実装とは別のレビュー担当エンジニアの確保についてご相談がある場合は、お問い合わせフォームからご連絡ください。現状の体制を伺ったうえで、進め方を一緒に整理します。