8月22日　Ｚシステム会議

8月26日　メルシー実績会議

8月28日　TZシステム会議

9月2日　メルシーキャプテン会議

配車管理 ― 納入先の住所を出荷予定表から自動で整えるようにしました（9月4日公開）

1. 配車管理記録の走行距離が空欄になる納入先が多くありました。原因は、出荷予定表のPDFに納入先の「名称・コード・住所」が載っているのに、取り込みでは使っておらず、納入先マスターへの登録が手作業頼みだったことです。取り込みで使う62件のうち28件が「名称とコードだけで住所も距離も空」という状態でした。
2. 出荷予定表を取り込むときに、納入先マスターも一緒に整えるようにしました。未登録の納入先は住所つきで新しく登録し、登録済みでも住所が空なら住所だけを補います。すでに住所が入っている行には触りません（手で直された住所を上書きしないためです）。
3. 取り込み前の確認画面にも「何件追加され、何件の住所が埋まるか」を表示します。
4. あわせて既存データの補完も行いました。住所が空だった27件を出荷予定表の住所で補い、住所のある納入先が37件から64件になりました。(株)ダイドー本社工場の住所の誤字（川内長野市→河内長野市）も修正しています。

• ※住所が残る3件は納入先コードを持たない手入力の行のため対象外です。
• ※検証は、書き込みを取り消す設定にした複製で本番に実際に流し、データが1バイトも変わらないことを確認したうえで行いました。

配車管理 ― 走行距離・所要時間を画面から一括取得できるようにしました（9月4日公開）

1. 住所は整いましたが、距離は住所から測る必要があり手作業のままでした。納入先マスターの画面に「座標・距離を一括取得」ボタンを追加し、28件をまとめて取得できるようにしました。
2. 地図サービスへの問い合わせは、サーバーからではなく画面側（ブラウザ）から行い、結果だけをサーバーに保存する方式にしています。本番サーバーが古く外部の地図サービスに接続できないためで、メルシーダイキの営業ルート画面で先に使っている方式と同じです。
3. 拠点は愛川町中津4013（DNPエリオ東京工場と同じ所在地）としています。既に登録済みの36件と同じ経路エンジンを使うため、値の一貫性が保てます。
4. 地図サービスの利用量は無料枠に対して0.3%程度で、費用は発生しません。

• ※別件として、厚木事業所の作業報告画面（workreport）で使っている地図の鍵が無効になっていることが分かりました。同画面は3箇所で地図を使っています。対応が必要かご判断ください。

シャーリング予定表 ― 前の工程の実績を待たずに予定を組めるようにしました（9月2日公開）

1. 「午前中にRGで切って午後にG2で切る」のように同じ日に2工程を組みたいのに、後ろの工程が前工程の実績を入力するまで候補に出ず、予定が組めないというご指摘をいただきました。
2. 前工程の実績がまだ無いときは、大板の枚数を仮の数量として置き、候補に出るようにしました。実績が入力されれば自動的に実績の数量に切り替わります。
3. 仮の数量には「概」のバッジを付け、マウスを乗せると「前工程の生産枚数がまだ入っていないため大板の枚数を仮に置いています」と表示します。
4. 8月13日に「印刷が終わっていない品物も候補に出す」と直したのと同じ趣旨で、そのとき片方だけ実績待ちのままになっていたものを揃えた形です。

• ※多丁取りの場合、実際の中板枚数は大板枚数×丁数のため、仮の数量は必ず少なめに出ます。数が合わないことは承知のうえで、まず予定が組めることを優先しています。工程ごとの丁数を持つマスタが整えば正確な数量にできます。
• ※枚数を指定して組み込む手段はまだありません（残数の全量が入ります）。

シャーリング寸法指定書 ― 寸法線から図へ補助線を伸ばしました（8月25日公開）

1. 図の外側に並ぶ全長・全幅などの寸法線が図から離れており、どの位置を指しているのか分からないというご指摘への対応です。製図の慣習にならい、寸法線の両端から図の枠まで細い破線を伸ばしました。
2. 切断線や対角線と紛れないよう、寸法線より細く薄い線にしています。

作業スケジューラ ― シャーコンパイラ画面を実装しました（8月23日）

1. 見た目だけ作られていて中身が繋がっていなかった「シャーコンパイラ」画面を、従来のデスクトップ版から移植して動くようにしました。
2. 受注番号または管理Noを入力すると、作業時間の累計と大板換算の枚数の推移を折れ線で表示します。3つのパターンを並べて比較することもできます。

