【2026-10-08 全ASP移管セット・移行ガイドの整備】

新サーバーはまだ未契約です。契約後にすぐ再開できるよう、全ASPを対象としてソース・共通処理・依存・設定例・起動対象・移行手順をまとめました。中田さんから「契約が終わったらこのセットを使う」方針をいただいています。

■ 契約後に使う保管物
全ASP移管セットZIP（75ファイル）:
https://nakata.studio/file_uploader/download.php?id=24

移行ガイド（概要と手順画面から上のZIPを取得可能）:
https://nakata.studio/support_guide_hub/view.php?id=7

担当者さんへお渡し済みの契約ガイド:
https://plus-creative.xyz/nakata/asp_server_guide/

■ 収録対象
11 ASP: A8、afb、ACCESSTRADE、Felmat、JANet、Lacoco、TG Affiliate、SLVRBULLET、GLADONE、NAHATO、ORGANICGROUP。
日次取得20本、リファラー取得19本、共通処理、Selenium/requests/pandas依存、認証実値が空の.env例、39本の実行対象一覧、元の起動シェル、検証記録、START_HERE/ASP_INVENTORY/MIGRATION_PLANを収録。秘密鍵・認証実値・本番DBは含めていません。
一度A8だけを全体移管セットとしてまとめてしまった範囲誤りを訂正しました。旧31ファイル版（id23）はA8限定の旧版で、全体移管には使用しません。

■ 今回の検証
・旧サーバーの取得ソース39本と収録対象のファイル名が一致。
・全Python/シェル構文、共通モジュール参照、環境設定キー、SHA256を点検。
・A8既存5組のMac実取得は日次/リファラー合計一致。本番API呼出し0。詳細はタスク#498。
・stormADを含むA8 12入口のオフライン試験成功。stormAD実取得は未実施。
・アップロードZIPはダウンロードした全バイトが一致。ガイド本文・リンクを読み戻し、既存の回答と閲覧進捗を維持。PC/スマホ幅の概要表示も点検。

■ 契約後の再開手順
1. IPと接続鍵を安全な経路で受領。
2. 実行ユーザーの旧cron、全ASPの有効/停止アカウント、通知・メール・集計処理と実行順を確定。
3. 新UbuntuへPython/Chrome/venvと全ASPソースを配置。実値設定は安全に移す。
4. 他ASPは素のソースに本番送信があるため、送信なし入口を先に整備・検証。そのうえで全有効ASPを実取得し、管理画面の対象日・金額・件数と照合。
5. cron相当試験と原則7日の新旧照合（旧側のみ本番送信、新側は送信なし）。中田さん承認後に旧取得処理を停止して新側へ切替、受信保存と重複なしを読み戻す。

TG Affiliateリファラーは保存版・旧サーバーともソースがなく、必要性を移行前に決定します。実行ユーザーの旧cronや一部権限不足ファイルは再開時に読みます。全ASPの新Ubuntu実取得・本番切替は未実施です。今回、旧ソース・旧cron・本番DBは変更していません。

ローカル保管先:
/Users/nakatafumito/Workspace/20261008/plus-all-asp-migration/kit/
月次アーカイブ:
https://github.com/nakata-studio/202610/tree/main/20261008/plus-all-asp-migration

9/28 本日の作業まとめ

本日は、タスク #492 の「契約ガイド整備」「Selenium 4対応版の整理」「契約後の移行計画」を一続きで進めました。

1. サーバー契約ガイドの確認・修正

• ConoHa公式で2GBプラン、まとめトク期限、自動バックアップ、申込手順を再確認しました。10/2以降は公式表示で再判断する注意、パスワード登録後の「確認しました」、チャージ入金期限、鍵削除・問い合わせ先を反映しています。
• 申込ページは「新規アカウント作成」と「既存アカウントログイン」が同じ画面にあることを実ブラウザで確認し、アカウント有無に応じて進める案内へ修正しました。
• 「本件の概要」を会社へ渡せる表現に整え、関連ページを右側の小窓、Markdownコピー／ダウンロードを左下に配置。本文リンクは青＋下線、関連リンクはページ名＋小さいURL表示に変更しました。
• 不安を与える古いサーバー表現を削除し、開始案内を21px・常時点滅へ調整。PC／スマホで表示・操作を確認し、はみ出しとコンソールエラーがないことを確認しました。
• 対象: /Users/nakatafumito/Workspace/20260924/asp_server_guide/index.html

2. Selenium 4対応版の整理

• /Users/nakatafumito/dev/PLUS/ASP_SCRIPTS/Selenium_4 に、発生額取得とリファラー取得のSelenium 4対応版を整理して配置しました。
• task #492 の過去記録と対応ブランチを突合し、afiB修正、未追跡のローカル10ファイル、確認用ページ2件を含めています。実データ入り.env、CSV・ログ、venv、未確認のA8作業中差分は除外しました。
• Python 44ファイルの構文、シェル構文、旧Selenium API、chromedriver_binary、旧絶対パス、DISPLAY/XAUTHORITY残存を機械確認し、READMEとチェックサムを付けました。
• 実績確認範囲は発生額13/14（Lacoco保留）、リファラー12/12（Lacoco対象外）です。A8追加アカウント、新Ubuntu上のcron、受信先までの本番相当確認は契約後に行います。

3. 契約後のサーバー設定・移行計画

• 作業計画HTMLを /Users/nakatafumito/Workspace/20260928/asp-server-setup-plan/index.html に作成しました。
• 見積りは実作業10〜18時間、最短9日、推奨10〜14日です。Day0〜3で接続・初期設定・Selenium 4版配置・個別試験・初回cron、Day4〜10で7日間の新旧照合を行います。
• 7日連続で結果が一致した時だけ切り替え、不一致時は旧サーバーを止めない安全条件にしています。16:9スライド9枚、ローカル表示、レスポンシブ、キー操作、記事への復帰、コンソールエラー0を確認済みです。

4. レポート作成基盤の更新

• 新しいreport-templateを、記事表示に加えて16:9スライドと任意のWeb Speech音声を同一HTMLで使えるよう更新しました。通常はreport.html、スライド／音声指定時はcombined.htmlを使う運用に統一し、旧report-page-builderは既存ページ保守専用としました。
• 音声は明示ボタンを押した時だけ開始し、停止・記事表示・タブ移動・離脱・最終スライドで止まる仕様です。PC／スマホ、16:9比率、ナビゲーション、Markdownコピー、短時間の音声開始・停止、コンソールエラー0を確認しています。

現在地と次の作業

• 契約ガイド、Selenium 4対応版、移行計画は契約前に準備できる範囲まで完了しています。
• タスクは引き続き「対応中」です。次は新サーバー契約後に、実機構築、A8追加アカウント確認、cron・受信先確認、7日連続照合を進めます。Lacocoは保留扱いです。

Codex: ASP日次取得サーバーの構築・移行作業計画HTML（Fumito確認用初稿）を作成。ローカル: /Users/nakatafumito/Workspace/20260928/asp-server-setup-plan/index.html。見積は実作業10〜18時間、全体最短9日・推奨10〜14日。Day 0〜3で接続・基盤・Selenium 4版配置・個別試験・cron初回確認、Day 4〜10は新旧7日間並行稼働、7日連続一致で切替判断。不一致時は旧系を維持して再確認。9枚スライドは音声なし。ローカル表示、960pxレスポンシブ、デスクトップ16:9、前後移動、ページ復帰、コンソールエラー0件を確認。月次アーカイブ nakata-studio/202609 PR #8 をmainへマージ済み。次: Fumitoによる内容確認。チェックリスト状態は変更していない。

Selenium 4対応版の整理・配置（Codex / 9/28）

task_manage #492 のコメント1263・1268・1271・1272・1273とローカルの移行ブランチを照合し、次へ配置しました。

/Users/nakatafumito/dev/PLUS/ASP_SCRIPTS/Selenium_4

• asp_data_get: agent/selenium4-migration / 887f55f（afiB可視ボタン修正を含む）
• asp_referrer: agent/selenium4-migration / 5c5fe2f（afiB可視ボタン修正を含む）
• コメント1273でローカル版を本流として扱うとされたGit未登録ファイル10本も追加
• 4工程記録ページ2枚を verification/ に同梱
• 実値入り .env_asp、CSV、ログ、venv、デモ用ファイルは除外
• コメント1273で「今回の作業ではない・中身未確認」とされたasp_referrerのA8 5本の未コミット差分は除外し、コミット版を採用

確認結果: Python 44本の構文OK、shell構文OK、旧Selenium記法・chromedriver_binary・/var/www/html固定・DISPLAY/XAUTHORITYのコード残存0、コピー元との内容一致（追跡済み42・ローカル追加10・検証HTML2）。SHA256SUMSと整理方針READMEを同梱。

492の検証記録上の範囲は、発生額13/14（Lacoco保留）、リファラー12/12（Lacoco対象外）です。A8追加アカウントと新Ubuntuサーバー上でのcron/本番受信先確認は未完のため、READMEに明記しています。

サーバー契約ガイドページの修正と調整（9/28）

修正した内容

• 料金を再確認：9/28 に ConoHa 公式サイトで確認し、9/24 と同じ金額でした。確認日を 9/28 に更新しました
• 10月2日以降の申込への備え：まとめトクのキャンペーン価格は 10/1 申込分までです。10/2 以降に申し込む場合は公式の料金ページで金額を確認し、12ヶ月か時間課金かを判断できる基準を追記しました
• 申込手順の抜けを補足：公式の手順にある、パスワード登録後の「確認しました」を押す操作を追加しました
• 鍵ファイルの扱い
  • 「一度しか保存できない」という注意を、申込を確定する前の画面（オプション設定）に移しました
  • 中田がサーバーに入れたことを確認した後に、Chatwork とパソコンから鍵ファイルを削除する手順を追加しました（Chatwork 公式ヘルプの手順）
• まとめトクの更新への備え：チャージ払いの入金期限（満了の7日前）と、満了日を控えて社内で予定を入れる手順を追加しました
• 困ったときの窓口：認証・支払いで進めないときのために、ConoHa のお問い合わせ窓口へのリンクを追加しました
• 細かな表記：料金タイプの表記、自動バックアップの選択との整合、画面写真の印の位置を直しました

確認したこと

• 金額・手順は、ConoHa 公式のページと照合しました（別の担当による事実確認を2回実施）
• パソコンとスマートフォンの画面幅で、最初から最後まで操作できることを確認しました

今後

ガイドページが整いました。お渡しの準備ができています。

サーバー契約ガイドページの作成と、本日の作業

作成したもの（9/24〜9/26）

サーバー契約のご案内を、1画面ずつ進めるガイドページとして作成しました。対応者の方がこのページだけで ConoHa VPS の契約を完了し、接続用の鍵ファイルと IP アドレスを中田へお送りいただくところまで進められる内容です。

構成 1. 契約が必要な理由
2. 料金とプランの決め方（メモリ2GBプラン。料金は 9/24 に ConoHa 公式サイトで確認）
3. 申込の前に用意するもの
4. 申込の手順（申込画面へ直接開けるボタン、画面の写真に操作する場所の印付き）
5. 接続用の鍵ファイルのダウンロード
6. IP アドレス・接続の許可・自動更新の確認
7. 鍵ファイルと IP アドレスを中田へ送って完了

そのほか - 料金や手順の公式ページへのリンク
- 画面写真の拡大表示
- 案内文の音声読み上げ（オン・オフ切り替え可）
- 形式は HTML ファイル1つで、ブラウザで開くだけで動きます

本日（9/28）の作業

ガイドページの修正と調整を行います。

今後

調整が整い次第、ガイドページをお渡しします。
なお、ページに載せている「まとめトク」の料金は 10/1 申込分までのキャンペーン価格です。お渡しの時点で期限を過ぎている場合は、公式の料金を確認し直して反映します。

次の PLUS 作業日の対応内容（9/17 決定）

