学習の目標
- 共有ノートブックについてオーナー／サブオーナー／レビュー者／閲覧者の役割を一文規約にできる。
- 命名・ソース追加・削除・棚卸しの週次ルールをテンプレ化できる。
- 新メンバー向け3分オンボード（アクセス取得→README→テスト質問）を説明できる。
前提条件
- 情報分類ラベル（公開／社内／秘密等）のたたき台がある。
- プロジェクト用のDriveまたはファイル置き場がある。
- ゲスト招待ポリシーが情報システムまたは法務と整合している。
キーコンセプト
- Accountableは1人: 複数ボスは意思決定が遅れる。
- ソースの鮮度: 外部URLは変化する。固定版PDF化やスナップショット方針。
- 最小権限: 余計なメンバーを常時Joinさせない。
- ライフサイクル: 進行→読取→アーカイブ→削除の4段。
手順（実践ステップ）
- RACI表: 4ロール以上でもよいが、Aは1名に固定。
- 命名規約: 英数字案件コード＋論点＋日付。絵文字は検索で事故りやすい。
- キックオフ1枚: 正本URL、禁止事項、よく使うプロンプト、緊急連絡。
- 週次5分: 新規ソースの重複・権限・版の監査。
- 月次: 僵尸ノートブック一覧を出し、オーナーに削除 or アーカイブを依頼。
- クローズ: 成果をDocs化し、NotebookLM側は読み取り専用→期限後削除。
- オンボード: アカウント発行→README読了証跡→テスト質問1本の実演。
演習課題
- 架空PJでRACIと命名例を1枚。実在PJなら削除候補ソース3件と理由。
- READMEを新卒向けに読み、わからなかった用語を1つ追記せよ。
自己チェックリスト
- [ ] オーナー名がドキュメントされた
- [ ] 禁止データリストが更新された
- [ ] 週次監査のカレンダー入りした
- [ ] 終了時アーカイブ手順がLink集にある
- [ ] ゲスト招待ログを残す運用
- [ ] APIキーや個人メモが混ざっていない
- [ ] バックアップ方針とNotebookLMの関係が説明できる
つまずきポイント（避けたい落とし穴）
- 名無し共有: ゴミソースだらけ。
- 個人Gmail依存: 退職で蒸発。
- 規約の形骸化: テンプレを毎回コピペし改訂日を残す。
まとめ
チームではツールより誰が責任を負い、いつ手を放すかが成功要因です。短い規約と週次5分が、長期の品質を支えます。
振り返りの問い（任意）
- オーナー不在のノートブックはないか。
- 外部メンバーが見てよいソースだけになっているか。
- 3ヶ月触っていないノートブックをどうするか決まっているか。
ミニレクチャー（20分）
立ち上げ初日にやるのは、A4半ページの「NotebookLMチャーター」だけでよい。記載項目は、オーナー、バックアップオーナー、招待ルール、禁止データ、命名接尾辞、終了時フロー。週次5分ミーティングでは、新規ソース3件だけをサムネイルレビューし、明らかにノイズなら即削除。月次で「90日無操作」ノートブックをリストアップし、オーナーにContinue or Killを迫る。個人Gmailでの実務利用を禁じ、Workspaceアカウントへ寄せる。最後に、新人ハンズオンはテスト用ダミーノートブックで実施し、本番データを見せない。
監査ログが必要な業界では、「いつ誰がどのソースを追加したか」をDrive側のファイル更新履歴と突き合わせる手順をチャーターに書く。ソースの外部URLが失効したらノートブック内に失効日メモを残し、代替PDFをDriveへ。複数部門共有時は部門コードを接頭辞に入れた命名で衝突を避ける。
ツール・参考リンク
権利表記
NotebookLMは各社の商標または登録商標です。本記事は公式提供ではなく、一般的な情報提供を目的としています。
画像クレジット
サムネイル画像はUnsplashのライセンスに基づき使用しています。
お問い合わせ
AIツールの導入・活用支援のご相談はお気軽にどうぞ
📞 090-6262-3842