AIに記事を書かせたら、やっていない運用まで整ってしまった――公開後の違和感から執筆ルールを変えた話
2026年11月13日、私はAIへ「今日の記事を書いて公開して」と頼みました。
AIは、前の記事の次回予告を読み、担当者が変わっても毎日デプロイを続けるための引き継ぎ資料をテーマに選びました。本文を書き、画像を作り、公開前の検査を通し、私の承認後にQiitaへ公開しました。
公開されたのは、次の記事です。
担当者が変わっても毎日デプロイを続ける――自動化と手動復旧を引き継ぐ運用資料の作り方
文章は読みやすく、構成も整っていました。しかし、公開後に読み返した私は、AIへ質問しました。
これは私が日々やっていることの実態にともなっていると思いますか？
答えは「完全には伴っていない」でした。
記事には、私が実際に続けている確認方法だけでなく、まだ行っていない引き継ぎ体制や点検方法まで含まれていました。内容そのものが役に立たないわけではありません。問題は、実際の記録と一般的な提案の境界が見えないまま、私の運用を題材にした記事として公開したことでした。
この記事では、昨日実際に起きたことと、その直後に変更した執筆ルールを記録します。理想的な記事の作り方ではなく、AIがもっともらしい説明を広げたとき、どこで止めるべきだったかを振り返ります。
事実だった部分と、提案だった部分
昨日の記事には、私の運用に沿う部分がありました。
- AIへ記事の下書きと整理を任せる
- ローカルのMarkdownを公開原稿として残す
- 画像をGitHubの公開用リポジトリへ置く
- 公開前にタイトル、画像URL、タグ、重複を検査する
- Qiitaへの全体公開前に人間が承認する
- 公開後にURL、記事ID、本文一致を確認する
これらは、今回の公開記録やプロジェクト内のスケジュールで確認できます。
一方、次の内容は、私が日々実行していると確認できたものではありませんでした。
- 運用の地図、日次カード、異常時カード、復旧カード、変更履歴の5資料を使う
- 担当者、承認者、サービス管理者が分かれている
- 引き継ぎを見学、交代、単独実行の3段階で進める
- 通常日、異常日、復旧後のリハーサルを行う
- 月次で権限や引き継ぎ資料を点検する
これらは「引き継ぎ可能な運用を作るなら役立つ提案」ではあります。しかし、実施記録を確認せず、日々の実態と同じ流れの中へ置いてしまいました。
事実と提案を表へ分けると、問題がはっきりします。
| 内容 | 確認できる根拠 | 区分 |
|---|---|---|
| AIが原稿を作る | 今回の原稿と作業記録 | 実際に行った |
| 画像をGitHubへ反映する | Assetsのcommit | 実際に行った |
| 公開前に人が承認する | 公開直前の会話と記録 | 実際に行った |
| 5種類の引き継ぎ資料を使う | 実施記録なし | 提案 |
| 担当者交代のリハーサル | 実施記録なし | 提案 |
| 月次点検 | 実施記録なし | 提案 |
この表を公開前に作っていれば、記事の語り方を変えられました。
なぜ公開前検査を通ってしまったのか
昨日の公開前検査は、次の項目を確認していました。
先頭見出しとタイトルが一致する
本文が必要な長さに達している
画像URLがHTTP 200を返す
ローカル画像が4点ある
禁止マーカーが残っていない
タグが5個以内
同じタイトルの記事がない
直前の記事が公開済み
検査はすべて通りました。Qiita APIの結果も、全体公開、本文一致、5タグを示していました。
しかし、この検査が確認していたのは「投稿できる状態か」です。
文章の形式が整っているか
画像を表示できるか
重複投稿ではないか
公開結果が原稿と同じか
次の問いは入っていませんでした。
本文に書いた運用を本人が実際に行っているか
その行動を確認できる記録があるか
一般的な提案を体験談のように書いていないか
技術的な公開ゲートは正常に働きました。足りなかったのは、記事の主語と根拠を確認する編集ゲートでした。
AIは空白を「良い運用」で埋めやすい
今回、AIは前の記事の次回予告から、引き継ぎ資料というテーマを選びました。
テーマに沿って記事を完成させるため、引き継ぎに必要そうな要素を整理しました。5種類の資料、役割分担、リハーサル、更新条件という構成は、説明としては自然です。
しかし、「説明として自然」と「本人が実際に行っている」は別です。
AIは、材料が足りないときでも、前後の文章から自然な続きを作れます。記事制作では、この能力が次のずれを生みます。
前の記事で停止条件を書いた
→ 次は引き継ぎ資料が必要そう
→ 5種類に分けると説明しやすい
→ リハーサルまで書くと記事として完成する
最後まで読むと、筋の通った記事になります。そのため、事実の不足より文章の完成度が目立ちます。
今回の問題は、架空のVersion番号や存在しない機能を一文だけ書いたことではありません。確認していない運用を一つずつ足し、全体として「すでに整った運用」に見える構成を作ったことでした。
公開後の一問で問題が見えた
問題を見つけたのは、自動検査ではなく、私が公開後に投げた一問でした。
これは私が日々やっていることの実態にともなっていると思いますか？
この質問によって、記事を次の2つに分けて読み直せました。
- 実際の作業記録で確認できる内容
- AIが一般的な運用として加えた内容
AIは、5種類の資料、役割分担、交代リハーサル、月次点検などが、実態確認ではなく提案だったと認めました。
私は、次回以降は実態に伴うようにしようと伝えました。
ここで大切だったのは、「文章が良いか」ではなく、「これは本当に私の話か」と問い直したことです。
執筆ルールへ追加した5つの確認
会話だけで終わらせると、次の記事で同じことが起きます。そこで、プロジェクトの長期運用ルール PROJECT_RULES.md に「実態との整合」を追加しました。
追加した確認は次の5つです。
1. 執筆前に4つへ分ける
題材を、次の4区分へ分けます。
実際に行ったこと
記録で確認できること
まだ行っていないこと
一般的な提案
「実際に行った」と「記録で確認できる」は似ていますが、同じではありません。本人の記憶にある作業でも、記事へ具体的な数値や結果を書くなら、記録を確認します。
2. 記録のない運用を体験談の中心にしない
日次記録、公開履歴、GitHub差分、承認記録などで確認できない内容は、「私が行った方法」の中心に置きません。
説明に必要なら、一般例として区切ります。
3. 未実施なら語り方を変える
まだ試していない方法を書く場合は、次のように明示します。
現在の運用ではない
今後試す案である
一般的な例である
「私はこうしています」と「こうするとよさそうです」を混ぜません。
4. 実施の有無を推測しない
担当者交代、定期点検、複数人の承認体制などは、一般的な運用記事でよく登場します。しかし、私の環境で実施している証拠がなければ補いません。
5. 材料が足りなければ題材を縮める
記事を長くするために理想的な手順を足しません。確認できる材料が少なければ、質問するか、事実のある範囲へ題材を縮めます。
今日の記事で実際に行ったこと
今回の記事では、新しいルールを使いました。
まず、題材を昨日の公開後に実際に起きた出来事へ限定しました。
確認した正本は次の3つです。
- 公開済みのVol.100本文
-
PUBLISH_SCHEDULE.jsonに残った公開記録 - 違和感の確認後に更新した
PROJECT_RULES.md
そこから確認できる範囲だけを書きました。
2026年11月13日に記事を公開した
画像4点をAssetsへ反映した
Qiita APIで本文一致を確認した
公開後、実態に伴っているかを問い直した
実施していない運用が混ざっていると確認した
次回以降の執筆ルールを更新した
反対に、次のことは書いていません。
昨日の記事をすでに訂正した
新しい確認ルールで複数の記事を検証した
別の担当者が新ルールを使った
新ルールによって再発がなくなった
どれも、現時点では確認できないためです。
公開前に追加する短い質問
今後は、技術的な公開検査の前に、次の質問を使います。
この記事の中心は、実際に行ったことですか。
各判断に、確認できる記録がありますか。
実施していない方法を、現在の運用として書いていませんか。
提案がある場合、提案だと本文で分かりますか。
本人が読んだとき「これは私の話だ」と言えますか。
5つすべてに答えられなければ、公開準備完了にはしません。
この確認は、誤字やリンク切れの検査とは別に行います。文章の形式ではなく、記事と本人の実態が合っているかを見るためです。
AIへ渡す依頼文も変える
AIへ「今日の記事を書いて」とだけ頼むと、過去記事の流れから自然な続きを完成させようとします。
次回からは、依頼時に次の条件を含めます。
今日の記事は、実際の作業記録で確認できる出来事を中心にしてください。
執筆前に、材料を次の4つへ分けてください。
1. 実際に行ったこと
2. 記録で確認できること
3. まだ行っていないこと
4. 一般的な提案
3と4を体験談として書かないでください。
記事の中心に使える記録が足りなければ、推測で補わず、題材を縮めてください。
指示だけで完全に防げるわけではありません。公開前に、元記録と本文を人が見比べる工程は残します。
公開後に分かったことも記録にできる
公開後に違和感へ気づいたことは、理想的な流れではありません。しかし、その出来事自体は確認できる記録です。
AIを使った記事制作では、完成した文章が滑らかなほど、「書いてあることは正しいだろう」と受け入れやすくなります。今回の経験から、私は文章の完成度とは別に、次の問いを置くことにしました。
これは本当に、自分がやったことなのか。
この問いに答えられない部分は、削るか、提案として分けます。
まとめ
昨日の記事は、原稿、画像、公開手順という技術的な条件を満たしていました。しかし、実際に行っている運用と、AIが整理した一般的な提案の境界が曖昧でした。
今回の要点は次のとおりです。
- 読みやすい記事でも、本人の実態に沿っているとは限らない
- 公開可能性の検査と、記事の主語・根拠の確認は別である
- AIは記録の空白を、自然で望ましい手順で埋めることがある
- 執筆前に、実際・記録・未実施・提案の4つへ分ける
- 未実施の方法を体験談の中心にしない
- 材料が足りなければ、記事を広げず題材を縮める
- 公開前に「これは本当に自分がやったことか」と確認する
- 違和感を会話で終わらせず、次回の執筆ルールへ残す
最初の一歩は、AIが作った記事の各見出しへ「実際」「記録」「未実施」「提案」のどれかを付けることです。
次回は、今回追加した確認ルールを実際の記事制作で使い続け、どの確認が役立ち、どこでまだ迷ったかを、記録が揃った時点で振り返ります。