AI Daily Digest

Claude Codeの使い方：計画と実行の分離術 Tier1

何が起きたか

Boris Tane氏のブログ記事「How I use Claude Code: Separation of planning and execution」がHacker Newsで859ポイントを獲得し、544件のコメントが付きました。核心はシンプルで、「計画を承認するまでClaude Codeにコードを書かせない」というワークフローです。

具体的には、リサーチ→計画文書の作成→人間によるレビュー・注釈→実装という流れを一つのセッション内で完結させます。計画文書はClaude Code組み込みのplan modeではなく、独自の.mdファイルとして管理します。理由は、エディタで自由に編集でき、コンテキストウィンドウの圧縮後も完全に残るからです。

要点

Tane氏のワークフローには3つの柱があります。

第一に、リサーチフェーズで「deeply」「in great details」「intricacies」といった強い副詞を使い、Claude Codeにファイルを精読させます。この段階で浅い理解のまま進むと、後の実装でアーキテクチャを無視した変更が発生します。

第二に、計画文書にインラインコメントを直接書き込みます。「ここはこのパターンではなく既存の○○と合わせる」といった判断を計画段階で注入することで、実装時の手戻りを防ぎます。

第三に、1セッションで最後まで通します。セッションを分割すると、それまでに蓄積されたコンテキストが失われます。コンテキストウィンドウが圧縮されても、計画文書という「永続的なアーティファクト」が残るため、実装精度が維持されます。

なぜ重要か

LLMがコードを書く精度は向上していますが、「見えない前提」を正しく扱えるかは別問題です。2月17日に取り上げたvibe codingのように、勢いでコードを書かせるアプローチとは対照的に、Tane氏の手法は「LLMが失敗する本当の原因はシンタックスではなく、アーキテクチャの暗黙の前提にある」という認識に基づいています。

HNのコメントでも「LLMに計画を書かせることで前提を表面化させ、デバッグ対象にできる」という指摘が支持を集めていました。AI支援開発のベストプラクティスが、個人の勘からワークフロー設計の問題に移行しつつあります。

議論の争点

所感

「計画を承認してから実装する」という原則自体は古くからあるソフトウェア開発の基本ですが、それをLLMとのやり取りに適用したときの効果は想像以上に大きいです。LLMの弱点を構造で補うという発想は、プロンプトエンジニアリングの次のフェーズと言ってよさそうです。

用語メモ

コンテキストウィンドウ圧縮

長いセッションでトークン上限に達した際、Claude Codeが自動的に過去のやり取りを要約して圧縮する機能。
この記事では、計画文書が圧縮後も残る点が重要とされています。

plan mode

Claude Codeに組み込まれた計画策定モード。コード変更前に設計意図を明示する機能。
この記事では、独自の.mdファイルとの使い分けが論点になっています。

RTX 3090一枚でLlama 70Bを動かす：NVMe→GPU直結の技術 Tier1

概要

NTransformerという推論エンジンが、24GB VRAMしか持たないRTX 3090一枚でLlama 3.1 70Bを動作させることに成功しました。核心技術は、NVMeストレージからCPUを経由せず直接GPUにモデル重みを転送するDMAパイプラインです。HNで363ポイント、93件のコメントを集めています。

先に押さえる3点

まず速度から。Llama 3.1 70B（Q4_K_M + レイヤースキップ）で約0.5トークン/秒、mmapベースラインの83倍です。対話用途には遅いですが、バッチ処理やバックグラウンドジョブなら実用範囲に入ります。

次にアーキテクチャ。3段階のキャッシュ階層を使います。Tier A（VRAM常駐）、Tier B（ピン留めRAM、PCIe DMAで非同期転送）、Tier C（NVMe/mmapフォールバック）。NVMe読み込み、PCIe転送、GPU計算をダブルバッファでオーバーラップさせる「SLEP streaming」が速度向上の鍵です。

最後にレイヤースキップ。コサイン類似度で冗長なレイヤーを特定し、80層のうち20層をスキップします。品質低下は最小限で、速度は倍以上になります。

影響

