個人用コンピューターの中の会社

複数エージェント構成は、単なる道具ではなく小さな組織に近づく。共有基盤、差し替え可能な実行エンジン、計画担当、実装担当、レビュー担当、承認担当、調整担当、運用担当を個人用コンピューターに置く未来を考える。

1. 形は組織的になる

複数のエージェントが関わり始めると、比喩が変わる。最初は道具の話に見える。だが、役割、引き継ぎ、承認、記録が増えると、もっと古い形に近づく。

単一のエージェントは道具である。引き継ぎを持ついくつかのエージェントは作業の流れである。役割、レビュー、承認、経路選択、記憶、エスカレーションを持つ永続的なエージェント群は、組織に見え始める。

前の記事では、なぜ複数エージェントなのか、生き残る実行基盤としての tmux、エージェントを使った作業の背後にある二つの状態機械 を扱った。最後に残る問いは、責務を分けた後、個人用コンピューターの中に何ができるのかである。

その組織は、法律上の会社である必要はない。一人のコンピューターの中に住める。ただし運用上の形は見慣れたものになる。

• 計画担当が仕事の形を決める
• 実装担当がタスクを実行する
• レビュー担当が成果を確認する
• 承認担当が危険な操作を止める
• 調整担当が作業を振り分ける
• 運用担当が状態と信頼境界を扱う
• 一つの最上位エージェントが人間と話す

意外なのは、AI がコードを書けることではない。個人用コンピューターが組織の構造を借り始めることだ。注意は有限で、境界には危険があり、引き継ぎには根拠が要る。同じ圧力がここにも出る。

2. 人間は操作者ではなくなる

古い個人用コンピューターの物語では、人間が操作者だった。機械はコマンドを待っていた。ユーザーはクリックし、入力し、ドラッグし、コピーし、貼り付け、進捗を見守った。

エージェントを使った作業はユーザーの仕事を変える。機械はターミナル作業を続けられる。だからといって、人間がターミナルの細かさで監督し続ける必要はない。

ターミナル操作がますます AI に渡されるなら、人間はペイン、プロセス ID、シェルプロンプト、経路選択コマンドに注意を使うべきではない。人間は目標、優先度、例外、承認に注意を使うべきだ。

これは、人間を組織図の上へ動かす。ただし、上に上げた状態で判断できるだけの情報を、システムが運べる場合に限る。

ユーザーは機械のコンソールの前にいる人というより、補佐役と話す社長に近くなる。最上位エージェントはすべてのキー入力を報告する必要はない。判断面を報告すればよい。

• 何が動いているか
• 何が詰まっているか
• どの判断が必要か
• どのリスクが変わったか
• どの成果物を読むべきか
• 何を割り込みなしに安全に進められるか

だから人間に見える画面は、装飾的にならずに狭くなれる。働いている会社の最高経営責任者は、あらゆる引き継ぎ、待ち行列、小さなタスクを自分で管理しない。必要なのは、目標、例外、承認、根拠、優先度の変化をまとめた報告面である。エージェントを使った個人の作業環境も同じ移動をすべきだ。詳細を見せることはできる。しかし既定の人間向け画面は、装飾された安心感や細かなタスク管理ではなく、上位者のレビューのために作られるべきである。

3. 中間管理役は冗談ではない

「中間管理エージェント」という言葉は好意的には聞こえない。しかし実行が広がり始めると、複数エージェントのシステムに必要なのは、まさにその役割である。

誰かが作業を集約しなければならない。ある実装担当はレビュー待ちで、別の実装担当は検証に失敗し、三つ目は進められ、四つ目は本番データに触れるべきではない、ということを誰かが知っていなければならない。どの詳細を人間に上げる価値があるかを、誰かが判断しなければならない。この役割がないと、人間には沈黙か、すべてのペインの生ログが届く。

それが管理である。

小さな構成では、この役割は調整担当と呼ばれることが多い。大きな構成では、複数の層があるかもしれない。

• プロジェクト調整担当
• レビュー調整担当
• リリース調整担当
• 承認調整担当
• 運用担当

名前より流れを見るほうがよい。実行は広がり、状態は集約される。判断は、それを責任を持って下せる層へ移動する。

人間の組織は、注意力が有限だからこの形を発明した。エージェントの組織も同じ理由でそれを再発見する。

4. 承認担当

承認担当が必要なのは、実装担当が実行できるからといって実行すべきではない操作があるからだ。実行能力は承認ではない。

削除、デプロイ、認証情報の変更、本番データへの書き込み、外部公開、取り消しにくい移行、公開コメント、ブランチ公開は、ローカル下書きを編集するのとは危険の性質が違う。実装担当は実行が得意でも、取り消しにくい操作を進めるかどうかを決める主体としては不適切な場合がある。

だから承認担当は別の役割になる。勢いを止めてよい場所が、システムには必要である。

