チャット型ソフトウェアからAIアシスタント型ソフトウェアへの変化

OpenAIが発表したChatGPTの登場から、一年以上が経とうとしています。ChatGPT API公開後の初期段階では、人間とAI（特にここでは大規模言語モデル）との単純な対話を提供するソフトウェアが中心でした。しかし今では、OpenAI GPTs（以下GPTs）やMicrosoft Copilot（以下Copilot）を代表とする、AIによる外部データへのアクセスやAPI通信によって人間を支援する「AIアシスタント型」のソフトウェアが台頭してきています。

GPTsは、ユーザー自身が好みのAIアシスタントを制作できる仕組みです。ChatGPTは汎用的な仕組みのため、特定の業務を行わせようとすると、役割や前提を含んだ長々としたプロンプトを入力する必要がありました。その点でGPTsは、AIに対する指示だけでなく、AIが参照可能な情報や行動もあわせてユーザーが事前設定しておくことで、特定の用途に特化したAIアシスタントを制作することができます。これまでは、ChatGPTを使いこなそうとすると、用途に対応した様々なプロンプトを辞書のように手元に保管しておく必要がありましたが、GPTsの登場により、単に目的別のGPTsに話しかければタスクをこなすことができるようになったのです。

例えば筆者であれば、記事のURLを入力すると自分好みの要約を作成してくれるGPTsや、ファクトチェックのためにいくつかの情報源を探索してくれるGPTsなどを業務上の必要に応じて作成しており、自社の業務を手伝ってくれるオンラインアシスタントさんにも活用してもらうことで業務の効率化を図っています。

GPTsは自身で作成するだけでなく、他のユーザーが作成したものを使用することもできます。論文のPDFをアップロードすると、その内容をわかりやすく日本語で解説してくれるPaper Interpreterや、論文のリサーチを行ってくれるConsensusなどは、筆者も日常で活用しています。

一方でCopilotは、現在はOfficeアプリケーションの操作を補助するためのAIアシスタントです。Wordでの文章生成やExcelでの数値データ処理の支援、PowerPointでのスライドスタイル変更やOutlookでのメール要約といったタスクを支援してくれます。将来的にはGPTsと同じようにユーザーがカスタムしたCopilotを作成できたり、Teamsでのミーティングの書き起こしから参加者別に個別にToDoが書き起こされたり、出席できなかったメンバーにはその人にとって重要だと思われる内容の要約が配られるようになる、といった展望が示されています。

人間がソフトウェアを扱うのではなく⁠、AIがソフトウェアを扱う時代に

これらの例に共通するのは、従来は私たちが手ずから情報を検索したり、ファイルを収集してまとめたりしてきたことを、AIが代行してくれている、ということです。Copilotの例で言えば、これまでは人間が覚えなくてはいけなかったWordやExcelの操作を、AIアシスタントが代わりに行ってくれるようになってきている、というわけです。

これをもう少し抽象化して考えてみると、私たち人間がソフトウェアを扱うモデルが、「⁠人間がソフトウェアを操作する」というモデルから、「⁠人間がAIに指示をして、AIがソフトウェアを操作する」というモデルに転換してきていると考えることができます。ソフトウェアを扱う主体が、人間からAIにシフトしているのです。

例えば、検索システムを活用しての情報収集とその結果のレポートをGPTsに依頼するとしたとき、検索システムへの検索クエリはAIが生成しています。AIが依頼を達成するために必要だと考えられるクエリを多面的に生成し、検索を実行して情報収集した結果がレポート生成の入力情報となり、そのレポート自身もAIがアウトラインを設計して生成する動きになります。人間はあくまで依頼を行っているだけであり、その依頼をもとにソフトウェアを駆使して依頼を達成しようとしているのはAIです。

このようにAIがソフトウェアを操作し、これまで人間が行ってきたタスクを自律的にこなしてくれる仕組みのことを、拙著『その仕事、AIエージェントがやっておきました。』では、AIエージェントとして紹介しました。

