Raspberry Pi 5 で Qwen3.6-35B-A3B を 3.5 tok/s オフライン駆動する車載エージェント CarWatch、単一ファイルでグラフ・ベクトル・BM25 を統合する LatticeDB、プロンプト構造化で脆弱性は再分配される実証ほか7件

今日の3行

• Raspberry Pi 5（16GB、約300 €）で Qwen3.6-35B-A3B（Unsloth UD-Q3_K_S 14.3GB）を 3.5 tok/s 生成 / 25+ tok/s プロンプト処理で完全オフライン駆動する車載エージェント CarWatch が公開されました。745ページの車両マニュアルを lexical RAG でページ引用付きで回答し、OBD・クラウド連携・whisper.cpp による音声を統合し、Python 標準ライブラリのみで SD カード完結で再現できます。
• 単一ファイルの埋め込み型グラフDB LatticeDB が公開されました。グラフ走査・HNSW ベクトル検索・BM25 全文検索を同一クエリで扱い、0.13 μs のノード参照と 1M ベクトルで 0.83 ms / 100% recall を記録します。サーバ不要で 1 ファイルに集約できるため、Graph RAG やエージェントメモリのローカル基盤として今日から検証できます。
• 424 のセキュリティセンシティブな Python タスクで GPT-4o と LLaMA 3.1-8B を 5種のプロンプトで生成し Bandit と CodeQL で評価した結果、構造化・セキュリティ指示を強めても脆弱性は消えず分布が移動するだけだと示されました。プロンプトで安全を足しても万能ではないため、生成後のレビュー工程と CWE 別の対策を設計する必要があります。

深掘り: Raspberry Pi 5 で Qwen3.6-35B-A3B を 3.5 tok/s で完全オフライン駆動する車載エージェント CarWatch

要点 Raspberry Pi 5（16 GB、~300 €）上で Qwen3.6-35B-A3B（Unsloth UD-Q3_K_S dynamic quant、14.3 GB）を完全オフラインで駆動する車載エージェント CarWatch が公開されました。実機計測で 3.5 tok/s generation / 25+ tok/s prompt、持続 65 °C、no cloud / no internet / no subscription で動作します。車を GroupMind のチャットルームのエージェント @gle（名称は変更可能）として参加させ、departures / arrivals / trip summaries や、車体への衝突時に dashcam クリップを投稿し、CodeWatch 経由でスマートフォンや watch から承認・返信できます。Open PRs は CodeWatch dashboard 上で ClawWatch や WhereWatch と並んで確認できます。車両の 745 ページの owner’s manual を lexical RAG として SD カードに同梱し、ページ引用付きで回答し、manual に書かれていないことは回答を拒否します。「when should I add oil and what kind of oil?」のような車両固有の質問に完全オフラインで答え、online 時は agent family のより強力なモデル群と連携します。OBD コネクタで車両内部の状態を読み取り、manufacturer’s cloud service（エアコン変更やドアの開閉など）へのコネクタを備えます。hands-free voice は energy VAD → whisper.cpp による continuous listener を on-Pi で動作させ、no wake word / no cloud STT で発話を拾い、同じ grounded pipeline で回答を room に返します。コードは Python 標準ライブラリのみで構成され、no pip install / no venv で git clone だけで動作し、AST scan で検証済みです。systemd services が model server / room agent / voice listener / phone dashboard / engine watcher を boot 時に自律起動し、hourly の git pull と dashboard の “update now” ボタンで車両側が自ら更新を取得し、phone hotspot の NAT 越しでも到達可能な dial-out tunnel を備えるため、laptop を車内に持ち込む保守は不要です。

