Hyper の会社ブレイン：AI Agent の知識ベースはどう設計すべきか

Hyper で足が止まったのは、company brain という言葉そのものではありません。多くのチームがすでに直面している問題を、かなり率直に言っている点です。AI Agent は、複数ターンにわたってコードを直し、メールを書き、スクリプトを実行できるようになりました。それでも、チームが昨日却下した案を知らないことがよくあります。Codex に決済ページを直してもらうと、古い PR のプロダクト表現を参照してしまうかもしれません。Claude Code に API の制約を確認させると、Drive を読み直す一方で、その後 Slack で決まった変更を見落とすかもしれません。人間の同僚なら「その案はもう使わないよ」と一言添えますが、Agent はその空気を勝手には覚えません。

私はまず Hyper を、アーキテクチャのケースとして見ます。まだ初期段階のプロダクトであり、公開情報は第三者検証済みの効果を意味しません。それでも、YC ページと Launch HN の議論に出ている情報は、AI Agent 向けの会社知識ベースが何を担うべきかを考える材料になります。単なる文書検索でも、MCP connector でもなく、Agent が正しく、新しく、権限に沿った会社コンテキストの中で動くための仕組みです。

普通の RAG が詰まるところ

普通の RAG は、文書からチャンクを見つける用途に向いています。Markdown、PDF、Web ページを分割し、embedding を作り、質問時に近い内容を取り出して、モデルに回答を組み立てさせます。BetterLink でも以前 RAG + Agent アーキテクチャ を扱いました。この方法は、ナレッジ Q&A、サポート FAQ、コードベースの説明にはかなり使えます。

ただ、会社コンテキストはもう少し厄介です。Agent が必要としているのは「似た内容を探す」だけではありません。その内容が今も信頼できるのか、誰が見てよいのか、当時なぜその判断になったのかまで必要です。

古い情報と新しい情報が混ざる

小さなリリース判断を考えてみます。月曜の会議では「金曜に出す」と決まりました。水曜に顧客フィードバックが変わり、プロダクト責任者がリリースを翌週月曜に変更しました。ベクトルデータベースには両方の文章が入る可能性があります。どちらが上位に来るかは、query、embedding、chunk、ランキング次第です。Agent が古い「金曜に出す」という断片だけを拾うと、間違った告知を書き、間違ったタスクを並べ続けます。

より安定した設計では、2 つの fact をどちらも残しつつ、新しい fact が古い fact を置き換えたことを明示します。誰が言ったのか、いつ言ったのか、どの範囲に影響するのか、以前の結論がなぜ無効になったのか。こうしておけば、Agent が「なぜ延期したのか」と聞かれたとき、履歴を追えます。古い文脈を消す必要はありません。

権限は回答後ではなく検索前に扱う

会社知識ベースが実行権限を持つ Agent に接続されると、権限は細部ではなくなります。営業、サポート、エンジニアリング、経営層が同じ顧客について質問しても、返すべき情報範囲は違うかもしれません。OpenAI のチーム向け connector の説明でも、ChatGPT はユーザーが既にアクセスできる内容だけを見るとされ、connector は既存の権限境界を尊重します。

このチェックは、モデルがコンテキストを見た後にプロンプトで守らせるものではありません。まず見えてはいけないデータを除外し、その後に検索、ランキング、注入を行うべきです。そうしないと、Agent がログ、下書き、tool call を通じて機密情報を漏らす可能性があります。

Agent には「なぜ」も足りない

多くの社内文書は、結果だけを記録し、理由を残していません。あるデザイン案が却下された理由は、ブランドに合わなかったからかもしれません。営業が顧客の反応を聞いたからかもしれません。技術的負債が重すぎたから、あるいは単に当時リソースが足りなかったからかもしれません。Agent が結果だけを見ると、別の場面で同じ失敗を繰り返しがちです。

OpenAI の memory 更新では、良い記憶の目標として、コンテキストの継続、好みへの追従、時間が経っても新しさを保つことが挙げられています。会社レベルでは、もう 1 つ足したい要件があります。判断の背後にある制約を説明できることです。この層がないと、Agent は資料を速く探せるだけで、会社をより理解しているとは言いにくいでしょう。

Hyper の公開情報から見えるアーキテクチャ

Hyper の公開情報には、私が気にしている細部がいくつかあります。プロダクトが完璧だと証明するものではありませんが、「Slack と Drive をベクトルデータベースに入れる」よりは具体的です。

