【セッションレポート】AI を使う？AI に使っていただこう。AI が考えた次の行動と実アクションの実践的 Agent アプローチ（AWS-55） #AWSSummit

はじめに

こんにちは、コンサルティング部の神野です。

AWS Summit Japan 2025の2日目、「AI を使う？AI に使っていただこう。AI が考えた次の行動と実アクションの実践的 Agent アプローチ」(AWS-55)というセッションに参加してきました。

AI に使っていただこうというAIに敬意を払ったタイトルでどんな内容なのか気になったので聴講してみました。
なんといってもAI様々のご時世ですからね・・・！

セッション概要

タイトル: AI を使う？AI に使っていただこう。AI が考えた次の行動と実アクションの実践的 Agent アプローチ

概要: 2025 年は皆さん口を揃えて 「Agent の年」と言っていました。この新しいテクノロジーの波は、すでにアーリーアダプターたちによって実装され、ビジネス環境に変革をもたらし始めています。年の折り返し点を迎えた今、Agent の誕生背景から現在の発展状況、そして今後の可能性について改めて考察しましょう。本セッションでは、Agent が登場した背景とその進化の過程を紐解きながら、現在どこまで業務自動化が進展しているのかを探ります。基本的な Tool Use の概念から、複雑なタスクを自律的に遂行できる高度な Agent の技術まで、LLM （大規模言語モデル）を活用した最新の自動化手法を包括的に解説します。さらに、理論だけでなく実践にも焦点を当て、Amazon Bedrock Agents を活用した Agent の実装デモンストレーションや成功事例を紹介します。セッションの最後には、参加者の皆様がすぐに取り組めるソリューションをご紹介し、Agent 導入への第一歩を踏み出すためのヒントをお伝えします。

スピーカー: 呉 和仁（アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 自動車・製造グループ シニアソリューションアーキテクト）

セッションレベル: Level 300（中級者向け）

セッション内容

LLMの限界とTool Useの必要性

セッションは、LLMの限界を示す身近な例から始まりました。「今日の幕張の天気を教えて」という質問に対して、LLMは「申し訳ありませんが、私はリアルタイムの天気情報にアクセスすることができません」と答えてしまいます。しかし「2014年2月7日に何があった？」と聞くと、「日本では記録的な大雪が関東地方を中心に降り、交通機関に大きな影響を与えました」と正確に答えます。

この結果から、LLMは物知りで過去のことはよく知っているし、調べ方も知っている。でも最新情報に答える術がないとわかります。

そこで登場するのがToolという概念です。LLMに使用できるToolを提供すれば、LLMはToolを適切に選択して実行指示を出せるようになります。

上記結果を見るにToolを介して天気の回答が可能になりましたね！

ただ、この仕組みについて、2022年5月に発表されたMRKL（Modular Reasoning, Knowledge and Language）論文が紹介されました。AI21 Labsが発表したこの論文では、LLMの欠点として以下の2つが指摘されています。

1. 最新情報にアクセスできない
2. 計算などのある種の推論が苦手である

当時のモデルは2桁までは100%で計算できましたが、3桁からどんどん精度が落ちていきました。
MRKLでは、LLMをTool選択および引数抽出装置として使うことで、これらの課題を解決しようとしています。

Toolの実装における課題と解決策

ToolをLLMに提供すれば最新情報取得や計算タスクが解決できることがわかりました。しかし、単純にToolをシステムプロンプトとして与えるだけでは3つの問題が発生します。

3つの問題

1. ハルシネーション
外部システムにツールを使わせる予定なのに、LLMが自分でさもツールを使ったかのように虚偽の結果を返してしまいます。

2. ツール情報の漏洩
一般的にはユーザーから質問を受けたら最終回答だけを返して欲しいです。例えば、「今日の天気は？」と聞かれたら、内部でGETウェザーツールを使って「32℃快晴です」と返したいのに、「ここでget_weather ツールを使います」のように内部プロセスを回答するのは困ります。

3. 不定の応答フォーマット
ユーザーが問い合わせを投げると「はい、かしこまりました。天気を調べてみましょう」みたいな前置きから始まって「これでうまくいくはずです」みたいな終わり方をすることが多いです。システム的には「get_weather("幕張")」だけ欲しいのに、前後に不要な文言があるとパースがとても大変です。

解決策：Amazon BedrockのTool Use

モデルプロバイダ各社が提供するFunction CallingやTool Use機能を使うことで、これらの問題を高い確率で回避できます。Amazon BedrockでもToolを提供しています。

専用構文の導入と出力の構造化
Tools専用の構文を使ってLLMにToolの情報を渡すことで、ツール情報の漏洩やハルシネーションを回避できるようになります。

また、LLMの出力でツールが選択された場合、ツール名と引数をJSON形式で抽出できることでパースが容易になります。

