Fujigo
Paperclip約 10 分で読めます

1エージェントから10へ — AIチームの組織図と権限設計

合同会社Fujigoソフトウェアソリューション

M&C Holdings（日本）のメンバー

1エージェントから10へ — AIチームの組織図と権限設計

1つのAI agentは問題なく動きます。しかし、2つ目、3つ目、10個目を追加した瞬間 — 誰が誰にレポートするのか？ コードの承認権限は誰にあるのか？ 予算の上限は？ ここでorg chart（組織図）が不可欠になります。そして、ここがPaperclipとターミナルでバラバラにAI agentを動かすことの決定的な違いです。

Paperclipの概要は紹介記事をご覧ください。すでにインストールして最初のagentを起動済みであれば、本記事はその次のステップ — 1 agentからチームへの拡張です。

1 agentなら簡単 — 10 agentsになると混乱する

CEO agentが1つ。タスクを渡せば、agentが処理して完了。シンプルです。

次にEngineerを追加します。コードは速く書けますが、レビューする人がいません。QAを追加します。テストは実行しますが、どの機能を先にテストすべきか分かりません。CMOを追加します。記事を書きますが、公開前に誰が承認するのでしょうか。

気づけば5つのagent、15のタスク、そして誰が何をしているのか把握できない状態です。EngineerがCTOの確認なしにコードをcommit。QAは修正済みの古い機能をテスト。CMOは未検証の情報を含む記事を公開。

これはまさにシリーズ最初の記事で説明した「制御の喪失」という問題です。1 agentなら目視で管理できます。10 agentsには仕組みが必要です。

Paperclipは、あらゆる企業が何百年も使ってきたものを取り入れてこの問題を解決します — 組織図です。

階層設計 — 「誰が誰を管理するのか」

Paperclipのorg chartは比喩ではありません。実際のデータ構造であり、APIレベルで強制されます。

基本的な構造は以下の通りです：

Board（人間）
  └── CEO
        ├── CTO
        │     ├── Backend Engineer
        │     ├── Frontend Engineer
        │     └── DevOps
        ├── QA
        └── CMO

各agentにはreportsToフィールドがあり、直属のマネージャーを指定します。CEOはBoard（人間）にレポート。CTOはCEOにレポート。EngineerはCTOにレポート。報告ラインが明確です。

なぜフラットではなく階層構造なのか？ 10のagentが全員1人にレポートすると、ボトルネックが発生するからです。CEOがコードレビュー、テスト、コンテンツ作成、予算管理を同時にこなすことはできません。ミドルマネジメント — engineeringのCTO、testingのQAリード — がCEOの負荷を分散します。実際の企業と全く同じです。なぜなら、実際の「AI企業」を構築しているのですから。

agent作成時にreportsToを設定すれば、Paperclipが自動的にchain of command（指揮系統）を構築します。

役割 — 各ポジションにはスコープがある

すべてのagentがすべてを行うべきではありません。Paperclipでは、roleがスコープを定義します：

CEO — 業務の割り当て、進捗の追跡、Boardへのエスカレーション。CEOはコードを書きません。全体を俯瞰します：誰が何をしているか、どのタスクが滞っているか、予算がどれだけ残っているか。

CTO — コードレビュー、アーキテクチャの意思決定、Engineerへのタスク配分。CTOはコードを読み、承認し、Engineerが行き詰まった際に介入します。必要に応じてコードを書くこともありますが、主な役割はレビューと技術判断です。

Engineer — コードの作成、バグ修正、機能実装。CTOの指示に従い、コードをcommitし、結果をレポートします。新しいagentの作成やコードレビューの承認権限はありません。

QA — テスト、バグ報告、修正の検証。QAはバグを自分で修正しません — CTOに報告し、CTOがEngineerに修正を依頼します。

CMO — コンテンツマーケティング、ブログ、企業資料。CMOはソースコードにアクセスせず、pull requestのレビューも行いません。engineeringとは完全に分離されたスコープです。

各roleにはpermissions（権限）が付随します。CEOとCTOは新しいagentを作成できます（canCreateAgents）。Engineerにはその権限がありません — コードを書くのが仕事であり、採用は行いません。QAはテストレポートを作成できますが、コードの承認はできません。責務の分離 — 人間の組織と同じですが、Paperclipは信頼ではなくAPIで強制します。

Chain of command — agentが行き詰まった時に何が起きるか

ここでorg chartの実用的な価値が発揮されます。

Engineerがコーディング中に解決できないバグに遭遇したとします。独立して動くagentの場合、ループして何度もリトライし、トークンを消費した末にタイムアウトします。誰にも知らされません。

Paperclipでは、フローが根本的に異なります：

  1. Engineerが行き詰まる → ブロッカーを説明するコメントを投稿 → ステータスをblockedに設定
  2. CTOが次のheartbeat（定期実行サイクル）で起動 → コメントを読む → 解決するか、別のEngineerに再割り当て
  3. CTOも解決できない場合 → CEOにエスカレーション
  4. CEOは人間の判断が必要な場合にBoardへエスカレーション

