インスタ自動投稿を、止めないための付録集

この記事について

これは、有料記事の付録A〜Dを、まとめて無料で公開したものです。
本編（有料）は 2026年9月5日（土） に公開します。

入っているのは、この4つです。

• 付録A　継続運用チェックリスト：期限を切らさない
  ／静かな故障に、早く気づく

• 付録B　コード一覧：どのファイルが何をしているか
  ／Claude Codeへの頼み方

• 付録C　用語集：引っかかった言葉を、その場で引く

• 付録D　更新履歴：この記事を、これからどう直していくか

無料にした理由も書いておきます。
付録Dは「買ったあと、どこを直したか」を残す場所です。
改訂は追加料金なしとお約束している以上、その履歴を有料の内側に
閉じるのは筋が通りません。
付録A〜Cも、本編の手順と対で使う参照資料です。
手元に置いて何度も開くものなので、まとめて外に出しました。

それでは、付録Aから始めます。

付録A　継続運用チェックリスト
── 期限を切らさない、静かな故障に気づく

この付録でやること

ここから先は、読む付録ではなく、使う付録です。

第8章までで、仕組みは完成しました。
あとは「動き続けてもらう」だけです。そのために必要な作業は、
実はとても少ない。週に5分と、月に15分。それだけです。

ただし、その少ない作業をやらないと止まります。
しかも、止まり方には決まった型があります。
この付録は、その型を先回りして潰すための手順書です。

やることを先にまとめておきます。大きく2つしかありません。

• ①

  • やること：3つの鍵の期限を切らさない

  • なぜ必要か：鍵が切れると、はっきり止まる（第7・8章）

  • 頻度：期限の1か月前・1週間前

• ②

  • やること：投稿の実物を、自分の目で見る

  • なぜ必要か：エラーが出ない「静かな故障」は、目でしか
    見つからない
    （第7章）

  • 頻度：週に5分

1. 3つの鍵の期限表 ── ★最初に一度だけ作る

第7章で整理した3つの鍵を、もう一度出します。
この表を、いま手元の手帳かメモアプリに書き写してください。
この付録でいちばん大事な作業は、これひとつです。

書き写すときは、期限の実日付を入れてください。こういう形です。

【自動投稿の鍵メモ】
・投稿用トークン（Instagram）   … 期限なし ※デバッガーで「Page／期限なし」を確認済み（YYYY-MM-DD）
・画像用PAT（IMAGES_REPO_PAT）  … 期限 YYYY-MM-DD  → 1か月前に作り直す
・cron発火用PAT（cron-job.org） … 期限 YYYY-MM-DD  → 1か月前に作り直す

投稿用トークンの「期限なし」について

3つのうち、投稿用トークンだけ「期限なし」と書きました。
ここは補足が要ります。

第3章の手順どおりに取れていれば、投稿用トークン（ページトークン）
に有効期限はありません。放っておいても切れません。ただし、
「正しく取れていれば」です。

• 手順の途中の貼り直しという一手を飛ばすと、見た目は同じでも数時間で
  切れる鍵が出来上がります（第7章の実話／第8章ケース1）。

• そして厄介なことに、その鍵でもテスト投稿は通ってしまいます。

だから、投稿用トークンについては「期限を管理する」のではなく、
取ったその場で性質を確認するのが正解です。

カレンダーに2回入れておく

期限のある2つの鍵（画像用PAT・cron発火用PAT）は、カレンダーに2回、
予定として入れておくのが確実です。

• 期限の1か月前：「画像用PATの期限まで1か月」
  ／ 気づくだけでいい。まだ何もしなくてよい

• 期限の1週間前：「画像用PATを作り直す」 ／ この日に作り直す
  （作業は10分）

2. 毎週やること（5分）

ここからが定期点検です。まず週に一度、5分。おすすめは日曜の夜か、
月曜の朝です。

いちばん大事なのは、2つめの「実物を3本、最後まで読む」です。

実物を3本読む ── ここでしか見つからない故障がある

第7章で説明したとおり、この仕組みにはエラーが出ない故障があります。

• 土曜の朝なのに「今ごろ会社で…」と書いてある（曜日を渡し忘れ）

• 実在しない時刻を書いている（「毎朝9時ごろ」問題）

• 同じ言い回しが毎日出てくる（クセ）

• 画像の中で、見出しが変なところで折り返されている／端が切れている

これらは全ステップ緑で、通知も来ません。数字にもすぐには出ません。
自分の目で読む以外に、見つける方法がありません。

見つけたら、その場で直さなくていい

おかしな投稿を見つけたとき、あわてて直す必要はありません。
メモしておいて、まとめてClaude Codeに相談すれば十分です。

3. 毎月やること（15分）

月に一度、15分。毎月1日など、日付を決めてしまうのが楽です。

利用料の確認

第2章で説明したとおり、この仕組みでお金がかかるのは2か所だけです。

• Claude Code（作るとき）

  • どこで見るか：「console.anthropic.com」 の利用状況、
    または契約しているプランの請求

  • 目安：作っている期間だけ。運用が始まれば触る回数は激減する

• 文章を作るAPIキー（毎日）

  • どこで見るか：同上（従量課金）

  • 目安：1日2投稿なら、月に数百円の範囲におさまることが多い

GitHub・cron-job.org・画像の置き場は、この規模なら
すべて無料枠の中です。

数字を1行だけ記録する

第7章で週次レポートを自動化しているので、数字は勝手に届きます。
それとは別に、月に一度だけ、手で1行書き残すことをおすすめします。

