前回記事「メールアドレスを識別子として扱うのをやめよう」では、企業システムを念頭に、Webシステムを構築する上で、アイデンティティ情報をどのように保存するべきか、という観点の記事を和訳しました。
同じ著者、Prithvi Poreddyさんが、今度は企業がアイデンティティ管理の仕組みを導入する時に、カスタム開発で構築すべきか、それともできあいのソリューションを購入すべきか、といういわゆる「ビルド vs バイ」の問題についての記事を公開していました。どちらかというと現職より前職に関係していそうな話題ではありますが、こちらも翻訳してみました。
アイデンティティセキュリティの「構築か購入か」：戦略・能力・リスク
（Prithvi Poreddy、2026年1月6日）
作れるかどうかを問うのはやめましょう。作るべきかどうかを問うべきです。
「構築 vs 購入」はエンジニアリングにおける最古の論争です。しかしアイデンティティセキュリティでは、判断を誤ると単にお金を無駄にするだけではありません。信頼を損ないます。
ベンダー製品を購入すれば、スピード、コンプライアンスのチェックボックス、そして障害時に責任を負う相手が得られます。しかし同時に、あなたは自社のロードマップを彼らの優先事項に賭けることになります。彼らが落ちれば、あなたも落ちます。彼らが値上げすれば、あなたは支払うことになります。
自社開発すれば、完全なコントロールを得られます。自分の運命を自分で握れます。その一方で、すべてのバグ、すべての深夜3時の障害対応、そしてセキュリティチームの眠りを奪うすべての脆弱性も自分で抱えることになります。
では、どう選ぶべきでしょうか？
多くのチームはこれを「エンジニアの自尊心」対「ベンダーロックイン」と捉えます。それは誤った見方です。本質的な問いはこうです：あなたが作ろうとしているのはユーティリティですか、競争優位ですか？
ほとんどのチームが間違えるのは、この問いを完全に飛ばしてしまうからです。安全に見える選択、経営陣が望む選択、直近のデモでベンダーが約束したことに基づいて決めてしまいます。
政治を脱色して正しい答えに辿り着くために、私が使うフレームワークを紹介します。
フレームワーク
チームは通常、徹底した評価を行います。ベンダーデモ、PoC、TCO分析、機能比較。プロセスは厳密です。それでも多くの意思決定は悪い結末を迎えます。分析不足ではなく、誤った軸で分析しているからです。
標準的な評価は、機能、コスト、スケジュールに焦点を当てます。しかし滅多に問わないのは、これは本当に自社の差別化要因なのか？現実的に開発・運用できるのか？これが失敗したとき、関係者のキャリアはどうなるのか？という点です。
必要なのは、価格と機能だけでなく、戦略・能力・リスクを勘定に入れるフレームワークです。
私は三つの柱を使います：
戦略的必然性：このアイデンティティ機能はコモディティ（誰もが必要だが、どう実装するかは気にされない）か、差別化要因（御社の顧客が御社を選ぶ理由の一つになる）か？もし「配管（コモディティ）」なら、御社のエンジニアリングの才能を費やすべきではありません。
実行の現実：本当に自社で構築・保守できるのか？「優秀なエンジニアがいる」ではなく、「アイデンティティセキュリティの専門家、専任の人員、24時間365日のインシデント対応、今後3年間の経営コミットメント」があるのか？
総合的リスク：もし失敗したらどうなるか？自社開発で壊れたら、あなたの責任です。あなたのキャリアが懸かっています。購入して壊れたら、ベンダーを責めて切り替えられます。リスクは非対称です。
この三つの要素が、構築・購入・ハイブリッドのいずれかを決めます。
第1の柱：戦略的必然性：配管か製品か
最初の問いが最も重要です。その機能は本当にビジネスにとって意味があるのか、それとも電灯のように、事業を継続するために必要なインフラにすぎないのか。ほとんどのアイデンティティ機能は「最低限必要なもの」に過ぎません。従業員向けSSO、パスワードリセット、基本的なMFA。どの会社も必要です。信頼性高く動かなければ、事業遂行は困難です。
しかし、SSOが競合より優れているからといって、顧客はあなたの製品を選びません。これは重要なインフラであって、競争上の差別化要因ではありません。（顧客のユーザーがあなたのシステムを使うとして）ユーザーはシームレスな認証を期待します。あなたがどう作ったかを評価はしません。
重要か？はい。差別化か？いいえ。その区別が重要です。
そして稀に、アイデンティティ自体が製品であるケースがあります。Netflixのアカウント共有制御。Stripeの開発者向け認証体験。AWS IAM。これらの企業は、アイデンティティの扱い方で案件を勝ち取っています。彼らにとっては自社開発が理にかないます。
試金石はこうです：この特定のアイデンティティ機能で勝敗が決まる競合を名前で挙げられますか？
答えが「いいえ」なら、なあたの製品にとってアイデンティティ機能は配管（インフラ）です。購入しましょう。エンジニアリングチームは、収益を生む機能や競争優位を作る機能の構築に集中すべきで、OAuthフローを再発明するべきではありません。
答えが「はい」なら、読み進めてください。自社開発のケースがあり得ます。
これを吟味する5つの問い：
- 顧客向けか、社内限定か？（社内限定はほぼ常に＝コモディティ）
- 顧客は製品選定時にこの機能に言及しますか？
- 「十分良い」で足りますか、それとも「最高水準」が必要ですか？
- これは収益や競争上のポジショニングに直接影響しますか？
- ベンダー製品の標準機能で要件の80％を満たせますか？
多くに「コモディティ」と答えたなら、ここで終わりです。決定は購入です。残りのフレームワークは不要です。
いくつかに「差別化」と答えたなら、第2の柱へ進みましょう。
第2の柱：実行の現実：能力か願望か
第1の柱を通過したとしましょう。アイデンティティが本当に戦略的です。次の難問は、本当に実行できるのか？です。
ここで多くのチームは自分たちに嘘をつきます。「優秀なエンジニアがいる」は、「ミッションクリティカルなアイデンティティ基盤を構築・運用できる」とは別物です。作るのは簡単です。安全で、コンプライアンスに準拠し、スケーラブルで、負債にならないシステムを作るのは難しい。
本当の試練はDay 0（初期構築）ではありません。Day 2（3年後、元のエンジニアは退職し、証明書が午前3時に期限切れ寸前で、誰もトークンローテーションの仕組みを覚えていない）です。
自信と現実のギャップを暴く問いは以下です。
特定のアイデンティティセキュリティの専門性はありますか？ 「バックエンドが得意」ではありません。OAuth、OIDC、SAML、暗号鍵管理を理解していますか？過去にこれを作ったことがありますか？
恒常的な専任チームを割けますか？ パートタイムでもプロジェクトベースでもありません。プロダクトオーナー、エンジニア、QAを備え、毎年予算が付く本物のチームです。「誰かの20％時間を当てる」なら、能力があることにはなりません。
午前3時の障害対応は誰がしますか？ サービスが落ちれば、収益は止まります。専任SRE、24時間365日オンコール、文書化されたランブックはありますか？それとも「作った人が呼ばれる」のでしょうか？
セキュリティチームの承認は得ていますか？ 独自構築を情報セキュリティチームがレビューして承認していないなら準備不足です。安全に実施できると彼らが確信する必要があります。
スケジュールは？ 6か月以内に必要なら、どれほど優秀でも能力が十分高いとはいえません。急ぎの構築は失敗します。時間に追われているなら、購入しましょう。
多くで低スコアなら、購入です。たとえアイデンティティが戦略的でも、安全に実行できません。
高スコアなら、第3の柱へ。
第3の柱：総合リスク：非対称な賭け
アイデンティティが戦略的で、チームが実行可能だと判定しました。最後の問いは、失敗したら何が起こるか？です。
ここでキャリア計算が入ります。ベンダー製品を購入して壊れたら、選択肢があります。ベンダーを責め、サポートにエスカレーションし、乗り換えをちらつかせます。あなたの職は安全です。自社構築で壊れたら、あなたの責任です。あなたのアーキテクチャ、あなたのチーム、あなたの決断。侵害や大規模障害が起きれば、なぜ実績ある製品を買わなかったのかを取締役会に説明するのはあなたです。
リスクは非対称です。
賭けの大きさを決める問いは以下です。
失敗したら誰が責任を負いますか？ 答えが「自分」や「自分の部長」なら、キャリアリスクを伴います。約束する前に経営の後ろ盾を確保してください。
被害範囲は？ このアイデンティティシステムが落ちたら、影響は1チームに留まりますか、それとも全社の収益が止まりますか？範囲が大きいほど、賭けは高まります。
厳格なコンプライアンス要件はありますか？ SOC2、HIPAA、FedRAMPが必要なら、構築は監査の標的になります。自社製が本当に安全だと証明しなければなりません。ベンダーはコンプライアンスレポートを渡します。あなたはスプレッドシートを渡して祈ります。
レガシーコードの実績は？ 正直に。社内ツールは保守・アップグレードされますか？それとも誰も触りたがらず、5年後に書き直されますか？収益を生まないコードの保守が苦手なら、構築のリスクは高いです。
コスト超過を吸収できますか？ 構築は常に見積りより高くつきます。予算が固定で、超過が政治的ダメージを生むなら、それはリスクです。
リスクが高いからといって「構築するな」という意味ではありません。何にサインしているのかを理解せよ、という意味です。経営が賭けの大きさを理解していることを確かめ、論拠を文書化し、経営コミットメントを文書で得ましょう。
こうして収斂する：意思決定マトリクス
第1の柱（戦略的必然性）と第2の柱（実行能力）のスコアを取り、シンプルなマトリクスにプロットします。戦略的必然性がX軸（コモディティ〜差別化）。実行能力がY軸（低〜高）。すると4つのゾーンのいずれかに着地します。
ユーティリティゾーン（必然性低・能力低）：購入
これは自明です。あなたにとってアイデンティティは配管であり、そもそも構築できるチームもありません。従業員SSO、基本的なアクセス制御、標準的なコンプライアンス要件。ベンダー製品を買いましょう。ここにエンジニアリングの1時間も浪費しないことです。
才能浪費ゾーン（必然性低・能力高）：購入
これは罠です。「作れるから」といって「作るべき」とは限りません。はい、あなたのチームはOktaのSSOを作り直せるでしょう。でも、なぜ？エンジニアはコモディティインフラの再発明ではなく、製品を差別化し収益を生む機能に時間を使うべきです。購入して先へ進みましょう。
危険ゾーン（必然性高・能力低）：パートナーまたはハイブリッド
差別化が必要なのに、安全に作るスキルが不足しています。多くの悲劇が起きるのはここです。野心的なプロジェクト、リソース不足、キャリアに終止符を打つ失敗。最善策は柔軟なプラットフォームを購入し、専門家に大幅なカスタマイズを依頼すること。コアのセキュリティリスクを保有せずに差別化を得られます。
イノベーションゾーン（必然性高・能力高）：構築
アイデンティティが競争優位であり、実行できるチームがある。構築が理にかなう唯一の象限です。ただしここでも第3の柱が重要です。
リスクのオーバーレイ
イノベーションゾーンに入っても、第3の柱のスコアを確認しましょう。高リスクなら、経営の後ろ盾、論拠の文書化、バックアッププランが必要です。中リスクなら、注意深く進め、強固なプロジェクトガバナンスを敷きましょう。低リスクなら、これ以上安全にはなりません。
このフレームワークはあなたに代わって決めてはくれません。電卓ではありません。多くのチームが見落とす問いに向き合うための思考ツールです。
ありがちな誤りを避ける
最終決定の前に、次の罠に気をつけてください。
「自前主義」症候群：エンジニアは作るのが好きです。作れるからといって作るべきとは限りません。コモディティ機能の構築に費やす1時間は、競争優位の構築に費やさない1時間です。
Day 2 保守の過小評価：システムには継続的なセキュリティパッチ、バグ修正、コンプライアンス更新が必要です。連携システムが増えるほど複雑性は複利で増します。APIは変わります。依存関係は壊れます。上流サービスが更新されると認証フローが失敗します。最初は単純でも、保守の蜘蛛の巣になります。負担は止まらず、増えるばかりです。
隠れたコスト：紙面では構築が安く見えます。現実には市場投入が遅れ、高価なエンジニアリソースを拘束し、長期的にはベンダー製品より高くつく技術的負債を積み上げます。
自社の実績を無視：社内ツールの履歴を見ましょう。独自システムは通常、保守・更新されますか？それとも誰も触りたがらず、数年後に書き直されますか？非収益コードの保守が苦手な組織では、構築は試算以上のリスクを伴います。
意思決定の進め方
多くの「構築 vs 購入」判断が失敗するのは、すぐにスプレッドシートへ飛びつくからです。TCOを計算し、ベンダー見積りを比較し、それで終わったと考えます。2年後、なぜ200万ドルの投資が価値を生まなかったのか、あるいは自社構築システムがセキュリティの負債になったのかを取締役会に説明する羽目になります。
真の決断はコストではありません。戦略、能力、リスク許容度です。
コミットする前にこのフレームワークを使いましょう。三つの柱を正直に歩きます。正直であれば、答えはたいてい明白になります。コモディティ機能で内製の専門性が低い？ためらいなく購入です。差別化要因で、実績あるチームと経営支援がある？自信を持って構築です。その他は？慎重に進みましょう。
そして覚えておいてください。常に構築、常に購入が目標ではありません。2年後に「なぜこの道を選んだのか」と問われても、堂々と弁護できる決断をすることが目標です。
次に向けて
このフレームワークが役に立ったなら、あなたがどう適用したかをぜひ教えてください。見落としはありましたか？何を変えますか？コメントをお寄せください。
今、これらの問いを案内し、具体的なリスク警告付きの推奨を生成するインタラクティブツールを作っています。準備ができ次第、アーリーアクセスに興味があればコメントかメッセージでお知らせください。
いかがだったでしょうか。日本ではまだまだ自社開発派の企業があり、意外と海外でもこの点が常識とまではなっていないのですね。
元投稿のコメント欄では、顧客の環境がユニークなため、ベンダーの製品ではカバーできないケースもあり、ここにはスタートアップと共同開発する選択肢についての指摘もあり、これに対して、顧客が自分の要件をユニークだと思い込んでいるが、実は過大評価で、ありがちな要件の場合もある、という指摘もあります。
色々な会社の状況を見ているベンダー側から見れば実は製品そのままの機能でなくても対応方法があったり、その要件自体がたまたまそうなっていただけで、未来永劫そうなっている必要性があるわけでもないけど、顧客側の担当者が社内説明の手間を省略して、かえって面倒なことになっている、というケースも過去何度か見てきました。
自社開発でこだわりを発揮した作り込みをするのは、まずは能力があり競争優位性に関連する部分に集中して、それ以外の部分は割り切った方が、全体として良いプロジェクト、良いプロダクトになる可能性が高い、このことが、より多くの人に広まっていくことを願います。