見出し画像

CerebrasのKnowledge Baseから考える、個人開発に本当に必要な検索基盤

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中

複数のリポジトリを行き来しながら開発していると、同じ問題が何度も起きます。

「この仕様は、どの資料で決まったのか」
「似た実装を、別のリポジトリで作っていなかったか」
「この設定を変えた理由は、Gitの履歴にあるのか、Slackの会話にあるのか」
「Google Driveにある資料と、実装のどちらが新しいのか」

情報は存在しています。問題は、必要な瞬間に見つからないことです。

Cerebrasは、この問題に対して社内用のKnowledge Baseを構築しました。2026年7月15日に公開された技術記事によると、公開から約3か月で、社員、オートメーション、AIエージェントから一日1万5,000件を超える質問を受ける、社内でも利用の広い基盤になっています。

ここで注意したいのは、これは外部企業が契約して使う一般向けSaaSの紹介ではなく、Cerebrasが自社内に構築した仕組みだということです。また、一日1万5,000件という数字は利用規模を示しますが、回答精度、業務時間の削減、投資対効果まで証明する数字ではありません。

公開記事は設計を詳しく説明する一方、検索品質の評価値や誤答率、運用費用は十分に公開していません。

ただし、私のように一人開発が中心で、Jamsだけもう一名のエンジニアと進めている環境へ、その仕組みをそのまま持ち込むのは過剰です。

私がCerebrasの事例から持ち帰るべきなのは、大規模なベクトルデータベースではありません。

情報を一か所へ移し切るのではなく、必要な時に、適切な情報源から根拠付きで取り出すという設計思想です。

この記事では、CerebrasのKnowledge Baseがどのように作られているのかを技術的に整理しながら、MacBook Pro上の複数リポジトリ、Google Drive、限定的なSlack利用を前提に、個人・少人数開発向けのProject Context Routerへ縮約します。


一つの正本へ集める発想は、現場では続かない

社内ナレッジの問題が起きると、「すべてを一つの場所へ集めよう」という案が出ます。

考え方としては分かりやすいものの、Cerebrasはこの方法を採りませんでした。情報は、それぞれ最も扱いやすい場所で生まれるからです。

Slackでは議論が進みます。GitHubではコード、Pull Request、Commit、レビューコメントが残ります。JiraにはIssueや状態が入り、Google Docsには仕様や説明が置かれます。Pull Requestの議論をGoogle Docsで行えば不自然ですし、仕様書をGitのCommitだけで管理するのも読みにくい。

Cerebrasが選んだのは、元の道具を置き換えることではありませんでした。情報が生まれる場所は維持し、その上に共通の取得レイヤーを作る方法です。

ここで区別したいのが、Single Source of TruthとSingle Retrieval Layerです。

Single Source of Truthは、正しい情報を一つの場所に集約する発想です。一方、Single Retrieval Layerは、正本が複数の場所に残ることを認めたうえで、質問に応じて必要な情報を横断取得する仕組みです。

私の環境でも、コードの正本はリポジトリにあります。契約や正式資料はGoogle Driveにあります。仕様変更の背景や未解決事項はSlackに残ることがあります。これらを無理に一つへ移すより、情報源ごとの役割を保った方が現実的です。

この論点は、長期案件の背景、正式資料、判断履歴を会話履歴から切り離して管理する方法ともつながります。

強いKnowledge Baseは、検索画面だけでは成立しない

Cerebrasの設計を役割で整理すると、大きく三つに分けられます。

一つ目は、社内の情報を収集し、検索できる状態に変換する層です。

二つ目は、質問に応じて情報を検索し、回答へまとめる層です。

三つ目は、認証、認可、監査、利用分析を担う層です。社内情報を扱う以上、検索性能だけでは足りません。誰が何を見られるか、どの情報へアクセスしたかを管理する必要があります。

