データ収集と読み取り専用配信を分離する——検査済みの版だけを閲覧へ渡す

朝の一斉閲覧が仕入先へ集中する

営業担当者が朝に仕入先の在庫一覧を開く業務を考えます。画面を開くたびに各仕入先へ問い合わせる仕組みなら、利用者が増えるほど外部への接続も増えます。一人の画面が遅くなるだけでなく、仕入先の応答制限に触れ、別の担当者まで待たされるかもしれません。検索条件の違いで取り込む時点がずれると、同じ商品を見ながら在庫数が異なることもあります。収集と閲覧を直接結ぶ構成では、問い合わせの集中と値の時点の違いを同時に扱う必要があります。

閲覧画面に必要なのは、毎回取り直すことではなく、判断に使える時点の情報を安定して見ることです。そこで外部からの収集、意味を整えた蓄積、利用者への読み取りを三つへ分けます。収集担当が定めた間隔で情報を更新し、画面は蓄積された版を読みます。更新が遅れたときには画面側で古さを示します。この分離には保存領域や更新管理が必要ですが、誰が何回見たかと外部への問合せ回数を切り離せます。

営業担当が一つの商品を何度も検索することと、その商品の元データが何度も変わることは一致しません。検索の多さを更新頻度の根拠にすると、人気商品に接続が集中します。必要な更新頻度は商品の変動と判断の用途から決め、閲覧の多さは画面の応答を改善する材料として扱います。二つを分けて測ることで、どの部分へ投資するかも判断しやすくなります。

まず必要な新しさを決める

在庫の画面を分離する前に、どんな判断をするかを確かめます。商談の候補を探すための参考在庫なら、一定間隔の更新でも使えるかもしれません。一方、その場で発注を確定する操作には、直前の確認や仕入先側の確保が必要です。蓄積データの閲覧だけで在庫を保証してはいけません。ここでは候補を調べる一覧と、注文前に確認する工程を分けます。同じ画面で数字を見せても、数字が保証する範囲は操作ごとに違います。

一律に「最新」と書く代わりに、商品ごとの対象時点、最終成功時刻、更新予定を示します。仕入先が更新時点を明示しない場合、その情報も不明として残します。画面の再読み込みは保存済みの値を読み直すだけで、外部情報の取得を意味しないことを説明します。利用者にとっては小さな違いに見えますが、発注前の確認を省略してよいかに関わります。分離の設計は、更新が誰の責任かを明確にする作業でもあります。

新しさの条件は数値だけでなく、例外も文章にします。休業日の仕入先は前営業日の値を使ってよいか、臨時出荷停止中は更新が成功していても利用を止めるか、といった条件です。時刻だけで有効性を決めると、営業日や提供元の注意事項を見落とします。定時収集が成功したことと、注文候補として使えることを分ければ、更新済みの危険な情報を過信せずに済みます。

収集側は途中の失敗を閉じ込める

収集工程は、対象仕入先、対象商品、必要な項目、取得条件を入力として受け取ります。外部への接続が成功したら、受け取った情報を一旦保管し、件数、単位、商品対応を検査します。途中まで取れた結果をそのまま閲覧用へ書き込むと、更新の前半と前回の後半が混在します。今回の設計では、更新候補を別に用意し、条件を満たした範囲を明示してから閲覧用の版を切り替えます。全仕入先の同時更新が必要かも用途で決めます。

一社だけ停止した場合は、他社の更新まで止めるか、取得済みの部分を公開するかを事前に決めます。在庫候補の一覧なら会社単位で更新し、停止した会社は前回値と注意表示を残す方法が考えられます。全社を比較する日次報告なら、同じ締め時刻の値が必要かもしれません。成功と失敗を一つの結果に丸めず、対象範囲ごとの更新状態を残します。利用者が見る合計も、どの会社分が当日の値かを判断できる形にします。

