ベストプラクティス / 重要！エージェント作成のステップ

重要！エージェント作成のステップ

最終更新日：2024年7月1日

重要！エージェント作成のステップ

GPTBotsは、AIアプリケーション（エージェント）をコーディングなしで作成できる開発プラットフォームです。さまざまなニーズに合わせてエージェントを簡単に作成できます。

GPTBotsは直感的で使いやすいサービスですが、「自分の目的に合ったエージェントをどう設計するか」が最大のポイントです。

そこで大切なのが、設計のための思考プロセスです。

この記事では、自分に合ったエージェントをじっくり考え、段階的に作り上げるためのガイドを紹介します。

思考プロセス

エージェントの設計は一般的なプロダクト設計とほぼ同じ考え方で進めます。

ただし、エージェントは「人間のような存在」として捉えるのがおすすめです。そうすることで現実世界の課題をより自然にエージェントに投影し、解決策も具体的にイメージできます。

シナリオ

まず、「このエージェントでどんな課題を解決したいか」というシナリオを考えます。

シナリオを整理するには「5W1H」を使うと便利です。

Where：いつ, When：どこで, Who：誰が, Why：なぜ, How：どうやって, What：何を

例：

お客様（誰が）が、自宅（どこ）で、オンラインショッピングをしているとき（いつ）、商品の返品方法がわからないため（なぜ）、オンラインストアのカスタマーサービスに電話（どうやって）して問い合わせる（何を）。

これは、ECカスタマーサービス用エージェントの典型的なユーザーシナリオです。

この例をもとに、エージェントが対応する具体的なシナリオをリストアップできます。例えば、

商品の返品方法がわからない
返金方法がわからない
商品交換方法がわからない
クレームの入れ方がわからない
商品の使い方を知りたい
プラットフォームの他の連絡方法を知りたい
...

エージェントにあまり多くの課題解決を求めるのはおすすめしません。対応するシナリオが明確で独立しているほど、効率よく問題解決できます。

人間と同じく、特定分野の「専門性」を持つことが重要です。

上記の例ではすべてが「ECカスタマーサービス」に関連しており、エージェントの役割イメージがはっきりします。

逆に、「ローンの提案」や「商品のおすすめ」など、ECカスタマーサービスと関係のないシナリオは、このエージェントから除外してください。

ポジショニング

シナリオを書き出したら、エージェントの明確な役割（ポジショニング）を決めます。

上記の例なら、「ECプラットフォームの質問に答え、返品や交換などをサポートするカスタマーサービス用エージェント」となります。

リソース

ポジショニングが決まったら、エージェントに必要なリソースを準備します。主にナレッジとツールの2つです。

ナレッジ

ナレッジとはエージェントが学ぶべき情報で、通常はドキュメントなどの形で用意します。

人間も業務をこなす前に、関連するナレッジを学ぶ必要があります。エージェントも同じです。

エージェントは持っているナレッジをもとにユーザーの質問に答えます。

たとえば、あるECプラットフォームの返品・交換手続きに関するナレッジがエージェントに用意されていない場合、エージェントは正しくレスポンスできません。最悪の場合、根拠のないデタラメな回答（ハルシネーション）を返してしまうこともあります。

エージェントのシナリオや役割に合わせて必要なナレッジドキュメントを用意しましょう。

例えば、返品や交換に関する質問に答えさせたい場合は、ECプラットフォームの返品・交換ルールや規約に関する資料を準備します。

ツール

ツールとはエージェントがタスクを実行するために使う必要不可欠の道具です。

つまり「API」のことです。エージェントにAPIをツールとして提供することで、必要なタイミングでAPIを呼び出し、各種タスクを自動でこなせるようになります。

たとえば、ECサイトのユーザーが商品を返品したい場合、返品用APIをエージェントに組み込んでおきます。するとエージェントは、ユーザーの要望に応じてAPIを呼び出し、返品手続きを代行できます。

エージェントのシナリオや役割に合わせて、返品API、交換API、チケット発行APIなど必要なツール（API）を用意しましょう。

デザイン

設計方針が固まり、リソースも準備できたら、いよいよエージェントの具体的な設計に進みます。

アイデンティティプロンプト：エージェントの役割を定義する

優れたエージェントを作るには、まず「アイデンティティプロンプト」を適切に設定することが重要です。