2026-08-01  フォロワー125人（前月比+16）／リーチ率12%／エンゲージ率36%／この月にやったこと：note記事を2本公開

4. 年に一度やること（1月）

年に一度でいい確認もあります。年明けの、時間のあるときで十分です。

5. 鍵を作り直すときのチェックリスト

期限が近づいたとき、あるいは止まって作り直すときの手順です。
鍵ごとに違うので、3つぶん載せます。

① 投稿用トークンを作り直す（第3章）

② 画像用PATを作り直す（第5章）

③ cron発火用PATを作り直す（第6章）

6. 止まったときの緊急チェックリスト

投稿が出ていないことに気づいたときの、最初の3分です。
第8章の要約なので、詳しくはそちらを見てください。
ここは「開いてすぐ動ける版」です。

7. 仕様変更を、自分で追えるようになる

この記事は2026年時点の仕様をもとに書いています。
Instagram側の仕組みは、これからも変わります。
「変わったら詰み」では困るので、変更を自分で拾う方法を
用意しておきます。

やることは、3つの窓口を月に一度のぞくだけです。
全部読む必要はありません。

• 「Graph API Changelog」：APIの仕様変更・新バージョン・廃止予定
  ／ 日付の新しい数件だけ見る

• 「Instagram Platform Changelog」：Instagram側に限った変更 ／ 同上

• アプリのお知らせ（「developers.facebook.com」 のダッシュボード
  ／登録アドレスへのメール）：あなたのアプリに影響する変更だけが届く
  ／ ★これがいちばん大事。メールを見逃さない

バージョンの廃止スケジュールの読み方

コードの中には、「v21.0」 のようなAPIのバージョン番号が書
かれています。これは「この仕様で話しかけます」という宣言です。

• Metaは新しいバージョンを定期的に出し、
  古いバージョンは約2年で使えなくなります。

• 使えなくなると、ある日を境に投稿が全部エラーになります。

• ただし、廃止の日付は事前に公表されます。突然消えることは
  ありません。

もうひとつの窓口：障害情報

「自分は何も変えていないのに、今日だけ失敗した」というとき、
Meta側の一時的な障害であることがあります。

• 「metastatus.com」 で、
  Instagram関連の障害が出ていないかを見られます。

• 障害なら、こちらは何もしないのが正解です。
  復旧すれば翌日から通ります。

8. 記録のつけ方 ── 1行でいい

最後に、地味ですがいちばん効くものを。

何かあったら、1行だけ書き残してください。

2026-08-09  朝も昼も投稿されず。原因＝投稿用トークンが短期のものだった（貼り直しを飛ばしていた）。
            作り直して復旧。以後、デバッガーで Page／期限なし を毎回確認する。

これだけです。凝った書式はいりません。

★ まとめて使うチェックリスト（コピー用）

ここまでの内容を、そのまま書き写して使える形でまとめておきます。
この節だけコピーして、メモアプリに貼ってください。

■ 鍵の期限メモ（最初に一度だけ書く）
・投稿用トークン（Instagram）   … 期限なし ※Page／期限なしを確認した日：____-__-__
・画像用PAT（IMAGES_REPO_PAT）  … 期限 ____-__-__ → 1か月前と1週間前にカレンダー登録
・cron発火用PAT（cron-job.org） … 期限 ____-__-__ → 1か月前と1週間前にカレンダー登録

■ 毎週（5分・日曜の夜など）
[ ] 1週間ぶん、投稿が出ているか
[ ] 投稿の実物を3本、最後まで読む（曜日・時刻・言い回し・画像の折り返し）
[ ] 失敗通知メールが来ていないか
[ ] 週次レポートのメールが届いているか

■ 毎月（15分・1日など）
[ ] 鍵の期限まで、あと何日か
[ ] Actions に赤い実行が無かったか
[ ] cron-job.org の実行履歴に失敗が続いていないか
[ ] 今月の利用料と、上限設定が効いているか
[ ] Metaからのお知らせメールを確認
[ ] フォロワー数と、その月にやったことを1行記録

■ 年に一度（1月・30分）
[ ] 使っているAPIバージョンが廃止予定でないか
[ ] 1年ぶんの数字を振り返る
[ ] 投稿テーマ（柱）の見直し
[ ] プランの見直し
[ ] メールの2段階認証・アプリパスワードの確認

■ 止まったとき（3分）
[ ] ① その時刻の実行があるか（無い＝cron側 / ある＝②へ）
[ ] ② どのステップが赤いか（最後だけ赤い＝投稿用トークン）
[ ] ③ メッセージの末尾をコピー
[ ] ④ 鍵の文字列を伏せて、Claude Codeに貼って相談
[ ] ⑤ 直ったら1行記録

つまずきポイント早見表

• 期限をメモしたが、どこに書いたか忘れた

  • なぜ起きるか：保存場所が「そのとき開いていたアプリ」だった

  • どうするか：毎月かならず目に入る1か所に決めて、3行まとめて書く

• 期限の当日に気づいて慌てる

  • なぜ起きるか：カレンダー登録が1回だけだった

  • どうするか：1か月前と1週間前の2回入れる

• cron発火用PATだけ見つからない

  • なぜ起きるか：GitHubの金庫を探している

  • どうするか：置き場所は cron-job.org の設定画面の中

• 鍵を更新したのに、翌日また止まった

  • なぜ起きるか：登録しているジョブが複数あるのに1つしか
    直していない

  • どうするか：8:00・12:30・週次と、全ジョブぶん更新する

• 新しいトークンにしたのに、また切れた

  • なぜ起きるか：貼り直しの一手を飛ばした

  • どうするか：デバッガーで タイプ＝Page／有効期限＝なしを毎回確認

