- AWS Builder Center›
 - builders.flash
 
「話すだけで仕事が終わる」世界へ ~ Amazon Bedrock で作るリアルタイム AI 議事録アプリケーション
2025-11-04 | 岳獅 悠司 (株式会社デイトナ・インターナショナル)
はじめに
はじめまして、株式会社デイトナ・インターナショナルの岳獅と申します。
私たちは「FREAK'S STORE」等のアパレル事業や、住宅事業等、『衣・食・住』におけるライフスタイル事業を展開しています。私が所属する DX本部では、自社 EC サイト「Daytona Park」の運営を担っています。EC サイトの運営は、日々スピーディな意思決定が求められるため、チーム内の情報共有や議論の場である「会議」が非常に重要な役割を占めます。
この会議という日常業務のあり方を AI 技術によって根本から見直し、より生産的な時間にできないか。そうした問題意識を背景に、AI を活用したリアルタイムで議事録を自動更新するアプリケーションの開発が始まりました。
本記事では、このプロトタイプ開発の着想から、直面した技術課題、そして会議で「話すだけで仕事が終わる」という将来のビジョンと、それを支える具体的な AWS アーキテクチャまで、詳しくご紹介します。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
課題 : 議事録作成とその後のタスク管理のコスト
会議が終わった後、その内容を議事録としてまとめ、関係者に共有し、そこから発生したタスクを洗い出して担当者に割り振る。この一連の作業は、多くの組織で当たり前のように行われています。
もし、この「議事録」が会議の終了を待たず、議論と同時にリアルタイムで生成され、参加者全員で共有できるとしたらどうでしょうか ?
私はこの問いに、AWS のサーバーレスサービスと生成AIサービスを活用して挑戦することにしました。
すべての始まり : AI 議事録の精度への衝撃
このプロジェクトの着想は、既存の AI ツールに会議の録画データを入力し、議事録を生成させたときの体験にあります。出力されたテキストは、単なる文字起こしではありませんでした。議論の要点、課題、そして ToDo リストが驚くほど正確に整理されていたのです。1 時間の会議内容を、わずか 5 分で会議に出ていない人でも完璧に理解できる。この効率性に衝撃を受け、私はこう考えました。
「会議後にこれほどの価値を生み出せるなら、会議中にリアルタイムで提供できれば、生産性をさらに飛躍させられるのではないか」
この仮説からプロトタイプの開発をスタートしました。
リアルタイム議事録がもたらす価値
このアプリケーションが目指すのは、単なる作業の自動化ではありません。会議におけるコミュニケーションの質を高めることです。リアルタイム性がもたらす価値は、主に次の 3 つです。
1. 認識ズレの解消と時間短縮
 リアルタイムで生成される議事録を全員が閲覧することで、議論の前提や文脈が常に視覚的に共有されます。これにより、「今、何について話しているか」という認識のズレがなくなり、認識を合わせるために費やされていた時間を大幅に短縮し、本質的なディスカッションに集中できます。
 
2. 議論の質の向上
議論が本筋から逸れかけたときも、共有された議事録が「道しるべ」となり、自然と軌道修正を促します。ファシリテーターのスキルに依存せずとも、会議全体の生産性が向上します。
 
3. 参加の促進と理解の深化
専門的な議論で一時的に話の流れを掴めなくなった参加者や遅れて出席した参加者にも、テキストで内容を追いかけることで容易にキャッチアップできます。これにより、参加者全員が議論に貢献しやすくなります。
システム構成
プロトタイプの構築にあたり、スケーラビリティ、柔軟性、そして迅速な開発を実現するため、AWS のサーバーレスサービスを中心にアーキテクチャを設計しました。システムは大きく分けて、ユーザーが直接操作する 2 つのクライアントと、それらを支えるサーバーサイドで構成されます。
クライアントアプリケーション
ユーザーが議事録機能を利用するために、役割の異なる2つのクライアントを用意しました。
 
                  1. Electron 製アプリケーション
