生成AI×音声入力で仕事はどう変わる？Typeless 1,527件を分析

• Codex
• Claude
• AI
• 地方中小企業

生成AIを使っているのに、思ったほど仕事が速くならないと感じることはありませんか。そんなとき、モデルやプロンプトばかり見直していませんか。

結論から言います。私にとって、生成AIを仕事で使い切るには音声入力が欠かせません。大事なのは、文字を速く打てることだけではないんです。頭の中にある背景や迷いを、削らずAIへ渡せる。ここが大きいと感じています。

実際に調べてみると、TypelessのローカルDB全1,647行のうち、分析条件を満たした入力は1,527件（92.7%）。203日のうち188日使い、録音時間は合計17.66時間、入力後の文字数は257,454字に達していました。Claude Codeのログも調べると、人間による入力821ターンのうち79.7%が初手の後に続く入力だったのです。

見えてきたのは、長く始めて、短く仕上げるという仕事の型です。最初に背景や条件をまとめて話し、返ってきたものを見て短く直す。ただし、これは私一人の利用履歴です。音声入力が生産性を上げたと証明する実験ではありません。その線は引いたうえで、実際の数字から分かったことをお話しします。

私にとって、生成AIと音声入力は一つの仕事道具になった

まずお伝えしたいのは、音声入力が「たまに使う便利機能」から、AIへ仕事を頼むための入口に変わったことです。

「便利な入力方法」から「仕事の基盤」へ変わった

私はこれまで、いくつもの音声入力ツールを試してきました。その中で、いちばん使い勝手が良いと感じたのがTypelessです。結果として、ずっと使い続けています。

もちろん、第三者を交えた比較テストで一位を決めたわけではありません。私の端末、話し方、仕事、よく使うアプリとの相性についての評価です。そこは分けて考える必要があります。

使い始めたころは、メールやメモを少し速く書ければ十分だと思っていました。でも、生成AIが調査、資料作成、文章編集、データ分析、コード編集まで担うようになると、音声入力の意味が変わりました。

文章を作るだけではありません。調べてほしいことを伝え、迷っている点を相談し、画面を見て修正を返します。つまり、音声入力がAIとの仕事を始めるスイッチになったんです。

今回、Typelessのローカルデータベースを読み取り専用で集計しました。すると、対象期間203日のうち188日で使っていました。利用率は92.6%です。分析対象1,527件の録音時間は合計17.66時間。入力後の文字数は257,454字です。

毎朝「今日も音声入力を使うぞ」と決めていたわけではありません。カーソルを置く。話す。AIの返答を見る。また話す。それが、いつの間にか普段の動作になっていました。

意識しないほど自然に使える道具は、仕事の基盤になりやすい。188/203日という数字を見て、私はあらためてそう感じました。

音声・画面・キーボードを使い分ける

では、何でも声で入力すればよいのでしょうか。私はそうは思いません。

長い背景説明や、まだ整理できていない考えは音声が向いています。固有名詞、数値、コード、URLのように、一文字ずつ正確に扱いたいものは、キーボードで入力すると確認しやすくなります。そして、AIが作ったものは画面で見ます。

• 音声：背景、意図、迷い、違和感をまとめて渡す
• 画面：成果物を見て、目的との差を見つける
• キーボード：正確な文字列や細かな箇所の確定

この三つは競争相手ではありません。場面ごとに役割が違います。

たとえば、提案書を作るなら、最初に相手の状況や今回の狙いを話します。初稿が出たら画面で確認し、「この表現は少し強い」「2ページ目の数字を再確認して」と声で返し、最後に会社名や金額をキーボードで確定します。こうすると、仕事が途切れにくいんです。

カンマンでCodexを使ったブログ制作をどう組み立てているかは、Codexと音声入力を使ったブログ制作の実践記事でも紹介しています。音声に調査、執筆、確認、修正を組み合わせる考え方です。

数字が教えてくれたこと、教えてくれなかったこと

今回の数字から確認できたことは三つです。

