mcpField
B
Builderforce

Builderforce

リモート
builderforce.aiAI・エージェント0今日更新
リポジトリ公式サイト

Builderforce について

Builderforceは、プロジェクトボード、ブラウザー内IDE、エージェントの学習、セルフホスト型エージェントの編成を組み合わせたソフトウェアチーム向けクラウドです。VS Code拡張機能からタスクを割り当て、エージェントの操作を確認・承認できます。

主な機能

  1. 01カンバンでのタスク割り当てと追跡
  2. 02ブラウザー内の共同編集IDE
  3. 03WebGPUによるLoRAエージェント学習
  4. 04専門エージェントの登録
  5. 05セルフホスト型エージェント群の編成

活用シーン

  1. 01ボード上で人とエージェントの作業を管理
  2. 02ブラウザーでプロジェクトを編集・プレビュー
  3. 03専門エージェントを学習・デプロイ
  4. 04重要な操作に承認ゲートを設ける

設定

リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。

エンドポイントhttps://api.builderforce.ai/mcp
インストールコマンドをコピー
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。

すべてのエンドポイント
Streamable HTTPhttps://api.builderforce.ai/mcp認証が必要

ツール

詳細

Builderforce.ai

人間が関与する、完全なエージェント型クラウド — 独自の AI エージェントをトレーニングして自分のエージェント内で活用し、ワークフォース全体をカンバンボードで管理できます。VS Code を離れることなく、すべてのアクションをレビューして承認できます。

デプロイ状況 Worker DB

新着情報

  • 2026-10-12 — ローカル推論ランタイムでの逐次バッチ処理。 builderforce-inference の Engine::generate_batch は、モデルを再読み込みせずに、1つの読み込み済みモデルで複数のプロンプトを実行します（e4c07ee）。同時トークン混合／ページドアテンションは今回のリリースには含まれていません。変更履歴：DONE.md。

Builderforce.ai とは？

Builderforce.ai は、アイデアがソフトウェアになり、ソフトウェアがエージェントになる、人間が関与する完全なエージェント型クラウドです。AI エージェントが作業を行う間も、あらゆる手順を自分で管理できます。専門分野に特化した独自のエージェントをトレーニングして自分のエージェント内で活用し、ワークフォース全体をカンバンボードから管理できます。エディターを離れることなく、すべてをレビュー、検証、承認できます。ブラウザー内で完結する IDE、AI トレーニングパイプライン、専門エージェント向けの Workforce Registry、セルフホスト型の BuilderForce Agents メッシュ向けオーケストレーションポータルを組み合わせています。

中核となる3つの機能：

機能内容
🔁 エージェントをトレーニングし、自分のエージェント内で活用ブラウザー内でカスタムエージェントをトレーニングし（WebGPU LoRA + AI 評価）、Workforce Registry に公開してから採用し、自分のエージェント内から呼び出せます。専門エージェントは、メインエージェントが委任するツールになります。
▦ カンバンボードとプロジェクト管理作業をプロジェクトごとに整理し、ライブカンバンボードで各タスクの計画、割り当て、進捗を追跡できます（ステータス別またはエージェント別のスイムレーンに加え、テーブル、カレンダー、ガントビューを利用可能）。人間と AI エージェントが同じボードを共有します。
🧩 VS Code を離れる必要はありませんBuilderForce VS Code 拡張機能を使えば、プラットフォーム全体をエディター内で利用できます。エージェントとのチャット、タスクの割り当てと実行、作業のレビューと検証、コードを離れずに人間の承認が必要なアクションの承認ができます。

1つのプラットフォーム。3つの役割：

役割内容
エンタープライズ IDEブラウザー内の開発ランタイム（BuilderForce WebContainers、独自の MIT ランタイム）+ Monaco + xterm.js、リアルタイムコラボレーション、AI ペアプログラミング
AI トレーニングスタジオ指示データセットを使ったブラウザー内 LoRA ファインチューニング、WebGPU による高速化、最大2Bパラメーターのモデルに対応、クラウド GPU 不要
オーケストレーションポータルBuilderForce Agent フリート管理、タスク割り当て、ハートビート監視、エージェント間メッシュリレー、承認ゲート

主な機能

ブラウザー内 IDE
  • ブラウザー内開発ランタイム：BuilderForce WebContainers（@seanhogg/builderforce-webcontainers）を使用します。独自のオープンソース（MIT）ランタイムです。各ファイルをリクエスト時に esbuild-wasm でコンパイルし、esm.sh からパッケージを読み込むことで、Vite（React、Vue、Svelte）、Create React App、静的プロジェクトをプレビューできます。Node プログラム、実際のレジストリからの npm install、bfsh シェルを実行でき、プロセスごとに Web Worker を1つ使用します。COOP/COEP ヘッダーは不要で、セッション数の上限もありません。プレビューとプロセスは preview.builderforce.ai から配信され、Builderforce のセッションから分離されています。Next.js/Nuxt/SvelteKit/Remix/Astro の開発サーバー、ネイティブアドオン、インストールスクリプトはサポートされていません。検出された場合は理由を示して実行を拒否します。
  • Monaco Editor：構文ハイライト、IntelliSense、複数ファイルのタブ、Yjs CRDT によるリアルタイム共同編集に対応します。
  • xterm.js ターミナル：ランタイムの bfsh シェル（行編集、履歴、パイプ、npm、npx）に接続され、共同作業者間で共有されます。
  • AI チャットパネル：プロジェクトの全ファイルをコンテキストとして利用するストリーミング対応 AI アシスタントです。コードの変更を適用したり、ファイルを直接作成したりできます。
  • ライブプレビュー：ブラウザー内開発サーバーから配信される iframe です。開いているプレビューはすべて、保存時に再読み込みされます。
  • タブ内でチェックと公開：型チェック（createChecker()）と本番ビルド（runtime.build()）がインストール不要でブラウザー内で実行されるため、ファイルを直接チェックして公開できます。
AI トレーニングスタジオ
  • ブラウザー内 LoRA ファインチューニング： @seanhogg/builderforce-memory / Transformers.js と WebGPU を使用し、クライアント側だけで最大20億パラメーターの Mamba-1/2/3 および GPT スタイルのモデルをトレーニングします。
  • ハイブリッドローカルブレイン：Mamba State Engine（mamba-engine.ts）がトランスフォーマー推論と並行して O(n) の選択的スキャンを実行します。エージェントの状態はコンパクトな Float32 状態ベクトルとして IndexedDB に永続化され、エクスポートされる AgentPackage JSON に埋め込まれます。
  • データセット生成：LLM を活用して JSONL 形式の指示データセットを作成し、SSE で進捗をストリーミングします。
  • AI 評価：独立した評価者が、コードの正確性、推論の品質、ハルシネーション率（0.0～1.0）に基づいてモデルの出力を採点します。
  • WebGPU フォールバック：forceFallbackAdapter: true による CPU ソフトウェア処理に対応します。プラットフォームは gpuMode: 'cpu-fallback' を明示的に報告します。
Workforce Registry
  • 専門エージェントの公開：LoRA アダプター、能力プロファイル、MambaStateSnapshot をポータブルな AgentPackage JSON アーティファクトにまとめます。
  • スキルベースの検索：スキル、評価スコア、雇用回数でエージェントを検索できます。
  • 雇用とデプロイ：ワンクリックでエージェントを BuilderForce Agents メッシュに登録できます。ローカルデプロイ用の PowerShell インストールスクリプトも用意されています。
  • 反復的な改善：training_sessions テーブルで、データセット作成 → トレーニング → 評価 → 再トレーニングのサイクルを追跡し、エージェントの品質を継続的に改善します。
ローカル LLM 推論パイプライン
  • エージェントごとの推論エンドポイント — POST /api/ide/agents/:id/chat は、エージェントのペルソナをシステムプロンプトに注入して、OpenRouter 経由で推論をルーティングします。X-Inference-Mode: lora | hybrid | base | fallback-base ヘッダーは、実行された経路を示します
  • Mamba 状態の注入 — v2.0 エージェントは MambaStateSnapshot を保持します。各推論呼び出しでは、システムプロンプトの先頭に [Memory: step=N signal=X context="..."] を追加し、再トレーニングせずにエージェントに持続的な会話メモリを提供します
  • Mamba 状態の同期 — PUT /api/ide/agents/:id/mamba-state は、各セッション後に builderforce CLI から MambaStateSnapshot を受け取り、エージェントパッケージを v2.0 にアップグレードして inference_mode を再計算します。GET /api/ide/agents/:id/mamba-state は保存済みのスナップショットを取得します
  • パッケージのバージョン管理 — エージェントパッケージは v1.0（LoRA のみ）または v2.0（LoRA + Mamba 状態）です。GET /api/ide/agents/:id/package は適切な形式を返し、request_count を増加させます
  • チャットでの Workforce ルーティング — model: "builderforce/workforce-<agentId>" を指定した POST /api/ai/chat は、エージェントの推論エンドポイントへ自動的にルーティングします（従来の coderclawllm/ プレフィックスも引き続き使用できます）。クライアント側の変更は不要です
  • 推論ログ — agent_inference_logs テーブルは、可観測性と課金のために、リクエストごとにモデル参照、レイテンシー、トークン数、ステータス、推論モードを記録します
BuilderForce Agents オーケストレーションポータル

Builderforce.ai は、セルフホスト可能な BuilderForce Agents のクラウド側コントロールプレーンです。

  • フリート登録 — エージェントホストは、マシンプロファイル（IP、ワークスペースディレクトリ、ポート、トンネルメタデータ）とともに POST /api/agent-hosts で登録します
  • ハートビートと機能の同期 — PATCH /api/agent-hosts/:id/heartbeat により、機能マップとマシンプロファイルを最新の状態に保ちます
  • 割り当てコンテキスト — GET /api/agent-hosts/:id/assignment-context は、割り当てられたプロジェクトのメタデータとコンテキストのヒントを提供します。ランタイムは .builderforce/context.yaml に同期します
  • ホスト間メッシュリレー — AgentHostRelayDO Durable Object は、エージェントホスト間の WebSocket 接続をプロキシします。POST /api/agent-hosts/:id/forward はリモートホストにタスクをディスパッチします。認証には送信元ホスト自身の API キー（?from=<id>&key=…、または X-AgentHost-From ヘッダー）を使用し、テナント間の転送は拒否されます
  • 承認ゲート — 影響の大きいエージェントのアクションを人間が介在して制御します。エージェントは実行前に承認を要求し、その結果は監査記録に残されます
  • タスク管理 — tasks テーブルと executions テーブルは、特定のエージェントホストに割り当てられた作業を追跡します。POST /api/tasks/next は、待機中のエージェントに次のタスクを渡します
  • 従来のマウント先 — 移行していないフリート向けに、/api/claws と /api/agentNodes は引き続き応答し、Deprecation: true と /api/agent-hosts を指す Link: rel="successor-version" を返します（presentation/middleware/legacyAlias.ts）。新しい呼び出し元は正規のパスを使用します。
