Articles

単一AIではなく実行基盤で考える AI開発環境とUNIX哲学

Published: 2026-03-16 · First published on X

AI コーディングツールを使い始めると、すぐに「どのモデルが強いか」より厄介な問題にぶつかります。複数の AI をどう分業させ、どうつなぎ、どこでレビューさせるか。つまり、開発環境そのものをどう設計するかです。

結論から言うと、AI 開発環境は単一の AI ではなく、役割を分けた複数の AI と実行基盤として設計した方が安定します。ここで言う安定とは、レビュー観点を分離しやすく、途中成果物を追跡しやすく、責務衝突を切り分けやすいという意味です。

単一AIの限界

単一 AI で完結させると、生成の癖も、レビューの観点も、そのモデル 1 つに引っ張られます。

コードを書く能力と、設計を疑う能力と、差分を判定する能力は同じではありません。ここを 1 つのモデルにまとめると、出力の方向も失敗の仕方も似てきます。

ここで言う回答空間とは、ある問いに対して AI が出しうる答えの広がりです。問いが曖昧なほど回答空間は広くなり、単一モデルだけで閉じると最も典型的な答えに寄りやすくなります。だからこそ、生成だけで閉じず、review と role 分離を入れた実行基盤が効きます。

この記事自体も単一の AI で一気に整えたのではなく、複数の AI でレビューしています。実際、この原稿の review では、ある reviewer は「マルチ AI の方が安定する」という主張の根拠不足を指摘し、別の reviewer は UNIX 哲学の導入部の言い換えが重なっていると指摘しました。単一 AI で生成と自己レビューをまとめていた段階では、この 2 種類の欠陥は十分に分離されませんでした。

これは generate / review / fix を分けると、生成時には見えなかった別種の欠陥が review 側で露出しやすくなるからです。同じ原稿でも、review という役割を生成から分離し、さらに reviewer を複数モデルに分けると、別の観点からの指摘を取り込みやすくなります。

単一 AI の構造は単純です。

Issue
  │
  ▼
Model
  │
  ▼
Output

この形は速いですが、生成のあとに別の視点が入りません。短い探索、使い捨てスクリプト、設計責務が薄い作業ならこれでも十分です。逆に、設計判断、レビュー観点、並行作業が増えると、単一 AI だけでは不安定さが目立ちます。

必要なのはモデルではなく層

AI 開発環境を一般化すると、必要なのは 1 つの賢い画面ではありません。少なくとも次の 5 層です。

Human
  │
  ▼
Entry UI
  │
  ▼
Orchestrator
  │
  ▼
Resolver
  │
  ▼
Runtime / Workspace

Entry UI: 人間が issue を渡し、結果を確認する入口
Orchestrator: issue を分解して role ごとの仕事にする
Resolver: role に応じて model や policy を解決する
Runtime: 実際に AI を動かす層
Workspace: 各 issue の作業場所を分離する層

任意の管理 UI でよいのですが、自分の環境では Conductor をこの Entry UI として使っています。Conductor は自分が使っている管理 UI / 入口であって、execution fabric、つまり実行基盤全体そのものではありません。実際の責務は、下の Orchestrator、Resolver、Runtime、Workspace に分かれています。

この順序で見ると、Conductor のような固有ツールはあくまで 1 つの実装例です。先に抽象的な層を定義しておけば、UI を差し替えても実行基盤の設計は崩れません。

なぜ role と resolver を分けるのか

役割分離が効くのは、AI の仕事が 1 種類ではないからです。

Issue
  │
  ▼
Orchestrator
  │
  ▼
Role
  │
  ▼
Resolver
  │
  ▼
Runtime

ここで重要なのは、Skill が直接モデル名を知らなくてもよいことです。Skill は reviewer や implementer のような role を表現します。Resolver はその role を受け取り、registry を引いて対応する model を解決します。

skill: review
role: reviewer

Resolver はこの role を受けて、たとえば次のような registry entry から実モデルを解決します。

