ハクソク

世界を動かす技術を、日本語で。

私はうっかりLLMメモリをプログラム分析に変えてしまった

2026年8月29日原文(pwning.systems)

概要

  • LLMエージェントを用いた脆弱性調査における 記憶管理の課題 を解説
  • 記憶の喪失や 誤った結論の維持 を防ぐための新アプローチを提案
  • Datalog を用いた事実と推論の管理手法を紹介
  • Lemmalogという LLM支援型Datalogエンジン の仕組みを説明
  • 記憶の「検索」と「現在の真実」の違いを明確化

LLMエージェントの脆弱性調査における記憶の課題

  • LLMエージェントは 大規模コードベースの解析 や 攻撃面の特定 に有用
  • 調査が長時間に及ぶと、 過去の結論や前提を忘却 しやすい
  • 既に否定された仮説の再提案 や、誤った前提に基づく推論が発生
  • LLMに「それは誤り」と伝えても、 依存する他の知識が自動で修正されない 問題

記憶管理の従来手法とその限界

  • 多くのシステムは 過去の会話や観察結果を保存・埋め込み・検索 して再利用
  • この手法では「 何を知っているか」ではなく「 何を話したか」のみ保持
  • 調査中に前提が覆った場合、 LLMが自力で有効・無効な結論を再判別 する必要
  • 事実の追加・削除に伴う結論の自動更新 が困難

プログラム解析的な視点

  • プログラム解析では、「 事実」と「 規則」から新たな事実を導出
  • 入力事実が変化した際、 影響を受ける結論のみを効率的に更新 可能
  • LLMにも同様の 状態管理 が求められる

Datalogの導入

  • Datalog は宣言型ロジック言語で、事実と規則から新たな事実を導出
  • 例：
    • controls(attacker, object_a).
    • points_to(object_a, object_b).
    • kernel_object(object_b).
    • controls_kernel_object(Attacker) :- controls(Attacker, ObjectA), points_to(ObjectA, ObjectB), kernel_object(ObjectB).
  • 事実が訂正された場合、依存する結論を自動で無効化できる

Lemmalogの仕組み

  • LLMは「 曖昧な自然言語・コード・デバッガ出力」を 構造化事実 に変換
  • Lemmalogは 事実・規則・導出事実 の管理と推論を担当
  • LLMは「意味理解」、Lemmalogは「 状態の一貫性管理」を分担

事実の削除・差し替えと再評価

  • 事実の 追加は容易だが、削除は依存関係の追跡が必要
    • 例：c :- a. c :- b. の場合、a削除だけではcは消えない
  • 複数の観察に支えられた結論 の正確な維持
  • なぜその結論に至ったか （プロヴェナンス）のトラッキング
  • 事実の有効期間 （バリディティ・インターバル）を管理し、過去の状態も参照可能

ベクトルデータベースとの比較

  • ベクトルDBは「 過去の関連情報の検索」には有効
  • しかし、「 現在何が真実か」「依存する結論の自動無効化」には非対応
  • 記憶の検索 と 状態の維持 は別問題

脆弱性調査の分析状態モデル

  • 観察、仮定、関係、仮説、結論を プログラム解析の要素 として整理
  • 入力事実→規則→導出事実→固定点（現在の知識）
  • 依存関係の追跡により、 結論の根拠説明（プロヴェナンス） が可能

LLMとLemmalogの役割分担

  • LLM ：フロントエンド（自然言語・コード→構造化事実への変換）
  • Lemmalog ：中間表現・解析エンジン（事実・規則による状態管理）
  • LLM による再ナチュラル言語化・次の実験提案なども可能

Lemmalogの機能と効果

  • インクリメンタル評価・事実の撤回・プロヴェナンス・時系列管理・集約・ハイブリッド検索 など多彩な機能
  • LLMの「 一貫した知識管理」を強化し、 誤った結論の維持や記憶喪失を防止
  • 記憶の「 検索」と「 現在の真実」を明確に分離し、 複雑な調査をより信頼性高く支援

Hackerたちの意見

こういう機能があれば、ログにある不明なハードウェアの故障を調査するのに役立つんだけど、問題が私のショップにいる間は観察できなかったから確認できなかったんだ。問題は別の場所で発生していて、ソフトウェアの特定の状況や接続されている周辺機器が原因だったかもしれない。LLMが、会話の履歴の中で確認済みの結論を忘れてしまう同じ問題に直面したことがある。可能性を探っているときにその結論を再確認し続けなきゃいけなかった。結局、LLMに同じ問題を経験している他の人のサポートソースをキャッチさせて、要約だけに集中していたからそれを洗練させ続けたんだけど、最終的には仮説として十分なソースにまで持っていけたから、潜在的な原因についてより良い結論を導き出せたよ。