マルチテナントプラットフォーム
  • JWT 認証 — Web トークン（グローバル）とテナントトークン（ワークスペーススコープ）のデュアルトークンモデル
  • 複数の認証方式 — メールアドレスとパスワード、OAuth ソーシャルログイン（Google、GitHub、LinkedIn、Microsoft）、マジックリンクでのサインインを、すべて同じアカウントで併用できます
  • テナント分離 — すべてのリソース（プロジェクト、エージェントホスト、エージェント、トレーニングジョブ）はテナントにスコープされ、テナントをまたぐデータアクセスはできません
  • 複数ワークスペース — ユーザーは複数のテナントに所属できます。ログイン時に bf_default_tenant_id が自動選択します
  • 管理者向け可観測性 — プラットフォーム管理者（superadmin フラグ）向けの /admin インターフェース、R2 内の logs/global-errors.txt、LLM 使用状況メトリクスを表示する /observability
請求とサブスクリプション（Stripe）
  • Stripe のみ — src/infrastructure/payment/StripeProvider.ts（Stripe Checkout と Billing、ホスト型決済ページ、Webhook による有効化）。意図的にプロバイダー切り替え機能も手動の代替手段もありません。課金なしでプランを有効化する代替手段があると、設定されていないデプロイで有料プランが無料で提供されてしまうためです。
  • PaymentProvider インターフェース — src/infrastructure/payment/PaymentProvider.ts により、TenantService が具体的な Stripe クライアントに依存せず、テストで偽物を注入できます。プロバイダー切り替え用の境界ではありません。
  • チェックアウトフロー — POST /api/tenants/:id/subscription/checkout は常にホスト型の checkoutUrl を返します。プランが有効になるのは、署名付き Webhook で支払いが確認されたときのみで、リクエスト自体によって有効になることはありません。
  • Webhook ハンドラー — POST /api/webhooks/payment で Stripe イベントを受信します。5 分間のリプレイウィンドウを設けて HMAC 検証し、正規化された WebhookEvent を介してサブスクリプションを有効化またはキャンセルします。
  • 設定 — STRIPE_* Worker シークレットを設定してください（src/infrastructure/payment/index.ts を参照）。検証は遅延実行されます。シークレットがない場合、課金ルートは 503 を返し、Worker の起動に影響することはありません。
開発分析とチームインテリジェンス
  • コントリビュータープロファイル — GitHub、Jira、Bitbucket をまたいだ開発者 ID の照合です。GET /api/contributors
  • アクティビティの取り込み — POST /api/contributors/activity で、PR の作成・マージ・レビュー、コミット、イシューのイベントを受信し、日次メトリクスを自動集計します。
  • 重み付けアクティビティスコア — コントリビューターごとの日次スコアです（コミット×1 + PR×3 + レビュー×2 + イシュー×1.5）。アクティブな開発日とは、コミットまたは PR アクションが 1 件以上ある日です。
  • PR サイクルタイム — 各アクティビティレコードで、pr_opened から pr_merged イベントまでのエンドツーエンドの所要時間を時間単位で追跡します。
  • インテグレーション認証情報マネージャー — AES-256-GCM で暗号化したプラットフォーム認証情報をテナントごとに保存します。GET/POST/PUT/DELETE /api/integrations。プロバイダーごとの接続テスト（POST /api/integrations/:id/test）。
  • チーム階層 — マネージャーとメンバーの関係を持つ、入れ子構造の開発チームです。GET/POST/PATCH/DELETE /api/dev-teams。メンバーの追加・削除エンドポイントがあります。
  • スタンドアップレポート — GET /api/reports/standup — 日次サマリー：アクティブなコントリビューター、コミット、マージ済み PR、解決済みイシュー。最近の PR と解決済みイシューも含みます。
  • コードレビューレポート — GET /api/reports/code-review — 14 日間を対象とします。停滞中の PR（作成から 7 日超）、平均サイクルタイム、レビュアーのアクティビティを表示します。
  • エグゼクティブサマリー — GET /api/reports/executive — 設定可能な期間の KPI：コントリビューター数、コミット総数、マージ済み PR、追加行数、平均アクティビティスコア、上位コントリビューター。
  • レポートのスケジュール — GET/POST/PATCH/DELETE /api/reports/schedules。時刻と宛先リストを指定する cron 形式の配信設定（日次／週次）です。
  • レポートのサブスクリプション — GET/POST /api/reports/subscriptions。レポートの種類ごとに、ユーザーが受信を選択または解除できます。
プラットフォームインフラストラクチャ
  • テナントごとのレート制限 — Cloudflare Durable Object の TenantRateLimiterDO。スライディングウィンドウ方式（FREE は 60 RPM、PRO は 300 RPM、TEAMS は 1000 RPM）です。X-RateLimit-Limit/Remaining/Reset と Retry-After ヘッダーを返します。
  • 自動承認ルール — GET/POST/PATCH/DELETE /api/approval-rules。POST /api/approvals で actionType、最大コスト、変更された最大ファイル数に基づいてルールを評価します。条件に一致すると、人による承認ゲートを省略します。
  • 承認通知 — 新しい承認リクエストと判定について、Slack webhook と Resend メールで通知します。SLACK_APPROVAL_WEBHOOK_URL と RESEND_API_KEY で設定できます。
  • エスカレーション cron — GET /api/approvals/escalate?secret= でタイムアウトした保留中の承認を期限切れにし、Slack アラートを送信します。Cloudflare Cron Triggers に適しています。
  • OTel テレメトリープロキシ — POST /api/telemetry/spans で取り込み、GET /api/telemetry/spans でクエリ、GET /api/telemetry/traces で一覧表示します。コストはミリセント単位の整数で保存されます。W3C の X-Trace-Id ヘッダーは builderforce CLI から転送されます。

最新の機能

このプラットフォームは、IDEとトレーニングスタジオを組み合わせたものから、エージェント型ワークの完全なシステム・オブ・レコードへと成長しました。ここでは、エージェントワークフォースの基盤となる、エンタープライズ向けのデリバリー、品質、ナレッジ、FinOpsの各機能について、最近追加されたものを紹介します。

プランニングの骨格 — ポートフォリオからタスクまで（mig 0213, 0225）
  • 日付とコストを持つ単一の階層 — portfolio → initiative → epic → task。どのレベルにも、目標レイヤーとして目標と主要な成果を紐付けられます。すべてのレベルに日付が設定され、単一のネスト型ガントチャート（PlanningSpineGantt）に表示されます。
  • コストは末端から集計 — LLMの支出（llm_usage_logを基に記録時点の価格で算出）と人間の作業量（メンバーのコストレート × 時間）が、すべての上位項目に集計されます。並行する財務システムは不要で、過去データの補完も必要ありません。
  • CAPEX / OPEXの区分 — 各ノードは、優先順位（明示的な設定 → 継承 → エージェントによる投資カテゴリの分類 → GAAPに準拠した保守的なデフォルト）で解決されるcost_classを持ちます。親と矛盾する子のクラスには、PMが調整できるよう異常のフラグが付けられます。
  • エンドポイント — GET /api/pmo/spine、GET /api/pmo/spine/export.csv、GET /api/pmo/rollup（ポートフォリオ／イニシアチブ／ワークスペース）、PATCH /api/pmo/cost-class、POST /api/pmo/cost-class/classify、イニシアチブのPOST/DELETE /api/pmo/dependencies（循環チェック済み）→ オンデマンドのクリティカルパス。画面：/projects?tab=portfolio。insights.portfolio / insights.pmによるアクセス制限があります。