中核にはPostgresがあり、Embedding、要約、メタデータなどを共通の形で扱います。ただし、Postgresがすべての業務データを置き換えるわけではありません。Slack、コード、文書、独自データベースの情報を、同じ検索インターフェースから扱える形へ揃える、検索用の接続拠点に近い役割です。

各データソースは、「何の情報か」「どう接続するか」「どの頻度で取得するか」を定義します。Slackスレッドでも、コード断片でも、独自データベースでも、共通の形で検索可能な行を出力すれば、残りの検索基盤は同じ仕組みを使えます。

この単純な共通インターフェースが、データソースを増やしても全体を壊しにくい理由です。

Slackはメッセージではなく、会話の意味を検索する

Cerebrasで最も重要だった情報源はSlackでした。最新の技術議論が集まる一方、そのまま検索するには扱いにくいからです。

短い相づちと、詳細な技術説明が同じ「一件のメッセージ」です。短文はEmbeddingの類似度で上位に出やすく、発言の意味は前後の会話に依存します。古い回答が現在のインフラに合わないこともあります。

そのため、Cerebrasは一つの検索方式へ依存しません。

完全一致に強い全文検索は、エラー文字列、設定フラグ、ホスト名のような正確な文字列を拾います。

Embedding検索、つまり文章の意味を数値化して近い内容を探す方法は、「restore hangs」と「checkpoint stalls」のように語彙が異なる同じ問題を結びつけます。

逆文書頻度は、珍しい設定名を含む短い発言を、一般的な相づちより高く評価します。時間減衰は、同程度に関連する回答なら新しいスレッドを優先します。

これらの順位は、後で統合されます。単一のスコアを絶対視しない設計です。

Slackの収集にはSocket Modeが使われています。Slack BotがWebSocket経由でメッセージイベントを受け取り、すぐに応答し、イベントIDで重複を除きます。

重要なのは、新しいメッセージだけを保存しないことです。返信が届いたら、そのメッセージが属するスレッド全体を再取得し、親投稿とすべての返信を一つの会話として更新します。参加者や最終更新時刻も、常にスレッド全体の状態を反映します。

さらに、原文をそのままEmbeddingするのではなく、LLMで意味を蒸留します。

抽出するのは、エンジニアが実際に検索しそうな一行の質問、短い要約、解決内容、関連するシステムやコード参照です。Cerebrasは、会話を一貫した形式へ正規化する方が検索に有効だったと説明しています。ただし、改善幅や評価データの詳細は公開記事だけでは確認できません。

ただし、スレッド全体の要約だけでは、長い会話の途中にある重要な一言が消えることがあります。そこで使われるのがBurstingです。同じ人が連続して投稿した発言を一つのまとまりにし、スレッドの話題を前に付けてEmbeddingします。

すべての発言を追加対象にするわけではありません。記事では、珍しい語を示すIDFが4.0を超える、本文が200文字を超える、リアクションが付いているといった信号を組み合わせ、一定の基準を満たしたBurstだけを追加しています。

これらはCerebrasのデータに合わせた実装値であり、他の組織へそのまま移植すべき万能値ではありません。

この考え方は、Slackを「全文保存して検索する場所」ではなく、意思決定や解決知識を抽出する場所として扱う設計だと言えます。

コード検索ではgrepだけでもEmbeddingだけでも足りない

Cerebrasは、コードリポジトリをEmbeddingすべきか迷ったと説明しています。

Claude Codeのようなコマンドライン型AIが広がると、「コード検索はgrepで十分ではないか」と考えたくなります。実際、関数名、設定値、エラー文字列、ファイルパスが分かっている時は、正確な文字列検索が強い。

一方、大規模なコードベースでは、探している概念の名前を知らないことがあります。別の言葉で書かれた似た実装を探したい場合もあります。Cerebrasは、コードEmbeddingも導入しました。

Cerebrasの記事が参照するCursorの検証でも、grepだけの場合と比べて、意味検索を利用できる方が大規模コードベース上のエージェント性能を改善したと報告されています。ただし、その評価はCursor固有のベンチマークと実装条件に依存します。

