私がやってきたことを全部書き出したら、14万字になりました

なぜ書いたのか

この note を始めたとき、私は「毎日インスタを更新している人」では
ありませんでした。平日は朝から晩まで会社にいて、帰宅は22時半ごろ。
ソファに座った時点で、その日の気力はもう残っていません。

それでも @harumi_auto は、6月19日から今日まで、朝8時と昼12時半に
投稿を出し続けています。私が会議に出ている間も、通勤の間も、
寝ている間もです。

止まったのは、これまでに一度だけ。まる一日、朝も昼も出なかった
日があります。その日に何が起きたのかは、この記事の後半で
そのまま公開します。

作ったときのことを思い返すと、いちばん苦しかったのはコードを書く
ことではありませんでした。コードは Claude Code が書いてくれます。
苦しかったのは、Instagramに投稿するための「鍵」を手に入れる工程と、動き出したあと、エラーも出さずに壊れていくものの存在でした。
どちらも、ネットで調べても断片しか出てきません。
私は何度も詰まって、そのたびに1日を溶かしました。

その「溶かした1日」を、全部書き出しました。

何を書いたのか（目次を全部出します）

もったいぶっても仕方がないので、目次はすべて公開します。
章のタイトルだけでなく、その下の小見出しまで全部です。

読んでいただくと分かりますが、前半は「作る話」、後半は「動き出した
あとの話」に分かれています。私が時間を溶かしたのは後半なので、
そちらのほうが厚くなりました。

はじめに

• 平日夜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つの倉庫と、10のファイル
  （ファイル構成／「4つの関所」との対応）

• ファイル別・詳細（投稿の中身を作る／Instagramに投稿する／
  失敗したときだけ知らせる／数字を取ってくる／レポートにまとめる／
  メールで送る／疎通テストをまとめて実行する／毎日の投稿の手順書／
  週1回の数字収集の手順書）

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

• 必要な部品

• コードを、Claude Codeにどう渡すか
  （最初に組むとき／一部だけ直したいとき／動かなくなったとき）

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

• ★紛らわしい言葉の区別（「トークン」が2種類ある／
  「トークン」と「PAT」／「Secrets」と「Variables」／
  「リーチ」と「インプレッション」／
  「公開リポジトリ」と「非公開リポジトリ」）

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

• Claude Code・パソコンまわり

• GitHubまわり

• Instagram・Metaまわり

• 自動実行（cron）まわり

• 数字・分析まわり

• エラー・技術一般

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

• この版について

• 更新の方針 ── 買ったあとの改訂は、追加料金なしです
  （何を直すか／何は直さないか）

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

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

• 更新履歴

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

どれくらいの量になったか

書き終えて数えたら、こうなりました。

• 本文 … 約143,000字

• 画面キャプチャ … 21枚

• 図（システム構成図・実行画面のイメージ図など） … 8枚

• 構成 … 本編8章＋はじめに（付録4本は無料の別記事）

最初に構想したときは「3万字くらいかな」と思っていました。
5倍近くになった理由は単純で、つまずいた箇所を省かなかったからです。
「ここは適当に読み飛ばしてください」と書けば10分の1にできますが、
私自身がそういう記事に何度も苦労させられてきたので、それは
やめました。

キャプチャは、Metaの設定画面のように文章だけでは絶対に伝わらない場所
に集中して置いてあります。個人情報が写っている部分は、すべてぼかし
処理をしてあります。

正直に：こういう方には、合いません

販売前に書いておいたほうがフェアだと思うので、先に書きます。
次の3つに当てはまる方には、この記事はおすすめしません。

• ボタン1つで全部やってくれる完成アプリを期待している方。
  これは「自分で仕組みを組む」記事です。

• コードの中身を一切読む気がない方。コピペすら不要な作りには
  しましたが、最低限「いま何が動いているか」は理解していただく
  前提で書いています。

