company-brain

/company-brain — チーム共有のAI対応ナレッジベース

Company Brain (名詞)：チームで共有する、AI対応のナレッジベースです。人、企業、会議、SOP、意思決定を構造化し、Claudeがチームに代わって質問に回答できるようにします。

second-brain（個人向け）に対する、チーム向けの兄弟プロジェクトです。基本となる「コンパイル → wiki → 出力」のパターンは同じですが、複数の作成者による、営業や運用を重視したチームでの利用に最適化された、異なる raw スキーマを使用します。

また、Company Brain Setup というプロダクト化されたサービスの運用基盤でもあります（以前は「Second Brain as a Service」と呼ばれていましたが、スキル名に合わせて変更されました）。

メンタルモデル

second-brain と同じ3層構造ですが、raw/ レイヤーはフラットではなく、構造化されています。

raw/          →  wiki/         →  outputs/
(structured      (compiled        (generated
 by category)     interlinked)     artifacts)

構造化された raw/ ディレクトリ（各ディレクトリは vault 内のトップレベルフォルダーです）：

ディレクトリ	格納されるもの
people/	背景情報を含む連絡先情報 — 軽量なCRMです。人物ごとにMarkdownファイルを1つ作成します。
companies/	組織のプロフィール — 最終接点、案件規模、ステータスです。企業ごとにファイルを1つ作成します。
meetings/	通話／会議の文字起こしとメモです。命名規則：YYYY-MM-DD-<company-or-topic>-<slug>.md。自動同期のソースです。
sops/	標準業務手順書です。命名規則：<team>-<process>.md（例：sales-outbound-cadence.md）。
decisions/	意思決定の記録（文章形式。decide スキルの構造化形式とは異なります）。
customer-language/	見込み客／顧客／ユーザーの発言をそのまま記録したフレーズです。コピー、見出し、異議への対応に役立ちます。
recurring-questions/	通話中に3回以上尋ねられた質問です。それぞれを、回答済みのSOP／FAQ／スクリプトにします。
sales-objections/	異議と最適な回答のライブラリです。営業スクリプトの作成に使用します。
raw/	旧形式／未分類の記録（フォールバック用の格納先です。使用は最小限にしてください）。

wiki/、outputs/、INDEX.md は second-brain と同じように機能します。

予約済みディレクトリ（company-brain は変更しません）：Projects/、Team/、Templates/、Drafts/。

複数の作成者による運用ルール

すべての記録に、以下の情報を付与します。

source: <URL / call / email / manual entry>
author: <who added this — email or handle>
captured: YYYY-MM-DD
trust: unreviewed

Wikiページでは、## Sources セクションで累積した貢献を記録します（ソースファイルごと、作成者ごと）。上書きせず、必ず追記して貢献者を明記します。

機密性のタグ付け（任意ですが推奨）：

sensitivity: internal        # any team member can read
sensitivity: leadership      # exec team only
sensitivity: confidential    # named list only (list access in the file)

デフォルトは internal です。クエリモードでは機密性が考慮され、呼び出し元がアクセスリストに含まれていない場合、confidential の内容は回答に含めません。

信頼レベル

複数の作成者による運用ルールを支えるもう一つの要素は、記録されたすべての情報が、コンテキストとして同じ重みを持つわけではないという点です。構造化 raw ファイルにはすべて、trust: フィールドが含まれます。

フィールド名を status ではなく trust としているのは、companies/ と decisions/ ではすでにライフサイクル（見込み客／顧客、決定済み／撤回済み）を示す status: を使っており、両者が衝突しないようにするためです。

信頼レベル	意味	クエリでの扱い
unreviewed	記録済みですが、人間による確認はまだありません（新しい記録のデフォルト）	使用できますが、注意が付与されます。この情報に依拠する回答では、信頼度が低いことを示します
verified	人間が確認し、正しいと検証済みです	通常の重みで扱います
deprecated	誤り、または古くなっています。履歴としてのみ保持します	コンテキストとして使用しません
superseded	新しい情報に置き換えられています — superseded_by: [[target]] を追加します	コンテキストとして使用せず、クエリでは置き換え先を示します

数値の重みではなく、意図的に列挙型にしています。チームが4つの値を最新の状態に保つのは容易ですが、0～1の浮動小数点数を管理する人はいません。

