“ユーザフレンドリー”ならぬ”AIフレンドリー”の必要性について考えてみた

山本紘暉

2023.03.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

新規事業統括部Passregiチームの山本です。

先日、LangChainのAgentとZapier NLAを使ってみた記事を書いたのですが、それについてもう少し考えたので、記事として書いてみたいと思います。

https://dev.classmethod.jp/articles/tried-langchain-with-zapier-nla/

※ 本記事の内容は、考えてみたというレベルのものであり、推測などを多分に含みますので、ご注意ください。

補足：「AIフレンドリー」という言葉について

今回の説明のために考えてみた単語です。

とりあえずChatGPT（GPT-4）に聞いてみました。

Google検索の検索結果数をみるとそこまで数が大きくなく、テクノロジー分野でもそこまで広く使われてなさそうです。「”ai friendly”」の検索結果も、あまりそれっぽい感じではありませんでした（3/20）。

検索ワード	検索結果数
"aiフレンドリー”	約 703件
"ai friendly”	約 72,900件
"user friendly”	約 169,000,000件

同じような考え方はどこかですでにあるような気がするので、別の単語があるのかなと思います。（一応GPT-4に聞いてみましたが、期待している感じの答えではなかったです）

AIフレンドリーの考え方や必要性

さて、本筋に戻りたいと思います。

最近ChatGPTなどのAIが高性能になっています。今後AIがデータや情報を整理する主体になっていくことを考えると、データや情報をAIが使いやすい形に整理することが求められてきます。もちろん、AIがどんなデータや情報でも正しく扱えるようになることが理想ですが、データや情報からも歩みよることで、精度が高める（ミスがしにくくなる）ことできそうです。

（Webページの対応についてmotchieさんが記事に書かれているので、こちらを合わせてご参照ください）

https://dev.classmethod.jp/articles/improving-website-markup-for-effective-gpt-learning/

これは、サービスやアプリケーションに対しても同じことが言えるかと思います。先日試したLangChainのAgentの場合、Toolのインターフェースさえ整えれば、あとはそのタスクが必要かどうかをAgentが判断して、他のToolと連携した作業を一気に行うことができます。

https://dev.classmethod.jp/articles/tried-langchain-with-zapier-nla/

つまり、今までのケース（下の１・２番目）だけでなく、新しいケース（３番目）が追加されたことになります。

ユーザ（人間）がWebやアプリから操作する（ユーザフレンドリー）
エンジニアがドキュメントを読みプログラムを作成して、APIを実行する（開発者フレンドリー・プログラムフレンドリー(？)）
AIが指示を出して実行する（AIフレンドリー）

今後、効率化の面から情報処理や作業操作の主体としてAIの数や割合が増えていくことを考えると、AIが使いやすい形にしておかないと、自社のサービスやアプリケーションが使われなくなってしまうことがありえそうです（今までも、APIが提供されていないサービスよりも、提供されているサービスの方が選択されやすかったかと思います）。

サービス・アプリケーションのAIフレンドリーとして求められること

LangChain Agent + Zapier NLAを参考に、サービスがAIフレンドリーであるために、求められることを考えてみました。各レベルはどこかに定義されているものではなく、今回暫定的につけたものです。指示を出すAI側が変われば、サービス側が提供するべき内容も変わるかと思います。レベル２まで書きましたが、もしかしたらもっと高度なレベルがあるかもしれません。

レベル０

各タスクに対して、Agentがわかりやすい説明を提示する
- (Agentは各タスクの内容を理解し、どのタスクを使えばよいか選択する)
- (そのタスクに必要なパラメータを考えて実行する)
あるタスク（Action）に対する、パラメータ化された命令を処理できる

レベル１（現状）

各タスクに関して、Agentがわかりやすい説明を提示する
- (Agentは各タスクの内容を理解し、どのタスクを使えばよいか選択する)
- (選択したタスクに対して、自然言語で指示を出す)
あるタスク（Action）に対する自然言語の指示を実行できる

レベル２（理想形？）

サービス全体に対する自然言語の指示を実行できる
受け取った自然言語の指示から、サービス内どのタスクを実行すればよいか判断する
- 複数のタスクを実行する必要がある場合は、順序なども決定する
- サービスの利用状況やコンテキストによって実行するタスクを変える（ことが必要かも？「メールをください」という指示に対して、ユーザがGoogleと連携するよう設定されている場合はGmailからメールを検索し、ユーザがMicrosoftと連携するように設定されている場合はOutlookから検索する、というようなことがあるかも？）

どうすれば良いか

