ARTEX（アーテックス）は、大規模言語モデルを接続し、セキュリティ検査の計画とツール実行を調整するソフトウェアです。2026年10月8日、作者はアップデートの中止、クローズドソースへの移行、および今後の外部配布とメンテナンスサポートの中止を発表しました。公開リポジトリと配布イメージが引き続き利用可能であるという前提で作成されたインストールガイドは、適用条件を再確認する必要があります。
すでにソースや公開されているアーカイブリポジトリを確保している場合でも、すぐにインストールパスを変更することは困難です。取得したファイルがどの時点のものであり、どのような権利と条件が付随しているのか、誰が変更し維持するのかをまず確認する必要があります。この記事では、発表の意味とアクセス確認の結果を共有し、既存のインストールガイドの読み方とアーカイブ版の確認手順を整理します。
確認日は2026年10月9日です。本記事は公式発表と公開リポジトリ情報を検討したものであり、新しいアーカイブ版のインストール成功や実際のセキュリティ検査性能を測定したレビューではありません。
代表画像：AI生成概念図。実際のレポジトリ画面や実行環境を再現したものではありません。
1. 作者の発表から確認できる範囲
作者のGitHubプロフィールにある10月8日の発表は、悪用事例を背景に説明し、プロジェクトをこれ以上更新せず、クローズドソースに移行すると伝えています。その後、外部に新しいバージョンを配布したり、メンテナンスサポートを提供しないという内容も含まれています。ここでの悪用と開発趣旨に関する説明は、作者が表明した立場として読むべきです。特定の事件の全経緯や法的責任を独立して立証する資料ではありません。 作者の発表
この決定によって変わるのは、今後公式経路で期待できる公開開発とサポートです。過去に受け取ったすべてのファイルが同時に消滅したとか、すでに存在するコピーが自動的に実行不可能になったという意味まで含んでいるわけではありません。逆に、古いコピーが残っているという理由で公式メンテナンスが継続されると見ることもできません。
実務的には、新しい問題が発生した際に誰が確認し修正するのかが重要な問いとなります。公開メンテナンスが中断されたプロジェクトを継続して検討するには、ユーザーが確保した特定のバージョンを基準に、依存関係、変更履歴、実行条件を直接管理できる必要があります。これは、当該バージョンに新しい脆弱性が発見されたという主張ではなく、今後の検討責任とサポート経路が変わったという判断です。
2. 発表とダウンロードエラーは異なる証拠である
発表には今後の運営方針が記載されています。HTTP応答は、特定のURLに特定の条件でアクセスした際の結果です。両方を合わせて見ると現状を理解するのに役立ちますが、一方がもう一方のすべての原因を説明するわけではありません。
10月9日午前9時10分頃（韓国時間）のアクセス確認では、オリジナルリポジトリと確認対象のリリースパス、ARM64 ZIPダウンロードがHTTP 404を返しました。同じ確認で、公式Dockerイメージの特定のARM64マニフェストに対する匿名照会・プル確認はHTTP 401で終了しました。下記の表は確認したパスの結果であり、全バージョン・全プラットフォームに対する一括判定ではありません。
したがって、現時点で言える範囲は、既存の公式ダウンロードパスをそのまま辿ってインストールできるとは確認されていないということです。エラーに遭遇したからといって、出所の不明なZIPや代替イメージをすぐに使用するよりも、必要な配布物と確認可能な根拠をまず整理する方が良いでしょう。
公式文書を基に再構成。作者の発表とRegistry認証フローを根拠に、方針と応答観測を区別した概念図です。アクセス観測がすべての配布物の状態を保証するものではありません。
3. 既存の概要記事とインストールガイドはどのように読むべきか
以前公開したARTEX概要と導入境界は、当時の公開資料を基にシステムの構成とセキュリティ検討項目を説明しました。本記事は、事件分析を再確定したり、ツールの性能を評価する後続記事ではなく、公開配布とメンテナンス条件が変更された状況を扱います。以前の記事の確認日と今回の発表日を合わせて読むことで、説明対象と時点を区別できます。
10月5日を基準に準備されたインストールガイドは、当時の公式リポジトリの特定のコミットとCompose構成を根拠としていました。Composeは複数のコンテナの実行設定を一つのファイルにまとめるツールです。当該ガイドのソース固定とイメージ識別値の記録は依然として有用な検討方法ですが、オリジナルリポジトリの複製とイメージダウンロードが現在も可能であるという前提は別途確認する必要があります。
既存のインストールガイドを適用する前には、オリジナルダウンロードアドレス、イメージプロバイダー、使用するCPUプラットフォーム、および必要なバージョンから再確認する必要があります。特定の時点の設定を対照したガイドと、現在の環境でインストールに成功したという記録を区別し、新しいアーカイブ版を使用する場合は、そのアーカイブ版の条件に合わせて検討する必要があります。
ローカルにソースフォルダが残っていても、実行準備が完了したわけではありません。コンテナイメージ、言語パッケージ、データベース、ビルドツールが外部から必要となる場合があります。逆に、イメージが残っていても、どのようなソースと設定で作成されたのかが分からなければ、同じプログラムであると判断することは困難です。ソースの保存、ビルド可能性、起動成功、機能確認はそれぞれ異なる段階です。
4. 公開アーカイブリポジトリを見つけてもオリジナルが復旧したわけではない
フォークは、他のリポジトリから分岐したコピーを意味します。実際には、GitHubのフォーク機能で接続されたリポジトリもあれば、別途リポジトリに履歴を移して保存されたケースもあります。名前が同じであるという事実よりも、取得した時点とそれ以降の変更が重要です。
10月9日の公開GitHub API照会では、次の3箇所にアクセスできました。これらは調査候補リストであり、安全性やインストール成功を検証した推奨リストではありません。リポジリページとデフォルトブランチは今後変更される可能性があるため、検討時にはコミットも合わせて記録する必要があります。
[WRIMO_MD_TABLE_1]2つの候補は照会当時APIで正式なフォークとして表示されず、archiveproject候補はフォークとして表示されました。この表示はGitHubのリポジトリ接続関係に関する情報です。コードのオリジナル性や悪意のある変更の有無を代わりに確認する表示ではありません。 [公開API: mhtsec · Hinln · archiveproject
例えば、READMEだけが変更されたアーカイブ版と、自動更新アドレスが変更されたアーカイブ版では、検討すべき範囲が異なります。後者の場合、インストール後に新しい実行ファイルをどこから取得するのかも確認する必要があります。オリジナルと比較する基準ファイルがない場合、「オリジナルと同一」と書くよりも、確保したコミットと比較可能なファイルの範囲を記録すべきです。この記事では、3つの候補全体のコードレビューやインストール検証が完了したとは主張しません。
今回の確認過程では、mhtsecアーカイブ版を起点とした保管用公開フォークも準備しました。オリジナルv0.3.15コミットe6ec56999175509551a1e43a3ee3b053d0941bd9とタグを保存した資料です。履歴が残っているという事実は、新しいインストールや機能検証の成功とは別です。インストール自体はまだ完了していません。
5. 韓国語代替候補artex-koは何が違うのか
韓国語の画面と結果を希望する場合は、コミュニティローカライズプロジェクトjiwoochris/artex-koを検討できます。保管用フォークがオリジナル履歴の保存に焦点を当てているのに対し、artex-koは画面・文書・ユーザーに見える出力の韓国語化を追加した版です。原著者の公式後続バージョンや安全性が検証された代替品として紹介するものではありません。
確認したコードは、基本画面言語をkoに設定し、韓国語と中国語のメッセージファイルを分離しています。エージェントプロンプトには、ユーザーに見える自然言語を韓国語で書くようにするlangDirective()指示が追加されています。内部ガイドライン、コード、URL、原文技術資料をすべて翻訳する方式ではありません。コードで言語指示を確認したという事実と、すべてのモデルが常に韓国語で正確に答えるという保証は異なります。 画面言語設定 · 出力言語指示コード
検討した韓国語版コミットは9e1b227d73a6881c1455b0e5ee0595e669474ed2です。共に保存された上流変更履歴には、0.3.14とそれ以降の未リリース変更が記録されています。これをオリジナルv0.3.15と同一のコードであると断定する根拠としては使用しません。正確な基盤は、使用するコミットと上流資料の比較範囲で確認する必要があります。 上流変更履歴アーカイブ版
現在のREADMEは、デフォルトのComposeがオリジナルイメージを参照しているためクイックスタートに問題があり、韓国語版Dockerイメージの配布は準備中であると案内しています。ソースビルドパスの動作確認はリポジトリ運営者の説明であり、この記事で再現したインストール結果ではありません。したがって、韓国語版を選択しても、まず実行物を確保する経路から確認する必要があります。 韓国語版README
ライセンスはAGPL-3.0と表示されており、変更履歴とメンテナンス文書も提供されています。これらの資料の存在が、長期サポートの約束や独立したセキュリティ検証を代わりにするものではありません。韓国語化に伴うモデル応答・権限・外部転送・更新経路は、選択したバージョンで別途検討する必要があります。本記事ではartex-koを実際にインストールしたり実行したりしていません。 LICENSE · 韓国語版変更履歴
6. インストール前に固定すべきこと：コミット、ファイル、イメージ、条件
コミットは、Gitが特定の時点のファイル状態を識別する値です。ブランチ名は次の修正で指し示す位置が変わる可能性があるため、検討するソースはリポジトリアドレスと完全なコミット識別値をペアで記録することをお勧めします。オリジナルから確保した資料がある場合は、基準コミットとの変更リストを確認し、ファイル名だけが同じコピーで比較を代用しないでください。
確認手順は次のように分けられます。
- 出所と範囲：どのリポジトリからいつ取得したのか、どのコミットなのか、履歴を含むアーカイブなのか、ソースバンドルだけなのかを記録します。
- 変更点：READMEだけでなく、Dockerfile・Compose・依存関係・モデル接続・更新経路・ツール権限関連ファイルを確認します。ファイル名と実際の変更内容を合わせて読みます。
- 配布物接続：イメージと実行ファイルが検討したソースから作成されたのか、誰が供給しているのか、該当CPUプラットフォームをサポートしているのかを確認します。
- ハッシュと保管：確保したファイルのハッシュを記録し、後で同じファイルであるか比較します。配布者のチェックサムとファイルを同じ信頼できない場所から受け取った場合、両方の値が一致するだけでは出所を証明できません。
- 使用条件：当該コミットのLICENSE・著作権表示・READMEの別途宣言と、含まれる第三者構成要素の条件を合わせて保存します。
コンテナでは、digest、つまりイメージ内容を識別するハッシュを確認します。latestのようなタグは後で異なる内容を指す可能性があります。digestの固定は、再度取得する際に同じ内容を選択するのに役立ちますが、その内容が無害であるという検査ではありません。マルチプラットフォームイメージでは、全体リストを識別するdigestと特定のプラットフォームイメージのdigestも区別する必要があります。 Dockerイメージdigestドキュメント
確認結果は、長い成功宣言よりも、次のような短い記録として残す方が再検討に有用です。以下は実際のインストール記録ではなく、作成様式です。
출처 저장소: 검토 대상 공개 저장소 URL
소스 기준: 확인한 전체 커밋 식별값
비교 범위: 대조한 기준과 파일 목록 / 대조하지 못한 범위
사용 조건: 해당 커밋의 LICENSE와 관련 고지
실행물: 공급자, 플랫폼, 파일 해시 또는 이미지 digest
검증 범위: 정적 검토 / 빌드 / 시작 / 모델 응답 / 도구 권한
유지보수: 담당자, 업데이트 기준, 중단·복원 방법
公式文書を基に再構成。GitHubライセンス案内、Docker digestドキュメント、Dockerセキュリティドキュメントを基に整理した検討手順です。次の段階に進んだという事実が、以前の未確認項目を解決するわけではありません。
7. ライセンス表示は原文確認の出発点である
公開で読めるという事実と、複製・変更・再配布を許可する条件は区別する必要があります。照会した候補のAPIにはAGPL-3.0と表示されたライセンス情報がありましたが、自動分類だけで配布しようとするすべてのファイルの条件を確定することはできません。実際に選択したコミットのLICENSEと著作権表示、含まれる依存関係とファイルごとの条件を確認する必要があります。
作者の公開中止発表だけで、過去のすべての配布物の権利を一括判定したり、すべてのフォークが違法または何の制限もなく使用可能であると結論付けることはできません。GitHubの案内も、リポジトリの公開・フォーク関係とライセンス条件を区別して説明しています。この記事は各アーカイブ版に対する法的な検討を行った結果ではなく、特に外部再配布やサービス提供を計画する場合は、確保した原文条件に基づいた別途検討が必要です。 GitHubライセンス案内
保管する際も、コードだけを残して告知ファイルを省くと、後で確認する根拠が減少します。逆に、フォーク運営者が新しいLICENSEファイルを追加したからといって、元々含まれていたすべてのコードの権利が自動的に整理されるわけではありません。変更時点と適用範囲を確認し、不確実なファイルは検討範囲外として表示する必要があります。
8. 実行検証は別途の研究環境で分けて実施する
出所と条件を確認した後でも、すぐに業務機器で実行する必要はありません。ARTEXのようにファイルとツールを扱うエージェントは、実行アカウント・共有ディレクトリ・ネットワーク設定によってアクセス範囲が変わります。Dockerコンテナには隔離機能がありますが、ホストディレクトリや制御ソケットを共有し、過度な権限を与えると境界が弱まります。 Docker Engineセキュリティドキュメント
別途研究用仮想マシンで検討を開始し、業務ソース・ブラウザプロファイル・認証ファイルを接続しないでください。ツールに「外部アクセスをするな」と書くだけではネットワークは遮断されません。必要なモデルの宛先と残りの外部接続を区別し、実行環境で許可された通信範囲を確認します。
検証も一度の成功でまとめません。設定が読み取れるか、検討した実行物でプロセスが開始されるか、画面が開くか、選択したモデルから合成入力に対する応答を受け取るか、ツール実行前に必要な制限と承認が機能するかをそれぞれ記録します。サーバーのヘルス応答だけを受け取った場合は、サーバー確認まで完了したことになります。モデル応答やツール全体の承認経路まで検証した結果として拡大解釈しないでください。
外部モデルを使用すると、ローカルプログラムからでも入力が外部に伝達される可能性があります。最初の確認には、実際の顧客データや運用ログの代わりに合成テキストを使用し、保存場所・記録設定・使用量・停止方法を合わせて確認します。この手順は今後実施する検討基準であり、本記事で当該アーカイブ版を実際にインストールしたり、これらすべての項目を通過させたという意味ではありません。
9. 今の選択基準は入手できるかよりも維持できるかである
ARTEXの公開配布中止は、過去の説明がすべて間違っていたという意味ではありません。ただし、公式ダウンロードとメンテナンスが引き続き利用可能であるという前提は変わりました。既存のインストールガイドを読む際には基準日を確認し、オリジナル確保の段階から現在のアクセス可能性を再確認する必要があります。
アーカイブ版の役割は、特定の時点の資料を残すことです。再現可能な実行環境と安全な運用までを共に保証するものではありません。出所・コミット・条件・変更点・実行物を確認し、別途環境で検証した範囲を記録できる場合に、次の判断に進むことができます。
その根拠が不足している場合、ダウンロード迂回経路を増やすよりも、検討を中止し、維持されている他のツールを比較する方が合理的です。アーカイブ版の研究を続けるのであれば、修正責任と更新基準も定める必要があります。ファイルを確保したか、動作を確認したか、今後維持できるかを分けて記録することが、今回の変化で最も必要な点検です。
参考資料
確認日：2026年10月9日。リポジトリと配布経路の状態は今後変更される可能性があります。
- ARTEX作者の発表 — GitHubプロフィール：2026年10月8日の発表。
- 既存ARTEX概要とセキュリティ導入境界：以前の確認時点でのシステム説明。
- mhtsec/ARTEX公開API、Hinln/ARTEX公開API、archiveproject/ARTEX公開API：公開アーカイブ候補の照会。
- 保管用公開フォーク：オリジナル履歴保存用であり、インストール・安全性検証完了を意味しません。
- 韓国語コミュニティ代替候補artex-ko：ローカライズ範囲・基盤資料・配布経路・使用条件の確認。
- 確認対象リリースパス、確認対象ARM64 ZIP：アクセス観測対象であり、現在のダウンロード可能性を意味しません。
- Docker Registry認証フロー。
- Dockerイメージdigest。
- GitHubリポジトリライセンス案内。
- Docker Engineセキュリティ。
コメントを残す