DOS Kernel - trust substrate for agent fleets (stdio via PyPI)

DOS — Dispatch オペレーティングシステム

AI エージェントが成果を出したと偽ったとき、見逃さないために。

📊 実際のリポジトリでの動作を見る： スコアボード では、人気のあるAI構築リポジトリ15件（roborev、open-interpreter、crewAI、autogen、…）を評価しています。 エージェントがどれだけ書いたか、どのエージェントが書いたか、各コミットの主張がその差分によって裏付けられているかを確認できます。 自分のリポジトリを評価するには：dos commit-audit --sweep --workspace . BASE..HEAD。

この記録ひとつで全体像がわかります。エージェントは2つの機能を実装したと主張しますが、gitが裏付けるのは1つだけです。 dos verifyはコミットに基づいて回答し、嘘の場合は終了コード1を返します。終了コードをゲートに使えば、虚偽の「完了」は拒否されます。すべての行は実際のCLIの出力そのままです。出力が変わるたびにscripts/build_caught_lie_cast.pyが再記録します。

1つのリポジトリでエージェント群を動かしましょう。左のループは進捗しているように感じるだけですが、右のループなら舵取りができます。 唯一の違いは、DOSが現実世界（ここではgit）から読み取る判定であり、エージェントの言葉ではないことです。

AI エージェントは、作業が完了したと言います。DOSはその言葉を鵜呑みにせず、現実世界を確認します。そして、現実世界の中で最も近くにあるものがgitの履歴です。 エージェントがログインエンドポイントを実装したと言ったとき、本当に実装したのでしょうか。コマンドを1つ実行するだけです。 dos verifyはエージェントが入力した内容ではなく、作業が残した成果物に基づいて回答します。コミットが主張を裏付けている場合はSHIPPED、終了コードは0。何も反映されていない場合はNOT_SHIPPED、終了コードは1です。エージェントの説明は判定に一切関係しません。（DOSが読み取る証拠は、まずはgitだけです。ファイルツリー、時計、CIのステータス、テスト環境自体の状態など、エージェントが作成していないものはほかにもあります。）

dos verify AUTH AUTH1   # → SHIPPED      AUTH AUTH1 e62f74d   (exit 0)
dos verify AUTH AUTH2   # → NOT_SHIPPED  AUTH AUTH2           (exit 1)

最小構成はこれです。さらに規模を拡大できます。CI やフリートで、同じリポジトリを対象に、同じファイル上で競合しながら動く多数のエージェントに指示すると、DOS は互いの作業を妨げているエージェント、堂々巡りしているエージェント、そして「完了」という申告のうちどれが本当かも教えてくれます。すべての答えはアーティファクト（git、ファイルツリー、時計）から導き出され、語られた内容には頼りません。設定なしの通常の git リポジトリで動作し、伝える情報が増えるほど賢くなります。インストールするのは小さな Python パッケージひとつだけです。

セットアップ — リポジトリで DOS を使う

DOS は、エージェントが作業している既存の git リポジトリにインストールする Python パッケージです。DOS 自体を開発する予定がなければ、DOS のソースをクローンしたりフォークしたりする必要はありません。

cd path/to/your-repo
pip install dos-kernel
dos init --hooks auto   # detects the agent runtime(s) already in this repo
dos doctor              # shows exactly what this workspace is using

これ以降、作業が実際に反映されていない限り、エージェントは**「完了」**と報告できません。エージェント同士が互いのファイルを気づかれないまま上書きすることもなく、処理が停滞した場合は、静かに堂々巡りを続けるのではなくフラグが立ちます。dos init は、書き込んだ設定とフックのエントリーを出力します。生成されたエントリーを削除すれば、セットアップを元に戻せます。ランタイムが検出されない場合はその旨を伝え、明示的な選択肢を一覧表示します。推測で決めることはありません。

_{v0.30.0 · 5,600 件以上のテスト · CI：Linux で Python 3.11～3.13、Windows 3.13 でスモークテストを実行 · ランタイム依存関係は PyYAML のみ · MIT。}

🧭 次に進む場所： 理由と根拠（平易な説明、20 行の Bash による答え、実証済みの内容）、スタックに組み込む（MCP · フック · インストール）、システムコールと CLI のリファレンス、またはAI エージェントとしてこれを読んでいますか？ AGENTS.md — ビルド／テスト／チェックを 3 行で実行できます。全体の案内はすぐ下のルーターをご覧ください。

