AIによる参照元つき高品質SEO記事作成ツールの開発ロードマップ

AIによる参照元つき高品質SEO記事作成ツールの開発ロードマップ

最新の更新日
May 9, 2024 3:14 AM
記事作成日
Jan 26, 2024 7:31 AM
Category
開発・プログラミング | エンジニアリング
Target Keywords

vol.

Podcast

コーポレートサイト上の ソース・参照元つきAIによる高品質SEO記事コンテンツ作成ツールα版が完成しました🎉  の記事にて、AI(GPT4-turbo)を利用したAIによる高品質SEO記事作成ツールのα版が完成したことをご報告させていただきました。

現在はAIによる高品質SEO記事作成ツール: クローズドβ版公開を目指して鋭意開発中ですが、なかなか課題も山積みでして、本記事にて公開までの開発ロードマップを策定・公開していきたいと思います。

クローズドβ版にご興味のあるかたは ソース・参照元つきAIによるSEO記事コンテンツ作成ツール: クローズドβ版先行ご登録ページ のページから先行登録をお願い致します。

(本記事は専門的な内容を含みます)

以下、開発ロードマップ上の機能について詳細です。

ツール上でのファクトチェック・参照元との照らし合わせを容易にするためのビューアー・エディタを実装 → 実装しました!🎉

現在は[参照情報なし, すべて, 見出しと参照情報のみ]の3パターンのマークダウンファイルを出力、ユーザーにダウンロードしてもらって手元で参考情報と生成された本文を比較してもらう、というフローを想定しています。

下画像は「すべて」のバージョンを表示させた画像です。上半分は生成されたテキスト、下のモザイク箇所が根拠となった参照元(URLと該当箇所)です。

実際に生成された本文テキストと参考元データ
実際に生成された本文テキストと参考元データ

ユーザー自身にテキスト比較環境を毎回用意してもらうのは手間でしょうから、ここはツール上で簡易的なビューアー・エディタを用意する予定。

左側ペインに参照情報なしの見出しと本文、右側ペインに見出しと参考元情報という2カラム表示で、横並びに比較してもらえる表示とする予定です。

→ 簡易的なエディタになりましたが、下記のように実装できました🎉

image

AIテキスト生成時の参考文献としての著作権・robots.txtへの配慮

image

プロンプトとしてAIに参考コンテンツを送付することの著作権法上の懸念

ここはかなり悩ましいところです。モデルの学習データ、ファインチューニング用の学習データとして大量のデータをAIに読み込ませる場合、著作権法上において著作権の侵害とみなされる可能性は日本国内においてはかなり低いです。

しかし、プロンプトによって参考データを送付すること、またユーザー自身が参考データを選択する、ということは明らかに著作物の恩恵を具体的に得る行為となっているため、著作権の侵害とみなされる可能性が高いです。(グレーゾーンだが、かなりブラックに近い)

以下のような目的で学習データとして使うことは「データを享受する目的」に該当するため違法となる可能性があります。 ・学習データをそのまま出力させることを目的としたファインチューニングを行うための著作物の複製等 ・学習データの影響を強く受けた生成物が出力されるようなファインチューニングを行うための著作物の複製等 ・生成AIを用いて出力させることを目的として著作物の内容をベクトルに変換したデータベースを作成する等の著作物の複製等

引用元: AI画像生成の法的リスク(後編):著作権侵害を回避するために|

一般社団法人日本ディープラーニング協会が公開している生成AIの利用ガイドライン【条項のみ】(第1.1版, 2023年10月公開)においては、下記のように規定されています。

単に生成AIに他人の著作物を入力するだけの行為は原則として著作権侵害に該当しません。 もっとも、当該入力対象となった他人の著作物と同一・類似するAI生成物を生成する目的がある場合には、入力行為自体が著作権侵害になる可能性があります。 また、生成されたデータが入力したデータや既存のデータ(著作物)と同一・類似している場合は、当該生成物の利用が当該著作物の著作権侵害になる可能性もありますので注意してください。

引用元: 日本ディープラーニング協会 生成AIの利用ガイドライン文書内 5 データ入力に際して注意すべき事項 (1) 第三者が著作権を有しているデータ(他人が作成した文章等)

少なくとも、上記条項内における、「当該入力対象となった他人の著作物と同一・類似するAI生成物を生成する目的がある場合」に該当しないような配慮が必要でしょう。

具体的には、下記のような対策を検討しています。

  • アウトプットされた記事全体が、参考元と類似しないように配慮する
    • それぞれの参考元記事との類似度を測定するベクトル解析を実装?
    • コピペチェックの実装
  • 1つのみの参考元に基づいた生成を実施させない
    • 参考元が1つだけの場合はエラーとする

このあたりは最終的には利用いただくユーザー様によってチェックをいただく箇所ですが、ユーザー様が不利益を被らないような上記チェック機構は実装していきたいと思っています。

また、ユーザーには下記の行為をしないように遵守する制約を課す必要がありそうです。

