トラブルシューティング / よくある質問

CSIRT-Pro の利用中に起きやすいつまずきと、その確認手順と対処をまとめます。

各項目は「症状」「確認」「対処」の順で記載します。ここで解決しない場合は、ページ末尾のお問い合わせからご連絡ください。

検索が返らない / エラーになる

症状

検索を実行しても結果が表示されない。実行に時間がかかり続ける、またはクエリがエラーになる。

確認

group を含む大規模な集計を、広い時間範囲に対して実行していないか。
時間範囲セレクタが、データの存在しない期間や過度に広い期間になっていないか。
PRQL の構文（from filter select group sort take の順序、バッククォートやフィールド名の綴り）に誤りがないか。

対処

生ログ全体を走査する大規模な集計は、対象が大きいほど時間がかかります。 schema-on-read 方式では、検索時に生ログからフィールドを抽出してから集計するためです。

次の順で走査量を減らしてください。

時間範囲を狭める。
対象 Pipeline を限定する。
filter を先に置いて対象を絞り込む。

特定の値を 1 件絞り込む検索（point lookup）は数秒以内で返ることが多いです。まず狭い条件で動作を確認してから範囲を広げると、切り分けがしやすくなります。

構文エラーの場合は、クエリエディタのオートコンプリートを利用し、句の順序とフィールド名を見直してください。詳しい書き方は PRQL リファレンスを参照してください。

ログが取り込まれない / パース失敗

症状

API でログを送信したのに、検索しても該当ログが見つからない。取り込みは成功しているが、フィールドが空（NULL）になる。

確認

取り込み定義（Pipeline）の指定が経路に合っているか。
- POST /api/v2/ingest：クエリパラメータ pipeline_id（必須）
- POST /api/v2/ingest/batch：ボディの pipeline_id（必須）
- POST /api/user/<user_id>/bulk/<pipeline_name>/：パスで pipeline_name を指定
リクエストの Content-Type が送信形式と一致しているか（JSON は application/json、NDJSON は application/x-ndjson、テキストログは text/plain）。
正規表現モードの場合、Parse Settings のキャプチャグループ数と Parse Fields のフィールド名の数が一致しているか。
JSON ログの場合、Parse Settings を空（JSON モード）にしているか。

対処

抽出は検索時に行われるため（schema-on-read）、生ログ自体は messages 列に保持されます。パースに失敗したログは、Pipeline ごとの parsefailure 系テーブル（{org_uuid}-parsefailure_{pipeline_name}）に退避されます。取り込んだはずのログが見つからない場合は、まず parsefailure 系テーブルを検索して、退避されていないか確認してください。

退避されている場合は、Parse Settings とサンプルログを照合し、キャプチャグループとフィールド名の対応（位置で紐づく）を見直します。キャプチャグループ数とフィールド名の数が合っていないと、フィールドがずれる、または空になります。設定の詳細は Pipeline (ログ取り込み) を参照してください。

名前付きキャプチャグループは使わない

Python スタイルの名前付きキャプチャグループ (?P<name>...) は使用しません。標準的なキャプチャグループ (...) と Parse Fields の組み合わせで指定します。

AI 機能が動かない

症状

AI Investigate やケースの AI 分析を開いても応答が返らない、または機能が利用できない。

確認

他の機能（検索、ケース、Pipeline 等）は正常に動作しているか。
期待している操作が、AI 機能の対応範囲に含まれているか。

対処

AI 機能（AI Investigate、ケースの AI 分析）のバックエンドは、検索や取り込みを担うコア機能とは別のサービスとして稼働します。このサービスは独立しているため、環境によっては未起動のことがあり、その際は AI 機能だけが利用できなくなります。他の機能が正常で AI 機能だけが応答しない場合は、この状態が考えられます。時間をおいても改善しない場合はお問い合わせください。

