Claude CodeとBedrockで勤怠自動化！成功率93.3%を叩き出したMCP活用術

• 事実：平田機工がMCPとClaude Code、Bedrockを連携させPlaywrightによる勤怠自動化の実証実験を実施。
• 技術的変革：LLMを単なるコード生成器ではなく画面検証のガードレールとし、2段階JSON化と画像・HTML切り出しでパース精度を向上。
• 現場への影響：工数6時間で成功率93.3%を達成。生成コードの理解負債を防ぎ、HITL（人間介入）設計をどう組み込むかが鍵に。

深夜の障害対応でヘトヘトになりながら、ヘッドレスブラウザのログと格闘した経験はエンジニアなら誰しもがあるはずだ。「画面上のボタンをクリックしたはずなのに何も起きない」「CI上でのみ再現する原因不明のタイムアウト」といった不条理に直面し、泥沼のデバッグ作業に何時間も溶かしてしまう暗黒の時間——。既存システムのデータベースやAPIを直接更新できない制約下で、Web画面経由のブラウザ操作自動化（RPA）をAIエージェントに委ねようとする試みは常に魅力的に映るが、その裏には決定論的なコードと不確実なDOM構造が引き起こすスパゲッティ化の罠が潜んでいる。

今回、平田機工株式会社の情報システム部門が公開した検証事例は、まさにこのブラウザ自動化の泥沼に対する極めて現実的な処方箋を示している。同社は社内の勤怠管理システムを対象に、Playwright、MCP（Model Context Protocol）、Claude Code、そしてAmazon Bedrockを統合した自動化フローを構築した。私が特に唸らされたのは、ローカル環境を一切汚さないDockerベースの開発環境設計と、Node.jsとPythonの混在環境におけるブラウザリソースのスマートな共有アプローチだ。

コンテナ内でPlaywrightを動かす際の最大の課題はデバッグの可視化にある。彼らは公式イメージ『mcr.microsoft.com/playwright/python:v1.62.0-jammy』をベースに、Xvfb（仮想ディスプレイ）、x11vnc、noVNCを組み合わせ、ホスト側のブラウザ（localhost:6080）からコンテナ内部のデスクトップ画面をリアルタイムに操作・目視できる環境を作り上げた。さらに、MCPサーバー（Node.js版の@executeautomation/playwright-mcp-server）と自動化スクリプト（Python）を同居させるにあたり、環境変数『PLAYWRIGHT_BROWSERS_PATH=/opt/ms-playwright』を指定してChromiumの実体を1つに固定。ストレージ容量の無駄を削ぎ落としつつ、パスの競合を見事に解決している。

この環境下で、エージェントであるClaude CodeはMCP経由でPlaywrightを自律的に操作し、実際のWeb画面を探索しながらエレメントのセレクタや画面遷移のロジックを発見・コード化していく。従来であれば、エンジニアがDevToolsを開いて複雑に入り組んだDOMツリーから最適なCSSセレクタやXPathを手動で拾い上げ、愚直にコードへ落とし込んでいた泥臭い作業が、MCPのインターフェースを介することで一気に自動化されたのだ。これは単なる開発効率化にとどまらず、UI自動化スクリプト構築におけるパラダイムシフトと言っても過言ではない。

しかし、Playwright単体に画面操作を委ねるアプローチには構造的な限界が存在する。我々現場のエンジニアが日々苦しめられているのは、セッションごとに動的生成されるボタンID（例: ‘BTNDTL2026_9_150’）や、ラベルテキストを持たないアイコン画像ボタン、あるいは同一画面内に類似したクラス名を持つ要素がズラリと並ぶレガシーなHTML構造だ。指定したセレクタを機械的にクリックするだけのPlaywrightは、「意図しない別の日付の詳細画面を開いて誤打刻する」といった人間の感覚ではあり得ない致命的な判断ミスを平然と犯す。プログラムは間違った挙動を完璧に実行してしまい、結果としてデータ破壊という最悪のデッドロックを引き起こすのだ。

