GitHub Copilot にパケットキャプチャ解析をさせる！

Last updated at 2026-05-18Posted at 2026-04-17

こんにちは、たまにしかパケットキャプチャしないので、Wireshark （パケットキャプチャ解析ツール）の表示フィルターや「まずどこを見るんだっけ？」を毎回思い出すところから始まりがちなアーキテクトのやまぱん！です 😅

補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
結論から言うと、GitHub Copilot でパケットキャプチャの解析、できちゃいました！ 🎉
.pcapng をそのままコンテキストとして渡せたので、本格的なネットワークトラブルシューティングにもそのまま使えそうです。

TL;DR

GitHub Copilot は .pcapng をコンテキストとして読めます。エージェントモードに .pcapng を渡して capinfos / tshark / Python を順番に回せば、本格的なトラブルシューティングにも使えそうでした
今回のサンプルは 14.5 秒・約 111k パケット・137 MB。Fastly 経由の大きな HTTP ダウンロードが主役だとすぐ見えました
IP は並べるだけだと読めない。HTTP Host → DNS 応答 → TLS SNI → RDAP → reverse DNS の順でラベルを付けると一気に読める
使った GitHub Copilot のモデルは GPT-5.4
うまくいった流れは、packet-capture-analysis として Skill 化しました。次から同じ順番でそのまま回せます

この記事でやること

VS Code の GitHub Copilot Chat（以降 GitHub Copilot）に .pcapng を投げて、「実際にパケットキャプチャの解析ってできるの？」を手元で確かめました。

確かめられたのは、GitHub Copilot が capinfos / tshark / Python を組み合わせた解析ワークフローを回せることでした。生の .pcapng をネイティブにデコードしたわけではありません。

以下、その流れを体験まま書いていきます。

前提条件

この例は、Windows のローカル環境で PowerShell から次のツールを使う前提です。

VS Code で GitHub Copilot Chat が使えるローカル環境
capinfos （キャプチャファイルの情報や統計を確認する、Wireshark に含まれるコマンドラインツール）と tshark （コマンドラインでキャプチャと解析を行う、Wireshark に含まれるコマンドラインツール）が実行できること
Python で補助スクリプトを動かせること
安全に扱える検証用の .pcapng （パケットキャプチャの保存形式）があること

検証環境

AI アシスタント: VS Code の GitHub Copilot Chat
モデル: GPT-5.4
OS: Windows 11 Pro, build 26200
シェル: PowerShell
キャプチャ系ツール: Wireshark / Dumpcap 3.4.5

扱ったサンプルは test.pcapng で、解析結果から見える範囲では次のような規模でした。

取得時間: 14.496 秒
総パケット数: 111,738
総通信量: 約 137.06 MB
平均ビットレート: 約 79 Mbps

このサイズでも、エージェントモードに任せたら、ツールを自分で使い分けながら普通に整理してくれました。

確かめたかったこと

GitHub Copilot は、コードだけでなく CLI 実行やファイル作成まで任せられます。だったらパケットキャプチャ解析とも相性が良いはず、と思ったのがきっかけです。

最初にやることはだいたい決まっています。

全体サイズを見る
どのプロトコルが多いか見る
どの IP が帯域を使っているか見る
主要なホスト名や SNI を見る

この初動をそのまま Copilot に渡せるか、を確かめたいだけでした。障害対応や通信確認では、開発者以外でもパケットキャプチャを開くことがあるので、ここが回るととても助かります。

見る順番を先に決めた

実際に触ってみて、一番効いたのは「見る順番を先に決めたこと」でした。

順番はこれだけです。

capinfos で全体を見る
tshark で Endpoints と Conversations を出す
上位 IP をラベル化する

これをエージェントに渡すと、迷子になりません。

TLS / QUIC の復号キーは使っていません。
それでも、DNS、HTTP Host、TLS SNI、会話量、時間推移を見れば、どんな通信か十分つかめました。

この流れはそのまま次回も使えるので、Skill にして残しています。

解析を 4 層に分ける

自分の中では、解析を次の 4 層に分けると楽になりました。

段階	役割	使うもの
1	全体像を掴む	`capinfos`, `tshark`
2	通信量や時系列を見える化	Python, `matplotlib`, `gnuplot`
3	宛先 IP に意味を与える	HTTP Host, DNS, TLS SNI, RDAP
4	説明できる形に圧縮	Markdown レポート

この順でエージェントに渡すと、実務に使えるレポートまで持っていけました。

Step 1. `capinfos` と `tshark` で全体像を見る

ここは Copilot にまるごと任せたところです。.pcapng を渡して「まず全体を掴んで」と伝えると、毎回同じ順で見てくれます。

Protocol Hierarchy （プロトコル階層の統計）
Endpoints （通信先の一覧）
Conversations （会話ごとの統計）

