My GPTsが順次利用可能に！
先日、openAIのDevDayで情報が公開されたMy GPTsが昨日から順次利用可能になっています。
筆者にGPTアカウントでも利用可能となったため、色々と弄り倒して遊んでみました。
その中で、これは大きく体験を変えるなと思った事例があったので、今回はその内容をご紹介します。
頑張って書いたドキュメント、読まれていますか？
話は全く変わりますが、皆さん仕事でドキュメントは読まれていますでしょうか？また、自分が書いたドキュメントは組織内で活用されていますでしょうか？
特に、エンジニアの皆さんであれば、自分が作ったコード資産であったり、プログラムのドキュメントを作成したりというのは、日々の業務として取り組まれている方も多いのではないかと思います。
私はコードを書くのは好きなのですが、ドキュメントを書くのが結構苦手で、いつも面倒くさいなあ…と思いながら書いています。
なるべく読み手がわかりやすいように情報をまとめたりするのですが、ドキュメントって頑張って書いてもあまり読んでもらえず、ドキュメントに書いてあるのに直接自分に質問が飛んできたりして、せっかく書いたのになあ…なんて思う事も少なくありません（僕の書き方が悪い説もある）
また、自分がドキュメントを読む際にも、ドキュメント量が多くなるとそれだけで読む気が失せがちです。
例え情報が整理されていても、自分の欲しい情報を探し出すという行為は、想像以上に労力を使うものです。
なぜドキュメントは読まれないか？
なぜドキュメントを読まないのかといわれると大体面倒くさいからに集約するのではないかと思いますが、よく言われる要因としては下記の3つがあります。
- マニュアルをよむ習慣がない
- どこに何が書いてあるかわからない
- 読んでも内容が理解できない
特に下二つは自分にも覚えがあります。
ドキュメントの内容が専門的になればなるほど、読んでいても思考に引っ掛かりがおおくなり、欲しい情報を探すのも一苦労だし、読んでも理解できないという体験からドキュメント読むより書いた人に話聞く方が早いな…となりがちです。
My GPTsを用いた対話的ドキュメントの提案
本題です。
ドキュメントが読まれない理由をつらつらと書いてきましたが、その解決方法としてMy GPTsを使ってみようという話になります。
chatGPTでドキュメント整理というのは良くある事例かと思いますが、My GPTsを用いることで以下の点で優れていると感じました。
- 対話的インターフェースによって簡易にBOTを作れる点
- プロジェクトごとに専用の知識を持ったBOTを作れる点
- 作成したBOTを簡単に他者に共有できる点
さて、それでは早速実践してみましょう。
今回は例として、政府が提供している求人情報提供サービスのAPI仕様書を用います。
開くだけでもう読む気がしませんね！
情報は整理されていますが、60Pにも及ぶ膨大な物量と専門用語の羅列で何から調べればよいのかもわかりません。
（全く関係ありませんが、今回良い例を探して政府の公開APIを調べたところ、少なくない数のAPIがリンク切れか不具合を起こしてましたが我が国は大丈夫なのでしょうか）
ではこの読む気にならないAPI仕様書をMy GPTsに落とし込んでいきましょう。
My GPTs の設定
My GPTsの設定画面を開き、GBT Builderと対話しながらドキュメント解説BOTを作っていきます。
それではさっそく設定していきましょう。
まずは、基盤の知識となる情報を与えます。
先ほどのPDFファイルをダウンロードし、GBT Builderとの対話コンソールから、クリップ画像をクリックしてファイルを連携します。
その際に、連携したファイルに基づいてAPIの解説をするBOTを作りたいことを明示します。
日本語で返せ
そうするとGPT BuilderがBOTの名前を考えてくれるので、それでよいかを回答します。
アイコンも考えてくれるのでそれでよいかを回答
続いて、BOTの振る舞いを設定していきます。
こういった解説系にGPTを使う場合、ハルシネーションが怖いですが、ある程度はこの振る舞いの設定で回避できそうな所管（わからないものはわからないと返してと設定できる）
最後に、口調を設定して終了
これで完了です。
My GPTsが出る前も今回やろうとしていることと似たようなことはできましたが、作成にかかる手間が以前の手法とは比較にならないほどMy GPTsの方が少ないです。
実際に会話をしてみる前に設定を確認してみましょう。
Configureボタンを押すと、設定が確認できます。
先ほど対話した内容が自動で設定されています。
また、知識の部分にAPIリファレンスのPDFが設定されていることも確認できます。
では実際に会話してみましょう。
素晴らしいですね、人間は60Pのドキュメントを読める脳をしていませんが、対話形式ならドキュメント内容を理解できる事が実感できます。
特にほしい情報がどこにあるかを全く探さなくてよいというのが体験として非常に良いです。
応用としてこんなこともできます。
最後に、作成したBOTは画面右上のSAVEボタンを押すことで保存することが可能で、その際に他者への共有もできるようになっています。
これにより、作成者以外もすぐにこのドキュメントに関し、GPTを通してアクセスすることができるようになります。
これからのドキュメンテーションの在り方
今回の記事を書くにあたって、国のAPIリファレンスを例として話してきましたが、本来はもっと身近なプログラムのAPI仕様書を例に使おうと思っていました。
しかし、昨今のリファレンスやドキュメントはWebページを用いた階層構造になっていることが多く、GPTに知識を渡しづらいという側面があったため、PDFで仕様書が連携されている求人情報提供サービスのAPI仕様書を例として出しました。
私は普段、作ったプログラムのドキュメントをDocstring + Sphinx等で自動生成したりするのですが、その場合はやはり階層構造になってしまうため、今回のような使い方をする際には向いていないドキュメント形式になってしまいそうです。
今までは人間にわかりやすいドキュメントを書くことを意識していましたが、これからはドキュメントはGPTが理解しやすいように書くことが求められるようになり、人間にかみ砕く部分はGPTがやるといった未来も十分あり得ると、この記事の執筆を通して実感しました。
激動の生成AI時代、いままでの当たり前が当たり前でなくなっていく日々が続きますが、これからも振り落とされないように何とか食らいついていければと思っています。
Discussion
素晴らしい記事をありがとうございます。
「AI(GPT)が理解しやすいドキュメント」とは、箇条書きではなく、文章形式のものである、ということでしょうか？
ドキュメントの書き方、というよりも一枚のファイルにまとまっているか？が重要だと考えています。
GPTの読解能力はかなり優秀なので、箇条書きでも文章形式でも問題なく読み込めるという肌感があります。
一方で、重要なのはどのような媒体にドキュメントが書かれているか？という部分だと考えています。
ドキュメントが複数のファイルに分かれている（例えば、このページ（https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/API_Reference.html）のように複数のhtmlでドキュメントが構成されている)場合、すべてのファイルをクローリングしてきてGPTに食わせる、といった手間がかかります。
また、My GPTsを用いる場合は登録できるドキュメント数に限りがあるため、htmlが分割されたまま登録することができず、文書を抽出して一枚のファイルにまとめなおしてから登録をする、等の手順を踏む必要があります。
複数のファイルに分け、HTML形式で必要な情報毎にページを階層化してドキュメントを提供する、というのは人間が見る分には非常にわかりやすいですが、GPTに読み込ませる事を考えるとフォーマットとして適しているとはいいづらく、下手に階層化せずにすべての内容を一枚のファイルに網羅的に記述する方が取り扱いやすいと思ったため、そういったドキュメントを「AI(GPT)が理解しやすいドキュメント」と称した形になります。
Discord のリンク有効期限切れてます。