拙著ではAIエージェントを、「人がいちいち指示をしなくとも自分でやることを考えて、様々なツールを活用して目標に向かってタスクをこなしていくAIの仕組みのこと」であると定義しています（ここで言うツールは、ここまでの例で提示してきたソフトウェアと同じ概念⁠）⁠。前段で紹介したAIアシスタントであるGPTsもCopilotも、AIがタスクをこなすためにユーザーから具体的な指示を与えているわけではありません。ユーザーはあくまで、「⁠〇〇して欲しい」と依頼内容だけを伝えており、そのためにAIが使用できるソフトウェアをどのように使えばよいかは、AI自身に委ねられているのです。

ここまで説明してきたAIアシスタントはAIエージェントとほぼ同じ概念ですが、ユーザーを補助する（アシストする）ニュアンスが強い言葉になっています。そのためユーザーの補助も含め、タスクを自律的にこなしてくれる上位概念として、ここからはAIエージェントという言葉を使って解説していきます。

AIにとって使いやすいソフトウェアとは

このような構造の変化は、ソフトウェアの作り方そのものも変えていくと筆者は考えています。例えばAIが扱うソフトウェアは、AIにとって扱いやすいものになっていなくてはなりません。

これを具体的に見てみると、インターネット検索を行うAPIにおいても変化が現れています。インターネット検索を行うためによく用いられるGoogle Search APIやSerp APIといったAPIは、検索結果を人間に提示するのには向いていますが、AIに提示するのには向いていません。人間向けの体験では検索結果をもとに実際にWebページを巡回することが想定されていますが、AIは必要な情報をテキストで収集したいだけなので、検索キーワードに対して包括的なコンテンツがスコア付きで返ってくることが期待されているのです。

このようなAI向けの体験を提供するために活用されているのが、Tavily Search APIです。拙著で紹介しているレポート生成エージェントのGPT Researcherは、このTavily Search APIを使うことで効率よくインターネット上からデータを収集しています。

（⁠「⁠生成AIを活用したビジネス」で検索した際の検索結果。図2がSerp APIによる情報取得結果で、図3がTavily Search APIによる情報取得結果。Tavily Search APIの結果はAIに渡すための情報抽出に特化していることがわかる）

またGPTsでは、外部のAPIに接続するためにActionsという機能があります。そのActionsを利用するためには、OpenAPIのスキーマ定義に則ってJSONによる定義ファイルを設定する必要があります。現在は手動で設定をする必要があり、OpenAIからもJSONによる定義ファイルを作成するためのGPTsが提供されていますが、APIの利用ユーザーが人間からAIに今後シフトして行くのであれば、そもそもAPI側がOpenAPIのスキーマ定義に則ったJSONを提供する必要が出てくるでしょう。もっとも、OpenAPIやSwaggerといった規格では、かねてよりAPIクライアントもあわせて生成できるようになっていることから、そもそもこれは従来からの流れがさらに強化されるに過ぎないのかもしれません。

ソフトウェアの利用方法を考えるAIの仕組み

ソフトウェアがAIにとって扱いやすくなっていくと同時に、AI自身もソフトウェアを効率的に扱えるようになる必要があります。そのためにはAI自身が、ユーザーの依頼を達成しようとする中でどのようなソフトウェアをどのように使用すればよいかを「計画」する必要があります。そのために行われるのがタスク分解です。

カレーライスを作るシーンを例に、タスク分解について考えてみましょう。私たち人間はカレーライスを作ろうと思ったとき、何カレーを作るのか、どんな具材を利用するのかなど、カレーライスを作るための段取りを考えながら行動するのではないでしょうか。玉ねぎやスパイスなどの具材がない場合はそもそも買い出しに行かなければなりませんし、そもそも食器が洗われていない場合はまず片付けからする必要があります。「⁠カレーライスを作る」という行動一つをとってみても、大なり小なりこの行動を分解して動いていると考えられます。