• 私はTypelessを長い期間、かなり継続して使っていた
• 長い入力と短い入力には、違う役割があるように見えた
• Claude Codeでは、初手の後にも入力を重ねる使い方が多かった

一方で、分からないこともあります。音声入力を使わなかった同条件の日との比較はしていません。作業時間、成果物の質、売上への影響をそろえて比べた実験でもありません。

ですから、「音声入力で生産性が何倍になった」とは言えません。ここは大切です。

ただ、私自身は、音声入力がないとAIへ渡す情報が減ると感じています。気づいた修正を後回しにすることも増えます。頭の中で考え続け、AIに相談する前に疲れてしまうこともある。

実測データは、そうした私の実感と矛盾していません。ただし、因果関係の証明ではありません。この記事では、この境界を守りながら数字を読みます。

2つのログを読む前に知っておきたい違い

ここで、集計方法を先に整理します。少し地味ですが、数字を誤解しないために欠かせない部分です。

Typelessでは「実際に話した時間」を測った

Typeless側は、端末内のローカルデータベースに残る履歴を使いました。対象期間は2026年2月5日から8月26日です。入力原文を外部サービスへ送りません。日時、録音時間、入力後の文字数などをローカルで集計しました。

このデータの良いところは、話した長さを推測しなくてよいことです。10秒未満、10〜60秒、1分以上という区分は、実際の録音時間に基づいています。

ただし、Typelessの履歴がすべて生成AIへの入力とは限りません。メール、文書、メモなど、AI以外への入力も含まれます。

もう一つ、会話を識別するIDもありません。そこで、前の入力から30分以上空いたら新しいまとまりと考えました。そのうえで、最初の入力を「セッション先頭」、続くものを「後続入力」としています。

この方法で分かれたのが、セッション先頭607件と後続入力920件です。あくまで30分間隔から推定した区分で、実際の会話単位と一致するとは限りません。

Claude Codeでは「対話の順番」を測った

Claude Code側は、ローカルのセッションログから人間が入力したターンだけを抽出しました。対象期間は2026年7月14日から8月28日です。ただし、7月24日以前は一部のセッションが失われています。期間の前半は完全ではありません。

ログには、人間の入力だけでなく、自動実行、通知、スキルが差し込む文章も混ざっています。そこで、人間由来と判断できるログ属性を使いました。さらに、長い貼り付け文、ファイルパスやURLだけの入力を分けています。

その結果、人間の入力は821ターン、167セッションとなりました。このうち、通常の会話に近い文章として長さを見たものが663ターンです。

Claude Codeのログからは、初手か、その後の追撃かを確認できます。でも、その入力がTypelessだったのか、別の音声入力だったのか、キーボードだったのかは分かりません。

そこで、文章の文字数を350字/分で話した場合の秒数に置き換え、10秒未満、10〜60秒、1分以上へ分けました。これは長さを見るための目安です。350字/分は分析用の仮定で、私の実測速度ではありません。

それぞれのログ内の変化を見る

2つのログを表にすると、違いがよく分かります。

観点	Typeless履歴	Claude Code対話ログ
対象期間	2026-02-05〜2026-08-26	2026-07-14〜2026-08-28
分析対象	DB全1,647行のうち条件を満たす1,527件（92.7%）	人間821ターン、うち文章系663ターン
長さの基準	録音時間の実測	350字/分による代理換算
音声かキーボードか	Typeless入力なので音声	識別不可
セッション内の位置	セッション先頭・後続入力（30分区切りの推定）	初手・追撃（セッションログ上の順番）
主な欠損・限界	AI以外への入力を含み得る	期間前半の一部欠損、入力手段不明

ですから、「Typelessでは1分以上が12.6%、Claude Codeでは1.2%だった。だから使い方が変わった」とは言えません。対象期間も、対象となる入力も、長さの測り方も違うからです。

では、何を見るのか。

Typelessの中で、セッション先頭と後続入力がどう違うか。Claude Codeの中で、初手と追撃がどう違うか。この二つを別々に見ます。

すると、測り方が違う二つのログで、どちらも「最初は比較的長く、その後は短くなる」という方向が見えました。私はこれを、長く始めて短く仕上げる仕事の型を考えるための仮説として扱っています。

