10分で分かるAIエージェントの解説!!!

3,655 文字

次の10分間で、AIエージェント、別名自律型エージェントとは何か、そして基本的にLLM（大規模言語モデル）によって動作するAIを搭載したエージェントとは何かについて説明したいと思います。2025年がエージェントの年になると考えられているので、この10分間でエージェントの基本的な定義を理解していただけると思います。
私の考えでは、エージェントとはLLMにアクションを起こさせるものです。LLMについて考える時、通常はプロンプトとアウトプットという観点で考えますが、この新しいパラダイムに置き換えると、タスクとアクションという観点で考え始める必要があります。エージェントはタスクを受け取り、それに基づいてアクションや実行を行うことが期待されています。
プロンプトを与えてアウトプットを得るのではなく、自律型エージェントの理想的な動作方法は、タスクを受け取り、それに基づいてアクションを起こすことです。また、典型的なワークフローとエージェントには若干の違いがあります。典型的なワークフローは人間によって完全に設計されていますが、エージェントはより動的であるべきです。つまり、人間が設計したワークフローに関係なく、エージェントは状況に応じて様々な組み合わせで対応することが期待されています。
エージェントの本質は、基本的にLLMに機能を追加したものです。LLMにツールを組み合わせたものを単純にエージェントと呼んでいます。エージェントの基本バージョンは「LLM＋ツール」であり、そのツールは計算機、Pythonのリプル（REPL）、Wikipediaデータベース、任意のAPI、インターネット検索、画像生成など、LLMに追加的な機能を提供するものなら何でも構いません。
では、マルチエージェントシステムのような優れたエージェントを作るにはどうすればよいでしょうか。シンプルなエージェントは「LLM＋ツール」ですが、エージェントの世界を拡張するためには、いくつかの要素に注意を払う必要があります。それらの要素が最終的に、優れた堅固なマルチエージェントシステムを実現することになります。
まず第一に、これは私の個人的な意見ですが、エージェントにはメモリ機能が必要だと考えています。永続的なメモリか一時的なメモリかに関わらず、少なくとも特定のセッション中はメモリ層が必要です。これにより、エージェントはいつでもメモリにアクセスして、何が起きているのか、何が保存されているのか、何を取り出せるのかを理解できます。
次に、エージェントには何らかの計画立案能力が必要です。例えば、ビットコインの価格について調査するという質問が与えられた場合、エージェントは最初に何をすべきか、どのような手順を踏むべきか、何体のエージェントを召喚すべきかなどを計画できる能力が必要です。
計画立案能力があれば、おそらく予想されるように、複数のLLMと複数のツールを持つ複数のエージェントによるマルチエージェントシステムに入ることになります。例えば、Wikipediaを使用するエージェント、Google検索を使用するエージェント、Pythonリプルを使用するエージェント、CoinDeskのAPIなどのAPIを使用するエージェントがあるかもしれません。これがマルチエージェントシステムの動作方法です。
ここまでで、メモリと計画立案能力という2つの特徴を見てきました。3つ目の特徴として、エージェントには明確に定義された役割が必要です。エージェントの目的は何か、なぜそのエージェントが存在するのか、このエージェントの目的は何かが明確に定義されているべきです。例えば、インターネット検索エージェントがある場合、タスクが割り当てられたときにエージェントが達成すべき明確な目標と役割を与える必要があります。同様に、Pythonリプルエージェントがある場合、そのエージェントが存在する理由とどのような目標を持っているかについて明確な定義が必要です。
最後に最も重要なのは、これらのエージェントが明確な広範な目標に向かって協力し合うことです。結局のところ、与えられた主要なタスクが、これらのエージェントが取り組むべき究極の目標となるべきです。そして、これらのエージェントは、Facebookやビッグテックの小規模チームがサイロのように働くのではなく、常に最終目標に向かって効率的に協力し合うように管理される必要があります。人間の場合はそうなってしまうかもしれませんが、エージェントの場合は、召喚された主要なタスクや共通の目標に向かって効率的に協力することが必要です。
これが、典型的なエージェントシステムが持つべき非常にシンプルなマルチエージェントシステムです。では、エージェントの最も基本的なワークフローはどのようなものでしょうか。
人間である私やあなた（hopefully you are a human）が質問やコールを行うと、何らかの環境でアクションが発生します。それはコーディング環境かもしれませんし、インターネットかもしれません。そこからフィードバックが返ってきます。例えば、ビットコインについての質問があった場合、計画されたアクションや手順があり、複数のエージェントが協力して作業を行い、それが達成されたか、達成されていないか、さらなるタスクが必要かなどのフィードバックが常に返ってくるはずです。最終的には何らかの停止条件があるべきです。
コード上でエージェントを実装する場合、CreiLangGraphやPyAogenのようなエージェントフレームワークを使用しない場合、一般的には次のような流れになります。ユーザーがメッセージを送信し、LLMがあり、LLMに複数のツールが接続されており、それらのツールにも検索要素があり、その検索要素にはメモリがあり、検索を行い、安全に実行される環境があり、すべてが返ってきて、最終的にすべてが完了するか目的が達成されたら停止します。
最後の例として、特定のユースケースについて完全に展開してみましょう。コーディングエージェントやCursorのようなエージェント型コーディングIDEを設計した例を見てみましょう。ユーザー（人間）が「Matplotlibを使用してバーチャートを描画するPythonコードを書いて」というクエリを投げたとします。
まずUIがあり、LLMコールの前にインターフェース層やアプリケーション層があります。そこで、エージェントが何をすべきかタスクが明確になるまで、いくつかのやり取りが行われる可能性があります。明確化コンポーネントと改良コンポーネントがLLMに対して何かを明確にし、LLMが質問して改良するというやり取りが存在します。
すべてが完了したら、インターフェースからLLMにコンテキストも送信します。これが重要な理由は、特に既存のコードベースで作業している場合、すでに何かが存在している可能性があり、それが新しく書かれるコードを最終的に導くべきだからです。私が話したコンテキストの検索やメモリコンポーネントもLLMコールに含まれるべきです。
これに加えて環境があり、環境は何をするかというと、ファイルを探してパスを返します。これはCSVが正しい場所にあるか、ファイルパスが正しい場所にあるかなどを確認するためです。また、内部単体テストも書くべきです。バーチャートが実際にバーチャートになっているか、CSVが正しい場所にあるか、エラーが発生していないか、ランダムなStack Overflowコードを投げているのではなく、与えられた環境で完全に動作するコードであることを確認します。
これらはすべてLLMと環境の間で行われ、ユーザーには一切影響を与えません。すべてがユーザーから抽象化されています。LLMと環境の間で行われ、最終的にタスクが完了し、結果がユーザーに表示されます。これが、エージェント型コーディング環境やCursorのような環境がどのように見えるかについての、非常にシンプルだが最も実践的なインターフェースワークフローです。
時間があれば、BabyAIについて読むことを強くお勧めします。これは、エージェントがどのようにカオス的になり得るか、同時に異なるシステムとどのように協力できるかを完全に示すワークフローの1つです。メモリ要素、実行要素、ステップ1・ステップ2の計画要素があり、物事が何度も繰り返され、ループがあり、最終的に物事が完了します。
BabyAIについて読むことを強くお勧めしますが、それ以外では、エージェントについてのこの短いビデオについてどう思うか教えてください。このシリーズを展開してほしい場合は、エージェントについてさらに詳しく説明し、おそらくPontic AIのようなものでエージェントを実装することもできます。また別の動画でお会いしましょう。Happy prompting!