Datadog入門第3部 - インフラストラクチャ監視の実践マスターガイド

Datadogの基本設定が完了したら、いよいよインフラストラクチャ監視を始めましょう。この記事では、Infrastructure Monitoring機能の基本的な使い方と、効果的な監視体制の構築方法を分かりやすく説明します。サーバーからクラウド環境まで、まず押さえておきたい監視のポイントを学んでいきます。

3.1 Infrastructure Monitoring

Infrastructure Monitoringの概要と活用シナリオ

Infrastructure Monitoringとは

Infrastructure Monitoringは、Datadogの中核機能で、様々なインフラストラクチャを一元的に監視できる機能です。これまでツールごとに分かれていた監視を、一つのプラットフォームで統合できるのが大きな特徴です。

監視対象となる主要なインフラストラクチャは次のとおりです：

物理サーバー: Linux、Windows、macOSサーバー
仮想化環境: VMware、Hyper-V環境
コンテナ: Docker、Kubernetesクラスター
クラウドサービス: AWS EC2、Azure VM、GCP Compute Engine等

従来監視との主な違い

機能領域	従来監視ツール	Datadog Infrastructure Monitoring
統合性	ツール毎の分離	統一プラットフォーム
可視化	静的グラフ	動的・インタラクティブ
アラート	閾値ベース	機械学習による異常検知
クラウド対応	限定的	ネイティブ統合

ホストマップの活用方法

ホストマップの基本概念

ホストマップ（Host Map）は、インフラストラクチャ全体をヒートマップ形式で可視化する機能です。多数のサーバーの状態を一目で把握できます。

ホストマップでは以下の情報を視覚的に確認できます：

色による状態表示: CPU使用率やメモリ使用率を色で表現
サイズでの重要度: ホストの規模や重要度をサイズで表現
タグによるグループ化: サービスや環境ごとに自動分類
フィルタリング: 条件を指定して表示対象を絞り込み

実践的なホストマップ活用例

ホストマップの実践例

タグを使ってサービスや環境ごとにグループ化できます。たとえば、本番環境のWebサービスのCPU使用率を色で表示し、メモリ総量をサイズで表現するといった設定が可能です。

異常なホストを素早く特定するための一般的なパターン：

高CPU使用率: 80%を超えるホストを赤色で表示
メモリ不足: 使用率が高いホストをオレンジ色で警告
ディスク容量: 90%を超えるホストを紫色で表示

コンテナ監視 (Docker、Kubernetes)

Docker コンテナ監視

Docker環境では、コンテナの動的な生成・削除に対応した監視が必要です。Datadogではこうした動的な環境でも自動でコンテナを発見し、監視を開始します。

Docker環境でのDatadog Agentの基本的な設定例：

yaml

# docker-compose.yml
services:
  datadog-agent:
    image: gcr.io/datadoghq/agent:latest
    environment:
      - DD_API_KEY=${DD_API_KEY}
      - DD_SITE=datadoghq.com
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

Datadogで監視できるDockerメトリクスの主要な項目：

コンテナ数: 稼働中・停止中のコンテナ数
リソース使用率: CPU、メモリの使用状況
I/O性能: ディスク、ネットワークの読み書き量

Kubernetes クラスター監視

Kubernetes環境では、クラスター全体の健全性、個別ポッドの状態、リソースの効率的利用が重要です。

KubernetesでのDatadog Agent設定例（詳細な設定はDatadog公式ドキュメントを参照）：

yaml

# datadog-agent.yaml (要点のみ抽出)
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: datadog-agent
spec:
  template:
    spec:
      containers:
      - name: datadog-agent
        image: gcr.io/datadoghq/agent:latest
        env:
        - name: DD_API_KEY
          value: "your-api-key"
        - name: DD_COLLECT_KUBERNETES_EVENTS
          value: "true"

Kubernetesでの主要な監視ポイント：

クラスター健全性: Nodeの状態、Podの成功率
リソース監視: CPU、メモリのリクエストと実使用量
アプリケーション: Podの再起動回数、コンテナ起動時間

クラウドインテグレーション (AWS、Azure、GCP)

AWS統合の詳細設定

AWSとDatadogを統合することで、AWSサービスのメトリクスをDatadogで一元管理できます。

AWSで監視できる主要サービス：