• 数字は取れるのに、伸びの理由が分からない

  • なぜ起きるか：数字だけ残して、やったことを書いていない

  • どうするか：月に1行、「その月にやったこと」を書き足す

• Changelogを読み始めたが、意味が分からない

  • なぜ起きるか：全部読もうとしている

  • どうするか：アプリ宛のお知らせメールだけ見る。
    分からなければ貼って聞く

• 何も変えていないのに今日だけ失敗した

  • なぜ起きるか：Meta側の一時的な障害

  • どうするか：まず 「metastatus.com」 を見る。障害のときは触らない

この付録のまとめ

• やることは2つだけ。①3つの鍵の期限を切らさない②週に5分、
  投稿の実物を自分の目で読む。

• 鍵の期限表は、手帳かメモアプリに書き写す。
  記事を開き直さないと見られないチェックリストは、やらなくなります。

• 投稿用トークンは「期限を管理する」のではなく「取った瞬間に性質を
  確認する」。見るのはタイプ＝「Page」／有効期限＝「なし」の
  2行だけ。
  この30秒が、丸一日ぶんの投稿を守ります。

• cron発火用PATだけ、置き場所が違う。
  GitHubの金庫ではなく、cron-job.org の設定の中。

• エラーが出ない故障は、
  読むことでしか見つからない。週に3本、最後まで読む。

• 仕様変更は、アプリ宛のお知らせメールだけ見ればいい。
  意味が分からなければ、そのまま貼って聞く。

• 何かあったら1行残す。同じ故障は、半年後にもう一度来ます。

次の付録へ

ここまでが「動き続けてもらうため」の手順です。次の付録Bには、
この仕組みを構成しているファイルの一覧を載せます。
どのファイルが何をしているのか、直したいときどこを触ればいいのかが分
かる地図です。こちらも、通して読むものではありません。
「あの処理はどこにあるんだったか」と思ったときに開くページとして
使ってください。

付録B　コード一覧 ── どのファイルが、何をしているか

この付録でやること

この仕組みは、Pythonのファイルが7本と、GitHub Actionsの手順書
（ワークフロー）が2本でできています。それだけです。しかも、
毎日の投稿に関わるのは、そのうち3本だけです。

この付録は、その全部の地図です。

そしてもうひとつ、この記事の建て付けを繰り返しておきます。

あなたはコードを書きません。読む必要も、写す必要もありません。

コードは、Claude Codeに読ませるための材料です。
「このリポジトリのコードを参照して、私のアカウント用に組んで」
と頼むための地図が、この付録です。
だから、この付録に載っているのはコードそのものではなく、
「どのファイルが何をしているか」と「頼むときの言い方」です。

全体像 ── 2つの倉庫と、9つのファイル

第2章で説明したとおり、この仕組みは2つの倉庫（リポジトリ）
を使います。

• 仕組み本体

  • 公開/非公開：非公開（プライベート）

  • 何が入っているか：この付録に載っているファイル一式。鍵は入れない
    （金庫＝Secretsに入れる）

• 画像の置き場

  • 公開/非公開：公開（パブリック）

  • 何が入っているか：毎日作られた画像1枚とキャプション。
    Instagramに画像を取りに来てもらうために公開

仕組み本体のファイル構成

（仕組み本体のリポジトリ）
├── .github/
│   └── workflows/
│       ├── daily_post.yml          … 毎日の投稿の手順書（第5章）
│       └── weekly_analytics.yml    … 週1回の数字収集の手順書（第7章）
├── content_generator.py            … 投稿の中身（文章＋画像）を作る（第4章）
├── instagram_poster.py             … Instagramに投稿する（第3章）
├── notify.py                       … 失敗したときにメールで知らせる（第5章）
├── analytics_fetcher.py            … 数字を取ってくる（第7章）
├── analytics_report.py             … 数字をレポートにまとめる（第7章）
├── email_report.py                 … レポートをメールで送る（第7章）
├── validation/
│   └── validate.py                 … 4つの疎通テストをまとめて実行する（第3章）
├── requirements.txt                … 必要な部品の一覧
├── assets/                         … キャラクター画像などの素材
├── outputs/                        … その日作られた画像・キャプションの置き場（実行のたびに上書き）
└── analytics/                      … 集めた数字とレポートの蓄積

ファイルと「4つの関所」の対応

第8章で、トラブルは上流から下流へ4つの関所を順に疑う、と
説明しました。その関所と、ファイルの対応がこれです。
赤いバツが出たステップから、見るべきファイルが決まります。

• ① 合図を出す：（そもそも実行が始まらない）
  ／ ファイルではなく cron-job.org の設定

• ② 中身を作る：「Generate post image & caption」
  ／ 「content_generator.py」

• ③ 画像を置く：「Push image to public images repo」
  ／ 「daily_post.yml」（ワークフローの中で直接やっている）

• ④ 投稿する：「Post to Instagram」 ／ 「instagram_poster.py」

• （失敗の通知）：「Notify on failure (email)」 ／ 「notify.py」

ファイル別・詳細

ここから1本ずつ見ていきます。
各ファイルについて、役割／受け取るもの／出すもの／頼み方の4点だけ
載せます。

① 「content_generator.py」 ── 投稿の中身を作る（第4章）

この仕組みの心臓部で、いちばん大きいファイルです。「今日は何を、
どんな顔で、どう書くか」を全部ここで決めています。

• 役割：今日のテーマを決め、Claudeに文章を書かせ、
  その文章と表情つきキャラクターを合成して1枚の画像にする

