Application Insights 可用性テスト

Application Insights を使うと、世界中のさまざまな場所から Web サイトまたはアプリケーションの可用性と応答性を監視する定期的な Web テストを設定できます。 これらの可用性テストは、一定の間隔で Web 要求をアプリケーションに送信し、アプリケーションが応答していない場合や応答時間が遅すぎる場合はユーザーに警告します。

可用性テストのために、テスト対象の Web サイトまたはアプリケーションを変更する必要はありません。 パブリック インターネットからアクセスできる任意の HTTP または HTTPS エンドポイント (サービスが依存する REST API を含む) に対して機能します。 つまり、独自のアプリケーションだけでなく、アプリケーションの機能に不可欠な外部サービスも監視できます。 Application Insights リソースごとに最大 100 個の可用性テストを作成できます。

可用性テストの種類

可用性テストには、次の 4 種類があります。

• 標準テスト: 非推奨の URL ping テストと同様に、1 つの要求を送信して Web サイトの可用性をチェックする可用性テストの種類。 標準テストには、エンドポイントが応答し、パフォーマンスを測定しているかどうかの検証に加え、TLS/SSL 証明書の有効性、プロアクティブな有効期間チェック、HTTP 要求動詞 (GET、HEAD、POST など)、カスタム ヘッダー、HTTP 要求に関連付けられたカスタム データなども含まれます。

  標準テストを作成する方法を学習する。

• カスタム TrackAvailability テスト: 可用性テストを実行するカスタム アプリケーションを作成することにした場合、TrackAvailability() メソッドを使用して、結果を Application Insights に送信できます。

  カスタム TrackAvailability テストを作成する方法を学習する。

• (非推奨) 複数ステップの Web テスト: この一連の Web 要求の記録を再生して、より複雑なシナリオをテストできます。 複数ステップ Web テストは Visual Studio Enterprise で作成され、ポータルにアップロードされ、ここでそれらを実行できます。

• (非推奨) URL ping テスト: Azure portal を使用してこのテストを作成して、エンドポイントが応答しているかどうかを検証し、その応答に関連するパフォーマンスを測定できます。 また、依存する要求の解析などの高度な機能と結合されたカスタム成功基準を設定し、再試行が可能になります。

可用性テストを作成する

可用性のアラート

アラートは既定で自動的に有効になりますが、アラートを完全に構成するには、最初に可用性テストを作成する必要があります。

位置情報の作成タグ

Azure Resource Manager を使って標準テストまたは URL ping テストをデプロイするときに、次の作成タグを地理的位置属性に使用できます。

アラートを有効にする

1. 可用性テストを保存した後、作成したテストのコンテキスト メニューを開いて、[規則 (アラート) ページを開く] を選びます。

   

2. [アラート ルール] ページでアラートを開き、上部のナビゲーション バーで [編集] を選びます。 ここでは、重大度レベル、ルールの説明、このアラート ルールに使用する通知の基本設定が含まれるアクション グループを設定できます。

   

アラートの条件

自動的に有効になる可用性アラートでは、エンドポイントが使用できなくなると 1 つのメールがトリガーされ、再び使用可能になると別のメールがトリガーされます。 このエクスペリエンスで作成される可用性アラートは、"状態に基づきます"。 アラートの条件が満たされると、Web サイトが使用不可として検出された場合に 1 つのアラートが生成されます。 次にアラートの条件が評価されたときに Web サイトがまだダウンしている場合、新しいアラートは生成されません。

たとえば、Web サイトが 1 時間ダウンし、評価頻度が 15 分のメール アラートを設定してあるとします。 Web サイトがダウンしたときのメールと、その Web サイトがオンラインに戻ったときの別のメールのみを受け取ります。 Web サイトがまだ使用できないことを通知するアラートを 15 分ごとに継続的に受け取ることはありません。

アラートの条件を変更する