1. サーバー契約サポートページの作成（メイン）

目的：サーバー契約をお願いしているが、まだ動いてもらえていない。契約する内容を改めて紹介し、契約の流れを案内する（コンシェルジュする）、シンプルで分かりやすいサポートページを作る。

決まっていること - 読む人の呼び方は 「対応者」。「上司向け」などの言い方はページにも説明にも使わない
- 構成：対応者が最初に「なぜ必要か・費用・決めてもらうこと」を把握でき、その後に契約の流れ（手順）が続く形
- 形式：単体の .html 1ファイル。JavaScript はファイル内にインラインで書く
- 置き場所：作成日の日付フォルダ（例 /Users/nakatafumito/Workspace/<作成日>/asp-server-contract-support/index.html。フォルダ名は仮）
- 料金：作成日に ConoHa 公式サイトで調べ直して載せる（8/18 時点の値は使わない）。調べた日付をページに書く

材料 - コメント 1235「新規サーバー契約・移行 指示書」（8/18）
- 契約仕様：ConoHa VPS 2GBプラン / Ubuntu 24.04 LTS / 東京 / 自動バックアップ任意・推奨 / PLUS社名義で新規契約（名義変更ではない）
- 用意・決定してもらうもの：法人名義の ConoHa アカウント、支払い方法、root パスワード（共有はコメント欄以外の経路）、SSH 方針の承認、作業用ユーザー名、通知先
- 契約後に共有してもらう情報：IP アドレス、初期ログイン手段、コントロールパネル担当者
- 判断してもらう点：ASP 管理画面の IP 制限、通知先、data-organizing.com の扱い、バックアップ、移行希望時期
- コメント 1236「サーバ契約後の作業 A〜H」
- 旧レポート（契約のお願い）：https://plus-creative.xyz/nakata/plus_ai_report/detail/?id=3

作成日にやる手順 1. ConoHa 公式サイトで、料金、申込画面の選択肢（プラン・OS・リージョン・バックアップ）、法人名義での申込の流れを確認する
2. 1235 の内容を、対応者が迷わず手を動かせる順に並べ直してページを作る
3. PC 幅とスマホ幅で表示崩れ・コンソールエラーが無いことを確認し、中田に URL（フルパス）を渡す
4. 当月アーカイブ（nakata-studio/）の日付フォルダへ保存する

2. 中田の判断待ち（作業前に確認する）

• push：afiB ログインボタン修正のコミット 2件は未 push
  
  • asp_data_get 887f55f（slnm_afib.py）
  • asp_referrer 5c5fe2f（data-organizing_afiB_plus0501_referrer_get.py）
  • ブランチはどちらも agent/selenium4-migration（origin より 1 コミット先）
• Git 未登録ファイルの登録：新サーバーへ GitHub から配置すると入らず、該当 ASP が動かなくなる
  
  • asp_data_get：_btlr_fetch.py、slnm_a8_6.py、slnm_gladone.py、slnm_nahato.py、slnm_organicgroup.py
  • asp_referrer：_btlr_referrer.py（OrganicGroup・Gladone・Nahato の共通取得処理）、data-organizing_A8_plusAD02_referrer_get.py、data-organizing_gladone_referrer_get.py、data-organizing_nahato_referrer_get.py、data-organizing_organicgroup_referrer_get.py
  • 9/15 に「GitHub に無いものはローカル版を本流として扱う」と中田判断済み（現行サーバー由来）
• asp_referrer の A8 5本（plus02・plus03・plus0501・plusAD・stormAD）の変更は、今回の作業ではない未コミット変更。中身は未確認

3. その後の作業（参考）

• 契約後サーバー作業の設計ページ（1236 の A〜H と、1271 の「本流の注意点」を移行前チェック項目として入れる）
• Lacoco（発生額・リファラーとも）は保留のまま

現在の状態（9/17 終了時点）

• 4工程確認：発生額 13/14（Lacoco 保留）、リファラー 12/12 完了（Lacoco スルー）
• デモ用フォルダは片付け済み（.env_asp・受信記録なし、モック停止）
• 記録ページを MAMP で開くリンク：/Users/nakatafumito/dev/htdocs/asp-server-migration-20260914（作業終了後は削除候補）

1271 の訂正：「次にやること 1（管理画面で3件を照合）」は取り下げ

理由：この確認の目的は「移行で壊れていないか（今の本番と同じに動くか）」。照合は移行の合否に関係しないため不要と判断した（中田了承）。

• JANet（pp2005141）・Felmat：移行ブランチの変更を git diff で確認した。変わったのは Selenium 4 の書き方・ヘッドレス指定・ダウンロード先パス・window-size だけで、CSV の読む列（row[n]）は1か所も変わっていない。参照元URLが空になるのは今の本番でも同じで、移行の問題ではない
• SLVRBULLET：API で取得するだけで、移行で変わる部分が無い

反映 - 記録ページ 02_asp_referrer.html：JANet pp2005141 の④を OK に変更、Felmat・SLVRBULLET のメモから「未照合」を削除。記録表は 12/12 完了。焼き込み済み、当月アーカイブにも保存（サイズ一致）

次にやること（1271 の 2〜5 を繰り上げ） 1. 中田：片付け _demo で ./run_demo.sh clean（確認を続けるなら残す）
2. 中田判断：afiB 修正（2ファイル1行ずつ）のコミットと、asp_referrer/_btlr_referrer.py の Git 登録
3. 契約後サーバー作業の設計ページを作る（8/18 コメント「A〜H」と 1271 の「本流の注意点」が材料）
4. Lacoco（発生額・リファラーとも）は保留のまま

9/17 リファラー（asp_referrer）4工程確認の結果と次にやること

1269（引き継ぎ）の「8. 残作業」の 3 を実施した。前日 9/16 分を、送信先をモックに向けたデモで1本ずつ確認した（実行は中田、準備・差分確認・記録は Claude）。

結果（対象12本・Lacoco はスルー）