• 受け取るもの：文章生成用のAPIキー（「ANTHROPIC_API_KEY」）
  ／実行時刻の枠（8:00か12:30か）／テーマの指定（任意）

• 出すもの：「outputs/post.png」（投稿画像）／「caption.txt」
  （本文）／「hashtags.txt」／「post.json」（次の工程へ渡す情報）

中でやっていることを、順番に並べるとこうです。

• 1

  • やっていること：日付から、今日のテーマ（柱）を決める

  • 第何章の話か：第4章

• 2

  • やっていること：今日が平日か休日かを判定する（土日＋休日リスト）

  • 第何章の話か：第4・7章

• 3

  • やっていること：投稿枠（8:00 / 12:30）から、その時刻の状況を決める

  • 第何章の話か：第7章

• 4

  • やっていること：Claudeに、見出し・本文・ハッシュタグ・表情を書かせる

  • 第何章の話か：第4章

• 5

  • やっていること：書かれた内容を検査する
    （曜日の矛盾／実在しない時刻／使わない言い回し）

  • 第何章の話か：第7章

• 6

  • やっていること：おかしければ、
    書き直させる。それでもダメなら予備の文章に切り替える

  • 第何章の話か：第4・8章

• 7

  • やっていること：表情に合うキャラクター画像を選ぶ

  • 第何章の話か：第4章

• 8

  • やっていること：見出しを折り返して、画像に合成する

  • 第何章の話か：第4章

触ることになるのは、たいてい次の4か所です。

• どんな人物として書くか
  （一人称・年齢感・生活・口調）：書かせ方の指示文（PERSONA）

• 投稿のテーマ：柱の定義と、その出現比率

• 使ってほしくない言い回し：置き換えのリスト（第7章の「クセを潰す」）

• 祝日・長期休暇：休日として扱う日付のリスト（年に数回、手で足す）

② 「instagram_poster.py」 ── Instagramに投稿する（第3章）

画像とキャプションを、実際にInstagramへ出すファイルです。
ここが赤くなるときは、たいてい投稿用トークンの話です（第8章ケース
1）。

• 役割：公開URLに置かれた画像を指定して、Instagramに投稿する

• 受け取るもの：投稿用トークン（「INSTAGRAM_ACCESS_TOKEN」）／宛先
  アカウントの数字ID（「INSTAGRAM_ACCOUNT_ID」）／画像の公開URL
  （「POST_IMAGE_URL」）／「post.json」

• 出すもの：投稿の完了と、投稿ID（ログに出る）

投稿は、3段階で行われます（第3章で説明した流れそのままです）。

1. 「この画像とこの文章で投稿します」と予約する
   （入れ物＝コンテナを作る）

2. 準備ができるまで待つ（Instagram側が画像を取りに来る時間）

3. 公開する

③ 「notify.py」
── 失敗したときだけメールで知らせる（第5章）

いちばん短いファイルですが、いちばん存在価値のあるファイル
かもしれません。

• 役割：投稿が失敗したときだけ、メールを送る

• 受け取るもの：送信元のメール設定
  （「SMTP_USER」 / 「SMTP_PASSWORD」）／失敗した実行のURL

• 出すもの：メール1通

④ 「analytics_fetcher.py」 ── 数字を取ってくる（第7章）

ここから3本は、週に1回だけ動く「数字まわり」のファイルです。
毎日の投稿とは独立していて、止まっても投稿には影響しません。

• 役割：Instagramから、
  アカウントと各投稿の数字を取ってきて、記録に追記する

• 受け取るもの：投稿用トークン
  ／アカウントID／「全部を遡るかどうか」の指定

• 出すもの：「analytics/account_history.jsonl」
  （アカウントの推移）／「media_history.jsonl」（投稿ごとの数字）

このファイルの特徴的な仕事がひとつあります。

投稿された時刻から、「朝の枠」か「昼の枠」かを判定して、
記録に付けています。

• 朝の枠：7:30〜9:30

• 昼の枠：12:00〜13:30

• それ以外：上記以外（手動の告知投稿など）＝A/Bの集計から外す

⑤ 「analytics_report.py」
── 数字をレポートにまとめる（第7章）

• 役割：集めた数字を集計し、Claudeの所見を添えて1枚のレポートにする

• 受け取るもの：蓄積された記録（JSONL）／文章生成用のAPIキー

• 出すもの：「analytics/latest_report.md」
  （最新版）／「analytics/reports/YYYY-MM-DD.md」（保存版）

レポートに載るのは、次の4つです。

1. アカウントの推移（フォロワー数と、その増減）

2. ★朝と昼の比較（本数・平均リーチ・エンゲージ率・保存率）

3. 曜日別の傾向

4. 反応の大きかった投稿の一覧

⑥ 「email_report.py」 ── レポートをメールで送る（第7章）

• 役割：出来上がった週次レポートを、メールで自分に送る

• 受け取るもの：「notify.py」 と同じメール設定

• 出すもの：メール1通（本文＋ファイル添付）

⑦ 「validation/validate.py」
── 4つの疎通テストをまとめて実行する（第3章）

作っている途中でいちばん世話になるファイルです。
毎日の投稿には関わりませんが、「いま、どこまで通っているか」
を一発で確認できます。

• 役割：4つの疎通確認を、まとめて1回で実行する

• 確認する4つ：①投稿用トークン ②画像の公開URL ③通知メール ④
  文章生成のAPIキー

• 出すもの：それぞれ「通った／通らなかった」の結果（画面に表示）

⑧ 「daily_post.yml」 ── 毎日の投稿の手順書（第5章）

