会議の録画から議事録まで、どこまで自分たちで組めるのか。録画と文字起こしは外部のオンライン会議サービスに任せ、Walkersではカレンダー予定との突き合わせ、決定事項とネクストアクションを整理した構造化議事録の生成、お礼メール下書きの作成までを組みました。送信するかどうかの判断は最初から人に残し、動かして初めて分かったのは保存が全件失敗しても気づけない失敗の形でした。（※本記事は2026年7月〜8月時点の社内運用記録に基づくものであり、2026年10月時点の最新の稼働状態を保証するものではありません）
何を自動化したか
以前は、会議のメモや文字起こしテキストから、担当者がテンプレートに沿って議事録を手作業でまとめ、決定事項やネクストアクションの表を書き起こし、保存先に整えて保存する運用でした。この手作業のフローは、当時の運用でも一部の会議で使われていました。社内外を含めた日々の会議すべてにこの手順を手動で回すのは負荷が大きいため、Walkersは並行して処理パイプラインの自動化を進めました（ただし8月26日時点の記録では、後述のように生成処理の自動起動未登録や認証課題が残り、手動実行を併用していました）。
自動化の出発点は、当時の外部サービスの制約でした。利用していたオンライン会議の録画・文字起こしサービスには、特定の会議だけを狙って録画ボットを送り込むための仕組みが用意されていませんでした。そこでWalkersは、録画そのものはサービス側のカレンダー連携設定に任せ、社内の仕組みは「録画された会議とカレンダーの予定を突き合わせ、議事録を作り、必要な人に届ける」判定・生成・表示の役割に絞る設計にしました。
具体的には、次の流れで進みます。
- カレンダー上の予定から、社外の参加者がいる会議を判定し、進行中の商談と突き合わせます。
- 録画・文字起こしサービス側にたまった録画の一覧を定期的に確認し、まだ処理していないものを、日付や会議のタイトル、開催時刻の近さから該当する会議と紐づけます。
- 紐づいた会議の文字起こしをもとに、AIが決定事項・宿題・要点を整理した構造化議事録を作ります。
- 議事録が保存された直後に、お礼・決定事項・ネクストアクション・次回日程を盛り込んだメールの下書きを自動で作成します。
なお、2026年7月からは、商談と紐づけられなかった会議（社内MTGなど）も含め、録画・文字起こしを取得できた会議はすべて議事録化の対象にしています。以前は商談以外をスキップしていましたが、取得できたものは全件議事録化する方針に変えたことで、議事録を作るかどうかの判定を挟まずに済むようになりました（商談との紐づけ処理自体は継続しています）。
生成された議事録は、一覧・詳細の画面に表示されます。商談と紐づいた議事録は該当する案件のページからも参照でき、紐づかなかった議事録は「社内・その他」として区別して表示されます。ネクストアクションと宿題は、ホーム画面のパネルにも自動で表示され、担当者が毎回議事録を開かなくても宿題の有無を確認できるようになっています。
仕組みの全体像
この一連の流れは、当時の社内運用において、複数の処理が役割ごとに時間を分けて動くことで成り立っていました（※2026年8月時点の設計・稼働記録に基づく）。
- 1. 会議録画・文字起こし 外部会議サービスが自動録画・文字起こしを実施（録画対象設定は人が事前管理）
- 2. 録画取得とカレンダー照合 プログラムが定期収集し、カレンダー予定や商談情報と紐づけ判定（未紐づけも「社内・その他」として保持）
- 3. 構造化議事録の生成・保存 AIが決定事項や宿題を整理して議事録を生成・保存（※8月26日記録時点は自動起動未登録・認証失効のためキュー滞留と手動併用）
- 4. お礼メール下書き作成 AIが決定事項・次回日程を反映したメール下書きのみを自動作成（未確定の日時は出力しない）
- 5. 内容確認と送信判断 担当者が内容と送信可否を必ず目視で確認し、手動で送信を実行
外部サービス・自動プログラム・AI推論・人の手作業の役割境界を分離し、送信や認証復旧などの重要判断は人の工程として残しています。
| 工程 | 担当 | 頻度・時刻（JST） |
|---|---|---|
| 社外参加者ありの会議を判定し、商談と突き合わせる | プログラム＋AI（自動判定） | 1日2回（7:45・21:45頃） |
| 会議リンクが未設定の予定にリンクを自動で付与する | プログラム（自動） | 1日2回（7:30・21:30頃） |
| 会議の録画・文字起こし | 録画・文字起こしサービス（自動） | 会議開催時 |
| 録画一覧の確認と会議の突き合わせ、文字起こしの取得 | プログラム（自動収集） | 毎時50分頃 |
| 決定事項・宿題を整理した構造化議事録の生成 | AI（自動生成） | 収集後、処理待ちキューから順次実行（※8月26日時点は自動起動未登録で手動併用） |
| お礼メールの下書き作成 | AI（自動生成・下書きのみ） | 議事録保存の直後 |
| お礼メールの送信可否の判断・送信 | 人 | 都度 |
会議リンクを自動で付与する工程が入っているのは、リンクが設定されていない予定には録画・文字起こしサービスが自動参加できないためです。自社の担当者が主催し、他の参加者が1名以上いて、場所が空欄の予定だけを対象に、通知を送らずに設定します。この表に記載した通常処理の範囲では、「お礼メールの送信」だけを自動化せず、人の判断を挟む工程として残しています（例外対応や設定変更など、運用上人が担う工程は後述します）。
実際に起きた失敗と直し方
自動化してからここまで、いくつかの失敗を経験しています。起きた順に記録します。
- 2026年7月12日: 録画・文字起こしサービスが返す日時の形式が、保存先のデータベースが期待する形式と合わず、保存処理が全件失敗していました。しかも保存の失敗を記録に残さない作りだったため、誰も気づけないまま無症状で動き続けていました。対策として、日時の形式を正規化する処理を追加し、保存に失敗した場合は必ず記録に残す作りに直しました。
- 2026年7月12日〜13日: 開発環境の取り扱いをめぐる事故で、議事録関連のファイルを含む複数の作業資産が2日連続で消えるトラブルが起きました。対策として、未反映だった作業をまとめて本流（統合済みのコード）に統合し、以降は本流と作業環境が一致した状態を保つ運用にしました。
- 2026年8月16日: 利用しているAIサービスの月間利用上限に到達し、議事録の生成が20件まとめてエラーになって止まりました。しかも、AIの利用料金を表示するパネル自体が同年6月20日から表示エラーで止まっていたため、上限が近づいていることに事前に気づけませんでした。対策として、上限が解除されるのを待ってから未処理分をまとめて再実行する運用にし、料金表示側の不具合原因の洗い出しを行いました（解消済みの判定までは行っていません）。
- 2026年8月26日: 議事録を生成するAIの呼び出し先を切り替える移行を行った当日、切替後の初回実行が認証切れで全て失敗しました。認証状態を確認するコマンド自体は「ログイン済み」と表示してしまうため、実行時の失効に気づきにくい罠もありました。この日はエラーとなった3件をキューへ再投入し、20件すべてを再実行待ち（pending）の状態へ戻す対応を行いました。ただし、認証失効自体の解消は残っており、自動起動も未登録だったため、生成処理が成功して完了復旧したわけではありません。
- 2026年8月27日時点: 認証切れからの再ログイン作業は人の手でしか行えないため、この時点でも認証の復旧待ちが続いていました。
作業資産の消失を除けば、保存失敗の未記録、料金パネル停止による上限検知遅れ、認証確認コマンドの表示と実行結果の不一致など、異常に気づくための仕組みが機能していなかった失敗が多くありました。エラーで派手に落ちる失敗より、無症状のまま止まっている失敗のほうが、気づくまでに時間がかかります。
人に残った判断
自動化を進めた段階においても、いくつかの判断や運用作業は人の手に残っています（2026年8月時点の記録に基づく）。
- 会議の録画対象範囲の設定: 「すべての会議を録画するか」「社外との会議に限るか」は、録画・文字起こしサービス側の管理画面でしか変更できず、この設定権限は特定の担当者1名に限られていました。
- お礼メールの送信可否: 自動で作られるのは下書きまでで、実際に送るかどうかは必ず人が読んで判断してから操作します。
- 議事録ドラフトの最終確認: 並行運用している手作業フローでは、ドラフトは必ず人が確認したうえで確定し、推測で確定させない運用が明文化されています（自動生成された議事録についても、未確定事項を勝手に補完させない設計にしています）。
- ネクストアクションの担当決め: ネクストアクションの表には担当・期限の欄がありますが、割り当てを自動で決めるロジックはなく、担当者が内容を見て決める手順になっています。
- 認証切れからの復旧: AIの呼び出しに使う認証が切れた際の再ログイン作業は、人手で行う必要があります。
設計の原則
いくつかの失敗を経て、Walkersでは次のような原則を積み重ねてきました。
- 固定時刻に依存しない（キュー管理）: バッチの起動時刻自体は決めておきつつ、処理対象はキュー（待機中の処理一覧）に保持して起動時にまとめて処理する設計にしています。実行環境が一時停止しても、データが消失せず次回起動時に持ち越せるようにするためです（自動起動や認証が正常に整っていることが前提となります）。
- 本流と一致した環境から動かす: 各自の作業環境ではなく、常に最新の本流（統合済みの本番コード）を反映した専用の実行環境から動かします。
- 切替は片側ずつ、猶予期間を置かない（設計原則）: 新しい仕組みの稼働を確認してから旧仕組みの設定を止め、両方が並走して重複処理を起こす期間を作らない方針を原則としています。
- 止まっても安全側に倒す: 一部のAI生成処理が止まっても、録画やカレンダーの情報を集める収集処理は止めず、未処理分をキューにためておき、障害解消後にまとめて再実行できるようにしています。
- 同じ処理を重複させない: 同じ会議の録画を重複して登録しないよう、会議ごとに一意な識別子（重複判定用の会議ID）を持たせています。
- 無限にリトライしない: 開催から一定の日数を過ぎても文字起こしが手に入らない場合は「取得不可」として記録し、それ以上のリトライを打ち切ります。
- 収集と生成の役割を分ける: 録画完了の通知は受信の記録だけにとどめ、議事録の対象収集と生成はキューを介して分離する構造にしています。通知のたびに即時生成を走らせると、二重生成や取得途中の取りこぼしを招きやすいためです（収集処理とキューからの生成実行を分けて管理します）。
- 送信は絶対にしない: お礼メールは下書きの作成までで、送信そのものを行うAPIは呼びません。
- 確定できない内容は書かせない: 次回の打ち合わせ日時が確定できない場合は、その段落自体を出力させません。埋め草（推測の文言）を書くほうが、かえって失礼になるという判断です。
無音のまま失敗しないことを、機能の正しさと同じくらいの優先度で設計しています。毎朝の定期実行の記録でも触れていますが、正常に終わったように見える失敗をどう防ぐかは、自動化の運用でくり返し向き合っているテーマです。完了報告だけで済ませず成果物を確かめる観点は、現場運用の生成AIの社内ルールづくりにも共通します。
中小企業が同じことをするなら
同じ仕組みをゼロから作る必要はありません。まず着手するなら、次のような順番が現実的です。
- 録画の対象範囲と同意を先に決める: 「すべての会議を録画するか」「社外との会議に限るか」を最初に決め、関係者の同意を取っておきます。
- 議事録の型を先に決める: 見出し・決定事項・ネクストアクションをどう並べるかを先に固めてから自動化に着手すると、後からの手直しが少なくて済みます。
- 送信は必ず人が行う: メールなど社外に届く工程は、下書きまでを自動化の範囲にとどめ、送信は必ず人の確認を挟みます。
- 紐づかなかったケースの扱いを決めておく: 商談と紐づけられない会議をどう扱うか（対象外にするか、社内MTGとして別枠で記録するか）を最初から決めておくと、あとから対象範囲で悩まずに済みます。
営業活動の情報をどのように自動で読み取っているかについては、別記事の営業パイプラインの自動化にまとめています。なお、どのような方式で議事録AIを組むかや運用ルールの決め方については議事録のAI活用が扱い、本記事では実際に自社で動かした記録を受け持っています。
よくある質問
会議の録画から議事録まで、具体的に何を自動化していますか？
会議の録画・文字起こしは外部サービスを活用し、Walkers側ではカレンダー予定との突き合わせ、決定事項やネクストアクションを整理した議事録の生成、お礼メールの下書き作成までのパイプラインを構築しました。なお、2026年8月時点の記録では、認証失効への対応や生成処理の自動起動登録などの課題があり、手動実行や人手の復旧作業を併用しながら運用していました。
お礼メールは自動で送信されるのですか？
いいえ。自動で作られるのは下書きまでで、送信するかどうかは必ず人が判断します。次回の打ち合わせ日時が確定できない場合は、その段落自体を書かせない設計にしています。
議事録の自動化で失敗したことはありますか？
あります。日時の形式が合わずに保存が全件失敗していた、AIサービスの利用上限に到達して生成が止まった、認証切れで初回実行が失敗した、などを経験し、その都度対策を積み重ねてきました。
中小企業が同じ仕組みを作るには何から始めればよいですか？
録画の対象範囲と同意を先に決め、議事録の型を固めたうえで、送信を伴う工程だけは必ず人が確認する設計にすることをおすすめします。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。1社ごとに専用の環境を用意し、議事録を含む定常業務のAI活用を伴走するFDE型の仕組みについては、FDE-NOAHをご覧ください。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。
