安全にバイブコーディングできていますか？ ─ Gitleaks と AWS CDK MCP Servers で始めるセキュアなAI開発

AI, AWS, CDK, CDK-Nag, Cursor, GitLeaks, MCP, バイブコーディング

本記事の対象読者

  • Cursor などの AI ツールを活用した開発を行っているエンジニア
  • AWS CDK を使って IaC 開発しているエンジニア

はじめに

レコチョクのシステム開発第1グループに所属している山根と申します。
普段は OpenAI・Anthropic (Claude)・Google (Gemini) のモデル等に対応したチャット基盤を運営・開発しております。
弊社では、AIツールの積極利用および検証に努めております。

概要

生成AIを活用したバイブコーディング (AIと対話しながら進める開発) を取り入れるエンジニアも増えてきている一方で、コードやIaC (Infrastructure as Code) における「うっかりしたセキュリティの事故」も増加傾向にあると思います。

事実、GitGuardian社（ソースコードに含まれるAPIキーなどの機密情報を検知するセキュリティサービスを提供する企業）の「State of Secrets Sprawl」レポートによると、2024年に2,380万件の秘密情報が漏洩し、今年はさらに前年比の25%も増加したと報告されています。さらに驚くべきことに、2022年に漏洩した秘密情報の70%が現在も有効というデータも報告されています¹。

本記事では、次の2つの代表的なリスクと、それに対する実践的な対策方法を紹介します。

  • Git に誤って秘密情報を含めてしまうリスク → Gitleaks による検出
  • AWS CDK で構成ミスやセキュリティ設計漏れをするリスク → AWS CDK MCP Server と CDK-Nag による検知

1. Gitleaks で秘密情報の漏洩を防ぐ

なぜ必要か

AI ツールや自動生成の効率に頼るほど、 .envファイルや API キーをコードに直接貼り付けてしまう場面が増えます。特に Cursor のような AI ツールを使用している場合、コンテキストとして機密情報を含んだまま開発を進めてしまうリスクがあります。

Gitleaks は、正規表現とエントロピーチェックを組み合わせて、コミット履歴、ブランチ、タグから秘密情報を検出するツールです²。

例：NGなコード
# .env
OPENAI_API_KEY=sk-abc123xyz456...
AWS_ACCESS_KEY_ID=AKIA123IOSFODN...
AWS_SECRET_ACCESS_KEY=w23Jal123rXUtnxwfiwjFEMI/K7XDFENG/bPxRf...

// app.ts
const openaiKey = process.env.OPENAI_API_KEY || "sk-abc123xyz456...";

このまま git add . && git commit を実行すると、APIキーがGitの履歴に記録されてしまいます。

Gitleaks の導入方法 (pre-commit hook)

Gitleaks は、2025年現在も活発に開発が続いており、160種類以上の秘密情報パターンを検出できるようです。

.pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.28.0  # 2025年7月時点の最新版
    hooks:
      - id: gitleaks

# 初期化
pre-commit install
 
# コミット前に自動スキャンされるようになる

検出例（実行結果）
$ pre-commit run --all-files
Detect hardcoded secrets.................................................Failed
- hook id: gitleaks
- exit code: 1
 
    ○
    │╲
    │ ○
    ○ ░
    ░    gitleaks
 
Finding:     const jwtToken = "REDACTED"
Secret:      REDACTED
RuleID:      jwt
Entropy:     5.444070
File:        app.ts
Line:        9
Fingerprint: app.ts:jwt:9
 
Finding:     OPENAI_API_KEY=REDACTED
Secret:      REDACTED
RuleID:      generic-api-key
Entropy:     4.680758
File:        .env
Line:        2
Fingerprint: .env:generic-api-key:2
 
12:35AM INF 1 commits scanned.
12:35AM INF scanned ~1578 bytes (1.58 KB) in 66.5ms
12:35AM WRN leaks found: 2

出力の詳細解説

上記の出力を詳しく分解すると以下のようになります

1. 実行結果の概要

  • Detect hardcoded secrets...Failed: ハードコードされた秘密情報が検出されたため失敗
  • hook id: gitleaks: 実行されたツールはGitleaks
  • exit code: 1: エラーありを示すコード（0以外）でコミットをブロック

2. アスキーアートの表示

  • 公式の”banner”として、機密情報の漏洩を表現
  • ○は水滴、 │╲は流れる軌跡、 ░は漏れ出した情報の染みを表現し、「Git」+「Leaks（漏れ）」というツール名の通り、コードから秘密情報が滴り落ちる様子を直感的に表現
  • --no-bannerオプションで非表示可能（CI/CD環境などで有用）

3. 検出された秘密情報の詳細

項目 説明
Finding 検出されたコードの該当箇所（ REDACTEDで伏せ字表示）
RuleID 適用されたルール（ jwt=JWTトークン、 generic-api-key=APIキー）
Entropy ランダム性の度合い（高いほど秘密情報らしいと判定）
File 検出されたファイル名
Line 検出された行番号
Fingerprint 問題の一意識別子（CI/CDでの追跡に使用）