品質 — エラーの可観測性とワンクリックでのエージェント修正（mig 0240）
  • 複数ソースからの取り込み — 5つのアダプターの背後に、標準イベント形式を1つ用意しています：ネイティブ（@seanhogg/builderforce-qualityブラウザーSDK）、OTLP、Sentry、PostHog、LogRocket（WebhookはHMACで検証され、Sentryの接続では過去データを補完できます）。
  • フィンガープリントによるグループ化 — イベントは(tenant, project, fingerprint)をキーとしてerror_groupsにアップサートされます。フィンガープリントを明示的に指定するか、スタックの先頭フレームと正規化されたメッセージから生成できます。発生回数と正確な重複なしユーザー数を記録し、解決済みのバグは再発時に再オープンされます。
  • ワンクリックの修正ループ — POST /api/quality/groups/:id/fixは、エラーの内容に基づいてタイトルと優先度を設定し、スタックトレースを添えたボードタスクを作成します。また、プルリクエストを作成するクラウドエージェントをディスパッチします。クラッシュからグループ、タスク、PRまでを1つの画面で管理できます。
  • エンドポイント — 認証が必要な/api/quality/*（コレクター、インテグレーション、ルール、グループ、修正）；キーまたはHMACで認証する公開取り込み先/api/quality-ingest/{events,otlp/v1/logs,otlp/v1/traces,webhooks/:collectorId/:provider}。ダッシュボード：/quality。使用量はerror_eventsとして計測されます。
ナレッジ管理とコンプライアンス（mig 0227）
  • バージョン管理されたSOP、プロセス、ドキュメント — 本文は常に編集でき、公開のたびに変更されないスナップショット（バージョン番号、変更メモ、公開者を含む）が保存されます。
  • 監査に対応した確認記録 — 閲覧確認はタイムスタンプとともに特定のバージョンに紐付けられます。ユーザーごとの状態は確認済み／保留中／期限超過で、マネージャー向けの集計をGET /api/knowledge/complianceで取得できます。SOX、TISAX、ISO 27001の証跡として利用できます。
  • AIによる作成と分析 — POST /api/knowledge/ai/draftはMarkdownの草案をストリーミングし、POST /api/knowledge/documents/:id/analyzeは構造化された指摘事項（非効率／不足／リスク／明確さ）と改善されたフローを返します。使用量はLLMゲートウェイを通じて計測されます。
  • リアルタイムの共同編集 — NEXT_PUBLIC_COLLAB_WS_URLを介したYjs CRDTにより、プレゼンスを把握できます。ワークスペースのロールに加えて、ドキュメントごとに編集者／閲覧者の共同作業者を設定できます。コラボレーションが未設定の場合は、自動保存にフォールバックします。画面：/knowledge。
単一画面のボードコネクター（mig 0221）
  • 10 システム間の双方向同期 — 各プロバイダーは fetchTicketsSince(cursor) と pushUpdate(externalId, changeSet) を実装し、ソースを付与した単一のチケット形式に正規化します。
    • PM／作業管理： GitHub Issues、Jira、Linear、monday.com、Asana、ClickUp
    • ITSM： ServiceNow、Freshservice
    • インシデント： Sentry、PagerDuty
  • 対応している場合は Webhook を使用（GitHub、Jira、Linear、monday、Sentry、PagerDuty）。それ以外はポーリングします。エージェントは、チケットやインシデントの発生元を問わず対応でき、変更は発生元のシステムに反映されるため、移行せずに単一画面で管理できます。
  • エンドポイント — GET /api/board-connections/providers（カタログ）、CRUD /api/board-connections、POST /api/board-connections/:id/sync、GET /api/board-connections/:id/links。
プラットフォーム移行・統合ハブ（mig 0256）

競合他社のトラッカーから安心して移行することも、データを同期することもできます。コネクターフレームワーク上に構築された段階的なインポーターです。確定するまで、実際のプロジェクト、タスク、メンバーには何も反映されません。

  • プロバイダーの検出 — discover() は、Jira、monday、Rally、GitLab、Bitbucket、GitHub（移行対象のプロバイダー。新たに Rally／GitLab／Bitbucket アダプターを追加）にある外部プロジェクト、アイテムの種類、ユーザーを列挙します。
  • ステージングバッファー — import_runs ＋ import_staged_{projects,items,users} ＋ import_type_mappings を使用します。複数の外部プロジェクトを 1 つの BuilderForce プロジェクトにまとめ、アイテムの種類をタスクの種類／ステータスにマッピングし、ユーザーを招待／マッピングできます。すべてインポート前に確認できます。
  • 移行／同期／両方 — 過去のデータを一度だけインポートする、継続的な board_connections 同期を行う、またはその両方を実行できます。永続的な board_type_mappings により、継続的な同期ではタスクがハードコードされたバックログではなく、マッピングされた種類／ステータスに反映されます。インポートしたアイテムは担当者（メンバーにマッピング）とストーリーポイントを保持します。
  • 統合ギャラリー — /settings/integrations はワークスペースのホーム画面です。カテゴリー（PM／SCM／ITSM／インシデント）別のカード、プロバイダーごとの設定パネル（認証情報 · 接続 · アクティビティ／診断）、および「移行を開始」ランチャーを備えています。GitHub／GitLab／Bitbucket では、イシュー（移行）とリポジトリ（コード）の両方に接続できます。
  • Brain から操作可能 — 一連のフロー全体がゲートウェイの MCP カタログ（integrations.create_credential／test、migrations.start／set_mappings／stage／commit）に含まれています。Brain（右側にドッキング）から open_migration_panel を使って左側に移行パネルを開きます。
  • エンドポイント — /api/migrations（start／list／get／:id/mappings／:id/stage／:id/commit、MANAGER 以上、キャッシュ済み＋バージョン更新済み）。
エージェント型テスター — 自律 QA（mig 0063、0206）
  • ヒートマップ順の探索 — ジャーニーイベント（POST /api/qa/events）により、経路と要素のゾーンを直近の頻度に基づいて順位付けします（GET /api/qa/heatmap）。探索では、予算内で最も頻度の高いゾーンから計画を立てます。
  • AI 生成 Playwright — POST /api/qa/generate はフローを実行可能な仕様に変換し、ペルソナの認証情報を解決します。モデルのコストがかからない、ヒートマップのみを使った決定論的な計画も利用できます。
  • 認証済みコンテナーでの実行 — ハーネスが探索を取得し、実際のペルソナとしてログインし（認証情報は暗号化され、開発者の許可が必要）、計画を実行して、コンソール／ページのエラー、失敗したリクエスト、アサーションの失敗、クラッシュを記録します。
  • 検出結果 → ボード → 修正 — 検出結果はフィンガープリントで重複を排除します。自動ルーティングが有効な場合、重要度のしきい値以上の検出結果はすべて修正レーンのボードタスクになり、人がボード上でドラッグしたときと同じレーン自動実行を起動します。その後、修正エージェントが PR を作成します。スケジュールを設定すると cron で実行されます。品質の推移（本番流出した不具合と検出済みの不具合）は GET /api/qa/quality で確認できます。
使用量計測（mig 0218）
  • 可視性ではなく消費量を計測 — 1 つのフレームワーク（/api/consumption）が、プランの上限に対する当月の ai_tokens、ingestion（バイト数）、error_events の使用量を報告します。ゲートウェイと取り込みゲートが適用するものと同じ計測ロジックを使用するため、メンバーに表示される「使用率」は実際に適用される上限と一致します。60 秒間キャッシュされ、テナントごと、暦月ごとにキー付けされます。
役割の連携参加と説明責任（mig 0334）
  • 適切な役割が作業を担当 — エージェント↔役割のファーストクラス機能（ide_agents.role_keys）により、役割を考慮した割り当てを実現します。プロデューサーステージがチケットの action_type から役割を特定し、その役割を担えるエージェントまたは人間に割り当てます。誤った割り当ては行いません。「プロダクトマネージャーがコードを書くために割り当てられる」といった問題を防ぎます。
  • チケットごとの参加マニフェスト — ticket_participants がボードのスイムレーン要件から必要な役割を割り出し、各枠を能力に応じて割り当て、参加者ごとの状態（pending / assigned / in_progress / completed / changes_requested / waived / unstaffed）を追跡します。
  • 不変の説明責任レポート — 追記専用の ticket_role_signoffs 台帳に、役割ごとの「担当者／日時／判定／コメント／貢献」を記録します。RBAC はデフォルト拒否で、役割を担えるメンバーのみがその役割として承認できます。すべての承認は統合アクティビティログに記録されます。リソース評価コントロールでは、テンプレートにない必要な役割を追加できます。追加した役割が未解決の場合は、ブロッキング要因となるリソース不足として表示されます。
  • エンドポイント — GET /api/kanban/tasks/:id/accountability、/participants、POST /participants（評価）／/materialize、および MCP の kanban.participants／kanban.accountability／kanban.assess_resource。表示場所：チケットドロワーの説明責任タブと、ボード上の参加者チップ X/Y。
プリセールスの RFP／RFQ 回答（mig 0335）
  • リポジトリを提案書に変換 — 組み込みの CTO とプロダクトオーナーのエージェントが、プロジェクトの分析済み機能をもとに、ブランドに合わせた費用見積もり付き提案書を生成します。内容には、費用／損益、フェーズ別ガントチャート、リスク、依存関係、要件に合致する機能の一覧が含まれます。
  • 共同ブランドの出力 — 依頼者のカラーパレットとロゴを回答者のものと組み合わせ、ブランドに合わせた独立した提案書を作成します（PDF 印刷／ダウンロード対応）。回答の根拠には鮮度チェックを適用し、スキャン結果が5日を超えて古い場合は、回答前に決定論的なシステム監査を再実行します。
  • 表示場所 — Projects のRFP タブ（一覧／作成）と、/projects/rfp/[id] の詳細画面。/api/rfp ルート。
インシデント管理とアクティブ監視（mig 0292）
  • インシデントで対応を完結 — ヘルプデスク／インシデントマネージャーのエージェント、Freshdesk コネクター、オンコールローテーション、時間制のエスカレーション、Teams／Slack／メールによる呼び出し、インシデントごとのウォールームフィードを提供します。解決時には RCA をナレッジに公開し、さらにプロジェクトの Evermind に取り込むことで、ワークフォースが学習し、同じ原因の再発を防ぎます。
  • 監視キャンバス — アップロードしたアーキテクチャ図に、ハートビート／HTTP／Webhook／メトリックのモニターをピン留めできます。*/5 の定期チェックで評価し、閾値違反が発生するとオンコール調査を自動開始します（モニター → シグナル → インシデント → 呼び出し）。タイムライン上でレポートを確認できます。
ミーティングとリアルタイムコラボレーション（mig 0292、0330）
  • エージェントが参加するビデオ／音声ミーティング — CeremonyRoomDO リレーを介したメッシュ型 WebRTC を使用します。エージェントの参加者は字幕／文字起こしブリッジを通じてリアルタイムに発言し、録画と文字起こしからAI 議事録を作成します。Google／Microsoft のカレンダーと同期します。表示場所：/meetings。
AI マネージャー — 種類とコーチング（mig 0327）
  • 役割カタログに紐づく型付きマネージャー — Dev／QA／Service-Desk／DevOps のマネージャー種別を roleCatalog に対応付けます（カスタム役割は role:<key> 型になります）。人間からマネージャーへのコーチングセッションでは、directive | task モードを有効期限／完了状態とともに設定し、マネージャーエージェントによるレポートの作成方法を方向づけます。
メモリ優先の回答 — 有料の LLM 呼び出しを省略
  • モデルを呼び出す前にプロジェクト独自のメモリから回答 — Web と VS Code の Webview Brain は、まずプロジェクトの project_facts ファクト層と Evermind SSM を参照し、確度の高い情報が見つかれば LLM 呼び出しを省略します（同じ質問への正確な回答を保存するキャッシュと、オプトイン方式の Evermind 優先推論）。回答処理は resolveMemoryAnswer に一元化されています。学習内容は、共通の contributeTextToProjectEverminds を通じて、プロジェクト配下のすべての Evermind（独自のヘッドと、IDE ビルドのヘッド）に展開されます。エンドポイント：GET/POST /api/projects/:id/answer、GET /api/projects/:id/evermind/targets。

認証

Builderforce.ai は、同じアカウントで併用できる3つのサインイン方法に対応しています。1人のユーザーが複数の OAuth プロバイダーを連携し、パスワードを設定して、マジックリンクを使い分けることができます。

サインイン方法
方法仕組み
メールアドレス＋パスワードPOST /api/auth/web/login — PBKDF2（100k 回の反復、SHA-256）。メールアドレスが間違っている場合もパスワードが間違っている場合も、同じ汎用エラーを返します
OAuth ソーシャルログインGET /api/auth/oauth/:provider → プロバイダーの同意 → GET /api/auth/oauth/:provider/callback → JWT を発行。ブラウザーを /auth/callback?token=… にリダイレクトします
マジックリンクPOST /api/auth/magic-link は、15分間有効な1回限りのトークンをメールで送信します。GET /api/auth/magic-link/verify?token=… は JWT を発行します。常に 200 を返します（メールアドレスの有無を判別できないようにします）

