LuaN1aoAgent v2の設計を読む：Planner-Executor-Observer分離と証拠付き因果グラフ
LuaN1aoAgent is a fully autonomous AI-driven penetration testing agent powered by graph-based cognitive reasoning.
ひと目でわかる
- これは何？
- LuaN1aoAgent v2は、ペネトレーションテストの自律実行をPlanner・Executor・Observerの3役に分割し、結論を永続イベントとグラフの証拠に紐づける設計を採る。v1からの移行可否を判断するには、設定・永続化・Agentライフサイクルの契約が別物である点を先に確認する必要がある。
- 誰に向いている？
- 採用を検討すべきなのは、認可済みの検証環境で、モデルの推論過程そのものを監査可能な形で残したいチームである。v1のPythonランタイムと設定・永続化・Agentライフサイクルの契約が異なるため、v1の運用資産をそのまま持ち込めるとは考えないほうがよい。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
誰のためのツールか：認可された検証作業と監査可能性
LuaN1aoAgent v2は、認可されたセキュリティ研究を対象とした自律エージェントである。READMEは冒頭で「autonomous, authorized security research」と明記しており、無許可の対象に対する利用を想定していない。想定読者は、ペネトレーションテストの手順を毎回手作業で組み直す代わりに、目標とスコープを与えてエージェントに実行させ、その過程を後から追跡したい層だ。
解こうとしている問題は、LLMエージェントにペネトレーションを任せると、判断の根拠がモデルの会話履歴の内部に埋もれる点にある。READMEは「every important conclusion must remain traceable to persisted events, artifacts, and graph evidence」という原則を掲げており、結論そのものより、結論に至った経路を永続データとして残すことを設計の中心に置いている。したがって、単発のスキャンを自動化したいだけの用途や、結果だけを短時間で欲しい用途には、この構成は過剰である。
3役の分離：Planner・Executor・Observerが受け持つ範囲
v2はv1の共有履歴型P-E-Rループを捨て、実行時の境界を明示した3役に分割した。READMEの記述に沿って役割を整理する。
Plannerは目標、スコープ、依存関係、タスクの予算、グラフ水準のスケジューリングを握る。低レベルの操作を指示するのではなく、goal-levelのタスクを作成またはpatchする。判断はplanner_submitという終端ツールを通じて提出される。
Executorは境界づけられたTaskEnvelopeを受け取り、ツール戦略を自分で選ぶ。公開された意図、ツール入力、ツール出力、使用量、エラー、最終結果を記録する。大きな出力はコンテキストを膨らませる代わりに不変のartifactとして保存する。同一Taskのエポック間では同じPiセッション系列とworkspaceを再利用するが、異なるTask同士は分離される。提出はtask_result_submit経由である。
Observerは2つの独立モードで動く。Supervisorは直近のExecutorの行動を検査し、継続、チェックポイント、停止、Plannerへの制御返却を決める。Projectorは正規化された観測を非同期に証拠付きの推論グラフと操作グラフの差分へ変換する。Observerの各呼び出しは新しいPiセッションを使い、隠れたモデル履歴を共有しない。提出先はcontrol_submitとgraph_delta_submitである。
注目に値するのは、Observerがホットパスと非同期処理に分かれている点だ。制御判断はExecutorのループを止める位置に入るが、グラフ更新は止めない。この分離によってExecutorのスループットを落とさずに記録を厚くできる半面、グラフが実際の実行から遅れて追いつく時間差が生まれる。
因果グラフの作り方：EvidenceからExploitまでの制約
推論の表現は、モデルの文章ではなくノードとエッジで行う。READMEが示す流れは、Evidenceがsupportsまたはcontradictsの関係でHypothesisに接続し、HypothesisがconfirmsでVulnerabilityへ、Vulnerabilityがexploited byでExploitへ進む。Evidenceはobserved onでWebEndpointやServiceに結びつく。
ここで効いているのは、不確実性を型として分けていることだ。Hypothesisはconfirmed vulnerabilityとは別物として保持され、確定したVulnerabilityノードと成功したExploitノードは、証拠参照なしには書き込めないとREADMEは説明している。つまり「たぶん脆弱だろう」という段階と「確認済み」の段階が、同じデータ構造の中で混ざらない。
Projectorは正規化された実行観測をグラフ差分へ変換する役で、Executorのループをブロックしない。推論グラフは結論を操作グラフの具体的なエンティティへリンクするため、ある脆弱性の判断がどのホストやエンドポイントに対応するのかを辿れる。
制約として、この仕組みは観測が正規化できることを前提にしている。ツール出力の形式が大きく揺れる対象や、そもそもテキストとして残らない相互作用については、証拠参照を張れる粒度のイベントが生成されるかどうかを確認する必要がある。READMEからはそこまでの保証は読み取れない。
Plan-on-Graph：チェックリストを再生成せずタスクグラフを更新する
Plannerは線形のチェックリストを毎回作り直すのではなく、変化し続けるTask Graphを維持する。READMEの図ではGoalからRecon TaskとAuth Taskが分岐し、ReconがService Profileというマイルストーンへ進み、そのマイルストーンとAuthの両方がValidation Taskへ接続する。Blockerはblocks関係でValidation Taskを妨げる。
グラフ操作は構造化されており、create_tasks、patch_task、replace_dependencies、set_task_statusといった操作が列挙されている。タスクの追加、依存関係の張り替え、状態変更が個別の操作として表現されるため、途中で前提が崩れても全体を書き直さずに済む。
もう一点、Plannerはグラフ変更とタスクのハンドオフの後に、並列ウェーブ全体の完了を待たずに、準備できたタスクと利用可能な容量を突き合わせて調整する。並列度を上げたときに遊休が出にくい設計だが、依存関係の解決を誤ると準備できていないタスクを走らせる余地も同時に生まれる。replace_dependenciesの適用順序は、運用側で意識しておく価値がある。
動かすまでに必要なもの：Node.js 25+とPi SDK
リポジトリのバッジと記述から確認できる実行条件は、Node.js 25以上、TypeScript 5.x、ランタイムとしてPi SDK、アーキテクチャとしてP-E-Oという構成である。パッケージ名やインストール手順の具体的なコマンドは、与えられたREADMEの範囲では確認できない。npmやpnpmのコマンドをここで示すことはできないので、実際のセットアップはリポジトリのQuick Start節とpackage.jsonを直接参照してほしい。
設定については、v2がv1のin-placeリファクタではないとREADMEが明言している点が重要である。設定、永続化、Agentライフサイクル、可観測性の契約がそれぞれ異なる。したがってv1の設定ファイルをv2に流用する前提は立てられない。
提出用の終端ツール名は、設定や拡張を書く際の手がかりになる。planner_submit、task_result_submit、control_submit、graph_delta_submitの4つが役割ごとに分かれている。どの役がどのツールで結果を返すかを把握しておくと、ログの読み方とデバッグの入口が定まる。
ライセンスはAGPL-3.0である。ネットワーク越しに利用者へ機能を提供する形で改変版を動かす場合、AGPLの下ではソースの提供义务が生じうる。これは法務判断ではなく一般的な説明にとどめるが、社内ツールとして閉じて使うのか、外部に公開するサービスへ組み込むのかで検討事項が変わる点は、採用前に整理しておきたい。
v2の実力を今すぐ前提にできない理由
READMEは、v1が報告したベンチマーク結果をv2へ自動的に帰属させないと明記している。v2の結果は、凍結されたリリース上で再現可能な再計測が行われた後にのみ公開されるという方針である。つまり現時点で、v2の性能を裏づける数値は提示されていない。
これは弱点というより、書き直しに対して誠実な態度だと受け取れる。ただし採用判断の材料としては、性能の根拠が未提示であるという事実そのものが制約になる。PoCを組む際は、自組織の対象と手順で計測し直す以外に判断材料がない。
もうひとつの制約は実行環境である。Node.js 25以上という要件は、LTSを軸に運用している現場では標準より新しい。検証用のホストを別に用意するか、コンテナで隔離するかを先に決める必要がある。
さらに、Executorが大きな出力をartifactとして退避する設計はコンテキストの肥大化を防ぐが、artifactの保存先と保持期間は運用側の設計事項になる。証拠を残すことが目的のツールである以上、保存先の容量とライフサイクルを決めずに走らせるのは筋が悪い。
代替手段との違い：履歴に閉じるか、グラフに開くか
同じ領域には、LLMにシェルやスキャナを順番に呼ばせるタイプのエージェントが複数ある。それらとの差分は、結論の置き場所である。一般的な構成では、エージェントの判断は会話履歴の中に残り、セッションが終われば根拠の連鎖は失われるか、要約という形で圧縮される。
LuaN1aoAgent v2は、判断をEvidence、Hypothesis、Vulnerability、Exploitというノードと関係として外部化し、確定ノードには証拠参照を必須にする。会話履歴を読まなくても、どの証拠がどの仮説を支え、どの仮説がどの脆弱性を確定させたかをグラフ上で辿れる。
代償もある。グラフのスキーマとProjectorの正規化を維持するコストが発生し、ツール出力が想定形式から外れたときの扱いを決めておく必要がある。単発のスキャンを数回回して終わりという使い方なら、履歴ベースの素朴なエージェントのほうが導入は軽い。逆に、複数セッションをまたいで同じ対象を継続的に検証し、判断の根拠を後から説明する必要があるなら、グラフを外部に持つ構成に分がある。
導入前に確認する順序
最初に見るべきは、v2のQuick Startが示す実行手順と、必要な環境変数・設定キーの一覧である。v1の設定を流用できない以上、ここを飛ばすと後工程で作り直しになる。
次に、Executorが生成するartifactの保存先と、Projectorが書き込むグラフの永続化先を確認する。証拠参照が必須である以上、保存先が揮発性だと設計の前提が崩れる。
そのうえで、自組織の認可済み検証環境で小さなタスクを1つ流し、Live TraceでSupervisorの制御判断とProjectorのグラフ差分が期待どおりに出るかを見る。READMEが示すworkbench-live-traceとworkbench-reasoning-graphの2画面が、その確認の入口になる。
採用の判断は、この2画面を自組織の対象で再現できたかどうかで決めるのが妥当である。再現できなければ、Graphベースの利点は受け取れず、運用コストだけが残る。
編集部の結論
採用を検討すべきなのは、認可済みの検証環境で、モデルの推論過程そのものを監査可能な形で残したいチームである。v1のPythonランタイムと設定・永続化・Agentライフサイクルの契約が異なるため、v1の運用資産をそのまま持ち込めるとは考えないほうがよい。導入前に確認すべきは、実行に必要なNode.js 25+とPi SDKの依存関係、そしてv2のベンチマークが凍結リリース上で再計測されるまで未公表であるという事実である。
コミュニティノート