Typeless 1,527件で分かった、長い入力の意外な重み

ここからが、実際の結果です。まず驚いたのは、使った回数よりも「長い入力が占める時間」です。

203日のうち188日、合計17.66時間使っていた

対象期間は2026年2月5日から8月26日までの203日間です。そのうち、Typelessを使った日は188日。条件を満たした分析対象は1,527件で、録音時間は合計17.66時間、入力後の文字数は257,454字です。

かなり使っている自覚はありました。それでも、203日のうち188日という数字を見ると、想像以上です。仕事のある日だけでは収まらないくらい、日常の入力に入り込んでいました。

長さ別に見ると、次のとおりです。

• 10秒未満：596件、39.0%
• 10〜60秒：739件、48.4%
• 1分以上：192件、12.6%

全体の87.4%は1分未満です。普段の音声入力は、数秒から数十秒の小さな入力が中心だったんです。

次の図には、利用量、件数と録音時間の構成、月別の1分以上入力比率をまとめています。

図1：TypelessローカルDB全1,647行のうち、完了済みで本文と録音時間を確認できる1,527件（92.7%）を読み取り専用で集計。録音時間は実測で、月別比率は各月の分析対象に占める1分以上の割合です。

月別に見ると、1分以上の入力比率は6月19.4%、7月19.2%、8月18.3%です。6月以降は高い状態が続いています。これだけで上達や改善を断定はできません。ただ、利用期間の後半に、長く話す場面が増えていたことは確認できました。

192件の長い入力が、録音時間の67.9%を占めた

ここが、今回いちばん印象に残った数字です。

1分以上の入力は192件。件数では12.6%しかありません。ところが、録音時間では67.9%を占めていました。

一方、10秒未満は596件で、件数の39.0%。録音時間では5.6%です。10〜60秒は739件で、件数48.4%、録音時間では26.4%です。

つまり、短い入力はよく使う。でも、実際に声で多くの情報を渡していた時間は、少数の長い入力に集まっていたわけです。

これ、回数だけを見ていたら気づきません。

短い入力は、ちょっとした修正や確認に向きます。長い入力は、背景、条件、迷い、判断材料をまとめて渡す場面に向きます。役割が違うんです。

少数の長い入力が、総録音時間の大半を占めていた。だからといって、毎回長く話す必要はありません。複雑な仕事を始めるときに、長く話せることに大きな意味がある。私はそう受け取りました。

セッション先頭は長く、後続入力は短かった

30分間隔から推定したセッション内の分布を見ると、役割の違いがさらに分かりやすくなります。

Typeless入力	10秒未満	10〜60秒	1分以上
セッション先頭（30分推定、n=607）	32.3%	46.3%	21.4%
後続入力（30分推定、n=920）	43.5%	49.8%	6.7%

セッション先頭では、1分以上が21.4%あります。後続入力では6.7%まで下がりました。反対に、10秒未満は32.3%から43.5%へ増えています。

私の実務でも、最初に背景を話し、その後は差分だけを返すことが多いです。「もう少しやわらかく」「この数字を確認して」「対象を経営者に変えて」。同じ仕事を画面で共有できていれば、それで通じます。

もちろん、30分区切りは推定です。TypelessにはAI以外への入力も含まれます。それでも、同じTypeless履歴の中で、セッション先頭607件と後続入力920件の長さの構成が違っていた。この事実は残ります。

長く話す目的は、プロンプトの長文化ではありません

「では、長いプロンプトを書けばよいのか」と思うかもしれません。そこは少し違います。

長さそのものを目標にすると、必要のない説明まで増えます。AIへ渡したいのは、判断に必要な文脈です。

たとえば、まだ結論が出ない理由。候補を選び切れない背景。過去にうまくいかなかった方法。誰が成果物を読むのか。どこまで決まっていて、何が未確認なのか。

こうした情報は、キーボードで整った依頼文を書こうとすると削りがちです。「うまく説明できないから、もう少し考えてから頼もう」と止まってしまうこともあります。