これまで70Bクラスのモデルをローカルで動かすには、複数GPUかA100のような高価格帯GPUが必要でした。NVMe→GPU直結という発想は、ストレージを「拡張VRAM」として扱うもので、消費者向けGPUでの大規模モデル実行に新しい道を開きます。

HNコメントでは「DRAM on M.2スロット」というさらに踏み込んだアイデアも出ていました。NVMeの代わりにDRAMモジュールをM.2に刺せば、永続性は不要なのでレイテンシが桁違いに改善する可能性があります。2月21日のTaalas専用チップのような専用ハードウェアとは異なり、既存のハードウェアで攻めるアプローチです。

議論の争点

実務メモ

試すにはLinux（kernel 6.17+）、CUDA 13.1、RTX 3090以上が必要です。NVMe直結モードにはVFIOカーネルモジュールのバインドが必要で、IOMMUの無効化も伴います。実験環境でなければ手を出しにくいですが、0.5トークン/秒のバッチ処理が許容できるなら検討の余地があります。

用語メモ

GPUDirect Storage

NVMeデバイスからGPUメモリへCPUを介さず直接データ転送する技術。
この記事では、NTransformerが類似の仕組みを独自実装しています。

レイヤースキップ

Transformerモデルの冗長なレイヤーを推論時に飛ばす最適化手法。コサイン類似度で隣接レイヤーの類似性を測定し、スキップ対象を決定します。

zclaw：ESP32で動く888KBのAIアシスタント Tier1

ざっくり言うと

zclaw（ゼットクロー）は、ESP32マイコン上で動くAIアシスタントです。ファームウェア全体で888KiB以下という厳しいサイズ制限の中、Telegram経由でのやり取り、GPIO制御、cronスケジュール、永続メモリまで詰め込んでいます。C言語で書かれていて、HNで257ポイント・137コメントの反響を得ました。

ポイントは3つ

1つ目は、サイズの意味です。888KiBにはzclaw本体だけでなく、ESP-IDF/FreeRTOSランタイム、Wi-Fi/ネットワーク、TLS/暗号、証明書バンドルが全て含まれています。実際のアプリコードは約25KBです。組み込みの世界でこの密度は目を引きます。

2つ目は、常時稼働の利点です。HNコメントで指摘されていたのは、ESP32の価値はコンピュート能力ではなく「電源を入れっぱなしにしても壊れない」という運用面です。Linuxボックスでオートメーションパイプラインを動かすと、OSアップデートやプロセス管理が運用負荷になります。ESP32なら電源さえあれば黙って動き続けます。

3つ目は、エッジAIの形です。zclaw自体にLLMは載っていません。インターネット経由でクラウドのLLMと通信するゲートウェイです。ただ、GPIOやcronを持っているので、「AIの判断を物理デバイスに直結させる」ブリッジとして機能します。

どこに効く？

ホームオートメーションや簡易的なIoT制御に使えます。「Telegramで指示を送ると、ESP32がセンサー値を読み取ってLLMに判断させ、リレーを動かす」といった構成が、1チップで完結します。昨日のKarpathy Clawsが描く「デバイスに常駐するエージェント層」の、最もミニマルな実装例と言えます。

派生プロジェクトとしてMimiClawも出てきており、ESP32-S3ボードにOpenClawライクな機能を載せる試みが広がっています。

議論の争点

一言

OLEDディスプレイ付きのESP32で「AIタマゴッチ」を作ろうという提案がコメントに出ていて、それはそれで面白そうです。888KBに全部詰め込むという制約が、逆にクリエイティビティを刺激している感じがあります。

用語メモ

ESP32

Espressif Systems製の低消費電力マイコン。Wi-Fi/Bluetooth内蔵で、IoTや組み込みAI端末の定番プラットフォーム。
この記事では、AIアシスタントの常時稼働端末として使われています。

GPIO

General Purpose Input/Outputの略。マイコンの汎用入出力ピンで、センサーやリレーなど外部デバイスの制御に使用。
この記事では、LLMの判断結果を物理デバイスに伝える接点として機能しています。

