driver.js徹底解説｜依存ゼロ5KBで作るプロダクトツアーOSSと作者nilbuildの正体と使い方

GitHubで github.com/kamranahmedse/driver.js を開くと、URLが見慣れない nilbuild/driver.js に書き換わる。スター約2.6万、依存ゼロのプロダクトツアー定番ライブラリを探していた開発者の多くが、ここで一瞬手を止める。「乗っ取られたのか」「なりすましのフォークを踏んだのか」——名前が紛らわしいOSSにまつわる不安が頭をよぎるからだ。

結論から言えば、これは作者本人によるアカウント改名であり、nilbuild/driver.js は紛れもないオリジナルの driver.js そのものである。この記事では、まずその正体をGitHubの一次情報で確定させたうえで、依存ゼロ・約5KBという設計、最小実装からツアー・フックまでの主要API、Shepherd.js / Intro.js との違い、そしてSPA環境で踏みやすい落とし穴までを、公式リポジトリとドキュメントをベースに整理する。

UIライブラリの選定基準を体系的に押さえたい場合は、まず デザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】 を土台にすると、driver.jsのようなUXパーツがどの層を担うのかが俯瞰しやすい。

1. driver.jsとは何か——「ツアーライブラリ」ではなくフォーカス誘導エンジン

driver.jsを一言でいえば、「ページ上の任意の要素を強調表示し、そこに説明を添えるための小さなエンジン」だ。背景を暗く落とし（オーバーレイ）、対象要素だけをくり抜いてスポットライトを当て、その横にタイトルと説明文の入ったツールチップ（ポップオーバー）を出す。これがコア機能のすべてである。

多くの人は「プロダクトツアーのライブラリ」として認識しているが、作者自身はその枠を明確に否定している。READMEの該当箇所を引用する。

いや、これはツアーライブラリ以上のものだ。ツアーは数ある用途のひとつにすぎない。
原文：“No, it’s more than a tour library. Tours are just one of the many use-cases.”（driver.js README）

READMEは具体的な用途として、ユーザーが操作中のコンポーネントを強調して集中を促す、フォーム入力時に背景を暗くして文脈ヘルプを出す、視線を特定要素へ移すフォーカスシフター、動画プレイヤーでよく見る「消灯（Turn off the Lights）」演出、シンプルなモーダル、そしてもちろんプロダクトツアー——を挙げる。要するに 「ページに何らかのオーバーレイを被せたい」場面の汎用部品 だ。

公式のマスコットは、その性格をよく表している。

機能の核を支えているのが、依存ゼロ・軽量という設計思想だ。READMEは自らの軽さを、他ライブラリとのサイズ比較で強調している。

他のライブラリとサイズを比べても、driver.jsは最も軽量だ。gzip後でわずか約5KB、他は12KB超もある。
原文：“...it’s the most light-weight, it is just ~5kb gzipped while others are 12kb+.”（driver.js README）

この「約5KB」と「12KB超」という数字は、あくまでdriver.js公式の主張である点は割り引いて読むべきだが、依存パッケージがゼロでVanilla TypeScript実装という事実は、バンドルサイズとフレームワーク非依存の両面で効いてくる。Reactでも、Vueでも、素のHTMLでも、<script> 1本で同じものが動く。READMEが掲げる特徴を整理すると次のようになる。

2. nilbuild という名前の謎——作者Kamran Ahmedの改名を一次情報で確認する

この記事で最初に潰しておくべきは、「nilbuild/driver.js は本物か」という疑念だ。名前が有名OSSと紛らわしいリポジトリは、悪意あるなりすまし（タイポスクワッティングやアカウント乗っ取り）の温床になりうる。だからこそ、推測ではなくGitHubの一次情報で裏を取る。

調査の結果は明快だった。GitHub APIで repos/kamranahmedse/driver.js を叩くと、レスポンスの full_name は nilbuild/driver.js を返す。これはGitHubがアカウント改名時に旧URLを新URLへリダイレクトする挙動そのものだ。さらに nilbuild アカウントの実体を確認すると、決定的な証拠が並ぶ。

つまり、Kamran Ahmed氏がGitHubとX/Twitterの両方でハンドルを kamranahmedse から nilbuild へ変えた、というだけの話である。リポジトリの中身（コミット履歴・スター・npmパッケージ名 driver.js）はすべて連続しており、フォークでも別物でもない。

なお、npm上のパッケージ名は依然として driver.js（最新 v1.6.0）であり、import { driver } from "driver.js" というコードは改名前後で一切変わらない。インストール時にハンドル名を意識する必要はない。GitHubのURLだけが nilbuild/driver.js に変わった、と理解すればよい。

