ARTEXの「自己改善」はどこまで実装されたか——記憶と証拠をコードで読む

ARTEXを「自分で賢くなるAI」と説明すると、実装の重要な境界が消えてしまう。現在読めるBaaRaiの公開派生版には、状況の変化で計画を作り直し、作業結果をデータベースに残し、過去の教訓を次の作業へ渡す仕組みがある。一方、実行基盤のコードや指示を自動で改変し、その有効性を評価して採用する循環は、プロジェクト自身が未実装と明記する。問うべきは自己改善という名称より、何が記憶され、誰が結果を判定し、次の実行へ何を持ち込めるかである。セキュリティ分野の実装だが、この区別はPhysical AIの上位計画を設計する際にも参考になる。^[2,4]

事件に登場したARTEXと、現在読める派生版を分ける#

2026年10月21日、MicrosoftはStorm-0940によるARTEX利用を含む活動を報告した。この一次報告は、AIを利用する作業基盤が現実の攻撃活動に組み込まれたという観測として重要だ。ただし記事中の二千二百五十超という数字はテナントへのサインイン試行を指し、その数の組織が侵害されたという意味ではない。別集計の失敗認証のピークも、侵入成功の速度へ読み替えることはできない。脅威活動の件数を、そのまま製品の成功率や自己改善の効果に変換してはならない。^[1]

Microsoftは初期の標的化から特権取得まで三時間未満だった複数例も報告するが、AIなしの対照条件や、同じ設定を再現する実験記録ではない。したがって、その所要時間をARTEXが何倍高速化した証拠とすることはできない。まして後から加わった教訓機能が事件を高速化したと結論する根拠はない。本稿がここから扱うのは、その事件の再現ではなく、現在公開されているコードの責任分担と記憶の構造である。^[1,22,23]

分析対象はBaaRai/ARTEXの2026年10月23日のcommit、b3717f7a5fe8d07fcd4fe7167603f314e9b64840に固定した。READMEはAutumn-27/ARTEXの英語派生版と表明するが、元の公開URLは調査時点で取得できず、事件に使われた正確なcommitや改変内容も確認できない。BaaRai版では10月18日にRSI文書、21日に教訓ライブラリが追加されている。以下の機構はこの固定版の説明であり、原版や事件使用版へ自動的にさかのぼらせない。^[2,3,22,23]

この版の本体LICENSEはGNU Affero General Public License Version 3である。コードはGoのbackendを持ち、agent実行の依存名には元のAutumn-27のNormaが残るが、replaceでBaaRai/Normaへ差し替えられている。派生版の名前が似ていても、実際に動く依存や追加機能まで同じとは限らない。今回行ったのは公開ソースの静的読解であり、同梱の実行基盤や対象検証を動かした試験ではない。動作精度や安全性の独自検証を済ませたという主張もしない。^[20,21]

長い会話ではなく、二つのグラフが作業をつなぐ#

中核の設計は、世界についての状態と、その世界を調べている作業の状態を分けることにある。データベースには共有のasset graphと、タスクごとのexploration graphがある。前者が対象資産を表し、後者が目標、実行する意図、観測事実、発見、手掛かり、要約を表す。作業のノードを対象資産へ結び付けるanchorも別に持つ。「何が存在するか」と「何を試して何が分かったか」を分けるので、計画と観測を一つの文章の中で混ぜずに蓄積できる。^[7,10]

探索グラフには、ある目標から作業が生まれた関係、事実がどの作業から得られたか、証拠が何を支持するかといった辺を記録する。これを単に会話履歴の要約と呼ぶと、構造の役割を見落とす。Plannerは更新された状態を読み、次に行うintentを作る。Workerは一つのintentを担当し、成果を状態へ書き戻して終了する。次の方向を決める役と、一件の作業を遂行する役を分離することで、判断をやり直す入口を明確にしている。^[6,7,9,10]

複数Workerが同じ仕事を同時に拾わないための処理も、LLMの会話任せではない。ClaimIntentは状態がopenの行だけをrunningへ更新し、更新できた行が一つのとき取得成功とする。二つのWorkerが同じintentを見ていても、データベースの条件付き更新が所有権を裁く。多エージェントと呼ばれる部分の足元には、このような通常の並行処理の実装がある。モデルが協調すると説明するだけでは分からない、実行責任の具体的な所在だ。^[8]

状態が変わるたびに高価な再計画を呼ぶわけでもない。Engineは短時間に届く通知を800ミリ秒の幅でまとめ、定期的な監督も組み合わせる。この固定版でheartbeatの下限かつ標準は600秒である。通知を受けた計画更新と、しばらく変化がなくても状況を見直す監督を組み合わせる構成で、すべてを一定間隔で繰り返すだけのloopとは異なる。ただしこの時間尺度は作業計画のものであり、物理機械の制御周期を保証するものではない。^[6]

