設問１

（２）X社が運用・保守を行う機器からX社FWの方向に確立されるTCPコネクションだけを許可する

前提：
　・TCPコネクション確立要求は、工場からX社の方向に行われる
　（＝インターネット側からのSYN要求は来ない）

以上の前提より、「X社が運用・保守を行う機器からX社FWの方向に確立されるTCPコネクションだけを許可する」こと以外に許可をする通信はないことが分かる。

（２）クライアント証明書を配布してクライアント認証を行う

前提：
　TLSでは以下のフローのように双方の正当性を確認できる👇

上図より、クライアント証明書を配布してクライアント認証を行うことでなりすましを防ぐことができる。
また、クライアント証明書のCNには各デバイスのデバイス名(CN=Device-1)を割り当てることで個々のデバイスを識別できるようになっている。

設問２

（１）TCPの送信処理中に、デバイスの電源断などでTCPコネクションが解放された場合

TCPの再送制御が「無力化してメッセージが消えてしまう（＝消失を防げない）」最大の原因は、「通信の土台（TCPコネクション）自体が消滅してしまうこと」。
具体的なシナリオで考えてみよう。

1. QoS 0 なので、MQTT層の確認（PUBACKやPUBRECなど）はない。「投げっぱなし」。
2. アプリが「このデータを送るぞ」と指示を出し、OSのTCPバッファにデータが入って送り出そうとした瞬間、または送信途中に、工場のデバイスの電源がプツッと落ちたとする。
3. 電源が落ちた瞬間、OSは終了するため、当然TCPコネクションは強制的に破棄（解放）される。
   電源が落ちる＝メモリが完全リセットされ、TCPセッションの記憶が1バイト残らず消滅＝再起動ができても古いセッションを再開させることはできない。
4. TCPコネクションが消滅してしまったら、TCP層の再送機能（「さっきのパケットのACKが返ってこないからもう一回送るぞ」という制御）は、もう送るべき宛先もセッションも存在しないため、一切機能しない。
5. 結果として、バッファに残っていたデータや送信中のメッセージは完全に消失する。

これが、問題文にある「TCPの送信処理中に、デバイスの電源断などでTCPコネクションが解放された場合」という現象の正体。

Q.L4部分は正常だがL7の部分で不整合が~のような回答は正解なの？

よくある回答として、「パケットのL4部分は正常だがL7の部分で破損が生じた場合」という回答がある。一見、正しそうだが本問題においては趣旨がずれた回答になる。
ここで問われているのは、「アプリケーションのロジックや不整合」ではなく、「TCPというプロトコルが持っている『再送機能』の限界・弱点が露呈するのは、物理的にどういうシチュエーションか」という点。
もし「L4部分は正常だがL7の部分で不整合が…」などと答えてしまうと、肝心のTCPのメカニズム（コネクションと再送制御の関係）に話が及んでいないため、試験の模範解答のキーワードから外れてしまう。

（３）オ：SUBSCRIBE　カ：config/Di　キ：デバイスDi　ク：交換サーバ　ケ：業務サーバ

オ：SUBSCRIBE
　　本文中に「クライアントは、サーバにSUBSCRIBEを送信する」という部分があるので空欄オにはSUBSCRIBEが入る

　カ：config/Di
　項番１を見るとトピック名はconfig/Diなので、そのまま抜粋する

　キ：デバイスDi　ク：交換サーバ
　PUBLISHが保存され、稼働再開後に再送されるということは配信元サーバ側であることが分かる。そのため空欄クには交換サーバが適切である。
　で、クが交換サーバであることが分かればそのペアである、デバイスDiが空欄キに入ることが分かる。

ケ：業務サーバ
　図４中にある文をそのまま抜粋すればよい。そのため、業務サーバが入る。

設問３

（２）10

Q.そもそもアクセストークンとリフレッシュトークンの違いは？

• アクセストークン（Access Token）
  • 役割: 業務サーバ（API）に直接アクセスしてデータを取得するための「一時的な入場パスポート」。
  • 特徴: 有効期限はあえて短く（今回の問題では10分間）設定されている。APIにアクセスするたびに毎回これを提示する。