利用したのは、オープンソースのCocoIndexです。

コードを言語ごとの境界で分割し、最初はクラスなど大きな単位を試します。大きすぎればメソッド、さらに小さなブロックへ分割します。一つのファイルから、ファイル単位と関数単位など複数粒度のEmbeddingが作られる場合があります。

Cerebrasには40GBを超える内部リポジトリもあるため、毎回すべてを再Embeddingする方法は現実的ではありません。CocoIndexは同期状態をPostgresで管理し、Commitごとに変更された部分だけを再処理します。

リポジトリが増えると、チーム自身が設定ファイルで追加できるようにしました。ファイルパス単位の許可リストと除外リストも設定します。

ここでの教訓は、「grepかEmbeddingか」を選ぶことではありません。正確な文字列検索と意味検索を、対象と質問に応じて使い分けることです。

質問を受けたら、先に検索計画を立てる

Cerebrasの検索は、質問文をそのまま一つのVector Searchへ渡して終わりではありません。

最初に軽量なLLMが、どの情報源と道具が必要かを判断します。

利用できる道具には、ファイルごとの要約、Slackや文書やコードを横断する統合検索、Slackの直接検索、リポジトリへのripgrep、関連する最近のPull Request、特定分野の専門家を探す機能があります。

Plannerは、どのProjectが存在し、各Projectにどの情報源があり、それぞれ何を探すのに向くかという短い説明を参照します。質問と現在の検索範囲から道具を選び、Executorが並列に実行します。

各結果は、共通のEvidence形式へ揃えられます。検索元、関連度、更新時刻、出典などを同じ形で扱い、最後のLLMが回答と引用へまとめます。

これはRAG、つまり外部から検索した情報をAIの回答へ組み込む仕組みを、一回の検索ではなく、計画、並列取得、統合、回答生成へ分けた構造です。

長い資料をすべて一度にAIへ渡す方法より、質問に関係する根拠を選び直す方が、費用だけでなく重要情報の埋没を抑えやすくなります。長い入力の中ほどにある情報をモデルが安定して利用できない場合があることは、長文脈研究でも報告されています。

複数の検索結果は、合意と多様性で並べ直す

異なる検索方式は、異なる順位を返します。

全文検索では一位でも、意味検索では圏外かもしれません。逆に、同じ文書が複数の検索方式で上位に現れることもあります。

Cerebrasは、最初にReciprocal Rank Fusionを使って順位を統合します。各検索結果の順位に対し、記事では「重み ÷（60＋順位）」という形で点数を足しています。

これは元の検索スコアの尺度を直接そろえるのではなく、各検索方式で何位だったかを使って統合する方法です。

ただし、「複数方式で上位なら必ず正しい」という意味ではありません。複数の検索方式が同じ偏りを持っていれば、誤った候補へ合意する可能性もあります。だからこそ、その後の重複除去、出典の多様化、質問に対する再評価が必要になります。

その後、同じ出典から切り出された重複断片をまとめ、一つのファイルが上位を独占しないよう件数を制限します。多様な上位20件を作り、小さなRerankerへ渡します。

Rerankerは、元の質問に対して各候補を0から10で採点し、上位10件を残します。

最後に、採用された断片の前後を追加します。文書の一節が見つかった場合、近くの見出し、前提、注意点も取り込みます。切り出された一段落だけでは、条件や例外が失われるからです。

最終的に検索が返すのは、単なる文章断片ではありません。複数検索から統合され、重複を除かれ、質問に対して再評価され、周辺文脈を補われたEvidence Packetです。

MCPでは答えではなく、検索の部品を公開する

CerebrasはMCPも利用しています。MCPは、AIアプリケーションが外部のデータや道具を共通方式で利用するための公開規格です。2026年7月時点で、公式サイトの最新版は2025年11月25日版です。

ここで興味深いのは、「質問に答える」という大きな機能を一つ公開していないことです。

