はじめに

🟢 ずんだもん:
「みんな、こんにちはなのだ。ぼくは、Web 技術なんもわからんおじさんなのだ。」

🔴 きりたん:
「妖精でしょ。」

🟢 ずんだもん:
「心はおじさんなのだ。インフラばっかり触ってきたから、Web アプリはふわっとしか分からないのだ。」

🟣 イタコ:
「ふわっとしているくらいの方が、ポエムにはちょうどよろしいですわ。」

🟢 ずんだもん:
「そんなおじさんでも、最近の漏えいのニュースは気になるのだ。焼肉チェーンのアプリの会員約 1,079 万件、ハンバーガーチェーンのアプリの会員約 1,118 万件……。10 日のあいだに、1,000 万件を超える公表が 2 つなのだ。」

🔴 きりたん:
「去年からずっとよ。東京商工リサーチの調べだと、2025 年に上場企業とその子会社が公表した漏えい・紛失は 180 件、漏えいした個人情報は 3,063 万人分。原因の 64.4% が『ウイルス感染・不正アクセス』ね。」

🟢 ずんだもん:
「ぼく、手口が分かったのだ。どっちもスマホアプリの会員なのだ。アプリはストアから誰でも入手できて、Android のアプリ（APK）は解析すれば中身が読めるのだ。攻撃者はアプリを解析して、裏の API の仕様や埋め込まれたキーを知って、アプリを通さずに API を直接呼んでいるのだ！😤」

🔴 きりたん:
「その推理、調べてから言いなさい。」

🟢 ずんだもん:
「……調べたら、今回は当たっていたのだ。2026 年 10 月に、NICT と JPCERT/CC が同じ見立てを公表していたのだ。」

🔴 きりたん:
「へえ。じゃあ、アプリを難読化して隠せばいいのね。」

🟢 ずんだもん:
「それが、解析は完全には防げないと、NICT が書いているのだ。」

🟣 イタコ:
「では今日は、読まれても困らない作りを考えるのですわね。お金の話は、わたくしが受け持ちますわ。」

🟢 ずんだもん:
「よくある Web システムの設計を、この記事では『あるある設計』と呼ぶのだ。アプリを読まれた後に狙われる弱点を 6 つ挙げて、鍵と名簿を持たない設計に置き換えて、最後に高くなるか安くなるかを円で計算するのだ。」

本記事はポエムです。

この記事の前提

MAU（Monthly Active Users の略。その月に 1 回でもサインインした利用者の数）が 30 万までの会員サービスを想定しています。External ID の料金は、この MAU で数えます。30 万にした理由は 6 章で話します。
数字は 2026 年 10 月 30 日時点の公開情報です。料金は 10 月 29 日時点の Microsoft と AWS の公開価格で、割引は入れていません。
事件は会社名を伏せ、業界と業態で書いています。入口は、各社が公表した範囲だけで書いています。
事件を挙げるのは、各社の対応の良し悪しを言うためではなく、入口の型を見るためです。
守る側の記事なので、攻撃の手順や道具の名前は書きません。
想定するのは、配送先を持たない会員サービス（ポイント・クーポン・予約）です。物を送る業態の扱いは 2-4 で話します。
この記事の「Entra ID」は、Microsoft Entra External ID とマネージド ID を含む Entra の製品群の意味で使っています。会員のサインインを受け持つのは External ID（外部テナント）で、料金も別です。
MAU 30 万の負荷に耐えられるかは、5-5 で話します。

🔴 きりたん:
「そういえば前に、社内の定型業務を Azure Functions と Static Web Apps（SWA）で巻き取る記事を書いてたわね。」

🟢 ずんだもん:
「あの構成は、今日の『持たない設計』の社内版なのだ。」

この記事で紹介するもの

アプリは解析される前提（NICT の A2B 攻撃・JPCERT/CC のケース B）
読まれた後に狙われる、あるある設計の弱点 6 選（本人確認・埋め込んだ鍵・パスワード・名簿・設定ファイルの鍵・OS）
Entra ID で鍵と名簿を持たない設計（External ID・Easy Auth・マネージド ID・SWA と Functions・なぜ SWA か）
公表された入口への当てはめ（12 件を ✅ と 🔶 で見る）
微妙な点（中に入られたら・配備の鍵・残る鍵・お金・MAU 30 万の上限・名簿の守り先）
お値段（MAU 5 万までは安くなる。30 万までなら元が取れる）

1. アプリは解析される前提なのだ

1-1. 予測は、公的機関の見立てと同じだったのだ

🔴 きりたん:
「で、その NICT は何て書いてるの？」

🟢 ずんだもん:
「脅威情報分析チームの LETTICE が、10 月 13 日の注意喚起でこう書いているのだ。」

これらの情報漏洩事案の原因の一つとして、攻撃者が一般に公開されている Android アプリを解析し、その解析結果を悪用してバックエンドサーバを攻撃する手法が確認されました。

🟢 ずんだもん:
「NICT はこれを『A2B 攻撃（App-to-Backend Attack）』と呼んでいるのだ。Google Play の日本地域のアプリを入手して解析して、バックエンドサーバーの接続先、API の構成、通信に使うパラメーターを集めて、サーバーごとに攻撃を組み立てるのだ。」

🔴 きりたん:
「JPCERT/CC は？」

🟢 ずんだもん:
「10 月 8 日の注意喚起で、手口をケース A〜E の 5 つに分けたのだ。ケース B が『API 経由での不正な操作』で、公開しているスマホアプリを解析して、API のエンドポイントやキーを特定する手口なのだ。10 月 15 日の調査では、攻撃元のサーバーに、APK ファイルを解析して API に SSRF などの脆弱性がないかを調べた痕跡まであったのだ。」

🟣 イタコ:
「どの事件がこれだったのかは、分かっていますの？」

🟢 ずんだもん:
「NICT も JPCERT/CC も挙げていないのだ。 だから、この記事でも個別の事件には結びつけないのだ。」

1-2. アプリから読まれるもの

🟢 ずんだもん:
「NICT の注意喚起と JPCERT/CC の調査から拾うと、アプリから読まれるのはこういうものなのだ。」

接続先のサーバー
API の構成と、個々のエンドポイント
通信に使うパラメーター
応答のデータの形
アプリに埋め込んだキー

🔴 きりたん:
「Flutter で作れば読めないんじゃない？」

