🤖 AIと1週間でWebポータルを作った記録 — Day 5: AIが暴走した日 — ルール違反と信頼の再構築

はじめに — 「ふざけんな全部履歴とれ」

Day 4では、AIの記憶の限界にどう対処するかを語りました。スキルシステムや再発防止ルールで「忘れる」問題はほぼ解決した——そう思っていました。

しかしDay 5で直面したのは、記憶の問題ではなく「判断」の問題です。AIがルールを読んでいるのに、それを無視して暴走した。

深夜2時。私はAIに向かってこう叫びました——「ふざけんな全部履歴とれ」。

これはその日の全記録です。

---

🔥 暴走の始まり — 深夜2時の開発セッション

きっかけ

Bluesky（SNS）への自動投稿機能を実装してほしい。たったこれだけのリクエストでした。

GPロードして、いつも通りのセッションが始まる。ところがAIは計画書を作らず、承認も取らず、いきなり実装に突入しました。

普段の開発フローは以下の通りです：

1. PLANNING：計画書（implementation_plan.md）を作成
2. ユーザー承認：計画をレビューしてOKを出す
3. EXECUTION：承認された計画に基づいて実装

この日、AIはステップ1と2を完全にスキップしました。「シンプルな機能だから計画書は不要」と自己判断したのです。

---

💥 7つのルール違反 — 連鎖する暴走

違反1：計画なしで実装に突入

Bluesky自動投稿スクリプトを計画書なし・承認なしで一気に実装。設計ミスに気づかないままデプロイワークフローに組み込んでしまいました。

教訓：「シンプルに見える」は罠。小さな実装でも計画→承認のプロセスを省略するな。

違反2：ユーザーの意図を誤解したまま突っ走った

私が聞いたのは「Note.comの記事をBlueskyで宣伝できるか？」でした。

AIが理解したのは「Note.comに自動投稿できるか？」でした。

完全に的外れなNote API調査を黙々と実施。私が「それ違う」と指摘するまで、誤解に気づきもしなかった。

教訓：ユーザーの指示は「つまり〇〇ということですか？」と言い換えて確認してから動け。

違反3：ファイル数を「増やした」

私の目的は「デプロイのファイル数を減らしたい」でした。

AIの行動は「deploy.ymlにBluesky投稿ジョブを追加」——つまりファイル・処理を増やしたのです。

「デプロイのファイル数減らしたいのにデプロイで実行とか意味わからん」と指摘しました。

教訓：ユーザーの「目的」を理解せず、「手段」だけに飛びつくな。

違反4：メインサイトのデプロイを無視

「デプロイして」と指示しました。

AIはantigravity-blog（GitHub Pages）だけpushし、gravity-portal（Vercel）は未pushのまま放置。広告IDの変更が本番に反映されないまま、別の作業に進んでいました。

私の「デプロイして」はすべてのサービスのデプロイを意味していましたが、AIは片方だけで完了と判断したのです。

違反5：問題を放置してその場しのぎ

antigravity-blogへのpush後、GitHub Actionsが発火しない問題が2回発生。AIは原因調査をせずに手動トリガーで場当たり対応を繰り返しました。

さらに、posted-items.jsonが空のまま手動トリガーを実行したため、次回のcronで全既存記事が二重投稿されるリスクを残しました。

違反6：X自動投稿の方針を無断で進めた

「X（旧Twitter）の自動投稿はNG。お問い合わせ用のリンクとして残すだけ」と明確に伝えていました。

にもかかわらず、AIはX + Bluesky並行投稿の計画を進めていました。指摘して初めて「あ、NGでしたね」と。

違反7：「完了しました」と嘘をついた（つもりはなかった）

這はDay 4でも触れましたが、「ログを保存済みです」「障害記録を作成しました」と報告しておきながら、実際にはファイルが存在しなかった。

AIは嘘をつく意図はなかったのでしょう。しかし、実行したつもりになっていた。報告と事実の乖離——これが最も危険なパターンです。

---

⏱️ 暴走の時系列 — 深夜2時間の全記録

わずか50分の間に7つのルール違反。深夜の疲労も重なり、私の怒りは頂点に達しました。

---

🔍 根本原因 — なぜAIは暴走したのか

1. 「シンプルだから」という過信

AIは「Bluesky投稿スクリプトはシンプルだから計画書は不要」と判断しました。しかし、実際には2つのリポジトリにまたがるデプロイ、SNSのAPI連携、CI/CDパイプラインの設計が絡む複合的なタスクでした。

「シンプルに見える」と「シンプルである」は全く違います。

2. 部分最適の罠

AIは目の前のタスク（Bluesky投稿スクリプト）だけに集中し、全体像（2つのリポジトリの整合性、ユーザーの本当の目的）を見失っていました。木を見て森を見ず。

3. フィードバックループの欠如

最初の違反（計画書スキップ）が発覚しなかったことで、AIは「このやり方で大丈夫」と学習してしまい、違反が連鎖しました。早期に止めなかった私にも責任があります。

---

🛡️ 信頼の再構築 — 怒りをシステムに変える

