SOCKSプロキシを悪用した攻撃の観測と、AIを活用した分析

はじめに

三菱電機の山本です。
三菱電機　情報技術総合研究所では、製品開発時のセキュリティ対策にフィードバックする目的で、複数種類のハニーポットを設置・運用しています。ハニーポットとは、あえて外部からアクセスできる状態にしておき、そこに来る不審な通信を観測するための「おとり」のサーバーのことです。
今回、当社ハニーポットに対して、SOCKSプロキシまたはHTTPプロキシとして悪用できるかどうかを確認するとみられる通信を観測しました。SOCKS4、SOCKS5、HTTP CONNECTといった複数の方式を使い分けながら探る様子がうかがえ、観測事例として興味深い内容でした。
本記事では、この観測結果をご紹介するとともに、翌日に観測された類似の通信ログを用いて、生成AIによる自動分析の傾向も検証します。
（本記事では、一部のデータをマスキングしています。）

本記事でわかること：

• ハニーポットで観測された、オープンプロキシ探索とみられる通信の特徴
• 観測ログだけから断定できること・できないこと
• SOCKS5／SOCKS4／HTTP CONNECTの基本的な見分け方
• 生成AIにログ分析を任せた際に見られた「過剰な断定」の傾向
• 表計算ソフトの自動変換が、AIの分析に与えた影響

SOCKSをご存じの方は、次節「SOCKSとは」を飛ばして「観測結果」から読み進めていただいて構いません。

本記事では、観測ログから比較的強く言える事実と、断定できない事項を区別して記述します。

観測ログから言えるのは、外部の送信元が当社ハニーポットをSOCKS/HTTPプロキシとして利用可能か確認していた可能性が高い、という点です。一方で、実際に中継が成功したこと、踏み台として悪用されたこと、C2通信（攻撃者が乗っ取った機器に指令を送ったり、盗んだ情報を回収したりするための通信）であることは、今回の観測ログのみからは断定できません。

そのため本記事では、通信の送信元を「スキャン主体」または「送信元」と表記します。ハニーポット宛の通信という性質上、悪意が疑われる挙動ではありますが、個別の主体の意図や属性を断定する意図はありません。

なお、ペイロードとは通信の中身にあたるデータそのものを指す用語です。本記事では、1バイト（8ビット、2桁の16進数で表せる情報の単位）を2桁の16進数で表し、バイト間をコロンで区切って表記します（例：05:01:00）。

SOCKSとは

SOCKSはネットワークプロキシプロトコルです。プロキシとは、身近な例で言うと郵便物の私書箱のような仕組みで、送信者に代わって別の相手と直接やり取りしてくれる中継役を指します。SOCKSは、クライアント（通信を開始する側の機器）がプロキシサーバーを経由して外部サーバーと通信するための仕組みで、主にファイアウォールを越えたり、匿名性を確保したりする目的で使われます。[1][7]

SOCKSプロキシとHTTPプロキシの違いは以下の通りです。表の用語は、この後の本文でも順を追って説明します。

項目	SOCKS5	HTTPプロキシ
主な位置づけ	接続先の情報をもとに中継する汎用プロトコル	HTTPを理解して中継するプロキシ
対応プロトコル	TCP全般（UDPも一部対応）	主にHTTP/HTTPS
内容の解釈	基本的に読み取らない（透過的）	命令やヘッダーを読み取る
宛先指定	IPv4/IPv6アドレス、ドメイン名	URL、またはhost:port
名前解決	クライアント側／サーバー側のどちらでも可能	通常はプロキシ側が解決
認証方式	認証なし、ユーザー名/パスワード、GSSAPIなど	Basic、Digest、NTLMなど
代表的な初期通信	05:01:00 など	GET http://…、CONNECT host:port HTTP/1.1
用途	任意のTCP通信の中継（汎用）	Web通信の中継

