連絡履歴の機能とガイダンス機能について
回答済み
お世話になっております。
Pigeon 機能について以下3点をご教示ください。
質問【20210819_1】
連絡履歴パラメータフィールドの表示について
加工パラメータで指定して表示しているデータ以外に、"callflow" は"scope" などと同じくデフォルトで表示しているものになりますか？
質問【20210819_2】
ガイダンスに指定された文字列（加工パラメータによる一時保存データ含む）で、読み上げされない文字、認識されない文字があります。
弊社のテストでは、"&" を指定するとそれ以降の文字を認識してないように思います。この理由は何でしょうか？
また、’ （ ＾ の様に読み上げしない文字の一覧があればご教示いただけないでしょうか？
質問【20210819_3】
ガイダンス応答ボタンの機能「１」「２」「３」以外に、
「もう一度メッセージを聞きたい」ような機能のボタンはないでしょうか？
もし無い場合は、「１」「２」「３」の選択をせず、
ガイダンスに同じ内容を羅列するのでなく、何か代替案があればご教示ください。
以上です。よろしくお願いいたします。
-
お世話になっております。
上記質問のうち、質問【20210819_1】
連絡履歴パラメータフィールドの表示について
の質問内容を訂正させてください。
申し訳ありません。
【改め】連絡履歴パラメータフィールドに表示される情報は、
・パラメータ加工フローにて指定し、一時データとして格納したもの・AlertHub の標準出力で、"messege","scope","event","scopeSeverities","space" の5項目
の2分類が表示される仕様になっているということでよろしいでしょうか？
パラメータ加工フローに指定したものと、ガイダンスのメッセージテンプレートに指定している一時データとの合致性が少々混乱してしまっており、誤った質問をしてしまいました。
したがいまして質問【20210819_1】を上記【改め】に変更させていただきます。
申し訳ありませんが、よろしくお願いいたします。 -
ご質問ありがとうございます。
ご回答大変遅くなり、申し訳ございません。【改め】連絡履歴パラメータフィールドに表示される情報は、
・パラメータ加工フローにて指定し、一時データとして格納したもの・AlertHub の標準出力で、"messege","scope","event","scopeSeverities","space" の5項目
の2分類が表示される仕様になっているということでよろしいでしょうか？
AlertHub経由でPigeonを利用した場合、挙げていただいた5項目は常にパラメーターとして渡されます。パラメーター加工フローにて指定した項目はこれらに加えて追加で渡される形となります。
Pigeonとしてはすべて同列のデータとして扱っておりますので、ガイダンスの設定によりいずれのパラメーターも実行時に読み上げ内容への埋め込みが可能です。
ガイダンスに指定された文字列（加工パラメータによる一時保存データ含む）で、読み上げされない文字、認識されない文字があります。
弊社のテストでは、"&" を指定するとそれ以降の文字を認識してないように思います。この理由は何でしょうか？また、’ （ ＾ の様に読み上げしない文字の一覧があればご教示いただけないでしょうか？
これに関しては内部で使用している架電システムの都合によるものでございますが、原則としては文章として音読する際に一般的に読み上げられない文字（わかりやすい例で言えば「」は人の発言内容や強調を示す記号であり、都度「カギカッコ」と読むケースは稀かと思います）は読み上げられず、そうでない文字は読み上げ対象となります。ただし例外はあるものと思います。
基本的にUNICODEの全ての文字が指定可能である都合上、「読み上げしない文字の一覧」にあたる資料の用意は難しく、こちらに関しては実際にお試しいただく形でお願いしております。
また文章に「&」が含まれる場合に以降の読み上げが行われない事象については弊社内でも確認を行わせていただき、架電システムの不具合によるものと判明しております。これを回避する機能改善を早急に進めておりますので、アップデートをお待ちいただければと思います。
アップデートは遅くとも来週には適用予定です。大変ご迷惑をおかけし、申し訳ございません。
ガイダンス応答ボタンの機能「１」「２」「３」以外に、
「もう一度メッセージを聞きたい」ような機能のボタンはないでしょうか？もし無い場合は、「１」「２」「３」の選択をせず、
ガイダンスに同じ内容を羅列するのでなく、何か代替案があればご教示ください。再読み上げを指示するボタン機能はございませんが、ガイダンス読み上げ後には5秒間のボタン入力待ちを挟み、自動的に再度の読み上げが行われます。ただし、この再読み上げに対してなお応答がない場合はシステム固定のエラーメッセージが流れた後、通話が自動切断されます。
ボタン入力による任意タイミングでの再読み上げや3回以上の再読み上げには対応しておらず、こちらに関しては現時点の制約事項として、ご理解いただければと思います。
（読み上げ回数に関してはおっしゃる通り、ガイダンス自体に同じ内容を繰り返して設定しておくことで擬似的に回数を増やすことは可能です） -
お世話になっております。
質問【21010819_2】について追加質問があります。
＞また文章に「&」が含まれる場合に以降の読み上げが行われない事象については弊社内でも確認を行わせていただき、架電システムの不具合によるものと判明しております。これを回避する機能改善を早急に進めておりますので、アップデートをお待ちいただければと思います。
上記のご対応をいただき、ありがとうございます。
ご連絡をお待ち申し上げておりますので、よろしくお願いいたします。
また、チーム内から
「’」シングルコーテーション
<CR><LF>「ennter」についても同事象があったとの報告がありました。
付けたしになってしまい申し訳ないのですが、上記2つの特殊文字についてもご回答いただけますでしょうか？
よろしくお願いいたします。 -
お世話になっております。
また、チーム内から
「’」シングルコーテーション
<CR><LF>「ennter」についても同事象があったとの報告がありました。
付けたしになってしまい申し訳ないのですが、上記2つの特殊文字についてもご回答いただけますでしょうか？こちら、事象確認させていただきました。
シングルコーテーションについては確かに「&」と同様の事象を確認し、これについても想定外挙動と思われますので正常に処理が行えるよう対応させていただきます。
<CR><LF>に関しては弊社内で事象が再現せず、少なくともPigeonの挙動上の問題でないことを確認しております。こちらに関しては、おそらく「パラメータ加工フロー」にて正規表現を用いてデータを抽出していることによる制約と思われます。
以前いただいたご質問「受信メールから正しくスコープを選別するコツはありますか？」でのやりとりにて正規表現の「^」「$」が文章全体の先頭・末尾ではなく行頭・行末にマッチするように挙動改善させていただきました。この対応により正規表現のマッチが行単位で行われるようになっているため、複数行に跨るデータを抽出することができなくなっており、改行以降の文面が抽出できていないものと考えられます。
こちらに関して複数行の情報を取り扱うための機能改善が考えられるか社内で検討させていただきますが、当面はこれに関しては仕様上の制約として、正規表現により抽出するデータには改行を含められないものとお考えください。
ご不便をおかけし、申し訳ございません。
よろしくお願いいたします。 -
よってご回答いただいている ^ $ は使わずに抜き出している文字列群（System Walker からのエラーメッセージなので、複数行にわたるケースあり）なのですが、それでも同様のご回答になりますでしょうか？
申し訳ございません、設定内容について少々誤解をしておりました。
確認いたしましたところ、現在の挙動ですと「.」が改行文字にマッチしないようになっており、error:\s*(.+(\r?\n.+)*)
のように「改行+続きの文面が0個以上続く」ことを明示することでうまく全文を取得できる可能性があるようです。
ただしこの場合、送られてきた文面が例えば
error: 障害が発生しました。
詳細を確認してください。
status: failedのように後ろに別の情報を含む場合に、「error」に関する情報だけを抽出するのは難しくなります。
これに関しては、例えば「error」の直後に来るのが「status」とわかっていれば
error:\s*(.+(\r?\n.+)*)\r?\nstatus:
と「status」部分までをマッチさせることで、「error」の文面だけを取得できるかと思います。
このように複数行を取り扱う場合は正規表現の取り扱いの難易度が上がりますので、ご留意ください。
-
お世話になっております。
先ほど製品のアップデートを行い、文面に「'」「&」が含まれる場合に読み上げが途中で途切れてしまう問題について解消いたしました。
改めて動作について確認いただければと思います。弊社でも「' <CR><LF> &」などをデータから除外するなども可能ですが、どの文字が今回の事象に該当するかはご回答可能なものでしょうか？
今回挙げていただいた「'」「&」の他に、「<」「>」「"」にて読み上げが途切れる問題が発生するケースがあったことが判明しており、これらについては先のアップデートにより一通り修正いたしました。
修正にあたり、各種記号のうち特に悪影響を及ぼしやすいASCIIコード範囲内の半角記号については一通り正常動作を確認しておりますが、もしなんらかの文字により再度同様の事象が確認されるようであればお知らせください。
また、<CR><LF>に関しては先に申し上げた通り正規表現由来の挙動である可能性が高く、正規表現の設定の難易度も考えますと、データからの除外が可能であればその方がシンプルに解決するものと思います。お手数をおかけいたしますが、ご検討のほどよろしくお願いいたします。
サインインしてコメントを残してください。
コメント
9件のコメント