TL;DR — 4/29 GitHub予告なし停止、理由も返信もなし。二週間で五層レジリエンス・アーキテクチャを再構築：ローカルファースト × 三点SSoT × CI迂回直接プッシュ × 契約テスト・カオスドリル × セッション横断AI協働。核心教訓：どのサービスも通過必須にしてはならない。この原則は内部システムだけでなく、依存する外部サービスにも適用される。
2026年4月29日、paulkuo.twのレポジトリにcommitをプッシュしようとしたところ、エラーメッセージが続出した。その後GitHubにアクセスしたところ、GitHubアカウントに全くアクセスできないことが判明した（図のとおり）。一時的なログイン不可で数時間後には復旧すると思っていたが、そうはならなかった（スクリーンショット参照）。
Access to your account has been suspended due to a violation of our Terms of Service. Please contact support for more information.
サポートに申立て書を送ったが、今日まで何の返信も受けていない。
その時初めて、コード管理・CI・デプロイ、さらに私のワークフローの核心すべてを一社に依存することのリスクを意識した。その会社が私を排除したのである。理由も示さずに。
なぜ一つのサービス停止が全ワークフロー停止と等しいのか？
あの日の作業チェーンを分解すると、五つのノードによる一本の線であることがわかる：
執筆 → GitHubメインレポジトリ → GitHub Actions（CI） → Cloudflare Pages（デプロイ） → paulkuo.twオンライン
中間の三つのノードすべてがGitHubに依存している。その中でGitHub ActionsはCloudflare Pagesの自動デプロイをトリガーする要である。つまり、paulkuo.twへの投稿すらできなくなったのである。デプロイ自体が自分のマシン上で動いていないからだ。
さらに悪いことに、このチェーンを分解することを以前は考えたことがなかった。それは「そのように動作する」ものであり、エンジニア界隈ではそのような設計がデフォルトだった。GitHubが生きている間は、全体が円滑に動いて単一点障害（single point of failure）の本質を忘れさせるほどだった。
4月29日まで、この本質が露呈することはなかった。
スリーマイル島事故から何を学ぶか？
1979年3月28日未明、米国ペンシルバニア州スリーマイル島原子力発電所で米国史上最悪の民間原子力事故が発生した。原因は二次系の主給水ポンプ停止で、一次系圧力が急上昇した。自動閉鎖すべき逃がし弁（PORV）が引っかかって閉まらず、冷却水が継続的に流出した。
しかし計器表示が制御室を誤導した：逃がし弁の指示灯は「指令送信済み」を示すのみで「弁閉鎖済み」を示さず、運転員は弁が閉まったと誤解した。加圧器水位上昇を見て冷却水過多と判断し、高圧注水系統を停止したのである。結果、冷却水は引っかかった弁から継続流出し、炉心が次第に過熱、部分溶融に至った。
事故は単一エラーによるものではなく、三つの小さな問題が同時に蓄積し、現場人員が一分未満で正確な対応を行うことは不可能だった。
この事件は後にCharles Perrowの「ノーマル・アクシデント」（Normal Accidents）理論の嚆矢となる事例となった。Perrow本人がTMI事故調査員の一人で、1984年出版の『Normal Accidents』前半は彼によるこの事故の段階的再構成である。Perrowは二つの核心概念を提出した：「密結合」（一つの環節の事故が次の環節に高速伝播する）と「複雑性相互作用」（異なるサブシステムが予想外の方式で相互影響する）。このようなシステムでは、小さなエラーが大災害へと急速に拡大される。これは失敗の有無の問題ではなく、「遅かれ早かれ失敗する」問題なのである。
真に検討されるべきは特定の運転員の失誤ではなく、システム全体の設計と管理方式である。
我々が必要とするのは安全意識ではなく、安全システムである。
システムを整備し、緩衝区域を設け、余裕を持たせ、安定したループを作る。そうして初めて有恃無恐となれるのである。
この道理は我々内部システムだけでなく、依存する外部システムにも適用される。 全作業生命線を一社のサプライヤーに託すとき、そのサプライヤー自体があなたのシステムの一部となる。その脆弱性が、あなたの脆弱性となるのである。
GitHubの停止は私にとって、私自身のスリーマイル島だった。
二週間再構築：paulkuo.twの五層レジリエンス・アーキテクチャ
4月29日から私はGitHubのみに依存することはできないと決意し、「AI実行工学」に必要なレジリエンス・システムを計画・構築し、継続的に進化させ、5月12日に投稿機能の検収・オンライン化に至った。アーキテクチャは五層に分かれ、各層は「どのサービスも通過必須にしてはならない」という原則に基づいてデカップリングを行った。
全体俯瞰は以下のとおり：
① 創作層（Authoring）
ローカルMacが真の原稿（source of truth）で、Notionは私がスマートフォン・iPad・マシン横断で管理ファイルを閲覧できる読み専用mirrorに過ぎず、双方向同期はしない。
このロジックが重要である：以前は「Notionはクラウドにあり、マシン横断同期、バージョン履歴があるので、自然とSoT」と考えていた。しかしこれはNotionが永続的に存続するという前提である。事件後、私は逆に考えた：真の原稿は私が完全にコントロールできる場所にあるべきで、それはローカルMacである。Notionは一歩退いて表示層となり、故障しても私を阻害しない。
② 保存層（Persistence）
三点SSoT + 一つのコールドバックアップ：
- Codeberg（欧州オープンソースGitホスト）
- GitLab（商用Gitホスト）
- ローカルMac（master copy）
- Cloudflare R2（オフラインコールドバックアップ、repoバンドルとメモリスナップショット保存）
git push-allエイリアスを設定し、一つのコマンドで三社に同時プッシュする。GitHub originはremoteリストに残しているが、プッシュの度にfailする。これを「事件起点の記念碑」として意図的に残し、このアーキテクチャの由来を自分に思い起こさせている。日後復旧した際も使用するつもりである。
R2はGitホスト以外の第四の保険である。三社のGitホストが同時に事故を起こした場合（極めて不可能だが理論上あり得る）でも、バンドルはCloudflareオブジェクトストレージに残る。
③ デプロイ層（Deployment）
wranglerでローカルからCloudflare Pagesに直接プッシュし、GitHub Actionsを迂回。デプロイパイプライン全体がGitHubの生存と完全に分離されている。
これは工学上最も見落とされがちな環節である。多くの人がGitバックアップを再構築する際、CIもGitHubであることを忘れる。デプロイパイプラインのデカップリングはGitミラーリングより重要である。なぜならGitはゆっくり補完できるが、デプロイが断たれると発行すらできないからである。
④ 監視層（Observability）
レジリエンスには定期検証が必要：
- 契約テスト152エンドポイント：毎日LaunchAgentが自動実行し、実際のAPI動作と仕様定義にドリフトがないか比較
- カオスドリル（chaos drill）：H1ドリルを週次実行、意図的に一つの重要ノードを破壊し、システムが自動復旧できるか確認
- ドリフトスキャン（drift scan）：エンドポイントが密かに追加・変更されたのに仕様に書かれていない事象を自動検出
- BetterStackアラート：契約テスト失敗をBetterStackにプッシュし、メールとSMSで通知
この層はこのシステムで最も軽視されやすい部分である。この層がなければ、前三層の「レジリエンス」は宣言に過ぎない；この層があれば、レジリエンスは毎日検証される。
⑤ 協働層（Coordination）
この層が処理するのはインフラではなく、人とAIの協働方式である。
私は三種のAIセッションで分業を構成している：
- Chat（思考）：問題分解・方向探し・アーキテクチャ議論
- Cowork（計画）：文書整理・タスク計画・作業指示書作成
- Code（実行）：計画をプログラムコードに変換・機能実装・テスト実行
三者間はRFCメカニズム + handoff文書 + 共有待機キュー（PENDING.md）で協働。私はsession-handoff skillをこの協働の規律として設計：各セッション終了時に必ずフォーマットに従ってhandoffを記述し、次回セッション開始時にhandoffを読んで引き継ぐ。
このレジリエンス・アーキテクチャはAIに指示して作らせたものではない。二週間をかけ、私の試行錯誤の痛みの上で、三種のセッションと反復的に調整し、再度試行錯誤し、プロセスを修正してゆっくりと定型化したもので、現在も修正中である。
なぜ「一週間でAI従業員システム構築」が私に適用できないのか？
二週間の再構築過程で、強い実感があった：
市場にある「一週間でAI従業員システム構築」コースや既成Skillsパッケージは、他人には有効かもしれないが、私には効かない。
比喩を使おう：各Skillはタンパク質のようなものである。タンパク質がどのような形状に折り畳まれ、どのような機能を発揮するかは、それが置かれる細胞環境・酸塩基度・他のタンパク質との相互作用に依存する。タンパク質は異なる形状に折り畳まれ、異なることを行う。
Skillsも同様である。同じ「執筆skill」「デプロイskill」「カスタマーサービスskill」を異なる企業・異なる個体に投入すると、全く異なる形状に折り畳まれる。タスク境界と企業ニーズには必ず相異があるからである。個人と企業の目標は類似するかもしれないが、ワークフローの隙間・データの文脈・意思決定の優先順序はすべて異なる。
したがってAI Agentシステム設計には、パイプラインと内部パラメータの最適化に大量の時間が必要となる。特定のframeworkを使えばよいのではなく、自分自身の作業シナリオで反復的にイテレーションする必要がある。
私は毎日修正して、二週間で完走した。私はソフトウェア開発経験があり、ソフトウェア工学チームの管理経験もあり、AI協働の経験も蓄積し始めている。こうした背景のない人は、永遠に行き詰まるかもしれない。もちろん、より速い可能性もある。しかしプロンプトを一つ与えて、すべてが自動完成ということはあり得ないだろう。
二週間再構築で学んだ五つのこと
一、レジリエンス・システムの設計とは、システムを故障しないほど強固にすることではなく、局所的故障を許容し、かつ補完できるようにすることである。
Nassim Talebは『反脆弱性』で三分法を提出した：脆弱（fragile、圧力を受けると故障）、強靱（robust、圧力を受けても故障しない）、反脆弱（antifragile、圧力を受けてかえって強くなる）。従来の工学は「強靱」を追求する、つまり故障しないほど強固にする。しかし複雑な世界では、「強靱」は幻想である。次の圧力がどこから来るかは決してわからないからである。真に追求すべきはレジリエンス：故障しても全体を引き摺り下ろさず、故障しても修復可能。
私のあの五ノードの一本線は「偽強靱」だった：それは順調に動作し、安定に見えたが、最初の衝撃までしか耐えられない。
二、Agentの能力は強力だが、「一言指示して、残りはAIに任せる」というシナリオは現在のところ存在しない。
二週間で私はAIと少なくとも数百ラウンド協働した。AIの実行力は人類を遥かに超えるが、収束能力（複数の分岐するAI提案を一つの実行可能決策に収束させる）は現在のところ断層がある。毎ラウンド人間が引き継いでこの作業を行う必要がある。
三、したがって個体によるAI従業員システム構築に、速成のファーストフードはない。
前項承け。Skillsはタンパク質のようで、折り畳み形状はあなたの細胞環境に依存する。他人の折り畳み方を取得しても必ずしも使用できるとは限らない。あなたのワークフロー・あなたの美意識・あなたの決策モードが、最終的にあなただけが使用できるシステムを形成する。これがこの記事のアーキテクチャを公開し参考にしてもらえるが、コピーしても必ずしも有効でない理由である。
四、レジリエンス・システムにはHuman in the Loopが必要：設計段階と実行段階いずれも欠かせない。
二つ目はAI現在の能力限界について述べた。これは設計選択について述べる：いつの日かAI能力が十分になったとしても、レジリエンス・システムの設計において、人類は依然として重要ノードを占めるべきである。
HITL（human in the loop）の役割は二段階に分かれる：
設計段階：アーキテクチャ決策・依存境界・降格戦略・何が故障可能で何が絶対に故障してはならないか、これらはすべて人類が決断すべき判断である。AIは選択肢を列挙し、trade-offを展開できるが、一つの決策に収束し、結果に責任を負うのは依然として人間である。
実行段階：契約テストの結果を「真実の問題」として扱うべきか、カオスドリルで暴露されたバグを即座に修正すべきか、ドリフトスキャンで検出されたエンドポイントが「合法進化」か「仕様漏洞」か、毎件に人間の介入判断が必要である。システムがどの程度まで復旧できるかは、最終的に人間が現場にいるかどうかにかかっている。
レジリエンス・システムは「全自動」システムではない。 それは設計段階で意識的に人間を重要ノードに配置し、実行段階で継続的に人間に監督されるシステムである。全体をAIに投げて自分が上線しないなら、レジリエンスはせいぜい宣言されるのみである。最初の事故まで、AIが5つの可能根因を提示するが決裁できるものがなく、その時初めて問題はAIが十分強くないことではなく、誰も現場にいないことだと気づくのである。
五、AIはソフトウェア工学の「体力労働」を加速したが、同時に別の需要を拡大した：人間の繊細な判断を要する「決策密度」である。
プログラム作成時間は短縮されたが、何を書くか・なぜそのように書くか・いつ書かないか・複数のAI提案を一つの方案に収束させる方法を決定する、これらの決策密度が高まった。一時間の作業に30の微決策が濃縮され、各々に判断力が必要かもしれない。
一時的に適当な名称が思い浮かばないので、とりあえず「判断力経済」と呼んでおこう。
判断力経済が台頭している
過去十年、市場が補填してきたのは「実行力」：プログラムを書ける・設計ができる・データを処理できる人の給与が水位上昇のように高騰した。
未来十年、市場が補填するのは「判断力」かもしれない。実行ということなら、AIが既にある水準まで手助けできるからである。
ある説を見たことがある：知識労働者の役割は「Maker（実行者）」から「Curator（キュレーター）」へ移行し、最終的に「Judge（裁判官）」に落ち着くという。三つの位置は三種の異なる稀少性に対応する。作れることは、ますます稀少でなくなる；的確に・品味よく作れることは、まだ稀少；やるべきかどうか判断し・いつ停止するか・結果に責任を負うことが、最も稀少である。
4月29日GitHubに切断され、私は特定のネット機能を失ったと思った。よく考えてみると、私はアーキテクチャ決策権を放棄していたのである：このシステムがどのような外観で・誰に依存し・誰に依存せず・どのように検証し・どのように修正するか、これらの決策は本来すべて私のものであるべきなのに、以前は黙認で外注していたのである。
二週間後の5月12日、記事のアップロードが再開できるようになっても、特に感動はなかった。むしろ一句思い浮かんだ：生命線を一社に託したり、特定システムに重圧をかけて、それでいて自分は自由だと主張すべきではない。
💬 コメント
読み込み中...