記録を標準化する — 会議の記録を再利用・相互運用可能にする

会議の記録は、たいてい人ごと・回ごとにばらばらの形で残ります。録音は録音アプリ、メモはノート、配布資料はメールの添付、撮影したスライドはスマホのカメラロール。残るのは断片で、後から横断して参照することは、ほぼできません。

これは手間の問題ではありません。記録の構造の問題 です。一回ごとの記録にかける時間を増やしても、形式がばらばらなら、記録どうしはつながりません。検索できず、共有のたびに整え直しが要り、長期の参照は名ばかりになります。

本稿では、この状態から抜け出すための一つの方針、記録を標準化する ことを取り上げます。その意義と組み立て、そして実装としてのオープンソースのツール群 (media-scribe-workflow を中心とする 4 つの単機能ツール) を順に見ていきます。

標準化が解く問題

工学での標準化は、いつも 再利用性と相互運用性 という二つの目的を担ってきました。USB は一つの形でホストとデバイスをつなぎます。HTTP は一つの語彙で世界中のサーバを呼び出します。JSON は一つの記法で、言語をまたいだデータ交換を成り立たせます。どれも同じ命題の例です。共通インターフェースを定めれば、独立に作られた部品が組み合わせ可能になる。

会議記録では、いまの断片化が次のような結果を生んでいます。

  • 横断検索が利かない: 記録がそれぞれ別のファイル形式に閉じているため、複数の会議をまたいだ検索は事実上できない
  • 共有のたびに再フォーマット: 渡す相手の形式に合わせる作業が、記録のたびに発生する
  • 長期参照の崩壊: 数年たつと、当時の形式を開ける環境さえなくなる
  • メタデータの欠落: 「いつ・どこで・誰が・何について」という揃ったメタデータが付いていないため、自動で分類できない

標準化されていない記録は、書いた本人が使い直すときにも摩擦を生みます。三年前のあの会議の議論はどこにあったか。それを探す時間が、記録した時点での節約を帳消しにしてしまいます。

これを裏返すと、標準化された記録 に求められる性質は次の四つになります。

  1. 共通インターフェース: 入力・処理・出力の各段が、標準形式でつながる
  2. メタデータの整合: いつ・誰が・どの会議か、を記録自身が持っている
  3. 長期可読性: 数年後も開けて、検索でき、作り直せる形式
  4. 再利用可能アセット: 記録の一部 (発話、スライド、図) を、別の文書に組み込める

標準化の構成 — インターフェースが標準

記録の標準化を成り立たせるのは、ステージとステージのあいだに敷かれるデータ形式 です。各ツールは、入力と出力の標準形式を守ります。その形式に従う限り、部品は入れ替えられます。これが、標準化されたパイプラインのいちばん大事な性質です。

会議記録のパイプラインは、次の 4 段階に分けられます。

段階 入力 出力 標準形式
1. 録音 → 文字起こし 音声ファイル (mp4 / wav) 字幕 SRT (時刻つき字幕の業界標準)
2. スライド撮影 → 整形 プレゼン写真 (HEIC / JPEG) 補正済み画像 PNG / PDF (1920×1080 / 300 dpi A4)
3. SRT + 写真 → 構造化 SRT + 画像 + メタデータ LaTeX ソース LuaLaTeX (組版工学の標準)
4. LaTeX → 配布物 LaTeX ソース PDF + チャプター付き動画 PDF/A + YouTube チャプター記法

各段階のあいだに置いているのは、どれも 長く使われてきた業界標準 です。SRT は 2000 年ごろから、動画字幕の標準形式として定着しています5。LuaLaTeX は、欧米でも日本でも学術出版で広く使われている組版エンジンです。PDF/A は ISO 19005 として規格化された、長期保存向けの PDF のサブセットです6。YouTube のチャプター記法も、事実上の標準として広く受け入れられています。

つまり設計の原則は、個別ツールが標準を発明するのではなく、既存の標準を尊重して繋ぐこと です。本サイトの基礎記事 決定論的にではなく、相対的に の言葉で言えば、段階のあいだに標準形式を敷くことは、検証 (Verification) ── 隣接する二つの段階のあいだの差異を機械的に検出すること ── を成立させる条件 です1。形式が揃っていれば、「文字起こしの出力と整形の入力は一致しているか」「整形の出力と構造化の入力は一致しているか」を自動で確かめられます。標準化には二つの効き目があります。各段を相対的に差し替えられるようにすること。そして、隣り合う段の整合を機械で確かめられるようにすることです。

出力形式は用途に応じて選ぶ

前節の表では、第 4 段の出力を LuaTeX による PDF を中心に書きました。ただ、これは 選択肢の一つ にすぎません。標準化の本質は、段階のあいだのインターフェースを揃えることです。最終出力の形式を一つに決めることではありません。入力 (SRT + 整形済み画像 + 章立てメタデータ) が標準形式で揃っていれば、後段のテンプレートを差し替えるだけで、別の形式に出力できます。これも、標準化されたパイプラインの利点です。

