# サポート向け情報

Zen Firewall について Aikido サポートへお問い合わせいただく際は、まず以下の確認を行い、チケットには依頼された情報を含めてください。これにより、問題をより迅速に診断でき、不要なやり取りを減らせます。

### 1. トークンを確認する

Zen が Aikido と通信するには有効なトークンが必要です。アプリが次の場所に表示されない場合は、 [Zen ダッシュボード](https://app.aikido.dev/runtime/services)、最初に確認すべきなのはトークンです。

* 確認 `AIKIDO_TOKEN` アプリが実際に実行される環境に設定されていることを確認してください（シェルだけでなく）。
* トークンが余分な引用符や空白で囲まれていないことを確認してください。
* トークンが正しいアプリのものであることを確認してください。次を参照してください [Aikido Zen Firewallトークンを作成する](https://help.aikidogov.us/docs/docs-ja/zen-firewall/zen-installation-instructions/creating-an-aikido-zen-firewall-token).
* 有効にする [`AIKIDO_DEBUG=true`](https://help.aikidogov.us/docs/docs-ja/zen-firewall/zen-installation-instructions/configuration-via-environment-variables#debugging) そして、起動ログにトークンが検出されたと表示されることを確認してください。

### 2. Aikido への接続を確認する

Zen は Aikido のクラウドへの外向き HTTPS アクセスを必要とします。トークンが設定されているのにアプリがまだダッシュボードに表示されない場合、最も考えられる原因はネットワーク制限です。

参照 [Zen のアウトバウンドネットワーク接続](https://help.aikidogov.us/docs/docs-ja/zen-firewall/miscellaneous/outbound-network-connections-for-zen) ドメインの完全な一覧（EU、US、ME）と接続テストコマンドについては

### 3. サポート用情報

チケットを作成する際は、以下を共有してください:

**アプリと環境**

* Aikido 内のアプリへのリンク [Zen ダッシュボード](https://app.aikido.dev/runtime/services)
* プログラミング言語とランタイムのバージョン（例: Node.js 20、Python 3.12、PHP 8.3）
* フレームワークとバージョン（例: Express、Django、Spring MVC、Laravel、ASP.NET Core）
* Zen パッケージ／ライブラリのバージョン
* OS、コンテナのベースイメージ、またはホスティングプラットフォーム（例: Ubuntu 24.04、 `php:8.3-fpm`、AWS Lambda、Kubernetes）
* アプリがプロキシ、ロードバランサー、CDN、またはサービスメッシュの背後で動作しているかどうか

**設定**

* モード: ブロッキング（`AIKIDO_BLOCK=true`）または検出のみ
* その他の `AIKIDO_*` 設定している環境変数。参照: [環境変数による設定](https://help.aikidogov.us/docs/docs-ja/zen-firewall/zen-installation-instructions/configuration-via-environment-variables)

**問題の再現性**

* 問題は常に再現できますか？
* 単一のエンドポイントに影響しますか、それとも複数のエンドポイントに影響しますか？
* 問題を引き起こすサンプルリクエスト（機密情報と個人識別情報は伏せてください）
* 期待していた動作と実際に起きたこと

**デバッグログ**

1. 次の項目を設定します： `AIKIDO_DEBUG=true` アプリが実行される環境で。
2. アプリを再起動して、問題を再現してください。
3. 関連する部分のログを取得し、チケットに添付してください。どの行が Zen のものか分からない場合は、次を探してください `Aikido` または `Zen` 出力内で。

Zen の出力先はランタイムによって異なります:

* **Node.js**: Node プロセスの stdout または stderr を確認してください。プロセスマネージャー（PM2、systemd、Docker、Kubernetes、 `npm start` コンソールなど）が収集する場所を確認してください。
* **Python**: Python プロセスの stdout または stderr を確認してください。Gunicorn や Uvicorn などの WSGI / ASGI サーバーでは、ワーカーに設定されているエラーログの出力先を確認してください（例: Gunicorn の `--error-logfile`、またはフォアグラウンドで実行している場合は stdout）。
* **PHP**: 出力先は SAPI によって異なります:
  * Apache（`mod_php`）: Apache のエラーログ（次で設定されたパス `ErrorLog` ディレクティブ、通常は `/var/log/apache2/error.log`).
  * PHP-FPM: の `error_log` FPM プールで設定されたものに加え、上流の Web サーバーのエラーログです。
  * FrankenPHP: Caddy / FrankenPHP の stdout、または設定している場合は Caddy のログファイル。
  * CLI ワーカー（queue、cron、artisan）: コマンドの stderr。
* **Java（Spring、Javalin など）**: アプリケーションに設定されたログフレームワーク（SLF4J / Logback / Log4j2）を確認してください。Zen のメッセージは、他のアプリログと同じ出力先（コンソール、ログファイル、コンテナ内では stdout への JSON など）に表示されます。
* **.NET（ASP.NET Core / Framework）**: アプリケーションに設定された `ILogger` のシンクを確認してください。デフォルトの Console ロガーでは、これは stdout です（ `dotnet run`, `journalctl`、またはコンテナログで確認できます）。IIS ホストのアプリでは、stdout はログファイル経由でのみ表示されます。 `stdoutLogEnabled="true"` が `web.config`.
* **Ruby on Rails**: Rails のロガーを確認してください（`log/development.log`, `log/production.log`、または設定済みの別の場所）。単体の Ruby スクリプトは stderr にログを出力します。
* **Go**: Go バイナリの stdout または stderr を確認してください。

コンテナまたはサーバーレスプラットフォーム（Docker、Kubernetes、AWS Lambda / CloudWatch、Cloud Run、App Service、Heroku、Fly.io など）で実行している場合でも、プロセスは上記の行を出力しますが、プラットフォームがそれらをログ収集先へ転送します。そこからログを取得してください。

上記のすべてを提供していただくことで、フレームワーク、ランタイム、または環境固有の問題をはるかに効率よく特定できます。