コンピュート: EC2インスタンス、Lambda関数
データベース: RDS、DynamoDBの性能監視
ストレージ: S3、EBSの使用状況
ネットワーク: ELB、CloudFrontのパフォーマンス

AWS統合には適切なIAM権限設定が必要です。CloudWatchメトリクスの読み取り権限や、EC2インスタンス情報の取得権限などが必要です。


#### Azure統合の実装

Microsoft Azureとの統合では、Azureサービスの監視が可能です。

Azure統合にはサービスプリンシパルの作成が必要です。Azure CLIやAzure Portalから設定できます。

GCP統合の設定

Google Cloud Platformで監視できる主要サービス：

コンピュート: Compute Engine、GKE、Cloud Functions
ストレージ: Cloud Storage、Cloud SQL
ネットワーク: Load Balancing、Cloud CDN

ネットワーク監視の基礎

Network Performance Monitoring (NPM)

Datadog NPM（Network Performance Monitoring）では、アプリケーション間のネットワーク通信を可視化できます。

NPMで監視できる主要な項目：

ネットワークレイテンシ（RTT）
帯域使用率とスループット
パケットロス率
サービス間の依存関係

高レイテンシやパケットロスなどの異常を検知した際は、アラートを設定して自動通知できます。

プロセス監視とサービス発見

Process Monitoring

プロセス監視では、サーバー上で実行されているプロセスの詳細な情報を取得できます。

プロセス監視で確認できる主要な情報：

CPU使用率とメモリ使用量
ファイルディスクリプタ数
スレッド数とコンテキストスイッチ数
システムのロードアベレージ

Service Discovery

Service Discovery機能では、KubernetesやDockerなどの動的な環境でも新しいサービスを自動で発見し、監視対象に追加します。

主な特徴：

コンテナやサービスの自動検出
サービス名、バージョン、エンドポイントの特定
環境やチームなどのタグ自動付与

3.2 メトリクス管理

メトリクスの種類と特徴

Datadogメトリクスの分類体系

Datadogでは、4つの主要メトリクスタイプでシステムの状態を包括的に表現できます。

yaml

# メトリクスタイプの詳細分類
COUNT (カウント):
  説明: "イベントの総発生回数"
  用途: "API呼び出し数、エラー発生回数"
  集約方法: "合計値 (SUM)"
  例: "web.requests.total, error.count"
  
RATE (レート):
  説明: "単位時間あたりの発生頻度"
  用途: "秒間リクエスト数、分間エラー率"
  集約方法: "平均値 (AVG)"
  例: "web.requests.rate, error.rate"
  
GAUGE (ゲージ):
  説明: "特定時点での値"
  用途: "CPU使用率、メモリ使用量"
  集約方法: "最新値または平均値"
  例: "system.cpu.usage, system.memory.used"
  
HISTOGRAM (ヒストグラム):
  説明: "値の分布統計"
  用途: "レスポンス時間分布、サイズ分布"
  集約方法: "パーセンタイル (p50, p90, p99)"
  例: "request.duration, file.size"

メトリクス精度とサンプリング戦略

yaml

# メトリクス精度設定
Resolution Settings:
  High Resolution (1秒):
    - リアルタイム監視が必要
    - 一時的な異常検知
    - コスト: 高
    
  Standard Resolution (10-60秒):
    - 通常の性能監視
    - トレンド分析
    - コスト: 中
    
  Low Resolution (5-15分):
    - 長期トレンド監視
    - レポート作成
    - コスト: 低

Sampling Strategy:
  Critical Metrics: 100% sampling
  Standard Metrics: 10% sampling
  Debug Metrics: 1% sampling

カスタムメトリクスの作成

DogStatsD を使用したメトリクス送信

DogStatsDは、アプリケーションから直接カスタムメトリクスを送信するためのプロトコルです。

PythonでのDogStatsD使用例（詳細は公式ドキュメントを参照）：

python

from datadog import DogStatsdClient

# クライアント初期化
statsd = DogStatsdClient(host='localhost', port=8125)

# メトリクス送信例
statsd.increment('api.requests')  # リクエスト数をカウント
statsd.histogram('api.response_time', 0.150)  # 応答時間
statsd.gauge('users.active', 1250)  # アクティブユーザー数

アプリケーション埋め込みメトリクス