Slack検索、コード検索、統合検索、専門家検索といった取得の基本部品を、それぞれ小さなToolとして公開します。入力と出力を狭くし、安定させ、Tool内部ではできるだけLLMを使いません。

Claude CodeなどMCPに対応したAIが、どのToolをどの順番で呼び、取得結果をどう組み立てるかを決めます。Retrieval Layerは、特定のAIモデルの判断へ依存せず、根拠を返すことへ集中します。

Web UIでは同じToolを使いながら、Planner、Executor、Synthesisを一体で動かします。利用者には「質問して答えを得る」画面に見えても、内部では同じ検索部品が並列実行されています。

AIエージェントを安全に動かすには、モデル選びだけでなく、Tool、権限、状態、評価、ログ、停止、復旧を含む実行基盤が必要です。

検索範囲を絞らなければ、情報が増えるほど使いにくくなる

Cerebrasは、情報源が増えるにつれて「すべてをすべてから検索する」方法が役に立たなくなったと説明しています。

Compilerのエンジニアは、Data Center OperationsのRunbookを毎回見たいわけではありません。そこでProjectを、検索範囲の基本単位として導入しました。

一つのProjectは、関連するSlackチャンネル、コードリポジトリ、内部データベース、文書空間を束ねた検索範囲です。同じ障害対応チャンネルや共通リポジトリは、複数Projectから参照できます。データを複製する必要はありません。

利用開始時には、自分の仕事に合う既定Projectを選びます。新しい社員でも、どのSlackやリポジトリを見るべきかを先に学ばず、高い関連性の回答を得られます。

この設計は、検索精度をモデル性能だけで改善するのではなく、最初から探索空間を狭める方法です。

Cerebrasの思想は借りても、企業規模までは背負わない

ここまで読むと、Postgres、Embedding、Reranking、MCP、Slack Botを全部作りたくなります。

しかし、私の環境では、これは明らかに過剰です。

私は一人開発が中心で、Jamsだけもう一名のエンジニアと進めています。Slackは一部で使う程度です。情報の中心はMacBook Pro上の複数リポジトリで、Google DriveとSlackが補助的な主要情報源です。

Cerebrasでは、社員数、組織数、情報量、リアルタイム更新の規模が違います。People Search、Expert Search、Onboarding用UI、全社的な認可・監査、大量のSlack更新処理には意味があります。

私の初期課題は、もっと小さい。

現在の変更に関係するリポジトリを探すこと。正しいファイルを見つけること。Git履歴から変更理由を確認すること。必要ならDriveの正式資料やSlackの合意へ進むこと。そして、Codex、Claude Code、ChatGPTへ必要な根拠だけを渡すことです。

したがって、作るべきものは企業Knowledge Baseではありません。

MacBook Pro上の複数リポジトリを中心に、質問ごとに検索先を選び、必要な情報と根拠をAIへ渡すProject Context Routerです。

最初に作るべきなのは、ベクトルDBではなくrepo catalog

初期構成の中心は、大規模な中央データベースではありません。

まず必要なのは、各リポジトリが何を扱い、どのファイルを正本として優先し、どのProjectと関係し、どの程度機密かを記録する小さなrepo catalogです。

管理項目は、リポジトリID、ローカルパス、目的、技術スタック、関連Project、重要ファイル、正本ファイル、機密性、現役か廃止かといった情報です。

これによって、AIは最初から全リポジトリを無差別に検索せず、「この質問なら候補はこの二つ」と絞れます。

検索には、まず既存の決定論的な道具を使います。

ファイル名はfd、全文はripgrep、Git管理下の文字列はgit grep、変更理由はgit logとgit blame、構造的な探索はASTやシンボル検索です。

コードや設定を探す時、関数名、クラス名、API名、設定値、エラー文字列が分かっているなら、この方法が速く、安く、説明しやすい。

初期の処理は、次の流れで十分です。

