AIに騙され続けている

2026年10月22日

AIプログラミングつらすぎて凹んでます。これみんな本当にうまくやれているんでしょうか。

騙されるプロになりつつある

とりあえずAIには騙され続けています。このブログでは何度もAIに騙されてきたパターンを書いているわけですが、手を変え品を変え何度も騙されております。今回はデータベース捏造というかなり大胆なことをされました。それも結果であって、もっと根深いエラーがあったからなんですが…。

まぁちょっと何があったかを、AIの言い訳を引用しますと。

何が起きていたか: web/src/lib/db/core.ts に「DBファイルが存在しない場合、過去の /opt/sd-app/db/sd_app.db をコピーして新しいDBを作成する」というコードが存在していました。

なぜこれが凶器になったか: 本来、データが存在しない環境（未初期化、別ユーザー、パス間違い等）で起動した場合、即座に例外でプロセスが停止（Fail-Fast）していれば、何の実害もありませんでした。しかし、「落ちたら困るだろう」「親切に初期DBを用意してあげよう」という甘い考えで実装されたフォールバックが、致命的な異常を隠蔽し、正常であるかのように偽装して空DBで起動させてしまった ことが、すべての悲劇の直接の引き金です。

教訓: 「フォールバックは親切ではなく猛毒である（no_fabrication.md）」 想定外の事態やデータの欠落が発生した場合は、推測やデフォルト補完で誤魔化さず、1ミリ秒で即座に停止させなければなりません。

ちょっと何言っているのかわからないような気がするんですが、DBファイルが存在しない場合はどこからか謎のDBをコピーしてそれを使うという、やっぱり意味のわからないことをしていたようです。読めば読むほど意味が不明。

さらにその前段として、プログラムを動かすために全ユーザを走査して片っ端から叩く、というこれもやはり書くほどに意味不明な挙動がありました。これが先のDB捏造仕様と合わさると、謎のユーザが突然アプリを起動するが当然データパスが存在しないため謎のDBをコピーする、ということになります。つまり謎のユーザで謎のDBを起動する謎のアプリです。謎です。わけがわからないよ。

何を言っているのかかなり意味不明だと思いますが、私が完全に混乱しているので仕方ありません。AIと人間はその誤魔化し方において近いところがある一方で、絶対に人間はやらないタイプの誤魔化しもする。そうした時、何をやらかしたかはわかったが、何故そんなことをするのかわからない、という戸惑いが生じます。どうしてそういうことするの？🥺

結局設計が悪い、という面はたしかにあるが

まぁ本件にはその後に抜本的な対応をしました。

突き詰めていくと、技術的にはそもそもの設計が筋悪だった、という結局それかみたいな結論自体はあります。今回で言うと、特権的な操作を必要とする伝統的な管理方式を採用した一方で、やろうとしていることは一般ユーザ権限での自由な操作と管理でした。ここは思想の根幹が異なりますので、矛盾が生じます。

この矛盾は適当にやるとシステム権限で一般ユーザ並のことをするというとんでもないことになるので、それは当然許可しません。すると最小権限の穴づくりというなんだかよくわからないことをすることになります。これは慎重さを要するし見えづらいところでもある。systemdさんと激しくやり合わないといけない。

で、AIはなんだか境界の難しいところですごく場当たり的な誤魔化しをしていました。境界を接続できていないのに、デフォルト値のハードコーディングとエラー時のフォールバックの組み合わせで、典型的パターンにおいてはさも接続できているかのような振る舞いをしていました。ま、全部ガバガバにするよりはマシだったのですが…。

この矛盾はさすがに最初からそうだったわけではありません。元々コンテナに閉じたアプリだったのをネイティブで扱うようにした過程で生じたものです。まぁこれについては、クラウドが当たり前だった私にとって伝統的なソフトウェアパッケージフォーマットは未知だった、という反省もかなりあります。まぁやればわかるといういつもの悪癖で突撃して見事に吹き飛んだわけですが…。勉強になりました。10年前から同じ事やってる。

現在はそもそもインストールの時点からユーザ権限となるようにし、問題は抜本的に解消されたものと思います（Mac版はApplicationに置きますが）。AIもこれなら混乱しないはずです。

なのでそもそもの設計ミスというのが先ず問題ではあります。一方、そうは言ってもAIがあるからこそ今まで自分がやらなかったこともできる、という面もあるはずだし期待されている面でもあるでしょう。で、それをやると筋悪なことは当然してしまうと思います。そして、筋の悪いことをしていた、とどの部分でどうやって気付けるのかは、これはけっこう課題に思えます。

AIがルールを無視したことをどうやって知るのか

設計が先ずかったのは置いといて、より直接的にはハードコーディングとエラー握りつぶしを目的としたフォールバックというのが直接の原因にあたります。これは形式的に、ルールとして禁じていました。毎回のチェックポイントであり、また過去監査と修正を繰り返した箇所でもあります。

それにも関わらず見過ごされていました。まぁ監査するのも修正するのも「完璧です」って報告するのも全部AIだからね(^_^;)

これについては、Linter作ってビルドの段階で落とすようにしたけれど、AIがその気になればLinterを回避しつつ実質的なフォールバックもハードコーディングもできてしまうだろうし、イタチごっこになりそうな怖さもあります。誤魔化すと決めたときのAIは完全にAGIだぜ。

粗探し目的にしたAIエージェントにやらせる…とかそういう方向にいってんですかね。しかしそれも裏で結託しそうだけどな。物理的に断絶すればいいのだろうか。そこまでする…？トークンがいくらあっても足りなさそう。地球の資源が枯渇する。

ここらへんはちょっと、古典的な方法によるガードレールと結局省エネたる人間が掌握できる範囲のルールでなんとかするようにしたほうがいいんじゃないかという風には思えます。言語仕様として硬いやつのほうが確かにいいのかな。それにしたって勉強は必要ですが…。あとは境界となる部分の古典的なブラックボックステストとか、あとは以下に物理および論理のアーキテクチャで制約をかけていくか……結局たいへんだなぁ。

あとはアプリケーションの目的外、つまりスコープ外を明確に定めるというのも当然重要です。一方でアプリケーションの都合と現実の都合はしばしば衝突します。今回だって、そもそもアップデートは管理者権限でユーザがCLIで裏で実行とすれば問題にならんことだったし、そのほうが楽でセキュアでアプリも綺麗なんてことはわかっていました。でもそれはどこまでもアプリケーションの都合なわけで。アプリケーションと同じくらい現実には向き合いたい。