Hyper 会社ナレッジベース：AI Agent メモリのエンジニアリング設計

Claude Code にコード修正を頼んでも、3 か月前にそのブランチを削除した理由までは知りません。ChatGPT にプロジェクト判断を聞くと、すべての文書を読み直さないと答えられません。毎回プロジェクトの履歴を説明し直す必要がある。ここに Agent と普通の RAG の大きな違いがあります。RAG は静的な文書検索に強い一方で、会社の知識に含まれる 3 つの軸、つまり fact の有効期間、権限範囲、判断の推論チェーンを標準では扱えません。

Hacker News で Hyper は「会社ブレイン」を作ると言っていました。この言葉だけを見るとマーケティングっぽく聞こえます。それでも、創業者がローンチ投稿で明かした設計の細部には技術的な価値があります。episodes + facts の 2 層メモリ、typed edges、タイムスタンプモデル、hooks と MCP という 2 つの注入経路です。ここでは製品レビューではなく、これらの公開情報を使って「会社メモリ」の設計問題を分解します。5 層の設計チェックリスト、7 日間の試験導入、選定リスクの判断表までを見ていきます。

普通の RAG が受け止めきれない 3 種類のコンテキスト

RAG は文書を検索し、断片を返し、モデルに回答させます。この流れは静的なナレッジベースには有効です。ただし会社の知識には、RAG が標準で扱わない 3 つの軸があります。

軸	RAG の標準動作	実際の問題	Company brain に必要な仕組み
fact の有効期間	最新の一致断片を返す	古い文書＝無効な fact とは限らず、3 か月前の判断が後で覆っていることもあります	introduced_at / invalidated_at タイムスタンプで fact のライフサイクルを示す
権限範囲	検索時にユーザー ID を区別しない	全員に見える情報とプロジェクトメンバーだけが見える情報は違い、Agent が見てはいけない内容を読む可能性があります	access-control tags でフィルタし、チームや役割ごとに結果を絞る
判断理由	結論の断片を返す	結果を知ることと、推論の流れを知ることは違います。「なぜそう決めたのか」まで追えません	Episodes が元の会話を保持し、fact 層が derived from の出典を示す

従来の RAG は recency や relevance で並べ替えます。その情報が newer fact によって supersedes（置き換え）されたかどうかまでは判断できません。Hyper は各 fact に 2 つのタイムスタンプを付けます。introduced_at は最初に出現した時点、invalidated_at は無効になった時点を記録します。検索時は、文書の更新日ではなく、無効化された fact を除外する形です。

権限範囲は、複数人の組織ではさらに敏感です。Agent 呼び出しは、特定のチームメンバーを代理しているかもしれません。その人のプロジェクト範囲外の内容を読むべきではありません。Hyper は access-control tags で各 fact の可視範囲をマークし、検索層が呼び出し元の ID に応じて返す結果を絞ります。これは普通の「エンタープライズ検索」より細かい設計です。後者は文書単位の権限にとどまることが多く、company brain では fact 単位の絞り込みが必要になります。

判断理由は、普通の RAG が最も苦手なところです。「なぜ MongoDB ではなく PostgreSQL を選んだのか」と聞いたとします。RAG はアーキテクチャ文書の結論段落を返せるかもしれません。ただ、その段落には 3 か月前の技術議論、トレードオフ、最終判断のロジックが含まれていない可能性があります。Hyper の episodes 層は元の会話ノードを保持し、facts 層は derived from typed edge で出典 episode を指します。検索時に関係をたどれば、結果だけでなく推論チェーンにも戻れます。

Hyper の 2 層メモリアーキテクチャ

Hyper はメモリを 2 層で整理します。Episodes（元データの保存）と Facts（構造化層）です。その上にナレッジグラフで関係を張ります。

Episodes 層：元の会話ノードを保持し、コンテキストを捨てません。fact の出典アンカーとして機能します。Agent が判断プロセスを追う必要があるときは、fact から derived from edge をたどって元の会話断片に戻れます。要約済みの結論だけを読むわけではありません。

Facts 層：subject-predicate-object の三つ組で構造化します。各 fact は主体、関係、対象の 3 フィールドを持ち、さらにタイムスタンプと typed edges を持ちます。創業者が公開した typed edges は次の 3 種類です。

Typed edge	意味	利用場面
derived from	その fact がどの episode から来たか	判断の推論チェーンを追う
supersedes	新しい fact が古い fact を置き換える	無効な fact をマークし、古い結論をフィルタする
tension	facts の間に衝突や矛盾がある	人手修正を促し、矛盾した情報をモデルが採用するのを避ける