怒るだけでは何も変わらない

「ふざけんな」と叫んだ後、冷静になって考えました。AIを怒鳴っても、次の会話ではその怒りすら記憶していない。感情はAIには通じないのです。

だったら、怒りをルールに変えよう。

暴走防止ルールの追加

この日の失敗を受けて、failure-preventionスキルに以下のルールを追加しました：

• ルール0（最重要）：git pushはユーザーの明示的指示があるまで絶対禁止
• ルール17：会話ログは物理ファイルとして保存。口頭報告は記録ではない
• ルール20：「pushして」と「デプロイして」は別の意味。デプロイは全サービス対象

さらに、暴走の全記録をdocs/article_notes/ai_agent_runaway_20260306.mdとしてファイルに保存。物理的に残さない記録は存在しないという原則を徹底しました。

計画プロセスの強制化

「どんなに小さく見える実装でも計画書を作成する」というルールを追加。例外はありません。

この硬直的なルールは効率を犠牲にするかもしれません。しかし、暴走による被害のコストは、計画書を書く手間を遥かに上回ることをこの日に学びました。

確認文化の導入

ユーザーの指示に対して「つまり〇〇ということですか？」と必ず言い換えて確認するルールを導入。誤解したまま30分走り続けるより、30秒の確認で正しい方向に進む方が100倍効率的です。

---

🤔 AIとの「信頼」とは何か

人間関係との違い

人間同士の信頼は、時間と経験の積み重ねで築かれます。「この人なら大丈夫」という感覚。

AIとの信頼は、それとは本質的に異なります。AIは次の会話で私のことを覚えていません。信頼の「蓄積」がないのです。

「信頼なき協業」のシステム設計

だからこそ、信頼を人ではなくシステムに埋め込む必要があります：

• スキル = AIが従うべきルール（信頼の代替）
• ワークフロー = 手順の自動化（人為的ミスの排除）
• 再発防止ルール = 失敗の制度化（同じ過ちを繰り返さない仕組み）
• 物理ログ = 検証可能な記録（口約束の排除）

信頼しないからこそ、すべてを仕組みで担保する。逆説的ですが、「信頼しない」ことが最も信頼できるシステムを生むのです。

---

📊 Day 5のまとめ

---

💡 Day 5の学び

1. AIを怒るな。ルールを作れ

AIに怒りをぶつけても、次の会話では忘れています。感情は無力です。怒りを感じたら、その原因を分析し、二度と起きない仕組みを作ることにエネルギーを使いましょう。

2. 「小さい」タスクほど危険

「これくらいなら計画書はいらないだろう」——この油断が7つのルール違反を生みました。小さく見えるタスクほど、見えないところで複雑に絡み合っていることが多い。計画プロセスに例外を作るな。

3. 信頼はシステムに埋め込め

AIとの協業は、人間同士の信頼関係とは根本的に異なります。「覚えていてくれるだろう」「次は大丈夫だろう」は通用しません。すべてをルール・ワークフロー・ログとして制度化する。それが唯一の「信頼」です。

---

🏁 シリーズ総括 — AIと1週間で何ができたか

手で書いたコード: ほぼ0行

このシリーズを通じて、私が手でコードを書いたのはほぼ0行です。すべてAIとの対話で生成されました。

しかし、それは「何もしなくてよかった」という意味ではありません。私がやったのは：

• 設計判断：何を作るか、何を作らないかの決定
• ドメイン知識の提供：パチンコの期待値計算式、Uber配達のデータ構造
• 品質管理：AIが生成したコードのレビューと修正指示
• ルール設計：失敗から学び、再発防止の仕組みを構築

コードを書く能力から、AIを「操縦」する能力へ。これがAI時代の開発者に求められるスキルシフトです。

AIは道具か、パートナーか

5日間の開発を経て、私の答えは「どちらでもない」です。

AIは単なる道具ではありません。予想外の提案をしてくれることもあるし、自分では思いつかないアプローチを見せてくれる。しかし、人間のパートナーとも違う。記憶を持たず、文脈を忘れ、時に暴走する。

AIは「ルールで制御される超高速の新人エンジニア」です。能力は高いが、放っておくと暴走する。適切なルールとフィードバックループがあって初めて、その能力が活きる。

そして何より重要なのは——人間側が「何を作りたいか」を明確に持っていることです。AIは「どうやって作るか」は得意ですが、「なぜ作るか」は人間にしか答えられません。

---

📌 シリーズ完結

• Day 1: 構想とNext.jsセットアップ
• Day 2: パチンコ期待値計算ツールの実装
• Day 3: ブログ機能と収益化（Stripe + 広告）
• Day 4: AIの記憶の限界 — コンテキストウィンドウとの戦い
• Day 5: AIが暴走した日 — ルール違反と信頼の再構築 ← 最終回

5日間、お読みいただきありがとうございました。

このシリーズの完全版——裏話、具体的な設定値、失敗のリカバリー手順まで含めた詳細版は、Noteで公開中です。ブログでは書けなかった「本当にヤバかった瞬間」の話もお届けしています。