なぜ重要か クラウド不要で 35B モデルが車内で自律動作する構成は、エッジ SaaS やローカル推論プロダクトのコスト・プライバシー設計を変えます。推論が Pi 5 という ~300 € の手元ハードウェアで完結し、subscription や外部送信に依存しないため、月額課金の積み上がりやデータの外部預託を避けられます。原典の Why CarWatch では、Your data stays in your car（モデルは Pi 上で offline 動作し、必要な場合以外は外部に送信しない）、Any brand（車両データ層は vendor-neutral な carwatch/cloudcar.py で、Mercedes は最初の adapter に過ぎず、Tesla / BMW / VW は 3 つのメソッドを実装すれば差し替え可能）、Works with no signal（garage / tunnel / 圏外でも有用な部分は network に依存しない）、No subscription / no lock-in（AGPL、所有するハードウェアで動作）の 4 点が、manufacturer が構造的に取れない立ち位置として明示されています。加えて、Python 標準ライブラリのみ・SD カード完結・AST 検証済みという再現性は、個人開発者が今日から手元で試せることを意味します。745 ページ manual の lexical RAG がページ引用と拒否挙動を伴う点、grounded self-knowledge が live センシングに基づく点は、車両という誤答が許されない対象に対する信頼性の設計として直接参考になります。

仕組み 全体は「In the car - Raspberry Pi 5」内に閉じた構成と、GroupMind rooms / phone・watch（CodeWatch）との連携で説明されます。USB mic → carwatch-listen（VAD + whisper.cpp）→ llama.cpp server（Qwen3.6-35B-A3B）→ carwatch-agent（@gle room agent）→ GroupMind rooms → phone / watch という流れで、manual RAG（745 pages, on SD）と selfstate（temperature / throttling / fan / memory / disk / network / which model is loaded）が BRAIN に入力されます。carwatch-obd が OBD ケーブルを監視し、web dashboard は :8088 で status / update / voice / wifi を提供し、self-update が hourly git pull で更新を当て、dial-out tunnel が any NAT の背後から到達性を確保します。

grounded な回答のための仕組みが徹底されています。temperature / throttling / fan / memory / disk / network や loaded model は質問ごとに live で読み取り、感知できないことはできないと明言します。system prompt は unknown が fact として読まれないように構築されています。manual RAG は lexical 方式で SD カードに同梱し、ページ番号を引用し、manual にないことは拒否します。voice は continuous listener（energy VAD → whisper.cpp、all on-Pi）が発話を常時監視し、同じ grounded pipeline を経由して room に回答するため、wake word の儀式も cloud STT も不要です。

依存関係と運用は極限まで単純化されています。Every line of CarWatch is Python standard library で、no pip install / no venv / nothing to version-fight on a fresh Pi OS、git clone で動作します。systemd services が全体を boot 時に self-start し、車両側が hourly と dashboard ボタンで repo から自ら更新を pull し、dial-out tunnel（cloudflared quick tunnel で proven、open internet 越しに到達確認済み）で phone hotspot の背後でも reachable です。Three-tier connectivity として phone hotspot → home wifi → its own fallback access point を備え、phone が常に到達でき、電波のない garage でも dashboard（車両自身が serve する phone dashboard）に接続できます。

Local vs online の戦略は明確に分離されています。Always local（no signal でも動作）として、voice in / assistant’s answers（on-Pi model）/ owner’s-manual answers（RAG ships on the SD card）/ phone dashboard（served BY the car）/ trip / state tracking を担保します。Queued through connectivity gaps として、room posts / clip uploads / mention replies は永続的な on-disk outbox に先に保存し、欠損ではなく遅延配送します。Online-only かつ honest なものとして、remote reachability（dial-out tunnel）/ self-updates / escalation to bigger brains（まず local-LAN の model server、still no cloud、次に online かつ明示的に求められた場合のみ cloud model を車両自身の budget-capped key で利用）を位置づけます。glanceable な safety-relevant 情報は network に依存させず、social / heavy なものは gracefully に “later” へ degrad させるのが rule of thumb です。