40MBバイナリにバックドアを隠してAIに探させた結果 Tier1.5

まず結論

Quesma社がBinaryAuditというベンチマークを公開しました。実際のオープンソースサーバ（Caddy、dnsmasq、sozuなど）のバイナリにバックドアを手動で埋め込み、AIエージェントにGhidraやRadare2を使って発見させる実験です。最高スコアはClaude Opus 4.6の49%。実用にはまだ遠いですが、出発点としては興味深い結果です。

変わった点

従来の静的解析ツールは既知のパターンマッチングが中心でしたが、BinaryAuditはソースコード一切なしの純粋なバイナリ解析です。バックドアの種類も、隠しHTTPヘッダ経由のRCEや特定日付以降に発動するタイムボムなど多岐にわたります。

検出率はClaude Opus 4.6が49%、Gemini 3 Proが44%、Claude Opus 4.5が37%です。ただし偽陽性率にも差があり、GPT系は検出率18%ながら偽陽性0%、Claude Opus 4.6は検出率49%で偽陽性22%です。「見つけたが自分で否定する」パターンがOpus 4.6で観察されており、モデルが正解に近づいても最終判断で引き返す現象が報告されています。

注意点

バックドアは未難読化の状態で埋め込まれています。実際の攻撃者はシンボル隠蔽や文字列難読化を施すため、「難読化が入った瞬間に検出率はゼロに近づく」というコメントが付いていました。この指摘は正しいですが、ベンチマーク側も「まず非難読化で基準線を作る」という意図で設計されています。

ツールの問題も深刻です。Go製バイナリ（Caddy、50MB）ではRadare2のロードに6分、Ghidraは40分かかり、まともなデコンパイル結果が得られませんでした。IDA Proだけが5分で実用的な出力を返しました。ツール品質がAIの性能を制約している面があります。

議論の争点

使うならこうする

2月21日に取り上げたClaude Code Securityがソースコードレベルの脆弱性検出なら、BinaryAuditはコンパイル後のバイナリ検証です。サプライチェーン攻撃への防御として、両方のレイヤーを併用する形が見えてきます。ベンチマークはオープンソースで公開されているので、自組織のパイプラインに組み込んで試すことも可能です。

用語メモ

Ghidra

NSAが開発したオープンソースのリバースエンジニアリングツール。バイナリの逆アセンブル・デコンパイルに使用。
この記事では、AIエージェントのバイナリ解析ツールとして利用されています。

サプライチェーン攻撃

ソフトウェアの依存関係やビルドプロセスを狙う攻撃手法。配布されるバイナリにバックドアを仕込む手法が典型。
この記事では、BinaryAuditがその防御手段として位置づけられています。

Lobsters「AI生成」フラグ提案が映すコミュニティの分岐点 Tier1.5

何が起きたか

技術コミュニティサイトLobstersで、投稿に対する新しいフラグ理由として「AI生成（AI generated）」を追加する提案が出されました。ユーザーdanderson氏による提案で、291ポイント・109コメントの活発な議論が展開されています。

提案の定義は明確で、「人間の頭で考えたアイデアを伝えるために書かれたものではなく、LLMがプロンプトを膨らませて生成した成果物」です。主観性があることは認めた上で、WikipediaのAI文章の兆候を判定基準の参考として挙げています。

要点

賛成派の主な論点は、AI生成コンテンツの増加が「集団的注意力に対するDoS攻撃」になっているという認識です。あるコメントは「HNの投稿の20%以上がAI生成で、それが理由でLobstersに来た」と述べています。文章を書くコストがほぼゼロになったことで、意見記事の無限生成が可能になった現状への危機感があります。

反対派は「既存のspamフラグやoff-topicフラグで十分」という立場です。オンラインではなく内容の質で判断すべきだという原則論に加え、AIについて書かれた記事とAIが書いた記事を混同するリスクも指摘されました。

第三の立場として、「vibecodingタグの見直しが先」という意見もあります。LLM関連コンテンツを望む人も望まない人も現状のタグ体系に不満を持っています。

なぜ重要か