🟢 ずんだもん:
「JPCERT/CC は、Flutter のアプリも専用の道具で解析されうると書いているのだ。NICT は、iOS のアプリや Web の API でも同じ問題が起こりうると書いているのだ。」

🟣 イタコ:
「Web の画面も、ブラウザーに届く JavaScript は誰でも読めますものね。」

1-3. 読まれた後に狙われるもの

🟢 ずんだもん:
「NICT が、A2B 攻撃で主に狙われている脆弱性として挙げたのは、この 4 つなのだ。」

脆弱性	起きること
IDOR（BOLA）	識別子を変えると他人の情報が返る
SQL インジェクション	DB の個人情報を取られる
SSRF	内部やクラウドのメタデータを読まれる
RCE	サーバーで不正なプログラムを動かされる

🔴 きりたん:
「ログインしないと使えない API なら安全？」

🟢 ずんだもん:
「NICT は、ログインした後に使える API も狙われると書いているのだ。アプリに埋め込んだキーも狙われるのだ。JPCERT/CC は、アプリに共通の秘密鍵が埋め込まれていると、正規のアプリを通さない API の要求を作られる恐れがあると書いているのだ。」

🟣 イタコ:
「マクニカの解説にも、『スマホアプリを解析してAPIキーを取り出し、正規のアクセスに見える形でAPIを呼び出すケース』が挙がっていますわ。」

🟢 ずんだもん:
「しかも、攻撃者が AI でアプリの解析や脆弱性の探索を速めていることに、NICT も JPCERT/CC も触れているのだ。」

1-4. 解析は防げないから、読まれても困らない作りにするのだ

🟢 ずんだもん:
「NICT の注意喚起のまとめに、こうあるのだ。」

公開アプリが解析されること自体を完全に防ぐことは困難です。重要なのは、アプリの内部構造や API の仕様が攻撃者に知られた場合でも、バックエンドサーバの安全性が確保されるように設計・運用することです。

🔴 きりたん:
「JPCERT/CC は？」

🟢 ずんだもん:
「アプリに秘密情報を埋め込まない、署名処理や難読化に頼らずにサーバー側で認証と認可をする、正規のアプリ以外からのアクセスも想定してレート制限と監視を置く、なのだ。」

🟢 ずんだもん:
「隠すより、読まれても困らない作りにするのだ。 それが、今日の『鍵と名簿を持たない設計』なのだ。」

1-5. ほかの入口も並べておくのだ

🔴 きりたん:
「入口は、アプリの解析だけ？」

🟢 ずんだもん:
「入口の 1 つなのだ。2024〜2026 年の国内の事案 125 件を手口別に整理したウェステリアのまとめが、これなのだ。1 件が複数の手口に入っているのだ。」

手口	件数
不正アクセス（経路は未公表）	35
委託先・取引先経由	28
ランサムウェア	27
Web サービス・アプリ経由	26
盗まれた・弱い ID とパスワード	17
利用している SaaS・他社製ソフト	15
VPN・リモートアクセス機器	13
設定・管理の不備	10

🟢 ずんだもん:
「委託先、ランサムウェア、盗まれた ID とパスワード、VPN の機器も並んでいるのだ。2 章の弱点のうち、3 つ目（会員のパスワード）と 6 つ目（OS と VPN）は、こっちの入口にも効くのだ。」

2. 読まれた後に狙われる、あるある設計の弱点 6 選なのだ

🟢 ずんだもん:
「ここで言うあるある設計は、Web サーバーと DB を自分で持って、ログインの仕組みも自分で作る形なのだ。まちの図書館にたとえると、こうなるのだ。」

🟣 イタコ:
「長く使われてきた、標準的な作りですわね。」

🟢 ずんだもん:
「そうなのだ。手を抜いた作りではないのだ。真ん中の利用者が持っている案内図が、アプリなのだ。案内図は配るものだから、読まれる前提なのだ。」

🔴 きりたん:
「その案内図に、狙う場所まで載っているのね。」

🟢 ずんだもん:
「部品でつなぐと、こうなのだ。赤い枠が漏れやすい所で、丸の番号は 2-1〜2-6 の番号なのだ。」

🟣 イタコ:
「赤い枠は、どれもアプリから場所が分かるところですのね。」

🟢 ずんだもん:
「そうなのだ。どこか 1 か所が破られると、DB のパスワードを通って、全員分の名簿がまとめて出ていくのだ。」

🟢 ずんだもん:
「6 つを、アプリを読まれた後に効く順に 1 枚ずつ見るのだ。」

この章の図の見方：左がよくある作り（before）、右が置き換えた作り（after）です。太字が図書館のたとえで、その下が Web の作りです。

2-1. API が本人かを確かめない

🔴 きりたん:
「アプリから API の形が分かれば、会員 ID を書き換えるだけで他人のデータが返ってしまうわけね。」

🟢 ずんだもん:
「NICT が IDOR（BOLA）として挙げた弱点なのだ。ID が連番みたいに推測しやすいと、大量に漏れてしまうのだ。JPCERT/CC のケース B にも、権限の変更や不正なアカウントの作成が挙がっていたのだ。」

🟢 ずんだもん:
「こうするのだ（after）：API は、トークンに入っている利用者の ID と、読もうとしている行の持ち主を必ず照らす。 権限は DB の列で持たず、Entra のアプリロールで持つのだ。照会の回数の上限は、SWA と Functions には数えて止める設定が見当たらないから、手前に置く Front Door の WAF のレート制限ルール（既定は接続元の IP ごとに数える）か、API Management のポリシー（数える単位を利用者の ID などにできる）で掛けるのだ。」

2-2. 鍵をアプリやリポジトリに埋めてしまう

🔴 きりたん:
「アプリを解析すればキーが出てきてしまって、正規のアクセスに見える形で API を呼べてしまうのね。リポジトリのトークンも、リポジトリに入られれば取り出せるわ。」

🟢 ずんだもん:
「こうするのだ（after）：スマホアプリには鍵を入れず、利用者のトークンで API を呼ぶ。 配備は GitHub Actions などからワークロード ID フェデレーションで行って、長く使えるシークレットを持たないのだ。」

🔴 きりたん:
「ワークロード ID フェデレーションって？」

🟣 イタコ:
「GitHub Actions のような外の仕組みが、実行のたびに発行する短い寿命のトークンを Entra ID が信頼して、Azure に入るためのトークンに取り替える仕組みですわ（Microsoft Learn）。GitHub の側に、Azure のシークレットを置かずに配備できますの。」

