Zenn
🐇

個人的 AI Writing のやりかた

に公開
AI
ブログ
Zenn
ChatGPT
LLM
idea

こんにちは、よしこです。

最近コーディングではAIを活用できる場面が増えてきたのですが、これまで記事の執筆にはなかなかAIを活かせていませんでした。私は文章表現にこだわりが強いようで、抵抗感が拭えず…
でもそんな自分でもAIを活用して記事執筆の負担を削減できる方法が見えてきたので、今回はそれを紹介したいと思います。

といってもすべてを書かせるわけではありません。イメージこんな感じ！（せっかくなので挿絵にも使ってみる）

工程の差分

  1. 骨組み（0~20%）
    内容や要点のメモ書き。一旦箇条書きとかでいいので楽
  2. 肉付け（20~70%）
    骨組みを文章にしていく。ここが結構悩むしめんどくさい
  3. 仕上げ（70~100%）
    記事としてだいたいできたものを第三者視点で見返し、読みやすく調整を重ねる
    形になっているものの調整なので、時間はかかるけど気は軽い

このうち一番ボリュームのある「2. 肉付け」をAIにやってもらう方法を紹介します。

先に言っておくと、私の場合は肉付けをAIにやってもらっても仕上げ工程でほとんど自分の言葉で書きなおしています。画像にあるように、最終形を自分で書くのと同じにしたいので…
ただ総工数は断然減っているのと、「執筆のために腰を上げる心理的負荷」をぐっと下げられることがメリットです。

事前準備

AIのアウトプットを叩き台にして作業するときの違和感を最大限なくせるように、事前にAIに自分の文体を把握させておきます。

まず、過去に自分が書いてきた記事をテキスト形式のファイルにして、articlesディレクトリに格納します。zennだと今までGitHub連携していなかった場合でも過去記事のエクスポートができるので、私はこれを利用しました。

そしてAIエージェントを使える環境を用意します。Cursorや、VSCode + Cline(or Roo)のようなエディタ型がおすすめです。

これらが準備できたら、過去記事から抽出した特徴を別ファイルにまとめさせます。
以下のプロンプトで指示しました。（ @articles は記事ディレクトリを指すシンボル）

@articles このフォルダの中の記事全部読んで、私の文体や文章の特徴を把握して、writing-style.mdにまとめて。

モデルはOpenAIのGPT-4oを利用しました。コーディングには使えませんが、自然言語でのアウトプットはやはり4oが強い印象があります。

どんなふうにまとまるかの参考までに、実際の上記のアウトプットも貼っておきます。若干恥ずかしいけど。。

writing-style.md

記事執筆スタイル・文体プロファイル

1. 語り口・トーン

  • 読者に語りかけるフレンドリーな文体（例:「こんにちは、よしこです。」で始まる）
  • 柔らかい断定や体験談を交えた表現（「〜と思います」「〜してみました」など）
  • 「よければ〜」「ぜひ〜」など、読者への呼びかけや提案が多い
  • カジュアルな語尾や感嘆（「笑」「最高か？」など）も適度に使用

2. 構成・見出し

  • Markdownの見出し（#, ##, ###）を多用し、論点ごとに明確に区切る
  • 記事冒頭で「この記事では〜について紹介します」と目的を明示
  • まとめや「以上！」で締めることが多い
  • 箇条書きや表、図、コードブロックを多用し、視覚的にも分かりやすく

3. 技術的な説明・具体例

  • コード例や図、箇条書きを多用し、具体例を交えて説明
  • 技術的な背景や理由、選択の根拠を丁寧に記述
  • 他記事や外部リソースへのリンクを積極的に貼る
  • 失敗談や反省点も隠さず書く

4. 読者への配慮・注意喚起

  • 注意点や教訓、実際に困ったこと・工夫したことを率直に共有
  • 「こういう人にはこう」「この場合はこう」と分岐や例外も丁寧に説明
  • 読者の立場に立った補足やアドバイスを随所に挿入

5. ユーモア・個性

  • カジュアルな語尾や感嘆を交える
  • 体験談や裏話、余談も積極的に盛り込む
  • 記事の最後に宣伝や一言を添えることも（例: We're Hiring）

6. 技術選定や設計思想の明文化

  • 「なぜそうしたか」「どんな思想で選んだか」を明確に記述
  • 型やlinter、CIなど自動化・仕組み化への強いこだわり
  • 「注意力に頼らない」「仕組みで解決する」などの思想が随所に現れる
  • ベストプラクティスも鵜呑みにせず、必要性を検証し自分の言葉で説明

7. その他の特徴

  • 章ごとに「詳細記事」や「関連リンク」を貼り、知識の深掘りを促す
  • まとめや「教訓」セクションで学びや気付きを明文化

まあ、たしかにそんなふうに書いてるな〜って感じではありますね。

この特徴ファイルは一度生成できれば以降の執筆で毎回活用できます。

執筆