JavaでのDogStatsD使用例：

java

import com.timgroup.statsd.StatsDClient;
import com.timgroup.statsd.NonBlockingStatsDClient;

public class Metrics {
    private final StatsDClient statsd;
    
    public Metrics() {
        this.statsd = new NonBlockingStatsDClient(
            "myapp", "datadog-agent", 8125);
    }
    
    public void recordPurchase(double amount) {
        statsd.histogram("purchase.amount", amount);
        statsd.increment("purchase.count");
    }
}

メトリクス集約とタグ戦略

戦略的タグ設計

効果的なタグ戦略は、メトリクスの価値を最大化し、分析効率を向上させます。

タグの基本的な考え方

Primary Tags: env（環境）、service（サービス名）、version（バージョン）など
Secondary Tags: team（チーム）、datacenter（データセンター）など
Business Tags: customer_tier（顧客ランク）、feature_flag（機能フラグ）など

タグのベストプラクティス

小文字で統一（env:production）
ケバブケースで命名（instance-type:t3-medium）
user_idやsession_idなど高カーディナリティのタグは回避

集約ルールの設計

メトリクス集約には主に2つの方法があります。

空間集約（Space Aggregation） タグによるグループ化で、サービス別やリージョン別の平均値を算出します。

時間集約（Time Aggregation） 指定した時間窓（例：5分間）での統計を計算し、短期変動を平滑化します。

実際のクエリ例：

サービス別エラー率の算出
リージョン別レイテンシの比較
前週同時刻とのトレンド比較

メトリクス保持期間と課金への影響

保持期間ポリシー

Datadogのメトリクス保持期間は、データの価値とコストのバランスを考慮して設計されています。

Datadogのメトリクス保持期間の基本パターン：

高精度（1秒間隔）: 30分間保持、リアルタイム監視用
標準精度（1分間隔）: 15ヶ月保持、一般監視用
低精度（1時間/1日間隔）: 長期トレンド分析用

ビジネス重要度に応じて保持期間をカスタマイズできます。コンプライアンス要件がある場合は24ヶ月、デバッグ用は7日などの設定が可能です。

コスト最適化戦略

コスト最適化の主要なポイント：

メトリクス量の削減

テスト環境や廃止サービスの不要メトリクスを除外
環境ごとのサンプリング率調整（本番100%、ステージング50%など）

タグの最適化

user_id、session_idなど高カーディナリティタグの削除
分析に必要なタグのみ保持
定期的なタグ監査の実施

コストはホスト数、カスタムメトリクス数、データポイント数によって決まります。

メトリクス検索とフィルタリング

高度な検索クエリ

メトリクス検索では、大量のデータから必要な情報を素早く抽出できます。

基本的な検索パターン：

サービス指定: system.cpu.user{service:web-frontend}
複数条件: {env:production AND service:database}
除外条件: {* AND !service:test*}
時間範囲指定: [5m ago:now]

動的フィルタリング

テンプレート変数を使うことで、ダッシュボードを動的にフィルタリングできます。

主要なテンプレート変数：

$service: サービス名でフィルタリング
$env: 環境（production、stagingなど）で絞り込み
$region: リージョン別の表示

これらを組み合わせたクエリ例: avg:system.cpu.user{service:$service,env:$env}

3.3 ダッシュボード作成

ダッシュボードの設計原則

効果的ダッシュボード設計の法則

優れたダッシュボードは、情報の階層化と視覚的な明確さにより、迅速な意思決定を支援します。

yaml

# ダッシュボード設計の5つの原則
Design Principles:
  1. Purpose-Driven (目的主導):
    - 明確な対象ユーザー定義
    - 特定の問題解決にフォーカス
    - アクション可能な情報提供
  
  2. Information Hierarchy (情報階層):
    - 最重要情報を上部配置
    - 詳細情報は下部に配置
    - 関連情報をグループ化
  
  3. Visual Clarity (視覚的明確さ):
    - 適切な色使い
    - 読みやすいフォント
    - 十分な余白確保
  
  4. Responsive Design (レスポンシブ設計):
    - モバイル対応
    - 画面サイズ適応
    - 情報密度の最適化
  
  5. Actionable Insights (アクション可能な洞察):
    - 閾値の明確化
    - トレンド表示
    - 比較情報提供

