その日は、issue トラッカーが固まるところから始まりました。bd list を叩いても返ってこない。エージェントが 2 本、同じ瞬間にトラッカーへ書き込みにいって、データベースが動かなくなっていました。手で初期化し直して復旧はしましたが、そこで手を止めました。これを「ツールのバグを踏んだ」で片付けてよいのか。似た故障は少し前にも一度ありました。二度起きたなら、それは事故ではなく構成の問題です。
そこでその日は、機能の実装をやめて、フリートに自分自身の開発プロセスを監査させました。8 レーンの読み取り専用の監査を並列に走らせ、僕は所見の裏取りと裁定だけをやる。夕方には 23 の所見が 20 本の作業チケットになり、僕の判断を要する 4 つの論点はその場で決着して、決定文がチケットの本文に焼き込まれていました。今日はその一日の工程を、誤報の棄却も含めて書きます。ちなみに、修理そのものはまだ 1 行も終わっていません。
監査される側の体制
前提を先に置きます。監査の対象は、自社の旗艦プロダクト（FXトレーダーα）の開発リポジトリです。作業は beads という tracker のキューに載っていて、bd ready が「いま着手できる」チケット（bead と呼びます）を返します。dispatch が bead を 1 本取り、専用の git worktree を切り、実装は codex に委譲され、上位のモデルが監督する。出てきた PR は 3 層の自動レビュー（CI・静的スキャン・エージェントによるレビュー）を通り、マージ用のスクリプトがマージと同時に bead を閉じる。人間のレビューは通常の経路には入っていません。
- 01bd ready依存グラフ
- 02worktree隔離
- 03codex 実装委譲
- 043 層レビュー自動
- 05マージ＝closetracker 連動
この循環は、実際に回っています。監査もそこは否定しませんでした。壊れていたのは、循環そのものではなく、循環を支えるはずの周辺— データの退避、計器、規約 — のほうです。
8 レーンで読ませ、ひとりで裏を取る
監査は 8 つのレーンに分けて並列に走らせました。パイプライン、CI とゲート、tracker とそのデータベース、モデル委譲と支出、全セッションに注入される規約、運用の周期、hooks、そして方向性。各レーンは所見を最大 10 件まで、必ず証拠（ファイルと行）を添えて返す。書き込み権限は与えません。読めるのはリポジトリ、書けるのは報告書だけ、という分離です。
そのあと、僕と最上位モデルで、見出しに立つ所見を全件、引用箇所を自分で開いて再検証しました。ここで 3 件が落ちました。「フリート制御の直近 5 回の実行が失敗している」→ 実際は全部成功していた。「所見が 9 件トリアージ済みで残っている」→ そのファイルは存在せず、出力は 0 バイトだった。「dispatch のスクリプトに除外条件が無い」→ 前日に上流で修理済みで、僕の手元が 18 コミット古かったせいで見えていなかった。
ここが、この一日でいちばん持ち帰る価値のあった部分です。監査でサブエージェントを増やすと、所見の数は増えます。増えないのは精度のほうです。並列に読ませることの値打ちは網羅性であって、正しさは別のレイヤーで作るしかない。しかも 3 件目の誤報は、監査対象そのもの（作業ツリーの同期を怠っていたこと）が監査自身を汚染した例でした。古い canon を読んだエージェントは、既に直された問題を、自信を持って再提案してきます。
そして 1 件目の誤報は、より悪い所見への入口でした。フリート制御は失敗していない。成功していた。ただし中身は、何もせずに成功していたのです。
病名をつける
個別のバグを 23 個並べても、直す順番は決まりません。所見を眺めて、4 つの病型に畳みました。
| 病型 | 何が起きているか | 外から見える姿 | 処方 |
|---|---|---|---|
| データ層の耐久性欠損 | 書き出し・同期・退避の復旧経路が全部止まっている | 何も見えない（壊れるまで） | 自動化し、鮮度そのものを検査に入れる |
| green-but-dead | 前提を欠いた処理が skip され、成功として報告される | 緑のダッシュボード | skip の連続それ自体を警報にする |
| built-but-dark | 実装もテストも済んだ機構が、最後の 1 配線を欠いて眠る | 何も見えない | 配線されていることを回帰テストで固定する |
| canon rot | 常時ロードの規約に、廃止された決定が残る | 正しい実装が却下される | 正準を 1 面に絞り、他は指し示すだけにする |
データ層の耐久性欠損。 tracker のデータベースから git へ書き出される JSONL が、1 週間前で凍結していました。データベースの実体には 767 件の issue があり、書き出されたファイルには 735 件。差の 32 件は、その週にやった作業が、git のどこにも記録されていなかったという意味です。定期バックアップは無く、退避先として設定されていたのは同じディスクの中でした。復旧経路が全部死んでいる状態で、その朝、データベースが壊れたわけです。
green-but-dead。 週次ダイジェスト、品質の番人、指標の警報。どれも定期実行が「成功」を報告し続けていました。実際には認証情報が投入されていないので、処理を穏当に skip して数秒で緑になる。緑は「やった」ではなく「やらなかった」を意味していました。ダイジェストの最終出力は 2 週間半ほど前で止まっています。ここで効くのは個々の点灯ではなく、「skip し続ける緑を、それ自体エラーにする」一段上の監視のほうです。
built-but-dark。 マージ経路を強制するゲートのスクリプトは、書かれていて、テストも通り、リポジトリのどこからも参照されずに眠っていました。設定ファイルへの登録という、最後の 1 行が無い。記憶を統合する仕組みは 109 セッション分の未消化を抱えたまま、設定ファイルの効かないキー 1 つで 3 回連続して失敗していました。設計 → 実装 → 配線。この最後の一段だけが、いつも人間の手作業として残り、そのまま静かに眠ります。
canon rot。 全セッションに注入される規約に、既に廃止された決定が 5 箇所以上残っていました。いちばん危ないのは PR レビューの基準です。ある機能の提供形態について正式な決定が更新されたあとも、レビュー基準は旧決定のまま「その形態の導入は却下」と書かれていた。レビューを担当するエージェントは、その基準に忠実に従うほど、新方針どおりの正しい実装を止めます。人間なら「これは古い規約だな」と読み替える場面で、エージェントは読み替えません。憲法が腐ると、エージェントは正しく従うほど間違える。ここは、僕がこの一日で最も背筋が寒くなった所見でした。
4 つを並べると、処方箋の形が見えてきます。足りないのは機構ではありません。作った機構が点いていない。だから「新しく作る」のではなく、「配線する・点灯する・単一ソース化する」。
レポートを、実行できる形に変える
ここまでで、よくできた監査レポートが 1 枚あります。そして、よくできた監査レポートは読まれずに死にます。所見は散文で、優先順位は本文に埋まっていて、着手できるかどうかは誰にも問い合わせられない。前にこの tracker について書いた記事で、散文の計画書はエージェントにとって「書き込み専用の記憶」になると書きました。監査レポートも同じです。
そこで 23 の所見を 20 本の bead に変換しました。1 対 1 ではありません。同じ根を持つものは束ね、フェーズが違うものは割った。変換のときに置いた規律は 3 つです。
ひとつ、同じファイルを触る修理は、依存で直列化する。並列フリートは、同じファイルを同時に開いた瞬間に衝突します。委譲ルールを書いた 1 枚のファイルには 3 本の bead が手を入れる予定だったので、依存を張って順番を固定しました。ふたつ、危険な順序は、依存で強制する。データベースの移行 bead は、バックアップ整備の bead が閉じるまで bd ready に出てきません。「退避してから移行する」を、人間の記憶ではなくキューの構造に置く。みっつ、未決の論点は bead にしない。決まっていないことを作業として起票すると、エージェントが善意で決めてしまいます。
| 依存 | なぜ張ったか |
|---|---|
| バックアップの整備 → tracker のサーバーモード移行 | 移行の前に復旧経路を確保する（順序の強制） |
| 支出台帳の一本化 → モデルポリシーの更新 → 常時ロード規約の減量 | 3 本とも同じ規約ファイルを書き換える（直列化） |
| ID 抽出の堅牢化 → マージ経路の機械強制 | 2 本とも同じマージスクリプトを書き換える（直列化） |
依存グラフは、ここでは順序の記録装置として働いています。半年後の僕は「なぜバックアップが先だったのか」を覚えていないでしょうが、キューは覚えています。
裁定を、bead の本文に焼き込む
20 本のうち、機械に決めさせてはいけない論点が 4 つ残りました。お金が動く、正準が割れている、戻しにくい。この 3 つのどれかに触れるものは、僕のところへ上げる規則にしてあります。上げ方も決まっていて、選択肢とトレードオフと既定案を添えた構造化された質問にする。4 問まとめて出して、その日のうちに 4 つとも決着しました。
大事なのはそのあとです。裁定文は、それを実行する bead の説明文の冒頭に置きました。「founder 裁定（2026-07-10・確定）」で始まる段落があり、何を選び、何を選ばなかったかが書いてある。実装するエージェントは bd show を叩くだけで裁定の全文を読みます。ADR に格上げするほどではないが忘れると困る決定は、それを実行する作業そのものに書きつける。エージェント運用で本当に高くつくのは、決定を下すコストではなく、下した決定が 2 週間後に見つからないコストのほうです。
たとえばこの日の裁定のひとつは、データベースの並行破損に対して当座しのぎ（呼び出しの直列化）を飛ばし、本修理へ直行する、というものでした。当座しのぎは網羅が原理的に不完全で — 対話セッションや hook から飛ぶ呼び出しまでは包めない — 一段目に払う時間が二段目を遅らせるだけだと判断しました。この判断が正しいかどうかは、まだ分かりません。ただ、判断した理由は bead の中にあり、間違っていたときに読み返せる場所にあります。
「バグを踏んだ」のではなかった
その朝のデータベース破損に戻ります。原因を調べる前に、公式のドキュメントを読み直しました。答えは 1 行で書いてありました。beads の Dolt Backend for Beads にはこうあります。
Embedded mode is single-writer (enforced via file lock). If you need concurrent access, switch to server mode.
埋め込みモードは単一書き込みです（ファイルロックで強制されます）。同時アクセスが必要なら、サーバーモードに切り替えてください——訳は僕によるものです。
つまり僕は、バグを踏んだのではありませんでした。非推奨の構成で並列フリートを回していた。この tracker について前に書いた記事の終わりに、僕はこう書いています。「hash ID が採番の衝突を避けてくれても、共有された DB という制約は残ります」。制約を認識して、書き残して、公開までしておきながら、並列度を上げるときにその行を読み返していない。エージェントの記憶喪失を仕組みで補う話を書いた人間が、自分の記憶で失敗しているわけです。
事故が起きると、道具のほうを疑いたくなります。Markdown ベースの軽い tracker に移れば、データベースが壊れる故障は構造的に消えます。なので、それで失うものを数えました。依存グラフと、アトミックな claim（「この bead は私が取った」を競合なしに宣言する操作）。dispatch もマージも、この 2 つの上に建っています。壊れる部品を取り除くために、建物のほうを壊すことになる。だから残留を選び、常駐サーバーへの移行を本修理に据えました。そのうえで、いつ再評価するかを先に決めています。サーバーモードに移してもなお同種の事故が再発したら、そのときは簡素な tracker への降格を検討する。撤退線を先に引いておくと、道具への愛着が判断を汚しません。
最上位モデルの時間を、どこに置くか
この一日で、最上位のモデルが実際にやったことを数えると、8 レーンの所見の裏取り、4 つの病型への抽象化、裁定のための質問づくり、そして依存グラフの設計でした。コードは 1 行も書いていません。実装は codex に、最新情報のリサーチは grok に、長い文脈の要約は gemini に振ってあります。以前この振り分けについて書いたときの構造は、そのまま生きています。
生きてはいますが、駒は入れ替わりました。この日はちょうど CLI の更新日で、実装側の既定モデルが新しい世代（GPT-5.6 系の sol / terra / luna）に、リサーチ側が grok-4.5 に切り替わっています。監督と裁定は Claude の系列で、仕事の重さに応じて Opus・Sonnet・Haiku を降りたり上ったりする。ベンチマークの数値はどれも各社が自社の発表として出すもので、研究所をまたいだ直接比較には限界があります。だから僕が更新したのはモデル名だけで、役割の区画は動かしませんでした。「実装 / リサーチ / 監督 / 機械的な仕事」という 4 区画は、モデルが 2 世代進んでも生き延びています。
正直に書くと、推論の強度をタスクの重さから自動で決める仕組みは、まだ入っていません。今日の監査で「いつの間にか設定が一段下がっていた」ことに気づいたので、既定値の追認と、失敗したときだけ一段上げる規則を bead にしました。まだ open です。
一日で終わったのは、診断です
その日のうちに手当てできたのは、止血の一部だけでした。作業ツリーを同期し、凍結していた書き出しを解凍する（735 件 → 789 件。増えた 54 件のうち 20 件は、この日に起票した修理そのものです）。残りは全部 open のまま、依存グラフの上に並んでいます。「一日で監査から再設計まで」と書き出しておいてなんですが、一日で終わったのは診断で、治療はこれからです。
この種の棚卸しは、専任のプラットフォームチームがいる会社なら、四半期に一度の定例として回るものだと思います。ジャムチにはそのチームがいません。かわりに、監査そのものをエージェントの並列に投げて、人間は裏取りと病名づけと裁定に降りる。所見を散文で残さず、依存つきのキューに変換して、決定を実行の本文に焼き込む。ここまでやって、はじめて監査は「読まれずに死ぬレポート」から「勝手に片付いていく作業」に変わります。では、専任の基盤チームを置けない規模の会社は、自分たちのエージェント運用をどこで点検するのか。
この一日の手順そのもの（並列で読ませる → ひとりで裏を取る → 病名をつける → キューに変える → 裁定を焼き込む）を、いま導入支援の型として外に出す準備をしています。自社のエージェント運用に、そろそろ棚卸しが要ると感じていたら、まず話を聞かせてください。
参考: Dolt Backend for Beads（beads 公式ドキュメント・埋め込みモードの単一書き込み制約）、Beads - A memory upgrade for your coding agent。関連する自社の記録としてエージェントに記憶を渡す、無人運転の AI エージェントは、地味なところから壊れる、得意で振り分ける。監査レポートの原本は内部運用の数値を含むため公開していません。