• Instagram Graph API の規約変更に、永続的に対応してほしい方。
  これは2026年時点の仕様がベースです。仕様が変わったときに
  自分で追える方法は付録Aにまとめましたが、「未来永劫そのまま動く」
  お約束はできません。

3つ目については、次の節で補足させてください。

毎月いくらかかるか（実額を出します）

「自動化」と聞くと月額が怖い方もいると思うので、実際にかかっている
金額をそのまま出します。

• GitHub（コードの保管・自動実行） … 無料

• cron-job.org（定時実行の合図） … 無料

• 画像の配信 … 無料

• Instagram Graph API（投稿の実行） … 無料

• 投稿文を毎回作らせるAI … 有料（ここだけ）

つまり、毎月お金がかかっているのは、投稿文を作らせる分だけです。

@harumi_auto は1日2本、月にすると約60本を自動生成しています。
その実測が、月に400円前後でした（週に1回の数字レポート込み・
2026年10月）。AIが書く文章の長さや為替で月ごとに揺れますが、
多い月でも500円ほどです。

缶コーヒー3本ぶんほどです。私はこの金額を見たとき、正直
「もっとかかっていると思っていた」と拍子抜けしました。

ひとつ、白状しておきます

さきほど「未来永劫そのまま動くお約束はできない」と書きました。
これは体裁の話ではなく、つい先日それが起きたので書いています。

私は先日、投稿文を作らせるAIを新しい世代のものに入れ替えました。
作業としては、設定ファイルの中の名前を1つ書き換えるだけです。
5分で終わる、はずでした。

ところが動かしてみると、新しいAIは返事の形が変わっていました。
それまでは「返事のいちばん最初に本文がある」前提で作ってあったのに、
新しいAIは最初に考えごとを返してくるようになっていたのです。仕組みは
本文を取り出せずに失敗し、あらかじめ用意しておいた予備の文章に
静かに差し替えて、そのまま投稿しました。

エラーは出ません。実行結果は緑のまま。通知も飛びません。
気づかなければ、翌朝から毎日、予備の文章がずっと出続けていた
はずです。

見つけられたのは、本番に出す前に「投稿せずに文章だけ作ってみる」
やり方を、この記事を書きながら用意していたからでした。
皮肉な話ですが、
記事の第7章に「動いているは、正しいではない」という節を書いた私が、
その節に書いたとおりのことを自分でやらかしたわけです。

だから、買ったあとの改訂は追加料金なしにしました。仕様が変わったり、
私が新しく別の落とし穴にはまったりしたら、そのつど記事を直します。
note の有料記事は、買った人がいつでも最新版を読める作りなので、
これができます。更新の方針と履歴は付録Dにまとめてあります。

★ 試し読み：第8章から、1節を丸ごと公開します

ここからが今日の本題です。

有料記事の中から、第8章のケース1「アクセストークンが切れた」を、
まるごとそのまま公開します。抜粋でも要約でもなく、有料で読める本文と
一字一句同じものです。

この節を選んだ理由は3つあります。

1. 私が実際に、これで丸一日ぶんの投稿を落としたから。
   前々回の失敗談の続きにあたる、いちばん新しい失敗談です。

2. この節だけで完結して読めるから。
   他の章を読んでいなくても意味が通るように書いてあります。

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」がそろっていれば、
まず間違いありません。ただ、念のため無実を確認しておくと安心なものが
3つあります。どれも1〜2分で済みます。

• 時刻の合図（cron側）… GitHub の Actions タブに、
  その時刻の実行が残っているか → 実行が残っている＝合図は届いている

• 画像を運ぶ鍵… 同じ実行の中の、
  画像を置くステップ → 緑チェックで成功している＝この鍵は生きている

• 文章を作る部分… 同じ実行の中の、
  中身を作るステップ → 緑チェックで成功している＝ここも生きている

実話：私は、これで丸一日ぶんの投稿を落としました

ここからは、実際に起きたことをそのまま書きます。

