CLOSE

OpenAI APIを用いた技術ブログ記事作成アプリを開発した話(全1記事)

「テックブログを書くハードルを少しでも下げたい」 OpenAIのAPIを使った「技術記事作成アプリ」の構想と実装

毎回1つのテーマに絞り、テーマに対してのLTを行うTechDLT。「ChatGPT」をテーマにした「ChatGPTについてLT! TechDLT Vol.10」に登壇したのは、ほりゆう氏。OpenAI APIを用いた、技術ブログ記事作成アプリの開発について発表しました。

登壇者の自己紹介

ほりゆう氏(以下、ほりゆう):みなさま、本日はお時間をいただき、ありがとうございます。主催者のみなさま、参加者のみなさま、どうぞよろしくお願いします。「OpenAI APIを用いた技術ブログ記事作成アプリを開発した話」を紹介いたします。

まずは自己紹介からさせてください。私はエンジニアをしている堀越優希、ほりゆうと申します。もともと文系で、高等学校の国語科の教員をしていました。現在27歳です。エンジニアになったのは2020年の7月なので、今3年目くらいです。

ふだんはRailsやReactで開発をしています。マジックが趣味です。「なかよし」という言葉が好きなので、今日はみなさんと仲良く発表できたらなと思っています。どうぞ、お手柔らかにお願いいたします。

(スライドを示して)今日の目次はこんな感じです。みなさんご存じかもしれませんが、簡単に「OpenAIのAPIとは」を話して、どんなものを作ったのか、どう作ったのかを話して、最後にデモ動作を見せて、今後の改善をお話ししたいと思います。それでは10分間くらい、よろしくお願いします。

チャットのAPIと音声をテキストに変換するAPIを使って開発

まず「OpenAIのAPIとは」について簡単に説明します。OpenAIのAPIとは、アプリ開発にも用いることができるOpenAIのAPIです。みなさんChatGPTを使われていると思いますが、そのAPIです。画像処理や音声認識など、実はいろいろなAPIが提供されています。

私も今回の開発で初めて知ったものがいくつかあったんですが、(スライドを示して)このリンクのところにこういう画面が出て、APIがたくさん紹介されています。ちょっと見ていきましょう。

APIの一覧には、チャットや文章の補完があります。音声をテキストに変えるAPIなども提供されています。今回は、テックブログの記事作成を補助するアプリとして、チャットのAPIと、もう1つ「Speech to text」という音声をテキストに変換するAPIの両方を使って、開発してみました。

テックブログの記事作成のハードルを下げるアプリを作ってみた

それでは「何を作ったのか」です。作成したのは、テックブログ、技術を中心に書いたブログの記事の作成ハードルを下げるアプリです。テックブログは書き出しがすごく大変なんですが、その記事の作成のハードルを少しでも下げられたらいいなと思って作りました。

(スライドを示して)具体的にはこういった感じで、外部での発表とその資料を基に、テックブログの記事の作成を簡単にしてくれるアプリケーションを作りました。これによって会社のテックブログの投稿を増やしていきたいな、という気持ちです。こちらにもリンクがあるので、よければ後で見てみてください。

ちなみに、このアプリをどういうタイミングで作ったかというと、弊社には「お産合宿」というイベントがあります。部署や職種を超えたメンバーでチームを組んで開発する、開発合宿みたいなものです。

今回は、私ともう1名のエンジニアと広報の1名で参戦しました。2日間でバーッと急いでワイワイやりながら開発する楽しいイベントで生まれたアプリです。

技術ブログ記事作成アプリの構想

では、どう作ったのかを見ていきましょう。大きく3段階に分かれています。広報の方が特徴の洗い出し、エンジニア2人が登壇の音声活用と資料活用をやりました。

まずテックブログを書きやすくするために、Chat APIを使って記事の概要みたいなものを作ってもらうためにどうすればいいかを考え、弊社のテックブログの特徴みたいなものを洗い出すところから始めました。こちらは広報の方がやってくれました。

