製品が増えたときに直す場所を1つにする
製品の情報を複数のサイトに掲載するとき、同じ情報をどこで更新するか。今回は、自社の製品名鑑サイトと、会社の窓口のサイトの「プロダクト紹介」を対象に、一覧の管理方法と公開時の確認手順を変えました。この記事で扱うのは、2026年10月11日の記録です。
以前は、製品名鑑サイトの一覧をHTMLの中に直接書いていました。一方、窓口のサイトには、それとは別に固定の6件を掲載していました。製品が増えるたびに2か所を直す必要があり、片方だけ古くなることが困りごとでした。
そこで、製品情報の正本を products.json という1つのファイルにまとめました。名鑑サイトは実行時にこのファイルを読み込み、窓口のサイトはサーバに同じファイルを置いて読み込む形です。対象にしたのは、窓口のサイトの日本語・英語のページです。
今回の変更では、情報を更新する場所に加え、公開前と公開後に何を確かめるかも決めました。掲載するURLは公開前に全件検査し、公開前には現在の公開物を保存します。公開後には、手元のファイルと公開されたファイルを照合し、実際のページの表示も確認しました。
掲載する情報と、掲載しない理由を正本に持たせる
products.json の各製品には、日本語・英語の名前、分類、URL、料金の種類、対応言語、日本語・英語の説明を持たせました。英語ページが別にある場合は、英語用のURLも記載します。
料金については、「無料」「無料＋有料プラン」「有料」の3種類のラベルにとどめ、金額は載せません。金額の正本は各サービスのページです。一覧にも金額を書くと更新する場所が分かれ、片方が古くなるためです。製品一覧に情報を集める一方で、金額を管理する場所は増やさない判断にしました。
対応言語も表示に反映します。日本語だけのサービスには、英語のページで「Japanese」の印をつけます。製品の名前と説明を日本語・英語で持たせることに加え、サービスの対応言語も正本に記録し、一覧に反映する形です。
掲載しない製品の扱いも、正本に含めました。名鑑と窓口の両方から隠す場合は hidden、窓口にだけ出さない場合は hp:false を使い、理由を一言添えます。たとえば、売っている物が別の製品と同じで重複する場合です。表示する行だけを管理するのではなく、表示対象から外す判断も同じファイルに残します。
読み込みに失敗した場合の表示も決めました。名鑑サイトでは数字を「–」にして一覧を出さず、窓口のサイトでは以前の固定の一覧に戻します。共通のファイルを読む構成に合わせて、読めなかったときの振る舞いまで定めています。
このとき、2つのサイトで同じ表示に戻すわけではありません。名鑑サイトでは一覧の表示を止め、窓口のサイトでは従来の一覧を使います。それぞれのサイトについて、読み込みに失敗した場合に何を表示するかを決めました。
公開前の検査は「確認できなかった」を分ける
窓口のサイトへファイルを置く前に、掲載する行のURLをすべて取りに行く検査を入れました。各URLの判定条件は、転送後の最後の応答が200であること、本文が500バイト以上あること、<title> があることです。
URLから応答が返るかだけでなく、本文の大きさとタイトルの有無も確認します。転送がある場合は、転送前の応答ではなく、最後の応答を判定に使います。この条件を、掲載するURLの1件ずつに適用しました。
また、検査結果では、リンクの状態と、検査そのものを実施できたかを区別しました。終了コードと扱いは、次のように定めています。
| 終了コード | 意味 | 扱い |
|---|---|---|
| 0 | 全件OK | 置く |
| 1 | 落ちている行がある | 置かない |
| 2 | ファイルが読めない・対象が0件＝確認できなかった | 置かない（「落ちている」とは区別する） |
終了コード1と2は、どちらも公開を止める結果です。ただし、その意味は異なります。ファイルが読めず検査できなかったのに、リンク先が落ちていると扱えば、存在しない故障を探すことになります。反対に、確認できなかった結果を問題なしと扱えば、壊れた物を公開してしまいます。
そのため、「置くか、置かないか」だけでなく、「何を確認できた結果なのか」を終了コードに残しました。対象が0件の場合も、全件OKには含めません。ファイルを読めない場合と同じく、確認できなかった結果として公開を止めます。
この分岐は、わざと落ちるURLと壊れたファイルを使う負のテストで確認しました。それぞれ終了コード1と2が出ることを確かめています。正常な結果で先へ進めるだけでなく、落ちている行がある場合と検査できない場合を、別の結果として扱えることも確認しました。
名鑑サイトの公開手順にも、同じ検査を全件に対して入れました。窓口のサイトだけでなく、名鑑サイトを公開するときも、掲載するリンクを検査する手順です。
公開前に保存し、公開後にファイルと画面を照合する
公開時には、まず現在公開されているファイルの実物を保存しました。戻すためのファイルを、上書きする前に確保する手順です。上書きした後では、それまで何が公開されていたかを取り戻せないため、この順番にしました。
次にファイルを置き、その後でサーバ上のファイルと手元のファイルを照合しました。窓口のサイトでは4ファイルともmd5が一致し、名鑑サイトでも公開物と手元のsha256が一致しました。
公開前の保存と公開後の照合は、確認する対象が異なります。保存するのは更新前に公開されているファイルの実物で、更新後に照合するのはサーバ上のファイルと手元のファイルです。更新前の状態を残してから置き換え、置き換えた後のファイルを確かめる順番にしました。
さらに実際のページをブラウザで確認し、コンソールのエラーは0、横にはみ出す要素も0でした。ファイルの照合と画面の確認を両方行い、置いた内容と表示の状態をそれぞれ確かめています。
結果として、日本語・英語の「プロダクト紹介」には11件を掲載しました。ほかの4言語のページは従来の固定の一覧のままです。そちらにあるリンク14本についても、すべて200を確認しました。今回、一覧の読み込み方を変更した範囲と、固定表示を残した範囲は分かれています。
新しい製品を追加する流れは、次の手順になりました。
products.jsonに1件足す。- 名鑑サイトを公開する。
- 窓口のサイトへ置く手順を実行する。
窓口のサイトへ置く手順では、リンクの実測が必ず走ります。製品情報を追加する場所は1つにし、その情報を2つのサイトへ反映する際には、公開手順の中で検査を行う形にしました。
業務に置き換えると
社内の複数のページや資料に同じ情報を載せている場合、今回の記録から点検できるのは次の項目です。
- 同じ情報を別々に直していないか。 正本を1つにし、ほかはそれを読む形にできるか確認します。掲載しない理由も、正本に残す対象です。
- 掲載前に全リンクを確認しているか。 載せる行のURLを機械で取りに行き、決めた判定条件で確認する手順があるかを点検します。
- 「確認できなかった」を区別しているか。 OK、落ちている、確認できなかった、という結果を分け、検査できない場合も公開を止める扱いになっているかを確認します。
- 公開前の保存と公開後の照合があるか。 今の公開物を保存してから更新し、更新後はハッシュで手元のファイルと照合する順番になっているかを点検します。
今回の運用では、製品情報の正本を1つにまとめ、掲載しない理由もそこに記録しました。公開前のリンク検査は3つの結果に分け、全件OKの場合にファイルを置きます。さらに、公開前の実物の保存と、公開後のハッシュによる照合を手順に含めました。
対象のサイトは、自社の製品名鑑サイトと、会社の窓口のサイトです。窓口のサイトでは、日本語・英語の「プロダクト紹介」に今回の管理方法を適用しました。
この記事は、TechAthletes が自社のサービスを作る中で記録した実測をもとに書いています。業務への導入のご相談は 仕事の窓口 で受け付けています。