AIエージェントは本当に業務を動かせるのか — OpenClawで勤怠管理を自律化した記録

このプロジェクトについて

課題

2025年後半から、AIエージェントを業務に組み込む動きが急速に広がっています。OpenClaw、Claude Cowork、Microsoft Copilot Cowork、OpenAI Frontier――各社が「AIに業務を任せる」プラットフォームを次々とリリースし、「SaaSアポカリプス」という言葉まで生まれました。既存のSaaSが担ってきた業務を、AIエージェントが置き換えるという主張です。

しかし、実際のところはどうなのでしょうか。

• 社内独自のルールやワークフローを、AIエージェントは本当に理解できるのか
• コンテキストが複雑な業務を、安定して完遂できるのか
• APIコストは現実的な範囲に収まるのか
• セキュリティ上の懸念をどう管理するのか
• クラウドサーバー上で24時間運用できるのか

これらの疑問に対して、「やってみた」レベルではなく、本番業務に近い環境で検証した記録はまだ多くありません。

取り組み

私はFDE（Forward Deployed Engineer）として、このプロジェクトに携わっています。FDEとは、クライアント先に常駐し、業務を深く理解した上でそれをAI化して実現する役割です。一定のKPIを達成した段階で成果報酬をいただく形態で、Palantirが得意とする契約形態として知られています。

今回のクライアントでは、勤怠管理のチェック業務が大きな課題でした。

まず、ルールが複雑です。複雑な就業規則、部署ごとに異なる運用ルール、役職による例外条件、長年の属人化――これらが絡み合い、「このルールはA部署だけ適用」「係長以上はスキップ」「開催勤務と宿直が同日の場合は別の判定」といった条件分岐が無数に存在します。

さらに、ワークフローにも段階があります。勤怠チェックは一次承認・二次承認・最終承認と段階的に進み、それぞれ人事部内の異なる役職者が担当します。一次承認では汎用的なチェック（打刻漏れ、勤務時間の整合性など）を行い、承認が進むにつれてよりクリティカルなチェック（残業時間の上限超過、休憩時間の法定違反など）に移行します。フェーズごとにチェックすべきルールが異なり、前のフェーズの結果を踏まえて次のフェーズが動くという構造です。

現状では、人事部のメンバー約10名が毎月10日間かけて、この一連のプロセスを社員一人ひとりに対して目視で行っています。NGが検出された社員には個別にメールで修正依頼を送り、修正が戻ってきたら再チェックする――この往復が月末に集中します。

このプロジェクトのミッションは、100人日かかっている作業を10時間以内に完了させることです。承認ステップは日ごとに進むため1日で全て完結させることはできませんが、各フェーズの実行時間を1時間以内に圧縮し、10日間の承認サイクル全体で10時間――つまり人的工数を1/100にすることがKPI目標です。

単純なルールチェックだけならPythonで書けます。しかし、フェーズごとに異なるルールを適用し、前段の結果に応じて後段の処理を分岐させ、例外条件を部署や役職に応じて切り替える――こうしたワークフロー全体のオーケストレーションは、Pythonのスクリプトだけでは管理しきれません。LLM単体でも、こうした多段階の業務フローを安定して制御することは困難です。ここにOpenClawのようなAIエージェント基盤が必要になります。

なお、本シリーズでは主にルールチェックの自律化にフォーカスしています。ワークフロー制御（承認フェーズの管理、段階的なルール適用の切り替え）については、今後の記事で実現方法を公開していく予定です。

幸いにも、私が既にPythonとPlaywrightで構築した勤怠チェックシステムがあり、これをOpenClawのAIエージェントで自律化できるかを検証する良い土台がありました。

なぜクラウドサーバーで動かすのか

OpenClawのコミュニティを見ていると、専用のローカルマシンを用意して、捨てアカウントで動かしているケースが多いようです。暴走しても被害がそのマシン内で収まるようにするためで、合理的なアプローチだと思います。クラウドサーバー上で運用した事例はあまり見かけません。

本プロジェクトでクラウドサーバー（Hetzner Cloud）を選択したのは、いくつかの現実的な制約によるものです。

