AIと2日間戦って、数十のファイルの修正を「捨てた」話。—— エッジ環境で10年死なない認証基盤を築くための外科的切断

はじめに

AIエージェントによる認証ライブラリの「つぎはぎ修正」で数十ファイルが汚染されました。
全削除してWeb Crypto API・Request/Responseを直接使うライブラリフリーの認証基盤に再構築することで、エッジ環境で10年動く設計に変えられます。

認証ライブラリの導入でこんなことありませんか？

開発スピードを上げるために、定評のある認証ライブラリをプロジェクトに導入しようとした。
しかし、エッジ環境特有の挙動やAIエージェントの誤った修正により、数十のファイルに及ぶ「つぎはぎ」コードが発生した。
パッチを当ててその場を凌いだが、ブラックボックス化したエラーは消えず、システムの生存性が著しく低下した。

この記事をお勧めしない人

ライブラリが提供する「魔法」を信じ続け、ブラックボックスの中身を理解せずに使い続けたい人。
「今動けばいい」を最優先し、5年後の保守性や複雑化した依存関係という負債に関心がない人。
自分には関係ないと思い、Web標準APIを直接操作することを「非効率な車輪の再発明」だと考える人。

もし一つでも当てはまらないなら、読み進める価値があるかもしれません。

AIエージェントが招く「増築の罠」と設計の崩壊

AIは「目の前のエラー解消」という部分最適には忠実だが、マクロな設計の歪みを無視する土壌ができる。
3回制止してもコード編集を止めないAIの暴走が発生し、プロジェクトの「構造の正しさ」が破壊されるきっかけとなる。
ついに誰も全体像を把握できない「増築の罠」に陥り、プロダクトの寿命が尽きる最悪のシナリオを招く。

Web標準への回帰という明るい未来

この記事を読めば、ライブラリという依存を捨て、環境に左右されない「10年死なない」認証基盤を築く明るい未来があります。
具体的には、Web Crypto APIやRequest/Responseを直接操る、Web標準のシンプルなコードの設計図を手に入れられます。
この方法は、本ブログ「ClaudeMix」の認証基盤をライブラリフリーで再構築した過程で実証済みです。
この情報の、流行を追うだけの記事では決して得られない、エッジ環境における究極の生存戦略です。

このブログもそうでした

筆者もライブラリの利便性に溺れ、数十のファイルの修正とAIの暴走という「依存関係の地獄」を経験しました。
この記事で、つぎはぎのコードを捨て去る「外科的切断」の判断基準と、明日から試せるWeb標準APIの実装Tipsを持ち帰れるように書きました。
プロダクトの延命を真剣に考える方は、詳細な実装方法を確認できます。

📝 概要・発生環境

本記事では、筆者が運営するRemix × Cloudflare Edgeのブログ「ClaudeMix」において、認証ライブラリを完全に廃止し、Web標準APIを用いた手動実装へと移行した「外科的切断」の記録を共有します。

実行環境

Framework: Remix (Vite)
Runtime: Cloudflare Workers
Database: Cloudflare D1
Session: Cloudflare Workers KV
AI Tool: Claude Code

「認証はコモディティであり、自前で作るのは悪」という定説を信じ、当初は実績のあるライブラリ（Remix Auth）を導入していました。しかし、これが地獄の入り口でした。

⚠️ 問題の発見と症状

ローカルでは動く、エッジで死ぬ

ローカルの開発環境（Node.jsベース）では完璧に動作していた認証機能が、Cloudflare Workersにデプロイした瞬間に牙を剥きました。

Error: isSession is not a function
    at ... (node_modules/remix-auth/...)

認証ライブラリが内部で依存しているパッケージがNode.js固有のAPIを期待していたり、CJS/ESMの混在による名前解決の失敗が発生。さらに、これらを解決しようとAIエージェントに修正を依頼した結果、事態はさらに悪化しました。

AIの暴走と「増築の罠」

AIはエラーを消すために、ポリフィルの導入、依存パッケージのバージョン固定、不自然な型定義のパッチを次々と提案してきました。3回「根本原因を特定して、安易なパッチは避けて」と制止したにもかかわらず、AIは「エラー解消」という部分最適に突き進み、気づけば数十のファイルに修正が及ぶ巨大な差分が生成されていました。

「動いているっぽい」が、誰も構造を説明できない。そんな「構造の不自然さ」という毒がプロジェクトを汚染し始めたのです。