もう1つ、登壇者の音声を基に記事を作っていくので、その音声を文字に変換して、さらに要約するという手順が必要です。こちらもOpenAIの「Speech to text」というAPIを使って文字にして、Chat APIに投げて要約するという方針にしました。

もう1つが、登壇に使う資料を活用することです。おそらくテックブログの概要は音声だけでも作れますが、登壇資料も併せて文字にして要約して音声と合わせたら、より精度を高い概要ができるんじゃないかと考えました。

文字だと少しわかりにくいのですが、つまり、こういうことです。発表音声と発表スライドを用意する。音声をテキストにする。その要約を作る。合体させる。ブログになる。こんな感じのことができたらいいなと思って、開発をスタートしました。

開発する中でぶつかった2つの壁

後半です。あと5分くらいです。まず、ぶつかった壁についてお話しします。

実際に開発していくと、2つの大変な壁がありました。1つは「プロンプトの作成」、もう1つは「長いテキストの対応」です。

プロンプトはChat APIにリクエストする時の文章ですが、テックブログの特徴どおりに書いていってリクエストするのが非常に難しかったです。

具体的に弊社のブログの特徴を洗い出した結果、イントロがあって、今回紹介する技術とはこういう内容で、具体的にはこうでした。こういう結果が生まれました。まとめです。みたいな流れだったのですが、この形式で短い概要を作るのが非常に難しかったです。

もう1つは、長いテキストへの対応です。ドキュメントを読んでみると、合計4,096トークンしか送ることができません。トークンが何かについては、下のリンクに参考を貼っておきました。

文字数とは少し違って、要はリクエストする時の総量みたいな感じです。すごく長いテキストを送って、それを全部要約することはできなかったので、これをどうしようかなと考えました。

テキスト分割→それぞれを要約→集合体で要約

今回のLTでは、この「長いテキストへの対応」を詳しく説明したいと思います。いろいろな対応の仕方があると思いますが、私たちが行った長いテキストへの対応は(スライドを示して)こんな感じです。うまくいかなかったやり方を先にお伝えします。

「今から文章を2つ送るから2つ目の文章が来てから要約してください」というリクエストは、うまくいきませんでした。前の文章と次の文章を合わせて要約してくださいというのもダメでした。

複数のリクエストを送って2つをなんとかすることがあまりうまくできなかったので、今回はテキストを分割させて、それぞれを要約して、その集合体をもう1回要約させました。

(スライドを示して)その時のプロンプトがこちらです。少し読み上げますね。講演の音声を文字起こししたものです。「あなたは情報の整理ができます。ただし、条件を遵守してください。箇条書き、情報の抜け漏れがない、読み返しやすいようにする、項目と項目のつながりをわかりやすくする」と。

こちらを送ると、ある程度長い文章が分割されて、箇条書きで戻ってきます。内容が壊れることがあまりなかったので、「このかたちで音声の長い文章を箇条書きの短いまとまりにしよう」というリクエストを投げました。

シーケンス図を紹介

(スライドを示して)こちらの資料は、後でリンクを共有しますが、シーケンス図でいうとこんな感じです。音声ファイルを投げて、文字起こしが返ってきて、それをブロックに分割して、全部のブロックに対して短い箇条書きの要約を作る、そんなことをしていました。

文章にすると少し長いのですが、簡単に説明します。まずは文字起こしデータを作って、文字起こしデータから発表の要約を作ります。でも(要約は)長いので箇条書きにまとめてもらいます。

その後は、PDFの発表資料を要約してもらいます。PDFの発表資料と箇条書きになった文章をまとめて、Chat APIに投げて、テックブログの概要にしてもらうというかたちです。

統合要約を記事の概要にする時のプロンプト

(スライドを示して)2つの壁のうちの1つは、いろいろなやりとりがあったんですが、それを解決したのがこちらのプロンプトです。最終的にこのプロンプトで送るといい感じに書いてくれることがわかったので、こちらになりました。

