[第2回] QueryPie ACP Community Editionをインストールする — 導入検討のための最初の実習環境
2026年11月7日
前回は「攻撃者がすでに内部に侵入していたら、どこまで移動できるのか」と問いかけた。答えを得るには機能一覧を読むだけでなく、実際に製品を動かし、アカウントと権限を設定し、許可・遮断された操作の記録を確認する必要がある。
今回はその出発点として、 自分のMacにQueryPie ACP Community Editionの実習環境を構築した。 導入担当者が再現できるよう、環境、インストール順序、遭遇した問題、確認できた範囲を記録する。作業日は2026年11月7日、インストールしたACPのバージョンは11.6.7だ。
この記事の読み方: 各手順には参考マニュアルと該当節の名前を記載した。公式手順を確認し、今回の実習画面と比較してほしい。プロジェクトの分離、外部ポート16444、リソース使用量、所要時間は、このMac環境での設定・観測結果だ。文書は更新されるため、別バージョンを導入する際は最新の案内も確認しよう。
今回確認した範囲: イメージの取得、データベースの初期化、サーバーの準備状態確認、Communityライセンス登録、初期管理者パスワードの変更、変更後のパスワードでのログインとダッシュボード表示まで完了した。管理画面のWeb Base URLも保存して再確認した。実際のDB・サーバー・Kubernetesアクセス制御は次の実習で検証する。
1. 導入検討用の実習環境の目的を決める
今回の目的は、今後の機能検証に向けた小さな実験環境を作ることだ。DB一つとテストアカウントを接続し、「誰が接続できるか」「何ができるか」「何が記録されるか」を順に確認したい。
公式のCommunity案内ではARM64・macOSとDockerの組み合わせを試用向けとしている。試用の推奨値は4 vCPU、メモリ16 GiB、ディスク30 GiB以上。複数ユーザーでの本番運用はAMD64、8 vCPU、メモリ32 GiB、ディスク100 GiB以上、Linuxが推奨されている。今回はApple SiliconとDocker Desktopを使った。高可用性、バックアップ・復旧、認証連携、ログ保持の設計は別途検討が必要だ。
2. ノートPCの仕様とDockerへの割り当ては異なる
参考マニュアル: QueryPie ACP Community Editionの 「推奨サーバー仕様」。ここで試用と本番の推奨仕様を分けて確認した。運用OSの選定には、 LinuxディストリビューションとDocker・Podmanの対応状況も参考になる。以下の表はマニュアルの推奨値ではなく、自分のMacで確認した値だ。
項目 | 今回の実習環境 |
ホスト | macOS 26.7.2 / arm64 / 論理CPU 12基 / RAM 32 GiB |
Docker | Docker Desktop 4.98.0 / Engine 29.9.2 |
Compose | v5.6.1 |
Docker VMのリソース | CPU 12基 / メモリ約23.43 GiB |
インストール前のディスク空き容量 | 約49 GiB |
ACP | 11.6.7 — 実行時点で公式インストールスクリプトが推奨していたバージョン |
導入検討では「メモリ32 GBのノートPCがある」で終わらず、Dockerが実際に使えるメモリまで確認したい。イメージ、DB、ログを保存するディスク容量も必要だ。上の値は今回の環境の記録であり、製品の最小要件ではない。

3. 既存のQueryPie環境を保全し、実習環境を分離する
参考マニュアル: インストールガイド — setup.v2.shと、取得したパッケージ内のquerypie/11.6.7/README.ko.mdにある 「QueryPie ACPの自動インストールと実行」, 「DockerでQueryPie ACPを手動実行する」。パッケージだけを準備するオプションは、実際に取得したsetup.v2.shで確認した。プロジェクト・ネットワーク・データパスの分離は、既存環境を保全するために今回追加した構成だ。
Macにはすでに別のQueryPie環境があった。既存コンテナを停止した後、新しいComposeプロジェクトをacp-ce-labと名付け、ネットワークとデータパスを分けた。既存データは新しい実習環境に流用していない。
公式スクリプトは自動インストールにも対応している。今回は既存環境とログを保全するため、公式Composeパッケージを先に取得し、付属READMEの手動実行手順に従った。以下は今回実際に選んだ方法だ。
curl -fsSL https://dl.querypie.com/setup.v2.sh -o setup.v2.shbash setup.v2.sh --install-compose-package 11.6.7bash setup.v2.sh --populate-env querypie/11.6.7/.envchmod 600 querypie/11.6.7/.env
実行前にスクリプトを確認した。この時点のバージョンは26.10.1だった。以降のコマンドは生成されたquerypie/11.6.7ディレクトリで実行した。環境ファイルには認証情報が含まれる可能性があるため、内容をブログやリポジトリに公開しない。

