「音声認識字幕ちゃん」のサイズ調整

最近、ちまたでもスマホの翻訳アプリ、翻訳機器などを目にすることが多くなってきました。しかも同時翻訳までできてしまうのには驚きです。ただ、いざ使おうと思うと、最初はお試しで無料ですが、有料に誘われます。しかもこの翻訳系のサービスは、サブスクが殆どで、毎月料金が発生する形になります。しかもその提供会社はたいていは海外の会社でUSドルベースが多く、円支払いでは毎月3000~5000円などと高額になり、趣味の域を超えます。

今回紹介する「音声認識字幕ちゃん」は、大学の教員をされている西村良太さんが個人で開発され一般に公開されている、「Webベースの、文字起こし＋同時翻訳アプリ」です。大変使いやすくしかも無料です。西村さんには感謝申し上げます。

このサイトで提供されている起動用アプリですが、Windows用のbatファイルは直接に動作するので使いやすいですが、Macはそのままクリックしても動かずシェルスクリプトでアプリ化して動かすようにしました。

Macは一手間増える感じもありますが、異なる設定条件の複数の字幕ちゃんを起動できるのは素晴らしいことです。

但し、OBSに組み込んで使う時などは、都度、翻訳なしにしたり、言語を切り替えたりすることもありそうで、そうした自由度は、Webベースの中で、設定を変更できる方が、都合がいいと思い、今回は、Webをそのまま使うような流れを考えてみました。

但し、日本語の認識、及び、翻訳のレベルは、それほど高いとは言えず、語学を勉強された方からすれば、不満でしょう。標準語でゆっくり話す必要があります。またネットワークの状況で認識の感度が振れます。補助的な用途としてであれば、使い物になるでしょう。

ポイント解説

ビデオを補足します。

１　「音声認識字幕ちゃん」はGoogle Chromeで起動する。

同時翻訳を行う場合は、Google Script API-KEYが必要です。その取得については、

リダイレクト中… – 音声認識字幕ちゃん

www.sayonari.com

の説明に従ってください。

２　Google Chromeの起動時のウインドウサイズを固定できるようにする。

「音声認識字幕ちゃん」の緑色の字幕欄を、OBSでウインドウキャプチャーして、読み込むことを想定していますが、もともとブラウザは、自由にフニャフニャとウインドウサイズを動かすように出来ているため、それを固定させるのが起動用アプリのわけですが、設定変更の自由度が欲しいのとMacの場合の手間の多さから、ブラウザの中の緑色の字幕欄のサイズを固定させて、ブラウザの中で、フォントを変更するようにしたいわけです。

そのために,ウィンドウサイズを自由に追加登録して、それをホットキーで選択できるプラグイン、Window Resizerを使います。

３　「音声認識字幕ちゃん」を起動させるためのAppleスクリプトを作る。

私の場合は、既定ブラウザはSafariにしています。確かに、Safariでは、「音声認識字幕ちゃん」の文字起こし翻訳が起動しません。「音声認識字幕ちゃん」のURLはChromeと紐付けする必要があります。

Appleスクリプトは簡単です。

4　Stream Deckへマルチアクションとして登録する。

二つのアクションを登録します。一つ目は、Chromeで「音声認識字幕ちゃん」を開く、Appleスクリプトです。二つ目は、そのChromeのサイズを合わせるアクションです。私はStream Deckを使いますが、他にもホットキー、ショートカットを登録できるアプリがありますので、活用ください。

５　Stream Deckからマルチアクションを起動する。

Webベースで起動すると、後から簡単に変更ができるので便利です。翻訳言語の変更削除、フォントの変更などがラクです。

６　まとめ

器材記録

音声認識字幕ちゃん
Google Chrome
Window Resizer ( Chromeプラグイン)
Mac スクリプトエディタ
Stream Deck

Adobe Character Animator(スターター)
Final Cut Pro
Vrew(無料)
フリーボード
Mac mini M2
BGM: オリジナル音楽

以上です。

2023.7.31：TwitterがXに移行。APIへの影響が不明。
2023.2.16追記：TwitterAPIの有料化の発表がありましたが、投稿bot1500個までは無料化へ自動移行とのことで、多くの場合、問題なさそうです。
2022.5.13更新：Twitterを追加。無料使用に留める場合は、API v2を利用すること。

＜分散通知をスマホから実行する＞
別ページで表示

メールとブログを含めるとSNSよりソシアルメディア(Social Media)という方が正しいのでしょうが、単語として分かりにくいので、ここでは「情報を配信するツール」としてSNSと呼ばせてもらいます。

さて、昨年5回に亘って、「分散通知の仕組みを作る」として、電子メール、LINE、Push7、Bloggerのそれぞれへ、アプリを開かないで送信する仕組み、を説明しました。

しかし、スマホで操作すると、GoogleスプシをChromeのPCサイトから扱う、という方法は非常に扱いづらいことは分かっていました。

今回、それを、かなり実用的に改善しましたので紹介します。

実は、AppSheetとGASの連携については、Google内で開発が進んでいますので、半年先には、もっと簡単に色々できるようになっているかもしれません。

しかし今回私が改善したいこと自体が、さほど、高度な技術を要求することでもありませんので、現状の技量でアプローチしてみます。

ポイント解説

＜1＞ 人の手作業は、文を作成修正する→送りたいSNSを選び送信する、ただそれだけ。

