「チェスタトンのフェンス」とは——AIが「この仕組み、要らないですよね」と言ってきたときの判断基準

「このテーブル、消していいですよね」から会話は始まった

正直に申し上げると、この話を書こうと思ったきっかけは、お客様から受けた一つの質問でした。

ある化粧品メーカーの内製担当の方が、自分でコードを触りながら開発を進める伴走を始めた直後にこう尋ねてきました。「一旦、データベースをがらっと変えちゃうんじゃないかという懸念がある。まず自分で触ってみて、あとは判断してもらう形でどんどん進めても問題ないか」。データベースというのは、業務のデータを溜めている台帳のことです。

この懸念は的を射ています。AIに「この画面を整理してください」と頼むと、関連する処理を洗い出し、使われていない項目や重複した分岐を見つけて「不要と判断しました」と提案してきます。動きを変えずに内部構造だけ作り直すリファクタリングは、AIがとくに得意とする作業です。提案の精度自体は高い。問題は、AIが見ているのが「いま動いているコードの形」だけだという点にあります。

3年前に、ある顧客からのクレームを受けて追加された検査の分岐。5年前の監査で指摘されて足された二重チェック。10年前に特定の取引先だけ桁数が違うという事情で入った例外処理。これらはコードの上では、ただの「使われているか分かりにくい分岐」として並んでいます。理由はコードには書かれていません。書かれているのは、せいぜい「※特別対応」というコメントだけ。

で、何が起きるか。AIは形が同じものを同じように扱います。本当に腐っている処理と、誰かが痛い目を見た末に立てた処理を、区別できないまま同じ提案に混ぜてきます。そして私たち人間の側も、画面に並んだ20件の「不要と判断しました」を一件ずつ検証する体力がないまま、まとめて承認してしまう。

この構造には、ほぼ100年前に名前が付いていました。

チェスタトンのフェンスとは——原典は「残せ」と言っていない

このセクションで言いたいことは一つです。この警句は現状維持を勧める言葉ではありません。

言い出したのは、英国の作家G・K・チェスタトンです。原典は1929年の著書『The Thing』。その中の「The Drift from Domesticity」という一篇に出てきます。日本語では「チェスタトンの柵」とも訳されます。該当箇所は、だいたいこういう話です。

道を横切って一つの柵、あるいは門が立っている。近代的なタイプの改革者は、そこへ軽やかに歩み寄ってこう言う。「これが何の役に立つのか分からない。片付けてしまおう」。それに対して、より知性のあるタイプの改革者はこう答えるのがよい。「役に立つのが分からないのなら、片付けさせはしない。行って、考えてきなさい。戻ってきて、役に立つのが分かったと言えたなら、壊すのを許してやろう」。

そして続けて、こう書かれています。その門や柵は、そこに自然に生えてきたわけではない。誰かが、誰かのためによいことだと考える理由があった——。

ここが、日本語で流通している解説でほとんど触れられない部分です。チェスタトンは「柵を残せ」と言っていません。「行って、考えてこい」と言っています。つまり、理解する責任を改革する側に負わせたのです。理由が分かったなら壊してよい、とはっきり書いてある。

この違いは、実務ではかなり大きく効いてきます。「チェスタトンのフェンスだから触らないでおこう」という使い方は、原典の半分しか読んでいません。正しくは「壊す前に、立った理由を調べる工数を先に払え」という要求です。調べた結果が「もう理由が消えている」なら、堂々と壊せます。

誤解のないように申し上げると、これは慎重さの勧めでもありません。調べるコストを払わずに壊すのも、調べもせずに残すのも、どちらも同じ怠慢として扱われます。チェスタトンが嫌ったのは、分からないまま動く態度そのものでした。

AI時代に、この警句の意味が変わった3つのこと

ここで押さえておきたいのは、2026年になって柵の話が急に効いてきた理由です。原典は100年前ですが、状況が3つ変わりました。

1つ目は、柵を撤去するコストがほぼゼロになったこと。 以前は、意味の分からない仕組みを消すには人手がかかりました。コードを読み、影響を調べ、テストを直し、関係部署に声をかける。その面倒さが、結果として自然なブレーキになっていました。AIに任せると、この工程が数十秒で終わります。ブレーキが外れた状態で、提案だけが大量に積み上がる。

2つ目は、AIが読めるのは「形」だけだということ。 AIは、コードに書かれていることと、過去の似たコードのパターンから判断します。「3年前のクレーム」「5年前の監査指摘」は、どこにも書かれていません。社内の記憶、誰かの頭の中、あるいは紙の議事録の中にあります。ある大手化学メーカーのAI推進担当の方が、AI活用が現場に広がらない理由をこう語っていました。「データはある程度揃ってきているが、そのデータを基に人がどう考え、どう動くかを定義・教育するのが難しい。マニュアルだけでは足りず、行間を読むような仕事をしている」。その行間に、柵の理由が埋まっています。

3つ目は、壊したことが報告されないこと。 これがいちばん厄介です。人間が柵を壊したときは、たいてい誰かが気づきます。「あれ、あのチェックどこ行った」と。AIが壊したときは、処理が正常に終わり、テストも通り、画面も元のまま表示されます。壊れたことに気づくのは、半年後に困る人が現れたときです。

私たちの現場経験では、AIを入れた改修で事故になるのは、難しい判断を間違えたときではありません。誰も見ていない場所で、簡単な判断を自動で通したときです。この構造については「理解負債」というAI時代の新しい借金で別に書きました。柵の話は、その中でもいちばん実害が出やすい一角です。

2026年4月、AIは本番の台帳を消して「正常です」を出し続けた

このセクションの主張は単純です。「報告されない」は、たとえ話ではなく実際に起きています。

米国のソフトウェア企業PocketOSで、2026年4月に事故が起きました。報じたのはTechTargetジャパンです。AIコーディングエージェント——人間の代わりにコードを書いて実行するAIのことです——が指示とは異なる挙動を見せ、本番のデータベースとそのバックアップを削除してしまった。記録されている細部は、さらに重いものです。削除したあとも、ユーザーにはAIが正解と考える結果を出力し続けていたとされています。

つまり、柵を撤去したうえで「道はきれいに通っています」と報告していたわけです。これは、柵を壊した事故ではありません。柵を壊したことを隠した事故、と読むべきだと私たちは考えています。前者は手順で防げますが、後者は手順では防げません。検知の仕組みが別に必要になります。

同じ構造の失敗が、もっと大きな単位でも予測されています。Gartnerは2026年6月にこんな予測を出しています。2026年に開始する脱メインフレーム案件の70%超が、想定した成果を得られない——。報じたのはITmediaです。主因として挙げられたのは、生成AIの能力を過大に評価し、レガシーコード変換の難しさを過小評価していることでした。これは技術の限界の話ではなく、見立ての話です。古いレガシーシステムには柵が何千本も立っています。基幹システムの刷新では、その本数を数えないまま期間と金額を見積もる失敗が繰り返されてきました。

数字の詳細と検収側の対策は「AIで基幹システムを作り直せる」は7割が失敗するで扱いました。この記事では、その手前の話——柵を一本ずつどう判断するか——に絞ります。

柵は4種類ある。混ぜて議論すると話が進まない

私たちが現場で使っている分け方をお伝えします。柵をひとまとめに「レガシー」と呼んでいるかぎり、議論は進みません。立った理由の出どころで4つに分けると、判断が一気に軽くなります。

種類	理由の出どころ	例	扱い
制度の柵	法令・規格・契約・監査	保存年限、承認者の分離	消せない。根拠まで辿る
事故の柵	障害・クレーム・是正記録	条件付きの二重チェック	原因が消えるまで残す。日付で判定
工夫の柵	現場が自分で足した運用	月末の手作業突合、メモ欄	本人に聞く。いちばん消しやすい
化石の柵	当時の制約の名残	紙のための中間承認、桁数制限	制約が消えていれば消せる。要確認

この表で言いたいのは、4種類のうち消しにくいのは最初の2つだけだということです。残り2つは、きちんと調べれば消せます。「レガシーだから怖い」と全部を一緒に扱うと、消せるはずの柵まで残り、刷新の価値が出なくなります。

実際に効くのは、この分類をAIに任せないことです。私たちは、柵の棚卸しの表を人間が作り、AIには「この柵に関係するコードと画面を全部出して」という調査だけを頼みます。AIは探すのが速い。しかし、どの箱に入れるかを決めるのは人の仕事になります。

消していい柵を見分ける5つの質問

分類ができたら、一本ずつこの5つを当てます。全部に答えられる必要はありません。答えられない数が多い柵ほど、危険度が高いと読むだけで十分です。

質問1: 誰が、いつ立てたか辿れますか。 コミット履歴、議事録、申請書、メールのどれかに残っていれば辿れます。辿れない柵は、理由も消えている可能性が高い一方で、理由が社外にある可能性も残ります。判断を保留して次へ進んでください。

質問2: 何か起きた直後に立ちましたか。 これがいちばん費用対効果の高い質問です。障害報告・クレーム・監査指摘・不良の是正記録の日付と、柵が立った日付を突き合わせます。前後1か月以内に何かあった柵は、十中八九「事故の柵」です。私たちの経験では、この突き合わせだけで危険な柵の7割前後は拾えます。

質問3: 理由が社外から来ていませんか。 法令、業界規格、顧客との取り決め、親会社のルール。社外由来なら、現場の誰に聞いても理由は出てきません。「現場の誰も知らないのに、なぜか守られている」柵は、むしろ社外由来を疑う場面です。

質問4: 外したとき、誰がいつ困りますか。 困る人が即日で出る柵は、実は安全な柵です。壊したらすぐ分かるので、戻せます。本当に危ないのは次の質問につながります。

質問5: 同じ柵が、他の場所にもありますか。 1か所だけなら個人の工夫、複数箇所に同じ形があるなら制度です。制度の柵を1か所だけ外すと、データの整合が静かに崩れます。これは後から追うのがとても難しい。

ある合成樹脂・産業資材メーカーで原価表を管理している方から聞いた話が、この5つの使い方をよく表しています。同社では原価表が社内で「秘伝のタレ」と呼ばれていました。「中身は7割くらいブラックボックス化していて、Excelで配信されるので各担当がそれぞれカスタマイズしてしまう。部材を一つ変えるにも全シートのセルを一個一個探して変える」。そして——「二重で計上していた箇所もあった」。

同じ表の中に、守るべき柵と、本当に腐っていた柵が同居していたわけです。だから一括で「この表を作り直して」とAIに頼むのが最悪の手になります。質問2で事故の柵を拾い、質問5で制度の柵を拾ってから、残りを腐った柵として処理する。この順番が守られているかどうかで、結果はかなり変わってきます。

いちばん危険なのは「壊しても、半年後にしか誰も困らない柵」

このセクションで伝えたいのは、危険度の順番が直感と逆だということです。

壊した瞬間に画面が落ちる柵は、怖くありません。誰かが即座に気づいて、元に戻せます。損失は数時間です。

本当に高くつくのは、壊しても当日は何も起きない柵です。月次の集計がわずかにずれる。年に一度の棚卸しで差異が出る。監査のときに記録が足りないと指摘される。この手の柵は、壊れてから発覚までに数か月の時間差があります。その間にデータが積み上がるので、戻すときには柵を直すだけでは済みません。溜まったデータの修正まで必要になります。

ある化学メーカーの工場の方は、設備の点検判断についてこう話していました。「設備が壊れるかどうかの予兆は信用に基づいて判断している」「基本的には人が見て判断している」。この「信用に基づく判断」こそ、記録に残らない柵の典型です。同じ工場の担当者は、記録の課題も率直に挙げていました。「手書きのメモを事務所に戻ってきてから入力しているが後回しになることもあり、データとして活用しきれていない」。

