ARTEXは次の行動をどのように決定するのか？目標入力からツール実行・報告まで

ARTEXは、大規模言語モデル（LLM）が次の行動を決定し、実行ツールとリポジトリがその決定を引き継ぐセキュリティ研究ソフトウェアです。目標を入力すると、決められたコマンドリストを一度実行する方式よりも、計画 → 実行 → 観察 → 再計画が繰り返される構造に近いです。

この構造を理解するには、フォルダ名よりもリクエスト一つの道のりを見る方が早いです。画面で入力した目標がどこに保存され、誰が実行するタスクを作成し、ツールの結果がどのように次のモデル呼び出しに戻るのかを見ていきましょう。

分析基準は、韓国語フォーク jiwoochris/artex-ko の固定コミット 9e1b227d73a6881c1455b0e5ee0595e669474ed2 です。ソースと依存性コードを読んで確認した説明であり、LLM自動セキュリティ試験の実行結果や脆弱性発見の体験談ではありません。 分析対象ソース

AIで生成された概念イメージ。実際のARTEX画面や実行結果ではありません。

1. 画面、実行エンジン、モデルはそれぞれ異なる役割を担う

ARTEXの大きな流れは以下の通りです。観察結果はワーカーのモデル対話に戻り、保存された結果はプランナーの次の計画にも使用されます。

목표 입력 → 작업 생성 API → 저장·목표 분해 → 계획자
                                           ↓ 실행할 일
                                         작업자
                                           ↓
                                  LLM 호출 ↔ 도구 실행·결과
                                           ↓
                                  사실·발견 저장 → 다음 계획
                                           ↓
                                      화면·보고서