2-3. 会員のパスワードを自前の DB に持ってしまう

🔴 きりたん:
「ログインやトークンの発行の API も、アプリから形が分かってしまうわね。」

🟢 ずんだもん:
「NICT は、認証トークンの不正発行・偽造・認証の回避も点検するよう求めているのだ。自前のログイン画面は、よそで盗まれた ID とパスワードを試される的にもなってしまうのだ。警察庁などの令和 7 年の統計だと、他人の ID とパスワードを使った 399 件のうち、使われたサービスの最多は『社員・会員用等の専用サイト』（122 件）だったのだ。」

🟢 ずんだもん:
「こうするのだ（after）：会員のサインインは Microsoft Entra External ID に任せる。 アプリは SWA か App Service の Easy Auth で、サインイン済みの人だけを通すのだ。」

🟣 イタコ:
「サインインをメールのワンタイムコードにすれば、控える暗証番号そのものがありませんわね。」

2-4. 個人情報を業務 DB に全部写してしまう

🔴 きりたん:
「氏名もメールアドレスも電話番号も業務 DB にあると、SQL インジェクションが 1 か所あるだけで全員分が出ていってしまうわね。」

🟢 ずんだもん:
「こうするのだ（after）：住所などの個人情報は External ID の利用者の属性に置き、サインインした本人のトークンに載せて受け取る。 業務 DB には、利用者の ID と、注文やポイントだけを置くのだ。」

🟣 イタコ:
「SQL インジェクションそのものは、値をパラメーターで渡す書き方で防ぎますわ。持たない設計は、防ぎ損ねたときに出ていく物を減らしますの。」

🔴 きりたん:
「通販みたいに物を送るなら、住所が要るでしょ。」

🟢 ずんだもん:
「そのときは、配送先を注文だけに置いて、発送が終わったら、期限を決めて消すのだ。この記事の試算は、配送先を持たない会員サービス（ポイント・クーポン・予約）を想定しているのだ。」

2-5. DB のパスワードを設定ファイルに書いてしまう

🔴 きりたん:
「URL や画像を受け取る API があると、SSRF で内部のネットワークやクラウドのメタデータ、ローカルのファイルまで読まれてしまうのね。設定ファイルを読まれたら、DB の鍵が出ていってしまうわ。」

🟢 ずんだもん:
「JPCERT/CC のケース A にも、環境設定ファイルやバックアップファイルを盗もうとする動きが挙がっていたのだ。」

🟢 ずんだもん:
「こうするのだ（after）：アプリはマネージド ID で DB を開く。」

🟣 イタコ:
「マネージド ID は、Azure がその Azure リソースにだけ渡す身分証ですわ。Azure SQL Database と Azure Database for PostgreSQL は Microsoft Entra の認証に対応していますから、アプリはパスワードを持たずに接続できますの。」

🟢 ずんだもん:
「マネージド ID のトークンの窓口も SSRF の的になりうるから、5-1 で話すのだ。」

2-6. VM と VPN で OS を自分で抱えてしまう

🔴 きりたん:
「接続先のサーバーが分かれば、OS や機器の既知の脆弱性を探されてしまうわね。VM なら、OS のパッチと管理用の VPN の面倒も自分で見ることになってしまうし。」

🟢 ずんだもん:
「JPCERT/CC のケース A がそれなのだ。1-5 の分類でも、VPN・リモートアクセス機器が 125 件のうち 13 件あったのだ。」

🟢 ずんだもん:
「こうするのだ（after）：Web は SWA と Azure Functions（または App Service）で動かし、パッチを当てる OS と、管理用の VPN を持たない。」

3. Entra ID で、鍵と名簿を持たない図書館にするのだ

🟢 ずんだもん:
「6 つの『こうするのだ』をまとめると、持たないものは 4 つなのだ。認証と鍵と名簿は Entra ID に預けて、OS は Azure に任せるのだ。」

持たないもの	預け先（Entra と Azure の部品）	図書館のたとえ
認証	Entra External ID と Easy Auth	本人確認は受付会社に任せる
鍵	Entra のマネージド ID	職員は管理会社の顔パスで入る
名簿	External ID の属性を本人のトークンで	名簿は受付会社に預ける
OS	SWA と Functions	建物は管理会社に任せる

🔴 きりたん:
「職員室のドアに鍵穴が無いけど、職員はどうやって入るのよ。」

🟢 ずんだもん:
「施設の管理会社の顔パスなのだ！部品でつなぐと、こうなるのだ。」

🟣 イタコ:
「線の番号の順に、サインイン、トークン、API、DB ですわね。緑の線には、鍵が 1 本もありませんの。」

3-1. 認証を持たない：Entra External ID に任せる

🟢 ずんだもん:
「会員のサインインは、External ID の外部テナントに任せるのだ。」

🔴 きりたん:
「SWA とはどうつなぐの？」

🟢 ずんだもん:
「OpenID Connect のカスタム認証を設定するのだ。カスタム認証は SWA の Standard プランでしか使えないから、SWA は Standard にするのだ。App Service なら、組み込みの認証（Easy Auth）の設定で、テナントの種類に『外部構成』を選べるのだ。」

🔴 きりたん:
「パスキーは？」

🟢 ずんだもん:
「External ID でも使えるのだ。ただ、2026 年 10 月時点では、独自の URL ドメインと、アプリ側での登録の作り込みが要って、メールのワンタイムコードで入る利用者には使えないのだ。まずはメールのワンタイムコードで始めるのが手軽なのだ。」

🔴 きりたん:
「メールのコードだけだと、要素は 1 つよね。」

🟢 ずんだもん:
「そうなのだ。メールの受信箱を持っていること、の 1 つだけなのだ。2 要素目が要るなら、SMS かパスキーを足すのだ。」

🟣 イタコ:
「SMS は、5-4 の料金が乗りますわ。」

📝 追記（2026-10-31）：ここで言う外部テナントとは

今回の外部テナント（External ID）は、自社専用に 1 つ作る、会員用の Entra のテナントです。会員の名簿と認証情報を持ち、サインインの画面や多要素認証も受け持つ、いわば「外付けの会員 DB＋ログインの窓口」です。会員が会社や学校の Entra ID のアカウントのまま、テナントをまたいでサインインする形（マルチテナントのアプリや B2B のゲスト招待）とは違います。会員はテナントを何も持たず、自分のメールアドレスでこの外部テナントに登録します。