status の honesty policy も明示されています。feature は real car で動作して初めて “proven” とし、“built + tested” は real または simulated counterpart に対して end-to-end で動作したが physical car にまだ触れていない状態と定義します。公開されている status は、@gle room agent（mentions / grounded answers / presence heartbeat）は proven（running daily）、owner’s-manual RAG with page citations は proven、phone dashboard served by the car（status / wifi / voice toggle / update button）は proven、hands-free voice（continuous VAD listener → whisper → grounded answer → room）は proven（real voice transcribed on-Pi）、self-update（hourly timer + dashboard button）は proven、dial-out reachability behind any NAT（cloudflared quick tunnel）は proven（reached over the open internet）、OBD engine reading over Bluetooth ELM327（RPM / coolant / speed / hybrid % / 12 V）は proven（live readings from the real car daily、zero-touch daemon が自動再接続して投稿、DoIP / ENET cable path は gateway が応答せず dead と docs/plan.md で documented dead end）、manufacturer-cloud read（Mercedes me via Home Assistant: lock / doors / windows / tires / charge / range / fuel / odometer、account 上の every car）は proven（live on the real cars、one Helsinki / one Berlin、read-only by construction）、make-safe cloud commands（lock doors / close windows の 2 つのみ、security PIN 不要）は proven（dashboard からの close-windows が real open window を実際に閉じたことが確認済み、unlock / open / engine は deliberately not implementable）、raw CAN broadcast capture + decode tooling（carwatch/candecode.py）は proven capture（2518 frames、0 errors、signal naming は correlation drive が必要な candidates only、honestly unlabeled）、dashcam clip pull（WOLFBOX G900、hisnet CGI API mapped）は probe done / pipeline not wired、MBUX dashboard render / mirror icon strip は planned です。build log は docs/plan.md に every dead end を含めて記録されています。

導入するなら

• ハードウェアは reference build として Raspberry Pi 5 16 GB（active cooling が必須で、冷却なしでは SoC が throttle します）と、voice 用の USB microphone（any）を用意します。コストは ~300 € で、model は 14.3 GB のため SD カードに収まる構成です。まずは git clone だけで動作する zero dependencies 性を活かし、fresh な Pi OS で AST scan 済みの Python 標準ライブラリのみ構成をそのまま起動できるか確認します。
• OBD は Bluetooth ELM327 経由で RPM / coolant / speed / hybrid % / 12 V を取得する carwatch-obd が proven です。DoIP / ENET ケーブル経路はこの車両では gateway が応答せず dead とされているため、最初から ELM327 での zero-touch daemon の自動再接続を前提に検証します。CAN の生キャプチャを試す場合は carwatch/candecode.py で 2518 frames / 0 errors の capture が proven ですが、signal 名は correlation drive が必要な candidates only で honestly unlabeled という前提で扱います。
• manual RAG は 745 ページの owner’s manual を lexical RAG で SD カードに同梱する方式です。自分の車両の manual を同形式で用意し、ページ引用付きで回答し、manual にないことは拒否する挙動を、そのまま再現できるかテストします。「when should I add oil and what kind of oil?」のような質問で、offline 時に正しく引用と拒否が機能するかを確認します。
• manufacturer’s cloud は Mercedes me via Home Assistant で lock / doors / windows / tires / charge / range / fuel / odometer の read が account 上の every car で proven（one Helsinki / one Berlin）ですが、read-only by construction です。書き込みは make-safe な lock doors / close windows の 2 つのみが PIN 不要で proven（dashboard からの close-windows で real window が閉じることを確認済み）で、unlock / open / engine は deliberately not implementable という安全境界を尊重して運用します。他ブランドは carwatch/cloudcar.py の vendor-neutral interface に 3 つのメソッドを実装する adapter 方式で、Mercedes 以外は自作 adapter が必要です。
• 運用は systemd の自律起動（model server / room agent / voice listener / phone dashboard / engine watcher）と、hourly git pull + dashboard “update now” ボタンによる self-update、cloudflared quick tunnel による dial-out 到達性を前提に設計します。Three-tier connectivity（phone hotspot → home wifi → fallback access point）により、garage の圏外でも phone から :8088 の dashboard に到達できることを確認します。voice は energy VAD → whisper.cpp の continuous listener（all on-Pi、no wake word / no cloud STT）が同じ grounded pipeline で room に回答する流れを、実車で hands-free で検証します。grounded self-knowledge（temperature / throttling / fan / memory / disk / network / loaded model を per question で live read）を活かし、感知できないことはできないと答える system prompt の挙動を意図的に確認します。

