第1回：SSO導入で満足？現場を疲弊させる「見えない負債」の正体

TL;DR（超要約）

• IDaaSが解決するのは「ログイン（認証）」のみ。「ユーザー管理」機能は自作が必要
• アプリが増えるたびに管理機能を自作・再構築することが「見えない負債」となる
• この負債の主な原因は、壊れたから直す保守ではなく、成長のための機能拡張
• 自作の管理機能は、セキュリティリスクの温床となり、対応も困難
• TactnaはIDaaSの「次」（ユーザー管理）の課題を解決し、開発コスト1/3、期間を半減できる

はじめに：

こんにちは、TC3のコーポレート部の麻生です。以前、TC3のCEO兼「Tactna」のプロダクトオーナーでもある須藤に、Auth0やCognitoといったIDaaSとTactnaの違いについ話してもらったのですが（当時のインタビューはこちら）、さらにその先の話も聞きたいと思い、今回新たにTactnaの開発責任者である眞田を交えた座談会を企画しました。

認証機能やユーザー管理機能を受託開発や自社開発で作っていくことのリスクについて語ってもらう予定だったのですが・・・

麻生：今日はお集まりいただきありがとうございます。今回の座談会のテーマは「なぜスクラッチ開発（Built）の認証機能は『負債』になるのか？」です。「セキュリティリスク」や須藤さんがLinekedinに投稿していた「Post-CIAM」の観点から、自社や開発ベンダーを使ってスクラッチで作りこんでいくリスクについてお話しいただこうと思っているんですが。。。

須藤：麻生さん、ごめん。いきなりちゃぶ台を返すようで悪いんだけど、正直に言うと、そのテーマ設定自体がもう今の市場環境とズレてきている気がするんだよね。

麻生：ズレているというのは…？

須藤：「認証（Authentication）」そのものを作るかどうかの議論は、ある意味もう終わっているんだよ。パスキーや生体認証など、認証技術は日々高度化しているでしょ？ ここを自社でゼロからスクラッチ開発しようとする会社は、今はほとんどない。そこは「Auth0」や「Amazon Cognito」といったIDaaS（Identity as a Service）に任せるのが、すでに業界の標準の選択肢になっているからね。

眞田：そうですね。現場のエンジニアとしても同感です。IDaaSを使えば、堅牢な「ログイン画面」はすぐに手に入りますから。でも、「IDaaSを入れたから、これで認証周りの開発は終わりだ」と安心してしまうことこそが、実は最大の落とし穴なんですよ。

「認証」は解決されたが、「ユーザー管理」が残された

麻生：落とし穴？ IDaaSを入れたのに、まだ何か問題があるんですか？

須藤：IDaaSが得意なのは、あくまで「ユーザーを特定すること（認証）」なのね。「このアクセスは本当に本人によるものか？」を安全に確認する。ここまで。

でも、企業がWebサービス、特にBtoB向け（対企業に閉じたものではなくチーム利用も含む）のSaaSを運営する上で本当に必要な機能は、「特定されたユーザーをどう管理し、どう動かすか」という部分にあるんだよ。我々はこれを「ユーザーライフサイクル管理」と呼んでいるんだよね。

麻生：ユーザーライフサイクル管理・・・ですか？

須藤：そう。ユーザーが作成されて（Create）、どのアプリのどの権限を割り当てて（Assign）、昇進や異動で属性を変えて（Update）、退職したら権限を剥奪して削除する（Delete）。この一連の流れのこと。

特にBtoBだと、「企業ごとの管理者が、自分の部下を招待したい」とか「退職者は自分で削除したい」っていう要望が必ず出るでしょ？ このような管理機能は、実はIDaaS自体には十分には備わっていないんだ。

ユーザーライフサイクル管理におけるアクションと目的の例

眞田：そうなんです。だから現場では何が起きるかというと、エンジニアが毎回、アプリの裏側で「ユーザーライフサイクルを管理するための画面」をスクラッチで作ることになるんです。アプリAのために管理画面を作り、次にアプリBを作ったらまた別の管理画面を作り・・・。

