ヨドバシの中の人が語る、開発中のヨドバシAPIが目指す機能、仕組み、そしてセキュリティ（前編）

ヨドバシカメラは現在、お客様との接点をドメインとして設計する新たなAPIを開発中であることを、クリエーションラインが主催し10月27日に開催されたイベント「Actionable Insights Day 2023」で明らかにしました。

REST APIとして実装される予定のこのAPIについて同社は「ヨドバシスタッフの魂を注入する」としており、厳重なセキュリティやユーザーフレンドリーで高い利便性などが追求されています。

ヨドバシAPIがどのように設計され、開発、実装されていくのか。その中味が紹介されたセッションの内容を見ていきましょう。

本記事は前編と後編の2本の記事で構成されています。いまお読みの記事は前編です。

疎結合なのに一体感、ヨドバシAPIがつなぐ社会

株式会社ヨドバシカメラ 代表取締役社長 藤沢和則氏。

ヨドバシカメラの藤沢と申します。本日はまずこの貴重な機会をいただきありがとうございます。

3カ月前に講演の打診をいただいて内容を相談してきたのですが、今回のイベントのお客様は、技術について日々研究されたり突き詰めてらっしゃる方が非常に多いということなので、今回はテーマをAPIに絞って話をまとめました。

最初に私の方からお話したいのは、ヨドバシカメラは家電量販店というカテゴリーに加わっておりますけれども、今扱ってる商品の約4割は非家電商品という格好になってます。

また、総売り上げの約3割がヨドバシ.com、つまりインターネットショッピングとなっていまして、この比率が毎年少しずつ上がっています。これからだいたいネット通販の売り上げを5割、リアルのお店の売り上げを5割、そういう業態を作り出していこうというのが、私どもの大きなビジョンの1つでございます。

したがいましてネットとお店の裏側に、それと同じぐらいの物流、そしてIT部門を作って経営させていただいております。

1996年にヨドバシの最初のインターネットショッピングサイトをスタートして30年近くが経とうとしておりますが、今は社内で「プロジェクト2040」という、2040年に向けてITのアーキテクチャはどうあるべきか、今設計して2040年まで使えるものを作っていこうと、この5年ほど取り組みを行っております。

この中で一番大きなテーマとして捉えているのは企業と企業の連携です。

今でもEDIやデータ交換はどの企業もやられてると思うんですけれども、企業と企業や、お客様とヨドバシや、もしくはヨドバシとつながっている企業が、シームレスに自律的にお互いのリソースを共有し合いながら、サービスや付加価値を提供できるようになる、これが「プロジェクト2040」の大きなビジョンになっています。

今日はヨドバシAPIという技術の話にどんどん入っていきますけれども、そんな前提があって、そろそろ来年ぐらいには皆さんにお見せできるものがいろいろ出てくるようになると思います。

では、技術の話はヨドバシリテイルデザインの戸田からお話させていただきたいと思います。

ヨドバシはAPIを提供していく

株式会社ヨドバシリテイルデザイン サービスデプロイメント事業部 事業部長 戸田宏司氏。

ヨドバシリテイルデザイン サービスデプロイメント事業部の戸田宏司と申します。よろしくお願いいたします。今、社長から話がありました通り、弊社はAPIの開発に力を入れております。

我々はいつも、お客様との全ての接点で「ご利用ありがとうございます」ということをお伝えしております。

ご来店いただいたとき、商品のご案内をさせていただいてるとき、レジでご購入いただいているとき、ヨドバシ.comで注文をいただいてるとき、お届け先で配達をしているとき、といった全ての場面場面で、社員一同ありがたく思っております。

これは店舗のスタッフだけではなくて、システム側も同じ気持ちでやっております。

そして全ての場面で丁寧にお客様に接していけるように、その部分をドメインに分割しまして、さらにAPIで提供していく環境を整えているところです。また、各ドメインは独立しながらもすべて等しく安全で、協調することでヨドバシの価値を最大限に発揮できるという設計にもなっております。

本日はこのAPIのお話をさせていただこうと思っております。

お客様との接点をドメインとして捉え直しAPIを作る

「ドメイン駆動設計」の提唱者エリック・エヴァンスは、彼の著書の中で「ドメイン駆動設計が語っているのは我々の物語である」と言っております。

これをヨドバシカメラはどう考えているかというと、我々の物語というのは先ほど申し上げてる通り、お客様にとって快適で便利な接点を提供し続ける、そういうエンドレスストーリーだと考えております。

そのため、お客様との接点をドメインとして捉え直し、再定義して、APIの設計を進めております。

さらに先ほど藤沢が申し上げた通り企業間の連携も考えておりますので、APIは全てWebAPIとして公開していくことを考えております。

REST APIにヨドバシスタッフの魂を注入する

このAPIについて、これから掘り下げさせていただきます。

WebAPIは、コンシューマーの視点に立ってリソースとアクションをセットで提供するもの、という定義があります。我々はこの理念に深く共感しております。

