Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

通勤手当申請チェックエージェント開発のリアル

Avatar for WHIsaiyo WHIsaiyo
December 20, 2025

 通勤手当申請チェックエージェント開発のリアル

井上大貴さんによるJAWS-UG Presents AI Builders Dayの登壇資料です。

Avatar for WHIsaiyo

WHIsaiyo

December 20, 2025
Tweet

More Decks by WHIsaiyo

Other Decks in Technology

Transcript

  1. © 2025 Works Human Intelligence Co., Ltd. 通勤⼿当申請チェックエージェント開発のリアル JAWS-UG Presents

    - AI Builders Day 登壇資料 2025年12⽉20⽇ 株式会社Works Human Intelligence Product Div. 井上⼤貴(いのうえだいき)
  2. © 2025 Works Human Intelligence Co., Ltd. AGENDA 2 01

    02 03 04 05 イントロダクション ソリューション 運⽤する中で得た教訓 まとめ
  3. © 2025 Works Human Intelligence Co., Ltd. 4 ⾃⼰紹介 イントロダクション

    • 井上 ⼤貴 (Daiki Inoue) • AI エージェントの研究開発 @ 株式会社Works Human Intelligence ◦ 昨年までコンサル部⾨で主⼒製品(COMPANY)の周りで動かす ツールの開発に従事 ◦ re:Invent 2024 の参加をきっかけにAIエージェント開発に従事 • 福島県福島市 出⾝/在住 • リアル JAWS-UG 初参戦です! ◦ ↓Geminiが⾔ってました。お⼿柔らかにお願いします(冗談です)
  4. © 2025 Works Human Intelligence Co., Ltd. 5 会社紹介 イントロダクション

    ⼤⼿企業および公共‧公益法⼈向け統合型⼈事システムを開発‧販売‧サポートしています 商号 株式会社Works Human Intelligence 代表者 代表取締役最⾼経営責任者(CEO)安斎 富太郎 親会社 株式会社WHI Holdings 事業内容 ⼤⼿企業向け統合型⼈事システム「COMPANY®」の開発‧販売‧サポート、 HR関連サービスの提供 資本⾦ 100百万円 本社 〒105-5510 東京都港区虎ノ⾨2-6-1 虎ノ⾨ヒルズステーションタワー10階 事業所 東京(本社、新宿オフィス)、⼤阪、名古屋、福岡、広島 事業開始 2019年8⽉1⽇ 従業員数 2,198名(連結)※2024年12⽉末時点 電話番号 03-5575-5277 ⼦会社 株式会社ワークスビジネスサービス 株式会社セキスイビジネスアソシエイツ Webサイト https://www.works-hi.co.jp
  5. © 2025 Works Human Intelligence Co., Ltd. 6 統合型⼈事システム「COMPANY」 イントロダクション

    年末調整申告 ⾝上届出 給与明細照会 ⼈事考課 ⼈事情報 検索‧照会 Web Service 異動配置案作成 発令 各種帳票作成 福利厚⽣ 給与/賞与⽀給 税務処理 退職⾦⽀給 社会保険料計算 出向費⽤ 資格管理 個⼈情報管理 ⼈事‧給与 勤務予定作成 実績⼊⼒ 勤務状況把握 ⼯数管理 就労‧プロジェクト管理 ID権限申請 ⼈事情報連携 特権ID管理 棚卸 Identity Management 要員分析 研修管理 各種KPIチェック Talent Management シリーズ 提出物進捗管理 ⼊社⼿続 雇⽤⼿続管理 ⼊社 在職 退職 ⼈事給与から勤怠管理、タレントマネジメントに⾄るまで、幅広い領域をカバーしています。
  6. © 2025 Works Human Intelligence Co., Ltd. 7 統合型⼈事システム「COMPANY」 イントロダクション

    業種‧業態を問わず、数千名〜数万名規模の⼤⼿法⼈にご利⽤いただいています。 ※3 2024年12⽉末時点の契約法⼈における     「COMPANY ⼈事」の契約ライセンス数合計 管理する⼈事データ数 約 540万⼈※3 国内⼤⼿企業※1の 3社に 1社が 当社製品を利⽤ (当社調べ) ※1 従業員数3,000⼈以上 契約継続率 98%※2 ※2 2024年度 ⾦額ベース
  7. © 2025 Works Human Intelligence Co., Ltd. 内容 「通勤⼿当申請のチェック」という定型業務を効率化する AI

    エージェントを LangGraph で開発‧運⽤する中で、 発⽣した課題とその解決策を中⼼にお話しします。 最新の技術を駆使してソリューション構築、というようなきれいなお話ではなく、どちらかというと実際に運⽤ している中で発⽣した課題に焦点を当てた泥臭い内容になります。 対象 • AIエージェントの開発に取り組んでいる⽅∕これから取り組もうと思っている⽅ • 定型業務の効率化に取り組んでいる⽅∕これから取り組もうと思っている⽅ 8 本⽇お話しする内容 イントロダクション
  8. © 2025 Works Human Intelligence Co., Ltd. 9 なぜ通勤⼿当申請の承認なのか 通勤⼿当申請のチェック(承認)業務は担当者の負荷が⾼い業務の1つです。その最⼤の要因は規定の複雑さに起因す

    るチェック時の確認観点の多さ/確認作業の煩雑さにあります。 イントロダクション チェック観点 ⾃宅からオフィスまでの直線距離が 1.0km以上の場合が⽀給対象。 1.0km未満の場合は徒歩での通勤。 乗⾞駅は原則⾃宅の最寄り駅とする。 最寄り駅以外からの経路の場合は、 その経路が最寄り駅からの経路よりも 安価な場合のみ承認する。 ただし、役員の場合は......... . . . . 確認⼿順 1. 申請者の住所/申請者の事業所の 住所を確認する。 2. 地図アプリを開き、新住所と事業所 までの直線距離を算出する。 1. 地図アプリを開き、申請者の最寄り 駅を確認する。 2. 乗車駅∕最寄駅からの経路の最安 値を検索し、2つの経路の最安値を 比較する。 3. … . . . .
  9. © 2025 Works Human Intelligence Co., Ltd. 通勤⼿当申請の承認は確認観点が多く⼿順も複雑に分岐するためこれまで RPA が困難な領域でしたが、状況に応じて⾃

    律的にツールを実⾏するAIエージェントの登場により、⾃動化の実現が現実的になりました。 10 なぜ通勤⼿当申請の承認なのか イントロダクション ⾃宅と事業所の距離を測定 ⾃宅の最寄り駅を特定 徒歩での通勤が必要 申請された経路の ⽅が安い? 最寄駅からの経路の最安値 申請された乗⾞駅からの最安値を⽐較 申請者の役職を確認 . . . . . . . . . . . NO YES YES NO NO YES 1.0km以上? 乗⾞駅=最寄り駅? 申請情報の取得 チェックする観点の確認
  10. © 2025 Works Human Intelligence Co., Ltd. 11 なぜLangGraphなのか 複雑に分岐するフローに対し、LLMの柔軟で⾃律的な判断を活かしつつ、業務としてルールから逸脱させないための厳

    密な制御を両⽴できるオーケストレーションフレームワークであるため LangGraph を採⽤しました。 イントロダクション 実際に定義しているGraph構造
  11. © 2025 Works Human Intelligence Co., Ltd. 13 処理の流れ Slack

    アプリをメンションしてエージェントを呼び出します。通勤⼿当申請のチェックを依頼した場合は、申請データを アップロードするように要求されるのでチェックしたい申請データをアップロードします。 ソリューション
  12. © 2025 Works Human Intelligence Co., Ltd. 15 アーキテクチャ Slack

    アプリは ECS に、エージェント(LangGraph)は AgentCore Runtime にデプロイしています。利⽤者が普段使い 慣れているツールからエージェントを呼び出せる設計にしたく、Slack アプリを採⽤しました。 ソリューション
  13. © 2025 Works Human Intelligence Co., Ltd. 17 効果 定量効果

    • 直近(12/1~8)の測定では92%(60/65)の精度で期待結果とエージェントの出⼒が⼀致 • 差戻するべき申請を承認してしまう「誤承認」の発⽣は0件 • 差戻までのリードタイムが約40%削減 定性効果 • 承認者の⼼理的負荷の削減(エージェントが承認と判断している申請は⾃信をもって承認処理が出来る) ソリューション
  14. © 2025 Works Human Intelligence Co., Ltd. 19 モデルを更新しても必ずしも精度が改善するわけでない(1) メインのモデルは

    Claude Sonnet を利⽤しています。定期的に新しいバージョンがリリースされるため、その都度エー ジェントの精度改善を楽しみにモデルを更新しています。しかし、バージョンの更新後、これまで正しく判定できてい た内容を誤って判定してしまうような事象がいくつか発⽣しました。 運⽤する中で得た教訓 例えば 新経路の開始⽇は申請⽇に対して3ヶ⽉ 以内の未来または6ヶ⽉以内の過去であ る必要がある。この範囲外の申請につい ては本⼈への事情確認が必要である。 開始⽇=申請⽇の申請をチェックさせると... Claude Sonnet 4.0 Claude Sonnet 4.5 開始⽇と申請⽇は同じため 適合とします。 申請⽇と開始⽇が同⼀である場 合の取り扱いが不明なため 不適合とします。 今まで適合と出来ていた観点が不適合と 判定されるようになってしまった。 エージェントの⾔い分もわからなくはない...
  15. © 2025 Works Human Intelligence Co., Ltd. 20 モデルを更新しても必ずしも精度が改善するわけでない(2) DeepEval

    という OSS の LLM 評価フレームワークを利⽤しています。いわゆる LLM-as-a-Judge です。おかげでモデル やプロンプトの積極的な更新が可能になりました。評価システムは初期段階から構築しておくべきだと思います。 運⽤する中で得た教訓 https://deepeval.com/ 申請ごとに判定結果の根拠(≒サマリ)を出⼒させ、 その内容が期待結果と同義かどうかを確認している
  16. © 2025 Works Human Intelligence Co., Ltd. 21 ユーザーがFBしやすい仕組みを作ることが重要(1) 業務の補助的な位置づけである本エージェントは、精度が低いと使われなくなります。特に社内でテスト運⽤を開始し

    た直後は殆どの申請が差戻と判定されてしまい、かえってユーザーの⼯数を増やしてしまうような状態でした。 そのうえ、FBの⽅法として「エージェントの判定で不具合や不明点があったらいつでも連絡して下さい」というように 案内していたため、段々とFBが減っていき、エージェントの精度が向上せず、利⽤頻度も下がっていきました。 運⽤する中で得た教訓
  17. © 2025 Works Human Intelligence Co., Ltd. 22 ユーザーがFBしやすい仕組みを作ることが重要(2) そんな状況を打開するため、エージェントが実施したすべての判定結果を積極的にモニタリングするようにしました。

    申請ごとの判定結果とその根拠で誤りや⽭盾がないかを細かくモニタリングしました(⼈⼒)。モニタリングの結果は 全てユーザーに対して共有し、認識が合っているかをユーザーに確認するようにしました。 運⽤する中で得た教訓 全ての判定結果の内容を確認し ユーザーに結果を共有
  18. © 2025 Works Human Intelligence Co., Ltd. 23 ユーザーがFBしやすい仕組みを作ることが重要(3) ユーザーは開発側のモニタリングの結果が正しいか間違っているかをFBするだけでよいため、FBの数が向上しました。

    それが精度改善につながり、今では全ての申請に対してエージェントが利⽤されています。 エージェント開発は精度改善が課題になりやすいため、ユーザーからのFBを得やすい設計が重要になります。 運⽤する中で得た教訓
  19. © 2025 Works Human Intelligence Co., Ltd. 24 意外とコストは削減できる 当初は1申請あたり2ドル以上かかってしまうような状況でしたが、プロンプトキャッシングやノードごとにモデルを使

    い分けることでコストは1/3以下に削減出来ました。また当初MCPは積極的に活⽤する⽅針でしたが、MCPを利⽤すると トークンの消費が⼤きくなる傾向があるため、ツールは基本的に独⾃に定義しています。 運⽤する中で得た教訓 https://aws.amazon.com/jp/blogs/news/effectively-use-prompt-caching-on-amazon-bedrock/ プロンプトキャッシングの参考記事 ノードごとにモデルを分ける例
  20. © 2025 Works Human Intelligence Co., Ltd. 26 まとめ 定型業務の複雑性と

    AIエージェントの可能性 ⼀般的に「定型業務」と呼ばれる業務 も細かく⾒ると「⾮定型」の要素が多 く含まれる。 ⇒⾮定型業務に限らず、定型業務も AI エージェントで効率化‧⾃動化するべ き領域 LangGraph による 柔軟性と制御の両⽴ LangGraph は複雑に分岐するワークフ ローに対し、LLMの柔軟な⾃律判断を 活かしつつ、業務として逸脱させない ための厳密な制御を両⽴できるオーケ ストレーションフレームワーク。 開発者による継続的な改善が より⼀層重要 ‧ユーザーからのFBを得やすい設計が 重要。時には愚直なモニタリングも。 ‧LLM-as-a-Judge を⽤いた定量的な ⾃動評価基盤 ‧プロンプトキャッシングやモデル使 い分けによるコスト削減