⏸️ エラーが出ないまま3週間止まっていた——特典コンテンツを丸ごと止めていた設定1行の話

ドリップコーヒーの機械が、タイマー通りに動き出しました。

準備完了を知らせるビーッという音が鳴って、あとはカップを持ち上げるだけ——そう思っていました。

でもカップの中に入っていたのは、ただのお湯でした。コーヒーのカプセルをセットし忘れていたのです。

機械は正しく動いていました。温める機能も、タイマーも、完了通知も、何ひとつ壊れていませんでした。

ただ、コーヒーを作るために必要な「核」が、最初から抜けていただけです。

この小さな抜けが、「完了」と「空振り」を同時に成立させていたのです。

あなたは今、こうなっていませんか？

• 自動化やAIツールを動かしているが、成果が出ているかどうかよくわからない • エラーが出ていないから「たぶん動いているはず」と放置しがち • 久しぶりにフォルダや出力先を確認したら、何も溜まっていなかった経験がある • 設定を一度作ったあと、中身をほとんど見返していない

先に結論を言います。 設定ファイルに書き忘れた1行のせいで、Lilyの特典コンテンツ生成が3週間丸ごと空振りしていました。

この記事では、エラーログには何も出ないまま3週間止まっていた仕組みの話と、原因を追って見つけた「たった1行の欠落」のこと、そして修正後に何が変わったかを書きます。

専門用語はできるだけ噛み砕いて、実際の時系列で書いていきます。

3週間、何も動いていない——でも「正常」に見えていた

ログには「完了」と書いてあった

Lilyは現在、Claude Codeというプログラミング環境を使って、noteの特典コンテンツを自動生成するしくみを動かしています。 難しく聞こえるかもしれませんが、要するに「毎朝、決まった時間に機械が代わりにコンテンツの下書きを作ってくれる流れ」のことです。

このしくみには、「生成レーン」と呼んでいる処理の流れがあります。

毎朝スケジュールされた時間に動き始め、AIが文章を書き、それをファイルとして保存する——という3ステップです。

9月上旬のある日、何気なく出力フォルダを開きました。

そこで初めて気づいたのですが、前回の更新が3週間以上前のままになっていました。

「あれ、保存先を間違えたかな」と思って、別のフォルダも確認しました。どこにもありませんでした。

翌日も、念のため確認しました。やはり何もありませんでした。

「そういえば最近確認していなかったな」と気づいて、ログファイルを開くことにしました。

ここから3日間の原因調査が始まりました。

「エラーが出ていない」という静かな落とし穴

ログファイルというのは、機械が動いた記録を文字で残したものです。

「○時○分に動きました、問題なく終わりました」という日誌のようなものです。

そのログを確認すると、毎朝きちんと「完了しました」という記録が残っていました。

21回分のログ、すべてが「正常終了」と書いてありました。

1つも「エラー」も「失敗」という記録がありませんでした。ここで頭が混乱しました。

エラーが出ていれば「どこかが壊れた」とすぐわかります。でもログには「成功」と書いてある。

それなのに何も生成されていない。

「成功している」と「何も生まれていない」が同時に成り立っているこの状態が、3週間続いていたのです。

これは本当にしんどかったです、、、「どこを直せばいいのかわからない」という気持ちがいちばんきつかったです。

📕 AIエージェントと自動化の全工程をまとめた総集編 手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

自動化の「レーン」って何？——非エンジニアのための説明

料理のレシピに例えると

「生成レーン」という言葉が出てきたので、少し立ち止まって説明させてください。

プログラムを普段使わない方には馴染みのない言葉かもしれません。

料理にたとえると、こんな感じです。

「毎朝7時に冷蔵庫を開ける→材料を取り出す→切る→炒める→皿に盛る」という手順書があるとします。

この手順書を機械が自動で実行してくれる——それが「自動化のレーン」の基本的なイメージです。

Lilyの場合は「記事のテーマを読み込む→AIに文章を書かせる→ファイルに保存する」という3ステップでした。

人間が毎朝起きてやらなくていい、機械が代わりにやってくれる。それがこのしくみの便利さです。

手順は合っているのに、お皿が空になる

問題は、「手順書通りに動いているのに、お皿に何も乗っていない」という状態です。

料理で言うと、「冷蔵庫を開けた、材料を取り出した、切った、炒めた——でもお皿は空」という感じです。

プログラム的には「正常に動作した」と記録されます。

でも目に見える成果物、つまり生成されたコンテンツのファイルは何も存在しない。

この2つが矛盾せずに共存できるのが、今回いちばんわかりにくかった部分です。

「完了」はしている、でも「生まれていない」のです。

レーンという言葉を使っているのは、工場のベルトコンベアのイメージからです。

ベルトが動いていても、乗せるものがなければ何も運べません。

3日かけて原因を追いかけた

ログを1行ずつ読み直す作業

原因を探すため、まずログを細かく見直す作業から始めました。

「完了」と書いてあっても、その前のどこかで変な動きがなかったかを確かめるためです。

