Sonnet 5.5・Opus 5.5 比較｜ARP 解説アニメで検証

はじめに

生成 AI に技術教材や説明用のコンテンツを作らせる機会が増えています。同じ依頼でもモデルによって成果物の構成や説明の粒度は変わり、見た目が整っていても、技術的な表現に誤りが残ることがあります。

本記事では、2026 年 9 月 28 日に公開された Claude Sonnet 5.5 と、9 月 22 日に公開された Claude Opus 5.5 に同じプロンプトで ARP の解説アニメーションを作成させ、制作時間、説明の丁寧さ、技術的な正確さを比較します。成果物は音声なし・字幕付きの HTML アニメーションで、動画ファイルや動画生成モデルの映像ではありません。ゲーム制作で操作性を比べた『Opus 5.5・Opus 5・Astra 比較｜卓球ゲーム制作で検証』に対し、本記事は教材としての説明力と正確さを評価の中心に置いています。

結論を先に述べます。今回の 2 本では、Opus 5.5 のほうが短い作成時間（11 分）で、判断の途中経過やヘッダーの情報を段階的に示す成果物を作成し、筆者も丁寧でわかりやすいと感じました。Sonnet 5.5 の成果物は、短い字幕で要点を示す構成です。ただし両モデルとも、ルーター通過時の説明に誤読を招く表現が 1 か所ずつ残っており、教材として公開する前には技術レビューが必要です。今回の結果は初回成果物 1 本ずつの比較であり、モデル全般の速度や性能を示すものではありません。

検証の前提｜両モデルの位置づけと制作条件

まず公式情報で両モデルの位置づけを確認し、続いて題材と制作条件を示します。

公式情報に見る Sonnet 5.5 と Opus 5.5 の位置づけ

Anthropic は Sonnet 5.5 を、Claude 5.5 ファミリーの 2 番目のモデルで、Opus 5.5 を補完する高速・低コストのモデルと位置づけています。範囲の明確な日常的な作業、バグ修正、文書やスライドの作成を得意とする一方、持続的な判断を要する複雑な作業では Opus 5.5 が優位だと説明しています。

参考: Introducing Claude Sonnet 5.5（Anthropic）
“Opus 5.5 remains clearly stronger at complex, open-ended work requiring sustained judgment”
（Opus 5.5 は、持続的な判断を要する複雑で自由度の高い作業において、引き続き明確に優位である）
https://www.anthropic.com/claude-sonnet-5-5

公式が示す「30% 超高速」は Sonnet 5 との比較で、Sonnet 5.5 が Opus 5.5 より常に速いことを示すものではありません。また、既定の effort は Claude のアプリで Medium、Claude Platform で High と説明されています（今回の制作で使った設定は、後述のとおり未確認です）。Opus 5.5 の料金や effort の考え方は、『Claude Opus 5.5 とは｜Opus 5 との違いと使い始めの確認事項』で整理しています。

ARP の解説アニメーションを題材にした理由

ARP は、同じセグメント宛てと別セグメント宛てで「ARP で調べる相手」が変わり、ルーター通過時には Ethernet ヘッダーが作り直される一方で IP アドレスは変わらない、という複数の対応関係を順に見せる必要があるテーマです。時間軸のある表現に向く一方、MAC アドレスの付け替えのような細部で誤りが入りやすいため、説明力と正確さを同時に評価できると考えました。ARP 自体の仕組みは『ARP とは｜IP アドレスと MAC アドレスを結ぶ仕組みとルーター越えの違い』で解説しています。

使用したプロンプトと共通の制作条件

両モデルには同じプロンプトで作成を依頼し、最初に得られた HTML（初回成果物）を比較対象としました。記事執筆のために HTML は修正していません。使用したプロンプトは次のとおりです。

ARP の仕組みを説明する、日本語の解説アニメーションを作成してください。

対象読者は、IP アドレスの基本は知っているものの、IP アドレスと MAC アドレスの使い分けにまだ慣れていないネットワーク初学者です。

「同じセグメントの相手に送る場合」と「ルーター経由で別のセグメントの相手に送る場合」で、ARP によって誰の MAC アドレスを調べるのかが分かる教材にしてください。

【納品形式】

