コードから構築される
ノード、エッジ、モジュールの境界は、コードが実際にインポートしている内容 —— ルート、関数、コンポーネント、テーブル —— から生まれます。手描きで、いつの間にか実態からずれていく図ではありません。
Codebase Brain
あなたのアーキテクチャを、生きたグラフとして。
リポジトリ、モジュール、依存関係、誰が何を担当しているか —— すべてコード自体から読み取ったもので、誰かが2023年に描いた図ではありません。プッシュのたびに自動的に再構築され、実際に活動しているクラスタは光ります —— だからこの地図は、ウィキに貼られた古びた画像になることがありません。そしてこれはすべて、顧客と収益と同じ基盤の上にあるので、「この機能は実際に何に影響するのか？」という問いに、ついに答えが出ます。
表示しているのは実際のAIOProductOSのコードベースです —— 私たち自身の会社もこの上で動いています。
コードベース・ブレイン
あなたのプロダクトを —— コードも含めて —— 理解している
あなたのアーキテクチャを、顧客や収益と同じ基盤の上にある生きたグラフとして。クリックして、何ができるか見てみてください。
あなたのアーキテクチャをグラフとして
- 機能ごとにモジュールをクラスタ化し、依存関係を弦で表現
- プッシュごとに自動で再構築 —— 古びたウィキの図とは無縁
自分で自分を書き上げるドキュメント
- コードグラフから生成され、常に同期されている
- 誰もウィキを管理する必要がない
生きている場所を教えてくれる
- 実際に活動しているクラスタは光る
- 作業が実際にどこで行われているかが見える
顧客レコード上のコード
- ある機能から、それを届けているコードまでたどれる
- ……そしてそれに依存する収益まで
表示しているのは実際のAIOProductOSのコードベースです —— 私たちもこの上で動いています。
地図
すべてのモジュールが、実際の姿のまま結びつく。
コードベース全体を一つのインタラクティブなグラフに: モジュールは機能クラスタごとにまとめられ、依存関係は弦のように編み込まれ、それぞれのパーツの重要度に応じてサイズが決まります。モジュールをクリックすればその結びつきが開き —— コードが変わればグラフも自動で再構築されます。
ノードに載る担当情報
各モジュールには、誰が担当しているか、何ファイルあるかが載っています。新しいエンジニアは、口伝えの暗黙知ツアーの代わりに地図を手にできます。
重み付きの依存関係
モジュール間のエッジは、どれだけ強く互いに依存しているかを示します —— 触れる前に、何が壊れるかが見えます。
自分で最新の状態を保ちます: 地図はプッシュごと、そして1日2回、GitHubコネクタから直接再構築されます —— CIを組む必要もなく、図を維持する必要もありません。今すぐ見たい場合は、いつでも手動で更新できます。
生きたドキュメント
自分で自分を書き上げるドキュメント。
グラフから直接生成されるモジュールごとのドキュメント: そのモジュールが何のためにあるか、何で構成されているか、最もつながりの多いパーツ、所有しているテーブルとRPC、そして何に依存しているか。リポジトリから抽出されたREADMEもすぐそばに並びます。
- ✓決定論的 —— グラフから計算されるだけで、モデル呼び出しもトークン費用も発生しません。
- ✓常に最新: グラフが再公開されるたびに、ドキュメントはすでにそれと一致しています。
- ✓モジュールごとの「依存している/使われている」—— 結びつきを、ピクセルだけでなく文章でも伝えます。
codebase / docs / connectors
connectors — 546個の構成要素
routes 38 · functions 412 · mappings 51 · tables 9
- · stripe/route.ts — 顧客とMRRを遡って反映
- · github/mapping.ts — リポジトリ、言語、活動状況
- · sentry/mapping.ts — エラー → 作業項目
db · webhooks
pm · analytics · modules
コードグラフから生成 · サンプルデータ
codebase / inventory
- route api/connectors/stripe connectors 64
- table analytics_event db 58
- function stitchIdentity db 41
- component BoardView pm 37
- route api/codebase/brain/refresh codebase 22
TypeScript 68% · SQL 22% · その他 10%
接続数で並べ替え —— 重要度の高いものから · サンプルデータ
インベントリ
すべてのコード資産を、検索できる一つのカタログに。
グラフ上のすべてのノードを、種類・名前・モジュール・ファイル・接続数を持つフラットで絞り込み可能なリストとして —— 重要度の高いものから並べます。同じソースから生まれる、地図の表形式版の分身なので、決してズレることがありません。
- ✓種類、モジュール、名前で検索・絞り込み —— まず構成要素を見つけ、そのファイルを見つける。
- ✓同期されたすべてのリポジトリを横断して集計した言語比率。
- ✓コードホストごとの活動状況、公開範囲、スター数、未解決issueを備えたリポジトリ一覧。
何がデータを供給しているか
コードホスト3種を接続。デプロイ、エラー、スキーマも並んで。
すでに使っているエンジニアリングのスタックを接続してください。アーキテクチャグラフはGitHubから構築されます —— 接続すれば地図が現れ、あなたの側でCIやdevopsを組む必要はありません —— 一方でデプロイ、エラー、スキーマは同じ基盤の上に並んで届きます。
GitHub · GitLab · Bitbucket
アーキテクチャグラフは現在GitHubから構築され、TypeScript/JavaScript + Supabaseで最も深く対応しています。GitLabとBitbucketは、収益のすぐそばで、基盤上にリポジトリのメタデータを同期します。
Vercel · Netlify · Cloudflare
プロジェクト、環境、状態、ブランチ、コミットを含むデプロイのタイムライン。ある機能が実際にいつリリースされたかがわかります。
Sentry
本番環境のエラーはスタックトレース付きの作業項目として届きます —— アカウントや機能に結びつけられるリアルタイムのエラーフィードです。
Supabase · Firebase
スキーマとアクセス態勢 —— テーブル、ポリシー、認証設定。顧客のデータ行そのものを読むことは決してありません。
Inngest
非同期ジョブ、失敗、リトライが、目に見える作業項目になります —— システムの見えていなかった半分も、記録に残ります。
Zapier · webhook
基盤上のイベントが外向きのwebhookを発火させ、他のツールがポーリングなしで反応できるようになります。
各データソースはコネクタ単位で届きます —— 一つ接続すればそのデータが流れ始め、さらに接続すれば全体像がより完成していきます。
ひとつの基盤
コードは一方に、顧客はもう一方に。同じレコードの上で。
多くのチームは、アーキテクチャを一つのツールに、収益を別のツールに置き、その間には何もありません。ここでは、リポジトリ、デプロイ、エラーが、すでにアカウント・サブスクリプション・フィードバックを抱えている基盤の上に届きます。だから、機能、その裏側のコード、そしてそれを待っている顧客は、もう別々の3つの問いではなくなります。
正直に言うと: コードデータはコネクタ単位で基盤に結びつきます。Sentryのエラーは現在作業項目として届いていますが、顧客ごとのより充実したコードビューは、各ジョインが実装されるたびに順に有効になっていきます。
ノード1,734 · エッジ4,217 · モジュール36
このページの一番上にあるグラフは、私たち自身のものです。これはAIOProductOSのアーキテクチャマップの実際の数字です —— 私たちのチームがエンジニアをオンボーディングし、ある変更が何に影響するかを判断するために開く、まさに同じ画面です。私たちはコンセプトのデモをしているのではなく、自分たちのコードベースをお見せしているのです。
FAQ
よくある質問
Codebase Brainは何を見せてくれますか？
あなたのアーキテクチャをインタラクティブなグラフとして —— リポジトリ、モジュール、依存関係、担当者 —— さらに完全なコード資産インベントリと自動抽出されたドキュメントもあわせて表示するので、コードを読み進める代わりにシステム全体を見渡せます。
どのツールがデータを供給していますか？
アーキテクチャグラフはあなたのGitHubリポジトリから構築されます —— GitHubを接続すればそれが現れ、あなたの側でCIやdevopsを組む必要はありません。その隣、同じ基盤上には: GitLabとBitbucketのリポジトリメタデータ、Vercel・Netlify・Cloudflareからのデプロイ、そしてSentryからのエラー —— これらが顧客と収益のすぐそばに並びます。
ドキュメントはどこから来るのですか？
マッピングされたコードベースから自動的に抽出されるので、ドキュメントはウィキのように古びていくのではなく、実際のモジュールとその関係を反映し続けます。
なぜプロダクトOSの中でコードをマッピングするのですか？
収益やプロダクトの作業と同じ基盤の上にあるからです —— そのおかげで、モジュールは単なるコードではなく、それが仕えている機能や顧客と結びつきます。それが「なぜ」であり、収益とコードという言葉で表されます。
自分で最新の状態に保つ必要がありますか？
いいえ。GitHubを接続すれば、地図はプッシュごと、そして1日2回、CIやdevopsの設定なしに自動で再構築されます。実際に活動しているクラスタは光るので、作業が実際にどこで行われているかが反映されます。それでも、必要なときにいつでも手動で更新できる手段は残っています。