ちなみにKamran Ahmed氏は、AIエンジニアの学習地図としても定番の developer-roadmap の作者でもある。AIエージェントに一貫したUIを生成させる設計を学びたい読者には、関連文脈として design.mdとは？AIエージェントに一貫UIを生成させるデザイン仕様書の書き方入門 も合わせて読むと、「人間とエージェントの双方が踏み外しにくいUI部品」という観点が補完できる。

3. 30秒で動かす——最小実装とプロダクトツアー

理屈より先に動かす。driver.jsの導入はnpmなら1コマンドだ。

npm install driver.js
# pnpm add driver.js / yarn add driver.js でも可

最小構成は、driver() でインスタンスを作り、highlight() に対象要素とポップオーバーを渡すだけ。CSSの読み込みを忘れないのが唯一のつまずきポイントである。

import { driver } from "driver.js";
import "driver.js/dist/driver.css"; // これを忘れるとオーバーレイが素の見た目になる

const driverObj = driver();

driverObj.highlight({
  element: "#save-button",
  popover: {
    title: "ここで保存",
    description: "編集内容はこのボタンで保存されます。Esc でいつでも閉じられます。",
    side: "left",   // ポップオーバーを要素の左に出す
    align: "start", // 上端に揃える
  },
});

複数ステップを順に見せるプロダクトツアーにする場合は、driver() のconfigに steps 配列を渡し、drive() で開始する。showProgress: true を付けると「1 of 3」のような進捗が出る。

import { driver } from "driver.js";
import "driver.js/dist/driver.css";

const driverObj = driver({
  showProgress: true,
  nextBtnText: "次へ",
  prevBtnText: "戻る",
  doneBtnText: "完了",
  steps: [
    { element: "#editor",  popover: { title: "エディタ",     description: "ここに本文を書きます" } },
    { element: "#preview", popover: { title: "プレビュー",   description: "右側にリアルタイム表示されます" } },
    { element: "#publish", popover: { title: "公開",         description: "最後にここで公開します", side: "top" } },
  ],
});

driverObj.drive(); // ツアー開始（drive(2) のようにステップ指定での開始も可能）

これだけで、背景が暗転し、各要素が順にスポットライトされ、Next/Previous/Escでの操作とキーボードナビゲーションが効くツアーが完成する。steps の各要素は DriveStep 型で、element（セレクタ文字列・DOM要素・要素を返す関数のいずれか）と popover を持つ。popover 側で side（top/right/bottom/left）と align（start/center/end）を指定すれば、吹き出しの出る向きを要素ごとに制御できる。

4. アーキテクチャと主要API——Config・DriveStep・フックの全体像

driver.jsのコアは src/ 配下の小さなモジュール群で構成される。公開APIである driver() が、設定（config）・状態（state）・イベント（events）を束ね、ハイライト（highlight）→オーバーレイ（overlay）／ポップオーバー（popover）→配置計算（position）へと処理を流す。ソースを読むと、この責務分担がそのままファイル名に現れている。

driver(config) に渡せる主要オプションと既定値を、src/config.ts の configure() から抜き出すと次のとおり。既定で animate: true／allowClose: true／allowKeyboardControl が有効で、何も指定しなくても「アニメーション付き・Escで閉じられる・キーボード操作対応」のツアーになる。

driver.jsの真価は、状態遷移とイベントに差し込めるフック群にある。onHighlightStarted（描画直前）・onHighlighted（描画直後）・onDeselected（ハイライト解除直後）・onDestroyStarted / onDestroyed（破棄前後）といった状態フックと、onNextClick / onPrevClick / onCloseClick / onDoneClick というボタンイベントフックが用意されている。これらに分析イベントの送信や、次ステップへ進む前の非同期処理を挟める。

const driverObj = driver({
  animate: true,
  overlayOpacity: 0.7,
  stagePadding: 10,
  allowKeyboardControl: true,
  onHighlightStarted: (el, step, { state }) => {
    // 要素がハイライトされる直前。計測イベントの送信などに使う
    analytics.track("tour_step_shown", { index: state.activeIndex });
  },
  onNextClick: (el, step, { driver }) => {
    // 「次へ」を押したときの独自処理。明示的に進めるのを忘れない
    // 例: 非同期でデータ取得してから次へ
    driver.moveNext();
  },
  onDestroyed: () => {
    // ツアー終了後の後始末（フラグ保存など）
    localStorage.setItem("onboarding_done", "1");
  },
});

