ぱんだツールズという無料 Web ツール集を運営している。1ヶ月で公開ツール数が80を超えた。
ツールが増えるほど顕在化する問題がある。ユーザーが「どのツールを使えばいいかわからない」状態になること。
検索エンジン経由で個別ツールに直接ランディングする人は問題ない。問題は「ぱんだツールズに来たけど、何があるかぼんやりしか把握していない」状態の訪問者。トップページからツール一覧に行っても、80個並んでいたら目的に辿り着くまで時間がかかる。
この問題を解くために、ぱんだツールズには2つの「逆引きツール」が置いてある。
| ツール | 引き方 | 出力 |
|---|---|---|
| ファイル変換ナビ | 「○○ → ××」の変換から引く | 該当する変換ツールへの導線 |
| ファイル形式ガイド | 「JPEG とは？」のような形式情報から引く | フォーマットの説明 + 関連ツール |
この記事は、ファイル変換ナビをどう設計したか、サイトの規模が増えたタイミングで「逆引き」を作ると何がいいかの話。
なぜ「カテゴリ別一覧」だけでは足りなかったか
最初は、トップページとカテゴリ別一覧（PDF / 画像 / CSV / テキスト / 開発者ツール）だけでツール導線を作っていた。これはサイトを作った側の頭の中の構造で並んでいる。
でも訪問者の頭の中はそうではない。
| 訪問者の頭の中 | 既存の導線でのアクセス |
|---|---|
| 「PDF を JPEG にしたい」 | PDFカテゴリ → 並ぶPDFツール群から「PDF→画像変換」を見つける |
| 「HEIC が開けない」 | 画像カテゴリ → 10数個の画像ツールから「HEIC→JPEG」を見つける |
| 「CSV が文字化けした」 | CSVカテゴリ → CSV/Excelツール群から「文字コード変換」を見つける |
3クリック以上必要で、しかも各カテゴリに10個前後のツールが並んでいる中から正しいツールを選ばないといけない。「やりたいこと」と「ツール名」が一致しないと辿り着けない設計になっていた。
「PDF を画像にしたい」訪問者が「PDF→画像変換」というツール名にたどり着くまでに、PDFカテゴリ・画像カテゴリの両方を見ることもある（どっちのカテゴリに入ってるか想像がつかないため）。
これを解くために、「変換の方向（from → to）」をキーにしたデータベースを作って、検索で引けるようにした。それがファイル変換ナビ。
データ構造：「変換パス」を1レコードとして持つ
ファイル変換ナビのデータは、TypeScript の配列として fileConvertNaviData.ts に持っている。
export interface ConvertEntry {
id: string
fromLabel: string // 「PDF」
fromExt: string // 「.pdf」
fromCategory: FormatCategory // 'pdf' | 'image' | 'csv' | 'text' | 'file'
toLabel: string // 「JPEG / PNG」
toExt: string // 「.jpg / .png」
toCategory: FormatCategory
toolSlug: string // 'pdf-to-image'
toolName: string // 'PDF→画像変換'
description: string // 検索対象の説明文
tags: string[] // 検索対象のタグ
note?: string
}
肝になっているのは「ツール1個に対してエントリ1個ではなく、変換パス1個に対してエントリ1個」にしたこと。
たとえば PDF まわりは PDF→画像 / PDF→テキスト / PDF→PDF（圧縮）/ PDF→PDF（結合）/ PDF→PDF（分割）/ PDF→PDF（透かし追加）/ PDF→PDF（ページ番号追加）のように、複数の変換パスに分かれる。これを1レコードずつ持つ。
現時点でエントリ数は32件。ツール数（80超）より少ないのは、変換以外のツール（QRコード生成、パスワード生成、JWTデコーダなど）はナビ対象外にしているため。「変換」というユースケースにスコープを絞ったから、データ構造がシンプルに保てている。
検索の実装：全フィールド連結 + 部分一致
絞り込みは2軸でやっている。
const filtered = useMemo(() => {
const q = searchQuery.trim().toLowerCase()
return convertEntries.filter((entry) => {
// 1. カテゴリフィルタ（from / to のどちらかが一致）
if (categoryFilter !== 'all' && entry.fromCategory !== categoryFilter && entry.toCategory !== categoryFilter) {
return false
}
// 2. キーワード検索（全フィールド連結 + 部分一致）
if (q) {
const searchText = [
entry.fromLabel, entry.fromExt,
entry.toLabel, entry.toExt,
entry.toolName, entry.description,
...entry.tags, entry.note ?? '',
].join(' ').toLowerCase()
if (!searchText.includes(q)) return false
}
return true
})
}, [searchQuery, categoryFilter])
シンプルに「全フィールド連結 → 部分一致」で済ませている。FlexSearch などの検索ライブラリも検討したが、32件のエントリに対して全文検索エンジンは過剰だった。ブラウザ上で配列を filter で回すだけで十分速い。
タグフィールドの設計が地味に効いている。['pdf', 'jpeg', 'png', '画像', '変換', 'ページ', 'エクスポート'] のように、訪問者が打ちそうなクエリ語を網羅的に書いておく。これでツール名・説明文に出てこない単語（「エクスポート」「軽くする」など）でも引っかかる。
ファイル形式ガイドとの役割分担
もう一つの逆引きツール「ファイル形式ガイド」は、形式そのものを引くためのツール。「JPEG とは？」「WebP は何が違う？」「HEIC が開けないのはなぜ？」のような疑問に答える側。
データ構造はこうなっている：
export interface FileFormatEntry {
id: string
format: string // 'JPEG'
extension: string // '.jpg'
category: FormatCategory // 'photo' | 'graphic' | 'document' | 'data' | 'archive'
mimeType: string // 'image/jpeg'
description: string
features: {
transparency: boolean
animation: boolean
lossless: boolean
compression: '非圧縮' | '可逆' | '非可逆' | '両対応'
maxColors: string
browserSupport: 'すべて' | 'ほぼすべて' | '一部' | '非対応'
fileSize: '小' | '中' | '大' | '可変'
}
bestFor: string[]
notRecommended: string[]
convertTools: { slug: string; name: string; action: string }[]
technicalDetails: string
tags: string[]
}
「変換ナビ」と「形式ガイド」は別ツールだが、convertTools フィールドで相互リンクしている。 JPEG のページから「JPEG→PNG変換ツールへ」のような動線がある。
| ツール | 引き方 | 引いた後の終着点 |
|---|---|---|
| ファイル変換ナビ | やりたい変換から | 該当ツールへ |
| ファイル形式ガイド | 形式の疑問から | 形式の説明 + 関連ツール |
検索動機が違うので分けている：
- 「HEIC を JPEG に変換したい」→ 変換ナビが正解
- 「HEIC ってそもそも何？開けない場合の対処は？」→ 形式ガイドが正解
両方とも最終的にツールページへ送り込むという目的は同じ。入り口を変えているだけ。
SEO 的な副次効果
逆引きツールはユーザーの迷子対策で作ったが、副次効果として SEO 流入も拾えている。
GSC を見ると、変換ナビ・形式ガイドが拾っているクエリには2種類ある。
1. 変換クエリ
- 「pdf jpeg 変換」「heic jpeg 変換」「csv to json」のような変換意図のクエリ
- 既存の個別ツールページでも拾えるが、「複数の変換を試したい」訪問者には変換ナビの方がフィットする
2. 比較・違いクエリ
- 「png jpeg 違い」「webp 変換 メリット」のような知識系クエリ
- これは形式ガイドの方が刺さる
個別ツールページだけだと「使い方」のクエリしか拾えない。ナビ・ガイド系のページを足したことで、検討前段階のクエリにも露出できるようになった。
訪問者の検討フェーズと、それぞれに対応するページを整理するとこうなる：
| 検討フェーズ | クエリ例 | 適合するページ |
|---|---|---|
| 「そもそも何？」 | 「heic とは」 | 形式ガイド |
| 「どっちがいい？」 | 「png jpeg 違い」 | 形式ガイド or ガイド記事 |
| 「変換したい」 | 「heic jpeg 変換」 | 変換ナビ or 個別ツール |
| 「使う」 | 「heic jpeg 変換 ツール」 | 個別ツール |
ナビとガイドは検討初期〜中期、個別ツールは検討後期、と棲み分けている。
設計してよかったこと
1. ツール追加が「データ追加」だけで済む
ナビと形式ガイドは、データさえ書き足せばコンポーネントは書き換え不要。新しいツールを追加するときの作業が、
- ツールの実装
- ナビのエントリ1件追加（変換パスがある場合）
- 形式ガイドの
convertToolsに追記（関連がある場合）
の3ステップで終わる。サイト全体の導線設計を毎回触らずに済む。 今後ツール数が100、200と増えても、データを増やすだけで対応できる。
2. 「ぱんだツール」指名検索の受け皿になる
GSC の流入クエリを見ると「パンダツール」「ぱんだツールズ」のような指名検索がある。指名検索で来た人は、サイトの全体像を見たい状態が多い。トップページに直接ランディングするより、変換ナビ・形式ガイドのような全ツール俯瞰系のページに着地する方が回遊が伸びる。
3. 「自分のサイトの中で迷う」のがあほらしいと気づける
開発者は自分のサイトの構造を頭の中に持っているので、迷子にならない。だから「迷子問題」は自分では発見できない。ツール数が30を超えたあたりから、開発者でも自分のサイトで一瞬迷うようになる。 その瞬間が「逆引き」を作るタイミング。
学び
ツール数が増えるサイトで、カテゴリ別一覧だけに頼らない導線を1本足すと、UX も SEO も両方改善した。
設計のコツは「ツール1個 = レコード1個」にしないこと。 ユーザーのユースケース（変換パス・知りたい形式）を1レコードにすると、ユーザーの頭の動きに沿った検索ができる。
形式ガイドの方は、画像・ドキュメント・データなど主要フォーマットの「特徴・向いている用途・避けるべき用途・関連ツール」をデータ駆動で網羅している。技術記事を書く前のリサーチ用途にも使える。
ぱんだツールズ では PDF・画像・CSV・テキスト処理など80以上のツールを公開中。すべて無料・登録不要・ブラウザ完結で動く。
https://sakutto-panda.com
この記事は Zenn にも同じ内容を投稿しています。