4. イメージを取得し、データベースを初期化する
参考マニュアル: パッケージのREADME.ko.md → DockerでQueryPie ACPを手動実行する → MySQLとRedisの実行 / QueryPie ACP Toolsの実行。DB起動とmigrationの順序はこの節で確認した。イメージ取得の進捗、health応答、所要時間は実行中に記録した。READMEはComposeパッケージ取得後、インストールディレクトリで開ける。
構成要素はACPアプリケーション、MySQL、Redis、初期化用のToolsイメージだ。MySQLは製品設定や履歴を保存する基盤であり、後で接続する業務用DBとは分けて理解する必要がある。コンテナを動かすことと同じくらい、データがどこに残るかの確認が重要だ。
docker compose --profile database --profile app --profile tools pulldocker compose --profile database up -ddocker compose --profile tools up -dcurl http://localhost:8050/healthdocker compose --profile tools exec -T tools /app/script/migrate.sh runalldocker compose stop tools
Toolsのhealth応答が200であることを確認してからmigrationを実行した。取得した四つのイメージはいずれもarm64だった。メタデータ上のサイズ合計は約5.33 GBだが、これはダウンロード転送量や実際の追加ディスク使用量を測った値ではない。


記録ではイメージ取得は11時53分40秒に始まり、11時56分15秒より前に完了した。初回migrationは11時57分52秒から58秒までだった。ネットワーク、機材、キャッシュの有無に左右される一度の実測値だ。事前調査や撮影の時間まで合算して製品のインストール時間とは表現しない。
5. 実際に遭遇した問題:6443番ポートの競合
今回の環境で追加した対処: 外部ポートを16444に変えるのは、このMacでの競合を解消するための設定であり、すべてのインストールに必要な公式の基本手順ではない。後続のProxy設定では、 インストール後の初期設定の 「KAC:Proxy接続先アドレスの設定」を参照する。Dockerのポートマッピングと、製品内のProxyアドレス設定はそれぞれ確認が必要だ。
アプリケーションの初回起動時に、6443番ポートが使用中というエラーが出た。調べるとDocker Desktopがローカルの127.0.0.1:6443を使っていた。
再試行では起動したが、既存サービスと明確に分けるため、実習環境のKAC外部ポートを16444に変更した。コンテナ内部の6443は維持し、ホスト側だけを変えた。最終的なComposeのポート一覧には16444:6443が入る。
lsof -nP -iTCP:6443 -sTCP:LISTENdocker compose port app 6443# 이번 환경의 결과: 0.0.0.0:16444
Compose overrideでポート一覧を変更するときは、元の一覧へ意図せず追加されないよう、最終設定を確認する必要がある。今回はCompose v5.6.1でports: !overrideを使って一覧全体を指定した。下の画像は最初のエラーではなく、使用中のポートと変更後のマッピングを確認した画面だ。

この変更だけでKubernetesアクセス制御を検証したことにはならない。後のKAC実習では、ユーザーが接続するProxyのアドレスとポートにもこの値を反映する必要がある。導入担当者にとって重要なのは、Web管理画面のポート確認だけでは終わらないことだ。リソースへのアクセス経路とファイアウォール規則も整理する必要がある。
6. コンテナ稼働とサービスの準備完了を区別する
参考マニュアル: パッケージREADME.ko.mdの 「QueryPie ACP Applicationの実行」 および Community Editionの案内の 「QueryPie ACP Community Editionの手動起動」, 「インストール方法 → 3. インストール後の接続」。readyzの確認方法とWeb接続ポートはこの部分で確認した。
docker compose --profile app up -ddocker compose exec -T app readyzdocker compose ps
コンテナのrunning状態だけで判断せず、ACPのreadyzコマンドで準備完了を確認した。ポート変更後の最初の成功記録は12時2分11秒で、撮影時に再確認しても成功した。

ブラウザでhttp://localhost:8000/を開くとライセンス登録画面が表示された。起動直後の一度の測定では、メモリ使用量はapp約3.99 GiB、MySQL約550.8 MiB、Redis約10.06 MiBだった。まだユーザー操作のない状態での瞬間値なので、本番の容量設計の根拠には不十分だ。

7. Communityライセンスの申請は別の手順だった
参考マニュアル: Community Editionの案内の 「インストール方法 → 2. インストール中のライセンス発行 / 4. ライセンス登録」。申請は 公式Communityライセンス申請ページで行った。マニュアルの拡張子の説明と実際に受け取った形式の違いは、下に記録した。
画面には最大5人で1年間無料で試せると案内されていた。公式申請ページに受信可能な業務メールとテスト用組織情報を入力した。申請成功の表示を確認し、証明書付きの発行メールも届いた。


発行案内にはCOMMUNITY、アクティブユーザー5人、DAC・KAC・SAC・WACの範囲が記載されていた。今後申請する際は、その時点の提供条件と実際のライセンスを再確認したい。ライセンスに機能名があるだけでは、その使いやすさや自社環境との互換性を検証したことにはならない。
実際に届いたのはZIP内の.pem証明書だった。公式案内には.crtと説明されている部分もあるが、今回はZIPを展開したPEMファイルを Upload License → Continueで読み込んだ。組織名、Community種別、製品範囲、ユーザー上限を確認してApplyを押すと、ログイン画面へ進んだ。