途中の方向修正にはintentごとのFIFO queueが使われる。そこへ置いた方針を、WorkerのPreToolUseというhookが次のtool呼び出し前に読み、呼び出しを止めてモデルへ返す。これによって新しい情報を受けたWorkerが考え直せる。介入できるのはtoolの境界であり、すでに外部で進行している処理を任意の瞬間に取り消したり、起きた作用を巻き戻したりする機能ではない。停止という言葉の意味も、実行のどの地点を指すかで変わる。^[6,9]

この構成をPhysical AIへつなぐなら、環境モデルと作業仮説を分け、部品の状態と、それをどう確かめたかを別に保持する発想として読むのがよい。これは筆者の設計上の類推で、ARTEXがロボットで実証されたという意味ではない。DBが仕事の重複を防いでも、二本の腕が接触しない保証は生まれない。ツール境界での修正も、接触力の異常や人の接近に応じた高速停止の代わりにはならず、物理側の制御と停止系は別の責任として残る。^[6,7,8]

作業中の記憶と、次のタスクへ渡す教訓は別の機構だ#

記憶は一種類ではない。PlannerのTodoは起床をまたいで共有されるが、WorkerのTodoはその実行に限られる。一方、intentごとに決まるsession識別子を使い、停止や予算切れの後にも会話記録を再利用できる。何を今から行うかという短期の管理と、何を考え試したかという会話の継続を分けている。情報が残るからといって、それがすべて次のタスクにも使われたり、モデルの重みに変換されたりするわけではない。^[9,10]

探索が進むと、全ノードを毎回文脈へ入れる費用が大きくなる。coldgraph.goは活動のないfactや完了済みintentを圧縮し、goalやfindingなどはその対象から外す。非活動を数える単位は秒ではなくPlannerのroundで、既定値は六roundだ。まとめた情報にはメンバーやanchorの内容versionを含む署名を付け、内容が変われば古い要約を使い続けないようにする。これは注意を向ける情報量と鮮度を管理する実装であり、新しい能力を重みに学習する機構ではない。^[11]

タスクをまたぐlessonは別経路で作る。タスク終了時に呼ばれるExtractLessonsForTaskは、発見のstatusと最新の再検証結果を読み、規則に従ってpositive、negative、cautionを抽出する。confirmedやresolvedなどを肯定側、false positiveやduplicateなどを否定側へ分類し、再検証でfixedやinconclusiveなら注意を残す。ここにある抽出は、LLMが自由に研究を総括する処理ではなく、既存の管理状態を使う規則である。元の判定が誤っていれば、整った教訓として保存されても誤りは消えない。^[5,18]

教訓には適用の手掛かり、行動、元の識別子が必要で、欠けていれば採用しない。内容からハッシュを作って重複をまとめ、根拠もlessonと出典の組み合わせで管理する。同じ結果を繰り返し抽出して、支持件数だけが膨らむことを防ぐ工夫だ。ただしsupportは保存された根拠行の数であって、その教訓を使うと成績が上がる確率ではない。重複排除と効果測定は役割が違う。過去に何度現れたかを数えても、将来どの条件で役立つかは別に試す必要がある。^[5,7,17]

実行時の選択はoff、shadow、injectの三つに分かれ、未指定ならoffとなる。shadowは検索と利用予定の記録にとどまり、injectで初めて過去の結果をPlannerとWorkerの入力へ付け足す。最大八件に制限する一方、候補statusのままでも選択対象になり、retiredだけが除外される。したがって「正式採用されるまでagentには見えない」と説明するのは誤りだ。教訓の抽出、検索、文脈への投入、効果を確認した採用は、同じ操作ではない。^[5,16]

表示時には制御文字を除き、一行化し、長さを制限したうえで、過去の結果であって指示ではないと前置きする。ただしこれは外から来た文字列を扱う防御方針であり、モデルが必ずその区別を守る証明ではない。描画上限の処理はbyteを数えるため、日本語で同数の文字を入れられるとも限らない。記憶を増やす設計では、保存容量だけでなく、情報をどの優先順位でモデルに見せ、何を命令として扱わせないかも検討対象になる。^[5,16]

証拠を壊さず保存しても、結論の正しさは別に検証する#

Workerの指示には、観測した事実と推論を分け、製品versionの一致だけで確定した発見にしないという規律がある。報告前には、到達可能性、成立の前提、後段の制御、対象範囲、別の説明を検討するよう求める。反証を作業へ組み込む姿勢は重要だが、この五軸は主にpromptに置かれた指示である。独立した決定器が毎回すべてを検査して合格を保証する仕組みと、同じ強さではない。^[9]

専用のretesterは、新しい探索と再検証を分ける。結果をreproduced、fixed、inconclusiveに分類し、一度うまく再現できなかっただけで修正済みにしないよう指示する。fixedと判断するには、以前の前提との比較や正常な対照の成立を求める。ここでも評価者の判断は残るが、再現できないことと問題が解消したことの間に、判断保留の置き場を用意している。証拠が足りないときに無理に二択へ落とさない設計である。^[12]

