4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@sakutto-panda(サクッとぱんだ)

『ChatGPTに聞けばいい時代』にチートシート逆引きツールを14本作った理由。LLMでは代替できないUXの話

4
Posted at

ぱんだツールズという無料 Web ツール集には、チートシート系の逆引きツールが14本入っている。

ツール 引きたいもの
シェルコマンド検索 Linux / cmd / PowerShell の同等コマンド
正規表現構文検索 JavaScript / Python / Go / Java / PCRE の方言差
SQL方言検索 MySQL / PostgreSQL / SQLite / SQL Server の SQL 差
CI/CD設定検索 GitHub Actions / GitLab CI / CircleCI / Jenkins の文法差
パッケージマネージャ検索 npm / yarn / pnpm / pip / cargo / go の同等コマンド
エディタショートカット検索 VS Code / Vim / Emacs / IntelliJ
OSショートカット検索 Mac / Windows / Linux
キーボード記号検索 キー名 ↔ 記号（⌘・⌃・⇧・⌥...）
日時フォーマット検索 strftime / Java SimpleDateFormat / Go time
デプロイプラットフォーム検索 Vercel / Cloudflare / Netlify / AWS の比較
スプレッドシート関数 Excel / Google Sheets の関数
SNS投稿仕様 X / Instagram / TikTok / YouTube の画像サイズ
Cron式エクスプレイナー Cron 式の解読
用紙サイズリファレンス A判 / B判 / 米国レターなど

ツールを作っている最中に何度も浴びた質問がある。

「ChatGPT / Claude に聞けば全部出るのに、なぜ作るのか？」

実際、ここに並んでいるツールの内容はすべて LLM に聞けば1問ずつは解決する。にもかかわらず、ぱんだツールズ全体が1ヶ月運用したタイミングで、GSC では「codex スラッシュコマンド」のような開発者向けチートシート寄りのロングテールクエリで実際にクリックを拾い始めている。チートシート系ツール群はその表示の中核を担っている。

この記事は、LLM 時代にそれでもチートシートツールが消えない理由と、ぱんだツールズで14本のチートシートツールを作るときに採用した設計パターンの話。

LLM があってもチートシートが消えない4つの理由

1. 「3秒で引きたい」を満たせない

正規表現の \b がどのエンジンで使えるか、たとえばこれを LLM に聞くなら：

「\b はJavaScript・Python・Go・Java・PCRE でそれぞれ使えますか？」

と打ち込んで、3〜10秒待って、回答を読む。所要時間20秒くらい。

一方、チートシート系ツールなら、

  1. ブックマークから開く（1秒）
  2. 検索ボックスに \b と打つ（1秒）
  3. 5エンジンの対応状況が表で並ぶ（即座）

3秒で終わる。

「コードを書いている最中の集中を切らさず、5秒以内に答えが返る」UX は、LLM のチャットインタフェースでは難しい。プロンプトを考える時点でフロー状態が崩れる。

2. 「横断比較」を一覧で見られる

LLM は1問1答が基本。「Mac の Cmd+L は何のショートカット？」と聞くと答えるが、「同じことを Windows / Linux でやるには？」と聞き直す必要がある。チートシートなら最初から3列で並んでいる。

シェルコマンド検索の例：

export interface CommandEntry {
  id: string
  category: CommandCategory
  difficulty: Difficulty
  purpose: string
  tags: string[]
  linux: ShellCommand       // ← 3 OS が
  cmd: ShellCommand         // ← 1 エントリに
  powershell: ShellCommand  // ← 並列に入る
  comparisonNote?: string
}

データ構造の時点で「3つの環境を横並び比較する」ことが前提になっている。LLM とのチャットを何往復もやって自分でテーブルに整理するのと比べると、認知コストが桁違いに低い。

3. 公式ドキュメントへの確信ある導線

LLM の回答は、ハルシネーションのリスクがゼロではない。特に正規表現や SQL 方言のように「仕様の細部」を扱う質問は、誤情報が混じりやすい領域。

チートシートツールでは、各エントリに docUrl を必ず持たせている：

function sh(command: string, syntax: string, example: string, exampleDesc: string, docUrl: string, note?: string): ShellCommand {
  return { command, syntax, example, exampleDesc, docUrl, note, available: true }
}

const linuxDoc = (cmd: string, section = 1) =>
  `https://man7.org/linux/man-pages/man${section}/${cmd}.${section}.html`

man7.org の man ページ、Microsoft Learn の PowerShell リファレンス、PCRE の公式ドキュメントなど、最終的に必ず一次資料に飛べるようにしている。LLM の回答ベースで判断するより信頼度が一段高い。

4. オフライン・ネットワーク不安定でも動く

機内、地下鉄、海外のホテル Wi-Fi。「LLM に聞けばいい」が成立しないシーンは意外に多い。

ぱんだツールズのチートシートツールはすべて静的データ（TypeScript の配列）をそのままバンドルしているので、初回ロード後はネットワーク不要で動く。Service Worker でキャッシュさせれば完全にオフラインで使える。

LLM は便利だが、回線がないと完全に無力。地味だが大きな差。

