【警告】AIは「動くゴミ」を量産するのか？〜「9時間を足せばいい」が招くシステム崩壊の罠〜
「AIにコードを書かせたら、一発で動いた！すごい！」
最近、そんな歓喜の声をSNSでよく見かけます。ノーコード・ローコード開発のブームは、私たちに魔法の杖を与えてくれたように見えます。
でも、ちょっと待ってください。その「動いたコード」、本当に大丈夫ですか？先日、私がGoogle Apps Script（GAS）の開発で直面したのは、「一見動いているけれど、裏側でシステムが腐り始めている」という、背筋が凍るような事態でした。
今日は、AIを相棒にするすべての人が知っておくべき「システム思考なきAI開発」の恐怖について、自戒を込めて共有します。
🤖 AIの甘い囁き「9時間を足せば解決ですよ」
ことの発端は、スプレッドシート上のタイムスタンプ処理でした。
世界標準時（UTC）で記録されたデータを、日本時間（JST）で表示したい。よくある要件です。
AIに修正を依頼すると、彼は自信満々にこう提案してきました。
「簡単です。取得した時間に 9時間を足して 保存しましょう」コードを実行すると、確かに時刻は日本時間になりました。「解決！ありがとう！」……と言いたくなりますよね？
しかし、これはシステム開発における「自殺行為」です。
なぜなら、これは「表示をJSTにする」のではなく、「データの真実（UTC）を改ざんして、JSTに見せかけている」だけだからです。
もし将来、このデータを別のシステム（例えば海外のAPIや、BIツール）と連携させたらどうなるでしょう？ システムはそれが「UTCから9時間ズラされた偽データ」だとは知りません。結果、すべての時間計算が狂い、原因不明のバグが連鎖的に発生します。
AIは「今の表示を直したい」という点（ポイント）の課題は解決してくれます。しかし、タイムゾーンという複雑な系（システム）全体の整合性までは、考慮してくれないのです。
☢️ GASプロジェクトで起きた「見えない環境汚染」
さらに恐ろしいのが、GAS特有の「実行環境」の問題です。
AIにエラー修正を繰り返させていたとき、不可解な現象が起きました。コードは正しいはずなのに、なぜか古い処理が走り続けるのです。
原因は、「トリガーのゾンビ化」と「グローバル変数の汚染」でした。
AIはコード（テキスト）を書き換えることはできます。
しかし、GASのサーバー側に保存された「トリガー設定」や「プロパティストア」の状態までは見えていません。
AIの言う通りに修正を繰り返した結果、私のプロジェクト内には「使われていない古いトリガー」や「矛盾した設定値」がゴミのように蓄積していました。
これはまるで、コードとデータの放射能汚染です。
表面上のコードだけをきれいにしても、土壌（実行環境）が汚染されているため、何を作ってもバグという作物が育ってしまう。
「動いたかどうか」だけで判断する開発は、この「見えない負債」を指数関数的に積み上げていきます。
💡 AIを「魔法の杖」ではなく「加速装置」にするために
AIは優秀ですが、決して「設計者」ではありません。
彼らは確率的に「それっぽい答え」を出しているに過ぎないのです。
だからこそ、私たち人間には「システム思考」が不可欠です。
対症療法を疑う：「その修正は、他の機能に影響しないか？」
構造（システム）を教える：「9時間を足すな、タイムゾーン変換のライブラリを使え」と指示する。
デバッグよりリフレクション：エラーが出た時、単に直させるのではなく「なぜその構造にしたのか？」を問い、AIの思考のクセを修正する。
「AIを使えば、何も知らなくても開発できる」
それは半分正解で、半分は危険な嘘です。
AIという強力なエンジンを積むなら、人間がしっかりハンドル（構造理解）を握らないと、猛スピードで崖から落ちることになります。
あなたのそのコード、時限爆弾になっていませんか？
一度立ち止まって、「システム全体」を見渡してみてください。