この分離だけでシステムが安全になるわけではない。承認は OS のサンドボックスでも権限モデルでも安全性の証明でもない。記録された判断境界である。要点は、危険な行為を別の状態遷移に通すことだ。

1. 行為を要求する
2. 理由と影響範囲を説明する
3. 承認または却下を得る
4. 判断を記録する
5. 承認された場合にだけ進める

作業が小さいうちは事務的に見える。エージェントが高速で、永続的で、多くのローカル資源にまたがって動けるようになると、これは不可欠になる。

5. 運用担当

運用担当が必要なのは、状態と境界が増えるからだ。ローカルなエージェント作業環境は、スマートフォン、非公開ネットワーク、GitHub、認証情報、本番操作が可能な道具に触れた時点で、一つの部屋ではなくなる。

非公開メモと公開リポジトリの境界。ローカルのチェックアウトと遠隔サーバーの間。ローカルのターミナルセッションとスマートフォンや Telegram の表示面の間。Tailnet の閲覧面と広いインターネットの間。GitHub での公開とローカルメモの間。本番データとテスト用データの間。認証情報、ログ、生成された差分、人間の承認の間。

運用担当は連絡担当だけではない。連絡担当は文面を動かす。運用担当は、前提が変わる境界を越えて文脈を運ぶ。誰がデータを見られるか、誰が実行できるか、何が監査されるか、何を取り消せるか、影響範囲はどれくらいか、という前提である。

非公開ネットワークとローカル実行は役に立つが、信頼境界を消すわけではない。Tailnet は露出を減らせるが、スマートフォンからのすべての操作を安全にするわけではない。ローカルターミナルは作業をユーザーのファイルの近くに置けるが、それでも秘密情報や本番操作が可能な認証情報を保持している。公開 GitHub コメントはローカル下書き編集と同じ種類の行為ではない。

同じ規律は状態にも当てはまる。実行時の事実、プロジェクトの記憶、エスカレーション方針を一つの入れ物に潰してはいけない。実行時の層は何が起きたかを記録する。メッセージ配送、セッション状態、承認、失敗である。プロジェクトの記憶は、よりゆっくり変わる文脈を保存する。先例、判断、フィードバック、レビュー記録である。エスカレーション層は、スマートフォン、Telegram、GitHub、本番システム、人間の承認境界のどれを越えようとしているかを判断する。これらの層を混ぜると、システムは監査しにくくなり、批判されやすくなる。

作業環境がネットワーク化されても、この区別は残さなければならない。Telegram 連携、スマートフォンのダッシュボード、SSH 経由の遠隔接続、Tailnet の閲覧面、ブラウザ上のファイルレビュー、GitHub での公開、ローカルシェル実行は、それぞれ異なる信頼前提を持つ。

運用担当の仕事は、その前提を見える状態に保つことだ。越えようとしている境界、変わる権限や読者、引き継ぎと一緒に運ぶべき根拠、まだ人間の承認門を必要とする行為を名指しすべきである。これは運用上の設計規則であり、システムが安全であることの保証ではない。

6. なぜ個人用コンピューターはまだ重要なのか

システムが組織に似てくると、組織全体をクラウドに置きたくなる。一つのホストされた場所、一つのアカウント境界、一つの画面。魅力は分かりやすい。

その一部はクラウドに住むだろう。モデル呼び出しはすでにそうだ。チーム向けシステムは実行基盤のより多くを集中管理するかもしれない。しかし個人の作業では、個人用コンピューターは自然な本部であり続ける。ここでの「個人用コンピューター」には、ユーザー自身が管理する機械も含む。ノート PC、デスクトップ、自宅サーバー、ユーザー自身の運用環境の近くに残る遠隔ホストである。

理由は文脈への近さである。価値ある状態はモデルの会話の中だけにあるのではない。ユーザーの運用環境のあちこちに、すでに散らばっている。

ユーザーの個人用コンピューターや本人が管理するサーバーには、リポジトリ、メモ、設定ファイル群、SSH 用の認証情報、ローカルスクリプト、ブラウザ近くの成果物、テスト環境、プロジェクトのチェックアウト、書きかけの下書きがすでにある。それは単なる機器ではない。蓄積された運用環境である。

AI サブスクリプションは知能を提供できる。個人用コンピューターは、ユーザーの実生活の作業記憶を提供する。

だから、Claude Code と Codex のどちらを選ぶかは、時間とともに中心的な問題ではなくなるかもしれない。両方が同じ tmux や herdr の土台に座れるなら、個人用コンピューターは一つのベンダーのコマンドラインを中心に組織を作らない。ユーザーの永続する作業台を中心に組織を作り、異なるエージェント実行系を交換可能な人員として利用できる。

提供者側の制約があるから、この振り分けが効く。個人の AI 作業は、今でも料金体系、契約、トークン予算、利用制限、サービス可用性に左右される。個人用コンピューターの中の小さな会社は、組織全体の状態を移動せずに、費用が合い、利用でき、タスクに合う実行系へ作業を割り当てられるべきだ。

