嫁ちゃん
わたし
嫁ちゃん
わたし
AIと対話しながら、納得のいく一稿を練り上げる #
ブログの記事をAIに直してもらう。そう聞くと、たくさんの記事を一度にきれいにできそうに思える。でも、自分の文章を預けるとなると、どこまで変わるのか、元の言い回しが消えてしまわないかが気になる。
そこで、公開中の記事をいきなり直すのではなく、コピーしたものを下書きにして試すことにした。元の記事はそのまま残し、まずは一件だけ、どこが変わるのかをじっくり見てみる。
AIの提案を、そのまま完成稿にしない #
AIが提案した文章を自分で読み、必要なところに手を入れる。その原稿をもう一度AIに見せて、「最初に伝えた意図が届いているか」「読みやすさがどう変わったか」を一緒に確かめる。私には、この質疑応答の往復が思ったより楽しい。
AIの提案を採用するかどうかは、最後に自分で決める。事実や経験した順序が変わっていないか、自分が書いたときの温度が残っているかを確かめたいから。全部を一度に直されると、自分の記事ではなくなってしまう。だからこそ、一気に進めるのではなく、一件ずつ丁寧に扱っている。
今回の作業では、OpenAIのCodexが段取りを決め、Mac上で動く文章AI「Gemma 4 26B」が実際の修正案を作る。こうしたMacの中で動く大規模言語モデルを「ローカルLLM」と呼んでいる。Codexは記事と文体ルールを読んで指示を整理し、Gemmaが返した案を確かめて反映する役割を担う。Codex自体はクラウド側で動くため、記事の内容や指示、修正案はCodexにも渡る。文章案の作成をローカルで行う仕組みだが、全工程がMacの中だけで完結するわけではない。
ここは少し分かりにくいところなので、作業の分担を隠さず書いておきたい。進行役はCodexで、記事や文体の条件を見ながら、次に何をするかを決める。実際に文章の修正案を出すのは、Mac上のGemma 4 26Bだ。その案を確認し、記事に反映する段取りもCodexが担っている。つまり「ローカルLLMだけに記事を渡して、全部を直してもらった」という作業ではない。クラウドとMacのモデルが一緒に動く形だ。プログラムの仕組みを知らなくても、誰が考えて、誰が手を動かしたのかが分かれば、AIに何を任せたのかを読者にも伝えられると思う。
ローカルLLMに文章案を作ってもらえば、クラウドAIに頼む量を減らせることがある。AIが文章を処理する量は「トークン」という単位で数えられ、サービスによっては料金にも関わる。ただし、今回のようにCodexも使う場合は、記事や修正案がクラウド側にも渡るため、利用料が必ず下がるとは限らない。それでも、作業ごとにAIを使い分けるのは面白い。
クラウドAIに20ドルを払うことを考えると、私には少しハードルが高く感じる。必要なときに頼れる安心感はあるけれど、文章の下書きや見直しまで全部任せるのがよいのかは迷う。ローカルで動くモデルなら、手元のMacで試せるし、どんな作業をどちらに任せるか考えるきっかけにもなる。料金だけで決めるのではなく、自分がどの作業に価値を感じるかを確かめたい。
私は、こうした手順を知るために、必ずしも本を買う必要はないと思っている。今はネットで調べられるし、分からないことをAIに尋ねれば、必要な手順を一緒に整理してもらえる時代だ。ただし、AIがいつも正しいとは限らない。答えをそのまま信じず、公式情報や実際の画面で確かめることは欠かせない。それでも、調べる入口になったり、自分だけでは気づかなかった見方を教えてくれたりする。AIは答えを丸ごと任せる相手というより、次に何を調べるか、何を試すかを考える助けになっている。
今回の文章修正では、Mac上で動くGemma 4 26Bに修正案を作ってもらっている。私が使っているのは、メモリ32GBのM6 Mac miniだ。ローカルLLMを試すには、使いたいモデルに合ったメモリを備えた環境が必要になる。必ずこのMacでなければならないわけではないけれど、手元でAIを動かす環境の一例として、前回の記事でも紹介したM6 Mac miniを置いておく。
これからAIに頼る場面が増えれば、料金や使い方も今とは変わっていくのかもしれない。だから今は、何でも任せるのではなく、試した結果を見ながら自分に合う使い方を探している。
予期せぬ「崩れ」を見つけたとき #
AIとのやり取りには、思い通りにいかない場面もある。 前回の修正では、夫婦の会話を表示するための「台詞表示の終了記号」が欠けてしまったり、本人が書いた壁打ちの回答が一箇所だけ書き換わってしまったりした。
これに気づいたのは、記事のルールも確認していたCodexだ。Codexが「表示記号が足りない」「回答が元のものと違う」という崩れを見つけ、元の記号と回答を正しく復元してから、改めて記事へ反映してくれた。
こうした小さな崩れを見落とさないよう、修正案を自分でも読み、元の文章と照らし合わせながら進めている。
50歳を過ぎて、まだ知らないことに出会う #
私は長くエンジニアとして働いてきた。ITの進化には比較的触れてきたつもりだったけれど、50歳を過ぎてAIに出会い、まだ知らないことがこんなにあると気づいた。AIに文章を直してもらい、その案を自分で読み返す。そんな小さな経験が、私にとってはAI時代への再デビューのように感じられる。新しい道具を前にしたときのワクワクが、また戻ってきた。
もちろん、AIが広がることに不安もある。便利な使い方だけでなく、AIを使った犯罪の話を聞くと怖くなる。それでも、怖いから遠ざけるだけではなく、どう使われ、何に気をつけるのかを自分でも知りたい。使い方の手順はAIに聞けば教えてもらえるけれど、実際に触れて「こんなこともできるんだ」と感じる驚きは、自分で試して初めて分かるものだと思う。
最近はObsidianをやめて、サーバーとつないで使うMarkdownエディタをAIと共に作り、AIエージェントも作ったりして試している。どちらも、始める前から全部分かっていたわけではない。作ってみて、動かしてみて、初めて次に知りたいことが見えてくる。AIに記事を直してもらうことも、その延長にある小さな実験のひとつだ。まだ可能性を十分に分かっていないからこそ、気になったことをひとつずつ試し、新しい気づきを得ていきたい。
自分の目で確かめながら、少しずつ #
記事には、書いたときの記憶や、あとから足した考えが残っている。文章を整えることと、その人の経験を薄めることは別のはずだ。AIに直してもらうことで、書き始めるまでの心理的なハードルが少し軽くなったのはうれしい。それでも、自分で読み、対話しながら仕上げる時間は大切にしたい。
下書きの段階で納得いくまで煮詰めれば、記事の差し替え自体に大きな不安はない。それでも、いざ「公開」ボタンを押すとなると、やっぱり緊張する。自分で書いた記事が、ただAIに自動生成させたものだと思われるのは避けたいからだ。
私は文章を書くのが特別うまいとは思っていない。AIの修正で自分らしさが少し薄くなるように感じることはあるけれど、回りくどい部分が整理され、読んでくれる人には伝わりやすくなるのかもしれない。だから、直した文章が整っているかだけではなく、そこに自分が経験したことや、迷った気持ちが残っているかを見ている。技術の説明も、専門用語を並べるより、私が何を試してどう感じたのかを軸にしたい。読んだ人が「自分も少し触ってみよう」と思えるなら、記事にした意味があると思う。
まだ全記事へ広げる段階ではない。修正、人の手直し、AIとの読み返しを一件ずつ重ねて、自分なりの「デジタルな手仕事」の進め方を探している。
私が手を入れたあと、AIともう一度読み返して納得できるまで対話する。その往復も、このやり方の面白さだ。
嫁ちゃん
わたし
そらちゃん