この議論は単にLobstersの運営問題にとどまらず、昨日のAI uBlockブラックリストと同じ「AI生成コンテンツをどう扱うか」という問いの別の表出です。検索結果のフィルタリングとコミュニティの品質維持は、アプローチは違えど根本的に同じ課題を扱っています。

技術コミュニティが自主的にガバナンスを議論している点は健全です。ただ、AI生成かどうかの判定精度が上がらない限り、運用コストが高くなりすぎる可能性もあります。

所感

「コンテンツの質」と「生成手段」を分けて考えるべきという反対派の論理は筋が通っていますが、現実にはAI生成コンテンツの平均的な質が問題視されているわけで、そこを無視した原則論は空転しがちです。実装するなら、フラグの閾値設計が成否を分けそうです。

用語メモ

Lobsters

招待制の技術コミュニティサイト。HNと似た構造だが、より小規模でキュレーション重視。タグベースの分類が特徴。
この記事では、AI生成コンテンツの扱いを巡る自治の議論の場として登場しています。

ロボット掃除機7,000台を誤って掌握した男 Tier2

概要

ソフトウェアエンジニアのSammy Azdoufal氏が、自分のDJI Romoロボット掃除機をゲームコントローラーで操作するアプリを作ろうとしたところ、クラウドの認証バグにより約7,000台のカメラ・マイク・地図データにアクセスできてしまった、という話です。HNで162ポイント、106コメント。

先に押さえる3点

第一に、脆弱性の内容です。自分のデバイスの認証情報で他人のデバイスにもアクセスできてしまう、クラウド側の認可制御の欠陥です。24カ国、7,000台分のライブカメラ映像、マイク音声、室内マップ、ステータスデータが丸見えでした。

第二に、発見の経緯です。Azdoufal氏はAIコーディングアシスタントを使ってDJIのクラウド通信プロトコルをリバースエンジニアリングしていた際に偶然発見しました。意図的なハッキングではなく、趣味のプロジェクトから見つかった形です。

第三に、前例です。2024年にもEcovacs Deebot X2が米国各地でハッキングされ、スピーカーから暴言が流れたり、ペットを追い回したりする事件がありました。IoT機器のセキュリティ問題は繰り返されています。

影響

DJIは「修正済み」と発表しましたが、HNコメントでは「全台同じパスワード」を承認した設計プロセスへの批判が集中しています。「技術的に無能な企業には罰金が必要」という声が多く見られました。

根本的な問題は、IoTデバイスのインターネット接続自体がユーザーにとって不利益な機能（anti-feature）であるという点です。コメントでは、オープンソースファームウェアのValetudoへの切り替えを推奨する声が目立ちました。

実務メモ

自宅にカメラ・マイク付きのIoTデバイスを導入する際は、ネットワーク分離（VLAN）とファームウェアの確認を検討してください。Valetudo対応機種なら、クラウド依存を断つ選択肢があります。

用語メモ

Valetudo

ロボット掃除機のクラウド依存を排除するオープンソースファームウェア。ローカルネットワーク内のみで動作し、プライバシーを確保。
この記事では、IoTセキュリティの代替策として紹介されています。

Anthropicのサイバーセキュリティ開放：防御側へのAI供給 Tier2

ざっくり言うと

AnthropicがClaude Code Securityを発表しました。ソフトウェアの脆弱性を検出し、修正パッチを提案する機能で、EnterpriseとTeamプラン向けの限定リサーチプレビューとして提供されます。オープンソースメンテナーには優先アクセスが用意されています。HNで136ポイント、61コメント。

ポイントは3つ

1つ目は、検出手法の違いです。従来の静的解析ツールが既知パターンのマッチングに依存するのに対し、Claude Code Securityは「コンポーネント間の相互作用を理解し、データフローを追跡して、複雑でコンテキスト依存の脆弱性を検出する」と説明されています。人間のセキュリティ研究者に近いアプローチです。

2つ目は、多段階検証です。検出結果は自動的に再検証され、偽陽性のフィルタリングと重大度の評価が行われます。最終判断は人間が行い、ダッシュボードでパッチを確認・適用するフローです。

