0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Reddit MCPをChatGPTから投稿まで通すまでに詰まったポイントまとめ

0
Posted at

Reddit MCPをChatGPTから実投稿まで通し、4画像投稿とContent Publisher統合まで一気に進めた。

実装そのものより時間を使ったのは、preview→approval→publishの境界だった。忘れないうちに、今日ハマったところを残しておく。

APPROVAL_STALEなのにRedditの投稿画面は見えている

最初に一番時間を使ったのがこれ。

preview自体は成功しているのに、publishすると次のような状態になる。

APPROVAL_STALE: exact Reddit target is no longer visible

ところが、実際のReddit画面を見ると投稿フォームは普通に残っている。

原因はpreview時に保持していた対象の取り方だった。

const scope = page.locator("main");

modern Redditではmainが複数存在することがあり、後段のLocator.isVisible()でstrictnessに引っかかる。フォームが消えたわけではないのに、承認チェック側では「対象が見えない」と判定されていた。

create post時点ですでに一意に解決できているtitleFieldを使う形に変更した。

const scope = titleField;

画像の存在確認は別のmediaScopeで行っているので、targetScopeを広いmainにしておく必要もなかった。

この修正後、同じpreview→publishが通るようになった。

preview digestは永久に使える承認票ではない

古いdraftを使い回していると、previewのTTL切れでもAPPROVAL_STALEになる。

Reddit側では、publish対象を単なる本文ハッシュではなく、その時点のlive composerまで含めたpreviewとして扱っている。なので期限切れのdigestを無理に再利用しない。

prepare
  ↓
preview
  ↓
previewDigest
  ↓
publish

publishに失敗したら、原因を直した後にfresh previewを作り直す。この方が状態も追いやすかった。

画像は存在していてもstate directoryが違うと拒否される

4画像投稿を試したとき、ファイル自体は存在するのに次のエラーになった。

REDDIT_MEDIA_FORBIDDEN

Reddit adapterは任意のローカルファイルをアップロードできないようにしていて、publisherの保護ディレクトリ配下だけを許可している。

ここでCLI側と常駐daemon側のPUBLISHER_STATE_DIRが違っていた。結果として、CLIから見ると正しい画像でもdaemonから見ると「許可されたmedia directoryではない」扱いになる。

Windowsでは常駐側と同じstate directoryを使うように揃えた。

%LOCALAPPDATA%\reddit-mcp

ブラウザ投稿系でローカルファイルを扱うなら、パスだけではなく「どのruntimeが所有するファイルか」まで揃える必要がある。

CLI approvalをpipeで自動化しようとしてもTTYで止まる

CLIのapproveは意図的にinteractive TTYを要求する実装になっていた。

つまり、標準入力に承認文字列をpipeして自動化する経路では通らない。

ここを無理に迂回するより、ChatGPTからの明示的な承認はMCP/Actions側の専用経路で扱う方が自然だった。

最終的には、Reddit側にcontent-publisherを正式なtrusted callerとして追加し、Content Publisherからpreview digestを指定してpublishする形にした。

gpt-actionを偽装して呼ぶような実装にはしていない。

WindowsのScheduled Taskを再起動しても古いNodeが残ることがある

Content Publisher側を更新した後、Scheduled Taskを再起動したのに新しいツールが見えないことがあった。

調べるとタスク本体は停止しているのに、子のNodeプロセスが8789番ポートを握ったまま残っていた。

この状態だと、タスクを再起動したつもりでもアクセスしているのは旧serverのまま。

確認するときはTask SchedulerのStateだけではなく、実際のport ownerも見る。

Get-NetTCPConnection -LocalPort 8789

古い子プロセスを落としてから起動し直すと、新しいtools/listに切り替わった。

MCPサーバーが更新されても、古いChatGPT会話はtool schemaを持ち続ける

ローカルのContent Publisherは14ツールを返しているのに、作業中のChatGPT会話では旧6ツールのまま、という状態も起きた。

サーバーやSecure Tunnelが壊れているわけではない。publisher_healthを呼ぶと新しいReddit adapter自体は見えていた。

新しい会話でプラグインを読み直すと14ツールを正常に取得できた。

MCPのtool schemaを変更した直後は、server側のtools/listだけでなくChatGPT側の再ロードまで確認した方がいい。

最終的な構成

Redditを独立MCPとしてChatGPTに直接ぶら下げる構成から、Content Publisherを表玄関にする形へ変更した。

ChatGPT
  ↓
Content Publisher MCP
  ↓
RedditAdapter
  ↓
Windows Named Pipe RPC
  ↓
Reddit Agent Publisher
  ↓
Playwright / Chrome
  ↓
Reddit

Reddit専用のHTTP MCPをもう1段挟む必要はなかった。通常運用では8789のContent PublisherだけをChatGPTに公開し、Reddit daemonはローカル実行エンジンとして残している。

最後に実際のr/testへ投稿し、同じdraftをもう一度publishしてもalreadyPublished: trueとなり、二重投稿されないところまで確認した。

テストもReddit Agent Publisher側46件、Content Publisher側30件が通っている。

ブラウザ自動化は「Postボタンを押せた」で終わらせると怖い。previewの対象、承認の寿命、再試行時の重複防止、投稿後のread-backまで揃って、やっと投稿ワークフローとして使える感じになった。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?