1 つ目は、episodes と facts の分離です。HN のローンチスレッドで、創業者は文書、メール、カレンダー、Slack、Granola の記録などの元データを episodes と呼んでいます。facts は episodes から抽出した意味で、subject-predicate-object に近い形を取り、plain summary、導入時刻、失効時刻も持ちます。元データは事実の出典として残し、抽出した facts を推論と検索に使う形です。

2 つ目は、facts 間の関係エッジです。公開議論では、ある fact が別の fact と tension の関係にある、別の fact から derived されている、新しい fact が古い fact を supersede する、といった話が出ています。これは Agent にとって重要です。会社コンテキストは平らな資料フォルダではなく、変化し続ける判断の履歴だからです。

3 つ目は、ハイブリッド検索です。Hyper は HN で、query expansion、embedding semantic search、Postgres full-text search、reciprocal rank fusion に触れています。特別な魔法ではありませんが、かなり実務的です。セマンティック検索は意味に強く、全文検索は顧客名、チケット ID、関数名、契約番号のような完全一致に強い。融合ランキングは、単一の検索経路への依存を減らします。

4 つ目は、権限タグです。各 fact は provenance と access-control tags を持ち、検索時には質問者がアクセスできる facts と episodes だけが評価対象になります。これがない company brain は、すぐにセキュリティ負債になります。

5 つ目は、hooks と MCP の使い分けです。MCP 公式ドキュメントは、MCP を AI アプリケーションと外部システムを接続するオープン標準と説明しています。OpenAI Agents SDK も複数の MCP 接続方式をサポートしています。MCP は Agent がツールを能動的に呼び出すときに便利ですが、そのツールを呼ぶべきタイミングを Agent が認識する必要があります。Hyper は HN で、Claude Code、Codex、Cursor などでは lifecycle hooks も使い、セッション開始、prompt 送信、Agent ターン終了などの時点でコンテキストを注入または抽出すると説明しています。この設計は、特に hook のインストール透明性をめぐって議論があります。ただ、重要な問題を示しています。すべてのコンテキストを、Agent が思い出して取りに行くことに任せるのは不安定です。

company brain は検査できる部品に分けて作る

チームがまだ新しいベンダーを入れたくない場合でも、小さな版は作れます。すべてのデータを接続するところから始めるのではなく、レビューできる部品に分けるところから始めましょう。

Source：元データを再確認できるようにする

ソース層は、初日から全体を覆う必要はありません。良い出発点は、プロダクト判断の Markdown、最近の PR 要約、公開 issue、サポート知識ベースです。Slack、メール、CRM は情報量が多い一方で、ノイズと権限管理も重いので、後で追加するほうがよいです。

各ソースには、最低限のメタデータを持たせます。ソース種別、元 URL またはファイルパス、作成時刻、更新時刻、作者、可視範囲、hash です。後で fact の抽出が間違っていたとき、必ず元テキストに戻れるようにします。

Fact：fact は単なる要約にしない

使える fact には、subject、predicate、object、summary、source、introduced time、invalidated time、permission tags、confidence、人手による修正記録が必要です。これは項目を増やしたいからではありません。Agent が回答するときの境界を作るためです。

例としては、次のようになります。

Field	Example	Why it matters
subject	checkout-redesign	fact がどのプロジェクトに紐づくかを示す
predicate	supersedes	古い案との関係を示す
object	checkout-v1-layout	置き換えられた対象を追える
source	PR #183 + product-note.md	回答時の出典になる
valid_from	2026-06-03	新旧を判断できる
acl	product, engineering	検索前に権限を絞れる

fact 抽出は初回から正確にはなりません。そのため、人手による修正入口が必要です。HN の議論で、成熟企業の乱雑で矛盾したデータについて質問が出たとき、Hyper の創業者は /correct のような MCP skill による強い修正に触れていました。この方向性は参考になります。人が「これは違う。こちらを正とする」と明示でき、その履歴が残る設計です。

Retrieval：単一路線よりハイブリッド検索が安定する

ベクトル検索は曖昧な意味に強い一方、顧客名、SKU、チケット ID、関数名、契約番号などはキーワード一致が効くことが多いです。私は検索を 3 段階に分けます。

1. まずユーザー ID、プロジェクト、データソース、権限で絞り込みます。
2. 次にセマンティック検索、全文検索、グラフ近傍展開を並列で走らせます。
3. 最後に結果を融合または再ランキングし、関連度の高い少量の facts だけを注入します。