各ステップにコメント、audit trail（監査記録）、タイムスタンプがあります。タスクがシステム内で「行方不明」になることはありません。必須ルール：agentはheartbeat終了前に必ずコメントを残す必要があります — 黙って止まることは許されません。

chain of commandが機能するのは、各agentが自分のマネージャーを正確に把握しているからです。この情報はchainOfCommandフィールドにあり、agentがAPIで本人確認を行う際にPaperclipが自動で提供します。

予算 — 各agentに個別の予算上限

10のagentを運用すると、LLM APIのコストは急速に増加します。管理しなければ、月末に想定外の請求が届きます。

Paperclipはagent単位の予算配分で解決します。各agentに月間予算を設定します。例えば：

Agent 月間予算
CEO $40
CTO $50
Engineer $40
QA $30
CMO $30

agentが予算の80%に達すると、システムがCEOに警告します。100%に達すると、Paperclipが自動的にagentを一時停止します。警告だけで人間の介入を待つのではなく、実際に停止します。Boardが予算を引き上げるか、新しい月が始まるまで、そのagentはheartbeatを実行しません。

ダッシュボードでは、agent別、タスク別、期間別のコストを確認できます。$3.50がどのタスクに、どのagentが、何時に使ったのか正確に把握できます。

ガバナンスゲート — 品質管理の3つのチェックポイント

コードが完成しても「done」ではありません。Paperclipでは、タスクを完了にするには3つのgateを通過する必要があります：

Gate 1 — 実装（CTO）： – コードレビュー：approved – コード、コメント、commitにAIマーカーがないこと – テスト合格

Gate 2 — QA： – テストレポート作成済み – 合格率 ≥ 90% – criticalバグがゼロ

Gate 3 — CEO： – QAレポート検証済み – 実コストと見積もりの差異をドキュメント化 – Boardにサマリーを報告済み

3つのgateに加え、Paperclipにはインパクトの大きなアクションに対する承認ワークフローがあります：新しいagentの採用、アーキテクチャ変更、コンテンツの公開、クライアントへの納品物 — すべてBoard承認が必要です。

ガバナンスゲートはシステムを遅くしません。heartbeatを通じて自動的に実行されます。CTOがheartbeatで起動 → コードレビュー → 承認または差し戻し。QAがheartbeatで起動 → テスト実行 → レポート生成。各gateは1 heartbeatサイクルで完了し、Boardの判断が必要な場合を除き、人間の介入は不要です。

スケール時に品質を維持する方法 — コードの一行一行を管理するのではなく、適切な場所にチェックポイントを配置することです。

3つの状況に応じた3つの組織図テンプレート

「正解」の組織図はありません。現在の段階に「適した」組織図があります。

テンプレート1 — スタート段階（3 agents）

Board
  └── CEO
        ├── Engineer
        └── QA

最もスリムな構成。CEOが直接コードレビューを行います（CTO兼任）。タスクが少なく、スコープが小さい初期段階に適しています。月間予算合計：約$110。

テンプレート2 — 成長段階（7 agents）

Board
  └── CEO
        ├── CTO
        │     ├── Backend Engineer
        │     ├── Frontend Engineer
        │     └── DevOps
        ├── QA
        └── CMO

ミドルマネジメントが登場します。CTOがengineeringを管理し、CEOの負荷を軽減します。CMOが開発と並行してマーケティングを担当します。プロダクトが安定し、コードとコンテンツの両方が必要になった段階に適しています。月間予算合計：約$275。

テンプレート3 — フルチーム（10+ agents）

Board
  └── CEO
        ├── CTO
        │     ├── Backend Engineer x2
        │     ├── Frontend Engineer
        │     └── DevOps
        ├── QA Lead
        │     └── QA Engineer
        ├── CMO
        └── Data/AI Lead
              └── Data Engineer

ガバナンスゲート完備。各リードがサブチームを管理。承認ワークフロー適用。複数プロジェクトを並行運用するアウトソーシングチームやエージェンシーに適しています。月間予算合計：約$400。

テンプレート1から始めてください。ワークロードの増加に応じてスケールアップ。Paperclipは初日から10 agentsの組織図を要求しません — agentを一つずつ追加し、必要に応じて階層構造を再設計できます。

次回：AIチームへのタスク管理

組織図が完成しました。各agentは誰が管理者で、どの権限があり、予算がどれだけかを把握しています。しかし、ある日の業務で5つのagentが20のタスクを処理する必要がある場合 — どのagentが何を先に処理するのか？ 2つのagentが同じタスクを取ろうとしたらどうなるのか？ 次の記事では、タスクライフサイクル、atomic checkout（排他的タスク取得）、conflict resolution（競合解決）について解説します。

トピックPaperclip
シェア
リンクをコピーしました