対象: 2026年6月24日時点の塾コマボード確認記録
確認範囲: v3.71のローカル配布物と公開側のファイル差
記録上の注意: 本番への反映完了は確認できていません
アプリの不具合に見えても、画面の裏で読み込むJavaScriptが届いていなければ、原因は画面の計算式ではありません。6月24日の引き継ぎ記録が追ったのは、Googleカレンダーの内容が表示されない問題と、更新ファイルが公開側へそろっているかという境目です。ローカルで修正版を作ることと、利用者の画面に届くこと。その二つは別々に確かめる必要がありました。
読み込まれないファイルを切り分ける
引き継ぎでは、提供された更新ZIPに assets/app.js が含まれていない状態が確認されました。ファイルがないURLを開くと、JavaScriptではなくトップページのHTMLが返る設定も記録されています。ブラウザーから見ると「読み込み先には応答がある」のに、内容はスクリプトではない。応答が返ることだけでは、解決を判定できない例です。
この切り分けを受け、Googleカレンダー読込コードを含む assets/app.js を入れたv3.71の更新ZIPと差分ZIP、単体配置用ファイルがローカルで用意されました。manifestのバージョン更新漏れも修正対象になっています。ここまでで確かめられるのは、修正版を含む配布物を作成したことです。アップロードされたこととは同じではありません。
引き継ぎ資料では、配布ZIPに本体側だけでなくデモ側の assets/app.js も含め、単体で渡すファイルも用意したと整理されています。複数の経路を用意したことは、配布の選択肢を増やします。ただし、どのZIPを誰がどの公開ディレクトリへ配置したのかは、別の記録がなければ追えません。ファイル一式が揃った状態と、アクセス先に置かれた状態の間には、確認の工程が残ります。
公開側との照合で見えたずれ
6月24日の追確認では、公開本番の assets/app.js はJavaScriptとして応答していました。しかし、内容はローカルv3.71とSHA-256が一致せず、v3.66相当と記録されています。公開デモのJavaScriptもローカル版と不一致で、Googleカレンダー読込コードを含まない古い状態でした。さらに公開manifestのバージョン表記はv3.48のままです。
本番ファイルはJavaScriptのContent-Typeで返り、サイズも確認されています。けれど、応答形式が正しいことは、中身が最新であることとは別です。サイズだけでも判定できません。最後にローカル版とのハッシュを比べると一致しない。チェックは「応答したか」から「想定した版が置かれたか」へ進み、そこで公開本番とデモの双方に残る差が明らかになりました。
つまり、検査は「ファイルがあるか」だけでなく、応答形式、コードの内容、ハッシュ、表示バージョンを、本番とデモで別々に比べました。ここで見つかった不一致は、ローカルの完成をそのまま公開の完成と呼べない理由です。ZIPを準備した記録だけを見て「更新済み」と言えば、利用者の画面に残る古いファイルを見落とします。
「作成済み」と「反映済み」の間
この時点での到達点は、v3.71のローカル作成と、公開本番・デモに残る差の把握です。公開側がローカルv3.71へ更新された証拠は引き継ぎにありません。したがって、カレンダー連携が本番で直ったとも、配布ZIPが適用済みとも断定できません。ブラウザーで実際のアカウントを使った一連の確認も、この記録からは読み取れません。
塾コマボードの現在の案内先は、塾コマボードの個別LPです。このページは現行のサービス案内を示すもので、6月24日時点ですでに公開されていたことや、v3.71が本番へ反映されたことの証明ではありません。案内ページの公開状況と、アプリ本体の更新確認は分けて扱う必要があります。
本番とデモは別のURL、別のファイル配置です。片方が直ったとしても、もう片方まで同じ状態とは限りません。公開先ごとにJavaScriptの応答内容、manifestの版、ブラウザーでの読込を確認する必要があります。バージョン番号が同じでも、古いキャッシュや配置漏れが残る可能性はあるため、ファイル照合と画面の動作確認を組み合わせるのが確実です。
次の確認は、対象ファイルを公開先へ反映したあと、同じパスから取得したコードとmanifestを改めて照合することです。そのうえで、ログイン、Googleカレンダーの読込、表示、保存を実環境で確かめる必要があります。検証記録が「用意したファイル」から「利用者の環境で動いた」へ進むには、どの画面・アカウント・端末を通ったかまで残さなければなりません。