この 3 つを最初に見るだけで、全体像がつかめます。

どのプロトコルが支配的か
どの IP が通信量を食っているか
どの会話が支配的か

サンプルで、Copilot が最初に出してくれた要点はこんな感じでした。

取得時間は約 14.5 秒
TCP が支配的で、QUIC と TLS は一部
最大通信先は 146.75.113.xxx
HTTP 統計では GET 155 が確認できる

ここを固定しておくと、GitHub Copilot に「まずこの順番で集計して」と渡せるので、毎回の品質差が小さくなります。

Step 2. Python で可視化する

「可視化もして」と伝えると、集計用の Python を自分で書いて、グラフまで出してくれました。

エンドポイント別の通信量
会話別の通信量
DNS クエリ
HTTP Host
時系列のスループット

毎回同じ形で PNG と集計結果を出せるようにしておくと、「このグラフから何が読めるか」まで続けて聞けて、可視化がそのまま説明に繋がります。

なお、公開用の図表では public IP とローカル IP の末尾オクテットをマスクし、長いホスト名は短いラベルに寄せています。

通信先別のバイト量

まず効いたのは、どの宛先が帯域を食っているかを棒グラフにすることでした。

このグラフでは、egdownload.fastly-edge.com が支配的で、129.68 MB を占めていました。
さらに最大会話は 94.88 MBで、「本丸」がはっきり見えていました。

HTTP 統計でも GET 155 が出ていたので、見える範囲で「何かが大量にダウンロードされている」構図ははっきり見えています。

全体スループット推移

次に、時間軸で全体の勢いを見るグラフです。

暗号化通信が多いと、いきなり中身を読もうとしても詰まりがちです。
でも時間推移を見ると、「短時間バーストなのか」「だらだら続く通信なのか」が分かるので、行動特性から整理しやすくなります。

通信先別の時間推移

さらに、上位通信先ごとの時間変化を重ねると、「誰がいつ帯域を使ったか」が見えてきます。

このあたりまで来ると、GitHub Copilot にも「怪しい通信」「更新系の通信」「CDN ダウンロード」を分けて説明させやすくなります。

この重ねグラフでは、Fastly が主役で、Microsoft 365 系と思われる通信は混ざっているけれどメインではない、とすぐ整理できました。

Step 3. IP にラベルを付ける

最初は Copilot も IP アドレスをそのまま表に並べてきました。これが読みにくかったので、「そのままの IP じゃなくて、次の順でラベル付けして」と Copilot に渡して改善させました。

HTTP Host
DNS 応答
TLS SNI / gQUIC SNI （TLS / QUIC 接続時に見えるホスト名）
RDAP 所有者情報（IP アドレスの所有者情報を引く仕組み）
reverse DNS （IP から名前を逆引きする情報）

考え方としては、サービス名に近い根拠を優先し、最後に所有者情報で補完する という順番です。

この順番にしておくと、たとえば次のような表が作れます。

| IP             | Label                                       | Source          | Hint                           | RDAP   |
| -------------- | ------------------------------------------- | --------------- | ------------------------------ | ------ |
| 146.75.113.xxx | 146.75.113.xxx (egdownload.fastly-edge.com) | http_host       | Fastly CDN / Fortnite download | FASTLY |
| 52.105.227.xxx | 52.105.227.xxx (MSFT)                       | rdap_org        | Microsoft owned range          | MSFT   |
| 13.107.6.xxx   | 13.107.6.xxx (api.aadrm.com)                | tls_or_quic_sni | Microsoft 365 / Azure related  | MSFT   |

サンプルデータでも、上位通信先はこんな感じで読みやすくなりました。

146.75.113.xxx (egdownload.fastly-edge.com) : Fastly CDN / Fortnite download
52.105.227.xxx (MSFT) : Microsoft owned range
57.150.154.xxx (olkdiagnosticseus.blob.core.windows.net) : Microsoft 365 / Azure related
13.107.6.xxx (api.aadrm.com) : Microsoft 365 / Azure related
185.199.110.xxx (shinyay.github.io) : GitHub related

この表で大事なのは、Label だけでなく Source を残すことです。
あとから見返したときに、「これは HTTP Host 由来なのか」「RDAP 由来なのか」が分かるので、説明責任が持てます。

`hostname` と `organization` を混ぜない

もう 1 つ大事だったのが、ホスト名と所有者情報を同一視しない ことでした。

api.aadrm.com のような名前はサービス寄りの情報
MSFT のような表記は所有者寄りの情報

RDAP は強いですが、実サービス名そのものとは限りません。
この 2 つを分けて持つだけで、レポートを誤解されにくくなりました。

Step 4. Markdown レポートにまとめる

