設計の手順
同一の粒度を決める
架空の商品庫ではブランド、型番、仕様版を使います。色違いは別 SKU かもしれません。モデルと SKU の関係を先に定義します。
候補対を絞る
型番、確認済み別名、仕様で候補を探します。翻訳の近さは同一性ではありません。N×M の全比較を避け、漏れを抽検します。
一致と矛盾の項目を見る
公式例は全体の Score と項目の Noul を組み合わせます。この例は容量や地域版を重視します。欠損を unknown とし、一致証拠にしません。
統合前に関連候補を作る
元の記録と項目の出所を残します。明確な相違は拒否、重要項目の矛盾は確認します。高スコアで必須条件を上書きせず、取消可能な処理にします。
グループ全体を検証する
A≈B と B≈C だけで全体を統合しません。識別子、版、仕様を検査します。誤統合と見逃しを言語や別名ごとに測ります。
具体例 · 本サイトの架空データ
| 観察した事実 | 判断 | コードでの処理 |
|---|---|---|
| X2 64GB と128GB | 容量が異なる | 自動統合しない |
| 確認済み別名と同じ仕様 | 一致の候補 | 確認できる提案へ |
| 両方で容量が欠損 | 一致ではない | 追加情報か確認へ |
コピーできる設計例
独自の例です。JSON はリクエストや入力の形、Python は架空スコアの計算のみを示します。API は実行しません。接続前に公式仕様と処理方針を確認してください。
# Input contract for an invented pair; not an API result.
{
"left": {"id": "A", "model": "X2", "capacity_gb": 64},
"right": {"id": "B", "model": "X2", "capacity_gb": 128},
"entity_granularity": "model_and_capacity",
"allowed_outcomes": ["match", "different", "review"]
}よくある失敗
- 名前の類似だけで統合。
- 欠損同士を一致にする。
- 全体制約なしで推移的に統合。
TRY / THINK / COMPARE
先に考えてから解説へ
同名でも地域版が違う場合、価格を統合しますか？
解説を開く
SKU と地域の粒度を確認し、価格の出所と範囲を残します。
提出前の確認
- 粒度と ID を定義。
- 候補の漏れを抽検。
- 欠損と矛盾を区別。
- 全体制約と撤回記録。
よくある質問
高 Score なら統合できますか？
項目規則と撤回可能な記録も必要です。
別名はどう管理しますか？
根拠と確認履歴を残します。
参考資料
公式パターンと Datawhale の実践テーマを参考に、説明・例・演習を独自に作成しています。API の実行結果や性能測定ではありません。