1 つ目は会議の音声をリアルタイムで音声認識エンジンに送信するための macOS 向けデスクトップアプリケーションです。会議参加者のうち誰か 1 人が起動すれば、システムおよびマイクの音声がキャプチャされ音声認識エンジンへ送信されます。音声認識エンジンから返ってきた文字起こし結果を AWS に送ります。
 
 
                  2. Web ブラウザ (会議参加者用)
2 つ目は会議の参加者全員がブラウザでアクセスできるウェブページです。Amazon CloudFront 経由で配信され、WebSocket を通じて文字起こし結果や生成された議事録がリアルタイムに表示されます。
 
サーバーサイドアーキテクチャ
サーバーサイドは、AWS CDK を用いてコードでインフラを定義しています。Electron から送られる文字起こし結果をもとにリアルタイムな議事録を配信します。この文字起こし結果には発話途中の「中間テキスト」と発話が完了した「確定テキスト」の2種類があり、両者を組み合わせてリアルタイムな文字起こし結果を配信しつつ、確定テキストは議事録作成に利用されます。
アーキテクチャにおける主要な処理
主要な処理は以下の通りです。
 
 ① リアルタイムな文字起こし表示 : Electron から送られる表示用の全テキスト (中間および確定) は、Amazon API Gateway の WebSocket API に送信されます。この API は、受け取ったデータを保存することなく、低遅延で Web ブラウザ向けのクライアントへ WebSocket で配信する責務のみを担います。
 
 ② 議事録データの受付と永続化 : 一方で、議事録生成の元データとなる確定テキストのみが、API Gateway の REST API に送信されます。リクエストはまず AWS Lambda オーソライザーで認証され、許可されたリクエストのみが後続の Lambda に渡され、文字起こし結果として Amazon DynamoDB に保存されます。
 
 ③ 非同期での AI 処理実行 :  データ永続化を担当する Lambda は、未処理のテキストが規定量を超えたことを検知すると、Amazon SQS の FIFO キューにメッセージを送信します。この際、処理の順番を守るため会議ごとに発行される ID を MessageGroupID として指定します。
 
 ④ AI による議事録生成と更新 : SQS キューをトリガーとして、AI 処理専用の Lambda が起動します。この Lambda は DynamoDB から文字起こし結果を取得し、後述する 2 段階の AI 処理を実行します。AI 処理を完了した Lambda は、API Gateway の WebSocket API のエンドポイントを呼び出し、会議の参加者へ最新の議事録データを配信するよう指示します。これにより、各参加者が閲覧している Web ブラウザの画面がリアルタイムに更新されます。
 
 
  
AI 処理の核心 : デュアルエンジンによる音声認識精度の克服
- 異なる特性を持つ 2 つの音声認識エンジンをクライアントで同時に実行します。
 - それぞれの文字起こし結果をサーバーへ送信します。
 - 後段の AI 処理で、2 つの結果を比較・統合し、より文脈に即した正しいテキストを生成させます。
 
Amazon Bedrock の活用ポイント : 戦略的なタスク分割とモデルの使い分け
- 第 1 段階 (統合処理) : 2 つのエンジンの文字起こし結果を Amazon Bedrock に渡し、精度の高い統合テキストを生成させます。この処理では、メインとなるエンジンの結果を基準に、サブエンジンの結果で誤認識を補正するよう指示しています。
 - 第 2 段階 (議事録差分反映処理) : その統合テキストとこれまでの議事録の文脈を基に、再度 Amazon Bedrock へ差分更新をリクエストし、自然な形で議事録に追記させます。ここでは、議事録の編集操作を JSON 形式で出力させることで、意図しない変更を防ぎ、安定したリアルタイム更新を実現しています。
 
