はじめに

猫のいる宿を紹介するサイト「ねこ宿研究所」では、公開した記事をInstagramとThreadsでも紹介しています。

手作業で投稿を続けるのは難しいため、VPS上で動かしているHermes Agentの運用環境に、次の処理を行う自動投稿システムを作りました。

公開済み記事から投稿候補を選ぶ
InstagramとThreadsで異なる投稿文を組み立てる
Meta APIで投稿する
成功・失敗をDiscordへ通知する
cronから決まった時刻に実行する
失敗時は二重投稿を避けながら最大3回まで再試行する

実際に運用を始めると、再試行機能を追加した際にシェルスクリプトの実行権限が消え、cronが全停止する事故も起きました。本記事では、最終的な構成だけでなく、なぜその設計にしたか、障害から何を学んだかもまとめます。

なお、この記事は2026年8月時点で実際に構築・運用した内容です。Meta APIの仕様や必要な権限は変更される可能性があります。

Hermes AgentにAPIトークンを直接扱わせない

Hermes Agentは、Discordから指示を受け、スキルやターミナルを使って作業できるAIエージェントです。

最初は「Hermes Agentに記事を選ばせ、そのままMeta APIを呼ばせればよい」と考えました。しかし、外部投稿を自由なシェル操作へ任せると、次のリスクがあります。

同じ投稿を二重送信する
誤ったアカウントへ投稿する
タイムアウト時に、投稿済みか分からないまま再実行する
Discordの曖昧な指示を投稿承認として扱う
ログや会話へアクセストークンを出してしまう

そこで、Hermes AgentとMeta APIの間に、用途を限定したPython製の投稿ワーカーを置きました。

Discord
   ↓ 指示・完了通知
Hermes Agent
   ↓ 制限されたコマンドだけ実行
投稿候補選定スクリプト
   ↓ draft → approve → publish
投稿ワーカー
   ├─ Instagram API
   └─ Threads API

AIエージェントは運用や改修の窓口ですが、定刻投稿そのものは決定的なPythonスクリプトとcronで動かします。これにより、毎回LLMを呼ばず、モデルの利用枠や回答の揺らぎにも依存しない構成になりました。

コンテナとデータの分離

Hermes AgentはWordPressとは別のDocker Composeプロジェクトとして動かしています。WordPressのコンテナやDockerソケットはマウントせず、Hermes用のデータディレクトリだけを渡します。

services:
  hermes:
    image: nousresearch/hermes-agent:<固定したバージョン>
    restart: unless-stopped
    command: ["gateway", "run"]
    volumes:
      - /home/example/.hermes:/opt/data
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL

InstagramとThreadsのトークンは、リポジトリ外のファイルとして保存します。

~/.hermes/credentials/instagram-access-token
~/.hermes/credentials/threads-access-token

権限は600とし、投稿ワーカーはファイルを読むだけです。トークンをコマンド引数、キュー、監査ログへ入れないようにしました。

投稿ワーカーの状態管理

投稿ワーカーは、1回の投稿をJSONキューとして保存します。主な状態は次のとおりです。

awaiting_approval
        ↓
     approved
        ↓
    publishing
        ↓
     published

失敗時: failed / needs_review

本文、記事URL、画像URL、記事更新日、記事MarkdownのSHA-256を承認対象に含めます。承認後に記事や本文が変わった場合、ハッシュが一致しないため投稿を止めます。

def approval_hash(record: dict) -> str:
    payload = json.dumps(
        approval_payload(record),
        ensure_ascii=False,
        sort_keys=True,
        separators=(",", ":"),
    )
    return hashlib.sha256(payload.encode()).hexdigest()

自動運転へ移行する前には、DiscordからキューIDを指定して承認する試験期間を設けました。InstagramとThreadsの両方で実投稿を確認してから、自動運転専用の承認主体を追加しています。

投稿候補は公開済みMarkdownから選ぶ

ねこ宿研究所では、WordPress記事の正本をMarkdownで管理しています。自動投稿では、フロントマターが次の条件を満たす記事だけを候補にします。

