AIに記事を書かせる方法＆めちゃくちゃ勉強になった話
経緯
最初はTerraformでの「本番環境ドリフト検知」について、AIが出してきたベストプラクティスが間違っているのではないかという疑念からAIを追求したところ、AIが観念して撤回したところで、そのことを「AIがベストプラクティスと言っていることが実は正しいか不明」みたいなことで記事化しようとした。
現在の最終形は、GitHubにリポジトリを作って、そこにPushすればZennに記事として投稿されるという、Zennが提供しているGitHub連携を使って、ローカルでClaude Codeに記事を書かせてPushするスタイル。
最初は「AIに下書き投稿させて、自分がちょいちょい指示を出して記事に魂入れて公開すれば楽ちんじゃね？しかも外出先からスマホでできれば思いついた時にすぐ記事化できるやん」という浅はかな発想でしたが、記事への魂入れ（自分の経験、意見、試行錯誤等を追加する作業）は、結局自分がやらないと自分の気が済まないということに気づき、利便性を捨ててローカルで編集することに落ち着きました。
完成形としては雛形をClaude Codeに作らせて、そこから手を入れてPushし公開という流れ。
ただし、その魂入れの段階において、思いがけずかなりの時間を費やすことになった。（後述）
AIに記事を書かせるまで
1. 執筆環境構築
ローカルに場所作成し、Zenn CLIインストール
$ mkdir zenn-articles
$ cd zenn-articles
$ npm init --yes
$ npm install zenn-cli
$ npx zenn init
GitHub上でプライベートリポジトリを作成しPush
gh コマンドでやってるけど、ブラウザ上で直接作成しても可。
$ gh repo create zenn-articles --private --source=. --remote=upstream
Zennと連携
詳しくはこちら → https://zenn.dev/zenn/articles/connect-to-github
2. 執筆
元ネタがあればなんでも執筆させることができる。
試行錯誤系
まず、開発をしているリポジトリで、Gitの過去のコミットを確認させて、「別のAIエージェントに技術記事書かせるから、このリポジトリで試行錯誤した内容をまとめてプロンプト作って」と指示。
できたプロンプトと、現在の最終型のソースコードの一部を、執筆環境のAIエージェントに投げて下書きを完成させる。
チャットでの壁打ち系
壁打ちして何か良いことが分かったとしたら、そこから「別のAIエージェントに技術記事書かせるから、今までの会話をまとめてプロンプト作って」と指示。あとは上と一緒。
その他
まあ基本一緒で、「AIエージェントに記事書かせるからまとめてプロンプト作って」でいいんじゃないか。
3. 校正＆投稿
zenn cliのプレビュー機能で実際に記事を読み、固まったら記事として投稿する。
気を付けること
構成は自分で作成すること
あくまでもドラフトの作成者。自分で修正を入れてから必ず公開する。なのでドラフトを作成させるプロンプトの中に、自分で考えた構成（あるいは話の段取りでも良い）を含めるようにする。具体的なやり方などはAIに調べさせたり、まとめさせる。匿名化などもさせる。あまりにも他のページのコピペすぎる内容であれば変更を指示するか、URLを貼って素直に「他を参照してください」と言う。
反復改善フローを入れる
自分はClaude Codeなので、 CLAUDE.md に口調・トーンや、記事化するにあたっての注意事項を含めておく。これを作成するごとに見直してブラッシュアップさせていく。
ちなみに自分がAIに守らせているのは以下の5箇条（ただしこれもGrokに現在の記事化のトレンドを聞いてまとめたもの）。
- Tracability（参考文献・引用元の明示）
- Testability（コード例があり再現可能、バージョン明記）
- Separatability（事実と意見・考察を分ける）
- Readability（読みやすい構成にする）
- Originality（自身の体験・考察・試行錯誤・洞察を入れる）
余談（という名の本題）
1. Claudeデスクトップアプリのディスパッチを試して失敗
ディスパッチという、家のPCでClaudeを立ち上げっぱなしにしておいて、出先からスマホで指示をしたらローカルのコードベースを編集してくれるという機能を使ってやろうとしたところ、1つの指示でワークツリーとブランチを作りまくるので、Gitの履歴がカオスになって、イライラしてやめた。
しかもPR出すまで作成内容が分からず、そのPRを見てさらにふわっとClaudeに指示を出すだけになるので、魂入れ作業が自分の腹落ちするものにならなかった。開発にはディスパッチ機能は向いてるかもだけど、記事執筆には向かない。
2. AIが書いた記事に「検証しました」とあったので本当に検証したら検証が間違っていた
まさに「AIは嘘をつく可能性がある」ということを体現してしまった話。
Zenn CLIにはプレビュー機能というものがあり、これは極めて本物っぽくプレビューができるというもの。これを使ってプレビューをしていたら「検証しました」みたいなことが書いてあったけど、実際は検証というよりとにかくエラー解消のために試行錯誤していただけ。
で、その中に自信満々に言い切っているところがあって、それが人の書いた記事ならいいけど自分の名前で出す記事なら自分が確かめる必要があると思い、実際に検証してみたところ、でっち上げであることが判明。
おそらく結論ありきで間を埋めてしまった可能性が高い。（今回は実際に実装するタスクではなく記事を書き上げるタスクなので、実際に調べて検証をするという選択肢は優先度が非常に下げられたのではないか、と推測）
3. 開発中にAIに言われたベストプラクティスが結局ベストプラクティスだった
最初のきっかけであった「AIが提示したベストプラクティス」は、その後検証を経て消極的なベストプラクティスであったことが分かった。消極的というのは、現在解消されていない不具合っぽくて、本来想定されるべきものではないけど仕方なくそうしている、という話。
4. そもそも開発リポジトリにおいてもAIが間違っていた
今回のきっかけとなったドリフト自動検知のためのGitHub Actionsのコードで、AIが残したコメントが間違っていたという話。
最初はこう。
jobs:
drift-check:
runs-on: ubuntu-latest
permissions:
id-token: write # OIDC トークン取得に必要
contents: read
issues: write # Issue 作成に必要
steps:
...
- name: terraform plan（ドリフト検知）
id: plan
working-directory: infra/terraform/envs/prod
# -detailed-exitcode: 差分あり=2, 差分なし=0, エラー=1
# 差分あり(2)の場合もエラー扱いにしないため continue-on-error: true
continue-on-error: true
env:
...
run: |
# GitHub Actions のデフォルトは `bash -eo pipefail` なので、
# terraform plan が exit 2（差分あり）を返すと pipefail でパイプライン全体が
# 失敗扱いになり、-e でこの後の行に到達せず exitcode が記録されない。
# ここでは set +e で -e を無効化し、明示的に PIPESTATUS を取得する。
set +e
terraform plan \
-detailed-exitcode \
-no-color \
2>&1 | tee plan_output.txt
EXITCODE=${PIPESTATUS[0]}
echo "terraform plan exitcode=${EXITCODE}"
echo "exitcode=${EXITCODE}" >> "$GITHUB_OUTPUT"
exit 0
- これを元に記事を書かせる
- AIはこれが合っていると思い込んでさも努力したかのように途中の試行錯誤を「検証しました」というストーリーとしてでっち上げる
- その検証を検証してみると間違っていることが判明
- さらに検証を進めると、このコメントの内容も厳密には間違っていることが判明
詳しい説明は別記事にまとめます。
5. この記事は95%人間が書きました
載せているソースコードはAIが書いたので厳密には100%ではない。そしてタイトル詐欺ではない。次からAIに書かせる。
参考資料
アカウントにGitHubリポジトリを連携してZennのコンテンツを管理する
Zenn CLIをインストールする
Zenn CLIで記事・本を管理する方法
Discussion