2026/05/11 8:02

クラウドは、ユーザー空間 IP スタックを動作させるエージェントとしてどのように振る舞い、Ping パケットへの応答速度はどの程度になるのでしょうか？

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

Adam Dunkels は、Large Language Model（LLM）、具体的には Haiku 4.5 を実行する Claude Code が、標準的な計算ツールなしに ping リクエストに応答することで userspace IP スタックとして機能できるかを確認するために実験を行った。この構成では、LLM が

ping-respond.md

コマンドを介して実行され、

/dev/tun0

から生パケットヘッダーを読み取り、手動で IPv4 および ICMP ヘッダーを解析し、送信元/宛先 IP を入れ替え、TTL を 64 に設定し、ビッグエンディアン形式でチェックサムを再計算する。これはすべてテキスト生成を通じて（Python や外部の計算機を使用せずに）行われた。システムは正しい論理を持つ有効な応答を生成することに成功し、

172.16.0.1

と

172.16.0.2

の間の ping について約 42.6 秒の往復遅延（RTT）が確認された。しかしながら、この膨大な遅延は、従来のハードウェアスタックと比較して標準的な接続性には実用的ではないことを示している。このコンセプト検証は、LLM が優れた適応力を備え、複雑なネットワーク論理を実行できることを確認するものの、低遅延インフラストラクチャのために専用のハードウェアが不可欠であることを示しており、将来の最適化または速度を二次的要素とするニッチなアプリケーションにおいて、さらなる研究の可能性を残している。

本文

Claude コードにユーザースペース IP スタックとして振る舞ってもらうための楽しいアイデアをご紹介します：

コンセプト： Claude に IP パケットをバイト単位で読み込み、通常の IP スタックのように処理させることで、「ping」を送ることができ、適切に整形された ping 応答を受け取ることができます。
判定： ゾンボウ？はい。トークンを無駄にする？もちろん。面白い？それにも及ばないよ！

私は Claude にネイティブの LLM ベース IP スタックとして機能するコマンド（

ping-respond.md

）を開発してもらいました。それが生成した内容が以下の通りです：

# Ping Respond — tun0 デバイスからの 1 つの ICMP エコー要求を処理します

あなたはユーザースペース IP スタックとして振る舞ってください。TUN ヘルパーはすでに FIFO モードで実行中（`sudo python3 scripts/tun_helper.py --fifo`）です。あなたの役割：1 つのパケットを読み込み、解析し、正当な ICMP エコー応答を構築し、書き戻すことです。すべての IP ロジックは推論内で処理されます。ライブラリもスクリプトも使用しません。

## ステップ 1: パケットの読み込み

TUN デバイスから 1 つのパケットを読み取るために、この bash コマンドを実行してください：