ダッシュボードタイプ別設計指針

yaml

# 用途別ダッシュボード設計
Dashboard Types:
  Executive Dashboard (経営層向け):
    更新頻度: "日次/週次"
    表示期間: "30日/90日"
    重要指標:
      - 全体サービス可用性
      - ビジネスKPI
      - 重大インシデント数
      - コスト効率
    
    視覚化:
      - 大きな数値表示
      - 傾向を示すシンプルなグラフ
      - ステータスインジケーター
      - 前期比較

  Operations Dashboard (運用チーム向け):
    更新頻度: "リアルタイム"
    表示期間: "1時間/24時間"
    重要指標:
      - システム健全性
      - アラート状況
      - リソース使用率
      - サービス依存関係
    
    視覚化:
      - ヒートマップ
      - 時系列グラフ
      - トポロジマップ
      - アラートリスト

  Development Dashboard (開発チーム向け):
    更新頻度: "リアルタイム/分次"
    表示期間: "1時間/7日"
    重要指標:
      - アプリケーション性能
      - エラー率
      - デプロイメント状況
      - 機能使用状況
    
    視覚化:
      - 詳細時系列グラフ
      - エラー詳細テーブル
      - パフォーマンス分布
      - A/Bテスト結果

ウィジェットの種類と使い分け

主要ウィジェット詳細ガイド

Datadogでは、20種類以上の専用ウィジェットで多様なデータ可視化ニーズに対応できます。

yaml

# 数値表示ウィジェット
Value Widgets:
  Query Value:
    用途: "単一メトリクスの現在値表示"
    最適ケース: "アクティブユーザー数、エラー率"
    設定: "大きなフォント、色による閾値表示"
    
  Table:
    用途: "複数メトリクスの詳細比較"
    最適ケース: "サービス別性能比較、エラー詳細"
    設定: "ソート可能、条件付きフォーマット"
    
  List:
    用途: "上位/下位N項目の表示"
    最適ケース: "最も使用率の高いホスト"
    設定: "自動ソート、制限数設定"

# グラフ表示ウィジェット
Graph Widgets:
  Timeseries:
    用途: "時間経過による変化表示"
    最適ケース: "CPU使用率、応答時間トレンド"
    設定: "複数メトリクス重ね合わせ、Y軸スケール"
    
  Heatmap:
    用途: "2次元データの密度表示"
    最適ケース: "応答時間分布、アクセスパターン"
    設定: "色スケール、時間粒度"
    
  Distribution:
    用途: "値の分布状況表示"
    最適ケース: "レイテンシ分布、ファイルサイズ分布"
    設定: "パーセンタイル表示、区間設定"

実践的ウィジェット設定例

yaml

# SREダッシュボード向けウィジェット構成
SRE Dashboard Widgets:
  Service Level Indicators:
    Widget: "Query Value"
    メトリクス: "sum:request.success{*} / sum:request.total{*} * 100"
    表示: "99.95%"
    閾値:
      - Green: "> 99.9%"
      - Yellow: "99.0% - 99.9%"
      - Red: "< 99.0%"
    
  Error Rate Trend:
    Widget: "Timeseries"
    メトリクス: 
      - "rate(error.count{*})"
      - "rate(request.count{*})"
    表示期間: "24時間"
    Y軸: "ログスケール"
    
  Response Time Distribution:
    Widget: "Heatmap"
    メトリクス: "request.duration{*}"
    集約: "パーセンタイル(p50, p90, p99)"
    時間粒度: "5分"
    
  Top Errors:
    Widget: "Table"
    メトリクス: "sum:error.count{*} by {error_type}"
    ソート: "降順"
    表示数: "上位10件"
    リンク: "ログ詳細画面へ"

テンプレート変数の活用

動的ダッシュボードの実装

テンプレート変数により、一つのダッシュボードで複数の視点からの分析が可能になります。

yaml

