AIはおま環がわからない：WordPressで毎日全記事の更新をしたら記事IDが爆増した事件簿と迷探偵AI

2025年9月28日

とてもニッチな話。うちのサイトはWordPress製でテーマとしてはSWELLという有名なテーマを使っている。SWELLは簡易的なPVカウント機能があるのだけれど、dailyやweeklyの差分は自分で計算する必要がある。

で、せっかくカウンタがあるんだから活用しようかなと思って、最近全記事のPVのスナップショットをとるようにしたのさ。で、そこからdaily, weekly, monthlyの差分を計算するバッチ処理を書いた。計算しただけでは甲斐がないので、計算した結果を全記事のカスタムフィールド（自分で定義できる変数欄みたいなの）にセットするようにした……ところ、毎日記事IDが3000ずつ増えるようになった🥺

原因はActivityPubプラグインをよく知らずに適当に入れていたことだった。これによりデータベースに10万件以上のゴミIDが出来ていた。おま環故に、これがわかるまでけっこう苦労した。また完全なるおま環であったためか、AIに相談したらパニックの極みであり、ジャイアントスイングをされた。

事の顛末

毎日差分をセットするようになってから3000ずつ増えるようになったため、これは明らかにそれが原因だ、というのはわかっていた。記事数は1000で、daily, weekly, monthlyで界王拳三倍。計算も合う。

原因はわかるが、どうしてそうなるのかは理解できない。カスタムフィールドの更新をするだけで記事IDが増えるのは明らかに奇妙な挙動だ。LLMに相談したが、LLMも混乱しているのか、PUTではなくPOSTをつかってましたとか（確かにPUTのほうがいいので修正したがそこではない）、カスタムフィールドの更新で register_rest_fieldを使っているのは行儀が悪いので register_metaを使いましょうとか（これもその通りではあるので修正したがやはり関係ない）毎日記事を取得しているのが原因ですなど、何も問題がないところを「問題を発見しました！」と嬉々として報告してきて無能。

最終的に、初心にかえってコンテナにアクセスし、データベースの状況を調べたところ、以下のような大量のUPDATEログがIDを使っていたことが判明した。

| 44700 | [Update] 2021年… | 2025-09-26 00:21:17 | publish     | ap_outbox  |
| 44699 | [Update] macOS… | 2025-09-26 00:21:17 | publish     | ap_outbox  |
...

| 44700 | [Update] 2021年… | 2025-09-26 00:21:17 | publish     | ap_outbox  |
| 44699 | [Update] macOS… | 2025-09-26 00:21:17 | publish     | ap_outbox  |
...

oh……。

ap_outboxってなんぞ……と思ったら、ActivityPubプラグインだった。これがわかると、無能だったLLMが突如として活き活きして「完全にそれです。更新がトリガとなって通知でIDを消費しているのでしょう。Q.E.D.」と。

ActivityPubプラグインというのは、WordPressのFediverseに接続するためのプラグインなのだが、性質上デフォルト設定では更新を検知するとこういう挙動になるらしい。カスタムフィールドの更新はWordPress的には更新なので、こういうことになってしまったわけだ。

元よりノリで入れていただけのプラグインだったので、設定をちゃんとすれば問題なくなる可能性はあったが、面倒臭くなってプラグインを停止した。停止すると、記事ID爆増はおさまったので、やはりこれが原因であったらしい。ちなみにメタIDはさらに酷いことになっていた。データベースから削除した時のログがこれ。

MariaDB [hackle_db]> DELETE pm
    -> FROM wp_postmeta pm
    -> LEFT JOIN wp_posts p ON p.ID = pm.post_id
    -> WHERE p.post_type = 'ap_outbox';
Query OK, 77470 rows affected (2.394 sec)

MariaDB [hackle_db]> DELETE FROM wp_posts
    -> WHERE post_type = 'ap_outbox';
Query OK, 25799 rows affected (57.199 sec)

MariaDB [hackle_db]> DELETE pm
    -> FROM wp_postmeta pm
    -> LEFT JOIN wp_posts p ON p.ID = pm.post_id
    -> WHERE p.post_type = 'ap_outbox';
Query OK, 77470 rows affected (2.394 sec)

MariaDB [hackle_db]> DELETE FROM wp_posts
    -> WHERE post_type = 'ap_outbox';
Query OK, 25799 rows affected (57.199 sec)

77470件……。そんなに……。

AIは問題は解けるが問題文は作れない

反省点としては、まずよくわからないことをするもんじゃあないよという当たり前の話である。また、LLMの得意不得意の境界線がハッキリ出たシーンでもあった。

WordPress + ActivityPubプラグイン導入
全記事のカスタムフィールドを毎日更新

これら特殊な状況が組み合わさった結果、AIは完全なる無能と化した。

しかしap_outboxなるものが大量にIDを消費している、というデータベースの状況を提出したところ、一気に覚醒してたちまち適切な判断を下せるようになった。

これはつまり、AIは与えられた解けるが、現実世界において問題と思われるものはしばしば問題文の体裁にいたっていないことが多く、その状態では無力だ、ということを示している。

今回の事例で言えば、AIにとって問題設定は「WordPress REST APIでカスタムフィールドを更新すると、カスタムフィールドのIDが変に増加する」だったが、実際には「WordPress REST APIで投稿を更新すると、ActivityPubプラグインがフックし、ap_outboxという投稿タイプを大量に新規作成したため、wp_postsのIDが異常に増加する」である。

まぁわかってみればそりゃそうだ、ではあるのだけれど、現実に起きる問題とは、今回のように固有の環境が起因していたり、大きな影響を与えていることは少なくない。AIのベンチマークが必ずしもアテにならない原因の一端ではあろう。

これについて、AIがローカルの知識をすべてもっていれば解決できる！と思う向きもあるかもしれないが、一体誰がどうやって「すべてのローカル知識」とやらを用意し、そしてそれをAIが適切に利用できる形にするというのか。そもそも僕らはすべてのローカル知識があるから問題がわかるのだろうか？少なくとも僕はデータベースを見るまでActivityPubプラグインが原因とは思いもしなかった。

恐らく必要なことは、「問題文がそもそも大きく間違えているのではないか？」という疑いをもち、問題文自体を作成するための支援ができることだと思うが、恐らくそのような挙動を許すと、今度は「合っているのに間違っている」と他責に走る偽陰性のようなものが許し難いほど高まるように思える。

問題を設定することの困難さはいわゆるフレーム問題の枠組みなんだろうが、なぜこれを人間が出来るのかと考えたとき、それは責任のように思える。問題をこのように設定する、というのは、論理的判断というより、責任なのではなかろうか。死なないAIは原理的に責任が持てない。

となると、この問題は原理的に人間の領域、ということになるのかもしれないなぁ、などということを、最近はAI記事に負けている我がブログのPVを見つつ思うのであった。