はじめに
前回公開した以下の記事ですが、全て生成AIに書かせました。
私自身が直接関与したのは、アイディア出しとレビュー、Markdownの記法調整だけで、文章は全て生成AIで作りきりました。
使用したLLMは以下の通りです。
| LLM | バージョン | 課金の有無 |
|---|---|---|
| Grok | Grok 4 | 無し |
| ChatGPT | GPT 5 | 無し |
| Gemini | Gemini 2.5 Flash | 無し |
| Claude | Claude 3.7 Sonnet | 有 |
本記事では、どのようなプロセスで生成AIに記事を作成させたかを綴っていきます。
1. 壁打ち
10/8にSpannerの設計論文への興味から、Grokに論文を要約させたことが始まりです。
Grokはかなり高い確率でハルシネーションを起こすので、全ての情報に対しソースを求めつつ、私自身が理解した内容と論文の内容に齟齬が生じていないかをチェックしてもらいました。それでも不安な場合はGeminiとChatGPTの両方を使ってファクトチェックを実施しました。
その内、Oracle AI Database 26aiでも水平スケールに関する機能強化があったことを思い出し、Oracle Database 23aiで搭載された機能と、26aiで進化した機能についても同様にGrokと壁打ちし、私自身の理解を深めつつGrokにコンテキストとして覚えさせました。同じ要領でMySQLやPostgreSQLについてもGrokと10/21まで壁打ちしました。
Grokはチャットルーム単位でコンテキストを保持する仕様となっているので、日を跨いだ場合でも同一チャットルームで壁打ちを続けたことが、後々のプロセスの助けになりました。
記事内では触れませんでしたが、SAP HANAやMongo DBなどのテクノロジーについてもGrokと追求しました。
2. 記事作成
生成AIに記事を作らせようと思ったきっかけは、広木大地（ @hirokidaichi ）さんの講演です。
2025/11/13発売予定のAIエージェント 人類と協働する機械を、冒頭で書いた内容と全く同じく「全ての文章を生成AIに作らせた」と拝聴したので、私も挑戦してみようと思った次第です。
10/22に、Grokへ記事の作成を依頼しました。テーマは最初から「Oracle AI DB 26aiの進化と、Spannerの設計から読み解くRDBMS進化論」で決まっていたものの、初稿はおおよそ400文字でした。
その後、私のレビュー→修正と加筆を約20回繰り返しました。繰り返すたびに文章量が増え、最も文字数が多くなった時には4000字を超過していました。（mermaidの記述や脚注込み）
途中、私が過去に書いたQiitaの記事をGrokに読み取らせて私自身の文体を真似てもらったところ、かなりカジュアル度合いの強い記事になってしまったので、それを是正してもらうこともありました。
ちなみに、ここまでのステップは全てスマホの操作で完結しています。
3. LLMの乗り換え
4000字を超える規模の文章を何度もレビューするのが辛くなったので、プロンプト入力やレビューをスマホからPCへ乗り換えました。
また、Grokのチャットルームも壁打ちの頃から使用し続けた結果、PCで開くのもメモリが大量に必要となる規模に肥大化し、いよいよコンテキストをエクスポートする必要が出てきたので、合わせてLLMも乗り換えを検討することに。
そこで、まずはChatGPTに乗り換えてみたところ、なんとわずか2往復で1日の使用量上限に到達。ならばと思いGeminiにも任せてみたものの、こちらはmermaidのコードブロックが邪魔をして、コピペ可能な体裁で回答を生成できませんでした。
Geminiの無料プランでは、mdファイルを生成させるなどができず、チャットのテキスト形式でしかやり取りができない仕様になっています。コードブロックを含まないMarkdownや、プレーンテキスト形式のコンテンツが欲しい場合であれば十分に利用に堪えられます。
他の案として、CursorかClaudeのどちらかの使用を検討し「せっかくなら使用経験のないLLMを」と思いClaudeを使い始めることに決定。Claudeにも私自身の文体を読み取らせ、コンテキストは全てローカルファイルに保存してもらうようにして、作業を継続しました。
記事もローカルのmdファイル上でやり取りするようになったため、変更差分が簡単に見られるようになりレビューが爆速化しました。記事の大枠はClaudeを使い始めてから2日程度で出来上がりました。
AI臭さの脱臭
ある程度文章が出来上がってくると、ディティール、特に不自然な文章であったり、生成AIに作らせた文章でありがちな表現が、目に留まるようになりました。
文章表現以外でも、コロンの多用、過剰な強調も目立ったので、生成AI自身に「生成AIが生成した文章の特徴」を分析させて、記事の文章を見直し・修正を繰り返し行わせました。
4. 地獄の品質担保
文章の正確性に関しては、初期からGeminiとChatGPTでファクトチェックを行い、私自身も根拠となる一次ソースを読むことで担保できていました。しかし、割とノーチェックだった脚注を最後に確認したところ、30件超のリンク先URLと、リンク先のページタイトルがほぼ全て誤りだったことが判明しました。
一番最初の時から脚注として記述されていたSpannerの論文さえ、リンク先が不適切（誤ってはいなかったが、リンク先から論文を探す必要があった）でした。
アクセスするとHTTPステータスが404エラーのURLだったこともザラでした。
この修正をGeminiやClaudeに任せても全くうまくいかず、逐一私がWEB上のソースを探し出して、「指摘」という形を通してClaudeに修正してもらいました。結果として、この作業だけで最終的に4時間程度使う羽目に。もはやこの工程に関しては生成AIを噛ませない（指示を出さずに自分で直接修正する）ほうがはるかに楽でしたが、生成AIに全部書かせると方針を立てたので私も意地でやり通しました。
Qiitaのコミュニティガイドラインにもある通り、AIで生成したコンテンツが正しい内容であることを、きちんと確認した上で記事投稿する必要があります。記事に対して人が責任を負うことになる点は、くれぐれも忘れないようにしましょう。
感想
生成AIに期待していることを全て言語化する必要があることに加え、初回はコンテキストを作りながら進める必要もあり、当初思っていたよりも苦労が多く感じられました。
また、記事の本文はもちろんのこと、脚注のURLが正しいかも細かく人の目でレビューが必要だったので、それをチェックしている4時間の間は特に「自分で記事を書いてしまった方が絶対早い」という思いに何度も何度も駆られました。
ただ、この苦労を通して見えてきたのは、生成AIの得意・不得意の境界線です。文章の「生成」は得意でも、URLの検証やファクトチェックといった「事実確認」は現時点では人間がやるしかありません。意地でやり通したからこそ、この現実が身に染みて分かりました。
コーディングでも全く同じことが言えますが、生成AIに全てを任せるのではなく、バランスをとりながらAIが得意な部分だけ任せるような使い方が最も良い手法だと感じました。
【Appendix】出来上がったもの
GrokからClaudeへ乗り換えた際に、Claude自身に生成させたコンテキスト情報です。やりたいこともコンテキストとして明記しているので、雑に「こういう記事を書きたい」と依頼するだけで、それっぽい記事が作れます。
生成AI臭さを脱臭させるために、Claude自身に生成させたガイドラインです。
【Appendix】中間成果物
警告
以降のファイルはファクトチェック前の情報や、記述内容の正確性を欠いた状態の文章が記述されている、記事を作り上げていく過程で生成された中間ファイルです。生成AIで記事を練り上げていくプロセスで、どのようなAI臭さがあったか、Grokがイメージする @take-yoda らしさとはどういうものか、などの参考として掲載します。
AI臭さ脱臭前の記事
箇条書きと太字装飾だらけの記事になっていました。文体もどことなく不自然な箇所がちらほら見られます。
Grokが分析して再現した「私らしい」文体
普段の私って、こんな文章書いているのかなぁ！？