議事録自動処理パイプラインとは、Google Driveにアップロードされた会議録画を自動的に検知し、文字起こし・要約・案件マッチング・Slack通知まで一気通貫で実行するシステムである。2026年現在、Whisper/Amivoice等の音声認識とGPT-4o/Claudeによる要約を組み合わせた実装が主流となっている。本記事では、renue Internal Jobの実装知見をもとに、本番品質の議事録処理パイプラインを構築するための設計パターンを解説する。特に「3段階案件マッチングロジック」など、他の実装にはない独自知見を公開する。
議事録自動処理パイプラインの全体像
本番品質のパイプラインは以下の流れで構成される。
[Google Drive アップロード]
↓
[Cloud Run Job: 変更検知 (5分ごと)]
↓
[動画処理ジョブ]
├─ mp3変換(ffmpeg)
├─ サムネイル生成
├─ GCSアップロード
└─ meeting_log レコード作成
↓
[文字起こしジョブ (Amivoice/Whisper)]
↓
[要約・タスク抽出ジョブ (GPT-4o/Claude)]
↓
[案件マッチングジョブ (3段階ロジック)]
↓
[Slack通知ジョブ]
↓
[遡及処理ジョブ (定期バッチ)]
↓
[古いファイル自動削除 (1年経過後)]
本番品質パイプラインに必要な6つのジョブ
| ジョブ | 役割 | 実行頻度 |
|---|---|---|
| 1. check_video_job | 動画ファイル検知・前処理 | 5〜15分 |
| 2. check_meeting_log_job | 議事録生成(文字起こし→要約) | 5〜15分 |
| 3. retroactive_meeting_log_processor | 過去議事録の遡及処理 | 日次 |
| 4. delete_old_recording_files | 1年以上前のファイル削除 | 日次 |
| 5. check_amivoice_job | 音声認識ジョブの完了確認 | 5分 |
| 6. meeting_room_needs_job | 会議室ニーズ通知 | 週次 |
ジョブ1: 動画処理ジョブの実装
Google Driveを監視し、新規アップロードされた動画ファイルをダウンロード・前処理する。
対応フォーマット
- 動画: mp4 / mov / avi / mkv
- 音声: mp3 / wav / m4a
Google Driveフォルダ構成
処理状態を管理するためのフォルダ構成を決めておく。
- ROOT_FOLDER: アップロード先
- PROCESSING_FOLDER: 処理中のファイル
- PROCESSED_FOLDER: 処理完了したファイル
- ERROR_FOLDER: エラーが発生したファイル
各フォルダ間はGoogle Drive APIの`files.update(parents=...)`で移動させる。これにより「どのファイルが今どの状態か」が一目で分かる。
Service Accountによる削除の罠
Google Drive APIはService Accountでは`delete`できない。代わりに`update(body={"trashed": True})`でゴミ箱に移動させる必要がある。共有ドライブ対応のため`supportsAllDrives=True`を必ず指定する。
前処理の流れ
- Google Driveから`/tmp`にダウンロード
- `ffmpeg`で音声抽出(動画の場合)
- `ffmpeg`でmp3変換(Amivoice入力用)
- `moviepy`でサムネイル生成
- GCSにアップロード(署名付きURLで後からアクセス)
- `meeting_log`テーブルにレコード作成
- Google Driveのファイルを`PROCESSED_FOLDER`に移動
ジョブ2: 文字起こしジョブ(Amivoice/Whisper)
mp3ファイルを音声認識エンジンに送信し、文字起こしテキストを取得する。
Amivoice採用の理由
- 日本語特化の高精度エンジン
- 長時間音声(1時間以上)にも対応
- 話者分離機能
- 業務用途の利用規約が明確
長時間音声の分割処理パターン
1時間以上の会議を一気に処理するとタイムアウトする。renueの実装では「1時間ずつ区切り、10分単位で分割して同時並行処理」のパターンを採用している。
- 音声ファイルを10分単位のチャンクに分割
- 最大6チャンク(1時間分)を同時並行で文字起こし
- 全チャンク完了後、タイムスタンプ順に結合
- 次の1時間分のチャンクを処理
これにより、3時間の会議も30分程度で処理完了できる。
非同期ジョブの完了確認
Amivoice等の音声認識は非同期ジョブであるため、`check_amivoice_job`で完了状態を5分ごとにポーリングする。完了したら次のステップ(要約)に進む。
ジョブ3: 要約・タスク抽出(LLM)
文字起こしテキストをLLM(GPT-4o/Claude)に渡し、以下を自動生成する。
- 会議の要約 (3〜5行)
- 決定事項
- 次のアクション(ToDo)
- 参加者のコメント要点
- 議論の論点
プロンプトの設計ポイント
- 出力形式をMarkdownで固定
- 「決定事項」「ToDo」「次回議論」のセクションを必須とする
- ToDoには担当者と期日を明示させる
- 文字起こしエラー(「えーっと」「まあ」等)を除外させる
ジョブ4: 3段階案件マッチングロジック (renue独自)
議事録を作成した後、「どのプロジェクトの会議か」を自動判定してSlackに投稿する。これがrenueの実装で最も独自性が高い部分である。
従来の問題
- ユーザーが毎回手動で案件を選ぶのは面倒
- 全案件から選ぶと件数が多すぎて選択ミスが発生
- アップロード者の配属情報が欠けていると候補がゼロになる
- メールアドレスと実際のユーザー名の紐付けが不完全
3段階マッチングロジック
段階1: upload_by (アップロード者) 由来の配属案件
議事録をアップロードしたユーザーの配属案件を最優先で表示する。アクティブな案件(IN_PROGRESS、PLANNED)のみを対象とし、最大100件まで表示(Slackの制限)。
段階2: ファイル名から推定した従業員の配属案件
ファイル名の先頭フォルダ名から従業員を推定する。例えば`horii.takayuki/議事録.txt`というファイル名なら`horii takayuki`を抽出する。メールアドレスのローカル部分と照合し、正規化処理により`horii.takayuki@example.jp`と一致させる。段階1で見つからなかった配属案件を候補に追加する。
段階3: 全アクティブ案件(フォールバック)
段階1・2で候補が見つからない場合のみ実行する。全アクティブ案件から最大20件を表示し、既に候補に含まれている案件は除外する。
この3段階ロジックの解決する問題
- 配属情報がnullの従業員: upload_byで候補が取得できない場合でもファイル名から推定して適切な案件候補を提供
- メールアドレスとユーザーの紐付け不備: 正規化処理によりメールアドレスのローカル部分とファイル名を柔軟に照合
- 候補が全く表示されない問題: 最終的に全アクティブ案件をフォールバックとして提供
各段階で重複除去を行い、既に追加された案件は再度表示されないようにする。この設計により、ユーザーのワンクリックで議事録が正しいプロジェクトに紐付くようになる。
ジョブ5: 遡及処理ジョブ
過去の議事録を遡及的に処理するジョブ。以下の用途で使う。
- プロンプト改良後に過去の議事録を再生成
- 新しい分析項目(ToDo等)を過去分に適用
- エラーで処理されなかった議事録のリトライ
遡及処理の設計ポイント
- 日付範囲指定: `--start-date`/`--end-date`で対象を絞る
- 冪等性: 何度実行しても同じ結果になる
- 差分更新: 変更があったフィールドだけ更新
- レート制限: LLM API利用料を制限するためのスロットリング
ジョブ6: 1年経過ファイルの自動削除
録画ファイルはストレージコストが大きいため、古いファイルは定期的に削除する。
削除対象
- GCS上の動画ファイル(1年以上前)
- Google Drive上の動画ファイル(同上)
- 文字起こしテキストと要約は残す(参照用)
削除の注意点
- 監査ログの保持要件を確認(金融・医療等は長期保存必須)
- 削除前にSlackで通知(誤削除防止)
- Dry-runオプションで事前確認できるようにする
セキュリティ対策 — デバッグログの機密情報
議事録処理ジョブでは、デバッグログに機密情報(従業員ID、ファイル名、メールアドレス)が含まれる可能性がある。
環境変数による制御
# 本番環境での推奨設定
DEBUG_LOG_ENABLED=false
# 開発環境(デフォルト)
DEBUG_LOG_ENABLED=true
本番環境では`DEBUG_LOG_ENABLED=false`を必ず設定し、機密情報がログに出力されないようにする。
インフラ構成 (GCP)
renueの実装はGCPで構築されている。
使用サービス
- Cloud Run Jobs: バッチ処理実行環境
- Cloud SQL (MySQL): meeting_log等のデータ保存
- Cloud Storage (GCS): 動画ファイル保存
- Artifact Registry: Dockerイメージ保管
- Cloud Build: CI/CD
- Cloud Scheduler: 定期実行(5〜15分間隔)
手動デプロイ手順
# 1. Artifact Registry認証
gcloud auth configure-docker us-central1-docker.pkg.dev
# 2. Dockerイメージビルド
docker build -t us-central1-docker.pkg.dev/PROJECT_ID/renue-hub/renue-job:latest .
# 3. プッシュ
docker push us-central1-docker.pkg.dev/PROJECT_ID/renue-hub/renue-job:latest
# 4. Cloud Run Jobを更新
gcloud run jobs update JOB_NAME --image us-central1-docker.pkg.dev/PROJECT_ID/renue-hub/renue-job:latest --region us-central1
# 5. ジョブ実行
gcloud run jobs execute JOB_NAME --region us-central1
GCP Cloud SQLマイグレーションの注意点
Cloud SQLのマイグレーションは通常CI/CDに含まれない。デプロイ後に手動でAlembicを実行する必要がある。
# Cloud Shellから実行
alembic upgrade head
この手順を忘れると、新しいカラムを参照するコードがエラーになる。
renue Internal Jobの技術スタック
renueは「Self-DX First」の方針のもと、議事録処理パイプラインを自社プロダクトとして開発・運用している(全て公開情報)。
公開されている技術スタック
- 言語: Python 3.11.3
- DB: Cloud SQL (MySQL)
- ORM: SQLAlchemy + Alembic
- LLM: OpenAI / Anthropic / Google Generative AI / LangChain
- 音声認識: Amivoice
- インフラ: GCP (Cloud Run / Cloud Build / GCS / Cloud SQL)
- 外部連携: Slack / Google Workspace (Drive/Meet/Docs)
導入時のよくある失敗パターン
- 変更検知と重い処理を1ジョブにする: スケーラビリティが出ず、タイムアウト発生
- 長時間音声を一気に処理: タイムアウトで失敗する
- Service Accountでdeleteを試みる: 権限エラー、trashedへの移動が正解
- 案件マッチングを単一ロジックで実装: エッジケースで候補ゼロになる
- デバッグログを本番で有効化: 機密情報が漏洩する
- 遡及処理の冪等性を考慮しない: 二重登録やデータ破損が発生
- 古いファイルを削除しない: GCSコストが爆発する
- Cloud SQLマイグレーションを忘れる: デプロイ後にエラー
業界別の活用パターン
| 業界 | 主な活用 |
|---|---|
| コンサルティング | クライアント会議の議事録自動化、プロジェクト別集約 |
| SaaS/IT | 内部会議の自動記録、意思決定ログ |
| 法務 | 打ち合わせ記録、法的証拠としての保持 |
| 医療 | 症例検討会議の記録(プライバシー注意) |
| 教育 | 講義録画の文字起こし、検索可能ナレッジ |
| 公共 | 議会・審議会の議事録作成 |
よくある質問
議事録の精度はどれくらい?
Amivoice等の日本語特化エンジンなら文字起こし精度は90%以上、LLMによる要約の質も実用レベルに達している。ただし専門用語が多い会議では、用語辞書を準備するなどの工夫が必要。
コストはどれくらい?
1時間の会議あたり、文字起こしで数百円、LLM要約で数十円〜数百円が目安。月間100時間の会議を処理すると月額数万円〜十数万円の運用コストになる。人件費削減効果(月20時間以上)を考えるとROIは高い。
個人情報の取り扱いは?
議事録には氏名・所属・発言内容などが含まれるため、以下の対策が必要。①保存場所を社内限定、②アクセス制御、③保存期間の明確化(例: 1年後に自動削除)、④プライバシーポリシーでの開示、⑤参加者への事前通知。
案件マッチングの精度を上げるには?
3段階ロジックに加えて、議事録本文からLLMでプロジェクト名を抽出する第4段階を追加すると精度がさらに向上する。ただしLLM呼び出しコストが増えるため、段階1・2で十分なケースでは呼び出さない設計にする。
Cloud Run以外の選択肢は?
AWS Lambda、Azure Container Apps、Kubernetesなどでも同様の構成は可能。renueがCloud Runを選んだ理由は、バッチジョブに特化したCloud Run Jobsという機能があり、スケールとコストのバランスが良いためである。