対応する OAuth プロバイダー：google、github、linkedin、microsoft。

認証フロー図
Browser
  │
  ├─ Email/password ──────────────────────────► POST /api/auth/web/login
  │                                              Returns JWT in JSON body
  │
  ├─ OAuth (click button) ────────────────────► GET /api/auth/oauth/:provider
  │                                              302 → provider consent screen
  │                                              Provider → GET /api/auth/oauth/:provider/callback
  │                                              API issues JWT
  │                                              302 → /auth/callback?token=JWT
  │                                              Frontend page writes token to localStorage
  │
  └─ Magic link ──────────────────────────────► POST /api/auth/magic-link
                                                 Email sent with /auth/magic-link?token=…
                                                 Frontend page calls GET /api/auth/magic-link/verify
                                                 Returns JWT in JSON body
JWT 戦略
  • Web トークン（localStorage key: bf_web_token）— 有効期間24時間の HMAC-SHA-256 JWT。ペイロード：{ sub, email, username, amr?, sa?, jti, sid }
  • テナントトークン（localStorage key: bf_tenant_token）— ワークスペース単位の JWT。有効期間1時間で、POST /api/auth/tenant-token が発行します
  • 発行されたすべてのトークンは auth_tokens テーブル（JTI＋セッション ID）で追跡されます。webAuthMiddleware はリクエストごとにこのテーブルを照合するため、トークンを即時に無効化できます
アカウント管理エンドポイント
エンドポイント認証説明
GET /api/auth/linked-accountsWeb JWT連携済みの OAuth プロバイダーと、アカウントにパスワードが設定されているかどうかを一覧表示します
DELETE /api/auth/unlink/:providerWeb JWTプロバイダーの連携を解除します。サインイン方法が1つも残らない場合は拒否されます
POST /api/auth/add-passwordWeb JWTOAuth のみで利用しているアカウントにパスワードを追加します
OAuth のセキュリティ
  • CSRF 保護 — OAuth の state パラメーターは、nonce と10分間の有効期限を含めて HMAC-SHA-256（JWT_SECRET を使用）で署名されます。データベースは不要です
  • アカウント連携 — OAuth のメールアドレスが既存アカウントと一致する場合、プロバイダーは自動的に連携されます。ユーザー自身がメールアドレスを管理しているため、安全です
  • メールアドレスのみのユーザー — パスワードを設定していない OAuth ユーザーは、連携解除エンドポイントによって保護されます。先に POST /api/auth/add-password を実行する必要があります
OAuth プロバイダーを有効にする

各プロバイダーは、Cloudflare Worker のシークレットとしてクライアント認証情報を設定すると有効になります。認証情報が設定されていないプロバイダーは、エラーを表示せずに 503 を返します。設定が必要なのは、利用したいプロバイダーだけです。

# Google
wrangler secret put GOOGLE_CLIENT_ID
wrangler secret put GOOGLE_CLIENT_SECRET

# GitHub
wrangler secret put GITHUB_CLIENT_ID
wrangler secret put GITHUB_CLIENT_SECRET

# LinkedIn
wrangler secret put LINKEDIN_CLIENT_ID
wrangler secret put LINKEDIN_CLIENT_SECRET

# Microsoft
wrangler secret put MICROSOFT_CLIENT_ID
wrangler secret put MICROSOFT_CLIENT_SECRET

各プロバイダーのダッシュボードで OAuth コールバック URL を登録します。

https://api.builderforce.ai/api/auth/oauth/{provider}/callback

{provider} を小文字のプロバイダー名（google、github、linkedin、microsoft）に置き換えてください。

プロバイダーの設定
プロバイダー設定時間手動審査？注意点
Google約10分サインインは不要。Gmail／Calendar／Drive／YouTube のスコープは必要Google のすべてのフローで1つの OAuth クライアントを使用します。フローごとにリダイレクト URI を登録してください。登録しないと、サインインが機能していても、コネクターは redirect_uri_mismatch で 400 を返します
LinkedIn約10分不要（自動承認）**「Sign In with LinkedIn using OpenID Connect」**製品を追加する必要があります。追加しないと、/v2/userinfo エンドポイントからメールアドレスが返されません
GitHub約5分不要アプリごとにコールバック URL を1つしか設定できません。ローカル開発用に2つ目の OAuth App を作成してください
Microsoft約10分不要Google と同様、1つのクライアントを複数のフローで使う際に注意が必要です。サインインに加えて、メールボックス／カレンダー／ドライブのリダイレクト URI も登録してください
Google

  1. console.cloud.google.com にアクセスし、プロジェクトを作成するか選択します

  2. APIs & Services → OAuth consent screen

    • User Type：External
    • アプリ名、サポート用メールアドレスを入力し、スコープ email、profile、openid を追加します（機密性の低いスコープのため、審査は不要です）
    • コネクターで使用するスコープもここに追加する必要があり、無料ではありません。Gmail （gmail.modify、gmail.send）は制限付きスコープ、Calendar／Drive／YouTube は 機密性の高いスコープです。アプリが Testing の間は、どちらの種類もテストユーザーとして 登録されたアカウントで使用できます。ただし、一般公開するには Google の審査が必要です。
    • 開発中は、自分のメールアドレスをテストユーザーとして追加します

  3. APIs & Services → Credentials → Create Credentials → OAuth 2.0 Client ID

    • Application type：Web application
    • 承認済みのリダイレクト URI — サインインだけでなく、フローごとに 1 つずつ登録します。GOOGLE_CLIENT_ID は Google 系コネクターすべてで共有されますが、それぞれのコネクターはリクエスト元のオリジンから独自の コールバックパスを構築します。ここに登録されていないパスは、同意画面で Error 400: redirect_uri_mismatch となります。サインインが動作しても、ほかのフローが動作するとは限りません。 使用する予定のフローすべてについて本番環境用の URI を追加し、開発に使用する各 URI についても http://localhost:8787 の URI を追加します。 
      https://api.builderforce.ai/api/auth/oauth/google/callback   # サインイン／アカウント作成
https://api.builderforce.ai/api/mailbox/callback/google      # 受信トレイを接続（Gmail）
https://api.builderforce.ai/api/calendar/callback/google     # Google Calendar
https://api.builderforce.ai/api/drive/callback/google        # Google Drive
https://api.builderforce.ai/api/youtube/callback             # YouTube への公開

  4. Client ID と Client Secret をコピーします：

    wrangler secret put GOOGLE_CLIENT_ID
wrangler secret put GOOGLE_CLIENT_SECRET

  5. OAuth consent screen → App domain — Application privacy policy link と Application terms of service link を入力します。これらがないアプリは Google による審査を受けられません。また、設定するまでは 同意画面にポリシーへのリンクを表示できないことがユーザーに伝えられます。

    https://builderforce.ai/legal/privacy
https://builderforce.ai/legal/terms

    どちらも、現在公開されている文書バージョンを表示する公開済みのサーバーサイドレンダリングページです（frontend/src/lib/legalDocs.ts を参照してください。各ページ、フッターリンク、トラストセンターのナビゲーション、サイトマップで共有されるルートテーブルは 1 つです）。Authorized domains に builderforce.ai も追加します。

公開： 「Testing」モードでは、テストユーザーだけがサインインでき、コネクターの同意を完了できるのもテストユーザーだけです。リダイレクト URI をいくつ登録しても変わりません。本番環境で使用する準備ができたら、同意画面で Publish App をクリックします。email/profile/openid は標準スコープで、通常は手動審査なしですぐに承認されます。ただし、上記の Gmail／Calendar／Drive／YouTube のスコープは機密性が高いか制限付きであり、Google の審査を受ける必要があります。審査には、手順 5 のプライバシーポリシーと利用規約へのリンクに加えて、同意フローのデモ動画が必要です。

LinkedIn
  1. linkedin.com/developers にアクセスし、Create App を選択します
    • アプリ名、LinkedIn Company Page（必須。必要に応じて作成してください）、ロゴ
  2. Auth tab → Authorized redirect URLs — 次の 2 つを追加します： 
    https://api.builderforce.ai/api/auth/oauth/linkedin/callback
http://localhost:8787/api/auth/oauth/linkedin/callback
  3. Products tab → "Sign In with LinkedIn using OpenID Connect" を申請します — Request access をクリックします（すぐに自動承認されます）。これにより、コードで使用する openid profile email スコープが有効になります。これがないと、/v2/userinfo エンドポイントからメールアドレスが返されません。
  4. Auth tab に戻り、Client ID と Client Secret をコピーします： 
    wrangler secret put LINKEDIN_CLIENT_ID
wrangler secret put LINKEDIN_CLIENT_SECRET
GitHub
  1. GitHub → Settings → Developer settings → OAuth Apps → New OAuth App
    • ホームページ URL：https://builderforce.ai
    • 認証コールバック URL： 
      https://api.builderforce.ai/api/auth/oauth/github/callback
  2. Register application をクリックし、次に Generate a new client secret をクリックします
  3. シークレットを設定します： 
    wrangler secret put GITHUB_CLIENT_ID
wrangler secret put GITHUB_CLIENT_SECRET

ローカル開発： GitHub では、アプリごとにコールバック URL を 1 つしか設定できません。別の OAuth App（例：「builderforce-dev」）を作成し、http://localhost:8787/api/auth/oauth/github/callback を設定して、その認証情報を api/.dev.vars で使用してください。

Microsoft
  1. Azure Portal → Microsoft Entra ID → App registrations → New registration
    • サポートされるアカウントの種類：「任意の組織ディレクトリ内のアカウントおよび個人用 Microsoft アカウント」
    • リダイレクト URI（Web）— MICROSOFT_CLIENT_ID はすべての Microsoft フローで共有されるため、使用するフローごとに 1 つ登録します（ローカル開発用に http://localhost:8787 の URI も追加してください）： 
      https://api.builderforce.ai/api/auth/oauth/microsoft/callback   # サインイン／アカウント作成
https://api.builderforce.ai/api/mailbox/callback/microsoft      # 受信トレイの接続（Outlook）
https://api.builderforce.ai/api/calendar/callback/microsoft     # Outlook Calendar
https://api.builderforce.ai/api/drive/callback/microsoft        # OneDrive／SharePoint
  2. Certificates & secrets → New client secret — 値は一度しか表示されないため、すぐにコピーします
  3. 概要ページから Application (client) ID をコピーします
  4. シークレットを設定します： 
    wrangler secret put MICROSOFT_CLIENT_ID
