会議の効率化と聞くと、多くの方が「議事録をAIに書かせる」という話を思い浮かべます。私たちWeb制作会社のGrowGroup株式会社も、自社で会議支援ツール「GrowMeet」を内製したと言うと、たいてい「AI議事録ツールですね」と受け取られます。ですが、そのツールの設計仕様書は、「議事録」という言葉を一度も使っていません。全文を検索してもゼロ件です。
では何を作ったのか。答えを先に書くと、私たちは最初、まったく別のものを作ろうとして、それをやめました。やめた結果として残ったものが、今のGrowMeetです。
この記事は、そのツールがなぜ生まれ、何を目指し、何をあえてやらず、どこで失敗したかを、社内に残っている記録だけを根拠にして書いたものです。きれいな成功事例にはなりません。3ヶ月かけてまだ解けていない問題も、作ったのに消した機能も、そのまま書きます。会議の効率化を検討している方にとって、いちばん役に立つのは成功譚ではなく、「どこでつまずくか」の地図だと考えているからです。
目次
最初に作ろうとしたのは、Web会議ツールそのものでした
今のGrowMeetには、前身にあたるバージョンが存在します。そこで私たちが作ろうとしていたのは、AIでも議事録でもありません。ZoomやGoogle Meetのような、Web会議ツールそのものを自社で内製するという計画でした。
結論から言えば、これは断念しました。理由は明快で、インフラのコストが、運用の手間まで含めると高くつくことが分かったからです。映像と音声をリアルタイムに配信し続ける仕組みは、それ自体が巨大なインフラです。会議の本数が増えるほど費用は増え、その面倒を見る手間も増え続けます。私たちはWeb制作会社であって、会議インフラの運用会社ではありません。
そこで問い直したのが、「そもそも自分たちが本当に欲しかったものは何だったのか」です。並べてみると、答えは驚くほど小さいものでした。
- 会議が確実に録画され、決まった場所に残ること
- 高精度なリアルタイムの文字起こしがあること
- その文字起こしをAIに渡して、後続の仕事につなげられること
この3つに、「映像をリアルタイムに配信する」は含まれていませんでした。欲しかったのは会議の「場」ではなく、会議から出てくる「記録」と、その記録とAIの連携だったのです。だからそこにフォーカスし、Web会議の機能そのものは作るのをやめました。
ここが、このツールの設計の背骨です。GrowMeetはWeb会議機能を持ちません。すでにあるZoom・Google Meet・Microsoft Teamsの会議に、あとから相乗りして記録だけを取ります。この判断は、立派な思想が先にあって決まったのではありません。作ろうとして、コストに負けて撤退した経験から決まりました。失敗が、そのまま仕様になっています。
そして同じ問題意識は、その前後を通じて一貫しています。社内では以前から、Web会議のコストを下げたいこと、そして録画データが自動で1か所に集まらないことが課題として語られていました。同時に、ノーコードのワークフロー連携ツールは使わないという前提も置かれていました。手軽な連携ツールで貼り合わせる選択肢が最初から外れていたため、残るのは「自分たちで作る」だけだったのです。
ただし、正確に書いておきます。この一連の相談が「だからGrowMeetを作った」と明言された記録は、どこにもありません。因果としては書けません。言えるのは、「散らばる会議の記録を1か所に集約したい」「中間ツールに頼らず自前でやる」という問題意識が、複数の時点で一貫しているということまでです。
会議の効率化を阻んでいた、3つの課題
記録から読み取れる課題は、大きく3つに整理できます。特徴的なのは、そのうち1つは、作ってみるまで見えていなかったということです。
課題1：記録が、集まらない
Web会議ツールの録画は、たいていそのツールのクラウドに溜まります。会議ツールを乗り換えれば、置き場所も変わります。複数のツールを併用していれば、当然、記録は分散します。「あの会議、何て言ってたっけ」を確かめたいだけなのに、どこを探せばいいのか分からない。会議の効率化を阻む最初の壁は、AIの性能ではなく、この地味な散らかりです。
課題2：会議のあとの、転記の時間
Web制作の初回ヒアリングでは、決まった項目を聞きます。予算、時期、現状の課題、体制、目的。会議中は会話に集中したいので、聞いたことは会議のあとに、録画を見返しながらヒアリングシートへ手で書き写すことになります。会話はすでに終わっているのに、同じ内容をもう一度なぞる時間が発生していました。会議そのものより、会議のあとが重かったのです。
課題3：AIが、社内から信用されなくなった（作ってから分かった）
ここからが、作る前には見えていなかった課題です。
ヒアリングシートをAIが自動で埋める機能を作り、社内にリリースしました。そして不満が出ました。開発記録に残っているのは、次の2つです。
- 一度入力したら、その後は更新されない ── 会議の序盤にAIが埋めた内容は、後半でより正確な話が出ても書き換わらない。最初の一撃で固定されてしまう
- 精度が低い ── 埋まってはいるが、正しくない。結局すべて人が読み直すことになり、手で書き写すのと変わらない
この2つを解こうとすると、次の問題が待っていました。「更新されない」を直してAIが何度でも書き直せるようにすると、今度は人が直した内容まで、AIが別の答えで上書きしてくるのです。しかもAIは、なぜそう書いたのかを説明できません。人が確定させた答えが、根拠不明のまま勝手に書き換わる。この時点で、社内でのAIの信用は失われていました。
これは、AIツールを社内展開する会社が必ずぶつかる壁です。そして、精度をもう少し上げれば解決する、という種類の問題ではありませんでした。
目的：AIに「触らせない領域」を、人が宣言できるようにする
課題3への私たちの答えは、精度改善ではありませんでした。精度は上げ続ける前提としたうえで、それとは別に、「AIに触らせない領域を、人が明示的に宣言できる」仕組みを入れました。ヒアリングシートの各項目が持つ状態を、4つに拡張したのです。
| 項目の状態 | 意味 | AIの権限 |
|---|---|---|
| 未記入 | まだ誰も何も書いていない | 自由に書いてよい |
| AI記入済み | AIが埋めたが、人はまだ見ていない | より確からしい根拠が出たときだけ上書きしてよい |
| 確定 | 人が手で編集して確定させた | 上書き禁止 |
| ロック | 「これ以上AIで変えるな」と人が宣言した | 完全に対象外。触らない |
社内でこの機能がそのまま「これ以上AIで変えるな」と呼ばれているのは、それが必要とされた事情をよく表しています。上品な言い方ではありませんが、必要だったのはまさにこれでした。
あわせて、AIに根拠を言わせるようにしました。AIが項目を埋めるときは、「会議の何分何秒の、どの発言をもとにそう書いたか」をセットで返させ、画面上で確認できるようにしています。さらに、AI自身の確信度も画面に表示します。確信度が高いものは流し読みし、低いものだけ録画で確かめる。確認すべき場所が絞れるだけで、確認のコストは劇的に下がります。
ここが、この社内DXの最も大事な学びです。
「4つの状態」も「根拠表示」も、精度を上げるための機能ではありません。信頼を回復するための機能です。AIが人の決定を勝手に上書きし、その理由を説明できないなら、どれだけ賢くても現場では使われません。社内ツールが失敗する理由は、たいてい費用対効果ではなく、「怖くて使えない」のほうにあります。
意図的に「やらなかったこと」
目的がはっきりすると、やらないことが決まります。GrowMeetが意図的に持たなかった機能を、理由とセットで並べます。機能一覧より、こちらのほうが設計の中身をよく表します。
| やらなかったこと | 理由 |
|---|---|
| Web会議機能そのものを持たない | 作ろうとして、インフラコストと運用の手間で断念した。既存のZoom・Google Meet・Teamsに相乗りし、記録とAI連携だけに絞った |
| ノーコードの連携ツールを使わない | 中間ツールに依存せず自前で作る、という前提が最初から置かれていた |
| 文字起こしをデータベースに溜めない | 会議中はブラウザの中だけで保持し、会議後にファイルとして保存。共有場所へ転送できたら消す。会話の生データを溜め込まない |
| 要約もデータベースに溜めない | 同じ理由。成果物はファイルとして残し、システム側には残さない |
| 1つの会議につき、ファイルは1つだけ | 同じ会議の記録が何本も増えると、結局また探せなくなる。運用ルールではなく、データベース側の制約として構造的に強制している |
| 記録用のBotを、会議に再参加させない | 会議ツールの仕様上、主催者が退出したあとは同じ会議に戻れない。外部の仕様の限界を認めて、機能ごと諦めた |
特に見ていただきたいのが、下から2つです。「1件だけ」を運用ルールではなくデータベースの制約として強制している点。人の善意で守るルールは必ず破られますが、構造として不可能にしておけば破られません。「溜めない」も同じ発想で、消す処理を後回しにできない作りにしています。
そして最後の1行。できないことを認めて、機能を削除するのも設計判断です。「頑張ればなんとかなるかもしれない」で残した半端な導線は、使う人の時間を奪い続けます。
仕様書に書いた主役と、実際に主役になったものが違った
ここも正直に書きます。私たちが仕様書で主役に据えた機能は、主役になりませんでした。
実装の厚み──その機能のために専用に用意された処理の本数──で数えると、力の入り方は一目瞭然です。
| 機能 | 専用処理の本数 | 仕様書での扱い |
|---|---|---|
| ヒアリングシートのAI自動記入 | 5本（全機能中で最多） | 主要機能のひとつ |
| AI相談（会議中にAIへ聞く） | 2本＋振り分けの仕組み（急拡大中） | 仕様書に存在すらしない |
| リアルタイムのアドバイス | 1本 | 主要機能のひとつ |
| 感情分析 | 0本 | 主役として記載 |
読み取れることは3つあります。
- 実際の主軸は、ヒアリングシートのAI自動記入でした。専用処理が最多で、社内の不満に対する作り込みが投入された先もここです。「AI議事録ツールではない」というのは、言葉の綾ではなく実装の事実です
- 仕様書が主役に据えた感情分析は、専用処理が0本。最も薄く、事実上の飾りに終わりました
- 仕様書に存在しなかった「AI相談」が、あとから主力導線になりました。会議中に、その場でAIに聞ける機能です。開発の途中でタブとして追加され、今は社内のAI基盤と接続して急拡大しています
さらに、仕様書が定義した機能のうち、少なくとも3つは実装したあとで削除しました。一般画面と重複していた管理機能、使われなかった統計画面、設計時に決めていた保存方式。仕様書は、実装によって否定された箇所を含んだまま凍結されています。
これは失敗でしょうか。私たちはそう考えていません。仕様書は必ずズレます。ズレたときに実態のほうを正しいと認められるかどうかが、内製の成否を分けます。守るべきなのは仕様書ではなく、目的のほうです。会議ツールを作るのをやめた判断も、突き詰めれば同じことでした。
今日もまだ解けていない問題：日本語の文字起こし
会議の効率化を内製で狙う方に、いちばんお伝えしたいのがこの章です。私たちが最も苦しみ、いまだに勝てていないのは、日本語の文字起こしです。
開発の初期、私たちはわずか4日間で、文字起こしの提供元を最低10回入れ替えました。付けては外し、戻しては別のものを試す。この4日間だけを見ても、この領域がどれだけ厄介かが分かります。
問題の中心は、「日本語」「リアルタイム」「コストを抑える」の3つを同時に満たせないことでした。特にやっかいだったのが、字幕の言語が英語に強制されてしまうという現象です。日本語で話しているのに、英語の字幕が出る。手動で日本語に切り替えれば高精度かつ無料になる方法も見つけましたが、毎回人が切り替える前提の仕組みは、結局使われずに終わります。
最終的に私たちが打った手は、正面突破ではありませんでした。英語で出てしまう字幕を、そのまま後段でリアルタイムに日本語へ翻訳して表示する。つまり対症療法です。しかもこれは、最初の4日間の格闘から3ヶ月後のことでした。3ヶ月かけて、根本原因は解決できていません。
そして、この回避策の品質を、私たち自身が高く評価していません。日本語で話した内容を、いったん無理に英語へ変換し、それをまた日本語へ戻しているのですから、二重の変換を経た日本語が自然になるはずがありません。実際、社内での評価は「品質が微妙」です。使えないわけではないが、胸を張れる状態でもない。これが、この記事を書いている時点の正直なところです。
会議の効率化を内製で検討している方は、ここに一番時間を取られると思っておいてください。AIに何をさせるかを考える前に、そもそも日本語の会話がまともにテキストになるのか。ここが崩れると、その上に何を載せても崩れます。
成果 ── 測れているものと、測れていないもの
数字を盛らないために、出せる数字はひとつだけにします。
| 項目 | 内容 | 根拠 |
|---|---|---|
| 顧客会議のまとめ | 約30分 → 約3分 | 社内での申告値（厳密な計測値ではありません） |
| それ以外の削減時間 | 測っていません | 設計時に置いた試算値は実績ではないため、書きません |
3分がゼロではないところに実態が出ています。AIの出力をそのまま流すのではなく、人が目を通して直す時間が3分です。ここをゼロにすると、誰も確認していないものがお客様に届くことになります。3分は削るべきコストではなく、残すべき工程です。
一方で、時間では測れていない成果のほうが、実は大きいと考えています。
- 作りっぱなしになっていない：開発開始から約3ヶ月半、この記事の執筆時点でも開発は続いています。累計で約300回の変更が入りました
- 他の社内システムへ、実データを供給する基盤になった：たとえば面接の文字起こしを、採用業務のツール（GrowATS）へ自動で受け渡す仕組みが入りました。会議ツールが、他の業務の入力源に変わったということです
- 社内のAI基盤と接続した：会議の中身と、社内に蓄積された実データを横断して扱う段階に入っています
- 壊れなくなった：文字起こしの重複や録画の多重保存といった不具合を根本から解消しました。裏を返せば、それ以前は壊れていたということです
最後の項目は、社内ツールにとって決定的です。私たちが社内で繰り返し言ってきたのは、こういうバグがあると、みんな怖くて使えなくなるということでした。社内ツールに費用対効果の壁はありません。あるのは信頼の壁だけです。一度でも「怖い」と思われたら、どれだけ機能が優れていても使われなくなります。ロック機能も、根拠表示も、不具合の根本解決も、すべてこの一点に向かっています。
この経験から、御社の会議の効率化に移せること
GrowMeetは社内専用のツールで、販売していません。複数企業での利用にも対応しておらず、自社の他システムや社内AI基盤と密に結びついており、単体で切り出して売れる状態から、意図的に遠ざかる方向に進化しています。ですからこの記事は、ツールの宣伝ではありません。移せるのは、発想のほうです。
- まず「作らない範囲」を決める。私たちは会議ツールごと作ろうとして、コストで負けました。負けたおかげで、本当に必要なのは「録画」と「高精度な文字起こし」と「AI連携」だけだと分かりました。撤退は、スコープを削り込む最良の方法です
- 効率化の入口は、地味な不満でいい。「AIで何かできないか」から始めると、たいてい何も生まれません。「コストが高い」「探すのが面倒」から始めるほうが、確実に動きます
- AIには「触らせない領域」を人が宣言できるようにする。AIが人の確定した答えを上書きした瞬間、そのツールは信用を失います。上書き禁止と完全ロックは、精度改善より優先度が高い場合があります
- AIに、必ず根拠を言わせる。「どの発言をもとにそう書いたか」が見えるだけで、確認のコストは劇的に下がります。説明できないAIは、結局すべてを人が読み直すことになります
- やらないことを、仕組みで強制する。「溜めない」「1件だけ」といった判断は、運用ルールではなく構造上の制約で守る
- 仕様書は必ずズレる。ズレたら、実態のほうを正しいと考える。守るべきなのは仕様書ではなく目的です
この6つは、会議に限った話ではありません。どの業務をAIに任せるときにも、そのまま当てはまります。
よくある質問
結局、AI議事録ツールとは何が違うのですか？
目的が違います。AI議事録ツールのゴールは「読める議事録が残ること」ですが、GrowMeetのゴールは「決まった項目が、正しく埋まっていること」です。中心にあるのはヒアリングシートの自動記入で、議事録は主役ではありません。設計仕様書に「議事録」という語が一度も出てこないのは、その表れです。
Web会議ツールを乗り換える必要はありますか？
ありません。GrowMeetはWeb会議の機能そのものを持たない設計で、既存のZoom・Google Meet・Microsoft Teamsの会議に相乗りして記録を取ります。会議のやり方を変えずに、会議のあとだけを変える。これは思想というより、会議ツールを自作しようとして断念した結果として決まった設計です。
会議の内容は、どこに保存されるのですか？
文字起こしは会議中はブラウザの中だけで保持し、データベースには溜めません。会議後にファイルとして保存し、共有場所へ転送できたら削除します。要約も同様にデータベースには残しません。1つの会議に対してファイルは1つだけと決めており、これは運用ルールではなくデータベース側の制約として構造的に強制しています。
AIが間違ったことを書いたら、どうなりますか？
人が直せば、その項目は「確定」になり、AIは二度と上書きしません。それでも触られたくない項目には「ロック」を宣言でき、AIの処理対象から完全に外れます。加えて、AIが埋めた項目には根拠となる発言と確信度が表示されるので、どこを疑うべきかがすぐ分かります。
日本語の文字起こしの精度は、どのくらいですか？
正直に申し上げると、まだ満足していません。字幕が英語で出てしまう問題を、後段で日本語へ翻訳することで回避しており、二重の変換を経るぶん、日本語としての自然さに課題が残ります。この領域は、内製で会議の効率化に取り組むときの最大の難所です。ここは今も改善を続けています。
GrowMeetを導入することはできますか？
できません。社内専用ツールとして作っており、販売していません。ただし、この記事に書いた考え方──やらないことを先に決める、AIに触らせない領域を人が宣言できるようにする、根拠を必ず言わせる──は、御社の業務にそのまま移せます。私たちはその設計と実装を、業務のDXとしてご一緒しています。
内製と既製ツールの導入、どちらがいいですか？
私たちの経験から言えば、「全部作る」と「全部買う」の間に答えがあります。私たちは会議ツールごと内製しようとして断念し、既存の会議ツールに乗ったうえで、自社の業務にしかない部分だけを作りました。どこまでを既製品に任せ、どこからを自分たちで持つか──その線引きこそが設計です。まずはその線引きから、ご相談ください。
まとめ：作ろうとして、やめた。残ったものが答えだった
この社内DXは、Web会議ツールそのものを内製しようとして、コストに負けて撤退したところから始まりました。撤退したおかげで、本当に必要なものが3つだけだと分かりました。録画が確実に残ること。高精度なリアルタイムの文字起こしがあること。そしてそれをAIにつなげること。会議の場は作らない。会議の記録とAI連携だけを持つ。設計の背骨は、思想ではなく失敗から決まりました。
作ってから分かったことも、同じくらい重要でした。会議の効率化における本当の難所は、AIの性能ではありません。ひとつは日本語の文字起こしという、地味で、いまだ根本解決していない技術課題。もうひとつは「AIを信用してもらう」という設計課題です。後者への私たちの答えが、「これ以上AIで変えるな」と人が宣言できることと、根拠の表示でした。
そして最も大きかった成果は、浮いた時間ではありませんでした。会議ツールが他の業務システムへデータを供給する基盤になり、社内のAI基盤とつながった──会議が、他の仕事の入力源に変わったことのほうが、ずっと効いています。
GrowGroupは、この記事に書いたことを自社の業務で一つずつ実際にやってきた会社です。作るのをやめる判断も、AIに信用を取り戻させる設計も、全部自分たちで経験しています。だからこそ、御社の業務でもどこから手をつけ、どこで立ち止まるべきかを、具体的にお話しできます。
「会議の記録に時間を取られている」「AIを入れてみたが、現場が信用してくれない」「どこまで作って、どこから買うべきか分からない」──そうした課題があれば、ぜひ一度ご相談ください。同じ発想で、御社の業務も効率化できます。現状をお聞きしたうえで、御社に合わせた進め方を無料でご提案します。ご相談・お見積りはこちら