検査済みの版には、対象範囲と検査結果を結び付けます。商品数が急に半分へ減った場合、正常な品揃え変更か、取得の途中停止かを判断する材料になります。前回と差が大きいことだけで全て拒否するのではなく、変更の理由を確認できる仕組みが必要です。収集側で異常を検出して止めた際にも、画面へその理由と前回値を渡せれば、利用者を無言の空欄で待たせずに済みます。

閲覧側には変更権限を渡さない

利用者向けの読み取りは、許可した項目と範囲だけを返します。仕入先への認証情報や収集の設定を、画面へ渡す必要はありません。検索条件は商品分類、会社、対象日など利用者が理解できるものへ限定し、収集を自由に起動する操作と分けます。この分離により、画面側の不具合が元データの書換えへ広がる経路を減らせます。読み取り専用だから全て安全というわけではなく、閲覧してよい会社や価格の範囲は別途管理します。

保存している情報全てを返すのも避けます。仕入条件には社内限定の注記や担当者名が含まれるかもしれません。閲覧用には必要な在庫、対象時点、注意事項を選び、調査用の詳細は権限を分けます。収集と閲覧を分離すると、公開できる項目を定義する場所が作れます。画面の表示だけで隠しても、裏で不要な情報を返していれば分離したことにはなりません。応答内容自体が利用者の許可範囲と一致するかを検査します。

読み取りの権限は画面単位だけでなく情報単位で確認します。同じ在庫一覧でも、販売価格を見られる担当者と原価を見られる担当者は違うかもしれません。見せる項目を明示しておけば、別の画面を追加するときも必要な権限を確認できます。収集した原資料を直接画面へ渡す方法は開発の初期には簡単ですが、後から情報の公開範囲を狭める作業が複雑になることがあります。

更新を頼むボタンの扱いを決める

利用者が古い値を見つけたとき、更新を依頼できると便利です。ただし押すたびに外部へ接続するなら、一斉閲覧の問題が別の形で戻ります。同じ仕入先への更新依頼をまとめ、既に取得中ならその進行を表示する方法が考えられます。依頼を受け付けたことと更新が成功したことは分けます。「更新を受け付けました」の後に、成功した時点や失敗理由を確認できる必要があります。処理中の表示だけで更新済みと判断させないようにします。

更新には頻度の上限や仕入先側の条件が伴います。重要な商品だけを優先する場合も、利用者の連打順ではなく業務上の基準を設けます。予約済みの依頼を別の利用者が見られるようにすれば、不要な再依頼を減らせます。時間がかかる収集を画面の待機時間に閉じ込めず、受付、進行、結果を分ける設計です。失敗時の再取得をどこまで自動にするかも決め、料金や制限がある接続先へ無制限に繰り返さないようにします。

依頼をまとめるときは、同じ対象と同じ取得条件であることを確かめます。ある担当者は一商品だけ、別の担当者は全商品を必要としているなら、まとめて全件取得することが適切かを判断します。条件が異なるのに同じ依頼として扱うと、必要な情報が返りません。一度受け付けた依頼が失敗した場合も、別の依頼へ勝手に変えず、元の対象と結果を対応させて記録します。

分離の効果は場面を分けて測る

検証では、通常の閲覧、同時閲覧の増加、仕入先停止、部分更新、更新直後の検索を別々に試します。閲覧側が保存済みの値を返せるかだけでなく、停止中に古さが表示されるか、取得中の未検査データが混ざらないかも確認します。応答時間が短くなっても、値の時点が分からなければ業務の品質は上がりません。収集の成功率、閲覧の応答、表示の鮮度は異なる指標として扱い、一つの「正常」にまとめないようにします。

負荷を確かめるときも、外部の仕入先へ大量の問い合わせを送る必要はありません。保存した説明用データと模擬の接続先で閲覧数を増やし、外部へ問い合わせる回数が利用者数に比例しないことを確認できます。実接続の確認は許可された範囲で別に行います。模擬環境で速く返せたことは、本番の収集能力や相手側の制限を保証しません。試した条件と試していない条件を分けることで、次の検証の目的が明確になります。