音声なら、「まだ整理できていないのですが」と言って、そのまま考え始められます。生成AIには、散らかった材料を整理してもらえばよいんです。前提と仮説を分ける。足りない条件を質問してもらう。次に決めることを並べる。

考えを一緒に整える。これが、長い音声入力の使いどころです。

Claude Code 821ターンで見えた、追撃で仕上げる仕事

次はClaude Codeです。こちらで見えたのは、一度で完璧に頼むより、返ってきたものを見ながら仕上げる姿です。

167セッションのうち64.1%は2ターン以上続いた

Claude Codeのログでは、人間による入力821ターンを167セッションで確認しました。1セッションあたりの平均は約4.9ターンです。

全821ターンのうち、初手ではない入力は654ターン。割合にすると79.7%です。また、2ターン以上続いたセッションは107/167、つまり64.1%です。

この二つは、同じ意味ではありません。79.7%は全ターンのうち、初手以外が占める割合です。64.1%は167セッションのうち、2ターン以上続いたセッションの割合です。

それでも、一度依頼して終わる使い方より、入力を重ねる仕事が多かったことは分かります。

私の実務では、AIの返答や成果物を見てから、修正、追加、確認、承認を返します。最初から完璧なプロンプトを作ろうとすると、依頼前の準備が重くなります。でも、実物を見なければ分からない違和感もありますよね。

初手は仕事の出発点。追撃は、その仕事を目的へ近づけるレビュー。こう捉えると、AIとの対話がずっと始めやすくなります。

CodexとClaude Codeの運用の違いは、Claude CodeとCodexの自動化を比較した記事でも紹介しています。どちらを使う場合でも、成果物を見ながら方向を直すことが品質確認の土台です。

文章系663ターンでは、追撃ほど短くなった

821ターンのうち、貼り付けやパスだけの入力などを除いた文章系は663ターンです。この663ターンを、350字/分で話したときの長さへ換算しました。

全体では、10秒未満相当が62.1%、10〜60秒相当が36.7%、1分以上相当が1.2%です。

先ほど整理したとおり、Typelessとは直接比較しません。ここではClaude Codeログの中で、初手と追撃の変化だけを見ます。

Claude Codeの文章系入力	10秒未満相当	10〜60秒相当	1分以上相当
初手（n=78）	33.3%	62.8%	3.8%
追撃（n=585）	66.0%	33.2%	0.9%

初手78ターンでは、10〜60秒相当が62.8%で中心だったんです。追撃585ターンになると、10秒未満相当が66.0%へ増えています。

Typelessとは物差しが違います。それでも、それぞれのログの内部では、最初より後の入力が短くなる方向が共通していました。

次の図は、二つの変化を同じ色で並べたものです。左右の割合を比べるのではなく、Typelessの中の変化とClaude Codeの中の変化を別々に見てください。

図2：Typeless側はセッション先頭607件・後続入力920件（30分推定、録音時間を実測）。Claude Code側の棒グラフは文章系663ターン（初手78・追撃585）を350字/分で換算し、下段の821ターン・167セッションは全人間ターンの集計です。対象・期間・測定法が異なるため、左右の割合は直接比較できません。

短い追撃がレビューになる

短い入力が多いと、「雑な指示が増えただけでは」と感じるかもしれません。私は、そうとは限らないと思います。

AIが返した成果物を画面で見ていれば、共通の対象があります。だから、直したい差分だけを伝えればよいんです。

文章なら、冗長な段落や抜けた前提が見えます。資料なら、余白や文字量が見えます。Webページなら、折り返しやボタンの位置が見えます。「2段落目を半分に」「この余白を広げて」「ボタンの文言を具体的に」。短くても、対象がはっきりしています。

ここで必要なのは、長い説明力より観察力です。受け取って終わりにせず、目的との差を見つける。その違和感を、忘れる前に声で返す。音声入力は、この小さなレビューと相性が良いんです。

ただ、短い追撃を重ねても収束しないことがあります。そんなときは、一度止まります。そして、目的、対象者、完成条件を長めに言い直す。短く返し続けることも、長く話し続けることも、目的ではありません。

