AI に技術ブログを書かせてみてわかったこと

これまで私は、AI に記事を書かせることにあまりよい印象を持っていませんでした。AI が生成する文章は一般論に寄りすぎていて、冗長になりがちです。整ってはいるものの、わざわざその人の記事を読む理由が見つからない。そのような文章を何度も目にしてきました。

私が技術ブログを書く主な目的は、自分が新しい技術を学ぶことです。AI に記事を書かせれば、自分で調べ、考え、文章にする過程を飛ばしてしまうのではないかという懸念もありました。そのため、これまで記事は自分の手で書き、AI の利用は誤字脱字の指摘にとどめていました。

しかし最近、AI に記事を書かせて大きな反響を呼んだ事例も出てきています。松浦勝人氏の事例では、AI が自動で note のアカウントを作成して投稿した記事が、1 週間で多くの読者を集めたと明かされていました。AI には松浦氏の 60 年分のデータを入れており、過去のブログ、10 年間の連載、YouTube の生配信も参照させているとのことです。

この事例を見て、批判されているのは AI という執筆手段そのものではなく、書き手の体験や固有の材料が含まれていない低品質なコンテンツなのではないかと考えました。AI を使っていても、長年の経験という材料があれば、一般論ではない文章を作れるという裏返しの事例に見えます。

もう 1 つ印象に残ったのが、小樽商科大学の中島大輔氏が公開した期末レポートの講評です。AI にレポートを書かせた学生へ、教員としてどのように向き合ったかを、自身の学生時代の失敗談や講義中の出来事を交え伝える文章でした。最後にこの講評自体も AI に書かせたものだと明かされるのですが、私は普通に読んでいて、それまで AI が書いた文章だとはつゆほども思いませんでした。

AI に記事を書かせることに対して、これまで抱いていた嫌悪感は、単に私が AI の使い方を知らなかっただけなのかもしれません。実際には何も試していないのに嫌悪感だけを抱くのはフェアではないと思い、ここ数週間は AI による技術ブログの執筆を試してみました。

この記事では、AI に技術ブログを書かせるためにどのような方法を試したのかについて紹介します。

AI に技術ブログを書かせてみた

AI 特有の文体とならないように、まずは過去に書いた記事から共通する構成や文体を AI に分析させるところから始めました。幸いにも、私は過去に書いた記事を GitHub 上で管理しており、5 年分のブログ記事をすべて参照させることができたので良い材料になりました。導入では読者が抱える具体的な問題から始めること、必要な概念を説明してからコードへ進むこと、最後にまとめと参考資料を置くことといった構成の共通点を抽出し、文体の特徴も分析させました。

sapper-blog-app/contents/BLOG_WRITING_GUIDE.md at main · azukiazusa1/sapper-blog-app

Contribute to azukiazusa1/sapper-blog-app development by creating an account on GitHub.

github.com

分析結果をもとに、技術ブログを書くためのスキルを作成しました。単に過去記事の文体を真似させるだけでなく、普段私が記事を書くときに行っている以下の過程を組み込んでいます。

公式ドキュメントや仕様、Issue、Pull Request など仕様策定の議論といった一次情報を調べる
API が現在の形になった設計理由や、検討された代替案を確認する
実行可能なコードサンプルを作成し、実際の環境で動作を検証する
文章と技術的な正確性をレビューする

このスキルには、私が記事を書くときのエッセンスを詰め込んでいます。一次情報を調べて設計理由を理解し、サンプルを動かすという過程です。コードサンプルを作成して検証するように指示しているため、生成された記事を読むだけで終わらず、私自身も同じコードを動かして結果を確認できます。

スキルを使うと、ぱっと見た限りでは既存の記事とそれほど変わらない初稿が生成されますが、一通り読んでみるとまだブラッシュアップすべき箇所が多く見つかります。ここから先が、人間が記事を完成させるための作業です。AI が生成した文章をそのまま公開するのではなく、私自身が読んで疑問に思った箇所を整理し、必要な情報を追加していきます。

例えば「TanStack Virtual で大量の要素を仮想化して描画する」の記事では、冒頭の説明は程々に、いきなりライブラリの使い方から始まっていました。そもそも仮想化とは何か、どのような条件で大量の DOM がパフォーマンスへ影響するのか、なぜ仮想化が必要なのかという説明が不足していたのです。

そこで仮想化自体の説明を加えたり、DOM の要素数だけでなくどのような条件でパフォーマンスに影響を与えるのかを追加で調査してもらったりしました。また自身の知見を元に、まずは実装が単純なページングを検討し、ページの境界を意識せず連続して閲覧する必要がある場合に仮想化を選ぶ、という私なりの判断基準を加えています。

他にも説明していないコードが突然登場する箇所は別のセクションに分けるなど、自分自身が読んで疑問に思う箇所を整理して、読者が理解しやすい順番に並べ替えます。

自分で説明できないと感じた箇所では、AI に徹底的に質問します。なぜその説明が必要なのか、根拠となるソースはどこか、別の選択肢と比べて何が違うのかを、自分の言葉で説明できるまで確認します。その質問攻めの中で、AI 自身が曖昧なまま出力していた部分もよく発見できます。また AI の文章は全体的に冗長になりやすいため、どこまで文章を削れるかも重要です。足し算よりも引き算が文章をより良いものにするとはよく言ったものです。

コードを動かしたときに何が起きたのか、どこで戸惑ったのかといった体験は、AI が一次情報を調べただけでは知り得ません。操作や見た目が重要な箇所では、自分で試した結果を文章や画像として随時加える必要があります。「宣言的にカメラ・マイク権限を要求する <usermedia> 要素」の記事では、Chrome で実際に機能を試し、ユーザーへ許可を求めるダイアログやブラウザの設定画面、要素のスタイルが制約に違反した状態などのスクリーンショットを、わかりやすさのために追加しました。

AI に書かせても学習効果は大きく失われなかった

AI に記事を書かせる前に最も懸念していたのは、ブログを書く主な目的である学習の効果が失われることでした。しかし、数週間試した範囲では、意外にも学習という観点で失われたものはそれほど多くないと感じています。

まず、自分が知らないトピックについて、普段から見慣れた記事の構成で概要を知ることができます。疑問に思った箇所は、相手の時間を気にせず何度でも質問できます。比較用のコードや小さな検証もすぐに用意してくれたり、「これは本当にそうなのか？」と感じた箇所のソースを求めたりできるため、情報収集と試行錯誤の効率は上がりました。

一方で、AI の回答へ毎回同意するだけでは学習になりません。生成された構成や説明に対して、何がわからないのか、どの順番なら理解しやすいのか、自分の経験から何を補うべきかを考える必要があります。結局は一度自分の言葉で考えてから、質問や改善の指示として AI に伝えなければ、記事はよくなりません。

もちろん、すべての学習方法が同じになるわけではありません。何もない状態から文章を組み立てる時間や、コードを一文字ずつ入力する時間は減りました。その代わり、初稿を批判的に読み、主張の根拠を確かめ、説明の順番を考える時間が増えました。私にとっては、学習がなくなったというよりも、学習の中心が「書くこと」から「問い、検証し、編集すること」へ移ったという感覚に近いです。

嫌われているのは AI ではなく低品質な記事ではないか

AI が書いた記事に対する否定的な反応を見ていると、AI が使われたこと自体よりも、出力をほとんど確認せずに公開したような記事が批判されているのではないかと思います。どこかで読んだ一般論を長く言い換えただけで、書き手の体験も判断もなく、事実関係の検証もされていないといった文章が当てはまります。そのような記事は、AI を使っているかどうかにかかわらず、読む価値を見つけにくいでしょう。

AI を使えば低品質な記事も大量に作れるため、そのような記事を目にする機会が増えました。一方で、十分な材料を与え、書き手が内容に責任を持って編集した文章は、そもそも AI が生成したものだと気づかれない可能性があります。「AI が書いたと気づいた記事」だけを数えれば、AI の記事はどれも低品質だという結論になりやすくなります。

松浦氏の 60 年分の経験や、中島氏の講義と学生時代の思い出は、AI が何もないところから作り出したものではありません。AI は渡された材料を整理し、文章へ変換していますが、その文章を一般論ではないものにしているのは、書き手が蓄積してきた経験です。AI を使うことで書き手自身の体験が不要になるのではなく、むしろ体験や独自の判断をどれだけ材料として渡せるかが重要になるのだと思います。

私自身も過去 5 年間技術ブログを書き続けた上で身につけた「型」があるからこそ、一定の水準を確保できたのではないかと感じています。

執筆時間はそれほど短くならなかった

実際に試す前は、AI に記事を書かせれば執筆時間を大きく短縮できるのではないかと考えていました。しかし、今のところ、記事に使う時間は自分の手で書いていたときとそれほど変わりません。

AI は調査、比較用のコード、初稿の作成を高速に進めてくれる一方で、出力された内容の理解や一次情報の読み直しには相応の時間がかかります。コードを自分でも動かし、体験を加える過程も省けません。わからないことを徹底的に質問でき実験のコストも小さくなっているので、興味を持った個所を深掘りしすぎて、以前より時間を使う場合すらあります。