ここから2本は、PythonではなくGitHub Actionsの「作業手順書」
（ワークフロー）です。
「どのファイルを、どういう順番で動かすか」だけが書いてあります。

• 役割：毎日の投稿を、上から順に実行する

• 起動のしかた：外から合図を受けて起動
  （cron-job.org から。第6章）／手動実行も可

• 受け取るもの：投稿枠
  （「time_slot」）とテーマの指定（「pillar」。どちらも任意）

ステップの並びは、こうなっています。第8章で赤いバツを探すのは、
この並びの中です。

• 1：「Checkout」 ／ コードを取ってくる

• 2：「Setup Python」 ／ Pythonを用意する

• 3：「Install dependencies」 ／ 必要な部品を入れる

• 4：「Download Noto Sans JP fonts」
  ／ 日本語フォントをダウンロードする

• 5：「Generate post image & caption」 ／ ★中身を作る
  （「content_generator.py」）

• 6：「Convert post.png to JPEG」 ／ 画像をJPEGに変換する

• 7：「Push image to public images repo」
  ／ ★画像を公開の置き場に運ぶ（公開URLが決まる）

• 8：「Post to Instagram」 ／ ★投稿する（「instagram_poster.py」）

• 9：「Notify on failure
  (email)」 ／ 失敗したときだけメールを送る（「notify.py」）

• 10：「Upload artifacts
  (debug)」 ／ その日作られた画像などを数日保存する

⑨ 「weekly_analytics.yml」
── 週1回の数字収集の手順書（第7章）

• 役割：週に1回、数字を集めてレポートを作り、メールで送る

• 起動のしかた：cron-job.org から週1回（日曜の朝など）／手動実行も可

• 受け取るもの：「全部を遡るか」の指定
  （「backfill」。最初の1回だけ「true」）

• 1〜3：準備 ／ 「daily_post.yml」 と同じ

• 4：「Measure」 ／ 数字を取ってくる（「analytics_fetcher.py」）

• 5：「Analyze」 ／ レポートを作る（「analytics_report.py」）

• 6：送信 ／ メールで送る（「email_report.py」）

• 7：コミット ／ 集めた数字とレポートをリポジトリに保存する

環境変数（金庫に入れるもの）の一覧

コードの中に鍵は1つも書きません。
全部、GitHubの「金庫」（Secrets）と「変数」（Variables）
から受け取ります。この表が、登録すべきものの全部です。

任意で足せるもの（無くても動きます）：

• 「NOTIFY_EMAIL_TO」：失敗通知の宛先を、送信元と別にする

• 「REPORT_EMAIL_TO」：週次レポートの宛先を、別にする

• 「POST_PILLAR」：テーマを指定して1本だけ作る（動作確認用）

• 「POST_DATE」：日付を指定して作る
  （「土曜日の投稿はどう出るか」を試すとき）

• 「GRAPH_API_VERSION」：APIのバージョンを上げるとき（付録A）

必要な部品（「requirements.txt」）

Pythonの部品は、たった4つです。

• 「requests」：インターネット越しにやりとりする

• 「pillow」：画像を作る・合成する

• 「anthropic」：文章を書かせる

• 「numpy」：画像の背景を切り抜く計算

コードを、Claude Codeにどう渡すか

最後に、この付録のいちばん実用的な使い方を書いておきます。

最初に組むとき

一部だけ直したいとき

動かなくなったとき

つまずきポイント早見表

• どのファイルを直せばいいか分からない：症状とファイルが
  結びついていない ／ この付録の「4つの関所とファイルの対応」表を見る

• コードを全部読もうとして進まない：読む前提で構えている
  ／ 読まなくていい。URLを渡して頼む

• 直したら、前に入れた調整が消えた：ファイル全体を作り直す提案を受け
  入れた ／ 「変更する箇所だけ教えて」と頼む

• 画像の日本語が全部□になる：実行環境に日本語フォントが無い
  ／ ワークフローのフォント取得ステップがあるか確認（第5章）

• 「IMAGES_REPO」 が空だと言われる：金庫
  （Secrets）のタブに入れている／ 「Variables」タブに登録し直す

• 数字だけ取れない：トークンに数字を読む権限が無い
  ／ 権限を追加してトークンを作り直す（付録A）

• 週次の処理が失敗した：数字まわりのどれか
  ／ 毎日の投稿には影響しません。落ち着いて翌週でも構わない

• 土曜の投稿を確認したいが土曜まで待てない：日付を指定できることを
  知らない ／ 「POST_DATE」 で日付を指定して1本だけ作る

この付録のまとめ

• 仕組みは Pythonが7本＋手順書が2本。
  しかも毎日の投稿に関わるのは3本だけです。

• ファイルの分かれ方は、第8章の「4つの関所」とそのまま
  対応しています。赤いバツが出たステップから、
  見るべきファイルが決まります。

• 心臓部は 「content_generator.py」。人物設定・テーマ・言い回し・休日
  リストの4か所が、いちばんよく触るところです。

• 鍵はコードに書きません。全部、金庫（Secrets）と変数
  （Variables）から受け取ります。「IMAGES_REPO」 だけは変数。

• コードは読むものではなく、渡すもの。公開リポジトリのURLを
  Claude Codeに渡して、「参照して組んで」と頼んでください。

• 直すときは「変更する箇所だけ教えて」。
  これを言わないと、入れた調整が消えます。

次の付録へ

次の付録Cは、この記事に出てくる言葉の用語集です。
「トークンとPATって何が違うんだったか」
「コンテナって何のことだったか」——読んでいて引っかかった言葉を
引くための索引です。こちらも、通して読むものではありません。