• モックのリファラー表は 0件 → 149件。各ASPの送信件数の合計と一致
• 成果日はすべて 9/16。前日指定は全ASPで正しく動いた
• 記録ページのチェック6項目はすべて OK。記録表は 11/12 完了（pp2005141 の④だけ照合待ち）

今日やった準備（すべて未コミット・デモ用フォルダ内）

• 設定ファイル _demo/.env_asp に ASP_REFERRER_API_URL（モック）と仮の ASP_REFERRER_API_KEY を追記（中田承認。モックはキーを検証しない）
• リファラーのデモを12本作成：demo/demo<slvrbullet|accesstrade|afib|felmat|organicgroup|gladone|nahato>referrer.py、demo_janet<番号>_referrer.py（5本）、btlr系共通のデモ版 _demo/_btlr_referrer.py
• 全本で diff と構文チェック済み。差分は一時停止・表示・送信件数の数え上げとヘッドレス指定だけ
• run_demo.sh の referrer に対象指定を追加：./run_demo.sh referrer <a8|slvrbullet|accesstrade|afib|felmat|organicgroup|gladone|nahato|janet1037642|janet2005141|janet2005790|janet2007625|janet2007788>（省略時 A8）
• 記録ページを MAMP で開けるよう、シンボリックリンク /Users/nakatafumito/dev/htdocs/asp-server-migration-20260914 を作成（索引 htdocs/INDEX.md に登録。作業終了後は削除候補）
  
  • http://localhost:8887/asp-server-migration-20260914/02_asp_referrer.html
    
• 記録ページ /Users/nakatafumito/Workspace/20260914/asp-server-migration/02_asp_referrer.html に結果を書き込み、焼き込み済み。当月アーカイブ nakata-studio/202609 にも保存（サイズ一致）

本流のコードから分かった注意点（未修正・移行前に判断が必要）

• btlr系の共通処理 asp_referrer/_btlr_referrer.py が Git 未追跡。無いと OrganicGroup・Gladone・Nahato の3本とも動かない
• afiB・Felmat・JANet・AccessTrade は受け先の応答を確認しない（失敗しても気づかない）
• afiB・Felmat・JANet・AccessTrade は、ダウンロード失敗時にフォルダに残った古い CSV を送るおそれがある
• afiB（13〜16列）・Felmat（16列）・JANet（13〜20列）は、列数チェックより後ろの列を読むため、列の少ない行で止まる
• Felmat・JANet はログイン直後に待たずに次の画面へ進む（本番でタイミング失敗のおそれ）。デモは一時停止で隠れる
• btlr系はダウンロード失敗も0件扱いで正常終了する
• リファラー側の Lacoco は lacoco_sales_tb を使わない（今のモックのまま確認は可能）

次にやること（優先順）

1. 中田：管理画面で3件を照合する
   • JANet pp2005141：9/16 の SMBCモビット3件に参照元が出ているか。出ていれば本流が読む列（21列目）のずれで、JANet 5本すべてに影響
   • Felmat：9/16 で参照元URLが空の4件が、管理画面でも空か
   • SLVRBULLET：9/16 の成果が0件か
   • 結果を受けて、Claude が記録ページ（pp2005141 の④・メモ）を更新して焼き込み直す
2. 中田：片付け _demo で ./run_demo.sh clean（.env_asp・受信ログ・CSV を削除。モックも止まる）。確認を続けるなら残す
3. 中田判断：afiB 修正（2ファイル1行ずつ）と _btlr_referrer.py の Git 登録をどうするか
4. 契約後サーバー作業の設計ページを作る（8/18 のコメント「サーバ契約後の作業 A〜H」が材料）。上の「本流の注意点」も移行前チェック項目として入れる
5. Lacoco（発生額・リファラーとも）は保留のまま

このコメントは、会話の記憶を持たない次のAIセッションが、ここから作業を再開するための引き継ぎです。1268（9/15 の進捗）とあわせて読んでください。認証情報の値はここには書いていません。

0. 最初にやること

1. このコメントと 1268 を読む
2. 記録ページ /Users/nakatafumito/Workspace/20260914/asp-server-migration/01_asp_data_get.html を読む（確認済みの結果・注意点はページ内の CFG と verified JSON に入っている）
3. 中田に、どの作業から再開するかを「8. 残作業」から選んでもらう

1. 現在地（9/15 終了時点）

• 発生額（asp_data_get）：14本中13本の4工程確認が完了。Lacoco は保留
• リファラー（asp_referrer）：未着手。記録ページ 02 は作成済みだが、確認結果はまだ無い
• 契約後サーバー作業の設計ページ：未着手
• サーバーは未契約
• 片付け（clean）は、中田が実行する予定。実行済みかは設定ファイルの有無で確かめる

2. 場所（フルパス）

記録・引き継ぎ - 発生額の記録ページ：/Users/nakatafumito/Workspace/20260914/asp-server-migration/01_asp_data_get.html
- リファラーの記録ページ：/Users/nakatafumito/Workspace/20260914/asp-server-migration/02_asp_referrer.html
- 記録ページの焼き込み道具：/Users/nakatafumito/Workspace/20260914/asp-server-migration/_tools/（bake_server.py・bake_apply.py）
- 9/15 のモック受信ログの控え：/Users/nakatafumito/Workspace/20260914/asp-server-migration/_evidence/（アカウントIDを含むためアーカイブには置かない）
- 当月アーカイブ：GitHub nakata-studio/202609 の 20260914/asp-server-migration/（anonymousapart の gh トークンで操作）

デモ（確認用の実行環境） - デモ用フォルダ：/Users/nakatafumito/dev/htdocs/plus_asp_data_get_test/demo/
- 実行：_demo/run_demo.sh（mock / data_get [対象] / referrer / stop / clean）
- data_get の対象名：a8 / slvrbullet / accesstrade / afib / felmat / tgafi / organicgroup / gladone / nahato / janet1037642 / janet2005141 / janet2005790 / janet2007625 / janet2007788
- デモ本体：_demo/demo<対象>_data_get.py（リファラーは demo_a8_referrer.py の1本のみ）
- btlr系3本の共通補助ファイル（デモ版）：_demo/_btlr_fetch.py
- 一時停止の部品：_demo/_pause.py（step で Enter 待ち、show で値を表示。DEMO_AUTO=1 で止まらない）
- モック受け先：_demo/mock_receiver.py（127.0.0.1:8877。POST /asp_data と /asp_referrer を受けて received.jsonl に記録。check には空を返す。複数接続対応済み）
- 設定ファイル：_demo/.env_asp（中田が配置、clean で削除）