メンテナンス中など、Web サイトが短時間だけダウンした場合には通知を受け取りたくない場合があります。 評価頻度を、予想されるダウンタイムよりも長い値 (最大 15 分) に変更できます。 また、アラートの場所のしきい値を大きくすることもできます。そうすると、Web サイトが特定の数のリージョンでダウンしている場合にのみアラートがトリガーされます。

場所のしきい値、集計期間、テストの頻度を変更するには、[アラート ルールの編集] ページ (「アラートを有効にする」のステップ 2 を参照) に移動し、条件を選んで [シグナル ロジックの構成] ウィンドウを開きます。

カスタム アラート ルールを作成する

高度な機能が必要な場合は、[アラート] タブでカスタムのアラート ルールを作成できます。[アラート ルールの作成(>A)] を選択します。 使用可能なシグナルをすべて表示するには、[シグナルの種類] で [メトリック] を選択し、[可用性] を選択します。

カスタムのアラート ルールでは、より大きい値を使用できます。集計期間については 6 時間ではなく最大 24 時間、テストの頻度については 15 分ではなく最大 1 時間です。 さまざまな演算子、集計の種類、しきい値を選択することで、ロジックを詳細に定義するためのオプションも追加されます。

• Y 箇所中 X 箇所で障害が報告された場合にアラートを生成する: 新しい可用性テストを作成するとき、新しい統合アラート エクスペリエンスでは Y 箇所中 X 箇所のアラート ルールが既定で有効になります。 オプトアウトするには、"クラシック" オプションを選択するか、またはアラート ルールを無効にすることを選択します。 前述の手順に従って、アラートがトリガーされたときに通知を受信するようにアクション グループを構成します。 このステップを行わないと、ルールがトリガーされたときにポータル内通知のみを受け取ります。

• 可用性メトリックに関するアラート: 新しい統合アラートを使用すると、セグメント化された可用性の集計メトリックおよびテスト継続期間メトリックに関してもアラートを生成できます。

  1. [メトリック] エクスペリエンス内で Application Insights リソースを選択し、[可用性] メトリックを選択します。

  2. メニューから [アラートを構成する] オプションを選択すると、新しいエクスペリエンスが表示され、アラート ルールの設定対象とする特定のテストまたは場所を選択できます。 ここでは、このアラート ルールに対してアクション グループを構成することもできます。

• カスタム分析クエリに関するアラート: 新しい統合アラートを使用すると、カスタム ログ クエリに関するアラートを生成できます。 カスタム クエリを使用すると、可用性の問題を示す最も確かなシグナルを取得するのに役立つ任意の条件に基づいてアラートを生成することができます。 また、これは TrackAvailability SDK を使用してカスタムの可用性の結果を送信する場合にも当てはまります。

  可用性データに関するメトリックにはカスタムの可用性の結果が含まれます。これは、TrackAvailability SDK を呼び出すことによって送信できます。 メトリックに関するアラートのサポートを使用することにより、カスタムの可用性の結果に関するアラートを生成することができます。

アラートを自動化する

Azure Resource Manager テンプレートを使用してこのプロセスを自動化する方法については、Azure Resource Manager テンプレートを使用したメトリック アラートの作成に関するページを参照してください。

可用性テストの結果を表示する

このセクションでは、Azure portal で可用性テストの結果を確認し、Log Analytics を使用してデータにクエリを実行する方法について説明します。 可用性テストの結果は、折れ線グラフと散布図の両方で視覚化できます。

可用性を確認する

最初に、Azure portal の [可用性] エクスペリエンスでグラフを確認します。

既定では、[可用性] エクスペリエンスには折れ線グラフが表示されます。 診断テストのステップの詳細が含まれるテスト結果のサンプルを表示するには、ビューを [散布図] (グラフの上の切り替え) に変更します。 テスト エンジンは、失敗したテストの診断の詳細を格納します。 成功したテストの場合、診断の詳細は実行のサブセットに対して格納されます。 テスト、テスト名、場所を表示するには、緑色の点または赤い十字をマウスでポイントします。