現在の依頼から候補リポジトリを選びます。ファイル名、全文、シンボル、Git履歴を検索します。関係するファイルだけを読みます。リポジトリ名、ファイルパス、行番号、Commitなどの根拠を付けて、CodexかClaude Codeへ渡します。

この段階だけでも、相当部分の問題を解ける可能性があります。以前の検討では60から80パーセント程度という仮置きもしましたが、裏付けのある数値ではありません。

公開記事へ残すなら誤解を招くため、実装前の判断材料ではなく、代表質問によって検証する仮説として扱うべきです。

Google Driveは全体同期せず、正本候補だけを見る

第二段階でGoogle Driveを加えます。

対象は、要件定義書、契約・発注文書、研修資料、顧客別案件資料、現行設計書、議事録、正式成果物、Google Sheets上の運用データなどです。

ただし、Drive全体を取り込むべきではありません。

Driveには、コピー、同名ファイル、途中版、古い内容を複製した新しいファイル、共有範囲の異なる資料が混ざります。更新日が新しいだけで正本とは限りません。

対象フォルダIDや対象ファイルを限定し、正本フラグ、更新日、関連Project、関連リポジトリを管理する方が安全です。実ファイルを一つのフォルダへ移す必要はなく、「検索してよい場所の一覧」を持つだけでも構いません。

Slackは全件保存せず、決定と未解決事項を拾う

第三段階でSlackを追加します。

対象は、Jams関連チャンネル、エンジニアとのDMやグループDM、技術判断が行われるスレッドに限定します。

残す価値があるのは、決定事項、仕様変更、担当、期限、実装理由、再利用可能な知識、リポジトリへ未反映の重要情報です。

すべての会話を永続知識へ変える必要はありません。Slackには雑談、相づち、仮案、撤回された方針、途中の思考が含まれます。全文をそのままKnowledge Baseへ入れると、途中案を正式判断として取り出す危険があります。

必要なのは、スレッド単位の検索と、Decision Distillationです。日付、Project、論点、決定、理由、参加者、出典スレッド、関連リポジトリ、現在も有効かを記録します。

ただし、これは実際のSlackデータを確認して初めて正式な判断記録になります。設計例を、そのまま事実として扱ってはいけません。

ベクトル検索は、困ってから追加する

第四段階で初めて、高度な検索を検討します。

追加候補は、Slackの意思決定蒸留、Drive文書の要約、Embedding、意味検索と全文検索を組み合わせるHybrid Search、Reranking、更新差分処理、権限フィルタです。

導入判断は、技術的に作れるかではなく、通常検索で解けない問題が頻発しているかで決めます。

文書が数千から数万件へ増えた。正確なキーワードを知らない質問が多い。違う表現の同じ概念を探したい。Slackや議事録の自然言語検索が増えた。全文検索で見つからない事例が蓄積した。複数情報源の結果を統合する必要が高まった。

こうした兆候が出てからで十分です。

逆に、初期から大規模Postgres、pgvector、全件Embedding、Slack全体の常時同期、Drive全体同期、候補を再採点するCross Encoder、Knowledge Graph、人物・組織向けUIまで作れば、運用コストが便益を上回る可能性があります。

AI時代は、作れるものが増えたからこそ、作らない判断が重要です。

最小完成条件は、根拠付きで既存判断へ戻れること

このProject Context Routerの初期完成条件は、派手な検索画面ではありません。

Codexへ「この変更に関係する既存リポジトリ、設計書、過去判断を調べて」と依頼した時、関係する情報源と根拠を返せることです。

返すべき根拠は、リポジトリ名、ファイルパス、該当箇所、Commit、更新日、Driveファイル、Slackスレッドなどです。

評価も、回答がそれらしく見えるかではなく、次で行うべきです。

正しいリポジトリを選べたか。正しいファイルを返したか。古い情報を除外できたか。根拠を示せたか。関係のない情報を減らせたか。検索時間とToken使用量は妥当か。AI回答が改善したか。誤った取得による手戻りは減ったか。