AIとの仕事は、一括発注より運転に近い

従来の外注では、依頼書を渡して完成品を待つ形が多くありました。生成AIとの仕事は、もっと連続的です。

AIが作業している途中に情報を足す。方向を直す。次の作業を頼む。確認が必要なところで止める。感覚としては、一括発注より運転に近づいています。

OpenAIのCodexに関する公式ホワイトペーパーでも、音声入力は速さだけでなく、曖昧な記憶や不確実さを含んだ「編集前の考え」を渡しやすいとされています。そして、作業中に指示を加えて方向を直す考え方も紹介されています。

私のログで初手後の入力が79.7%を占めたことは、この使い方とよく合います。ただし、公式ホワイトペーパーは一人の実践例を中心とした運用ガイドです。効果を比べた実験ではありません。私のログも同じです。

共通しているのは、AIを動いている仕事へ指示を足せる環境として扱っている点です。

なぜ生成AIと音声入力は相性がよいのか

では、なぜこの組み合わせが使いやすいのでしょうか。私は、単なる入力速度より「渡せる情報が減りにくいこと」が大きいと考えています。

速さより、背景を削らず渡せることが大きい

音声入力の話では、「タイピングの何倍速いか」がよく注目されます。Typeless公式サイトは、音声入力をタイピングの4倍速と案内しています。AnthropicのClaude Code公式ガイドでは、話す速度は入力よりおおむね3倍速いと説明されています。より詳しいプロンプトになったというチームの実践も紹介されています。

ただ、すべての人や日本語業務で同じ倍率になるわけではありません。話す速度、認識精度、修正時間、端末、周囲の環境で変わります。企業が示す倍率を、そのまま私の生産性向上率にはできません。

私が注目しているのは、その先です。

キーボードで依頼文を書くと、「ここまで書かなくてもよいか」と背景を削ることがあります。入力に時間がかかるほど、伝える前に要約してしまうんです。

音声なら、なぜ困っているか、誰が読むか、何を避けたいか、どこで迷っているかまで出しやすい。生成AIに届く情報が増えれば、対象者や目的に合った案を作る材料も増えます。

音声入力は、考える時間をなくす道具ではありません。考えている途中の情報を、AIと共有できる形に変える道具です。私は、ここに速さ以上の価値を感じています。

「まだ整理できていない」が、相談の始まりになる

仕事で時間がかかるのは、答えが分かっている文章を打つ場面だけではありません。むしろ、答えが出ていない場面ですよね。

新しいサービスを誰に届けるのか。企画のどこに違和感があるのか。提案が通らない理由は何か。複数の要望のうち、何を優先するのか。

こうした問題を、きれいなプロンプトにしてから相談しようとすると、AIへ渡す前に止まります。

音声なら、矛盾した考えも出せます。「Aが良いと思う。でも、Bも捨てにくい」「数字は伸びている。ただ、現場の負担が気になる」。これで十分です。

そのうえで、AIに「前提、事実、仮説、未確認事項を分けてください」と頼みます。足りない情報は質問してもらう。人間が材料を出し、AIに整理してもらう。役割を分けるわけです。

もちろん、話しただけで正しい答えが出るわけではありません。誤認識や脱線もあります。だから、整理された結果を画面で確認し、数字や固有名詞は原資料へ戻って確かめます。

研究から考える、音声の速さだけでは分からないこと

音声入力とタイピングを比べた研究もあります。

2017年に公表されたRuanらの研究では、スマートフォンで短文を転記する実験を行いました。英語の音声入力はキーボードの2.93倍、中国語では2.87倍の入力速度だったと報告されています。

2020年のFoleyらの研究は、与えられた文を写す「転記」だけでなく、自分で内容を考える「作文」も比べました。音声は両方でタイピングより速かったものの、作文では差が小さくなりました。作業負荷については、作文時の身体的負荷を除き、有意な差は確認されていません。

つまり、何を入力するか考える時間まで含めると、「音声なら何倍速い」と単純には言えないわけです。これは、仕事で使った感覚にも合います。

なお、研究の条件はスマートフォン、英語や中国語、特定の音声認識、実験環境が中心です。日本語のPC作業やTypeless、生成AIとの長期的な協働へ、その結果をそのまま当てはめることはできません。

研究が示すのは、音声入力に速さの可能性があることです。私の仕事の成果を証明するものではありません。この違いさえ押さえれば、研究と実務の数字を無理なく参考にできます。

声を使わない場面も、先に決めておく

音声入力は万能ではありません。ここを忘れると、便利さがかえって負担になります。

私は、次の場面ではキーボードやコピー＆ペーストへ切り替えます。

• 正確な文字列を、そのまま渡す必要がある
• 周囲に聞かれてはいけない内容を扱う
• 認識結果の修正に、話す時間以上の手間がかかる

コード、数式、型番、長いURLは、一文字の違いが問題になります。静かな共有空間では話しにくいですし、機密情報や個人情報を声に出せない職場もあります。

目指すのは、音声だけで仕事をすることではありません。AIとの協働を止める抵抗を小さくすることです。

話した方が速く、背景を伝えやすいなら話す。正確さや秘密保持が優先なら、キーボードへ切り替える。この柔軟さが、実際の仕事では大切です。

Typelessを使い続けた理由と、企業利用での注意点

ここまで読んで、「なぜTypelessを使い続けたのか」が気になる方もいると思います。私にとっては、認識率の数字より、仕事を止めずに使えることが大きな理由だったんです。

専用画面へ移動しなくてよい

Typeless公式の案内では、テキスト欄にカーソルを置き、ショートカットを押して話します。もう一度押すと、整えられたテキストが挿入されます。特定のチャット画面だけでなく、さまざまなアプリの入力欄で使える設計です。

私にとって大きいのは、専用画面へ移動して録音し、文字起こしをコピーし、目的のアプリへ貼り付ける必要がないことです。考えている場所で、そのまま話せます。

一回なら小さな差です。でも、一日に何度も使うと、切り替えの少なさによって作業を中断しにくくなります。

また、公式にはフィラー語や繰り返しの除去、自動整形、個人辞書などが案内されています。実際の認識結果は、言葉や環境によって変わります。それでも、話し言葉を読みやすい入力へ整える考え方が、私の仕事に合いました。

ここでも、市場全体でTypelessが一位だと言っているわけではありません。私が複数の音声入力を試した中で、最も使いやすく、結果として使い続けられた。それが私の評価です。188/203日の利用実績は、その継続を数字で確かめたものです。

「保存しない」と「クラウドへ送らない」は別の話

企業で音声入力を使うなら、便利さだけでは決められません。音声や入力文がどこで処理されるか。保存されるか。モデル学習に使われるか。これは導入前に確認しておきたいところです。

TypelessのData Controlsは、2026年8月25日更新時点で、次のように説明しています。

• 音声は保存されないと説明されています
• 入力データはモデル学習に使われないと説明されています
• 履歴テキストは、任意のクラウド同期を有効にしない限り端末上に残る

一方で、文字起こし自体はクラウドで処理されます。音声と限定的な文脈情報をリアルタイムで扱い、処理後は直ちに破棄するという説明です。

つまり、「音声を保存しない」と「音声をクラウドへ送らない」は同じではありません。この違いを混同すると、情報管理の判断を誤ります。

公式説明を読んだうえで、自社の情報分類、秘密保持契約、顧客との取り決め、端末管理に照らして判断してください。機密度の高い内容は入力せず、必要に応じて匿名化し、承認された環境だけで使います。こうした運用も必要です。

サービスの仕様やデータポリシーは変わります。この記事に書いた内容を固定的な保証にはせず、導入時に最新の公式ページ、契約条件、管理設定を確認してください。

入力原文を公開しなくても、使い方は見直せる

今回の記事には、入力原文や顧客名を載せていません。分析に使ったのは、日時、録音時間、文字数、セッション内の位置といった情報です。

内容を外へ持ち出さなくても、「どれくらい使っているか」「短い入力と長い入力をどう使い分けているか」「一度の依頼で終わっているか」は確認できます。Claude Code側も、入力内容ではなく、ターン数と長さの分布を使いました。

ただし、メタデータなら何でも安全というわけではありません。時刻、ファイルパス、アプリ名から案件が推測されることがあります。企業で分析するときは、原文だけでなく、外へ出す集計項目も最小限にします。

そして、ログ分析を社員の評価へ直結させないことも大切です。

長く話した人が優秀なわけではありません。ターン数が多ければ良い仕事になるわけでもありません。分析の目的は、人とAIの間で、どこに入力の摩擦があるかを見つけることです。監視を目的にすると、数字を増やすことが仕事になってしまいます。

徳島の中小企業で試す「長く始め、短く仕上げる」運用

では、実際の職場ではどう始めればよいのでしょうか。徳島の企業から相談を受ける立場として、私は小さな仕事を一つ選ぶ方法をおすすめします。

最初の30秒から2分で、背景と完成条件を話す

最初から立派なプロンプトを作る必要はありません。仕事の入り口で、次の三つを話します。

1. 背景：なぜ今、この仕事が必要なのか
2. 完成条件：誰が何を見て、どう判断できればよいのか
3. 不確実さ：決まっていないこと、迷い、確認したいこと

たとえば提案書なら、枚数やデザインだけを指定しません。相手が何に困っているのか。今回、どこまで意思決定してほしいのか。避けたい表現は何か。そこまで話します。

会議後の整理なら、全文を要約してもらうより、決定事項、保留、担当、期限を分けてもらいます。採用原稿なら、募集要項だけでなく、現場の雰囲気や合わない人の条件も渡します。

話がまとまっていなくても構いません。最後に「事実と私の推測を分けて、足りない情報を質問してください」と付ければ、AIに整理してもらえます。ただし、数字や固有名詞は原資料と照合します。

返ってきたものへ、短い追撃を最低1回入れる

Claude Codeログでは、2ターン以上続いたセッションが64.1%です。これは、初回入力の後にも入力が続いたセッションの割合です。後続入力がすべてレビューだったわけではありませんが、私自身の運用を振り返る手がかりにはなります。

AIの初回出力は、確認用の試作と考えます。返ってきたら、次の三点を見てください。

• 目的に合っているか
• 根拠と推測が分かれているか
• 読み手が次に行動できるか

違っていたら、差分だけ返します。「対象者には難しい」「この結論の根拠を確認して」「三つに絞って」「公開前に止めて」。音声なら、気づいた瞬間に伝えられます。

重要な数字、外部への公開や送信、削除、契約、金銭が動く操作は、人間が確認する項目として残します。AIが速く動くほど、止まる場所を先に決める。この設計が必要です。

測るのは、仕事の前進

導入後に「今月は何回、音声入力を使ったか」だけを追うと、目的がずれます。長く話しただけで、成果物が良くなるわけではありません。追撃が多すぎるなら、初手の条件不足やAIの品質に原因があるかもしれません。

見たいのは、仕事の結果です。

• 着手から初稿までの時間
• レビューによる手戻りと、要件漏れの件数
• 人間が判断すべき場所で止まれた割合

ほかにも、根拠未確認の件数や、次回再利用できる手順にできた割合を見ます。部署や業務によって、選ぶ指標は変わります。

最初の30日で利用場面を決めます。60日で品質と安全上の問題を洗い出し、90日で継続、修正、中止を判断します。このくらいの期間で見ると、一度試しただけの利用と、仕事に定着した利用を分けやすくなります。

詳しい測り方は、生成AI研修を90日で評価するKPI設計もご覧ください。

私のTypeless分析でも、価値があったのは件数を数えたことだけではありません。DB全1,647行から条件を満たす1,527件を抽出し、1分以上は12.6%でも録音時間の67.9%を占めると分かりました。30分推定のセッション先頭と後続入力で、長さの役割が変わることも見えました。

量を測った先で、仕事の型を見つける。そこまで進んで、ログ分析が改善に変わります。

