ARTEXは、LLMと実行ツール、ウェブ画面、データベースを接続したセキュリティ研究システムです。インストールするには、ソースコードだけでなく、実行ファイル、依存関係、設定、データストレージまで準備されている必要があります。デプロイメントパスが途切れた場合、どの部分を確保できるかから再確認する必要があります。
2026年10月9日に再確認した結果、元のAutumn-27/ARTEXのGitHub公開APIと既存のDocker Hubイメージのlatestタグの照会は404を返しました。韓国語フォークは開きますが、デフォルトのComposeファイルは依然として元のイメージを参照しています。したがって、リポジトリアドレスをフォークに変更し、既存のComposeコマンドを実行する方法は解決策になりません。
現在確認されている代替案は、韓国語フォークが案内するソースビルドパスです。この記事では、固定コミットの設定・ビルド順序と依存関係へのアクセスを点検した結果を説明します。これは、完全に新しい環境でコンパイル・DB接続・管理者ログイン・モデル応答まで完了したインストール成功の体験談ではありません。
AIが生成した概念イメージ。実際のARTEX画面や実行完了状態を示すものではありません。
1. 今回確認した範囲
再検証の対象は、既存のインストール編に登場した元のリポジトリとイメージ、そして公開されているjiwoochris/artex-koのインストール資料です。韓国語フォークは、元のプロジェクトの公式配布再開ではなく、別途のメンテナーが管理するリポジトリとして区別します。
| 確認対象 | 今回の観測 | 解釈範囲 |
| — | — | — |
| 元のGitHubリポジトリ・ファイルリスト・リリース公開API | HTTP 404 | 認証なしの現在の公開パスからアクセス不可 |
| Docker Hub autumn27/artexのlatestタグAPI | HTTP 404 | 当該タグの公開照会失敗、実際のイメージプル成功ではない |
| 韓国語フォーク README・Compose・Dockerfile・環境変数例 | 固定コミットから読み取り成功 | インストール設計と案内確認 |
| norma v0.4.3 Goプロキシの.info・.mod | HTTP 200 | バージョン情報とモジュール宣言へのアクセス確認 |
| 全体の依存関係ダウンロード・コンパイル・サーバー実行・モデル呼び出し | 今回の再検証では実行せず | インストール成功を主張できない |
404だけでは、リポジトリが永久に削除されたのか、非公開に切り替わったのかまで確定することはできません。ただし、読者が認証なしでたどる既存の公開インストールパスが現在開かないという判断には十分な観測です。検索結果に過去のファイルが残っていても、現在のダウンロード可能性を代弁するものではありません。
直接確認パス: 元のリポジトリAPI · 元のリリースAPI · 既存のイメージタグAPI。
2. フォークをダウンロードしてもDockerクイックスタートがブロックされる理由
検討した韓国語フォークのコミットは7333fa47b9bdd89b4973992b2e15d9c393539b8cです。この時点のREADMEでは、元のイメージを取得できないためDockerクイックスタートが動作せず、韓国語版イメージは配布準備中であると説明されています。ソースコンパイルパスが機能するという説明はメンテナーの確認内容であり、この記事の実行測定結果とは区別します。 固定コミットREADME
Composeの主要な参照は以下の通りです。
artex:
image: autumn27/artex:${ARTEX_TAG:-latest}Gitリポジトリのアドレスとコンテナイメージのアドレスは別物です。フォークのコードを受け取ったとしても、この設定を使用する限り、実行ファイルは元のイメージリポジトリから探します。ARTEX_TAGを任意の別の名前に変更しても、そのタグが実際に配布されているという根拠にはなりません。 固定コミットCompose
また、このコミットのDockerfileは、ソース全体を自動的にコンパイルする形式ではありません。事前に準備されたdist/${TARGETARCH}/artexバイナリをイメージ内にコピーします。ファイルを準備せずにdocker buildだけを実行する方法も、完成された代替インストール手順ではありません。 Dockerfile
フォークのメンテナンスドキュメントと設定に基づいて再構成。 READMEと Dockerfileのパスを分離した図であり、フォークを元の公式配布として表示するものではありません。
3. ソースビルドも複数の段階を通過する必要がある
韓国語フォークが案内する順序は、フロントエンドの静的ビルド、結果物のサーバー内蔵ディレクトリへのコピー、Goバイナリのコンパイル、開始スクリプトの実行です。フロントエンドはブラウザに表示される画面であり、Goバイナリはその画面を提供し、APIとタスクを処理するサーバーです。
検討したgo.modはGo 1.26.3を宣言し、github.com/Autumn-27/norma v0.4.3を依存関係として指定しています。画面ビルドはweb/package.jsonのbuild:staticタスクを使用します。実際のビルドツールは、この宣言と使用するオペレーティングシステム・アーキテクチャを合わせて設定する必要があります。 go.mod · フロントエンド設定
上流の依存関係リポジトリが閉じられていても、モジュールプロキシに特定のバージョンが残っている場合があります。今回はGo公開プロキシからnorma v0.4.3のバージョン情報とモジュール宣言を読み取りました。しかし、これら2つのリクエストの成功は、ソース圧縮ファイルとすべての下位依存関係の確保、チェックサム検証、実際のコンパイル成功までを意味するものではありません。
この区別は、既存の開発PCと空のVMの違いを説明します。既存のPCにはすでにキャッシュがあるためビルドが成功しても、初めてインストールする人は依存関係を取得する段階で失敗する可能性があります。再現可能な案内を作成するには、キャッシュがない環境も検証対象に含める必要があります。この部分は、今回の資料確認から導き出された運用上の判断です。
4. インストール作業の前にソースとツールを確認する
以下は、別途Linux研究環境で使用する点検用コマンド例です。この記事では、当該環境の実行出力を測定したものではありません。組織がフォークの使用条件とコードを検討した上で選択したという前提であり、業務用の資格情報や個人ファイルを研究環境に接続する必要はありません。
git --version
go version
node --version
npm --version
git clone https://github.com/jiwoochris/artex-ko.git artex-ko-lab
cd artex-ko-lab
git checkout --detach 7333fa47b9bdd89b4973992b2e15d9c393539b8c
git rev-parse HEAD
git status --shortrev-parseの結果が選択したコミットと同じであることを確認し、ファイルを変更する前に作業ディレクトリの状態を記録します。コミット固定はどのソースを選択したかを示しますが、ソフトウェアが安全であることや、すべての依存関係が固定されていることを保証するものではありません。
その後、go.mod、go.sum、npmロックファイル、Dockerfile、開始スクリプトを一緒に検討します。インストールスクリプトが他の配布パスを呼び出しているかどうかも確認する必要があります。元のイメージがない状況で古い自動インストールスクリプトを繰り返し実行すると、同じ失敗パスに戻る可能性があるためです。
5. 検討用ビルド順序と中断地点
以下は、フォークドキュメントの順序を読みやすく分離した再現候補手順です。読者に検証済みのインストール方法として提示するコマンドではありません。npmインストールプロセスは依存関係スクリプトを実行できるため、ソース検討を終えた専用環境で実行する必要があります。
cd web
npm ci --include=dev
npm run build:static
cd ..
test -f web/out/index.html
test ! -e server/webui/dist
mkdir -p server/webui/dist
cp -a web/out/. server/webui/dist/
CGO_ENABLED=0 go build -tags embedui -o artex ./cmd/artex各コマンドは、直前のコマンドが成功した場合にのみ次の行に進みます。server/webui/distがすでに存在する場合は、上記の検査で停止し、既存の結果なのかソースに含まれる資料なのかをまず確認します。これは、繰り返しビルド時にパスが重複したり、古い画面が混ざったりするのを防ぐための条件です。一度にまとめて実行するインストールスクリプトではありません。
フロントエンドの依存関係にはビルド用パッケージも必要であるため、–include=devを明示しました。Goビルドが完了しても、その結果は現在のビルド環境を対象とした実行ファイルです。Linuxコンテナ用イメージに入れるには、オペレーティングシステムとCPUアーキテクチャが一致するバイナリを別途準備する必要があります。
エラーが発生した場合は、最初の失敗段階とメッセージを記録します。元のリポジトリが見えないという理由だけでチェックサム検証をオフにしたり、任意の依存関係フォークに切り替えたりする方法を基本的な解決策とはしません。代替の依存関係が必要な場合は、その変更自体を別途検討対象として扱う必要があります。
6. コンパイルの次にはDBとサービス設定が残る
単一バイナリに画面を組み込んだからといって、データベースまで含まれるわけではありません。フォークのREADMEは、PostgreSQL接続をconfig.jsonまたはARTEX_PG_DSNで設定する方法を案内しています。ホストで実行するサーバーとコンテナで実行するサーバーでは、DBに到達するアドレスが異なる場合があります。 DB設定案内
例えば、Compose内部のサービス名postgresは、同じネットワークに属するコンテナが使用できるアドレスです。ホストに直接実行したバイナリがその名前でDBに接続できると仮定すべきではありません。まずDBをどの環境で運用するかを決め、その環境で実際に到達可能なアドレスと認証設定を構成します。
READMEは、直接バイナリ実行よりもstart.shの使用を案内しており、ウェブ・APIと記録プロキシのアドレスをそれぞれ-addr、-proxyで受け取ると説明しています。ローカル研究用の候補設定は以下の通りです。DBと必要な設定が準備された状態を前提とします。
./start.sh -addr 127.0.0.1:8787 -proxy 127.0.0.1:8788この設定は、入ってくる接続のバインディングを制限することを目的としています。サーバーとツールが外部に送信する通信をブロックする設定ではありません。モデルAPIとツールの通信目的は、別途ネットワークポリシーで管理する必要があります。管理画面を実際に開き、新しい管理者アカウントを設定した後、サーバー再起動後も設定が維持されるかを確認して、インストール検証を続けることができます。
7. モデル接続と最初の応答は別の試験である
管理画面が開いたら、次はモデル接続です。使用するプロバイダーの現在のモデルID、API形式、ツール呼び出しサポート、およびアカウント権限を確認します。このとき、APIキーをコードやブログコメントに入れる必要はありません。接続テストで選択したモデルからの応答を受け取った後、合成文の要約のような小さな課題で画面と記録の流れを確認できます。
最初から外部対象を検査する自律作業を作成する必要はありません。モデルとツールがどのような入力を受け取り、どのような行動ができるかを確認する段階であるため、機密データや実際のサービスアドレスを含まない小さな入力が適切です。ツールを使用しないように少ないプロンプトでも、実行権限の遮断を代用するものではありません。
フォークドキュメントに基づいて再構成したインストール検証計画。 インストール・DB・LLM設定案内を根拠に整理されており、各段階の成功を測定した結果表ではありません。
8. 既存のインストール版がある場合は、まず保存する
すでに実行中の環境は、新しいインストールとは異なる扱いをします。公開イメージが消滅していても、ローカルイメージやバイナリが残っている可能性があります。どの実行物を使用しているかを確認する前に削除したり、ワンクリックアップデートを適用したりすると、再作成できるパスを失う可能性があります。
保存すべき対象は、ソースコミット、実行ファイルまたはイメージ識別値、実際の設定、DBとファイルデータです。パスワードやキーが含まれる設定は、一般文書と区別してアクセスを制限します。バックアップファイルが作成されたかだけでなく、別途の環境で復元できるかも確認する必要があります。
プログラムファイルを以前のバージョンに戻すことと、DBスキーマを以前の状態に戻すことは別物です。アップデートやフォークへの切り替えを検討する場合は、既存の環境をそのままにしてコピーで互換性を確認する方が、失敗の原因を絞り込みやすくなります。この章は、既存のインストール版の運用に関する一般的な提案であり、実際のシステムに変更を適用した記録ではありません。
まとめ：現在確認された代替案とまだ残る検証
現在の公開パスを基準とすると、既存の元のイメージベースのインストール案内はそのまま使用できません。韓国語フォークにはソースビルドパスがあり、その構成と主要な依存関係メタデータへのアクセスは確認しました。しかし、ビルドドキュメントが存在するという事実と、新しい環境でのインストール成功は異なる結果です。
次の検証は、固定コミットを空の研究環境でビルドし、DB接続・管理者設定・モデル応答・停止と復元まで確認することです。その結果が確保されるまでは、この記事をインストールパスの点検と再現計画として使用し、成功出力がある完成版の実習案内とは区別するのが正確です。
コメントを残す