この記事の結論(先に3つだけ)
Blogger にメールで記事を送ると、本文のリンクが google.com/url という別のアドレスに包まれていました。公開ずみ6記事で41本、1本残らずです。Blogger API という「ブログを外から操作する正式な窓口」へ投稿の経路を移したら、48本のリンクが1本も包まれずに入りました。かかったのは9月7日から11日までの5日間で、支払いは0円です。
- メール投稿では、リンクが全部包まれていました。 Amazon の紹介リンクも、出典のリンクも例外なしです
- Blogger API に移すと、包まれず、ラベルも自動で付きました。 私の手作業が1つ減りました
- いちばん時間を食ったのは、技術ではありません。 AIが自分で作った「待ち」で、1往復ぶん止まっていました
50代・非エンジニアです。プログラミングはできません。
第3回から第8回までは、AIの作業環境を整える話でした。第8回の CLAUDE.md とは何か では、AIにルールを守らせる置き場所の話を書いています。
今回からは、その環境で実際に事業を回し始めてからの話です。
私は Blogger(Google の無料ブログサービス)で3つのブログを持っています。都市伝説、ハンターハンターの考察、AI副業の3つです。記事はAIが書き、Blogger のメール投稿という機能で送っていました。決められたアドレスにメールを送ると、その中身が記事の下書きになる仕組みです。
楽でした。ところが、そこに穴がありました。
Blogger のメール投稿で、リンクが全部「包まれて」いた
2026年9月7日、送った記事のリンクが、元のアドレスのまま入っていないことが分かりました。 本来は https://www.amazon.co.jp/dp/… と入るはずのリンクが、https://www.google.com/url?q=…&source=gmail… という形に変わっていたのです。中のアドレスごと、Google のアドレスにくるまれていました。
見つけたのは、Mac で動いているAIです。Chrome を操作して、Blogger の編集画面と公開ページの両方を開き、リンクの中身を1本ずつ読みました。
結果は次のとおりでした。
| ブログ | 記事 | 包まれていたリンク |
|---|---|---|
| 都市伝説 | エリア51の記事 | 10本すべて |
| 都市伝説 | ナスカの地上絵の記事 | 9本すべて |
| ハンターハンター | 念能力の一覧の記事 | 7本すべて |
| ハンターハンター | クラピカとクロロの記事 | 6本すべて |
| AI副業 | ChatGPT のカスタム指示の記事 | 4本すべて |
| AI副業 | AI副業で稼げない理由の記事 | 5本すべて |
合計41本。1本の例外もありませんでした。
さらにもう1つ。AIへの依頼文は「下書きを見てほしい」というものです。ところが、6本とも公開ずみでした。包まれたリンクが、読者の踏める状態で外に出ていたことになります。
クラウドで動いている別のAIも、公開ページを自分で読み直して数え直しました。数字は同じ41本でした。2台のAIが別々に数えて、一致したので、ここは確定としました。
包まれたリンクの何が困るのか
困るのは、Amazon の紹介リンクです。 41本のうち3本が紹介リンクでした。包まれたリンクでも、クリックすれば Amazon のページには着きます。ただ、その途中に Google のアドレスを1回通ることになります。
Amazon アソシエイトの規約には、「仲介するサイトを経由したリンクは紹介料の対象外」という趣旨の決まりがあります。Google のクリック計測がその「仲介」に当たるのかどうかは、条文からは断定できませんでした。 そのため、収益に影響が出るかどうかは今も確かめていません。
分からないものは、安全なほうに倒すことにしました。直るまでのあいだ、メールで送る記事は次のように決めました。
- Amazon の紹介リンクは入れない
- 出典は「(出典:発行元名)」と文字だけで書く
- 自分のブログへのリンクも入れない
包まれ方も細かく見ています。リンクの中の = という記号まで、%3D という別の書き方に置きかえられていました。中のアドレスが丸ごと変換されて、Google のアドレスの中に押し込まれていたわけです。
直す材料は残っていました。送る前の原稿が、6本とも保管庫に残っていたのです。リンクの本数も、公開ページと完全に一致しました。
翌9月8日、Mac のAIが公開中の6記事の HTML(記事の中身を書いた元の文字)を、包まれていない原稿で貼り直しました。公開中の記事を書き換えるので、私が承認してからの作業です。
結果は41本から0本になりました。 貼る前と貼った後で文字数を1本ずつ突き合わせ、6本とも一致しています。
つまずき①:AIの観察は正確で、解釈だけが違っていた
AIは「メール投稿でもラベルは付く」と報告しましたが、正しくはありませんでした。 ラベルとは、記事に付ける分類の名札のことです。Mac のAIは、9月5日に公開した2本にラベルが付いているのを見つけました。そこから「メールでもラベルは付けられる」と考えたのです。
実際は、私が手で付けたものでした。
AIから「公開済みになっていたのはなぜか」「ラベルが付いていたのはなぜか」と聞かれ、私はこう答えました。
私が下書きを公開しました私がラベルを手動でつけました
これで、謎が2つ同時に解けました。メール投稿の設定は「下書きとして保存」のまま変わっていませんでした。Mac のAIが3つのブログの設定画面を開いて確かめています。ラベルも、メールでは付かないという元の理解のほうが正しかったわけです。
ここで押さえておきたいのは、AIの観察そのものは正確だったことです。ラベルは確かに付いていました。違っていたのは、「なぜ付いているのか」という解釈だけでした。
しかもAIは、記録に「なぜ差が出たかは分からない」と【未確認】のまま残していました。決めつけずに止めておいたから、私の一言で正しく直せたのだと思います。
もう1つ、ここで見えたことがあります。私に手作業が2つ乗っていたのです。
- 下書きを公開する … これは判断なので、私の仕事です
- ラベルを付ける … これは書式を整える作業です
私の保管庫のルールには「書式を整える作業は全部AIの仕事」と書いてあります。ラベル付けは、本来AIに渡すべき作業でした。
Blogger API へ移すと決めた理由と、正直なリスク
Blogger API に移せば、困っていたことが4つまとめて片づく見込みでした。 API とは、ブログを外のプログラムから操作するための正式な窓口のことです。メールのように「届いた中身を Blogger が解釈して記事にする」のではなく、「記事のHTMLをこの形で入れてください」とそのまま渡せます。
AIがまとめてくれた比較は、次のとおりでした。
| いまの問題 | API に移すと |
|---|---|
| リンクが包まれる | 包まれない見込み(HTMLをそのまま渡すため) |
| ラベル付けが私の手作業 | 記事ごとにラベルを指定できる |
| 下書きが何本たまっているか数えられない | 一覧で取れる |
| 公開か下書きかが設定任せ | 記事ごとに「下書きで入れる」と指定できる |
最後の「下書きで入れる」は、Blogger API の公式の説明書に isDraft(下書きにするかどうか)という指定として載っています※1。
私の答えは一言でした。「移します」。9月8日のことです。
ただし、AIはリスクも正直に書いてきました。
Blogger API で記事を投稿するには、「記事の作成・編集・削除」までできる権限を渡す必要があります。 「書き込むだけ」という狭い権限は用意されていませんでした。メールの投稿用アドレスは記事を足すことしかできないので、それより広い権限を渡すことになります。
それでも移すと決めたのは、いまの状態が「リンクが包まれて収益にならないかもしれない」と「ラベル付けが私の手作業」の2つを抱えていたからです。代わりにAIの道具には、次の安全策を入れてもらいました。
- 何も指定しなければ、必ず下書きで入る。 公開は特別な指定をしたときだけ
- 本文に
google.com/urlが混ざっていたら、投稿せずに止まる
許可の口を開ける:AIが自分で押さなかったボタン
API を使うには、「このプログラムが私のブログを触ってよい」という許可を Google から取る必要があります。 この許可取りで、AIは自分の判断で何度か手を止めています。
クラウドのAIからは許可が取れなかった
最初の壁は、クラウドで動くAIからは、この許可が取れないことでした。
許可の取り方には、「画面にコードを出して、別の機械で承認する」方式があります。テレビ向けのアプリなどで使われるやり方です。ところが Google の公式の説明書を開くと、この方式が使える範囲は、ログイン情報・Google ドライブ・YouTube などに限られていました※2。Blogger は入っていませんでした。
残る方法は、ブラウザを開ける自分のパソコンの上で許可を取るやり方です。そこで、Mac で動いているAIに作業を頼みました。
規約への同意は、本人が押す
Mac のAIは、Google Cloud(Google の開発者向けの管理画面)で準備を進めました。Blogger API を使えるようにする設定まではAIが済ませています。
ところが、途中でぴたりと止まりました。画面の最後に、こんなチェック欄があったからです。
Google API サービス: ユーザーデータに関するポリシーに同意します。
AIの説明はこうでした。これは Google との規約への同意で、本人の意思表示にあたる。だからAIが代わりに押さない。
画面は開いたまま、チェックを入れて「作成」を押すところだけを私に渡してきました。同じ理由で、許可の画面で「許可」を押すのも私の役目になりました。
画面の端には、Google Cloud の無料トライアル(約300ドル分)を案内する表示も出ていました。AIはそれも押していません。 支払いの話には一切触れない、と記録に書いてありました。
道具がそのままでは動かなかった
もう1つつまずきました。クラウドのAIが作った許可取りの道具は、途中で人がキーボードから文字を打ち込む作りになっていました。ところが Mac のAIは、自分が動かしているプログラムに文字を打ち込めません。
そこで私は、こう頼みました。
ダウンロード済みのJSONから読み取る形に直して。値は画面に出さないで。私がやるのはブラウザの許可だけにして
JSON とは、設定の値が書かれたファイルのことです。AIはその場で一時的な道具を作り直し、私がやったのはブラウザで「許可」を押すことだけになりました。
合鍵にあたる秘密の値は、記録にもチャットにも1文字も書かれていません。私のクリップボード(コピーした内容を一時的に置いておく場所)に直接渡されました。
つまずき②:止まっていたのは、AIが作った「待ち」だった
許可は9月9日に取れていたのに、その後2日間、記事は Blogger に入りませんでした。 原因は技術ではなく、段取りでした。
クラウドのAIは、「クラウドの環境に秘密の値が入るまでは、Blogger へ送らない」と決めていました。そして私に、値を貼り付けるよう頼んで、返事を待っていたのです。
ところが、本当に必要だったのは「合鍵を持っている場所から送ること」だけでした。Mac のAIは、9月9日の時点で合鍵を持っていて、動くことも確かめていました。 クラウドで送れないなら、Mac から送ればよかったのです。
気づいたきっかけは、私の一言でした。
Bloggerに下書きは増えてないですよ?
クラウドのAIは、記録にこう書いています。保管庫のルールには「『できない』で止めない。必ず次の一手まで出す」とある。それを、自分が作った待ち状態には当てていなかった。 「クラウドで“まだ”できないとき」も、次の一手は別のセッションにある、と。
「待っている」状態のなかには、本当は待たなくてよいものが混ざっていたことになります。
結果:Blogger API で48本のリンクが1本も包まれなかった
9月11日、Mac のAIが3つのブログに1本ずつ、API で下書きを入れました。リンクは合計48本で、包まれたものは0件でした。 入れたあとに API で本文を取り直し、google.com/url の数を機械で数えています。
| メール投稿(前) | Blogger API(後) | |
|---|---|---|
| リンクの包まれ | 公開6記事で41本すべて | 3記事48本で0件 |
| ラベル | 付かない(私が手で付けていた) | 3本とも自動で付いた |
| 公開か下書きか | 設定任せ | 記事ごとに指定。何もしなければ下書き |
私も、Blogger の管理画面で実物を1本開いて確かめました。 ハンターハンターの記事が、ラベル付きで下書き保存されていました。Amazon のリンクも問題なく付いていました。AIは文字数とリンクの数しか見ていなかったので、画面での見え方を確かめたのは私が最初です。
これで、メール投稿は使わないと決めました。9月11日に、投稿の経路を API に完全に移しています。
残った宿題:合鍵は7日で切れる
1つだけ、宿題が残りました。
Google の公式の説明書によると、管理画面の公開状態が「テスト中」のままだと、合鍵は7日で切れます※3。名前やメールアドレスだけを使う場合は例外ですが、Blogger の権限はその例外に入りません。
切れないようにするには、公開状態を「本番」に上げる必要があります。そのとき、Google の審査が要るかどうかが問題でした。
調べ方は、管理画面で権限を1つ登録して、それが「機密かどうか」のどの区分に入るかを見ることでした。設定を変える操作なので、AIは押さずに私に聞いてきました。私は「更新押して下さい」と答えました。
結果は「非機密」でした。非機密なら、本番に上げるのに審査は要りません。ただし本番に上げるには、まだ空欄だった「アプリ名」を埋める必要があると分かり、AIはそこで止めて私の判断を待っています。
本番に上げれば7日の期限が外れる見込みですが、外れたことはまだ確かめていません。
おわりに:Blogger API への移行でわかったこと
今回の5日間を振り返ると、学んだことは3つでした。
- 「楽な経路」には、見えない細工が入ることがある。 メール投稿は便利でしたが、リンクが丸ごと別のアドレスに変わっていました。公開ページを開いて、リンクの中身まで読まないと気づけませんでした
- AIは、本人の意思表示が要るボタンを押さなかった。 規約への同意、無料トライアル、設定の変更。どれも私に回ってきました。任せる範囲と任せない範囲が、AIの側で守られていました
- 止まっている理由は、技術より段取りにあることが多い。 2日間の停止は、合鍵を持っている別のAIに頼めば済む話でした
かかった費用は0円です。Google Cloud の無料トライアルにも触れていません。
非エンジニアでも、AIに手順を聞きながらなら、ブログの投稿経路を作り替えられました。 ただ、AIは平気で決めつけますし、平気で待ちます。そこに気づく一言を出すのは、やはり人の役目でした。
出典
- ※1 Posts: insert(Blogger API v3)(Google for Developers)
- ※2 OAuth 2.0 for TV and Limited-Input Device Applications(Google for Developers)
- ※3 Using OAuth 2.0 to Access Google APIs(Google for Developers)

