多言語 AI ツールディレクトリを構築した方法

ディレクトリには、どの言語でも一貫した識別情報が必要

AI ツールディレクトリには、互いに関係する二つの役割があります。便利なソフトウェアを見つけられるようにすることと、各掲載情報を安定して識別できるようにすることです。言語を増やすと、両方の役割が広がります。翻訳されたインターフェースは完成しているように見えても、その背後のページ間では、どの URL が項目を表すのか、翻訳が存在するのか、検索エンジンがどのバージョンを考慮すべきかについて、情報が食い違っていることがあります。

Toolso は、多言語に対応した AI ツールの発見・公開プラットフォームです。この記事では、ソースコードのレビューと、2026 年 10 月 26 日に実施した少数の公開ページの確認に基づき、Toolso の言語別ルート、canonical URL、代替言語の注釈、sitemap のエントリがどのように連携するかを説明します。検索順位の改善を測定したものではなく、すべての掲載情報に、設定済みの全言語のコンテンツがあると仮定しているわけでもありません。

出発点として役立つのは、シンプルな問いです。同じツールが複数の言語で掲載される場合、アプリケーションの各部分は、それらのバージョンを一貫して記述できるでしょうか。この問いは、コンテンツ運用とテクニカル SEO を結び付けます。翻訳は単なるメニュー項目の追加ではありません。コンテンツ、ルート、メタデータの整合が必要です。

図1。英語版ホームページ。スクリーンショット提供日：2026年10月26日。

1. 言語別ルートと言語識別子を分ける

現在の設定では、英語、簡体字中国語、繁体字中国語、韓国語、日本語、フランス語、ドイツ語、ロシア語、スペイン語、ポルトガル語の 10 ロケールを定義しています。デフォルトは英語です。ルーティング設定では必要に応じて言語プレフィックスを付けるため、デフォルト言語には /en プレフィックスが不要で、それ以外のロケールにはプレフィックスを付けます。

実際の例として、Raphael AI の掲載ページは、英語で /tool/raphael、簡体字中国語で /zh/tool/raphael を使用しています。2026 年 10 月 26 日に両方のページを確認したところ、レンダリング後の canonical URL は、それぞれの言語版を指していました。

内部ルーティングキーと、検索エンジンに公開する言語識別子は分かれています。現在の設定では、zh を zh-CN に、tw を zh-TW に、es を es-ES に、pt を pt-BR に対応付けています。短い内部キーはルーティングに便利ですが、意味の異なる言語注釈として、そのまま使われるべきではありません。

ルーターでは自動ロケール検出も無効にしています。これにより、リクエストされたパスに含まれる言語が明確になります。ただし、ローカライズの完了を示すものではありません。ナビゲーションの翻訳、掲載コンテンツの翻訳、メタデータの正しさは、それぞれ別に確認する必要があります。

図2。Toolso の Raphael AI 詳細ページ。2026年10月26日に提供された画面で、製品のインターフェースを示すものであり、言語アノテーションの検証結果ではありません。

2. URL の識別情報を一つの仕組みで構築する

ページのメタデータと sitemap の生成処理が個別にアドレスを構築すると、URL の小さな違いが広がることがあります。あるコンポーネントはデフォルトロケールを省略し、別のコンポーネントは追加するかもしれません。また、あるものはドメインのルート末尾にスラッシュを残し、別のものは削除するかもしれません。それぞれを単独で見れば妥当に思えても、組み合わせた出力には不整合が生じます。

Toolso の canonical、hreflang、sitemap 用のヘルパーは、絶対 URL を構築する関数を共有しています。この関数は、ローカライズされたパスの生成を共通のルーティングロジックに任せ、ルートパスに統一した正規化ルールを適用します。この実装では、デフォルトのホームページ URL を末尾にスラッシュがない形式に正規化しています。これは整合性を保つための私たちの規約であり、すべてのウェブサイトがこの表記を選ぶべきだという主張ではありません。