```bash
echo "READ" > /tmp/tun_cmd && timeout 35 cat /tmp/tun_resp

返却されるのはヘックス文字列（または「TIMEOUT」）です。TIMEOUT の場合、その旨を報告して停止し、ヘックス文字列を保存してください。これが生の IPv4 パケットです。

ステップ 2: IPv4 ヘッダーの解析

パケットはヘックスバイトの一連です（2 つのヘックス文字＝1 バイト）。以下のフィールドを解析します：

オフセット (バイト)	長さ	フィールド
0	1	バージョン (上位ニブル) ＋ IHL（低位ニブル、32 ビット単語単位）
1	1	DSCP/ECN
2–3	2	トータルレンジャ
4–5	2	アイデンティティ
6–7	2	フラグ (3 ビット) ＋フラグメントオフセット (13 ビット)
8	1	TTL
9	1	プロトコル（0x01 = ICMP でなければなりません）
10–11	2	ヘッダーチェックサム
12–15	4	ソース IP
16–19	4	宛先 IP

IHL はヘッダー長を示します：IHL × 4 バイト。標準では IHL=5（＝20 バイト）です。プロトコルが 0x01 でない場合は、「ICMP ではない、無視」と報告して停止します。

ステップ 3: ICMP ヘッダーの解析

ICMP ヘッダーは IP ヘッダーから直後に開始されます（バイトオフセット IHL×4）：

オフセット (ICMP 開始からの位置)	長さ	フィールド
0	1	タイプ（0x08 = エコー要求でなければなりません）
1	1	コード（0x00 でなければなりません）
2–3	2	ICMP チェックサム
4–5	2	アイデンティティー
6–7	2	シーケンス番号
8+	可変	パayload（変更せずコピー）

タイプが 0x08 でない場合は、「エコー要求ではない、無視」と報告して停止します。

ステップ 4: エコー応答の構築

特定の変数を変更することで応答パケットを構築します。ヘックス文字全体で作業してください。

4a: 応答用の IP ヘッダー

元の IP ヘッダーバイトを使用し、以下の項目を変更します：

バイト 8 (TTL)：
```
40
```
（十進数値 64）に設定
バイト 10–11 (ヘッダーチェックサム)： 一時的に
```
0000
```
に設定
バイト 12–15 (ソース IP)： 元の宛先IP を設定
バイト 16–19 (宛先 IP)： 元のソースIP を設定

次に、IP ヘッダーチェックサムを計算します：

チェックサムフィールド＝0000 の IP ヘッダー（IHL×4 バイト）を取得
16 ビット単語（2 バイトずつ）に分割
すべての単語を符号なし整数として加算
合計が 0xFFFF を超える場合：下位 16 ビット（sum & 0xFFFF）へキャリーを加算する（sum >> 16 を足す）まで繰り返す
反転 complement を取得：result = 0xFFFF - folded_sum
この値をバイト 10–11 に記述（ビッグエンディアン）

4b: 応答用の ICMPペイロード

ICMP メッセージの元のデータ（ICMP スタートからパケット終了まで）を使用し、以下の項目を変更します：

バイト 0 (タイプ)：
```
00
```
（エコー応答）に設定
バイト 1 (コード)：
```
00
```
を維持
バイト 2–3 (ICMP チェックサム)： 一時的に
```
0000
```
に設定
バイト 4+ (アイデンティティ、シーケンス、ペイロード)： 変更せず保持

次に、IP チェックサムと同じアルゴリズムで ICMP チェックサムを計算します：

チェックサムフィールド＝0000 のすべての ICMP メッセージ（タイプからペイロード終了まで）を取得
16 ビット単語に分割。バイト数が奇数の場合、チェックサムの計算のみで末尾にゼロバイトをパディングします。
すべての単語を符号なし整数として加算
キャリーを折りたたむ：合計が 0xFFFF を超える場合は、合計＝(sum >> 16) ＋ (sum & 0xFFFF) とするまで繰り返す
反転 complement を取得：result = 0xFFFF - folded_sum
結果が 0x0000 の場合、代わりに 0xFFFF を使用する
ICMP バイト 2–3 に記述（ビッグエンディアン）

4c: 応答パケットの組み立て

結合：IP ヘッダー（正しいチェックサム付き）＋ICMP メッセージ（正しいチェックサム付き）

ステップ 5: 応答を書き込み

組み立てたヘックス文字列を使用した以下の bash コマンドを実行してください：

echo "WRITE <your_hex_here>" > /tmp/tun_cmd && timeout 5 cat /tmp/tun_resp

「OK」を返されるはずです。

ステップ 6: レポート

要約を出力します：

ソース IP → 宛先 IP
ICMP エコー要求シーケンス番号
パケットサイズ（要求と応答）
「Reply sent successfully」またはエラーメッセージ

重要なルール

すべての計算はご自身で行ってください。Python、bc、またはいかなる電卓ツールも使用しないでください。
チェックサムの計算において、デバッグできるよう作業過程を示してください。
生成するすべてのヘックス値は適切な桁数を持たなければなりません（ゼロパディングを実行）。
いかなる異常も検出された場合（不適切なバージョン、予期せぬプロトコルなど）、不健全なパケットを送信する代わりに報告して停止してください。


このコマンドは `/dev/tun0` デバイスからバイトを読み取り、薄手の Python ヘルパーを使用して stty オプションを適切に設定し、IP チェックサムを計算します。ICMP エコーメッセージを検出した場合、ICMP エコー応答メッセージで応答し、すべてのチェックサムは正確に計算されます。

これを実行すると、Claude は以下の出力を生成します：

```text
受信されたパケット：45000054812840004001615dac100001ac100002080054f5000d0001a1fb006a0000000041c4000000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637

IP ヘッダーを解析中（最初の 40 ヘックス文字＝20 バイト）：
- 45 → バージョン=4、IHL=5（20 バイト）
- 0054 → トータル長さ = 84
- TTL=40（64）、プロトコル=01（ICMP）
- ソース：ac100001 = 172.16.0.1
- 宛先：ac100002 = 172.16.0.2

ICMP: タイプ=08（エコー要求）、コード=00、ID=000d、シーケンス番号=0001

