NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

注目のタグ

    AIエージェントの構築・運用・フロントエンド設計の実践知見 ~AI Builders Day 聴講レポート~

    はじめに

    こんにちは、アプリケーションエンジニア2年目の松澤です。

    突然ですが皆さんはAIエージェントの構築経験はありますでしょうか?私は個人でStrands Agentsなどを軽く触ったことがある程度の経験しかありません。ですので、Strands Agentsをはじめ、AIエージェントに関する技術に実際に触れたり、業務でAIエージェントを運用しているといった方から、新たな知見を得たいと考えていました。

    そんな中、JAWS-UG Presents - AI Builders Dayというイベントに参加してきました。

    AI Builders Dayとは

    jawsug.connpass.com

    AI Builders Dayとは、AWS User Group - Japan(JAWS-UG)が主催の学習イベントで、特に「AIエージェント」に特化したセッションが多く取り上げられています。約800名の方が参加され、その中でも、AIエージェントを構築・運用している方が半分程度いらっしゃいました。

    今回私は一日かけて様々なセッションを聴講しました。どのセッションも新たな知見を得ることができて非常に有意義な一日でした。その中でも、私が新たな知見を得た3つのセッションを厳選して聴講レポートを執筆します。


    全てAWSで完結!AWS AmplifyとViteで始めるスモールスタートなAIエージェント開発のススメ

    speakerdeck.com

    登壇者(敬称略):たけのこ

    こちらのセッションでは、AIエージェントでアプリケーションを作るとき、フロントエンドをどのように構築するかについて提案をされていました。私自身、AWS Amplify(以下Amplify) × Strands AgentsでAIエージェントを利用したチャットアプリケーションの作成に挑戦しようと考えていたので、非常に聞き応えのあるセッションとなっていました。

    Streamlitを利用する

    アプリケーションの公開先が社内に限定されていたり、とにかく早さを求めている場合はStreamlitを利用する方法があります。

    ただし、StreamlitはPoCから本番運用まで見据える場合、UIの自由度が求められる場合、既存システムのUIコンポーネントが再利用できる場合などには向きません。あくまで手軽に、小規模に開発をするといったケースに利用されます。

    Amplify を利用する

    StreamlitよりもリッチなUIを手軽に作成したい場合は、Amplifyを利用する方法があります。AmplifyはWebアプリケーション等を簡単に構築できるプラットフォームサービスとなっており、CDKでリソースを構築することができます。Amplify Hostingを利用して、GitHub等のリポジトリサービスと連携してAWS上にデプロイすることができたり、手軽にアプリ開発をする場合は何かと便利なサービスです。

    セッション内ではAmplifyを利用した構成を2つ提案されました。

    1つ目はAmplifyのフロントエンドでReact+Vite、バックエンドにCognitoを置きます。そして、Amazon Bedrock AgentCore Runtime(以下 AgentCore Runtime)上のエージェントにPOSTリクエストを行うという構成です。Streamlitの構築パターンのフロントエンドをAmplifyに置き換えた構成です。Reactを利用できるので、UIをリッチなものにすることができます。エンジニアの技術スタックに応じて、フレームワークをReactから変更することも提案されていました。

    2つ目は、下記に示すアーキテクチャのようにAmazon API Gatewayをリクエストの経路に挟む方法です。このアーキテクチャのメリットは、API GatewayにAWS WAFを適用することで、セキュリティが向上する点です。また、AgentCore RuntimeをCDKでAmplifyのバックエンドに記載することで、同一リポジトリで管理することができます。

    Copilot Kitを利用する

    Amplifyを利用する方法には、APIのリクエスト、レスポンスの処理や画面表示をスクラッチで実装する必要があります。AI SDKやLangGraphといったフレームワークはUI向けの仕組みが用意されていますが、Strands AgentsにはUI用のコンポーネントは存在しませんでした。

    ところがre:Inventの最中に、Strands AgentsがAG-UI(エージェント・ユーザーインタラクションプロトコル)に対応するようになりました。簡単に説明すると、AG-UIはエージェント対ユーザー間のプロトコルとなります。

    AG-UIが利用可能になったことで、AG-UIに対応するCopilotKitというプラットフォームが利用できるようになりました。CopilotKitを利用したアーキテクチャは以下のようになります。

    CopilotKitのコードをAmplifyのフロントエンドとバックエンド(AWS Lambda)に実装する必要がありますが、これによりシームレスにStrands Agentsとフロントエンドを接続することができます。

    本番運用やその他機能追加となると、Amplifyの拡張性の低さから、Amplifyから移行する必要がありますが、小~中規模の場合は有用な構成となりそうです。

    セッション小まとめ

    このセッションでは、小規模・中規模のAIエージェントアプリケーションのフロントエンドを構築する方法について触れられていました。特にCopilotKitは、AmplifyとStrands Agentsのつなぎ目として有用であることが分かったので、是非今後利用してみたいと感じました。


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

    speakerdeck.com

    登壇者(敬称略):井上大貴(株式会社Works Human Intelligence)

    こちらのセッションでは、LangGraphを用いて通勤手当申請システムのAIエージェントを開発された経験から、得られた知見などを共有されていました。

    通勤手当申請の承認は、地図アプリを利用して、申請者の最寄り駅を確認し、最安値を調査するなど、かなり承認者にとって負荷のかかる作業です。ワークフロー型のエージェントを構築することで負荷を軽減しようと取り組まれていました。

    LangGraphを用いたアーキテクチャ

    複雑な条件分岐を制御するために、LangGraph というグラフ構造を用いてマルチエージェントを定義できるライブラリが利用されていました。このライブラリを用いて、ワークフロー全体のオーケストレーションを行います。このグラフの中で判定タスクがポイントとなっており、判定に必要な情報がそろうまでツールを繰り返し実行します。この繰り返し実行をReActループと呼びます。

    ユーザーがSlackアプリでメンションを行い、エージェントを呼び出し、申請データをアップロードします。その後処理が開始され、申請の承認結果がダウンロードできるといったワークフローとなっています。

    アーキテクチャとしては、SlackアプリをECSに、LangGraphをAgentCore Runtimeにデプロイするというシンプルな構成になっています。

    運用する中で得た教訓

    モデルを更新しても、必ず精度が改善するわけではない

    LLMにはClaude Sonnetを利用しており、新しいバージョンがリリースされるたびにエージェントのLLMをアップデート(例:Claude Sonnet 4.0からClaude Sonnet 4.5)していました。しかし、これまで期待通りに判定できていた箇所も期待通りに判定できないことが発生したとのことです。そのため、その際にプロンプトを修正するなどして対応されていました。

    また、井上さんはDeepEvalというOSSを用いてLLMの評価を行っていることを述べていました。複数のセッションで同様のことが述べられていたのですが、AIエージェントをリリースしてからも、評価・改善は必要です。したがって、LLMOpsを見据えて評価手法を開発の初期から設計することが重要であるということでした。

    コスト削減の手法は様々

    常に高コストなモデルを使用するのではなく、単純なタスクであれば低コストのモデルを使用するなど、ノードごとにモデルを分けるという方法も提案されていました。

    また、MCPを利用する方針でしたが、大量にトークンを消費してしまうことが判明し、コスト削減のためにMCPを利用せず、独自にツールを定義されていました。

    セッション小まとめ

    私はワークフロー型のAIエージェントを構築する例として、AWS StepFunctionsやAWS Lambda durable functionsの例を見たことがありますが、LangGraphを利用した例は初めて見ました。AWSのアーキテクチャ上はシンプルな構成となるのが印象的でした。コードでワークフローを記述したい方にとっては、AWS Lambda durable functionsと並ぶ使い勝手の良さを感じるのではないでしょうか。また、LLMは最新のものが必ずしも良いわけではなく、出力やコストなどの多角的な面から評価する必要があることを学びました。


    AgentCore BrowserとClaude Codeスキルを活用した『初手AI』を実現する業務自動化AIエージェント基盤

    speakerdeck.com

    登壇者(敬称略):遠藤 大介(株式会社ジェネラティブエージェンツ)

    Amazon Bedrock AgentCore Browser(以下 AgentCore Browser)という機能が注目されてはいましたが、どのような機能か知らなかったため聴講してみることにしました。こちらのセッションは、通常よりも長い45分間のセッションとなり、AIエージェントの利用に関する思想やAgentCore Browserについて詳細に説明いただきました。

    初手AIという考え方

    このセッションの肝となってくる考え方は、「初手AI」という考え方です。これはどういうことかというと、従来のAIエージェントは、人間がAIエージェントに指示を行います。この時、人間のアクションがボトルネックとなってしまいます。

    しかし初手AIはAIエージェントが人間にタスクを依頼するという考え方をします。こうなると、イベント駆動で自動的にAIエージェントがタスクをこなして、何か人間に承認などのアクションを求める時だけ、人間がタスクを行います。人間のアクションが不要な場合はAIエージェントが自律的にタスクを遂行してくれるため、人間のボトルネックが少なくなります。AIが有能な秘書のように事前準備をすべて完了させるため、人間は最終判断に集中することができます。

    タスクゼロ

    タスクゼロとは、初手AIを実現するために遠藤さんのチームが開発したシステムです。Claude Codeを汎用AIエージェントとして利用し、自然言語の業務マニュアルを専用スキルとして動かします。管理用WebやAIエージェントはすべてサーバーレス構成です。

    Claude Codeといえば、コーディング用のAIエージェントかと思う方も多いと思いますが、コーディング以外の様々なタスクもこなしてくれるとのことで、改めて非常に有用なモデルだと感じました。

    タスクゼロの例として、社労士の方に賞与支払届の作成と提出を依頼するケースを紹介されていました。イベント駆動で「総務ちゃん」というアプリケーションが起動し、その後に社労士さんに依頼するといった流れで利用できます。

    MCPではなくスキルを利用する

    エージェントとツールのプロトコルとしてMCPを利用する方も多いかと思いますが、MCPを利用すると、トークン消費量が格段に増えます。

    トークンが多いと、推論の性能が格段に落ちます。昨今のLLMはコンテキストが大量に保持できるように進化してきましたが、保持できたとしても、性能が落ちるということが示唆されていました。

    したがって、ツールをまとめたスキルとして利用させることで、トークン消費量を抑えるという方法をとりました。スキルとは、ツール群をまとめる抽象化レイヤーのことです。業務に合わせて、Markdownを利用し、業務遂行に必要なさまざまなスキルを作っていました。

    AgentCore Browser

    そして、今回注目するポイントは、AIエージェントにタスクを行ってもらうときの方法の一つとして、AgentCore Browserを利用する方法です。

    AgentCore Browserは、Amazon Bedrock AgentCoreの機能のうちの一つで、AIエージェントが、セキュアなサンドボックス環境でブラウザを立ち上げて、ブラウザを操作してくれるという機能です

    AIエージェントが外部ツールを実行する際、API経由で実行することが多いかと思いますが、GUIでしか操作できないようなツールも中にはあると思います。そのようなとき、AgentCore Browserが利用できます。

    さらに、AgentCore Browserには便利な機能があります。

    • リプレイ機能による問題発生時の分析
    • Live View機能によるブラウザ操作のリアルタイムプレビュー
    • 人間が操作する状況でのテイクオーバー(ログインなどは人間が操作をしなければならないので、そういった状況でテイクオーバーができます)

    料金に関しても、IO待機中はCPUに課金されないなど、コストパフォーマンスに優れていることを指摘されていました。ブラウザの操作はIOで待機することが多かったりするので、この点は非常に有用だと感じました。

    そのほか、ローカル環境でAgentCore Browserを利用するように専用のCLI・APIを作成し、ブラウザのセッションを扱えるようになったりなど、実際の開発におけるポイントも紹介されていました。

    セッション小まとめ

    AgentCore Browserやスキルを活用し、エージェントが動きやすい環境を整えることで「初手AI」を実現し、本当に必要な時だけ人間が操作するという環境を整えていました。AgentCore Browserによって、CLIではなくGUIもAIエージェントが利用できるようになり、ボトルネックとなる人間のタスクもかなり少なくなったことが印象的でした。私もAgentCore Browserで会計申請などを楽にできたら嬉しいと感じました。


    まとめ

    本当はこれ以外にも執筆したい内容が山ほどあります。しかし、かなりブログが長くなってしまうので今回はこちらの3つのセッションをピックアップしました。かなり多くの方々がAIエージェントを構築されている現状や熱量を受け、私もAIエージェントを構築したくなりました。

    皆さんも、2026年はAIエージェントをぜひ「構築」してみてはいかがでしょうか?