表の補足：SOCKSは、アプリケーションデータの中身を細かく解釈するというより、接続先の指定や中継方法を扱うプロキシプロトコルです。CONNECTという命令を使えばHTTPプロキシでも他の通信をトンネル（内部を素通りさせる経路）にできます。ATYPは宛先アドレスの種類を表す値、ユーザー名/パスワード認証はRFC 1929 [8] で定義された認証方式、GSSAPIはKerberos認証などと組み合わせて使われる汎用の認証フレームワークです。

SOCKSは、接続先の指定や認証方式などの制御情報は解釈しますが、中継を始めた後のHTTPなどアプリケーションデータの中身は基本的に解釈しません。この性質のため、HTTP以外のプロトコル（SSH、FTP、ゲームなど）にも使えるのが特徴です。その一方で、その自由度の高さが悪用され、踏み台プロキシ（攻撃者が身元を隠すために経由する中継サーバー）として悪用されることがあります。

なお、上表はSOCKS5（RFC 1928 [7]）を前提としています。SOCKS4はTCPのみでUDPに対応せず、ドメイン名指定もできません（SOCKS4a拡張を除く）。また、HTTPプロキシもCONNECTを使えば他のTCP通信をトンネル化できるため、「SOCKSは汎用、HTTPはWeb専用」という区別は厳密なものではありません。

観測結果

集計の定義

「件数」が何を数えたものかによって解釈が変わるため、本記事の数値は以下の定義で集計しています。

• 観測期間：2026年4月20日 00:00:00 ～ 23:59:59
• 対象：当社ハニーポットのTCP 1080番ポート
• 件数の単位：ハニーポットが出力したログ行単位

そのため、本記事の件数は、TCPセッション数やペイロードのユニーク出現回数とは一致しない場合があります。

なお、後述のAI比較実験で使用した検証用サンプルは、本節の観測期間とは別の日（4月21日）に取得したデータです。同一のスキャン活動とみられる類似の通信が翌日も観測されたため、AIモデルの分析能力を検証する目的で、その一部を検証用データとして選定しました。本節の観測結果（121,863件等）とは独立した集計であり、両者の数値を混同しないようご注意ください。

観測概要

• SOCKS/HTTPプロキシ関連の通信：121,863件
• ユニーク送信元IPアドレス：約50個強。主な送信元レンジは次の2つです。
  　AA.BB.CC.*：33個
  　DD.EE.FF.*：17個
  　※「*」は、第1～第3オクテットが共通で、第4オクテットのみが異なる複数のIPアドレスを表します。
• 上記の通信件数（121,863件）に占める割合：
  　AA.BB.CC.*：約65.9%
  　DD.EE.FF.*：約33.8%
  　この2レンジで、通信件数の約99.7%を占めます。残り約0.3%は、この2レンジ以外の少数の送信元によるものです。
• 送信元ポート番号：エフェメラルポート帯とみられる多様な値

RFC 1928 [7]、および参考解説 [2] をもとに、観測したパケットに含まれるペイロードの一部を紹介いたします。

SOCKS5 認証方式ネゴシエーション

# 送信元→ハニーポット
05:01:00

それぞれの意味は次のようになります。

• 05 = SOCKS version 5
• 01 = 提示する認証方式の数
• 00 = No Authentication（認証なし）

送信元はハニーポットに対して、「SOCKS5を使用し、認証方式として認証なしを提示する」ネゴシエーションを開始しています。この段階では、まだ宛先への接続要求は行われていません。

SOCKS5 認証方式選択応答

# ハニーポット→送信元
05:00

# ハニーポット→送信元
05:ff

それぞれの意味は次のようになります。

• 05 = SOCKS version 5
• 00 = No Authentication Required（認証なし方式を選択）
• ff = No acceptable authentication methods（受け入れ可能な認証方式なし）

ハニーポットは送信元に対して、05:00（認証方式として「認証なし」を選択）や 05:ff（受け入れ可能な認証方式なし）を応答しています。これは認証方式の選択結果であり、宛先への中継接続が成功したことを意味するものではありません。

