Copilotが考えた「面従腹背のAI」

昨年夏以来、漢詩データベース検索 CanDというデータベースを構築・公開しています。詳細は直接サイトをご覧いただきたいと思いますが、今回の記事はこのデーターベースへのデータ登録作業の効率化とサイトの機能改善にAIを活用する試みの成功と失敗の記録です。

テキストデータからスプレッドシートへの変換：失敗

データベースに登録する漢詩のデータを作成する際、底本をもとにテキストデータに起こしていくわけですが、その作業はGoogleドキュメント上で行い、その後でそのテキストデータからコピー＆ペーストでSQLite上のテーブルにデータ登録していく、という手順を踏んでいました。どうしてそんな二度手間をかけるのかというと、SQLiteの操作に使用しているDB Browser for SQLiteのUIが長めのテキストを直接入力するのに適していないためです。データベースという性質上、データの正確性が命ですから、データに間違いがないかチェックしながら作成していきたいのですが、DB Browser for SQLiteの入力画面ではそれが困難なのです。そのため二度手間を承知で、データ作成はいったんGoogleドキュメント上で行っていたわけです。


とはいえ、この二度手間はやはりしんどい。底本をもとにテキストデータを作成する作業自体が決して楽な作業ではない上に、それがようやく完了したあとに、今度はGoogleドキュメントからDB Browser for SQLiteへひたすらコピー＆ペーストしなければなりません。どう考えても時間と労力の無駄です。


そこで考えたのが、AIを使用してGoogleドキュメントのテキストデータをスプレッドシートに変換してもらうという方法です。スプレッドシートにしてしまえば、それをCSVファイルに変換し、そのCSVをSQLiteにインポートするだけで済みます。時間も労力も99％省略することができます。


ものは試しと、早速、NotebookLMに作業用のノートブックを作成し、Googleドキュメントをソースとして追加・選択して「スプレッドシートに変換して」と依頼してみました。なお、Googleドキュメント内のテキストデータは以下のような形になっています。


1-1

《元日口號》

菊池五山

快意莫如元旦晴。烏輪生處彩雲擎。昨宵燈下看梅眼。移向嶽蓮殊覺明。

《元日口号》

快意 元旦の晴るるに如くは莫し。烏輪 生ずる処 彩雲 擎ぐ。昨宵 灯下 梅を看るの眼。移して 岳蓮に向ければ 殊に明らかなるを覚ゆ。

※●烏輪：太陽


これで一つの作品のデータになっていて、作品番号・詩題・作者・白文・詩題訓読・本文訓読・備考（語注など）が順に並んでいます。各項目は改行によって区切られ、作品と作品の間は空白行で区切ってあります。このようにデータは規則的に作成されていますが、その規則については全く説明せず、ただ「スプレッドシートに変換して」とお願いしただけです。さすがに無理かな、と思いながらしばらく待ったところ、なんと見事なスプレッドシートが完成しました。


上述のデータの作成規則をきちんと理解して１作品を１行に、１項目を１列に変換したスプレッドシートが出来上がり、しかも先頭行には元データに存在しない列タイトルまで付けられていますし、そのタイトル名も適切です。

これはすごいと感動したのも束の間、よく見てみると、詩題訓読の項目が消滅しているほか、備考データ内の「※」や「●」がなぜか削除されています。AIはしばしば「頼んでいないことまで先回りしてやってくれる」と称賛されますが、それは裏返すと「頼んでいない余計なことまで勝手にやってしまう」ということでもあります。今回の作業に関しては余計なことをしてもらってはこまるので、「ソースをスプレッドシートに変換してください。省略は一切せず、データに手も加えずに表にしてください。」とあらためて依頼してみました。すると「省略や改変を行わずスプレッドシート形式（表形式）にまとめました」と素直に応じてくれ、たしかに上述の問題を改善した結果が生成されました。


「これなら大丈夫」と一安心し、この依頼文でしばらく変換作業をおこなっていたのですが、そのうちに新たな問題に気付きました。備考の列のデータの一部が勝手に「（中略）」として省略されていたのです。さらに訓読文中のデータで漢字が勝手に変更されているのも見つけました（「是れ」が「進れ」になっていた。なんでやねん）。


