目次

1.    はじめに
2.    明日から実践できる AWS でのオブザーバビリティ革新
3.    自律的 AI エージェントアプリの未来！ 人と AI が共創する社会へのロードマップ
4.    ⽣成AI を活⽤したデータベースのスキーマ変換で移⾏を加速しよう
5.    さいごに

1. はじめに

こんにちは。DXビジネス事業部 Techチームです。
私たちのチームの仕事の一つに自社サービス開発・運用があり、本原稿を執筆するメンバーは、これに関わっています。

今回は、2025/6/25～2025/6/26に開催された「AWS Summit Japan 2025」にチーム参加してきましたので、気になったセッションやブースについてご紹介いたします。

※6/26のシアターセッションで、弊社の社員が事例を紹介しました。(ニュースリリース)

2. 明日から実践できる AWS でのオブザーバビリティ革新

私は、社内向けに生成AI活用基盤の運用を担当しているのですが、社内向けであることもあり、監視設定がやや疎かになっています。
※社内向け生成AI活用基盤については、こちらのニュースリリースを参照ください

 

現状、社員数百人が利用することでログの量が多くなること、機能開発を優先していることなどがあり、きちんとした監視設定を入れていません。
利用している社員からの申告でエラー発生に気づくこともあり、あまり良い状態ではないな・・・と思っているところでした。
そこで、今回のAWS Summitでは、オブザーバビリティを中心に拝聴していました。

参加したセッションの中で、すぐに導入を検討しようと思ったテーマについて、今回ご紹介します。

本セッションでは、監視を行うための仕組みとして、OpenTelemetryというフレームワークと、OpenTelemetryを組み込んだサービスであるAmazon CloudWatch Application Signalsの紹介を行っていました。

 

本記事では、Amazon CloudWatch Application Signals(以下、CloudWatch Application Signals)について取り上げます。

CloudWatch Application Signalsでは、アプリケーションコードの変更は不要で、AWS管理コンソールから設定を有効化するだけで利用でき、CloudWatchのダッシュボードで状況の可視化が可能です。
アプリケーションコードに手を入れずに情報を取得し、状態を把握できる点は、とても魅力的だと思います。

ただし、有効化するだけで利用できるのは、AWS LambdaとAmazon EKSだけとのことです。
担当しているシステムではAmazon ECS(AWS Fargate)を採用しており、利用にはひと手間必要となります。
Amazon ECS でアプリケーションを有効にする - Amazon CloudWatch

 

設定方法は2種類ありますが、利用しているのはAWS Fargateとなるため、サイドカー戦略を使用してデプロイする手順を採用する必要があります。

  • IAMロールの作成
  • Parameter Storeの設定
  • ECSの設定

等々、実施する作業がいくつかあります。

 

生成AI活用基盤の運用では、GitHub ActionsとCloudFormationを利用し、インフラの管理を行っており、ここに上記の内容を取り込んでいく必要があります。

すぐに試すことは難しいですが、近いうちに設定を行いたいと思います。

3. 自律的 AI エージェントアプリの未来！ 人と AI が共創する社会へのロードマップ

私は最近流行しているAIエージェントに注目し、「自律的 AI エージェントアプリの未来！ 人と AI が共創する社会へのロードマップ」をオンラインで視聴しました。

 

AIエージェントとは、ある目的に対して自律的または半自律的に思考・意思決定し、アクションを行うAI技術の一種です。生成AIが登場した当初は、特定タスクや目標に対して自律的に考え、依頼事項に応じて回答するイメージでしたが、最近ではさらに進化し、自律的に判断・行動しながら、ローカルPC上のデータ等も含めた広範囲の情報を基に、能動的にタスクを遂行できるようになりました。

 

今回視聴したセッションでは、このAIエージェントに焦点をあて AIと人が協働する社会を目指す中での具体的な技術情報が紹介されていました。