なお AI 機能は読み取り専用です。検索、集計、可視化、調査の補助のみを行い、対応、修復、通信のブロック、ケースのクローズなどを自動実行することはありません。「AI が自動でクローズしない」「自動でブロックしない」のは仕様です。詳細は AI Investigate とケース内 AI 機能を参照してください。

ログインできない / セッション切れ

症状

ログイン画面で認証が通らない。しばらく操作すると再ログインを求められる。

確認

対応ブラウザ（最新の主要ブラウザ）を使用しているか。
ブラウザの Cookie が有効か。プライベートブラウジングや拡張機能で Cookie がブロックされていないか。
多要素認証（MFA）の設定が完了しているか。

対処

Web のログインはメールアドレスとパスワード、および多要素認証（MFA）で行います。 MFA は必須で、TOTP や WebAuthn（Passkey を含む）に対応します。外部 IdP との SSO 連携（SAML 等）には対応していません。

Web セッションは署名付き JWT を含む Cookie で維持されます（既定の有効時間は 8 時間、組織で短縮可）。このため Cookie がブロックされているとログイン状態を保持できず、セッション切れが起きやすくなります。ブラウザの Cookie を有効にし、対象ドメインの Cookie 削除を行ってから、再度ログインしてください。

同一ユーザーでも、IP アドレスや User-Agent が異なる同時ログインは拒否されることがあります。別環境からログインし直す場合は、先に既存のセッションからログアウトしてください。

対応ブラウザのバージョン

最新の主要ブラウザに対応します。

要確認

サポート対象とする具体的なブラウザのバージョンは〔要確認: 対応ブラウザの具体バージョン〕です。

API キーが無効 / 失効

症状

API リクエストが 401（認証エラー）や 403（権限不足）で失敗する。

確認

使用している API キーが、必要な操作に対応した scope を持っているか。
API キーが削除・失効していないか。
リクエストヘッダーにキーを正しく付与しているか。

対処

API キーは scope によって権限が制御されます。操作に必要な scope を持たないキーでは、対象の API が 403 で拒否されます。

API キーは作成時にのみ表示されます。控えを失った、または失効した場合は、組織管理画面の API キー管理から再発行してください。不要になったキーは削除できます。詳細は組織管理を参照してください。

招待メールが届かない

症状

ユーザーを招待したのに、招待先に招待メールが届かない。

確認

招待先のメールアドレスに誤りがないか。
迷惑メールフォルダやスパムフィルタに振り分けられていないか。
受信側のメールサーバで、送信元が拒否・隔離されていないか。

対処

まず招待先のアドレスの綴りを確認し、迷惑メールフォルダを確認してもらってください。組織管理画面から、対象アドレスへ再度招待を送信できます。

社内のメールフィルタで止まっている可能性がある場合は、送信元アドレスを受信許可リストへ追加することで改善することがあります。

要確認

招待メールの送信元アドレス（差出人）は〔要確認: 招待メールの送信元〕です。受信許可リストへの登録が必要な場合は、確定後に本ページへ追記します。

レート制限（429）に達した

症状

API リクエストが 429 Too Many Requests で失敗する。一定時間でリクエストが受け付けられなくなる。

確認

短時間に大量のリクエストやバルク取り込みを行っていないか。
1 日あたりのリクエスト回数や転送量が、既定の上限に近づいていないか。

対処

既定で、1 日あたりのリクエスト回数と転送量に上限が設定されています。上限を超えると 429 が返ります。

まず、取り込みをバッチ（/api/v2/ingest/batch）にまとめる、リトライ間隔を空けるなどでリクエスト数と転送量を抑えてください。恒常的に上限が不足する場合は、上限の引き上げをサポート窓口へご依頼ください。

解決しない場合

上記で解決しない場合は、お問い合わせからご連絡ください。発生している画面、操作手順、表示されたエラーメッセージ（ステータスコードを含む）、発生時刻を添えていただくと、調査がスムーズです。