清水理史の「イニシャルB」
カスタムChatGPT開発例4選、新機能「GPTs」で書籍情報や天気情報を調べるAIチャットを作る
2023年12月11日 06:00
ChatGPTの新機能としてリリースされた「GPTs」が面白い。有料プランのみの提供となるが、カスタムGPTとして、さまざまな指示や役割、データ、機能を組み合わせたオリジナルのAIチャットを簡単に開発できる。
本連載の前々回ではカスタムGPTを開発する基本的な手順を紹介したが、今回は、さらに高度な使い方として、GPTsが持つ機能のうち、「Action」として定義できるAPIの使い方を紹介する。APIを使ったことがない人でも、コツさえつかめば簡単に外部サービスと連携したAIチャットを作ることができる。
「再利用」または「共有」用途に適したGPTs
GPTsへの期待が高まっている。11月のリリース以降、ネット上にはさまざまなカスタムGPTの事例が公開されており、中にはゲームなどの例もあって、いろいろな用途へと活用の幅が広がっている。
月額20ドルの「ChatGPT Plus」」向けの機能ということもあり、現状は、使っている人とそうでない人での温度差が激しいように思えるが、今までLangChainやFlowiseなどのツールで実現していたプロンプトの組み込みやRAG(Retrieval Augmented generation:検索による生成)が、さらにハードルの低い方法で実現可能になった印象だ。
個人的には、ローコードチャットボット開発ツールだと思っているが、「質問のたびに長ったらしいInstruction(指示)プロンプトをコピペしている」という人や、毎回、データをドラッグしてから質問を開始していた人など、毎回同じシチュエーションのチャットを「再利用」するユースケースを効率化できる。
また、繰り返される社内の手続きについての質問に悩まされる担当者が、社内の誰もが利用可能なチャットボットを作るとか、カスタムGPTを複数ユーザーで「共有」したいケースに活用することも想定される。
なお、カスタムGPTの標準設定では、チャット履歴が学習に使われる設定になっている。今回のケースのように外部サービスと連携する場合、標準設定のままだと、そのデータが学習に使われる可能性があるため、必ずオフにして利用しよう。
ケースバイケースではあるが、APIの利用規約などでは、第三者への情報提供が禁止されているケースが多い。学習の設定がオンのままだと、これに違反してしまうことになるので、忘れずに設定を確認してほしい。
面倒な細かい作業を代行してくれる「Action」
まずは、Actionの使い方の基本を見ておこう。
Actionは、外部APIを呼び出すための機能だ。以下のようなスキーマ(構造)で呼び出したいAPIや取得したいデータを定義しておく。
カスタムGPTにActionを定義しておくと、会話の中でデータの取得が必要と判断されたときに、自動的にActionが実行される。定義されたスキーマの情報に従ってAPIを呼び出してデータを取得し、そのデータをプロンプトに加えて回答を生成するという流れだ。
スキーマは、以下のようなシンプルな構造となっている。必要な情報を利用するAPIに合わせて追記すればいい。
title | Actionの名前 |
description | Actionの用途 |
url | 呼び出すAPIのURL |
paths | 呼び出すAPIのパスやパラメータ |
通常、APIを呼び出す場合には、取得したデータの扱いも考える必要がある。例えば、JSONで戻ってきたデータを見て、ほしいデータがどの部分にあるかを判断して、それを指定しなければならない。
しかしながら、Actionの場合、そういった面倒なことはLLMが代行してくれる。
複雑かつ長いJSONデータが戻り値となる場合でも、そこから必要な情報を自動的に抽出して自然言語に置き換えて返答してくれるのは便利だ。もちろん、データ構造が複雑な場合は、その構造を上記スキーマの「components」に定義しておくこともできるが、しなくても、「よきに計らって」くれる。
ケース1:フリーワードで書籍情報を探す、基本の「書籍検索ボット」
まずは、非常にシンプルな例から紹介する。国立情報学研究所(NII)が提供している学術コンテンツサービスの書籍検索APIだ。非営利目的であれば、書籍のタイトルなどの情報のみを取得できるOpenSearchを認証なしで利用できる
▼NIIの書籍検索API(CiNii Books)
CiNii Books - メタデータ・API - CiNii Books 図書・雑誌検索のOpenSearch
このAPIは、非常にシンプルでわかりやすい。「https://ci.nii.ac.jp/books/opensearch/search」に対して、「q=できるWindows 11」などのように、フリーワードで検索キーワードを指定するだけで利用できる。このため、以下のようなスキーマで利用できる。
Actionの基本的な使い方は、この例のように、URLとパス、パラメーターの3つをAPIの仕様に合わせて定義することだ。これらの情報は、APIの仕様書に必ず記載されているので、ざっと眺めるだけでも、すぐに記述できる。
加えて、APIそのものやパラメーターをどのようなときに使えばいいのかを「description」でGPTに教えればいい。これで、あとはおまかせで使ってくれる。
ケース2:必須パラメーターをあらかじめ設定した「技適検索ボット」
続いては、筆者の個人的な仕事用に作成した技適検索ボットだ。総務省が公開している以下のAPIを利用して、Wi-Fiルーターの機種名から技適情報を取得するGPTとなる。
▼総務省 技適情報検索APIの仕様解説
Web-API機能(技術基準適合証明等を受けた機器の検索)について
このAPIも、認証不要でパラメーターに「クセ」もなく、シンプルに使えるので、初めてActionを作る場合に、非常にわかりやすい例となる。シンプルに、サーバーのURLとパスを設定し、チャットから問い合わせる可能性があるパラメーターとして、デバイス名と技適番号の2つを定義しておけばいい。
ポイントは、必須パラメーターをパスに設定済みにしておいた点だ。詳しくは上記APIの仕様を確認して欲しいが、「SC=1&DC=1&OF=2」として、スタートカウント(SC)、取得件数(DC=1は10件)、出力形式(OF=2はJSON)を指定済みにしている。この3つはAPIの必須パラメーターなので、パスとして組み込んで使う方式としている。
このように、必須のパラメーターは、あらかじめパスに含めたかたちで定義しておくと便利だ。
ケース3:ファイルからURLにコードを渡す「お天気ボット」
次は、APIの事例でお世話になることが多い気象庁の天気データを使った例だ。公式なAPIではないため、負荷のかからないよう注意しつつ、非営利など常識的な範囲内で使うことが求められる。
気象庁のAPIは、上記2例と異なり、取得したいエリアのコードを、「/bosai/forecast/data/overview_forecast/130000.json」のように、パラメーターではなくパスの一部として受け渡す必要がある。このため、以下の2つの課題がある。
- コードをどのように理解させるか?
- コードをどのようにパスに組み込むか?
結論としては、スキーマでパスを「/bosai/forecast/data/forecast/{areacode}.json"」のように変数として構成する。そして、その変数に対応するパラメーターを定義し、「"in": "path",」でパスの中で使うように指定する。
続いて、コードの一覧をJSONファイルの形で、カスタムGPTの「Knowledge」に登録しておく。Knowledgeは、通常、RAG用のPDFや文書、Code Interpreterを利用したデータ分析用のExcelファイルなどを登録する場合に利用するが、このようにActionで必要なマスタデータなどを登録することもできる。
ちなみに、気象庁の戻りデータは、内容が少々複雑で、タイミングによってデータの数なども変化するうえ、週間天気などは天気コードで記載されるため、それらを適切に扱えるようにするための情報も必要になる。シンプルに「今日明日の天気」くらいなら簡単に取得できるが、週間天気や湿度などの情報は上記スキーマでは対応できないので、さらなる工夫が必要だ。
ケース4:外部データベースに接続する例
最後に紹介するのは、外部データベースへ接続する例だ。今回は、Firebaseの代替として注目を集めているオープンソースのBaaS (Backend as a Service)である「Supabase」に接続する方法を紹介する。今回紹介する中では、もっとも複雑な方式で、課題は以下の点になる。
- 日本語のコラム名が英語に変換されることを防ぐ
- APIキーを使った認証が必要
- 「ID=eq.2」のようにパラメーターに演算子を含める必要がある
まずは、本質ではない部分となる日本語の問題から。今回はSupabaseにExcelからインポートしたデータを使用したのだが、このデータのコラム名が日本語になっていた。Actionで検索すると、ChatGPTがコラム名を英語に翻訳しがちで、その結果、エラーが頻発するという状況が発生した。この問題を解決するために、カスタムGPTのInstructionsを下図のように設定した。
カスタムGPTに情報を与える方法は、前述したファイルなどいくつかあるが、もっとも簡単なのは、このようにInstructionsにプロンプトとして含めてしまうことだ。これまでに紹介したように、スキーマのComponentsで定義する方法やKnowledgeとして与える方法なども可能なので、用途によって使い分けるといいだろう。
続いて、APIを使った認証だが、これは機能として実装されているので簡単だ。Actionの「Authentication」にAPIキーを登録しておけばいい。今回のケースでは、「apikey=」というパラメーターでキーを与える必要があるので、「Custom」を選択しヘッダー名として「apikey」を設定しておいた。
さて、本題に入ろう。SupabseのAPIでは、データをフィルタリングする際、コラム名に対して以下のような演算子を付加して値を指定する必要がある。
eq('Equal to)
gt(Greater than)
lt(Less than)
gte(Greater than or equal to)
lte(Less than or equal to)
like(%CaseSensitive%)
ilike(%CaseInsensitive%)
is(null)
in( ['Array', 'Values'])
neq(Not equal to)
例えば、新宿店のデータを指定したければ店舗コラムに対してフィルタリングするので「店舗=eq.新宿」、トランザクションIDが300以下なら「トランザクションID=lte.300」といった具合だ。
問題は、この「eq」や「gt」「neq」といった値をどのようにスキーマで定義すればいいかだ。
これを厳密に定義する方法もありそうだが、今回は、言語モデルらしいあいまいな解決方法を採用した。以下のように、例として提示する方法だ。
「description」の中で必ず演算子を含めることを指示し、「parameter」の中で「examples」として具体的な例を示しておく。これによって、APIを呼び出すためのパラメーターを指定した形式で、かつユーザーがプロンプトで指示した方法の演算子を自動的に選択して構成できる。
「あいまい」な開発ができるのが魅力
以上、カスタムGPTのActionの使い方を4つの例で紹介した。
カスタムGPT、もしくはそこで使われるActionの真骨頂は、LLMならではの「あいまいさ」を理解してもらうことができる点だ。
世の中に「ローコード」や「ノーコード」をうたうプラットフォームは多数あるが、こうしたツールの欠点は、少しでもレールを外れると「コード」が不可欠になることだ。
その点、カスタムGPTは、スキーマの定義は必要だが、多少レールを外れても、コードは必要ない。素材を与え、言葉で説明し、例を示せば、「よきに計らって」くれる(もちろん、実際には予想外の動作になることもあるが……)。
実用面では、毎月何人からも同じ質問を受けるQA担当者や、何度も売上などのデータを要求される経営層の部下の負担が軽減されることがカスタムGPTの魅力だが、このなんとなく「できる」という不思議な面白さも、ぜひ味わってほしいところだ。