• リフレッシュトークン（Refresh Token）
  • 役割: アクセストークンが期限切れになったとき、新しいアクセストークンを再発行してもらうための「引き換え券（専用のパスポート）」。
  • 特徴: 有効期限は長め（今回の問題では60分間）に設定されている。APIには直接アクセスできず、認可サーバとの間でのみ使われる。

もし、リフレッシュトークンがないと….
アクセストークンが期限切れになるたびに認可サーバと認証のためのやり取りを要する必要が出てくる。
一方、リフレッシュトークンがあれば…
そのフローをスキップしてリフレッシュトークンを提示すればアクセストークンがもらえるというわけである。

以上のプロセスよりアクセストークンは10分おきに更新がかかるようになっている。そのため、設問の変更が反映されるタイミングは10分後となる。

（３）WebAPのURIを固定にし、絶対URIを事前に通知してもらう

前提整理：
　Q.認可要求のredirect_uriが書き換えられたらどうなる…?
　→本来は顧客サーバ(WebAP)に届くはずのトークンが攻撃者サーバに渡ってしまいなりすましが発生する
　Q.HTTPリクエストに含まれるURIって何？
　→認可要求に含まれるredirect_uriのこと。このredirect_uriにはWebAP(顧客サーバ)で待ち受けているuriを指定する
　Q.あらかじめ登録されている絶対URIって何？
　→認可サーバ側（X社）に、「この顧客（WebAP）の正規の返却先はあらかじめこのURLです」と事前登録してあるデータのこと。
　Q.なんでHTTPリクエスト内のURIと事前準備の絶対URIの２つが必要なの？
　→１人のクライアントが複数のAPIを呼び出す可能性があるから。

以上の前提より回答は「WebAPのURIを固定にし、絶対URIを事前に通知してもらう」となる。

p.3 Q.MQTTって何

MQTT(Message Queuing Telemetry Transport)とは、IoTなどでよく使われる軽量なメッセージ通信プロトコル。
簡単に言うと、デバイス同士が直接通信するのではなく、間にMQTT Brokerという中継サーバーを設けて通信する仕組み。
各デバイスはそれぞれBrokerにTCP接続しておけばよく、デバイス同士で個別にセッションを確立する必要がない。
そして、情報を送る側はBrokerにPublish（送信）し、情報を受け取る側は必要なTopicをSubscribe（購読）しておくことで、Broker経由で情報を受信できる。
そのため、デバイス同士の接続関係をシンプルにでき、複数のデバイスへの情報配信や通信管理が容易になる。
また、メッセージを保持する機能などもあるため、IoTのような通信環境でも使いやすいプロトコル。

p.3 Q.APIって何？

API(ApplicationProgrammingInterface)とは、あるアプリケーションやシステムが持っている機能を、外部の別のプログラムから利用するための窓口・ルール。

具体的なシナリオ
１．LINEがメッセージ送信用のAPI用のURLを公開する
２．企業Aは自社プログラム内に当該APIのURLを埋め込む
３．条件を契機にURLを呼び出す
　URLだけでなく、通常はHTTPの「POST」という方式を使い、中身（ボディやヘッダー）に以下の情報を詰め込んで送る。
　アクセストークン: 「うちは正当な権限を持った企業Aです」というパスワード（証明書）
　宛先: 誰に送るか（ユーザーIDなど）
　メッセージ内容: 「こんにちは！」などの文章
４. LINE側のサーバが「認証・認可」を行う
　・何が起きるか: LINEのサーバがそのリクエストを受け取った瞬間、一番最初にやるのが「このリクエストは本当に許可されたアプリからのものか？」のチェック。
　・チェック内容: 一緒に送られてきたアクセストークンを見て、「お、このトークンは企業Aのものだな。有効期限も切れてないな」と確認。ここで不正なトークンであれば、即座にエラー（401 Unauthorizedなど）を返して弾く。
５. LINE側のサーバがメッセージを処理してプッシュ送信する
　・何が起きるか: 認証が無事に通ると、LINEのサーバは受け取ったメッセージの中身を読み解く。
　・実際の動作: 「なるほど、ユーザーBさんにこの文章を送ればいいんだな」と理解したLINEのサーバは、自社のインフラを使って、対象のユーザーのスマホアプリに向けてメッセージをピコーンとプッシュ通知（配信）。
６. 自社プログラムが「成功したよ」というレスポンスを受け取る
　・何が起きるか: メッセージの送信処理が終わると、LINEのサーバは自社プログラムに対して「ちゃんと送れたよ！（HTTP 200 OK）」という返事（レスポンスデータ）を返す。
　・完了: 自社プログラム側でその「成功」の返事を受け取った時点で、一連の自動送信処理が完了。