① 著作権侵害  生成AIを利用して出力された生成物が、既存の著作物と同一・類似している場合は、当該生成物を利用(複製や配信等)する行為が著作権侵害に該当する可能性があります。  そのため、以下の留意事項を遵守してください。 ・ 特定の作者や作家の作品のみを学習させた特化型AIは利用しないでください。 ・ プロンプトに既存著作物、作家名、作品の名称を入力しないようにしてください。 ・ 特に生成物を「利用」(配信・公開等)する場合には、生成物が既存著作物に類似しないかの調査や生成物の利用が権利制限規定(著作権法30条1項や同30条の3等)に該当するかの検討を行うようにしてください。

引用元: 日本ディープラーニング協会 生成AIの利用ガイドライン文書内 6 生成物を利用するに際して注意すべき事項 (2)生成物を利用する行為が誰かの既存の権利を侵害する可能性がある

ただ、参考データとするだけで無断転載・無断引用をしているわけではない、というポイントにおいて救いがありそうです。実際、いわゆる1円ライターがやっていることも同様のことを実施しているわけで、これがAIに置き換わっただけに直ちに著作権侵害になるかどうかは微妙なラインです。

まだどのように配慮するかは検討中ですが、参考箇所の多い記事については生成テキストの最下部に参考元として自動的に参考元を出力し、リンクを設置して参考にしていることを明記する方法を検討しています。

たとえば、 Hakky Handbookというデータ・AIのナレッジポータルサイトにおいて、(おそらく類似の方法によって)複数の参考情報をソース元に生成された記事を確認することができます。

該当メディア内の 効率的なLP作成術|自動生成AIシステムの活用方法とLP作成のポイントの記事では、記事最下部に「参考文献」として生成時にコンテンツ内容を参考にしたサイトを掲示しています。

AIによる参考コンテンツの無断転載・無断引用の防止するための抽出機能の実装(コピペチェック機能)

ほかに明確な問題がありうるとすると、参考データを無断で「引用」してしまっている場合。特定の文章・一文がAIによってパラフレーズ(言い方の改変)されず、原文そのまま引用されている場合には引用元として明記が必要となります。

現在はまだこの引用元のチェックに関してはツール上で実装できていません。

なるべくツール上で検出できるように実装していきたいですが、場合によってはユーザー自身による発見・発見した場合に引用元として明記することをお願いすることになるかもしれません。

また引用元のチェックは、AIによって抽出された参照元のみならず、スクレイピングによって取得したコンテンツと比較して行っていくべきでしょう。そのほうがより厳密な引用チェックとなります。

いわゆる「コピペチェック」機能を搭載することになります。 ただし、チェック対象はあくまで参考情報として渡した記事との比較とし、参考情報以外とのコピペチェックについては当面実装はしない予定です。

ただし、「コピペチェック」自体の機能は他ツールでも実施が可能であり、コピペチェックに特化した専用ツールが既にいくつも出ています。

コピペチェック機能の実装はなかなか骨の折れそうな作業でありリリースに大幅な遅延が想定されるため、当面は上記のようなツールをユーザー側で別途組み合わせてご利用いただくことを想定しています。

スクレイピングを禁じるサイトを参考対象から除外する

またスクレイピング実施時において、スクレイピングを禁止するサイトはスクレイピングさせないように処理をすることが必要です。

この点はScrapyの挙動を制限することによって、robots.txtでスクレイピング禁止を明記しているサイトはスクレイピング先から除外する等の挙動を実装予定。

高品質SEO記事のためのAIツール: クローズドβ版公開に向けてのデプロイ作業

image

コンテナベースでの環境構築

本ツールのフロントはStreamlitで構築しており、そのままStreamlit Cloudで公開してしまうのが最も手間がかからない方法です。

しかし、ローカルとの差異でうまく環境が立ち上がらなかったり、スクレイピングがうまく実行できなかったり、またStreamlit Cloudの仕様で独自ドメインとの接続ができなかったりと多くの課題があるため、dockerコンテナベースで公開可能なサービスを用いてデプロイする予定です。

参考: Streamlit Community CloudでWebアプリを公開する際の準備事項

ログイン機能実装の観点からSupabaseを利用する予定でいますが、Fly.ioも候補としては検討余地があります。

参考: サヨナラHeroku 〜アプリケーションの知識だけで本番稼働を実現できる無料のプラットフォームを追い求めて〜

ログイン機能の実装

あまり手間をかけたくないこともあり、Supabaseによるログイン認証で実装していきたいと思っています。

Streamlitとの相性がどのくらいなのかは不安が残るところです。

ユーザーごとのトークン割当・利用トークンの計測

ここはLangChainを利用するのが簡単なのかなと検討中。

高品質SEO記事のためのAIツール: オープンβ版以降に実装していきたい機能リスト(優先度低め)

image

ソース元・根拠・参照元の引用をより正確にAIに抽出させる

現在はプロンプトによって根拠を示すことを指示し、JSONデータの出力指定によって本文と根拠とを別々で示すように処理しています。