メタデータのヘルパーは、ページ分割された URL のクエリ値にも対応しています。このオプションを指定すると、canonical と代替言語のリンクに同じクエリが追加されます。これにより、呼び出し側は 2 ページ目を別の言語の 2 ページ目に関連付けることができ、誤って 1 ページ目につなげるのを避けられます。それでも、各呼び出し箇所の確認は必要です。ヘルパーに機能があるからといって、すべてのルートで正しく使われているとは限りません。

canonical の注釈は、優先する URL を伝えます。Google がその URL を選ぶことを保証するものではありません。この違いは、Google の正規化に関するガイダンスで説明されています。

3. 実際に存在する翻訳で言語クラスターを決める

アプリケーションとして 10 ロケールに対応していることは、すべてのツールで 10 言語分の説明が完成していることを意味しません。両者を同一視すると、実際のコンテンツ以上の対応を約束する言語注釈を作ることになります。

私たちの言語リンク用ヘルパーは、利用可能なロケールの集合を受け取ります。呼び出し側がこの集合を渡すと、そのロケールだけに代替リンクを生成します。デフォルト言語版が利用可能な集合に含まれている場合に限り、そのバージョンを指す x-default の代替リンクを含めます。集合を省略すると、設定されている全ロケールを宣言するため、コンテンツの実際の提供状況を正確に渡すことが、呼び出し箇所の重要な責任になります。

ルーティング設定では、next-intl による代替言語の HTTP Link の自動出力を無効にしています。代わりに、ページのメタデータと sitemap のヘルパーを通じて、言語コードを対応付けた注釈を生成します。これにより、明示的な言語マッピングに加えて、生のルーティングキーから自動生成された別の注釈群を管理する事態を避けています。

結果はデプロイ後にも確認する必要があります。Raphael のサンプルでは、英語版と簡体字中国語版の両方のページが、同じ 10 個の代替言語リンクと x-default を宣言し、互いのページへのリンクも含んでいました。これが検証するのは、そのサンプルでレンダリングされた注釈であり、翻訳品質や検索インデックスへの登録ではありません。Google のローカライズされたページに関するドキュメントでは、言語コード、戻りリンク、x-default のフォールバックとしての役割が説明されています。

4. sitemap をコンテンツに基づく一覧として扱う

sitemap ジェネレーターは、存在し得るすべての言語 URL を簡単に生成できます。しかし、より有用な一覧は、実際に掲載条件を満たすコンテンツを反映するものです。

Toolso の sitemap ジェネレーターのツールデータクエリは、公開済みのツールを選択します。それとは別に、利用できる名前と有効な説明コンテンツを持つレコードから、利用可能な翻訳の集合を構築します。翻訳レコードはカーソルベースのバッチで読み込み、ジェネレーターはすべての説明をメモリにため込むのではなく、URL の組み立てに必要なロケール情報を保持します。

その後、利用可能なロケールに対してのみ、ツール詳細ページのエントリを生成します。ブログ詳細ページのエントリも同様に、各記事のロケール集合で絞り込みます。どちらも、sitemap 内の URL と代替言語のリンクに、共通の URL ヘルパーを使用します。したがって、データベースに言語用の枠があるだけでは、詳細ページのエントリを作る条件を満たしません。

更新日時にも注意が必要です。ツール詳細ページのエントリではコンテンツ更新を表す seoUpdatedAt フィールドを使用し、ブログのエントリでは対応するコンテンツ更新日または公開日を使用します。閲覧数の更新を毎回新しい編集上の改訂のように見せるのではなく、意味のあるコンテンツ変更を表すことが目的です。

これによって、生成されたすべてのエントリが現在の本番環境で正常だと確認できるわけではありません。sitemap の送信自体もヒントにすぎません。Google の sitemap に関するガイダンスも、クロールやインデックス登録を保証していません。

5. フォールバックコンテンツを明示的な状態にする

翻訳がない場合の方針が必要です。そうしなければ、同じ原言語の説明が複数の言語 URL の下に表示される一方で、サイトはそれらを完成した翻訳として提示してしまいます。

