こんにちは．18日目のデフエンジニアの会アドカレはふじえもんがお送りします．
今日は2度目の記事で，前回は，初日に書きました！
まだ読んでない方はぜひ．コメントやリアクションなどいただけましたらとても嬉しいです．作った成果物はリポジトリにありますのでぜひお試しを．
今回も引き続き，開発したものについて紹介しながら最近考えていることや取り組んでいることについて共有できればと思います．
「聴こえに関係なく発言できる、伝わる環境づくり」を実現するために何ができるか
言語化のきっかけはRSGT2023への登壇と感想ブログの執筆
まず，自分は「聴こえに関係なく発言できる、伝わる環境づくり」に興味があります．
だから，デフエンジニアの会でデフハッカソンを企画したり，音声認識とか音声信号処理とかを絡めたアプリを作ったり，技術カンファレンスで情報保障の準備を担当したり，聴覚フェスティバルの運営をしたりと，こんな感じで機会と縁があれば，自分自身が楽しみながらどんどん挑戦させていただいています．関わって下さる方々に大感謝．
Xのプロフィールにも3, 4年ぐらい書いています．興味範囲もほとんど変わってない．
書き始めたのは多分RSGT2023に登壇してから，ぼんやり考えがまとまり始めてきたころだった気がする．
などと書いていて，ふとブログを遡ってみたら，3日目の記事の後半に書いた経緯とかをちゃんと書いてた．文量が多い．我ながらかなりの熱意がこもっている．
抜粋．
自分が目指すゴールとして、ハッカソン、就活等色々経験して考えていたことは「聴覚障害の有無に関わらず互いに伝え合い伝わる環境づくり」です。
目指す理由をざっくりまとめると、「議論の場が整備されないことには、まともな議論が成立しない。全員がその場にいる意味、目的が尊重されるために。そのための試行錯誤です。」
最終的に、noteに知見としてまとめ、議論の材料として情報共有できればと思います。結果、結論だけでなくそこに至るまでの過程も出来る限り出します。(自分のための備忘録でもある。だから時間かかってもガッツリ書きたいだけ書いた。)
学外のイベント、就活、企業に勤める、様々な場に応用することを目指して。
聴こえる聴こえない、話せる話せない関係なく、誰もが誰とでも伝え合えあい伝わる環境、場を。
多分，登壇後の交流で聴こえ方についていろんな方に説明したり議論しているうちに，これまで考えていたことが徐々に言葉になったタイミングだったんじゃないかなあ．
とても楽しかったです(言うまでもなく，きっと文量にそれだけの熱意，感動が現れていることでしょう)．
（残念ながら機会が合わず，今年だけでなく来年も顔を出しに行けそうにないのですが．．スクラムフェスや他の関連イベント，2027でお会いしましょう！）
ちなみに登壇内容の概要としては，Agile開発を学ぶ合宿中のグループでのワークで，多様な聴こえの学生が集まった中で起きた課題とそれを解決するまでの思考やプロセスを聴覚障害の多様性と絡めて発表させていただきました．スライドです↓字幕付き版はこちら．
ろう・難聴者にとって困るのは音声コミュニケーションにアクセスしづらいこと
そもそも，自分が難聴者としてどう音を聴いて，人と話しているのか，どんな困りごとがあるのかをちゃんと考え始めたのは大学に入ってからです．
入学してから，ろう・難聴者の知人が増え，さまざまな聴こえ方・コミュニケーションの形があることを知りました．医学モデルや社会モデルの違いを学び，日本語対応手話の勉強もしました．
それは世界が広がり，聴覚障害や己の難聴について解像度を高めるきっかけになりました．
そして，まだまだ，ろう・難聴者の生活ではさまざまな困りごとがあることを，自身のこれまでの経験や周囲の人との交流から気づきました．
とくに音声コミュニケーションに関する困りごとが多い印象です．
日常生活では様々な生活音，環境音，人の声が流れていて，聴覚障害の状況によっては音声情報へのアクセスが難しい場面に遭遇することが多いと思います．
このことは，声や音だけで情報を発信しているから，発信されている情報にアクセスできない人がいる，状況が起きると考えることができます．
例えば文字情報や，画像，映像など視覚情報，あるいは振動フィードバックによる触覚情報でも伝えることはできます．また，音声言語に限らず，手話や触手話でも伝達することができます．
もちろん，音声だけでしか情報発信できない事情(ヒト・カネ・モノ)や理由があるかもしれません．
一般に，音声で伝えればほとんどの人にはたいてい伝わるかもしれませんが，それは音声情報にアクセスできる人がたまたま多かったから，音声で発信しているにすぎないんだと思います．
そんなわけで，音声コミュニケーションにおける課題について考えるようになりました．
いろいろアプローチはあると思います．
ぱっと思いつく，自分が普段から取り組んでいるものだと
音声認識を使い，音声情報から文字情報へと文字起こししたり，
補聴器を使い，音量を大きくしたり，聞き取りやすいように雑音を抑えたり，人の声を強調したりすることで困りごとの程度が緩和したり解決するかもしれません．
前置きはこれぐらいにして，そろそろこの記事の本題に入りましょう．
以降は，せっかくなのでエンジニアらしく，アプリをつくることで課題解決を目指している過程について紹介します（もちろん，モノを作らずとも，人と人とのルールや理解で解決できることもあると思います）．
どなたにでも活用いただけるように，各々，リポジトリを公開しております．
使い方や仕組みの詳細は各リポジトリのREADMEやドキュメントにありますのでご興味があればまずリポジトリを見ていただけると幸いです．なにかお気づきの点があればDMやIssueで教えてください．もちろん感想やアイデアもお待ちしております！
インターネットに接続することなく，PiP(ピクチャーインピクチャー)表示で文字起こし結果を確認できるasrivia(あすりびあ)
asriviaの使用シーンとしては，たとえば，個人使用の範囲や文字起こしアプリの使用許可を得た上で，音声情報にアクセスする際に，自分の手元で文字情報に変換して，情報を受け取りたいときに使えます．
Blackholeなどの仮想マイクを使って，このアプリに音声入力すれば，PC上で流れている音をこのアプリで認識させて文字起こしできます．
UIはこんな感じ．上がメイン言語だけのとき．下がメイン言語と翻訳言語のとき．
フォントサイズもボタンポチポチしてその場で変えられます．
デフォルトの配色はシンプルにコントラスト比が最も高く見やすい黒背景&白文字にしています．
音声認識モデルはWhisper
優れた音声認識のAPIは色々ありますが，インターネットが必要だったり，使った分に応じて支払いが生じることがあります．また文字起こしのアプリもいくつかありますが，長くなるので割愛します．
このリポジトリでは，Whisperという3年ぐらい前にOSSで公開された音声認識モデルを使って，ローカルで文字起こしを行って，PiP表示しています．
オリジナルのOpenAIから出ているモデルでもいいですし，Appleシリコン搭載のMacをお使いであればmlxにより最適化されたモデルが使えます．一応どっちも対応してますので，モデルさえダウンロードいただければ使えるはず．
どうWhisperを動かすかは実装を見ていただいたり，すでにそういう解説記事は世にありふれているのでそちらに譲ります．
PiP(ピクチャーインピクチャー)表示はTkinter
PiP表示は，常に最前面にすることで，ほかのアプリの上に重ねて表示することができる表示方法です．
TkinterベースでUIを作っています．シンプルな画面でお気に入り．
PiP表示をする処理の一部です．字幕表示のためのサブウィンドウです．このウィンドウだけ表示しています．
Toplevel()で最前面表示を実現しています．Tkinter8.5リファレンスはこちら．
def start_pip_window(result_q, stop_ev):
pip = tk.Toplevel()
pip.title("asrivia")
pip.geometry("500x110")
pip.attributes("-topmost", True)
pip.attributes("-alpha", 1.0)
font_size = tk.IntVar(value=14)
text_label = tk.Label(pip, text="認識結果がここに表示されます", font=("Arial", 14), wraplength=480, justify="left")
text_label.pack(pady=10)
# 翻訳結果も同じラベルで表示、文字色を白に変更
translate_label = tk.Label(pip, text="", font=("Arial", 12), fg="white", wraplength=480, justify="left")
translate_label.pack(pady=5)
メイン関数の処理の一部です．字幕だけ表示させたいので，ルートウィンドウを隠しています．
root = tk.Tk()
root.withdraw()
翻訳はPlamoで
日本語-英語間で翻訳ができます．Plamoを使っています．開発者の環境(M4Max, 128GB)では4秒ほどのラグがあるのでなんとか改善したいところです．しばらくは認識だけ使っていただくのがいいかもしれません．
課題と展望
課題
- 無音であることを示す
- Whisperの認識結果には，無音の場合ハルシネーションが起きて関係ない文字列が表示されることがあるので．例えば「ありがとうございました」など．YouTubeの最後の無音部分にこの文字列を字幕に入れていたりするのが原因（だった気がする）．
- 翻訳時の遅延を減らす
- いわずもがな
- 日英以外の言語でも翻訳できるようにする
- トライしてるんですが，翻訳エラーにうまく対応できていないのでお蔵入り．そのうち．
- ログとして認識結果を記録できるようにする
- 認識結果が枠外へはみ出して表示されないようにする
展望
-
基本的に最も大きなモデルが一番高精度なのですが，その分計算資源を使うことになるので，小さなモデルでもいい感じに認識したいところです．これは提供元が頑張るところでもありますが，開発者としてアプリ側でなにか工夫したいところです．
-
認識用の端末を親機として用意しておいて，何かしらの方法で通信して，1つ以上の子機に認識結果を共有して表示する仕組みがあると，イベントとかでの字幕表示に使えるかもしれません．
-
やはり確率で最もそれっぽい文字列を出しているに過ぎないので，音声の状況によっては誤字脱字が起きることがあります．これは避けられません．じゃあどうやって解決するか．いろいろありますが，音声認識モデルの学習・調整→音声入力→音声認識後の順で見ていくとこんな感じで考えられそう．
- 音声認識モデルの調整が直接できれば単語登録などの仕組みを用いて，優先して表示させたい文字列を出したり，話者の発話に合わせて学習させるのも1つの手です．Whisperは単語登録は(プロンプトを使って少しだけそれっぽいのができるぐらいでちゃんとしたものは)出来なかった気がする．ただ最近WhisperのPEFT(Parameter-Efficient Fine-Tuning)をサポートしたリポジトリを見かけたのでそのうち試してみる予定です．
- 音声入力環境を整え，認識させたい音声だけを入力あるいは取得するようにすることも一つの手です．指向性マイクを使ったり，アプリ側で前処理をして音声だけ取り出したり．あとは綺麗に発話して認識させられる人がいればリスピークとか．
- 認識結果をいじって，より正しいと思われる修正候補を出すことを最近は考えています．以下に続く内容がそれです．
余談-自分の環境でどのモデルを使えば良さそうか参考になるasrlance(あすらんす)は音声認識性能を比較評価できます
「あすらんす」は音声認識性能を比較評価するツールです．音声ファイルパスと正解文を実行時に入力することで，認識精度（マイクロCER），処理にかかった時間，CPU使用率を結果として出力します．
最初は，Whisperの一番大きいモデルだけを扱っていたんですが，ほかのモデルにも対応出来たほうがいろんな人が使いやすいよね，じゃあどのモデルを使えばいいか，把握して選べるときの参考になるといいよね，で作ったものです．
ほんとに必要最小限ではありますが，少し便利になります．
リアルタイムで文字起こしして修正した文字列を以降も自動で修正してくれるOtoreco(おとれこ)
Whisperとか重いモデルを手元で動かせなかった時期に試作したものです．
WebSpeechAPIを使ってブラウザ上で日本語認識しています．
文字列マッチングという，該当する文字列があるかを全認識結果から探して，一致すれば指定の文字列に置換するようにしてみました．
GitHub Pagesとして公開しているのでお手元ですぐに触っていただけます．
https://shotafujie.github.io/Otoreco/
操作手順
- 修正したい文字列を範囲選択する
- 「修正を適用」するボタンを押下する
- 表示されたテキストエリアで適用したい文字列を入力する
- OKボタンを押下する
- 上記の操作で修正結果が適用されます．
- また以降も修正対象の文字列は自動で置換されます．
- 置換対象の文字列は認識結果表示欄の下で確認できます．
このあと試したいこと
- もう少し賢く修正提案してほしい
- 日本語だと同音異義語があるのでうまく対応したい
- ある程度曖昧に，ファジーに修正対象を見つけられると嬉しいかもしれない
ということで，これは9ヶ月ぐらい前に作ったもので，自然言語処理周りの知見が無いので，勉強してアイデアを貯めている最中です．
進捗があればまた共有します．
Whisper等の音声認識結果を賢く修正するためのGUIツールPredy(ぷれでぃ)
Otorecoと似たものです．Whisperによる認識結果を対象に試行錯誤しています．
Claude Codeとやらをプライベートでも導入し始めたので早速助けてもらっています．
今は，Levenshtein距離による類似度計算を行ってCSV辞書ベースの専門用語マッチングをしています．あらかじめ専門用語や認識させたい文字列をCSVにまとめておいて，それを参照しながら誤認識の可能性がある文字列を検出しています．
検出部分はオレンジ色でハイライトされます．
修正前．例だと「機械学習関連」を「機械学習」の誤りだと検出しています．
(よく見るとほかに検出して欲しい箇所はありますが，残念ながら検出されませんでしたorz)
最大3つまで修正候補が表示されるので，マウス操作やキーボード操作で選びます．
修正後．反映されました．アプリ画面右下に検出結果が出てますが，件数が変わりましたね．
Vim風に楽にキーボード操作できる
このアプリは修正を楽にするためのアプリです，
なので，なるべくキーボードだけで操作が完結できると嬉しいと考えたので，Vim風に，特定キーでモードを切り替えたり，検出箇所の移動ができたり，UndoRedoができたりするようにしました．
Mac側のキー入力と干渉したりして，いろいろ大変でした．．ありがとう，Claude．
辞書エディタ
そして，そのCSVの編集を楽にするために辞書エディタ機能もあります．
Ctrl+Eを押下すると，辞書を編集できる画面が別で開かれます．追加，保存，削除ができます．
テストデータは機械学習関連の用語が入っています．
CSVを直接編集してもいいし，アプリを使いながらリアルタイムでCSVを編集することもできます．
今後の展望
- 最近，ローカルLLMを呼び出してなにかすることにハマっているので，たとえばローカルLLMを裏で立ち上げて置いて，ある程度まとまった文量を渡して修正提案させたりとか
- 日本語のトークナイザーSudachiのPython版も気になっています．形態素解析した上でなにかできそう．以前はkuromojiとか使ってました．
PerplexityやClaude Codeで情報収集や開発が爆速になった今，自分は何を考えて生きるべきか
さて，そんなこんなで4つほどここ半年ぐらいで作ったものを紹介してきました．
日が変わるまであと10分しかないのでここからは短めに．
詳細はもう少しまとまってから別日に出せれば思いますが．
簡潔にいえば，アイデアを実現することが楽になったのかなと思います．
なので，日頃から感じている課題を書き留めておき，アイデアとして温まったら形にする．それを繰り返すことで開発者としてなにか成長できるのかもしれません．これは今試しているところです．
昨日まで代表のmaminekoさんが三部作で熱い記事を書いてくださっています．
最後に，以下の言葉で締めています．概ね同意です．
AI時代のエンジニアは、不要になるのではなく、より重要になる。
なぜなら、
第1部で見たように、現在のAIには限界がある
第2部で見たように、AIを使いこなすには人間の判断が必要
第3部で見たように、完璧なAIが登場しても人間にしかできないことがある
つまり、どの段階でもエンジニアは必要です。
変わるのは「何をするか」であって、「必要かどうか」ではありません。
AIに仕事を奪われる・・と思うのではなく、AIを使いこなして、より価値の高い仕事ができるようにしよう、と考える。
それが、これからのエンジニアの生き方になるのではと私は考えています。
価値を提供するためにモノづくりをしているので，顧客の課題が何なのかを聞き出し，要件に落とし込み，それを楽に実現・解決するエンジニアリングをすることに変わりはなく，それが速くなったに過ぎないのだと思います．
以上！
あとがき
ホームページもありますので，ご興味あればご覧ください．
近々，見た目を刷新して，より面白いサイトにする予定です．デザイン力が欲しい．
今日の記事は昨日朝に思い立って，退勤後に3時間ぐらいとっっても頑張って書き上げました．
久々に締切駆動執筆できて楽しかったです．
来年も面白いことにどんどん挑戦していきます．
ご縁があればどうぞよろしくお願いします！
ここまで読んでいただきありがとうございました！