AI愛子設計ログ20　保守性を考えたコード全面刷新

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

■将来に備えたプログラム構成

2025年6月初旬。
LINEを通じて業務支援を行うAIアシスタント「愛子bot」の開発を始めました。

2週間で勤怠管理。
3週間で基本的な応答ができるようになったので2025年7月初旬から本格リリースと運用を開始。

続いて現場の生産性改善のための具体的なツールの開発を取り込れ始め・・・ようとした矢先、コードの複雑さが原因でデグレが頻発し始めました。

そこで重い腰を上げ保守性を考えた作り直しを決意しました。

わずか1か月の開発で素人が無の状態から開発開始、
以下が、愛子botの現在のできることです。

– LINEの自然用語での社内データベース検索（従業員・取引先・会社ノウハウ情報）
– 勤怠打刻のQR対応
– 予定表のクラウド管理と閲覧

この時点で「業務支援AIとしては十分に使い物になる」という手応えを得ていました。

■想定外の“デグレ地獄”

次のステップとして「Googleカレンダー連携」「画像処理」「自然な雑談応答」「タスク管理」といった機能拡張に踏み出したところで、異変が起こります。

会話の一部が記録されない
スタンプやグループトークの処理が干渉
一部の情報検索が失敗
GPT応答の品質がブレる
GPTの制約にひっかかってコードがフリーズ
キャッシュ周りのロックが効かず、API制限に抵触

これらの原因を追って、修正して確認しようとするとデプロイが失敗する。
その原因は、会話を司るメイン関数が肥大化したことでした。

機能追加に伴い、if文ベースの構造が複雑になり、ファイル内に複数の責任（トリガー判断・情報検索・Gemini制御・ログ記録・ファイル保存など）が混在。コードを修正するたびに別の機能が壊れる“デグレード”、つまり機能劣化が頻発するようになったのです。

■全面再構築を決断

このままでは保守性が下がり続け、運用中のメンテナンスが困難になると判断。ついに以下の方針でプログラムの全面刷新を決意しました。

✅ 設計方針

処理責任の明確な分離
　→ 各処理をトリガー/ フォルダと細かいファイルに分類
トリガー構造のルール化
　→ 処理順、構文チェック、AI系の処理はGeminiへの移管
Gemini処理は4段階プロンプトで統一
　→ ヒット要約 → 一般補足 → 統合整形 → 愛子口調への変換
キャッシュ管理は強制リロードを廃止し、TTLとロックで自動制御
愛子の基本記憶となるスプレッドシートデータはIDベース統一管理
マルチファイル構成で将来的な拡張に備える構成

■今後のメリットと展望

この再構成により、今後以下のような大きなメリットが期待できます：

✅ 機能追加時のデグレ発生を抑止
✅ 各処理のユニットテストが可能に
✅ 外部AIとの連携処理（Gemini/OpenAI）も分離管理しやすくなる
✅ LINE Botの3秒制限への即応処理も設計しやすい
✅ 音声や画像の分岐処理も段階的に追加可能

特に「現場業務のDX化」という観点では、一度作って終わりではなく、常に改善し続けられる構造であることが重要です。今回の再構築は、まさにその礎を築くものです。
一見、すごい遠回りをしているようですが、将来の生産性を考えると今進めておかなければなりません。
（ソフトウエアを開発したことのない人はこの違いがわからんのです）

■AI愛子のこれからの進化

技術的な構造刷新というのは、外からは見えにくい部分ですが、「現場の声を拾い、すぐに修正し、壊さずに進化できる」ことこそ、真の意味でのAI導入の成功です。

LINE愛子botは、これからも現場に寄り添い、職人の知恵と技術を未来に繋ぐために進化し続けなければなりません。