ツール詳細ページのメタデータには、明示的な翻訳フォールバックの分岐があります。フォールバックコンテンツを提供する場合、ページを noindex に設定し、canonical を英語版のツールページに向け、そのレスポンスでは代替言語クラスターを無効にします。翻訳データが一時的に利用できない場合や存在しない場合には、それぞれ別の処理があります。こうしたページを、翻訳に成功したページとして説明すべきではありません。

ブログ詳細ページの実装も、関連する方針に従っています。フォールバック時には記事の元の言語版を指し、代替言語のリンクを無効にし、noindex を使用します。アーカイブ済みのブログコンテンツも noindex に設定します。これらは、このプロジェクト固有の編集上・技術上の判断であり、すべての多言語ウェブサイトに同じルールを適用することを勧めるものではありません。

実務上の区別は、インターフェースの翻訳とコンテンツの翻訳の違いにあります。訪問者にはフォールバックへのアクセスが必要な場合もありますが、検索向けメタデータでは、それを独立した完成済みの言語版として提示すべきではありません。sitemap のコンテンツ提供状況によるフィルタリングも、詳細ページの動作と整合している必要があります。

6. 実装の確認と出力の検証を分ける

ヘルパーを読むことは有益ですが、訪問者やクローラーが受け取るのは最終的なレスポンスです。ミドルウェア、キャッシュ、データの提供状況、デプロイ済みのバージョンによって結果は変わります。したがって、コードレビューはレスポンスの確認の代わりにはなりません。

リポジトリには sitemap 監査スクリプトがあり、レスポンスステータス、robots 指示、canonical URL、さらにオプションで言語間の関係を確認できます。私たちはこのスクリプトをレビューし、二つの Raphael ページでレンダリングされたメタデータと、それらの sitemap エントリを確認しました。エントリの canonical URL と代替言語のリンクは、サンプルとして確認したページのものと一致していました。本番環境全体の監査は実行しておらず、Search Console も確認していません。

3 枚のスクリーンショットは、ホームページ、Raphael AI の掲載ページ、登録の開始画面を示しています。記録しているのは、撮影時点のインターフェースです。技術的な確認を再現するには、ある掲載ページについて、利用可能な二つの言語でレンダリングされた canonical と言語リンクを比較し、その URL を sitemap と照合します。URL と日付も記録してください。翻訳がない場合の動作は別にテストします。完成した翻訳とフォールバックでは、異なるアサーションが必要です。

Search Console での観察結果は別の記録に残します。Google が何をクロールしたか、どの canonical を選んだか、何がインデックスに登録されているかを記録します。アクセス解析やコンバージョンの数値も、さらに別の記録にまとめます。これらを分けておくことで、ローカルで行った実装の確認が、検索や売上の成果として語り直されるのを防げます。

ほかのディレクトリ開発者が活用できること

最も再利用しやすい考え方は、コンテンツの提供状況に基づいて URL の宣言を決めることです。ルーティングキーと言語コードを区別し、メタデータと sitemap の生成で URL 構築を共有し、翻訳がない場合には明示的な状態を設けます。そのうえで、検索パフォーマンスについて主張する前に、そうした設計意図を実際のレスポンスと比較します。

小規模なチームにとって、これは運用上の規律でもあります。新しい言語を編集ワークフローに加えるときは、コンテンツの状態を把握し、検証工程を設ける必要があります。小さなサンプルから不整合を発見することはできますが、ディレクトリ全体の対応状況を確認することはできません。ルーティングルールや翻訳の提供状況が変わったときは、URL クラスターを再確認してください。

図3。ツールの URL をインポートし、メディアが入力された登録画面。2026年10月26日に提供されたもので、最終的な登録完了を示してはいません。画像内の価格やカウンターは、撮影時点のインターフェース情報です。

多言語ディレクトリを構築している方は、次の問いを念頭に Toolso を見てみてください。各言語のページに有用なコンテンツがあるか。そして、その URL シグナルはコンテンツを正確に表しているか。