だから私は混合型になると予想している。

• モデルは遠隔のサブスクリプションかもしれない
• 実行はユーザー自身の機械や本人が管理するサーバーの近くに残る
• 状態は可能な限りローカルファイルとローカルサービスに住む
• スマートフォン、ブラウザ、音声は人間向けの面になり、多くの場合 SSH や非公開ネットワーク越しに使われる
• ターミナルプロセスは機械向けの面として残る

AI 組織は、作業がある場所に住む。

7. herdr と postman が示すもの

herdr と tmux-a2a-postman は同じ種類の道具ではない。しかし二つを合わせると、組織化の方向が見えやすくなる。一方は組織に実行場所を与え、もう一方はメールと責務を与える。

herdr はターミナル作業空間をよりエージェント認識的にする。公式ドキュメントは作業空間、タブ、ペイン、エージェント状態、永続化、遠隔接続、連携機能、プラグイン、socket API を説明している。それは組織の実行面である。エージェントと人間が実際のターミナル作業を見て、制御し、復旧できるようにする。

postman は引き継ぎを明示的にする。役割に名前を与え、宣言された辺を通じてメッセージを配送し、アーカイブを保存し、返信責務を追跡し、待機中や保留中の状態を見えるようにする。それは組織の調整面である。一つのエージェントの現在の文脈枠や、一人の人間のペイン記憶に作業が完全依存するのを防ぐ。

二つを合わせると、同じ未来が見えてくる。

• ターミナルセッションは執務室になる
• ペインは机になる
• エージェントは実装担当やレビュー担当になる
• メッセージの経路は社内便と責務台帳になる
• タスク成果物は案件記録になる
• レビューと承認は門になる
• 人間は受付窓口と話す

比喩は不完全だが、運用上の構造を指している。

8. 最上位エージェント

この構成が成熟すると、ユーザーはほとんどのエージェントと話すべきではなくなる。すべての役割と会話するなら、ターミナルのペイン問題を会話の層で再現するだけだ。

ユーザーは、ローカル組織全体の責任ある代表のように振る舞う最上位エージェントと話すべきだ。そのエージェントは、ある手順を Claude Code に、別の手順を Codex に、さらに別の手順をレビュー担当に、危険なコマンドを承認担当に委譲するかもしれない。ユーザーは通常、その振り分けを監視する必要はない。

この予測のより強い版では、ユーザーはほとんどの場合、どの実行系が動いているかも気にする必要がなくなる。Claude Code と Codex は異なる気質、統合、強みを保つかもしれない。それでも、同じ案件記録、ペイン、メール、確認、承認門の背後にいる交換可能な実装担当になる。継続性は組織が持つ。実行系は労働力を提供する。すると提供者側の制限は、作業環境全体を脅かす制約ではなく、割り当て時の入力になる。

最上位エージェントは全知である必要はない。委譲すべき時、要約すべき時、質問すべき時、止まるべき時を知っていればよい。それは魔法の知性ではなく、経路選択の判断である。

ここで社長の比喩が役に立つ。社長は組立ラインを操作しないから弱いのではない。組織が正しい事実を上に送るから、より有効になる。見える面が小さくなる理由も同じだ。各実装担当のコンソールを再現するのではなく、組織の状態を見せるべきである。問うべきは、人間が何が変わったか、責任がどこにあるか、どの境界を越えようとしているかを見られるかどうかである。

人間にとって、表示面は小さくなる。

• 目標を話す
• 要約を読む
• 成果物を点検する
• 例外を承認または却下する
• 優先順位を調整する

機械にとって、システムは大きくなる。

• 永続するターミナル実行基盤
• 複数エージェントの調整
• メールボックスとタスク状態
• レビューと承認記録
• 記憶と先例
• 遠隔閲覧と通知面

隠れた組織が作業を運ぶだけの構造を持ち、人間がまだ判断しなければならない場面を知るだけの信頼境界の規律を持つから、人間に見える画面は小さくできる。

9. 予測

将来の個人 AI 環境は、単なる補助役でも、よりよいターミナルでもない。個人用コンピューターの中にある小さな組織である。

人間は tmux に触れる必要がなくなるべきだが、tmux のような土台は今後も動く。人間は装飾的なダッシュボードを眺める必要がなくなるべきだが、システムには正確な状態が必要だ。人間はすべての実装担当を選ぶ必要がなくなるべきだが、システムには役割、振り分け、承認、根拠が必要だ。

問いは、「それは Claude Code だったか Codex だったか」から、「私のローカル組織のどの部分がこれを処理し、どんな根拠を残し、どの判断がまだ私の責任なのか」へ移る。

これは個人用コンピューターの別のモデルである。コンピューターはユーザーが操作する道具であるだけではなくなる。ユーザーの代わりに組織が働く場所になる。