🔤 このページの先で使う 5 つの言葉。 プランは名前付きの目標です （AUTH）。フェーズは、その目標を実現するための、リリース可能な 1 つのステップです（AUTH1）。レーンは、1 つのエージェントが変更できるファイルツリーの範囲です。オラクルは、証拠とルールを読み取る DOS の部分です。スタンプは、リリースされたフェーズがコミットメッセージの件名に残す印（AUTH1: …）で、オラクルが grep する対象です。 用語は以上です。

平易な言葉で

コーディングエージェントは作業を行い、その結果を報告します。たいてい報告は事実ですが、ときには何も成果を出していないワーカーが、意気揚々と 「すべての作業が完了しました！」 と言うこともあります。エージェントが 1 つなら、出力を読み直して自分で確かめられます。これは、すでに払っている本物のコストです。エージェントを 20 個同時に動かすと、そのコストは払えなくなります。すべてを読む人はいなくなり、各ワーカーが自分の宿題を自分で採点し、問題はチェックされないまま静かに積み重なります。やがてコードベースは なんとか 動くものの、安全に変更できる人はいません。DOS は報告を読まない審判役です。実際に起きたこと（コミット、ファイル、時計）を読み取り、どんな報告にも左右されない判定を下します。導入にかかるのは午後ほどで、ランタイム依存関係は 1 つだけです。また、役割の範囲を守ります。伝えるのは 何が起きたか だけで、コードが 良いかどうか は判断しません。品質の判断はテストとレビューに委ねられます。（平易な言葉による詳しい説明。）

主張ではなく、測定された結果

ここに示すすべての数値は、エージェントが偽装できない事実（テスト環境の DB 状態、git の履歴）に基づいて評価されています。DOS ゲートは、2 つのモデルを使った 258 件のタスクで、誤検知ゼロのまま「実装しました」という虚偽を 15 件 検出しました。同じ判定役は、共有レコード 1 件で発生した衝突のうち、気付かれないままの 8 件中 6 件 を阻止しました。適切なタイミングで失敗が決まった実行を終了すると、1,634 件の成功を誤って終了することなく、フリートの計算リソースを約 11％節約 できました。また、報酬セットへの採用ラベルにより、自己採点する収集器が残し続ける有害データを取り除き、採用精度が 60％から100％ に向上しました。手法、金銭に関わる重要な 2 つの数値、そして予測と賭けの正直さの勾配については、何が証明され、何がまだ賭けなのか をご覧ください。

ドキュメントのほかの内容

このページでは、導入、デモ、そしてこの仕組みが解決する問題を紹介します。詳しい内容はテーマごとのページにあります。知りたいことを見つけて、該当ページへ進んでください。

オプションのデモ — 60 秒でお試しください

ターミナルをお使いですか？使い捨てのリポジトリで全体を実行できます。1 つのコマンドでひな形を作成し、実際のコミットを作成して検証し、終了後にクリーンアップします。

pip install dos-kernel      # PyYAML is the only runtime dep
dos quickstart              # → SHIPPED AUTH AUTH1 … then NOT_SHIPPED AUTH AUTH2

SHIPPED が 1 つ、NOT_SHIPPED が 1 つあります。前者は git が裏付けられる主張、後者は何も反映されなかった主張です。この対比こそが、この製品です。デモの最後には、すでにエージェントを実行している場所につなぐルーターが表示されます。Claude Code / Cursor のタブ（dos init --hooks）、MCP ホスト、CI ステップ、フリートのいずれでも、次にすることはドキュメントを探し回ることではなく、1 行のコマンドです。（リポジトリを残して試すには --keep ./demo を追加してください。インストールもしたくない場合は、uvx --from dos-kernel dos quickstart で同じデモを一時的に実行できます。何も残りません。）手動で同じことを 5 行で行う方法は、docs/QUICKSTART.md をご覧ください。

_{自信度が同じ 2 つの主張に、それぞれ 1 つの判定 — git が裏付けられるものには SHIPPED、何も反映されなかったものには NOT_SHIPPED。すべての文字列は examples/demo/verify_demo.sh の出力をそのまま掲載しています。クリックして進めるバージョンは、ローカルで順を追って確認してください（HTML ファイルです。リポジトリをクローンしてブラウザーで開いてください。GitHub では実行中のページではなく、ソースが表示されます）。}

