「自作の機能」を排除せよ：モダンな Web デザインへの不満と提言

Susam Pal 氏による投稿（2026 年 5 月 23 日）

本稿は、現代の Web デザイン手法に対する不平（rant）です。Web ユーザーとしての体験に基づき、開発者が避けるべき「自作（roll their own）」すべき機能を列挙し、その理由を論じます。

---

📜 「自作しない」の原則：暗号学から Web デザインへ

セキュリティ分野では有名な格言**「自作の暗号を使くな（Don't roll your own crypto）」**があります。

• 意味: 誰もコードを書き禁止されているわけではなく、必要のある人への支援はあります。
• 要約: ユーザーデータを保護するプロダクションソフトウェアにおいて、非公開で未検証の実装に依存すべきではありません。
• 推奨: 確立され、ピアレビューを受け、十分に審査されたパッケージやツールを使用してください。

かつての独自開発 RC4 実装（初期化ベクトル問題、ストリーム予測可能性など）による悲劇から学ばれ、現在は大手 EC サイトや銀行などでも自作の暗号使用はほぼ見られなくなりました。規制対象分野ではこれに抵触すると大規模な制裁を受けるリスクがあります。

Web デザインも同様に、「スクロールバーが壊れることは暗号方式の失敗と同等の重大事態ではないか」という批判もありますが、ユーザーが日常的に依存する機能において**「開発者が X を自作すべきではない」**という原則は通用します。

---

🚫 自作してはいけない機能一覧（X）

日常業務を行うための Web サイトにおいて、以下の機能を実装せず、ブラウザのデフォルト挙動を引き継ぐべきです。

• ページスクロール挙動
• リンクによるナビゲーション
• テキスト選択機能
• コンテキストメニュー（右クリックメニュー）
• クリップボードへのコピー・貼り付け機能
• パスワード入力フィールド
• 日付選択ボックス（DatePicker）

免責事項: 本稿はデザインガイドラインではありません。Web ユーザーとしての嘆きであり、専門家の推奨事項ではないことに留意してください。ただし、以下に挙げる不満点は多くの利用者にとって共通するものです。

---

💬 各機能に関する具体的な不満と理由

1. カスタムスクロール挙動 ❌

ユーザーはマウス、タッチパッド、キーボードでの自然なスクロールを熟知しています。

• 問題: ブラウザデフォルトを上書きするとページが「壊れた」ように見えます。
  • スクロール速度の不均衡（速すぎたり遅すぎたり）。
  • キーボード操作の不安定さ。
• 結論: 慣れ親しんだ挙動を、未熟な実装に変えてはいけません。

2. カスタムリンクナビゲーション ❌

Web ブラウザがリンク処理に特化しており、「命綱（bread and butter）」です。

• 問題: GitHub などでのクリック時に巨大な JavaScript ブロックがトリガーされ、読み込みに時間がかかります。
  • 場合によっては、新しいタブで開く方が圧倒的に速いことがあります。
• 確認方法: 以下の手順で開発者ツールを確認してください。

  1. 任意の GitHub プロジェクトへアクセス。
  2. ブラウザで F12 を押し、開発者ツール（Debugger / Sources）を開く。
  3. サイドバーの「Event Listener Breakpoints」を拡大。
  4. 「Mouse」から「click」を選択してイベントを設定。
  5. リンクをクリックし、トリガーされる処理を確認。
  

• 提言: 「正常なリンクナビゲーションを妨げるほど重要なのか？」を再考してください。

3. カスタムパスワード入力フィールド ❌

ブラウザ標準の

<input type="password">

は十分に機能しています。

• 標準機能:
  • パスワード保存・埋め込みの提案。
  • 強力なパスワード生成（新規アカウント）。
  • 非安全な HTTP 接続での認証情報の警告。
  • パスワードマネージャーやオートフィルとの連携。
  • アクセシビリティツールとの互換性。
• リスク:
  • 自作バージョンで置き換えると全機能が失われます。
  • 単にテキストフィールドをマスクしただけの場合、OS や支援ツールが「通常の可視テキスト」とみなし、パスワード漏洩のリスクが高まります。

4. カスタム DatePicker ❌

ユーザーはどこでも同じ方法でカレンダーを操作したいです。

• 現状の問題: 10 のサイトがあれば 10 の使い方を覚える必要が生まれます。
  • 年へ移動するために月表示を縮小するなどの不合理な UI。
  • 「前年度ボタン」を数十回クリックしないと日付を選べない実装。
  • 入力自体を受け付けないケース。
• 提言: カレンダーウィジェットはネイティブ機能に追加せず、隣接して配置すべきです。

  <!-- 推奨構成例 -->
  <input type="date">
  <!-- カスタム表示が必要な場合のみ横に追加 -->
  

---

🧠 より広範な提言：フォームコントロールと変化の速度

フォームコントロールへの介入をやめるべき

• 既存の問題解決を試みることは、ほぼ常に新たな問題を引き起こします。
• UI/UX を頻繁に変更（数ヶ月ごと）すべきではありません。
  • 新技術に適応するのは可能でも、高齢者や他の利用者はそうなりません。
  • UI が変更されるたびに「全く新しい道具の学習コスト」が発生し、社会的な負担になります。

ユーザー体験への配慮

• 比喩: Linux コマンドラインオプションが数ヶ月で変わるのを強制するのは同義です。洗濯機のボタン配置が毎日変わる状況も想像してください。
• 結論:それは愉快なものではありません！ユーザーの学習時間を尊重し、安定した Web エクスペリエンスを提供してください。