14本のツールに共通するデータ構造

14本のチートシートツールは、構造を共通化している。だから増やすコストがツール3〜4本目から劇的に下がった。

1. 「比較対象」を1エントリに並列に持つ

シェルコマンド検索なら、Linux / cmd / PowerShell を1エントリに並列に持っている。SQL方言検索なら4方言、正規表現構文検索なら5エンジン。

シェルコマンド検索で「ls」を引いた結果。Linux (bash) / cmd / PowerShell の3列で、構文・例・公式ドキュメントリンクがそれぞれ表示される

「ls の Windows 版って何だっけ」を引きたいときに、3つのコマンド（ls / dir / Get-ChildItem）が1画面で揃う。データ構造は TypeScript で書くとこう：

// regex-syntax-search
export interface RegexSyntaxEntry {
  id: string
  category: RegexCategory
  purpose: string          // 「単語境界」のような目的
  tags: string[]
  javascript: RegexSyntax  // ← この5つが
  python: RegexSyntax      //   1エントリに
  go: RegexSyntax          //   並列に並ぶ
  java: RegexSyntax
  pcre: RegexSyntax
  comparisonNote?: string  // 方言差の補足
}

UI 上は「正規表現の \b（単語境界）はこの5エンジンでこう書く」という1行のテーブルになる。データ構造が UI を直接駆動する。

2. 「対応していない」をデータの第一級市民として扱う

シェルコマンドには「Linux にあるけど cmd にはない」コマンドがたくさんある。これを「PowerShell にも対応コマンドがある」と無理に書くと、嘘が混じる。

function sh(...): ShellCommand {
  return { command, syntax, example, exampleDesc, docUrl, note, available: true }
}

function na(note?: string): ShellCommand {
  return { command: '-', syntax: '-', example: '-', exampleDesc: '直接対応するコマンドなし', docUrl: '', note, available: false }
}

available: boolean を持たせて、「対応するコマンドはない」という事実を明示的にエンコードしている。UI 側でグレーアウト表示にするだけでよい。

「対応していない」を1級市民として扱うと、LLM に聞いたときに起きがちな『無理に答えをひねり出す』問題が起きない。チートシートとしての正確性が上がる。

3. tags 配列で検索を寛容にする

各エントリに tags: string[] を持たせて、ユーザーが打ちそうな表現を網羅的に書いておく。シェルコマンド検索の ls エントリならこんな感じ：

{
  id: 'list-files',
  category: 'file',
  difficulty: '基本',
  purpose: 'ディレクトリの中身を一覧表示',
  tags: ['ls', 'dir', '一覧', 'リスト', 'ディレクトリ', 'フォルダ', '中身', '表示'],
  linux: sh('ls', 'ls [-la] [path]', 'ls -la', '隠しファイルも含めて詳細表示', linuxDoc('ls')),
  cmd: sh('dir', 'dir [path]', 'dir /a', '隠しファイルも含めて表示', cmdDoc('dir')),
  powershell: sh('Get-ChildItem', 'Get-ChildItem [-Force] [path]', 'Get-ChildItem -Force', '隠しファイルも含めて取得', psManagement('get-childitem')),
}

「ls の Windows 版」「フォルダ 中身 表示」「dir 隠しファイル」のどれで打ち込んでも、同じエントリにヒットする。

検索ロジック自体は単純な「全フィールド連結 + 部分一致」だが、tags を厚く書いておくとユーザーの語彙の揺れを吸収できる。LLM に聞くときに起きる「うまく言語化できない」摩擦が、検索ボックスでは起きない。

サイト独自性として効いた

「LLM があれば全部解決する」と最初は自分でも思っていた。1ヶ月運用してわかったのは、それでもチートシートツールには指名検索もロングテール検索も入るということ。

GSC を見ると、/tools/ai-cli-commands（AI CLI チートシート）には「codex スラッシュコマンド」のクエリで月50回弱の表示がある。これは LLM への質問方法すら、LLM ではなく検索エンジンで調べているということ。

チートシートツールは、LLM 時代の「補助線」として残ると考えている。

  • LLM は 未知の問題を解く のに強い
  • チートシートは 既知の知識を即座に引く のに強い

両方の用途は重ならない。LLM が普及するほど、「LLM に聞くまでもない調べごと」が顕在化する。そこをチートシートツールが拾う。

まとめ

チートシート系のツールは、LLM があっても消えない。むしろ LLM 時代の「即引き」ニーズの受け皿として強くなる。

設計のコツは3つ：

  1. 「複数の対象を1エントリに並列に持つ」データ構造で、横断比較を UI に直結させる
  2. 「対応していない」を1級市民で扱う（available: boolean を持つ）
  3. tags 配列でユーザーの語彙ゆれを吸収する

正規表現の方言差は、LLM に聞き直すよりこちらが速い：

ぱんだツールズ では他にもファイル変換・画像処理・PDF処理など80以上のツールを公開中。すべて無料・登録不要・ブラウザ完結で動く。
https://sakutto-panda.com

この記事は Zenn にも同じ内容を投稿しています。

4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?