AIにnote記事制作を任せるなら、投稿後検証までスキルにしたほうがいい
はじめに
Codexでnote記事を1本作りました。
テーマは『ヴァイオレット・エヴァーガーデン』の感想記事です。最初は本文を作るだけのつもりではなく、作品について深くヒアリングしながら、本文、見出し画像、本文画像、note下書き投稿まで一気通貫で進めました。
実際に作成したnote記事はこちらです。
ただ、実際にやってみると、いちばん大事だったのは本文生成ではありませんでした。
下書き保存後に、note上で本当に記事が壊れていないか検証することでした。
今回の作業では、本文画像がエディタ上では入って見えたのに、保存後に再オープンすると消えている問題が起きました。さらに、Markdownの太字記号がnote上でそのまま残る可能性も見つかりました。
この記事では、そのときの流れと、失敗をその場限りにせず note-post / note-images / note-hobby-writer というスキルへ戻した話をまとめます。
作ったもの
今回作ったものは、次の4つです。
| 作ったもの | 内容 |
|---|---|
| note記事本文 | ヒアリングをもとにした約5000字の感想記事 |
| 見出し画像 | note一覧で内容が伝わる文字入りサムネイル |
| 本文画像 | 湖、抱擁、手紙をモチーフにしたオリジナル画像 |
| 投稿フロー改善 | 保存後検証、画像復旧、Markdown装飾確認をスキル化 |
作品の公式画像や本編スクリーンショットは使わず、構図や感情だけを参考にしたオリジナル画像を生成しました。権利面の不安を避けつつ、記事の雰囲気を支えるためです。
全体の流れ
作業の流れはこんな感じでした。
ポイントは、投稿直後の見た目ではなく、保存後に再オープンして確認したことです。
noteのエディタ上で一時的に画像が見えていても、保存後に残っているとは限りません。今回も、最初の下書き保存では本文画像が 0/3 になりました。
起きた問題
今回大きく詰まったのは3つです。
| 問題 | 起きたこと | 対応 |
|---|---|---|
| 本文画像が保存後に消えた | 投稿直後は入って見えたが、再オープン後の本文画像が 0/3 だった |
既存下書きを開き直し、本文画像だけ復旧 |
| 失敗時に下書きURLが返らなかった | スクリプトが ok:false だけ返し、復旧対象URLがわからなかった |
失敗時にもURLとスクリーンショット情報を返すよう改善 |
| Markdown装飾がnoteで崩れる可能性 |
**太字** が変換されず、記号のまま残る恐れがあった |
投稿後に strong と記号残りを検証するルールを追加 |
特に本文画像の消失は、投稿自動化ではかなり危ないです。
下書き保存まで成功しているように見えるので、検証を入れていないと「できた」と判断してしまいます。でも読者が見る記事には画像が入っていない。これは記事制作フローとしては失敗です。
投稿後検証をどう見たか
noteの下書きを保存したあと、再オープンして .ProseMirror 内の画像数を確認しました。
概念としては、次のような検証です。
const result = await page.evaluate(() => {
const editor = document.querySelector(".ProseMirror");
return {
bodyImages: editor?.querySelectorAll("img").length ?? 0,
strongCount: editor?.querySelectorAll("strong").length ?? 0,
blockquoteCount: editor?.querySelectorAll("blockquote").length ?? 0,
hasRawMarkdownBold: editor?.innerText.includes("**") ?? false,
};
});
今回の最終確認では、本文画像3枚、太字、引用がnote上で確認できる状態になりました。
ここで大事なのは、検証対象を「保存処理がエラーなく終わったか」ではなく、読者が見る本文に必要な要素が残っているかにしたことです。
失敗時にもURLを返す
最初の失敗では、下書きそのものは作られているのに、スクリプトの戻り値には編集URLが出ていませんでした。
そのため、復旧対象の下書きを探すためにブラウザ履歴を見にいく必要がありました。これは運用として弱いです。
そこで、失敗時にもURLやスクリーンショットを返すようにしました。
console.error(JSON.stringify({
ok: false,
error: err.message,
url,
title: parsed.title,
...result,
published: false,
savedScreenshot: outScreenshot,
verificationScreenshot,
}));
ok:false でも、下書きURLがあれば復旧できます。
自動化では「成功か失敗か」だけでなく、失敗したあとに人間や別スクリプトが立て直せる情報を返すことが大事でした。
本文画像だけ復旧する
画像が消えたあと、記事全体を再投稿するのではなく、既存下書きを開き直して本文画像だけを復旧しました。
復旧フローはこうです。
この復旧処理は note_recover_body_images.cjs として切り出しました。
また、PowerShellのヒアストリング経由でNodeコードを流すと日本語セレクタが文字化けしやすかったため、復旧スクリプトは .cjs ファイルとして保存し、日本語ボタン名はUnicodeエスケープで扱う方針にしました。
地味ですが、こういうところが自動化の安定性に効きます。
スキルに戻した改善
今回の修正は、作業ディレクトリのスクリプトだけで終わらせませんでした。
次回も同じ失敗を避けられるように、関連するスキルへ運用ルールを戻しました。
| スキル | 反映したこと |
|---|---|
note-images |
ユーザーの好みを反映すること、AI感を避けること、noteサムネは原則文字入りにすること |
note-post |
保存後再オープン検証、失敗時URL返却、本文画像復旧スクリプトの使い方 |
note-hobby-writer |
本文完成後に太字・引用を整えること、Markdown記号残りを防ぐこと |
一回の作業で詰まったことを、次回の作業手順に戻す。
これをやると、AIに任せられる範囲が少しずつ広がります。
AIとの会話で効いたところ
今回の流れで、方針を決めたユーザーの一言がいくつかありました。
いっきには語れないから、あなたが深いところまでヒアリングして。順番に
この一言で、記事制作を「本文をすぐ書く作業」ではなく、「語りたいことを掘ってから構成する作業」として進めることになりました。
サムネには原則文字入れて読みたくなるようにさせるように
画像生成を、きれいな絵を作るだけでなく、note一覧で読まれる導線として扱う方針になりました。
今回作業に17分もかかったね。どこで詰まったのか整理して、原因を解明して、解決法を出して、今後スムーズに作業できるように関連するスキル更新して。
ここで、作業完了からフロー改善に切り替わりました。
この視点がかなり重要でした。うまくいった成果物だけを見るのではなく、時間がかかった場所を特定して、次回のためにスキルへ戻す。AIエージェントを使うなら、この運用が効きます。
画像を使う場合の注意
今回は公開記事にnote下書き画面のスクリーンショットを載せることも考えられました。
ただし、スクリーンショットには以下が写りやすいです。
| 写りやすい情報 | 対応 |
|---|---|
| noteアカウント名 | トリミングまたは不使用 |
| 編集URL | 公開記事には載せない |
| ブラウザ履歴やタブ名 | 事前に確認する |
| ローカルパス | 記事中では <user> などにぼかす |
そのため、この記事ではスクリーンショットよりもMermaid図と表を中心にしました。
まとめ
AIに記事制作を任せるとき、本文生成だけを見るとかなり簡単に見えます。
でも実運用では、そこから先が大事です。
- 画像が保存後にも残っているか
- Markdown装飾が投稿先で正しく変換されているか
- 失敗時に復旧できる情報が返るか
- その失敗を次回のスキルに戻せているか
今回は、note記事制作を通じてこのあたりを改善しました。
個人的には、AIエージェントの価値は「1回うまく作ること」より、失敗を観測して、次の手順を少し賢くすることにあると感じています。
本文を書くAIから、投稿後に検証して、失敗をスキルに戻すAIへ。
その一歩として、今回のnote投稿フロー改善はかなり実践的な学びになりました。
Discussion