目次
はじめに
こんにちは。BeeXの黒澤です。
このブログは先日の以下のブログの続きとなりますので、
以下に目を通した上で、こちらのブログも読んでいただければと思います。
https://www.beex-inc.com/blog/ai-agent-basics
先のブログでは、AIエージェントの基礎となる要素についてまとめておりました。
本ブログでは良いAIエージェントを作るための要素についてまとめたいと思います。
エージェントができることを増やすには？
AIエージェントが複雑で高度なことをこなすためには、1. エージェントが扱える情報を適切に提供する、2. 多様なToolsを準備する、の2点が必要な要素になります。
エージェントが扱える情報を適切に提供する
いわゆる、"コンテキストエンジニアリング"のことです。
コンテキストエンジニアリングの定義について、Box社記事(https://japan.box.com/blog/why-context-engineering-far-more-just-prompt-engineering-20)の定義を参照します。
"タスクを達成するために必要なものを全てLLMに提供するために、適切な情報ちツールを適切な形式で、適切なタイミングで提供する動的システムを設計および構築する分野"
つまり、ユーザからの依頼内容に対してRAGやメモリ(過去の履歴)、Web検索、ツールで取得できる情報などから適切な情報を過不足なく与えるための技術となります。
エージェントが適切に動作するためには、与えるプロンプトを考え、アクセスできる情報を整理する必要があります。
例えば、「僕の今年度の有給の残り日数を教えて」というタスクを考えると、エージェントが回答するための情報は以下のようなものが考えられます。
- メモリ: 消化済み有給日数を過去のやりとりから計算
- RAG: 所属会社の有給規定に関するドキュメントの情報
- ツール: 会社の人事システムへアクセス
エージェントは与えられた情報から思考し、行動するため、正しくない情報や知らない情報があると途端に正しくない行動が生まれます。エージェントはエスパーのようになんでも知っているわけではないため、もし想定外の動作をしている場合は情報の不足や誤りがないかを確認すると良いと思います。
多様なToolsを準備する
エージェントが外部世界とのやりとりをするための技術がToolsになります。(MCPもToolsの一種になります。)
Toolsはエージェントが情報を取得する、何かを作る、情報を送信するなどエージェントが必要な全ての操作を作る必要があります。
具体的にはファイルに書き込む、データベースにデータを書き込む、外部のAPIを呼び出すなどが挙げられます。
理屈的にはありとあらゆるToolsを用意することで、エージェントは自律的に外部情報を取得し、外部システムと連携し、ユーザの求める形式での結果出力を行うことが可能です。(現実的にはLLMモデルのコンテキスト長制限がエージェント動作の限界になると思われます。)
例えば、「ECサイトのデータベースから過去1年でゲームジャンルの製品を買ったユーザにキャンペーンメールを送付して」というタスクで考えると、
- ECサイトのデータベースの情報: 特定ユーザを抽出できるSQLの生成
- ECサイトのデータベースへクエリを実行: 作ったSQLを実行して情報を取得
- メール文面の作成: 過去のキャンペーンメールの情報を取得し参考にしたフォーマットされたメール文面の作成
- メールヘッダー用画像の生成: 今回のキャンペーンイメージに沿ったメールヘッダー用画像の生
- メール送信: 対象ユーザに作成したコンテンツのメールを送信
というツールの利用をすることで一連の操作をエージェントが行うことができるようになります。
データ分析のコンテキストエンジニアリング
システム全体としてエージェントを"育てて"いくための全体イメージをデータ分析エージェントシステムを例に考えていきます。
大きく2つの主体: システムのユーザとシステム開発・運用者の２つの立場があり、それぞれの役割と動きをまとめます。
システムのユーザ
ユーザはエージェントが求める結果を返すことを期待しています。
求める結果を得るためにはプロンプト(ここでは依頼内容を中心とした情報)を作成→実際にエージェントに依頼→エージェントからの結果を確認→プロンプトを調整し再度依頼...というサイクルを回しながら欲しい結果を得られるように動きます。
ユーザ自身にはエージェントを期待通りに動かすためのプロンプト作成技術や出力された結果を検証するための知識を座学や経験から学んでもらう必要があるため、それを超えるメリットが見込まれる業務(独力で対応が難しい、時間がかかるなど)をエージェントとして提供することが必要になります。
データ分析エージェントは、データ構造やSQLを知らない一般社員からすると独力で対応が難しい、もしくはExcelによる手動集計を多く含み時間がかかるなどといった特性があるため、テーマ選定として良い一例だと思います。
システム開発・管理者
システム開発・運用者(以降システム担当)は構築したエージェントシステムを運用し、よりユーザの業務に適したエージェントに改善していくことを期待しています。
そのためにユーザが依頼したい内容をエージェントが対応するために不足しているコンテキストの編集(ここではRAG内のデータメンテナンスやシステムプロンプトの調整などを想定)や外部アクセス用ツールの追加、メンテナンスを行います。
エージェントは前述の通り、適切なコンテキストとToolsを軸に行動を起こすシステムのため、そのメンテナンスはエージェントを生かすための基礎であり、生命線であると考えます。これらのメンテナンスが適切に行われているかの検証として、オブザーバビリティの導入(https://www.datadoghq.com/blog/monitor-ai-agents)やエージェントの入出力結果の分析、ユーザからの直接のフィードバック受け入れといった、従来のシステムエラーやレイテンシー増加などの明らかなシステム障害とは異なる指標での対応が求められています。
AIエージェントを含んだシステムは増えてきていますが、従来の基幹システムのような決定論的システムではなく、ユーザの業務に直接的に役立つことが求められることが多いと思われるので、ユーザとのコミュケーションを通じた改善を継続的に行う仕組みが求められていると思います。
まとめ
本記事では、エージェントを高度化するための方法、エージェントをシステムとして扱うための方式の検討について記載しました。
ここ1年で目まぐるしく発展したAIエージェントですが、実運用されているAIエージェントがまだ少なく、PoC段階のものも多い中で、作って終わりにならず実際にユーザに価値を提供するためのシステムメンテナンス、ユーザコミュニケーションについても考えていく必要があると思います。
個人的にも引き続き業界動向を追いつつ、AIエージェントの構築、運用の支援ができるように努めていきたいと思います。
以上、最後までお読みいただきありがとうございました。
- カテゴリー
この記事をシェアする