# 包括的テンプレート変数設定
Template Variables Configuration:
  環境選択:
    Variable Name: "$env"
    Type: "Tag Values"
    Tag Key: "env"
    Default Value: "production"
    Multi-select: false
    Include All: false
    
  サービス選択:
    Variable Name: "$service"
    Type: "Tag Values"
    Tag Key: "service"
    Query Filter: "env:$env"
    Default Value: "*"
    Multi-select: true
    Include All: true
    
  時間範囲:
    Variable Name: "$timeframe"
    Type: "Custom"
    Options:
      - "1h": "過去1時間"
      - "24h": "過去24時間"
      - "7d": "過去7日"
      - "30d": "過去30日"
    Default Value: "24h"
    
  リージョン:
    Variable Name: "$region"
    Type: "Tag Values"
    Tag Key: "region"
    Query Filter: "env:$env AND service:$service"
    Default Value: "*"
    Multi-select: true
    Include All: true

高度なテンプレート変数活用

bash

# 連動するテンプレート変数の実装
# メインクエリでのテンプレート変数使用
avg:system.cpu.user{env:$env,service:$service,region:$region}

# 条件付きフィルタリング
avg:request.duration{env:$env,$service,$region} by {endpoint}

# 動的タイトル生成
Title: "CPU使用率 - $env環境 $serviceサービス"

# 複数値対応
avg:memory.usage{service:$service.in($service_list)}

チーム共有とアクセス制御

組織レベルでのダッシュボード管理

エンタープライズ環境では、適切なアクセス制御と共有戦略が重要になります。

yaml

# アクセス制御階層
Access Control Hierarchy:
  Organization Level:
    - 管理者: 全ダッシュボード管理権限
    - メンバー: 閲覧および作成権限
    - 読み取り専用: 閲覧のみ
    
  Team Level:
    - チームオーナー: チーム内ダッシュボード管理
    - チームメンバー: チーム内ダッシュボード編集
    - 外部コラボレーター: 特定ダッシュボード閲覧
    
  Dashboard Level:
    - 作成者: 完全な編集権限
    - 編集者: 内容編集権限
    - 閲覧者: 表示のみ権限

# 実践的共有設定
Sharing Configuration:
  社内共有:
    Public Link: "認証なしアクセス"
    Organization内: "組織メンバーのみ"
    Team限定: "特定チームのみ"
    
  外部共有:
    読み取り専用リンク: "時間制限付き"
    PDFエクスポート: "定期自動送信"
    Slack統合: "アラート時自動投稿"

モバイル対応ダッシュボード

レスポンシブ設計の実装

モバイルデバイス対応により、場所を選ばない監視体制を構築できるようになります。

yaml

# モバイル最適化設計
Mobile Optimization:
  レイアウト調整:
    - 縦並び配置優先
    - タッチ操作対応
    - 拡大縮小可能
    
  情報密度:
    - 重要指標に絞り込み
    - 大きなフォント使用
    - 簡潔なラベル
    
  操作性:
    - スワイプナビゲーション
    - 簡易フィルタリング
    - クイックアクション

# モバイル専用ダッシュボード例
Mobile Dashboard Structure:
  Header Section:
    - サービス状態概要
    - 重要アラート数
    - 現在時刻とタイムゾーン
    
  Key Metrics Section:
    - 可用性 (大きな%表示)
    - エラー率 (色付きインジケーター)
    - 応答時間 (トレンド付き)
    
  Quick Actions Section:
    - インシデント作成
    - オンコール確認
    - 詳細ダッシュボードリンク

# Datadog Mobileアプリ活用
Mobile App Features:
  プッシュ通知:
    - 重要アラート即座通知
    - インシデント更新通知
    - SLA違反警告
    
  オフライン機能:
    - 最新データキャッシュ
    - 基本操作継続可能
    - 同期自動復旧
    
  統合機能:
    - PagerDuty連携
    - Slack通知
    - カレンダー統合

まとめ

この記事では、DatadogのInfrastructure Monitoring機能、メトリクス管理、ダッシュボード作成の基本的な活用方法を紹介しました。

主要ポイントの再確認

yaml

Infrastructure Monitoring:
  ✅ ホストマップによる全体俯瞰
  ✅ コンテナ・K8s環境の深い監視
  ✅ マルチクラウド統合監視
  ✅ ネットワーク・プロセス監視

メトリクス管理:
  ✅ 4つのメトリクスタイプ活用
  ✅ カスタムメトリクス戦略的設計
  ✅ タグベース効率的分析
  ✅ コスト最適化手法

ダッシュボード作成:
  ✅ 目的別設計原則
  ✅ 20種類以上ウィジェット活用
  ✅ テンプレート変数による動的化
  ✅ モバイル対応レスポンシブ設計