8. 初回ログインでパスワードを変更し、ダッシュボードを開く
参考マニュアル: Community Editionの案内の 「インストール方法 → 5. ログイン / 6. インストール完了」。初期アカウントと変更手順を確認した。変更の強制とアカウント管理の条件は、 初期qp-adminアカウントのパスワード変更強制とアカウント削除機能の 「qp-adminのパスワード変更強制条件 / パスワード変更方法」を参照した。今回はアカウントを削除していない。

公式ガイドの初期管理者qp-adminでログインすると、パスワード期限切れの案内と変更画面が表示された。新しいパスワードを設定し、成功を確認してから再ログインし、ユーザーダッシュボードを開いた。実習用管理者パスワードは別途安全に保管した。


Go to Admin Page → General → Company Management → Generalへ移動し、Web Base URLをhttp://localhost:8000に設定した。末尾のスラッシュを付けずに保存し、再読み込み後も値が残ることを確認した。これはMac一台で行う今回の実習用アドレスだ。他のPCや外部認証システムと連携する場合は、そこから到達可能なアドレスとTLS構成が必要になる。
参考マニュアル: インストール後の初期設定の 「共通設定 → QueryPie Web Base URL設定」と QueryPie ACP Community Edition初期構成ガイドの 「Web Base URL設定」。末尾のスラッシュを除き、ポートを含める方法を確認した。同じガイドの 「サービス別Proxy設定」は外部クライアント接続の実習で参照する項目であり、この記事では設定を完了していない。

管理画面上部にはWAC証明書更新に伴うWAC Proxyの再起動案内があった。今回はWAC接続を検証しておらず、該当コンポーネントの適用確認とサービス別Proxy設定は各機能の実習で行う項目として残した。 ログイン成功をすべてのアクセス経路の準備完了と見なさないことが重要だ。
9. 導入担当者が今回のインストールから持ち帰る問い
検討項目 | 今回確認したこと / 次に確認すること |
実習の実施可能性 | 今回のMac・Docker構成で11.6.7の起動とダッシュボード接続を確認 |
本番環境への適合性 | 本番OS・アーキテクチャ・リソース要件・サポート範囲は別途確認が必要 |
ネットワーク | 6443競合を経験。管理画面とリソース用ポート・Proxyアドレスの一体設計が必要 |
データ管理 | 既存環境と新規データを分離。本番では設定・監査記録の保持、バックアップ・復旧手順が必要 |
ライセンスとアカウント | ライセンス適用、初期パスワード変更、再ログインを確認。個人別管理者と認証連携は今後検討 |
アクセス制御の効果 | テストリソース、許可・遮断シナリオ、監査記録を実際に検証する予定 |
初めて導入してみて、検討の出発点は製品画面を表示することと同時に、自分たちの環境の制約を明らかにする過程でもあると感じた。今回は既存データとポートが制約だった。本番へ広げるなら、証明書、アカウント連携、ネットワーク経路、障害対応、ログ保持も同様に検討対象になる。
次の実習ではこの環境にテストDBを一つ接続する。「接続できた」で終わらず、 権限のないユーザーが拒否されるか、許可した操作と遮断した試行がどのような証跡として残るかを確認したい。初回に提起した「侵入後の制御」を実際の動作で確かめる出発点だ。
参照した公式資料
以下は本文でリンクした文書をまとめたものだ。インストール・実習・文書の確認基準日は 2026年11月7日。画像はマニュアルから転用したものではなく、今回の実習で撮影した。
QueryPie ACP Community Edition — 推奨サーバー仕様、ライセンス申請・登録、初回ログイン、手動起動、準備状態の確認。
インストールガイド — setup.v2.sh — 公式インストールスクリプトの導入手順。
querypie/11.6.7/README.ko.md — 公式Composeパッケージの付属ファイル。「DockerでQueryPie ACPを手動実行する」のMySQL・Redis、Tools、Applicationの手順。
LinuxディストリビューションとDocker・Podmanの対応状況 — 本番ディストリビューションとコンテナエンジンの選定資料。
Communityライセンス申請ページ — 実際のライセンス発行申請。
初期qp-adminアカウントのパスワード変更強制と削除機能 — 初期パスワードの変更動作とアカウント管理条件。
インストール後の初期設定 — Web Base URLとサービス別Proxy設定。
Community Edition初期構成ガイド — Web Base URLの入力形式と、後続の実習で行うサービス別Proxy設定。
本文の画面は今回の実習で撮影した。インストール成功、ライセンス有効化、機能検証、本番適合性は、それぞれ別の確認項目として記録している。
![[第3回] QueryPie ACPに最初のDBを接続する — 開発者の接続方法はどう変わるか](/assets/content/acp-lab-notes/first-database-connection/01.webp)