- HTML・CSS・JavaScript を 1 つの HTML ファイルにまとめてください。
- 保存した HTML ファイルをブラウザで開くだけで動作させてください。
- 外部ライブラリ、外部画像、外部フォント、外部通信は使用しないでください。
- インストールやビルドを必要としない構成にしてください。
- 完成したファイル名は arp-animation.html としてください。

【画面と再生】

- PC のブラウザでの閲覧・画面収録を想定し、主な表示領域は横長の 16:9 としてください。
- ウィンドウの大きさに合わせて縮小し、文字や図が欠けないようにしてください。
- 音声・BGM は不要です。日本語の字幕と図の動きだけで内容を理解できるようにしてください。
- 全体の再生時間は 60〜90 秒を目安にしてください。
- 「再生」「一時停止」「最初から」の操作を用意してください。
- ページを開いた直後は停止し、「再生」を押すと最初から最後まで自動で進む構成にしてください。
- 再生終了後は、最後の画面で停止してください。

【ネットワーク構成】

LAN1：192.168.10.0/24

- PC-A：192.168.10.10/24
- PC-B：192.168.10.20/24
- R1 の LAN1 側：192.168.10.1/24
- PC-A・PC-B・R1 の LAN1 側を、L2 スイッチ SW1 に接続します。
- PC-A のデフォルトゲートウェイは 192.168.10.1 とします。

LAN2：192.168.20.0/24

- R1 の LAN2 側：192.168.20.1/24
- PC-C：192.168.20.30/24
- R1 の LAN2 側と PC-C を接続します。

構成図は、この接続関係が分かるように配置してください。

【説明する 2 つの場面】

場面 1：PC-A から PC-B へ送信

- PC-A が宛先を同一セグメントと判断する。
- PC-A が PC-B の MAC アドレスを調べるため、ARP Request を送る。
- Request が SW1 を介して LAN1 内に届く様子を示す。
- PC-B が ARP Reply を PC-A に返す。
- PC-A の ARP キャッシュに PC-B の対応情報が登録される。
- PC-A が PC-B 宛てにデータを送信する。

場面 2：PC-A から PC-C へ送信

- PC-A が宛先を別セグメントと判断する。
- PC-A がデフォルトゲートウェイの MAC アドレスを ARP で調べる。
- R1 の LAN1 側が応答し、PC-A が対応情報を記憶する。
- PC-A が、IP の宛先を PC-C、Ethernet の宛先 MAC を R1 の LAN1 側として送信する。
- R1 が LAN2 側で PC-C の MAC アドレスを ARP で調べる。
- R1 が PC-C へデータを転送する。

【技術上の前提】

- IPv4 over Ethernet の通常の通信を扱います。
- 各場面の開始時点で、説明に必要な ARP キャッシュは空とします。
- NAT、Proxy ARP、VLAN、特殊な静的ルートは使用しません。
- ARP Request のブロードキャストがルーターを越えて転送される表現にしないでください。
- 今回の通常の問い合わせへの ARP Reply は、問い合わせ元へのユニキャストとして示してください。
- R1 の LAN1 側と LAN2 側の MAC アドレスを区別してください。
- MAC アドレスは「MAC-A」「MAC-R1-LAN1」などの説明用ラベルで構いません。その場合は、説明用の略記であることを示してください。
- ARP の通信と、その後のデータ通信を区別してください。
- 復路の通信やスイッチの MAC アドレス学習の詳細は、今回の説明対象に含めなくて構いません。

【表現の方針】

- 技術的な正確さを最優先にしてください。
- 次に、初学者が説明を追えること、文字の読みやすさ、図と字幕の対応を重視してください。
- 色だけでなく、ラベルや矢印でも通信の種類や方向を区別してください。
- 情報を一度に詰め込まず、説明に合わせて段階的に見せてください。
- 最後に、同一セグメントと別セグメントで「ARP で調べる相手」がどう違うかを簡潔に整理してください。
- 配色、レイアウト、演出、場面転換は自由に工夫してください。

確認質問はせず、この条件の範囲で判断して完成させてください。可能な範囲で動作確認を行い、実際に確認した内容と、未確認の内容を区別して報告してください。

両成果物の HTML には、次の仕様が共通して実装されていました。