「省略や改変をしないで」というお願いを「わかりました。省略や改変はしません」と引き受けながら、実際には黙って省略・改変を行う・・・まさに面従腹背、世の中で一番信用してはいけない相手です。僕はこの時点でこの効率化案をあきらめました。すでに述べた通りデータベースはデータの正確性が命です。知らないあいだに勝手にデータを改変されてはたまりません。

代替の効率化方法として、久しぶりにAccessを使うことにしました。Accessなら入力フォームを作成・使用できるので、DB Browser for SQLiteに直接入力するよりはるかに入力が容易ですし、入力したデータは簡単にCSVファイルとしてエクスポートできます。効率化できるならAIにこだわる必要はありません。

訓読文作成の自動化：成功

これは上のスプレッドシートへの変換より先に実施していたことですが、白文から訓読文（書き下し文）を作成する作業をGeminiに依頼して作業の省力化に成功しました。

白文に基づいて訓読文を作成するのは地味に手間のかかる作業です。白文のテキストをもとに訓読文を作ろうとすると、漢字の配置順を入れ替えなければいけません（欲断魂→魂を断たんと欲す）。カット＆ペーストの繰り返し繰り返しです。白文のテキストを使わずにゼロから訓読文を入力することもできますが、かかる手間はどのみち同じです。

そこでAIの出番です。現在のAIなら漢文訓読くらいはある程度できるでしょう。

Geminiに白文を提示し、「書き下し文にしてください。」と依頼するとおおむね正しい訓読文が作成されます。ただ、それだけだと、勝手に句ごとに改行したり、漢字の読み仮名を（　）で付け加えたりするので、そういう余計なことをしないように釘をさす必要があります。



出力結果は８～９割正しいものが出来上がります。多少の手直しは必要ですが、自力でゼロから訓読文を作成することを考えれば、大幅に時間と労力を省くことができます。

僕はかつて「夢の（？）漢文自動訓読システムUD-Kundoku」という記事を書いたことがありますが、それから５年余り、AIははるかに正確な訓読ができる能力を獲得し、そしてその能力を誰もが簡単に利用できるようになったのです。

サイトの機能改善のためのPHPスクリプト改変：成功

漢詩データベース検索 CanDは、SQLiteのデータベースと、そのデータベースを操作するPHPでできています。検索結果として、検索対象語句を含む作品の一覧がシンプルにテキストで表示されますが、検索対象語句をハイライトしていないため、表示された作品のどの部分に検索対象語句が存在するのかわかりにくいという難点がありました。絶句程度の長さならともかく、長編の古詩などになると何の印もついていないテキストから検索対象語句の場所を探し出すのは極めて困難です。

そこで、検索対象語句をハイライトする機能を追加するためのPHPスクリプト改変をAIに丸投げすることにしました。自力ではできそうにない（というよりやる気が起きない）からです。

NotebookLMに作業用のノートブックを作成し、現状のPHPスクリプトをコピペしたGoogleドキュメントをソースとして追加・選択し、まずは「検索結果の表示で、検索にヒットした語句の部分を赤字にするにはどうしたらいいですか」と質問してみました。


回答が返ってきましたが、「具体的な実装イメージ」を読んでもどうすればいいのかわからなかったため、結局、「それらの改良をすべて施した「kanshi_search2スクリプト改良版」を出力してください」と丸投げしました。


出力されたスクリプトをそのままPHPファイルにして動かしたところ、エラーメッセージが表示されたため、そのエラーメッセージをまたNotebookLMに投げて修正箇所を教えてもらって解決、さらに新たなエラーが出たため、再度NotebookLMに修正方法を質問、最終的に「それらの修正をすべて反映した改良版のスクリプト全体を出力してください。」ともう一度丸投げし、出力されたスクリプトを実行したところ、エラーも出ず、検索対象語句の赤字表示も無事に機能しました。


結局、５往復程度のやり取り、時間にして２時間程度で所期のサイト改善が完了したのですから、これに関しては素直にAIの能力に脱帽です。

まとめ

今回使用したのはGeminiとNotebookLMだけなので、これをもってAI全般を論じることは適切ではないかもしれませんが、率直な印象としては記事のタイトルのとおり、「やるな」と言ったことを「わかりました」と言いつつ密かにやってしまう面従腹背の相手を信用し切ることはできません。信用できない相手がきわめて有能というのはかえってやっかいです。自分の監視の目が及ぶ範囲内でのみ利用するのが無難な気がしますが、しかし、その限界を踏まえた上でも、やはり効率化・省力化に有用なのは間違いありません。