onNextClick のようなイベントフックを定義した場合、自動でのステップ送りは行われなくなる点に注意したい。フック内で driver.moveNext() を明示的に呼ぶ必要がある。これは「次へ進む前に必ずバリデーションを通す」といった割り込みを可能にするための設計だ。Driver インスタンスは moveNext() / movePrevious() / moveTo(index) / refresh() / getActiveIndex() / isLastStep() / destroy() などのメソッドを公開しており、外部のUIから手動でツアーを制御することもできる。

ツアー1ステップのライフサイクルを図にすると、フックがどのタイミングで発火するかが見える。

5. driver.js / Shepherd.js / Intro.js 比較——ライセンスと依存とサイズ

プロダクトツアー／オンボーディング系のOSSは複数あり、driver.jsはその中で「依存ゼロ・軽量・フレームワーク非依存・MIT」という象限に位置する。代表的な選択肢と並べて違いを整理する。選定で最初に効くのはバンドルサイズよりライセンスだ。商用プロダクトに組み込むなら、ここを外すと後で費用や再実装が発生する。

要点を補足する。Intro.js はツアーUIの老舗で機能は豊富だが、オープンソース版はAGPL系で、商用利用には別途有償ライセンスが必要になる。これが「とりあえず入れたら後でライセンス費用が問題化した」という事故の典型だ。Shepherd.js はMITで自由に使えるが、ポップオーバーの位置決めにFloating UI（旧Popper.js系）を内部依存として持つため、最小構成のバンドルはdriver.jsより大きくなりがちだ。react-joyride / Reactour はReactに特化していて状態管理との相性は良いが、React以外では使えない。

フレームワークに縛られないVanilla実装という性質は、設計面でも示唆がある。UIロジックを特定フレームワークから切り離し「替えられる部品」として扱う発想は、フロントエンドのクリーンアーキテクチャ完全解説｜依存の方向を制御してReactを「替えられる部品」にする設計論 で論じた依存方向の制御と地続きだ。driver.jsをドメイン層から薄いアダプタ越しに呼ぶ構成にしておけば、将来ツアーライブラリを差し替える余地も残る。

6. 実戦パターン——フォーム補助・フォーカスシフター・AIプロダクトのオンボーディング

driver.jsの応用は「ツアー」に限らない。READMEが挙げる用途を、実装パターンとして具体化する。

まずSPAでの動的要素への対処。React/Vueではルート遷移でDOMが差し替わるため、element にセレクタ文字列ではなく関数を渡し、解決を遅延させるのが定石だ。レイアウトが変わったら refresh() で位置を再計算する。

const driverObj = driver({
  steps: [
    {
      // 関数で返すと、ハイライトする瞬間まで要素解決を遅延できる
      element: () => document.querySelector("[data-tour='cart']"),
      popover: { title: "カート", description: "追加した商品はここに入ります", side: "bottom" },
    },
  ],
});

// レイアウト変更・ルート遷移後に位置を再計算
window.addEventListener("resize", () => driverObj.refresh());

次にReactでの安全な組み込み。useEffect でツアーを起動し、クリーンアップで必ず destroy() を呼ぶことで、アンマウント時のオーバーレイ残留を防ぐ。これはdriver.js自体がVanillaであっても、Reactのライフサイクルと素直に噛み合う。

import { useEffect } from "react";
import { driver } from "driver.js";
import "driver.js/dist/driver.css";

export function useOnboardingTour(enabled) {
  useEffect(() => {
    if (!enabled) return;

    const obj = driver({
      showProgress: true,
      steps: [
        { element: "#chat-input", popover: { title: "質問を入力", description: "ここにプロンプトを書きます" } },
        { element: "#model-select", popover: { title: "モデル選択", description: "用途に応じて切り替えます" } },
      ],
      onDestroyed: () => localStorage.setItem("ai_onboarding_done", "1"),
    });

    obj.drive();
    return () => obj.destroy(); // アンマウントで確実に破棄
  }, [enabled]);
}

この最後の例は意図的にAIプロダクトのオンボーディングを題材にしている。チャットUI・モデル選択・トークン上限といった「AIアプリ特有の概念」は初見のユーザーには分かりづらく、最初の数十秒で価値を伝えられるかが定着率を左右する。プロンプト入力欄やモデル切替を順に強調するツアーは、その典型的な処方箋だ。

