Contents
はじめに：Threads投稿Botを軽く試してみたら…
最近、Threadsが日本でもじわじわと存在感を増しています。投稿APIも用意されているということで、簡単な自動投稿Botでも試してみようと思い、実際に手を動かしてみました。
ところが、実装してみると「えっ、なんでこんなに面倒なの？」という違和感の連続。
X APIの方が遥かに楽です。
今回は、その“面倒さ”の正体を掘り下げていく中で気づいた、Meta側の設計思想のようなものについて書いてみたいと思います。
やたら面倒な認証フロー
まず、Threadsの投稿APIを使うためには、Meta for Developers上でアプリを作成し、Instagram Graph APIを有効化しなければなりません。そのうえで、投稿したいアカウントを「テスター」として登録し、アクセストークンを取得する必要があります。
この時点でもう、想像よりも手間がかかります。そして、さらに厄介なのがアクセストークンの有効期限です。
MetaのGraph APIで取得できるアクセストークンには、大きく分けて「短期トークン（約1〜2時間）」と「長期トークン（最大60日）」があります。後者を使えばある程度の継続利用が可能ですが、それでも60日を過ぎると再認証が必要になります。しかも、トークンのリフレッシュは自動ではできません。
つまり、完全な自動運用はできない設計になっているわけです。
「なんでこんな不便なんだ？」という疑問
投稿Bot程度であれば、もっと手軽に作れてもいいはず。ところが、実際にはアカウントごとにアクセストークンを発行・管理しなければならず、しかも毎回ユーザーの手動認証が必要。
たとえば、複数アカウント（いわゆる“複垢”）でBotを回そうとすると、それぞれのアカウントで認証を通し、トークンを取得し、管理し、定期的に更新する必要があります。さらに開発モードのままでは使えるアカウントも制限されており、本番環境への移行には審査も必要。
この時点で、「これは偶然の面倒くささじゃないな」と直感しました。
偶然ではなく“意図的な構造”なのでは？
ちょうどその頃、とあるクラウドソーシングサイトで見かけた案件がありました。
複数のThreadsアカウントに対して、グループごとに投稿をリポストするBotの開発。報酬：5,000円
一見シンプルな依頼に見えますが、自分で試してみた身としては「いやいや、無理無理」と即座に反応してしまいました。
なぜなら、複数アカウント分のトークンを手動で発行して、それらを管理し、期限切れ前に再認証まで見てあげる必要があるからです。単に「投稿するだけ」では済まず、人間が定期的に介在する運用フローを前提にしなければならない。
ここでようやく、「Metaはあえてこういう構造にしてるのでは？」という考えが浮かびました。
MetaはBotを“技術で制限”するのではなく“コストで潰す”
MetaのAPI設計を見ていると、「スパムBotを技術的に完全に封じ込める」のではなく、
- 人間の手を介在させる必要のある認証フロー
- 自動化できないトークン更新
- 複数アカウント管理の煩雑さ
といった形で、心理的・実務的な“めんどくささ”を積み上げていくことで、Bot開発の取引コストを吊り上げているように思えます。
結果として、
- 個人が自分用に軽く作る分には何とかなる
- でも、他人に代わって運用するBot（＝商用・代行・請負）は現実的に割に合わない（高額になって価値と代金が釣り合い難い）
という境界線を意図的に設計しているのではないかと感じました。
アクセストークンの有効期限について補足
Metaのアクセストークンには「短期（約1〜2時間）」と「長期（最大60日）」の2種類があります。
本記事では、長期トークン（long-lived token）＝60日間有効であることを前提としていますが、
将来的に仕様が変更される可能性もあるため、最新の有効期限はMeta公式のトークンデバッガなどで確認することをおすすめします。
まとめ：やってみたからこそ見えた、Metaの設計の“意図”
Threadsの投稿自動化は、技術的には可能です。ただし、運用まで視野に入れると一気にハードルが上がります。特に、複数アカウントを横断するようなBotを作ろうとすると、**単純なスクリプト以上の“人間的手間”**が必要になる設計になっています。
こうした構造は、おそらくMeta側が意図して作った「自動化しにくいAPI設計」であり、Bot対策の一環と考えれば非常によくできているとも言えます。
手軽にBotを作るつもりが、いつの間にかMetaの設計思想と向き合うことになった──そんな体験でした。
コメント