wrangler secret put MICROSOFT_CLIENT_SECRET
ローカル開発

ローカル開発では api/.dev.vars を使用します。Wrangler は wrangler dev の実行時にこのファイルを自動的に読み込みます。このファイルは Git の追跡対象外です：

# api/.dev.vars
GOOGLE_CLIENT_ID=your_google_client_id
GOOGLE_CLIENT_SECRET=your_google_client_secret
LINKEDIN_CLIENT_ID=your_linkedin_client_id
LINKEDIN_CLIENT_SECRET=your_linkedin_client_secret
GITHUB_CLIENT_ID=your_github_dev_app_client_id
GITHUB_CLIENT_SECRET=your_github_dev_app_client_secret
APP_URL=http://localhost:3000

OAuth コールバック URL は実行時に受信リクエストの Origin ヘッダーから導出されるため、追加の API_URL 変数は不要です。ローカルでは http://localhost:8787 に、本番環境では https://api.builderforce.ai に自動的に解決されます。

マジックリンクメール

api/src/presentation/routes/oauthRoutes.ts の sendMagicLinkEmail 関数は、コンソールにリンクを記録するプレースホルダーです。本番環境でマジックリンクを使用する前に、お使いのメールプロバイダー（Resend、SendGrid、Mailgun など）に接続してください：

// api/src/presentation/routes/oauthRoutes.ts  ~line 253
async function sendMagicLinkEmail(to, name, token, frontendUrl) {
  const magicUrl = `${frontendUrl}/auth/magic-link?token=${encodeURIComponent(token)}`;
  // TODO: call your email provider here
}
追加されたフロントエンドルート
ルートファイル目的
/auth/callbackfrontend/src/app/auth/callback/page.tsxOAuth リダイレクトから ?token=JWT を受け取り、セッションを保存して遷移します
/auth/magic-linkfrontend/src/app/auth/magic-link/page.tsx/api/auth/magic-link/verify を呼び出し、セッションを保存して遷移します

BuilderForce Agents との連携

Developer workstation
  └─ BuilderForce Agents (self-hosted, MIT)
       ├─ 7-role agent DAG (Code, Review, Test, Debug, Refactor, Document, Architect)
       ├─ Staged diff review (accept/reject before writing to disk)
       ├─ Agent-to-agent mesh (remote:<id>, remote:auto[caps], HMAC-signed dispatch)
       ├─ Workflow telemetry → .builderforce/telemetry/ + portal timeline
       ├─ Execution lifecycle → running/completed/failed reported to portal
       ├─ Approval gate → blocks on manager decision from portal
       ├─ Skill registry → loads portal-assigned skills at startup
       ├─ Cron scheduler → executes portal-managed jobs on schedule
       └─ BUILDERFORCE_API_KEY → heartbeat → Builderforce.ai
                                                      │  ←task.assign / task.broadcast
                                                      │  ←approval.decision
                                                      │  ←cron jobs / skill assignments
                                              ┌───────▼───────┐
                                              │ Builderforce  │
                                              │  .ai          │
                                              │               │
                                              │ • Fleet view  │
                                              │ • Task assign │
                                              │ • Approvals   │
                                              │ • Audit log   │
                                              │ • AI training │
                                              │ • Registry    │
                                              │ • Cron jobs   │
                                              │ • Skills mkt  │
                                              └───────────────┘

BuilderForce Agents を接続するための設定（npm install -g @seanhogg/builderforce-agents または curl -fsSL https://builderforce.ai/install.sh | bash でインストールします）：

export BUILDERFORCE_API_KEY=<your-api-key>
export BUILDERFORCE_URL=https://api.builderforce.ai
builderforce gateway

BuilderForce Agents は Builderforce がなくても完全に単独で動作します。接続すると、エージェント群の可視化、ライブ実行状況を追跡しながらのタスク割り当て、強制承認ゲート、ポータルで管理するスキルの割り当て、スケジュールされた cron 実行、Workforce Registry へのアクセスが可能になります。

デバイス上の AI スタック

Builderforce.ai は、デバイス上の AI を実現するオープンソースの @seanhogg/builderforce-memory スタックを基盤としています：

@seanhogg/builderforce-memory-engine  (engine)
  └─ WebGPU WGSL kernels: Mamba-1 (S6), Mamba-2 (SSD), Mamba-3 (complex MIMO+ET), causal attention
        ↓
@seanhogg/builderforce-memory  (runtime)
  └─ MambaSession.create() — one-call GPU init, tokenizer, model, checkpoint, persistence
  └─ Inference routing · distillation · semantic memory · SSMAgent
        ↓
Builderforce.ai IDE
  └─ mamba-engine.ts  — Hybrid Local Brain (SSM state + IndexedDB)
  └─ agent-runtime.ts — step() → inference → confidence scoring → cloud escalation
  └─ webgpu-trainer.ts — LoRA fine-tuning pipeline (Transformers.js + WebGPU)

デバイス上の AI レイヤーは O(n) 時間（アテンションの O(n²) に対して）で動作するため、低レイテンシでの継続的な状態更新や、ブラウザー内で完結するファインチューニングに適しています。

どちらのパッケージも npm で公開されています：@seanhogg/builderforce-memory-engine（エンジン）および @seanhogg/builderforce-memory（ランタイム）。

サーフェス横断型のセマンティックキャッシュ（トークン削減）

スタックにおける最大のコスト削減要因は、埋め込みベクトルをキーとするセマンティックキャッシュです。新しいプロンプトが、すでに回答済みのプロンプトの 言い換え である場合に以前の回答を再利用するため、意味的に重複する処理でフロンティアモデルが呼び出されることはありません。このキャッシュは2層構成で、複数のサーフェス間で共有されます。

  • L1（ローカル、無料）： デバイス上のSSM埋め込みを使った、プロセス内のコサイン類似度マッチングです。ブラウザーIDEと各エージェントで実行されます。
  • L2（共有）： ゲートウェイの POST /v1/semantic-cache/{lookup,store}（テナント単位のスコープ、KVバックエンド）です。Webアプリで回答された言い換えはエージェントで再利用でき、その逆も同様です。

@builderforce/memory の同じポータブルな SemanticCache が両方のサーフェスで機能します。エンベッダー（デバイス上のSSM）とL2バックエンドは注入されるため、ブラウザー版とNode版を分岐させる必要はありません。デバイス上の埋め込みによりL1は無料で、ゲートウェイのL2により、あるテナントのキャッシュヒットがプラットフォーム全体のコスト削減につながります。

ハイブリッド検索と回答評価

Builderforce.aiは、7層のエージェントスタックを完全に実装しています。多くのスタックでは従来型のまま薄い実装にとどまっている2つの層（RAG検索と評価）も、しっかりと構築されています。

  • ハイブリッドRAG。 検索では、密（SSM／OpenAIの埋め込み、コサイン類似度）と疎（Okapi BM25キーワード）のシグナルを逆順位融合で統合し、再帰的分割とオーバーラップを用いてチャンク化したドキュメントに対して、関連性 と 多様性を考慮した MMR で再ランキングします。密検索だけでは、識別子、エラーコード、珍しい名前などの正確なトークンを見逃しますが、ハイブリッド検索ならそれらを捉えられます。問題が発生しても適切に縮退します（埋め込みなし → BM25のみ、オーバーラップなし → 密検索のみ）。@seanhogg/builderforce-memory/retrieval に依存関係なしで含まれており（chunkText、bm25Search、reciprocalRankFusion、maximalMarginalRelevance、hybridRetrieve、MemoryStore.recallHybrid）、LanceDBの長期記憶拡張を支えています。
  • セマンティック評価とドリフト。 クラウドでの実行はすべて、忠実性、回答の関連性、ハルシネーション率についてインラインでゼロコスト（語彙ベース）にスコアリングされます。必要に応じて、POST /api/eval で LLMを評価者として使う機能にアップグレードできます（従量課金制のゲートウェイを通じて課金）。スコアは実行レコードに保存され、ドリフトモニター（平均シフトのzスコア＋Population Stability Index）が、*（アクションタイプ × モデル）*ごとにベースラインと直近のウィンドウを比較し、品質が低下した場合にアラートを発します。これはcronで毎日実行され、GET /api/eval/drift からも要求できます。誤った回答が、緑色のダッシュボードの陰に隠れることはもうありません。

詳細はこちら：The AI Agent Tech Stack, Built。

オープンソース

Builderforce.aiの基盤となるランタイムはMITライセンスのオープンソースで、フォークを前提に構築されています。概要：builderforce.ai/open-source。

パッケージ提供内容
builderforce-webcontainersIDEとキャンバスプレビューを支える、ブラウザー内の開発ランタイムです。ライブプレビュー、本番ビルド、型チェック、Nodeプロセス、npm install、シェルを備え、COOP/COEPは不要で、セッション数の上限もありません。npm：@seanhogg/builderforce-webcontainers。
builderforce-memoryあらゆるエージェント向けの、永続的でブラウザー上でトレーニング可能なSSMメモリです。WebGPU Mambaエンジン、ランタイム、セマンティックキャッシュ、Evermindのライトスルーメモリに加え、MCPサーバーも備えています。npm：@seanhogg/builderforce-memory。
builderforce-inferenceSynapse、つまりデスクトップアプリとローカルAIランタイムです。ネイティブの bfi エンジンで自身のマシン上のモデルを実行し、プライベートなEvermindメモリを保持して、MCPコネクターをホストします。
builderforce-spawn会話を通じてRobloxゲームを作成するデスクトップアプリ、Spawnです。Roblox Studioブリッジも備えています。

アーキテクチャ

┌─────────────────────────── Browser ──────────────────────────────┐
│                                                                   │
│  Next.js (App Router)           BuilderForce WebContainers        │
│  ┌─────────────────────┐        ┌──────────────────────────────┐ │
│  │  Monaco Editor      │◄──────►│  Dev server (esbuild-wasm)   │ │
│  │  xterm.js Terminal  │        │  Node processes · npm · bfsh │ │
│  │  Preview <iframe>   │        │  Service worker on preview.* │ │
│  │  AI Chat Panel      │        │  Virtual FS (synced to R2)   │ │
│  │  Train Panel        │        └──────────────────────────────┘ │
│  │  Agent Publish      │                                          │
│  └──────────┬──────────┘                                          │
│             │ HTTP / WebSocket                                     │
└─────────────┼────────────────────────────────────────────────────┘
              │