• ※元データは2025年3月末で更新が止まっているため、2025年4月以降の受注は「未登録」と表示されます。
• ※保存と切断図の表示は未実装です（次段階の予定）。

フィルム在庫 ― 入庫画面を実機のタブレットに収まるようにしました（8月28日〜9月4日公開）

1. 実機のタブレット（横向き）で、下段の情報欄が画面からはみ出し、パレット内容の一覧が1行しか見えないというご指摘をいただきました。写真を送っていただき、それを元に調整しています。
2. 情報欄・バッジ帯・各行の余白を段階的に詰め、作業者名をタブバーの右横に統合するなどして、合計で約200px以上の縦を節約しました。パレット内容の一覧が十分に見えてスクロールできる状態になっています。
3. パレット内容を開いたとき、残数のある先頭の行が最初から見える位置に来るようにしました。
4. 実機で画面を強制的に再読み込みしないと最新の見た目にならない問題があったため、公開のたびに自動で切り替わる仕組みを入れました。以後はスーパーリロードが不要です。

Z入力をスマートフォン向けに作り直しました（新Z入力・9月2日公開）

1. 携帯電話の時代に作られたZ入力を、iPhone を最優先にした画面に作り直しました。従来の画面はそのまま並行して使えます（新しいURLでの運用です）。
2. どの機能を作り直すかは、コードではなく実際の利用実績（直近90日の操作記録）から決めました。その結果、使われていないと思われていた「認定シール」の入力が実は830件使われていること、逆に厚木事業所側の一部の操作は2014〜2022年で使用が途絶えていることが分かりました。
3. 入力欄を1つにして「元 → 先 → 数量」と役割が進む方式にしました。iPhone で入力欄を移動するとキーボードが閉じてしまう問題を避けるためです。
4. カメラでのバーコード読み取りを実装しました。カメラをONにしている間は続けて読み取れ、「登録」「1項目消去」「全やり直し」は専用のバーコードで操作します。印刷用の操作カード台紙も用意しました。
5. 電波が切れた場合に備え、送信できなかった入力は端末に残して自動で送り直します。ただし二重に在庫が動かないよう、送り直す前に「そのコマンドが既に記録されているか」を必ず確認します。確認できない場合は送信しません。
6. メニューに「新Z入力」を追加しました（権限をお持ちの13名にのみ表示されます）。

• ※在庫を動かす部分の書式は1バイトも変えていません。実際の操作記録を正解データとして、新しい画面が同じ書式を再現することを検証しています。
• ※厚木事業所への展開と、フィルム在庫画面への組み込みは保留中です。メルシーダイキ側の現場確認を先に行う方針のためです。

新Z入力 ― 現場からのご指摘への対応（9月3日公開）

1. 「iPhoneでボタンが一切反応しない」とのご報告。入力欄のフォーカスを保つための処理が、iPhoneではタップそのものを打ち消していました。パソコンのブラウザでは起きないため開発時のテストを通過してしまっていた不具合です。
2. 「バーコードを認識しない」とのご報告。使用していた読み取り部品のブラウザ用の窓口が機能しておらず、JANもCode39も1件も読めていませんでした。自前で映像を取り込んで解析する方式に変更しました。
3. 「普通の向きだと読めず、縦にすると読める」とのご報告。バーコードの向きによって読めなくなるため、通常・90度回転の両方を順に試す方式にしました。
4. 「読み取り回数がすごい速さで増え、本体が熱を持つ」とのご報告。解析の間隔と精度の設定を見直し、1秒あたり11回・CPU約40%だったものを4.2回・約8%まで下げました。読み取りやすさは落ちていません。
5. 「数量以外でもテンキーが出て分かりにくい」とのご報告。表示の切り替えが効かない指定になっていたため修正しました。

• ※実機のカメラでのピント・照明・現物ラベルの印字品質は、まだ現場で確認できていません。読めない場合は画面下部に出る「解像度／回数」の表示をお知らせください。

住宅改修システム ― 利用者・案件・フロアの3階層に作り直しました（9月4日公開）

1. 工事計画図が端末の中にしか保存されず、利用者や案件との結びつきもない状態でした。「利用者 → 案件 → フロア」の3階層に整理し、データをサーバーで保管する形に作り直しました。
2. ログインすると前回開いていた案件がそのまま復帰します。案件が開くまで各タブは操作できないようにしました。
3. 案件名は「＜利用者名＞邸 住宅改修工事」で、同じ利用者に2件以上ある場合のみ作成年月が付きます。案件の作成・切り替え・削除ができます。削除しても図面と写真は残す作りにしました（誤操作から戻せるようにするためです）。
4. 工事計画図に加えて、基本情報・理由書の入力内容もサーバーに自動保存されるようにしました。通信が切れている間の編集も端末側に控えを取り、次に開いたときに新しい方を採用します。
5. 他の端末で更新されていた場合は上書きせずお知らせします。