普段は「正常終了しました」という最後の行だけ確認していました。

でも今回は、その前の細かい記録まで1行ずつ読んでいきました。

1日単位で読んでいくと、ある共通したパターンが見えてきました。

「AIへのリクエストを送った」という記録の直後に、長い空白があって、そのまま「完了」になっていたのです。

普通であれば「AIへのリクエストを送った→応答を受け取った→ファイルに書き込んだ→完了」という流れになるはずです。

でも「応答を受け取った」と「ファイルに書き込んだ」の記録が、21日分すっぽり抜けていました。

「ここだ」と思いました。この空白の部分に、原因が隠れているはずです。

AIへのリクエストが「届いていなかった」

AIというのは、ここでは有料のAPIサービスを指します。

「この文章を書いてください」という依頼を機械経由で送ると、文章が返ってくる仕組みです。

インターネット越しに「お願い」を送って、「できました」という返事をもらう——そんなイメージです。

Lilyのレーンは、毎朝このやり取りを自動でやっていたのです。

この「依頼を送る」部分のコマンド（機械への命令文）を丁寧に見直しました。

すると、命令文の中に「どのAIモデルを使うか」という指定が入っていませんでした。

AIには「モデル」と呼ばれる複数の種類があります。

同じ会社のサービスでも、「軽くて速いもの」「高精度だけど時間がかかるもの」と複数の種類が用意されています。

「どれを使うか」を指定しないと、サービス側は「どれを使えばいいかわからない」という状態になります。

その結果、リクエストが正常に処理されず、エラーが返ってきていたのです。

でも問題は、そのエラーが外側から見えない形で処理されていた点です。

内部ではエラーが起きていたのに、全体としては「完了」と記録されていたのです。

原因は「--model」という1行の欠落だった

非エンジニアへの補足説明

--modelと聞いてピンと来ない方のために、もう少し説明します。

これは「このAIモデルを使ってください」と機械に伝えるための命令のパーツです。

料理のレシピで「醤油を使ってください」と書く行が1行あるとします。

その行を書き忘れると、料理は進んでいるのに味がつかない、という状態になります。

今回はそれに近い状態でした。

「AIを使って文章を書いてください」という命令は書いてあったのに、「どのAIを使うか」という1行が抜けていました。

抜けた1行の影響で、AIへのリクエストは毎回失敗していました。

でもその失敗が「完了」として処理されていたため、外からは何も見えなかったのです。

この「見えない失敗」が、3週間気づかせなかった正体です。エラーが静かなほど、発見が遅れます。

なぜ3週間も気づかなかったのか

書き忘れた正確なタイミングは特定できませんでした。

でもログの記録から逆算すると、9月初旬から21日間この状態が続いていたことはわかりました。

なぜ気づくのが遅れたか、原因は2つあります。

1つ目は、エラーが表面に出なかったことです。

プログラムの内部で「AIが使えない」というエラーが起きても、外から見ると「完了」に見えていました。

「ログが正常＝問題なし」という思い込みが、21日間の空振りを見えなくしていたのです。

エラーが出ていない安心感が、かえって確認をサボらせていました。

2つ目は、成果物を直接確認する習慣がなかったことです。

ログを確認する習慣はあったのですが、「コンテンツが実際に存在するかどうか」を毎日確認するルーティンがありませんでした。

21日間、毎朝動いているつもりになっていたわけですから（笑）これ、正直かなり恥ずかしかったです。

修正は5分以内に終わった。でも3週間は戻らない

1行を追加するだけだった

原因がわかれば、修正は本当に単純でした。命令文の中に「使用するモデルの指定」を1行追加するだけです。

この1行を追加して、ファイルを保存しました。それだけで作業は終わりました。

翌朝、確認のためにフォルダを開きました。新しいファイルが1つできていました。

修正してから24時間以内に、最初の特典コンテンツが出てきていたのです。 「ちゃんと動いてる」という安堵よりも先に、「なんで3週間気づかなかったんだろう」という気持ちが来ました。

「たった1行だったのか」という拍子抜けと、「21日分のロスはどうにもならない」という現実感が、同時にありました。

修正の軽さと、失った時間の重さが、ちぐはぐに感じられた瞬間でした。

止まっていた分は、戻ってこない

3週間で本来21本生成されるはずだったコンテンツが、空振りし続けていました。

その21本が後から戻ってくるわけではありません。

これは、自動化の仕組みを使うときに気をつけておきたい点だと思っています。

「動かしているつもりの期間」は、後から取り戻せません。

ただ、この経験で得たものもありました。

「ログに成功と書いてあっても、成果物が実際に存在するかどうかを確認する」という習慣です。

今は毎朝、生成フォルダのファイル数を実際に確認するステップを加えています。

3週間の空振りから得た、いちばん具体的な変化です。

修正後、特典コンテンツが2本になった

1本目が安定して動き出した

修正してから3日後、1本目の特典コンテンツが完成した状態でフォルダに保存されているのを確認しました。 テキストファイルとして出力され、Lilyが内容を確認して手直しする形で運用するようにしました。

