3社のAPIを突き合わせるとき、IDを書き写してはいけない｜名前で引き当てる設計にした理由

01 / 本文

結論：IDを書き写すと、取り違えても誰も気づかない

3つのサービスのAPIから、同じ分類（ジャンル）のデータを集めるスクリプトを書いた。最初はこう書いていた。

{'id': 6958, 'name': 'バック'}

動く。しかしこの数字が本当に「バック」なのか、コードを読んでも確かめられない。書き写すときに1桁間違えても、別の分類の数字が集まってくるだけで、エラーにはならない。

数字を書くのをやめ、名前で引き当てる方式に変えた。

# 変更前：数字を書き写す。取り違えても気づけない
GENRES = [{'id': 6958, 'name': 'バック', 'slug': 'back'}]

# 変更後：名前だけを書き、IDはAPIから引き当てる
GENRES = [{'name': 'バック', 'slug': 'back'}]

def genre_ids(cred, floor_id):
    """ジャンル名 → ジャンルID の対応表をAPIから作る。"""
    table = {}
    offset = 1
    while True:
        rows = call('GenreSearch', dict(cred, floor_id=floor_id,
                                        hits=500, offset=offset)).get('genre', [])
        if not rows:
            break
        for row in rows:
            name = (row.get('name') or '').strip()
            if name:
                table.setdefault(normalise(name), str(row['genre_id']))
        offset += 500
    return table

02 / 本文

見つからなかったら、飛ばす

名前で引く方式にすると、「見つからない」場合の扱いを決める必要がある。

私は黙って飛ばすことにした。近そうなIDを当てるより、そのサービスからは数えないほうがいい。

この判断が効いた。実行してみたら、2件が飛ばされた。

「人妻」→ 実際の登録名は 「人妻・主婦」

「ナース」→ 実際の登録名は 「看護婦・ナース」

一字違うだけで引き当てられない。 IDを書き写す方式だったら、この2件は間違ったIDで別の分類を数えていた可能性がある。しかも、確かめる手段がなかった。

03 / 本文

社ごとに呼び方が違う

3社を突き合わせて分かったのは、同じものを指す名前が社ごとに違うことだった。

制服 ／ 制服女子

レズビアン ／ レズ

看護婦・ナース ／ ナース

そこで、候補を並べて実在した名前だけを使う仕組みにした。どれも見つからなければ、その社は数えない。

GENRES = [
    {'name': '制服', 'slug': 'seifuku', 'duga': ['制服女子']},
    {'name': 'レズビアン', 'slug': 'lesbian',
     'duga': ['レズ'], 'sokmil': ['レズ']},
]

def look_up(table, genre, key):
    """その社での呼び方を、実在する名前の中から選ぶ。無ければ空。"""
    for candidate in [genre['name']] + list(genre.get(key) or []):
        found = table.get(normalise(candidate))
        if found:
            return found
    return ''

04 / 本文

一覧を出す道具を先に作る

名前で引く方式にすると、正しい名前を知る手段が要る。「一字違うと黙って飛ばされる」のだから、実際の登録名を確かめられないと運用できない。

そこで、各社の分類名を一覧するだけの小さなスクリプトを作った。数十秒で終わり、データは何も書き換えない。

これを先に作っておけば、分類を追加するときに毎回推測しなくて済む。実際、正式名はこの一覧から見つけた。

05 / 本文

無いものは作らない

調べていくと、3社のどこにも存在しない分類がいくつも出てきた。世間ではよく使われる言葉でも、各社の分類には無い。

こういうとき、「近いから」といって別の分類に当てはめると、数字の意味が変わってしまう。

実在する近い分類に誘導するか、何も作らないかを、その都度決めた。キーワード検索でヒットするからといって、それは分類ではないことも意識した。作品名に含まれる語と、分類は別物だ。

06 / 本文

上限があるなら、画面に書く

APIには取得の上限がある。1社は検索の offset 上限で5万件まで。他の2社は時間の都合で人気順の上位5,000件までにした。

つまり集計結果は実際より少なく出る。これを黙っていると、数字が正確であるかのように見えてしまう。

画面に「人気順の上位までを数えているため、実際より少なく出ることがあります」と明記した。内訳（各社が何件か）も出している。

制約を隠さないほうが、数字の信頼性は上がる。

07 / 本文

まとめ

IDを書き写さない。 名前で引き当てれば、取り違えは起きない。見つからなければ飛ばす。

社ごとに呼び方が違う。 候補を並べ、実在した名前だけを使う。

正しい名前を調べる道具を先に作る。 一字違うと黙って飛ばされるのだから、確認手段が要る。

無いものは作らない。 近いからといって別の分類を当てると、数字の意味が変わる。

上限があるなら画面に書く。 制約を明示したほうが、数字は信頼される。