証拠を保存する層は、さらに別の仕事をする。evidence/store.goは通信記録などを一時的なtrafficから独立させ、SHA-256と長さを確認し、一時領域から永続化した内容参照のblobへ移す。DBのtransactionも使い、報告が参照する証拠を後からたどれるようにする。これが守るのは、受け取った証拠が途中で欠けたり別物へ置き換わったりしないことだ。その記録が結論を十分に支持するかは、ハッシュだけでは分からない。^[13]

報告文と証拠の版も結び付ける。報告を作るagentは実際の記録を読み、その時点のevidence_versionを使って更新する。DB側は指定versionの整合を確認するので、根拠が変わった後に古い読み取りを前提とした報告を置く危険を抑える。ただし証拠を取得できない場合の文章報告も可能で、すべての発見に同じ種類の通信証拠が必須ではない。証拠の形式が揃うことと、報告に至る全経路で実証が揃うことを区別しなければならない。^[14,15]

この差はロボットの検査記録にも通じる、というのが筆者の見方だ。カメラ画像の保存時刻とhashが正しくても、その画像だけで部品が奥まで入ったとは限らない。古い観測を参照していないかという管理と、そもそも観測が成功条件を測れているかという検証の両方が必要になる。ARTEXの証拠保持は前者の参考になるが、後者を自動解決するものではない。ログが豊富であることを、結論が正確であることの代わりにしない姿勢が重要だ。^[9,12,13,15]

再帰的改善には、記憶の追加を超えた採用の証拠が要る#

BaaRai版のRSI文書は、タスク内の再計画、タスク間の教訓、promptやskillなど実行基盤の改善を異なるloopとして整理する。現在のコードで追えるのは再計画と、教訓の抽出・任意の入力追加までだ。実行基盤を探索して自動採用することや、コードが自己改変することは未実装と明記する。文書冒頭のmeasurementとshadow memoryという保守的な説明に加え、現行コードにはinjectもある。文書の分類を読むだけでなく、どこまで入力を変える処理が存在するかを確認する必要がある。^[4,5,16]

将来の実行基盤改良については、採用条件が書かれている。実タスクで得た着想は候補の提案には使うが、そのまま採用の証拠にはしない。未見のbenchmark、同じモデル・seed・予算でのbaseline比較、独立したjudge、変更ごとのowner承認、rollback、編集してはいけない安全面を要求する。これはすでに自動化された保証ではなく、今後その機能を加える際の契約だ。自己改善という名前の下でも、変更権限と採用権限を分ける意図が読み取れる。^[4]

評価用runnerの存在は確認できる。対象とjudgeに同じモデルを指定するのを拒否する処理や、反証を求めるgrader、分母や信頼区間を扱うコードがある。ただし同モデル拒否には明示的なoverrideがあり、モデル名の比較だけで独立性を完全に保証するわけでもない。さらに評価装置があることと、教訓機能によって精度やtoken効率が改善した実測結果があることは別だ。今回確認した一次資料から、shadowとinjectの対応比較や、タスク間転移の改善率は示せない。^[19]

改善器が改善されたと言うためには、記憶を増やした後に同じ仕事がうまくいっただけでは足りない。新しいpromptや道具の説明が、独立した課題群でも同じ予算でより良い判断を生み、誤りや退行を増やしていないことを測る必要がある。これはRSI文書の採用契約を踏まえた筆者の評価基準である。保存したlessonの数やsupport件数は、その試験に使う候補の管理には役立つが、改善の証明そのものにはならない。^[4,5,19]

Physical AIの技術者が持ち帰れるのは、事件の速度でも、ロボットへそのまま移せる能力でもない。環境の状態と探索履歴を分け、作業の所有権をDBで裁き、観測と報告のversionを合わせ、再利用する知識に出典を付けるという設計である。一方、tool境界までしか介入できない上位agentに、物理側の不可逆な動作や高速停止まで任せることは、このコードの証拠からは導けない。高位計画が何を知り、下位実行器が何を保証するかを分けるための参考として読むべきだ。^{[6,7,8,13,15]}

ARTEXの公開派生版が示すのは、記憶と証拠を持つ作業システムを、自然言語の会話以外の仕組みで支える方法である。同時に、教訓を入力へ追加すること、教訓が有効だと検証すること、改善器自身を変更して採用することの距離も明らかにする。今後の評価で見るべきものは、その距離を何件の独立試験とどんな採用手続きで埋めたかだろう。自己改善の実体は、増えた記憶の量ではなく、変更された部分と、その変更を支える証拠の対応に現れる。^[4,5,17,19]

関連する技術解説：ASPIREとENPIREのロボット自己改善ループ