2種類の出力
LLMのレスポンスは2種類に分離されます。

1. テキスト出力（緑色）: AIの思考過程。
2. ツール実行指示（オレンジ色）: 構造化されたツール名と引数のJSON

注意点として、テキスト部分にもツール情報が書かれていますが、これは通常のユーザーには見せる必要がありません。Tool Useがある間はツールを実行する必要があるため、最終結果にツールが含まれなければ問題ありません。

ループ処理の実装
ツールの実行結果をユーザーメッセージとして分離して渡すことで、実行結果を解釈しやすくなって精度も向上します。

Tool Use全体フロー

Tool Useの全体的な流れは以下の通りです。

ここまでの内容をまとめると

• LLMの限界補完: LLMは万能ではなく、ツールを使うことで最新情報取得や計算といった苦手なタスクを改善できる
• ツール選択と引数抽出: Tool Useはツールの選択と引数抽出だけを行うことで様々なことができるようになり、アプリケーションに組み込みやすくなる
• ループ処理による解決: Tool Useをループで繰り返していくことで、複雑な質問に対しても回答を得られるようにする

次にエージェントへの進化へと触れていきます。

エージェントへの進化

本セッションのタイトル「AIを使う？いやいや、AIに使っていただこう」が示すように、エージェント開発の本質はAIにツールを使っていただくための準備にあります。開発者は、ツールの準備と、AIにそれらを使ってもらうための説明を試行錯誤する必要があります。

人間の介入度合いの設計

エージェント実装では、人間の介入度合いと外部世界への影響度を考慮した設計が重要です。

• 課金・決済系: 人間の確認が必須
• Read Only: レポート生成などは全自動化可能
• 高コスト処理: 動画生成やHPCジョブは人間チェック

先ほどのTool Useのフローに人間が加入するとどうなるのでしょうか？

人間の介入が必要な場合、ツール実行の部分で人間がその結果を代替すればOKです。最も泥臭いやり方として、ツールの実行結果をLLMに返すところを人間が担当することで実現できます。

LLMの急激な進化

LLMの進化速度は著しく、SWE-bench++ベンチマークでは、Claude 3 Opusの21%からClaude 3.5 Sonnetの46.4%まで、わずか3ヶ月で大幅に向上しました。エージェントができる範囲も急速に拡大しています。

今やClaude 4が出ているので、その進化スピードは驚異的ですよね。どんどん賢くなってきている印象です。

Amazon Bedrock Agentsの活用

エージェントを本番環境で動かすには、プロンプト管理、アクセス制御、セキュリティなど様々な要素が必要です。Amazon Bedrock Agentsは、これらをマネージドサービスとして提供します。

主要機能

• 基盤モデル: Amazon NovaやClaude等を選択可能
• メモリ・ガードレール: 会話管理とセキュリティ機能
• アクショングループ: ツール管理とCode Interpreter
• トレース機能: CloudWatch/S3と連携したログ保全

実装デモ：ログ可視化エージェント

Bedrock使用ログを可視化するエージェントのデモが紹介されました。

このエージェントは2つのツールを使用しています。

1. SQLクエリツール: AthenaでログデータをCSV形式で取得
2. Code Interpreter: 取得データをPythonでグラフ化

実際に「上位2つのアイデンティティのトークン使用量を月次で折れ線グラフ化」という複雑な要求に対して、エージェントが計画を立て、SQLを生成し、可視化まで自動実行しました。

エラーハンドリングのポイント

ツールで発生したエラーは必ずエージェントに返すのが大事です。デモでは「SubQuery is not supported」エラーが発生しましたが、これをエージェントに返すことで、サブクエリを使わない代替SQLで自動修復も可能となる可能性があるためです。

エラーハンドリング箇所は自分で実装する際の参考になってよかったです！

おわりに

本セッションのタイトル「AIを使う？いやいや、AIに使っていただこう」が示すように、エージェント開発の本質は「AIにツールを使っていただくための準備」が大事だなと感じました。

重要なポイント

• ツールがLLMの限界を解決: 最新情報取得や計算をツールで補完
• 人間の介入度合いの設計: 責任やコストに応じた適切な自動化レベル
• Amazon Bedrock Agentsの活用: マネージドサービスで開発負荷を軽減

LLMの進化は急速で、エージェントができることの範囲も今後さらに拡大していくと思われます。

ここでAmazon Bedrock Agentsを活用することで、開発者はツール開発とオーケストレーション設計に集中でき、エージェントの本番利用を推奨しています。

本セッションの内容を参考に、AIにツールを使っていただけるよう不備がなくしっかり実装したいですね。

以上、本レポートが参考になりましたら幸いです！
ご覧いただきありがとうございましたー！！