role: reviewer
model: codex

role: implementer
model: claude

こうしておくと、モデル変更がコード変更ではなく運用変更になります。generate に向く model、review に向く model、fix に向く model を、registry / resolver 経由で切り替えられるからです。

具体的には、Orchestrator が 1 つの issue を implementer と reviewer に分け、Resolver が reviewer に対して review 向きの model を割り当てます。単一 AI では 1 つの偏りに引っ張られるところを、role と model の分離で崩せます。

なぜ UNIX 哲学と相性がいいのか

UNIX 哲学との相性が良い理由は単純です。UNIX は、小さな道具を分け、共通 interface でつなぎ、途中結果を観察可能に保つ設計だからです。

今回の文脈では、少なくとも次の 3 原則が効きます。

役割を小さく分ける
file / CLI を安定 interface にする
artifact を残して再実行可能にする

Bell Labs の UNIX 論文では、pipe は ordinary file と同じ read / write の規約で扱える channel として説明されます。Ritchie と Thompson の "The UNIX Time-Sharing System"（1974）や、Ritchie の retrospective でも、shell、I/O redirection、pipes が user interface の基礎として語られています。つまり UNIX の強さは、大きな統合アプリではなく、単純な接続規約にあります。

この 3 原則を AI 実行基盤に当てはめると、構造はこうなります。

CLI / Shell
  │
  ▼
planner / coder / reviewer / tester
  │
  ▼
issue.md / plan.md / patch.diff / report.md

例えば cat issue.md | plan-agent > plan.md のように計画を作り、plan.md をもとに patch.diff を生成し、その結果を report.md に残す、という流れです。AI を賢いコマンドとして扱い、成果物を file として残す形です。途中の plan.md を人間が書き換えてから次に進めることもできるので、全自動と手動介入の境界も保ちやすくなります。

この形が良いのは、途中結果を確認しやすく、再実行しやすく、置き換えもしやすいからです。artifact が残っていれば、どの reviewer が何を指摘し、どの patch がどう変わったかを追えます。ここに registry / resolver を組み合わせると、UI と execution fabric を分けたまま運用できます。

運用では workspace 分離が効く

AI を使うと複数の issue を同時に処理したくなります。ただし、複雑な開発を完全並列で安全に進めるには、まだ責務衝突が起きやすいです。

だから基本原則はこれです。

1 issue = 1 workspace

既存 repo と履歴を共有したいなら worktree を使い、依存や権限を完全に切り離したいなら別 repository を使います。Conductor を入口として使う理由の 1 つも、この workspace 分離を扱いやすいからです。

git worktree は単なる Git の小技ではありません。AI ごとに workspace を分ける isolation layer です。複数の issue を同時に扱うなら、この分離がないと差分も責務も混ざります。逆に worktree を分けておくと、reviewer は patch を見ることに集中でき、implementer は別 issue の変更に引きずられにくくなります。

単一 AI で十分な場面はあります。しかし、review 観点を分けたい、複数の role を並行させたい、作業途中の artifact を残したい、という瞬間から、単一 AI より multi-role な execution fabric の方が安定します。

最小構成で始めるなら、入口 UI は何でもよく、artifact は file に残し、reviewer は generator と分ける。この 3 点だけでも、単一 AI で閉じる運用よりかなり扱いやすくなります。

まとめ

AI 開発環境は、単一 AI かどうかよりも、役割分離された実行基盤として設計されているかどうかで安定性が変わります。

見るべき対象は model 単体ではなく、entry UI / orchestrator / resolver / runtime / workspace の接続です。Conductor はその入口になりえますが、本質は UI ではありません。小さな role、file / CLI の共通 interface、artifact を残して再実行可能にする運用です。

UNIX 哲学は古い比喩ではなく、いまの AI 開発環境を設計する時にもそのまま効きます。大きなアプリとして閉じるより、小さく分けて、つないで、残す。その方が multi-AI はうまく動きます。