3つ目は実績です。Claude Opus 4.6を使い、本番のオープンソースコードベースから「数十年間検出されなかった500件以上の脆弱性」を発見したと発表しています。責任ある開示のプロセスが進行中です。

どこに効く？

2月21日にも取り上げたこの発表の追加情報として、HNでの反応が参考になります。監査企業の創業者からは「大手LLM企業が直接競合製品を出してくる」という競争圧力の指摘がありました。OpenAIのAardvarkとの比較では、OpenSSF CVEベンチマークでClaude Code Opus 4.5の正答率は約71%と報告されています。

防御側にとっての意味は、セキュリティ監査のコストと速度が変わることです。全てのコードベースに人間の専門家を配置することは現実的ではなく、AIによるトリアージが最初のフィルターとして機能する世界が近づいています。

一言

セキュリティ分野は「攻撃側がAIを使う以上、防御側も使わなければ対等にならない」という論理が成立する数少ない領域です。ただ、偽陽性と「見つけたのに否定する」問題（本日の記事4で取り上げたBinaryAuditの課題）は、ここでも付きまといます。

用語メモ

OpenSSF CVEベンチマーク

Open Source Security Foundationが提供する脆弱性検出の評価基準。既知のCVE（共通脆弱性識別子）に対するツールの検出精度を測定。
この記事では、Claude Code Securityの性能評価に使われています。

NanoClaw：Apple ContainersからDockerへ移行した理由 Tier2

まず結論

AIエージェントフレームワークNanoClawが、macOSのApple ContainersからDockerへの移行を発表しました。開発者のGavriel Cohen氏による説明で、HNで75ポイント、55コメント。個人プロジェクトから「数千人がプロダクション利用している」段階に移行したことで、プラットフォーム選択の優先順位が変わったという判断です。

変わった点

NanoClawはセキュリティ重視のAIエージェントフレームワークで、コア部分は約500行のTypeScriptです。LLMにターミナルアクセスを与える際、コンテナでOSレベルの隔離を行う設計が特徴です。

Apple Containersは理論的にはmacOSネイティブの隔離環境を提供しますが、実際の開発者体験は「苦痛」という声が多く、Seatbeltも宙ぶらりんの状態です。Dockerへの移行は、クロスプラットフォーム互換性とエコシステムの成熟度を選んだ形です。

注意点

HNコメントでは「コンテナに入れたところで全ての安全上の問題から守られるわけではない」という冷静な指摘も出ています。コンテナエスケープの脆弱性は過去にも発見されており、AIエージェントが予期しないコマンドを実行するリスクはコンテナだけでは完全に排除できません。

別のアプローチとして、Docker内でUnixパーミッションによる多層防御を採用しているプロジェクトや、Apple Containersを捨ててFirecrackerやgVisorに移行する動きも報告されていました。

使うならこうする

AIエージェントにシェルアクセスを与える場合、最低限Docker隔離は必須です。NanoClawを使うなら、明示的にマウントしたディレクトリのみエージェントからアクセスできる設計になっています。本番環境ではさらにネットワーク制限やリソース制限（cgroups）を追加してください。2月17日のAnthropic Claude Codeアクション非表示問題のように、エージェントの動作可視性も重要です。

用語メモ

Apple Containers

macOS上の軽量コンテナ技術。Linux VMを内部で使用し、Appleのセキュリティモデルと統合。
この記事では、開発者体験の問題でDockerに置き換えられています。

NanoClaw

コンテナ隔離されたAIエージェントフレームワーク。約500行のTypeScriptで、Anthropic Agent SDKとSQLiteを使用。
この記事では、Apple ContainersからDockerへの移行が報じられています。

チャットボット最大の敵はページリロード Tier2

何が起きたか

zknill.ioのブログ記事が、AIチャットボットのUI設計における根本的な問題を指摘しています。ClaudeのWebUI上でストリーミング中にページをリロードすると、応答が消えてスケルトンUIに戻り、生成完了後にようやく全文が表示される――この挙動は多くのユーザーが経験しているものです。HNで83ポイント、25コメント。