本流（移行ブランチ） - 発生額：/Users/nakatafumito/dev/htdocs/plus_asp_data_get_test/asp_data_get/（ブランチ agent/selenium4-migration、先頭 4232a7b）
- リファラー：/Users/nakatafumito/dev/htdocs/plus_asp_data_get_test/asp_referrer/（ブランチ agent/selenium4-migration、先頭 964913f）
- Python：asp_data_get/venv/bin/python3（Selenium 4.47）

3. 中田と決めた運用ルール（守ること）

• 本番の受け先には送らない。送信先は必ずモックに向ける
• デモは「本流のコピーに一時停止を差し込むだけ」。差し込んだ行には末尾に「# (demo)」を付ける。例外は、ヘッドレス指定を「通常は画面表示、DEMO_HEADLESS=1 のときだけヘッドレス」に変える1か所のみ（中田承認済み）
• デモを作ったら、必ず本流との diff を取り、一時停止以外の差分がヘッドレス指定だけであることを確かめる。構文チェックもする
• 一時停止は、元のスクリプトの print の後に差し込む（前に入れると表示順がずれる）
• デモの実行は中田が行う。AIは準備・差分確認・記録を行い、ASPへのログインを自分で実行しない
• 設定ファイルの配置と削除は中田が行う。AIは中身の値を表示しない
• 本流の修正は、中田の承認を得てから行う。コミット・push は中田の指示があるまでしない
• 時刻：6:00〜9:44 は現行サーバーの cron が同じアカウントにログインする。当日の取得が済んでいれば、中田の判断で前倒しできる
• JANet は Chrome のポートが 9222 固定のため、1本ずつ実行する
• 中田への報告では、ファイルは必ずフルパスで書く。中田がやることは1行で簡潔に書く
• 記録ページは JavaScript が動かない表示でも見えるよう、描画結果をHTMLに焼き込む（手順は「6.」）

4. 再開の手順

1. 中田が /Users/nakatafumito/dev/htdocs/plus_asp_data_get_test/_demo/.env_asp を置く
2. AIが設定ファイルを書き換える（値は表示しない）
   
   • ASP_DATA_API_URL の行をコメントアウトして残し、ASP_DATA_API_URL='http://127.0.0.1:8877/asp_data'
     を追加
   • SUPPORT_MAIL の行をコメントアウトして残し、SUPPORT_MAIL を中田のアドレス（contractor.nakata@plus-company.jp）に変更
   • 権限を 600 にする
   • _demo で ../asp_data_get/venv/bin/python3 -c "from _lib_env import env; print(env('ASP_DATA_API_URL'), env('SUPPORT_MAIL'))" を実行し、モックと中田のアドレスが読めることを確かめる
3. ./run_demo.sh mock でモックを起動し、http://127.0.0.1:8877/
   が 200 を返すことを確かめる
4. 本流のディレクトリ（asp_data_get / asp_referrer / その親）に .env_asp が無いことを確かめる

5. 新しい対象のデモを作る手順

1. 本流のスクリプトを全文読む。check の送信、ログイン、取得、送信（insert / update）、エラーメールの位置と条件を特定する
2. demo/demo<対象>_data_get.py として、本流をコピーし次の位置に差し込む
   
   • import の後：from _pause import step, show
   • check の送信前：step「0. 受け先へ取得済みか確認」、デコード後：show「check 応答」
   • ログイン前：step「1. ログイン」、ボタンを押した後：step「1. ログイン完了」
   • レポート画面の後：step「2. …の表示」
   • 取得値が決まった後：show「取得値」と step「2. データ取得完了」
   • 送信前：show「送信JSON」と step「3. 送信」、送信後：show「受け先の応答」と step「4. 反映」
   • エラーメール送信前：step「エラー通知」
3. 差し込みは文字列が1回だけ現れることを確かめてから置換する。既存ファイルは上書きしない
4. diff と構文チェックを行う
5. run_demo.sh の data_get の case に対象名を追加する
6. 記録ページに「作成済」とコードから読み取った注意点を書く

6. 記録ページの更新手順（焼き込み）

1. 01_asp_data_get.html の script 内の CFG.rows で、該当行に pre:{demo, time, s0〜s4, val, cnt, memo} を書く。実施前チェックは verified JSON（script id="verified"）に state・by・at・note・summary・owner・todo を書く
2. python3 /Users/nakatafumito/Workspace/20260914/asp-server-migration/_tools/bake_server.py をバックグラウンドで起動
3. ブラウザで http://127.0.0.1:8799/01_asp_data_get.html
   を開き、localStorage を消して再読み込みし、JS で {name:'01_asp_data_get.html', bar: .bar の outerHTML, wrap: .wrap の outerHTML} を POST /save する
4. python3 /Users/nakatafumito/Workspace/20260914/asp-server-migration/_tools/bake_apply.py 01_asp_data_get.html で差し込む
5. 8799 のサーバーを止め、当月アーカイブの同じパスへ PUT して、サイズが一致することを読み戻す

- 注意：焼き込み後のHTMLは、ボタン属性が data-copy="" の形になっている。文字列置換のときはこの形に合わせる

7. 未コミットの変更

今回（9/15）行ったもの - asp_data_get/slnm_afib.py：ログインボタンを見えている方から選ぶ1行
- asp_referrer/data-organizing_afiB_plus0501_referrer_get.py：同じ1行

今回の作業ではない変更（中身未確認） - asp_referrer の A8 5本（plus02・plus03・plus0501・plusAD・stormAD）が変更済み
- 未追跡：asp_data_get の _btlr_fetch.py・slnm_a8_6.py・slnm_gladone.py・slnm_nahato.py・slnm_organicgroup.py、asp_referrer の _btlr_referrer.py・A8 plusAD02・gladone・nahato・organicgroup

