ナレッジベース

蓄積された障害パターンを検索・閲覧できます — 合計 972 件

972件
CPU クレジット枯渇(T系インスタンスのスロットリング)
想定される原因
  • T系インスタンスのCPUクレジットが枯渇してバースト性能が失われた
  • 長時間の高CPU負荷でクレジットを使い切った
  • Unlimitedモードが無効でクレジット残量が0になった
  • ワークロードに対してインスタンスサイズが小さすぎる
確認手順
  • CloudWatch の CPUCreditBalance メトリクスが 0 に近づいていないか確認
  • CloudWatch の CPUUtilization の推移グラフで長時間高負荷状態が続いていないか確認
  • EC2コンソール > インスタンス > モニタリングでCPUクレジット推移を確認
  • T系インスタンスのクレジット仕様(ベースライン%)とワークロードのCPU要件を比較
  • Unlimited モードの有効/無効設定を確認
EBS ディスク I/O スロットリング
想定される原因
  • gp2 ボリュームのバーストクレジットが枯渇してIOPSがベースラインに制限された
  • ボリュームの IOPS/スループット上限に達した(gp3 の設定値が低い)
  • データベースなどの I/O 集約型ワークロードがディスク帯域を使い切っている
  • インスタンスタイプの EBS 最大スループット上限に達した
  • 複数ボリュームの合計 IOPS がインスタンス上限を超えている
確認手順
  • CloudWatch の VolumeQueueLength, VolumeReadOps, VolumeWriteOps を確認
  • CloudWatch の EBSWriteBytes / EBSReadBytes でスループット使用量を確認
  • ボリュームタイプ(gp2/gp3/io1/io2)と設定IOPSを確認
  • iostat コマンドで I/O wait % をリアルタイム確認
  • インスタンスタイプごとの EBS 最大スループット制限を確認
インスタンス到達不能(Status Check 失敗)
想定される原因
  • ホストハードウェアの障害(AWS インフラ側の問題)
  • カーネルパニックまたは OS クラッシュ
  • ネットワーク設定ミスによるルーティング不可
  • EBS ルートボリュームの破損
  • 電源・ネットワークの基盤障害
確認手順
  • EC2コンソール > インスタンス > ステータスチェックタブで失敗種別を確認
  • System Status Check 失敗 → AWS インフラ側問題(インスタンス再起動/移行が有効)
  • Instance Status Check 失敗 → OS/アプリ問題(EC2 シリアルコンソールで確認)
  • EC2 シリアルコンソール(Systems Manager経由)でカーネルパニックログを確認
  • CloudWatch の StatusCheckFailed メトリクスの履歴を確認
SSH 接続不可(22番ポート到達不能)
想定される原因
  • セキュリティグループのインバウンドルールでSSH(22)が許可されていない
  • ネットワーク ACL でポート22がブロックされている
  • 使用する SSH キーペアが異なる
  • インスタンスが起動中/停止中でSSHデーモンが未起動
  • VPC のルートテーブルが正しく設定されていない(インターネットゲートウェイなし)
確認手順
  • セキュリティグループのインバウンドルールでSSH(TCP 22)が自分のIPに許可されているか確認
  • ネットワーク ACL でポート22のインバウンド/アウトバウンド両方が許可されているか確認
  • EC2 コンソールでインスタンスが running 状態か確認
  • Elastic IP またはパブリック IP が割り当てられているか確認
  • VPC のサブネットのルートテーブルに 0.0.0.0/0 → Internet Gateway が設定されているか確認
メモリ不足(OOM Killer 発動)
想定される原因
  • アプリケーションのメモリリーク
  • インスタンスメモリに対してワークロードが大きすぎる
  • スワップ領域が設定されていないか不足している
  • 複数プロセスの合計メモリが物理メモリを超えた
  • JVM ヒープサイズの上限設定が不適切
確認手順
  • /var/log/messages または /var/log/kern.log で 'oom-killer' を検索
  • free -h でメモリとスワップの使用状況を確認
  • top / htop で各プロセスのメモリ使用量(%MEM, RES)を確認
  • CloudWatch の mem_used_percent メトリクス(CloudWatch Agent 必要)を確認
  • ps aux --sort=-%mem | head -20 でメモリ大食いプロセスを特定
インスタンスメタデータサービス (IMDS) アクセスエラー
想定される原因
  • IMDSv2 が強制されているが、アプリが IMDSv1(トークンなし)でアクセスしようとしている
  • IMDSv2 のトークン TTL が切れている
  • コンテナ内から IMDS にアクセスする際に hop limit が 1 のままで届かない
  • インスタンスに IAM ロールがアタッチされていない
  • IMDS 自体が無効化されている(HttpEndpoint: disabled)
確認手順
  • curl -s http://169.254.169.254/latest/meta-data/ でメタデータアクセスを確認
  • IMDSv2: TOKEN=$(curl -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600' http://169.254.169.254/latest/api/token) で取得確認
  • EC2 コンソール > インスタンス設定 > Instance Metadata の設定を確認
  • aws ec2 describe-instances --query 'HttpEndpoint,HttpTokens' で IMDS 設定を確認
  • コンテナ環境なら hop limit が 2 以上か確認: aws ec2 describe-instances --query 'MetadataOptions.HttpPutResponseHopLimit'
ディスク容量枯渇(/ または /var のフルアップ)
想定される原因
  • ログファイルやコアダンプが蓄積してディスクを圧迫している
  • EBS ボリュームの初期サイズが小さすぎる
  • inode 数が枯渇(小さなファイルが多数作成された場合)
  • Docker イメージ/コンテナの残骸が蓄積
  • tmpfs の使いすぎ
確認手順
  • df -h で各マウントポイントのディスク使用量を確認
  • df -i で inode 使用率を確認
  • du -sh /* 2>/dev/null | sort -rh | head -20 で大きいディレクトリを特定
  • find /var/log -name '*.log' -size +100M でサイズの大きいログを特定
  • docker system df でDockerが消費している容量を確認
Nitro インスタンスのネットワーク帯域スロットリング
想定される原因
  • インスタンスタイプのネットワーク帯域上限(ベースライン)を超えた
  • 小さいインスタンスでバースト帯域クレジットが枯渇
  • ENA ドライバーが古いまたは設定ミス
  • プレイスメントグループ外で高帯域通信が発生している
  • VPC フローログの有効化による軽微なオーバーヘッド
確認手順
  • CloudWatch の NetworkIn/NetworkOut でスループット使用量を確認
  • インスタンスタイプのネットワーク帯域スペック(Gbps)を確認
  • ethtool -S eth0 | grep -i drop でパケットドロップを確認
  • iperf3 でスループット上限を実測
  • ena のドライババージョン確認: modinfo ena | grep ^version
Auto Scaling 起動失敗(インスタンス起動設定エラー)
想定される原因
  • 起動テンプレートに設定した AMI ID が存在しないまたはリージョン違い
  • スポットインスタンスの容量が不足(特定 AZ/インスタンスタイプ)
  • IAM インスタンスプロファイルが無効または存在しない
  • サブネットの IP アドレスが枯渇している
  • 起動テンプレートのバージョンが古く削除済みの設定を参照
確認手順
  • EC2 コンソール > Auto Scaling グループ > アクティビティで失敗理由を確認
  • aws autoscaling describe-scaling-activities でエラー詳細を取得
  • 起動テンプレートの AMI ID が該当リージョンに存在するか確認
  • IAM インスタンスプロファイルのポリシーが有効か確認
  • サブネットの使用可能 IP 数を確認(aws ec2 describe-subnets)
Systems Manager (SSM) エージェント接続不可
想定される原因
  • SSM エージェントが停止しているまたはバージョンが古い
  • インスタンスの IAM ロールに AmazonSSMManagedInstanceCore ポリシーが付与されていない
  • プライベートサブネットで SSM エンドポイント(VPC エンドポイント)が設定されていない
  • セキュリティグループで HTTPS(443) アウトバウンドが許可されていない
  • インスタンスが Systems Manager に登録されていない
確認手順
  • インスタンス内: sudo systemctl status amazon-ssm-agent で SSM エージェントの状態確認
  • IAM ロールに AmazonSSMManagedInstanceCore ポリシーがあるか確認
  • セキュリティグループで TCP 443 アウトバウンドが許可されているか確認
  • プライベートサブネット: com.amazonaws.<region>.ssm 等の VPC エンドポイントが作成済みか確認
  • AWS コンソール > Systems Manager > Fleet Manager でインスタンスが表示されるか確認
EC2 インスタンスメタデータサービス(IMDSv2)アクセス障害
想定される原因
  • IMDSv2必須設定でIMDSv1リクエスト(GETのみ)が拒否されている
  • SDKが古くIMDSv2(PUTでトークン取得後GET)に対応していない
  • コンテナからのIPホップ数がIMDSのhop_limit(デフォルト1)を超えている
  • IMDSが無効化されている(HttpEndpoint=disabled)
確認手順
  • IMDSv2トークン取得: PUT /latest/api/token を確認
  • aws ec2 describe-instances でMetadataOptions(HttpTokens)を確認
  • コンテナ環境でのhop_limit設定(ECS: 2が推奨)を確認
  • AWS SDKのバージョンがIMDSv2対応(boto3 1.9.5+等)か確認
EC2 EBSボリュームI/Oスロットリング(バーストクレジット枯渇)
想定される原因
  • gp2ボリュームのバーストクレジットが枯渇(バースト上限: 3000 IOPS)
  • io1/io2の設定IOPS上限に達している
  • インスタンスのEBS帯域幅制限に達している(インスタンスタイプ依存)
  • DBや大量ログ書き込みによる一時的なIOPS急増
確認手順
  • CloudWatchのEBSメトリクス(BurstBalance、VolumeQueueLength)を確認
  • BurstBalanceが0%になっていないか確認(gp2ボリューム)
  • io1/io2のIOPS実績と設定値を比較
  • インスタンスタイプのEBS最大帯域幅制限を確認
EC2 Systems Manager Session Manager 接続不可
想定される原因
  • EC2インスタンスにAmazonSSMManagedInstanceCoreポリシーを持つIAMロールがない
  • SSM Agentが停止または古いバージョン
  • プライベートサブネットにSSM/SSMMessages/EC2MessagesのVPCエンドポイントがない
  • インスタンスのセキュリティグループがアウトバウンドHTTPSを許可していない
確認手順
  • aws ssm describe-instance-information でインスタンスの管理状態を確認
  • インスタンスのIAMロールにAmazonSSMManagedInstanceCoreポリシーを確認
  • SSM AgentのステータスをRun Command経由またはSystem Logで確認
  • プライベートサブネットのVPCエンドポイント(com.amazonaws.ssm等)を確認
EC2 Placement Group 起動失敗(InsufficientCapacity)
想定される原因
  • クラスタープレイスメントグループで要求したインスタンス数分の物理ホストキャパシティが不足
  • プレイスメントグループへのインスタンス追加時に既存グループと同一ハードウェア不足
  • 既存インスタンスを停止→再起動した際に同一物理ホストに再配置できない
  • インスタンスタイプがプレイスメントグループに対応していない
確認手順
  • エラーメッセージのInsufficientCapacityとプレイスメントグループの関係を確認
  • プレイスメントグループのタイプ(Cluster/Spread/Partition)を確認
  • リクエストしているインスタンスタイプとプレイスメントグループの互換性を確認
  • AZを変更することでキャパシティが確保できるか確認
タスク起動失敗(essential container exited)
想定される原因
  • アプリケーションの起動エラー(環境変数不足、設定ファイルミス)
  • 依存サービス(DB、API)への接続失敗でプロセスが終了
  • ヘルスチェックの連続失敗でコンテナが強制終了
  • メモリ不足で OOM Killed(exit code 137)
  • コンテナイメージのエントリポイント/コマンド設定ミス
確認手順
  • CloudWatch Logs でコンテナのアプリケーションログを確認(exit code 直前の行が重要)
  • ECS コンソール > クラスター > サービス > タスク > 停止理由を確認
  • aws ecs describe-tasks で stopCode と stoppedReason を取得
  • exit code 137 → OOMKilled、143 → SIGTERM、1 → アプリエラー
  • タスク定義の環境変数・シークレット設定を確認
Fargate タスクがリソース不足で起動できない
想定される原因
  • 特定 AZ での Fargate Spot 容量が一時的に不足
  • 特定リージョン/AZ でのキャパシティ制約
  • タスク定義の vCPU/メモリ組み合わせが Fargate でサポートされていない
  • アカウントの同時タスク数クォータに達した
確認手順
  • ECS コンソール > サービス > イベントで配置失敗の詳細を確認
  • aws ecs describe-services でサービスのイベントを取得
  • タスク定義の CPU/メモリ組み合わせが有効な組み合わせか確認(Fargate の対応表)
  • AWS Service Quotas でアカウントの ECS タスク同時実行上限を確認
  • 複数 AZ にサブネットが設定されているか確認
ECR イメージプル失敗(認証エラー)
想定される原因
  • タスク実行ロール(ecsTaskExecutionRole)に ecr:GetAuthorizationToken 権限がない
  • タスク実行ロールに ecr:BatchGetImage / ecr:GetDownloadUrlForLayer 権限がない
  • 指定したイメージタグが ECR に存在しない(削除済みまたはスペルミス)
  • クロスアカウントの ECR リポジトリへのアクセス権がない
  • ECR リポジトリがプライベートで VPC エンドポイントが未設定
確認手順
  • aws ecr get-authorization-token でトークン取得が成功するか確認
  • ECS タスク実行ロールに AmazonECSTaskExecutionRolePolicy があるか確認
  • aws ecr describe-images で対象タグが存在するか確認
  • Fargate + プライベートサブネット: ECR の VPC エンドポイントが設定されているか確認
  • タスク定義の image URI(リポジトリ名・タグ・リージョン)が正確か確認
ECS サービスの ALB ヘルスチェック失敗
想定される原因
  • ヘルスチェックパス(/health 等)がアプリに実装されていない
  • ヘルスチェックのタイムアウトがアプリの応答時間より短い
  • コンテナポートとターゲットグループのポートが一致していない
  • アプリの起動が遅くてヘルスチェック猶予期間内に準備できない
  • セキュリティグループでロードバランサーからのヘルスチェックポートが許可されていない
確認手順
  • ALB コンソール > ターゲットグループ > ターゲットタブで不健全の詳細理由を確認
  • ヘルスチェックパスに curl でアクセスして 200 を返すか確認
  • タスク定義のコンテナポートとターゲットグループのポートが一致するか確認
  • セキュリティグループでコンテナポートへのインバウンドが ALB から許可されているか確認
  • ECS サービスのヘルスチェック猶予期間(health_check_grace_period_seconds)の設定値を確認
ECS タスクが Secrets Manager / Parameter Store から値を取得できない
想定される原因
  • タスク実行ロールに Secrets Manager の GetSecretValue 権限がない
  • シークレットを暗号化している KMS キーへの復号権限がない
  • シークレット名またはパラメータパスのスペルミス
  • シークレットが存在しない(別リージョン・別アカウント)
  • Parameter Store の SecureString パラメータへの kms:Decrypt 権限がない
確認手順
  • aws secretsmanager get-secret-value --secret-id <name> で取得できるか確認
  • タスク実行ロールのポリシーに secretsmanager:GetSecretValue があるか確認
  • KMS キーポリシーにタスク実行ロールの Decrypt アクションが許可されているか確認
  • シークレット名の ARN がタスク定義で指定したものと一致するか確認
  • プライベートサブネット: Secrets Manager / SSM の VPC エンドポイントが設定されているか確認
ECS サービスのデプロイが DEPLOYMENT_CIRCUIT_BREAKER でロールバック
想定される原因
  • 新バージョンのコンテナが起動に失敗している(アプリエラー、設定ミス)
  • ヘルスチェックが連続失敗して新タスクが Unhealthy と判定された
  • デプロイ中に必要なリソース(シークレット、設定値)が取得できない
  • 新イメージの起動時間が長くてヘルスチェックタイムアウトを超えた
  • コードの不具合で起動直後にクラッシュする
確認手順
  • ECS コンソール > サービス > デプロイ > 失敗タスクのログを CloudWatch で確認
  • aws ecs describe-services でデプロイの rolloutState と rolloutStateReason を確認
  • 停止したタスクの stoppedReason(exit code)を確認
  • 新バージョンイメージをローカルで動作確認
  • ALB ターゲットグループの不健全ターゲットの理由を確認
タスク間通信障害(サービスディスカバリー / Cloud Map エラー)
想定される原因
  • Cloud Map のサービスにタスクが未登録(ヘルスチェック失敗で除外)
  • サービスディスカバリーの DNS 名前空間が異なる VPC を参照している
  • セキュリティグループでタスク間通信のポートが許可されていない
  • Cloud Map の SRV レコードの TTL 期間内にキャッシュが古い情報を返している
  • ECS タスクのサブネットが名前空間と異なる VPC に存在する
確認手順
  • aws servicediscovery list-instances でサービスのインスタンス登録状況を確認
  • タスク内から nslookup <service-name>.<namespace>.local でDNS解決を確認
  • Cloud Map ヘルスチェックの設定とタスクのヘルス状態を確認
  • セキュリティグループで必要なポートがタスク間で許可されているか確認
  • 同じ VPC・サブネット内でのみ動作しているか確認
ECS Exec(コンテナシェル接続)が失敗する
想定される原因
  • タスク定義または ECS サービスで ExecuteCommand が有効化されていない
  • タスクロールに ssmmessages アクションの権限がない
  • Fargate + プライベートサブネット: SSM メッセージエンドポイントへの疎通がない
  • タスクがまだ起動中または停止している
  • AWS CLI のバージョンが古く ECS Exec をサポートしていない
確認手順
  • aws ecs describe-tasks で enableExecuteCommand が true か確認
  • タスクロールに ssmmessages:CreateControlChannel 等の権限があるか確認
  • aws ecs execute-command --interactive --command /bin/sh で実際に接続試行
  • プライベートサブネット: com.amazonaws.<region>.ssmmessages VPC エンドポイントを確認
  • AWS CLI v2.x 以降を使用しているか確認(v1 では ECS Exec 非対応)
ECS タスクのログが CloudWatch に出力されない
想定される原因
  • タスク定義で指定した CloudWatch Logs グループが事前に作成されていない
  • タスク実行ロールに logs:CreateLogGroup / PutLogEvents 権限がない
  • awslogs の設定(region / group / stream-prefix)が誤っている
  • タスク定義でログ設定が awslogs 以外または未設定
  • CloudWatch Logs のリテンション設定で古いログが削除されている
確認手順
  • aws logs describe-log-groups でロググループが存在するか確認
  • タスク実行ロールに logs:CreateLogGroup と logs:PutLogEvents があるか確認
  • タスク定義の logConfiguration の awslogs-group, awslogs-region を確認
  • ECS コンソール > タスク > ログタブでログの出力状況を確認
  • awslogs-create-group: true 設定で自動作成が有効か確認
ECS Auto Scaling がスケールしない(クールダウン・メトリクス設定ミス)
想定される原因
  • スケールアウトのクールダウン期間中でスケールが抑制されている
  • ターゲット追跡スケーリングのターゲット値が高すぎてスケールが発動しない
  • CloudWatch メトリクスにデータがない(コンテナから出力されていない)
  • サービスの最大タスク数(Max capacity)に達している
  • Application Auto Scaling ロールに ECS への権限がない
確認手順
  • ECS コンソール > サービス > Auto Scaling の現在のキャパシティと設定を確認
  • CloudWatch のスケーリングメトリクス(CPU 使用率など)を確認
  • Application Auto Scaling のスケーリングアクティビティを確認
  • aws application-autoscaling describe-scaling-activities でスケールの履歴を確認
  • 現在のタスク数が Max capacity に達していないか確認
ECS Service Connect サービス間通信障害
想定される原因
  • Service ConnectのCloudMapネームスペースが正しく設定されていない
  • サービス定義のportMappingsとService Connect設定の不一致
  • Envoyプロキシコンテナが起動失敗している
  • タスクのIAMロールにCloudMapの読み取り権限がない
確認手順
  • ECSサービスのService Connect設定でnamespaceとserviceNameを確認
  • タスク定義のportMappingsでnamを確認(Service Connect用のエイリアス)
  • Envoyプロキシコンテナのログを確認
  • CloudMapのサービスレジストリでヘルスチェック状態を確認
ECS Exec(シェルアクセス)接続失敗
想定される原因
  • ECSサービスでenableExecuteCommandが有効化されていない
  • タスクIAMロールにSSM Session Managerの必要な権限がない
  • コンテナ内にSSMエージェントがインストールされていない(Fargate v1.4.0+は不要)
  • VPCエンドポイント(com.amazonaws.ssm等)が存在しないプライベートサブネット
確認手順
  • aws ecs describe-services でenableExecuteCommandをtrueに確認
  • タスクIAMロールのSSM権限(ssmmessages:CreateControlChannel等)を確認
  • aws ecs execute-command --interactive --command /bin/sh を実行してエラー詳細確認
  • VPCにSSM/SSMMessages/EC2MessagesのVPCエンドポイントがあるか確認
ECS タスク定義のシークレット取得失敗(Secrets Manager/SSM)
想定される原因
  • タスク実行ロールにsecretsmanager:GetSecretValueまたはssm:GetParametersの権限がない
  • シークレット/パラメータのARNが誤っている
  • KMSカスタムキーで暗号化されたシークレットでKMS復号権限がない
  • クロスアカウントのシークレット参照でリソースポリシーが未設定
確認手順
  • ECSタスク実行ロールのIAMポリシーを確認
  • タスク定義のsecrets/environmentのARNが正しいか確認
  • KMS CMKを使用している場合、タスク実行ロールにkms:Decrypt権限を確認
  • aws secretsmanager get-secret-value でAWS CLIで直接取得を試行
ECS Fargate タスクのサブネット・SG設定ミスによる起動失敗
想定される原因
  • プライベートサブネットでのFargate起動時にNAT GatewayまたはVPCエンドポイントが不足
  • サブネットのIPアドレスが枯渇しENIが作成できない
  • セキュリティグループがアウトバウンドを制限してECRからのイメージプルに失敗
  • 指定サブネットがFargate非対応AZにある
確認手順
  • ECSコンソールのタスクの停止理由を確認
  • サブネットの利用可能なIPアドレス数を確認
  • プライベートサブネットからのアウトバウンドルートを確認(NAT GatewayまたはVPCエンドポイント)
  • SGのアウトバウンドルール(443, 最低限)を確認
Lambda タイムアウト(実行時間上限超過)
想定される原因
  • タイムアウト設定が処理に必要な時間より短い
  • 外部API/DBへの同期呼び出しでレスポンス待ちが発生
  • データ量が多く処理時間が予測より長くなった
  • DBコネクションプール枯渇でキュー待ち
  • コールドスタート + 重い初期化処理でタイムアウト
確認手順
  • CloudWatch Logs の 'Task timed out' メッセージと実行時間を確認
  • X-Ray トレースで処理のどのステップに時間がかかっているか特定
  • Lambda コンソールでタイムアウト設定値を確認
  • 外部呼び出し(DB, API)にタイムアウト設定があるか確認
  • CloudWatch の Duration メトリクスの P90/P99 を確認
Lambda メモリ不足(OOM)
想定される原因
  • Lambda のメモリ設定が処理に必要な量より少ない
  • 大きなファイルや大量データをメモリ上で展開している
  • メモリリーク(グローバル変数への蓄積)
  • JVM/Node.js のヒープ設定がメモリ割当てに追いついていない
  • 再帰処理などでスタックオーバーフロー
確認手順
  • CloudWatch Logs の REPORT 行で 'Max Memory Used' を確認
  • Max Memory Used が設定値に近い(90%以上)場合はメモリ不足のサイン
  • Lambda Power Tuning ツールでコスト効率の良いメモリ量を算出
  • グローバル変数に状態を蓄積しているコードがないか確認
  • 実際の処理データサイズと必要メモリを見積もる
Lambda コールドスタートによるレイテンシ増大
想定される原因
  • コンテナが再利用されず新規起動が発生した(コールドスタート)
  • 初期化コード(ハンドラー外)で重い処理を行っている
  • デプロイパッケージが大きくロードに時間がかかる
  • VPC Lambda で ENI 作成が遅延する
  • Provisioned Concurrency が未設定で低トラフィック時の遅延が発生
確認手順
  • CloudWatch Logs の REPORT 行で Init Duration の有無を確認(コールドスタートのサイン)
  • X-Ray のトレースで Initialization セグメントの時間を確認
  • デプロイパッケージのサイズを確認(aws lambda get-function)
  • VPC Lambda か否かを確認(VPCではENI作成が遅延する場合あり)
  • CloudWatch の InitDuration メトリクス(カスタム)でコールドスタート頻度を確認
Lambda 同時実行数の上限超過(throttling)
想定される原因
  • アカウントの同時実行数上限(デフォルト 1000)に達した
  • 関数に設定した予約済み同時実行数が低すぎる
  • バースト処理で急激にリクエストが増加した
  • 同一アカウントの別関数が同時実行数を大量に消費している
  • SQS トリガーのバッチサイズが大きすぎて一気に同時実行数を消費
確認手順
  • CloudWatch の Throttles メトリクスを確認
  • CloudWatch の ConcurrentExecutions メトリクスでアカウント全体の使用状況を確認
  • Lambda コンソールで関数の予約済み同時実行数の設定を確認
  • Service Quotas でアカウントの同時実行数上限を確認
  • CloudWatch の UnreservedConcurrentExecutions で残り枠を確認
Lambda から RDS/Aurora への接続エラー(VPC 設定ミス)
想定される原因
  • Lambda のセキュリティグループが RDS のセキュリティグループのインバウンドルールに含まれていない
  • Lambda が VPC に設定されていない(RDS は VPC 内にある)
  • Lambda と RDS が異なるサブネット/VPC に存在する
  • データベースのコネクション数が上限に達している
  • RDS のセキュリティグループでポート3306/5432が許可されていない
確認手順
  • Lambda の VPC 設定で RDS と同じ VPC のサブネットを使用しているか確認
  • RDS のセキュリティグループのインバウンドルールに Lambda のセキュリティグループが含まれているか確認
  • RDS コンソールで現在のコネクション数と上限を確認
  • Lambda 関数のサブネットが RDS と同じ VPC 内にあるか確認
  • VPC フローログで Lambda からの通信がブロックされていないか確認
Lambda デッドレターキュー(DLQ)への大量メッセージ投入
想定される原因
  • 非同期呼び出しが最大試行回数を超えてエラーになり DLQ に投入された
  • Lambda 関数自体のエラー(バグ)によるリトライ失敗
  • Lambda のタイムアウト・OOM による繰り返し失敗
  • DLQ のメッセージを処理するロジックが未実装
  • Destination on Failure の設定ミス
確認手順
  • DLQ(SQS)のメッセージ数と内容を確認して失敗の理由を特定
  • CloudWatch Logs で Lambda のエラーログを確認
  • aws lambda get-function-event-invoke-config で最大再試行回数を確認
  • DLQ に届いたメッセージのボディからリクエストを再構築してデバッグ
  • CloudWatch の Errors メトリクスで失敗率を確認
Lambda 環境変数 / Secrets の取得失敗
想定される原因
  • Lambda コンソール/Terraform で環境変数の設定漏れ
  • 環境変数の暗号化に使用した KMS キーへの復号権限がない
  • 本番・開発の設定を取り違えた
  • デプロイ時に環境変数の上書き・削除をしてしまった
  • Secrets Manager 参照の ARN がずれている
確認手順
  • Lambda コンソール > 設定 > 環境変数で設定値を確認
  • aws lambda get-function-configuration で環境変数一覧を取得
  • KMS 暗号化している場合: Lambda 実行ロールに kms:Decrypt があるか確認
  • 実際の環境変数をコードでダンプして値が正しいか確認
  • IaC(CDK/Terraform)の最新状態と実際の設定が一致しているか確認
Lambda レイヤーのロード失敗
想定される原因
  • Lambda レイヤーのディレクトリ構造が正しくない(/python/, /nodejs/ 等)
  • レイヤーの Lambda ランタイムとバージョンが一致していない
  • レイヤーのアクセス許可が設定されていない(クロスアカウント)
  • レイヤーが削除または別バージョンに差し替えられた
  • ライブラリのバージョン衝突
確認手順
  • Lambda コンソール > レイヤーで指定しているレイヤーとバージョンを確認
  • レイヤーの ZIP 内のディレクトリ構造を確認(python/lib/python3.x/site-packages/)
  • レイヤーのランタイム互換リストに Lambda の実行ランタイムが含まれているか確認
  • aws lambda get-layer-version でレイヤーの詳細を取得
  • ローカルで同じランタイムを使って import を確認
Lambda の IAM 権限不足(AccessDeniedException)
想定される原因
  • Lambda 実行ロールのポリシーに必要な権限が付与されていない
  • S3 バケットポリシーや DynamoDB リソースポリシーで Lambda ロールへのアクセスが制限されている
  • KMS キーポリシーで Lambda ロールへの操作が許可されていない
  • IAM 境界(Permission Boundary)で権限が制限されている
  • SCP(Service Control Policy)で組織レベルで制限されている
確認手順
  • CloudWatch Logs のエラーで 'not authorized to perform' の action と resource を特定
  • Lambda 実行ロールのポリシーに必要なアクションが含まれているか確認
  • IAM Policy Simulator でテスト実行
  • 対象リソース(S3, DynamoDB 等)のリソースポリシーを確認
  • aws iam simulate-principal-policy でシミュレーション
Lambda のデプロイパッケージサイズ超過
想定される原因
  • 依存ライブラリ(node_modules, pip packages)が大きい
  • テスト用ファイルやドキュメントを本番パッケージに含めている
  • 開発用ツール(devDependencies)を本番パッケージに含めている
  • バイナリファイルや大きなモデルファイルを同梱している
  • ZIP 制限: 50MB(直接アップロード)、250MB(展開後)
確認手順
  • zip ファイルのサイズを確認(50MB 超は S3 経由でないとアップロード不可)
  • 展開後のディレクトリサイズを du -sh で確認
  • node_modules または site-packages の中で最も大きいライブラリを特定
  • 必要なライブラリのみが含まれているか確認(devDependencies が混入していないか)
  • Lambda コンソールで現在のコードサイズを確認
Lambda SnapStart コールドスタート遅延(Java)
想定される原因
  • SnapStartのスナップショットが古く、関数更新後に再作成中
  • OnRestoreフック内でのシークレット取得などの重い処理
  • SnapStart非対応のJavaランタイムを使用(Java 11以降のcorrettoが必要)
  • スナップショット内のランダム値(UUID等)が復元後に再利用され問題発生
確認手順
  • CloudWatch LogsでINIT_TYPEとDURATIONを確認(SnapStart使用時はRESTOREが表示)
  • SnapStartが有効化されているか(PublishedVersionのみ対応)を確認
  • OnRestoreフックの処理時間を計測
  • Java 17/21のcorretto(managed runtime)を使用しているか確認
Lambda レスポンスストリーミング(Response Streaming)タイムアウト
想定される原因
  • Lambdaの最大タイムアウト(15分)に達してストリーミングが切断
  • クライアント側のHTTP接続タイムアウトがLambdaより短い
  • Function URLを経由しているが非ストリーミングモードで設定
  • ALB + Lambdaではストリーミング非対応
確認手順
  • Lambda関数のタイムアウト設定を確認(最大900秒)
  • Function URLの呼び出しモード(BUFFERED vs RESPONSE_STREAM)を確認
  • クライアントのHTTPタイムアウト設定を確認
  • AWS SDKの InvokeWithResponseStream APIを使用しているか確認
RDS コネクション数上限到達
想定される原因
  • インスタンスクラスに対してmax_connectionsが少ない(インスタンスメモリに依存)
  • Lambda や ECS からコネクションプールなしで多数接続が発生
  • アプリケーションのコネクション未クローズ(リーク)
  • long-running transaction でコネクションが解放されない
  • RDS Proxy を使わず Lambda から直接接続している
確認手順
  • SELECT count(*) FROM pg_stat_activity; でアクティブ接続数を確認(PostgreSQL)
  • SHOW STATUS LIKE 'Threads_connected'; でMySQL接続数を確認
  • CloudWatch の DatabaseConnections メトリクスを確認
  • 接続元(アプリサーバー)のコネクションプール設定を確認
  • SELECT * FROM pg_stat_activity WHERE state = 'idle' でアイドル接続数を確認
RDS フェイルオーバー後の接続エラー
想定される原因
  • Multi-AZ のフェイルオーバー(計画外:ハードウェア障害・AZ障害)
  • 手動フェイルオーバー実行後にアプリが古い接続を保持
  • Aurora のリーダー昇格後にアプリの Writer エンドポイント接続が切断
  • メンテナンスウィンドウの再起動
  • RDS の強制再起動(パラメータグループ変更後)
確認手順
  • RDS コンソール > イベントでフェイルオーバーの発生日時と理由を確認
  • CloudWatch の FailedSQLServerAgentJobsCount / DatabaseConnections の急落を確認
  • アプリのコネクションプールが再接続設定(reconnect: true)になっているか確認
  • Aurora なら Cluster エンドポイント(Writer)を使用しているか確認(インスタンスエンドポイント直接参照は NG)
  • VPC DNS の TTL がキャッシュに影響していないか確認
RDS CPU 使用率の急上昇(クエリ問題)
想定される原因
  • インデックスが存在しないカラムへの検索(フルテーブルスキャン)
  • N+1 問題(ループ内でDBクエリを繰り返し発行)
  • 大量データの JOIN や集計クエリ
  • 古くなった統計情報によるクエリプランの劣化
  • コネクション急増によるDBへの負荷集中
確認手順
  • Performance Insights でトップSQL(CPU 消費上位)を確認
  • CloudWatch の CPUUtilization と DatabaseConnections を相関確認
  • スロークエリログを有効化: SET GLOBAL slow_query_log = 1
  • EXPLAIN ANALYZE で問題クエリの実行計画を確認
  • Performance Insights の Wait Events でボトルネックの種類を特定
RDS ストレージ容量不足
想定される原因
  • データの増加でストレージが枯渇
  • binlog(MySQL)や WAL(PostgreSQL)ファイルが蓄積
  • ストレージの自動スケーリングが無効
  • 多数のスナップショットが保存されている
  • 大量のテーブル/インデックスが作成されて肥大化
確認手順
  • CloudWatch の FreeStorageSpace メトリクスを確認(バイト単位)
  • RDS コンソールでストレージの使用量とアロケーション量を確認
  • SHOW MASTER STATUS; でbinlogの蓄積を確認(MySQL)
  • SELECT pg_size_pretty(pg_database_size(current_database())); でDB全体サイズ確認(PostgreSQL)
  • 自動スケーリング設定の有効/無効を確認
Aurora レプリカラグの増大
想定される原因
  • Writer への大量の書き込みがReader の追従を上回っている
  • Reader インスタンスのCPUやI/Oが高負荷でログの適用が遅れている
  • 長時間のクエリがReader でロックを保持してレプリケーション適用を阻止
  • Reader と Writer のインスタンスクラスが大きく異なる
  • 一時的な大量バルクインサート・UPDATE による書き込みスパイク
確認手順
  • CloudWatch の AuroraReplicaLag メトリクスを確認
  • SHOW SLAVE STATUS\G でラグの詳細を確認(MySQL互換)
  • Performance Insights でReader上の重いクエリを確認
  • Reader のCPU・I/O使用率を確認
  • CloudWatch の DDLThroughput, DMLThroughput で書き込み量を確認
RDS Parameter Group 変更後の再起動エラー
想定される原因
  • 静的パラメータ(static)の変更は再起動が必要
  • パラメータグループを変更後にインスタンスを再起動していない
  • カスタムパラメータグループをインスタンスに適用していない(デフォルトのまま)
  • Aurora クラスター変更とインスタンス変更の順序が逆
確認手順
  • RDS コンソールのインスタンス詳細で Parameter Group ステータスが in-sync か pending-reboot か確認
  • aws rds describe-db-instances でパラメータグループのステータスを確認
  • 変更したパラメータが static か dynamic かを確認(static は再起動必要)
  • Aurora の場合クラスターとインスタンス両方のパラメータグループを確認
RDS SSL/TLS 証明書の期限切れ
想定される原因
  • RDS CA 証明書(rds-ca-2019)の有効期限切れ(2024年8月に期限)
  • アプリケーションの証明書バンドルが古い
  • SSL 接続が強制されているが証明書の更新をしていない
  • RDS インスタンスが古い CA を使用したまま更新されていない
確認手順
  • RDS コンソールで各インスタンスの 'Certificate Authority' を確認
  • aws rds describe-db-instances で CACertificateIdentifier を確認
  • 接続文字列の SSL 設定と証明書ファイルのパスを確認
  • openssl s_client -connect <rds-endpoint>:5432 で証明書を確認
RDS 自動バックアップ失敗
想定される原因
  • ストレージ容量が不足していてスナップショット作成に失敗
  • バックアップウィンドウとメンテナンスウィンドウが重複している
  • バックアップ保持期間が 0 に設定されていて自動バックアップが無効
  • 一時的な AWS インフラの問題
確認手順
  • RDS コンソール > スナップショットで失敗したスナップショットのステータスを確認
  • CloudWatch で FreeStorageSpace を確認
  • バックアップウィンドウとメンテナンスウィンドウの重複を確認
  • BackupRetentionPeriod が 0 でないか確認(0 = 自動バックアップ無効)
  • RDS イベントサブスクリプションでバックアップ失敗通知を設定しているか確認
RDS Proxy の接続プール枯渇
想定される原因
  • RDS Proxy のコネクションプールが全て使用中でタイムアウト
  • RDS インスタンス側の max_connections に対して Proxy のプールが大きすぎる
  • ピン留め(Pinning)が頻発してコネクションが再利用されない
  • 接続のボローイングタイムアウト設定が短すぎる
  • 実際のワークロードが想定より多い
確認手順
  • CloudWatch の ProxyClientConnections と DBConnections を確認
  • RDS コンソール > プロキシ > メトリクスでプール使用率を確認
  • ピン留めが多発していないか(SET ステートメント、一時テーブルなどが原因)
  • RDS インスタンスの max_connections と Proxy の MaxConnectionsPercent を比較
  • CloudWatch の ProxyQueryRequests と ProxyLatency を確認
RDS Multi-AZフェイルオーバー後の接続切断
想定される原因
  • Multi-AZフェイルオーバー時の30〜120秒のダウンタイム(正常動作)
  • アプリケーションが古いIPをDNSキャッシュに保持(TTL問題)
  • コネクションプールがフェイルオーバー後に再接続しない設定
  • RDSエンドポイントのDNS TTL(5秒)よりアプリのDNSキャッシュTTLが長い
確認手順
  • RDSイベントログでフェイルオーバーの完了を確認
  • nslookup/dig でRDSエンドポイントのDNS解決を確認
  • アプリケーションのコネクションプール設定(testOnBorrow, validationQuery等)
  • RDS Proxy使用で透過的フェイルオーバーが可能か検討
RDS Performance Insights有効時の高負荷クエリ特定
想定される原因
  • インデックスが適切に設定されていないクエリによるフルテーブルスキャン
  • N+1クエリ問題によるDB呼び出し爆発
  • メンテナンスウィンドウ外でのANALYZE/VACUUMによる負荷
  • コネクションプール不足による接続のキューイング
確認手順
  • Performance InsightsのTop SQLでDBロードの高いクエリを特定
  • Wait EventでCPU/IO/Lockのどれが支配的か確認
  • EXPLAIN ANALYZEで問題クエリの実行計画を確認
  • pg_stat_statementsでクエリ統計を確認(PostgreSQL)
RDS Aurora Serverless v2 スケーリング遅延によるタイムアウト
想定される原因
  • minACUが低すぎて(0.5 ACU等)スケールアップに数秒〜数十秒かかる
  • トラフィックスパイクがスケール速度を上回っている
  • maxACUに達して追加スケールが不能
  • コネクション数がACU数に対して過多
確認手順
  • CloudWatchのServerlessDatabaseCapacityメトリクスでACU推移を確認
  • minとmaxのACU設定値を確認
  • スパイク時のコネクション数とACU数の相関を確認
  • RDS Proxy使用でコネクションプーリングが有効か確認
ALB 502 Bad Gateway(バックエンドからの不正応答)
想定される原因
  • バックエンドがHTTPではなく他プロトコル応答を返した
  • バックエンドがリクエストに対して無応答でタイムアウト
  • ALBのアイドルタイムアウト(デフォルト60秒)をバックエンドが先に切断
  • バックエンドのヘルスチェックが失敗して全ターゲットがUnhealthy
  • HTTP/2のprotocol errorによる切断
確認手順
  • ALBアクセスログの target_status_code と elb_status_code の組み合わせを確認(502は-と502)
  • ターゲットグループのヘルスチェックで不健全なターゲットを確認
  • バックエンドアプリのエラーログでリクエスト処理エラーを確認
  • ALBのアイドルタイムアウト設定とバックエンドのKeep-Aliveタイムアウトを比較
  • CloudWatch の HTTPCode_ELB_502_Count を確認
ALB 504 Gateway Timeout(バックエンド応答タイムアウト)
想定される原因
  • バックエンドの処理時間がALBのアイドルタイムアウト(デフォルト60秒)を超えた
  • 重い処理(DB集計、外部API待ち)でレスポンスが遅延
  • バックエンドのコネクションプール枯渇でリクエストがキューで待機
  • バックエンドのCPU/メモリ高負荷
確認手順
  • ALBアクセスログのrequest_processing_time / target_processing_time / response_processing_timeを確認
  • CloudWatch の TargetResponseTime P95/P99 を確認
  • バックエンドアプリのAPMまたはX-Rayで遅いエンドポイントを特定
  • ALBのアイドルタイムアウト設定値を確認(デフォルト60秒)
  • バックエンドインスタンスのCPU/メモリ使用率を確認
ALB ターゲットグループにヘルシーターゲットがない(503)
想定される原因
  • バックエンドインスタンス/タスクが全てダウンしている
  • ヘルスチェックパスが存在しないかエラーを返している
  • デプロイ中のローリングアップデートで一時的にゼロになっている
  • ターゲットグループが空(インスタンスが登録されていない)
  • セキュリティグループでヘルスチェックポートがブロックされている
確認手順
  • ALBコンソール > ターゲットグループ > ターゲットタブで各ターゲットのステータスを確認
  • 不健全ターゲットの詳細理由(503 / Connection timeout / etc.)を確認
  • ヘルスチェックエンドポイントに直接 curl でアクセスして応答を確認
  • ECS/EC2コンソールでバックエンドインスタンスの状態を確認
  • セキュリティグループでALBからのヘルスチェックポートが許可されているか確認
ALB SSL/TLS 証明書のエラー(HTTPS 接続失敗)
想定される原因
  • ACM 証明書の有効期限切れ(自動更新失敗)
  • 証明書のドメインとアクセスしているドメインが一致しない
  • 証明書が ALB リスナーに正しくアタッチされていない
  • ACM の自動更新に必要な DNS 検証レコードが削除された
確認手順
  • ACM コンソールで証明書の有効期限とドメイン名を確認
  • ACM の更新ステータス(PENDING_VALIDATION / FAILED)を確認
  • ALB コンソール > リスナー > 証明書タブで証明書が正しくアタッチされているか確認
  • Route 53 で ACM 検証用の CNAME レコードが存在するか確認
  • openssl s_client -connect <alb-dns>:443 で証明書の詳細を確認
ALB リクエストルーティング設定ミス(意図しない 404)
想定される原因
  • リスナールールのパスパターンが実際のリクエストパスと一致していない
  • ホストヘッダーのルール設定でドメイン名が違う
  • ルールの優先度が逆で先にデフォルトルールが評価されている
  • トレイリングスラッシュの有無でマッチしない
確認手順
  • ALBコンソール > リスナー > ルールで各ルールのパターンと優先度を確認
  • ALBアクセスログでリクエストのパスとマッチしたルールを確認
  • 実際のリクエストパス(/api/v1/ vs /api/v1)とルールを照合
  • ルールの優先度番号を確認(小さい数字が先に評価)
ALB スティッキーセッション(セッション固定)の問題
想定される原因
  • スティッキーセッションの持続時間がセッションの実際の使用時間より短い
  • オートスケーリングでターゲットが削除されてセッションが失われた
  • スティッキーセッションが無効なのにアプリがセッションをインメモリで管理している
  • 負荷が特定ターゲットに集中してパフォーマンス劣化
確認手順
  • ターゲットグループのスティッキーセッション設定を確認
  • スティッキーセッションの持続時間とアプリのセッション TTL を比較
  • オートスケーリングが発生しているか確認
  • ターゲット間の負荷分散が偏っていないか確認
ALB アクセスログの S3 書き込み失敗
想定される原因
  • S3 バケットポリシーにELBサービスアカウントの書き込み権限がない
  • 指定したS3バケットが存在しないまたはリージョンが違う
  • S3バケットのプレフィックスの末尾にスラッシュが不要
確認手順
  • S3バケットポリシーにELBサービスアカウント(リージョンごとに異なる)の権限があるか確認
  • バケット名とリージョンが正しいか確認
  • ALBコンソール > 属性 > アクセスログのステータスを確認
ALB WAF によるリクエストブロック(403 Forbidden)
想定される原因
  • 正規リクエストがWAFのマネージドルールに誤検知された
  • 特定のIPアドレスがIPブロックリストに追加されている
  • リクエストヘッダーやボディがSQLインジェクション/XSSルールにマッチ
  • WAFのレートリミットルールを超えた
  • CountモードではなくBlockモードに設定されている
確認手順
  • AWS WAFコンソール > ウェブACL > 概要でブロックされたリクエスト数を確認
  • WAFのサンプルリクエストでブロックされたルール名を確認
  • CloudWatch LogsのWAFログで詳細なルールマッチ情報を確認
  • WAFのルールをCountモードに変更して誤検知かどうか確認
  • ブロックされたIPが正規のクライアントか確認
ALB WebSocketアップグレード失敗
想定される原因
  • ALBリスナーのWebSocket対応が未設定
  • バックエンドがWebSocketアップグレードに対応していない
  • Security Groupが長時間接続のidleタイムアウトで切断
  • wss://の場合SSL終端の設定ミス
確認手順
  • ALBリスナーのプロトコルがHTTP/HTTPSであることを確認(NLBはTCP必要なケースあり)
  • ターゲットグループのヘルスチェックパスとWebSocketエンドポイントの整合性確認
  • ALBのアイドルタイムアウト設定(デフォルト60秒)を延長
  • クライアントのwsライブラリがリトライロジックを持つか確認
ALBアクセスログS3書き込み失敗・ログ欠損
想定される原因
  • S3バケットポリシーにELBサービスプリンシパルの書き込み許可がない
  • バケットのリージョンとALBのリージョンが不一致
  • S3バケットのSSE-CMKによる暗号化でELBがキーにアクセスできない
  • ログプレフィックスの設定ミス
確認手順
  • S3バケットポリシーに delivery.logs.amazonaws.com のPutObject許可があるか確認
  • ALBのリージョンとS3バケットのリージョンが同じか確認
  • SSE-KMSの場合、ELBサービスにKMSキーの使用許可を付与
  • ALBのアクセスログ設定でEnabled=trueを確認
ALB Lambda ターゲット503/接続失敗
想定される原因
  • LambdaのリソースポリシーにALBからの呼び出し許可がない
  • LambdaがALBのリクエスト形式に対応するレスポンス形式を返していない
  • LambdaのタイムアウトがALBの待機時間より短い
  • Lambda関数が特定リージョンのALBからの呼び出しを許可していない
確認手順
  • Lambda関数のリソースポリシーでelasticloadbalancing.amazonaws.comのinvokeを確認
  • Lambda関数が正しいALB形式のJSONレスポンス(statusCode/headers/body)を返しているか確認
  • ALBターゲットグループのヘルスチェック設定を確認
  • CloudWatch LogsでLambdaのエラーを確認
ALB 認証アクション(Cognito/OIDC)による認証ループ
想定される原因
  • ALBがセッションクッキーを設定するがクライアントがクッキーを保存しない
  • OIDCのcallback URLがALBのDNS名と一致しない
  • セッションタイムアウトが短すぎてアクセスのたびに再認証
  • CognitoアプリクライアントのコールバックURLにALBのURLが登録されていない
確認手順
  • ALBリスナールールの認証アクション設定を確認
  • Cognitoアプリクライアントの許可されたコールバックURLを確認
  • ブラウザのDevToolsでAWSALBCOOKIEクッキーの有無を確認
  • ALBの認証アクションのセッションタイムアウト設定を確認
CloudFront 502/503(オリジンエラー)
想定される原因
  • オリジン(ALB/EC2/S3)が落ちているまたは応答しない
  • CloudFrontのオリジンタイムアウト(デフォルト30秒)超過
  • オリジンのセキュリティグループがCloudFrontのIPを許可していない
  • オリジンのSSL証明書がCloudFrontから見て無効
  • オリジンサーバーのキャパシティ不足
確認手順
  • CloudFrontのエラーレートメトリクス(5xxErrorRate)を確認
  • オリジンに直接アクセスして応答を確認
  • CloudFrontのリアルタイムログでオリジンのsc-statusを確認
  • オリジンのセキュリティグループにCloudFrontのIPレンジが許可されているか確認
  • CloudFrontコンソール > ディストリビューション > エラーページで設定確認
CloudFront キャッシュヒット率の低下
想定される原因
  • Cache-Control: no-store / no-cache がオリジンから返されている
  • クエリ文字列やCookieをキャッシュキーに含めすぎてキャッシュが分散
  • TTLが短すぎてすぐにキャッシュが無効化される
  • Authorization ヘッダーが転送されているためキャッシュされない
  • 動的コンテンツとしてキャッシュ除外設定になっている
確認手順
  • CloudWatchのCacheHitRateメトリクスを確認
  • CloudFrontのリアルタイムログでx-cache(Hit/Miss/RefreshHit)を確認
  • オリジンのレスポンスヘッダー(Cache-Control, Vary)を確認
  • キャッシュポリシーの設定でどのヘッダー/クエリ文字列を含めているか確認
  • CloudFrontコンソールのビヘイビア設定でTTLを確認
CloudFront CORS エラー(403/Access-Control-Allow-Origin)
想定される原因
  • CloudFrontがOriginリクエストヘッダーをオリジンに転送していない
  • オリジンがCORSレスポンスヘッダーを返していない
  • CORSレスポンスがキャッシュされてOriginヘッダーに関係なく返される
  • OPTIONS メソッドが転送されていない
  • キャッシュポリシーでOriginヘッダーがキャッシュキーに含まれていない
確認手順
  • CloudFrontのビヘイビア設定でOriginヘッダーが転送されているか確認
  • オリジンのCORSレスポンスヘッダーを直接確認
  • キャッシュポリシーにOriginヘッダーが含まれているか確認
  • OPTIONSメソッドがCloudFrontビヘイビアで許可されているか確認
  • CloudFrontのCORSマネージドポリシーを使用しているか確認
CloudFront カスタムドメインの SSL 証明書エラー
想定される原因
  • ACM証明書がus-east-1以外のリージョンで作成されている(CloudFrontはus-east-1のみ対応)
  • 証明書のドメイン名がCloudfrontのカスタムドメインと一致しない
  • 証明書のステータスがPendingまたはFailed
  • 証明書がCloudFrontディストリビューションにアタッチされていない
確認手順
  • ACMコンソールでus-east-1(バージニア北部)に証明書が存在するか確認
  • 証明書のドメイン名とCloudFrontの代替ドメイン名が一致するか確認
  • 証明書のステータスがISSUEDになっているか確認
  • CloudFrontのディストリビューション設定で証明書が選択されているか確認
CloudFront Lambda@Edge のエラー
想定される原因
  • Lambda@Edge 関数の実行エラー(バグ)
  • Lambda@Edge のタイムアウト(Viewer Request/Response: 5秒, Origin: 30秒)
  • Lambda@Edge がus-east-1以外のリージョンにデプロイされている
  • Lambda@Edge 関数のメモリが不足
  • Lambda@Edge でサポートされていないAPI(環境変数等)を使用
確認手順
  • CloudWatch Logs(us-east-1)でLambda@Edgeのログを確認(エッジロケーションのログ)
  • CloudFrontのリアルタイムログでx-edge-result-typeを確認
  • Lambda@Edgeの実行時間がタイムアウト上限内か確認
  • Lambda@Edgeがus-east-1にデプロイされているか確認
  • Lambda@Edgeの制限(環境変数不可、VPC不可等)に違反していないか確認
CloudFront での S3 オリジン 403 エラー
想定される原因
  • S3バケットポリシーにCloudFrontのOAC(Origin Access Control)が許可されていない
  • OAC/OAIが設定されていないのにバケットがパブリックアクセスを拒否している
  • 古いOAI(Origin Access Identity)を使用していて非推奨になった
  • S3バケットのパブリックアクセスブロックが有効でOACなしではアクセス不可
確認手順
  • CloudFrontディストリビューションでOAC(Origin Access Control)が設定されているか確認
  • S3バケットポリシーにCloudFrontのサービスプリンシパル(cloudfront.amazonaws.com)が許可されているか確認
  • S3のパブリックアクセスブロック設定を確認
  • バケットポリシーのConditionでAWS:SourceArnがディストリビューションARNと一致するか確認
CloudFront のキャッシュ無効化(Invalidation)が遅い
想定される原因
  • 大量のパスを無効化しようとして時間がかかっている
  • /*(ワイルドカード)無効化は時間がかかる
  • CloudFrontの無効化処理はエッジロケーション全体への伝播に時間がかかる
  • 月間1000パスを超えると追加料金が発生
確認手順
  • CloudFrontコンソール > ディストリビューション > 無効化タブで状態を確認
  • aws cloudfront get-invalidation で無効化のステータスを確認
  • 無効化するパス数を確認(/* は全パスのカウント)
  • CloudFrontの伝播完了には通常5〜10分かかることを把握
CloudFront Signed URL / Signed Cookie による403エラー
想定される原因
  • Signed URLの有効期限(Expires)が切れている
  • Signed URLの生成に使ったCloudFrontキーペアが失効または削除された
  • Key Pair IDがディストリビューションの信頼済みキーグループに登録されていない
  • Signed URLのURL文字列が改変・URLエンコードのミスで署名が無効
  • Signed CookieのDomain/Pathがリクエストと一致していない
確認手順
  • Signed URLのExpiresパラメータをデコードして有効期限を確認(Unixタイムスタンプ)
  • CloudFrontコンソール > ディストリビューション > キーグループ で使用中のキーペアを確認
  • AWS IAM > CloudFront Key Pairs でキーペアの有効期限と状態を確認
  • CloudFrontのアクセスログ(x-edge-result-type)でMissがどの段階で発生するか確認
  • openssl dgst -sha1 -sign private_key.pem でSignature再生成して比較
CloudFront WAF(AWS WAF)によるリクエストブロック
想定される原因
  • AWS WAFのマネージドルールセット(CommonRuleSet等)が正当なリクエストを誤検知
  • SQLインジェクション・XSS防御ルールがアプリの正常なPOSTボディに反応
  • レートベースルールのしきい値(5分あたりの件数)を通常のユーザーが超えた
  • Bot Controlルールが通常のAPIクライアントをボットと判定
  • WAFがCloudFrontではなくALBにアタッチされており二重評価が発生
確認手順
  • AWS WAF > Web ACL > ログ でブロックされたリクエストのルールIDとTerminating Ruleを確認
  • CloudWatch Logs(aws-waf-logs-*)でBlockedRequestsとRuleを確認
  • AWS WAFサンプリングリクエストでブロックされたリクエストの詳細を確認
  • WAFのモード(Count/Block)を確認して誤検知ルールをCountモードで動作させる
  • ルールグループのオーバーライドでFalse Positiveのルールを特定
CloudFront Invalidation後もキャッシュが更新されない
想定される原因
  • エッジロケーションへのInvalidation伝播に最大数分かかる
  • ブラウザキャッシュがCloudFrontより手前でコンテンツを保持
  • S3バージョニングで古いバージョンが参照されている
  • Invalidationパスの指定ミス(例: /index.htmlのみで/が含まれない)
  • カスタムオリジンのCache-Controlヘッダーが長いTTLを設定
確認手順
  • aws cloudfront list-invalidations でInvalidationのStatusを確認
  • curl -I でx-cacheヘッダーを確認(Hit/Miss from cloudfront)
  • Invalidationのパス指定(/* で全キャッシュ削除)
  • ブラウザのキャッシュをクリアして再確認
  • CloudFrontのResponse Headers PolicyでCache-Controlを上書き
CloudFront Functions/Lambda@Edge 実行エラー
想定される原因
  • CloudFront Functionsのコードにシンタックスエラーまたは実行時エラー
  • Lambda@Edgeのタイムアウト(viewer-request/response: 5秒、origin: 30秒)超過
  • Lambda@EdgeがCloudFrontに結び付けられたIAMロールに必要な権限がない
  • レスポンスオブジェクトの形式が不正
確認手順
  • CloudFront Functionsのテスト機能でコードを事前テスト
  • Lambda@EdgeのCloudWatch Logsをエッジロケーションで確認(us-east-1のレプリカ)
  • CloudFrontのリアルタイムログでfunction execution errorを確認
  • Lambda@EdgeのIAMロールのtrust policyにedgelambda.amazonaws.comを確認
CloudFront Origins ヘルスチェック失敗でオリジンフェイルオーバー
想定される原因
  • プライマリオリジンが5xx応答を返しフェイルオーバーが発動
  • フェイルオーバーのStatusCodeがデフォルト(502、503、504)のみで他のエラーコードが未設定
  • セカンダリオリジンも同じ問題で両方がUnhealthy
  • オリジングループのフェイルオーバー条件の設定ミス
確認手順
  • CloudFrontのキャッシュ統計でorigin requestsとerror rateを確認
  • プライマリオリジンに直接リクエストして5xx原因を確認
  • オリジングループのフェイルオーバーStatusCodesを確認
  • セカンダリオリジンのヘルス状態を確認
EKS ノードグループが NotReady(kubelet 停止)
想定される原因
  • EC2 インスタンスのリソース枯渇(CPU/メモリ/ディスク)
  • aws-node(VPC CNI)プラグインのクラッシュ
  • kubelet プロセスの停止
  • EC2 インスタンス自体のハードウェア障害
  • IAM ロールの権限不足で EKS API に接続できない
確認手順
  • kubectl describe node <name> の Conditions と Events を確認
  • kubectl get pods -n kube-system で aws-node, kube-proxy の状態を確認
  • EC2 コンソールでノードのシステムステータスチェックを確認
  • CloudWatch のノードのCPU/Memory/Disk使用率を確認
  • kubectl top node でリソース使用率を確認
EKS Pod が Pending(リソース不足・Fargate設定)
想定される原因
  • クラスターのノードリソースが不足
  • Fargate プロファイルで namespace/ラベルセレクターが一致しない
  • nodeSelector や affinity の条件に一致するノードがない
  • Cluster Autoscaler が新ノードを起動できない(上限/AZキャパシティ)
  • Fargate 環境で EBS ボリューム(PVC)を要求している(Fargate は EBS 非対応)
確認手順
  • kubectl describe pod <pod> の Events でスケジューリング失敗理由を確認
  • kubectl get nodes -o wide でノードのリソース状況を確認
  • Fargate: aws eks list-fargate-profiles でプロファイルのセレクターを確認
  • kubectl describe node <node> で Allocatable vs Requests を確認
  • Cluster Autoscaler のログを確認: kubectl logs -n kube-system -l app=cluster-autoscaler
EKS aws-auth ConfigMap による RBAC 認証エラー
想定される原因
  • IAM ユーザー/ロールが aws-auth ConfigMap に追加されていない
  • aws-auth の rolearn または userarn の ARN フォーマットが誤っている
  • RBAC の ClusterRole/Role がグループに正しく紐づいていない
  • aws configure の credentials が古い/誤っている
  • kubeconfig の更新が必要(aws eks update-kubeconfig 未実行)
確認手順
  • kubectl get configmap aws-auth -n kube-system -o yaml でマッピングを確認
  • aws sts get-caller-identity で現在の IAM ID を確認
  • aws eks update-kubeconfig --name <cluster> で kubeconfig を最新化
  • eksctl get iamidentitymapping --cluster <cluster> でマッピングを確認
  • ClusterRole の bindings を確認: kubectl get clusterrolebinding
EKS VPC CNI(aws-node)の IP アドレス枯渇
想定される原因
  • サブネットの IP アドレスが枯渇(/24 = 251 IP で足りない)
  • warm IP プールが大きすぎて IP を過剰に事前割り当て
  • ノード 1 台あたりの ENI 数 x IP 数の上限(インスタンスタイプによる)
  • IP を使用中のゾンビ Pod が残っている
  • MINIMUM_IP_TARGET / WARM_IP_TARGET の設定過多
確認手順
  • kubectl get pods -n kube-system -l k8s-app=aws-node のログを確認
  • aws ec2 describe-subnets で AvailableIpAddressCount を確認
  • インスタンスタイプごとの最大 ENI 数と IP 数を確認
  • kubectl get pods --all-namespaces | grep -v Running で異常 Pod を確認
  • aws ec2 describe-network-interfaces で使用中の ENI を確認
EKS Cluster Autoscaler がスケールしない
想定される原因
  • Auto Scaling Group の最大サイズ上限に達している
  • Cluster Autoscaler の IAM ロールに権限が不足している
  • Cluster Autoscaler がポッドのリソースリクエストなし(requests 未設定)を無視する
  • スケールダウン保護(disruption budget)がスケールインを妨げている
  • Cluster Autoscaler のバージョンと EKS バージョンが一致していない
確認手順
  • kubectl logs -n kube-system -l app=cluster-autoscaler でスケール判定ログを確認
  • Auto Scaling Group の MaxSize と現在のインスタンス数を確認
  • Cluster Autoscaler の IAM ポリシーに autoscaling:DescribeAutoScalingGroups 等があるか確認
  • Pod に resources.requests が設定されているか確認
  • Cluster Autoscaler のバージョンが EKS バージョンに対応しているか確認
EKS ALB Ingress Controller(AWS Load Balancer Controller)の設定エラー
想定される原因
  • AWS Load Balancer Controller の IAM ロールに権限が不足している
  • IngressClass(kubernetes.io/ingress.class: alb)が設定されていない
  • ALB アノテーションの値が無効
  • Controller が正しいサブネットを見つけられない(タグ不足)
  • AWS Load Balancer Controller 自体がインストールされていない
確認手順
  • kubectl get pods -n kube-system | grep aws-load-balancer でコントローラーの状態を確認
  • kubectl logs -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller でエラーを確認
  • kubectl describe ingress <name> のイベントでエラーを確認
  • サブネットに kubernetes.io/role/elb: 1 タグが付いているか確認(パブリックALB)
  • IAM Service Account の IRSA 設定を確認
EKS コントロールプレーンとノード間の通信障害
想定される原因
  • プライベートエンドポイントのみ有効でVPC外からのアクセスが制限されている
  • エンドポイントアクセスの IP アドレス許可リストに現在の IP がない
  • コントロールプレーンとノード間のセキュリティグループが通信をブロック
  • EKS の API サーバーが一時的に利用不可(AWS 側のメンテナンス)
  • VPC DNS 解決が無効で API エンドポイントの名前解決ができない
確認手順
  • aws eks describe-cluster で endpointPublicAccess と publicAccessCidrs を確認
  • 現在の IP アドレスが publicAccessCidrs に含まれているか確認
  • VPC の DNS ホスト名・DNS 解決が有効か確認
  • kubectl cluster-info でアクセス確認
  • AWS サービスヘルスダッシュボードで EKS のステータスを確認
EKS Fargate Pod の IRSA(IAM Roles for Service Accounts)エラー
想定される原因
  • EKS クラスターの OIDC プロバイダーが IAM に登録されていない
  • Service Account のアノテーション(eks.amazonaws.com/role-arn)が設定されていない
  • IAM ロールの信頼ポリシーの OIDC URL またはサービスアカウント名が誤っている
  • IAM ロールの信頼ポリシーの条件(aud, sub)が正しくない
  • Pod の service account が IRSA 設定済みの SA を使用していない
確認手順
  • aws iam list-open-id-connect-providers でクラスターの OIDC プロバイダーが登録されているか確認
  • kubectl get serviceaccount <sa> -o yaml でアノテーションを確認
  • IAM ロールの信頼ポリシーの Condition(StringEquals)を確認
  • Pod のサービスアカウントが IRSA 設定済みの SA を指定しているか確認
  • kubectl exec でPod内から AWS STS コールをテスト
EKS Fargate PodスケジューリングFailed
想定される原因
  • FargateプロファイルのnamespaceセレクタがPodのnamespaceと不一致
  • FargateプロファイルのlabelセレクタがPodのラベルと一致しない
  • Fargateプロファイルが存在しないか削除されている
  • Podのリソース要求がFargateの最大リソース(4vCPU/30GB)を超過
確認手順
  • aws eks list-fargate-profiles でプロファイル一覧を確認
  • kubectl describe pod でスケジューリングエラーの詳細を確認
  • FargateプロファイルのnamespaceとlabelセレクタをPodのメタデータと照合
  • PodのリソースリクエストがFargateの上限内か確認(最大4vCPU/30GiB)
EKS CoreDNS障害によるクラスタ内名前解決失敗
想定される原因
  • CoreDNS Podがクラッシュしている(CrashLoopBackOff)
  • CoreDNS ConfigMapの設定ミス(Corefile)
  • ノードのresolv.confがCoreDNSのClusterIPを参照していない
  • CoreDNSのリソース不足(OOMKill)
  • kube-proxy障害によるCoreDNS ClusterIPへのルーティング失敗
確認手順
  • kubectl get pods -n kube-system -l k8s-app=kube-dns でCoreDNSの状態確認
  • kubectl logs -n kube-system <coredns-pod> でエラーログ確認
  • kubectl get cm -n kube-system coredns -o yaml でCorefile確認
  • ノードから nslookup kubernetes.default.svc.cluster.local でDNS動作確認
  • CoreDNSのメモリリミットとActual使用量を比較
EKS Karpenter ノードプロビジョニング失敗
想定される原因
  • NodePoolのinstanceSizesやarchの制約が厳しすぎて適合するインスタンスがない
  • EC2NodeClassのAMIセレクター設定が誤っていてAMIが見つからない
  • KarpenterのIAMロールにEC2/SSMの必要な権限がない
  • リージョンの特定インスタンスタイプの在庫不足
確認手順
  • kubectl logs -n karpenter deployment/karpenter でエラー詳細を確認
  • kubectl get nodeclaim でNodeClaimのステータスを確認
  • NodePoolのspec.template.spec.requirementsを確認
  • EC2NodeClassのamiSelectorTermsを確認
EKS Pod Disruption Budget(PDB)によるローリングアップデート停止
想定される原因
  • PDBのminAvailableが現在の全レプリカ数と同じで1つも削除できない
  • Deployment rolloutがPDBで制限されてタイムアウト
  • ノードメンテナンス/アップグレード時にPDBが強すぎてnodeがDrainできない
  • PDBとDeployment rollout strategyのmaxUnavailableが矛盾
確認手順
  • kubectl get pdb -A でPDBの状態を確認(ALLOWED DISRUPTIONS: 0の場合は詰まり)
  • kubectl describe pdb でminAvailable/maxUnavailableを確認
  • kubectl get deployment でREADY数とDESIRED数を比較
  • kubectl drain --dry-run でEviction可否を事前確認
API Gateway 502 Bad Gateway(Lambda 統合エラー)
想定される原因
  • Lambda 関数が未処理の例外でクラッシュした
  • Lambda のレスポンスフォーマットが API Gateway の期待する形式と異なる(proxy 統合)
  • Lambda のレスポンスが 6MB(同期)または 10MB を超えた
  • Lambda が設定されたタイムアウト内に応答しなかった
  • API Gateway に Lambda の実行権限が付与されていない
確認手順
  • CloudWatch Logs で Lambda のエラーログを確認
  • API Gateway のアクセスログでintegration_error_messageを確認
  • Lambda のレスポンスオブジェクトのフォーマットを確認(statusCode, headers, body が必要)
  • Lambda 関数の実行タイムアウト設定を確認
  • aws lambda get-policy で API Gateway からの invoke 権限を確認
API Gateway 429 Too Many Requests(スロットリング)
想定される原因
  • API ステージのスロットリング設定(RPS)を超えた
  • Usage Plan のクォータ(日次/月次リクエスト数)に達した
  • アカウントレベルのデフォルト制限(10,000 RPS)に達した
  • 特定のメソッドのスロットリング設定が低すぎる
  • クライアントのリトライが連鎖的に負荷を増大させている
確認手順
  • CloudWatch の 4XXError と Throttle カウントを確認
  • API Gateway コンソール > ステージ > スロットリングの設定を確認
  • Usage Plan のクォータ残量を確認
  • Service Quotas でアカウントのAPI Gatewayデフォルトスロットリングを確認
  • どのエンドポイントが最も多くのスロットリングを受けているかを特定
API Gateway CORS エラー(OPTIONS プリフライト失敗)
想定される原因
  • OPTIONS メソッドが設定されていない
  • Lambda Proxy 統合でCORSヘッダーをLambdaから返していない
  • API Gateway のCORS設定がされているがLambdaのレスポンスヘッダーが上書きしている
  • HTTP API(v2)と REST API(v1)でCORS設定方法が異なる
確認手順
  • ブラウザのデベロッパーツールでOPTIONSリクエストのレスポンスを確認
  • API Gatewayコンソール > リソース > OPTIONS メソッドの設定を確認
  • Lambdaのレスポンスヘッダーにaccess-control-allow-originが含まれているか確認
  • HTTP API の場合: API設定 > CORS設定を確認
API Gateway カスタムドメインの設定エラー
想定される原因
  • ACM証明書がus-east-1(エッジ最適化)またはAPIと同じリージョン(リージョン)に必要
  • APIマッピングでステージ名が間違っている
  • Route 53のエイリアスレコードが古いCloudFrontドメインを指している
  • 複数のAPIが同じベースパスを使用して競合している
確認手順
  • API Gatewayコンソール > カスタムドメイン名で設定を確認
  • ACM証明書のリージョンがAPIタイプに合っているか確認
  • APIマッピングでステージとAPIの組み合わせが正しいか確認
  • nslookupでカスタムドメインがAPI GatewayのCloudFrontドメインを解決するか確認
API Gateway 統合タイムアウト(29秒制限)
想定される原因
  • Lambda やバックエンドの処理が29秒を超えた
  • API Gateway の統合タイムアウト上限は29秒(引き上げ不可)
  • データベースクエリや外部API呼び出しで遅延が発生
  • 長時間処理を同期APIとして実装している設計の問題
確認手順
  • X-Ray または CloudWatch Logs で処理時間を確認
  • 統合タイムアウト設定値を確認(デフォルト29秒、最大29秒)
  • どの処理に時間がかかっているかプロファイリングで特定
API Gateway Authorizer の認証失敗(403 Unauthorized)
想定される原因
  • JWTトークンの期限切れ(exp クレーム超過)
  • Lambda Authorizer が Deny ポリシーを返している
  • Cognito User Pool の設定が API Gateway の Authorizer と一致しない
  • Authorization ヘッダーのフォーマット(Bearer <token>)が誤っている
  • Authorizer のキャッシュ期間中に失効したトークンがキャッシュされている
確認手順
  • JWT.io でトークンのペイロードを確認(exp クレームの有効期限)
  • CloudWatch Logs で Authorizer Lambda のレスポンスを確認
  • API Gateway のテスト機能でAuthorizationヘッダー付きリクエストを実行
  • Cognito のユーザープール設定とAPI GatewayのAuthorizer設定を照合
  • Authorizer のキャッシュ TTL 設定を確認
API Gateway のデプロイ後に変更が反映されない
想定される原因
  • REST API(v1)は設定変更後に明示的なデプロイが必要
  • 新しいデプロイをステージにプロモートしていない
  • HTTP API(v2)はAuto-deployが無効になっている
  • Canaryデプロイが設定されていてベーストラフィックに新バージョンが当たっていない
確認手順
  • API Gatewayコンソールで未デプロイの変更(黄色マーク)があるか確認
  • デプロイ履歴で最新のデプロイがステージに反映されているか確認
  • HTTP API の Auto-deploy 設定を確認
  • IaC(Terraform/CDK)でデプロイが自動化されているか確認
API Gateway のアクセスログが出力されない
想定される原因
  • API Gatewayのアカウント設定でCloudWatch Logsへの書き込みIAMロールが未設定
  • ステージのアクセスログ設定でCloudWatch LogsグループのARNが未設定
  • 指定したCloudWatch Logsグループが存在しない
  • ログフォーマットが設定されていない
確認手順
  • API Gatewayコンソール > 設定 > CloudWatch ログのIAMロールARNを確認
  • ステージ設定のアクセスログ設定でARNが入力されているか確認
  • 指定したCloudWatch LogsグループのARNが正確か確認
  • IAMロールにlogs:CreateLogGroupとlogs:PutLogEventsがあるか確認
API Gateway WebSocket API 接続管理エラー
想定される原因
  • PostToConnection でGoneExceptionが発生するのは接続IDが既に切断済みの場合(古い接続IDをキャッシュ)
  • WebSocketのアイドルタイムアウト(デフォルト10分、最大2時間)を超えて接続が切断
  • ルート選択式(Route Selection Expression)のキーがメッセージに存在せずデフォルトルートもない
  • ルートのLambdaが非同期処理をして接続が確立する前にメッセージが来る
  • Lambda統合の処理時間が29秒制限を超えてWebSocket接続がタイムアウト
確認手順
  • CloudWatch > API Gateway > WebSocket メトリクスでConnectCount/DisconnectCountを確認
  • API Gateway > ステージ > ログ でWebSocket接続のlifecycleイベントを確認
  • DynamoDB(接続IDストア)でGoneExceptionが発生した接続IDの状態を確認
  • API Gateway > WebSocket API > ルート でルート選択式(.body.action等)を確認
  • CloudWatch Logs InsightsでGoneExceptionのパターンを分析
API Gateway プライベート統合(VPC Link)エラー
想定される原因
  • VPC LinkのステータスがPENDING/FAILEDでまだ利用可能でない
  • NLB(Network Load Balancer)のターゲットグループに正常なターゲットがない
  • VPC LinkとNLBが異なるVPCまたはリージョンにある
  • NLBのリスナーポートとAPI Gatewayの統合ポートが一致していない
  • セキュリティグループ(NLB→バックエンド)でAPIのポートがブロックされている
確認手順
  • aws apigateway get-vpc-link --vpc-link-id <id> でVPC Linkのステータスを確認
  • NLBのターゲットグループのヘルス状態(HealthyHostCount)を確認
  • API GatewayのPrivate統合設定でVPC Link IDとNLB ARNを確認
  • NLBとバックエンド間のセキュリティグループルールを確認
  • CloudTrailでVPC Link作成・更新のAPIコールを確認
API Gateway HTTP API JWT Authorizer認証失敗
想定される原因
  • JWT AuthorizerのissuerURLがトークン発行者のURLと不一致
  • audienceの設定がJWTのaudクレームと不一致
  • JWTの有効期限切れ(exp)
  • JWKSエンドポイントが到達不能でキー検証ができない
確認手順
  • JWT AuthorizerのissuerURLをCognito/Auth0のOIDC Discovery URLと比較
  • jwt.ioでトークンをデコードしてaud/issクレームを確認
  • API GatewayのアクセスログでJWT検証エラーの詳細を確認
  • JWKSエンドポイント(issuer/.well-known/jwks.json)が到達可能か確認
API Gateway カスタムドメイン ACM証明書エラー
想定される原因
  • REST API(Edge-Optimized)のカスタムドメインはus-east-1のACM証明書が必要
  • Regional APIのカスタムドメインは同一リージョンのACM証明書が必要
  • ACM証明書が発行済み(Issued)でないか検証中(Pending validation)
  • カスタムドメインのRoute 53/DNS設定が誤っている
確認手順
  • API GatewayのエンドポイントタイプがEdge/Regionalのどちらか確認
  • Edge-Optimizedの場合: us-east-1のACM証明書を確認
  • Regionalの場合: 同一リージョンのACM証明書を確認
  • ACM証明書のステータスがIssuedか確認(DNS検証が完了しているか)
S3 バケットポリシーによるアクセス拒否(403)
想定される原因
  • バケットポリシーに明示的なDenyが設定されている
  • S3のパブリックアクセスブロックが有効でパブリックアクセスが拒否
  • IAMポリシーにS3アクションの許可が不足している
  • KMS暗号化バケットでKMSキーへのアクセス権限がない
  • クロスアカウントアクセスでバケットポリシーに許可がない
確認手順
  • aws s3api get-bucket-policy でバケットポリシーを確認
  • aws s3api get-public-access-block でパブリックアクセスブロック設定を確認
  • IAM Policy Simulator でアクセスが許可されているか確認
  • CloudTrail でS3のAccessDeniedイベントを確認して拒否理由を特定
  • KMS暗号化の場合: KMSキーポリシーを確認
S3 署名付き URL(Presigned URL)の有効期限切れ
想定される原因
  • Presigned URL の有効期限(ExpiresIn)が短すぎる
  • URLを生成したIAMロール(特にAssumeRole)の一時的な認証情報が期限切れ
  • クライアントの時刻がサーバーと大きくずれている(±15分以上)
  • URLの発行から使用までの時間が有効期限を超えた
確認手順
  • Presigned URL のクエリパラメータ(X-Amz-Expires)で有効期限を確認
  • URLを生成した際のIAMロール(STS一時認証情報)の有効期限を確認
  • クライアントのシステム時刻を確認(date コマンド)
  • URLの生成から使用のワークフローで所要時間を測定
S3 バケットのクロスリージョンレプリケーション失敗
想定される原因
  • 送信元または送信先バケットでバージョニングが有効になっていない
  • レプリケーション IAM ロールに必要な権限が不足している
  • 送信先バケットのKMSキーへのアクセス権限がレプリケーションロールにない
  • 送信先バケットが存在しない、または別のAWSアカウントへのアクセスが拒否
  • バケットポリシーでレプリケーションロールからのアクセスが拒否
確認手順
  • 送信元と送信先バケットのバージョニング設定を確認
  • レプリケーションIAMロールのポリシーにs3:ReplicateObjectとs3:GetObjectVersionが含まれているか確認
  • S3コンソール > バケット > マネジメント > レプリケーションルールでエラーを確認
  • CloudWatch S3レプリケーションメトリクスで失敗数を確認
  • KMS暗号化の場合: レプリケーションロールにkms:Decrypt/Encryptが付与されているか確認
S3 大容量オブジェクトのアップロード失敗(マルチパートアップロード)
想定される原因
  • ネットワークの不安定性でパーツのアップロードが中断された
  • 5GBを超えるオブジェクトをシングルPutObjectで送信しようとした
  • マルチパートアップロードを完了(CompleteMultipartUpload)せずに放置
  • IAMロールにs3:PutObjectとs3:CreateMultipartUploadの権限がない
  • バケットのライフサイクルで未完了のマルチパートが削除された
確認手順
  • aws s3api list-multipart-uploads --bucket <bucket> で未完了のアップロードを確認
  • アップロードライブラリのエラーログでどのパーツで失敗したか確認
  • IAMポリシーにマルチパートアップロードに必要な全アクションがあるか確認
  • ネットワーク帯域と安定性を確認
S3 イベント通知が SQS/Lambda に届かない
想定される原因
  • LambdaにS3からの呼び出し権限(リソースポリシー)がない
  • SQSキューポリシーでS3からのsqs:SendMessageが許可されていない
  • S3のイベント通知設定が正しくない(ファイルプレフィックス/サフィックスミス)
  • 同じバケットに同じプレフィックスの通知が2つ設定されて競合
  • SNSトピックポリシーでS3からの publish が許可されていない
確認手順
  • S3コンソール > プロパティ > イベント通知の設定を確認
  • Lambda関数のリソースポリシーにS3からの invoke 権限があるか確認
  • SQSキューポリシーにS3サービスからのsqs:SendMessageが許可されているか確認
  • S3のイベントがS3コンソールのテスト機能で正常に配信されるか確認
  • CloudTrail でS3のevent notification関連のエラーを確認
S3 静的ウェブサイトホスティングの 403/404 エラー
想定される原因
  • S3のパブリックアクセスブロックが有効でウェブサイトが403になる
  • バケットポリシーにパブリック読み取り権限がない
  • インデックスドキュメント(index.html)がバケットに存在しない
  • ウェブサイトホスティングが有効化されていない
  • CloudFront + OACを使う場合にS3ウェブサイトエンドポイントではなくREST APIエンドポイントを使う必要がある
確認手順
  • S3コンソール > プロパティ > 静的ウェブサイトホスティングが有効か確認
  • パブリックアクセスブロック設定を確認
  • バケットポリシーにs3:GetObjectのパブリック許可があるか確認
  • index.htmlがバケットのルートに存在するか確認
  • CloudFrontを使う場合はRESTエンドポイントを使用しているか確認
S3 ライフサイクルポリシーが動作しない
想定される原因
  • ライフサイクルルールのフィルター(プレフィックス/タグ)が対象オブジェクトと一致しない
  • バージョニングが有効なバケットで非カレントバージョンのルールが別途必要
  • ライフサイクルアクションは毎日一度の実行(最大24時間の遅延)
  • マルチパートアップロードの未完了部分に対するルールが未設定
  • ルールのステータスが無効(Disabled)になっている
確認手順
  • S3コンソール > マネジメント > ライフサイクルルールでルールの有効/無効を確認
  • フィルターのプレフィックスまたはタグが対象オブジェクトと一致するか確認
  • バージョニングが有効な場合: NonCurrentVersionExpiration ルールの設定を確認
  • S3 Inventory でオブジェクトの作成日とストレージクラスを確認
  • 対象オブジェクトのタグがルールのタグフィルターと完全一致するか確認
S3 Object Lock / Glacier によるオブジェクト削除・変更ブロック
想定される原因
  • Object Lockのリテンション期間(Retain Until Date)が満了前のオブジェクトを削除しようとした
  • Legal Holdが設定されているオブジェクトをリテンション期間に関わらず削除しようとした
  • Governance modeのバイパスに必要な s3:BypassGovernanceRetention 権限がない
  • Glacierアーカイブからリストアしていないオブジェクトを直接読もうとした
  • バケットレベルのデフォルトリテンション設定によりアップロードされたオブジェクトが自動ロック
確認手順
  • aws s3api get-object-retention --bucket <b> --key <k> でリテンション設定を確認
  • aws s3api get-object-legal-hold --bucket <b> --key <k> でLegal Hold状態を確認
  • aws s3api get-bucket-object-lock-configuration でバケットのデフォルト設定を確認
  • aws s3api head-object --bucket <b> --key <k> でGlacierのRestore状態を確認
  • CloudTrailでs3:DeleteObject試行とアクセス拒否の詳細を確認
S3 Transfer Acceleration / 高速転送の速度が向上しない
想定される原因
  • バケットでTransfer Accelerationが有効化されていない
  • クライアントのIPがすでにS3に地理的に近くAccelerationの恩恵がない(AWSが推奨しない場合あり)
  • Accelerateエンドポイント(.s3-accelerate.amazonaws.com)でなく通常エンドポイントを使用している
  • クライアント側のネットワーク帯域が既に上限でS3側は問題ない
  • マルチパートアップロードのチャンクサイズ(デフォルト8MB)が小さすぎてオーバーヘッドが大きい
確認手順
  • aws s3api get-bucket-accelerate-configuration でAcceleration状態を確認
  • aws s3 presign を使ってaccelerateエンドポイントのURLを生成して速度テスト
  • AWSの比較ツール(https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com)で速度比較
  • クライアント側のネットワーク帯域をiperf等で計測
  • aws configure set default.s3.multipart_chunksize でチャンクサイズを確認
S3 VPCエンドポイント経由のアクセス拒否
想定される原因
  • VPCエンドポイントポリシーがバケットへのアクセスを制限している
  • バケットポリシーがaws:sourceVpceを必須条件としているがエンドポイント経由でない
  • ゲートウェイエンドポイントのルートテーブルへの追加が漏れている
  • インターフェースエンドポイントのDNS設定(プライベートDNS)が未有効化
確認手順
  • VPCエンドポイントポリシーでS3バケットとアクションの許可を確認
  • バケットポリシーのConditionでaws:sourceVpceの設定を確認
  • VPCのルートテーブルにS3ゲートウェイエンドポイントが追加されているか
  • インターフェースエンドポイントの場合、プライベートDNS名有効化を確認
S3 バケットレプリケーション失敗
想定される原因
  • レプリケーションのIAMロールに宛先バケットへの書き込み権限がない
  • レプリケーションルールのプレフィックス/タグフィルターがオブジェクトにマッチしない
  • 宛先バケットのバージョニングが無効(レプリケーションはバージョニングが必須)
  • 宛先バケットのバケットポリシーがレプリケーションIAMロールを拒否
確認手順
  • S3コンソールのレプリケーションルールで失敗したオブジェクトを確認
  • オブジェクトのメタデータでReplicationStatusを確認(COMPLETED/FAILED/PENDING)
  • レプリケーションIAMロールの権限(s3:ReplicateObject等)を確認
  • 宛先バケットのバージョニング設定を確認
S3 Event Notification 未配信/遅延
想定される原因
  • SQS/SNSのリソースポリシーにS3からの送信許可がない
  • Lambda関数のリソースポリシーにS3からのinvoke許可がない
  • イベント通知の設定が意図したバケットのプレフィックス/サフィックスと一致しない
  • SQSキューがフルでメッセージが破棄されている
確認手順
  • S3バケットのEvent Notifications設定を確認
  • SQSキューのポリシーにs3.amazonaws.comのSendMessage許可を確認
  • Lambda関数のリソースポリシーでS3からのinvokeを確認
  • SQSの送信失敗メッセージ数メトリクスを確認
VPC ピアリング経由の通信不可
想定される原因
  • 両方またはどちらかのVPCのルートテーブルにピアリングルートが追加されていない
  • セキュリティグループでピア VPC の CIDR からの通信が許可されていない
  • VPC ピアリング接続が Pending Acceptance 状態(承認待ち)
  • CIDR レンジが重複していてルーティングが正しく解決できない
  • DNS 解決の設定(enableDnsResolution)が無効
確認手順
  • VPC コンソール > ピアリング接続でステータスが active か確認
  • 両方の VPC のルートテーブルにピアリングルート(destination: 相手VPC CIDR, target: pcx-xxx)があるか確認
  • セキュリティグループにピア VPC の CIDR からのインバウンドが許可されているか確認
  • ping または traceroute で疎通確認
  • VPC フローログで通信が REJECT されていないか確認
NAT Gateway を経由したインターネットアクセス失敗
想定される原因
  • プライベートサブネットのルートテーブルに 0.0.0.0/0 → NAT Gateway のルートがない
  • NAT Gateway がパブリックサブネットではなくプライベートサブネットに配置されている
  • パブリックサブネットのルートテーブルに Internet Gateway ルートがない
  • NAT Gateway の Elastic IP が解放されている
  • NAT Gateway が停止または利用不可状態
確認手順
  • プライベートサブネットのルートテーブルに 0.0.0.0/0 → nat-xxx のルートがあるか確認
  • NAT Gateway がパブリックサブネットに配置されているか確認
  • パブリックサブネットのルートテーブルに 0.0.0.0/0 → Internet Gateway のルートがあるか確認
  • NAT Gateway のステータスが Available であることを確認
  • EC2 インスタンスのサブネットが NAT Gateway ルートを持つルートテーブルに関連付けられているか確認
VPC エンドポイント経由のサービスアクセス失敗
想定される原因
  • ゲートウェイエンドポイント(S3/DynamoDB)のルートがルートテーブルに追加されていない
  • インターフェースエンドポイントのセキュリティグループで HTTPS(443)が許可されていない
  • エンドポイントポリシーで特定のリソースへのアクセスが制限されている
  • エンドポイントが作成されていないサービスにプライベートアクセスしようとしている
  • DNS プライベートホスト名が有効になっていない(インターフェースエンドポイント)
確認手順
  • VPC コンソール > エンドポイントでエンドポイントのステータスと設定を確認
  • ゲートウェイエンドポイント: ルートテーブルにプレフィックスリストへのルートがあるか確認
  • インターフェースエンドポイント: セキュリティグループで HTTPS インバウンドが許可されているか確認
  • エンドポイントポリシーの内容を確認
  • VPC の DNS 設定(enableDnsHostnames, enableDnsSupport)が有効か確認
セキュリティグループのステートフル動作の誤解による通信不可
想定される原因
  • ネットワーク ACL(ステートレス)でエフェメラルポートのアウトバウンドルールが不足(返りトラフィック)
  • セキュリティグループはステートフルなので返りトラフィックは自動許可だが、NACLは両方向設定が必要
  • アウトバウンドセキュリティグループルールで必要なポートが許可されていない
  • ネットワーク ACL のルールで特定ポートのアウトバウンドが未設定
確認手順
  • セキュリティグループのインバウンドとアウトバウンドルールを両方確認
  • ネットワーク ACL のインバウンドとアウトバウンド(エフェメラルポート 1024-65535)を確認
  • VPC フローログで ACCEPT / REJECT の状況を確認
  • NACL vs セキュリティグループの処理順序を理解しているか確認
  • telnet または nc で具体的なポートの疎通確認
VPC フローログで大量の REJECT が検出される
想定される原因
  • セキュリティグループで必要なポートが許可されていない
  • ネットワーク ACL で特定の送信元 IP/ポートがブロックされている
  • AWS Shield Advanced による DDoS 対策での自動ブロック
  • 不正アクセス試行(ポートスキャン等)への正常な拒否
  • アプリの設定ミスで誤ったポートに接続しようとしている
確認手順
  • CloudWatch Logs Insights でフローログを分析: 送信元/宛先IP/ポートを集計
  • REJECT が多いポートがアプリで使用するポートと一致するか確認
  • 対象ポートのセキュリティグループとNACLのルールを確認
  • 送信元IPが正規のクライアントか(スキャン攻撃でないか)確認
  • CloudWatch Metric Filter でREJECT数をメトリクス化してアラーム設定
Transit Gateway 経由のルーティング障害
想定される原因
  • Transit Gateway ルートテーブルにルートが伝播または追加されていない
  • VPC のルートテーブルに TGW へのルートがない
  • クロスアカウントの Attachment が承認待ち(Pending Acceptance)
  • TGW アタッチメントのサブネットが正しくない
  • TGW のルートテーブルの関連付けや伝播設定が不完全
確認手順
  • TGW コンソールでアタッチメントのステータスが available か確認
  • TGW ルートテーブルの関連付けと伝播設定を確認
  • 各 VPC のルートテーブルに 0.0.0.0/0 または対象CIDR → TGW のルートがあるか確認
  • クロスアカウント: Resource Access Manager(RAM)でリソース共有が承認されているか確認
  • VPC フローログで TGW 経由のトラフィックがどこで止まっているか確認
DNS 解決の失敗(Route 53 プライベートホストゾーン)
想定される原因
  • Route 53 プライベートホストゾーンが VPC に関連付けられていない
  • VPC の DNS ホスト名(enableDnsHostnames)または DNS 解決(enableDnsSupport)が無効
  • VPC ピアリング先の プライベートホストゾーンが参照元 VPC に関連付けられていない
  • DHCP オプションセットで DNS サーバーがカスタム設定になっている
  • セキュリティグループで UDP/TCP 53 が Route 53 Resolver に対してブロックされている
確認手順
  • Route 53 コンソールでホストゾーンの VPC 関連付けを確認
  • VPC の DNS 設定(enableDnsHostnames, enableDnsSupport)を確認
  • nslookup <hostname> でDNS解決を確認
  • dig コマンドで DNS レコードを確認
  • DHCP オプションセットの DNS サーバー設定を確認
VPC ネットワークACL(NACL)による予期しないトラフィックブロック
想定される原因
  • NACLはステートレスのためインバウンドを許可してもアウトバウンド(レスポンス)の戻りトラフィックが別途許可が必要
  • エフェメラルポート(1024-65535)のアウトバウンドが許可されておらずレスポンスが返らない
  • インバウンドルールのRule NumberでDeny Allルール(*)が正当なAllowより先に評価されている
  • NACLのデフォルト拒否ルール(ルール番号* DENY ALL)が残りトラフィックをブロック
  • セキュリティグループとNACLの両方でトラフィックを制御しており片方だけ変更して混乱
確認手順
  • VPC フローログ(CloudWatch Logs)でREJECTエントリのsrcport/dstportを確認
  • AWS コンソール > VPC > ネットワークACL でインバウンド/アウトバウンドルールとRule Numberを確認
  • Network Reachability Analyzer でソース→宛先の到達可否を分析
  • エフェメラルポート(1024-65535)のアウトバウンドAllowルールが存在するか確認
  • セキュリティグループとNACLの両方のルールを並べて比較確認
VPC IPv6 デュアルスタック設定エラー
想定される原因
  • プライベートサブネットのIPv6アウトバウンドにEgress-Only Internet Gatewayへのルートが未設定
  • セキュリティグループのインバウンドルールでIPv4は許可しているがIPv6(::/0)のルールがない
  • VPCにIPv6 CIDRブロックが割り当てられていないかサブネットに委任されていない
  • ALBがDual-Stackモードでないためクライアントのみ IPv6 対応になっている
  • EC2インスタンスのOSでIPv6が有効化されていないか静的IPv6アドレスが未設定
確認手順
  • aws ec2 describe-subnets でSubnetのIpv6CidrBlockAssociationSetを確認
  • ルートテーブルに ::/0 → Egress-Only Internet Gateway のルートがあるか確認
  • セキュリティグループのインバウンドルールにIPv6(::/0 または特定アドレス)のルールを確認
  • EC2インスタンスで ip -6 addr show / ip -6 route show でIPv6設定を確認
  • ALBのIP address typeがdualstackになっているか確認
AWS Transit Gateway ルーティング障害
想定される原因
  • TGWルートテーブルへのVPCアタッチメントの関連付け漏れ
  • ルート伝播(Propagation)が無効でルートが自動追加されていない
  • TGWルートテーブルにブラックホールルートが存在する
  • VPCのサブネットのルートテーブルにTGWへのルートがない
  • TGWアタッチメントのSubnetが単一AZで他AZからの通信が届かない
確認手順
  • aws ec2 describe-transit-gateway-route-tables でルート確認
  • aws ec2 get-transit-gateway-route-table-propagations でPropagation状態確認
  • aws ec2 describe-transit-gateway-attachments でアタッチメント状態確認
  • VPCサブネットのルートテーブルにTGWへの0.0.0.0/0または特定CIDRルートを確認
  • VPC Flow LogsでTGW経由トラフィックのREJECT/DROPを確認
AWS PrivateLink(VPCエンドポイントサービス)接続障害
想定される原因
  • エンドポイントサービス側が接続リクエストを承認していない
  • インターフェースエンドポイントのプライベートDNS有効化が未設定
  • エンドポイントサービスのNLBがUnhealthyでトラフィックが届かない
  • コンシューマーVPCのセキュリティグループがエンドポイントへのアクセスを制限
確認手順
  • エンドポイントサービス側で「Endpoint connections」の承認待ちリクエストを確認
  • インターフェースエンドポイントの「Enable private DNS name」設定を確認
  • エンドポイントサービスのNLBのターゲットヘルスを確認
  • エンドポイントにアタッチされたセキュリティグループの許可ルールを確認
VPC Flow Logs欠損・取得できない障害
想定される原因
  • Flow LogsのIAMロールにvpc-flow-logs.amazonaws.comのサービスプリンシパルが設定されていない
  • S3バケットポリシーがFlow Logsの書き込みを許可していない
  • CloudWatch Logsのロールに適切な権限がない
  • ネットワークインターフェース/サブネット/VPCにFlow Logsが設定されていない
確認手順
  • aws ec2 describe-flow-logs でFlow Logsのステータスを確認
  • Flow Logs IAMロールの信頼ポリシーにvpc-flow-logs.amazonaws.comを確認
  • S3バケットポリシーにFlow Logsのputオブジェクト許可を確認
  • CloudWatch Logsのロールにlogs:CreateLogGroupなどの権限を確認
CrashLoopBackOff(Podが繰り返しクラッシュ)
想定される原因
  • アプリケーションの起動エラー(設定ミス、環境変数不足)
  • 依存サービス(DB、外部API)が未起動または接続不可
  • Liveness Probe の閾値が厳しすぎてコンテナが強制終了される
  • メモリ不足による OOMKilled
  • コンテナイメージのエントリポイント設定ミス
確認手順
  • kubectl logs <pod> --previous でクラッシュ直前のログを確認
  • kubectl describe pod <pod> で Events セクションのエラーを確認
  • kubectl get events --sort-by='.lastTimestamp' で直近イベントを確認
  • Liveness/Readiness Probe の設定値(initialDelaySeconds, failureThreshold)を確認
  • Pod の resource limits(memory)と実際の使用量を確認
Node NotReady(ノードが不健全)
想定される原因
  • ノードのディスク容量枯渇(DiskPressure)
  • ノードのメモリ枯渇(MemoryPressure)
  • kubelet プロセスの停止またはクラッシュ
  • ノード VM のネットワーク障害またはクラッシュ
  • PID 数の上限到達(PIDPressure)
確認手順
  • kubectl describe node <node> で Conditions と Events を確認
  • kubectl top node でリソース使用率を確認
  • Azure Portal でノード VM のメトリクス(CPU/Memory/Disk)を確認
  • AKS > Node pools で各ノードのステータスを確認
  • kubectl get pods --all-namespaces --field-selector spec.nodeName=<node> で該当ノードのPodを確認
ImagePullBackOff(コンテナイメージ取得失敗)
想定される原因
  • イメージ名またはタグのスペルミス
  • コンテナレジストリの認証情報(imagePullSecrets)が未設定または誤り
  • ACR(Azure Container Registry)へのアクセス権限不足
  • プライベートレジストリのイメージを public として参照しようとしている
  • 指定したタグのイメージが削除または存在しない
確認手順
  • kubectl describe pod <pod> の Events でエラーメッセージを確認
  • イメージ名・タグが正しいか ACR または Docker Hub で確認
  • kubectl get secret <secret> で imagePullSecrets が存在するか確認
  • AKS の Managed Identity に AcrPull ロールが付与されているか確認
  • az acr repository show-tags で対象タグが存在するか確認
OOMKilled(メモリ不足によるコンテナ強制終了)
想定される原因
  • コンテナの memory limits が実際の使用量より低く設定されている
  • アプリケーションのメモリリーク
  • 大量データの一括処理によるメモリスパイク
  • memory requests と limits の乖離が大きくノードが過負荷
  • JVM や .NET ランタイムのヒープサイズが limits を超えている
確認手順
  • kubectl describe pod <pod> で OOMKilled の Reason と Last State を確認
  • kubectl top pod <pod> --containers でコンテナごとのメモリ使用量を確認
  • Container Insights(Azure Monitor)でメモリ使用量の推移を確認
  • アプリのヒープダンプを取得してメモリリークを調査
  • Pod の resource limits の memory 設定値を確認
Service Unreachable(サービスへの疎通不可)
想定される原因
  • Service の selector と Pod の labels が一致していない
  • Pod が全て NotReady または CrashLoopBackOff 状態
  • Service の targetPort と Pod の containerPort が一致していない
  • Pod が存在しない(スケールダウン、デプロイ失敗)
  • NetworkPolicy によって通信がブロックされている
確認手順
  • kubectl get endpoints <service> で Endpoints が空でないか確認
  • kubectl describe service <service> で Selector を確認
  • kubectl get pods -l <selector> で一致する Pod が Running か確認
  • kubectl get networkpolicy -n <namespace> で通信制限を確認
  • kubectl port-forward pod/<pod> <port> で Pod 直接疎通を確認
Pending Pod(スケジューリング失敗)
想定される原因
  • クラスターに Pod を配置できるノードのリソース(CPU/メモリ)が不足
  • nodeSelector または affinity の条件に一致するノードが存在しない
  • ノードに Taint が設定されているが Pod に対応する Toleration がない
  • PVC が Bound されていないため Pod がスケジュールできない
  • ノードプールが最大スケールアウト数に達している
確認手順
  • kubectl describe pod <pod> の Events で具体的なスケジューリング失敗理由を確認
  • kubectl get nodes で各ノードの Status と Resource を確認
  • kubectl describe node <node> で Allocatable と Allocated Resources を比較
  • kubectl get nodes --show-labels でノードのラベルと Pod の nodeSelector を照合
  • kubectl describe node <node> で Taints を確認し Pod の Tolerations と照合
Ingress 502/503(Ingress Controller 経由のアクセス失敗)
想定される原因
  • バックエンド Service の Endpoints が空(Pod が Ready でない)
  • Service の targetPort が Pod の containerPort と一致していない
  • Ingress の host / path の設定ミス
  • Pod の Readiness Probe が失敗して Endpoints から除外されている
  • バックエンド Pod がリクエストを処理できない(アプリエラー・過負荷)
確認手順
  • kubectl get endpoints <backend-service> で Endpoints が存在するか確認
  • kubectl describe ingress <ingress> で Rules と Backend の設定を確認
  • kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx で Ingress Controller のログを確認
  • curl またはブラウザで Service に直接(port-forward 経由)アクセスして疎通確認
  • kubectl describe pod <backend-pod> で Readiness Probe の失敗状況を確認
PersistentVolumeClaim Pending(永続ボリューム作成失敗)
想定される原因
  • 指定した StorageClass が存在しない、またはスペルミス
  • 指定したアベイラビリティゾーン (AZ) にノードが存在しない
  • Azure Disk のプロビジョニングクォータに達している
  • WaitForFirstConsumer モードで Pod がスケジュールされるまで PVC が Bound されない仕様
  • Node の CSI ドライバーが正常に動作していない
確認手順
  • kubectl describe pvc <pvc> の Events でプロビジョニングエラーを確認
  • kubectl get storageclass で指定した StorageClass が存在するか確認
  • kubectl get pods -n kube-system | grep csi でCSIドライバーのPodが起動しているか確認
  • Azure Portal でサブスクリプションのディスクプロビジョニングクォータを確認
  • kubectl describe pvc でアベイラビリティゾーンの制約を確認
AKS ノードオートスケーラー(Cluster Autoscaler)スケールアウト失敗
想定される原因
  • AzureサブスクリプションのvCPUクォータが上限に達している
  • ノードプールのmax-countに達しスケールアウトが停止
  • ターゲットリージョン/SKUのキャパシティ不足
  • Cluster AutoscalerのPodリソースリクエストが不正でスケールアップ判断できない
  • ノードプールのVMSSがデプロイに失敗している
確認手順
  • kubectl get events でPendingPodのスケジューリング失敗理由を確認
  • az vm list-usage でリージョンのvCPUクォータ残量を確認
  • ノードプールのmin/max count設定を確認
  • Cluster AutoscalerのログをPodログで確認
AKS Azure CNI IPアドレス枯渇
想定される原因
  • Azure CNIモードでPodsとNodesが同じサブネットのIPを消費してIPが枯渇
  • サブネットのCIDRが小さすぎる(/24で254IPで不足)
  • ノード追加時に各ノードが事前予約するIP(max-pods × nodes)を超過
  • 削除済みのPod/NICのIPがリリースされていない
確認手順
  • az network vnet subnet show でAvailableIPAddressesを確認
  • kubectl get nodes でノード数とmax-pods設定を確認
  • IPアドレス消費量: ノード数 × max-pods(デフォルト30)を計算
  • 未使用のNIC(孤立したリソース)を確認
AKS Workload Identity認証失敗
想定される原因
  • フェデレーテッドクレデンシャルのIssuer URLがAKSのOIDC Issuer URLと不一致
  • SubjectがサービスアカウントのNS/名前と不一致
  • AKSのOIDC Issuer機能が有効化されていない
確認手順
  • az aks show でOIDC Issuer URLを確認
  • kubectl get sa -o yaml でサービスアカウントのannotationを確認
  • フェデレーテッドクレデンシャルのIssuer/Subjectを確認
AKS ノードプールアップグレード失敗(ドレイン障害)
想定される原因
  • PDB(Pod Disruption Budget)がノードドレイン中のPod削除をブロック
  • Terminatingのまま固まるPod(finalizer待ち)
  • maxSurge設定が低すぎてアップグレードスループットが不足
確認手順
  • kubectl get pdb -A でALLOWED DISRUPTIONSが0でないか確認
  • kubectl get pods でTerminatingのままのPodを特定
  • az aks nodepool show でupgrade設定(maxSurge)を確認
502 Bad Gateway - Backend Worker Crash
想定される原因
  • アプリケーションプロセス(w3wp.exe)がクラッシュしている
  • メモリ不足によるプロセスリサイクル
  • 未処理の例外がアプリケーションで発生している
  • Startup Timeoutが短すぎる設定になっている
確認手順
  • Azure Portal > App Service > Diagnose and solve problems > Availability and Performance を確認
  • Application Event Log (Kudu > Debug Console > D:/home/LogFiles/eventlog.xml) を確認
  • App Service > Logs > Application logs で例外スタックトレースを確認
  • App Service Plan のメモリ使用率メトリクスを確認
  • WEBSITE_SCM_ALWAYS_ON_ENABLED の設定を確認
502 Bad Gateway - Backend Timeout (SCM/Upstream)
想定される原因
  • バックエンドアプリの処理が 230 秒(ARR timeout)を超えている
  • データベースクエリのタイムアウト
  • 外部 API 呼び出しが遅延している
  • Cold start による初期化遅延
確認手順
  • App Service > Metrics > Response Time で応答時間を確認
  • Application Insights > Performance > Slow requests を確認
  • 依存サービス(DB, 外部API)の応答時間を確認
  • WEBSITE_SWAP_WARMUP_PING_PATH が設定されているか確認
アプリケーション起動失敗 (Startup Failure)
想定される原因
  • 環境変数・接続文字列の設定漏れ
  • 起動タイムアウト(WEBSITES_CONTAINER_START_TIME_LIMIT)超過
  • 依存ライブラリのバージョン不一致
  • ポートのバインド設定ミス (PORT 環境変数)
  • app.config / appsettings.json の設定エラー
確認手順
  • App Service > Configuration > Application Settings で環境変数を確認
  • Kudu Console (Advanced Tools) > LogFiles > Application を確認
  • Docker コンテナの場合: App Service > Log stream でリアルタイムログ確認
  • WEBSITES_PORT または PORT 環境変数が正しいか確認
  • デプロイパッケージの完全性を確認
DNS 名前解決エラー
想定される原因
  • VNet 統合時のカスタム DNS 設定ミス
  • Private Endpoint の DNS ゾーン設定不備
  • 接続先ホスト名のスペルミス
  • WEBSITE_DNS_SERVER 設定が誤っている
確認手順
  • App Service > Networking > VNet Integration の DNS 設定を確認
  • Kudu Console で nslookup <hostname> を実行
  • Private DNS Zone のリンク設定を確認
  • WEBSITE_DNS_SERVER 環境変数を確認
  • 接続先サービスの FQDN が正しいか確認
認証エラー (EasyAuth / AAD)
想定される原因
  • AAD アプリ登録のリダイレクト URI 設定ミス
  • クライアントシークレットの期限切れ
  • トークンの audience (aud) が不一致
  • EasyAuth の設定ミス (Provider configuration)
  • CORS 設定と認証の競合
確認手順
  • Azure AD > App registrations > Authentication でリダイレクト URI を確認
  • App Service > Authentication でプロバイダー設定を確認
  • クライアントシークレットの有効期限を Azure AD で確認
  • ブラウザの開発者ツールで Authorization ヘッダーを確認
  • App Service ログで WWW-Authenticate ヘッダーの内容を確認
SNAT ポート枯渇
想定される原因
  • 短命な HTTP クライアントを都度 new している (HttpClient の使いまわし不足)
  • DB コネクションプールの枯渇
  • アウトバウンド接続の急増(バースト)
  • App Service Plan のインスタンス数に対して SNAT ポートが不足
確認手順
  • App Service > Diagnose and solve > SNAT Port Exhaustion を確認
  • App Service > Metrics > SNAT Connection Count を監視
  • コードで HttpClient/HttpClientFactory が正しく利用されているか確認
  • DB 接続をコネクションプール経由にしているか確認
  • App Service Plan のスケールアウト設定を確認
依存サービス接続タイムアウト (DB / Redis / Storage)
想定される原因
  • データベースのリソース制限(DTU/vCore枯渇)
  • ファイアウォール/NSG でアウトバウンドをブロックしている
  • 接続文字列の設定ミス(ポート、ホスト名)
  • Private Endpoint の設定不備
  • アイドル接続のタイムアウト後の再接続失敗
確認手順
  • Azure SQL / Redis のメトリクスでリソース使用率を確認
  • App Service > Networking でアウトバウンドルールを確認
  • App Service > Configuration で接続文字列を確認
  • Kudu Console から Test-NetConnection <host> <port> を実行
  • NSG/ファイアウォールのアウトバウンドルールを確認
ヘルスチェック失敗によるインスタンス除外
想定される原因
  • ヘルスチェックエンドポイントが認証を要求している
  • ヘルスチェックパスのレスポンスが 200 以外を返している
  • アプリの起動完了前にヘルスチェックが開始される
  • ヘルスチェックが内部で依存サービスに接触してタイムアウトしている
確認手順
  • App Service > Health check の設定パスを確認
  • そのパスへ直接 curl して応答コードを確認
  • ヘルスチェックエンドポイントに認証除外設定があるか確認
  • ヘルスチェックのレスポンスタイムを Application Insights で確認
設定・環境変数エラー (Configuration Error)
想定される原因
  • App Service Configuration に必要なキーが未設定
  • スロット (Staging/Production) 間で設定がコピーされていない
  • Key Vault 参照が失敗している (権限不足)
  • 環境名 (Development/Production) によって参照するファイルが異なる
確認手順
  • App Service > Configuration > Application Settings で全設定を確認
  • Key Vault 参照の場合: Managed Identity に Get/List 権限があるか確認
  • デプロイスロット固有の設定が正しいか確認
  • ローカルの appsettings.json と Azure 設定の差分を確認
デプロイ後の接続エラー / Cold Start 問題
想定される原因
  • Always On が無効で一定時間後にアプリがアンロードされる
  • Swap 時のウォームアップが不十分
  • .NET / Java のコンパイル・JIT による起動遅延
  • 起動時に大量のデータロードやキャッシュウォームアップをしている
確認手順
  • App Service > Configuration > Always On が有効か確認
  • App Service > Deployment slots > Swap 設定を確認
  • WEBSITE_SWAP_WARMUP_PING_PATH / WEBSITE_SWAP_WARMUP_PING_STATUSES を確認
  • 起動時間を Application Insights で計測
メモリリーク / OOM による強制再起動
想定される原因
  • アプリケーションのメモリリーク
  • 大きなオブジェクトのキャッシュが解放されない
  • App Service Plan のメモリが不足している
  • サードパーティライブラリのメモリリーク
確認手順
  • App Service > Metrics > Memory Working Set を時系列で確認
  • App Service > Diagnose > Memory Dump を取得して分析
  • Application Insights > Live Metrics でリアルタイムメモリを監視
  • アプリの IDisposable 実装と using ステートメントを確認
SSL/TLS 証明書エラー
想定される原因
  • カスタムドメインの証明書が期限切れ
  • 証明書の SNI バインドが設定されていない
  • 自己署名証明書をバックエンドで使用している
  • WEBSITE_LOAD_CERTIFICATES 設定が不足
確認手順
  • App Service > Custom domains > TLS/SSL bindings で証明書の有効期限を確認
  • 証明書の Common Name / SAN がドメインと一致するか確認
  • App Service > TLS/SSL settings で SNI バインドを確認
  • WEBSITE_LOAD_CERTIFICATES 環境変数に証明書の Thumbprint が設定されているか確認
Cold Start Timeout(コールドスタートタイムアウト)
想定される原因
  • Consumption プランでのスケールゼロからの初回起動遅延
  • 依存パッケージが多く DLL ロードに時間がかかる
  • アプリケーション起動時に重い初期化処理(DB 接続確立など)を実行している
  • 大きなデプロイパッケージによる起動遅延
  • 関数ホストのタイムアウト設定が短すぎる
確認手順
  • Application Insights > Performance > Cold Start の発生頻度と時間を確認
  • Azure Portal > Function App > Metrics > Function Execution Time を確認
  • host.json の functionTimeout 設定値を確認
  • デプロイパッケージのサイズと依存ライブラリ数を確認
  • Premium プランまたは App Service プランでの Pre-warmed インスタンス設定を確認
Host Not Started(Functionsホスト起動失敗)
想定される原因
  • host.json または function.json のバインディング設定が誤っている
  • 必要な拡張機能(NuGet パッケージ)がインストールされていない
  • 拡張機能バンドルのバージョンが不一致
  • function.json の bindings type/direction の設定ミス
  • worker プロセスの起動に必要な環境変数が未設定
確認手順
  • Azure Portal > Function App > Log stream でホスト起動ログを確認
  • host.json の extensionBundle バージョン指定を確認
  • function.json の bindings 設定(type, direction, name)を確認
  • Kudu (Advanced Tools) > Debug Console で extensions.csproj を確認
  • Application Insights > Exceptions でホスト起動例外を確認
Storage Connection Failure(ストレージ接続失敗)
想定される原因
  • AzureWebJobsStorage 接続文字列が未設定または誤り
  • ストレージアカウントが削除または無効化されている
  • ストレージアカウントへのネットワークアクセスがファイアウォールでブロックされている
  • ストレージアカウントのアクセスキーが再生成されて古いキーを参照している
  • Managed Identity でのストレージ接続に必要なロールが未付与
確認手順
  • App Settings の AzureWebJobsStorage 接続文字列が正しいか確認
  • Azure Portal でストレージアカウントの存在と状態を確認
  • ストレージアカウントのアクセスキーが最新かどうか確認
  • ストレージアカウントのネットワーク設定でファイアウォールルールを確認
  • Managed Identity を使用している場合: Storage Blob Data Owner ロールの付与を確認
Function Execution Timeout(実行タイムアウト)
想定される原因
  • 処理時間が host.json の functionTimeout 設定を超えている
  • 外部 API やデータベースへのリクエストが応答しない
  • 無限ループまたは再帰処理によるハングアップ
  • 大量データの同期処理による処理時間超過
  • Consumption プランの最大タイムアウト(10分)を超える処理
確認手順
  • host.json の functionTimeout 設定値を確認
  • Application Insights > Performance で関数の実行時間分布を確認
  • 関数内の外部呼び出し(HTTP、DB)にタイムアウト設定があるか確認
  • Application Insights > Dependencies で遅延している依存サービスを特定
  • プランごとのタイムアウト上限(Consumption: 10分, Premium/Dedicated: 無制限)を確認
Out of Memory(メモリ不足)
想定される原因
  • 大量データをメモリ上に一括ロードしている
  • アプリケーションのメモリリーク(未解放のオブジェクト)
  • Consumption プランのメモリ上限(1.5GB)を超える処理
  • 非同期タスクの大量並列実行によるメモリ圧迫
  • IDisposable オブジェクトが適切に破棄されていない
確認手順
  • Application Insights > Live Metrics でメモリ使用量をリアルタイム確認
  • Azure Monitor > Function App > Memory Working Set メトリクスを確認
  • 関数コードで大量データを一括でメモリにロードしていないか確認
  • IDisposable オブジェクトが using ブロックで適切に破棄されているか確認
  • Consumption プランのメモリ上限(1.5GB)と実際の使用量を比較
Scale-out Throttling(スケールアウト制限・429 Too Many Requests)
想定される原因
  • Consumption プランの無料実行数クォータ(月100万回/40万GB-秒)を超過
  • スケールアウト後も処理が追いつかず上流サービスがリトライを繰り返している
  • バースト的なトラフィックによるスケールアウト中の一時的な 429
  • Function App の同時実行数制限(host.json の maxConcurrentCalls)に達している
  • 依存サービス(Service Bus、Event Hub)のスロットリングが伝搬している
確認手順
  • Azure Portal > Function App > Metrics > Function Execution Count を確認
  • Application Insights > Failures で 429 エラーの発生パターンを確認
  • host.json の extensions.serviceBus.maxConcurrentCalls / maxConcurrentSessions を確認
  • 上流サービス(Service Bus、Event Hub)のメトリクスでバックログを確認
  • Consumption プランの課金メーターを確認して無料枠の残量を確認
Durable Functions Poison Queue(毒キュー蓄積・オーケストレーション失敗)
想定される原因
  • オーケストレーター関数のコードに非決定論的処理(DateTime.Now、Guid.NewGuid 等)が含まれる
  • アクティビティ関数が最大再試行回数を超えて失敗し続けている
  • オーケストレーター関数のコードを変更したがインフライト中のインスタンスが古い履歴をリプレイしようとしている
  • ストレージアカウントの操作タイムアウトによるオーケストレーション状態の破損
  • 外部イベントのタイムアウト(WaitForExternalEvent)による不整合
確認手順
  • Application Insights で OrchestrationFailed / ActivityFailed の例外を確認
  • Azure Storage Explorer でタスクハブの -poison キューに蓄積されたメッセージを確認
  • Durable Functions の監視エンドポイント(statusQueryGetUri)でインスタンス状態を確認
  • オーケストレーター関数内の DateTime.Now / Guid.NewGuid / Random 使用箇所を確認
  • 最近のコードデプロイとインフライト中のオーケストレーション開始時刻を比較
HTTP Trigger 401 Unauthorized(認証失敗)
想定される原因
  • Function Key が未設定またはリクエストヘッダー(x-functions-key)やクエリパラメータ(code=)に含まれていない
  • 使用している Function Key または Host Key が再生成されて古いキーを使用している
  • AuthorizationLevel が Function/Admin に設定されているが Anonymous を想定している
  • EasyAuth(Azure AD 認証)が有効なのに Bearer トークンを付与していない
  • IP アドレス制限または VNet 制限によってアクセスが拒否されている
確認手順
  • Azure Portal > Function App > Functions > <function> > Function Keys でキーの存在を確認
  • リクエストの x-functions-key ヘッダーまたは code= クエリパラメータを確認
  • function.json または関数属性の AuthorizationLevel を確認(Anonymous/Function/Admin)
  • Azure Portal > Function App > Authentication でEasyAuthの設定を確認
  • Azure Portal > Function App > Networking でアクセス制限を確認
Azure Functions Durable Functions オーケストレーション障害
想定される原因
  • オーケストレーター関数内で非決定論的コード(DateTime.Now等)を使用
  • アクティビティ関数のタイムアウト(デフォルト: 30分)
  • Azureストレージのタスクハブキューへのアクセス問題
  • 大量インスタンスによるストレージスロットリング
  • ネストされたサブオーケストレーションのデッドロック
確認手順
  • Azureポータルの Durable Functions Monitor拡張でオーケストレーション状態を確認
  • オーケストレーター関数内でDateTime.Now/Guid.NewGuid等の非決定論的コードがないか確認
  • ストレージアカウントのスロットリングメトリクスを確認
  • タスクハブのストレージキュー(-workitems等)の存在を確認
Azure Functions Premium プラン VNET統合での外部接続失敗
想定される原因
  • Functions AppのVNet統合でDNSがAzure Pのプライベートゾーンを参照していない
  • WEBSITE_DNS_SERVER設定が未設定でパブリックDNSを参照
  • VNet統合サブネットのルートテーブルがプライベートエンドポイントへのルートを持たない
  • NSGがFunctions App送信IPからプライベートエンドポイントへの通信をブロック
  • WEBSITE_VNET_ROUTE_ALL=1が未設定でVNET統合が部分的
確認手順
  • FunctionsアプリのVNet統合設定でサブネットを確認
  • WEBSITE_DNS_SERVER=168.63.129.16 の設定を確認
  • WEBSITE_VNET_ROUTE_ALL=1 の設定を確認
  • プライベートDNSゾーンがVNet統合のVNetにリンクされているか確認
Azure Functions Cold Start遅延(Consumptionプランのコールドスタート)
想定される原因
  • 従量課金プランでのコールドスタート(アイドル後のインスタンス初期化に5〜30秒)
  • Javaや.NETなど起動が重い言語ランタイムの初期化時間
  • 大きな依存ライブラリのロードに時間がかかる
確認手順
  • Application Insightsでcold start duration(host startup)を確認
  • Functions Planを確認(Consumption/Premium/Dedicated)
  • アプリのスタートアップコードの初期化時間を測定
Azure Functions Event Hubsトリガー処理遅延・チェックポイント障害
想定される原因
  • チェックポイント更新が失敗してイベントが再処理される
  • Functionsのスケールアウト数がパーティション数を超えている
  • バッチサイズの設定が大きすぎてタイムアウト
確認手順
  • Event Hub metricsでConsumer Group Lagを確認
  • FunctionsのscaleOut数とEvent Hubパーティション数を比較
  • host.jsonのeventHub設定(maxBatchSize)を確認
VM 応答なし / SSH・RDP 接続不可
想定される原因
  • NSG(ネットワークセキュリティグループ)のインバウンドルールでSSH/RDPポートがブロックされている
  • VMがフリーズ・ハングしてOSが応答していない
  • Azure Firewall またはパブリックIPが削除・変更された
  • VMのゲストOSのファイアウォール(iptables/Windows Firewall)がポートをブロックしている
  • VM停止(割り当て解除)状態になっている
確認手順
  • Azure Portal > VM > ネットワーク > NSGインバウンドルールでSSH(22)/RDP(3389)が許可されているか確認
  • Azure Portal > VM > 概要でVMの「実行中」ステータスを確認
  • Azure Portal > VM > ブートダイアグノスティクス > シリアルログでOS起動エラーがないか確認
  • Azure Portal > VM > シリアルコンソールでOSコンソールに直接アクセス
  • az vm get-instance-view --name <vm> --resource-group <rg> でVMの状態確認
VM CPU 高負荷 / レスポンス低下
想定される原因
  • アプリケーションのCPUリークまたは無限ループ
  • VMサイズに対してワークロードが大きすぎる
  • Burstable VM(B系)のCPUクレジット枯渇
  • マルウェア・暗号通貨マイニングプロセスの混入
  • バックグラウンドジョブ(バックアップ、インデックス再構築等)との競合
確認手順
  • Azure Monitor > VM > CPUメトリクスで過去1時間の推移を確認
  • SSH/RDPでログインし top/Task Manager でプロセスごとのCPU使用率を確認
  • az monitor metrics list でCPUメトリクスを取得
  • Burstable VM(B系)の場合 CPU Credits Consumed メトリクスを確認
  • Azure Advisor でVMサイズの推奨事項がないか確認
VM ディスク容量不足 / I/O エラー
想定される原因
  • OSディスクまたはデータディスクの空き容量が不足している
  • マネージドディスクのIOPS上限に達してスロットリングが発生
  • ログファイルやテンポラリファイルが無制限に増大している
  • ディスクサイズに対してVMサイズのディスクIOPS上限が低い
  • スナップショットや古いバックアップがディスクを圧迫
確認手順
  • df -h(Linux)または Get-PSDrive(Windows)でディスク使用量を確認
  • Azure Portal > VM > ディスク でディスクサイズとIOPS上限を確認
  • Azure Monitor > ディスク読み書きIOPS メトリクスでスロットリングを確認
  • du -sh /* でディレクトリ別使用量を確認し大きなファイルを特定
  • Azure Diagnostics Extension のディスクメトリクスを確認
VM 起動失敗 / ブートエラー
想定される原因
  • カーネルパニックまたはブートローダーの破損
  • リージョンのリソース不足でVM割り当てに失敗(Allocation Failed)
  • fstabの誤設定で起動時にマウントエラーが発生
  • OSディスクの破損またはファイルシステムエラー
  • Windowsの自動更新後に互換性の問題が発生
確認手順
  • Azure Portal > VM > ブートダイアグノスティクス > スクリーンショット でブート画面を確認
  • Azure Portal > VM > シリアルログ でOSレベルのエラーメッセージを確認
  • Azure Portal > アクティビティログ でAllocation Failedエラーを確認
  • 別のVMにOSディスクをアタッチしてfstabやブートファイルを修復
VM メモリ不足 / OOM Killer 発動
想定される原因
  • アプリケーションのメモリリーク
  • VMサイズに対して同時接続数・処理量が多すぎる
  • キャッシュ設定が不適切でメモリを使い切っている
  • スワップ領域が未設定または小さすぎる
  • Javaヒープサイズの設定ミスで上限なく増大
確認手順
  • free -h(Linux)でメモリ・スワップ使用量を確認
  • Azure Monitor > 利用可能メモリバイト数 メトリクスを確認
  • /var/log/syslog または /var/log/messages で OOM Killer ログを確認
  • ps aux --sort=-%mem でメモリ消費上位プロセスを確認
  • vmstat 1 5 でメモリ・スワップの動的変化を観察
VM への外部接続エラー(NSG / パブリックIP)
想定される原因
  • NSGのインバウンドルールでポートがブロックされている
  • パブリックIPが割り当てられていない、または削除された
  • VMの内部ファイアウォール(iptables/ufw)がポートをブロック
  • ロードバランサーのバックエンドプールからVMが外れている
  • Azure Firewall のポリシーで通信が拒否されている
確認手順
  • Azure Portal > VM > ネットワーク でNSGルールとパブリックIPを確認
  • az network nsg rule list でNSGルールを一覧表示
  • Azure Network Watcher > IP フロー検証 でパケットの到達可否を確認
  • iptables -L(Linux)でOS内ファイアウォールルールを確認
  • ロードバランサーのバックエンドプールメンバーシップを確認
VM 拡張機能(Extension)インストール失敗
想定される原因
  • Azure VMエージェント(waagent)が起動していないまたはバージョンが古い
  • カスタムスクリプト拡張機能のスクリプトが実行エラーで失敗
  • インターネット接続不可でExtensionのダウンロードに失敗
  • 拡張機能のタイムアウト(デフォルト90分)を超過
  • 同じ拡張機能が既にインストール済みで競合
確認手順
  • Azure Portal > VM > 拡張機能 でプロビジョニング状態とエラーメッセージを確認
  • /var/log/azure/(Linux)またはC:\WindowsAzure\Logs\(Windows)でエージェントログを確認
  • systemctl status walinuxagent(Linux)でVMエージェントの状態確認
  • VMからインターネット(storage.azure.com等)への疎通を確認
  • az vm extension list でインストール済み拡張機能を確認
VM バックアップ失敗(Azure Backup)
想定される原因
  • VSS(Volume Shadow Copy Service)エラーでスナップショット取得に失敗(Windows)
  • VMのゲストエージェントが応答していない
  • ディスク容量不足でスナップショット領域が確保できない
  • カスタムスクリプトまたはアプリがVSSと競合している
  • Recovery Services VaultとVMが別リージョンにある
確認手順
  • Azure Portal > Recovery Services Vault > バックアップジョブ でエラー詳細を確認
  • イベントビューアー > アプリケーション でVSSエラーを確認(Windows)
  • VMのゲストエージェントの状態を確認(waagent/Windows Azure Guest Agent)
  • ディスクの空き容量を確認(スナップショット用に10%以上必要)
  • バックアップポリシーのリージョン設定を確認
Azure VM スポットインスタンス(Spot VM)突然の削除/エビクション
想定される原因
  • Azureのキャパシティ不足でスポットVMがエビクション(Eviction)
  • スポット価格が設定した最大価格(Max Price)を超過
  • エビクションポリシーが Deallocate でなく Delete になっている
  • Scheduled Eventsを監視していないためグレースフルシャットダウンできていない
確認手順
  • Azure Instance Metadata Service(IMDS)でScheduled Eventsを確認
  • エビクションポリシーが Deallocate か Delete かを確認
  • リージョンのスポットVMキャパシティを別SKUで確認
  • Azure Monitorでスポット削除イベントを確認
Azure VM ブートエラー(シリアルコンソール・救急ブート)
想定される原因
  • /etc/fstabの不正エントリによりLinux VMがemergencyモードで起動
  • WindowsのBCDストア破損によりシステムが起動不能
  • OSディスクのファイルシステム破損
  • カーネルアップデート後のドライバー非互換
確認手順
  • Azureポータルのブート診断でスクリーンショットとシリアルログを確認
  • シリアルコンソールでVMに直接アクセスして状態確認
  • Windowsの場合: BCD/bootrec コマンドで修復
  • Linuxの場合: emergencyモードで /etc/fstab を修正
Azure VM Custom Script Extension(CSE)実行失敗
想定される原因
  • スクリプトが非ゼロの終了コードで終了している
  • スクリプトのダウンロードURLに到達できない(StorageのSAS期限切れ等)
  • スクリプトの実行時間が制限(90分)を超えた
  • 実行ユーザーの権限不足
確認手順
  • Azureポータルの拡張機能のステータスとエラーメッセージを確認
  • VM内の /var/log/azure/custom-script/handler.log(Linux)を確認
  • C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\(Windows)を確認
  • スクリプトのダウンロードURLに到達できるか確認
Azure VM VMSS(Virtual Machine Scale Sets)ローリングアップグレード障害
想定される原因
  • ローリングアップグレード中の新インスタンスのヘルスプローブが失敗
  • Application Healthエクステンション(またはLBヘルスプローブ)の設定ミス
  • 新OSイメージでアプリケーションが正常起動しない
  • アップグレードポリシーの maxUnhealthyUpgradedInstancePercent が厳しすぎる
確認手順
  • VMSSのローリングアップグレードステータスを確認
  • アップグレード済みインスタンスのApplication Healthエクステンションの状態を確認
  • 新インスタンスのアプリケーションログを確認
  • LBヘルスプローブの設定とアプリのヘルスエンドポイントを確認
Azure SQL 接続タイムアウト / 接続プール枯渇
想定される原因
  • 接続プールのMax Pool Sizeに達しており新規接続が取得できない
  • アプリケーションがDB接続を適切にCloseしていない(コネクションリーク)
  • Azure SQLのDTU/vCoreリミットに達してクエリ処理が遅延
  • ファイアウォールルールでアプリからの接続がブロックされている
  • Azureの一時的な接続障害(Transient Fault)
確認手順
  • Azure Portal > SQL Database > メトリクス > DTU消費率 で上限に達していないか確認
  • 接続文字列の Max Pool Size 設定値を確認(デフォルト100)
  • アプリケーションのDB接続の Open/Close が対になっているか確認
  • Azure Portal > SQL Server > ファイアウォールと仮想ネットワーク でIPが許可されているか確認
  • sys.dm_exec_sessions でアクティブ接続数を確認
Azure SQL クエリタイムアウト / デッドロック
想定される原因
  • インデックス不足により全表スキャンが発生してクエリが遅延
  • 複数トランザクションが同一リソースを逆順にロックしてデッドロック
  • 長時間のトランザクションがロックを保持し続けている
  • DTU/vCoreリミットに達してクエリ実行がスロットリングされている
  • 統計情報が古くて非効率なクエリプランが選択されている
確認手順
  • Azure Portal > SQL Database > クエリパフォーマンス分析 (Query Performance Insight) で遅いクエリを確認
  • sys.dm_exec_requests でブロッキングチェーンを確認
  • Azure SQL の拡張イベント (Extended Events) でデッドロックグラフを取得
  • sys.dm_db_missing_index_details で不足インデックスを確認
  • DBCC SHOW_STATISTICS でテーブル統計の鮮度を確認
Azure SQL 認証エラー(ログイン失敗)
想定される原因
  • SQLログインのパスワードが変更または期限切れになっている
  • Azure AD認証のトークンが無効または期限切れ
  • ユーザーが対象データベースに存在しない(contained databaseユーザー未作成)
  • マネージドIDに必要なデータベース権限が付与されていない
  • ファイアウォールブロックと認証エラーが混同されている
確認手順
  • 接続文字列のユーザー名・パスワードが正しいか確認
  • Azure AD認証の場合、マネージドIDまたはサービスプリンシパルに権限があるか確認
  • SQL Server Management Studio (SSMS) で同じ認証情報でログインテスト
  • sys.server_principals で対象ユーザーの存在を確認
  • Azure Portal > SQL Server > Azure Active Directory でAD認証設定を確認
Azure SQL DTU / CPU リソース上限
想定される原因
  • データベースのDTUまたはvCore上限に達して処理がスロットリング
  • クエリの最適化不足で過剰なリソースを消費している
  • バッチ処理やバックアップと通常処理が同時実行してリソース競合
  • テーブル統計の陳腐化により非効率なクエリプランが実行されている
  • 接続数が多すぎてworker threadが枯渇
確認手順
  • Azure Portal > SQL Database > メトリクス > DTU割合(または CPU割合)を確認
  • sys.dm_db_resource_stats でリソース使用履歴を確認(直近64分)
  • Azure Monitor > SQL Database メトリクスで過去7日のリソース推移を確認
  • Query Performance Insight でリソース消費上位クエリを特定
  • sys.dm_exec_query_stats でCPU消費の多いクエリを特定
Azure SQL ファイアウォール / 接続拒否
想定される原因
  • サーバーレベルのファイアウォールルールにクライアントIPが含まれていない
  • Azure サービス(App Service等)からの接続で「Azureサービスを許可」が無効
  • 仮想ネットワークサービスエンドポイントが設定されていない
  • Private Endpointのみ有効でパブリックアクセスが無効化されている
  • データベースレベルのファイアウォールが別の設定になっている
確認手順
  • Azure Portal > SQL Server > ネットワーク > ファイアウォールルールでクライアントIPを確認
  • 「Azureサービスおよびリソースにこのサーバーへのアクセスを許可する」が有効かを確認
  • Azure Virtual NetworkのサービスエンドポイントとSQL Serverのルールを確認
  • Private Endpointの設定とDNS解決(privatelink)を確認
Azure SQL ストレージ上限 / ディスク容量超過
想定される原因
  • データベースのサイズがサービス層の上限(max_size)に達した
  • トランザクションログが肥大化してサイズ上限に到達
  • 大量のデータ挿入または削除後にログスペースが開放されていない
  • Geo-replicationが遅延していてログが開放されない
  • サービス層(S0等)のmax_sizeが小さすぎる
確認手順
  • SELECT * FROM sys.database_files でデータファイルとログファイルのサイズを確認
  • DBCC SQLPERF(LOGSPACE) でログ使用率を確認
  • Azure Portal > SQL Database > ストレージメトリクスで使用量を確認
  • データベースのmax_size設定をPortalで確認
  • Geo-replicationの複製遅延(Lag)を確認
Azure SQL Geo-replication / フェールオーバー障害
想定される原因
  • セカンダリリージョンが障害または一時的に利用不可
  • ネットワーク遅延でGeo-replicationの同期が遅延(Lag増大)
  • フェールオーバーグループの設定が正しくない
  • プライマリDBへの書き込み負荷が高くセカンダリへの反映が追いつかない
  • セカンダリDBに対するユーザー権限が不足
確認手順
  • Azure Portal > SQL Database > Geo-replication でレプリケーション状態とラグを確認
  • sys.dm_geo_replication_link_status でレプリケーション遅延を確認
  • Azure Service Health でセカンダリリージョンの障害情報を確認
  • フェールオーバーグループのRTO/RPO設定を確認
  • セカンダリDBの接続文字列と権限を確認
Azure SQL Database Elastic Pool リソース競合
想定される原因
  • 特定のデータベースがElastic Poolの全eDTUを消費しプール全体が遅延
  • Elastic Poolの最大eDTU設定が実際のワークロードに対して不足
  • プール内のデータベース数が増加し合計リソース要求が超過
  • バッチ処理やメンテナンスタスクが業務時間帯に実行されている
確認手順
  • Azureポータルの Elastic Pool メトリクス(eDTU percentage)を確認
  • 各データベースのDTU使用率を確認して高消費データベースを特定
  • per database min/max DTUの設定を確認
  • sys.dm_exec_requests でアクティブクエリを確認
Azure SQL Managed Instance VNet統合接続障害
想定される原因
  • SQL MI専用サブネットのNSGに必須インバウンド/アウトバウンドルールが不足
  • サブネットのルートテーブルにMicrosoft.Sql管理トラフィック用のルートがない
  • VNetピアリング経由のDNS解決でMIのプライベートDNSゾーンが伝播されていない
  • サブネットの委任(Delegation)がManagedInstanceに設定されていない
確認手順
  • MI専用サブネットのNSGに管理ポート(9000, 9003, 1438, 1440, 1452等)が開いているか確認
  • サブネットのルートテーブルにInternet宛の0.0.0.0/0が設定されているか確認
  • nslookup <mi-name>.database.windows.net でDNS解決を確認
  • サブネット委任(Microsoft.Sql/managedInstances)の設定確認
Azure SQL Database 長時間トランザクションによるブロッキング
想定される原因
  • 長時間実行のトランザクションが大量の行ロックを保持
  • アプリケーションがトランザクションをコミット/ロールバックしないままコネクションを保持
  • バッチ更新でロックエスカレーション(行ロック→ページ→テーブル)が発生
  • 明示的トランザクション内でのユーザー入力待ちによるロック長時間保持
確認手順
  • sys.dm_exec_requests で wait_type=LCK_M_* のブロッキングセッションを特定
  • sys.dm_os_waiting_tasks でブロッキングチェーンの根本(head blocker)を特定
  • sys.dm_tran_locks でロック保持中のリソースとトランザクションを確認
  • Query Store でブロッキングの原因クエリを特定
Application Gateway 502 Bad Gateway
想定される原因
  • バックエンドサーバーがダウンまたはヘルスプローブに応答していない
  • ヘルスプローブのパス・ポート設定がバックエンドと一致していない
  • NSGがApplication Gatewayからバックエンドへのトラフィックをブロックしている
  • バックエンドのレスポンスタイムがヘルスプローブのタイムアウトを超えている
  • Application Gatewayのバックエンドプールが空(サーバーが設定されていない)
確認手順
  • Azure Portal > Application Gateway > バックエンドの正常性 で各バックエンドの状態を確認
  • ヘルスプローブの設定(パス、ポート、プロトコル、タイムアウト)をバックエンドに合わせて確認
  • バックエンドサーバーに直接アクセスしてサービスが応答するか確認
  • NSGのインバウンドルールでApplication Gatewayの管理ポート(65200-65535)とバックエンドポートが許可されているか確認
  • Application Gateway のアクセスログ・パフォーマンスログ(Log Analytics)でエラー詳細を確認
Application Gateway SSL/TLS 証明書エラー
想定される原因
  • リスナーのSSL証明書が期限切れになっている
  • バックエンドのHTTPS設定でホスト名とSSL証明書のCNが一致しない
  • 中間CA証明書がチェーンに含まれていない
  • Key Vaultの証明書が更新されたが参照が古いバージョンのまま
  • バックエンドのSSL証明書が自己署名で信頼されていない
確認手順
  • Azure Portal > Application Gateway > リスナー で証明書の有効期限を確認
  • Azure Key Vault > 証明書 で証明書の状態と有効期限を確認
  • バックエンドHTTPS設定の「認証証明書」または「信頼されたルート証明書」の設定を確認
  • openssl s_client -connect <backend>:443 でバックエンドの証明書チェーンを確認
  • Application Gateway のバックエンド正常性でSSLエラーのメッセージを確認
Application Gateway 接続タイムアウト / レスポンス遅延
想定される原因
  • バックエンドアプリの処理時間がApplication Gatewayのリクエストタイムアウト(デフォルト30秒)を超えている
  • アイドルタイムアウト(デフォルト4分)以内にレスポンスが返っていない
  • バックエンドのデータベースクエリや外部API呼び出しが遅延
  • バックエンドのCPU/メモリリソース不足で処理が遅延
  • KeepAliveの設定がバックエンドとApplication Gatewayで不一致
確認手順
  • Azure Portal > Application Gateway > バックエンドHTTP設定 > 要求タイムアウト(秒)を確認
  • Application Gateway のアクセスログでtimeTakenを確認して遅いリクエストを特定
  • バックエンドサーバーのログでリクエスト処理時間を確認
  • バックエンドサーバーのCPU/メモリ使用率を確認
  • Application Gateway のメトリクス(Failed Requests, BackendResponseLatency)を確認
Application Gateway WAF ブロック
想定される原因
  • WAFのOWASP CRS(Core Rule Set)が正当なリクエストを誤検知してブロック
  • SQLインジェクション・XSS防御ルールがアプリの正常なクエリパラメータに反応
  • WAFが検出モード(Detection)ではなく防止モード(Prevention)で動作している
  • カスタムルールで意図しないIPやURLをブロック
  • ファイルアップロードのリクエストサイズがWAFの上限を超えている
確認手順
  • Azure Portal > Application Gateway > WAF > ログ でブロックされたリクエストとルールIDを確認
  • Log Analytics で AzureDiagnostics | where Category == 'ApplicationGatewayFirewallLog' を実行
  • ルールIDをMicrosoft公式ドキュメントで検索して誤検知かを判断
  • WAFのモードが「防止」か「検出」かを確認
  • ブロックされたリクエストのURIとパラメータを確認
Application Gateway ルーティング設定ミス(404 / パスベースルーティング)
想定される原因
  • パスベースルーティングのURLパスパターンが正規表現または文字列として正しく設定されていない
  • URL書き換えルールのパターンが意図しないリダイレクトループを引き起こしている
  • デフォルトルートのバックエンドが設定されていない
  • リスナーとルーティングルールの組み合わせが意図しない順序で評価されている
  • マルチサイトリスナーのホスト名設定が誤っている
確認手順
  • Azure Portal > Application Gateway > ルール でパスベースルールのURLパターンを確認
  • Azure Portal > Application Gateway > バックエンドの正常性 でバックエンドの割り当てを確認
  • Application Gateway アクセスログでrequestUriとruleNameを確認
  • URL書き換えルールの正規表現を検証ツールでテスト
  • リスナーの優先度とルートルールの評価順序を確認
Application Gateway スケール不足 / CU 上限
想定される原因
  • トラフィックが急増してApplication GatewayのCU(Capacity Unit)が上限に達した
  • オートスケールの最大CU設定が実際のトラフィック量に対して低すぎる
  • SSL処理(暗号化・復号)がCUを大量消費している
  • WAFが有効な場合、検査処理でCU消費が増加
  • 固定スケール(Manual)設定でインスタンス数が不足
確認手順
  • Azure Portal > Application Gateway > メトリクス > 現在の容量ユニット を確認
  • Application Gateway のオートスケール設定(最小CU・最大CU)を確認
  • スループット(Mbps)メトリクスで帯域使用量を確認
  • 新規接続数/秒メトリクスでピーク時の接続数を確認
  • WAF有効時はCU消費が約2倍になることを考慮した設定か確認
Application Gateway カスタムエラーページ / レスポンスコード設定
想定される原因
  • カスタムエラーページのURL(Blobストレージ等)がパブリックアクセス不可になっている
  • エラーページのHTMLが外部リソース(CSS/画像)を参照しておりそれらも取得できない
  • レスポンスコード書き換えルールの条件式が誤っており意図しないステータスコードが返る
  • Application GatewayのカスタムエラーページURLがHTTPSでないためMixed Content警告
  • カスタムエラーページの設定がグローバルではなくリスナー個別に必要なのに未設定
確認手順
  • Azure Portal > Application Gateway > HTTP設定 / リスナー でカスタムエラーページURLを確認
  • カスタムエラーページURLに外部からアクセスして表示できるか確認
  • Blob StorageのアクセスレベルがパブリックかSAS必要かを確認
  • 書き換えルールの条件式をPortalのテスト機能で検証
  • ブラウザの開発者ツールでエラーページ表示時のネットワークリクエストを確認
Application Gateway Mutual TLS(mTLS)クライアント証明書エラー
想定される原因
  • クライアントがTLS接続時にクライアント証明書を送信していない
  • クライアント証明書の発行CAがApplication GatewayのTrusted Client CA証明書に登録されていない
  • クライアント証明書が期限切れまたは失効(CRL/OCSP)している
  • Application GatewayのSSLポリシーがクライアント証明書の要求設定になっていない
  • クライアント証明書のSAN/CNがApplication Gatewayのホスト名と一致しない
確認手順
  • Azure Portal > Application Gateway > SSL設定 でmTLS(クライアント認証)の有効化状態を確認
  • Azure Portal > Application Gateway > SSL設定 > 信頼されたクライアントCA証明書 でCA一覧を確認
  • openssl s_client -connect <agw-fqdn>:443 -cert client.pem -key client.key でmTLSハンドシェイクをテスト
  • openssl x509 -in client.pem -text でクライアント証明書の有効期限と発行CAを確認
  • Application GatewayのアクセスログでSSL related error codeを確認
Application Gateway v2 自動スケール障害・インスタンス不足
想定される原因
  • Application Gateway v2の最大インスタンス数(125)に達している
  • minCapacity設定が低すぎてトラフィックスパイク時に追いつかない
  • 手動スケーリングモードで設定されたインスタンス数が不足
  • WAFモードが有効でCPU使用率が高い
確認手順
  • Azureポータルの「Capacity Units」メトリクスで使用率を確認
  • インスタンス数のメトリクスを確認
  • CPU使用率とスループットのメトリクスを確認
  • Application Gateway v1 vs v2のどちらを使用しているか確認
Application Gateway バックエンドHTTPSのSSL証明書検証エラー
想定される原因
  • バックエンドのSSL証明書がApplication Gatewayのトラステッドルート証明書に含まれていない
  • エンドツーエンドSSL設定でバックエンドの証明書のCN/SANがホスト名と不一致
  • バックエンドHTTPS設定で「ホスト名をバックエンドのアドレスから取得」が未設定
  • 自己署名証明書使用時のルート証明書のアップロード漏れ
確認手順
  • Azureポータルの「バックエンドの正常性」でSSLエラー詳細を確認
  • バックエンドのSSL証明書のCN/SAN、発行CA、有効期限を確認
  • HTTP設定の「ホスト名を選択する」設定を確認
  • Application GatewayのTrusted Root Certificatesを確認
Application Gateway URL Rewrite設定ミスによるルーティング障害
想定される原因
  • URLリライトの正規表現キャプチャグループの参照番号が誤っている({var_uri_path_1}等)
  • リライト条件の評価順序が意図と異なる
  • パスベースルーティングとURLリライトの組み合わせが競合
  • 大文字小文字の扱いがリライトルールで考慮されていない
確認手順
  • Application GatewayのログでURL rewriteの適用を確認
  • テストリクエストを送信してリライト後のURLをバックエンドログで確認
  • リライトルールの条件と正規表現を個別にテスト
  • パスベースルーティングとリライトルールの適用順序を確認
Application Gateway カスタムエラーページのCORS設定問題
想定される原因
  • WAFがCORSプリフライトのOPTIONSリクエストをブロック
  • WAFエラーレスポンスにAccess-Control-Allow-Originヘッダーがない
  • AGWのバックエンドがCORSヘッダーを返さずにAGWがそのまま転送
  • カスタムエラーページにCORSヘッダーが含まれていない
確認手順
  • OPTIONSリクエストがWAFによってブロックされているかAgwAccessログを確認
  • ブラウザのNetworkタブでCORSプリフライトのレスポンスを確認
  • AGWのヘッダーレスポンスポリシーを確認
  • WAFの管理ルールでOPTIONSが除外されているか確認
APIM 401 / 403 認証・認可エラー
想定される原因
  • Subscription Keyが無効、期限切れ、または送信されていない
  • JWTトークンの署名・有効期限・audienceの検証に失敗
  • APIのサブスクリプション要件がクライアントと一致していない
  • OAuth2.0のスコープがAPI操作の要件を満たしていない
  • IPフィルタリングポリシーでクライアントIPがブロックされている
確認手順
  • Azure Portal > APIM > APIキー でSubscription Keyの有効性を確認
  • Azure Portal > APIM > テスト でAPIを直接テストしてエラーを再現
  • APIM の診断ログ(Application Insights / Log Analytics)でエラー詳細を確認
  • APIのポリシーXMLで validate-jwt または check-header ポリシーの設定を確認
  • JWTトークンをjwt.ioでデコードしてaudience/issuer/expを確認
APIM バックエンド 502 / タイムアウト
想定される原因
  • バックエンドAPIサーバーがダウンまたは応答していない
  • APIMのバックエンドURLが誤っているまたは変更されている
  • バックエンドへの接続がNSGまたはファイアウォールでブロックされている
  • APIMのタイムアウト設定(デフォルト60秒)をバックエンドの処理時間が超過
  • バックエンドのSSL証明書が無効でAPIMが接続を拒否
確認手順
  • Azure Portal > APIM > バックエンド でバックエンドURLとヘルス状態を確認
  • APIM の診断ログでbackendUrl、バックエンドレスポンスコードを確認
  • バックエンドURLにcurlで直接アクセスして応答を確認
  • APIMのポリシーで forward-request ポリシーのtimeoutを確認
  • バックエンドのSSL証明書が有効かopenssl s_clientで確認
APIM レート制限 / クォータ超過(429)
想定される原因
  • rate-limit-by-key または rate-limit ポリシーで設定した呼び出し数を超えた
  • quota または quota-by-key ポリシーで月次クォータに達した
  • 特定のSubscription(またはクライアントIP)が集中的にAPIを呼び出している
  • クライアントがリトライロジックで短時間に大量のリクエストを送信
  • APIM のキャパシティ(CU)が不足して内部的にスロットリングが発生
確認手順
  • Azure Portal > APIM > APIポリシー でrate-limitまたはquotaポリシーの設定値を確認
  • Azure Portal > APIM > メトリクス > 要求合計、成功した要求でトレンドを確認
  • APIM 診断ログでSubscriptionId別の呼び出し数を分析
  • Application Insights でサブスクリプション・IPごとの呼び出し頻度を確認
  • APIMのキャパシティ(Capacity)メトリクスで過負荷状態を確認
APIM ポリシー実行エラー
想定される原因
  • ポリシーのC#式(Policy expression)が実行時エラーを引き起こしている
  • コンテキスト変数(context.Variables)に存在しないキーにアクセスしている
  • rewrite-uri のテンプレート文字列が正しくない
  • ポリシーの適用スコープ(グローバル/製品/API/操作)が意図と異なる
  • 外部サービス参照(send-request等)が失敗している
確認手順
  • Azure Portal > APIM > テスト でAPIを実行してトレースでポリシーの実行ステップを確認
  • 「Ocp-Apim-Trace: true」ヘッダーをつけてレスポンスのOcp-Apim-Trace-Locationからトレースを取得
  • Application Insights のException / Traceログでポリシーエラーを確認
  • ポリシーXMLの式(@(...))をポリシーエディタで構文チェック
  • ポリシースコープの継承順(グローバル→製品→API→操作)を確認
APIM VNet統合 / Private Endpoint 接続エラー
想定される原因
  • APIMのVNet統合でバックエンドのDNS解決ができていない
  • NSGがAPIMのサブネットへのトラフィックをブロックしている(管理ポート65200-65535)
  • 内部モードのAPIMに外部からアクセスしようとしている
  • Private Endpointのプライベートリンクが正しく設定されていない
  • サブネットのサービスエンドポイントやUDRが誤設定されている
確認手順
  • Azure Portal > APIM > ネットワーク でVNet統合の状態と接続状況を確認
  • NSGのインバウンドルールでインターネットからポート65200-65535(管理)が許可されているか確認
  • Private DNSゾーン(privatelink.azure-api.net)の設定を確認
  • APIMのサブネットに正しいNSGとUDRが適用されているか確認
  • nslookup <apim-name>.azure-api.net でDNS解決先を確認
APIM キャッシュ不整合 / Redis 外部キャッシュエラー
想定される原因
  • 外部Redis Cache(Azure Cache for Redis)への接続が切れている
  • RedisのSSL設定(TLS要求)とAPIMの接続設定が不一致
  • cache-lookup / cache-store ポリシーのキー設定が不適切でキャッシュが効かない
  • vary-by-header / vary-by-query-string の設定が原因で期待しないキャッシュキーが生成
  • Redisのメモリ上限(maxmemory)に達してキャッシュエントリが削除されている
確認手順
  • Azure Portal > APIM > 外部キャッシュ で外部Redisの接続状態を確認
  • Azure Cache for Redis > コンソール で PING コマンドを実行して疎通確認
  • APIMのポリシーで cache-lookup ポリシーのvary-by設定を確認
  • Azure Cache for Redis のメモリ使用量メトリクスとEvictedKeysを確認
  • APIMのトレースでキャッシュHIT/MISSの動作を確認
APIM バックエンド API バージョン管理 / リビジョン競合
想定される原因
  • クライアントが廃止(deprecated)されたAPIバージョンを使い続けている
  • APIバージョン設定でバージョンヘッダー/クエリパラメータが必須なのに送信されていない
  • バックエンドAPIにBreaking Changeが入り古いリビジョンと互換性が失われた
  • 複数のリビジョンが存在し、現在のリビジョン以外がデフォルトのまま
  • APIバージョン管理ポリシーが複数のVersion Setで矛盾している
確認手順
  • Azure Portal > APIM > API > バージョン でバージョン一覧と現在リビジョンを確認
  • クライアントのリクエストにApi-Version ヘッダーまたはクエリパラメータが含まれているか確認
  • APIMのアクセスログでどのAPIバージョン/リビジョンが呼ばれているか確認
  • バックエンドAPIのSwagger/OpenAPI仕様でBreaking Changeを確認
  • APIMのサブスクリプション利用状況レポートで古いバージョンの使用者を特定
APIM スケーリング不足 / 容量アラート
想定される原因
  • トラフィック増加でAPIMのキャパシティ(Capacity)メトリクスが70%を超えている
  • 単一ユニットでのスループット上限(約250リクエスト/秒)に達している
  • CPUヘビーなポリシー(JWT検証・暗号化)がユニットを圧迫
  • ログ記録(Application Insights)のオーバーヘッドが高い
  • Developer/Basic/Standard層でゾーン冗長やマルチリージョンが使えない
確認手順
  • Azure Portal > APIM > メトリクス > キャパシティ で使用率を確認(70%超えがスケールアウトの目安)
  • Azure Portal > APIM > スケール でユニット数と現在のキャパシティを確認
  • Application Insights のSampling設定でログ量を確認
  • APIMのCPU使用率を関連メトリクスで確認
  • 各APIのスループット(リクエスト数/分)を確認して負荷の偏りを特定
Azure APIM 証明書(クライアント証明書)認証エラー
想定される原因
  • APIMのポリシーでクライアント証明書のthumbprintが許可リストに含まれていない
  • クライアント証明書がAPIMに送信されていない(HTTPSでもクライアント証明書は別途送信が必要)
  • バックエンドサービスへのmTLS接続でAPIMのクライアント証明書が設定されていない
  • 証明書の有効期限切れ
確認手順
  • APIMのポリシーで validate-client-certificate または check-header の設定を確認
  • 証明書の有効期限をAzureポータルで確認
  • APIMのバックエンド設定でクライアント証明書が選択されているか確認
  • Application Insightsのトレースで受信した証明書のthumbprintを確認
Azure APIM デベロッパーポータルのOAuth2.0認証フロー障害
想定される原因
  • AADアプリ登録のリダイレクトURIにデベロッパーポータルのURLが含まれていない
  • トークンエンドポイントのCORS設定がデベロッパーポータルのオリジンを許可していない
  • APIMのOAuth2.0認証サーバー設定のクライアントIDが誤っている
  • PKCEフローが必要なのにclient_secretのみで設定されている
確認手順
  • AADアプリ登録の「リダイレクトURI」に https://<apim-instance>.developer.azure-api.net/oauth2/callback を追加
  • APIMのOAuth2.0認証サーバー設定でクライアントID/シークレットを確認
  • デベロッパーポータルの「OAuth2.0」設定でスコープを確認
  • ブラウザのNetworkタブでOAuth2フローのエラー詳細を確認
Azure APIM エラーポリシーとバックエンドエラーの伝播設定
想定される原因
  • ポリシーのon-errorセクションが設定されていなくデフォルトの500エラーが返る
  • バックエンドのエラーレスポンスをAPIMポリシーが書き換えている
  • forward-requestポリシーが欠落してバックエンドにリクエストが転送されない
  • ポリシー変数(context.Response等)の誤参照
確認手順
  • APIMポリシーのon-error/on-outbound-requestセクションを確認
  • Application Insightsのtraceでpolicy実行フローを確認
  • テストコンソールでpolicyの実行ステップを確認
  • forward-requestポリシーの位置と設定を確認
Azure APIM 自己ホスト型ゲートウェイ(Self-hosted Gateway)接続障害
想定される原因
  • オンプレミスFWがAPIMのconfig endpoint(*.azure-api.net:443)をブロック
  • Self-hosted GatewayのSAS Token/認証情報が期限切れ
  • ゲートウェイのDockerイメージのバージョンが古くAPIMとの互換性がない
  • KubernetesのNetworkPolicyがゲートウェイのAPIアウトバウンドをブロック
確認手順
  • ゲートウェイPodのログでconfig endpointへの接続エラーを確認
  • APIMポータルでSelf-hosted Gatewayのオンライン状態を確認
  • ゲートウェイからAPIM Config Endpointへのアウトバウンド443接続を確認
  • SAS Tokenの有効期限を確認
Blob Storage 403 / 認証・SASトークンエラー
想定される原因
  • SASトークンの有効期限が切れている
  • ストレージアカウントキーがローテーションされて接続文字列が古くなっている
  • Blob コンテナーのアクセスレベルが「プライベート」でAnonymousアクセスが不可
  • マネージドIDにストレージへのRBACロール(Storage Blob Data Contributor等)が未付与
  • SASトークンのIPアドレス制限または許可プロトコルが一致しない
確認手順
  • SASトークンの有効期限(se=)をデコードして確認
  • Azure Portal > Storage Account > アクセスキー でキーの状態を確認
  • Azure Portal > Storage Account > コンテナー > アクセスポリシー でアクセスレベルを確認
  • Azure Portal > ストレージアカウント > IAM でマネージドIDのロール割り当てを確認
  • Azure Storage Explorer でSASまたは接続文字列を使って接続テスト
Blob Storage 接続タイムアウト / スロットリング
想定される原因
  • ストレージアカウントのIOPS・帯域・リクエスト数の上限に達してスロットリングが発生
  • 大量のBlobアクセスが同一パーティション(同一プレフィックス)に集中している
  • 大きなBlobの並行ダウンロードで帯域幅の上限を超過
  • Standard StorageとPremium Storageの性能差を考慮していない設計
  • 同一ストレージアカウントを多数のサービスが共有してリソース競合
確認手順
  • Azure Portal > Storage Account > メトリクス > トランザクション、成功率を確認
  • Azure Monitor でSuccessE2ELatencyとSuccessServerLatencyを確認(スロットリング判定)
  • StorageRead/StorageWrite のDiagnosticsログでThrottlingErrorを確認
  • ストレージアカウントのIngress/Egress帯域メトリクスを確認
  • az storage account show で現在のサービス制限を確認
Blob Storage 404 / Blob が見つからない
想定される原因
  • Blobが削除されている(ソフト削除が有効な場合は復元可能)
  • Blob名のパス(大文字小文字含む)が完全一致していない
  • コンテナー名が誤っているまたはコンテナーが削除されている
  • SASトークンのスコープに対象のコンテナー/Blobが含まれていない
  • レプリケーション遅延でGRS/ZRS のセカンダリに未反映
確認手順
  • Azure Portal > Storage Account > Storage Browser でBlobとコンテナーの存在を確認
  • ソフト削除が有効な場合、「削除済みBLOBを表示」でアーカイブを確認
  • Blob名(パス、大文字小文字)をURLエンコードも含めて正確に確認
  • SASトークンのsigned resource(sr=b/c)が対象スコープと一致しているか確認
  • az storage blob list でコンテナー内のBlob一覧を確認
Blob Storage CORS エラー
想定される原因
  • ストレージアカウントのCORSポリシーで対象のOriginが許可されていない
  • CORSポリシーで許可するHTTPメソッドが設定されていない
  • CORSポリシーで許可するヘッダーが不足している
  • CORSが設定されていない(デフォルトは無効)
  • ブラウザのキャッシュに古いCORS設定が残っている
確認手順
  • Azure Portal > Storage Account > リソース共有(CORS)でCORSルールを確認
  • ブラウザの開発者ツール > Networkタブで preflight(OPTIONS)リクエストの応答を確認
  • curlで OPTIONS リクエストを送ってAccess-Control-Allow-Originヘッダーを確認
  • Azure Storage CORSポリシーのAllowed Origins、Methods、Headers を確認
Blob Storage ストレージアカウント無効化 / ロック
想定される原因
  • ストレージアカウントキーベース認証が無効化されている(セキュリティポリシーによる)
  • Azure Policyによりストレージアカウントの設定変更がブロックされている
  • リソースロック(CanNotDelete/ReadOnly)が適用されている
  • 支払い遅延によりサブスクリプションが停止してストレージが無効化
  • 不審なアクティビティ検知によりMicrosoftがアカウントを一時停止
確認手順
  • Azure Portal > Storage Account > 設定 > 構成でキーアクセスが有効か確認
  • Azure Portal > リソース > ロック でリソースロックを確認
  • Azure Policy のコンプライアンス状態でNon-compliantポリシーを確認
  • サブスクリプションの支払い状態とコスト管理を確認
  • Azure Security Center / Defender でアラートを確認
Blob Storage ライフサイクル管理 / 自動階層化エラー
想定される原因
  • Archiveアクセス層のBlobをリハイドレーション(Archive→Cool/Hot)せずに直接読もうとした
  • リハイドレーションの優先度設定(Standard: 最大15時間, High: 1時間以内)を把握していない
  • ライフサイクルポリシーのルール条件(lastModified/createdAfter等)が意図と異なる
  • 不変ポリシー(Immutability Policy)が設定されていてライフサイクルポリシーと競合
  • ライフサイクルポリシー適用後のBlobをすぐに確認しようとした(適用は非同期)
確認手順
  • Azure Portal > Storage Account > ライフサイクル管理 でポリシールールの条件を確認
  • 対象Blobのアクセス層(Hot/Cool/Cold/Archive)を確認
  • Archiveblobの場合、x-ms-rehydrate-priority ヘッダーの設定を確認
  • 不変ポリシーの設定を確認(WORM: Write Once Read Many)
  • ライフサイクルポリシーの最後の実行日時と次回実行予定を確認
Blob Storage 大容量アップロード / チャンク転送エラー
想定される原因
  • ブロックのタイムアウト(コミット期限は7日間)が切れた後にCommitBlockListを実行
  • ネットワーク不安定でPutBlock中に接続が切れてブロックが不完全
  • 単一Blobの最大サイズ(Block Blob: 約190.7TiB、ブロックサイズ上限: 4000MiB)を超えようとした
  • 並列アップロードのスレッド数が多すぎてスロットリングが発生
  • クライアントライブラリのバージョンが古くチャンク転送に対応していない
確認手順
  • エラーのブロックIDを特定してGetBlockListで未コミットブロックの状態を確認
  • アップロード完了率(転送済みバイト)とタイムアウト設定を確認
  • Azure Storage SDK のバージョンを確認(最新の Azure.Storage.Blobs を推奨)
  • Azure Monitor でストレージのスロットリングエラー(ServerBusyError)を確認
  • ネットワーク帯域とMTU設定を確認
Azure Blob Storage プライベートエンドポイント経由のアクセス失敗
想定される原因
  • プライベートDNSゾーン(privatelink.blob.core.windows.net)がVNetにリンクされていない
  • プライベートエンドポイントのDNS設定が自動登録されていない
  • オンプレミスDNSがAzureのプライベートDNSゾーンにフォワードしていない
  • ストレージアカウントのパブリックアクセス無効化後にプライベートエンドポイントが未設定
確認手順
  • プライベートDNSゾーンが正しいVNetにリンクされているか確認
  • nslookup <account>.blob.core.windows.net でプライベートIPが返るか確認
  • プライベートエンドポイントのApproval状態がApprovedか確認
  • NSGでプライベートエンドポイントへのポート443が許可されているか確認
Azure Blob Storage 不変ストレージ(WORM)による削除・変更エラー
想定される原因
  • コンテナまたはBlobに不変ポリシー(Time-based Retention)が設定されている
  • リーガルホールドが設定されておりロックがかかっている
  • 不変ポリシーがロック済み(Locked)で期間変更不可
  • コンプライアンス要件でデータが保護されている(意図的な設定)
確認手順
  • コンテナの不変ポリシー設定を確認(Azureポータル → コンテナ → アクセスポリシー)
  • リーガルホールドタグの一覧を確認
  • ポリシーのRetention期間と現在日時を比較して期限切れを確認
  • ポリシーがUnlocked(変更可能)かLocked(変更不可)かを確認
Azure Blob Storage カスタムドメイン(CDN)設定後のSSLエラー
想定される原因
  • Blob Storageのカスタムドメイン設定でHTTPS未対応(Azure CDN経由が必要)
  • Azure CDNのカスタムHTTPS証明書のプロビジョニングが完了していない(最大8時間)
  • CNAMEの検証レコード(cdnverify)が正しく設定されていない
  • DigiCert/GlobalSignの証明書メール承認が未完了
確認手順
  • Azure CDNカスタムHTTPSのプロビジョニング状態を確認(Azureポータル)
  • DNS CNAMEレコードがCDNエンドポイントを正しく指しているか確認
  • cdnverify.customdomain → cdnverify.endpoint.azureedge.net のCNAMEを確認
  • DigiCertからのメール承認が完了しているか確認
VNet 間通信不可 / VNet Peering 障害
想定される原因
  • VNet PeeringがDisconnected状態になっている(片側のみ削除等)
  • VNetのアドレス空間(CIDRブロック)が重複しており Peering が確立できない
  • Peering設定で「転送されたトラフィックを許可」が無効になっている
  • NSGがVNet間の通信をブロックしている
  • UDR(ユーザー定義ルート)が意図しないルートを設定してトラフィックを迂回させている
確認手順
  • Azure Portal > VNet > ピアリング でピアリングの状態が「接続済み」か確認
  • 両VNetのピアリング設定(双方向)が正しく設定されているか確認
  • VNetのアドレス空間が重複していないかIPAM観点で確認
  • NSGのインバウンド/アウトバウンドルールでVirtualNetworkタグが許可されているか確認
  • Azure Network Watcher > 接続トラブルシューティング で疎通確認
NSG ルールによるトラフィックブロック
想定される原因
  • NSGのデフォルト「DenyAllInbound」ルールが必要なポートを許可するルールより高い優先度で処理されている
  • 許可ルールの優先度(数値)が拒否ルールより高く(数値が大きく)なっている
  • 送信元/宛先IPアドレスまたはポート範囲の設定が正確でない
  • サブネットレベルとNICレベルの両方にNSGが設定されて二重にブロックされている
  • AzureサービスタグのIPレンジが更新されてNSGルールが古いIP情報を参照している
確認手順
  • Azure Portal > NSG > 受信セキュリティ規則 で優先度とルール内容を確認
  • Azure Portal > NSG > 有効なセキュリティ規則 でNIC/サブネット全体の評価順を確認
  • Azure Network Watcher > IP フロー検証 で特定の通信がNSGで許可されているか即確認
  • NSGフローログ(Log Analytics)で DENY ログを確認
  • NICとサブネットの両方にNSGが設定されていないか確認
VPN Gateway 接続障害(Site-to-Site / P2S)
想定される原因
  • IPsecの事前共有キー(PSK)またはルートベース/ポリシーベースの設定が両側で一致しない
  • BGPのASNまたはピアIPが誤設定されている
  • オンプレミス側のVPNデバイスがIKEv1/IKEv2設定で不一致
  • P2S VPNのルート証明書がVPN Gatewayに登録されていない
  • NAT-TがVPNデバイスで無効になっておりNAT越しの通信ができない
確認手順
  • Azure Portal > VPN Gateway > 接続 で接続状態とエラーメッセージを確認
  • Azure Portal > VPN Gateway > BGP ピアの状態 でBGPセッション状態を確認
  • オンプレミスVPNデバイスのログでIKEネゴシエーションエラーを確認
  • IPsecポリシー(IKEフェーズ1/2のアルゴリズム)がAzureとオンプレミスで一致しているか確認
  • Azure Network Watcher > VPN トラブルシューティング でゲートウェイ診断を実行
Azure DNS 名前解決エラー
想定される原因
  • Private DNSゾーンがVNetにリンクされていない
  • カスタムDNSサーバーが設定されているがVNet内から到達できない
  • Private Endpointを作成したがPrivate DNSゾーンのAレコードが自動登録されていない
  • 分割ビューDNS(スプリットブレイン)の設定が不正で内部/外部で解決先が異なる
  • VNetのDNSサーバー設定が168.63.129.16(Azure DNS)以外になっている
確認手順
  • Azure Portal > Private DNS Zone > 仮想ネットワークリンク でVNetへのリンクを確認
  • Azure Portal > VNet > DNS サーバー でカスタムDNS設定を確認
  • nslookup <hostname> 168.63.129.16 でAzure DNSに直接問い合わせてレコードを確認
  • Private Endpoint を持つリソースのPrivate DNS統合設定を確認
  • VM上でcat /etc/resolv.conf(Linux)でDNSサーバーIPを確認
UDR(ユーザー定義ルート)によるルーティング問題
想定される原因
  • UDRのネクストホップIPアドレスが到達不可能(NVAが停止等)
  • 0.0.0.0/0のデフォルトルートをNVA(Network Virtual Appliance)に向けているがNVAが障害
  • 非対称ルーティングでリクエストとレスポンスが異なる経路を通りファイアウォールで遮断
  • 特定のサービス(Azure PaaS)へのルートが誤ってNVA経由になっている
  • サブネット間でUDR設定の整合性が取れていない
確認手順
  • Azure Portal > VM > ネットワーク > 有効なルート で実際に適用されているルートを確認
  • Azure Network Watcher > 次ホップ で特定の通信先への実際のルートを確認
  • UDRのネクストホップIPのNVAが正常稼働しているか確認
  • ルートテーブルがサブネットに正しく関連付けられているか確認
  • Azureシステムルートが意図せずUDRで上書きされていないか確認
Azure Firewall トラフィックブロック / ルール誤設定
想定される原因
  • ネットワークルールコレクションでアウトバウンドの特定ポートが許可されていない
  • アプリケーションルールでFQDN(ドメイン)が許可リストに含まれていない
  • 脅威インテリジェンス(Threat Intelligence)が正当なサービスのIPをマルウェアと誤検知してブロック
  • ルールコレクションの優先度順序が意図と異なり拒否ルールが先に評価されている
  • DNSプロキシ機能が有効でFQDN解決に失敗してアプリケーションルールが適用できない
確認手順
  • Azure Portal > Azure Firewall > ログ(Log Analytics)でDenyされたトラフィックの詳細を確認
  • AzureDiagnostics | where Category == 'AzureFirewallNetworkRule' and Action == 'Deny' でフィルタ
  • Azure Portal > Firewall Policy > ルールコレクション で各ルールの優先度とアクションを確認
  • 脅威インテリジェンスアラートのIPを確認して誤検知かを判断
  • Azure Firewall のDNSプロキシ設定とDNSサーバー設定を確認
Azure Bastion 接続エラー / RDP-SSH 問題
想定される原因
  • AzureBastionSubnetのNSGがBastionに必要なインバウンド/アウトバウンドポートをブロック
  • Bastion SubnetのサイズがAzure要件(/26以上)を満たしていない
  • BastionからターゲットVMへのポート3389(RDP)または22(SSH)がVMのNSGでブロック
  • BastionのSKUがBasicのままでStandardの機能(ネイティブクライアント等)を使おうとしている
  • VNetPeeringまたはVPN経由のVM接続でBastionの経路設定が不足
確認手順
  • Azure Portal > Bastion > 概要 でプロビジョニング状態と設定を確認
  • AzureBastionSubnetのNSGでGatewayManager(443インバウンド)とAzureCloud(443アウトバウンド)が許可されているか確認
  • AzureBastionSubnetのアドレス空間が/26以上であることを確認
  • ターゲットVMのNSGでBastionのサブネットアドレス範囲からRDP/SSHポートが許可されているか確認
  • Bastion > セッション でアクティブセッションと失敗セッションを確認
ExpressRoute 回線障害 / BGP セッション断
想定される原因
  • オンプレミス側のCEルーターとAzureのBGPセッションがHoldタイムアウトで切断
  • ExpressRoute回線プロバイダー側での障害または計画メンテナンス
  • BGPのAS番号またはピアIPアドレスの設定ミス(オンプレ側とAzure側で不一致)
  • オンプレミスからAzureへのプレフィックス広告が停止(アドバタイズ制限等)
  • ExpressRouteゲートウェイのリソース不足でBGPセッションが維持できない
確認手順
  • Azure Portal > ExpressRoute回線 > 概要 でプロバイダー状態と回線状態を確認
  • Azure Portal > ExpressRoute回線 > プライベートピアリング > ARP テーブル/ルートテーブルを確認
  • Get-AzExpressRouteCircuitARPTable でARPテーブルを取得してL2接続を確認
  • Get-AzExpressRouteCircuitRouteTable でルートテーブルを確認してBGP経路受信状態を確認
  • プロバイダーへの障害報告が既にあるかプロバイダーポータルで確認
Azure Virtual Network Service Endpoint障害
想定される原因
  • サブネットにサービスエンドポイント(Microsoft.Storage等)が有効化されていない
  • リソース(ストレージ/SQL)のVNetルールにサブネットが追加されていない
  • サービスエンドポイントポリシーで特定のリソースのみ許可しているが対象が含まれていない
  • サービスエンドポイントの有効化後にVNetルール側の設定が未完了
確認手順
  • サブネット設定でサービスエンドポイント(Microsoft.Storage、Microsoft.Sql等)が有効か確認
  • ストレージ/SQLのファイアウォールとVNetルールにサブネットが追加されているか確認
  • サービスエンドポイントポリシーのリソース一覧を確認
  • az network vnet subnet show でserviceEndpointsを確認
Azure DDoS Protection スタンダードによる誤トラフィックミティゲーション
想定される原因
  • 正常なトラフィックスパイクがDDoS攻撃として誤検知されミティゲーション発動
  • DDoS Protectionのベースライン学習期間(約1週間)が完了していない
  • テスト/負荷試験トラフィックがDDoS検知閾値を超えた
  • DDoS Protection Standard未設定で無料の基本保護のみ
確認手順
  • Azure MonitorのDDoS Protectionアラートで攻撃ベクター詳細を確認
  • パブリックIPアドレスのDDoS Protection設定を確認
  • DDoSメトリクス(Under DDoS Attack、Packets Dropped等)を確認
  • ベースライン学習が完了しているか確認(有効化後7日以上経過)
Azure NAT Gateway の接続失敗と SNAT ポート枯渇
想定される原因
  • NAT GatewayのSNATポートが枯渇(1パブリックIP当たり64512ポート)
  • TCP接続が適切にクローズされずにTIME_WAIT状態でポートを保持
  • フロー数がNAT Gatewayの最大フロー数(300万)を超えた
  • アプリがコネクションプールを使用せず毎回新規接続
確認手順
  • NAT GatewayのメトリクスでSnatConnectionCountとDroppedPacketsを確認
  • アクティブなSNATポート使用数を確認(最大64512/IP)
  • TCPのTIME_WAIT接続数を確認(netstat -an | grep TIME_WAIT)
  • アプリのコネクション管理を確認
Azure Private DNS Resolver によるハイブリッド DNS 解決障害
想定される原因
  • Private DNS ResolverのForwardingRulesetがVNetにリンクされていない
  • アウトバウンドエンドポイントのForwarding Ruleの宛先DNSサーバーが誤っている
  • オンプレミスDNSからAzureへのforwarderがResolverのInboundエンドポイントIPを指していない
  • DNS Resolverのサブネット委任(Microsoft.Network/dnsResolvers)が未設定
確認手順
  • Private DNS ResolverのInbound/Outboundエンドポイントを確認
  • Forwarding RulesetがVNetにリンクされているか確認
  • ForwardingRuleの宛先DNSサーバーIPが正しいか確認
  • オンプレミスのDNS ConditionalForwarderの設定を確認
Front Door 503 / オリジン障害
想定される原因
  • オリジンサーバーがダウンしているかヘルスプローブに応答していない
  • ヘルスプローブのパスがオリジンに存在しない(404を返して非正常と判定)
  • Front Doorのヘルスプローブ送信元IPがオリジン側でブロックされている
  • オリジングループ内の全オリジンが非正常状態
  • オリジンの応答コードがヘルスプローブの期待値(200)と異なる
確認手順
  • Azure Portal > Front Door > オリジングループ で各オリジンの健全性状態を確認
  • Azure Portal > Front Door > レポート > ヘルスプローブログ でプローブ失敗の詳細を確認
  • オリジンサーバーにcurlで直接アクセスしてサービスが応答するか確認
  • オリジン側のファイアウォール/NSGでFront DoorのIPプレフィックス(AzureFrontDoorタグ)が許可されているか確認
  • Log Analytics でFrontdoorHealthProbeLog を確認
Front Door キャッシュ問題(古いコンテンツ配信)
想定される原因
  • Cache-Control ヘッダーのmax-ageが長すぎて古いコンテンツが配信され続けている
  • デプロイ後にキャッシュのパージを実施していない
  • クエリ文字列の扱い設定(ignore/include/exclude)が意図と異なりキャッシュキーが一致しない
  • URLが /foo/ と /foo の違い等でキャッシュキーが分かれて効率が悪い
  • 動的コンテンツにCache-Controlが設定されていなくてFront Doorがキャッシュしてしまっている
確認手順
  • Azure Portal > Front Door > キャッシュのパージ でパージの実施状態を確認
  • ブラウザの開発者ツールでレスポンスの Cache-Control と X-Cache ヘッダーを確認
  • Log Analytics でFrontdoorAccessLog の cacheStatus(HIT/MISS/BYPASS)を確認
  • キャッシュルールの設定(クエリ文字列の処理、TTL)を確認
  • オリジンのレスポンスヘッダーにCache-Controlが正しく設定されているか確認
Front Door SSL/TLS 証明書エラー
想定される原因
  • カスタムドメインのSSL証明書が期限切れ
  • Front Doorマネージド証明書のプロビジョニングに必要なCNAME検証が失敗
  • カスタムドメインのCNAMEレコードがFront Doorのエンドポイントを指していない
  • Key Vaultのカスタム証明書のバージョンが更新されたが参照が古い
  • DigiCertによる証明書発行に時間がかかっている(通常数時間)
確認手順
  • Azure Portal > Front Door > カスタムドメイン で証明書のステータスと有効期限を確認
  • DNSプロバイダーでドメインのCNAMEレコードがFront Doorのエンドポイント(.azurefd.net)を指しているか確認
  • nslookup <custom-domain> でDNS解決先を確認
  • Key Vault証明書を使っている場合、Front DoorのマネージドIDにKey Vaultのアクセス権があるか確認
  • Front DoorのマネージドID(システム割り当て)が有効か確認
Front Door WAF ブロック / DDoS 対策
想定される原因
  • WAFのOWASP マネージドルールが正当なリクエストを誤検知
  • ボット保護が通常のAPIクライアント(スクレーパー等)をブロック
  • WAFのレートリミットが低く設定されて通常トラフィックをブロック
  • WAFが検出モードではなく防止モードで運用されている
  • 特定のUser-Agentがボットとして分類されてブロックされている
確認手順
  • Azure Portal > WAF ポリシー > ログ でブロックされたリクエストとルールIDを確認
  • Log Analytics で AzureDiagnostics | where Category == 'FrontdoorWebApplicationFirewallLog' を実行
  • ブロックされたリクエストのRuleId、RuleGroup、Actionを確認
  • Microsoft公式ドキュメントでルールIDの説明と誤検知の対処法を確認
  • WAFポリシーのモード(検出/防止)を確認
Front Door ルーティング / リダイレクト設定ミス
想定される原因
  • HTTP→HTTPSリダイレクトをFront Doorとオリジンの両方で設定してリダイレクトループが発生
  • パスパターン(/* や /api/*)の優先順位が意図した順序で評価されていない
  • URL書き換えルールが誤っておりオリジンが404を返している
  • ルートルール(デフォルト)とカスタムルートの競合
  • HTTPS強制とHSTSの設定が競合している
確認手順
  • Azure Portal > Front Door > ルート でルートルールのパスパターンと優先順位を確認
  • ブラウザの開発者ツールでリダイレクト履歴(3xx)をトレース
  • オリジンが独自にHTTPS強制リダイレクトを行っていないか確認
  • curl -L でリダイレクトチェーンを追跡して無限ループを検出
  • Front Door の「ルールエンジン」でルール評価の詳細を確認
Front Door Private Link オリジン接続エラー
想定される原因
  • Private Linkオリジンの接続承認がオリジン側でまだ承認されていない(Pending状態)
  • オリジン(App Service / Storage等)のPrivate Endpointの接続要求が拒否または削除された
  • Front DoorのPremium SKUではないためPrivate Linkオリジンが使用できない
  • オリジンのPrivate Link サービスの設定(ロードバランサーやNSG)が正しくない
  • オリジンリソースのリージョンとFront Doorのオリジングループのリージョンが一致しない
確認手順
  • Azure Portal > オリジン側リソース(App Service等)> ネットワーク > Private Endpoint接続 で承認状態を確認
  • Azure Portal > Front Door > オリジングループ > オリジン > プライベートリンク設定を確認
  • Front DoorのSKUがPremiumであることを確認(Standard SKUはPrivate Link非対応)
  • オリジンのPrivate Link サービス設定(フロントエンドIP、ポート)を確認
  • 承認待ちのPrivate Endpoint接続リクエストをオリジン側で確認
Front Door レイテンシ増加 / パフォーマンス劣化
想定される原因
  • キャッシュヒット率が低くオリジンへのリクエストが多くオリジンのレイテンシが支配的
  • オリジンサーバー自体の処理が遅い(バックエンドの問題)
  • Front Doorのエッジロケーションからオリジンまでの物理距離が遠い
  • オリジンのヘルスプローブが失敗して正常なオリジンへのフォールバックが発生
  • TCPコネクションの確立コストが高い(Keep-Aliveが効いていない)
確認手順
  • Azure Portal > Front Door > レポート > レイテンシスコアカード でエッジ別レイテンシを確認
  • Azure Monitor > Front Door > TotalLatencyメトリクス(エンドツーエンド)を確認
  • Log Analytics で backendResponseLatencyMsMs とTimeTakenMs を比較してオリジン遅延を特定
  • キャッシュヒット率(CacheHitPercentage メトリクス)を確認
  • オリジンサーバーのレスポンスタイムをオリジン側ログで確認
Azure Front Door Standard/Premium WAFカスタムルールによる誤検知
想定される原因
  • WAFカスタムルールの条件が正常なリクエストと一致している
  • マネージドルールセット(DefaultRuleSet/BotManager)が特定パラメータを誤検知
  • レート制限カスタムルールのしきい値が低すぎる
  • Geo-filteringルールで意図しないリージョンがブロックされている
確認手順
  • Front Door WAFログ(FrontDoorWebApplicationFirewallLog)でブロックされたリクエストの詳細を確認
  • マッチしたルールID(RuleId)とアクションを特定
  • 正常なリクエストのヘッダー/パラメータとルール条件を比較
  • WAFポリシーのモードがDetectionかPreventionか確認
Azure Front Door セッションアフィニティ(スティッキーセッション)障害
想定される原因
  • Front Doorのセッションアフィニティが無効(デフォルト無効)
  • ブラウザがALSBSAクッキーをセキュア/HttpOnly属性のために保存しない
  • バックエンドのヘルスプローブ失敗により別のオリジンにフェイルオーバー
  • アプリケーションがステートレス設計でないのにセッションアフィニティに依存
確認手順
  • Front Doorルートのセッションアフィニティ設定を確認
  • ブラウザのDevToolsでALSBSAクッキーの有無を確認
  • バックエンドオリジンのヘルスプローブが全て成功しているか確認
  • アプリケーションの状態管理方式を確認(Redis等の外部セッションストア)
Azure Front Door カスタムドメインDNS検証失敗
想定される原因
  • DNSのTXTレコード(_dnsauth.<subdomain>)が設定されていないか伝播していない
  • CNAME検証(afdverify.)とTXT検証(_dnsauth.)の混同
  • DNS TTLが長くて変更が伝播していない
  • カスタムドメインがすでに別のFront Doorプロファイルに登録されている
確認手順
  • Azureポータルの「カスタムドメイン追加」でTXT検証値を確認
  • dig TXT _dnsauth.<subdomain>.<domain> で検証レコードを確認
  • DNS変更後のTTL経過時間を確認(最低5分待機推奨)
  • 他のFront Doorプロファイルに同じドメインが登録されていないか確認
Azure Load Balancer バックエンド非正常 / 疎通不可
想定される原因
  • バックエンドVMがダウンまたはヘルスプローブポートが閉じている
  • NSGがロードバランサーのヘルスプローブ(AzureLoadBalancerタグ)をブロックしている
  • ヘルスプローブのポートまたはパスがアプリの実際のポートと一致していない
  • バックエンドプールにVMが登録されていない
  • Floating IP(Direct Server Return)が有効でゲストOSの設定が追いついていない
確認手順
  • Azure Portal > Load Balancer > バックエンドプール でVMの登録状態を確認
  • Azure Portal > Load Balancer > 正常性プローブ でプローブ設定を確認
  • NSGのインバウンドルールでAzureLoadBalancer(168.63.129.16)からのトラフィックを許可しているか確認
  • バックエンドVMに直接接続してアプリがヘルスプローブポートで応答するか確認
  • Azure Monitor > ロードバランサー > ヘルスプローブの状態 メトリクスを確認
Load Balancer セッション維持 / スティッキーセッション問題
想定される原因
  • ロードバランシングルールのセッション永続性が「なし」になっている
  • クライアントIPがNATやプロキシで変わるため「クライアントIP」ベースのセッション維持が機能しない
  • バックエンドVMがスケーリングで入れ替わりセッション情報が失われた
  • アプリがセッション状態をVMローカルに保存しておりVM間で共有されていない
  • TCPアイドルタイムアウト(デフォルト4分)でセッションが切断された
確認手順
  • Azure Portal > Load Balancer > 負荷分散規則 でセッション永続性の設定を確認
  • アプリがセッション状態をRedis Cache等のセントラルストアに保存しているか確認
  • クライアントIPの変動(NAT/プロキシ)の有無を確認
  • TCPアイドルタイムアウト設定(デフォルト4分、最大30分)を確認
  • バックエンドVMのスケーリングイベントとセッション断のタイミングを相関分析
Load Balancer パブリックIP / アウトバウンド接続(SNAT)枯渇
想定される原因
  • バックエンドVMあたりのSNATポート数の上限(デフォルト1024)に達した
  • 大量の短時間接続を繰り返してSNATポートを消費している
  • アウトバウンドルールが設定されておらずデフォルトSNATに依存している
  • バックエンドプールのVM数が増えてVM1台あたりのSNATポートが減少
  • アプリがHTTP接続を毎回新規作成してSNATポートを消費している
確認手順
  • Azure Monitor > ロードバランサー > SNAT接続数 メトリクスで消費量を確認
  • Azure Monitor > SNAT接続失敗数 メトリクスで枯渇の発生を確認
  • バックエンドプール内のVM数と1VMあたりのSNATポート数の計算(合計64000/VM数)
  • アプリのHTTP接続プーリング設定を確認
  • アウトバウンドルールの設定有無を確認
Load Balancer 負荷分散ルール ポートマッピングエラー
想定される原因
  • インバウンドNATルールと負荷分散ルールが同一フロントエンドポートを競合して使用
  • バックエンドポートがVMのアプリとは異なるポートに設定されている
  • 同一フロントエンドIPアドレスの複数ルールが同じポートを参照している
  • HA ポートルール(すべてのポート)と個別ポートルールが混在して競合
  • フローティングIP有効時にゲストOS側でフロントエンドIPの設定が不足
確認手順
  • Azure Portal > Load Balancer > 負荷分散規則 で各ルールのフロントエンド/バックエンドポートを一覧確認
  • Azure Portal > Load Balancer > インバウンドNAT規則 でNATルールとのポート競合を確認
  • バックエンドVMで ss -tlnp または netstat -tlnp でリッスンポートを確認
  • HA ポートルール(プロトコル:All、ポート:0)の有無を確認
  • フロントエンドIPとポートの組み合わせが一意かを確認
Internal Load Balancer プライベートIP 解決失敗
想定される原因
  • ILBのフロントエンドIPがVNetの異なるサブネットから到達できない(UDRの問題)
  • NSGがILBのフロントエンドIPへのトラフィックをブロックしている
  • ILBと接続元VMが異なるVNetにあり、VNet Peeringが設定されていない
  • ILBのサブネットにUDRが設定されておりトラフィックが意図しない経路を通っている
  • Azure内部ルーティングでILBのプライベートIPへのルートが存在しない
確認手順
  • Azure Portal > Load Balancer > フロントエンドIP でプライベートIPとサブネットを確認
  • 接続元VMとILBが同一VNet内または適切にピアリングされたVNet内にあるか確認
  • Network Watcher > 次ホップ で接続元VMからILBのフロントエンドIPへの経路を確認
  • NSGのルールでILBフロントエンドIPへのトラフィックが許可されているか確認
  • 接続元サブネットのUDRでデフォルトルートが意図しない次ホップになっていないか確認
Load Balancer VMSS スケールアウト後の接続断
想定される原因
  • 新しいVMSSインスタンスが起動中でヘルスプローブに合格するまで時間がかかる
  • スケールイン時に接続ドレイン(connection draining)が設定されておらず既存セッションが切断される
  • ヘルスプローブのタイムアウト・間隔が短すぎて起動中のインスタンスを不合格と判定
  • カスタムスクリプト拡張機能の実行中はアプリが起動していない
  • VMSSのアップグレードポリシーが自動(Auto)でローリングアップグレード中にトラフィックが偏る
確認手順
  • Azure Portal > Load Balancer > 負荷分散規則 で「接続ドレイン」(アイドルタイムアウト)設定を確認
  • VMSSのヘルスプローブ応答時間を計測してプローブタイムアウトと比較
  • Azure Portal > VMSS > インスタンス でスケールアウトした新インスタンスの状態を確認
  • VMSSのアップグレードポリシーを確認
  • スケールイン時のインスタンスタイムアウト設定を確認
Load Balancer メトリクス異常 / 診断設定
想定される原因
  • Load Balancerの診断設定が有効化されておらずメトリクスがLog Analyticsに送られていない
  • メトリクスデータのギャップはスケールアウト/スケールイン中に発生しやすい
  • アラートルールのしきい値または集計期間の設定が実際の問題を検出できない設定になっている
  • Azure Monitorのデータ遅延(最大数分)でリアルタイム確認ができない
  • Load Balancer SKU(Basic vs Standard)によって利用可能なメトリクスが異なる
確認手順
  • Azure Portal > Load Balancer > 診断設定 で設定の有無と送信先(Log Analytics / Storage)を確認
  • Azure Portal > Load Balancer > メトリクス でデータポイントが表示されているか確認
  • Basic SKUとStandard SKUのメトリクス差異を確認(BasicはSNATメトリクス等が非対応)
  • アラートルールの集計タイプ(Average/Count/Max)としきい値を確認
  • Log Analyticsのクエリで AzureDiagnostics | where ResourceType == 'LOADBALANCERS' を確認
Azure Load Balancer フローティングIP(Direct Server Return)設定障害
想定される原因
  • フローティングIP有効時にバックエンドVMのループバックアダプタ設定が不足
  • SQL Server Always OnリスナーのILB構成でフローティングIPが必要だが未設定
  • HAポートルールと通常ポートルールが競合している
  • バックエンドがフローティングIPのVIPでリッスンしていない
確認手順
  • ロードバランサールールのFloating IPが有効か確認
  • バックエンドVMのループバックアダプタにVIPのIPアドレスが設定されているか確認
  • SQL Always OnリスナーのIPと一致するILBフロントエンドIP確認
  • HAポートルールのprotocol=All/port=0設定を確認
Azure Load Balancer アウトバウンド接続(SNAT)枯渇
想定される原因
  • アウトバウンドルールのSNATポート割り当てが不足(デフォルト: バックエンド台数で自動分配)
  • 同一パブリックIPからの大量短時間接続でポートが枯渇
  • Basic LBでのデフォルトアウトバウンドがStandard LBに移行できない
  • コネクションプールなしでDBへの大量接続
確認手順
  • Azureポータルで Load Balancer の SNATPortUsed メトリクスを確認
  • アウトバウンドルールの AllocatedSNATPorts を確認
  • バックエンドインスタンス数とSNATポート割り当て数の比率を確認
  • Connection Monitorでアウトバウンド接続失敗のパターンを分析
Azure Load Balancer クロスリージョン負荷分散障害
想定される原因
  • リージョナルLBのヘルスプローブが失敗しクロスリージョンLBから除外
  • クロスリージョンLBがStandard LBのみサポート(Basic LBは不可)
  • リージョナルLBのフロントエンドIPがクロスリージョンLBのバックエンドに登録されていない
  • セキュリティグループがグローバルLBのソースIP(147.243.0.0/16等)をブロック
確認手順
  • クロスリージョンLBのバックエンドプールにリージョナルLBが登録されているか確認
  • 各リージョンのStandard LBのヘルス状態を個別に確認
  • NSGでAzure Load Balancer サービスタグが許可されているか確認
  • クロスリージョンLBの対応リージョン(一部のみ)を確認
ファイアウォールポリシー暗黙的Denyによる通信ブロック
想定される原因
  • ファイアウォールポリシーに許可ルールが存在しない(暗黙的Deny)
  • アクセスリストの順序が誤っており、許可ルールよりDenyルールが先にマッチ
  • 送信元/宛先IPアドレスの範囲指定ミス
  • サービス追加時のポリシー更新漏れ
確認手順
  • show access-list で該当ACLのヒット数を確認
  • packet-tracer input <interface> tcp <src-ip> <src-port> <dst-ip> <dst-port> で通信シミュレーション
  • show conn でアクティブセッションの有無を確認
  • ログで Deny されたパケットの送信元・宛先・ポートを特定
NAT変換テーブル枯渇によるセッション確立失敗
想定される原因
  • PATポートプールが枯渇(最大65535ポート/IPアドレス)
  • 同時セッション数がNATプールIPアドレス数に対して過多
  • タイムアウト設定が長すぎてセッションが解放されない
  • NATプールIPアドレス数が不足
確認手順
  • show xlate count でNAT変換テーブルの使用数を確認
  • show conn count でアクティブセッション数を確認
  • show nat detail でプール使用状況を確認
  • show running-config nat でタイムアウト設定を確認
ファイアウォール同期失敗によるHA切り替え
想定される原因
  • フェイルオーバー専用インターフェース(ハートビートリンク)の断線
  • アクティブ機の障害によるスタンバイへの切り替え
  • コンフィグ同期失敗(バージョン不一致等)
  • ネットワーク遅延によるハートビートタイムアウト
確認手順
  • show failover でHA状態を確認
  • show failover history で切り替え履歴を確認
  • フェイルオーバー専用インターフェースのケーブルと物理リンクを確認
  • 両系のソフトウェアバージョンが一致しているか確認
SSL/TLS復号化エラーによるHTTPS通信ブロック
想定される原因
  • SSL復号化ポリシーの証明書が端末に信頼されていない
  • 証明書の有効期限切れ
  • クライアント証明書認証が必要なサービスでの復号化
  • 証明書ピンニング(Certificate Pinning)を使用するアプリ
確認手順
  • SSL復号化ポリシーで使用している中間CA証明書の有効期限確認
  • 端末のトラストストアにCA証明書が配布されているか確認
  • 該当サービスがCertificate Pinningを使用していないか確認
  • SSL復号化の除外リストに登録が必要か検討
セッションテーブル溢れによる新規接続不可
想定される原因
  • DDoS/SYNフラッド攻撃によるハーフオープンセッション増大
  • アプリケーションの接続リーク(セッションを正常クローズしない)
  • ファイアウォールのライセンスによるセッション数制限
  • タイムアウト設定が長すぎてゾンビセッションが蓄積
確認手順
  • show conn count で現在のセッション数と最大値を確認
  • show threat-detection statistics top-ports でトップ通信先を確認
  • show cpu usage でCPU負荷を確認
  • 外部からのSYNフラッドかアプリ側の問題か切り分け
IPSシグネチャ誤検知による正常通信ブロック
想定される原因
  • IPSシグネチャの誤検知(False Positive)
  • シグネチャの感度設定が高すぎる
  • 正常なトラフィックパターンが攻撃シグネチャに一致
  • シグネチャデータベースのバグ
確認手順
  • ブロックされた通信のシグネチャIDを特定
  • シグネチャの詳細(CVE番号、説明)を確認してFPの可能性を評価
  • 同じシグネチャが複数の正常ホストに対して発動していないか確認
  • シグネチャのベンダーリリースノートでFP報告がないか確認
管理インターフェースへの認証失敗ロックアウト
想定される原因
  • パスワード変更後の古いパスワードでのログイン試行
  • 自動化スクリプトが古い認証情報を使用
  • 外部からのブルートフォース攻撃
  • RADIUS/TACACサーバーとの認証連携障害
確認手順
  • ログイン試行元IPアドレスを確認(内部/外部の切り分け)
  • TACACS/RADIUSサーバーの疎通確認
  • アカウントのロックアウトポリシー設定を確認
  • 自動化ツール(Ansible等)の認証情報が最新か確認
ゾーンポリシー設定ミスによる双方向通信の片方向ブロック
想定される原因
  • 非対称ルーティングによりリターンパケットが異なるインターフェースで受信
  • ゾーンペアポリシーの双方向設定漏れ
  • Statefulファイアウォールの状態テーブルにセッション情報なし
  • NATルールの誤設定でリターントラフィックが変換されない
確認手順
  • traceroute で往路と復路の経路が一致しているか確認
  • show conn で接続状態を確認(established/half-open)
  • ゾーンポリシーの双方向設定を確認
  • ルーティングテーブルで非対称経路がないか確認
CPU/メモリ高負荷によるパフォーマンス低下
想定される原因
  • 大量のトラフィックによるNAT/ステート処理の増大
  • IPS/DPI機能によるCPU消費
  • ログ出力量の増大
  • ソフトウェアバグによるメモリリーク
確認手順
  • show processes cpu-usage sorted でCPUトッププロセスを確認
  • show memory detail でメモリ使用状況を確認
  • show interface でパケットドロップ数を確認
  • show conn count と show xlate count で処理量を確認
VRF/仮想ルーター設定ミスによるルーティング不能
想定される原因
  • VRF間のルートリーク設定漏れ
  • インターフェースが誤ったVRFに割り当てられている
  • VRF間通信に必要な静的ルートが未設定
  • MPLS/BGP VPNのルートディスティングイッシャー設定ミス
確認手順
  • show vrf でVRF一覧と割り当てインターフェースを確認
  • show ip route vrf <name> でVRF別ルーティングテーブルを確認
  • show run interface でインターフェースのVRF割り当てを確認
  • VRF間通信のルートリーク設定を確認
ファイアウォール非対称ルーティングによるセッション切断
想定される原因
  • 冗長FW構成でインバウンドとアウトバウンドが異なるFWを通過
  • ECMPで双方向の経路が異なる
  • FWクラスターのセッション同期が失敗
確認手順
  • FWセッションテーブルでinbound/outboundを確認
  • ルーティングテーブルで双方向の経路を確認
  • FWクラスターのセッション同期状態を確認
ファイアウォール ポリシーヒット数ゼロルールの誤検知と不要ルール整理
想定される原因
  • シャドウルール(より上位の広いルールにすでにマッチするため下位ルールが評価されない)
  • 過去に追加した不要なルールが残存
  • ルールの順序が誤っていて意図したポリシーが適用されない
  • ルールの期限切れや環境変更でルールが無効化された
確認手順
  • 各ルールのヒットカウントを90日以上のスパンで確認
  • ポリシー分析ツールでシャドウルールを特定
  • ルールの依存関係(同一ソース/宛先のルールの順序)を確認
  • ルール追加の経緯(変更管理ログ)を確認
ファイアウォール GeoIP/国別フィルタリングの誤検知
想定される原因
  • CDN/クラウドプロバイダーのAnyCast IPが実際の国と異なる国にGeolocation登録されている
  • GeoIPデータベースが古く新しいIPアドレスブロックの国情報が未更新
  • クラウドサービスのエグレスIPが日本国内サービスでも海外IPに見える
  • GeoIPデータベースのプロバイダーによって国情報が異なる
確認手順
  • ブロックされたIPアドレスのGeoIP情報を複数のサービスで確認
  • GeoIPデータベースの最終更新日を確認
  • 誤検知のIPがCDN/クラウドのIPレンジに属するか確認
  • FWベンダーのGeoIPデータベース更新スケジュールを確認
デフォルトルート喪失による全トラフィック断
想定される原因
  • 上流ISPとのリンクダウンによるデフォルトルート喪失
  • BGPセッション切断によるデフォルトルート撤回
  • スタティックルートのネクストホップ到達不能
  • フローティングスタティックルートへの切り替わり失敗
確認手順
  • show ip route でルーティングテーブルとデフォルトルートを確認
  • show interface <WAN-IF> でWANインターフェースの状態を確認
  • ping <upstream-GW> でゲートウェイの疎通確認
  • show ip bgp summary でBGPセッション状態を確認(BGP使用時)
インターフェースエラーカウンタ増大による通信品質低下
想定される原因
  • ケーブル劣化・断線によるCRCエラー
  • デュプレックス/スピードのネゴシエーション不一致
  • 物理層の電気的な問題(ノイズ、インピーダンス不整合)
  • 過負荷による出力キューの溢れ(output drop)
確認手順
  • show interfaces <IF> でエラーカウンタの詳細を確認
  • show interfaces <IF> counters errors で増加速度を確認
  • ケーブルとSFP/トランシーバーの物理確認
  • show interfaces <IF> でデュプレックス/スピード設定を確認
ルーティングループによるパケット転送不能
想定される原因
  • スタティックルートの誤設定(相互参照)
  • ダイナミックルーティングプロトコルのルート再配布ループ
  • フローティングスタティックルートとダイナミックルートの競合
  • RIPのカウントトゥインフィニティ
確認手順
  • traceroute <dst> でループしているホップを特定
  • show ip route <dst> で各ルーターのルーティングテーブルを確認
  • ルート再配布の設定(redistribute コマンド)を確認
  • ルートマップとアクセスリストの設定を確認
QoSキューイング設定ミスによる重要トラフィックの遅延
想定される原因
  • VoIP/ビデオトラフィックのDSCP値が正しくマークされていない
  • 帯域幅ポリシーの設定値が実際のトラフィックに対して不足
  • キューの優先度設定が逆転している
  • 中継ルーターでDSCPリマーキングされてしまう
確認手順
  • show policy-map interface <IF> でQoS適用状況とドロップ数を確認
  • show queue <IF> でキューの状態を確認
  • ping <dst> で遅延/ジッタを測定
  • ACL/DSCP値でトラフィック分類が正しく行われているか確認
CPUスパイクによるルーター制御プレーン過負荷
想定される原因
  • TTL=1のパケット(traceroute)による制御プレーン処理増大
  • ルーティングテーブルの揺らぎ(ルートフラッピング)
  • ACLロギングの過多
  • ブロードキャストストームまたはマルチキャストの過多
確認手順
  • show processes cpu sorted でCPU消費プロセスTop10を確認
  • show ip traffic でIPパケット統計を確認
  • show log でルートフラッピングのログを確認
  • show interfaces でブロードキャスト数を確認
MTU不一致によるパケット断片化・通信障害
想定される原因
  • VPN/トンネルによるオーバーヘッドでMTUを超過
  • PPPoEのMTU(1492)とEthernetのMTU(1500)の不一致
  • 一部区間でジャンボフレームが非対応
  • Path MTU Discovery Blackhole(ICMPブロック)
確認手順
  • ping <dst> size 1472 df-bit でMTUブラックホールを確認
  • traceroute でMTU制限区間を特定
  • show interfaces でMTU設定を確認
  • VPN/トンネルのMSS設定を確認
HSRP/VRRP切り替えによるゲートウェイフラッピング
想定される原因
  • ネットワーク遅延によるHSRPハローパケットのタイムアウト
  • プリエンプション設定によるアクティブ機の頻繁な交代
  • トラッキングオブジェクトの状態変化
  • 両系が同一プライオリティでアクティブを競合
確認手順
  • show standby brief でHSRP/VRRPの状態を確認
  • show standby <IF> detail でプライオリティとトラッキングを確認
  • 両系間の遅延を測定してハロータイムアウトと比較
  • show track でトラッキングオブジェクトの状態を確認
ACLの設定ミスによる意図しない通信制御
想定される原因
  • ワイルドカードマスクの計算ミス
  • ACLエントリの順序ミス(広いルールが先にマッチ)
  • インバウンド/アウトバウンドの方向指定ミス
  • 暗黙的なdeny any anyで意図したトラフィックがブロック
確認手順
  • show ip access-lists でヒット数を確認して誤マッチを特定
  • show run interface でACLの適用方向を確認
  • packet-tracer または debug ip packet でパケット追跡
  • ACLロジックを1エントリずつ手動検証
ルーター NAT変換テーブル枯渇による新規セッション失敗
想定される原因
  • NATテーブルの最大エントリ数(show ip nat translations total)が上限に達した
  • TCP/UDPセッションのタイムアウト値が長すぎてエントリが長期間残り続けている
  • PATプールのIPアドレス数が少なくポート空間(各IPあたり65535ポート)が不足
  • ショートフローを大量に発生させるアプリ(IoT等)が多数接続してテーブルを圧迫
  • NATのタイムアウト値がデフォルト(TCP:86400秒、UDP:300秒)のまま大規模NAT環境で動作
確認手順
  • show ip nat translations total でアクティブなNATエントリ数を確認
  • show ip nat statistics でhitcounts・missesとpool使用状況を確認
  • show ip nat translations | count で総エントリ数を確認
  • ip nat translation max-entries の設定値を確認(デフォルトはプラットフォーム依存)
  • show ip nat translations tcp/udp で長寿命セッションを特定
ルーター IPSec/GRE トンネルインターフェース障害
想定される原因
  • トンネルのソースインターフェースがダウンしてトンネル自体もダウン
  • トンネル宛先IPへのルートが存在しないか到達不可
  • GREキープアライブの失敗でトンネルがDown状態に遷移
  • 中間ネットワークがGREプロトコル(IP Protocol 47)をブロックしている
  • IPSecトンネルのSAが期限切れで再ネゴシエーションに失敗している
確認手順
  • show interface tunnel <n> でトンネルの状態とuptime、KeepAlive設定を確認
  • ping <tunnel_destination> source <tunnel_source> でアンダーレイ疎通を確認
  • show ip route <tunnel_destination> でトンネル宛先へのルートを確認
  • show crypto ipsec sa でIPSecのSA確立状態とパケットカウントを確認
  • debug tunnel でトンネルのパケット送受信をデバッグ(注: 本番での実施は要注意)
OSPF LSA Flapping(隣接関係断続的切断)
想定される原因
  • インターフェースの物理的な不安定
  • Hello/Dead intervalの設定不一致
  • MTU不一致によるDD(Database Description)パケットの分断
確認手順
  • show ip ospf neighbor で隣接関係の状態変化を確認
  • インターフェースのエラーカウントを確認
  • Hello/Dead intervalが一致しているか確認
  • show ip ospf interface でMTU設定を確認
ルーター IPv6/IPv4デュアルスタック設定障害
想定される原因
  • ルーターインターフェースのIPv6 RA(Router Advertisement)が無効
  • DHCPv6サーバーのプレフィックス委任(PD)プールが枯渇
  • IPv6のデフォルトゲートウェイがRAで広告されていない
  • FWがICMPv6(RA/RS/ND等)をブロックしている
確認手順
  • ルーターインターフェースでipv6 nd ra suppressが設定されていないか確認
  • radvdまたはDHCPv6のPDプールの残量を確認
  • クライアントでip6tables/nftablesがICMPv6をブロックしていないか確認
  • tcpdump icmp6 でRAパケットを確認
スパニングツリーループによるネットワークストーム
想定される原因
  • スパニングツリーが無効なスイッチの追加によるループ形成
  • BPDUガードが無効でエンドデバイスからBPDUを受信
  • STPトポロジー変更が頻発してMACアドレステーブルが揺らぎ
  • UplinkFastやBackboneFastが未設定で収束が遅い
確認手順
  • show spanning-tree でSTPのルートブリッジとポート状態を確認
  • show spanning-tree detail でトポロジー変更の頻度を確認
  • show interfaces counters でブロードキャスト数を確認
  • show mac address-table でMACアドレステーブルの揺らぎを確認
VLANミスマッチによるL2通信断
想定される原因
  • トランクポートのネイティブVLANが両端で不一致
  • アクセスポートに設定されたVLANがトランクの許可リストにない
  • dot1q/ISLカプセル化の設定ミス
  • VLANデータベースが他のスイッチと同期していない
確認手順
  • show interfaces trunk でトランク設定と許可VLANを確認
  • show interfaces <IF> switchport でアクセス/トランク設定を確認
  • CDP/LLDPのネイティブVLANミスマッチ警告を確認
  • show vlan brief でVLAN存在確認
MACアドレステーブル飽和によるフラッディング増大
想定される原因
  • MACアドレステーブル容量を超えるデバイスの接続
  • MACフラッディング攻撃(CAMテーブルオーバーフロー攻撃)
  • ループによるMACアドレスフラッピング
  • MACアドレスエージングタイムの設定ミス
確認手順
  • show mac address-table count でテーブル使用量を確認
  • show mac address-table でフラッピングしているMACを特定
  • show interfaces counters でフラッディングカウンタを確認
  • 物理ループの有無をSTPで確認
EtherChannelネゴシエーション失敗による帯域不足
想定される原因
  • 両端でLACP/PAgPモードが不一致(active/passiveの組み合わせ誤り)
  • メンバーポート間でスピード/デュプレックスが不一致
  • VLANやスパニングツリー設定がメンバーポート間で不一致
  • 片側でonly/static設定、もう片側でLACP設定
確認手順
  • show etherchannel summary でバンドル状態を確認
  • show lacp neighbor でLACPネゴシエーション状態を確認
  • show interfaces port-channel <n> でポートチャネルの状態を確認
  • 各メンバーポートの設定が一致しているか確認
PoE電力不足によるIPフォン・APの起動失敗
想定される原因
  • スイッチのPoE総予算を超えるデバイスの接続
  • ハイパワーPoE(802.3bt: 90W)対応APの大量接続
  • 電源ユニットの冗長性喪失による利用可能電力の低下
  • PoEプライオリティ設定なしで後から接続したデバイスに電力供給されない
確認手順
  • show power inline でPoE予算と消費電力を確認
  • show power inline <IF> detail で各ポートの消費電力を確認
  • スイッチの電源ユニット状態を確認
  • 接続デバイスのPoEクラス(消費電力)を確認
DHCPスヌーピング誤設定による正常DHCP応答ブロック
想定される原因
  • DHCPサーバーが接続されているポートをトラスト設定していない
  • アップリンクポート(トランク)がアントラスト設定になっている
  • DHCPサーバー移動後のトラスト設定更新漏れ
  • DHCPリレー経由の構成でアップリンクがアントラスト
確認手順
  • show ip dhcp snooping でDHCPスヌーピングの設定を確認
  • show ip dhcp snooping statistics でドロップ統計を確認
  • DHCPサーバー接続ポートのトラスト設定を確認
  • アップリンク/トランクポートのトラスト設定を確認
802.1X認証失敗によるネットワークアクセス拒否
想定される原因
  • RADIUSサーバーとの通信エラー(疎通断・シークレット不一致)
  • 端末の証明書が期限切れまたはドメイン離脱
  • RADIUSサーバー上のユーザー/コンピュータアカウントの問題
  • EAPメソッドの不一致(PEAP vs EAP-TLS等)
確認手順
  • show dot1x all でポートの認証状態を確認
  • show radius statistics でRADIUSの成功/失敗数を確認
  • RADIUSサーバーへの疎通確認(ping/telnet 1812)
  • RADIUSサーバーのログで拒否理由を確認
スイッチスタック分割によるマスター/メンバー間通信断
想定される原因
  • スタックケーブルの断線または劣化
  • スタックメンバースイッチの再起動/障害
  • スタックリングの片方向断
  • スタックソフトウェアバージョンの不一致
確認手順
  • show switch でスタックメンバーの状態を確認
  • show switch stack-ports でスタックポートの状態を確認
  • スタックケーブルの物理接続を確認
  • show version でソフトウェアバージョンが一致しているか確認
ジャンボフレーム非対応によるiSCSI/NFS通信障害
想定される原因
  • ストレージネットワーク(iSCSI/NFS)向けVLANでジャンボフレームが未設定
  • 経路上の一部スイッチのみジャンボフレーム対応でボトルネック
  • サーバーNICのMTUとスイッチのMTUが不一致
  • アップリンクポートのMTUが未設定
確認手順
  • show interfaces <IF> でMTU設定を確認
  • show system mtu でシステムグローバルのMTU設定を確認
  • ping <dst> size 8972 df でジャンボフレーム疎通を確認
  • 全経路スイッチのMTU設定を確認
スイッチ CPU 過負荷による管理・通信不安定
想定される原因
  • TCPSyN Flood・ARP Floodなどのネットワーク攻撃によりコントロールプレーンに大量パケットがPunt
  • TCAMテーブル(ルーティング/ACL/MAC)がハードウェア上限を超えてソフトウェア転送に切り替わり
  • STP BPDUやOSPF/BGPのルーティングアップデートが大量発生してCPUを圧迫
  • SNMPポーリングが高頻度でCPUに負荷をかけている
  • マルウェア感染したホストがブロードキャストストームを起こしてCPUを過負荷
確認手順
  • show processes cpu sorted でCPUを消費しているプロセスを確認
  • show platform tcam utilization でTCAM使用率を確認
  • show interfaces | include input rate でトラフィック量の異常を確認
  • show control-plane host open-ports でコントロールプレーンへのアクセスを確認
  • show spanning-tree detail でSTPのトポロジ変化が頻発していないか確認
MACアドレステーブルフラッピング(ループ/重複MAC)
想定される原因
  • ネットワークループでフレームが複数のポートから届く
  • STPが無効なポートに冗長リンクが接続
  • NICボンディングの設定ミスで同一MACが複数ポートから見える
確認手順
  • syslogでMACフラッピングの発生ポートを特定
  • show spanning-tree でSTPトポロジーを確認
  • フラッピング発生ポートのリンク状態を確認
スイッチ 802.1Q QinQ(二重タグ)設定障害
想定される原因
  • エグレスポートでOuterタグ(S-VLAN)が剥がされずに二重タグのままクライアントに届く
  • トランクポートのethertype設定が0x8100と0x88A8で不一致
  • Inner VLAN(C-VLAN)が許可されていないポートに届く
  • インターフェースのQinQモード設定が誤っている
確認手順
  • スイッチのインターフェース設定でQinQモードを確認
  • エグレスポートのVLAN設定でOuterタグの除去設定を確認
  • Ethertypeの設定(0x8100/0x88A8)を確認
  • wiresharkでフレームの二重タグを確認
DNSサーバー応答なしによる名前解決全断
想定される原因
  • DNSサーバーのサービス停止またはリソース枯渇
  • DNSサーバーへのファイアウォールポリシーでUDP/TCP 53がブロック
  • 再帰クエリの権限設定(allow-recursion)でクライアントからの問い合わせが拒否
  • フォワーダーとして設定した上位DNSサーバーが停止
確認手順
  • dig @<DNS-IP> google.com でDNSサーバーへの直接問い合わせ確認
  • systemctl status named/bind9 でサービス状態を確認
  • named-checkconf /etc/named.conf で設定ファイルの文法確認
  • ファイアウォールのポート53(UDP/TCP)開放状況を確認
DNSゾーンファイル設定ミスによる特定ドメインの解決失敗
想定される原因
  • Aレコード/CNAMEレコードの入力ミス
  • ゾーンファイルのSOAシリアル番号が更新されていない
  • CNAMEがMXやNSレコードを指している(不正設定)
  • ゾーンファイルのピリオド(終端ドット)付け忘れ
確認手順
  • named-checkzone <zone> <zonefile> でゾーンファイルを検証
  • dig <hostname> でレコードの存在を確認
  • ゾーンファイルのSOAシリアル番号が増加しているか確認
  • CNAME/MXレコードの指定先が正しいか確認
DNSキャッシュポイズニング・スプーフィング攻撃
想定される原因
  • DNSSEC未設定でキャッシュポイズニング攻撃に脆弱
  • DNSソースポートのランダム化が無効
  • 攻撃者が偽造DNS応答を送り込んでいる
  • オープンリゾルバとして悪用されている
確認手順
  • DNSSEC設定の有無を確認
  • dig +dnssec <domain> でDNSSEC署名を確認
  • named.conf でallow-queryとallow-recursion設定を確認
  • ログで不審なDNSクエリパターンを確認
内部DNSの分離(Split DNS)設定ミスによる内部リソースアクセス失敗
想定される原因
  • DNSビュー(view)のACLにクライアントIPが含まれていない
  • 内部ゾーンを外部ビューにも設定してしまっている
  • クライアントの/etc/resolv.confに内部DNSが設定されていない
  • VPN接続時にDNS設定が内部に切り替わっていない
確認手順
  • named.conf のview設定とACLを確認
  • dig @<internal-DNS> <hostname> で内部DNSへの直接問い合わせ
  • クライアントの/etc/resolv.conf(またはnslookup server)を確認
  • VPN接続時のDNS割り当て設定を確認
逆引きDNS(PTRレコード)未設定によるメール配信失敗
想定される原因
  • メールサーバーのIPアドレスにPTRレコードが設定されていない
  • ISPが逆引きDNSの管理権限を保持しており自社設定不可
  • PTRレコードが設定されているが受信側の逆引きと不一致
  • in-addr.arpaゾーンの設定ミス
確認手順
  • dig -x <IP> で逆引きDNSを確認
  • nslookup <IP> で逆引き名前解決を確認
  • in-addr.arpaゾーンファイルのPTRレコードを確認
  • ISPのIPアドレス管理画面で逆引き設定を確認
高負荷によるDNSクエリタイムアウト
想定される原因
  • DNSアンプ攻撃(DDoS)によるサーバー過負荷
  • 大量のクエリによるキャッシュヒット率の低下
  • フォワーダーへの応答待ちによる遅延
  • ハードウェアリソース(CPU/メモリ)の不足
確認手順
  • rndc stats でDNSクエリ統計を確認
  • named-xfer や named の CPU/メモリ使用率を確認
  • top クエリとクエリ元IPを確認
  • ネットワークのトラフィック量を確認(DDoS判定)
DNSゾーン転送失敗によるセカンダリサーバーの情報不同期
想定される原因
  • プライマリDNSのallow-transfer設定でセカンダリが許可されていない
  • ファイアウォールでTCP 53がブロック(AXFR用)
  • SOAシリアル番号の更新漏れでセカンダリが転送を開始しない
  • TSIG認証キーの不一致
確認手順
  • dig AXFR <zone> @<primary-DNS> でゾーン転送テスト
  • named.conf のallow-transfer設定を確認
  • ファイアウォールのTCP 53開放状況を確認
  • TSIG認証キーが両サーバーで一致しているか確認
TTL設定が長すぎるキャッシュによる移行後も古いIPへのアクセス
想定される原因
  • レコードのTTLが長すぎてキャッシュが長期間残る
  • DNSレコード変更前のTTL短縮作業を実施しなかった
  • ネガティブキャッシュ(NXDOMAIN)のTTLが長い
  • クライアントやアプリがDNSキャッシュを独自に持つ
確認手順
  • dig <domain> でTTL値を確認
  • dig +trace <domain> で権威DNSの応答を確認
  • クライアントのDNSキャッシュをクリアして再確認(ipconfig /flushdns)
  • 全世界のDNS伝播状況を確認
DNSSEC 検証エラーによる名前解決失敗
想定される原因
  • ゾーンの署名鍵(ZSK/KSK)の有効期限が切れてRRSIGが無効になっている
  • 鍵ロールオーバー時に親ゾーンのDSレコードが更新されず委任が断絶
  • リゾルバーのトラストアンカーが古くなっている(ルートゾーンのKSK更新未追従)
  • DNSSECが有効なゾーンに対してNSECウォークを悪用した攻撃でSERVFAILが発生
  • ゾーン転送でDNSSECレコード(RRSIG/NSEC等)が正しく転送されていない
確認手順
  • dig +dnssec +cd <domain> A でDNSSEC検証をバイパスして名前解決できるか確認
  • dig +dnssec <domain> A @8.8.8.8 でパブリックリゾルバーでの検証結果を確認
  • dnsviz.net でDNSSECチェーンの可視化と問題箇所を特定
  • dig DS <domain> @<parent-ns> で親ゾーンのDSレコードを確認
  • dig DNSKEY <domain> で現在の公開鍵を取得してDSレコードと一致するか確認
DNS over HTTPS(DoH)/ DNS over TLS(DoT)接続失敗
想定される原因
  • ファイアウォールがDoT用ポート853またはDoH用443をブロックしている
  • DoTサーバーの証明書が信頼されていないまたは期限切れ
  • クライアントがDoH/DoTを使おうとしているが組織のプロキシがDNSをインターセプト
  • Firefoxのカナリードメイン(use-application-dns.net)がNXDOMAINを返しDoHを無効化
  • 暗号化DNSがセキュリティポリシーで禁止されておりFirewallがブロック
確認手順
  • curl -H 'accept: application/dns-json' 'https://1.1.1.1/dns-query?name=example.com' でDoHの疎通確認
  • openssl s_client -connect 1.1.1.1:853 でDoTのTLSハンドシェイクを確認
  • ファイアウォールでポート853(TCP/UDP)と443(DNS用)のログを確認
  • Firefoxのabout:networkingでDoHの設定と状態を確認
  • dig use-application-dns.net @<resolver> でカナリードメインのNXDOMAIN設定を確認
DNS Split-Horizon設定ミスによる名前解決障害
想定される原因
  • BINDのviewの順序が誤っていて内部クライアントが外部viewで処理
  • ACLの重複や誤設定
  • 内外viewで同じゾーンが矛盾した設定
確認手順
  • named-checkconf でBIND設定の構文確認
  • dig @<internal-dns> でDNS応答を確認
  • viewの順序とACL設定を確認
DNS応答パケット過大(EDNS0/UDP断片化)によるタイムアウト
想定される原因
  • DNSSEC有効時の大きな応答がUDPの1500バイト制限を超過して断片化
  • ファイアウォールがUDP断片化パケットをブロック
  • EDNS0バッファサイズが大きすぎる設定
確認手順
  • dig +bufsize=512 でEDNS0バッファサイズを制限してテスト
  • dig +tcp でTCP強制クエリが成功するか確認(断片化の問題か切り分け)
  • ファイアウォールのICMP Fragmentation Needed(Type 3 Code 4)の扱いを確認
DNS 権威サーバーのゾーン転送(AXFR/IXFR)失敗
想定される原因
  • 権威サーバーのallow-transfer設定にセカンダリDNSのIPが含まれていない
  • NSGやFWがTCPポート53をブロック(ゾーン転送はTCP必須)
  • シリアル番号が不正でIXFRが失敗してAXFRフォールバックも失敗
  • TSIGキーの設定不一致
確認手順
  • dig AXFR @<primary-ns> <zone> でゾーン転送を手動テスト
  • named.confのallow-transfer設定を確認
  • FWでTCP/53が許可されているか確認
  • TSIGキーの設定を両サーバーで確認
DHCPスコープ枯渇による新規クライアントのIPアドレス取得失敗
想定される原因
  • スコープのIPアドレス数に対してクライアントが過多
  • リースタイムが長すぎて解放されないアドレスが蓄積
  • 不正なDHCPクライアントがIPを消費している
  • 静的IPとDHCPスコープが重複して競合
確認手順
  • show ip dhcp pool でスコープの空き状況を確認
  • show ip dhcp binding でリース中のMACアドレスを確認
  • リース中のアドレスが実際に使用されているか(ping確認)
  • スコープの除外アドレス設定を確認
DHCPリレーエージェント設定ミスによるサブネット間のIPアドレス取得失敗
想定される原因
  • ルーターのインターフェースにip helper-addressが未設定
  • ip helper-addressが間違ったDHCPサーバーIPを指している
  • ファイアウォールでUDP 67/68がブロックされている
  • DHCPサーバーのスコープにgiaddorサブネットの設定がない
確認手順
  • show running-config interface でip helper-address設定を確認
  • DHCPサーバーのログでリレーパケットを受信しているか確認
  • ping <DHCP-server> でリレーエージェントからDHCPサーバーへの疎通確認
  • DHCPサーバーにクライアントのサブネットに対応するスコープがあるか確認
不正DHCPサーバー(Rogue DHCP)による誤ったIPアドレス配布
想定される原因
  • PC等にDHCPサーバーソフトが誤ってインストール・起動された
  • ルーターやAPのデフォルト設定でDHCPが有効のまま接続
  • VMのネットワーク設定でホストのDHCPサーバーが露出
  • 意図的な攻撃(DHCPスプーフィング)
確認手順
  • スイッチのDHCPスヌーピングログで不正DHCPサーバーのポートを特定
  • show ip dhcp snooping binding で不正なバインディングを確認
  • nmap -sU -p 67 <subnet> で不正DHCPサーバーを探索
  • クライアントに配布されているゲートウェイ/DNS設定を確認
DHCPリーステーブル破損による再起動後の重複アドレス配布
想定される原因
  • DHCPサーバーの異常停止でリースDBが保存されずに起動
  • 静的IPと重複するアドレスをDHCPが配布
  • スコープから静的IP除外(excluded-address)が未設定
  • DHCPデータベースファイルの破損
確認手順
  • show ip dhcp conflict でコンフリクトアドレスを確認
  • ip dhcp conflict logging が有効か確認
  • 問題アドレスのARP応答元を確認(arp -a)
  • 静的IPとDHCPスコープの重複を確認
DHCPオプション設定ミスによるDNS/ゲートウェイ配布エラー
想定される原因
  • DHCPオプション3(デフォルトゲートウェイ)の設定値ミス
  • DHCPオプション6(DNSサーバー)の設定値が古い
  • サブネットマスクのオプション1の設定ミス
  • スコープオプションとサーバーオプションの優先順位の誤解
確認手順
  • show ip dhcp pool でオプション設定を確認
  • dhcp offer パケットをWiresharkでキャプチャして配布値を確認
  • クライアントが受け取ったDHCP設定を確認(ipconfig /all)
  • 各スコープのオプション設定を確認
Windows DHCPサーバーの承認失敗によるサービス停止
想定される原因
  • ActiveDirectoryへのDHCPサーバー登録が行われていない
  • ドメイン参加状態の変化によって承認が失効
  • DCとの通信断により承認確認ができない
  • DHCP管理者権限のないアカウントでサービスが動作
確認手順
  • DHCPコンソールまたはGetDhcpServerDnsName でサーバーの承認状態を確認
  • イベントビューアーでDHCPサービスログを確認
  • ADとの通信確認(nltest /sc_query:<domain>)
  • dhcp-server-ipaddress.adatum.com のSRVレコードを確認
DHCPフェイルオーバー設定ミスによるスプリットブレイン
想定される原因
  • フェイルオーバーピアとの通信断によるスプリットブレイン
  • フェイルオーバー設定のポートまたはシークレットが不一致
  • タイムゾーン/時刻不同期によるリース計算の誤り
  • フェイルオーバー比率の誤設定
確認手順
  • show ip dhcp failover でフェイルオーバー状態を確認
  • フェイルオーバーポート(647)の疎通確認
  • 両サーバーの時刻同期確認(NTPが一致しているか)
  • フェイルオーバー設定のシークレットを確認
DHCP Snooping 設定によるクライアントのアドレス取得ブロック
想定される原因
  • アップリンクポートがDHCP Snooping の trusted に設定されておらず、DHCPサーバーからのOFFERが破棄されている
  • DHCPリレーエージェント経由の構成でリレーインターフェースがuntrustedのまま
  • DHCP Snoopingバインディングテーブルが上限に達して新規バインドができない
  • Dynamic ARP Inspection(DAI)がSnoopingバインディングと不一致のARPを破棄
  • VLAN間でSnooping設定が漏れており特定VLANのみ問題が発生
確認手順
  • show ip dhcp snooping でSnoopingが有効なVLANとtrustedポートを確認
  • show ip dhcp snooping binding でバインディングテーブルとエントリ数を確認
  • show ip dhcp snooping statistics でドロップ数とドロップ理由を確認
  • show ip arp inspection でDAI設定との連携を確認
  • スイッチのsyslogでDHCP_SNOOPINGエラーメッセージを確認
DHCP Discover に応答なし(unicast/relay 経路問題)
想定される原因
  • ip helper-addressがDHCPサーバーのアドレスを誤って指定しているか未設定
  • DHCPサーバーとルーター間のUDP 67/68ポートがACLでブロックされている
  • giaddr(Gateway IP Address)に対応するスコープがDHCPサーバーに存在しない
  • DHCPサーバー自体がダウンまたはサービスが停止している
  • 複数VLANのリレー先でサーバーが特定VLANのブロードキャストを処理できない
確認手順
  • show ip interface <if> でip helper-addressの設定を確認
  • debug ip dhcp server events でサーバーがDiscoverを受信しているか確認
  • ping <DHCPサーバーIP> でルーターからサーバーへの疎通を確認
  • show ip dhcp server statistics でDiscoverとOfferの件数を確認
  • ACLでUDP 67/68が許可されているか show access-lists で確認
DHCPリースデータベース破損・サービス障害
想定される原因
  • サーバーの異常シャットダウンによるリースファイルの破損
  • ディスク容量不足でリースファイルへの書き込みが途中で停止
  • Windows DHCPサーバーのJetDBデータベースの整合性エラー
  • DHCPフェイルオーバーパートナーとの同期失敗
確認手順
  • DHCPサービスのログでエラーメッセージを確認
  • リースファイル(/var/lib/dhcpd/dhcpd.leases)の構文チェック
  • ディスク容量(df -h)でリースファイル保存先の空き容量を確認
  • Windows: netsh dhcp server show database でデータベース状態を確認
DHCP Option 82(リレーエージェント情報)による払い出し失敗
想定される原因
  • DHCPサーバーがOption 82を無視する設定
  • スイッチが追加したOption 82をサーバーが不正と判断して拒否
  • DHCPスヌーピングとリレーのOption 82設定の競合
確認手順
  • DHCPサーバーのログでOption 82付きパケットへの応答を確認
  • サーバーのOption 82処理方法(ignore/append/replace)を確認
  • wiresharkでDHCPパケットのOption 82フィールドを確認
DHCPv4 GIADDRエラーによるリレー越しの払い出し失敗
想定される原因
  • DHCPリレーのGIADDR(Gateway IP Address)が0.0.0.0のまま送信されている
  • 複数のリレー経由でGIADDRが途中で上書きされて誤ったスコープが選択される
  • リレーエージェントの設定でip helper-addressが誤ったインターフェースに設定
  • サーバーがGIADDRのサブネットに対応するスコープを持っていない
確認手順
  • DHCPサーバーへ届くパケットのGIADDRフィールドを確認
  • ルーター/スイッチのip helper-addressの設定を確認
  • DHCPサーバーのスコープにGIADDRのサブネットが含まれているか確認
  • 複数ルーター経由の場合、各ルーターのリレー設定を確認
IPSec フェーズ1(IKE)ネゴシエーション失敗
想定される原因
  • 暗号化アルゴリズム(AES/3DES)の不一致
  • 認証方式(Pre-Shared Key/証明書)の不一致
  • DHグループ(Diffie-Hellman)の不一致
  • Pre-Shared Keyが両端で異なる
確認手順
  • debug crypto isakmp でIKEネゴシエーションの詳細を確認
  • show crypto isakmp sa でISAKMP SAの状態を確認
  • 両端のIKEポリシー(crypto isakmp policy)を比較
  • Pre-Shared Keyが両端で一致しているか確認
IPSec フェーズ2(IPSec SA)ネゴシエーション失敗
想定される原因
  • トランスフォームセット(ESP暗号化・認証アルゴリズム)の不一致
  • Proxy ID(保護するトラフィックの送信元・宛先サブネット)の不一致
  • PFSグループの不一致
  • ACL(crypto map用)の設定ミスでトラフィックを正しく選択できない
確認手順
  • debug crypto ipsec でIPSec SAネゴシエーションの詳細を確認
  • show crypto ipsec sa でSAのカウンタを確認
  • 両端のtransform-setを比較
  • crypto map ACLの送信元・宛先サブネットを確認
SSL-VPN証明書期限切れによる接続不可
想定される原因
  • SSL-VPNゲートウェイのサーバー証明書が期限切れ
  • 証明書の自動更新が失敗していた
  • クライアントの時刻がずれていて有効期限判定が誤る
  • 中間CA証明書のチェーンが切れている
確認手順
  • show ssl certificate でSSL証明書の有効期限を確認
  • openssl s_client -connect <VPN-host>:443 で証明書情報を確認
  • 証明書の自動更新ログを確認
  • クライアントの時刻設定を確認
VPNスプリットトンネリング設定によるアクセス問題
想定される原因
  • スプリットトンネルACLに必要なサブネットが含まれていない
  • フルトンネルが必要な環境でスプリットトンネルが設定されている
  • クライアントが受け取るルートが不正確
  • VPN経由でアクセスすべきリソースがローカルルートと競合
確認手順
  • VPN接続中のクライアントのルーティングテーブルを確認(route print)
  • スプリットトンネルACLの内容を確認
  • VPN経由でアクセスしたいリソースのサブネットがACLに含まれているか確認
  • クライアントに配布されるルートを確認
IPSec NAT-T(NAT Traversal)問題によるNAT越えVPN障害
想定される原因
  • 中間NATデバイスがESPパケット(プロトコル50)を通過できない
  • NAT-TのUDP 4500ポートがファイアウォールでブロック
  • 一方のVPNゲートウェイがNAT-T非対応
  • NATデバイスのIPSec ALGが誤動作
確認手順
  • show crypto isakmp sa detail でNAT-Tの使用状況を確認
  • UDP 4500の疎通確認
  • 中間NATデバイスのIPSec ALG設定を確認
  • 両端でNAT-Tが有効になっているか確認
VPNユーザー認証失敗(RADIUS/LDAP連携エラー)
想定される原因
  • RADIUSサーバーの設定変更(シークレット変更等)
  • LDAPのバインドDNまたはパスワードが変更された
  • ユーザーアカウントのロックアウトまたは無効化
  • MFA(多要素認証)設定の問題
確認手順
  • RADIUSサーバーのアクセスログで拒否理由を確認
  • test aaa group <group> <user> <pass> でAAA認証テスト
  • LDAPサーバーへの疎通確認(ldapsearch コマンド)
  • ユーザーアカウントの状態(ロック/有効/パスワード期限)を確認
OpenVPN TLSハンドシェイク失敗
想定される原因
  • クライアント証明書またはCA証明書の期限切れ
  • tls-auth/tls-cryptの共通鍵(ta.key)が両端で異なる
  • 証明書のサブジェクト名(CN)が検証条件と不一致
  • OpenVPNのTLSバージョン不一致
確認手順
  • openssl verify -CAfile ca.crt client.crt でクライアント証明書を検証
  • openssl x509 -in server.crt -noout -dates で有効期限を確認
  • ta.keyが両端で同一のファイルか確認
  • openvpn --verb 6 で詳細ログを確認
VPNトンネルのDPD(Dead Peer Detection)タイムアウトによる頻繁な再接続
想定される原因
  • インターネット回線の一時的な品質低下でDPDパケットが届かない
  • DPDのタイムアウト値が短すぎる
  • 非対称ルーティングでDPD応答が届かない
  • 中間NATデバイスがIDLEセッションを早期に破棄
確認手順
  • show crypto isakmp sa でDPD関連のSA状態を確認
  • ping <peer-IP> でICMPの疎通を確認
  • DPDのタイムアウト設定を確認
  • NATデバイスのセッションタイムアウトと比較
SD-WANオーバーレイトンネル品質低下による通話・ビデオ品質劣化
想定される原因
  • アンダーレイ回線(ISP)の品質低下
  • BFDセッションのタイムアウト設定が厳しすぎてフラッピング
  • 帯域幅ポリシーが音声/ビデオトラフィックに対して不適切
  • パス選択ポリシーがリアルタイムトラフィックを最適経路に転送しない
確認手順
  • SD-WANコントローラーのトンネル品質メトリクスを確認
  • 各アンダーレイ回線のパフォーマンステストを実施
  • BFD設定のタイムアウト値を確認
  • アプリケーションポリシーのパス選択設定を確認
VPN 大量ユーザー接続時のパフォーマンス劣化
想定される原因
  • VPNゲートウェイのセッション数上限(ライセンス・ハードウェア制限)に到達
  • TLS暗号化処理がCPUに集中してアクセラレータ(AES-NI等)が未活用
  • VPNゲートウェイのアップリンク帯域が総ユーザー使用量に対して不足
  • スプリットトンネリングが無効で全トラフィックがVPN経由になり帯域を圧迫
  • UDP 4500(NAT-T)のQoS設定がなく音声・映像通話が遅延する
確認手順
  • show vpn-sessiondb summary でアクティブセッション数と上限を確認
  • show cpu usage でVPNプロセスのCPU消費率を確認
  • show interface <外部NIC> でインバウンド/アウトバウンドの帯域使用量を確認
  • show vpn-sessiondb detail でユーザーごとの帯域使用量を確認
  • VPNゲートウェイのライセンス(最大セッション数・帯域)を確認
IPsec IKEv2 EAP/RADIUS認証障害
想定される原因
  • RADIUSでのユーザー名/パスワード不一致
  • サーバー証明書のSANが接続先ホスト名と不一致
  • RADIUS共有シークレット不一致
確認手順
  • RADIUSログでAccess-Accept/Rejectを確認
  • IKEv2デバッグログでEAP exchangeを確認
  • RADIUS共有シークレットが正しいか確認
SSL-VPN(OpenVPN/GlobalProtect)証明書検証エラー
想定される原因
  • VPNサーバー証明書の有効期限切れまたは信頼されていないCAで署名
  • CRL(証明書失効リスト)の有効期限切れで全クライアントの接続失敗
  • OCSPレスポンダーに到達できずクライアントが接続を拒否
  • 中間CA証明書がチェーンに含まれておらずルートCAへの信頼が確立できない
確認手順
  • VPNサーバー証明書の有効期限を確認(openssl x509 -in cert.pem -noout -dates)
  • CRLの有効期限とCRL配布ポイントへのアクセスを確認
  • OCSPレスポンダーのURLと到達性を確認
  • 証明書チェーンが完全か確認(ルートCA→中間CA→サーバー証明書)
バックエンドサーバーのヘルスチェック失敗による503エラー
想定される原因
  • バックエンドアプリケーションのクラッシュまたは停止
  • ヘルスチェックパス(/health等)がアプリ変更で無効になった
  • ヘルスチェックのタイムアウト設定が短すぎる
  • サーバーリソース枯渇(CPU/メモリ)でヘルスチェックに応答できない
確認手順
  • show ltm pool <name> でプールメンバーの状態を確認(F5)
  • curl <backend-IP>:<port>/health でヘルスチェックエンドポイントを直接確認
  • バックエンドサーバーのログでエラーを確認
  • ヘルスモニターの設定(チェックパス・タイムアウト・間隔)を確認
SSLオフロード設定ミスによるHTTP/HTTPS通信エラー
想定される原因
  • X-Forwarded-ProtoヘッダーがバックエンドへのHTTPリクエストに付与されていない
  • バックエンドアプリがHTTPSリクエストを受け取っても再度HTTPSリダイレクトしてループ
  • SSL証明書の中間CA証明書チェーンが不完全
  • クライアント証明書認証(mTLS)の設定ミス
確認手順
  • curl -v でレスポンスヘッダーを確認
  • バックエンドに到達するリクエストのヘッダーを確認
  • openssl s_client で証明書チェーンを確認
  • バックエンドのアクセスログでHTTP/HTTPSを確認
セッション持続性(Persistence/Sticky Session)設定ミス
想定される原因
  • セッション持続性が設定されていないためリクエストが別サーバーに振られる
  • Cookieベースの持続性でCookie名が誤っている
  • 持続性レコードのタイムアウトがセッションより短い
  • NATやプロキシによって送信元IPが変化してIP持続性が機能しない
確認手順
  • show ltm persistence <pool> で持続性の状態を確認
  • アプリのセッションストレージが共有(Redis等)か確認
  • 持続性のタイムアウト設定をセッション有効期間と比較
  • ロードバランサーのアクセスログで同一クライアントの分散先を確認
同時接続数上限によるコネクション拒否
想定される原因
  • バックエンドの処理能力を超えるトラフィックの流入
  • 接続タイムアウトが長すぎてゾンビ接続が蓄積
  • ロードバランサーのコネクション数ライセンス上限
  • サーバーダウンによってトラフィックが残存サーバーに集中
確認手順
  • show ltm virtual <name> でコネクション統計を確認
  • tmsh show /ltm pool <pool> でプールの接続状況を確認
  • バックエンドサーバーのCPU/メモリを確認
  • コネクション数の時系列グラフで急増タイミングを確認
HAProxy ACL設定ミスによる意図しないルーティング
想定される原因
  • ACLのpath_begやhdr(host)の条件が実際のリクエストと一致しない
  • use_backendルールの順序が意図と異なる
  • 大文字/小文字の不一致(-i オプション未使用)
  • 正規表現パターンのエスケープミス
確認手順
  • haproxy -c -f /etc/haproxy/haproxy.cfg で設定ファイルを検証
  • echo 'show info' | socat stdio /var/run/haproxy.sock でランタイム情報確認
  • curl -H 'Host: <host>' <LB-IP>/<path> でルーティングを確認
  • haproxyログのログレベルをdebugに上げてACLマッチ状況を確認
F5 iRule設定ミスによるトラフィック処理エラー
想定される原因
  • iRuleのTCLコードのシンタックスエラー
  • 存在しない変数や関数の参照
  • iRuleが想定外のトラフィックパターンで実行される
  • iRuleの無限ループまたは過大な処理によるCPU負荷
確認手順
  • tmsh list ltm rule <name> でiRuleのコードを確認
  • /var/log/ltm でiRule関連のエラーを確認
  • iRule Editor でTCLの構文チェック
  • virtual serverのiRule割り当てを確認
ロードバランサーのTCP/HTTPプロファイル設定不足による接続タイムアウト
想定される原因
  • バックエンドのレスポンスタイムアウトがロードバランサーの設定より長い
  • IDLEタイムアウトが短すぎてKeepAlive接続が切断される
  • 長時間処理するAPIリクエストのタイムアウト設定
  • WebSocketなど長時間接続が必要なプロトコルのタイムアウト
確認手順
  • プロファイルのタイムアウト設定を確認
  • バックエンドの実際の処理時間を計測
  • クライアントの接続エラーログとタイムアウト値を確認
  • WebSocket等の長時間接続プロトコルの使用有無を確認
nginxアップストリーム設定ミスによる502 Bad Gateway
想定される原因
  • バックエンドサービスが停止しているまたはポートが変更された
  • proxy_passのURLが正しくない
  • バックエンドのファイアウォールがnginxからの接続をブロック
  • バックエンドの応答が遅くupstream_read_timeoutを超過
確認手順
  • nginx -t で設定ファイルの文法チェック
  • curl <upstream-IP>:<port> でバックエンドへの直接アクセスを確認
  • nginx error.logのupstream関連エラーを確認
  • ss -tlnp でバックエンドのリスニングポートを確認
ロードバランサーのグレースフルシャットダウン失敗による接続断
想定される原因
  • コネクションドレイン(排出)タイムアウトが短すぎて処理中のリクエストが完了前に切断
  • ゼロダウンタイムデプロイ時にnginxのreload信号後にアップストリームが即座に切れる
  • ロードバランサーのバックエンド削除時にDrainingモードを経由せず直接削除
  • WebSocketや長時間接続のセッションがドレインタイムアウト内に終了しない
  • バックエンドサーバー側がFINを受け取る前にプロセスを強制終了(SIGKILL)している
確認手順
  • ロードバランサーのアクセスログで接続断のタイムスタンプとリクエスト状態を確認
  • バックエンドのアプリログでSIGTERM受信後の処理完了状況を確認
  • ロードバランサーのコネクションドレイン設定(タイムアウト値)を確認
  • netstat -an | grep CLOSE_WAIT でドレイン中の残存セッションを確認
  • ロードバランサーのBackendのステータス遷移(Active→Draining→Out of Service)を確認
ロードバランサー TLS 1.0/1.1 非推奨によるクライアント接続失敗
想定される原因
  • ロードバランサーのTLS最低バージョンをTLS 1.2に設定したがクライアントがTLS 1.0/1.1のみ対応
  • クライアント(古いブラウザ・レガシーシステム)がTLS 1.2以降の暗号スイートをサポートしていない
  • ロードバランサーで特定の暗号スイートのみ許可しているがクライアントと共通のスイートがない
  • Java/Python等のクライアントライブラリが古くTLS 1.2のデフォルト有効化が必要
  • OSレベルでTLS 1.0/1.1を無効化しているがアプリがシステムデフォルトを使わず古い設定を持つ
確認手順
  • openssl s_client -connect <lb>:443 -tls1 でTLS 1.0接続が拒否されるか確認
  • openssl s_client -connect <lb>:443 -tls1_2 でTLS 1.2接続が成功するか確認
  • ロードバランサーの許可TLSバージョンと暗号スイート設定を確認
  • クライアントのSSLライブラリバージョンとサポートTLSバージョンを確認
  • Wireshark/ssldump でClientHelloのTLSバージョンフィールドを確認
SSLオフロード後のHTTPSリダイレクトループ
想定される原因
  • LBがSSLを終端してHTTPで転送するがバックエンドがHTTPS強制リダイレクト
  • X-Forwarded-Protoヘッダーを確認せずにリダイレクト
確認手順
  • LBの転送プロトコル設定を確認
  • バックエンドのHTTPSリダイレクト設定を確認
  • X-Forwarded-Protoヘッダーの転送を確認
ロードバランサー バックエンドサーバーのドレイン中断によるアクティブセッション切断
想定される原因
  • ドレインタイムアウトがアクティブセッションの期間より短い
  • WebSocket/SSEなど長時間接続がドレイン中に切断される
  • ドレイン設定が無効(Connection Draining disabled)
  • ヘルスチェックが異常を検知する前に手動でサーバーを除外した
確認手順
  • LBのConnection Draining設定とタイムアウト値を確認
  • アクティブセッションの平均/最大継続時間を確認
  • メンテナンス時の接続切断がエラーログに記録されていないか確認
  • ドレイン中のアクティブ接続数をモニタリング
Squidプロキシのアクセスリスト設定によるサイトブロック
想定される原因
  • ACLのdstdomain/dstip設定でブロック対象に意図しないサイトが含まれている
  • 新しいSaaSサービスのドメインがブロックリストに含まれている
  • URLフィルタリングカテゴリの誤分類
  • アクセスリストのルール順序が意図と異なる
確認手順
  • squid access.log で該当リクエストのACL名を確認
  • squid -k parse で設定ファイルを検証
  • 該当URLが含まれるACLを確認
  • cat /etc/squid/squid.conf でACLルールを確認
プロキシのSSL BUMP(SSL インスペクション)による接続失敗
想定される原因
  • Squidが生成する偽造証明書のCA証明書がブラウザに信頼されていない
  • 証明書ピンニング(HPKP)を使用するサービスへのSSL BUMP
  • TLS 1.3やECDH鍵交換の非対応によるSSL BUMP失敗
  • Squidの中間CA証明書の有効期限切れ
確認手順
  • squid access.log でSSL_CONNECT_FAILのURLを確認
  • Squidの中間CA証明書の有効期限を確認
  • ブラウザに中間CA証明書が配布されているか確認
  • Certificate Pinningサービスのリストを確認
プロキシのキャッシュ汚染(Stale Cache)による古いコンテンツ配信
想定される原因
  • キャッシュのmax-age/TTLが長すぎる
  • アプリがCache-Control: no-storeを付けていない
  • 条件付きリクエスト(ETag/If-Modified-Since)が正しく処理されない
  • 動的コンテンツが誤ってキャッシュされている
確認手順
  • squid access.log でTCP_HIT/TCP_MISS比率を確認
  • 問題URLのキャッシュエントリを確認(squid -k debug)
  • アプリのHTTPレスポンスヘッダーでCache-Control確認
  • 問題のキャッシュオブジェクトの保存期間を確認
プロキシ認証設定によるアプリケーション接続失敗
想定される原因
  • アプリケーションがプロキシ認証に対応していない(Java, Python等のライブラリ)
  • KerberosチケットのSPN(Service Principal Name)設定ミス
  • NTLMのネゴシエーションがロードバランサー経由で破壊される
  • サービスアカウントのパスワード変更後の認証設定更新漏れ
確認手順
  • curl -x http://<user>:<pass>@<proxy>:<port>/ <url> で手動認証テスト
  • Wiresharkで407とNTLM/Kerberos交換をキャプチャ
  • アプリの環境変数(HTTP_PROXY/HTTPS_PROXY)を確認
  • SPNの登録状況(setspn -L <account>)を確認
プロキシの同時接続数・ファイルディスクリプタ不足
想定される原因
  • OS側のulimit(ファイルディスクリプタ上限)が低い
  • Squid/プロキシの設定でmax_fdが不足
  • クライアントの急激な増加
  • Keepalive接続の蓄積でFDが解放されない
確認手順
  • ulimit -n でFD上限を確認
  • squid -N -d5 でデバッグモードで起動してFD状況確認
  • lsof -p <squid-pid> | wc -l で使用中FD数を確認
  • netstat -an | grep <proxy-port> でコネクション状態を確認
PAC(Proxy Auto-Config)ファイルの誤設定によるプロキシ未適用
想定される原因
  • PACファイルのJavaScript構文エラー
  • FindProxyForURL関数の条件が内部ドメインに対してDIRECTを返している
  • WPADのDNSレコードが設定されていない
  • PACファイルの配布先URLが変更されたが更新されていない
確認手順
  • ブラウザのPAC設定URLにアクセスしてPACファイルの取得を確認
  • PACファイルのJavaScript構文をブラウザのコンソールで検証
  • nslookup wpad でWPADのDNSレコードを確認
  • 問題のURLに対してFindProxyForURLの戻り値を確認
プロキシログ解析で発覚した内部からの不審通信
想定される原因
  • マルウェアのC2通信によるビーコニング
  • 情報漏洩(Data Exfiltration)
  • 不正インストールされたクラウドストレージアプリ
  • 外部DNSトンネリングによるプロキシ迂回
確認手順
  • プロキシログで同一IPからの定期的なアクセスパターンを確認
  • アップロードバイト数が多い端末を特定
  • User-Agentが標準的なブラウザでないリクエストを確認
  • 該当端末のプロセスとネットワーク接続を確認(netstat)
プロキシ経由のWebSocket接続失敗
想定される原因
  • プロキシがHTTP/1.0のみ対応でWebSocket Upgradeに必要なHTTP/1.1をサポートしていない
  • プロキシがCONNECTメソッドによるトンネリングを許可していない
  • プロキシのタイムアウト設定が短くWebSocketの長時間接続が切断される
  • SSL BUMP(SSLインスペクション)がWebSocketのUpgradeヘッダーを除去している
  • プロキシのACLでWebSocketのポート(80/443以外)がブロックされている
確認手順
  • curl -v --proxy <proxy> -H "Upgrade: websocket" -H "Connection: Upgrade" http://<host> でUpgradeが通るか確認
  • プロキシのアクセスログでCONNECTメソッドが許可されているか確認
  • プロキシのタイムアウト設定(connect_timeout / read_timeout)を確認
  • SSL BUMPの有無と対象ドメインのSSLインスペクション除外設定を確認
  • WebSocketポートがACLで許可されているか確認
透過プロキシ(Transparent Proxy)によるHTTPS接続エラー
想定される原因
  • 透過プロキシのCA証明書がクライアントにインストールされておらず「証明書エラー」が発生
  • クライアントがHTTPS(TLS)でCertificate Pinningを使用しておりMITM不可
  • iptables/nftablesのTCPリダイレクトルールが正しく設定されていない
  • Squidのssl_bump設定でbump対象とsplice対象の振り分けが誤っている
  • Certificate Transparencyチェックでプロキシ発行証明書が拒否される
確認手順
  • クライアントブラウザの証明書エラーメッセージとIssuerを確認(プロキシCA由来か確認)
  • iptables -t nat -L PREROUTING でリダイレクトルールを確認
  • Squidのssl_bump設定(acl / ssl_bump step)を確認
  • openssl s_client -connect <host>:443 でサーバー証明書を確認
  • Certificate Pinningを使うアプリをsplice除外設定しているか確認
プロキシ経由のSSL証明書ピンニング(Certificate Pinning)エラー
想定される原因
  • SSL/TLSインスペクション(SSLバンピング)プロキシが証明書を置換しピンニングと不一致
  • モバイルアプリやAPIクライアントが証明書ピンニングを実装している
  • プロキシのCA証明書がクライアントのトラストストアに追加されていない
  • HPKP(HTTP Public Key Pinning)ヘッダーによる厳格なピンニング
確認手順
  • プロキシのSSLインスペクション設定を確認(有効/無効)
  • クライアントアプリの証明書ピンニング実装を確認
  • プロキシCAをクライアントのトラストストアに追加しているか確認
  • Wiresharkでアプリが受信している証明書の発行者を確認
プロキシ NTLM認証ループ(Windows統合認証障害)
想定される原因
  • プロキシSPNがADに未登録でKerberos認証が失敗しNTLMループ
  • ブラウザのInternet Zoneにプロキシが含まれてステルス認証が無効
  • NTLMv1/v2互換性問題
確認手順
  • ブラウザのネットワークログで407の繰り返しを確認
  • setspn -L でSPN登録を確認
  • ブラウザのSecurityゾーン設定を確認
プロキシ キャッシュポイズニング(Cache Poisoning)防止設定
想定される原因
  • キャッシュキーに含まれないヘッダー(X-Forwarded-Host等)がレスポンスに影響する
  • Hostヘッダーインジェクションによるキャッシュへの悪意のあるコンテンツ混入
  • Varyヘッダーが不適切でUser-Agent等でキャッシュが分割されていない
  • デバッグヘッダーが本番環境で有効なままでキャッシュに混入
確認手順
  • キャッシュキーの設定を確認(どのヘッダーがキャッシュキーに含まれるか)
  • X-Forwarded-HostやX-Original-URLヘッダーの扱いを確認
  • Vary ヘッダーの設定を確認
  • キャッシュされたレスポンスに意図しない内容が含まれていないか確認
WPA Enterprise(802.1X)認証失敗による無線接続不可
想定される原因
  • クライアント証明書の期限切れ(EAP-TLS使用時)
  • RADIUSサーバーへの疎通断またはシークレット不一致
  • WLCとRADIUSの認証方式不一致(PEAP vs EAP-TLS)
  • 端末がドメインから外れていてコンピュータ認証が失敗
確認手順
  • WLCのクライアント認証ログを確認
  • RADIUSサーバーのアクセスログで拒否理由を確認
  • test aaa radius でRADIUSの疎通テスト
  • 端末の証明書ストアで証明書の有効期限を確認
無線チャンネル干渉による速度低下・接続断
想定される原因
  • 近隣APとの同一チャンネル干渉(特に2.4GHz帯)
  • 電子レンジ・Bluetooth等の非WiFi干渉源
  • チャンネル幅が広すぎて(80MHz/160MHz)干渉が増大
  • APの送信電力が高すぎてセル間干渉が発生
確認手順
  • WLCのRFメトリクスでチャンネル使用率とノイズフロアを確認
  • 現場でWiFi Analyzerを使って周辺APのチャンネルを確認
  • 2.4GHzのAP間でチャンネル1/6/11の使い分けを確認
  • 5GHzのチャンネル設定とAPの送信電力を確認
クライアントのローミング失敗による接続断
想定される原因
  • クライアントが低いRSSIでも現在のAPに固執(スティッキークライアント)
  • 802.11rファスト移行が有効だが一部クライアントが非対応
  • 隣接APがローミングに必要なオーバーラップカバレッジを持たない
  • APの送信電力が不均一でカバレッジホールが発生
確認手順
  • WLCでクライアントのローミング履歴を確認
  • クライアントのRSSIとSNR値を確認
  • 802.11rが有効な場合、クライアントの対応状況を確認
  • AP間のカバレッジオーバーラップが15-20%確保されているか確認
APのRADIUS疎通断によるSSIDの全認証失敗
想定される原因
  • RADIUSサーバーへのネットワーク疎通断
  • RADIUSサーバーのサービス停止
  • WLCとRADIUSの間のファイアウォールルール変更
  • RADIUSのUDP 1812/1813ポートのブロック
確認手順
  • WLCからRADIUSサーバーへのping確認
  • test aaa group コマンドでRADIUS疎通テスト
  • RADIUSサーバーのサービス状態を確認
  • ファイアウォールのUDP 1812/1813の開放状況を確認
5GHz帯DFSチャンネルレーダー検知によるAPの周波数変更
想定される原因
  • DFSチャンネルでレーダー波を検知(気象レーダー等)
  • チャンネル利用可能確認(CAC)中の誤検知
  • APファームウェアのバグによる誤検知
  • 電子機器からのノイズがレーダーと誤判定
確認手順
  • WLCのDFSイベントログでレーダー検知の頻度と場所を確認
  • 近隣のレーダー施設(気象・航空)の有無を確認
  • APファームウェアバージョンを確認
  • DFSチャンネル使用のAPとDFS非使用APのパフォーマンス比較
WLCとAPのCapwap接続断によるAPのスタンドアロンモード移行
想定される原因
  • WLC障害またはリロード
  • APとWLC間のネットワーク経路断
  • CAPWAP用のUDP 5246/5247がブロック
  • APのプライオリティ設定でWLCへの接続が後回し
確認手順
  • APからWLCへの疎通確認(ping WLC-IP from AP)
  • show ap join stats summary でAP接続状況を確認
  • UDP 5246/5247のファイアウォール設定を確認
  • WLCの障害ログを確認
無線LAN帯域幅枯渇による速度低下
想定される原因
  • 1台のAPに接続するクライアント数の過多(推奨は25-30台/AP)
  • 低速レート(11b/g)クライアントがエアタイムを大量消費
  • マルチキャスト/ブロードキャストによるエアタイム消費
  • 隠れ端末問題(Hidden Terminal Problem)
確認手順
  • WLCでAP別の接続クライアント数を確認
  • 低速レート(1/2/5.5/11Mbps)のクライアントを特定
  • チャンネル使用率のメトリクスを確認
  • Minimum Data Rate設定を確認
IoTデバイスのWPA2/WPA3非対応による接続失敗
想定される原因
  • WPA3必須設定のSSIDにWPA2以前のデバイスが接続しようとしている
  • PMF(Protected Management Frames)必須設定に非対応デバイス
  • WPA2+WPA3移行設定(Transition Mode)が未設定
  • TKIPを使用するレガシーデバイスがAES必須SSIDに接続できない
確認手順
  • 接続できないデバイスのWiFi規格とセキュリティ対応を確認
  • SSIDのセキュリティ設定(WPA2/WPA3/PMF)を確認
  • デバイスのドライバーバージョンを確認
  • WPA3 Transition Mode(WPA2/WPA3混在)が設定されているか確認
Wi-Fi 6(802.11ax)端末と旧APの互換性問題
想定される原因
  • APのファームウェアが古くWi-Fi 6の一部機能(TWT、BSS Coloring等)が未実装
  • BSS Coloringの色番号が近隣APと衝突して干渉回避が機能していない
  • OFDMAのダウンリンクのみ有効でアップリンクが無効のため性能が半減
  • レガシー端末(802.11g/n)が混在してビーコンの保護オーバーヘッドが増加
  • Wi-Fi 6E(6GHz帯)端末が5GHz帯にしか接続できずWi-Fi 6Eの恩恵なし
確認手順
  • APの管理画面またはWLC(Wireless LAN Controller)でWi-Fi 6機能の有効状態を確認
  • iwconfig / wpa_cli status でクライアントの接続モード(HE/VHT/HT)を確認
  • 802.11axパケットキャプチャ(Wireshark)でHE Capabilitiesの交換内容を確認
  • APの近隣スキャンでBSS Color値の重複を確認
  • Wi-Fi アナライザーツールでチャネル利用率とOFDMAの動作を確認
無線LAN コントローラー(WLC)とAPの冗長構成障害
想定される原因
  • プライマリWLCがダウンまたはネットワーク障害でAPからCAPWAPトンネルが切断
  • WLC HA(High Availability)ペアのホットスタンバイが正しく設定されていない
  • セカンダリWLCへのフォールバック時にAPがセカンダリへのJoin設定を持っていない
  • WLCのライセンス数超過でAPが再接続できない
  • CAPWAPトンネルが経由するネットワーク機器(ファイアウォール等)がUDP 5246/5247をブロック
確認手順
  • show ap summary でAPの接続先WLCと状態を確認
  • show redundancy summary でWLC HAペアの状態を確認
  • ping <プライマリWLC IP> でAPからの疎通を確認
  • show ap join stats summary でJoin失敗の原因を確認
  • show license summary でAPライセンス使用状況を確認
Wi-Fi 802.1X RADIUS認証タイムアウト
想定される原因
  • WLCからRADIUSサーバーへの到達性問題
  • RADIUSサーバーの高負荷
  • EAPタイムアウト値がRADIUS応答時間より短い
確認手順
  • WLCからRADIUSへのpingを確認
  • RADIUSサーバーの負荷を確認
  • WLCのRADIUSタイムアウト値を確認
Wi-Fi チャネル干渉による速度低下・接続不安定
想定される原因
  • 同一チャネルを使用する複数のAPが互いに干渉(CCI: Co-Channel Interference)
  • 隣接チャネルが重複しているAPからの干渉(ACI: Adjacent Channel Interference)
  • 電子レンジやBluetooth機器などの2.4GHz帯干渉源
  • チャネルが手動固定されており自動最適化が行われていない
確認手順
  • Wi-Fi Analyzerでチャネル使用状況とRF環境を確認
  • WLCのRF Healthレポートでチャネル利用率とSNRを確認
  • ACSログでAP間のチャネル割り当てを確認
  • スペクトルアナライザーで非Wi-Fi干渉源(電子レンジ等)を特定
BGPネイバー関係の確立失敗(TCPセッション障害)
想定される原因
  • TCP 179へのファイアウォールブロック
  • BGPバージョン不一致(稀)
  • eBGPで直接接続でないのにebgp-multihop未設定
  • ループバックアドレスを使用しているがルートが存在しない
確認手順
  • show ip bgp summary でネイバーの状態と維持時間を確認
  • telnet <peer-ip> 179 でTCP 179の疎通を確認
  • show ip route <peer-ip> でルーティング確認
  • debug ip bgp <peer-ip> events でBGPイベントをデバッグ
BGPルート受信はできているが転送されない(Route Filtering問題)
想定される原因
  • インバウンドprefix-listで受け取るべきプレフィックスが拒否されている
  • route-mapのsequenceが意図と異なる順序でマッチ
  • maximum-prefixの上限に達してルートを受け付けない
  • as-path filterが意図しないASを拒否
確認手順
  • show ip bgp neighbors <ip> received-routes でフィルタ前のルートを確認
  • show ip bgp neighbors <ip> routes でフィルタ後のルートを確認
  • show ip prefix-list <name> でprefix-listの内容を確認
  • show ip bgp <prefix> でルートの属性を確認
OSPFネイバー確立失敗(Hello/Deadタイムアウト不一致)
想定される原因
  • HelloタイマーまたはDeadタイマーの値が両端で不一致
  • OSPFエリアIDの不一致
  • 認証設定(plain/MD5)の不一致
  • ネットワークタイプ(broadcast/point-to-point)の不一致
確認手順
  • show ip ospf neighbor でネイバーの状態を確認
  • show ip ospf interface <IF> でHello/Deadタイマーを確認
  • 両端のOSPF設定(エリアID・認証・ネットワークタイプ)を比較
  • debug ip ospf adj でアジャセンシー確立過程を確認
OSPFルートフラッピングによるネットワーク不安定
想定される原因
  • 不安定な物理リンクによるOSPFネイバーのフラッピング
  • MTU不一致によるDBD(Database Description)パケットの断片化
  • OSPFデータベースオーバーフロー
  • 誤ったredistributeによるOSPFドメイン内へのループルート混入
確認手順
  • show ip ospf statistics でSPF計算回数を確認
  • show ip ospf database でLSAの状態を確認
  • show interfaces でリンクのアップ/ダウン頻度を確認
  • show ip ospf interface でMTU設定を確認
BGP AS_PATH操作ミスによる意図しないルート選択
想定される原因
  • AS_PATH Prependの回数設定ミスで意図したパスが選ばれない
  • Local Preferenceの設定が意図と逆になっている
  • MEDの比較がデフォルト無効(同一ASからでないと比較しない)
  • weight属性の設定範囲ミス
確認手順
  • show ip bgp <prefix> でベストパスと選択理由を確認
  • show ip bgp <prefix> detail で全パスの属性を比較
  • route-mapのset文を確認
  • 両端で期待するトラフィックフローを文書化して比較
OSPF LSA Type-5外部ルート再配布ループ
想定される原因
  • 2台のASBRが互いに相手のredistributeしたルートを再度redistributeしている
  • BGPからOSPFへのredistributeループ
  • connectしているネットワークと重複するOSPF外部ルート
  • redistributeタグ設定によるループ防止が機能していない
確認手順
  • show ip ospf database external でType-5 LSAを確認
  • show ip route <affected-prefix> でルートの出所を確認
  • redistribute設定にroute-mapが使用されているか確認
  • 複数のASBRのredistribute設定を比較
BGP Maximum-Prefix超過によるネイバー強制切断
想定される原因
  • 上流ISPからのフルルート受信で設定したmax-prefixを超過
  • 想定より多くのプレフィックスがアナウンスされた(経路漏洩等)
  • maximum-prefixの設定値が実際の必要数より低すぎる
  • BGP Route Leakによる大量プレフィックス受信
確認手順
  • show ip bgp summary でネイバーの状態(idle/shutting)を確認
  • show ip bgp neighbors <ip> でmaximum-prefix設定を確認
  • 上流ISPへのルート数を問い合わせ
  • BGP Route Leakの兆候がないか確認
OSPF区域(Area)設定ミスによるネットワーク分断
想定される原因
  • バックボーンエリア(Area 0)が不連続な設計
  • バックボーンに接続していない非ゼロエリアが存在
  • Virtual Linkの設定が必要だが未設定
  • ABR(Area Border Router)の設定ミスでエリア間ルートが届かない
確認手順
  • show ip ospf でエリア構成を確認
  • show ip ospf border-routers でABRを確認
  • OSPFのネットワーク図を作成してArea 0との接続性を確認
  • show ip route ospf でエリア間のルートが届いているか確認
BGP Route Reflector 障害によるフルメッシュiBGP経路喪失
想定される原因
  • Route Reflector(RR)がダウンしてRRクライアント間でiBGP経路が伝播されなくなった
  • 複数のRRで同一cluster-idを設定しておりCLUSTER_LISTループ検知で経路がドロップ
  • RRクライアントが誤ってRRとしても設定されており経路反射のループが発生
  • RRとクライアント間のTCPセッションが間欠的に切れてiBGP不安定が継続
  • RRのCPU過負荷で大量のiBGPアップデート処理が追いつかない
確認手順
  • show bgp summary でRRとのiBGPセッション状態とPreix Received数を確認
  • show bgp <prefix> でRR経由で受信した経路のCLUSTER_LISTとORIGINATOR_IDを確認
  • 全RRのcluster-idが一意になっているか確認(show bgp | include cluster-id)
  • RRのCPU使用率とBGPプロセスのメモリを確認
  • show bgp neighbors <rr_ip> でセッションの安定性(State/Flaps)を確認
OSPF Type-7 LSA から Type-5 への再配布エラー(NSSA)
想定される原因
  • NSSAエリアのABR(Area Border Router)のうちType-7→Type-5変換をするルーターが選出されていない
  • NSSAのABRがForwarding-Addressをスタブルート(0.0.0.0)に変換する設定で外部経路が詳細に広告されない
  • NSSA ABRでarea <n> nssa no-redistributionが設定されてType-7のType-5変換がブロック
  • Forwarding-Addressに指定されたIPがバックボーンエリアで不達でType-5が使用されない
  • 複数のABRが存在する場合、Router-IDが高いルーターが変換役になるがそのルーターがダウン
確認手順
  • show ip ospf database nssa-external でType-7 LSAの内容とForwarding-Addressを確認
  • show ip ospf database external でType-5への変換が行われているか確認
  • show ip ospf border-routers でABRとASBRの到達性を確認
  • NSSAエリアの各ABRで show ip ospf | include NSSA を確認
  • area <n> nssa default-information-originate が設定されているか確認
BGP Graceful Restart失敗による経路消失
想定される原因
  • GRタイマー内(デフォルト120秒)に再接続できなかった
  • ピアがGR helperモードに未対応
  • ソフトウェアアップグレード中のBGPプロセス再起動
確認手順
  • show bgp neighbors でGR状態確認
  • GRタイマー設定値と再起動時間を比較
  • ピアのGR Helperモード対応を確認
OSPF Area 0(バックボーン)との隣接断による全域ルーティング障害
想定される原因
  • ABRとArea 0の隣接関係が切断
  • Area 0との連続性が失われた非バックボーンエリアが孤立
  • バーチャルリンクの設定が必要だが未設定
確認手順
  • show ip ospf neighbor でArea 0の隣接関係を確認
  • show ip route ospf でエリア間ルートの消失を確認
  • ABRのospf設定でarea 0接続インターフェースを確認
BGP Communities 設定ミスによる経路フィルタリング障害
想定される原因
  • no-exportコミュニティが意図せず付与されてeBGPピアに経路が送られない
  • route-mapのcommunity matchが誤っていて正常な経路がdenyされている
  • コミュニティの値形式(AS:値)が一致していない
  • additive/deleteオプションの誤使用でコミュニティが意図せず削除
確認手順
  • show bgp ip <prefix> でコミュニティ属性を確認
  • route-mapのcommunity matchの条件を確認
  • no-exportコミュニティが意図しない経路に付与されていないか確認
  • ip community-list の設定を確認
OSPF Stub/NSSA Area 設定によるデフォルト経路問題
想定される原因
  • Stub AreaでABRがデフォルト経路を生成/広告していない
  • NSSA AreaでType-7→Type-5変換がABRで失敗
  • Totally Stubbyエリアで外部経路が必要なのにブロックされている
  • エリアの両端でstub/nssa設定が一致していない
確認手順
  • show ip ospf でArea typeを確認(stub/nssa/normal)
  • show ip route ospf でデフォルト経路(0.0.0.0/0)がOSPFで学習されているか確認
  • 両サイドのルーターでエリアタイプが一致しているか確認
  • ABRでType-7 LSAのType-5変換を確認
単一IPからの大量接続ドロップ(DDoS パターン)
想定される原因
  • 外部からのDDoS/SYN Flood攻撃を受けている
  • ボットネットによる分散型攻撃の単一ノードからのトラフィック
  • 正規ユーザーのアプリケーション不具合による過剰リクエスト
  • ファイアウォールのレート制限閾値が低すぎる設定ミス
確認手順
  • ファイアウォールログで送信元IPのドロップ回数を時系列で集計
  • 送信元IPのWHOIS情報・脅威インテリジェンスDBで評判を確認
  • トラフィック量の推移をNMSやNetFlowで確認し通常時と比較
  • 接続先ポート・プロトコルの分布を確認しパターンを特定
  • 同一IPからの接続試行レートを確認
既知の悪意あるIPへのアウトバウンド通信検知
想定される原因
  • 内部端末がマルウェアに感染しC2サーバーと通信している
  • フィッシングメール経由でバックドアが設置された
  • 正規ソフトウェアのアップデートサーバーが脅威インテリジェンスDBに誤登録されている
  • 内部ユーザーが悪意あるWebサイトにアクセスした
確認手順
  • 該当内部IPの端末を特定し、EDRログでプロセス・通信履歴を確認
  • 宛先IPを脅威インテリジェンス(VirusTotal、AbuseIPDB等)で照会
  • 通信内容をパケットキャプチャで分析しC2プロトコルの特徴を確認
  • 該当端末の最近のログイン履歴・ソフトウェアインストール履歴を確認
  • 同一宛先に通信している他の端末がないか横展開を確認
ポートスキャン検知(連続ポートアクセス)
想定される原因
  • 攻撃者による偵察フェーズのポートスキャン実行
  • 脆弱性スキャナー(Nmap、Masscan等)による自動スキャン
  • ペネトレーションテストの一環(事前通知がない場合は不正)
  • ワームやボットによる自動拡散の試行
確認手順
  • 送信元IPのスキャン対象ポート範囲とパターンを分析
  • 送信元IPの地理情報・脅威インテリジェンスを確認
  • スキャン対象サーバーで実際にオープンしているポートを確認
  • ペネトレーションテストの予定がないか確認
  • 同時期に他の送信元からのスキャンがないか確認
ファイアウォールルール設定ミス(正規トラフィックのブロック)
想定される原因
  • ファイアウォールルールの優先順位が誤っており、許可ルールより前にDenyルールが適用されている
  • ルール変更後のテストが不十分で正規トラフィックがブロックされた
  • 暗黙のDenyルール(最終ルール)にヒットしている(明示的な許可ルール漏れ)
  • IPアドレス変更後にファイアウォールルールが更新されていない
確認手順
  • ファイアウォールのルールヒットカウンターでどのルールがマッチしているか確認
  • ブロックされているトラフィックの送信元IP・宛先IP・ポートを特定
  • ルールの優先順位(上から順に評価)を確認し、Denyが先にマッチしていないか検証
  • 最近のルール変更履歴を確認し、変更前後のトラフィックフローを比較
  • テスト用にログモード(ブロックせずにログのみ)で検証
DNSトンネリング検知(不審なDNSクエリパターン)
想定される原因
  • マルウェアがDNSプロトコルを利用してC2通信やデータ流出を行っている
  • 攻撃者がDNSトンネリングツール(iodine、dnscat2等)で通信制限を回避している
  • 内部端末がDNS over HTTPS(DoH)を使用してフィルタリングを迂回している
  • 正規のCDNやSaaS利用で長いサブドメインが生成されている(誤検知の可能性)
確認手順
  • DNSログで異常に長いサブドメイン(30文字以上)やTXTレコードの大量クエリを確認
  • クエリ先ドメインのWHOIS情報と登録日を確認(新規登録ドメインは要注意)
  • 該当端末のDNSクエリ頻度を時系列で分析し通常時と比較
  • DNSレスポンスのペイロードサイズが異常に大きくないか確認
  • サブドメイン文字列のエントロピー(ランダム性)を計算して正規通信と比較
Geo-IPブロック(制限地域からの接続検知)
想定される原因
  • 攻撃者がGeo-IP制限対象国のIPアドレスからアクセスを試行している
  • ボットネットの一部が制限地域のIPレンジから接続している
  • 正規ユーザーがVPN経由で制限国のIPを使用している
  • Geo-IPデータベースの誤分類により正規トラフィックがブロックされている
確認手順
  • ブロックされたIPアドレスのGeo-IP情報を複数のデータベースで照合確認
  • 同一IPからの接続試行パターン(対象ポート、頻度)を分析
  • 正規ユーザーからのアクセス障害報告がないか確認
  • Geo-IPデータベースの更新日を確認し最新版であることを検証
  • 制限地域からの接続が増加傾向にないか時系列分析
UDP Flood攻撃(DNS/NTPリフレクション)
想定される原因
  • 攻撃者がDNS/NTPサーバーをリフレクタとして悪用しUDP Flood攻撃を実行している
  • Memcached/SSDPプロトコルを悪用した増幅攻撃(最大50,000倍の増幅率)
  • 送信元IPが偽装されており、オープンリゾルバが攻撃トラフィックを生成している
  • 社内のDNS/NTPサーバーが外部からのリフレクション攻撃に悪用されている
確認手順
  • ファイアウォールでUDPトラフィックのPPS(パケット/秒)とBPS(ビット/秒)を確認
  • 送信元ポート(53/123/11211/1900等)から攻撃プロトコルを特定
  • 自社のDNS/NTPサーバーがオープンリゾルバとして外部から悪用されていないか確認
  • 上流ISPのNetFlowデータでトラフィック量の推移を確認
  • 攻撃パケットのペイロードサイズとリクエスト/レスポンス比を分析
不正なVPNトンネル確立の検知
想定される原因
  • 内部ユーザーが未許可のVPNソフトウェアを使用してネットワーク制御を迂回している
  • 攻撃者が侵入後にVPNトンネルを使って持続的なバックドアを確立している
  • 正規のVPN接続が設定ミスにより未承認のピアから接続されている
  • マルウェアがVPNプロトコルを利用して通信を暗号化し検知を回避している
確認手順
  • 検知されたVPNプロトコル(OpenVPN/IPsec/WireGuard)と使用ポートを確認
  • VPN接続元の内部IPアドレスと端末を特定
  • 許可されたVPN接続リストと照合し未承認の接続を識別
  • トンネル経由のトラフィック量と通信先を分析
  • 該当端末にインストールされたVPNクライアントソフトウェアを調査
SMB/RDPポートへの外部からのアクセス試行
想定される原因
  • インターネットからSMB(445)やRDP(3389)ポートが直接アクセス可能な状態になっている
  • EternalBlue(MS17-010)等のSMB脆弱性を狙った自動スキャン
  • RDPブルートフォース攻撃による認証突破試行
  • ファイアウォール設定ミスで本来ブロックすべきポートが開放されている
確認手順
  • ファイアウォールでSMB(445)/RDP(3389)ポートが外部に公開されていないか確認
  • 該当ポートへのアクセス試行回数と送信元IPの分布を分析
  • 内部サーバーのSMBバージョンとパッチ適用状況(MS17-010等)を確認
  • RDPが必要な場合、NLAが有効化されているか確認
  • 同一IPからSMBとRDP両方へのスキャンがないか相関分析
ICMPトンネリング/異常ICMPトラフィック検知
想定される原因
  • 攻撃者がICMPプロトコルを利用してデータを外部に流出させている
  • pingトンネリングツール(ptunnel、icmpsh等)でファイアウォールを迂回している
  • マルウェアがICMPペイロードにエンコードデータを埋め込んで通信している
  • 正常なICMP通信の範囲を超える大きなペイロードが送信されている
確認手順
  • ICMPパケットのペイロードサイズが通常(64バイト程度)を大幅に超えていないか確認
  • ICMPエコーリクエストの頻度が異常に高くないか時系列で分析
  • ICMPペイロードの内容を分析しエンコードされたデータが含まれていないか確認
  • 該当端末でptunnel、icmpsh等のトンネリングツールが実行されていないか確認
  • ICMP通信先が既知のC2サーバーでないか脅威インテリジェンスで照合
セッションテーブル枯渇(コネクションテーブル溢れ)
想定される原因
  • Slowloris等のコネクション枯渇型DoS攻撃を受けている
  • ボットネットからの大量接続によりセッションテーブルが溢れている
  • ファイアウォールのセッションタイムアウト値が長すぎて古いセッションが残留
  • 内部システムのコネクションリークでセッションが大量消費されている
確認手順
  • ファイアウォールのセッションテーブル使用率と上限値を確認
  • セッション数が急増した時間帯と送信元IPの分布を分析
  • TCP/UDP/ICMPごとのセッション数の内訳を確認
  • セッションタイムアウト設定(TCP established/half-open等)を確認
  • 内部サーバーのコネクション数が異常に多くないか確認
IPスプーフィング攻撃の検知
想定される原因
  • 攻撃者が送信元IPを偽装してアクセス制御を迂回しようとしている
  • DDoS攻撃の一環でリフレクション/アンプリフィケーション攻撃に利用されている
  • RFC1918プライベートIPが外部インターフェースから受信されている(明確な偽装)
  • ルーティング設定ミスで正規トラフィックが誤ったインターフェースから到着している
確認手順
  • 受信インターフェースと送信元IPの整合性を確認(外部IFからの内部IPは偽装)
  • BogonリストIPアドレス(未割当/予約済みアドレス)からの通信がないか確認
  • uRPF(Unicast Reverse Path Forwarding)のログを確認
  • ルーティングテーブルを確認し非対称ルーティングによる誤検知を排除
  • 同時期のDDoS攻撃やリフレクション攻撃の兆候がないか相関分析
異常なアウトバウンドポート使用の検知
想定される原因
  • マルウェアが非標準ポートを使用してC2通信を行っている
  • リバースシェルが一般的なポート(4444/5555/8080等)で確立されている
  • 攻撃者がポートホッピングで検知を回避しようとしている
  • 正規アプリケーションが非標準ポートを使用している(要確認)
確認手順
  • 該当ポートを使用しているプロセスをEDRログで特定
  • 通信先のIPアドレスを脅威インテリジェンスで照合
  • 該当ポートのトラフィック内容をDPIまたはパケットキャプチャで分析
  • 社内の許可ポートリストと照合し未承認の通信を識別
  • 同一端末からの他の不審な通信パターンがないか確認
ARP Spoofing/ポイズニング検知
想定される原因
  • 攻撃者がARPスプーフィングで中間者攻撃(MITM)を実行しようとしている
  • 内部端末がARPキャッシュポイズニングで通信を傍受している
  • ネットワーク設定ミスでIPアドレスの重複が発生している
  • 不正なデバイスがGratuitous ARPでゲートウェイを偽装している
確認手順
  • ARPテーブルでIP-MACアドレスの対応が正しいか確認
  • ゲートウェイのMACアドレスが正規のものか確認
  • 同一IPに対して複数のMACアドレスが検出されていないか確認
  • DAI(Dynamic ARP Inspection)のログを確認
  • 物理的に不正デバイスが接続されていないかネットワークポートを調査
ファイアウォールログの改ざん/削除検知
想定される原因
  • 攻撃者がファイアウォールに侵入し証拠隠滅のためログを削除した
  • 内部不正者が不正行為の痕跡を消すためにログを改ざんした
  • ファイアウォールのディスク容量不足でログがローテーションにより消失した
  • syslogサーバーとの接続断によりログの欠落が発生した
確認手順
  • ファイアウォールの管理ログインイベントを確認し誰がログを操作したか特定
  • syslogサーバー側に転送済みのログのバックアップがあるか確認
  • ログの時系列で欠落期間(ギャップ)がないか確認
  • ファイアウォールのディスク使用率と自動ローテーション設定を確認
  • ログ整合性チェック(ハッシュ検証)で改ざんの有無を確認
フラグメンテーション攻撃の検知
想定される原因
  • 攻撃者がIPフラグメンテーションを悪用してIDS/IPSのシグネチャ検知を回避しようとしている
  • Teardrop攻撃(重複フラグメント)でシステムクラッシュを狙っている
  • Tiny Fragment攻撃でTCPヘッダーを分割しフィルタリングを回避している
  • 正規トラフィックのMTU設定問題でフラグメンテーションが発生している
確認手順
  • フラグメンテーションされたパケットの送信元IP・プロトコル・フラグメントオフセットを分析
  • 重複フラグメントや極小フラグメント(8バイト以下)がないか確認
  • ネットワーク経路のMTU設定に問題がないか確認
  • フラグメンテーション攻撃と同時に他の攻撃が行われていないか相関分析
  • ファイアウォールのフラグメント再構築機能が有効か確認
不正なNAT/PATテーブル操作の検知
想定される原因
  • 攻撃者がファイアウォール管理権限を取得しNATルールを改ざんしてトラフィックをリダイレクトしている
  • 不正なDNATルールが追加され内部サービスが外部に露出している
  • PATテーブルの枯渇により正規トラフィックのNAT変換に失敗している
  • 管理者が変更管理プロセスを経ずにNATルールを変更した
確認手順
  • NATルールの変更履歴と変更者を監査ログで確認
  • 現在のDNATルールで意図しない内部サービスが外部公開されていないか確認
  • PATテーブルの使用率と枯渇の兆候を確認
  • NATルール変更が変更管理プロセスに記録されているか確認
  • 不正なポートフォワーディングが設定されていないか全NATルールをレビュー
IoTデバイスからの不審なアウトバウンド通信
想定される原因
  • IoTデバイスがMirai等のIoTボットネットマルウェアに感染している
  • IoTデバイスのデフォルト認証情報が悪用されてボットに組み込まれた
  • IoTデバイスが他のネットワークへのスキャン/攻撃の踏み台として利用されている
  • IoTデバイスのファームウェア脆弱性を悪用した侵害
確認手順
  • IoTデバイスの通常の通信パターン(通信先、ポート、頻度)と比較
  • 該当デバイスのファームウェアバージョンと既知脆弱性を確認
  • デフォルト認証情報が変更されているか確認
  • 他のIoTデバイスも同様の不審な通信をしていないか確認
  • 通信先のIPアドレスを脅威インテリジェンスで照合
Torネットワークへのアクセス検知
想定される原因
  • 内部ユーザーがTorブラウザを使用してダークウェブにアクセスしている
  • マルウェアがTorネットワーク経由で匿名C2通信を行っている
  • 内部犯行者がTorを使用して匿名でデータを外部に流出させている
  • セキュリティリサーチャーが業務でTorを利用している(正当な場合あり)
確認手順
  • Torリレー/出口ノードのIPリスト(公開リスト)と通信先を照合
  • 該当端末でTorブラウザやtor.exeプロセスが実行されていないか確認
  • Tor通信の目的が業務上正当なものかユーザーに確認
  • Tor利用と同時期のデータアップロードや不審な行動がないか確認
  • プロキシログでTor利用前後のWeb閲覧履歴を確認
DHCPスターベーション攻撃の検知
想定される原因
  • 攻撃者がMACアドレスを偽装して大量のDHCPリクエストを送信しアドレスプールを枯渇させている
  • 不正なDHCPサーバー(Rogue DHCP)がネットワークに接続されている
  • ネットワーク機器の故障でDHCPリクエストがループしている
  • 正規端末の大量接続でDHCPプールが不足している
確認手順
  • DHCPサーバーのリース状況とプール使用率を確認
  • 短時間で大量のDHCP DISCOVERが送信されていないか確認
  • リース割当先のMACアドレスが正規デバイスのものか確認
  • ネットワーク上に不正なDHCPサーバーが存在しないか確認
  • DHCPスヌーピングのログを確認
SQLインジェクション攻撃の検知
想定される原因
  • Webアプリケーションの入力パラメータに対するSQLインジェクション攻撃
  • 自動スキャンツール(sqlmap等)による脆弱性探索
  • 既知のSQLインジェクション脆弱性を悪用した攻撃
  • APIエンドポイントのパラメータバリデーション不足を狙った攻撃
確認手順
  • WAFログでブロックされたリクエストのパラメータ・ペイロードを確認
  • 攻撃対象のURLパスとパラメータ名を特定
  • アプリケーションのソースコードでパラメータバインディングが使われているか確認
  • 同一IPからの攻撃頻度とパターンを分析
  • WAFのSQLインジェクションルールセットが最新か確認
XSS(クロスサイトスクリプティング)攻撃の検知
想定される原因
  • 反射型XSS攻撃:URLパラメータにスクリプトを注入して実行を試行
  • 格納型XSS攻撃:掲示板・コメント欄等にスクリプトを永続的に挿入
  • DOM-based XSS攻撃:クライアントサイドのJavaScriptの脆弱性を悪用
  • 自動脆弱性スキャナーによるXSSペイロードテスト
確認手順
  • WAFログでブロックされたXSSペイロードの内容を確認
  • 攻撃対象のパラメータとURLパスを特定
  • アプリケーションの出力エスケープ処理が適切か確認
  • Content-Security-Policyヘッダーが設定されているか確認
  • 同一IPからの攻撃パターンを時系列で分析
ディレクトリトラバーサル攻撃の検知
想定される原因
  • ファイルパスを含むパラメータに対するディレクトリトラバーサル攻撃
  • Webアプリケーションのファイルアップロード/ダウンロード機能の脆弱性を悪用
  • LFI(Local File Inclusion)脆弱性を使った機密ファイル読み取り試行
  • 自動スキャンツールによるパストラバーサル脆弱性の探索
確認手順
  • WAFログでブロックされたリクエストのURIとパラメータを確認
  • 攻撃者がアクセスを試みたファイルパスを特定
  • アプリケーションのファイル参照機能で入力値の検証が行われているか確認
  • Webサーバーのドキュメントルート外へのアクセスが制限されているか確認
  • chroot/sandboxでアプリケーションのファイルアクセス範囲が制限されているか確認
レート制限超過(API不正利用)
想定される原因
  • APIエンドポイントへのブルートフォース攻撃(認証突破試行)
  • スクレイピングボットによる大量リクエスト
  • 不正なAPI利用(レート制限の回避試行)
  • 正規ユーザーのアプリケーション不具合によるリクエストループ
確認手順
  • レート制限に達したIPアドレスとリクエスト先URIを特定
  • リクエストパターン(同一パラメータの繰り返し等)を分析
  • User-Agentヘッダーでボットか正規ブラウザかを判別
  • 認証エンドポイントへのリクエストの場合、ログイン試行の成功/失敗率を確認
  • APIキーの不正利用がないか確認
SSRF(Server-Side Request Forgery)攻撃の検知
想定される原因
  • 攻撃者がSSRF脆弱性を利用してクラウドメタデータ(IAMクレデンシャル等)を窃取しようとしている
  • URL入力パラメータを悪用して内部ネットワークの情報を収集する攻撃
  • リダイレクト機能を悪用したSSRF(オープンリダイレクト→内部アクセス)
  • 自動脆弱性スキャナーによるSSRF脆弱性の探索
確認手順
  • WAFログでブロックされたリクエストのパラメータ値(URL、リダイレクト先)を確認
  • 攻撃対象のアプリケーションがURL入力を処理する機能を持っているか確認
  • クラウド環境のIMDS(メタデータサービス)がIMDSv2に設定されているか確認
  • 内部ネットワークのIP範囲(10.x、172.16-31.x、192.168.x)へのアクセス試行を確認
  • アプリケーションのHTTPクライアントがリダイレクトを追跡する設定になっていないか確認
コマンドインジェクション攻撃の検知
想定される原因
  • Webアプリケーションのシステムコマンド呼び出し箇所に対するOSコマンドインジェクション攻撃
  • シェルメタ文字(;、|、`、$()等)を利用した任意コマンド実行の試行
  • ファイル処理機能(画像変換、PDF生成等)のコマンド呼び出しを悪用した攻撃
  • 自動スキャンツールによるコマンドインジェクション脆弱性の探索
確認手順
  • WAFログでブロックされたペイロードのコマンド内容を確認
  • 攻撃対象のエンドポイントがシステムコマンドを呼び出す機能を持つか確認
  • アプリケーションのソースコードでexec()、system()、popen()等の使用箇所を確認
  • 攻撃元IPからの他の攻撃パターン(SQLi、XSS等)が併発していないか確認
  • サーバー側でコマンド実行が成功した痕跡(プロセス起動ログ等)がないか確認
ファイルアップロード攻撃(悪意あるファイルタイプのバイパス)
想定される原因
  • 攻撃者がWebシェル(PHPバックドア等)をアップロードしてリモートコード実行を試行
  • 二重拡張子(.php.jpg)やNULLバイト(%00)でファイルタイプチェックを回避する攻撃
  • Content-Typeヘッダーを偽装して悪意あるファイルを正規ファイルに見せかける攻撃
  • SVGファイルに埋め込まれたXSSペイロードやXXEペイロードのアップロード
確認手順
  • WAFログでブロックされたファイル名・Content-Type・ファイルサイズを確認
  • アップロード機能のファイルタイプ検証方法(拡張子のみか、マジックバイトも確認しているか)を確認
  • アップロードされたファイルの保存先ディレクトリでスクリプト実行が無効化されているか確認
  • 過去にアップロードが成功した不審なファイルがないかファイルシステムを調査
  • Webシェルの既知パターン(eval、system、exec等を含むPHPファイル)がないか検索
XXE(XML External Entity)攻撃の検知
想定される原因
  • XMLパーサーが外部エンティティの処理を有効にしており、攻撃者がシステムファイルを読み取ろうとしている
  • Billion Laughs攻撃(XML Bomb)で再帰的エンティティ展開によるDoSを試行
  • XXE経由でSSRF攻撃を実行し内部ネットワークにアクセスしようとしている
  • SOAP/REST APIのXML入力パーサーの脆弱性を狙った攻撃
確認手順
  • WAFログでブロックされたXMLペイロードの内容(DTD宣言、エンティティ定義)を確認
  • 攻撃対象のエンドポイントがXML入力を処理しているか確認
  • XMLパーサーの設定で外部エンティティの処理が無効化されているか確認
  • 攻撃者がアクセスを試みたファイルパスやURLを特定
  • サーバー側でXXEが成功した痕跡がないか確認
CSRF(クロスサイトリクエストフォージェリ)攻撃の検知
想定される原因
  • 攻撃者が被害者のブラウザを利用して意図しないリクエストを送信させている
  • CSRFトークンが実装されていないフォームに対する攻撃
  • CSRFトークンの検証ロジックに脆弱性がある(トークン再利用、予測可能等)
  • SameSite Cookie属性が設定されておらずクロスサイトリクエストが許可されている
確認手順
  • WAFログでブロックされたリクエストのReferer/Originヘッダーを確認
  • 攻撃対象のフォーム/APIにCSRFトークンが実装されているか確認
  • CSRFトークンの生成・検証ロジックが適切か確認
  • SameSite Cookie属性の設定状況を確認
  • 攻撃元のURLがフィッシングサイトでないか確認
HTTP Request Smuggling攻撃の検知
想定される原因
  • Content-LengthとTransfer-Encodingヘッダーの矛盾を利用したリクエストスマグリング
  • フロントエンド(CDN/LB)とバックエンドでHTTPパーサーの解釈差異を悪用
  • CL.TE/TE.CL/TE.TEパターンでWAFをバイパスして後段のサーバーを攻撃
  • HTTP/2→HTTP/1.1ダウングレード時のプロトコル変換の脆弱性を悪用
確認手順
  • WAFログでContent-LengthとTransfer-Encodingの両方が含まれるリクエストを確認
  • フロントエンド/バックエンドのHTTPパーサーの挙動差異を検証
  • リクエストの境界が正しく解釈されているかテスト
  • HTTP/2ダウングレード設定を確認
  • 同一IPからの他の攻撃パターンとの相関分析
Webログインページへのブルートフォース攻撃
想定される原因
  • 攻撃者がWebアプリケーションのログインページにブルートフォース攻撃を実行
  • 漏洩パスワードリストを使用したクレデンシャルスタッフィング攻撃
  • 自動化ツール(Hydra、Burp Suite等)によるログイン試行
  • パスワードリセット機能を悪用した認証突破試行
確認手順
  • WAFログでログインエンドポイントへのPOSTリクエスト頻度を確認
  • 試行されているユーザー名のパターンを分析(同一ユーザーか複数ユーザーか)
  • 認証失敗レスポンスの内容がユーザー名の存在を漏洩していないか確認
  • 攻撃元IPの分布を確認(単一IPか分散型か)
  • ログイン成功が含まれていないか確認(認証突破の有無)
HTTPヘッダーインジェクション/レスポンスヘッダースプリッティング
想定される原因
  • ユーザー入力がHTTPレスポンスヘッダーに反映される箇所でCRLFインジェクションを実行
  • レスポンスヘッダースプリッティングでSet-Cookieヘッダーを注入しセッション固定攻撃を試行
  • Hostヘッダーインジェクションでキャッシュポイズニングを試行
  • リダイレクトURLにCRLF文字を注入してヘッダーを操作
確認手順
  • WAFログでCRLF文字(%0d%0a、\r\n)を含むパラメータを確認
  • 攻撃対象のパラメータがHTTPレスポンスヘッダーに反映されるか確認
  • リダイレクト機能やSet-Cookieヘッダーの動的生成箇所を特定
  • Hostヘッダーの値がアプリケーションで検証されているか確認
  • キャッシュサーバーがヘッダーインジェクションの影響を受けていないか確認
Webスクレイピングボットの検知
想定される原因
  • 競合他社によるWebコンテンツの自動収集(価格情報、商品データ等)
  • ヘッドレスブラウザ(Puppeteer、Selenium等)による自動操作
  • SEOスパムのための大量クローリング
  • 正規のボット(Googlebot等)の偽装によるスクレイピング
確認手順
  • User-Agentヘッダーのbot偽装を確認(正規ボットのIPレンジとの照合)
  • リクエストパターン(ページ遷移速度、robots.txt遵守の有無)を分析
  • JavaScriptの実行有無やCookieの受容状況でヘッドレスブラウザを判別
  • アクセスされたページの種類と順序を分析(商品ページの網羅的アクセス等)
  • TLSフィンガープリント(JA3)でボットライブラリを識別
NoSQLインジェクション攻撃の検知
想定される原因
  • MongoDB等のNoSQLデータベースのクエリオペレータ($gt、$ne、$where等)を注入した認証バイパス
  • JSONパラメータに不正なMongoDBオペレータを含めたデータ抽出試行
  • $whereオペレータ経由のJavaScript実行による任意コード実行
  • 自動ツールによるNoSQLインジェクション脆弱性の探索
確認手順
  • WAFログでブロックされたリクエストのJSONボディ/パラメータを確認
  • MongoDBオペレータ($gt、$ne、$where、$regex等)が含まれていないか確認
  • アプリケーションのDB接続層でクエリのサニタイズが行われているか確認
  • MongoDB側で$whereオペレータやJavaScript実行が無効化されているか確認
  • 認証エンドポイントでNoSQLインジェクションによるバイパスが可能か検証
WAFバイパス試行(エンコーディング/難読化)
想定される原因
  • 攻撃者がダブルURLエンコーディング(%25xx)でWAFのパターンマッチを回避
  • Unicode正規化の差異を悪用したWAFバイパス(全角文字でフィルタ回避等)
  • UTF-7/UTF-16等のエンコーディング差異を利用したペイロード難読化
  • HPP(HTTP Parameter Pollution)でパラメータ分割によるWAFバイパスを試行
確認手順
  • WAFログで多重エンコードされたペイロードのデコード結果を確認
  • WAFのデコーディング処理が多段階(URL→HTML→Unicode等)で実行されているか確認
  • Content-Typeのcharset指定が不正に操作されていないか確認
  • HPP(同一パラメータの複数指定)でペイロードが分割されていないか確認
  • WAFのルールセットバージョンとバイパス対策パッチの適用状況を確認
APIキー/認証トークン漏洩の検知
想定される原因
  • 開発者がAPIキーをURLクエリパラメータに含めて送信している(Refererヘッダー経由で漏洩リスク)
  • エラーレスポンスにAPIキーや内部トークンが含まれている
  • ログファイルやアクセスログにBearerトークンが記録されている
  • GitリポジトリやWebページのソースコードにAPIキーがハードコードされている
確認手順
  • WAFログでURLクエリパラメータにAPIキーパターン(api_key=、token=等)が含まれていないか確認
  • レスポンスボディにAPIキーや認証トークンのパターンが含まれていないか確認
  • アクセスログにBearerトークンが記録されていないか確認
  • エラーレスポンスのスタックトレースに認証情報が含まれていないか確認
  • APIキーのローテーション状況と有効期限を確認
HTTP Slowloris攻撃の検知
想定される原因
  • Slowloris攻撃で不完全なHTTPヘッダーを送信しWebサーバーのコネクションを枯渇させている
  • Slow POST攻撃でHTTPボディを極めて低速に送信しコネクションを占有
  • Slow Read攻撃でレスポンスのTCPウィンドウサイズを極小にして応答を遅延させている
  • 正規クライアントの低速回線による接続がタイムアウト設定に抵触している
確認手順
  • Webサーバーの同時接続数と待機中の接続数を確認
  • 特定IPからの長時間保持されている接続数を確認
  • HTTPリクエストの完了率(正常完了vs.タイムアウト)を分析
  • Webサーバーのタイムアウト設定(header timeout、body timeout)を確認
  • WAFの接続状態監視ログで不完全なリクエストの割合を確認
LDAP インジェクション攻撃の検知
想定される原因
  • LDAPクエリに不正な文字列を注入して認証バイパスを試行
  • LDAPフィルタインジェクションでActive Directoryの情報を不正取得
  • ワイルドカード(*)を利用したブラインドLDAPインジェクション
  • ユーザー検索機能のLDAPクエリ構築における入力値サニタイズ不足
確認手順
  • WAFログでLDAPメタ文字(*、(、)、\、NUL等)を含むパラメータを確認
  • 攻撃対象のエンドポイントがLDAP認証や検索機能を使用しているか確認
  • アプリケーションのLDAPクエリ構築でパラメータエスケープが行われているか確認
  • LDAPサーバーのアクセスログで不正なクエリが実行されていないか確認
  • 認証バイパスが成功した痕跡がないか確認
Prototype Pollution攻撃の検知
想定される原因
  • 攻撃者がJavaScriptのプロトタイプチェーンを汚染してアプリケーションの動作を改変
  • JSONマージ/ディープコピー機能の脆弱性を利用した__proto__プロパティの注入
  • 権限昇格のためにisAdmin等のプロパティをプロトタイプ経由で設定
  • サードパーティライブラリの既知のPrototype Pollution脆弱性を悪用
確認手順
  • WAFログでJSONボディに__proto__、constructor.prototypeが含まれるリクエストを確認
  • アプリケーションのオブジェクトマージ/ディープコピー処理を確認
  • 使用しているnpmパッケージにPrototype Pollution脆弱性がないか確認(npm audit)
  • Object.create(null)やMap等でプロトタイプフリーオブジェクトが使用されているか確認
  • 攻撃が成功した場合の影響範囲(権限昇格、RCE等)を評価
不正なHTTPメソッド使用の検知
想定される原因
  • PUTメソッドを使用してWebサーバーに直接ファイルをアップロードする試行
  • TRACEメソッドを利用したクロスサイトトレーシング(XST)攻撃
  • WebDAVメソッド(PROPFIND、COPY、MOVE等)で情報収集を試行
  • X-HTTP-Method-Overrideヘッダーによるメソッドバイパス
確認手順
  • WAFログでGET/POST以外のHTTPメソッドが使用されたリクエストを確認
  • Webサーバーで有効化されているHTTPメソッドの一覧を確認
  • WebDAVが意図せず有効になっていないか確認
  • TRACEメソッドが有効になっていないか確認
  • X-HTTP-Method-Overrideヘッダーがアプリケーションで処理されていないか確認
シグネチャベースの侵入検知アラート
想定される原因
  • 既知の攻撃パターンに一致するトラフィックが検出された
  • 脆弱性エクスプロイトの試行がシグネチャにマッチ
  • マルウェア通信のシグネチャパターンが検出された
  • シグネチャの誤検知(False Positive)によるアラート
確認手順
  • アラートのシグネチャID(SID)から攻撃の詳細情報を確認
  • 該当通信のパケットキャプチャで実際のペイロードを分析
  • 攻撃対象のサービス/アプリケーションが該当脆弱性を持つか確認
  • 同一シグネチャのアラート頻度と送信元の傾向を分析
  • シグネチャの更新日と最新CVE情報を照合
異常検知ベースのトラフィック異常アラート
想定される原因
  • ゼロデイ攻撃やシグネチャ未登録の新しい攻撃パターン
  • 内部ネットワークでのラテラルムーブメント(横展開)
  • データ流出(大量データの外部送信)の兆候
  • 正規のトラフィックパターン変化(業務変更等)による誤検知
確認手順
  • 異常検知されたトラフィックの詳細(送信元/宛先、ポート、プロトコル)を確認
  • ベースラインからの逸脱度合いと時間帯を分析
  • 該当時間帯に業務変更やシステム変更がなかったか確認
  • パケットキャプチャで通信内容を詳細分析
  • 他のセキュリティデバイスで同時期のアラートがないか相関分析
既知CVEのエクスプロイト試行検知
想定される原因
  • 公開された脆弱性(CVE)のエクスプロイトコードを使った攻撃
  • 自動化されたエクスプロイトキットによる大量スキャン
  • パッチ未適用のシステムを標的とした攻撃
  • 概念実証(PoC)コードの悪用による攻撃
確認手順
  • アラートに含まれるCVE番号からNVD/MITREで脆弱性の詳細を確認
  • 攻撃対象のシステム/ソフトウェアが該当CVEの影響を受けるバージョンか確認
  • パッチ適用状況を確認し未適用なら緊急対応を判断
  • 攻撃が成功した兆候(不正プロセス、ファイル変更等)がないか確認
  • 同一CVEを狙った攻撃が他のシステムにも来ていないか確認
ラテラルムーブメント検知(内部ホストスキャン)
想定される原因
  • 攻撃者が初期侵入後に内部ネットワークで横展開(ラテラルムーブメント)を試行している
  • 侵害された端末からSMB/RDP/WMIを使用して他のホストへのアクセスを試行
  • Pass-the-Hash/Pass-the-Ticket攻撃で窃取した認証情報を使い回している
  • ワームやランサムウェアがネットワーク内で自動拡散を試行している
確認手順
  • 送信元の内部IPアドレスが正規端末か、通常のアクセスパターンから逸脱していないか確認
  • SMB(445)、RDP(3389)、WMI(135)への接続先数と頻度を時系列で分析
  • 該当端末のEDRログでPsExec、WMI、PowerShell Remotingの使用を確認
  • Active Directoryのログオンイベント(4624/4625)で不審な認証パターンを確認
  • NTLMリレーやKerberoasting攻撃の兆候がないか認証ログを調査
C2(Command & Control)ビーコン通信の検知
想定される原因
  • マルウェアがC2サーバーに定期的なビーコン通信(ハートビート)を送信している
  • Cobalt Strike、Metasploit等のペネトレーションツールのビーコンが検出された
  • DNSビーコニングを使ったC2通信(DNS over HTTPSを含む)
  • 正規アプリケーションのヘルスチェック/アップデート確認が定期通信パターンに類似している(誤検知)
確認手順
  • 通信パターンの周期性を分析(一定間隔+ジッター付きの通信は典型的なビーコンパターン)
  • 宛先IPアドレス/ドメインを脅威インテリジェンス(VirusTotal、OTX等)で照合
  • 通信のHTTPヘッダー・ペイロードを分析しC2フレームワークの特徴を確認
  • 該当端末のプロセスツリーでビーコン通信を生成しているプロセスを特定
  • JA3/JA3Sフィンガープリントで既知のC2ツールのTLSパターンと照合
Kerberoasting攻撃の検知
想定される原因
  • 攻撃者がサービスアカウントのTGSチケットを大量取得してオフラインでパスワードクラッキングを試行
  • Rubeus/Impacketツールを使用したKerberoasting攻撃の実行
  • SPNが設定されたサービスアカウントが弱いパスワードを使用しており標的にされている
  • RC4暗号化のTGSチケットが要求されている(より弱い暗号方式を意図的に選択)
確認手順
  • Active DirectoryのイベントID 4769でRC4暗号化のTGSチケット要求を確認
  • 短時間で大量のTGSチケットが要求されていないか分析
  • 要求元のユーザーアカウントとIPアドレスを特定
  • SPNが設定されたサービスアカウントのパスワード強度を確認
  • 該当アカウントでRubeusやInvoke-Kerberoast等のツールが実行された痕跡がないか確認
BloodHound/SharpHound によるAD情報収集検知
想定される原因
  • 攻撃者がBloodHound/SharpHoundを使用してActive Directoryの権限パスを分析している
  • 侵害後のリコンフェーズでドメイン構造と特権アカウントを列挙している
  • ADの信頼関係やグループメンバーシップを網羅的に収集している
  • 正規の管理者がAD監査ツールを実行している(要確認)
確認手順
  • LDAPサーバーのアクセスログで短時間の大量クエリパターンを確認
  • クエリ内容がadminCount、trustedForDelegation等の特権関連属性に集中していないか確認
  • 該当ユーザーアカウントの権限レベルと通常のLDAP利用パターンを比較
  • 該当端末でSharpHound.exe等のツールが実行されていないかEDRログで確認
  • 収集されたデータがネットワーク外に送信されていないか確認
DNS Rebinding攻撃の検知
想定される原因
  • 攻撃者がDNS Rebinding手法で外部ドメインを内部IPに解決させ、ブラウザの同一オリジンポリシーを迂回
  • TTL=0のDNSレスポンスでDNSキャッシュを操作し、内部ネットワークへのアクセスを実現
  • IoTデバイスやルーターの管理画面に対するDNS Rebinding経由の不正アクセス
  • WebアプリケーションのSSRF脆弱性とDNS Rebindingの組み合わせ攻撃
確認手順
  • DNSログで同一ドメインが短時間で異なるIPアドレスに解決されていないか確認
  • TTL=0またはTTLが極端に短いDNSレスポンスがないか確認
  • 外部ドメインが内部IPアドレス(RFC1918)に解決されていないか確認
  • 該当端末のブラウザで不審なWebサイトにアクセスしていないか確認
  • 内部ネットワークのサービスにDNS Rebinding経由のアクセスがないか確認
DCSync攻撃の検知(ドメインレプリケーション権限悪用)
想定される原因
  • 攻撃者がMimikatzのDCSync機能を使用してドメインの全認証情報をダンプしている
  • 侵害されたアカウントがDS-Replication-Get-Changes権限を持ちADレプリケーションを悪用
  • 不正に取得したドメイン管理者権限でntds.ditを抽出しようとしている
  • 正規のドメインコントローラー追加に伴うレプリケーションリクエスト(要確認)
確認手順
  • Active DirectoryのイベントID 4662でDS-Replication-Get-Changes権限の使用を確認
  • レプリケーションリクエストの送信元がドメインコントローラーかどうか確認
  • 該当ユーザーアカウントのDS-Replication権限の割り当てが正当かレビュー
  • 該当端末でMimikatzやImpacket等のツールの実行痕跡がないか確認
  • krbtgtアカウントのパスワードが変更されていないか確認
SSLストリッピング/TLSダウングレード攻撃の検知
想定される原因
  • 中間者攻撃(MITM)でHTTPS通信をHTTPにダウングレードし通信内容を傍受
  • POODLE/BEAST等のTLSプロトコル脆弱性を悪用した暗号ダウングレード攻撃
  • SSLリネゴシエーション攻撃によるDoS試行
  • 古いTLSバージョン(SSLv3/TLS1.0)の使用を強制する攻撃
確認手順
  • IDS/IPSログでTLSバージョンのダウングレードリクエストを確認
  • サーバーでSSLv3やTLS1.0が無効化されているか確認
  • HSTSヘッダーが設定されHTTPへのダウングレードが防止されているか確認
  • TLS_FALLBACK_SCSVが有効になっているか確認
  • ネットワーク上でSSLストリッピングプロキシの兆候がないか確認
Golden Ticket/Silver Ticket攻撃の検知
想定される原因
  • 攻撃者がkrbtgtアカウントのハッシュを取得しGolden Ticketを生成して無制限のドメインアクセスを確立
  • サービスアカウントのハッシュを使用してSilver Ticketを生成し特定サービスに不正アクセス
  • DCSync攻撃後にkrbtgtのパスワードハッシュが窃取された
  • Mimikatz/Rubeus等のツールでKerberosチケットが偽造された
確認手順
  • Kerberos認証ログでTGTの有効期間がドメインポリシーの最大値を超えていないか確認
  • TGS要求に対応するTGT取得イベント(AS-REQ)が存在するか確認(Silver Ticket検知)
  • krbtgtアカウントのパスワード最終変更日を確認
  • 該当ユーザーの実際のログオンセッションとKerberosチケットの発行状況を比較
  • ドメインコントローラーのイベントログで不審なKerberosイベント(4768/4769/4771)を調査
データベースサーバーへの不正クエリ検知
想定される原因
  • 攻撃者がSQLインジェクション成功後にデータベースの全データをダンプしている
  • 内部犯行者が権限を悪用してデータベースの大量データを抽出している
  • 情報収集フェーズでスキーマ情報(テーブル名、カラム名)を列挙している
  • 正規のデータ分析やバックアップ処理が異常として検知された
確認手順
  • データベース監査ログで大量データを返すクエリを特定
  • クエリ実行元のIPアドレスとユーザーアカウントを確認
  • 抽出されたデータの内容が機密情報(個人情報、クレジットカード等)を含むか確認
  • クエリパターン(SELECT *、UNION SELECT、INTO OUTFILE等)を分析
  • 該当時間帯の正規のバッチ処理やETL処理の有無を確認
SMBリレー/NTLMリレー攻撃の検知
想定される原因
  • 攻撃者がResponder等のツールでLLMNR/NBT-NS/mDNSポイズニングを実行し認証情報を窃取
  • NTLMリレーで窃取した認証情報を中継して他のサービスに不正認証
  • SMBリレー攻撃でSMB署名が無効なサーバーに対して権限昇格を試行
  • ネットワーク上に不正なResponder/Impacketプロセスが実行されている
確認手順
  • ネットワークトラフィックでLLMNR(5355)/NBT-NS(137)/mDNS(5353)のレスポンスを分析
  • 不正なレスポンスを返しているIPアドレスを特定
  • SMBサーバーでSMB署名が有効になっているか確認
  • NTLMv1が使用されていないか確認(NTLMv2のみ許可すべき)
  • ネットワーク上でResponder/Impacketの特徴的な通信パターンがないか確認
暗号化通信内の脅威検知(ETA: Encrypted Traffic Analytics)
想定される原因
  • マルウェアがTLS暗号化でC2通信を隠蔽しているが、TLSメタデータの特徴で検知
  • JA3/JA3Sフィンガープリントが既知のマルウェアのパターンに一致
  • 自己署名証明書や短い有効期限の証明書がC2インフラの特徴を示している
  • TLSハンドシェイクパラメータの異常(Cipher Suite順序等)でマルウェアを検知
確認手順
  • JA3フィンガープリントを脅威インテリジェンスDB(ja3er.com等)で照合
  • TLS証明書のSubject/Issuer/有効期間/SANを確認
  • JA3Sフィンガープリント(サーバー側)もCobalt Strike等の既知パターンと照合
  • TLSバージョンとCipher Suiteの組み合わせが一般的なブラウザのものか確認
  • 通信先のIPアドレス/ドメインの評判を確認
DGA(Domain Generation Algorithm)ドメイン通信の検知
想定される原因
  • マルウェアがDGAを使用して動的にC2ドメインを生成し通信先を特定している
  • ボットネット(Conficker、Necurs等)のDGA通信パターン
  • NXDOMAINの大量発生はDGAドメインの名前解決失敗を示している
  • 正規のCDN等のランダムサブドメインが誤検知されている可能性
確認手順
  • DNSログで高エントロピー(ランダム文字列)のドメインクエリを時系列で分析
  • NXDOMAINレスポンスの割合が急増していないか確認
  • ドメインの文字列パターンを分析(母音/子音比率、n-gramモデル等)
  • 該当端末のプロセスでDNSクエリを生成しているプロセスをEDRで特定
  • 既知のDGAパターン(マルウェアファミリー別)との照合
IPS自動ブロックによるFalse Positive(正規トラフィック遮断)
想定される原因
  • IPSシグネチャが正規のアプリケーション通信を攻撃と誤判定してブロック
  • シグネチャルールが広すぎて正規トラフィックにマッチしている
  • アプリケーション更新後に通信パターンが変わりシグネチャに抵触
  • IPSのシグネチャセット更新後に新ルールが正規通信をブロック
確認手順
  • IPSのブロックログでシグネチャIDとマッチしたペイロードを確認
  • ブロックされた通信が実際に正規のものか送信元/アプリケーションを確認
  • 同一シグネチャによるブロック頻度と影響範囲を分析
  • シグネチャルールの条件を確認し、過剰にマッチしていないか検証
  • 最近のシグネチャ更新で新規追加されたルールがないか確認
ペイロード難読化による検知回避の検知
想定される原因
  • 攻撃者がシェルコードを難読化(XOR/Base64/多段エンコード)してIDS検知を回避
  • ポリモーフィックシェルコードで毎回異なるパターンを生成しシグネチャ検知を回避
  • IPフラグメンテーションやTCPセグメンテーションでペイロードを分割して検知を回避
  • 複数レイヤのエンコーディングを重ねて検知エンジンの処理を回避
確認手順
  • 検知されたペイロードのエンコーディング方式を分析(Base64、XOR、ROT13等)
  • フラグメント再構築後のペイロード全体を確認
  • IDS/IPSのデコーディングエンジンが多段デコードに対応しているか確認
  • 攻撃元IPからの他の攻撃活動との相関分析
  • 使用されている回避技術からAttacker TTP(MITRE ATT&CK T1027)を特定
不審なSMTPトラフィック(スパム/フィッシング送信)検知
想定される原因
  • 内部端末がスパムボットに感染し大量のスパムメールを送信している
  • フィッシングキャンペーンの送信元として社内メールサーバーが悪用されている
  • 内部犯行者が機密データをメール添付で外部に流出させている
  • メールサーバーのオープンリレー設定が悪用されている
確認手順
  • 内部からの外部SMTP(25/587)接続数を時系列で確認
  • メール送信の宛先数とメール件数を分析し通常の業務利用と比較
  • 送信メールの件名・本文・添付ファイルのパターンを分析
  • メールサーバーのリレー設定が適切か確認(オープンリレーでないか)
  • 送信元端末のプロセスでSMTP通信を行っているアプリケーションを特定
ARP Spoofing/ポイズニング検知(IDS視点)
想定される原因
  • 攻撃者が内部ネットワークでARPスプーフィングを実行しMITM攻撃を準備している
  • ツール(arpspoof、ettercap、bettercap等)によるARP cache poisoning
  • 不正デバイスがゲートウェイのMACアドレスを偽装して通信を傍受
  • ネットワーク設定ミスによるIPアドレスの重複
確認手順
  • ARPテーブルの変更履歴を確認しIP-MAC対応の不整合を特定
  • ゲートウェイIPのMACアドレスが正規のものか確認
  • ネットワーク上のGratuitous ARPパケットの頻度を分析
  • 物理ポートに接続されたデバイスのMACアドレスとスイッチポートの対応を確認
  • DAI(Dynamic ARP Inspection)のログを確認
Log4Shell(CVE-2021-44228)攻撃パターンの検知
想定される原因
  • 攻撃者がLog4j脆弱性(CVE-2021-44228)を悪用してJNDI Lookup経由でRCEを試行
  • HTTPヘッダー(User-Agent、X-Forwarded-For等)にJNDIペイロードを注入
  • エンコード回避手法(${${lower:j}ndi:等)でWAF/IDSの検知を回避する試行
  • 脆弱なLog4jバージョンを使用するJavaアプリケーションが標的にされている
確認手順
  • IDS/IPSログでJNDI Lookupパターン(${jndi:ldap/rmi/dns//})を確認
  • 各種エンコード回避パターン(${lower:}、${upper:}、${env:}等)も検索
  • 攻撃対象のアプリケーションがLog4j 2.x(2.17.0未満)を使用していないか確認
  • JNDI Lookupの宛先(LDAP/RMIサーバー)が外部IPか確認
  • 攻撃が成功した場合のコールバック通信(外部へのLDAP/RMI接続)がないか確認
SSHブルートフォースログイン試行
想定される原因
  • 外部からのSSHブルートフォース攻撃(パスワード辞書攻撃)
  • ボットネットによる自動化されたSSHクレデンシャルスタッフィング
  • 内部の不正ユーザーが他のサーバーへのアクセスを試行
  • SSHがデフォルトポート(22)で公開されており攻撃対象になっている
確認手順
  • /var/log/auth.log または /var/log/secure でfailed passwordの頻度を確認
  • 攻撃元IPアドレスの地理情報と脅威インテリジェンスを確認
  • 試行されているユーザー名のパターン(root, admin, test等)を分析
  • SSH接続の成功ログがないか確認(攻撃が成功していないか)
  • fail2banやDenyHostsの動作状況を確認
アカウントロックアウト(連続認証失敗)
想定される原因
  • ブルートフォース攻撃によるアカウントロックアウト
  • ユーザーがパスワードを忘れて繰り返し誤入力
  • パスワード変更後に古い認証情報がキャッシュされたデバイスからの自動認証
  • サービスアカウントのパスワード期限切れによる自動ロック
確認手順
  • Active DirectoryのイベントID 4740でロックアウト元のコンピューターを特定
  • ロックアウトされたアカウントの種類(ユーザー/サービスアカウント)を確認
  • 認証失敗の送信元IPが正規のものか不審なものかを判別
  • パスワードポリシー(ロックアウト閾値、ロックアウト期間)を確認
  • 同時期に複数アカウントがロックアウトされていないか確認
通常とは異なる場所/IPからのログイン成功
想定される原因
  • アカウントの認証情報が漏洩し第三者が不正ログインしている
  • ユーザーがVPN経由で通常とは異なるIPからログインしている(正当)
  • フィッシング攻撃でクレデンシャルが窃取されて悪用されている
  • 共有アカウントが不正に使い回されている
確認手順
  • ログイン元IPの地理情報と過去のログイン履歴を比較
  • 「あり得ない移動」(短時間で遠距離のIP変更)がないか確認
  • ログイン成功後のユーザーの行動(ファイルアクセス、権限変更等)を確認
  • 該当ユーザーに直接連絡してログインに心当たりがあるか確認
  • 同一IPから他のアカウントへのログイン試行がないか確認
権限昇格試行(sudoの不正利用)
想定される原因
  • 一般ユーザーがroot権限の取得を試みている(内部不正の可能性)
  • 攻撃者が侵入後にローカル権限昇格を試行している
  • sudoersファイルの設定不備で想定外のユーザーがsudoを実行
  • 脆弱性を利用した権限昇格エクスプロイト(CVE-2021-4034等)
確認手順
  • /var/log/auth.log で sudo/su コマンドの実行履歴を確認
  • 試行したユーザーのアカウント状態と権限を確認
  • sudoersファイルの設定内容をレビュー
  • 該当ユーザーの最近のログイン元IPと活動履歴を確認
  • 権限昇格に関連するCVE(Polkit, sudo等)のパッチ適用状況を確認
クレデンシャルスタッフィング攻撃(多数IPからの正規ユーザー名での認証失敗)
想定される原因
  • 漏洩したクレデンシャルリスト(combo list)を使用した自動ログイン試行
  • パスワードスプレー攻撃(少数パスワードを多数アカウントに試行しロックアウトを回避)
  • ボットネットを利用した分散型ブルートフォース攻撃(IP分散で検知回避)
  • ダークウェブで取得した認証情報を使った不正アクセス試行
確認手順
  • 認証失敗ログで同一ユーザー名に対して異なるIPからの試行パターンを分析
  • 試行されているユーザー名が実際に存在する正規アカウントかどうか確認
  • 認証失敗率と成功率の比率を確認(一部成功している場合はクレデンシャル漏洩の可能性)
  • Have I Been Pwned等で対象ユーザーのメールアドレスが漏洩リストに含まれていないか確認
  • 攻撃元IPの分布パターンを分析(住宅プロキシ・VPN出口の使用を検出)
サービスアカウント不正利用(非対話型アカウントの対話的ログイン)
想定される原因
  • 攻撃者が窃取したサービスアカウントの認証情報で対話的ログインしている
  • 内部不正者がサービスアカウントを悪用して高権限での操作を行っている
  • サービスアカウントのパスワードが共有されているか脆弱なものが設定されている
  • 正規の管理者がトラブルシューティングでサービスアカウントを使用している(ポリシー違反)
確認手順
  • Active DirectoryのイベントID 4624でログオンタイプが対話的(2/10/11)のサービスアカウントを検索
  • 該当サービスアカウントの通常利用パターン(ログオンタイプ、接続元)と比較
  • RDPセッションの場合、接続元IPが正規の管理サーバーかどうか確認
  • 該当サービスアカウントの権限レベルと所属グループを確認
  • ログオン後の活動(ファイルアクセス、プロセス起動、権限変更)を調査
MFAバイパス試行の検知
想定される原因
  • MFAファティーグ攻撃(大量のプッシュ通知を送信してユーザーに誤承認させる)
  • OTPコードのブルートフォース試行(6桁の場合100万通り)
  • フィッシングサイト経由でMFAトークンをリアルタイム中継する攻撃(Adversary-in-the-Middle)
  • セッションCookie/トークンを窃取してMFAを迂回する攻撃
確認手順
  • MFAログで同一ユーザーへの短時間の大量プッシュ通知送信がないか確認
  • OTP認証失敗の頻度を確認し、ブルートフォースパターンを検出
  • 認証成功後のセッションが異なるIPアドレスから使用されていないか確認
  • 該当ユーザーにMFA承認の心当たりがあるか直接確認
  • Adversary-in-the-Middleの兆候(フィッシングメール受信歴)がないか確認
RDPブルートフォース攻撃の検知
想定される原因
  • 外部からRDPポート(3389)に対するブルートフォース攻撃が実行されている
  • 漏洩したRDPクレデンシャルを使った自動ログイン試行
  • ランサムウェアグループによるRDP経由の初期侵入試行
  • 内部ネットワークでの横展開(RDP経由のラテラルムーブメント)
確認手順
  • WindowsイベントID 4625(ログオンタイプ10)の頻度を時系列で確認
  • 攻撃元IPアドレスが外部か内部かを確認
  • 試行されているユーザー名のパターンを分析
  • RDPの成功ログイン(イベントID 4624、ログオンタイプ10)がないか確認
  • NLA(Network Level Authentication)が有効になっているか確認
OAuth/SAMLトークン不正利用の検知
想定される原因
  • 攻撃者がOAuthトークンを窃取しAPIアクセスを悪用している
  • Golden SAML攻撃でSAMLアサーションを偽造しクラウドサービスに不正アクセス
  • OAuth同意フィッシングで悪意あるアプリに過剰な権限を付与させている
  • リフレッシュトークンが漏洩し長期間の不正アクセスが継続している
確認手順
  • OAuthトークンの発行元IPと使用元IPの一致を確認
  • SAMLアサーションの署名証明書が正規のIdPのものか検証
  • OAuthアプリのスコープ(権限要求)が正当なものか確認
  • リフレッシュトークンの発行・使用ログを確認
  • Azure AD/Entra IDの条件付きアクセスログで異常なトークン使用を確認
特権グループへの不正なメンバー追加
想定される原因
  • 攻撃者がドメイン管理者グループに自身のアカウントを追加して権限昇格
  • 侵害されたアカウントが特権グループの変更権限を持ち不正にメンバーを追加
  • 内部不正者が正当な理由なく特権グループに自身またはダミーアカウントを追加
  • 正規の管理操作だが変更管理プロセスを経ていない(ポリシー違反)
確認手順
  • Active DirectoryのイベントID 4728/4732/4756でグループメンバーシップの変更を確認
  • 変更を実行したアカウントと変更元のIPアドレスを特定
  • 追加されたメンバーのアカウントが正規のものか確認
  • 変更管理チケットが発行されているか確認
  • 特権グループ(Domain Admins、Enterprise Admins、Schema Admins等)の現在のメンバーを棚卸し
SSHキー不正追加の検知
想定される原因
  • 攻撃者が侵入後にSSH公開鍵を追加して永続的なバックドアアクセスを確立
  • マルウェアが自動的にauthorized_keysファイルに鍵を追加
  • 内部犯行者が自身の鍵を追加して後からアクセスできるようにしている
  • 正規の管理操作でSSH鍵が追加された(変更管理の確認が必要)
確認手順
  • authorized_keysファイルの変更日時と変更内容を確認
  • 追加された公開鍵のフィンガープリントを確認し所有者を特定
  • 変更を行ったプロセスとユーザーをauditdログで確認
  • 他のサーバーのauthorized_keysにも同じ鍵が追加されていないか横断確認
  • 変更管理チケットが発行されているか確認
営業時間外のログイン検知
想定される原因
  • 攻撃者が検知されにくい営業時間外に不正アクセスしている
  • 内部犯行者が監視の薄い夜間にデータ持ち出しを行っている
  • 海外の攻撃者が時差でアクセスしており現地は営業時間外になっている
  • 正規の残業や海外拠点からのアクセス(正当な場合あり)
確認手順
  • 該当ユーザーの通常のログイン時間帯パターンと比較
  • ログイン後の活動内容(ファイルアクセス、データ転送等)を確認
  • 該当ユーザーに残業やシフト勤務の予定があるか確認
  • 同一時間帯に他のユーザーでも営業時間外ログインがないか確認
  • VPNログやバッジ入退室記録と突合して物理的な存在を確認
Windows認証イベントの異常(ゴールデンチケット使用兆候)
想定される原因
  • 攻撃者がkrbtgtアカウントのNTLMハッシュを取得しGolden Ticketを偽造している
  • DCSync攻撃後にkrbtgtハッシュが窃取されドメイン全体が侵害されている
  • TGTの有効期間がドメインポリシーの最大値を超えている(偽造の兆候)
  • Mimikatz/Rubeusツールによるチケット偽造
確認手順
  • KerberosイベントID 4768/4769でTGTの有効期間がポリシー上限を超えていないか確認
  • TGT発行元がドメインコントローラーか確認(非DCからの発行は偽造の可能性)
  • krbtgtアカウントのパスワード最終変更日を確認
  • AS-REQ(4768)なしにTGS-REQ(4769)が発行されていないか確認
  • 該当ユーザーのKerberosチケットの暗号化タイプがポリシーと一致するか確認
API認証エラーの大量発生
想定される原因
  • 漏洩したAPIキーが無効化された後も攻撃者が使用を試行している
  • JWTトークンの期限切れ後にリフレッシュが失敗している
  • APIキーのブルートフォース試行
  • APIクライアントのバグで認証情報が正しく送信されていない
確認手順
  • API認証エラーの送信元IPとAPIキー/トークンのパターンを分析
  • エラーレスポンスが攻撃者に有用な情報を漏洩していないか確認
  • APIキーのローテーション状況と無効化済みキーのリストを確認
  • JWT検証のエラー詳細(期限切れ/署名不正/クレーム不正)を分析
  • 正規のAPIクライアントで同様のエラーが発生していないか確認
特権コマンドの不審な実行検知
想定される原因
  • 攻撃者が新しいユーザーアカウントを作成してバックドアアクセスを確立
  • 監査ポリシーを変更してセキュリティログの記録を無効化(証拠隠滅)
  • セキュリティイベントログを消去して攻撃の痕跡を削除
  • 正規の管理操作が変更管理プロセスを経ずに実行された
確認手順
  • WindowsイベントID 4720(ユーザー作成)、4719(監査ポリシー変更)、1102(ログ消去)を確認
  • コマンド実行元のユーザーアカウントと接続元IPを特定
  • 作成されたアカウントの権限レベルと所属グループを確認
  • 変更管理チケットが発行されているか確認
  • 同時期の他の不審な活動と相関分析
パスワードなし/デフォルトパスワードでのアクセス検知
想定される原因
  • ネットワーク機器やIoTデバイスのデフォルトパスワードが変更されていない
  • パスワードポリシーが空パスワードを許可する設定になっている
  • テスト環境で設定したデフォルトパスワードが本番環境に残存している
  • 新規導入したデバイスの初期設定でパスワード変更が漏れている
確認手順
  • デフォルトクレデンシャル(admin/admin、root/root等)で認証が成功していないか確認
  • パスワードポリシーで空パスワードが禁止されているか確認
  • ネットワーク機器やIoTデバイスのデフォルトパスワード一覧と照合
  • 脆弱性スキャナーでデフォルトクレデンシャルのチェックを実施
  • 新規導入デバイスの初期設定手順にパスワード変更が含まれているか確認
VPN認証の異常パターン検知
想定される原因
  • 攻撃者が窃取したVPN認証情報で不正接続している
  • VPNアカウントが共有されており複数拠点から同時接続されている
  • VPN接続後にスプリットトンネルを悪用して内部ネットワークと外部を同時アクセス
  • VPN認証のブルートフォース攻撃
確認手順
  • VPN認証ログで同一アカウントの同時接続を確認
  • VPN接続元IPのGeo-IP情報とユーザーの物理的な勤務地を比較
  • VPNクライアントのバージョンとセキュリティパッチ状況を確認
  • VPN接続後のトラフィックパターンを分析
  • VPN認証のMFA設定状況を確認
セッションハイジャック/Cookie窃取の検知
想定される原因
  • XSS攻撃でセッションCookieが窃取されている
  • 中間者攻撃(MITM)でセッショントークンが傍受されている
  • マルウェアがブラウザのCookieストアからセッション情報を窃取
  • セッション固定(Session Fixation)攻撃でセッションIDが予測/固定されている
確認手順
  • セッションに紐づくIPアドレスの変更を検知
  • 同一セッションIDが異なるIPアドレスから同時に使用されていないか確認
  • セッションの発行時間と有効期限が適切か確認
  • XSS脆弱性の有無を確認(Cookie窃取の経路として)
  • セッションCookieにHttpOnly/Secure/SameSite属性が設定されているか確認
PAM/特権アクセス管理の異常検知
想定される原因
  • 攻撃者がPAMシステムを迂回して特権アカウントのパスワードを直接取得
  • PAMの承認ワークフローを経ずに特権パスワードがチェックアウトされている
  • Break Glass(緊急アクセス)アカウントが正当な理由なく使用されている
  • PAMセッション記録を回避するためにPAMを経由しない直接アクセスが行われている
確認手順
  • PAMのチェックアウトログで承認なしのパスワード取得がないか確認
  • Break Glassアカウントの使用履歴と理由を確認
  • PAMを経由しない直接の特権アクセスがないか確認
  • セッション記録ログで不審な操作がないか確認
  • PAMの設定変更が行われていないか監査ログを確認
AWS/Azure/GCPクラウドIAM異常ログインの検知
想定される原因
  • クラウドのルートアカウント/グローバル管理者がMFAなしでログインしている
  • クラウドのアクセスキーが漏洩し不正利用されている
  • AssumeRole/Impersonationで意図しないロール切り替えが行われている
  • GitHubリポジトリやログファイルにクラウド認証情報がハードコードされている
確認手順
  • AWS CloudTrail/Azure AD Sign-in Logs/GCP Audit Logsでログインイベントを確認
  • ルートアカウントのMFA設定状況を確認
  • アクセスキーの最終使用日時と使用元IPを確認
  • IAMポリシーの変更履歴を確認
  • GitHubでのシークレットスキャン結果を確認
不審なプロセス実行(PowerShellエンコードコマンド)
想定される原因
  • マルウェアがPowerShellを使ってペイロードをダウンロード・実行している
  • Living-off-the-Land(環境寄生型)攻撃でPowerShellを悪用
  • フィッシングメールのマクロからPowerShellが呼び出されている
  • 正規の管理スクリプトがエンコードコマンドを使用している(要確認)
確認手順
  • PowerShellのスクリプトブロックログ(Event ID 4104)で実行内容をデコード・確認
  • プロセスの親プロセスツリー(Event ID 4688)で起動元を特定
  • ダウンロード先URLの脅威インテリジェンスを確認
  • 該当端末のEDRログで他の不審な活動がないか確認
  • Constrained Language Modeの適用状況を確認
ランサムウェア挙動の検知(大量ファイル暗号化)
想定される原因
  • ランサムウェアが実行されファイルの暗号化が進行中
  • フィッシングメールの添付ファイルからランサムウェアが展開された
  • RDP経由の不正アクセス後にランサムウェアが手動展開された
  • 脆弱性を利用した自動拡散型ランサムウェア(WannaCry型)
確認手順
  • 暗号化されたファイルの拡張子とランサムノートからランサムウェアの種類を特定
  • vssadminによるシャドウコピー削除やbcdedit修正のログを確認
  • 感染経路(メール添付、RDP、脆弱性等)を特定するため直前のログを精査
  • ネットワーク内の他の端末への横展開がないか確認
  • バックアップの最新復旧ポイントと無事を確認
不明なプロセスによるレジストリ変更
想定される原因
  • マルウェアが永続化(Persistence)のためにAutoRunレジストリキーを変更
  • バックドアがスタートアップに自身を登録している
  • 正規ソフトウェアのインストーラーがAutoRunに登録(要確認)
  • 攻撃者がリモートアクセスツール(RAT)の永続化を設定
確認手順
  • 変更されたレジストリキーの値(実行パス)を確認し、ファイルの正当性を検証
  • Sysmonのイベント13で変更元プロセスを特定
  • 該当ファイルのハッシュをVirusTotal等で照合
  • Autoruns(Sysinternals)でスタートアップエントリの全体を確認
  • 変更されたプロセスの親プロセスチェーンを追跡
DLLサイドローディング/インジェクション検知
想定される原因
  • 攻撃者が正規プロセスの検索順序を悪用してマルウェアDLLをサイドローディング
  • プロセスインジェクション(CreateRemoteThread等)による悪意あるDLLの注入
  • Reflective DLL Injectionによるファイルレス攻撃(ディスク上に痕跡なし)
  • 正規ソフトウェアのDLL検索パス脆弱性を悪用した攻撃
確認手順
  • Sysmonイベント7(Image Loaded)でロードされたDLLのパスと署名状態を確認
  • 正規プロセスが通常ロードしないDLLが読み込まれていないか確認
  • DLLファイルのハッシュをVirusTotal等で照合
  • プロセスのメモリ領域に不審なRWX(読み書き実行)権限のセクションがないか確認
  • DLLのロード元ディレクトリが正規のシステムパスかアプリケーションパスか確認
ファイルレスマルウェア検知(WMI/PowerShell Living-off-the-Land攻撃)
想定される原因
  • 攻撃者がWMIイベントサブスクリプションで永続化メカニズムを設定している
  • LOLBas(Living Off The Land Binaries)を悪用したファイルレス攻撃の実行
  • mshta.exe、certutil.exe、regsvr32.exe等のシステムバイナリを攻撃ツールとして悪用
  • PowerShellの.NET直接呼び出し([System.Reflection.Assembly]::Load)によるメモリ内実行
確認手順
  • WMIリポジトリで不審なイベントサブスクリプション(EventFilter/Consumer/Binding)を確認
  • Sysmonイベント1(Process Create)でmshta、certutil、regsvr32の起動コマンドラインを確認
  • PowerShellスクリプトブロックログ(Event 4104)で.NETリフレクションやダウンロード処理を確認
  • Autoruns(Sysinternals)のWMIタブで不審な永続化エントリを確認
  • プロセスの親子関係で不審なチェーン(Excel→cmd→PowerShell等)がないか確認
許可されていないUSBデバイスの接続検知
想定される原因
  • 内部犯行者(Insider Threat)がUSBデバイスでデータを持ち出そうとしている
  • ユーザーが個人のUSBデバイスを業務端末に接続している(ポリシー違反)
  • 攻撃者がUSBデバイスを使って物理的にマルウェアを配布している(USB Drop Attack)
  • BadUSB/Rubber Ducky等の悪意あるUSBデバイスが接続された可能性
確認手順
  • WindowsイベントログのUSBデバイス接続イベント(Event ID 2003/2100等)を確認
  • 接続されたUSBデバイスのベンダーID・プロダクトIDを特定
  • 該当ユーザーにUSBデバイス接続の正当な理由があるか確認
  • デバイス接続後にファイルコピーやデータ転送が行われていないかEDRログで確認
  • USBデバイス制御ポリシーが適切に適用されているか確認
LSASS(Local Security Authority Subsystem Service)メモリダンプ検知
想定される原因
  • 攻撃者がMimikatzでLSASSプロセスのメモリからNTLMハッシュ/Kerberosチケットを窃取
  • ProcDump、comsvcs.dll等の正規ツールを悪用したLSASSメモリダンプ
  • 攻撃者がlsass.exeのメモリダンプファイルをオフラインで解析
  • Task Manager経由でlsass.exeのダンプファイルが作成された
確認手順
  • Sysmonイベント10(Process Access)でlsass.exeへのアクセスを確認
  • アクセス元のプロセスがmimikatz、procdump、rundll32等でないか確認
  • lsass.exeへのアクセス権限(PROCESS_VM_READ等)を確認
  • ファイルシステムに.dmpファイルが作成されていないか確認
  • EDRのクレデンシャルダンプ検知アラートを確認
スケジュールタスクによる不審な永続化
想定される原因
  • マルウェアがスケジュールタスクを作成してシステム起動時やログオン時に自動実行を確保
  • 攻撃者がschtasks.exeで永続化メカニズムを設定
  • バックドアが定期的にC2サーバーに通信するタスクを登録
  • 正規のシステム管理タスクが変更されて悪意あるコマンドが追加された
確認手順
  • WindowsイベントID 4698(スケジュールタスク登録)でタスクの内容を確認
  • タスクのアクション(実行コマンド/スクリプト)の正当性を検証
  • タスクのトリガー(起動条件)と実行アカウントを確認
  • Linux環境ではcrontab -lで全ユーザーのcronジョブを確認
  • 正規のタスクリストと比較して未知のタスクがないか確認
EDRエージェントの無効化/改ざん検知
想定される原因
  • 攻撃者がEDR/アンチウイルスを無効化して検知を回避しようとしている
  • マルウェアがセキュリティエージェントのサービスを停止させている
  • 脆弱なドライバーを悪用したBYOVD(Bring Your Own Vulnerable Driver)攻撃
  • 管理者がトラブルシューティングのために一時的にセキュリティ機能を無効化した
確認手順
  • セキュリティエージェントの稼働状態を全端末で確認
  • エージェント停止の直前に実行されたプロセスやコマンドを確認
  • タンパープロテクション機能が有効になっているか確認
  • BYOVD攻撃に使用される脆弱ドライバー(gdrv.sys等)がロードされていないか確認
  • GPOでセキュリティ機能の無効化が制限されているか確認
不審なネットワーク接続プロセスの検知
想定される原因
  • マルウェアがリバースシェルで攻撃者にコマンド実行環境を提供している
  • 通常ネットワーク通信しないプロセス(notepad.exe、calc.exe等)が外部に接続している
  • バインドシェルがローカルポートで待ち受けて攻撃者の接続を待機
  • 正規プロセスにインジェクションされたマルウェアが通信を行っている
確認手順
  • Sysmonイベント3(Network Connection)で通信元プロセスと宛先を確認
  • 該当プロセスが通常ネットワーク通信を行うアプリケーションか確認
  • 宛先のIPアドレス/ポートを脅威インテリジェンスで照合
  • プロセスのメモリ内容を分析しインジェクションの痕跡がないか確認
  • 同一端末で他の不審なプロセスが実行されていないか確認
クリップボードデータの窃取検知
想定される原因
  • クリップボードスティーラーがパスワードや認証情報をキャプチャしている
  • 暗号通貨クリッパーがクリップボード内のウォレットアドレスを攻撃者のアドレスに置換
  • キーロガーがクリップボードの監視機能を併せ持っている
  • 正規のパスワードマネージャーがクリップボードにアクセスしている(誤検知の可能性)
確認手順
  • クリップボードにアクセスしているプロセスとアクセス頻度を確認
  • 該当プロセスのファイルハッシュをVirusTotal等で照合
  • クリップボードの内容が外部に送信されていないか通信ログを確認
  • 暗号通貨アドレスの置換がないかクリップボード履歴を確認
  • パスワードマネージャーのクリップボードクリア設定を確認
Windowsイベントログの消去検知
想定される原因
  • 攻撃者が侵入の痕跡を消すためにイベントログを消去した
  • マルウェアが自動的にログを削除して検知を回避している
  • 内部不正者が不正行為の証拠を隠滅している
  • 正規の管理者がディスク容量対策でログを消去した(変更管理の確認が必要)
確認手順
  • WindowsイベントID 1102(セキュリティログ消去)と104(システムログ消去)を確認
  • ログを消去したユーザーアカウントと接続元IPを特定
  • SIEMに転送済みのログバックアップから消去前のイベントを確認
  • ログ消去の前後に他の不審な活動がないか相関分析
  • 変更管理チケットが発行されているか確認
Officeマクロによるマルウェア実行検知
想定される原因
  • フィッシングメールの添付ファイル(Word/Excel)に悪意あるVBAマクロが含まれている
  • ユーザーが「コンテンツの有効化」をクリックしてマクロを実行した
  • Excel 4.0マクロ(XLM)を使用した検知回避型マルウェア
  • テンプレートインジェクション攻撃でリモートマクロが実行された
確認手順
  • プロセスの親子関係でOfficeアプリ(winword.exe/excel.exe)→cmd.exe/PowerShellの連鎖を確認
  • Officeファイルのマクロ内容をoledump.py等で分析
  • マクロの実行元ファイルのパスとファイルハッシュを確認
  • 該当ユーザーが受信したメールの添付ファイルを確認
  • Excel 4.0マクロ(XLM)が使用されていないか確認
認証情報窃取ツール(Mimikatz等)の実行検知
想定される原因
  • 攻撃者がMimikatzで認証情報(NTLMハッシュ、Kerberosチケット)を窃取している
  • LaZagne等のツールでブラウザやアプリケーションの保存パスワードを抽出している
  • ペネトレーションテスターが許可されたテストの一環でツールを実行している(要確認)
  • マルウェアにバンドルされた認証情報窃取モジュールが実行されている
確認手順
  • EDRのアラートでツールのファイルハッシュとコマンドラインを確認
  • VirusTotalでファイルハッシュを照合し既知のツール/マルウェアか確認
  • 該当プロセスの親プロセスチェーンを追跡し起動経路を特定
  • ペネトレーションテストの実施予定がないか確認
  • ツール実行後にクレデンシャルが悪用された痕跡がないか確認
不審なサービスインストール検知
想定される原因
  • マルウェアがWindowsサービスとして自身を登録して永続化
  • 攻撃者がsc.exeでサービスを作成しSYSTEM権限でのコード実行を確立
  • 脆弱なドライバー(BYOVD)がインストールされセキュリティ製品を無効化
  • 正規のソフトウェアインストールに伴うサービス登録(要確認)
確認手順
  • WindowsイベントID 7045(サービスインストール)でサービスの詳細を確認
  • サービスバイナリのファイルパスと署名状態を確認
  • ファイルハッシュをVirusTotal等で照合
  • サービスの起動アカウントと起動タイプを確認
  • 直近のソフトウェアインストール履歴と照合
キーロガー/スクリーンキャプチャマルウェアの検知
想定される原因
  • キーロガーマルウェアがキーボード入力を記録しパスワードや機密情報を窃取
  • スクリーンキャプチャマルウェアが画面のスクリーンショットを定期的に取得し外部送信
  • RAT(Remote Access Trojan)のキーロガー/スクリーンキャプチャ機能が有効化
  • 正規のリモートサポートツールが不正利用されている
確認手順
  • EDRでSetWindowsHookEx、GetAsyncKeyState等のAPI呼び出しを確認
  • プロセスがスクリーンショットファイル(.bmp/.png/.jpg)を定期的に生成していないか確認
  • キーログファイル(.log/.txt)が特定ディレクトリに作成されていないか確認
  • 該当プロセスのネットワーク通信(ログ/スクリーンショットの外部送信)を確認
  • 該当プロセスのファイルハッシュをVirusTotal等で照合
Bootkit/Rootkit検知(カーネルレベルの改ざん)
想定される原因
  • カーネルレベルのルートキットがインストールされプロセスやファイルを隠蔽している
  • MBR/VBRが改ざんされブート時にマルウェアがロードされている(Bootkit)
  • UEFIファームウェアマルウェアが永続的な感染を確立している
  • 脆弱なドライバーを悪用してカーネルレベルのアクセスを取得している
確認手順
  • EDRのカーネルレベルスキャンでルートキットの痕跡を確認
  • MBR/VBRの整合性チェック(正規のハッシュとの比較)を実施
  • Secure Bootの有効状態とUEFIファームウェアの整合性を確認
  • 隠されたプロセスやファイルがないかアンチルートキットツール(GMER等)で確認
  • カーネルドライバーのリストで未署名・不明なドライバーがないか確認
不審なWinRM/PowerShellリモーティングの検知
想定される原因
  • 攻撃者がWinRM/PowerShell Remotingで横展開(ラテラルムーブメント)を実行している
  • 侵害されたアカウントがリモートでPowerShellコマンドを実行している
  • IT管理者が正当な管理目的でPowerShell Remotingを使用している(要確認)
  • PSExecの代替としてWinRMが攻撃に使用されている
確認手順
  • WinRMのイベントログ(Microsoft-Windows-WinRM/Operational)で接続元を確認
  • PowerShellのリモーティングログ(Event ID 4104/53504)で実行コマンドを確認
  • 接続元IPが正規の管理サーバーかどうか確認
  • リモートセッションで実行されたコマンドの内容を分析
  • WinRMのリスナー設定(HTTP/HTTPS)とアクセス制御を確認
異常なCPU/メモリ使用率の検知(クリプトマイナー等)
想定される原因
  • クリプトマイナー(XMRig等)がCPUリソースを消費して暗号通貨をマイニングしている
  • マルウェアが大量のCPU/メモリを消費してシステムリソースを枯渇させている
  • 正規アプリケーションのバグで無限ループやメモリリークが発生している
  • DDoSボットが他のターゲットへの攻撃トラフィックを生成している
確認手順
  • Task ManagerやProcessExplorerでCPU消費が高いプロセスを特定
  • 該当プロセスのファイルハッシュをVirusTotal等で照合
  • プロセスのコマンドラインにマイニングプール接続情報が含まれていないか確認
  • CPU使用率の時系列推移を確認し不審な上昇パターンを分析
  • 該当プロセスのネットワーク通信を確認(Stratumプロトコル等)
ブラウザ拡張機能の不正インストール検知
想定される原因
  • マルウェアがブラウザ拡張機能をサイドロードしてWeb閲覧を監視・改ざん
  • フィッシング経由で悪意あるブラウザ拡張機能をインストールさせられた
  • 正規の拡張機能が乗っ取られ(サプライチェーン攻撃)マルウェア化した
  • ユーザーが過剰な権限を持つ拡張機能を不注意にインストールした
確認手順
  • インストールされた拡張機能のIDと要求する権限を確認
  • Chrome拡張機能のマニフェストファイルで要求パーミッションを分析
  • 拡張機能のソースコードに不審なスクリプトインジェクションがないか確認
  • 該当拡張機能のストア評価とレビューを確認
  • 拡張機能がアクセスしたWebサイトと送信したデータを分析
フィッシング/悪意あるURLへのアクセス検知
想定される原因
  • ユーザーがフィッシングメールのリンクをクリックした
  • マルウェアがC2サーバーや悪意あるURLに通信しようとしている
  • 検索エンジン経由でSEOポイズニングされた悪意あるサイトにアクセス
  • 広告ネットワーク経由のマルバタイジング(悪意ある広告)
確認手順
  • ブロックされたURLの脅威カテゴリと評判スコアを確認
  • 該当ユーザーが最近受信したメールにフィッシングURLが含まれていないか確認
  • 同じURLにアクセスしようとした他のユーザーがいないか確認
  • ブロック前にアクセスが成功していた期間がないか確認
  • URLが新規ドメイン(登録直後)でないか確認
大量データの外部アップロード検知(情報漏洩の疑い)
想定される原因
  • 内部犯行者(Insider Threat)による意図的なデータ持ち出し
  • マルウェアによる自動データ流出(Exfiltration)
  • 正規業務での大容量ファイル共有(要確認)
  • 退職予定者によるデータの事前持ち出し
確認手順
  • アップロード先のサービス/ドメインを特定(個人向けクラウドストレージ等)
  • 該当ユーザーの通常のアップロード量と比較して異常値かどうか判定
  • アップロードされたファイルの種類・内容をDLP(Data Loss Prevention)ログで確認
  • 該当ユーザーの人事情報(退職予定、配置転換等)を確認
  • 同時期に他のデータ持ち出し手段(USB、メール等)が使われていないか確認
暗号通貨マイニング通信の検知
想定される原因
  • 端末がクリプトマイニングマルウェアに感染し、マイニングプールと通信している
  • Webブラウザ経由のクリプトジャッキング(悪意あるJavaScriptによるブラウザマイニング)
  • 内部ユーザーが業務端末で意図的にマイニングソフトウェアを実行している
  • サーバーが侵害されクリプトマイナーが設置された(クラウド環境で頻発)
確認手順
  • プロキシログでStratum/JSON-RPCプロトコルの通信先(マイニングプール)を確認
  • 該当端末のCPU使用率が異常に高くないか確認(マイニングは高CPU負荷)
  • EDRログで実行中のプロセスにxmrig、minerd等のマイニングソフトウェアがないか確認
  • ブラウザ経由の場合、アクセスしたWebサイトにCoinHive等のマイニングスクリプトが含まれていないか確認
  • 該当端末の電力消費量やファン動作が通常と異なるか確認
TLS証明書異常の検知(既知ドメインへの自己署名証明書)
想定される原因
  • 中間者攻撃(MITM)により正規サイトの証明書が攻撃者の自己署名証明書に差し替えられている
  • 企業のSSLインスペクション機器が正しく設定されておらず証明書エラーが発生している
  • フィッシングサイトが有名ドメインに似せた証明書を使用している
  • 攻撃者がDNSスプーフィングと自己署名証明書を組み合わせて通信を傍受している
確認手順
  • プロキシログで証明書のSubject CN/SANとアクセス先ドメインの一致を確認
  • 証明書の発行者(CA)が信頼されたCAチェーンに含まれているか確認
  • 同一ドメインに対する証明書が過去と異なっていないか履歴を比較(Certificate Transparency Log)
  • 該当ネットワークセグメントでDNSスプーフィングが行われていないか確認
  • 企業のSSLインスペクション機器のCA証明書が端末に正しく配布されているか確認
Shadow IT(未許可SaaSサービス)利用の検知
想定される原因
  • 従業員が個人のクラウドストレージ(Dropbox、Google Drive等)に業務データをアップロードしている
  • 部門が独自にSaaSサービスを契約しIT部門の管理外で利用している
  • 退職予定者が個人アカウントにデータをバックアップしている
  • 開発チームが未承認のコードリポジトリや開発ツールを利用している
確認手順
  • プロキシログで個人向けクラウドストレージへのアクセスパターンを確認
  • CASBの発見レポートで未承認SaaSの利用状況を確認
  • データ転送量が多いユーザーと転送先サービスを特定
  • 該当ユーザーの業務上の利用理由があるか確認
  • 機密データが転送されていないかDLPログを確認
プロキシ認証のバイパス試行検知
想定される原因
  • ユーザーがプロキシ経由のフィルタリングを回避するためにVPN/トンネリングツールを使用
  • マルウェアがHTTP CONNECTトンネル内で非HTTPS通信を行い検査を回避
  • UltraSurf/Psiphon等のプロキシ回避ツールが使用されている
  • 直接インターネットに接続してプロキシ制御を迂回しようとしている
確認手順
  • ファイアウォールでプロキシを経由しない直接の外部接続(80/443)がないか確認
  • HTTP CONNECTトンネル内のトラフィックが実際にHTTPSか確認
  • プロキシ回避ツール(UltraSurf、Tor、Psiphon)の通信パターンを確認
  • 該当端末にプロキシ回避ツールがインストールされていないかEDRで確認
  • プロキシ設定がGPOで強制されているか確認
Webシェルへのアクセス検知
想定される原因
  • 攻撃者が以前にアップロードしたWebシェルにアクセスしてコマンドを実行している
  • Webサーバーが侵害されWebシェル(PHPバックドア等)が設置されている
  • プロキシログの分析で内部サーバーへのWebシェルアクセスが検知された
  • 外部サーバーに設置されたWebシェルへの通信(C2通信の一種)
確認手順
  • プロキシログでcmd=、exec=、command=等のパラメータを含むURLアクセスを確認
  • レスポンスサイズとコンテンツタイプが通常のWebページと異なるか確認
  • アクセス先URLのファイル名が一般的なWebシェル名(c99、r57、b374k等)でないか確認
  • 同一URLへの定期的なアクセスパターン(攻撃者によるバックドア利用)がないか確認
  • レスポンスにLinuxコマンド出力のパターン(uid=、root:x:等)が含まれていないか確認
DGA(Domain Generation Algorithm)ドメインへの通信検知
想定される原因
  • マルウェアがDGAでC2ドメインを動的生成し通信を試行している
  • NXDOMAINの連続発生はDGAドメインの名前解決失敗パターン
  • 新規登録ドメイン(NRD)へのアクセスがマルウェアのC2通信を示している
  • 正規のCDNやサービスのランダムサブドメインが誤検知される可能性
確認手順
  • プロキシログで短時間に多数の不明ドメインへのアクセスを確認
  • アクセスされたドメインのWHOIS情報と登録日を確認(新規登録ドメインは要注意)
  • ドメイン名の文字列エントロピーを分析しDGAパターンを特定
  • NXDOMAINレスポンスの割合を時系列で確認
  • 該当端末のEDRログでDNSクエリを生成しているプロセスを特定
HTTP/HTTPS経由のデータエンコード流出検知
想定される原因
  • マルウェアがBase64エンコードしたデータをURLパラメータやHTTPヘッダーに埋め込んで流出
  • カスタムHTTPヘッダーにエンコードデータを格納して検査を回避
  • 画像ファイル(ステガノグラフィー)にデータを埋め込んでHTTP経由で送信
  • チャンク転送エンコーディングを悪用してDLPの検査を回避
確認手順
  • プロキシログでURLパラメータに長いBase64文字列が含まれていないか確認
  • カスタムHTTPヘッダー(X-Custom等)に大量のデータが含まれていないか確認
  • 送信されたファイルのContent-Typeと実際のコンテンツの一致を確認
  • POSTリクエストのボディサイズが通常より大きくないか確認
  • 該当端末のプロセスでHTTP通信を生成しているアプリケーションを特定
生成AI/LLMサービスへの機密データ送信検知
想定される原因
  • 従業員が機密データ(ソースコード、顧客情報等)をChatGPT等のAIサービスに入力している
  • 開発者がプロプライエタリなコードやAPIキーをAIアシスタントに貼り付けている
  • ユーザーが社内文書をAIサービスに要約させるために全文を送信している
  • AI利用ポリシーが未整備で従業員が機密データの取り扱いを認識していない
確認手順
  • プロキシログでOpenAI/Anthropic/Google AI等のAPIエンドポイントへの通信量を確認
  • DLPでAIサービスに送信されたデータの内容(ソースコード、PII等)を確認
  • 該当ユーザーのAIサービス利用パターンを分析
  • 送信データに機密分類のキーワード/パターンが含まれていないか確認
  • 社内のAI利用ポリシーの周知状況を確認
マルバタイジング(悪意ある広告)経由の攻撃検知
想定される原因
  • 正規の広告ネットワークに悪意ある広告が混入し、ユーザーをマルウェア配布サイトにリダイレクト
  • エクスプロイトキット(RIG、Magnitude等)のランディングページへのリダイレクト
  • 広告内のiFrameにマルウェアダウンロードスクリプトが埋め込まれている
  • RTB(Real-Time Bidding)を悪用した標的型マルバタイジング
確認手順
  • プロキシログでリダイレクトチェーン(広告ネットワーク→中継サイト→エクスプロイトキット)を追跡
  • マルウェア配布URLの脅威インテリジェンスを確認
  • 同一広告ネットワークからのリダイレクトで他のユーザーが影響を受けていないか確認
  • 該当ユーザーの端末でマルウェアのダウンロード/実行が行われていないかEDRで確認
  • ブラウザの脆弱性が悪用されていないか確認(Flash、Java等)
Webメール経由のデータ持ち出し検知
想定される原因
  • 内部犯行者が個人メールアカウントで業務データを外部に送信している
  • 退職予定者がWebメール経由でデータを事前に持ち出している
  • マルウェアがWebメールサービスをC2チャネルとして利用している
  • 正規の業務で個人メールアドレスに資料を送信している(ポリシー違反)
確認手順
  • プロキシログでWebメールサービスへのアップロードサイズを確認
  • DLPログで添付されたファイルの内容と分類レベルを確認
  • 該当ユーザーの人事情報(退職予定等)を確認
  • Webメール利用が業務上必要かどうかを確認
  • 同一ユーザーの他のデータ持ち出し手段(USB、クラウドストレージ等)の利用状況を確認
不審なUser-Agentによるアクセス検知
想定される原因
  • マルウェアが古いUser-Agent文字列(IE6等)を偽装して通信している
  • 自動化スクリプト(Python requests、curl、wget等)によるWebアクセス
  • User-Agentが空のリクエストはボットやマルウェアの典型的な特徴
  • 正規のAPI呼び出しやCI/CDパイプラインのHTTP通信(要確認)
確認手順
  • プロキシログで異常なUser-Agent文字列のリクエストを抽出
  • 同一User-Agentを使用する全IPアドレスの分布を確認
  • 該当端末でHTTP通信を生成しているプロセスをEDRで特定
  • 空のUser-Agentや極端に古いUser-Agentのアクセスパターンを分析
  • User-Agent文字列を既知のマルウェアパターンDBと照合
ドメインフロンティング攻撃の検知
想定される原因
  • 攻撃者がCDN(CloudFront、Azure CDN等)を悪用してC2通信を正規トラフィックに偽装
  • TLSのSNIフィールドと実際のHTTP Hostヘッダーが異なる(ドメインフロンティングの特徴)
  • 検閲回避ツール(Signal、Tor等)がドメインフロンティングを使用している
  • APTグループがC2通信の隠蔽にCDNを利用している
確認手順
  • プロキシログでTLS SNIとHTTP Hostヘッダーの不一致を検知
  • CDN経由のトラフィックで実際の宛先(Originサーバー)が不明な通信を特定
  • Hostヘッダーの宛先がCDNのデフォルトドメインでないか確認
  • 該当通信のペイロード内容を分析(SSL復号化が必要)
  • 既知のAPTグループのドメインフロンティングインフラとの照合
HTTPSインスペクションエラー(TLS復号化失敗)
想定される原因
  • アプリケーションの証明書ピンニングによりSSLインスペクションが不可能
  • クライアント証明書認証を使用するサービスでSSLインスペクションが競合
  • TLS1.3のeSNI/ECHによりSNIが暗号化されインスペクションが困難
  • SSLインスペクション機器の処理能力不足でTLSハンドシェイクが失敗
確認手順
  • SSLインスペクションのバイパスリスト(例外リスト)が過度に拡大していないか確認
  • バイパスされている通信の中にマルウェアC2通信が含まれていないか確認
  • TLSハンドシェイク失敗の頻度と対象ドメインを分析
  • SSLインスペクション機器のCPU/メモリ使用率を確認
  • 証明書ピンニングを使用するアプリケーションの一覧を確認
Pastebin/コード共有サイトへの機密データ投稿検知
想定される原因
  • 開発者がデバッグのためにソースコードやログをPastebinに貼り付けている
  • APIキーやパスワードを含むコードがパブリックリポジトリにプッシュされた
  • 攻撃者が窃取したデータをPastebinにアップロードしている
  • 正規の技術共有目的だが機密情報が含まれている
確認手順
  • プロキシログでPastebin/Gist/パブリックリポジトリへのPOSTリクエストを確認
  • DLPで投稿内容にAPIキー、パスワード、PII等のパターンが含まれていないか確認
  • 該当ユーザーの投稿内容を確認し機密レベルを評価
  • パブリックに公開された情報の範囲と影響を評価
  • GitHubシークレットスキャンで既にコミットされた秘密情報がないか確認
Webアプリケーションの認証情報ハーベスティング(フォームジャッキング)
想定される原因
  • eコマースサイトがMagecart攻撃でクレジットカードスキマーが注入されている
  • サプライチェーン攻撃で外部JavaScriptライブラリにスキマーが混入
  • Webサイトの改ざんでログインフォームのデータが外部に送信されている
  • ブラウザ拡張機能がフォームデータを窃取している
確認手順
  • プロキシログでフォーム送信後に不明な外部ドメインへのリクエストがないか確認
  • Webページのソースコードに不審な外部JavaScriptの読み込みがないか確認
  • フォームデータの送信先が正規のサーバーのみか確認
  • CSP(Content-Security-Policy)ヘッダーで不正なスクリプト読み込みが検知されていないか確認
  • Subresource Integrity(SRI)で外部ライブラリの改ざんを検知
DNS over HTTPS(DoH)による制御迂回検知
想定される原因
  • マルウェアがDoHを使用してDNSフィルタリングを迂回しC2ドメインを解決している
  • ユーザーがブラウザのDoH設定で社内DNSフィルタリングを迂回している
  • DoHプロトコルを利用したデータトンネリング(DNSトンネリングのHTTPS版)
  • プライバシー保護のためにブラウザがデフォルトでDoHを有効化している
確認手順
  • プロキシログでdns.google、cloudflare-dns.com、dns.quad9.net等のDoHエンドポイントへのアクセスを確認
  • ブラウザのDoH設定が有効になっている端末を確認
  • DoH経由のDNSクエリ内容を分析(SSL復号化が必要)
  • DoHトラフィックの量が通常のDNS解決に比べて異常に多くないか確認
  • 社内DNS経由で名前解決されなかったドメインを特定
Webアプリケーション脆弱性スキャンの検知
想定される原因
  • 外部攻撃者が自社WebアプリケーションをNikto/Acunetix等で脆弱性スキャンしている
  • Burp Suite等のツールによる手動のペネトレーションテスト(承認済みか確認)
  • ボットネットによる大規模な自動脆弱性スキャン
  • 社内のセキュリティチームが定期的な脆弱性診断を実施している
確認手順
  • スキャン元のIPアドレスが社内セキュリティチームまたは委託先のものか確認
  • ペネトレーションテストの実施スケジュールと照合
  • スキャンの対象URL範囲とスキャンパターンを分析
  • スキャンで発見された脆弱性にすでにパッチが適用されているか確認
  • 同一IPからの攻撃活動(SQLi、XSS等の実際の攻撃)がないか相関分析
OAuth同意フィッシング(悪意あるアプリ認可)検知
想定される原因
  • 攻撃者がフィッシングメールで悪意あるOAuthアプリの認可を誘導している
  • 不正なアプリがmail.read、files.readwrite等の過剰なスコープを要求している
  • 正規のアプリに見せかけたフィッシングアプリがユーザーのデータにアクセスを試行
  • サプライチェーン攻撃で正規アプリの認可がハイジャックされている
確認手順
  • プロキシログでOAuth認可フロー(/authorize エンドポイント)のアクセスを確認
  • Azure AD/Google WorkspaceのOAuth同意ログで不審なアプリ認可を確認
  • 認可されたアプリのスコープ(権限範囲)が過剰でないか確認
  • 認可フローのリダイレクト先URLが正規のものか確認
  • 該当ユーザーにアプリ認可の心当たりがあるか確認
インスタンス起動失敗(リソース不足)
想定される原因
  • 指定ゾーンのリソースプールが枯渇している
  • プロジェクトのCPU/GPUクォータを超過している
  • リージョン固有のリソース制限に達している
  • 特定のマシンタイプがゾーンで利用不可
確認手順
  • GCP Console > IAM & Admin > Quotas でCPU/GPUクォータの使用状況を確認
  • gcloud compute regions describe [region] でリソース制限を確認
  • 別ゾーンでの起動を試行して問題がゾーン固有か確認
  • Cloud Monitoring でクォータ使用率の推移を確認
  • gcloud compute instances list で現在のインスタンス数を確認
SSH接続タイムアウト
想定される原因
  • VPCファイアウォールルールでポート22がブロックされている
  • インスタンスに外部IPが割り当てられていない
  • OSレベルでsshdが停止またはクラッシュしている
  • IAP(Identity-Aware Proxy)の設定が正しくない
確認手順
  • gcloud compute firewall-rules list でポート22の許可ルールを確認
  • gcloud compute instances describe [instance] で外部IPの有無を確認
  • シリアルコンソールからsshd のステータスを確認
  • VPC Flow Logs でトラフィックがドロップされていないか確認
  • IAP経由の接続が必要か確認(外部IPなしの場合)
ディスクI/Oパフォーマンス低下
想定される原因
  • pd-standardディスクのIOPS/スループット上限に達している
  • ディスクサイズが小さくIOPS上限が低い(サイズ比例のため)
  • インスタンスタイプのディスク帯域幅上限に達している
  • 同一ディスクへの並行I/Oが多すぎる
確認手順
  • Cloud Monitoring でdisk/read_ops_count, disk/write_ops_countを確認
  • ディスクタイプとサイズから理論上のIOPS上限を計算
  • iostat -x でインスタンス内部のI/O統計を確認
  • インスタンスのマシンタイプによるディスク帯域制限を確認
  • 同時にアタッチされているディスク数と帯域配分を確認
サービスアカウントキー認証エラー
想定される原因
  • サービスアカウントに必要なIAMロールが付与されていない
  • インスタンスのアクセススコープが不足している
  • サービスアカウントキーが無効化または削除されている
  • プロジェクト間のサービスアカウント利用で権限不足
確認手順
  • gcloud iam service-accounts get-iam-policy [sa_email] でロールを確認
  • gcloud compute instances describe [instance] でスコープを確認
  • gcloud auth list でアクティブなアカウントを確認
  • IAM Policy Troubleshooter で権限不足の原因を診断
  • Audit Log でアクセス拒否のログを確認
ライブマイグレーション中の一時的なネットワーク断
想定される原因
  • Googleのホストメンテナンスによるライブマイグレーション実行
  • ハードウェア障害によるインスタンスの自動移行
  • ゾーンメンテナンスイベントによる計画的移行
  • インスタンスのメンテナンスポリシーがMIGRATEに設定されている
確認手順
  • gcloud compute operations list --filter='operationType=compute.instances.migrateOnHostMaintenance' で移行履歴確認
  • Cloud Monitoring のcompute.googleapis.com/instance/uptime メトリクスを確認
  • シリアルポートログでマイグレーションイベントを確認
  • Cloud Console > Compute Engine > Operations でメンテナンスイベント確認
  • インスタンスのメンテナンスポリシー(MIGRATE/TERMINATE)を確認
起動スクリプト実行失敗
想定される原因
  • 起動スクリプト内のコマンドエラー(パッケージ未インストール等)
  • startup-script-url で指定したGCSオブジェクトへのアクセス権限不足
  • スクリプト内の依存サービスが起動時にまだ利用不可
  • メタデータサイズ制限(256KB)を超過している
確認手順
  • シリアルポート出力でスクリプトのエラーを確認: gcloud compute instances get-serial-port-output [instance]
  • Cloud Logging でstartup-script のログを検索
  • メタデータの内容確認: gcloud compute instances describe [instance] --format='value(metadata)'
  • GCSバケットのIAM権限とサービスアカウントのアクセス権を確認
  • スクリプトのシェバン行(#!/bin/bash)が正しいか確認
外部IPアドレス枯渇・割り当て失敗
想定される原因
  • リージョンの外部IPアドレスクォータ上限に達している
  • 未使用の静的IPアドレスが予約されたまま放置されている
  • 多数のインスタンスが個別に外部IPを持っている
  • Cloud NATを使わず全インスタンスに外部IPを割り当てている
確認手順
  • gcloud compute project-info describe でIN_USE_ADDRESSESクォータを確認
  • gcloud compute addresses list --filter='status=RESERVED' で未使用の静的IPを確認
  • リージョン別のIP使用状況をConsole > VPC > IP addressesで確認
  • gcloud compute instances list --filter='networkInterfaces[].accessConfigs[].natIP:*' で外部IP付きインスタンスを一覧
プリエンプティブルインスタンスの強制停止
想定される原因
  • GCEがリソースを回収するためプリエンプションが発生した
  • 24時間の最大稼働時間制限に達した
  • ゾーン内のリソース需要が増加し回収対象になった
  • 特定のマシンタイプのSpot VM供給が不足
確認手順
  • gcloud compute operations list --filter='operationType=compute.instances.preempted' でプリエンプション履歴確認
  • Cloud Monitoring のpreemption回数メトリクスを確認
  • インスタンスの稼働時間が24時間に近いか確認
  • Audit Log でプリエンプションイベントのタイムスタンプを確認
メタデータサーバーへのアクセス失敗
想定される原因
  • カスタムルーティングでメタデータサーバーへのルートが削除されている
  • iptablesルールがメタデータサーバーへのアクセスをブロック
  • ネットワークインターフェースの設定が不正
  • Docker/コンテナ内からのメタデータアクセスが遮断されている
確認手順
  • curl -H 'Metadata-Flavor: Google' http://169.254.169.254/ でアクセス可能か確認
  • ip route show でメタデータサーバーへのルートが存在するか確認
  • iptables -L -n でメタデータIP宛のルールを確認
  • networkInterfaces の設定を gcloud compute instances describe で確認
  • Docker内の場合はホストネットワークモードか確認
ヘルスチェック失敗によるインスタンスグループからの除外
想定される原因
  • アプリケーションがヘルスチェックパスで正常レスポンスを返していない
  • ヘルスチェックのポート/パスの設定とアプリケーションの設定が不一致
  • アプリケーションの起動に時間がかかりヘルスチェック間隔内に応答できない
  • ファイアウォールがヘルスチェックのソースIP(35.191.0.0/16, 130.211.0.0/22)をブロック
確認手順
  • gcloud compute health-checks describe [hc_name] で設定内容を確認
  • インスタンス内からcurl localhost:[port][path] でアプリ応答を確認
  • ファイアウォールルールで35.191.0.0/16と130.211.0.0/22からの通信が許可されているか確認
  • Cloud Console > Network Services > Load Balancing > Backend で各インスタンスのヘルス状態確認
  • アプリケーションログでエラーや起動遅延を確認
Windows RDP接続不可
想定される原因
  • ファイアウォールルールでRDP(ポート3389)が許可されていない
  • Windowsパスワードがリセットされていない/期限切れ
  • インスタンスのWindowsサービスが正常に起動していない
  • 外部IPが割り当てられていない
確認手順
  • gcloud compute firewall-rules list --filter='allowed[].ports:3389' でRDP許可ルールを確認
  • gcloud compute reset-windows-password [instance] でパスワードを確認/リセット
  • シリアルコンソールでWindows起動状態を確認
  • 外部IPの割り当て状態を確認
  • Cloud Console > Compute Engine > VM instances でインスタンスステータスを確認
カスタムイメージからのインスタンス作成失敗
想定される原因
  • 指定したカスタムイメージが削除されているまたはプロジェクトが異なる
  • イメージの共有設定(IAM)で他プロジェクトからのアクセスが許可されていない
  • イメージがdeprecated/obsoleteに設定されている
  • イメージのディスクサイズがインスタンスのブートディスクサイズより大きい
確認手順
  • gcloud compute images list --project=[project] で利用可能なイメージを確認
  • gcloud compute images describe [image] でイメージの状態(deprecated等)を確認
  • イメージのIAMポリシーで必要なプロジェクト/サービスアカウントにアクセス権があるか確認
  • イメージファミリーを使用している場合は最新イメージの状態を確認
  • gcloud compute images list --filter='family=[family_name]' でファミリー内のイメージ一覧を確認
Pod がCrashLoopBackOffで起動失敗
想定される原因
  • コンテナのメモリ使用量がresources.limits.memoryを超過しOOM Killedになった
  • アプリケーションの起動コマンドやentrypointが不正
  • 必要な環境変数やConfigMap/Secretがマウントされていない
  • 依存サービス(DB等)への接続に失敗してアプリがクラッシュ
確認手順
  • kubectl describe pod [pod_name] でEvents/State/Last Stateを確認
  • kubectl logs [pod_name] --previous で前回クラッシュ時のログを確認
  • kubectl get pod [pod_name] -o yaml でresources limitsとrequestsを確認
  • kubectl top pod でリアルタイムのリソース使用量を確認
  • kubectl get events --sort-by='.lastTimestamp' でクラスタイベントを確認
ノードプールのスケールアップ失敗
想定される原因
  • プロジェクトのCPU/メモリクォータがリージョンで上限に達している
  • ノードプールの最大ノード数設定に達している
  • 指定したマシンタイプがゾーンで利用不可
  • IPアドレス枯渇によりノードにIPが割り当てられない
確認手順
  • kubectl describe pod [pod_name] でScheduling失敗の理由を確認
  • gcloud container clusters describe [cluster] でautoscaling設定を確認
  • gcloud compute project-info describe でCPU/IPクォータを確認
  • kubectl get events --field-selector reason=FailedScaleUp でスケール失敗イベントを確認
  • Cloud Console > Kubernetes Engine > Cluster > Nodes でノード状態を確認
Ingress の外部IPが割り当てられない
想定される原因
  • Ingressの設定(annotations等)に誤りがある
  • ロードバランサー関連のクォータ(forwarding rules等)が上限
  • BackendServiceのヘルスチェック設定とPodのポートが不一致
  • GKE Ingress Controllerの権限不足
確認手順
  • kubectl describe ingress [ingress_name] でEventsのエラーメッセージを確認
  • kubectl get ingress [ingress_name] -o yaml でannotationsとrulesを確認
  • kubectl get svc でbackend ServiceのtypeとportMappingを確認
  • gcloud compute forwarding-rules list でLBリソースの作成状況を確認
  • Cloud Console > Network Services > Load Balancing で詳細なエラーを確認
ImagePullBackOffでコンテナイメージ取得失敗
想定される原因
  • Artifact Registry/GCRへの認証情報(imagePullSecrets)が設定されていない
  • ノードのサービスアカウントにArtifact Registry読み取り権限がない
  • イメージのタグまたはダイジェストが存在しない
  • プライベートレジストリのURLが間違っている
確認手順
  • kubectl describe pod [pod_name] でイメージ取得エラーの詳細を確認
  • kubectl get pod [pod_name] -o yaml でimage URLとimagePullSecretsを確認
  • gcloud artifacts docker images list [repo_url] でイメージの存在を確認
  • ノードのサービスアカウントのIAMロール確認(artifactregistry.reader)
  • kubectl get secrets でimagePullSecretの存在を確認
PersistentVolumeClaim バインド失敗
想定される原因
  • 指定したStorageClassが存在しないまたは設定が不正
  • PersistentDiskのクォータが上限に達している
  • PVCのアクセスモード(ReadWriteMany等)がPDでサポートされていない
  • ゾーン制約によりPodのスケジュールされたゾーンでボリュームが作成できない
確認手順
  • kubectl describe pvc [pvc_name] でEvents内のエラーを確認
  • kubectl get storageclass で利用可能なStorageClassを確認
  • gcloud compute disks list でPDのクォータ使用状況を確認
  • kubectl get pv で既存のPersistentVolumeの状態を確認
  • PVCとPodのゾーン制約が一致しているか確認
DNS解決失敗(kube-dns/CoreDNS障害)
想定される原因
  • kube-dns/CoreDNS Podが正常に動作していない
  • NetworkPolicyがDNSトラフィック(UDP/TCP 53)をブロックしている
  • サービス名の指定が間違っている(namespace含む完全修飾名の問題)
  • ノードのDNS設定が不正またはクラスタDNSのConfigMapが破損
確認手順
  • kubectl get pods -n kube-system -l k8s-app=kube-dns でDNS Podの状態確認
  • kubectl exec [pod] -- nslookup kubernetes.default でクラスタ内DNS動作確認
  • kubectl logs -n kube-system [coredns-pod] でDNSサーバーのログ確認
  • kubectl get networkpolicy --all-namespaces でDNSブロックの可能性確認
  • kubectl get configmap coredns -n kube-system -o yaml で設定確認
ノードのNotReady状態
想定される原因
  • ノードのディスク使用量がeviction thresholdを超えた
  • kubeletがOOMまたは高負荷で応答不能になっている
  • ノードのネットワーク接続が断たれている
  • ノードのメモリ不足でシステムプロセスが正常動作していない
確認手順
  • kubectl describe node [node_name] でConditionsとEventsを確認
  • kubectl top nodes でノードのリソース使用率を確認
  • gcloud compute ssh [node] -- df -h でディスク使用量を確認
  • gcloud compute ssh [node] -- journalctl -u kubelet でkubeletログを確認
  • kubectl get pods --field-selector spec.nodeName=[node_name] でノード上のPodを確認
GKEクラスタアップグレード中のサービス中断
想定される原因
  • PodDisruptionBudgetが厳しすぎてドレインが完了しない
  • Podのterminationに時間がかかりタイムアウト
  • DaemonSetやsystem Podがノードのドレインをブロック
  • maxSurge/maxUnavailableの設定によりアップグレードが遅延
確認手順
  • kubectl get pdb --all-namespaces でPDBの設定を確認
  • gcloud container operations list --filter='operationType=UPGRADE_NODES' で進捗確認
  • kubectl get nodes でノードのバージョンとステータスを確認
  • kubectl get pods --field-selector status.phase!=Running でpending/evicting中のPodを確認
  • Cloud Console > Kubernetes Engine > Cluster > Upgrade でアップグレード状態確認
Workload Identity認証エラー
想定される原因
  • KSA(Kubernetes Service Account)とGSA(Google Service Account)のバインディングが未設定
  • GSAにiam.workloadIdentityUser ロールが付与されていない
  • Pod specでserviceAccountNameが正しく指定されていない
  • クラスタまたはノードプールでWorkload Identityが有効化されていない
確認手順
  • kubectl describe serviceaccount [ksa] -n [namespace] でアノテーションを確認
  • gcloud iam service-accounts get-iam-policy [gsa_email] でバインディングを確認
  • kubectl get pod [pod] -o yaml でserviceAccountNameを確認
  • gcloud container clusters describe [cluster] でworkloadIdentityConfigを確認
  • Pod内から curl metadata.google.internal/computeMetadata/v1/instance/service-accounts/ で確認
Pod間通信のネットワークタイムアウト
想定される原因
  • NetworkPolicyがPod間通信をブロックしている
  • 対象ServiceのselectorとPodのlabelが一致していない
  • kube-proxyのiptablesルールが破損している
  • Pod CIDRの枯渇により新規PodにIPが割り当てられていない
確認手順
  • kubectl get networkpolicy -n [namespace] でNetworkPolicyの存在を確認
  • kubectl get endpoints [service_name] でServiceに紐づくPod IPを確認
  • kubectl exec [pod] -- wget -qO- [service_name]:[port] で接続テスト
  • kubectl describe svc [service_name] でselectorとportsを確認
  • kubectl get pods -o wide で各PodのIPアドレスとノードを確認
HPA(Horizontal Pod Autoscaler)が動作しない
想定される原因
  • metrics-serverが正常に動作していないまたは未インストール
  • PodにCPU/メモリのresource requestsが設定されていない
  • カスタムメトリクスの場合、Stackdriver Adapterが正しく設定されていない
  • HPAのtargetCPUUtilizationPercentageの計算にrequestsが必要
確認手順
  • kubectl get hpa [hpa_name] で現在のメトリクス値とステータスを確認
  • kubectl describe hpa [hpa_name] でConditionsとEventsを確認
  • kubectl top pods でメトリクス取得が可能か確認
  • kubectl get deployment [deploy] -o yaml でresources.requestsの設定を確認
  • kubectl get pods -n kube-system | grep metrics-server でmetrics-serverの状態確認
GKE APIサーバー接続エラー(kubectl)
想定される原因
  • kubeconfigの認証情報(トークン)が期限切れ
  • クラスタのAPIサーバーへのネットワークアクセスがブロックされている
  • プライベートクラスタでマスターアクセス認証ネットワークが未設定
  • gcloudの認証情報が期限切れ
確認手順
  • gcloud auth list で現在の認証状態を確認
  • kubectl config current-context で接続先クラスタを確認
  • gcloud container clusters describe [cluster] でmasterAuthorizedNetworksConfigを確認
  • kubectl cluster-info でAPIサーバーの到達性を確認
  • gcloud container clusters get-credentials [cluster] で認証情報を再取得
コールドスタートによるレスポンス遅延
想定される原因
  • min-instancesが0に設定されておりトラフィックなし時にインスタンスが0になる
  • コンテナイメージのサイズが大きく起動に時間がかかる
  • アプリケーションの初期化処理(DB接続プール作成等)が重い
  • 依存ライブラリのロードに時間がかかる(Java/Python等)
確認手順
  • Cloud Console > Cloud Run > Service > Metrics でRequest Latencyのスパイクを確認
  • Cloud Logging でcontainer startup timeを確認
  • コンテナイメージサイズを確認: gcloud artifacts docker images list --include-tags
  • min-instances設定を確認: gcloud run services describe [service]
  • Cloud Trace でコールドスタートリクエストのトレースを確認
リクエストタイムアウト(504 Gateway Timeout)
想定される原因
  • リクエスト処理時間がサービスのtimeout設定(デフォルト300秒)を超過
  • バックエンドのDB/APIへの接続が遅延または応答なし
  • コンテナのCPU/メモリ不足で処理が遅延
  • コンカレンシー設定が高すぎてリクエストが処理待ちで滞留
確認手順
  • Cloud Run のtimeout設定を確認: gcloud run services describe [service]
  • Cloud Logging でリクエストの処理時間分布を確認
  • Cloud Monitoring でインスタンスのCPU使用率を確認
  • Cloud Trace で遅いリクエストのボトルネクを特定
  • Cloud Run メトリクスのrequest_latencies でp95/p99を確認
コンテナのメモリ超過によるクラッシュ
想定される原因
  • アプリケーションのメモリリークが発生している
  • memory limitの設定がワークロードに対して不足
  • 並行リクエスト数が多くリクエストあたりのメモリ使用が積算
  • 大きなファイルやレスポンスをメモリ上に保持している
確認手順
  • Cloud Run > Metrics > Container memory utilization でメモリ推移を確認
  • Cloud Logging で 'memory limit exceeded' ログを検索
  • gcloud run services describe [service] でmemory limitを確認
  • Cloud Run のcontainer/instance_countとmemoryの相関を確認
  • concurrency設定と1リクエストあたりのメモリ消費量を見積もり
VPCコネクタ経由の接続エラー
想定される原因
  • VPCコネクタのスループット/接続数が上限に達している
  • コネクタのサブネットIPが枯渇している
  • ターゲットのプライベートIPが所属するVPCとコネクタのVPCが異なる
  • ファイアウォールルールがコネクタからの通信をブロック
確認手順
  • gcloud compute networks vpc-access connectors describe [connector] で状態確認
  • Cloud Monitoring でconnector/sent_bytes_count, received_bytes_countを確認
  • コネクタのインスタンス数とスループットメトリクスを確認
  • VPCのファイアウォールルールでコネクタのIP範囲からの通信が許可されているか確認
  • gcloud run services describe [service] --format='value(spec.template.metadata.annotations)' でegress設定確認
デプロイ失敗(ヘルスチェック未通過)
想定される原因
  • コンテナがPORT環境変数で指定されたポートをリッスンしていない
  • アプリケーションの起動に失敗している(設定エラー、依存関係不足等)
  • 起動に時間がかかりstartup timeout(デフォルト240秒)を超過
  • コンテナのCMD/ENTRYPOINTが正しくない
確認手順
  • gcloud run revisions describe [revision] で失敗理由を確認
  • Cloud Logging でリビジョンのコンテナログを確認
  • ローカルでdocker run -p 8080:8080 -e PORT=8080 でコンテナを起動テスト
  • Dockerfileの EXPOSE とCMDが正しいか確認
  • Cloud Run のポート設定とアプリのリッスンポートが一致しているか確認
認証エラー(IAM invoker権限不足)
想定される原因
  • 呼び出し元にCloud Run Invoker(roles/run.invoker)ロールが付与されていない
  • サービスがallUsers公開されておらず認証トークンが必要
  • IDトークンのaudience(aud)がサービスのURLと一致しない
  • サービスアカウント間呼び出しでIDトークンではなくアクセストークンを使用している
確認手順
  • gcloud run services get-iam-policy [service] で許可されたメンバーを確認
  • 呼び出し時のAuthorizationヘッダーにIDトークンが含まれているか確認
  • トークンのaudience claimがサービスURLと一致しているか確認
  • gcloud auth print-identity-token --audiences=[service_url] でトークン生成テスト
  • Cloud Audit Logs でアクセス拒否の詳細を確認
Cloud SQLへの接続プール枯渇
想定される原因
  • Cloud Runのインスタンス数 × concurrency × 接続数がCloud SQLの最大接続数を超過
  • コネクションプールの設定がCloud Runのスケーリングを考慮していない
  • コネクションリークが発生し接続が返却されない
  • Cloud SQL Auth Proxyの接続数上限に達している
確認手順
  • Cloud SQL > Monitoring > Connections でアクティブ接続数を確認
  • アプリケーションのコネクションプール設定(max_pool_size等)を確認
  • Cloud Run のインスタンス数とconcurrency設定を確認
  • gcloud sql instances describe [instance] で max_connections を確認
  • Cloud Logging で接続エラーの頻度と発生タイミングを確認
リビジョンのトラフィック分割設定エラー
想定される原因
  • 指定したリビジョンが存在しないまたはRetiredステータス
  • トラフィック配分の合計が100%にならない
  • ターゲットリビジョンのヘルスチェックが通過していない
  • リビジョンの最大保持数を超えてGCされたリビジョンを指定
確認手順
  • gcloud run revisions list --service=[service] で利用可能なリビジョンを確認
  • gcloud run services describe [service] でcurrent traffic splitを確認
  • gcloud run revisions describe [revision] でステータスを確認
  • Cloud Console > Cloud Run > Service > Revisions でリビジョン一覧確認
  • 各リビジョンのServing StatusがActiveか確認
Secret Manager参照エラー
想定される原因
  • Cloud Runのサービスアカウントにsecretmanager.secretAccessorロールがない
  • シークレット名またはバージョンの指定が間違っている
  • シークレットが別プロジェクトにあり cross-project アクセスが未設定
  • シークレットのバージョンが無効化(disabled)されている
確認手順
  • gcloud secrets describe [secret_name] でシークレットの存在を確認
  • gcloud secrets versions list [secret_name] でバージョン状態を確認
  • Cloud Runサービスのサービスアカウントを確認: gcloud run services describe [service]
  • サービスアカウントのIAMバインディングでsecretAccessorロールを確認
  • gcloud secrets get-iam-policy [secret_name] でアクセス許可を確認
同時リクエスト数超過によるリクエスト拒否
想定される原因
  • max-instancesの上限に達し全インスタンスがconcurrency上限
  • 急激なトラフィック増加にスケールアウトが追いつかない
  • concurrency設定が低すぎてインスタンスあたりの処理能力が制限
  • CPUスロットリング(CPU always allocated でない場合)でレスポンスが遅延
確認手順
  • Cloud Run > Metrics > Container instance count で最大値に達しているか確認
  • Cloud Run > Metrics > Request count でリクエスト数の推移を確認
  • gcloud run services describe [service] でmax-instancesとconcurrency設定を確認
  • Cloud Monitoring で429レスポンスの発生頻度を確認
  • Cloud Run > Metrics > Billable instance time でCPU allocationモードを確認
カスタムドメインのSSL証明書プロビジョニング失敗
想定される原因
  • DNSレコード(CNAME/A/AAAA)がCloud Runの指定値に設定されていない
  • DNS伝播に時間がかかっている(最大24-48時間)
  • ドメインの所有権確認が完了していない
  • CAA(Certificate Authority Authorization)レコードがGoogle CAを許可していない
確認手順
  • gcloud run domain-mappings describe --domain=[domain] で状態を確認
  • dig [domain] CNAME/A/AAAA でDNSレコードが正しく設定されているか確認
  • gcloud run domain-mappings list で全ドメインマッピングのステータスを確認
  • DNS CAAレコードが設定されている場合 pki.goog が含まれているか確認
  • Cloud Console > Cloud Run > Domain Mappings で証明書状態を確認
Cloud Run Jobsの実行タイムアウト
想定される原因
  • タスクの処理時間がtask-timeout設定を超過
  • 外部APIやDBへの接続待ちでタスクが停滞
  • 処理するデータ量が想定より大きく時間がかかる
  • メモリ不足でスワップが発生し処理速度が低下
確認手順
  • gcloud run jobs describe [job] でtask-timeoutとmax-retriesを確認
  • gcloud run jobs executions describe [execution] で失敗タスクの詳細を確認
  • Cloud Logging でジョブ実行中のログを確認
  • Cloud Monitoring でジョブのCPU/メモリ使用率を確認
  • 処理対象データのサイズと処理時間の関係を分析
最大接続数超過エラー
想定される原因
  • アプリケーションのコネクションプールが適切に設定されていない
  • 接続リーク(closeされないコネクション)が蓄積している
  • Cloud SQLインスタンスのティアに対してmax_connectionsが低い
  • 複数サービスからの同時接続数がインスタンスの容量を超過
確認手順
  • Cloud SQL > Monitoring > Connections Active で現在の接続数を確認
  • SHOW PROCESSLIST(MySQL)/ SELECT * FROM pg_stat_activity(PostgreSQL)で接続詳細確認
  • Cloud SQL のフラグ設定でmax_connectionsの値を確認
  • アプリケーション側のコネクションプール設定を確認
  • Cloud SQL Proxy経由の接続数を確認
レプリケーション遅延
想定される原因
  • プライマリでの書き込み負荷が高くレプリカの適用が追いつかない
  • レプリカのインスタンスサイズがプライマリより小さい
  • 大量のDDL操作やバルクインサートが実行されている
  • ネットワーク帯域の制限(クロスリージョンレプリカの場合)
確認手順
  • Cloud SQL > Monitoring > Replication Lag でラグの推移を確認
  • SHOW SLAVE STATUS(MySQL)/ SELECT * FROM pg_stat_replication(PostgreSQL)で詳細確認
  • プライマリのwrite ops/secとレプリカのapply rateを比較
  • レプリカのCPU/メモリ/ディスクI/Oを確認
  • 実行中の長時間クエリがレプリカの適用をブロックしていないか確認
ストレージ自動拡張による一時的な性能低下
想定される原因
  • ストレージ使用量が急増し自動拡張がトリガーされた
  • バイナリログ/WALの蓄積でストレージを消費
  • 一時テーブルやソートスペースが大量のディスクを使用
  • 自動拡張の上限に達してこれ以上拡張できない
確認手順
  • Cloud SQL > Monitoring > Storage Usage で使用量推移を確認
  • gcloud sql instances describe [instance] で storageAutoResizeLimit を確認
  • SHOW BINARY LOGS(MySQL)でバイナリログサイズを確認
  • pg_database_size()(PostgreSQL)でデータベースサイズを確認
  • Cloud Monitoring の cloudsql.googleapis.com/database/disk/utilization を確認
Cloud SQL Auth Proxy接続エラー
想定される原因
  • インスタンス接続名(project:region:instance)が間違っている
  • Cloud SQL Auth Proxyのサービスアカウントにcloudsql.client ロールがない
  • Cloud SQL Admin API が有効化されていない
  • ネットワーク接続の問題(VPC、ファイアウォール等)
確認手順
  • gcloud sql instances describe [instance] --format='value(connectionName)' で接続名を確認
  • サービスアカウントにcloudsql.clientロールがあるか確認
  • gcloud services list --enabled | grep sqladmin でAPI有効化を確認
  • Cloud SQL Auth Proxyのログでエラー詳細を確認
  • ネットワーク設定(Private IP使用時のVPC Peering等)を確認
スロークエリによるCPU高負荷
想定される原因
  • インデックスが欠落しフルテーブルスキャンが発生
  • 不適切なJOINやサブクエリによるクエリ計画の劣化
  • テーブルロック競合で他クエリがブロックされている
  • 統計情報が古くオプティマイザが最適な計画を選択できない
確認手順
  • Cloud SQL > Query Insights でスロークエリを特定
  • EXPLAIN ANALYZE でクエリの実行計画を確認
  • Cloud SQL > Monitoring > CPU utilization で負荷推移を確認
  • SHOW ENGINE INNODB STATUS(MySQL)/ pg_stat_statements(PostgreSQL)で統計確認
  • Cloud SQL のスロークエリログを有効化して分析
フェイルオーバー後のアプリケーション接続断
想定される原因
  • 高可用性フェイルオーバーにより接続先IPが変更
  • アプリケーションのコネクションプールがstaleコネクションを保持
  • DNSキャッシュにより古いIPに接続し続けている
  • フェイルオーバー中の一時的なダウンタイム(通常60秒以内)
確認手順
  • Cloud SQL > Operations でフェイルオーバーイベントを確認
  • gcloud sql instances describe [instance] で現在のIP/状態を確認
  • アプリケーションのコネクションプール設定(validationQuery等)を確認
  • Cloud SQL Auth Proxyが自動再接続しているか確認
  • Cloud Monitoring のuptime メトリクスでダウンタイムを確認
SSL/TLS接続強制時の認証エラー
想定される原因
  • Cloud SQLインスタンスでSSLが必須設定だがクライアントがSSL未使用
  • サーバーCA証明書がダウンロードされていないまたは期限切れ
  • クライアント証明書が無効化されているまたは期限切れ
  • 接続文字列にsslmode=require等のパラメータが指定されていない
確認手順
  • gcloud sql instances describe [instance] --format='value(settings.ipConfiguration.requireSsl)' でSSL強制を確認
  • gcloud sql ssl client-certs list -i [instance] でクライアント証明書状態を確認
  • 接続文字列/DSNにSSL関連パラメータが含まれているか確認
  • サーバーCA証明書の有効期限を確認
  • Cloud SQL のconnector(Auth Proxy等)使用時はSSLが自動適用か確認
自動バックアップ失敗
想定される原因
  • バックアップ実行中にインスタンスの負荷が高すぎる
  • バックアップストレージのクォータ/予算超過
  • ポイントインタイムリカバリのバイナリログ/WALが破損
  • インスタンスが停止中またはメンテナンス中
確認手順
  • gcloud sql backups list -i [instance] で過去のバックアップ状態を確認
  • Cloud SQL > Backups でエラーメッセージの詳細を確認
  • gcloud sql instances describe [instance] --format='value(settings.backupConfiguration)' で設定確認
  • Cloud Monitoring でバックアップ時間帯のインスタンス負荷を確認
  • バックアップストレージの使用量と制限を確認
プライベートIP接続設定エラー
想定される原因
  • Private Service Access(VPC peering)が設定されていない
  • 割り当てるIP範囲が不足または重複している
  • 接続元のVMやサービスが別のVPCネットワークに所属
  • ファイアウォールルールがCloud SQLのプライベートIPへのアクセスをブロック
確認手順
  • gcloud compute networks peerings list で VPC peering状態を確認
  • gcloud services vpc-peerings list --network=[network] でPrivate Service Access確認
  • gcloud sql instances describe [instance] --format='value(ipAddresses)' でプライベートIP確認
  • 接続元VMのVPCネットワークとCloud SQLのVPCが一致するか確認
  • gcloud compute routes list でプライベートIP範囲へのルートを確認
認可済みネットワークからの接続拒否
想定される原因
  • 接続元のIPアドレスがCloud SQLの認可済みネットワークに含まれていない
  • 接続元のIPがNAT/プロキシにより変わっている
  • 認可済みネットワークのCIDR表記が間違っている
  • IPv6アドレスからの接続で認可設定がIPv4のみ
確認手順
  • gcloud sql instances describe [instance] --format='value(settings.ipConfiguration.authorizedNetworks)' で許可IPを確認
  • 接続元の外部IPを確認(curl ifconfig.me 等)
  • Cloud Audit Logsで接続拒否ログを確認
  • 認可済みネットワークのCIDR表記が正しいか確認
  • Cloud SQL Auth Proxyの使用を検討(認可済みネットワーク不要)
メンテナンスウィンドウでの予期しない再起動
想定される原因
  • Googleによる定期メンテナンス(パッチ適用)がメンテナンスウィンドウ内で実行
  • メンテナンスウィンドウが設定されておらずランダムなタイミングで実行
  • メンテナンス拒否期間(deny maintenance period)が設定されていない
  • マイナーバージョンの自動アップデートが適用
確認手順
  • gcloud sql instances describe [instance] --format='value(settings.maintenanceWindow)' でウィンドウ確認
  • Cloud SQL > Maintenance で次回メンテナンスのスケジュールを確認
  • Cloud SQL > Operations でmaintenance タイプの操作履歴を確認
  • gcloud sql instances describe [instance] --format='value(settings.denyMaintenancePeriod)' で拒否期間確認
  • 通知設定でメンテナンス予告メールが届いているか確認
データベースフラグ設定によるインスタンス再起動ループ
想定される原因
  • 設定したフラグの値が有効範囲外
  • 複数のフラグ間で互換性のない組み合わせを設定
  • メモリ関連フラグがインスタンスの実メモリを超過
  • バージョン固有のフラグを互換性のないバージョンで使用
確認手順
  • gcloud sql instances describe [instance] --format='value(settings.databaseFlags)' で現在のフラグを確認
  • Cloud SQL > Operations で最近のフラグ変更操作を確認
  • Cloud Logging でインスタンス起動時のエラーログを確認
  • gcloud sql flags list --database-version=[version] で有効なフラグと範囲を確認
  • Cloud SQL > Instance details でインスタンスの状態を確認
403 Access Denied(バケットアクセス拒否)
想定される原因
  • サービスアカウントまたはユーザーにStorage IAMロールが付与されていない
  • Uniform bucket-level accessが有効でACLが無視されている
  • VPC Service Controlsのペリメータでアクセスがブロック
  • Organization PolicyでpublicAccessPreventionが有効
確認手順
  • gsutil iam get gs://[bucket] でバケットのIAMポリシーを確認
  • gcloud projects get-iam-policy [project] --filter='bindings.role:storage' でプロジェクトレベルのIAMを確認
  • バケットのUniform bucket-level access設定を確認
  • VPC Service Controlsのペリメータでバケットが保護されていないか確認
  • Cloud Audit Logs でアクセス拒否の詳細を確認
大容量ファイルアップロードのタイムアウト
想定される原因
  • ネットワーク帯域が不足し大容量ファイルの転送に時間がかかりすぎる
  • Resumable uploadのセッションが期限切れ(7日間有効)
  • クライアント側のタイムアウト設定が短すぎる
  • プロキシやファイアウォールが長時間接続を切断
確認手順
  • gsutil -D cp でデバッグモードを有効にしてエラー詳細を確認
  • ネットワーク帯域をiperf等で計測
  • アップロード先のバケットリージョンと接続元の距離を確認
  • プロキシ/ファイアウォールのタイムアウト設定を確認
  • gsutil のretry設定を確認
429 Too Many Requests(レートリミット)
想定される原因
  • 単一バケットへのリクエストレートが上限(5000 write/s, 5000 read/s)を超過
  • 特定のオブジェクトプレフィックスへのアクセスが集中(ホットスポット)
  • バースト的なアクセスパターンでレートリミットがトリガー
  • バケットの帯域幅制限に達した
確認手順
  • Cloud Monitoring でstorage.googleapis.com/api/request_count を確認
  • リクエストパターンを分析して特定プレフィックスへの集中を確認
  • Cloud Logging で429レスポンスの頻度とパターンを確認
  • オブジェクト名のプレフィックス分布を確認(シーケンシャル命名はNG)
  • バケットのロケーションタイプ(single-region vs multi-region)を確認
署名付きURL(Signed URL)の期限切れ・認証エラー
想定される原因
  • 署名付きURLの有効期限が切れている
  • URLの署名に使用したサービスアカウントキーがローテーションされた
  • URLパラメータが改ざんされている
  • 署名に使用したサービスアカウントにオブジェクトへのアクセス権がない
確認手順
  • 署名付きURLの有効期限パラメータを確認
  • 署名に使用したサービスアカウントの状態とキーの有効性を確認
  • URLのクエリパラメータが正しいか確認(エンコーディング含む)
  • サービスアカウントにstorage.objects.get/create権限があるか確認
  • V4署名の場合は最大7日間の有効期限制限を確認
ライフサイクルルールによる意図しないオブジェクト削除
想定される原因
  • ライフサイクルルールの条件が意図より広範囲のオブジェクトにマッチ
  • Age条件の日数設定が想定より短い
  • ライフサイクルルールの適用範囲(prefix)が正しくない
  • バージョニング有効時にnoncurrentバージョンの削除ルールが作動
確認手順
  • gsutil lifecycle get gs://[bucket] でライフサイクルルールを確認
  • Cloud Audit Logs でGCS.objects.deleteのログを確認(methodName=storage.objects.delete)
  • バケットのバージョニング設定を確認: gsutil versioning get gs://[bucket]
  • ライフサイクルルールのconditionとmatchPrefix/matchSuffixを確認
  • オブジェクトのCreated日時からライフサイクルルールの適用タイミングを逆算
CORSエラーによるブラウザからのアクセス失敗
想定される原因
  • バケットにCORS設定が行われていない
  • CORS設定のOriginがリクエスト元のドメインと一致しない
  • 許可するHTTPメソッドまたはヘッダーが不足
  • CORSのmaxAgeSecが短すぎてプリフライトが頻発
確認手順
  • gsutil cors get gs://[bucket] で現在のCORS設定を確認
  • ブラウザのDevToolsでNetworkタブのプリフライト(OPTIONS)リクエストを確認
  • レスポンスヘッダーにAccess-Control-Allow-Originが含まれているか確認
  • リクエスト元のOrigin(プロトコル+ドメイン+ポート)がCORS設定に含まれるか確認
  • リクエストのMethodとHeadersがCORS設定で許可されているか確認
オブジェクト暗号化キー(CMEK)エラー
想定される原因
  • Cloud Storageサービスアカウントにcryptoキーの使用権限がない
  • CMEKで使用するKMSキーが無効化または破棄されている
  • KMSキーのリージョンとバケットのロケーションが異なる
  • KMSキーリングが存在しないまたはプロジェクトが異なる
確認手順
  • gsutil kms get gs://[bucket] でバケットのデフォルト暗号化キーを確認
  • gcloud kms keys describe [key] --keyring=[keyring] --location=[location] でキー状態を確認
  • Cloud Storage サービスアカウントのIAMロール確認(cloudkms.cryptoKeyEncrypterDecrypter)
  • キーのバージョンが有効(ENABLED)か確認
  • KMSキーとバケットのリージョンの一致を確認
gsutil/gcloud storage の並列転送エラー
想定される原因
  • ネットワーク帯域が不安定または不足
  • 並列スレッド数が多すぎてOS側の接続制限に達している
  • プロキシまたはファイアウォールが多数の同時接続を制限
  • ローカルのファイルシステムI/Oがボトルネック
確認手順
  • gsutil -d でデバッグモードを有効にしてエラー詳細を確認
  • .boto ファイルまたは環境変数で並列転送設定を確認
  • ネットワーク帯域とレイテンシを計測
  • OS のファイルディスクリプタ制限(ulimit -n)を確認
  • Cloud Storage のリージョンと接続元の距離を確認
バケット作成時のネーミング/リージョンエラー
想定される原因
  • バケット名が既に他のプロジェクトで使用されている(グローバルユニーク)
  • バケット名がNaming conventionに違反(大文字、アンダースコア、長さ等)
  • 指定したリージョン/マルチリージョンが無効
  • Organization Policyでバケット作成先リージョンが制限されている
確認手順
  • gsutil ls gs://[bucket_name] でバケットの存在を確認
  • バケット名がRFC規則に準拠しているか確認(小文字、ハイフン、3-63文字)
  • 利用可能なリージョン一覧を確認: gsutil ls -L gs:// で既存バケットの場所を参照
  • Organization PolicyのgeoRestrictionを確認
  • プロジェクトのバケット数制限を確認
公開アクセス設定のセキュリティ警告
想定される原因
  • allUsersまたはallAuthenticatedUsersにIAMバインディングが設定されている
  • ACLでpublic-readが設定されている
  • Organization Policyのpublic access preventionが未設定
  • 開発時に一時的に公開した設定が残っている
確認手順
  • gsutil iam get gs://[bucket] でallUsers/allAuthenticatedUsersバインディングを確認
  • Security Command Center で公開バケットの検出結果を確認
  • gcloud org-policies describe storage.publicAccessPrevention で組織ポリシーを確認
  • gsutil ls -La gs://[bucket]/[object] でオブジェクトのACLを確認
  • Cloud Asset Inventory で公開設定のバケットを一括検索
オブジェクト一覧取得の遅延(大量オブジェクト)
想定される原因
  • バケット内のオブジェクト数が数百万以上で一覧取得に時間がかかる
  • プレフィックスを指定せずにバケット全体をリストしている
  • delimiterの使用によるサーバーサイド処理の負荷
  • フラットネームスペースで大量のオブジェクトがある場合のスキャンコスト
確認手順
  • gsutil du -s gs://[bucket] でバケット内のオブジェクト数を概算
  • リスト操作にprefixとdelimiterが適切に使用されているか確認
  • Cloud Monitoring でstorage.googleapis.com/api/request_countのlist操作を確認
  • Hierarchical namespace (HNS)が有効かどうか確認
  • gsutil ls の実行時間を計測
イベント通知(Pub/Sub)のメッセージ欠損
想定される原因
  • Cloud StorageサービスアカウントにPub/Sub Publisherロールがない
  • 通知先のPub/Subトピックが削除されているまたは別プロジェクト
  • Pub/Subサブスクリプションのackが遅れメッセージが再配信/期限切れ
  • 通知設定のイベントタイプフィルターが意図した操作にマッチしない
確認手順
  • gsutil notification list gs://[bucket] で通知設定を確認
  • Cloud StorageサービスアカウントのPub/Sub権限を確認
  • gcloud pubsub topics describe [topic] でトピックの存在を確認
  • gcloud pubsub subscriptions describe [subscription] でサブスクリプション状態確認
  • Cloud Monitoring でPub/Subの未配信メッセージ数を確認
関数デプロイ失敗(ビルドエラー)
想定される原因
  • package.json/requirements.txtの依存パッケージが解決できない
  • ソースコードにシンタックスエラーがある
  • ビルドタイムアウト(デフォルト60分)を超過する重い依存関係
  • エントリーポイント関数名がソースコードと不一致
確認手順
  • gcloud functions deploy の出力でビルドエラーの詳細を確認
  • Cloud Build > History でビルドログを確認
  • ローカルで依存パッケージのインストールが成功するか確認
  • エントリーポイント(--entry-point)とソースのexport関数名の一致を確認
  • ランタイムバージョンとパッケージの互換性を確認
関数実行タイムアウト
想定される原因
  • 外部APIやDB接続が遅延またはハングしている
  • 処理対象データが大きすぎて制限時間内に完了しない
  • コールドスタートによる初期化遅延が長い
  • 非同期処理が完了前にレスポンスを返してしまう
確認手順
  • gcloud functions describe [function] でtimeout設定を確認
  • Cloud Logging で実行時間のログを確認
  • Cloud Trace で処理のボトルネックを特定
  • 外部サービスの応答時間を確認
  • 関数のメモリ/CPU設定とワークロードの適合性を確認
メモリ不足によるクラッシュ
想定される原因
  • 処理中に大きなデータをメモリに展開している
  • メモリリークがリクエスト間で蓄積(グローバル変数の誤使用)
  • 画像/動画処理などメモリ集中型の処理
  • 割り当てメモリがワークロードに対して不足
確認手順
  • gcloud functions describe [function] --format='value(availableMemoryMb)' でメモリ設定確認
  • Cloud Monitoring のcloudfunctions.googleapis.com/function/user_memory_bytes を確認
  • Cloud Logging でOOMエラーの発生頻度を確認
  • ローカルでメモリプロファイリングを実行
  • グローバルスコープで大きなオブジェクトを保持していないか確認
Pub/Subトリガーのメッセージ重複処理
想定される原因
  • 関数の実行時間がPub/Subのack deadline(デフォルト10秒)を超過
  • 関数がエラーで終了しメッセージが再配信された
  • Pub/Subのat-least-once配信保証により正常時も重複が発生
  • 関数のインスタンスが処理完了前に終了した
確認手順
  • Cloud Logging でmessage IDごとの処理回数を確認
  • Pub/Subサブスクリプションのack deadline設定を確認
  • 関数の平均実行時間とack deadlineの比較
  • Cloud Monitoring でPub/Subの再配信メトリクスを確認
  • 関数のエラーレート(crashやtimeout)を確認
IAMインボーカー権限不足(403エラー)
想定される原因
  • 呼び出し元にCloud Functions Invokerロールが付与されていない
  • 関数がallUsers非公開で認証トークンが必要
  • 呼び出し時にIDトークンではなくアクセストークンを使用している
  • 2nd Genで --allow-unauthenticated が指定されていない
確認手順
  • gcloud functions get-iam-policy [function] で許可されたメンバーを確認
  • 呼び出し時のAuthorizationヘッダーを確認
  • 関数の認証設定を確認: gcloud functions describe [function] --format='value(httpsTrigger)'
  • Cloud Audit Logsでアクセス拒否の詳細を確認
  • 2nd Genの場合はCloud Run のIAMも確認
コールドスタートによる初回レイテンシ
想定される原因
  • インスタンスがスケールダウンした後の初回呼び出し
  • 依存パッケージの初回ロードに時間がかかる
  • グローバルスコープでの初期化処理(DB接続、SDK初期化等)が重い
  • コンテナイメージが大きく展開に時間がかかる
確認手順
  • Cloud Logging でfunction execution started のログからコールドスタートを検出
  • Cloud Monitoring のexecution_timesをcold/warmで分離して確認
  • Cloud Trace でコールドスタート時の初期化処理の内訳を確認
  • デプロイパッケージのサイズを確認
  • min-instances設定を確認
Cloud Storage トリガーのイベント欠損
想定される原因
  • トリガーの設定(バケット名、イベントタイプ)が正しくない
  • Eventarcのサービスアカウント権限が不足(2nd Gen)
  • バケットのnotification設定が削除されている(1st Gen)
  • 関数のリージョンとバケットのリージョンが異なる
確認手順
  • gcloud functions describe [function] でtrigger設定を確認
  • 1st Gen: gsutil notification list gs://[bucket] で通知設定を確認
  • 2nd Gen: gcloud eventarc triggers describe [trigger] でEventarcトリガーを確認
  • Cloud Logging でイベント配信のログを確認
  • Eventarcサービスアカウントの権限を確認
VPCコネクタ経由のエグレス接続エラー
想定される原因
  • VPCコネクタが作成されていないまたはREADY状態でない
  • コネクタのスループットが上限に達している
  • 関数のegress設定がALL_TRAFFICまたはPRIVATE_RANGES_ONLYに設定されていない
  • ターゲットのプライベートIPへのファイアウォールルールが不足
確認手順
  • gcloud compute networks vpc-access connectors describe [connector] で状態確認
  • gcloud functions describe [function] でvpcConnectorとegressSettings確認
  • コネクタのスループット/接続数メトリクスを確認
  • ターゲットへのファイアウォールルールを確認
  • コネクタのIPレンジとターゲットVPCのルーティングを確認
同時実行数制限によるリクエスト拒否
想定される原因
  • max-instances設定により関数のスケールアウトが制限されている
  • プロジェクト全体のCloud Functions同時実行クォータに達している
  • 急激なトラフィックバーストに対してスケールアウトが間に合わない
  • 各インスタンスの処理時間が長く回転率が低い
確認手順
  • gcloud functions describe [function] --format='value(maxInstances)' で設定確認
  • Cloud Monitoring でactive_instancesの推移とmax値を確認
  • GCPコンソール > Quotas でCloud Functionsのクォータを確認
  • Cloud Logging で429エラーの発生頻度を確認
  • 関数の平均実行時間と秒間リクエスト数からインスタンス必要数を計算
環境変数・シークレット参照エラー
想定される原因
  • デプロイ時に--set-env-varsで環境変数が設定されていない
  • Secret Managerのシークレットへのアクセス権限が不足
  • シークレットのバージョンが無効化されている
  • 環境変数名のタイポまたはケースミスマッチ
確認手順
  • gcloud functions describe [function] --format='value(environmentVariables)' で環境変数確認
  • gcloud functions describe [function] --format='value(secretEnvironmentVariables)' でシークレット設定確認
  • シークレットのバージョン状態を確認: gcloud secrets versions list [secret]
  • 関数のランタイムサービスアカウントのIAMロールを確認
  • ソースコード内で参照している環境変数名が設定と一致しているか確認
HTTPトリガーのCORSエラー
想定される原因
  • 関数内でCORSヘッダーを返していない
  • OPTIONSメソッド(プリフライト)のハンドリングが実装されていない
  • Access-Control-Allow-Originのオリジン指定が不正
  • レスポンスにAccess-Control-Allow-Methodsヘッダーが欠落
確認手順
  • 関数のソースコードでCORSヘッダー設定箇所を確認
  • curl -X OPTIONS [function_url] でプリフライトレスポンスを確認
  • ブラウザDevToolsのNetworkタブでOPTIONSリクエストのレスポンスを確認
  • レスポンスヘッダーにAccess-Control-Allow-Origin/Methods/Headersが含まれるか確認
  • Firebase Hostingのrewrite使用時はhosting側の設定も確認
Firestore/Realtimeトリガーの無限ループ
想定される原因
  • 関数がトリガー元のドキュメントに書き込んで再度トリガーされる
  • 更新処理が同じコレクション/パスの変更を引き起こす
  • 条件分岐が不十分でトリガーの終了条件がない
  • 複数の関数が相互にトリガーし合うチェーン
確認手順
  • Cloud Monitoring でfunction/execution_countの急激なスパイクを確認
  • Cloud Logging で同一ドキュメントへの連続書き込みログを確認
  • 関数のソースコードでトリガーパスと書き込みパスの関係を確認
  • 請求アラートでコスト急増を確認
  • 関数の実行回数/秒をモニタリング
502 Bad Gateway(バックエンド応答エラー)
想定される原因
  • すべてのバックエンドインスタンスがヘルスチェックに失敗している
  • バックエンドサービスのポート設定とアプリケーションのリッスンポートが不一致
  • バックエンドインスタンスのリソース枯渇(CPU/メモリ)で応答不可
  • バックエンドグループに有効なインスタンスが0台
確認手順
  • Cloud Console > Network Services > Load Balancing > Backend でヘルス状態を確認
  • gcloud compute backend-services get-health [bs_name] --global で各バックエンドの状態確認
  • gcloud compute health-checks describe [hc_name] でヘルスチェック設定を確認
  • バックエンドインスタンスにSSHして curl localhost:[port] で応答確認
  • Cloud Logging で502エラーの詳細ログ(statusDetails)を確認
SSL証明書のプロビジョニング失敗
想定される原因
  • ドメインのDNSがロードバランサーのIPを指していない
  • DNS伝播が完了していない
  • CAAレコードがGoogleのCAを許可していない
  • 証明書のドメイン数が上限(100ドメイン)を超過
確認手順
  • gcloud compute ssl-certificates describe [cert_name] で証明書状態を確認
  • dig [domain] A/AAAA でDNSがLBのIPを指しているか確認
  • gcloud compute forwarding-rules list でLBの外部IPを確認
  • dig [domain] CAA でCAAレコードの設定を確認
  • 証明書のdomainStatusでドメインごとの状態を確認
ロードバランサーのレイテンシ増大
想定される原因
  • バックエンドサーバーの処理遅延(アプリケーションレベル)
  • バックエンドサーバーのリソース不足(CPU/メモリ飽和)
  • ロードバランシングアルゴリズムが不適切で特定バックエンドに偏り
  • バックエンドのコネクション数が多すぎてキューイングが発生
確認手順
  • Cloud Monitoring でhttps/total_latencies とhttps/backend_latencies を比較
  • Cloud Logging でリクエストログのlatencyフィールドを分析
  • バックエンドインスタンスのCPU/メモリ使用率を確認
  • Cloud Trace でリクエストの詳細トレースを確認
  • バックエンドサービスのbalancing mode(UTILIZATION/RATE/CONNECTION)を確認
URL Map ルーティング設定ミス
想定される原因
  • URL Mapのhost ruleにリクエストのHostヘッダーが含まれていない
  • path ruleのパターンがリクエストパスにマッチしない
  • pathMatcherの設定がdefaultServiceしか定義されていない
  • ワイルドカードパターンの優先順位が意図通りでない
確認手順
  • gcloud compute url-maps describe [urlmap] で全ルールを確認
  • Cloud Logging のリクエストログでmatchedPathRuleフィールドを確認
  • gcloud compute url-maps validate [urlmap] でバリデーション
  • テストリクエストを送信してルーティング結果を確認
  • Host ヘッダーとpath ruleの組み合わせを手動で照合
Cloud Armor WAFによるリクエストブロック
想定される原因
  • Cloud Armorのセキュリティポリシールールがリクエストをブロック
  • IPアドレスベースのdenyリストに接続元IPが含まれている
  • WAFの事前設定ルール(XSS/SQLi検知)が誤検知を起こしている
  • レートリミットポリシーによるスロットリング
確認手順
  • Cloud Armor > Security Policies > [policy] > Logs でブロックされたリクエストを確認
  • Cloud Logging でsecurityPolicyNameとmatchedRuleを確認
  • gcloud compute security-policies describe [policy] でルール一覧を確認
  • ブロックされたリクエストのsource IP/User-Agent/パスを確認
  • Cloud Armor のpreview modeでルールの影響を事前確認
バックエンドサービスのドレイン中のリクエスト失敗
想定される原因
  • ローリングアップデート中にバックエンドが削除されリクエストが中断
  • Connection Drainingのタイムアウトが短すぎる
  • ロングポーリングやWebSocket接続がドレインタイムアウトを超過
  • Instance Groupのスケールダウンが急激
確認手順
  • gcloud compute backend-services describe [bs] --global でconnectionDraining設定を確認
  • Cloud Logging でドレイン中の失敗リクエストを確認
  • Instance Groupのrolling update設定(maxUnavailable等)を確認
  • リクエストの平均処理時間とドレインタイムアウトを比較
  • WebSocket/SSE等の長時間接続の有無を確認
ヘルスチェックのフラッピング
想定される原因
  • ヘルスチェックのintervalが短すぎてアプリの一時的な遅延で失敗
  • unhealthyThreshold/healthyThresholdが低すぎて少ないエラーで切り替わる
  • アプリケーションのGC(ガベージコレクション)による一時的な応答遅延
  • ヘルスチェックのタイムアウトがアプリの応答時間に対して短い
確認手順
  • Cloud Monitoring でbackend_services/healthyとunhealthyの推移を確認
  • gcloud compute health-checks describe [hc] でinterval/timeout/thresholdを確認
  • Cloud Logging でヘルスチェック失敗の詳細を確認
  • バックエンドアプリのGCログや一時的な遅延パターンを確認
  • ヘルスチェックエンドポイントの応答時間分布を確認
NEG(Network Endpoint Group)同期エラー
想定される原因
  • ServiceにNEG annotationが設定されていない
  • NEGコントローラーの権限不足
  • Podのreadinessが通過していないためNEGに登録されない
  • ゾーン間のNEGエンドポイント数の偏り
確認手順
  • kubectl get svc [service] -o yaml でcloud.google.com/neg annotationを確認
  • gcloud compute network-endpoint-groups list でNEGの状態確認
  • gcloud compute network-endpoint-groups list-network-endpoints [neg] でエンドポイント確認
  • kubectl describe svc [service] でNEG関連のイベントを確認
  • kubectl get pods -o wide でPodのReadiness状態を確認
WebSocket接続のタイムアウト
想定される原因
  • ロードバランサーのbackend timeout(デフォルト30秒)がWebSocket接続に対して短い
  • バックエンドサービスのtimeoutSecがWebSocketのidle時間より短い
  • WebSocket upgradeのヘッダーがLBで正しく転送されていない
  • Internal LBではWebSocket非対応の設定がある
確認手順
  • gcloud compute backend-services describe [bs] --global でtimeoutSecを確認
  • Cloud Logging でWebSocket接続の切断パターンを確認
  • バックエンドでWebSocket Upgrade(Connection: Upgrade, Upgrade: websocket)が返されているか確認
  • LBのプロトコル設定(HTTP/HTTPS)を確認
  • Cloud Monitoring でactive connectionsの数と切断頻度を確認
リージョン間フェイルオーバー設定の不備
想定される原因
  • バックエンドグループの failover priority/capacity設定が不適切
  • フェイルオーバー先リージョンのバックエンドも不健全
  • ヘルスチェックの評価遅延によりフェイルオーバーが遅れる
  • capacity drainの設定でトラフィックが段階的にしか移行しない
確認手順
  • gcloud compute backend-services describe [bs] --global でバックエンドグループの設定を確認
  • 各リージョンのバックエンドヘルス状態を確認
  • failoverRatioとcapacityScalerの設定を確認
  • ヘルスチェックのcheckInterval/thresholdがフェイルオーバー速度に影響していないか確認
  • Cloud Monitoring で各リージョンのトラフィック分配を確認
413 Request Entity Too Large
想定される原因
  • リクエストボディがLBの最大サイズ制限を超過
  • バックエンドサービスのmaxRequestBodySize設定が小さい
  • ファイルアップロードがデフォルト制限(通常32MB/64MB)を超過
  • Cloud Armorポリシーのリクエストサイズ制限
確認手順
  • バックエンドサービスの設定でmaxStreamDuration/timeoutを確認
  • アプリケーション(nginx/apache等)のclient_max_body_size設定を確認
  • Cloud Armorのルールでリクエストサイズ制限がないか確認
  • LBのログでリクエストサイズ(requestSize)を確認
  • External HTTP(S) LBの仕様上の制限(リクエストヘッダー最大64KB)を確認
Internal LBのアクセス不可(VPCスコープ問題)
想定される原因
  • クライアントとInternal LBが異なるVPCネットワークに存在
  • VPCピアリングは設定されているがInternal LBへのルートがない
  • サブネットの設定が正しくない(リージョン不一致等)
  • ファイアウォールルールがInternal LBのヘルスチェックまたはクライアントアクセスをブロック
確認手順
  • gcloud compute forwarding-rules describe [fr] --region=[region] でVPCとサブネットを確認
  • クライアントVMのVPCネットワークとLBのVPCが一致するか確認
  • VPCピアリングの設定と export custom routes の状態を確認
  • gcloud compute networks subnets describe [subnet] でプロキシ専用サブネットの存在を確認
  • ファイアウォールルールでInternal LBのIPへのアクセスが許可されているか確認
キャッシュヒット率が低い
想定される原因
  • レスポンスヘッダーにCache-Control: no-store/no-cacheが設定されている
  • Set-Cookieヘッダーがレスポンスに含まれキャッシュ不可になっている
  • Varyヘッダーが多くのバリエーションを生成しキャッシュ効率が低下
  • キャッシュキーの設定が不適切でURLごとに別キャッシュになっている
確認手順
  • Cloud Monitoring でcdn/cache_hit_ratio メトリクスを確認
  • Cloud Logging のCDNログでcacheStatus(HIT/MISS/BYPASS)を確認
  • curl -I [url] でレスポンスのCache-Control/Vary/Set-Cookieヘッダーを確認
  • バックエンドサービスのCDN設定でcache modeを確認
  • キャッシュキーの設定(include/exclude query params等)を確認
古いコンテンツの配信(キャッシュ無効化の遅延)
想定される原因
  • max-ageやs-maxageのTTLが長すぎてキャッシュが更新されない
  • キャッシュ無効化リクエストの伝播に時間がかかっている(最大数分)
  • 無効化リクエストのレート制限に達している
  • URLパスパターンが正しく指定されていない
確認手順
  • gcloud compute url-maps list-cdn-cache-invalidations [urlmap] で無効化履歴を確認
  • curl -I [url] でAge/X-Cache-Statusヘッダーからキャッシュ鮮度を確認
  • Cloud Console > Network Services > CDN > Invalidations で進捗確認
  • バックエンドのCache-Control max-age設定を確認
  • 無効化パスのパターン(ワイルドカード)が意図通りか確認
署名付きURLの認証失敗
想定される原因
  • 署名キー名がバックエンドサービスのCDN設定に登録されていない
  • 署名の計算方法が間違っている(URL prefix vs URL)
  • 署名付きURLの有効期限が切れている
  • キーの値(Base64エンコード)が正しくない
確認手順
  • gcloud compute backend-services describe [bs] でsignedUrlKeyNamesを確認
  • 署名付きURLのExpires/KeyNameパラメータを確認
  • CDNのsigned URL typeがurl-prefix-basedかurl-basedか確認
  • 署名計算に使用するキーがバックエンドに登録されたものと一致するか確認
  • Cloud Logging で署名検証失敗の詳細を確認
オリジンへの接続タイムアウト(キャッシュミス時)
想定される原因
  • オリジンサーバーがダウンまたは高負荷で応答遅延
  • バックエンドサービスのtimeoutSecが短すぎる
  • オリジンのヘルスチェックが失敗しバックエンドが不健全
  • CDNとオリジン間のネットワーク接続の問題
確認手順
  • Cloud Monitoring でcdn/origin_latencies メトリクスを確認
  • バックエンドサービスのヘルスチェック状態を確認
  • Cloud Logging でoriginリクエストのレイテンシとエラーを確認
  • オリジンサーバーのCPU/メモリ/接続数を確認
  • バックエンドサービスのtimeoutSec設定を確認
CDN有効化後の予期しないコスト増加
想定される原因
  • キャッシュヒット率が低くオリジンからの取得(cache fill)が頻発
  • 大容量コンテンツ(動画等)のエグレス通信量が多い
  • マルチリージョン配信でリージョン間のcache fill転送が発生
  • 不要なリクエスト(bot等)がCDNを経由して課金対象になっている
確認手順
  • Cloud Billing でCDN関連の課金内訳を確認
  • Cloud Monitoring でcdn/egress_bytes とcdn/cache_fill_bytes を確認
  • Cloud Logging でリクエスト数とバイト数の内訳を確認
  • キャッシュヒット率を確認して改善余地を分析
  • Bot/crawlerからのトラフィック比率を確認
Cloud Storage バケットバックエンドのアクセス拒否
想定される原因
  • バックエンドバケットに公開アクセス(allUsers)が設定されていない
  • CDN用の署名付きURL/Cookieが設定されていない
  • バケットのIAMポリシーでCDNからのアクセスが許可されていない
  • Public Access Preventionが有効でallUsers設定が不可
確認手順
  • gsutil iam get gs://[bucket] でバケットのIAMポリシーを確認
  • gcloud compute backend-buckets describe [bb] でCDN/signedUrl設定を確認
  • バケットのPublic Access Prevention設定を確認
  • Cloud Logging でCDN→バケットのリクエストエラーを確認
  • CDN署名付きURL設定がある場合はキーの有効性を確認
特定リージョンでのレイテンシ増大
想定される原因
  • ユーザーの近くにCDNエッジPoPがない
  • オリジンサーバーが単一リージョンにあり遠いエッジからのcache fillが遅い
  • 特定リージョンのキャッシュヒット率が低い(ロングテールコンテンツ)
  • Premium Network Tierを使用していない
確認手順
  • Cloud Monitoring でリージョン別のレイテンシメトリクスを確認
  • Cloud Logging でクライアントIP/地域別の応答時間を分析
  • バックエンドサービスのネットワークティア(Premium/Standard)を確認
  • リージョン別のキャッシュヒット率を確認
  • オリジンサーバーのロケーションとユーザー分布を確認
HTTP/2 プッシュ・圧縮設定の不備
想定される原因
  • オリジンサーバーが圧縮レスポンスを返していない
  • CDNのcompressionMode設定が無効
  • レスポンスのContent-Typeが圧縮対象に含まれていない
  • レスポンスサイズが小さすぎて圧縮が適用されない
確認手順
  • curl -H 'Accept-Encoding: gzip, br' -I [url] でContent-Encodingを確認
  • gcloud compute backend-services describe [bs] でcompressionMode設定を確認
  • オリジンのnginx/apache圧縮設定を確認
  • レスポンスのContent-Typeを確認(text/html, application/json等が対象)
  • Cloud Logging でレスポンスサイズとContent-Encodingを確認
カスタムキャッシュキーの設定ミス
想定される原因
  • 不要なクエリパラメータ(utm_*, fbclid等)がキャッシュキーに含まれている
  • HostヘッダーのバリエーションでキャッシュがFragmentation
  • プロトコル(HTTP/HTTPS)がキャッシュキーに含まれ別扱い
  • includeQueryString=trueで全パラメータがキーに含まれている
確認手順
  • gcloud compute backend-services describe [bs] でcacheKeyPolicy設定を確認
  • Cloud Logging でキャッシュキーの生成パターンを確認
  • リクエストURLのクエリパラメータバリエーションを分析
  • 同一コンテンツに対するキャッシュミス率を確認
  • Cloud Monitoring でキャッシュエントリ数の推移を確認
CDNログの欠損・遅延
想定される原因
  • バックエンドサービスのログ設定が無効化されている
  • Log Sinkの宛先(BigQuery/Cloud Storage等)の権限不足
  • ログサンプリングレートが設定されて一部のログしか記録されていない
  • Cloud Loggingの取り込み制限に達している
確認手順
  • gcloud compute backend-services describe [bs] --format='value(logConfig)' でログ設定確認
  • logConfig.sampleRateでサンプリング率を確認(1.0=100%記録)
  • Cloud Logging > Log Router > Sinks でSinkのエラーを確認
  • Cloud Monitoring の logging.googleapis.com/export/* メトリクスを確認
  • Cloud Loggingのクォータ使用状況を確認
HTTPSリダイレクトの無限ループ
想定される原因
  • CDNがHTTPS→HTTPでオリジンに接続し、オリジンがHTTPSにリダイレクト
  • LBのHTTP→HTTPSリダイレクトとアプリのリダイレクトが競合
  • CDNのbackendプロトコルがHTTPでオリジンがHTTPSを強制
  • X-Forwarded-Protoヘッダーがオリジンに正しく伝わっていない
確認手順
  • curl -L -v [url] でリダイレクトチェーンを確認
  • CDNバックエンドのプロトコル設定(HTTP/HTTPS)を確認
  • オリジンのリダイレクト設定を確認(nginx/apache/アプリ)
  • LBのURL Mapでリダイレクトルールを確認
  • X-Forwarded-Proto ヘッダーの伝播を確認
Negative Cachingによるエラーレスポンスの長時間キャッシュ
想定される原因
  • Negative CachingのTTLが長すぎてエラーが長時間キャッシュされる
  • 一時的なオリジンエラーがキャッシュされ復旧後も古いエラーが配信される
  • Negative Cachingの対象HTTPステータスコードが広すぎる
  • キャッシュ無効化がNegative Cacheに対して実行されていない
確認手順
  • gcloud compute backend-services describe [bs] でnegativeCachingPolicy設定を確認
  • Cloud Logging でキャッシュされたエラーレスポンスを確認
  • curl -I [url] でレスポンスのAge headerとステータスコードを確認
  • negativeCachingPolicyのcode別TTL設定を確認
  • オリジンのエラー発生時刻とキャッシュTTLの残りを計算
ファイアウォールルールによるトラフィックブロック
想定される原因
  • 明示的なdenyルールがallow ルールより高い優先度で設定されている
  • VPCのimplicit deny(デフォルト拒否)により許可ルールがないトラフィックがブロック
  • ターゲットタグやサービスアカウントの指定が間違っている
  • Hierarchical Firewall Policyが組織/フォルダレベルでブロック
確認手順
  • gcloud compute firewall-rules list --sort-by=priority で全ルールを優先度順に確認
  • VPC Flow Logs で該当トラフィックのdisposition(ALLOWED/DENIED)を確認
  • Firewall Insights > Denied connections で拒否されたトラフィックを確認
  • gcloud compute instances describe [instance] でnetwork tags/service accountを確認
  • Hierarchical Firewall Policies を確認: gcloud compute org-security-policies list
サブネットIPアドレス枯渇
想定される原因
  • サブネットのCIDR範囲が小さすぎて全IPが使用済み
  • GKE PodのセカンダリIP範囲が枯渇
  • 停止中のインスタンスがIPを保持している
  • Internal LBやPrivate Service Accessが多数のIPを消費
確認手順
  • gcloud compute networks subnets describe [subnet] でCIDR範囲とIP使用状況を確認
  • gcloud compute addresses list --filter='subnetwork:[subnet]' で割り当て済みIPを確認
  • Cloud Console > VPC > Subnets でIP使用率を確認
  • GKEクラスタのセカンダリ範囲の使用状況を確認
  • 停止中インスタンスによるIP保持を確認
VPCピアリングの接続問題
想定される原因
  • ピアリング設定で custom route export/import が無効
  • CIDR範囲が重複してピアリングが確立できない
  • トランジティブピアリング非サポートで間接的な接続が不可
  • ピアリング接続数の上限(25)に達している
確認手順
  • gcloud compute networks peerings list --network=[network] でピアリング状態を確認
  • ピアリング設定のexportCustomRoutes/importCustomRoutesを確認
  • 両方のVPCのCIDR範囲に重複がないか確認
  • gcloud compute routes list でピアリング経由のルートを確認
  • ピアリング接続数と上限を確認
Cloud NAT のポート枯渇
想定される原因
  • min_ports_per_vmの設定が低すぎて同時接続数に対して不足
  • 特定のインスタンスが大量のoutbound接続を行っている
  • NATのIPアドレス数が不足
  • 接続のTIME_WAITが蓄積してポートが解放されない
確認手順
  • Cloud Monitoring でnat/allocated_ports, nat/port_usage を確認
  • gcloud compute routers nats describe [nat] --router=[router] で設定を確認
  • nat/dropped_sent_packets_count メトリクスでパケットドロップを確認
  • インスタンスごとのポート使用状況を確認
  • NATに割り当てられたIPアドレス数を確認
VPN接続のトンネルダウン
想定される原因
  • IKEバージョン/暗号化アルゴリズムのネゴシエーション不一致
  • Pre-shared key(共有秘密鍵)が両端で異なる
  • ピアVPNゲートウェイのIPアドレスが変更された
  • ファイアウォールがUDP 500/4500をブロックしている
確認手順
  • gcloud compute vpn-tunnels describe [tunnel] でstatus/detailedStatusを確認
  • Cloud Monitoring でvpn/tunnel_established メトリクスを確認
  • Cloud Logging でVPNゲートウェイのIKEログを確認
  • ピア側のVPN設定(IKE version, 暗号化, Pre-shared key)を確認
  • gcloud compute vpn-gateways describe [gw] でゲートウェイIPを確認
カスタムルーティングの設定ミス
想定される原因
  • カスタムルートのnext hopが停止中のインスタンスを指している
  • ルートの優先度(priority)が意図通りに設定されていない
  • サブネットルートとカスタムルートの競合
  • タグベースのルーティングでインスタンスのタグが不足
確認手順
  • gcloud compute routes list で全ルートと優先度を確認
  • gcloud compute instances describe [instance] でnext hopインスタンスの状態を確認
  • Network Intelligence Center > Connectivity Tests でルーティングを検証
  • VPC Flow Logs でトラフィックのルーティングパスを確認
  • タグベースルートの場合、対象インスタンスのタグを確認
Private Google Accessの未有効化による外部IP不要サービスへの接続失敗
想定される原因
  • サブネットでPrivate Google Accessが有効化されていない
  • 外部IPなしのインスタンスがGoogle APIにアクセスしようとしている
  • Cloud NATが設定されていない状態でインターネットアクセスが必要
  • DNS設定がprivate.googleapis.comに正しく解決されていない
確認手順
  • gcloud compute networks subnets describe [subnet] --format='value(privateIpGoogleAccess)' で確認
  • インスタンスに外部IPが割り当てられているか確認
  • Cloud NATの設定有無を確認
  • DNS設定でgoogleapis.comの解決先を確認
  • Private Service Connectの設定を確認
Shared VPCのクロスプロジェクト権限エラー
想定される原因
  • サービスプロジェクトのサービスアカウントにNetwork Userロールがない
  • Shared VPCの関連付けが正しく設定されていない
  • サブネットレベルのIAMで特定サブネットへのアクセスが制限されている
  • GKE/Cloud Run等のサービスエージェントにShared VPC権限がない
確認手順
  • gcloud compute shared-vpc list-associated-resources [host_project] でサービスプロジェクトを確認
  • サービスアカウントのIAMロール確認: roles/compute.networkUser
  • サブネットレベルのIAMバインディングを確認
  • GKE Host Service Agent Userロールの付与を確認
  • gcloud projects get-iam-policy [host_project] でShared VPC関連のバインディングを確認
VPC Flow Logsの取得漏れ・コスト超過
想定される原因
  • サンプリングレートが低く設定されている(デフォルト50%)
  • Aggregation intervalが長くて短期接続が捕捉されない
  • メタデータアノテーション有効でログサイズが増大しコスト増
  • 特定のサブネットでFlow Logsが無効になっている
確認手順
  • gcloud compute networks subnets describe [subnet] --format='value(logConfig)' で設定確認
  • サンプリングレート(flowSampling)とaggregationIntervalを確認
  • Cloud Billing でFlow Logsのコストを確認
  • Cloud Monitoring でlogging.googleapis.com/byte_count を確認
  • 全サブネットでFlow Logsが有効か一括確認
Cloud Interconnect/Partner Interconnectの接続障害
想定される原因
  • 物理回線の障害(Dedicated Interconnect)
  • BGPセッションのネゴシエーション失敗(ASN, MD5 key等)
  • VLAN attachmentの設定不整合
  • パートナー側のインフラ障害
確認手順
  • gcloud compute interconnects describe [interconnect] でoperationalStatus確認
  • gcloud compute interconnects attachments describe [attachment] でstatus/BGP設定確認
  • Cloud Monitoring のinterconnect/link/status メトリクスを確認
  • Cloud Router のBGPセッション状態を確認: gcloud compute routers get-status [router]
  • パートナー側のステータスページを確認
DNS解決エラー(Cloud DNS設定問題)
想定される原因
  • Cloud DNS プライベートゾーンが対象VPCにアタッチされていない
  • DNS転送ゾーンの転送先が到達不能またはタイムアウト
  • DNSレコードが存在しない(タイポやゾーン設定漏れ)
  • inbound/outbound DNS forwardingの設定不備
確認手順
  • gcloud dns managed-zones describe [zone] でvisibilityとnetworksを確認
  • gcloud dns record-sets list --zone=[zone] でレコードを確認
  • nslookup/dig [hostname] @[dns_ip] で直接クエリして応答を確認
  • DNS forwardingの転送先IPへの到達性を確認
  • Cloud DNS のレスポンスポリシーの設定を確認
VPC Service Controls境界によるアクセスブロック
想定される原因
  • アクセス元のID(ユーザー/SA)がペリメータのingress policyに含まれていない
  • ペリメータ内からペリメータ外のプロジェクトへのegressが制限されている
  • Access Levelの条件(IP範囲、デバイスポリシー等)を満たしていない
  • 新しいサービスをペリメータ内で使用しようとして制限されている
確認手順
  • gcloud access-context-manager perimeters describe [perimeter] で設定確認
  • Cloud Audit Logs で VPC_SC_VIOLATION のログを確認
  • Access Context Managerのingress/egress policyを確認
  • Access Levelの条件を確認
  • VPC SC Troubleshooterで原因を診断
権限不足エラー(403 Permission Denied)
想定される原因
  • ユーザーまたはサービスアカウントに必要なIAMロールが付与されていない
  • ロールは付与されているがリソースレベルの権限が不足
  • 条件付きIAMバインディングの条件を満たしていない
  • Organization Policyが操作を制限している
確認手順
  • IAM Policy Troubleshooterで権限不足の原因を特定
  • gcloud projects get-iam-policy [project] で現在のバインディングを確認
  • gcloud iam roles describe [role] でロールに含まれるpermissionを確認
  • 条件付きバインディング(condition)の評価結果を確認
  • Cloud Audit LogsでアクセスエラーのmethodNameとresourceName確認
サービスアカウントキーの漏洩・不正使用
想定される原因
  • サービスアカウントキーがGitリポジトリにコミットされた
  • キーファイルがログや設定ファイルに平文で記録された
  • 開発者のローカルマシンからキーが漏洩
  • 不正なサードパーティアプリケーションにキーが共有された
確認手順
  • Security Command Center で漏洩検知のFindingを確認
  • Cloud Audit Logs で該当SAの異常なAPIアクセスパターンを確認
  • gcloud iam service-accounts keys list [sa] でキーの一覧と作成日時を確認
  • GitHub Secret Scanning等の通知を確認
  • 該当SAの最近のアクティビティ(リソース作成/削除等)を確認
サービスアカウントのimpersonation失敗
想定される原因
  • 呼び出し元にService Account Token Creatorロールが付与されていない
  • SA自体にService Account Userロールが不足
  • Organization Policyでimpersonationが制限されている
  • impersonation chainが長すぎる(直接impersonateのみ許可の場合)
確認手順
  • gcloud iam service-accounts get-iam-policy [sa_email] で誰がimpersonate可能か確認
  • 呼び出し元のIDにroles/iam.serviceAccountTokenCreatorが付与されているか確認
  • Organization Policyのconstraintsでimpersonation制限を確認
  • --impersonate-service-account フラグのチェーン設定を確認
  • Cloud Audit Logsでimpersonation失敗のログを確認
カスタムロールのpermission不足・非推奨
想定される原因
  • カスタムロールに存在しないpermissionが含まれている
  • permissionが非推奨(deprecated)になり機能しなくなった
  • カスタムロールのlaunch stageがTESTINGでGAではない
  • API更新によりpermission名が変更された
確認手順
  • gcloud iam roles describe [role] --project=[project] で現在のpermissionを確認
  • gcloud iam list-testable-permissions [resource] で利用可能なpermissionを確認
  • カスタムロールのetag/stageを確認
  • Permission Reference で最新のpermission名を確認
  • IAM Recommenderでロールの最適化提案を確認
Workload Identity Federationの設定エラー
想定される原因
  • Workload Identity PoolまたはProviderの設定が不正
  • Attribute mappingのCEL式が外部トークンのclaimと一致しない
  • Attribute conditionで外部IDがフィルタされている
  • プロバイダーのissuer URLが到達不能
確認手順
  • gcloud iam workload-identity-pools providers describe [provider] で設定を確認
  • 外部トークンのclaims内容をデコードして確認(jwt.io等)
  • attribute mappingのCEL式が外部トークンの構造と一致するか確認
  • attribute conditionの評価結果を確認
  • gcloud iam workload-identity-pools describe [pool] でプール状態を確認
Organization Policyによる操作制限
想定される原因
  • 組織レベルのポリシーがプロジェクトの操作を制限している
  • リソースロケーション制約(gcp.resourceLocations)でリージョンが制限
  • サービスアカウントキー作成制約(iam.disableServiceAccountKeyCreation)
  • 外部IPの使用制約(compute.vmExternalIpAccess)
確認手順
  • gcloud org-policies list --project=[project] で適用されているポリシーを確認
  • gcloud org-policies describe [constraint] --project=[project] で制約の詳細を確認
  • Cloud Console > IAM & Admin > Organization Policies で全制約を一覧
  • Organization/Folder/Project の継承関係でどのレベルで設定されているか確認
  • Cloud Audit Logs でOrgPolicy violation のログを確認
IAM条件付きバインディングの評価失敗
想定される原因
  • 時刻条件が現在時刻にマッチしない(期限切れや時間帯外)
  • リソース条件(resource.type, resource.name等)がリクエストと不一致
  • CEL式にシンタックスエラーがある
  • 条件のtitleが空または不正
確認手順
  • gcloud projects get-iam-policy [project] --format=yaml で条件付きバインディングを確認
  • 条件のCEL式を IAM Conditions simulator でテスト
  • 現在時刻と条件の時間範囲を比較
  • リクエスト対象のリソースタイプ/名前が条件と一致するか確認
  • Cloud Audit Logs でcondition evaluation の結果を確認
サービスアカウントの無効化・削除による障害
想定される原因
  • サービスアカウントが誤って無効化された
  • サービスアカウントが削除され30日の復元期間を過ぎた
  • 組織管理者によるセキュリティ対応でSAが無効化された
  • プロジェクト削除によりSAも一緒に削除された
確認手順
  • gcloud iam service-accounts describe [sa_email] でSAの状態を確認
  • gcloud iam service-accounts list --filter='disabled=true' で無効化されたSAを確認
  • Cloud Audit Logs でDisableServiceAccount/DeleteServiceAccountの操作を検索
  • 使用中のワークロード(GKE, Cloud Run等)のSA設定を確認
  • gcloud iam service-accounts undelete [sa_unique_id] で復元可能か確認
OAuth 2.0 トークンの期限切れ・リフレッシュ失敗
想定される原因
  • リフレッシュトークンが取り消された(ユーザーがアクセスを取り消し)
  • OAuth同意画面のスコープが変更されトークンが無効化
  • リフレッシュトークンの有効期限(6ヶ月未使用で失効)が切れた
  • サービスアカウントキーがローテーションされた
確認手順
  • gcloud auth list で現在のアクティブアカウントと認証状態を確認
  • OAuth 2.0 トークンの有効期限を確認
  • Google Cloudコンソール > API & Services > Credentials でOAuthクライアントを確認
  • リフレッシュトークンの取り消し履歴を確認
  • ADC (Application Default Credentials)の設定を確認
IAMバインディングの上限超過
想定される原因
  • リソースレベルのIAMポリシーに大量のバインディングが追加されている
  • 個別ユーザーへの直接バインディングが多すぎる(グループ未使用)
  • 条件付きバインディングが多くポリシーサイズが肥大化
  • 自動化ツールが不要なバインディングを蓄積
確認手順
  • gcloud [resource] get-iam-policy [name] --format=json | wc -c でポリシーサイズを確認
  • バインディング数をカウント
  • 個別ユーザーバインディングの割合を確認
  • 削除されたアカウント(deleted:user:)のバインディング残存を確認
  • 条件付きバインディングの数を確認
ドメイン制限共有ポリシーによる外部共有ブロック
想定される原因
  • iam.allowedPolicyMemberDomainsポリシーで外部ドメインが制限されている
  • パートナーや外部ベンダーのアカウントが許可ドメインに含まれていない
  • allUsersやallAuthenticatedUsersの使用が制限されている
  • サービスアカウントの外部プロジェクトへの共有が制限
確認手順
  • gcloud org-policies describe iam.allowedPolicyMemberDomains --project=[project] で制約を確認
  • 許可されたドメインのリストを確認
  • 追加しようとしているメンバーのドメインを確認
  • Organization/Folder/Projectレベルのオーバーライドを確認
  • タグベースの例外設定を確認
Audit Logsの欠損・設定不備
想定される原因
  • Data Access Audit Logsが有効化されていない(デフォルト無効のサービスが多い)
  • ログの保持期間を過ぎて削除された(デフォルト400日)
  • Log Sinkの設定でAudit Logsが除外されている
  • クエリのフィルタ条件が正しくない
確認手順
  • gcloud projects get-iam-policy [project] --format=json でauditConfigsを確認
  • Cloud Console > IAM & Admin > Audit Logs で各サービスのログ設定を確認
  • Cloud Logging > Log Router > Sinks で除外フィルタを確認
  • Admin Activity Logs は常に有効(無効化不可)であることを確認
  • ログの保持期間と対象期間の照合
カーネルパニックによるシステム停止
想定される原因
  • カーネルモジュールの不具合
  • メモリハードウェア障害
  • ルートファイルシステムのマウント失敗
  • ドライバの互換性問題
確認手順
  • dmesg | grep -i panic でパニックメッセージ確認
  • /var/crash/ 配下のクラッシュダンプ確認
  • memtest86+ でメモリテスト実施
  • lsmod で問題のあるモジュール確認
  • journalctl -k -b -1 で前回起動のカーネルログ確認
OOMキラーによるプロセス強制終了
想定される原因
  • アプリケーションのメモリリーク
  • 物理メモリ不足
  • swap領域不足
  • cgroup メモリ制限超過
確認手順
  • dmesg | grep -i oom でOOMイベント確認
  • free -h でメモリ使用状況確認
  • cat /proc/meminfo でメモリ詳細確認
  • ps aux --sort=-%mem | head でメモリ消費上位プロセス確認
  • cat /proc/sys/vm/overcommit_memory で設定確認
CPUソフトロックアップ検出
想定される原因
  • カーネルのデッドロック
  • 割り込みハンドラの長時間実行
  • 高負荷によるスケジューラ遅延
  • ハードウェア障害(CPU/メモリ)
確認手順
  • dmesg | grep -i 'soft lockup\|hung task' で検出確認
  • top / htop でCPU使用率確認
  • cat /proc/sys/kernel/watchdog_thresh でウォッチドッグ閾値確認
  • perf top でCPU消費関数の特定
I/Oスケジューラによるディスクレイテンシ増大
想定される原因
  • ディスクのハードウェア劣化
  • I/Oスケジューラの設定不適切
  • 過剰なI/O負荷
  • RAIDコントローラの障害
確認手順
  • iostat -xz 1 でディスクI/O統計確認
  • cat /sys/block/sda/queue/scheduler で現在のスケジューラ確認
  • smartctl -a /dev/sda でディスクの健康状態確認
  • iotop でI/O消費プロセス特定
  • dmesg | grep -i 'error\|fault' でI/Oエラー確認
Oopsエラーによるモジュールクラッシュ
想定される原因
  • カーネルモジュールのバグ
  • メモリ破壊
  • ドライバの互換性問題
  • カーネルバージョンとモジュールの不一致
確認手順
  • dmesg | grep -i oops でOopsメッセージ確認
  • Call Trace からクラッシュ箇所のモジュール特定
  • modinfo <module> でモジュールバージョン確認
  • uname -r で実行中カーネルバージョン確認
ネットワークドライバ障害によるNIC無応答
想定される原因
  • NICドライバのバグ
  • ネットワークカードのハードウェア障害
  • ファームウェアの不具合
  • IRQコンフリクト
確認手順
  • ethtool eth0 でリンク状態確認
  • dmesg | grep -i 'eth0\|nic\|link' でドライバメッセージ確認
  • lspci | grep -i network でNICデバイス確認
  • cat /proc/interrupts でIRQ割り当て確認
  • ethtool -S eth0 でエラーカウンタ確認
SELinux/AppArmorによるアクセス拒否
想定される原因
  • SELinuxポリシーの不一致
  • AppArmorプロファイルの制限
  • ファイルのセキュリティコンテキスト不正
  • 新規インストールサービスのポリシー未設定
確認手順
  • getenforce でSELinuxモード確認
  • ausearch -m AVC -ts recent で最近の拒否イベント確認
  • aa-status でAppArmorプロファイル状態確認
  • ls -Z でファイルのコンテキスト確認
  • sealert -a /var/log/audit/audit.log で解析
ファイルディスクリプタ枯渇
想定される原因
  • プロセスのファイルディスクリプタ上限が低い
  • システム全体のfile-max設定不足
  • ファイルディスクリプタリーク
  • 大量の同時接続
確認手順
  • cat /proc/sys/fs/file-nr で使用中FD数確認
  • ulimit -n で現在のプロセス制限確認
  • ls /proc/<pid>/fd | wc -l で特定プロセスのFD数確認
  • lsof -p <pid> | wc -l でオープンファイル一覧確認
  • cat /proc/sys/fs/file-max でシステム上限確認
ACPI/電源管理エラーによるスリープ復帰失敗
想定される原因
  • BIOSのACPI実装不具合
  • デバイスドライバのサスペンド/レジューム未対応
  • ファームウェアのバグ
  • 電源管理設定の不整合
確認手順
  • dmesg | grep -i acpi でACPIエラー確認
  • cat /sys/power/state で対応スリープ状態確認
  • journalctl -b | grep -i 'suspend\|resume' で復帰ログ確認
  • lspci -vv | grep -i power でデバイス電源状態確認
inotifyウォッチ上限到達
想定される原因
  • fs.inotify.max_user_watches のデフォルト値が低い
  • 開発ツール(webpack等)が大量のウォッチを消費
  • 監視対象ディレクトリの過剰設定
確認手順
  • cat /proc/sys/fs/inotify/max_user_watches で現在値確認
  • find /proc/*/fd -lname anon_inode:inotify 2>/dev/null | wc -l でウォッチ使用数推定
  • sysctl fs.inotify で関連設定一覧確認
タイムソース異常によるシステム時刻ずれ
想定される原因
  • TSCの不安定(仮想環境で多発)
  • CPUの省電力機能による周波数変動
  • NTPデーモンの未設定/停止
  • ハードウェアクロックの電池切れ
確認手順
  • cat /sys/devices/system/clocksource/clocksource0/current_clocksource で現在のクロックソース確認
  • timedatectl status で時刻同期状態確認
  • chronyc tracking または ntpq -p でNTP同期確認
  • hwclock --show でハードウェアクロック確認
カーネルtaintedフラグによる警告
想定される原因
  • プロプライエタリドライバ(NVIDIA等)のロード
  • 自作/未署名モジュールのロード
  • カーネルのセキュアブート署名検証失敗
  • サードパーティモジュールの使用
確認手順
  • cat /proc/sys/kernel/tainted でtaintフラグ値確認
  • dmesg | grep -i taint でtaint原因確認
  • lsmod でロード済みモジュール一覧確認
  • modinfo <module> | grep license でライセンス確認
サービスの起動失敗(ExecStart異常終了)
想定される原因
  • 設定ファイルの構文エラー
  • 必要なディレクトリ/ファイルの不在
  • ポートの競合
  • 依存サービスの未起動
確認手順
  • systemctl status <service> で状態確認
  • journalctl -u <service> -n 50 で詳細ログ確認
  • systemd-analyze verify <service> でユニットファイル検証
  • 設定ファイルの構文チェック(nginx -t等)
  • ss -tlnp でポート使用状況確認
サービスの自動再起動ループ(crash loop)
想定される原因
  • アプリケーションのクラッシュバグ
  • 設定ミスによる即時異常終了
  • リソース不足(メモリ/ディスク)
  • StartLimitInterval内に上限回数到達
確認手順
  • systemctl status <service> で restart counter確認
  • journalctl -u <service> --since '5 min ago' で直近ログ確認
  • systemctl show <service> | grep -i limit で制限値確認
  • coredumpctl list で直近のコアダンプ確認
タイムアウトによるサービス強制停止
想定される原因
  • サービスの起動処理が重い
  • 停止処理でのハング
  • Type=notify でNotifyAccess未設定
  • ディスクI/O遅延
確認手順
  • systemctl show <service> | grep Timeout でタイムアウト値確認
  • journalctl -u <service> で起動/停止処理の進行状況確認
  • systemd-analyze blame で起動時間確認
  • iostat でディスクI/O状況確認
依存関係エラーによるサービス起動順序異常
想定される原因
  • After/Requires の依存先サービスの起動失敗
  • 循環依存の発生
  • 依存サービスのユニットファイル不在
  • ターゲットの依存解決失敗
確認手順
  • systemctl list-dependencies <service> で依存ツリー確認
  • systemd-analyze critical-chain <service> で起動チェーン確認
  • systemctl status <dependency> で依存先の状態確認
  • systemd-analyze verify <service> で循環依存検出
ジャーナルログの肥大化によるディスク圧迫
想定される原因
  • SystemMaxUse の未設定/大きすぎる値
  • ログの大量出力サービスの存在
  • ログローテーション未設定
  • Storage=persistent でディスクへ永続化
確認手順
  • journalctl --disk-usage でジャーナルサイズ確認
  • du -sh /var/log/journal/ でディレクトリサイズ確認
  • cat /etc/systemd/journald.conf でジャーナル設定確認
  • journalctl --verify でジャーナル整合性確認
cgroup制限によるサービスリソース不足
想定される原因
  • MemoryMax/MemoryHigh の設定が低すぎる
  • CPUQuota による処理能力制限
  • TasksMax によるプロセス数制限
  • IOWeight によるI/O帯域制限
確認手順
  • systemctl show <service> | grep -E 'Memory|CPU|Tasks' で制限値確認
  • systemd-cgtop でcgroupリソース使用状況確認
  • cat /sys/fs/cgroup/<service>/memory.current でメモリ使用量確認
  • systemctl status <service> で制限到達メッセージ確認
マウントユニットの失敗によるファイルシステム未マウント
想定される原因
  • /etc/fstab のエントリ不正
  • デバイスが存在しない
  • ファイルシステム破損
  • nofail オプション未設定
確認手順
  • systemctl list-units --type=mount --state=failed で失敗マウント確認
  • mount -a でfstab全体のマウントテスト
  • blkid でデバイスUUID確認
  • fsck -n <device> でファイルシステム整合性確認
  • systemctl status <mount-unit> で詳細確認
タイマーユニットが発火しない
想定される原因
  • OnCalendar の書式誤り
  • タイマーユニットの enable 忘れ
  • 対応する .service ファイル不在
  • Persistent=true 未設定で再起動後にスキップ
確認手順
  • systemctl list-timers --all でタイマー一覧確認
  • systemctl status <timer> でタイマー状態確認
  • systemd-analyze calendar '<expression>' でカレンダー式検証
  • journalctl -u <timer> でタイマーイベント確認
ユニットファイルのパーミッションエラー
想定される原因
  • ExecStart のスクリプトに実行権限がない
  • ユニットファイルのパーミッションが不適切
  • User= で指定したユーザーの権限不足
  • SELinux/AppArmor による制限
確認手順
  • ls -la /etc/systemd/system/<service> でユニットファイル権限確認
  • ls -la <ExecStart path> でスクリプト権限確認
  • id <User> でユーザー存在確認
  • namei -l <path> でパス全体の権限確認
networkd/resolved によるDNS解決失敗
想定される原因
  • DNSサーバーの設定ミス
  • ネットワーク未接続状態でのDNS問い合わせ
  • /etc/resolv.conf のsymlinkが壊れている
  • DNSSEC検証失敗
確認手順
  • resolvectl status でDNS設定確認
  • resolvectl query <domain> でDNS解決テスト
  • ls -la /etc/resolv.conf でシンボリックリンク確認
  • networkctl status で全インタフェース状態確認
  • journalctl -u systemd-resolved で詳細ログ確認
ソケットアクティベーションの接続受付失敗
想定される原因
  • ポートが既に使用されている
  • 対応するサービスユニットの不在
  • ソケットファイルのパーミッション問題
  • ListenStream のパス/ポート設定誤り
確認手順
  • systemctl status <socket> でソケット状態確認
  • ss -tlnp | grep <port> でポート使用プロセス確認
  • systemctl cat <socket> でソケット設定確認
  • ls -la <socket-path> でUNIXソケットのパーミッション確認
emergency/rescue モードへの予期しないフォールバック
想定される原因
  • 重要なファイルシステムのマウント失敗
  • 重要なジェネレータの失敗
  • fstabの致命的エラー
  • initramfsの破損
確認手順
  • journalctl -xb で起動ログ確認
  • systemctl list-units --state=failed で失敗ユニット確認
  • cat /etc/fstab でマウント設定確認
  • systemctl default で通常起動を試行
ext4ファイルシステムのジャーナル破損
想定される原因
  • 突然の電源断によるジャーナル不整合
  • ディスクのハードウェア障害
  • ストレージコントローラの不具合
  • カーネルのバグ
確認手順
  • dmesg | grep EXT4 でエラーメッセージ確認
  • mount | grep ro で読み取り専用マウント確認
  • smartctl -a /dev/sda でディスク健康状態確認
  • tune2fs -l /dev/sda1 でファイルシステム情報確認
  • dumpe2fs /dev/sda1 | grep -i error でエラーカウント確認
inode枯渇によるファイル作成不可
想定される原因
  • 小さなファイルの大量作成(セッション/キャッシュファイル)
  • mkfs時のinode数設定が少なすぎる
  • 一時ファイルの未削除蓄積
  • メールキューの蓄積
確認手順
  • df -i でinode使用率確認
  • find / -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head でinode消費ディレクトリ特定
  • for dir in /tmp /var/spool /var/cache; do echo $dir; ls $dir | wc -l; done
  • tune2fs -l /dev/sda1 | grep -i inode でinode設定確認
XFSファイルシステムのメタデータI/Oエラー
想定される原因
  • ストレージデバイスの障害
  • RAIDコントローラのキャッシュ問題
  • 急な電源断後の不整合
  • SAN/NAS接続の不安定
確認手順
  • dmesg | grep -i xfs でXFSエラー確認
  • xfs_info /dev/sdb1 でファイルシステム情報確認
  • smartctl -a /dev/sdb でディスク状態確認
  • mount でマウント状態確認
NFS マウントのstale file handle
想定される原因
  • NFSサーバー側でエクスポートが再作成された
  • NFSサーバーの再起動
  • ネットワーク障害によるセッション切断
  • クライアントのファイルハンドルキャッシュ不整合
確認手順
  • stat /mnt/nfs でstaleエラー確認
  • showmount -e <server> でエクスポート確認
  • nfsstat -c でクライアントNFS統計確認
  • rpcinfo -p <server> でRPCサービス確認
  • mount | grep nfs でマウントオプション確認
LVMボリュームの認識失敗
想定される原因
  • 物理ボリュームのデバイスが見えない
  • LVMメタデータの破損
  • マルチパス設定の問題
  • ディスクの取り外し/障害
確認手順
  • pvs でPhysical Volume一覧確認
  • vgs でVolume Group一覧確認
  • lvs でLogical Volume一覧確認
  • pvscan --cache でPVキャッシュ更新
  • cat /etc/lvm/lvm.conf | grep filter でフィルタ設定確認
ディスク容量100%到達によるサービス停止
想定される原因
  • ログファイルの肥大化
  • 一時ファイルの蓄積
  • 大容量バックアップの残存
  • deleted但しオープンされているファイル
確認手順
  • df -h でディスク使用率確認
  • du -sh /* --exclude=/proc 2>/dev/null | sort -rh | head でディレクトリ別サイズ確認
  • lsof +L1 で削除済みだが使用中のファイル確認
  • find /var/log -name '*.log' -size +100M で大きなログ確認
  • journalctl --disk-usage でジャーナルサイズ確認
btrfsのCRCチェックサムエラー
想定される原因
  • ディスクのビット腐敗(bit rot)
  • メモリ障害によるデータ破壊
  • コントローラの不具合
  • ディスクの物理的劣化
確認手順
  • btrfs device stats /mnt でデバイス統計確認
  • btrfs scrub start /mnt でスクラブ実行
  • btrfs scrub status /mnt でスクラブ結果確認
  • dmesg | grep -i btrfs でエラー確認
  • smartctl -a /dev/sda でディスク状態確認
TRIMの失敗によるSSD性能低下
想定される原因
  • SSDがTRIM非対応
  • ファイルシステムがdiscardオプション未設定
  • RAIDコントローラがTRIMを通さない
  • カーネルのドライバがTRIM未対応
確認手順
  • lsblk -D で各デバイスのDISCARDサポート確認
  • cat /sys/block/sda/queue/discard_max_bytes で対応確認
  • fstrim -v / でTRIM手動実行テスト
  • systemctl status fstrim.timer で定期TRIM確認
  • hdparm -I /dev/sda | grep -i trim でドライブ対応確認
overlayfsのマウントエラー
想定される原因
  • Dockerのoverlay2レイヤー破損
  • upperdir/workdirの不整合
  • 同一ディレクトリの重複マウント
  • ストレージドライバの変更後の不整合
確認手順
  • mount | grep overlay でoverlayfsマウント確認
  • docker system df でDockerストレージ使用確認
  • ls -la /var/lib/docker/overlay2/ でレイヤー確認
  • docker info | grep -i storage でストレージドライバ確認
quota超過によるユーザー書き込み拒否
想定される原因
  • ユーザーのディスク使用量がハードリミット到達
  • グレース期間超過後のソフトリミット適用
  • quota設定とアプリケーション要件の不一致
  • 一時ファイルのquotaカウント
確認手順
  • repquota -a で全ユーザーのquota使用状況確認
  • quota -u <user> で特定ユーザーのquota確認
  • du -sh /home/<user> でディレクトリサイズ確認
  • quotaon -p / でquota有効状態確認
fstabのUUID不一致による起動失敗
想定される原因
  • ディスク交換後のUUID変更
  • パーティションテーブルの再作成
  • fstab編集時のUUID typo
  • デバイス名の変更(/dev/sdX→/dev/sdY)
確認手順
  • blkid で全デバイスのUUID確認
  • cat /etc/fstab でマウント設定確認
  • lsblk -f でファイルシステムとUUIDの対応確認
  • findmnt --verify でfstab検証
ZFS poolのdegraded状態
想定される原因
  • ミラー/RAIDZ構成のディスク1台が故障
  • 一時的なI/Oエラーによるディスクのオフライン化
  • ケーブル接触不良
  • ディスクファームウェアの問題
確認手順
  • zpool status で全pool状態確認
  • zpool status -v <pool> でエラー詳細確認
  • smartctl -a /dev/sdX で故障ディスク診断
  • zpool events | tail でイベント確認
  • zpool iostat -v <pool> でI/O確認
スワップ領域の枯渇によるシステム応答遅延
想定される原因
  • 物理メモリとswapの合計が不足
  • swappinessが高すぎてswapを過度に使用
  • メモリリークアプリケーション
  • swap パーティションの未設定
確認手順
  • free -h でメモリ/swap使用量確認
  • swapon --show でswap構成確認
  • cat /proc/sys/vm/swappiness で設定値確認
  • vmstat 1 5 でsi/so(swap in/out)確認
  • cat /proc/meminfo | grep -i swap でswap詳細確認
メモリリークによる使用量漸増
想定される原因
  • アプリケーションのメモリ解放漏れ
  • カーネルモジュールのメモリリーク
  • 共有ライブラリの不具合
  • キャッシュの無制限増加
確認手順
  • ps aux --sort=-%mem | head -10 でメモリ使用上位確認
  • pmap -x <pid> でプロセスメモリマップ確認
  • cat /proc/<pid>/status | grep Vm でメモリ詳細確認
  • valgrind --leak-check=yes <command> でリーク検出
  • echo scan > /sys/kernel/debug/kmemleak でカーネルリーク検出
hugepages設定不良によるメモリ割当失敗
想定される原因
  • hugepages の予約数が不足
  • メモリの断片化
  • THPのdefragが性能に悪影響
  • vm.nr_hugepages の設定不足
確認手順
  • cat /proc/meminfo | grep -i huge でhugepage状態確認
  • cat /sys/kernel/mm/transparent_hugepage/enabled でTHP設定確認
  • cat /proc/sys/vm/nr_hugepages で予約hugepage数確認
  • hugeadm --pool-list でhugepageプール確認
NUMA配置不均衡による性能劣化
想定される原因
  • プロセスが非ローカルNUMAノードのメモリを使用
  • NUMAバランシングの不適切設定
  • メモリがNUMAノード間で偏在
  • CPUアフィニティとメモリ配置の不一致
確認手順
  • numactl --hardware でNUMAトポロジー確認
  • numastat でNUMAノード別メモリ統計確認
  • numastat -p <pid> でプロセスのNUMA配置確認
  • cat /proc/sys/kernel/numa_balancing でバランシング確認
  • lstopo でトポロジー可視化
slab/kmemキャッシュの異常肥大
想定される原因
  • 大量のファイル/ディレクトリアクセスによるdentryキャッシュ膨張
  • カーネルモジュールのslabリーク
  • vm.vfs_cache_pressure が低すぎる
  • ファイルシステムのメタデータキャッシュ肥大
確認手順
  • slabtop でslabキャッシュ使用量確認
  • cat /proc/meminfo | grep -i slab でSReclaimable/SUnreclaim確認
  • cat /proc/slabinfo | sort -k 3 -rn | head でslab上位確認
  • cat /proc/sys/vm/vfs_cache_pressure で設定確認
ECC メモリエラー(correctable/uncorrectable)
想定される原因
  • DIMMの物理的劣化
  • メモリの過熱
  • DIMMスロットの接触不良
  • コスミックレイ(宇宙線)による一時的ビット反転
確認手順
  • edac-util -s でEDACステータス確認
  • edac-util -r で詳細レポート確認
  • mcelog --client でMCEログ確認
  • grep -i edac /var/log/messages でエラー履歴確認
  • dmidecode -t memory でDIMM情報確認
overcommit拒否によるfork失敗
想定される原因
  • vm.overcommit_memory=2 で厳密モード設定
  • CommitLimit到達
  • プロセスの仮想メモリ要求過大
  • overcommit_ratio が低すぎる
確認手順
  • cat /proc/sys/vm/overcommit_memory で設定確認
  • cat /proc/sys/vm/overcommit_ratio で比率確認
  • cat /proc/meminfo | grep -i commit でCommitted_AS/CommitLimit確認
  • free -h で全体メモリ状況確認
  • ps aux --sort=-vsz | head で仮想メモリ使用上位確認
共有メモリ(shm)の上限到達
想定される原因
  • kernel.shmmax の値が小さい
  • /dev/shm のサイズ制限
  • kernel.shmall の値が不足
  • アプリケーションの共有メモリ要求過大
確認手順
  • ipcs -m で現在の共有メモリセグメント確認
  • cat /proc/sys/kernel/shmmax で最大セグメントサイズ確認
  • cat /proc/sys/kernel/shmall で全体ページ数確認
  • df -h /dev/shm でtmpfsサイズ確認
  • ipcs -lm で共有メモリ制限確認
ページテーブル肥大によるメモリオーバーヘッド
想定される原因
  • 大量のプロセス/スレッド起動
  • 巨大な仮想アドレス空間のmmap
  • hugepages未使用での大容量メモリ管理
  • fork爆弾の影響
確認手順
  • cat /proc/meminfo | grep PageTables でシステム全体のPT確認
  • grep VmPTE /proc/<pid>/status でプロセス別PT確認
  • ps -e --no-headers | wc -l でプロセス数確認
  • cat /proc/<pid>/smaps | grep -i pte でマッピング別PT確認
メモリバルーニングによるVM性能低下
想定される原因
  • ホスト側のメモリ不足でバルーン膨張
  • VMのメモリ割当過剰設定
  • ホスト側の他VMとのリソース競合
  • バルーンドライバの設定ミス
確認手順
  • cat /proc/meminfo | grep Balloon でバルーン使用量確認
  • free -h でゲスト側メモリ確認
  • virsh dommemstat <vm> でホスト側統計確認(ホストで実行)
  • dmesg | grep -i balloon でバルーンイベント確認
cgroup memory.maxによるコンテナOOM
想定される原因
  • コンテナのメモリ制限が低すぎる
  • アプリケーションのメモリ使用量の見積もり不足
  • メモリリーク
  • キャッシュ込みでの計算超過
確認手順
  • docker stats でコンテナメモリ使用確認
  • cat /sys/fs/cgroup/docker/<id>/memory.current で使用量確認
  • cat /sys/fs/cgroup/docker/<id>/memory.max で制限値確認
  • dmesg | grep oom-kill でOOMイベント確認
  • docker inspect <container> | grep Memory で設定確認
MMIO/DMAリージョンの競合
想定される原因
  • PCIデバイスのBARリソース競合
  • IOMMUの設定問題
  • BIOSのリソース割り当て不良
  • 32bitアドレス空間の枯渇(4GB以上のBAR)
確認手順
  • lspci -vv | grep -i 'memory\|region' でPCIリソース確認
  • dmesg | grep -iE 'dmar|iommu' でIOMMUエラー確認
  • cat /proc/iomem でメモリマッピング確認
  • dmesg | grep 'BAR.*no space' でリソース競合確認
TCP接続タイムアウトの頻発
想定される原因
  • ファイアウォールによるパケットドロップ
  • nf_conntrack テーブル満杯
  • ルーティングの問題
  • 対向ホストのダウン
確認手順
  • ping <host> でホスト到達性確認
  • traceroute <host> で経路確認
  • ss -s でソケット統計確認
  • cat /proc/sys/net/netfilter/nf_conntrack_count で接続数確認
  • iptables -L -n -v でドロップルール確認
DNSの名前解決失敗
想定される原因
  • DNSサーバーの応答なし
  • /etc/resolv.conf の設定不備
  • DNSキャッシュの汚染
  • ネットワーク接続自体の問題
確認手順
  • cat /etc/resolv.conf でDNS設定確認
  • dig @8.8.8.8 <domain> で外部DNS確認
  • systemctl status systemd-resolved でリゾルバ状態確認
  • nslookup <domain> でDNS解決テスト
  • ping <dns-server-ip> でDNSサーバー到達性確認
ネットワークインターフェースのリンクダウン
想定される原因
  • ケーブルの抜け/断線
  • スイッチポートの障害
  • NICのハードウェア故障
  • オートネゴシエーション失敗
確認手順
  • ip link show でインターフェース状態確認
  • ethtool <iface> でリンク状態・速度確認
  • dmesg | grep -i 'link\|carrier' でリンクイベント確認
  • cat /sys/class/net/<iface>/carrier でキャリア状態確認
  • mii-tool <iface> でMII状態確認
IPアドレス重複による通信障害
想定される原因
  • DHCPサーバーの割当ミス
  • 静的IP設定の重複
  • VRRPなどの冗長構成の設定ミス
  • 不正な機器の接続
確認手順
  • arping -D <ip> -I <iface> でIP重複検出
  • arp -a でARPテーブル確認
  • ip addr show で自機のIP確認
  • nmap -sn <network> でネットワークスキャン
  • journalctl -u NetworkManager | grep -i duplicate
iptables/nftablesルール設定ミスによるパケットドロップ
想定される原因
  • ルール順序の誤り(先にDROPが適用)
  • デフォルトポリシーがDROP
  • 新規サービスのポート開放忘れ
  • IPv6ルールの未設定
確認手順
  • iptables -L -n -v --line-numbers でルール一覧確認
  • nft list ruleset でnftablesルール確認
  • iptables -L -t nat でNATテーブル確認
  • conntrack -L で接続トラッキング確認
  • iptables -Z && iptables -L -n -v でカウンタリセットして確認
MTU不一致によるパケット断片化・通信障害
想定される原因
  • VPN/トンネル経路でのMTU削減
  • ジャンボフレーム設定の不一致
  • PMTUD のICMPブロック
  • VXLAN/GRE等のオーバーヘッド
確認手順
  • ip link show <iface> でMTU確認
  • ping -M do -s 1472 <host> でPMTU確認
  • ip route get <host> でルートMTU確認
  • tracepath <host> でMTUパス確認
  • cat /proc/sys/net/ipv4/ip_no_pmtu_disc で設定確認
ボンディング/チーミングのスレーブ障害
想定される原因
  • スレーブインターフェースの物理障害
  • スイッチ側のポート障害
  • LACPネゴシエーション失敗
  • ドライバの不具合
確認手順
  • cat /proc/net/bonding/bond0 でボンディング状態確認
  • ip link show でスレーブ状態確認
  • ethtool <slave-iface> でリンク状態確認
  • journalctl | grep bond でボンディングイベント確認
  • teamdctl team0 state でチーミング状態確認
TCPバックログ溢れによる接続拒否
想定される原因
  • net.core.somaxconn が低い
  • アプリケーションのaccept処理が遅い
  • SYNフラッド攻撃
  • tcp_max_syn_backlog が不足
確認手順
  • ss -ltn でLISTENソケットのbacklog確認
  • cat /proc/sys/net/core/somaxconn で上限確認
  • netstat -s | grep -i overflow でオーバーフロー統計確認
  • cat /proc/sys/net/ipv4/tcp_max_syn_backlog でSYNバックログ確認
  • ss -s でTCPソケット統計確認
ポートエフェメラル枯渇
想定される原因
  • 大量の短命接続によるTIME_WAIT蓄積
  • ip_local_port_range が狭い
  • 接続プールの未使用
  • Keep-Alive未活用
確認手順
  • ss -s でTIME_WAITソケット数確認
  • cat /proc/sys/net/ipv4/ip_local_port_range でポート範囲確認
  • ss -tan state time-wait | wc -l でTIME_WAIT数確認
  • cat /proc/sys/net/ipv4/tcp_tw_reuse で設定確認
VLANタグ設定ミスによる通信不能
想定される原因
  • VLAN IDの設定誤り
  • スイッチ側のtrunkポート設定不備
  • NICが802.1qオフロード非対応
  • 親インターフェースがダウン
確認手順
  • ip -d link show でVLAN情報確認
  • cat /proc/net/vlan/<iface> でVLAN統計確認
  • bridge vlan show でブリッジVLAN確認
  • ethtool -k <iface> | grep vlan でVLANオフロード確認
  • ip link show <parent> で親IF状態確認
IPv6の自動設定(SLAAC)失敗
想定される原因
  • accept_ra が無効
  • ルーターからのRAが届かない
  • DAD(重複アドレス検出)の失敗
  • IPv6がカーネルレベルで無効
確認手順
  • ip -6 addr show でIPv6アドレス確認
  • cat /proc/sys/net/ipv6/conf/<iface>/accept_ra でRA受信設定確認
  • rdisc6 <iface> でRA受信テスト
  • sysctl net.ipv6.conf.<iface>.disable_ipv6 で無効化状態確認
  • ip -6 route show でIPv6ルーティング確認
ブリッジネットワークのSTP障害
想定される原因
  • ネットワークループの発生
  • STP設定の不整合
  • MACアドレスの重複
  • ブリッジ間のBPDU到達不良
確認手順
  • brctl showstp br0 でSTP状態確認
  • bridge link show でブリッジポート確認
  • cat /sys/class/net/br0/bridge/stp_state でSTP有効確認
  • ip link show type bridge でブリッジ一覧確認
  • dmesg | grep -i bridge でブリッジイベント確認
SSH接続拒否(Connection refused)
想定される原因
  • sshdサービスが停止している
  • sshdがデフォルトポート以外でリッスン
  • ファイアウォールによるブロック
  • TCP Wrapper による拒否
確認手順
  • systemctl status sshd でサービス状態確認
  • ss -tlnp | grep :22 でリッスン確認
  • iptables -L -n | grep 22 でFWルール確認
  • cat /etc/ssh/sshd_config | grep -i port でポート確認
  • cat /etc/hosts.deny でTCP Wrapper確認
SSH公開鍵認証の失敗
想定される原因
  • authorized_keys ファイルのパーミッション不正
  • .ssh ディレクトリの権限不正(700以外)
  • 公開鍵の不一致
  • StrictModes有効時のホームディレクトリ権限
確認手順
  • ls -la ~/.ssh/ でパーミッション確認
  • ls -la ~/.ssh/authorized_keys で鍵ファイル権限確認
  • ssh -vvv user@host で詳細デバッグ
  • journalctl -u sshd | grep 'Failed\|Accepted' で認証ログ確認
  • cat /etc/ssh/sshd_config | grep -i pubkey で設定確認
SSH接続の遅延(ログイン前に長時間待機)
想定される原因
  • UseDNS yes による逆引きDNSの遅延
  • GSSAPIAuthentication による認証試行
  • PAM設定内のDNS問い合わせ
  • クライアント側の鍵試行順序
確認手順
  • ssh -vvv user@host 2>&1 | grep -i 'debug\|delay' で接続過程確認
  • grep -i 'usedns\|gssapi' /etc/ssh/sshd_config で設定確認
  • time ssh user@host exit で接続時間計測
  • dig -x <client-ip> で逆引き応答時間確認
ブルートフォース攻撃の検知
想定される原因
  • 外部からのブルートフォース攻撃
  • ボットによる自動スキャン
  • 内部ネットワークからの不正アクセス試行
  • パスワード認証の有効化
確認手順
  • journalctl -u sshd | grep 'Failed password' | wc -l で失敗回数確認
  • lastb | head で直近の認証失敗確認
  • grep 'Failed password' /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn で攻撃元IP集計
  • fail2ban-client status sshd でban状態確認
SSH接続の突然切断(Broken pipe)
想定される原因
  • ネットワークの不安定
  • サーバー側のClientAliveInterval設定
  • NAT/ファイアウォールのセッションタイムアウト
  • クライアント側のアイドルタイムアウト
確認手順
  • grep -i 'alive\|timeout' /etc/ssh/sshd_config でサーバー設定確認
  • grep -i 'alive\|timeout' ~/.ssh/config でクライアント設定確認
  • ping <host> でネットワーク安定性確認
  • journalctl -u sshd | grep -i timeout で切断ログ確認
ホスト鍵変更警告(MITM疑い)
想定される原因
  • サーバーの再インストール/OS変更
  • DNS改ざんやIP変更
  • 実際の中間者攻撃
  • 同一IPの別サーバーへの変更
確認手順
  • ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub でサーバー側フィンガープリント確認
  • ssh-keygen -F <host> でknown_hostsエントリ確認
  • 正当な変更かセキュリティチームに確認
  • nslookup/dig でDNS解決先の正当性確認
SSHトンネル/ポートフォワーディングの失敗
想定される原因
  • AllowTcpForwarding no の設定
  • GatewayPorts の未設定
  • 転送先ポートが既に使用中
  • PermitOpen による制限
確認手順
  • grep -i 'tcpforwarding\|gatewayports\|permitopen' /etc/ssh/sshd_config で設定確認
  • ss -tlnp | grep <port> でポート使用状況確認
  • ssh -v -L <port>:<host>:<port> user@host で詳細出力確認
  • journalctl -u sshd | grep -i forward でフォワーディングログ確認
SSH鍵アルゴリズムの互換性問題
想定される原因
  • クライアント/サーバー間のアルゴリズム不一致
  • 古いSSHバージョンとの互換性問題
  • セキュリティ強化により廃止されたアルゴリズムの使用
  • ssh_config/sshd_config のCiphers/KexAlgorithms制限
確認手順
  • ssh -Q kex でクライアント対応KEXアルゴリズム確認
  • ssh -Q cipher でクライアント対応暗号確認
  • ssh -vvv user@host 2>&1 | grep 'kex\|cipher' で交渉過程確認
  • sshd -T | grep -i 'ciphers\|kex\|hostkey' でサーバー設定確認
MaxStartups到達による接続拒否
想定される原因
  • 同時認証接続数が上限超過
  • ブルートフォース攻撃による認証中コネクション増加
  • 自動化ツールの大量並列接続
  • MaxStartups のデフォルト値(10:30:100)が低い
確認手順
  • grep MaxStartups /etc/ssh/sshd_config で設定値確認
  • ss -tn state syn-recv | grep :22 | wc -l で認証中接続数確認
  • journalctl -u sshd | grep -i MaxStartups でドロップイベント確認
  • netstat -tn | grep :22 | grep -v ESTABLISHED | wc -l で未確立接続数確認
SFTPサブシステム設定エラー
想定される原因
  • ChrootDirectoryのパーミッション不正(root:root 755必須)
  • sftp-serverパスの不正
  • internal-sftp未使用でのchroot不能
  • MatchブロックのForceCommand設定誤り
確認手順
  • grep -A5 -i sftp /etc/ssh/sshd_config でSFTP設定確認
  • ls -la <ChrootDirectory> でchroot先権限確認
  • namei -l <ChrootDirectory> でパス全体の権限確認
  • sshd -T | grep sftp でサブシステム設定確認
  • sftp -vvv user@host で接続デバッグ
SSH エージェント転送の問題
想定される原因
  • ssh-agentが起動していない
  • ForwardAgent no の設定
  • SSH_AUTH_SOCKの環境変数未設定
  • sudo後のソケットアクセス権限喪失
確認手順
  • echo $SSH_AUTH_SOCK で環境変数確認
  • ssh-add -l で登録鍵一覧確認
  • grep ForwardAgent ~/.ssh/config でエージェント転送設定確認
  • ls -la $SSH_AUTH_SOCK でソケットファイル存在確認
PAMモジュールによるSSH認証失敗
想定される原因
  • アカウントのロック/期限切れ
  • /etc/nologin ファイルの存在
  • PAMモジュールの設定エラー
  • pam_faillock によるロック
確認手順
  • passwd -S <user> でアカウント状態確認
  • chage -l <user> でアカウント有効期限確認
  • faillock --user <user> でロック状態確認
  • cat /etc/pam.d/sshd でPAM設定確認
  • ls /etc/nologin || ls /var/run/nologin でnologin確認
cronジョブが実行されない
想定される原因
  • crondサービスが停止している
  • crontabの書式エラー
  • スクリプトのパーミッション不足
  • 環境変数(PATH等)の未設定
確認手順
  • systemctl status cron / systemctl status crond でサービス状態確認
  • crontab -l で現在のcrontab確認
  • grep CRON /var/log/syslog で実行ログ確認
  • cat /etc/cron.deny でユーザー拒否リスト確認
  • journalctl -u cron --since '1 hour ago' で直近ログ確認
cronジョブの重複実行
想定される原因
  • 前回の実行が終了前に次回が開始
  • crontab と /etc/cron.d/ の両方に同一ジョブ登録
  • anacronとcronの二重実行
  • 実行時間がスケジュール間隔を超過
確認手順
  • crontab -l と ls /etc/cron.d/ で重複登録確認
  • pgrep -f <script> で同一プロセスの多重起動確認
  • cat /var/log/syslog | grep <script> で実行頻度確認
  • ls /var/spool/anacron/ でanacronタイムスタンプ確認
cron実行時の環境変数問題
想定される原因
  • cronのデフォルトPATHが限定的(/usr/bin:/bin)
  • SHELL がログインシェルと異なる
  • ユーザープロファイル(.bashrc等)が読み込まれない
  • LANG/LC_ALL未設定による文字化け
確認手順
  • env で通常環境の変数確認
  • crontab -l | head でcrontab内のSHELL/PATH定義確認
  • grep -i path /etc/crontab でシステムcronの環境確認
  • which <command> でコマンドのフルパス確認
cronメール配信の失敗/大量送信
想定される原因
  • MTAが未インストール/停止
  • MAILTO未設定でlocal deliveryが溜まる
  • ジョブの標準出力/エラーが大量
  • メールキューの肥大化
確認手順
  • which sendmail でMTA存在確認
  • mailq でメールキュー確認
  • crontab -l | grep MAILTO でメール設定確認
  • du -sh /var/spool/mail/ でローカルメール蓄積確認
anacronの実行タイミングずれ
想定される原因
  • RANDOM_DELAY が大きい
  • START_HOURS_RANGE の設定で実行時間帯が限定
  • タイムスタンプファイルの不整合
  • 電源OFF時間の長さ
確認手順
  • cat /etc/anacrontab でanacron設定確認
  • ls -la /var/spool/anacron/ でタイムスタンプ確認
  • cat /var/spool/anacron/cron.daily で最終実行日確認
  • systemctl status anacron.timer でタイマー状態確認
cron.d/ファイルのパーミッション拒否
想定される原因
  • /etc/cron.d/ 内ファイルのパーミッションが緩い(644以外)
  • ファイルのオーナーがroot以外
  • グループ/他者書き込み権限あり
  • crontabファイルの改行コードがCR+LF
確認手順
  • ls -la /etc/cron.d/ でファイル権限確認
  • stat /etc/cron.d/<file> で詳細確認
  • file /etc/cron.d/<file> でファイル形式確認
  • journalctl -u cron | grep -i insecure でエラーログ確認
cronジョブのディスクI/O集中による性能影響
想定される原因
  • バックアップジョブのI/O集中
  • logrotateの大量ファイル処理
  • 複数のcronジョブが同時刻に設定
  • ionice未使用でのI/O優先度競合
確認手順
  • crontab -l でジョブのスケジュール時刻確認
  • iostat -x 1 でI/O負荷確認
  • iotop でI/O消費プロセス確認
  • ls /etc/cron.d/ /etc/cron.daily/ で全ジョブ一覧確認
at/batchコマンドの実行失敗
想定される原因
  • atdサービスが停止
  • ユーザーが /etc/at.deny に含まれる
  • /etc/at.allow 未存在で全ユーザー拒否
  • at スプールディレクトリの権限問題
確認手順
  • systemctl status atd でサービス状態確認
  • cat /etc/at.deny でユーザー拒否リスト確認
  • cat /etc/at.allow で許可リスト確認
  • atq でジョブキュー確認
  • ls -la /var/spool/at/ でスプール権限確認
systemdタイマーとcronの競合
想定される原因
  • systemdタイマーとcron両方で同一タスクを実行
  • ディストリビューション移行時の設定残存
  • apt-daily.timer と /etc/cron.daily/apt の併存
  • logrotate.timer と cron.daily/logrotate の重複
確認手順
  • systemctl list-timers --all でアクティブタイマー確認
  • ls /etc/cron.daily/ で日次ジョブ確認
  • systemctl status apt-daily.timer 等のタイマー状態確認
  • dpkg -L <package> | grep cron でパッケージのcron登録確認
cronジョブのタイムゾーン問題
想定される原因
  • システムタイムゾーンがUTCでcrontabがJST想定
  • DST(夏時間)切替による実行タイミングずれ
  • TZ変数未設定
  • timedatectl設定とcronの不一致
確認手順
  • timedatectl でシステムタイムゾーン確認
  • date で現在時刻/TZ確認
  • grep -i tz /etc/crontab でTZ設定確認
  • cat /etc/timezone でタイムゾーン確認
cronログの出力先問題
想定される原因
  • rsyslogのcronファシリティ設定なし
  • /var/log/cron が未作成
  • journaldのみでファイル出力なし
  • ログローテーション後のファイル未作成
確認手順
  • grep cron /etc/rsyslog.conf でcronログ設定確認
  • ls -la /var/log/cron* でログファイル存在確認
  • journalctl -u cron で journald経由のログ確認
  • cat /etc/logrotate.d/cron でローテーション設定確認
crontab構文エラーによるジョブ無視
想定される原因
  • 時刻フィールドの値が範囲外(分:0-59, 時:0-23等)
  • 6番目のフィールド(ユーザー名)の欠落(/etc/cron.d/の場合)
  • 特殊文字のエスケープ不足(%)
  • 空行/コメントの書式不正
確認手順
  • crontab -l で現在のcrontab確認
  • grep -n '' /etc/cron.d/<file> で全行確認
  • crontab -T <file> で構文チェック(対応版のみ)
  • journalctl -u cron | grep -i error で構文エラー確認
apt/yumの依存関係解決失敗
想定される原因
  • リポジトリの混在(stable/testing等)
  • 部分的なアップグレードの中断
  • サードパーティリポジトリとの競合
  • パッケージのピン止め(hold)
確認手順
  • apt-cache policy <package> でバージョン候補確認
  • apt-mark showhold でhold中パッケージ確認
  • apt-get check で依存関係整合性確認
  • yum deplist <package> で依存関係確認
  • dnf repoquery --requires <package> で要件確認
パッケージデータベースのロック競合
想定される原因
  • 別のapt/yumプロセスが実行中
  • 前回の操作が異常終了してロック残存
  • unattended-upgradesの自動実行中
  • aptデーモン(apt-daily.timer)の実行中
確認手順
  • ps aux | grep -i 'apt\|dpkg\|yum\|dnf' で実行中プロセス確認
  • lsof /var/lib/dpkg/lock-frontend でロック保持プロセス確認
  • systemctl status apt-daily.timer で自動更新状態確認
  • cat /var/run/yum.pid でPID確認
リポジトリのGPG鍵検証失敗
想定される原因
  • リポジトリの鍵が未インポート
  • 鍵の有効期限切れ
  • リポジトリのURL変更後の鍵不一致
  • 鍵サーバーへのアクセス不能
確認手順
  • apt-key list で登録済み鍵一覧確認
  • gpg --list-keys で鍵確認
  • rpm -qa gpg-pubkey* でRPM鍵確認
  • apt-get update 2>&1 | grep NO_PUBKEY で不足鍵ID確認
dpkg中断によるパッケージ設定未完了
想定される原因
  • インストール中の電源断
  • ディスク容量不足でのインストール中断
  • post-inst スクリプトの失敗
  • 依存パッケージの設定未完了
確認手順
  • dpkg --audit で問題パッケージ一覧確認
  • dpkg -l | grep -E '^(iF|iU|rc)' で半端な状態のパッケージ確認
  • apt-get -f install で修復試行
  • cat /var/lib/dpkg/info/<package>.postinst でスクリプト確認
リポジトリ接続エラー(404/タイムアウト)
想定される原因
  • リポジトリURLの誤り/期限切れ
  • ミラーサーバーの障害
  • ネットワーク接続の問題
  • EOL(サポート終了)ディストリビューション
確認手順
  • cat /etc/apt/sources.list で登録リポジトリ確認
  • curl -I <repo-url> でリポジトリアクセス確認
  • yum repolist でリポジトリ状態確認
  • lsb_release -a でディストリビューションバージョン確認
  • ping <repo-host> でネットワーク確認
カーネルアップデート後のモジュール不整合
想定される原因
  • カーネルヘッダーパッケージの未インストール
  • DKMSモジュールのビルド失敗
  • 古いカーネル用モジュールの非互換
  • ドライバソースのバージョン不適合
確認手順
  • uname -r で実行中カーネルバージョン確認
  • dkms status で DKMS モジュール状態確認
  • ls /lib/modules/$(uname -r)/ でモジュールディレクトリ確認
  • dpkg -l | grep linux-headers でヘッダーパッケージ確認
  • dmesg | grep -i 'module\|firmware' でモジュールエラー確認
RPMデータベースの破損
想定される原因
  • 突然の電源断によるDB破損
  • ディスク容量不足でのトランザクション中断
  • 同時アクセスによるロック破壊
  • RPMの古いバージョンの不具合
確認手順
  • rpm -qa で全パッケージ一覧取得テスト
  • cd /var/lib/rpm && /usr/lib/rpm/rpmdb_verify Packages でDB検証
  • ls -la /var/lib/rpm/__db.* でロックファイル確認
  • file /var/lib/rpm/Packages でDB形式確認
共有ライブラリの不足/バージョン不一致
想定される原因
  • 必要なライブラリパッケージの未インストール
  • ldconfig未実行(キャッシュ未更新)
  • LD_LIBRARY_PATH の設定不足
  • glibc バージョンの不一致(古いOS上で新しいバイナリ実行)
確認手順
  • ldd <binary> で必要ライブラリ一覧と解決状態確認
  • ldconfig -p | grep <lib> でキャッシュ内ライブラリ確認
  • apt-file search <library.so> でパッケージ特定
  • rpm -qf <library-path> でRPMパッケージ特定
  • strings /lib/*/libc.so.6 | grep GLIBC でglibc対応バージョン確認
Snap/Flatpakのサンドボックス権限エラー
想定される原因
  • snapのstrict confinementによるアクセス制限
  • home/removable-media インターフェース未接続
  • AppArmor プロファイルによる拒否
  • flatpakのファイルシステムアクセス未許可
確認手順
  • snap connections <snap> で接続済みインターフェース確認
  • snap logs <snap> でアプリログ確認
  • flatpak info --show-permissions <app> で権限確認
  • journalctl --since '5 min ago' | grep -i 'denied\|apparmor' で拒否ログ確認
パッケージキャッシュの破損
想定される原因
  • ダウンロード中の通信エラー
  • プロキシのキャッシュ汚染
  • ディスク障害によるファイル破損
  • リポジトリのミラー同期中のアクセス
確認手順
  • apt-get check でキャッシュ整合性確認
  • ls -la /var/cache/apt/archives/ でキャッシュサイズ確認
  • du -sh /var/cache/apt/ でキャッシュ総量確認
  • md5sum /var/cache/apt/archives/<pkg>.deb でチェックサム確認
自動セキュリティ更新(unattended-upgrades)の失敗
想定される原因
  • 依存関係の問題で自動更新ブロック
  • ディスク容量不足
  • confファイルの対話的確認待ち
  • dpkg設定中のエラー
確認手順
  • cat /var/log/unattended-upgrades/unattended-upgrades.log で詳細ログ確認
  • apt-get -s dist-upgrade でシミュレーション
  • dpkg --configure -a で保留設定確認
  • cat /etc/apt/apt.conf.d/50unattended-upgrades で設定確認
pip/npmグローバルインストールの権限問題
想定される原因
  • sudoなしでのシステムディレクトリへのインストール試行
  • 以前sudoでインストールしたためファイル所有者がroot
  • virtualenv/nvm未使用
  • npm prefixがシステムディレクトリ
確認手順
  • pip show <package> でインストール先確認
  • npm config get prefix でnpmプレフィックス確認
  • ls -la /usr/lib/python3/dist-packages/ で所有者確認
  • which python && which pip でパス確認
rsyslogの起動失敗/設定エラー
想定される原因
  • 設定ファイルの構文エラー
  • 存在しないモジュールの参照
  • ファイルパスの誤り
  • 互換性のない設定ディレクティブ
確認手順
  • rsyslogd -N1 で設定ファイル検証
  • systemctl status rsyslog でサービス状態確認
  • journalctl -u rsyslog で詳細エラー確認
  • cat /etc/rsyslog.conf で設定確認
  • ls /etc/rsyslog.d/ でインクルードファイル確認
ログローテーション失敗によるファイル肥大化
想定される原因
  • logrotate設定ファイルの構文エラー
  • ディスク容量不足(回転先の容量)
  • ログファイルのパーミッション問題
  • postrotateスクリプトのエラー
確認手順
  • logrotate -d /etc/logrotate.d/<config> でデバッグ実行(dry-run)
  • cat /var/lib/logrotate/status でローテーション履歴確認
  • ls -la /var/log/<file> でファイルサイズ/権限確認
  • logrotate --force /etc/logrotate.d/<config> で強制実行テスト
journaldのディスク使用量制限超過
想定される原因
  • SystemMaxUse未設定でディスク10%まで使用
  • 大量ログ出力サービスの存在
  • ジャーナルの破損
  • Storage=persistent設定での蓄積
確認手順
  • journalctl --disk-usage でジャーナル使用量確認
  • journalctl --verify でジャーナル整合性確認
  • cat /etc/systemd/journald.conf で設定確認
  • systemctl status systemd-journald でサービス状態確認
ログのリモート転送失敗(rsyslog/fluentd)
想定される原因
  • リモートsyslogサーバーのダウン
  • ネットワーク/ファイアウォールのブロック
  • 転送プロトコル(TCP/UDP)の不一致
  • ローカルキューの満杯
確認手順
  • nc -vz <host> 514 で接続テスト
  • rsyslogd -N1 で設定検証
  • journalctl -u rsyslog | grep -i 'suspend\|error' で転送エラー確認
  • ls -la /var/spool/rsyslog/ でスプールサイズ確認
  • ss -lnp | grep 514 でリモート側のリッスン確認
auditdのログ肥大/パフォーマンス影響
想定される原因
  • 監査ルールが広範すぎる
  • audit_backlog_limitの値が低い
  • 高I/Oシステムでのsyscall監査
  • audisp-remoteの転送遅延
確認手順
  • auditctl -l で現在の監査ルール確認
  • auditctl -s でauditステータス確認
  • aureport --summary で監査サマリー確認
  • cat /etc/audit/auditd.conf でバックログ設定確認
  • ausearch -m AVC --start recent で直近イベント数確認
syslog-ngの解析エラーによるメッセージドロップ
想定される原因
  • メッセージフォーマットの不一致
  • テンプレート設定のエラー
  • rate-limit設定による制限
  • UTF-8以外のエンコーディング混入
確認手順
  • syslog-ng -s で設定構文チェック
  • syslog-ng-ctl stats でドロップ統計確認
  • syslog-ng-ctl query get '*' で内部メトリクス確認
  • cat /etc/syslog-ng/syslog-ng.conf で設定確認
ログファイルのパーミッション問題による書込失敗
想定される原因
  • ログファイルの所有者/グループ不正
  • ログディレクトリの権限不足
  • logrotate後のファイル再作成時の権限問題
  • SELinuxコンテキスト不正
確認手順
  • ls -la /var/log/<file> でファイル権限確認
  • namei -l /var/log/<path> でパス全体の権限確認
  • getfacl /var/log/<file> でACL確認
  • ls -Z /var/log/<file> でSELinuxコンテキスト確認
カーネルリングバッファのオーバーフロー
想定される原因
  • カーネルリングバッファサイズが小さい
  • 大量のカーネルメッセージ生成
  • ネットワークドライバの過剰ログ出力
  • printk rate limitの設定
確認手順
  • dmesg | tail で最新メッセージ確認
  • dmesg --level=err でエラーレベルのみ確認
  • cat /proc/sys/kernel/printk で現在のprintk設定確認
  • sysctl kernel.printk_ratelimit で流量制限確認
構造化ログ(JSON)のパースエラー
想定される原因
  • マルチラインログのJSON不完全
  • アプリケーションの出力にバイナリ混入
  • 文字エンコーディング問題
  • ログ出力の途中切断
確認手順
  • tail -1 /var/log/<file> | jq . で最終行のJSON妥当性確認
  • grep -c '{' /var/log/<file> で行数と構造確認
  • file /var/log/<file> でファイルエンコーディング確認
  • head -c 1000 /var/log/<file> | cat -v でバイナリ混入確認
logrotateのcopytruncateによるログ欠損
想定される原因
  • copyとtruncateの間にログ書き込み発生
  • 高スループットアプリケーション
  • アプリケーションがSIGHUP非対応
  • バッファリングされたログの喪失
確認手順
  • grep copytruncate /etc/logrotate.d/* でcopytruncate使用設定確認
  • diff <(wc -l /var/log/app.log.1) <(wc -l expected) で行数差異確認
  • cat /etc/logrotate.d/<config> で現在のローテーション方式確認
journaldのレート制限によるログ欠落
想定される原因
  • RateLimitIntervalSec/RateLimitBurst のデフォルト値が厳しい
  • アプリケーションの過剰ログ出力
  • デバッグレベルのログが本番で有効
  • ループ内のエラーログ大量出力
確認手順
  • journalctl -u <service> | grep -i suppressed で抑制数確認
  • cat /etc/systemd/journald.conf | grep -i rate でレート設定確認
  • systemctl show <service> | grep -i log でサービスログ設定確認
ログ集約基盤(ELK/Loki)へのインジェスト障害
想定される原因
  • Elasticsearch/Lokiのインジェスト容量超過
  • バルクリクエストのサイズ過大
  • Circuit Breakerによるメモリ保護
  • インデックスのシャード数過多
確認手順
  • curl -s localhost:9200/_cluster/health でESクラスタ状態確認
  • curl -s localhost:9200/_cat/thread_pool/bulk で処理キュー確認
  • curl -s localhost:9200/_nodes/stats/breaker でCB状態確認
  • ログシッパーのメトリクス/ログで送信失敗率確認
GRUBブートローダーの読み込み失敗
想定される原因
  • GRUBのインストール先パーティションの変更
  • grub.cfgの破損/削除
  • ディスクの追加/削除によるデバイス順変更
  • MBR/EFI領域の破損
確認手順
  • ls (hd0,1)/ でGRUBシェルからパーティション内容確認
  • set でGRUB環境変数確認
  • ls でGRUBから見えるデバイス一覧確認
  • Live USBから mount して /boot/grub/ 確認
initramfs/initrdの破損による起動停止
想定される原因
  • initramfsの破損/不完全な生成
  • ルートデバイスのドライバがinitramfsに含まれていない
  • カーネルアップデート時のinitramfs生成失敗
  • UUID変更後のinitramfs未更新
確認手順
  • lsinitramfs /boot/initrd.img-$(uname -r) でinitramfs内容確認
  • file /boot/initrd.img-* でファイル形式確認
  • ls -la /boot/ で起動関連ファイル確認
  • 前回正常カーネルで起動して確認
fsckによる起動時ファイルシステムチェック停止
想定される原因
  • マウントカウント超過による自動fsck
  • 前回の不正シャットダウン
  • ファイルシステムの不整合検出
  • tune2fs のcheck_interval設定
確認手順
  • tune2fs -l /dev/sda1 | grep -i 'mount count\|check' でfsck設定確認
  • dmesg | grep fsck でfsck実行ログ確認
  • cat /etc/fstab で各パーティションのpass値確認
UEFI Secure Boot検証失敗
想定される原因
  • 署名されていないカーネル/ブートローダー
  • MOK(Machine Owner Key)未登録
  • Secure Boot鍵のリセット
  • サードパーティドライバの未署名
確認手順
  • mokutil --sb-state でSecure Boot状態確認
  • mokutil --list-enrolled で登録済みMOK確認
  • efibootmgr -v でブートエントリ確認
  • dmesg | grep -i 'secure\|verified' でブート時ログ確認
Plymouth/スプラッシュ画面でのフリーズ
想定される原因
  • グラフィックドライバの問題
  • フレームバッファの解像度不対応
  • Plymouthプラグインの破損
  • ファームウェアファイルの欠損
確認手順
  • 起動時にEscキーでPlymouthスプラッシュをスキップ
  • カーネルパラメータに nomodeset を追加して起動テスト
  • ls /usr/share/plymouth/themes/ でテーマ確認
  • plymouth --details でデバッグ情報確認
systemd-modules-loadでのモジュール読み込み失敗
想定される原因
  • モジュールが現在のカーネルバージョンに存在しない
  • DKMSモジュールのビルド失敗
  • blacklist設定との競合
  • /etc/modules-load.d/ に古いモジュール名残存
確認手順
  • systemctl status systemd-modules-load で状態確認
  • cat /etc/modules-load.d/*.conf で読込指定確認
  • modprobe -n -v <module> でモジュール探索テスト
  • cat /etc/modprobe.d/*.conf でblacklist確認
  • find /lib/modules/$(uname -r) -name '<module>*' でモジュール存在確認
起動時のネットワーク待機タイムアウト
想定される原因
  • ネットワーク設定のタイムアウト
  • DHCPサーバーの応答遅延
  • 未接続のネットワークインターフェース
  • network-online.targetに依存するサービス
確認手順
  • systemd-analyze blame で起動時間ボトルネック確認
  • systemd-analyze critical-chain で起動チェーン確認
  • systemctl status NetworkManager-wait-online で状態確認
  • nmcli device status で全インターフェース状態確認
SELinux/AppArmorのrelabel/プロファイル読込遅延
想定される原因
  • /.autorelabel ファイルの存在による全ファイルラベリング
  • SELinuxポリシー変更後の再ラベリング
  • AppArmorプロファイルの破損
  • 大量ファイルシステムでの長時間relabel
確認手順
  • ls /.autorelabel でautorelabelフラグ確認
  • getenforce でSELinuxモード確認
  • sestatus でSELinux詳細状態確認
  • aa-status でAppArmor状態確認
  • systemd-analyze で起動時間確認
UEFIファームウェア設定の不整合
想定される原因
  • EFI変数のNVRAM破損
  • BIOSリセットによるブートエントリ喪失
  • CSM/Legacy互換モードとUEFIの混在
  • efivarfs のマウント失敗
確認手順
  • efibootmgr -v でブートエントリ確認
  • ls /sys/firmware/efi/ でEFI変数アクセス確認
  • mount | grep efivarfs でefivarfsマウント確認
  • ls /boot/efi/EFI/ でESP内容確認
default.targetの不正設定による起動モード異常
想定される原因
  • default.targetのシンボリックリンク破損
  • 存在しないtargetへのリンク
  • GUIインストール後のtarget未変更
  • apt/yumアップデートによるtarget変更
確認手順
  • systemctl get-default で現在のデフォルトtarget確認
  • ls -la /etc/systemd/system/default.target でリンク先確認
  • systemctl list-units --type=target で利用可能なtarget確認
DRACUTモジュール不足による起動シェルドロップ
想定される原因
  • LVMモジュールのinitramfs未含有
  • 暗号化ボリュームのcryptsetupモジュール未含有
  • NFS rootのnfsモジュール不足
  • カスタムドライバのinitramfs未組込
確認手順
  • lsinitrd /boot/initramfs-*.img | grep <module> でモジュール含有確認
  • dracut --list-modules で利用可能モジュール確認
  • cat /etc/dracut.conf.d/*.conf で追加モジュール設定確認
  • rd.shell rd.debug カーネルパラメータで詳細起動
fstrimサービスによる起動後のディスクI/Oスパイク
想定される原因
  • fstrim.timerの発火タイミングと起動直後が重なる
  • 長期間fstrim未実行でのdiscard量蓄積
  • SSDの大容量空き領域のTRIM処理
  • 起動後のanacron/systemdタイマー集中実行
確認手順
  • systemctl status fstrim.timer でタイマー状態確認
  • systemctl list-timers でタイマー発火時刻確認
  • iostat -x 1 でI/O状況確認
  • journalctl -u fstrim で過去の実行時間確認
イベントログサービスが停止しBSODが記録されない
想定される原因
  • イベントログサービスのクラッシュ
  • ディスク容量不足によるログ書き込み失敗
  • カーネルドライバの致命的エラー
  • メモリ破損によるシステムハング
確認手順
  • Get-Service EventLog でサービス状態を確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=6008]]' で予期しないシャットダウン履歴確認
  • wevtutil gl System でログサイズと保持設定を確認
  • Get-EventLog -LogName System -Source 'Microsoft-Windows-WER-SystemErrorReporting' でBSOD記録確認
  • ディスク空き容量の確認(C:\Windows\System32\winevt\Logs)
セキュリティログが監査ポリシー変更後に記録されない
想定される原因
  • 監査ポリシーのGPO競合
  • セキュリティログの最大サイズ到達と上書き禁止設定
  • ローカルポリシーとドメインポリシーの不整合
  • CrashOnAuditFail設定による制限
確認手順
  • auditpol /get /category:* で現在の監査ポリシーを確認
  • Get-WinEvent -LogName Security -MaxEvents 10 でログの記録状態確認
  • wevtutil gl Security でセキュリティログの容量と保持ポリシー確認
  • gpresult /h gpresult.html で適用されているGPOを確認
  • reg query HKLM\System\CurrentControlSet\Control\Lsa /v CrashOnAuditFail で設定確認
Windows Event Collectorサービスが起動に失敗する
想定される原因
  • WinRMサービスが未起動
  • ファイアウォールでWinRM(5985/5986)がブロック
  • サービスアカウントの権限不足
  • 依存サービス(HTTP.sys)の起動失敗
確認手順
  • Get-Service Wecsvc,WinRM でサービス状態確認
  • wecutil gs <SubscriptionName> でサブスクリプション状態確認
  • netsh advfirewall firewall show rule name=all | findstr WinRM でFW確認
  • sc qc Wecsvc でサービス構成と依存関係確認
  • Test-WSMan -ComputerName localhost でWinRM接続テスト
DFSレプリケーションでイベントログの複製遅延が発生
想定される原因
  • USNジャーナルのラップアラウンド
  • ステージング領域のクォータ超過
  • ネットワーク帯域不足による同期遅延
  • 共有フォルダの大量変更による同期バックログ
確認手順
  • Get-DfsrState -GroupName <group> でレプリケーション状態確認
  • dfsrdiag PollAD で AD からの情報取得状態確認
  • Get-WinEvent -LogName 'DFS Replication' -MaxEvents 50 でDFSRイベント確認
  • wmic /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo get State でフォルダ状態確認
  • dfsrdiag Backlog /smem:<server1> /rmem:<server2> /rgname:<group> でバックログ確認
イベントログの書き込みでディスクI/Oボトルネック発生
想定される原因
  • ディスクI/O飽和(他プロセスとの競合)
  • ストレージコントローラの障害
  • イベントログファイルの断片化
  • ウイルス対策ソフトのリアルタイムスキャン干渉
確認手順
  • Get-Counter '\PhysicalDisk(*)\Avg. Disk Queue Length' でキュー長確認
  • Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Write' で書き込みレイテンシ確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=50]]' で遅延書き込みイベント確認
  • fsutil volume diskfree C: でディスク空き容量確認
  • defrag C: /A で断片化レベルを分析
イベントログファイルが破損し読み取り不能になる
想定される原因
  • 予期しない電源断によるファイル破損
  • ディスクのセクタ不良
  • イベントログサービスの異常終了
  • ストレージ仮想化レイヤーの問題
確認手順
  • wevtutil gl Application で各ログチャネルの状態確認
  • Get-WinEvent -LogName Application -ErrorAction SilentlyContinue でログ読み取りテスト
  • chkdsk C: でディスク整合性の確認(読み取りのみ)
  • dir C:\Windows\System32\winevt\Logs\*.evtx でファイルサイズ異常確認
  • wevtutil el | ForEach-Object { wevtutil gl $_ } でチャネル全体の状態確認
リモートサーバーへのイベントログ転送がネットワークエラーで失敗
想定される原因
  • ネットワーク接続断またはルーティング問題
  • WinRMリスナーのタイムアウト設定が短すぎる
  • DNSの名前解決失敗
  • 中間ファイアウォールによるポート5985/5986ブロック
確認手順
  • Test-NetConnection -ComputerName <collector> -Port 5985 で接続テスト
  • wecutil gr <SubscriptionName> でランタイム状態確認
  • nslookup <collector_hostname> でDNS解決確認
  • Get-WinEvent -LogName 'Microsoft-Windows-Forwarding/Operational' -MaxEvents 20 で転送ログ確認
  • winrm get winrm/config でWinRM構成とタイムアウト確認
カスタムイベントログチャネルの登録・設定エラー
想定される原因
  • マニフェストXMLの構文エラー
  • 既存チャネルとの名前競合
  • wevtutil imコマンドの権限不足
  • DLLパスの不一致
確認手順
  • wevtutil el | findstr <channel_name> でチャネル存在確認
  • wevtutil gp <publisher_name> でパブリッシャー登録状態確認
  • dir C:\Windows\System32\winevt\Logs\<channel>.evtx でログファイル存在確認
  • Get-WinEvent -ListProvider * | Where-Object { $_.Name -like '*custom*' } でカスタムプロバイダー一覧
  • 管理者権限でPowerShellを実行しているか確認
WMI経由のイベントログクエリがタイムアウトする
想定される原因
  • WMIリポジトリの破損
  • イベントログサイズが大きすぎてクエリが遅延
  • WMIプロバイダのメモリリーク
  • RPCサービスの問題
確認手順
  • winmgmt /verifyrepository でWMIリポジトリ整合性確認
  • Get-WmiObject -Query 'SELECT * FROM Win32_NTLogEvent WHERE Logfile="System"' -ErrorAction Stop でクエリテスト
  • Get-Counter '\WMI Objects(*)\*' でWMIパフォーマンスカウンター確認
  • Get-Service Winmgmt,RpcSs でサービス状態確認
  • wbemtest で対話的にWMI接続テスト
Sysmonイベントログの大量生成によるシステム負荷増大
想定される原因
  • Sysmonフィルタ設定が広すぎる
  • ログローテーション設定不備
  • マルウェアやノイズの多いアプリによる大量イベント生成
  • Sysmonドライバのバグ
確認手順
  • sysmon -c で現在のSysmon設定を表示
  • Get-WinEvent -LogName 'Microsoft-Windows-Sysmon/Operational' -MaxEvents 100 | Group-Object Id で頻出イベント確認
  • wevtutil gl Microsoft-Windows-Sysmon/Operational でログサイズ確認
  • Get-Process | Sort-Object CPU -Descending | Select -First 10 でCPU消費プロセス確認
  • (Get-Item 'C:\Windows\System32\winevt\Logs\Microsoft-Windows-Sysmon%4Operational.evtx').Length でファイルサイズ確認
イベントログのアーカイブとバックアップの自動化失敗
想定される原因
  • アーカイブ先ディレクトリの権限不足
  • ディスク空き容量不足
  • AutoBackupLogFilesレジストリ設定の不備
  • タスクスケジューラの実行アカウント問題
確認手順
  • reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\Security /v AutoBackupLogFiles でポリシー確認
  • wevtutil gl Security でRetention設定確認
  • dir C:\Windows\System32\winevt\Logs\Archive-* でアーカイブ済みファイル一覧
  • Get-ScheduledTask | Where-Object { $_.TaskName -like '*EventLog*' } でタスク確認
  • icacls C:\Windows\System32\winevt\Logs でログディレクトリの権限確認
EventLog Readers グループの権限設定不備による閲覧制限
想定される原因
  • ユーザーがEvent Log Readersグループに未所属
  • セキュリティログのSDDL設定が制限的すぎる
  • UACによる権限昇格なしでのアクセス
  • GPOによるログアクセス制限
確認手順
  • net localgroup 'Event Log Readers' でグループメンバー確認
  • wevtutil gl Security /f:xml でSDDL設定確認
  • whoami /groups で現在のユーザー権限確認
  • gpresult /r で適用されているポリシー確認
  • Get-WinEvent -LogName Security -MaxEvents 1 -ErrorAction Stop でアクセステスト
ドメインコントローラーのBSODによるADサービス停止
想定される原因
  • NTDSデータベース(ntds.dit)の破損
  • lsass.exeのメモリ破損
  • サードパーティ認証フィルタのクラッシュ
  • 不正なスキーマ拡張によるNTDS不安定化
確認手順
  • dcdiag /v で包括的なDC診断を実行
  • Get-WinEvent -LogName 'Directory Service' -MaxEvents 50 でADイベント確認
  • ntdsutil 'semantic database analysis' 'go' でDB整合性確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=1000]]' でlsassクラッシュ確認
  • repadmin /showrepl でレプリケーション状態確認
Kerberos認証エラーによるログオン失敗の多発
想定される原因
  • クライアントとDC間の時刻差が5分以上
  • パスワードの有効期限切れまたは不一致
  • SPNの重複登録
  • DCのKerberosキーの不整合
確認手順
  • w32tm /query /status でNTP同期状態確認
  • klist を実行してKerberosチケット状態確認
  • setspn -X で重複SPN検出
  • Get-WinEvent -LogName Security -FilterXPath '*[System[EventID=4771]]' -MaxEvents 20 で失敗パターン確認
  • nltest /dsgetdc:<domain> でDC到達性確認
NTDSサービスの起動失敗とデータベースマウントエラー
想定される原因
  • ntds.ditデータベースの破損
  • トランザクションログとDBの不整合
  • ディスク空き容量不足でコミットログ書き込み失敗
  • 不正なオフライン操作によるDB状態不整合
確認手順
  • DSRMモードでブートしesentutl /mh 'C:\Windows\NTDS\ntds.dit' でDB状態確認
  • dir C:\Windows\NTDS\ でDBとログファイルのサイズ確認
  • Get-WinEvent -LogName 'Directory Service' -MaxEvents 100 でエラー詳細確認
  • ディスク空き容量の確認
  • ntdsutil 'files' 'info' で NTDS ファイルパスと状態確認
ADレプリケーションの失敗と lingering objects
想定される原因
  • DCが tombstone lifetime (180日)以上オフラインだった
  • ネットワーク分断による長期間のレプリケーション停止
  • USN rollbackの発生
  • サイト間レプリケーションリンクの設定不備
確認手順
  • repadmin /showrepl * /csv > repl.csv で全DCのレプリケーション状態確認
  • repadmin /replsummary でレプリケーションサマリ表示
  • dcdiag /test:replications で診断テスト
  • repadmin /removelingeringobjects でlingering object検出
  • Get-ADReplicationPartnerMetadata -Target * でパートナー状態確認
LDAP検索のパフォーマンス低下とクエリタイムアウト
想定される原因
  • 検索フィルタのインデックス未作成属性使用
  • 大規模グループのネスト展開
  • MaxPageSizeやMaxResultSetSizeの制限到達
  • 非効率なLDAPクエリ(ワイルドカード先頭一致)
確認手順
  • reg add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v '15 Field Engineering' /t REG_DWORD /d 5 でLDAPログ有効化
  • ntdsutil 'ldap policies' 'connections' 'connect to server <DC>' 'show values' でLDAPポリシー確認
  • Get-WinEvent -LogName 'Directory Service' -FilterXPath '*[System[EventID=1644]]' で高コストクエリ特定
  • dsquery * -filter '(objectClass=user)' -limit 0 -s <DC> で応答時間テスト
  • repadmin /bind <DC> でDC応答確認
SYSVOLのディスク容量枯渇によるGPO配布停止
想定される原因
  • SYSVOL配下に大容量ファイルが配置された
  • DFSRステージングクォータの不足
  • 削除されたGPOの残骸が残っている
  • ログオンスクリプトの肥大化
確認手順
  • dir C:\Windows\SYSVOL\ /s でSYSVOLサイズ確認
  • fsutil volume diskfree C: でディスク残量確認
  • Get-DfsReplicatedFolder -GroupName 'Domain System Volume' | Select StagingPathQuotaInMB でステージング確認
  • Get-GPO -All | Select DisplayName,CreationTime で全GPO一覧
  • dfsrdiag Backlog /smem:<DC1> /rmem:<DC2> /rgname:'Domain System Volume' でバックログ確認
サイト間VPN切断によるDCレプリケーション断絶
想定される原因
  • サイト間VPN/WAN回線の切断
  • ファイアウォールでRPCポートがブロック
  • DNSの不整合によるDC名前解決失敗
  • KCCが生成したトポロジのブリッジヘッド選定問題
確認手順
  • repadmin /showrepl /errorsonly でエラーのあるレプリケーションパートナー確認
  • nltest /dsgetdc:<domain> /site:<remote_site> でリモートサイトDC到達性確認
  • Test-NetConnection -ComputerName <remoteDC> -Port 135 でRPC Endpoint Mapper確認
  • dcdiag /test:connectivity /s:<remoteDC> で接続テスト
  • Get-ADReplicationSiteLink -Filter * でサイトリンク設定確認
FSMOロール移行設定エラーによるドメイン操作失敗
想定される原因
  • FSMOロール保持DCのオフライン化
  • FSMO転送時のレプリケーション未完了
  • 強制seizeのネットワーク分断中の実行
  • RIDプール枯渇
確認手順
  • netdom query fsmo で全FSMOロール保持DC確認
  • dcdiag /test:knowsofroleholders でFSMO認識状態テスト
  • dcdiag /test:ridmanager でRIDプール状態確認
  • Get-ADDomainController -Filter * | Select Name,OperationMasterRoles でロール分散確認
  • repadmin /showrepl <FSMO_DC> でFSMO保持DCのレプリケーション確認
ADデータベースのオンラインデフラグ未実行による肥大化
想定される原因
  • 大量オブジェクト削除後のホワイトスペース増加
  • オフラインデフラグの長期未実施
  • ガベージコレクション間隔の設定不適切
  • 一時的な大量オブジェクト作成と削除の繰り返し
確認手順
  • (Get-Item 'C:\Windows\NTDS\ntds.dit').Length / 1GB でDBサイズ確認
  • Get-WinEvent -LogName 'Directory Service' -FilterXPath '*[System[EventID=700]]' -MaxEvents 5 でデフラグ実行履歴確認
  • ntdsutil 'files' 'info' でDB情報表示
  • Get-ADObject -SearchBase 'CN=Deleted Objects,DC=domain,DC=local' -IncludeDeletedObjects -Filter * | Measure-Object で削除オブジェクト数確認
  • reg query 'HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' /v 'Garbage Collection Interval (hours)' でGC間隔確認
DNSゾーンのAD統合レプリケーション異常
想定される原因
  • ADレプリケーション失敗に伴うDNSパーティション同期遅延
  • DNS Application Partitionの不整合
  • DCプロモーション時のDNSゾーン作成失敗
  • 手動でのDNSレコード誤削除
確認手順
  • dcdiag /test:DNS /DnsDynamicUpdate でDNS動的更新テスト
  • dnscmd /enumzones でゾーン一覧と種類確認
  • repadmin /showrepl <DC> | findstr DomainDnsZones でDNSパーティションのレプリ状態確認
  • nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain> でSRVレコード確認
  • dcdiag /test:RegisterInDNS /DnsDomain:<domain> でDNS登録テスト
グループポリシー処理時のLDAP接続エラー
想定される原因
  • DCへのネットワーク到達性の問題
  • クライアントのDNS設定不備
  • コンピューターアカウントのパスワード不整合
  • SMB署名要求の不一致
確認手順
  • gpresult /r でGP処理結果確認
  • nltest /sc_query:<domain> でセキュアチャネル状態確認
  • Test-ComputerSecureChannel -Server <DC> でセキュアチャネルテスト
  • nslookup <domain> で名前解決確認
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 30 でGP処理ログ確認
ADオブジェクトの誤削除とRecycle Binからの復元
想定される原因
  • 管理者の操作ミス
  • スクリプトによる意図しない一括削除
  • OU保護(誤削除防止)の未設定
  • 委任されたユーザーの権限過剰
確認手順
  • Get-ADObject -Filter {isDeleted -eq $true} -IncludeDeletedObjects -SearchBase 'CN=Deleted Objects,DC=domain,DC=local' -Properties * で削除オブジェクト確認
  • Get-ADOptionalFeature -Filter {Name -like 'Recycle Bin Feature'} でRecycle Bin有効状態確認
  • Get-WinEvent -LogName Security -FilterXPath '*[System[EventID=5141]]' -MaxEvents 20 で削除イベント確認
  • Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion で保護状態確認
  • repadmin /showrepl でレプリケーション完了確認(復元前)
W3WPワーカープロセスのクラッシュによるアプリケーションプール停止
想定される原因
  • アプリケーションコードのハンドルされない例外
  • メモリリークによるOutOfMemoryException
  • スタックオーバーフロー(再帰呼び出し)
  • サードパーティモジュールの不具合
確認手順
  • Get-WebAppPoolState で全アプリケーションプールの状態確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=5011]]' でクラッシュイベント確認
  • Get-WinEvent -LogName Application -FilterXPath '*[System[Provider[@Name="Windows Error Reporting"]]]' -MaxEvents 10 でWER確認
  • C:\inetpub\logs\LogFiles でHTTPステータスコード確認
  • Debug Diagnostics ToolでクラッシュダンプをRecoveryフォルダから分析
Windows認証の失敗によるHTTP 401エラー
想定される原因
  • SPNがサービスアカウントに未登録
  • カスタムポート使用時のSPN設定漏れ
  • NTLM認証が無効化されKerberos only環境でダウングレード不可
  • アプリケーションプールのIDとSPNの不一致
確認手順
  • setspn -L <service_account> でSPN登録確認
  • setspn -Q HTTP/<hostname> でSPN重複確認
  • Get-WebConfigurationProperty -Filter /system.webServer/security/authentication/* -Name enabled で認証設定確認
  • klist でクライアント側チケット確認
  • IISログファイルで401のサブステータスコードを確認
IIS World Wide Web Publishing Serviceが起動しない
想定される原因
  • ポート80/443が他プロセス(Apache, Skype等)で使用中
  • SSL証明書のバインド設定が不正
  • HTTP.sysドライバの初期化失敗
  • 依存サービス(WAS)の未起動
確認手順
  • netstat -ano | findstr ':80' でポート使用プロセス確認
  • netsh http show sslcert でSSL証明書バインド確認
  • Get-Service W3SVC,WAS でサービス状態確認
  • netsh http show urlacl でURL予約確認
  • sc qc W3SVC でサービス依存関係確認
ARR(Application Request Routing)のバックエンドサーバー通信エラー
想定される原因
  • バックエンドサーバーの応答遅延・ダウン
  • ARRタイムアウト設定が短すぎる
  • バックエンドのファイアウォールでIISフロントエンドからの接続ブロック
  • バックエンドのアプリケーションハング
確認手順
  • Test-NetConnection -ComputerName <backend_ip> -Port 8080 でバックエンド接続テスト
  • C:\inetpub\logs\FailedReqLogFiles でFREB(Failed Request Tracing)ログ確認
  • Get-WebConfigurationProperty -pspath 'IIS:\' -filter 'webFarms/webFarm' -name collection でサーバーファーム設定確認
  • IISログでsc-statusとtime-takenの相関確認
  • ARRヘルスチェックのURL応答確認
高トラフィック時のHTTP.sysカーネルキュー溢れ
想定される原因
  • アプリケーション処理速度の低下(DB待ち等)
  • アプリケーションプールのキュー長設定が小さすぎる
  • ワーカープロセス数の不足
  • 外部APIへの同期呼び出しによるスレッド枯渇
確認手順
  • Get-Counter '\HTTP Service Request Queues(*)\CurrentQueueSize' でキュー長確認
  • Get-Counter '\W3SVC_W3WP(*)\Active Requests' でアクティブリクエスト数確認
  • Get-WebConfiguration /system.applicationHost/applicationPools でプール設定確認
  • netsh http show servicestate でHTTP.sys状態確認
  • Performance Monitorで'ASP.NET\Requests Queued'確認
IISログファイルの肥大化によるディスク容量逼迫
想定される原因
  • ログローテーション未設定またはクリーンアップ未実施
  • 高トラフィックサイトでの大量リクエストログ
  • Failed Request Tracingの長期有効化
  • ログファイルの圧縮アーカイブ未設定
確認手順
  • Get-ChildItem C:\inetpub\logs -Recurse | Measure-Object -Property Length -Sum でログ合計サイズ確認
  • Get-WebConfigurationProperty -Filter 'system.applicationHost/sites/site/logFile' -Name * でログ設定確認
  • Get-ChildItem C:\inetpub\logs\LogFiles -Recurse | Sort-Object Length -Descending | Select -First 10 で大きいファイル確認
  • fsutil volume diskfree C: でディスク残量確認
  • Get-WebConfigurationProperty -Filter 'system.applicationHost/sites/site/traceFailedRequestsLogging' -Name enabled で FREB状態確認
SSL/TLS証明書の期限切れによるHTTPS接続エラー
想定される原因
  • SSL証明書の更新忘れ
  • 証明書自動更新(ACME/Let's Encrypt)の失敗
  • 中間証明書の期限切れ
  • バインドに設定された証明書ハッシュの不一致
確認手順
  • Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.NotAfter -lt (Get-Date) } で期限切れ証明書確認
  • netsh http show sslcert で現在のSSLバインド確認
  • Get-WebBinding | Where-Object { $_.protocol -eq 'https' } でHTTPSバインド確認
  • openssl s_client -connect localhost:443 でSSL接続テスト
  • certutil -verify <cert_file> で証明書チェーン検証
ASP.NETアプリケーションのメモリリークによるプールリサイクル頻発
想定される原因
  • アプリケーションコードのメモリリーク(Dispose未呼び出し)
  • 大量のセッションデータのインメモリ保持
  • Static変数へのオブジェクト蓄積
  • サードパーティライブラリのメモリリーク
確認手順
  • Get-Counter '\Process(w3wp*)\Private Bytes' でワーカープロセスメモリ確認
  • Get-Counter '\Process(w3wp*)\Working Set' でワーキングセット確認
  • Get-Counter '\.NET CLR Memory(w3wp*)\# Bytes in all Heaps' でマネージドヒープ確認
  • Get-WebConfigurationProperty -Filter 'system.applicationHost/applicationPools/add[@name="DefaultAppPool"]/recycling/periodicRestart' -Name * でリサイクル設定確認
  • procdump -ma <w3wp_pid> でメモリダンプ取得
URL Rewriteルールの競合によるリダイレクトループ
想定される原因
  • HTTPSリダイレクトルールがロードバランサー背後で常に発火
  • 複数のリダイレクトルールの相互参照
  • ARRとURL Rewriteの組み合わせによる無限ループ
  • web.configの階層的な設定オーバーライドの競合
確認手順
  • Failed Request Tracing(FREB)を有効にしてリダイレクトチェーンを確認
  • appcmd list config '<site>/' /section:system.webServer/rewrite/rules でルール一覧確認
  • curl -v -L --max-redirs 5 http://example.com でリダイレクト追跡
  • web.configの全階層でrewriteルールを確認
  • IISログのsc-status 301/302の繰り返しパターン確認
アプリケーションプールのアイドルタイムアウトによる初回アクセス遅延
想定される原因
  • アイドルタイムアウトが短く設定されている(既定20分)
  • Application Initialization機能が未設定
  • JITコンパイルとアセンブリロードによる初回遅延
  • データベース接続プールの再構築
確認手順
  • Get-WebConfigurationProperty -Filter 'system.applicationHost/applicationPools/add[@name="DefaultAppPool"]/processModel' -Name idleTimeout でタイムアウト値確認
  • Get-WindowsFeature Web-AppInit でApplication Initialization機能インストール確認
  • IISログでtime-takenが突出するリクエストパターン確認
  • Get-WebConfigurationProperty -Filter 'system.applicationHost/applicationPools/add' -Name startMode でスタートモード確認
  • Get-WebConfigurationProperty -Filter 'system.webServer/applicationInitialization' -Name * でプリロード設定確認
IIS暗号スイート設定不備によるTLS接続拒否
想定される原因
  • TLS 1.0/1.1を無効化後に古いクライアントが接続試行
  • 暗号スイートの過度な制限
  • 証明書の鍵タイプ(RSA/ECDSA)と暗号スイートの不一致
  • IIS Crypto等のツールによる過剰な設定変更
確認手順
  • Get-TlsCipherSuite | Format-Table Name で有効な暗号スイート一覧確認
  • reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' /s でプロトコル設定確認
  • nmap --script ssl-enum-ciphers -p 443 <server> で外部からの暗号スイート確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[Provider[@Name="Schannel"]]]' -MaxEvents 20 でSchannelエラー確認
  • ssllabs.comのテスト結果でグレード確認
web.configの構文エラーによるHTTP 500.19
想定される原因
  • web.configのXML構文エラー(タグ閉じ忘れ等)
  • インストールされていないモジュールの設定参照
  • 親レベルでロックされたセクションの変更試行
  • web.configファイルのアクセス権限不足
確認手順
  • appcmd verify config '<site_path>/' で設定検証
  • type C:\inetpub\wwwroot\web.config で内容確認
  • icacls C:\inetpub\wwwroot\web.config でアクセス権確認
  • applicationHost.configのsectionGroup/sectionでロック設定確認
  • Get-WebConfigurationLock -Filter 'system.webServer/rewrite' でセクションロック確認
WSUSサーバーのIISアプリケーションプールクラッシュ
想定される原因
  • WsusPoolのメモリ制限到達
  • WSUSデータベース(SUSDB)の接続タイムアウト
  • Windows Internal Database(WID)のロック競合
  • WSUSコンテンツディレクトリへのアクセス障害
確認手順
  • Get-WebAppPoolState WsusPool でプール状態確認
  • Get-WinEvent -LogName Application -FilterXPath '*[System[Provider[@Name="Windows Server Update Services"]]]' -MaxEvents 20 でWSUSイベント確認
  • Get-Counter '\Process(w3wp*)\Private Bytes' でメモリ使用量確認
  • Test-Path 'C:\WSUS\WsusContent' でコンテンツディレクトリアクセス確認
  • sqlcmd -S np:\\.\pipe\Microsoft##WID\tsql\query -d SUSDB -Q 'SELECT 1' でDB接続テスト
クライアントのWSUS認証エラーによる更新取得失敗
想定される原因
  • WSUS用SSL証明書の信頼チェーン問題
  • クライアントのプロキシ設定によるWSUSアクセスブロック
  • コンピューターアカウントの認証問題
  • WSUS IISサイトのWindows認証設定不備
確認手順
  • wuauclt /detectnow でクライアント側更新検出テスト
  • reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate でWSUS設定確認
  • Get-WindowsUpdateLog でWindows Updateログ生成・確認
  • netsh winhttp show proxy でシステムプロキシ確認
  • Test-NetConnection -ComputerName <wsus_server> -Port 8530 で接続テスト
WSUS同期サービスの起動失敗
想定される原因
  • インターネット接続またはプロキシ設定の問題
  • Microsoft Updateへのファイアウォールブロック
  • WSUSサービスアカウントの権限不足
  • 同期対象の製品/分類が多すぎてタイムアウト
確認手順
  • Get-WsusServer | Get-WsusStatus で同期状態確認
  • Get-Service WsusService でサービス状態確認
  • Test-NetConnection -ComputerName windowsupdate.microsoft.com -Port 443 で接続テスト
  • netsh winhttp show proxy でWSUSサーバーのプロキシ設定確認
  • Get-WsusProduct | Where-Object { $_.UpdatesNeeded -gt 0 } で製品設定確認
WSUSデータベースのレプリカ同期遅延
想定される原因
  • 上流WSUSサーバーとの通信障害
  • レプリカWSUSのIIS/サービスの問題
  • 上流WSUSデータベースの大規模変更(再分類等)
  • ネットワーク帯域制限による同期遅延
確認手順
  • Get-WsusServer -Name <downstream> | Get-WsusStatus でレプリカ状態確認
  • Get-WsusServer | Get-WsusComputer でクライアント報告状態確認
  • 上流WSUSのイベントログで同期完了時刻確認
  • レプリカWSUSからTest-NetConnection -ComputerName <upstream> -Port 8530 で接続テスト
  • WSUSコンソールで「下流サーバー」の最終同期時刻確認
WSUSデータベース(SUSDB)のクエリパフォーマンス劣化
想定される原因
  • SUSDBインデックスの断片化蓄積
  • 不要な更新プログラムメタデータの肥大化
  • WID(Windows Internal Database)のメモリ制限
  • WSUSクリーンアップウィザードの長期未実施
確認手順
  • sqlcmd -S np:\\.\pipe\Microsoft##WID\tsql\query -d SUSDB -Q 'SELECT COUNT(*) FROM tbRevision' でレコード数確認
  • Get-WsusServer | Invoke-WsusServerCleanup -DeclineSupersededUpdates でクリーンアップテスト(DryRun)
  • WSUSコンソールの応答時間を確認
  • タスクマネージャーでsqlservr.exe(WID)のメモリ・CPU使用率確認
  • Get-WinEvent -LogName Application -FilterXPath '*[System[Provider[@Name="Windows Server Update Services"]]]' で警告確認
WSUSコンテンツディレクトリのディスク容量不足
想定される原因
  • 不要な更新プログラムファイルの蓄積
  • 全言語のコンテンツをダウンロード設定
  • 置換された更新プログラムの未クリーンアップ
  • コンテンツディレクトリの初期サイズ見積もり不足
確認手順
  • Get-ChildItem -Path 'C:\WSUS\WsusContent' -Recurse | Measure-Object -Property Length -Sum でコンテンツサイズ確認
  • fsutil volume diskfree <content_drive>: でディスク残量確認
  • Get-WsusServer | Get-WsusUpdate -Status InstalledOrNotApplicable | Measure-Object で不要更新数確認
  • WSUSコンソールで言語設定確認
  • wsusutil checkhealth でヘルスチェック
WSUSクライアントからのレポートがネットワークエラーで届かない
想定される原因
  • WsusPoolのパフォーマンス問題(503エラー)
  • クライアントのネットワーク/プロキシ設定
  • GPOでのWSUS URL設定の不一致
  • WSUS IISの同時接続数制限
確認手順
  • Get-WsusComputer -IncludeDownstreamComputerTargets | Where-Object { $_.LastReportedStatusTime -lt (Get-Date).AddDays(-7) } で未報告クライアント確認
  • WSUSコンソールで「すべてのコンピュータ」の最終連絡時刻確認
  • クライアント側: reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate でWSUS設定確認
  • クライアント側: Test-NetConnection -ComputerName <wsus> -Port 8530 で接続確認
  • WSUS IISログで503エラーの頻度確認
WSUS GPO設定の競合によるクライアント更新動作異常
想定される原因
  • 複数GPOでWSUS設定が競合
  • WUServerとWUStatusServerのURL不一致
  • ローカルポリシーとドメインポリシーの競合
  • Windows Update for Business設定との競合
確認手順
  • gpresult /h report.html でGPO適用結果確認
  • reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /s で全WSUS関連レジストリ確認
  • Get-GPResultantSetOfPolicy -ReportType Html -Path report.html でRSoP確認
  • reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU で自動更新設定確認
  • gpresult /r | findstr 'Windows Update' で適用GPO確認
Windows Update Agent(WUA)の破損による更新エラー
想定される原因
  • SoftwareDistributionフォルダ内のデータストア破損
  • WUA自体のバージョン問題
  • 一時ファイルの蓄積による問題
  • ネットワーク中断による部分ダウンロードの残留
確認手順
  • Get-WindowsUpdateLog でWUログ確認
  • Get-Service wuauserv,bits でサービス状態確認
  • dir C:\Windows\SoftwareDistribution\DataStore でデータストア確認
  • (New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow() で手動検出テスト
  • sfc /scannow でシステムファイル整合性確認
WSUS同期中のSSL接続エラー(上流サーバー)
想定される原因
  • 上流WSUSのSSL証明書の期限切れまたは変更
  • 中間証明書の欠落
  • TLSバージョンの不整合(上流がTLS1.2のみ対応等)
  • 自己署名証明書の信頼チェーン未構成
確認手順
  • openssl s_client -connect <upstream_wsus>:8531 でSSL証明書確認
  • certutil -verify -urlfetch <cert> で証明書チェーン検証
  • Get-ChildItem Cert:\LocalMachine\Root で信頼されたルート証明書確認
  • reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' でTLS設定確認
  • WSUSコンソールで上流サーバーURL設定確認
WSUSサーバーのメモリ不足によるサービス全般の遅延
想定される原因
  • WID(sqlservr.exe)の過度なメモリ消費
  • WsusPoolのメモリリーク
  • サーバーの物理メモリ不足
  • 同時クライアントスキャン数の過多
確認手順
  • Get-Counter '\Memory\Available MBytes' で利用可能メモリ確認
  • Get-Process sqlservr,w3wp | Select ProcessName,WorkingSet64 でプロセスメモリ確認
  • Get-Counter '\Memory\Pool Nonpaged Bytes' で非ページプール確認
  • systeminfo | findstr 'Total Physical Memory' で搭載メモリ確認
  • Get-Counter '\Process(sqlservr)\Private Bytes' でWIDメモリ確認
WSUSデータベースの整合性エラーとメタデータ破損
想定される原因
  • 予期しないサービス停止によるDB破損
  • ディスク障害によるデータファイル損傷
  • WSUSアップグレード中のエラー
  • 長期運用によるメタデータ蓄積と不整合
確認手順
  • sqlcmd -S np:\\.\pipe\Microsoft##WID\tsql\query -d SUSDB -Q 'DBCC CHECKDB' でDB整合性確認
  • WSUSコンソールで更新承認操作が正常に動作するか確認
  • Get-WinEvent -LogName Application -FilterXPath '*[System[EventID=12072]]' でエラー履歴確認
  • wsusutil checkhealth でWSUSヘルスチェック
  • sqlcmd -d SUSDB -Q 'SELECT COUNT(*) FROM tbUpdate WHERE IsHidden=0' で有効更新数確認
仮想マシンのBSOD(ブルースクリーン)発生とVMクラッシュ
想定される原因
  • 仮想ハードウェアドライバ(統合サービス)の互換性問題
  • ホストメモリ過負荷によるVMメモリ不足
  • VHD/VHDXファイルの破損
  • CPUの物理的障害またはオーバーコミット
確認手順
  • Get-VM | Where-Object { $_.State -eq 'Paused' -or $_.State -eq 'Off' } で異常VM確認
  • Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-Worker-Admin' -MaxEvents 20 でワーカーイベント確認
  • Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-VMMS-Admin' -MaxEvents 20 でVMMS確認
  • Get-VMIntegrationService -VMName <vm> で統合サービス状態確認
  • Test-VHD -Path <vhdx_path> でVHDX整合性確認
仮想マシンへのRDP/コンソール接続認証エラー
想定される原因
  • CredSSP暗号化オラクル修復ポリシーの不一致
  • Enhanced Sessionモードの設定問題
  • VMのRDP証明書の期限切れ
  • ホストとVMのCredSSP設定の不一致
確認手順
  • Get-VMHost | Select EnableEnhancedSessionMode でEnhanced Session設定確認
  • reg query 'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' /v AllowEncryptionOracle でCredSSP設定確認
  • Get-VM -Name <vm> | Get-VMIntegrationService でゲストサービス状態確認
  • VMConnect.exe でコンソール接続テスト
  • Hyper-Vマネージャーの接続設定確認
Hyper-V Virtual Machine Management Service(VMMS)の起動失敗
想定される原因
  • Hyper-Vの構成データベースの破損
  • WMIリポジトリの破損
  • VMM証明書の問題
  • BIOS/UEFIでの仮想化支援機能の無効化
確認手順
  • Get-Service vmms でサービス状態確認
  • Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-VMMS-Admin' -MaxEvents 30 でVMMSイベント確認
  • systeminfo | findstr 'Hyper-V' でHyper-V要件確認
  • winmgmt /verifyrepository でWMI整合性確認
  • Get-VM -ErrorAction SilentlyContinue でVM一覧アクセステスト
Hyper-Vレプリカのレプリケーション失敗
想定される原因
  • ネットワーク帯域不足による転送タイムアウト
  • レプリカサーバーのディスク容量不足
  • 証明書ベース認証の期限切れ
  • VMの変更量(チャーン率)が高すぎる
確認手順
  • Get-VMReplication | Select VMName,Health,State,LastReplicationTime でレプリカ状態一覧
  • Measure-VMReplication -VMName <vm> でレプリケーション統計確認
  • Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-VMMS-Admin' -FilterXPath '*[System[EventID=32022]]' でエラー確認
  • Test-NetConnection -ComputerName <replica_server> -Port 443 で接続テスト
  • Get-VMReplicationServer でレプリカサーバー設定確認
仮想マシンの動的メモリ割り当て不足によるパフォーマンス低下
想定される原因
  • ホストの物理メモリ過負荷(全VMの合計要求超過)
  • 動的メモリの最大値設定が低すぎる
  • VM内アプリケーションのメモリリーク
  • Smart Pagingファイルの使用によるI/O低下
確認手順
  • Get-VM | Select Name,MemoryAssigned,MemoryDemand,MemoryStatus でVM メモリ状態確認
  • Get-Counter '\Hyper-V Dynamic Memory Balancer(*)\Available Memory' でバランサー状態確認
  • Get-VMMemory -VMName <vm> で動的メモリ設定確認
  • Get-Counter '\Memory\Available MBytes' でホストメモリ確認
  • Get-VM | Where-Object { $_.MemoryStatus -ne 'OK' } でメモリ問題VM確認
VHDXファイルの肥大化とストレージ容量枯渇
想定される原因
  • 容量可変VHDXの無制限拡大
  • チェックポイント(スナップショット)の蓄積
  • VM内でのログファイルや一時ファイルの肥大化
  • 削除済みチェックポイントのマージ未完了
確認手順
  • Get-VHD -Path <vhdx_path> | Select VhdType,FileSize,Size でVHDX情報確認
  • Get-VM | Get-VMCheckpoint で全VMのチェックポイント確認
  • Get-ChildItem -Path <vm_storage_path> -Include *.vhdx,*.avhdx -Recurse | Sort-Object Length -Descending でファイルサイズ確認
  • fsutil volume diskfree <storage_drive>: でホストディスク残量確認
  • Get-VM | Get-VMHardDiskDrive | Get-VHD | Select Path,FileSize でVM全ディスク確認
仮想スイッチのネットワーク接続断
想定される原因
  • 物理NICのドライバ更新によるバインド解除
  • NICチーミング設定の変更
  • 物理ネットワークアダプタの障害
  • Windows Updateによるネットワークドライバ変更
確認手順
  • Get-VMSwitch で仮想スイッチ一覧と状態確認
  • Get-VMSwitch -Name <switch> | Select NetAdapterInterfaceDescription でバインドNIC確認
  • Get-NetAdapter でホスト物理NIC状態確認
  • Get-VMNetworkAdapter -VMName <vm> でVMのネットワークアダプタ状態確認
  • Get-NetLbfoTeam でNICチーミング状態確認(使用時)
VMの構成ファイル(vmcx)破損による起動不可
想定される原因
  • 予期しないホスト停止による構成ファイル破損
  • 異なるバージョンのHyper-Vホスト間でのVM移動
  • ストレージ障害によるファイル損傷
  • 手動でのファイル操作による不整合
確認手順
  • Get-VM -Name <vm> -ErrorAction SilentlyContinue でVM読み込み確認
  • Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-Config-Admin' -MaxEvents 20 で構成イベント確認
  • Test-Path '<vm_path>\Virtual Machines\*.vmcx' で構成ファイル存在確認
  • Get-VMHost | Select VirtualMachineMigrationEnabled,VirtualMachinePath で設定確認
  • Get-VM | Select Name,Version で構成バージョン一覧確認
Live Migration失敗とVMの移動不可
想定される原因
  • ソース・宛先ホスト間のCPU互換性問題
  • 移行ネットワークの帯域不足
  • VMのメモリ変更率がネットワーク転送速度を超過
  • ConstrainedGroup/セキュリティ設定の不一致
確認手順
  • Compare-VM -CompatibilityReport -VM <vm> -DestinationHost <host> で互換性チェック
  • Get-VMHost | Select VirtualMachineMigrationEnabled,MaximumVirtualMachineMigrations で移行設定確認
  • Get-VMMigrationNetwork でLive Migration用ネットワーク確認
  • Test-NetConnection -ComputerName <dest_host> -Port 6600 で移行ポート接続テスト
  • Get-VM -Name <vm> | Select ProcessorCount,MemoryAssigned でVM仕様確認
仮想マシンのCPUパフォーマンス問題(CPUレディ時間の増大)
想定される原因
  • ホストCPUの物理コア数に対してVM仮想プロセッサが過剰割当
  • 特定VMのCPU独占によるスケジューリング競合
  • 電源管理設定によるCPUパフォーマンス制限
  • NUMAノード間のスケジューリング非効率
確認手順
  • Get-Counter '\Hyper-V Hypervisor Virtual Processor(*)\% Guest Run Time' でVMのCPU使用率確認
  • Get-Counter '\Hyper-V Hypervisor Logical Processor(*)\% Total Run Time' でホストCPU確認
  • Get-VM | Select Name,ProcessorCount | Sort-Object ProcessorCount -Descending でvCPU割当確認
  • Get-Counter '\Hyper-V Hypervisor Root Virtual Processor(*)\% Total Run Time' でルートパーティション確認
  • Get-VMProcessor -VMName <vm> で予約/上限/相対ウェイト確認
Hyper-V統合サービスの不整合によるゲストOS管理機能停止
想定される原因
  • 統合サービスのバージョン不一致(ホスト/ゲスト)
  • ゲストOSのVMICドライバ破損
  • ゲストOSのハングまたは過負荷
  • 統合サービスが無効化されている
確認手順
  • Get-VMIntegrationService -VMName <vm> | Select Name,Enabled,PrimaryStatusDescription で統合サービス状態確認
  • Get-VM -Name <vm> | Select Heartbeat でハートビート状態確認
  • Get-VMIntegrationService -VMName <vm> -Name 'Time Synchronization' で時刻同期状態確認
  • VM内: Get-Service vmicheartbeat,vmictimesync,vmicvss でVMICサービス確認
  • Get-VM | Where-Object { $_.Heartbeat -ne 'OkApplicationsHealthy' } で問題VM一覧
Hyper-Vホストのセキュリティ設定によるShielded VM操作エラー
想定される原因
  • HGS(Host Guardian Service)との通信障害
  • ホストのTPMまたはSecure Boot設定の問題
  • Code Integrityポリシーの不一致
  • HGS認証局の証明書期限切れ
確認手順
  • Get-HgsClientConfiguration でHGSクライアント設定確認
  • Get-HgsAttestationBaselinePolicy でベースラインポリシー確認
  • (Invoke-WebRequest -Uri 'http://hgs.domain.local/Attestation/admin/metadata').StatusCode でHGS接続テスト
  • tpmtool getdeviceinformation でTPM状態確認
  • Confirm-HgsRegistration でホスト登録確認
DHCPサーバーサービスのクラッシュによるIP配布停止
想定される原因
  • DHCPデータベース(dhcp.mdb/dhcp.jdb)の破損
  • JETデータベースエンジンのトランザクションログ不整合
  • メモリ不足によるサービスクラッシュ
  • サードパーティDHCPフィルタの不具合
確認手順
  • Get-Service DHCPServer でサービス状態確認
  • Get-WinEvent -LogName 'Microsoft-Windows-DHCP-Server/Operational' -MaxEvents 30 でDHCPイベント確認
  • dir C:\Windows\System32\dhcp\ でデータベースファイル確認
  • Get-DhcpServerv4Scope でスコープ設定確認
  • netsh dhcp server show dbproperties でDB設定確認
DNS動的更新の認証エラーによるレコード登録失敗
想定される原因
  • DNSレコードの所有者がDHCPサーバーアカウントと不一致
  • DnsUpdateProxy グループの設定不備
  • DHCP Credential設定のサービスアカウント権限不足
  • Secure Only更新ゾーン設定でのACL問題
確認手順
  • Get-DhcpServerv4DnsSetting でDHCP DNS更新設定確認
  • Get-DhcpServerDnsCredential でDNS更新用資格情報確認
  • dnscmd /zoneinfo <zone> でゾーンの動的更新設定確認
  • Get-DnsServerResourceRecord -ZoneName <zone> -Name <host> でレコード所有者確認
  • net group DnsUpdateProxy /domain でグループメンバー確認
DNSサーバーサービスの起動失敗
想定される原因
  • Active Directoryサービス(NTDS)が未起動
  • AD統合ゾーンへのアクセス権限不足
  • DNSデータベースファイル(ファイルバックゾーン)の破損
  • ネットワークインターフェースのバインド設定問題
確認手順
  • Get-Service DNS,NTDS でDNSとADサービス状態確認
  • Get-WinEvent -LogName 'DNS Server' -MaxEvents 30 でDNSイベント確認
  • dnscmd /info でDNSサーバー設定確認
  • nslookup localhost でローカルDNS応答テスト
  • dcdiag /test:DNS でDNS関連診断
DHCPフェールオーバーのパートナー間同期障害
想定される原因
  • パートナーサーバーへのネットワーク到達性問題
  • フェールオーバー用ポート(647)のファイアウォールブロック
  • パートナーDHCPサービスの停止
  • MCLT(Maximum Client Lead Time)超過による状態遷移
確認手順
  • Get-DhcpServerv4Failover でフェールオーバー関係の状態確認
  • Test-NetConnection -ComputerName <partner> -Port 647 でフェールオーバーポート接続テスト
  • Get-DhcpServerv4Lease -ScopeId <scope> | Measure-Object でリース数比較(両サーバー)
  • Get-WinEvent -LogName 'Microsoft-Windows-DHCP-Server/FilterNotifications' -MaxEvents 20 でフィルタイベント確認
  • netsh dhcp server show failover でフェールオーバー詳細確認
DNS再帰クエリの高負荷によるサーバー応答遅延
想定される原因
  • フォワーダーサーバーの応答遅延・障害
  • インターネット回線の帯域飽和
  • DNSキャッシュサイズの不足
  • 大量のキャッシュミスによる再帰クエリ増大
確認手順
  • Get-DnsServerStatistics でDNS統計情報確認
  • Get-DnsServerForwarder でフォワーダー設定確認
  • Resolve-DnsName -Name example.com -DnsOnly | Measure-Command で応答時間計測
  • Get-Counter '\DNS\Recursive Queries/sec' で再帰クエリ数確認
  • Get-DnsServerCache | Measure-Object でキャッシュエントリ数確認
DHCPスコープのIPアドレス枯渇
想定される原因
  • スコープ範囲に対してクライアント数が多すぎる
  • リース期間が長すぎて未使用アドレスが解放されない
  • 不正デバイスの大量接続
  • 予約アドレスの過剰設定
確認手順
  • Get-DhcpServerv4ScopeStatistics でスコープ使用率確認
  • Get-DhcpServerv4Lease -ScopeId <scope> | Measure-Object でアクティブリース数確認
  • Get-DhcpServerv4Lease -ScopeId <scope> | Sort-Object LeaseExpiryTime でリース期限確認
  • Get-DhcpServerv4Reservation -ScopeId <scope> | Measure-Object で予約数確認
  • Get-DhcpServerv4Scope | Select ScopeId,SubnetMask,StartRange,EndRange でスコープ範囲確認
DNSフォワーダーへの接続タイムアウト
想定される原因
  • フォワーダーIPへのネットワーク経路の問題
  • ファイアウォールでDNS(UDP/TCP 53)がブロック
  • ISPのDNSサーバー障害
  • DNS over TLS/HTTPS設定の不整合
確認手順
  • Test-NetConnection -ComputerName 8.8.8.8 -Port 53 でフォワーダー到達性確認
  • Resolve-DnsName example.com -Server 8.8.8.8 でフォワーダー直接クエリテスト
  • Get-DnsServerForwarder でフォワーダーIP一覧確認
  • Get-NetFirewallRule | Where-Object { $_.DisplayName -like '*DNS*' } でFWルール確認
  • tracert 8.8.8.8 でネットワーク経路確認
DHCPオプション設定の誤りによるクライアントネットワーク障害
想定される原因
  • スコープオプションのIPアドレス入力ミス
  • サーバーオプションとスコープオプションの競合
  • ネットワーク変更後のDHCPオプション更新忘れ
  • ポリシーベースのオプション設定の優先度問題
確認手順
  • Get-DhcpServerv4OptionValue -ScopeId <scope> で全スコープオプション確認
  • Get-DhcpServerv4OptionValue で全サーバーオプション確認
  • Get-DhcpServerv4Policy -ScopeId <scope> でポリシー設定確認
  • ipconfig /all(クライアント側)で実際に配布された設定確認
  • ping <gateway_from_dhcp> でゲートウェイ到達性確認
DNSゾーン転送の失敗(プライマリ・セカンダリ間)
想定される原因
  • ゾーン転送許可リスト(NS/IP)にセカンダリが未登録
  • ファイアウォールでTCP 53がブロック(AXFRはTCP使用)
  • プライマリDNSのゾーン転送設定でセカンダリIPが許可されていない
  • ネットワーク分断による転送失敗の蓄積
確認手順
  • Get-DnsServerZone -Name <zone> | Select ZoneType,SecureSecondaries,SecondaryServers でゾーン転送設定確認
  • dnscmd <primary> /zoneinfo <zone> でゾーン情報詳細確認
  • Test-NetConnection -ComputerName <primary> -Port 53 でTCP53接続テスト
  • nslookup -type=SOA <zone> <primary> とnslookup -type=SOA <zone> <secondary> でシリアル番号比較
  • Get-WinEvent -LogName 'DNS Server' -FilterXPath '*[System[EventID=6522]]' で転送エラー確認
DHCP Relay Agent(IPヘルパー)の動作不良
想定される原因
  • ルーター/L3スイッチのIP helper-address設定漏れ
  • DHCPサーバーへのルーティング問題
  • ファイアウォールでUDP 67/68がブロック
  • DHCP Relay Agentサービスの未起動
確認手順
  • ルーター/L3スイッチの設定確認(ip helper-address)
  • Test-NetConnection -ComputerName <dhcp_server> -Port 67 -InformationLevel Quiet で接続テスト
  • DHCPサーバー側でGet-DhcpServerv4Scope でリモートサブネット用スコープ確認
  • パケットキャプチャでDHCP Discover/Offerの流れを確認
  • DHCPサーバーのイベントログでリモートサブネットからのリクエスト受信確認
DNS Scavengingによる必要レコードの誤削除
想定される原因
  • タイムスタンプ付きで作成された静的レコード
  • No-Refresh/Refresh間隔の設定が短すぎる
  • サーバーが長期間オフラインで動的更新されなかった
  • Scavengingが有効なゾーンでの手動レコードの誤設定
確認手順
  • Get-DnsServerScavenging でScavenging設定確認
  • Get-DnsServerZoneAging -Name <zone> でゾーンのエージング設定確認
  • Get-DnsServerResourceRecord -ZoneName <zone> | Where-Object { $_.Timestamp -ne $null } でタイムスタンプ付きレコード確認
  • Get-WinEvent -LogName 'DNS Server' -FilterXPath '*[System[EventID=2502]]' でScavenging実行履歴確認
  • dnscmd /ageallrecords <zone> でエージング対象レコード確認(実行注意)
DHCPスコープの分割統合によるアドレス重複
想定される原因
  • 複数DHCPサーバーで重複するスコープ範囲を配布
  • 静的IP設定デバイスとDHCP範囲の重複
  • DHCPフェールオーバー設定不備による重複割当
  • 以前のDHCPリースと新規リースの競合
確認手順
  • Get-DhcpServerv4Lease -ScopeId <scope> | Where-Object { $_.AddressState -like '*InactiveReservation*' -or $_.AddressState -like '*Conflict*' } で競合リース確認
  • Get-DhcpServerv4Scope | Select ScopeId,StartRange,EndRange で全スコープ範囲確認
  • Set-DhcpServerv4Scope -ScopeId <scope> -ConflictDetectionAttempts 2 で競合検出の有効化確認
  • arp -a でARP テーブル確認(重複IPのMAC確認)
  • 複数DHCPサーバーのスコープ範囲の重複チェック
クラスターノードのBSODによるフェールオーバー発生
想定される原因
  • ストレージドライバの障害によるカーネルパニック
  • メモリ障害(ECC訂正不能エラー)
  • クラスターCSV(Cluster Shared Volume)アクセス障害
  • iSCSI/FC HBA ドライバの不具合
確認手順
  • Get-ClusterNode | Select Name,State でノード状態確認
  • Get-ClusterLog -Destination C:\Temp でクラスターログ出力
  • Get-WinEvent -LogName 'Microsoft-Windows-FailoverClustering/Operational' -MaxEvents 50 でイベント確認
  • Get-ClusterResource | Where-Object { $_.OwnerNode -eq 'Node02' } で影響リソース確認
  • 障害ノードのメモリダンプ(C:\Windows\MEMORY.DMP)を分析
クラスター認証エラーによるノード参加失敗
想定される原因
  • CNO(クラスター名オブジェクト)のAD権限不足
  • コンピューターアカウントのパスワード不整合
  • Kerberos認証のSPN問題
  • クラスターに追加するノードのドメイン参加問題
確認手順
  • Get-ClusterNode でクラスターメンバーシップ確認
  • Test-Cluster -Node <node> でクラスター検証テスト
  • Get-ADComputer <cluster_name> -Properties * でCNOオブジェクトのAD属性確認
  • nltest /sc_query:<domain> でノードのセキュアチャネル確認
  • dsacls でCNOのAD権限確認
クラスターサービス(ClusSvc)の起動失敗
想定される原因
  • クォーラム構成の過半数ノードがダウン
  • Witnessリソース(ファイル共有/クラウド)への接続障害
  • クラスターハイブ(CLUSDB)の破損
  • ネットワーク分断によるスプリットブレイン
確認手順
  • Get-Service ClusSvc でサービス状態確認
  • Get-ClusterQuorum でクォーラム構成確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[Provider[@Name="Microsoft-Windows-FailoverClustering"]]]' -MaxEvents 30 でイベント確認
  • Test-NetConnection -ComputerName <witness_server> -Port 445 でWitness接続テスト
  • cluster /quorum でクォーラム状態確認
Cluster Shared Volume(CSV)のレプリケーション遅延
想定される原因
  • ウイルス対策ソフトのCSVファイルシステムフィルタ干渉
  • CSVネットワーク(ハートビート)の帯域不足
  • ストレージのI/Oレイテンシ増大
  • CSVボリュームの所有者ノードの高負荷
確認手順
  • Get-ClusterSharedVolume | Select Name,State,OwnerNode でCSV状態確認
  • Get-ClusterSharedVolumeState でCSV詳細状態確認
  • Get-Counter '\Cluster CSV Volume Manager(*)\Redirected Read Bytes/sec' でリダイレクトI/O確認
  • Get-ClusterNetwork でクラスターネットワーク状態確認
  • ウイルス対策ソフトのCSV除外設定確認
クラスターリソースの応答遅延とヘルスチェック失敗
想定される原因
  • リソース(SQL/IIS等)の内部デッドロック
  • ストレージI/Oの長時間ブロック
  • メモリ不足によるリソース応答遅延
  • ヘルスチェックのタイムアウト設定が短すぎる
確認手順
  • Get-ClusterResource | Select Name,State,OwnerNode でリソース状態確認
  • Get-ClusterResource '<resource>' | Get-ClusterParameter でリソースパラメータ確認
  • Get-ClusterLog でIsAlive/LooksAlive失敗の詳細確認
  • Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read' でストレージレイテンシ確認
  • Get-ClusterResource '<resource>' | Get-ClusterParameter -Name LooksAliveInterval,IsAliveInterval でヘルスチェック間隔確認
クラスターストレージ(共有ディスク)のI/Oエラー
想定される原因
  • SAN/iSCSIパスの障害
  • MPIO(マルチパスI/O)の設定問題
  • ストレージのLUNマスキング/ゾーニングエラー
  • ディスクのハードウェア障害
確認手順
  • Get-ClusterResource -ResourceType 'Physical Disk' | Select Name,State でディスクリソース確認
  • mpclaim -s -d でMPIOパス状態確認
  • Get-PhysicalDisk | Select FriendlyName,HealthStatus,OperationalStatus でディスク状態確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=153]]' でI/Oリトライ確認
  • iscsicli reporttargetmappings でiSCSIターゲット確認
クラスターハートビートネットワークの断絶
想定される原因
  • ハートビート用NICの障害
  • スイッチ/ケーブルの物理障害
  • NICチーミングの誤設定
  • ネットワーク輻輳によるハートビートパケットのドロップ
確認手順
  • Get-ClusterNetwork | Select Name,State,Role でネットワーク状態確認
  • Get-ClusterNetworkInterface | Select Node,Network,State でNIC状態確認
  • Test-NetConnection -ComputerName <other_node> でノード間接続テスト
  • Get-NetAdapter でNIC物理状態確認
  • Get-ClusterLog | Select-String 'heartbeat' でハートビート関連ログ確認
クラスタークォーラム設定のWitness障害
想定される原因
  • Witness共有先サーバーの停止/ネットワーク障害
  • Witnessファイル共有のACL/アクセス権問題
  • Cloud Witnessのストレージアカウントキー変更
  • SMBバージョンの不一致
確認手順
  • Get-ClusterQuorum でクォーラム設定確認
  • Get-ClusterResource | Where-Object { $_.ResourceType -like '*Witness*' } | Select Name,State でWitness状態確認
  • Test-Path \\<server>\<share> でWitness共有アクセス確認
  • Get-ClusterResource 'File Share Witness' | Get-ClusterParameter でWitnessパラメータ確認
  • az storage account show --name <account> でCloud Witnessストレージ確認
クラスターの可用性グループ(AG)リスナーDNS登録エラー
想定される原因
  • DNSの動的更新権限不足(CNOアカウント)
  • リスナーIPアドレスが既に使用されている
  • DNSゾーンのSecure Update設定による登録拒否
  • 複数サブネット環境でのDNS登録問題
確認手順
  • Get-ClusterResource '<listener_name>' | Get-ClusterParameter でリスナー設定確認
  • nslookup <listener_name> でDNS登録状態確認
  • Get-ClusterResource '<listener_name>' | Select Name,State でリスナー状態確認
  • Test-NetConnection -ComputerName <listener_ip> -Port 1433 でリスナー接続テスト
  • Get-DnsServerResourceRecord -ZoneName <zone> -Name <listener> でDNSレコード確認
Storage Spaces Directのディスク障害とプール修復
想定される原因
  • 物理ディスクの障害またはSMART警告
  • ディスクの接続不良/コントローラ問題
  • ストレージプールの容量不足で修復不可
  • ファームウェアの不具合
確認手順
  • Get-PhysicalDisk | Where-Object { $_.HealthStatus -ne 'Healthy' } で障害ディスク確認
  • Get-VirtualDisk | Select FriendlyName,HealthStatus,OperationalStatus で仮想ディスク状態確認
  • Get-StoragePool | Select FriendlyName,HealthStatus でプール状態確認
  • Get-StorageJob で進行中の修復ジョブ確認
  • Get-PhysicalDisk | Select FriendlyName,MediaType,Usage,HealthStatus でディスク詳細確認
クラスターロールの手動移動中のドレインエラー
想定される原因
  • Live Migration対象VMのメモリ変更率が高い
  • クラスターネットワーク帯域の不足
  • 移動先ノードのリソース不足
  • リソースの依存関係による移動順序問題
確認手順
  • Get-ClusterGroup | Select Name,OwnerNode,State で全ロール状態確認
  • Get-ClusterNode <node> | Select DrainStatus でドレイン状態確認
  • Get-ClusterResource | Where-Object { $_.State -eq 'Online Pending' -or $_.State -eq 'Offline Pending' } で保留リソース確認
  • Get-Counter '\Hyper-V Hypervisor Logical Processor(*)\% Total Run Time' で移動先ノードCPU確認
  • Get-ClusterLog | Select-String 'drain' で ドレイン関連ログ確認
クラスター対応更新(CAU)の適用失敗
想定される原因
  • 更新プログラムのインストールエラー
  • リブート後にクラスターサービスが起動しない
  • ドレイン操作の失敗による更新中断
  • Pre/Post-UpdateスクリプトのエラーやWSUS接続問題
確認手順
  • Get-CauRun -ClusterName <cluster> で最新CAU実行結果確認
  • Get-CauReport -ClusterName <cluster> -Last 5 でCAUレポート確認
  • Get-WinEvent -LogName 'Microsoft-Windows-ClusterAwareUpdating/Admin' -MaxEvents 30 でCAUイベント確認
  • Test-CauSetup -ClusterName <cluster> でCAU前提条件テスト
  • Get-CauPlugin でCAUプラグイン設定確認
カーネルメモリリークによるシステムBSOD
想定される原因
  • サードパーティドライバのメモリリーク
  • ネットワークドライバのバッファリーク
  • ファイルシステムフィルタドライバの不具合
  • ハンドルリークの累積
確認手順
  • poolmon.exe で pool tag 別メモリ使用量確認(Bバイト降順)
  • Get-Counter '\Memory\Pool Nonpaged Bytes' で非ページプール使用量確認
  • Get-Counter '\Memory\Pool Paged Bytes' でページプール使用量確認
  • Get-Process | Sort-Object Handles -Descending | Select -First 10 でハンドル数確認
  • verifier /query でドライバ検証ツール状態確認
NTLM認証の多用によるLSASS CPU高負荷
想定される原因
  • アプリケーションがKerberosではなくNTLMを使用
  • NTLM制限ポリシー未適用で無制限にNTLM認証を許可
  • ブルートフォース攻撃によるNTLM認証の大量試行
  • レガシーアプリケーションのNTLM依存
確認手順
  • Get-Counter '\Process(lsass)\% Processor Time' でLSASS CPU使用率確認
  • Get-Counter '\NTLM Authentication(*)\*' でNTLM認証統計確認
  • Get-WinEvent -LogName Security -FilterXPath '*[System[EventID=4776]]' -MaxEvents 100 | Group-Object -Property { $_.Properties[1].Value } でNTLM認証元集計
  • nltest /sc_query:<domain> でセキュアチャネル確認
  • Get-Counter '\Process(lsass)\Working Set' でLSASSメモリ確認
Windows Updateサービスによる予期しないCPU/ディスク高負荷
想定される原因
  • コンポーネントストアの破損
  • SoftwareDistributionフォルダの肥大化
  • 保留中のWindows Updateの累積
  • WMI/CBS処理のデッドロック
確認手順
  • Get-Counter '\Process(TrustedInstaller)\% Processor Time' でCPU確認
  • Get-Counter '\Process(svchost*)\% Processor Time' でsvchost確認(wuauserv特定)
  • Get-WindowsUpdateLog でWUの処理状態確認
  • DISM /Online /Cleanup-Image /CheckHealth でコンポーネントストア確認
  • (Get-ChildItem C:\Windows\SoftwareDistribution -Recurse | Measure-Object Length -Sum).Sum / 1GB でSoftwareDistributionサイズ確認
DFSレプリケーションのバックログ蓄積
想定される原因
  • ネットワーク帯域の制限/スケジュール設定
  • 大量のファイル変更(データ移行等)
  • ステージングフォルダのクォータ不足
  • パートナーDFSRサービスの問題
確認手順
  • dfsrdiag Backlog /smem:<server1> /rmem:<server2> /rgname:<group> /rfname:<folder> でバックログ確認
  • Get-DfsrBacklog -GroupName <group> -FolderName <folder> -SourceComputerName <src> -DestinationComputerName <dst> でバックログ確認
  • Get-DfsReplicationGroup | Get-DfsReplicatedFolder | Select GroupName,FolderName,StagingPathQuotaInMB でステージング確認
  • Get-DfsrState -GroupName <group> で状態確認
  • Get-Counter '\DFS Replication Service Volumes(*)\*' でDFSRカウンター確認
CPU使用率の継続的高騰とプロセスハング
想定される原因
  • アプリケーションのコードバグ(無限ループ)
  • 暴走クエリ(SQL Server等)
  • マルウェアによるCPUリソース消費
  • WMIプロバイダのハング
確認手順
  • Get-Counter '\Processor(*)\% Processor Time' でCPU使用率確認
  • Get-Process | Sort-Object CPU -Descending | Select -First 10 Name,Id,CPU でトッププロセス確認
  • Get-Counter '\Process(*)\% Processor Time' | Sort-Object CookedValue -Descending でプロセス別CPU確認
  • Get-Counter '\System\Processor Queue Length' でプロセッサキュー長確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=2004]]' でリソース警告確認
ディスクI/O飽和によるシステム全体の応答遅延
想定される原因
  • 同時書き込みプロセスの競合(バックアップ+業務)
  • HDDの物理劣化(セクタ不良)
  • RAIDリビルド中のパフォーマンス低下
  • 不適切なストレージ階層(SSD必要な場所にHDD)
確認手順
  • Get-Counter '\PhysicalDisk(*)\Avg. Disk Queue Length' でキュー長確認
  • Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Read','\PhysicalDisk(*)\Avg. Disk sec/Write' でレイテンシ確認
  • Get-Counter '\PhysicalDisk(*)\Disk Bytes/sec' でスループット確認
  • Get-PhysicalDisk | Select FriendlyName,MediaType,HealthStatus でディスク状態確認
  • Resource Monitor > Disk タブ で I/O アクティビティの高いプロセス特定
TCPポート枯渇によるネットワーク接続失敗
想定される原因
  • アプリケーションのHTTP接続未クローズ(接続プール未使用)
  • 大量の短命接続によるTIME_WAIT蓄積
  • エフェメラルポート範囲の設定が狭い
  • マイクロサービス間の過度な短命接続
確認手順
  • netstat -ano | findstr TIME_WAIT | find /c /v '' でTIME_WAIT接続数確認
  • Get-NetTCPConnection | Group-Object State | Sort-Object Count -Descending で接続状態分布確認
  • netsh int ipv4 show dynamicport tcp でエフェメラルポート範囲確認
  • Get-Counter '\TCPv4\Connections Established' で確立済み接続数確認
  • Get-NetTCPConnection -State TimeWait | Group-Object OwningProcess | Sort-Object Count -Descending で原因プロセス特定
WMIリポジトリ破損によるシステム監視機能停止
想定される原因
  • 不正なシャットダウンによるリポジトリ破損
  • サードパーティWMIプロバイダの不具合
  • ディスク障害によるMOFファイル破損
  • WMIサブスクリプションの蓄積
確認手順
  • winmgmt /verifyrepository でリポジトリ整合性確認
  • Get-WmiObject Win32_OperatingSystem -ErrorAction Stop でWMI基本テスト
  • Get-WinEvent -LogName 'Microsoft-Windows-WMI-Activity/Operational' -MaxEvents 30 でWMI活動ログ確認
  • Get-CimInstance Win32_Process -ErrorAction Stop でCIM接続テスト
  • wbemtest で対話テスト
メモリ不足によるページファイル過剰使用
想定される原因
  • アプリケーションのメモリリーク
  • 物理メモリに対してワークロードが過大
  • ページファイルサイズの不適切な固定設定
  • メモリ集約型プロセスの同時実行
確認手順
  • Get-Counter '\Memory\Available MBytes' で利用可能メモリ確認
  • Get-Counter '\Memory\% Committed Bytes In Use' でコミットチャージ確認
  • Get-Counter '\Memory\Pages/sec' でページング頻度確認
  • Get-Counter '\Paging File(*)\% Usage' でページファイル使用率確認
  • Get-Process | Sort-Object WorkingSet64 -Descending | Select -First 10 Name,@{N='WS(GB)';E={$_.WorkingSet64/1GB}} でメモリ消費プロセス確認
Windowsサービスのハンドルリークによるシステム不安定化
想定される原因
  • サービスのコードバグ(ハンドルClose漏れ)
  • COMオブジェクトの解放漏れ
  • レジストリキーのCloseKey漏れ
  • タイマーキューハンドルのリーク
確認手順
  • Get-Process | Sort-Object HandleCount -Descending | Select -First 10 Name,Id,HandleCount でハンドル数確認
  • Get-Counter '\Process(*)\Handle Count' でプロセス別ハンドル数確認
  • Get-Counter '\Objects\Processes','\Objects\Threads','\Objects\Handles' でシステム全体オブジェクト数確認
  • Process Explorer でハンドルの種類別内訳確認
  • !htrace でハンドルトレース(WinDbg、ダンプ分析時)
ネットワーク帯域飽和によるスループット低下
想定される原因
  • バックアップジョブによる帯域独占
  • DDoS攻撃やネットワークストーム
  • NICの速度設定問題(100Mbpsに固定等)
  • 単一サーバーへの過剰なファイル共有アクセス
確認手順
  • Get-Counter '\Network Interface(*)\Bytes Total/sec' でNIC帯域使用量確認
  • Get-Counter '\Network Interface(*)\Output Queue Length' で出力キュー確認
  • Get-Counter '\Network Interface(*)\Packets Received Discarded' でドロップパケット確認
  • Get-NetAdapter | Select Name,LinkSpeed,Status でNIC設定確認
  • Get-NetAdapterStatistics でNIC統計確認
タスクスケジューラの大量タスク実行によるリソース競合
想定される原因
  • 同一時刻に大量のタスクがスケジュール
  • タスクの実行時間超過による連鎖遅延
  • タスクの並行実行制限設定
  • 不要な古いタスクの残存
確認手順
  • Get-ScheduledTask | Where-Object { $_.State -eq 'Running' } | Measure-Object で実行中タスク数確認
  • Get-ScheduledTask | Where-Object { $_.State -eq 'Queued' } でキュー待ちタスク確認
  • Get-ScheduledTask | Get-ScheduledTaskInfo | Sort-Object LastRunTime -Descending | Select -First 20 で最近実行タスク確認
  • schtasks /query /fo LIST /v で全タスクの詳細確認
  • Get-WinEvent -LogName 'Microsoft-Windows-TaskScheduler/Operational' -MaxEvents 50 でスケジューラログ確認
ファイルサーバーのSMBサービスクラッシュによる共有アクセス不能
想定される原因
  • SMBドライバ(srv2.sys)のバグ
  • SMB署名処理の高負荷によるタイムアウト
  • ファイルシステムフィルタドライバの競合
  • メモリ不足によるSMBバッファ割当失敗
確認手順
  • Get-Service LanmanServer でサービス状態確認
  • Get-SmbServerConfiguration でSMBサーバー設定確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[Provider[@Name="srv2"]]]' -MaxEvents 20 でsrv2イベント確認
  • Get-SmbShare でアクティブ共有一覧確認
  • fltmc でロードされたファイルシステムフィルタ確認
ファイル共有のアクセス権エラーによる接続拒否
想定される原因
  • 共有アクセス許可とNTFSアクセス許可の不一致
  • ユーザーのグループメンバーシップ変更後のトークン未更新
  • ABE(Access-Based Enumeration)の設定による表示制限
  • 継承の遮断による意図しない権限喪失
確認手順
  • Get-SmbShareAccess -Name <share> で共有レベル権限確認
  • icacls '<path>' でNTFS権限確認
  • whoami /groups(クライアント側)で有効なグループメンバーシップ確認
  • Get-SmbShare -Name <share> | Select Name,Path,FolderEnumerationMode でABE設定確認
  • Get-Acl '<path>' | Format-List で詳細ACL確認
DFS名前空間サービスの起動失敗
想定される原因
  • PDC Emulatorへの接続障害
  • DFS名前空間のADオブジェクト破損
  • サービスアカウント(NETWORK SERVICE)の権限問題
  • AD内のDFSメタデータの不整合
確認手順
  • Get-Service Dfs でDFSサービス状態確認
  • Get-DfsnRoot でDFS名前空間一覧確認
  • dfsutil /root:\\<domain>\<namespace> /view でDFSルート情報確認
  • nltest /dsgetdc:<domain> /PDC でPDCEmulator到達確認
  • Get-WinEvent -LogName 'Microsoft-Windows-DFSN-Server/Operational' -MaxEvents 20 でDFS-Nイベント確認
DFSレプリケーションの競合ファイル大量発生
想定される原因
  • 複数ユーザーが異なるサーバーで同一ファイルを同時編集
  • レプリケーション遅延中のファイル変更
  • オフラインファイル(CSC)同期との競合
  • アプリケーションの自動保存による頻繁な更新
確認手順
  • Get-DfsReplicatedFolder | Select GroupName,FolderName,ConflictSizeInMb で競合サイズ確認
  • dir '\\<server>\<share>\DfsrPrivate\ConflictAndDeleted' で競合ファイル確認
  • Get-DfsrConflictInfo -GroupName <group> -FolderName <folder> で競合情報確認
  • Get-WinEvent -LogName 'DFS Replication' -FilterXPath '*[System[EventID=4412]]' -MaxEvents 50 で競合イベント確認
  • dfsrdiag Backlog で各方向のバックログ確認
SMBマルチチャネルの不適切な動作によるスループット低下
想定される原因
  • NICのRSS(Receive Side Scaling)未設定
  • SMBマルチチャネルが無効化されている
  • クライアント/サーバー間のNIC速度不一致
  • ファイアウォールによるSMB代替ポートのブロック
確認手順
  • Get-SmbMultichannelConnection でマルチチャネル接続状態確認
  • Get-SmbClientConfiguration | Select EnableMultichannel でクライアント設定確認
  • Get-SmbServerConfiguration | Select EnableMultichannel でサーバー設定確認
  • Get-NetAdapterRss でRSS設定確認
  • Get-SmbConnection | Select ServerName,NumOpens,Dialect でSMB接続詳細確認
ファイルサーバーのボリュームシャドウコピー(VSS)容量枯渇
想定される原因
  • VSS差分領域の最大サイズ設定が小さい
  • ファイル変更頻度が高くシャドウコピー差分が急速に肥大
  • バックアップソフトのVSS使用との競合
  • ボリューム自体のディスク容量不足
確認手順
  • vssadmin list shadowstorage でVSS領域設定確認
  • vssadmin list shadows でシャドウコピー一覧確認
  • (Get-WmiObject Win32_ShadowStorage).UsedSpace / 1GB で使用量確認
  • fsutil volume diskfree D: でボリューム残量確認
  • Get-WinEvent -LogName Application -FilterXPath '*[System[EventID=8193]]' でVSSエラー確認
SMBセッション数上限到達による新規接続拒否
想定される原因
  • クライアント数が多くセッション上限に到達
  • クライアントのSMBセッション未解放(オフラインファイル等)
  • サーバーのIRPStackSizeが小さい
  • アプリケーションのファイルハンドル未クローズ
確認手順
  • Get-SmbSession | Measure-Object でアクティブセッション数確認
  • Get-SmbOpenFile | Measure-Object で開いているファイル数確認
  • Get-SmbSession | Group-Object ClientComputerName | Sort-Object Count -Descending でクライアント別セッション確認
  • reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v MaxMpxCt でSMB設定確認
  • Get-Counter '\Server\Sessions Active' でアクティブセッション数確認
FSRMクォータ設定エラーによるファイル保存失敗
想定される原因
  • ハードクォータの厳格な制限
  • クォータテンプレートの設定値が実使用量に対して小さい
  • ソフトクォータの閾値超過後の対応遅れ
  • 自動適用クォータの意図しないパス適用
確認手順
  • Get-FsrmQuota -Path 'D:\Shares\*' でクォータ設定確認
  • Get-FsrmQuota -Path '<path>' | Select Path,Size,Usage で使用量確認
  • Get-FsrmAutoQuota でauto-apply quota設定確認
  • dirquota quota list でクォータ一覧確認
  • Get-FsrmQuotaTemplate で適用テンプレート確認
ファイルロック競合によるユーザーのファイル編集不可
想定される原因
  • ユーザーがファイルを開いたまま離席/ログオフ
  • アプリケーションのファイルハンドルリーク
  • Opportunistic Lock(Oplock)のネゴシエーション失敗
  • バックアップソフトによるファイルロック
確認手順
  • Get-SmbOpenFile | Where-Object { $_.Path -like '*<filename>*' } でファイルを開いているセッション確認
  • openfiles /query /s <server> でサーバー上の開いているファイル一覧
  • Get-SmbSession -ClientComputerName <client> でクライアントセッション確認
  • handle.exe -a <filepath> でハンドルを保持しているプロセス確認
  • net file でアクティブファイル接続確認
重複排除(Data Deduplication)のスケジュール遅延
想定される原因
  • 最適化ウィンドウが短すぎる
  • ボリュームのデータ量が多くジョブが時間内に完了しない
  • CPU/メモリリソースの競合
  • チャンクストアの整合性問題
確認手順
  • Get-DedupStatus | Select Volume,OptimizedFilesCount,SavedSpace でDedup状態確認
  • Get-DedupSchedule でスケジュール設定確認
  • Get-DedupJob でアクティブジョブ確認
  • Get-DedupMetadata -Volume D: でメタデータ状態確認
  • Get-Counter '\Dedup Volume Activity(*)\*' でDedupパフォーマンス確認
NTFSファイルシステムの破損によるボリュームマウント失敗
想定される原因
  • 予期しない電源断やシステムクラッシュ
  • ディスクのハードウェア障害(セクタ不良)
  • ストレージコントローラの不具合
  • ファイルシステムドライバのバグ
確認手順
  • fsutil dirty query D: でダーティービット確認
  • chkdsk D: (読み取り専用チェック)でエラー確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=55]]' でNTFSエラー確認
  • Get-PhysicalDisk | Select FriendlyName,HealthStatus でディスク健全性確認
  • wmic diskdrive get status,model,serialnumber でディスク状態確認
BranchCacheのキャッシュ無効化による拠点間転送速度低下
想定される原因
  • ファイルサーバー側のBranchCacheハッシュ生成が無効
  • Hosted Cacheサーバーの障害
  • クライアント側のBranchCacheサービス停止
  • GPOでBranchCacheが適切に構成されていない
確認手順
  • Get-BCStatus でBranchCache状態確認
  • Get-BCHashCache でハッシュキャッシュ状態確認
  • Get-BCDataCache でデータキャッシュ状態確認
  • netsh branchcache show status all で詳細状態確認
  • Get-Counter '\BranchCache\*' でBranchCacheカウンター確認
グループポリシークライアント側拡張(CSE)のクラッシュ
想定される原因
  • セキュリティポリシーCSEの破損
  • ポリシーテンプレート(.adm/.admx)のフォーマットエラー
  • WMIフィルタのクエリエラー
  • サードパーティCSE(ソフトウェア配布等)の不具合
確認手順
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -MaxEvents 50 でGPイベント確認
  • gpresult /h report.html でGP適用結果確認
  • reg query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions でCSE一覧確認
  • Get-WinEvent -LogName System -FilterXPath '*[System[EventID=1085]]' でCSEクラッシュ確認
  • dir C:\Windows\PolicyDefinitions\*.admx でADMXファイル確認
GPOのログオンスクリプトによる認証遅延
想定される原因
  • ログオンスクリプトの処理時間が長い
  • スクリプトが参照するネットワークリソースが応答しない
  • 同期実行設定によりスクリプト完了までデスクトップが表示されない
  • スクリプト内のエラーハンドリング不足によるハング
確認手順
  • gpresult /r で適用されているスクリプトGPO確認
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -FilterXPath '*[System[EventID=4018]]' でスクリプト処理時間確認
  • GPO設定: コンピューターの構成 > ポリシー > 管理用テンプレート > システム > スクリプト で設定確認
  • スクリプトの内容を手動で実行してエラー確認
  • ネットワークドライブマッピング先の応答確認
グループポリシーサービス(gpsvc)の起動失敗
想定される原因
  • gpsvcサービスのレジストリ権限破損
  • 依存サービス(RPCSS, Netlogon)の起動失敗
  • WMIリポジトリの破損
  • Windows Updateの不完全適用
確認手順
  • Get-Service gpsvc でサービス状態確認
  • sc qc gpsvc でサービス構成確認
  • icacls 'HKLM\SYSTEM\CurrentControlSet\Services\gpsvc' でレジストリ権限確認
  • Get-Service RPCSS,Netlogon でgpsvc依存サービス確認
  • sfc /scannow でシステムファイル整合性確認
SYSVOLレプリケーション遅延によるGPO不整合
想定される原因
  • DFSRサービスの問題によるSYSVOL同期停止
  • DCのFRS→DFSR移行の不完全
  • ネットワーク障害によるDC間通信断
  • USNジャーナルラップによるDFSR停止
確認手順
  • dfsrdiag Backlog /smem:<DC1> /rmem:<DC2> /rgname:'Domain System Volume' でバックログ確認
  • Get-DfsReplicationGroup -GroupName 'Domain System Volume' | Get-DfsrMembership でメンバー確認
  • dcdiag /test:sysvolcheck /test:netlogons でSYSVOL状態確認
  • net share SYSVOL でSYSVOL共有状態確認
  • dir \\<DC>\SYSVOL\<domain>\Policies で各DCのポリシーフォルダ比較
WMIフィルタによるGPO処理の大幅遅延
想定される原因
  • 非効率なWMIフィルタクエリ(広範囲スキャン)
  • WMIリポジトリの肥大化/破損
  • 複数GPOに付与された複数WMIフィルタの累積
  • WMIプロバイダの応答遅延
確認手順
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -FilterXPath '*[System[EventID=5312]]' でWMIフィルタ処理時間確認
  • Get-GPO -All | Where-Object { $_.WmiFilter -ne $null } | Select DisplayName,WmiFilter でWMIフィルタ付きGPO確認
  • gwmi -query '<WMI_filter_query>' | Measure-Command でWMIクエリ実行時間計測
  • gpresult /r でフィルタされたGPOの確認
  • winmgmt /verifyrepository でWMIリポジトリ整合性確認
GPOのADMXテンプレートファイル欠損によるポリシー編集不可
想定される原因
  • Central StoreのADMXファイル欠損
  • ADMX/ADMLバージョンの不一致
  • SYSVOLレプリケーション未完了でDC間で不整合
  • 手動削除またはファイル破損
確認手順
  • dir \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\*.admx | Measure-Object でADMXファイル数確認
  • 各DC間でPolicyDefinitionsフォルダの内容比較
  • gpmc.msc でGPOエディター表示時のエラーメッセージ確認
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -FilterXPath '*[System[EventID=1091]]' で確認
  • dir \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\<locale>\ で言語ファイル確認
ソフトウェア配布GPOによるインストール失敗
想定される原因
  • MSIパッケージの配布ポイント(共有フォルダ)へのアクセス権限問題
  • 配布ポイントのサーバーダウンまたはネットワーク障害
  • MSIパッケージの破損またはバージョン不一致
  • GPOのセキュリティフィルタリング設定不備
確認手順
  • gpresult /r で適用されているソフトウェア配布GPO確認
  • Test-Path '\\<server>\<share>\<package>.msi' でパッケージアクセステスト
  • msiexec /i '\\<server>\<share>\<package>.msi' /qn で手動インストールテスト
  • Get-WinEvent -LogName Application -FilterXPath '*[System[Provider[@Name="MsiInstaller"]]]' -MaxEvents 20 でMSIイベント確認
  • icacls '\\<server>\<share>' で配布ポイント権限確認
GPOリンク順序の競合による設定の予期しない上書き
想定される原因
  • GPOリンク順序の設定ミス(数字が小さい方が優先)
  • Block Inheritanceの不適切な使用
  • Enforced(強制)フラグの設定漏れ
  • 複数GPOの同一設定に異なる値を設定
確認手順
  • gpresult /h report.html で全GPOの適用順序と結果確認
  • Get-GPInheritance -Target 'OU=<ou>,DC=domain,DC=local' でOU のGPO継承確認
  • Get-GPO -All | Get-GPOReport -ReportType XML で全GPO設定エクスポート
  • (Get-GPO -Name '<gpo>').GpoStatus でGPO状態確認
  • Get-GPLink -Target 'OU=<ou>,DC=domain,DC=local' でリンク一覧確認
グループポリシー基本設定(GPP)のアイテムレベルターゲティング失敗
想定される原因
  • ターゲティング条件のWMIクエリが遅い
  • セキュリティグループの入れ子(トークン展開の遅延)
  • ターゲティング条件の論理エラー(AND/OR組み合わせ)
  • ネットワーク問題によるDCへのクエリタイムアウト
確認手順
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -FilterXPath '*[System[EventID=4016]]' でGPPエラー確認
  • gpresult /h report.html でGPP適用結果確認
  • GPMC > GPO編集 > 基本設定項目 > 共通タブ > ターゲティング で条件確認
  • whoami /groups でクライアント側のトークン内グループ確認
  • WMIターゲティング条件のクエリを手動実行して応答時間確認
Slow Link Detection によるGPO処理スキップ
想定される原因
  • VPN接続時の低帯域判定
  • DCへのネットワーク遅延が大きい
  • NLA(Network Location Awareness)の誤判定
  • Slow Link閾値の設定が環境に合っていない
確認手順
  • gpresult /r で「Slow Linkが検出されました」メッセージ確認
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' -FilterXPath '*[System[EventID=5305]]' でSlow Link検出確認
  • Test-NetConnection -ComputerName <DC> で DCへの接続テスト
  • nltest /dsgetdc:<domain> でDC選択確認
  • reg query 'HKLM\SOFTWARE\Policies\Microsoft\Windows\System' /v GroupPolicyMinTransferRate でSlow Link閾値確認
セキュリティポリシーのSecedit適用エラー
想定される原因
  • ポリシーで参照されるアカウント/グループがADに存在しない
  • セキュリティデータベース(secedit.sdb)の破損
  • SID解決の失敗(信頼関係の問題)
  • 制限されたグループポリシーの不正なメンバー指定
確認手順
  • secedit /analyze /db C:\Windows\Security\local.sdb /log C:\secedit.log でセキュリティ分析
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' でエラー詳細確認
  • C:\Windows\Security\Logs\winlogon.log でセキュリティポリシー適用ログ確認
  • net group '<group_name>' /domain で参照グループの存在確認
  • secedit /export /cfg C:\secpol.cfg でセキュリティポリシーエクスポート確認
GPO結果セット(RSoP)とロギングのトラブルシューティング
想定される原因
  • GPOのセキュリティフィルタリングによる除外
  • ループバック処理モード(Replace/Merge)の予期しない動作
  • キャッシュされた古いポリシーの残留
  • GPOの「無効」設定の見落とし
確認手順
  • gpresult /h C:\gpresult.html /scope:computer でコンピューターポリシー結果確認
  • gpresult /h C:\gpresult.html /scope:user でユーザーポリシー結果確認
  • Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' で処理の全過程確認
  • rsop.msc でRSoPスナップイン確認
  • gpresult /z で詳細(フィルタされたGPO含む)確認
Docker デーモンが起動しない
想定される原因
  • daemon.jsonの構文エラーや無効な設定値
  • ストレージドライバが対応していない、または破損している
  • 前回のシャットダウンが不正でPIDファイルが残存している
  • カーネルモジュール(overlay, br_netfilter等)が未ロード
確認手順
  • systemctl status docker でサービス状態を確認
  • journalctl -xeu docker.service でデーモンログを確認
  • cat /etc/docker/daemon.json で設定ファイルの構文を検証
  • /var/run/docker.pid の存在確認と削除
  • lsmod | grep overlay でカーネルモジュールを確認
Docker デーモンがクラッシュして再起動を繰り返す
想定される原因
  • ホストのメモリ不足でOOM Killerに終了させられた
  • Dockerデーモン自体のバグやメモリリーク
  • 破損したコンテナメタデータによるパニック
  • 互換性のないプラグインやランタイムの問題
確認手順
  • dmesg | grep -i oom でOOM Killerの発動を確認
  • journalctl -u docker --since '1 hour ago' でクラッシュ前のログを確認
  • free -h と docker system df でメモリ・ディスク使用量を確認
  • docker version でバージョンと既知のバグを照合
  • /var/lib/docker/containers/ 配下の破損ファイルを確認
Docker ソケットへの接続がタイムアウトする
想定される原因
  • リモートDockerデーモンのTLS証明書の期限切れまたは不一致
  • ファイアウォールがDockerポート(2375/2376)をブロックしている
  • DOCKER_HOST環境変数が不正なアドレスを指している
  • デーモンがTCPリスンを有効にしていない
確認手順
  • echo $DOCKER_HOST でDocker接続先を確認
  • curl -k https://[host]:2376/version で直接接続テスト
  • openssl s_client -connect [host]:2376 で証明書を確認
  • iptables -L -n または firewall-cmd --list-all でポート開放を確認
  • daemon.jsonの hosts 設定を確認
イメージビルド時にデーモンエラーが発生する
想定される原因
  • BuildKitキャッシュが破損している
  • ビルドコンテキストが大きすぎてメモリ不足になっている
  • デーモンのストレージ領域が不足している
  • BuildKitのバージョン不一致
確認手順
  • docker builder prune でビルドキャッシュの状態を確認
  • df -h /var/lib/docker でストレージ空き容量を確認
  • docker info | grep -i buildkit でBuildKit設定を確認
  • .dockerignore の内容を確認してコンテキストサイズを検証
Docker データディレクトリのディスク容量不足
想定される原因
  • 未使用イメージ・コンテナ・ボリュームの蓄積
  • ビルドキャッシュの肥大化
  • コンテナログファイルが巨大化している
  • data-rootパーティションの容量が元々小さい
確認手順
  • docker system df で Docker のディスク使用状況を確認
  • df -h /var/lib/docker でパーティション空き容量を確認
  • du -sh /var/lib/docker/* で内訳を確認
  • docker system df -v で詳細な使用量を確認
  • find /var/lib/docker/containers -name '*-json.log' -size +100M でログファイルを確認
Docker デーモンのファイル権限エラー
想定される原因
  • ユーザーがdockerグループに所属していない
  • docker.sockのパーミッションが不正
  • SELinuxまたはAppArmorによるアクセス拒否
  • rootless Docker設定の問題
確認手順
  • groups $(whoami) で現ユーザーのグループを確認
  • ls -la /var/run/docker.sock でソケットの権限を確認
  • getenforce でSELinuxの状態を確認
  • aa-status でAppArmorのプロファイルを確認
  • systemctl --user status docker でrootlessモードの状態を確認
Docker デーモンのパフォーマンス低下
想定される原因
  • 大量のコンテナ(停止中含む)がデーモンに負荷を掛けている
  • containerdのshimプロセスが大量に残存している
  • ストレージドライバのI/O性能が低い
  • デーモンのイベントストリームが詰まっている
確認手順
  • docker ps -aq | wc -l でコンテナ総数を確認
  • ps aux | grep containerd-shim | wc -l でshimプロセス数を確認
  • iostat -x 1 3 でディスクI/Oを確認
  • docker events --since 1h で大量のイベントが発生していないか確認
  • top -p $(pidof dockerd) でデーモンのCPU/メモリを確認
Docker イメージのプル失敗(デーモン側)
想定される原因
  • 指定したタグまたはイメージがレジストリに存在しない
  • レジストリへの認証情報が期限切れまたは未設定
  • プロキシ設定によりレジストリにアクセスできない
  • プライベートレジストリのTLS証明書が信頼されていない
確認手順
  • docker login でレジストリ認証を確認
  • curl -I https://registry-1.docker.io/v2/ でレジストリ接続を確認
  • cat ~/.docker/config.json で認証設定を確認
  • env | grep -i proxy でプロキシ設定を確認
  • docker info | grep Registry でデフォルトレジストリを確認
Docker デーモンのライブリストア失敗
想定される原因
  • daemon.jsonでlive-restoreが無効になっている
  • デーモンバージョンアップ後のコンテナ状態不整合
  • containerdとdockerdのバージョン不一致
  • ネットワーク設定の変更によりリストア時に接続できない
確認手順
  • docker info | grep 'Live Restore' でlive-restore設定を確認
  • docker ps -a でコンテナの状態を確認
  • journalctl -u docker --since 'last boot' でリストアログを確認
  • docker network ls で孤立ネットワークを確認
  • containerd --version と docker --version の互換性を確認
Docker デーモンのネットワークドライバ初期化失敗
想定される原因
  • docker0ブリッジが削除されているか不正な状態
  • iptablesのルールが壊れているまたはモジュール不足
  • 他のソフトウェアと同じサブネットが競合している
  • カーネルのネットワーク機能(netfilter)が無効
確認手順
  • ip link show docker0 でブリッジの存在を確認
  • iptables -L -t nat でNATテーブルを確認
  • ip addr show で既存ネットワークとの競合を確認
  • lsmod | grep br_netfilter でモジュール状態を確認
  • cat /etc/docker/daemon.json の bip 設定を確認
Docker デーモンのcgroup設定エラー
想定される原因
  • cgroupドライバがcgroupfsとsystemdで不一致
  • cgroup v2環境で古いDockerバージョンを使用している
  • cgroupのマウントポイントが欠落している
  • Kubernetes環境でcgroupドライバの不整合
確認手順
  • docker info | grep 'Cgroup Driver' でcgroupドライバを確認
  • stat -fc %T /sys/fs/cgroup/ でcgroupバージョンを確認
  • mount | grep cgroup でマウント状態を確認
  • cat /etc/docker/daemon.json の exec-opts を確認
  • kubelet --cgroup-driver の設定を確認(K8s環境)
Docker デーモンのセキュリティポリシー違反
想定される原因
  • デフォルトのseccompプロファイルが必要なシステムコールを制限している
  • AppArmorプロファイルが厳しすぎてコンテナ操作をブロック
  • SELinuxがDockerデーモンのアクセスを拒否
  • カスタムセキュリティプロファイルの設定ミス
確認手順
  • docker info | grep Security でセキュリティ設定を確認
  • ausearch -m avc -ts recent でSELinux拒否ログを確認
  • dmesg | grep apparmor でAppArmor拒否を確認
  • docker inspect --format '{{.HostConfig.SecurityOpt}}' でコンテナのプロファイルを確認
  • cat /etc/apparmor.d/docker でプロファイル内容を確認
コンテナが起動直後にExitする
想定される原因
  • ENTRYPOINTまたはCMDで指定したバイナリがイメージ内に存在しない
  • シェルスクリプトのシバン行が不正またはCRLF改行コード
  • マルチアーキテクチャ不一致(ARM用イメージをx86で実行等)
  • 依存ライブラリの欠落によるバイナリ実行失敗
確認手順
  • docker logs [container_id] でコンテナの出力を確認
  • docker inspect [container_id] | jq '.[0].State' で終了コードを確認
  • docker run --entrypoint /bin/sh [image] -c 'ls /app' でファイルの存在確認
  • file [entrypoint] でバイナリのアーキテクチャを確認
  • docker inspect [image] | jq '.[0].Architecture' でイメージアーキテクチャを確認
コンテナがOOM Killerで強制終了される
想定される原因
  • コンテナのメモリ制限(--memory)が小さすぎる
  • アプリケーションにメモリリークがある
  • JVMのヒープサイズがコンテナメモリ制限を超えている
  • 子プロセスの生成でメモリが増加している
確認手順
  • docker inspect [container] | jq '.[0].State.OOMKilled' でOOM判定を確認
  • docker stats [container] でリアルタイムメモリ使用量を監視
  • docker inspect [container] | jq '.[0].HostConfig.Memory' でメモリ制限を確認
  • dmesg | grep -i 'killed process' でカーネルOOMログを確認
  • docker logs [container] --tail 50 でクラッシュ直前のログを確認
コンテナのネットワーク接続ができない
想定される原因
  • コンテナが正しいネットワークに接続されていない
  • DNS設定が不正でホスト名解決ができない
  • ターゲットのコンテナ/サービスがまだ起動していない
  • ポートマッピングの設定ミス
確認手順
  • docker network inspect [network] でネットワーク内のコンテナを確認
  • docker exec [container] cat /etc/resolv.conf でDNS設定を確認
  • docker exec [container] ping [target] で疎通確認
  • docker port [container] でポートマッピングを確認
  • docker exec [container] nslookup [hostname] でDNS解決を確認
Dockerfileのビルドでレイヤーキャッシュが効かない
想定される原因
  • COPY . . がpackage.jsonの前に記述されキャッシュが毎回無効化
  • ビルド引数(ARG)の変更でキャッシュが無効化
  • --no-cache フラグが指定されている
  • BuildKitのキャッシュマウントが設定されていない
確認手順
  • Dockerfile の命令順序を確認(変更頻度の低い順か)
  • docker history [image] で各レイヤーのサイズと日時を確認
  • docker build の出力で CACHED の表示を確認
  • .dockerignore で不要ファイルが除外されているか確認
コンテナ内のボリュームデータが消える
想定される原因
  • 匿名ボリュームを使用しておりコンテナ削除時にデータが消失
  • ボリュームマウント先のパスが間違っている
  • docker-compose down -v でボリュームごと削除してしまった
  • コンテナ内でデータが別パスに書き込まれている
確認手順
  • docker volume ls で既存ボリュームの一覧を確認
  • docker inspect [container] | jq '.[0].Mounts' でマウント状態を確認
  • docker volume inspect [volume] でボリュームの実体パスを確認
  • docker exec [container] ls -la /path/to/data でデータの存在を確認
  • docker-compose.yml のvolumes定義を確認
コンテナ内のファイル権限エラー
想定される原因
  • コンテナが非rootユーザーで実行されているがファイルがroot所有
  • ボリュームマウント元のホスト側パーミッションが不適切
  • --read-only フラグでルートFSが読み取り専用になっている
  • Dockerfile の USER 命令とファイル所有者の不一致
確認手順
  • docker exec [container] id で実行ユーザーのUID/GIDを確認
  • docker exec [container] ls -la /app でファイル権限を確認
  • docker inspect [container] | jq '.[0].HostConfig.ReadonlyRootfs' を確認
  • ls -la [host_mount_path] でホスト側パーミッションを確認
  • Dockerfile の USER 命令を確認
コンテナのCPU使用率が高くレスポンスが遅い
想定される原因
  • CPU制限(--cpus)が小さすぎてスロットリングが頻発
  • アプリケーションに無限ループや非効率な処理がある
  • 同一ホスト上の他コンテナとCPUリソースが競合している
  • GCやJITコンパイルが一時的に高CPU負荷を発生させている
確認手順
  • docker stats [container] でCPU使用率をリアルタイム確認
  • docker exec [container] top -bn1 でプロセス別CPU使用率を確認
  • cat /sys/fs/cgroup/cpu/docker/[id]/cpu.stat でスロットリング回数を確認
  • docker inspect [container] | jq '.[0].HostConfig.NanoCpus' でCPU制限を確認
  • docker stats --no-stream --format '{{.CPUPerc}}' で全コンテナのCPUを一覧
コンテナイメージのサイズが大きすぎる
想定される原因
  • マルチステージビルドを使用していない
  • 開発ツールやデバッグパッケージが本番イメージに含まれている
  • パッケージマネージャのキャッシュがクリーンアップされていない
  • ベースイメージが大きい(ubuntu代わりにalpineを使うべき)
確認手順
  • docker images [image] でイメージサイズを確認
  • docker history [image] で各レイヤーのサイズを確認
  • dive [image] でイメージ内容を詳細分析
  • Dockerfileのステージ数と各RUN命令を確認
  • docker image inspect [image] | jq '.[0].Size' で正確なサイズを確認
コンテナのヘルスチェックが失敗する
想定される原因
  • ヘルスチェックのエンドポイントがまだ準備できていない
  • ヘルスチェックコマンドが存在しない(curlがイメージに含まれていない)
  • タイムアウト値が短すぎて応答が間に合わない
  • アプリケーションが期待するポートでリスンしていない
確認手順
  • docker inspect [container] | jq '.[0].State.Health' でヘルス状態を確認
  • docker inspect [container] | jq '.[0].Config.Healthcheck' でHC設定を確認
  • docker exec [container] [healthcheck_cmd] で手動実行して確認
  • docker logs [container] でアプリの起動状況を確認
  • docker exec [container] netstat -tlnp でリスンポートを確認
コンテナの再起動ポリシーによる無限再起動
想定される原因
  • アプリケーションの設定エラーで起動直後にクラッシュ
  • restart: always 設定で根本原因が修正されないまま再起動が続く
  • 環境変数や設定ファイルの欠落
  • 依存サービスが利用できない状態が継続
確認手順
  • docker inspect [container] | jq '.[0].RestartCount' で再起動回数を確認
  • docker logs [container] --tail 100 でクラッシュ原因を確認
  • docker inspect [container] | jq '.[0].HostConfig.RestartPolicy' でポリシーを確認
  • docker events --filter container=[name] でイベント履歴を確認
  • docker inspect [container] | jq '.[0].State' で現在の状態を確認
コンテナからホストのサービスに接続できない
想定される原因
  • コンテナのlocalhostはコンテナ自身を指しホストではない
  • host.docker.internal が利用できない環境(Linux旧版)
  • ホストのサービスがlocalhostのみバインドでブリッジからアクセス不可
  • ファイアウォールがdocker0ブリッジからのアクセスをブロック
確認手順
  • docker exec [container] getent hosts host.docker.internal で名前解決を確認
  • ホスト側で ss -tlnp | grep [port] でバインドアドレスを確認
  • docker network inspect bridge でゲートウェイIPを確認
  • iptables -L INPUT で入力フィルタを確認
  • docker run --add-host 設定を確認
コンテナ内のプロセスがゾンビ化する
想定される原因
  • PID 1 で実行されるプロセスがシグナルハンドリングやwait()を行っていない
  • シェルスクリプトがexecなしで子プロセスを起動している
  • initプロセス(tini等)が設定されていない
  • マルチプロセスアプリケーションで子プロセスの回収が行われていない
確認手順
  • docker exec [container] ps aux | grep defunct でゾンビプロセスを確認
  • docker exec [container] cat /proc/1/cmdline でPID 1のプロセスを確認
  • docker inspect [container] | jq '.[0].HostConfig.Init' でinit設定を確認
  • docker top [container] でプロセスツリーを確認
  • Dockerfileの ENTRYPOINT/CMD を確認
コンテナ間の名前解決ができない
想定される原因
  • デフォルトのbridgeネットワークではDNS解決が無効
  • コンテナが異なるユーザー定義ネットワークに所属している
  • 対象コンテナが停止しているかネットワークから切断されている
  • Docker内蔵DNSサーバー(127.0.0.11)に問題がある
確認手順
  • docker network ls で使用中のネットワークを確認
  • docker network inspect [network] でコンテナの所属を確認
  • docker exec [container] cat /etc/resolv.conf でDNS設定を確認
  • docker exec [container] nslookup [service_name] 127.0.0.11 でDNS解決テスト
  • docker ps で対象コンテナの起動状態を確認
ポートバインドの競合エラー
想定される原因
  • 他のコンテナまたはホストプロセスが同じポートを使用している
  • 前回のコンテナが正常に停止せずポートを保持し続けている
  • docker-composeの再起動で古いコンテナが残っている
  • ホストのサービス(nginx, apache等)が同じポートを使用
確認手順
  • ss -tlnp | grep [port] でポートを使用しているプロセスを確認
  • docker ps --filter publish=[port] で同ポートのコンテナを確認
  • docker ps -a で停止中のコンテナを確認
  • lsof -i :[port] でポート使用元を特定
  • netstat -tlnp | grep [port] でリスン状態を確認
Docker ネットワークが削除できない
想定される原因
  • ネットワークに接続されたコンテナ(停止中含む)が存在する
  • docker-composeで作成されたネットワークにorphanコンテナが接続中
  • ネットワークのエンドポイントが不整合状態で残っている
  • サービスメッシュやプラグインがネットワークを使用中
確認手順
  • docker network inspect [network] | jq '.[0].Containers' で接続コンテナを確認
  • docker ps -a --filter network=[network] でネットワーク使用コンテナを確認
  • docker network ls で全ネットワーク一覧を確認
  • docker inspect [container] | jq '.[0].NetworkSettings.Networks' で接続先を確認
コンテナから外部インターネットに接続できない
想定される原因
  • ホストのip_forwardが無効になっている
  • iptablesのMASQUERADEルールが欠落している
  • ホストのDNS設定が不正でコンテナに伝播している
  • 企業プロキシ環境で環境変数が未設定
確認手順
  • cat /proc/sys/net/ipv4/ip_forward でIP転送設定を確認
  • iptables -t nat -L POSTROUTING でMASQUERADEルールを確認
  • docker exec [container] cat /etc/resolv.conf でDNS設定を確認
  • docker exec [container] ping 8.8.8.8 でIPレベルの疎通を確認
  • docker info | grep Proxy でプロキシ設定を確認
Docker ネットワーク作成時のサブネット競合
想定される原因
  • VPNやホストネットワークとDockerサブネットが重複している
  • 大量のDockerネットワークでデフォルトのアドレスプールが枯渇
  • docker-composeの各プロジェクトが自動でネットワークを作成して枯渇
  • カスタムサブネット指定が他のネットワークと重複
確認手順
  • docker network ls で全Dockerネットワークを確認
  • docker network inspect [network] | jq '.[0].IPAM' でサブネットを確認
  • ip route でホストのルーティングテーブルを確認
  • for n in $(docker network ls -q); do docker network inspect $n | jq '.[0].IPAM'; done で全サブネットを一覧
  • ifconfig / ip addr でVPNインターフェースのサブネットを確認
iptables/nftablesとDockerの競合
想定される原因
  • firewalldがDockerのiptablesルールを上書きしている
  • 手動のiptablesフラッシュでDOCKERチェインが消えた
  • nftablesバックエンドとDockerのiptables互換性問題
  • iptables-legacyとiptables-nftの切り替えミス
確認手順
  • iptables -L -t nat | grep DOCKER でDOCKERチェインの存在を確認
  • systemctl status firewalld でfirewalldの状態を確認
  • iptables --version でバックエンド(legacy/nft)を確認
  • update-alternatives --query iptables でiptablesの選択を確認
  • nft list ruleset | grep docker でnftablesルールを確認
コンテナ間通信の遅延・パケットロス
想定される原因
  • overlayネットワークのVXLANオーバーヘッドでMTU超過
  • ホスト間のネットワーク帯域が不足している
  • コンテナのネットワーク名前空間でTC(Traffic Control)制限がある
  • ドライバのバグやカーネルネットワークスタックの問題
確認手順
  • docker exec [container] ping -c 10 [target] でRTTとパケットロスを確認
  • docker network inspect [network] | jq '.[0].Options' でMTU設定を確認
  • docker exec [container] ip link show eth0 でMTUを確認
  • tcpdump -i docker0 でパケットキャプチャして分析
  • ethtool -S [interface] でNICの統計情報を確認
Docker Swarm overlayネットワークの障害
想定される原因
  • Swarmノード間のポート(4789/UDP, 7946/TCP+UDP)が開いていない
  • VXLANカーネルモジュールが未ロード
  • 暗号化overlayネットワークでIPsec設定の問題
  • ノードのクロック同期ずれによるgossipプロトコルの障害
確認手順
  • docker node ls でSwarmノードの状態を確認
  • 各ノード間でポート4789/UDP, 7946/TCP+UDPの疎通を確認
  • lsmod | grep vxlan でVXLANモジュールを確認
  • docker network inspect ingress で ingress ネットワークの状態を確認
  • timedatectl でノード間の時刻同期を確認
macvlan/ipvlanネットワークで通信できない
想定される原因
  • 親インターフェース名が間違っているか存在しない
  • 仮想化環境でプロミスキャスモードが無効
  • macvlanではコンテナからホスト自身への通信ができない仕様
  • VLAN IDの設定ミスやスイッチ側のVLAN設定不足
確認手順
  • ip link show で利用可能なインターフェースを確認
  • ip link show [parent] | grep PROMISC でプロミスキャスモードを確認
  • docker network inspect [network] | jq '.[0].Options' で設定を確認
  • bridge vlan show でVLAN設定を確認
  • docker exec [container] ip addr show でIPアドレスを確認
Dockerのuserland-proxyによるパフォーマンス低下
想定される原因
  • docker-proxyのユーザー空間プロキシがボトルネックになっている
  • 大量の同時接続でdocker-proxyプロセスが過負荷
  • ヘアピンNATの設定が不適切
  • docker-proxyとiptables NATの二重処理
確認手順
  • ps aux | grep docker-proxy でプロキシプロセスを確認
  • docker info | grep 'Userland Proxy' でプロキシ設定を確認
  • top で docker-proxy のCPU使用率を確認
  • iptables -t nat -L -n | grep DNAT でNATルールを確認
  • cat /etc/docker/daemon.json の userland-proxy 設定を確認
IPv6ネットワーク設定の問題
想定される原因
  • DockerデーモンでIPv6が有効化されていない
  • fixed-cidr-v6 の設定が不正または未設定
  • カーネルのIPv6フォワーディングが無効
  • ネットワーク作成時にenable_ipv6オプションが指定されていない
確認手順
  • docker info | grep IPv6 でIPv6設定を確認
  • cat /etc/docker/daemon.json の ipv6, fixed-cidr-v6 設定を確認
  • sysctl net.ipv6.conf.all.forwarding でIPv6転送設定を確認
  • docker network inspect [network] | jq '.[0].EnableIPv6' を確認
  • docker exec [container] ip -6 addr show でIPv6アドレスを確認
コンテナのネットワーク分離が機能していない
想定される原因
  • デフォルトbridgeのicc(inter-container communication)がtrue
  • internalネットワーク設定が正しく適用されていない
  • --network=host でネットワーク分離が完全に無効化
  • コンテナが複数ネットワークに接続されてブリッジ役になっている
確認手順
  • docker network inspect bridge | jq '.[0].Options' でicc設定を確認
  • docker network inspect [network] | jq '.[0].Internal' でinternal設定を確認
  • docker inspect [container] | jq '.[0].NetworkSettings.Networks' で接続ネットワークを確認
  • iptables -L DOCKER-ISOLATION-STAGE-1 で分離ルールを確認
  • docker exec [container] curl [external_url] で外部接続可否を確認
ボリュームマウントが空になる
想定される原因
  • バインドマウントがコンテナ内の既存ディレクトリを上書きした
  • ホスト側のマウントソースディレクトリが空
  • Dockerfileで作成したファイルがボリュームマウントで隠された
  • node_modules等がバインドマウントで空のホストディレクトリに置換された
確認手順
  • docker inspect [container] | jq '.[0].Mounts' でマウント設定を確認
  • ls -la [host_path] でホスト側ディレクトリの内容を確認
  • docker run --rm [image] ls /app/target_dir でイメージ内の元ファイルを確認
  • docker volume inspect [volume] でボリュームのMountpointを確認
  • docker-compose.yml のvolumes定義を確認
ボリュームの権限エラーでアクセスできない
想定される原因
  • ボリューム内のファイルがrootで作成されたが非rootユーザーで実行
  • ホスト側のディレクトリ権限とコンテナ内ユーザーのUID不一致
  • SELinuxのコンテキストラベルが適切でない
  • 読み取り専用ボリューム(:ro)への書き込み試行
確認手順
  • docker exec [container] id で実行ユーザーを確認
  • docker exec [container] ls -la /data でボリュームの権限を確認
  • ls -laZ [host_path] でSELinuxコンテキストを確認
  • docker inspect [container] | jq '.[0].Mounts[].Mode' でマウントモードを確認
  • stat [host_path] でUID/GIDを確認
ボリュームドライバのエラー
想定される原因
  • ボリュームプラグインがインストールされていない
  • NFSサーバーへの接続ができない(ネットワーク/認証問題)
  • プラグインのプロセスがクラッシュしている
  • ドライバオプションの設定値が間違っている
確認手順
  • docker plugin ls でインストール済みプラグインを確認
  • docker volume create --driver [driver] --opt [opts] [name] で作成テスト
  • showmount -e [nfs_server] でNFSエクスポートを確認
  • docker plugin inspect [plugin] でプラグイン状態を確認
  • journalctl -u docker で関連エラーを確認
NFS ボリュームマウントのタイムアウト
想定される原因
  • NFSサーバーが停止しているか到達不能
  • ファイアウォールがNFS関連ポート(111, 2049等)をブロック
  • NFSサーバーのexportsにクライアントが許可されていない
  • ネットワーク遅延やパケットロスによるRPCタイムアウト
確認手順
  • showmount -e [nfs_server] でエクスポートを確認
  • rpcinfo -p [nfs_server] でRPCサービスを確認
  • mount -t nfs [server]:/path /mnt で手動マウントテスト
  • telnet [nfs_server] 2049 でポート疎通を確認
  • nfsstat -c でNFSクライアント統計を確認
ボリュームのディスク容量不足
想定される原因
  • ボリュームが配置されたパーティションの容量不足
  • データベースのWALログやバイナリログの肥大化
  • アプリケーションログがボリュームに出力され続けている
  • ボリュームに対するクォータ制限に達した
確認手順
  • docker system df -v でボリュームのサイズを確認
  • docker volume inspect [volume] でMountpointを特定
  • du -sh /var/lib/docker/volumes/[volume]/_data で実際のサイズを確認
  • df -h /var/lib/docker/volumes でパーティション空き容量を確認
  • docker exec [container] du -sh /data/* でボリューム内の内訳を確認
ボリュームのビルド時COPYとの競合
想定される原因
  • DockerfileでVOLUME宣言の後にCOPYしたファイルが永続化されない
  • VOLUME命令でマウントポイントが匿名ボリュームになりイメージ内容が隠される
  • ビルド時に作成したデータがランタイムのボリュームマウントで上書き
  • マルチステージビルドでVOLUMEの位置が不適切
確認手順
  • Dockerfile の VOLUME 命令の位置とCOPY/ADD命令の順序を確認
  • docker history [image] でレイヤー順序を確認
  • docker run --rm [image] ls /app/data でビルド時のファイルを確認
  • docker inspect [image] | jq '.[0].Config.Volumes' で宣言済みボリュームを確認
Windows/Mac でのバインドマウントの性能問題
想定される原因
  • Docker Desktop for Mac/Winのファイルシステムレイヤーのオーバーヘッド
  • 大量のファイル(node_modules等)がマウントされている
  • ファイル監視(inotify/fsevents)がクロスOSで正しく動作しない
  • WSL2バックエンドでのファイルシステム境界越えアクセス
確認手順
  • docker info | grep 'Storage Driver' でファイルシステムバックエンドを確認
  • time docker exec [container] ls /app/node_modules | wc -l でアクセス速度を測定
  • Docker Desktop設定のFile Sharing / VirtioFS設定を確認
  • cat /proc/sys/fs/inotify/max_user_watches でwatcher上限を確認
  • ホスト・コンテナ間のファイル同期方式を確認
ボリュームデータの破損
想定される原因
  • コンテナの強制停止(docker kill)でデータの書き込みが不完全
  • ホストのディスク障害やI/Oエラー
  • 同時に複数コンテナが同じボリュームに書き込んでいる
  • 電源断やシステムクラッシュでファイルシステムが不整合
確認手順
  • docker exec [container] [db_tool] --check で整合性チェック
  • dmesg | grep -i error でディスクI/Oエラーを確認
  • docker inspect [container] | jq '.[0].Mounts' でマウント設定を確認
  • 同じボリュームをマウントしている他のコンテナがないか確認
  • smartctl -a /dev/sdX でディスクのSMART情報を確認
tmpfsマウントのメモリ不足
想定される原因
  • tmpfsのデフォルトサイズ(64MB)が小さすぎる
  • /dev/shmのサイズ制限に達した(ML/データ処理ワークロード)
  • 一時ファイルの作成が多すぎてtmpfsを使い切った
  • PostgreSQL等のDBが共有メモリ不足で起動できない
確認手順
  • docker exec [container] df -h /dev/shm でshm使用量を確認
  • docker exec [container] df -h /tmp でtmpfs使用量を確認
  • docker inspect [container] | jq '.[0].HostConfig.ShmSize' でshm設定を確認
  • docker inspect [container] | jq '.[0].HostConfig.Tmpfs' でtmpfs設定を確認
ボリュームのバックアップ・リストア失敗
想定される原因
  • バックアップ中にコンテナがデータを書き込み続けている
  • tar圧縮時に権限不足でファイルを読めない
  • リストア先のボリュームが読み取り専用でマウントされている
  • バックアップファイルの転送中に破損した
確認手順
  • docker run --rm -v [vol]:/data busybox ls -la /data でボリューム内容を確認
  • md5sum [backup_file] でバックアップファイルの整合性を確認
  • docker inspect [container] | jq '.[0].Mounts[].RW' で読み書きモードを確認
  • tar -tf [backup.tar.gz] でアーカイブ内容を確認
ボリュームマウントでSELinuxラベルの問題
想定される原因
  • バインドマウントにSELinuxラベル(:z/:Z)が付与されていない
  • ホスト側ファイルのSELinuxコンテキストが不適切
  • マルチコンテナで:Z(プライベート)を使用して相互アクセス不可
  • SELinuxのブーリアン設定が必要な操作を拒否
確認手順
  • getenforce でSELinuxの状態を確認
  • ls -laZ [host_path] でファイルのSELinuxコンテキストを確認
  • ausearch -m avc -ts recent で最近の拒否ログを確認
  • sesearch --allow -s svirt_lxc_net_t でコンテナの許可ルールを確認
  • docker inspect [container] | jq '.[0].Mounts[].Mode' でマウントモードを確認
Docker Compose でのボリューム共有の問題
想定される原因
  • depends_onだけでは初期化完了を待てない(起動完了と初期化完了は異なる)
  • 複数サービスが同時にボリュームへ書き込みデータ競合が発生
  • サービス間でボリュームのマウントパスが不一致
  • 外部ボリュームが未作成の状態でcompose upを実行
確認手順
  • docker-compose config でvolumes定義の正規化結果を確認
  • docker-compose ps で各サービスの起動状態を確認
  • docker volume ls | grep [project] でプロジェクトのボリュームを確認
  • docker-compose logs [service] でサービスの起動ログを確認
  • docker-compose.yml のvolumesトップレベル定義を確認
RUN命令の実行失敗でビルドが止まる
想定される原因
  • apt-get update を実行せずにパッケージをインストールしようとした
  • ベースイメージに必要なコマンドが含まれていない
  • requirements.txt/package.json に存在しないパッケージが指定されている
  • ネットワークアクセスができずパッケージのダウンロードに失敗
確認手順
  • Dockerfileの該当RUN命令を確認
  • docker build --progress=plain で詳細なビルドログを確認
  • ベースイメージに対話的に入って手動でコマンドを実行
  • パッケージファイル(requirements.txt等)の内容を確認
  • ビルドネットワークの疎通を確認
Dockerfile が見つからない
想定される原因
  • ビルドコンテキストのディレクトリが間違っている
  • Dockerfileのファイル名が異なる(大文字小文字、拡張子)
  • -f オプションで指定したパスが不正
  • .dockerignore でDockerfile自体を除外してしまっている
確認手順
  • ls -la でビルドコンテキスト内のファイルを確認
  • docker build コマンドの -f オプションとコンテキストパスを確認
  • cat .dockerignore で除外ルールを確認
  • file Dockerfile でファイルの存在とエンコーディングを確認
マルチステージビルドでファイルがコピーされない
想定される原因
  • COPY --from のステージ名またはパスが間違っている
  • ビルドステージでファイルが期待するパスに生成されていない
  • ビルドステージのRUN命令が失敗してファイルが作成されなかった
  • WORKDIR の設定不一致で相対パスが異なる場所を指している
確認手順
  • Dockerfileの各ステージのWORKDIRとCOPY先を確認
  • docker build --target builder で中間ステージまでビルドして内容確認
  • docker run --rm [builder_image] ls -la /app で生成ファイルを確認
  • COPY --from のステージ名がAS句と一致しているか確認
ビルドコンテキストが大きすぎてビルドが遅い
想定される原因
  • .dockerignore が未設定または不十分
  • node_modules, .git, ビルド成果物がコンテキストに含まれている
  • 大きなデータファイルやメディアファイルが含まれている
  • ビルドコンテキストのパス指定が広すぎる
確認手順
  • du -sh . でビルドコンテキストのサイズを確認
  • cat .dockerignore で除外ルールを確認
  • du -sh * | sort -rh | head -20 で大きいファイル/ディレクトリを確認
  • docker build --progress=plain の最初の行でコンテキストサイズを確認
ベースイメージのプルに失敗してビルドできない
想定される原因
  • ベースイメージのタグが存在しないか非推奨になっている
  • プライベートレジストリへの認証ができていない
  • 指定したプラットフォーム向けのイメージが提供されていない
  • レジストリへのネットワーク接続ができない
確認手順
  • docker pull [base_image] で直接プルを試行
  • Docker Hubでタグの存在を確認
  • docker login で認証状態を確認
  • docker manifest inspect [image] で対応プラットフォームを確認
  • curl -s https://registry-1.docker.io/v2/library/node/tags/list でタグ一覧を取得
COPY/ADD命令でファイルが見つからない
想定される原因
  • .dockerignore で必要なファイルを除外してしまっている
  • COPYのソースパスがビルドコンテキストからの相対パスとして間違っている
  • ビルドコンテキスト外のファイルを参照しようとしている
  • ファイル名の大文字小文字の不一致(Linux環境で)
確認手順
  • .dockerignore の内容を確認
  • ビルドコンテキストのルートから見た相対パスを確認
  • ls -la [expected_path] でファイルの存在を確認
  • docker build --no-cache で再ビルドして最新状態を確認
BuildKitのシークレットマウントエラー
想定される原因
  • --secret オプションでビルド時にシークレットが渡されていない
  • SSH エージェントが起動していないか転送設定が不正
  • BuildKitが有効でないためRUN --mount構文が使えない
  • シークレットIDの名前が一致していない
確認手順
  • docker build コマンドの --secret オプションを確認
  • ssh-add -l でSSHキーがエージェントに登録されているか確認
  • echo $SSH_AUTH_SOCK でSSHエージェントソケットを確認
  • DOCKER_BUILDKIT=1 が設定されているか確認
  • Dockerfileの RUN --mount=type=secret,id= のIDを確認
クロスプラットフォームビルドの失敗
想定される原因
  • QEMUユーザーモードエミュレーションが未インストール
  • buildxのドライバがdocker-containerではなくdockerになっている
  • ベースイメージが指定プラットフォームを未サポート
  • QEMUのバージョンが古くてエミュレーションが不安定
確認手順
  • docker buildx ls でビルダーインスタンスとプラットフォーム対応を確認
  • docker run --rm --privileged multiarch/qemu-user-static --reset -p yes でQEMU状態を確認
  • cat /proc/sys/fs/binfmt_misc/qemu-aarch64 でbinfmt登録を確認
  • docker buildx inspect --bootstrap でビルダー詳細を確認
ビルド時のネットワークアクセス不能
想定される原因
  • ビルド時のDNS解決ができない
  • 企業プロキシ環境でビルドコンテナにプロキシ設定が渡っていない
  • ビルド時のネットワークモードが制限されている
  • パッケージリポジトリやレジストリがダウンしている
確認手順
  • docker build --network=host で一時的にホストネットワークで試す
  • docker run --rm busybox nslookup google.com でDNS解決を確認
  • env | grep -i proxy でプロキシ設定を確認
  • curl -I [package_repository_url] でリポジトリの応答を確認
  • daemon.json の dns 設定を確認
ビルド中のディスク容量不足
想定される原因
  • 過去のビルドキャッシュが大量に蓄積している
  • 多数のダングリングイメージが残存している
  • /var/lib/docker パーティションの容量が小さい
  • ビルド中に大きなファイルをダウンロードして容量を超過
確認手順
  • docker system df でDocker全体のディスク使用量を確認
  • df -h /var/lib/docker でパーティション空き容量を確認
  • docker builder prune --all --dry-run で削除可能なキャッシュサイズを確認
  • docker images -f dangling=true でダングリングイメージを確認
ビルド引数(ARG)が反映されない
想定される原因
  • ARGがFROM命令より前に定義されてステージ内でスコープ外
  • --build-arg のキー名がDockerfileのARG名と一致していない
  • マルチステージビルドで各ステージにARGが再宣言されていない
  • ARGの値をENVに代入していないため実行時に参照できない
確認手順
  • Dockerfile の ARG 命令の位置とスコープを確認
  • docker build コマンドの --build-arg オプションを確認
  • docker history [image] --no-trunc でビルド時の値を確認
  • 各ステージで ARG が再宣言されているか確認
ビルド時のセキュリティスキャン警告
想定される原因
  • ベースイメージに既知の脆弱性が含まれている
  • アプリケーション依存パッケージに脆弱なバージョンが含まれる
  • ベースイメージが長期間更新されていない
  • CI/CDのセキュリティゲートの閾値を超過
確認手順
  • docker scout cves [image] でイメージの脆弱性をスキャン
  • trivy image [image] で詳細な脆弱性レポートを取得
  • docker scout recommendations [image] で推奨事項を確認
  • ベースイメージの最終更新日を確認
  • package-lock.json / requirements.txt の依存関係を監査
Docker Hub への認証失敗
想定される原因
  • ユーザー名またはパスワード(PAT)が間違っている
  • Personal Access Token の有効期限が切れている
  • 2FAが有効でパスワードではなくPATが必要
  • Docker Hub のレート制限に達している
確認手順
  • docker login で対話的に認証を試行
  • cat ~/.docker/config.json で保存済み認証情報を確認
  • curl -u user:token https://registry-1.docker.io/v2/ で直接テスト
  • Docker Hub Web UIでPATの有効期限を確認
  • docker info | grep Username でログイン状態を確認
イメージのプッシュが拒否される
想定される原因
  • プッシュ先のリポジトリ名が存在しないまたは権限不足
  • イメージ名にレジストリプレフィックスが付いていない
  • タグの不変性(immutable tags)設定で上書きが禁止
  • レジストリのストレージクォータを超過
確認手順
  • docker images [image] でローカルのイメージ名を確認
  • docker tag [image] [registry/repo:tag] でタグ付けを確認
  • レジストリのWeb UIでリポジトリの存在と権限を確認
  • レジストリのクォータ/制限設定を確認
  • docker login [registry] でプッシュ先レジストリへの認証を確認
プライベートレジストリのTLS証明書エラー
想定される原因
  • プライベートレジストリが自己署名証明書を使用している
  • CA証明書がDockerデーモンに登録されていない
  • レジストリがHTTPのみで動作しているがHTTPSでアクセスしている
  • 証明書の有効期限が切れている
確認手順
  • openssl s_client -connect [registry]:5000 で証明書を確認
  • ls /etc/docker/certs.d/[registry]:5000/ で証明書配置を確認
  • cat /etc/docker/daemon.json の insecure-registries を確認
  • openssl x509 -in cert.pem -noout -dates で有効期限を確認
  • curl -k https://[registry]:5000/v2/ で接続テスト
Docker Hub のレート制限に達した
想定される原因
  • 未認証ユーザーとして100pulls/6時間の制限に達した
  • CI/CDパイプラインで大量のpullが発生している
  • 同一IPアドレス(NAT環境)から多数のクライアントがアクセス
  • 無料プランの認証済みユーザー制限(200pulls/6時間)に達した
確認手順
  • curl -sI https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest で残りリクエスト数を確認
  • docker info | grep Username で認証状態を確認
  • CI/CDのpull頻度とパイプライン数を確認
  • 共有IPからのアクセス数を確認
イメージのマニフェストが見つからない
想定される原因
  • 指定したタグがレジストリに存在しない
  • 要求したプラットフォーム/アーキテクチャ向けのマニフェストがない
  • レジストリがOCIマニフェスト形式に未対応
  • マニフェストリストが破損または不完全
確認手順
  • docker manifest inspect [image]:[tag] でマニフェストを確認
  • curl -sH 'Accept: application/vnd.docker.distribution.manifest.v2+json' [registry]/v2/[repo]/manifests/[tag]
  • レジストリのWeb UIでタグの存在を確認
  • docker manifest inspect --verbose [image] で対応プラットフォームを確認
  • skopeo inspect docker://[image]:[tag] で詳細情報を確認
プライベートレジストリへのプッシュが遅い
想定される原因
  • ネットワーク帯域が不足している
  • レジストリサーバーのストレージI/Oがボトルネック
  • プッシュするイメージのレイヤーが大きすぎる
  • 同時プッシュ数が多くレジストリが過負荷
確認手順
  • iperf3 でレジストリサーバーとの帯域を測定
  • docker images [image] でイメージサイズを確認
  • docker history [image] で各レイヤーのサイズを確認
  • レジストリサーバーのCPU/メモリ/ディスクI/Oを確認
  • daemon.jsonの max-concurrent-uploads 設定を確認
レジストリのGarbage Collectionでイメージが消える
想定される原因
  • GC実行中にプッシュが行われてレイヤーが削除された
  • マニフェストリストとblob参照の不整合
  • GCの設定で参照されているレイヤーまで削除してしまった
  • タグなしマニフェスト(dangling)がGCで削除された
確認手順
  • registry garbage-collect --dry-run で削除対象を確認
  • レジストリのアクセスログでGC実行時のpush有無を確認
  • curl [registry]/v2/[repo]/blobs/sha256:[digest] でblob存在を確認
  • レジストリの設定ファイルでGCポリシーを確認
コンテナレジストリのディスク容量不足
想定される原因
  • 古いイメージのタグが削除されずにblobが蓄積
  • Garbage Collectionが設定・実行されていない
  • 大きなイメージが頻繁にプッシュされている
  • ストレージバックエンドのクォータ設定が小さい
確認手順
  • df -h [registry_storage_path] でストレージ使用量を確認
  • du -sh [registry_storage_path]/blobs/ でblob合計サイズを確認
  • レジストリAPIでリポジトリとタグの数を確認
  • registry garbage-collect --dry-run で回収可能なサイズを確認
  • レジストリの保持ポリシー設定を確認
レジストリミラー/プロキシキャッシュの不具合
想定される原因
  • ミラー元(upstream)レジストリへのネットワーク接続障害
  • キャッシュが古く(stale)なっているが更新できない
  • ミラー設定のURLやプロトコルが間違っている
  • 認証情報がミラーサーバーに設定されていない
確認手順
  • curl [upstream_registry]/v2/ でupstreamへの接続を確認
  • レジストリのconfig.ymlのproxy設定を確認
  • レジストリのログでupstreamエラーを確認
  • キャッシュディレクトリのディスク空き容量を確認
  • daemon.jsonのregistry-mirrors設定を確認
マルチアーキテクチャイメージのプッシュ失敗
想定される原因
  • レジストリがマニフェストリスト(fat manifest)をサポートしていない
  • ビルドした各プラットフォームのイメージが先にプッシュされていない
  • attestation(provenance/sbom)の形式がレジストリに未対応
  • docker manifest create のリファレンスが間違っている
確認手順
  • docker manifest inspect [image] でマニフェストリストを確認
  • docker buildx imagetools inspect [image] で詳細を確認
  • レジストリのOCI/Docker manifest v2サポート状況を確認
  • 各プラットフォーム個別イメージの存在を確認
  • docker buildx build の --provenance, --sbom オプションを確認
レジストリの起動失敗
想定される原因
  • 設定ファイル(config.yml)の構文エラーや必須項目の欠落
  • ストレージバックエンドのディレクトリに書き込み権限がない
  • ポート5000が他のプロセスに使用されている
  • TLS証明書ファイルのパスが間違っている
確認手順
  • docker logs [registry_container] で起動ログを確認
  • ls -la /path/to/registry/storage でストレージ権限を確認
  • ss -tlnp | grep 5000 でポート使用を確認
  • registry serve /etc/docker/registry/config.yml --help で設定検証
  • TLS証明書と秘密鍵のパスとパーミッションを確認
レジストリへのアクセスでCORS/Webhook エラー
想定される原因
  • Webhookエンドポイントが到達不能またはダウン
  • レジストリのCORS設定にフロントエンドのオリジンが含まれていない
  • Webhook通知のタイムアウトが短すぎる
  • ネットワークポリシーがレジストリからWebhook先への通信をブロック
確認手順
  • curl -X POST [webhook_url] でWebhookエンドポイントの疎通を確認
  • レジストリのconfig.ymlのnotifications設定を確認
  • レジストリのconfig.ymlのhttp.headers設定を確認
  • レジストリコンテナからWebhookサーバーへのネットワーク疎通を確認
  • Webhook受信側のログでリクエストの到達を確認
docker-compose.yml の構文エラーで起動できない
想定される原因
  • YAMLのインデントが不正(タブ使用、インデント不揃い)
  • Compose V2形式とV1形式の混在
  • ポートやボリュームの値の型が間違っている
  • 予約語や無効なプロパティの使用
確認手順
  • docker compose config で設定ファイルの検証を実行
  • yamllint docker-compose.yml でYAML構文チェック
  • cat -A docker-compose.yml でタブ文字の混入を確認
  • docker compose version でComposeバージョンを確認
  • インデントが2スペースで統一されているか確認
サービスの依存関係で起動順序がうまくいかない
想定される原因
  • depends_onはコンテナの起動順のみ保証し、サービスの準備完了は保証しない
  • healthcheckが設定されていないためcondition: service_healthyが使えない
  • 依存サービスの初期化に時間がかかる(DB migration等)
  • healthcheckのinterval/timeoutが不適切
確認手順
  • docker compose ps でサービスの起動状態を確認
  • docker compose logs [service] で依存サービスのログを確認
  • docker inspect [container] | jq '.[0].State.Health' でヘルス状態を確認
  • docker-compose.yml の depends_on と healthcheck 設定を確認
  • 依存サービスが実際にリクエストを受け付ける準備時間を確認
orphanコンテナの警告・競合
想定される原因
  • compose.ymlからサービスを削除したが古いコンテナが残存
  • プロジェクト名が変わって別プロジェクトのコンテナが検出された
  • docker compose up を異なるcompose.ymlで実行した
  • 手動でコンテナ名を変更して不整合が発生
確認手順
  • docker compose ps -a で全コンテナ(停止中含む)を確認
  • docker ps -a --filter label=com.docker.compose.project で関連コンテナを確認
  • docker compose ls でアクティブなcomposeプロジェクトを確認
  • docker compose config --services で現在のサービス一覧を確認
環境変数が反映されない
想定される原因
  • .envファイルがcompose.ymlと同じディレクトリにない
  • environment とenv_file の優先順位の理解不足
  • .envファイルの構文エラー(クォートの問題、空白)
  • シェル変数とCompose変数の展開タイミングの違い
確認手順
  • docker compose config で展開後の設定を確認
  • docker compose run [service] env でコンテナ内の環境変数を確認
  • cat .env で.envファイルの内容を確認
  • docker compose --env-file .env.custom config で指定ファイルのテスト
  • docker inspect [container] | jq '.[0].Config.Env' で設定済み環境変数を確認
Composeのネットワークで名前解決が失敗する
想定される原因
  • 接続先をサービス名ではなくコンテナ名で指定している
  • サービスが異なるネットワークに所属している
  • 対象サービスが起動に失敗していてDNSに登録されていない
  • カスタムネットワークを定義して自動作成ネットワークから外れている
確認手順
  • docker compose ps で全サービスの起動状態を確認
  • docker network inspect [project]_default でネットワーク内のコンテナを確認
  • docker compose exec [service] nslookup [target_service] でDNS解決テスト
  • docker-compose.yml のnetworks設定を確認
  • docker compose config で正規化された設定を確認
ボリュームのパーミッション問題(Compose)
想定される原因
  • コンテナの実行ユーザーとボリューム内ファイルの所有者が不一致
  • 名前付きボリュームが前回root実行で作成され非root実行に変更
  • ホストのバインドマウントディレクトリの権限不足
  • Docker Desktop (Mac/Win) でのUID/GIDマッピングの問題
確認手順
  • docker compose exec [service] id で実行ユーザーを確認
  • docker compose exec [service] ls -la /data でファイル権限を確認
  • docker volume inspect [volume] でマウントポイントを確認
  • ls -la [host_bind_path] でホスト側の権限を確認
  • Dockerfile の USER 命令を確認
Composeでビルドが失敗する
想定される原因
  • buildセクションのcontextパスが間違っている
  • Dockerfileのパスがcontextからの相対パスとして不正
  • ビルド引数(args)が正しく渡されていない
  • docker-compose.ymlの場所からの相対パスの解釈ミス
確認手順
  • docker-compose.yml の build セクションの context, dockerfile, args を確認
  • ls [context_path] でコンテキストディレクトリの存在を確認
  • ls [context_path]/Dockerfile でDockerfileの存在を確認
  • docker compose config で展開後のビルド設定を確認
  • docker compose build --no-cache [service] で再ビルドを試行
docker compose up でイメージが古いまま更新されない
想定される原因
  • docker compose up が既存イメージを再利用し再ビルドしない
  • latestタグのイメージが更新されているがローカルキャッシュが古い
  • buildとimageの両方が指定されているときの挙動の誤解
  • --build フラグ付きで実行していない
確認手順
  • docker compose images で使用中のイメージとバージョンを確認
  • docker images [image] でローカルイメージの作成日時を確認
  • docker compose config で image / build の設定を確認
  • レジストリの最新タグとローカルのdigestを比較
Compose V1 から V2 への移行エラー
想定される原因
  • docker-compose V1バイナリが削除/未インストール
  • スクリプトやCI/CDがV1コマンド(docker-compose)を使用
  • V1とV2の動作の微妙な違い(ネットワーク名、コンテナ名のセパレータ等)
  • docker compose プラグインが正しくインストールされていない
確認手順
  • docker compose version でV2プラグインの存在を確認
  • which docker-compose でV1バイナリの存在を確認
  • スクリプト/CI設定で docker-compose の使用箇所を検索
  • docker compose ls でプロジェクトの互換状態を確認
  • コンテナ名の命名規則(- vs _)を確認
Composeのリソース制限が効かない
想定される原因
  • deployセクションのresourcesはSwarmモードまたは--compatibility必須
  • Compose V2ではdeploy.resources.limitsが標準で有効だがV1では無効
  • mem_limit/cpus(旧構文)とdeploy.resources の混在
  • cgroup v2環境でメモリ制限の適用方法が異なる
確認手順
  • docker compose version でバージョンを確認
  • docker stats [container] でリソース制限の適用状態を確認
  • docker inspect [container] | jq '.[0].HostConfig.Memory' で設定を確認
  • docker compose config でリソース設定の展開を確認
  • docker info | grep 'Cgroup Version' でcgroupバージョンを確認
Compose でのログ出力の問題
想定される原因
  • syslogやfluentd等のログドライバではdocker logsで読めない
  • コンテナのアプリケーションがstdout/stderrに出力していない
  • ログドライバの設定(アドレス、タグ等)が間違っている
  • ログローテーション設定でログが早期に削除されている
確認手順
  • docker compose logs [service] でログ出力を確認
  • docker inspect [container] | jq '.[0].HostConfig.LogConfig' でログ設定を確認
  • docker-compose.yml のlogging設定を確認
  • アプリケーションのログ出力先(ファイル vs stdout)を確認
  • docker compose config でログ設定の展開を確認
Compose のセキュリティ設定の問題
想定される原因
  • 必要なLinux capabilityが付与されていない
  • seccompプロファイルが厳しすぎてアプリケーションの動作を阻害
  • read_only: true設定で一時ファイルの書き込みがブロック
  • privileged: trueが必要な操作をunprivilegedで実行
確認手順
  • docker-compose.yml のsecurity_opt, cap_add, cap_drop, read_only を確認
  • docker compose exec [service] capsh --print で付与されたcapabilityを確認
  • docker compose exec [service] cat /proc/1/status | grep Cap で確認
  • dmesg | grep audit でブロックされた操作を確認
  • strace -f で失敗するシステムコールを特定
コンテナのメモリ制限超過でOOM Kill
想定される原因
  • コンテナのメモリ制限が実際のワークロードに対して不足
  • アプリケーションのメモリリークが蓄積
  • JVMヒープサイズがコンテナメモリ制限を考慮していない
  • バッファリングやキャッシュがメモリを圧迫
確認手順
  • docker stats [container] でリアルタイムメモリ使用量を確認
  • docker inspect [container] | jq '.[0].State.OOMKilled' でOOM判定確認
  • cat /sys/fs/cgroup/memory/docker/[id]/memory.max_usage_in_bytes でピーク使用量確認
  • docker inspect [container] | jq '.[0].HostConfig.Memory' でメモリ制限値を確認
  • docker events --filter event=oom でOOMイベントを監視
CPUスロットリングによるレスポンス低下
想定される原因
  • --cpus 制限が低すぎてCFSスロットリングが頻発
  • バースト的なCPU使用パターンに対してquota/periodが合っていない
  • 同一ホスト上の他コンテナとCPUリソースが競合
  • GCやコンパイル等の一時的な高CPU処理がスロットリングに引っかかる
確認手順
  • cat /sys/fs/cgroup/cpu/docker/[id]/cpu.stat でスロットリング統計を確認
  • docker stats --no-stream で全コンテナのCPU使用率を確認
  • docker inspect [container] | jq '.[0].HostConfig.NanoCpus' でCPU制限を確認
  • cat /sys/fs/cgroup/cpu/docker/[id]/cpu.cfs_quota_us でquota値を確認
  • mpstat -P ALL 1 でホストCPU使用率を確認
コンテナのディスクI/Oがボトルネックになる
想定される原因
  • blkioのI/O制限(--device-write-bps等)が設定されている
  • overlayfsのレイヤー構造がI/O性能を低下させている
  • ホストのディスクが他のコンテナや処理でI/O飽和
  • ログ出力がディスクI/Oを圧迫している
確認手順
  • docker inspect [container] | jq '.[0].HostConfig.BlkioDeviceWriteBps' でI/O制限を確認
  • iostat -x 1 でディスクI/O使用率を確認
  • docker stats [container] でBlock I/Oを確認
  • iotop -aoP でプロセス別I/Oを確認
  • cat /sys/fs/cgroup/blkio/docker/[id]/blkio.throttle.io_service_bytes で統計確認
PIDリミットに達してプロセス生成できない
想定される原因
  • --pids-limit で設定した上限に達した
  • フォーク爆弾やスレッドリークで急速にPIDを消費
  • デフォルトのPID制限が小さすぎる(Docker default: unlimited → 一部環境で制限あり)
  • ゾンビプロセスが蓄積してPIDを占有
確認手順
  • docker inspect [container] | jq '.[0].HostConfig.PidsLimit' でPID制限を確認
  • docker exec [container] cat /sys/fs/cgroup/pids/pids.current で現在のPID数を確認
  • docker top [container] でプロセス一覧を確認
  • docker exec [container] ps aux | wc -l でプロセス数をカウント
  • cat /sys/fs/cgroup/pids/docker/[id]/pids.max で制限値を確認
ホストのスワップ使用によるコンテナ性能低下
想定される原因
  • コンテナのメモリ使用量が制限に近くスワップが発生
  • --memory-swap が設定されておりスワップを許容している
  • ホスト全体のメモリが不足してスワップ圧迫
  • swappiness設定が高くアクティブなメモリもスワップアウト
確認手順
  • docker stats [container] でメモリとスワップ使用を確認
  • free -h でホストのメモリ/スワップ状況を確認
  • cat /sys/fs/cgroup/memory/docker/[id]/memory.memsw.usage_in_bytes でスワップ含む使用量確認
  • vmstat 1 でスワップイン/アウトのレートを確認
  • docker inspect [container] | jq '.[0].HostConfig.MemorySwap' でスワップ制限を確認
コンテナのulimit設定不足
想定される原因
  • コンテナのデフォルトulimit(nofile)が低い
  • 高接続数のサービス(nginx, DB等)でファイルディスクリプタが不足
  • ファイルディスクリプタリークでFDが枯渇
  • daemon.jsonのデフォルトulimitが未設定
確認手順
  • docker exec [container] ulimit -a で現在のulimit値を確認
  • docker exec [container] cat /proc/1/limits でプロセスのlimit確認
  • docker inspect [container] | jq '.[0].HostConfig.Ulimits' で設定を確認
  • docker exec [container] ls /proc/[pid]/fd | wc -l で使用中FD数を確認
  • cat /etc/docker/daemon.json のdefault-ulimitsを確認
GPU リソースが利用できない
想定される原因
  • NVIDIA Container Toolkitがインストールされていない
  • NVIDIAドライバがホストにインストールされていない
  • --gpus フラグなしでGPUを使おうとしている
  • daemon.jsonのruntimes設定にnvidiaが登録されていない
確認手順
  • nvidia-smi でホストのGPUドライバ状態を確認
  • docker info | grep Runtimes でnvidiaランタイムの存在を確認
  • dpkg -l | grep nvidia-container でToolkitの有無を確認
  • cat /etc/docker/daemon.json の runtimes 設定を確認
  • docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi でGPUテスト
コンテナのネットワーク帯域制限の問題
想定される原因
  • TCトラフィックシェーピングが設定されている
  • ホストのNIC帯域が他コンテナと共有で飽和
  • overlay/VXLANのオーバーヘッドで実効帯域が低下
  • コンテナのvethインターフェースにqdisc制限がある
確認手順
  • docker exec [container] tc qdisc show dev eth0 でqdisc設定を確認
  • docker exec [container] iperf3 -c [target] -t 10 で帯域テスト
  • iftop -i docker0 でブリッジのトラフィックを確認
  • docker network inspect [network] | jq '.[0].Options' でネットワーク設定を確認
  • ethtool [host_interface] でNIC速度を確認
cgroup v2 でのリソース制限の互換性問題
想定される原因
  • 古いDockerバージョンがcgroup v2を完全サポートしていない
  • systemdのcgroupコントローラ委譲(delegation)が未設定
  • cgroup v2でのメモリ/CPU制限のインターフェースが異なる
  • ハイブリッドモード(v1+v2混在)での互換性問題
確認手順
  • stat -fc %T /sys/fs/cgroup でcgroupバージョン(cgroup2fs or tmpfs)を確認
  • cat /proc/cgroups でコントローラの状態を確認
  • docker info | grep 'Cgroup Version' でDockerが認識するバージョンを確認
  • systemctl show --property=Delegate docker.service で委譲設定を確認
  • cat /sys/fs/cgroup/cgroup.controllers で利用可能なコントローラを確認
Dockerデーモン自体のリソース消費過多
想定される原因
  • 大量のコンテナ管理でデーモンのメモリ使用量が増加
  • goroutineリークによるメモリ消費の増加
  • containerd-shimの孤立プロセスが蓄積
  • デーモンのイベントサブスクリプションが解除されずリーク
確認手順
  • ps -p $(pidof dockerd) -o rss,vsz,pcpu でデーモンリソースを確認
  • curl --unix-socket /var/run/docker.sock http://localhost/debug/pprof/goroutine?debug=1 でgoroutine確認
  • ps aux | grep containerd-shim | wc -l でshimプロセス数を確認
  • docker ps -aq | wc -l でコンテナ総数を確認
  • docker system df でDocker全体のリソース使用を確認
コンテナのストレージ使用量が上限に達した
想定される原因
  • --storage-opt size=10G で設定した書き込みレイヤーの上限に達した
  • コンテナ内でログやテンポラリファイルが蓄積
  • apt/yum のキャッシュが書き込みレイヤーに残っている
  • アプリケーションがボリュームではなくコンテナ内にデータを保存
確認手順
  • docker system df -v でコンテナごとのサイズを確認
  • docker diff [container] でコンテナの変更ファイルを確認
  • docker exec [container] du -sh /* でディレクトリ別使用量を確認
  • docker inspect [container] | jq '.[0].HostConfig.StorageOpt' で制限を確認
  • docker inspect [container] --size | jq '.[0].SizeRw' で書き込みサイズを確認
カーネルのinotifyウォッチャー上限に達した
想定される原因
  • 開発用コンテナのファイルウォッチャーがinotify上限を消費
  • 複数コンテナのnode_modules監視で累積的にウォッチャーを消費
  • カーネルのデフォルト設定(8192)が小さすぎる
  • ファイルウォッチャーのリークで解放されないウォッチが蓄積
確認手順
  • cat /proc/sys/fs/inotify/max_user_watches で現在の上限を確認
  • find /proc/*/fdinfo -name '*.inotify' 2>/dev/null | wc -l で使用中ウォッチャー数を確認
  • docker exec [container] find /proc/1/fd -lname 'anon_inode:inotify' | wc -l
  • sysctl fs.inotify.max_user_watches で値を確認
  • 各コンテナのファイル監視設定を確認
コンテナログの肥大化でディスクが圧迫される
想定される原因
  • ログローテーション(max-size/max-file)が設定されていない
  • アプリケーションが大量のログをstdout/stderrに出力
  • デバッグレベルのログが本番環境でも有効
  • daemon.jsonにデフォルトのログローテーション設定がない
確認手順
  • find /var/lib/docker/containers -name '*-json.log' -exec du -sh {} \; でログサイズを確認
  • docker inspect [container] | jq '.[0].HostConfig.LogConfig' でログ設定を確認
  • cat /etc/docker/daemon.json のlog-opts設定を確認
  • docker system df でDockerのディスク使用状況を確認
  • du -sh /var/lib/docker/containers/*/ で各コンテナのサイズを確認
docker logs コマンドでログが表示されない
想定される原因
  • ログドライバがsyslog/journald/fluentd等でdocker logsに非対応
  • daemon.jsonのデフォルトログドライバがjson-file以外に変更されている
  • コンテナ個別にログドライバを none に設定している
  • アプリケーションがstdout/stderrではなくファイルにログ出力
確認手順
  • docker inspect [container] | jq '.[0].HostConfig.LogConfig.Type' でドライバを確認
  • cat /etc/docker/daemon.json の log-driver 設定を確認
  • docker info | grep 'Logging Driver' でデフォルトドライバを確認
  • docker-compose.yml の logging.driver を確認
  • docker exec [container] cat /app/logs/ でファイルログの確認
Fluentdへのログ転送が失敗する
想定される原因
  • Fluentdコンテナ/サービスが起動していない
  • Fluentdのアドレス/ポート設定が間違っている
  • Fluentdのバッファが満杯でログを受け付けない
  • コンテナがFluentdより先に起動してしまう
確認手順
  • docker ps | grep fluentd でFluentdコンテナの起動状態を確認
  • docker exec [app_container] nc -zv [fluentd_host] 24224 で疎通確認
  • docker logs [fluentd_container] でFluentd側のエラーを確認
  • docker inspect [container] | jq '.[0].HostConfig.LogConfig.Config' で設定を確認
  • docker-compose.yml のfluentdサービスとログ設定を確認
ログのタイムスタンプがずれている
想定される原因
  • コンテナのタイムゾーンがホストと異なる(デフォルトUTC)
  • NTP同期が設定されていないか失敗している
  • アプリケーションが独自のタイムスタンプ形式を使用
  • コンテナ間のクロック同期がされていない
確認手順
  • docker exec [container] date でコンテナ内時刻を確認
  • date でホストの時刻を確認
  • docker exec [container] cat /etc/timezone でタイムゾーンを確認
  • timedatectl でホストのNTP同期状態を確認
  • docker exec [container] cat /etc/localtime を確認
マルチラインログが分割されて表示される
想定される原因
  • Docker のログドライバが行単位で処理するため複数行ログが分割される
  • ログ集約ツール(Fluentd/Logstash)のマルチラインパーサーが未設定
  • スタックトレースやJSON整形出力が複数エントリとして記録
  • アプリケーションのログフォーマットが一貫していない
確認手順
  • docker logs [container] --tail 50 でマルチラインログの分割状態を確認
  • ログ集約ツールのmultiline parser設定を確認
  • アプリケーションのログフォーマッタ設定を確認
  • Fluentd: concat プラグインの設定を確認
  • Logstash: multiline codec の設定を確認
構造化ログ(JSON)のパースエラー
想定される原因
  • アプリケーションが非JSONメッセージ(起動ログ、デバッグ出力)を混在出力
  • JSONログの途中で改行が入り不完全なJSONになる
  • サードパーティライブラリがstdout/stderrに非構造化ログを出力
  • ログスキーマの変更でパーサーとの不整合が発生
確認手順
  • docker logs [container] | head -20 でログフォーマットを確認
  • docker logs [container] | python -m json.tool でJSONバリデーション
  • ログ集約ツールのparse failure metricを確認
  • 非JSONログが混入している箇所を特定
  • アプリケーションのロガー設定を確認
ログドライバの設定変更が既存コンテナに反映されない
想定される原因
  • ログドライバ設定はコンテナ作成時に固定され実行中は変更不可
  • daemon.jsonの変更後にdockerサービスを再起動していない
  • docker compose up がコンテナを再利用して新設定が適用されない
  • コンテナ個別設定がdaemon.jsonのデフォルトを上書き
確認手順
  • docker inspect [container] | jq '.[0].HostConfig.LogConfig' で実際の設定を確認
  • cat /etc/docker/daemon.json の log-driver/log-opts を確認
  • docker info | grep 'Logging Driver' で現在のデフォルトを確認
  • docker-compose.yml の個別logging設定を確認
  • systemctl status docker でデーモンの最終起動時刻を確認
Syslogドライバでログが欠損する
想定される原因
  • UDPプロトコル使用時のパケットロス
  • rsyslogのrate-limiting設定でメッセージが破棄される
  • syslogサーバーの処理能力が不足
  • ネットワーク輻輳によるUDPパケットのドロップ
確認手順
  • docker inspect [container] | jq '.[0].HostConfig.LogConfig.Config' でsyslog設定を確認
  • journalctl --unit rsyslog で rate-limit メッセージを確認
  • cat /etc/rsyslog.conf の $SystemLogRateLimitInterval を確認
  • ss -u -a | grep 514 でUDPソケット状態を確認
  • netstat -su でUDP統計(エラー/ドロップ)を確認
ログの文字化け・エンコーディング問題
想定される原因
  • コンテナのロケールがC/POSIXでUTF-8が未設定
  • アプリケーションがバイナリデータをstdoutに出力
  • ログ集約パイプラインがUTF-8以外のエンコーディングに未対応
  • マルチバイト文字がバッファ境界で分断される
確認手順
  • docker exec [container] locale でロケール設定を確認
  • docker logs [container] | file - で出力のエンコーディングを確認
  • docker exec [container] echo $LANG で言語設定を確認
  • ログ集約ツールのcharset設定を確認
  • アプリケーションの出力エンコーディング設定を確認
ログの集約・検索が遅い(ELKスタック)
想定される原因
  • Elasticsearchのインデックス設定(シャード数/レプリカ数)が不適切
  • ログ量に対してElasticsearchクラスタのリソースが不足
  • インデックスのライフサイクル管理(ILM)が未設定で肥大化
  • マッピング爆発(field数過多)でインデックス性能が低下
確認手順
  • curl localhost:9200/_cluster/health でクラスタ状態を確認
  • curl localhost:9200/_cat/indices?v でインデックスサイズを確認
  • curl localhost:9200/_nodes/stats でノードリソースを確認
  • Logstash/Fluentdのバッファ状態を確認
  • Elasticsearch slow log を確認
コンテナログにセンシティブ情報が含まれる
想定される原因
  • アプリケーションが環境変数やデバッグ情報をそのまま出力
  • フレームワークのリクエストログにAuthorizationヘッダーが含まれる
  • エラーハンドリングで接続文字列(パスワード含む)をログ出力
  • docker inspect の出力にシークレットが平文で含まれる
確認手順
  • docker logs [container] | grep -i 'password\|secret\|key\|token' でセンシティブ情報を検索
  • アプリケーションのロガー設定でマスキングルールを確認
  • docker inspect [container] | jq '.[0].Config.Env' で環境変数を確認
  • ログ集約パイプラインのフィルター/マスキング設定を確認
  • Dockerfile のENV命令にシークレットが含まれていないか確認
ログのラベル・タグ付けが正しく機能しない
想定される原因
  • コンテナにラベルが設定されていない
  • ログドライバのtagテンプレートの構文エラー
  • ラベルベースのルーティングで期待するラベルが欠落
  • docker compose のラベル設定とログパイプラインの不一致
確認手順
  • docker inspect [container] | jq '.[0].Config.Labels' でラベルを確認
  • docker inspect [container] | jq '.[0].HostConfig.LogConfig.Config.tag' でタグ設定を確認
  • ログ集約ツールのルーティング設定とラベル名を照合
  • docker-compose.yml の labels 定義を確認
  • Fluentd/Logstash のタグフィルター設定を確認
特権コンテナのセキュリティリスク
想定される原因
  • docker run --privileged で全権限付与されている
  • 開発時の設定がそのまま本番に残っている
  • DinD(Docker in Docker)で安易に特権モードを使用
  • デバイスアクセスのために不必要に特権を付与
確認手順
  • docker inspect [container] | jq '.[0].HostConfig.Privileged' で特権モードを確認
  • docker inspect [container] | jq '.[0].HostConfig.CapAdd' で追加capabilityを確認
  • docker ps --filter label=com.docker.compose.service でサービス一覧から特権を調査
  • docker inspect [container] | jq '.[0].HostConfig.Devices' でデバイスマウントを確認
  • docker inspect [container] | jq '.[0].HostConfig.PidMode' でPID名前空間を確認
コンテナイメージの脆弱性が検出された
想定される原因
  • ベースイメージが長期間更新されていない
  • アプリケーションの依存ライブラリに既知の脆弱性
  • 不要なパッケージがイメージに含まれ攻撃面が拡大
  • EOLのベースイメージを使用している
確認手順
  • docker scout cves [image] でイメージの脆弱性をスキャン
  • trivy image [image] で詳細レポートを取得
  • docker scout recommendations [image] で推奨を確認
  • grype [image] で脆弱性をチェック
  • docker scout compare --to [updated_image] で修正状況を比較
Docker API が認証なしで外部公開されている
想定される原因
  • daemon.jsonで -H tcp://0.0.0.0:2375 と設定しTLS未設定
  • ファイアウォールがDockerポートを外部に公開している
  • TLS設定のテスト後に認証を無効のまま残している
  • クラウドのセキュリティグループ設定ミス
確認手順
  • cat /etc/docker/daemon.json の hosts 設定を確認
  • ss -tlnp | grep 2375 でTCP未暗号化ポートのリスンを確認
  • curl http://[public_ip]:2375/version で外部からのアクセス可否を確認
  • iptables -L INPUT | grep 2375 でファイアウォールルールを確認
  • docker logs で不審なコンテナ起動ログを確認
コンテナ内でrootとして実行されている
想定される原因
  • DockerfileにUSER命令がなくデフォルトのrootで実行
  • パッケージインストール後にUSERを非rootに切り替えていない
  • rootが必要な初期化処理のためにroot実行を維持
  • ベースイメージがrootユーザーのみ定義
確認手順
  • docker exec [container] id で実行ユーザーを確認
  • docker inspect [container] | jq '.[0].Config.User' でUser設定を確認
  • Dockerfile の USER 命令の有無を確認
  • docker exec [container] cat /etc/passwd で利用可能ユーザーを確認
  • docker history [image] で USER 変更レイヤーを確認
シークレットがイメージレイヤーに残存している
想定される原因
  • ENV命令でシークレットをイメージに焼き込んでいる
  • COPY でシークレットファイルを追加した後にRMしても前のレイヤーに残る
  • ARGで渡したシークレットがdocker historyで確認可能
  • マルチステージビルドの初期ステージにシークレットが残存
確認手順
  • docker history --no-trunc [image] で全レイヤーのコマンドを確認
  • docker save [image] | tar -xf - で全レイヤーを展開して検索
  • dive [image] でレイヤーごとのファイル変更を確認
  • docker inspect [image] | jq '.[0].Config.Env' で環境変数を確認
  • git log --all -- '*credentials*' '*secret*' でリポジトリ内のシークレットを確認
コンテナエスケープの脆弱性
想定される原因
  • runc/containerdに既知のエスケープ脆弱性(CVE)が存在
  • カーネルの脆弱性を利用した名前空間のバイパス
  • 不適切なボリュームマウント(/等のホストルート)
  • 特権コンテナ + ホストネームスペース共有の組み合わせ
確認手順
  • runc --version でバージョンと既知CVEを照合
  • containerd --version でバージョンを確認
  • docker version で全コンポーネントのバージョンを確認
  • docker inspect [container] | jq '.[0].HostConfig' でホスト共有設定を確認
  • uname -r でカーネルバージョンと既知脆弱性を照合
ネットワークポリシーの欠如によるコンテナ間の不正アクセス
想定される原因
  • デフォルトのicc=true設定で全コンテナ間通信が許可
  • フロントエンドとバックエンドが同じネットワークで分離されていない
  • ネットワークセグメンテーションポリシーが未定義
  • internalネットワーク設定が使われていない
確認手順
  • docker network inspect bridge | jq '.[0].Options."com.docker.network.bridge.enable_icc"'
  • docker network ls で全ネットワークとコンテナの所属を確認
  • docker inspect [container] | jq '.[0].NetworkSettings.Networks' で接続先を確認
  • iptables -L DOCKER-ISOLATION-STAGE-1 で分離ルールを確認
  • 各サービスのポートアクセスパターンを分析
Docker Socket マウントによるホスト制御リスク
想定される原因
  • CI/CDランナーにdocker.sockをマウントしてDooD構成
  • 監視ツールにdocker.sockを読み取り用でマウント
  • Docker管理UIにフルアクセスのsocketを提供
  • 開発用コンテナにdocker.sockを安易にマウント
確認手順
  • docker inspect [container] | jq '.[0].Mounts[] | select(.Destination=="/var/run/docker.sock")' で確認
  • docker ps --filter volume=/var/run/docker.sock でsocketマウントコンテナを一覧
  • docker exec [container] docker ps でコンテナからのDocker API アクセスを確認
  • docker-compose.yml で /var/run/docker.sock のマウントを検索
  • コンテナ内からdocker run --privileged が実行可能か確認
イメージのサプライチェーン攻撃リスク
想定される原因
  • Docker Content Trust(DCT)が無効でイメージ署名を検証していない
  • 信頼できないサードパーティイメージを検証なしで使用
  • ベースイメージのダイジェスト固定をしていない(:latest使用)
  • プライベートレジストリで署名検証が設定されていない
確認手順
  • echo $DOCKER_CONTENT_TRUST でContent Trust設定を確認
  • docker trust inspect [image] で署名情報を確認
  • cosign verify [image] で cosign 署名を検証
  • Dockerfileのベースイメージがdigest指定かタグ指定か確認
  • 使用中のサードパーティイメージの出元を確認
Seccomp プロファイルによるシステムコールブロック
想定される原因
  • デフォルトのseccompプロファイルがアプリケーションに必要なシステムコールを制限
  • 新しいカーネルのシステムコール(clone3等)がプロファイルに未登録
  • カスタムseccompプロファイルが厳しすぎる
  • Dockerバージョンとカーネルバージョンの組み合わせで不整合
確認手順
  • docker inspect [container] | jq '.[0].HostConfig.SecurityOpt' でseccomp設定を確認
  • dmesg | grep seccomp でブロックされたシステムコールを確認
  • ausearch -m seccomp -ts recent で監査ログからブロック情報を取得
  • strace -f [command] でアプリケーションが使用するシステムコールを特定
  • docker run --security-opt seccomp=unconfined でseccomp無効テスト
コンテナのリソース制限未設定による DoS リスク
想定される原因
  • docker run でリソース制限オプションが指定されていない
  • docker-compose.yml にdeploy.resources.limitsが未設定
  • デフォルト設定のままで本番デプロイ
  • リソース制限がcgroup未対応で無効化されている
確認手順
  • docker stats --no-stream で全コンテナのリソース使用と制限を確認
  • docker inspect [container] | jq '.[0].HostConfig | {Memory, NanoCpus, PidsLimit}' で制限を確認
  • docker info | grep 'WARNING' でcgroup関連の警告を確認
  • docker system info | grep -i 'cgroup' でcgroupサポートを確認
  • 各コンテナのリソース使用パターンを分析
Docker Compose の .env ファイルがリポジトリに含まれている
想定される原因
  • .gitignore に .env が追加されていない
  • 過去のコミットに .env が含まれたままで history に残存
  • .env.example と .env を混同してコミット
  • CI/CDの設定ファイルにシークレットがハードコードされている
確認手順
  • git log --all --full-history -- '.env' で.envのコミット履歴を確認
  • cat .gitignore | grep env で除外設定を確認
  • git ls-files | grep -i env でトラッキング中のenvファイルを確認
  • gitleaks detect で リポジトリ全体のシークレットスキャン
  • trufflehog git [repo_url] でgit履歴のシークレットを検出