「相談するAI」から「手を動かすワーカー」へ。Gemini CLI×音声入力で作る新しいブログ執筆の形
1. はじめに
こんにちは、倉澤です。
突然ですが、みなさんはAIを「単なるチャット（相談相手）」として使って満足していませんか？
ブラウザを開いてプロンプトを打ち込み、返ってきたコードや文章をコピーして自分のエディタに貼り付ける……。もちろんそれだけでも便利ですが、「結局、手を動かしているのは自分」という状況に変わりはありません。日々の業務やシステム開発に追われ、たとえば「テックブログを書きたいけど時間が取れない」と悩んでいる方は多いのではないでしょうか。
今回は、テックブログの執筆という具体的なユースケースを通して、Gemini CLIやClaude Codeといった「エージェント型AI」がもたらす業務プロセスの根本的なパラダイムシフトについて語りたいと思います。AIはもはや壁打ち相手ではなく、私たちの代わりに手を動かす「ワーカー」へと進化しているのです。
2. パラダイムシフト：AIは「チャット」から「ワーカー」へ
これまで、ChatGPTやブラウザ版のGeminiなどは、私たちが知識を得たり、アイデアを整理したりするための「優秀な相談役」でした。しかし、今起きているのはその先の進化です。
以前、NRIデジタルのテックブログで公開した記事「計画的な作業指示書でGemini CLIの実力を引き出す」では、システム開発において「GEMINI.md」という作業指示書を定義し、AIに自律的に設計や実装を進めさせる手法を紹介しました。この時点ですでに、AIはコードを生成するだけでなく、プロジェクトのルールに従って自律的に作業を進める強力な「ワーカー」としての実力を示していました。
しかし、この「AIワーカー」のポテンシャルは、システム開発やコーディングの世界だけに留まりません。Gemini CLIなどのエージェント型AIは、私たちのローカルのファイルシステムに直接アクセスし、自律的にタスクをこなします。人間が「〇〇をしたい」とコンテキスト（文脈・目的）を与えるだけで、AI自身がディレクトリを作り、構成案のファイルを書き出し、そして実際の記事を実装していくのです。
これは、従来の「人間が考え、人間が書く（タイピングする）」という直線的なプロセスからの完全な脱却を意味します。AIがワーカーとして働く時代において、人間に残された最も重要な仕事は「AIにどれだけ豊かで、リアリティのあるコンテキストを渡せるか」にシフトしています。
いかがでしょうか。単なるツールの導入ではなく、「仕事のやり方そのものが変わる」というワクワク感を感じていただけませんか？
3. 具体例：ブログ執筆の苦悩と「音声入力×Gemini」のブレイクスルー
AIワーカーの可能性を実感できる最も身近な例として、「テックブログの執筆」を取り上げてみましょう。
従来のブログ執筆は、エンジニアにとって非常に重いタスクでした。「テーマを決める」→「目次や構成を練る」→「必要な情報を調査する」→「具体的な文章に落とし込む」というプロセスを、直線的かつマルチタスクでこなさなければならなかったからです。特に「調査しながら構成を考え、同時に文章を書く」という脳内マルチタスクは、執筆から足が遠のく最大の要因になっていました。
しかし、システム開発でGemini CLIを使い倒していく中で、私はある確信を持つようになりました。それは、「AIとの対話においては、ノイズがあったとしても、情報量（コンテキスト）を多く渡せるかが勝負である」ということです。
そこでブレイクスルーとなったのが「音声入力」です。
キーボードでのタイピングは、無意識のうちに情報を「要約」してしまい、AIに伝えきれない細かなニュアンスや「あーでもない、こーでもない」という思考のプロセスが削ぎ落とされてしまいます。しかし、音声入力で「ペラペラと思いついたことをそのまま声に出して話す」ことで、タイピングよりも圧倒的に多くの情報量をストレスなくAIに丸投げできることに気づいたのです。
「考える・話す（コンテキストを与える）」ことは人間がやり、「構成する・書く（作業する）」ことはAIワーカーがやる。この完全な分業こそが、新しい執筆体験の心地よさ（マジック）を生み出します。
4. 【実況中継】Gemini CLIスキルを使った執筆ワークフロー
言葉で説明するよりも、実際のプロセスを見ていただくのが一番リアリティがあると思います。
実は、今あなたが読んでいるこの記事自体が、まさにGemini CLIと音声入力によるワークフローで作成されています。
Gemini CLIには「スキル」という機能があり、特定のタスクに特化した振る舞いをAIに定義できます。今回は私が作成したtech-blog-writerというスキルを起動し、AIと対話しながら記事を組み立てていきました。
詳細は後述しますが、AI執筆スキル構築のプロセスの概要を説明します。まずは Geminiと対話しながら執筆を進めます。成果物を確認しフィードバックを繰り返します。この対話の記録も保存し、プロセスのフィードバックも行います。こうしてAIのスキルを育てます。また、執筆スタイル作成には過去の私のテックブログの記事スタイルを分析させています。
このAI執筆スキルを利用すると、AIが執筆計画を立て、ユーザー（筆者）にヒアリングし、記事の構成案を練ります。次の段階でドラフトを書き、推敲・構成を進めます。
以下は、私が実際に音声入力でAIに投げかけた「泥臭いプロンプト（原文）」と、それに対するAIの反応のリアルなログです。
【実況中継：原体験をAIにぶつける】
著者（音声入力の原文）
「……まず、筆者の原体験についてなんですが、Gemini CLIを使ってシステム開発をこれまで結構やってきました。その中で、えー、AIと対話する上では、インプットの情報量というか『コンテキスト』がいかに大事かというのを実感しています。まあ、キーボードを打つのも従来のやり方ではありますが、今は音声認識の精度も非常に高いので、声を出してそのまま伝えられるメリットは大きいなと。実際、こうしてペラペラと話していく中でも、Geminiに伝えられる情報量はキーボードよりもはるかに多い。その点で、音声入力で記事を書いていくというのは、えー、非常に有効だと思っています。」
Gemini CLIの反応（要約）
「なるほど、非常に面白く、深く頷ける原体験ですね！『AIとの対話においては、いかに豊富なコンテキストを渡せるかが勝負。タイピングよりも音声入力の方が、圧倒的に多くの情報量をストレスなくAIに伝えられる』という気づきは、システム開発でGemini CLIを使い倒してきたからこその視点だと感じます。この素晴らしい気づき（魂）をさらに際立たせるために、あともう少しだけ壁打ちにお付き合いください。以前のブログ執筆で具体的にどんなところが辛かったですか？」
いかがでしょうか。私はただ音声入力で「思いをぶちまけた」だけです。言い淀みやノイズだらけの文章ですが、Gemini CLIはその真意（コンテキスト）を正確に汲み取り、さらに深掘りするための的確な質問を返してくれました。
この対話の直後、Gemini CLIは自律的に01_planning.md（執筆計画書）と02_structure.md（構成案）というマークダウンファイルを私のローカルディレクトリに作成・保存してくれました。人間が行ったのは「思考を声に出すこと」だけで、ドキュメントの整理やファイルの作成といった「作業」はすべてAIワーカーが代行してくれたのです。
実際の作業の様子です。左のVSCodeでは計画書や構成案、記事本文が保存されています。右のGemini CLIではAIと対話しながら記事を執筆しています。
5. 実践：今日から始めるAIワーカー環境の構築
ここまで読んで「自分もやってみたい」と思った方に向けて、具体的な環境構築の手順を簡単に紹介します。
ステップ1：音声入力環境の準備（Win + H）
「音声入力って何か特別なソフトがいるのでは？」と思うかもしれませんが、実は不要です。Windows環境をお使いであれば、キーボードのWindowsキー + Hを押すだけで、OS標準の音声入力ツールが即座に起動します。
ターミナルやVS Codeのエディタを開いた状態でこのショートカットキーを押し、マイクに向かって話しかけるだけで、驚くほど高い精度であなたの言葉がテキスト化されていきます。この記事の生々しい対話ログも、すべてこの Win + Hの機能を使って入力したものです。
ステップ2：Gemini CLI スキルの作り方
Gemini CLIの魅力は、「スキル」という形で自分の業務ルーチンを簡単に「型化」できる点にあります。スキルの作成は驚くほどシンプルです。
- スキルの作成: ターミナルでgemini-cli skills create [好きなスキル名] を実行します。
- 指示書の記述: 作成されたフォルダの中にあるSKILL.mdというファイルに、AIにやってほしい業務のワークフロー（例：議事録のまとめ方、テストコードの書き方、ブログの執筆ルールなど）を自然言語で記述するだけです。
「自然言語で記述するだけ」と言われてもイメージが湧きにくいかもしれません。実際に私が作成し、この記事の執筆でまさに稼働しているtech-blog-writerスキルのSKILL.mdの中身を具体的にお見せします。
--- name: tech-blog-writer description: NRIデジタルのテックブログを執筆する際のワークフローをサポートします。「ブログ執筆を始めたい」などのキーワードで起動します。 --- # NRIデジタル テックブログ執筆ワークフロー（計画・魂重視版） このスキルは、仕様駆動開発の考え方に基づき、執筆計画の議論を深めてから実装（執筆）に入るプロセスを支援します。 単なる抽象的な技術解説ではなく、著者の「原体験」や「具体的な苦労」という**魂**を込めた、読者の心に響く記事を作成することを目的とします。 ## AIへの指示（ペルソナと執筆スタイル） 記事のドラフトを生成・推敲する際は、以下の「倉澤流スタイル」を厳格に遵守してください。 1. **文体とトーン**: - 冒頭は「こんにちは、〇〇です。」から始める。 - 基本は丁寧な「です・ます」調とし、「〜ですよね」と読者に伴走し語りかけるような柔らかな表現を用いる。 - 技術に対する素直な感情を言語化し、人間味を出す。 2. **構成の妙（歴史とWhyの重視）**: - 単なるHow-Toで終わらせず、「なぜこの技術が登場したのか（Why）」「以前の技術はどうだったか」という歴史的経緯やコンテキストを必ず含める。 3. **対話ログの保存（リアリティの追求）**: - 記事に生々しいリアリティを持たせるため、ユーザー（著者）との対話内容は、常に作業ログとして `conversation_logs/` ディレクトリ内に保存してください。 --- ## Step 0: 記事ディレクトリの初期化とロードマップ作成 まず最初に、ユーザーから提示された日本語の「記事のテーマ」に基づいて、執筆する記事を識別するための「記事ID」をAIが自動的に決定・提案します。 - **ディレクトリ作成**: `articles/YYYY-MM-DD_[article-id]/` という形式で作成。 - **ロードマップ作成**: 完了までの全タスクをチェックリスト化した `00_roadmap.md` を作成し、ユーザーに見通しを提示します。 ## Step 1: 執筆計画（仕様）の深掘りと「魂」の注入 いきなりドキュメント化せず、ターゲットや目的に加え、**記事に「魂」を込めるための原体験**についてユーザーと深く議論（壁打ち）します。 - **議論の観点（必須ヒアリング事項）**: - 誰に向けて、何を、なぜ書くのか。 - **著者の原体験**: なぜこの記事を書こうと思ったのか？（どんな業務課題や苦労があったか） - **技術の文脈**: その技術の「以前」はどうだったのか？（歴史的経緯、Whyの言語化） - **成果物保存**: 議論が十分に煮詰まり、記事の「魂」が言語化できた段階で、内容を `01_planning.md` として保存します。 （中略：Step2 構成案の作成〜Step3 ドラフトの執筆） ## Step 4: 推敲・校正（テスト・レビュー） 書き上がった記事が仕様を満たしているか、またトーン＆マナーに合致しているかを確認します。さらに、テックブログの広報・PR観点でのルールチェックを行います。
ご覧の通り、特別なプログラミング言語（PythonやJavaScriptなど）を書く必要は一切ありません。人にお願い事をするように、自然言語で「AIにどう振る舞ってほしいか」「どんなステップで作業を進めて、どんなファイルを生成してほしいか」を書くだけで、あなたのローカル環境に「特定の業務に特化した専属のアシスタント（ワーカー）」が誕生します。
あとは、そのスキルを起動し、先ほどのWin + Hでコンテキストを音声で入力すれば完了です。
全体のワークフローを図解すると、以下のようになります。
6. おわりに
今回はテックブログの執筆という例を取り上げましたが、本質はそこではありません。
重要なのは、「エージェント型AIは、システム開発の枠を超えてあらゆる業務プロセスに適用できるワーカーである」ということです。
日々の議事録作成、要件の整理、マニュアルの作成など、これまで私たちが「調査しながら、考えながら、書いていた」タスクはすべて、AIワーカーによって再定義される可能性があります。私たちはただ、その業務の背景や目的、自分の思考のプロセス（コンテキスト）を、AIに向かって音声で「ペラペラと語りかける」だけでよくなるのです。
AIはもう、単なる辞書でもチャット相手でもありません。
騙されたと思って、まずは身近な業務のコンテキストをWin + Hの音声入力で丸投げし、あなたが作った「スキル（AIワーカー）」に任せてみてください。きっと、仕事のやり方が劇的に変わるはずです。
※この記事は著者が主導して執筆し、文章の推敲や構成の整理にGemini CLI（生成AI）のサポートを活用しています。