イントロダクション：RPAの「保守地獄」からの脱却
「月曜日の朝、出社して最初にやることは、週末に停止したRPAのエラーログを確認することです」
大手企業の情シス担当者からは、疲労の色を滲ませながらこのような声がよく聞かれます。DX（デジタルトランスフォーメーション）の切り札として導入されたはずのRPA（ロボティック・プロセス・オートメーション）が、いつしか「保守」という名の新たな業務を生み出している――これは決して珍しい話ではありません。
従来のRPAは、言わば「融通の利かない実直な作業員」です。画面のレイアウトが1ピクセルずれたり、ボタンのID（識別子）が少し変わったりしただけで、彼らは迷子になり、作業を放棄してしまいます。WebサービスやSaaSが頻繁にアップデートされる現代において、この脆弱性は致命的とも言えます。
しかし今、生成AIとLLM（大規模言語モデル）の進化により、この状況が一変しようとしています。Taxy.aiやLaVagueといった新しいツール群は、細かな手順を教え込むのではなく、「このサイトで競合の価格を調べて」といった意図（Intent）を伝えるだけで、AIが自律的にブラウザを操作します。
今回は、株式会社テクノデジタル 代表取締役であり、AIエージェント開発・研究者として最前線に立つHARITA氏にインタビューを実施。次世代RPAとも呼ぶべき「自律型AIエージェント」は、果たして我々を保守地獄から救い出してくれるのか？ それとも新たなリスクを持ち込むのか？ その真価と現在地を、経営者視点とエンジニア視点を交えて深掘りします。
インタビュイー紹介：AIオートメーションの最前線
HARITA
株式会社テクノデジタル 代表取締役 / AIエージェント開発・研究者
徳島県出身。中学生からゲームプログラミングに没頭し、高校生で既に業務システムの受託開発を経験。現在は株式会社テクノデジタルの代表として、AIエージェントや最新AIモデルの研究・開発を自ら牽引。35年以上のキャリアを持ちながら、常に最先端の技術スタックをアップデートし続ける。「まず動くものを作る」プロトタイプ思考を重視し、技術の本質を見抜いてビジネスへの最短距離を描くアプローチに定評がある。
編集部： 本日はよろしくお願いします。HARITAさんは普段、AIエージェント開発や業務システム設計を牽引されていますが、最近の「ブラウザ操作の自動化」に関するトレンドをどう見ていますか？
HARITA： よろしくお願いします。非常にホットな領域ですね。ただ、バズワード先行で少し誤解されている部分も多いと感じています。「AIが勝手に全部やってくれる」という魔法のような期待値と、実際のエンジニアリングの現場にはまだギャップがありますから。
編集部： 確かに、「自律型エージェント」という言葉だけが独り歩きしている印象もあります。
HARITA： ええ。実際の開発現場でも、オープンソースのLaVagueや、商用サービスのMultiOnなどが検証されていますが、これらは従来のRPAとは根本的に「脳みそ」が違います。今日はその技術的な違いと、ビジネスで使う上での「落とし穴」について、包み隠さずお話しできればと思います。
Q1: 「自動化」の定義が変わる？Instruction vs Intent
編集部： まず、従来のRPAと、今回取り上げるTaxy.aiやLaVagueのようなAIエージェント、技術的に何が決定的に違うのでしょうか？
HARITA： 最大の違いは、「Instruction（指示・手順）」ベースか、「Intent（意図）」ベースかという点です。
従来のRPA、例えばSeleniumやUiPath（の基本的な機能）などは、Webページの裏側にあるDOM（Document Object Model）という構造に強く依存しています。「IDが login-button の要素をクリックせよ」とか、「XPathが /div[2]/button の場所を押せ」といった具合に、厳密な住所指定が必要です。
編集部： それが「壊れやすい」原因ですね。
HARITA： その通りです。SaaSのアップデートでボタンのIDが変わったり、divタグが一つ増えたりしただけで、その住所は無効になります。これが「保守地獄」の正体です。
一方、最新のAIエージェントは、人間と同じように「画面を見て」います。より正確には、ChatGPTやClaudeの最新モデルのような高度なマルチモーダルAIが、スクリーンショット（視覚情報）とHTMLの簡略化されたテキスト情報の両方を解釈しています。「ログインボタン」というラベルや、ドアのアイコンなどを見て、「あ、これがログインするための要素だな」と判断するわけです。
編集部： なるほど。座標ではなく、意味を理解していると。
HARITA： そうです。これを我々は「Grounding（グラウンディング）」と呼んだりします。抽象的な「ログインしたい」という意図を、具体的な画面上の操作対象（要素）に結びつける能力です。
LaVagueのようなフレームワークでは、「World Model（世界モデル）」という概念を取り入れています。これは、「今の画面状態（State）」に対して、「ある行動（Action）」をとったら、「次の画面はどうなるか」を予測しながら進む仕組みです。
- ユーザーの意図: 「Amazonで一番安いUSBケーブルをカートに入れて」
- 現状認識: 今はトップページだ。検索バーがある。
- 行動計画: まず「USBケーブル」と入力して検索ボタンを押そう。
- 実行と検証: 検索結果画面になったか？ 価格順に並べ替えよう。
このように、彼らは都度判断しています。だから、検索バーの位置が右から左に移動しても、彼らは迷いません。人間が「あれ、レイアウト変わったな」と思いながらも操作できるのと同じです。
編集部： 柔軟性が段違いですね。まさにパラダイムシフトです。
HARITA： ただ、柔軟であるということは、裏を返せば「毎回違う動きをする可能性がある」ということでもあります。ここがエンジニアとしては悩ましい点なんですが（笑）。
Q2: Taxy.aiやLaVagueの実力と「まだできないこと」
編集部： 仕組みは理解できました。では、現時点での実力はどうでしょうか？ 実務でバリバリ使えるレベルですか？
HARITA： 結論から言うと、「限定的な用途なら実用的だが、完全な置き換えにはまだ早い」というのが一般的な見解です。
具体的に、Taxy.ai（ブラウザ自動化ツール）やLaVague（AIエージェント構築フレームワーク）を評価すると、いくつかの「壁」に直面します。
1. 速度（レイテンシ）の問題
HARITA： 従来のRPAは爆速です。プログラムが走るだけですから。しかし、AIエージェントは、ワンアクションごとにLLM（巨大なAIモデル）に問い合わせを行います。「画面を見る」→「考える」→「操作する」のサイクルを回すため、ボタンを一つ押すのに数秒かかることもザラです。1000件のデータを高速処理するような業務には、今のところ向きません。
2. コストの問題
HARITA： LLMへの問い合わせにはコストがかかります。ChatGPTの最新モデルやClaudeの最新版といった高性能モデルを使うと、1ステップごとにトークン（課金単位）を消費します。
複雑なタスクで試行錯誤を繰り返すと、1回の実行コストが無視できない金額になることもあり得ます。従来のRPAなら電気代とライセンス料で済んでいた処理が、従量課金になる点は経営的な判断が必要です。特に推論能力の高いモデルは高価になりがちですので、タスクの難易度に応じてモデルを使い分ける戦略が求められます。
3. ハルシネーション（誤操作）のリスク
編集部： AIが嘘をつく、というあれですね。
HARITA： ブラウザ操作におけるハルシネーションは、もっと物理的です。「送信ボタン」だと思って「削除ボタン」を押してしまう、といったリスクです。
LaVagueなどはかなり精度が高いですが、それでも100%ではありません。例えば、ECサイトで似たような商品を誤ってクリックしてしまうケースなどが報告されています。「読み取り専用」のタスクならいいですが、「書き込み・決済」を伴うタスクを全自動で任せるのは、まだ慎重になるべきでしょう。
編集部： オープンソースのLaVagueと、SaaS型のTaxy.aiなどはどう使い分けるべきでしょうか？
HARITA： Taxy.aiのようなSaaSは、セットアップが簡単で、開発者がいなくても使い始められるのが魅力です。「まずは動かしてみたい」というフェーズに適しています。
一方、LaVagueはオープンソースのフレームワークなので、エンジニアが自社のシステムに組み込んだり、使用するLLMをローカルモデル（Llamaシリーズなど）に切り替えてセキュリティを担保したりといったカスタマイズが可能です。機密情報を扱う企業なら、LaVagueのようなアーキテクチャを自社環境で構築する方が、ガバナンスの観点から安全と言えるでしょう。
Q3: どのような業務領域が「次世代RPA」に置き換わるか
編集部： 課題はあるものの、可能性は巨大です。具体的に、どのような業務ならこの技術の恩恵を受けられるでしょうか？
HARITA： 「非定型」かつ「判断が必要」な業務です。これがスイートスポットです。
ケース1：APIのないレガシーSaaSや管理画面の操作
HARITA： 世の中にはAPIが公開されていないSaaSがたくさんあります。これまでは人が手作業でやるか、壊れやすいスクリプトを書くしかありませんでした。
例えば、「複数のSaaSから特定の条件に合うユーザー情報を集めて、スプレッドシートにまとめる」といったタスク。画面仕様が微妙に変わっても動じないAIエージェントなら、APIがないシステムの「擬似的なAPI」として機能します。
ケース2：動的な情報収集（リサーチ）
HARITA： 「競合他社のサイトを巡回して、新製品のキャンペーン情報を集めて」という指示は、従来のRPAでは不可能です。サイトごとに構造が違うし、キャンペーンバナーが出る場所もランダムだからです。
AIエージェントなら、人間のように「あ、ここにNew Arrivalって書いてあるな」と認識して情報を取得できます。営業支援やマーケティングリサーチの分野では、革命的な効率化が期待できます。
ケース3：Human-in-the-loop（人間参加型）のワークフロー
HARITA： 実務において推奨されるのは、AIにすべてを任せるのではなく、「下書き」や「準備」をさせる使い方です。
例えば、経費精算システムへの入力。AIに領収書を読み込ませてブラウザに入力させますが、最後の「申請ボタン」だけは人間が確認して押す。これなら誤操作のリスクを回避しつつ、面倒な入力作業だけを9割削減できます。
編集部： なるほど。0か100かではなく、協働するわけですね。
Q4: 今後の展望：ブラウザ操作は「コモディティ」になるか
編集部： 最後に、この技術の未来について教えてください。2025年以降、どうなっていくと予測しますか？
HARITA： 今後、LAM（Large Action Model：大規模行動モデル）という言葉をよく耳にするようになるでしょう。Rabbit R1のようなデバイスが話題になりましたが、あれは「操作そのもの」を学習したモデルです。
今はまだ、LLMに画面を見せて「どうする？」と聞いていますが、将来的にはブラウザ操作に特化した専用モデルが登場し、速度も精度も劇的に向上するはずです。ブラウザ操作自体がOSやブラウザの標準機能（Copilotなど）に組み込まれていく可能性も高いですね。
編集部： その時、エンジニアや情シス担当者にはどんなスキルが求められますか？
HARITA： PythonでSeleniumのコードを書く能力は、徐々に不要になるかもしれません。代わりに必要になるのは、「AIエージェントをオーケストレーション（指揮）する能力」です。
「どのような指示を出せばAIが迷わないか」「どこにガードレール（安全策）を設けるか」「複数のエージェントをどう連携させるか」。コードを書くのではなく、業務プロセスそのものを設計し、AIに正しく意図を伝えるスキル。これこそが、次世代の自動化エンジニアのコアコンピタンスになるでしょう。
編集後記：ツール選定の前に「自動化の哲学」を問う
HARITA氏との対話を通じて見えてきたのは、単なるツールの進化ではなく、「自動化」という概念そのものの変質でした。
これまでのRPAは「ロボットに合わせる」必要がありました。人間が業務をロボットでもできるレベルまで細分化し、環境を固定化してあげる必要があったのです。しかし、Taxy.aiやLaVagueが提示する未来は、「AIが人間に合わせる」世界です。曖昧な指示を汲み取り、変化する環境に適応する。
もちろん、コストや速度の課題は残ります。しかし、「壊れやすい自動化」に疲弊している組織にとって、この技術は間違いなく検討に値する選択肢です。
重要なのは、技術が完璧になるのを待つことではありません。今の段階から「どの業務ならAIエージェントに任せられるか」を実験し、AIと協働する業務プロセスを構築し始めることです。
コメント