さらに、この構成は Amazon Bedrock の強みであるモデル選択の柔軟性を最大限に活かせます。例えば、第 1 段階の比較的単純な「統合処理」はコスト効率に優れた軽量・高速なモデルに任せ、第 2 段階の文脈理解が重要な「議事録への差分反映」はより高性能なモデルに担当させる、といった戦略的な使い分けが可能です。これにより、コストとパフォーマンスの最適なバランスを追求できます。
プロンプトの実装例
第 1 段階 (統合処理)
メインエンジンの文字起こし結果を基準とし、サブエンジンの結果を参考にしてメインエンジンの誤認識部分を補正する
サブエンジンの範囲がメインエンジンを超えた部分の内容は一切採用せず、メインエンジンの文章の範囲内でのみ補正を行う
# メインエンジンの結果(補正対象):
{master_text}
# サブエンジンの結果(補正参考):
{sub_text}
# 出力範囲
-メインエンジンの文章構造と範囲を維持する。サブエンジンの前後の余分な文章は絶対に追加しない
- メインエンジンの発言範囲を超えた内容は追加しない。サブエンジンが前後に多くの内容を含んでいても、メインエンジンに対応する部分のみを使用
# 補正
- メインエンジンとサブエンジンを照らし合せて最終的なtextを決定する
- 前後の文脈から話者の意図を理解し、誤字脱字を補正する。文章の流れが自然になるように補正する
- 文脈から漢字の誤変換があると思ったら、一度ひらがなにしたうえで意味の通じる漢字に変換する
# タイムスタンプ
- タイムスタンプはメインエンジンのものをそのまま採用
# 例
- メイン: "久しぶりですね!こんにちは今日もい転機ですね"
- サブ: "こんにちは今日も良い天気ですね。このあとはなにをなさるのですか"
- 結果: "久しぶりですね!こんにちは今日も良い天気ですね" (メインの範囲内で「い転機」を「良い天気」に補正)
# 出力形式
補正後の文字起こしを以下のJSON配列形式で出力すること:
# 重要な注意事項
レスポンスされた文字列をそのままJSONパースするので、下記のような形式で出力すること。説明や思考過程は一切含めない
[
  {
    "text": "補正後のテキスト",
    "startTime": "メインエンジンの開始タイムスタンプ (ISO 8601形式)",
    "endTime": "メインエンジンの終了タイムスタンプ (ISO 8601形式)",
    "timezone": "{timezone}",
    "confidence": 0.95
  }
] 
                   第 2 段階 (議事録差分反映処理)
あなたは書記担当である。順次与えられる文字起こしの内容から議事録をリアルタイムで反映する
以下の指示に従い、JSON配列形式の操作のみ出力する。説明や思考過程は出力しない
# 現在の議事録(行番号付き)
{current_minutes_with_lines}
# 既に議事録に反映済みの文字起こし(直近抜粋)
{sent_transcripts}
# 新しい文字起こし
{new_transcripts}
# 編集ポリシー
- 編集可能範囲: 議事録末尾の最新トピックのみappend, insert, replace, delete可能
    - トピックとは「##」または「###」見出しから始まるブロックを指す
- 最新トピックよりも上の行(古い部分)は編集禁止。似た内容があっても統合しない
- 新しい話題になったら新規トピックを末尾へappendする
# 議事録の方針
- 新しい文字起こしの反映
    - 誤字脱字の修正: 議事録全体の文脈で補正する
    - 要点の抽出: 重要点を要約して記載(発言者は特定しない)
    - 分かりやすい文章: 議事録全体を通して分かりやすい内容にする
    - 冗長な内容の省略: 全ての内容を議事録に載せようとはせず、全体を通してノイズになる内容は省く
    - 人名の取り扱い: 人名は全てカタカナ表記で書く
- 議事録全体の整理
    - 構造化: 関連情報をトピック化し、「##」「###」でタイトルをつける
    - 具体的なトピック名: 「スケジュール」「デザイン」「テスト」など、なるべく具体的にする
    - トピックのボリューム: 1トピックあたり最大10行以下に抑える
    - 階層化: トピックの内容は「-」で箇条書きをし、さらに「スペース2文字 + -」を使い字下げして読みやすくする
    - 時系列: 上から下へ進行。新規は常に末尾へ
# 良い議事録の例
## スケジュールについて (←「##」でトピックの大見出し)
### 開発スケジュール (←「###」でトピックの小見出し)
- 技術的課題が存在する (←「-」で箇条書き)
    - 再現性のないバグが発生している (←詳細を字下げして見やすく)
    - xxxの実装方法が不明
