認証は1日で作れる——それが落とし穴です。
多くの B2B チームが同じ物語を語ります。始まりはただのシンプルなログイン画面。でも実際に利用されると、それは静かに ID インフラへと成長し、あなたのプロダクトの基盤となっていきます。
一つの機能だと思ったら、気づけば巨大な ID モデルだった
どんな自作認証も最初はほんの数行から始まります。だが、リリース後の小さな判断が、静かにプロダクト全体を支配するモデルへと固まっていきます。
初日：40 行のコード
メール・パスワード・ハッシュして保存、ログイン時に比較。綺麗に完了。
だからこそ、全てのチームがここから始めるのです。認証が午後だけで終わる簡単なものに見えるのもこのためです。
200日目：静かな ID モデル
ユーザーとは誰か。どの組織に属しているか。どのセッションが信頼できるか。どのようにアクセス権を取り消すか。
レートリミット、MFAとその復旧フロー、セッション、リフレッシュトークン、「is_admin」だけでは済まない高度な組織モデル。あなたが出したあらゆる判断が、気付けばプロダクトに暗黙のルールとして根付きます。
5年後：絶対に手を付けられない基盤
紙の上でログイン画面を差し替える＝コード上で ID 基盤を作り直すこと。
ある20年モノの SaaS がユーザー名をメールに切り替えようとしました。許可チェックが数百のモジュールに分散し、誰も責任を持てず、結局できませんでした。
自作認証は順調 ― だがビジネスが動いた途端につまずく
何年も何事もなく動き続けます。だが、ビジネス上の変化がひとつ起きるだけで、「十分」だったものが一瞬で「障壁」になります。多くのスケールするプロダクトにこの三つの壁が訪れます。
エンタープライズ顧客が SSO を要求し始める
初の大型案件がまとまり、調達担当が自社の Entra や Google Workspace を使った SSO を要求。次の顧客は別の IdP 利用で SAML も OIDC も必要。顧客ごとに ID 設計がバラバラで、ほとんどすべてがやり直しになります。
- 顧客ごとに異なるプロトコル、フィールドマッピング、証明書ローテーション
- SSO は「一度きり」ではなく、導入企業ごとに毎回作り直し
- ついには一人のエンジニアしか全体像を把握できなくなる“属人化”へ
バラバラだったアイデンティティが統一を求められる
組織ごと・製品ごとに分散し、買収で引き継がれるケースも。「IDの統合」は一見機能追加に見えても、コード上では「1ユーザー・1組織」の定義見直しです。
- 1つのメールで複数組織に属せる？過去のユーザー名はどう移行する？
- 買収した9製品なら、9つの認証基盤が同時稼働
- 全システムから一括で退職者を削除、かつ監査できる必要
AI エージェントや CLI からの代行操作が始まる
もう「人がブラウザでログイン」だけじゃない。エージェントや MCP サーバー、CLI もそれぞれ「誰か」の代わりに操作します。でも自作認証は「人をログインさせる」しか知らないのです。
- トークンは誰に・どんな権限・どんなオーディエンスで発行された？
- 一つのツールや一部のデータだけ限定的に許可、後から取消し
- MCP や CLI アクセスは OAuth 基盤、もうログインフォームだけでは足りない
本当のコストは“作ること”じゃない。何年も背負うことだ。
最初のバージョンは安い：数人・数週間で完成。でもその後は毎年コア製品に割くはずだったエンジニアリング工数を食い続けます。
支払い方が変わっただけの請求書
「認証費用」なんて請求書は来ません。
人月、納期遅れ、セキュリティ負債、手戻り、全てで支払う羽目に。ある会員制組織はライセンス料を嫌って自作したが、5年後には維持コストの方が遥かに割高だったのです。
静かに1〜2 人だけに依存する現実
重要な文脈は文書ではなく「誰かの頭の中」にある。
どの顧客がどう設定されているか、なぜ過去あの移行をこの形にしたか。その人が不在だとエンタープライズ対応が止まり、退職すれば知見ごと失われるのです。
エンジニアのリソース配分、本当にこれで良い？
OAuth サーバーを自作しても、顧客から追加料金はもらえません。
認証は確かに「信頼できる」必要がある。でも「自作＝信頼できる」ではない。多くのプロダクトにとって、認証はコア依存ではあるがコア差別化ではありません。
自作しないなら、どう選ぶべき？
成熟した認証サービスはほとんどの機能（SSO・MFA・組織・統合ログイン・エージェント連携）を標準搭載しています。肝心なのは「脱出可能か」。数千行自作コードから抜け出す代わりに、他人のロックインにはまらないこと。
標準プロトコル——独自スタックは避けよう
OIDC, OAuth, RS256 署名の JWT——既知の仕組みが重要。普通のトークンから直接 claim を読み取り、ベンダー独自APIの学習は不要です。
本当に「出入り自由なドア」か
オープンソースかつセルフホストできるなら、いつでも移行可能。独自システムを手放す代わりに“出られない”ホスティングへ乗り換えてしまわないよう注意。
「ユーザーテーブル準拠」じゃない課金体系
登録ユーザー・月間アクティブ数で課金するのは、伸びるほど増税になる。スケールすると結局「自作しよう」と思わせる最大の理由に。
データにロックインが無いか
必要になったとき、いつでもユーザーデータをエクスポート可能。しかも専門事業者に預 けることで、本来持つべきでなかったリスク（PII管理）から自分を守れます。