原典 Show HN: I made a Raspberry with Qwen my local car AI

2. LatticeDB — 単一ファイルでグラフ走査・HNSWベクトル検索・BM25全文検索を同一クエリで扱える埋め込み型グラフDB

要点 LatticeDBは、単一ファイルで動作する埋め込み型のproperty-graphデータベースです。ネイティブなベクトルインデックスと全文検索インデックスを備え、同一データセットに対してグラフ走査、HNSWによるベクトル類似度検索、BM25による全文検索を1つのエンジンと1つのクエリ言語で実行できます。関係性が重いワークロードを単一マシンで扱うために設計され、zero-configで動作し、embedded single-writerモデルを採用しています。データベース全体が単一のポータブルなファイルで、サーバや設定は不要です。永続化はWAL-backedで、1つの owning process が1台のマシンで所有するLocal-first設計です。性能として、0.13 μsのノード参照と、1Mベクトルで0.83 ms / 100% recallのベクトル検索を掲げています。1つのイベントログとして、 durableな名前付きストリームと組み込みのグラフchangefeedが、グラフ書き込みと同じtransaction/WALパスを共有します。同一クエリで3種の検索を組み合わせる例として、MATCH (chunk:Chunk)-[:PART_OF]->(doc:Document)-[:AUTHORED_BY]->(author:Person) WHERE chunk.embedding <=> $query_vector < 0.3 AND doc.content @@ "neural networks" RETURN doc.title, chunk.text, author.name ORDER BY chunk.embedding <=> $query_vector LIMIT 10 のように記述できます。インストールはCLIが curl -fsSL https://raw.githubusercontent.com/jeffhajewski/latticedb/main/dist/install.sh | bash、Pythonが pip install latticedb、TypeScript / Node.jsが npm install @hajewski/latticedb で、Goは bindings/go/README.md のcgoワークフローに従います。Published wheelsやPublished package tarballsは対応プラットフォームでliblatticeをbundleすることが想定され、ソースからのビルドでは LATTICE_BUNDLE_LIB_DIR=/path/to/lib を指定してbundleできます。Graph RAGやagent memory、ローカルナレッジツールは、エンジン自体の定義ではなく、このプリミティブ上に構築されるワークロードの例として位置づけられています。サンプルでは hash_embed / hashEmbed / HashEmbed という組み込みヘルパーが使われますが、これは外部サービスなしで動く deterministicなplaceholderであり、類似テキストが近いベクトルになるわけではないため、距離の閾値は任意であり、結果の意味を持たせるには実 embedding モデルを使う必要があります。

なぜ重要か Graph RAGやエージェントメモリに必要な、関係・意味・テキストの3種の検索をサーバ不要で1ファイルに集約できる点が重要です。グラフ走査・ベクトル検索・全文検索を同一クエリで扱えるため、個人開発の知識ベースやAgent memoryのローカル基盤として、今日から技術選定と検証を1つの埋め込みDBに寄せられます。

実践で使える点 ローカルのRAG基盤やエージェントメモリを試すなら、LatticeDBを単一ファイルの埋め込みDBとして検証できます。Pythonでは pip install latticedb で導入し、Database("knowledge.db", create=True, enable_vectors=True, vector_dimensions=128) のように開き、txn.create_node / txn.create_edge でグラフを構築し、txn.set_vector(chunk.id, "embedding", hash_embed(text, dimensions=128)) と txn.fts_index(chunk.id, text) でベクトルとテキストを投入したうえで、 MATCH ... WHERE chunk.embedding <=> $query < 0.5 と @@ を組み合わせたクエリや fts_search を試します。TypeScriptでは npm install @hajewski/latticedb、Goではリポジトリの bindings/go/README.md に従って導入し、サンプルの hash_embed は動作確認用のplaceholderとして扱い、本番の意味検索は実 embedding モデルに置き換えて評価します。