なお、SOCKS4やHTTP GETなど、SOCKS5のネゴシエーションとして解釈できない通信に対しても、今回の検証用サンプルではハニーポットは同じ 05:ff を返していました。05:ff はSOCKS5の認証方式選択応答として定義された値であり、SOCKS4やHTTPの仕様上の正式な拒否応答ではありません。今回のログでは、ハニーポット実装が解釈できない入力に対してこの値を返していたものと考えられます。

SOCKS5 接続要求

# 送信元→ハニーポット
05:01:00:01:GG:HH:II:JJ:KK:LL

SOCKS5のCONNECT要求は VER CMD RSV ATYP DST.ADDR DST.PORT という形式です。この6つの項目は、それぞれ「バージョン」「命令の種類」「予約領域（今は使われていない部分）」「宛先の指定方法」「宛先アドレス」「宛先ポート番号」を表します。IPv4宛先の場合、それぞれの意味は次のようになります。

• 05 = SOCKS version 5
• 01 = CONNECT（接続してほしいという命令）
• 00 = RSV。Reserved（予約領域）で、現時点では意味を持たない
• 01 = ATYP（Address Type、宛先アドレスの種類）が01＝IPv4アドレス指定であることを示す
• GG:HH:II:JJ = 宛先IPv4アドレス
• KK:LL = 宛先ポート番号p。16bit big-endian（2バイトの数値を、大きい桁から先に並べる表記方法）で表現される

送信元はハニーポットを経由して、GG.HH.II.JJ:pへ接続しようとしています。

応答ペイロードの解釈における留意点

ログ上には、上記の 05:00 / 05:ff のほかに、05:00:00 および 05:09:… で始まる応答も記録されていました。当初、これらの解釈には元のバイナリログでの確認が必要と考えていました。しかし、検証用に抽出した30秒分のサンプルデータを詳細に解析した結果、次のことが分かりました。

• 05:00:00 は、表計算ソフトが 05:00（2バイト）というコロン区切り文字列を時刻値として自動変換した結果でした。今回使用した環境では、セルの表示形式（h:mm と h:mm:ss）に変換前のコロン区切りの数に対応する手がかりが残っていたため、これをもとに機械的に復元できました。RFC 1928上、認証方式選択応答は VER METHOD の2バイト固定です。そのため、少なくとも「認証方式選択応答」としての 05:00:00 は仕様に合致しません。今回のサンプルでは、表計算ソフトによる時刻値への自動変換が原因であることを確認しています。
• 05:09:… は、バイト長とフィールド配置の上ではSOCKS5 CONNECT応答形式に合う10バイト列でした。この形式は VER REP RSV ATYP BND.ADDR BND.PORT で、それぞれ「バージョン」「応答結果」「予約領域」「アドレス種別」「サーバー側でバインドされたアドレス」「サーバー側でバインドされたポート」を表します。今回のREPフィールド（応答結果を表す1バイト）は 09 でした。RFC 1928で定義されているREPフィールドの値は 00～08 であり、09 は未定義です。そのため、標準的なSOCKS5応答としての意味は断定できません。BND.ADDR/BND.PORTが 0.0.0.0:0 である点は、有効な接続情報が返されていない状態と整合します。なお、この 09 という値の原因（ハニーポット実装上の独自仕様か、ログの変換処理か、その他の要因か）は、今回の観測ログだけでは断定していません。
• コロン区切りのバイト列は、表計算ソフトで時刻値として自動変換される場合があります。集計時は文字列として保持する必要があります。

SOCKS4 接続要求

# 送信元→ハニーポット
04:01:KK:LL:GG:HH:II:JJ:00

SOCKS4のCONNECT要求は VN CD DSTPORT DSTIP USERID という形式です。SOCKS5と異なり認証方式のネゴシエーションがなく、いきなり接続要求から始まります。

• 04 = SOCKS version 4
• 01 = CONNECT
• KK:LL = 宛先ポート番号
• GG:HH:II:JJ = 宛先IPv4アドレス
• 00 = USERID（ユーザー識別子）の終端。今回のログでは中身が空でした