タイムスタンプモデル：各 fact には 2 つの時間軸があります。T 軸はイベント発生時刻、たとえば「判断は 3 月に行われた」を記録します。T’ 軸はシステムが fact を取り込んだ時刻、たとえば「この fact は 6 月にナレッジベースへ書き込まれた」を記録します。会社の知識は遅れて入力されることが多いため、この分離が重要です。会議の結論が 1 週間後に記録されることもあり、システムは「事実が起きた時刻」と「その事実を知った時刻」を区別する必要があります。

アーキテクチャの要点：

• Episodes は要約して捨てず、元の会話ノードを保持します（HN での創業者説明と Zep 論文の文脈）。
• Facts は三つ組として構造化され、それぞれがタイムスタンプと typed edges を持ちます（HN で公開された内容）。
• introduced_at / invalidated_at が fact のライフサイクルを示し、検索層は無効化された内容を除外します。
• ナレッジグラフは「fact」だけでなく「関係」を typed edges で扱います。ここが普通のベクトルデータベースとの大きな違いです。

この設計の目的は、より多くのデータを保存することではありません。Agent が関係をたどってコンテキストを見つけられるようにすることです。普通のベクトルデータベースは似た断片を返せますが、断片同士の論理依存、置き換え関係、衝突点は知りません。typed edges とタイムスタンプを組み合わせると、「この fact はどこから来たか」「まだ有効か」「置き換えられていないか」というメタ情報を検索結果に添えられます。

検索と注入の 2 つの経路

知識を書き込んだ後、Agent がそれを使う経路は 2 つあります。能動的に問い合わせる「検索」と、受動的に受け取る「注入」です。

検索メカニズム（HN での創業者説明）：

• Postgres 全文検索：キーワード一致。たとえば「特定の API endpoint の定義」のような正確な問い合わせに向きます。
• Embedding セマンティック検索：ベクトル類似検索。「前回のパフォーマンス最適化の結論は何だったか」のような曖昧な問い合わせに向きます。
• Reciprocal Rank Fusion（RRF）：全文検索とセマンティック検索の 2 経路の召回結果を統合し、総合順位で返します。
• Access-control tags フィルタリング：呼び出し元の ID に応じて結果を絞り、権限境界を守ります。

この組み合わせは純粋なベクトルデータベースとは違います。後者はセマンティック召回だけなので、正確なキーワード問い合わせで結果を落とすことがあります。Hyper は RRF で 2 つの召回経路を統合し、並べ替え段階でキーワード一致と意味的類似度をあわせて見ます。

注入経路の比較：hooks と MCP は異なるデータチャネルです。

軸	Hooks	MCP
仕組み	Agent のコンテキストへリアルタイムに注入する（push）	標準化された tool calling プロトコル（pull）
透明性	HN ではインストール提示が十分に明確か疑問が出ていました	OpenAI SDK では MCP server を明示的に宣言する必要があります
適した場面	現在のプロジェクト文書など、コンテキストの自動注入	データベース問い合わせなど、Agent が能動的にツールを呼ぶ場面
技術依存	クライアント側にインターセプト層が必要	OpenAI/Anthropic など、Agent フレームワーク側の MCP 対応が必要
管理リスク	ユーザーが何のデータを注入されたか知らない可能性があります	管理者が MCP server の権限範囲を制御できます

2 つの経路は併用できます。Hyper の創業者は、hooks を Claude Code を開いたときにプロジェクト文書を自動読み込みするようなリアルタイム注入に使い、MCP を Notion や Gmail の問い合わせのような Agent の能動的な外部ツール呼び出しに使うと説明しています。ただし HN では hooks の透明性も疑問視されました。どのデータが Agent の会話へ自動注入されるのか、ユーザーが明確に理解できるかという問題です。

選定時に確認したい点は 2 つです。hooks に明確なインストール提示があるか。MCP server の権限範囲を管理者が制御できるか。OpenAI の developer mode 文書では、MCP apps にはセキュリティ検証が必要で、Enterprise プランでは RBAC でアクセスを制御できます。つまり MCP の管理モデルは比較的成熟しています。一方、hooks の透明性は製品設計に依存します。

Company brain の 5 層設計チェックリスト

自作でも製品選定でも、この 5 層に答えがあるかを確認します。どれか 1 つ欠けると、実運用で必ず詰まります。

第 1 層：データソース接続