次に応答を構築します。IP ヘッダー：ソース/宛先を交換、TTL=64、チェックサムを再計算。ICMP: タイプ=00（エコー応答）、チェックサムを再計算。

IP ヘッダーチェックサム — チェックサムゼロ化されソース/宛先が交換されたヘッダー：
4500 0054 8128 4000 4001 0000 ac10 0002 ac10 0001

合計：4500+0054+8128+4000+4001+0000+ac10+0002+ac10+0001 = 0x29F20
折りたたみ：0x9F20+0x2 = 0x9F22
補足：0xFFFF-0x9F22 = 0x60DD

ICMP チェックサム — タイプを 08→00 に変更、チェックサムゼロ化：
元のチェックサム 54F5 は折りたたみ合計 0xAB0A と対応していました。タイプ 08→00 を変更すると合計は 0x0800 減ります：0xAB0A-0x0800 = 0xA30A。
補足：0xFFFF-0xA30A = 0x5CF5

応答パケット：4500005481284000400160ddac100002ac10000100005cf5000d0001a1fb006a0000000041c4000000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637

そして結果を得ました！

$ ping -W 300 -c 1 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=42593 ms

--- 172.16.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 42592.723/42592.723/42592.723/0.000 ms

このテストは Haiku 4.5 で実行され、比較的高速なモデルです。ただし、往復時間（round-trip time）が 45 秒もかかっているため、遅い ping です。他のいくつかのモデルほど遅くはありませんが。

著者： Adam Dunkels, PhD — ハードウェアとソフトウェアの境界領域で複雑な製品を開発する企業を支援しています：サービス

同じ日のほかのニュース

一覧に戻る →

2026/05/11 2:19

ローカル AI が標準となる必要があります。

## Japanese Translation: 開発者は、安定的なアプリケーションと厳格なプライバシーを確保するため、脆弱であるクラウドホスト型モデルよりも、Apple 製の組み込みローカル AI ツール（`SystemLanguageModel` および `LanguageModelSession` など）を優先すべきです。外部サーバーへの依存は、課金問題やサービス停止時にサービスがクラッシュするという致命的な障害点を生じさせると同時に、機密ユーザーデータを保持リスクおよび潜在的な侵害に晒すことになります。対照的に、データ処理を安全にデバイス上で実行することにより、不必要なサーバー経由の迂回とベンダー依存を排除し、アプリケーションを強固なものに保てます。「Brutalist Report」という iOS クライアントは、典型的なクラウドソリューションに見られる複雑なアカウント要件を回避するため、ネイティブ API を使用して完全にローカルで記事のサマリーを生成する優れた例です。長いコンテンツの場合には、テキストをチャンク化（約 10k 文字）し、各チャンクごとに事実のみを含むノートを作成した後、それらをローカルで統合して最終的なサマリーを生成する推奨ワークフローがあります。このワークフローの将来形としては、`@Generable` および `@Guide` といった Swift の構造体を使用し、構造化された AI 出力を強制して非構造化データのようなデータをそのまま受け取るのではなく、UI が一貫したフィールドを確実にレンダリングできるようにする方向性が考えられます。この変化により、ユーザーは情報がデバイスから離れることがないと信頼できるようになります。企業にとって、ローカルモデルの導入は、AI をコストが高く予測不能な外部依存体から、サマリー化や分類を効率的に行い、ユーザー所有データを扱いながらレート制限や停止時間への心配なしに運用可能な信頼性の高い低コストサブシステムへと変革させます。開発者は、クラウドモデルを真に必要な場合のみ使用し、ローカル AI をノベルティなチャットボックスではなく、予測可能で信頼できる動作を持つ subsystem として扱うべきです。

2026/05/11 10:23

手書きコーディングに戻ろうとしています。

