予約した制作ノート8本を公開前に読み直すと、崩れていたのは「今は」と「これから」だった

warp-studio.com では、書き上がった制作ノートの公開日を AI が決めて予約し、その日の朝9時に PC がサイトを作り直して自動で出しています。仕組みは予約公開の仕組みのノートに書きました。AI は、記事をまとめて出さないように、公開の日を2〜4日おきに、のちに週に1回にしていました。ところが、ノートはそれより速いペースで書き上がりました。新しく書いた1本は予約の列のいちばん後ろに入ったので、書いてから公開されるまで2〜5週間かかるようになっていました。

公開を待つあいだに、書いた内容が古くなっていないか。2026年10月19日、その時点で予約していた8本を、書いたのとは別の AI のエージェントが公開前に読み直しました。事実と違う箇所が1つ、誤りではないものの古く見える箇所が7つありました。8本の中で、日付を添えて書いた文は1つも誤りになっていません。崩れていたのは、書いた日から見た「今は」や「これから」でした。その結果と、10月21日に足した「確かめた日」の欄と警告、10月24日に予約の決め方そのものを変えた記録です。

予約していた8本と、読み直したきっかけ

10月19日の朝、読み直したときに予約していた制作ノートは、10月20日から11月17日までに出る予定の8本でした。最初にリポジトリへ入れたのは10月7日から14日で、公開日まで13日から34日あいていました。

この日、AI に「制作ノートは遠くまで予約しすぎて、読む側から分かりにくくなっていないか」と尋ねました。「まだやっていません」で終わるなら、公開前に確かめて済ませたほうがよいのでは、という問いも添えています。

確かめ方は読み取りだけです。本文から今の状態を述べた文（「今は」「〜のまま」、件数や設定値など）を拾い、ノートの sources に挙げたリポジトリやファイル、git の記録、作業の記録と照らしました。日付の付いた過去の出来事は対象から外し、10月20日に出る1本の、すでに分かっていた1件（予備のモデルの名前）も数に入れていません。

3つの判定と8本の結果

判定は、公開の日に事実と違う「誤り」、誤りではないがその後の変化で読む人が迷い得る「古く見える」、公開の日にも正しい「問題なし」の3つです。

8本のうち6本に何か見つかりました。公開日が遠いほど増えたわけではなく、10月27日の予定だったデザインの改善ループは0、11月3日の予定だった AI メディアの公開の枠のノートは3です。その後、デザインの改善ループは10月23日に前倒ししました。

8本では、日付を添えた文は崩れなかった

日付を添えた文は、どれも公開の日に正しいままでした。「この AI の機能は、3月27日に公開版の画面から外しています」「10月8日からの新しい公開の仕組みでは」のような文です。

崩れたのは、日付の無い「今」と、書いた日の目線の言い方です。予約公開の仕組みのノートの「転送は15件に減っています」は、10月8日の初回の公開の結果として書いた文です。10月10日に別の製品ページが出て転送がもう1件外れ、10月23日の時点で14件です。そのまま公開の日に読めば、今の件数に見えるところでした。自動プレイの計測のノートは、本文に「10月6日の振り返りでは」と日付がありました。それでも見出しが「いまの状態」だったため、10月7日に条件が1つ合格したあとも、10月6日の数が今の数として読めました。

公開の枠のノートは、10月19日の時点では、「これから」の節が「最初の朝の枠は10月8日7時の回です」で始まっていました。予定していた11月3日には、4週間近く前のことです。同じノートの「何もしない回は約90秒で終わる見込みです」も、10月8日9時のその回は約30秒で終わっていました。

誤りの1つは、別の型です。題材が変わったのではなく、書いたあとの別の調べで、本文に入れるべき事実が見つかりました。予約が長いほど、この型が入り込む時間も長くなります。

