ダイニーが提供するマルチプロダクトと認証認可基盤の課題

AIによって爆発的に開発速度が上がりました。その一方で、「認証認可」の領域においてはAIに任せる事がまだまだ難しいのが現状です。こうした中で技術的負債にどのように対応すべきなのか、についてお話します。

ダイニーでは、飲食店における店舗内の営業業務から、バックオフィスでの経営分析・勤怠管理までをトータルで支援するマルチプロダクトを展開しています。

対象ユーザーや扱うデータの機密性が異なる複数のプロダクトが共存しているため、共通かつセキュアな認証認可の仕組みをいかに構築するかが大きな課題となっていました。また、初期のスピードを優先するために複数のプロダクトで認証認可が個別実装されており、結果としてプロダクトを横断した統一的なユーザー体験を提供するのも難しくなっていました。

そんな中、ダイニーでは2026年1月から認証認可を共通の基盤に置き換えるリアーキテクチャPJTがスタートしました。

AI時代における「技術的負債」とは何か？

まず、「技術的負債」という言葉の定義を整理したいと思います。
技術的負債には様々な定義がありますが、本日の発表では「現在から将来にわたってソフトウェアを運用する総コストを引き上げるもの」と定義します。

理想的な実装と現在の実装を比較した際、継続的に余計な工数が発生していたり、インシデントの発生確率が高まっていたりする場合、それは負債を抱えている状態と言えます。負債を放置すると継続的に「利子・コスト」が積み上がりますが、これを解消するためには、一時的に大きなコストを支払って長期的なリターンを得る「投資的活動」が必要となります。

昨今のAIの登場や進化によって開発は大きく変化しました。何が技術的負債なのかも見直すべき局面にあるのではないでしょうか。

従来のエンジニアリングでは「コードを書く時間よりも読む時間の方が圧倒的に長いため、人間にとって可読性の高いコードを書くべきだ」とされてきました。しかし現在では、AI（Claude Codeなど）がミニファイ（難読化）されたコードすら問題なく解読し、コードの修正やインシデント対応を一瞬でこなしてしまいます。さらに、UIデザインの作成や3Dアニメーションの構築までもAIが短時間で実行できるようになっています。

このような状況下では、従来の感覚でコードをきれいにリファクタリングしたとしても、実際には開発効率にまったく影響を与えず、単なる自己満足で終わってしまうケースが起こり得ます。

AI時代においても残る「4つの負債」

AIがどれほど進化しても、なお解消にコストがかかり、議論する価値のある負債には4点あると私は考えています。

1つ目は「影響範囲が読めない・誤解を与えるコード」です。
仕様変更で何百箇所も書き換える必要があり、テストやCI（継続的インテグレーション）でガードされていないコード。AIの解読速度は速いものの「見落とし」は発生するため、コンテキストから漏れた場合にバグを引き起こしてしまいます。

2つ目は「DBに残る古い形式のデータ」です。
コードの外側に存在するため、どれだけコードの書き換えスピードが上がったとしても、システム側の都合だけでは容易に変更・移行できない問題があります。

3つ目は「既存の挙動に依存したユーザーの運用」です。
人間の実際の業務オペレーションがシステムに依存している場合、コードの修正速度とは無関係に、運用の切り替えに時間がかかってしまいます。

最後は、「セキュリティ的な未解消の脆弱性」です。
AIによって防御側の修正速度も上がるが、攻撃側もAIを活用するため、脆弱性を見つける速度の方が修正速度よりも圧倒的に早い状況が当面続くかと思います。

技術的負債はいつ解消するべきか？小さな改善と戦略的な大規模投資

実務において最も難しいのは、「技術的負債をいつ解消すべきか、あるいは解消せずに放置すべきか」という判断です。負債の大小に分けて、それぞれに対応していくのが良いかと思います。

• 小さな改善：AIの活用により、実装・修正にかかるコストがほぼゼロになるケースが増加しています。こういったトレードオフの生じない小さな改善は、見つけ次第すぐに解消していくべきです。
• 戦略的・大規模な負債：システム基盤の刷新など大きな負債の解消は、完了までに長期間を要する「投資的活動」となります。そのため、解消によって得られるメリットと発生するコストを明確にし、経営的な観点も含めて投資判断を行う必要があります。
  

