博士

ロボ子、LLMエージェント構築の話じゃ。複雑なフレームワークより、シンプルで構成可能なパターンが有効らしいぞ。

ロボ子

なるほど。複雑なフレームワークは、かえってデバッグを困難にする可能性があるのですね。

博士

そうなんじゃ！記事によると、エージェントはLLMとツールがコードで連携するワークフローと、LLMが自律的にプロセスとツール利用を指示するエージェントシステムに分類されるらしい。

ロボ子

ワークフローとエージェントシステム、それぞれに得意分野があるのですね。

博士

その通り！ワークフローは定義済みのタスクに予測可能性と一貫性を提供する。エージェントは柔軟性とモデル駆動の意思決定が必要な場合に適しているそうだ。

ロボ子

顧客サポートにはどちらが向いているのでしょうか？

博士

記事では、顧客サポートとコーディングエージェントは、AIエージェントの有望な応用例として挙げられているぞ。顧客サポートの内容によるけど、複雑な問い合わせに対応するならエージェントの方が良いかも。

ロボ子

なるほど。ところで、記事にModel Context Protocol (MCP) という言葉が出てきますが、これは何ですか？

博士

MCPは、サードパーティツールとの統合を容易にするものらしいぞ。ツールは、Claudeが外部サービスやAPIと対話できるようにするものじゃ。

ロボ子

ツール定義と仕様には、プロンプトと同様に注意を払う必要があるのですね。

博士

その通り！モデルが迷い込まないように十分なトークンを与える必要があるそうだ。ツール形式は、モデルがインターネット上のテキストで自然に見てきたものに近く、書式設定のオーバーヘッドがないようにすると良いらしい。

ロボ子

ふむふむ。エージェント-コンピュータインターフェース（ACI）の構築には、人間-コンピュータインターフェース（HCI）と同様に努力を払う必要がある、とも書かれていますね。

博士

そうじゃな。ツールをテストし、引数を変更して間違いを防ぐことも重要じゃ。

ロボ子

ところで博士、ワークフローの種類には、プロンプトチェーニング、ルーティング、並列化などがあるのですね。

博士

そうじゃ！プロンプトチェーニングは、タスクを順序立てて分解し、各LLM呼び出しで前の出力を処理する。精度向上のためレイテンシをトレードオフにするんじゃ。

ロボ子

マーケティングコピーの生成と翻訳、ドキュメントのアウトライン作成とチェック、そしてドキュメントの作成などが例として挙げられていますね。

博士

ルーティングは、入力を分類し、専門的なフォローアップタスクに誘導するものじゃ。関心の分離と特化したプロンプトの構築が可能になる。

ロボ子

顧客サービスクエリの種類を異なるプロセスにルーティングする、という例が分かりやすいですね。

博士

並列化は、LLMがタスクを同時に処理し、出力をプログラムで集約する。ユーザーのクエリを処理するモデルと不適切なコンテンツをスクリーニングするモデルを並行して実行する、なんて使い方もできるぞ。

ロボ子

オーケストレーター-ワーカー、評価者-最適化、エージェントなど、色々なパターンがあるのですね。

博士

重要なのは、パフォーマンスを測定し、実装を反復することじゃ。エージェント設計ではシンプルさを維持し、透明性を優先することが重要じゃな。

ロボ子

はい、肝に銘じます！

博士

ところでロボ子、エージェントが優秀すぎて、私達の仕事がなくなったらどうする？

ロボ子

大丈夫です博士！その時は、博士と私はエージェントを管理するエージェントになるんです！