海外との商談が増えて、困っていたこと
僕はエンジニアではありません。株式会社コホマダという会社で、海外企業の日本市場参入と、日本企業の海外展開を支援しています。前回、Claude Code で自社サイトを作った話を書きました。今回はその続きではなく、まったく別のものを作った話です。
仕事柄、海外との打ち合わせが多くなりました。英語が中心ですが、ポルトガル語の商談もあります。先日は101分、通訳を挟んで話しました。
先に断っておくと、これから作るものは「翻訳がないと商談できない」から作ったのではありません。通訳が必要な場面には通訳に入ってもらいますし、英語の打ち合わせは普通にやっています。そこは仕事なので、機械に任せる話ではない。
困っていたのは、別のところでした。
通訳が訳さない部分がある
直近でポルトガル語の案件がありました。通訳に入ってもらったので、本題は問題なく理解できます。そこは通訳の仕事で、正確にやってもらえます。
ただ、通訳が訳すのは本題です。
話の合間にこぼれる一言や、本題から少しそれた雑談まではカバーされません。それは通訳の職分の外なので、当然のことです。
問題は、そこに大事なものが混ざることでした。
「うちも似たことで困っていて」「前に一度やって失敗した」。そういう一言は、たいてい議題から外れたところで出ます。日本語の商談なら確実に拾って、その場で掘り下げているはずの場面です。
それが、訳されないまま流れていく。あとで議事録を見ても、そこは要約されて消えているか、そもそも記録に残っていません。
拾いたかったのは、ここでした。
議事録は残る。でも、その場では読めない
打ち合わせの録画と文字起こしは、ツールを入れて残しています。終わったあとに見返せば、何を話したかは分かる。
ただ、それは終わってから読むものです。
商談で本当に必要なのは、相手が話しているその瞬間に「いま何を求められたのか」を掴むことです。議事録は、そこには間に合いません。
そして外国語だと、この「その場で掴む」が一段むずかしくなる。聞き取ることに意識を持っていかれて、意味を組み立てる余裕が削られる。理解が半歩遅れて、こちらが考えている間に次の話に進んでいる。
トーンは、文字にならない
もうひとつ。同じ言葉でも、言い方で意味が変わります。
「それは難しいですね」を、切り捨てるように言ったのか、迷いながら言ったのか。後者なら、まだ余地があります。前者なら、そこは引くべきところです。
耳では、その差は分かります。日本語ならほぼ無意識に処理している情報です。ところが外国語だと、言葉を追うので手一杯になって、トーンまで意識が回らないことがある。
だから、言葉のほうを機械に引き受けてもらいたかった。文字は画面に出ているから、耳は相手の言い方に集中できる。そういう状態を作りたかったんです。
認識のズレに、あとから気づく
そしてこれが一番厄介でした。
その場では通じたつもりでいて、後日のメールで噛み合っていないことが分かる。「そちらが確認すると言いましたよね」「いえ、こちらが確認すると申し上げました」。
これは語学力の問題ではありません。省略された主語や、曖昧なまま流した条件が、あとで別の意味で立ち上がってくる。日本語同士でも起きることが、外国語だと確率が上がるだけです。
議事録を見返せば、どちらが正しいかは分かります。ただ、そのときにはもう一往復増えている。その場で「いま、こう受け取りましたが合っていますか」と確認できていれば、起きなかった話です。
欲しかったのは、補助輪でした
つまり僕が欲しかったのは、通訳の代わりでも、議事録の代わりでもありません。
その場で、いま言われたことを目で確認できる状態です。耳は相手の言い方に向けたまま、言葉のほうは画面で拾う。理解がずれていれば、その場で聞き返せる。
補助輪です。走るのは自分で、外れかけたときに支えてくれるもの。
構成としては、こうなります。
イヤホンで相手の声を普通に聞きながら、同じ音を裏で拾って、日本語にして画面に出す。
作ってみたら、動きました。ただ、そこまでに壁が5枚ありました。全部 macOS の壁で、コードの問題ではありませんでした。この記事は、その5枚の話です。
最初に、何を諦めたか
「ブラウザでできないの？」と最初に思いました。
できません。
macOS のブラウザは、自分のタブの音しか取れません。Zoom や Teams で鳴っている音には手が届かない。これは OS の制約なので、実装をどう変えても回避できません。
なので構成はこうなりました。
Zoom / Meet / Teams の音
│ ← ここだけネイティブ（Swift）
▼
音声の取り込み＋文字起こし
│ ローカルのTCP
▼
Node のサーバー（依存パッケージ 0）
│
▼
ブラウザの画面 ← 自分が見るのはここだけ
画面はブラウザです。音の取得だけ、どうしてもネイティブにせざるを得なかった。
壁① 「音を録る」が「画面を録る」に化ける
macOS でシステム音声を取る方法はいくつかあります。BlackHole のような仮想オーディオデバイスを入れる方法が有名で、実際このMacにはもう入っていました。
ただこれ、出力先を「複数出力装置」に切り替える必要があります。 イヤホンの音量調整が効かなくなったりする。会議の直前にオーディオ設定をいじるのは、正直こわい。
そこで ScreenCaptureKit を使いました。出力先を一切変えずに、鳴っている音だけ取れます。 聞こえ方が変わらないのが決定的でした。
ただし、ここで妙なことが起きます。
macOS はシステム音声の取得を「画面収録」の権限に含めています。
映像は要らないので、取得サイズは 2×2 ピクセルにしました。
let cfg = SCStreamConfiguration()
cfg.capturesAudio = true
cfg.width = 2; cfg.height = 2 // 映像は使わないので最小
実質なにも映していません。それでも OS から見れば「画面収録するアプリ」なので、メニューバーにインジケータが点きます。
これは仕様なので、受け入れるしかありませんでした。
壁② Info.plist は、置くだけでは読まれない
文字起こしには macOS 内蔵の Speech フレームワークを使いました。英語と日本語は端末内で完結するので、音声が外に出ません。商談の中身を扱う以上、ここは譲れませんでした。
利用には許可が要ります。Info.plist に説明文を書く、というのは調べればすぐ出てきます。
書きました。落ちました。
This app has crashed because it attempted to access privacy-sensitive
data without a usage description. The app's Info.plist must contain an
NSSpeechRecognitionUsageDescription key...
書いてあるのに「書け」と言われる。しばらく意味が分かりませんでした。
答えは、実行ファイルの中に焼き込む必要があるというものでした。.app/Contents/Info.plist に置いただけでは、この起動のされ方だと読まれません。
swiftc -O -parse-as-library MeetingCore.swift \
-Xlinker -sectcreate -Xlinker __TEXT -Xlinker __info_plist \
-Xlinker Info.plist \
-o "$APP/Contents/MacOS/MeetingCore"
この -sectcreate の一行です。これを消すと、また同じところで落ちます。
壁③ ターミナルから起動すると、必ず落ちる
焼き込んでも落ちました。
いろいろ試した結果、こういうことでした。
./MeetingCore.app/Contents/MacOS/MeetingCore # 落ちる
open MeetingCore.app # 動く
アプリとして起動されたときだけ、許可が通ります。 ターミナルから直接叩くと、同じバイナリでも拒否されます。
これは地味に困りました。open で起動すると、標準出力が拾えないからです。文字起こしの結果をどうやって受け取るのか。
結局、ローカルの TCP に流すことにしました。
// 音声認識の許可は、LaunchServices 経由で .app として
// 起動したときだけ通る。つまり stdout は使えない。
// なので結果はローカルの TCP へ流す。
Sink.shared.connect(port: port)
設計がねじれているように見えますが、そうせざるを得なかったという話です。
壁④ 許可ダイアログが、出てこない
裏方アプリにしたかったので LSUIElement を true にしていました。Dock に出ないアプリにする設定です。
起動しました。何も起きません。エラーも出ません。ただ黙って止まる。
原因は、許可を求めるダイアログが前面に出てこないことでした。裏方アプリなので、macOS がダイアログを前に持ってこない。ユーザーは何が起きているか分からず、アプリは永遠に応答を待ち続ける。
false に戻したら、普通にダイアログが出ました。
壁⑤ ビルドし直すと、許可が消える
これが一番きつかった。
コードを1文字直してビルドし直すと、画面収録も音声認識も、許可が全部外れます。
理由は署名です。このMacには署名用の証明書がありません。
$ security find-identity -v -p codesigning
0 valid identities found
証明書がないとアドホック署名になります。これは中身から指紋を作る方式なので、ビルドするたびに指紋が変わり、macOS が「別のアプリ」と判断して許可を破棄します。
つまり、直す → ビルド → 許可を取り直す、の無限ループです。1日に2回はまりました。
根本的には自己署名証明書を作れば解決します。ただ、その日はそこまで手が回らなかったので、調整しそうな値を全部起動引数に逃がしました。
--silence-gap 1.1 文の区切りとみなす無音の長さ
--speech-floor -50 声とみなす音量
--locale en-US 相手の言語
作り直さずに調整できるようにする。 対症療法ですが、これで止まらなくなりました。
動いたあとに出た、本当の問題
5枚の壁を越えて、音が取れて、文字にもなりました。
なのに、翻訳が出ない。
音は認識している。画面に英語も流れている。でも日本語にならない。
原因は、文の区切りでした。
音声認識は、喋っている途中の状態を細かく返してきます。それを「いつ1文として確定させるか」を自分で決めないといけない。最初は「無音が続いたら」という判定にしていました。
会議は間があるので、これで足りると思っていました。足りませんでした。相手が喋り続けると、いつまでも確定しない。翻訳に渡す単位が決まらない。
しかも無理に切ると、こういうものが出てきます。
a dozen all king the
これを翻訳すると「ダースオールキング」になります。壊れた入力からは、壊れた訳しか出てきません。
直したのは、文末を見るという一点でした。
// 認識器は句読点を付けてくれる。それを区切りの合図に使う。
const ENDS_SENTENCE = /[.!?。！？]["')\]]?\s*$/;
if (ENDS_SENTENCE.test(fresh) && !tooShort(fresh)) commit();
間だけで判断していた頃は、話し終えてから1.3秒待たされていました。文末で即座に切るようにしたら、待ち時間が消えました。
[123ms] Could you send us a quotation by Friday
→ 金曜日までに見積書を送っていただけますか
[492ms] We also need to confirm the delivery timeline before we sign
→ 契約に署名する前に納期を確認する必要もあります
速度の問題だと思っていたものが、区切り方の問題でした。
同じ文が2回出た
もうひとつ。確定した文が、次の確定にも丸ごと混ざって出てくることがありました。
「どこまで確定済みか」を文字数で覚えていたのが原因です。音声認識は、後から前の語を直します。句読点が付いたり、大文字になったり。すると前方一致が崩れて、「全部が新しい文だ」と誤判定する。
単語数で持つように変えたら、直りました。
// 文字列の前方一致で見ていたら、同じ発言が2回出た。
// 認識器は後から前の語を直すので、単語数で持つ。
if (words.length < SEG.done) SEG.done = 0;
const fresh = words.slice(SEG.done).join(' ');
こういうのは、動かしてみるまで分かりませんでした。
一番ヒヤリとしたこと
技術の話ではありません。
自分の日本語を英語にする機能をテストしていたときです。
入力：できます。ただ、納期については一度社内で確認させてください。
訳 ：However, please confirm the delivery date within the company.
読めますか。
「こちらが社内で確認します」が、「そちらが社内で確認してください」になっています。
日本語は主語を省きます。機械翻訳はそれを勝手に補うので、誰の行為かがひっくり返る。 これを商談で送っていたら、話が完全にすれ違っていました。
対策として、生成した英文をもう一度日本語に戻して、並べて表示するようにしました。
ENGLISH
We can accommodate you. However, we will confirm the delivery date
within our company.
日本語に戻すと：対応させていただきます。但し、納期につきましては
弊社にて確認させていただきます。
送る前に、自分で検算できる。
ちなみに主語を入れて「当社内で確認いたします」と書いたら、一発で正しく訳されました。AIの問題ではなく、入力の問題でした。
できたもの
core/MeetingCore.swift 356行 音声の取り込みと文字起こし
app/server.mjs 411行 区切り・翻訳・配信
app/ui.html 350行 画面
合計およそ1,100行。npm の依存パッケージは0個です。
環境は macOS 15.7、Intel の MacBook Pro。Xcode は入れていません（CommandLineTools だけでビルドできました）。
文字起こしは macOS 内蔵なので、追加費用はかかりません。英語と日本語は端末内で完結します。
画面はこうなっています。左に相手の発言と日本語訳、右に自分の返答と、その英語・ポルトガル語。上から下へ会話として読めます。
これから
正直に書いておくと、これは自分が困ったから作ったもので、商品として作ったものではありません。
いまの翻訳部分は、正式なAPIを使っていません。自分ひとりで使う分には問題ありませんが、人に渡すものにするなら、ここは正規のAPIに差し替える必要があると思っています。設計は差し替えられる形にしてあるので、作業自体は大きくありません。
もうひとつ。ポルトガル語の音声認識は端末内で完結せず、外に出ます。英語と日本語は出ません。自分の商談なら自分で判断すればいい話ですが、他社の商談を扱うものとして渡すなら、ここは説明しないといけない部分です。
そのうえで。
同じ困り方をしている方は、思ったより多いのかもしれない、とは感じています。海外とやり取りしていて、通訳を挟むほどではないけれど、相手の一言は確実に取りたい。そういう場面です。
将来的には、きちんと作り直して人にお渡しできる形にできたら面白いな、とは思っています。ただ現状は個人用の道具で、そのまま渡せるものではありません。API連携のところを含めて、見直すことがまだいくつもあります。
もし同じことで困っている方がいたら、コメントで教えてください。どこから手をつけるかの参考にします。
おわりに
エンジニアではない人間が、こういうものを作れる時代になりました。
ただ今回いちばん時間を食ったのは、コードを書くところではありませんでした。OSの都合と、それをどう回避するかの判断です。そこは AI に丸投げできませんでした。エラーメッセージが嘘をつく（「Info.plistに書け」と言われて、書いてあるのに落ちる）場面もありました。
そして最後にヒヤリとしたのは、翻訳が意味を反転させたことでした。動くかどうかより、間違ったまま動くほうが怖い。
使ってみて、はっきりしたことがあります。これは通訳の代わりにはなりません。相手の言葉には、機械が拾えない温度があります。言い淀みや、言い換えたときの間。そこに一番大事なことが入っていたりする。
結局これは、記録を残して、あとから自分の理解を確かめるための道具でした。走るのは自分で、外れかけたときに支えてくれるもの。最初に補助輪と書いたのは、そういう意味です。
同じようなものを作ろうとしている方の、時間の節約になれば嬉しいです。特に壁⑤（ビルドすると許可が消える）は、知らないと確実に溶かします。