このコンテンツは、noteの有料記事を購入してくださった方に渡すものです。

無料記事では書けない手順の詳細や、実際に使っている設定の具体例を載せています。

1本目を動かし始めて気づいたのは、生成の「ばらつき」でした。

同じ設定で毎朝動かしていても、出来栄えが日によって少し違いました。

設定を少しずつ調整しながら、1週間ほどで安定する状態になりました。

「ここまで来るのに3週間ロスしたんだな」という気持ちは正直ありましたが、動いていることへの満足感の方が大きかったです。

2本目のレーンを追加した

1本目が安定してきたタイミングで、2本目の特典レーンを追加することにしました。 テーマが違う記事には、別の特典を用意したかったからです。

2本目は、Claude Code自律環境の設定手順を扱うものにしました。 仕組みの全部は、Claude Code自律環境についての有料記事にまとめています。

修正から2週間が経過した今、2本の特典レーンが毎朝安定して動いています。 3週間の空振りがあったとは思えないくらい、今は順調です。

1本のレーンが動いているときは、もう1本を追加することのハードルを高く感じていました。

でも実際に動かしてみると、設定の構造が同じなので思ったより早く立ち上がりました。

この経験で変えた「設定の書き方」2つ

省略できても、明示するようにした

今回の教訓を一言で言うと、「デフォルトに頼らない」ということです。

デフォルトとは、「特に指定しなかったときに自動で選ばれる値」のことです。

AIのサービスでは、指定しなければ自動で選んでくれる項目が数多くあります。

書かなくても動く、というのは便利に見えます。

でも、サービス側の仕様が変更されたとき、「自動で選ばれるもの」が静かに変わることがあります。

その変化が原因で生成が止まっても、エラーが出るとは限りません。

だから今は、使用するモデルを必ず1行明記するようにしました。

「省略できるから省略する」ではなく、「明示できるなら明示する」という方針です。

面倒に感じるかもしれませんが、1行書き足すだけです。

その1行が、次の3週間の空振りを防いでくれます。

「成功ログ」より「成果物の実在」を確認する

もう1つ変えたことがあります。ログの「成功」だけを信じるのをやめました。

毎日、生成フォルダのファイル数を実際に目で確認します。30秒以内に終わる確認です。

ログは機械が自動で書いた日誌です。

機械が「完了した」と判断すれば、実際に何も生まれていなくても「完了」と書きます。

でも実際のファイルは嘘をつきません。あるかないか、それだけです。

「動いているはず」から「動いているかどうか確認した」という状態に変える。

この30秒の習慣が、いちばんの再発防止策だと思っています。

この変化を加えてから、生成レーンに対する信頼感が変わりました。

「たぶん動いているだろう」ではなく、「今日も動いているのを確認した」という感覚があります。

仕組みを「動かすこと」より、「見続けること」のほうが難しい

動かしてからが本番だった

Lilyは以前、「仕組みを作ること」がゴールだと思っていました。

自動で動く流れを組み上げたら、あとはほったらかしで成果が出続けると考えていたのです。

解雇から半年で月商を作れたのも、自動化の仕組みを作ったからです。

でも今回のように、その仕組みが止まっていることに3週間気づかない期間がありました。

仕組みは作るだけでなく、定期的に「本当に動いているか」を確認しないといけない。

これが今回いちばん痛くて、でもいちばん残った教訓です。

仕組みを作った瞬間が、スタートラインだったんだと思っています。

そこから先の「見続けること」が、本当の運用なのだと気づきました。

確認を続ける小さな習慣

自動化の落とし穴は、シンプルなところにあります。「動かしているつもり」という思い込みです。

自動化をしていると、確認をサボりたくなります。

「自動なんだから、見なくていいはず」という気持ちになります。

でも、人間が設定した以上、人間がミスした部分は機械には直せません。

定期的な確認は、自動化を本当に機能させるための最後のひと手間です。

毎朝1分、ファイルが増えているかを確認するだけでいい。

ただそれだけで、次の3週間の空振りは防げます。

この1分は、仕組みへの投資だと思っています。

「ちゃんと動いている」という事実を、自分の目で確かめる時間です。

まとめ：「エラーが出ない」は「正常」と同じではない

今回の話を振り返ります。 特典コンテンツの生成レーンが、3週間・21回空振りし続けていました。

原因は、コマンドの中の1行の書き忘れでした。

エラーは表面に出ず、ログには「成功」と記録され続けていました。

修正は5分以内に終わりました。

翌日から生成が再開し、今は2本のレーンが毎朝安定して動いています。

この経験から得た習慣は2つです。

「使用モデルは必ず明示する」と、「成果物の実在を毎日30秒確認する」。

シンプルなことです。

でも、シンプルなことを続けることが、仕組みを本当に動かすことだと——3週間の空振りが教えてくれました。

仕組みを作った方、自動化を始めた方に、最後に1つだけ聞きたいです。

「ログに成功と書いてあっても、今日の成果物を確認しましたか？」

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順