会議の録画と文字起こしを一箇所に集める。会議データの基盤づくり

会議の録画と文字起こしは、Meetのようなオンライン会議の機能によって、既に社内に大量に自動で作られています。

ところが、それが会議を主催した人の個人領域に保存されたままになっています。
だから他の人からは見えませんし、主催者が退職すればアクセスできなくなります。
社内に存在するのに使えない状態だと思います。

今回は、会議データの集約について整理していきます。
会議と議事録の全体像は会議と議事録のAI化。準備から共有・タスク化までの設計にまとめてあります。

会議データが個人の領域に散っている

会議データは、なぜ個人の領域に散ってしまうのでしょうか？
理由は単純です。
録画の保存先が、主催者の個人領域を既定にしている構成が一般的で、そこから誰も設定を変えません。
保存されていることは分かっても、どこに保存されているかを意識していないのが普通の状態だと思います。

結果として、部署ごとに主催者ごとに会議データが分散していきます。
一覧もなければ、検索もできない状態です。
そのうち本人も、1か月前の会議の録画がどこにあるか分からなくなります。

集約されていないと何が困るかも書いておきます。
参加していなかった人が確認できず、「あの会議で何が決まったか」を知りたいときに主催者に聞くしかありません。
過去の経緯も追えず、「この件について過去にどう議論されたか」を調べられないので同じ議論を繰り返します。

主催者の異動で失われることもあり、アカウントが停止されるとアクセスできなくなります。
もうひとつ、要約や分析につなげられません。
個人領域に散っていると、まとめて処理できないからです。

さらに、保存期間の管理もできません。
いつまで残すかを組織として決められないので、無期限に溜まり続けます。

なかでも大きいのは、要約や分析につなげられないことです。
つまり、会議データを参照させて経緯を追えるようにするには、集約されている必要があります。

保存先を1つに決めて、自動コピーで集める

では、何から手を付ければよいのでしょうか？
導入はここでも段階を踏みます。

最初は保存先の決定で、会議データを保存する場所を1つ決めるところから始めます。
構造も決めておきます。
「会議記録／年／部門」程度の3階層で足りますし、階層を深くしないのが大事なところです。

命名の規則は「日付_会議名」にして、日付を先頭にすると時系列で並びます。
「集める対象」も決めておき、全部の会議を集める必要はありません。
目安は、部門をまたぐ会議、決定を伴う会議、顧客との会議です。
個人の1on1や短時間の共有は、対象外にして構いません。

この段階で「どこに保存するか」を全社に周知して、設定を変えてもらうか手動でコピーしてもらいます。
もちろん手動でも構いませんが、まず場所が決まることのほうが重要です。

ただ、手動だと抜けるので、次に自動化します。
個人領域に保存された会議データを、定期的に共有の場所へコピーする仕組みです。

設計のポイントは3つあり、まず元のファイルを残すことです。
移動ではなくコピーにするのは、移動すると主催者が「自分の録画がなくなった」と混乱するからです。

次に対象を絞ることで、例えば会議名に特定の文字が入っている、参加者が3人以上、といった条件で絞り込みます。
全部をコピーすると容量が問題になるからです。
もうひとつが重複を防ぐことで、既にコピーしたものを再度コピーしないよう、処理済みの記録を別に残しておきます。

あわせて通知も出します。
コピーされたことを主催者に伝えると、「勝手にコピーされた」という受け取り方を防げます。

一覧も作っておきます。
日付・会議名・参加者・保存場所へのリンクを並べたもので、この一覧が後の検索の入口になります。
個人領域からの移行そのものは個人フォルダの業務データを共有領域へ。AI活用の前提整備にまとめてあります。

検索・要約・分析につなぐ

集約が回り始めたら、どう使えばよいのでしょうか？
いよいよ使う段階に入ります。
まず経緯を追うことで、「この件について過去にどう議論されたか」を聞けるようになります。
議事録を横断して参照させる形です。

次に決定事項の一覧化で、複数の会議から決定事項を抽出して並べると「今期に決まったこと」の一覧が作れます。
もうひとつが会議の分析で、決定事項の数、繰り返し出ている議題、参加者の発言の偏りといったところを見ます。
会議の棚卸しの材料になります。

さらに引き継ぎにも使え、異動時に担当していた案件の会議記録を渡せるようになります。
このなかで最も日常的に使われるのは、経緯を追う用途です。
決定事項の一覧化と会議の分析は、四半期の振り返りのところで使われます。

「使える状態」にするには、参照させる範囲の設計が必要です。
全部を一度に参照させると精度が落ちるので、部門や期間で分けておきます。
議事録そのものの型は議事録作成を仕組みに寄せる。1万字の文字起こしを要約で回すにまとめてあります。

保存期間と権限は、会議の種類で線を引く

集約したあとは、何を決めておけばよいのでしょうか？
今度は管理の設計です。

まず保存期間を種類ごとに決めておきます。
決定を伴う会議は3年程度で、経緯を追う必要があるので長く残します。
定例の進捗会議は1年程度で、過去のものは参照されません。
顧客との会議は契約期間に一定期間を足した長さで、契約の内容によって変わります。

「期間を超えたものを削除する」運用も決めておきます。
ここを決めないと無期限に溜まりますし、容量の問題だけでなく古い情報が参照されるリスクもあります。

棚卸しそのものの回し方は使われていない資料が精度を下げる。ドライブ棚卸しを自動化するで扱っています。

あわせて権限の設計も要ります。
会議によって閲覧範囲が違うので、部門をまたぐ会議は関係する部門に、経営会議や人事に関わる会議は限定し、これは集約の対象から外すという判断もあります。
顧客との会議は、営業部門と関係部門に絞ります。

「閲覧範囲が限られる会議は集約しない」という線を引くのが確実だと思います。
集約してから範囲を絞るより、最初から対象外にしておくということです。

文字起こしは長く残し、録画は短く残す

録画と文字起こしは、同じように扱ってよいのでしょうか？
実務上、ここに論点が1つあります。
録画は容量が大きく、文字起こしのほうは小さいという差があります。
後から参照されるのはほとんど文字起こしのほうなので、設計を分けておきます。

文字起こしのほうは長く残します。
容量が小さくて参照されますし、AIの参照先にもできるからです。
録画は短く残して3か月程度にしておき、画面共有の内容が重要な会議だけ長く残します。
この分け方だけで容量の問題はほぼ解決しますし、参照の利便性のほうも落ちません。

あわせて「録画がないと分からない会議」を特定しておきます。
画面上で数字や図を見ながら議論した会議のことで、ここについては録画も長く残します。

参照先そのものの整え方はファイルサーバをAIの参照先にする。ドライブ整理はAI活用の前提工事にまとめてあります。

失敗の型は、だいたい6つに集約されます。
全部の会議を集めてしまう、移動ではなくコピーにしない、通知を出さない、保存期間を決めない、閲覧範囲が限られる会議も集約する、録画と文字起こしを同じ期間残す、といったところです。
どれも、対象を絞って元のファイルを残し、通知を出して種類ごとに期間を決め、最初から対象外にして分けて扱えば避けられます。

集めた文字起こしを参照するGemini Notebookを作ったら、当社の組織のAIポータル「AI Portalize」に登録すると全社に公開され、使われた回数と使った人数が作った人に返ってきます。

保存先と保存期間さえ決まれば、会議データは資産になる

会議データが個人領域に散っていると、参加していなかった人が確認できない、過去の経緯を追えない、主催者の異動で失われる、要約や分析につなげられない、保存期間の管理ができない、という問題が起きます。

進め方は3フェーズで、保存先を1つ決め、自動コピーで集め、検索と分析につなぐ、という並びです。
保存先は3階層・日付を先頭にした命名にして、集める対象は部門をまたぐ会議、決定を伴う会議、顧客との会議に絞ります。
個人の1on1や短時間の共有は、対象外で構いません。

自動コピーは、元のファイルを残し、対象を絞り、重複を防ぎ、通知を出し、一覧を作る、という設計にします。
保存期間は種類ごとに決め、決定を伴う会議は3年、定例は1年です。
権限は会議によって違うので、閲覧範囲が限られる会議は集約しないという線を引いておきます。

また、録画と文字起こしは分けて扱います。
文字起こしは長く残して、録画は3か月程度にします。
画面共有の内容が重要な会議だけ、録画も長く残します。
この分け方で、容量の問題はほぼ解決します。

まずは会議データを保存する場所を1つ決めて、集める対象の条件を書き出してみましょう。