AI Agent × ヘッドレスブラウザによる業務自動化をきっかけとした、AI駆動思考への第一歩

![image](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/375c5590b68a4cc581784d065a1ada96.png?updatedAt=1781671377000) こんにちは、LINEヤフー株式会社の花谷拓磨（[@potato4d](https://x.com/potato4d)）です。普段はフロントエンド領域を中心とした開発組織のマネジメントや、AI Agent のプロダクト開発などを担当しています。 本記事では、[Orchestration Development Workshop](https://techblog.lycorp.co.jp/ja/20251031a)（以下、ODW）の第 11 回として開催したWorkshop **「AI Agent × Headless Browser で今日から始める業務自動化 〜 定型業務から開発まで 〜」** の内容をお伝えします。 ODWは、CTO配下から選抜されたエンジニアが集まる「Orchestration Guild」が運営する、AI駆動開発の実践知見を全エンジニアに横断展開するためのWorkshopです。 ## 見えないボトルネックとして確かに存在する非本質的な業務 AI Agent の活用は今や Agentic Coding の枠組みすらも超えて、プロダクト開発のほとんどの領域に入り込む時代へと移り変わりつつあります。 企画からデザイン、開発まで、多くの領域の業務で AI が浸透していくことで、How にかける時間は大幅に圧縮され、より本質的な Why/What に対して向き合う時間が増えていることは間違いありません。 その一方で、もっと身近で普遍的なはずの労働強度の低い仕事の存在については、意外なほどに手が入れられず、従来型の業務スタイルのまま取り残されている印象があります。 例えば、社内システムやそれらに関する事務的な手続きなど。決まりきった操作を繰り返すものが、手作業のまま放置されてしまっているケースは少なくありません。 細かな理由こそさまざまですが、端的に真因を挙げると、**改善するにはコスト対効果が不釣り合いである**という認識によるものがほとんどでしょう。 自動化対象がAPIが提供されていなかったり、提供されていたとしても利用までのハードルが高いようなケースもあれば、そもそも一回あたりの所要時間は小さいから許容しているケース、所要時間は長いが頻度は低いから許容しているケースなど、総合的には作成・メンテナンスのコストと、業務圧縮量を天秤にかけた結果として今の状態があるはずです。 最終的には損益分岐点に到達していないと判断されてきたからこそ放置されてきた業務たちであり、その意思決定は多くの場合妥当であったはずです。 ただ、そのコスト認識の常識が今、大きく変わりつつあります。 ソフトウェア開発の現場では、すでに Codex や Claude Code に開発マシンのフルアクセスを許可し、端末上で完結する作業のほとんどを任せることが日常茶飯事です。そして、その業務が必ずしも全て専門性を要するものかというと、決してそうではありません。 自然言語を利用して、効率的に進行したい業務を簡潔に Agent に投げかける。それだけで完結している業務も少なくないでしょう。そういったものは開発者に限らず、ごく少量の、ゼロに近い工数で、従来の単純作業は自動化ができるのではないでしょうか？ 古来より使われ続けてきた RPA や Bot による自動化はある程度の時間的コストをかけて作り、長期的にメンテナンスを行う前提でしたが、Agent は初期段階で金銭的コストがかかることを制約として持つ代わりに、時間的コストやメンテナンスコストを大きく圧縮して運用可能となっています。 そのため、これまで考えられていた損益分岐点は大きく変化しており、端的に言うと生成コストより生み出す成果が大きい場合、すぐに自動化しても良いといってもそれほど問題がない状態となりつつあります。特に開発者以外も行うような業務については、一度自動化が実現できたときに時間を削減できる人数が圧倒的に多くなるため、自動化のポテンシャルが高いことは明確です。 例えば LINE ヤフーの場合、[社員数はおおよそ 10,000 人](https://speakerdeck.com/lycorp_recruit_jp/introduction-for-engineer-english?slide=5) ですから、全員の業務を一日 5 分効率化するだけで、月間 16,000 時間以上の削減につながります。もし開発者全員が自主的に自動化していたという前提であったとしても、8,000 時間以上の削減のポテンシャルを秘めています。 そのため、全職種がオートメーションに挑戦する段階を迎えていると言って差し支えないでしょう。開発者が必ず関わる必要があった従来のコスト感覚をアンラーニングし、各業務を棚卸しして適切なオートメーションを進めていく必要があります。 ## AI Agent × ヘッドレスブラウザが実現する自動化の第一歩 その未来に向かうため、今回は AI Agent × ヘッドレスブラウザの組み合わせを、開発者とデザイナーを対象とした Workshop として実施することとしました。 テーマ設定については、ブラウザが自動化されるという体験が誰にとってもなじみやすく、それでいて開発現場でもコストが高く感じていた E2E テストやブラウザ周りが絡む開発の効率化のエッセンスにつながると考えたためです。 対象者については、これまでの 10 回の Workshop ではエンジニアに閉じていましたが、開発者と比較的距離の近い職種として、メインの参加者をデザイナーに据えました。 LINE ヤフーでは過去に [Creators Vision vol.2「生成 AI 時代における『私たち』の働き方」開催レポート](https://techblog.lycorp.co.jp/ja/20251020a) など、AI × Dev × Design の 3 種が混合するワークフローについてディスカッションを進めてきた土壌があること。 そして何より、特に職種の狭間が溶けつつあるクライアントとデザイン領域は、定常業務の効率化だけではなく、これをきっかけに AI 駆動が新たに根付いた現場を作り出しやすいという想定のもとでの対象設定です。 総合的に従来とは毛色の違う Workshop となりましたが、親しみやすい第一歩になることを主眼としています。 ここからは、Workshop の実際の内容を紹介します。今回の Workshop では、冒頭でセットアップを行ったあと、基礎編と実践編に分かれて 2 つのハンズオンを実施しました。 ## Playwright の導入 今回の Workshop では、ヘッドレスブラウザとして、[Playwright](https://playwright.dev/) を採用することにしました。Computer Use や Browser Use といったより AI ネイティブなアプローチも選べる時代ですが、 - 技術的に十分に枯れており、想定外のトラブルが起きづらいこと - 自動化という文脈においては headless/headed を自由に切り替えやすく、誰でもブラッシュアップをしやすいこと - 社内のセキュリティポリシーとの整合性を、運営側である程度グリップできること などを考慮したときの安定した選択肢として採用しています。 実践では、それぞれの知識に応じてセキュリティ要件を遵守しつつ取捨選択することが重要です。とはいえハンズオンではコントローラブルでありながらも扱いやすい技術であるほうがメリットが大きいと考えました。 ## 基礎編：社内システムへのアクセスとシステム横断の自動化 基礎編では、ヘッドレスブラウザを使った業務自動化を二段階に分けて体験してもらいました。 最初のステップでは、仮想的に用意した社員検索システムをヘッドレスブラウザ越しに操作し、その一連の手続きを再利用可能なスキルとして切り出すハンズオンを行いました。 ![image](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/9ee3cc26e86e4372acb6725f1ad22244.png?updatedAt=1781671402000) デモ用社員検索システム 実際にハンズオン受講者には以下のようなプロンプトを利用して、Skill 自身を AI に作成させるところまで体験してもらっています。（プロンプトはイメージであり、実際のハンズオンの内容とは少し異なります。） ハンズオンの 2-1 を進めます。 「社員検索システム」から情報を取得するスキルを ./.agents/skills/get-employee-info/SKILL.md に作成してください。 手順は以下のとおりです。 1. ユーザーに取得したい従業員の識別子を尋ねる (提示されている場合はそれを使う) - 識別子は「日本語の本名（例：花谷拓磨）」または「アルファベット（例：takuma.hanatani）」のいずれか 2. ${社内システムへのドメイン} へと playwright を使用してアクセスする 3. 同一セッションを使いまわして従業員の情報を取得する - ${社内システムへのドメイン}/employee/ へアクセス - 取得する情報は「名前」「ID」「メールアドレス」「所属 (本務)」の 4 つとする 4. すべての取得が終わったら、ユーザーに返却する 5. playwright を閉じる 実際の業務自動化ではもう少し抽象的なプロンプトでもうまく動いてくれることも多いですが、今回は対象参加者の多さも考慮し、一定以上明確な指示のもと、想定通りの結果が得られるようにしています。 翻訳全文 生成が完了し、動作確認が終わったあとは社内のナレッジベースとの通信を組み合わせ、複数の社内システムをまたいだ業務の自動化を行いました。 具体的には業務内で発生しがちな「特定の PJ 関係者についてまとめておく」というフローを題材とし、Wiki から Workshop 関係者の情報を引き、それを社員検索システムで検索、最終的に整形した一覧としてまた Wiki に書き戻すという流れを、Agent への一回の依頼で完結させるシナリオとなっています。 ![image](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/7fa7149bcf7a41c787ad16783e4a38a1.png?updatedAt=1781671431000) こういったシステムを横断する作業は手作業で 10～20 分程度かかることも多いですが、AI Agent に依頼するとプロンプトを打ち込めばあとは放置するだけ、という体験へと変わります。 こういった「チリツモ」の AI 駆動での業務による解消の一例として、基礎編を行いました。 ## 実践編：デザイン追従とマークアップを AI に任せる ![image](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/6e8bfebd0996422097af9b9cc9ace9d1.png?updatedAt=1781671445000) 実践編では、現場でありがちなフロントエンド業務をそのまま AI 駆動に置き換えるハンズオンを行いました。 「タイムライン型 UI の改修」を題材に、デザインデータを UI として実装し、その結果を AI がチェックするまでの一連の流れを体験してもらいます。よりアジャイルな開発手法も増える中でも、依然として最終製品データを作るツールとしての Figma の人気は根強くあります。加えて社内的にも Figma を採用している土壌があり、Figma MCP（MCP）を活用することで開発スピードをより引き上げられるため、社内の実際の環境に近い形で実践的に擬似体験してもらうことを目的としました。 実践編ではデザインのメタデータをベースとしたマークアップを実施したあと、Playwright を利用してスクリーンショットを撮ってのデザイン照合を AI に自律的に行ってもらうまでを実施しました。デザインのメタデータをベースとした照合とスクリーンショットをベースとした差分比較を通じて、ソースコードでのレビューと実際のレンダリングベースでのレビューという一連の業務実装に近い流れを AI に任せることが実現できています。 フロントエンド開発におけるヘッドレスブラウザの利用というと E2E テストによる開発の印象が強い中で、普段の実装の中でも人間の目に近いレビューをさせやすいこと、そして形にするだけなら事前に評価基準を明確化すると簡単なプロンプトで実現できることを紹介し、デザイナーがまずイメージを形にするといった工程を思い描きやすい形で紹介しています。 ![image](https://vos.line-scdn.net/landpress-content-v2-vcfc68aynwenkh3bno0ixfx8/5b3a16e821ab49058911be3779a93747.png?updatedAt=1781671463000) 実際にハンズオンで見せていたサンプルの様子。 この実践編をもってハンズオンは終了となります。 ## デザイナーからのフィードバック Workshop 終了後には参加者からアンケートを取り、ハンズオンの体験について多くの率直なフィードバックをいただきました。ここではエンジニア向けの Workshop では見えにくかった、デザイナーならではの目線で印象的だったコメントをいくつか紹介します。 ## 「何ができるか」のイメージが具体化したことへの手応え もっとも多く寄せられたのは、AI Agent の活用範囲について解像度が上がったという声でした。 これまで AI といえば、画面の中で質問を投げかけて完結するチャットの延長線上で捉えていた方が多く、他のツールと連携させることで「手作業で調べていた工程をまるごと省略できる」という体験そのものが驚きだったというコメントが目立ちます。 ** 普段AIについては、単純に質問を投げかけてその画面上で完結することが多かったが、その他のツールと繋ぐことで、わざわざ手で調べて参照していた作業などを省略できることに驚いた。これまで対峙していたAIはほんの一部で、もっと使いこなすことでより便利に生産性を上げられることがわかった。 また、「定型業務を効率化する」という方向性は職種を問わない普遍的なニーズである一方で、専用ツールの提供を待たずとも、自分の手元で環境を組み上げれば自動化が実現できるという感覚を持ち帰っていただけたようです。 専用のAIツールやツール連携を待たずとも、自分で環境を構築することで自動化が可能になるんだ！と希望を持てました。 もちろん、その「環境を組み上げる」工程自体が開発者以外にとってはまだ一段高いハードルであり、事前準備の段階で詰まってしまった方が一定数いらしたことも事実です。ここは運営として真摯に受け止めつつ、裏を返せば「本編のハンズオンに乗ってさえしまえば AI 駆動なワークフローの恩恵を体感してもらえる」ことの裏付けでもあるため、今後の Workshop の構成側で吸収していくべきポイントだと考えています。 いずれにせよ、冒頭で述べた「コスト感覚のアンラーニング」が、開発者だけでなくデザイナーの側にも届きはじめている手応えを感じる感想でした。 ## アウトプットのブレを「自分だけじゃない」と知る体験 もう一つ印象的だったのは、モデレーター側の画面と自身の手元の挙動をリアルタイムで見比べられたことに対する反応です。 AI のアウトプットは同じプロンプトでも出力のスピードや内容に揺らぎが生まれるものですが、それを「自分の操作が悪いのではないか」と捉えてしまい、AI に対するハードルが上がってしまうケースは少なくありません。 人によって出力のスピードや内容が微妙に違っていたので、AI のアウトプットが期待通りにならないのは「私だけじゃないんだ！」とホッとした気持ちになりました。アウトプット品質のブレは AI の面白さでもあり課題だと思うので、どう補正・担保していくのかは、今後もぜひ学ばせていただきたいと思います。 翻訳全文 出力のブレを「個人の習熟度の問題」ではなく「AI と向き合う上での共通の課題」として捉え直せる場を提供できたこと自体が、今回のワークショップの収穫の一つだったように思います。 その他のフィードバックとしては、Codex App に関する環境構築のハードルなど、AI ドライブなワークフローに至るより手前の段階での課題感についての声もいくつかいただきました。こうしたフィードバックは、今後デザイナー向けにワークショップを開催する際の構成や事前準備の磨き込みに直接活かせる、運営側にとっても非常にありがたい収穫です。これらを踏まえて改めて感じたのは、AI ドライブなワークフローへの関心と前向きな姿勢が、確かに開発者以外の職種にも広がりはじめているということでした。 ## ここから始まる未来について ここまで紹介してきた内容は、あくまでひとつのきっかけでしかありません。 私自身、個人的に強く感じている課題感として、イノベーター層として先行して AI 活用してきた人とそれ以外の人で AI の使い方に大きな差が出すぎているという点があります。実際、Agentic Coding（自律型コーディング）によるプロダクト開発が当たり前になりつつある一方で、「対話する ChatBot」の延長線上での利用に留まっている人もまだまだ少なくはありません。 対話する ChatBot から一歩踏み出して AI を活用するために、わかりやすく身近な作業である「ブラウザ操作の自動化」を、今回は題材として選びました。とはいえこれも単独で見れば一つの切り口にすぎず、本当に伝えたかったのはその手前にある思考の転換のほうです。 真に重要であるのは、「とりあえず AI に任せることを試してみる」という発想が、職種を問わず業務を始めるときの最初の選択肢として持てるようになること。これさえ獲得できれば、手段としてのブラウザ自動化はあくまで一つの実装にすぎず、別の道具に置き換わったとしても効能は変わらないはずです。 そして「とりあえず AI に任せてみる」を最初のオプションに据えられるようになることは、結果として人間がより本質的で労働強度の高い業務に集中するための地ならしになります。これが組織全体に及ぼす総量は、全職種の人数を掛け合わせた分だけスケールしていくため、おそらく我々の直感が捉えているよりずっと大きいはずです。 LINE ヤフーでも [LY MCP Agent](https://techblog.lycorp.co.jp/ja/20260518b) を業界の中でも早い段階から開発してきましたが、それと並行して、業界全体としても Codex App や Claude の Co-Work（共働）、各種 Agentic Browser（自律型ブラウザ）など、Desktop / Browser App としての UX も急速に整いつつあります。エンジニアが書き捨てる便利機能としてのインフラから、職種を問わない日常の道具へと、AI の輪郭が一段階下のレイヤーに降りてきていると感じる場面が増えました。 だからこそ、今こそが好機と言えます。 これまでは開発者や一部のアーリーアダプターだけが取っていた Co-Work 的なアプローチを、自然と日常業務の中で取れるようになる世界観。これは決して遠い未来の話ではなく、手元にある道具を少しずつ繋ぎ直すだけで届く射程に入っているはずです。 そしてその繋ぎ直しは、結局のところ、開発組織にいる誰かが隣の職種に手を伸ばすところからしか始まらないはずです。それが至るところで自然に起きるようになる頃には、職種による AI 利活用の差は、もう過去の課題になっているのかもしれません。 [AI活用スキル向上ワークショップ「Orchestration Development Workshop」記事一覧](https://techblog.lycorp.co.jp/ja/20260226a)**

AI Agent × ヘッドレスブラウザによる業務自動化をきっかけとした、AI駆動思考への第一歩

背景や根拠まで確認しますか？

調べる

選ぶ

サイト