PNG や TSV を大量に出しても、そのままだと把握しづらいです。最終的に GitHub Copilot に Markdown レポートとして要約させると、冒頭を読むだけで全体が分かります。

## 要約

- 取得時間: 14.497 秒
- 総パケット数: 111738
- 総通信量: 137.06 MB
- 推定ローカル端末: 172.16.83.xxx
- 確認できた主要 HTTP Host: egdownload.fastly-edge.com
- 最大会話: 146.75.113.xxx:80 <-> 172.16.83.xxx:50485

## IP ラベル付け方針

- IP はそのまま羅列せず、裏付けが取れる範囲でラベル化する
- ラベル付けの優先順は HTTP Host -> DNS 応答 -> TLS SNI -> RDAP -> reverse DNS

今回も test_report_ja.md まで出したことで、「グラフは見たけど結局どういう通信だったの？」に直接答えられる形になりました。

感想

この記事の主な争点は、「生のパケットを渡して何か引き出せるのか」でした。そこはクリアしていて、GitHub Copilot は .pcapng をコンテキストとして読めました。

結果、capinfos / tshark / Python を組み合わせて、実際の通信の中身まで整理できました。これは 本格的なネットワークトラブルシューティングにそのまま使える ということです。障害時に取ったキャプチャを渡して、指示を次のように返すだけで初動が進みます。

「まず全体掴んで」
「次は Python でグラフ出して」
「IP そのままじゃなくて HTTP Host でラベル付けして」
「最後に Markdown レポートにまとめて」

tshark のオプションを自分で思い出さなくていいのが一番助かりました。

もう 1 個気づいたのは、.pcapng だけじゃなくて他のログも同じワークスペースに放り込めば、そのまま突き合わせて見てもらえることです。アプリの例外ログ、Windows イベントログ、netsh trace の出力あたり。「この時刻のパケットと、この時刻のサーバーログ、突き合わせて」と頼めば、時刻順に並べて 1 本のレポートにしてくれます。.pcapng 1 ファイルで終わる話じゃなく、ワークスペースごと放り込めるのが実戦では効きそうだな、と思いました。

GitHub Copilot 限定の話ではない

ここまでやってきて気づいたんですが、効いていたのは GitHub Copilot 固有の何かじゃなくて、つぎの手順そのものでした。

capinfos / tshark で一次集計する
Python で二次加工と可視化をする
IP を根拠付きでラベル化する
最後に Markdown レポートに落とす

CLI 実行とファイル編集ができるエージェントであれば、Claude Code でも Cursor でも、たぶん同じように進められます。

Skill にする

この流れが 1 回うまくいったら、次は Skill 化です。

今回まとめた公開版の Skill はこれです。

packet-capture-analysis

GitHub の branch 名や path を取り違えると 404 になりやすいので、この記事では実在確認済みの SKILL.md 直リンクを置いています。

Skill 自体をもっと知りたい方は、以前書いたこちらの記事もあわせてどうぞ。

Skill 化も Copilot にまるごと任せました。今回の解析ログをそのまま渡すだけだと手順の羅列で終わってしまうので、追加で 「パケットキャプチャ解析の一般的なナレッジを Web で調べてきて、合わせて Skill に反映して」 と指示しました。

Copilot が Web 検索で集めてきた知識と、今回の実体験を重ねてまとめた結果、Skill には次のような観点が入っています。

方法論の原則
分岐条件
アンチパターン
標準出力
完了条件

ここまで入れておくと、次に同じ手の解析をやるとき、Skill を渡して 「この通りにやって」 と伝えるだけで済みます。

渡すときの完了条件はこんな感じで固定しました。

Markdown レポートを出す
上位通信先を示す
上位会話を示す
根拠付きの IP ラベル表を出す
PNG を最低 2 枚以上出す

毎回同じ成果物が返ってくるようになるので、「よくわからないからもう一回指示し直す」が減ります。

まとめ

最初の問い「GitHub Copilot でパケットキャプチャ解析はできるのか？」の答えは、「できる。.pcapng をコンテキストとして扱えるので、本格的なトラブルシューティングにもそのまま使える」 でした。

実戦で固定したのは、次の 5 点です。

Protocol Hierarchy / Endpoints / Conversations を最初の 3 手として固定する
Python で派生集計と可視化を作る
IP を根拠付きでラベル化し、その流れごと Skill 化する
Expert Information は結論ではなく出発点として使う
暗号化通信は本文復号にこだわりすぎず、行動特性（時系列・相手先の偏り）で整理する

この調子だと、実際のネットワークトラブルで「まずこの .pcapng 見て、変な通信ないか調べて」と渡す使い方が普通にできます。毎回同じ切り分けを思い出すのもいい加減つらいので、次は実際の障害対応で無意識に Copilot に投げてそうです。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

GitHub Copilot に パケットキャプチャ解析をさせる！