ここからは、弊社ダイニーで認証認可基盤リアーキテクチャに取り組んだ際のメリット・コストが実際どうだったのかについてご紹介します。

ダイニーの認証認可リアーキテクチャの背景

弊社のプロダクトは当初、モバイルオーダーとPOSから始まりました。当初は一つだけモノリスがある状況で、アカウント・権限も全てこの中に入っていました。その後、ダイニーキャッシュレス・ダイニー勤怠が新たにサービスが増えていくに従って、アカウントの仕組みを新たに複製・同期していく必要が生じました。これらを共通の認証認可基盤に切り替えようと、リアーキテクチャPJTが発足しました。

従来の認証認可基盤では、以下の3つの問題が顕在化していました。

課題①：勤怠とそれ以外で、アカウントが分断

勤怠サービスとその他のサービスでアカウントが分断されていたため、全サービスを横断したデータ分析画面を作ることが困難でした。また、ユーザーはサービスごとに複数のパスワードを管理する必要があり、「POSの画面に勤怠のパスワードでログインを試みて失敗する」といった問い合わせが頻繁に発生していました。

課題②：複数人でのアカウント使い回し

店舗現場において、個人ごとのアカウント発行や切り替え運用が煩雑だったことから、一つのアカウントを複数人で使い回す運用が蔓延していました。これはセキュリティ上極めて危険な状態です。単に「個人アカウントを作ってください」と周知するだけでは解決しないため、機能やUX（ユーザー体験）を根本から改善する必要がありました。

課題③：API認可の不揃いと脆弱性

一部の機能において「フロントエンドのUIで操作ボタンを非表示にする」という制御に依存しており、バックエンドのAPI自体で適切な認可判定が行われていない箇所が存在しました。近年ではAI向けツールなどUIを経由せず直接APIを呼び出すケースが増加しているため、この状態は深刻な脆弱性となっていました。

セキュリティ負債のインパクトを経営言語に変える「DVE」の取り組み

セキュリティ上の脆弱性は、修正しても目先の売上向上や機能追加に直結しないため、後回しにされやすい傾向があります。また、経営層に対して技術的なリスクを説明しても、その重要性や緊急性が正しく伝わりにくいという問題がありました。

そこでダイニーでは、一般的な脆弱性の説明ではなく、自社のプロダクトに対して具体的にどのような攻撃シナリオが存在し、ビジネスにどれだけの被害を与えるかを可視化する独自データベース「DVE（CVEを活用したデータベース）」を構築しました。

DVEの中で最も重要な指標がExpected Lossです。これは、脆弱性がもたらすインパクトの大きさと発生確率を掛け合わせ、発生し得る損害額を数値化したものです。

ダイニーのようなSaaSビジネスの場合、セキュリティインシデントに起因する顧客の解約が最大の損害要因となります。そのため、解約が発生した場合のARR（年間定常収益）への影響額や、株価に対するマルチプル（評価倍率）を掛け合わせることで、比較可能な損害額を具体的に算出しています。

CVSSスコアや発生確率などの根拠をテンプレートに沿って細かく記載することで、「この脆弱性を放置すると○千万円〜○億円規模の期待損失が発生する」という定量的な数値を提示し、経営層が合理的な投資判断を行える環境を整えました。

新アーキテクチャの設計とPDPの導入

これらの課題を解決するため、ダイニーではすべてのサービスで共通して利用できる認証認可基盤を新たに設計・構築しました。

共通SSOで、全サービス共通のログイン画面を提供します。ユーザーはSSOで認証を行い、受け取ったトークン（Cookie/JWT）を以降のAPIリクエストに付与する形にしました。

PDPは、認可判定を集中的に行うコンポーネントです。各ドメインサービスのバックエンドは、「このユーザーがこのリソースに対して操作を行えるか」をPDPに問い合わせ、アクセスを許可またはブロックする形にします。

これにより、アカウントの一元化と、宣言的かつ統一された認可制御が実現しました。

大きな負債の返済計画を立てる方法

AIによってコードを書くコストは大幅に削減されましたが、変更を安全に本番環境へデプロイし、動作を確認・切り替える工程は依然として時間を要します。開発速度のボトルネックは「実装」から「リリース・移行工程」へと移行しているのです。

ダイニーでは、システムの停止や障害の影響を最小限に抑えながら新基盤へ移行するため、以下の3つの手法を組み合わせて運用しました。

