本日の作業内容と、移行に向けて残っている準備をまとめます。

1. 本日の結果（結論）

移行対象となる全39本（発生額20本・リファラー19本）のうち、35本でログインからレポートページ到達までの動作確認が完了しました。残る2本はA8のstormADアカウントで、これはご指示によりスルーとしています。

これにより、Selenium 4対応と新環境での動作確認は、実データ取得を除いてほぼ完了した状態です。

2. 移行漏れになるところだった8本を復旧

本日最も重要な成果です。現行サーバーが実際に動かしているスクリプトとGitHubリポジトリの中身を突き合わせたところ、8本がリポジトリに登録されていないことが判明しました。

発生額側4本（A8の6アカウント目、オーガニックグループ、グラッド、ナハト）、リファラー側4本（同じ4アカウント分）です。リポジトリだけを見て移行していたら、この4社分のデータ取得が新サーバーで丸ごと止まっていました。

中田様から現行サーバーの最新ファイル一式をご提供いただき、8本すべてを取り込んで改修し、動作確認まで完了しています。

あわせて、オーガニックグループ・グラッド・ナハトの3社は同一システムの別ドメインで、処理が共通モジュール2本にまとめられていることも判明しました。この共通モジュールも古い記述のままだったため、同時に改修しています。

3. 現行サーバーでも起きていた不具合を2件発見・1件修正

テスト中に、移行とは無関係に現行環境でも発生していたと思われる問題が見つかりました。

1件目はA8リファラー6本の日付指定です。日付の欄はプルダウン形式ですが、スクリプトは文字を打ち込む方式で操作しようとしていたため、日付が設定されないまま検索が実行される状態でした。終了日にいたっては設定処理自体がありませんでした。プルダウン専用の操作方法に変更し、開始日・終了日とも前日を指定するよう修正済みです。実機で昨日の日付が正しく設定されることを確認しました。

2件目はA8 stormADアカウントのログイン失敗です。他のA8アカウントがすべて成功する中、このアカウントだけログイン後にトップページへ戻されます。現行サーバーの実行ログでもこのアカウントの報酬は0で、設定ファイル上のパスワードの文字数も他アカウントと明らかに異なっていました。パスワードが変更されて設定が古いままの可能性がありますが、ご指示によりスルーとしています。

4. データの送信先について

ご質問いただいた送信先2つ（plus-creative.xyz と data-organizing.com）は、いずれも変更不要です。

どちらもXserver上にあり、今回移すConoHa VPSとは別契約のため、移行の対象外です。またスクリプト側も送信先URLを設定ファイルで管理しているため、現行の設定ファイルを新サーバーへ持っていけば、送信先は自動的に同じになります。コードの修正は発生しません。

5. テスト環境の整備

中田様が1本ずつ動作を確認できるよう、テスト環境と記録用のチェックシートを整備しました。テスト環境の構成は現行サーバーと完全に一致しています（発生額20本・リファラー19本）。動作確認時のスクリーンショットは56枚を保管しており、チェックシートの各行から確認できます。

なお、本日の作業内容はGitHubリポジトリには一切反映していません（ご指示のとおり）。テスト用に取得した認証情報も、作業終了後にすべて削除済みです。

移行にあたって残っている準備

PLUS社にお願いしたいこと

・ConoHa VPSの新規契約（2GBプラン／Ubuntu 24.04 LTS／東京リージョン）
・契約後、新サーバーのIPアドレスと初期ログイン情報のご共有
・ASP各社の管理画面でIP制限をかけているかのご確認（かけている場合、新サーバーのIPを許可リストへ追加する作業が必要です）
・エラー通知の宛先と、リファラー側で使用しているSlack通知を現行のまま使うか、PLUS社側のものへ切り替えるかのご判断
・移行を実施する時期のご希望（月初・月末はデータ確認の負荷が高いため、月の中旬を推奨します）

中田側で実施すること（契約後）

・新サーバーの初期設定（タイムゾーンを日本時間へ変更、日本語環境の導入、作業用ユーザーの作成、SSH接続の安全化）
・実行環境の構築（Python・Chrome・必要なライブラリの導入）
・スクリプトと設定ファイルの配置
・実データでの動作確認（前日分のデータを実際に取得し、金額やCV件数が正しいか、受け先2サイトへ正しく登録されるかの確認）
・自動実行（cron）の登録と、初回自動実行の立ち会い確認
・1〜2週間の並行稼働と、新旧の登録結果の日次突合
・一致を確認したうえで、現行サーバー側の自動実行を停止

判断が必要な事項

・現在の8本の未登録スクリプトをGitHubリポジトリへ正式に登録するかどうか（登録しない場合、今後も同じ移行漏れリスクが残ります）
・A8 stormADアカウントを今後も取得対象として残すか、除外するか

実施上の注意点

並行稼働の期間中は、新旧2台から同じASPアカウントへ同時刻にログインすると、ASP側の制限で片方が弾かれる可能性があります。そのため実行時刻をずらす必要があります（例：現行は朝7時44分から、新サーバーは10時44分）。

