AWS Transcribe(Speech to text)が日本語対応したので試してみた!あとGoogleとも比べてみた!
AWSのTranscribeが待望の日本語対応をしてくれました!
早速どんなものか試してみたいと思います。
また同じSpeech To Textのサービスを持っているGCPでの動作比較もしてみました。
今回は電話の会話記録の音声データでスピーカが2人存在するデータを利用しました
AWS Transcribe
Transcribeのstart_transcription_jobを実行します。
スピーカは2人のため下記のパラメータを利用しました。
'ShowSpeakerLabels': True, 'MaxSpeakerLabels': 2,
AWSの方は勝手に形態素解析まで実施してくれているのか、
文章がかなり途切れ途切れになりました。
{ "jobName": "samplejob2", "accountId": "xxxxxxxxxxxxx", "results": { "transcripts": [ { "transcript": "もしもし はい あ お 願い し ます お 電話 ありがとう ござい ます か 解析 会社 さん xxxxxxxxxxx モバイル です ホーム ページ を 見 た 言わ せ て いただき まし た ありがとう ござい ます エネルギー 使い 放題 プラン に つい て 聞き たい わ こちら の 契約 期間 の 縛り は あり ます か? こちら は 最低 六 カ月 三 六 カ月 契約 いただく 必要 が ござい ます もちろん か月 より も 短い 期間 工 解約 さ れ た 場合 違約 金 が 発生 し ます 現金 は いくら です か 一 万 円 です 分かり まし た あと パケット 使い 放題 だ と 思い ます が 速度 制限 は あり まし た 正確 な 数字 を 公開 でき ない の です が が ある 一定 の 利用 料 を 超え ます と 翌日 に 速度 制限 が かかる こと が 報告 さ れ て い ます あ 分かり まし た ありがとう ござい ます その 他 ご 不明 な 点 は ござい ます か 大丈夫 です ありがとう ござい ます で は ありがとう ござい まし た 担当 鈴木 が 対応 さ せ て 頂き まし た お 電話 ありがとう ござい まし た ありがとう ござい まし た うん はい" } ], "speaker_labels": { "speakers": 2, "segments": [ ・・・・・・・・・・・・・・・・・・・・・・・・ 長いので省略します。 下記のようにスピーカ毎・単語毎のItemも出力されていました。 ・・・・・・・・・・・・・・・・・・・・・・・・ "items": [ { "start_time": "4.94", "end_time": "5.55", "alternatives": [ { "confidence": "1.0", "content": "もしもし" } ], "type": "pronunciation" }, { "start_time": "6.34", "end_time": "6.65", "alternatives": [ { "confidence": "0.99", "content": "はい" } ], "type": "pronunciation" }, { "start_time": "6.66", "end_time": "7.58", "alternatives": [ { "confidence": "0.974", "content": "あ" } ], "type": "pronunciation" }, { "start_time": "7.59", "end_time": "7.65", "alternatives": [ { "confidence": "0.906", "content": "お" } ], "type": "pronunciation" }, { "start_time": "7.66", "end_time": "8.09", "alternatives": [ { "confidence": "1.0", "content": "願い" } ], "type": "pronunciation" }, { "start_time": "8.1", "end_time": "8.24", "alternatives": [ { "confidence": "1.0", "content": "し" } ], "type": "pronunciation" }, { "start_time": "8.25", "end_time": "8.55", "alternatives": [ { "confidence": "1.0", "content": "ます" } ], "type": "pronunciation" }, { "start_time": "10.44", "end_time": "10.51", "alternatives": [ { "confidence": "0.972", "content": "お" } ], "type": "pronunciation" },
GCP
続いてGCPです。
AWSの方で利用したのと同じ音声ファイルを利用し
Cloud Speech-to-Textを実行してみます。
{ "conversation": [ { "transcript": "はい", "confidence": 0.9321745038032532 }, { "transcript": "お電話ありがとうございます株式会社xxxxxxxxxxxxxモバイルです", "confidence": 0.9289773106575012 }, { "transcript": "ありがとうございます", "confidence": 0.9539141654968262 }, { "transcript": "ホームページを見ると言わせていただきました良い使い放題プランについてお聞きしたいですかこちらは契約期間の縛りはありますか", "confidence": 0.891223669052124 }, { "transcript": "こちらは最低6ヶ月間6ヶ月契約いただく必要がございます", "confidence": 0.9191603064537048 }, { "transcript": "もし6ヶ月よりも短い期間でご解約された場合違約金が発生してます", "confidence": 0.9336251616477966 }, { "transcript": "違約金はいくらですか", "confidence": 0.9120486974716187 }, { "transcript": "1万円です", "confidence": 0.9227500557899475 }, { "transcript": "わかりました本当ポケット着たい放題だと思いますが速度制限はありますか", "confidence": 0.9032462239265442 }, { "transcript": "正確な数値は公開できないのですが", "confidence": 0.9470984935760498 }, { "transcript": "日課である一定の量を超えますと翌日に速度制限がかかることが報告されています", "confidence": 0.9332273602485657 }, { "transcript": "分かりましたありがとうございます", "confidence": 0.9206825494766235 }, { "transcript": "その他ご不明な点はございますか", "confidence": 0.952523410320282 }, { "transcript": "大丈夫ですありがとうございます", "confidence": 0.932539701461792 }, { "transcript": "ではありがとうございました担当鈴木が対応させていただきましたお電話ありがとうございました", "confidence": 0.9320775866508484 }, { "transcript": "ペロ寝ました", "confidence": 0.7940347790718079 } ] }
ペロ寝ましたって何だって思うかもしれませんが、「ありがとうございました」を言っています。
それはさておきGCPの方の方が制度が高そうです。
その他2,3個の音声ファイルで試してみたのですが
私の印象ではまだGCPの方が精度が高いように感じます。
精度に関してはAWSもこれから上がっていくのかと期待しています。
APIの使い方自体はAWSの方がシンプルで使いやすい印象を受けました。
またアウトプットファイルがS3に格納されるのですが、
S3のファイルputイベントと、他のサービスを組合せるなど
面白そうな使い方ができそうです。
(GCPの場合は音声ファイルのサイズによりオプションを変える等の面倒な点があります)
AWS cloudtrailの「ログファイルの検証を有効化」の機能を試してみる
cloudtrailの「ログファイルの検証を有効化」の有効化にはするのですが、
機能詳細を確認することがありませんでした。
先日触ってみたので備忘で残したいと思います。
cloudtrailの赤枠部分のファイルを書き換えてみました。
Validate-logsを試してみる
上記ファイルを修正し、validateすると書換が発生したログファイル分かります。
aws cloudtrail validate-logs --trail-arn arn:aws:cloudtrail:ap-northeast-1:xxxxxxxxxx:trail/aws217-test --start-time 20190113T19:00:00Z Validating log files for trail arn:aws:cloudtrail:ap-northeast-1:xxxxxxxxxx:trail/awsxxx-test between 2019-01-13T19:00:00Z and 2019-01-15T03:45:33Z Log file s3://awsxxx-test-cloudfront-in-test6/test-prefix/AWSLogs/xxxxxxxxxx/CloudTrail/ap-northeast-1/2019/01/15/xxxxxxxxxxx_CloudTrail_ap-northeast-1_20190115T0110Z_eKpIcz4LwCJIlM6d.json.gz INVALID: invalid format Results requested for 2019-01-13T19:00:00Z to 2019-01-15T03:45:33Z Results found for 2019-01-13T19:56:11Z to 2019-01-15T01:56:11Z: 31/31 digest files valid 192/193 log files valid, 1/193 log files INVALID
検出可能な項目は下記ドキュメントに一覧化されています。
docs.aws.amazon.com
変更内容までは追えないようなので、
このあたりを追うのであれば下記との組合せが必要そうです。
AWS lambdaからGCPのSDKを使うlambda layerを作成
先日、AWS LambdaからGCPのSDKを利用したいと思い、
Layerを固めることがありました。
その際エラーが出てしまい解決までにハマってしまったので、
ブログに書こうと思いました。
エラー内容
固めたzipをlambda Layerとしてアップしたところ
Runtimeエラーとなってしまいました。
実行環境はAmazonLinux2です。
Runtimeエラーの対策
Lambda RuntimeのEC2(AmazonLinux)でpython3系を設定
AWS WAF 海外IPを拒否しGoogleのクローラ(bot)は許可する設定
Googleのクローラの条件
海外IPアクセスの条件
AWS WAFを設定
まず1つ目のCondition作成として「string and regex match」を選択します
「Googlebot」をuser-agentヘッダに含む場合の条件を作成します。
上記のように入力しAdd filterボタンを押します。
Filterに追加されたらCreateボタンを押します。
条件作成2個目
2つ目の条件は国別の制限をします。Geo matchを選択します。
日本を登録します
ルール作成
上記で作成した条件を元にルールを作成します
上記で作成した条件を設定します。
この時、WAFのデフォルトルールを
Allowにしたかったので下記のようにルールを設定しています。
条件の整理
B=「日本からのアクセス」
=「User-agentにGooglebotを含まない」かつ「海外アクセスである」
- 「User-agentにGooglebotを含まない」かつ「海外アクセスである」場合ブロック
- それ以外はAllow(許可)
ド・モルガン風に考える
検証してみる
注意点
- WAFログを定期的に解析しアクセス元IPをDNSリバースルックアップ[※1]を実施
- なりすましのアクセス元IPを判定する
- 2のIPをWAFのIP拒否リストに設定する
AWS KMS の概要とエンベロープ暗号化について説明してみる
最近AWS KMSについて聞かれることがあったので
ブログにまとめてみようと思います。
KMSってなに?をざっくり
- 対象鍵を安全に保管してくれるサービス
- 各AWSサービスのデータ暗号化・複合化する機能として連携(S3、EBS等)
- うるさいセキュリティのポイントをある程度抑えてくれる(キーローテーション、暗号化鍵の方式を決定)
前提知識:対称鍵とは
キーの種類
下記に簡単な説明を書きます。
・AWS所有
見ることすらできない鍵です。AWSが利用します。
基本的に触れないので理解すべきこともないです。
・AWS管理
もっともよく使う鍵です。
おおよそのケースで単純に暗号化したいだけならこの鍵を利用します。
デフォルトの鍵です。aws/service-nameの形式で存在します
ある程度AWSが用意した枠組みでしか管理ができないため
細かい制御が必要な場合は後述のカスタマー管理のキーを利用します。
例えば、クロスアカウントで共有が不可のため、
複数アカウントが関連するときは利用できないケースが多いです
・カスタマー管理
・データキー
上記のように運用することで下記を実現できます
・容量大データも一律して同じ大きさのDatakeyを利用し暗号/複合管理
・外部に漏れるとマズイ情報(Plaintext data key)は必要な時のみ取出し利用
https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/concepts.html#enveloping
エンベロープ暗号化をCLIで一通りこなしてみる
AWS S3のオブジェクトを時間指定でパブリック公開する
検証内容
AWS:VPCピアリングでうまく接続できない時に確認したいこと
VPCピアリングでうまく接続できない時に確認したいことを、自分でもたまに忘れそうなのでメモがてら書きます。
セキュリティグループ、ルートテーブル、NACL
この辺りは当然ですね。丁寧に確認しましょう。
名前解決ができるかどうか
RDS等の接続ができない場合は、こちらが怪しいです。
https://docs.aws.amazon.com/ja_jp/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns