説明文： AIに記事を書かせるだけでなく、検査、修正、保存、公開、サイトマップの更新、本番確認まで任せるには？ Claude Codeを「待機係」から「最後まで片づける担当」に変える考え方と安全策。
「記事は完成しました。続きは定期処理を待ちます」。その後、公開が止まる。別の自動処理が失敗し、次の順番も来ない。AIが優秀でも、仕事は永遠に待合室だ。Claude Codeに記事公開まで任せることは、必要な権限と正規の実行手段がある範囲なら可能だ。 肝心なのは「自分でできる工程を先へ進める」と「勝手に安全策を外す」を分けること。
文章を書くAIから、終わらせるAIへ
Claude Codeは、プロジェクトのファイルを読み、編集し、コマンドを実行し、Gitの変更を保存できる開発支援ツールだ。記事工場なら仕事を次のようにつなげられる。
- 新しい記事を受け取る。
- 内容、個人情報、リンク、言語の欠けを検査する。
- 失敗した箇所を修正し、必要な検査をやり直す。
- 正規の公開用データを書き出す。
- 変更が衝突していないことを確認して正規の保存先へ記録する。
- 本番の記事本文、一覧、更新表示、サイトマップ、配信フィードを確かめる。
- 失敗が出たら原因を直し、もう一度確認する。
「記事を書きました」で帰る係と、「読者が実際に読めました」まで確かめる係は別の職種である。後者が欲しい。
定期処理や自動テストの順番を待たない
以前は「記事を投入→定時処理を待つ→確認を待つ→次の処理を待つ」のように、途中の待ち時間が積み重なることがある。コマンドで直接実行できる工程なら、Claude Codeがそこで検査し、修理し、同じ正規の公開経路へ渡せばよい。
ただし待つ順番を省くことと、必要な検査を省くことは違う。個人情報の混入、事実の重大な誤り、本文の欠落、別言語への文章の混入は止めて直す。Googleも、生成AIによって読者に価値のないページを大量生産する行為は検索の迷惑行為に当たり得るとしている。速さで品質をごまかしたら、結局あとで修正地獄だ。
「公開しました」の証拠は、公開ボタンではない
コードの保存が成功しても、公開先の画面が古いままのことはある。配信データが更新されても、記事の一覧からたどれないこともある。
本当の完了確認は、実際の公開URLを開き、正しい言語・正しい本文版が表示され、記事一覧などの入口から届くかを確かめること。画面に「成功」と出たのに読者には旧版が見えるなら、旧版を見せている事実のほうが重要だ。状態表示は報告、公開ページは現場である。
AIの行動範囲と、共同作業の衝突を決めておく
権限のない公開作業には別の正規実行先が必要だ。鍵をチャットに貼らせたり、保護を解除したりする理由にはならない。また、別の定期処理とAIが同じ原稿を同時に更新すると、古い版で新しい変更を上書きする危険がある。保存前に最新の版を照合し、公開経路は一本に保つ。
人間が毎回クリックする代わりに、事前に決めた境界・安全検査・変更履歴の下で、できる作業をAIが最後まで持つ。権限が足りない箇所と検査不合格だけを明確に報告する。この分け方なら「全部任せる」は「全部無条件に通す」にはならない。
何が楽しくなるのか
こうして単純な待ち仕事が減ると、人間は「次はどんな疑問を記事にする？」「読まれたのはなぜ？」に集中できる。AIが記事を受け取り、問題を直して公開を確かめ、人間はアクセスの変化から次のネタを見つける。手を動かす時間より、発見して考える時間の比率が増える。
「AIに丸投げしたい」の本当の意味は、検査を省くことでも人間が責任を放棄することでもない。AIができる後片づけまで人間に返さず、成果物が読者に届くところまで運ぶことだ。 待合室の椅子は撤去。次は公開ページの前で点呼を取ろう。
参考資料： Claude Code公式概要（ファイル編集・コマンド・Git操作）、Google検索セントラルの生成AIコンテンツ指針。本文の公開手順は一般的な実務モデルであり、特定環境の公開成功を保証するものではない。