結果として、認証（ログイン）はIDaaSで共通化されているのに、その裏にある「管理機能」や「権限ロジック」は、サービスごとに毎回再構築（Rebuilding）され続けている。これが、開発リソースを溶かし続ける「見えない負債」の正体なんです。

麻生：なるほど。「認証を作るのが負債」なのではなく、「認証の上にある管理機能を毎回作り直すこと」が負債になっているわけですね。

須藤：その通り。我々はこの領域を「Post-CIAM」と呼んでいるんだけど、IDaaSという「セキュリティ基盤」の上に載る、「ビジネスロジックと管理のレイヤー」こそが、これからの主戦場になると考えているんだ。当社が提供するTactnaはまさにそこを埋めるパーツなんだよ。

ID管理における「機能拡張」のイタチごっこ

麻生： なるほど。毎回作り直すのは無駄だし、作った後の「メンテナンス」も大変だということですね。

須藤：そうそう。。でも、いわゆるメンテナンス（保守）って現状維持することをイメージされると思うんだけど、問題は日々変わる社会のニーズに適用していくための機能・非機能の拡張なんだよね。 ここが一番の課題なんだ。

麻生： 機能拡張、ですか？

須藤： そう。自社開発（Build）で作る場合って、どうしても「今あるアプリの要件」に合わせて個別最適化して作っちゃうでしょ？ コストを抑えるために。 でも、ビジネスは成長するよね。

新しいアプリが増える、課金モデルが変わる、あるいは将来的にAIエージェントがユーザーとして入ってくる。。。そういった新しい要件が出てくるたびに、自前の管理基盤だとつぎはぎで機能を追加開発しなきゃいけない。これは壊れたから直す（メンテナンス）んじゃなくて、足りないから足す（機能拡張）という開発工数が永遠に発生し続けるってことなんだ。

眞田： まさにそうですね。最初はシンプルでも、アプリが増えるたびに「同じチームでもアプリごとにメンバーの権限を変えたい」「メンバーを招待したい」「チームごとにIdP連携したい」って要件が複雑化して、その都度データベースの設計からやり直すことになる。これがエンジニアを疲弊させる「イタチごっこ」の正体ですね。 Tactnaは「プラットフォーム」として最初から拡張性を前提に作られているので、新しいアプリや新しいユーザータイプ（AIなど）が増えても、設定ベースで対応できる。 

「今あるアプリのために作る」のか、「将来の拡張性のためにプラットフォームを買う」のか。この視点の違いは大きいですよ。どちらを選択してもリリースまでの速度は変わらないにもかかわらずです。

自作した「管理画面」に潜む、第二のセキュリティリスク

麻生： 「拡張し続ける開発コスト」の話、すごく腹落ちしました。 でももう一点、当初のテーマだった「セキュリティ」についても聞きたいです。管理画面くらいなら自社で作っても、IDaaSを使っている限りセキュリティ的には問題ないんじゃないですか？

須藤：そこがもう一つの盲点なんだよね。実はセキュリティには大きく2つのレイヤーがあるのね。1つ目は「ユーザー特定（認証）のセキュリティ」。これはIDaaSに任せれば解決する。でも2つ目の「インフラ・アプリケーションのセキュリティ」という問題が残るんだ。

眞田：要は、ユーザーを安全に特定したあとに、アプリ側が安全なままそれを利用しないといけない。

世の中の脅威は日々進化しています。新しい脆弱性が見つかるたびに、自社開発したシステムのライブラリをアップデートし、パッチを当て続けなければならない。IDaaSがいくら堅牢でも、その上のアプリケーションに穴があったら、そこから情報が漏れてしまいますから。

須藤：そう。「動くものを作る」ことと、「安全な状態を維持し続ける」ことは別次元の話なんだ。スクラッチ開発（Build）の場合、作った瞬間からセキュリティの陳腐化が始まる。これを自社（や受託開発のベンダー）のエンジニアリソースだけで、最新の攻撃トレンドに合わせて完璧に守り続けるのは、現実的には非常にコストがかかるし困難なんだよね。

