この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。架空のデータとブラウザの操作を使って、SortableJSの用途、仕組み、失敗時の観察ポイントを学びます。実在のサービスや個人情報へのアクセスは行いません。
検証ステータス： 2026-10-30までの既存審査で、公式資料と保存済みDaily Codeの固定ソースを照合し、Node.js構文検査の結果を記録しています。ブラウザ実操作、描画、CDN応答は未検証です。画面の説明はコードからの期待値であり実測と区別します。
| 項目 | 内容 |
|---|---|
| 対象 | Chrome/Edge/Firefox等の現代的なブラウザ（実機互換性は未確認） |
| 使用ライブラリ | SortableJS（教材内バージョン: 1.15.6） |
| 費用 | デモのソース自体に有料APIは不要。通信料金や利用条件は環境に依存 |
| データ | ページ内の架空データ。認証情報・位置情報・企業データ不要 |
| 学習操作 | ドラッグまたはボタンでタスクカードを完了に動かす |
なぜこの技術を試すのか
タスクの一覧はExcelの表でも作れますが、次にやることを直感的に移動させたい場合にはカード型の画面が役立ちます。SortableJSは要素をドラッグして並べ替える操作を手軽に加えられるライブラリです。ただしカードが動いたことと、サーバーに仕事の状態が保存されたことは同じではありません。今回は画面のDOMだけを操作する小さなかんばんを作り、「見た目の状態」と「データの永続化」を意識的に分けます。
動くサンプルを作るときは、見た目が動いたという事実だけで終わらず、「どの入力がどの変数を変え、どの処理が描画を更新したか」を区別する必要があります。今回の教材では、その変化を画面に明示します。実際のサービスへ取り込むときには、認証や保存の処理を別途設計してください。
まず試す：ライブデモと期待する結果
初期表示は「未着手」に「🔍 調べる」「🧪 試す」の2件、「完了」に「✅ 計画」の1件です。正常に初期化された場合、状態欄はSUCCESS: 未着手 2 / 完了 1と表示される想定です。「先頭を完了に移す」を1回押すと「🔍 調べる」が移動してSUCCESS: 未着手 1 / 完了 2、2回目は「🧪 試す」が移動してSUCCESS: 未着手 0 / 完了 3となる想定です。3回目は移動対象がなく、件数は変わりません。カードをドラッグして列間を移動する場合も件数が更新されます。同じ列の上下だけを入れ替えても件数は変わりません。ページを再読み込みすると初期状態へ戻る想定です。localStorageもバックエンドも実装されていないためです。
操作の前に確認すること
自分のPCがJavaScriptを実行できることを確認します。管理者権限は必要ありません。
ブラウザの開発者ツールを開き、Consoleでエラー、NetworkでCDN取得失敗がないか見る準備をします。
デモが公開されていない場合は、上記の
docs/demos/sortablejs-kanban/内のindex.htmlとapp.jsを同じフォルダへ保存します。READMEがあるweb/sortablejs-kanban/には実行用の2ファイルはありません。ターミナルでその保存フォルダへ移動し、Windowsならpy -3 -m http.server 8000 --bind 127.0.0.1、Linux/macOSならpython3 -m http.server 8000 --bind 127.0.0.1を実行します。ブラウザでhttp://127.0.0.1:8000/を開き、終了時はターミナルでCtrl+Cを押します。Pythonが利用できない環境では別のローカルHTTPサーバーが必要です。初期の
SUCCESSと2件/1件を確認してから、ボタンを1回、もう1回と押して件数を記録します。SUCCESSは初期化処理の到達を示すだけで、ドラッグやCDN配信の実機成功を保証しません。ブラウザで実際にカードが動くかを別に確認してください。
仕組みの全体図
flowchart LR
A["入力やクリック"] --> B["イベントを受ける"]
B --> C["SortableJS のAPI"]
C --> D["状態と描画を更新"]
D --> E["見た目と文字で確認"]
この図は学習用の概念図で、ブラウザ内部の実装やネットワーク通信の詳細を表したものではありません。ライブラリが何でも「操作がどの変数へ届くか」を追いかけることは共通です。
どう動いているのか：APIを読み解く
Sortable.createを列の要素へ適用すると、列内のカードをドラッグで並べ替えられます。groupで共通グループを指定した二つの列なら、列をまたいだ移動も許容されます。移動後のonEndで各列の子要素数を数え直し、画面の件数へ反映します。ここでは先頭のカードが動いても、もとのカードのテキストや識別子を勝手に書き換えません。複数のカードがある状態で見た目だけを数えるのは学習用として十分ですが、実務では不変のtask IDをカードに持たせる必要があります。
最小コードの読み方
for (const el of [todo, done]) {
Sortable.create(el, { group: 'tasks', animation: 160, onEnd: update });
}
上記は実際のapp.jsから構造を保って読みやすくした抜粋です。todoとdoneは前段でdocument.querySelectorによって取得した要素、updateは件数を再表示する関数です。単独実行する完成ファイルではありません。HTMLと実装一式はDaily Codeのdocs/demos/sortablejs-kanban/内にあります。onEndはドラッグ完了時にupdateを呼びます。一方、ボタン操作はdone.append(todo.firstElementChild)の後にupdate()を直接呼びます。
一条件だけ変更して比較する
実務で使う場合、onEndイベントから「カードID」「移動先の列」「順序」を読み取り、APIへ保存する方式を設計できます。ただしイベント発生直後に成功表示してはいけません。サーバーが保存を拒否した場合は、元の位置へ戻すか、未保存であることを明示する必要があります。ネットワークが切れても移動できるようにするのか、オンラインが必要なのかも要件として決めます。
まずapp.jsのanimation:160をanimation:0に一か所だけ変更し、ページを再読み込みしてドラッグの移動アニメーションを比較します。件数はどちらも2/1から始まり、カードを列間移動すれば1/2になる想定です。animationはミリ秒単位のアニメーション設定で、カードの保存先や件数を変える設定ではありません。比較後は160へ戻してください。ブラウザでの動作結果はまだ実測していません。
失敗したときにどこを見るか
ドラッグ操作だけではキーボード利用者がタスクを移動できません。サンプルには未着手の先頭1件を完了へ送るボタンだけを用意し、進捗件数をrole="status"で通知します。任意のカードの選択、完了から未着手への移動、キーボードでの並べ替え、取り消しは未実装であり、完全なアクセシビリティ対応とは呼べません。実サービスではフォーカス管理も含めて別途実装・試験してください。また、DOMのテキストをそのままタスクIDにする設計は、同名タスクが出た瞬間に曖昧になるので避けてください。
| 観察した状態 | 切り分ける点 | 対応の例 |
|---|---|---|
| 画面が初期状態から変わらない | スクリプト取得・初期化・イベント登録 | Console / Network / scriptタグを確認 |
| 表示が変わるが意味が合わない | 入力値・配列・単位・更新対象 | 値を固定して一条件ずつ確認 |
| ボタンを押せない | セレクターとDOM生成順序 | idが一致するかHTMLを確認 |
| 一部の端末だけ動かない | ブラウザ機能、権限、CDN、性能 | 端末とバージョン、再現操作を記録 |
ブラウザ内でのエラーと公開Webサーバーの障害は別です。前者は開発者ツールのエラー内容、後者はHTTPレスポンスやアセットの配信条件から調べます。未知の失敗を成功と表現しないことが、技術メモの信頼性を高めます。
業務・学習への応用
障害対応の進捗管理、原稿の編集ステージ、サンプルのレビュー待ち、軽いチーム作業などに応用できます。監査証跡が必要な業務では、ブラウザのDOMだけでなく、更新者・更新時刻・変更前後をサーバーに記録することが欠かせません。見栄えと業務要件の境界を意識することが、この小さなデモの実務的な学びです。
導入前に決めること
読者へ公開するとき、表示したデータがどこから来るか、誰が変更できるか、画面へ残る情報の種類、ライブラリ更新時の確認項目を決めます。今回のデモにはログインもサーバー保存もありません。そこで運用機能を追加する前に、まず「想定どおり表示される最小部分」と「実務上の信頼性・権限・バックアップが必要な部分」を区別することを勧めます。第三者CDNは外部通信のため、企業ネットワークで許されるか事前確認が必要です。
別方式と比較する
| 方式 | 向く場面 | 注意点 |
|---|---|---|
| SortableJS | ドラッグまたはボタンでタスクカードを完了に動かすなど目的に合う場面 | 依存ライブラリの更新・利用条件の管理が必要 |
| ブラウザ標準API | 小さな機能を自前で作る | 仕様や互換性を自分で確認する |
| 静的画像・表 | 操作を必要としない説明 | 状態の変化をその場で体験できない |
ライブラリは必要なときに選ぶ道具です。何を達成したいかと学習コストを合わせて比較します。「ライブラリを入れること」を目的にしない方が、小規模なページでは保守しやすくなります。
GitHubサンプル
ブログ本文は背景や考え方、Daily Codeは実行・改造するためのコード、という役割を分けています。外部サービスへ投稿・保存するAPIは含めません。
公式情報・一次情報
資料確認範囲： 2026-10-30にSortableJS公式READMEのgroup/onEndとMDNのドラッグ操作・キーボード代替の説明を再確認しました。CDNアセットの実ロードとブラウザ操作は未確認です。
検証範囲の補足
Daily Codeの固定コミットと既存のNode.js構文検査結果を参照できます。ただし実ブラウザの画面表示、ライブラリCDNの応答、全端末での動作は未確認です。実際の動作は読者の環境でConsoleとNetworkを利用して確かめてください。