このように考えると、AIも人間と同様に行動をタスク分解することによって確実に依頼を遂行することができるようになるのではないか、という仮説が立てられます。実際に、このアプローチはPlan-And-Solveという名前のついた正統なアプローチです。カレーライスの例で言えば、レシピに必要な材料をリストアップしたり、必要な材料を購入したり、必要な調理器具を準備したりといった一つひとつの動作がソフトウェアの利用に相当します。レシピに必要な材料をリストアップするために、レシピのデータベースにアクセスして最もユーザーのニーズに近いデータを抽出してくる、といった具合です。あるいは、レシピ提供サービスにAPI通信してデータを取得してくるのかもしれません。どのような手段でデータ取得すればよいかもAI自身が考えるのであり、そのための段取りとして事前のタスク分解があるのです。

一方で、ユーザーの依頼によっては実行前に完璧なタスク分解を行うのが難しいケースもあります。AI自身が事前学習しているような内容であれば仮説を立てることができますが、最新の情報に関するリサーチ依頼などAI自身が学習していない内容の場合、まずは少し検索してみて何となく情報を把握してから再計画する、といったアプローチをとる必要があります。私たち人間が同様の仕事をする際にも、似たようなアプローチをとるのではないでしょうか。

このように、実際にエージェントを設計しようとすると、「⁠あれ、この場合はどんな風に設計したらもっと柔軟にAIが動いてくれるような設計になるんだろう？」と様々な問題に突き当たります。計画一つを取っても様々な考え方があり、「Understanding the planning of LLM agents: A survey」というサーベイ論文が出ているほどです。「⁠AIがすべてを解決してくれる」と言えるほど現在のAIは万能ではなく、AI本来の力を使いこなしていくためには相応のソフトウェアアーキテクチャを設計する必要があるのです。

AI同士がチームとして活動する

また、AIエージェントの業務実装に取り組む人々にとっての現在の関心は、複数のエージェントを協調動作させるマルチエージェントという発想に集まっています。拙著でも紹介したGenerative AgentsやChatDevといった事例が、マルチエージェントの事例にあたります。

何でも汎用的に依頼をこなす単一のAIエージェントを作るのは、実は困難です。私たち人間が何かを見ようとするとき、その視界に現れないものが無視されてしまうのと同様に、AIも何らかの事象に焦点を当てているときには、それ以外のものが盲点となります。このような性質から、チームワークでその盲点を軽減しよう、というのがマルチエージェントの発想です。私たちがチームを組んだり、会社のような組織を作り上げるのと同じ発想ですね。

例えばリサーチ業務を行うAIエージェントを設計する場合、情報を収集するAIエージェントとレポートを作成するAIエージェントを分割する方が成果物の品質は良くなります。上の図ではそれぞれをリサーチチームとドキュメントチームに分割し、監督者がそれぞれのチームをマネジメントするヒエラルキー型の構造で、タスクが遂行されるように設計しています。各チームではそれぞれ実際に検索システムで検索を実行するエージェントやWebをスクレイピングするエージェント、実際に文章を生成するエージェントや図を生成するエージェントが協調動作するように設計しています。

リサーチ業務を行うAIエージェントを設計する解がこれだ、という訳ではないですが、ある意味組織を設計するかのようにAIエージェント同士がより良い協働を生み出すためにはどうすればよいかを考える必要のあるところが、AIエージェントを活用したソフトウェア設計の面白いところだと筆者は考えています。

まとめ

私たちがAIエージェントをベースとしたソフトウェアに慣れ親しめば慣れ親しむほど、人間が主体となって操作するソフトウェアの形が、AIが主体となって操作するソフトウェアの形に変化していく。これを本稿では、AIエージェントによって変わるソフトウェアのパラダイムとして紹介しました。

拙著『その仕事、AIエージェントがやっておきました。』では、AIエージェントをベースとしたソフトウェアがどのようにビジネス上の課題を解決していくのかといった観点から、具体的にAIエージェントを設計するためにはどのような要素を検討する必要があるのかを、「⁠個性」「⁠記憶」「⁠計画」「⁠行動」の4つの観点から解説しています。さらに、プロダクトとしてすでに提供されているAIエージェントを例にとり、AIエージェントをベースとしたソフトウェアによって私たちの業務体験がどのように変化していくのかを追体験できる章も用意しています。今後起こりうるパラダイムシフトの前準備として、お手に取って頂ければ幸いです。