www.youtube.com 本動画では、令和5年度春期システムアーキテクト試験の午後Ⅰ問4「顔認証基盤システム」を、問題文・解答例・採点講評の観点に沿って解説します。題材は生体認証機器メーカーF社が、ホテル事業者をはじめ複数の提携事業者で共通利用できる顔認証基盤を構築し、ホテルのチェックイン、客室開錠、施設利用、さらに提携サービス利用へ適用するアーキテクチャ設計です。本問の核は、汎用的な認証基盤と個別の業務アプリケーションを分離しつつ、最大100万人規模の顔情報を扱いながら認証レスポンス1秒以内という性能要件と厳格なセキュリティ要件を両立させる設計思考にあります。午後Ⅰとしては、機能分割の意図、データの関連付けの仕組み、そしてクラウド中心設計を性能要件に合わせてエッジコンピューティングへ拡張する理由を、与件根拠に基づいて一貫した論理で説明できるかが合否を分けます。 全体像として顔認証基盤は、ホテルだけでなくレンタカー等の提携事業者でも利用できる共通基盤として設計されます。共通基盤が担うのは顔情報の登録と照合という認証そのもの、そして認証結果として返す識別情報を事業者ごとに管理する仕組みです。一方、ホテル側の会員管理システムや業務システムが担うのは、チェックイン状態の管理、宿泊中かどうかの判定、施設利用の許可といった業務固有の判断です。ここでの設計の肝は、顔認証を業務ロジックに埋め込まず、あくまで認証基盤は「本人を特定し、事業者が必要とする識別情報を返す」までに責務を限定し、宿泊中かどうかなどの業務状態は業務システムが持つという分離を徹底する点にあります。採点講評の観点でも、汎用基盤化の狙いを理解せずにホテル業務の内部処理として説明してしまうと、設問の意図から外れやすくなります。 設問1は、顔認証基盤をホテル業務フローにどう組み込むかという連携の要点を問うており、認証結果が業務状態を変えるトリガになる点を正確に捉える必要があります。顔認証端末が認証結果として受け取るのは、顔そのものではなく識別情報、典型的には会員番号などのIDです。チェックイン完了を成立させるには、その識別情報をホテルの会員管理システムへ渡して、会員管理側でチェックイン状態を更新させる必要があります。したがって空欄aのポイントは、認証結果を会員管理システムへ送信することでチェックイン完了をトリガする、という責務分担の明示になります。施設利用時の判定条件では、単に会員であることだけでは足りず、現在宿泊中であること、すなわちチェックインが完了している利用者であることの確認が必要になります。空欄bはまさにこの業務条件で、認証基盤が返すのはIDであり、宿泊中かどうかは会員管理システムが持つ状態で判断するという分離がここでも現れます。午後Ⅰの読解としては、認証は「誰か」を返すが、利用可否は「状態」を見て決める、という役割分担を崩さないことが重要です。 設問2は、顔認証基盤のデータ管理方式と、複数事業者での利用を成立させる識別情報の扱いを問う設問群で、本問の汎用基盤化の理解度が最も露骨に差として出る領域です。アプリでの本人確認方法では、顔登録時のなりすまし対策として、運転免許証等の顔写真付き公的証明書の顔写真と、アプリで撮影した顔画像の照合によって本人確認を行うという流れを押さえます。ここは単に「公的証明書で確認」ではなく、顔認証という手段で両者を照合する点まで言い切ることが、技術的整合性のある説明になります。顔情報と識別情報の関連付けは、利用者が事業者システムへログインした状態で顔画像を送信することを起点に、基盤側が受信した顔情報で認証を実施し、既存の顔情報と一致したエントリに当該事業者の識別情報を紐付けるという流れです。ここで重要なのは、顔DBは基盤側の共通資産であり、識別情報は事業者ごとに異なるという前提で、同一人物に対して事業者別のIDを関連付けることで、基盤の汎用性が担保される点です。 その上で設問2(3)の事業者情報を送信する目的は、採点講評で正答率が下がりやすい典型ポイントです。顔情報だけで個人は特定できても、基盤が返すべき識別情報は事業者ごとに異なります。マルチサービス前提の基盤では、同じ人物がホテルでは会員番号A、提携事業者では会員番号Bというように別の識別情報を持ち得るため、リクエストがどの事業者から来たのかが分からなければ、どの識別情報を返すべきか決められません。したがって事業者情報を送る目的は、当該事業者の識別情報を特定して返すためであり、ここを「認証精度向上」や「アクセス制御」など一般的な理由にすり替えると本問の基盤設計意図から外れます。午後Ⅰでは、基盤の汎用化を成立させるために、顔情報と識別情報をどの軸で管理しているかを押さえることがそのまま得点につながります。 設問3は、本問の技術的ハイライトであるエッジコンピューティング導入の理由と適用条件、そしてその際のデータとセキュリティの扱いを問うています。最大100万人分の顔情報をクラウドの顔認証サーバで照合し、都度ネットワーク越しに往復させる設計では、通信遅延や回線混雑、問い合わせ頻度の増大により、1秒以内というレスポンス要件を安定して満たすことが難しくなります。そこで端末側に必要データを事前配布し、端末内で認証を完結させるエッジ認証を併用する設計へ拡張します。ここでダウンロードすべき最低限の情報は、認証のために必要な顔情報と、認証成功時に業務システムへ返す識別情報の組です。顔情報だけでは「誰か」を返せず、識別情報だけでは照合できないため、両者を対にして保持する必要があります。 一方でエッジ端末にはストレージ容量や管理コストの制約があるため、全会員分を保持するのは非現実的です。したがってエッジ認証を使うべきなのは、認証対象を限定できる場面、具体的には当日チェックイン予定者など対象集合を小さく絞り込める場合です。採点講評が求めるのは、単に「チェックイン時にエッジを使う」という場面の回答ではなく、なぜその場面で使えるのか、すなわち認証対象が絞り込めるから端末側データ量が許容範囲に収まり、ハードウェア制約下でも性能要件を満たせるという理由付けまで含めた理解です。午後Ⅰでは、適用場面と設計理由がワンセットで評価されるため、場面だけ、あるいは理由だけの片肺回答にならないよう注意が必要です。 さらにエッジ端末に顔情報を保持する以上、端末の紛失や盗難が直ちに個人情報漏えいリスクに直結します。そのため遠隔消去機能を備える理由は、紛失等が発生した際に端末内の顔情報を含む個人情報を消去し、被害拡大を防ぐためです。ここも「セキュリティ強化のため」と抽象化すると評価が弱く、何を消すのか、どのリスクを潰すのかを具体化することが採点講評の趣旨に沿います。 本問を通じて視聴者が学べるのは、汎用基盤を作るときの責務分離とデータモデルの軸の取り方、そして性能要件が厳しいときにクラウド集中型からエッジ併用へ設計を拡張する際の、データ配布範囲の設計とセキュリティ対策の組み立て方です。難所は、事業者情報送信の目的のように、マルチテナント・マルチサービスとしての識別情報管理を理解していないと一般論に逃げやすい点と、エッジ導入を単なる高速化策として捉えてしまい、対象絞り込みという前提条件と端末制約との整合を説明できなくなる点にあります。採点講評が示す「理由まで含めた解答」を意識し、与件の制約と方式選択の因果を丁寧につなぐことが合格水準への近道になります。 最後に、この動画を見る意義をまとめると、令和5年度春期システムアーキテクト午後Ⅰ問4を通じて、共通認証基盤と業務アプリの境界を設計し、事業者ごとの識別情報管理で汎用化を成立させ、さらに性能要件とデータ規模制約に対してエッジコンピューティングを合理的に適用し、端末側データ保持に伴うリスクを遠隔消去などの対策で潰すという、一連のアーキテクチャ設計の思考手順を具体的に身に付けられる点にあります。単なる顔認証の技術紹介ではなく、要件と制約から方式を選び、責務分離とデータの持ち方で実装可能な設計へ落とすという、システムアーキテクトの答案作法をこの問4で固めてください。
