TL;DR — 一人で四つの AI ウィンドウと同時に協働すると、自律は最初に commit を急いだ時点で失われた。本稿は、私がいかにして現実のインシデントから一つのガバナンスシステムを進化させたかの記録だ：憲法五条、governance-lint pre-commit hook、75 エンドポイントの契約テスト、12,946 ファイルの復元演習——制度の各層にはそれぞれ対応するインシデント番号がある。
2026 年 5 月 22 日、私の commit が止められた。
同僚に止められたのではない。チームに私以外の人間はいない。私を止めたのは 229 行の bash スクリプト——governance-lint.sh、git pre-commit hook に組み込まれている。それは冷たく Strict fails: 4 を吐き出した：二つの handoff 文書に status frontmatter フィールドが欠けており、## Consequences の章もなかったのだ。
面白いのは、このスクリプトは私自身が AI に書かせたものだということだ。ルールも私自身が定めた。だが 48 個のファイルを一度に commit しようと急いでいたとき、私自身は違反に気づかなかった。機械が私の代わりに記憶していたのだ。
これは大した技術的な物語ではない。フルタイムではないエンジニアが、四つの AI ウィンドウと協働する過程で、ひたすら踏み抜いては穴を埋め、最後に一つのガバナンスシステムを育てていった記録である。
同じ日に三つの穴が爆発、なぜ「もっと注意する」では足りないのか？
物語は 2026 年 4 月 19 日から始まる。その日、私は Chat、Cowork、Code の三つのウィンドウを同時に使って paulkuo.tw のプロジェクトを処理していた。午後になると、三つの問題がほぼ同時に浮上した。
第一に、session-handoff という skill が repo 層では v5.3 なのに、クラウド層では v4.13 のままだった。両者ともに自分が最新だと思い込んでおり、互いの分裂の存在を誰も知らなかった。
第二に、Cowork ウィンドウが「検証済み」とされる一連の事実を引用して判断を下したのだが、遡ってみると、それらの事実は誰一人として検証コマンドを走らせていなかった。推論の連鎖全体が空気の上に築かれていた——後にこれを「castle in the sky」と呼んだ。
第三に、同一の memory が CLAUDE.md と memory ファイルにそれぞれ一つずつ保存されており、内容が完全には一致していなかった。片方を変えても、もう片方は知らないままだ。
三つの問題の共通の根源は、誰かが手を抜いたことではなく、アーキテクチャ上「誰の言うことが正しいか」を保証する仕組みがなかったことだ。AI 対話ウィンドウが一つしかないなら、この種の問題は存在しない。だが、あなたのワークフローが Chat で計画、Cowork で偵察、Code で実装、Paul で決裁——四つの参加者がそれぞれ記憶を持ち、それぞれ結論を生み出す——となると、「事実の一貫性」はエンジニアリングされなければならない問題になる。
CLAUDE.md にルールを数行書き足してみた。効果はあったが、すぐに気づいた：注意力は commit を急ぐプレッシャーの下で失われる。受動的な文書は能動的な防衛線にはならないのだ。
そこで私たちは少々馬鹿げて聞こえることをした：憲法を書いたのである。
人機協働憲法の五条はいったい何を管理するのか？
「憲法」というのはレトリックではない。この文書の構造は実際に憲政設計のロジックを参照している：まず身分を定める（誰が参加者か）、次に権限を定める（誰が何をできるか）、最後に紛争解決の仕組みを定める（問題が起きたらどうするか）。
五条の設計は、その一つ一つが私たちの踏み抜いた穴に対応している。
第一条、SSoT 原則。 paulkuo.tw repo の git HEAD が、すべてのルール、skill、ガバナンス文書、memory、タスクキューの唯一の事実の源泉である。これは設計上の好みではなく、消去法の結果だ——私は Anthropic 公式ドキュメントを調査したが、そこには「Custom Skills do not sync across surfaces… You’ll need to manage and upload Skills separately for each surface」と明記されていた。業界の解決策も一様に git-first を指し示している。誰もが git を SSoT として使っているのは、他に選択肢がないからだ。
第二条、媒体の対等。 クラウド（Claude.ai）は永遠に下流の mirror であり、協働の主幹には入らない。この条は skill 分裂事件に対して立てられた。v5.3 と v4.13 の分裂は、まさにクラウド層が「もう一つの正本」と見なされたことが原因だった。
第三条、権限と責任の分担。 この条が最も精妙であり、最も誤解されやすい。それは権限をガチガチに固定するものではない——Chat は X しかできない、Code は Y しかできない、というものではない。それは「主責任は柔軟 + 照合は剛性」だ：誰が何を担当するかは調整できるが、相互検証の義務は剛性である。Code が書き終えたものは Cowork が必ず検証し、Cowork の偵察結論は Code が必ず再現できなければならない。これは三権分立の憲政設計のロジックと一致する——行政・立法・司法の間のチェックは選択的な礼儀ではなく、構造的な義務である。本稿は「知性と秩序」シリーズの一部であり、まさにこの種の秩序が人機協働の中でいかに再構築されるかを探求している。
第四条、記憶の階層。 一つの事実は一つの担当層にのみ保存し、層をまたいだ複製を禁じる。同一層内では、各 memory は原子化されなければならない——一つのファイルは一つの事柄を語る。この条は memory 重複事件に対して立てられ、後の memory システム全体の再構築の根拠ともなった。
第五条、記憶の拡張。 新しい記憶媒体（例えば Mem0、Letta、MCP memory server）を接続するには、正式な ADR（Architecture Decision Record）プロセスを経なければならない。ある日「このツールは便利だ」と思っただけで直接つなぐことはできない。
決裁したその日、私は Cowork ウィンドウと午後四時から五時まで議論し、v0.1 を書き終えるとすぐに不十分だと気づき、即座に v0.2 まで修正した。憲法全体が同じ日の危機の中で誕生したのだ。
文書から防衛線へ：governance-lint はいかにしてルールをコードに変えたか？
憲法を書き終えた後、六日間は平穏だった。そして 4 月 25 日、また踏み抜いた。
一群の handoff 文書の frontmatter フォーマットが統一されておらず、ある文書は status が欠け、ある文書は ## Consequences の章がなかった。これらは CLAUDE.md にも憲法にも規定されていたが、それでも漏れる。理由は単純だ：ルールは文書に書かれており、文書はあなたが git commit するときに飛び出して止めてはくれない。
これで私たちは一つのことをはっきり理解した：自律（autonomy）では足りない、他律（heteronomy）が必要だ。governance-lint はこの発想の産物である——bash 製の pre-commit hook、229 行、commit 段階で機械がチェックできるルールをチェックする役割を担う。
現在二つの硬性チェックを有効にしている。第一のチェックはすべての handoff 文書をスキャンし、frontmatter に status（Draft / Accepted / Superseded / Deprecated の四値のみ受け付ける）があり、本文に ## Consequences の章があることを確認する。第二のチェックは記事の pillar フィールドをスキャンし、その値が ai | circular | faith | startup | life の五つの正当な値の範囲内であることを確認する——以前ある記事が circular-economy と書き込み、build が一気に爆発したことがあった。
設計上、いくつかの意図的な決定がある。歴史的な文書には免除の仕組みがある——憲法以前の handoff は新ルールに縛られない、これは一度限りの赦免だ。だが新しい文書はコンプライアンスを守らねばならない。本当に回避する必要があれば --no-verify を使えるが、commit message に [skip-lint-recovery] を記し、理由を説明しなければならない。脱出口は存在するが、脱出の代償は記録を残すことだ。
5 月 22 日のあの阻止が、それが本番環境で本当に役立った初めての例だった。48 個のファイルの大量 commit で、人の目は四箇所の違反を見逃したが、機械は見逃さなかった。修正してから再 commit すると、13 個の commit すべてが governance-lint を通過した。
このシステムの進化の経路はきわめて典型的だ：CLAUDE.md の一行のルール → 三回以上違反される → pre-commit hook へとアップグレード。私たちはこの道を「インシデント駆動の制度進化」と呼んでいる——まず観察し、それから自動化する。最初から過度にエンジニアリングしないこと。
GitHub の切断：ガバナンスシステムのストレステスト
2026 年 4 月 29 日、私の GitHub アカウント zarqarwi が suspend された。予告もなく、説明もなかった。
repo は失われなかった——ローカル側は完全だった。だがワークフロー全体が瞬時に断たれた：Pages の自動デプロイは死に、Issues トラッカーは消え、GitHub Actions はすべて停止した。この事件の完全なエンジニアリング記録は別の記事にあるので、ここではガバナンスシステムに関わる部分だけを語る。
ストレステストは二つのことを露呈した。
第一に：ガバナンスシステムの SSoT 原則（第一条）が命を救った。すべてのルール、文書、memory がローカルの git の中にあったため、GitHub が切れても remote が一つ減っただけで、事実の源泉が減ったわけではなかった。私たちは 48 時間以内に Codeberg + GitLab の二重リモートへ切り替え、ワークフローはまったく劣化しなかった。もし SSoT が当時 GitHub Issues やその他のクラウドサービスに置かれていたら、この物語の結末はまったく違っていただろう。
第二に：危機が制度建設を加速した。アカウントが suspend されてから復旧するまでの間に、私たちは 12,946 ファイルの復元演習（暗号化バックアップからの解凍 + 検証）を行い、五層のレジリエンス・アーキテクチャを書き、75 エンドポイントの契約テスト設計を稼働させ、commit-msg hook のサブプロジェクト横断的な影響検出を強化した。時間があったからではなく、「GitHub すら切れるのなら、切れないものなど何があるのか」という問いが、各層の防衛線を徹底的に考え抜くことを迫ったからだ。
レジリエンス・アーキテクチャとガバナンスシステムの交点はここにある：レジリエンスが扱うのは「外部サービスが切れたらどうするか」であり、ガバナンスが扱うのは「内部協働が乱れたらどうするか」だ。両者の共通の信念は同じ一本である——いかなる単一ノードの失敗もシステム全体の停止を招いてはならない。五層レジリエンス・アーキテクチャの第一原則「No Single Point of Control」は、憲法第一条の SSoT 原則と、本質的には同じことの外部版と内部版なのだ。
インシデントから制度へ：各防衛線の出自
時間軸全体を振り返ると、明確なパターンがある：
2026 年 4 月 19 日、三つのガバナンス上の穴が同時に爆発 → その日のうちに憲法 v0.2 を書き上げた。 4 月 20 日、三つの AI ウィンドウに憲法試験を課す → Cowork が 70% しか取れず、Code が 97% を取ったことが判明。 4 月 25 日、handoff フォーマット違反が N≥3 に累積 → governance-lint pre-commit hook が稼働。 4 月 29 日、GitHub アカウントが suspend → レジリエンス・アーキテクチャ五層を全面的に構築。 5 月 10 日、Worker API セキュリティ監査で 75 のエンドポイントを発見 → 契約テスト三層アーキテクチャを設計。 5 月 12 日、自動最適化システムが七週間停止 → 正式に退役 + 分散型 autoresearch へのパラダイムシフト。
各層の制度の出生証明書には、それぞれ一つのインシデント番号が記されている。「あらかじめ設計され、使われるのを待っていた」層は一つもない。
これである命名を思いついた。私たちはこのものを Governance Harness と呼ぶ——governance cage（檻）ではなく、harness（安全ベルト）だ。安全ベルトの機能はあなたの行動を制限することではなく、より大胆に走れるようにすることだ。governance-lint が commit を止めるのは不注意を罰するためではなく、急いでいるときにルールを記憶することに気を散らさずに済むようにするためだ。契約テストが毎日自動で走るのは信頼していないからではなく、75 のエンドポイントのセキュリティ状態は人間の記憶で維持すべきではないからだ。
アップグレードの階段は固定されている：問題を観察する → まず文書に書き込んでソフトルールとする → 1〜2 週間観察する → 同種の問題が N≥3 回繰り返したら → 自動化へとアップグレードする。governance-lint が CLAUDE.md の一文から pre-commit hook へ至るまで、六日かかった。commit-msg hook のプロジェクト横断的な影響検出が、衝撃マップ文書から自動化へ至るまで、二週間かかった。速度が肝心なのではない、パターンが肝心なのだ：まず止血し、それから根治する。十分に観察してから自動化する。
試験が露呈した盲点
一つの物語で締めくくろう。
憲法を書き終えた翌日、私たちはおそらくあまり誰もやったことのないことをした：三つの AI ウィンドウに一つのガバナンス試験を課したのだ。15 問、事実問題、判断問題、状況問題の三つの層に分けて。
結果は Code 97 点、Chat 77 点、Cowork 70 点だった。
最低点は Cowork——そして Cowork は私たちのアーキテクチャの中で「司法」の役割を担い、検証と仲裁を司る存在だ。最もルールを理解すべき役割が、最も悪い点数を取った。
理由は具体的だ：Cowork のサンドボックス環境は物理的に一部のファイルのリアルタイムな状態を見ることができないため、正確な行数やバージョン番号に関わる事実問題では、記憶に頼って答えるしかない——そして記憶はドリフトする。Chat の問題はより根本的だ：そもそも Read 能力を持たず、すべての「正確な事実」は又聞きである。
この結果は直接二つの制度修正をもたらした：Chat が正確な事実照会に答える権限を制限すること、そして Cowork のワークフローに「サンドボックスのデータは Mac ローカルのデータと等しくない」という確認ステップを強制的に組み込むこと。
ガバナンスはルールを書き終えれば終わるものではない。それはあなたと協働する一日一日が、つねに試験なのだ。
よくある質問
Q: なぜ人機協働にガバナンスシステムが必要なのか？そのまま使えばいいのでは？
単一の AI 対話なら不要だ。だが、Chat で計画し、Cowork で偵察し、Code で実装し、Codex で監査するというように四つのウィンドウを同時に使うと、それぞれが記憶を持ち、それぞれが間違いを犯し、それぞれが他のウィンドウと矛盾する結論を生み出す。ガバナンスシステムがなければ、「前回どこまで進んだか」「この数字は本物か」「誰の言うことが正しいか」といった問題に大量の時間を費やすことになる。ガバナンスシステムは、繰り返しの照合ではなく、本当に重要な判断に注意を向けさせてくれる。
Q: governance-lint pre-commit hook は具体的に何をチェックするのか？
現在二つのチェックを有効にしている：第一に、handoff 文書の frontmatter には status フィールド（Draft/Accepted/Superseded/Deprecated の四値のみ受け付ける）が必須で、本文には Consequences の章が必須である。第二に、記事の pillar フィールドは五つの正当な値の範囲内でなければならない。違反すると commit が止められ、修正しなければ push できない。これは 229 行の bash スクリプトで、git pre-commit hook に組み込まれている。
Q: このガバナンスシステムはチーム向けか、それとも個人向けだけか？
現在は一人 + 複数の AI ウィンドウのために設計されている。だが、その根底にあるロジック——SSoT 原則、相互検証の義務、インシデント駆動の制度的アップグレード——は小規模チームの場面でも同様に成り立つ。違いは、チームでは人と人との間の権限と信頼の問題を扱う必要があるのに対し、このシステムが扱うのは人と AI との間の事実一貫性の問題である点だ。
Q: インシデント駆動の制度進化のアップグレード階段とは何か？
問題を観察する → まず文書に書き込んでソフトルールとする → 同種の問題が N≥3 回繰り返し発生したら → 自動化（hook、cron、スクリプト）へとアップグレードする。governance-lint はこうして CLAUDE.md の一行の文章から pre-commit hook へと変わったのだ。肝心なのは、最初から過度に自動化しないこと。まずパターンを観察してから決める。
💬 コメント
読み込み中...