原典 Show HN: LatticeDB – Like SQLite but for graph databases

3. Prompt Structure Redistributes, Not Reduces — 構造化・セキュリティ指示は脆弱性を減らさず再分配する424タスクでの実証

要点 arXivに公開された論文「Prompt Structure Redistributes, Not Reduces: An Empirical Analysis of Security-Weaknesses in LLM-Generated Python Code」は、自然言語プロンプトからLLMがコードを生成する際に、プロンプトエンジニアリングが生成ソフトウェアの安全性を形作る重要な手段になると指摘したうえで、構造化・セキュリティ指向のプロンプトがより安全なコードを促すために広く用いられるものの、その効果は検出される弱点が単に存在するか否かを超えて広がると論じています。424のセキュリティセンシティブなPythonタスクを用い、GPT-4oとLLaMA 3.1-8Bで、構造的・セキュリティ的なガイダンスを段階的に追加した5種のプロンプトバリアントで解を生成し、BanditとCodeQLで2つの軸に沿って評価しています。

なぜ重要か LLMにコード生成を任せる個人開発者にとって、プロンプトに安全指示を足せば安全になるという前提が成り立たないことは、生成後のレビュー工程の設計に直結します。構造化やセキュリティ指示を強めても脆弱性が単純に消えるわけではないという実証を踏まえれば、プロンプト側の工夫だけに依存せず、生成後の静的解析と弱点の種類別の対策を組み合わせる運用に切り替える判断ができます。

原典 Prompt Structure Redistributes, Not Reduces: An Empirical Analysis of Security-Weaknesses in LLM-Generated Python Code

4. Aging of Prompt Engineering Techniques Across LLM Versions — 5手法の有効性がLLM世代間でどう移り変わるかを6モデルで再現評価

要点 arXivに公開された論文「Aging of Prompt Engineering Techniques Across LLM Versions」は、prompt engineering と prompt engineering techniques（PETs）が AI システムのソフトウェアエンジニアリングに不可欠な要素になっていると指摘したうえで、新しい LLM が頻繁にリリースされる中で各手法の有効性が世代間でどう変化するかは不明なままだと問題提起しています。Khojah et al.（2025）の部分的再現として、Zero-Shot、Few-Shot、Chain-of-Thought（CoT）、Contrastive Chain-of-Thought（CCoT）、Program-of-Thought（PoT）の adapted version という5手法を、6つの instruction-tuned モデルで評価する設計です。

なぜ重要か モデルを乗り換えるたびにプロンプトの勝ち筋が入れ替わるなら、固定したプロンプトテンプレートを使い回す運用は負債になります。SaaS で prompt テンプレを資産化している個人開発者にとって、世代ごとに再計測して有効性を入れ直す前提で eval を回すかどうかの判断が変わります。

実践で使える点 新しい instruction-tuned モデルへ切り替える際は、Zero-Shot / Few-Shot / CoT / CCoT / PoT を同一タスクで横並びに再評価し、世代間でどの手法が有効かを再計測する運用にします。固定プロンプトを前提にせず、モデル世代ごとのベンチマークを残してテンプレを更新する体制を整えます。

原典 Aging of Prompt Engineering Techniques Across LLM Versions

5. Claude Code v2.1.246 — Bash allow ルールのワイルドカード警告と Auto mode 権限タブの追加ほか

要点 Claude Code v2.1.246 の What’s changed として、次の変更が記載されています。

• Bash allow ルールでサブコマンドの前にワイルドカードを含む場合（例: Bash(git * main)）に起動時警告が追加されました。サブコマンドの前に挿入されたオプションにもマッチしてしまうためです。
• /permissions に Auto mode タブが追加され、auto mode classifier rules の表示と編集ができます。
• ターン終了時の duration 行にターンの完了時刻が追加され、✻ Sautéed for 23s · done 6:05 PM のように表示されます。
• fullscreen モードで、端末のリサイズ後に transcript が空白で表示され、次のキー押下まで下端にジャンプしたままになる問題が修正されました。
• diff に非常に長い single… を含む場合の深刻な transcript スローダウンが修正されました（原文は very long singl で途切れています）。