基本的にはそれなりにうまく動作していますが、記事タイトルをそのまま表示するだけを根拠部分として表示したりと、最もウリである部分にもかかわらず正確性にはまだ不安定さが残ります。

現在のやり方だと、現実の推論の過程を表示しているのではなく、改めて「生成したテキストと参照元テキストで類似の箇所を表示している」という動作をしているように思います。 (GPTの内部動作なので厳密には分かりません)

一旦はクローズドβ版としてのデプロイを優先させていくものの、デプロイ後には優先して参照元・根拠部分の正確性向上を最優秀課題として性能向上させていく予定です。

根拠部分の正確性を改善、より高めるには下記2つの方向性があると考えています。

  • 出力指定時のプロンプトをさらに工夫する
  • RAG(Retrieval-Augmented Generation)を構築する

前者において、現在はPydanticによる型ヒントを利用し、Pydanticによるクラスをそのまま文字列変換、プロンプト内で渡すことによって出力データのコントロールを行っています。

この点は、よりGPTが読みやすいJSON形式に変換してから渡す、という点でさらに改善できそうです。

RAGを構築する方法についてはまだ私自身勉強中。ただ、RAGを活用することによって「推論の根拠」として、実際に根拠とした箇所の表示が(推論という正しい筋道で)可能になりそうです。

AIによるテキスト生成時のコスト最適化

image

本ツールの一番の特徴は「高品質であること」です。そのため、一旦は生成にかかったコストや維持コストは置いておいて、とにかく「実用・公開に耐えるだけの高品質な記事」を生成していくことを優先していきたく思います。

現時点での生成コストは、タイトル、見出し、本文含めて3,000字程度のテキスト生成およびサムネイル画像・見出し画像の生成すべて含めておよそ$5前後。1ドル=140円で換算すると、3,000文字の記事を作成するのに700円かかるという計算になります。

サーバー・サービス維持コストが別途発生するとしても、そこまでコストを意識しない実験的な生成でこの数値は「悪くない」と考えています。

クラウドソーシングで依頼する場合の最安相場である1文字=1円よりもさらに圧倒的に安く、また作成時間も10分程度と、圧倒的に記事作成コストを圧縮できることが可能だからです。 また1円ライターよりも高品質であることは保証できます。

ただ、ほとんどコスト削減のための対策は未実施なので、削減余地はあります。ただし記事品質を下げてまで、コスト削減することは行わない予定です。またコスト削減施策も優先度は低いです。

GPTへの記憶の持たせ方

テスト実装段階では、プロンプトに過去テキスト埋め込みをした方が重複説明が発生する可能性が低かったため、今のところ生成済みテキストをそのまま再度プロンプトに埋め込む方式をとっています。 もっと上手いやり方や、わざわざ埋め込みせずとも重複説明が発生しないようであれば、この部分のトークンは節約できる可能性があります。

短期・長期記憶を持たせるための方法はいくつかあります。そのままGPTを利用するやり方のなかで最も効率と効果が高そうなのは「以前に渡した内容を要約してから再度プロンプトに埋め込む」という方式のようです。

ほかには、LangChainMemory機能を活用すれば、会話の柔軟な記憶や要約処理ができるようです。

画像生成時のコスト圧縮

品質に影響を及ぼさずにコスト削減できるポイントとしては、画像生成においてDALL-E(OpenAI)ではなく別の無料生成サービスを利用すること。現在はDALL-Eが少ないテキストを自動的に変換していい感じにプロンプトとして送ってくれることが便利なためDALL-Eを利用していますが、サムネイル画像生成と各見出し画像生成で1記事あたり$1〜$1.5程度は発生しています。

試しに無料での画像生成が可能なStable Diffusionで、日本語記事タイトルを英語に翻訳しただけのタイトルを入力。想像以上に記事タイトルのイメージに近い画像が生成されました。

Stable Diffusionでサンプル記事タイトルから生成したイメージ画像
Stable Diffusionでサンプル記事タイトルから生成したイメージ画像

Stable Diffusionは明確にテイストをパラメータとして指定できるようで、無料な点のみならず使い勝手も良さそうです。 ただし、無料とはいってもDALL-Eとは異なりStable Diffusionの利用にはサーバーを用意する必要がありますが、サーバーレスによって実装できる余地もありそうです。

参考: AWS Lambdaによるサーバーレス画像⽣成AIの作成⽅法 | FUJISOFT Technical Report

β版公開より後の予定ですが、なるべく早くDALL-EからStable Diffusionへの移行を図りたいと思います。

スクレイピング実行時のパフォーマンスを改善

おもにスクレイピング時の待ち時間短縮を目指します。

image

現在はSeleniumによって、選択先の記事コンテンツのスクレイピングを実施しています。ローカルからスクレイピングを実行。

Seleniumは並列処理によるスクレイピングを実施することはできない(難しい)ため、利用ライブラリとしてScrapyへと変更し、並列処理によるスクレイピング待ち時間の短縮を目指します。