最新情報

訪問者の目に入る上部バーから内部運用向けのインジケータを取り除き、公開ヘッダーは初めての訪問者にとって意味のあるナビゲーションとアクションだけを表示するようにしました。

ダッシュボード内の「アカウントとアクセス」を端から端まで確認し、アカウント種別の切り替え、言語切替、ツールチップがデスクトップで一貫して読めるように整えました。

具体的な外部ソースを指す参考項目は、安定して新しいタブで開きます。読んでいたガイドの位置を失うことなく、参考情報を確認できます。

単一のURLではなく「各発行会社のサイト」のようにカテゴリーを指す参考項目は、リンク表示ではなく本文テキストとして表示されます。クリックしても遷移しないリンクが現れることがなくなります。

同じ表示ルールが公開中のすべてのガイドに適用されるため、どのガイドを読んでいても「参考情報」セクションの見え方と挙動が同じになります。

NoJo Enterprise・JapanETCcard・JapanTollReceiptsの3つのサイトが、承認済みのお客様の声について同じキュレーション済みリストを参照する形になりました。いずれかのサイトにお声が追加されると、ご覧の言語のまま、他の2サイトでも同じお声をお読みいただけます。再入力や再翻訳の手作業は発生しません。

サイトの表示言語を切り替えても、各お客様の声を最初から最後まで自然な文章でお読みいただけます。句読点・敬体／常体・言い回しのすべてが表示言語に合わせて整えられており、もう一方の言語の直訳のような違和感がありません。

現在表示中のページを、ナビゲーション上で再度クリックすると、サイトはそれを「再表示の合図」として受け取り、ページ上部までスクロールします。

端末の「視差効果を減らす」設定が有効になっている方には、アニメーションではなく、即時ジャンプでページ上部に移動します。

ナビゲーションリンクへの中クリック・Ctrl+クリック・⌘+クリック・Shift+クリックは、これまで通り新しいタブまたはウィンドウで開きます。

ETC再セットアップとセットアップ証明書、ETC利用証明書と領収書の違い、ETCマイレージの登録・ログイン トラブルシューティング、ETC利用照会サービスの登録手順、ETC利用明細の保存期間、高速代の消費税の取扱い、高速代の仕訳例、ETC利用明細と電子帳簿保存法、ETC利用明細が表示されない場合と過去分の確認、そしてETC経費精算スターターキット――合計10本のガイドを今サイクルで新規執筆・公開しました。いずれも独立した中立リファレンスとして、公式関係性を主張せず、税務助言も行わず、必要に応じて公的・正本のソースへ読者を案内します。

サイトマップ ページの最下部に、公開中のすべてのガイドを番号付き・3カラムで列挙した網羅的な索引を追加しました。トピック別に探したいときは従来どおり上部のセクションをそのまま使い、特定のページに直接たどり着きたい場合は1画面の「目次」としてこの索引から探せます。

これまで個別に公開していた11本のリファレンス（法人フリート向けの主要ガイド、ETC利用明細の総合ガイド、反映遅延の解説、カーシェアとレンタカーのETC領収書、freee / マネーフォワード向けCSV準備、ETCマイレージとの突き合わせ、車載器管理番号のセットアップ、高速道路の経理処理ガイド、通行料と利用明細の照合）を統合カタログに取り込みました。ナレッジセンターのハブ画面に表示される総件数が、公開している実際のガイド数と一致するようになりました。

ナレッジセンターのハブURLが2回掲載されていた小さな不整合を解消し、検索エンジン向けサイトマップは公開URLごとに正規エントリが1件だけになりました。今後サイトマップを再取得するクローラは、当社が公開しているページの集合と一貫したURLリストを参照できるため、インデックスの同期が取りやすくなります。

ナレッジセンターのハブ画面、ガイド一覧ページ、そして新しいサイトマップの複数行索引は、いずれも同じ統合カタログを参照するようになりました。ガイドの新規公開・改名・取り下げが発生した際は、すべての一覧表示が手動同期なしで一斉に更新されます。これまで「ハブには135件と表示されているのに別のページでは145件が出ている」というずれが発生し得る構造になっていましたが、その種のずれを今後は構造的に発生させない設計に切り替えました。

日本語の文末の疑問符を、ビルド ツールが時折残してしまっていた半角の `?` ではなく、本来の全角「？」に揃えました。文の途中にある英語の製品名の前後に挟まっていた半角スペース（初期の機械翻訳が残しがちな癖）も削除し、ひとつのまとまりとして自然に読めるようにしました。これらは「訳の差し替え」ではありません ―― 意味は完全に同じです ―― が、これらが揃ったことで、ページ全体が「日本語が母語の書き手」が書いたような読み心地になります。

英語先行の下書きから持ち越されていた一部のカタカナ語のうち、日本語の業務文書では通常漢字で書かれるものについて、慣例的な漢字表記に変更しました。目的は純粋に読みやすさの向上です。用語集の変更はなく、専門用語が消えることもありません。また、連携先（特にMEISAIとJapanETCcard）のスタイルガイドで指定されている固定用語はそのまま維持しています。

CTA ボタンと引用文のうち、英語から逐語訳されて機械的に読めていたごく一部を、日本語のマーケティング コピーライターが実際に書きそうな表現に書き直しました（一括置換ではなく、人間のレビュアーによる確認を経ています）。元の意味とトーンは完全に保たれており、表現を曖昧にしたり弱めたりはしていません。