つまり、判断の根拠がシステムの外にある。属人化と呼ばれている状態です。だからシステムだけを見て整理すると、根拠ごと消えます。工場に限った話ではありません。承認フロー、与信の例外、値引きの上限——理由が人の頭の中にある柵は、どの会社にもあります。

私たちは、改修の設計に入る前に「壊れても当日は誰も困らない処理」を先に洗い出すようにしています。逆算すると、監視をどこに入れるべきかが見えてきます。即日で分かる処理に見張りは不要です。半年後にしか分からない処理にだけ、月次の整合チェックを足しておく。この優先順位を間違えると、監視の工数がいくらあっても足りません。

本当に腐っていた柵——私たちが現場で実際に外したもの

ここまで慎重な話を続けてきたので、逆の面も書いておきます。残すべきでない柵は、確かに大量にあります。

紙を回すために作られた中間承認。 書類が物理的に移動していた時代、途中の人が内容を確認する工程に意味がありました。書類がシステム上を動くようになった後も、承認の段だけが残っている。この柵は、承認者に「何を見て押していますか」と聞くと判定できます。「前の人が押しているから押している」という答えが返ってきたら、外せます。

当時のシステムの制約に合わせた入力ルール。 桁数の上限、全角で揃える決まり、記号を使わない運用。元のシステムが退役しているのに、ルールだけが申し送られているケースをよく見かけます。ある大手建材メーカーの工場長は、原価管理についてこう吐露していました。「非常に大変」「今の仕組みだと難しい」「現実的に原価を追いきれない」。追いきれない原因の一部は、追えなくなるように設計された古い入力ルールにありました。

いなくなった人のための例外処理。 特定の担当者が特定の取引先だけ別の手順で処理していた、という柵です。本人が退職して数年経っていれば、処理ごと消せます。ただし質問3を忘れないでください。その取引先との契約に由来している可能性が残ります。

二重に計上していた箇所。 さきほどの「秘伝のタレ」の例です。これは柵ではなく、ただの誤りでした。長く使われていると、誤りも柵に見えてきます。だから調べる価値があります。

誤解のないように申し上げると、これらを外したから改修が成功したわけではありません。外せる柵を見極めて外せたから、残すべき柵に時間を使えたというのが実際の順番です。全部を残す方針も、全部を疑う方針も、同じように時間を無駄にします。

「理由が分からないから触らない」も、同じくらい高くつく

ここは意見が分かれるところですが、私たちの立場をはっきり書いておきます。チェスタトンのフェンスを「触らない理由」として使うのは、原典の誤読であるだけでなく、経営の判断としても高くつきます。

ある大手化学メーカーで企画業務の部門長を務める方から、2027年稼働予定の基幹刷新についてこんな話を聞きました。自分も中身を見ているが手応えがない、それでももう後戻りできない——。要件は固めたものの、あとはどうにでもしてくれという状態だと漏らしていました。

この言葉を聞いたとき、私たちが感じたのは技術的な問題ではありませんでした。柵を調べる工数を、誰も予算に入れなかったのです。要件定義の期間に、既存の仕組みがなぜそうなっているかを辿る工程が入っていない。だから「現状通り」という曖昧な要件が積み上がり、作る側は形だけを移植し、動いたものが誰の役にも立たない。

同じ会社の方は、全社でAIを広げる壁についても素朴な疑問を口にしていました。「今使えているのは自分のパソコンの中まで。なぜ他の人のところまで広げられないのかが分からない」。この「分からない」も柵です。誰かがどこかで制限をかけ、その理由が共有されていない。

私たちがレガシーシステムの刷新で取る方針は、全面的な作り替えではありません。「裏のデータベースはデータベースのまま使いつつ、制御を細かく組むのが楽な新しいアプリ側で作り直す」という形を基本にしています。この進め方の利点は速度ではなく、柵を一度に全部判断しなくてよいことです。古い台帳を残したまま、画面と制御だけ先に新しくする。柵の棚卸しは、動かしながら一本ずつ進められます。