• ツール選択：Notion、Gmail、Slack、GitHub、Linear、Jira など。チームの workflow に合わせます。
• 接続方式：webhooks（リアルタイム）または polling（定期取得）。webhooks は速い一方、接続先の対応が必要です。
• データクレンジング：Slack の雑談チャンネルのようなノイズを除き、機密情報をマークし、文字コードを揃えます。
• 初期インポート：全履歴を入れるか、新規データだけにするか。過去データには古い fact が大量に含まれる可能性があります。

第 2 層：fact 層 Schema

• Fact 構造：subject-predicate-object の三つ組で、各 fact を統一形式で保存します。
• タイムスタンプ：introduced_at（初出）+ invalidated_at（失効時刻）。片方が欠けるとライフサイクル判断が難しくなります。
• Typed edges：少なくとも derived from（出典）、supersedes（置き換え）、tension（衝突）の 3 種類を持たせます。
• 衝突処理：tension を自動で付けて人が確認するか、タイムスタンプで newer fact を採用します。

第 3 層：検索層

• 召回の組み合わせ：全文（キーワード）+ セマンティック（embedding）+ RRF 融合。純粋なセマンティック召回は正確な問い合わせを落とすことがあります。
• 権限フィルタ：fact 単位の access-control tags で、呼び出し元の ID に応じて結果を絞ります。
• 並べ替え：recency、relevance、fact validity を組み合わせ、無効な fact を除外します。
• 遅延目標：検索応答は実測で < 500ms。これを超えると Agent 呼び出しの体感が悪くなります。

第 4 層：注入層

• 経路選択：hooks（リアルタイムなコンテキスト注入）と MCP（Agent の能動的な呼び出し）。両方を併用できます。
• Agent 互換性：Claude Code、Cursor、ChatGPT、Codex が選んだ経路に対応しているか。
• 管理モデル：hooks に透明なインストール提示があるか。MCP の server 権限を管理者が制御できるか。
• データ量制御：トークン上限を超えないよう注入コンテキスト長を制限し、relevance の高い fact を優先します。

第 5 層：ガバナンス層

• 権限継承：データソースの権限を fact 単位の可視範囲へどう写すか。Slack の非公開チャンネル由来の fact は全員に見えてはいけません。
• 監査ログ：誰がいつどの fact を注入し、Agent がいつどの fact を読んだか。問題発生時に追跡できる必要があります。
• 人手修正：誤った fact をマークし、invalidated フローを設計し、手動で補足 fact を追加できるようにします。
• データエクスポート：完全な fact store を JSON/CSV で出せるかを確認し、ベンダーロックインを評価します。

このチェックリストの考え方は単純です。データソース層は「どこから来るか」を決めます。fact 層は「どんな構造で保存するか」を決めます。検索層は「どう見つけるか」を決めます。注入層は「どう渡すか」を決めます。ガバナンス層は「誰が管理し、どう修正するか」を決めます。どれか 1 層でも欠けると、会社ナレッジベースは実運用で止まります。

7 日間の試験導入パス

小規模チームの最初の 1 週間で、Slack、メール、CRM を全量接続しないほうがよいです。権限が複雑でノイズも多く、検証段階でガバナンス問題が先に出てしまいます。まず低リスクのデータソースから始め、召回率と修正フローを確認してから広げます。

Day 1-2：低リスクのデータソースを選ぶ

• Notion の公開文書（プロダクトロードマップ、技術仕様）
• GitHub README と Wiki（プロジェクト構成、API 文書）
• 除外：Slack の非公開チャンネル、過去メール、CRM 顧客データ（権限が敏感でノイズも多い）

Day 3：Fact Schema を設計する

• 3〜5 フィールド：subject、predicate、object、introduced_at、source
• 完璧を目指さない：検証段階の重点は検索経路の確認で、Schema は後から改善できます。
• 命名規則を決める：subject は ProjectX のような統一形式にし、predicate は uses のような動詞にします。

Day 4-5：検索と注入をテストする

• 検索テスト：5〜10 個のクエリを用意し、重要な fact が見つかるかを確認します。
• 注入テスト：Claude Code または Cursor など 1 つの Agent を選び、注入されたコンテキストを読めるかを検証します。
• 遅延記録：検索応答が < 500ms か、注入後に Agent が fact を正しく引用できるかを記録します。

Day 6-7：リプレイと人手修正

• 過去クエリをリプレイし、検索結果に誤った fact や古い fact が含まれるかを確認します。
• エラー記録：invalidated にすべき fact を列挙し、マーク手順を設計します。
• 修正フロー設計：人が補足 fact を追加し、誤った fact に invalidated_at タイムスタンプを付ける流れを作ります。

最初の 1 週間でやらないこと：

