NPB Analysis 2026年8月更新：データ更新と開発環境を見直しました

更新内容

NPB Analysisのデータ更新と開発環境を見直しました。現役選手を標準対象とする取得処理と、引退選手を含めて確認できる拡張オプションを分け、通常更新と検証用の処理を区別しています。利用者が通常の検索で必要とするデータを安定して更新しながら、過去の選手や異なる対象範囲も検証できるよう、取得条件を一つの固定値にせず分離しました。

取り込んだ結果は apps/web/data/npb.sqlite に登録し、WebとAPIの参照先を揃えています。中間ファイルを手動でコピーする手順を減らし、更新後は同じデータでテスト・ビルドできるようにしました。データ更新の作業者が生成したファイルと、Webが実際に読むファイルが別になると、更新したつもりでも画面が古いままになってしまうため、参照先を一本化しています。

更新後には、ファイルが存在することだけでなく、代表的な選手のプロフィール、年度別成績、検索条件、ランキングの結果を確認します。欠損が増えていないか、年度や所属が不自然に変わっていないか、データが空のときに画面がエラーにならず説明を表示できるか、といった点を確認対象にしています。

通常更新と調査用更新の違い

通常更新では、現在の検索利用者が必要とする選手と年度を対象にし、取得対象を絞りすぎて表示データが欠けないことを優先します。調査用更新では、引退選手や過去年度を含めた範囲を試し、パーサーが異なるプロフィール形式や古い成績表を扱えるかどうかを確認します。調査用の結果をそのまま通常公開のデータへ上書きしないことで、検証中の条件が通常の検索へ混ざるのを防いでいます。

この二つを分けておくと、同じ取得処理でも「本番へ載せるための更新」と「パーサーを改善するための実験」を別々に評価できます。取得件数が増えたことだけを成功条件にせず、既存の選手ページが壊れていないこと、年度や所属の表記が保持されていること、検索結果の件数が急に減っていないことを差分として確認しています。

開発時の検証

全件取得をいきなり実行せず、選手数やかな検索の件数を絞ったデバッグ取得を使います。少数の入力でHTMLの変化、SQLiteの更新、検索結果の表示を確認してから、本番用の処理へ進みます。取得元のHTMLが変わった場合は、パーサーが例外を出すケースだけでなく、空欄や古い値を正常なデータとして通してしまうケースも確認します。

SSRの画面、読み取りAPI、データパーサーはそれぞれテストし、データが欠けた場合や条件が不正な場合にサーバーの内部情報を返していないかも確認します。特に、検索結果が0件のとき、名前の入力が長すぎるとき、未知の年度や球団を指定したとき、SQLiteの値がNULLになるときに、利用者が次に何をすべきか分かる画面を維持しています。

更新後の確認では、データベースの件数だけを見るのではなく、代表的な読み取り経路を実際に通します。選手名検索から個別ページへ移動する経路、年度と球団を指定して比較する経路、成績の項目が空欄になる経路、APIへ同じ条件を送る経路を確認します。画面だけ正しく見えてもAPIが古いファイルを読んでいる可能性がありますし、反対にAPIだけが新しいデータを返してSSRが古い状態を描画してしまう可能性もあるためです。

取得元のページ構造が変わった場合は、失敗した選手だけを再取得するのか、全件を停止するのかを判断します。空欄を「成績なし」と解釈してよいのか取得失敗なのか区別できない場合は、更新を成功扱いにしません。誤った値を大量に登録するより、更新を止めて原因を確認し、前回の検証済みデータを維持するほうが利用者への影響を抑えられます。

利用者への影響

画面の検索・比較機能は、従来どおりNPB Analysisで利用できます。今回の更新は、通常の選手検索やプロフィール表示の使い方を変更するものではありません。対象範囲やデータ更新の条件が変わる場合は、検索結果の説明と更新時点を確認できるようにします。

掲載データには取得元と更新時点の制約があるため、記録を参照するときは画面の注記と公式資料をあわせて確認してください。誤りを見つけた場合は、検索条件、該当ページ、表示値、比較対象、参照した資料を添えてご連絡ください。次回の更新では、データの出典と更新時点をさらに見つけやすくする改善を進めます。

更新記事では、取得処理の内部実装をすべて記載するのではなく、利用者に関係する対象範囲、更新時点、データの制約、公式情報との照合が必要な場面を説明します。実装者向けの詳細なコマンドやテーブル定義はプロダクト側のドキュメントで管理し、EX FOUNDRYの記事では、どの更新が検索結果へ影響するかを追えるようにしています。