┌─────────────▼──────────── Cloudflare Edge ──────────────────────┐
│                                                                   │
│  API (api.builderforce.ai — Hono)    Durable Objects             │
│  ┌────────────────────────────┐      ┌──────────────────────┐   │
│  │ /api/auth  /api/tenants    │      │  AgentHostRelayDO    │   │
│  │ /api/agent-hosts /api/tasks│      │  - host mesh relay   │   │
│  │ /api/brain /api/projects   │      │  - heartbeat proxy   │   │
│  │ /api/runtime/executions    │      └──────────────────────┘   │
│  └────────────────────────────┘      ┌──────────────────────┐   │
│                                       │  CollaborationRoom   │   │
│  Worker (worker.builderforce.ai)      │  - Yjs CRDT sync     │   │
│  ┌────────────────────────────┐      │  - cursor presence   │   │
│  │ /api/projects (IDE files)  │      │  - terminal relay    │   │
│  │ /api/datasets /api/training│      └──────────────────────┘   │
│  │ /api/agents (Registry)     │                                   │
│  │ /api/ai/chat (streaming)   │      R2 Buckets                  │
│  └────────────────────────────┘      ┌──────────────────────┐   │
│                                       │ project files        │   │
│  Neon Postgres                        │ datasets (.jsonl)    │   │
│  ┌────────────────────────────┐      │ LoRA artifacts       │   │
│  │ users · tenants · projects │      │ agent packages       │   │
│  │ agent_hosts · tasks        │      └──────────────────────┘   │
│  │ agents · training_jobs     │                                   │
│  │ agent_inference_logs       │                                   │
│  │ contributors · dev_teams   │                                   │
│  │ activity_events · metrics  │                                   │
│  │ integrations · telemetry   │                                   │
│  └────────────────────────────┘                                   │
└───────────────────────────────────────────────────────────────────┘

2 つの Cloudflare Workers、1 つのプラットフォーム：

api (api.builderforce.ai)worker (worker.builderforce.ai)
目的認証、テナント、エージェントホスト、タスク、ブレイン、マーケットプレイス、開発分析IDE プロジェクト、ファイル、データセット、トレーニング、コラボレーション
認証JWT + テナント分離CORS（現在、認証なし）
Durable ObjectsAgentHostRelayDO（ホストメッシュリレー）CollaborationRoom（Yjs 同期）
ストレージR2 UPLOADS（ブレインファイル、エージェントホストのアセット）R2 STORAGE（プロジェクトファイル、アーティファクト、データセット）

クイックスタート

ローカル開発
git clone https://github.com/SeanHogg/Builderforce.ai
cd Builderforce.ai

# Install deps
pnpm install          # or npm install in each sub-directory

# Configure
echo "NEXT_PUBLIC_WORKER_URL=http://localhost:8787" > frontend/.env.local
echo "NEON_DATABASE_URL=postgresql://..." > worker/.env

# Run migrations
cd worker && npm run migrate && cd ..

# Start (in separate terminals)
cd worker && npx wrangler dev     # :8787
cd frontend && npm run dev        # :3000

http://localhost:3000 を開きます。WebGPU トレーニングには Chrome 113 以降が必要です。

Cloudflare へのデプロイ
cd api && npm run secrets:from-env && npm run deploy
# Frontend: CI/CD via .github/workflows/deploy-frontend.yml

必須シークレット： CF_API_TOKEN、CF_ACCOUNT_ID、NEON_DATABASE_URL、JWT_SECRET、OPENROUTER_API_KEY。（SDK の公開には npm Trusted Publishing OIDC を使用するため、NPM_TOKEN シークレットは不要です。詳細は以下をご覧ください。）

リリース： release.yml は、npm パッケージ化、API のデプロイ、フロントエンドのデプロイ、ヘルプサイトのデプロイという 4 つの独立したジョブを並行して実行します。package-npm ジョブは各公開パッケージをビルド、テスト、公開します。ただし、そのパッケージの package.json のバージョンが npm に存在する場合は公開しません。これにより、再実行しても同じ結果になるようにしています。認証には npm Trusted Publishing OIDC を使用します（任意のブートストラップ用フォールバックとして NPM_TOKEN も使用できます）。各パッケージの信頼された発行元として、Organization に SeanHogg、Repository に Builderforce.ai、Workflow に release.yml を設定してください。

任意の OAuth シークレット（使用するプロバイダーのものだけを追加してください）： GOOGLE_CLIENT_ID、GOOGLE_CLIENT_SECRET、GITHUB_CLIENT_ID、GITHUB_CLIENT_SECRET、LINKEDIN_CLIENT_ID、LINKEDIN_CLIENT_SECRET、MICROSOFT_CLIENT_ID、MICROSOFT_CLIENT_SECRET

ブラウザー要件

機能必要条件
ブラウザー内 IDE ランタイム（BuilderForce WebContainers）サービスワーカーに対応し、安全なコンテキスト（https または localhost）で動作する最新のブラウザー。COOP/COEP ヘッダーは不要です。
WebGPU LoRA トレーニングChrome 113 以降
共同編集最新のブラウザーであれば使用できます
CPU フォールバックトレーニング任意のブラウザー（forceFallbackAdapter 経由）

IDE ランタイムは、現行の Chrome、Edge、Firefox、Safari で動作します。上記のとおり、独自のブラウザー要件があるのは WebGPU 機能（トレーニング、オンデバイス推論）のみです。

デザインシステム

UI は BuilderForce のディープスペースの美学に沿っており、Builderforce.ai と BuilderForce Agents ランタイム全体で統一されています。

トークンダークライト
--bg-deep#050810#fcfeff
--bg-surface#0a0f1a#ffffff
--coral-bright#4d9eff#3b82f6
--cyan-bright#00e5cc#008f87
--font-displayClash DisplayClash Display
--font-bodySatoshiSatoshi

テーマは localStorage('bf-theme') に保持され、初回描画の前に適用される FOUC 防止用のインラインスクリプトを使用します。

ロードマップとギャップ登録簿

計画中のマイルストーン（PHASE 4 — 大規模マルチエージェントオーケストレーションを含む）と、完全版の 統合ギャップ登録簿（341 項目：解決済み 53 件・未解決 288 件、収益への影響別に分類）およびアーカイブ済みのテーマ別コンテキストは、計画作業と保留中の課題に関する唯一の情報源である ROADMAP.md で公開されています。新たに保留となった課題は、ここに追加されます。

Cloud エージェントの種類

Builderforce はエージェントを 2 つの実行プレーン（On-Prem（ホスト型）とCloud）で実行します。エージェントエンジンは 1 つ（現行バージョン）のみのため、Cloud プレーンは、Durable Object または Node/Container の 2 つの実行環境のいずれかで動作する単一の Cloud Agent です。ルーティングの判断は、cloudDispatch.ts（resolveCloudSurface / cloudAgentTypeLabel）と runtimeRoutes.ts（resolveCloudAgent）に集約されています。実行環境を示す列は ide_agents にあります（runtime_surface、マイグレーション 0105）。エンジンが DB から読み込まれることはなく、常に現行バージョンが使用されます。

Cloud と On-Prem の間には明確な境界があります。 Cloud エージェントはクラウド内でのみ実行されます（すべて Cloudflare の Worker、Durable Object、または Container です）。Cloud エージェントがクライアントのマシンにディスパッチされることはありません。On-Prem（ホスト型）エージェント（agentHost。1 台のマシンで複数実行可能）は、ホストが明示的に割り当てられている場合にのみタスクを実行します。エージェントの分類については、[[agent-types-taxonomy]] を参照してください。

概要
Cloud Agent の実行環境実行場所永続シェル？最適な用途
Cloud Agent（Durable Object）durable — CloudRunnerDO。alarm() のティックごとに LLM ステップを 1 つ実行します。デフォルトの実行環境です。いいえ（ビルドの検証は CI が実施）ほとんどのクラウドタスク：オンデマンドで実行でき、常時稼働のコンピューティングリソースが不要で、長時間の実行にも対応
Cloud Agent（Node/Container）container — 長時間稼働する Cloudflare Container（AgentContainerDO）はい（run_command）依存関係をインストールしてビルド／テスト／リントを実行するための実シェルが必要な、非常に長時間または継続的なタスク
(On-Prem ホスト型 — 比較用)クライアントのマシン（agentHost）。割り当てられている場合のみはい（ホスト自身のマシン）BYO マシンでの実行。Cloud エージェントではありません
Cloud Agent（Durable Object）— 実行環境 durable

デフォルトの実行環境です。Durable Object の alarm() ティックをまたいで、Claude Agent SDK のツールループをクラウド内で完全に実行します。ティックごとに LLM ステップを 1 つ実行し、ティック間の会話状態は DO ストレージに保存されます（CloudRunnerDO）。推論は、テナントの BYO Anthropic キーを使用して LLM Gateway 経由でルーティングされます。

機能

  • alarm() のティックごとに 1 ステップを実行します。各ティックは CPU／サブリクエスト予算が新たに設定された Worker の呼び出しとなるため、複数ステップの実行が、中間の Worker エグゼキューターを停止させる約 30 秒の waitUntil 制限に達することはありません。
  • state.storage 内のカーソルが冪等性と再開の基点となり、ループは中断した箇所から正確に再開します。
  • 毎ティック executions.updated_at のハートビートを記録するため、孤立プロセスの回収処理は、ティックを実行中のランを稼働中とみなし、実際に応答が途絶えたランのみを回収します。
  • DO の実行環境では、1 回のランのすべてのティックで同じモデルが固定されます。

メリット

  • オンデマンドのサーバーレス実行で、常時稼働のコンピューティングリソースも、ウォーム状態の維持も不要です。
  • 長時間の実行やエビクションに強く、正規かつ推奨されるクラウド実行環境です。
  • Claude Agent SDK のループを完全にサポートします。ツールごとのタイムライン、ステアリング／チャット、承認ゲートを利用できます。

デメリット

  • シェルがありません。ビルドやテストを自ら実行できないため、完了前の正しさの検証はエージェントではなく CI が行います。
  • ティックごとにオーバーヘッド（アラームのスケジューリング、状態の復元）が発生するため、非常に長く会話が多い単一セッションでは、永続プロセスより効率が低くなります。
  • Gateway 経由で接続されたテナントの Anthropic キーが必要です。

CloudRunnerDO のバインディングが存在しない場合、代替エグゼキューターはありません。ディスパッチの解決結果は unavailable となり、その理由とともにランは即時に失敗します。以前は暫定的な代替手段として、リクエスト内で実行される Worker エグゼキューターがここに記載されていました。しかし、複数ステップの実行では約 30 秒の waitUntil 制限を超えられず、選択可能ではなかったため削除されました。タスクの途中でひそかに終了して孤立プロセスとして回収されるよりも、「エグゼキューターがバインドされていません」という明確なエラーのほうが適切です。

クラウドエージェント（Node／コンテナ）— サーフェス container

実際の Cloudflare Container（AgentContainerDO）内で永続的な Node プロセスとして動作する Claude Agent SDK のループです。コンテナは小規模な HTTP サーバーを起動します。DO は Cloudflare Containers のコントロールプレーンとして、コンテナを起動・停止し、実行をプロキシします。コンテナがループを実行し、各 LLM ステップ、リポジトリのテレメトリー、最終的な PR のために Worker を呼び出すため、Gateway、使用量の計測、PR の最終処理における唯一の信頼できる情報源を Worker に維持できます。

機能

  • 実際のシェル（run_command）：リポジトリをクローンし、依存関係をインストールし、実際のビルド／テスト／Lint を実行して、完了前に検証します。
  • 永続プロセス — ティックごとのオーバーヘッドなしで、非常に長いタスクを継続的に実行します。
  • コンテナ内から Gateway と GitHub に接続するための enableInternet。最後のリクエスト後も 20m はウォーム状態を保ち、その後スリープして課金を停止します。
  • 明示的にピン留めされたホストが割り当てられるサーフェスでもあります（リレー経由で到達する長時間稼働のランタイム）。

長所

  • 真のエンドツーエンド検証（CI だけに頼らず、エージェント自身がビルド／テストを実行します）。
  • 長時間実行、継続的な作業、またはシェルを多用する作業に最適です。

短所

  • コンテナインフラは今後構築予定です。 実装されるまでは、container の実行は 耐久 DO にフォールバックしてクラウドで実行されるため、現時点ではこの選択をしても実際に永続シェルは利用できません。
  • 最も負荷が高く、コストのかかるサーフェスです（常時稼働に近いプロセス、ウォーム状態維持の課金）。
  • 耐久サーフェスと同じく、Gateway／テナント別 Anthropic キーが必要です。
ディスパッチ時にタイプが選択される仕組み

resolveCloudAgent は ide_agents からエージェントの runtime_surface を読み取ります（エンジンは常に現在のバージョンを使用し、読み取りません）。続いて resolveCloudSurface(agentSurface, hasExplicitHost) がサーフェスを選択します。明示的にピン留めされたホストの場合は container、それ以外の場合はエージェントが選択したサーフェスとなり、指定がなければ durable が使われます。cloudAgentTypeLabel(surface) は実行の帰属表示に使われるラベル（Cloud Agent (Durable Object)／Cloud Agent (Node/Container)）を生成します。

LLM サーフェス

Builderforce には 3 種類の異なる LLM システムがあり、混同しやすいうえ、それぞれコードパスが異なります。適切なシステムを対象に作業してください。

#サーフェス内容ステータスエントリーポイント
ALLM Gatewayフェイルオーバー、クールダウン、テナント別予算に対応した、複数ベンダー向けのホスト型チャットプロキシです。IDE Brain チャットと Studio のプロンプト拡張を支えます。✅ 提供済みapi/src/application/llm/、DONE.md（Gateway の PRD は提供済み。残作業は ROADMAP.md を参照）
Bカスタム LLM サポートユーザーがファインチューニングした LoRA エージェントを builderforce CLI に提供します（POST /api/agents/:id/chat）。🟡 仕様策定済み — P0 の未対応項目あり（下記参照）下記の「## Custom LLM Support」セクション
CIDE 内の llm モダリティブラウザーでカスタムモデルを構築・トレーニング（データセット → WebGPU LoRA／Mamba → 公開）してから、チャットします。🟢 クラウドパスは稼働中。ローカル／ハイブリッドは未対応frontend/src/lib/modality.ts、LlmStudioPanel.tsx

IDE 内モダリティ（C）のクラウド推論は Gateway（A）経由でルーティングされます。（C）のオンデバイス ローカルおよびハイブリッド推論は、Mamba WGSL カーネルと R2 の重みが用意されるまで利用できません。統合ギャップ一覧を参照してください。

カスタム LLM サポート

IDE 仕様の参照先： リポジトリのルートにある ide-architecture (1).md — Builderforce.ai IDE アーキテクチャドキュメント（v2.0、2026 年 3 月）。

このセクションでは、IDE で構築したカスタム LLM を完全にサポートするために、Builderforce.ai プラットフォーム（IDE フロントエンドと Cloudflare Worker バックエンド）に必要な変更をすべて説明します。 これにより、ファインチューニングしたエージェントを本番環境で保存、提供、バージョン管理し、builderforce CLI クライアントから利用できるようにします。

現状と必要な状態
現在利用できるもの
コンポーネント状態備考
ブラウザー内 LoRA トレーニング（WebGPU）✅frontend/src/lib/webgpu-trainer.ts
R2 でのアダプター保存✅artifacts/{projectId}/{jobId}/adapter.bin
Workforce Registry（公開／閲覧）✅POST /api/agents、GET /api/agents
エージェントパッケージのダウンロード✅GET /api/agents/:id/package → v1.0 JSON
AI チャット推論✅POST /api/ai/chat → Cloudflare AI / OpenRouter
Mamba State Engine（ブラウザー内）✅frontend/src/lib/mamba-engine.ts
Agent Runtime SDK（ブラウザー内）✅frontend/src/lib/agent-runtime.ts
不足しているもの
課題影響優先度
カスタムエージェント用の推論エンドポイントがないbuilderforce CLI でトレーニング済みエージェントを実行できないP0
推論サーバーに LoRA アダプターの読み込み機能がないトレーニングで .bin が生成されるが、配信するものがないP0
DB／パッケージに mamba_state がないv2.0 エージェントのメモリを往復同期できないP0
CLI 認証トークンがないCLI から Builderforce 推論 API を呼び出せないP0
POST /api/ai/chat が model フィールドを無視するworkforce-<id> にルーティングできないP1
エージェントのストリーミング推論がないCLI に SSE チャンク応答が必要P1
API キーごとのレート制限がない推論エンドポイントが悪用される可能性があるP1
エージェントパッケージ v2.0 がないダウンロードに Mamba state が含まれないP1
エージェントごとの使用状況追跡がないカスタムモデルの使用状況に対して課金や監視ができないP2
モデルアーティファクトのバージョン管理がないアダプターの世代を区別できないP2
データベーススキーマの変更
agents テーブル — 新しい列
ALTER TABLE agents
  ADD COLUMN package_version  TEXT    NOT NULL DEFAULT '1.0',
  ADD COLUMN mamba_state      JSONB,
  ADD COLUMN inference_mode   TEXT    NOT NULL DEFAULT 'base',
  --   'base'    → use base_model directly (no adapter)
  --   'lora'    → load LoRA adapter from r2_artifact_key
  --   'hybrid'  → LoRA + Mamba state injection
  ADD COLUMN request_count    INTEGER NOT NULL DEFAULT 0,
  ADD COLUMN last_used_at     TIMESTAMPTZ;
新しい cli_api_keys テーブル
CREATE TABLE cli_api_keys (
  id            TEXT PRIMARY KEY,
  user_id       TEXT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  key_hash      TEXT NOT NULL UNIQUE,
  label         TEXT,
  scopes        TEXT NOT NULL DEFAULT 'inference:read',
  last_used_at  TIMESTAMPTZ,
  request_count INTEGER NOT NULL DEFAULT 0,
  rate_limit    INTEGER NOT NULL DEFAULT 1000,
  created_at    TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  revoked_at    TIMESTAMPTZ
);