## Japanese Translation: k10s（NVIDIA クラスター運用者向けの GPU 意識型 Kubernetes ダッシュボード）の構築から得られた主な教訓は、AI は機能の迅速な提供に優れている一方で、システムアーキテクチャにおいては頻繁に失敗し、倒壊しやすいコードベースを導き込む点にある。Go と Bubble Tea フレームワークを用いた「vibe-coded」アプローチで 30 週間週末にわたり開発を進めたチームは、7 ヶ月間で 234 コミットを実現したにもかかわらず、深刻な構造的欠陥が蓄積しており、最終的にこの作業の約 70% が破棄された。これには `model.go` に収められたコード行を約 1,690 行も含まれている。プロジェクトは以下の 5 つの批判的アーキテクチャ上の失敗に直面した：AI がシステム不変則を無視し（結果として散在する `nil` 代入が発生）、キーハンドリングが地獄のように困難になる「神オブジェクト」と単一構造体設計に依存した、GPU に焦点を当てた範囲を超えた機能の蔓延を引き起こす「速度の幻想」におびやかされた、構造化データを不安全な位置指定式配列へと平坦化したこと、そして goroutine から直接の状態変異を許容しチャンネルを用いなかったことを通じて状態遷移を誤って扱った。将来の失敗を防ぐため、このプロジェクトはシステムを Rust で再実装中である。この移行により厳密な所有ルールが強制され、コーディング前にアーキテクチャ（インタフェース、メッセージ型など）を明示的に設計することが求められ、AI の支援が長期的な構造的完全性を損なうのではなく支えるように確保される。 ## Text to translate: **Improved Summary:** The primary lesson from building k10s—a GPU-aware Kubernetes dashboard for NVIDIA cluster operators—is that while AI excels at rapid feature delivery, it frequently fails at system architecture, leading to a codebase prone to collapse. Using a "vibe-coded" approach with Go and the Bubble Tea framework over 30 weekends, the team accumulated deep structural flaws despite making 234 commits in seven months; ultimately, ~70% of this work was discarded, including approximately 1,690 lines of code in `model.go`. The project faced five critical architectural failures: AI ignored system invariants (leading to scattered `nil` assignments), defaulted to a "god object" single-struct design making key handling a nightmare, succumbed to the "velocity illusion" causing feature creep beyond the GPU focus, flattened structured data into unsafe positional arrays, and mishandled state transitions by allowing direct mutations from goroutines instead of using channels. To prevent future failure, the project is rewriting the system in Rust. This transition enforces strict ownership rules and requires designing architecture (interfaces, message types) explicitly before coding, ensuring AI assistance supports rather than undermines long-term structural integrity.

2026/05/11 2:43

インシデントレポート：CVE-2024-YIKES

## Japanese Translation: ソースコードのサプライチェーン攻撃は、`left-justify`（週ごとのダウンロード数が 8.47 億回）という侵害された JavaScript の依存関係に起因し、その結果、Python ツールの `snekpack` を介して数百万人の開発者に影響を及ぼしました。`snekpack` は、悪意のあるライブラリ `vulpine-lz4` を統合した後にマルウェアを配布しました。このインシデントは Day 1 に発生し、Google AI Overviews で提示されたフィッシングリンクに引っかかり、 maintainer の Marcus Chen が被害にあうことで始まり、複数パッケージレジストリ（`.npmrc`、`.pypirc`、Cargo、Gem の認証情報）の認証情報が漏洩し、引渡条約のない国にあるサーバーに到達しました。当初、「Critical」から「Catastrophic」と評価が変更されたものの、Day 3 に関連性の/crypto マining ウォーム (`cryptobro-9000`) が誤って脆弱なマシンを `snekpack` のアップグレードによってパッチ適用したため、「Somehow Fine」と宣言されました。攻撃チェーンには以下が含まれていました： - 悪意のある `vulpine-lz4` ビルドスクリプトは、ホスト名がトリガー（例："build"、"ci"）に一致する場合マルウェアを実行しました。 - 不正なアップデートでは、reverse shells が Tue デイのみ有効になるように、そしてデフォルトシェルを `fish` に変更するなどの機能を追加されました。 - 企業大手（Fortune 500 社）はソーシャルメディアを通じて認識し、ある VP はマウイ島でこの事実に気づきました。インシデントは Day 3 の 15:22 UTC に解決され、CVE-2024-YIKES は Week 6 に割り当てられ、ウォームによって約 420 万台の_MACHINE_ が救助された（ただしその C2 サーバーも侵害されていた）と推定されます。根本原因には、弱いレジストリ認証、AI 生成のフィッシングリンク、不十分な CI/CD の衛生管理があり、ユーモラスに「犬が Kubernetes を食べ、YubiKey が失われた」という形で表現されました。是正措置には、`vulpine-lz4` のリファクタリング（Rust に書き直し）、アーティファクト署名の実装（2022 年第 3 四半期からバックログされていた）、強制的な MFA の導入、847 の推移的依存関係の監査が含まれます。このインシデントは、自動化されたビルドパイプラインにおける重要なギャップと、将来の攻撃を防止するための厳格な依存関係監査の必要性を示しています。