削除の代わりに非推奨としてマークします。「raw ファイルを削除しない」というルールは引き続き有効です。情報が誤りだと判明した場合や古くなった場合は、削除せずに deprecated（または参照先を付けて superseded）とマークします。履歴を保持し、コンテキストを保護します。

信頼レベルと機密性は独立しています。ファイルには verified と confidential、または unreviewed と internal を設定できます。

既存の vault：信頼レベルの導入前に作成されたファイルには trust: フィールドがありません。その場合は unreviewed として扱います。vault のスキーマドキュメント（CLAUDE.md／AGENTS.md）が信頼レベル導入前のものであれば、最初の /cb review 実行時に信頼レベルの仕様を追加するか確認します（vault の CLAUDE.md が引き続き正本です。置き換えるのではなく、拡張してください）。

Step 1 — ボールトの設定とスキーマを読み込む

1. references/vault-config.mdを読み、ボールトのパスを確認します（デフォルト：${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/）
2. ボールトのスキーマ文書を読みます。<vault>/CLAUDE.mdまたは<vault>/AGENTS.mdのうち存在するものを読みます（両方ある場合は両方読みます）。これが正式なチームスキーマです。存在する場合はreferences/schema.mdより優先してください。チームのボールトが信頼できる情報源です。
3. どちらも存在しない場合は、チームスキーマのスターターキットであるreferences/schema.mdを使用します。

Step 2 — モードを解析する

呼び出し	モード
/cb capture / /company-brain capture / "チームのナレッジベースにこれを記録して"	capture
/cb compile / "会社の Wiki をまとめて"	compile
/cb query <q> / "チームは X について何を知っていますか"	query
/cb review / "会社のナレッジベースをレビューして" / "チームのナレッジベースを整理して"	review
/cb lint / "会社のナレッジベースを lint して"	lint
/cb connect / "チーム間のつながりを探して"	connect
/cb search <term> / "会社のナレッジベースを検索して"	search

Step 3 — モードを実行する

capture

取り込み方法はsecond-brainと同じですが、振り分け先が異なります。内容の種類に応じて、適切な構造化ディレクトリを選択してください。

1. 内容の種類を判定し、適切なディレクトリに振り分けます：

   • 通話／会議の文字起こし → meetings/YYYY-MM-DD-<company-or-topic>-<slug>.md
   • 人物のLinkedIn／プロフィール／連絡先のコンテキスト → people/<name-slug>.md
   • 会社のプロフィール／見込み客／クライアント → companies/<company-slug>.md
   • 文書化されたプロセス／「Xのやり方」 → sops/<team>-<process>.md
   • 経営陣／チームが下した決定 → decisions/YYYY-MM-DD-<decision-slug>.md
   • 顧客の逐語的な引用 → customer-language/<theme-slug>.md（既存のテーマ別ファイルがあれば追記します）
   • 通話中に尋ねられた質問 → recurring-questions/<question-slug>.md（繰り返しの場合はカウンターを追記します）
   • 聞いた営業上の反論 → sales-objections/<objection-slug>.md（繰り返しの場合はバリエーションを追記します）
   • 判断が難しい場合は、質問します。
   • 保存先のディレクトリがまだない場合は、今回の記録とともに作成します。新しいボールトでは、まず1つのパイロットワークフロー用のディレクトリだけを作成します（references/vault-config.md →「Start narrow」を参照）。

2. 複数著者のメタデータを追加します（ファイルの先頭）：

   source: <URL / call with X on YYYY-MM-DD / email from Y / etc.>
   author: <who captured this>
   captured: YYYY-MM-DD
   trust: unreviewed      # every capture starts unreviewed — review mode promotes it
   sensitivity: internal  # or leadership / confidential
   

3. ファイルを保存し、ファイルパスと1行の要約を報告します。

ここでは Wiki にまとめません。captureは迅速な取り込みのためのモードです。

compile

second-brainのcompileモードと同じ基本パターンです。未処理の構造化されたrawファイルをWikiページにまとめ、INDEX.mdを更新し、Sourcesセクションを追加します。

second-brainとの違い：

• 複数著者の明記：Sourcesセクションには、ファイル名だけでなく著者も含めます

  ## Sources
  - `people/jane-doe.md` (added by @alex, 2026-06-30) — CTO of Acme, evaluated us Q2
  

• カテゴリをまたいだコンパイル：「Acme Corpとの取引」に関するWikiページでは、companies/acme.md、meetings/2026-06-15-acme-discovery.md、sales-objections/acme-pricing.md、people/jane-doe.mdの情報を1つのWikiページにまとめる場合があります。
• 機密性の継承：Wikiページは、ソースの中で最も高い機密性を継承します。いずれかのソースがconfidentialの場合、Wikiページもconfidentialになります。
• 信頼性に基づくフィルタリング：deprecatedおよびsupersededのソースはWikiページから除外します。すでにWikiページに取り込まれたソースが後からdeprecatedになった場合、再コンパイル時に影響を受けるページを再レビュー対象としてフラグ付けし、そのソースを除外します。Sourcesにはファイルのreviewedおよびreviewed_byスタンプを使って、次のように記載します：- meetings/2026-06-15-x.md (deprecated 2026-07-01 by @alex)。主にunreviewedのソースから作成されたページには、先頭に> ⚠ Mostly unreviewed sourcesの注意書きを追加します。
• チーム用のINDEX.mdカテゴリ：Sales、Customers、Ops、Product、Team & People、Decisions、Playbooks。必要に応じて拡張してください。

その他のすべて（概念ごとに1ページ、[[wikilinks]]、Connectionsは必須、量より質）は同じです。

query

second-brain query と同じですが、以下が追加されます。

• 最初に機密性を確認：呼び出し元を特定し、その機密性レベルを超えるコンテンツは含めないようにします。
• 信頼性に関するルール：unreviewed より verified を優先し、古い情報より新しい情報を優先します。deprecated または superseded のコンテンツはコンテキストとして使わないでください。参照先として引用する場合に限り、最大でも 「(deprecated — [[replacement]] を参照)」 と記載します。情報源が矛盾する場合は、新しく信頼性の高いほうを優先し、回答でその食い違いを明示します。
• 信頼度フラグ：回答が主に unreviewed の情報源に基づく場合は、冒頭でその旨を伝えます。「信頼度は低めです — 4 件中 3 件の情報源が unreviewed です。情報の確度を高めるには、/cb review を実行してください。」
• 著者を考慮した回答：引用時には、情報の提供者を含めます。「[[Acme Deal]]（情報源：meetings/2026-06-15-acme-discovery.md、@alex 作成）によると……」
• 外部情報の不足分は deep-research に回す：second-brain と同様です。

回答、参照した wiki ページ、出力の機密性レベルを outputs/<YYYY-MM-DD>-<question-slug>.md に保存します。

review

人間による選別作業です。 チームが、取り込んだノイズがそのままコンテキストに混入するのを防ぐための仕組みです。すべての情報を自由に取り込み（何も失われません）、レビュー済みの情報だけが最大限に重視されます。

0. 最初に機密性を確認 — query モードと同じルールを適用します。呼び出し元を特定し、その機密性レベルを超えるファイルはキューから除外します。除外件数を報告します。「機密性レベルを超える項目 3 件をスキップしました — リーダーシップリストに登録されたメンバーによるレビューが必要です。」

1. トリアージキューを作成：

   • 構造化 raw ディレクトリにある trust: unreviewed の全ファイル（trust: フィールドがないファイルも含む）。新しいものから順に並べます。
   • lint でフラグが立ったすべての項目（チェック 1〜12。チェック 13 は review 自体に関するものです）。
   • レビュー日が過ぎているファイル（該当するフィールドがある場合）：review_by を過ぎた decisions/ ファイル、last_reviewed + review_cadence の期限を過ぎた sops/ ファイル。

2. キュー内の項目を 1 件ずつ確認します。 各ファイルについて、1 行の要約、情報源、著者、取り込み日、参照している wiki ページを表示します。次の 4 つの処理を提示します。skip 以外の処理では、すべて reviewed: YYYY-MM-DD + reviewed_by: <handle> を付与します。

   • verify → trust: verified
   • deprecate → trust: deprecated（誤りまたは古くなった情報。履歴として保持します）
   • supersede → trust: superseded + superseded_by: [[target]]（置き換え先を確認します）
   • skip → 変更せずに残し、次回のレビューで再度表示します。

3. frontmatter の更新をまとめて適用 — ファイル本文は書き換えず、メタデータブロックのみを更新します。

4. 下流への影響を示す：deprecated / superseded のファイルが既存の wiki ページに反映されている場合、そのページを列挙し、すぐに再コンパイルするかどうかを確認します。

5. 要約で締めくくる：「12 件をレビューしました：8 件を verified、3 件を deprecated、1 件を superseded にしました。wiki ページ 2 件を再コンパイルしました。次回のレビュー推奨日：。」 レビュー自体の監査記録として、要約を outputs/<YYYY-MM-DD>-review.md に保存します。

実施頻度：アクティブな vault では毎週です。忘れずに実施できるよう、loopify と組み合わせてスケジュールしてください。レビューが 1 か月以上滞っている vault は、lint のチェック 13 に表示されます。

lint

second-brain と同じ 7 件のチェックに加えて、以下を実施します。

8. 古くなった人物／企業情報 — アクティブなアカウントについて、people/ または companies/ のファイルが 6 か月以上更新されていない
9. しきい値を超えた繰り返し質問 — 5 回以上質問されているものの、wiki ページまたは SOP がない質問
10. 対応のない反論 — sales-objections/ のファイルに、sops/ または wiki/ の対応策へのリンクがない
11. SOP の鮮度 — 12 か月以上更新されていない SOP（ビジネスの進化に伴い、古くなっている可能性があります）
12. 著者の負荷の偏り — 1 人のコントリビューターが取り込みの 80% 超を担当している（通常、vault が 1 人に依存していることを示します。チームの継続性にとって好ましくありません）
13. レビューの滞留 — trust: unreviewed のファイルが 20 件を超えている、または 1 か月以上レビューが行われていない（outputs/*-review.md がない）。/cb review の実行を促します。

connect

second-brain と同じですが、カテゴリーをまたいだリンク候補も提案します。たとえば、sales-objections/pricing-too-high.md が存在する場合、customer-language/willingness-to-pay.md と sops/discovery-call-cadence.md へのリンクを提案します。

search

同様です。構造化されたすべての raw ディレクトリと wiki/ を対象に grep します。

オプション：ソースの自動同期

チームの Vault では、情報を自動で取り込むと便利です。セットアップ方法については、references/auto-sync-sources.md を参照してください。

ソース	取り込む内容	セットアップ
Fathom / Gong / Granola	通話・会議の文字起こし	Webhook → meetings/ に追記
Slack export	保存する価値のあるチーム内の議論	手動または定期エクスポート → raw/slack-<channel>-<date>.md
Email (Front / Missive / Superhuman)	保存する価値のある顧客対応スレッド	指定アドレスへの転送 → people/ または companies/ に追記
CRM (HubSpot / Attio / Pipedrive)	商談の状態、連絡先情報	定期同期 → companies/ + people/

自動同期は任意です。ほとんどのチームは手動での記録から始め、Vault が成熟してから自動化を追加します。loopify と組み合わせると、定期的な同期ジョブをスケジュールできます。

マルチライターの Git 同期（チームメンバー + リモートエージェント）

チームの Vault は定義上、複数の書き手が使うものであり、Git が調整レイヤーになります。Vault をホスト型リモート（GitHub/GitLab）に置くと、リモートはファイルシステムにアクセスできないエージェント向けの記録 APIも兼ねます。対象は、クラウドエージェント、スケジュール済み同期ジョブ、チームメンバーのマシンです。Git ホストの API にアクセスできるもの（直接、または Executor のような MCP 統合レイヤー経由）なら、Wiki を読み取り、構造化された raw ディレクトリに記録をコミットできます。

書き手同士の情報の不整合を防ぐためのルールは次のとおりです。

1. ローカルで作業するセッションは、書き込み前に必ず pull します。Vault の作業前に git pull --rebase --autostash を実行し、コミット後に push します。人間とエージェントの両方がコミットする環境では、ローカルコピーはすぐに古くなります。
2. Obsidian ユーザーの場合：コミュニティの Git プラグインで、一定間隔（約 10 分）での自動 pull と起動時の pull を有効にし、自動コミットはオフにします。コミットは意味のある単位（記録またはコンパイルごとに 1 件）に保ち、「Vault のバックアップ」のようなノイズを避けてください。これは一部のメンバーだけでなく、チームメンバー全員のマシンで設定する必要があります。
3. リモートエージェントと自動同期ジョブは、追記を基本としてコミットします。構造化ディレクトリに新しいファイルを追加し、内容が分かるコミットメッセージを付け、記録のフロントマターに作成者を記載します（複数の作成者を前提とする信頼モデルに必要です）。別々のファイルへの追記で競合はまれになり、残った競合も rebase で解消できます。

オンボーディング時に各マシンで一度、同期の流れを確認してください。API 経由でリモートからコミット → ローカルで pull → ファイルが表示されること。

他のツールとの組み合わせ

• second-brain — 関連するツールです。個人用 Wiki には second-brain、チーム用には company-brain を使います。Vault のパスを分ければ、1 人で両方を同時に管理できます。
• skillify — company-brain から情報を読み取る新しいスキルの作成に使います（例：毎週月曜日に company-brain を検索する weekly-team-brief スキル）。
• loopify — 自動同期ジョブをスケジュールします（Fathom の日次取り込み、Slack エクスポートの週次実行、週次レビュー、月次の INDEX lint）。
• toolify — company-brain に情報を取り込む連携を設定します（Fathom の Webhook 受信、Attio API など）。
• deep-research — query で情報の不足が見つかった場合は、外部の情報を調査します。今後のコンパイルに備え、deep-research の結果を raw/ に保存します。
• decide — decisions/ フォルダーは、decide の構造化されたアーカイブを補完します。decide は評価を記録し、decisions/ は経緯 + 結果 + 振り返りメモを記録します。
• pm — チームのタスク管理には Projects/ を使います（company-brain の対象外として予約されています）。Projects/ は pm が管理し、company-brain はコンテキストとして読み取りますが、変更はしません。
• jab-hook — customer-language/ を活用し、見込み客が実際に使う表現に響くソーシャル向けコピーを作成します。
• ブログの下書きを作成するスキル（独自のもの、または連携プラグイン）— customer-language/、recurring-questions/、sops/ を参照し、信頼性の高いブログ記事の下書きを作成します。

関連する実装（参考）

second-brain と同じ系譜です。

• Gbrain — Garry Tan 氏のチーム規模のブレイン（14.6 万ページ、2.4 万人の人物エンティティ）。Postgres/PGLite をバックエンドとし、グラフ探索と定期メンテナンスに対応しています。チームのカンパニーブレインが Markdown のみでは手狭になったとき、Gbrain がアップグレード先になります。
• Hermes の llm-wiki — 3 フォルダパターンの参考になります。
• Notion AI / Glean / Mem — 商用の「Company OS」ツールです。Company-brain は Claude ネイティブで Markdown ファーストの代替手段です。より安価で、移植性に優れ、すでに Obsidian / Git 管理のドキュメントを中心に作業しているチームに適しています。

品質に関する注意事項

• チーム規模では、構造化された生データがフラットな生データに勝ります。 Second-brain の型プレフィックスは個人には有効ですが、チームでは複数の作成者による検索を高速に保つために、人物、企業、会議などの専用ディレクトリが必要です。
• 複数の作成者の帰属情報は必須です。 すべてのファイルに author: と captured: を記録します。Wiki ページでは、ソースと作成者を明記して引用します。
• 機密性は最初から最後まで尊重されます。 クエリモードでは、呼び出し元のレベルを超えるコンテンツは含めません。Wiki ページは、ソースのいずれかで最も高い機密レベルを引き継ぎます。
• 生ファイルは決して削除しないでください。 second-brain と同じルールです。構造化ディレクトリが信頼できる唯一の情報源です。情報が誤っている、または古くなっている場合は、削除ではなく非推奨にします。trust: deprecated に設定すると、履歴を保ったままコンテキストから除外されます。
• 自由に取り込み、慎重に重み付けします。 信頼度の列挙型により、情報を投入しても安全です。未レビューの情報が最大の重みで回答を汚染することはなく、/cb review による定期的な整理で情報を昇格または引退させます。
• 対象を絞って始め、拡大は実績を得てから行います。 収益に関連するワークフローを 1 つ選び、そのディレクトリを用意して、1〜2 人で試験運用します。クエリに回答が得られ、レビューが機能するようになってから対象を広げてください。references/rollout.md を参照してください。
• company-brain の運用中に Projects/、Team/、Templates/、Drafts/ を変更しないでください。
• 自動同期は任意です。 まずは手動で始め、ボルトが成熟してから自動化してください。チームが定期的に手動で会議を記録するようになる前に、Fathom の Webhook に工数を費やさないでください。
• ボルト全体を 1 人に依存させないでください。 lint で作成者の負荷の偏りが 80% を超えていると警告された場合、そのチームはブレインを失うまであと 1 人分しか余裕がありません。貢献者を増やしてください。