Amazon Web Services ブログ

Amazon Bedrock AgentCore を使った業務支援 AI Agent 開発

本ブログは株式会社 Works Human Intelligence 様と Amazon Web Services Japan 合同会社が共同で執筆しました。

Works Human Intelligence (以下、WHI) は「人に真価を。」をコーポレートブランドに掲げ、日本の大手企業および公共・公益法人向け統合型人事システム COMPANY の開発・販売・サポートの他、HR 関連サービスの提供を行っています。WHI は人事部門が定型業務ではなく戦略的な業務に取り組めるよう尽力しており、今回は AWS の Generative AI Innovation Center (以下、GenAIIC) とともに取り組んだ AI Agent を活用したプロダクト構築から得た知見についてご紹介します。

背景 Overview

人事システムをご利用されるお客様は、組織変更や人事制度変更、社員情報の更新といった多くの場面で対応が必要となります。WHI では AI Agent を活用することで、担当部署の方々の業務負荷軽減、生産性向上に寄与できることを期待しています。実際に AI Agent を活用したプロダクトの構築に取り組んだところ、いくつかの悩みが生じました。WHI が課題解決に向けて取り組む中で、GenAIIC には新しい観点を追加し、良いものを作るためのサポートを期待していました。

今回のプロジェクトの対象は、担当部署の方の業務を支援する 2 つの AI Agent です。
1 つ目の AI Agent (以下、通勤手当エージェント) は引越しの際などに生じる通勤手当申請の承認に関するエージェントです。2 つ目の AI Agent (以下、ブラウザ操作エージェント) は、お客様に代わって COMPANY を操作するエージェントとなっています。
ここからは通勤手当エージェント、ブラウザ操作エージェントの順に、2 つのエージェントの課題と解決方法をお伝えします。

通勤手当エージェント

課題 Challenge

通勤手当エージェントは、通勤手当申請の承認という定型業務を支援するエージェントです。WHI では既に LangGraph と Amazon ECS、AWS Fargate を用いた PoC を進めていましたが、開発途中で Amazon Bedrock AgentCore がリリースされたため、移行を検討し始めました。
COMPANY とシームレスに統合する AI Agent の実現に向けての Amazon Bedrock AgentCore でのソリューション構築、および現行開発している AWS Fargate や Amazon Cognito を用いた認証認可の実装を含んだ統合的なマルチエージェント環境への移行を GenAIIC と共に実施したいと考えました。

解決策 Solution overview

通勤手当エージェントは LangGraph と Amazon ECS を利用して開発していましたが、全て同じ ECS タスクとして起動するモノリシックな構成になっていることに対して WHI も懸念がありました。そこで、サブエージェントは個別に Amazon Bedrock AgentCore Runtime で起動するように変更しました。マルチテナント対応が求められていたため、自分たちで構築できる自由度を求めて Amazon DynamoDB と Amazon Cognito を用いてテナント管理をすることとしました。

アーキテクチャ

通勤手当エージェントは Slack が呼び出しの起点となるため、呼び出されたタイミングで認証を行い、リクエストに対して適切な各サブエージェントが処理を行う仕組みとなっています。

architecture1

結果 Results and Impact

プロジェクトの途中で Amazon Bedrock AgentCore が GA したことで、本格的に活用できるようになりました。通勤手当エージェントは LangGraph を継続して利用していますが、サブエージェントは別の Runtime で起動するように変更を行いました。この対応により将来のサブエージェント拡充を容易にしています。今後はサブエージェントを束ねるスーパーバイザーエージェントを Strands Agents に変更することも検討しています。
また、今まではエージェントの状態を確認するために Langfuse をホストしていたため運用コストが発生していましたが、Amazon Bedrock AgentCore Observability に変更することで負荷が軽減されました。

ブラウザ操作エージェント

課題 Challenge

ブラウザ操作エージェントは、ブラウザを使い、COMPANY にアクセスし、内容を確認した後、操作を行なってエビデンスを取得する処理を行います。構築は LangGraph と Playwright MCP で進めていました。ブラウザ操作のトークン数は、以下のアプローチによって、88% の削減効果が確認できていました。

  • エージェントループ (AI と Playwright MCP との会話履歴) から過去の不要になった部分を削除
  • Playwright MCP の戻り値からブラウザ操作に不要な部分を削除
  • TOOL 部分のプロンプトキャッシュの有効化

