القائمة
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Jules REST APIを使用してタスクを対話的に依頼・管理する。セッション作成・プラン承認・メッセージ送信・進捗監視をAPI経由で行い、Claudeと協調してタスクを完遂する。ベースブランチ指定とPR自動作成に対応。認証はJULES_API_KEY_OP_URI（1Passwordシークレット参照）またはJULES_API_KEYで行う。Do NOT use for 認証情報未設定の環境でのタスク実行（task-executingを使用すること）。
SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業（requirements-defining、software-designing、task-planningを直接使用すること）。
設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
SDDドキュメントの整合性チェック、実装同期確認、アーカイブ（CLAUDE.md同期含む）、ファイル最適化を行う。ドキュメント間の矛盾検出、実装との乖離確認、完了タスクの整理と仕様のCLAUDE.md転記、肥大化ファイルの分割が必要な場合に使用する。Do NOT use for ドキュメントの新規作成（requirements-defining、software-designing、task-planningを使用すること）。
エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirements-definingを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
استنادا إلى تصنيف SOC المهني
| name | health-check |
| description | インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。 |
| metadata | {"version":"1.0.0"} |
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価・レポートします。
このスキルは以下の機能を提供します:
以下の状況でこのスキルを使用してください:
「ヘルスチェックを実施したい」「サービスの状態を確認したい」「インフラメトリクスを調査したい」などと依頼されたら、以下の手順で進めます。
調査に入る前に、以下の情報をユーザーに確認します。必ずAskUserQuestionツールを使用してください。
[health-check] ステップ 1/6: 事前情報の収集
ヘルスチェックの対象について確認させてください:
- 対象のサービス/アカウント: どのサービスやアカウントを調査しますか？
- 監視ダッシュボードのURL: メトリクスを確認するダッシュボードはありますか？
- 調査対象期間: どの期間を確認しますか？（例: 直近24時間、直近1週間）
以下の情報があれば収集します（不明な場合はスキップ可能）:
調査対象のナレッジベースファイルが存在する場合は読み込みます:
[health-check] ステップ 2/6: 全体俯瞰
重要: ブラウザ自動化ツールでダッシュボードを確認する場合は references/browser_automation_guide_ja.md を参照してください。調査品質の保証、データ抽出の注意点、SPA固有の制約を記載しています。
クロスアカウント/クロスサービスの一括ダッシュボードを確認し、異常のあるアカウント/サービスを特定します。
ユーザーにダッシュボードの状態を確認しながら、以下を整理します:
アラートの全体状況
コストの全体傾向
主要メトリクスの異常値
確認した結果を以下の形式で整理します:
## 全体俯瞰サマリー
| サービス/アカウント | ステータス | 主な所見 |
|---------------------|-----------|----------|
| サービスA | 正常 | 特記なし |
| サービスB | 注意 | CPU使用率上昇傾向 |
| サービスC | 警告 | アラート発火中（5xx増加） |
→ 詳細深掘り対象: サービスB、サービスC
[health-check] ステップ 3/6: 詳細深掘り
全体俯瞰で異常または注意と判定したサービスについて、11カテゴリのメトリクスを詳細に確認します。
重要: メトリクスのリファレンスは references/metrics_guide_ja.md を参照してください。使用する直前に読み込みます。
各カテゴリの詳細は references/metrics_guide_ja.md に記載されています。以下は概要です:
| # | カテゴリ | 主な確認項目 |
|---|---|---|
| A | コスト | 日次/週次/月次推移、前日比/前週比、リクエスト連動性 |
| B | アラート | トリガー状態、発火履歴、同時発火パターン |
| C | ロードバランサー | リクエスト数パターン、レスポンスタイム、エラー率、Unhealthy host |
| D | CPU | アプリコンテナ、EC2/VM、検索エンジン、3系統同時上昇 |
| E | メモリ | 空きメモリ率、使用量傾向（リーク疑い）、JVMヒープ特性 |
| F | データベース | RDS CPU、接続数、デッドロック、ストレージ |
| G | キャッシュ | メモリ余裕度、Eviction、CPU、接続数 |
| H | キュー/ストリーム | メッセージ滞留時間、DLQ、スループット |
| I | 検索エンジン | ディスク使用率、ノードCPU、インデクシング遅延 |
| J | 証明書・外形監視 | SSL残日数、レスポンスタイム、稼働率 |
| K | アプリケーション基盤 | GC、エラーログ、Lambda、SESバウンス率、CPUクレジット |
対象サービスに該当しないカテゴリはスキップしてください。
[health-check] ステップ 4/6: 相関分析
分析原則のリファレンスは references/analysis_principles_ja.md を参照してください。使用する直前に読み込みます。
収集したメトリクス情報に基づき、5大原則を適用して分析します:
| パターン | メトリクスの組み合わせ | 示唆する状況 |
|---|---|---|
| インフラ障害 | アラート発火 + リクエスト変動 + コスト変動 | サービス影響あり |
| リソース逼迫 | CPU上昇 + レスポンスタイム悪化 + エラー増 | スケーリング要検討 |
| JVMヒープ枯渇 | GC頻発 + GCポーズ増大 + p95悪化 | ヒープサイズ/リーク調査 |
| メッセージ処理障害 | キュー滞留 + DLQメッセージ増加 | コンシューマ調査 |
| 正常スケーリング | コスト増 + リクエスト増（連動） | 需要増対応 |
| インフラ変更起因 | コスト増 + リクエスト横ばい（乖離） | 変更内容の確認 |
| キャッシュ破壊 | Eviction増加 + DB CPU上昇 + レスポンスタイム悪化 | キャッシュメモリ増設/戦略見直し |
| ストレージ逼迫 | ディスク使用率上昇 + DB CPU上昇 + レスポンスタイム悪化 | データクリーンアップ/ストレージ拡張 |
[health-check] ステップ 5/6: レポート作成
レポートテンプレートは assets/templates/health_check_report_template_ja.md を参照してください。使用する直前に読み込みます。
調査結果をレポートテンプレートに基づいて構造化します。
| セクション | 内容 |
|---|---|
| 調査概要 | 調査日時、対象、調査者、調査期間 |
| エグゼクティブサマリー | 全体の健全性評価（1-2行）と即時対応が必要な事項 |
| 重大な異常 | サービス影響の可能性があるもの。優先度・内容・推奨アクションを明記 |
| 中程度の注意点 | 閾値内だが通常と異なる傾向。経過観察か予防的対応かを判断 |
| 正常範囲の項目 | テーブル形式で簡潔に。閾値方向が直感と逆のメトリクスは正常理由を補足 |
| 相関分析の結果 | メトリクス間の相関の有無を明示（なかった場合も記載 → 調査の網羅性を示す） |
| エスカレーション済み案件の経過 | 前回からの変化（悪化/改善/横ばい）を差分で明記 |
| 推奨アクション | 優先度・内容・対象をテーブルで整理 |
[health-check] ステップ 6/6: ナレッジベース更新
ナレッジベーステンプレートは assets/templates/knowledge_base_template_ja.md を参照してください。使用する直前に読み込みます。
調査で得られた知見をナレッジベースに蓄積します。
レポートの保存先はユーザーに確認します:
ヘルスチェックレポートの保存先を確認させてください。
デフォルトでは以下のパスに保存します:
[プロジェクトルート]/health-check-reports/[YYYY-MM-DD]-health-check.md
このまま進めてよろしいですか？
別のパスを指定する場合は、パスをお知らせください。
ナレッジベースの保存先もユーザーに確認します:
ナレッジベースファイルの保存先を確認させてください。
デフォルトでは以下のパスに保存します:
[プロジェクトルート]/health-check-reports/knowledge-base.md
既存のナレッジベースファイルがある場合は、そのパスを教えてください。
[プロジェクトルート]/
└── health-check-reports/
├── knowledge-base.md # ナレッジベース（蓄積型）
├── [YYYY-MM-DD]-health-check.md # 日次レポート
├── [YYYY-MM-DD]-health-check.md
└── ...
| 項目 | 内容 |
|---|---|
| 目的 | 異常のあるアカウント/サービスを特定 |
| 方法 | クロスアカウント一括ダッシュボード |
| 所要時間 | 5-10分 |
| 出力 | 詳細深掘り対象リスト |
| 項目 | 内容 |
|---|---|
| 目的 | 特定アカウントの根本原因を調査 |
| 方法 | アカウント別フィルタダッシュボード |
| 所要時間 | サービスあたり10-20分 |
| 出力 | カテゴリ別メトリクス評価 |
【重要】質問が必要な場合は必ずAskUserQuestionツールを使用する
前提: スクロール量やチェックリスト手順はブラウザ自動化ガイド（
references/browser_automation_guide_ja.md）で定義済み。ユーザーから調査対象URL・サービス・閾値が提示されない場合は、調査開始前に確認する。
references/browser_automation_guide_ja.md セクション2を参照）同じ手順で調査すれば同じ結論に至ることを目指します:
単発の値よりも変化を重視します:
定期バッチや業務サイクルによるスパイクを誤検知しないようにします:
単一メトリクスではなく、複数メトリクスの組み合わせで判断します:
推奨アクションは具体的に記載します: