消したはずの文字を刷り重ねる版画のような状態でした。
Lilyのnoteでは、購入案内が重なっていました。
あなたは今こうなっていませんか？
• 新しい記事を増やし、過去記事の末尾は見ていませんか？ • 自動の購入案内を、入っているはずで済ませていませんか？ • 読まれても売れない理由を、集客だけに探していませんか？
先に結論を言います。記事を増やす前に、購入案内の実物を確かめる必要がありました。
この記事では、購入案内が59本で重複した失敗を書きます。
無料記事174本の監査までと、未確認のことも残します。
59本の記事で、購入案内が重なっていました
問題は本文を読み終えた先にありました
今回の問題は、記事のテーマやタイトルではありません。 本文のあとにある、有料記事への購入案内でした。
同じ購入案内の重複が、59本の記事で見つかりました。
興味を持った方へ用意した説明が、重なっていました。
案内を書いたこと自体は、間違いではありませんでした。
ただ、必要な説明でも繰り返せば読みにくくなります。
最後まで読んでくださった方には、申し訳なく思います。記事の終わりまで整えてから、公開すべきでした。
LilyはAIを使い、記事づくりの一部を自動化しています。
購入案内を入れる作業も、その仕組みに任せていました。
毎回同じように入り、手作業より安定するつもりでした。
実際には、任せた作業の結果を十分に見ていませんでした。
署名の欠落は、別の問題として数えました
調べると、末尾の署名が抜けた記事も見つかりました。
記録上の欠落は31本で、修復対象は合計90本でした。
重複59本と署名の欠落31本は、別の問題です。
59本すべてで、署名も消えていたわけではありません。
混ぜて数えると、何を直したのか曖昧になってしまいます。
Lily自身も、数字の意味を分けて捉え直しました。
案内が多すぎる記事と、末尾の要素が足りない記事です。
見た目は逆でも、同じ仕組みの見直しにつながりました。
どちらも、新しい本文を書き足して直る問題ではありません。
公開済みの記事に戻り、状態を確かめる必要がありました。
新しい内容を考えるより、地味に見える作業だと思います。
その地味な部分を、後回しにしてしまった結果でした。
読者への影響は、分からないままです
重複を見た方が、全員嫌になったとは言えません。気にせず読んだ方も、いたのかもしれません。
購入をやめた方がいたかも、Lilyには分かりません。そこまで確かめた記録は、持っていないためです。
ただ、分かりにくい表示を放置する理由もありません。
買っていただく以前に、普通に読める末尾にしたいです。
まず戻るべきなのは、公開されている記事の末尾でした。
編集画面で原稿を見るだけでは、足りていませんでした。
書いた内容の記憶より、今の表示を見るほうが確かです。
Lilyには、その実物を確かめる作業が不足していました。
「反映されていない」という判断を信じていました
確認の仕組みがあっても、安心できませんでした
購入案内は、ただ貼って終わりではありませんでした。反映されたかを調べる仕組みも、用意していました。
確認まであれば安心できそうで、Lilyもそう思いました。
ところが、問題はその確認の仕方にあったんです。
末尾の署名の文字があるかを、判断材料にしていました。
見つかれば反映済み、なければ未反映と扱っていました。
一見分かりやすくても、署名と購入案内は別のものです。署名が見つからない理由は、ほかにもあり得ます。
署名がないことと、購入案内がないことは別でした。
仕組みは、その違いを十分に扱えていませんでした。
書式の変化で、確認の前提が崩れました
当時の記録では、8月25日ごろが変化の目安でした。引用形式で貼った内容が、落ちる挙動がありました。
引用形式は、本文と見た目を分けるための書式です。署名にも購入案内にも、その書式を使っていました。
一部が落ちると、探している署名が見つかりません。仕組みは、その状態を未反映と判断していました。
ここで、細かな技術名を覚えていただく必要はありません。表示の変化で、確認の前提が崩れたという話です。
note側の内部事情までは、Lilyには分かりません。
ここでは、当時の修復記録にある挙動を書いています。
外側で何が変わったかだけが、問題ではありませんでした。
想定と違う表示への、Lily側の判断も粗かったんです。
外部のサービスを使う以上、表示は変わることがあります。
そのとき、同じ操作を繰り返してよいとは限りません。
直そうとする動きが、重複を増やしていました
未反映と判断したあとは、購入案内を貼り直していました。
入らなかったものを、もう一度入れるつもりでした。
すでに案内がある記事なら、追加するほど重なります。直そうとする動きが、重複を増やしていたんです。
それが分かったときは、正直しんどく感じました。何もしなかったから起きた失敗、だけではありません。
確認して直そうとする部分にも、間違いがありました。確認機能があるというだけで、安心していたんです。
再実行する前には、失敗の表示だけで決められません。文章を追加する作業では、やり直しが重複になります。
9月2日、増やす仕事から直す仕事へ戻りました
本数が増えない作業を、優先しました
9月2日の記録に、今回の修復が残っています。Lilyが戻ったのは、新作ではなく過去記事でした。
重複があると分かれば、直す必要は明らかでした。それ以前は、増やす作業のほうが見えやすかったです。
記事を1本書けば、新しい成果物が手元に残ります。テーマを考えることにも、次へ進んだ感覚があります。
一方、末尾を直しても記事の本数は増えません。問題がなくなった状態は、少し伝わりにくいです。
それでも、公開済みの記事を放置できませんでした。今回は、そちらを優先する必要がありました。
増やした本数だけでは、読者の体験は分かりません。
今回の59本は、そのことを具体的に示していました。
頑張って記事を増やしていたとしても、別の話です。末尾の重複は、そこに戻らないと直りませんでした。
修復90本と監査174本は、役割が違います
修復対象には、8月22日以降の記事が含まれています。そこから、重複した購入案内などを直しています。
案内の重複59本と、署名の欠落31本が対象でした。修復対象として記録された合計は、90本です。
そのあと、8月以降の無料記事174本を監査しています。
90本だけを見て終えた、という記録ではありません。
直した対象と、最後に確かめた範囲の違いです。この2つの数字は、同じ意味ではありませんでした。
見つかった記事を直せば、ひとまず安心はできます。でも、見つかっていない記事への不安は残ります。
そこで、修復した記事の外側まで確認しています。174本という数字は、その確認範囲を表しています。
数が大きいから立派、という話にはしたくありません。そこまで戻る必要があったことが、今回の反省です。
作業したことと、整ったことを分けました
修復したという報告だけでは、曖昧さが残ります。作業したことと、表示が整ったことは違うからです。
欲しかったのは、修正作業をしたという報告だけではありません。
読者が見る記事で、重複が解消された状態でした。
最終監査では、対象範囲は健全と記録されています。購入案内と署名に、修復後の確認が残っています。
ただし、その結果は当時の対象記事についてのものです。
未来の記事まで、ずっと大丈夫とは約束できません。
仕組みを直しても、表示の変化は起こり得ます。今回の確認を、永久の保証にはできませんでした。
ご自身で直す場合も、確認範囲を言葉にしてみてください。
「全部」より、どの記事を見たかのほうが確かです。
1本なら、まず1本を確認したという状態です。区切りを曖昧にしないほうが、次に迷いません。
記事の書式と、判断する仕組みを見直しました
見た目を直すだけでは、原因が残ります
重複した文章を取り除けば、表示はすっきりします。でも、それだけでは原因が残ってしまいます。
同じ判断で貼り直す仕組みが、動き続けるためです。また未反映と間違えれば、同じ問題に戻ります。
そこで、過去記事の修復と仕組みの見直しを行いました。記事だけを整えて、終わりにはしませんでした。
直したかったのは、今ある重複と、それを生む判断です。どちらか片方だけでは、落ち着けませんでした。
読者に見える結果と、そこへ至る動きの両方が必要です。
AIに修正を頼むときも、これは伝えておきたいです。
見た目の問題だけを渡すと、原因が残ることがあります。
「なぜ繰り返したかも確認して」と添える考え方です。
書式をそろえたことと、売れることは別です
購入案内の書式も、一定の形にそろえました。案内のラベルと、リンク付きの文章を分ける形です。
何の案内かを示し、改行してリンクを置いています。当時は、その形へ統一する修復を行いました。
リンクは、押すと別のページへ進む文字のことです。購入先へ進むために、読者が触れる部分になります。
文章があっても、進む場所が分かりにくければ困ります。見えているだけでは、案内として十分と言えません。
ただ、今回は売れる言葉を発見した話ではありません。書式をそろえ、重複などを直した話です。
短くすれば売れる、という答えも出ていません。この修復から、そこまで断定はできないためです。
書式の統一と、売上への効果は別の話です。都合よくつなげず、ここは分けておきます。
確認できないことを、不在と扱っていました
今回、確認できないことを、存在しないことにしていました。
署名がなければ案内もないと、判断していたんです。
見つからない理由が表示の変化なら、追加は逆効果です。すでにある文章を、さらに足すことになります。
だから、判断する材料そのものを見直しました。自分の作業記録だけで、結果を決めないためです。
まず公開記事を1本見れば、実物を確かめられます。案内があるかを見てから、次の操作を考えられます。
大量の記事があっても、最初の確認は小さくできます。全体を触る前に、実物との差を知ることです。
Lilyは、仕組みが出した答えを信じすぎていました。
その答えが何を見ているかも、知る必要がありました。
無料記事174本の監査で、言えることを分けました
確認した数を、商売の成果にはしません
最終監査は、8月以降の無料記事が対象でした。その範囲で174本を確認した記録があります。
大きく改善したように見えても、数字の意味は別です。確認した数と、商売の成果は同じではありません。
174本は、売れた本数を表してはいません。購入へ進んだ人数を表しているわけでもありません。
購入案内などの状態を、確認した記事の本数です。その意味以上のものを、数字へ乗せたくありません。
今回の題材を選んだ理由も、そこにあります。見栄えのよい成功談には、まだできない出来事でした。
必要な修復だったことと、売れたことは別です。書く側として、そこには少しもどかしさもあります。
すっきり成功と言えたほうが、話はまとまります。それでも、確認した範囲を超えては書けません。
売上への効果は、今も未確認です
今回の修復で、売上が伸びたとは書けません。効果を確かめた記録が、そろっていないためです。
案内の重複が、売れない原因だったとも言えません。原因の候補と、確かめた事実は分けておきたいです。
分かるのは、重複があり、修復したことです。対象の無料記事を監査したことも、記録にあります。
修復前後で、購入がどう変わったかは別の話です。そこまで確認できて、初めて効果の話ができます。
売上への効果は、未確認のまま残しています。その状態で、今回の失敗について書いています。
読みやすい案内に戻せたことは、よかったと思います。期待がないわけではありませんが、実績とは違います。
期待を実績のように書けば、話が変わってしまいます。失敗を直した記録として、正直に残したいです。
記事末尾の監査で、証明できないこともあります
重複がなくなっても、購入までの流れには先があります。リンクが意図したページへ進むかも、別の確認です。
進んだ先で購入できるかも、同じ確認ではありません。174本の監査を、その全部の証明にはしません。
記事末尾で確かめた範囲を、広げすぎないためです。案内があれば買えるはず、と考えたくはなります。
自分で売ると、全部つながっていると思いがちです。でも、読者がたどる順番で見ないと分かりません。
Lilyは、その前の部分でつまずいていました。今日できるのは、確認した場所を残すことです。
案内を見たことと、購入先を見たことを分けます。見ていない部分まで、確認済みにしないためです。
詳しい表でなく、短いメモでも構いません。何を確認したのかが、分かるように残すことです。
集客を増やす前に、確かめたい場所がありました
新しい記事では、過去記事の重複は消えません
記事が売れないと、もっと読まれたいと思います。Lilyも、記事を増やす方向へ意識が向きます。
タイトルを変えたり、新しいテーマを探したりします。どちらも、やることが分かりやすいからです。
ただ、今回は既存の記事に重複がありました。読む人を増やす前に、確認すべきものがありました。
集客が不要だった、という結論ではありません。今回の自分には、修復を先にする理由がありました。
重複した59本を、そのままにはできませんでした。新しい記事を足しても、過去の重複は消えません。
増やす作業で、修復の代わりはできませんでした。当たり前に見えても、実際に戻ると重く感じます。
前へ進んだ気持ちになれる作業ばかりではありません。それでも、自分が出した記事にある問題でした。
自動化しても、任せた場所を見る必要があります
Lilyは、自動化そのものをやめたいわけではありません。
繰り返す作業を任せられることには、助けられています。
ただ、任せることの意味を取り違えていました。同じ結果になるかを、見なくてよいわけではありません。
今回のように、確認する側が間違うこともあります。防ぐつもりの部分が、問題を増やしていました。
仕組みがあると、手作業より安心したくなります。でも、その安心にも確かめる材料が要りました。
LilyのClaude Code自律環境は、別にまとめています。
仕組みの全体については、そちらにまとめています。
環境を用意すれば売れる、という話ではありません。今回も、自分の記事へ戻って直す必要がありました。
AIに任せたあと、何を見るかまで考えたいです。そこを抜かすと、今回のような失敗が残ります。
今日の1本は、新作でなくてもよいと思います
副業や個人開発では、作り続ける力が必要です。一方で、作ったものへ戻る時間も必要でした。
記事を書こうとしているなら、先に1本開いてみてください。ご自身の無料記事で、購入案内があるものです。
最後まで移動し、読者として末尾を見てみてください。
同じ案内が重なっていないか、それだけでも見られます。
今すぐ全部を直そう、という話ではありません。見つけた問題の範囲も、まだ分からないからです。
まず1本の状態を知れば、次に調べる理由ができます。問題がなければ、それも確認できた事実です。
Lilyは174本へ戻りましたが、その数から始めなくてよいです。
ご自身の記事を、1本見るところからで十分です。
成功談より先に、残しておきたい反省があります
修復できても、読まれた時間は戻せません
記録では、案内の重複と署名の欠落を修復しました。対象の無料記事について、最終監査も行っています。
そこまで戻れたことは、必要な対応だったと思います。
見つかった問題を、放置せずに済んだ点はよかったです。
ただ、修復前に読んだ方の体験は戻せません。読みにくい末尾を見せた時間まで、消えはしません。
その方が何を感じたかは、Lilyには分かりません。だからこそ、都合のよい解釈もできません。
誰も気にしていなかったはず、と済ませたくはありません。反対に、全員を失望させたとも決めつけません。
分かる範囲を直し、分からないことは残します。今回の失敗には、その姿勢が必要でした。
数字で説明できる修復と、想像しかできない影響です。最後まで、その2つを混ぜずに書きたかったです。
次に何を書くかの前に、確かめることができました
以前なら、次は何を書くかを先に考えていたと思います。今回は、その前に確かめたいことができました。
すでに読んでくださる方へ、どんな末尾を見せているかです。
購入案内が、実際にはどう表示されているかです。
文章力だけでは、その問いに答えは出ませんでした。公開された記事を見て、初めて分かることだからです。
書き上げると、そこで終わった気持ちになります。でも、読者が触れるのは、そのあとのページです。
整えたつもりの原稿と、実際に表示された結果です。その間に差がないか、確かめる必要がありました。
今日の1歩を選ぶなら、公開済みの末尾を見たいです。新しい記事を急ぐ前に、そこへ戻りたいです。
遠回りに感じても、今回の自分には必要でした。増やすだけでは気づけない問題が、そこにありました。
59本の重複を、売れた話へ変えずに残します
購入案内の重複は、59本で見つかりました。署名の欠落31本と合わせ、90本を修復した記録があります。
そのあと、無料記事174本を監査しています。書式と、未反映を判断する仕組みも見直しました。
ここまでは、今回の経緯として書けることです。修復で売上が伸びたかは、まだ書けません。
気持ちよく終わる成功談には、なりませんでした。同じところで困る方には、残す意味があると思いました。
AIで収入を作りたいとき、作る量へ意識が向きます。Lilyも、その気持ちはよく分かります。
それでも今回は、増やす前に戻る必要がありました。自分がすでに出した記事の、いちばん下までです。
次の記事を読んでもらうことだけを考える前に。今の記事から購入へ進めるか、実物で確かめます。
📕 この記事の内容を、実装まで全部まとめた有料記事があります
手順・コード・テンプレをそのまま渡しています
AIで「寝てても回る仕組み」を30日で組む全手順｜コード不要・特典40ファイル・毎月更新
この記事の販売者