検証に使う保存データには、正常な応答だけでなく、欠けた項目や重複した商品も用意します。画面が軽く動くかの試験と、意味が違う情報を止める試験は目的が異なります。一つの試験結果を全工程の合格へ広げないことが大切です。定時処理を一度動かしただけなら、翌日の回復や長期の蓄積は未確認とします。期間を広げた確認が必要な理由を示せば、運用開始後の点検計画も立てやすくなります。

収集と配信の間に検査済みの境界を置く

収集と配信を分ける構成では、何を収集し、どこまで検査した値を渡すかを定めます。金融データ基盤のヤクモ提供の実装には、複数の公的情報源から取得し、構造化、蓄積、読み取り専用配信へ進む構成があります。銘柄の要点を見せるWeb画面と記事配信は、利用者へ届ける側の実装例です。在庫一覧への設計では、保存した版を画面が読む経路と、外部の値を更新する経路を分けます。どの仕入先の値がいつ確認されたかも渡し、閲覧の成功を収集の成功へ置き換えないようにします。

更新間隔、同時閲覧数、応答時間はそれぞれ試験して定める条件です。読み取り専用で配信できても、全ての用途で最新値を保証できるわけではありません。在庫の更新依頼は受付まで、注文前の確認は仕入先側の状態まで、と役割を分けます。対象データの変動が速ければ、定時収集の間隔を短くするだけで足りるかを確かめます。技術名を同じように採用しても同じ品質になるとは限らないため、接続先の制限と利用者の判断をもとに分離の境界を決めます。

読み取り専用という条件は、配信側が元データを書き換えないことを明確にします。ただし利用者の判断の妥当性まで保証する言葉ではありません。在庫情報では、出所、対象時点、更新状態を見て用途へ適合するかを確かめる必要があります。参考候補の一覧と注文を確定する画面を同じ保証で扱わず、注文直前に必要な照会を別に置きます。画面を追加するときも、読み手が必要とする保証の範囲を先に定めれば、収集側へどんな記録を求めるかが分かります。

取得と検査をPython、蓄積をPostgreSQLやSupabase、原資料の保持をオブジェクトストレージへ分担する構成が考えられます。クラウドバッチで定時更新し、pytestで失敗時の挙動を検査する場合も、閲覧者へ収集の認証情報を渡さない境界が必要です。在庫一覧は検査済みデータだけを読み、更新候補は別に管理します。具体的な更新間隔や版切替の方式は対象に合わせて検証します。一社が停止した場合に、他社の更新と注意表示を両立できるかを確かめます。

小さな分離から始められる

最初から大きなデータ基盤を作る必要はありません。一種類の仕入先情報を定時に収集し、検査済みの版を保存し、一覧はその版だけを読むところから始められます。運用上の完了条件は、閲覧が増えても不要な収集が増えないこと、収集失敗が画面で分かること、更新前の版へ戻れることです。構成図を分けるだけでは足りず、権限、時点、版の切替まで確かめると、実際の分離になっているかを判断できます。

社内の集計表、ニュース収集、設備データの閲覧にも応用できます。一方、毎秒変わる情報を操作の直前に確定させる用途では、定時収集だけでは足りません。読み取りの基盤を持ちつつ、確定操作に必要な確認を別工程で設けることが考えられます。分離は更新を遅くするための設計ではなく、どの時点の何を見ているかを明確にするための設計です。閲覧の安定性と判断に必要な新しさを、別々の条件として満たすことが重要になります。

運用が小さい段階では、保存した版を一つだけ保つこともできますが、復旧に必要な過去版は決めておきます。削除の前に、どの報告や判断で使われた版かを確認します。全履歴を永久保存する必要はありませんが、訂正時に以前の画面へ戻れる期間は業務に合わせて設定します。蓄積を置くことで保存の責任が生まれるため、保持期間と削除条件も収集の設計に含めます。