ARTEX・Cairn・Strix比較――AIが「探索のループ」を担う仕組み

1. AIエージェント化される「探索のループ」とは

人が追加の指示を出しながらAIを使う場合は、ツールの実行結果を読み、「この結果にはどのような意味があるか」「次はどの条件を調べるべきか」を考えて追加の指示を出します。思考と判断の中心は人側にあります。

これに対して自律型のセキュリティエージェントでは、ツールの実行と次の判断をつなぐ仕組みがプログラムとして組み込まれています。AIが自ら調査の方向を提案し、ツールの出力を読み取り、得られた情報をデータとして保存し、その蓄積をもとに次の行動を決定します。観察と行動が1回で終わるのではなく、結果が次の判断へと循環していく点が大きな特徴です（ARTEXのplanner実装、CairnのReason処理、Strixのエージェント連携）。

探索ループの基本構造

※上記の表は、3つの実装を共通の視点で読み解くために本記事が整理した枠組みです。各実装にこの通りの名前がついた機能が存在するわけではありません。

エージェントの動作において注目すべきなのは、呼び出せるツールの数だけではありません。「得られた結果をどのように次の判断へフィードバックするか」という記憶と更新の設計です。記憶の保持が不十分であれば同じ調査を何度も繰り返してしまいますし、不確かな仮説を事実として共有してしまえば、その後の探索全体が意図しない方向へ逸れてしまいます。

2. ARTEX・Cairn・Strixの全体像と比較軸

いずれのシステムも、大規模言語モデル（LLM）にツール実行環境、記憶領域、作業分担のルールを組み合わせて構成されています。「モデル自体の能力」と「その能力を探索へつなぐためのアーキテクチャ」を切り離して捉えると、各ツールの狙いが整理しやすくなります（ARTEXのplanner実装、CairnのReason処理、Strix公式ドキュメント）。

※この比較は公開資料とコードの読み取りに基づいて整理したものです。同一環境でツールを実際に稼働させて優劣を測定した比較ではありません。公式リポジトリの入口はARTEX、Cairn、Strixです。開発元の公式リポジトリとforkや派生記事を区別し、確認コミットをそろえて確認することが重要です。

3. 各ツールの個別設計：分担・記憶・検証

3つのツールは、先ほど挙げた「探索のループ」をそれぞれ異なる構造で実現しています。個々の内部実装を見ていきましょう。

ARTEX：計画役と実行役の明確な分離

ARTEXでは、「計画を立てる役割（planner）」と「調査を実行する役割（worker）」が明確に分かれています。

公開実装において、次の探索方針である「Intent」を生成するのはplannerのみです。workerは割り当てられたIntentを実行し、その結果を書き戻して作業を完了します。worker自身が勝手に新しい探索方向を次々と作り出す構造にはなっていません（planner実装、worker実装）。

ARTEXの設計上の大きな特徴は、管理する対象を「資産グラフ」と「探索グラフ」の2つに分けて保持する点です（ARTEXの設計説明）。

• 資産グラフ：「どのようなホストやエンドポイントが存在するか」という対象物の構造
• 探索グラフ：「何を根拠に、どの方向を調査し、何が判明したか」という判断と行動の履歴

この2つを結び付けることで、「ある資産に対して過去にどのような調査を行ったか」をたどることも、「探索の経緯からどの資産が影響を受けるか」を確認することも可能になります。

さらにplannerは、複数回の判断をまたいで維持される作業計画を持っています。前の調査結果が必要な作業を、前提条件が揃う前に不用意に並列実行してしまわないための制御です。互いに依存しない独立した調査だけを並列に進め、前提が必要な調査は結果を待つという整理が行われています（plannerの共有計画）。

なお、発見事項に対して通信流量などの証拠を紐付ける処理も存在しますが、これは設定によって動作が変わります。レポートが出力されていること、通信記録が残っていること、そしてその通信記録が特定の発見を直接裏付けていることは、それぞれ分けて確認する必要があります（証拠の関連付け処理）。

Cairn：共有グラフを通じた状態空間探索

Cairnは、出発地点と目標地点は決まっているものの、その間にどのような経路が存在するかが事前に分からない問題を解くための仕組みです。セキュリティ検証はその適用対象の1つであり、プロジェクトの位置付けとしては汎用的な「状態空間探索エンジン」と説明されています（Cairnの説明）。

ここでいう「状態空間」とは、現時点で判明している情報や、これから取り得る行動によって変化する状況の全体を指します。あらかじめすべての状態を網羅しておくのではなく、得られた結果に応じて次の候補となる状態を動的に広げていきます。

Cairnでは、エージェント同士が直接会話するのではなく、「共有ボード」と呼ばれるグラフ構造を介して情報をやり取りします。

エージェントごとに個別のメモを持たせるのではなく、根拠と結果を共有ボードに集約することで、チーム全体での協調を実現しています（Cairnの共有ボード）。

公開実装におけるタスクは、初期調査を行う「Bootstrap」、グラフを読み込んで次の探索方針や終了を判断する「Reason」、割り当てられたIntentを実際に調査する「Explore」に分かれています。「固定された職種別の役割を持たない」という設計思想ですが、これは判断と実行の分担がないという意味ではなく、汎用的なWorkerに対してReasonやExploreといったタスクを動的に割り当てる構造をとっています（Reason処理、Explore処理）。

