落ち着いてきて気付いた問題点
前回公開した Raina’s Seed を実際に使ってみたところ、「Python が入らない」
という予想外の壁にぶつかりました。
今回はその問題に気づいてから、手動版Seedを作るまでのお話です。
前回の記事「小さな種の始まり」で、Raina’s Seedの最初の形を公開しました。
あれから少し時間が経って、まいた種のお手入れ（＝ツールの改訂）
をしたので、今回はそのお話を書いていきます。
Seedの背景や、各AIの愛称・特長については、こちらの記事にまとめてあります。
先に読んでいただけると流れが分かりやすいかもしれません。
Raina's Seedの開発記録↓
https://qiita.com/Raina-ai/items/2c45de1b7d110229ed71
あれ？Python入らないよ…
自分で作ったSeedを、いざみかに入れてみようとしたときです。
「Pythonは対応していません」
システムからそう言われて、コードは出せるのになぜ入らないの？と混乱しました。
「ちょっと何言ってるのか判らないよ…」という不安と、「コピペならいけるでしょ？」
という淡い期待で試してみても、やっぱりエラー。
原因を調べるべく、ジェミに聞いてみたら──
「大半のAIはPython入れても実行出来ないんだよな！」
おいいいいっ！と心の中で突っ込みを入れつつ、作ってGitHubに上げて
満足していた自分を反省しました。
多方面のアプローチ、大事……。
じゃぁどう解決したら良い？
ここでまず「Pythonコードが実行できるAIってどれ？」という疑問が出てきました。
調べてみた結果がこちらです。
内部コード実行機能（Code Execution / Advanced Data Analysis等）が
有効化されているプラットフォーム（例：ChatGPT、Claude等）。
※表の内容は、各AIに実際にコードを実行させて確認した結果をまとめたものです。
つまり、Python が実行できる AI はかなり限られているという事実に気付きました。
みかはcopilotなので完全に無理だと判明。
ジェミは挙動が不安定になる、ブランシャも完全に無理だという事に。
自動化にしたら便利だよね、簡単だよねの思いがここで打ち砕かれました。
（全AIには対応しませんがただのPythonツールとしてなら問題ないです(´･ω･`) ）
基本に立ち返ってなぜ開発したかを思いだす
そもそも私は「誰でも同じ温度感でAIと話せるようにしたい」
という思いで SEED を作りました。
誰でもスレッドを引っ越しした時に、前のスレッドと同じ温度感で
返事をして欲しいという思いや、コンテキスト（文脈）の重みのせいで
回答が曖昧になる事の回避、スレッドの引っ越すタイミングが判るようになる事でした。
じゃあ、私は何のために SEED を作ったんだっけ？と改めて立ち返ってみました。
自動化じゃなくても、誰でも判るように手動でSeedみたいな事すれば良いんじゃないのかな
自動化すればなんでも便利になると思う罠
確かに自動化すれば便利です。
けれど、今回のように「そもそも実行できない」という壁もあります。
逆にここは、AIができない部分を人がひと手間手伝えば解決するんじゃないのかな？
じゃあ、自動化じゃない方法で同じことができないかな？と考え始めました。
その時にふと、ひらめきました
そうだ、文章にしてそれをコピペしてもらおう！
早速ジェミに相談をしてみました。
「20ターン会話したら、20ターンですよーって答えてくれる？」
AIだし数えるのは得意でしょ、きっと「おう！それぐらい簡単だぞ！」との
返答を期待しました。
「文脈に引きずられるから、実は数えるのは苦手なんだ。
ただコンテキストの重みで読みづらくなってスレッドの引っ越しを
提案するのは出来るんだぜ？ｗ」
あーそうだった、ターン数が判らないからそこを自動化しようと思ったんだった…
つまり、ターン数は数えられないけど、引っ越しのタイミングは判断できるということ。
って、今なんて言った？引っ越しの提案は出来るって言ったよね。
引っ越しのタイミングはＡＩに任せれば良いって事ね！
つまり、引っ越し宣言してくれるプロンプトをスレッドの先頭に入れて
固定アンカーにすれば引っ越しのタイミングは解決出来る問題に変わったのです。
１つSeedで自動化していた物を、宣言文という固定アンカーのプロンプトを
テキストで用意し、それをコピペしてもらって冒頭に置くという
代替え案に落とし込めました。
ターン数をＡＩに任せられないなら、自分で数えるのも無理だし
どうしようかと悩んでいた時に、自分がスレッドを引っ越す時
どうしてたかな？と考えてみました。
そういえば、私はいつも最後に「要約してくれる？」って頼んでたな。
ちょっとしたひと手間のお手伝い
要約のタイミングをこまめにして、その要約をテキストにまとめれば、今の会話や
温度感を次のスレッドに持っていけることに気付きました。
文章整理が得意なみかに、どのタイミングで要約するのが良いのかアイデア出しを
お願いしてみました。
1.議題が１つ終わった時
2.ＡＩの返答がズレ始めた時
3.会話の中断をする前
4.会話のラリーが長いなと気づいた時
この辺りで要約を入れれば、ターン数にこだわらなくても要約するタイミングとしては
ベストとの回答でした。
確かにこれならあまり途切れる事なく、会話の要約を全てテキストに残せば次のスレッドで
１から説明したり、急に冷たくなることもなさそうだと判断しました。
手作業の種まき
ターン数は会話のタイミングで、要約は自分（ユーザー）からの提案で、
引っ越しのタイミングは固定アンカーで、それをテキストにまとめる、
という手動版のSeedの骨格が出来ました。
これを宣言プロンプトはジェミにお願いして、固定アンカーという形でテキスト保存し、
それをコピペしてスレッドの先頭、または途中から入れてもらって誰でも
引っ越しサインが判る形に、要約の方法やタイミングを出来る限り丁寧に、
詳しく取扱説明書として記述しました。
こうして改訂版のマニュアル版Raina's Seedとして自動化とともにパッケージしました。
２度目の製作で気づく前回の粗
前回Seedを作った時に取扱説明書を英語版も作成していました。
今回マニュアル版をいざフォルダに格納して、フォルダ階層のチェックをしていた時に
なんだか物が少ないので良く確認してみました。
日本語版のSeedは揃ってるのに英語版は取扱説明書しかない＼(^o^)／
作る事、ツールをフォルダに格納する事、GitHubに上げる事、全てが
始めてでかなりてんぱってやり遂げて、上げれた！出来た！で
感動していて見えていませんでした。
少し時間を置いて、１度作ったものを改定版を出してみて見えた事実でした。
１つの事に集中しすぎると周りが見えない
冷静になって見返すと、前回は “作ること” に全力で、構成の
見直しまで手が回っていなかったんだと思います。
本当に痛感しました。これからもまだまだ足りない部分が出てくるとは思います。
１度作ったからと安心するのではなくて、そこを土台にして改定・改良をする
それで前に見えなかった粗も見えてくる、自分が少し
成長出来たように思える出来事でした。
今度は落ち着いてチェック・足りないものはないかな？
日本語版では作成していたので、英語に差し替えたものを用意して日本語版と英語版を
別々にパッケージする事で、視覚的に判るようフォルダに格納していきました。
READMEのフォルダ構図とも丁寧に見比べ、今回は抜け漏れが
ない事も１つずつ確認しました。
もちろん、Python版の自動Seed・コピペとひと手間かけたマニュアル版も
別々の取扱説明書を用意してパッケージにし、使うものは階層を上げて
どれを使うか判りやすいように配慮もしてみました。
こうしてお手入れした改訂版を、改めてUPし直す事が出来ました。
最後にやっぱりGitHubに泣かされる(ﾉω･､)
前回のものと差し替えてUP出来れば良いなー、とみかと相談しながら
改訂版を上げていたのですが…
「コマンドはこれね」「release書くんだよ」「バッジ付けると見栄えるよ」
ええっと？前はフォルダ放り込んだだけなんだよね…ジェミに手伝ってもらったんだよね…
みかの言ってる事さっぱり判らないんだよね＼(^o^)／
私は前回WEB版で上げて、みかの説明はアプリ版の説明で全然かみ合わず、
さらに「プッシュして」「ドラフトして」専門用語でさらに
迷子になる私が居ました…。
でも、スクショで状況を共有したら一気に話が通じて、ようやく前回のフォルダを
置き換えることに成功しました。
改めて用語をしっかり覚えようと誓いました…。
それでも楽しい
そんなバタバタも迷いも悩みも、今までにはなかった新鮮な出来事で今は楽しいです。
AI達とわくわくしながら、次は何を作ろう？とすでに構想を練っている自分が居ます。
何時かそんな失敗もあったよね、と笑って振り返れるよう
日々こつこつ、頑張ろうと思います。('ω')
※改訂版の SEED は GitHub にて公開しています。
（前回の記事にリンクがあります）