はじめに
こちらは エーピーコミュニケーションズ Advent Calendar 2025 11日目の記事です。
2024年後半〜2025年頭にかけて、チーム内のナレッジ共有用に基盤を作りました。
最初は AWS S3 上の SPA として実装してしばらく運用していましたが、2025年春頃に GAS ＋ スプレッドシート構成に移行することとなりました。
背景
それまでは、ナレッジ共有はほぼ Slack でしたが、いくつかの課題を感じていました。
「情報が時系列に流れていき、後から探しにくい」、「チャット形式なので、まとまった内容を読むには見づらい」などです。
「Slack だけでは足りないが、いきなり重いドキュメント運用にはしたくない」という前提で、
軽めのナレッジ共有できる仕組みを検討してみることにしました。
最初は S3&SPA、その後 GAS に移行した理由
最初は技術検証も兼ねていたので 、遊び半分でAmazon S3 にホスティングした SPA サイトとして作成してみました。
静的ホスティングでコストは安くフロントエンドの自由度が高い想定だったのですが、主に認証周りのセキュリティ面で以下の様な不安と課題を覚えました。
- SPA サイトのためバックエンド認証がなく、フロントからの簡易認証だけではセキュリティ的に不安(セッションハイジャックができてしまいそう？)
- きちんとした認証を入れようとすると、結局バックエンドや認証基盤が必要になる(cognitoを用意する？)
- S3／CloudFront／認証周りなど、運用対象が増える
用途はいったん「社内の限られたメンバー向けのナレッジ共有」であるとともに、セキュリティ面の不安を抱えたままなのも嫌だったので、2025年春頃に構成を切り替えることになりました。
結論的にはパフォーマンスや自由度は劣るものの、Google Workspaceの範囲で使えて、認証は Google アカウントに任せる様な構成として、Google Apps Script（GAS）＋スプレッドシート で作り直すことができました。
基盤の構成
構成はできるだけシンプルにしています。イメージは次のとおりです。
UI から記事を Markdown で登録し、GAS 経由でスプレッドシートに保存します。
Slack 連携を使う場合は、定期的にメッセージを同期して記事と紐づけて参照します。
所感・利用感
markdownとスプレッドシートの利用価値
方針はシンプルで、「記事コンテンツは Markdown」であり「保存先は Google スプレッドシート」です。
正直そこまで考えていたわけではなかったのですが、11月ごろにNotebookLMがスプレッドシートに対応したことで、共有された情報の利用価値が高くなるものになりました。
認証機能
アプリ側に独自のログイン機能は不要で、Googleアカウントでの認証です。
スプレッドシートの共有設定で制御が可能なため、基本的社内アクセス前提としているものとしては組織グループや個人ユーザーに共有をするだけなので非常に手間がなく簡単です。
OAuth で認証アプリでない警告が表示されてしまうため、必要に応じてGoogle CloudのプロジェクトからGoogleへの審査が必要になる想定です。
Google OAuthの実装方法について
まとめ
この基盤を作ったタイミング（2024年後半〜2025年頭）では、最低限のものを作ることを想定していました。
運用をしていく上で課題的な部分も見えてきており、活用まで考えた上で作成する必要があると思いました。
RAG周りの進化も非常に早いため、構成的な面での検討余地もあると思うので継続して色々と試してみたいと思います！
NotebookLM を組み合わせたナレッジ活用の記事も準備しているのでお楽しみに！
こちらはnotehub-gasで公開しています！