付録C　用語集 ── 引っかかった言葉を引く

この付録でやること

本文を読んでいて「この言葉、前にも出てきたけど何だったか」
と思ったときに引く索引です。

この付録は、次の順で並べています。

• 1：★紛らわしい言葉の区別
  （トークンが2種類ある、など。ここだけは一読の価値あり）

• 2：この記事の中で使っている「たとえ」の一覧

• 3：Claude Code・パソコンまわり

• 4：GitHubまわり

• 5：Instagram・Metaまわり

• 6：自動実行（cron）まわり

• 7：数字・分析まわり

• 8：エラー・技術一般

1. ★紛らわしい言葉の区別

この記事を読んでいて混乱するとしたら、たぶんこの5組のどれかです。
ここだけは、目を通しておくと後が楽になります。

①「トークン」が2種類ある

• アクセストークン：鍵・許可証のこと。Instagramに投稿する許可
  ／ 第3章、第8章

• トークン（AIの単位）：文章の分量の単位。料金の計算に使う ／ 第2章
  （コストの話）

②「トークン」と「PAT」

• アクセストークン：Instagram/Metaの鍵 ／ 投稿用トークン

• PAT（Personal Access Token）：GitHubの鍵 ／ 画像用PAT／cron発火用PAT

③「Secrets」と「Variables」

• Secrets：GitHubの「金庫」 ／ 見られたら困るもの
  （鍵・パスワード）。登録後は中身を見られない

• Variables：「変数」 ／ 見られても困らないもの
  （置き場の名前など）。あとから中身を確認できる

④「リーチ」と「インプレッション」

• リーチ：何人に届いたか（同じ人が3回見ても「1」）

• インプレッション（表示回数）：何回表示されたか
  （同じ人が3回見たら「3」）

⑤「公開リポジトリ」と「非公開リポジトリ」

• 非公開（プライベート）：仕組み本体／ 人に見せる必要がない

• 公開（パブリック）：画像の置き場だけ
  ／ Instagramが画像を取りに来るので、公開でないと届かない

2. この記事で使っている「たとえ」

技術用語をそのまま出すと読みにくいので、本文ではいくつかたとえを
使っています。対応表です。

• 金庫

  • 正式には：Secrets

  • どういうものか：鍵を安全にしまっておく場所

• 作業手順書

  • 正式には：ワークフロー（Workflow）

  • どういうものか：「何を、どの順で実行するか」を書いた指示書

• 無料の倉庫

  • 正式には：GitHub

  • どういうものか：コードやファイルを置いておく場所

• 時報係／目覚まし時計

  • 正式には：cron-job.org

  • どういうものか：決まった時刻に「実行して」と合図を送る外部サービス
    （第1章では「外付けの目覚まし時計」、
    第6章以降は「時報係」と呼んでいます。同じものです）

• 4つの関所

  • 正式には：（この記事の独自表現）

  • どういうものか：合図 → 中身を作る → 画像を置く → 投稿する、
    の4段階

• 静かな故障

  • 正式には：（この記事の独自表現）

  • どういうものか：エラーが出ないまま、中身だけおかしくなっている状態

• 柱

  • 正式には：（この記事の独自表現）

  • どういうものか：投稿のテーマの大きな軸。何本か決めて日替わりで順番
    に回すやり方（この記事では4本立て、うち販促の1本は初期休止＝実質3本
    ／第4章）

• 予備の文章

  • 正式には：フォールバック

  • どういうものか：AIがうまく書けなかったときに使う、
    あらかじめ用意した文章

3. Claude Code・パソコンまわり

• Claude Code：Anthropic社のAIに、パソコンの中の作業（ファイルを
  作る・直す・動かす）を任せられる道具。
  この記事ではデスクトップアプリ版を使う（第2章）

• プロンプト：AIへの頼み方の文章。
  この記事では「Claude Codeへの頼み方の例」として何度も出てくる

• API：プログラム同士が話すための窓口。
  「InstagramのAPI」＝Instagramに機械から話しかけるための窓口

• APIキー：その窓口を使うための鍵。
  この記事では文章を書かせるために1本使う（「ANTHROPIC_API_KEY」）

• 従量課金：使った分だけ払う方式。文章生成のAPIキーがこれ（第2章）

• ターミナル：文字でパソコンに命令する画面。
  この記事では基本的に使いません（任意枠）

• VS Code：プログラムを書くための道具。
  これも任意。使わなくても最後まで進めます

• Python：この仕組みを書いてある言語。読めなくて構いません

• ライブラリ／依存関係：「既にある部品」を借りて使う仕組み。
  この記事で使う部品は4つだけ（付録B）

• 環境変数：プログラムに、
  外から値を渡すための入れ物。鍵をコードに書かずに渡すために使う

4. GitHubまわり

• GitHub：コードやファイルを置いておける、
  無料の「倉庫」。この仕組みの土台（第2章）

• リポジトリ：倉庫の中の1部屋。この記事では2つ使う
  （仕組み本体・画像の置き場）

• 公開／非公開：その部屋を誰でも見られるか、
  自分だけか。画像の置き場だけ公開にする

• コミット：変更を記録として確定すること

• プッシュ：手元の変更を、GitHubへ送ること

• クローン：GitHubにあるものを、手元にまるごと持ってくること

• main（メイン）：標準の作業場所の名前。この記事では常にここだけ使う

• GitHub Actions：GitHubが用意している実行係。
  決められた手順を、GitHubのコンピュータで動かしてくれる（第5章）

• ワークフロー：その「作業手順書」。この仕組みには2本ある
  （毎日の投稿・週1回の数字収集）

