私がやってきたことを全部書き出したら、14万字になりました
前回は、2か月ぶんの数字を並べました。フォロワーの伸びも、
朝と昼の差も、投稿が届いていない9割のことも、そのまま出しました。
今日は少し毛色が違います。
この2か月半、私が何をどう作ってきたのかを、丸ごと1本にまとめた
記事を、9月5日から有料で出します。その中身の話をさせてください。
なぜ書いたのか
この note を始めたとき、私は「毎日インスタを更新している人」では
ありませんでした。平日は朝から晩まで会社にいて、帰宅は22時半ごろ。
ソファに座った時点で、その日の気力はもう残っていません。
それでも @harumi_auto は、6月19日から今日まで、朝8時と昼12時半に
投稿を出し続けています。私が会議に出ている間も、通勤の間も、
寝ている間もです。
止まったのは、これまでに一度だけ。まる一日、朝も昼も出なかった
日があります。その日に何が起きたのかは、この記事の後半で
そのまま公開します。
作ったときのことを思い返すと、いちばん苦しかったのはコードを書く
ことではありませんでした。コードは Claude Code が書いてくれます。
苦しかったのは、Instagramに投稿するための「鍵」を手に入れる工程と、動き出したあと、エラーも出さずに壊れていくものの存在でした。
どちらも、ネットで調べても断片しか出てきません。
私は何度も詰まって、そのたびに1日を溶かしました。
その「溶かした1日」を、全部書き出しました。
何を書いたのか(目次を全部出します)
もったいぶっても仕方がないので、目次はすべて公開します。
章のタイトルだけでなく、その下の小見出しまで全部です。
読んでいただくと分かりますが、前半は「作る話」、後半は「動き出した
あとの話」に分かれています。私が時間を溶かしたのは後半なので、
そちらのほうが厚くなりました。
💡 第2章から付録Aまでの各章には、それぞれ冒頭に「この章でやること」、
末尾に「つまずきポイント早見表」と「この章のまとめ」が付いています。
以下の一覧では、この3つは繰り返しになるので省いています。
はじめに
平日夜10時半に帰宅する会社員が、毎日インスタを更新できている理由
この記事を読むと、何ができるようになるか
なぜ「自動化」だったのか
想定している読者(プログラミングが分からなくても大丈夫です)
この記事が想定していない読者
かかるコスト(① 作るとき:Claude Code / ② 毎日動かすとき:
Anthropic APIキー)この記事の使い方
第1章 全体像を理解する
まず「地図」を手に入れる
なぜ、この構成なのか
登場人物(部品)の紹介
システム構成図
データの流れ ── 投稿1回が走るまでに何が起きているか
なぜ「目覚まし」を外注するのか ── cron-job.org を使う本当の理由
「全自動」の限界 ── 手動投稿を、あえて残す
完成形を、いま見てください
第2章 環境構築 ── 作業場を用意する
まず、用意するもの(環境の前提)
なぜ「デスクトップアプリ版」なのか
Claude Code(デスクトップアプリ版)を導入する
(ダウンロード/サインイン/プランを選ぶ)課金上限を設定する(やらないと、いつか泣きます)
動作確認 ── Claude Codeに最初の一声をかける
GitHubアカウントを用意する
(そもそも「リポジトリ」とは/この記事では「2つの倉庫」を使います)【任意】ターミナル/VS Codeで使いたい人へ(上級者向け)
第3章 Instagram Graph API 攻略 ── この記事いちばんの山場
まず地図を見る ── なぜここが難しいのか
ステップ0 ── 「2つの取得方式」があることを知る(重要な前提)
ステップ1 ── Instagramをプロアカウントにする
ステップ2 ── Facebookページを用意して、Instagramと連携する
ステップ3 ── Meta for Developers に登録する
ステップ4 ── アプリを作成する
ステップ5 ── 必要な権限(permission)を理解する
ステップ6 ── アクセストークンを取得する
ステップ7 ── トークンを「長持ちする鍵」にする
ステップ8 ── InstagramビジネスアカウントID(投稿の宛先)を
取得するステップ9 ── 取得した鍵と宛先を「疎通テスト」する
ステップ10 ── 実際に1枚、テスト投稿してみる
取得した「鍵と宛先」をどこに置くか
トークンの期限切れに、どう備えるか
よくあるエラーと対処
第4章 投稿コンテンツをClaude Codeに作らせる
この章は「読むだけ」で大丈夫 ── 先に肩の力を抜いてください
まず方針 ── 中身を「毎日ゼロから考える」のは絶対に続かない
「中の人」を一人だけ、先に決めておく ── ペルソナの固定
ネタを生成させる ── 「決まった形(JSON)」で返してもらう
平日と休日で書き分ける ── 運用で踏んだ落とし穴
読まれる工夫 ── 1行目とハッシュタグ
画像を毎回そろえる ── ブランドカード+キャラクター合成
画像の「置き場所」 ── ImgBBではなく、GitHubから配る
投稿前に自動で弾く ── 品質チェック
第5章 GitHub Actions で実行させる
先に、肩の力を抜いてください ── 全部を理解してから進めなくていい
なぜ「自分のパソコン」ではダメなのか ── クラウドで動かす理由
全体像 ── ワークフローという「作業手順書」
ステップ1:鍵を「金庫」にしまう ── Secrets の登録
(「秘密ではない設定」は Variables へ)ステップ2:画像を運ぶための専用キー ── 画像リポジトリ用 PAT
ステップ3:手順書(ワークフロー)を、決まった場所に置く
ステップ4:まず手元で確かめてから、クラウドへ
ステップ5:いよいよ動かす ── 「Run workflow」を押す
ステップ6:結果を「ログ」で読む ── 緑のチェックと赤いバツ
第6章 cron-job.org で定期実行する
先に、肩の力を抜いてください ── 全部を理解してから進めなくていい
なぜ「外部のスケジューラー」が要るのか
全体像 ── 「ボタンを押す」を、URLで肩代わりさせる
ステップ1:発火専用の鍵(cron発火用PAT)を用意する
ステップ2:cron-job.org に登録する
ステップ3:何を叩くか ── URL とリクエストの中身
ステップ4:いつ叩くか ── スケジュール(8:00 と 12:30)
ステップ5:テスト発火 ── 「204」が出れば成功
ステップ6:二重の安全網 ── 失敗にちゃんと気づく
第7章 運用設計 ── 動き出した仕組みと、どう付き合うか
先に、肩の力を抜いてください ── この章は、読むだけでいい章です
「動いている」は、「正しい」ではない
3つの鍵の期限管理 ── いちばんよく止まる原因
(実話:私は、期限切れで丸一日ぶんの投稿を落としました)投稿の頻度をどう決めるか ── 1日1回か、複数回か
投稿の時間帯をどう決めるか
数字を、手で数えるのをやめる
A/Bテストの見方 ── 平均だけで勝ち負けを決めない
(平均は簡単に揺れる/「リーチ」を見ないと分からない/見るべき
数字は結局この3つだけ)「自動だけだと飽きられる」問題
(テーマを何本かに分けて回す/言い回しの「クセ」を潰していく)手動を、どこに残すか ── 自動化しないと決めたもの
アカウントを止められないために
フォロワーが伸びないときに、見直す3点
第8章 トラブルシュート集 ── 止まったとき、どこから疑うか
大原則 ── 上流から下流へ、4つの関所を順に疑う
(最初の3分でやること)症状から引く ── 逆引き表
ケース1:アクセストークンが切れた ── いちばん多く、いちばん止まる
← ★今日この節を丸ごと公開しますケース2:そもそも実行が走っていない ── 合図が届いていない
ケース3:画像を置くステップで止まる
ケース4:全ステップ緑なのに、投稿が見当たらない
ケース5:文章を作るステップで止まる
ケース6:投稿は出ているのに、中身がおかしい
ケース7:数字が取れない ── 全部成功なのにレポートが空
ケース8:失敗しているのに、通知メールが来ない
ケース9:Instagram側に断られる ── 画像やキャプションの形式
ケース10:同じ投稿が2回出た
復旧したあとに、必ずやること
それでも分からないときの、頼み方
付録A 継続運用チェックリスト ── 期限を切らさない、
静かな故障に気づく
3つの鍵の期限表 ── ★最初に一度だけ作る(投稿用トークンの
「期限なし」について/カレンダーに2回入れておく)毎週やること(5分)── 実物を3本読む/見つけても、
その場で直さなくていい毎月やること(15分)── 利用料の確認/数字を1行だけ記録する
年に一度やること(1月)
鍵を作り直すときのチェックリスト
(投稿用トークン/画像用PAT/cron発火用PAT)止まったときの緊急チェックリスト
仕様変更を、自分で追えるようになる
(廃止スケジュールの読み方/障害情報の窓口)記録のつけ方 ── 1行でいい
★ まとめて使うチェックリスト(コピー用)
付録B コード一覧 ── どのファイルが、何をしているか
全体像 ── 2つの倉庫と、9つのファイル
(ファイル構成/「4つの関所」との対応)ファイル別・詳細(投稿の中身を作る/Instagramに投稿する/
失敗したときだけ知らせる/数字を取ってくる/レポートにまとめる/
メールで送る/疎通テストをまとめて実行する/毎日の投稿の手順書/
週1回の数字収集の手順書)環境変数(金庫に入れるもの)の一覧
必要な部品
コードを、Claude Codeにどう渡すか
(最初に組むとき/一部だけ直したいとき/動かなくなったとき)
付録C 用語集 ── 引っかかった言葉を引く
★紛らわしい言葉の区別(「トークン」が2種類ある/
「トークン」と「PAT」/「Secrets」と「Variables」/
「リーチ」と「インプレッション」/
「公開リポジトリ」と「非公開リポジトリ」)この記事で使っている「たとえ」
Claude Code・パソコンまわり
GitHubまわり
Instagram・Metaまわり
自動実行(cron)まわり
数字・分析まわり
エラー・技術一般
付録D 更新履歴 ── この記事は、これからも直します
この版について
更新の方針 ── 買ったあとの改訂は、追加料金なしです
(何を直すか/何は直さないか)更新されたことを、どうやって知るか
間違い・分かりにくい箇所を見つけたら
更新履歴
今後、追加を予定しているもの
💡 付録A〜Dは、有料記事とは別の無料記事にまとめてあります。
買わなくても、いま読めます。
→ インスタ自動投稿を、止めないための付録集
本編の手順と対で使う参照資料なので、文章の雰囲気を見ていただく
試し読みにもちょうどいいと思います。
どれくらいの量になったか
書き終えて数えたら、こうなりました。
本文 … 約143,000字
画面キャプチャ … 21枚
図(システム構成図・実行画面のイメージ図など) … 8枚
構成 … 本編8章+はじめに(付録4本は無料の別記事)
最初に構想したときは「3万字くらいかな」と思っていました。
5倍近くになった理由は単純で、つまずいた箇所を省かなかったからです。
「ここは適当に読み飛ばしてください」と書けば10分の1にできますが、
私自身がそういう記事に何度も苦労させられてきたので、それは
やめました。
キャプチャは、Metaの設定画面のように文章だけでは絶対に伝わらない場所
に集中して置いてあります。個人情報が写っている部分は、すべてぼかし
処理をしてあります。
💡 コード本体は、記事の中に貼るのではなく、誰でも見られる公開
リポジトリに置いてあります。
→ github.com/harumi-insta-auto/harumi-auto-template
買わなくても、いま見られます。ただし、これは中身が空っぽの雛形です。
「どのファイルが何をしていて、Claude Codeにどう頼めばいいか」の
地図は付録Bに書いてあります。
正直に:こういう方には、合いません
販売前に書いておいたほうがフェアだと思うので、先に書きます。
次の3つに当てはまる方には、この記事はおすすめしません。
ボタン1つで全部やってくれる完成アプリを期待している方。
これは「自分で仕組みを組む」記事です。コードの中身を一切読む気がない方。コピペすら不要な作りには
しましたが、最低限「いま何が動いているか」は理解していただく
前提で書いています。Instagram Graph API の規約変更に、永続的に対応してほしい方。
これは2026年時点の仕様がベースです。仕様が変わったときに
自分で追える方法は付録Aにまとめましたが、「未来永劫そのまま動く」
お約束はできません。
3つ目については、次の節で補足させてください。
毎月いくらかかるか(実額を出します)
「自動化」と聞くと月額が怖い方もいると思うので、実際にかかっている
金額をそのまま出します。
GitHub(コードの保管・自動実行) … 無料
cron-job.org(定時実行の合図) … 無料
画像の配信 … 無料
Instagram Graph API(投稿の実行) … 無料
投稿文を毎回作らせるAI … 有料(ここだけ)
つまり、毎月お金がかかっているのは、投稿文を作らせる分だけです。
@harumi_auto は1日2本、月にすると約60本を自動生成しています。
その実測が、月に200円前後でした。AIが書く文章の長さや為替で
月ごとに揺れますが、週に1回の数字レポートを足しても、多い月で
月500円には届きません。
缶コーヒー1〜2本ぶんです。私はこの金額を見たとき、正直
「もっとかかっていると思っていた」と拍子抜けしました。
⚠️ ただし、これは動かし続けるための費用です。最初に作るときは別で、
そこには Claude Code の利用料(サブスクか従量課金)がかかります。
作るのは最初の数日に集中する作業なので、「一時的にまとまって使う分」
と「毎月かかる分」を分けて考えてください。この分け方と、上限設定の
やり方も記事の中に書きました。
ひとつ、白状しておきます
さきほど「未来永劫そのまま動くお約束はできない」と書きました。
これは体裁の話ではなく、つい先日それが起きたので書いています。
私は先日、投稿文を作らせるAIを新しい世代のものに入れ替えました。
作業としては、設定ファイルの中の名前を1つ書き換えるだけです。
5分で終わる、はずでした。
ところが動かしてみると、新しいAIは返事の形が変わっていました。
それまでは「返事のいちばん最初に本文がある」前提で作ってあったのに、
新しいAIは最初に考えごとを返してくるようになっていたのです。仕組みは
本文を取り出せずに失敗し、あらかじめ用意しておいた予備の文章に
静かに差し替えて、そのまま投稿しました。
エラーは出ません。実行結果は緑のまま。通知も飛びません。
気づかなければ、翌朝から毎日、予備の文章がずっと出続けていた
はずです。
見つけられたのは、本番に出す前に「投稿せずに文章だけ作ってみる」
やり方を、この記事を書きながら用意していたからでした。
皮肉な話ですが、
記事の第7章に「動いているは、正しいではない」という節を書いた私が、
その節に書いたとおりのことを自分でやらかしたわけです。
だから、買ったあとの改訂は追加料金なしにしました。仕様が変わったり、
私が新しく別の落とし穴にはまったりしたら、そのつど記事を直します。
note の有料記事は、買った人がいつでも最新版を読める作りなので、
これができます。更新の方針と履歴は付録Dにまとめてあります。
★ 試し読み:第8章から、1節を丸ごと公開します
ここからが今日の本題です。
有料記事の中から、第8章のケース1「アクセストークンが切れた」を、
まるごとそのまま公開します。抜粋でも要約でもなく、有料で読める本文と
一字一句同じものです。
この節を選んだ理由は3つあります。
私が実際に、これで丸一日ぶんの投稿を落としたから。
前々回の失敗談の続きにあたる、いちばん新しい失敗談です。この節だけで完結して読めるから。
他の章を読んでいなくても意味が通るように書いてあります。有料でどこまで書いているか、いちばん正直に伝わる節だから。
手順の細かさも、写真の入り方も、しつこさも、ここを読めば
分かると思います。
ひとつだけ先にお断りします。ここから文体が急に変わります。
私のこの note はいつも一人称のゆるい読み物ですが、有料記事は
「あなたが手を動かすための説明」なので、地の文が説明口調になります。
そこも含めて、そのまま出します。
(ここから、有料記事 第8章より)
ケース1:アクセストークンが切れた
── いちばん多く、いちばん止まる
自動投稿が完全に止まる原因のうち、体感でいちばん多いのがこれです。
しかも厄介なことに、前の日まで何ごともなく動いていたのに、
ある朝を境にぱたりと止まります。
この節は、この記事の他の章を読んでいなくても、ここだけで完結して
読めるように書きます。少し丁寧すぎるくらいに書きますが、
実際に止まった朝に読む節なので、そのほうがいいと考えました。
まず、症状
昨日まで正常に投稿されていた。今日は朝も昼も、1本も出ていない。
GitHub Actions の実行履歴は残っている
(つまり、時刻の合図はちゃんと届いている)。実行を開くと、画像を作るところまでは全部成功(緑)。いちばん最後の
「Instagramに投稿する」ステップだけが赤いバツになっている。
この「最後の1ステップだけが赤い」という形が、トークン切れのいちばん
分かりやすい特徴です。