「以下に示す情報を基に、以下の構成で、字数指定して、技術ブログの記事を完結させてください。構成はこんな感じだよ」と送って、詳細、結果、まとめ、という感じになっています。

特徴としては、コードを書いている方はご存じかもしれませんが、引数を取っています。アプリケーションを使うユーザーが、これは何の登壇なのか、何のイベントなのか、例えばAWSや技術内容と入力すると、それがここに入って基礎知識が補完されるという内容になっています。

わかりにくいと思うので、デモを持ってきました。そちらをご覧いただこうと思います。Gif動画はこんな感じです。リクエストの時間は尺の都合上カットしていますが、音声ファイルをアップして、PDFファイルをアップして、何についての講演かを入力して、ポチッと押すと、このようにテックブログの要約ができるというアプリケーションです。

サービス名における誤字を改善したい

最後に、今後の改善策です。出力されたブログの概要はだいたいいい感じの内容ですが、細かく見ていくと、文字の間違いがけっこうありました。弊社のサービスや、自社で開発しているアプリケーションの名前によく誤字が見られました。

今後の改善策としては、私もまだあまり調べられていませんが、LangChainという技術を活用すると事前知識に基づいた回答ができるようなので、これを導入したいと思っています。

事前に弊社のサービス名や弊社のテックブログを読ませた上でリクエストをすると、より精度の高い回答をしてくれるんじゃないかなと思っています。以上です。ご静聴ありがとうございました。

15分くらいの発表であれば問題なく読み込める

司会者:ありがとうございました。めちゃくちゃ実用的だな、僕らのLT会にこれがあるとイベントレポートすぐに書けるなと思って、羨ましい目で見ていました。

ほりゆう:初めてお邪魔させてもらったので、よかったです。

司会者:いえいえ、ありがとうございます。ちなみにこの仕組みって、もうすでに導入して稼働しているんですか?

ほりゆう:弊社では、いくつか「お産合宿」で作ったアプリケーションが稼働しているのですが、こちらはまだ本番で動かしていないので、ちょっと早めにやろうかなと思っています。

司会者:そうなんだ。稼働させる上での障壁がまだまだありそうですか?

ほりゆう:そうですね。音声の録画の容量みたいなものはやはりAPIで決まっているので、あまり長い音声だと対応できないとか。あとは、2日間で急いで開発したので、ユーザビリティが低くなっていて、そこをちょっと直したいですね。

司会者:聞き逃してしまったかもしれませんが、文字起こしってどうやっているんでしたっけ? 

ほりゆう:大丈夫です。文字起こしは、OpenAIに「Speech to text」というAPIを利用しています。

司会者:それを知らなかったです。

ほりゆう:(スライドを示して)こちらですね。けっこう簡単に使えるので、みなさんも使っていただけるとうれしいです。

司会者:チャットしか知らなかったので、APIの一覧がある。

ほりゆう:そうです。

司会者:一覧があることは初めて知りましたね。ありがとうございます。他に、登壇予定のお二方からもなにか、ご質問はありますか? 

さくしん@flutter.salon氏(以下、さくしん@flutter.salon):先ほど、たぶんフリスビーの音声ファイルの最大が25MBと出ていましたが、長さとか、そのあたりの制限はあるんですか?

ほりゆう:ありがとうございます。長さには容量の制限がありましたが、試した限りそんなには。登壇するレベル、例えば15分くらいの発表であれば問題なく読み込むことができています。

1つ思い出したんですが、読み込ませる前処理としてノイズを取って、言葉を聞こえやすくすると精度が上がったので、そういうのをやってみてもいいかなと思いました。長すぎなければ、まとめてくれると思います。

さくしん@flutter.salon:はい。

司会者:ありがとうございます。

ほりゆう:ありがとうございます。

司会者:あらためて、ほりゆうさん、ありがとうございました。

ほりゆう:みなさま、お時間をいただき、ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 1年足らずでエンジニアの生産性が10%改善した、AIツールの全社導入 27年間右肩上がりのサイバーエージェントが成長し続ける秘訣

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!