# 私の自動化システムは全て正常に動作していた、そして一丸となって私に逆襲した > 記事を一つ投稿するのに、理論上は30分、実際は3時間かかった。その過程で六つのシステム問題が露呈：botのcommitで三つのミラーが永続的に不整合、自動翻訳が人工翻訳を上書き、記事が公開されたのにトップページが気づかない、各AI窓に渡される仕様がバラバラ。最も皮肉なのは、全てのコンポーネントが正しく動作していたことだ。これは一人企業のレジリエンス・エンジニアリングpostmortem：AIと自動化が要件・データ・画面・テストに介入し始めると、人が真に管理すべきは単一タスクではなく、新しい仕事秩序全体、そして自分がまだどれだけの判断権を握っているかである。 - Author: Paul Kuo（郭曜郎） - Date: 2026-06-04 - Pillar: 知性と秩序 / Intelligence & Order - Tags: レジリエンス・エンジニアリング, 自動化ガバナンス, マルチエージェント協調, 判断権, AI主体性, postmortem, 一人企業 - Canonical: https://paulkuo.tw/ja/articles/automation-bites-back/ - Language: Japanese (日本語) - Translation: AI-translated from the zh-Hant (Traditional Chinese) original - Original (zh-Hant): https://paulkuo.tw/articles/automation-bites-back.md - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：もともとは記事を一つ投稿するだけのはずが、3時間かかり、一連のシステム問題に遭遇した：botのcommitで三つのミラーが不整合・自動翻訳が人工翻訳を上書き・トップページのキャッシュが新記事をブロック・異なるAI窓の間で仕様ドリフト。最も皮肉なのは、全てのコンポーネントが「正しく」動作していたことだ。本当に修復すべきは自動化の解体ではなく、全ての参加者が読める契約を各自動化に提供すること：トリガー条件・副作用・opt-outマーク・検証エントリーの四項目が必須。そして契約の背後にはより根本的な問題がある：未来の仕事のリスクは自動化が壊れることではなく、自動化が全て正常に動作しているのに、それらが互いに何を影響し合っているかを誰も知らないことだ。
▶ 要約を聴く
AI合成音声・著者本人の声のクローン
昨日の深夜、私は記事を投稿した。 四言語版のファイルは10分で配置完了。カバー画像の生成・確認・決定も順調。そしてpushボタンを押した。その後の3時間、私は自分のシステムと格闘していた。 バグと格闘していたのではない。3時間の間、私は壊れたものを一つも修理しなかった。SEO botは正しく新URLを登録し、翻訳botは正しく記事を翻訳し、キャッシュは正しくページをキャッシュし、スケジュールスクリプトは正しくデータを記録した。各コンポーネントを単独で検査すると、全てがやるべきことをやっていた。 しかし合わさると、それらが一丸となって私に逆襲した。 私は元々新しいリリースフローをテストしたかっただけなのに、最終的に仕事方式の変革の入口に立っていることを発見した。 ## テストしたのはツール、遭遇したのは新しい仕事秩序 この期間、私は複数のAI協調ツールを自分のワークフローに接続しようとしていた。表面的にはツールのテストだが、実際に直面したのはより深い問題だった：要件・データ・画面・テスト・修正が全てAIによって介入され始めると、人が真に管理すべきは単一タスクではなく、新しい仕事秩序全体である。 最初、私はAIがコードの補完・commit・重複作業の整理を手伝ってくれるだけだと思っていた。しかしやっているうちに、AIは単純に元のフローを加速するのではなく、「フロー自体」の再理解を強いていることに気づいた。 次の六つの穴は、この授業の授業料である。そのうち四つが最も代表的で、一つずつ解剖する価値がある。残りの二つはよりオペレーション層の話だが、最後には同じ一つの問題に収束する：自動化が、全ての参加者が読める契約として書かれていなかった、ということだ。 ## なぜpush後、三つのミラーが永遠に整合しないのか？ まず背景を説明する。このサイトは[GitHubアカウントの予告なし停止](/ja/articles/resilience-engineering-after-github-suspend/)を経験し、その後repoを三つのミラーに展開した：Codeberg・GitLab・GitHubが対等並存し、ローカルgitが唯一の真実の源である。前日、GitHubが復旧し、三ミラーとローカル端のデプロイシステムが再接続されたばかりだった。そして私が記事投稿の瞬間に、この新システムの性格を本当に体感することになった。 記事をpushした後、GitHub端の自動化が動き始めた：一つのbotが四言語版URLをSEOインデックスリストに登録し、commitを追加；もう一つのbotがソーシャルメディア投稿素材を生成し、また別のcommitを追加；そして自動merge。結果：私がpushするたびに、GitHubが他の二つのミラーより一、二個のcommitを多く持つことになった。 私の最初の反応はそれらを追平することだった。間違いだった。force-pushでbotのcommitを上書きすると、次のラウンドでまた再追加され、再び上書き・再追加という典型的なモグラ叩きになった。2ラウンド叩いてから立ち止まって考えた：botは干渉ではなく、私のために働いている、そのcommitは作業成果だ。正しいやり方は`fetch`とfast-forwardで、その成果をローカルに取り込み、他の二つのミラーを補完することだ。 この穴の本質：**私は自分でcommitを成長させるシステムを構築したが、私の筋肉記憶はまだ「リモートを動かすのは私だけ」の時代に留まっていた。** ## 自動翻訳はなぜ人工翻訳を上書きしたのか？ 第二の逆襲は、より深いところから来た。 この記事の英語・日本語・簡体字版は、事前に人工で磨いたものだった：用語・語感・ローカライゼーションを全て調整済み。私は四つのファイルを配置してpush。数分後、GitHub端の自動翻訳パイプラインが起動し、翻訳記録にこの新記事のエントリーがないことを発見、忠実にタスクを実行：三言語版を再翻訳し、私が配置したファイルを上書きした。 より興味深いのは品質の方向性だった。比較した結果、機械で再翻訳した簡体字版はむしろローカライゼーションが後退していた：人工版は「进化生物学」「集群」と書き、大陸読者の慣用語；機械版は「演化生物学」「丛集」と書き、台湾用語の直接変換だった。自動化は人工成果を上書きしただけでなく、より悪いバージョンを上書きしていた。 修復自体は難しくない：ファイルを復元、commitメッセージに`[skip-translate]`マークを追加、翻訳記録のハッシュ値を整合させ、パイプラインに「これは翻訳済み、触るな」と知らせる。真の教訓はその前にある：**このパイプラインにはopt-out機構があるが、それが存在することを知っているのはパイプライン自体だけだった。** 私（および私のために働く各AI窓）の操作マニュアルには、この一条がまったくなかった。 ## 記事が公開されたのに、なぜトップページが気づかないのか？ 第三撃は、キャッシュから来た。 記事ページの四言語版は全て200を返し、タイトル正しく、カバー正常。私は作業完了だと思った。そしてトップページの「最新思考」セクションが、まだ前の記事に留まっていることを発見した。 調査のプロセスは玉ねぎを剥くようだった。まずCDNキャッシュを疑い、CloudflareのAPIでトップページURLをpurge、成功、効果なし。レスポンスヘッダーを見ると、`cf-cache-status: DYNAMIC`、CDN層でキャッシュしているのではなかった。最後にサイト自体のmiddlewareを調べると：[Workers Cache API](https://developers.cloudflare.com/workers/runtime-apis/cache/)を使ってエッジノードで各ページのHTMLをキャッシュし、24時間生存、しかもcache keyにバージョン番号サフィックスが付いている。バージョン番号が変わらなければ、キャッシュも変わらない；keyがURLと見た目が違うため、zone purgeでも照合できない。 この機構を設計した人、つまり数週間前の私自身（あるAI窓を通じて）は、コードコメントに明確に書いていた：「コンテンツ更新後はバージョン番号をbumpしてキャッシュをクリア」。しかしこの文章はコードコメント内にしか存在せず、記事投稿フローのチェックリストに入ったことがなかった。そこで「デプロイ成功」と「読者に見える」の間に、誰も思い出せない壁が立ちはだかった。 ## なぜ各AI窓に渡される仕様がバラバラなのか？ 前三つの穴を修理して、私は終わったと思った。「なぜこれらの穴が存在するのか」を振り返って検査するまでは、第四層を掘り当てた：仕様ドリフト。 私の仕事方式は複数のAI窓の並列実行：執筆担当・エンジニアリング担当・偵察担当があり、各々が同じ執筆仕様を開始前の前提としてロードする。この[一人で四つのAI窓を率いるガバナンス・アーキテクチャ](/ja/articles/governance-harness-engineering/)については、以前書いた。ある製品が実際の運用に入り始めると、問題は「作れるかどうか」ではなく、異なるタスクがどのように分解・配送・回収・再判断されるかになる。あるAIは文書を担当し、あるAIはインターフェースを担当し、あるAIはテストとフィードバックを担当；人はより高い位置に退き、アーキテクチャ設計者と判断者の役割を演じ始める。 問題は：その仕様に複数のコピーがあることだった。repo内の正本・文書ミラー・そしてデスクトップアプリケーションロード用のコピー。正本がアップグレードされても、コピーは必ずしも追いつかない；より致命的なのは、文書内で「コピーは自動同期される」と宣言されているが、実際にgit hookを調べると、その自動同期のライン、書かれているが、一度も接続されていなかった。 つまり：仕様文書自体が、防ごうとしていたエラーを犯していた。存在しない自動化を記述し、それを読む各AI窓は、同期が自動発生すると信じていた。 地図と領土の関係がここで完全に反転した。地図が領土に追いつかないのではなく、地図が領土がどう見えるかを宣言し、全員が地図に従って歩き、領土にまったく存在しない橋へと歩き込んだ。 人間のチームでは、期限切れの文書の被害は限定的だ：新人がその通りにやって、壁にぶつかり、一言聞き、誰かが訂正し、エラーはそこで止まる。だがAI協調のワークフローでは、文書はそのままagentの行動根拠である。誤った文書は静的なエラーではなく、次のラウンドの自動化行動の共通の源になる。各窓が同じ誤った地図に従って行動し、壁にぶつかって振り返り問い直す者はいない。エラーは希釈されず、忠実に同期実行されるだけだ。これはもはや文書管理の問題ではなく、AI協調時代の知識ガバナンスの問題である：agentが期限切れの仕様に基づいて行動するとき、文書そのものがシステムリスクになる。 ## レジリエンスの第二の教訓：自動化には契約が必要 最初の[レジリエンス・エンジニアリング](/ja/articles/resilience-engineering-after-github-suspend/)を書いたのは、GitHub停止が教えてくれた：単一プラットフォームに生命線を握らせるな。それはレジリエンスの第一の教訓：冗長性。 今回の第二の教訓はまったく異なる。手を出したのはプラットフォームではなく、私自身が構築したものだった。六つの穴は一つも外部依存から来ておらず、全て「私が自動化を構築して、その後全ての参加者に知らせるのを忘れた」ことから来ていた。参加者には未来の私、そして私のために働く各AI窓が含まれる。先ほど展開しなかった二つのオペレーション層の小さな穴も、分解していけば結局同じ一文に行き着く：誰かがシステムの振る舞いを変えたのに、全ての参加者が読む説明を誰も更新しなかった。 この時私は真に感じた、AIがもたらすのはツールのアップグレードではなく、「分業ロジック」の再編成である。過去我々が問うたのは：誰がやるのか？今我々が問うのは：どの部分をAIに委ねるのか？どの部分はまだ人の判断が必要か？どの部分は主権を保持すべきか？ 修復リストは実際は非常に短い。各自動化に契約を補い、全ての窓が開始時にロードする共有文書に書き込む、内容は四項目： **いつ動くか**：push後？commitメッセージに特定の語句？10分毎？ **何を動かすか**：どのファイルを変更・どのcommitを追加・どのキャッシュをクリア。 **今回動かさない方法**：`[skip-translate]`のようなopt-outマーク、なければ補う。 **事後の確認場所**：logパス・バージョン番号・manifest、問題発生時3分以内に動作したかを確認できる。 この四項目を合わせると、最小限実用になる自動化契約になる。これは事故後の個人メモではなく、どのチームでもそのまま採用できるworkflow governanceであり、二つの運用規律とセットで機能する：新しい自動化は契約が書き揃うまでパイプラインに接続しないこと、そして契約を修正したら全ての参加者（人とAI）が開始時にロードする文書を同時に更新すること。チーム規模は条件ではない。システム内に同じ状態を触る参加者が二人以上いるなら、この契約は存在すべきだ。 GoogleのようなLarge型プラットフォームが[postmortem文書](https://sre.google/sre-book/postmortem-culture/)・AI協調フロー・開発システムを統合し始めると、我々が見るのは単一製品機能ではなく、新しい組織形態が成形されつつあることだ。AIはエンジニアを支援するだけでなく、組織の記憶・修復・フィードバック・意思決定ループに入り込み始めている。一人企業はこの傾向を極限まで圧縮したものに過ぎない：「他の当番の人」に責任を転嫁することができず、全ての穴は自分で埋めたもので、全ての修復も直接次の窓の開始仕様になる。あなたが書き下すそれぞれの教訓は、翌日には何かの窓にロード・実行・検証される。postmortemの投資収益率は、チームよりもむしろ高い。 未来のチーム境界は、もはや人員編制だけで決定されるのではなく、人・モデル・データ・フロー・権限が共同で構成するかもしれない。製品ももはや開発される物体ではなく、継続的に学習・修正・進化するシステムである。 ## 委譲するのはタスクか、判断権か？ 契約が解決するのは「見えない」問題である。しかしこの3時間はもう一つのより深い問題を残し、契約では解決できない。 我々がpromptを投げる時、見かけ上は指令を発しているだけだが、実際には判断権の一部をシステムに委譲している。ここで本当に考える価値があるのは、AIがタスクを完了できるかではなく、我々が自分が何を委譲したかを知っているかである。 今回の実装が私に与えた最大の気づきは：AIは人の代わりに仕事を完成するだけでなく、人の思考の前段に入り込んでいることだ。それは要求に応答するだけでなく、我々がどのように問題を記述し・タスクを分割し・優先順位を設定し、そして製品がどのように完成されるべきかを理解することにも影響を与え始めている。 したがって、真の問題はおそらくAIが人を置き換えるかではなく、人が効率を追求する過程で、徐々に自分の判断ポジションを放棄するかである。ツールがますます器官に似てくると、我々は再確認しなければならない：この器官は私に仕えるのか、それとも私があるシステムの延長になろうとしているのか？ ここで、比喩ではない具体的な判断基準を一つ提示したい：システムが自らトリガーし、自ら状態を書き換え、そして次のラウンドの意思決定に影響を与え始めたとき、それはもはや単なるツールではなく、ガバナンスの範囲に入ったのだ。ハンマーは真夜中に勝手に働き始めないが、自ら翻訳し、自らcommitを追加し、トップページがどうあるべきかを自ら決めるシステムは働き始める。前者に必要なのはメンテナンスだけだが、後者には契約・権限・説明責任が必要だ。この線をどこに引くかが、システムへの姿勢を決める：線のこちら側ではあなたは利用者であり、あちら側では統治者である。 これは私が前日に書いたばかりの問題にも戻る：[AIは結局外部ツールなのか、それとも我々の仕事生命体の器官になりつつあるのか](/ja/articles/organism-or-organ/)？それが単なるツールなら、人はまだ主体である；しかしそれが器官になるなら、我々はこの生命体が結局誰に支配されるのかを明確に問わなければならない。 だから、この件は表面的には技術問題だが、深層では実はガバナンス問題である。AIの鍵はモデル能力だけでなく、権限・データ・フロー・責任・主体性がどのように再配置されるかにある。 ## 反作用するものは、全て生きている 3時間の混戦終了後、私はこのシステムを見直した：自分でcommitを成長させるrepo・自分で翻訳するパイプライン・自分で帳簿をつけるスケジューラー・エッジノードで各ページを記憶するキャッシュ。 それは確実にますます生き物に似てきている。そして生き物とはこういうものだ：指令を待ってから動くのではなく、自分のリズム・自分の反射・自分の新陳代謝を持っている。あなたがそれを養い・拡充すると、いつかその挙動があなたの地図を超え、そしてある深夜に反作用を与えて、思い出させる：地図を更新する時だ。 私はこの方向に探索を続ける、なぜなら私はますます確信しているからだ、これは単純な効率革命ではなく、仕事文明の書き換えである。真に重要なのは、我々がどれだけのAIツールを使ったかではなく、AIが徐々に器官になる時代に、我々がまだ人の主体性・判断力・ガバナンス能力を保てるかである。 結局のところ、未来の仕事のリスクは自動化が壊れることではなく、自動化が全て正常に動作しているのに、それらが互いに何を影響し合っているかを誰も知らないことだ。壊れたものはエラーを出し、痕跡を残し、修理のために立ち止まらせる；正常に動作するものはそうしない。静かに積み重なり、ある深夜に一斉に姿を現すだけだ。 逆襲を食らうことは失敗ではなく、システム進化の必然である。エラーはこれからも現れるが、恐れることはない。『老子』の「禍は福の倚る所、福は禍の伏す所」は正しい。真に重要なのは、全てのエラーに痕跡を残させ、修正を促させることだ。地図をより正確に、契約をより明確にし、次のイテレーションを前回より成熟させることだ。