なぜ重要か ワイルドカードの位置によってオプションまで許可してしまう挙動は、エージェントに権限を渡す運用で即事故につながります。今回の起動時警告の追加と /permissions の Auto mode タブにより、permissions 設定の誤りを把握し是正できます。

原典 v2.1.246

6. Jalapeño — OpenAI初の自社推論チップがワットあたり1.5〜1.9倍・レイテンシ1.7〜3.6倍、高インタラクティブで2.1〜4.1倍を実測

要点 OpenAI初の自社推論チップJalapeñoについて、OpenAIがチップと周辺システムのテスト結果を公開しました。Jalapeñoは現代のモデル向けにより高速で電力効率の高い推論を提供し、既存のハードウェアシステムがトレードオフを迫られることの多いスループットとレイテンシを1つのアーキテクチャで両立します。単位電力あたりにより多くのAI処理をこなしつつレスポンスをより速く返します。性能はGPT-OSS 120B、DeepSeek R1、Kimi K2.5 1Tの3モデルにわたって検証され、OpenAI内外のモデルでアーキテクチャが機能することが示されています。3モデル共通で、比較システムに対してピークスループット時にワットあたり1.5〜1.9倍のAI処理量、エンドツーエンドレイテンシで1.7〜3.6倍の低減を記録し、高いインタラクティブ性が求められるワークロードでは2.1〜4.1倍の性能を発揮します。顧客にとっては、より速いレスポンス、より応答性の高いエージェント、需要増大時のより信頼性の高いアクセスにつながり、ますます高性能なAIをより手頃で幅広く利用可能にすることが目的として掲げられています。Jalapeñoの開発自体もOpenAIのモデルが加速させており、初期世代がチップの設計と立ち上げを支援し、最新のモデルが最適化とプログラミングを加速しています。Jalapeñoは測定結果を伴う動作中のfirst-party siliconであり、今後数か月で顧客向けにより高速で高性能かつ効率的なプロダクトを提供するためにランプアップが予定されています。モデル、プロダクト、サービングソフトウェア、チップ、メモリ、ネットワーキング、システムを一体で設計するフルスタックの優位性の証左として位置づけられ、複数世代にわたるプラットフォームの始まりとされています。

なぜ重要か 同一モデルでもチップによってワットあたりの処理量が1.5〜1.9倍、レイテンシが1.7〜3.6倍と数倍変わることが一次情報で示されたため、API単価と自前ホスティングの損益分岐の前提が変わります。個人開発のSaaSでは推論コストと体感速度が利益とUXを直接左右するため、将来の値下げ余地やハードウェア選定の判断材料として押さえておく必要があります。

原典 Jalapeño’s first results show industry-leading speed and efficiency in AI inference

7. Reading Is Not Using — 検索できても判断に使われない「retrieval-integration gap」を2k〜128kトークンで定量化

要点 arXivに公開された論文「Reading Is Not Using: Retrieval, Judgment, and the Design of AI Financial Research Workflows」は、LLMが金融開示を処理し投資判断を支援するAIアナリストとして展開されることが増えていると指摘したうえで、そうしたシステムは取得した情報を想起できるかで評価されることが多く、想起した情報が判断に影響を与えるかでは評価されていないと問題提起しています。long-contextの金融分析においてretrieval-integration gapを特定しています。焦点となる企業の情報は固定したまま無関係なコンテキストのみを2,000トークンから128,000トークンまで変化させる実験で、リスク開示が投資判断に与える影響は直接的なretrievalが正確なままであっても実験上のノイズフロアまで低下することを見出しています。