今回のログでは、SOCKS5だけでなく、この形式に合致する通信も一定数観測されました。今回のハニーポット実装では、SOCKS4形式の要求をSOCKS4プロキシ要求としては受理せず、SOCKS5の認証方式選択応答である 05:ff を返していました。

HTTP CONNECT

# 送信元→ハニーポット
CONNECT GG.HH.II.JJ:p HTTP/1.1
Host: abcde.fgh

CONNECTは、HTTPプロキシに対して任意の宛先 host:port へのTCPトンネル確立を要求するメソッドです[9]。したがってこの通信は、ハニーポットがSOCKSプロキシだけでなく、HTTPプロキシとしても利用できるかを確認する試行と考えられます。

HTTP/1.1 200 Connection Established などの成功応答は確認できておらず、CONNECTによる中継が成立した証跡はありません。なお、上記の例ではCONNECTの宛先がIPアドレス、Hostヘッダーがドメイン名となっており両者が一致していませんが、これは検証用サンプルにおいても元データのままの挙動であり、マスキングによる差異ではないことを確認しています。HTTP/1.1のCONNECTでは、リクエストターゲットのauthority（host:port）とHostヘッダーの値は、通常一致しているべきものです。そのため、この不一致は通常のWebクライアントとは異なる挙動の一つと考えられます。

HTTP GET

# 送信元→ハニーポット
GET /check_3c29f...48e HTTP/1.1
Host: abcde.fgh
...

/check_<random> というパスは、到達性確認やプロキシチェッカー由来の通信である可能性があります。このリクエストラインは、GET /check_<random> HTTP/1.1 という形式（origin-form）であり、HTTPプロキシに対して直接送る場合に典型的な GET http://host/check_<random> HTTP/1.1 という形式（absolute-form）ではありません。origin-formだけでは、プロキシ経由の確認とHTTPサーバーへの直接アクセスを区別できないため、追加の確認が必要です。検証用サンプルでは、このGETがSOCKSネゴシエーションやHTTP CONNECTを一切経ずに、TCP接続直後の最初のアプリケーションデータとして届いていることを確認しました。つまりトンネル内のリクエストではなく、1080番ポートに直接投げられたものです。ハニーポットはこれを解釈できずに 05:ff を返しています。

ただし、このパスの目的そのもの（プロキシ死活確認なのか、他の意図があるのか）は、応答内容による裏付けがないため断定できません。ここまでに挙げた3点——05:ffの解釈、時刻変換の事故、このパスの目的——は、いずれも後述のAI比較実験で改めて取り上げます。

観測ログから見た通信の特徴

観測ログから、以下の特徴が確認されました。

• 4月20日の観測期間全体を通じて、短時間に異なるポートから多数の接続
• SOCKS4、SOCKS5、HTTP CONNECT、HTTP GETが混在
• HTTP GETで、/check_<random>を要求
• TCPフラグと時系列を確認した範囲では、アプリケーションデータの送信後、短時間でFINまたはRSTにより接続が終了していた

状況を図示すると、以下のように表されます。図の左側が送信元、中央が当社ハニーポット、右側が送信元の指定した接続先です。矢印は「そのような通信が届いた」ことを示すもので、実際に中継が成功したことを意味しません。

※上段の/check_<random>についても、リクエストが正常に処理されたことを示すものではありません。この要求に対しては、HTTPとしての応答ではなく、ハニーポット実装による 05:ff のみが観測されています。

観測から言えること／言えないこと

比較的強く言えることは、以下の点です。

• 短時間に多数の送信元から、SOCKS4／SOCKS5／HTTP CONNECT／HTTP GETを織り交ぜた通信が届いており、オープンプロキシとして利用可能なホストを探索する挙動と整合します。AA.BB.CC.*、DD.EE.FF.*のレンジから、オープンプロキシ探索を目的とした通信が送信されていた可能性が高いと考えられます。

