AI エージェントのオーケストレーションを再考する
年末年始に Claude Code のキャッチアップをしてたと報告したが、Claude Code に実装されていく仕組みを観察していると、汎用的な AI エージェントのオーケストレーションにおける設計上のポイントがなんとなく見えてきたようにも感じた。
それは GoF によるコマンドパターンと UNIX 的な認証認可の転用。そして不確実性コーンの縮減のための追加質問ハーネスと長期記憶が重要になるということであり、 Mike Gancarz の『UNIX という考え方』で示された原則の再検討である。
つまり UNIX 哲学において示されたコマンドや認証認可の設計思想を現代的な対話型 AI インターフェイスで補完することが、AI エージェントのオーケストレーションにおいても重要な指針となっていくのではないかということだ。
UNIX コマンドが実装してきた不確実性の解消
そもそも、UNIX コマンドは Why を除いた 4W1H を明示してコンピュータに処理を依頼するように設計されている。誰のユーザー権限として、いつ、どこを対象に、何をどのように実行するか。sudo cp source.txt dest.txtというコマンドは、この 4W1H を簡潔に表現している。
しかし、すべての情報を毎回明示的に指定するのは煩雑であるため、UNIX は、引数が足りなくても「カレントディレクトリ」「デフォルト値」「対話的インタフェース」といった複数メカニズムによって、決定論的な処理になるまで不確実性を補完する仕組みを実装している。これらのメカニズムは、ユーザーが本質的な情報だけを指定すればよいように設計されており、UNIX コマンドの使いやすさの基礎になっている。
AI エージェントにおいても同様の不確実要素の削減が必要になってくるが、この時に一番必要なのは、UNIX コマンドにおいてはオミットされていた Why の提示である。UNIX コマンドでは、Why（なぜその操作をするのか）は通常、明示的に表現されない。ユーザーは自分の意図を理解しており、コマンドはその意図を実現するための手段に過ぎない。しかし、AI エージェントが自律的に動作する場合、Why の欠如は重大な問題を引き起こす。
例えば、「テストを実行して」という指示に対して、AI エージェントは「なぜテストを実行するのか」を理解する必要がある。デバッグのためか、デプロイ前の確認か、CI/CD パイプラインの一部か。Why を理解することで、テスト失敗時の対処方法（エラーを報告するだけか、原因を調査するか、修正を試みるか）が変わってくる。
/dig プラグインが「仕様が不明瞭な部分への選択肢付きの深掘り質問」を行うのも、この Why を明確にするためである。ユーザーの「よしなに」という曖昧な指示の背後にある意図を、段階的な質問によって明確化していく。これは、UNIX の対話的インタフェースに「意図の確認」というレイヤーを追加したものと言える。
UNIX の不確実性解消メカニズムの詳細
UNIX が実装してきたメカニズムは、それぞれ異なる種類の不確実性に対応している。
カレントディレクトリによるコンテキスト推論は、「どこで」という不確実性を解消する。ユーザーはcdでディレクトリを移動することで、操作の「文脈」を切り替えている。プロジェクト A のディレクトリにいるときと、プロジェクト B のディレクトリにいるときでは、同じmakeコマンドでも異なる対象をビルドする。カレントディレクトリは、ユーザーの「今の関心事」を表現する仕組みである。
デフォルト値による慣習の継承は、「最も一般的なユースケース」に対応する。cdは引数がなければホームディレクトリに移動する。grepは標準入力からデータを読む。80%のケースで同じ値が使われるなら、それをデフォルトにすることで、ユーザーは本質的な情報だけを指定すればよくなる。
対話的インタフェースによる確認と補完は、「危険な操作」「不可逆な操作」「重要な意思決定」に絞られている。rm -iは削除前に確認を求め、git commitはメッセージが指定されていなければエディタを開く。重要なのは、すべての情報を対話的に収集するのではなく、本当に必要なものだけに絞ることである。この「何を確認し、何を確認しないか」の設計が、ユーザー体験を左右する。
AI エージェントは、これら 3 つのメカニズムに加えて、Why を理解し、提示する能力が求められる。逆に言えば「なぜそれをするのか」を明確にすることで「4W1H」が関数従属的に導出され、「4W1H」が明確になれば UNIX の認証認可の決定論的システムが転用できる推移的関数従属が行われ、それこそが安全で予測可能な AI エージェントのオーケストレーションを実現していく。
Claude Code のコマンド化と UNIX 的な認証認可
UNIX システムは、ユーザー権限、ファイルパーミッション、sudo などの仕組みによって、誰が何をできるかを明確に定義してきた。これは『UNIX という考え方』で示された「過度の対話的インタフェースを避ける」という原則にも通じる。プログラムは必要な権限だけを持ち、不要な対話や確認を排除することで、シンプルで安全なシステムを実現する。
従来の CLI ツールでは、chmodでファイルの読み書き実行権限を制御し、chownで所有者を変更する。プロセスは特定のユーザー権限で実行され、その範囲内でしか操作できない。この「最小権限の原則」は、AI エージェントにも必要であり、AI エージェントが無制限に動作すると、以下のような問題が発生する可能性がある。
- 破壊的変更: 重要なファイルの削除や上書き
- 情報漏洩: 機密情報への不適切なアクセス
- リソース浪費: 無制限な API 呼び出しやストレージ消費
- スコープクリープ: 意図しない範囲への影響
これらを防ぐには、各エージェントに「できる範囲」を明示的に定義する必要がある。Claude Code でも、特定のツールや操作には事前の承認が必要になる設計がなされている。例えば、WebFetch ツールは特定のドメインにのみアクセスを許可する設定が可能で、EnterPlanMode ツールはユーザーの明示的な承認なしには実行できない。
コマンドパターンによる Web インターフェイスの再構成
コマンドパターンは、Gang of Four（GoF）の『デザインパターン』で示された行動に関するパターンの一つである。リクエストをオブジェクトとしてカプセル化し、パラメータ化や履歴管理を可能にする。これは『UNIX という考え方』の「一つのプログラムには一つのことをうまくやらせる」という原則とも符合する。コマンドオブジェクトは、一つの要求を表現し、その実行を責任を持って処理するものであり、伝統的なコマンドパターンは、以下の 4 つの要素で構成される。
- Command: 実行される操作をカプセル化したインタフェース
- ConcreteCommand: Command を実装し、Receiver のメソッドを呼び出す
- Receiver: 実際の処理を行うオブジェクト
- Invoker: コマンドを保持し、適切なタイミングで実行する
この構造により、「要求の発行者」と「要求の実行者」を分離できる。これは UNIX のシェルを通常のアプリケーションでも適用できるようにパターン化したものであり、リッチな UI を持つ Web インターフェイスであっても API エンドポイントを通じて、ユーザーまたはエージェントの要求を同じコマンドオブジェクトとして表現し、バックエンドで認証認可した上で適切なサービスに委譲することで、 安全で予測可能な操作を実現できる。
Claude Code においても、ユーザーの要求を一度コマンド化し、それが自動実行可能かどうかを管理したり、スキルやスラッシュコマンドを自作できる作りとなっているが、従来のコマンドパターンとは異なり「実行可能な状態になるまで情報を集める」という「不確実性解消フェーズ」が追加されている。コマンドオブジェクトは最初は不完全な状態で生成され、段階的に情報が追加されていき、完全な状態になってから初めて、具体的なコマンドに変換して、それを実行して良いか確認する。
この過程が「ユーザーとの対話」と「システムの推論」のバランスで成り立っていることに注目されたい。すべてをユーザーに質問すれば煩雑になり、すべてをシステムが推論すれば誤った実行につながる。Claude Code は『UNIX という考え方』の「過度の対話的インタフェースを避ける」という原則を守りつつ、必要な情報を補完的に収集することがプロダクティビティに直結するという意識で設計されていると感じる。
不確実性コーンと追加質問ハーネス
ここまでで不確実性の解消が重要であることを述べてきたが、その理論的背景として「不確実性コーン」の概念が役立つ。不確実性コーン（Cone of Uncertainty）は、ソフトウェア開発プロジェクトにおいて、初期段階では見積もりの不確実性が高く（プロジェクトの最終的なコストや期間が 4 倍から 0.25 倍の範囲でばらつく可能性がある）、プロジェクトが進むにつれて不確実性が減少していくことを示す概念である。
多くの従来型の計画立案手法は重要なことを見落としている――不確実性を踏まえていないものは計画ではないのだ。計画とは、いまこの時点で私たちが知っていることを元に立てられている。不確実性とは、目標と方法のそれぞれについて私たちがまだわかっていないことを別の言い方であらわしたものだ。ほとんどの不確実性（知識の欠落）は、具体的に何かしてみる――実践したり、開発したり、シミュレーションしたり――ことでフィードバックと知識を得なくては解消できない
従来のプロジェクト進行において不確実性を削減するためには、出来うる 4W1H を事前に設計するという非現実的な要求がなされてきたが、アジャイル開発やインクリメンタルデリバリーの考え方が浸透するにつれて、そもそも実現したかったことを明文化してから実現方法を段階的に検討して不確実性を削減していくアプローチが重要視されるようになった。
この概念は、UNIX コマンドと AI エージェントのコマンドパターンにおける不確実性解消メカニズムに敷衍できる。つまり、UNIX コマンドは 4W1H を明確にしてから入力するが、AI エージェントは「Why（なぜ）」から始まって「追加質問ハーネス」と、オンデマンドなコンテキスト補完によって、実行時点までに不確実性を段階的に削減するということだ。そして、実行結果のフィードバックをもとに追加の質問と実行が行われる。
従来の UNIX コマンドと AI 時代のツールの決定的な違いは、「曖昧性を許容する長期記憶」と「自然言語的対話」がある点である。実行依頼時点では依頼者にもなかった論点を過去と未来の実行結果を保持したコンテキストから再生成することで、ユーザーに内省を促し、その瞬間に生まれた必要だった情報を補完させる。ここにきて AI エージェントは依頼を忠実に実行する存在ではなく、意図を実現するための協働者として機能できる。
インテントベースのメモリアクセスと Everything as File への回帰
長期記憶を具体化する実装例として、Claude Code の Agent Skills を使ったエージェントメモリがある。ユーザーが「この設計判断を記憶して」と言えば構造化されて保存され、「前回の調査結果を思い出して」と言えばセマンティック検索で取得される。ファイルパスや行番号を指定する必要はない。やりたいこと（インテント）から読み書きできるメモリである。
興味深いのは、この実装が『UNIX という考え方』の核心である「Everything is a File」への回帰を示していることである。Gancarz は、UNIX の成功要因として「すべてをファイルとして扱う」という単純な抽象化を挙げている。この思想は、クラウド時代に Infrastructure as Code（IaC）として蘇り、AI 時代には Everything as Code へと進化した。そして今、セマンティックメモリストレージによって Everything as File に回帰している。
AI エージェントの記憶も、設計判断も、すべてマークダウンファイルとして保存している。ただし単なる回帰ではない。ファイルシステムという普遍的な基盤の上に、セマンティック検索という新しいレイヤーが重なることで段階的開示と遅延ロードのアプローチが実現される。
「AI エージェントのアジャイルな哲学」を確かめたい
以上までで、僕自身が感じているAI エージェント時代のツール設計における 4 つの重要なパターンについて解説してきた。
第一に、「コマンドパターン」による要求のカプセル化である。ユーザーやエージェントの要求を即座に実行するのではなく、コマンドオブジェクトとして保持し、実行可能な状態になるまで情報を集める。これにより、認可の検証、履歴管理、ロールバックといった機能が実現できる。
第二に、「不確実性コーンの段階的削減」である。カレントディレクトリによるコンテキスト推論、デフォルト値による慣習の継承、対話的インタフェースによる確認と補完、実行結果のフィードバックという階層的なアプローチで不確実性を削減しつつも、煩雑にならない範囲で最小限の質問に絞る。
第三に、「UNIX 的な認証認可の転用」である。AI エージェントのオーケストレーションにおいて、権限範囲の明示的定義は不可欠である。破壊的変更や情報漏洩を防ぎつつ、柔軟な対話的インタフェースを実現するには、UNIX が培ってきた最小権限の原則を適用する必要がある。
第四に、「セマンティックメモリストレージ」である。インテントベースで読み書きできる長期記憶により、作業の中断・再開時のコンテキスト損失を最小化できる。興味深いのは、この進化が「Everything is a File」→「IaC」→「Everything as Code」を経て、再び「Everything as File」へと回帰している点である。ファイルシステムという普遍的な基盤の上にセマンティック検索が重なり、コーディングエージェントだけでなく汎用エージェントでもコンテキストエンジニアリングの要になる。
これらは、UNIX が数十年かけて培ってきた不確実性解消メカニズムとセキュリティモデルがアジャイルと AI の補完によって柔軟かつ強固になっていったソフトウェア開発の歴史的蓄積と見ることもできる。曖昧性を許容する長期記憶と自然言語対話が注入されることで、実行時点にはなかった論点がオンデマンドに生成され、決定論的な実行に収束していく。その過程で得られた判断や文脈は、セマンティックメモリとして保存され、次回以降の不確実性削減に活用される。このように自分の中で生まれつつある「AI エージェントのアジャイルな哲学」を今後実装していく AI エージェントのオーケストレーションで PoC していきたいと考えている。すぐにチョットワカルから全然わからない！ってなりそうだけど。