WRIMO-MD-TABLE-0]サーバープログラムはcmd/artex/main.goでManagerとHTTPサーバーを構成します。ブラウザが呼び出すAPIとモデルを呼び出すバックエンドが区別されています。主要なタスクデータはPostgreSQLに保存され、対話履歴とコマンド成果物には別途ファイル保存パスも使用されます。go.modにSQLiteの依存性があるからといって、主作業DBまでSQLiteだと解釈すると、この流れを誤読することになります。 [プログラムエントリーポイント · DB接続コード

2. 目標入力はすぐにシェルコマンドにはならない

仮想の隔離された実習サービスに対して、「指定されたHTTP応答のセキュリティヘッダーを確認し、確認できなかった項目は別途表示せよ」という目標を入力したと仮定してみましょう。この例は流れを説明するためのものであり、実際に実行された試験ではありません。

フロントエンドのapi.createTaskは入力をPOST /api/tasksに送信します。サーバーのcreateTaskはJSONやモデル設定などのリクエスト項目を確認した後、Manager.CreateTaskWithOptionsを呼び出します。ここでタスクとそのタスクの探索履歴が接続されます。APIがタスクIDを返すことと目標達成は別々の事象です。 フロントエンドリクエスト · タスク作成処理

その後、launchTaskが初期情報を挿入し、タスクの実行可能性を判断するパスに渡します。実行を開始するstartTaskEngineは目標を分解し、その結果が準備された後、Engine.Runを呼び出します。この順序は、プランナーがまだ存在しない目標を読み込む状況を減らすための構造です。モデルを使用した目標分解が結果を生成できない場合、元の目標をそのまま使用する代替パスもあります。 開始・目標分解パス

Engine.Runは、タスクごとに1つのプランナーループと設定された数のワーカー・ループを開始します。基本的な流れは、まず計画する方式です。ただし、seed_first_intentオプションで初期実行タスクを事前に入力した場合、ワーカーがそれを最初に担当し、その後の結果がプランナーを起動する可能性があります。したがって、すべてのタスクが必ず最初のプランナー呼び出しから始まると断定することはできません。 実行エンジン開始

3. プランナーはタスクを作成し、ワーカーは結果を残す

プランナーが作成するintentは、ここでいう「次に実行する具体的なタスク」です。目標がセキュリティヘッダーの点検であれば、「指定された応答のヘッダーを読み込み、確認された項目を記録する」というタスクになるでしょう。目標と実行するタスクを分離しておくことで、全体目標を維持しつつ、観察に応じて次のタスクを変更できます。

Planner.Planは、今回発生した変更、探索グラフの現在の状態、残りの目標とタスクリストをモデル入力として構成します。モデルは公開されたツールを通じて実行するタスクを追加したり、目標達成を示すことができます。人間と対話するMainAgentは観察・ヒント・指示を伝える役割であり、この自律計画の繰り返しはプランナーの責任です。 計画入力とツール構成 · MainAgentの役割

ワーカーは待機中のタスクを取得します。DBのClaimIntentは、状態がopenのノードのみをrunningに変更し、実際に1行が変更されたかを確認します。複数のワーカーが同じ候補を見ても、この状態変更に成功したワーカーのみがタスクを担当するように構成されています。 タスク割り当て · DB状態変更

リポジトリには2つの関係があります。探索グラフは、目標・実行するタスク・観察した事実・発見がどのように繋がったかを記録します。資産グラフは、サービスやエンドポイントなど、何を扱ったかを記録します。探索ノードと資産を接続して、「どのタスクを通じてどの対象からこの観察が得られたか」を追跡します。これはデータ関係をグラフで表現したものであり、別途グラフDBを使用するという意味ではありません。 ノード・接続・資産接続スキーマ

ワーカーの実行が終了すると、結果が保存され、NotifyDoneがプランナーを起動します。発見を登録する際にも別途通知パスがあります。プランナーは複数の変更通知をまとめて一度の計画で処理し、変更がない場合は定期的な確認で再び起動します。再計画は、結果に対する反応と定期的な確認を併用する構造です。 プランナー・ワーカー繰り返し

図1. 韓国語フォークの実行エンジンとワーカーコードに基づいて再構成。計画・実行・観察の関係を単純化しており、実行実証結果ではありません。

4. モデルがツールを選択し、プログラムが実行する

Worker.executeは、担当タスク、関連資産、制約条件、現在の状況をモデル入力として作成します。特に担当タスクはシステムプロンプトに含めることで、長い対話が圧縮されても実行目的を維持しようとする設計です。ツールリストにはグラフ記録ツールやファイル・シェルツールなどが含まれ、設定に応じて追加ツールも組み立てられます。 ワーカー実行構成

ARTEXはnorma v0.4.3 SDKにエージェント実行を委ねます。captureRunSessionがセッションのPromptを駆動し、モデル応答とツール実行イベントを受け取ります。モデル接続部は、選択したモデル・APIアドレス・通信形式で呼び出しを構成します。したがって、ARTEX自体がLLMであるわけではなく、設定されたモデルサービスが判断を生成します。 依存性バージョン · モデル接続 · セッション駆動

SDKで確認した基本の繰り返しは以下の通りです。

1. 現在の対話と利用可能なツールの名前・入力形式をモデルに伝達します。
2. モデルがツール名と引数を返すと、プログラムは登録されたツールを探します。
3. 入力形式・権限・実行前フックを確認した後、実際のツールを呼び出します。
4. 出力やエラーをtool_resultとして対話に追加します。
5. モデルがその結果を読み取り、次の呼び出しまたは終了を選択します。

仮想の例では、HTTP応答を読み取った結果がモデルに戻ります。ヘッダーを確認できた場合、その観察を事実として記録できます。接続に失敗した場合、「点検不可」という結果を持って次の判断をする必要があります。HTTP 200という観察だけで、サービス全体が安全である、あるいは脆弱であるという結論にはなりません。

モデルが返すツール呼び出しは実行リクエストです。実際のシェルコマンドは、SDKのプロセス実行コードが実行環境で実行します。タスクごとのディレクトリを指定することも、ファイルの整理と実行位置に関する設定であり、それ自体がOSレベルの隔離を作成する機能ではありません。

5. 承認ルールと実行環境の境界は一緒に考慮する必要がある

ワーカーセッションはSDK権限モードをModeBypassに設定します。これは、基本的なSDK承認質問を経るとは仮定できない設定です。一方、エンジンはワーカーにARTEXのGuardフックを接続するため、別途の傍受ルールが実行リクエストを処理できます。 権限モード設定 · ワーカーフック接続

Guard.applyInterceptは、対象ツールに対してルールを評価し、allow、deny、askを処理します。askは人間の承認応答を待ちます。ただし、傍受オブジェクトがないか、該当ツールが傍受対象でない場合、このパスではブロックしません。ルールが一致せず、LLM補助審査もオフになっているか接続されていない場合、許可するパスがあります。遮断ルールは、設定と接続状態まで確認して初めて意味があります。 実際の分岐

特に、読み取ったソースのPlanner.Planには、ワーカーのようにGuardフックをオプションに接続するコードが見られない一方で、基本ツールリストにはシェルツールが含まれています。ワーカー承認パスがあるという事実を、すべてのエージェントのすべてのツール呼び出しに同じ統制が適用されるという保証に拡大してはなりません。 役割ごとのツールとフック接続を別途検討する理由です。 プランナーツール・実行オプション

安全な最初の実習は、合成データのみがある専用環境で、所有し許可したHTTPサービス一つを対象に設計できます。必要なモデル通信と実習サービス通信を区別し、残りのアクセスは実行環境で制限します。業務ファイル・ブラウザプロファイル・ホスト制御インターフェースを接続せず、短い時間・呼び出し予算と中断方法をまず定めます。これは今後検証する実習設計であり、今回のコード分析でこのような統制が実際に機能したと主張するものではありません。

図2. 韓国語フォークのGuard分岐とプランナーオプションに基づいて再構成。固定コミットのソース観察であり、実際の遮断・迂回試験は実施していません。

6. 停止理由もステータスとして残す

一時停止は実行コンテキストをキャンセルし、ワーカー・ループが新しいタスクを引き受けないようにします。プランナーは、実行中のタスクを調整するsteer_workと、中断するkill_workも使用できます。全体タスクの終了と個別の実行タスクの終了は別途管理されます。 中断・介入コード

ワーカーの正常終了は一般的にdone、エラーはblocked、ターン数や実行時間予算に達した場合はexhaustedとして記録されます。予算終了時には、シェルツールを隠した最終段階で既に確認した内容を記録するように構成されています。時間を使い果たした状態を目標達成として処理しない区別です。 終了状態分岐 · ワーカー最終化設定

この状態管理がすべての外部副作用を元に戻すという意味ではありません。既に完了したHTTPリクエストやファイル変更はキャンセル信号とは別です。中断機能とともに実行対象・ファイル権限・ネットワーク範囲を小さく設定する理由もここにあります。

7. レポートの「確認」はどのコードから来るのか

実行中、captureRunSessionはツール呼び出し・ツール結果・テキスト・終了・使用量イベントを活動記録に変換します。サーバーはこれを保存し、SSE、つまり接続を維持したままサーバーイベントを送信する方式で画面に伝達します。選択的に残すモデル対話記録とプロキシを通過したHTTP記録は異なる証拠です。プロキシ設定だけで、すべてのツールのすべてのネットワーク通信が記録されるとは保証できません。 活動キャプチャ · 画面イベント送信

結果を読み取る際に最も重要な区別は、実行タスクの完了、目標達成、脆弱性の再現検証です。prove_goalは、指定された目標がこのタスクの目標ノードであるか、証拠が読み取り可能な事実・発見ノードであるかを確認します。その後、証拠と目標を接続し、目標状態をmetに変更します。すべての目標がこの状態になると、タスク完了と判断します。この関数内で証拠の内容を独立して再実行する検証は確認されていません。 目標判定コード

report_findingも同様の注意が必要です。説明には、確認された脆弱性を証拠とともに提出するように記載されています。しかし、記録関数RecordFindingTxは、タスク・探索・実行タスクの所属を確認し、提出された内容で探索ノードをconfirmed状態に保存します。別途のfindingsレコードにはデフォルトのpending状態が使用されます。探索ノードのconfirmedという名前は、この保存パスが脆弱性を再現して真であると判定したという意味ではありません。 提出ツール · 保存トランザクション · 発見テーブル

HTTP証拠の自動接続も設定依存的です。オフになっている場合、証拠参照引数を除外して発見を保存でき、実際の接続がない場合はevidence_status: not_boundを返すパスがあります。 証拠接続分岐

ソースには、発見登録をきっかけに実行記録と証拠を読み取り、詳細レポートを作成するレポーターエージェントを初期構成するパスもあります。このパスはエージェント・ツール・トリガー設定の影響を受けます。一方、Markdownレンダラーは保存された発見と証拠をレポート形式に整形します。レポートを作成することと、証拠を独立して再現・確認することは区別する必要があります。 レポーター構成 · レポートレンダリング

したがって、結果を検討する際には、モデルの結論と実際の要求・応答、正常な対照、再現条件を合わせて読む必要があります。単純なヘッダー欠落のような観察も、その項目が必要な文脈と影響が確認されて初めてセキュリティ上の結論につながります。ARTEXの繰り返し構造は、次の調査方向を作成し、証拠を収集するプロセスを自動化しますが、自動実行と検証された脆弱性はそれぞれの根拠に基づいて評価されるべきです。

この記事の基準は、元の最終確認公開版v0.3.15や保存フォークgasbugs/ARTEXではなく、上記で固定した韓国語フォークです。最小限の比較でもコアエージェント・エンジンファイルが異なっているため、この説明を元のすべてのバージョンにそのまま適用することはできません。該当コミットのルートLICENSEはAGPL v3全文であり、比較した元の版と同一です。韓国語版のユーザー出力は言語指示によって誘導されるため、韓国語の品質まで構造だけで保証されるものでもありません。 LICENSE · 韓国語版説明