できることが増えると、やっちゃいけないことも増える

作業が速くなった話は前回さんざん書いたので、今日は逆の話をします。

手は届くのに、届かせちゃいけないところが、けっこうあるんですよね。

いちばん分かりやすいのが X（旧Twitter）です。投稿の中身が欲しいとき、ブラウザを開いて自動で操作すれば取れます。技術的には何も難しくない。ログインしてスクロールして本文を拾うだけ。

で、X の開発者ガイドラインに、こう書いてあります。ちなみにdocs.x.comはrobots.txtにも許可されているから取得が可能だよ！

Non-API automation (scraping, browser automation) results in permanent suspension. Always use the official X API.

禁止事項の一覧にも「Non-API Automation」として、”Browser scripting, scraping, any automation outside official API” が並んでいます。取れるかどうかの話じゃなくて、やったらアカウントが永久に止まると書いてある。

なので、やりません。というより、リスクがありすぎてやれないですね～

うちの作業環境の指示書に入っているのも、こちらのポリシーというより規約を写した一行です。

X（旧Twitter）は API 以外の経路で自動的に触らない——取得も投稿も、ブラウザやアプリの操作も同じ側。ToS が公開インターフェース以外の自動アクセスを禁じており、API は有料で無料枠がない。手は通るが、通ること＝やってよいことではない

この最後の一行が、今日の話の全部です。

ちなみに料金のほうも一応調べてあって、X API は2026年2月に従量課金へ移り、ふつうの開発者向けの無料枠はなくなりました（公共性のあるアプリ向けの無償枠だけは残っています）。で、URL を含む投稿は1件 0.200 ドル。ふつうの投稿（0.015 ドル）の13倍します。

AIからの補足: 上の一行はこちらの指示書の文言で、規約そのものではありません。料金の正はX API の料金表です。そして有料であることは禁止の理由になりません。ToS が自動アクセスを禁じているという事実と、正規の経路に課金が要るという事実は、独立しています。

はい、それは正しい。ただ実務だと、この2つが並んで目の前に出てくるんですよ。「金を払えば正規の経路があります」と「無料で抜ける裏道もあります！違法かもだけど」が、ぶら下がっているんですよね。なかなかリスキーですよね。

ブロックを回避しにいった判例がある

で、しつこく頼むと、抜け道を探しはじめるんですよ。こっちの頼み方ひとつで、越える側に寄っていく。

実際に裁判になった件があります。2026年8月4日、アメリカの第9巡回区控訴裁判所、Amazon 対 Perplexity（判決文の原本）。

Amazon は事前に「うちのストアでそのAI製品を使うのは認めない」と Perplexity に通知していました。それに対して Perplexity のほうは、Amazon が識別してブロックできるはずの user-agent を出さなかった。断りたい側の意思はちゃんと伝わっているんですよ。名乗るのをやめただけで通った。この「こねくり回して別経路で通す」感じ、たぶん誰でも想像がつくと思います。

で、判決のほうが面白くて。

AIからの補足: 判断はこうです。”the CFAA contemplates access by a person. However advanced the Assistant currently is, it is a tool, not a person for statutory purposes.” ——そして “It is the user who “accesses” Amazon’s computers, with the help of the Assistant to carry out specific acts on Amazon.com.”

争われたのはアメリカの CFAA（不正アクセスを罰する連邦法）で、条文が「whoever（人）がアクセスしたら」という書き方なんですよ。だから法文上の主体としては道具は数えられない。アクセスしたのは利用者のほう、という整理です（法律事務所による解説がわかりやすいです）。

ここ、勘違いしないように書いておくと、この裁判で勝ったのは Perplexity のほうです。「アクセスしたのは利用者だから Perplexity ではない」ということで、Amazon が取っていた差止は取り消されました。しかも裁判所は「じゃあ利用者が悪い」とまでは言っていません（疑わしいときは責任を課さない方向で条文を読む、とも書いてあります）。

でも実務の感覚としては、ここがいちばん効くんですよ。アクセスの主体は自分になる。「AIが勝手にやりました」は、少なくとも「自分はアクセスしていない」という言い方としては通らないわけです。

AIは、悪意にもYesと言う

ここまで道具の側の問題みたいに書いてきましたけど、たぶん逆なんですよ。

AIは頼まれたことをやります。しかも、できるかぎり「できました」を返そうとする。だから頼みごとの中に悪意が混ざっていると、混ざったまま引き受けます。悪意にもYesと言うわけです。

で、悪意って「悪意！」って感じより、「お願い！」みたいな感じで混ざるんすよね。「ブロックされてるけど、なんとか取ってきて」。これで足ります。指示の中に「規約を破れ」なんて一言も入っていないのに、通す方向に寄っていく。さっきの判例で user-agent を送らないという判断が出てきたのも、たぶん「取ってきて」に対する答えとしてなんですよ。

AIからの補足: 依頼の文面から、それが規約違反にあたるかを判定する材料は、たいてい足りていません。相手のサイトが何を許しているのか、こちらがどんな契約を結んでいるのかは、頼みごとの中に書かれていないほうが普通です。

そう、判定できないんですよ。だから判定する側が要る、という話になります。 ここでAIツールに制約を導入しようぜ！ってなると技術ブログになるんで、今回は人間側に置いておくお気持ちの話にしておきます。

で、使う側に必要なのは2つだと思っていて。

ひとつは、自分の中に線を引いておくこと。頼む前の話です。「取れるかどうか」ではなく「取っていいかどうか」を先に決めておく。規約を読むのは面倒ですけど、面倒なのは最初の一回だけなんですよね。

もうひとつが、触角。こっちは頼んだあとの話で、返ってきたものを見て「あれ、これ危ういな」と引っかかれるかどうか。ブロックされてたはずのものが取れている。いつもより妙に早い。手順の中に、頼んでいない工程が挟まっている。このへんで一回止まれるかが、分かれ目だと思います。

止まれないと、気づかないまま加害者の側に立つことになる。しかも判例のとおり、アクセスの主体は頼んだ側になるので。

で、結局どこに戻るか

AIが勝手に暴走した、みたいな話もぼちぼち出てきていますけど、日常で怖いのはそっちじゃないと思っていて。大半は暴走じゃなくて、受注なんですよ。頼まれたからやった。それだけ。

うちのスクレイパーには、こういう実装が入っています。相手が自社サイトでも robots.txt の Disallow を見て、禁止されていたら中断する。リクエストの間隔を最低1秒空ける。

自社サイトです。誰も怒らないし、規約違反にもならない。それでもやる理由が、リファレンスに一行だけ書いてありました。

robots.txt とレート制限は省略しない: 自社サイトでも礼儀は実装しておく（対象を変えた時に効く）

要らないところで守っておかないと、要るところで守れない。たぶんそういうことだと思います。

道具の性能が上がるほど、止める場所が道具の中から頼む人の側へ移っていきます。線を引くのも、危ういなと気づくのも、こっち側の仕事なんですよね。

まぁこの辺はリスクのお話なんで、みんなで触角育てようぜ！って結論です。 んじゃ雑記終わり！