それぞれのドメインでお客様や取引先様の立場に立って必要なリソースに絞り、分かりやすく使っていただく、そんな環境を我々は整えていっております。

提供するAPIの形式は、REST APIです。誰もが直感的にわかりやすいといったところが採用している理由になっております。

しかしREST APIで提供される機能はCRUD（Create：作成、Read：読み出し、Update：更新、Delete：削除のそれぞれの頭文字）であり、ちょっとユーザーフレンドリーではないケースもあります。

我々はそんなそっけないREST APIを、お客様のご要望を推察し、適切なタイミングでご案内する、そんなヨドバシのスタッフの魂を注入しようとしています。

エスパーのような形で商品の提案ができる

そこで技術的には「CQRS」（Command and Query Responsibility Segregation：コマンドクエリ責務分離）を採用します。

そしてクエリをユースケースに合わせてご用意することで、絶妙なご提案を実現しようとしております。例えば、まるでエスパーのようにお客様のご要望やニーズを深く理解し、ご来店のたびに適切な商品を提案する、といったようなことです。

これをAPIで表現するとどうなるか。

まず、ご購入いただいたところからコマンドが発行されまして、コマンドのドメインモデルにデータが入ってきます。

その後、ユースケースに応じてクエリモデルが生成されまして、それぞれのご提案といった形のデータが出来上がっていく。

これを適切なタイミングでお客様の方にご提示をすると、お客様にとってエスパーのような形で商品の紹介ができると、そういうことをAPIで実現していこうと考えております。

ゼロトラストアーキテクチャを採用

このAPIのリソースオーナーは誰か、これは全てお客様だと我々は思っております。我々はこのお預かりしているリソースを大切に守っていく義務があると考えております。

そこで米国国立標準研究所の標準「NIST SP800-207」に沿ってゼロトラストアーキテクチャを採用することにしております。

ゼロトラストアーキテクチャでは7つの基本方針が示されているのですが、まとめると次の3つぐらいになるのではないかと思っています。

1. リソースは必要に応じてアクセスできる
2. アクセスを動的に検証する
3. セキュリティ観点で監視、測定する

この3つが満たされることが大切です。

アクセス元であるSubject、図では右上の方にある黄色い丸、このSubjectからリソースに問い合わせをする。

このときにPDP（Policy Decision Point：ポリシー決定ポイント）と連携してPEP（Policy Enforcement Point：ポリシー実施ポイント）が検証し、合格すればトラストゾーン、丸の中の緑色の部分に到達できます。

そしてPEP、PDPの検証は全てモニターされるということになっております。

我々はAPIの全てのエンドポイントにこのルールを適用させていくことを考えております。

さらに我々は境界防衛モデルも併用し、リソースの機密レベルに応じて配置を考えることで何重にもリソースを守っていきます。

認証はAAL 3を実現、しかしパスキーの扱いに悩む

次に、リソースを守る具体的な技術、認証と認可についてお話をさせていただきます。

認証も米国国立標準研究所の「NIST SP 800-63B」に沿って「認証強度」のAAL 3（認証強度 最高）を選択できることを実現しております。

AAL 1は単一要素認証、AAL 2が多要素認証、AAL 3が多要素認証で暗号鍵＋ハードウェアベースで守られる、という形になります。

具体的には、AAL 1はパスワードによる知識認証、あるいは暗号表みたいなものを使った所有者認証もしくは生体認証のうち、どれか1つが使われてる。これが単一要素認証になります。

この所有物認証、知識認証、生体認証から複数を組み合わせることができれば多要素認証としてAAL 2レベルになります。

AAL 3は多要素認証の中で暗号鍵の技術が使われていて、かつ、秘密鍵がハードウェアベースできちんと守られていることが要件になっています。

FIDO 2≒WebAuthnは、スマートフォンで生体やPINで認証し、デバイス内のセキュアなハードウェアに秘密鍵が保存されていることで、AAL 3に適合していました。

しかし新しい仕様のパスキーが生まれました。パスキーでは利便性を優先し、Apple IDやGoogleアカウントを用いることでクラウドを経由してデバイス間で暗号鍵が同期できる仕様になっています。

つまり秘密鍵がクラウドに送られるため、セキュアなハードウェアの中に秘密鍵が保存されているかというと疑問が出てくるわけです。すると、これはAAL 3ではなくなってしまうのか、という疑問が出てきます。

残念ながらパスキーでクラウド経由の同期をすると、認証強度としてはレベルダウンしているのではないかと考えられます。

≫後編に続きます。後編では、パスキーによる認証強度のレベルダウンを最小限にするための方法、認可にOAuth 2.0を採用したことなどが解説されています。

関連記事

ヨドバシカメラは昨年、プライベートクラウドを内製していることを明らかにしていました。

• ヨドバシの中の人が初めて語る、ヨドバシ.comを支える内製プライベートクラウドの中身

（2023/12/05 9:50 本文中の「Policy Entry Point」を「Policy Enforcement Point」に修正しました。お詫びして訂正いたします）