用途に応じて選べる出力形式を 3 つ挙げます。

出力形式 適する用途 強み
LuaTeX → PDF/A 学術出版、印刷配布、長期保存 数式組版、タイポグラフィ品質、ISO 規格準拠
Markdown Web 公開、GitHub リポジトリ、軽量共有、AI への入力 可搬性、編集容易性、テキスト検索
JSON API 連携、機械処理、データベース投入、検索インデックス 構造の明示、機械可読性、後段自動化

たとえば次の三方向への同時配信を、同じ標準化された入力から組み立てられます。

  • 学会発表録の公式報告書 → LuaTeX PDF
  • 社内 Wiki / GitHub Pages 共有版 → Markdown
  • 検索可能なナレッジベースへの投入 → JSON

media-scribe-workflow では、いまのところ msw-report が LaTeX テンプレートを使っています。けれども上のように入力側が標準形式で揃っているので、Markdown / JSON 用テンプレートを追加すれば同じパイプラインで別形式の出力に拡張可能 です。最終出力の形式は、読み手 (学術査読者・社内スタッフ・機械処理パイプライン) や保存の要件に合わせて選ぶ。実際の運用はそうなります。

ツールキットの編成

media-scribe-workflow2 を中心に、目的の違う 4 つの単機能ツールでこのパイプラインを実装しています。これが現在の構成です。

1. media-scribe-workflow ── パイプラインの中心です。Whisper で文字起こしした SRT を受け取り、Claude による文脈の解析と、LuaTeX 形式の構造化レポートの生成を行います。サブコマンド (msw-config / msw-report / msw-compile / msw-pipeline) は、各段階を一つずつ呼ぶことも、まとめて実行することもできるように作っています。

2. perspective-corrector3 ── スライド写真の台形の歪みを直す単機能ツールです。会場の後ろからスマートフォンで撮ったスライドは、台形に歪みます。4 隅の自動検出 (Canny エッジ + 輪郭近似) と手での微調整を組み合わせて、1920×1080 の PNG か、300 dpi A4 の PDF に整えます。HEIC (iPhone 標準) にも対応しているので、撮ったファイルをそのまま流し込めます。

3. video-chapter-editor ── 動画のチャプターを編集する GUI です (media-scribe-workflow に同梱)。波形表示と動画プレビューを並べ、クリックでチャプター位置を打ち、ドラッグで微調整します。ffmpeg で書き出すときに、GPU のハードウェアエンコード (VideoToolbox / NVENC / QSV / AMF) を選べます。そのため、長い会議の録音もローカルで現実的な時間で処理できます。

4. luatex-docker-remote4 ── LuaLaTeX の実行環境を、リモートの Docker コンテナに切り離します。msw-compile の裏で動くコンパイラ環境を、ローカルマシンを汚さずに整えるための補助装置です。詳しくは本サイトの既掲記事 LuaTeX を Docker でリモート実行する で解説しています。

陶器と配管 ── Git に倣った設計分離

media-scribe-workflow の README は、設計の考え方として、Git の用語 「陶器と配管」 を引き継いでいます7。

Git のコマンドは、昔から二つの層に分けて理解されてきました。

  • 陶器 (porcelain): 利用者がじかに触る高水準コマンド (git commit / git push など)
  • 配管 (plumbing): 陶器が裏で呼び出す低水準コマンド (git update-ref / git hash-object など)

陶器は人間向けに磨かれた表面で、配管は機械どうしの接続部です。この分離によって Git は、人間にとっての使いやすさと、スクリプトから組み合わせられる部品としての性質を、両立させています。

media-scribe-workflow も同じ分け方をとっています。

  • 陶器: video-chapter-editor (PySide6 ベースの GUI)、rehearsal-download / rehearsal-finalize などの統合コマンド
  • 配管: msw-config / msw-report / msw-compile、vce-encode / vce-split、yt-srt / video-trim / video-chapters といった単機能 CLI

陶器を通る道も、配管を通る道も、同じ標準形式を経由します。だから利用者は、GUI だけで済ませることも、Make ファイルで自動化することもできます。

ワークフローの実例

実際の使い方は、典型的には次のような流れです。

  1. 会議に出席 ── 録音、スライド写真の撮影 (会場の後ろからでよい)、必要なら動画撮影
  2. ローカルに取り込み ── 音声 + 写真 + (必要なら) 動画ファイル
  3. perspective-corrector でスライド整形 ── HEIC ファイルをそのまま流し込み、4 隅の自動検出 + ドラッグで微調整、PDF に一括出力
  4. Whisper で文字起こし ── ローカル GPU か、リモートの Whisper サーバへ送り、SRT を受け取る
  5. msw-pipeline で構造化 ── SRT + 整形済みスライド + メタデータ → Claude が話者・話題・構造を整理 → LaTeX 生成 → LuaTeX で PDF 化
  6. (必要なら) video-chapter-editor で動画にチャプターを打つ ── YouTube または独自プレーヤ向けに、チャプター付き動画を出力

