入力画面が重くなりにくい
作業名候補を出すためだけに過去の作業履歴全体を読みに行く構成を避け、日々の記録画面で必要な情報だけを取得しやすくしました。
Release Notes
らくログタスク β0.5.8 更新内容
2026年5月27日に、らくログタスク β0.5.8 を更新しました。 今回の中心は、作業履歴が増えても入力画面と特定作業集計の作業名候補を軽く表示できるようにする改善です。 過去履歴全体を毎回読むのではなく、作業名だけをまとめた軽量な候補キャッシュを参照する構成にしました。
確認時点の履歴
19,216件
work_history に蓄積されていた作業履歴数です。
候補キャッシュ
949件
task_name_suggestions に作成された作業名候補数です。
改善対象
2画面
入力画面と特定作業集計画面の候補取得を見直しました。
今回の更新テーマ
作業ログアプリは、使い続けるほど履歴が増えていきます。 履歴が少ないうちは候補表示のために過去履歴を参照しても問題になりにくいですが、数万件規模になると入力画面の初期表示や再取得の負担になります。 β0.5.8では、日々の入力に必要な候補だけを軽く扱えるように、作業名候補専用のキャッシュを追加しました。
作業名候補を軽く表示できる
新規作業名の候補表示では、履歴全体ではなく軽量な候補テーブルを参照します。長く使い続けても候補表示の負荷が増えにくくなります。
特定作業集計の選択も軽量化
特定作業集計タブで対象作業名を選ぶ場面でも、作業名候補キャッシュを使うようにしました。集計前の作業名選択を軽くするための改善です。
追加・改善した機能
01
task_name_suggestions テーブルを追加
作業名、最終利用日時、利用回数などを保持する候補専用テーブルを追加しました。元データは work_history と task_master のままにし、表示高速化用の派生キャッシュとして扱います。
02
入力画面の全履歴スキャンを廃止
入力画面では、今日の勤務情報、今日の作業履歴、作業マスタ、最近使った作業名、作業名候補だけを中心に取得する構成へ整理しました。
03
新規作業開始時に候補キャッシュを更新
作業を開始したときに touch_task_name_suggestion RPC を呼び出し、候補の追加、最終利用日時の更新、利用回数の加算を行います。
04
特定作業集計の作業名一覧も軽量化
対象作業名を選ぶだけの段階では work_history 全件を読み込まず、task_name_suggestions を使って候補を表示します。
05
SQL未適用環境へのフォールバック
候補テーブルが未作成の環境でも、作業マスタや直近履歴を使って最低限の候補表示ができるようにしています。
技術的な裏側
追加したSQLでは、作業名候補専用の task_name_suggestions テーブル、インデックス、RLSポリシー、候補を更新するRPCを作成します。 既存の work_history から候補を作るバックフィルも含めています。
supabase/migrations/20260527_task_name_suggestions.sql SELECT COUNT(*) FROM task_name_suggestions; -- 949
入力画面と特定作業集計画面では、共通処理 lib/task-suggestions.ts を通して候補を取得します。 作業マスタ、候補キャッシュ、直近履歴などをマージし、重複や空文字を除外することで、画面ごとに同じ候補生成ロジックを使えるようにしました。
今回あえて行っていないこと
work_historyの既存カラム構造は変更していません。- 作業開始・作業切替処理全体のRPC化は、次の改善候補として残しています。
- 月別集計や全期間集計の結果キャッシュ化は、今回の対象外です。
関連する実装ノウハウ
今回の更新に近い、Supabaseのデータ取得、候補UI、公開アプリ運用まわりの実装ノウハウです。