はじめに
Ubieでデータエンジニアをやっている @yosh_yumyum です。
普段はBigQueryやdbtを使ったデータ分析基盤の構築・運用が業務の中心ですが、今回はデータといっても社内WikiやNotionにあるようなドキュメント（非構造データ）のデータ整備と利活用を目指した取り組みを紹介します。
本記事を通じて、以下の様な知見を得られるかと思います。
- 議事録やSlackでの会話など、社内に点在する多様なデータを組織的に整備するためのアプローチ
- ワークフロー構築および自動化ツールの利活用による非構造化データの利活用手法
- 生成AIやchat botを組み合わせたナレッジ活用の具体的な事例
データ平定プロジェクト：継続的な利活用のために
データエンジニアリングの世界には"Garbage In Garbage Out"という言葉がある通り、上流のデータの整備なくしては示唆のある分析や良質なアウトプットを継続的に得ることは難しいです。
社内のナレッジ活用でこの考えを当てはめてみると、生成AIを使って議事録など文書を作成する、その文書を生成AIに読ませて開発に役立てる、といったようにナレッジを循環させる取り組みは今や多くの開発チームや組織で行われていると思います。
しかし、陳腐化した社内ドキュメントを参照したり、特定のチャネルのみから情報の取得ができないとなると、組織・チームの"今"を"正しく"知ることは難しく、ナレッジの循環が継続的に機能しているとは言えません。
特に、変化の早さと正しい方向付けが強く求められるUbieでは、ナレッジの循環停滞に伴い人力で詳しい調査をしたり、コミュケーションコストが増加するとなるとクリティカルな問題となり得ます。
そこでUbieでは、個別のデータ活用事例を創出するだけではなく、全社の生産性を継続的に向上することを目的として、社内データマネジメント基盤構築プロジェクト（社内での通称：データ平定プロジェクト）が発足しました。
プロジェクト初期から描いていた理想図。AIに依頼すれば最新の正しいナレッジが簡単に得られる体験を求め続けました
人とAIがアクセス可能なSSoT
データ整備の第一歩としてデータ平定プロジェクトでは、ドキュメントベースであるNotionをAI Readyなデータソースへと改善することから始めました。
NotionがAIにとって良質なSSoTとして機能するように、データ整備ガイドラインを作成し全社にアナウンスするとともに、現行のドキュメントの移行作業を実施しました。
データ整備ガイドライン
データ整備ガイドラインの鍵となる考え方を抜粋すると、以下のようになっています。
- ページの置き場所の制限（原則Notion DB配下にページを作成する、など）
- Notionのページ作成の自由度を制限（MCP toolでのアクセスがしやすいように、ネストの深いページ構造を避ける、など）
- 一部プロパティ（＝メタデータ）の入力必須化
- フロー情報・ストック情報の区別
- アクセス権限の再設計
社員が広く利用しているということもあり、方針についての議論があったり個別の利用例に対する移行サポート工数も要しましたが、質疑・サポート体制を整え粘り強く伴走しながら移行を進めています。
フロー情報転送の自動化（ナレッジの共同化、表出化)
そうしてデータ整備ガイドラインを施行しつつ、次はフロー情報の整備に取り掛かりました。
活用余地のあるフロー情報として、議事録や商談ログがあります。
UbieではGoogle Meetをオンライン会議の標準ツールとしていることもあり、議事録はGoogle MeetでのGeminiの要約・文字起こしを使えば入手できますが、下記のような課題がありました。
- 生成された議事録・文字起こしは会議の主催者のマイドライブに保存され、そのままだと社内に広くアクセスさせることが難しい
- Geminiの要約ではなく、社内で利用される議事録フォーマットに整形し直したい
- 社内のドキュメントベースであるNotionやSlackからアクセスできないと、人間にもAIにも扱いづらい
このままではAIにとってアクセス可能な情報とは言いづらいです。
議事録転送の自動化と、標準サマリの蓄積
1つ目のアクセス権限の問題に対しては、マイドライブから社内の共有ドライブへ定期転送するGASを作成しました。こうすることで、会議に参加していない人、そしてUbieの生成AI アプリケーション "Dev Genius"が文字起こしにアクセス可能になります。
会議によっては機微情報を扱うこともあるので、除外設定などのオプションを用意した上で設定をお願いしています。
2つ目および3つ目の問題に対しては、ZapierとGeminiを駆使し共有ドライブに配置された文字起こしを再度要約しNotion DBに蓄積させることで、皆にとってアクセスしやすく読みやすい形式で議事録を蓄積することができました。
仕組みとしては、下記の流れになっています。
- マイドライブから共有ドライブへの転送を行うGASを定期実行
- 共有ドライブへ転送された、というイベントをZapierで検知
- 事前に登録したシステムプロンプトと、Google Docs APIから取得した議事録のdocument bodyを入力として、Gemini(社内のGoogle Cloud Projectで用意)で要約させる
Google Meet文字起こしの転送自動化フロー
商談ログの転送自動化
Ubieではオンライン会議のほぼ全てがGoogle Meetで行われているため、社内の議事録については前述の仕組みで収集することができます。
議事録に加え、もう一つ価値のあるフロー情報として商談ログがあります。中でも、商談によってはオフラインで実施することもあり、前述の仕組みだと収集が困難なことも多々あります。
そこで、UbieではAIボイスレコーダーであるPLAUDを導入しました。
ボタン一つで録音ができ、簡単に文字起こし・要約できることから、営業職中心に活用されており体験としてはかなり良いと評判です。
PLAUD利用者の声
現時点では、PLAUD単体では文字起こしデータをPLAUD外へエクスポートすることは難しいため、Zapierを利用し、Notion DBまで転送しています。
PLAUD文字起こしの転送・利活用フロー
現時点では個別にZapを作成する必要があり管理が煩雑になるという課題はありますが、上図のようなカスタマイズがZapierでは可能なので、多様なニーズに対して柔軟性が高いので重宝しています。
PLAUDのアプリを見る限りだと、今後はNotionやGoogleカレンダーとの連携機能も予定されているようなので、今後はZapier側での管理コストが下がるようなデータ連携を期待したいところです。
なおデータアクセス観点から、商談ログは関係者のみが閲覧できるようアクセス制限を徹底したい場合もあるので下記のようにSlackでのRequest Approvalを必須にしているケースもあります。
承認フロー付きZapierを使い議事録を転送している例
議事録・商談ログの活用(ナレッジの連結化)
こうしてNotionに蓄積された議事録・商談ログですが、単に人間が読みに行くのではなくAIを介して透過的にナレッジを収集できることが重要です。人がドキュメントの場所を意識するのではなく、プロンプト一つでAIが情報検索する、というAgenticな体験こそが生成AI時代の業務効率化の鍵となるでしょう。
Ubieの生成AI アプリケーション "Dev Genius" ではSlack経由での呼び出しも可能であり、誰もが簡単にchat bot（社内ではAIP: AI Partnerと呼んでいます）を作ることが可能です。
こうして作られたAIPは、今や業務効率化の上で欠かせない存在となっています。
そこで、データ平定プロジェクトでもフロー情報利活用の第一歩として議事録・商談ログを検索するchat bot(AIP)を作成しました。
@mtg_search を呼び出せば、前述のデータ整備ガイドラインで標準DBとして定めたNotion DBを検索し、蓄積された議事録を検索してくれます。
議事録検索chat botの使用例. 天体観測（OKRの進捗共有会）というキーワードと、日付で検索している
議事録検索AI Partnerのシステムプロンプトの一部。使用ツールや検索プロセスを指示している
1枚目のスクリーンショットに、「使用したツール」とありますがこのchat botは内部的にはMCP toolを呼び出しており、2つ目のNotion MCPはUbieでカスタマイズしたNotion用MCP toolとなっています。
汎用的なMCP toolでもプロンプトの工夫次第では適切に検索をしてくれることもありますが、コンテキストエンジニアリングの考えの元、専用のMCP toolを用意しています。
Ubieでのコンテキストエンジニアリングについてはこちら：
データ平定プロジェクトではコンテキストエンジニアリングの考えに基づき社内データ基盤を設計しています。議事録の利活用に限ってもそのエッセンスは随所に現れています：
- データ整備ガイドラインによる、AIが読みやすいコンテキストの整備・分離（=読みやすいデータソース）
- 専用MCP toolやAI Agentの責務デザインによる、コンテキスト取捨選択（=要求に応じたツール選択）
- Geminiを使い社内議事録フォーマットへ変換することで、不要コンテキストの除去（=不要トークンの削除、Agentの応答の安定性向上）
余談ですが、3つ目社内議事録フォーマットへの変換ではなくフィラーワードの除去や音声入力による表記揺れのみを修正し、なるべく音声入力のまま提供しようと試みたこともありました。
しかし、議事録の長さによってはoutput tokenの制限に引っかかってしまうことや、AIから呼び出した場合に抽出できる情報の精度が生の音声入力とあまり変わらないと判断したため、要約を提供しつつ元のGoogle Driveへのリンクを貼る、という方法に落ち着きました。
この辺りは今後のLLMの発展によって解決する面はあるとは思いつつ現時点ではプロンプトやコンテキストの工夫で乗り切っています。
メタデータの付与とストック情報化への試み（ナレッジの内面化から再び共同化へ）
蓄積された議事録・商談ログをAIから検索しやすくなったのは大きな一歩です。
しかしSECIモデルの考えに基づくと、広くアクセス可能になったデータを個々人が使うだけでなく重要な知見は集合知としてもストックしていくことが継続的なデータ利活用の鍵となります。
ストック化のアプローチとしては、まずストック情報が抽出できそうなフロー情報にタグ付けを行いタグ別に集計し、最終的に生成AIを活用してストック情報化する、という流れが考えられます。
Ubieでは、フィルタのしやすさや可用性を考慮の上、タグは"Select(Multi-select)"ではなく、RelationとしてタグDBを作成し社内で広く使われています。
全てのページに人力でタグ付けするのは非現実的であり、またRelation PropertyはNotion AIで自動生成することは現状不可能なため、Geminiでタグを生成＆Notion APIでタグ付けを実施しました。
こうしてタグづけされたデータに対し、集計ロジックを内包した別のAIP(chat bot)を呼び出す、呼び出した結果をナレッジストック用のNotionのDBに蓄積し直す、といった形でナレッジの循環が期待できます。
データ平定チームでは全社横断で利用する標準的なタグ（関連OKRなど）を用意しましたが、この仕組みを公開したところ早速ユーザーから特定の商談・特定の事業に特化したタグを用意したいという声もいただけました。
仕組みを作るだけでなく、仕組みによってどのような社内のユーザー（データ平定チームにとっての、顧客）の課題解決に寄与できるか、を念頭に絶えずユーザーからのFBやインタビューを行い今もストック情報化・データ平定に励んでいます。
タグ付けしたNotionページ一覧. これだけでも社内でどんなことが起きてるのか一覧できる
蓄積した議事録をもとにしてOKRの進捗状況（天体観測）をストック化
今後の展望：ナレッジ循環の質を高め、AIが業務に溶け込む未来へ
今回紹介した取り組みでは、誰もが本来の創造的な業務に集中できる環境を目指すために、地道なデータ整備とそれを土台にした自動化の仕組みを社内ユーザーのフィードバックを絶えず受けながら一つ一つ積み上げて実現していきました。
その結果、数ヶ月でナレッジの抽出からストック情報化までの一連の流れを構築できました。今後はこのナレッジ循環の「質」をさらに高め、組織全体の生産性をもう一段階引き上げることを目指していきます。
具体的には、以下がポイントになっていくと考えています。
- AIP(chat bot)の高度化:コンテキストエンジニアリングによるAIP(chat bot)の応答精度向上や負荷軽減
- 業務プロセスへの統合: AIPを単なる「便利なチャットボット」から、特定の業務フローに不可欠な「必須コンポーネント」さらには「チームメイト」へと昇華
- 全社的な活用事例の創出と文化醸成: 現在の議事録活用に留まらず、営業、開発に特化したナレッジ循環の仕組みの構築
この記事が同じような課題を抱える方々にとってのヒントとなれば幸いです。
Discussion