3-2. 鍵を持たない：Entra のマネージド ID で入る

🟢 ずんだもん:
「アプリから DB と Storage へは、マネージド ID で接続するのだ。配備は、GitHub Actions などからワークロード ID フェデレーションで行うのだ。」

🔴 きりたん:
「これで鍵はゼロ？」

🟢 ずんだもん:
「……外部テナントの側に、鍵が残りやすい所が 3 つあるのだ。」

SWA が External ID へサインインするための、アプリ登録のシークレット
全員分を読む処理（3-6 の一斉配信）が Microsoft Graph を呼ぶための、アプリの資格情報
プロフィール編集の中継の API の資格情報（3-3）

🟣 イタコ:
「サインイン用のシークレットは、マネージド ID に置き換える設定が SWA にありますけれど、使えるのは社内向けの構成（ワークフォース）だけですわ。」

🔴 きりたん:
「ほかの 2 つも、マネージド ID にできないの？」

🟢 ずんだもん:
「アプリ登録とマネージド ID は、同じテナントに属している必要があるのだ。マネージド ID が属するのは Azure のリソースと同じテナントで、外部テナントは別のテナントだから、外部テナントに登録したアプリはマネージド ID を資格情報にできないのだ。」

🟣 イタコ:
「でしたら、アプリを Azure 側のテナントに置いたらどうですの？」

🟢 ずんだもん:
「試したのだ！ Azure のリソースを置いているテナントにマルチテナントのアプリを登録して、マネージド ID を資格情報として付けて、そのアプリを外部テナントに入れて Graph の User.Read.All を与えたのだ。2026 年 10 月 30 日に試験用の外部テナントで試したら、シークレットを使わずに、外部テナントの利用者の一覧を読めたのだ。Learn も、別のテナントのリソースにアクセスするときは、アプリの登録をマルチテナントにして相手のテナントに入れる形を示しているのだ。」

🔴 きりたん:
「じゃあ、一斉配信の鍵は要らないのね。プロフィール編集の中継の API は？」

🟢 ずんだもん:
「利用者のトークンを受け取って本人の権限で Graph を呼ぶから、同じ形で鍵を無くせるかは試していないのだ。」

🟢 ずんだもん:
「だから、残る鍵は 1〜2 本なのだ。Key Vault に置いて、期限を決めて取り替えて、読める範囲をアプリごとに分けるのだ。 Key Vault は、こういう『どうしても残る鍵』の置き場として使うのだ。」

3-3. 名簿を持たない：External ID の属性をトークンで受け取る

🟢 ずんだもん:
「External ID には、利用者の属性（組み込みの属性と、自分で定義するカスタム属性）を、サインインのときに発行するトークンへ載せる機能があるのだ。アプリはトークンの中の本人の属性だけを使って、業務 DB には利用者の ID と、注文やポイントだけを置くのだ。」

🔴 きりたん:
「この形、ほかにも良いことがあるんでしょ。」

🟢 ずんだもん:
「あるのだ。マネージド ID は、External ID の外部テナントの Microsoft Graph には直接届かないのだ。マネージド ID が属するのは Azure のリソースと同じテナントで、外部テナントは別のテナントだからなのだ。」

🟣 イタコ:
「本人の属性をトークンで受け取るなら、アプリから Graph を呼ぶ必要が、そもそもありませんわね。」

🟢 ずんだもん:
「アプリは、全員分の名簿を読む手段を持たずに済むのだ。」

🔴 きりたん:
「裏返すと、外部テナントに登録したアプリで Graph を呼ぶ処理は、マネージド ID では動かないのね。」

🟢 ずんだもん:
「そうなのだ。だから一斉配信は、Azure 側のテナントのアプリにして鍵を無くすのだ。プロフィール編集の中継の API は、アプリの資格情報で動くのだ（3-2）。」

🔴 きりたん:
「で、住所が変わったらどうするの？」

🟢 ずんだもん:
「External ID には、組み込みの編集画面が無いのだ。だから自分で作るのだ。Microsoft の手本は、画面から中継の API を呼んで、中継の API が Microsoft Graph の本人のプロフィールを、本人の権限（User.ReadWrite）で書き換える作りなのだ。編集のときは、多要素認証を求める条件付きアクセスを組むのだ。」

🟣 イタコ:
「その中継の API は外部テナントに登録したアプリとして動きますから、資格情報を持ちますのね（3-2）。」

🟢 ずんだもん:
「そうなのだ。SWA のサインインでアプリが受け取れるのは利用者の情報（クライアントプリンシパル）で、本人の Graph 用のトークンは入っていないから、編集画面は MSAL で別に組むのだ。本人が /me で直せるのは、Learn の一覧だと氏名・住所の類なのだ。電話番号は一覧に無いから、アプリ側の権限で直すことになると推定するのだ。」

3-4. OS を持たない：画面は SWA、API は Functions

🟢 ずんだもん:
「画面は SWA、API は Azure Functions の Flex Consumption プランで動かすのだ。Functions の関数アプリは、SWA の Standard の『独自の関数アプリの持ち込み』で SWA につなぐのだ。どちらにも、パッチを当てる OS は無いのだ。」

3-5. なぜ SWA と Functions なのか

🔴 きりたん:
「ちょっと待って。VM や App Service や Container Apps じゃだめなの？」

🟢 ずんだもん:
「比べると、こうなのだ。」

置き場	パッチを当てる OS	組み込みの認証	待機中の料金
VM	自分で当てる	無い（自作する）	台数分かかる
App Service	無い	Easy Auth	プランの台数分かかる
Container Apps	無い（イメージは自分で）	Easy Auth	0 台まで縮められる
SWA ＋ Functions	無い	SWA の認証（Standard）	SWA は定額、API は使った分

🟢 ずんだもん:
「VM は、2-6 の弱点そのものなのだ。」

🟣 イタコ:
「App Service と Container Apps なら？」

🟢 ずんだもん:
「持たない設計の大半はできるのだ。どっちも組み込みの認証（Easy Auth）があって、マネージド ID も使えるのだ。App Service は組み込みの認証の設定で External ID の外部テナントを選べて、Container Apps は OpenID Connect のカスタムプロバイダーを設定できるのだ。ただ、Container Apps は、コンテナーのイメージの中身を新しく保つ仕事が残るのだ。」

🟢 ずんだもん:
「SWA を推すのは、画面と API を分けた作りだからなのだ。 画面はビルド済みのファイルだから、SWA がグローバルに分散して配ってくれて、画面のためにサーバーを待機させなくていいのだ。API は Flex 従量課金で、使った分だけなのだ。待機の台数を決めなくていいから、小さな規模ほど安いのだ。」

🟣 イタコ:
「画面をサーバー側で組み立てる作りや、長く動き続ける処理があるなら、App Service か Container Apps の方が素直ですわね。」

🔴 きりたん:
「SWA って、この規模なら Premium じゃないの？冷えた状態からの起動で待たされるし。」

🟢 ずんだもん:
「SWA のプランは Free と Standard の 2 つで、Premium は無いのだ。専用プランは 2025 年 10 月 31 日に廃止されたのだ。画面はグローバルに分散して配られるから、冷えた状態からの起動は無いのだ。」

🟢 ずんだもん:
「冷えるのは API の側なのだ。Flex 従量課金は使われないと 0 台まで縮むから、次の最初の 1 回が遅くなるのだ。」

🟣 イタコ:
「でしたら、Flex の『常時使用可能』のインスタンスを 1 台置けばよろしいですわ。2 GB の 1 台で、待機の料金は東日本で月約 3,150 円ですの（1 GB 秒 0.0006 円 × 730 時間）。Functions の Premium プラン（EP1）は 1 台月約 2.8 万円ですから、この規模なら Flex で足りますわね。」

3-6. 規律を 3 つ足す

🔴 きりたん:
「部品に任せられないことは？」

🟢 ずんだもん:
「3 つあるのだ。」

API は本人の行だけを返す。 トークンの利用者 ID と行の持ち主を照らす処理は、部品では肩代わりできない。API ごとに書く。
全員分を読む権限は、Web の関数に持たせない。 メールの一斉配信のように全員分が要る処理は、別の関数と別のアプリ（3-2 の、マネージド ID を資格情報にしたマルチテナントのアプリ）に分け、インターネットから呼べないようにする。
アプリの側の工夫に頼らない。 難読化やアプリの改ざん検知は足してもかまわないが、API は、アプリ以外からも呼ばれる前提で書く（JPCERT/CC）。

🟣 イタコ:
「社内向けの業務なら、どうなりますの？」

🟢 ずんだもん:
「External ID の代わりに、社員の Entra ID を使うのだ。前の記事の構成（SWA、Functions、マネージド ID、Linked Backends、条件付きアクセス）がそれで、こっちはサインイン用のシークレットもマネージド ID に置き換えられるのだ。」

4. Entra ID の設計を、公表された入口に当てはめてみるのだ

🔴 きりたん:
「じゃあ、持たない作りだったら、今年公表された入口はどうなるの？」

🟢 ずんだもん:
「当てはめてみるのだ。見るのは各社の対応の良し悪しじゃなくて、入口の型なのだ。NICT と JPCERT/CC も、どの事件が A2B 攻撃だったかは挙げていないのだ。どの事例も、各社が調べて公表した範囲だけで話すのだ。」

🟢 ずんだもん:
「✅ は、その入口が成り立たないか、盗まれる物が無いもの。🔶 は、被害が小さくなるか、3-6 の規律で防ぐものなのだ。まず、2 章の 6 つの型で振り分けると、こうなるのだ。」

🔴 きりたん:
「入口と結果は？」

🟢 ずんだもん:
「表にすると、こうなのだ。」

事件（公表）	入口	持たない設計なら
海外のデータ基盤の顧客（2024-06）	多要素認証の無いアカウント	✅ 管理者に多要素認証を掛けるなら止まる
海外の営業支援 SaaS（2025-08）	リポジトリ経由のトークン	✅ 置く鍵が無い
大手飲料メーカー（2025-09）	拠点のネットワーク機器	✅ 守る機器と OS が無い
FAQ システムの委託先（2026-10）	管理サイトの不正ログイン	✅ 管理画面も Entra で入る
新聞社（2026-10）	開発用クラウドの鍵	✅ 長く使える鍵が無い
カーシェア大手（2026-10）	Web システムへの侵入	✅ 画像を残さない
ソフトウェアの販売会社（2026-10）	会員情報取得 API の不正利用	✅ API の先に名簿が無い
画像共有サービス（2026-09）	変換サーバーの脆弱性	🔶 ハッシュが存在しない
EC 構築サービス（2026-08）	アプリの脆弱性	🔶 抜ける名簿が減る
コンビニの会員 ID（2026-10）	本人表示の仕組み	🔶 本人の行だけ返す
焼肉チェーンのアプリ（2026-10）	未公表	🔶 業務 DB に名簿が無い
ハンバーガーチェーンのアプリ（2026-10）	未公表	🔶 業務 DB に名簿が無い

🔴 きりたん:
「✅ が 7 つ、🔶 が 5 つね。一つずつ説明して。」

海外のデータ基盤サービスの顧客は、情報窃取マルウェアで盗まれた ID とパスワードで、多要素認証を設定していなかった顧客のアカウントに入られた。調査にあたった会社は、約 165 の組織が影響を受けた可能性があるとしている。持たない設計でも、外部テナントの管理者には同じ多要素認証が要る（5-6）。
海外の営業支援 SaaS の連携アプリは、攻撃者が開発元の GitHub のアカウントに入り、そこから連携アプリの環境に入って OAuth トークンを手に入れ、700 を超える組織の顧客管理 SaaS からデータを持ち出した。
大手飲料メーカーは、攻撃者がグループの拠点にあるネットワーク機器を経由してデータセンターのネットワークに入り、ランサムウェアを実行した。Web システムではなく社内のネットワークの事例だが、自分で守る機器が入口になった例として入れた。
FAQ システムの委託先は、管理サイトに不正ログインされ、同じサーバーにある利用企業の DB から問い合わせ情報（最大 5 社・延べ 713,126 件）を取られた可能性がある。委託先は、再発防止策に多要素認証の導入を挙げている。持たない設計で顧客ごとに DB と ID を分ける形なら、1 社の管理画面から他社の DB へは届かない。
新聞社（約 183 万件）は、開発用のクラウドに入るための認証情報が盗まれた。盗まれ方は未公表なので、✅ は「盗まれたのが長く使える鍵だったなら」という条件付き。
カーシェア大手の ✅ は、その会社自身が再発防止策として決めたこと（本人確認書類の画像を登録後に残さない）と同じ。
ソフトウェアの販売会社は、会員情報取得 API を不正に利用され、最大 22,519,960 件の会員の情報を第三者に取得された。流出した可能性のある項目には、パスワードも入っている。原因は調査中。持たない設計では、会員のパスワードも名簿も業務側に無く、API は本人の行しか返さないので、全員分を返す API がそもそも無い。✅ は入口に対してではなく、「API の先に全員分の名簿があった」ことに対するもの。
画像共有サービスと EC 構築サービスは、どちらも中でコードを動かされた。画像共有サービスは動画などの変換処理の脆弱性を突かれ、変換サーバーから届く DB を読まれている。流出したデータには、パスワードのハッシュ値が含まれていた。EC 構築サービスは、アプリの脆弱性を使って不正なプログラムを動かされ、DB の情報を外へ送られた。
コンビニの会員 ID（約 215 万件）は、運営会社が「ユーザー本人に情報を表示する機構」に不正アクセスがあったと説明している。手口の詳細は未公表なので、🔶 は「本人の行だけ返す規律（3-6）が効く形だったなら」という条件付き。
焼肉チェーンのアプリは、登録者の 99.8% が対象だった。手口は未公表なので、「どこから入られたにせよ、全員分が 1 か所にあった」までにとどめる。
ハンバーガーチェーンのアプリ（約 1,118 万件）は、公式アプリの会員情報を管理するシステムに第三者がアクセスしたと公表している。原因は調査中なので、名簿の型に入れたのは「氏名や電話番号を、会員情報を管理するシステムにまとめて持っていた」までにとどめる。

