AI愛子設計ログ11　キャッシュメモリ対応の難しさ

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

■少ないメモリでも最高のパフォーマンスを：キャッシュとの戦い

ソフトウェア開発において、メモリ管理ほど奥が深く、そして悩ましいテーマはありません。

特に、クラウド上で動作するAIやBotのような「軽さ」と「速さ」が命のシステムにおいては、メモリ効率こそが性能のすべてと言っても過言ではないでしょう。

■キャッシュは味方か、敵か

前回の報告の通り、Google Sheetsを活用したLINE Botの構築で、「キャッシュ」を全面採用する話を報告しました。

やはり返信速度の遅さと、常にスプレッドシートにアクセスするという構成は、リクエストのたびにGoogle Sheets APIへのアクセスを発生させ、処理を著しく遅くしていたのです。

■「全部キャッシュしてしまえ」の罠

そこで次に取った戦略は、すべてのデータを起動時にキャッシュしてしまうという手法でした。

Geminiによると、Cloud Run側のキャッシュ容量という概念はないらしいのですが、とにかく大量には置けますよ、とGemini自身がそういうので、全スプレッドシートの情報（それでも数キロバイト程度）をキャッシュ化すると、読み込みは爆速。Botの応答も一気に改善しました。

しかし、今後、もしこのサイズが数メガバイトを超えるようにでもなると、

「この情報は本当に必要か？」
「今この瞬間に読み出すべきか？」

という設計をしなければなりません。
本来であれば最小のメモリで、最大の性能を引き出すのが理想です。商用のソフトウエアではほぼほぼこれがソフト開発の肝といってもいいかも知れません。

しかし、これはなかなかAIでも出来兼ねる技。
ソフトエンジニアにとってはまさに腕の見せ処、飯のタネなのです。

そして、そういう設計を実現できたときのソフトウェアは、本当に美しく、気持ちよく動作するものです。

■まとめ

キャッシュは便利！しかし万能ではない
メモリの使い方を意識することは、システム全体の哲学に関わる
少ないメモリで大きなパフォーマンスを出す、これも職人の技なのですよね。