# 4/29 GitHubに切断された：二週間で再構築した五層レジリエンス・アーキテクチャの工程記録 > 2026年4月29日、GitHubアカウントが予告なしで停止された。理由も通知もなし。執筆・デプロイ・CIの生命線が一瞬で断たれた。本稿では二週間で再構築した五層レジリエンス・アーキテクチャを解剖する：ローカルファースト執筆、Codeberg + GitLab + Cloudflare R2の三点SSoT、GitHub Actionsを迂回したCloudflare Pagesへの直接プッシュ、契約テスト+カオスドリル、そしてChat/Cowork/Codeの三種AIセッション協働。同時に、なぜレジリエンス・システムにはHuman in the Loopが必須であり、なぜ「判断力経済」が台頭しているかを論証する。 - Author: Paul Kuo（郭曜郎） - Date: 2026-05-15 - Pillar: 創造と構築 / Creation & Enterprise - Tags: レジリエンスエンジニアリング, Human in the Loop, Multi-Remote Git, Cloudflare Pages, AI Agent, Normal Accidents, 判断力エコノミー - Canonical: https://paulkuo.tw/ja/articles/resilience-engineering-after-github-suspend/ - Language: Japanese (日本語) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/resilience-engineering-after-github-suspend.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：4/29 GitHub予告なし停止、理由も返信もなし。二週間で五層レジリエンス・アーキテクチャを再構築：ローカルファースト × 三点SSoT × CI迂回直接プッシュ × 契約テスト・カオスドリル × セッション横断AI協働。核心教訓：**どのサービスも通過必須にしてはならない**。この原則は内部システムだけでなく、依存する外部サービスにも適用される。
▶ 要約を聴く
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. ![GitHub予告なしアカウント停止メッセージ](/images/articles/resilience-engineering-after-github-suspend/github-suspended.jpg) サポートに申立て書を送ったが、**今日まで何の返信も受けていない**。 その時初めて、コード管理・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日未明、米国[ペンシルバニア州スリーマイル島原子力発電所](https://www.nrc.gov/reading-rm/doc-collections/fact-sheets/3mile-isle)で米国史上最悪の民間原子力事故が発生した。原因は二次系の主給水ポンプ停止で、一次系圧力が急上昇した。自動閉鎖すべき逃がし弁（PORV）が引っかかって閉まらず、冷却水が継続的に流出した。 しかし計器表示が制御室を誤導した：逃がし弁の指示灯は「指令送信済み」を示すのみで「弁閉鎖済み」を示さず、運転員は弁が閉まったと誤解した。加圧器水位上昇を見て冷却水過多と判断し、**高圧注水系統を停止した**のである。結果、冷却水は引っかかった弁から継続流出し、炉心が次第に過熱、部分溶融に至った。 事故は単一エラーによるものではなく、三つの小さな問題が同時に蓄積し、現場人員が一分未満で正確な対応を行うことは不可能だった。 この事件は後にCharles Perrowの[「ノーマル・アクシデント」（Normal Accidents）理論](https://en.wikipedia.org/wiki/Normal_Accidents)の嚆矢となる事例となった。Perrow本人がTMI事故調査員の一人で、1984年出版の『Normal Accidents』前半は彼によるこの事故の段階的再構成である。Perrowは二つの核心概念を提出した：「**密結合**」（一つの環節の事故が次の環節に高速伝播する）と「**複雑性相互作用**」（異なるサブシステムが予想外の方式で相互影響する）。このようなシステムでは、小さなエラーが大災害へと急速に拡大される。これは失敗の有無の問題ではなく、「**遅かれ早かれ失敗する**」問題なのである。 真に検討されるべきは特定の運転員の失誤ではなく、システム全体の設計と管理方式である。 **我々が必要とするのは安全意識ではなく、安全システムである。** システムを整備し、緩衝区域を設け、余裕を持たせ、安定したループを作る。そうして初めて[有恃無恐](https://www.google.com/search?q=有恃無恐)となれるのである。 **この道理は我々内部システムだけでなく、依存する外部システムにも適用される。** 全作業生命線を一社のサプライヤーに託すとき、そのサプライヤー自体があなたのシステムの一部となる。その脆弱性が、あなたの脆弱性となるのである。 GitHubの停止は私にとって、私自身のスリーマイル島だった。 ## 二週間再構築：paulkuo.twの五層レジリエンス・アーキテクチャ 4月29日から私はGitHubのみに依存することはできないと決意し、「**AI実行工学**」に必要なレジリエンス・システムを計画・構築し、継続的に進化させ、5月12日に投稿機能の検収・オンライン化に至った。アーキテクチャは五層に分かれ、各層は「どのサービスも通過必須にしてはならない」という原則に基づいてデカップリングを行った。 全体俯瞰は以下のとおり： ![paulkuo.tw 4/29後再構築の五層レジリエンス・アーキテクチャ](/images/articles/resilience-engineering-after-github-suspend/architecture.jpg) ### ① 創作層（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は[『反脆弱性』](https://www.books.com.tw/products/0010628905)で三分法を提出した：**脆弱**（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（裁判官）**」に落ち着くという。三つの位置は三種の異なる稀少性に対応する。作れることは、ますます稀少でなくなる；的確に・[センスよく](/ja/articles/post-code-era-taste/)作れることは、まだ稀少；やるべきかどうか判断し・いつ停止するか・結果に責任を負うことが、最も稀少である。 4月29日GitHubに切断され、私は特定のネット機能を失ったと思った。よく考えてみると、私はアーキテクチャ決策権を放棄していたのである：このシステムがどのような外観で・誰に依存し・誰に依存せず・どのように検証し・どのように修正するか、これらの決策は本来すべて私のものであるべきなのに、以前は黙認で外注していたのである。 二週間後の5月12日、記事のアップロードが再開できるようになっても、特に感動はなかった。むしろ一句思い浮かんだ：生命線を一社に託したり、特定システムに重圧をかけて、それでいて自分は自由だと主張すべきではない。