• ※★施工前・施工後の写真は、これまで一度も保存できていませんでした。サーバー側に画像処理の機能が入っておらず、送信した瞬間にエラーになる状態だったためです。画面側で縮小してから送る方式に変え、案件ごとに保存されるようにしました。
• ※保存したファイルはURLを直接叩いても中身が出ないようにしています（実測で確認済み）。

住宅改修システム ― 画面のモダン化と作図機能の仕上げ（8月25日〜9月4日公開）

1. 画面の骨格を作り直しました。上部の横並びタブを廃して左の縦ナビに変え、トップバーを白基調にし、作図の道具は左のレールにまとめています。3案を作ったうえでご選択いただいた案を実装したものです。
2. 作図エリアを画面いっぱいに広げ、ウィンドウの大きさやタブの切り替えに追随するようにしました。
3. 間取り図では、部屋の辺をつかんだ変形、L字・凹型の部屋、既存の部屋の外周をなぞる廊下の作図、ドア・トイレ・浴槽の配置（内開き・外開きの切り替え、なぞった長さでの設置）に対応しました。
4. 部屋や設備のパレットは、1度設置したら選択が自動で解除されるようにしました（描画モードは連続して描くため解除しません）。
5. 隣接した部屋があるときに設備が隣室側に置かれる、外開きのドアが壁から浮くなど、操作中に見つかった不具合をあわせて修正しています。

Z携帯 ― 予約リストの並び順（8月28日公開）

1. 使わなくなった古い予約の予約コード名を変更して別件に流用した際、予約リストの下に埋もれて現場が見つけられない、とのご要望をいただきました。
2. 予約コードを変更したときに受付日時を更新するようにし、新規登録したものと同じく一覧の上に出るようにしました。

• ※元の受付日時は上書きされて残りません。別項目として残す案もご提示しましたが、今回は上書きで進める判断をいただいています。

請求予定データが作られない不具合を発見・修正しました（9月3日公開）

1. 長期会員の会費タブで「2027年の請求予定を作成しました」と出た直後に「会員情報が存在しません」と表示され、実際には1行も作られない、という症状の調査から始まりました。
2. 原因は、会員の存在確認で件数を入れた変数と判定に使った変数が食い違っていたことです。このため会員の有無にかかわらず必ず処理を打ち切っており、請求予定を作る5つの経路がすべて無効になっていました。
3. この誤りは記録が残っている最初の版から存在しており、システムの管理を始める以前からの不具合です。
4. 会員種別を変更した会員にだけ2027年以降のデータがある、という不自然な分布も、種別変更の処理だけがこの関数を通らないためだと説明がつきました。

• ※既に欠けている2027年以降のデータは約1,100人分あります（レンタルコート会員615・ゲスト来場者344・長期正会員8ほか）。長期会員は画面を開けば自動で補われますが、それ以外は対象外のため、補い方は別途ご相談させてください。

請求漏れを防ぐ更新確認ダイアログを追加しました（9月3日公開）

1. 期間満了の会員には次回請求前に「更新／種別変更／退会」を確認され、更新の方は何も登録されない運用と伺いました。予定データが無いまま請求書を作ると、その会員はエラーも警告もなく一覧から消えるだけで請求漏れになります。
2. この「不足分の予定作成」の処理自体は以前から用意されていましたが、画面からの導線がなくURLを直接叩く手動運用でした。請求管理画面で請求月を選んだときに更新対象の会員をダイアログで提示し、承認された場合のみ作成する方式にしました。
3. 状態を「更新（データ作成）／更新／変更（変更先の種別）／退会」の4区分で表示します。作成対象がいない月はダイアログを出しません。
4. 実際に 2026年11月分で、3年平日会員の3名（10006・10179・10611）が次回請求月の予定を持たないことを検出できました。
5. 会員管理画面と請求管理画面で重複していた請求予定まわりの処理を共通のライブラリに切り出しました。切り出しの前後で出力が完全に一致することを確認しています。

• ※実装中に、入会日が請求月より後の会員が「予定が無い」として誤って更新対象になり、入会前の期間の請求予定を作ってしまう問題を見つけ、あわせて修正しました。

請求金額の調査（9月3日）

