Kompira シリーズ間での架電情報の引き渡しについて
回答済み
お世話になっております。
Pigeon には連絡先とコールフロー機能がありますが、これを受信スロットに入るメール情報から指図することはできますか？
※イメージでお尋ねしているので、もし方向性が間違っている場合は、実現可能な方向性をご提示ください。
もしメール内に、連絡先名や電話番号、もしくはコールフローIDなどを含ませておいた場合に、AlertHubを通して、一致したコールフローを呼び出すなどできますでしょうか？
Enterprise を利用した場合と、利用しない場合とでご教示ください。
よろしくお願いいたします。
-
正式なコメント
ご質問ありがとうございます。回答させていただきます。
AlertHubのPigeonアクション単体では、受信メッセージに応じて使用するコールフローを変えることはできませんが、これを実現する方法はいくつかございます。
■ ルール・スコープ・アクションを複数作る方法
使い分けるコールフローが2〜3個と十分に少ないようであれば、受信スロットに対して複数のルールを定義し、例えば「コールフローA」という文面が含まれる場合に「スコープA」にイベントを発行するルール、「コールフローB」という文面が含まれる場合に「スコープB」にイベントを発行するルール・・・といった形でそれぞれ別のスコープへイベントを発行する方法を取ることができます。
あとはコールフロー毎に1つずつ別のアクションを定義しておき、スコープ毎に異なるアクションを呼び出すようトリガー設定を行うことで、受信したメッセージ内容に応じて呼び出されるアクションが変わり、コールフローの使い分けをすることができます。
この方法は設定の数が増えるため煩わしいですが、設定の難易度は最も易しくなります。
■ Webhookアクションを用いてPigeonのAPIを呼び出す方法
Pigeonアクションを使わずに、WebhookアクションによりPigeonの連絡実行APIを呼び出すことも可能です。Webhookアクションではリクエストボディ内にメッセージ受信内容や、その一部を抽出して挿入することができるので、コールフローIDを動的に変えてリクエストを送ることができます。
この方法を取る場合、サービス外からPigeonのAPIを利用するのと同じくAPIトークンを発行し、X-Authorizationヘッダを指定してリクエストを送る必要がございます。
■ Kompira Enterpriseを使用する方法
Kompira Enterpriseを使用する場合、AlertHubでWebhookアクションを用いてEnterpriseのWeb APIを呼び出すか、受信用のメールサーバーが用意できる場合はEnterpriseからそちらへ直接アクセスしてメールを受信する形でメッセージを受け取ります。
メール本文を解析し、内容に応じてコールフローIDを決定する流れはEnterprise上に実装し、最終的にはEnterpriseからPigeonのAPIを呼び出すことで連絡実行を行う形となります。
コメントアクション -
2パターン目で提示した方法は、curlコマンドにより手動でPigeonのAPIを呼び出すのと同等の動きをAlertHubのWebhookアクションにて実現する形となります。PigeonのAPIの呼び出し方に関しては Pigeon チュートリアル が最もわかりやすいかと思いますので、まずはこちらにお目通しいただいたうえで、下記の説明をお読みください。
AlertHubのWebhookアクションでチュートリアルにあるようなAPI呼び出しをするには、下記のようにアクションを設定する必要があります。
- アクションの種類として「WEBHOOK」を選択
- 「Webhook URL」にPigeonの連絡実行APIのURLを入力
- 「HTTPメソッド」に「POST」を選択
- 「リクエスト本文」にAPIへの送信データを入力
- 「HTTPヘッダ」にヘッダ名「Content-Type」を値「application/json」で追加
- 「HTTPヘッダ」にヘッダ名「X-Authorization」を値「Token APIトークンの値」で追加
このとき、手順4で入力する送信データはチュートリアルの例にならうと、下記の様になります。
（実際のコールフロー・ガイダンスのIDや、ガイダンスの内容によってこの指定内容は変わります）{ "params": { "callflowId": "049de6fc-c1a7-4963-af43-616cce2492c6", "guidanceId": "570e6f71-5459-43fe-a745-aa7d115ce20d", "parameters": { "server": "テスト用サーバー", "incident": "軽度の障害" } } }このとき、コールフローIDの指定を動的に変えるには「049de6fc-c1a7-4963-af43-616cce2492c6」の部分をパラメータ化する必要がございます。例えばトリガーの「パラメーター加工フロー」を用いて「callflowId」というフィールドにコールフローIDをセットした場合の全体の設定イメージは下記の画像のようになります。
同様の流れにて、使用するガイダンスやガイダンス文面に展開するパラメーターも動的に決めることが可能です。
-
お世話になっております。
時間が経ってしまって申し訳ありません。
上記の■ Webhookアクションを用いてPigeonのAPIを呼び出す方法
を実践したのですが、400 Bad Request で返されました。
何が悪いのかご教示いただけますか？
"detail": "Invalid request payload", と出ていたので、リクエスト本文を以下に転記いたします。
{
"params":{
"callflowId": "{{callflow}}",
"guidanceId": "f682ad66-b641-4c59-bf04-9e745239d97e",
"parameters":{
"hostname": "{{hostname}}",
"date": "{{date}}",
"time": "{{time}}",
"error": "{{error}}"
}
}
}やりたかったことは、コールフロー数が増えてしまったので、
・コールフローを動的に変えて架電したい・加工パラメータで一時保存されたデータも併せて動的に変えて架電したい
です。よろしくお願いします。
ステータスコード400 のボディ：
{ "type": "https://fixpoint.co.jp/probs/badrequest", "title": "Invalid request parameter(s)", "detail": "Invalid request payload", "instance": "/api/apps/pigeon/chain/invoke" }
ヘッダ：Cache-Control no-cache, no-store, no-transform, must-revalidate, private, max-age=0 Content-Length 168 Content-Type application/json; charset=utf-8 Date Fri, 01 Oct 2021 09:24:26 GMT Expires Thu, 01 Jan 1970 00:00:00 UTC Pragma no-cache Server nginx Vary Origin -
お世話になっております。
上記ご説明拝読いたしました。
再度よく読み直し、弊社はアラートメールの中で、Pigeonコールフローの「表示名」を使って
ルールの正規表現でマッチングをし、
パラメータ加工フローによって、Pigeonコールフローの「表示名」を抜き出しているので、
Pigeonコールフローの「表示名」を使うのではなく、
Pigeonコールフローの「コールフローID」を動的に利用するのかと推察いたしました。
以下が弊社で本日再テストしてみた結果です。
残念ながら、今度はルールが破棄されてしまいました。
sakura editer で正規表現をためすとちゃんと検索されるのですが、何がわるいのでしょうか？
また、何か勘違いがありますでしょうか？
ご教示をお願いいたします。
*----------------------------------------------------------------------------------*
【受信スロットに入ったアラートメール】（一部）callflow: 73021c20-78a3-42d7-8cea-df7802d86cff
hostname:xxxxxxxxxxxxxxxxxx
date:2021/09/03
time:11:01:19
error:種別 ：システム ソース ：Schannel*----------------------------------------------------------------------------------*
【マッチングさせるルール指定】
*----------------------------------------------------------------------------------*
今回、上記ルールが破棄となっています。
もし破棄とならなかったら、トリガー指定は以下です。
【パラメータ加工フロー】
*----------------------------------------------------------------------------------*
【アクション】
上記パラメータ {{callflow}} を以下のリクエスト本文に指定してAPIを使おうと思っています。
以上、よろしくお願いいたします。
-
お世話になっております。
メールの文字間に「スペース」があることに気づかず、失礼いたしました。
WEBHOOK API での架電は動作いたしました。
これまでのテストと仕様を変えることになるため、正確に仕様を把握したいと思います。
上記の仕組みで架電をPigeon ではなく、WEBHOOK で行う場合、
①コールフローIDを処理フローでマッチングするため、
ルール：コールフローID ＝ 1:1 の関係となり、
ルールはコールフローID数分作成が必要
②①より、スコープもコールフローID数分の作成が必要
③トリガー・アクション・ガイダンスは各スコープ共通で利用可④WEBHOOKアクションのHTTPヘッダに指定したトークンは、いつまで使えますか？
トークンカレンダーは何年も先まで用意があるようですが、半年／一年などど利用可能期間を決めて
運用するべきか、通常どう推奨なさってるのか教えてください。
⑤今回、WEBHOOKリクエスト本文にパラメータとして、
{{hostname}},{{date}},{{time}},{{error}} を指定しました。
これは加工パラメータによって、メール本文から抽出され、ガイダンスに記載してあります。
リクエスト本文には、やはりparameters として指定が必要なものですか？
⑥この架電の連絡履歴を見ると、Pigeon の時よりずっとパラメータ情報が減っています。
WEBHOOKリクエスト本文で指定した、
{{hostname}},{{date}},{{time}},{{error}}
のみが表示されています。
これはAPI で指定したもののみ表示する仕様ですか？
例えば他にも表示できるものはありますか？
またその表示方法は上記以外にどのようなものがありますか？
⑦WEBHOOK API による自動架電を運用に移した時、
ルールやトリガーの並列処理はどうなるのでしょうか？
すべての架電において同じ名前の一時フィールドを用いています。
架電が自動で大量に発生した場合、
処理遅延
待ち行列
データのUNIQUE 性（整合性）について
心配はいらないとは思いますが、Pigeon というアプリ利用に比べて
API コマンドでは劣る部分があるかなど、念のため教えてください。
以上、ご回答のほどよろしくお願いいたします。 -
回答させていただきます。
■ ①②③について
目的がコールフローの使い分けのみであれば、トリガーによるコールフローID抽出だけ行えば連絡先のコールフローはメール本文から決定可能ですので、ルールやスコープも1つで問題ございません。
連絡先のコールフローごとに深刻度を分けて管理する必要があるようであれば、ルール・スコープを個別に持つことが必要となりますが、 トリガーの「パラメーター整形フロー」で行っているのと同様にルール側でもコールフローIDを抽出を行い、これを深刻度名として利用することで1つのスコープ・ルールで設定ができる可能性はございます。
こちらの記事もご参照ください。
製品情報 - AlertHub のスコープに複数の深刻度を持たせることが出来るようになりました
■ ④について
APIトークンはそれ1つで全てのAPI操作が可能となる非常に強力な情報となっており、漏洩に気を配るのであれば長くとも1年程度に設定しておき、定期的に更新するほうがセキュアとなります。
とは言え更新が漏れたまま気付かないでいるとPigeonによる連絡が発生しなくなるリスクもありますので、トークン期限の管理に手をかけ難いようであればいっそ十分に長い期間を設定し、事実上期限切れしないトークンを発行する運用にしても構いません。
安全性と利便性はトレードオフの関係にありますので、運用上無理ない範囲での期間設定をするのがよろしいかと思います。
■ ⑤⑥について
WebhookアクションにてPigeonのAPIリクエストを行う場合、Pigeonの架電パラメーターとして使用する情報は全て「parameters」内に明示する必要がございます。また逆に明示していない情報がPigeonに渡されることはございません。
Pigeonアクションによる連絡実行も原理としてはWebhookアクションと同等ですが、こちらでは「parameters」へ指定する値を自動的に決定する形となっております。
■ ⑦について
Pigeonアクションではコールフロー・ガイダンスの選択のみに設定を簡素化しているものの、内部的にはAPI経由で連絡のリクエストを行なっております。そのため今回のWebhookアクションを使用するのとPigeonの動作には特に違いはございません。
-
お世話になります。
ご回答ありがとうございました。
申し訳ありませんが、もう少し教えてください。
弊社の架電は、■１．スコープ・ルール（深刻度は常に0）・トリガー・アクション・Pigeon の
一番シンプルな構成
■２．アラートメールには「コールフロー表示名」を持たせ、ルールで「コールフロー表示名」を指定した正規表現でマッチするかどうかのチェックを施す（↓）（もし「本文」が「^callflow:callpocUN$」とマッチした場合）
■３．トリガーでパラメータ加工フローによりメール内データ抽出
（「本文」から正規表現「callflow:\s*(\S+)」によって値をひとつ取り出して一時フィールド「callflow」に保存する
の構成です。
＞＞■①②③について
＞＞目的がコールフローの使い分けのみであれば、トリガーによるコールフローID抽出だけ行えば連絡先のコールフローはメール本文から決定可能ですので、ルールやスコープも1つで問題ございません。【質問１：20211005】
今回、目的を「コールフローの動的指定による自動架電」に置いております。
そうすると、200近くある新規コールフローにおいて、従来のKompira cloud の構築工数が削減できるかと思っております。ご回答に「コールフローはメール本文から決定可能ですので、ルールやスコープも1つで問題ございません。」とありますが、
動的を目的にするので、もし
■２．の、ルールによるコールフローIDのマッチングはしないとした場合、
何か不都合はありますでしょうか？受信スロットに入ってきたメール全てが対象になるかと思います。
リスクなどありませんでしょうか？またその時、マスター構成が１つ在って、コールフローが増えるごとに構築が必要となるのは、
どれでしょうか？
■２・の場合、rule は受信スロットと深刻度のために必要かと思っております。
※処理フロー登録なし
でも受信スロットも深刻度も変更がなければ、マスターがあればよいでしょうか？
【質問２：20211005】
＞＞■ ⑤⑥について＞＞WebhookアクションにてPigeonのAPIリクエストを行う場合、Pigeonの架電パラメーターとして使用する情報は全て「parameters」内に明示する必要がございます。また逆に明示していない情報がPigeonに渡されることはございません。
＞＞Pigeonアクションによる連絡実行も原理としてはWebhookアクションと同等ですが、こちらでは「parameters」へ指定する値を自動的に決定する形となっております。
Pigeon が自動的に表示しているパラメータ
callflow,event,message,scope,scopeSeverities,space,trigger
については、webhook-action のparameters の中に{{scope}} のように指定すれば、連絡履歴に出せるようになりますか？
また、パラメータ callflow については、弊社でガイダンスに載せていないのに連絡履歴パラメータに現われています。
もしやシステム予約のパラメータ callflow と、
弊社がパラメータ加工フローで指定した任意の一時フィールド名 callflow が被ってますでしょうか？
パラメータ加工フローで指定した任意の一時フィールド名 callflow は、callflowID とか CFid とかに
変えて運用したほうが安全でしょうか？以上、ご回答のほどよろしくお願いいたします。
-
■ 【質問１：20211005】について
書かれている内容を拝見した限りですと、受信スロット・ルール・スコープは完全に1つにまとめて問題ないように思います。ただし、受信スロットに対して送信するメールの中にPigeon連絡を実施しないものが含まれるようでしたら、例えば「message.content.text」が正規表現「^callflow:\s*(\S+)$」とマッチ「する」ものだけを通すようにルールを組むなど、連絡対象外のメールを除外するようにルールを設定する必要はございます。
ルールを1つにまとめることに関してはパフォーマンス上の問題はなく、むしろ1つの受信スロットに対して判定されるルール数が少ない方が有利となります。
■ 【質問２：20211005】について
webhook-action のparameters の中に{{scope}} のように指定すれば、連絡履歴に出せるようになりますか？
scopeのような複数の値を子要素として持つものを直接指定するのは上手くいきませんが、 {{scope.scopeId}} のように必要な値1つに絞り込む形で指定する分にはPigeonのパラメーターと指定しても問題なく、連絡履歴にも表示されます。
パラメータ加工フローで指定した任意の一時フィールド名 callflow は、callflowID とか CFid とかに
変えて運用したほうが安全でしょうか？Webhookアクションを用いて連絡を行う場合、「parameters」に指定したパラメータのみPigeonに渡されることになりますので、そちらに指定していないパラメータが渡されることはございません。
一方でPigeonアクションを使用する場合はトリガーの「パラメーター整形フロー」にて生やしたデータがそのまま受け渡されるため、おそらくはPigeonアクションによる連絡結果と混同しているものと思います。どちらにせよ、Pigeon側の処理に特に影響は起きませんので、フィールド名は自由に指定していただいて構いません。
-
もう一点お願いいたします。
＞＞scopeのような複数の値を子要素として持つものを直接指定するのは上手くいきませんが、 {{scope.scopeId}} のように必要な値1つに絞り込む形で指定する分にはPigeonのパラメーターと指定しても問題なく、連絡履歴にも表示されます。上記の{{scope.scopeId}} をparameters 指定しようと思います。
"parameters":{
"hostname": "{{hostname}}",
"date": "{{date}}",
"time": "{{time}}",
"error": "{{error}}"の中に指定することになるとおもいますが、
/api/apps/pigeon/chain/invoke のAPIドキュメントの Schema をみると、parameters*
{description: Guidanceテンプレートの置換用辞書。 詳細はGuidanceのmessageTemplateの説明を参照。とあります。
{{scope.scopeId}} をparameters 指定するには、どう記述すればよいかご教示ください。よろしくお願いいたします。
-
ご教示いただいた、^callflow:\s*(\S+)$ ではルールが破棄されてしまいます。
^callflow:.*$ などもやってみましたが同じです。添付画像拝見しましたが、こちらの錯覚かもしれませんが「$」と手前の「)」との間の空白幅が少々大きいように見えます。下記のいずれかにあたる可能性が考えられますので、ご確認ください。
- 「)」と「$」の間に半角スペースが混じってしまっている
- 「$」が全角の「＄」になってしまっている。
いずれにも当たらない場合、別の可能性としてはメール本文の方の行末に半角スペース等が含まれていたりすると、空白文字以外とマッチする「\S」と行末マッチする「$」との間に空白文字が許容されていないことからマッチがうまくいかなくなることが考えられます。これを考慮するのであれば、下記のように正規表現を設定ください。
^callflow:\s*(\S+)\s*$
もしくは、行頭・行末にマッチさせてのチェックが不要であればトリガーの方と同様に「callflow:\s*(\S)」とのマッチで確認するのでも良いかと思います。
{{scope.scopeId}} をparameters 指定するには、どう記述すればよいかご教示ください。
parametersの中に、たとえば下記のように指定を増やしてください。
"parameters" {
"hostname": "{{hostname}}",
"date": "{{date}}",
"time": "{{time}}",
"error": "{{error}}",
"scopeId": "{{scope.scopeId}}"
}いつも翌日には回答いただいているので、何か情報が足りないのではないかと思い
ご連絡いたしました。ご回答遅くなりまして申し訳ございません。
サポートにいただいたご質問に関しては1営業日中（翌日が平日であれば24時間以内）に返答することを目標としておりますが、可能な限り日付が変わる前に回答できるように努力させていただいております。
一方で業務状況によっては回答までの時間には差が出てしまうこと、ご理解いただければと思います。
-
お疲れ様です。
ご提示いただいたパラメータ指定だと異常となってしまいます。
私も同様の指定はしていたのですが、何が悪いのでしょうか？
申し訳ありませんがご教示願います。
{
"params":{
"callflowId": "{{CFid}}",
"guidanceId": "f682ad66-b641-4c59-bf04-9e745239d97e",
"parameters":{
"hostname": "{{hostname}}",
"date": "{{date}}",
"time": "{{time}}",
"error": "{{error}}",
"scopeId":"{{scope.scopeId}}”
}
}
}ボディ{ "type": "https://fixpoint.co.jp/probs/badrequest", "title": "Invalid request parameter(s)", "detail": "Invalid request payload", "instance": "/api/apps/pigeon/chain/invoke" }ヘッダCache-Control no-cache, no-store, no-transform, must-revalidate, private, max-age=0 Content-Length 168 Content-Type application/json; charset=utf-8 Date Thu, 07 Oct 2021 05:11:13 GMT Expires Thu, 01 Jan 1970 00:00:00 UTC Pragma no-cache Server nginx Vary Origin リトライ回数：0/3
失敗理由：400 Bad Request
イベントID：8ffcae44-21c0-4bb3-9c13-8ef9c59a875b -
お世話になっております。
おかしな事象が発生するのでお尋ねします。
①rule の正規表現を加工パラメータと同じものにして、ruleがマッチすることを確認しましたもちろんwebhook API まで動作できて、Pigeonから連絡成功が確認できました。
②rule の正規表現を、ご提供いただいた^callflow:\s*(\S+)\s*$
に変更し、他は何も変えず実施すると、アクションが失敗しました。
失敗コードは前述と同じ 400 Bad Request です。
rule の正規表現は、受信スロットから入ったデータをチェックするもので、
ルールの処理フローを通ったら、そのデータは捨てられるものと思っております。
ですが今回、ruleの正規表現を変えただけで、後続処理に影響がでました。
これは何故でしょうか？
WEBHOOKアクションは、Pigeonアクションに比べて、
何か安定性が落ちる要因がありますか？
本契約後の環境で、全架電を WEBHOOKでやろうとしているので、気になりお尋ねしました。 -
何度も申し訳ありません。
・scopeIdのパラメータがエラーになること
・rule の正規表現を変えただけでアクションが失敗することの原因がわかりました。
原因：メール転送によるもの新規メールであれば、parameter の引き渡しは上手くいき、
転送メールの場合、bad parameter となってしまうようです。
【転送メールの内容】
＊－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＊転送
From: ■■ ■■(Xxxxx, Xxxx)
Sent: Thursday, October 7, 2021 4:20 PM
To: exxxxxxxxxxxxxxxxxxxx_x_q0ygxxxxxxxxxxxxxxxxxxxx_kai@receiver.cloud.xxxxxxxx.jp
Subject: FW: 必ず初回メールで：^callflow:\s*(\S+)\s*$転送
From: ■■ ■■(Xxxxx, Xxxx)
Sent: Thursday, October 7, 2021 4:18 PM
To: exxxxxxxxxxxxxxxxxxxx_x_q0ygxxxxxxxxxxxxxxxxxxxx_kai@receiver.cloud.xxxxxxxx.jp
Subject: 必ず初回メールで：^callflow:\s*(\S+)\s*$callflow:a9be8f92-969d-4f9f-b394-3d352b7b2258
date:2021/10/07
time:16:17
hostname:g o o g l e . c o m n h k
error:空白 括弧() コロン: チルダ^
＊－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－＊
加工パラメータでは、
message.content.text から正規表現「callflow:\s*(\S+)」によって値をひとつ取り出して一時フィールド CFid に保存する
と設定していたので、subject のあたりの情報を拾ってしまい、bad parameter となったようです。
こちらのミスでした。申し訳ありませんでした。
話が変わってしまい申し訳ないのですが、scopeId と同じように、
scope のdisplayName も表示することはできますでしょうか？
その場合は、
"displayName":"{{scope.displayName}}"
の指定でよろしいでしょうか？
また、Schemaの ChainParams に
callflow とありますが、
callflowId だけじゃなく、コールフロー表示名もパラメータ指定で表示することはできますでしょうか？
次々と申し訳ありませんが、こちらもご教示のほどよろしくお願いします。 -
scopeId と同じように、
scope のdisplayName も表示することはできますでしょうか？
その場合は、
"displayName":"{{scope.displayName}}"
の指定でよろしいでしょうか？その指定方法で問題ないかと思います。ただPigeonの連絡結果画面だけ見たときに何のdisplayNameかがわかりにくくなりますので、
"scopeDisplayName":"{{scope.displayName}}"と「scopeの」displayNameであることを明示した方が良いかと思います。
Schemaの ChainParams に
callflow とありますが、
callflowId だけじゃなく、コールフロー表示名もパラメータ指定で表示することはできますでしょうか？ChainParamsの「callflow」はコールフローのID指定ではなく、コールフローの定義内容を直接指定して連絡を行うためのフィールドで、今回のように事前定義したコールフローを用いて連絡を行う場合には使用することができません。
ご参考までに、コールフローの直接指定に関してはこちらの記事の「コールフロー・ガイダンスの内容をその場で指定して連絡を実行する」が詳しいので、そちらを併せてご参照ください。
コールフローの表示名については連絡結果画面から直接確認することはできませんが、「コールフロー」欄のリンクからコールフローの詳細画面に飛ぶことで確認できますので、そちらを併せてご活用いただくのが良いかと思います。
-
お世話になっております。
色々とありがとうございました。
WEBHOOKアクションの仕様がわかってまいりましたので、新規コールフローの架電はこちらの手法で
行う可能性が出てまいりました。
そこで確認をさせてください。■前述した通り、弊社は一番簡単な構成で自動架電の設計をしておりましたので、
callflow が増えるごとに、guidance 以外の設定はすべて新規作成しなくてはなりませんでした。
(scope,rule,trigger,actionが新規に必要で、callflow が200なら、200x4=800 定義の作成）
■しかしWEBHOOKアクションに切り替えた場合、
scope:(全共通で１つ）rule: callflow:callflowId のレイアウトを ^callflow:\s*(\S+)$ でマッチング(全共通で１つ）
trigger：必要なデータを加工パラメータで一時フィールドに格納：仕様は同じ(全共通で１つ）
action：api によりcallflow を動的に変えられるので仕様は同じ(全共通で１つ）
となり、800定義の作成が必要だった設定が１つで済むという認識でよろしいでしょうか？
ご回答のほど、よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
23件のコメント