平田機工の設計思想が際立っているのは、Amazon Bedrock（Claude 3.5 Sonnet）を単なるコード生成アシスタントとしてではなく、UI操作の「ガードレール（検証者）」としてシステム内に直接組み込んだ点にある。人間が画面を見て無意識に行っている「正しい画面に遷移したか？」「必要なデータが揃っているか？」という状況判断をLLMのマルチモーダル能力で代替させているのだ。技術コミュニティにおいても、AnthropicによるClaudeのPlaywrightスキルやMCP連携を巡り「どこまでAIにテストや画面操作を任せられるか」という議論が活発化しているが、本事例はその限界に対する具体的な解決策を提示している。

特に注目すべきは、LLMの解析精度を極限まで高めるために導入された3つのテクニックだ。

• マルチターン（二段階）解析の徹底: カレンダーや集計表のような二次元構造のHTMLテーブルをLLMに一発で解釈させようとすると推論が不安定になる。そこで、第1段階で画面のテーブル構造を純粋なJSONデータへと構造化・変換させ、第2段階でそのJSONをプロンプトに注入して詳細な条件判断を行わせるアプローチをとっている。
• 決定論的プロンプティング（temperature: 0）: 解析結果のゆらぎや揺らぎによるハルシネーションを排除するため、Bedrock呼び出し時のtemperatureパラメーターを厳格に0に固定。同一画面に対しては常に決定論的な解析結果が得られるよう制御している。
• コンテキストウィンドウの最適化（HTML切削＋画像）: トークン上限と処理コストを抑えるため、ターゲット日付の周辺テキスト（前後10,000文字程度）を抽出するスクリプト（extract_relevant_html）を実装。視覚的なスクリーンショット画像と部分HTMLの双方をBedrockに渡すことで、動的IDや画像ボタンの誤認率を激減させている。

決定論的なPythonコードによる自動操作と、確率論的なLLMによる定量的ガードレールの組み合わせ。この「ハイブリッド型のアーキテクチャ」こそが、脆いブラウザ自動化をミッションクリティカルな実務に耐えうる堅牢なシステムへと進化させる鍵なのである。

平田機工が公開した検証結果のデータは、現代のAI駆動開発がもたらす圧倒的な生産性と、その裏に潜む実務上の課題を雄弁に物語っている。以下にその実証スペックと評価をまとめた。

約1,400行に及ぶプロダクションレベルのPythonコードを、環境構築の時間を含めてわずか6時間で書き上げたという実績は脅威的だ。しかも成功率は93.3%に達し、残りの6.7%の失敗ケースにおいても、Bedrockのガードレールが「意図しない画面遷移」を検知してスクリプトの実行を自動停止させている。つまり、データの一貫性を損なう事故は0件だったということだ。

しかし、シニアエンジニアとして私が最も強く警告したいのは、この「爆速開発」の陰に忍び寄る『理解負債（Comprehension Debt）』の問題である。MCPとClaude Codeが自動出力した1.4 KStepのコードは、短期的には完璧に動作するかもしれない。だが、基幹システム側の仕様変更やUIのリニューアルが行われた際、その自動生成されたコードの内部ロジックや依存関係を人間が即座に理解し、保守・デバッグできるだろうか？ コードを書くコストが限りなくゼロに近づく一方で、コードを理解し責任を持つコストはむしろ増大しているのだ。

また、昨今叫ばれる「市民開発（非エンジニアによる業務自動化）」の文脈においても注意が必要だ。「ClaudeやMCPを使えばノーコード感覚で業務部門がRPAを作れる」という安易な幻想を抱くのは危険である。どの画面でリスクが発生し、どの部分にBedrockによる判定（ガードレール）を挟むべきか、そしてエラー時にいかに人間にバトンタッチするかというHITL（Human-in-the-Loop）の設計は、システムの非機能要件やビジネスリスクを熟知したエンジニアにしか不可能な領域だからだ。

我々エンジニアは、単にキーボードを叩いてコードを書く職人から、AIエージェントと人間、そしてレガシーシステムの間を調停する「アーキテクト」へと脱皮を迫られている。あなたは自社の開発現場で、AIが吐き出した数千行のコードの保守責任を背負う覚悟ができているだろうか？ 明日から取り組むべきは、生成されたコードのテストコード自動化と、明確なHITL運用ルールの策定である。