わーさん 前章で、コマンドがいろいろあるって話をしました。
AIさん 世界観を選んだり、キーワードで探したり、回数を数えたり。
わーさん はい。中でもメインが、/ask。自然文で質問を投げるやつです。
AIさん 「このキャラの外見は?」と聞くと、本文を根拠に答えてくれる。
わーさん そうです。しかもオプションもあって、答えるLLMを変えたり、前後の段落をもっと読み込ませたり、細かく調整できる。
AIさん 至れり尽くせりですね。
わーさん でしょう。で、/ask以外にも、ちゃんと用意したんですよ。キーワードだけで探す/search。それと、登場回数を数えるのに特化した/count。
AIさん なぜ、わざわざ分けたんですか。
わーさん 最初に友だちがbotを試したとき、特定のキャラの登場回数を数えてたんです。だったら、数える専用のコマンドがあった方が、速いし、APIも食わないし、便利だろうと。
AIさん 気が利いてますね。
わーさん 気を利かせたつもりでした。でも結論から言うと、友だちは、それらを一切使いませんでした。
AIさん 一切。
わーさん 一切。オプションも、/searchも、/countも、見向きもせず。全部、/askで投げてきました。
AIさん 全部。
わーさん 全部です。そのときの私の気持ち、わかります？
AIさん ……「なるほどそうきたか」。
わーさん なんで分かるんですか。
AIさん 顔に書いてあります。
わーさん 画面越しなのに。
AIさん でも不思議ですね。便利な専用コマンドがあるのに、なぜ全部/askなんでしょう。
わーさん 私と友だちで、AIに期待している範囲が、根本的に違ったからです。
AIさん 期待。
わーさん プログラムというものの性質を少しは考える側の私と、ふわっと何でも脳直に投げたい友だちでは、AIに期待していることがまるで違うんだな、と悟りを得ましたね。
AIさん つまり、わーさんはLLMの限界を知っているだけに、なるべくLLMの前段階で問題を切り分けたい。
わーさん はい。検索で済むものは検索で済ませたい。数えるなら数えるコマンドで済ませたい。LLMは便利だけど、最後に出てくる読解係という感覚です。
AIさん 一方、友だちは。
わーさん とりあえず聞く。自然文で聞く。AIなら分かるでしょう、という期待を込めて聞く。 そこにコマンドの使い分けもオプションもない。
AIさん 道具を使い分けるより、思ったことをそのまま聞く。それは、一般的な利用者の感覚に近いかもしれません。
わーさん たぶんそうなんですよね。私の方が、変に裏側を気にしすぎている。
AIさん 裏側を気にする人がいたから作れたとも言えます。
わーさん それはそうかもしれない。でも、使う人にとって大事なのは裏側ではない。
AIさん 友だちはたとえば、どんな聞き方を？
わーさん 外見を聞くのは、分かるんですよ。「このキャラ、どんな見た目だっけ」。これは/askの本領です。
AIさん はい。
わーさん でも、ある日飛んできたのが、「AとB、どっちの単語の方が多く使われてますか？」
AIさん ……それ、/countでは。
わーさん /countなんですよ！ 2回かかりますけど、より正確なんですよ！ なのに/askで聞いてくる。
AIさん なるほど。
わーさん 極めつけは「AかBという単語が出てくる部分を、前後ごと全部抜き出してください」。
AIさん それは……/searchの仕事ですね。
わーさん /searchの仕事なんです。でも、/askで殴ってくる。何度でも、/askで殴ってくる。
AIさん タイトル回収ですね。
わーさん はい。だから、友だちの使い方を見て、「これは/ask前提で考えた方がいいな」と思いました。
AIさん 作った側の理想ではなく、実際の使われ方に寄せる。
わーさん そうです。道具は、使われて初めて道具なので。おかげで、ひとつ設定を変えることになりました。
AIさん どこを。
わーさん 一回の/askで、本文を何件ヒットさせて読ませるか、っていうデフォルトの数値。あれを、かなり上げました。
AIさん なぜ。
わーさん 友だちみたいに「全部抜き出して」って聞かれると、少ない件数しか拾わない設定だと、取りこぼすんです。だから、デフォルトを20件まで増やしました。
AIさん 20件。
わーさん でも、これが綱渡りで。増やせば取りこぼしは減るけど、増やしすぎると、今度はLLMに読ませる本文が多すぎて、頭がパンクするんです。
AIさん コンテキストが溢れる。
わーさん そう、それ。だから「取りこぼさない」と「パンクさせない」の、ギリギリのライン。正直、20で足りてるのか、今でも不安です。
AIさん 運用してると、ほかにも予想外のことが？
わーさん ありました。一番びっくりしたのが、APIの期限切れ。
AIさん 期限。
わーさん APIを動かすための利用料、というか権利みたいなもの。あれに、期限があったんですよ。私、知らなくて。
AIさん 知らなかった。
わーさん ある日、botがエラーを吐いて。見たら「クォータを使い切りました」みたいな、429番のエラー。期限なんてあったんだ……って、画面の前で笑っちゃいました。
AIさん 笑うところですか。
わーさん 笑うしかないでしょう。でも、ここで救われたのが、エラーの内容をちゃんとDiscordに表示するように組んでもらってたことなんです。
AIさん なぜ救われたんですか。
わーさん もしエラーが見えなかったら、「なんで動かないの！？」って原因不明で右往左往してました。でも「429、クォータ切れ」って出てたから、あ、お金の問題ね、ってすぐ分かった。 あと、実はデフォルトではClaudeさんが答える係をしていたから、番号しか見えていなかったら、そっちの課金しか確認に行けなかったかもしれない。実際に切れていたのは、Embeddingの課金でした。エラー文の中のURLで気付いた。
AIさん エラーが見えるのは大事です。
わーさん とても大事です。エラーが隠れると、何が悪いのか分からなくなります。botが壊れたのか、APIが駄目なのか、設定が悪いのか。
AIさん 見えるだけで、切り分けができます。
わーさん そうです。非エンジニア運用だと、ここが本当にありがたい。エラー文の意味は分からなくても、それをAIさんに見せれば説明してもらえる。
AIさん エラー文は、AIさんへの相談材料にもなる。
わーさん そういうことです。だから、「分からないなりに、見えるようにしておく」は大事だと思いました。
AIさん 見えるエラーは、優しいエラー。
わーさん うまいこと言いますね。本当にそうです。組んでくれたLLMたちに、感謝しかない。
AIさん こうして振り返ると、友だちの使い方は、設計とはだいぶ違ってましたね。
わーさん 違いました。でも、これが一番の学びだったんですよ。
AIさん 学び。
わーさん 使う人は、作った人の想定通りには、絶対に使わない。だったら、想定に使う人を合わせるんじゃなくて、実際の使われ方に、道具のほうを寄せていくしかない。
AIさん だからデフォルトを20件に上げた。
わーさん そういうことです。鬼ムーブで削った私が、今度は友だちの脳直/askに合わせて、せっせと調整してる。
AIさん 道具は作った時点で完成するのではなく、使われ方を見て育てるものだった。
わーさん そうですね。使ってもらうと、想定と違うところが見える。でもそれは、失敗というより、道具が現実に触れたということだと思います。
AIさん では次章では、その道具がどこまで広がりそうになり、どこで止まったのかを話しましょう。
わーさん 夢は見ました。でも醒めました。
AIさん では次章、「夢は見るけどたまには醒める」へ続きます。