現行サーバーの最新ファイル一式をご提供いただき、ありがとうございました。GitHub未管理だった8本すべてを取り込み、Selenium 4対応と動作確認まで完了しました。

未管理8本すべて成功

発生額側4本（A8 plusAD02、オーガニックグループ、グラッド、ナハト）、リファラー側4本（同じ4アカウント分）のすべてで、ログインからレポートページ到達までを確認しました。各社スクリーンショットを取得済みです。

判明した構造

オーガニックグループ、グラッド、ナハトの3社は同一システムの別ドメインで、共通モジュール（_btlr_fetch.py / _btlr_referrer.py）に処理がまとめられていました。この共通モジュール2本がSelenium 3のままだったため、あわせて改修しています。

A8の6アカウント目（plusAD02）については、リファラー側に他のA8と同じ日付プルダウンの不具合があったため、先日と同じ修正を適用しました。

改修内容

受領した8本と共通モジュール2本に対し、既存15本と同じ内容の対応を行いました。旧APIの置換、chromedriver_binaryの廃止、新ヘッドレスの明示、絶対パスの撤廃、ウィンドウサイズの指定です。全44本が構文チェックを通過しています。

現在の全体状況

全39本のうち、ログイン到達を確認できたものが35本になりました。残る2本はA8 stormADの発生額側とリファラー側で、これはご指示によりスルーとしています。未確認として残っていた8本は、今回すべて解消しました。

テスト環境の構成が現行サーバーと完全に一致（発生額20本・リファラー19本）したため、これで移行対象の全体像が確定しました。

ご確認いただきたい点

ご提供いただいたフォルダに認証情報ファイル（.env_asp）が2つ含まれていました。作業には支障ありませんでしたが、受け渡し用フォルダに認証情報が残り続けるのは望ましくないため、削除してよろしいでしょうか。必要な際は現行サーバーから直接取得できます。

なお、ご指示のとおり、今回の作業内容はGitHubリポジトリには一切反映していません。

A8リファラー5本の日付指定を修正しました。あわせて、前回のコメントに誤りがありましたので訂正いたします。

前回報告の訂正

前回「startYm / startD / reportSearchBtn が現行画面に存在しない」とお伝えしましたが、これは誤りでした。私が別の画面（コンバージョンリファラレポート）を調べて報告してしまったためです。実際にスクリプトが使う成果発生レポート画面を確認したところ、これら3つはいずれも現在も存在していました。誤った情報をお伝えし、申し訳ありません。

実際の原因

正しい原因は要素の種類でした。startYm と startD はテキスト入力欄ではなく、プルダウン（select要素）です。スクリプトは文字を打ち込む send_keys という方法を使っていましたが、プルダウンに対してこの方法は機能しません。そのため日付が設定されないまま検索が実行されていました。

さらに、開始日だけを設定して終了日（endYm / endD）を設定していないため、仮に開始日が入っても期間が「昨日から今日まで」ではなく「昨日から当月末まで」のようにずれる状態でした。

修正内容

プルダウン専用の操作方法（Select）に変更し、開始日と終了日の両方に昨日の日付を設定するようにしました。値の形式は実際の画面から確認しています（年月は2026/08のようにゼロ埋め、日は26のようにゼロ埋めなし）。

修正後、実際にA8へログインして動作を確認しました。開始日・終了日とも昨日（2026/08/26）が正しく設定され、検索が実行され、CSVダウンロードボタンが表示されるところまで確認できています。

対象はA8リファラー5本（plus0501 / plus02 / plus03 / plusAD / stormAD）すべてです。

ご指示への対応状況

テスト内容のリポジトリへの反映は行っていません。今回の修正はテスト環境上のみで、GitHubへのコミットもしていません。A8 stormADのログイン失敗については、ご指示のとおり対応せず記録のみ残しています。

補足

この日付指定の不具合は移行とは無関係に現行サーバーでも発生していたはずのものです。A8のリファラー取得データが想定と異なっていた場合、この不具合が原因の可能性があります。

リファラー側（asp_referrer）のログイン到達検証を完了しました。あわせて、移行前に対応が必要な問題を新たに1件検出しています。

検証結果（リファラー14本中13本 成功）

成功: A8 4アカウント（plus0501/plus02/plus03/plusAD）、JANet 5アカウント、AccessTrade、afiB、Felmat、Lacoco。各社ともログインからリファラーレポートページ到達まで確認し、スクリーンショットを取得済みです。

失敗: A8 stormAD の1本のみ。これは発生額側と同一アカウントで、原因も同じ（パスワード変更の可能性）です。A8管理画面でのご確認をお待ちしています。

新たに検出した問題: A8リファラーの日付指定が現行画面と不一致

A8のリファラー取得5本は、日付の指定に startYm（年月）と startD（日）という2つの入力欄、および reportSearchBtn という検索ボタンを使う作りになっています。

しかし現在のA8管理画面（新レポートβ版）を実際に確認したところ、これら3つはいずれも存在せず、日付欄は startYmd という1つの入力欄（2026/08/01 形式）に変更されていました。

