Brainbaseの全体像

Brainbaseは、AIに何度も説明したくない文脈を自分のローカル環境に置き、CodexやClaude Codeが必要な時に取りに来られるようにする仕組みです。

このページは、技術構成を細かく覚えるためではなく、使う人が「何をどこに置き、AIがどう使い、日々どう育てるのか」をつかむための入口です。

ひとことで

AIが毎回迷いやすい「自分・仕事・関係性・決定事項」をBrainbaseに置き、AIはMCP経由でそれを読んでから作業します。

Brainbaseでは、この文脈を「プロジェクト」を中心に整理します。ここでいうプロジェクトは、開発案件だけではありません。病院、クリニック経営、新規事業、特定の顧客対応、研究テーマのように、AIに同じ前提で考えてほしいまとまりを指します。

全体の流れ

1. ユーザーがCodexやClaude Codeに依頼します。
2. AIがBrainbase MCPに「この人の文脈を教えて」と聞きます。
3. Brainbaseが「これはどのプロジェクトの話か」を見ます。
4. ローカルSSOTから、そのプロジェクトの目的、関係者、用語、決定事項を返します。
5. 必要に応じて、メール、カレンダー、ドライブ、タスク、議事録などの元データを見ます。
6. 元データから得た情報は、すぐ正本にはしません。
7. 人間が確認したものだけを正本に入れます。
8. 次回以降、AIはその前提を持った状態で返答や作業をします。

何がどこにあるか

場所	役割
Codex / Claude Code	ユーザーから依頼を受け、作業するAIエージェントです。
Brainbase MCP	AIがBrainbaseの文脈を取りに行く入口です。
ローカルSSOT	自分、仕事、関係性、決定事項などの正本です。
Personal KG	自分の判断基準、価値観、経験、気づきを置く場所です。仕事で使うかどうかを考える前の個人的な文脈もここで扱います。
プロジェクト	AIに同じ前提で考えてほしい仕事のまとまりです。目的、関係者、用語、決定事項を束ねます。
元データ	メール、カレンダー、ドライブ、タスク、議事録などです。判断材料にはしますが、そのまま正本にはしません。
日次ルーティン	ohayo、oyasumi、retro で文脈を見直し、必要なものだけを正本に育てます。

プロジェクトが中心になる理由

Brainbaseで一番大事なのは、AIが「これは何の話か」を外さないことです。

同じ人との会話でも、経営の話、採用の話、医療現場の話、新規事業の話では、見るべき前提が変わります。プロジェクトを分けておくと、AIはその話に関係する人、固有名詞、経緯、決定事項を優先して読めます。

音声メモや会議メモの要約でも同じです。文字起こし自体の精度をBrainbaseが直接上げるわけではありません。代わりに、どのプロジェクトの話か、関係者は誰か、よく出る固有名詞は何か、聞き間違えやすい言葉は何かを渡すことで、蒸留や要約の精度を上げます。

たとえば医療経営者の場合、最初は「病院」や「クリニック経営」そのものを1つのプロジェクトとして扱って構いません。慣れてきたら、採用、収支改善、往診、学会、共同研究のように、AIに違う前提で考えてほしい単位だけを分けます。

データ構造の見方

Brainbaseのデータ構造は、最初から細かいデータベース設計として覚える必要はありません。まずは次のような箱があると考えてください。

箱	入れるもの	例
self	自分自身の基本情報、役割、よく使う前提	会社、役職、仕事の領域、苦手な説明
projects	AIに同じ前提で考えてほしい仕事のまとまり	クリニック経営、Brainbase導入、共同研究
people	関係者	顧客、相談相手、意思決定者、院内メンバー
relationships	人や組織との関係性	何を一緒に進めているか、注意すべき経緯
terms	固有名詞、略称、聞き間違えやすい言葉	サービス名、院内用語、文字起こしで崩れる名前
decisions	すでに決めたこと、戻してはいけないこと	今月は海外取り寄せで進める、まず5プロジェクトに分ける
personal_kg	判断基準、価値観、気づき、まだ仕事の正本にする前の考え	重要視する経営指標、違和感、学び
sources	元データの置き場所	メール、カレンダー、ドライブ、タスク、議事録、音声メモ

AIは、まず projects を見て「今どの前提で考えるべきか」を決めます。その上で、関係する people、relationships、terms、decisions、personal_kg を読んで作業します。

Brainbaseが増やす価値

Brainbaseの価値は、情報を大量に保存することではありません。AIが作業を始める前に、本人の前提を読み、説明のやり直しを減らすことです。

たとえば、次のような依頼で差が出ます。

• 「この人に返信して」と言った時に、相手との関係性や過去の経緯を踏まえる。
• 「このプロジェクトを進めて」と言った時に、目的、関係者、判断基準を取り違えない。
• 「今日やることを整理して」と言った時に、カレンダーやタスクだけでなく、本人が大事にしている優先順位も見る。
• 「昨日の振り返りをして」と言った時に、気づきをPersonal KGに入れ、必要なものだけをSSOTに昇格する。

元データとの関係

メール、カレンダー、ドライブ、タスク管理ツール、議事録は、Brainbaseにとって材料です。

ただし、材料を取り込めばすぐ価値が出るわけではありません。大事なのは、AIが材料を読み、人間に確認し、今後も使う前提だけを正本として残すことです。

そのため、Brainbaseのオンボーディングでは次の順で進めます。

1. まず、本人が二度と説明したくない文脈を聞きます。
2. 現在のプロジェクトを最小限に分けます。
3. それぞれの目的、関係者、用語、判断基準を整理します。
4. その文脈を使って、AIがどれだけ説明を省けるかを試します。
5. 必要になったところで、メール、カレンダー、ドライブ、タスクの接続を検討します。
6. 元データから得た情報は、人間が見直してから正本に入れます。

Personal KGとSSOTの関係

Personal KGは、本人の内側にある文脈を置く場所です。たとえば、価値観、判断基準、過去の経験、最近の気づき、まだ仕事の正式な前提にするか迷っていることを扱います。

SSOTは、今後AIが仕事の前提として参照してよい正本です。

日々の運用では、oyasumi や retro で一日の気づきや振り返りをPersonal KGに入れます。その中から、今後の仕事で繰り返し使うべきものだけをSSOTに入れます。

最初に目指す状態

最初のゴールは、すべてのデータを接続することではありません。次の状態を作ることです。

• CodexやClaude CodeからBrainbase MCPを呼べる。
• get_context や search で、自分・仕事・関係性・プロジェクトの文脈が返る。
• AIへの依頼で、説明し直さなくて済む場面がひとつでも生まれる。
• 正本に入れる前に、人間が確認する流れが守られている。

やらないこと

Brainbase v1では、次のものを前提にしません。

• サーバー運用
• Web UI
• 外部LLMへの無条件送信
• OAuthトークン、パスワード、APIキーをチャットに貼る運用
• 人間の承認なしに、ライブ設定、スケジューラー、正本を書き換えること

まずは、個人のローカル環境でBrainbase MCPを動かし、AIが本人の文脈を読んで作業できる状態を作ります。