🔴 きりたん:
「画像共有サービスと EC 構築サービスが 🔶 止まりなのは、なんで？」

🟢 ずんだもん:
「持たない設計でも、中でコードを動かされたら、そのアプリの身分証の権限は使われるからなのだ。次の章で話すのだ。」

5. Entra ID で組むときの微妙な点もあるのだ

🟢 ずんだもん:
「持たない設計にも、微妙な点があるのだ。正直に話すのだ。6 つを 1 枚にまとめると、こうなるのだ。」

5-1. 中に入られたら、Entra のマネージド ID は使われる

🔴 きりたん:
「顔パスって、館内に入り込んだ人にも使えるんじゃないの？」

🟢 ずんだもん:
「……そうなのだ。マネージド ID も同じで、アプリの中でコードを動かされると、そのアプリに付いた ID の権限は全部使われるのだ。画像共有サービスの事件で読まれたのも、変換サーバーから届く DB だったのだ。」

🔴 きりたん:
「1 章の SSRF で、マネージド ID のトークンを取られたりしないの？」

🟢 ずんだもん:
「App Service と Functions では、トークンの窓口に、プラットフォームが値を入れ替える秘密のヘッダー（IDENTITY_HEADER）を付けて頼む決まりなのだ。Microsoft Learn も、このヘッダーを SSRF 攻撃の軽減に役立つものと説明しているのだ。外から URL を差し替えさせるだけの SSRF だと、このヘッダーの値が分からないから、取りにくいのだ。」

🟢 ずんだもん:
「でも、中でコードを動かされたら（RCE）、取られるのだ。 だから、全員分を読む権限は Web の関数に持たせず、届く範囲を部屋ごとに絞るのだ（3-6）。」

5-2. 配備の経路が一番重い鍵になる：ワークロード ID フェデレーションで絞る

🟣 イタコ:
「改装業者さんは、館内を丸ごと入れ替えられますわね。」

🟢 ずんだもん:
「アプリのコードを配備できる人や仕組みは、アプリの身分証をすべて使えるのと同じなのだ。配備はワークロード ID フェデレーションで行って、配備できる人を絞るのだ。」

5-3. External ID 側に、アプリの資格情報が 1〜2 本残る

🟢 ずんだもん:
「会員向けの構成では、外部テナントに登録したアプリの資格情報が 1〜2 本残るのだ（3-2）。SWA のサインイン用と、プロフィール編集を作るならその中継の API 用なのだ。一斉配信が Graph を呼ぶ分は、Azure 側のテナントのアプリにマネージド ID を付ければ、鍵を持たずに済むのだ。残る分は Key Vault に置いて、有効期限を決めて取り替えて、読める範囲をアプリごとに分けるのだ。」

5-4. External ID は MAU でお金がかかる

🟣 イタコ:
「そして、お金ですわ。」

🟢 ずんだもん:
「External ID は、MAU が 5 万を超えた分から料金がかかるのだ。SMS の認証は 1 通ごとに料金がかかって、日本は 1 通 11.03 円の帯に入るのだ。日本にデータを置く Go-Local というオプションも、1 MAU あたり 3.151 円の追加なのだ。」

🟣 イタコ:
「この記事では SMS と Go-Local を使わない前提で、次の章で計算しますわ。」

5-5. External ID と SWA が MAU 30 万に耐えられるかは、事前に Microsoft に確かめる

🔴 きりたん:
「そもそも MAU 30 万なんて、SWA と Functions で耐えられるの？」

🟢 ずんだもん:
「公開されている上限を並べると、こうなのだ。」

部品	公開されている上限
SWA Standard	要求数の上限は公開されていない
SWA Standard の帯域	月 100 GB まで含まれる
Functions Flex	1 アプリで最大 1,000 台まで増える
Functions Flex のリージョン	既定で 250 コアまで使える
External ID の要求数	1 秒に 200 要求まで受ける
External ID の IP あたりの要求数	1 つの IP から 1 秒に 20 要求まで受ける
External ID のオブジェクト数	既定で 30 万個まで持てる

🟢 ずんだもん:
「Functions は、この記事の試算の負荷なら余裕があるのだ。月 1,800 万回の呼び出しは平均で 1 秒に約 7 回で、2 GB のインスタンスは既定で 1 台が 16 件を同時に処理するのだ。ピークが平均の 20 倍で 1 回 0.5 秒かかっても、同時に 70 件ほどだから、5 台ほどで足りるのだ。」

🔴 きりたん:
「Python だと？」

🟢 ずんだもん:
「Python のアプリは既定が 1 台 1 件だから、台数はもっと増えるのだ。」

🔴 きりたん:
「External ID は？」

🟢 ずんだもん:
「会員の数が先に上限に当たるのだ。既定の 30 万オブジェクトには利用者とアプリが入って、超えるには Microsoft サポートへの依頼が要るのだ。この記事の仮定（会員は MAU の 3 倍）だと、MAU 10 万で会員が 30 万人になって、上限に届くのだ。」