特定のテストまたは場所を選択します。 または期間を短くして、目的の期間に関するより詳細な結果を表示できます。 検索エクスプローラーを使用して、すべての実行の結果を表示します。 または Log Analytics クエリを使用して、このデータに対してカスタム レポートを実行できます。

エンドツーエンドのトランザクションの詳細を表示するには、[詳細の表示] で [成功] または [失敗] を選択します。 次に、サンプルを選択します。 グラフでデータ ポイントを選択することにより、エンドツーエンドのトランザクションの詳細も取得できます。

テストを調べて編集する

テストの編集、一時的な無効化、または削除を行うには、テストのコンテキスト メニュー (省略記号) を開いて、[編集] を選びます。 変更を行った後、すべてのテスト エージェントに構成の変更が反映されるまで、最大 20 分かかる場合があります。

エラーが発生した場合

散布図上の赤い十字を選んで、[エンド ツー エンド トランザクションの詳細] ビューを開きます。

ここで、次のことを行うことができます。

• [トラブルシューティング レポート] を調べて、テストが失敗する原因になっている可能性があるものを明らかにします。
• サーバーから受信した応答を調べる。
• 失敗した可用性テストの処理中に収集された、サーバー側の相関関係を持つテレメトリを使用してエラーを診断する。
• Git または Azure Boards でイシューまたは作業項目をログして、問題を追跡します。 このバグには、Azure portal のイベントへのリンクが含まれます。
• Visual Studio で Web テスト結果を開く。

エンドツーエンドのトランザクションの診断エクスペリエンスの詳細については、トランザクション診断のドキュメントを参照してください。

例外の行を選択すると、代理可用性テストが失敗した原因であるサーバー側の例外の詳細が表示されます。 コード レベルの豊富な診断のデバッグ スナップショットを取得することもできます。

生の結果に加えて、メトリックス エクスプローラーに 2 つの重要な可用性メトリックを表示することもできます。

• 可用性: すべてのテスト実行にわたる、成功したテストの割合 (%)。
• テスト期間: すべてのテスト実行にわたる平均のテスト期間。

Log Analytics のサンプル クエリ

Log Analytics を使って、可用性の結果 (availabilityResults)、依存関係 (dependencies)、その他を見ることができます。 Log Analytics の詳細については、ログ クエリの概要に関するページを参照してください。

従来の URL ping テストを標準テストに移行する

次の手順では、URL ping テストの機能をレプリケートする標準テストの作成プロセスについて説明します。 これにより、以前作成した URL ping テストを使用して、標準テストの高度な機能をより簡単に利用し始めることができます。

必須コンポーネント

作業の開始

1. Azure PowerShell (Connect-AzAccount + Set-AzContext) を使って、サブスクリプションに接続します。

2. 現在のサブスクリプションのすべての URL ping テストを一覧表示してください。

   Get-AzApplicationInsightsWebTest | `
   Where-Object { $_.WebTestKind -eq "ping" } | `
   Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
   

3. 移行したい URL ping テストを見つけて、そのリソース グループと名前を記録します。

4. 次のコマンドを使って、URL ping テストと同じロジックで標準テストを作成します。これは、HTTP と HTTPS 両方のエンドポイントで機能します。

   $resourceGroup = "pingTestResourceGroup";
   $appInsightsComponent = "componentName";
   $pingTestName = "pingTestName";
   $newStandardTestName = "newStandardTestName";
   
   $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
   $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
   $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
   
   $dynamicParameters = @{};
   
   if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
   $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
   }
   
   if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
   $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
   $dynamicParameters["ContentPassIfTextFound"] = $true;
   }
   
   New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
   -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
   -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
   -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
   -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);
   

   新しい標準テストには既定でアラート ルールがないため、わずらわしいアラートは作成されません。 URL ping テストは変更されないため、これについては引き続きアラートを利用できます。

5. 新しい標準テストの機能を検証してから、URL ping テストを参照するアラート ルールを更新して、代わりに標準テストを参照するようにします。