2024年度は「RAG」というワードがトレンドとなりましたが、RAGのシステムもAIエージェントも、単独で使用するには解決できる限界がありました。この課題を解決する方法として、「マルチAIエージェント」という仕組みが最初に紹介されていました。

 

 

  • 仕組み

この仕組みでは「スーパーバイザエージェント」として、最もトップレベルに存在するAI（会社に例えると社長）、その次の階層に各目的別にツールを参照できるAI（部長やリーダー）、さらに下で最後の階層として、各ナレッジの情報に特化したツール（一般社員）が配置されています。

 

セッション内では、転勤の際の交通費の清算方法を確認する事例が取り上げられていました。
動作の例として、以下のような使い方が考えられるかと思います。
1.    まず社員がスーパーバイザエージェントに問い合わせを行う
2.    スーパーバイザエージェントが、社内マニュアルを管理するAIに問い合わせを行う
3.    さらにAIが、社内システム検索ツールを呼び出し、回答を返す

 

従来の汎用的なAIでも広範な情報を元に回答できますが、このような仕組みを採用することで、自社内データおよび一般的なWeb上のデータにも一つのアプリケーションから質問・回答可能となり、非常に便利です。AIエージェントの導入により、より高精度な情報が得られる印象を持ちました。

 

 

  • ユースケース

また、開発側のみでなく、ビジネス側の視点にも重視されており、各業務のユースケース（テキストの自動分析（契約書）、ドキュメントレビュー、顧客向け報告書の自動作成、ドキュメント差分チェック）が紹介されていました。

特に興味深かった事例は「ドキュメント差分チェック」のユースケースです。通常のChatGPTのようなアプリケーションでも十分対応できそうに思えますが、この場合ハルシネーションの発生が多く、うまくいかないケースが多いようです。ここでRAGやエージェントを活用すれば、ハルシネーションが少なく高精度なチェックが期待できるとのことです。

 

具体的なユースケースとして、「規格文章の差分から、対応するマニュアルの改訂ポイントを洗い出す」ことが上げられていました。
・ドキュメント分割エージェントにより、精査するドキュメントを比較しやすい量に分解する
・対応表作成エージェントにより、ドキュメント解析し、修正前後の対応表を作成する
・対応表から差分抽出エージェントが、差分レポート作成する

 


最後に、一事業部単位でAIエージェントを組み込んだ際の世界観も構成図で紹介されておりました。
企業のあらゆる場面で「AIエージェント」の活躍が期待でき、楽しみですね♬

4. ⽣成AI を活⽤したデータベースのスキーマ変換で移⾏を加速しよう

こちらは、6月25日のセッション「⽣成AI を活⽤したデータベースのスキーマ変換で移⾏を加速しよう」のブースになります。
とうとうDB移行の世界にもAIがやってきました。AWS DMS Schema Conversion（以降 DMS SC)です。

これまで、DB移行といえばSCT(Schema Conversion Tool)で定義変換を行っていましたが、PL/SQLなどの関数変換に困っていた我々を救ってくれます。
DMS SCは、SCTと同様にルールベース変換を行ったうえで、足りない部分をAIが変換してくれるとのことです。

セッション中のデモではPL/SQLの変換率がルールベースでは８％だったのがAIを使うことで８５％になってました。これはすごい！

クラウド移行に伴うデータベース製品を変更する際には、必須アイテムですね。

5. さいごに

それぞれ、自身が関わっている業務に関連した内容を気になるセッションとしてご紹介しました。

 

今年も生成AIに関連したセッションは多かったですが、それ以外にもデータベースやオブザーバビリティの分野でもとても役に立つセッションもあり、私たちの業務に大きなインパクトをもたらしています。
今後も、日々アップデートされる最新技術を積極的に取り入れ、開発やサービス運用に活かしていきたいと思っています。

 

本記事が読者の皆さまにとって、新しい発見やヒントにつながれば幸いです。