はじめに
「アンドロイドは電気羊の夢を見るか？」のような韻を踏みましたが、パケット解析も最早、Claude Codeのような生成AIツールが活用できるのではないかと思い、パケット解析専用のSKILLSを作成してみました。
Claude Code SKILLSについては、いろいろな方が既に記事として取り上げております通り、繰り返し行う作業手順をパッケージ化することで、毎回自分専用の複雑なプロンプトを入力することなく、目的のタスクを遂行する技術です。
今回は、その実証実験をするために（少し遅れ気味ですが）、free5GCというオープンソースソフトウェアを利用し、現在の携帯電話5Gコアネットワークの通信シーケンスを分析してみたいと思います。（純粋に5G Core Networkの学習目的です。）
free5GCのセットアップ
先人達が既にQiitaの記事として取り上げておりまして、以下の記事を参考にすれば、セットアップ自体はそれほど苦労しません。
現在(2026年8月)のBest Practiceとして、以下にまとめます。以下のページはfree5GCのユーザーガイドです。
以下の様に開発目的以外では、docker-compose版が推奨ということ、そちらに従います。
- Ubuntu 26.04のインストール (2018年製のMicrosoft Surfaceだったので、久しぶりにLinux OSをHardware直でインストールしました。）
- gtp5gをgit cloneしてインストール
- dockerのインストール
- docker-composeのインストール
- free5gc-composeをgit cloneしてインストール
あとは、なすがままに待ちます。少し待つと各ネットワークノード達が私の旧式Surface notebookで立ち上がります。（PCの中にコアネットワークが再現できるなんて、素直にすごい。。。）
# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5631ebd45e28 free5gc/n3iwue:latest "bash -c 'ip route d…" 24 hours ago Up 24 hours n3iwue
8149ecf1db1f free5gc/n3iwf:v4.2.3 "./n3iwf -c ./config…" 24 hours ago Up 24 hours n3iwf
1ef5b02ac0ea free5gc/tngf:v4.2.3 "./tngf -c ./config/…" 24 hours ago Exited (0) 24 hours ago tngf
4cf0e9231905 free5gc/ueransim:latest "./nr-gnb -c ./confi…" 24 hours ago Up 24 hours ueransim
b8295b167666 free5gc/chf:v4.2.3 "./chf -c ./config/c…" 24 hours ago Up 24 hours 2122/tcp, 8000/tcp chf
bba8e2f367c3 free5gc/smf:v4.2.3 "./smf -c ./config/s…" 24 hours ago Up 24 hours 8000/tcp smf
3c5b652953a0 free5gc/nssf:v4.2.3 "./nssf -c ./config/…" 24 hours ago Up 24 hours 8000/tcp nssf
01a5818be0e0 free5gc/udm:v4.2.3 "./udm -c ./config/u…" 24 hours ago Up 24 hours 8000/tcp udm
b68e71f31f61 free5gc/pcf:v4.2.3 "./pcf -c ./config/p…" 24 hours ago Up 24 hours 8000/tcp pcf
2b022bb066dc free5gc/amf:v4.2.3 "./amf -c ./config/a…" 24 hours ago Up 24 hours 8000/tcp amf
20f2fd216b99 free5gc/udr:v4.2.3 "./udr -c ./config/u…" 24 hours ago Up 24 hours 8000/tcp udr
3439c75829e3 free5gc/nef:v4.2.3 "./nef -c ./config/n…" 24 hours ago Up 24 hours 8000/tcp nef
cc9b82639d4c free5gc/ausf:v4.2.3 "./ausf -c ./config/…" 24 hours ago Up 24 hours 8000/tcp ausf
8fb62b4179d7 free5gc/webui:v4.2.3 "./webui -c ./config…" 24 hours ago Up 24 hours 0.0.0.0:2121-2122->2121-2122/tcp, [::]:2121-2122->2121-2122/tcp, 0.0.0.0:5000->5000/tcp, [::]:5000->5000/tcp webui
30904aefe779 free5gc/nrf:v4.2.3 "./nrf -c ./config/n…" 24 hours ago Up 24 hours 8000/tcp nrf
5bdf9004d743 free5gc/upf:v4.2.3 "bash -c './upf-ipta…" 24 hours ago Up 24 hours upf
576e6d8b287c mongo:4.4 "docker-entrypoint.s…" 24 hours ago Up 24 hours 27017/tcp mongodb
5Gコアネットワークのノード達が立ち上がってそうです。(以下のリファレンスアーキテクチャに含まれていないノードも存在していますが。）
このシステムにはWebコンソールも同梱されており、http://"free5GCインストールのホスト":5000と入力するだけでWeb consoleが表示されます。(おそらくwebuiコンテナがこの処理を担当しているのでしょう。）
Webコンソールはadmin/free5gcでログインすることが可能です。すべての機能を把握はできていませんが、加入者データの登録、位置登録の確認などはこちらのコンソールから確認ができます。
位置登録シーケンスの実行
いよいよ位置登録シーケンスの実行ですが、最新のdocker-compose環境では、UERANSIMが同梱されています。
# docker exec -it ueransim bash
と入力すると、UERANSIMコンテナ内にログインできます。さらに以下のコマンドを入力することで、gNodeB(5G基地局、リファレンスアーキテクチャではRANと表現されている）のプロセスが立ち上がっていることが確認できます。
# ps aux | grep nr-gnb | grep -v grep
root 1 0.2 0.0 691020 8488 ? Ssl Aug12 3:11 ./nr-gnb -c ./config/gnbcfg.yaml
次に、以下のUE(5G携帯端末） Configurationファイルを確認します。
# cat ./config/uecfg.yaml
# IMSI number of the UE. IMSI = [MCC|MNC|MSISDN] (In total 15 digits)
supi: "imsi-208930000000001"
# Mobile Country Code value of HPLMN
mcc: "208"
# Mobile Network Code value of HPLMN (2 or 3 digits)
mnc: "93"
# Permanent subscription key
key: "8baf473f2f8fd09487cccbd7097c6862"
# Operator code (OP or OPC) of the UE
op: "8e27b6af0e692e750f32667a3b14605d"
# This value specifies the OP type and it can be either 'OP' or 'OPC'
opType: "OPC"
# Authentication Management Field (AMF) value
amf: "8000"
# IMEI number of the device. It is used if no SUPI is provided
imei: "356938035643809"
# IMEISV number of the device. It is used if no SUPI and IMEI is provided
imeiSv: "4370816125816151"
# List of gNB IP addresses for Radio Link Simulation
gnbSearchList:
- 127.0.0.1
- gnb.free5gc.org
:
何やらこのファイルにデフォルトの加入者情報が設定されておりますので、再び、Webコンソールを開き、Subscribersを選択し、CREATEボタンを押します。そうすると、以下の様にUERANSIMに記載されている加入者情報デフォルトとして存在しています。それをそのままCREATEします。
これで準備完了です。位置登録を実行します。
# ./nr-ue -c ./config/uecfg.yaml
UERANSIM v3.3.0
[2026-08-13 07:44:57.891] [nas] [info] UE switches to state [MM-DEREGISTERED/PLMN-SEARCH]
[2026-08-13 07:44:57.892] [rrc] [debug] New signal detected for cell[1], total [1] cells in coverage
[2026-08-13 07:44:57.892] [nas] [info] Selected plmn[208/93]
[2026-08-13 07:44:57.892] [rrc] [info] Selected cell plmn[208/93] tac[1] category[SUITABLE]
[2026-08-13 07:44:57.892] [nas] [info] UE switches to state [MM-DEREGISTERED/PS]
[2026-08-13 07:44:57.892] [nas] [info] UE switches to state [MM-DEREGISTERED/NORMAL-SERVICE]
[2026-08-13 07:44:57.892] [nas] [debug] Initial registration required due to [MM-DEREG-NORMAL-SERVICE]
[2026-08-13 07:44:57.892] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_sig]
[2026-08-13 07:44:57.892] [nas] [debug] Sending Initial Registration
[2026-08-13 07:44:57.892] [nas] [info] UE switches to state [MM-REGISTER-INITIATED]
[2026-08-13 07:44:57.892] [rrc] [debug] Sending RRC Setup Request
[2026-08-13 07:44:57.893] [rrc] [info] RRC connection established
[2026-08-13 07:44:57.893] [rrc] [info] UE switches to state [RRC-CONNECTED]
[2026-08-13 07:44:57.893] [nas] [info] UE switches to state [CM-CONNECTED]
[2026-08-13 07:44:57.952] [nas] [debug] Authentication Request received
[2026-08-13 07:44:57.952] [nas] [debug] Received SQN [000000000028]
[2026-08-13 07:44:57.952] [nas] [debug] SQN-MS [000000000000]
[2026-08-13 07:44:57.989] [nas] [debug] Security Mode Command received
[2026-08-13 07:44:57.989] [nas] [debug] Selected integrity[2] ciphering[0]
[2026-08-13 07:44:58.025] [nas] [debug] Registration accept received
[2026-08-13 07:44:58.026] [nas] [info] UE switches to state [MM-REGISTERED/NORMAL-SERVICE]
[2026-08-13 07:44:58.026] [nas] [debug] Sending Registration Complete
[2026-08-13 07:44:58.026] [nas] [info] Initial Registration is successful
[2026-08-13 07:44:58.026] [nas] [debug] Sending PDU Session Establishment Request
[2026-08-13 07:44:58.027] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_sig]
[2026-08-13 07:44:58.027] [nas] [debug] Sending PDU Session Establishment Request
[2026-08-13 07:44:58.027] [nas] [debug] UAC access attempt is allowed for identity[0], category[MO_sig]
[2026-08-13 07:44:58.352] [nas] [debug] Configuration Update Command received
[2026-08-13 07:44:58.493] [nas] [debug] PDU Session Establishment Accept received
[2026-08-13 07:44:58.493] [nas] [info] PDU Session establishment is successful PSI[1]
[2026-08-13 07:44:58.503] [app] [info] Connection setup for PDU session[1] is successful, TUN interface[uesimtun2, 10.60.0.6] is up.
[2026-08-13 07:44:58.584] [nas] [debug] PDU Session Establishment Accept received
[2026-08-13 07:44:58.584] [nas] [info] PDU Session establishment is successful PSI[2]
[2026-08-13 07:44:58.594] [app] [info] Connection setup for PDU session[2] is successful, TUN interface[uesimtun3, 10.61.0.5] is up.
更に、Webコンソールを確認します。
位置登録されてます！
パケット解析の課題
AI以前は地道にWiresharkでパケットの中身を分析して、正常なシーケンスとなっているかどうかを確認しておりました。AI時代の今何ができるか？ そのままパケットキャプチャファイルとプロンプトをClaude先生に渡すのが楽で、それで十分なのではないか！と普通に思います。
しかし、問題はパケットキャプチャファイルのサイズが概して巨大であることです。そのまま使用しては、大量のトークンを使用し、コスト面および環境負荷（エコでない！）という意味では非常によろしくないと思われます。
パケット解析用のSKILLSの作成
まずは、Anthoropic officialのskill-creatorを使用してテンプレートを作成します。
私もまだ、完全に使いこなせていないかもしれませんが、以下のような形でテンプレートを作成しました。
❯ /skill-creator "pcapファイルの中身を解析して、各ネットワークノードに分解し、全体のネットワークシーケンスを作成したい。"
ここからいくつか微調整していきます。
例えば、前出した通りの課題があります。
- 大量のトークンを使用する
- レポート表示形式(Markdown or Web?)
- どのような内容を要約する？
- Marmaid形式でファイルを出力する？
などです。
微調整した結果、以下のファイル構造となりました。（自分自身で、マニュアルで追記した記述もいくつかあります。）
以下が、SKILL.mdの内容です。(一部、このSKILLSの中身に、Markdown固有の記載があるため、意図的に特殊文字を削除しています。したがって、このままSKILLSとしては使用できません。すいません。）
ですが、何をしようとしているかは理解していただけると思います。
---
name: pcap-sequence
description: pcap/pcapng キャプチャを解析してネットワークノードに分解し、系全体の流れを Mermaid シーケンス図＋ノード一覧の Markdown レポートにまとめる。パケットキャプチャ、pcap、pcapng、Wireshark、tshark、tcpdump のファイルを渡されたとき、あるいは「通信シーケンスを図にしたい」「どのノードがどこと喋っているか整理したい」「装置間のやり取りを可視化したい」「この通信の流れを説明して」「キャプチャを解析して」と言われたときは必ずこのスキルを使うこと。ユーザーが「シーケンス図」という言葉を出さなくても、キャプチャファイルの中身の理解・通信フローの整理・ノード間関係の把握が目的なら該当する。障害解析やプロトコル調査でキャプチャを読む場面も対象。
---
# pcap → ネットワークシーケンス
## このスキルが解く問題
実運用のキャプチャは数万パケット・数百ノードになる。全部を時系列に並べた図は
「正確だが誰も読まない成果物」になり、依頼者が本当に知りたい**系の構造と流れ**が
埋もれる。
使用トークンについても考慮にいれる。すなわち莫大なサイズのパケットキャプチャを全部
読み込んでは、使用トークンもその分上昇する。可能な限り読み込むパケットキャプチャの数を少なくする。
このスキルの中心は圧縮の判断だ。**周期的な通信は1周期だけ描いて「×N回」と畳み、
系の状態を変えるイベント（接続確立、呼設定、切断、異常）は残す。** その仕分けを
根拠を持ってやるために、まず機械的な集計を取る。
原則として、`packets.tsv` を人間の目で頭から追ってはいけない。数万行を読んでも
構造は見えないし、途中で力尽きる。必ず集計から入り、集計で当たりを付けてから
個別パケットに降りる。
## 手順
### 1. digest を作る
python3 <skill>/scripts/pcap_digest.py CAPTURE.pcapng -o digest/
数万パケットでも数秒で終わる。`tshark` があれば自動で使い（RTP/SIP/SNMP など
数百のプロトコルを識別できる）、無ければ内蔵パーサに落ちる。どちらを使ったかは
`summary.json` の `engine` に出る。
出力されるファイルと、読む順序:
| ファイル | 中身 | 読み方 |
|---|---|---|
| **`brief.md`** | 全体像1枚。判明ホスト名、上位ノード、主要会話と1周期の中身、one-shot の集計、注意信号 | **まずこれだけ読む** |
| `summary.json` | 数値のメタ情報 | brief に含まれるので通常不要 |
| `nodes.csv` | 全ノード | 26位以下が要るときだけ |
| `conversations.csv` | 全会話 | 特定の会話を掘るときだけ |
| `packets.tsv` | 正規化した全パケット | **Read で開かない**（下記） |
**トークンを浪費しない読み方**。5万パケットのキャプチャだと
`conversations.csv` は約8万トークン、`packets.tsv` は約230万トークン相当ある。
一方 `brief.md` は約4千トークンで、判断に必要なことはほぼ揃っている。
全体像の把握に CSV を丸ごと読むのは、同じ情報を20倍の値段で買うのに等しい。
個別パケットが要るときは `Read` ではなく `grep` / `awk` で絞る:
grep -P '\t172\.16\.1\.9\t' digest/packets.tsv | head -40 # 特定ノード
awk -F'\t' '$5=="SIP"' digest/packets.tsv | head -40 # 特定プロトコル
awk -F'\t' '$2>53.5 && $2<55' digest/packets.tsv # 時間窓
ペイロードの中身まで見たいときは digest ではなく tshark を直接使う
（`tshark -r CAPTURE -Y 'tcp.port==2000' -x | head -100`）。
キャプチャが大きすぎる場合は `--bpf 'ip.addr==10.0.0.1'` で絞るか
`--max-packets N` で頭を切る。`--no-packets` で `packets.tsv` の生成自体を
省ける。ただし絞る前に一度は全体で digest を取ること。**何を捨てたか
分からないまま絞ると、系の一部だけを全体像として報告してしまう。**
### 2. ノードに分解し、役割を特定する
**推定の前に、身元が書いてある場所を探す。** キャプチャには装置名がそのまま
残っていることが多く、見つかれば役割は推定でなく事実として書ける。ポート番号
からの推測より圧倒的に確度が高いので、必ず先に確認する:
| 手掛かり | 取り方 |
|---|---|
| pcapng の名前解決ブロック | `brief.md` の「判明しているホスト名」（digest が自動抽出） |
| DNS 応答 | `awk -F'\t' '$5=="DNS"' digest/packets.tsv \| grep response` |
| DHCP のホスト名オプション | `tshark -r CAPTURE -Y 'dhcp' -T fields -e dhcp.option.hostname` |
| LLDP / CDP の隣接情報 | `tshark -r CAPTURE -Y 'lldp \|\| cdp'` |
| SIP の From/To/User-Agent | `tshark -r CAPTURE -Y 'sip' -T fields -e sip.from.user -e sip.User-Agent` |
| SNMP の sysName | `tshark -r CAPTURE -Y 'snmp' -x \| grep -i sysname` |
| TLS の SNI / 証明書 | `tshark -r CAPTURE -Y 'tls.handshake.extensions_server_name'` |
| 平文ペイロード中の装置名 | `tshark -r CAPTURE -Y 'tcp.len>0' -x \| grep -aoE '[A-Za-z][A-Za-z0-9_.-]{5,}'` |
名前が取れなかったノードだけ、以下の材料から役割を推定する:
| 手掛かり | 示唆 |
|---|---|
| `syn_listen_ports` にポートがある | そのポートで待ち受けるサーバ側（SYN の宛先） |
| `heavy_recv_ports` に同じポートが大量 | サーバ側（SYN が捕れていない途中キャプチャでも判る） |
| `top_send_ports` が毎回バラバラの高番ポート | クライアント側（エフェメラルポート） |
| `peer_count` が 1 で送受信がほぼ同数 | 1対1のペア構成（冗長系・装置間リンクなど） |
| `peer_count` が多く相手が広範囲 | 集約点。管理サーバ、ルータ、監視系 |
| `is_multicast` の宛先にのみ送信 | 配信源。受信側はキャプチャ点では見えないことが多い |
| `protocols` に SIP/RTP/RTCP | VoIP。SIP がシグナリング、RTP がメディア |
| `protocols` に VRRP/HSRP | ルータ冗長。マスタ/バックアップの関係を見る |
| `protocols` に SNMP かつポート161で受信 | SNMP エージェント（被管理装置） |
| `protocols` に ARP が突出 | ゲートウェイか、疎通を探している装置 |
| `protocols` に STP/LLC | L2 スイッチ |
**推定は推定と分かるように書く。** 「172.16.5.4 は SNMP エージェント」ではなく
「SNMP エージェントと推定（根拠: ポート161で1051パケット受信、get-request に
report で応答）」と書く。キャプチャから確実に言えるのは通信の事実だけで、
装置の正体は依頼者の方が知っている。断定して外すと、依頼者は他の記述まで
疑うことになる。
IP しか分からないノードには `N1`, `N2` のような短い識別子を振る。Mermaid の
participant 名に使え、図が読みやすくなる。
### 3. 会話を「描く／畳む／落とす」に仕分ける
ここが成果物の質を決める。`conversations.csv` の `class` 列が出発点になる:
| class | 意味 | 図での扱い |
|---|---|---|
| `periodic` | 一定間隔の連続送信（RTP など） | 1本の矢印 + `Note` にレート。畳む |
| `periodic-burst` | 一定周期で往復のまとまりが繰り返す（ポーリングなど） | `cycle_detail` の1周期を `loop` で描く |
| `quasi-periodic` | ほぼ周期的だが揺れる | 代表1周期 + ばらつきを注記 |
| `bursty` | 不規則にまとまって流れる | 代表的な往復のみ。全部は描かない |
| `one-shot` | 数パケットで終わる | **原則そのまま描く。系のイベントはここに出る** |
| `multicast-stream` | マルチキャストへの連続送信 | 1本の矢印 + レート注記 |
| `multicast-sparse` | マルチキャストへの散発送信 | 意味があれば描く（IGMP、探索など） |
`periodic-burst` の会話には `cycle_detail` 列に**1周期の中身が1ステップずつ**
入っている（向き・プロトコル・ペイロード長・tshark の Info）。これをそのまま
`loop` ブロックの中身にすれば、正確なラベルが付いた図になる。`cycle_interval_s`
が周期、`cycle_repeats` が回数、`cycle_interval_cv` がばらつき（0に近いほど
機械的な定期送信）。
**落としてよいもの**: 単独の ACK、STP/LLC の定常フラッディング、ミラーポート
由来の重複パケット。**落としてはいけないもの**: SYN/FIN/RST、SIP の
INVITE/BYE、DHCP、再送、ICMP エラー、初出の ARP。これらは系の状態が変わった
瞬間で、障害解析ではここだけが手掛かりになる。
迷ったときの基準は「**この矢印を消したら、依頼者の系の理解が変わるか**」。
変わらないなら畳む。
### 4. Mermaid シーケンス図を組む
読みやすさの制約から先に決める:
- **participant は1図あたり12個まで。** 超えると横に潰れて読めない。
- 超える規模なら **俯瞰図1枚 + クラスタ別の詳細図** の二段構えにする。俯瞰図では
サブネットや装置グループを1つの participant にまとめ、詳細図で中を開く。
- 時刻は絶対時刻ではなく**キャプチャ先頭からの相対秒**（`+1.234s`）で書く。
絶対時刻は桁が多く、間隔の把握を妨げる。
Mermaid の書き方で外しやすい点:
- participant は短い ID と別名に分ける: `participant N1 as 172.16.1.9<br/>(:2000 サーバ)`。
**別名を引用符で囲まない** — シーケンス図では引用符が名前の一部として表示されてしまう。
改行は `<br/>` を使う。
- `->>` 実線はリクエスト／データ、`-->>` 破線は応答／ACK に使い分けると向きが読める。
- `loop`, `alt`, `opt`, `par`, `rect` が使える。`rect rgb(240,240,240)` でフェーズを囲むと区切りが見える。
- `Note over A,B: ...` に周期・回数・観測事実を書く。図の情報量はここで稼ぐ。
書き方の例（形を示すためのもの。実際のラベルは digest の値から取る）:
sequenceDiagram
autonumber
participant N1 as 172.16.1.9<br/>(:2000 待ち受け)
participant N2 as 172.16.1.10<br/>(:12081)
participant MGR as 10.3.0.30<br/>(SNMP マネージャと推定)
rect rgb(238,244,250)
Note over N1,N2: フェーズ1: 定常ポーリング (+0.0s 〜 +94.3s)
loop 300.7ms 周期 × 336回 (ばらつき 0.1%)
N2->>N1: PSH 168B (独自プロトコル)
N1-->>N2: ACK
N2->>N1: PSH 52B
N1-->>N2: ACK
end
end
Note over MGR: SNMPv3。PDU は暗号化されており内容は不明
MGR->>N1: get-request
N1-->>MGR: report (1.3.6.1.6.3.15.1.1.4.0)
### 5. 使用トークン数を計算する
全パケットを読み込んで解析した場合と比較して、使用トークン数をどれだけ削減できたかを計算する。
### 6. レポートにまとめる
成果物は**シーケンス図と気付きの2つ**。1つの Markdown にこの順で書く。
成果物は Markdown ファイルのみとし、Artifact 公開はユーザーが明示的に求めた場合に限る。
# <キャプチャ名> ネットワークシーケンス解析
## 概要
キャプチャ範囲（期間・パケット数・ノード数）と、系として何が起きているかを数行。
## ノード一覧
| ID | IP | ホスト名 | 役割 | 主な相手 | パケット数 |
表は1つ。分類の小見出しを作って分割しない。
## シーケンス図
Mermaid。ノードが多ければ俯瞰図＋詳細図に分け、各図に何を示した図かを一言添える。
## 気付いたこと
周期・回数・ペイロードサイズなど図から読み取れることに加え、再送、RST、
応答遅延、片方向のみの通信、暗号化で読めない範囲など。無ければ
「特筆すべき異常なし」と明記する。
**この4つ以外の節を足さない。** 分類の階層、解析手順の説明、中間データの
付録などは、依頼者が求めているものではない。書きたくなったら「これは図か
気付きのどちらかに入るか？」を確かめ、入らないなら落とす。
一方で、**この枠の中で何を書くかは判断に委ねられている。** 図を何枚に分けるか、
どの会話を載せるか、どの気付きが報告に値するかは、キャプチャごとに違う。
上の枠は分量の歯止めであって、考えなくてよいという意味ではない。
推定を断定として書かないことだけは外さない。「独自プロトコルのため中身は
不明」「SYN が無いので待ち受け側は流量からの推定」といった但し書きは、
図をどこまで信じてよいかの情報なので、気付きの中に一言入れる。
レポートは依頼者の言語で書く（日本語で依頼されたら日本語で）。
## 使用トークン数
全パケットを読み込んで解析した場合と比較して、使用トークン数をどれだけ削減できたかを入れる。
## つまずきやすい点
- **途中からのキャプチャ**では SYN が無いので、サーバ／クライアントの判定は
流量ベースの推定になる。`syn_listen_ports` が空なら、その旨を限界として書く。
- **ミラーポート／SPAN 経由**のキャプチャは同一パケットが2回記録されることがある。
同じ時刻・同じ長さの連続に気付いたら、回数を2倍で報告しないよう注意する。
- **暗号化された通信**（TLS、SNMPv3 privKey、独自プロトコル）は中身が読めない。
読めないものを推測で埋めず、「ペイロード長のパターンから N 種類の
メッセージがあると見られる」のように観測できる範囲で書く。
- **独自ポートのアプリケーション**（tshark が `TCP` としか言わないもの）は、
ペイロード長の並びが強い手掛かりになる。`cycle_detail` の長さの並びが
そのままメッセージ種別の並びであることが多い。
- **図が大きくなりすぎたら**、正確さより可読性を取って分割する。分割したことと
分割の基準はレポートに書く。
一番のポイントは、最初にダイジェスト(brief.md)を作り、その中身をClaude先生に理解させたうえで、必要なパケット解析を順番に実施しているだけです。つまり、あほみたいに全部パケットキャプチャをLLMに投げないということです。
パケット解析の実行
あとは、先ほど取得したfree5GCの位置登録シーケンスを以下の様に解析させます。
'c:/Users/k_kis/5G_registration_ueransim.pcap'を解析してください。
以下はこのSKILLSが出力したMarkdownファイルの抜粋です。
上記の様に、シーケンスの要約と自然言語で何が起こったかを解説してくれます。
もう少し、しっかり見ないといけないとは思いますが、5Gの位置登録シーケンスとして正しそうです。（ここは追って学習が必要です。）
出力されたレポートについて、日本語として少し変ですが、とりあえずおおまかに、5Gの位置登録シーケンスを理解することができました。
パケット解析に使用したトークン数
このSKILL.mdにはトークン数の計算処理も入れました。以下がその解析結果です。今回の実行に関していえば、2.3%までトークン数を圧縮できていることがわかります。
おわりに
まだまだ検証は必要ですが、いろいろなパケットキャプチャを使用して、その精度と圧縮率を継続して精査していき、定型処理をローカル側に保存するスクリプトで着実に実行し、人間側で極力コントロールができる環境であれば、パケット解析も生成AIにおまかせしてもいいのではないかと思えてきました。そして、自分専用にカスタマイズしたSKILLSへとチューンアップしていけば、気の狂うようなパケット解析が、必要なくなる時代が来るのかもしれません。ここまで読んでいただきありがとうございました。