LangChainのAgentに渡される、Zapier NLAのTool（上記のレベル１に該当）に含まれる情報の中で、主なものは以下のとおりです（これをサービス側が作る必要がありそうです）。

（name（メンバー変数）：タスクの名前）
description（メンバー変数）：そのタスクの内容に関する説明。Agentが受け取り、どのタスクを利用するべきか判断する。
_run（メソッド）：そのタスクの実行方法。instruction（自然言語の指示）を受け取り、Zapier NLAのAPIに渡す。

まず、前提である_runメソッドとして、サービスがタスクに関する自然言語の指示を受け取り、それをパラメータ化して実行できるようにする必要があります。これは新しくAIを利用する箇所なので、少し内容としては重そうです。

次に、descriptionを考える必要があります。少し頭を使う箇所かと思います。

例として、Slackのチャンネルにメッセージを送るTool（タスク。Action）のdescriptionをみてみると、以下のようになっています。

A wrapper around Zapier NLA actions. 
The input to this tool is a natural language instruction, 
for example "get the latest email from my bank" or 
"send a slack message to the #general channel". 
Each tool will have params associated with it that are specified as a list. You MUST take into account the params when creating the instruction. 
For example, if the params are [\'Message_Text\', \'Channel\'], your instruction should be something like \'send a slack message to the #general channel with the text hello world\'. 
Another example: if the params are [\'Calendar\', \'Search_Term\'], your instruction should be something like \'find the meeting in my personal calendar at 3pm\'. 
Do not make up params, they will be explicitly specified in the tool description. 
If you do not have enough information to fill in the params, just say \'not enough information provided in the instruction, missing <param>\'. 
If you get a none or null response, STOP EXECUTION, do not try to another tool!
This tool specifically used for: Slack: Send Channel Message, 
and has params: [\'Message_Text\', \'Channel\']

もう少しプログラムをみてみると、これにはベース（テンプレート）がありました。最後の２行にかかれている{zapier_description}と{params}がPythonプログラム内部でformatされて、各Action（Tool）に合わせて書き換えられるようです。

# flake8: noqa
BASE_ZAPIER_TOOL_PROMPT = (
    "A wrapper around Zapier NLA actions. "
    "The input to this tool is a natural language instruction, "
    'for example "get the latest email from my bank" or '
    '"send a slack message to the #general channel". '
    "Each tool will have params associated with it that are specified as a list. You MUST take into account the params when creating the instruction. "
    "For example, if the params are ['Message_Text', 'Channel'], your instruction should be something like 'send a slack message to the #general channel with the text hello world'. "
    "Another example: if the params are ['Calendar', 'Search_Term'], your instruction should be something like 'find the meeting in my personal calendar at 3pm'. "
    "Do not make up params, they will be explicitly specified in the tool description. "
    "If you do not have enough information to fill in the params, just say 'not enough information provided in the instruction, missing <param>'. "
    "If you get a none or null response, STOP EXECUTION, do not try to another tool!"
    "This tool specifically used for: {zapier_description}, "
    "and has params: {params}"
)

これを見ると、以下のようなことが言えるかと思います。

AI用にプロンプトを作成する必要はある
が、タスク毎（Tool・Action）ごとに大きく変える必要がない
内容は人間向けに書いていたコメントやドキュメントと大きく変わらない（流用できそう）
- (場合のよってはAIに作成させても良いかも)

なので、そこまでdescriptionを作成するのは大きな手間ではなさそうです。

(おまけ)

もしかしたら、近い将来人間もAIフレンドリーになる必要があるかもしれません（自分でも何を言っているかよくわかりませんが）。とりあえず自分をAIフレンドリーにしてみました。

(以下、自分の自己紹介ブログの内容を入力しました)

結果は以下のようになりました。コンテキスト（特性・趣味）やできること（注意点）などが書かれいていい感じな気がします。これがあればAIと仲良くなれるでしょうか

(少し真面目な話をすると、例えばアサインを考える業務を補助するAIや、顧客からのコンタクトが有った際に内容に応じたメンバーにつなぐ作業をするAIを考えた場合、（自己紹介文をそのまま入力するのも良いですが）このように形を整えてあげても良いかもしれません。)

まとめ・感想

AIが進化していく中で、サービス側がどうすればよいかについて、AIフレンドリーという言葉で考えてみました。タスクレベルでの指示を自然言語で受け取り実行できること、AIがそのタスクで使用できるか判断できるようにdescriptionを考えることが必要そうです。前者は重めの話ですが、後者は今までの手法を活用できそうです。

あまりこの分野に詳しくないまま書いているので、間違い・勘違いなどがあるかもしれません。

読んだ方が何か考えるきっかけや材料になれば幸いです。