共有グラフを利用することで、複数の調査を並行して進めつつ、一方で得られた情報を、別の調査でも使うことができます。ただし、共有された情報に誤りがあった場合、その誤りも全体へ拡散しやすい側面があります。出力形式やデータ参照がスキーマ通りであることと、記録された内容が現実の挙動として正しいこととは、別の問題として捉える必要があります（Cairnの出力契約、データモデル）。

Strix：動的な役割分担と反証を含む検証

Strixは、Webアプリケーション、API、ソースコードなどを対象としたセキュリティ検証エージェントです。ブラウザ操作、HTTPプロキシ、シェル端末、コード静的解析ツールなどを備え、発見した疑わしい挙動を実際に確かめる工程に重点を置いています（Strix公式ドキュメント）。

プロンプトの実装を見ると、全体を統括するroot agentが調査対象を分解し、必要に応じて子エージェントを作成して作業を割り振る構成をとっています。子エージェントは固定的な専門職として初めから常駐しているのではなく、検証したい内容や対象に応じて動的に生成されます。「偵察役・検証役・報告役の3者が順番に1回ずつ動く」といった単純な固定フローではありません（Strixの役割設計、エージェント作成・連携の実装）。

報告処理のデータ構造には、根拠（evidence）、前提（assumptions）、反証（counter-evidence）、確度（confidence）、影響度が変わる条件などが定義されています。「一見すると脆弱性に見えるが、実は仕様上許可された正常な挙動ではないか」という反対の可能性も考慮して検証結果をまとめる設計です。一方で、実際にツールを実行せずにコードから導いた静的な根拠や、ライブラリの依存関係に基づく報告なども区別して扱われます（Strixの報告処理）。

このため、「Strixが報告した内容は、すべて動的な実証コード（PoC）によって第三者環境でも再現が確認されたものである」と捉えるのは適切ではありません。プロンプト上で証拠の提示を要求していることと、提示された証拠が常に客観的に再現可能であることは区別して評価する必要があります。

また実装上、子エージェントが発言内で主張した「発見」と、システムに正式登録された「レポート」を区別して親エージェントへ引き渡す処理も存在します。「見つけた」という会話上の報告を鵜呑みにせず、登録された記録が存在するかどうかを確認する設計が見て取れます（登録レポートを参照する処理）。

4. 探索結果はどう引き継がれるか

ここまで見てきた3つのアプローチを並べると、重要な共通点が浮かび上がります。それは、単に複数のAIが同時に動いていることではなく、「途中で分かった結果をどのように記録し、次の判断へ引き継ぐか」という情報管理の仕組みです。

• ARTEX：資産情報と探索履歴をグラフとして結び付けて引き継ぐ
• Cairn：Fact（調査で得た情報）とIntent（調査方針）を共有ボードで管理して引き継ぐ
• Strix：動的に生成された子エージェントの作業結果と登録レポートを集約して引き継ぐ

扱うデータの形式は異なりますが、いずれも「得られた結果を吟味し、次の行動を決める」というループを成立させるための足場となっています。

具体的な検証シナリオでの設計比較

理解を深めるために、架空の社内Webアプリケーションを対象に「テスト用一般ユーザーの権限が、設計通りに他ユーザーのデータから分離されているか」を確認する場面を想定してみます。各ツールの設計思想に注目すると、以下のような違いが見えてきます。

※上記は設計の特徴を説明するための例であり、各ツールを実際に稼働させた試験結果ではありません。

どのツールを用いる場合でも、「想定と異なる応答が返ってきた」という事実だけで直ちに深刻な脆弱性と断定することはできません。テスト時の権限設定、対象システムの本来の仕様、通信の再現性を確かめる必要があります。AIが探索を代行するとしても、判断の根拠となる情報がどのように残されているかを確認する視点は欠かせません。

5. 周辺ツールとの位置付けの整理

セキュリティ領域におけるAIツールは、この3つだけに限りません。自律エージェントの役割をより広い視野で理解するために、関連する既存ツールや先行プロジェクトとの違いを整理しておきます。

PentAGIについては開発元の設計説明と公式リポジトリを、PentestGPTについては現行READMEを参照しています。特にPentestGPTは、2024年の研究発表当初に対話型として提案された構成（legacy版）と、現在の自律的なパイプライン構成を区別して捉える必要があります。

また、Nucleiのような既存のスキャナにも設定に基づいたワークフロー機能があり、「従来ツールはすべて単発実行で、AIツールだけが反復を行う」と単純に二分できるわけではありません。違いを比較する際は、「あらかじめ決められた手順を辿るのか」、それとも「実行結果を読み取って動的に次の手順を組み立てるのか」という境界を見極めることが大切です（Nucleiの設計、Semgrepの静的解析用語）。

6. 並列エージェントの時間とコストの現実

複数のエージェントを協調させれば、常に作業が高速化し、コストも削減できるのでしょうか。この問いに対して具体的なデータを示しているのが、Cairnの論文（2026年9月26日公開）です。

