株式会社renue
AI導入・DXの悩みをプロに相談してみませんか？
AIやDXに関する悩みがありましたら、お気軽にrenueの無料相談をご利用ください。 renueのAI支援実績、コンサルティングの方針や進め方をご紹介します。
議事録自動処理パイプラインとは、Google Driveにアップロードされた会議録画を自動的に検知し、文字起こし・要約・案件マッチング・Slack通知まで一気通貫で実行するシステムである。2026年現在、Whisper/Amivoice等の音声認識とGPT-4o/Claudeによる要約を組み合わせた実装が主流となっている。本記事では、一般的な実装知見をもとに、本番品質の議事録処理パイプラインを構築するための設計パターンを解説する。特に「3段階案件マッチングロジック」など、他の実装にはない独自知見を公開する。
議事録自動処理パイプラインの全体像
本番品質のパイプラインは以下の流れで構成される。
[Google Drive アップロード]
↓
[Cloud Run Job: 変更検知 (5分ごと)]
↓
[動画処理ジョブ]
├─ mp3変換(ffmpeg)
├─ サムネイル生成
├─ GCSアップロード
└─ 議事録レコード作成
↓
[文字起こしジョブ (Amivoice/Whisper)]
↓
[要約・タスク抽出ジョブ (GPT-4o/Claude)]
↓
[案件マッチングジョブ (3段階ロジック)]
↓
[Slack通知ジョブ]
↓
[遡及処理ジョブ (定期バッチ)]
↓
[古いファイル自動削除 (1年経過後)]
本番品質パイプラインに必要な6つのジョブ
| ジョブ | 役割 | 実行頻度 |
|---|---|---|
| 1. 動画検知ジョブ | 動画ファイル検知・前処理 | 5〜15分 |
| 2. 議事録生成ジョブ | 議事録生成(文字起こし→要約) | 5〜15分 |
| 3. 遡及処理ジョブ | 過去議事録の遡及処理 | 日次 |
| 4. ファイル削除ジョブ | 1年以上前のファイル削除 | 日次 |
| 5. 音声認識完了確認ジョブ | 音声認識ジョブの完了確認 | 5分 |
| 6. 会議室ニーズ通知ジョブ | 会議室ニーズ通知 | 週次 |
ジョブ1: 動画処理ジョブの実装
Google Driveを監視し、新規アップロードされた動画ファイルをダウンロード・前処理する。
対応フォーマット
- 動画: mp4 / mov / avi / mkv
- 音声: mp3 / wav / m4a
Google Driveフォルダ構成
処理状態を管理するためのフォルダ構成を決めておく。
- ROOT_FOLDER: アップロード先
- PROCESSING_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で後からアクセス)
- 議事録テーブルにレコード作成
- Google Driveのファイルを`処理済みフォルダ設定`に移動
ジョブ2: 文字起こしジョブ(Amivoice/Whisper)
mp3ファイルを音声認識エンジンに送信し、文字起こしテキストを取得する。
Amivoice採用の理由
- 日本語特化の高精度エンジン
- 長時間音声(1時間以上)にも対応
- 話者分離機能
- 業務用途の利用規約が明確
長時間音声の分割処理パターン
1時間以上の会議を一気に処理するとタイムアウトする。一定時間ごとに区切り、短いチャンクに分割して並行処理するパターンが有効である。
- 音声ファイルを10分単位のチャンクに分割
- 最大6チャンク(1時間分)を同時並行で文字起こし
- 全チャンク完了後、タイムスタンプ順に結合
- 次の1時間分のチャンクを処理
これにより、3時間の会議も30分程度で処理完了できる。
非同期ジョブの完了確認
Amivoice等の音声認識は非同期ジョブであるため、音声認識完了確認ジョブで完了状態を5分ごとにポーリングする。完了したら次のステップ(要約)に進む。
ジョブ3: 要約・タスク抽出(LLM)
文字起こしテキストをLLM(GPT-4o/Claude)に渡し、以下を自動生成する。
- 会議の要約 (3〜5行)
- 決定事項
- 次のアクション(ToDo)
- 参加者のコメント要点
- 議論の論点
プロンプトの設計ポイント
- 出力形式をMarkdownで固定
- 「決定事項」「ToDo」「次回議論」のセクションを必須とする
- ToDoには担当者と期日を明示させる
- 文字起こしエラー(「えーっと」「まあ」等)を除外させる
ジョブ4: 3段階案件マッチングロジック (renue独自)
議事録を作成した後、「どのプロジェクトの会議か」を自動判定してSlackに投稿する。この部分が設計上の工夫のしどころとなる。
従来の問題
- ユーザーが毎回手動で案件を選ぶのは面倒
- 全案件から選ぶと件数が多すぎて選択ミスが発生
- アップロード者の配属情報が欠けていると候補がゼロになる
- メールアドレスと実際のユーザー名の紐付けが不完全
3段階マッチングロジック
段階1: アップロード者 由来の配属案件
議事録をアップロードしたユーザーの配属案件を最優先で表示する。アクティブな案件(進行中・計画中)のみを対象とし、最大100件まで表示(Slackの制限)。
段階2: ファイル名から推定した従業員の配属案件
ファイル名に含まれる情報から利用者を推定し、社内の利用者情報と突き合わせる。段階1で見つからなかった配属案件を候補に追加する。
段階3: 全アクティブ案件(フォールバック)
段階1・2で候補が見つからない場合のみ実行する。全アクティブ案件から最大20件を表示し、既に候補に含まれている案件は除外する。
この3段階ロジックの解決する問題
- 配属情報がnullの従業員: アップロード者情報で候補が取得できない場合でもファイル名から推定して適切な案件候補を提供
- メールアドレスとユーザーの紐付け不備: 正規化処理によりメールアドレスのローカル部分とファイル名を柔軟に照合
- 候補が全く表示されない問題: 最終的に全アクティブ案件をフォールバックとして提供
各段階で重複除去を行い、既に追加された案件は再度表示されないようにする。この設計により、ユーザーのワンクリックで議事録が正しいプロジェクトに紐付くようになる。
ジョブ5: 遡及処理ジョブ
過去の議事録を遡及的に処理するジョブ。以下の用途で使う。
- プロンプト改良後に過去の議事録を再生成
- 新しい分析項目(ToDo等)を過去分に適用
- エラーで処理されなかった議事録のリトライ
遡及処理の設計ポイント
- 日付範囲指定: `--start-date`/`--end-date`で対象を絞る
- 冪等性: 何度実行しても同じ結果になる
- 差分更新: 変更があったフィールドだけ更新
- レート制限: LLM API利用料を制限するためのスロットリング
ジョブ6: 1年経過ファイルの自動削除
録画ファイルはストレージコストが大きいため、古いファイルは定期的に削除する。
削除対象
- GCS上の動画ファイル(1年以上前)
- Google Drive上の動画ファイル(同上)
- 文字起こしテキストと要約は残す(参照用)
削除の注意点
- 監査ログの保持要件を確認(金融・医療等は長期保存必須)
- 削除前にSlackで通知(誤削除防止)
- Dry-runオプションで事前確認できるようにする
セキュリティ対策 — デバッグログの機密情報
議事録処理ジョブでは、ログに個人情報が含まれる場合がある。
環境変数による制御
# 本番環境での推奨設定
デバッグログ出力 = false
本番環境ではデバッグログ出力を無効にする設定を必ず行い、機密情報がログに出力されないようにする。
インフラ構成 (GCP)
ここではGCPを前提とした構成例を示す。
使用サービス
- Cloud Run Jobs: バッチ処理実行環境
- Cloud SQL (MySQL): 議事録データの保存
- Cloud Storage (GCS): 動画ファイル保存
- Artifact Registry: Dockerイメージ保管
- Cloud Build: CI/CD
- Cloud Scheduler: 定期実行(5〜15分間隔)
デプロイの流れ
コンテナレジストリへの認証、イメージのビルドとプッシュ、ジョブ定義の更新、ジョブ実行の4段階で運用する。
GCP Cloud SQLマイグレーションの注意点
Cloud SQLのマイグレーションは通常CI/CDに含まれない。デプロイ後に手動でAlembicを実行する必要がある。
マイグレーションコマンドをクラウド側のシェルから手動実行する。
この手順を忘れると、新しいカラムを参照するコードがエラーになる。
renue 議事録パイプラインの技術スタック
議事録処理パイプラインを内製する場合の一般的な構成要素を示す。
公開されている技術スタック
- 言語: 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 | 内部会議の自動記録、意思決定ログ |
| 法務 | 打ち合わせ記録、法的証拠としての保持 |
| 医療 | 症例検討会議の記録(プライバシー注意) |
| 教育 | 講義録画の文字起こし、検索可能ナレッジ |
| 公共 | 議会・審議会の議事録作成 |