実際の業務を題材に、音声から試してみる

生成AI研修でプロンプト例だけを配っても、日常業務に戻ると使われなくなることがあります。プロンプトを書く作業そのものが、新しい負担になるからです。

そこで、実際の仕事を題材にします。会議後の整理、提案書の初稿、顧客への説明案、社内手順の作成。まず、音声で背景を渡してみます。

AIの返答を見る。短い追撃を入れる。事実を確かめる。完成条件まで持っていく。この流れを一度経験すると、AIが仕事を一緒に進める相手へ変わります。

もちろん、導入で起こりやすい失敗もあります。認識精度を一度試しただけで判断し、長く話すことを義務にし、AIの返答を確認せず社外へ出す。この三つは避けたいところです。

今回のTypeless分析対象でも、87.4%は1分未満です。短い入力は悪くありません。最初に必要な背景を渡し、後は短く直す。仕事に合わせて長さが変わるのが自然です。

カンマンは徳島の企業として、地域の中小企業が無理なく続けられる生成AI活用を一緒に考えています。業務の内容、情報の機密度、担当者の経験、確認体制から設計します。

生成AIの社内定着、音声入力を含む実務検証、自社ログを使った改善に課題を感じている方は、カンマンの生成AI研修・無料相談へご相談ください。徳島の現場で無理なく始められる一歩を、一緒に考えましょう。

よくある質問と参考資料

最後に、音声入力と生成AIについてよく聞かれそうな点をまとめます。数字の読み方で迷ったときにも、ここへ戻ってください。

Q1. 音声入力を使わないと生成AIを活用できませんか？

いいえ。私にとっては欠かせない道具ですが、すべての人や業務に必須だと証明されたわけではありません。

周囲に聞かれたくない内容、正確な文字列、静かな共有空間では、キーボードが向きます。まず、AIへの長めの背景説明や、返答への短い修正から試してください。

話した方が速く、入力内容も豊かになる場面だけ残せば十分です。目的は、仕事を前へ進めることです。

Q2. Typelessの利用履歴だけで、生産性向上を測れますか？

利用履歴だけでは測れません。件数、録音時間、文字数、セッション先頭と後続入力の分布は、使い方を知る手がかりです。

生産性を見るには、完了までの時間、手戻り、成果物の品質、未確認事項、利用者の負担なども必要です。

DB全1,647行から条件を満たした分析対象1,527件は、音声入力が私の仕事に定着していたことを示しています。ただし、音声入力が成果を生んだという因果関係までは示しません。

Q3. Claude Codeログの「10秒未満」は、すべて音声入力ですか？

いいえ。Claude Codeログからは、Typeless、別の音声入力、キーボードのどれを使ったか識別できません。

文章系の入力を抽出し、350字/分という仮定で長さを換算した目安です。そのため、Typelessの実測録音時間とClaude Codeの換算値は単純比較できません。

Claude Code側で確認できるのは、初手より追撃が短くなるという、そのログ内部の傾向です。

参考資料

• Ruan, S.ほか「Comparing Speech and Keyboard Text Entry for Short Messages in Two Languages on Touchscreen Phones」：University of Washington掲載PDF
• Foley, M.ほか「Comparing Smartphone Speech Recognition and Touchscreen Typing for Composition and Transcription」：ACM DOI
• Typeless公式：日本語公式サイト
• Typeless公式：Data Controls
• OpenAI「Codex-maxxing for long-running work」：公式ホワイトペーパー
• Anthropic「Claude Code パワーユーザーのヒント」：公式ヘルプ

生成AIの性能は、モデルだけで決まりません。私たちがどれだけ背景を渡し、返ってきたものを見て、次の指示を重ねられるか。ここで仕事の進み方が変わります。

私にとって音声入力は、考えを削らずAIへ渡すための道具です。そして、違和感をその場で返し、仕事を止めずに進めるための基盤でもあります。

まず一つの仕事で試してみてください。最初に少し長く話す。返答を見て、短い追撃を入れる。そこから、自分とAIに合う「長く始め、短く仕上げる」型が見えてくるはずです。