株式会社Berry
🐡

Claude Code GitHub Actionsで実現!重要な仕様を見逃さないレビュー自動化とチーム開発の革新

に公開

Claude Code GitHub Actionsによる監査ログ実装チェックの自動化

こんにちは、株式会社Berryの浅沼です。
今回は、品質管理システム(QMS)の開発で導入したClaude Code GitHub Actionsによる監査ログ実装チェックの自動化について、実装の詳細と運用効果をご紹介します。

eQMSでは監査ログが必須要件となることが多いですが、手動でのレビューだけでは実装漏れのリスクが常に付きまといます。この課題をAIの力で解決した取り組みについて、具体的な実装から運用まで詳しく解説していきます。

1. はじめに - なぜ監査ログの自動チェックが必要だったのか

背景:QMSにおける監査ログの重要性

QMSmart(品質管理システム)では、文書の作成・更新・削除、承認フロー、ユーザー操作など、あらゆるデータ操作に対して監査ログの記録が求められます。これは単なる要件ではなく、ER/ES指針(厚生労働省による医薬品等の製造販売業者等における電子記録・電子署名の活用に関するガイドライン)の観点から必須の機能です。

特に以下のような操作では、監査ログの実装が欠かせません:

  • 文書の作成・更新・削除
  • 承認・却下などの状態変更
  • ユーザー権限の変更
  • 一括操作(インポート・エクスポート)

課題:手動レビューによる実装漏れのリスク

従来は、プルリクエストレビュー時に人間の目でチェックしていましたが、以下の問題が頻発していました:

  • 見落としのリスク: 複数ファイルの変更で監査ログ実装を見逃す
  • 属人化: レビュアーによってチェック精度にばらつき
  • レビュー工数: 毎回の手動確認で時間がかかる
  • 学習コスト: 新メンバーが監査ログのパターンを覚える負担

実際に、重要な機能で監査ログが抜けていたことが本番リリース直前に発覚し、急ぎ、追加を行ったことがあります。

解決方針:AI活用による自動化の検討

そこで、Claude Code GitHub Actionsを利用して、プルリクエスト時に自動で監査ログ実装をチェックする仕組みを導入することにしました。

2. 監査ログ実装チェックの要件定義

チェック対象の条件

まず、どのような場合に監査ログが必要かを明確に定義しました:

  1. .vueファイルで@clickイベントが含まれている

    • ユーザーのボタン操作を起点とする処理
  2. データ操作(CRUD)を行っている

    • repositories/配下の関数呼び出し
    • insert, update, delete, createなどの操作
  3. 状態変更を伴う操作

    • approve, reject, activate, deactivateなど
    • データ一括操作(bulk operation, import, export)

必要な監査ログ実装

監査ログが必要と判定された場合、以下の実装が求められます:

  1. 適切なインポート
import { createAuditLogCommon } from "@/utils/auditlog/common";
// または
import { createDocumentAuditLog } from "@/utils/auditlog/document";
  1. 監査ログ関数の呼び出し
// データ操作と同じ関数内または呼び出し先で
await createAuditLogCommon({
  action: "delete",
  target_type: "document",
  target_id: documentId,
  details: { reason: deleteReason }
});
  1. 適切なパラメータの設定
    • action: 操作の種類
    • target_type: 対象オブジェクトの種類
    • target_id: 対象の識別子
    • details: 操作の詳細情報

3. Claude Code GitHub Actionsの実装

ワークフロー設計

.github/workflows/auditlog_check.ymlで実装したワークフローの核心部分です:

name: AuditLog Check
on:
  pull_request:
    types: [opened, synchronize]
    branches:
      - release/*
      - release/uat/*
      - development
    paths:
      - "src/components/**"

defaults:
  run:
    shell: bash

concurrency:
  group: ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-${{ github.workflow }}-auditlog-check
  cancel-in-progress: true

jobs:
  auditlog-check:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # 変更ファイルを比較するため全履歴を取得

      - name: Get changed files
        id: changed-files
        run: |
          # プルリクエストの変更ファイル一覧を取得
          git diff --name-only origin/${{ github.base_ref }}...HEAD > changed_files.txt
          echo "Changed files:"
          cat changed_files.txt

      - name: AuditLog Implementation Check
        uses: anthropics/claude-code-action@beta
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          timeout_minutes: "30"
          direct_prompt: |
            # Audit Log チェック

            ## 目的
            プルリクエストで変更されたファイルの中で、ボタンによるアクションがあり、
            データの操作(作成・更新・削除)を行っている場合に、
            適切なauditlog処理が実装されているかチェックする。

            ## チェック対象の条件
            1. `.vue` ファイルで `@click` イベントが含まれている
            2. データ操作(作成・更新・削除)を行っている(repositories/ 配下の関数呼び出し)
            3. 以下のパターンのいずれかに該当する:
               - リポジトリ関数で CRUD 操作(insert, update, delete, create など)
               - 状態変更(approve, reject, activate, deactivate など)
               - データ一括操作(bulk operation, import, export など)

            ## チェック内容
            上記条件に該当するファイルで、以下のauditlog処理が実装されているかチェック:

            ### 必要なauditlog実装
            1. `src/utils/auditlog/` 配下の関数のインポート
            2. データ操作と同じ関数内またはその呼び出し先でauditlog関数の呼び出し
            3. 適切なauditlogパラメータの設定

            ### 対象となるauditlog関数の例
            - `createAuditLogCommon` (基本関数)
            - `createDocumentAuditLog`, `createDocumentVersionAuditLog`
            - `createEventAuditLog`, `createTrainingAuditLog`
            - その他 `src/utils/auditlog/` 配下の関数

            ## 実行手順
            1. 変更ファイル一覧(changed_files.txt)を確認
            2. 対象条件に該当するファイルを特定
            3. 該当ファイルでauditlog処理の実装状況をチェック
            4. 実装漏れがある場合は詳細レポートを作成
            5. 問題がない場合は「✅ AuditLog チェック完了」とレポート

            ## レポート形式
            実装漏れがある場合:
            ```
            ❌ AuditLog実装チェックで問題を検出

            ### 問題のあるファイル
            - `ファイルパス`: 問題の詳細
              - 検出されたデータ操作: 具体的な操作内容
              - 欠けているauditlog処理: 必要な処理の説明
              - 推奨される実装: 具体的な実装例

            ### 推奨アクション
            各ファイルで適切なauditlog処理を追加してください。
            ```

            問題がない場合:
            ```
            ✅ AuditLog チェック完了

            チェック対象ファイル: X件
            auditlog実装済み: Y件
            対象外ファイル: Z件
            ```

ポイントは、プルリクエストのたびに変更ファイルを特定し、Claudeに渡すことです。

プロンプトエンジニアリング

Claudeへの指示(プロンプト)は、検出精度の要となる部分です。Claude Code GitHub ActionsのBeta版では、direct_promptパラメータを使用します。このブログを書いている時点でv1が利用可能になっています。betaとv1の違いについては、公式ドキュメントを参照ください。

https://code.claude.com/docs/ja/github-actions#ベータ版からのアップグレード

メインプロンプト(具体的な指示):

direct_prompt: |
  # Audit Log チェック

  ## 目的
  プルリクエストで変更されたファイルの中で、ボタンによるアクションがあり、
  データの操作(作成・更新・削除)を行っている場合に、
  適切なauditlog処理が実装されているかチェックする。

  ## チェック対象の条件
  1. `.vue` ファイルで `@click` イベントが含まれている
  2. データ操作(作成・更新・削除)を行っている(repositories/ 配下の関数呼び出し)
  3. 以下のパターンのいずれかに該当する:
     - リポジトリ関数で CRUD 操作(insert, update, delete, create など)
     - 状態変更(approve, reject, activate, deactivate など)
     - データ一括操作(bulk operation, import, export など)

  ## チェック内容
  上記条件に該当するファイルで、以下のauditlog処理が実装されているかチェック:

  ### 必要なauditlog実装
  1. `src/utils/auditlog/` 配下の関数のインポート
  2. データ操作と同じ関数内またはその呼び出し先でauditlog関数の呼び出し
  3. 適切なauditlogパラメータの設定

4. 実装の詳細とポイント

ファイル変更検出の仕組み

git diff --name-only origin/${{ github.base_ref }}...HEAD > changed_files.txt

この1行で、プルリクエストで変更されたファイル一覧を取得しています。fetch-depth: 0により全履歴を取得し、ベースブランチとの差分を正確に検出します。

プロンプトの設計思想

プロンプト設計で特に重視した点:

  1. 段階的な判定プロセス

    • まず対象ファイルを特定
    • 次に対象操作を検出
    • 最後に監査ログ実装を確認
  2. 具体的な検出パターンの明示

    - リポジトリ関数で CRUD 操作(insert, update, delete, create など)
    - 状態変更(approve, reject, activate, deactivate など)
    
  3. レポート形式の標準化

    ❌ AuditLog実装チェックで問題を検出
    
    ### 問題のあるファイル
    - `ファイルパス`: 問題の詳細
      - 検出されたデータ操作: 具体的な操作内容
      - 欠けているauditlog処理: 必要な処理の説明
      - 推奨される実装: 具体的な実装例
    

レポート生成の工夫

実装漏れを検出した場合の出力例:

❌ AuditLog実装チェックで問題を検出

### 問題のあるファイル

- `src/components/document/DocumentDeleteButton.vue`: 削除処理でauditlog実装が不足
  - 検出されたデータ操作: documentRepository.delete() の呼び出し
  - 欠けているauditlog処理: 削除操作の監査ログ記録
  - 推奨される実装:

    ```typescript
    import { createDocumentAuditLog } from "@/utils/auditlog/document";

    // 削除処理後に追加
    await createDocumentAuditLog({
      action: "delete",
      document_id: targetDocument.id,
      details: { reason: deleteReason }
    });
    ```

### 推奨アクション

適切なauditlog処理を追加してください。

5. 運用開始後の効果と改善

検出精度の向上

初期の課題
運用開始直後は、以下のような誤検出が発生していました:

  • 読み取り専用の操作(検索、表示)でも監査ログを要求
  • テストファイルの変更でも警告が発生
  • UIコンポーネントの見た目変更でも検出

改善策
プロンプトに以下の除外条件を追加:

## 除外条件
以下の場合は監査ログ不要:
- 読み取り専用操作(select, find, get など)
- テストファイル(*.test.ts, *.spec.ts)
- UIの見た目のみの変更(スタイル、レイアウト)

結果、誤検出率を大幅に削減することができました。

6. 実際の検出事例

典型的な実装漏れパターン

ケース1:削除機能の監査ログ漏れ

変更前:

<template>
  <button @click="deleteDocument">削除</button>
</template>

<script setup lang="ts">
  const deleteDocument = async () => {
    await documentRepository.delete(documentId);
    // 監査ログの実装が漏れている
    router.push("/documents");
  };
</script>

AIの検出レポート:

❌ 検出されたデータ操作: documentRepository.delete()
推奨される実装: createDocumentAuditLogの呼び出しを追加

修正後:

const deleteDocument = async () => {
  await documentRepository.delete(documentId);

  // 監査ログを追加
  await createDocumentAuditLog({
    action: "delete",
    document_id: documentId,
    details: { reason: deleteReason }
  });

  router.push("/documents");
};

ケース2:承認機能の監査ログ漏れ

AIが検出したのは、承認処理での状態変更に監査ログが不足していたケースです:

// 変更前(監査ログなし)
const approveDocument = async () => {
  await documentRepository.updateStatus(documentId, "approved");
};

// 修正後(監査ログ追加)
const approveDocument = async () => {
  await documentRepository.updateStatus(documentId, "approved");

  await createDocumentAuditLog({
    action: "approve",
    document_id: documentId,
    details: { approver_comment: comment }
  });
};

開発者の学習効果

興味深いことに、AIの指摘を受けた開発者が自発的に他のファイルでも監査ログ実装を見直すケースが増えました。AIが具体的な実装例を示すため、学習効果が高いことがわかりました。

プロンプト設計のベストプラクティス

複数のチェックを実装して見えてきたベストプラクティス:

  1. 明確な条件定義:曖昧さを排除した判定条件
  2. 段階的処理:ファイル特定 → 対象操作検出 → 実装確認
  3. 具体的な修正例:開発者がすぐに対応できる実装例の提示
  4. 除外条件の明記:誤検出を防ぐ明確な除外ルール

7. まとめと今後の展望

導入効果のまとめ

Claude AIによる監査ログ実装チェックの自動化により、以下の効果を得ることができました:

品質向上

  • 監査ログ実装漏れの撲滅
  • 一貫性のある実装品質
  • コンプライアンス要件の確実な対応

開発効率

  • レビュー工数の大幅削減
  • 属人化の解消
  • 新メンバーの学習支援

リスク軽減

  • 監査対応での証跡不足の回避

今後の改善計画

より高度なコンテキスト理解
現在は個別ファイルの検査が中心ですが、将来的にはファイル間の関連性やビジネスロジックの文脈も考慮したチェックを検討しています。

プロンプトの継続改善
実際の運用データを基に、検出精度のさらなる向上を目指します。

AI活用開発の可能性

今回の取り組みを通じて、AIは単なる開発支援ツールではなく、チーム全体の知識とノウハウを標準化・共有する強力な仕組みになることを実感しました。

特に以下の領域での活用可能性を感じています:

  • コードレビューの高度化
  • ドキュメント生成と品質チェック
  • テスト設計とカバレッジ分析
  • セキュリティ・コンプライアンス対応

QMSmart開発チームでは、今後もAIを活用した開発プロセスの改善に継続的に取り組んでいきます。同様の課題を抱えるチームの参考になれば幸いです。

応募待ってます!まずはカジュアル面談から

弊社にご興味ある方いらっしゃいましたら、まずはカジュアル面談から、ぜひご連絡ください。
株式会社Berryではエンジニア募集中です!
医療業界での経験や3Dの知見は問いません。Berryの考え方や製品に少しでも興味が持てた方はお気軽に応募下さい!
https://www.wantedly.com/projects/2241352
https://www.wantedly.com/projects/2241336

株式会社Berry
株式会社Berry

Discussion