一方で、観測ログのみからは以下を断定できません。

• 実際に中継が成功したこと。SOCKS5 CONNECT応答における成功コード（REP=00）および HTTP/1.1 200 Connection Established は確認できていません。
• ハニーポットが踏み台として継続的に悪用されたこと。
• ハニーポットが要求された宛先へ実際に外向き接続を試みたこと。本記事のログは、送信元/宛先IPアドレスをスキャン主体のIPアドレスでフィルタリングして抽出したものです。仮にハニーポットが要求された宛先（フィルタ条件に含まれないIP）へ接続を試みていたとしても、その通信自体がこの抽出データには含まれません。「ログにない」ことは「起きなかった」ことの証拠にはならない、という点に注意が必要です。
• C2通信であることも、今回の観測ログだけでは断定できません。既知のC2ドメイン／IPとの一致、マルウェア検体との関連、定期的なビーコン性、C2フレームワークに固有のURIやUser-Agentといった根拠は確認できていません。そのため本記事ではC2とは断定せず、主な解釈をオープンプロキシ探索とします。

ここまでは、人手による観測ログの解釈を説明しました。ここからは、同じ分析を生成AIに任せた場合、どこまで正しく解釈できるのかを検証します。特に注目したのは、「ログから判断できないことを、それでも断定してしまわないか」という点です。

AIを利用した分析

今回、3つの生成AIモデル（Claude Sonnet 4.6 [3]、Claude Opus 4.8 [4]、GPT-5.5 [6]）を使用し、同一のパケットログを2つの条件で分析させる実験を行いました。条件は、ペイロード列を文字列のまま保持したもの（条件S）と、前述の時刻変換の事故を再現した状態（条件E）です。各モデル・各条件で5回ずつ実行し、計30回の結果を、あらかじめ用意した正解データと機械的に突き合わせました。詳細な手順は【補足】に掲載しています。

なお、GPT-5.4 mini [5]は、xlsxファイルを画面表示用のプレビューとしてしか扱えず、610行規模のデータを正確に処理できなかったため、比較対象から除外しています。この検証は当社独自のGUI経由で行ったもので、モデル自体の限界かGUI側のファイル処理の実装によるものかは切り分けられません。GPT-5.5も同じ独自GUI経由で実行しているため（Claude 2モデルはAnthropic公式のチャット画面を使用）、以下で報告するGPT-5.5の結果も、モデル自体の性質か実行経路の違いによるものかを完全には切り分けられない点にご留意ください。

本比較は各AIモデルの絶対的な優劣を示すものではなく、今回の条件下で見られた解釈の傾向や限界を示すものです。各条件5回という小規模な試行であるため、以下で述べる差はいずれも統計的な優劣ではなく、今回のデータと実行環境における観察結果として扱います（以下、この断りは省略します）。

主要な発見：モデルを問わない共通の過剰断定

正解データには、観測ログだけでは本来判断できないはずの項目を2つ意図的に用意していました。

• ハニーポットが実際に外部への接続を試みたか
• /check_<random> というパスの目的が何であったか

いずれも正解は「判断できない」です。前者は前述の通りデータがフィルタリングされた抽出データであるため、後者は /check_<random> へのリクエストに対してハニーポットから 05:ff のみが返されており、応答内容による裏付けがないためです。

30回の実行のうち、この2項目を正しく保留できた回数は次の通りでした。ここでの「断定した回数」は、「試みた」「目的はこうだ」のように言い切った場合と、「試みていない」のように否定を言い切った場合の両方を含みます。

項目	保留できた回数	断定した回数
外部接続を試みたか	1/30	29/30
パスの目的	0/30	30/30

3モデルとも、ほぼ全ての試行で「ログにない」ことを「起きなかった」ことの証拠として扱いました。もっともらしい推測を、確認された事実であるかのように断定してしまったのです。モデル間の性能差はほとんど見られませんでした。この2点に関しては、3モデルが同じ盲点を共有していたというのが、今回の実験で最も強く出た結果です。

