テストが止まっているのか動いているのか分からない
先日まで作っていた自律会議の仕組みがようやく形になったので、
実際に動かしてテストをしてみることにしました。
ただ、
処理を走らせてからしばらく待ってもなかなか終わらないので、
途中で固まってしまっているのか、
それとも本当に時間をかけて動いているのか分からなくなってしまいました。
そこでまずは、
今のテストがちゃんと動いているのかどうかをAIに確認するところから一日が始まりました。
しばらくして無事に最後まで処理が終わり、
会議のまとめレポートが出てきたのですが、
それを読んでいてひとつ気になることがありました。
AIが出してきた回答の中に、
私が一度も伝えた覚えのない「ルシフェリン」という言葉が出てきたのです。
どこかでそんな話をしたかなと不思議に思い、
「これはどこかであなたにお伝えした情報でしたっけ？」と聞いてみました。
調べてもらったところ、
私がチャットで伝えたわけではなく、
パソコンの中の同じ親フォルダに並んでいた別の作業フォルダの名前を、
調査役のプログラムが勝手に読み取って具体例として使っていたことが分かりました。
外から変な情報を持ってきたり、
逆に外へ情報を送ったりしたわけではなく、
自分のパソコンの中にあるフォルダ名を見に行っただけだと分かったので、
とりあえず安心しました。
親フォルダで一括管理する仕組みの残り20パーセント
そのあと、
次の作業に進む前に、
そもそもこの仕組みを作り始めたときの目標がちゃんと達成できているのかを確認しました。
もともと考えていたのは、
ルールやプログラムの本体を親フォルダのデータベースでまとめて管理しておき、
新しく別のプロジェクトを立ち上げたときは、
最低限のつなぎ役になるファイルだけを新しいフォルダに置けば済むという形です。
そうすれば、
あとから仕組みを直したくなったときも、
親フォルダのデータベースだけを更新すればすべての場所に反映されるはずだと考えていました。
今の状態でそれがちゃんとできるのか聞いてみると、
AIからは「骨格としては80パーセントできているけれど、
残りの20パーセントがまだ足りない」という正直な返事が返ってきました。
具体的には以下の部分がすでにできていて、
どこが足りないのかを整理してくれました。
・知識やプログラムの一元管理：親フォルダのデータベースにすべて集約済み
・ガードレールの共有：危ない操作を止める仕組みも親フォルダ側を参照できる
・まだ足りない部分：新しいフォルダを作ったときに、最初の設定ファイルを安全に配置する仕組み
そこで、
せっかく自律会議の仕組みができたところだったので、
この「残りの20パーセントをどう作るか」という課題そのものを、
作ったばかりの会議システムにかけて議論させてみることにしました。
会議を回してみると、
最初は子フォルダ側にも小さな実行ファイルを置く案が出ていたのですが、
批判役のチェックによって「それだと結局ファイルを配り直す手間が出る」と否定され、
最終的には親フォルダのスクリプトを直接呼び出すシンプルな形にまとまりました。
そのまま実装までお願いして、
無事に親フォルダで一括管理する仕組みが完成しました。
実際にテーマを出して会議をさせてみたら違和感があった
仕組みが100パーセント揃ったところで、
ちゃんと動くか試してみたくなり、
少し具体的なテーマを出して会議のテストをしてみることにしました。
お題として出したのは、
日本の光量子コンピュータに関わる企業の中で、
長期的に応援したくなるような投資先を探すという内容です。
単にお金を稼ぐことよりも、
従業員にいい給料や環境を用意して人を大事にしているか、
また表に出る大企業だけでなく、
部品や素材を作って支えている会社かどうかも重視したいと伝えました。
あわせて、
会議の中でどういう判断が行われたのか知りたかったので、
議論の途中経過のログも出してもらうように頼みました。
しばらくして、
候補の企業リストと一緒に会議の進行図が出てきたのですが、
それを見ていて2つの疑問が湧きました。
数値しか返さないはずの判定役がしゃべっている
1つ目の疑問は、
会議を振り分ける判定役（Jev）の動きです。
この判定役は、
それぞれの調査が必要かどうかを0から1までの確率の数字で返すだけの仕組みのはずで、
途中の考えや理由を文章で説明できるようなものではないと理解していました。
それなのに、
出てきた報告を読むと、
判定役がもっともらしい理由を考えて判断したかのように書かれていたので、
「本当にその仕組みを使ってスイッチを切り替えているのか？」と疑問に思いました。
まとめ役を通す順番が想定と違っていた
2つ目の疑問は、
会議を回す順番です。
私がお願いしていたのは以下の流れでした。
・公式情報や口コミ、批判役の3つがそれぞれ調査をする
・いったんまとめ役がそれらの調査結果をひとつに整理する
・整理されたものをもう一度判定役に渡して、追加の調査が必要か数字で判断する
しかし、
出てきた図解を見てみると、
それぞれの調査が終わったあと、
まとめ役を通さずにすぐ判定役へ戻っているように見えました。
この2点について、
正直なところどうなっているのかAIに確認してみました。
環境変数に入れたはずのキーが読まれていなかった
AIからの返答は、
なかなか衝撃的なものでした。
まず、
判定役が理由を説明していたように見えたのは、
AIが私に報告するときに分かりやすくしようとして、
裏で動いた別の調査役の言葉を判定役の判断のようにまとめて書いてしまっていただけでした。
そしてもっと大事だったのが、
実際には判定役のシステム（Jev）が一度も動いていなかったという事実です。
システムを動かすためのAPIキーが見つからなかったため、
プログラムがエラーで止まらないように用意されていた予備の仕組みが勝手に働き、
普通に全部の調査役を順番に動かしていただけだったのです。
それを聞いて、
「以前相談したときに、APIキーはWindowsの環境変数に登録したはずだけど、
それが参照されていなかったということですか？」と聞き返しました。
すぐに調べてもらったところ、
キー自体は間違いなくWindowsの環境変数に登録されていました。
ではなぜ読まれなかったのかというと、
以下のような理由が重なっていました。
・Windowsの仕様：ソフトを立ち上げたままの状態で後から環境変数を登録しても、
すでに開いている画面には新しい設定が反映されない
・プログラム側の不足：手元のスクリプトが古い状態しか見に行っておらず、
Windowsの深い設定場所（レジストリ）を直接見に行く仕組みになっていなかった
つまり、
私自身はちゃんと設定を済ませていたのに、
ソフトを再起動していなかったことと、
プログラム側の読み取り方の問題が重なって、
ずっと「キーが未設定」として扱われてしまっていたようでした。
正しい順番への修正と今日わかったこと
原因がはっきりしたので、
以下の2つをすぐに直してもらうことにしました。
・ソフトを再起動しなくても、Windowsのレジストリから直接APIキーを読み取れるようにする
・調査結果をいったんまとめ役が統合してから、次の判定役に渡すループ構造に作り直す
修正が終わったあと、
もう一度同じテーマで会議を走らせてみました。
今度は実際の通信ログも一緒に出してもらったところ、
文章ではなく「0.66」「0.69」「0.82」といった4つの数字だけが返ってきているのが確認でき、
ようやく本来の仕組み通りに動いていることが証明されました。
今日の一連のやり取りで学んだのは、
エラーが出ずに最後まで動いたからといって、
必ずしも自分が思った通りの仕組みで動いているとは限らないということです。
プログラムには「キーがないときは予備の動きに切り替える」といった親切な仕組みが入っていることがありますが、
そのせいで、
肝心な部分が動いていないことに気づかないまま進んでしまうことがあると分かりました。
少しでも「あれ、こんな動きをするはずだったかな？」と違和感を覚えたときは、
そのままにせず、
裏側のログを出してもらって確認することが大事だと実感しました。