解析2時間。実装20分。
人間が手を動かしている時間ではありません。どちらも、AIへ作業を任せてから結果が返ってくるまでの時間です。
商品名が分からない物を、AliExpressで探しやすくしたい。それだけのつもりで作り始めた「AliExpress Navi」が、いつの間にか、商品分類そのものを調べ直すプロジェクトになりました。
AIを使えば、もっと簡単に終わると思っていました。実際、調査も実装もかなり任せられます。ところが、任せられる範囲が広がると「ここも調べておきたい」が増えていく。
気づけば、プログラムを作る時間より、その中に入れる商品分類を考える時間の方が大きくなっていました。
- AIなのに解析2時間、実装20分
- 始まりは「商品名が分からないと検索できない」だった
- 商品を並べるのではなく「何を探しているか」を整理する
- カテゴリを作り始めたら、分類そのものが大仕事になった
- 細かく分けすぎても、まとめすぎても使えない
- AIに商品分類を任せるようになった
- Dotsを使ったら、さらに深みにはまった
- 1カテゴリの解析に約2時間かかる理由
- 名前を知らない人が本当に探せるかまでテストする
- 調査が終わっても、そのまま実装はしない
- Codexでの実装も20分前後が当たり前になった
- AIで時短したはずなのに、AIの終了を待つようになった
- AIで仕事が減るどころか、できることが増えてしまった
- 調査の副産物として「変な商品」まで見つかる
- まだ完成していない。それでもAliExpress Naviを公開した
- AliExpress Naviは今も拡張中
- 小さな検索ツールが、商品辞書を作るプロジェクトになった
AIなのに解析2時間、実装20分
現在の開発では、規模の大きなカテゴリになると、AIによる調査・分類・監査に約2時間かかることがあります。コード実装を任せているCodexでも、大規模な追加では20分前後かかることが珍しくなくなりました。
この2時間は、私が画面につきっきりで商品を調べている時間ではありません。指示を送ってから、AIが調査し、分類を整理し、監査して、成果物を出すまでの待ち時間です。20分の方も、Codexが既存コードを確認し、実装や検証、配布用ファイルの生成を行う時間です。
もちろん、その前後には人間の仕事があります。何を作るか決め、分類方針を確認し、結果を読み、必要なら調べ直してもらう。実装後には、実際の画面で受入確認もします。
つまり「2時間20分でカテゴリが完成する」という話でもありません。
それでも、AI側の処理だけでこの時間がかかると、最初は少し意外でした。検索を助けるツールに、何をそこまで調べさせているのか。原因は、画面の裏側にある商品分類でした。
始まりは「商品名が分からないと検索できない」だった
AliExpressを見ていると、写真なら用途が分かるのに、名前が分からない商品に出会います。
「こういう物が欲しい」というイメージはある。ところが検索窓を前にすると、何と入力すればよいのか分からない。日本語の商品名も知らないのに、英語名となると、さらに分かりません。
日本語で検索すること自体はできます。ただ、実際に試すと、欲しい物とは違う商品がやたらと出てくることもあります。検索語を少し変えたいと思っても、その言葉が出てこない。
私が解決したかったのは、この段階の困りごとでした。
検索結果を比較する前に、まず「自分が欲しい物は何という種類なのか」を知りたい。そこを日本語の分類からたどれるようにすれば、探しやすくなるのではないか。
そんな発想から作り始めたのが、WordPress上で動く無料ツール「AliExpress Navi」です。
商品を並べるのではなく「何を探しているか」を整理する
カテゴリから探す場合、基本的には次の順番で進みます。
- 大カテゴリを選ぶ
- 商品棚を選ぶ
- 商品タイプを絞る
- 必要なら方式や接続などの違いを選ぶ
- 英語検索語を確認する
- AliExpressの検索へ進む
商品棚は、近い種類の商品をまとめた、売り場の棚のようなものです。日本語で棚を見ながら、欲しい物に近づいていきます。
ツールの中心にあるのは、商品を探すための言葉です。「この商品を買ってください」と選ぶところまで代行するのではなく、検索を始めるための手がかりを用意しています。
そのため、同じ商品タイプでも検索候補に違いがある場合は、利用者にその違いが伝わる必要があります。「標準」「高性能」といった言葉だけでは、何を選べばよいのか分かりません。
接続方式なのか、表示方式なのか、入出力の方向なのか。選ぶ理由が分かる名前にするところまで、分類の仕事に含まれています。
カテゴリを作り始めたら、分類そのものが大仕事になった
最初は、大カテゴリを作って、その中に商品名を並べればよいと思っていました。
工具なら工具、時計なら時計。あとは探しやすい順に並べれば、だいたい形になるはずです。
ところが実際に調べ始めると、商品名を集めるだけでは済みませんでした。
似た名前の二つは、同じ商品なのか。それとも構造が違う別の商品なのか。色違いを分けているだけではないか。その商品を、このカテゴリへ置いてよいのか。日本語の名前を付けても、一般の人に意味が伝わるのか。
英語検索語まで決めようとすると、曖昧な分類のまま先へ進めなくなります。何を探す商品なのかが曖昧なら、検索する言葉も曖昧になるからです。
たとえば「時計本体」を整理したときも、腕時計、懐中時計、指輪型時計、置時計、壁掛け時計だけでは終わりませんでした。音声で時刻を知らせる時計、触って確認する時計、文字で時刻を示すワードクロック、振り子時計や鳩時計なども出てきます。
一つのカテゴリを追加するつもりが、その中にある商品群を調べ直すことになる。
ここで、開発の中心が変わりました。検索ナビのプログラムを作ることより、そのナビに入れる商品分類を設計することの方が、大きな仕事になったのです。
細かく分けすぎても、まとめすぎても使えない
商品を詳しく調べるほど、違いは見つかります。ただ、見つかった違いをすべて別の商品タイプにすると、今度は分類が使いにくくなります。
黒と白、大小、素材やブランド、セット内容。そのたびに別の棚を作っていたら、利用者は似た項目を延々と選ぶことになります。
そこで、色やサイズなど、同じ商品内の違いである「SKU差」は、原則として独立した商品タイプにしない方針にしています。
一方、見た目が似ていても、接続方式や動作原理が違えば、探すべき商品が変わることがあります。そこまで一緒にしてしまうと、欲しい物へたどり着けません。
どこまで同じ商品としてまとめ、どこから分けるか。この線引きが、思っていた以上に難しい。
しかも、一度決めた分類が、その後も使いやすいとは限りません。
工具・DIYでは、用途を中心にした分類から、商品タイプの棚へ作り直しました。自動車部品では、初案が純正部品寄りになり、一般の利用者が買う場面を想像しにくい部品が多く混ざりました。そこで、社外エアロなどへ方向を見直すことになりました。
AIが出した一覧に商品がたくさん入っていても、それだけで使える分類になるわけではありません。
「ここへ来た人は、何を見つけたいのか」。その問いに戻ると、丸ごと作り直した方がよい場合もありました。
AIに商品分類を任せるようになった
こうした調査を、人間だけで一つずつ進めるのは現実的ではありません。そこで、商品分類にもAIを本格的に使うようになりました。
ただし、頼んでいるのは商品名の一覧作成だけではありません。
市場を調べ、商品タイプを洗い出し、似た項目を整理する。呼び方の違いをそろえ、重複を探し、別カテゴリへ置くべき物が混ざっていないか確認する。さらに英語検索語と、購入前に確認したい条件までまとめてもらいます。
たとえば電子部品なら、名前が分かって検索できても、接続方式や対応する型番を確認しないと選べない物があります。そのため、候補ごとに「購入前にここを確認」という項目も整理しています。
AIを、調査担当、分類担当、監査担当として使うようになったわけです。
一方、何を作りたいか、どこまで細かくするか、この名前で一般の人が分かるか、どの方向へ作り直すかは、私が判断しています。
以前なら自分で一覧を埋める時間が大きかったところが、今は、出てきた分類を見て「これは使いやすいか」を考える時間に変わりました。
作業を任せられる分、判断する対象が増えています。
Dotsを使ったら、さらに深みにはまった
途中から、長時間の調査を任せられるAI「Dots」を使うようになりました。
これで、分類をさらに深く調べられるようになりました。ところが、深く調べられるようになった分だけ、以前の分類で足りないところも見えてきます。
抜けていた商品群が見つかる。似ていると思っていた二つが、実は別の商品だと分かる。追加しようとすると、別カテゴリに似た項目がある。そちらとの関係を確認すると、既存の分類にも見直したい部分が出てくる。
調べて理解すれば終わる、という流れを想像していました。実際には、理解が進むほど、次に調べることが増えていきました。
AIを使うほど、分類の沼が深くなっていく。
完成度を上げようとして穴を探すと、穴が見つかります。直して調べ直すと、今度はもっと細かな穴が見つかる。Dotsを使ってから、この循環がさらに強くなりました。
もちろん、知らなかった商品を知り、雑然としていた分類が整理される面白さもあります。だから続いているのですが、「これで終わりそうだ」と思う機会は、なかなか増えません。
1カテゴリの解析に約2時間かかる理由
規模の大きいカテゴリで解析に約2時間かかるのは、調べる対象が多いことに加え、一つの分類に対して何度も違う角度から確認しているからです。
実装前に商品分類そのものを徹底的に調べる工程を、開発上は「Hack工程」と呼んでいます。大まかな流れは次のようになります。
- 市場を調べ、商品候補を集める
- 重複を確認し、色やサイズなどのSKU差を除く
- 商品タイプを整理し、別カテゴリとの境界を確認する
- 日本語名称と英語検索語を決め、検索候補を作る
- 購入前の確認項目をまとめる
- 名前を知らない人の言葉からたどれるか試す
- 分類の穴を探し、全件を監査する
- 成果物を生成し、文書・表・実装データの整合性を確認する
境界確認とは、簡単に言えば「この商品を本当にこの棚へ置いてよいか」を確かめる作業です。
時計本体を整理する場合でも、時計バンドや修理工具、収納ケースは別の物です。時刻表示が付いている気象観測機器まで、すべて時計本体へ集めればよいわけでもありません。
さらに、新しく作る棚と、すでにある棚の関係も確認します。
時計本体の整理では、既存カテゴリに置いていたフリップ時計や完成ニキシー管時計、IPS方式のニキシー風時計、天井投影時計などは、既存の所属を維持しました。新カテゴリを作ったからといって、関連しそうな商品を全部移動する方針にはしていません。
新しい分類だけを見ればきれいでも、ツール全体では重複や混乱を生むことがあります。そのため、既存カテゴリまで含めた監査が必要になります。
ここまで任せていると、2時間という待ち時間も、だいぶ見え方が変わります。
名前を知らない人が本当に探せるかまでテストする
分類表を作っていると、商品名を知っている人には分かりやすい並びになりがちです。
けれど、このツールを作った理由は、商品名が分からない人を助けることでした。名前を知っている前提でしか使えないなら、出発点からずれています。
そこで、正式な商品名を使わずに、欲しい物を説明する「逆引きテスト」も行っています。
時計なら、たとえばこんな言葉です。
- 指につける時計が欲しい
- 文字で時刻を表示する時計を探したい
- 服につける小さな時計が欲しい
この言葉から、時計本体、該当する棚、商品タイプ、検索候補へ自然に進めるかを確認します。
「指輪型時計」と知っていれば簡単でも、「指につける時計」としか説明できない人は、どの棚を見るのか。棚の名前で迷わないか。候補の違いが分かるか。
ここで引っかかるなら、名称や配置を見直す必要があります。
一覧に漏れなく入っていることと、利用者が見つけられることは、別の確認でした。
調査が終わっても、そのまま実装はしない
AIの調査結果が出たら、その内容を整理し、監査してから実装へ進みます。
大きなカテゴリでは、おおむね次の三つを作っています。
| 成果物 | 役割 |
|---|---|
| DOCXの文書 | 分類の方針、判断理由、別カテゴリとの境界を読む |
| XLSXの表 | 全商品タイプと全検索候補を一覧で確認する |
| JSONのデータ | プログラムへ実装する内容の正本にする |
JSONは、プログラムが扱いやすい形で情報をまとめたデータです。ただ、大量の商品分類を人間が確認するには、表の方が見やすい。なぜその分類にしたかを残すには、文書が向いています。
そのため、同じ調査結果を、読む目的に合わせて分けています。
AIが作ったファイルでも、JSONと表の内容や件数が一致しているか、商品を識別するIDが重複していないか、検索候補が抜けていないかを確認します。保存したファイルを再読込できるかもチェックします。
カテゴリによっては、JSONのハッシュ値という、データの同一性を確かめる値まで記録します。実装途中で、別のデータに変わっていないか確認するためです。
ここで、HackとCodexの担当も分けています。
Hackは「何を実装するか」を固める工程。Codexは「決まったものをどう実装するか」を担当します。
Codexへは、監査済みJSONを正本として渡し、商品分類を勝手に考え直さずに実装するよう指示します。せっかく整理した分類が、実装中に別の形へ変わってしまうと、監査からやり直しになるからです。
Codexでの実装も20分前後が当たり前になった
分類が固まれば、次はWordPressプラグインへの実装です。
最初の感覚では、JSONを追加して画面へつなげれば終わりでした。ところがカテゴリが増えるほど、既存の仕組みとの整合を確認する仕事も増えていきます。
現在のプラグインを読み、新しいデータをナビへ接続する。商品ID、検索候補の番号、英語検索語を確認し、既存カテゴリと衝突していないかを見る。外部サービスとの接続に使う既存APIも、その仕組みに合わせて利用します。
さらに、PHP、JavaScript、CSSという、処理や画面表示を担うコードを確認します。追加したカテゴリが動くだけでなく、以前からある機能も動くかという「回帰確認」も必要です。
スマートフォンでの表示を確認し、配布用ZIPを生成した後には、そのZIPを再展開して中身も確かめます。
こうした仕事を任せるようになると、大規模な実装で20分前後かかることも珍しくなくなりました。
そして、分類だけでなく、Codexへ渡すプロンプトまで巨大化しました。
既存機能を壊さない。他カテゴリを勝手に移動しない。検索語を書き換えない。候補番号を取り違えない。既存の接続処理を使う。スマートフォンでも確認する。ZIPの中身まで確認する。
守ってほしい条件を具体的に書くほど、実装指示も長くなります。商品棚を増やしていたはずが、AIへ渡す指示の棚卸しまで増えていました。
AIで時短したはずなのに、AIの終了を待つようになった
AIへ作業を任せる理由の一つは、人間の作業時間を減らすことです。
実際、同じ範囲の商品調査、一覧整理、実装を自分だけで進めることを考えると、今のやり方はかなり助かっています。
ところが、任せる仕事の規模が大きくなった結果、今度はAIの作業が終わるのを待つようになりました。
AIに仕事を任せたはずなのに、「まだ解析中か」と2時間待つ。最初に想像していた時短とは、少し違う景色です。
ただ、その間ずっと操作している必要はありません。任せた調査を待ち、結果が返ってきたところで確認する。人間が手を動かす時間と、処理が終わるまでの時間が分かれるようになりました。
調査側の約2時間と、実装側の約20分も、担当する仕事が違います。前者は分類の中身を固める仕事、後者は確定した内容を既存プログラムへ組み込む仕事です。
この数字だけで、どちらが速いかを比べるつもりはありません。
私にとっての変化は、待ち時間が生まれるほど大きな仕事を、AIへ任せるようになったことでした。
AIで仕事が減るどころか、できることが増えてしまった
以前なら、調べる手間を考えて、ある程度のところで止めていたと思います。
工具の棚を作るだけでも大変なら、時計やファッションの細かな分類まで手を広げる余裕はありません。抜けがあると分かっても、調べ直す負担を考えると、そのままにしたかもしれません。
ところがAIを使うと、「ここも確認してもらえる」が増えます。
10までしかできなかったところを、100まで扱えるようになる。すると、10で終わらせずに100までやりたくなる。そこまで調べると、さらに先の問題も見えるようになります。
AliExpress Naviで起きたのは、まさにこれでした。
検索語だけでよかったはずが、候補の違いを整理したくなる。候補を整理すると、購入前の確認項目も必要になる。商品タイプが増えると、別カテゴリとの重複が気になる。分類が整うと、名前を知らない人でも使えるか試したくなる。
作業は任せられるようになりました。その分、私は「分けすぎではないか」「まとめすぎではないか」「面白い商品だが、この辞書に必要か」と判断するようになりました。
AIによって一人で扱える仕事の規模が大きくなり、その余裕を、さらに作り込む方へ使ってしまった。
だから、効率がよくなったのに、プロジェクトは小さくなりませんでした。
調査の副産物として「変な商品」まで見つかる
分類を調べていると、本来の目的から少し外れたところで、「こんな物まで売っているのか」という商品も見つかります。
そこでトップ画面に、「AliExpressで見つけた気になるもの」という手動の掲載枠を設けました。私が選んだ商品を、最大3点掲載する場所です。
掲載例には、組み立て式の三角形モダンヴィラ、7000W電動マウンテンバイク、大人向け電動ドリフトゴーカートなどがあります。
商品分類を真面目に調べていたら、家のような物や、妙に気になる乗り物まで出てきました。
この枠は、売れ筋ランキングでも、AIによるおすすめでもありません。「なんだこれ？」「ちょっと見てほしい」と思った物を、私が意図的に選ぶ編集枠です。
重機も候補になりましたが、一般の人が使っている場面を想像しにくく、外しました。変わっていれば何でもよいというより、「なんだこれ？」に加えて、少し欲しくなり、使っている自分も少し想像できる。そのくらいの距離感で選んでいます。
面白くて載せたい商品が、アフィリエイト対象外の場合もあります。ここでは、収益性よりAliExpressらしい面白さを優先することもあります。
分類辞書を整える作業とは別に、眺める楽しさも残しておきたい。そんな小さな遊びです。
まだ完成していない。それでもAliExpress Naviを公開した
AliExpress Naviは、すべての商品カテゴリを整備し終えてから公開したわけではありません。調査、分類、実装が残っている状態で、使える部分から公開しました。
理由は単純で、全部が完成するまで待っていたら、公開がいつになるか分からなかったからです。
カテゴリを一つ追加するにも、調査、分類、重複監査、境界監査、成果物生成、Codex実装、既存機能の回帰確認まであります。その前後には、私の判断と確認も入ります。
しかも、カテゴリごとに規模がまったく違います。
ファッション、カメラ、時計。大カテゴリの名前としては一つでも、調べ始めると、多くの商品タイプや境界問題が出てきます。「あと何カテゴリだから、すぐ終わる」という計算ができません。
そこで、使える状態になったカテゴリから公開し、ツールを動かしながら追加する方針にしました。
実際の画面を見ると、分類表だけでは気づかなかった選びにくさも分かります。必要なら既存カテゴリも見直し、再設計する。
公開は、すべての作業が終わった印ではありません。今の私にとっては、使える形にしたものを、さらに育てていくための区切りです。
AliExpress Naviは今も拡張中
記事を書いている現在も、カテゴリ追加や既存分類の見直しを続けています。
これまでに、工具・DIY、キッチン用品、バス・水回り、PC・電子部品、照明・LED、気象観測機器、収納・生活用品、ファッション小物・服飾雑貨、メガネ本体、カメラ本体、時計本体などを扱ってきました。
これらは、順次調査・整備している分野です。すべてが同じ段階まで完成し、公開画面へ実装済みという意味ではありません。
新しい棚を作ることもあれば、すでにある棚を作り直すこともあります。専門的すぎる名前を見直したり、用途でまとめていた項目を商品タイプへ組み替えたり。調査、実装、再確認、再設計を繰り返しています。
AIに一言頼んで完成したツールというより、小さく作って使い、気づいた問題をAIと一緒に直してきたツールです。
追加するカテゴリが増えれば、終わりに近づくはずでした。実際には、調べられる範囲も増えているので、終わりの位置が少しずつ動いています。
小さな検索ツールが、商品辞書を作るプロジェクトになった
出発点は、「商品名が分からないと、AliExpressで検索しにくい」という身近な困りごとでした。
そのために検索ナビを作り、商品を分類し始めたら、分類そのものが大仕事になりました。AIへ調査を任せ、Dotsでさらに深く調べるようになると、抜けや境界の問題も見つかるようになりました。
今では、規模の大きいカテゴリで解析に約2時間かかることがあり、監査したデータをCodexへ渡して、実装にも20分前後を待つことがあります。
手間を減らしたくてAIを使ったのに、減った手間の分だけ、以前なら手を付けなかったところまで進んでしまいました。
もちろん、まだ直すところも、調べるところも残っています。ただ、知らなかった商品を知り、探す道筋が少しずつ整っていくのは面白い。完成を待たずに公開したのも、この形で使いながら育てていきたいからです。
小さな検索補助ツールのつもりが、今では商品辞書を作っている感覚に近くなっています。今後どこまで大きくなるのか、自分でもまだ分かりません。
どんな分類になっているか気になる方は、現在公開中のAliExpress Naviを見るから、実際に触ってみてください。
