Table of Contents
この文字起こしは、2023 年 12 月 12 日に開催された Authlete Customer and Partner Meetup 2023 のプレゼンテーションのひとつです。 日本経済新聞社 プラットフォーム推進室 ソフトウェアエンジニア 淵脇誠さまに、OpenID Connect のアーキテクチャや、運用基盤の選定（AWS）と構成例、また次世代認可基盤への移行に関してお話しいただきました。
日本経済新聞社の淵脇です。よろしくお願いいたします。本日は、OIDC アーキテクチャーセッションで、弊社が行っている日経 ID 基盤刷新プロジェクト、Melissa（メリッサ）についてお話しいたします。
最初に、わたし及び、わたしの所属する日経 ID チームについて、軽く紹介させていただきます。
わたしは 2020 年に日本経済新聞社に入社しまして、日経 ID の開発をずっとやっています。AtCoder という競技プログラミングを、趣味でけっこうやっています。もしやっている方がいらっしゃいましたら、お声がけしていただければと思います。
わたしの所属する日経 ID チームは、Melissa という刷新プロジェクトの開発チームです。総勢10 名ほどで、スクラムチームを組んで、フルスタックな開発をしています。
Melissa はギリシャ語でミツバチを意味します。ミツバチは、生態系におけるインフラの役割を担います。ID 基盤につきましても、日経のいろいろなサービスのインフラを担っていけたらという思いから、このプロジェクトコードをつけました。
このセッション自体は OIDC アーキテクチャセッションとなっていますが、アーキテクチャに入る前に、日経 ID 戦略の背景と、加えて Melissa がどう始まったのかについて、お話ししていきたいと思います。
まず、日本経済新聞社における日経 ID の位置付けです。
日本経済新聞社の事業ドメインとして、News & Insights と、Brand Communication、Decision-making、Experienceという、4 つの経営ドメインを定義しています。
それぞれ、News & Insights は、非常に馴染み深い、いわゆる新聞、報道機関としての仕事です。それに加えて、そこに載っている広告などの Brand Communication。また、たとえばエグゼクティブが経営判断をする材料とかをやるための Decision-making。そして、個人のキャリア形成などの Experience。こういったところに注力していくことを、中期経営計画などで定めています。
こんな感じで、報道機関でありながら、いろんな分野にサービスを張り巡らしていくために、これらを統合して見渡し、ユーザーを横断的に深く理解する必要が出てきました。それを実現する基盤が日経 ID です。
よって、日経 ID は、単純にログインを行う基盤というだけではなく、経営戦略の一部として扱われている点が重要です。
もともと日経 ID は、日経電子版と言われるニュースサイトへログインするための基盤として導入されたものでした。しかし、このような感じで、経営マターとして非常に期待が大きくなってきたという現実があります。
そのため、実際に ID 基盤が提供している機能と、経営陣からの期待値のギャップが、非常に大きくなってきました。
ここにオレンジの枠で描いてあるのが、旧基盤です。2010 年、OpenID Connect 仕様がまだ正式版ではなかった時代に、日経 ID はOpenID Connect を実装した基盤を提供しており、その稼働実績が 10 年以上ありました。
ところが、当然 2010 年に作ったものですので、いろいろレガシーな部分が出ていました。また、昨今の最新のセキュリティ事情への対応だとか、新しい認証のトレンドへの追従が非常に難しくなってきたという課題があります。
とくに日経 ID の新ミッションとして、赤枠で囲ってあるような「ポートフォリオ最適化」などを、非常に求められてくるようになりました。そして、日経 ID の基盤自体に高いアジリティが求められるようになってきた現実があります。
ですので、これを実現するために新しいことを始めなきゃね、というところが起点になっています。
そこで、この下の部分の、とくにアジリティ（新しい要件に対する変更容易性）を確保するために、基盤を完全に刷新しようと始まったのが、この Melissa プロジェクトになります。他に求められることについては、様々なチームと協業することによって、経営からの日経 ID に対する期待を満たし、この全体をカバーしていくことを目指しています。
基盤の刷新にあたっては、要件定義が必要になります。このときには、皆さん、言いたい放題言ってきます。たとえばここに書いていますが、レガシー機能の互換性であったりとか、サービス継続性であったりとか、あともちろん ID 基盤としてのプロダクトの価値向上といったものが求められるわけです。こんな感じでいろいろ要求が出てきます。
もともとサポートしていたのだからこれも引き続きサポートしてね、というのも当然出てくるわけです。この基盤自体はかなり古いので、セキュリティ上問題がある機能や、OIDC の仕様に違反している機能とかも、もともとあったのだから当然やってくれるよね、みたいな要求は、まあ出てきます。
さらに、サービスの継続性も、ID 基盤には非常に強く求められるものです。もちろんIDが止まっちゃうとすべてのサービスが使えなくなってしまうので、無停止での移行といったことも出てきます。
それに加えて、一番やりたかったのは、ID 基盤としての価値向上です。
実際、セキュリティ上問題がある機能を新しい基盤でもそのまま提供すべきなのかどうかは、非常に議論の多いところです。それはプロダクトの価値向上に反するんじゃないのみたいなところはありますが、そういった、相反する要求を要件としてまとめ上げたい、というのがあります。
こういうのはプラットフォームの宿命というところもあるので、ID チームをちゃんと作って、やっていくしかない、というのが実際のところです。
基盤刷新におけるシステム要件定義の難しさはいろいろあります。とくに、技術的挑戦が受け入れられにくいであるとか、事業継続性の要求が極めて強く安定思考である、といったことがあります。
今回の例では、元々 2010 年に作った基盤が残っているので、それを多少アップデートすればいいのではないか、みたいな圧力もあるわけです。そうすれば一応安定はしますし、挑戦とかもないので、これまでの使い心地はそのまま続きます。一方で、もともと一番やりたかったアジリティの向上とかは、かなりやりにくくなってしまいます。
なので、安定して稼働するシステムが正義だよということで、既存システムの改修で終わりがち、みたいなところがあったりします。
そういうことを繰り返していくとどうなるか。ここに緑の枠で囲ってあるんですが、結果としてレガシー機能の互換性とサービスの継続性にフォーカスし、プロダクトの価値向上につながらないといったことが、けっこうあります。
これはプラットフォームに限らず、基盤システムとか基盤系では、かなりよくある話なのかなと思っています。プロダクトの価値向上として、要求を積んだけれども結局要件定義の段階で落されちゃったみたいなところは、けっこうある話かなと思っています。
ただ実際、レガシー機能に関しては、必要なものはもちろんやりますが、セキュリティ上問題があるとか、OIDC の仕様に違反しているとか、そういったものについては、やっぱり落としていきたいわけですね。
なので、できればそういったものを落としつつ、プロダクトの価値向上に注力したいというのが、ID チームとして強く思うところでした。
こういった要求とか、ID 基盤チームの思いを考えつつ、基盤刷新にどのようなミドルウェアを使うかを検討しました。ここにいくつか製品を並べています。もうちょっと選択肢としては多かったですが、代表的なものを並べています。
まず Authlete については、一般的には SaaS での提供がメインかなと思いますが、オンプレミス版もあります。オンプレミス版は、Authlete 社からアプリケーションを提供してもらって、それを自分でホスティングする方法です。それも選択肢に加えています。
我々はどちらかというとソフトウェアエンジニアが集まったチームなので、その観点で評価すると、やはり Authlete が非常にエンジニアフレンドリー、とにかくぱっと見で作りやすそう、というのが第一印象でした。たとえば、Authlete 社のサイトに並んでいる API ドキュメントなどを見て、実際うちのシステムを刷新したときにどういうアーキテクチャになるのか、ある程度経験を積んだ人ならほぼ一瞬でわかるような、そんな非常にいいアーキテクチャだな、という印象でした。
一方ここに書いている、製品 A とか製品 B に関しては、ソフトウェアエンジニアの観点からは、非常になんていうか、とっつきにくいというか、ある程度ベンダーを入れた開発を前提にしているんだろうな、みたいな雰囲気があって、ある意味ブラックボックスみたいな雰囲気でした。
そのようなこともあり、我々に合っているのは何かをいろいろ考えた結果、Authlete を採用しよう、となりました。
さらに日経の場合、元々 2010 年に作った基盤にすごい規模のユーザーベースがいました。そういったレガシーな要件に対し、Authlete のカスタマイズ性や提供機能から、対応容易性がかなり高いため、これでいけるだろうと判断しました。
このような比較を経て、最終的に、疎結合で、高凝集で、イミュータブルなサービスであることとか、最新の標準仕様を実装したサービスであるとか、コスト面の競争力とかを考え、ソフトウェアエンジニアからも強く要望を受けて、最終的に Authlete を選ぶことに決まりました。
Authlete を選ぶことで、我々がもともと目指したかったアジリティ性の向上にフォーカスできるのではということで、非常に期待していました。
その結果、要件レベルとしては、Authlete で対応できないものはばっさり切り捨てましょう、ということで、レガシー機能の互換性はがんばって切り捨てる方向に動きました。
これはソフトウェア開発、とくに「サービス開発あるある」ですが、たとえば皆さんが AWS とか Azure とかを使うときに、「それは AWS では対応してない機能です」というのは、レガシーな要件を落とすための非常に強い説得力になるところがあると思います。
Authlete についても、似たような感じで使わせていただいたところがあります。「 Authlete は OIDC の世界で非常に権威ある、標準的な実装です。それに反する要件につきましては、本当にそれを受けいれる価値があるのか、ビジネス面からも慎重に判断してください」、と。そういう「圧」をかけることで、だいぶヤバい仕様を落としました。
これは、Authlete が OIDC のコミュニティの中で非常にその影響力を持っていることが、かなり働いたのかなと思います。これからもそういった方向での影響力の維持も、非常に期待したいところではあります。
ここまでで、日経 ID の戦略と、Melissa に至るまでの背景をお話ししました。
次に、この Melissa プロジェクトのアーキテクチャについてお話ししていこうと思います。
先ほど、Authlete にオンプレミスという選択肢があるという話をしました。これは Authlete 社の Web サイトにもプランとして載っています。Authlete 社のクラウドサービスで提供する SaaS のプランと、Authlete 社からアプリケーションをいただいて自分たちでホスティングするオンプレミスプランがあります。
どちらがいいかは非常に悩ましいところですが、ひとつはコスト面です。あとメンテナンスについて、オンプレミスプランなら自分でホスティングするので、タイミングを自由に制御できます。またオンプレミスプランについては、どのクラウドを使うかといったことは自由です。自社でノウハウのある AWS スタックを使うことも可能になります。
そういったことを検討した結果、日経ではオンプレミス版を選択しました。つまり Authlete 社からアプリケーションファイルをいただいて、それらを自分でデプロイして運用するかたちです。
さらにもうひとつ、決めるべき要素として、内製 or 外注といったものがあります。
内製も外注も、やはり一長一短あるというのが実際のところです。内製だからいいとか、外注だから安心とか、そういったことはないわけですね。
たとえば、アジリティ（変更容易性）に関して言えば、内製の場合ですと、「開発チームの技術力を確保できれば高い」という、条件付きで高い、みたいな感じになります。外注だともちろんこれは低くはなるんですけども、ただ内製だからといって、アジリティが必ず高いかというと、それはチームの実力によるところがあります。
開発コストについても、外注の場合は変動費が高くなるとか、内製の場合は社員を抱えないといけないので固定費が高くなるとか、そういったリスクがあります。
これらは会社によります。幸い日経 ID チームは、エンジニア採用に成功していたので、ある程度エンジニアリングリソースが確保できる状況でした。
そういうこともありまして、内製のメリットを活かせると判断し、内製を選択しました。
体制は、マネージャー、プロダクトオーナー、スクラムマスターに加えて、ソフトウェアエンジニア 8 名、これは兼任にはなりますが UX デザイナー 3 名、という体制でやっています。
ID 基盤チームとしては比較的豪華なメンバーなんじゃないかと思っています。スクラム開発とか自分たちで運用する DevOps といった感じで開発を行っています。
Authlete のオンプレミス版をどういう風にAWS上で動かしているかの、アーキテクチャ図がこちらになります。
認証の部分は AWS の ECS（コンテナベースの実行基盤）で稼働しており、それと同じように、Authlete も ECS で動かしています。そこに、マネージドデータベースである Aurora MySQL をつなげて、Authlete を運用しています。
Authlete のオプションとして Redis を使うという選択肢があり、何か高速な応答が必要であれば Redis をキャッシュにする方法もあります。しかし今のところは、Aurora MySQL の性能がある程度高いこともあり、Redis は入れずに使っています。この図に Redis がありますが、これは認証の方で使っているものでして、Authlete の方は MySQL + ECS のコンテナ基盤という、非常にシンプルな構成で動かしています。
また、ここに乗っているもの以外にも、Datadog とか PagerDuty とか、運用に必要な各種 SaaS を使いまして、日経のエンジニアのみで運用までカバーしています。
Authlete を使うとひとつ出てくるのが、認証については自前で実装しなければいけないという話です。ただ、これについてはけっこう方針を立てやすいです。なぜなら、OpenID Connect の仕様が、意外と認証についても少し踏み込んで決めているんですね。ここに一例を並べています。
たとえば、ログインをせずに認可をしたいという要件がたまにあったりします。これは組み込みの WebView とかで、既に認証は終わっているから、認可コードだけ発行してくれといった話です。そういうユースケースに備えて、OpenID Connect では、prompt=none と言われる認可リクエストのオプションを用意しています。
あと、モバイルアプリの中の WebView の中で、ログインセッションを共有したいといったことがあります。ここには Token Exchange と書いていますが、その派生で Native SSO という仕様がありまして、それを使うとシングルサインオンができる、といったものが OIDC 系の中でいろいろ定義されているわけですね。
こういったものを使うと、Authlete 自体は認可に特化した基盤ですと言いながら、かなりの部分、認証をどう実装するべきかの方針を立てやすいです。
ですので、やっぱり標準仕様を軸に実装できるというのは非常に強いな、というのがわかると思います。
もうひとつ重要な話です。先ほどの DX セッションでは、ゼロから指数関数的に伸びたサービスの話を聞きました。我々の要件はその逆でして、もともとユーザーベースがいるところをどうやって切り替えるかの話になります。
1,000万人規模の「旧日経 ID 基盤」を全部停止して、一気に切り替えることは、非常に難しいです。それをやる案もあったのですが、リスクが高すぎるので、徐々に切り替えていくという方式にしました。
これは ID 基盤自体だけではなく、ID 基盤を使っているクライアント（Relying Party）側の事情もありました。
開発チームが Relying Party ごとにいるのですが、対応できる工数がそれぞれバラバラです。ある開発チームは外注のベンダーを使っているから予算確保してから発注しなきゃいけないとか、別の Relying Party は非常にエンジニアリングリソースがあるので即日対応できるとか、そういった事情がいっぱいあるわけです。
そのため、「旧日経 ID 基盤」と「新日経 ID 基盤」は、基本共存するという方式でいくことにしました。そして、Authlete は柔軟に対応できました。「新日経 ID 基盤」から、「旧日経 ID 基盤」と Authlete の両方にイントロスペクションリクエストを出してみて、どちらかでオッケーだったらオッケー、みたいな実装をすればかんたんに共存できるわけです。
実際には、オートグロインを組み合わせてユーザーにあまり意識させないようにするとか、かなり細かいテクニックがありますが、それらを組み合わせると、このブラウザから見て、「新」なのか「旧」なのかをまったく意識せずに、徐々に切り替えていくことができます。
Authlete を使って 2 年ほど開発を継続して、感じられる効果がいくつあります。ここに 3 つ挙げています。
まず、レガシーからの脱却が確実に進んでいます。OpenID Connect の当時のドラフト版にはあったけど正式版になって削られたような部分や、そもそもセキュリティ的にまずいものも、どんどん脱却が進んでいます。
あとこれはちょっと細かい話ですが、「Client as a Code」、これはわたしの造語ですけれど、Relying Party のクライアント設定のことです。これを、Authlete の Terraform を使ってコードベースで管理できます。いままでの旧基盤では Web の GUI からやっていたので、バージョン管理が難しかったです。コードベース管理によって、バージョン管理とか revert（元に戻す）とかが非常にやりやすくなり、メンテナンス性も上がったかなと思っています。
あともうひとつ、開発チームの、標準仕様への解像度ですね。これはもう非常に上がったと思います。やはり Authlete を理解して使わないといけないので、OIDC に関する仕様はそうですし、それにプラスして、Authlete は認証に関するところは何も提供しないので、じゃあどうやったら業界標準でできるのかといったところで、たとえば他社の認証の実装を研究して、業界標準を理解しよう、というモチベーションはかなり高くなったと思っています。
最後に、今後の日経 ID について少しお話ししたいと思います。
これはほとんど個人的願望ですが、Passkeys は、いつかやりたいなと思っているところです。
日経のユーザー層は年齢層の高い人も多いので、複雑なログインをしてください、つまり MFA を設定してくださいといったものに対して、非常に抵抗のある方が多いわけですね。パスワードに複雑なものを使ってくださいと言っても、なかなか難しいところがあったりします。
そういったところでも、高い UX を提供できる Passkeys は、かなり我々のユーザー層に合っているのではと思っています。また会員数が非常に多いため、単純なパスワードが大量にあったりすると、インシデントの影響もかなり大きくなってしまいます。
モバイルユーザーが多く、Passkeys 導入の下地ができているなど、非常にポテンシャルが高いです。このあたりをやっていきたいと思っています。
ちなみにチームの中で、プライベートで Passkeys を実装した人が、エンジニア 8 人中 2 人くらいいます。それくらい、やりたいという熱量が高まっているところです。
ご清聴、ありがとうございました。