成果物は PDF + チャプター付き動画 + チャプターリスト (YouTube 互換) で、どれも標準形式です。後になって、ある会議の特定の箇所を引用したくなったとします。PDF をテキスト検索し、対応する動画のチャプターを直接再生する。そうした再利用が、摩擦なくできます。


ここからは、この標準化の試みを、2026 年の知的生産論の中に置き直してみます。

梅棹忠夫が『知的生産の技術』(1969) で論じたのは、思考と処理の 分離・統合の技術 こそが知的生産の中心だ、ということでした8。京大式カードは、物としての記録装置です。書き手の考えを途切れさせずに、処理 (整理・分類・並べ替え) を後の段に切り出すための標準形式でした。これは本サイトの基礎記事 決定論的にではなく、相対的に でいう 媒介性 ── 道具やメディアが、何を見せ、何をしやすくするかを決めること ── の具体例です。Clark & Chalmers (1998) が「拡張された心」として認知科学の側から定式化したのも、同じ事態です91。

会議記録の標準化は、この流れを現代に延ばしたものだと私は考えています。

  • 梅棹のカード = 思考と処理を時間で分ける標準形式 (1969 年の物理メディア)
  • 会議記録の標準化 = 録音・撮影・整理・参照を、形式・段階・人 をまたいで分ける標準形式 (2026 年のデジタルメディア)

二つは、時代もメディアも違います。それでも 「記録は思考の媒介物であり、その媒介を整える行為そのものが知的生産の技術である」 という主張では、根が同じです。本サイトの既掲記事 書くことは考えることか — 思考と道具の境界 と LuaTeX を Docker でリモート実行する、そして本稿は、どれもこの命題に別の断面から近づく試みです。

会議は、ふつう出版されません。けれども会議の記録が 再利用可能・相互運用可能な形 で標準化されていれば、それは長く生きる資産になります。個人の蔵書として。組織のナレッジベースとして。そして、将来の自分への手紙として。数年後の自分が「あの会議で本当は何を聞きたかったのか」をさかのぼり、言葉にし直すための余地です。標準化は、そのための前提です。そしてそれは、技術ではなく 態度 の問題です。決定論的にではなく、相対的に で宣言した、形式の境界を固定し、道具のほうを相対的に置く態度です。

参考文献


  1. 媒介性 / 差延 / 検証と妥当性確認 (V&V) の非対称性 の操作的な定義と理論的な扱いについては、本サイトの基礎記事 決定論的にではなく、相対的に の脚注、および著者の Zenodo プレプリント・シリーズ (レター版 DOI: 10.5281/zenodo.20096462) を参照。 ↩↩

  2. mashi727/media-scribe-workflow, GitHub リポジトリ. https://github.com/mashi727/media-scribe-workflow ── 本稿で扱うパイプラインの中核ツール。Whisper × Claude × LuaTeX を統合する構成と、msw-* / vce-* のサブコマンド体系の詳細はリポジトリ README を参照。 ↩

  3. mashi727/perspective-corrector, GitHub リポジトリ. https://github.com/mashi727/perspective-corrector ── プレゼンテーション写真の台形歪みを補正する PySide6 + OpenCV ベースのデスクトップアプリ。 ↩

  4. mashi727/luatex-docker-remote, GitHub リポジトリ. https://github.com/mashi727/luatex-docker-remote ── LuaLaTeX のリモート Docker 実行環境。 ↩

  5. SubRip Subtitle (.srt) 形式は DVD の字幕を抜き出すツール SubRip (初版 2000 年 3 月) を起源として広く流通した時刻つき字幕形式で、ハッシュ番号 + タイムコード (HH:MM:SS,mmm) + 字幕テキストの三項組から成る。Whisper をはじめとする現代の音声認識ツールはこのフォーマットを標準出力の一つとして採用している。 ↩

  6. ISO 19005-1:2005 Document management — Electronic document file format for long-term preservation — Part 1: Use of PDF 1.4 (PDF/A-1). 国際標準化機構, 2005. 長期保存用 PDF サブセットの規格。 ↩

  7. Chacon, Scott, and Ben Straub. Pro Git, 2nd ed., Apress, 2014, Chapter 10 “Git Internals”. 高水準コマンドを「porcelain」、低水準コマンドを「plumbing」と呼び分ける慣習の出典。https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain ↩

  8. 梅棹忠夫『知的生産の技術』岩波新書、1969 年。 ↩

  9. Clark, A. and D. Chalmers. “The Extended Mind.” Analysis, vol. 58, no. 1, 1998, pp. 7–19, p. 7 ── “Where does the mind stop and the rest of the world begin?” ↩