大変お世話になっております。pinocoです。
弊社は「AWSでなんか、なんか、こう、頑張っていこう」的な感じの会社なのですが、
今日はGCPのサービスについて書いてみたいと思います。
ちなみに余談なのですが、
2018の1Qの各クラウドサービスのシェアはAmazon,MS,IBMと来て第4位にGoogleでございました。
私の肌感覚ではAmazon(AWS),Google(GCP)が主なので「そうなのかー」と感慨深い感じの結果でございました。
もうちょっとAzureやSofLayerなんかも勉強しないといかんなあ、と感じるところではあります。
では本題。
今回検証したのはGCPのCloud Speech to Text APIでございます。
どんなものか、ものすごく掻い摘んで説明しますと、
「音声をinputとしてその音声をテキスト化したものをOutとして返してくれる」
そんなAPIでございます。
では触っていきましょう。
1.inputファイルの作成
音声ファイルの作成については、オフィスで一人ブツブツいいながらつくる勇気がなかったので
とりあえず、弊社の社是ぽい文言をテキスト化してそれをmacのsayコマンドで読み込ませて作ります。
人が読むよりも精度として得られる結果が高くなりそうな気がしますが、羞恥心には変えられませぬ。
# sayに渡すファイルを作る cat << _EOS_ > ./input.f 選ばれ続ける 社会・お客様・従業員にとって無くてならない企業として、 100年後も必要とされていること。 そのためにIT技術を手段として、様々な課題を解決します。 解決するためのプロセスは、可能なかぎりシンプルに。 より少なく、よりシンプルに、そしてより良く。 シンプルであることで本質に近づくと考えています。 _EOS_ # 作ったファイルをsayコマンドに与えて,wav形式のファイル(リニアPCM,16bit,1600Hz)を作ります say -o simp.wav --data-format=LEI16@16000 -f ./input.f
ちなみにさらっと書きましたが、APIが対応している音声ファイル形式に合わせるのに苦心しました。
ここまできたら次はGCP側で作業をします。
2. GCPでやること
基本的にはGCPで公開されているのQuickStart(Using the Command Line)に従って
進めて行けばいいだろう、と「だろう運転」で進めたところ
全然QuickにStartを切れなかったため、以下でやった事を整理しつつ
理解を深めたいと思います。
QuickStartの「Speech-to-Text API を有効にする」に従い、Speech APIを有効化します
で権限を紐づけるサービスアカウントの
役割に「GCSのオブジェクトへの閲覧権限」をつけています。
※APIを呼んでも肝心のGCSに配置した音声ファイルが見れない、という事態がこれで防げるはずです。
上記まで完了したら認証情報(json)が取得出来ますので大事に取っておきます。
APIの有効化が済んだら、GCS上にRegional/ASIA-NORTHEAST1でGCSにバケットを作成して、
作成した音声ファイルをputしておきます。
3. クライアント側での認証情報の設定と、APIの実行
GCPの認証情報を処理するため、google cloud SDKを投入しておきます。
で以下の通りSpeech APIの権限と紐付けてあるサービスアカウントのjson読み込ませ、
アクセストークンが取得できる状態にしておきます。
# サービスアカウントの認証情報の読み込み gcloud auth activate-service-account サービスアカウントのアドレス --key-file APIの有効化の時に取得した.jsonのフルパス # サービスアカウントのトークン取得 gcloud auth print-access-token サービスアカウントのアドレス # 補足 # 確認 gcloud auth list # 検証後、利用した認証情報を除去する gcloud auth revoke サービスアカウントのアドレス
API実行時にパラメーターを渡すためのjsonファイルを作っておきます。
cat << _EOS_ > param.json
{
"config": {
"encoding": "LINEAR16",
"sampleRateHertz": 16000,
"languageCode": "ja-JP"
},
"audio": {
"uri": "gs://バケット名/simp.wav"
}
}
_EOS_
ではトライします。
work$curl -s -H "Content-Type: application/json" \
> -H "Authorization: Bearer "$(gcloud auth print-access-token サービスアカウントのアドレス) \
> https://speech.googleapis.com/v1/speech:recognize \
> -d @param.json
{
"error": {
"code": 403,
"message": "The caller does not have permission",
"status": "PERMISSION_DENIED"
}
}
work$
はい、失敗です。「権限がない」と怒れらます。
もう何も信じられません。
とりあえずダメもとでGCSの音声ファイルオブジェクトのプロパティから
サービスアカウントに対して「読み取り」権限を振ってあげます。
で再度トライ。
work$curl -s -H "Content-Type: application/json" \
> -H "Authorization: Bearer "$(gcloud auth print-access-token サービスアカウントのアドレス) \
> https://speech.googleapis.com/v1/speech:recognize \
> -d @param.json
{
"results": [
{
"alternatives": [
{
"transcript": "選ばれ続ける社会お客様従業員にとってなくてならない企業として100年後も必要とされていることそのために言っと技術を手段として様々な課題を解決します解決するためのプロセスは可能な限りシンプルにより少なくよりシンプルにそしてより良くシンプルであることで本質に近づくと考えています",
"confidence": 0.94387203
}
]
}
]
}
work$
うまくいきました。
confidenceが0.94(おそらく信頼度が94%とかってことだと思われます)です。
でも、なぜうまく行ったのでしょうか。
サービスアカウント作成するときに「ストレージオブジェクト閲覧者」をつけたのに。。
それでは駄目だったということは結果から推察できるのですが、
ではどうすべきだったかが？すぐにはわからないです。
これは宿題にしておきます。
私のGCP,IAMに関する圧倒的な理解度の低さを見せつけたところで、
今日はこれまでにしておきます。