次のステップ

Infrastructure Monitoringの基本ができたら、次はAPM（Application Performance Monitoring）やRUM（Real User Monitoring）といったアプリケーションレベルの監視に進んでいくと、より包括的な監視体制が構築できます。

Datadogの機能を段階的に活用しながら、組織の監視体制を充実させていきましょう。

Datadog入門 第3部 - インフラストラクチャ監視の実践マスターガイド ​

3.1 Infrastructure Monitoring ​

Infrastructure Monitoringの概要と活用シナリオ ​

Infrastructure Monitoringとは ​

従来監視との主な違い ​

ホストマップの活用方法 ​

ホストマップの基本概念 ​

実践的なホストマップ活用例 ​

コンテナ監視 (Docker、Kubernetes) ​

Docker コンテナ監視 ​

Kubernetes クラスター監視 ​

クラウドインテグレーション (AWS、Azure、GCP) ​

AWS統合の詳細設定 ​

GCP統合の設定 ​

ネットワーク監視の基礎 ​

Network Performance Monitoring (NPM) ​

プロセス監視とサービス発見 ​

Process Monitoring ​

Service Discovery ​

3.2 メトリクス管理 ​

メトリクスの種類と特徴 ​

Datadogメトリクスの分類体系 ​

メトリクス精度とサンプリング戦略 ​

カスタムメトリクスの作成 ​

DogStatsD を使用したメトリクス送信 ​

アプリケーション埋め込みメトリクス ​

メトリクス集約とタグ戦略 ​

戦略的タグ設計 ​

集約ルールの設計 ​

メトリクス保持期間と課金への影響 ​

保持期間ポリシー ​

コスト最適化戦略 ​

メトリクス検索とフィルタリング ​

高度な検索クエリ ​

動的フィルタリング ​

3.3 ダッシュボード作成 ​

ダッシュボードの設計原則 ​

効果的ダッシュボード設計の法則 ​

ダッシュボードタイプ別設計指針 ​

ウィジェットの種類と使い分け ​

主要ウィジェット詳細ガイド ​

実践的ウィジェット設定例 ​

テンプレート変数の活用 ​

動的ダッシュボードの実装 ​

高度なテンプレート変数活用 ​

チーム共有とアクセス制御 ​

組織レベルでのダッシュボード管理 ​

モバイル対応ダッシュボード ​

レスポンシブ設計の実装 ​

まとめ ​

主要ポイントの再確認 ​

次のステップ ​

Datadog入門第3部 - インフラストラクチャ監視の実践マスターガイド

3.1 Infrastructure Monitoring

Infrastructure Monitoringの概要と活用シナリオ

Infrastructure Monitoringとは

従来監視との主な違い

ホストマップの活用方法

ホストマップの基本概念

実践的なホストマップ活用例

コンテナ監視 (Docker、Kubernetes)

Docker コンテナ監視

Kubernetes クラスター監視

クラウドインテグレーション (AWS、Azure、GCP)

AWS統合の詳細設定

GCP統合の設定

ネットワーク監視の基礎

Network Performance Monitoring (NPM)

プロセス監視とサービス発見

Process Monitoring

Service Discovery

3.2 メトリクス管理

メトリクスの種類と特徴

Datadogメトリクスの分類体系

メトリクス精度とサンプリング戦略

カスタムメトリクスの作成

DogStatsD を使用したメトリクス送信

アプリケーション埋め込みメトリクス

メトリクス集約とタグ戦略

戦略的タグ設計

集約ルールの設計

メトリクス保持期間と課金への影響

保持期間ポリシー

コスト最適化戦略

メトリクス検索とフィルタリング

高度な検索クエリ

動的フィルタリング

3.3 ダッシュボード作成

ダッシュボードの設計原則

効果的ダッシュボード設計の法則

ダッシュボードタイプ別設計指針

ウィジェットの種類と使い分け

主要ウィジェット詳細ガイド

実践的ウィジェット設定例

テンプレート変数の活用

動的ダッシュボードの実装

高度なテンプレート変数活用

チーム共有とアクセス制御

組織レベルでのダッシュボード管理

モバイル対応ダッシュボード

レスポンシブ設計の実装

まとめ

主要ポイントの再確認

次のステップ