ユーザーのデバイスにゴミを残したくなかった ― AIがlocalStorageを提案してきた話
先日リリースした業務効率AI診断を実装していたとき、ちょっと引っかかった出来事がありました。
回答の保持方法について、AIが提案してきたコードが localStorage を使っていたんです。普通に動くし、Web開発のベストプラクティスとしては妥当な選択です。でも、受け入れませんでした。最終的に sessionStorage に書き換えています。
この記事は、その1行の判断の話です。同時に、AIにコードを書かせる機会が増えた今、人間がどこで線を引くべきかについて、自分の考えを残しておきます。
引っかかった1行のコード
業務効率AI診断は、14〜17問の選択式に答えると、AIが業務効率の現状と課題を分析して表示するツールです。回答内容を画面遷移をまたいで保持する必要があるので、ブラウザ側のストレージを使います。
AIが書いてきたのは、おおむねこういうコードでした。
localStorage.setItem('diagnosis-answers', JSON.stringify(answers));ブラウザのWebストレージにJSONで回答を保存するだけのコードです。リロードしても回答が消えないし、ユーザーが途中で離脱して後から戻ってきても続きから答えられる。一見、親切な実装です。
実際、AIの選択は「Web開発の一般的なベストプラクティス」としては正しいです。フォーム回答を保持する典型例として、ドキュメントやチュートリアルでも localStorage がよく出てきます。
でも、このコードは取り込みませんでした。
何が引っかかったのか
理由はシンプルです。ユーザーのデバイスにゴミを残したくなかったから。
localStorage は、明示的に削除するか、ユーザーが手動でブラウザのデータを消さない限り、ずっと端末に残り続けます。タブを閉じても、ブラウザを閉じても、PCを再起動しても残ります。
業務効率AI診断のユーザー像を改めて考えてみました。
- 想定ユーザーは経営者、業務責任者、情シス担当
- 利用シーンは社内PC、出先のカフェ、共用PCもあり得る
- 扱う内容は自社の業務体制、Excel依存度、属人化の度合いといった、他人に見られたくない情報
- 利用頻度は「1回診断したら終わり」が基本。再訪して続きから書きたい需要は薄い
この要件で
localStorageを使うと何が起きるか。診断を終えた後も、その人の会社の業務課題に関する回答が、端末のブラウザに残り続けます。共用PCなら、次に使う人がDevToolsを開けば普通に読めます。
これは技術的なセキュリティの話というより、ユーザーに対する態度の話です。自分が使い終わったツールが、自分の知らないところで端末に痕跡を残し続ける。それを「クリアの責任はユーザー側にある」で済ませるのは、設計として誠実じゃないと感じました。
なぜAIは localStorage を選ぶのか
AIの提案が悪かったわけではありません。AIは学習データから「最もよくある正解」を出してきます。Webフォームで回答を保持するパターンとして、localStorage を使う例は世の中に大量にあります。リロード耐性も高い。AIにとっては自然な選択です。
ただ、AIが見ていないものがあります。
- このプロダクトが誰のために作られているか
- その人たちがどんな環境で使うか
- 扱うデータの機微性はどの程度か
- そもそも長期保持が必要な機能か これらは要件の重み付けの問題で、コードからは読み取れません。プロダクトオーナーの判断が必要な領域です。
AIは「動くコード」を書きます。「このユーザーにとって正しいコード」かどうかは判断していません。
sessionStorage に書き換えた
最終的に採用したのはこっちです。
sessionStorage.setItem('diagnosis-answers', JSON.stringify(answers));違いは1単語ですが、挙動は大きく違います。
sessionStorage は、タブを閉じた瞬間にデータが消えます。ブラウザ全体ではなく、そのタブだけのスコープです。ユーザーが「終わった」と思ってタブを閉じれば、回答も一緒に消える。クリアの責任が、利用者からシステム側に移ります。
トレードオフはあります。ユーザーが誤ってタブを閉じたら回答は戻りません。途中離脱して後で続きを、というユースケースは捨てることになる。でも診断ツールの性格上、3分で終わる前提なので、許容できる範囲だと判断しました。
これは「セキュリティを上げた」というより「ゴミを残さないようにした」が正しい表現です。同一オリジン内のJSから見えるかどうかという点では、localStorage も sessionStorage も変わりません。違うのは保持期間とスコープです。だから「セキュア度が上がった」と言うと厳密には不正確で、本質はデータの残存リスクを最小化したという設計判断です。
業務効率AI診断のリリース記事で「回答内容はブラウザのタブ内のみに保持され、タブを閉じた時点で消去されます」と書いているのは、このコード変更の結果です。
AIコーディング時代に、人間は何をするのか
ここから先は、もう少し広い話です。
2026年現在、AIにコードを書かせるエンジニアは爆発的に増えました。私自身、業務でAIをガッツリ使う側です。提案されたコードをそのまま採用することもよくあります。
その上で、AIに任せきれない領域があると感じています。
AIは一般解を出す。要件への適合は人間が判断する。
これが本記事を書く一番の動機です。AIは賢いし、生産性は確実に上がります。ただ、AIの提案は「学習データの中央値」であって、「目の前のプロダクトの正解」ではありません。
業務効率AI診断の localStorage 問題でいうと、AIは間違っていません。一般的なWebアプリのフォーム保存として、最適に近い選択をしています。問題があったとすれば、AIが見ていない要件 ―― ユーザー像、利用環境、データの機微性、再訪頻度 ―― を踏まえて、提案を自分の要件に翻訳する作業が必要だった、ということです。
この翻訳作業は、コードを書くことより、要件を見抜くことに近い。AIに任せきりにすると、ここがすっぽり抜けます。動くものはできますが、誰のためのコードなのかが曖昧になる。
「AIで作れる時代」と「AIに任せていい時代」は別物だと、最近よく考えます。
1行の判断が、長く残る
業務システムは長期運用が前提です。当社のサイトのキャッチコピーが「長期運用を前提としたシステム」なのも、これが受託開発の本質だと考えているからです。
1行のコードの判断が、何年もユーザーに残り続けます。localStorage か sessionStorage か、たった1単語の違いですが、診断を受けた何百人、何千人の端末に、その判断が反映されます。
「動けばいい」で済ませない設計が、長く使われるシステムを作る。AIが書いたコードでも、その判断は人間がやる。これは、AIに置き換わらない仕事だと思っています。
業務効率AI診断は無料・登録不要でご利用いただけます。今回のような設計判断を積み重ねた成果物として、よければ試してみてください。
業務システム・AI活用・Webサービスの開発から保守まで、長期運用を前提とした設計でご支援しています。お問い合わせフォーム、またはLINE公式アカウントからお気軽にどうぞ。
