はじめに
社内のハッカソンで、「AIがファシリテーターになれるか？」という問いに挑戦してみました。
リアルタイム音声認識や生成AIを使って、会議の進行を助けるWebアプリケーションのプロトタイプを開発してみた、という話です。
本記事は、ハッカソン期間中に作成したプロトタイプの途中経過レポートです。
まだまだ課題だらけで、実用レベルには程遠い状態なんですが、技術検証の過程で得られた学びや気づきを共有したいと思います。
また、本記事は技術寄りの記事ではなく、サービスの概要・設計・課題に焦点を当てた内容となっています。技術的な内容の詳細は同じメンバーが別記事として投稿していますので、リンクを貼っておきます。
モチベーション
これをやろうと思ったきっかけは以下です。
- 音声処理技術への興味: 音声 ↔️ テキストの相互変換を実装してみたかった
- AIの人間らしさへの挑戦: どこまで人間っぽい動きに近づけられるか試したかった
- 実用性: ファシリテーションをしてほしいニーズは実際にありそう（調べては無い）
目指したもの
ファシリテーションのやり方は人それぞれ（1回目）ですが、今回は会議中の発言をリアルタイムで音声認識して、議論が停滞したタイミングでAIが適切な質問や提案を投げかけることで、会議を活性化させるアプリケーションを目指してみました。
実装した機能（プロトタイプ）
- リアルタイム音声認識: 会議参加者の発言を即座にテキスト化
- 無言検知: 議論が止まったタイミングを自動検知
-
タイムキーパー: 時間経過に応じて適切なファシリテーション
- 前半: 議論を広げる質問
- 後半: 結論に導く発言
- 音声合成: AIの発言を自然な音声で出力（字幕付き）
- 議論の要約: 会議内容を自動でまとめる
動作例
理想的な動作としては、こんな流れを想定していました。
① 最初にAIが会議の内容を説明し、参加者が議論を始める
② 議論が進まず無言になる → AIファシリが質問 → 再び議論が活性化する
実際には、応答速度や認識精度の課題があって、スムーズな会話にはまだまだ課題が多い状態です。
技術スタック
- フロントエンド: Next.js, React, TypeScript
-
AWSサービス:
- Amazon Transcribe（音声→テキスト変換）
- Amazon Bedrock（生成AI）
- Amazon Polly（テキスト→音声合成）
- Amazon S3（音声ファイル保存）
システム構成
AWS構成図
基本的な処理の流れはこんな感じです。
[参加者の音声]
↓
[音声認識（Transcribe）]
↓
[テキスト化]
↓
[状況判断（停滞検知・時間管理）]
↓
[AI応答生成（Bedrock）]
↓
[音声合成（Polly）]
↓
[AIファシリの発言]
このサイクルを繰り返すことで、会議の進行をサポートします。
フロントエンドはNext.js、バックエンドはAWSのサービス群を活用しています。
設計の考え方と工夫
人間のファシリテーターを観察して分解する
AIにファシリテーションをさせるには、まず人間のファシリテーターが何をしているのかを把握する必要がありました。観察した結果、以下のような行動パターンに分解できそうかなと考えました。（ファシリテーションは多種多様なやり方があるので、一概にコレというわけではないです（2回目））
- 会議の目的と流れを説明する（開始時）
- 議論が止まったら質問を投げかける（停滞時）
- 時間を意識して話を進める（時間管理）
- 最後に結論をまとめる（終了時）
参加しているメンバー中心に議論を進めてもらって、行き詰まったりして無言が続いてしまったらファシリテーターが話しかけて議論のきっかけを作るスタイルです。（繰り返しになりますが、ファシリテーションは一概にコレというわけではないです（3回目））
これらをルールベースで実装してみました。
工夫したポイント
1. 時間駆動型ファシリテーション
会議の経過時間に応じて、AIの発言内容を変化させる仕組みを作ってみました。
- 前半（0〜50%）: 議論を広げる質問（「他にはどうですか？」「別の視点では？」）
- 後半（50〜100%）: 結論に導く発言（「そろそろまとめましょう。今は〇〇と△△と××の意見が出ています。」「決めるとしたら？」）
人間のファシリテーターが無意識に行っている時間感覚を、単純なルールで再現しようという試みです。
2. 無言検知による介入タイミング
ファシリテーターの重要な役割は「議論が止まったときに動く」ことです。テキスト化された発言の量と継続時間を監視することで、停滞を検知しています。
3. 処理速度の改善
リアルタイム性を重視して、音声データの送信方式をストリーミング化しました。
改善結果: 応答時間 30秒 → 7秒
とはいえ、人間の会話のテンポ（1〜2秒）には遠く及びません。
直面した課題と学び
ハッカソンを通じて、AIファシリテーションの難しさと奥深さを実感しました。
技術的な課題
1. 応答速度が遅い
最大の課題はリアルタイム性の欠如でした。
- 音声のテキスト化に最低4秒
- AI応答生成に2〜3秒
- 音声合成に1〜2秒
合計で7〜9秒もかかってしまいます。人間の会話のテンポ（1〜2秒）からは程遠く、会話が途切れてしまうんですよね。
2. 認識精度の問題
複数人が同時に話したり、声が小さかったりすると、正確にテキスト化できません。これで誤った判断をしてしまうことも。
3. ネットワーク環境への依存
音声データの送受信はネットワーク環境に強く影響されます。不安定な環境では、さらに遅延が増加します。
本質的な課題
技術的な問題以上に、ファシリテーション自体の難しさを痛感しました。
1. 「空気を読む」ことの難しさ
人間のファシリテーターは、言葉以外の情報（表情、声のトーン、視線、沈黙の質）を総合的に判断しています。音声だけだと、判断材料が圧倒的に足りないです。
2. 適切なタイミングの判断
「いつ発言すべきか」の判断が非常に難しかったです。早すぎると議論を遮ってしまうし、遅すぎると間が持たない。この感覚をルール化するのは困難でした。
3. 文脈の理解
単純な時間ベースのルールでは、議論の内容や流れを理解できません。「今、議論が盛り上がっているのか、停滞しているのか」を正確に判断するには、より高度な文脈理解が必要です。
これらの課題により、現時点では実際の会議で使えるレベルには達していません。
得られた学び
一方で、実装を通じて多くの気づきもありました。
1. 人間の判断の凄さ
処理フローを設計する過程で、人間が無意識に行っている判断の複雑さと素早さはやっぱり凄いなと思いました。「場の空気を読む」「適切なタイミングで発言する」といった行動は、実は高度な情報処理の結果になんだなーと。
2. 技術選定の重要性
音声処理の技術選定が、全体の性能に大きく影響することを学びました。リアルタイム性を重視するなら、もっと高速な音声認識サービスを検討する必要がありますね。
3. プロトタイピングの価値
実際に作ってみることで、机上では見えなかった課題が明確になりました。特に「どこが技術的な問題で、どこが本質的な問題か」がはっきりしたのは大きな収穫です。
今後の展望
このプロトタイプをベースに、以下のような改善を考えています。
短期的な改善
- 処理速度の高速化: より高速な音声認識サービスの検討
- マルチモーダル化: 音声だけでなく、映像（表情・視線）も活用
- 文脈理解の強化: 議論の内容を理解して、より適切なタイミングで介入
長期的な目標
- 効果の定量的な測定: AIの介入が本当に議論を活性化させるか検証
- 動的なファシリテーション: 議題や参加者の特性に応じて振る舞いを調整
- 人間との協調: 人間のファシリテーターを置き換えるのではなく、補助するツールとしての活用
まだまだ道のりは長いですが、少しずつ改善していければと思っています。
まとめ
ハッカソンを通じて、AIによるファシリテーションの難しさと奥深さを実感しました。
現状は、多くの課題を抱えたプロトタイプに過ぎません。 ただ、技術検証を通じて、実現に向けた道筋と解決すべき課題がはっきりしたのは良かったなと思います。
特に印象的だったのは、人間が無意識に行っている「場の空気を読む」「適切なタイミングで発言する」といった行動を、ロジックに落とし込む難しさです。これらは簡単に自動化できるものじゃないですが、だからこそ挑戦しがいのあるテーマだと感じています。
この記事は途中経過で、今後も改善を続けていく予定です。 処理速度の改善や、より自然なファシリテーションの実現に向けて、引き続き取り組んでいきます。
進捗があれば、また記事として共有できればと思います。
参考
NCDC株式会社( ncdc.co.jp/ )のエンジニアチームです。 募集中のエンジニアのポジションや、採用している技術スタックの紹介などはこちら( github.com/ncdcdev/recruitment )をご覧ください！ ※エンジニア以外も記事を投稿することがあります
Discussion