利益相関を先に明示します。私は SoFarBot（www.sofarbot.com）という、AIツールの無料ディレクトリサイトの運営者です。この記事ではサイトを支える半自動パイプライン（候補収集 → AIによる下書き生成 → 人手レビュー → 公開）を、エンジニアリングの視点で書きます。先に結論：AIは機械的な作業の8割を片付けてくれるが、「このツールを掲載するかどうか」という判断だけは、今もモデルに任せていません。
パイプライン全体像
収集 → 重複排除 / リダイレクト追跡で実URL取得 → AI下書き（日英で振り分け）→ LLMによるカテゴリ分類 → 下書き保存 → 人手レビュー → 公開
設計の原則は一つだけです。量が多く許容誤差の大きい作業はAIに、量が少なく許容誤差の小さい作業は人に。 以下、順番に説明します。
1. 候補収集：ランディングページを信じず、本当の公式サイトまで追う
収集元は複数です。GitHub（star / topic でOSSを拾う）、いくつかのRSS（AIニュースや研究所ブログ）、そして ProductHunt の GraphQL API。
何度もハマった点があります。ProductHunt の website フィールドは utm 付きのリダイレクト短縮URLであることが多く、そのまま保存すると多くのプロダクトの「公式サイト」が同じリダイレクタのドメインになってしまいます。対策は地味ですが確実で、各 website に対して 301 / 302 を一度追いかけ、最終的に着地する本当の公式サイトを保存します。
2. AIによる書き換え：「翻訳」ではなく「リライト」
候補が入ってきた時点では、元の英語の説明文で品質はバラバラです。ここで大規模言語モデルを使い、サイト内の統一された語り口に書き換えます。
- 英語版は Gemini、中国語版は DeepSeek、簡体字↔繁体字の変換はローカルで処理します（トークンの無駄を省き、制御もしやすい）。
- プロンプトでは「逐語訳ではなくSEOを意識してリライトする」ことを強調します。直訳した文はSEO価値が低く、読み心地も良くありません。
- カテゴリ分類もLLMに任せます。候補情報と既存のカテゴリ一覧を渡し、最も近いカテゴリを選ばせます。キーワードの単純一致では「AI動画 / AIナレーション / AI字幕」のような近いカテゴリでほぼ間違えます。
この工程がAIに一番助けられている部分です。以前は説明文を一件書くのに数分かかっていましたが、今は下書きがほぼ一瞬で出ます。
3. なぜ書き換え後すぐ公開しないのか
AIのリライトには、安定して出る2種類の誤りがあるからです。
- 平然と詳細を補う：元の文に日本語対応と書いていなくても、「多言語対応」と勝手に足してきます。
- メリット・デメリットが綺麗すぎる：見張っていないと、長所しか書かない、あるいは短所を「惜しい長所」のような言い回しにします。
そのため書き換えの成果物は必ず一度「下書き」に落とし、人手レビューを通してから公開します。レビューでやるのは、無料枠が本物か、短所を十分に書けているか、プロジェクトがまだ生きているか、といった判断です。この部分は今も自動化できていませんし、するつもりもありません。ここがディレクトリサイトの存在意義そのものだからです。
細かいが実用的な工夫
- アイコン / カバー：まずサイト自身の og:image を取得し、取れなければ Google の s2 favicon サービスにフォールバックして、必ず画像を確保します（一覧ページに空の画像枠があると見栄えが悪く、CLSにも響きます）。
- フロントエンド：Nuxt 3 + SSR。一覧ページも詳細ページもサーバーサイドレンダリングで、インデックスにも初期表示にも有利です。
- 多言語コンテンツ：内容は言語ごとに行を分けて保存します（en / zh / zh-TW）。フロントの i18n の key-value ではなく、言語ごとに独立したタイトル・説明・本文のレコードです。
まとめ
パイプラインの設計判断を一言でいうと、「収集・書き換え・一次分類」のような量が多く許容誤差の大きい作業はモデルに、「掲載するか・短所を書けているか」のような量が少なく許容誤差の小さい作業は人に、という切り分けです。最初はモデルに掲載可否まで決めさせようとしましたが、もっともらしく間違えるので、素直に分け直しました。
成果物は www.sofarbot.com にあります。現在100以上のツールと80以上のOSSプロジェクトを掲載しています。手法もハマった点も上に書いた通りで、私のサイトに依存せずそのまま使えます。