10月9日に予約分と公開中のページを確かめたとき（食い違いは19件）も、同じ形がありました。製品ページ「SubTrim」の「最後に実行したのは2026年10月6日で、月1回の自動実行は、まだ設定されていません」は、日付の付いた前半は正しく、「まだ」の後半だけが崩れていました。価格を最後に確かめた10月6日の夜に、毎日の自動の確認を作ったためです。

日付を添えても崩れた例が1つあります。About の「2026年10月7日時点で、製品3本と制作ノート3本を公開しています」は、日付が設定の固定の値、本数がビルドした日の数で、公開のたびに本数だけが増えました。10月9日に、日付もビルドの日から作るように直しています。日付は、中身と同じ時点で決まらないと効きません。

古さは、動いている題材と、先の予定を書いたノートに集まった

古く見えた7つは、題材のリポジトリが動き続けているノートと、書いた日のあとに結果が出る予定を書いたノートに集まりました。社畜サバイバーは10月7日から19日に公開版を何度も更新していて、2本に1つずつ出ています。毎日動いている Chronicle AI を扱う公開の枠のノートには3つです。反対に、10月7日のあと見た目に関わるファイルが変わっていないデザインの改善ループは0でした。

ノートの外にもありました。公開の枠のノートの末尾がリンクする /apps の Chronicle AI の説明は「クラウドの定時実行で毎時起動し」のままで、10月7日の夜からの1日6回と食い違っていました。試遊版のプレイデータのノートが案内するプライバシーポリシーとゲームのページも、10月18日からの「進行の引き継ぎ」に触れていませんでした。ノートだけを直しても、リンク先が古ければ、読む人は同じところで迷います。

直したもの

10月20日に出る2本と /apps は、10月19日のうちに直しました。自動プレイの計測のノートは、見出しを「10月の判定」に替え、「その後、10月7日に日英の全画面の確認が合格になりました。」の1文を足しています。報告の案は10月10日の判定の数も足すものでしたが、直しを確かめた別の AI が、社畜サバイバーの記録どうしでその数が食い違っていると指摘し、日付の確かな1文だけにしました。直すときに足す文も、新しい「今」になり得ます。

試遊版のプレイデータのノートには、10月21日に進行の引き継ぎの段落を足しました。ゲームのページの「協力に同意した方のプレイデータだけを送信し」も、「だけ」が新しい機能と食い違うと別の AI に指摘されて言い方を替え、プライバシーポリシーとあわせた3か所が10月23日の朝に公開されています。

公開の枠のノートは、10月23日に予定より早く仕上げました。「これから」の節の前半を、10月23日までの結果を書く節に替え、「約90秒の見込み」には、10月21日から23日の何もしない回の実際の秒数（31〜53秒）を添えています。このノートは公開を決める前の段階だったので警告の対象外でしたが、本文に、根拠を確かめきれない箇所に付ける「要確認」の目印が残っていたため、書き直さないと公開の扱いにできない形になっていました。残りの2本は10月24日に直しました。予約公開の仕組みのノートは、転送の件数を、10月8日の15件と10月24日の時点の14件に、日付で書き分け、もう1本の技術メモには、書いたあとで分かった事実の節を足しています。

確かめた日の欄と、日数の警告

10月19日の報告は、予約の仕組みに足す確認を5つ挙げていました。10月21日に入れたのは、確かめた日の欄と警告、公開の数日前の見直しを、公開の予定をまとめた作業用の日程の表に書くことの2つです。

確かめた日の欄は、front matter（記事の先頭の、題名や日付を書く欄）の checkedAt です。今の状態を述べた文を、最後に根拠と照らした日を書きます。それまでの updatedAt は公開日と同じ値で、いつ確かめたかを表していませんでした。出す前の検査（check-release）は、10月21日の版では、次の関数でこの日付を見ていました。

export const freshnessWindowDays = 14;
export const needsFreshnessCheck = (item, today = todayInJapan()) => {
  if (item.data.status !== 'published' || !item.data.publishedAt || isLive(item, today)) return false;
  if (!item.data.checkedAt) return true;
  return (Date.parse(item.data.publishedAt) - Date.parse(item.data.checkedAt)) / 86400000 > freshnessWindowDays;
};