p.4 Q.PUBRELとPUBCOMPって何？

PUBRELのメッセージのリリース通知とは「じゃあ、実際にそのメッセージの処理を実行していいよ！」と実行許可を出すメッセージ。
PUBCOMPのメッセージ送信終了の通知とは、「PUBRELをうけとったから正式に処理を完了したよ！これでこの通信セッションは完全に終わり！」というメッセージ。

1. PUBLISH（送信側 ➡️ 受信側）
   • 「このメッセージを送るね！」（データ本体を渡す）
2. PUBREC（受信側 ➡️ 送信側）
   • 「メッセージ受信の通知」: 「PUBLISHをちゃんと受け取ったよ！」（これで受信側はデータを一時保存する）
3. PUBREL（送信側 ➡️ 受信側）
   • 「メッセージリリースの通知」: 「受け取りを確認した！じゃあそのメッセージを正式に確定（リリース）して処理してくれ！」というゴーサイン。
4. PUBCOMP（受信側 ➡️ 送信側）
   • 「メッセージ送信終了の通知」: 「了解、正式に処理を完了したよ！これでこの通信セッションは完全に終わり！」という最終確認。

p.8 Q.RTTの２倍に等しいってどういうこと？

前提：
　・図５はQoSレベル2を説明した図
　・QoSレベル２はPUBLISH、PUBREC、PUBREL、PUBCOMPの４メッセージからなる。
　（１つの処理に４メッセージ＝2往復かかる）

以上の前提より、１つのメッセージでは2往復を要するため、RTTの２倍に等しいという結論が出る。

Q.トークンってそもそも何？

トークンとは、認証や認可のために使われるデータで、ユーザーやクライアントの識別、認証状態、アクセス権限などを確認するためのもの。
基本的にはただの「文字列（英数字や記号の羅列）」だけど、その中身の持ち方によって大きく2つのタイプ（OpaqueTokenとJWT）に分かれている。
それらを見ていこう！

① Opaque Token（参照トークン）

OpaqueTokenとは抽選番号のようなランダムな文字列（例：a8f92bc7d1e4...）をトークンとして扱う方式。このトークン自体には意味は含まれていない。

👇フロー

１．認可サーバがトークンを発行してユーザに渡す
２．ユーザがauthorizationヘッダーにトークンをつけてWebAPIにアクセスする　
３．業務サーバはこれを受け取ると「これ有効？」と認可サーバに裏で問い合わせに行く。
４．認可サーバが当該トークンを内部情報と参照して以下👇の有効性を返す。

{
  "active": true,
  "sub": "user123",
  "scope": "account:read profile:read",
  "exp": 1790000000
}

active：トークンが有効かどうか
sub：誰に紐づくトークンなのか
scope：どのような操作を許可されているか
exp：いつ有効期限が切れるか

５．認可サーバの情報と以下を比較して、許可できると判断したらAPIの処理を実行する。
　・トークンは有効か？
　・有効期限は切れていないか？
　・要求された操作に必要な権限があるか？
　・必要なら、そのユーザーが対象リソースにアクセスできるか？
→正当性が確認できたら当該処理を許可する

② JWT（JSON Web Token）

文字列の中に、「誰に対して」「どのAPIの権限（スコープ）を許可して」「いつまで有効か」という情報（JSONデータ）が丸ごと詰め込まれているトークン。

👇JWTの構成

#JWTはHeader.Payload.Signatureの３部分から構成されている

#Header
{
  "alg": "RS256",
  "typ": "JWT"
}

#Payload
{
  "sub": "user123",
  "scope": "read write",
  "exp": 1790000000
}

#Signature
x7Kp...（署名データ）

👇認証フロー