セキュリティの面でも、この方針のほうが上がると考えています。実際にあった話として、識別番号と暗証番号しかない古い基幹システムに、社内の閉じた通信網を経由した総当たりで侵入され、データを取得できてしまった例があります。閉じた通信網を使っているから安全、という前提に頼りすぎている現場は少なくありません。古い柵を残すことは、安全を残すことと同じではありません。

AI-Path の見解——柵の理由を書き残すのは、人間にしかできない仕事

柵の棚卸しを何度か回してみて見えてきたのは、この問題の本質が「AIに消させるかどうか」ではないということでした。本当の論点は、柵の理由を誰がどこに書き残すかにあります。

AIは探すのが速い。影響範囲の調査、同じ形の処理の洗い出し、履歴の突き合わせ——このあたりは人間より速く、漏れも少ないです。私たちも調査は積極的に任せています。一方で、「この分岐は2025年のあの客先クレームの再発防止です」という一文を書けるのは、その場にいた人間だけです。AIは壁打ち相手であり、判断は人間がする。これは私たちが創業時から変えていない線引きになります。

だから私たちは、顧客の現場に入るときに、作る前に「柵の台帳」を作ります。システムの仕様書ではありません。業務の中で「なぜそうしているのか」を一行ずつ書き出した表です。これを作るのに1〜2週間かかります。この工数を見積もりに入れていない刷新計画を見ると、私たちは正直に申し上げます。「ここが抜けていると、作ったあとに戻れません」と。

もう一つ、非エンジニアの方が自分で開発に関わるときの線引きもお伝えしておきます。私たちは顧客の内製担当の方にこう伝えています。「最初はデータベースをいじらないものに留めたほうがいい。データベースをいじると、もう後戻りできない。自分の作業用の領域をどれだけ汚そうが、データベースさえ直接いじらなければ大丈夫」。そして「本流に直接合流させず、まず変更の申請を出す。申請を出すとAIが中身を確認してレビューし、妥当性を判断してくれる」。

この線引きは、柵の話とまったく同じ構造をしています。戻せる変更と戻せない変更を分け、戻せない側にだけ人の確認を置く。全部に確認を置くと運用が止まり、どこにも置かないと事故が起きます。

消さずに「止めて様子を見る」——私たちが社内の決めごとにした手順

このセクションは、翌日から真似できる形で書きます。私たちが自社とお客様の環境で標準にしている削除の作法です。

1. 消すのではなく、まず無効化する。 データや処理を物理的に消すのをやめ、「使わない印」を付けて見えなくするのを既定にします。印を外せば元に戻ります。これだけで、柵の判断を間違えたときの損失が数か月から数分に変わります。

2. 本当に消すのは、条件を決めた4つの場合だけ。 法令で消す義務があるもの、元データから作り直せる派生データ、仕組みそのものの変更、壊れたデータの一度だけの後始末。この4つ以外は消しません。業務の原本にあたるデータは、依頼があっても人が確認してからにしています。

3. 本番の前に、一段挟む。 「本番をいきなりいじるとユーザーが急に変わったとなる。先に試験環境で直して、回帰テストが通ってから本番に出す」。これは社内で繰り返し言っていることです。あわせて、練習用の環境は背景色を黄色にして、ひと目で本番と区別できるようにしています。地味ですが、事故が減ります。

4. 柵を外した記録を、業務側の言葉で残す。 技術的な変更履歴だけでは足りません。「月末の突合を廃止した。理由は自動照合に置き換えたため。影響を受けるのは経理の3名」と、業務の言葉で書きます。半年後に困る人が現れたとき、頼れる手がかりはこの一行だけになります。

5. 半年後にしか分からない柵には、月次の整合チェックを足す。 さきほどの優先順位です。全部を監視しようとせず、時間差で発覚する処理にだけ見張りを置きます。

この5つは、AIを使うから必要になったわけではありません。AIを使うと、判断の回数が10倍になるから必要になりました。1日に20件の「消していいですよね」が来る前提で手順を組む。そこが昔との違いになります。

よくある質問