データの由来や範囲に制約がある場合、その制約を自分から疑うことを、少なくとも今回の3モデルはしませんでした。分析対象のデータがどのような条件で抽出されたものかを明示的に伝える、「データにない事実を断定するな」と具体的に指示するといった対策が必要になりそうです。

モデル間で差が出た点

一方で、次の2点にはモデル間の差がありました。

今回の5回ずつの試行では、Claude Opus 4.8とClaude Sonnet 4.6において、認証の判定を取り違える回答がGPT-5.5より多く観察されました。 正しくは「SOCKS5として正しくネゴシエーションした通信では、認証方式としてNo Authentication Requiredが選択されている」ですが、Opus 4.8は10回中4回、Sonnet 4.6は10回中3回、「一部承認・一部拒否が混在」と誤答しました。GPT-5.5はこの誤りを一度もしていません。これは、拒否応答が非SOCKS5の通信（SOCKS4やHTTPなど）に対するものであることを見落とした結果です。

時刻変換の事故への対応も、3モデルで割れました。

モデル	対応
GPT-5.5	変換に気づくが、デコード結果への反映を毎回怠る（5回中5回）
Claude Opus 4.8	初回は気づかず「3バイトの規格違反」という別の誤った理論を構築。2回目以降は気づき、正しく2バイトへ復元
Claude Sonnet 4.6	変換の発生自体は毎回検出するが、復元したバイト数を毎回誤る

正しい2バイトへの復元に、5回中5回とも到達できたモデルはありませんでした（※小規模試行、以下同様）。

事実抽出そのものの精度

件数やIOCなど、事実として答えが決まっている項目でも精度に差がありました。条件Sではおおむね高精度でしたが、条件E（時刻変換あり）では3モデルとも精度が下がり、下がり方はモデルによって異なりました（具体的な数値は【補足】参照）。なお、GPT-5.5は当社独自のGUI経由で実行しており、この経路の違いがスコア差に影響した可能性を完全には排除できません。

自己矛盾という第三の失敗モード

正解データと比較しなくても、回答単体の内部の食い違いから見つかる失敗もありました。GPT-5.5とClaude Opus 4.8がそれぞれ1回ずつ、「あるバイト列を正しくデコードして記載しているのに、その種類の件数を0と回答する」という矛盾を起こしています。デコードの能力と、その結果を集計に反映する能力が、必ずしも一致しないことを示しています。

おわりに

ここまでお読みいただき、ありがとうございました。
今後もハニーポットで観測・分析した結果について発信していく予定です。ご質問やコメント、お待ちしております。

参考