この評価方法は、まだ設計されていません。だからこそ、最初から大規模化せず、代表的な質問セットを作って検証する必要があります。

検索性能より先に、秘密情報と権限を設計する

ローカルリポジトリを横断検索する時、見落としてはいけないのが秘密情報です。

`.env`、APIキー、Token、秘密鍵、顧客情報、個人情報、契約情報、Slack DMを、AIへ無条件に渡してはいけません。

最低限、除外パターン、許可リスト、Projectごとの検索範囲、読み取り専用、出力時の秘匿、ログへ残さない情報を決める必要があります。

MCPを使う場合も同じです。MCPはデータとToolをAIへ接続できますが、接続できることと、許可してよいことは別です。

初期Toolは読み取り専用にし、たとえば次のような小さな機能へ限定するのが妥当です。

リポジトリ一覧を返す。指定範囲を検索する。ファイルを読む。Git履歴を探す。指定したDriveフォルダを検索する。限定したSlackチャンネルを検索する。Projectの文脈を返す。過去の決定を探す。

書き込み、削除、外部送信、本番操作は、検索基盤の役割から分けるべきです。

未確定事項は、実装前に全部埋めなくてよい

現時点では、実装開始そのものが正式決定しているわけではありません。

対象リポジトリの総数、現役と廃止の区分、依存関係、正本ファイル、機密性も未確定です。

Google Driveでは、対象フォルダ、Shared Driveを含むか、API検索かローカル同期か、正本の決め方、顧客別アクセス制御が決まっていません。

Slackでは、対象Workspace、Channel、DM、対象期間、Decision Distillationの自動化、Slackの決定をリポジトリへ移す運用が未確定です。

最初に接続するAIも、Codex、Claude Code、ChatGPTのどれにするか決まっていません。接続方式もCLI、MCP、Skill、小さなScript、ローカルWeb UIから選ぶ必要があります。

更新方式も、オンデマンド検索、cron、ファイル監視、Git hook、定期Index、Drive Changes API、Slack Eventのどれを採るか未決定です。

これらを最初に全部決める必要はありません。

最初の実験は、対象リポジトリを三つ程度に絞り、実際に繰り返し発生する代表質問を10から20件用意し、repo catalogと全文検索とGit履歴検索だけで、どこまで正しい根拠へ到達できるかを見ることです。質問は、実装場所、変更理由、正本、過去の類似実装、未解決事項など種類を分けます。

成功条件は、検索機能が動くことではありません。開発中の説明の繰り返しが減り、既存判断の見落としが減り、AIへ渡すContextが短く正確になり、実装の手戻りが減ることです。

作るべきなのは知識の倉庫ではなく、現在の仕事へ根拠を運ぶ仕組み

CerebrasのKnowledge Baseは、大規模な企業だから成立する特殊な事例に見えます。

しかし、最も重要な思想は規模に依存しません。

情報を無理に一つへ集めない。情報源ごとの強みを残す。質問に応じて検索先を選ぶ。完全一致と意味検索を使い分ける。複数の検索結果を統合し、質問へ再評価する。断片だけでなく周辺文脈を返す。AIには答えを丸投げするのではなく、根拠を取得する小さなToolを渡す。検索範囲をProjectで絞る。

個人・少人数開発へ落とすなら、さらに単純になります。

最初はローカルリポジトリだけを見る。repo catalogを作る。ripgrepとGit履歴を使う。正本ファイルを優先する。根拠を返す。必要になった時だけDrive、Slack、Embedding、Reranking、MCPを追加する。

私が作るべきなのは、すべての情報を保管する巨大なKnowledge Baseではありません。

今の作業に必要な情報を、正しい場所から、正しい根拠とともに運んでくるProject Context Routerです。

その設計なら、Cerebrasの思想を借りながら、Cerebrasの規模までは背負わずに済みます。

出典・参考資料

いいなと思ったら応援しよう！

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中 社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。