管理者専用の新しいアクションを追加しました。これにより、管理者は1回のリクエストでミラーの完全な再同期を連携先に対してトリガーできます。アクションは冪等で、2回実行しても行が重複することはなく、実行前後のドキュメント件数、挿入された行数と更新された行数の内訳、対象とした上流総件数、連携先のチェックサム、を構造化された監査証跡として返します。これにより、管理者はミラーが正本と一致したことを機械可読な形で確認できます。新規デプロイをミニット ゼロから完全同期で送り出したい場合や、SWR スロットルが許容範囲を超えてドリフト状態を保留した場合などに使うことを想定しています。

v2.31で導入した運用担当者向けの診断エンドポイントが、`upstream_total`（連携先から最後に通知された総件数）、`drift`（ローカルと上流の差分）、`last_full_pull_at`（ミラーが最後に完全な追いつきを実行した時刻）を追加で報告するようになりました。「このデプロイは正本から遅れていないか？」を、`kubectl exec` やログ tail なしに、診断1回で確認できます。

ミラー読み出しごとに走るSWRリフレッシュは、これまで連携先の`/latest`（直近数件）のみを取得していました。今後はローカルミラー件数と記録済みの上流総件数のドリフトも検査し、差分が設定可能なしきい値（既定50件）を超え、かつ最後のフル取得から設定可能な最小間隔（既定6時間）が経過していれば、リフレッシュは透過的に`/full`リシンクへ昇格し、すべての行を一括で取り込みます。スロットリングにより`/full`の呼び出し頻度は最小間隔あたり1回までに保たれ、ドリフト状態が継続しても連携先のサービスを叩き続けることはありません。

新規デプロイ直後でミラーがまだハイドレートされていない場合だけ表示する15件の静的フォールバックは、これまで「合計X件」の装飾表示にハードコード値を使っていました。今後はミラーが上流から最後に観測した総件数を参照するため、ポッド上で1度でも上流呼び出しが成功していれば、公開ページが連携先の正本数と矛盾する数値を表示することはありません。ハードコードの初期値は、上流呼び出しが一度も完了していない真のコールドスタート時のためだけに残されています。

Mongoの新コレクションに、連携先から正常に取得できたお客様の声を1件1ドキュメントで保存します。安定ID（連携先ID／登録ID／レガシー行はコンテンツ・ハッシュ）で識別され、連携先呼び出しが成功するたびにアップサートされ、デプロイをまたいで単調に増加します。公開のお客様の声エンドポイントは、このミラーを主データソースとして読み出します（新着順ページネーション、p99サブミリ秒）。15件の固定フォールバックは、ミラーがまだハイドレートされていない新規デプロイの「最初の読み出し」だけで動作します。

ミラーが空の状態で新規デプロイが立ち上がった場合、最初のリクエストが密かにワンショットのバックグラウンド ハイドレーションをトリガーします。ハイドレーションは連携先の `/latest`（高速・新着10〜20行）と `/list` の最初の10ページ（各15行＝合計約150行の新着）を巡回し、空ページや失敗ページに当たり次第そこで停止します。重い `/full`（2,600件超を一度に返却し、上流タイムアウトに乗り上げやすい）は意図的に使いません。結果として、新規デプロイは「冷えたミラー」から「最新約150行が見える状態」へ、毎回数秒で到達します。

ミラーから配信した各読み出しについて、直近の成功リフレッシュがSWRウィンドウ（デフォルト24時間・デプロイごとに調整可能）を超えていれば、バックグラウンドで `/latest` を1本だけ取得し、新規行をアップサートします。重複防止ロックにより、トラフィック量に関係なく同時実行は常に1本のみ、読み出し自体がこのネットワーク呼び出しでブロックされることはありません。連携先で新規公開された行は、トラフィックがあるサイトでは数分以内に次の訪問者から見え始めます。

診断エンドポイントに、現在のミラー ドキュメント件数を `local_mirror.doc_count` として追加しました。これにより運用担当者は、当該デプロイのミラーが「空（＝連携先／フォールバックに依存している状態）」なのか「完全にハイドレート済み（＝自己充足している状態）」なのかを一目で判断できます。既存の `last_upstream_call` ブロックと併せて、「なぜお客様の声がデグレードしているのか？」をどこからの1回の curl で回答できるようになりました。

公開向けにお客様の声を返す全コード パス（連携 /list、連携 /full、静的フォールバック）に対して、共通ヘルパーで「防御的な新着順ソート」を一律に適用しました。これにより公開 API の並び順は契約として自己保証されるかたちとなり、上流の連携サービスが ID 昇順や登録順など別の順序で返してきても、マーケティング ページに到達する前に必ず新着順に整えられます。同一日付のアイテム間では入力順を維持するため、上流のタイブレーク（ID降順など）はそのまま尊重されます。

コールドスタート時に即座に描画できるよう、約30件のお客様の声をJSバンドルに埋め込むビルド時ジェネレーターが、書き出し前に必ず新着順へソートするようになりました。以前はキャッシュの並び順をそのまま使っていたため、ライブAPIのレスポンス順と食い違うことがあり、ページを開いて数秒後に「並びが戻ったように見える」違和感の原因となっていました。初回描画とフェッチ後の描画が、常に同じ順序で表示されます。

連携プロキシ内の15件の静的フォールバック リストが登録順で保持されており、上流とキャッシュの両方が到達できない場合に「4/8 → 4/7 → 4/5 → 4/12 → 4/11 → 4/9」という非時系列の並びが表示されていました。モジュールのインポート時に新着順でソートするよう修正し、フォールバック時も先頭のカードが最新のお客様の声になるようにしました。