すごく面白いね。HNに似たような投稿があったのを思い出すんだけど（残念ながら今は見つからない）、それはLLMを使って記事を一連のステートメントに分解して、事実や出来事のエンティティ-リレーションシップグラフを構築してたんだ。で、それを従来のグラフクエリメソッドでクエリしてた。まるでここでDataLog / Lemmalogがやってるみたいにね。特に、当時のLLMが苦手だったタイムラインベースのクエリに対して効果的だったのを覚えてる。（Cycについても見てみてね: https://en.wikipedia.org/wiki/Cyc）こういうアプローチが、LLMの応答を権威あるデータソースに基づかせるための基盤になると思う。誤りを不正確なトラバーサルや不正確な「事実」に特定できるはず。ただ、具体的で明確な事実に対してはうまくいくけど、あいまいな情報や意見ベースの情報はLLMの領域に残るだろうね。

└

これのことかな？: https://news.ycombinator.com/item?id=41445445

└

これは証拠の基盤にはいいけど、ほとんどの場合、大きな記憶や推論の改善にはつながらないね。

私も似たような結論に達したよ：LLMはリクエストの実行端末にしか存在すべきじゃない。1. ユーザーリクエストの理解：自然言語 -> より厳密な表現、私の場合はDatalog。2. 結果の解釈：事実と派生事実 -> 自然言語。その間では、いくつかのオントロジーや形式的な知識構造に基づいた機械的な推論が必要だと思う。これが私が考えている別の原則、Weatheringにつながるんだ。役立つ推論はシステムの形を変えるべきだと思う。もしLLMがすでに関係、マッピング、ルール、または抽象を推測していたら、繰り返し使うことでその推論がシステムに組み込まれて、次の似たリクエストではゼロから再発見する必要がなくなるはず。継続的に使うことで、Weatheringが可能なシステムは、繰り返しの作業に対してますます少ない確率的知性を必要とするようになるだろうね。言い換えれば、知性の成果が再利用可能な構造に固まるから、認知の限界コストが下がるはずだよ。

└

野生のベイズ後方分布。最高だね！

└

理論的には、どんなLLMが生成したインフラや分類セットも、精度の低さからドリフトすることになるし、それがIRや他の論理プロセスに悪影響を及ぼすよね。緩い分類法を使うのは好きだけど、革命的ってわけじゃないな。

└

「風化」って聞くと、何かがゆっくりと侵食されていくイメージがあるな。

└

君が「風化」と呼んでいることは、僕の常に不満に思っていることだ。LLM駆動のソフトウェアは、リクエストが来るたびにほぼゼロから始まるように見える。メモを取るような学習や一般化のメカニズムはあるけど、信頼性がない。例えば、「これはメモにあるけど、リクエストは新しいデータのスキャンが必要そうだから、メモを無視して」って言える便利なレバーはないし、逆に「メモの情報から推測できるから、再推論しないで！」っていうのもない。Dynamic CheatsheetsやAgentic Context Engineeringのような研究がこの側面を探求しているけど、一般的に信頼できる解決策には程遠い。これが解決されるまで、これを解決しようとするシステムのバリエーションは、(a) LLM寄り：人間がフィルターとして不正確な応答を拒否するために、非構造化メモリファイルを作成する (b) LLMをレイヤーとして使う：君が説明していることやその記事がやっていることだと思う。

これは私がClaudeとの長い研究プロジェクトでの経験にすごく合ってる。情報を削除するのがすごく難しいんだ。Claudeはあちこちに記録を残す癖があって、否定された後でも事実として扱うことがある。現在の真実が古い「事実」で簡単に汚染されちゃうんだよね。

これが私がずっと悩んでいる事実なんだ。事実を忘れるからじゃなくて、無効化が伝播しないからなんだ。私の対処法は決定ログを作ること。これを始めてからのプロジェクトではうまくいってる。私のCLAUDE.mdは、エージェントに私の決定をファイルに保存させる指示を出してる。いつその決定をしたのか、どんな文脈だったのかのメタデータも付けてね。エージェントはこのファイルを決定のインデックスとして使っていて、トラッキングを失うことはほとんどない。チームメンバーも開発フェーズについてもっと知るのに役立ってるよ。あなたのシステムは、無効または関連性がなくなったメモリの部分を無効化するの？それともただ保存/取得するだけ？

彼は「is_a」表現で保存されたデータを生成するためにLLMを使ってるんだね。まさにクラシックなAIだ。すぐに、彼は量化子が必要だと気づくよ。「すべてのために」は時々強すぎるから、「ほとんどのために」が必要になるんだ。そこにはCycがある。悪くないアイデアだけど、歴史があるね。

Hacker Newsで議論の続きを見る