• HTML・CSS・JavaScript を 1 つの HTML ファイルにまとめ、外部ライブラリと外部通信を使っていない。
• LAN1（192.168.10.0/24）と LAN2（192.168.20.0/24）を R1 がつなぐ構成で、PC-A から PC-B、PC-A から PC-C への 2 場面を描いている。
• MAC アドレスは MAC-A、MAC-R1-LAN1 などの略記を使い、説明用であることを画面内に注記している。
• ARP Request、ARP Reply、ARP キャッシュへの登録、その後のデータ通信の順に進み、最後にまとめの画面がある。
• 16:9 の画面を字幕付きで約 90 秒再生し、再生・一時停止・最初からのボタンを備えている。

Sonnet 5.5・Opus 5.5 の成果物と作成時間の比較

2 本の成果物は、構成とアドレス設計がほぼ同じで、情報の配置と説明の粒度が異なります。

2 つの成果物

Sonnet 5.5 が作成した ARP 解説アニメーションです。

Opus 5.5 が作成した ARP 解説アニメーションです。

作成時間と実装の比較

作成時間の 24 分と 11 分は、今回の 1 回ずつの制作で筆者が確認した値であり、Sonnet 5.5 と Opus 5.5 の生成速度の差として一般化できるものではありません。制作時の詳細条件は現時点で確認できておらず、時間差の原因も特定していません。

評価と確認の主体

本記事の評価と確認は、次の 3 つを区別して記載しています。

筆者の視聴評価

筆者本人が両方の成果物を視聴し、見やすさやわかりやすさについて感想を述べたものです。主観評価であり、測定結果ではありません。

ChatGPT によるコード確認

制作支援に使った ChatGPT が、HTML のコード確認と JavaScript の構文検査を行いました。本記事の実装に関する記述は、HTML のコードに基づきます。

執筆環境での追加確認

記事執筆時にヘッドレスの Chromium（表示領域 1600×1000）で両方の HTML を開き、各成果物に含まれるシーク用の関数で全区間を 0.5 秒刻みに表示させたところ、JavaScript のエラーは表示されませんでした。スペースキーで再生を始めると再生時間が進むことも確認しています。この確認では、通しでの実時間再生や、実際のブラウザー・スマートフォンでの見え方は確認していません。ラベルの重なりなど表示上の細部は、この環境の静止画で確認したものです。

説明の丁寧さの違い｜筆者の感想を裏付ける実装

筆者は視聴後、Opus 5.5 のほうが丁寧で見やすく、わかりやすいと感じました。これは筆者の主観評価ですが、HTML の実装を見ると、その印象につながる違いを確認できます。

ネットワークの判定を段階的に見せる

別セグメント宛ての場面で、Opus 5.5 は右側のパネルに、自分のネットワーク（192.168.10.0）、宛先のネットワーク（192.168.20.0）、不一致のため別セグメントという判定、デフォルトゲートウェイに渡すこと、ARP で調べる相手が 192.168.10.1（R1）であることを、約 1 秒ずつ順に表示します。判断の途中経過が画面に残るため、なぜ PC-C ではなく R1 を調べるのかを追いやすい構成です。

Sonnet 5.5 も同じ場面で、自分の LAN、宛先の位置、渡す先、調べる相手を 4 行の表で示し、調べる相手の行を強調しています。結論は正確ですが、宛先側のネットワークアドレスは示さず、「LAN の外（別セグメント）」という判断結果を一度に提示する形です。

フレームの中身をヘッダー単位で整理する

Opus 5.5 は右側のパネルに「いま流れているフレーム」として、Ethernet ヘッダー（宛先 MAC、送信元 MAC、タイプ）と、ARP の中身または IP ヘッダーを分けて表示します。タイプ欄には ARP の 0x0806 と IPv4 の 0x0800 を示し、ARP Request では「調べたい IP」の行を強調しています。

Sonnet 5.5 も、画面下部の中央パネルで Ethernet と ARP／IP を行で分け、送信元・宛先の MAC アドレスと IP アドレスを並べています。ARP の中身は「192.168.10.1 の MAC アドレスは」という問い合わせの形で表し、フィールド名よりも会話に近い表現を選んでいます。初学者向けの入口としては、この表現も理解の助けになります。

ルーターが ARP の完了を待つ流れを見せる

