見た目だけ誤魔化すAIにどう対応すべきか

Antigravityで自分向けのアプリケーションを開発している。もうかれこれ10以上やっている。その中には、以前自分で書いたものをAIにリメイクさせたものなどもある。

目次

自分、手抜きですから…

自分用のアプリであるため、ところどころ手抜きだ。たとえば、データベース設計で手抜きをする。AIイラストのプロンプトを生成するWebアプリがあって、プロンプトの順番をorderとして保存しているのだけれど、order=100をNegative Promptということにしている、など。

本来はNegative Promptとして独立したカラムを持つべきなのだが、いわゆる歴史的経緯というやつで、なんかそういう場当たり的なことをしてしまった。そして開発を続けるうちにorder=100を前提とした依存性が高まって変えられなくなるいつものアレ。

AIに修正させたところ

しかしAIならば面倒臭いところも厭わずにやってくれる。ちゃんとしようと思って、AIにNegative Promptとして独立したカラムをもたせて処理するように指示した。そうすると、スキーマを変えてmigrateのスクリプトも作って、実行してみるとちゃんと動いているように見えた。ので、そのときはできた、と思っていたのだが…。

後日、いじっていると一部挙動不審なところがあり、調べさせると

AI「古いデータは昔のスキーマの仕様になっちゃってるからですねハハッ。古いデータの仕様っぽかったらよしなにするよう関数書き換えました。ミッションコンプリート」

などと意味不明な供述をし…。

「え、古いデータについてはマイグレーションしてなかったってこと?画面上できているように見えるけれど、それは見せかけで、データベース上は古いままってこと?」
AI「そっすね。あ、だめな感じすか?ですね、はい、絆創膏貼ったようなもんですよね。おkおk、なおしまーす」

あのマイグレーションスクリプトはなんだったのか。まぁちゃんと確認しなかったのが悪いと言われると完全にそのとおりなんだけどさ。しかしAIの手抜きは許しがたい。手抜きしていいのは俺だけだ!

吠えたところで動かないのは困るので、その後改めて移行し、自分でデータベースを確認するなどした。

移行したことは確認したできたが、結局そこは不具合の原因ではなく、改めて調査に時間がかかったのは別の話。

データベースは自分で見る

とりあえず今回の反省として、やはりデータベースは自分で見る必要があると強く思った。特にマイグレーションなどがあると、想定と異なる挙動をしていることがある。テーブル設計も面倒くさがらずにちゃんとみないとあかんね。それで「DB Browser for SQLite」をインストールした。

データベースを実際みてみると、フロントエンドでやったように見せかけてるけどデータベースに反映されてないとか、冗長なフィールドがあるとか、色々あったな。

AIのしれサボり問題

AIコーディングは本格化していくのは確定的、というか既に相当使われており、業務委託などを全部切って代わりにClaude Codeに課金している現場はリアルに多いだろう。いくらAIが高いといっても、人間よりは安いからねぇ。

なのでこれからソフトウェアエンジニアは同じソフトウェアエンジニアによって駆逐されていくわけだが、しかし実際に稼働していれば、AIの嘘つき問題はけっこう深刻だとわかる。AIが手抜きするのは人間臭いといえばそうかもしれないんだが、なんというか、そこはちゃんとやれ!っていうところでも構わず手抜きするのが深刻に困るし、根本的な知性のなさを感じる。

なので確認する作業が必要なのだが、これはやはり専門的な知識が必要だ。

AIプログラミングになるとどうしてもブラックボックステストが必要だと思うが、そうすると今後はそういうテスター的な枠で生き残ったりするんだろうか。あまり給与は高くならなさそうだが。どうせ信用されず、ガチガチの仕様書渡されて確認するだけのつまらない仕事なんだろうな。昔工場にいたとき、ハードウェアの品質管理部門がそんな感じだったな。ベテランの爺さんの話によれば、昔はもっと裁量があって、設計とも喧嘩できたらしいんだが…。

ガチガチの仕様書は作るほうもつまらないし、それらしいだけで肝心なことは何も確認できないのが常だ。AI監督みたいな仕事ができるにしても、今度はちゃんと人間を信用する体制にしないと、どこまでも不幸になっていくだけじゃないかと思うが、果たしてどうなるかね…。

この記事をいいなと思っていただけた方、よければ高評価・チャンネル登録……はないので、コメント・SNSでシェア・ブックマーク、RSSフィード登録を、よろしくお願い致します。

コメント

コメントする

目次