要点

問題の核心は、SSE（Server-Sent Events）ベースのアーキテクチャとHTTPのステートレス性にあります。Claude UIはコンテキスト全体をPOSTし、サーバーがSSEでトークンをストリーミングします。ページリロードでSSE接続が切れると、生成中のトークンへのアクセス手段がなくなります。

よくある対策は、SSEイベントを逐一Redisなどに保存してリジューム用エンドポイントを用意する方法ですが、「全トークンをDBに書く」のはオーバーヘッドが大きいです。

著者の提案は、WebSocketとPub/Subチャネル（Ablyを使用）の組み合わせです。永続的なデータベースなし、つまりサーバー側のステートなしで、ページリロード後のセッション復旧とトークンストリームの再開を実現しています。

なぜ重要か

AIチャットUIは「長時間かけて応答を生成する」という、従来のWebアプリにはなかったパターンを持っています。1分以上かかる応答の途中でブラウザが落ちる、タブを切り替える、Wi-Fiが切れる――こうした日常的なシナリオに対する耐性が、ユーザー体験を大きく左右します。

HNコメントでは「SSE自体の問題ではなく、状態管理の問題」という反論もありました。SSEでもセッションIDとリジューム機能を正しく実装すれば同様の体験は実現できるという指摘です。

所感

Webの「リフレッシュで状態を捨てる」という設計思想は、エラーからの復旧を容易にする意味で正しかったのですが、AIチャットのような長時間セッションとは相性が悪い。この問題はフロントエンド設計の新しい定番課題になりそうです。

用語メモ

SSE（Server-Sent Events）

サーバーからクライアントへ一方向にイベントを送信するWeb API。LLMの応答ストリーミングに広く使用。
この記事では、ページリロード時のセッション喪失の原因として分析されています。

Amazon・Meta・Alphabet、AI投資で税負担が急減 Tier2

概要

Yahoo Financeの報道によると、AIデータセンター建設への巨額投資と、ワシントンの新税制が組み合わさり、ビッグテック各社の2025年度の税負担が大幅に減少しています。AI関連の設備投資（capex）が加速度的減価償却の対象となり、事実上の税額控除として機能しています。HNで32ポイント、24コメント。

先に押さえる3点

まず投資規模。Alphabet、Microsoft、Meta、Amazonの4社で2026年のAI関連capexは約7,000億ドル（約105兆円）に達する見通しです。Amazonだけで2,000億ドル、Alphabetは1,750〜1,850億ドルを予定しています。

次にフリーキャッシュフローへの影響。Alphabetのフリーキャッシュフローは2025年の733億ドルから2026年に82億ドルへ、約90%の激減が見込まれています。Amazonはマイナス170〜280億ドル、Metaも約90%減少。MicrosoftだけがCapex増加率が緩やかで、28%減にとどまります。

最後に税制面。トランプ政権の「One Big Beautiful Bill」に含まれる企業向け税制優遇と、AI投資に対する加速度的減価償却が、各社の実効税率を大幅に引き下げています。

影響

AI投資の規模が税制にまで影響を及ぼすフェーズに入った、という点が重要です。2月19日に取り上げたAI投資のROI問題と合わせて読むと、巨額投資→税控除→キャッシュフロー圧迫→それでも投資を止められない、というサイクルの構造が見えてきます。

HNコメントでは「大企業が税を免れ、スタートアップは公平に競争できない」という批判が出ていました。AI投資による税控除が結果的に大企業の優位性をさらに固めるという構図です。

実務メモ

直接的にエンジニアの実務に影響するニュースではありませんが、AI関連のクラウドサービスの価格動向を左右する背景情報として頭に入れておく価値はあります。7,000億ドル規模のインフラ投資は、GPU供給やクラウド料金に間接的に波及します。

用語メモ

capex（設備投資）

Capital Expenditureの略。データセンター建設やGPU購入など、固定資産への支出。
この記事では、AI関連capexが税控除と連動して各社の財務に影響しています。