4. スキャン結果のサマリ

  • 1 commits scanned: 1つのコミットを検査
  • scanned ~1578 bytes: 約1.5KBのコードを66.5msで高速処理
  • leaks found: 2: 合計2つの秘密情報を検出

これにより、「コミット前に」漏洩の芽を摘むことができます。

Gitleaks の高度な活用方法

1. 非アクティブな秘密情報の許可リスト更新

.gitleaks.tomlファイルで、ローテーション済みや無効化された秘密情報を許可リストに追加できます³
title = "gitleaks config"
 
[extend]
useDefault = true
 
[allowlist]
regexTarget = "match"
description = "rotated or false positive secrets"
regexes = [
  '''1234567890abcdef1234567890abcdef''',  # 無効化済みのトークン
  '''sk-proj-old-key-rotated-2024''',       # ローテーション済みのOpenAI APIキー
]

2. スキャン短縮のための設定

大規模なリポジトリでは、スキャン範囲を限定することで処理時間を短縮できます
# 最新の1000コミットのみをスキャン
gitleaks detect --log-opts="-n 1000"
 
# 秘密情報を隠蔽 (redact) して表示
gitleaks detect --redact
 
# 特定のディレクトリのみスキャン
gitleaks detect --source /path/to/directory

3. CI/CD への統合

GitHub Actions での実装例
name: gitleaks
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 全履歴を取得
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

2. AWS CDK MCP Server と CDK-Nag でセキュリティを強化する

AWS MCP とは

2024年12月に AWS が発表した AWS MCP Servers は、AI アシスタントが AWS サービスやリソースと対話するための標準化されたプロトコルです⁴。これにより、Cursor などの AI ツールが CDK のベストプラクティスを理解し、セキュアなインフラコードの生成を支援します。

MCP サーバーは以下のような AWS サービスに対応しています

  • AWS Lambda
  • Amazon Bedrock
  • AWS CloudFormation
  • Amazon CloudWatch Logs
  • Amazon DynamoDB
  • Amazon EC2
  • Amazon ECS
  • Amazon RDS
  • Amazon S3
  • AWS IAM

なぜ必要か

CDK は非常に柔軟なツールですが、デフォルトのまま書いてしまうとセキュリティ上のベストプラクティスを見落とすことがあります。CDK-Nag は、AWS Solutions、HIPAA、NIST、PCI などの規制フレームワークに基づいて、CDK アプリケーションのセキュリティ・コンプライアンス検証できるツールです⁵。

例：NG な CDK コード (暗号化なしのS3バケット)
new s3.Bucket(this, "MyBucket", {
  removalPolicy: RemovalPolicy.DESTROY,
});

このコードには、暗号化やパブリックアクセスの制限設定が含まれていません。

AWS CDK MCP Server の導入

AWS CDK MCP Server は、以下の機能を提供します⁶

  • CDK Nag ルールの説明: AWS Well-Architected に基づいたセキュリティルールの詳細な説明
  • AWS Solutions Constructs: 検証済みのアーキテクチャパターンの検索と実装
  • セキュリティ自動化: CDK NagとLambda Powertoolsの統合
  • Bedrock Agent スキーマ生成: Lambda関数を使用したAction Groupsの自動スキーマ生成

Cursor での設定例
// ~/.aws/amazonq/mcp.json
{
  "mcpServers": {
    "awslabs.cdk-mcp-server": {
      "command": "uvx",
      "args": ["awslabs-cdk-mcp-server@latest"],
      "autoApprove": ["read_resource", "list_resources"]
    }
  }
}

設定が完了すると、Cursor で AWS CDK MCP Server の豊富なツールが利用可能になります

cdk_mcp_server_with_cursor.png

図：Cursor での AWS CDK MCP Server 設定画面。CheckCDKNagSuppressions や ExplainCDKNagRule などのセキュリティ分析機能が利用可能

CDK-Nag の導入と活用
npm install cdk-nag

CDK コードに次のように適用します⁷
import { AwsSolutionsChecks, NagSuppressions } from "cdk-nag";
import { Aspects } from "aws-cdk-lib";
 
// Nagチェックを有効化
Aspects.of(this).add(new AwsSolutionsChecks({ verbose: true }));

警告出力例
[Error at /CdkTestWithNagStack/ProblematicBucket/Resource] AwsSolutions-S1: The S3 Bucket has server access logs disabled. The bucket should have server access logging enabled to provide detailed records for the requests that are made to the bucket.
 
[Error at /CdkTestWithNagStack/ProblematicBucket/Resource] AwsSolutions-S10: The S3 Bucket or bucket policy does not require requests to use SSL. You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies.

CDK コードの設計段階で、セキュリティ不備が「明示的に」指摘されるようになります。