① Canary Deployment：障害の影響を一部のユーザーに抑える

一部のユーザーのみを先行して新しいSSO認証に切り替え、段階的に割合を拡大していきます。万が一問題が発生した場合は即座にロールバックを行います。

② Expand → Migrate → Contract：サービスを止めずに移行する

データベースの移行で取り入れます。まず新旧両方の基盤へ同時にデータを書き込み（Expand）、読み取り側を徐々に新基盤へ移行。すべての参照が移行したことを確認した後に古い実装を削除（Contract）します。

③ Shadow Deployment：実トラフィックでデグレを見つける

PDP（認可判定）の移行で取り入れます。本番リクエストに対し、旧実装と新実装の両方で認可判定を実行。ユーザーへは旧実装の判定結果を返し、新実装の判定結果は旧実装との乖離をログ監視するためだけに利用します。

タスクDBによる複雑な依存関係の管理

大規模なリアーキテクチャでは、タスク同士の依存関係が極めて複雑になります。ダイニーではタスク管理データベースを活用し、「Is Blocked（ブロックされているか）」というプロパティを重視して管理を行いました。

依存する先行タスクが完了すると自動的にブロックが解除され、着手可能なタスクが優先度順に並ぶ仕組みを構築することで、人間の頭の中だけで管理する限界を突破しました。

AIによって実装コストが激減したため、「後で直す」というコメントやフォローアップタスクを残すくらいであれば、その場でプルリクエスト（PR）を作成して解消してしまう方針を徹底しています。もし即座に修正できないブロックが存在する場合は、解消条件とリマインダーを明確に記録します。

コードが増えてからlintのルールを厳しくすると、既存コードの修正に莫大なコストがかかります。そのため、プロジェクトの初期段階から厳格なルールの検査機構を入れておくことが重要です。

ダイニーの新認証認可基盤では、バックエンドを含む全体でTypeScriptを採用しており、型の安全性を損なうような抜け道を徹底的に遮断するLintルールを設定しています。

また、AIにコードを書かせると、意味のないテストMockを大量に生成してしまう傾向があります。これに対処するため、勝手にMockを作成することを禁止・制限するlintルールを導入し、厳格な検査をAI自身に突破させることで高い品質を維持しています。

負債解消のインパクト

ここからは、認証認可基盤のリアーキテクチャPJTをやった事で得られたインパクトについてお話します。

今回のPJTを通して、得られたメリットの一つ目は「シームレスなユーザー体験の実現」です。ダッシュボード上でPOSや勤怠などの複数サービスを跨ぐ単一UIでの横断分析が可能となり、ログイン周りの不具合や問い合わせが大幅に減少しました。

メリットの二つ目は、「セキュリティレベルの飛躍的向上」です。フロントエンド依存の認可を廃止し他事で、AIツールからの直接的なAPI呼び出しに対してもセキュアに対応できる環境が整いました。

そして、DVEに基づく評価により、数億円規模に相当する期待損失額を削減することに成功しました。

一方で、負債を解消しようとした結果、新たなトレードオフや課題が生じる場面もありました。

PDPを中央集権化したことで、認可判定時に必要となる「対象リソースのIDや関係性（リレーション）」を取得するロジックが想定以上に複雑化しました。

認証認可基盤側が知っている情報と、各ドメインサービス側にある情報が分断されているため、すべてのリレーションを認可基盤側に保存するか、各ドメインサービス側でリレーションを辿ってPDPへ渡すかという構造的な判断が求められています。

また、複数人でのアカウント使い回しを防ぐためのシステム機能は完成したものの、実際の店舗スタッフや利用者の運用習慣を変えてもらうまでには、引き続き時間と丁寧な働きかけが必要となっています。

まとめ：AI時代のエンジニアリングと負債との向き合い方

「技術的負債をいつ解消すべきか？」はなかなか難しい問題かと思います。なので、これは負債解消のメリットとコストを明らかにした上で、投資として判断すべき問題と考えています。

中にはAIによってトレードオフすら生じない「小さな負債」もあるかと思います。この小さな負債は、トレードオフすら生じないので、見つけ次第潰していく事で日々向き合っていくのが良いのではないでしょうか。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら

※動画の視聴にはFindyへのログインが必要です。