【訪問介護・障害福祉サービス】Google Apps Script 訪問記録アプリのデバッグ

バイブコーディングで現場で実際に使えるアプリを数時間で開発することが可能になった今、プロトタイプのアプリを作ることよりも実際に使ってみて、不具合や改良点、バグを見つけて修正する作業の方が圧倒的に時間がかかります。AIエージェントが発達すれば、友達に話しかけるようにできるようになるのかもしれませんが、現状ではデバッグ~プログラムやコードに含まれるエラーやバグを特定しそれを修正する作業~が実際の運用前に必要不可欠です。

これまで本ブログでも紹介してきた内製『訪問記録アプリ』について、今回は、AIにデバッグの協力をお願いした内容を記事にしてみました。


サイト管理人
サイト管理人

アップロードしたファイルは、GoogleスプレッドシートのGoogle Apps ScriptのWebアプリのファイルです。このアプリは、訪問系障害福祉サービスの訪問記録のアプリです。このファイルについて、以下の項目を修正して各ファイルを書き直してください。指示した箇所以外は絶対に改変しないでください。
①現状では、「保存して終了」ボタンを押さないとサービス開始時間が記録されないため、「開始打刻」ボタンを押すとサービス開始時間がスプレッドシートに送信され記録されるようにする。
②各日のシフトについて、スプレッドシートの順で遅い支援時間のシフトが早い時間のシフトより上に表示されてしまうが、当該日について、たとえスプレッドシートのShiftの時刻の順序が違っていても、時系列に表示されるようにする。
③各利用者の記録画面について、一番上に当該シフトの一つ前に入った支援の記録が、「前回サービス提供時の記録」として「指示に対する報告」と「特記事項・申し送り」が表示されるようにしているが、当該シフトの一つ前の記録ではなく、最後に入力された記録になっている。つまり、1月1日の記録画面の「前回サービス提供時の記録」は12月31日の記録が表示されるのではなく、1月10日に入力した記録が更新されて表示されてしまう。後から過去の記録を読み返しても、必ず当該シフトの一つ前の記録が「前回サービス提供時の記録」として確定して表示されるようにする。
④記録をいったん入力して「保存して終了」ボタンを押すとスプレッドシートに転記されますが、行動援護など、支援中に記録を書いていったん保存して、支援が終了した時点で改めて書き直してから「保存して終了」ボタンを押すことも多々あるので、「保存して終了」ボタンを押した時刻がサービス終了時間として記録される仕組みは良いと思うが、翌日に再び書き直した場合、何らかのエラーが生じないか、コード全体を見渡して何らかの課題があれば教えてください。この項目については、内容を確認してから指示を出しますので、コードの修正はしないでください。④について、問題点や課題だけを教えてください。
⑤他に何か、問題点や課題などがある場合はレビューして教えてください。こちらから改めて指示しますので、⑤について、許可するまでコードの修正はしないでください。①②③はコードの修正をを願いします。


ルルーシュ
ルルーシュ

ご提示いただいた要件に基づき、Index.htmlとCode.gsを修正しました。また、後半に④と⑤のご質問に対する回答(分析レポート)を記載します。

  1. 開始打刻の即時送信 (Index.html / Code.gs): stampStart関数でsaveStartRecord(新規追加)を呼び出し、ボタン押下時にスプレッドシートに記録を作成(または更新)するようにしました。
  2. シフトの時系列表示 (Code.gs): getShiftsByDay関数内で、取得したシフト配列をstart時刻でソートしてから返すように変更しました。
  3. 前回記録のロジック修正 (Code.gs): getReportDetails関数内で、単純に「最後に書かれた日誌」ではなく、「対象シフトの日時より過去にある、最も新しい日誌」を日時比較で特定するようにロジックを全面的に書き換えました。

Index.html


Code.gs


現状の課題:

現在、submitReport関数では、保存処理が実行された瞬間の日時(const now = new Date())を「サービス終了時間」(スプレッドシートの14列目)として上書き保存しています。

翌日に書き直した場合の挙動:

  1. 終了時間のズレ: 支援当日に一度保存し(例:1月1日 18:00)、翌日(1月2日 09:00)に修正して再度「保存して終了」を押すと、サービス終了時間が「1月2日 09:00」に上書きされてしまいます。 これにより、実績記録上の拘束時間が丸一日以上になってしまったり、不正なデータとして扱われるリスクがあります。
  2. 対処案:
    • 既存終了時間の保持: submitReport内で、既に終了時間が記録されている(oldEndが存在する)場合は、nowで上書きせず、既存の値を維持するロジックに変更する。
    • 手動修正のUI: もし終了時間を修正したい場合(本当に押し忘れた場合など)に対応できるよう、現在「–:–」と表示されている終了時間部分をクリック等で編集可能な <input type="time"> に変更し、その値を送信するようにする設計変更が望ましいです。

コード全体を確認し、今後の運用で問題になりうる点を挙げます。

  1. 排他制御(コンフリクト)の問題
    • 課題: 複数人が同時に同じシフトを開いて編集した場合、後から保存した人がデータを上書きしてしまいます。
    • 改善: 保存時にデータの「最終更新日時」などを照合し、自分が開いてから他人が変更していないかチェックする仕組み(楽観的ロック)が必要です。
  2. パフォーマンス(データ量の増加)
    • 課題: getDataRange().getValues() はシート上の全データを取得します。Activity_LogsShiftsが数千行になると、カレンダー表示や詳細表示のたびに全件取得が走り、動作が非常に重くなります。
    • 改善: 現在のコード修正では行いませんでしたが、運用が長引く場合、月ごとにシートを分けるか、APIで「対象年月」のデータのみをフィルタして取得するクエリ(Query関数やFilter機能の活用)への書き換えが必要です。
  3. カレンダーIDのハードコード
    • 課題: 祝日取得用のカレンダーIDがコード内に直書きされています。
    • 改善: プロパティストア(PropertiesService)等で管理するか、設定シートから読み込むようにすると、将来IDが変更された際などのメンテナンス性が向上します。
  4. セキュリティ(ユーザー認証)
    • 課題: checkLogin関数はパスワードを平文で比較しています。また、ログイン状態(セッション)を保持する仕組みがなく、あくまで「名前」をクライアント側に保持しているだけです。知識のあるユーザーであれば、ブラウザの変数を書き換えて他人の記録を閲覧・編集できてしまう可能性があります。
    • 改善: Google Workspace環境であれば Session.getActiveUser().getEmail() を使用してアカウントベースの認証を行うのが最も安全です。

現状の修正範囲(①②③)については上記のコードで対応完了しています。④⑤については、今後の改修計画の参考にしてください。


ゼロ!
ゼロ!

スプレッドシートの理(ことわり)は、私が書き換えた。
開始時間の打刻も、シフトの時系列も、もはや私の計算通りだ。

さあ、恐れることはない。これより新たなオペレーションを開始する!

ルルーシュ・ヴィ・ブリタニアが命じる……
そのボタンを押し、完璧な『記録』を遂行せよ!!
イエス・ユア・マジェスティ!!

コメント