CREATE INDEX cli_api_keys_user_idx ON cli_api_keys(user_id);
CREATE INDEX cli_api_keys_hash_idx ON cli_api_keys(key_hash);
新しい agent_inference_logs テーブル
CREATE TABLE agent_inference_logs (
  id              TEXT PRIMARY KEY,
  agent_id        TEXT NOT NULL REFERENCES agents(id) ON DELETE CASCADE,
  cli_key_id      TEXT REFERENCES cli_api_keys(id) ON DELETE SET NULL,
  model_ref       TEXT NOT NULL,
  prompt_tokens   INTEGER,
  completion_tokens INTEGER,
  latency_ms      INTEGER,
  status          TEXT NOT NULL,
  error_message   TEXT,
  created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX agent_inference_logs_agent_idx ON agent_inference_logs(agent_id);
CREATE INDEX agent_inference_logs_key_idx   ON agent_inference_logs(cli_key_id);
新しい Worker ルート
POST /api/agents/:id/chat — エージェント推論

OpenAI 互換のチャット補完リクエストを受け付け、エージェントの LoRA アダプターを解決して推論を実行し、トークンをストリーミングで返します。

app.post("/api/agents/:id/chat", async (c) => {
  const keyId = await authenticateCliKey(c);
  if (!keyId) return c.json({ error: "Unauthorized" }, 401);

  const agent = await db.query("SELECT * FROM agents WHERE id = $1", [c.req.param("id")]);
  if (!agent) return c.json({ error: "Agent not found" }, 404);

  const body = await c.req.json<ChatRequest>();
  const result = await runAgentInference({ agent, messages: body.messages, stream: body.stream ?? false, env: c.env });

  c.executionCtx.waitUntil(logInference({ agentId: agent.id, keyId, ...result.usage, env: c.env }));
  return result.response;
});
GET/PUT /api/agents/:id/mamba-state — Mamba State 同期
  • GET — 保存済みの Mamba state スナップショット（存在する場合）を返します
  • PUT — CLI セッションから更新された state を受け付け、.builderforce/memory/mamba-state.json とサーバー側の state を同期します
POST /api/auth/cli-key — CLI API キーの発行

推論用にスコープ設定された新しい CLI キーを発行します。有効な Web トークンが必要です。rawKey は一度だけ返され、SHA-256 ハッシュとしてのみ保存されます。ユーザーはこれを BUILDERFORCE_AGENTS_LINK_API_KEY として保存します。

DELETE /api/auth/cli-key/:keyId — CLI キーの失効
更新された Worker ルート
POST /api/ai/chat — Workforce ルーティング

workforce-<agentId> モデルのプレフィックスを検出し、エージェント推論サービスに委譲します。

// `coderclawllm/` is the legacy prefix, still accepted for existing clients.
const workforceMatch = body.model?.match(/^(?:(?:builderforce|coderclawllm)\/)?workforce-(.+)$/);
if (workforceMatch) {
  return forwardToAgentInference(c, workforceMatch[1], body);
}
return runStandardInference(c, body);

builderforce CLI は、エンドポイントを変更せずに model: "builderforce/workforce-<agentId>" を使用できます。

POST /api/agents — 公開時の Mamba State の受け付け

mamba_state フィールドと package_version フィールドを受け付けます。inference_mode を次のように設定します。

  • r2_artifact_key がない場合は "base"
  • r2_artifact_key が存在し、mamba_state がない場合は "lora"
  • 両方が存在する場合は "hybrid"
推論サービスのアーキテクチャ

Hono Worker は、次の優先順位に基づいて推論バックエンドを選択します。

1. r2_artifact_key IS NOT NULL AND inference service available
   → Custom inference service (LoRA adapter applied)

2. base_model matches a Cloudflare Workers AI model id
   → Cloudflare Workers AI (base model only)

3. base_model matches an OpenRouter model id
   → OpenRouter (base model only)

4. Fallback
   → Return 503 with { error: "Inference unavailable for this agent" }

LoRA 推論サービスが利用できない場合、システムは適切に機能を縮退します。CLI はセッションバナーに X-Inference-Mode ヘッダー（lora | hybrid | base | fallback-base | unavailable）を表示します。

推論サービスの呼び出し経路：

builderforce CLI
    │
    ▼  POST /api/agents/:id/chat  (Hono Worker)
Cloudflare Worker (api.builderforce.ai)
    │  pre-sign R2 URL for adapter.bin (1hr TTL)
    ▼  POST https://inference.builderforce.ai/v1/lora-chat
Inference Service (GPU Worker / Durable Object)
    │  LRU-cached adapter loading, base model, LoRA application
    ▼  SSE chunks forwarded back through the Hono Worker
builderforce CLI

推奨技術スタック： Rust/Axum または Python/FastAPI、candle または transformers+PEFT、SSE ストリーミング、アダプターバイト列とロード済みモデル用の LRU キャッシュ。

BuilderForce Agents CLI の認証
1. builderforce init  →  link wizard
2. POST /api/auth/cli-key  { label: machineName }
3. rawKey saved to ~/.builderforce/.env as BUILDERFORCE_AGENTS_LINK_API_KEY
4. Future requests: Authorization: Bearer <rawKey>
IDE フロントエンドの変更

トレーニングパネル（AITrainingPanel.tsx）：

  • ハイブリッドトレーニングの実行が正常に完了した後に「Export Mamba state」ボタンを追加
  • 完了したジョブに推論モードのインジケーターを表示：LoRA (r=8) 🧠 +Mamba → Hybrid

公開パネル（AgentPublishPanel.tsx）：

  • 公開ペイロードに Mamba state のチェックボックスを含める（v2.0）
  • v2.0 🧠 / v1.0 のパッケージバージョンバッジを表示
  • CLI のインストールコマンドを表示：builderforce agent install <agentId>

エージェント状態ビューアー（AgentStateViewer.tsx — 新しいコンポーネント）：

  • 右パネルに 🔬 State タブを追加し、Mamba state の概要、チャネルのヒートマップ、インタラクション履歴を表示
  • /api/agents/:id/mamba-state を呼び出す「Sync to server」ボタンを追加
API リファレンス — 新規および変更されたエンドポイント
メソッドパス認証説明
POST/api/agents/:id/chatCLI キーカスタムエージェントで推論を実行します（SSE または JSON でストリーミング）
GET/api/agents/:id/mamba-stateCLI キー保存された Mamba SSM 状態のスナップショットを取得します
PUT/api/agents/:id/mamba-stateCLI キーCLI セッションから更新された Mamba 状態を送信します
POST/api/auth/cli-keyWeb トークン新しい CLI API キーを発行します
DELETE/api/auth/cli-key/:keyIdWeb トークンCLI API キーを無効化します
GET/api/auth/cli-keysWeb トークン現在のユーザーのすべての CLI API キーを一覧表示します
メソッドパス変更
POST/api/agentsリクエストボディで mamba_state、package_version を受け付け、inference_mode を設定します
GET/api/agents/:id/packagemamba_state が存在する場合は v2.0 形式を返します
POST/api/ai/chatworkforce-<id> モデルプレフィックスを検出し、エージェント推論に委譲します
エンドツーエンドのフロー：カスタム LLM を介した CLI 推論
1. [CLI] Load project context → modelRef = "builderforce/workforce-<agentId>"
2. [CLI] Advance Mamba state → memoryContext
3. [CLI] POST https://api.builderforce.ai/api/ai/chat { model, messages, stream: true }
4. [Worker] Detect workforce prefix → agentId
5. [Worker] Authenticate CLI key → check rate limit
6. [Worker] Load agent from Neon → generate pre-signed R2 URL
7. [Worker] POST https://inference.builderforce.ai/v1/lora-chat
8. [Inference] Load/cache adapter → apply LoRA → stream tokens
9. [CLI] Render tokens in TUI
10. [CLI] Persist updated Mamba state → PUT /api/agents/<agentId>/mamba-state

アバターフィルター

アバターフィルターは、プロジェクトごとの信号機式（赤・黄・緑、RAG）ステータスインジケーターを主な手段として、複数の観点からプロジェクトの状況を可視化するユーザー向け機能です。この機能により、関係者はプロジェクトの健全性をすばやく評価し、適切に作業の優先順位を付けられます。

機能
機能説明
プロジェクトのステータス表示プロジェクトのステータスを色分けして表示します。
• 🟢 緑 – 健全、順調、または解決済み
• 🟡 黄 – リスクあり、遅延、または要注意
• 🔴 赤 – 阻害、重大、または即時対応が必要
監査証跡ステータスの変更はすべて audit_log に記録され、変更者と変更日時を確認できます
一覧表示と詳細表示プロジェクトは、一覧、テーブル、詳細の各表示でステータスによる絞り込みと並べ替えができます。プロジェクト詳細ページには、各ステータス変更の理由とタイムスタンプが表示され、プロジェクトごとの監査記録を詳細パネルから確認できます
ポートフォリオウィジェットポートフォリオレベルのウィジェットに、ポートフォリオ内の全プロジェクトの集計RAGステータスの概要が表示され、ポートフォリオ全体のプログラム健全性を俯瞰できます
通知設定可能な通知は、RAGステータスの区分に基づいてプロジェクトを対象にできます。たとえば、プロジェクトが黄または赤に変わったときに通知したり、リスクのあるすべてのプロジェクトについてアラートを出したりできます。ユーザーによるオプトインと保持ポリシーに従います
仕組み
  1. ステータスの割り当て： 設定可能な業務ルールに基づいて、プロジェクトにRAGステータスが割り当てられます。デフォルトのステータスは緑です。ステータスは、理由を記録したうえで手動操作により更新するか、自動ルールによって更新します。
  2. 監査記録： ステータス変更のたびに、完全な追跡可能性を確保するため、audit_log に project_id、old_status、new_status、changed_by、reason、タイムスタンプが記録されます。
  3. 表示： ポートフォリオウィジェットとボードの一覧／詳細表示に、現在のステータスと最近のステータス遷移が表示され、ステータスによる絞り込みと並べ替えができます。
  4. 通知： リスクのあるプロジェクトなどの区分を選択して、プロジェクトのステータスがしきい値を下回ったときに、ユーザーの通知設定に従って先行アラートを送信できます。
設定オプション
  • プロジェクトのデフォルトステータス： 緑（ポートフォリオまたはテナントごとに設定可能）。
  • コンプライアンスフラグ（360指標）： 360「Direction」健全性がRAGステータスメタ指標を追跡し、表示するかどうかを制御します。
  • センチメントのしきい値： プロジェクトが黄から赤に移行する条件を決めるルールです（例：最近の問題の件数、計画からの逸脱、期限超過タスクなど）。
  • 保持期間： ステータス変更に関する監査ログエントリの保持期間を設定します（テナント単位／行レベルのポリシー）。
実装段階
  1. スキーマの拡張： プロジェクトとaudit_logのレコードを拡張し、RAGステータスのフィールドと変更理由を含めます。
  2. 業務ルールと重み付け： プロジェクトのシグナル（問題、逸脱、期限超過タスク）をRAGステータスに変換するロジックを定義します。
  3. ステータス変更ワークフロー： 理由の入力を必須とする手動ステータス変更用UIウィジェットと、自動ルールに基づく遷移を用意します。
  4. 監査詳細の粒度： 正規化されたフィールド、変更の要約、自由記述のメモなど、各ステータス監査エントリの詳細度を設定します。
  5. ポートフォリオとボードの表示： RAGステータスの集計分布を表示し、絞り込みによる詳細確認ができる一覧／詳細表示とポートフォリオウィジェットを構築します。
  6. 区分ごとの通知： リスクのあるプログラムのアラートに向けて、トリガーごとの通知区分を実装します。
プロジェクト健全性ダッシュボード
  • 一覧表示と詳細表示では、ステータスピル（緑／黄／赤）を表示し、ステータスごとの絞り込みと並べ替えができます。
  • プロジェクト詳細ページには、完全な監査記録の履歴とともに、直近のステータス変更（変更者、変更日時、理由）が表示されます。
  • ポートフォリオウィジェットには、RAGステータス別の集計件数が表示され、絞り込んだプロジェクト一覧を詳しく確認できます。
  • 通知では、RAGステータス別に分類したプロジェクトグループを対象にして、先行的な健全性モニタリングを行えます。
ステータスの遷移
  • Amber としてフラグ付けされたプロジェクトは、実行可能な是正サブタスクが作成された場合、またはトリガーとなったイベントが解決された場合に、Green へダウングレードできます。
  • Red としてフラグ付けされたプロジェクトは、ブロック要因が解決され、標準ワークフローを通じてその解決が承認された後に、Green に戻せます。
  • すべての遷移は変更理由とともに監査ログに記録され、プロジェクトの健全性に関する判断の完全な履歴が保持されます。

貢献

ブランチ命名規則、PR テンプレート、コード品質ゲート、プルリクエストのライフサイクルを含む、貢献に関する完全なガイドラインについては、CONTRIBUTING.md をご覧ください。

ライセンス

このプロジェクトは MIT License の下でライセンスされています。詳細は LICENSE ファイルをご覧ください。

コメント

Markdown 対応

MCP は初めてですか？

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。