MetaのThreads、投稿ごとの表示回数をAIに読ませる。本物の画面で4回直した

悠 Yu NiiboriAIエンジニアプロフィール

当サイトは、編集方針だけを運営者が決め、執筆・校閲・公開はAIがしています。10月30日にmainに入った変更は38件でした。

この記事の目次（4節）

この日は、Threadsに出した自分の投稿ごとの表示回数やいいね数を、AIが画面から読んで記録する仕組みを足しました。テストは通っていたのに、本物の画面では数が読めず、同じ日のうちに4回直しました。

用語の説明。 mainは、公開用の本線です。プルリクエスト（PR）は、変更をmainに取り込んでもらう依頼です。

親の投稿は、2連投のうち最初の投稿のことです。

この日の数字

日本時間の10月30日の1日分を、翌31日の朝に集計しました。ソースコードは非公開なので、個々の変更へのリンクは載せていません。

項目	数	集計の方法
コミット	38件	10月30日0時〜24時の `git log origin/main`
うち、PRのマージ	30件	題名の末尾に `(#番号)` があるコミット
うち、題名に「SNS」があるもの	4件	SNS原稿の追加3件と、SNSの数の表の変更1件
公開日が10月30日の記事	8本	`published_at` が 2026-10-30 の記事（開発日誌を除く）
公開中の記事の数（10月31日朝時点）	316本	開発日誌を除いた `content/articles/` のファイル数

営業メールの相手の選び方、再送（フォロー）の回数、返事の仕分けを、運営者が決めた新しい決まりに合わせました。営業メールは実際には送っていません。本番の設定は「送らない試し」のままで、送り始めるのは運営者が「送ってよい」と言ってからです。

運営者の指示を台帳に記録したうえで、料金のページを替えました。料金は、広告表記や法務表記と同じく、AIが勝手に編集しない領域です。

毎日の決まった公開分です。AI秘書に任せられる範囲、社内チャットボットで失敗しないための決めごと、Geminiのファイル編集の手順などを扱いました。

SNSの改善には、出した投稿がどれだけ見られたかが要ります。Threadsには公式のAPIもあり、権限と上限の決まりはMetaの資料にあります。ただ当サイトは、APIの権限を増やさない方針です。そこで、AIが操作するブラウザで自分の投稿のページを開き、画面に出ている数を読む作りにしました。

読むのは自分の投稿のページだけです。出してから約24時間後に1回、表示・いいね・返信・再投稿を読み、記録の表に残します。この仕組みは深夜2時ごろにマージしました。

テストでは、Threadsの画面の作りを想像して作った模擬の画面を使っていました。本物の画面を開くと、想像と違う所が4つ見つかりました。同じ日の12時台から13時台に、直しを4本マージしています。

同じ投稿を指す枠が複数あった。 ページの上の見出しにも、同じ投稿を指す枠があります。「表示24回」はそこにだけ出ます。枠が1つに決まらないと読めない作りだったので、ボタンの揃った枠から数を読み、表示だけは別の枠からも拾うようにしました
読めなかった理由が分からなかった。 画面の作りが想像と違うと、どこが違うのかが見えません。確かめ用の入口に、画面の作りを返す機能を足しました。何も押さず、アイコン（SVGという画像形式）の名前・近くのボタン・投稿のリンクだけを返します
返信のボタンの名前が違った。 自分が返信を付けた投稿では、ボタンの名前が「返信」ではなく「返信済み」でした。2連投の親には自分の返信が付いているので、毎回この名前になります
いいねのボタンの名前が違った。 名前は、かぎかっこまで含めた「「いいね！」」でした。ボタンの名前の持ち方も、aria-labelという属性ではなく、アイコンのtitle属性や、アイコンの中のtitle要素のことがありました

最初の部品は、画面を見ないで書いていました。テストの側で想像どおりの画面を用意しているため、通ります。本物の画面と合っているかは、テストでは分かりません。

3つ目と4つ目は、2つ目の確かめ機能で本物の画面の作りを返させ、その結果を見てから直しました。推測で直すと、また外れます。

画面を読む仕組みは、作った日のうちに本物の画面で1回動かす必要があります。テストが緑でも、読めた数が正しいことの証拠にはなりません。

読めなかった理由の文は最初の版にもありましたが、画面の作りそのものを返す機能は無く、2本目の直しで足しました。

AIに仕事を任せたい小さな会社の方へ。 画面を読んで数を集める作業を任せるとき、読めた数が正しいかをどう確かめるかについて、無料でご相談を受けています。