論文はGLM-5.1と、推論役・実行役で共有する最大6枠を使い、外部インターネットを遮断して評価しています。比較対象のDirectは、共有グラフによる協調を使わない方式です（CAIRN論文）。

※上記の実験は数学の問題やCTF課題を対象としたベンチマークであり、実際の企業インフラに対する侵入成功率を示すものではありません。また本記事が独自に実測した数値でもありません（評価条件と結果）。

この結果から見えてくるのは、並列化によって短縮できる実行時間と、情報共有やタスク調整のために消費される追加の計算量（トークン消費）のトレードオフです。

短い課題では、仕事を分けたり結果を共有したりする負担が、時間短縮の効果を上回ることがあります。長く探索する課題では、複数の方向を同時に追う価値が出てきます。使うモデルやトークンの内訳によって料金は変わるため、トークン量をそのままAPI料金の倍率には換算できません。

ARTEXやStrixを含め、「どのシステムが最も優れているか」を一概に評価することは困難です。比較を行うのであれば、対象システムの規模、使用するモデル、事前に与える前提知識、制限時間、消費可能な計算リソース、そして成功とみなす判定基準を厳密に揃える必要があります。

7. 実運用における権限・証拠・終了条件の設計

探索ループを実際の業務や検証プロセスへ組み込むにあたっては、ツールの自律性だけでなく、安全な運用のための境界線を明確にしておく必要があります。

自律性と実行権限の区別

AIの「自律性」とは、得られた情報をもとに、次の行動をどこまで自分で判断できるかを指します。一方、「実行権限」とは、どの対象システムに対してどのような操作を行ってよいかという認可の範囲を指します。AIの判断能力や自律性が向上したからといって、システムに与える操作権限まで無制限に広げてよいわけではありません。

検証を実施する際は、必ず事前に許可された検証環境と安全なテストデータを用意し、対象範囲、使用する認証情報、実行可能な操作種別を厳密に制限しておく必要があります。コンテナ内で動かしているからといって、外部への不正な通信が自動的に遮断されるわけではありません。Strixの公式ドキュメントでも、自身が所有している環境、または明示的に許可された対象に対してのみテストを実行するよう明確に案内されています（Strix公式ドキュメント）。

また、ツールを自社インフラ上にセルフホストして動かしている場合でも、バックエンドで呼び出すLLMが外部クラウド上のAPIであれば、プロンプトに含まれる調査データは外部モデルへ送信されます。ローカルモデルを使うのか、商用APIを使うのかによって情報管理の前提が異なる点にも注意が必要です（Strixの公開版の説明）。

終了時に残すべき成果物の基準

調査を安全かつ再現可能な形で完了させるためには、「何を記録として残すか」の基準を定めておくことが実務上重要になります。

• 発見された問題の内容と、それを裏付ける通信記録やログ等の根拠を分けて記録する
• 実際に調査を完了した対象範囲と、時間の制約等で未確認のまま残った範囲を明記する
• 再現に成功した手順や条件だけでなく、試行して失敗した条件や反証となる挙動も記録する
• 時間切れや予算上限（トークン上限）によって途中で調査を打ち切った場合は、その理由を残す
• 修正が行われた後の再検証記録は、初期調査時の発見記録と混ざらないよう区別して管理する

「問題が報告されなかった」という結果は、「調査対象に問題が存在しないことが証明された」という意味ではありません。終了条件と未確認の領域が明記されていなければ、受け取った人間が調査結果を正しく評価し、次のセキュリティ対策へつなげることが難しくなります。

8. 探索と証拠を運用する技術へ

ARTEX、Cairn、Strixの設計を比較すると、AIによるセキュリティ検証の論点が「どの言語モデルの推論能力が高いか」という単純な問いから、「探索のループをどのように構造化し、運用可能にするか」というシステム設計の問いへと移行していることが分かります。

• 計画役と実行役を分けて探索を進めるのか（ARTEX）
• 共有グラフによって多角的な仮説検証を並行して進めるのか（Cairn）
• 動的なタスク分解と反証の記録によって報告の根拠を固めるのか（Strix）

AIが自律的に試行錯誤を繰り返す範囲が広がるほど、それを利用する人間側に求められる役割も変化します。AIから提示された最終的な「発見リスト」だけを眺めるのではなく、「どのような仮説に基づき、何を根拠として判断を下し、どこを未確認のまま残したのか」という探索のプロセスと証拠を追跡できる仕組みが重要になります。

AIエージェントの動向を追う際は、モデルの単体性能やエージェントの数だけでなく、探索の記憶、証拠の記録、そして人間が検証可能な形で運用できる設計になっているかという視点を持つことが役立ちます。

関連する解説：相次ぐサイバー攻撃とAIの警告、AIエージェントに本番権限を渡す前に考えること。

この記事は2026年10月7日時点の公開資料とソースコードの読み取りに基づく比較です。3つのツールを実際の対象へ実行した検証ではありません。ソースへのリンクは確認したコミットに固定し、公式の紹介や論文の評価と、本記事の考察を分けて記載しています。