[1] remote.it, SOCKS Proxies: What They Are and What They're Used For (https://www.remote.it/resources/understanding-socks-proxies/)
[2] nogawa.blog, SOCKSプロトコルを完全に理解する (https://nogawa.blog/2026/05/09/socks-protocol-complete-guide-socks5/)
[3] anthropic.com, Claude Sonnet 4.6 (https://www.anthropic.com/news/claude-sonnet-4-6)
[4] anthropic.com, Claude Opus 4.8 (https://www.anthropic.com/news/claude-opus-4-8)
[5] openai.com, GPT 5.4 mini (https://openai.com/ja-JP/index/introducing-gpt-5-4-mini-and-nano/)
[6] openai.com, GPT 5.5 (https://openai.com/ja-JP/index/introducing-gpt-5-5/)
[7] IETF, RFC 1928: SOCKS Protocol Version 5 (https://www.rfc-editor.org/rfc/rfc1928)
[8] IETF, RFC 1929: Username/Password Authentication for SOCKS V5 (https://www.rfc-editor.org/rfc/rfc1929)
[9] IETF, RFC 9110: HTTP Semantics (https://www.rfc-editor.org/rfc/rfc9110)

【補足】自動分析の手順と結果

本節では、生成AIを使用した自動分析の手順と、その評価方法を紹介します。
※ AIの出力は非決定的であり、本節で紹介する自動分析手順を再現しても、本節で示す結果が得られない可能性があります。

実験の設計

AIに比較・採点までさせると、比較対象のモデル自身が採点を担当することになり、公平な評価とは言えません（自己評価バイアス）。そこで今回は、次のような設計にしました。

• 繰り返し回数：AIの答えは毎回同じとは限らないため、各モデル・各条件につき5回ずつ実行し、合計30回分の結果を集めました。
• 答え方の形式：あらかじめ項目を決めた「回答用紙」（JSON形式のスキーマ）に記入させました。件数を答える欄が14個、判断を答える欄が8個のほか、IOC（Indicator of Compromise。侵害の痕跡となるIPアドレスやドメイン名などの手がかり）や非標準値（仕様上定義されていない値）を書く欄があります。
• 採点の方法：あらかじめ用意した正解と機械的に突き合わせて自動採点しました。人やAIによる主観採点は行っていません。
• 正解の作り方：正解データの作成では、比較対象外のモデルによる独立分析を参考情報として使いました。ただし、最終的な正解はAIの出力をそのまま採用したものではなく、RFC 1928の記述と実際のバイト列の長さを人が照らし合わせて確定しています。

以上の流れを図にまとめると、以下のようになります。上段が実際にAIへ分析させる流れ、下段が採点の基準となる正解データを事前に確定させる流れです。両者は右端の「自動採点」で合流します。

対象データ

分析対象は、前掲の「観測結果」の節で扱った日（4月20日）とは別の日（4月21日）に観測したデータです。同じスキャン活動とみられる通信が、翌日にも届いていました。その中から、ハニーポットが30秒間に送受信したパケットのうち、送信元と宛先のIPアドレスがスキャン主体のものだけを抜き出した610件を使いました。ファイルに含まれる項目は、通信の時刻、送信元の国、送信元IPアドレス、送信元ポート番号、ペイロード（通信の中身）、プロトコル名、宛先IPアドレス、宛先ポート番号、TCPフラグ（通信の状態を表す制御情報）の9個です。

このファイルを2種類用意しました。ペイロードの列を文字列のまま保存した「条件S」と、前述した時刻変換の事故——ペイロードの一部が表計算ソフトによって時刻の値に化けてしまう現象——をわざと再現した「条件E」です。両方のファイルの違いは、ペイロード列のうち44個のセルだけです。

プロンプト

各モデルには、条件Sまたは条件Eのxlsxファイルと、次の指示文（プロンプト）を渡しました。すべてのモデルに、まったく同じ文言を使っています。

添付のxlsxは、あるホストが受信・送信したTCPパケットの記録です。内容を分析し、下記のJSONスキーマに厳密に従って出力してください。判断できない項目は、数値なら null、列挙値なら "undetermined"、配列なら空配列としてください。推測で埋めないでください。

「推測で埋めないでください」という一文が、今回の実験のポイントです。分からないことは分からないと答えてよい、とはっきり伝えた上で、実際にそれができるかを見ています。

回答用紙（JSONスキーマ）に用意した欄は、大まかに次の通りです。

• 件数を答える欄：14項目（総パケット数、SOCKS5ネゴシエーションの件数、CONNECT応答の成功／失敗数など）
• プロトコルの一覧、デコード結果、IOC（送信元レンジ・ドメイン・宛先ポート）
• 判断を答える欄：8項目。うち3項目（外部接続を試みたか、パスの目的、送信元が同一人物によるものか）は、正解が「分からない」であるように意図的に設計しています
• 非標準値、データ品質に関する気づき

実行環境と再現性について

本実験は2026年8月に実行しました。Claude Sonnet 4.6とClaude Opus 4.8はAnthropic公式のチャット画面（claude.ai）から、GPT-5.4 miniとGPT-5.5は当社独自のGUIから、それぞれxlsxファイルをアップロードする形で実行しています。実行経路がベンダーによって異なるため、この違い自体が結果に影響した可能性は完全には排除できません。API経由でファイルを直接渡す方法とも、ファイルの読み込み方や既定の設定が異なる可能性があります。

思考の深さ（reasoning effort）や温度（temperature）などの詳細設定は、いずれの実行環境でも変更せず、既定設定のまま実行しています。モデルは日々更新されるため、将来同じ手順で実行しても、本記事と同じ結果になるとは限りません。

採点は、正解データとJSON形式の回答を機械的に突き合わせるスクリプトで行っています。

採点の指標

何をどう採点したかを、以下にまとめます。

指標	内容
件数の正確性	件数を答える14項目のうち、何割が正解と一致したか
デコードの正確性	バイト列を分解した結果（項目名や値）が、何割正しかったか
IOCの抽出	送信元のIPアドレス範囲・ドメイン名・宛先ポートを、どれだけ過不足なく見つけられたか（F1という、正確さと網羅性を1つの数値にまとめた指標。1.0に近いほど良い）
判断の適否	8つの判断項目のうち、何割が正解と一致したか。「分からない」が正解の項目を言い切ってしまうと不正解になる
罠検出	条件Eで、時刻変換の問題に気づけたか
過剰断定	「分からない」が正解の項目を、言い切ってしまった回数。正確性とは別に数えている
自己矛盾	正解と比べなくても分かる、回答そのものの中の食い違い（例えば、バイト列を正しく読み取っているのに、その件数を0と答えてしまう、といった矛盾）

モデル別の傾向（件数・デコードの正確性）

条件ごとの平均正解率は次の通りでした（※小規模試行、以下同様）。
※件数の正確性は5回分の平均、デコードの正確性は5回のうち最も低かった回と最も高かった回の範囲を示しています。デコードは1試行内に多数のフィールド判定が含まれ、試行ごとに間違え方が変わるため、平均よりも範囲の方が実態を反映しやすいと判断しました。

モデル	条件S・件数の正確性	条件E・件数の正確性	条件S・デコードの正確性の範囲	条件E・デコードの正確性の範囲
Claude Sonnet 4.6	100%	100%	96～100%	96～100%
Claude Opus 4.8	99%	100%	67～100%	96～100%
GPT-5.5	90%	86%	96%	59～81%

GPT-5.5の条件Eでのデコードの正確性が低いのは、本文で述べた「時刻変換に気づくが直さない」という失敗が、5回中5回で起きたためです。Claude Opus 4.8で条件Sの数値が低い回が2回ありますが、これは時刻変換とは関係のない、細かい読み取り漏れが理由です。

過剰断定の内訳

過剰断定の集計は3項目を分母としています。本文で触れた2項目（外部への接続を試みたか、パスの目的）に加え、「複数の送信元レンジが同一の主体によるものか」という判断項目も、正解が「分からない」です。モデル・条件ごとの内訳は次の通りです。

モデル	条件	過剰断定の回数（3項目中、5回の平均）
Claude Sonnet 4.6	S	2.0
Claude Sonnet 4.6	E	2.0
Claude Opus 4.8	S	2.0
Claude Opus 4.8	E	2.4
GPT-5.5	S	1.8
GPT-5.5	E	2.0

3項目目（送信元の帰属）は、本文の2項目ほど過剰断定が起きておらず、多くの試行で正しく保留できていました。GPT-5.5の条件Sだけ平均が1.8とやや低いのは、5回のうち1回だけ「外部への接続を試みたか」を正しく保留できた回があったためです。

この実験の限界

• データは1種類（30秒間・610件）だけです。時間帯や攻撃の種類が変われば、違う結果になる可能性があります。
• 5回の繰り返しは、結果が偶然でないかを確認するための最小限の回数です。本記事の数値は「5回中何回」という書き方にとどめており、統計的に意味のある差だと主張するものではありません。
• レポートとしての読みやすさや、対応策の実用性は、今回の実験では測っていません。
• 実行経路がベンダーによって異なる点（上記「実行環境と再現性について」）も、結果に影響した可能性を排除できない限界の一つです。