TL;DR — 2026/6/22、GitHubが二度目の無予告アカウント停止を実行した。しかし今回は4/29とまったく違った。サイトの更新機能は止まらず、準備中だったニュースレターサービスは予定通り公開され、デプロイフローも滞らなかった。paulkuo.twは何事もなかったかのように動き続けた。二ヶ月前の障害の後、私は二週間かけて疎結合アーキテクチャを再構築した。今回はその耐障害性システムの検証だった。テストは通過した。しかし新たな盲点も露わになった。

▶ 要約を聴く
AI合成音声・著者本人の声のクローン

6月22日の午後、私はpaulkuo.twのニュースレター購読機能の仕上げをしていた。バックエンドはすでにデプロイ済みで、エンドツーエンドのテストも全て通過していた。AIに進捗をプロジェクトダッシュボードへ同期させていたそのとき、会話ウィンドウに警告が現れた。目に刺さるほど見慣れた赤い文字がまた飛び出してきた：

Your account was suspended

GitHubにまた切断された。

二ヶ月前、同じこの文字が、私の開発と投稿を丸二週間不可能にした。あの日は4/29だった。スタートアップとスーパー個人カテゴリに完全なエンジニアリング記録を書いた。GitHubアカウントが無予告で停止され、明確な理由も事前通知もなかった。その瞬間、執筆、バージョン管理、CIからデプロイまで、命綱のほぼ全てが同時に断ち切られた。私は二週間かけて五層の耐障害性アーキテクチャを再構築し、サイトの正常運営を取り戻した。

今回も無予告の停止だった。しかし結果は違った。サイトの更新機能は止まらず、ニュースレター機能は予定通り公開され、デプロイフローも滞らなかった。paulkuo.tw全体が動き続け、何事もなかったかのようだった。

GitHubが今回優しくなったわけではない。同じように冷酷で、同じように突然で、同じように403で、同じように事前通知がなかった。違ったのは、その間に設計されたシステムだ。一度目の障害が起きたとき、そのアーキテクチャはまだ存在していなかった。二度目の障害が起きたとき、それはGitHub停止の衝撃を見事に受け止めた。

GitHubの二度目の停止で、何が止まり、何が止まらなかったのか？

停止後、システムのどの層が影響を受けたかを確認した。止まったのは主に「記録と同期」に関わる部分だった。「稼働と公開」を担うコアフローは止まらなかった。

6/22のGitHub停止後、paulkuo.twの各層の実際の状態：赤はGitHubアカウントの連動により中断したパス、緑はGitHubを迂回して正常に稼働したパス

実際にブロックされたのは三つの部分だった。GitHubのメインリポジトリへのgit pushが失敗し、GitHub上のプロジェクトダッシュボードへの同期が中断し、GitHubのアイデンティティに依存する全ての操作（コマンドラインツールとAPI）が403を返した。

しかし正常に動作し続けた部分はより多く、より重要だった。コードはCodebergとGitLabという二つの独立したgitホストへ引き続きプッシュされ、この部分は一切影響を受けなかった。作業履歴のコミットは三つのリモートすべてが受け取るはずだったが、GitHubがブロックされた状態でも、CodebergとGitLabは正常に受け取った。デプロイフローはwranglerを使ってCloudflareへ直接プッシュする方式で、CloudflareのAPIトークンを使用しており、GitHubアカウントとは一切関係がなかった。サイト、ニュースレター、APIはすべてCloudflare上で正常に稼働し続けた。プロジェクトダッシュボードのNotionミラーも無事だった。GitHub APIではなくリポジトリ内のファイルを読んでいるからだ。

現在のシステムアーキテクチャでは、GitHubのアイデンティティに縛り付けられた機能は当然ブロックされ、GitHubを経由しない部分は全て生き残った。これが4/29の後の二週間で、私が力を注いで再構築したものだ。

なぜ今回、デプロイが一切影響を受けなかったのか？

4/29の際に学んだ教訓がある。多くの人はコードをGitHubに置いているだけだと思っているが、実はデプロイの命綱まで一緒に渡してしまっている。

私が以前使っていたデプロイチェーンはこうだった。GitHubにプッシュすると、GitHub Actionsが起動し、Cloudflare Pagesが自動デプロイされる。便利に見えるし、標準的でもある。だが問題は、GitHub Actionsがこのチェーンの必須経路だったことだ。アカウントが一度停止されると、チェーンの途中で断ち切られる。コードは自分のマシン上にあるのに、「公開」はもう自分のコントロール外にあった。

前回停止されたとき、私はコンテンツも、ファイルも、サイトも持っていながら、公開できなかった。だから再構築の際にデプロイチェーンを切り離した。現在のフローは：ローカルでビルドし、wranglerを通じてCloudflare Pagesへ直接プッシュし、CloudflareのAPIトークンを使う。このチェーン上に、GitHubが生きていることを必要とする工程は一つもない。

だから6/22にGitHubアカウントが停止されても、ニュースレターのバックエンドとフロントエンドは予定通りデプロイされ、検証され、公開された。私はアカウントが停止された後になってからサイトの状態を確認したほどだ。購読ページは正常、フォームは使用可能、メール送信フローも完全に動作していた。そのとき初めて、これが本当の疎結合だと実感した。GitHubがオンラインかどうかが、もはや私のサイトの公開可否を左右しなくなっていた。

📊 二度の停止の比較

  • 4/29 一度目：命綱の全てが切断され、再構築に二週間を要し、ようやく投稿を再開できた。
  • 6/22 二度目：サイトのダウンタイムはゼロ、当日に新機能を予定通り公開した。
  • 二度の事象の間：あの五層疎結合アーキテクチャが、二度目の停止の際に私を守った。

しかし今回、私が見落としていた盲点も露わになった

話がここで終わるなら、「役に立つシステムを構築した」という事例に過ぎない。しかし現実の障害が照らし出すのは、自分がうまくやれた部分だけではなく、思いもよらなかった、あるいは見えていさえしなかった部分でもある。

今回掘り出されたのは、冗長化されていると思っていたが実はされていなかった箇所だった。

進捗を同期しようとしていたとき、手元には二つのAIが異なる方法でGitHubに接続しながら作業を手伝っていた。私はずっとそれを二つの独立したパスと見なしていた。一方がダメなら、もう一方がある、と。するとGitHubアカウントが停止された途端、両方が同時に落ちた。理由を言えば単純だ。二つのAIはアクセス方法こそ違っていたが、最終的にはどちらも「私のGitHubアカウント」というアイデンティティでドアを開ける必要があった。GitHubが停止したのはそのアカウントというアイデンティティ全体であり、それを使う全てのツールが自然に同時に無効化された。

身近な例えで言えばこうだ。キッチンに蛇口が一つ、浴室に蛇口が一つある。ある日キッチンの水が出なくなった。構わない、浴室で汲めばいいと思ったら、浴室も出ない。なぜなら、この二つの蛇口は壁の中で同一の幹管、同一の元栓につながっているからだ。普段は壁の中の配管は見えないから、ずっと別々の独立した水源だと思い込んでいた。私の二つの冗長パスは、まさにその二つの蛇口だった。

この状況を「同一障害源の単一障害点」と呼ぶ。これは偽の冗長性だ。全く冗長化されていないより危険なのは、誤った安心感を与えるからだ。冗長化がなければ、少なくとも無防備であることはわかる。偽の冗長性は鎧を着ていると思わせ、打ち抜かれた瞬間になって、それが厚紙だったと気づかせる。

この出来事は、より大きな問題を見せてくれた。システムが複雑になればなるほど、「幹管」は深く隠れ、見えなくなっていく。私たちが見えるのは二つの蛇口、二つのツール、互いに独立しているように見える二つの選択肢だ。しかしそれらは見えないところで同一の点につながっている。見えないことは存在しないことではなく、見えない依存関係はしばしば最も危険だ。それが一緒に壊れることすら気づかないからだ。