• クライアント案件のため、専用ハードウェアの調達が難しかった — 物理マシンの購入・設置には承認プロセスが必要で、実験のスピード感に合わない
• セキュリティ上、完全に隔離された環境が必要だった — クライアントの個人情報を含むデータを扱うため、社内ネットワークから切り離されたサンドボックスで、匿名化されたデータのみを処理する構成が求められた
• 24時間稼働の安定性 — ローカルマシンはスリープや停電で止まるが、クラウドサーバーは常時稼働できる

ただし、クラウドサーバーで動かすことにはリスクもあります。エージェントが外部にアクセスできる環境であること、サーバーの管理コストが発生すること、セキュリティ設定を自分で管理する必要があることなどです。これらの対策については、個別記事で詳しく説明します。

構築の流れ

本プロジェクトでは、OpenClawを使って以下を段階的に構築しました。

1. AIによるルールのコード化 — 勤怠チェックルールをAIに読ませ、検証用Pythonコードを自律生成させる
2. マルチエージェント構成 — 5つのAIエージェントに役割を分担し、コスト爆発とコンテキスト肥大化を防ぐ
3. Playwrightパイプライン — ブラウザ操作を自動化し、既存システムとの結果比較を毎回$0で実行する
4. 自律修正の検証 — HTMLの構造変更やルール追加に、AIエージェントがどこまで自律的に対応できるか

クライアント案件のため、具体的な企業名や詳細なルール内容は伏せています。なお、本記事の公開にあたっては、企業・個人が特定できない範囲でクライアントから許可をいただいています。技術的な構成・設定・コスト・失敗談はできる限りそのまま公開しています。

結果

指標	値
ベンチマーク一致率	100% (729/729件)
パイプライン実行コスト	$0/回 (LLM不要、Playwright + Python)
AI自律修正の成功率	明確な仕様変更は自律対応可能
カラム構造変更への対応	coderエージェントが動的カラム特定に自律リファクタ
月間運用コスト見込み	heartbeat $0 (ローカルLLM) + 定期実行$0 (スクリプト)

※ 上記の$0はパイプライン実行（Python/Playwright）と定期処理（ローカルLLM）のコストです。エージェント運用時にはmainエージェント（Gemini Flash）、coderエージェント（Claude Sonnet / Haiku）、analyzeエージェント（ChatGPT-5.4）のAPIコストが別途発生します。詳細は下記「エージェント構成」のコスト帯を参照してください。

---

なぜ「全部AIでやる」ではないのか

結果だけを見ると、「パイプライン実行コスト$0」「Pythonのルールチェック」と、従来のルールベースシステムと何が違うのかと思われるかもしれません。実際、勤怠チェックの実行そのものはPythonスクリプトで十分です。LLMに毎回ルールを判定させる必要はありません。

しかし、業務をAIエージェントで動かすということは、実行だけの話ではありません。

Pythonルールベースだけの限界

Pythonのルールベースシステムは、決まったルールを正確に繰り返すことには優れています。しかし、現実の業務では以下のような問題が起きます。

• 就業規則が改定されたとき、誰がコードを修正するのか
• HTMLの構造が変わったとき、パーサーが壊れたことに誰が気づくのか
• 新しい勤務種別が追加されたとき、マスターデータの更新からテスト実行まで誰がやるのか

ルールベースシステムは、書いた人がメンテナンスし続けることを前提にしています。書いた人が異動したり退職したりすれば、システムは徐々に現実とずれていきます。

LLM単体の限界

では、LLMに全てを任せればよいのでしょうか。実験の中で、これも現実的ではないことがわかりました。

• 勤怠ルールは数十種類あり、毎回プロンプトに渡すとコンテキストが肥大化し、コストが爆発する
• LLMの判定は確率的であり、同じデータに対して毎回同じ結果が返る保証がない
• 数値の比較や時刻計算のような再現性と正確性が求められる処理は、コードの方が圧倒的に信頼できる

本プロジェクトでも、コード生成をGemini Flashに任せたところ、正しいコードを生成できず何度もリトライを繰り返しました。たった1回のタスクで$8以上を消費し、それでも使えるコードは出てきませんでした。これが全部署×月次で回れば、判定精度も出ないままAPIコストだけが積み上がることになります。

AIエージェント基盤（OpenClaw）が解決すること

OpenClawのようなAIエージェント基盤が提供するのは、Pythonの正確性とLLMの柔軟性を組み合わせ、それを業務として統率する仕組みです。

実行はPython、判断と適応はLLM、統率はエージェント基盤。 この三層構造が、業務AIエージェントの核です。

具体的には以下のような仕組みが用意されています。

仕組み	役割	なぜ必要か
SOUL.md	エージェントの人格・行動原則	「何をしてはいけないか」を明示し、暴走を防ぐ
AGENTS.md	ルーティングテーブル・委任ルール	どのタスクをどのエージェント/モデルに振るかを設定ファイルで固定する
MEMORY	日次メモ・長期記憶	セッションが切れても文脈を引き継ぐ。属人化の知識をファイルに残す
Skill (SKILL.md)	業務スキルの定義と手順書	AIが修正すべき対象と手順を理解するためのドキュメント
セッション隔離	サブエージェントの独立実行	重い処理のコンテキストがメインに残らない。コスト爆発を防ぐ
モデルルーティング	タスクごとのモデル選択	コード生成はSonnet、簡易処理はFlash、定期処理はローカルLLM

たとえば、就業規則が改定されたとき。Pythonルールベースだけなら、開発者がコードを修正する必要があります。LLM単体なら、そもそもルールを正確に覚えていません。OpenClawの構成では、ユーザーが「このルールはC部署だけ係長以上はスキップして」と一言指示すれば、mainエージェントがcoderエージェントに振り分け、coderはSKILL.mdの定義ファースト原則に従ってTSV定義を更新し、コードを修正し、テストを実行します。ルールの知識はファイルに残り、実行はコードで行い、判断と適応はLLMが担う。

HTMLの構造が変わったときも同様です。本プロジェクトでは実際に2カラムが追加される変更が発生し、coderエージェントに「ヘッダー名で動的にカラム位置を特定する方式に変更して」と指示したところ、SKILL.mdへの設計原則の追記からコードのリファクタリング、テスト実行まで自律的に完遂しました。

三層構造のまとめ

層	担当	得意なこと	苦手なこと
実行層 (Python)	ルールチェック、数値比較、時刻計算	正確性、再現性、コスト$0	変化への適応、曖昧さの処理
判断層 (LLM)	コード生成、ルール解釈、構造変更対応	柔軟性、自然言語理解	再現性、コスト管理
統率層 (OpenClaw)	ルーティング、記憶、セッション管理、暴走防止	業務フロー全体の一貫性	― (仕組みであり、自ら判断はしない)

「全部AIでやる」のではなく、それぞれの層が得意なことだけを担当する。この設計こそが、業務AIエージェントを現実的にするための鍵だと考えています。

---

なぜこのプロジェクトを公開するのか

AIエージェントによる業務自動化は、技術的には可能です。しかし、「可能」と「実用的」の間には大きな距離があります。

このプロジェクトを通じて実感したのは、AIエージェントには明確な強みと、同じくらい明確な限界があるということです。明確な仕様変更の実行は得意ですが、「何が問題かわからない」調査系のタスクはまだ人間の領域です。何でもかんでもAIエージェントに丸投げしても、期待した結果は出ません。コスト管理を怠るとAPIコストが一晩で数ドルに達しますし、設定を誤るとエージェントが暴走します。

これらの経験を、抽象的な議論ではなく、具体的な設定ファイル・コスト記録・失敗事例とともに共有することで、同じようにAIエージェントの業務導入を検討されている方の参考になればと考えています。

---

技術スタック

レイヤー	技術
AIエージェント基盤	OpenClaw (v2026.3.24)
高精度モデル (コード生成・分析)	Claude Sonnet 4.6
効率モデル (オーケストレーション・Web処理)	Gemini 3 Flash
ローカルモデル (定期処理・heartbeat)	Gemma3 4B (Ollama)
ブラウザ自動化	Playwright (Python)
サーバー	Hetzner Cloud (4vCPU / 16GB)
検証・デバッグ	Claude Code (Opus)