アイデンティティプロンプトではエージェントの役割・スキル・タスク・制約などを明確に定義します。これにより、エージェントが自分の責任を理解し、より適切に動作します。

詳しくはこちら：効果的でパワフルなアイデンティティプロンプトの作り方

コンテキストの割り当て：限られた情報量の中で必要な情報を扱う

エージェントは大規模言語モデル（LLM）を基盤としていますが、LLMには「コンテキスト長」という扱える情報量の上限があります。

人によって短時間で多くの文章を読める人もいれば、そうでない人もいます。LLMのコンテキスト長も人が短時間で理解できる情報量に似ています。

そのため、限られたコンテキスト内で必要な情報だけをLLMに与え、無関係な情報はできるだけ減らすことで、よりよい結果を得ることができます。

詳しくはこちら：LLMコンテキストを適切に割り当てる方法

ナレッジベース：エージェントにナレッジを与える

事前に用意したナレッジドキュメントをナレッジベースにアップロードします。これにより、ユーザーが質問したとき、エージェントはまずそのクエリでコンテンツベースを検索し、関連するドキュメントから情報を見つけて要約し、回答を返します。

ただし、ナレッジドキュメントをそのままエージェントのナレッジベースにアップロードする方法が、必ずしもナレッジ活用の最適解とは限りません。
RAGフレームワークやLLMのタスク設計によって、より良いナレッジ運用方法が変わる場合があります。
自分のシナリオに最適な方法を検討したい場合は、以下の記事も参考にしてください。

詳しくはこちら：コンテンツベースの操作方法

ツール：エージェントにタスク実行機能を持たせる

ツールモジュールでは、用意したAPIをツールとしてパッケージ化し、エージェントに追加します。これにより、エージェントはこれらのAPIを使って特定のタスクを実行できます。

詳しくはこちら：ツールの作成方法

また、GPTBotsには多数の既存ツールも用意されており、必要に応じてエージェントにそのまま追加できます。

フロー：複雑な処理やプロセスに対応する

エージェントのロジックが複雑で、多くのステップや条件分岐が必要な場合は、「フロー」機能が便利です。フローを使えば、キャンバス上でエージェントのワークフローをドラッグ＆ドロップで自由に設計できます。

詳しくはこちら：フローについて

メモリ：エージェントに継続的なタスク処理を持たせる

人と人との会話と同じように、前回どんな話をしたかを覚えておかないと、話題を続けたりスムーズに会話を進めることができません。

エージェントの「メモリ」はこの役割を果たします。

メモリ機能を有効にするかどうか、またどのように活用するかは、エージェントのサービス内容によって選択できます。例えば:

複数回のやり取り（深い議論や相談など）が必要な場合は、「長期メモリ」を有効にすることで、会話の流れを保ち続けられます。
数回のやり取りで解決できる場合（オンライン相談など）は、「短期メモリ」のみで十分です。
1回のやり取りで完結する場合（例：メール作成など）は、メモリ機能自体を使わなくても問題ありません。

同時に、「ユーザー属性」をエージェントのメモリとして持たせることで、ユーザーに関する情報をエージェントが理解し、よりパーソナライズされたサービスを提供できるようになります。

例えば、ホテルのルームサービス用エージェントの場合、エージェントがゲストとやり取りする際にはユーザー属性を通じてあらかじめゲストの氏名や部屋番号などの情報を取得しています。そのため、ゲストがエージェントを使って食事の注文を依頼した場合でも、改めて氏名や部屋番号を聞く必要はありません。どの部屋に届ければいいかは既に分かっているため、エージェントは「どんなサービスをご希望ですか？」だけを確認すればよいのです。

公開・利用場所の検討：エージェントをどこで活用するか

自分のユースケースに合わせて、エージェントをどのチャネルやサービスに組み込むべきか検討しましょう。

ユーザーが利用する場所にエージェントを組み込むことで最大限活用できます。

事例紹介

ここまでの内容を読んでも、「エージェントの設計方法がまだピンとこない」という方のために、実際のサンプルを多数用意しています。

エージェント作成時にどれかテンプレートを選ぶだけですぐにエージェントを作成できます。テンプレート内であらかじめ設定されている各パラメータを参考にしながら、「自分ならどう設計するか」を考えてみるのもおすすめです。この方法はエージェント設計を学ぶ上で非常に効果的です。