１．認可サーバがユーザにJWTを発行する
２．ユーザがJWTをauthorization ヘッダーにつけてAPIへアクセスする
３．API側がJWTを検証する
　①認可サーバの公開鍵でSignature内の署名データを復号
　②API側でもJWTのハッシュを作成する
　③①と②の値が一致したら正当なトークンであると判断
４．トークン内のPayloadと現在アクセスしているユーザ・ユーザの操作等を比較し正当性を判断
　→正当であれば当該処理を許可する

Q.URLとURIの違いって何？

• URI（Uniform Resource Identifier / 統一資源識別子）
  • 「ネット上のあらゆるリソース（場所、名前、データなど）を特定・識別するための住所（識別子）の総称」。
  • 「ここにあるよ」と指し示すもの全てがURIに含まれる。
• URL（Uniform Resource Locator / 統一資源位置子）
  • 「そのリソースがネット上のどこに『あるか（場所・アクセス方法）』を示すもの」。
  • 

    Example Domain

    

    example.com
    (https://example.com/api) のように、プロトコル（https://）やドメイン名を使って「実際の場所」まで具体的に指し示すものはすべてURLになる。

つまり、世の中にあるすべてのURLは、URIの一種（部分集合）。「すべてのURLはURIだけど、すべてのURIがURLというわけではない」という関係になっている。 （※ちなみに、場所ではなく「名前」で識別する「URN」というものもあるが、ITの世界ではほぼURLの形をとるため、まとめて「URI」と呼ぶことが多い）

Q.URIと情報取得までのフロー

疑問点：
　client-idはいつ指定されるの？
　client-idはユーザに個別ではなくWebAPのclient-idってこと？　
　顧客サーバ配下のユーザごとの認証はするの？一度WebAPが認可コード得たら他のユーザでも使えちゃうのでは？

１．情報要求
　①ブラウザ上の画面で「この機器の情報がほしい！」とボタン等をクリックすると、ブラウザの裏側では以下のような HTTPリクエスト（基本はGETメソッドなど） が顧客サーバ（WebAP）に向けて飛ぶ。
　②ブラウザは、そのボタンに紐づいたパス（例: GET /devices/info-01 HTTP/1.1）を含んだリクエストを、顧客サーバのFQDN宛てに送信する。

２．リダイレクト応答
　①authorizationヘッダに認証情報が付与されていない場合に、認証情報が付与されていないと判断。
　②顧客サーバ（WebAP）は、302 Found と一緒に Location ヘッダに「次はこのURLに飛んでね」という宛先を書いてPCに返す

HTTP/1.1 302 Found
Date: Thu, 12 Nov 2026 07:44:00 GMT
Content-Type: text/html; charset=UTF-8
Location: https://auth.example.com/authorize?response_type=code&client_id=customer_ap_001&redirect_uri=https://app.customer-company.com/oauth/callback
Content-Length: 0

#Q.リダイレクト先だけ言われても、PCは一体どんな情報を自分で考えて流せばいいのか困っちゃうんじゃないの？
#A.PCが自分で情報を考えて付け足す必要は一切ない。なぜなら、先ほどの Location ヘッダーに書かれているURLには、「次に持って行くべき荷物（パラメータ）が最初から全部セットで書き込まれているから。
#response_type=code （認可コードをちょうだいという指定）
#client_id=customer_ap_001 （私はこのWebAPシステムですという身分証）
#redirect_uri=https://... （終わったらここに返してねという宛先）

３．PCが認可サーバに認可要求
　Locationヘッダーの情報からGETリクエストを送信する

GET /authorize?response_type=code&client_id=customer_ap_001&redirect_uri=https://app.customer-company.com/oauth/callback HTTP/1.1
Host: auth.example.com

４．認可サーバ⇔PC間で認証を実施する

５．認可応答
　PCのユーザ認証が成功したら、認可応答を返す

６．PCからリダイレクト
　認可応答のLocationヘッダーをもとにGETリクエストを作成して、redirect先に送信する

７．トークン要求
　WebAPが認可サーバへトークン要求を実施

８．トークン応答
　認可サーバは、認可コード等を確認しAPIの権限に正当性を確認できたらトークンを発行する。

９．アクセス要求
　トークンを受け取ったらアクセス要求をする