コーポレートサイト上の ソース・参照元つきAIによる高品質SEO記事コンテンツ作成ツールα版が完成しました🎉 の記事にて、AI（GPT4-turbo）を利用したAIによる高品質SEO記事作成ツールのα版が完成したことをご報告させていただきました。
現在はAIによる高品質SEO記事作成ツール: クローズドβ版公開を目指して鋭意開発中ですが、なかなか課題も山積みでして、本記事にて公開までの開発ロードマップを策定・公開していきたいと思います。
クローズドβ版にご興味のあるかたは ソース・参照元つきAIによるSEO記事コンテンツ作成ツール: クローズドβ版先行ご登録ページ のページから先行登録をお願い致します。
（本記事は専門的な内容を含みます）
目次:
- ツール上でのファクトチェック・参照元との照らし合わせを容易にするためのビューアー・エディタを実装 → 実装しました！🎉
- AIテキスト生成時の参考文献としての著作権・robots.txtへの配慮
- プロンプトとしてAIに参考コンテンツを送付することの著作権法上の懸念
- AIによる参考コンテンツの無断転載・無断引用の防止するための抽出機能の実装（コピペチェック機能）
- スクレイピングを禁じるサイトを参考対象から除外する
- 高品質SEO記事のためのAIツール: クローズドβ版公開に向けてのデプロイ作業
- コンテナベースでの環境構築
- ログイン機能の実装
- ユーザーごとのトークン割当・利用トークンの計測
- 高品質SEO記事のためのAIツール: オープンβ版以降に実装していきたい機能リスト（優先度低め）
- ソース元・根拠・参照元の引用をより正確にAIに抽出させる
- AIによるテキスト生成時のコスト最適化
- GPTへの記憶の持たせ方
- 画像生成時のコスト圧縮
- スクレイピング実行時のパフォーマンスを改善
- AIによるテキスト生成時のパフォーマンスを改善
- （参考）1記事を生成するのに必要な待ち時間
- スクレイピングおよびアウトライン生成以降の一括生成・キュー機能（非同期処理）
- カスタムプロンプトや生成したテキスト・サムネイルなどを保存するデータ保存機能の実装
- テンプレートプロンプト
- プロンプトインジェクション対策（セキュリティ）
- フロントとバックエンドの分離、サーバレス化
- 見出しの新規追加・削除・ドラッグ&ドロップによる並び替え → 削除のみ実装しました🎉
- キーワードの一括置換機能で、表記ゆれ・別表現として新規記事を制作するケースに対応
- 生成されたテキストの品質保証（予期せぬアウトプットが出力された場合の検知と再生成）
- GPT以外のさまざまなAIモデルに対応
- オープンβ版・本製品公開以降の機能を妄想
- 生成されたコンテンツにおけるAIによる二重ファクトチェック
- 自社メディアのコンテンツをベースに、さらに競合記事などを参考文献として渡してSEO記事を作成
- YouTube, Podcast, PDFなど、さまざまなデータソースに対応
- 自社データやWebにない情報をアップロードし、蓄積・保持できる「ベースナレッジ」機能を追加
- さまざまな種類のコンテンツ・書きぶりの変更に対応
- ツールへのほかユーザー招待・権限管理
- バージョン管理
- WordPressへの自動入稿
- AIによる高品質SEO記事作成ツール: クローズドβ版の先行登録を募集しています！
以下、開発ロードマップ上の機能について詳細です。
ツール上でのファクトチェック・参照元との照らし合わせを容易にするためのビューアー・エディタを実装 → 実装しました！🎉
現在は[参照情報なし, すべて, 見出しと参照情報のみ]の3パターンのマークダウンファイルを出力、ユーザーにダウンロードしてもらって手元で参考情報と生成された本文を比較してもらう、というフローを想定しています。
下画像は「すべて」のバージョンを表示させた画像です。上半分は生成されたテキスト、下のモザイク箇所が根拠となった参照元（URLと該当箇所）です。
ユーザー自身にテキスト比較環境を毎回用意してもらうのは手間でしょうから、ここはツール上で簡易的なビューアー・エディタを用意する予定。
左側ペインに参照情報なしの見出しと本文、右側ペインに見出しと参考元情報という2カラム表示で、横並びに比較してもらえる表示とする予定です。
→ 簡易的なエディタになりましたが、下記のように実装できました🎉
AIテキスト生成時の参考文献としての著作権・robots.txtへの配慮
プロンプトとして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ツール: クローズドβ版公開に向けてのデプロイ作業
コンテナベースでの環境構築
本ツールのフロントはStreamlitで構築しており、そのままStreamlit Cloudで公開してしまうのが最も手間がかからない方法です。
しかし、ローカルとの差異でうまく環境が立ち上がらなかったり、スクレイピングがうまく実行できなかったり、またStreamlit Cloudの仕様で独自ドメインとの接続ができなかったりと多くの課題があるため、dockerコンテナベースで公開可能なサービスを用いてデプロイする予定です。
参考: Streamlit Community CloudでWebアプリを公開する際の準備事項
ログイン機能実装の観点からSupabaseを利用する予定でいますが、Fly.ioも候補としては検討余地があります。
参考: サヨナラHeroku 〜アプリケーションの知識だけで本番稼働を実現できる無料のプラットフォームを追い求めて〜
ログイン機能の実装
あまり手間をかけたくないこともあり、Supabaseによるログイン認証で実装していきたいと思っています。
Streamlitとの相性がどのくらいなのかは不安が残るところです。
ユーザーごとのトークン割当・利用トークンの計測
ここはLangChainを利用するのが簡単なのかなと検討中。
高品質SEO記事のためのAIツール: オープンβ版以降に実装していきたい機能リスト（優先度低め）
ソース元・根拠・参照元の引用をより正確にAIに抽出させる
現在はプロンプトによって根拠を示すことを指示し、JSONデータの出力指定によって本文と根拠とを別々で示すように処理しています。
基本的にはそれなりにうまく動作していますが、記事タイトルをそのまま表示するだけを根拠部分として表示したりと、最もウリである部分にもかかわらず正確性にはまだ不安定さが残ります。
現在のやり方だと、現実の推論の過程を表示しているのではなく、改めて「生成したテキストと参照元テキストで類似の箇所を表示している」という動作をしているように思います。 （GPTの内部動作なので厳密には分かりません）
一旦はクローズドβ版としてのデプロイを優先させていくものの、デプロイ後には優先して参照元・根拠部分の正確性向上を最優秀課題として性能向上させていく予定です。
根拠部分の正確性を改善、より高めるには下記2つの方向性があると考えています。
- 出力指定時のプロンプトをさらに工夫する
- RAG（Retrieval-Augmented Generation）を構築する
前者において、現在はPydanticによる型ヒントを利用し、Pydanticによるクラスをそのまま文字列変換、プロンプト内で渡すことによって出力データのコントロールを行っています。
この点は、よりGPTが読みやすいJSON形式に変換してから渡す、という点でさらに改善できそうです。
RAGを構築する方法についてはまだ私自身勉強中。ただ、RAGを活用することによって「推論の根拠」として、実際に根拠とした箇所の表示が（推論という正しい筋道で）可能になりそうです。
gpt4-turboモデルが公開される前にプロンプト量の圧縮の目的も兼ねて LlamaIndexは触っていましたが、まだまだ使いこなすには程遠いレベルなので精進していきたいです。
本番環境での運用を見据えて、現在はLangChainでの実装を想定しています。
AIによるテキスト生成時のコスト最適化
本ツールの一番の特徴は「高品質であること」です。そのため、一旦は生成にかかったコストや維持コストは置いておいて、とにかく「実用・公開に耐えるだけの高品質な記事」を生成していくことを優先していきたく思います。
現時点での生成コストは、タイトル、見出し、本文含めて3,000字程度のテキスト生成およびサムネイル画像・見出し画像の生成すべて含めておよそ$5前後。1ドル=140円で換算すると、3,000文字の記事を作成するのに700円かかるという計算になります。
サーバー・サービス維持コストが別途発生するとしても、そこまでコストを意識しない実験的な生成でこの数値は「悪くない」と考えています。
クラウドソーシングで依頼する場合の最安相場である1文字=1円よりもさらに圧倒的に安く、また作成時間も10分程度と、圧倒的に記事作成コストを圧縮できることが可能だからです。 また1円ライターよりも高品質であることは保証できます。
ただ、ほとんどコスト削減のための対策は未実施なので、削減余地はあります。ただし記事品質を下げてまで、コスト削減することは行わない予定です。またコスト削減施策も優先度は低いです。
また、現在ではChat Completions APIを使っていながら、生成済みテキストを再度プロンプトに埋め込んでから続きを作成する、というフローを取っています。Chat Completions APIはそもそも過去のやりとりを記憶しているので、生成済みテキストをわざわざ再度プロンプトに埋め込む必要はないかもしれません。
Chat Completions APIにおいては、Webブラウザ版ChatGPTとは異なりスレッドの記憶機能はないようです。（現状、Chat Completions APIはステートレスなAPI）
GPTへの記憶の持たせ方
テスト実装段階では、プロンプトに過去テキスト埋め込みをした方が重複説明が発生する可能性が低かったため、今のところ生成済みテキストをそのまま再度プロンプトに埋め込む方式をとっています。 もっと上手いやり方や、わざわざ埋め込みせずとも重複説明が発生しないようであれば、この部分のトークンは節約できる可能性があります。
短期・長期記憶を持たせるための方法はいくつかあります。そのままGPTを利用するやり方のなかで最も効率と効果が高そうなのは「以前に渡した内容を要約してから再度プロンプトに埋め込む」という方式のようです。
画像生成時のコスト圧縮
品質に影響を及ぼさずにコスト削減できるポイントとしては、画像生成においてDALL-E(OpenAI)ではなく別の無料生成サービスを利用すること。現在はDALL-Eが少ないテキストを自動的に変換していい感じにプロンプトとして送ってくれることが便利なためDALL-Eを利用していますが、サムネイル画像生成と各見出し画像生成で1記事あたり$1〜$1.5程度は発生しています。
試しに無料での画像生成が可能なStable Diffusionで、日本語記事タイトルを英語に翻訳しただけのタイトルを入力。想像以上に記事タイトルのイメージに近い画像が生成されました。
Stable Diffusionは明確にテイストをパラメータとして指定できるようで、無料な点のみならず使い勝手も良さそうです。 ただし、無料とはいってもDALL-Eとは異なりStable Diffusionの利用にはサーバーを用意する必要がありますが、サーバーレスによって実装できる余地もありそうです。
参考: AWS Lambdaによるサーバーレス画像⽣成AIの作成⽅法 | FUJISOFT Technical Report
β版公開より後の予定ですが、なるべく早くDALL-EからStable Diffusionへの移行を図りたいと思います。
スクレイピング実行時のパフォーマンスを改善
おもにスクレイピング時の待ち時間短縮を目指します。
現在はSeleniumによって、選択先の記事コンテンツのスクレイピングを実施しています。ローカルからスクレイピングを実行。
Seleniumは並列処理によるスクレイピングを実施することはできない（難しい）ため、利用ライブラリとしてScrapyへと変更し、並列処理によるスクレイピング待ち時間の短縮を目指します。
ただし、現在の対象5記事・ローカルから実行の場合においても、スクレイピング対象先のサイトや通信環境次第ではありますが、高速WiFi下でおよそ実行時間が1分30秒という結果になっています。
4G回線テザリングによる5記事取得の場合、3分50秒程度かかってしまいます。通信環境による影響をなくすため、クラウドでのスクレイピングを実装したいところです。
オープンβ版公開時には負荷分散やIPアドレスのランダム化等、さまざまなスクレイピングのための仕組みも必要となることが想像されますが、クローズドβ版においては一旦このままSeleniumでの実装としていく予定です。
AIによるテキスト生成時のパフォーマンスを改善
LangChainなどのエージェントを利用すれば、GPTによるテキスト生成時にも並列処理することが可能なようです。
ただし、途中までに生成したテキストを読み込まない状態だと、同一の説明を何度も繰り返すようなテキストが生成されてしまいます。（それまでに生成した文脈を考慮しないため）
そのため、テキスト生成を並列化するかどうかは検討中。ここは速度よりも記事品質を優先させていきます。
（参考）1記事を生成するのに必要な待ち時間
クローラやGPTなどの待ち時間は、およそ下記になります。
- 5記事の記事をスクレイピングによって取得（高速WiFi環境下）: 1分30秒
- アウトラインの生成（1度のリトライを含む場合）: 1分20秒
- 本文の生成（見出し7つ分、一括生成の場合。およそ2,000字〜3,000字）: 7分30秒
- サムネイル画像の生成: 15秒
- h2見出しの箸休め画像の一括生成（h2見出し4つ分、再生成を含まず）: 40秒
- h2見出しの箸休め画像のDL用Zipファイル生成: 45秒
いまのところ、待ち時間の合計はおよそ12分となっています。 本当は10分以内まで縮めたいところですが、今は生成スピードよりも生成される記事の品質にこだわって開発していきたいです。
スクレイピングおよびアウトライン生成以降の一括生成・キュー機能（非同期処理）
実際に自身で運用してみて思うのですが、生成されたアウトライン自体をすべてボツにする機会は少ないです。
アウトラインを一部編集したり、生成された本文テキストをみて見出しやタイトルを変更するなど、アウトラインと本文を行ったり来たりしながら調整していきます。
そのため、スクレイピング以降のすべての処理はキューリストとして、バックグラウンドで実行させるのが良さそうと感じています。
ユーザーとしては、キーワードの入力と参考対象記事を選択するだけ。その間は他のキーワードの入力・参考対象の選択が可能。 一定時間が経過するとすべての生成結果が確認できるようになるという仕組みです。
キーワードと参考記事選択後、どこまで一括で生成させるか？も選択できるように実装。アウトラインまで、本文まで、本文と画像までの3パターンで実装予定。
Streamlit上の実行ではキューリストの実装は無理そうなので、FastAPIなどによって表記処理で生成を行うAPIを作成し、バックグラウンドとして処理をさせる仕組みが必要そうです。
キューリストがすべて完了したらメールで通知する、などの実装も必要になるかもしれません。
カスタムプロンプトや生成したテキスト・サムネイルなどを保存するデータ保存機能の実装
現時点では、本AIツールはデータベースを実装していません。生成データ等はすべてブラウザのキャッシュ上に保存させる方法をとっています。
そのため、タブを閉じるとすべてのデータが消えてしまいます😱
しかし、データ保存の機能については当面は優先度は低いものと考えており、すべての生成データを保存するとなると、保存データ量も膨大なものになることが想定されます。
設計も含めて、一旦はデータベースの機能は最低限にとどめていきたく思います。
公開時にはログイン機能を実装することもあり、Supabaseなどを用いて何らかのデータベースを利用する予定ではありますが、データベースにどこまでの情報を保存させるかは検討中の段階です。
テンプレートプロンプト
カスタムプロンプトはユーザーが自由に追加で定義するプロンプトですが、このカスタムプロンプトを一からユーザーが記述するのではなく、システム上であらかじめいくつかのテンプレートを用意しておく機能です。
たとえば、「架空のユーザーにインタビューしているように書く」や「絵文字や！マークを多用して、若年層向けのテキストで書く」など。
プロンプトインジェクション対策（セキュリティ）
悪意のあるユーザーによって、プロンプトインジェクションをすることで指示しているプロンプトが引っこ抜かれる、盗まれるということは有りえます。
ただ、そもそも本ツールの優位性はプロンプトそれ自体にはないと考えています。エンジニアの方であれば、本ツールと同様のことを実現することは比較的容易です。
しかし、世の中の多くの方は非エンジニアであり、またユーザーは「いかに使いやすいか」「いかに面倒を省いてくれるか」という点に価値を感じるものと思っています。
したがって本ツールの優位性はプロンプトそれ自体ではなく、「高品質な記事作成のための一連のプロセスを半自動化してくれる、ツールを利用したプロセスそのもの」にあります。
そのため、プロンプトインジェクション対策は多少は実施予定のもののそこまで力を注ぐつもりはなく、利用規約で該当の行為を禁止する、必要に応じてログチェックを行う等で対策をしていくつもりです。
フロントとバックエンドの分離、サーバレス化
現在はStreamlitで構築しており、当面はこのままデプロイする予定です。
ただユーザー数が増えてきたり、よりインタラクティブなフロントでの動作を可能にしたいという場合には、フロントとバックエンドとの分離、ひいてはサーバレス化での運用も視野に入れていきたいと思います。
見出しの新規追加・削除・ドラッグ&ドロップによる並び替え → 削除のみ実装しました🎉
見出しについては編集、hレベルの変更については対応しているものの、新しく見出しを追加することには対応していません。
アウトラインを確認していると、「この箇所にもう1つ見出しが欲しいな…」と思い追加したいこともしばしば。また反対に「この見出しは重複になっているし、いらないな」と思うことも。
見出し新規追加・削除機能はまさしくAIとの協業ライティングを実現するのに必要な機能とは感じていますが、まずはサービス公開を優先して進めていきたいこともあり、一旦はこのままクローズドβ版までは進めていく予定です。
また、見出しの順番並び替えをドラッグ&ドロップで行うことは現在できません。編集はできるものの、テキストボックスのみによる編集となります。これはStreamlitで構築している関係で、Streamlitではそのようなインタラクティブな操作（並び替え）をもたらす機能がないためです。
そのため、見出し新規追加・削除・並び替えの機能を実装するためにはStreamlitから脱却、フロントを改めて作り直すことが必要になりそうです。
ユーザー体験としても重要そうなので実装したいところなのですが、フロントリプレイスは工数が大変大きくなるため、泣く泣く公開と他機能を優先していきたいと思います…！ しばらくはこのまま公開へと進めてまいります。
2024/02/23追記: 見出し削除機能のみ、追加実装しました！見出しの新規追加も実装できそうです。ドラッグ&ドロップによる並び替えは仕様上難しそうなので、しばらく実装する予定はありません。
キーワードの一括置換機能で、表記ゆれ・別表現として新規記事を制作するケースに対応
検索キーワードをみていると、同じ意味のものを異なるキーワードで検索されたり、表記ゆれの形で検索されるケースが多々あります。
1つの記事で表記ゆれ対応する形でも良いのですが、キーワードが長くタイトルテキスト内の占有率が高く対応しづらかったり、クリック率改善のため別記事として作成するケースもしばしば。
このとき、本ツールで競合記事を参考にした場合、キーワードが参考記事のキーワードのまま生成されてしまいます。
現行でもタイトル・見出し編集画面ですべてのキーワードを手作業で編集することで対応が可能ですが、このような無駄な作業はなくしていきたいです。
そこで、表記ゆれ・別表現キーワード用の記事として制作しなおすための、タイトル・見出し編集画面における「キーワード一括置換機能」を将来的に実装していく予定です。
また、参考記事をGPTに提出し本文を生成する際にも、「〇〇の代わりに〇〇のキーワードを使って記事を書いてください」と指示できるよう、本文生成時での置換キーワード指定にも対応予定です。
生成されたテキストの品質保証（予期せぬアウトプットが出力された場合の検知と再生成）
ごくまれにですが、生成されたテキストがあらかじめセットされている指示プロンプトをそのまま吐き出してしまう見出しパートが生成される場合があります。
生成されたテキストに指示プロンプトが含まれているか？のチェック機構と、含まれていた場合の処理（再生成する、あるいはエラーで一旦停止させる）を実装することが必要になりそうです。
GPT以外のさまざまなAIモデルに対応
GPT以外にも、特に文章生成モデルに関してはClaude3といったGPTよりも（おそらく）高性能なモデルが出てきました。
ユーザーの選択によって、GPTかClaudeかなどモデルを選べるようにしていきたいと思います。
オープンβ版・本製品公開以降の機能を妄想
以降はオープンβ版、または本製品版を公開できて以降に「こんなことが出来るようになると良いな」という妄想です。
生成されたコンテンツにおけるAIによる二重ファクトチェック
本製品の一番のキモは、「ハルシネーションの軽減と発見容易」です。
現時点でも、たとえばニュース記事の生成アプリケーション等では、さまざまにこのハルシネーションへの対策がなされています。
本製品のように追加情報を学習させる（Fewshot-Learning）させることももちろん有効な方法ですが、その他にもさまざまな手法があります。
その1つが、「AIによる生成結果を再度AIに評価させる」という手法。評価用の別モデルに基づくAIを用意し、その評価用AIによって再度評価を実施するというものです。
この点は現在まさに研究が進められている分野。たとえばAmazon ScienceではRefCheckerというOSSでの評価用フレームワークが紹介されています。
また、2024年4月3日にはKnowHaluという2段階の評価モデルに基づくフレームワークによって、ハルシネーションの発見率が大きく高まった、というイリノイ大学による論文がarXivに提出されています。
また、日本語テキストにおけるハルシネーション検出は下記のレポートが面白そうだと感じました。
当製品でも将来的には二重ファクトチェックを実装していきたいと考えています。
自社メディアのコンテンツをベースに、さらに競合記事などを参考文献として渡してSEO記事を作成
現在はあくまでデフォルトのGPTに対して、選択した記事を参考文献として渡す形になっており、参考文献以外の部分についてはGPTが学習した一般的なデータをもとにしています。
参考文献以外の部分においてもGPTの基礎的なナレッジを強化させるため、たとえば自社メディアで既に公開している記事を活用する方法があります。
活用方法として考えられるのは、下記の2通り。
- RAG（Retrieval-Augmented Generation）を構築し、参考文献と一緒に渡すようにする
- GPTをカスタマイズしてファインチューニングする
実装の用意さや現実的な運用を考慮すると、前者のRAGを構築する方法のほうがベターでしょう。
RAGを構築していく場合はRAG構築プランという別途のプランにする予定です。その場合にユーザーが自動的にRAGを構築・運用できるようなシステムとするか、受託のような形で個別にカスタマイズ対応するかは検討しています。（おそらく個別対応にする予定）
YouTube, Podcast, PDFなど、さまざまなデータソースに対応
今のところ、参照情報として渡す情報はGoogle検索ベースでのテキスト情報に限定しています。
将来的には、キーワード検索にYouTubeを含めたり、Podcastも含めたりようになると面白いのではと。 それぞれ音声を自動文字起こし・要約してソース元として渡せるようにしてみたいと考えています。
また、ユーザーがPDFやDocs形式でのファイルをアップロードすることも可能にできると面白いなと。 この場合、機密性にも考慮してAzureによるRAGの実装を検討しています。
自社データやWebにない情報をアップロードし、蓄積・保持できる「ベースナレッジ」機能を追加
上記のデータソースでは、個別の記事を書かせる際に都度ファイルを指定・アップロードしていただくことを想定していますが、別途、基礎となる情報源のデータ群となるような「ベースナレッジ」機能を追加していきたいと考えています。
たとえば、一冊の本をPDFとしてアップロードしたあと、ベースナレッジとして保存。以降はこのベースナレッジを基礎として、さまざまなコンテンツを書くようにしていきたいです。
ベースナレッジの情報も、都度参照情報として出力させるようにしていく予定です。
さまざまな種類のコンテンツ・書きぶりの変更に対応
コンテンツには様々な書きぶり・コンテンツ種類があります。同じ内容でも、伝え方によって独自コンテンツとしていくことが可能です。
たとえば、下記のようなコンテンツ種類を生成できるようにしていきたいと思います。
- インタビュー形式
- 複数人によるパネルディスカッションの書き起こし形式
この場合、架空のペルソナを作成したうえで、事実となる情報を読み込ませてペルソナが語る形でコンテンツを生成していくことになります。
ただ、実際のインタビューではなく、あくまで架空の人物による架空のシナリオを出力する形になるので、読者の反感を買うなどのリスクが生じる可能性があります。
そのため、ここは実際に機能として実装するかは検討中です。
ツールへのほかユーザー招待・権限管理
招待機能を実装することで、キーワード選定と参考記事の選択はSEO担当者やマーケターが、生成された記事の編集・調整はライターがと役割分担が可能になりそうです。
バージョン管理
AIが生成した元記事、編集した記事、それらの差分をチェックできるバージョン管理機能がついたら、承認フローとしても便利そうだなと思います。
WordPressへの自動入稿
正直WordPressとはあまり関わりたくない気持ちはありますが…！しかし広く普及しているCMSであることも事実。ユーザーのことを考えると、ワンクリックでWordPressへ入稿する仕組みがあるに越したことはありません。
この場合はプラグインで実装することになるかもしれません。実装も手間そうですし、かなり優先度は低め。
Shodoという記事校正ツールがユーザー招待・コメント機能・WordPressへの入稿に対応しており、このツールに乗っかる（ユーザーに利用してもらう、推奨する）のが良いかもしれません。
このように妄想はつきませんが…！まずはクローズドβでのAI高品質SEO記事作成ツールの公開を目指して開発してまいります。
AIによる高品質SEO記事作成ツール: クローズドβ版の先行登録を募集しています！
本AIツールにご興味をもたれた方は、ぜひクローズドβ版の招待のための先行登録をお願い致します。
ソース・参照元つきAIによる高品質SEO記事コンテンツ作成ツール: クローズドβ版先行ご登録ページ
本AIツールの機能について、詳細につきましては ソース・参照元つきAIによる高品質SEO記事コンテンツ作成ツールα版が完成しました🎉 の記事よりご確認ください。
この記事の気になった箇所を読み返す:
- ツール上でのファクトチェック・参照元との照らし合わせを容易にするためのビューアー・エディタを実装 → 実装しました！🎉
- AIテキスト生成時の参考文献としての著作権・robots.txtへの配慮
- プロンプトとしてAIに参考コンテンツを送付することの著作権法上の懸念
- AIによる参考コンテンツの無断転載・無断引用の防止するための抽出機能の実装（コピペチェック機能）
- スクレイピングを禁じるサイトを参考対象から除外する
- 高品質SEO記事のためのAIツール: クローズドβ版公開に向けてのデプロイ作業
- コンテナベースでの環境構築
- ログイン機能の実装
- ユーザーごとのトークン割当・利用トークンの計測
- 高品質SEO記事のためのAIツール: オープンβ版以降に実装していきたい機能リスト（優先度低め）
- ソース元・根拠・参照元の引用をより正確にAIに抽出させる
- AIによるテキスト生成時のコスト最適化
- GPTへの記憶の持たせ方
- 画像生成時のコスト圧縮
- スクレイピング実行時のパフォーマンスを改善
- AIによるテキスト生成時のパフォーマンスを改善
- （参考）1記事を生成するのに必要な待ち時間
- スクレイピングおよびアウトライン生成以降の一括生成・キュー機能（非同期処理）
- カスタムプロンプトや生成したテキスト・サムネイルなどを保存するデータ保存機能の実装
- テンプレートプロンプト
- プロンプトインジェクション対策（セキュリティ）
- フロントとバックエンドの分離、サーバレス化
- 見出しの新規追加・削除・ドラッグ&ドロップによる並び替え → 削除のみ実装しました🎉
- キーワードの一括置換機能で、表記ゆれ・別表現として新規記事を制作するケースに対応
- 生成されたテキストの品質保証（予期せぬアウトプットが出力された場合の検知と再生成）
- GPT以外のさまざまなAIモデルに対応
- オープンβ版・本製品公開以降の機能を妄想
- 生成されたコンテンツにおけるAIによる二重ファクトチェック
- 自社メディアのコンテンツをベースに、さらに競合記事などを参考文献として渡してSEO記事を作成
- YouTube, Podcast, PDFなど、さまざまなデータソースに対応
- 自社データやWebにない情報をアップロードし、蓄積・保持できる「ベースナレッジ」機能を追加
- さまざまな種類のコンテンツ・書きぶりの変更に対応
- ツールへのほかユーザー招待・権限管理
- バージョン管理
- WordPressへの自動入稿
- AIによる高品質SEO記事作成ツール: クローズドβ版の先行登録を募集しています！
