「できた」と言うのはスクリプト　自作の会社OSでエージェントを部署に分けて回す

エージェントに仕事を任せると、「終わりました」と言うのは誰か、という問いに行き当たる。ギリシャ・アテネで個人で開発するDimitris氏は、Claude CodeとCodexを部署に分けた複数のエージェントとして動かす自己ホスト型の「会社OS」OtoDockを作った。答えははっきりしていて、新しい版を出す時に「出荷できた」と宣言するのは、エージェントではなくスクリプトだ。

以下では、本人のHacker Newsへの投稿とコメント、GitHubのREADMEとリリースノートから、その仕組みを順に見ていく。モデルに何を任せ、何をコードと人の手元に残しているかが読みどころになる。

会社OSで、会社OS自体を作る

Dimitris氏は2026年9月9日、Hacker Newsの「Show HN」に投稿し、会社OSを作り、自分の事業を回すのにも使っていると書いた。会社OSと呼ぶのは、エージェントを部署に分けて置き、会社の組織のように仕事を割り振る仕組みだからだ。人が一人でも、エージェントの側に部署と役割を持たせれば、小さな会社のように仕事を分けられる。

OtoDockのREADMEによると、OtoDock自体もOtoDockの上で動くエージェントが書き、試験し、出荷している。作る道具と、その道具で回す仕事が同じ仕組みの上に乗っている形だ。仕組みに穴があれば、まず自分の開発が止まる。自分で使い続けることが、そのまま仕組みの試験にもなっている。なお、本人の事業の中身は、公開のページでは確かめられなかった。

土台は決まった手順のコードで組む

仕組みの土台について、Dimitris氏は9月10日のHacker Newsのコメントで、決まった手順のコードで組み、モデルは1回の作業の中でだけ動くと説明した。定時の仕事はcronで起こし、外からの起動はWebhookで受ける。権限はツールごとの関門で確かめ、通さない側を既定にする。費用の上限は、利用者ごととエージェントごとに持つ。

いつ動くか、何に触れてよいか、いくらまで使ってよいかは、どれもコードの側が決める。モデルが受け持つのは、起こされた1回の作業の中身だけだ。モデルに全体の流れを任せず、流れの枠をコードで固めてから、その中でモデルを動かす作りになっている。

モデルの出力は、同じ頼み方でも毎回同じになるとは限らない。だからこそ、毎回同じであってほしい部分、つまり起動の時刻や権限や費用の上限をコードの側に寄せている、と読める。モデルの出来が揺れても、仕組み全体の動きは揺れにくくなる。

出荷の完了はスクリプトが宣言する

新しい版を出す手順も、同じ考え方でできている。Dimitris氏は9月10日の別のコメントで、出荷の手順は全ての関門を持つスクリプトで、試験と検査を流し、1つでも外れれば出荷を断ると書いた。そのうえで「エージェントは出荷完了を宣言できず、スクリプトが宣言する」と述べている。エージェントがどれだけ自信を持って「できた」と言っても、試験と検査が通らなければ版は出ない。

出荷する物そのものにも、後から確かめられる記録を付ける。10月13日付のv1.8.0のリリースノートによると、出荷するコンテナイメージはGitHubの上で作り、版の印を付ける前に起動して確かめる。そのうえで、署名つきの由来の証明と、部品表（SBOM、中に入っている部品の一覧）を付ける。利用者は「gh attestation verify」で検証できる。ここでも判定の材料は、エージェントの申告ではなく、誰でも後から確かめられる記録だ。

出荷の判定を、作業したエージェント自身の報告から切り離している点が、この仕組みの芯になっている。エージェントが書いたコードを、エージェントではない手順が通すかどうか決める。書く役と判定する役が分かれているので、片方の思い込みがそのまま外に出ることは起きにくい。

部署と権限と承認で、持ち場を区切る

エージェントの持ち場は部署で分ける。READMEと9月9日の本人のコメントによると、エージェントを部署に入れると、仕事を任せてよい向き（下だけ、下と横、全方向、なし）が自動で決まる。人はエージェントごとに管理者・編集者・投稿者・閲覧者の4つの役割を持ち、各エージェントには管理者が割り当てたツールとスキルしか見えない。見えない道具は、使いようがない。

人の承認の扱いも、版を重ねて細かくなった。10月25日付のv1.9.0のリリースノートによると、v1.9.0ではツールに付けたラベルで動き方を分けた。読むだけと印の付いたツールは聞かずに動く。それ以外は、「確認する」方式なら人に聞き、「自動」方式なら取り消せる物だけを動かして、残りは見直しに回す。部署の変更など6つの操作は、どの方式を選んでも必ず人に聞く。任せる範囲を広げても、組織の形を変える操作だけは人の手元に残る。

通して見ると、OtoDockは三つの層で仕事を区切っている。流れの枠を決めるのはコード、出荷の可否を決めるのはスクリプト、組織や設定を変えるのは人だ。エージェントはその枠の中で、割り当てられた道具だけを使って働く。

編集部の見方

取り入れるかは別として、まず理解するなら、エージェントに「できた」と言わせず、決まった手順のスクリプトに判定させるという分け方を見てみるといいかもしれない。Claude CodeやCodexで仕事を回しているなら、モデルが動く範囲と、コードが決める範囲の境目がどこにあるかを書き出す手がかりになる。OtoDockでは、その境目がcronとWebhookによる起動、ツールごとの関門、出荷のスクリプトの三か所に置かれている。