8. 残作業（優先順）

1. Lacoco を再開するか決める
   • 対応表 lacoco_sales_tb の用意の仕方を、A（モックが本番から表だけ読んで返す）か B（空の表を返す）から中田に選んでもらう
   • モック側だけを変更し、Lacoco の本流とデモの一時停止には手を入れない
2. afiB の修正をコミットするか決める：中田の判断待ち
3. リファラー側の確認に入る
   • 使うページ：02_asp_referrer.html
   • 設定ファイルには ASP_REFERRER_API_URL と ASP_REFERRER_API_KEY が必要。今の発生額用の設定ファイルには入っていないため、中田に用意してもらう
   • ASP_REFERRER_API_URL は http://127.0.0.1:8877/asp_referrer
     に書き換える
   • デモはまだ A8 plus0501 の1本だけ。発生額と同じ手順で1本ずつ作る
   • 本番のリファラー実行はシェル data-organizing_asp_referrer_get.sh が 6:00 に順に呼ぶ。TGaffi は本番シェルでコメントアウトされている
4. 契約後サーバー作業の設計ページを作る：8/18 のコメント（サーバ契約後の作業 A〜H）が材料

9/15 の作業のまとめです。発生額（asp_data_get）の4工程確認を、保留の Lacoco を除く13本で完了しました。本番の受け先には1件も送っていません。

1. 発生額の確認結果（9/14分）

• 確認方法：本流スクリプトのコピーに工程ごとの一時停止を差し込んだデモを、中田が1本ずつ実行し、ログイン・取得・送信・反映を目で確認した
• 送信先は手元のモック受け先。13本すべてがモックの受信ログに届いたことを確認した
• 記録ページ：/Users/nakatafumito/Workspace/20260914/asp-server-migration/01_asp_data_get.html

2. 見つけて直した不具合

afiB のログインボタンの選び方（移行ブランチ） - 8/24 の改修で、ID欄とパスワード欄は「見えている方」を選ぶように直されていたが、ログインボタンだけは1つ目（非表示・別フォーム）を掴んでいた
- そのためログインボタンを押せず、Err になっていた
- ボタンも「見えている方」を選ぶ1行に修正。発生額とリファラーの2本とも同じ不具合があったため両方を修正した
- 修正前の実行で、モックに Err を2回送り、エラーメール（宛先は中田）も送信している
- 修正はまだコミットしていない

3. デモ環境で行った変更（本流には影響なし）

• デモ用の設定ファイルで、送信先をモックに、エラーメールの宛先を中田に変更（本番の行はコメントアウトで残した）
• モック受け先を、ブラウザが接続を保持しても止まらない形に修正。起動し直しても受信ログを消さないようにした
• btlr系3本（OrganicGroup・Gladone・Nahato）が使う共通の補助ファイルは、デモ用のコピーを作って一時停止を差し込んだ

4. 本流で見つかった注意点（移行後の課題候補）

いずれもコードから読み取った事実で、実際に起きたことは確認していない。

• AccessTrade：金額を読めないと0円のまま送る。エラーメールの条件が成立せず送られない。前回 Err でも update でなく insert を送る
• JANet 5本：失敗への備えが無く、途中で失敗すると Err もエラーメールも送らずに止まる。CSVが見つからないと0円のまま送る。Chrome のポートが 9222 固定で同時に2本動かせない
• btlr系3本：CSVが見つからないと0円扱い。報酬額に円記号が付くと合計に足されない（合成CSVで確認）
• Lacoco：エラーメールが送られない。失敗しても Err を送らず止まる
• TGaffi：エラーメール本文の改行が「\n」の文字のまま入る

5. Lacoco を保留にした理由

Lacoco は報酬を計算するための対応表（lacoco_sales_tb）を、最初に受け先から取得する。モックはこの表を返せないため、デモが途中で落ちる。対応案は次の2つで、どちらにするかは未決。

• A. モックが対応表の問い合わせだけを本番から読み取って返す
• B. モックが空の表を返す（金額は必ず0円になる）

6. 次のステップ

1. 片付け（受信ログ・CSV・設定ファイルの削除、モック停止）。中田が clean を実行する
2. afiB のログインボタン修正をコミットするか判断する
3. Lacoco の対応表の用意の仕方を A・B から決め、発生額を14本そろえる
4. リファラー側（asp_referrer）の確認に入る。リファラー用の設定ファイル（送信先 ASP_REFERRER_API_URL を含む）の準備から始める
5. 契約後サーバー作業の設計ページを作る（未着手）

9/14〜9/15 の進捗と、次のステップをまとめます。確認作業そのもの（ASPへのログインを伴うデモの実行）は、まだ1本も行っていません。現時点は、実行前の準備と安全確認が終わった段階です。

1. 手順書兼記録ページ（作成済み）

9/14 の予定コメントでは置き場所を plus_ai_report としていましたが、中田の指示でローカルのHTMLに変更しました。発生額とリファラーで工程が違うため、1枚ずつに分けています。

• 中身は、概要、工程、実施前チェック、1本ごとの手順、記録表、異常の記録、片付け、Markdown書き出し
• 対象は、発生額が10社14本、リファラーが9社13本。A8の残りアカウント（発生額5本、リファラー4本）はチェックリスト外のため既定で対象外とし、画面で切り替えられる
• 確認済みの結果は、確認者・時刻・根拠つきでHTML本文に書き込んでいる。JavaScriptが動かない画面でも同じ表示になる
• PC幅・スマホ幅での表示崩れなし、コンソールエラーなしを確認済み

2. 実施前チェックの状況（発生額側）

3. 実行前の確認で分かったこと

