淡水社の音声入力を育てる――Aqua VoiceとMCPの使いどころ

図解1｜AI活用、まず一語から

音声入力の改善は、目についた表記の揺れを一つ選び、何を直したいのかを確かめるところから始まります。

解説1｜困りごとは、認識と表記に分けて見る

ストーリー

淡水社でもAIを仕事に生かす取り組みが始まっています。シャケモンは、技術用語を話して入力するときの表記の揺れを相談します。コイ丸先輩は、用語を大量に登録する前に、まず一語で試すよう提案します。図の「パワークエリー」から「Power Query」への変更は、検討用の例です。淡水社の実際の音声入力履歴や設定変更の記録ではありません。

音声入力では、話した内容が文字になります。その結果が期待と違うとき、「語として認識しにくい」のか、「語は伝わったが表記を統一したい」のかで対処が変わります。前者なら専門用語を認識候補にする方法、後者なら特定の表記を置き換える方法を検討できます。文章全体の書き方や、実際に生じた誤認識の報告は、さらに別の役割です。

一件を選ぶ利点は、登録前の状態と次回の入力を比較できることです。まず元の入力、期待する表記、使用する場面を記録し、既存の設定にも同じ目的のものがないか調べます。改善したと判断するのは、設定を選んだ時点ではなく、次の入力結果を見てからです。

図解2｜音声入力と設定管理は別の経路

音声を文字にしてアプリへ入れる流れと、音声入力の設定を確認・調整する流れを分けて考えます。

解説2｜MCPは「声で会話する仕組み」ではない

Aqua Voiceの通常の役目は、人の発話をテキストにして、Codexやエディターなどの入力先へ渡すことです。一方、図の下段は、CodexなどのエージェントがAqua Voiceの情報やカスタマイズへ接続する、設定管理の経路を示しています。Aqua Voiceの公式MCP案内は、音声入力セッションやカスタマイズ、設定などにアクセスする手段としてMCPを説明しています。

二つの経路を混ぜると、「音声を入力しただけで辞書が更新される」「MCPをつなげば音声会話が始まる」と誤解しやすくなります。実際には、発話からテキストが届くことと、設定を読む・変更することは別の操作です。設定管理には接続や権限の確認も必要です。

淡水社の検討では、まず入力でどのような表記が必要かを確かめます。そのあと、設定の確認をCodexに任せる価値があるかを判断します。図の下段は可能な連携の設計図であり、淡水社のアカウントでMCP接続が完了したことを示すものではありません。

図解3｜直し方には、四つの置き場

同じ技術用語でも、何を変えたいかによって置き場所を選びます。

解説3｜辞書に何でも入れない

Dictionaryは、専門用語や製品名など、音声入力で扱いたい語を認識させるための候補です。Replacementは、入力結果を決めた表記へ直したいときの候補です。たとえば「パワークエリー」を「Power Query」に統一したいなら、まず現在の認識結果と既存の置換ルールを確認します。この例をそのまま登録するという指示ではありません。

Custom Instructionsは、文体や製品名の書き方など、文章全体にまたがる方針を持たせたいときに検討します。Feedbackは、実際に生じた誤認識をサービスへ知らせるためのものです。Feedbackを送っても、すでにアプリへ入力された文章がさかのぼって直るわけではなく、次回の認識改善も保証されません。

どの方法でも、Codexや既存スクリプトが同じ補正をしていないか先に調べます。役割を分ければ、どの設定が結果に影響したのかも追いやすくなります。

図解4｜登録前に、既存と比べる

既存の辞書や補正処理と比べ、必要な候補だけを残します。

解説4｜候補抽出は、登録とは別の工程

元ネタが提案するのは、記事・書籍・コード・過去の入力などから用語や誤認識の候補を見つけ、既存の仕組みと比べる流れです。候補を見つけた時点でAqua Voiceへ一括登録するという意味ではありません。過去の入力を分析する場合も、閲覧できる範囲と扱ってよい情報を先に確かめます。

シャケモンは、既存の用語資料や表記補正がどこにあるかを確かめます。同じ語がAqua VoiceのDictionaryにすでにあるなら、新規登録の候補から外せます。Codex側に置換処理があるなら、どちらが表記を整える担当かを決めます。コイ丸先輩は、確認と保守を続けられる量に絞ります。

たとえば「Power Query」が候補に出ても、認識自体が安定しているなら辞書追加は不要かもしれません。実際の誤表記が繰り返されるなら、原因と既存設定を確認してからReplacementを考えます。資料に載っているだけの語と、音声入力で困っている語を区別することが、重複や登録しすぎを防ぎます。

図解5｜送る情報の境界を決める

情報を選ぶ条件が先で、連携手段の選択はその後です。

解説5｜使える機能より、渡してよい情報を先に確認する

Dictionaryの候補や過去の入力には、仕事の情報が混ざることがあります。APIキーや認証コード、顧客の機密、個人情報、社内だけのURLなどは、辞書への登録や外部サービスへ渡す候補から除きます。「公開可能な一般用語だけを扱う」と決めれば、最初の試行範囲も明確になります。実際の資料を使う前には、会社の情報管理方針と利用権限を確認します。

連携手段にも役割があります。MCPはエージェントとの対話の中で情報や設定を確認する用途、CLIは確認済みの候補をまとめて処理する用途、APIは独自のプログラムへ組み込む用途として検討できます。Aqua VoiceはMCPとCLIを公式に案内しています。図は用途の比較であり、淡水社で三つとも導入する計画ではありません。

最初は、新しい連携方法を増やすこと自体を目的にしないのが現実的です。既存のスクリプトや設定が十分なら、候補を人に示すところまでで止めてもよいでしょう。必要な操作と、誰が確認するかを先に決めてから、手段を選びます。

図解6｜一件から試し、次回で確かめる

設定の追加を成果とせず、次の入力で意図した表記になるかを見ます。

解説6｜小さく試すと、次に何を直すか分かる

試行の一単位は、候補一件と、その後の入力結果です。Codexが候補と既存設定の差分を示し、人が「この語をどこで直すか」を決めます。必要なら選んだ設定へ反映し、次回の音声入力を確かめます。期待どおりでなければ、認識、置換、文章ルールのどこに原因があるかを再び分けて考えます。

まとめ

Aqua Voiceは話した言葉をテキストへ変える入口です。MCPなどの連携は、その入力環境を確認・整備するための別経路になり得ます。淡水社のようにAI活用を始める場面でも、まず既存の仕組みを確認し、情報の境界を決め、一件から評価する順序が適しています。図の流れは提案であり、連携や改善が実施済みという報告ではありません。

今回の仕掛け

用語を大量に登録する計画ではなく、「候補→既存との比較→人の判断→次回の確認」という閉じた小さな試行にしたことです。音声入力のたびに改善点を見つけられても、反映するかどうかは目的と情報の扱いで判断します。

参考：Aqua Voice MCP公式案内、Aqua Voice CLI公式案内。製品仕様は2026年10月15日に確認しました。