つまりA8のリファラー取得は、現行サーバー上でも日付の指定に失敗している可能性が高い状態です。移行の有無にかかわらず、この5本はセレクタの修正が必要です。ログイン自体は正常なので、修正すれば復旧できる見込みです。

リファラー側にも未管理スクリプトが4本

発生額側と同様に、現行cronが実行している19本のうち4本がGitHub未登録でした。

• data-organizing_A8_plusAD02_referrer_get.py（A8の6アカウント目）
• data-organizing_organicgroup_referrer_get.py
• data-organizing_gladone_referrer_get.py
• data-organizing_nahato_referrer_get.py

発生額側の未管理4本と同じASPの組み合わせであり、両側で同じ4ASPがリポジトリから欠落していることが確定しました。

現在の全体進捗

全39本（発生額20本・リファラー19本）のうち、ログイン到達の確認が済んだものが27本、失敗1アカウント（発生額・リファラー各1本）、未管理により保留が8本です。

ご判断いただきたい事項（再掲を含む3点）

第一に、未管理スクリプト8本（発生額4本・リファラー4本）をリポジトリへ取り込んでよいか。第二に、A8 stormADアカウントのパスワードが変更されていないかのご確認。第三に、今回検出したA8リファラーの日付セレクタ修正を、移行作業に含めて実施してよいか。

テスト環境で1本ずつ検証を進めた結果、移行計画に影響する問題が3点見つかりました。

1. 現行サーバーの4本がGitHub未管理（最重要）

現行ConoHaのcronは発生額スクリプトを20本実行していますが、GitHubリポジトリ(PLUS-Company/asp_data_get)には16本しか登録されていません。以下4本がリポジトリ管理外です。

• slnm_a8_6.py（A8の6アカウント目。本日のログで報酬37,040を実際に取得しています）
• slnm_organicgroup.py
• slnm_gladone.py
• slnm_nahato.py

認証情報ファイルにもORGANICGROUP・GLADONE・NAHATOのキーが存在しており、実際に稼働している取得処理です。リポジトリだけを見て移行すると、これら4ASP分の発生額が新サーバーで取得されなくなります。

対応として、この4本を現行サーバーから取得してリポジトリへ取り込み、他と同じSelenium 4対応を施したうえでテスト対象に加える必要があります。実施してよいかご判断ください。

2. A8のアカウント対応がファイル名と一致していない

ファイル番号とアカウントの並びがずれていました。実測値は以下です。

• slnm_a8_3.py → plusAD
• slnm_a8_4.py → stormAD
• slnm_a8_5.py → plus03

数字順に対応していると想定すると誤ったアカウントで検証してしまうため、実測に基づき修正済みです。

3. A8 stormADアカウントでログインできない

他のA8アカウントが全て成功する中、stormADのみログイン後にトップページへ戻されます（再現性あり）。調査したところ、現行サーバーの本日の実行ログでもこのアカウントの報酬は0で、認証情報のパスワード長が他アカウントと明確に異なっていました。パスワードが変更されて設定ファイルが古いままの可能性があります。

A8管理画面でstormADアカウントのパスワードが変更されていないか、ご確認いただけますでしょうか。

本日の検証結果

発生額側16本のうち、Selenium利用の15本を検証し14本が成功しました（A8 4アカウント、JANet 5アカウント、AccessTrade、afiB、Felmat、Lacoco、TGaffi）。失敗はA8 stormADの1本のみで、原因は上記3のとおりです。

現在の状況

Selenium 4 対応のコード改修は発生額・リファラーの全32本とも完了し、GitHub の agent/selenium4-migration ブランチへ push 済みです。現行 ConoHa サーバーのコードには一切手を付けていないため、日次取得は従来どおり動いています。

現在は、その改修版を1本ずつ動作確認するためのテスト環境（中田のローカル）を構築中です。コード本体と発生額側の実行環境までは配置が終わり、残りはリファラー側の実行環境と検証用スクリプトの配置です。あわせて、確認の記録を1本ずつ残していくためのチェックシートを用意しました。

これから行うテスト（全31本を1本ずつ）

本番データを汚さないよう、テストを2段階に分けています。

フェーズA: ログイン到達の確認（受け先への送信なし）

各ASPの管理画面にログインし、レポートページまで到達できるかだけを確認します。CSVのダウンロードも、受け先への登録も行わないため、本番データは1件も動きません。ASP側の画面変更やChrome更新による影響は、この段階で検出できます。

対象は発生額16本・リファラー15本の計31本です。ASP内訳はA8（5アカウント）、JANet（5アカウント）、AccessTrade、afiB、Felmat、Lacoco、TGaffi、SLVRBULLETの8社16アカウントです。

フェーズB: 取得値とデータ登録の確認（新サーバー構築後）

実際に前日分の発生額・CVを取得し、値が正しいか、受け先2サイトへ正しく登録されるかを確認します。CSVのダウンロード、集計値の妥当性、リトライとSlack通知の動作もここで見ます。本番の受け先を汚さないため、この段階は新サーバー構築後に、実行時刻をずらした並行稼働で行います。