さらに踏み込めば、AIコーディングエージェント自身にツアーを生成させるという使い方も現実味を帯びている。コンポーネントのセレクタとひと言説明さえ与えれば、steps 配列は機械的に組み立てられる。AIにUIを一貫生成させる土台づくりは Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き でも扱っており、driver.jsの宣言的な steps 構造は、エージェントが出力先として扱いやすい形をしている。デザインスキルをエージェントに教え込む発想は designer-skillsとは｜デザイン237スキルをClaude Codeに教えるOSSプラグイン集 も参考になる。

7. 導入時の注意点と既知の課題

driver.jsは小さく鋭い道具だが、万能ではない。本番投入で踏みやすい注意点を、設計の前提として押さえておく。

リポジトリの構成自体は現代的で、メンテナンスも継続している。src/ にコア、playground/ にAstro製のライブ例、tests/ にVitestのテストが置かれ、ビルドはVite、パッケージ管理はpnpm、リリースは release-it という構成だ。デフォルトブランチが main ではなく master である点（READMEやスクリプトのrawファイル取得時に効く）と、npm上に -next.0 のプレリリースタグが多数存在する点は、参照時の細かな注意として覚えておくとよい。

ローカルで挙動を試したい場合、READMEはplaygroundの起動手順を案内している。ライブラリをソースから直接importするため、src/ への変更が即座にホットリロードされる。

pnpm install
pnpm run playground:install
pnpm dev   # playground/ のAstroアプリが立ち上がる

各サンプルは playground/src/examples/ 配下の highlight.ts / popover.ts / tour.ts / api.ts にグループ分けされており、ここを読むのが実質的なリファレンスになる。公式ドキュメントの網羅度が気になる場合は、driverjs.com のデモと、この playground のソースを突き合わせるのが最短だ。

関連記事——UI・デザインから掘り下げる

driver.jsは単体のUI部品だが、「ユーザーをどう導くか」というUX設計や、AIにUIを生成させる文脈に置くと位置づけが鮮明になる。次の記事が深掘りに役立つ。

・デザインシステムとは？仕組み・構成要素・有名事例をエンジニア向けに整理する【2026年版】：UIパーツの設計思想を俯瞰する土台。driver.jsのようなUX部品がどの層に属するかが見える
・design.mdとは？AIエージェントに一貫UIを生成させるデザイン仕様書の書き方入門：エージェントに一貫したUIを生成させる仕様の書き方。ツアーのstepsをAIに組ませる発想と地続き
・designer-skillsとは｜デザイン237スキルをClaude Codeに教えるOSSプラグイン集：デザイン知識をエージェントに教えるアプローチ。オンボーディングUXの自動生成に応用できる
・Claude Design活用術：Figma・Canva AI・v0と徹底比較＋実用プロンプト集：UI生成ツールの比較。driver.jsで仕上げる「動き」の前段にあたるデザイン生成を扱う
・フロントエンドのクリーンアーキテクチャ完全解説｜依存の方向を制御してReactを「替えられる部品」にする設計論：Vanillaなdriver.jsを「替えられる部品」として組み込む設計の指針

まとめ——名前に惑わされず、軽さを取る

nilbuild/driver.js を開いて「乗っ取りか」と身構えた人は多い。だが正体は、developer-roadmapで知られる Kamran Ahmed 氏がGitHub/X両方のハンドルを nilbuild に改名した、というだけだった。リポジトリの中身もnpmパッケージ名 driver.js も連続しており、これは紛れもないオリジナルである。名前の紛らわしさは、一次情報を1つ確認すれば解ける。

道具としてのdriver.jsは、依存ゼロ・約5KB・Vanilla・MITという、いま選ぶ理由が明確なライブラリだ。ハイライトとポップオーバーという小さなコアに絞り、フックで挙動を差し込めるよう設計されているため、プロダクトツアーからフォーカス誘導、AIプロダクトのオンボーディングまで、フレームワークを問わず使い回せる。一方で、条件分岐や多言語、SPAの動的要素は自前設計が前提であり、ここを軽く見ると本番でつまずく。

プロダクトツアーやオンボーディングを「とりあえず軽く、フレームワークに縛られず、商用でも無償で」入れたいなら、driver.jsは2026年でも第一候補に挙げて差し支えない。

参照ソース

・nilbuild/driver.js — GitHubリポジトリ（MIT・スター約2.6万）
・Driver.js 公式ドキュメント・デモ（driverjs.com）
・driver.js — npm パッケージ（v1.6.0）
・Kamran Ahmed（nilbuild）— GitHubプロフィール
・kamranahmed.info — 作者個人サイト
・nilbuild/developer-roadmap — 作者の代表作（参考）