• ステップ：手順書の中の1行の作業。
  実行画面で緑チェックや赤いバツが付く単位

• Secrets（金庫）：鍵を安全にしまう場所。一度入れると中身は見られない

• Variables（変数）：秘密でない設定値の置き場。
  あとから中身を確認できる

• PAT（Personal Access Token）：GitHubの鍵。この仕組みでは2本使う
  （画像用・cron発火用）

• アーティファクト：実行の結果として保存しておけるファイル。
  作られた画像を数日残すのに使っている

• workflow_dispatch：「外から合図をもらったら実行する」という
  起動方式。cron-job.org から叩くために使う（第6章）

5. Instagram・Metaまわり

• Meta：Facebook・Instagramを運営している会社。
  開発者向けの設定は全部この会社の画面で行う

• Graph API：Meta が用意している、
  機械から操作するための窓口。Instagramへの投稿もここを通る（第3章）

• プロアカウント／ビジネスアカウント：Instagramの業務用の設定。
  これに切り替えないと、自動投稿はできません（第3章）

• Facebookページ：Instagramのビジネスアカウントとつないでおく必要
  があるページ。実質、手続き上の要件

• Metaアプリ：開発者向け画面で作る「申請の単位」。
  鍵は、このアプリに紐づいて発行される

• IG User ID／アカウントID：投稿先のアカウントを表す数字の並び。名前
  （@〜）ではなくこの数字で指定する

• アクセストークン：投稿する許可証。この仕組みでいちばん止まる原因
  （第8章ケース1）

• ユーザートークン／ページトークン：トークンの種類。この仕組みで
  使うのはページトークン。ユーザートークンのままだと使えない

• 短期／長期（永続）：トークンの寿命。
  正しい手順を踏むと、ページトークンは期限なしになる

• スコープ（権限）：その鍵で何ができるかの範囲。
  投稿の権限、数字を読む権限、などが個別に付く

• Graph API Explorer：鍵を取得するための、Metaの作業画面

• Access Token Debugger：鍵の種類と有効期限を確認する画面。
  ★この2行を見る習慣が、事故を防ぎます

• メディアコンテナ：投稿の下書きの入れ物。
  「この画像とこの文章で投稿します」と予約した状態（第3章）

• 公開（publish）：その入れ物を、実際にタイムラインへ出す操作

• レート制限：「一定時間に何回まで」という回数制限。
  1日2投稿ならまず当たりません

• フィード投稿／ストーリーズ
  ／リール：投稿の種類。この記事で扱うのはフィード投稿（画像1枚）だけ

6. 自動実行（cron）まわり

• cron（クロン）：「決まった時刻に、
  決まったことを実行する」仕組みの総称

• cron-job.org：この記事で使う外部の時報係。
  無料。決まった時刻にGitHubへ合図を送る（第6章）

• crontab（クロン式）：実行時刻の書き方。
  「0 9 * * 0」 で「毎週日曜9時」のように書く

• ジョブ：cron-job.org に登録した1件の予定。この仕組みでは3件
  （8:00の投稿／12:30の投稿／週1回の数字収集）

• タイムゾーン：時刻の基準地域。
  ★「Asia/Tokyo」 になっているかを必ず確認する（第6・8章）

• JST / UTC / PDT：日本時間／世界標準時／アメリカ西海岸の時間。
  エラーの表示は日本時間とは限りません（第8章ケース1）

• 手動実行（Run workflow）：時刻を待たずに、
  その場で1回動かすこと。動作確認に使う

• 二重発火：同じ実行が2回起きること。同じ投稿が2回出る原因
  （第8章ケース10）

7. 数字・分析まわり

• インサイト：Instagramが出している数字のこと。
  読むには専用の権限が要る

• リーチ：何人に届いたか（同じ人が何度見ても1）

• インプレッション（表示回数）：何回表示されたか

• エンゲージメント：いいね・コメント・保存など、何らかの反応の合計

• エンゲージ率：届いた人のうち、
  何%が反応したか。「届いた人に刺さったか」を見る数字

• リーチ率：フォロワー数のうち、
  何%に届いたか。「そもそも見られているか」を見る数字

• 保存率：届いた人のうち、
  何%が保存したか。「あとで読み返したい」と思われた度合い

• A/Bテスト：1つの条件だけを変えて比べること。
  この記事では「朝8:00 vs 昼12:30」

• スロット（枠）：投稿の時間帯の区分。この仕組みでは朝・昼・それ以外
  （手動の告知など）に分ける

• バックフィル：過去のぶんを遡って一括で取り込むこと。
  最初の1回だけ使う

• JSONL：1行に1件ずつデータを書き足していく形式。
  数字の蓄積に使っている

8. エラー・技術一般

• HTTPステータス：通信の結果を表す3桁の番号。
  下の4つだけ知っていれば足ります

• 400：こちらの言い方がおかしい（内容の不備）

• 401 / 403：鍵の問題（無効・権限不足）

• 404：宛先が見つからない（名前の間違い）

• 「code 190」：Metaのエラー番号で、
  ★「トークンの問題」を意味する番号。これが出たら第8章ケース1へ

• YAML（ヤムル）：手順書（ワークフロー）を書いている形式。
  行頭の空白に意味があるので、直すときは慎重に

• JSON：データをやりとりする形式。エラーメッセージもこの形で返ってくる

• Markdown（マークダウン）：文章に見出しや箇条書きを付ける、
  軽い書き方。レポートがこの形式

• SMTP：メールを送るための仕組み。通知メールに使っている

