今回は私がもう一つのAIとの格闘について述べていきたい。
それはこれまでにも伝えた既存システムの分散化の話である。
システム的な話は余り好きではない人もいると思うが、しばらくご容赦頂きたい。
既存の３坂道ブログ巡回システムの概要と問題点
まずここでは既存のシステムの概要を簡単にまとめておきたい。
既存システムでは扱っているブログをレベル０ブログ、ブログ１ブログ、レベル２ブログと階層を分けて管理している。
レベル０ブログは公式サイトのことである。レベル１ブログは公式ブログのメンバーブログ記事を少し加工して投稿しているブログである。そしてレベル２ブログはレベル１ブログの記事内容にレベル１ブログへのリンクを加えた内容を投稿している。
レベル１ブログとレベル２ブログはWordPressを用いて作成している。
そして既存システムには大きく分けて３つの機能がある。
- 一つ目は、３坂道公式ブログを巡回する機能。
- 二つ目は、WordPressブログへの記事投稿機能。
- 三つめは、Xへの投稿記事投稿機能。
メンバーによる新規のブログ投稿があれば、取り込んでレベル０ブログ、レベル１ブログ、レベル２ブログの記事情報などを記事データベースと投稿スケジュール管理データベースに保管する
それと同時に各種ブログ投稿用の記事やXpost用の記事を作成しローカルフォルダに保管する。そして更に記事に添付された画像をローカルフォルダにダウンロードし保管している。
公式ブログのメンバーブログ記事を少し加工して、レベル１ブログに投稿し、記事データベースと投稿スケジュール管理データベースに投稿した記事のURLを保存する。
レベル１ブログへの記事投稿が完了したら、記事データベースのレベル２ブログの記事データに対してレベル１ブログ記事へのリンクを加えた内容でをアップデートする。そして投稿スケジュール管理データベースのレベル２ブログの投稿スケジュールを更新する。
メンバー公式ブログに新規のブログが投稿されたことを知らせるために、Xに投稿する記事を作成し、XのAPIを使用して投稿する機能である。
この記事では最大４個の画像を添付して投稿している。
ただ、XのAPIの仕様が変更されたため、現在はXへの投稿ができなくなってしまったのでこの部分は、停止している。
既存システムでは、Xへの投稿が出来ないだけではなく、WordPressブログへの記事投稿に際しても、記事やタイトルに絵文字が含まれていると投稿が失敗するという問題も発生している。
基本的にメンバーブログの記事中には多かれ少なかれ絵文字が使われている。なので、投稿エラーが発生した場合は、手動でブログへ記事投稿してそのURLをシステムに通知することで作業を継続していた。
ただ、投稿エラーに気付くのが遅れてしまって投稿スケジュールが遅れてしまうことも度々発生していた。
そこで、これらの問題を解決するために、AIと相談してWordPressブログへの投稿とXへの投稿記事作成の機能を改善することにしたのが、AIのハルシネーションとの格闘の連続となったのだ。
システムの分散化
まず、AIと相談して、公式サイトの巡回とブログ投稿は分散化することとした。
３公式サイトを定期的に巡回して各種データベースやローカルフォルダに記事情報や記事データ、画像データを保管する機能と、WordPressブログへの記事投稿機能独立したシステムとして分けることにした。
そこで、公式サイトの巡回とブログ投稿を担当するシステムを「巡回システム」と呼び、WordPressブログへの記事投稿機能を担当するシステムを「ブログ投稿システム」と呼ぶことにした。
AIと相談して、まずは巡回システムを作成することにした。既存システムのソースプログラムをAIに提供して、巡回システムのソースプログラムを作成してもらことを目標にした。
既存のシステムの仕様を伝えながら、巡回システム内の各機能の役割や処理の流れをAIと相談して決めていった。
結構順調に進み、AIにソースプログラムを作成してもらう段階でも、それなりのソースを提供されたのだ。
ただ、AIが提供してくれたソースは、既存システムのソースをベースにしているものの、かなり大幅に変更されていて、データベースのテーブル構造なども変更されていた。
そこで既存でレベル２ブログの投稿システムが既に分散化して存在しており、そちらは当面継続して使用したいので、データベースのテーブル構造やデータの保管等は一旦既存システムと同様の方法で行うこととしたい旨をAIに伝えて、再度ソースプログラムを作成してもらった。
その過程で、ほぼほぼ一日作業に費やしていたので、その後続の作業は翌日に行うことにした。
AIには責任感は無い - コンパイルエラーとAIの限界
翌日、AIに作成してもらったソースプログラムをコンパイルしてみたところ、エラーが発生してしまった。
そこで、エラーの内容をAIに伝えて、修正してもらうようにお願いした。
すると、AIはエラーの内容もすぐに理解してくれた様で、修正したソースプログラムを提供してくれた。
ただ、その際にエラーの発生原因を説明してくれたのだが、それは昨日の作業の中で私が既にAIに説明していたことを反映してくれていれば起きないエラーであった。
そこで、確認のために私が昨日伝えた内容について聞いてみると、AIはその内容を全く覚えていない様であった。
前回のこのブログでの記事で、AIの記憶の限界について述べたが、実はこの時はまだその限界を完全に理解していなかった。
いろいろとAIとやり取りして、AIの記憶の限界について理解していくまでに、実はかなり多くの（noteLMなども含む）試行錯誤や無駄な作業時間を費やしていたのだ。
更には、こういう原因でこういうエラーが発生していますと伝えてくれるのだが、それってあなたが昨日作ってくれたソースプログラムなのだから、なんで昨日の作成段階で考慮してくれなかったの？って疑問に感じた。
私は気づいていなかったのだが、こういうAIとのやり取りでも大量の文書がAIから提示されていたので、チャットがどんどん不要なごみであふれていっていたのだ。
そのうちに、私が拒否したAIからの提案に対しても、勝手に決定事項として取り扱うそぶりを見せるようになってきた。
問題解決までの試行錯誤
コンパイルエラーの解消
そこで、AIの記憶の限界を考慮して、AIとのやり取りの中で、AIに覚えておいて欲しい内容については、AIにその内容を要約してもらい、その要約を私が保存しておくことにした。
しかしその要約が全くAIの記憶の限界を超えていることもあって、AIの妄想も入り込み全く意味がないものだった。
仕方無く、要約は私の方で行うことにした。また、それをAIに提供して、AIにその内容を理解してもらう様にチャットの指示の中に文章で伝えたら、既存システムの仕様を伝えた段階でハルシネーションを起こすのだった。
そこで、AIに提供するソースプログラムの量を減らして、AIが理解しやすい様にすることにしても無駄だった。
そこでAIに相談したところ、要約やソースプログラムはある程度文書にまとめて、チャットの添付機能を使用して提供することにした。ただし添付ファイルも一度に大量に提供するのではなく、必要な部分を分割して提供することにした。
コンパイルエラーを解消するために、プロジェクト単位にソースを取りまとめ、まずは一つ分のプロジェクトのソースを添付としてAIに提供し、コンパイルエラー一件について一件の指示を行う様にして、コンパイルエラーをつぶしていった。
この方法はある程度うまくいってイルエラーを解消することができた。
ただ、途中で、それってあなたの提案を受けてそういう形にしたんだよねと言うことが何回もあったが、作業を進めるために、そういうことは気にしないことにした。
AIと会話しているとあたかも人間と会話しているような錯覚に陥ることがあるが、AIはあくまでもシステムであって責任感とかいう概念とは全く関係が無いことを常に念頭に置いておく必要があると痛感した。
単体テストでのエラー
コンパイルエラーを解消した後、単体テストを行ったところ、当然だがいくつかのエラーが発生してしまった。
このエラーの解消でも、いろいろと問題が発生し、試行錯誤したが、今回はその内容については割愛して次回以降にお伝えしたいと思う。
一点、既存システムで実施していることをソースを改善（近代化）しながら実装していくことにしたのだが、AIは既存システムのソースをベースにしているはずなのにかなりの機能が実装されていなかった。この点は最初びっくりしてしまった。（今は逆にそういうものだと思って、一点ずつ確認する手順を踏んでいる。）
まとめ
今回は、既存システムの分散化に伴うWordPressブログへの投稿とXへの投稿記事作成の機能改善について、AIとの格闘の様子をお伝えしました。
AIの記憶の限界やハルシネーションの問題に直面しながらも、試行錯誤を重ねて問題解決に向けて進めていく様子が伝わったかと思います。
どうしてもチャットが長くなり、記憶の壁が発生し、AIが過去のやり取りを忘れるだけではなく、推論機能で勝手にやり取りがあったかのように妄想してしまうことがあるため、AIとのやり取りでは、そういう前提で作業を進めていく必要があります。
