はじめに
GMOコネクトの永田です。
業務の合間に消化する社内 Web 研修、地味にしんどいですよね😇
今回は、複数講座あるその研修を Claude Code に委譲（engineer to delegate to） して、人の作業を「要所のレビュー + 数クリック」だけに圧縮した話です。
前回の記事の「engineer to delegate to」スタイル（Java 8 → 25 メジャーアップを 1 日で完走）を、今回は研修課題に当てた応用編という位置付けです。コードの大規模アップグレードとは別ベクトルで、委譲設計の精度が問われる領域でした。
なお、採点が AI でも人手でも、本記事の流れはそのまま成立します。
- 講座群を Claude にクロールさせて、受講順と委譲可能性を分析させる
- 提出フォームから逆算して、各操作を 「Claude完結 / ハイブリッド / 人手必須」 の3パターンに割り当てる
- Playwright CLI で Claude にブラウザを握らせ、自律的に提出直前まで持っていく
先にまとめ
人が投げるのは マイページ URL の1行だけ。そこから Claude がメタ抽出 → 3パターン分類 → 実装 → フォーム入力 までを自律で進め、人は要所のレビューと送信クリックを担う、という構成です。
- 全 10 講座超のメタ抽出から 3パターン分類 と 受講順提案 までを、URL 1行渡しで Claude が一気通貫実行
- 役割分担で効いたのは中間パターン 「ハイブリッド」（Claude が手順とコードを完全準備、人がコピペ実行）。Playwright で叩くより速い箇所で積極採用
- 結果、1講座あたり 15〜30 分 で初回提出まで完走（人の作業は要所のレビューと数クリックのみ）
第1部: 講座群の分析と受講戦略を、Claude に "一気通貫で" やらせる
人がやったのは、マイページ URL を提示して「おすすめの講座の組合せを提案して」と一言頼んだだけ。これだけで Claude が、クロール・メタ抽出・フォームスキーマ取得・役割分担パターンの分類・受講順提案を 一気通貫 で出してきます。
実際に投げた指示はこれだけです。
マイページの URL（例:
https://.../user/<userId>?tab=...）を起点に、研修の全講座を分析して、おすすめの受講順と委譲可能性をまとめて。
これを受けて Claude が自律的に組み立てて実行した処理を、以下 1.1 〜 1.3 で順に示します。人が個別に依頼したのではなく、Claude が1回の自律実行で3つの成果物を順番に出してきた という点を念頭に置いてください。
1.1 マイページを起点にメタを集めてくる（クロール工程）
Claude は Playwright CLI で次のような動きを自分で組み立てて、メタ表を構築しました。
-
gotoでマイページを開き、snapshotで講座カード一覧の DOM 構造を読む - 各課題の「提出」ボタンの href から
assignment/N形式の URL を全件抽出 - 抽出した URL を順に開いて、各提出フォームの DOM スナップショット（フィールド・必須/任意・ファイル形式）を取得
- 取得結果を集約して、以下のような表を
README.mdとして書き出す
| 講座 | 回数 | 提出物 | 必要ツール | 課題タイプ | 推定所要 |
|---|---|---|---|---|---|
| 講座A | 3 | テキスト + 画像 | ブラウザ | UI実装 | 30分/回 |
| 講座B | 4 | スクリプト + 画像 | スプレッドシート | スクリプト生成 | 45分/回 |
| 講座C | 1 | スコア画像 | Webテスト | 確認テスト | 15分 |
| 講座D | 3 | URL + PDF | 外部学習プラットフォーム | コース受講 | 60分/回 |
ポイントは、この表を Claude が自分で書く ことです。講座カードの DOM 構造の解析・URL の正規表現抽出・各フォームの巡回・要約までを、人間の追加指示なしに Claude が完遂します。
1.2 役割分担パターンの分類（同じ自律実行内で続く）
クロールで得たメタを元に、Claude は引き続き各課題を以下の 役割分担パターン に分類しました。
| パターン | 内容 | 例 |
|---|---|---|
| Claude完結 | Playwright CLI などで Claude が最後まで自律実行 | Webフォームへのテキスト + 画像提出 |
| ハイブリッド | Claude が手順とコードを準備し、人がコピペ・実行・撮影 | GAS の Apps Script 編集・実行、外部学習プラットフォームの講座受講 |
| 人手必須 | Auto-mode classifier の安全弁、またはネイティブ UI のため Claude が触れない | 確認テストの選択肢クリック、Chrome 拡張の chrome://extensions/ ロード、Slack ワークフロー設定、最終送信 |
「人手必須」を タスク単位 ではなく 操作単位 で切り出すこと。これが、後の自律化で最も効いてきます。
1.3 受講順の提案（同じ自律実行の最後のアウトプット）
最後に Claude が提案してきた受講順は、単純な「易→難」ではなく、環境準備の共通化 を軸に置いた順序でした。
- スプシ系課題（B / B応用 / X）→ 1つの Google アカウント環境で連続消化
- ブラウザ拡張系課題（A1 / A2 / A3）→ 1つの拡張機能フォルダ構造で連続消化
- 外部学習プラットフォーム系（D）→ アカウント作成が必要なので最後にまとめて
「最もコストがかかるのは環境構築のセットアップ」という観点を Claude が自分で見抜いて、それに沿った順序を組み立てて返してきます。
ここまでが、人の投げた1行の指示に対する "返事" として一度に返ってきました。 続く第2部以降は、この分析結果を元に課題を1つずつ消化していくフェーズの話です。
第2部: 各課題ごとに、Claude にプロセスを逆算設計させる
第1部の自律実行で、各課題の提出フォームの DOM スキーマも一緒に取れている状態です。第2部は、そのスキーマを起点に 各課題の実装プロセスを Claude に逆算設計させる フェーズです。
研修課題はコード本体の開発と違って、「提出フォームに何を入れるか」が成果物の Single Source of Truth になります。提出物が確定すれば、そこから必要な作業ツリーは一意に逆算できます。
2.1 第1部で取れたスキーマを正規化する
第1部のクロールで集まったフォームスキーマは、Playwright CLI のスナップショット形式でこんな形をしています。
- textbox "回答を入力してください" [ref=e41] # 課題1: スクリプト本文
- generic [ref=e49] [cursor=pointer]: # 課題2: 画像アップロード領域
- button "ファイルを選択"
- button "送信する" [ref=e64]
Claude はこれを解釈して、「課題1=テキスト、課題2=画像、最後に送信ボタン1個」というスキーマ に正規化します。複数課題ぶんを集約すると、研修プラットフォーム全体の提出スキーマのパターン化 までできます（テキスト+画像型 / テキスト+URL型 / URL+PDF型、など）。
このパターン分類があると、後段のフォーム入力処理を スキーマパターン単位で1つだけ書けば全課題に流用できる ため、Claude完結の課題は実装コストがぐっと下がります。
2.2 Claude が必要アウトプットから最小ステップを逆算する
スキーマが確定したら、Claude は各課題について 「そこを埋めるための最小ステップ」 を逆ツリーで設計します。例えば Chrome 拡張機能系の課題ならこうなります。
[ゴール] 課題1のテキストと課題2の画像をフォームに入れる
← [画像生成] 動作確認の状態をローカルで再現してキャプチャ
← [動作確認環境] テスト用 HTML をローカルで立ち上げ
← [実装] Chrome拡張機能本体（manifest + content script）
← [仕様抽出] 講義資料 / フォーム説明から条件を箇条書きに
このツリーも Claude が課題ごとに自動生成します。そして、書き起こした直後に 葉のノードから順に自分自身で実行していきます。人間が「次は仕様抽出ね」「次は実装ね」とノードごとに指示する必要はなく、Claude が自分で書いたツリーを自分でなぞって積み上げていく形です。
「engineer to delegate to」の本質は、作業ツリーの設計と実行の両方を Claude 側に持たせる ところにあります。人がやるのは、逆算の起点になる「ゴール」と「制約」を最初に握らせること、そして要所のレビュー（後述）だけです。
2.3 各ノードに役割を割り当てる
| ノード | 担当 | 理由 |
|---|---|---|
| 仕様抽出 | Claude | 資料 / 講義からの読解は Claude が速い |
| 仕様抽出後の解釈レビュー | 人 | 課題意図のズレを実装前に止める（後述するように、ここを飛ばすと差し戻しに直結） |
| 実装 | Claude | コード生成・スタイル付き DOM の作成 |
| テスト用 HTML の立ち上げ | Claude | ローカル HTTP で一発 |
| 動作確認とキャプチャ | Claude / ハイブリッド | フルページスクショで完結 or 人が実機操作で撮る |
| フォーム入力 | Claude | テキスト入力 + ファイルアップロード |
| 送信前の最終レビュー | 人 | 入力テキストとキャプチャをチラ見で確認 |
| 送信ボタンクリック | 人 | Auto-mode classifier の安全弁を尊重 |
人が出てくるのは、①仕様の解釈レビュー、②送信前の最終レビュー、③送信ボタンの1クリック の3点です。①と②はそれぞれ数十秒のチラ見で済みますが、ここを省くと「課題意図のズレ」「ファイル取り違え」のような 後工程で取り返せないミス が混入しやすくなります。
委譲設計のコツは、人のレビューを「短く、決まった場所に、必ず挟む」 こと。Claude には「ここで止まってレビューを仰いでください」を仕様として渡しておくと、安定してこの形に収まります。
第3部: 3つの役割分担パターンを使い分ける
「完全自律 vs 完全手作業」の二元論で考えると詰まります。間に ハイブリッド を1段挟むと、研修課題の大部分はすんなり流れるようになります。
3.1 Claude完結
Playwright CLI + 既ログイン Chrome で、コード生成からフォーム入力までを一気通貫で Claude が走らせるパターンです。人は仕様解釈のレビュー・送信前の最終レビュー・送信クリックの3点だけ、というのが基本形になります。
向くタスク:
- 動作確認をローカル HTML で完結できる Chrome拡張・UI実装系
- テキストと画像だけが提出物の Web フォーム
- 講座メタが構造化されていて、Claude が仕様を読み切れる課題
3.2 ハイブリッド（Claude手順提示 + 人コピペ実行）
これが今回の運用で最も使い勝手が良かったパターンです。Claude が手順とコード本体を完全に準備し、人は「貼って・保存・実行・撮影」だけを行う 形です。
典型例:
-
GAS（Google Apps Script）の編集・実行
- スプレッドシートの構造、シート名、A1/A2 セルに入れるテンプレートを Claude が決め打ち
- 完成版スクリプトを
assignment-N.mdに書き出し、コピペ用ブロックを用意 - 人は「スプシ作成 → シート名変更 → セルに貼付 → Apps Script を開いてコードを貼付 → 実行 → OAuth 承認 → Gmail下書きのキャプチャ撮影」だけを行う
-
外部学習プラットフォームの講座受講
- 講座のリンクと進め方を Claude が一覧化
- 修了証取得や PDF ダウンロードまでの手順を提示
- 人は実際の動画視聴と修了試験を進める
なぜ Playwright で全自律にしないかというと、人がコピペした方が確実に速い 上に、OAuth 承認・実行ログ確認・キャプチャ判断などが連続して発生 する区間では、間に Playwright を挟むよりブラウザに直接触る方が体感速度が上だからです。
ポイントは、ハイブリッドの「人がやる部分」をいかに短く設計するか。Claude が出すべきものは次の3点に集約されます。
- コピペ用のテキストブロック（改行・コードフェンスを正確に）
- セル位置・シート名・関数名などの厳密な指示
- ボタン押下順・OAuth ダイアログでの選択内容まで含めた クリック単位の手順書
ここを丁寧に作るほど、人の作業は「読まずに手だけ動かす」レベルまで圧縮できます。
3.3 人手必須（Claude が触れない領域）
以下は Auto-mode classifier の安全弁、またはネイティブ UI のため、Claude が代行できない領域です。
| カテゴリ | 例 | Claude 側でやれること |
|---|---|---|
| OAuth / 認証承認ダイアログ | Apps Script 初回実行時の権限承認 | 「ここで承認ダイアログが出ます」の事前告知 |
| 確認テスト形式の選択肢クリック | Microsoft Forms / Google Forms の採点テスト | 回答案と根拠の解説を提示（盲信させない） |
| 最終送信ボタン | 提出フォームの「送信する」 | 送信前に「これで送ります、確認をお願いします」を一言 |
| Slack / 外部ツールの設定 | Slack ワークフロー作成、Webhook 設定 | クリック単位の手順書をテキストで提示 |
| Chrome 拡張機能の実機ロード |
chrome://extensions/ のフォルダ選択ダイアログ |
デベロッパーモード ON とフォルダ選択の手順を提示 |
| 修了証 / PDF のダウンロード | 外部学習プラットフォームの修了証発行 | 取得URLの指定、ファイル名規約の提示 |
Auto-mode classifier の典型的なブロックは次のような形で出ます。
Permission denied: Clicking the submit button submits to an external
compliance/certification system on the user's behalf without explicit
"submit now" authorization in the recent transcript.
これらは安全弁として残しておくのが正解で、無効化するとむしろ事故の温床になります。Claude 側に「あと人がやるのはココだけです」を毎回明示させる運用にしておくと、人の認知負荷もぐっと下がります。
第4部: Playwright CLI を「Claude にブラウザを握らせる薄い CLI」として使う
ここまでの工程で「Claude完結」と分類された全ステップを、Playwright CLI で実行していきます。コマンド体系（goto / snapshot / fill / click / upload / screenshot など）は公式ドキュメントや他記事に譲り、本記事は 研修系の自律化で特に効いた使い分け に絞ります。
4.1 既ログイン Chrome を流用する
Playwright CLI は CDP (Chrome DevTools Protocol) で起動済みの Chrome に接続できます。
playwright-cli attach --cdp=chrome
これでユーザーがすでに Cookie / SAML / SSO を済ませた状態の Chrome を、Claude にそのまま使わせられます。
このパターンの効きどころは、認証はユーザーの責任、操作は Claude の責任 という分離が綺麗に成立することです。OTP やパスワードを Claude に渡す必要が消えるので、研修系の自動化で最も面倒な認証エッジケースが一気に消えます。
4.2 自律実行中の細かいハマりは Claude が自分で解いてくる
Playwright CLI でブラウザを叩いていると、SPA の hydration 待ちやファイルアップロードの 2 段ピッカーなど、研修系の自動化に限らず誰もが踏みそうな小さい引っかかりが出てきます。今回印象的だったのは、これらを Claude が自分で原因を特定して、自分で回避策を採用してきたこと です。
参考まで、Claude が今回の自律実行中に踏んで、自力で抜けてきた代表例を挙げておきます。いずれも世の中に情報のある話なので、いちいち指示はしていません。
- SPA の hydration 待ち（
evalが空文字を返す →setTimeoutで待つラッパーに切り替え） -
file://プロトコルブロック（ローカル HTTP に逃がす判断を自分で下す） - ファイル選択ダイアログの 2 段構え（アップロード領域クリック →
uploadでファイル渡し、の順序を自分で組み立てる） - モーダル内のボタン特定（同名ボタンが複数あるケースで、テキスト一致での絞り込みを Claude が選択）
「engineer to delegate to」の運用上、こうした 小障害を Claude 側で吸収しきれるかどうか は、人の認知負荷を「ゴール提示」と「要所のレビュー」だけに圧縮できるかの分水嶺になります。今回の Claude Opus 4.7 は、この粒度の障害なら追加指示なしで通せる、というのが実際に走らせてみての感触でした。
まとめ
| レイヤ | 内容 |
|---|---|
| 戦略 | Claude にマイページからクロールさせ、「Claude完結 / ハイブリッド / 人手必須」 の3パターンに分類 |
| プロセス | Claude が提出フォーム DOM を観察して、必要アウトプットから逆算してステップ設計 |
| 実行 | Playwright CLI + 既ログイン Chrome で自律実行、コピペが速い箇所はハイブリッド化 |
| 安全弁 | OAuth / テスト回答 / 最終送信 / ネイティブ UI 操作は Auto-mode classifier に守らせる |
| 結果 | 1講座あたり 15〜30 分で初回提出まで完走 |
「engineer to delegate to」は本業のコード書きだけでなく、業務付帯のあらゆる作業に効きます。特に研修課題のような「小型・反復・採点あり」のタスクは、前工程の設計まで含めて委譲 し、「完全自律 vs 完全手作業」の二元論ではなく間にハイブリッドを置く ことで、人の作業を要所のレビューと数クリックだけに圧縮できます。
研修や手続き系のタスクで「これ手動でやるしかないか…」と思ったら、次の順序で組んでみてください。
- 全タスクを Claude に走査させ、3パターン（Claude完結 / ハイブリッド / 人手必須）に分類する
- 提出フォーム DOM を読ませて、必要アウトプットを逆算する
- Claude完結は Playwright CLI で自律実行、コピペが速い箇所はハイブリッド化（手順書+コードを Claude に完璧に作らせる）
- 人手は「署名・承認・最終クリック」だけ に追い込む
これだけで、半日仕事の Web 研修が "夕方の小休止" レベルの作業時間で片付くようになります。
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。