lacoco 実測結果と修正内容 (2026-07-28) ※チェックリスト #2135

ConoHa 上で DRY_RUN=1 (= API へ書き込まない) で実走し、原因を確定した。

実測でわかったこと

サーバ環境は python 3.6.8 / selenium 3.141.0 / pandas 1.1.4 / Chrome 86。
前回コメントで挙げた「Selenium 4 で旧 API が削除されている」という推測は誤りだった。selenium は 3 系のままで、find_element_by_* は正常に動く。

ログイン → 日付入力 → CSV ダウンロードまでは両スクリプトとも完全に成功していた。不動作の原因はスクレイピングではなく、ダウンロード後のデータ処理側にあった。

原因1: 成果 0 件の日に異常終了する (slnm_lacoco.py)

ラココの CSV は成果が 0 件の日でも、中身が空のダミー行を 1 行返す。この行の「リンク」列が NaN (float) になり、link_name in data['link_name'] が TypeError: 'in ' requires string as left operand, not float で落ちる。本番コードはこの集計処理が try の外にあるため、そのまま異常終了して報酬が登録されない。

管理画面で確認したところ、ラココの成果は 2026-04-19 を最後に発生していない。つまり 04-20 以降は毎日この経路で落ちていた。

原因2: 成果があった日も報酬 0 円で登録されていた (slnm_lacoco.py)

成果のあった 2026-04-19 を TARGET_DATE 指定で再取得したところ、CSV は正常に取得でき型エラーも 0 件だったが、報酬額は 0 のままだった。

