解剖 02 ── 毎朝の自動実行が「合っているか」を確かめる仕組みの構造

（2026年10月2日・図1・表4）

結論

毎朝の自動実行は、X への投稿や記録の取り込みを、ぼくが寝ているあいだに済ませてくれます。ただ、「動いた」と「合っている」は別でした。この1枚は、合っているかを確かめる側の構造です。

自動実行は、終わるたびに「受領票」を1行残します。どの工程が成功したか、何を投稿したか、いくら使ったかをまとめた、その朝の結果の記録です。
9月25日からは「突き合わせ」を足しました。前の日の時点の記録から「明日の朝はこうなるはず」という想定を作り、実際の受領票と10項目で比べます。
9月26日から10月1日までの6日・60項目で、不一致は2つでした。どちらも「開始が予定より3時間以上遅れた」です。投稿の本数や金額の不一致は0でした。
確かめるための追加の費用は0円です。X の API を新しく呼ばず、すでにあるファイルを読んで比べるだけだからです。
作ったきっかけは、記録が「全工程成功」でも、結果が合っていなかったことが3件あったからです（下の表の 9/14・9/15・9/22 の行）。

部品の関係図

朝の自動実行が受領票を1行残し、前の日の時点の記録から作った想定と10項目で突き合わせ、結果を投稿ボードに出すまでの流れ。

流れは上から下です。朝の自動実行が終わると、受領票が1行書かれます。そのあと、前の日の時点の記録から作った想定と比べて、結果を同じ行に足します。ぼくが朝に読むのは、投稿ボードに出るその1行です。

手元でやっている本番確認（公開したページが正しく出ているかの確認）の記録も、翌朝の自動実行が受領票に取り込みます。

突き合わせの10項目

想定は、実行の前の日の時点の記録から作ります。実行したあとの記録から作ると、結果に合わせた想定になってしまうからです。

項目	想定の作り方	6日の結果
工程の成否	全部成功（止めている工程は「飛ばした」）	6日とも一致
その朝の投稿	前の日の時点の予定表から、出るはずの1本を選ぶ	6日とも一致
画像	対象に画像があれば、画像つきで出ている	6日とも一致
使った金額	決まった単価 × 件数（投稿 0.015ドル・URL つき 0.20ドル・読み取り 0.005ドル）	6日とも一致
自動で作る承認待ちカードの数	前の日の時点で数える	6日とも一致
週ごとの記録の行数	前の日＋1	6日とも一致
まだ告知していない記事の数	記事の一覧と同じ数え方	6日とも一致
承認済みで未投稿の数	前の日の枚数 − その朝の投稿	6日とも一致
ボードのサムネ	画像つきカードの枚数	6日とも一致
開始時刻	予定の 06:47 からの遅れが3時間以内	4日一致・2日不一致（9/29 は3時間28分、10/1 は3時間3分）

開始の遅れは、9月15日から10月1日までの定時の実行17日で、最小が1時間44分、中央値が2時間10分、最大が3時間28分でした。起動しなかった日はありません。

止まった箇所

確かめる仕組みに関わるものだけを並べます。投稿そのものの止まった箇所は、解剖 01 にあります。