注意: CDK のバージョンや設定によって検出される警告は異なる場合があります。AWS CDK のデフォルト設定は継続的に改善されており、最新版では暗号化やパブリックアクセス制限などが自動的に適用される場合があります。

バイブコーディングも「完璧」ではない ─ AWS CDK MCP Server が教えてくれる改善ポイント

バイブコーディングは非常に便利ですが、「セキュアな S3 バケットを書いて」と指示しても、設定が一部抜けたコードが出てくることもあります。
AWS CDK MCP Server を通してバイブコーディングを行うと、設計ミスを即座に検知し、ベストプラクティスに沿った改善提案をしてくれるのが大きな強みです。

例：バイブコーディングで生成されたコード
const bucket = new s3.Bucket(this, "MyBucket", {
  versioned: true,
});

一見シンプルで問題なさそうに見えますが、AWS CDK MCP Server を経由すると以下のような指摘を受けます
[警告] AwsSolutions-S1: S3バケットにサーバーアクセスログが設定されていません。
[警告] AwsSolutions-S10: SSL通信の強制が行われていません。

AWS CDK MCP Server により補正されたコード例
const bucket = new s3.Bucket(this, "SecureBucket", {
  encryption: s3.BucketEncryption.S3_MANAGED,
  blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
  enforceSSL: true,
  versioned: true,
});

このように、バイブコーディングでも見落とされがちな部分を補完してくれるのが AWS CDK MCP Server の真価です。
単なるコードジェネレーターではなく、「 AWS のセキュリティ要件やベストプラクティス」を AI が”構造的に理解”したうえで設計をガイドしてくれる仕組みとなっています。

セキュアな S3 バケットの実装例
import { NagSuppressions } from 'cdk-nag';
 
const logsBucket = new s3.Bucket(this, "LogsBucket", {
  encryption: s3.BucketEncryption.S3_MANAGED,
  blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
  enforceSSL: true,
  versioned: true,
  lifecycleRules: [{
    expiration: cdk.Duration.days(90)
  }]
});
 
const bucket = new s3.Bucket(this, "SecureBucket", {
  // 暗号化の有効化
  encryption: s3.BucketEncryption.S3_MANAGED,
 
  // パブリックアクセスの完全ブロック
  blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
 
  // SSL通信の強制
  enforceSSL: true,
 
  // バージョニングの有効化
  versioned: true,
 
  // アクセスログの有効化
  serverAccessLogsBucket: logsBucket,
  serverAccessLogsPrefix: 'access-logs/'
});
 
// 必要に応じて特定のルールを抑制（理由を明記）
NagSuppressions.addResourceSuppressions(
  logsBucket,
  [
    {
      id: "AwsSolutions-S1",
      reason: "これはログバケット自体なので、アクセスログは不要"
    }
  ]
);

3. 実践的な活用例

Cursor を使った安全な開発フロー

  1. 事前準備
    • Gitleaks を pre-commit hook として設定
    • AWS CDK MCP Server を Cursor に設定
    • CDK-Nag を開発パイプラインに組み込む
  2. 開発時の流れ

    # AWS CDK MCP Serverを使ってセキュアなコードを生成
    # Cursorに「AWS Well-Architectedに準拠したS3バケットを作成して」と指示
     
    # Gitleaksが自動的にコミット前にチェックを行う
    git commit -m "Add secure S3 bucket"
     
    # CDK-Nagでインフラコードを検証
    cdk synth

  3. CI/CD パイプラインでの統合

    # GitHub Actions例
    name: Security Check
    on: [push, pull_request]
     
    jobs:
    secrets-scan:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
           with:
             fetch-depth: 0
         - uses: gitleaks/gitleaks-action@v2
     
    cdk-check:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with:
             node-version: '20'
         - run: npm ci
         - run: npx cdk synth
         - name: Run CDK Nag
           run: |
             npm test  # CDK-Nagを含むテストを実行

4. 対策まとめ

リスク 対応ツール 効果
コード内の API キー・パスワードの漏洩 Gitleaks コミット前に機密情報を自動検出・ブロック
AWS リソース構成のセキュリティ設定漏れ CDK-Nag 暗号化・アクセス制限の有無を静的に警告
インフラ構成の設計ミスやベストプラクティス違反 AWS CDK MCP Server AI アシスタントによる設計時のガイダンスとコード生成

おわりに

AI ツールによって開発体験が向上する一方で、セキュリティ面のリスクはこれまで以上に敏感になる必要があると考えています。

今回紹介した Gitleaks・AWS CDK MCP Server・CDK-Nag のようなツールはごく一部ですが、活用することで、開発スピードとセキュリティの両立が可能になります。

「安全にバイブコーディングできているか？」を自問し、今日からの良き開発ライフの一助になれば幸いです。

参考リンク

AI, AWS, CDK, CDK-Nag, Cursor, GitLeaks, MCP, バイブコーディング