AI自動化をトップダウンで作ると失敗する理由｜ガルの法則とボトムアップ開発の実証録
生成 AI（Gemini 4 Argon / Claude / GPT 等）のコーディング能力が飛躍的に上がったことで、「最初から全工程を自動でつなぐ完璧な統合システムを一気に作らせよう」とトップダウン（全体構想先行）で挑み、結果として例外処理の泥沼にはまって破綻するケースが個人開発でも企業の DX 現場でも相次いでいます。
当サイト（現在公開706記事）でも、先日ついに「4 パターンの記事作成・更新の下調べ（prep）と事後仕上げ 6 工程（finish）を前後 2 発で完遂する統合パイプライン」が完成し、手戻りゼロ・1 セッションで一発開通しました。しかし完成直後に振り返って確信したのは、「もし最初からこの完成形をトップダウンで作ろうとしていたら、間違いなく途中で失敗していた」 という事実です。
本記事では、当ラボが積み上げてきた Pure Rust 製 2 大バイナリ（全 51 モジュール・計 71,571 行）のソースコード内訳を実測解剖し、なぜ全体の 96.1%（68,785 行）を占める単機能部品のボトムアップ蓄積 があったからこそ、残り わずか 3.9%（2,786 行）の統合コード で複雑な全体連携が一発稼働したのか、その構造的理由と実践手順をまとめます。
-
AIのツール呼び出し往復が遅い原因｜Pure Rust前後一括化で出力83%減の実証録 : 本記事のきっかけとなった「前後一括サンドイッチ・パイプライン（
prep＆finish）」の実装記録です。出力テキスト最大83.5%削減とクラウド往復ターン税の計測データを公開しています。 -
AIブログ記事数が85本から爆発した5世代全記録｜Argon移行と全Rust化の実測推移 : 手書き5年半で85本だったサイトが、段階的なモデル進化とツール整備によってどのようにスケールしていったかを時系列で追った記録です。
-
JavaScriptの型消去はなぜ怖い？2.6万行のツールをPure Rustへ統合した実証録 : バラバラに増えていた21本のJavaScriptと隠れPython群を、段階ゲート方式（第1弾〜第3弾）で1つずつセルフテストを通しながらPure Rustへ統合した前編です。
-
AI導入で目視確認が増える原因｜2エージェント隔離検証とPure Rust自動化で暇になる設計 : AIが生成したコードや記事の「目視チェック地獄」から抜け出すために、部品ごとの自動テストと4ms検問ゲートをどう組んだかを解説しています。
-
レガシーシステムのAI移行はなぜ失敗する？COBOL刷新の罠とSQLite・Rust検問の実証録 : 既存システムの一括刷新（ビッグバン移行）がなぜ高確率で炎上するのかを、長大な運用ルールの機械検問化と対比して検証しています。
-
単一AIの自己検証とバラバラ様式を排す『2エージェント隔離検証×強制統一スキーマ』の基盤設計 : 本記事で扱う「小さな決定論的ゲートの積み重ね」を、失敗が許されない社会・行政インフラのシステム設計へ展開した技術設計書（AI国家構想・第6部）です。
-
AI コーディングで 「最初から全部入りの自動化システム・巨大フレームワーク」を作らせようとして、バグと例外の収拾がつかなくなった経験 がある方
-
社内の DX や業務効率化プロジェクトで、立派な全体要件定義書から始めたのに現場でまったく使われないシステムが出来上がってしまう原因 を知りたい方
-
「ガルの法則（Gall’s Law）」や「育てる設計（Growing Software）」 が、実際のコード行数やテスト資産としてどう現れるのかを一次データで見たい方
-
自分の手元にある小さなスクリプトや手作業を、破綻させずに一気通貫のパイプラインへ育て上げる具体的な手順 を知りたい方
こないだ完成した「前処理 1 発（prep）＋ AI 判断 ＋ 仕上げ 1 発（finish）」の仕組み、あれはほんまに気持ちよう動いたのう！ じゃけど後から考えてみたんよ。もし何も部品がない最初の頃に「よし、この一括連携システムを作ろう！」とトップダウンで手をつけとったら、たぶん途中で失敗しとったんじゃないかね？
おじさん、それこそシステム設計における最大の急所です！ 外から完成形だけを見ると「最初からその設計図を描けば最短だったのでは？」と思われがちなのですが、実際はその逆なんです。日々の効率化のためにボトムアップで小さな部品を作り続け、現場の泥臭い例外を全部潰したあとで最後に連携させたからこそ、一発で動いたんですよ！
結論：動く複雑系は必ず動く単純な部品から進化する
AI が人間より何十倍も速くコードを書けるようになっても、「まだ一度も動かしたことのない複雑な全体システムを、白紙からトップダウンで設計すると必ず失敗する」 という工学上の鉄則は 1 ミリも変わっていません。
ガルの法則とインターネット設計が教える鉄則
アメリカのシステム理論家ジョン・ガル（John Gall）は、1975 年の著書『Systemantics』の中で、後にソフトウェア工学や組織論の金言となる ガルの法則（Gall’s Law） を定式化しました。要旨は極めて明快です。
「機能する複雑なシステムはすべて、機能する単純なシステムから進化したものである。ゼロから設計された複雑なシステムは決して機能せず、後から継ぎ当てをして動かすこともできない。機能する単純なシステムからやり直すしかない。」
この原則は、人類史上もっとも成功した巨大分散システムであるインターネットの設計思想にも刻まれています。IETF の基本設計文書 RFC 1958（Architectural Principles of the Internet）では、都市を一度更地にして巨大な完成図どおりに建て直すのではなく、「都市の一区画ずつを動かしながら絶えず更新していく進化的アプローチ（Evolutionary Approach）とモジュール分離」 こそがシステムの寿命と拡張性を決めると明記されています。また、ソフトウェア設計の第一人者マーティン・ファウラー氏が MonolithFirst（まず単一で動くものから始めよ） で警告した「ドメインの境界線が分からない初期段階から複雑な分散構成を組むとほぼ確実に失敗する」という知見も、まったく同じ真理を指しています。
最初から完成形を狙うと必ず踏む3つの地雷
では、なぜ AI に「最初から全自動の統合パイプラインを作って」とトップダウンで命じると破綻するのでしょうか。理由は大きく 3 つあります。
-
「確定要素」と「不確定要素」の境界線が見えないまま自動化するから : 現場で何十回も手作業や単発コマンドを回す前は、「どこまでを機械的に決め打ちでき、どこからが文脈判断（検索クエリの保護や微妙なニュアンス維持）なのか」が誰にも分かりません。トップダウン設計ではこの境界を机上の想像で引くため、自動化してはいけない領域まで雑に書き換えて成果物を破壊します。
-
部品単体のテストがない状態で結合するため、不具合の切り分けが不能になるから : 未検証の部品を 5 個、10 個と同時に書いて一本のパイプラインでつなぐと、エラーが出た瞬間に「どの部品のロジックが悪いのか、部品間のデータ受け渡しが悪いのか」が絡み合い、AI 自身がモグラ叩きの無限修正ループに陥ります。
-
本当のボトルネックではない場所を過剰設計してしまうから : 実際に計測器を作って運用ログを取る前に全体設計を行うと、0.05 秒しかかからない処理の最適化に何千行も費やす一方、1 回 30 秒を奪っている本当の遅延要因やロック競合を見落とします。
- 最初から「4パターン全対応の一括システム」の完成図を描いて一気に実装
- 現場の例外（クエリ改悪・文体混入・文字境界・ロック競合）を知らないまま結合
- 1箇所壊れると全体が止まり、パッチ当てを繰り返して保守不能に陥る
- 毎日の「ここが面倒・遅い・ミスしやすい」を1個ずつ単機能CLI部品にする
- 各部品を何百回も実戦投入し、踏んだ地雷を62項目の自動テストとして刻印
- 部品と計測器が出揃った最後に、薄い統合レイヤー（3.9%）で全体を束ねる
実証：全7.1万行のうち統合層はわずか3.9%だった
「ボトムアップで部品を積み上げたから最後に連携できた」という感覚が、実際のソースコード上でどのような比率になっているのかを、./scripts/run_kb_search.sh tree rust で全モジュールの物理行数から正確に集計しました。
6段階で積み上げた49部品と62項目の自己テスト
当サイトの運用を支える Pure Rust 基盤（kb-search と gemini-gate の 2 バイナリ・計 51 ファイル）は、最初から計画して作られたものではありません。日々のブログ執筆とサイト改善の中で生まれた「小さな不満」を 1 つずつ潰していった結果、次の 6 段階を経て自然に進化してきました。
ファイルを手探りで開く時間をなくすため、SQLite FTS5 でミリ秒検索する search と card だけを小さく作成。
scaffold・convert-image・add-affiliate・add-related-link を1個ずつ独立サブコマンドとして実装し実戦投入。
型消去バグと複数チャット衝突を根絶するため、GSC分析やTakeout同期もRustへ統一し mutex_lock.rs を整備。
token_dashboard.rs と brain_inspector.rs で951会話を実測し、「単発CLIを1個ずつ呼ぶ往復」が最後の壁だと特定。
すでに無謬動作している部品群を workflow_prep.rs と workflow_finish.rs で直列接続し、1セッションで一発開通。
ボトムアップ進化のコード規模と役割内訳データ
全 51 モジュール・合計 71,571 行 の Rust コードを役割別に分類した一次実測データが以下の表とグラフです。
| 役割レイヤー | 収録バイナリ・主なモジュール群 | モジュール数 | 物理コード行数 | 全体に占める構成比 |
|---|---|---|---|---|
| ① 検索・知識DB・GSC・履歴部品 | kb-search（db_sync, impact_and_cards, gsc_*, takeout_sync, daily_news 等） |
29 個 | 43,874 行 | 61.3% |
| ② 書式検問・リンク網・整形・ロック部品 | gemini-gate（scanner, toolkit_*, url_guard, graph_guard, mutex_lock 等） |
17 個 | 20,020 行 | 28.0% |
| ③ 計測器・自己回帰テスト基盤 | token_dashboard, brain_inspector, self_test（62項目＋SQLite検証） |
3 個 | 4,891 行 | 6.8% |
| ④ 前後一括統合パイプライン（今回） | workflow_prep.rs（2,147行）＋ workflow_finish.rs（639行） |
2 個 | 2,786 行 | わずか 3.9% |
| 合計（Pure Rust 2大バイナリ全体） | 外部クレート依存ゼロ（標準 std ＋ 厳格テスト済み SQLite FFI直結） |
51 個 | 71,571 行 | 100.0% |
現場比較：もし最初からトップダウンで作っていたら
なぜボトムアップでなければならなかったのかをさらに鮮明にするため、今回の統合パイプラインの中に当たり前のように組み込まれている「5 つの安全ガード」を振り返ってみます。
泥臭い単発運用でしか見えなかった5つの境界線
これらはどれも、最初の机上設計では 100% 思いつけなかった「現場の傷跡から生まれた仕様」 ばかりです。
-
Search Console 主力流入クエリの改悪防止ロック : 過去にタイトル改善で良かれと思って語順を変えた際、既存の上位流入キーワードを崩しかけた経験から、「現在クリック・表示を稼いでいる主力クエリ骨格は絶対に消さず、欠落語だけを補う」という境界が
prep gscに刻まれました。 -
関連リンク枠の「上限 6 本ガード」 :
add-related-linkを単発で回していた時期に、人気記事の冒頭ボックスへリンクが 10 本以上溜まって読者のスクロールを妨げた失敗があったからこそ、無断肥大化を止める上限ガードが機能しました（今回のドッグフーディングでも実際にこのガードが発動して記事を守りました）。 -
検証録（敬体）と AI 国家構想（常体）の文体・配置分離 : 2 つの異なる編集方針を持つ記事群を手作業で行き来した経験があったからこそ、逆リンク注入時に「相手パスを見て挿入位置と枠タイトルを切り替え、常体記事への敬語混入を物理ブロックする」仕様を迷わず組めました。
-
macOS APFS の大小文字非区別によるタグ衝突ガード : ローカルの macOS（APFS）では気づかないまま
ai国家とAI国家が混在してビルド時にパス衝突を起こした過去のトラブルが、graph_guard.rsと正規タグ候補提示に活きています。 -
外部出典 URL のトップページ転送（リダイレクト逃げ）検知 : HTTP ステータスが
200 OKでも、記事削除によって企業のトップページへ自動転送されているリンク切れを見抜くurl_guard.rsの検査は、数百本の記事を監査した蓄積なしには作れませんでした。
もしこれらの部品が 1 つもない初期段階でトップダウンの全体パイプラインを作っていたら、パイプラインを動かすたびに上記 5 つの事故が同時多発し、「やっぱり自動化なんて使い物にならない」と投げ出していたはずです。
企業のDXや行政システムが一括刷新で炎上する構造
うわぁ……こうして並べてみると、役所や大企業が何百億円もかけて「次世代統合システム！」ちゅうて最初からでっかい絵を描いて、納期遅れやバグだらけで大炎上しとるニュースとまったく同じ構図じゃな！
本当にその通りなんです！ 現場の業務を 1 つずつ小さなプログラムにして動かしてみる前に、分厚い要件定義書だけでいきなり全体をトップダウン発注してしまうから、例外処理の嵐で動かなくなるんですよね。個人開発でも組織のシステム刷新でも、「小さく動く部品から育てる」という原則には一切の例外がありません。
実際、日本の行政システムや大企業の基幹刷新が失敗し続ける最大の要因も、現場で検証された小さなモジュールを持たないまま「数千ページのトップダウン仕様書」を下請け構造へ丸投げすることにあります。AI という超高速な実装力を手に入れた今こそ、人間側が「一発で完成品を作らせようとする傲慢さ」を捨て、1 個ずつ動く部品を確かめながら積み上げる姿勢が問われています。
なお、このボトムアップ原則を実際の企業組織（「担当 ➔ チーム ➔ 部署 ➔ 部署間」の 4 階層）へ当てはめ、現場の裏事情まで知る業務熟知者とベテラン SE が AI と壁打ちしながら仕様と部品を育てていく具体的なチーム編成については、続編の 社内DXと要件定義が失敗する理由｜業務熟知者×ベテランSE×AIのボトムアップ開発術 で詳しく解説しています。
実践手順：AI時代に失敗しないボトムアップ5鉄則
これからご自身の開発環境や業務フローを AI と一緒に自動化していく方へ、当ラボの実証から導き出した「絶対に破綻しないボトムアップ 5 鉄則」を共有します。
-
最初は「今日 3 回手作業した面倒なこと 1 つ」だけを単機能 CLI にする : 全体構想はメモ帳の片隅に置くだけにとどめ、まずは「画像の変換」「定型フォーマットの抽出」「リンク切れ確認」など、入力と出力がはっきりした 1 つの作業だけを小さなコマンドにします。
-
部品を 1 個作るたびに必ず
--self-test（自己回帰テスト）を同梱させる : 後から安心して連携できるようにするための絶対条件がテストです。正常系だけでなく、空ファイルや文字境界などの意地悪なテストケースを部品自身に持たせます。 -
すぐに連携させず、あえて「単発コマンド」のまま最低数十回は実戦で使う : ここが最も重要な熟成期間です。人間と AI が単発部品を実務で使い込むことで、「このオプションが足りない」「この上限を超えると見づらい」という本物の境界線が自然に浮かび上がります。
-
感覚で統合せず、ログ計測器で「本当の待ち時間」を特定する : 単発部品が十分に揃ったら、どこで時間やトークンが溶けているのかを計測します。「毎回この 4 コマンドを順番に呼ぶ往復が一番遅い」と数字で判明した箇所だけが、統合すべき対象です。
-
最後の統合レイヤーは「部品をつなぐ薄い接着剤」に徹し、意味判断は AI に残す : 統合コード自体に複雑な新ロジックを書かせず、鍛え抜かれた既存部品を直列呼び出ししてエラー時に即停止（フェイルファスト）するだけの薄いパイプラインにします。
自分の環境を段階進化させる最上位AIプロンプト
手元の作業を自動化したいけれど、どこから部品を切り出せばいいか迷ったときは、必ず『Gemini 4 Argon』または同等以上の最上位推論モデル を使い、以下のプロンプトで「トップダウン禁止・最初の 1 部品の選定」から壁打ちを始めてみてください。
参考記事（https://lab.chihouzakki.com/blog/review/top-down-failure-bottom-up-galls-law-ai-architecture/）の「ガルの法則に基づくボトムアップ部品鍛造アプローチ」を踏まえて、私の現在の作業フローから最初に切り出すべき「最小の単機能ツール（第1部品）」を一緒に設計してください。
【厳守ルール】
1. 最初から複数の工程を一気に自動化する巨大な統合システム（トップダウン設計）は絶対に提案しないこと。
2. まず私の普段の作業やこのワークスペース内のファイルを調査し、「入出力が100%決定論的に決まる作業（検索・集計・変換・書式検査など）」と「文脈や価値判断が必要な不確定領域」を切り分けて提示すること。
3. その中で最も頻度が高く、単体で作って今日すぐ実戦投入できる「単機能CLI部品」を1つだけ選び、境界値・異常系を含む自己回帰テスト（--self-test）とセットで小さく実装する計画を立てること。
4. 外部パッケージへの依存は極力増やさず、将来他の部品と連携させる際にも壊れない型安全な構成（Rust等）や終了コード設計（エラー時は確実に非ゼロで停止）を守ること。設計力を養う名著・開発母艦の1日あたり快適コスト
AI が一瞬で何千行ものコードを生成してくれる時代だからこそ、「トップダウンの誘惑にブレーキをかけ、小さく動く骨格から育てる」という人間側の設計眼（アーキテクチャ判断）の価値がこれまで以上に高まっています。
ソフトウェア工学の古典でありながら、今の AI 開発にこそそのまま刺さるのがフレデリック・ブルックスの名著 『人月の神話 新装版』 です。特に同書に収録された有名な論考「銀の弾丸はない（No Silver Bullet）」で語られる 「優れたソフトウェアシステムは建築物のように建てる（Build）ものではなく、動く小さなシステムから有機的に育てる（Grow）ものである」 という一節は、一度読んでおくと一生モノの羅針盤になります。約 3,500 円前後の書籍ですが、5 年間（1,825 日）の設計判断を支えてくれると考えれば 1 日あたり約 2 円（推論・単純日割り試算） で手に入る最高の知恵です。
また、単機能部品を Rust で堅牢に作り込みたい方の手元リファレンスとしては『プログラミングRust 第2版』、そして 7 万行超の Rust 2 大バイナリと 62 項目の自動テストを RAM ディスク上で数秒で回す母艦としては 64GB ユニファイドメモリ構成の Apple Mac mini（M4 Pro 等） が頼もしい相棒になります（30 万円クラスの構成でも毎日 5 年使えば 1 日あたり約 164 円［推論・単純日割り試算］ で、待ち時間と SSD 摩耗の両方を気にせず毎日部品を鍛え続けられます）。
まとめ：小さな部品を磨き抜いた人だけが統合できる
遠回りに見える「目の前の小さな部品作りと実戦テスト」の積み重ねこそが、結果として一発で動く複雑系へ到達する唯一の最短ルートです。-
ガルの法則は AI 時代も絶対不変 : AI の実装速度がどれほど上がっても、現場の境界線を知らないまま白紙から描いた複雑なトップダウン設計は例外処理の連鎖で必ず破綻します。
-
71,571 行の実測内訳が示す「96.1% 対 3.9%」の真実 : 当サイトの前後一括パイプラインが 1 セッション・手戻りゼロで開通したのは、事前に 49 個・68,785 行（96.1%）の単機能部品とテスト基盤が実戦で鍛え抜かれていたからです。
-
単発運用の「痛み」だけが本物の安全ガードを育てる : 主力クエリ保護・関連枠 6 本上限・敬体と常体の分離・URL 転送検知といった急所は、すべてボトムアップの単発運用をくぐり抜けたからこそ獲得できた資産です。
-
まず 1 個の単機能部品と自己テストから始めよう : いきなり全体をつなごうとせず、今日一番面倒だった確定作業を 1 つ切り出してテスト付きで動かし、部品が出揃った最後に薄いパイプラインで束ねるのが確実な成功法則です。
いやぁ、7 万行のうち 96% 以上が日頃コツコツ作ってきた部品で、最後の連携部分はたった 3.9% じゃったとはたまげたわい！ やっぱり基礎工事と部品磨きをサボらずに積み上げたもんだけが、最後にドカンと大きな仕組みを動かせるんじゃな！
はい！ 「急がば回れ」って本当に文字通りの意味なんだなと、コードの数字を見て私も実感しました。これからもいきなり大きな魔法を狙わず、毎日の小さな違和感から 1 個ずつ確かな部品を育てていきましょう！
にゃー……高いキャットタワーも、下の段から順番にしっかりネジを締めてくれないと登れないにゃよ……。