• アプリパスワード：Gmailなどで、プログラムからメールを送るために
  発行する専用のパスワード。普段のパスワードとは別物

• 2段階認証：ログイン時に、パスワード＋もう1つの確認を求める設定。
  アプリパスワードを発行するには、
  これが有効になっている必要があります

• ログ：実行の記録。エラーは「読む」ものではなく「渡す」もの（第8章）

• 豆腐（□）：日本語フォントが無い環境で、
  文字が四角に化ける現象。第5章でつまずくポイント

この付録のまとめ

• 言葉を覚える必要はありません。引っかかったときに引ければ十分です。

• ★混乱しやすいのは5組：トークンの2つの意味／トークンとPAT／Secrets
  とVariables／リーチとインプレッション／公開と非公開リポジトリ。

• 「code 190」 はトークン、401・403は鍵、404は宛先。
  この3つだけ頭の隅にあると、第8章を開いたときの理解が速くなります。

• 分からない言葉に出会ったら、
  そのままClaude Codeに聞いてください。「これは何ですか」で十分です。

次の付録へ

最後の付録Dは、更新履歴です。この記事は、Instagram側の仕様変更や、
読んでくださった方からの指摘に応じて改訂していきます。
いま読んでいる版がいつ時点のものか、そしてどこが変わったかを、
そこで確認できます。

付録D　更新履歴 ── この記事は、これからも直します

この付録でやること

この記事は、書き終わったら終わり、にはしません。

理由は単純で、Instagram側の仕組みが変わるからです。
画面のボタンの名前が変わることもあれば、APIのバージョンが切り
替わることもあります。
そのたびに手順が合わなくなり、「記事のとおりにやったのに、
その画面が無い」ということが起こります。

この付録は、そのための場所です。

• いま読んでいる版が、いつ時点のものか

• 前の版から、どこが変わったか

• 更新されたことを、どうやって知るか

• おかしなところを見つけたとき、どこに伝えればいいか

1. この版について

• 版：v1.0（初版）

• 公開日：2026年9月5日

• 記載内容の基準時点：2026年8月
  （この時点の画面・仕様で全手順を実際に通しています）

• APIのバージョン：Instagram Graph API v21.0

• 著者の運用実績：@harumi_auto にて、
  2026年6月19日から毎日2回の自動投稿を継続運用中

2. 更新の方針 ── 買ったあとの改訂は、追加料金なしです

はっきり書いておきます。

この記事を一度購入していただければ、その後の改訂版は、追加の
料金なしで読めます。

noteの記事は、購入した記事がそのまま更新される仕組みです。
私が本文を直せば、あなたが開いているページも新しくなります。
買い直しは発生しません。

何を直すか

• ★仕様変更で手順が合わなくなった箇所：画面の名前が変わった
  ／APIのバージョンが上がった／権限の名前が変わった

• 読者の方から指摘をいただいた、
  分かりにくい箇所：説明の順番、言葉の定義、つまずきやすい前提

• 私自身が新しく踏んだトラブル：第8章にケースを追加します

• 運用して分かった、数字の傾向：第7章の実データを更新します

何は直さないか

• 構成そのもの（章立て）：途中まで読んでくださっている方が、
  迷子になるため

• 著者の体験談・失敗談：そのときに起きた事実なので、書き換えません

3. 更新されたことを、どうやって知るか

• ★この付録Dを見る：いちばん確実です。
  更新するたび、下の履歴表に1行増えます

• noteの更新通知：記事が更新されると、購入者に通知が届く場合があります

• @harumi_auto（Instagram）：大きめの改訂をしたときは、
  投稿でお知らせします

4. 間違い・分かりにくい箇所を見つけたら

遠慮なく教えてください。いちばん助かります。

• noteのコメント欄：この記事のコメント欄に書いていただくのが、
  いちばん確実です

• Instagram：@harumi_auto のDM

書いていただけると助かる内容は、この3点です。

1. どの章・どのあたりか（「第3章のトークン取得のところ」で十分です）

2. 記事に書いてある画面と、実際の画面がどう違ったか

3. エラーが出た場合は、そのメッセージ（⚠️鍵の文字列は伏せてください）

5. 更新履歴

新しいものが上です。

• v1.0

  • 日付：2026-09-05

  • 変更内容：初版公開。第1〜8章＋付録A〜D。@harumi_auto の実運用
    （2026年6月19日〜）にもとづく

6. 今後、追加を予定しているもの

いまの時点で「そのうち足したい」と考えているものを、正直に
並べておきます。
約束ではありません（いつになるか分からないものも含みます）。

• 第8章のケース追加：新しいトラブルを踏むたびに足します。
  これは確実に増えます

• 第7章の数字の更新：運用が半年・1年と続いたときの数字に差し替えます

• 祝日の扱いを自動化する方法：いまは手でリストに書き足す方式です
  （第7章）。もっと楽な方法が固まったら足します

• 鍵の期限が近いことを、実行前に知らせる仕組み：付録Aのチェックリスト
  を、仕組み側で肩代わりする案。私自身がいちばん欲しい機能です

この付録のまとめ

• この版は v1.0（2026年9月5日
  ／内容は2026年8月時点）。APIのバージョンは 「v21.0」。

• 改訂は追加料金なし。
  noteの記事がそのまま更新されます。買い直しは発生しません。

• 更新されたかどうかは、この付録Dの履歴表を見れば分かります。

• おかしなところを見つけたら、
  ぜひ教えてください。⚠️ただし鍵の実物は送らないでください。

• 永続的な仕様対応は約束できません。
  だからこそ、付録Aの「変更を自分で追う方法」を用意しています。