Opus 5.5 では、PC-A から R1 へ届いたデータが「R1 が受信（転送待ち）」として約 13 秒間 R1 の上に表示され、その間に R1 が LAN2 側で ARP を行い、完了後に同じデータが PC-C へ進みます。R1 が次の区間の MAC アドレスを得てから転送するという順序が、1 つのパケットの流れとして見えます。

Sonnet 5.5 では、PC-A から R1 へのデータ、R1 の ARP、R1 から PC-C へのデータがそれぞれ別の区間として表示され、受信したデータを保持している状態は描かれません。順序は字幕と ARP キャッシュのパネルで説明されています。

ルーターの要件を定めた RFC 1812 の 3.3.2 は、ARP の問い合わせと応答を行う間、少数のデータグラムを短時間キューに保持することを推奨（SHOULD）しています。義務（MUST）ではありませんが、Opus 5.5 の「転送待ち」の演出はこの推奨に沿った流れで、ARP の完了後に転送が進むという処理の順序を理解する助けになります。なお、約 13 秒はアニメーション上の説明時間であり、実機の標準的な ARP 解決時間や保持時間を示すものではありません。

字幕の量と再生操作

字幕の情報量は Opus 5.5 のほうが多く、HTML タグを除いた 1 区間の平均文字数は Sonnet 5.5 が約 38 文字、Opus 5.5 が約 66 文字です。Sonnet 5.5 の字幕は 1〜2 行に区切られ、基準画面に対する文字サイズも大きめに設定されています。1 画面で読む量を抑えたい場合は、Sonnet 5.5 の構成が向く場面もあります。

再生操作では、Opus 5.5 が進行バーのクリックで任意の位置へ移動できます。気になった場面へ戻って見直せる点は、教材として使う場合の実用上の違いです。Sonnet 5.5 は再生・一時停止・最初からの 3 操作で、途中の場面を見直すには最初から再生する必要があります。

一方、執筆環境の静止画では、Opus 5.5 で LAN2 の区間を移動するパケットのラベルが、PC-C のアイコンと名前に重なる瞬間がありました（約 70 秒前後と約 79〜82 秒）。技術的な誤りではありませんが、公開前に実際の画面で見え方を確認したい点です。

両モデルに残った技術的な表現の注意点

両成果物とも ARP の流れは正しく実装されていましたが、ルーター通過時の説明に、誤読を招く表現が 1 か所ずつ残っていました。いずれも同じ画面内の別の表示では正しい情報が示されており、表示同士の整合性や見出しの範囲の問題です。

Sonnet 5.5: 字幕と詳細パネルの不一致

R1 が PC-C へ転送する場面で、字幕は「IP の宛先はそのまま、宛先 MAC だけを PC-C に替えて転送します。」と説明しています。実際には、R1 は LAN2 側から新しいフレームを送るため、送信元 MAC アドレスも MAC-R1-LAN2 に変わります。

同じ場面の詳細パネルでは、宛先 MAC に MAC-C、送信元 MAC に MAC-R1-LAN2 が正しく設定され、注記の「IP アドレスは変わらず、MAC アドレスだけが区間ごとに付け替わる。」も正しい内容です。このため、ルーティングの理解が欠けているというより、字幕と詳細表示の整合性の問題と捉えるのが妥当です。ただし、詳細パネルで強調表示されるのは宛先 MAC と宛先 IP のセルだけのため、字幕と合わせて「宛先だけが変わる」と受け取られやすい状態です。

Opus 5.5: 見出しが示す範囲が広い

同じ場面の右パネルでは、IP ヘッダーの欄に「IP ヘッダー（そのまま）」という見出しが付いています。今回変わらないのは送信元・宛先 IP アドレスで、IP ヘッダー全体ではありません。RFC 1812 は、ルーターが転送時に TTL を 1 以上減らすことを求めています。

参考: RFC 1812 — Requirements for IP Version 4 Routers
“When a router forwards a packet, it MUST reduce the TTL by at least one.”
（ルーターがパケットを転送するときは、TTL を少なくとも 1 減らさなければならない）
https://www.rfc-editor.org/rfc/rfc1812.html

TTL が変わると、IPv4 ヘッダーのチェックサムも再計算されます（RFC 791）。同じパネルの注記には「TTL は 1 減ります」と正しい補足があり、字幕も「IP の送信元・宛先は変わりません」と範囲を限定しています。見出しを「IP ヘッダー（送信元・宛先 IP は同じ）」とすれば、注記との食い違いを解消できます。

