コードに対応する図
EraserやWhimsicalは見栄えのいい箱を描くだけ。エンジニアは結局、締め切りに間に合うものを作ります。Bobの図は、Alexが実際にコードベースで使うファイル構成とモジュール境界になります。
Bob·Architectチームが構築するシステムを設計するAIアーキテクトエージェント
Bobがシステムを設計し、スタックを選定し、その構造をAlexに引き渡すことで、あなたのアーキテクチャは忘れ去られたドキュメントではなく、コードベースそのものになります。
コードに対応する図。きれいなだけの絵ではありません。
アーキテクチャドキュメントが書かれたその日に古くなってしまう理由
誰も実装しない見栄えのいい図
Eraser や Whimsical は美しいボックスと矢印を描きます。ですが、エンジニアは結局、締め切りに間に合うものを作ります。Bob の図は、Alex が実際に使うファイル構造とモジュール境界になります。
流行で決まるスタック選定
「人気だったから Mongo を選びました。」Bob は、なぜ Mongo より Postgres なのか、なぜ直接呼び出しよりキューなのか、なぜ Memcached ではなく Redis なのかを説明します。その理由は文書として残るので、あとから検証や異議申し立てができます。
アーキテクチャとコードが乖離する
Wiki の図はスプリント 1 時点のもの。コードはスプリント 14 時点のもの。どちらも一致するように更新する人はいません。Bob は現在のシステムをレビューし、実際にリリースされている内容を反映するようにアーキテクチャ文書を更新します。
非機能要件がリリース後に発覚する
パフォーマンス、セキュリティ、オブザーバビリティは、最初の障害が起きた後に後付けされがちです。Bob は設計段階でそれらを計画し、Emma のスケール要件と、データモデルがサポートすべきアクセスパターンを踏まえて設計します。
Bobとの1日
最初のプロンプトからリリース済みの成果まで — Bob が実際にどう機能するのかをご紹介します。
- 01
- 02
理由を持ってスタックを選ぶ
データベース、フレームワーク、キュー、キャッシュ——それぞれの選定には、異議を唱えられるよう書面のトレードオフ説明が付いています。
- 03
データモデルとモジュール境界を整理する
エンティティ、リレーションシップ、所有権、書き込みパス——あとでリファクタリングが痛くなる部分です。
- 04
コードに対応するシステム図を描く
ボックスと矢印は実際のモジュールと依存関係を反映しており、コードが実装されても図は同期されたままです。
- 05
Bob が堅牢なシステムを設計するために必要なすべて
アーキテクチャ図
サービス、データフロー、および統合図は、別のツールではなくEditor内で生成されます。
技術スタックの推奨
スタックの選定は、流行や慣れではなく、あなたの制約条件に照らして正当化されます。
データモデル設計
スキーマとリレーションは、プロダクトの実際のアクセスパターンに合わせて設計されます。
非機能要件の計画
パフォーマンス、セキュリティ、可観測性は、ローンチ後ではなく設計段階で対応されます。
意思決定ログ
アーキテクチャ上の意思決定は、その理由とともに記録されるため、将来の自分が見直せます。
構造からコードへのマッピング
図は、Alexが構築するファイル構造とモジュール境界に対応しています。
アーキテクチャレビュー
Bobは既存システムをレビューし、明確な根拠とともに変更提案を行えます。
Bobがチームに加わると何が変わるか
手作業のワークフローは遅く、手動で、ツールに大きく依存します。各カードにホバーすると、それぞれの改善が重要な理由を確認できます。
なぜビルダーたちは他ではなくBobを選ぶのか
比較
Eraser AI から乗り換えですか？Bob が優れているポイントはこちらです。
流行りではなく、根拠にもとづくスタック選定
ChatGPT は、学習データで最もよく見かけたフレームワークを勧めます。Bob は、Mongo ではなく Postgres を選ぶ理由、直接呼び出しではなくキューを使う理由、Memcached ではなく Redis を選ぶ理由を説明します。しかも、その根拠は検証でき、判断も後から見直せます。
常に最新の状態を保つアーキテクチャ
Wiki の図はスプリント 3 までには古くなります。Bob は実際のコードをレビューし、リリース済みの内容に合わせてアーキテクチャを更新します。つまり、ドキュメントが机上の空論になることはなく、新しいエンジニアのオンボーディングも 1 か月ではなく 1 日で済みます。
Atoms と Eraser AI：機能、価格、機能を比較する
| 機能 | Atoms 推奨 | Eraser AI |
|---|---|---|
| 出力 | コードに落とし込めるアーキテクチャ | Wiki内の図 |
| 根拠あるスタック選定 | 明文化されたトレードオフ | 一般的な提案 |
| コードのリリースに合わせて同期を維持 | コードベースに照らして更新済み | スプリント3までには古くなる |
| エンジニアリングに接続 | Alexに引き継ぐ | エクスポートで引き継ぐ |
| 図の作成 | 自動生成 | 自動生成 |
Bob がAIチームの他のメンバーとどのように連携するか
Bob は単独で動くわけではありません。フルチームで構築する際に、引き継ぎがどのように行われるかをご紹介します。
Bobが建設業者向けに設計するもの
Bob が生み出す、実際のコードに対応する具体的なアーキテクチャ作業。
- システムを設計する
グリーンフィールドなシステム設計
制約条件に照らして技術スタックの選定理由を明確にしながら、システムをゼロから設計します。
- スタックを選ぶ
スタック選定
プロジェクト向けのスタック候補を比較し、チーム体制とスケールに合ったものを選びます。
- スキーマを設計する
データモデル設計
プロダクトで実際に実行されるクエリに合わせて、スキーマ、リレーション、インデックスを設計します。
- 連携を整理する
連携マッピング
連携作業を始める前に、サードパーティサービス、Webhook、データフローを整理して可視化します。
- スケール計画を立てる
パフォーマンスとスケーリング計画
本番環境で問題になる前に、ボトルネックを特定し、次の桁の成長に向けた計画を立てます。
- セキュリティを確認する
セキュリティとコンプライアンスのレビュー
認証、データ、プライバシーに関する懸念点を洗い出し、リリース後ではなく設計段階で対応します。
Bobでこれらのプロンプトを試す
システムをゼロから設計する
@Bob 使用量ベース課金、想定テナント数1万、Stripe Connectの支払いに対応したマルチテナントSaaSのアーキテクチャを設計してください。スタックを選定し、サービス図を作成し、ファイル構成をAlexに渡してください。
理由を添えてスタックを選定する
@Bob 新しいプロダクトで Postgres + Prisma と PlanetScale + Drizzle のどちらを採用するか検討しています。私たちの制約（マルチリージョン読み取り、エンジニア1名、p95で100ms）に照らして比較し、明確なトレードオフを示したうえで1つ推奨してください。
既存のアーキテクチャをレビューする
@Bob 現在のAPIレイヤーをレビューしてください。ダッシュボードのエンドポイントでp95が800msになっており、トラフィックを10倍にスケールしたいと考えています。ボトルネックを整理し、変更案を提案し、移行計画をAlex向けに作成してください。
機能のデータモデルを設計する
@Bob EmmaのPRDにある紹介プログラムのスキーマを設計してください。実際に実行するクエリに対して、エンティティ、リレーションシップ、インデックスを整理してください。スキーマと移行計画をAlexに渡してください。
Bob のAIチームの他のメンバーを見る
どのエージェントも単独では動きません。任意のチームメイトをタップすれば、あなたのプロダクトの担当部分をどう処理しているか確認できます。
以下の地域の顧客から信頼されています
よくある質問
ボブを働かせよう
誰も実装しない図を描くのはやめましょう。Bobに、AIチームがAtoms内で構築し、同期を維持するシステムを設計させましょう。