🟣 イタコ:
「サインインが一斉に起きたときにも、上限がありますわね。要求の上限は 1 テナントで 1 秒 200 件で、メールのワンタイムコードでのサインインは 1 回に 7 件ほどを使いますの。クーポンの通知などで一斉にサインインが起きると、1 秒に 30 件弱で頭打ちになる計算ですわ。1 つの IP からは 1 秒 20 要求までですから、携帯回線のように多数の会員が同じ IP を共有することがある回線では、テナント全体の 200 より先に、こちらに当たる可能性があると推定しますわ。」

🟢 ずんだもん:
「SWA は、要求数の上限が公開されていないのだ。公開されているのは帯域で、月 100 GB を超えた分は 1 GB あたり 31.51 円かかるのだ。VM から配る場合もデータ転送の料金はかかるから、6 章の試算には入れていないのだ。」

🔴 きりたん:
「じゃあ、どうするの？」

🟢 ずんだもん:
「MAU 30 万を狙うなら、作り始める前に Microsoft に問い合わせておくのだ。 External ID のオブジェクト数の引き上げ、サインインが集中したときの上限、SWA に大量のアクセスが来たときの挙動の 3 つは、公開の数字だけでは決めきれないのだ。」

5-6. 名簿の守り先は、External ID の管理者に移る

🔴 きりたん:
「名簿、消えてないじゃない。受付会社に移っただけでしょ。」

🟢 ずんだもん:
「置き場が変わっただけなのだ。だから守る場所も移るのだ。名簿を預けた先の管理者、つまり外部テナントの管理者アカウントが乗っ取られたら、全員分が出るのだ。」

🟣 イタコ:
「管理者には多要素認証を必ず掛けて、人数を絞って、普段は権限を外しておくのですわね。」

🟢 ずんだもん:
「名簿が消えたのではなく、守る場所が自分の DB からテナントの管理者に移ったのだ。」

6. Entra External ID の MAU 課金で、お値段の話なのだ

6-1. 試算の前提

🟣 イタコ:
「ここからは、わたくしの出番ですわ。あるある設計と持たない設計で、変わるところだけを比べます。DB、WAF、監視、ストレージは、どちらにも同じものが要りますから外しましたの。」

🟣 イタコ:
「単価は、Azure の公開価格の API で取った東日本リージョンの円建ての小売価格ですわ（2026 年 10 月 29 日時点）。」

項目	単価
VM（D2s v5・Linux）	1 台月 14,261 円
VPN Gateway（VpnGw1）	月 21,852 円
SWA Standard	1 アプリ月 1,417.95 円
Functions Flex の無料分	月 10 万 GB 秒と 25 万回
Functions Flex の時間の超過分	1 GB 秒 0.0041 円
Functions Flex の回数の超過分	10 回 0.0006 円
External ID の無料分	5 万 MAU まで
External ID の超過分	1 MAU 4.7265 円

🟣 イタコ:
「置いた仮定は、次のとおりですわ。」

利用者 1 人が月に 60 回 API を呼び、1 回あたり 0.1 GB 秒を使う。
あるある設計の VM は、MAU 3 万で 2 台、10 万で 3 台、30 万で 4 台にする。
運用の手間は時間単価 1 万円で数える。あるある設計は、VM 1 台のパッチに月 2 時間、自前のログインの保守に月 8 時間かかる。持たない設計は、全部で月 4 時間かかる。
Functions の常時使用可能のインスタンス（3-5）は入れていない。2 GB を 1 台置くと、月約 3,150 円増える。

6-2. 前後の差

MAU	あるある	持たない	差
3 万	月 17.0 万円	月 4.2 万円	年 154 万円安い
10 万	月 20.5 万円	月 28.0 万円	年 91 万円高い
30 万	月 23.9 万円	月 123.1 万円	年 1,191 万円高い

🟢 ずんだもん:
「MAU 3 万なら、持たない方が年 154 万円も安いのだ！」

🟣 イタコ:
「MAU が 5 万までは External ID が無料ですから、VM と VPN が要らないぶん安くなりますの。そこから先は、External ID の料金が一番大きな費目になりますわ。30 万 MAU なら、External ID だけで月約 118 万円ですの。」

🔴 きりたん:
「どこで逆転するの？」

🟣 イタコ:
「この仮定で MAU 8.5 万前後ですわ。運用の手間を数えなければ、6.4 万前後ですの。」

🟢 ずんだもん:
「受付会社の料金が高いのだ……。」

6-3. 漏れたときの値段

🟣 イタコ:
「一方、漏れたときに会社が払った額は、桁が違いますわ。」

事例	1 人あたりのお詫び	会社が計上した損失
通信教育大手（2014 年）	500 円の金券	特別損失 260 億円
カーシェア大手（2026 年）	3,000 円	特別損失 55 億円
出版大手（2024 年）	記載なし	特別損失 24 億円

カーシェア大手は、本人確認書類の画像が外へ送られた 146 万 4,800 件の利用者に、3,000 円を払う。55 億円の特別損失のうち、お見舞金は約 44 億円。
補償の有無や額は、会社ごとに違う。この記事では、500 円を控えめな見積もり、3,000 円を大きめの見積もりとして使う。
お詫びの品のほかに、調査と対応の費用がかかる。JNSA のインシデント損害額調査レポートでは、フォレンジック調査が 300〜400 万円から、コールセンターが 3 か月で 700〜1,000 万円、1 万人へのお詫び状の郵送が約 130 万円。
IBM の 2026 年の調査では、データ侵害 1 件あたりの世界平均は 499 万ドル。

🔴 きりたん:
「2026 年の改正で、個人情報保護法に課徴金ができたって聞いたけど？」

🟣 イタコ:
「7 月に成立した改正ですわね。課徴金の対象は違法な第三者提供などで、攻撃による漏えい（安全管理措置の不備）は対象外ですの。漏えいの値段は、今も、お詫びと対応費と信用で決まりますわ。」

6-4. 損益分岐

🟣 イタコ:
「持たない設計で増える年の費用を、1 回漏れたときの損失で割ると、『年に何 % の確率で漏れる会社なら元が取れるか』が出ますわ。会員の数は MAU の 3 倍、調査と対応の費用は 2,000 万〜3,000 万円と置きましたの。」

