デリバリーモデル

個人ではなくポッド単位で

すべての案件はバックアップ担当者を配置したポッド(チーム)単位で編成され、固定の品質ゲートを通過し、顧客がすでに所有するインフラ上に納品されます。

ポッド編成

案件規模に合わせて編成

ポッドは最小構成から、大規模案件向けの拡大構成まで対応します。具体的な役割と人数は確定次第こちらに掲載します。

最小構成ポッド

合意の上で決定

大規模ポッド

合意の上で決定

所有権

ワークスペースは顧客が所有します

Customer owns the workspace — A Build organization on the customer's own GitHub repo, and their own AgentOS tenant.

No personal-account credentials — No delivery credentials live on a personal account.

品質ゲート

すべての案件に適用される同一基準

Spec agreed first — Scope and acceptance criteria are agreed with the customer before delivery starts.

Revisions until met — Work goes through revisions until the agreed spec is met — no partial acceptance.

Two-person QA — Every deliverable passes review by a second pod member before it ships.

Gates never bypassed — The delivery lead configures Build's own quality gates for the engagement, and they are never bypassed.

Live status board — Every engagement has a live status board the customer can see.

Backup named at kickoff — A backup pod member is named at kickoff, so no engagement depends on one person.

編成プロセス

割り当てではなくマッチング

Interactorが案件に合うポッド候補をマッチングし、顧客は2〜3件の候補プロフィールから営業日10日以内に選択します。

成果物ポリシー

何を誰が所有するか

Generalized artefacts — Connectors and templates built during delivery may be offered back to Interactor for a bounty or account credit — never required.

Customer code — The customer's own code is the customer's.

マニフェスト例

デリバリーマニフェストの実例

投入した役割DM-2026-000

BuildがBuildを作る

Interactor Buildが自社プロダクトにリリースするすべての機能は、顧客に提供しているものと同じ目標 → タスク → PRエンジンを通ります。作った本人たちのための近道はありません。

  • Buildオペレーター · 1
  • レビュアー · 1
プロダクト指標
マージされた目標PR
2,018GitHub検索、InteractorOSS/product-manager · 2026-09-04計測
インシデント・ポストモーテム
7docs/incidents/、InteractorOSS/product-manager · 2026-09-04計測
作成したランブック
53docs/runbooks/*.md(最上位)、InteractorOSS/product-manager · 2026-09-04計測

結果自社プロダクトに2,018件の目標PRをリリース — それぞれが、提供しているものと同じエンジンでレビュー・マージされました。

進めたい案件はありますか?

案件に合ったポッド編成についてお問い合わせください。