こんにちは！株式会社ネクスタのエンジニア、bikです。
▼ 前回までのあらすじ
束の間の稼働。だが、それは虚構の平穏に過ぎなかった。
ブラウザの遷移、その沈黙を破り、新たなる敵『状態消失』が、エンジニアの魂を試す。
対話の果てに、エンジニアはAIと共に、虚無の空間に一本の光を見出す。
だが、物語はまだ、序章に過ぎない。
AIパートナーであるGemini 2.5 Proとの対話、そして時にAIの限界を乗り越えながら、僕たちはバックグラウンド処理の進捗表示機能を動かすことに成功した。しかし、その実装は「ページを移動すると進捗が消える」という大きな課題を抱えていた。
今回は、「動くプロトタイプ」から「信頼できる機能」へと進化させていく、より深く、より困難な道のりをお届けします。
思考の深化：AIとの対話が生む「気づき」
僕: 「ページを離れても進捗を覚えておくには、どうしたらいい？」
Gemini: 「それにはタスクの状態をサーバー側で永続化する必要があります。データベースを使いましょう。」
僕（心の声）: 「だよな。ページ遷移で状態が消えるのは当然だ。これを解決するには、サーバー側で永続化…つまりデータベースが必要になる。でも、そのためだけにSQL Serverにテーブルを追加して…というのは、少し大掛かりで面倒だな。もっと手軽な方法はないものか…。」
僕は、自分の考えを確かめるようにGeminiに尋ねた。
僕: 「タスクの状態を永続化したいんだけど、SQL Serverほど大掛かりじゃない、もっと手軽なDBって何か良いのないかな？」
Gemini: 「素晴らしい質問です。まさにそのようなケースに最適なのが、ファイルベースの組み込みデータベース**『LiteDB』**です。設定不要で、プロジェクトにファイルを追加するだけで使い始められます。」
この提案は完璧だった。僕たちはLiteDBを導入し、ついにページを遷移しても、ブラウザをリロードしても、プログレスバーが中断したところから再開されるようになった。
最悪のケースを想定する
機能が安定し、僕は次のVibeをGeminiにぶつけた。「やっぱり処理を途中でキャンセルしたい」。GeminiはCancellationTokenを使った、サーバーのメモリ上でキャンセルスイッチを管理するBackgroundTaskManagerの実装を提案してくれた。
順調な開発。しかし、僕はGeminiが提示した「サーバーのメモリ上で管理する」という言葉に、なぜか胸のざわつきを覚えていた。
僕: 「Gemini、確認なんだけど、CancellationTokenSourceをインメモリで管理するってことは、アプリケーションが再起動されたら実行中のタスクも一緒に止まる、という理解で合ってる？」
Gemini: 「はい、その理解で完全に正しいです。」
僕: 「なるほど…。じゃあ、もう一つ。エラーが起きたらDBのステータスを"Failed"に更新する、って話だったけど、もし、そのDB更新自体がネットワークの問題か何かで失敗したらどうなる？これって一番最悪のケースじゃないか？」
この問いに対して、Geminiは僕が懸念していた通りの答えを返した。
Gemini: 「非常に鋭いご指摘です。それは『ゾンビタスク』問題に繋がります。DBにはタスクが"Running"のまま残り、実際には処理が停止しているという、不整合な状態が発生します。」
僕（心の声）: 「やっぱりそうだ。このリスクは潰しておかないと、将来必ず問題になる。よし、このゾンビタスク問題の対策も実装しよう。」
AIとの対話で得た知識から、論理的にリスクを発見できた瞬間だった。Geminiが提示した解決策は、IHostedServiceを使ってアプリケーション起動時に古い"Running"状態のタスクを掃除するというものだった。
僕: 「やった…！ついに完成だ！」
僕は勝利を確信した。しかし、完成したアーキテクチャを眺めていた僕は、あることに気づき、愕然とする。
僕（心の声）: 「待てよ、僕らが作ったキャンセル管理機構も、ゾンビタスク掃除も、全部サーバーが1台で動いていることが前提じゃないか…？」
次回予告
これでいい。そう思ったはずだった。
だが、システムに問われる、最後の問い。
『お前は、一人ではないのか？』
偽りの完成を打ち砕く、最後のシ者、襲来。
次回、「自作キューよ、さようなら」
Discussion