6. URL ping テストを無効化または削除します。 Azure PowerShell でこれを行うには、次のコマンドを使用できます。

   Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   

ファイアウォールの内側でのテスト

ファイアウォールの内側でエンドポイントの可用性を確保するには、パブリック可用性テストを有効にするか、切断された、またはイングレスのシナリオで可用性テストを実行します。

パブリック可用性テストの有効化

内部 Web サイトにパブリック ドメイン ネーム システム (DNS) レコードがあることを確認します。 DNS を解決できない場合、可用性テストは失敗します。 詳細については、内部アプリケーションのカスタム ドメイン名の作成に関するページを参照してください。

トラフィックを認証する

トラフィックを検証するために、標準テストにカスタム ヘッダーを設定します。

1. この可用性テストを識別するために、スペースを含まない英数字文字列を作成します (例: MyAppAvailabilityTest)。 これ以降、この文字列を "可用性テスト文字列識別子" と呼びます。

2. 可用性テストを作成または更新するときに、[標準テストの情報] セクションで、カスタム ヘッダー X-Customer-InstanceId と値 ApplicationInsightsAvailability:<your availability test string identifier> を追加します。

   

3. これまでの手順で定義したヘッダーと値が受信トラフィックに含まれていることをサービスで必ず確認します。

または、クエリ パラメーターとして "可用性テスト文字列識別子" を設定します。

例: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

可用性テストからの受信要求を許可するようにファイアウォールを構成する

個々の IP を承認したり、最新の IP リストを維持したりせずに Azure サービスを簡単に有効にするには、サービス タグを使用します。 これらのタグを Azure Firewall とネットワーク セキュリティ グループの全体に適用して、可用性テスト サービスがエンドポイントにアクセスできるようにします。 サービス タグ ApplicationInsightsAvailability は、すべての可用性テストに適用されます。

1. Azure ネットワーク セキュリティ グループを使っている場合は、ネットワーク セキュリティ グループ リソースに移動し、[設定] で [受信セキュリティ規則] エクスペリエンスを開いてから、[追加] を選びます。

2. 次に、[ソース] として [サービス タグ] を選び、[ソース サービス タグ] として ApplicationInsightsAvailability を選びます。 サービス タグからの着信トラフィック用にオープン ポート 80 (http) と 443 (https) を使用します。

エンドポイントが Azure の外部にある場合、またはサービス タグがオプションではない場合にアクセスを管理するには、Web テスト エージェントの IP アドレスを許可リストに登録します。 PowerShell、Azure CLI、または Service Tag API を使用した REST 呼び出しを使用して、IP 範囲のクエリを実行できます。 現在のサービス タグとその IP の詳細の包括的な一覧については、JSON ファイルをダウンロードしてください。

1. ネットワーク セキュリティ グループ リソースの [設定] で [受信セキュリティ規則] エクスペリエンスを開き、[追加] を選びます。

2. 次に、[ソース] として [IP アドレス] を選びます。 次に、[ソース IP アドレス/CIDR 範囲] のコンマ区切りの一覧に IP アドレスを追加します。

切断またはイングレスなしシナリオ

1. Azure Private Link を使用して、Application Insights リソースを内部サービス エンドポイントに接続します。

2. 内部サーバーまたはエンドポイントを定期的にテストするカスタム コードを作成します。 コア SDK パッケージ内の TrackAvailability() API を使用して、結果を Application Insights に送信します。

サポートされる TLS 構成

クラス最高の暗号化を提供するために、すべての可用性テストでは、選択した暗号化メカニズムとしてトランスポート層セキュリティ (TLS) 1.2 および 1.3 が使用されます。 さらに、各バージョンでは、以下の暗号スイートと楕円曲線もサポートされます。

TLS 1.3 は現在、可用性テスト リージョン NorthCentralUS、CentralUS、EastUS、SouthCentralUS、WestUS でのみ使用できます。