実施上の注意

同一ASPアカウントに現行サーバーと同時刻でログインすると、ASP側の同時ログイン制限で片方が弾かれる可能性があります。そのためテストは現行cronの実行時間帯（発生額7:44〜9:44、リファラー6:00）を避けて実施します。

進行中の課題

テスト環境を配置したフォルダが別マシンとのファイル同期対象になっており、実行環境のファイルが同期処理で巻き戻される事象が発生しています。原因は特定済みで、同期の除外設定を追加するか配置場所を変更することで解消できる見込みです。本日中に解消し、フェーズAに着手します。

サーバー契約について

契約前に着手できる作業（コード改修とログイン動線の確認）は完了しています。サーバー契約の準備が整いましたら、IPアドレスと初期ログイン情報をお知らせください。受領後、初期設定からcron登録まで進めます。

本日(2026-08-24)の進捗

• 両リポジトリ(asp_data_get / asp_referrer)の Selenium 4 対応コード改修が完了し、agent/selenium4-migration ブランチへ push 済み。
• 手元環境(Chrome 151 + Selenium 4.47)で発生額側の Selenium 7社(A8/AccessTrade/Felmat/JANet/Lacoco/TGaffi/afiB)の実ログイン検証を PASS。
• afiB のログイン破綻(トップページ隠れフォーム + 誤セレクタ + bare except)を発見して修正。全Seleniumスクリプトに --window-size を追加。
• progress 40%。

重要: 現行 ConoHa サーバー(/var/www/html/asp_data_get, /var/www/html/asp_referrer)で稼働中のコードには一切手を付けていません。改修はすべてローカルにコピーした実測物の上で行っています。現行の日次取得は従来どおり動いています。

明日(2026-08-25)の作業予定

方針: 一括移行や現行の置き換えはしません。現行を無傷のまま残し、独立したテスト環境で1本ずつ・1工程ずつ、依頼者(中田)自身が動きを目視確認しながら進めます。

1. 現行 ConoHa コードは無傷で保持(触らない)。
2. ローカル(または隔離した別環境)にテスト環境を用意する。
3. テスト用チェックシートを作成する(スクリプト単位・工程単位で、目的/実行コマンド/期待結果/PASS・FAIL を記録できる形)。
4. 作業ステップ説明書を作成する(各手順が何をするか、どう確認するかを依頼者が自分で追える形)。
5. 上記をもとに、依頼者(中田)と Claude で1本ずつ・1工程ずつ確認していく。

