ネットワーク通信を正しく理解するためには、ポート番号やトランスポート層の役割を押さえることが不可欠です。
特にTCPやUDPといった代表的なプロトコルの違いを理解することで、通信トラブルの回避やセキュリティ対策にもつながります。
本記事では、ポート番号の基本的な仕組みと、TCP/UDPそれぞれの特徴、実務での使い分け方を詳しく解説していきます。
トランスポート層の役割と重要性
ネットワーク通信は複数の層によって成り立っており、その中でもトランスポート層は通信の信頼性を担保するために非常に重要な役割を果たします。
ユーザーが送信したデータが、正しく、順序通りに、完全な形で相手に届くよう制御を行うのがこの層の主な仕事です。
ここでは、OSI参照モデルにおけるトランスポート層の位置づけから、その通信制御の仕組み、さらにはポート番号との関係まで、網羅的に解説していきます。
OSI参照モデルにおけるトランスポート層の位置
トランスポート層は、OSI参照モデルにおける第4層に位置しています。
トランスポート層について
「Transport（トランスポート）」は「運ぶ・届ける」という意味があります。トランスポート層の役割は、データを正しいアプリ（アプリケーション）まで届けることです。 ただ「相手のコンピュータに届けば終わり」ではなく、どのアプリに渡すのか（ポート番号で識別）までしっかり管理します。 たとえば、Webならポート番号80番（HTTP）、メールなら25番（SMTP）といった具合に、通信の宛先アプリを正確に指定して届けます。
上位にはセッション層やプレゼンテーション層、下位にはネットワーク層やデータリンク層が存在します。
この構造の中で、トランスポート層はアプリケーションから渡されたデータをセグメントに分割し、通信相手の正しいアプリケーションへ届けるための処理を担当します。
通信においては、各層が独自の責務を持っており、トランスポート層は「エンド・ツー・エンド」の通信制御という非常に重要な部分を担います。
つまり、通信の始点から終点までの間で、信頼性を保ったデータ転送を保証するのです。
トランスポート層で行われる通信制御とは
トランスポート層では、いくつかの通信制御機能が提供されています。（上図のL4:TCPデータ範囲）
主に以下のような処理が行われます。
- データの分割と再構成
- 順序制御（パケットの並び順保持）
- 再送制御（パケットロス時の再送処理）
- 誤り検出と訂正
- フロー制御（送信側と受信側の処理速度を調整）
これらの制御により、通信経路で一部のパケットが欠損した場合や、順序が乱れた場合でも、受信側は正しくデータを復元することができます。
特にTCP（Transmission Control Protocol）では、こうした機能がすべて実装されており、高信頼な通信を実現しています。
一方で、UDP（User Datagram Protocol）はこれらの制御を行わない代わりに、高速かつシンプルな通信が可能です。
用途によってTCPとUDPを使い分けることが、ネットワーク設計では求められます。
トランスポート層とポート番号の関係
トランスポート層の重要な構成要素のひとつがポート番号です。
ポート番号は、通信の宛先となるアプリケーションを識別するための番号で、TCPやUDPにおいて送受信の目印として機能します。
同じ端末上で複数のアプリケーションが同時に通信を行うことがありますが、その際にどのアプリケーションにデータを渡すかを判断するために、このポート番号が使われます。
たとえば、ウェブ通信では通常TCPの80番ポートが、メールの送信にはSMTPで25番ポートが使用されるなど、用途に応じたポート番号が決まっています。
こうしたポート番号の知識があることで、通信の監視やトラブルシューティング時に原因を迅速に特定できるようになります。
また、ファイアウォールやルーター設定においても、どのポートを開放するかが重要なセキュリティ項目になります。
ポート番号の基礎知識
ネットワーク通信において、ポート番号はトランスポート層の重要な要素です。
IPアドレスが宛先ホストを識別するのに対し、ポート番号はそのホスト内でどのアプリケーションと通信するかを特定します。
サーバーやクライアントが正しく動作するには、適切なポート番号の理解と設計が不可欠です。
ここでは、ポート番号の基本からその分類、アプリケーションとの関係までを丁寧に解説していきます。
ポート番号とは何か
ポート番号は、IP通信においてアプリケーション単位で通信先を識別するための番号です。
TCPやUDPなどのトランスポート層プロトコルでは、この番号を使って特定のアプリケーションにデータを届けます。
たとえば、同じホストに複数のアプリケーションが動作していても、HTTPはポート80、SSHはポート22というように、それぞれが固有の番号で管理されることで衝突せずに同時通信が可能になります。
また、ポート番号は16ビットの整数として表現され、0から65535までの範囲を取ります。
この中で一部の番号は特定の用途に予約されており、任意に使用すると予期せぬ衝突や誤動作の原因になるため注意が必要です。
ポート番号の分類（ウェルノウン、登録済み、動的）
ポート番号は用途に応じて以下の3つに分類されます。
| 分類 | 番号範囲 | 用途 |
|---|---|---|
| ウェルノウンポート | 0～1023 | 主要な標準アプリケーションが使用（HTTP, FTPなど） |
| 登録済みポート | 1024～49151 | ユーザーアプリケーションが申請して使用 |
| 動的／プライベートポート | 49152～65535 | 一時的なクライアント通信などに使用 |
ウェルノウンポートはIANA（Internet Assigned Numbers Authority）により厳格に管理されており、サーバー用途ではこれらを適切に設定することで、ユーザーの接続性を確保できます。
一方で、動的ポートは特にクライアントが外部に接続する際に自動的に割り振られ、手動で指定することは稀です。
アプリケーションとポート番号の紐付け
通信を行う際、各アプリケーションはあらかじめ決められたポート番号で待機している必要があります。
たとえば、Webサーバーであれば通常はポート80（HTTP）や443（HTTPS）を使用します。これはブラウザなどのクライアントが、暗黙的にこれらの番号を宛先として接続を試みるためです。
サーバー側で誤ったポート番号を設定してしまうと、通信が確立されず「接続できない」といったトラブルの原因になります。
実際の現場では、セキュリティ対策の一環として、デフォルトからポート番号を変更するケースもありますが、その際にはクライアント側にも設定変更が必要になります。
よく使われる代表的なポート番号一覧
以下は業務で頻繁に登場する代表的なポート番号の一覧です。
| プロトコル | ポート番号 | 用途 |
|---|---|---|
| HTTP | 80 | Web通信（非SSL） |
| HTTPS | 443 | Web通信（SSL/TLS） |
| SSH | 22 | リモートシェル接続 |
| FTP | 20, 21 | ファイル転送 |
| SMTP | 25 | メール送信 |
| DNS | 53 | 名前解決（UDP/TCP両用） |
| MySQL | 3306 | データベース接続 |
| PostgreSQL | 5432 | データベース接続 |
| Flask | 5000 | Pythonアプリケーション開発用 |
| Tomcat | 8080 | Javaアプリケーション（HTTP） |
これらのポート番号は暗記する必要はありませんが、ネットワークやアプリケーションのトラブルシューティング時には役立つ知識です。
特に、ファイアウォールやルーターの設定において通信が遮断されている原因を調査する際、ポート番号の知識は必須となります。
TCPとUDPの違いと使い分け
TCPとUDPは、トランスポート層で用いられる主要なプロトコルであり、アプリケーションごとに適切な選択が求められます。
トランスポート層には、TCP（Transmission Control Protocol）とUDP（User Datagram Protocol）という2つの代表的なプロトコルがあります。TCPは信頼性を重視し、UDPは速度を重視したプロトコルです。たとえば、TCPはWeb通信（HTTPSなど）で使われ、UDPは動画配信やオンラインゲームなど、多少のデータ欠損が許される場面で使われます。
それぞれの特性を理解し、通信要件に応じて最適なプロトコルを選定することは、ネットワーク設計において非常に重要です。
ここでは、TCPとUDPの具体的な特徴や代表的な利用例、そして使い分けの判断基準について解説します。
TCPの特徴と適用例
TCP（Transmission Control Protocol）は、信頼性の高い通信を実現するためのプロトコルです。
パケットの到達確認（ACK）、順序制御、再送制御、輻輳制御といった機能を備えており、正確なデータ転送が求められる場面で使用されます。
主な特徴は以下の通りです。
- コネクション型通信（接続の確立と終了処理が必要）
- 通信の信頼性が高い（パケットロス時の再送、順序保証）
- 通信量や処理コストがUDPよりも高い
代表的な適用例：
- Web通信（HTTP/HTTPS）
- メール送受信（SMTP、IMAP、POP3）
- ファイル転送（FTP、SFTP）
- リモートアクセス（SSH、Telnet）
これらの用途では、データの欠損や順序の乱れが致命的なエラーとなるため、TCPのような信頼性の高い通信手段が不可欠です。
TCPヘッダの構造
TCPヘッダは、次のような順序と大きさで書き込むように定められています。ビット列なので、数字は２新法で表示されます。
| フィールド名 | 長さ（ビット） | 説明 |
|---|---|---|
| 送信元ポート番号 | 16ビット | データ送信元のポート番号 |
| 宛先ポート番号 | 16ビット | データ送信先のポート番号 |
| シーケンス番号（Sequence Number） | 32ビット | 送信したデータの順序を示す番号 |
| 確認応答番号（Acknowledgment Number） | 32ビット | 受信側からの応答。次に期待するシーケンス番号 |
| データオフセット | 4ビット | TCPヘッダの長さを表す（オプション含む） |
| 予約領域 | 3ビット | 将来の拡張用（現在は未使用） |
| 制御フラグ | 9ビット | URG: 緊急ポインタ有効 ACK: 確認応答有効 PSH: 即時転送指示 RST: 強制切断 SYN: 接続開始 FIN: 通信終了 |
| ウィンドウサイズ | 16ビット | 受信側のバッファ許容量（フロー制御） |
| チェックサム | 16ビット | データ誤り検出用 |
| 緊急ポインタ | 16ビット | URGフラグ使用時の優先データ位置 |
| オプション（任意） | 可変長 | MSSやウィンドウスケーリングなどの追加情報 |
| パディング | 可変長 | ヘッダ長を32ビットの倍数に調整するための埋め草 |
3ウェイハンドシェイクとは？（通信開始）
3ウェイハンドシェイクとは、TCP通信において接続を確立するための3ステップのやり取りです。送信側と受信側が互いに「通信してもいいかどうか」を確認し合うことで、安全で信頼性のある通信を開始できます。
| ステップ | 送信元 | 受信先 | 送信フラグ | 説明 |
|---|---|---|---|---|
| ① | クライアント | サーバ | SYN | 「通信したい」とリクエスト（初期シーケンス番号も送信） |
| ② | サーバ | クライアント | SYN + ACK | 「OK、準備できてるよ」と返す（自身の初期番号とACKを送信） |
| ③ | クライアント | サーバ | ACK | 「じゃあ通信開始ね」と応答し、接続が確立される |
この手順によって、通信の双方が「送る準備がある」「受け取る準備がある」ことを明確に確認し、パケットの順序や信頼性を保証できるようになります。
4ウェイハンドシェイクとは？（通信終了）
通信を開始するには「3ウェイハンドシェイク」が必要でしたが、通信を終了する際には「4回」のやり取りが必要になります。これが4ウェイハンドシェイク（Four-Way Handshake）です。
なぜ回数が増えるのかというと、TCPでは送信と受信の終了をそれぞれ別々に確認する必要があるためです。つまり、「もう送らない」だけでなく「もう受け取らない」もお互いに伝え合う必要があるのです。
| ステップ | 送信元 | 受信先 | 送信フラグ | 説明 |
|---|---|---|---|---|
| ① | クライアント | サーバ | FIN | 「もう送るデータはない」と送信終了を伝える |
| ② | サーバ | クライアント | ACK | 「了解、まだ受信中だけど送信は停止」と応答 |
| ③ | サーバ | クライアント | FIN | 「自分も送信を終了する」と通知 |
| ④ | クライアント | サーバ | ACK | 「了解、これで通信終了」と最終確認 |
このようにして、TCPは**一方的な切断ではなく、互いに確認しながら丁寧に通信を終了させる**ことで、中途半端な切断やデータ損失を防いでいます。
TCPフラグ6種の説明
TCPヘッダには、通信状態を管理するための6つの「制御フラグ」があり、1ビットずつで構成されています。それぞれの意味と用途は以下のとおりです。
| フラグ名 | ビット値 | 意味 | 主な用途 |
|---|---|---|---|
| URG | 001000 | 緊急フラグ（Urgent） | 今すぐ処理すべきデータがあることを示す |
| ACK | 010000 | 確認応答（Acknowledge） | 相手のデータを受け取ったことの通知 |
| PSH | 000100 | プッシュフラグ（Push） | 今すぐアプリ層にデータを渡すよう指示 |
| RST | 000010 | リセット（Reset） | 通信を強制終了させたいときに使用 |
| SYN | 000001 | 接続開始（Synchronize） | 通信の最初に送る接続要求の合図 |
| FIN | 000001 | 通信終了（Finish） | 通信を終了したいことを伝える |
※複数のフラグは同時に立てることが可能で、例えば 010001（ACK + FIN）のような組み合わせで使われます。
🔍 Wiresharkで確認するTCPヘッダの各フィールド
実際のネットワークトラフィックを解析する際、Wiresharkの画面でTCPヘッダは以下のように表示されます。特に重要なポイントをピックアップして解説します。
| Wireshark上の表示 | 対応するTCPヘッダ項目 | 例（表示値） | 解説 |
|---|---|---|---|
| Source Port | 送信元ポート番号 | 54321 | クライアント側が使ったポート番号（エフェメラルポート） |
| Destination Port | 宛先ポート番号 | 80 | 通信先サービスのポート（この例ではHTTP） |
| Sequence Number | シーケンス番号 | 0 | 送信側が付けるデータの順序番号（SYN時は初期番号） |
| Acknowledgment Number | 確認応答番号 | 1 | 受信側が「次に期待するシーケンス番号」を通知 |
| Header Length | データオフセット | 32 bytes | TCPヘッダの長さ（オプション含む） |
| Flags | コントロールフラグ | 0x02 (SYN) | SYNなら接続開始、ACKやFINなどもここに表示 |
| Window Size Value | ウィンドウサイズ | 64240 | 受信可能なバッファサイズ（フロー制御に利用） |
| Checksum | チェックサム | 0xffff | ヘッダ＋データのエラーチェック値（Wiresharkで検証） |
| Urgent Pointer | 緊急ポインタ | 0 | URGフラグが立っているときにのみ使用 |
| Options | オプション | MSS, SACK, Timestampなど | 接続時の追加情報（性能最適化や再送制御） |
[ パケットキャブチャ例 ]
Transmission Control Protocol, Src Port: 54321, Dst Port: 80
Source Port: 54321
Destination Port: 80
Sequence Number: 0 (relative sequence number)
Acknowledgment Number: 0 (relative ack number)
Header Length: 32 bytes
Flags: 0x002 (SYN)
.000 …. = Congestion Window Reduced (CWR): Not set
..0. …. = ECN-Echo: Not set
…0 …. = Urgent: Not set
…. 0… = Acknowledgment: Not set
…. .0.. = Push: Not set
…. ..1. = Synchronize: Set
…. …0 = Finish: Not set
Window: 64240
Checksum: 0xffff
Urgent Pointer: 0
Options: (34 bytes)
Maximum segment size: 1460 bytes
No-Operation (NOP)
No-Operation (NOP)
Timestamps: TSval 1, TSecr 0
Wiresharkでは、TCPヘッダは「Transmission Control Protocol」セクションでまとめて確認できます。特に、Flagsの部分を見れば「通信のどの状態か」が一目で分かるようになっています。
UDPの特徴と適用例
UDP（User Datagram Protocol）は、TCPと比べて軽量な非接続型の通信プロトコルです。
再送や順序保証といった制御機能を持たないため、リアルタイム性を重視する通信に適しています。 主な特徴は以下の通りです。
- コネクションレス型通信（接続の確立不要）
- ヘッダが小さく通信処理が高速
- パケットロスや順序の乱れが起きる可能性あり
代表的な適用例：
- 音声通話（VoIP）
- 動画ストリーミング
- オンラインゲーム
- DNSリクエスト
- ネットワーク監視プロトコル（SNMP）
これらの用途では、多少のパケットロスや遅延よりも、通信の即時性が重視されるため、UDPが選ばれます。
TCPとUDPの使い分けの判断基準
通信プロトコルの選定は、単に「速い・遅い」「重い・軽い」といった判断ではなく、通信の目的・要件を踏まえたうえでの合理的な選定が求められます。
以下のような基準に従うと、より実務に適した判断が可能です。
通信要件ごとのプロトコル選定指針
| 通信要件 | 最適なプロトコル | 理由 |
|---|---|---|
| データの完全性が最重要 | TCP | 再送や順序保証により信頼性が高い |
| リアルタイム性が求められる | UDP | 接続処理がなく、遅延が少ない |
| パケットロスが許容される | UDP | 音声や映像では多少の損失は無視できる |
| 小さなデータの単発通信 | UDP | DNSなどは接続のオーバーヘッドが不要 |
| セッション管理や双方向通信が必要 | TCP | 安定した接続状態を維持できる |
実際の設計現場では、プロトコル選定によってシステム全体のパフォーマンスや耐障害性に大きな影響が出るため、初期段階での要件整理が重要になります。
TCPとUDPを正しく理解し、設計意図に応じた使い分けができることは、ネットワーク設計者にとって基本かつ不可欠なスキルです。
通信トラブルとポート番号の関係
ネットワークの通信トラブルの多くは、ポート番号の設定や制御に起因しています。
特に、サービスが稼働しているにもかかわらず外部からアクセスできない場合や、アプリケーションが接続エラーを起こす場合には、ポート番号の状態が原因であるケースが少なくありません。
ここでは、通信トラブルの典型的な原因となるポートの開放状況やファイアウォールの制御、そしてセキュリティリスクとしてのポートの扱いについて解説します。
通信エラーとポート開放の関係性
ネットワーク上でサービスを公開するには、対象のポート番号が開放されている必要があります。
たとえばWebサーバを公開する場合、HTTPならポート80、HTTPSならポート443を開けておかないと外部からの接続が確立できません。
通信トラブルでよくある事象として、「サービス自体は起動しているのに外部から接続できない」ケースがあります。この原因の多くは以下のいずれかです。
- アプリケーションが想定するポートが未開放である
- OSやルーター側の設定でポートがブロックされている
- アプリケーション側のリスニングポートが誤っている
実際の確認には、以下のようなコマンドを使用します。
netstat -an | grep LISTEN
ss -lnt
これにより、どのポートでどのプロセスが待機しているか（リスン状態）が確認できます。
もしポートがリスン状態でない場合、アプリケーションが異常終了しているか、設定ファイルに誤りがある可能性があります。
ファイアウォールによるポート制御の考え方
多くの通信トラブルは、ファイアウォールによって通信が遮断されていることが原因です。企業やクラウド環境では、通信を許可するポートのみ明示的に開放する「デフォルト拒否（deny all）」の方針が一般的です。 ファイアウォールの制御対象は大きく以下の2種類に分かれます。
- インバウンド（外部からの通信）
- アウトバウンド（内部からの通信）
たとえば、SSH接続で問題がある場合、ポート22番がインバウンド方向でブロックされていないかを確認する必要があります。 Linux環境では、以下のようなコマンドで確認・制御できます。
sudo ufw status
sudo iptables -L
クラウド環境（例：AWSやGCP）では、セキュリティグループやファイアウォールルールによりポート制御を行います。
管理画面やCLIでのルール確認・編集が可能です。
ポートスキャンや攻撃対象としてのリスク
ポートは、セキュリティ上の脆弱性を突く対象にもなり得ます。悪意ある攻撃者はまず、対象ホストの開いているポートをスキャンし、その結果からどのサービスが稼働しているかを推定します。 ポートスキャンの代表的な手法には以下があります。
- TCP SYNスキャン
- UDPスキャン
- フルコネクトスキャン
スキャンにはnmapなどのツールが多く利用されます。
nmap -sS 192.168.1.1
不用意に多数のポートを開放していると、古いバージョンのサービスや脆弱なミドルウェアが見つかり、攻撃対象とされる可能性が高まります。
そのため、以下のような対策が必要です。
| リスク要因 | 対策方法 |
|---|---|
| 不要なポートの開放 | 使用しないポートはすべて閉じる |
| サービスのバージョン漏洩 | バナー情報の抑制や更新の徹底 |
| ポートスキャンへの無防備 | IPS/IDSの導入やポートノッキングの採用 |
このように、ポート番号の管理は単なる通信制御に留まらず、システム全体のセキュリティにも大きく関わる要素となります。
通信トラブルの原因究明だけでなく、ポートを通じたリスク管理も含めた包括的な視点が求められます。
ポート番号とセキュリティの基本
ネットワーク通信においてポート番号は、アプリケーションごとに通信の入り口となる重要な要素です。
しかしその一方で、外部からの攻撃に対する入り口にもなり得るため、セキュリティ対策の観点からもポート管理は極めて重要です。
特に、不要なポートを開放したままにしていたり、フィルタリング設定が不適切だったりすると、脆弱性を突かれて情報漏洩や侵入のリスクが高まります。
本記事では、ポート番号とセキュリティの関係を理解し、安全なシステム運用を実現するための基本的なポイントを解説します。
ポート制限によるセキュリティ強化策
多くの攻撃者は、まず対象となるシステムがどのポートを開いているかを調べる「ポートスキャン」を実行します。
これにより、対象がどのサービスを稼働させているか、またバージョン情報や脆弱なミドルウェアがあるかを把握しようとします。
これを防ぐためには、ポート制限による通信制御が不可欠です。
まず基本となるのが、「必要なポートだけを開放し、それ以外はすべて閉じる」というホワイトリスト型のアプローチです。
Linuxでは、ufwやiptablesを使って明示的にポートを制御することができます。 以下は、特定ポート（例: 22番）だけを開放する例です。
sudo ufw allow 22/tcp
sudo ufw default deny incoming
また、クラウド環境ではセキュリティグループやネットワークACLを用いて、インバウンド・アウトバウンド両方向の通信を制御します。
特定IPアドレスやポート範囲を指定してルールを適用することができ、よりきめ細かい対策が可能です。
不要ポートの閉鎖とフィルタリング設定
実際のシステム運用においては、使っていないサービスのポートが開いていないか定期的にチェックすることが推奨されます。
たとえば、開発時にテスト用に開放したまま放置されたポートや、古い管理インターフェースなどがそのままになっていると、重大なリスクとなります。
まずは現在開いているポートの一覧を把握するため、以下のようなコマンドを使用します。
sudo netstat -tuln
ss -tunlp
次に、不必要なサービスは停止し、以下のようにファイアウォールで明示的にブロックします。
sudo ufw deny 21
sudo ufw delete allow 80
また、iptablesを利用する場合には、チェーン単位でDROPルールを適用する方法も有効です。
iptables -A INPUT -p tcp --dport 23 -j DROP
このような制御を行うことで、予期せぬ外部接続の発生を未然に防ぎ、不要な攻撃対象を削減することができます。
実務におけるポート管理のポイント
現場での運用では、単にポートを開閉するだけでは不十分です。ログ監視やアクセス制御、定期的な棚卸しを通じて継続的にセキュリティレベルを維持する必要があります。
以下は実務において押さえておきたい管理ポイントです。
| 管理項目 | 説明 |
|---|---|
| ポート使用状況の可視化 | 月次・四半期ごとに使用ポートの棚卸しを実施 |
| ログモニタリング | 不正アクセスや異常な通信の兆候をログから検知 |
| ルールの見直し | 変更管理と連動し、不要になったポートは即時閉鎖 |
| 多層防御の採用 | ファイアウォールに加え、WAFやIDS/IPSで補完 |
また、ポート制御の誤設定により、本来アクセス可能なはずのサービスが遮断されるトラブルも散見されます。
設定後の疎通確認や、変更時の事前検証も運用手順として定着させることが重要です。
ネットワーク設計時においても、あらかじめ必要なポートとその用途を明記した設計書を用意し、導入後もそれをもとに定期監査を実施することで、長期的な安全性を確保できます。
まとめ
ポート番号は、ネットワーク通信の中でアプリケーションを識別するための重要な仕組みです。
しかしその一方で、外部からの攻撃対象になりやすい脆弱なポイントでもあります。特に、不要なポートを開放したままにしておくことは、セキュリティ上の大きなリスクにつながります。
セキュリティを高めるためには、必要最小限のポートのみを開放し、不要なものは明示的に閉じることが基本となります。
加えて、ファイアウォールやルーター設定により、外部からのアクセス制御を行うことが重要です。
実務においては、ポート番号の使用状況を常に把握し、ドキュメント化しながら定期的に見直す運用体制を整えることで、安全で安定したネットワークを維持できます。
ポート番号とセキュリティの関係を正しく理解し、戦略的な管理を行うことが、これからのインフラ管理者に求められる基本姿勢です。
▶︎ 次は「DNSと名前解決の仕組み: IPアドレスとの関連性を理解する」の動作を理解してみましょう。