両成果物に共通する簡略化

両成果物とも、ARP キャッシュは PC-A と R1 の必要な行だけを表示し、その旨を画面内に注記しています。RFC 826 の受信処理では、ARP Request の対象となった側も送信元の対応を登録するため、実機では場面 1 の PC-B や場面 2 の R1 にも PC-A のエントリが作られます。説明の焦点を絞るための妥当な簡略化ですが、Wireshark や実機の ARP テーブルと照らし合わせる教材では、この差を補足しておくと混乱を防げます。

公開前に人が確認したい観点

今回の 2 つの指摘を踏まえると、生成した技術教材では次の観点を人が確認することをおすすめします。

字幕と詳細表示の整合

同じ場面の字幕、パネル、強調表示が同じ事実を示しているかを確認します。字幕だけを読んでも誤解しないかが目安です。

見出しやラベルの範囲

「そのまま」「だけ」など範囲を示す語が、実際に変わらない項目や変わる項目に限定されているかを確認します。

簡略化の明示

省略した動作（相手側のキャッシュ登録、パケットの保持方法など）が、注記や本文から読み取れるかを確認します。

実際の画面での見え方

実際のブラウザーで再生し、文字の重なりや、読み切れない字幕の速さがないかを確認します。

今回の用途での評価と一般化できない範囲

最後に、技術教材の作成という今回の用途での評価と、この比較から言えない範囲を整理します。

技術教材の作成で見た今回の評価

今回の用途では、Opus 5.5 の成果物のほうが、判断の途中経過、ヘッダー単位の情報、ルーターでの保持を順に示しており、初学者が「なぜその MAC アドレスを調べるのか」を追いやすい構成でした。作成時間も今回は Opus 5.5 のほうが短く、筆者の感想と実装の違いは一致しています。

一方、Sonnet 5.5 の成果物も、ARP の流れと各フレームのアドレスは正しく実装していました。短い字幕で要点を示す構成は、概要を短時間で伝える用途に向いています。機能や情報量の多さだけで優劣は決められず、読者が 90 秒の中で流れを追えるかという観点で選ぶことをおすすめします。

どちらのモデルを使う場合も、今回のように 1 か所の表現が誤読につながる可能性は残ります。生成した教材は、ネットワークの知識を持つ人が字幕・見出し・詳細表示を突き合わせてから公開する運用が現実的です。

今回の比較で一般化できない範囲

本記事の結果は、次の条件による単発の事例です。

• 比較対象は、同じプロンプトから得た各モデルの初回成果物 1 本ずつです。
• 利用環境、effort などの推論設定、作成時間の計測の開始・終了点、途中操作の有無は確認できていません。
• 作成時間は筆者の確認値で、モデル固有の生成速度や平均的な性能を示すものではありません。
• トークン使用量と API 費用は測定しておらず、実測に基づく費用対効果は算出していません。
• 指摘した表現は初回成果物のもので、修正を依頼した場合の結果は比較していません。

同じ比較を自社の教材制作で試す場合は、利用環境と effort を固定し、作成時間の計測点を決めたうえで複数回実行すると、結果のばらつきを把握しやすくなります。

まとめ

同じプロンプトから作成した ARP の解説アニメーションでは、今回 Opus 5.5 が短い作成時間で、判断の過程やヘッダー情報を段階的に示す成果物を作成しました。ただし両モデルとも、ルーター通過時の表現に誤読を招く箇所が 1 つずつ残りました。生成した教材は、見た目や説明の丁寧さとは別に、技術レビューを経て公開することをおすすめします。

• Sonnet 5.5 と Opus 5.5 に同じプロンプトで ARP の解説アニメを作成させた。
• 筆者の確認では、作成時間は Sonnet 5.5 が 24 分、Opus 5.5 が 11 分だった。
• Opus 5.5 は判定の途中経過とヘッダー情報を段階的に表示した。
• Sonnet 5.5 は短い字幕と下部のパネルで要点を示す構成だった。
• Sonnet 5.5 の字幕は、送信元 MAC の付け替えを省いた表現だった。
• Opus 5.5 の IP ヘッダーの見出しは、変わらない範囲を広く示していた。
• 単発の比較のため、モデル全般の速度や性能には一般化できない。

以上、最後までお読みいただきありがとうございました。