サーバー契約(指示書#1-3)は並行で進めていただける状態です。契約後の初期設定・cron登録・並行稼働は、上記テストで各スクリプトの正常動作を確認できてから着手します。

Selenium 4対応のコード改修と、実ASPアカウントでのログイン検証まで完了しました。両リポジトリとも agent/selenium4-migration ブランチへ push 済みです。

実ログイン検証の結果（最新Chrome 151 + Selenium 4.47 / 手元Mac）

発生額側 8社中、Selenium を使う7社すべてでログイン→レポートページ到達を確認しました（各社スクショ取得済み）:
A8 / AccessTrade / Felmat / JANet / Lacoco / TGaffi = 一発PASS。afiB のみ当初FAILし、原因特定して修正→PASS。
SLVRBULLET は JSON API 型でChrome更新の影響を受けないため対象外。

afiB で見つかった問題（要確認事項あり）

afiB のログインが失敗していました。原因は3点:
1. スクリプトが afi-b.com のトップページの隠れログインフォーム（#formPartnerId）を使っていたが、現在のUIではこのフォームは非表示（displayed=False）で操作不能。
2. ログインボタンのセレクタ button.btn-partner が「無料会員登録」ボタンにも一致する誤セレクタ。
3. さらに afb はログイン欄の id が DOM上で2重定義されており、通常の取得だと操作できない側を掴む。

修正: 専用ログインページ（/general/partner/requiredlogin）を使い、name属性＋可視判定で実入力欄を選ぶ形に変更。発生額側・リファラー側の両方の afiB スクリプトに反映済み。

【要確認】この不具合は「afi-b.com のトップUI変更でセレクタが合わなくなった」もので、いつから失敗していたかはコード側からは特定できません。受け先（plus-creative.xyz の asp_data）で afiB の日次発生額レコードが直近いつまで入っているかをご確認いただけると、影響期間が確定します。リファラー側の受け先には afiB のデータ蓄積自体はあります。

もう1点の共通改修: ヘッドレスの window-size

新Chromeの新ヘッドレス（--headless=new）は既定ウィンドウが小さく、ページ下部の要素が画面外だと入力が弾かれます（afiB で顕在化）。両リポジトリの全Seleniumスクリプトに --window-size=1920,1080 を追加しました。

現在の到達点と残作業

完了: 指示書#6「契約前に着手できること」の 1（コード改修 全32本）と 2（手元でのASPログイン検証）。
残り（新サーバー契約後）: サーバー初期設定、CSVダウンロード〜受け先insertまでの実データ経路の検証、cron登録、1〜2週間の並行稼働での新旧突合。

サーバー契約の準備が整いましたら、IPアドレス等をお知らせください（指示書#3）。

コード改修フェーズが完了しました。両リポジトリとも agent/selenium4-migration ブランチへ push 済みです。

asp_data_get (commit 3128454)

• chromedriver_binary 廃止 (14ファイル) → Selenium Manager 自動解決へ
• 旧 find_element_by_* 116箇所を By 形式へ置換
• Selenium 4 で削除済みの chrome_options= 引数を options= へ (10ファイル / 指示書外の隠れ改修項目として検出)
• --headless=new 化 (15ファイル)
• /var/www/html 直書き13箇所を撤廃 → スクリプト位置からの相対導出 (APP_DIR)
• asp_data_get.sh: 設置場所非依存 + venv Python + DISPLAY削除 + Downloads自動作成

asp_referrer (commit 43c0453)

• chromedriver_binary 廃止 (12ファイル) / 未使用の DesiredCapabilities import 削除 (5ファイル)
• 旧API 112箇所を By 形式へ置換 (css/id/name/xpath)
• --headless=new 化 (13ファイル)
• /var/www/html 直書き30箇所を撤廃。CSVダウンロード先を旧 referrer_get/ からリポジトリ内 Downloads/ へ集約 (サブフォルダ構成は維持)
• シェル: $SCRIPT_DIR 基準 + venv Python + Downloads自動作成

パス設計の判断

指示書ではB案「.env_asp にパスを持たせる」としていましたが、実装では「スクリプト自身の位置から相対導出」を採用しました。設定項目が増えず設定漏れの失敗モードが消える・_lib_env.py の既存慣習と一致・どこに置いても無改修で動くためで、「コードから絶対パスを消す」目的はより強く達成されます。

検証済み

• py_compile 全ファイル通過 (両リポジトリ)
• APP_DIR 定義順の機械検査 (accesstrade の定義前参照バグを検出・修正)
• Mac 手元環境 (Chrome 151 + Python 3.10 + Selenium 4.47) で Selenium Manager のドライバ自動解決・--headless=new 起動・By形式・download prefs のスモークテスト合格

残作業

• 実ASPアカウントでのログイン検証 (16+15本)。.env_asp の入手方法を Fumito と調整中

本日はチェックリスト3「asp_data_get バージョンアップ対応」に着手します。

予定作業:
1. Selenium 4対応ブランチ作成
2. 改修7項目の実施（chromedriver_binary削除 / 旧API置換 / DesiredCapabilities削除 / --headless=new / パス環境変数化(B案) / シェルのvenv対応 / pandas 2系対応）
3. 手元環境（Python 3.12 + Selenium 4）での動作検証
4. 進捗次第で asp_referrer 側にも着手

なお「サーバ契約後の作業工程検討」は2026-08-18のコメントにてA〜H工程として投稿済みのため、チェックを入れて消化しました。

asp_data_get の Selenium 4 対応

• 対応ブランチ作成 → 改修7項目（chromedriver_binary削除 / 旧API置換 / DesiredCapabilities削除 / --headless=new / パス環境変数化B案 / シェルのvenv化 / pandas 2系）

• 手元検証環境の構築 — Mac に Python 3.12 + Selenium 4 の venv を作り、最低1本（SLVRBULLET は API 型なので最初の疎通確認に最適）を実行確認

• （進捗次第）asp_referrer 側の同改修に着手（チェックリスト4）

サーバ契約後の作業は、以下になります。

A. サーバー初期設定

Ubuntu の初期状態はタイムゾーンがUTCで、日本語ロケールも入っていません。
この2つを直さないと、cronの実行時刻が9時間ずれ、ASP管理画面から取得した日本語が文字化けします。
取得スクリプトは「前日」を自分で計算しているため、OSの時刻がずれると取得対象日そのものが狂います。

タイムゾーンをJSTへ変更（timedatectl set-timezone Asia/Tokyo）
日本語ロケールの生成（ja_JP.UTF-8）とcron用の環境変数準備
日本語フォントの導入（fonts-noto-cjk）。Chromeが日本語を描画できないとDOM取得やデバッグ用スクショが読めなくなる
作業用一般ユーザーの作成とsudo付与。cronはこのユーザーで動かす（root不要）
パッケージ全体の更新
swapの確認。2GBプランなら通常は不要だが、Chrome多重起動時の保険として1〜2GB確保しておく
不要サービスの停止。今回のサーバーはWebを公開しないので、Apache/nginxは入れない

B. SSH の安全化

Ubuntu 24.04 特有のハマりどころが1つあります。
22.10以降のUbuntuはSSHがsystemdのsocket activationで起動するため、/etc/ssh/sshd_config の Port を変えるだけではポートが変わりません。ssh.socket 側の ListenStream も変更する必要があります。

手元でed25519鍵を作成し、公開鍵をサーバーへ登録
sshd_config でポート変更、PermitRootLogin no、PasswordAuthentication no
systemctl edit ssh.socket で ListenStream を新ポートへ上書き（これを忘れるとポートが22のまま）
変更適用前に別のターミナルで新ポートの接続確認をしてから既存セッションを閉じる（締め出し防止）
ufwで新SSHポートのみ許可
fail2banの導入
手元の ~/.ssh/config にホスト定義を追加
sudo systemctl edit ssh.socket

C. 実行環境のインストール

現行はChrome 86とSelenium 3.141で5年前のまま凍結されています。
新環境ではChromeが最新になるため、ドライバの取得方法そのものが変わります。
Selenium 4.6以降は同梱のSelenium Managerが対応ドライバを自動で解決するので、現行のように chromedriver-binary でバージョンを固定する必要がなくなります。

Python 3.12（Ubuntu 24.04 標準）と python3-venv の確認
プロジェクト用のvenvを作成。システムのPythonを直接汚さない
Google Chrome を公式aptリポジトリから導入。以降 apt upgrade で自動追従する
curl -fsSL https://dl.google.com/linux/linux_signing_key.pub | sudo gpg --dearmor -o /usr/share/keyrings/google-chrome.gpg
依存パッケージの導入: selenium（4系）、pandas（2系）、requests。chromedriver-binary は入れない
Xvfbは入れない。現行も実際には未インストールで、ヘッドレスで動いていた
google-chrome --version と、Selenium から起動してページを取得できるところまで最小サンプルで確認

D. 設置パスの決定（先に決めるべき判断ポイント）

現行コードには /var/www/html/... が50箇所以上ハードコードされています。ここをどう扱うかで以降の作業量が変わるので、Eに入る前に決めます。

A案: 同じ /var/www/html/asp_data_get/ /var/www/html/asp_referrer/ を使う
パス関連の改修が不要になり、移行作業が最短で終わる
ただしWebサーバーを置かないのに /var/www を使う不自然さが残り、次に移設するとき同じ問題を繰り返す

B案: /opt/asp/ 配下へ移し、パスを環境変数化する（推奨）
.env_asp にインストールディレクトリとダウンロード先を持たせ、コードから絶対パスを消す
50箇所の置換が必要だが、これは今回のSelenium 4対応で全ファイルを触るついでに済む
次回以降のサーバー移設がパス無改修で済むようになる

推奨はB案です。 どのみち全32本を触る改修なので、ここで一緒に片付けるのが合理的です。

E. asp_data_get の設定（発生額の取得 / 17本）

現在は毎朝7:44・8:44・9:44の3回動き、前日の発生件数と報酬をplus-creative.xyzへPOSTします。
ASP 8社・16アカウントぶんのログイン情報を扱うため、設定ファイルの権限管理が最重要です。

リポジトリを配置（PLUS-Company/asp_data_get、Selenium 4対応ブランチ）
.env_asp を現行サーバーから移送し、chmod 600 で配置。中身はASP各社のID/PW（16アカウント分）、受け先APIのURLとキー、メールAPIのシークレット、Basic認証、通知先アドレスの計38項目
ダウンロード用ディレクトリ（Downloads）の作成と書き込み権限確認
asp_data_get.sh の修正
冒頭の cd /var/www/html/asp_data_get/ を新パスへ
16箇所ある /usr/bin/python3 をvenvのPythonへ
export DISPLAY=:0 は不要になるので削除
16本の取得スクリプトを1本ずつ手動実行して確認
Selenium組（A8×5、Felmat、AccessTrade、afi-B、JANet×5、TG-Affiliate、Lacoco）はログイン動線が各社で違うため、まとめて流さず個別に見る
SLVRBULLETのみSeleniumではなくJSON APIなので、Chrome更新の影響を受けない
send_mail.py の通知が届くか確認
受け先（plus-creative.xyz / asp_data）の画面で前日データが入っていることを確認

F. asp_referrer の設定（リファラーの取得 / 15本）

毎日6:00に動き、CVがどの記事経由で発生したかをdata-organizing.comへ送ります。
asp_data_get とは作りが違い、こちらのほうが移設に強い構造になっているので、対応内容も変わります。

リポジトリを配置（PLUS-Company/asp_referrer）
.env_asp を600で配置。こちらにはSlack Webhook URLが含まれるため、発生額側とは中身が異なる
シェル（data-organizing_asp_referrer_get.sh）の確認
.env_asp はスクリプトと同階層から相対で読むため、この部分は無改修で動く
ただしPythonを python3 とPATH経由で呼んでいるため、cronのPATHにvenvを通すか、シェル側を書き換える必要がある
各スクリプトを最大3回リトライし、成否をSlackへ通知する構造はそのまま活かす
CSVダウンロード先の /var/www/html/referrer_get/ が23箇所にハードコードされているため、D案で決めたパスへ置換
15本を1本ずつ手動実行して確認
全件終了後に呼ばれる api_unsettled.php（未確定の再集計）が叩けることを確認
受け先（data-organizing.com）でCV行が入っていることを確認

G. cron の設定

cronは対話シェルと違い環境変数をほとんど引き継ぎません。
現行のcrontabにある環境変数のうち、新環境で必要なものと不要になるものを仕分ける必要があります。

crontabに設定する環境変数
MAILTO（エラー検知の生命線）
PYTHONIOENCODING=utf-8
LANG=ja_JP.UTF-8
PATH（venvを通す。referrer側のシェルがPATH依存のため必須）
DISPLAY と XAUTHORITY は削除する。 Xvfbを使っておらず、新ヘッドレスでは不要
毎日02:00の reboot は引き継がない。 現行機は稼働134日で、このcronは少なくとも直近134日実行されていません。メモリを2GBにする以上、reboot前提の運用を持ち込む理由がありません
並行稼働のあいだは実行時刻を現行とずらす（例: 発生額10:44、リファラー7:00）。同じASPアカウントへ同時刻に2台からログインすると、同時ログイン制限で片方が弾かれます
初回の自動実行に立ち会い、cron経由でも手動実行と同じ結果になることを確認

H. 検証と並行稼働

「スクリプトが動いた」ことと「正しいデータが入った」ことは別です。
受け先には重複判定があるため二重登録にはなりませんが、後から実行した側で上書きされるので、新サーバーの結果が正しいことを毎日見る必要があります。

1〜2週間、新旧を並行させて登録結果を突き合わせる
突合の観点
発生額: ASP別・アカウント別の件数と報酬額が一致するか
リファラー: CV件数と参照元URLが取れているか
報酬が空欄になっているレコードがないか
手動での再実行時は対象日が常に前日固定である点に注意する。過去日を埋めたい場合は現状スクリプトに日付引数がないため、Pythonを直接触る必要がある
連続7日以上一致したら切替判断

現在ASPの日次取得を動かしているサーバーは個人契約のConoHa VPSです。これをPLUS社名義の契約へ移すための指示書をまとめました。現行サーバーと両リポジトリ（asp_data_get / asp_referrer）を2026-08-18時点で実測し、その値を根拠にしています。

要点は3つです。第一に、現行機の名義変更ではなくPLUS社名義での新規契約をお願いします。現行機には本件と無関係な個人用の資産が同居しているためです。第二に、移すのはスクリプトと実行環境だけで、データベースは受け先2サイト（Xserver側）にあるためデータ移行は発生しません。第三に、スクリプトの改修は必須です。現行はChrome 86（2020年10月）とSelenium 3系で固定されており、新しいサーバーに入るChromeとは組み合わせられないためです。

以下が指示書の本文です。契約仕様、PLUS社側で用意していただくもの、こちらで進める準備、確認していただきたい点を分けて記載しています。

新規サーバー契約・移行 指示書（ASP日次取得システム）

対象: ASP発生額取得（asp_data_get）とリファラー取得（asp_referrer）を動かしているサーバー1台
現状: 上記2系統は個人契約のConoHa VPS（160.251.6.246）上で稼働しています。これをPLUS社名義で契約したサーバーへ移し、契約・支払い・権限をPLUS社側に一本化することが目的です。
調査日: 2026-08-18（現行サーバーおよび両リポジトリの実測に基づく）

0. 結論

1. PLUS社名義で ConoHa VPS「2GBプラン」（3コア / メモリ2GB / SSD 100GB）を新規契約 してください。OSは Ubuntu 24.04 LTS を選択します。
2. 現行サーバーの名義変更ではなく 新規契約 とします。現行機には本件と無関係な個人用の資産が同居しており、名義ごと引き継ぐ形は取れないためです。
3. 移行すべき永続データは実質ありません。データベースは受け先2サイト（Xserver側）にあり、今回移すのは「スクリプトと実行環境」だけです。
4. ただし スクリプトの改修は必須 です。現行はChrome 86（2020年10月）とSelenium 3系で固定されており、新しいサーバーで入るChromeとは組み合わせられません。改修点は本書「5. スクリプトのバージョン対応」に実測で列挙しています。

1. 契約してもらうサーバー仕様（申込画面で選ぶ値）

料金の目安（2026-08-18時点・ConoHa公式サイト記載・税込）

比較のためXserver VPSも確認しましたが、2GBプランは新規受付を停止中で、4GBプランは月額4,400円（12ヶ月契約で3,600円）とConoHaより高くなります。既存のXserver契約とまとめたい事情がなければConoHaを推奨します。

2. 契約時にPLUS社側で用意・決定していただくもの

1. ConoHaアカウント（法人名義）。既にあればそこに追加、なければ新規開設。
2. 支払い方法（クレジットカードまたはConoHaチャージ）。
3. rootパスワード。契約画面で設定します。値はPLUS社側で管理し、共有時は本タスクのコメント欄ではなく別経路でお願いします。
4. SSH接続ポリシーの承認。以下を前提に構築します。
   
   • SSHは公開鍵認証のみ（パスワード認証は無効化）
   • SSHポートは22から変更（現行機も2122に変更済み）
   • rootの直接ログインは禁止し、作業用の一般ユーザーを作成
5. 作業用ユーザー名の指定。指定がなければ plus とします。
6. 通知先の指定。現行はエラー・完了メールの宛先と、リファラー側のSlack Incoming Webhookを使っています。移行後も同じ宛先を使うか、PLUS社の別アドレス・別チャンネルに切り替えるかを決めてください。

3. 契約後に共有していただく情報

1. 新サーバーのIPアドレス
2. 初期rootパスワード（または初期ログイン手段）
3. ConoHaのコントロールパネルにアクセスできる担当者（障害時の再起動・コンソール操作をお願いする可能性があります）

上記を受領した時点から構築作業に着手できます。

4. 現行サーバーの実測値（今回の判断根拠）

2026-08-18にサーバーへ接続して取得した実測値です。

補足が2点あります。

• 引き継ぎレポートには「毎日02:00にrebootする」と記載がありますが、稼働時間が134日であることから、少なくとも直近134日間このrebootは実行されていません。この状態でも取得自体は継続しているため、新環境ではreboot前提の運用をやめ、メモリを増やす方向で組み直すのが妥当と考えます。
• CentOS 8はサポートが終了しており、パッケージの更新経路が失われています。Chromeが2020年から更新されていないのはこのためで、現行機の延命は現実的ではありません。

5. スクリプトのバージョン対応（改修が必要な箇所）

新サーバーではChromeが最新版（更新され続けるもの）になるため、Chrome 86に固定された現行コードはそのままでは動きません。両リポジトリ（PLUS-Company/asp_data_get、PLUS-Company/asp_referrer）の全ソースを実測して洗い出した改修項目です。

改修そのものは大部分が機械的な置換ですが、ASP 8社ぶんのログイン動線を1本ずつ実行して確認する工程が必要です。ASP側の画面変更や、Chromeが新しくなったことによる挙動差はここでしか検出できません。取得スクリプトは発生額17本・リファラー15本の計32本あります。

6. 中田側で事前に進めておくこと

契約を待たずに着手できるものと、契約後にしかできないものを分けています。

契約前（着手可能）

1. 両リポジトリのSelenium 4対応ブランチを作成し、上記1〜7の改修を実施する。
2. 手元の環境（最新Chrome + Python 3.12 + Selenium 4）でASP 8社ぶんのログインと取得を検証する。ここで各社の画面変更の有無も洗い出す。
3. 新サーバー用のセットアップ手順書（OS初期設定、Python・Chrome導入、cron登録まで）を作成する。作業を再現・引き継ぎできる形にしておく。
4. 現行サーバーに置いてある設定値（ASPアカウント、APIキー、通知先）の棚卸しを行い、新サーバーへ移す内容を確定する。値そのものは本タスクのコメントには記載しません。

契約後

5. 新サーバーの初期設定（作業ユーザー作成、SSH鍵設定、パスワード認証停止、ポート変更、タイムゾーンをJSTに設定）。
6. スクリプト配置と手動実行での疎通確認。受け先2サイトに正しく登録されるところまで確認します。
7. cron登録と、初回自動実行の立ち会い確認。
8. 1〜2週間の並行稼働で新旧の登録結果を突き合わせ、一致を確認したうえで現行サーバーのcronを停止。

7. 移行手順と切り替えの考え方

移すのはスクリプトと実行環境だけで、データベースは受け先2サイト（Xserver側）にあります。したがってデータ移行は発生せず、切り替えは「どちらのサーバーのcronを動かすか」を切り替えるだけです。

ただし並行稼働には条件があります。

• 同じASPアカウントに新旧2台から同時刻にログインすると、ASP側の同時ログイン制限でどちらかが弾かれる可能性があります。並行期間は実行時刻をずらす（例: 新サーバーは10:44、現行は従来どおり7:44〜9:44）運用にします。
• 受け先APIには重複判定（check）があるため、二重登録にはなりません。同じ日のデータは後から実行された側で上書きされます。したがって並行期間中は「新サーバーの結果が正しいか」を毎日確認する必要があります。

切り替え完了後、現行サーバー上のASP関連ディレクトリとcronは停止・削除します。現行サーバー（個人契約）自体は他の用途があるため解約はしません。

8. PLUS社に確認・判断していただきたい点

1. ASP各社の管理画面にIP制限をかけていないか。 かけている場合、新サーバーのIPアドレスを各ASPの許可リストへ追加する作業が必要です。ASP側の設定変更はPLUS社アカウントの操作になります。
2. 通知先（エラー・完了メールの宛先、Slack Webhook）を現行のまま使うか、PLUS社側のものへ切り替えるか。
3. リファラー側の受け先である data-organizing.com の扱い。 このドメインはXserver上で稼働しており、今回移すConoHa VPSとは別契約です。今回の対象外としていますが、こちらもPLUS社名義への整理が必要かどうかは別途ご判断ください。
4. バックアップオプションを付けるかどうか。
5. 移行の希望時期。 月初・月末はデータ確認の負荷が高いため、月の中旬に切り替え日を置くことを推奨します。