🔍 調査と試行錯誤のプロセス

ライブラリの中身を疑う

当初はライブラリの設定ミスを疑い、数時間を設定変更に費やしました。しかし、どれほど設定を調整しても、エッジ環境という「物理法則」がライブラリの内部実装を拒絶し続けました。

AIによる「延命」の失敗

AIに依存関係の解決を任せた結果、以下のような「増築の罠」に陥りました。

vite.config.ts への不自然なエイリアス設定
依存ライブラリの内部ソースコードを直接修正しようとする試み
package.json の overrides 地獄

これらは一時的にエラーを消すかもしれませんが、将来的にライブラリをアップデートした瞬間に崩壊する、いわば「死の足場」でした。

💡 根本原因の特定

問題の根本は、「エッジファーストな時代において、Node.js前提の重厚な抽象化ライブラリを持ち込むこと自体が、構造的な矛盾であった」という点にありました。

環境の乖離 : ライブラリの依存先がWeb標準API（Workers Runtime）ではなく、Node.js APIを前提としていた。
AIの性質 : AIエージェントは「エラーを消す」という短期目標に極めて忠実であり、マクロな「保守性」や「設計の単純さ」を無視してでも部分最適に突き進んでしまう。
責任の所在 : 魔法のような抽象化は、問題が起きた時に「中身が見えない」という致命的なリスクを開発者に押し付ける。

🔧 解決策：外科的切断とWeb標準への回帰

私は2日間戦った末に、数十のファイルに及ぶ差分をすべて捨て去る「ブランチの削除」を決断しました。そして、ライブラリを一切使わず、 Web標準API（Request/Response/Cookie/Crypto）のみを用いた再実装を行いました。

1. 依存関係の外科的切断

まず、remix-auth および関連するStrategyパッケージをすべてアンインストールしました。これにより、ブラックボックス化されていた「魔法」を物理的に排除しました。

2. Web標準APIによるCookie管理

Cookieの署名と検証を、Node.jsに依存しない Web Crypto API を用いて実装しました。

// app/data-io/account/auth/cookie.server.ts (抜粋)
const encoder = new TextEncoder();

export async function sign(value: string, secret: string): Promise<string> {
  const key = await crypto.subtle.importKey(
    "raw",
    encoder.encode(secret),
    { name: "HMAC", hash: "SHA-256" },
    false,
    ["sign"]
  );
  const signature = await crypto.subtle.sign("HMAC", key, encoder.encode(value));
  return `${value}.${btoa(String.fromCharCode(...new Uint8Array(signature)))}`;
}

3. 軽量なセッション管理

セッションデータ自体はCloudflare Workers KVに保存し、ブラウザにはセッションIDのみを署名付きCookieとして保持させる、極めてシンプルな構造を採用しました。

🎓 学んだこと・まとめ

AI時代の「引き算」の重要性

AIはコードを増やすのは得意ですが、減らすのは苦手です。数十のファイルに及ぶつぎはぎコードが発生したとき、それを修正し続けるのではなく、「勇気を持ってブランチを消し、構造自体を引き算する」という決断は、人間にしかできません。

Web標準こそが最強の防衛拠点

ライブラリのバージョンアップに怯える日々は終わりました。HTTPプロトコル、Cookie、そしてWeb Crypto API。これら10年後も変わらない「Web標準」を基盤に据えることで、環境に依存しない、真に堅牢なシステムを構築できました。

今回の教訓

AIの「実装できました」を疑う眼力を持つこと。
「動く」ことよりも「説明できる構造」を優先すること。
エッジ環境では、重厚な抽象化よりも軽量なWeb標準APIを信じること。

同じような課題で悩んだ方はいませんか？
ライブラリに頼りすぎて、自分のコードを説明できなくなる恐怖を感じたことはありませんか？
もっと良い解決方法があれば教えてください！

「動いているコードを全削除して再実装する」という判断は、この認証リファクタリングだけではありません。StripeエージェントがSSoT違反のコードを「完了」と報告し、全削除を決断した事件でも同じ「引き算の意思決定」パターンが登場します。また、Cloudflare WorkersでのD1・KVを含む全インフラの設計はAIエージェントが壊さない開発環境設計で論じた「外部状態への依存ゼロ」という思想と連続しています。

🔗 関連リソース

Cloudflare Workers Web Crypto API Docs

MDN: Using the Web Crypto API