コンテキストは多ければよいわけではありません。広すぎるコンテキストは、モデルに無関係な facts まで手がかりとして扱わせます。より実用的なのは、毎回 5〜15 件の狭い facts を出典と信頼度つきで注入することです。情報が足りない場合は、Agent が追質問するか、元ソースを確認するべきです。

Injection：MCP、hooks、手動コンテキストには別々の境界がある

MCP は入口であり、完全な記憶システムではありません。Agent がツールやデータソースにアクセスできるようにし、search_company_facts、correct_fact、get_decision_history のような機能も公開できます。Agent の tool calling の延長として、会社知識ベースをツールとして接続する発想です。

hooks の強みは安定性です。セッション開始時や prompt 送信前に自動でコンテキストを注入でき、モデルがツールを呼ぶことに依存しません。一方でリスクもあります。ユーザーは、何がインストールされ、いつ動き、何を読むのか、どう無効化できるのかを知る必要があります。この点は HN コメントでも反発がありました。小規模チームで自作するときも、通知、ログ、トグルを見える場所に置くべきです。

手動コンテキストにも価値があります。高リスクのタスクでは、人が「今回使ってよいプロジェクト知識」を選ぶほうが、全自動より安心です。AI-first は、すべてを無人化するという意味ではありません。

Governance：修正、エクスポート、監査は早めに設計する

company brain が便利になるほど、移行コストは上がります。HN でもベンダーロックインへの懸念が出ていましたが、これは現実的な心配です。すべての Agent が同じ知識層に依存すると、エクスポート、削除、バックアップ、監査は追加機能ではなくなります。

検証段階で、私は次の点を確認します。facts は JSON や CSV でエクスポートできるか。元の episodes は削除できるか。権限変更時に再フィルタリングされるか。どの Agent がどのタスクでどの fact を使ったかのログはあるか。人手による修正は古い fact を上書きするのか、履歴チェーンを残すのか。早めに聞くほど、後の負債は減ります。

いくつかの選択肢をどう使い分けるか

これらの選択肢は、同じ問題を解いているわけではありません。名前に引っ張られないほうがよいです。

選択肢	向いている用途	入力	強み	弱点
文書 RAG	既存資料から答える	Markdown、PDF、Web ページ	安く作りやすい	fact の失効や衝突に弱い
エンタープライズ検索	従業員のセルフサービス検索	Drive、Slack、Wiki	カバー範囲が広く接続も成熟	Agent の自動実行向けとは限らない
MCP ツール	Agent と外部システムの接続	API、データベース、ツール	標準化され、エコシステムが速い	Agent がツールを呼ぶことに依存する
個人メモリ	1 人のユーザーの好みを覚える	会話、好み、タスク履歴	パーソナライズに強い	チーム facts と多人権限に弱い
company brain	Agent に安定した共有コンテキストを渡す	文書、PR、会議、チャット、メール	facts、関係、権限、注入を扱える	アーキテクチャと governance のコストが高い

従業員が「経費精算の手順はどこ？」と聞くだけなら、エンタープライズ検索や普通の RAG で十分です。Agent がコードを直し、メールを送り、営業フォローを書き、顧客リスクを要約するなら、もっと多くの情報が必要になります。この fact は今も有効か。出典は信頼できるか。ユーザーは見てよいのか。その action は確認を必要とするのか。

OpenAI のチーム connector は、チームツールの内容を会話に持ち込む方向に進んでいます。MCP エコシステムは、Agent がより多くのツールへ接続しやすくしています。company brain は、その間にある層に近いものです。散らばったコンテンツを、継続的に更新され、追跡でき、権限で絞り込まれ、複数の Agent が再利用できる会社コンテキストに変えます。

7 日間の検証：狭いワークフローから始める

company brain を検証するために、全社データを最初から接続する必要はありません。低リスクで頻度の高い Agent ワークフローを 1 つ選び、1 週間だけ回してみます。

1〜2 日目：ワークフローと情報源を選ぶ

境界が明確なシナリオを選びます。たとえば「Codex に最新のプロダクト制約に沿って小さな機能を直してもらう」「サポート Agent に最近の bug 記録から返信草稿を作らせる」といったものです。つなぐ情報源は 3 種類だけにします。プロダクト判断の文書、最近の PR 要約、公開 issue です。全量 Slack、メール、CRM から始めないようにします。