前回の通知方式では、SNSアプリ別にGoogleSSとGASを組み合わせて、GoogleSSを立ち上げて内容を確認して、送信ボタンを押す、これをSNSアプリ毎に行う方式でしたが、今回は、GoogleSSは一つのファイルにして、その中へ、GASを各アプリ別に組み込む、という方法にしました。

その各アプリ別のGASは、前回の通知方式で作ったものを、ほぼそのまま流用しています。
作業手順は以下のようになります。

＜作業手順＞
別ページで表示

前回は、各GoogleSSを立ち上げて、投稿ボタンを押す、これを繰り返すという手間がありました。それがAppSheetの以下の２つのメニューで完結するようにしました。なお、AppSheetについては、こちらの投稿の中で、概略触れています。解説している日本語の書物は殆ど見かけませんが、唯一これくらいです。使っているうちにだんだん慣れてくるとは思います。

AppSheetアプリの実際の動きは、以下の動画をご覧ください。

このビデオは無音です。Twitterは組み込む前です。

以上のような動きになりますが、その中で、通知の作成及び修正の画面が以下です。追加または修正した行が、通知の送信の対象となります。ですから、今現在適当なテスト内容になっていますが、例えば、「避難情報通知用」などテンプレートとして用意しておくのもいい方法です。

上図を表示しているデータは、以下です。sheet1には順次新しい投稿が書き込まれて、それを更新日時でSORTしたものがsheet2へ入り、その最新行からsheet3をコピーしています。

「拡張機能」→「Apps Script」の中に記述したスクリプトは、全部掲載します。

複数SNSの送信GAS

＜２＞　Twitterを使えるようにする。

Twitterですが、災害発生時には最も実績のある情報発信ツールであることは、東日本大震災他大災害の時を振り返れば明らかです。ただ、利用者が多いからか、イタズラや不正利用を防止せねばならず、APIのような、外部からアクセスできるツールに対する許可は、敷居が高い印象がありました。

しかし、申し込んでみると結構すんなりいけます。最近、APIが、APIv1.1からAPI v2にバージョンアップしました。どうもAPI v2から直接使う方法が分かりにくく、色々調べて、TwitterAPI v2をEssentialからElevated(無料）へ引き上げる方法が良さそうです。

引き上げる際に、許可が必要で、用途に関する質問に英語で返答する必要がありますが、簡単な英語で書いても大丈夫かと思います。数多く解説のブログが書かれていますが、例えばこのブログは分かりやすいです。

引き上げておいて、
OAuth1.0aのみにチェック
OAUTH1.0A SETTINGS でRead and writeにチェック
CallbackURI/RedirectURL ,WebsiteURL,Terms of service,Privacy policyは、https://twitter.com
と設定します。

Twitterは、同一内容の複数投稿は拒否するようです。その辺りは、GoogleSSのカラムに前回の投稿内容をコピーして今回の投稿内容と比較して、同じ場合は、tweet.gs内でルーチンを通さないようにしました(上のGASを参照）。

＜３＞　AppSheetで作ったアプリはプロの仕上がり感

AppSheetは、各SNSのロゴをイメージとして読み込んで表示するだけのことですが、上の図のように、プロが作ったようなアプリになります。そこが素晴らしい。

課題点というか仕方ない点としては、各SNS別に送信履歴を残していない点です。これはまあ、各アプリ側では当然履歴として残っていますのでそれで十分でしょう。

現状は、各SNS側の画面から通知文の修正は出来ないようになっています。しかし、基本となる通知文を作った後で、それを各アプリ側でコピーして、各アプリ側で修正して送信する、という流れの方が素直かも知れません。
このあたりは、AppSheetとGASの連携の開発が進むと、すぐに可能になりそうです。しかしながら、今回のものでも、特に不便は感じません。

＜４＞頻繁にテスト出来ない悩み

この複数通知の仕組みを作って思う課題、課題というか悩みは、頻繁にテスト出来ないことです。なにしろ、緊急通知が目的ですから、滅多に通知なんか発信されるものではないです。テスト用にそれぞれIDやアドレスを作ったとしても、実用としては常に本番用のアドレスにしておかなければ意味がありません。そんなわけで、実際に全部テストできるのは、年に一度の「防災訓練の日」の活動の一環としてテスト送信させてもらう、ということになります。

そこがちょっと不便なところ。

でも多くの方は、そんな緊急発信のためではなく、いわゆる普通の「伝言板」「回覧板」的な使い方になると思いますので、十分、応用できると思います。

＜５＞まとめ〜中途半端な規模の人たちのために〜懸念材料

地方自治体で多いのは、「LINEに加入してアプリを入れて活用してください」型です。正直言ってLINEを嫌いな人もいるはず。しかし最近、だんだん、LINEに限定させず複数のSNSの中から、ユーザーが選択できる形式も増えてきました。

スタッフの充実した都市の役所や大規模組織なら色々そうした工夫ができるでしょう。逆に、本当に小さい規模なら電話一本、伝言でOKでしょう。しかし大多数は、そのどちらとも言えない中途半端な規模の自治会、中途半端な規模のNPO。公民館はあるが住み込みは置けない。電話もない。自治会としてインターネット契約をすることは結構面倒なので、個人に契約者になってもらおうとすると、その個人がいつまで肩代わりしてくれるか保証はない。そうなると、Googleなどのサービスも無料で使えるものが中心となります。そんな人たちのために、少しでもお役に立てば嬉しいです。

懸念材料としては、Twitter Botに有料化の動きがあること。GASやAppSheetの連携が自動化処理と見做されると停止されるか有料化されることを懸念します。つまり無料で使えるインターネットサービスは、減少していく方向にあるでしょう。

以上です。