なぜ重要か long-contextに詰め込めばRAGが賢くなるという前提が崩れます。リスク開示を正確に想起できても投資判断がノイズに埋もれるなら、取得と統合を分離したワークフロー設計が必要になります。コンテキスト長を伸ばすこと自体が判断の質を担保しないという実証は、金融分野のRAGやAIアナリストの設計判断に直結します。

原典 Reading Is Not Using: Retrieval, Judgment, and the Design of AI Financial Research Workflows

8. Joint Optimization of Tool Creation and Use for Large Language Model Agents — 単一ポリシーでツール生成と利用を同時学習するSMITH

要点 arXivに公開された論文「Joint Optimization of Tool Creation and Use for Large Language Model Agents」は、tool-augmented language modelsは人間が用意したAPIの範囲に制約されること、既存のtool-creationシステムは推論時にfrozen LLMへプロンプトすることで補うもののツールを書くモデルと使うモデルが分離され、生成したスキーマが自分で呼び出せるスキーマかどうかのシグナルがないことを指摘しています。SMITH（Schema-grounded Multi-task Iterative Tool Honing）として、tool creationとtool useを単一ポリシー内で同時に学習するreinforcement learning frameworkを提案しています。各rolloutは、数例からツールを書くbuild taskか、pooled toolを呼び出すuse taskのいずれかです。

なぜ重要か エージェントの上限が既存APIの有無で決まるという問題を、生成から利用までを同一モデルで最適化することで解こうとする提案です。SaaSに足りない操作を自前ツールとして生やせるかどうかの実装指針として、ツール生成と利用を分離せず学習する設計を押さえておく必要があります。

原典 Joint Optimization of Tool Creation and Use for Large Language Model Agents

9. StepGuard — ステップレベルでツール実行を事前・事後に監査するGuardモデル

要点 arXivに公開された論文「StepGuard: Learning Step-Level Guardrails with Scalable Supervision and Safety-Utility Balancing」は、LLM-based agentsがtool invocationを通じて外部環境と対話できる一方で、file modification、information leakage、unauthorized actionsといったセキュリティリスクをもたらすと指摘しています。既存のguardrailsは完了したtrajectoriesを評価することが多く、step-levelの行動を実行前に監視する観点が十分に探求されていないとしています。StepGuardとして、完了したエージェントのtrajectoryを監査し、tool actionsを実行前にチェックできるstep-levelのguardモデルを提案しています。学習のために、safeおよびunsafeなtrajectoriesを生成する自動データエンジンStepGenを導入するとしています。

なぜ重要か ファイル変更や情報漏えいを軌跡の完了後に検知するのでは手遅れになります。実行前に止められるguardを挟む設計は、個人開発でエージェントに書き込み権限を渡す際の必須のガードレールになります。事前監査と事後監査を同一のstep-levelモデルで担うという位置づけを押さえておくことで、権限委譲時の安全設計を検討できます。

原典 StepGuard: Learning Step-Level Guardrails with Scalable Supervision and Safety-Utility Balancing

10. Quoting Paul Dix — AIが100万行を書き数ヶ月で精錬し数百万台で動くソフトウェアは検証システムと適切な指示で可能という指摘

要点 Simon Willisonが2026年8月26日にPaul Dixの「The end of programming」からの引用を紹介しました。AIが100万行を書き、その後の数ヶ月にわたり精錬して、現在数百万台の開発者マシンで動作する信頼性の高いソフトウェアを生み出したことは驚異的だと述べています。比較対象となるオラクルがあったため言語間の移植は単純だったとする見方もできるが、それは矮小化だとしています。検証システムを構築し適切な方向づけを与えれば、AIは高度に複雑で洗練されたソフトウェアを生成し、動作するまで継続的に精錬できると指摘しています。

なぜ重要か 検証オラクルと適切なディレクションがあればAIは大規模で複雑なソフトウェアを継続的に改善できるという主張は、個人開発が巨大なコードベースをAIに任せる際のテスト・検証への投資判断を変えます。コード生成そのものより、検証システムの有無と指示設計が成功条件になると位置づけられます。

原典 Quoting Paul Dix