• 設定ファイルの送信先が本番を向いていた。 中田が配置した設定ファイルの発生額の送信先は、本番の受け先でした。このままデモを実行すると本番に登録されるため、実行を止めました。
• 全20本に、本番のエラーメール送信先が直接書かれている。 設定ファイルの送信先を変えても、エラーメールは本番のメール送信の仕組みを通ってサポート宛てに届きます。
• 送信の条件はスクリプトで違う。 多くは取得値が「Err」のときだけ送ります。SLVRBULLETは途中で何か例外が起きると必ず送ります。JANetの4本は条件をまだ読めていません。
• GitHubに無いスクリプトがある。 Gladone、Nahato、OrganicGroup、A8の6本目と、前3本が使う補助ファイルは、ローカルにしかありません。8/27に現行サーバーから取得した分と思われます。
• A8のデモは、一時停止の差し込みに加えてヘッドレス指定が本流と違う。 画面を表示して動く作りになっています。
• この設定ファイルにはリファラーの送信先が無い。 発生額用の設定ファイルのため、リファラー側を確認するときは別に用意が必要です。

4. 中田の判断（9/15）

• GitHubに無い3本は、ローカル版を本流として確認に使う
• デモは画面を表示して確認する。ヘッドレス指定の差分は許容する
• 送信先をモックへ書き換える。元の行はコメントアウトで残し、戻せるようにする
• エラーメールは、宛先を中田に変えて受け取る

5. 実施した変更（9/15）

• デモ用フォルダの設定ファイルで、発生額の送信先をモック（127.0.0.1:8877）に変更。本番の行はコメントアウトで残し、戻し方を書いた
• デモが実際に読み込む値がモックであることを確認
• 設定ファイルの権限を 600 に変更（8/18 の方針どおり）
• 本流のスクリプトとGitHubのリポジトリには手を入れていない

6. 次のステップ

中田の対応 1. エラーメールの宛先にするメールアドレスを伝える
2. 9:45 を過ぎてから開始する

その後の進め方 1. 設定ファイルのエラーメール宛先を中田に変える（元の行はコメントアウトで残す）
2. SLVRBULLET（発生額）のデモを作る。本流をコピーし、一時停止だけを差し込む
3. 本流との差分が、一時停止の差し込みと画面表示だけであることを確認する
4. デモを実行し、⓪確認・①ログイン・②取得・③送信・④反映を1工程ずつ見て、記録ページに書く
5. 1社1アカウントのASP（AccessTrade、afiB、Felmat、Lacoco、TGaffi、OrganicGroup、Gladone、Nahato）を同じ手順で進める
6. JANet の5本をまとめて進める。残り4本のエラーメール条件は、デモ作成時に読む
7. 発生額が終わったら、リファラー側に移る。リファラー用の設定ファイルの用意から始める
8. 全件終了後に片付け（受信ログ・CSV・設定ファイルの削除、モック停止）を行い、記録ページの書き出しをこのタスクにコメントする

まだ着手していないもの - 契約後サーバー作業の設計ページ

本日は3件を進めます。9/10に予定していた作業の持ち越しです。

1. 手順書兼記録ページの作成
2. そのページを使った4工程デモの確認（発生額・リファラーの残りASP）
3. 契約後サーバー作業の設計ページの作成

時間割

現行サーバーのcronが6:00〜9:44に同じASPアカウントへログインするため、この時間帯はASPへのログインを行いません。同時ログインで片方が弾かれるためです。

作業1: 手順書兼記録ページ

目的

9/8にA8 plus0501で行った「ログイン → 取得 → 送信 → 反映」の確認を、残りのASPでも同じ手順・同じ観点で行い、結果を1か所に残します。手順と記録を別々にすると、どの手順で確認した結果なのかが追えなくなるため、1ページにまとめます。

置き場所

plus_ai_report に新規ページとして作成します。移行レポート（id=3）とは分け、確認作業の記録専用とします。

ページ構成

1. 目的と対象範囲
2. 本番を汚さない仕組み（下記「安全策」）
3. 共通手順（モック起動 → 実行 → 確認 → 片付け）
4. ASP別の記録表
5. 異常があった場合の記録欄（事象・画面・原因の見立て・次の対応）

記録表の項目

認証情報（ID・パスワード・APIキー）はページに一切書きません。

作業2: 4工程デモの確認

現状の仕組み（9/8作成・実在確認済み）

場所: /Users/nakatafumito/dev/htdocs/plus_asp_data_get_test/_demo/

• 本流スクリプトのコピーに「工程ごとに止まる処理」だけを差し込んだもの。本流には手を入れていない
• 送信先は設定の2行だけを手元のモック受け先（127.0.0.1:8877）に向ける。ログインと取得は本物のASPで動く
• 実行は run_demo.sh（mock / data_get / referrer / stop / clean）
• 現状はA8 plus0501専用の2本のみ

設計: 対象ASPへの拡張

• 対象スクリプトごとに、本流のコピーへ同じ位置（①ログイン ②取得 ③送信 ④反映）で一時停止を差し込む
• ログイン動線は各社で異なるため、差し込み位置は1本ずつ本流を読んで決める。まとめて機械的に差し込まない
• run_demo.sh に対象指定を追加する（例: ./run_demo.sh data_get felma）
• 本流との差分が「一時停止の差し込みだけ」であることを diff で確認してから実行する

対象（チェックリスト記載のASP）

発生額: 10社・14本

リファラー: 9社・13本

実施順

1. SLVRBULLET（Chromeを使わないため、モック・送信経路の疎通確認を兼ねる）
2. 1社1アカウントのASP（AccessTrade、afiB、Felmat、Lacoco、TGaffi、OrganicGroup、Gladone、Nahato）
3. JANet 5本（同じASPで複数アカウントのため最後にまとめる）

発生額を先に全社終え、その後リファラーに移ります。

手順（1本ごと）

1. 実行前: 本流との差分を確認し、実施時刻が9:45以降であることを確認
2. ./run_demo.sh mock でモック受け先を起動し、ブラウザで一覧画面を開く
3. 対象のデモを実行し、①〜④を1工程ずつ画面とターミナルで確認
4. 各工程の結果を記録ページに記入
5. 異常があれば、その場で先に進めず記録欄に残す
6. 全件終了後に ./run_demo.sh clean で受信ログ・CSV・認証情報を削除