TLS 構成の非推奨化

TLS 1.0 と TLS 1.1

TLS 1.0 と TLS 1.1 は廃止されます。

TLS 1.2 と TLS 1.3

トラブルシューティング

ダウンタイムと停止のブック

このセクションでは、複数の Application Insights リソースと Azure サブスクリプションを対象とする 1 つのペインで、Web テストのサービス レベル アグリーメント (SLA) を簡単に計算してレポートする方法を説明します。 ダウンタイムと停止レポートには、顧客の接続、一般的なアプリケーションの応答時間、および発生したダウンタイムについて理解を深められるように、強力な構築済みのクエリとデータ視覚化が用意されています。

SLA ブック テンプレートには、次の 2 つの方法で Application Insights リソースからアクセスできます。

• [可用性] エクスペリエンスを開き、上部のナビゲーション バーで [SLA レポート] を選びます。

• [Workbooks] エクスペリエンスを開いて、[ダウンタイムと停止] テンプレートを選びます。

パラメーターの柔軟性

ブックに設定されているパラメーターは、レポートの残りの部分に影響します。

• Subscriptions、App Insights Resources、Web Test: これらのパラメーターによって、大まかなリソースのオプションが決まります。 これらは Log Analytics クエリに基づいており、すべてのレポート クエリで使われます。
• Failure Threshold と Outage Window: これらのパラメーターを使って、サービス停止の独自の条件を決定できます。 たとえば、選択した期間にエラーが発生した場所のカウンターに基づいた、Application Insights の可用性アラートの条件です。 一般的なしきい値は、5 分間に 3 つの場所となります。
• Maintenance Period: このパラメーターを使って、通常のメンテナンス頻度を選択できます。 Maintenance Window は、メンテナンス期間例の日時セレクターです。 指定した期間に発生したすべてのデータは、結果では無視されます。
• Availability Target %: このパラメーターを使ってターゲット目標を指定し、カスタム値を受け取ります。

[概要] ページ

概要ページには、お客様の以下に関する概要情報が含まれています。

• SLA の合計 (定義されている場合はメンテナンス期間を除く)
• エンドツーエンドの停止インスタンス
• アプリケーション ダウンタイム

停止パラメーターに従い、テストが失敗し始めた時点から正常に再び合格するまでの間で停止インスタンスが決定されます。 テストが午前 8:00 に失敗するようになり、午前 10:00 に再び成功した場合は、データのその期間全体が同じ停止と見なされます。 また、報告期間中に発生した最長の停止を調査することもできます。

一部のテストは、さらに調査するために Application Insights リソースにリンクすることができます。 ただし、これを利用できるのはワークスペースベースの Application Insights リソースのみです。

ダウンタイム、障害、および失敗

[概要] ページの横には、さらに 2 つのタブがあります。

• [停止とダウンタイム] タブには、停止インスタンスの合計と、テスト別に分類されたダウンタイムの合計に関する情報があります。

• [Failures by Location] (場所別の失敗) タブには、問題がある可能性のある接続領域を特定するのに役立つ、テストに失敗した場所の geo マップがあります。

その他の機能

• カスタマイズ: 他の Azure Monitor ブックと同様にレポートを編集でき、チームのニーズに基づいてクエリや視覚化をカスタマイズできます。

• Log Analytics: すべてのクエリを Log Analytics で実行して、他のレポートまたはダッシュボードで使用できます。 パラメーターの制限を解除して、コア クエリを再利用してください。

• アクセスと共有: レポートは、チームやリーダーと共有したり、ダッシュボードにピン留めしてさらに使用したりできます。 ユーザーには、実際のブックが格納されている Application Insights リソースに対する読み取りアクセス許可とアクセス権が必要です。

よく寄せられる質問

このセクションでは、一般的な質問への回答を示します。

全般

イントラネット サーバー上で可用性テストを実行することはできますか?

可用性テストは、世界中に分布するプレゼンスのポイントで実行されます。 以下に示す 2 つのソリューションがあります。

