日本語
なぜ独自の認証システムを作るべきではないのか：数十件の顧客インタビューから学んだ教訓
独自の認証システムは 1 日で構築し、何年も動かせます。本当のコストは、ビジネスが変化したその日から現れます。数十件の B2B インタビューから得た教訓。
Yijun
Developer
Developer
独自の認証システムは 1 日で構築し、何年も動かせます。本当のコストは、ビジネスが変化したその日から現れます。数十件の B2B インタビューから得た教訓。
認証は、自分で簡単に実装できそうに見えます。メール、パスワード、ハッシュ化して、ログイン時に比較。独自認証システムの構築なんて簡単そうですよね？
できます。それが罠です。
私たちは自作認証を作った多くのチームと話しました。ほとんどが同じ理由で弊社へ相談に来ました：それがビジネスの足かせになっていたからです。
業界や技術スタック、規模は違えど、結末は同じ。自分たちで作った認証が時間と共に「負債」となっていました。
奇妙なのは、それが障害として現れないことです。システムは問題なくログインできていて、普通に動きます。しかし、ビジネスの変化が現れた瞬間、道がふさがれます：セキュリティレビュー、初のエンタープライズ顧客、企業買収、2つのプロダクトをまたぐ機能開発など。
先週までは「問題なし」だったのに、次のロードマップはその認証が原因で止まります。
自作認証でよくある最大のミスは、「機能」として扱ってしまうことです。初日に書けるものです。しかしユーザーや組織や権限管理と絡みだすと、どんどん複雑になります。
認証は「機能」ではありません。これは「アイデンティティ基盤」です。
どの自作認証も同じように始まります。メールアドレスとパスワードを受け取り、ハッシュ化し、保存、ログイン時に比較。40行程度のクリーンなコードで完成。
問題はリリース後に始まります。ボットがサインアップエンドポイントを攻撃するのでレートリミットや CAPTCHA、デバイスフィンガープリントを追加。SMS コードが突然送れなくなり、リトライや1日あたりの制限も追加。さらに難しい問題が続きます：安全なパスワードリセット、多要素認証（MFA）とその復旧フロー、セッションとリフレッシュトークン、単なる is_admin 以上の権限管理。
それぞれは単独では難しくないです。スプリント 1 回で終わるものも多い。しかし、そのたびにプロダクトにとっての大きな問いへ回答することになります。
それらの答えを積み重ねると、プロダクトが暗黙的に前提とする「アイデンティティモデル」になります：何が「ユーザー」か、1人が複数の組織に所属できるか、エンタープライズ顧客のアイデンティティとの連携はどうするか、退会時にアクセスをどう外すか。
その後に書く全ての機能が、その前提に基づいて動き、年月とともに変更が困難になります。
典型例は、とある企業のケース。業界特化 B2B SaaS、創業 20 年。実店舗向けにサービスを提供。10 年以上前に独自認証を構築し、顧客ごとに別のログイン、権限チェックは業務モジュールに直接書き込む合理的な選択肢でした。
20 年後、「メールを ID とした統一ログインを 1 つにしたい」という一見小さな要望が出ましたが、実はページの変更ではなく、チェックは数百に及ぶモジュールへ拡散し、統一するにはユーザーモデル、組織モデル、認証情報移行、権限境界すべての修正が必要でした。誰も承認したがらず、何年も停滞しました。
最初に作った時は「機能」に見えても、実際は巨大なアイデンティティモデルだったのです。
公平に言えば、自作認証も長く運用できます。人をログインさせ、セッションを更新し、日々の業務にも耐えます。その複雑さはゆっくりと増え、すぐには負担になりません。
しかし「十分」が意味するのは、ビジネスが壁にぶつかっていないだけということが多い。もし壁に当たったら、それは認証自体の問題ではなく、隣り合わせのビジネスが変化したことで、「十分」が一夜にして「足かせ」になります。
以下の状況は、多くのプロダクトがスケールしていく中で必ず登場します。見かけは違いますが、根底には同じ課題があります：ビジネスが前進し、古いアイデンティティモデルが追いつかなくなったのです。
シナリオ：顧客が自身の IdP でログインしたいと言ってきたが、自作認証には「他者のアイデンティティプロバイダー」という概念がない。
初のエンタープライズ案件が成立し、調達部門から要件書が届きます。最初は Microsoft Entra や Google Workspace の SSO、その次は SAML と OIDC 両方の対応、さらに SCIM で従業員の自動登録／削除。
顧客ごとに設定も異なります：プロトコル、フィールドマッピング、証明書ローテーション、組織構造と自社モデルのマッピングなど。
しかも、その作業は使い回しできません。次の顧客は異なる IdP と新しい設定を持ちこみ、毎回ほぼやり直し。SSO は一回きりの機能ではありません。大手顧客が増えるたびに繰り返し構築し、コストも比例して増していきます。
認証は「製品へのログイン」から「顧客の IdP との連携」へ大きく性質転換します。まったく別の仕事です。
ある企業は、SSO 全体の設定を手作業で管理し、全般を把握するエンジニアはたった 1 人。その人がいれば導入もスムーズ、休暇を取れば営業とオンボーディングが全てストップ。退職時には知見ごと消えました。
初めて自作認証を作った日の段階では、こんな問題は誰も想像していませんでした。
シナリオ：アイデンティティデータが初めは組織やプロダクトごとにバラバラだったが、ビジネス拡大とともに統一が必要に。
上記の二十年企業はこの課題にぶつかりました。同様の課題は他のプロダクトでもよく見られます。あるプラットフォームは 9 つの買収製品を抱え、それぞれ独自の認証・ユーザーストアを維持していました。
買収したからといって、アイデンティティが勝手に統合されるわけではありません。新たな製品ごとに別の認証基盤を継承し、9 本平行管理にはかなりのマンパワーが必要です。
課題も山積み。A/B 両方のプロダクトで同じ人は同一ユーザーなのか別人なのか、組織はどうマッピングするか、クロスプロダクト機能の権限管理は、退職者のアクセスを 9 製品同時にどう剥奪するか、監査はどこで？
9 製品のうち、個別に壊れているものはありません。しかし、積み重なると巨大な壁になります。
「アイデンティティ統合」は一見「機能」に見えます。しかしコード的には「1 ユーザー・1 組織」の定義そのものを再設計する難易度であり、ほぼ全ての機能が古い定義に依存しているため、変えることは積み上がったレイヤー全体を揺るがします。
シナリオ：人間（ブラウザログイン）だけでなく、エージェントや CLI、スクリプトもユーザー代行でアクセス。自作認証にはその区別無し。
エージェントはあるユーザーのために内部ツール API を呼びます。MCP サーバーは保護リソースを安全に公開したい。CLI もブラウザなしでアカウントデータにアクセスしたい。
どれも本質的に同じ課題：どのユーザーのリクエストか、触れるリソースは何か、トークン発行先・スコープ・剥奪可否・監査対象は誰か？
古い自作認証だと、こうしたクライアント向けの仕組みがありません。MCP は OAuth で認可します。CLI は OAuth ログイン、または利用停止可能なパーソナルアクセストークン。いずれも本来ログインページ用に設計されたシステムでは扱えません。
「ログインページ＝1 ユーザー」の想定で作った認証のままでは、今後は代理アクセス対応が必要になります。
上記いずれの事例も「認証の障害」ではありません。システムは動作し続けます。それぞれは一見「小さな機能」ですが、実際はプロダクト戦略、データ移行、顧客デリバリーの問題となって現れます。
一番分かりやすいのが MFA です。一見「ログイン後に追加で本人確認するだけ」。
しかし、2,3 ステップ入ると「どのユーザー・組織に強制適用か」「管理者は全員に強制できるか」「決済やデータエクスポートなどセンシティブ操作には再認証が必要か」「リカバリーコード生成／再設定／サポート対応はどうするか」「SSO ユーザーの MFA は自社管理か顧客の IdP 管理か」など、「セキュリティポリシー層」と言える規模の追加になります。
「ユーザー同期だけ」も同じ裏話。「ユーザー／組織／会員モデルが正しく設計されて初めて論点になる」ような意思決定の連鎖が控えています。
機能を増やすほど、自社プロダクト内部に“アイデンティティ製品”をもう 1 つ作って運用しているようなもの。初期は数人・数週間で作れても、数年単位でメンテコストを払い続けることになります。
自作派の最大理由は「コスト」であり、それ自体は間違いではありません。
ある会員団体は5年前に検討。会員は10万だが定常ログインは数千だけ。ベンダーは登録会員数単位で課金し、見積りは予算超過。自作なら安い結論に。
しかし5年後、数学は逆転。自作のログイン維持・セキュリティ確保コストは既に外部製品購入より高くついていました。
初年度は「節約した請求額」は目に見えて、エンジニア工数は見えません。5 年後には「避けた請求」は同額でも、工数はロードマップ遅延・セキュリティ負債・継承不可能な維持コストとなって現れてきます。
つまり自作認証は「無料」ではありません。単に「認証サブスクリプション請求書」は届かず、「人月工数」「納期遅延」「リワーク」「セキュリティ負債」、元々本業へ投入すべきリソースの消耗という形で払い続けます。
「エンジニアひとりで手作業 SSO」は珍しくありません。自作認証を数年運用すれば、重大な文脈やノウハウが 1,2 人に集中します：どの顧客の設定がどうなっているか・どの項目は触れてはいけないか・過去のマイグレーション経緯など。ドキュメント化されず、人の頭の中にしかありません。
その人がいればデリバリーが進み、いなければエンタープライズ案件も止まる。重要インフラが「所有者」ではなく「たまたま分かる人頼り」になるのです。
さらに進むと、顧客自身が使える SSO 設定 UI まで用意するチームもあります。一見成熟して見えても、対象顧客はせいぜい数十社だけ。実際 150 万 MAU サービスで たった十数社のために巨大なシステムを運用している例も見ました。
「機能」のつもりで自社専用ミニ製品を開発し、そのコストはごく少数の顧客にしか分散できません。アイデンティティ自体が本業なら投資ですが、そうでないならこれこそ「純度 100% の隠れコスト」です。
さっきの 20 年 SaaS。エンジニアが弱い訳ではありません。業界向け製品を 20 年保守できるのは、その業界を深く理解している証です。
それこそが問題。本音で言えば、彼らを 1 顧客ごとの手作業 SSO・20 年分の権限ロジック掘り起こしに使いたいですか？それとも本業の業界ソフト開発に？
これは「エンジニアの理想追求」ではなく「リソース配分戦略」です。請求システム・業界 SaaS・会員ポータル・運用ソフトなど、「OAuth サーバー自作」では 1 円も収益が増えません。
ある請求 SaaS チームはこう語りました：「自作 IdP も悪くはない。でもこれは戦略判断。可能な限り認証には工数を割かず、良いものを既製品で使い、本業の進化に集中すべき」
認証は「信頼性」が最重要。ただし「信頼性＝自作」ではありません。データベース、メール送信、クラウドも同じで、成熟したチームは「重要だから自社運用すべき」とは限らないと知っています。
ほとんどのプロダクトにとって、認証は「コア依存」であって「差別化要素」ではありません。アイデンティティがビジネスの本質でない限り、自社で認証製品を運用しても競争優位にはならず、むしろ長期的なリソース消耗になります。
「だから絶対認証コード書くな」に極論しがちですが、それも違います。
ある種の段階では、自作（もしくは一部だけ内製）は完全に合理的です：社内デモや初期プロトタイプ、一度限りの検証プロジェクトなど。加えて、外部製品が絶対表現できない独自かつ緻密な認可要件だけ社内で維持しつつ、そのユーザー認証/セッション/SSO/MFA/ユーザーディレクトリは既成品に任せるのは、極めて現実的。
ただし、「POC（概念実証）坂」に要注意。ありがちですが、2 人のデベロッパーが 6～8 ヶ月かけて外部システム統合のプロトタイプを作るケース。設計自体は悪くなく、「自分たちとしては良い」と評判も実際ある。ただし「大規模運用を想定した設計」ではなかった点が落とし穴です。
POC ほど長期インフラに“化ける”リスク大。半年後には「現行ソリューション」、2 年後には「レガシー」、5 年後には「誰も触れないインフラ」に。ホームグロウン認証の出口は「壊れてから」ではなく、「基盤になる前」に決断すべき。
要は－「認証コードを 1 行書いたかどうか」ではなく、「汎用的なアイデンティティ基盤を永遠に自社保有し続ける」体制になっていないか、が問題です。
周辺部分は自作しても良い。ただしコアのアイデンティティ層は慎重に。そして、気付かないうちにフル CIAM プラットフォームを作ってしまわないように。
自力実装を諦めた場合に次の疑問：「どこを買うか・どう選ぶか？」
成熟ソリューションは殆どの機能（SSO・MFA・組織マルチアカウント・統合ログイン・エージェントアクセス等）を網羅しています。差が出るのは「機能表」ではありません。
むしろ重要で見落としがちな比較ポイントは下記。全ては「自作コードの束から逃れるために、今度はロックイン製品の檻へ飛び込まないため」にあります。
なお正直に言うと：Logto はこれら 4 点を叶えるべく作った認証製品です。OSS／セルフホスト可で、マネージドクラウドも用意：保守ゼロなら Cloud、自由度重視なら OSS 版と「出入り口の開いた設計」です。
サインイン・MFA・SSO・RBAC すべて標準 OIDC ベースで即運用可、課金はトークン従量課金なので使った分だけお支払い。
他にも成熟した選択肢は色々あり、正解はひとつではありません。比較するなら認証ソリューションの選び方もぜひ参照ください。
初日は「自作認証」も合理的な選択です。しかし、後年インフラ化します。
ビジネスが新しい歩みを踏み出すたび、再び問題化します：エンタープライズ顧客は SSO 要望、セキュリティ部門は MFA 必須、プロダクト統合へ統合ログイン、AI エージェントは代理アクセスしたい——。見かけは小さな機能でも、その裏にはポリシー上の大きな決断が連鎖し、結局本業に割くべき工数を食い尽くします。
この「請求書」は初日には届きません。数年経ってようやく見えます。「あの時書いたログインページ」は、既に製品の一生を通じて動く「アイデンティティ基盤」でした。
認証は恐らくあなたの本業ではありません。その事実を早く認識するほど、本当に作るべき製品にパワーとリソースを回せます。
いいえ。社内デモ・初期検証・特化型プロジェクトや、既製品が表現困難な厳密な認可要件のみ必要な場合などは向いています。避けるべきは、気付かぬうちに「長期的で汎用的なアイデンティティ基盤」を作ってしまい、これがビジネスチームのメンテ責任範囲に居座ることです。
認証は「あなたは誰か」、認可は「何ができるか」に答えます。実際の SaaS では両者は密接に絡み合います：ユーザー・組織・ロール・権限・セッション・トークンクレーム・監査ログが複雑に統合されているため、認証システムすげ替えも単なる「ログイン画面」の話ではありません。
それは「顧客の IdP 連携」＝「相手のアイデンティティシステムとの連携」が必須になるためです。各顧客で IdP・プロトコル・クレームフィールド・証明書・組織構造などバラバラ。最初の 1 社とつながっても、他社は “コピペ” では済みません。そのため毎回手作業、挙句ノウハウは 1 人しか分からない分断状態になりがちです。
可能です。ただし「一気に全切り替え」方式は一般的に適しません。段階的に移行しましょう：新規サインアップ・ログイン・エンタープライズ SSO をまず新基盤で処理、既存ユーザーは次回ログイン時に順次移行。常にロールバックパス・監査ログを備えて、「無戻化」しないよう注意してください。