Amazon Bedrock AgentCore で ESG 対応の意思決定を支援 – 人の判断を記憶する AI エージェント

本ブログは、株式会社エナリス 星野 友宏 氏、KDDI アジャイル開発センター株式会社 御田 稔 氏、同 山本 直弥 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。

脱炭素に関する規制や情報開示のルールは変化が速く、企業が追うべき情報は増え続けています。今回は、株式会社エナリス（以下、エナリス）と KDDI アジャイル開発センター株式会社（以下、KAG）が Amazon Bedrock AgentCore と Strands Agents で構築した「ESG 戦略意思決定プラットフォーム」（以下、ESG ダッシュボード）をご紹介します。ESG 関連のニュースや規制動向を AI エージェントが日次で収集し、エナリスの事業視点で読み解いた記事と、取るべき対応アクションを提示する仕組みで、2026 年 7 月から社内で利用されています。本記事では、担当者の判断を AI の記憶として蓄積し、次回以降の記事に反映する仕組みを中心に、品質とコストを両立させるための設計を紹介します。

背景と課題

エナリスは、需給管理・電力卸・電力小売で培ったノウハウをもとに、PPA や VPP などの脱炭素ソリューションを展開する企業です。その事業は電力に関する制度や脱炭素関連の規制と密接に結びついており、制度の変化は自社サービスの設計や顧客への提案に直結します。一方で、ESG 関連のニュースや規制動向の調査は担当者の手作業に頼っており、情報の網羅性や解釈の深さが個人に左右されていました。

また、ニュースを要約するだけでは、「エナリスとして何をすべきか」を考える工程は人に残ります。そこで、自社への影響と対応アクションまでを AI が提示すること、そして担当者の判断を次回以降の提案に反映できる仕組みにすることを目指しました。

ESG ダッシュボードの概要

ESG ダッシュボードは、次の 3 つの画面で構成されています。

• 記事一覧：日次で自動生成された記事と、URL やキーワードを指定してその場で生成した記事を表示します。各記事には、エナリスの視点で再構築した本文、リスク／機会、対応アドバイス、AI による信頼性評価が表示され、担当者はコメントを登録できます
• 週次サマリ：優先度の高い記事を週単位でまとめます。担当者は、提示された対応アクションにエナリスとして取り組むかを、記事ごとに「承認」「保留」「却下」で登録します
• 意思決定履歴：過去の判断と、却下した場合の理由を振り返れます

ESG ダッシュボードの記事一覧画面

ESG ダッシュボードの週次サマリ画面

アーキテクチャ

システム全体構成図

ESG ダッシュボードは、次の 4 つの経路で構成しています。

• リアルタイム記事生成：AWS Amplify 上のフロントエンドから、Amazon Cognito の ID トークンを使って AgentCore Runtime を直接呼び出します。Runtime は JWT による呼び出し元の認可に対応しているため、Amazon API Gateway を挟まずに呼び出せます。生成結果はストリーミングで逐次表示します
• 画面表示・データ登録：記事一覧の取得や、意思決定・コメントの登録は、API Gateway と AWS Lambda による REST API で処理します
• 日次の記事生成：Amazon EventBridge が毎日起動する Lambda が、Amazon S3 の収集対象 URL リストを読み込み、URL ごとに Runtime を起動します
• 週次サマリの生成：Lambda が Amazon DynamoDB の記事をもとに Amazon Bedrock のモデルを直接呼び出し、サマリを生成します。決まった形式で集約するだけの処理なので、ここではエージェントを使っていません

Runtime は起動元に合わせてリアルタイム用と日次用の 2 つがあり、どちらも生成した記事を DynamoDB に直接書き込みます。担当者の意思決定とコメントは、Lambda が DynamoDB と AgentCore Memory の両方に書き込みます。DynamoDB は画面に表示するための記録、AgentCore Memory はエージェントが参照するための記憶、と役割を分けています。

AgentCore Runtime 内部のエージェント構成

Runtime の中は Strands Agents の Agents as Tools パターンで構成しており、オーケストレーターがサブエージェントをツールとして持ち、①→②→③→④ の順に呼び出します。

• ① 情報源判定（Claude Haiku 4.5）：収集対象のサイトを選定します。①の中で呼び出す robots.txt 確認のエージェント（Claude Sonnet 4.6）が、AI エージェント向けの外部 Web 検索 API で利用規約と robots.txt を確認し、取得してよいかを判定します。この検索結果は判定専用とし、生成や評価には使いません
• ② 記事取得・意味分解（Claude Haiku 4.5）：ニュース記事（リアルタイムでは最新 2 件、日次では対象日付の記事）を取得し、関連情報を 2 つの経路で集めます。エナリスが自社サイトで公開している「エナリスジャーナル」の関連記事は AgentCore Browser 上の独自ツールで都度取得し、制度動向に関する社内の解釈をまとめた資料は Amazon Bedrock Knowledge Bases からセマンティック検索で引き出します。取得は②で完了させ、③④はその結果を引き継ぎます
• ③ 記事再構築・リスク／機会判定（Claude Sonnet 4.6）：②の情報と、AgentCore Memory から取り出した過去の判断をもとにニュースを再構築し、リスクと機会、実務・経営への示唆を整理します
• ④ 対応アドバイス・信頼性評価（Claude Haiku 4.5）：③の記事を前提に対応策を提言し、その内容を自動評価します。完了後、オーケストレーターが結果を DynamoDB に保存します

技術的ポイント 1：担当者の判断を記憶し、次の記事に反映する

担当者が画面で登録した意思決定とコメントは、Lambda が CreateEvent で AgentCore Memory に書き込みます。書き込んだ内容からは組み込みの戦略で長期記憶が抽出され、次回以降の記事生成で参照されます。使っている戦略は次の 2 つです。

• User preference 戦略：過去のコメントやレビューの観点
• Semantic 戦略：進行中、または予定している対応策

意思決定は承認・却下のときだけ、コメントは常に登録します。保留を登録しないのは意図的な設計で、迷いのある判断を混ぜず、確定した判断だけを記憶に残すためです。

AgentCore Memory は、ユーザーとエージェントの会話から好みや重要な事実を抽出し、以降の会話に活かす使い方が代表的ですが、ESG ダッシュボードでは会話ではなく、業務画面で登録された担当者の判断を API で直接書き込んで記憶の元にしています。チャットのような対話の形をとらない業務システムでも、利用者の判断を記憶として蓄積し、エージェントの出力に反映できる一例です。

記憶の取り出しには、RetrieveMemoryRecords を呼ぶ独自のツールを戦略ごとに用意し、それぞれ関連度の高い上位 5 件を取得します。取得した記憶は③記事再構築で参照し、どの観点でニュースを読み解くか、エナリスの取り組みに照らして何をリスクや機会と捉えるかの判断材料にします。④の対応アドバイスは③の記事を前提に作られるため、記憶の内容はアドバイスにも間接的に効きます。モデルを再学習させるのではなく、蓄積した判断を生成のたびに参照する仕組みです。

組織としての知見は、ナレッジベースに持たせています。格納しているのは、電力・燃料関連の制度動向について社内で共有・議論し、その解釈をまとめた資料です。規制の条文などの一次情報はその都度 Web から取得し、ナレッジベースには「その規制変更をエナリスとしてどう捉えるか」を持たせる、という役割分担にしています。

技術的ポイント 2：自動評価と人の確認を組み合わせて品質を担保する

エージェントを分割する：開発の初期には、複数のニュースをまとめて処理すると、本来は別々のニュースの内容が混ざり、1 本の記事にまとまってしまう問題がありました。プロンプトの改善では解消できず、役割ごとのサブエージェントに分けることで解決しています。Agents as Tools では各サブエージェントが独立したコンテキストで処理を行うため、情報の混線を防げたと考えられます。

自動評価と、その限界：エナリスと KAG は前回の記事でも、人と AI が相互にフィードバックし合って精度を高め合う HCAI（Human-Centered AI）の仕組みを取り入れてきました。ESG ダッシュボードでもこの考え方を引き継ぎ、④が Strands Agents の評価用 SDK である Strands Evals を使って、生成した対応アドバイスをその場で採点します。③の再構築記事、取得した関連情報、ナレッジベースの内容を根拠として渡し、アドバイスが根拠に忠実かといった 9 つの指標で評価して、平均値を A／B／C の 3 段階で画面に表示します。

ただし、この評価の対象は④のアドバイスで、③の記事は根拠の側にあります。③で誤りが混入していても、④がそれに忠実であれば評価は高くなります。多段のパイプラインで最終出力だけを評価しても、途中で生じた誤りは検出できません。そこで③の記事は担当者が画面で確認し、その判断が技術的ポイント 1 の記憶を通じて次回の③に戻る設計にしています。自動評価が④を守り、自動評価の届かない③を人が確認して、その判断を③に返す。守る場所と、判断を活かす場所がそろっていることが、この仕組みの要点です。

