AIに「この記事を公開して」と頼んだら、ブログに新しい記事が追加される。
Cloudflare版ノマドラボを作り始めたとき、僕が面白いと思ったのは、そんな運営の形だった。
ただ、記事を作れることと、確認なしで公開していいことは違う。
今回、Cloudflare版の第二弾記事をAI社員と一緒に制作し、GitHubからCloudflare Pagesへ公開するところまで進めた。その間には、本文の修正、画像制作、独立した品質確認、そして公開を一度待つ判断があった。
実際の流れを振り返ると、AIに任せる工程を増やすほど、人間の承認をどこに置くかが大切になってくる。
これは、完全自動投稿が完成したという話ではない。AI社員に制作を支えてもらいながら、公開判断は人間が持つという方法を試した記録だ。
AIと作ったブログで、次に試したかったこと
Cloudflare版ノマドラボは、今まで運営してきたWordPressのサイトとは別に作った試作ブログだ。
最初の記事では、GitHubに保存したサイトのファイルをCloudflare Pagesで公開するところまでを記録した。
次の第二弾では、サイト制作でAIが形にしたことと、僕が判断したことを整理した。
第二弾の記事は「AIと一緒にブログを作ったら、人間の仕事は何が残るのか？｜Cloudflareで試した役割分担」で読める。
その次に確かめたかったのは、役割分担を考え方で終わらせず、記事を一本公開する工程の中でも実行できるかということだった。
AI社員が原稿を作り、別の担当が確認し、公開してよいと判断されたものだけをサイトに反映する。言葉にすると簡単だけれど、実際に進めると「どの原稿が正本なのか」「何を確認できたら次へ進むのか」という問題が出てきた。
AI社員に記事制作を任せた流れ
第二弾は、ノマドラボ支店長から制作指示を出し、Cloudflare制作社員が記事設計と本文初稿を作るところから始めた。
主題は、AIと人間の役割分担。僕が実際に操作・判断したことと、AIが担当したことを混同しないようにする方針も決めた。
初稿をそのまま公開しなかった
初稿のあと、支店長が独立して内容を確認した。その結果、四つの限定修正が必要になった。
たとえば、GitHubへ誰がファイルを保存したかを、実行履歴なしに断定しないこと。僕が口にしていない感情を、あとから感想として足さないこと。第一弾の設定手順を繰り返しすぎないこと。そして、すでに動いている機能と、これから目指す自動化を分けることだ。
Cloudflare制作社員がその四点を修正し、支店長が再び確認した。ここで本文がA判定となり、以後は確定原稿を勝手に書き換えないことになった。
最初の原稿を一度で完成扱いにせず、確認した内容だけを直した。これは今回の制作で、実際に行ったことの一つだ。
本文と画像を一つの完成品にする
本文が決まったあと、アイキャッチ一枚と本文図解二枚を制作した。
画像が伝えるのも「人が決める。AIが支える。」という役割分担だ。三枚とも1200×630ピクセルに調整し、記事内の配置、画像の説明文（alt）、キャプションを決めた。
特に公開フローの図解は、これから目指す運用を表したものだった。現在すべてが自動で動いているように見えないよう、「今後目指す運用イメージ」と明記する方針にした。
画像が完成しても、それだけでは記事全体の完成ではない。本文と組み合わせた状態で、配置と意味が合っているかを確かめる必要があった。
なぜ制作後に何度もQAを行ったのか
今回のQAは、文章を何度も読み直すだけの作業ではなかった。
内容の事実関係を確認すること。確定した原稿と実装用データが一致していること。見出しやリンク、画像が正しい位置にあること。それぞれ確認する対象が違っていた。
第二弾ではH2が六本、H3が二本、第一弾への内部リンクが一本という構成を保った。画像も三枚あり、代替テキストとキャプションまで確認対象にした。
確定原稿を参照できなかったときは止まった
実際に一度、作業が保留になった場面がある。
本文と画像をまとめて確認しようとしたとき、Cloudflare制作社員が、支店長のA判定を受けた確定本文の全文を取得できなかった。
ここで、以前の初稿や修正内容から文章を推測して作り直すことはしなかった。支店長へ未確認事項として報告し、正本が渡されるまで照合を止めた。
その後、支店長が確定本文を全文提示したので、本文を変えずに画像との統合QAを再開できた。
これはCloudflareの障害でも、重大なプログラムエラーでもない。何を正しい原稿とするか確認できなかったため、公開へ進まなかったという制作上の出来事だ。
僕は、この「いったん止まる」判断も、AIと仕事を分担するときに必要な工程だと考えている。
GitHubとCloudflareの公開で注意したこと
完成品のQAが通っても、すぐにGitHubを更新したわけではない。
今回のサイトは、GitHubの本番ブランチmainが更新されると、接続先のCloudflare Pagesへ自動デプロイされる構成だった。
だから、原稿をGitHubの本番ブランチに反映する操作は、単にファイルを保存することではない。公開サイトを更新するきっかけにもなる。
支店長は完成品の品質確認を進めたが、その判定と、僕が本番公開を認めることは別にした。最終的に社長の公開GOが出るまで、mainは更新しない運用を守った。
公開の承認後、Cloudflare制作社員が変更差分を確認し、第二弾の記事データを含むHTMLファイルと、新しく用意した画像三枚を一つのコミットでmainに反映した。
そのあとCloudflareの公開URLを開き、記事の表示と画像の読み込みを確認した。GitHubに保存されているだけで、読者に届くとは限らない。実際に公開画面に出ているかどうかまでが確認の対象だった。
人間の承認を残したことで分かったこと
今回、AI社員は記事の設計、本文制作、限定修正、画像準備、実装用データの整備、公開操作を支えた。
支店長は制作途中の品質を判定し、必要な修正や保留を指示した。そして僕は、完成品を公開してよいかを最終的に判断した。
実際の本番確認では、記事のH2六本とH3二本、画像三枚とその説明文、前の記事へのリンク、第一弾とトップページが保たれていることを確かめた。記事一覧に第二弾が追加され、検索機能も動いていた。
PC表示を確認し、スマートフォンの表示についても僕からOKを伝えた。公開後の最終QAはA判定で完了した。
ここで区別しておきたいのは、AI社員が制作を進められたことと、AIが独断で公開可否を決めたことは同じではない、という点だ。
作業が進んでも、確定原稿が確認できなければ止める。本文と画像がそろっても、公開承認がなければ本番には反映しない。公開したら、読者と同じ画面で表示を確かめる。
今回の記録から僕が得たのは、「AIに任せる」と「確認を手放す」を分けて考えるという判断基準だった。
次に改善したい記事公開の仕組み
第二弾は公開まで進められた。でも、記事の作成から承認までが自動で管理される仕組みが完成したわけではない。
次に整えたいのは、どの本文が確定版なのかを見失わず、公開前の確認を繰り返しやすくすることだ。
たとえば、原稿の確定版と画像を一つの単位で管理し、本文・画像・リンクのチェック結果を残す。確認を通過したものだけを公開候補にして、最後のGOが出るまで本番ブランチに反映しない。
さらに、公開後には実際のページを確認し、必要なら更新内容を追跡できるようにしたい。
これは、これから検討・検証する運用だ。今回の経験だけで、制作時間が短縮されたとか、ブログ運営の収益が改善したとは言えない。
AIと一緒に記事を公開してみたい人は、まず一つだけ決めてみてほしい。
「何が確認できたら、その記事を公開してよいことにするか？」
文章が完成したら公開なのか。事実やリンク、画像を確認してからなのか。最後に自分のGOが必要なのか。
その基準を一行で決めるだけでも、AIに依頼する仕事と、自分が受け持つ判断を分けやすくなる。
AIに制作を任せても、公開判断まで手放す必要はない。
僕はこれからも、その役割分担を小さく試しながら整えていきたい。