お疲れ様です！IT業界で働くアライグマです！
個人開発している開発関連ニュースのキュレーションサービス「DevPick」で、製品名ごとに記事を集めるトピックページを整理しました。違う製品の記事が同じページに混ざる一方、同じ製品の記事が短縮名と正式名のページに分散していたためです。どちらも名前の問題ですが、片方は分け、もう片方はまとめる必要がありました。
別製品の混在と、同じ製品の記事の分散が起きていた
トピックページは、ある製品や技術についての記事をまとめて読むための入口です。記事を分析したときに名前を抽出し、その名前のページへ記事を結び付けています。ところが本番では、Beam・Pi・Factory・Coreという短い名前のページに、別対象の記事が同居していました。
たとえばPiという名前には、AIエージェントのツールと、小型コンピューターのRaspberry Piが関係します。Piの公式リポジトリとRaspberry Piの公式製品一覧を見ても、同じものではありません。同じ名前を含むからといって、同じページに集めれば便利になるわけではありませんでした。
反対の問題もありました。メーカー名などを省いた短縮名と、正式名が別々のトピックとして公開され、同じ製品の検索入口と記事が分散していたのです。正式名のページを開いても、短縮名で分類された記事は集まりません。
すでに、大文字・小文字、全角・半角、空白や記号の違いをそろえる処理はありました。こうした文字の形をそろえる処理を正規化と呼びます。ただ、空白を消しても省略されたメーカー名は戻りませんし、同名の別製品を区別する根拠も増えません。
必要だったのは、文字の形を整える処理に加えて、「その名前が何を指しているか」を決める処理でした。2026年10月8日に同名の別対象を分ける対応を広げ、その後、10月10日に短縮名を正式名へまとめる対応を追加しています。
IT女子 アラ美
ITアライグマ同名の別製品は、原題・概要の文脈で分ける
同名の別対象がある名前については、原題と概要に現れるメーカー名・製品名などを根拠にして、対象を分けています。Piなら、Raspberry Piと分かる語がある場合はそちらへ、別のPiを指す根拠がある場合はそちらへ結び付けます。短い名前だけで一つの対象に決めません。
重要なのは、候補がちょうど一つに決まったときだけ分類することです。根拠がなければ付けませんし、両方の対象を指す根拠が出た場合も、この判定では付けません。たとえば「あるPiのツールをRaspberry Piで動かす」という内容なら、両方が登場します。どちらか一つを選ぶ根拠にはならないためです。
実装の考え方を単純化すると、次のようになります。これは実際のデータ構造を再現したコードではなく、判断条件だけを取り出した例です。
# 単純化した例：根拠に合う対象を集める
matches = find_matching_targets(original_title, description)
if len(matches) != 1:
return None # 根拠がない場合も、複数ある場合も分類しない
return matches[0]ここで、根拠に使う語の選び方にも落とし穴がありました。最初の実装では、根拠の文字列を部分一致で探していました。たとえばメーカー名の一部としてintelを探すと、一般語のintelligenceにも当たります。製品名を見つけたつもりで、単に別の単語の一部を拾ってしまうわけです。
この問題は、マージ前のレビュー対応で修正しました。一般語や別の語の一部になりやすい綴りを根拠から外し、メーカー名・製品名だと分かる語に絞っています。すべてが本番で起きた誤分類というわけではなく、本番の混在を直す変更の中で、さらに誤分類を生む条件を取り除いた形です。
型番には、もう一段の区別が必要でした。Intelの公式命名説明にあるようなCoreの型番と、AIモデルの説明で使われる「Core 7B model」は、途中までの文字が似ていても別の表現です。実装では語の境界を確かめる正規表現を使い、「Core 7」や「Core i7」を判定しつつ、数字の直後に英字が続く「7B」や「5G」、また「7 billion」は根拠にしないようにしました。
IT女子 アラ美ITアライグマ同じ製品の短縮名は、明示した対応表でまとめる
分ける対応とは逆に、同じ対象を指す別名は正規の名前へまとめます。このように、別々の表記が同じ対象を指すと確認して集約する作業が名寄せです。DevPickでは、同一対象と確認できた別名だけを対応表に書く方式にしています。名前が似ているものを機械的に全部まとめる方式にはしていません。
10月10日の修正では、すでにあった別名対応表へ、メーカー名やモデルの系列名を省いた短縮名を追加しました。記事の分析が短縮名を返しても、正規のトピックへ寄せます。ただし、名前に含まれるバージョン番号が違うものは、この修正ではまとめていません。
実際の製品名とは別の、架空の名前で単純化すると、対応は次のようになります。
# 単純化した例：架空の製品名
aliases = {"Nova 2": "Example Nova 2"}
def canonical_name(name):
return aliases.get(name, name)
canonical_name("Nova 2") # "Example Nova 2"
canonical_name("Nova 1") # "Nova 1"：別バージョンはそのまま「Nova」のような系列名だけでまとめてしまうと、異なるバージョンの記事まで同じページへ集まります。短縮名の統合で解消したいのは、同じ対象の記事が分かれていることです。どこまでを同じ対象と扱うかは、対応表の一行を書く時点で決める必要がありました。
同じ変更のマージ前には、別名の情報を原題照合にも渡す修正を加えました。原題照合は、分析とは別に、記事の元タイトルに現れる名前から既存トピックを探す処理です。正規のトピックだけが存在していても、元タイトルには短縮名しか書かれていない場合があります。
最初の実装では、別名のトピックが存在しないと、照合用の名前にその別名が入りませんでした。対応表には書いてあるのに、原題から見つける経路では使われない状態です。そこで、正規トピックが存在する場合は、別名そのものが保存されていなくても、別名の表示を照合候補へ追加しています。
この経路では、正規トピック自体がまだ存在しない場合に、新しく作るところまでは行いません。別名対応表があることと、すべての処理が同じ条件で対象を作成することは、別の話です。どの入口がどの情報を使うのかを確認して、適用範囲をそろえました。
IT女子 アラ美ITアライグマ既存記事と旧URLも、同じ判断で整理する
新しく取り込む記事の分類を直すだけでは、すでに混在・分散したページは残ります。そこで、保存済みの記事にも元タイトルと概要を使った判断を適用し、トピックとの紐づけを付け直しました。
同名の別製品については、根拠が一つに絞れる記事を、対象が明確なトピックへ移します。根拠が足りない記事や複数の対象に当たる記事は、曖昧な短い名前への紐づけを外します。ここで外すのはトピックとの関連だけで、ニュース記事そのものは削除しません。分類できないことと、記事として不要なことを混同しないためです。
別名の統合では、短縮名に付いていた記事を正規の名前へ寄せます。すでに正規の名前にも付いている記事は、同じ関連を二重に追加しないようにしました。新規記事の処理と既存記事の付け直しが同じ判断関数を使うことで、修正後にまた別の基準で分類されるのを防ぎます。
もう一つ残るのが、以前のトピックページのURLです。同じ対象の別名なら、正規のトピックが存在する場合に、そのページへ転送できます。一方、同名の別製品が集まっていた短い名前は、一つの転送先を決められません。短い名前のページを残し、対象を明示したトピックへのリンクを案内する形にしています。
一覧やサイトマップも、この違いに合わせました。正規ページへ転送できる別名は、一覧に重ねて出さないようにします。ただし、正規のトピックが存在しない場合まで別名を一律に消すことはしていません。名前の対応表だけを見て隠すと、実際に開けるページまで一覧から落としてしまうためです。
以前のページ分割とサイトマップを整理した記事でも、表示と検索向けの情報をそろえる作業をしました。今回も、分類の保存先だけで完了とせず、読者が旧URLからたどり着く先と、一覧に並ぶページまで確かめる必要がありました。
IT女子 アラ美ITアライグマ分類できる例より、分類してはいけない例をテストする
今回の変更では、正しいトピックへ移る例に加えて、判定を止める条件をテストに入れています。名前が見つかったことだけで成功扱いにすると、混在を直した処理が、別の混在を作ってしまうためです。
同名の識別では、根拠がない記事と、複数の対象の根拠がある記事を分類しないことを確認します。型番の判定でも、「Core 7」を拾えることと、「Core 7B」を拾わないことを組にしています。肯定例だけなら、広すぎる部分一致でも通ってしまいます。
別名の統合では、短縮名だけに付いている記事と、短縮名・正規名の両方に付いている記事を用意しています。どちらも正規名へ一度だけ紐づくこと、異なるバージョンは移さないことが確認対象です。原題照合には、正規名は存在するが別名は保存されていない場合と、正規名自体が存在しない場合の両方を追加しました。
既存記事を整理する処理には、同じ処理をもう一度実行しても、変更が増えないことを確かめるテストもあります。やり直すたびに関連が重複したり、別のトピックへ動いたりすると、既存データの修正を安心して再実行できません。
これらのテストで、未知の製品名まで正しく分類できると証明したわけではありません。確認できた名前と根拠に対して、どこで統合し、どこで分離し、どこで判定を保留するかを固定したものです。対応表と根拠語は、対象を増やすたびに、その境界も一緒に見直す必要があります。
私にとって今回の学びは、名寄せの精度を「たくさん集められたか」だけで見ないことでした。同じ対象を取りこぼさない条件と、別の対象を混ぜない条件を、同じ変更の中で確かめることが大事でした。
IT女子 アラ美ITアライグマまとめ
DevPickのトピック整理では、10月8日に同名の別製品を分ける対応を広げ、10月10日に同じ製品の短縮名をまとめる対応を追加しました。文字の表記をそろえるだけでは、どちらも解決できませんでした。
同名の別製品は、元タイトルと概要の根拠が一つに絞れるときだけ分類します。同じ製品の別名は、確認した対応表で正規名へ寄せます。この判断を、新規記事・原題照合・既存記事の整理へ適用し、旧URLにも対象の違いを反映しました。
私が今回学んだのは、名前の整理には「まとめる」と「分ける」の両方が必要だということです。判断材料が足りない記事を無理に分類せず、分類してはいけない例までテストすることが、混在を増やさないための土台になりました。
IT女子 アラ美ITアライグマ
