ログイン必須の社内Web発注システムを CLI 化して「一言で発注」にする（確定ゲート付き）

社内の備品・名刺・印刷物などを、担当者がブラウザで何画面もクリックして発注している業務を、 AI エージェント（Claude Code 等）から /order <名前> の一言で回せる CLI に置き換える手順。 対象は API の無い、ログイン必須のサーバーレンダリング型 Web システム（Laravel / Rails / Django 等）。

前提

• 発注サイトのログイン ID / パスワード（社内のログイン情報台帳から取る。ID がメールアドレスか社員IDかを実際にログインして確かめる。台帳の備考欄に本当の ID が書かれていることがある）
• Node.js 18+（組み込み fetch）、ブラウザ操作が要る画面のために playwright-core
• 業務マニュアル（画面の順番・既定値: 用紙、梱包、配送方法、枚数など）

手順

1. 画面構造を副作用ゼロで実測する（curl だけ）

1. ログインページを GET し、フォームの action / hidden の CSRF トークン名（_token 等）/ 入力 name を控える。
2. POST でログインし、成功時のリダイレクト先 title と、失敗時のエラー文言（例「IDもしくはパスワードが間違っています」）を控える。失敗文言を知っておくと CLI のエラー判定が確定的になる。
3. ログイン後のサイドメニューの href を全部列挙し、一覧画面・詳細/編集画面・申請・注文・履歴の URL を確定する。
4. 一覧は「表示件数 最大」のクエリで 1 ページに収め、行の data-* 属性とセルの並びを控える。
5. 詳細/編集画面は JS レンダリングのことが多いが、<script> 内に const xxx = {...JSON...} として初期値が埋まっている。行頭 const|let|var 名 = JSON; を正規表現で拾い JSON.parse すれば、役職・住所などの登録値が API 無しで取れる。
6. 「申請」など AJAX ボタンは、ページ内 JS の $.ajax({url, headers:{'X-CSRF-TOKEN': ...}, data}) を読んでエンドポイント・ヘッダ・ボディ形式（配列は key[]）と成功判定（{"status":0} 等）を控える。
7. 多段ウィザード（配送先→用紙→出荷→確認→確定）は curl では入れない。ページ内に操作チュートリアルの JSON（例 tut_list）が埋まっていれば、そこから各ステップの URL・ボタン ID・「実際に注文が行われます」のステップ番号が副作用ゼロで分かる。

2. CLI を 4 コマンドに分ける（確定は必ず別フラグ）

order-cli check   <名前|社員ID|ID>          # 読み取りのみ。登録値・申請状況・履歴
order-cli apply   <名前> [--qty 100]        # 申請（AJAX）。既に申請中なら何もしない
order-cli order   <名前> [--yes] [--to ..]  # ウィザードを確認画面まで進める。--yes 無しは DRY RUN
order-cli history [<名前>]

• check / apply / history は HTTP + 自前 cookie jar（set-cookie を name=value で蓄積、redirect:"manual" で自分で追う）。ブラウザ不要で速い。
• order だけ Playwright。確認画面で内容とスクリーンショットを出して止め、--yes があるときだけ確定ボタンを押す。AI 側の手順書にも「人の OK を得る前に --yes を付けない」と明記する。
• 対象の特定は「名前（空白除去）/ 社員ID / ID の部分一致」。複数一致は候補を出して exit 1（勝手に選ばない）。
• 認証情報は ~/.config/<tool>.env のようなファイルからだけ読む。argv・ログ・スクショのファイル名に載せない。

3. 未確認画面は「初回実行で学ぶ」設計にする

ウィザード内側の画面はフォームの name が事前に取れない。決め打ちで落ちる実装にせず:

• 選択は chooseByText(page, scope, "マットポスト紙 180kg") のように表示テキストの部分一致で行う（select の option → radio/checkbox のラベル → クリック可能要素の順に探す）。
• 想定要素が無い / URL が想定と違う / エラー表示が出た → そのページの全フォーム要素（tag/name/id/type/options/ラベル）を stderr にダンプし、スクショを保存して exit 2。
• AI 側の手順書に「exit 2 が出たらダンプを読んでセレクタを直し再実行。人に画面操作を頼まない」と書く。

4. テストと検証

• HTML 行パース・JSON 抽出・値マッピング・対象マッチ・フォーム直列化・配送方法の自動切替（例: 500 枚以上は宅急便）を純関数で export し、node --test でフィクスチャテストにする。
• check と history は本番に対して実行して確認（読み取りのみ）。apply と order --yes はテストで叩かない。

実測で踏んだ罠

• 日付の区切りが画面ごとに違う（一覧は 2026-08-25 21:42、注文画面は 2026/09/09 15:39）。片方の正規表現だと日時が無言で空になる。\d{4}[-/]\d{2}[-/]\d{2} で両対応。
• 行の data-group_id は申請 ID ではない。申請 ID はチェックボックス input[name="ids[]"] の value。ID セルが数字なので「最初の数字セル＝枚数」とすると取り違える。
• 一覧の名前検索クエリは部分一致が効かないことがある。全件取得して自前でマッチする方が確実。
• AI エージェントの自動許可モードでは「外部発注システムをブラウザ操作する」実行が安全判定で止まることがある。迂回せず、dry run は人が対話セッションで承認して走らせる。CLI 側の --yes ゲートがあるので、承認しても勝手に確定はしない。

実装を安いモデルに委譲するときのコツ

仕様書の冒頭に「あなたは実装者本人。再委譲禁止。既存ファイル不変。指定 3 ファイルだけ書く」と書く。 監督用のメモリ（委譲ルール）が前置きに混ざると、実装者が「自分も監督」のつもりで別ツールを直し始める。