ARTEX（アーテックス）は、大規模言語モデル（LLM）を接続し、セキュリティ点検の計画とツール実行を調整する公開ソフトウェアです。モデル自体の名前ではなく、モデル・実行ツール・作業記録をまとめるシステムです。最近、金融機関の個人情報流出報道に登場し関心が高まりましたが、関連する痕跡が発見されたという事実と、攻撃全体をAIが単独で実行したという主張は区別する必要があります。
導入する際も同様の区別が必要です。セキュリティ分析を支援するソフトウェアであっても、ファイルを読み込み、コマンドを実行し、外部モデルに内容を送信する場合、使用する組織は新たなリスクを負う可能性があります。この記事は、公開された事件資料と公式リポジトリを読み解き、ARTEXの構造、開発履歴、内部検討時のリスク、外部評価で守るべき境界を説明します。インストールや実行による性能測定を行った使用レビューではありません。
代表イメージ：AI生成概念図。実際のARTEX画面や金融機関システムを再現したものではありません。
1. 金融機関事件でどこまで確認されたか
事件の存在、ARTEX関連の観測、使用痕跡に関する取材、最終的な技術的立証は、それぞれ異なる階層です。資料が公開された日付も合わせて読むことで、初期報道と後続報道が衝突しているように見える問題を減らすことができます。
金融委員会は2026年10月2日の資料で、新韓銀行の情報流出事故に続き、国民銀行などで追加被害が発生し、通報後に現場調査と攻撃IP・種類の共有を進めていると発表しました。外部に露出したサービス全体を把握し、認証・アクセス制御を点検するよう指示しました。この公式資料には、ARTEXという名前や完全自律AI攻撃という判断はありません。金融委員会発表
10月2日、ソウル経済は、攻撃に使われたと推定されるサーバーのHTMLタイトルからARTEXの中国語侵入テストコンソールの標識が観測されたと報じました。当時の記事には、実際に攻撃ツールとして使用されたかは確認されていないという但し書きがあります。これは、関連環境が存在した可能性を示す観測として読むのが適切です。ソウル経済初期報道
10月3日、ヘラルド経済は、金融保安院関係者を引用し、新韓銀行のログと攻撃IPの逆追跡でARTEXの活用痕跡を確認したと伝えました。同じ関係者は、人の介入なしにAIが単独で攻撃したわけではないと説明しました。したがって、後続取材を無視して使用根拠が全くないと書くのも不正確です。ヘラルド経済後続取材
ただし、公開された生ログや最終技術報告書を確保し、独立して再現・検証したわけではありません。どのバージョンとモデルが使用されたのか、どの機能がどの銀行の事件にどれだけ関与したのか、自動化の割合がどの程度だったのかは、この資料だけでは確定できません。ツールの中国語画面や開発アカウントで攻撃者の国籍を推定する根拠も十分ではありません。
| 資料 | 確認または伝達内容 | この資料で確定できない内容 |
| — | — | — |
| 金融委員会 10月2日発表 | 金融機関侵害、現場調査、脅威情報共有とアクセス制御点検 | ARTEXの関与とAI自動化の程度 |
| ソウル経済 10月2日報道 | 推定サーバーのARTEXコンソール標識観測 | 実際の攻撃過程での役割 |
| ヘラルド経済 10月3日取材 | 金融保安院関係者が活用痕跡確認を説明 | 生証拠の独立検証、使用モデルと全体自動化 |
この区別は事件を矮小化するためではありません。何を防御すべきかを定めるには、確認された被害とツールに関する推定を混同しないようにする必要があります。実際の要求に対するサーバー側のアクセス制御と外部サービスリストの点検は、特定のAIツールの関与の有無にかかわらず必要です。
2. モデル一つではなく、複数の構成要素を接続したシステム
この記事で分析するプロジェクトは、GitHubのAutumn-27/ARTEXです。公式リポジトリは、Goバックエンド、Next.js画面、PostgreSQLデータベースと複数のLLMエージェントを組み合わせたシステムとして紹介しています。エージェントとは、モデルの回答を作業ツール呼び出しと結びつけるプログラムです。公式リポジトリ
大きな構造は、計画を立てる部分、作業を実行する部分、結果を保存する部分、人が検討する部分と理解できます。計画エージェントは次に確認するべきことを分割し、実行エージェントは担当する作業をツールで処理します。画面は進行状況と結果を表示します。「自動化」という言葉は、この繰り返しを意味し、人の目標指定・設定・検討までがなくなるという意味ではありません。
記録は二つの観点に分かれます。資産グラフは、どのような対象とサービスがあるかを示す接続リストであり、探索グラフは、今回の作業でどのような思考・観測・発見が続いたかを示す記録です。対象を知ることと、その対象について何を確認したかを分離して管理します。二つのグラフは接続されますが、同じデータ構造ではありません。
公式文書に基づいて再構成した概念図。READMEのシステム構造と実行エージェントソースを根拠に単純化しました。攻撃経路を提示する図ではありません。
公開ソースの実行エージェントは、ファイル読み書き・編集とBashのようなツールを構成します。Bashはオペレーティングシステムコマンドを実行する通路です。各作業の専用ディレクトリを作成しますが、ディレクトリを分けるだけではプロセスが他のファイルやネットワークにアクセスできないように防ぐことはできません。このため、実行環境の権限が重要な検討対象です。worker.go
3. 公開履歴に見る発展とセキュリティ修正
GitHubメタデータ上、このリポジトリの作成時刻は2026年7月26日であり、リリースリストにも同日v0.1.0があります。これは現在の公開リポジトリと配布記録の開始点であり、開発着手日を立証する資料ではありません。「大会優勝プロジェクト」という説明はリポジトリの自己紹介にあり、この記事では別途大会結果の原文まで検証していません。リポジトリメタデータ・リリースリスト
調査時点の最新正式リリースは、2026年9月24日に公開されたv0.3.14です。分析したmainブランチはコミットb55ceb1で、以降の変更を含みます。したがって、mainの現在の動作をv0.3.14配布版の動作としてそのまま説明してはなりません。実際の検討では、リリース・コミット・イメージ識別子を固定し、該当バージョンの設定を確認する必要があります。
変更履歴には、安全制御がなぜ継続的に検証されるべきかを示す項目があります。以下の内容はプロジェクトが記録した過去の問題と修正であり、現在すべてのバージョンが脆弱であるとか、事件の原因がこれであったという主張として読んではいけません。公式CHANGELOG
| バージョン・日付 | 履歴に記録された変更 | 検討すべき質問 |
| — | — | — |
| v0.3.10 · 9月13日 | 他の作業の資産が対象に混ざる照会問題修正 | 作業別対象分離が実際に維持されるか？ |
| v0.3.11 · 9月15日 | モデル審査結果のコードブロック処理補完 | 審査結果を解釈できない場合、どのように処理するか？ |
| v0.3.12 · 9月17日 | 記録プロキシの基本アドレスをlocalhostに制限 | 画面とプロキシがどのネットワークに露出されるか？ |
| v0.3.13 · 9月19日 | 審査出力の途切れによる誤った許可経路緩和、作業別許可・ブロック規則追加 | 失敗時のブロックと対象制限を独立して検証するか？ |
核心は修正項目の数ではありません。モデル出力の解釈、作業範囲の照会、ネットワーク露出など、異なる階層で問題が発生する可能性があります。アップデートは必要な改善ですが、一度アップデートしたという事実が、全体実行環境の安全性を保証するものではありません。
4. 内部で使用すると組織も攻撃対象になりうる
セキュリティツールを導入するリスクは、特定のプロジェクトにバックドアがあるという意味とは異なります。今回の読み取り分析で悪意のあるバックドアを確認したわけではありません。リスクは、実行権限、外部接続、記録の機密性、サプライチェーンを合わせて検討すると具体的に明らかになります。
インストール経路とサプライチェーン
サプライチェーンとは、プログラムだけでなく、依存関係・コンテナ・アップデートなど、実行ファイルを取得する経路を意味します。公式構成は、外部コンテナイメージとPostgreSQLを使用し、ローカルデータおよびスキルディレクトリをコンテナに接続します。基本イメージタグが変わると、同じ設定を再利用しても実行ファイルが異なる可能性があります。docker-compose.yml
学習検討環境でも、出所・バージョン・ハッシュを確認し、検討していないインストールスクリプトを普段の業務機器で直接実行しないことが推奨されます。組織のソースリポジトリ、SSHキー、クラウド資格情報、ブラウザセッションを学習用実行環境と共有しないようにすべきです。これはARTEXがそのような情報を盗むという主張ではなく、改ざんされたり過度な権限を与えられた実行ファイルの被害範囲を減らす一般的な制御です。
モデル接続と詳細記録
モデル接続ソースは、APIキーとユーザー指定APIアドレス・プロキシ設定を扱います。外部モデルを接続すると、リクエストに入力された内容が選択されたプロバイダや中継地点に転送される可能性があります。どのプロバイダとアドレスを承認するか、必要な内容をどれだけ減らすか、保管ポリシーが何かを確認する必要があります。ソースに接続機能があるという事実だけで、特定のインストールの実際の転送内容を確定することはできません。provider.go
詳細LLM記録機能は、設定に応じてリクエスト・応答と生通信本文をデータベースに保存します。本文記録とトークン使用量記録は別です。実行中に画面に表示されない情報も記録に残る可能性があるため、保存期間、アクセス権限、削除・バックアップポリシーを別途定める必要があります。llmrec.go
実際の顧客応答、運用ログ、契約資料、アカウントとキーを入れずに合成資料のみを使用する理由がここにあります。記録ボタンをオフにするだけで外部モデルに内容が送信されなくなるわけではありません。外部転送とローカル保存は、それぞれ異なる確認項目です。
ツール権限とプロンプトインジェクション
プロンプトインジェクションは、読み込むべき資料内の文章をエージェントへのコマンドのように受け取らせる危険性です。公開ページやリポジトリの内容、ツール応答が作業資料である状況では特に注意が必要です。この部分はARTEXで再現された脆弱性報告ではなく、外部資料を読み込み、実際のツールを呼び出す構造で考慮すべき脅威モデルです。
例えば、学習資料に実行を誘導する文章が混ざっていても、その文章は人の承認や組織ポリシーを代替することはできません。ファイル・プロセス・ネットワーク権限を外部から制限し、実行前の承認と記録を検証する必要があります。プロンプトに注意事項を書き留めることは必要な説明ですが、オペレーティングシステムの権限境界を作成することはできません。
ウェブ画面とネットワーク境界
Composeの例では、画面/APIポートとlocalhostに制限されたプロキシポートを別途指定します。画面/APIの露出範囲は、ホストファイアウォールとデプロイ設定まで確認する必要があります。コンテナを使用しても、基本的に外部通信が遮断されたり、組織ネットワークから隔離されたりするわけではありません。学習用ネットワークは業務ネットワークと分離し、承認されたモデル接続以外の通信を制限できるようにする必要があります。公式Compose設定
5. 承認画面があってもすべての行動が自動的に遮断されるわけではない
分析したmainソースには、ツール呼び出しを許可・遮断・人に要求する規則があります。しかし、規則を適用するツールのリストと審査機能の設定によって動作が異なります。規則に合致しない呼び出しでモデル審査がオフになっているか接続されていない場合、許可経路があり、モデルの失敗や解釈不能な結果は設定された失敗ポリシーに従います。guard.go・intercept.go
したがって、「承認機能があるから安全だ」という確認で終わらせてはいけません。どのような呼び出しが審査対象なのか、承認待機中に実際の実行が停止するのか、審査失敗やタイムアウト時には何が起こるのか、中断後すでに開始した作業はどのように処理されるのかを隔離環境で検証する必要があります。本文では、審査機能をオフにする方法や迂回する方法は扱いません。
公式コードに基づいて再構成した運用検討図。承認ソース、モデル接続、記録保存が根拠です。すべての制御がデフォルトで提供・有効化されるという意味ではありません。
組織の判断基準は明確にすることができます。業務機器や運用アカウント接続を要求する検証であれば範囲を再度縮小し、承認されていない宛先通信を阻止できない場合は実行検討を保留します。実際の顧客データが必要な設計であれば、合成データに置き換えられるかまず確認します。セキュリティツールの利便性と、そのツールを使用する環境の安全性は別途評価する必要があります。
6. 外部の模擬ハッキングにはどのような方法で活用できるか
ここでは、ツールの使用制限がまず重要です。READMEの著者宣言は、個人学習・コード研究・ローカル隔離原理検証のみを許可範囲として説明しています。資産を所有しているか許可を得ている場合でも、ウェブサイト・オンラインサービス・ネットワークシステムに実際のテストを実行すること、および実戦侵入テスト・運用環境での使用を禁止すると明記しています。したがって、この記事はARTEXを外部の実サービスに投入する手順を推奨しません。README使用制限
リポジトリライセンスはAGPL-3.0であり、READMEもオープンソースライセンス自体と別途の著者使用宣言を区別しています。異なる文書を一つの文章にまとめて、商業的利用がすべて禁止されるとか、書面許可さえあれば問題ないとか結論付けてはなりません。別途宣言の法的効力や適用関係は、この技術記事が判断する範囲ではありません。組織の法務・セキュリティ検討で両文書を合わせて確認する必要があります。LICENSE原文
外部評価業務には、ARTEXの構造から得られる一般的な運用原則を適用できます。実際の使用は、該当目的を許可するツールと契約を別途選択した上で進める必要があります。以下はツールとは無関係な評価計画の例であり、ARTEXを実対象に実行する指針ではありません。
- 書面で範囲を定める。資産所有者の承認、対象リスト、時間、許可活動と除外活動、担当者、中断権限を文書で固定します。契約顧客の運用データをモデルに送信する権限まで自動的に含まれるとは見なしません。
- 環境を分離する。業務用アカウントと機器を再利用せず、承認されたテストアカウント・合成資料・別途ワークスペースを使用します。不要なファイルと宛先にはアクセスできないようにします。
- 実行前に人が判断する。モデルの提案と実際のツール実行を分けます。範囲と影響を検討した行動のみを進め、失敗・不確実な結果は中断または人の検討に回します。
- 証拠を最小限に留める。時間、対象、承認根拠、観測結果、修正後の再確認結果を連結します。報告書に元の個人情報や不要な通信内容を添付しません。
- 中断条件を先に定める。範囲外の対象、実際の個人情報露出、承認されていない通信、サービス異常、ログ欠落が確認されたら停止します。結果は検証済み・未確認・再確認必要に分け、担当者に伝達します。
ARTEX自体を学習する場合は、ローカル隔離環境で合成資産と記録を使用する範囲に制限します。承認待機、範囲外要求遮断、記録保存・削除、中断動作など、運用境界を確認することが学習目標となりえます。機能を学習するという理由で、実際の金融機関や顧客のシステムを対象に試験する必要はありません。
7. 金融機関防御でまず変わるべきこと
特定のツールの名前をブロックリストに追加するだけで問題を解決するのは困難です。人が使おうと自動化ツールが使おうと、サーバーは要求者が該当情報にアクセスする資格があるかを判断する必要があります。認証は誰であるかを確認する過程であり、認可はその人が特定の情報や機能を使用できるかを確認する過程です。
金融委員会が指示した外部サービス全数把握とアクセス制御点検は、この基本的な問題と関連しています。従業員・協力会社用サービスであっても、外部からアクセスできる場合は管理対象です。正常なログインがあったという事実だけで、すべてのデータ照会を許可してはならず、不要な応答情報と異常な照会を合わせて検討する必要があります。これは個別事件の最終原因を断定する説明ではなく、公開対応方向を実務的な観点から解釈したものです。金融委員会対応方向
ARTEXの公開構造は、AIが繰り返し作業の計画と実行を接続できることを示しています。しかし、今回の事件で正確にどのような機能が作動したかとは別に、防御組織は外部資産のアクセス制御と自動化された要求の観測能力を強化する必要があります。ツールを内部で研究する組織は、モデルデータと実行権限を減らし、人の承認と独立した隔離を合わせて検証する必要があります。この二つの方向を区別すれば、事件報道を誇張することなく、実際の備えに必要な質問を作成できます。
参考資料と確認範囲
- 金融委員会、金融機関侵害脅威対応発表：事件対応と外部システム点検の公式根拠。
- ソウル経済、10月2日ARTEXコンソール標識報道・ヘラルド経済、10月3日使用痕跡取材：観測と後続取材を日付別に区分。
- Autumn-27/ARTEX・リリース・固定コミットCHANGELOG：構造・配布履歴・修正の文脈。
- 固定コミットのソースツリー：ファイル・ツール・モデル・承認・記録接続に関する読み取り分析。事件証拠を再現した資料ではない。
- AGPL-3.0 LICENSE：READMEの別途使用宣言と合わせて検討する原文。
公式資料と公開リポジトリのみを使用しました。実際の内部ログ・顧客帰属資料・攻撃コマンド・侵害手順は含まれていません。リリースとmainブランチを区別し、後続調査で事件のツール関与範囲が変更された場合、該当説明も更新する必要があります。
コメントを残す