ある土曜日、私は投稿用トークンを作り直しました。目的は、
投稿とは別の用件でした（数字を読むための権限を1つ追加したかった）。
手順どおりに進めて、最後にテスト投稿をして、成功も確認しました。
画面には投稿のIDが表示され、Instagramを開けば投稿もちゃんと出ている。
その時点では、何ひとつ問題は見えませんでした。

ところが翌日、朝も昼も、投稿が1本も出ませんでした。

原因を追いかけて、青ざめました。トークンを作る手順には、途中で一度、
取得したトークンを画面上部の入力欄に貼り直すという、地味だけれど絶対
に飛ばしてはいけない工程があります。私はそこを飛ばしていた。
その結果、「ずっと使える鍵」ではなく「数時間で切れる鍵」を
作ってしまい、それを金庫（GitHubのSecrets）に入れていたのです。

そして、いちばん間が悪かったのがここです。

だから成功してしまった。「確認した」という記憶だけが残り、
翌朝には切れていた——というのが顛末です。

なぜ切れたのか ── 「短期の鍵」と「長期の鍵」

なぜ「数時間で切れる鍵」ができてしまうのか。ここだけ、仕組みを
知っておくと再発を防げます。

Instagramに投稿するための鍵（アクセストークン）は、2段階で作ります。

• 1段目：あなた自身の鍵（ユーザートークン）… 発行直後は短期。
  長期に交換する操作をして初めて長持ちする

• 2段目：ページの鍵（ページトークン）＝ これを投稿に使う … 1段目の鍵
  の寿命を、そのまま引き継ぐ

落とし穴は、この一行に尽きます。

復旧の手順

ここからが実作業です。@harumi_auto で実際に復旧したときの順番を、
そのまま書きます。所要時間は15〜20分ほどです。

① Metaの「Graph API Explorer」を開く

developers.facebook.com/tools/explorer/
を開きます。ここは、Metaが用意しているAPIのお試し画面です。

② 必要な権限をチェックして、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 … 数字（リーチ・保存など）を読む

③ 1段目の鍵を「長期」に交換する

ここが第1の要点です。②で出てきた鍵は短期なので、長期に交換する
操作をします。画面上部のURL欄を書き換えて送信する形になります
（正確な書き方はClaude Codeに聞くのが確実です。アプリIDと
アプリシークレットという2つの値を、自分のアプリの設定画面から
持ってくる必要があります）。

④ ★長期になった鍵を、画面上部のトークン欄に「貼り直す」

この記事の中で、いちばん飛ばされやすく、いちばん高くつく一手です。

③で長期の鍵が返ってきますが、画面上部の入力欄には、まだ②の短期の
鍵が入ったままです。ここで③の長期の鍵をコピーして、上部の欄に
貼り直します。

⑤ 2段目の鍵（投稿に使う鍵）を取り出す

貼り直した状態で、自分のページの情報を取得するリクエストを送ります。
返ってきたデータの中に「access_token」という項目があり、
これが投稿に使う鍵です。

⑥ ★「アクセストークンデバッガー」で、鍵の正体を確認する

ここが、この節でいちばん覚えておいてほしい工程です。

developers.facebook.com/tools/debug/accesstoken/
を開き、⑤で得た鍵を貼って「デバッグ」を押します。すると、
その鍵の正体が表で表示されます。見るのは2行だけです。

• タイプ … 正しい値は「Page」。
  「User」になっているなら、⑤を取り違えている
  （1段目の鍵を見ている）

• 有効期限 … 正しい値は「なし」。
  日時が入っているなら、それは短期の鍵。④の貼り直しを飛ばしている

⑦ GitHubの金庫（Secrets）の鍵を差し替える

GitHubのリポジトリの「Settings → Secrets and variables → Actions」
を開き、投稿用トークンを入れてある項目（@harumi_auto では
「INSTAGRAM_ACCESS_TOKEN」）を Update して、新しい鍵に
差し替えます。

⑧ 投稿せずに、疎通だけ確かめる

差し替えたら動作確認をしたくなりますが、ここでいきなり投稿を
実行しないほうがいいです。復旧作業の途中で余計な投稿が出ると、
その日の投稿の並びが崩れます。