---

エージェント構成

本プロジェクトでは、1つのAIエージェントに全てを任せるのではなく、5つのエージェントに役割を分離しました。

エージェント	モデル	役割	コスト帯
main	Gemini 3 Flash	オーケストレーション、タスク振り分け	低
heartbeat	Gemma3 4B (ローカル)	死活監視応答	$0
monitor	Gemini 3 Flash	Web要約、定期チェック	低
coder	Claude Sonnet / Claude Haiku	コード生成・Skill修正 / ソース検証	中
analyze	ChatGPT-5.4	深い分析、比較レポート	中

この構成に至るまでには、コスト爆発やエージェント暴走といった失敗を経ています。それらの詳細は個別記事で紹介します。

---

このプロジェクトで学んだこと

AIエージェントの強み

• 明確な仕様変更は自律実行できる — 「このルールはC部署だけ係長以上はスキップして」と一言で指示すれば、定義ファイルの更新からコード修正、テスト実行まで完遂する
• ブラウザ操作の自動化判断ができる — Webページへのログイン、フォーム入力、結果取得をLLMが自律的に実行できる（ただし固定化すればLLM不要で$0にできる）
• マルチモデル構成でコストを最適化できる — 全タスクを高価なモデルに任せるのではなく、タスクの性質に応じてモデルを使い分ける

AIエージェントの限界

• 「何が問題かわからない」調査はまだ難しい — ベンチマーク不一致の原因特定のような探索的タスクは、コード全体を見渡せる人間+高精度モデルの方が速く正確
• 見た目が同一の文字を区別できない — Unicodeの罠（○ vs 〇）はAI生成コードで特に起きやすく、テストデータとの実データ突合が必須
• コスト管理は能動的にやる必要がある — 放置すると1日で数ドルが消える。ローカルLLMの活用やセッション隔離が重要

運用上の教訓

• 定義ファースト原則 — AIが自律修正できるようにするには、コードにハードコードせず、定義ファイル（TSV/YAML/SKILL.md）をsingle source of truthにする
• 設定ファイルに落とし込む — 「プロンプトでお願いする」運用は脆い。ルーティング、モデル選択、セッション設定は全て設定ファイルに明示する
• 暴走対策は初日にやる — heartbeat設定、proactive指示の制限、セッション隔離は、エージェントを動かす前に設定しておく

---

シリーズ記事

本プロジェクトの詳細を、以下のシリーズ記事で順次公開していきます。

回	テーマ
第1回	AIエージェント基盤を構築する — サーバー設計とコスト戦略
第2回	AIにルールを「コード化」させる — 3モデルの自律生成力を比較する
第3回	暴走するAIエージェントを制御する
第4回	5エージェント構成 — コンテキスト爆発を防ぐ設計
第5回	93%から100%へ — AI生成コードのデバッグ全記録
第6回	定義ファースト — AIが自律修正できる設計原則
第7回	Playwrightパイプライン — 実行コスト$0の自動化
第8回	HTMLが変わったとき、AIは自律的に対応できるか

---

対象読者

• AIエージェントの業務導入を検討しているエンジニア
• OpenClawや類似のAIエージェント基盤に興味がある方
• SaaSの業務をAIで置き換えることの現実性を知りたい方
• マルチモデル構成やコスト最適化の実例を探している方

注意事項

本プロジェクトはクライアント案件の一環として実施しています。具体的な企業名、詳細な業務ルール、認証情報等は公開していません。技術構成・設定方法・コスト実績・失敗事例に焦点を当てて記載しています。

勤怠管理システムは比較的シンプルなワークフローであり、より複雑な業務への適用には追加の検討が必要です。AIエージェントの業務導入における初級レベルの実践例として、参考にしていただければ幸いです。

また、私自身OpenClawの利用経験はまだ浅く、見落としている設定やより適切な方法、一般的なベストプラクティスがあるかもしれません。もし改善点やご指摘がありましたら、ぜひコメントやLinkedInでお知らせいただけると幸いです。