解決すべき問題が増えるほど、システムはより複雑な方向へ向かう。サービスを一つ追加し、ツールを一つ加えるたびに、背後の依存グラフに線が増え、そのグラフをもはや誰も完全に把握できなくなる。これは前の記事で触れた「正常事故」理論が語っていることだ。十分に複雑で、かつ互いに連動するシステムでは、事故はいつか必ず起きる。違いは時期だけだ。全ての連動を事前に見通せる人はいない。なぜなら連動そのものがシステムの進化とともに絶えず生まれ続けるからだ。

そして複雑性のリスクは往々にして、ノード間の見えない結合から生まれる。独立した冗長パスと思っていたものが、主経路と同一の障害源を共有しているかもしれない。リスクはツールの中に潜むのではなく、ツールとツールの関係の中に潜む。

複雑さそれ自体が、隠れたリスクなのだ。

これはスリーマイル島事故のある細部を思い起こさせる。オペレーターは「指令送信済み」のインジケーターランプを見つめ、バルブが閉まったと思っていた。実際にはバルブは開いたまま固着していた。あのランプが示していたのは「指令を送った」という事実であり、バルブの実際の状態は別の話だった。偽の冗長性も同じ錯覚だ。二つのパスがあるように見せながら、その二つの底には、同時に断ち切られる同一の根がある。

耐障害性に完成の日はない。あるのは現実による繰り返しの検証だけだ

4/29の障害は、耐障害性アーキテクチャの構築を教えてくれた。6/22の障害は、別のことを教えてくれた。アーキテクチャは図面を描いても、デプロイが完了しても完成ではない。現実によって検証されて初めて、どこが本当に機能していて、どこは機能していると思い込んでいるだけなのかがわかる。

これはスタートアップとスーパー個人というテーマで、私が繰り返し検証したいと思っている問題だ。カオスエンジニアリングは重要だが、演習は結局のところ自分で設定した負荷テストだ。どれだけリアルに見せても、「次に何が起きるか知っている」という底知れぬ余裕が残る。現実の障害は違う。6/22の停止は予告なく、私の演習シナリオには存在せず、私が用意したテストでもなかった。それはただ突然起き、私は手元のシステムで即座に対応しなければならなかった。

今回は無事に乗り越えた。サイト、デプロイ、ニュースレター、すべて生き残った。しかし同時に一つのリスクも掘り起こされた。二つのAIセッションが二つの冗長パスだと思っていたが、実は同一のアイデンティティ源を共有していた。これはアーキテクチャを判断する際の私の見落としを露わにした。ツール自体の問題ではなく。

だから、耐障害性アーキテクチャは現実世界によって検証されて初めて、その真の価値がわかる。さらに重要なのは、検証のたびに盲点リストを更新できることだ。一度目の障害の後、私のリストには「五層疎結合」と書いた。二度目の障害の後、もう一行追加した。「マルチパスの冗長化は、パスの数だけを見るのではなく、障害源が本当に独立しているかを確認しなければならない」と。将来きっと三度目、四度目が来て、システムは積み重なりながら進化し続けるだろう。

前の記事でこう書いた。自分の命綱を一社に預けながら、自分は自由だと主張すべきではない、と。

二ヶ月後の心得はこうだ。システムを構築しても自由とは限らない。本当にあなたを支えるのは、システムが現実のテストを受けたとき、問題を見て取り、構造を変えられ、主導権を自分の手に取り戻せることだ。

GitHubの三度目の停止が来るかどうか、私にはわからない。しかし今回わかったことがある。それが来るとき、私のシステムはすでにより耐えられるようになっている。

アラン・ワッツが言ったように：「変化の意味を理解する唯一の方法は、それに身を投じ、流れに乗り、共に踊ることだ。」

あの赤い文字がもう一度現れるかもしれない。しかし次に現れたとき、私のサイトはおそらく、何事もなかったかのように、動き続けているだろう。