しかしながら、独自実装に依存していたため、Strands Agents への移行が困難といった課題を抱えていました。また、より一層トークンを削減する方法について検討していました。こうした中で GenAIIC と協働することとなりました。

解決策 Solution overview

ブラウザ操作エージェントは Strands Agents を使い、いくつかのブラウザ操作ツールを試しながら、処理がうまくいくことを確認し、その後は利用するトークン数の削減に取り組みました。エージェントのワークフローは以下の 5 つのステップで構成されています。

  1. 操作テンプレート選択 : ユーザーの指示に基づき、ナレッジベースから最適な操作テンプレートを検索します。
  2. 操作マニュアル作成 : 取得したテンプレートのプレースホルダーを、別のナレッジベースから取得した情報で置換します。
  3. ブラウザ操作 ( 現状確認 ): 作成したマニュアルに基づき、ブラウザを操作して現状の確認を行います。
  4. 変更案作成: 現状確認で得られた情報 (CSV など ) を基に、変更案を作成し、ユーザーに提示します。
  5. 変更実行 ( ブラウザ操作 ): ユーザーの承認後、変更案に基づき再度ブラウザを操作して変更を実行します。

基本的なワークフローを定めていますが、ユーザーのインプットに情報が足りない場合や、一部の作業のみ行うことなどもエージェントの自立的な判断で柔軟に対応できます。

アーキテクチャ

ブラウザ操作エージェントから COMPANY へのアクセスには IP アドレス制限を行なっているため、VPC 内に Amazon Bedrock AgentCore Runtime を配置し、NAT ゲートウェイ経由で固定 IP アドレスでアクセスする構成としました。また、操作テンプレートや操作手順作成時の補助情報を格納するナレッジベース、短期的な情報を保存する S3 バケットも構築しました。

architecture2

結果 Results and Impact

ブラウザ操作エージェントは Strands Agents を利用して構築しました。ブラウザ操作ツールは browser-use、Playwright、fast playwright を試し、fast playwright が消費するトークン数が最も少ないことを確認しました。加えて、Bedrock のプロンプトキャッシュの有効化やシステムプロンプトの変更といった改善を WHI と GenAIIC で協力して行ったことで、一回の処理でかかる費用を最大 97% 削減することに成功しました。

主な改善施策は以下の通りです。

  • ユーザーメッセージも対象としたプロンプトキャッシュの活用 : Bedrock のプロンプトキャッシュ機能を有効化 (2,171 円 → 307 円 )
  • エージェントの行動最適化 : サブエージェントのプロンプトを改善し、不要な操作を削減 (307 円 → 154 円 )
  • モデルの変更 : モデルを Claude Sonnet 4.5 から Haiku 4.5 に変更 (154 円 → 56 円 )

これらの改善によりコストを最適化しつつ、複数の変更を連続して実行するシナリオや、指示が曖昧な場合にエージェントから人間に質問するシナリオなど、より複雑なタスクも成功させることができました。

まとめと今後 Conclusion and Next step

WHI と GenAIIC が協力して開発を進めたことで、AI Agent の実行基盤を Amazon Bedrock AgentCore Runtime に移すことに成功し、Amazon Bedrock AgentCore Observability を活用して稼働状況を確認できるようになりました。
Amazon Bedrock AgentCore を利用することによって、マネージドサービスでログの確認も容易にできるようになり非常に開発が楽になった、また、ブラウザエージェントは Strands Agents にしたことで、柔軟に動作するエージェントが少ない実装で実現できたと WHI メンバーは語っています。現実には数多くの定型作業が存在するため、それらを支援する AI Agent を構築することは難しさを伴いますが、GenAIIC との協業により、ビジネスロジックの開発に集中できる状態に到達しています。
Amazon Bedrock AgentCore は実行基盤にあたる Runtime だけではなく、他の機能も備えているため、WHI では今後の活用を検討しています。また、AI Agent はモデルの変更によって挙動もコストも変わります。今回のプロジェクトを通じて、処理が実行可能であることまで確認ができたため、 今後も継続してモデルの検証を行いコスト最適化を実施する予定です。