• Slack、メール、CRM を接続しない（権限とノイズが複雑）
• 完璧な Schema を追わない（まず検索経路を検証し、後から改善する）
• 本番データソースを接続しない（テストデータまたは公開文書で流れを検証する）

検証の終わりには、動く検索 + 注入フロー、検証済みの 5〜10 件の fact、修正マークの流れがあるはずです。この 3 つがデータソース拡張の前提になります。まず「見つかる、読める、直せる」を確認し、その後で接続ツールを増やします。

選定リスク判断表

意思決定時は 7 つのリスク軸を確認します。それぞれに情報源と信頼度を付けておきます。

リスク軸	公開情報	出典	信頼度	選定時に確認すること
データエクスポート	創業者はエクスポート対応と説明	公開スレッドの創業者返信	medium	エクスポート形式（JSON/CSV）、完全性、移行コスト
プライバシー約束	FAQ では「ユーザーデータで学習しない、AES-256 暗号化」とされる	Hyper FAQ	medium	SOC 2 / ISO 27001 の予定、データ保存場所
ベンダーロックイン	セルフホスト option なし	公開スレッドの返信	high	エクスポートが完全か、代替手段があるか
Hooks の透明性	インストール提示が十分に明確か疑問が出ている	公開スレッドの利用者フィードバック	medium	ユーザーがどのデータが注入されるか理解できるか
権限継承	access-control tags	公開スレッドの創業者説明	high	データソース権限を fact 単位へどう写すか。継承ルールは未公開
ナレッジグラフのコンテキスト	typed edges が関係を保持	公開スレッドの創業者説明	high	Episode が要約されて意図を失わないか（利用者から懸念あり）
衝突処理	人手修正の仕組みは未公開	公開スレッドの製品Q&A	low	誤った fact をマークできるか、手動で補足できるか

7 つのうち、データエクスポートとベンダーロックインは特に重要です。HN の返信では創業者がエクスポート対応に触れていますが、公式の完全なコミットメントまでは確認できません。つまり選定時には、エクスポート形式が JSON/CSV のように構造化されているか、typed edges とタイムスタンプを含む完全な fact store を出せるか、別システムへ移行するときにどれだけ追加整形が必要かを確認すべきです。

Hooks の透明性も見落としやすいリスクです。hooks はクライアント側でコンテキストを注入するため、ユーザーはどのデータが Agent の会話へ自動ロードされたのかを知らないかもしれません。選定時は、明確なインストール提示があるか、ユーザーが注入データの範囲を確認・制御できるかを見ます。

権限継承は、access-control tags という技術方針は公開されていますが、継承ルールは未公開です。実際の問題は具体的です。Slack の非公開チャンネル由来の fact を fact 単位の可視範囲へどう写すのか。CRM 顧客データをチームごとにどう絞るのか。製品選定でも自作でも、このマッピング設計は必要です。

次に読むもの

Agent とナレッジベースの組み合わせをさらに掘るなら、次の記事も参考になります。

• RAG + Agent：次世代 AI アプリケーションアーキテクチャ — RAG と Agent の組み合わせ、検索結果で Agent の判断を動かす方法。
• AI Agent メモリシステム：エージェントにコンテキストを覚えさせる — Agent 個人メモリの設計と、会社レベルの共有メモリとの違い。
• Workers AI + Vectorize RAG チュートリアル — Cloudflare Vectorize の実践、小型 RAG システムを作る技術細部。
• AI Agent の監視と自己復旧：失敗から制御へ — Agent 実行失敗時の監視と自己復旧。メモリと実行をつなぐ考え方。
• Agent tool calling 実践：AI に外部 API を呼ばせる — MCP と tool calling の技術細部。注入経路の実践参考。

結論

Hyper はまだ初期段階のプロダクトです。それでも公開されている設計の細部、つまり 2 層メモリ、typed edges、タイムスタンプモデル、hooks と MCP の 2 経路は、「会社メモリ」を学ぶよいケースです。小規模チームが選定または自作するときは、データエクスポート、hooks の透明性、衝突処理の 3 点を重点的に確認してください。

検証段階では、狭い workflow から始めます。Notion の公開文書や GitHub README から始め、検索の召回率と修正フローを確認してから、Slack やメールへ広げます。最初から完璧な Schema を目指さないこと。fact のライフサイクル、権限継承、人手修正は、実測しながら改善する必要があります。

すでに Claude Code や Cursor を使っているなら、まず hooks でプロジェクト文書を注入し、Agent が fact を正しく引用できるかを観察してみるとよいです。次の一歩は、メモリと実行を閉じた流れにすること。Agent の監視と自己復旧を組み合わせ、失敗を自動で検出し、再試行できるようにします。