status: publish
slugが記事URLと一致する
title、description、fact_checkedがある
同じプラットフォームで直近60日に使っていない
公開URLがHTTP 200を返す

Instagramでは、さらにサイトのWordPressメディアにあるJPEG画像を必要条件にしました。

image_pattern = re.compile(
    r"!\[([^]]+)\]\((https://www\.example\.com/"
    r"wp-content/uploads/[^)]+\.(?:jpg|jpeg))\)",
    re.IGNORECASE,
)

外部サイトや予約サイトの画像は取得しません。記事内画像がWebPしかない場合は、その記事をInstagram候補から外すか、WordPress側にJPEG派生版を用意します。

また、Markdown上では公開扱いでも、WordPress側のURLがまだ存在しないケースがありました。候補決定前に記事URLと画像URLへHEADリクエストを送り、到達不能な候補はスキップします。

def first_reachable(platform: str, candidates: list[dict]) -> dict:
    for item in candidates:
        if not public_url_ok(item["url"]):
            continue
        if platform == "instagram" and not public_url_ok(
            item["image_url"], "image/jpeg"
        ):
            continue
        return item
    raise AutomationError("No unused article with reachable public URLs")

InstagramとThreadsの文章を分ける

同じ記事を紹介する場合でも、両プラットフォームへ同一文面を同時投稿しないようにしました。

Threadsは記事URLを本文へ含め、時間帯ごとに役割を分けています。

08:00  ねこ宿小ネタ
11:30  今日のねこ宿
15:00  猫・旅行ネタ
19:00  新着記事・宿紹介
22:00  軽い雑談・質問

Instagramはサイト内JPEG画像と代替テキストを付け、1日2回投稿します。

11:30  ねこ宿紹介
20:00  写真・記事・看板猫紹介

宿紹介では、猫に必ず会えるような表現を避けるため、次の趣旨を必ず入れます。

猫との時間は、猫の意思やその日の体調を尊重してお楽しみください。

禁止表現や文字数は投稿ワーカーでも検査します。プロンプトだけで守るのではなく、コード側でも止めるのがポイントです。

Meta APIでの投稿

Instagramは、画像コンテナを作成し、処理完了を確認してから公開します。

アカウント確認
  ↓
メディアコンテナ作成
  ↓
status_codeがFINISHEDになるまで確認
  ↓
media_publish
  ↓
投稿IDとpermalinkを取得

Threadsも、テキストコンテナを作成してから公開します。どちらも投稿前にAPIが返すユーザー名を検査し、想定したアカウントでなければ停止します。

最も注意したのはネットワークタイムアウトです。公開APIの呼び出し後に通信が切れると、「投稿に失敗した」のか「投稿は成功したが応答を受け取れなかった」のか判断できません。

この場合は自動再投稿せず、キューをneeds_reviewにして対象プラットフォームを一時停止します。

except TimeoutError:
    record["status"] = "needs_review"
    state["paused"][record["platform"]] = True
    save_record(record)

Discordへ完了通知する

投稿成功後は、Discord Bot APIで非公開の運用チャンネルへ通知します。

✅ threadsへ自動投稿しました（th-travel）。
記事: 記事タイトル
キュー: TH-...
https://www.threads.com/...

Discordのメッセージには、キューIDをもとに作った数値nonceを付けています。通知処理を再実行した場合でも、同じ完了通知が重複しにくくするためです。

重要なのは、投稿成功後のDiscord通知失敗を「投稿失敗」と同一視しないことです。キューがすでにpublishedなら、通知の再試行はしても、SNS投稿は再実行しません。

cron失敗時の再試行をどう設計したか

運用開始後、「cronが失敗したら原因を確認して再投稿し、3回失敗したら諦める」機能を追加しました。

単純にコマンド全体を3回実行するのは危険です。1回目で投稿済みなのに応答だけ失われた場合、同じ内容を3回投稿する可能性があります。

そこで、各試行の前後でキューディレクトリを比較します。

