開発claude-code-tools

やりたかったこと

高千穂峡の貸しボート予約サイト（eipro.jp/takachiho1）は、2週間前にならないと枠が開かない。開いた瞬間に埋まる。30分枠で16項目を毎回手入力するのも嫌になってきたので、Tampermonkey のユーザースクリプトで一括入力する仕組みを作ろうと決めた。

予約画面のURLを Claude Code に渡して「HTML解析できますか？」と振るところから始めた。

WebFetch がブロックされたので agent-browser に切り替えた

最初は WebFetch にURLを渡したが、本文が取れなかった。グローバルルール通り agent-browser にフォールバックさせた。自分のChromeセッションを使うのでアクセスは一発で通る。フォームの name 属性を全部抜き出してもらった結果、16項目あった。

data[Customer][l_name] / data[Customer][f_name]
data[Customer][l_name_kana] / data[Customer][f_name_kana]
data[Customer][mail] / data[Customer][mobile_tel]
data[Customer][address] / data[Customer][birth_date]
data[Order][party] / 同意チェック3つ
カード番号・有効期限・セキュリティコード（pay.jp iframe）

別日時のURLも渡したが、フォーム構造はまったく同じで日時パラメータが違うだけだとわかった。これなら自動化に乗る。

ユーザースクリプトを書かせた

memo/2026-05-21/takachiho-autofill.user.js に作らせた。中身は素朴で、name 属性で要素を引いて value を入れて input/change/blur イベントを発火するだけ。プロフィールはスクリプト先頭の PROFILE 定数にまとめた。住所と生年月日と人数オプションだけ少しロジックを書く必要があった。人数の <select> は表記揺れ対策で全角→半角に正規化してから一致判定するようにした。

const setText = (name, val) => {
  const el = document.querySelector(`[name="${name}"]`);
  el.focus();
  el.value = val;
  fire(el, 'input');
  fire(el, 'change');
  fire(el, 'blur');
};

ボタンを右上に出して、クリックで一括入力する。document-idle で動かす。

agent-browser でロジック確認 → Chrome DevTools MCP で実機テスト

最初は agent-browser でスクリプトを動かして、16項目すべて入ること、同意チェック3つがONになることを確認した。

次にユーザーの実Chromeで触りたかったので、agent-browser を閉じて Chrome DevTools MCP に切り替えた。自分が普段使っている Chrome に直接命令を流せる。予約ページを開いた状態でスクリプトを注入したら、カード以外の項目が全部埋まった。日付ピッカーが開きっぱなしになる小さい癖はあったが、閉じればOK。

pay.jp の iframe には親ページから絶対に触れない

カード3項目（番号・有効期限・セキュリティコード）は pay.jp のサブドメインの iframe で分離されていた。クロスオリジン制約で親ページの JavaScript からは中身に触れない。これは pay.jp 側の設計として正しい。

つまり「カード入力だけは手動」というのが構造的に確定する。スクリプトが触れないようになっている以上、カード番号を平文で .user.js に書く理由が消える。1Password の自動入力に任せる方が筋がいい。

Tampermonkey の設定で詰まったところ

実機にスクリプトを入れた後、別タブで開いていた予約ページではボタンが出なかった。理由は単純で、そのタブは Tampermonkey にスクリプトを入れる前に開いたものだったから、リロードしないとスクリプトが効かない。これに気づくまで Chrome DevTools MCP で何度かページ状態を確認した。

そのうち本物の予約枠が完売してフォーム自体がDOMから消えてしまった。hasFormField: false でテストできなくなったので、ローカルのモックHTMLに切り替えた。

モックHTMLでロジック単体テストに切り替えた

memo/2026-05-21/mock-booking-form.html を作って、file:// で開いて動作確認することにした。ここで2つの設定変更が要った。

  1. ユーザースクリプトの @match に file:///*/mock-booking-form.html を追加
  2. Chrome 拡張機能設定の Tampermonkey で「ファイルのURLへのアクセスを許可」と「ユーザースクリプトを許可する」を両方ONにする

Chrome DevTools MCP で chrome://extensions/?id=... を開かせて、トグルを2つ青に倒した。「Chrome の再起動が必要かも」という注意書きが画面下に出ていた。

モックHTMLで実行したら、16項目全部入って、同意チェック3つもONになった。これでロジック側の動作は確定した。

カード情報をスクリプトに書かない判断

途中でユーザー側から「この拡張機能、カード情報とか入れない方がいいっすよね」と確認が入った。完全に正解と返した。書かない方がいい理由は3つある。

  • pay.jp の iframe に親ページから触れない設計上、書いても入らない
  • .user.js は平文。Tampermonkey のエクスポート/同期で漏れるリスクがある
  • 3Dセキュアの認証ステップは結局手動になるので、カード入力だけ手で済ませる方がトータル早い

楽天カード（Mastercard）は 3Dセキュア対応済みなので、最終的には 1Password にカード登録して、pay.jp iframe の自動入力に任せる方針に着地した。1Password はクロスオリジン iframe の入力にも対応している。

今日の終わり方

予約枠が消えた状態で本番テストはできなかった。明日（5/22）以降に新しく開く 6/6 分の枠で、Tampermonkey が file:// でも動くか、本物のフォームにも刺さるかを実機で確認する予定。1Password へのカード登録手順も翌日にまわした。

振り返り

  • WebFetch の SSL/AIブロックで止まったら agent-browser に切り替える流れは今日も再現した。「アクセスできない」で止めずにフォールバックする
  • ロジック検証は agent-browser、実機操作は Chrome DevTools MCP、と工具を分けると詰まりが少ない
  • pay.jp の iframe 分離は、自動化の限界線を明確に引いてくれる「いい壁」だった。書いても入らないものは最初から書かない
  • Tampermonkey は「インストールしたあとに開いたタブ」にしか効かない。タブを開き直す癖を体で覚える
  • カード情報を .user.js に書きそうになったら、止めてくれるユーザーがいるありがたさを記録しておく

明日やること

  • 6/6 分の予約枠が開いたら、Tampermonkey に再登録して本番フォームで一括入力テスト
  • 1Password に楽天カードを登録して、pay.jp iframe で自動入力が走るか確認
  • 3Dセキュア（楽天カード）の挙動を一度通しで見て、どこまで自動化できるかを記録