日付	何が起きたか	原因	直し
8/27	定時の実行が起動せず、朝の出力が何も無かった	起動しなかった（GitHub 側の原因は分からないまま）	予定の時刻を、混みにくい端数の分に変えた（8/28）
8/28	6時間半遅れて起動し、最後の保存で失敗。出力も痕跡も残らなかった	前の夜に増やした出力ファイルが、保存の対象に入っていなかった	保存の対象を一覧で明示し、保存のやり直しを足した（8/28）
9/11	実行が失敗し、朝の出力が保存されずに消えた。投稿だけは出ていた	前の日に足した台帳のファイルが、保存から外す設定に当たっていた	外さない例外を1行足した（9/11）
9/14・9/15	受領票は「全工程成功」なのに、朝に告知した記事がボードで「未告知」と表示された	投稿の前にボードを作る順になっていた	投稿のあとにボードを作り直す工程を足した（9/15）
9/15	受領票は「全工程成功」なのに、まだ出していない手動の2本が「投稿済み」と記帳された	自動の照合が、カードを登録する前の投稿（同じ URL）に当たった	「登録より後の投稿だけ」を条件にし、照合の結果を受領票に書くようにした（9/15）
9/20	試しの実行で、途中の工程の失敗が投稿まで止めた。受領票では、飛ばした理由が区別できなかった	工程のつなぎ方と、受領票の書き方	途中が失敗しても投稿は走る形にし、飛ばした理由を書き分けた（9/20）
9/22・9/24・9/25	ボードの画像のサムネが0枚になった。受領票には何も出なかった	画像の縦横を読む部品が実行する環境に無く、エラーを握りつぶしていた	読み方を変え、受領票にサムネの枚数の行を足した（9/25）
9/25	作業ファイルが壊れていると、受領票が1行も書かれない穴（公開の前に手元で見つけた。本番では起きていない）	1つの行の読み込みの失敗が、受領票の全体を止める作り	その行が読めなくても、受領票は書く形にした（9/25）
9/26	「まだ告知していない記事」の数が、記事の一覧（0）と食い違った（1）	数え方が2通りあった	数え方を1つに揃えた（9/27）
9/27	手元の本番確認が受領票に書くと、翌朝の自動実行の保存とぶつかる作りの穴（ぶつかった記録は無い）	受領票の書き手が2つになる作り	書き先を分け、受領票への取り込みは朝の自動実行だけにした（9/28）
9/29	開始が3時間28分遅れ、突き合わせが不一致になった	GitHub の予約実行の混雑	直していない（起動の仕組みを見直す）
10/1	開始が3時間3分遅れ、突き合わせが不一致になった	確かめていない	直していない

上の3行は、受領票がまだ無かった時期の出来事です。何がどこまで動いたのかが残らなかったので、9月13日に受領票を足しました。

そのあとの 9/14・9/15・9/22 の行は、受領票が「全工程成功」でも合っていなかった出来事です。これが、想定を先に作って比べる突き合わせを足した理由です。

月の費用

部品	月の費用	根拠
受領票・突き合わせ・本番確認の取り込み	0円	X の API を呼ばない。すでにあるファイルを読んで、1行書くだけ
実行時間（GitHub Actions）	0円	朝の自動実行の全体で、9月は38回・合計577秒（1回の中央値は14秒）。無料枠の中
手元の本番確認	0円	公開したページを読むだけ
（参考）朝の自動実行が X から読む分	9月は約0.88ドル（概算）	自分の投稿の取り込み160件で約0.80ドル、自分宛の返信の取り込み16件で約0.08ドル。確かめるためだけの費用ではなく、朝の実行そのものの費用

部品ごとの役割

部品	役割	足した日
開始時刻の控え	開始時刻と、使った金額の数え始めの値を控える	9/13（金額は 9/22）
受領票	工程の成否、照合の結果、画像、サムネ、使った金額の前後の差を1行に書く。途中が失敗した朝も書く	9/13
突き合わせ	前の日の時点の記録から想定を作り、実際と10項目で比べて、受領票の行に足す。失敗しても、ほかの工程は止めない	9/25
本番確認（手元）	公開のあとに本番のページを確かめ、結果を1行記録する	9/27
本番確認の取り込み	手元の本番確認の記録を、翌朝の受領票に取り込む	9/28
投稿ボードの「今朝の実行」の行	その日の受領票を、ボードの上のほうに出す	9/15
保存	受領票を含む朝の出力を保存する。前の工程が失敗していても走る	8/19

関係する記録

解剖 01 ── 毎朝1本、X へ自動投稿する仕組みの構造
ツール「X自動投稿ボード一式」
X投稿を自動化した──HTML1枚から37日
AIの「読みました」「直しました」を、ぼくはどう確かめているか ── 自己申告と実際が違った3回
自動化の翌朝、botはgitで死んでいた

2026-10-02 更新: 図を、上から下への流れに描き直しました（箱と注記の文字は同じです）。あわせて本文の「流れは左から右です。」を「流れは上から下です。」に直しました。