最小限の実用的な改善は、CI ステップやディスパッチループで、エージェントの「完了」を信頼する行を dos verify PLAN PHASE に置き換え、その終了コード（0 は出荷済み／1 は未出荷）に応じて分岐することです。解析も、計画も、設定も必要ありません。CI 統合の手引きで、最初から最後まで説明しています。ご自身のリポジトリに合わせて実行するには、10 分でリポジトリをオンボードから始めてください。

コミットが誰かの確認より速く積み上がる場合は、同じ証拠確認の仕組みをレビューキューに向けてください。残余レビューは、commit-audit のコミットごとの判定を 3 つの区分にまとめます。CLEARED（差分が主張を裏付けているため、「主張どおりに実行したか」を再確認する手間をほぼ 0 にできます）、RESIDUAL（git で裏付けられなかった主張 — 100% 人間による確認が必要）、そして主張のない残りです。このリポジトリの直近 200 件のコミットでは、確認可能な主張 171 件のうち 170 件をクリアしました。これは、モデルの信頼度スコアではなく git によって証明された、再レビューを省ける件数です。（CLEARED が示すのは変更の形が主張と一致したということだけであり、コードが正しいという意味ではありません。正しさのレビューは、すべてのコミットに引き続き必要です。この区分が求める確認は、目を増やすことだけで、減らすことはありません。）

次の段階 — 判定を独自のスタックに組み込みましょう：組み込み方。

フリートで起こる問題

誰も監督せずに大量のエージェントを同時に動かすと、こうなります。 各作業者は自分の成功を報告し、ほかに頼れるものもないので、その報告を信じます。確認されない問題は静かに積み重なります。あちこちで嘘がつかれ、二つのエージェントが同じファイルを上書きし、少しずつスコープが広がり、作業者の一人が堂々巡りを続けます。やがてコードベースは「なんとなく」動くようになり、誰も安全に変更できなくなります。

問題は、エージェントを起動したあと、自分たちの宿題を自分たちで採点させたことです。DOS は不足していたシグナル、つまり実際の事実に基づく判定を提供するため、ループが閉じます。同じフリートを、二つの体制で動かした場合を見てみましょう。

flowchart LR
  subgraph OPEN["NO REFEREE — you believe the narration"]
    direction TB
    A1["agent: 'done!'"] --> B1[["believed"]]
    A2["agent: 'done!'"] --> B1
    A3["agent: 'done!'"] --> B1
    B1 --> C1["silent corruption piles up<br/>(lies · collisions · spin)"]
    C1 --> D1["'sorta works' — can't be changed"]
  end
  subgraph CLOSED["DOS ADJUDICATES — you steer on a verdict"]
    direction TB
    A4["agent: 'done!'"] --> V{{"dos verify<br/>reads git"}}
    V -->|in git ancestry| S["SHIPPED (exit 0)"]
    V -->|found nowhere| N["NOT_SHIPPED (exit 1)"]
    S --> L["land it"]
    N --> R["re-dispatch / flag — caught"]
    R -.verdict steers the loop.-> A4
  end

フリートで実際に起こる失敗を、それぞれ作業者の説明とひそかに食い違う事実、そして DOS が下す判定と並べて示します。

最初の行が最もよくあるケースです。典型的な兆候は、ほとんど何もしていない作業者からの「作業がすべて完了しました！」という朗らかな一言です。DOS はその一言を読みません。実際の事実を読むため、主張を裏付ける成果物がなければ、その瞬間に主張は崩れます（詳しくはdocs/108をご覧ください）。これが導入を容易にする理由でもあります。verify には計画もレジストリも設定も不要で、終了コードそのものが判定です。どんなシェルや CI のステップでも、言葉を解析せずに終了コードに基づいて分岐できます。

_{動くところを見てみませんか？ 二つのループは、1 フレームずつ進められる自己完結型のアニメーションでもあります。リポジトリをクローンし、docs/assets/loop_visual.html をブラウザーで開いてください。（HTML ファイルなので、GitHub では実行されずソースが表示されます。ローカルで開いてください。）}

リースのスコープ — 現在は単一のファイルシステムが対象です。 検証側（verify、commit-audit、liveness）は Git の履歴を読み取るため、マシン間を自由に移動できます。受付側（arbitrate、レーンリース）はローカルファイルシステムのみが対象です。WAL は 1 台のディスク上にあり、別々のマシンで動く作業者はシリアライズの基準点を共有しません。すべての作業者を 1 台のマシンまたは共有ファイルシステム上で動かすフリートは完全にカバーされます。複数のホストにまたがるフリートでは、リモートリースドライバーが提供されるまでは、dos arbitrate を強制力のあるミューテックスではなく、参考情報として扱ってください。設計についてはdocs/366をご覧ください。