眞田：そこで、弊社が提供するTactnaのようなSaaSを採用する（Buyする）メリットはここにあります。我々はSaaSベンダーとして、インフラのセキュリティアップデートや監視を常に行っています。TactnaはISO 27001（ISMS）、27017認証も取得していますし、AWSの厳格な審査（FTR）も受けるなど、サービスのブラックボックス部分を大事にしています。

「認証」はIDaaSに守られ、その上のユーザー管理はTactnaの堅牢性に守られる。 この二重の安心感を提供できるのが、スクラッチ開発との決定的な違いですね。もちろんその先のアプリケーション固有機能の管理は各開発者に委ねるしかないのですが、この認証からアプリケーションの間にあるブラックボックスに多くの脆弱性が潜んでいます。

初期コスト1/3、期間半減の衝撃

須藤：それに、コストの観点でもインパクトは大きいよ。ある金融機関のお客様の事例では、当初スクラッチ開発で約6,000万円かかると見積もられていた共通認証・管理基盤の開発が、TactnaとAuth0を組み合わせることで約2,000万円に収まる見込みなんだよね。

眞田：1つ加えると、初期コストが3分の1になるだけでなく、サービスインまでの期間も約半分に短縮されるんですよね。特にシリーズB以降のスタートアップや、DXで複数のサービスを立ち上げようとしている大企業にとって、このスピード感は生命線と言っても良いと思います。Tactnaを使えば、最初から「マルチアプリ・マルチテナント」に耐えうるデータ構造を持てるので、将来アプリが増えた時にレバレッジが効くのでスムーズに対応できます。

須藤：多くの企業が「とりあえず今はこれでいいや」と単純なデータモデルで作ってしまい、後から複数アプリやtoB向けに売ろうと戦略を変えて、システムを大きく作り直す羽目になっているからね。

未来への視座：AIエージェント時代の「ID」

須藤：さらに視点を未来に向けると、これからの『ユーザー』は人間だけじゃない。「AIエージェント」が1つのIDを持ち、様々なサービスにアクセスする時代が既に来てるじゃない？

眞田：ですね。人間、AI、エッジデバイス……。多様な主体（サブジェクト）が複雑に関わり合う中で、それぞれのライフサイクルを正しく管理することは、もはや自社で賄えるレベルを超えています。

Tactnaは、人間だけでなくAIエージェントをも『サブジェクト』として抽象化して管理できるモデルを持っています。今は、ユーザーライフサイクル管理と言っていますが、サブジェクトライフサイクル管理、と言うのがしっくりくる気がしますね。

須藤：そうだね。今のうちからTactnaという『整えられた箱』にIDを入れておくことで、将来AI活用が本格化した際にも、スムーズにシステムを適応させることができる。

『認証を作る』のではなく、『未来のビジネスの変化に耐えうるユーザー（≒サブジェクト）構造を買う』。これが、今あえてTactnaを選ぶ最大の理由になるね。

編集後記：

今回の鼎談を通じて明らかになったのは、「認証機能の自作は論外だが、顧客管理基盤の自作（IDaaSのラッパー）もまた、多くの企業にとって差別化につながらない重労働である」という事実でした。

開発リソースを、顧客管理基盤の再構築ではなく、顧客への価値提供に集中させるために。

そして、来るべきAIエージェント時代に、破綻しないID基盤を手に入れるために。

IDaaSの導入を検討されている、あるいは既に導入済みで管理機能の開発に頭を悩ませているCTOや事業部の皆さま、「認証の次」に来る課題を先回りして解決する、Post-CIAMのソリューションとしてのTactnaを、ぜひ検討のテーブルに載せてみてください。

検討にあたって検討項目を解説したガイドブックを無料で配布中です。

こちらもぜひご確認ください。