1500人の現場を支える：Notion RAG構築の技術的深淵

ラブグラフという、1500人ものカメラマンが全国で躍動する組織において、社内Notionが「情報の墓場」と化すのは、ある種、成長に伴う必然的なデッドロックだ。業務の多様化はドキュメントの肥大化を招き、検索性は低下し、結果として現場のカメラマンは必要な情報に辿り着くために貴重な時間を浪費する。この「情報の非対称性」こそが、我々エンジニアが真っ先に解決すべきボトルネックである。今回、morii氏が取り組んだのは、単なるチャットボットの導入ではない。毎日Notionと同期し、画像内の要素すらも検索対象に含めるという、極めて実戦的なQAエージェントの構築だ。

特筆すべきは、LLMのトレンドであるEmbedding（ベクトル検索）をあえて採用せず、古典的かつ堅牢なBM25を採用した点にある。これは非常に鋭い技術的判断だ。ベクトル検索は意味的な類似性には強いが、社内用語や特定の固有名詞が飛び交うドキュメント群においては、BM25のようなキーワードベースの検索の方が、エンジニアの直感に近く、かつデバッグも容易である。さらに、画像内の要素をVLM（Vision Language Model）で解析し、テキストとして索引化するアプローチは、ドキュメントの「視覚的情報」をナレッジとして昇華させるための極めて有効な一手だ。このシステムは、月間約1600件の質問を5秒程度で捌き、8割以上の回答精度を誇る。これは、単なるプロトタイプではなく、現場のワークフローに深く根を下ろした「プロダクト」として完成されていることを意味する。

エンジニアが最も恐れるのは、AIエージェントを導入した結果、API利用料が青天井に膨れ上がり、経営層から「コスト削減」という名の無限ループに追い込まれることだ。本プロジェクトでは、Gemini 3.5 Flash-Liteを軸に、Google Cloudのサーバーレス環境を徹底的に活用することで、この懸念を払拭している。特に、Cloud Runを「インスタンス数0」で運用し、常時稼働サーバーを持たない設計は、スタートアップや中規模組織にとっての最適解と言える。また、LLMのトークン消費を抑えるための「目次常駐方式」や、SHA-256を用いた画像解析のキャッシュ戦略など、細部に至るまでコスト意識が徹底されている。

以下に、実環境でのコスト試算の構造を示す。この数値は、単なる見積もりではなく、実測に基づいた「エンジニアの防衛線」である。

このアーキテクチャにおいて、ページ数が1000を超えると目次常駐の固定費が重くなり、2000を超えると日次クロールのJob費用が支配的になるという「スケールの壁」が明確に定義されている。これは、システムが成長した際にどこをリファクタリングすべきかというロードマップを、最初から設計図に組み込んでいることを意味する。我々エンジニアは、AIを魔法の杖として扱うのではなく、このように「コストと性能のトレードオフ」を数学的に制御する姿勢こそが求められているのだ。

この事例が我々に突きつけるのは、「AIをどう使うか」という問い以上に、「AIが前提となった環境で、エンジニアは何を担保すべきか」という本質的な課題だ。morii氏の実装プロンプトには、単体テストで実LLMを呼ばないための依存注入や、ログのNDJSON出力、Terraformによるインフラ管理など、モダンなエンジニアリングの作法が凝縮されている。AIエージェントは、もはや「実験的なスクリプト」ではなく、堅牢なソフトウェア開発の対象である。もしあなたが、明日から社内QAエージェントを構築しようとしているなら、まずは「検索の精度」よりも「検索の根拠（引用）」をどうモデルに守らせるか、そして「回答できない場合にどう誠実に逃げるか」という設計に時間を割くべきだ。

最後に、読者であるあなたに問いたい。あなたの組織にあるドキュメントは、AIが読み解く準備ができているだろうか？ 構造化されていないMarkdownや、画像の中に埋もれた重要な意思決定プロセスを放置したまま、AIエージェントを導入しても、それは「ゴミを高速に検索する機械」を作るだけに過ぎない。AIエージェントの性能は、入力されるデータの質に依存する。明日からあなたが取るべきアクションは、コードを書くことではない。まずは、社内のドキュメントを「機械が理解可能な形式」へと整理し、情報のライフサイクルを定義することだ。AIはエンジニアの仕事を奪うのではない。AIを使いこなすために、エンジニアが「情報の整理屋」としての本分を全うすることを求めているのだ。この技術的負債を解消する覚悟が、あなたにはあるだろうか？