• ファイアウォール ドア: 頻繁に変更される多数の Web テスト エージェントからサーバーへの要求を許可します。
• カスタム コード: イントラネット内部からサーバーに定期的な要求を送信する独自のコードを記述します。 Visual Studio Web テストを実行して、このコードをテストすることができます。 テストの結果は TrackAvailability() API を使用して Application Insights に送信できます。

可用性テストのユーザー エージェント文字列は何ですか?

ユーザー エージェント文字列は、Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights) です

TLS サポート

この非推奨化はどのように Web テストの動作に影響しますか?

可用性テストは、サポートされている Web テストの場所それぞれにおける分散クライアントとして機能します。 Web テストが実行されるたびに、可用性テスト サービスは、Web テスト構成内で定義されているリモート エンドポイントへのアクセスを試みます。 現在サポートされている TLS 構成すべてを含む TLS クライアント Hello メッセージが送信されます。 リモート エンドポイントが可用性テスト クライアントと共通の TLS 構成を共有している場合、TLS ハンドシェイクが成功します。 それ以外の場合、Web テストは TLS ハンドシェイクの失敗によって失敗します。

Web テストが影響を受けないようにするにはどうすればよいですか?

影響を回避するために、Web テストがやり取りを行う各リモート エンドポイント (依存要求を含む) は、可用性テストがサポートするのと同じプロトコル バージョン、暗号スイート、楕円曲線の内の少なくとも 1 つの組み合わせをサポートする必要があります。 リモート エンドポイントが必要な TLS 構成をサポートしていない場合は、上記の非推奨化後の TLS 構成のいずれかの組み合わせをサポートするように更新する必要があります。 これらのエンドポイントは、(できれば成功した Web テスト実行の) Web テストのトランザクションの詳細を表示することで検出できます。

リモート エンドポイントでどの TLS 構成がサポートされているかを検証するにはどうすればよいですか?

エンドポイントがどの TLS 構成をサポートしているかをテストするために利用できるツールがいくつか存在します。 1 つの方法は、こちらのページで詳しく説明されている例に従うことです。 リモート エンドポイントがパブリック インターネット経由で利用できない場合は、エンドポイントを呼び出すアクセス権を持つマシンから、リモート エンドポイントでサポートされている TLS 構成を検証するようにする必要があります。

2025 年 5 月 1 日以降、影響を受けるテストの Web テストの動作はどうなりますか?

この非推奨化の影響を受けるすべての TLS ハンドシェイクの失敗で発生する決まった例外型は存在しません。 しかし、Web テストの失敗で発生することになる最も一般的な例外は The request was aborted: Couldn't create SSL/TLS secure channel となるでしょう。 また、影響を受ける可能性がある Web テスト結果に関する TLS 転送のトラブルシューティング手順でも、TLS 関連のエラーを確認できるはずです。

自分の Web テストで現在どの TLS 構成が使用されているかを表示できますか?

Web テストの実行中にネゴシエートされた TLS 構成を表示することはできません。 リモート エンドポイントが可用性テストで一般的な TLS 構成をサポートしている限り、非推奨化後にどのような影響も発生しないはずです。

非推奨化が影響を与える可用性テスト サービス内のコンポーネントはどれですか?

このドキュメントで詳しく説明されている TLS の非推奨化は、2025 年 5 月 1 日以降の可用性テストの Web テスト実行動作にのみ影響します。 CRUD 操作に関する可用性テスト サービスとのやり取りの詳細については、「Azure Resource Manager TLS サポート」を参照してください。 このリソースは、TLS のサポートと非推奨化のタイムラインの詳細について説明しています。

TLS に関するサポートはどこで受けることができますか?

従来の TLS の問題に関する一般的な質問については、「TLS の問題の解決」を参照してください。

次のステップ

• トラブルシューティング
• Azure Resource Manager テンプレートの Web テスト
• Web テスト REST API