ブラウザとアカウントを紐づけたい…。
今回はChatGPTさんに助けてもらいながら、Python で複数のID（ユーザー）管理を行うアプリを作ってみました。
「私はロボットではありません」というワード、絶妙にシュールですね。
どうも、コンバット（クリムゾン）越後です。
生成AIの強みの一つは、情報の根拠が英語ベースなところです。
つまり、日本語化されていない文献であっても（むしろ喜んで）それらを参照します。
言うまでもなく、MicroSoft も Google も Webの根幹も欧米で生まれて発展してきたテクノロジーです（＝英語で書かれた文献が多い）。
内容によっては日本語の文章をネット検索で調べるよりも、生成AIに尋ねた方がはるかに効率的なのですね。
始まりは YouTube の一コマ
普通は前置きがもっと短いし、サッサと主題に入るのですケドね。
いちいち起承転結の「起」を丁寧に書くこのブログ。
副業関係をテーマにしたYouTube動画で見た一コマ。
まあ、こんなような内容ですね。
「これはスゴイことを知ったなあ」と、思いましたが。
ちょっと調べると、この方面で進めていくことを断念するに至りました。
理由としては
・コンテナ機能を理解するのが面倒くさい
・VPN（プロキシサーバー）に加入したらお金がかかる
・実際のところ、いくらくらいの費用かよくわからない
・VPNの仕組みやセッティングが複雑で難しそう
・「最新」の方法ではたぶん、無さそう
・界隈では有名な方法なので対策がとられていそう
頭の中でソロバンをはじいて、「ないな」と思ったのですね。
不明な点が多すぎる…、バフェット理論で有名な「自分が理解できないものには手を出すな」に通じる話です。
最後の項目ですが、SNS側として対策はとりやすいと思いますよ。
だって、Firefox + プロキシサーバー の組み合わせで商業活動している連中は怪しいってことでしょ。
シャドウバンなどしなくとも、スコアリングが不利になるようにアルゴリズムを変更したらPR効果が薄れていくのは確かでしょう。
しかし、考え方そのものはイタダキました。
Cookie（クッキー）とは何ぞや
Amazon でも X でも何でもいいですが、いちいち「ログイン」ってしないですよね。
でも、最初の1回目は絶対にアカウント作成やログインという作業をしているのです。
試しに、普段は使わない Edge とか違うブラウザで Amazon に行ったら、初回のログインを求められます。
当然、検索履歴などもそう。
サジェスト（おすすめ）もユーザー行動を元にして情報を出しています。
Cookie（クッキー）がユーザー情報を蓄えているから、便利に使えるわけです。
じゃあ、X でアカAで投稿した後にユーザー切り替えをして、アカBでアカAに「いいね」「フォロー」「リプライ」などをしたら、どうでしょうか？
同じ人が別々のアカウントをコネクトして、何かしているね、そう思われます。
どうでしょうか？ こんなことをしていて、このポストは注目を浴びているぞ！ などとアルゴリズムが判断してくれるでしょうか？
だから、Firefox のコンテナ機能なんですよ。
でも、それは先ほどの理由から使いたくないのです。
だから、Chrome で使えるブラウザ管理アプリを自作するのです。
自作と言っても、ChatGPTさんがだいたいやってくれるから簡単なのです。
最終的には、前回作った「グローバルIP七変化」スクリプトと合体させるわけです。
生成AIでコーディングのコツ
ChatGPT先生に別々の目的のスクリプト生成を何回も依頼していますが、一発でうまくいった試しはありません。
エラーで中断したり意図したとおりに動かなかったときは、エラーコードを読み解いたり、「〇●しても××しないのはなぜでしょう？」と分析する必要がある。
この辺の過程は、手動でコーディングする場合と一緒ですね。
大事なのは、ロードマップとなります。
生成AIも一発で成功するとは思っていない節があって、小規模から進めて徐々に機能を追加していくやり方を好みます。
だから、最終的にはこういうものを作りたい。
そう思っていても、段階を踏んで育てていくことが大切です。
まずはAのプロセスを試し、それがうまくいったらBのプロセスを試す。
Bのプロセスはうまくいかないな、これで煮詰まるよりは別のアプローチを考えようか。
Bがうまくいかない原因は…そういう感じですか。
じゃあ、その辺を避けて…Cのプロセスならどうでしょうか？
AIがいくつか方法を提案してきたな。
私が最終的にやりたいのはDだから、▲▲が実装できなくても支障は無いですね、プラン①でお願い。
動きました、これで、A→C→Dとつながった、成功ですね。
とにかく1発で決めようとしないことです。
いきなり長いコードをつくってしまうと、①→②→③→④→⑤のどこで問題が発生しているのか特定しにくくなります。
実際は①で問題が起きているのに、それが表面化するのが④だったりすると原因の究明が大変です。
あるいは、②→③は問題ないのにも関わらず③のアレが原因かもしれんな、みたいに間違った推論を生みやすくなります。
まずは①が本当に問題なく意図したとおりの結果になっているのかを検証、それができてから先に延ばしていくイメージが良いでしょう。
Selenium の利用
Python から Selenium を利用して、下記のスクリプトを作りたいです。
IDを後から追加していくことができます。
IDに対して、対応したブラウザを紐づけます。
ID-001でウェブサイトAにログインした状態を維持したまま、ID-002でウェブサイトBにログインすることが可能。
それぞれのIDでCookieを個別に管理して、状態を保存する。
とりあえず、最初の投げかけは上記の文章でした。
Selenium とは、ブラウザ絡みのテストで便利なやつです。
登録などしなくとも、Python にインポートするだけで利用できるので簡単です。
これで、GPTさんが割と抽象的なものを作ってきたので（それ単体では具体的に動作テストすることができない）、もうちょっと方向性を明確にしました。
分かりやすく進めていくために、 Googleアカウントを複数登録して、ブラウザ別にAmzonにログインする仕様で進めてみましょう。
こうやって具体性を持たせると、実働させながら動作テストを行うことができます。
そうすると、いい考えだとヨイショしてくれます ↓
とても良い選択です ✅
「Googleアカウントごとに独立したブラウザ環境を作り、その状態でAmazonにログインする」というのは、
Cookie管理やプロファイル分離の理解に最適な練習になります。
🎯 今回のゴール
複数の Google アカウントをそれぞれ独立した Selenium ブラウザ（プロファイル）に紐づけて、
各アカウントで Amazon にログイン → 状態を保持（Cookie保存・再利用）する。
🧩 ステップ全体像
| ステップ | 内容 | 実行の目的 |
|---|---|---|
| ① | プロファイルフォルダ構造を作る | Googleアカウントを個別に保持する |
| ② | Selenium で Chrome プロファイルを分離起動 | ID（例：google-001）ごとに別ブラウザ環境 |
| ③ | Amazon にアクセス＆手動でログイン | 各GoogleアカウントでAmazonログイン |
| ④ | Cookieを保存・再利用 | 次回以降、自動ログイン復元可能 |
🗂️ フォルダ構成（例）
project/
├─ profiles/
│ ├─ google-001/
│ ├─ google-002/
│ └─ google-003/
└─ amazon_multi_login.py
…、
まあこんな感じです。
最終的には、OS(C:)直下に空フォルダを作って保存することになりましたが、アカウント毎にCookie を保存しておいて、次回呼び出し時にはそれを読み込んでブラウザを開こうってわけです。
私は、クラウドであるGoogleDrive上にプロジェクトフォルダを作ってコーディングしていました。
それがデータの読み込みに悪影響している可能性がある、エラーを起こす理由の一つとしてそう考えられる。
そう言うから、内部（クラウドに依存しない場所）にデータ保存先を作りました…が、更新を続けていくうちにプロジェクトフォルダ内でデータ保存するようになりました。
結局、エラーを起こす原因は別のところにあり、データの保存先は関係なかったみたいです。
Amazon にログインする仕様にしたのはダミーです。
ここでSNSにログインしたいんや、と正直に書いてしまうと
「こいつ…、良からぬことを考えているのでは？ 一応、釘をさしておくか」と、思われることが経験則でわかってきたので、ちょっとダマしています。
それはそうとして、【🎯 今回のゴール】という文言を使っていますね。
そうなんです。
まずは近場のゴールを目指しましょう、それができたら拡張していって完成版に近づけましょう。
こういう考え方ですね。
このAI先生が持っているプロダクト・スタイルっていうのですか？
これを理解したうえで積み木を下から積んでいくことが重要。
アカギ vs 浦部 なんです。
ある程度の規模までは、生成AIのほぼ言う通りで積んでいけます。
どの規模まで可能かは、スクリプトの質に依存するでしょう。
つまり、上手に依頼・質問することによって「可能な規模」を大きくできます。
しかし、必ず限界が来る。
規模が大きく・複雑化するほど破綻が起きやすいから。
そうなってくると人間がコツコツ直していく作業が必要になると思います。
特に怖いのが、こちらが認識していない部分での改造がでてくることです。
「何かおかしくなっているぞ？ 何で？ …、え～と、知らない間にこの辺の構造がガラッと変わっているじゃないの！」
私レベルの運用ではそうです。
コーディングの知識なくてもプログラミング可能っていう話は、本当かなあ？ と、思います。
UI付きスクリプトの完成
便利さの代償に失っているものもある。
そういう哲学的な一面に気付いた気もしました。
簡単に言うなら、家の玄関の鍵をかけなければ外出先で鍵を無くさないように管理する手間がなくなるよ（その代わり家のドアは施錠されないよ）、みたいなものです。
スマホでSNSにアクセスするケースを考えます。
◎（勝利） IPアドレスの強度な迷彩力
×（不利） 同一IPアドレスの流用
×（不利） 端末固有のハードウェア・フィンガープリント
×（不利） メインブラウザの COOKIE（便利さの代償）
PCでSNSにアクセスするケースを考えます。
〇（有利） 特定しにくいハードウェア・フィンガープリント
△（微妙） 複数ブラウザの使い分け(面倒くさい）
▲（やや不利） 地域が絞られる住宅用ネット回線
×（不利） 同一IPアドレスの流用
×（不利） メインブラウザの COOKIE（便利さの代償）
普通に使用する感覚だと、ユーザーの行動は追跡されます。
×（不利）や▲（やや不利）の要素を排除しつつ、利便性も考慮しなければなりません。
足跡を残しにくいやり方であっても、不便で仕方が無いということなら「いい方法」だとは言えないでしょう。
隠密性と
使用コストと
わかりやすさと…
要求は多く、果てしない。欲しいものは作るしかありません。
どれだけ隠すんだ？ っていう話ですが、デキタ・デキタということです。
ブラウザは Chrome を使用。
Googleアカウントにログインした状態を維持して、最終ページも保存します。
アカウント毎にクッキーを個別管理、それだけじゃありません。
Firefox のコンテナ機能などいらん。
VPN への契約などいらん。
これから運用テストを開始します。
まあ、楽しみですね。
以前はゲームは何作か作りましたが、実用系はまったく手掛けませんでした。
ゲームの方が作っていて面白いというのもありますが、「データベース」と「ネットワーク」と「API連携」がコーディングの3大鬼門なんですね。
この鬼門に今、挑戦して制している。
しかも、開発速度が速い、とても速いのです。
それらの原動力となっている生成AIは、確かにパワーです、爆速エンジンです。
まあ、じゃじゃ馬ポルシェの手綱を握っているのは勘と根性で生きているアナログ人間なのですケドね、なんつって。
便利になったなあ（その代償は？）
昔は、雑誌に載っているコードを写本してましたからね。
一字一句間違えずに打たないと、エラーがでるという。
コピペ？ 何それですよ。
英単語で “color” ってあるじゃないですか？
こういうローマ字とのギャップが激しいものは、暗記するのに苦労しましたね。
C-O-L-O-R（シー・オー・エル・オー・アール）ってYMCA方式で覚えましたよ、色指定なんてものは頻繁に出てきますからね。
昔は聖書やお経を「写本」していたわけです、もちろんキーボードじゃなくて筆で手書きですが。
でも、BASICの写本とかしていたら、少しだけ気持ちがわかるのです、古代人の。
この気持ちがわかるっていうのが大事なのです、私はロボットではありませんから。
手を使うっていう事は、何気に大事だと思いますけどね。
人間は体を動かさないと賢くならない「生命体」なのです。
これこそが超余談にして、AIに頼りすぎてはダメよっていう…アレです。
いや～、スゴイ余談だったなあ。
コメント