生成AI上級者だけじゃないチームで、ナレッジ活用はどう設計するか？
生成AI活用の事例を読むと、決まって「Skillを自作できるメンバーが揃っている」チームの話が出てきます。でも、実際のチームがそうとは限りません。
- 「全員が上級者」を前提にした設計が壊れる理由
- 有機的に変わる層と、構造化された層を分けるという解決策
- この分離の本質は「Google Drive」そのものではない
- 実装手段をどんな基準で選べばいいか
「全員が上級者」を前提にした設計は、なぜ壊れるのか
これまでの記事で紹介してきたプロジェクトのチームは、講師の方と、情報管理や補助業務を担当するスタッフの方という構成でした。Notionのデータベースを直接いじったり、Claude Skillsを組んだりする役割は、あくまで運用担当が引き受けています。
あたま最初、講師の方にも新しいシステム側の操作を少し覚えてもらう案を検討しました。でも、そこで立ち止まって考え直しました。
講師の方の日常業務は、これまでもこれからも、Google Driveでの資料の編集や差し替えです。ここに「Notionでの入力方法」や「Skillの使い方」を新しく覚えてもらう前提を置くと、講師の方の負担が増えるだけでなく、講義準備という本来の仕事から意識がそれてしまいます。生成AI活用の設計を「全員がシステムを直接操作できるようになる」ことを前提に組むと、こうしたメンバーがボトルネックになりました。
チーム全員を「システムを扱える人」に育てようとするのは、一見丁寧に見えて、実は最も労力のかかる解決策です。育成が終わるまでシステムは機能せず、育成が終わった後もメンバーの入れ替わりのたびに同じコストがかかります。
有機的に変わる層と、構造化された層を分ける
そこで採った設計判断が、講師の方が普段どおりに更新し続ける資料の置き場（このプロジェクトではGoogle Drive）と、NotionとClaude Skillsで構成された構造化システム本体を、意図的に分離することでした。
講師の方から見ると、やっていることは以前と何も変わりません。Google Drive上のファイルを開き、内容を編集し、必要なら差し替える。それだけです。構造化システム側が、その更新をこちらから取りに行く形にしています。
変化を吸収する役目を、人ではなく境界に持たせたのがこの設計の要点です。講師の方に新しい操作を覚えてもらう代わりに、システム側が講師の方の既存のワークフローに合わせにいきました。
以前の記事で、複数の生成AIサービスのうち、検索や参照の公式な経路を持たないものを「入力側専用」という非対称な役割に位置づけた話を紹介しました。この発想は、AIツール同士の役割分担だけでなく、人やチームの役割分担にもそのまま当てはまります。能力や関わり方に差があるメンバーを無理に均そうとするより、それぞれの立ち位置に合わせて役割を割り振るほうが、たいてい負担が小さく済みます。
この分離の本質は「Google Drive」そのものではない
ここまでの説明だけを読むと、「非技術者にはGoogle Driveを使わせておけばいい」という話に聞こえるかもしれません。ただ、それはこの設計判断の中心ではありません。
あたまもしこのチームが全員生成AIの扱いに慣れた上級者だったとしても、講師の方が講義内容を有機的に更新し続けるという性質そのものは変わらなかったはずです。だとすれば、似たような分離の構造はやはり必要だっただろうと思います。
つまり、答えは「Google Driveを使うこと」ではなく、「有機的に更新され続ける層と、検証や蓄積、自動化を担う構造化された層を分けること」のほうにあります。Google Driveは、このチームがもともと使い慣れていたからこそ選ばれた、実装上の一つの手段にすぎません。チームの構成が違えば、GitHubでの管理やSlackでのやり取りが同じ役割を担っていた可能性も十分にあります。
この記事の核心は、「非技術者にはGoogle Driveを与えよ」という個別の処方箋ではありません。有機的に変わり続ける部分と、構造として固めたい部分を先に見分け、両者の境界をどのツールに担わせるかを、チームがすでに持っている習慣に合わせて決める、という考え方そのものです。
実装手段をどんな基準で選べばいいか
この分離を実装する手段そのものに、唯一の正解はありません。判断基準になるのは、そのチームが今すでに使い慣れているツールがどれか、という一点です。
前々回の記事で、情報格納のハブにNotionを選んだ理由として「管理者がすでに使い慣れていること」を挙げました。同じ発想が、有機的な層の側にもそのまま適用できます。新しいツールを覚えてもらうコストと、既存のツールをそのまま使い続けてもらえる利点を比べたとき、後者が上回る場面のほうが、実務では圧倒的に多いというのが実感です。
逆に言えば、「このツールが優れているから」という理由だけで有機的な層の手段を選ぶと、そのツールに不慣れなメンバーの負担が増え、結局は運用が続かなくなります。優劣より、チームの現在地に合っているかどうかを優先する判断です。
まとめ
生成AI活用の設計を「全員が上級者になる」ことを前提に組むと、技術者ではないメンバーがボトルネックになります。この記事で紹介した分離は、有機的に更新され続ける層と、構造化された層を分け、変化を吸収する役目を人ではなく境界に持たせるという考え方でした。実装の手段（このプロジェクトではGoogle Drive）はチームが元々使い慣れているツールに合わせて決めればよく、そこに唯一の正解はありません。
次回は、当初は別の生成AIサービスを前提にしていた設計を、実際には方針転換することになった経緯を紹介します。
関連記事
コメント