対象は、公開を決めていて、まだ公開日が来ていないものだけです。checkedAt が無いか、公開日の14日より前なら一覧に出す作りでした。警告だけで公開は止めません。止める作りにすると、その朝の公開ごと止まってしまうためです。10月21日の時点では、そのとき11月10日と11月17日に予約していた2本（確かめたのは公開日の22日前と29日前）が出たので、日程の表に、それぞれの数日前の見直しを足しました。

この関数が見るのは日付だけで、読み直したかどうかは checkedAt を書く側の申告に頼っています。

予約を遠くまで入れる意味

毎日作業している時期は、制作ノートがたまりやすくなります。ある程度たまったら、更新の頻度を調整してもいいのではないか。今は、最初に決めた低い頻度の決まりを守りすぎている気がします。サイトの改善を始めたころは、書く話が少なく、活動が止まっていないことも見せたかったので、細かく先まで予約する意味がありました。今はたまる一方なので、もう少し更新の頻度を上げてもいいのではと、常々思っていました。一度そう AI に聞いたときは、公開の無い日が出るのを嫌って、却下されています。

そもそも、そこまで予約をためる意味はあるのでしょうか。公開が書いた日から離れるほど、今とのずれが大きくなって矛盾が出るので、確認が必要になります。読む人の多くは、制作ノートを、今日か最近あった出来事の話として読むと思います。数日先ならまだしも、そんなに先まで予約しておくのは何のためなのか、という気持ちしか出てきません。せめて、いつ出しても変わらない話と、今や最近の話として出したほうがいい話は、分けて考えたほうがいい気がします。いつも列の後ろに足していくと、おかしなことになります。

10月24日に変えた決め方

この考えを受けて、10月24日に制作ノートを2つに分けました。

• 今の話: 結果や数字、最近の出来事への対応を書いたもの。確認が済んだら、数日のうちに出します。予約の列の後ろには並べず、いつ出しても同じ話より先に出します。
• いつ出しても同じ話: 仕組みや手順、設計の判断を書いたもの。空いている日に置き、今の話が入ったら後ろへずらします。

front matter に timing を足し、今の話は now、いつ出しても同じ話は anytime としました。出す前の検査の警告も分け、now は確かめた日から7日、anytime はこれまでどおり14日を超えたら出します。公開の無い日が続いても、埋めるために予約をためることはしません。

予約していた4本は、この決め方で並べ直しました。11月3日の予定だった公開の枠のノートは、10月23日までの結果を書いた今の話なので、公開日を10月26日に移しました。10月27日の、モデル終了の通知から全アプリを見直したノートは、10月30日の期限の前に出す今の話で、日付はそのままです。予約公開の仕組みのノートと、11月17日の予定だった技術メモは、いつ出しても同じ話です。10月24日に古い所を直したうえで、空いている日に置き直しました。このノートは今の話なので、確かめた日は10月24日、公開日は10月29日です。

10月24日の時点で、報告の5つのうち3つは仕組みに入れていません。sources に挙げたリポジトリごとに checkedAt からのコミットの数を出し、多いノートだけを読み直すこと。ノートがリンクするサイト内のページも一緒に見ること。書くときに、今の状態には「○月○日時点で」と日付を添え、公開の日に過去になる「これから」「見込み」は、公開前に結果へ書き換える前提で目印を付けておくこと、です。今の話を数日のうちに出すようにしたので、3つ目に挙げた「これから」の崩れは、起きにくくなるはずです。

書いたものを別の AI に確かめさせる考え方は改善ループのゲート設計についての制作ノートに、公開前に機械で止める検査はAI が書いた記事の誤りと公開前の機械の検査についての制作ノートに書いています。10月19日に経緯を書き足した1本は、モデルを比べてから替える決まりについての制作ノートです。