禁止範囲も書いておきます。実メールは送らない。本番設定は変えない。財務や HR データは読まない。出典のない fact を結論として扱わない。

3〜4 日目：facts と衝突関係を抽出する

ソースから 50〜100 件の facts を抽出します。一部は手で抽出し、その後モデルに補助させます。各 fact には、出典、時刻、権限、信頼度を付けます。衝突があっても、古い内容を急いで消さないでください。関係を付けます。置き換え、補足、衝突、確認待ち、という形です。

ここではシンプルな schema で十分です。最初から複雑なグラフデータベースを買う必要はありません。Postgres のテーブル、JSONB、全文インデックス、ベクトル拡張でも小さな検証はできます。Hyper の公開議論でも、構造化メタデータとグラフ的な関係を近い場所で扱えるため、この種のシステムでは Postgres が便利だと触れられていました。

5〜6 日目：コンテキストを注入し、タスクをリプレイする

Agent にツールまたは hook を追加します。現在のタスクを入力すると、出典つきで 5〜15 件の関連 facts を返すものです。その後、20 件の実タスクをリプレイし、3 つの数字を記録します。

• 人が背景説明を追加する回数は減ったか。
• Agent が古い fact や間違った fact を引用する回数は減ったか。
• 権限外の fact が出たか、広すぎるコンテキストで脱線したか。

出力がきれいかどうかだけを見ないでください。company brain の価値は、説明の繰り返しを減らし、古い情報の誤用を減らし、証拠が足りないときに Agent を慎重にすることです。

7 日目：拡大、停止、方向転換を決める

20 件のタスクのうち、効果が出たものが少ないなら、まだ全社展開しないほうがよいです。ワークフローが合っていないのかもしれませんし、fact 抽出が粗すぎるのかもしれません。逆に、追質問が明らかに減り、古い fact の引用も減り、権限外の取得がなければ、会議メモや選別済み Slack チャンネルなど、もう 1 つ情報源を増やしてもよいでしょう。

次の段階では、AI Agent の監視と自己回復 と組み合わせます。低信頼度の fact、衝突中の fact、高リスク action が使われたら、人手確認に回す設計です。

導入前にリスクを明文化する

会社知識ベースが Agent に接続されると、それは単なる情報検索プロジェクトではなくなります。いくつかのリスクは、早めに計画へ書き込むべきです。

1 つ目は、プライバシーと学習利用の境界です。Hyper の創業者は HN コメントで、ホストされたデータを学習に使わず、販売もしないと述べ、FAQ とプライバシーポリシーを案内していました。ただし、こちらのクローラーでは公式プライバシーページ本文を読めなかったため、細かい条項までは推測しません。チームはローンチ投稿だけで判断せず、契約、データ処理条項、保持期間、削除フローを確認するべきです。

2 つ目は、hook の透明性です。自動コンテキスト注入は、Agent が MCP を呼ぶことを期待するより安定しています。しかしユーザーは、自分のマシンに何がインストールされ、いつ動き、何を読むのかを知る必要があります。インストール通知、実行ログ、無効化スイッチ、見える設定は明確であるべきです。

3 つ目は、履歴汚染です。成熟した会社には、互いに矛盾する古い文書がよくあります。新しいものが常に権威を持つとは限りません。法務、財務、宗教、行政手続きでは、古い文書こそ規範である場合もあります。単純に「新しいほど信頼できる」とはできません。情報源や役割ごとに重み付けを変える必要があります。

4 つ目は、ベンダーロックインです。company brain を長く使うほど、それは会社のオペレーティングシステムの一部に近づきます。エクスポート形式、バックアップ戦略、セルフホストの選択肢、障害時の離脱計画は早めに確認するべきです。それがないと、短期的には快適でも、長期的には詰まります。

システムが「不確かです」と言えるようにする

Hyper が押し出している方向性は良いと思います。Agent がチームのワークフローに深く入るなら、普通の文書検索より安定した会社コンテキストが必要です。ただし、導入は地に足をつけるべきです。全社ブレインと呼ぶ前に、システムが古い fact と新しい fact を区別でき、出典へ戻れ、権限で絞り込め、人手修正を受け入れ、証拠が薄いときに「不確かです」と言えるかを確認しましょう。

小規模チームなら、狭いワークフローから始められます。低リスクの情報源を 3 種類、数十件の facts、20 件の実タスク。まずそれを回し、その後で拡大するか決める。派手ではありませんが、成果を出す必要がある Agent には、そのほうがずっと実用に近いはずです。