AIを業務に取り入れられるか試してみる
当ブログをご覧いただきありがとうございます。エンジニアの高橋です。
今回のブログでは、『業務にAIを取り入れられるか』といった実験的な内容です！
(人生初のハンズオン記事！！)
取り組みの背景
ユーティルでは自社のことを「中小・中堅企業を対象にデジタル化をお手伝いする会社」と定義しています。DX化を推進していく企業だからこそ、まずは自分たちの日々の業務のDX化をより一層進めていくことが必要だと捉えています。
現在ユーティルでは様々なお悩みを抱えたお客様へ、コンテンツマーケティングという形で良質な記事の発信を通じて多くのユーザー様にアプローチしています。
しかし、記事作成における事前調査や記事の構成作成で負荷が高いケースがあり、『技術的アプローチで解決できることはないか』という話が社内で出ています。
また、社内のAIに対する知見を増やす目的もあります。私たちのプロダクトではまだAIを取り入れておらず、興味ある人が個人利用の範疇でAIを使用している状況です。
もしAIを業務に導入するならば、開発コストとして費用対効果が見合うものになるのか判断指標の一つにしたいという目的もあります。
今回の課題
今回挑戦するのは『記事の構成作成の工程をAIで解決できるか』という視点です。
マーケティング部の新記事作成チームの方に質問をしながら記事作成のフローを整理するところから始めました。
ユーティルのマーケティング部では『月間100本の新記事作成』をKPIとして設定しています。
マーケティング部の活動に関してはこちらもご覧ください。
新規時作成のフローを整理する中で、いくつかの改善できそうなポイントが見えてきました。
- 作成する記事のキーワード選定
- 難易度：中
- 100記事分のキーワード選定で新記事作成チームとして10時間 / 月の作業時間
- 記事構成の作成
- 難易度：中
- 3～5時間 / 1記事、100記事分で新記事作成チームとして300～500時間 / 月の作業時間
- 入稿
- 難易度：低
- 管理画面からwysiwygエディタで入稿
- 30～40分 / 1記事、100記事分で新記事作成チームとして50～66時間 / 月の作業時間
※入稿に関しては既に改善に向けた取り組みが進んでいます。後日改めて記事としてご紹介いたします。
構成作成するスキルや知識によって記事構成を作成するのに慣れない人だと5時間/記事掛かる点で、構成作成の工程の改善が必要だと捉えました。
ユーティルの開発部には「技術を使い、課題を解決する」というスタンスが根底にあります。
今回は社内でまだ実用化されていないAIの活用という面で、技術的アプローチが出来るのではないかという取り組みの一環になります。
今回試した内容
ゴールの設定
『記事構成を生成系AIで出力できるようにする』というのが今回のゴールになります。
とはいえ、いきなり最初から「いい感じにやってくれる」わけではないので、ゴールを以下の点に設定しました。
- 記事構成レベルで使える要点整理
- 目次レベルの要約
- 参照データなどを合わせて取得
- リストなどの出力パターン対応
- 使用者にとっての難易度を下げる
- プロンプト設計の簡略化
- 自社でAIツールを作成する際の課題整理
使用技術について
今回はOpenAI社が提供しているChatGPT APIを使用しました。
以前にも、開発部の勉強会でOpenAI社のWhisperを使用したことがあり、今後Whisperについても実践的に活用できるか深掘りする可能性を考慮して選定をしました。
実際に作ってみました
画面
パターン1：コードの出力例
【出力の設定】
- 具体例を出す
- 箇条書きで
- 参照や情報源を含めて
- 「WhisperとLaravelを使って音声を文字起こししたい」
【出力結果】
【出力結果に対しての評価や感想】
取り組む段階で2021年9月(モデルによっては同年6月)までの情報を元に結果が出力されるというのは理解していました。
想定通り、Laravelのバージョンが2020年9月リリースの8で出力されています。(Laravel9は2022年2月リリース)
Laravel9からFlysystem Ver3に変更されていたり、langディレクトリの変更があったり、Laravel8とLaravel9のリリーススパンが開いたことによるバグフィックス期間などの観点で行くと情報の古さという点ではやはり課題が残る点です。
パターン2：質問に対しての要点整理
【出力の設定】
- 子供でもわかるように
- 箇条書きで
- 参照や情報源を含めて
- 「SEOにAIを活用する時に気をつける点を教えて」
【出力結果】
【出力結果に対しての評価や感想】
そもそもの題材が子供でも難しい点は置いておき、出力内容的には網羅性、参照文献などの提示を含みつつ箇条書きでの出力など、プロンプトに沿った出力にはなっている点には満足しています。
実際に開発してみて
改良点など
今回の開発では非エンジニアの利用を想定しているため、プロンプトをノーコード的に設定できるようにしました。
今回のものを応用すれば、
- DBにaskingsテーブルなどを作り、キーワードと出力してほしい形式などを保存
- バッチ処理でAskテーブルに保存した質問内容をChatGPTへ送信
- レスポンスをresponsesテーブルに保存
上記のようなプロセスで、構成の素案作成をある程度は自動化が可能かなと気付きを得ることが出来ました。
今後の課題
とはいえ、まだまだ今回のハンズオンでは対応できなかった課題は山積みです。
- チューニングなどの知見の不足
- 出力データの品質担保
- ユーザーへの誤った情報発信の防止策
- 検索汚染にならないように独自性と網羅性の追求
- 最新データや、より専門性が高いデータの活用
- ツールとして内製化する場合の保守コスト(人員、動作環境、etc…)
今回の開発内容をいきなり実践投入というわけにはいかなそうというのが個人的な見解です。
とはいえ、開発部内で今回の内容を共有して、色々な角度から業務改善へアプローチする視点は必要だなと再認識できました。
まとめ
今回のブログの発端が、開発部内で定期的にしている開発ブログミーティングでした。
「業務改善の糸口になるかもしれないのでこれ(今回の開発)やってみたい」と言ったことで挑戦するチャンスもらえて楽しめました！
- 業務改善へのアプローチ視点を持つ
- 開発内の色んなタスクに優先順位をつけながら物事に取り組む
- 費用対効果やメリット / デメリットなどを考えながら開発する
こういった視点を持っている人だと、色々チャレンジできる環境と個人的には感じています。
人生の中で働いている時間の割合は大きいからこそ、仕事自体に目的など持って楽しめる方はぜひお話だけでもできれば幸いです。