1. 長期正会員1名の2026年11月の請求額が20,000円（前後の月は30,000円）になっていました。11月請求は翌年1月分を含みますが、集計した時点で2027年のデータが無く2ヶ月分で確定していたためです。当該1行のみ30,000円に修正しました。
2. あわせて、未発行・未請求の請求月について金額が3ヶ月分の合計と一致するかを全会員で検証しました。金額の過不足は上記1件のみでした。
3. 「請求金額が0のまま」の会員が7名155件ありましたが、これは請求漏れではありませんでした。請求書の金額はこの項目ではなく月会費から都度計算されており、実際に該当の方も12回すべて正しく請求・入金済みでした。
4. この項目は会員管理画面に表示するための参考値で、割引などで手作業により個別の金額が入っている場合があります。一括で再計算すると手修正の意図を壊す恐れがあるため、一括再計算は行わない判断としました。

• ※★調査の途中で当社が退会判定の項目を読み違え、「退会済みの会員に請求が出ている（4名・85,000円）」と一度ご報告しましたが、これは全て誤りでした。実際には再入会された現役の会員で、誤請求は1件もありません。ご報告時にご心配をおかけしました。
• ※退会の判定は、当社が誤用した項目ではなく、その月の予定行と退会者区分で行うのが正しいことを確認しています。現行の仕組みは意図どおり機能しています。

交通アクセスとスクールページの修正（9月1日公開）

1. 「大沼神社を左折」という案内について、実際には神社の正面にあるのは歩行者専用の参道で車では曲がれないことを地図データで確認しました。第1駐車場・クラブハウスへ導くため「大沼神社を過ぎて左折」に修正しました。
2. スクールページのコーチのレベル表記を「一般 上級」から「一般 中上級」に修正しました。本番表示用と複製版の両方を同期しています。

合計時間をサーバー側でも算出するようにしました（9月1日公開）

1. 合計（拘束・運転・作業・休憩）と開始時刻は日報画面を開いたときにブラウザで計算して保存する作りで、日報画面を一度も開かない便は合計が空のまま残っていました。管理用CSVでは「拘束−0−0−0」となり時間異常として表出していました。
2. 帰庫時と退勤時にサーバー側でも合計を算出して保存するようにしました。不具合ではなく構造の問題でしたが、これで日報画面を開かなくても合計が埋まります。
3. 規模は2026年で年に十数件、8月は3便（いずれも同じドライバー・車番）でした。該当の便には日報画面へのアクセスが1件も無いことを記録で確認しています。
4. 移行にあたり8月の137便で保存済みの値と突き合わせ、一致131件・値が変わる4件・未集計が埋まる5件でした。値が変わる4件はいずれも計算値の方が正しく、時間の残差が0分になりました。

• ※過去データの一括修正は未実施です（8月分で9便が対象）。

帰庫後の作業時間と待機時間の仕上げ（8月22日〜31日公開）

1. 帰庫登録から退勤までを「帰庫後作業」として計上する仕組みを整えました。日報画面からも帰庫後の入力ができるようにし（本人・帰庫登録済み・退勤から1時間以内の場合のみ）、その分だけ退勤時刻が延びます。
2. 帰庫後に休憩を取っていると同じ時間が作業と休憩に二重計上され、待機時間がマイナスになる不具合を修正しました。
3. 到着と作業開始・休憩開始が1分ずれることで生じる待機時間の端数を解消し、8月の該当データも修正しました。
4. スキップした拠点の補正が管理用CSVだけ効いておらず、走行距離が異常として誤検知されていた問題を修正しました。
5. 8月25日 Z6便の「帰庫入力後に前の拠点に戻ってしまう／退勤画面が出ない」という事象について、原因3点を特定して修正しました。
6. データベース接続が一時的に失敗する事象に対し、接続の再試行を入れて安定化しました。公開後の稼働確認では再試行の発生は0件です。

• ※8月24日の公開直後、公開したファイル同士で同じ名前の処理が重なり、日報画面が約3分エラーになりました。当社の確認不足によるもので、同日中に復旧しています。以後、公開前に名前の重複を機械的に照合し、公開後にも画面が正常に開くことを確認して、異常なら自動で元に戻す手順を追加しました。

無認証だった管理用スクリプトを削除しました（9月4日・セキュリティ対応）

1. 公開領域の直下に、ログイン確認を一切行わずにデータの削除・更新を実行する管理用スクリプトが置かれたままになっていました。どこからも参照されておらず、現在の環境では実行してもエラーになる状態でしたが、予防のためサーバーとリポジトリの両方から削除しました。
2. メルシーダイキ側で同種のファイルが外部の自動巡回プログラムに叩かれ、予約データが壊された事故（2026年6月）と同じ構造のため、同様の対応としています。
3. 削除前のファイルはバックアップを取得しています。