安全策（本番を汚さない）

• 送信先はモック受け先のみ。本番（plus-creative.xyz / data-organizing.com）には1件も送らない
• 本流のディレクトリには認証情報を置かない。誤って本流を実行しても本番へ送れない状態を維持する
• 認証情報はデモ用フォルダにのみ一時配置し、作業終了時に必ず削除する
• 現行cronの時間帯（6:00〜9:44）は実行しない

確認が必要な点

• A8の残りアカウント（発生額5本・リファラー4本）はチェックリストの対象に含まれていません。今回は対象外として進め、含めるかは別途判断します
• 9/8のコメントでは残り本数を「発生額15本・リファラー14本」としていましたが、スクリプトの実数と一致しません。本日の記録ページではスクリプト単位の実数で管理します

作業3: 契約後サーバー作業の設計ページ

目的

空のサーバーとSSH接続用のアカウントだけを渡された状態から、1段ずつ実行と確認を繰り返して、自動実行の登録まで到達できる手順ページを作ります。作業を中断・引き継ぎしても、どこまで終わったかが分かる形にします。

置き場所

plus_ai_report に新規ページとして作成します。

前提

• ConoHa VPS 2GBプラン、Ubuntu 24.04 LTS（8/18指示書の推奨値）
• 渡されるのは空のサーバー、IPアドレス、初期ログイン手段のみ
• スクリプトは「Selenium 4対応 + 設置場所非依存化」のブランチ（agent/selenium4-migration）を使う

ページ構成

8/18に投稿したA〜Hの工程を土台に、各段を次の4点セットで書き直します。

段の並び

1. 初期ログインと現状確認
2. タイムゾーン・日本語ロケール・フォント
3. 作業用ユーザー作成とsudo付与
4. SSH鍵認証の設定
5. SSHポート変更（ssh.socket側の変更を含む。別ターミナルで新ポート接続を確認してから既存セッションを閉じる）
6. ファイアウォールとfail2ban
7. Python・Chromeなど実行環境のインストールと最小動作確認
8. スクリプト配置と設定ファイル（権限600）
9. 発生額・リファラーを1本ずつ手動実行して確認
10. cron登録と初回自動実行の立ち会い
11. 新旧並行稼働と突合、切替判断

締め出しの危険がある4〜6は、それぞれ独立した段にして「確認してから次へ」を必須にします。

ページ冒頭に置く未決事項（8/18指示書 §8）

• ASP管理画面のIP制限の有無
• 通知先（メール・Slack）を現行のまま使うか
• data-organizing.com の扱い
• バックアップオプションの有無
• 移行の希望時期

本日の完了条件

• 手順書兼記録ページが作成され、確認結果が記入されている
• 発生額・リファラーの対象スクリプトについて、実施済み・未実施・異常ありが記録ページ上で区別できる
• 作業終了時に認証情報・受信ログ・CSVが削除されている
• 契約後サーバー作業の設計ページが作成されている

本日は、改修後のスクリプトが実際にどう動くかを、依頼者（中田）自身がターミナルとブラウザで1工程ずつ目視確認しました。

確認した内容

対象はA8のplus0501アカウントで、発生額取得とリファラー取得の両方です。以下の4工程を、工程ごとに一時停止しながら確認しました。

1. ログイン: Chromeの画面を表示した状態でA8にログインし、レポート画面に到達する
2. データ取得: 発生額は前日（9/7）の行から報酬額を読み取り、リファラーは成果発生レポートとコンバージョンリファラレポートの2つのCSVをダウンロードして読み込む
3. データ送信: 受け先へ送るJSONの中身を表示したうえでPOSTする
4. データ反映: 受け先の一覧画面に登録されたことを確認する

結果は、発生額が1,024,940円（9/7分）で1件、リファラーが21件（すべて9/7のCV）で、いずれも正しく送信・反映されました。リファラー側は8/27に修正した日付指定（プルダウン方式）が有効に働き、前日分だけが正しく取れています。

本番データを汚さないための措置

送信先の受け先には本番（plus-creative.xyz / data-organizing.com）ではなく、手元に用意した模擬の受け先を使いました。設定ファイルの送信先URL2行だけを差し替えており、ログインとデータ取得は本物のASPで動いています。したがって本番の受け先には1件も送っていません。

本流スクリプトには一切手を入れていません。実演に使ったのは本流のコピーに「工程ごとに止まる処理」を差し込んだもので、差分はその差し込みだけです。本流のディレクトリには認証情報を置いていないため、誤って本流を実行しても本番へは送れない状態にしています。実演終了後、認証情報は削除済みです。

現在の状況

サーバーは未契約です。契約前に確認できることは、これで一通り完了しました。

次回（9/10）の予定

第一に、同じ4工程の確認を他のASPでも行います。発生額側は残り15本、リファラー側は残り14本が対象です。

第二に、契約後のサーバー作業の設計です。空のサーバーとSSH接続用のアカウントだけを渡される前提で、最低限のセキュリティ設定（鍵認証・ポート変更・ファイアウォール）、実行環境のインストール、スクリプトの配置、自動実行の登録までを、1つ1つ確認しながら進められる作業手順ページを作成します。

【進捗】
移行対象39本の確認が完了し、ブラウザ系37本中35本はログイン・レポート画面到達まで確認済みです。現行サーバーには手を加えておらず、日次取得は従来どおり稼働しています。

【本日の作業】
- GitHub未登録の8本と共通モジュール2本を、現行サーバーから安全に再取得
- 認証情報を除外したうえで、コードと検証結果を整理
- 未登録8本をGitHubへ正式登録するための準備
- A8 stormADを今後も取得対象に残すか、対象外にするか確認
- タスクの進捗・チェックリストを現在の状況に更新
- 新サーバー契約状況を確認し、契約済みの場合は構築作業へ着手

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

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. 移行の希望時期。 月初・月末はデータ確認の負荷が高いため、月の中旬に切り替え日を置くことを推奨します。