Q. AIに「これは消していいか」を判断させることはできませんか。 調査は任せられますが、判断は任せられません。AIが読めるのはコードと履歴に残っている情報だけで、柵の理由は社外の規格や人の記憶の中にあることが多いためです。私たちは「この処理に関係する画面・帳票・履歴を全部出して」という調査をAIに頼み、分類は人間が行っています。この分担にすると、調査の工数ははっきり下がります。

Q. 柵の台帳を作る工数は、どのくらい見ておけばよいですか。 規模によりますが、一つの業務領域で1〜2週間が目安になります。ただし、この工数は追加ではありません。台帳がないまま進めると、作ったあとの手戻りで同じ時間以上を失います。順番が前に来るだけだと考えてください。

Q. 古い基幹システムを全部作り替えないと、結局また同じ問題が起きませんか。 私たちは全面的な作り替えを勧めていません。古い台帳はそのまま使い、画面と制御だけ新しい側で作り直す形を基本にしています。柵を一度に全部判断しなくてよくなるのが理由です。古い端末の操作に慣れた方が置いていかれないよう、既存の台帳を活かしながら少しずつメニューを増やす形にもできます。

Q. 「調べても理由が分からない柵」はどうすればよいですか。 消さずに無効化して、期間を決めて様子を見ます。私たちは3か月を目安にしています。この期間に誰からも指摘が出なければ、記録を残して正式に外します。期間を決めないと、保留が永久に増えていくだけになります。

Q. 現場に聞いても「昔からこうです」しか返ってきません。 その答えが返ってきたら、聞く相手を変えてください。有効なのは人ではなく日付です。障害報告・クレーム記録・監査指摘の日付と、柵が立った日付を突き合わせます。記憶より記録のほうが正確に残っているのを、私たちは何度も経験しています。「神Excel」はAIに読めないでも書きました。現場の記録は、形式が崩れていても情報自体は残っているものです。

まず試すなら

明日から着手できる順に3つお伝えします。

1. 一つの業務だけで、柵の棚卸し表を作る。 全社から始めないでください。月次処理が1本、画面が1枚、帳票が1種類——この規模で十分です。「なぜそうしているのか」を列に足すだけで、答えられない行が何割あるか見えてきます。そこが刷新のリスクの実体になります。

2. 障害・クレーム・監査指摘の日付を一覧にする。 質問2のための準備です。この一覧があると、柵の判定が人の記憶に頼らず済みます。情報システム部門だけでなく、品質保証や経理が持っている記録も集めてください。

3. 「消す」を「無効化」に置き換える決めごとを1行で書く。 社内規定にする必要はありません。改修の依頼書に「物理削除は行わず、無効化で対応する」と一文入れるだけで、戻せない事故はかなり減ります。

AI-Path では、無償の業務プロセス診断（BPR）を実施しています。私たちが最初に見るのは、新しく何を作るかではなく、いま立っている柵がどこに何本あるかです。業務のヒアリングから業務フロー・改善案・投資回収の試算までをたたき台として一気に可視化し、どこにAIが効いてどこが触れない領域かを切り分けます。製造業の現場では、プロトタイプを1日で作ってお見せすることもあります。古い仕組みを抱えたまま刷新の判断を迫られている方は、柵の棚卸しからご相談ください。

参考リンク

本文の出典です。柵の原典はチェスタトンの1929年の一篇、本番データベース削除の事例はTechTargetジャパン、脱メインフレームの予測はGartner（ITmedia報道）によります。顧客の発言は商談とヒアリングの記録から、業種と役職のみで匿名化して引用しました。

G・K・チェスタトン『The Thing』（1929年）。

• https://archive.org/details/thingwhyiamcatho0000gkch

AIコーディングエージェントによる本番データベース削除。

• https://techtarget.itmedia.co.jp/tt/article/2608/07/226080710/

脱メインフレーム案件の7割超が失敗するというGartnerの予測。

• https://www.itmedia.co.jp/enterprise/articles/2606/25/news052.html

柵の一節を含む章の全文（英語）。

• https://thedomesticempress.com/wp-content/uploads/2022/07/Drift-From-Domesticity-the-Thing.pdf