コンテンツにスキップ
Aikido Docs 日本語版

サポート向け情報

Zen FirewallについてAikidoサポートに問い合わせる際は、まず以下の項目を確認したうえで、必要な情報をチケットに記載してください。これにより、問題の診断を迅速化し、不要なやり取りを避けることができます。

1. トークンを確認する

Section titled “1. トークンを確認する”

Zenが Aikido と通信するには有効なトークンが必要です。アプリがZenダッシュボードに表示されない場合、まず確認すべきはトークンです。

  • AIKIDO_TOKEN が、アプリが実際に動作する環境（シェルだけでなく）で設定されていることを確認してください。
  • トークンが余分な引用符や空白で囲まれていないことを確認してください。
  • トークンが正しいアプリに紐づいていることを確認してください。詳細はAikido Zen Firewall トークンの作成をご覧ください。
  • AIKIDO_DEBUG=true を有効にし、起動ログでトークンが検出されたことが報告されているか確認してください。

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

Section titled “2. Aikidoへの接続を確認する”

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

ドメイン（EU、US、ME）の全リストと接続テストコマンドについてはOutbound Network Connections for Zenをご覧ください。これらの確認は、アプリが動作しているのと同じホスト（該当する場合は同じコンテナ）から実行し、いずれかが失敗した場合はその出力を共有してください。

3. サポート向け情報

Section titled “3. サポート向け情報”

チケットを起票する際は、以下の情報を共有してください。

アプリと環境

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

設定

  • モード: ブロッキング（AIKIDO_BLOCK=true）または検知のみ
  • 設定しているその他の AIKIDO_* 環境変数 — 詳細は環境変数による設定をご覧ください

問題の再現性

  • 問題は一貫して再現しますか？
  • 単一のエンドポイントに影響しますか、それとも複数のエンドポイントに影響しますか？
  • 問題を引き起こすサンプルリクエスト（シークレットやPIIは削除したもの）
  • 期待していた動作と実際の動作の違い

デバッグログ

  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: FPM プールに設定された error_log、および上流の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 でホストされているアプリでは、web.config で stdoutLogEnabled="true" を設定した場合のみ、ログファイル経由で stdout が出力されます。
  • 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 など）で実行している場合も、上記の出力先はプロセスから変わらず出力されており、プラットフォームのログコレクターに転送されているだけです。そこからログを取得してください。

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