- 1週間延長
### 全体スケジュール
- 影響なし
## デザインのタスク
- フィードバックを反映する
- 開発チームに変更箇所を共有する
# 操作方法
## append: 末尾に追加
[{"type": "append", "content": "## デザインのタスク\\n- フィードバックを反映する\\n- 開発チームに変更箇所を共有する"}]
## replace: 指定行の内容を変更
[{"type": "replace", "index": 7, "content": "- 影響なし"}]
## insert: 指定行の直前に挿入
[{"type": "insert", "index": 5, "content": "- 1週間延長"}]
## delete: 指定行を削除
[{"type": "delete", "index": 3}]
# 必須条件
- 返答は必ずJSON配列のみ返す
- 最大5個の操作まで(重要な変更を優先)
- JSONが途切れないように完結させる
- 各contentは最大200文字まで
- 出力全体は必ず1500文字以内
- 許可操作: append(常時)/ replace・insert・delete(編集可能範囲内のみ)
# 重要な指示
あなたの出力は以下のJSON形式のみでなければならない。説明や思考過程は一切含めない
出力例:
[
  {"type": "append","content":"- 開発チームに変更箇所を共有する"}, 
  {"type": "replace", "index": 9, "content": "- フィードバックを反映する"}
] 
                   将来の展望 :「話すだけで仕事が終わる」世界の実現
このアプリケーションの最終的な目標は、単なる議事録ツールを開発することではありません。会議で「話すだけで仕事が終わる」という、新しいワークフローを作り出すことです。 このビジョンは、AI の役割を現在の「記録」から、より能動的な「実行」へと進化させることで実現します。今後の発展として、例えば以下のような可能性を考えています。
マルチモーダル AI によるリアルタイムな「共同デザイン」
アパレル企業ならではの活用例として、デザイン会議への活用が挙げられます。デザイナーと企画担当者が会議で新しい服のデザインについて議論するとします。「もう少し襟を広くして、袖にフリルを加えてみよう」と話すと、その言葉を理解したマルチモーダル AI が、リアルタイムでデザイン画を生成し、画面に表示します。参加者はそのビジュアルを見ながらさらに議論を深め、アイデアを即座に形にしていく。会議が、ダイナミックな共同デザインの場へと変わっていくかもしれません。
 
AI エージェントによるタスクの即時実行
さらに、AI をタスク実行の「エージェント」として活用することも考えられます。会議における人間の役割は「責任を伴う意思決定」に集約され、AI はその決定をトリガーに、タスクを実行するパートナーとなります。
ソフトウェア開発の会議で「この件、GitHub で issue を切ってください」と発言すれば、AI が即座に課題化し、Pull Request の作成まで着手する。さらに「この変更を検証環境にデプロイして」と指示すれば、その場でビルドとデプロイが実行され、参加者は会議を中断することなく動作確認まで行える。人間の「言葉」が、瞬時にタスクやコードに変換され、議論から実装、確認までのサイクルが会議という場で完結する。私はそのような未来の実現を目指しています。
 
まとめ
本記事では、AWS の各種サービスを活用して構築した「リアルタイムAI議事録アプリケーション」の概要とアーキテクチャを紹介しました。
サーバーレスサービスと生成 AI の組み合わせは、これまで難しかったアイデアをスピーディーに形にできる可能性を示してくれます。
この取り組みが、皆様の業務改善や新たなソリューション開発のヒントとなれば幸いです。
筆者プロフィール
岳獅 悠司
 株式会社デイトナ・インターナショナル
テックリード
2021 年 9 月に株式会社デイトナ・インターナショナル入社。テックリードとして社内基盤システムの立ち上げをゼロから主導。サーバーサイド開発から、CDK を用いた AWS インフラ構築まで、システム全体のアーキテクチャを統括しています。技術⾯でプロジェクトを牽引しながら、同時に生成 AI を活用した取り組みでチーム全体の生産性を上げるべく日々模索しています。
趣味はサウナで、思考が煮詰まったときは決まってサウナへ駆け込みます。熱い室内で思考をリセットし、水風呂で頭をクリアにする。クリエイティブなアイデアはいつも「ととのい」の瞬間に降りてきます。