サービス設計 / 2026/8/7 / 約5分

複数のAIに仕事を渡すとき、「誰が何を決めてよいか」を先に契約にする

この記事について

同じリポジトリで複数のAIエージェントを併走させていると、最初にぶつかる壁は技術的な衝突ではなく権限の衝突だった。「この判断は自分でやってよいのか」が曖昧なまま走らせると、勝手に踏み込んで事故を起こすか、逆に許可を待って全工程が止まるか、どちらかに倒れる。この記事は、役割ごとに「やってよいこと／やってはいけないこと」を表で固定し、工程間の受け渡し方式も決めた運用の記録。すでに公開している複数のAIエージェントが同じリポジトリで働くためのgit衛生ルールは「作業の作法」の層を扱ったが、この記事は一段上の「意思決定の所在」の層を扱う。

起きていた問題：能力ではなく権限の曖昧さ

複数のAIエージェントに記事執筆・レビュー・公開判断を分担させる構成を組んだとき、最初に想定していた課題は「どのAIにどの作業が向いているか」という能力の割り振りだった。しかし実際に運用してみると、能力より先に権限の境界があいまいなことが原因のトラブルが目立った。

あるエージェントが、本来は次工程の担当が判断すべき「公開してよいか」まで自分で決めてしまう
別のエージェントは逆に、明確に自分の権限内のはずの作業でも「念のため確認」を挟み、パイプライン全体が止まる
同じフォルダに複数のエージェントが書き込み、どちらの変更が正なのか後から分からなくなる

これらは個々のAIの能力不足ではなく、「この判断は誰の担当か」が契約として明文化されていなかったことが根本原因だった。

対処：工程ごとに「読む場所・書いてよい場所・書いてはいけない場所」を固定する

対処として、パイプラインを複数の工程（automation）に分割し、それぞれについて次の3点を表で固定した。

主に読む場所（インプットの範囲）
書いてよい場所（アウトプットの範囲）
書いてはいけない場所（越境の明示的禁止）

実際に運用している契約の骨格は、記事の生成パイプラインを5つの工程に分けている。

工程	役割	書いてよい場所	書いてはいけない場所
ネタ収集	トピック候補を集める・重複を避ける	提案の置き場のみ	公開候補フォルダ・公開済みフォルダ
編集判断	トピックの採用/保留/却下・主張の芯を決める	骨子メモのみ	公開候補フォルダ・公開済みフォルダ
初稿作成	記事初稿を作る	初稿フォルダのみ	公開候補フォルダ・公開済みフォルダ・編集方針文書
検証・昇格	構造・証拠・読みやすさを検証し合格稿だけ次工程へ上げる	検証記録・条件を満たした初稿のみ	キャラ原典・編集方針文書
時限公開	公開候補を時限で公開する（1回最大1本）	公開済みフォルダ・失敗退避フォルダ	初稿フォルダ・検証記録

ポイントは、「書いてよい場所」より「書いてはいけない場所」を明示していること。書いてよい範囲だけを決めると、境界に近い判断（「ここまでは自分の裁量内では」という解釈）が工程ごとにブレる。禁止範囲を先に固定しておくことで、越境の判断コストそのものを消している。

昇格条件（次工程に渡してよい基準）も同時に固定した。たとえば初稿から公開候補への昇格は「必須要素が揃っている・危険な断定がない・未対応のプレースホルダーが残っていない・採点基準を満たしている」といった機械判定可能な条件を並べ、判断者の主観に依存する余地を減らしている。

権限による分担、能力による分担ではない

このパイプラインとは別に、AIエージェントごとの役割分担表も運用している。

AI	位置づけ	権限の性質
編集長役（レビュー・方針判断担当）	編集長・PM・レビュー	企画判断・方針整理はするが、単独での公開判断や本番パイプライン変更はしない
実装主力（記事執筆・コード担当）	主力実装	記事執筆・コード・PR作成はするが、公開指示なしでの公開状態変更はしない
画像生成・編集担当	画像生成・編集	画像生成と保存はするが、本番パイプライン変更や単独公開はしない
外部監査役	読者目線の外部レビュー	公開前レビュー・炎上リスク検出はするが、リポジトリ前提の判断はしない

この表を作ったときに気づいたのは、効いていたのは能力による分担ではなく権限による分担だったこと。「記事を書くのが得意か」「コードが書けるか」という能力の違いは確かにあるが、事故を防いでいたのは能力差そのものではなく、「この判断は誰の担当で、誰の担当ではないか」を先に固定していたことだった。実例として、公開の最終判断は常に人間側に残し、方針そのものの変更提案は編集判断の役割に返す、という線引きを崩さないようにしている。

差し戻しのルールも契約に含める

権限の契約は「進める条件」だけでなく「差し戻す条件」も対にして決めておく必要があった。

検証工程が不合格と判定した初稿は、初稿フォルダに戻す（勝手に修正して次工程へ進めない）
差し戻しの理由は検証記録として残す(次に誰が読んでも経緯が分かる形にする)
修正担当は元の生成担当に限定し、検証担当が自分で書き換えて再提出しない(採点者が採点対象を自分で作る利益相反を避ける)
失敗として退避したものは、そのまま再公開しない

この「差し戻しの権限も固定する」という部分を後回しにすると、うまくいかなかったときに誰が直すのかが曖昧になり、結局いちばん手の空いているエージェントが権限外の修正まで引き受けてしまう、という別の越境が起きる。進める条件と同じ強さで、差し戻す条件も契約に含めておく必要があった。

やってみてわかったこと

複数のAIを併走させたときに最初に壊れるのは技術的な整合性ではなく権限の整合性だった。「誰が何を決めてよいか」が曖昧なまま能力の割り振りだけを最適化しても、事故は減らなかった
「書いてよい場所」より「書いてはいけない場所」を先に決める方が、境界のグレーゾーンでの独自解釈を減らせた
昇格条件を機械判定可能な形で書いておくと、工程間の受け渡しが「担当者の裁量」ではなく「条件を満たしたかどうか」の判定に変わり、判断のブレが減る
差し戻しのルールを進める条件と対にしておかないと、失敗時の後始末だけ権限が曖昧な状態が残る

更新履歴

2026-08-01: 初出。