はじめに
こちらは エーピーコミュニケーションズ Advent Calendar 2025 12日目の記事です！
今回は社内でのナレッジ共有について考えたこととして、前編の構想編としての記事になります！
ナレッジ共有について再考してみる
今年はナレッジ共有について考える機会が何度かあった年でした。
チーム内での共有ツールを作ってみたり、実際の活用として活発にしていくにはどうしたら良いかということを考えたりしたため、アドベントカレンダーを機に言語化してみることにしました。
理想像
まずは理想的な状態を考えてみます。
理想的な状態とは、「人が意識せずに知識が回る状態」 だと考えます。
コストや手間をいくらでもかけられるのであれば理想的なものはできると思いますが、現実問題そんな環境は世界中のどこを探してもおそらく見つかることはありません。
「利用者が困ったときにちゃんと利用ができる」という状態が最終的な目的になると思います。
副次的に今まで時間を設けて共有していた時間を削減できるような面もあると思います。
また、ツールを入れ替えることがゴールではなく、ナレッジ共有とは何をするものなのかという点を改めて考えみます。
特定のシステムや担当者に依存せず、業務の中で自然と知識が蓄積・再利用される状態になるだろうが、業務フローの見直しから必要になるため、正直なところ、その様な環境を構築するのは容易ではないと感じました。
誰かが意図的に"共有する"のではなく、日々の業務行動そのものが知識化される。
情報が自然に流れ、必要なときに自動的に手元に現れる。
これが理想的で最終的な状況であると考えました。
特徴
| 観点 | 理想的な状態 |
|---|---|
| 入力 | ドキュメントや報告書が自動的に共有対象として吸収される |
| 検索 | 「どこにあるか」を意識せずに内容で検索できる |
| 活用 | AIや要約機能によって、理解・再利用が容易になる |
| 更新 | 利用履歴がフィードバックされ、情報が自然にメンテナンスされる |
構造イメージ
社内環境とコスト面を考慮した導入設計
なぜNotebookLMなのか
そうは言っても、理想的な環境を作れるほどのコストも時間もないため、いったんは個人開発の範囲としてPoC環境の様なものを作成しようという算段です。
今回の取り組みは小さなところからと個人的にチーム内での共有用に始めた実験です。
まずは小さく試してみるという現実的なアプローチを選んでみました。効果が見えれば自然と広がるだろうし、失敗しても影響範囲は限定的です。
組織的な背景を考えた際の制約などをいったん排除すべく、Googleアカウントの範囲だけで試行錯誤でき、追加コストが発生しないNotebookLMを選択しました。
個人検証から始め、効果が見えてからチームなど組織的に利用できたら良いと考えています。
データソースの選定
初期フェーズでは、社外向けの公開技術記事と、既存のナレッジ共有ツールで蓄積されたスプレッドシートに限定することを前提としました。
ナレッジ共有ツールはフロントエンドのフォーマットに沿って入力すると、単純に内容をスプレッドシートに登録するだけの仕組みとなっており、今回はそれをそのまま活用できるものとしました。
新たにデータを集める必要がなく、既存資産を有効活用できるのは大きなメリットです。
- 権限調整の回避：公開済みの技術記事と、既にチーム内で共有されているスプレッドシートだけを扱うことで、余計な権限調整の手間などが不要となること
- インフラコストの最小化：公開技術記事ははてなブログのAPI経由で取得可能
- 既存資産の活用：以前開発したナレッジツールで蓄積されたスプレッドシートをそのまま利用できる
公開情報と既存資産だけでどこまで実現できるかを確認することで、理想的な状態に近い人が手をいれる時間を取らなくても動作するような環境を目指してみます。
データ投入の方針
初期段階として、収集したデータをそのままNotebookLMに投入することから始めました。
カテゴリ分けや重み付けなどの細かい調整は行わず、まずは全データを突っ込んで実際に使ってみることを優先しています。実際の利用状況や回答の傾向を見てから、必要に応じて調整を検討する方針です。
期待できる効果
現状ライトな環境して考えられる期待できる効果が以下になりますが、汎用的だったり一般的な質問であればLLMと同じじゃない？LLMの方が早くない？という気もするので、そこの兼ね合いが難しい気もしてきます。
- 既存知識が再利用される：埋もれた記事やシートの情報が「AIによる要約」として蘇る
- 検索の入口が変わる：「探す」ではなく「聞く」という自然言語のアプローチが広がる
- 管理工数が減る：AI要約がメンテナンスを補助し、人の介入を最小化する
まとめ
理想としては「知識が追加での負担がなく、自動で溜まること」と定義してみました。
そうはいってもそこまで作ることはコスト的にも難しそうであるため、現実的な第一歩は、「NotebookLMで知識の流れを再び動かす」ことです。
ツールを入れ替えること自体が目的ではなく、利用者が必要なときに便利に利用できる状態をどう設計するかを忘れなければ、ナレッジ共有という命題は少しずつ良くなるはずだと感じました。
次回予告
後編の実践編では、この考えをもとに実際に構築した内容を紹介します。
- データ収集の自動化：GASとSlack Botを使った具体的な実装
- NotebookLMへの投入：約2000件の記事とスプレッドシートをどう扱ったか
- 実際に使って分かったこと：利点と限界、新機能の活用可能性
想定通りに動いたのか、実践を通じて見えてきた課題と改善の方向性をまとめます。