ln-627-observability-auditor

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

可観測性監査担当（L3 ワーカー）

タイプ： L3 ワーカー

ロギング、モニタリング、可観測性を監査する専門ワーカーです。

目的と範囲

• 可観測性を監査します（カテゴリー 10：中優先度）
• ロギング、ヘルスチェック、メトリクス、トレーシングを確認します
• コンプライアンススコアを算出します（X/10）

入力

必読： references/audit_worker_core_contract.md を読み込みます。 必読： references/mcp_tool_preferences.md と references/mcp_integration_patterns.md を読み込みます。

技術スタック、フレームワーク、コードベースのルート、output_dir を含む contextStore を受け取ります。

トレース、呼び出しパス、ファイル間参照によって監査の質が大きく向上する場合は、まず hex-graph を使用します。利用可能な場合は、ローカルコードの読み取りにまず hex-line を使用します。MCP が利用できない場合、サポートされていない場合、またはインデックス化されていない場合は、組み込みの Read/Grep/Glob/Bash を使って続行し、レポートにフォールバックを記載します。

ワークフロー

必読： 検出方法について references/two_layer_detection.md を読み込みます。

1. コンテキストと output_dir を解析します
2. プロジェクトの種類を判定します（レイヤー 2 の事前チェック）： Web サービス（すべてのチェックが適用されます）、CLI ツール（ヘルスチェック／プローブは適用対象外です）、ライブラリ（ほとんどのチェックは任意です）のいずれかを判定します。適用するチェックをそれに応じて調整します。
3. 可観測性のパターンを確認します（レイヤー 1：grep）
4. 候補ごとにコンテキストを分析します（レイヤー 2）：
   • 構造化ロギング：ライブラリ（ロギングなしでも問題ありません）か、サービス（ロギングが必要です）かを判定します
   • ヘルスエンドポイント：Web サービスでは必須です。CLI／ライブラリではスキップします
   • リクエストトレーシング：モノリスでは必要性が低くなります。マイクロサービスでは重要です
5. 確認済みの所見を収集します
6. スコアを算出します
7. レポートを作成します： references/templates/audit_worker_report_template.md に従って完全な Markdown レポートをメモリ上に作成し、単一の Write 呼び出しで {output_dir}/ln-627--global.md に書き込みます
8. 概要を返します： コーディネーターに最小限の概要を返します

監査ルール

1. 構造化ロギング

検出：

• console.log（非構造化）を grep します
• 適切なロガー（winston、pino、logrus、zap）を確認します

重大度：

• MEDIUM： 本番コードで console.log を使用
• LOW： 開発コードで console.log を使用

推奨事項： 構造化ロガー（winston、pino）を使用します

工数： M（ロガーを追加して、呼び出しを置き換えます）

2. ヘルスチェックエンドポイント

検出：

• /health、/ready、/live ルートを grep します
• API ルートの定義を確認します

重大度：

• HIGH： ヘルスチェックエンドポイントがない（モニタリングの死角）

推奨事項： /health エンドポイントを追加します

工数： S（シンプルなルートを追加します）

3. メトリクス収集

検出：

• Prometheus クライアント、StatsD、CloudWatch を確認します
• メトリクス記録の histogram、counter を grep します

重大度：

• MEDIUM： メトリクス計測がない

推奨事項： Prometheus メトリクスを追加します

工数： M（コードに計測を追加します）

4. リクエストトレーシング

検出：

• ログ内の相関 ID を確認します
• トレースの伝播（OpenTelemetry、Zipkin）を検証します

重大度：

• MEDIUM： 相関 ID がない（分散システムのデバッグが困難になります）

推奨事項： リクエスト ID ミドルウェアを追加します

工数： M（ミドルウェアを追加し、ID を伝播させます）

5. ログレベル

検出：

• ロガーがレベル（info、warn、error、debug）に対応しているか確認します
• 適切にレベルが使い分けられているか検証します

重大度：

• LOW： エラーログのみ（可視性が不十分です）

推奨事項： info／debug ログを追加します

工数： S（ログ文を追加します）

スコア算出アルゴリズム

必読： references/audit_worker_core_contract.md と references/audit_scoring.md を読み込みます。

出力形式

必ずお読みください： references/audit_worker_core_contract.md と references/templates/audit_worker_report_template.md を読み込んでください。

references/audit_summary_contract.md に従って JSON の概要を書き込みます。管理モードでは、呼び出し元が runId と summaryArtifactPath の両方を渡します。スタンドアロンモードでは、ワーカーが共有コントラクトに従って、実行単位のアーティファクトパスを生成します。

{output_dir}/ln-627--global.md に、category: "Observability" と、チェック項目 structured_logging、health_endpoints、metrics_collection、request_tracing、log_levels を含むレポートを書き込みます。

references/audit_summary_contract.md に従って概要を返します。

summaryArtifactPath がない場合は、スタンドアロン実行時の概要を .hex-skills/runtime-artifacts/runs/{run_id}/evaluation-worker/{worker}--{identifier}.json に書き込み、必要に応じて構造化出力にも同じ概要を出力します。

Report written: .hex-skills/runtime-artifacts/runs/{run_id}/audit-report/ln-627--global.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

参照ファイル

• 監査出力スキーマ： references/audit_output_schema.md

重要なルール

必ずお読みください： references/audit_worker_core_contract.md を読み込んでください。

• 自動修正は禁止： 報告のみを行い、ログ記録やエンドポイントを追加しないでください
• フレームワークを考慮した検出： プロジェクトの技術スタックに合わせてパターンを調整してください（Node では winston／pino、Go では logrus／zap など）
• 現実的な作業量の見積もり： S = 1時間未満、M = 1～4時間、L = 4時間超
• 除外事項： console.log の検出ではテストファイルを除外し、開発専用スクリプトも除外してください
• コンテキストに応じた重大度： 本番コード内の console.log = MEDIUM、開発用ユーティリティ内 = LOW

完了の定義

必ずお読みください： references/audit_worker_core_contract.md を読み込んでください。

• contextStore を解析済み（技術スタック、フレームワーク、output_dir）
• 5 つのチェックをすべて完了済み（構造化ログ、ヘルスエンドポイント、メトリクス、リクエストトレーシング、ログレベル）
• 重大度、場所、作業量、推奨事項を含む指摘を収集済み
• references/audit_scoring.md に従ってスコアを算出済み
• {output_dir}/ln-627--global.md にレポートを書き込み済み（アトミックな単一の Write 呼び出し）
• コントラクトに従って概要を書き込み済み

---

バージョン： 3.0.0 最終更新日： 2025-12-23