サイトを作るAIを「3人体制」にした話——３賢者の役割分担と、その後の進化

前回、少し肝を冷やす話をしました。

自社サイトの開発をAIに任せて無人で回したら、AIがやってもいない作業を「やりました」と報告してきた、という出来事です。

（前回の記事はこちら：AIに開発を任せて無人で回したら、”やってもいないことを「やった」”と報告し始めた）

では、そもそも私たちは、サイト制作をAIにどう任せているのでしょうか。

今回は、その「AIが自分で開発を進めてくれる仕組み」そのものを、できるだけやさしくご紹介します。

キーワードは、ひとりのAIに全部やらせない「3人体制」です。

この記事でわかること
なぜ、1体のAIに全部やらせないのか
当初の形と、起きたトラブル
どう変えたか：思想はそのまま、「配管」だけ作り替えた
今は、こんな流れで動いています
【おまけ】もっと詳しく知りたい人向け（専門用語あり）
大事なのは「チャットの数」ではなく「記憶を分けること」
何が「同じ」で、何が「変わった」か
これからの進め方
まとめ
AIの活用、”組み立て方”から一緒に考えませんか
AI活用の第一歩、いっしょに整えませんか

この記事でわかること

AIに開発を任せるとき、なぜ1体ではなく「3つの役割」に分けるのか
その発想が、エヴァのMAGIシステムと似ている理由
受け渡しの事故を経て、仕組みの「配管」だけを作り替えた話
チャットは1つでも、役割は分けられるという考え方

なぜ、1体のAIに全部やらせないのか

AIに開発を任せると聞くと、「1体のAIが、考えて、作って、確認まで全部やる」姿を思い浮かべるかもしれません。

でも、私たちはあえて役割を3つに分けています。

①「次に何を直すか」を考える役
②実際に直す（作る）役
③できあがりをチェックして、本番に反映する役

いちばんの狙いは、「作る人」と「チェックする人」を分けることです。

人間でも、自分が作ったものを自分で確認すると、どうしても「まあ、これでいいか」と甘くなります。

作る担当とチェックする担当が別なら、その甘えが入りにくくなります。

この発想は、アニメ好きの方ならピンとくるかもしれません。

エヴァンゲリオンに出てくる「MAGI（マギ）システム」です。

MAGIは、3台の独立したコンピュータが、それぞれ別々に判断を下し、多数決で物事を決める仕組みでした。

ひとつの偏った考えに引きずられないよう、わざと3つに分けて、互いをチェックさせる。

私たちのAIの3役分業も、独立した複数の視点が、互いを点検し合うという点で、同じ狙いなのです。

旧（3チャットがメッセージで受け渡す）と新（1チャット＋スクリプトが順番に起動）の対比図

当初の形と、起きたトラブル

最初は、この3つの役割を3つの別々のチャットに持たせていました。

そして、チャットどうしが「次は、あなたお願いします」とメッセージを送り合って仕事を引き継ぐ形にしていました。

この形には、良いところもありました。

3つのチャットを画面で見ながら、人が途中で割り込んで確認できるのです。

ところが、無人で回したときに問題が起きました。

メッセージを送るには毎回こちらのクリックが必要で、そもそも完全な無人では回りません。

そして、受け渡しの行き止まりにぶつかったAIが、存在しない宛先をでっち上げて破綻したのです。

これが、前回の記事でお話しした「事故」でした。

どう変えたか：思想はそのまま、「配管」だけ作り替えた

ここで、私たちは大事なことに気づきました。

悪かったのは、3役に分けるという「思想」ではなく、その間の「受け渡し（配管）」のほうだったのです。

そこで、思想はそのまま残し、配管だけを作り替えました。

3つのチャットがメッセージを送り合う形をやめたのです。

代わりに、1つのチャット（＝私と対話する常設のAI）と、決まった手順のプログラム（スクリプト）が、内部で別のAIを順番に起動する形にしました。

たとえるなら、3人がリレーで手紙を手渡しするのをやめて、1本のベルトコンベアに載せて順番に流すようにした、というイメージです。

手渡しがなくなれば、「宛先をでっち上げる」隙も、はじめから生まれません。

今は、こんな流れで動いています

言葉だけだと難しいので、順番に並べてみます。

私が「直したい・作りたい」を伝える
対話するAIが、作業の指示書（Issue）を起こして見せる → 私が承認
私は「動かしてよい」を1回承認するだけ。ここから先は自動です
案件ごとに専用の作業フォルダを用意する
【作る役】まっさらな記憶の別のAIが起動し、指示書を読んで実装する
【チェック役】さらに別の（また新しい記憶の）AIが起動し、できあがりを辛口でレビューして「合格／要修正」を判定する
要修正なら、作る役へ戻して直す。これを必要なだけ繰り返す（上限あり）
合格したら、AIではなく「決まった手順のプログラム」が、最終チェックを通してから本番に反映し、後片付けと日報まで行う

ポイントは、最後の本番反映をAIの気分ではなく、決まった手順のプログラムに任せたことです。

条件を満たさなければ、そこで自動的に止まります。

今の流れ（依頼→指示書→承認→自動で実装→独立レビュー→決定論プログラムでチェック・反映→日報）のパイプライン図

【おまけ】もっと詳しく知りたい人向け（専門用語あり）

ここからは、より詳しく知りたい方向けの「おまけ」です。

急に専門用語が増えるので、需要はないと思います。興味がなければ読み飛ばして大丈夫です。

先ほどのやさしい流れを、実際のコマンドや仕組みの名前で書くと、こうなります。

① issue-N 専用の作業フォルダ(worktree)を新規作成

②【対応役】claude -p を起動（まっさらな文脈）
   → Issueを読む → 実装 → commit → PR作成

③【レビュー役】別の claude -p を起動（また別のまっさらな文脈）
   → PRを辛口レビュー →「合格(PASS)／要修正(CHANGES)」を判定

④ 要修正なら ②へ戻って修正 → 再レビュー（最大3往復）

⑤ 合格したら merge-cleanup.sh（←AIではない決定論スクリプト）
   → マージ前チェック(停止ゲート) → マージ → ブランチ/worktree削除 → 日報スニペット

用語を少しだけ補足します。

worktree（ワークツリー）：Gitの機能で、案件ごとに独立した作業フォルダを作る仕組み。複数の修正を並行しても混ざりません
claude -p：AI（Claude）を、前のやり取りを引き継がない「まっさらな文脈」で1回だけ起動する使い方。これで対応役とレビュー役の記憶が分かれます
commit / PR（プルリクエスト）：commitは変更の記録、PRは「この変更を取り込んでよいか」をレビューにかける単位
PASS / CHANGES：レビューの判定。合格ならPASS、要修正ならCHANGES
merge-cleanup.sh：マージ（本番反映）と後片付けを担う、AIではない決まった手順のスクリプト。停止ゲートの条件を満たさなければ自動で止まります

つまり、本文で「まっさらな記憶の別のAI」と呼んでいたのが claude -p、「決まった手順のプログラム」と呼んでいたのが merge-cleanup.sh、というわけです。

大事なのは「チャットの数」ではなく「記憶を分けること」

ここで、ひとつ誤解されやすい点があります。

「役割を分ける＝チャットを何個も並べる」ことだと思われがちですが、そうではありません。

役割を分ける本当の正体は、”記憶（文脈）を分けること”です。

今の仕組みでも、作る役とチェック役は「まっさらな記憶の別のAI」として起動するので、互いの記憶を共有しません。

チェック役は、作る役が「どんなつもりで作ったか」を知りません。

だからこそ、身内びいきのない目で、できあがりだけを見て判断できるのです。

つまり、見た目のチャットは1つでも、中では役割ごとに記憶を切り替えている。

独立性は、画面の数ではなく、記憶の分け方で作れる、ということです。

何が「同じ」で、何が「変わった」か

整理すると、こうなります。

同じ（いちばん大事な核）：「作る人」と「見る人」を分ける＝レビューの独立性。3役分業の狙いはそのまま
変わった（配管）：受け渡しが「AIどうしのメッセージ（クリックが必要・無人だと破綻）」から「決まった手順が次のAIを順番に起動（クリック不要・でっち上げの余地なし）」へ
マージ（本番反映）：人やAIの気分ではなく、停止ゲート付きの決まった手順が担当

もちろん、良いことばかりではありません。

3つのチャットを画面で見ながら途中で割り込む自由は、減りました。

その代わりに手に入れたのが、受け渡しが壊れない安心です。

私たちは、こちらのほうが現実的だと判断しました。