MAU	1 回の損失（500 円）	分岐（500 円）	分岐（3,000 円）
3 万	0.65 億円	最初から得	最初から得
10 万	1.75 億円	年 0.52%	年 0.10%
30 万	4.8 億円	年 2.5%	年 0.44%

🔴 きりたん:
「比べる物差しは？」

🟣 イタコ:
「2025 年に上場企業とその子会社が公表した『ウイルス感染・不正アクセス』による漏えいは 116 件で、東証の上場会社 3,782 社（2025 年末のプライム・スタンダード・グロースの合計）で割ると、年約 3% になりますわ。子会社を含み、公表された分だけですから、粗い物差しですけれど。ランサムウェアや委託先経由も含む全部の漏えいの率ですから、Web の会員 DB だけの率ではありませんの。」

🟢 ずんだもん:
「MAU 30 万までは、控えめな 500 円の見積もりでも、損益分岐（年 2.5%）が物差しを下回るのだ！」

🔴 きりたん:
「でも、持たない設計で全部防げるとは限らないでしょ。4 章には 🔶 もあったし。」

🟣 イタコ:
「そのとおりですわ。この分岐は、1 回の損失を全部防げると置いた、効き目の上限での見積もりですわ。防げる分を半分と置くと、分岐は 2 倍になりますの。MAU 30 万なら、500 円で年 5.0%、3,000 円で年 0.87% ですわ。」

MAU	500 円（全部）	500 円（半分）	3,000 円（全部）	3,000 円（半分）
10 万	年 0.52%	年 1.04%	年 0.10%	年 0.20%
30 万	年 2.5%	年 5.0%	年 0.44%	年 0.87%

🟢 ずんだもん:
「500 円の見積もりで『30 万までは元が取れる』と言えるのは全部防げる場合で、3,000 円なら半分でも物差しを下回るのだ。」

🔴 きりたん:
「30 万で区切ったのは、なんで？」

🟣 イタコ:
「500 円の見積もりで分岐が年 3% に並ぶのは、全部防げる場合で MAU 55 万前後ですの。物差しの粗さを考えて、この記事は 30 万までを前提にしましたわ。3,000 円の見積もりなら、この仮定では MAU がどれだけ増えても、分岐は年 0.63%（半分なら 1.26%）を超えませんの。」

🟢 ずんだもん:
「しかも持たない設計では、業務 DB に氏名や住所が無いから、漏れたときに出ていく項目が減るのだ。利用者の ID と注文は、名簿と照らせば本人に結びつくから個人情報のままだけど、お詫びの範囲は出ていった項目で決まるから、実際の差は表より縮むと推定するのだ。」

🔴 きりたん:
「ほかの IDaaS とは比べたの？」

🟣 イタコ:
「MAU 課金はどの IDaaS にも共通の形で、単価は製品によって違いますわ。AWS の Amazon Cognito の Lite プランなら、30 万 MAU で月約 1,415 ドルですの（External ID は約 7,500 ドル）。機能の範囲も違いますから、MAU が 30 万を超えて伸びる見込みなら、比べてから選ぶのがよさそうですわ。」

7. まとめ：Entra ID で個人情報漏えい対策はできるのか

🔴 きりたん:
「最後にまとめて。で、タイトルの答えは？」

🟢 ずんだもん:
「半分はできるのだ。 認証と鍵と名簿は、Entra ID に預けられるのだ。API が本人の行だけを返すこと、配備の経路を絞ること、外部テナントに残る資格情報と管理者を守ることは、自分の仕事として残るのだ。」

🟢 ずんだもん:
「まとめると、こうなのだ。」

2026 年の漏えいの原因の一つは、公開アプリを解析して裏の API を知り、アプリを通さずに API を直接呼ぶ手口だった（NICT の A2B 攻撃、JPCERT/CC のケース B）。
アプリの解析は防げない。隠すより、読まれても困らない作りにする。
あるある設計で読まれた後に狙われる弱点は、API が本人かを確かめないこと、鍵をアプリに埋めること、会員のパスワードを持つこと、個人情報を全部写すこと、DB の鍵を設定ファイルに書くこと、OS を自分で守ることの 6 つ。
持たない設計では、認証を Entra External ID と Easy Auth に、鍵を Entra のマネージド ID に、名簿を External ID の属性とトークンに預け、OS を SWA と Functions に任せる。API の本人確認と、全員分を読む権限の切り分けは、規律として残る。
外部テナント側の資格情報は 1〜2 本残るので、Key Vault と期限で管理する。一斉配信の Graph 用は、Azure 側のマルチテナントのアプリとマネージド ID で鍵を持たずに済む。
中でコードを動かされたら、Entra のマネージド ID は使われる。そのぶん、守る場所は、アプリのコード・配備の経路・External ID の管理者に絞られる。
MAU 5 万までは安くなり、そこから先は External ID の料金で高くなる。3,000 円の見積もりなら MAU 30 万まで元が取れる。500 円の見積もりでは、損失が全部防げる場合に限る。
MAU 30 万を狙うなら、External ID のオブジェクト数とサインインの集中、SWA に大量のアクセスが来たときの挙動を、作る前に Microsoft に確かめておく。

🔴 きりたん:
「で、なんもわからんおじさんは、結局どうするの？」

🟢 ずんだもん:
「APK はいくらでも解析していいのだ！中には、鍵も名簿も入っていないのだ！😤」

🟣 イタコ:
「閉館後の図書館に残るのは、本と、名前の書いていない貸出記録だけですものね。そのかわり、受付会社への支払いは毎月ですわ。MAU 30 万なら、External ID だけで月約 118 万円ですの。」

🟢 ずんだもん:
「……ぼくのお小遣いでは払えないのだ。」

🔴 きりたん:
「大丈夫よ。ずんだもんのアプリに、30 万人も来ないから。」

🟢 ずんだもん:
「MAU 5 万までは無料なのだ！ぼくのアプリは、永遠に無料枠なのだ！」

🟣 イタコ:
「それは、設計ではなく人気の問題ですわね。」

🟢 ずんだもん:
「……なんもわからんおじさん、泣いていいのだ？😭」

関連記事・参考リンク

利用キャラクター

ずんだもん：VOICEVOX:ずんだもん
東北きりたん：VOICEVOX:東北きりたん
東北イタコ：VOICEVOX:東北イタコ

本記事で使用しているキャラクター画像の著作権は、それぞれの権利者に帰属します。
非商用目的での利用に基づき掲載しています。