1. 自分で骨組みを作成

最初は自分のターン。伝えたい内容を新規ファイルに雑に書き出していきます。読みやすさはこの時点では全く気にせず箇条書きでいいので、心理的にだいぶ楽です。
私は書く前に構成のイメージがだいたい定まっているのでこの段階で見出しでアウトラインも作ってしまいますが、苦手な場合はAIと対話しつつ構造化を手伝ってもらうか、次のステップでそこまで含めて任せてみてもいいかもしれません。

例として、前回書いた 個人的 Vibe Coding のやりかた の骨組みを掲載してみます。

Vibe Coding記事の骨組み

こんにちは、よしこです。

最近Vibe Codingでスマホアプリを作ることが多いので、自分がどういう手順でやってるか書いてみます。

要件定義

  • 成果物：要件定義.md
  • GPT-4oでやることが多い
    • 推論モデルだとテンポが悪いため
    • 推論なしでもできるぐらいの難易度
    • 4oが話してて楽しいので個人的な好み。合間で画像生成できるのは便利かも
  • 決めること: 何をするプロダクトなのか、機能、どんな画面の種類から構成されるか、名前
    • ソースコードの随所に入るので、事前に名前決めておくのは重要

技術選定

  • 成果物: 技術選定.md, monorepo構造.md, DBテーブル設計.md, API仕様.md など
  • なぜやるのか？
    • コーディングのはじめにLLMに要件定義書を読ませると、技術を詰める前にコードを書き始めてしまうことが多い。
    • 使う技術やディレクトリ構造などを事前に決めておくことで手戻りを防げる
      • たとえばdenoでやりたかったのにnodeで書かれた、モバイルアプリのつもりだったのにWebアプリにされた…などを防げる
    • 要件からの流れで詳細仕様のところも話せると楽
      • DBのテーブル構造とか、必要なAPIの種類とか
    • これもGPT-4oでやることが多い
      • 要件定義と同じチャットでごちゃ混ぜで話してることも多い
      • 最後に要件定義mdと技術選定md出して、といったら別々に出してくれる
  • よくやる構造
    • だいたいmonorepo
    • API(hono or mastra) + Flutter(iOS) + DB,認証(Supabase) なことが多い

リポジトリ作成

  • 事前準備
    • ディレクトリ作成とgit initは自分でしておく
    • 前段で吐いたmdをdocs/に配置してコミットする
    • ※git管理が超大事。gitだけはvibeに乗らない。作業単位、うまく動いた単位でこまめにコミットする。
  • Claude Codeを使う
    • ファイルが一気に生成されたり依存のインストールが走ったりするので、エディタ型だと都度indexが走ったりして邪魔に感じることが多い
    • 環境構築としてコマンドを叩くことが多いのでCLIベースのほうがしっくりくる
  • docsを読ませる
    • 読ませるとだいたい勝手に実装に入っていく
    • 「不明点があったら質問して」って言っておくと質問してくれるので、答えてそれもmdに反映させておく
  • あとはディレクトリごとに勝手に構築してもらう
    • APIの作成と立ち上げ（DBはモック）、クライアントの作成と立ち上げ（APIはモック）、ふたつの疎通、DB作って疎通、みたいな感じで段階を経るとやりやすい
    • だいたい勝手にやってくれる、人間は実行コマンド見てYesを押すだけ
  • ざっくりできたらそれぞれを起動して動作確認
    • だいたいは何らかエラー出るので、Claude Codeにコピペして直させる
    • 2ラリーぐらいしたらちゃんと立ち上がる印象がある
    • ぱっと見で直したいところがあれば言葉で指示して直させる

微調整

  • Cursorなどエディタ形式のAgentでやる
    • modelはClaude 3.7 Sonnet, Gemini 2.5, ChatGPT-4.1あたり
  • 動いてる上でファイル見て文言調整するとか、長すぎてやばそうなファイルがあれば分割させるとか
    • こういう作業は自分でファイル見れたほうが楽なのでエディタのほうがいい

こんな感じでコード書かずにスマホアプリがつくれます。

まあまあ書いてるな…と思うかもしれませんが、とりあえず適当な箇条書きでいいと思って書き出し始められれば、脳内を垂れ流すイメージでで意外とざざっと書けちゃいます。
詰まってしまったら、一旦次の工程に進んでみてまた戻ってきて…を繰り返してもよさそうです。

2. AIで肉付け

骨組みができたら、以下のようなプロンプトでAIに肉付けした叩き台を書いてもらいます。

@file.md 構成書いたので、@writing-style.md を踏まえて、記事にしてみて。いま全部箇条書きだけど、基本平文にしたい。今書いてる文章はそのまま使ってほしいんじゃなくて内容を伝えたいものなので、表現とかは変えてOK。

プロンプトは好みに応じて修正してください。
これで記事の体裁を保った叩き台が作れます。箇条書きで要点だけだった骨組みを、文脈や読みやすさも考慮して平文にひらいてくれるって感じですね。

モデルはOpenAIのGPT-4oを使っています。最新のGPT-4.1とも比較しましたが個人的には4oのアウトプットが好みでした。骨組みからそのまま残すべきところと直すべきところの取捨選択が上手い印象です。

3. 自分で仕上げ

2で肉付けされたものを客観的に読んでみて、気になるところを修正します。自分がゼロから書いたらどうなるかのイメージは思い浮かべられるので、そこと一致させていく感じです。
（まあそうすると私の場合は結局全体的に書き直すことになるんですよね。笑）

でも、ゼロから全部自分で書かなきゃいけないのと、叩き台が目の前にあってそれを添削すればいいのとではかなり心理的負荷が変わります。
一人でスピーチするのは辛いけど、誰かにインタビューされれば喋れる という感覚に近いです。

だいたいここでセクション組み替えたり、スマホで見て文字の長さ調整したり…そのへんの作業は従来と変わりません。

納得いくまで仕上げたら完成！

4. AIレビュー

完成したあと、ためしにモデルをo3に切り替えてレビューさせてみたらかなり良かったです。

https://x.com/yoshiko_pg/status/1918293773177765897

結構「あ、たしかに…」みたいな内容をレビューしてくれます。これからは毎回やろうと思いました。
今回はo3でしか試してませんでしたが、他のモデルとレビュー比較してみても面白そうですね。

まとめ

こんな感じのプロセスにたどり着き、最近はまたちょっとずつ記事が書けるようになってきました。
とにかく記事を書くときの腰の重さがだいぶ軽くなったのが革命的です。今までは 0 -> 100 の心理的コストが大きくてエディタを開くところに辿り着いていなかったんだなぁというのを実感しました。
なんだかんだ一文字書き始めてしまえばそこからは進むんですよね。私は骨組みと仕上げはあまり苦にならないので、合っている方法を見つけられたと思います。

というわけでこの記事もAIによる肉付けの助けを借りて書いてみましたが、どうでしょう？
といっても結局ほとんどリライトしているので、今までと読み味は変わらないかなと思います。笑

最近は個人的にもAIまわりで新しい発見が多いので、こういう工夫で執筆の負荷を減らして色々発信していけたらと思っています！

最後におまけとして、この記事の骨組みも置いておきます。

この記事の骨組み
  • 文章表現にこだわりが強く、今まで執筆にAIを使うことができなかった
  • 自分の文章として最大限違和感のない形でドラフトを作成する方法を紹介する

必要なもの

  • 過去自分が書いてきた記事
  • AIクライアント
    • CursorやRooのようなエディタ型がおすすめ

前準備

インプット材料の準備

  • 過去自分が書いた記事をテキスト形式のファイルとしてダウンロードし、articlesディレクトリに格納する
    • zennならエクスポートができる

文体の把握

まずAIに過去記事を読ませ、特徴を別ファイルにまとめさせる

@articles このフォルダの中の記事全部読んで、私の文体や文章の特徴を把握して、writing-style.mdにまとめて。

自分の記事を読ませて抽出させた特徴も貼っておきます。（恥ずかしいけど…）

:::details writing-style.md
// あとからここにいれる
:::

執筆

内容を雑に書き出す

まず内容は自分が出さないとどうしようもないので、伝えたい内容を新規ファイルに雑に書き出していく。
箇条書き、かつ読みやすさとかはこの時点では気にしなくていいのでだいぶ楽。
私はアウトラインはここで見出しとして作ってしまいます。構造化が不慣れな場合はそこもAIと対話しつつ手伝ってもらってもいいかも。

例としてこの記事と、前回書いた 個人的 Vibe Coding のやりかた のドラフトを掲載してみます。（恥ずかしいけど…）

:::details この記事の雑書き出し
// あとからここにいれる
:::

:::details Vibe Coding記事の雑書き出し
// あとからここにいれる
:::

AIによるドラフト執筆

@file.md 構成書いたので、@writing-style.md を踏まえて、記事にしてみて。いま全部箇条書きだけど、基本平文にしたい。今書いてる文章はそのまま使ってほしいんじゃなくて内容を伝えたいものなので、表現とかは変えてOK。

これでドラフトを書き上げてくれます。プロンプトは好みに応じて修正してください。

調整

記事を読んでみて、気になるところを修正します。自分がゼロから書いたらどうなるか、のイメージは思い浮かべられるので、そこと一致させます。

AIを使う使わないの差分としては、

  • AIなし： 0 -> 100 すべて自分
  • AIあり： 0 -> 20 は自分（内容書き出し）、 20 -> 80 をAI、 80 -> 100 を自分

のイメージです。
半分以下になっています。
あと最初の作業が要点吐き出すだけでいいので、着手ハードルがすごく下がる実感があります。
書き始めると結構自分の言葉でも書けちゃったりする。

むすびのことば

Discussion