⑨ 次の自動発火を待って、実物を見る

疎通が確認できたら、あとは次の定時（@harumi_auto なら翌朝8:00）
を待ちます。翌朝、Instagramを開いて投稿が出ていれば、復旧完了です。

落とした分の投稿を、あとから出すべきか

止まっていた日の投稿を「取り返す」べきか——これは、
私はやらないほうがいいと考えています。

二度と起こさないための、3つの習慣

• ① 鍵を触ったら、必ずデバッガーで見る … タイプ＝「Page」
  ／有効期限＝「なし」。この2行だけ。30秒で済みます

• ② テスト投稿を「確認」と呼ばない … テスト投稿は「いま使えるか」
  しか分かりません。明日も使えるかは、デバッガーにしか分かりません

• ③ 権限は、必要そうなものを最初から全部入れる … あとから
  足せません。足したくなったときの作り直しが、事故の温床です
  （私の場合はまさにそれでした）

この節のまとめ（ここだけ読んだ方へ）

• 最後の投稿ステップだけが赤いバツで、
  「"code": 190」が出ていたら、投稿用トークンの期限切れです。

• 原因のほとんどは、2段階のうち「長期にした鍵を貼り直す」一手を
  飛ばしたこと。見た目では区別がつかない短期の鍵が出来上がります。

• 「テスト投稿が通った」は、正しさの証拠になりません。
  私は切れる4分前にテストして、翌日止めました。

• 確認すべきはアクセストークンデバッガーの2行——タイプ＝「Page」
  ／有効期限＝「なし」。

• 復旧は、1段目からやり直して、金庫の鍵を差し替え、
  投稿せずに読み取りだけで疎通確認し、次の定時を待つ。

価格と、買ったあとのこと

長くなりました。最後に、値段の話をさせてください。

販売開始から9日間は早期価格を置いていましたが、いまは5,980円です。
期間や人数の区切りはありません。

いつ買っても、中身は同じものが手に入ります。
期間限定で読めるページのようなものは用意していません。
「買った方はいつでも最新版が読めます」という、
下に書いた約束と食い違ってしまうからです。

記事に入っているもの ── プロンプト／ペルソナの穴埋め集

これは、記事そのものの一部として入っています。

記事の中でいちばん「自分用に書き換える必要がある」部分——AIに渡す
指示文と、「中の人」の設定——を、コードから切り離した穴埋め式の
テキストにまとめて、記事の末尾に収めてあります。ここは人によって
中身がまったく違うところなので、雛形があると最初の一歩が
軽くなります。

買ったあとのことも書いておきます

• 改訂は追加料金なしです。仕様が変わったときや、私が新しく
  別の落とし穴にはまったときは、そのつど本文を直します。
  note の有料記事なので、買った方はいつでも最新版が読めます。

• どこを直したかは、付録Dの更新履歴に残します。
  「買ったあと静かに書き換わっていた」という状態にはしません。

• 間違いや分かりにくい箇所を見つけたら、
  教えてください。直した上で、履歴にその旨を残します。

さいごに

この note を始めたのは7月5日でした。
「毎日インスタを更新したいけれど、
平日の夜にそんな時間はない」という、それだけの話から始まって、
気がつけば6本の記事を書き、そのあいだも @harumi_auto は勝手に投稿を
続けていました。

派手な成果は出ていません。前回書いたとおり、フォロワーの伸びは
鈍っていますし、投稿が届いているのはフォロワーの1割ほどです。

それでも、止まったのが一度だけで済んだことと、
止まったときに自分で直せたこと——この2つだけは、
はっきり手元に残りました。それを全部書き出したのが、この記事です。

同じように「時間はないけれど、続けたい」と思っている方に、
遠回りをせずに済む地図として届いたらうれしいです。

それでは、また次の記事で。

ハルミ

📷 Instagram → @harumi_auto
今日話した仕組みが、いまも毎日ここで動いています。