CSV のリンク名 : 美容器CP_水着ピンク脱毛完全ガイド (https://xn--eckp2g630n3ukyzxne8a.com/)

単価表のリンク名 : 美容器CP脱毛完全ガイド (https://xn--eckp2g630n3ukyzxne8a.com/)

「水着ピンク_」が入った新しいリンク名が単価表に無いため照合が成立しない。旧コードは照合できなかった行を黙って素通りする作りで、警告も出ないまま報酬 0 円として登録される。成果は発生しているのに金額が計上されない状態だった。

原因3: エラー通知が一度も飛ばない仕組みだった

if insert_reward == "Err" は int と文字列の比較なので条件が常に False。原因1・原因2 のどちらが起きても通知されず、気づけない構造になっていた。

マスタ (単価表) と照らし合わせる仕組み

ラココの CSV の「金額」列は実額ではなく常に 1 が入っている。そのため実際の報酬額は、成果が発生した LP のリンク名をキーに単価表を引いて算出する設計になっている。

• 単価表の実体: asp_data 側の lacoco_sales_tb。API の action は lacoco_sales_tb
• 保持している項目: link_name (リンク名) / category (listingSite・halfPrice・etc) / price (単価)
• 現在の登録は 6 件
  
  • 美容器CP_サロンリスト(https://salon-list.net/)
    : listingSite / 48000
  • 美容器CP_脱毛完全ガイド (https://xn--eckp2g630n3ukyzxne8a.com/)
    : listingSite / 48000
  • 半額オファー_脱毛完全ガイド (https://xn--eckp2g630n3ukyzxne8a.com/)
    : halfPrice / 24000
  • 美容器CP_エピリノ(http://epilino.jp/)
    : etc / 42000
  • 美容器CP_エキサイトエピ(https://datsumo.excite.co.jp/)
    : etc / 42000
  • 2023年冬LP_サロンリスト(https://salon-list.net/)
    : listingSite / 48000
• 照合方法: CSV の 15 列目「リンク」の値が、単価表の link_name に部分一致で含まれるかを見る。当たった 1 件の price を報酬に加算し、category ごとの件数を数える
• 新しい LP が追加されると単価表に無いリンク名が発生し、そのままでは報酬が計上されない。単価とカテゴリは PLUS 社側の取り決めなのでコードでは決められない

今回入れた修正

slnm_lacoco.py
1. 空行・NaN を集計対象から除外。成果 0 件の日は報酬 0 で正常終了するようにした (原因1 の解消)
2. 照合ループの向きを「成果行ごとに単価表を引く」形に是正。旧コードは 単価表 x 成果行 の二重ループで、1 行が複数の単価表項目に当たると多重加算する構造だった。当たった最初の 1 件で確定させる
3. halfPrice の二重加算を解消。旧コードは halfPrice の分岐で price を足したうえ、直後の共通処理でも price を足しており、報酬額が過大になっていた。加算は 1 行につき 1 回だけにした
4. 単価表に無いリンク名を unmatched として記録し、ログに STEP7-UNMATCH として出力するようにした (原因2 の可視化)
5. エラー通知の条件を修正。常に False だった insert_reward == "Err" をやめ、単価表に無いリンク名を検出したときに通知を送る形にした。件名と本文に該当リンク名を列挙する (原因3 の解消)

data-organizing_lacoco_pluslacoco_referrer_get.py
6. 列数チェックの閾値を 13 から 16 に是正。参照する最大列が row[15] なのに 13 列で通しており、13〜15 列の行が IndexError になる状態だった
7. 空行スキップを追加。管理ID とクリック日時がどちらも空の行は成果行ではないと判定して弾く。旧コードはこれを弾かず、成果 0 件の日に全項目が空のレコードを毎日 API へ登録していた

なお referrer 側は 2026-04-19 のデータ取得自体は正常で、クリック日時・成果日時・リンク・リファラ・ステータスがすべて正しく取れることを確認済み。

残っている判断事項

• 単価表への新リンク名の登録。美容器CP_水着ピンク_脱毛完全ガイド の単価とカテゴリが決まり次第、lacoco_sales_tb へ追加する。指示があり次第対応する
• 過去分の計上漏れ。管理画面の成果一覧は大半がこのリンク名のため、2026-04-19 より前にも報酬 0 円で登録されている可能性がある。遡って突合するかどうか
• 現在サーバ上の 2 ファイルはデバッグ版 (DRY_RUN 既定で登録しない) のままなので、cron が動いても登録されない。本番運用に戻すタイミングの決定が必要

slnm_lacoco.py デバッグ版 作成 (2026-07-28) ※チェックリスト #2135 関連

対象: asp_data_get/slnm_lacoco.py (lacoco 日別報酬の取得)
referrer 側と同方針。本番データを書き換えずに、どの工程で落ちているか / 報酬額がどう積算されているかを実測する。ファイル名は本番と同名のまま (原本は bak/ に退避済)。

安全装置

1. DRY_RUN=1 が既定。insert API とエラーメール送信を行わず、送信予定 JSON をログ出力するだけ。読み取り系 (lacoco_sales_tb / check) は実行する。
2. CSV ダウンロード先を本番の /var/www/html/asp_data_get/Downloads から /tmp/slnm_lacoco_debug/download/ に分離。本番の残骸 CSV を読まない・消さない。
3. 例外を握り潰さず traceback 全文を出力。CSV 取得〜集計も try の内側へ。
4. 取得した CSV は削除せず /tmp/slnm_lacoco_debug/ に保管。
5. FORCE_SCRAPE=1 を付ければ「既にデータ取得済み」でもスクレイピング工程を追える。

デバッグ出力内容

工程ごとに [STEP0]〜[STEP9] のタグ付きログを標準出力 + /tmp/slnm_lacoco_debug/run_<日時>.log へ出力。

• ENV: python / selenium / pandas / chromedriver_binary のバージョン、.env_asp から ID・PW・API-KEY・API-URL が取得できているか (値は出さず set / EMPTY のみ)
• STEP0 判別マスタ: lacoco_sales_tb の HTTP ステータス、件数、全レコードの link_name / category / price と各型
• STEP0b 取得済み判定: check の HTTP ステータスとレスポンス本文、scr_flg の決定理由
• STEP1 ブラウザ起動: Chrome / chromedriver バージョン
• STEP2 ログイン: 遷移前後の URL / title、#id / #pass / #login_bt の発見可否
• STEP3 レポートページ遷移: PEPORT_PAGE の設定有無
• STEP4 日付入力: #start_date / #end_date の発見可否と入力値
• STEP5 CSV ダウンロード: #dlbt の発見可否、DL 完了待ち (最大30秒監視)、落ちたファイル名。失敗時はディレクトリ内容を列挙
• STEP6 CSV 読取: ファイルサイズ、pandas の shape と列名一覧、iloc[:,14] の列名 / dtype / NaN 件数、link_name の全値と型
• STEP7 報酬集計: 型不一致の検出、マッチした行の link_name / category / price と累計 reward、最終 insert_reward と category_count
• STEP8 登録 API: DRY_RUN 時は送信予定 JSON、実送信時は HTTP ステータスとレスポンス
• STEP9 エラーメール: 送信条件の判定結果
• 各工程でスクリーンショット (.png) と page_source (.html) を保存。例外時は 99_exception

実行コマンド (ConoHa)

DRY_RUN=1 python3 /var/www/html/asp_data_get/slnm_lacoco.py
DRY_RUN=1 FORCE_SCRAPE=1 python3 /var/www/html/asp_data_get/slnm_lacoco.py

コード読解で判明した不具合 (実測前 / 要検証・要修正)

1. 既知の TypeError (旧 line 178) の原因は型不一致。CSV の link_name が NaN (float) の場合や、マスタ側 link_name が非文字列の場合に link_name in data['link_name'] が TypeError: 'in ' requires string as left operand, not float になる。デバッグ版では該当行を STEP7-TYPE として型つきで記録し、処理は継続する。
2. halfPrice の報酬が二重加算されている。category == halfPrice のとき halfPrice の price を足したうえ、直後の共通行でも int(data['price']) を足している。報酬額が過大になる。
3. エラーメール通知が一度も飛ばない。insert_reward は int なのに if insert_reward == "Err" で文字列比較しており、条件が常に False。
4. CSV 未取得時に link_names が未定義のまま集計へ進み NameError になる。加えて本番は csv_files[0] を無条件に読むため、DL 失敗時に Downloads に残る別実行の残骸 CSV を掴むリスクがある。
5. find_element_by_css_selector / find_element_by_id は Selenium 4 で削除済み API。referrer 側と同じくサーバの selenium バージョン次第で即死する。デバッグ版は 3 / 4 両対応にしてバージョンをログ出力する。

次のアクション

referrer 版とあわせて ConoHa へ設置し DRY_RUN=1 で実走 → ログと画面キャプチャで原因を確定 → 上記 1〜5 の修正方針を決定。

lacoco referrer 不動作 調査方針 (2026-07-28)

対象: data-organizing_lacoco_pluslacoco_referrer_get.py
本番へデータを送らずに、どの工程で落ちているかを実測するデバッグ版を作成。ファイル名は本番と同名のまま (差し替えて実行 / 原本は bak/ に退避済)。

安全装置 (= 本番データを汚さない)

1. DRY_RUN=1 が既定。API へ POST せず、送信予定 JSON をログ出力するだけ。実送信は DRY_RUN=0 を明示したときのみ。
2. CSV ダウンロード先を本番の /var/www/html/referrer_get/ から /tmp/lacoco_debug/download/ に分離。本番 CSV を読まない・消さない。
3. 例外を握り潰さず traceback 全文を出力。CSV 処理を try の内側へ移動。
4. 取得した CSV は削除せず /tmp/lacoco_debug/ に保管。

デバッグ出力内容

工程ごとに [STEP1]〜[STEP7] のタグ付きログを標準出力 + /tmp/lacoco_debug/run_<日時>.log へ出力。

• ENV: python / selenium / chromedriver_binary の各バージョン、.env_asp から ID・PW・API-KEY・API-URL が取得できているか (値は出さず set / EMPTY のみ)
• STEP1 ブラウザ起動: Chrome バージョン、chromedriver バージョン
• STEP2 ログイン: 遷移前後の URL / title、#id / #pass / #login_bt の各要素の発見可否
• STEP3 レポートページ遷移: PEPORT_PAGE の設定有無と遷移後 URL
• STEP4 日付入力: #start_date / #end_date の発見可否、入力した日付
• STEP5 CSV ダウンロード: #dlbt の発見可否、DL 完了待ち (.crdownload 消滅を最大30秒監視)、落ちたファイル名。失敗時はディレクトリ内容を列挙
• STEP6 CSV データ取得: ファイルサイズ、ヘッダーの列数と中身、データ行数、行ごとの列数不足・IndexError
• STEP7 API 送信: DRY_RUN 時は送信予定 JSON 全文、実送信時は HTTP ステータスとレスポンス。最後に sent / skipped 件数
• 各工程でスクリーンショット (.png) と page_source (.html) を /tmp/lacoco_debug/ に保存。例外時も 99_exception として保存

実行コマンド (ConoHa)

DRY_RUN=1 python3 /var/www/html/asp_referrer/data-organizing_lacoco_pluslacoco_referrer_get.py

実測前に判明している疑い (要検証)

1. find_element_by_css_selector() は Selenium 4 で削除済み API。サーバの selenium が 4 系なら、ログイン処理が全て AttributeError で即死し、except の print だけで終わる。不動作の第一容疑者。デバッグ版は Selenium 3 / 4 の両対応にしてバージョンをログ出力する。
2. 本番コードは CSV 処理が try / except の外にある。ログインが失敗して CSV が取れなくても、ダウンロードフォルダに残っている他 ASP の最新 CSV を拾い、lacoco として API 送信してしまう構造。過去データ汚染の可能性あり。
3. PEPORT_PAGE が空でレポートページ遷移が未実装。ログイン直後のページで #start_date を触っている。
4. 行の列数チェックが len(row) >= 13 なのに row[14] / row[15] を参照。13〜15 列の行は IndexError になる。

次のアクション

デバッグ版を ConoHa へ設置し DRY_RUN=1 で実走 → ログと画面キャプチャで原因を確定 → 修正方針を決定。

python3 /var/www/html/asp_referrer/data-organizing_lacoco_pluslacoco_referrer_get.py

ソース確認ポイント
- ブラウザの起動
- ログイン
- レポートページ遷移
- CSVダウンロード
- CSVデータ取得
- データのAPI送信

現状反映未設定
/var/www/html/_asp_referrer
/var/www/html/_asp_data_get

タイミングを見てテスト確認後、
ディレクトリをリネームし反映

作業報告 (2026-05-11 〜 2026-05-12)

1. 認証情報の env 化 (= 全ハードコード除去)

asp_data_get / asp_referrer の両ディレクトリで、Python と shell のハードコード機密値を .env_asp に切出し。

• 対象: ASP の ID/PW (15 アカウント) / API キー / Basic 認証 / SUPPORT_MAIL / Mail シークレット / Slack Webhook / 未確定通知 API
• 仕組み: 同階層配置の .env_asp (chmod 600) を _lib_env.py の env() で読込。shell は set -a; . .env_asp; set +a で読込
• 書換量: asp_data_get 側 約 135 箇所 (ID/PW + URL + API-KEY + secret_key + Basic 認証 tuple) / asp_referrer 側 約 90 箇所 (ID/PW + URL + API-KEY + shell の USER/PASS/API_KEY/URL/Slack)
• 動作確認: ConoHa 本番に反映後、test_env_loader.py (= 副作用ゼロのローダーテスト) で 42/42 OK / cron 実走でも動作確認済

2. レポート (= 引き継ぎマニュアル) 更新

https://plus-creative.xyz/nakata/conoha_server_plus/report/

• リスク・改善点を更新: HIGH 2 件 + MEDIUM 2 件を DONE に変更 (= 4 件解消 / 残 MEDIUM 1 件 + LOW 3 件)
• アーキテクチャ / 運用手順 / トラブルシューティング を .env_asp 経路に整合
• スライド版 (slides.php) を大幅充実化: 9 枚 -> 18 枚 (= 統計 / フロー / リスト / 表形式を追加 / 音声バグも修正)

3. GitHub アップ完了

• https://github.com/PLUS-Company/asp_data_get
  (Private)
• https://github.com/PLUS-Company/asp_referrer
  (Private)
• README / .gitignore / .env_asp.example 整備済
• plus-nakata アカウントで commit / push (= 個人アカウントとは完全分離)
• チェックリスト #2159 (GitHub 管理設定) はこれで実質完了

4. 残課題 (= 引き継ぎ後の宿題)

• [M] 受け先 #2 (data-organizing.com) の SQL 直連結 -> プリペアドステートメント化
• [L] バックアップ / 未使用ファイルが運用ディレクトリ常駐 -> 退避推奨
• [L] cron #1 (asp_data_get.sh) はリトライなし
• [L] referrer_tb のカラム名 typo: daleted_flg
• 既存: slnm_lacoco.py の TypeError (line 178 / 型ガード未対応 / 別タスク #2135)
• 既存: Chromedriver 残留対策 Phase 2 (= a8 系 5 本 + felma + janet 5 本に try/finally + driver.quit() 水平展開 / 別タスク #2136)

ソースの整理をしてアップ。
https://github.com/PLUS-Company/asp_data_get

https://github.com/PLUS-Company/asp_referrer

→ファイル、ソース整理中

ファイル構成などが整ったら共有

使用しているソースをGitHubにアップし、そこで管理する設定に切り替える

1.現ソースのダウンロード
2.現ソースの整理(.envなど切り分け）
3.リポジトリ作成( asp_data_getとasp_referrerの2種)
4.ソースのアップ

https://plus-creative.xyz/nakata/conoha_server_plus/report/

00概要 / システム全体像
01アーキテクチャ
02サーバ環境（ConoHa VPS）
03受け先サイト環境（PHP / SQLite）
04cron 一覧（3 本）
05取得スクリプト #1: asp_data_get
06取得スクリプト #2: asp_referrer
07受け先サイト #1: ASPデータ（plus-creative.xyz）
08受け先サイト #2: ASP Referrer（data-organizing.com）
09データフロー / 連携先一覧
10運用・メンテナンス手順
11トラブルシューティング
12リスク・改善点
13アーカイブ ダウンロード
14ローカル取得状況

必要ライブラリ/ファイルの設置と構成を更にわかりやすく記述する

https://plus-creative.xyz/nakata/conoha_asp/report/index.php

以下conohaサーバーでPLUS社関連のcronです。
その関連ファイルを
/Users/nakatafumito/dev/htdocs/conoha_server_plus/conoha_data
にダウンロード。
利用していないバックアップや不要ファイルもあるため、実際に使用しているものを揃える。

またその内容について
/Users/nakatafumito/dev/htdocs/conoha_server_plus/reportにindex.phpで作成。

cron:
[nakata@160-251-6-246 ~]$ crontab -l
MAILTO=

https://plus-creative.xyz/nakata/conoha_asp/

https://plus-creative.xyz/nakata/asp_conoha_report/

引き継ぎ概要（明日の自分用 / 2026-04-29 時点）

前提読み: comment_id=1054（同タスク内）に「ファイル構成・ログ・直近実行結果・打ち手候補」を投稿済み。本コメントはその続編。

残留 Chromedriver 6本の原因（決定的）

ConoHa上の /var/www/html/asp_data_get/ 配下14スクリプトを driver.quit() / try-finally の有無で分類:

結論: driver.quit() を一度も呼んでいない a8 / a8_2 / a8_3 / a8_4 / felma の 5本 + 1（a8_5 想定）= 6本 が、観測された残留6本と数が一致。

バックアップ取得済み（2026-04-27）

• 場所: ConoHa /home/claude/asp_data_get_bak/20260427/
• 対象: 14本の slnm_*.py + asp_data_get.sh + _asp_data_get.sh + send_mail.py（19ファイル）
• 検証: 元ファイルとの md5 完全一致（diff 0）
• mtime/権限保持（cp -p）
• 取得失敗: slnm_a8_5.py のみ権限 -rw------- (600 / owner: nakata) で claude ユーザーから読めず未バックアップ

リストア手順（claude → nakata 権限が必要）:

ssh conoha

sudo -u nakata cp -p /home/claude/asp_data_get_bak/20260427/<filename> /var/www/html/asp_data_get/<filename>

明日の着手計画

リファレンスは slnm_tgafi.py（既に options=options + try/finally + driver.quit() の最適化済み形）。

修正対象（残留対策の本丸 = Phase 2）

• a8 / a8_2 / a8_3 / a8_4 / felma … driver.quit() 自体を未呼び出し
• janet / janet_200xxxx ×4 … driver.quit() あるが try/finally で囲っていない
• a8_5 … 権限600で要 sudo（明日最初に nakata 権限で参照）

1本ずつ行う統一パッチ

1. Options() 生成箇所に追加:
   
   • options.add_argument("--disable-dev-shm-usage")
   • options.add_argument("--disable-gpu")
   • options.add_argument("--window-size=1280,720")
2. webdriver.Chrome(chrome_options=options) → webdriver.Chrome(options=options) に統一
3. driver起動以降を try: ... finally: try: driver.quit() except Exception: pass で囲う

段取り（推奨）

1. slnm_a8.py から1本だけパッチ → ConoHa上で単体実行 → 成功 + プロセス残留なしを確認
2. OK なら残り a8_2/a8_3/a8_4/felma に水平展開
3. janet 系5本（既に options=options で disable-dev-shm 入りなのは janet_200xxxx）に try/finally 追加
4. a8_5.py は権限解放 → 同パターン適用
5. 全パッチ後、asp_data_get.sh 一括実行 → output.txt とプロセス残留チェック

残留検知の手順（コピペ可）

ssh conoha "ps aux | grep -E 'chrome|python.*slnm' | grep -v grep; echo '---'; free -h"

観察基盤の不在問題

output.txt は 毎回 rm -f → 上書き で履歴が残らない。Phase 2 着手前に asp_data_get.sh のリダイレクト先を output_$(date +%Y%m%d).txt 等にローテーション化するのが筋（comment_id=1054 の打ち手 C）。観察期間を要する Phase 2 効果検証のため先に整備するのが望ましい。

別件: lacoco の TypeError（未着手）

slnm_lacoco.py line 178:

TypeError: 'in <string>' requires string as left operand, not float

原因: lacoco_sales_datas の link_name に float 値が混入。

修正案（型ガード）:

if isinstance(data.get('link_name'), str) and link_name in data['link_name']:

これは Phase 1 のスコープ外として残されている案件。Phase 2 と独立して着手可能。

環境・前提のメモ

• サーバ: ConoHa VPS（ssh conoha で接続。User: claude / Port: 2122）
• 配置: /var/www/html/asp_data_get/（owner: nakata）
• ランナー: asp_data_get.sh が冒頭で pkill -f chromedriver → 14本順次実行 → send_mail.py
• ログ: output.txt（毎回上書き、履歴なし）
• 直近実行: 2026-04-27 07:47:51

投稿経緯のメモ（明日の自分のため）

lifework.link/task_manage への投稿は 必ず https://lifework.link/task_manage/api/?action=comment.create
+ role: admin で行う。HTML フォーム経由（/task_manage/detail/?id=XXX への POST）は class=user 扱いで「対応者 未読」になる事故がある（2026-04-27 / comment_id=1053 の誤投稿で確定）。memory に feedback として保存済み。

メモ

収集プログラム

asp_referrer:
/var/www/html/asp_referrer/data-organizing_asp_referrer_get.sh
[conohaVPS:160.251.6.246]
asp_data_get:
/var/www/html/asp_data_get/asp_data_get.sh
[conohaVPS:160.251.6.246]

表示サイト

asp_referrer:
https://data-organizing.com/

[sv16152.xserver.jp]

asp_data_get:
https://plus-creative.xyz/nakata/asp_data/

[plus-x9.xsrv.jp]

ファイル構成

• 配置: /var/www/html/asp_data_get/ (owner: nakata)
• ランナー: asp_data_get.sh — pkill chromedriver/chrome → 14本のslnm_*.pyを順次実行 → send_mail.py
• slnm_lacoco.py: Phase 1修正済み (4/23 更新)。try/finally + driver.quit() / --disable-dev-shm-usage / --disable-gpu / --window-size=1280,720 反映済み

ログの吐き方（重要）

• 出力先: /var/www/html/asp_data_get/output.txt の 1ファイル単独
• 動作: 毎回先頭で rm -f output.txt → { ... } >> output.txt 2>&1 で上書き
• 過去ログは残らない ← 「2〜3日運用観察」と言いつつ履歴がない構造
• 完了後に send_mail.py がメール送信
• 直近の実行: 2026-04-27 07:47:51

直近の実行結果（output.txt より）

• a8 / a8_2〜5 / felma / accesstrade / afib / janet / janet_200xxxx×4 / tgafi: 全て成功（cURL送信ID 12745〜12758）
• slnm_lacoco.py: TypeError 再発中

File "slnm_lacoco.py", line 178, in <module>

    if link_name in data['link_name']:

TypeError: 'in <string>' requires string as left operand, not float

chromedriver 残留プロセス（重大）

07:44 起動の chromedriver が 6本残っている:

nakata  812716/812798/812879/812963/813044/813127  chromedriver --port=...

swap 使用 170MB / 全体 mem 510MB available。

Phase 1 で driver.quit() を保証したのに残留している ← lacoco以外の13本がオプション/quit保証未対応のままだから。lacoco は14番目（最後）なので、6本残るのは a8 系/felma/janet 系の可能性が高い。

整理

次の打ち手の候補

• A: lacoco の TypeError を line 178 で修正（型ガード: if isinstance(data.get('link_name'), str) and link_name in data['link_name']:）
• B: Phase 2 に進めて残り13本へ try/finally + options を水平展開（残留プロセス本体の対策）
• C: ログをローテーション化（output_YYYYMMDD.txt にして N日保持）し、観察可能にする

個人的には C → A → B の順が筋がいい（観察基盤を先に作らないと B の効果検証ができない）。

現場作業記録（2026-04-23）

接続・権限

• claude ユーザー → /var/www/html/asp_data_get/ に書込権限なし（Permission denied）
• nakata ユーザーで直接ssh接続（秘密鍵: SERVER/key/conoha/20201011180445.pem）→ 書込権限確保

環境確認

ベースライン（作業開始時、前回07:47実行から3時間経過）

• Mem: 152MiB / 818MiB
• Swap: 177MiB / 2GiB
• chrome残留プロセス: 6個 ← 主犯の証拠。原因は a8系＋felmaの driver.close() のみ組

実施した変更（slnm_lacoco.py のみ）

1. 原本退避: /var/www/html/asp_data_get/_bak/20260423/slnm_lacoco.py.original に cp -a で保全
2. options に3行追加: --disable-dev-shm-usage / --disable-gpu / --window-size=1280,720
3. webdriver.Chrome(chrome_options=options) → webdriver.Chrome(options=options)
4. driverスコープを try: ... finally: driver.quit() で囲んで例外時quit保証
5. 旧 driver.quit()（単独行）は finally に移動したため削除
6. TypeError 箇所（lacoco_sales_datas の型不整合）は今回無改変。別タスク #2135 の担当
7. サイズ: 7,212 → 7,518 bytes / 構文チェック py_compile OK

単体実行検証（手動、本番 asp_data_get.sh とは独立）

=== BEFORE: chrome processes: 0 ===

=== RUN slnm_lacoco.py ===

データがないので、スクレイピングしてアップロードします

スクレイピングします

before

after

Traceback (most recent call last):

  File "slnm_lacoco.py", line 178, in <module>

    if link_name in data['link_name']:

TypeError: 'in <string>' requires string as left operand, not float

=== elapsed: 19s ===

=== AFTER RUN: chrome processes: 0 ===  ← 残留ゼロ確認

TypeError は既知（別タスク #2135）。ポイントは 例外時でも driver.quit() が finally で確実実行された点。旧コードでは L172 の TypeError 発生で L163 の単独 driver.quit() に到達せずプロセス残留していた。

Phase 2 判断: 保留（数日観察）

Phase 2（残り13本への一括適用）は lacoco の数日観察後に判断。

観察の観点

1. 翌朝07:40 cron実行後の chromeプロセス残留数（ベースライン 6 → 5 に減るはず）
2. swap消費量の推移（lacoco 1本修正だけでは劇的変化は期待しない、が傾向を見る）
3. lacoco の取得結果自体（TypeErrorは既知、driver操作までは正常完了するはずなので CSV DL は走る想定）
4. 新オプション3種（dev-shm/gpu/window-size）による副作用の有無

チェック方法（翌朝以降、随時）

# 07:50 以降に確認

ssh conoha "ps -ef | grep -c chrome; free -h; tail -30 /var/www/html/asp_data_get/output.txt"

判断基準

• 残留プロセス 6 → 5 に減っていれば Phase 2 GO
• 同数のままなら他要因の可能性を再調査（例: chromedriver プロセスだけ残るパターン vs chrome 本体も残るパターン）
• 副作用があれば rollback: cp _bak/20260423/slnm_lacoco.py.original ./slnm_lacoco.py

再開トリガ

2〜3日運用観察 → 中田側から Phase 2 の GO/NO-GO を投げてもらう。

修正箇所を特定。lacocoは既に driver.quit() が存在するので（L163）、主な改善は以下4点:

1. L94-96 の options に --disable-dev-shm-usage, --disable-gpu, --window-size=1280,720 を追加
2. L107 chrome_options=options → options=options（selenium 3.141/ChromeDriver 86 両方で動作）
3. driverスコープを try/finally で囲み、例外時にも driver.quit() を保証

4. L163 の driver.quit() は finally に移動

   TypeError部（L172）はdriverスコープ外のため触らない（別タスク #2135）。修正版を作成

Phase 1（lacoco単体試験）完了。結果は成功。

実施内容

• ConoHaへ nakata ユーザーでssh接続（秘密鍵: SERVER/key/conoha/20201011180445.pem）
• 原本退避: /var/www/html/asp_data_get/_bak/20260423/slnm_lacoco.py.original
• 修正版差し替え: /var/www/html/asp_data_get/slnm_lacoco.py (7,212 → 7,518 bytes)
• ローカル作業: /Workspace/20260423/asp_data_get_chromedriver_fix/

修正内容（diff要点）

1. options に3行追加: --disable-dev-shm-usage / --disable-gpu / --window-size=1280,720
2. webdriver.Chrome(chrome_options=options) → webdriver.Chrome(options=options) (新API統一)
3. driverスコープを try:...finally: driver.quit() で囲み、例外時にも必ず quit される形に
4. 旧L163の単独 driver.quit() は finally に移動したので削除
5. lacoco 固有の TypeError（L178相当）は今回無改変（別タスク #2135）

検証ログ（2026-04-23 単体手動実行）

環境確認結果

• Chrome: 86.0.4240.75
• ChromeDriver: 86
• selenium: 3.141.0
• → --headless=new は不可。--headless 維持で確定
• → selenium 3.141 でも options=options 新API は正常動作

重要な観察: 主犯はやはり残存プロセス

作業開始時のサーバ状態で ps -ef | grep chrome = 6プロセス残存（前回実行終了から3時間経過後）。
原因: driver.close() のみで driver.quit() が呼ばれないスクリプト（a8系5本＋felma等）が終了処理で chromedriver プロセスを殺せていなかったため。
Phase 2 で同じパッチを残り13本に適用すれば、asp_data_get.sh 全体として swap 消費が下がる見込み。

次のステップ（Phase 2 候補）

残り13本への適用順（lacocoと同じ3つの修正のみ）:
1. driver.close() のみで driver.quit() 未呼出の組（swap残留の主犯）: slnm_a8, _2, _3, _4, _5, slnm_felma
2. 既に driver.quit() はあるが古いAPI の組: slnm_accesstrade, slnm_afib, slnm_janet(×5)
3. 既に新APIで修正済み: slnm_tgafi（追加するなら disable-dev-shm-usage 等の3行のみ）

着手判断待ち。Phase 2 続行可否を返してほしい。

サーバ状態（現時点）
- uptime 15日、load 0.00、Mem 147MiB/818MiB、Swap 178MiB/2GiB
- 今朝07:44の実行直後スナップショット。プロセス残存なし（pkill効いてる）
- 既に asp_data_get.sh 先頭に pkill -f chromedriver 入り

スクリプト構成（15本、全部 nakata ユーザー所有・パス /var/www/html/asp_data_get/）
- slnm_a8 / _2 / _3 / _4 / _5 / felma / accesstrade / afib / janet×5 / tgafi / lacoco
- 全て Selenium+Chromedriver。構造はほぼ同一

共通する重い原因（grep結果から確定）

tgafi.py だけは既に options=options と try/except/finally: driver.quit() に改修済（コメント「chrome_options → options に修正」あり）。これが良いテンプレートになる。

lacoco の TypeError は別タスク。今回はChromedriver調整のみに限定する。

計画（B案ベース、段階的）

Phase 0: 準備（破壊ゼロ）

1. ローカル /Workspace/20260421/asp_data_get_chromedriver_fix/ に現行15本を rsync で取得
2. ベースライン取得: ps -ef | grep -c chrome、free -h、output.txt の実行時間
3. Chromeバージョン確認（--headless=new 使用可否の判断）

Phase 1: 1本で試験（slnm_felma.py）

• 理由: 旧API＋driver.close()のみ、処理が短く単独で回しやすい
• 修正内容（統一テンプレート）:

options = Options()

options.add_argument('--headless=new')          # Chrome 109+前提で置換、ダメなら '--headless'

options.add_argument('--no-sandbox')

options.add_argument('--disable-dev-shm-usage') # 追加

options.add_argument('--disable-gpu')            # 追加

options.add_argument('--window-size=1280,720')   # 追加

driver = webdriver.Chrome(options=options)       # chrome_options= を廃止

try:

    ...既存処理...

finally:

    try: driver.quit()

    except: pass

• サーバ _bak/20260421/ に原本退避 → 差し替え → 単体手動実行
• 監視: ps -ef | grep chrome（実行中と終了後）／ free -h ／ output.txt比較
• plus-creative.xyz/nakata/asp_data/ で data が同一件数入るか確認

Phase 2: 残り13本に同修正を適用

• Phase 1成功後のみ実施
• 1本ずつ _bak/20260421/ 退避 → 差分レビュー → 差し替え → 単体実行
• lacoco は driver周りだけ触る（TypeError部分には触れない）
• a8系5本・janet系5本は構造ほぼ同一なので効率良い

Phase 3: asp_data_get.sh に保険

• 各Python実行の あとに pkill -f chromedriver 2>/dev/null; sleep 1 を挟む
• 全体時間は＋15秒程度、安全優先

Phase 4: フル手動実行で検証

• 平日昼間に bash asp_data_get.sh を手動実行
• 実行中: ps で並列プロセス数監視（1driverしか立たない事を確認）
• 実行後: free -h で swap推移、plus-creative.xyz側で15本分のデータ到達確認
• data-organizing.com/report_check.php で突合

Phase 5: 翌朝07:40 cronでの本番確認

• 翌日朝に output.txt / free -h 再取得
• swapベースライン比較。下がっていれば完了、task_manage #2136 をチェックON

リスクと判断ポイント

確認事項（着手前に欲しい回答）

1. ConoHa上のファイル書き込みに sudo 必要か？ claudeユーザーで /var/www/html/asp_data_get/ は書ける想定か、sudo -u nakata を使っていいか。分からなければ Phase 0 で touch テストして報告する形でもOK
2. --headless=new への切り替えを試していいか、--headless 維持で最小変更にするか。最小変更派なら3行追加（dev-shm / gpu / window-size）のみでも効果見込める
3. Phase 1の対象は felma でいいか。別推奨あれば変えていい

この3点合意できたらPhase 0から動く。

コメント#1042の調査結果をもとに、残り2項目の解釈を整理。着手前の方針確認用。

1. slnm_lacoco.py修正

• 症状: TypeError: in <string> requires string as left operand, not float
• 原因: Lacoco結果の取り込み時、左辺にfloat（報酬額などの数値）が来た状態で in 演算子を使っている箇所がある。Lacoco側のレスポンス仕様変更で、以前は文字列だった値が数値型で返ってきている可能性が高い。
• 対応:
  
  • 該当行で str(value) への明示キャスト、または数値比較への切り替え
  • 他フィールドの型も併せて確認（同様の破綻が潜在している恐れ）
• 確認: 修正後、asp_data に Lacoco の発生額が反映されるか check_report で突合

2. asp_data_get.sh の Chromedriver 調整

• 症状: 毎朝07:40の実行で swap 212MB消費の主因。Chromedriver を毎回6プロセス起動して Selenium 実行しているのが重い。
• 方向性（2案）:
  
  • A案: Chromedriver を単一プロセス常駐にして各スクリプトが接続する（軽量だが状態汚染リスクあり）
  • B案: 各スクリプト終了時に driver.quit() とプロセス kill を徹底。--headless=new / --disable-dev-shm-usage / --no-sandbox 等のメモリ抑制オプションを付与（堅実）
• 推奨: まず B案 で負荷計測 → 不足なら A案 に踏み込む
• 注意: 並行数は上げない。既に逐次実行なのは正しい設計

位置づけ

タスク441は進捗60%。前半3項目（負荷調査・最適化・ログイン設定）は完了済み。この2件が残りの実作業で、完了後にチェックリスト #1987「動作確認・負荷テスト」へ進む。

着手の許可が出てから実作業に入る。

ASP発生額収集:
asp_data_get/asp_data_get.sh
毎日　朝07:40
Selenium + Chrome で15スクリプト逐次実行。A8(5種)・Felmat・AccessTrade・AfiB・Janet(4種)・TGAFI・Lacoco

ASPリファラー取得:
asp_referrer/asp_referrer_get.sh
毎日　（daily CSV生成あり）
A8/AfiB/Felmat/Lacoco のリファラーデータ取得。curlベースで軽量

最も重いのは asp_data_get.sh
Chromedriver を毎回6プロセス起動してSeleniumでスクレイピング。今日07:44に実行された痕跡あり（output.txt 07:47更新）。swap 212MB消費の主因はこれの可能性が高い。

slnm_lacoco.py
TypeError: 'in ' requires string as left operand, not float
lacoco の結果取り込みが失敗している

https://pub.a8.net/a8v2/media/loginAction.do

Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

plus03のみ取得できていなかった。

アカウント情報に変更あったか？
ログインスクリプトエラーか？

https://data-organizing.com/report_check.php?date=2026-04-12

チェックページ追加しチェック。

負荷となっている　確定情報停止（承認・キャンセル）の送信停止
→crontab　コメント化

1. rootでサーバーにログイン
   ssh root@ -p
   2. 新ユーザー作成
      useradd -m claude
      passwd claude # パスワード設定（鍵認証するなら仮でもOK）
   3. ローカル（Mac）でSSH鍵ペア生成
      ssh-keygen -t ed25519 -f ~/.ssh/conoha_claude
      # → ~/.ssh/conoha_claude（秘密鍵）
      # → ~/.ssh/conoha_claude.pub（公開鍵）
   4. 公開鍵をサーバーに登録（サーバー側で作業）
      mkdir -p /home/claude/.ssh
      chmod 700 /home/claude/.ssh
      # 公開鍵の内容を貼り付け
      echo

【2026-03-31 作業内容】

■ report_check.php 新規作成（旧report_test.php）
- report.phpのメインテーブル下に以下2セクションを追加
1. データ未取得のスクリプト一覧（asp/accountがDBに存在しない場合に表示）
- asp_dataの発生額が0 → OK（成果なし）
- asp_dataの発生額が0超 → NG（取得漏れ）
2. 総合判定テーブル
- report.php合計 vs asp_data合計を比較
- 一致 → 「完璧」表示、不一致 → 差額表示

■ asp_dataサイト（plus-creative.xyz/nakata/asp_data/）
- status00〜03.phpに合計行を追加

■ ページ間遷移
- report.php → report_check.php リンク追加（日付引き継ぎ）
- report_check.php → report.php 戻りリンク追加

アップロードはユーザー側で実施予定。

作業設計：ASPスクレイピング不動作の調査・修正フロー

前提

パスワード変更後から不動作。対象スクリプト：
- /var/www/html/asp_referrer/data-organizing_asp_referrer_get.sh - /var/www/html/asp_referrer/data-organizing_confirm_asp_referrer_get.sh

Step 1：cronログの確認

cat /var/log/cron.log | tail -50

• エラーメッセージを特定
• 「Permission denied」「command not found」「login failed」など種別を確認

Step 2：スクリプトの直接実行

bash /var/www/html/asp_referrer/data-organizing_asp_referrer_get.sh

• cronと同じ実行ユーザーで試す（www-data等）
• エラーがリアルタイムで確認できる

Step 3：認証情報の確認

スクリプト内のID/PW記述箇所を確認：

grep -n "password\|passwd\|login\|user" /var/www/html/asp_referrer/data-organizing_asp_referrer_get.sh

• 変更前のパスワードがハードコードされていれば → 新パスワードに差し替え
• cookieファイルを使っている場合 → cookieを削除して再取得

Step 4：実行権限の確認

ls -la /var/www/html/asp_referrer/

• chmod +x が必要なケース
• cronの実行ユーザー（通常root or www-data）がファイルを読めるか確認

Step 5：スクリプトにデバッグログを追加

set -x  # シェルスクリプト先頭に追加

exec >> /var/log/asp_referrer_debug.log 2>&1

実行結果を /var/log/asp_referrer_debug.log に出力して原因を絞り込む

Step 6：修正後の動作確認

1. cronを手動トリガーで実行（run-parts等）
2. 出力ファイルの更新日時と内容を確認
3. 翌日の自動実行を待機して再確認

想定される最有力原因

パスワード変更後の不動作なので、スクリプト内の認証情報が古いままの可能性が最も高い。Step 1→3を優先的に確認する。

test

アカウント情報（パスワード）を変更後、不具合発生。
asp_referrerのスクレイピングがうまく実行されない。
原因を調査し、修正、様子を見ていく。

タスク情報を補完しました。

• 開始日・工数・優先度を設定
• 作業方針をdesc2に記載
• チェックリスト3件を新規作成（調査→修正→テスト）
• 現在保留中

本日、以下ページのAfiB以下が自動取得がとまっていた
https://plus-creative.xyz/nakata/asp_data/

JANet（pp1037642）
JANet（pp2005790）
JANet（pp2005141）
JANet（pp2007625）
JANet（pp2007788）
TGaffi（plus-tg）

調査、修正対応