どこまで活用できるか

設定なしで通常の git init から使え、情報を伝えるほど賢くなります。フレームワークを導入して段階を選ぶ必要はありません。浅いところから始めて、深く掘り下げるほど効果が得られます。どの段階でも同じカーネルを使います。

• 設定不要。 通常の git リポジトリに dos verify PLAN PHASE を指定するだけです。プランもレジストリも dos.toml も必要ありません。コミット履歴だけをもとに回答します（via grep-subject ／ via none）。これが QUICKSTART の全内容であり、上記の初日から CI で得られる効果でもあります。
• 構成を伝える。 dos init で dos.toml（レーン、パス、データとしての ship 文法）を作成できます。プラン文書を追加すると、dos plan が各フェーズの 主張 をオラクルの判定と並べて表示します。プランファイルの正確な形式（コピーして使え、組み込みのリーダーで往復変換できます）と、実際に動作する 4 つのワークスペース例を参照してください。
• 独自の型を教える。 独自のブロック理由、ゲート判定、出力レンダラー、受付述語、モデルを利用した判定器、カスタムのプラン方言、あるいはホストドライバー全体を、フォークせずにワークスペースポリシーとして宣言できます。全体像は docs/HACKING.md（7 つの拡張軸）と、コピーして使える examples/dos_ext/ にあります。

接続方法

この段階は、設定をどこまで深めるかを示しています。もう一つの軸は、判定役をどのように呼び出すかです。スタックを再構成するのではなく、普段の作業方法に合ったインターフェースを通じて導入できます。ここに挙げるすべての方法から、同じカーネルの判定にアクセスできます。手軽なものから順に並んでいます。

これらのインターフェースは、価値の流れの上流、つまり誰が審判を呼び出すかを担います。同じ判定は下流にも流れ、判定に基づいて動作するシステムへ届きます。すべての判定は判定ジャーナルに記録され、dos export で Datadog／Honeycomb／Grafana などのオブザーバビリティスタックに出力できます（docs/266）。dos notify は人による対応が必要な項目を Slack に送信し、dos reward はファインチューニングで学習できる対象を制限し、dos attest はループにアクセスできない懐疑的な人でも確認できる署名付きレシートを発行します（docs/246）。エージェントのツール呼び出しからダッシュボードまで、カーネルも判定の語彙も 1 つです。

次のレベルへ — 毎日運用する：フリートの運用。

同じチームのプロジェクト

DOS は、実際に信頼できる AI エージェントを運用するために Anthony Chaudhary が開発した 3 つのオープンソースツールの 1 つです。それぞれ異なるタイミングで機能します。

• fak — エージェントカーネル — DOS は、エージェントがすでに実行したことを（事後に、git や改ざんできないその他の証拠から）読み取ります。fak は、エージェントが実行中に許可される操作を管理します。トークンエンジンの前段に配置され、境界であらゆるツール呼び出しを判定する、単一の静的な Go バイナリです。機能ゲート、ツール結果の隔離、監査証跡を備え、DOS のループ外審判に対するインラインゲートとして機能します。go install github.com/anthony-chaudhary/fak/cmd/fak@latest · ドキュメント。
• Diffgram — 人が AI のデータを監督するための AI データストアです（ラベリング、ワークフロー、カタログ）。DOS と fak がエージェントを監督するのに対し、Diffgram はエージェントが学習に使うデータや生成するデータを監督します。

引用

ここで紹介するアイデアは、エージェントフリートのループ外審判について論じた論文 「検証に必要なのはすべて――ただし、あなたが考えている場所ではない」 にまとめられています。ビルド済み PDF は paper/releases/ にあります。arXiv のプレプリントは準備中です。arXiv ID が付与されるまでは、リポジトリを引用してください。

@misc{dos_kernel,
  title        = {Verification Is All You Need --- But Not Where You Think},
  author       = {Chaudhary, Anthony},
  howpublished = {\url{https://github.com/anthony-chaudhary/dos-kernel}},
  note         = {DOS --- the Dispatch Operating System; arXiv preprint in preparation},
  year         = {2026}
}

ライセンス

MIT — LICENSE を参照してください。