🍽️ レストランの人気ランキングで例えると超わかりやすい!
CloudWatchには2種類のメトリクスがあります
📈 通常のメトリクス：
「今日は何人のお客様が来たか？」を数える
🏆 INSIGHT_RULE_METRIC：
「誰が一番多く注文しているか？」を自動で見つける
通常のメトリクスは
「全体の数」
を追跡しますが、
INSIGHT_RULE_METRICは
「トップコントリビューター（最も影響を与えている人・もの）」
を自動発見します！
例えば、APIエラーが増えた時に
「どのIPアドレスが最もエラーを出しているか？」
を自動で教えてくれます✨
通常のメトリクス
Standard CloudWatch Metrics
🎯
何を測る？
全体の合計値や平均値
• 今日の来店客数：500人
• 今日の売上：100万円
• APIの呼び出し回数：10,000回
• 今日の来店客数：500人
• 今日の売上：100万円
• APIの呼び出し回数：10,000回
❓
答えられる質問
• 「全部で何回？」
• 「平均はどれくらい？」
• 「合計はいくつ？」
• 「平均はどれくらい？」
• 「合計はいくつ？」
🍽️
レストランの例
「今日の総注文数：300件」
全体の数はわかるけど、
誰が何を注文したかは分からない
全体の数はわかるけど、
誰が何を注文したかは分からない
⚡
得意なこと
• トレンド分析
• 容量計画
• 全体的なパフォーマンス監視
• 容量計画
• 全体的なパフォーマンス監視
😓
苦手なこと
• 「誰が」原因か分からない
• 特定のユーザー追跡不可
• 問題の根本原因特定が困難
• 特定のユーザー追跡不可
• 問題の根本原因特定が困難
INSIGHT_RULE_METRIC
Contributor Insights Metrics
🎯
何を測る？
Top-Nコントリビューター
• 最も多く呼び出すIPアドレス Top 10
• 最もエラーを出すユーザー Top 5
• 最も帯域を使う接続元 Top 20
• 最も多く呼び出すIPアドレス Top 10
• 最もエラーを出すユーザー Top 5
• 最も帯域を使う接続元 Top 20
❓
答えられる質問
•
「誰が最も？」
• 「何が最も？」
• 「どこから最も？」
• 「何が最も？」
• 「どこから最も？」
🍽️
レストランの例
「人気メニュー Top 5」
1位: ステーキ（田中さん20回）
2位: パスタ（鈴木さん15回）
3位: サラダ（佐藤さん12回）
→ 誰が何を好むか自動追跡！
1位: ステーキ（田中さん20回）
2位: パスタ（鈴木さん15回）
3位: サラダ（佐藤さん12回）
→ 誰が何を好むか自動追跡！
⚡
得意なこと
• 問題の根本原因を即座に特定
• 異常なユーザー/IPを自動発見
• リアルタイムでTop-N追跡
• 異常なユーザー/IPを自動発見
• リアルタイムでTop-N追跡
😓
苦手なこと
• 全体のトレンド分析
• 長期的な容量計画
• コストが通常メトリクスより高い
• 長期的な容量計画
• コストが通常メトリクスより高い
🍽️ レストランチェーンで完全理解！
通常のメトリクス
「レジの集計」
📝 シチュエーション：
あなたは全国100店舗を持つレストランチェーンのオーナー。毎日の売上を知りたい。
あなたは全国100店舗を持つレストランチェーンのオーナー。毎日の売上を知りたい。
📈 通常のメトリクスでわかること：
• 今日の総売上：500万円
• 総来店客数：1,000人
• 平均客単価：5,000円
• ピークタイム：12時〜13時
• 今日の総売上：500万円
• 総来店客数：1,000人
• 平均客単価：5,000円
• ピークタイム：12時〜13時
😓 わからないこと：
• どのお客様が常連か？
• どのメニューが人気か？
• クレームが多い店舗は？
• 特定の問題の原因は？
• どのお客様が常連か？
• どのメニューが人気か？
• クレームが多い店舗は？
• 特定の問題の原因は？
💭 オーナーの困りごと：
「売上が落ちてる...でも、
どの店舗が？どのメニューが？どのお客様層が？
全部の店舗を1つずつ調べるのは大変！」
「売上が落ちてる...でも、
どの店舗が？どのメニューが？どのお客様層が？
全部の店舗を1つずつ調べるのは大変！」
INSIGHT_RULE_METRIC
「自動ランキングシステム」
📝 シチュエーション：
魔法のシステムが自動で「誰が」「何を」最も影響しているかランキング化！
魔法のシステムが自動で「誰が」「何を」最も影響しているかランキング化！
🏆 INSIGHT_RULE_METRICでわかること：
• 売上貢献 Top 10 顧客
1位: 田中さん（月50万円）
2位: 鈴木さん（月30万円）
• 人気メニュー Top 5
• クレームが多い店舗 Top 3
• 待ち時間が長い時間帯 Top 5
• 売上貢献 Top 10 顧客
1位: 田中さん（月50万円）
2位: 鈴木さん（月30万円）
• 人気メニュー Top 5
• クレームが多い店舗 Top 3
• 待ち時間が長い時間帯 Top 5
✨ すごいところ：
• 自動で ランキング更新
• リアルタイムで 変化追跡
• 問題が起きたら 即座に原因特定
• 自動で ランキング更新
• リアルタイムで 変化追跡
• 問題が起きたら 即座に原因特定
😊 オーナーの喜び：
「昨日からクレームが急増...あ！
新宿店のパスタが原因 だって
システムが教えてくれた！
すぐに対応できる！」
「昨日からクレームが急増...あ！
新宿店のパスタが原因 だって
システムが教えてくれた！
すぐに対応できる！」
⚙️ INSIGHT_RULE_METRICの仕組み
1
ルール作成（どんなランキングを作る？）
🍽️ レストランの例：
「各店舗で、 どのメニューが 最も注文されているか？ Top 10を追跡して！」
💻 AWSの例：
「APIに対して、 どのIPアドレスが 最も多く呼び出しているか？ Top 20を追跡して！」
📋 設定内容：
• データソース：CloudWatch Logsまたはメトリクス
• 集約キー：IPアドレス、ユーザーID、URL等
• Top-N：上位いくつを追跡するか
「各店舗で、 どのメニューが 最も注文されているか？ Top 10を追跡して！」
💻 AWSの例：
「APIに対して、 どのIPアドレスが 最も多く呼び出しているか？ Top 20を追跡して！」
📋 設定内容：
• データソース：CloudWatch Logsまたはメトリクス
• 集約キー：IPアドレス、ユーザーID、URL等
• Top-N：上位いくつを追跡するか
⬇️
2
自動データ収集（裏で勝手に集計中）
🍽️ レストランの例：
魔法のシステムが全店舗の注文を自動集計
• 渋谷店：ステーキ 50回、パスタ 30回...
• 新宿店：パスタ 80回、サラダ 40回...
• 池袋店：ハンバーグ 60回、ステーキ 45回...
💻 AWSの例：
Contributor Insightsが自動でログ/メトリクスを分析
• 192.168.1.1：1000回
• 10.0.0.5：800回
• 172.16.0.10：600回
⚡ ポイント： 手動集計は一切不要！
魔法のシステムが全店舗の注文を自動集計
• 渋谷店：ステーキ 50回、パスタ 30回...
• 新宿店：パスタ 80回、サラダ 40回...
• 池袋店：ハンバーグ 60回、ステーキ 45回...
💻 AWSの例：
Contributor Insightsが自動でログ/メトリクスを分析
• 192.168.1.1：1000回
• 10.0.0.5：800回
• 172.16.0.10：600回
⚡ ポイント： 手動集計は一切不要！
⬇️
3
ランキング自動生成（Top-Nが判明！）
🍽️ レストランの例：
📊 全店舗の人気メニュー Top 5：
🥇 1位：ステーキ（全店で計500回）
🥈 2位：パスタ（全店で計450回）
🥉 3位：ハンバーグ（全店で計380回）
4位：サラダ（全店で計320回）
5位：カレー（全店で計280回）
💻 AWSの例：
📊 API呼び出しが多いIP Top 10：
🥇 1位：192.168.1.1（10,000回）
🥈 2位：10.0.0.5（8,500回）
🥉 3位：172.16.0.10（7,200回）
...（以下、Top 10まで自動表示）
📊 全店舗の人気メニュー Top 5：
🥇 1位：ステーキ（全店で計500回）
🥈 2位：パスタ（全店で計450回）
🥉 3位：ハンバーグ（全店で計380回）
4位：サラダ（全店で計320回）
5位：カレー（全店で計280回）
💻 AWSの例：
📊 API呼び出しが多いIP Top 10：
🥇 1位：192.168.1.1（10,000回）
🥈 2位：10.0.0.5（8,500回）
🥉 3位：172.16.0.10（7,200回）
...（以下、Top 10まで自動表示）
⬇️
4
メトリクスとして保存（INSIGHT_RULE_METRIC誕生！）
🎯 重要：
このランキングデータが
INSIGHT_RULE_METRIC として保存されます！
📊 保存される情報：
• 各コントリビューターの値（例：192.168.1.1 → 10,000回）
• ランキング順位（1位、2位、3位...）
• 時系列での変化（今日は1位だったが、昨日は5位だった等）
✨ できること：
• CloudWatchダッシュボードで可視化
• アラーム設定（特定のIPが急増したら通知）
• 過去データとの比較分析
INSIGHT_RULE_METRIC として保存されます！
📊 保存される情報：
• 各コントリビューターの値（例：192.168.1.1 → 10,000回）
• ランキング順位（1位、2位、3位...）
• 時系列での変化（今日は1位だったが、昨日は5位だった等）
✨ できること：
• CloudWatchダッシュボードで可視化
• アラーム設定（特定のIPが急増したら通知）
• 過去データとの比較分析
⬇️
5
リアルタイム更新（常に最新ランキング）
⏱️ 自動更新：
設定した間隔（例：5分ごと）で自動的にランキング更新
🍽️ レストランの例：
ランチタイムにパスタが急に人気！
→ 5分後にはランキングに反映
→ スタッフが素早くパスタを増産
💻 AWSの例：
特定のIPからの異常なアクセス増加
→ 即座にランキング上位に浮上
→ アラームが発火して管理者に通知
→ 迅速にブロック対応可能！
設定した間隔（例：5分ごと）で自動的にランキング更新
🍽️ レストランの例：
ランチタイムにパスタが急に人気！
→ 5分後にはランキングに反映
→ スタッフが素早くパスタを増産
💻 AWSの例：
特定のIPからの異常なアクセス増加
→ 即座にランキング上位に浮上
→ アラームが発火して管理者に通知
→ 迅速にブロック対応可能！
📋 詳細比較表
| 項目 | 通常のメトリクス | INSIGHT_RULE_METRIC |
|---|---|---|
| データの種類 | 合計値、平均値、最大値等 | Top-Nコントリビューターのランキング |
| 答えられる質問 | 「全体でどれくらい？」 | 「誰が/何が最も影響している？」 |
| データソース | AWSサービスが自動送信 | CloudWatch Logs / カスタムメトリクス |
| セットアップ | 基本的に不要（自動） | ルール作成が必要 |
| コスト | 比較的安価 | ルールごとに課金（やや高め） |
| ユースケース | 全体的な監視、トレンド分析 | 問題の根本原因特定、異常検知 |
| リアルタイム性 | 1分〜5分間隔 | 設定可能（最短1分） |
| ディメンション | 事前定義が必要 | 動的に自動抽出 |
💼 実際のユースケース
セキュリティ侵入検知
🎯 やりたいこと：
APIへの不正アクセスを即座に検知
📊 INSIGHT_RULE_METRICの設定：
「401エラー（認証失敗）を出している IPアドレス Top 20 を追跡」
✨ メリット：
• 不正アクセス元を即座に特定
• 異常なIP（10回/分等）を自動検知
• ランキング急上昇でアラーム発火
• 迅速にIPをブロックリスト追加
APIへの不正アクセスを即座に検知
📊 INSIGHT_RULE_METRICの設定：
「401エラー（認証失敗）を出している IPアドレス Top 20 を追跡」
✨ メリット：
• 不正アクセス元を即座に特定
• 異常なIP（10回/分等）を自動検知
• ランキング急上昇でアラーム発火
• 迅速にIPをブロックリスト追加
APIパフォーマンス分析
🎯 やりたいこと：
どのエンドポイントが重いか特定
📊 INSIGHT_RULE_METRICの設定：
「レスポンスタイムが長い API URL Top 10 を追跡」
✨ メリット：
• ボトルネックのAPI即座に判明
• 「/api/heavy-query」が常に1位
• 最適化の優先順位が明確
• パフォーマンス改善効果を測定
どのエンドポイントが重いか特定
📊 INSIGHT_RULE_METRICの設定：
「レスポンスタイムが長い API URL Top 10 を追跡」
✨ メリット：
• ボトルネックのAPI即座に判明
• 「/api/heavy-query」が常に1位
• 最適化の優先順位が明確
• パフォーマンス改善効果を測定
ユーザー行動分析
🎯 やりたいこと：
どのユーザーが最もアクティブか把握
📊 INSIGHT_RULE_METRICの設定：
「API呼び出しが多い ユーザーID Top 50 を追跡」
✨ メリット：
• パワーユーザーを特定
• 利用パターンの理解
• プレミアムプラン提案のターゲット
• 異常な使用パターン検知
どのユーザーが最もアクティブか把握
📊 INSIGHT_RULE_METRICの設定：
「API呼び出しが多い ユーザーID Top 50 を追跡」
✨ メリット：
• パワーユーザーを特定
• 利用パターンの理解
• プレミアムプラン提案のターゲット
• 異常な使用パターン検知
コスト最適化
🎯 やりたいこと：
どのリソースがコストを食っているか
📊 INSIGHT_RULE_METRICの設定：
「データ転送量が多い S3バケット Top 20 を追跡」
✨ メリット：
• コスト原因の即座の特定
• 不要な転送の削減
• CloudFront導入の判断材料
• 最適化効果の可視化
どのリソースがコストを食っているか
📊 INSIGHT_RULE_METRICの設定：
「データ転送量が多い S3バケット Top 20 を追跡」
✨ メリット：
• コスト原因の即座の特定
• 不要な転送の削減
• CloudFront導入の判断材料
• 最適化効果の可視化
モバイルアプリ分析
🎯 やりたいこと：
どの端末でエラーが多いか把握
📊 INSIGHT_RULE_METRICの設定：
「クラッシュが多い デバイスモデル Top 15 を追跡」
✨ メリット：
• 問題のあるデバイスを即座に特定
• OSバージョン別の不具合把握
• 優先的にサポートすべき端末明確
• アップデート効果の測定
どの端末でエラーが多いか把握
📊 INSIGHT_RULE_METRICの設定：
「クラッシュが多い デバイスモデル Top 15 を追跡」
✨ メリット：
• 問題のあるデバイスを即座に特定
• OSバージョン別の不具合把握
• 優先的にサポートすべき端末明確
• アップデート効果の測定
ECサイト最適化
🎯 やりたいこと：
どの商品ページが重いか把握
📊 INSIGHT_RULE_METRICの設定：
「ページロードが遅い 商品ID Top 30 を追跡」
✨ メリット：
• 売上に影響する遅延ページ特定
• 画像最適化の優先順位決定
• キャッシュ戦略の改善
• コンバージョン率向上
どの商品ページが重いか把握
📊 INSIGHT_RULE_METRICの設定：
「ページロードが遅い 商品ID Top 30 を追跡」
✨ メリット：
• 売上に影響する遅延ページ特定
• 画像最適化の優先順位決定
• キャッシュ戦略の改善
• コンバージョン率向上
✨ INSIGHT_RULE_METRICを使う3大メリット
問題の根本原因を即座に特定
エラーが急増した時、通常のメトリクスでは「エラーが増えた」ことしか分かりません。
INSIGHT_RULE_METRICなら 「どのIPが」「どのユーザーが」 エラーを出しているか自動で教えてくれます！
調査時間が数時間→数分に！
INSIGHT_RULE_METRICなら 「どのIPが」「どのユーザーが」 エラーを出しているか自動で教えてくれます！
調査時間が数時間→数分に！
完全自動化で手間いらず
一度ルールを設定すれば、あとは全自動！
• ログを手動で検索不要
• 集計スクリプト不要
• ダッシュボード自動更新
設定して放置するだけでOK！
• ログを手動で検索不要
• 集計スクリプト不要
• ダッシュボード自動更新
設定して放置するだけでOK！
リアルタイムで異常検知
新しいIPが突然1位に浮上したら即座にアラーム！
• DDoS攻撃の初期検知
• 不正アクセスの即座発見
• パフォーマンス劣化の早期発見
問題が大きくなる前に対処！
• DDoS攻撃の初期検知
• 不正アクセスの即座発見
• パフォーマンス劣化の早期発見
問題が大きくなる前に対処！
📝 Contributor Insightsルールの作成例
# API呼び出しが多いIPアドレス Top 20を追跡 { "Schema": { "Name": "CloudWatchLogRule", "Version": 1 }, "LogGroupNames": [ "/aws/lambda/my-api" ], "LogFormat": "JSON", "Contribution": { "Keys": [ "$.sourceIP" ], "Filters": [ { "Match": "$.httpMethod", "In": ["GET", "POST"] } ] }, "AggregateOn": "Count" } # 👆 このルールで自動的に： # 1. ログからsourceIPを抽出 # 2. 各IPの呼び出し回数をカウント # 3. Top 20をランキング化 # 4. INSIGHT_RULE_METRICとして保存 # 5. CloudWatchダッシュボードで可視化可能に！
💡
導入のベストプラクティス
1. まずは小さく始める：
最初から全てのログに適用しない。まずは最も重要なAPI 1つから始めて効果を確認。
2. Top-Nの数は適切に：
• 大規模システム：Top 50〜100
• 中規模システム：Top 20〜50
• 小規模システム：Top 10〜20
多すぎると見づらく、少なすぎると重要な情報を見逃す可能性。
3. アラーム設定を忘れずに：
ただランキングを見るだけでなく、異常値を検知してアラームを設定しよう！
• 「1位のIPが10,000回/時を超えたらアラーム」
• 「新しいIPが突然Top 5に入ったらアラーム」
4. コストに注意：
INSIGHT_RULE_METRICは通常メトリクスより高コスト。必要なルールだけに絞ろう。
• ルールごとに$0.50/月
• 処理されるログイベント量に応じて追加課金
5. ログフォーマットを統一：
各サービスのログフォーマットが統一されていると、ルール作成が簡単に！
JSON形式での出力を推奨。
6. 定期的なレビュー：
月1回はランキングをレビューして、新しいインサイトを発見しよう！
• 「この常連IPは信頼できるパートナーだから除外しよう」
• 「このユーザーの使い方が参考になるから、UX改善に活かそう」
最初から全てのログに適用しない。まずは最も重要なAPI 1つから始めて効果を確認。
2. Top-Nの数は適切に：
• 大規模システム：Top 50〜100
• 中規模システム：Top 20〜50
• 小規模システム：Top 10〜20
多すぎると見づらく、少なすぎると重要な情報を見逃す可能性。
3. アラーム設定を忘れずに：
ただランキングを見るだけでなく、異常値を検知してアラームを設定しよう！
• 「1位のIPが10,000回/時を超えたらアラーム」
• 「新しいIPが突然Top 5に入ったらアラーム」
4. コストに注意：
INSIGHT_RULE_METRICは通常メトリクスより高コスト。必要なルールだけに絞ろう。
• ルールごとに$0.50/月
• 処理されるログイベント量に応じて追加課金
5. ログフォーマットを統一：
各サービスのログフォーマットが統一されていると、ルール作成が簡単に！
JSON形式での出力を推奨。
6. 定期的なレビュー：
月1回はランキングをレビューして、新しいインサイトを発見しよう！
• 「この常連IPは信頼できるパートナーだから除外しよう」
• 「このユーザーの使い方が参考になるから、UX改善に活かそう」
🎓 まとめ
🍽️ レストランの人気ランキング = INSIGHT_RULE_METRIC
全体の数を数える通常メトリクスに対し、
INSIGHT_RULE_METRICは
「誰が」「何が」最も影響しているか
を
自動的にランキング化して教えてくれる魔法のツール✨
📊
通常のメトリクス
「今日は何人？」
「全部でいくつ？」
を答える
🏆
INSIGHT_RULE_METRIC
「誰が最も？」
「何が最も？」
を自動発見！
🎯 こんな時に使おう：
✅ エラーの原因（どのIPが？）を特定したい
✅ パフォーマンスの重いAPI（どのURLが？）を見つけたい
✅ 不正アクセス（誰が？）を検知したい
✅ コスト原因（どのリソースが？）を突き止めたい
✅ アクティブユーザー（誰が最も使う？）を把握したい
問題解決のスピードが10倍に！
通常メトリクスと組み合わせることで、
「全体の傾向」と「個別の原因」の両方を把握できます🎉
まずは1つのルールから始めてみよう！