AI愛子設計ログ21　大幅メンテナンスの重要性

続きです。
※本記事は「技術解説編」です。先に公開したユーモア中心の「おちゃらけ版」とは若干時系列が異なるため、シリーズでお読みいただくと理解が深まるかと思います。

■コードが複雑化してきたときの保守性

前回、拡張性と保守性が次の最大の課題になったという話でした。ちょっとした改良を加えようかと思ったら全体がクラッシュし、もう何をしているのか分からなくなる状態に。
まさにソフトウエアあるあるです。

■AIに命名を任せすぎはヤバイ

愛子Botの設計・開発も2か月がそろそろ終了。
プログラムは肥大化し、関数名を考えるのも、AIに「この処理の名前考えて」と聞けば、それっぽい名前を返してくれ、それで進めていました。
ところが、この“ちょっとしたAI頼り”が、まさか深い落とし穴にはまることになろうとは…

■関数名を直すだけ、が

ある日、とある関数名write_employee_data() に各種作業を取り込むことにしました。すると正確には社員データを保存しているだけではなくなったので、分かりやすいように、handle_employee_info() と修正を試みました。

ちょっとした整理整頓のつもりでした。
当然AIに聞けば、

「handle_employee_info()の方がより意味が明確ですね！」
と返してくれます。

よし、じゃあ置換。と

■ここからが地獄の入口

関数名を置換しただけなのに、なぜか変更が反映されない。
テストをしても動きが全く更新されません。でも grep しても出てこない。AIにも聞いてみるが「見つかりませんね」と言われる始末。
コードを見返しても違いが分からない。
ほぼ、一日使ってやっと分かりました。
同じhandle_employee_info()という名前の関数をAIが別の目的で作っていたのです。
もちろん、AIのせいではなく人間側が見ていなくて丸投げしていた結果の問題です。
さらに困ったのは、同じような処理をする関数が、名前違いで複数存在していたこと。

write_employee_data()
save_employee_info()
upload_employee_record()

どれも「社員情報を何かに読み書きしている」ような処理。でも中身が少しずつ違う。「どれが本物か」さっぱり分かりません。
不具合が出て直したつもりでも全く直りません。

■永遠と直しても「反映されない」現象の真相

AIもどのファイルが正解かは分かりません。AIも必死になって可能性のありそうな不具合の対策を次々と提案してくれます。
でも本番で動いていたのは、別のファイルだということに気が付くのに相当時間を費やしてしまいました。コードも書き換えること何度か。もはや正常に動いていたコードがどんなのだか分からなくなる始末。

■「AI任せ」の限界

この事件を通じて学んだのは、関数名をAIに任せると、自分が意味を理解しないままコードが増殖するということ。
命名は自分で考える AIの提案は参考まで。意味と責任を理解してから命名確定しなければならない。
重複命名チェック grep def 関数名、pyright で定義の重複を確認
ファイルごとの責任明確化 「保存系」「読み取り系」「キャッシュ系」でディレクトリを分離する
import整理 from x import y形式に統一。AIの生成コードも手動で整理

AIは本当に便利で、開発効率を爆上げしてくれます。でもその便利さに甘えて「意味を考えずに使ってしまう」と、すっちゃかめっちゃかになります。

整理整頓はソフトウエア上でも大事です。自分でやりましょう。