評価には当初、オープンソースの評価フレームワークである RAGAS を使っていましたが、別系統で動く外部ライブラリとの連携にオーバーヘッドがありました。Strands Evals への移行で 1 件あたりの評価時間は約 8 分から約 4 分へと約 40% 短縮し、判定結果は移行の前後で一致しています。

技術的ポイント 3：品質を保ったままコストを下げる

構築当初はすべての処理を Claude Sonnet 4.6 で動かしており、LLM の利用コストが課題になりました。Amazon CloudWatch でトークン使用量を可視化し、入力トークンの量とモデルの単価の 2 つの軸で打ち手を重ねた結果、1 回の実行あたりの入力トークンは数千万トークン規模から数十万トークン規模へと 98% 以上減り、1 日あたりの LLM コストは約 88% 下がっています。

入力を削る

• Web の取得方法を見直す：HTML をタグごと渡していた処理を改め、①ではページの内容をテキストで返す外部 Web 検索 API に切り替えました（情報源判定 1 件あたり約 800 万 → 約 40 万トークン）。②では AgentCore Browser 上の独自ツールで HTML の除去と構造化を行っています（記事取得 1 件あたり約 100 万 → 約 40 万トークン）

単価を下げる

• キャッシュを使う：システムプロンプトやツール定義など毎回同じ部分をプロンプトキャッシュの対象にしました。情報源判定 3 件での測定では約 400 万トークンがキャッシュからの読み込みになり、その分は通常の入力より低い単価で処理されています
• モデルを使い分ける：サブエージェントごとに Claude Haiku 4.5 の出力を検証し、品質に影響が出ない①②④を Haiku 4.5 に移しました。③と、①の中の robots.txt 確認は Sonnet 4.6 のままです。robots.txt 確認は機械的に見えますが、解釈を誤ると取り込んではいけない情報を取り込むことになります。モデルは処理の重要度ではなく、誤りをどこまで許容できるかで選んでいます。

導入効果

2026 年 1 月から AgentCore の導入を進め、約 4 か月の開発を経て、2026 年 7 月からサステナビリティ推進の担当部署で利用が始まりました。

業務面

• 担当者が手作業で行っていた ESG 関連情報の収集と整理が日次で自動化され、自社への影響と対応アクションの案を起点に検討を始められるようになりました
• 承認・却下の判断とその理由が意思決定履歴として残り、判断の経緯を後から振り返れるようになりました

技術面

開発の過程で見直しを重ねた結果、構築当初（すべての処理を Claude Sonnet 4.6 で実行し、評価に RAGAS を使っていた時点）と比べて、次の効果が出ています。

• 入力トークン（1 回の実行あたり）：数千万トークン規模 → 数十万トークン規模（98% 以上削減）
• LLM コスト（1 日あたり）：約 88% 削減
• 評価時間（1 件あたり）：約 8 分 → 約 4 分（約 40% 短縮）

また、サーバーレス構成のため、ベースとなるインフラの固定費は月額数十ドル程度に抑えられ、OS の保守などの運用負荷もかかりません。

現在は、実際に利用する担当者のフィードバックを受けて改善を続けています。

今後の展望

週次サマリを経営層の意思決定の場でも活用していくほか、同じ構成を、規制への適合性をアドバイスする「規制／ルール分析」機能へ展開する予定です。あわせて、これまでの社内の解釈に加えて、公式の制度ルールや法改正の情報もナレッジベースに順次取り込んでいきます。まずは社内で運用しながら、データの取得方法や、外部に公開できるデータの範囲を整備し、将来的には規制分析の知見を活かした外部向けサービスとしての展開を目指しています。

まとめ

エナリスと KAG は、Amazon Bedrock AgentCore と Strands Agents を使い、担当者の判断を AgentCore Memory に蓄積して次回以降の記事に反映する ESG ダッシュボードを構築しました。自動評価の届かない工程を人が確認し、その判断を記憶として同じ段に返す設計は、HCAI を実運用に落とし込む一つの形です。AI エージェントの本番運用に取り組む方の参考になれば幸いです。

著者

星野 友宏 株式会社エナリス 事業企画本部 みらい研究所 技術開発部門

御田 稔 KDDI アジャイル開発センター株式会社 テックエバンジェリスト

山本 直弥 KDDI アジャイル開発センター株式会社 ビジネスイノベーション開発本部 ビジネスイノベーション開発4部 ソフトウェアエンジニア

安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト