90分の会議動画が10分で議事録になる時代へ:ローカルAI議事録パイプライン(M4 Pro最適化)

失敗から設計へ。Google Meetの議事録設定をきっかけに、ローカルAI議事録パイプラインを構築。90分動画を10〜30分で処理する仕組みと、その設計思想を解説します。

90分の会議動画が10分で議事録になる時代へ:ローカルAI議事録パイプライン(M4 Pro最適化)
読了時間: 約5分

背景

Google Meetでオンラインミーティングを実施しました。

録画は残っている。
しかし、会議終了後に議事録を生成しようとしたところ、
議事録機能には事前設定が必要だったことを知ります。

「今さら設定しても遅い。」

そこで考えました。

「MP4さえあれば、ローカルで議事録を自動生成できる仕組みを作れないか?」

こうして、ローカルAI議事録パイプラインの構築が始まりました。

MP4
 ↓
音声抽出(ffmpeg)
 ↓
Whisper(文字起こし)
 ↓
LLM(要約)
 ↓
議事録生成

90分の動画が、mediumモデルで約10〜14分、largeモデルでも約30分弱で処理できました。
環境は MacBook Pro M4 Pro / 48GBメモリ です。


要件定義

今回のシステム要件は以下の通りです。

  • 入力:MP4動画
  • 出力:
    • 文字起こし(全文)
    • 議事録(要約)
  • 日本語対応
  • ローカル完結(機密保持)
  • モデル選択可能(tiny〜large)
  • CLI実行可能
  • 一時ファイル自動削除

技術構成

1. 音声抽出

Whisperは 16kHz / mono / pcm_s16le 形式が推奨です。\
そのため、ffmpegでWAVに変換します。

2. Whisper(Apple Silicon 最適化)

PyTorchの mps を利用してGPU(Metal)を活用します。

device = "mps" if torch.backends.mps.is_available() else "cpu"

Apple Siliconでは fp16=False が推奨です。


実測結果(90分動画)

モデル 処理時間


medium 約10〜14分
large 約30分弱

この速度であれば、会議直後に議事録の叩き台が完成します。


設計思想

今回意識したのは「仕組み化」です。

  • ステップ分離(抽出 / 文字起こし / 要約)
  • モデル切替可能
  • APIキー未設定時の安全設計
  • ローカル完結

AIを使うのではなく、設計する。
それが Miyakawa Codes のスタンスです。


注意点

Whisperは稀に存在しない文言を生成することがあります。
議事録用途では必ず人間による最終確認を推奨します。


技術解説(Qiita版)

実装手順や環境構築の詳細は、Qiitaにまとめています。

👉 https://qiita.com/miyakawa2449@github/items/be7a1e5c2a16ac934f13

GitHub

プロジェクトはこちら
👉 https://github.com/miyakawa2449/meet


このプロジェクトをどう育てていくか

今回のローカルAI議事録パイプラインは、完成形ではありません。

むしろこれは「出発点」です。

単に Whisper を使って議事録を作ることが目的ではなく、AIを“使う”のではなく、“設計する”ことがこのプロジェクトの本質です。

今後は、以下の3つの軸で進化させていきます。


① 話者分離(Diarization)

現在は「文字起こし結果をまとめる」段階ですが、議事録としての価値を高めるには、

  • 誰が発言したのか
  • どの流れで議論が進んだのか

を構造化する必要があります。

話者分離を導入することで、単なるテキストではなく「会議の構造」を扱えるようにする。

これは、議事録をログからナレッジへ昇華させるための一歩です。


② faster-whisper への差し替え(高速化と最適化)

現在は openai-whisper を使用していますが、将来的には faster-whisper への差し替えを検討しています。

重要なのは「どのライブラリを使うか」ではなく、

  • ASR(音声認識)を差し替え可能な構造にすること
  • 計算資源を最大限活かせる設計にすること

です。

エンジンは交換できる。
構造は維持する。

この設計思想が、プロジェクトの持続性を生みます。


③ ローカルLLMによる完全オフライン化

現在は要約にAPIを利用していますが、将来的にはローカルLLMによる完全オフライン化を目指します。

  • 会議データを外部に出さない
  • 手元の計算資源で完結させる
  • AIを“サービス”ではなく“ツール”として扱う

これは単なる技術的挑戦ではなく、主体性の問題です。

AIを借りるのではなく、AIを扱う側に立つ。
それがこのプロジェクトの思想的な軸です。


これはツール開発ではない

この取り組みは、「便利な議事録ツールを作ること」ではありません。

失敗をきっかけに、

  • 問題を運用で解決するのか
  • 仕組みで解決するのか

を問い直した結果です。

議事準備の録画設定を忘れた。

しかしそこで止まらず、仕組みを設計する方向に舵を切った。

このプロジェクトは、その思考の記録でもあります。


今後、このパイプラインは進化していきます。

そしてその過程そのものが、
Miyakawa Codes にとっての実験場であり、設計のログになります。

AIを使う時代から、AIを設計する時代へ。

この記事をシェア

関連記事

AI駆動開発における役割分担と運用実践記録
技術ブログ

AI駆動開発における役割分担と運用実践記録

はじめに 本記事は、私が実際に運用している Rails製ブログ管理画面 において、 AI使用統計機能の追加 Chart.js グラフ不具合の調査・修正 Claude 4.5 モデルへのアッ...