次に、エラーメッセージ
赤いバツのステップを開くと、こういうメッセージが出ています。
これは@harumi_auto で実際に出たものを、そのまま載せています。
create_media_container failed: HTTP 400
{"error": {"message": "Error validating access token: Session has expired on
Saturday, 08-Aug-26 04:00:00 PDT.", "code": 190, "error_subcode": 463}}英語ですが、見るべきところは3つだけです。
「Error validating access token」… アクセストークン
(投稿用の鍵)の検証に失敗した= 鍵が受け付けられなかった「Session has expired on …」… いつ切れたか。
ここに書かれている日時に、鍵は失効している「"code": 190」… Metaのエラー番号。
190は「トークンの問題」を表す番号。ここが190なら、ほぼ確定
💡 「"code": 190」を見つけたら、それはトークンの話です。
他のところ(時刻の合図、画像の置き場、文章の生成)をいくら見直しても
直りません。逆に、190以外の番号が出ているなら、この節ではなく後半の
ケースを見てください。
⚠️ 表示されている失効時刻は、日本時間ではないことがあります。
上の例の「PDT」はアメリカ西海岸の時間で、
日本時間より16時間遅れています。「08-Aug-26 04:00:00 PDT」は、
日本時間では 8月8日の20:00 です。「表示が昨日の日付だから今日は
関係ないのでは」と誤解しやすいので、時差だけ気に留めておいてください
(この換算もClaude Codeに聞けば一発で出ます)。
それが本当にトークンなのか ── 他の可能性を消す
「最後のステップだけ赤い」「code 190」がそろっていれば、
まず間違いありません。ただ、念のため無実を確認しておくと安心なものが
3つあります。どれも1〜2分で済みます。
時刻の合図(cron側)… GitHub の Actions タブに、
その時刻の実行が残っているか → 実行が残っている=合図は届いている画像を運ぶ鍵… 同じ実行の中の、
画像を置くステップ → 緑チェックで成功している=この鍵は生きている文章を作る部分… 同じ実行の中の、
中身を作るステップ → 緑チェックで成功している=ここも生きている
💡 ここが、この章の大原則の効き目です。「投稿の一歩手前まで、
全部うまくいっている」という事実そのものが、他の関所の無実証明
になります。止まった場所が、犯人を教えてくれるわけです。
実話:私は、これで丸一日ぶんの投稿を落としました
ここからは、実際に起きたことをそのまま書きます。
ある土曜日、私は投稿用トークンを作り直しました。目的は、
投稿とは別の用件でした(数字を読むための権限を1つ追加したかった)。
手順どおりに進めて、最後にテスト投稿をして、成功も確認しました。
画面には投稿のIDが表示され、Instagramを開けば投稿もちゃんと出ている。
その時点では、何ひとつ問題は見えませんでした。
ところが翌日、朝も昼も、投稿が1本も出ませんでした。
原因を追いかけて、青ざめました。トークンを作る手順には、途中で一度、
取得したトークンを画面上部の入力欄に貼り直すという、地味だけれど絶対
に飛ばしてはいけない工程があります。私はそこを飛ばしていた。
その結果、「ずっと使える鍵」ではなく「数時間で切れる鍵」を
作ってしまい、それを金庫(GitHubのSecrets)に入れていたのです。
そして、いちばん間が悪かったのがここです。
私がテスト投稿をしたのは、その鍵が切れる4分前でした。
だから成功してしまった。「確認した」という記憶だけが残り、
翌朝には切れていた——というのが顛末です。
⚠️ ここから引き出せる教訓:「テスト投稿が通った」は、トークンが
正しい証拠になりません。切れる直前の鍵でも、テストは通ります。
確かめるべきなのは「投稿できたかどうか」ではなく、鍵そのものの性質—
—種類は正しいか/有効期限はあるか、の2点です。確かめ方は、
このあとすぐ説明します。
💡 もうひとつ、救われた点も書いておきます。止まったこと自体には、
その日のうちに気づけました。
失敗したときだけ届くメール通知(第5章)と、
cron-job.org 側の通知(第6章)——この二重の網があったので、
「何日も止まったまま気づかない」という最悪の事態には
なりませんでした。
通知は、動いているときは何も言ってこないぶん存在を忘れがちですが、
こういう日のためにあります。
なぜ切れたのか ── 「短期の鍵」と「長期の鍵」
なぜ「数時間で切れる鍵」ができてしまうのか。ここだけ、仕組みを
知っておくと再発を防げます。
Instagramに投稿するための鍵(アクセストークン)は、2段階で作ります。
1段目:あなた自身の鍵(ユーザートークン)… 発行直後は短期。
長期に交換する操作をして初めて長持ちする2段目:ページの鍵(ページトークン)= これを投稿に使う … 1段目の鍵
の寿命を、そのまま引き継ぐ
落とし穴は、この一行に尽きます。
⚠️ 2段目の鍵の寿命は、「2段目を作った瞬間に、画面に入っていた1段目
の鍵が長期だったかどうか」で決まります。1段目を長期に交換する操作
をしても、その長期の鍵を画面の入力欄に貼り直さないまま2段目を
作ると、画面にはまだ短期の鍵が入ったままなので、出てくる2段目も
短期になります。
しかも、出来上がった鍵の見た目は、長期のものと区別がつきません。
私がはまったのは、まさにここです。
💡 さらにたちが悪いのは、2段目の鍵だけを後から
延長することはできないという点です。「短期のまま作ってしまった」
と気づいたら、1段目からやり直すしかありません。逆に言えば、
やり直しさえすれば必ず直ります。
復旧の手順
ここからが実作業です。@harumi_auto で実際に復旧したときの順番を、
そのまま書きます。所要時間は15〜20分ほどです。
⚠️ 作業に入る前にひとつ。トークンの文字列は、パスワードと同じ
機密情報です。画面のコピーを人に見せたり、
チャットに貼ったりしないでください。私はこの復旧作業のあいだ、
Claude Codeには手順だけを聞き、鍵の実物は一度も渡していません。
それで問題なく完了できます。
① Metaの「Graph API Explorer」を開く
developers.facebook.com/tools/explorer/
を開きます。ここは、Metaが用意しているAPIのお試し画面です。
⚠️ 最初に、画面右上の「Metaアプリ」の選択が正しいかを必ず
確認してください。別のアプリが選ばれた状態のまま作業すると、
まったく別のアカウント向けの鍵ができてしまいます。私は複数の
アカウントを運用しているので、ここを取り違えかけたことがあります。
画面に出ているアプリ名が、あなたが作ったアプリの名前になっているか、
指差し確認をおすすめします。
② 必要な権限をチェックして、1段目の鍵(短期)を発行する
権限の一覧から、必要なものにチェックを入れて
「Generate Access Token」を押します。@harumi_auto で使っている権限は
次の6つです。
pages_show_list … 自分のページの一覧を見る
business_management … ビジネス設定にアクセスする
instagram_basic … Instagramアカウントの基本情報を読む
instagram_content_publish … Instagramに投稿する(これが本命)
pages_read_engagement … ページの反応を読む
instagram_manage_insights … 数字(リーチ・保存など)を読む
💡 ここでチェックを入れ忘れた権限は、あとから鍵に足すことが
できません。
足したくなったら、また最初からやり直しです。私は数字を読む権限
(instagram_manage_insights)を最初に入れ忘れていて、あとで作り
直すはめになり、そのやり直しの最中に、この章のトラブルを
起こしました。
面倒でも、必要そうなものは最初から全部チェックしておくほうが、
結果的に早いです。
③ 1段目の鍵を「長期」に交換する
ここが第1の要点です。②で出てきた鍵は短期なので、長期に交換する
操作をします。画面上部のURL欄を書き換えて送信する形になります
(正確な書き方はClaude Codeに聞くのが確実です。アプリIDと
アプリシークレットという2つの値を、自分のアプリの設定画面から
持ってくる必要があります)。
⚠️ ここで実際に私がやった、しょうもないけれど時間を溶かすミスを2つ
書いておきます。①アプリシークレットの貼り間違い(「設定→
ベーシック」にある正しい値を使う。違う値だと
「Error validating client secret」と怒られます)②説明文の
プレースホルダーを消し忘れる。「{アプリID}」のような書き方を
そのまま貼ると、中かっこごと送信されてエラーになります。
記号ごと完全に消して、生の値だけを貼る——これだけで防げます。
④ ★長期になった鍵を、画面上部のトークン欄に「貼り直す」
この記事の中で、いちばん飛ばされやすく、いちばん高くつく一手です。
③で長期の鍵が返ってきますが、画面上部の入力欄には、まだ②の短期の
鍵が入ったままです。ここで③の長期の鍵をコピーして、上部の欄に
貼り直します。
⚠️ 私が丸一日ぶんの投稿を落としたのは、この一手を飛ばしたからです。
画面上は何も変わりませんし、飛ばしてもエラーは出ません。
だからこそ危ない。「貼り直したか?」を声に出して
確認するくらいでちょうどいいと思っています。
⑤ 2段目の鍵(投稿に使う鍵)を取り出す
貼り直した状態で、自分のページの情報を取得するリクエストを送ります。
返ってきたデータの中に「access_token」という項目があり、
これが投稿に使う鍵です。
⑥ ★「アクセストークンデバッガー」で、鍵の正体を確認する
ここが、この節でいちばん覚えておいてほしい工程です。
developers.facebook.com/tools/debug/accesstoken/
を開き、⑤で得た鍵を貼って「デバッグ」を押します。すると、
その鍵の正体が表で表示されます。見るのは2行だけです。
タイプ … 正しい値は「Page」。
「User」になっているなら、⑤を取り違えている
(1段目の鍵を見ている)有効期限 … 正しい値は「なし」。
日時が入っているなら、それは短期の鍵。④の貼り直しを飛ばしている

なし」の2行だけ
💡 この2行を確認する30秒が、丸一日ぶんの投稿を守ります。
私はこれを省いたせいで止めました。テスト投稿ではなく、この画面を
見てください。テスト投稿は「いま使えるか」しか教えてくれませんが、
この画面は「明日も使えるか」を教えてくれます。
⑦ GitHubの金庫(Secrets)の鍵を差し替える
GitHubのリポジトリの「Settings → Secrets and variables → Actions」
を開き、投稿用トークンを入れてある項目(@harumi_auto では
「INSTAGRAM_ACCESS_TOKEN」)を Update して、新しい鍵に
差し替えます。
💡 金庫の中身は、登録したあとは自分でも見られません(「Update
(上書き)」しかできない作り)。これは不便ではなく安全のためです。
ですから、古い値と見比べるようなことはできません。上書きしたら、
それが新しい鍵です。
⑧ 投稿せずに、疎通だけ確かめる
差し替えたら動作確認をしたくなりますが、ここでいきなり投稿を
実行しないほうがいいです。復旧作業の途中で余計な投稿が出ると、
その日の投稿の並びが崩れます。
💡 私は、数字を集めるワークフロー(第7章で作った週次のレポート)
を手動で実行して確認しました。これはInstagramに何も投稿せず、
読み取りだけを行うので、鍵が生きているかどうかだけを、安全に確
かめられます。読み取り専用の処理をひとつ持っておくと、こういうときに
効きます。
💬 Claude Codeへの頼み方の例:「投稿用トークンを差し替えました。
実際に投稿はせずに、新しいトークンで Instagram の情報が
読めるかどうかだけを確認したいです。いまあるワークフローのうち、
どれをどう実行すればいいか教えてください。」
⑨ 次の自動発火を待って、実物を見る
疎通が確認できたら、あとは次の定時(@harumi_auto なら翌朝8:00)
を待ちます。翌朝、Instagramを開いて投稿が出ていれば、復旧完了です。
📝 著者の実話:私は、翌朝の投稿が無事に出たのを確認するまで、
正直そわそわしていました。そして、翌朝ちゃんと出ていました。
そのときのほっとした感じは、手動で毎日投稿していたころには無
かったものです。自分が寝ている間に、仕組みが勝手に立ち
直ってくれたような気がして、少し妙な気分だったのを覚えています。
落とした分の投稿を、あとから出すべきか
止まっていた日の投稿を「取り返す」べきか——これは、
私はやらないほうがいいと考えています。
💡 理由は、文章が時間帯に合わせて書かれているからです。@harumi_auto
の投稿は「朝8:00の私」「昼12:30の私」を前提にした文章になっています。
それを夜に出すと、「昼休みです」という文章が22時に流れることになり、
かえって不自然です。止まった日は、静かに諦める。
1日投稿がなかったことに気づく読者は、まずいません。
二度と起こさないための、3つの習慣
① 鍵を触ったら、必ずデバッガーで見る … タイプ=「Page」
/有効期限=「なし」。この2行だけ。30秒で済みます② テスト投稿を「確認」と呼ばない … テスト投稿は「いま使えるか」
しか分かりません。明日も使えるかは、デバッガーにしか分かりません③ 権限は、必要そうなものを最初から全部入れる … あとから
足せません。足したくなったときの作り直しが、事故の温床です
(私の場合はまさにそれでした)
この節のまとめ(ここだけ読んだ方へ)
最後の投稿ステップだけが赤いバツで、
「"code": 190」が出ていたら、投稿用トークンの期限切れです。原因のほとんどは、2段階のうち「長期にした鍵を貼り直す」一手を
飛ばしたこと。見た目では区別がつかない短期の鍵が出来上がります。「テスト投稿が通った」は、正しさの証拠になりません。
私は切れる4分前にテストして、翌日止めました。確認すべきはアクセストークンデバッガーの2行——タイプ=「Page」
/有効期限=「なし」。復旧は、1段目からやり直して、金庫の鍵を差し替え、
投稿せずに読み取りだけで疎通確認し、次の定時を待つ。
(試し読みは、ここまでです)
価格と、早期の特典について
長くなりました。最後に、値段の話をさせてください。

早期価格3,980円は、2026年9月13日(日)23:59まで。9月14日(月)
の朝に5,980円へ戻します。
週末を2回はさむように区切りました。 平日は帰ってから長い記事を読む
時間がない、という前提でこの記事を書いているので、締切のほうを平日に
置くのは筋が通らないと思ったからです。
早期に買ってくださった方への特典
── 2,000円引き、それだけです
特典は値引き一本です。5,980円が3,980円になります。2026年9月13日
(日)23:59までにお買いいただいた方が対象で、人数制限はありません。
日付だけで区切ります。
「早期限定の追加コンテンツ」のようなものは用意していません。
あとから買った方が読めないページがあると、下に書いた「買った方
はいつでも最新版が読めます」という約束と食い違ってしまうからです。
中身は、いつ買っても同じものが手に入ります。
記事に入っているもの ── プロンプト/ペルソナの穴埋め集
特典ではなく、記事そのものの一部として書いておきます。
記事の中でいちばん「自分用に書き換える必要がある」部分——AIに渡す
指示文と、「中の人」の設定——を、コードから切り離した穴埋め式の
テキストにまとめて、記事の末尾に収めてあります。ここは人によって
中身がまったく違うところなので、雛形があると最初の一歩が
軽くなります。
💡 期間限定ではありません。いつお買いいただいても、記事の一部として
付いてきます。
買ったあとのことも書いておきます
改訂は追加料金なしです。仕様が変わったときや、私が新しく
別の落とし穴にはまったときは、そのつど本文を直します。
note の有料記事なので、買った方はいつでも最新版が読めます。どこを直したかは、付録Dの更新履歴に残します。
「買ったあと静かに書き換わっていた」という状態にはしません。間違いや分かりにくい箇所を見つけたら、
教えてください。直した上で、履歴にその旨を残します。
さいごに
この note を始めたのは7月5日でした。
「毎日インスタを更新したいけれど、
平日の夜にそんな時間はない」という、それだけの話から始まって、
気がつけば6本の記事を書き、そのあいだも @harumi_auto は勝手に投稿を
続けていました。
派手な成果は出ていません。前回書いたとおり、フォロワーの伸びは
鈍っていますし、投稿が届いているのはフォロワーの1割ほどです。
それでも、止まったのが一度だけで済んだことと、止まったときに自分で
直せたこと——この2つだけは、はっきり手元に残りました。それを
全部書き出したのが、9月5日に出す記事です。
同じように「時間はないけれど、続けたい」と思っている方に、
遠回りをせずに済む地図として届いたらうれしいです。
それでは、また9月5日に。
ハルミ
📷 Instagram → @harumi_auto
今日話した仕組みが、いまも毎日ここで動いています。