新しいキューがない
  → 投稿処理へ入る前の失敗。最大3回まで再試行可能

新しいキューがpublished
  → SNS投稿は成功。再投稿しない

新しいキューがpublishing / failed / needs_review
  → Metaへ到達した可能性がある。停止して人が確認

プラットフォームがpaused
  → 再試行しない

ラッパーの骨格は次のようになりました。

for (( attempt=1; attempt<=3; attempt++ )); do
    before=$(snapshot_queue)

    if python3 social_automation.py "$platform" "$slot"; then
        exit 0
    fi

    decision=$(retry_decision "$before")
    case "$decision" in
        published:*) exit 0 ;;
        retry:*)     sleep 30 ;;
        *)           exit 1 ;;
    esac
done

「失敗したら再試行」ではなく、「外部へ副作用が発生していないと確認できる場合だけ再試行」と考える必要がありました。

実際に起きた障害：再試行機能を追加したらcronが全停止

再試行機能の追加はHermes AgentへDiscordから依頼しました。ロジック自体は安全側に作られていましたが、更新後のシェルスクリプトが600になり、実行権限が消えていました。

cronログには次のエラーが残っていました。

flock: failed to execute run_social_automation.sh: Permission denied

原因は単純ですが、Pythonの構文検査だけでは検出できません。修正後は、配備処理とスキルの運用手順へ次の確認を追加しました。

chmod 700 run_social_automation.sh
bash -n run_social_automation.sh
stat -c "%a %n" run_social_automation.sh

さらに、投稿を伴わない/bin/falseを自動処理の代わりに指定し、正確に3回で終了するテストも行いました。

status=1 attempts=3 gave_up=1

最後に実際のThreads投稿を1件実行し、キューがpublishedになったこと、Discord通知が届いたこと、連続失敗数が0へ戻ったことまで確認しました。

運用して分かったこと

1. AIエージェントと副作用のある処理を分ける

Hermes Agentは、調査、運用指示、スキル改善の窓口として便利です。一方、SNS投稿のように取り消しにくい処理は、引数と許可範囲を狭くしたワーカーへ閉じ込めた方が安全でした。

2. 再試行回数より「再試行してよい状態」の定義が重要

最大3回という数字だけでは二重投稿を防げません。外部APIへ到達する前か、到達した可能性があるかを、永続化した状態から判断する必要があります。

3. 投稿後通知は投稿処理と別の副作用

Discord通知が失敗しても、SNS投稿まで巻き戻ったわけではありません。工程ごとに成功状態を分けることで、安全に復旧できます。

4. AIによる改修でもUnixの基本確認は必要

コード差分、構文、テストに加えて、実行権限、cronサービス、実行ユーザー、ログの保存先まで確認する必要があります。今回の障害はchmodとstatで防げるものでした。

5. 完全自動化でも停止手段を残す

Instagram、Threads、全体を個別に停止できるフラグを用意しました。曖昧なAPI結果や連続失敗時は自動停止し、再開だけは明示的な運用指示を必要とします。

まとめ

Hermes Agentを使って、記事選定、Instagram・Threads投稿、Discord通知、cron運転までを一つの運用フローにまとめました。

実装で特に重要だったのは、AIに自由に投稿させることではなく、次の境界をコードで作ることでした。

投稿できるアカウント、URL、画像形式を限定する
投稿内容と記事ソースをハッシュで固定する
状態を永続化して二重投稿を防ぐ
結果が曖昧なら再試行せず停止する
外部副作用の前だけ最大3回再試行する
投稿結果をDiscordへ通知する
スクリプトの実行権限まで配備後に検査する

AIエージェントによる自動化は、自由度を高くするほど便利になるとは限りません。外部へ書き込む部分を小さく、決定的に、止めやすくすることで、ようやく日常運用へ載せられると感じました。

本システムを運用している「ねこ宿研究所」は、看板猫のいる宿を調査・紹介するサイトです。本記事の構成は、そこで実際に公開している記事とSNS運用を対象に検証しました。

参考