前の回でも話しましたが、AIで心理テストを作っていると品質がバラバラになりがちです。最初はAIの限界なんだと思っていました。でもテストをいくつも作るうちに分かってきました。AIが作れないわけじゃなかったんです。自分がちゃんとした基準を渡していなかっただけでした。毎回新しくリクエストするたびに、ある日は選択肢3つ、ある日は2つ、またある日は5つが出てきました。結果の種類もあるテストは4つ、あるテストは6つ。基準がないから一貫性がなくて当然でした。
ガイドを作ることにした
このまま放っておくと後で収拾がつかなくなりそうだと感じました。テストが10個、20個になったら後から一つずつ手直しするのが大変なのは目に見えていました。最初から一定の基準で作られていれば、後から直すことも減ると思いました。そこでテスト生成ガイドを作ることにしました。このガイドをAIに事前に渡しておけば、毎回新しく説明しなくても一貫した基準でテストを作れると考えました。
AIにガイドの作り方を聞いたら、AIが質問を連発してきた
ガイド自体もAIにどう作ればいいか聞いてみました。するとAIが逆にいくつも質問を返してきました。設問は何問にすべきか、選択肢は最低何個か、テストのコンセプトはどう決めるのか、ユーザーが感情移入するポイントをどう設計するのか、ファイル構造はどうなっているか、参考にすべき既存のドキュメントがあるか。いざ答えようとすると、決まっていないことがかなり多くありました。ガイドを作ろうとしていたのに、基準を自分自身でもちゃんと整理できていなかったんです。
そこで順序を変えました。まず基準を自分で決めました。設問数は最低12問、選択肢は最低3個以上で4個推奨、結果の種類は最低5種類以上。そして基準をAIに渡したら、やっとまともなガイドを仕上げてくれました。良いケースと悪いケースの例も一緒に入れてくれて、最後にはチェックリストも作ってくれました。結果として、ガイドドキュメントはかなり充実したものになりました。
ガイドを渡したら品質が上がった——ただし選択肢の数以外は
ガイドを渡してから感じが変わりました。以前より結果の種類がバランスよく出るようになり、文体もある程度一貫性を保つようになりました。クオリティが一気に上がるというより、底上げされる感覚でした。一番よくないケースが減りました。
改善が必要な部分が見えたらAIに「この項目がちゃんと守られていない」と伝えながら、ドキュメントを少しずつ磨いていきました。でも何十回も修正した項目がありました。選択肢の数です。ガイドに「最低3個以上、推奨4個」と明記していたのに、選択肢が2個のテストが何度も出てきました。項目を強調したり、例を追加したり、間違ったケースを明示したりしてみましたが、完全には解決しませんでした。ある日はちゃんと守れていて、またある日は2つしか出てこない。ガイドがあっても守られない項目は結局守られないんだ、ということをその時初めて実感しました。
モデルを変えたら文書が急に効き始めた
Antigravityで作業しているときに、あるきっかけでモデルを変えてみました。Gemini 2.5 Flashでした。すると不思議なことが起きました。それまでちゃんと守られていなかった項目が、急に守られるようになったんです。選択肢の数も安定して4つ出るようになり、結果の種類の構造もガイドに合った形で出てきました。最初は偶然かと思いましたが、何度やっても同じでした。
Gemini 3.0 Proの方がより強力なモデルなのに、なぜガイドへの準拠は2.5 Flashの方が良く感じるのか。正確な原因は分かりませんが、私の推測はこうです。3.0 Proはリリースされてまだ間もないモデルで、今も継続的なパッチが当たっています。その過程で動作が少しずつ変わって、それがガイドの準拠にも影響しているのではないかと思っています。実際、3.0 Proもある日はガイドをちゃんと守ったり、ある日はまた守らなかったりという、バラつきがありました。まだ安定化しきれていないモデルだからかな、というのが今の見立てです。
現在のやり方：モデルの用途を分けて、毎回確認する
そこで今はモデルを用途によって使い分けています。企画やコード作業のような複雑な推論が必要な作業はGemini 3.0 Proを使います。こういった作業は3.0 Proの方が明らかにうまくこなします。一方、テストデータ生成のようにガイドに沿わなければならない繰り返し作業は、今の時点では2.5 Flashの方が安定していると感じるので、そちらに回しています。3.0 Proがより安定してくれば変わるかもしれませんが、とりあえず今はこの方法が一番無難です。
そしてどのモデルを使っても、必ず結果物を確認します。ガイドに従っていない項目が見えたら、ガイドのリンクを再び貼りながら「この部分が対応されていない」と指摘します。最初はこれを面倒だと感じていましたが、これは実は当然のプロセスです。人間が書いた結果物だってレビューするのに、AI出力をそのまま使えば当然問題が出ます。完全に自動化するよりも、確認フローの中にAIを置く方が正しいということを受け入れるようになりました。
ゲームガイドにも広げた
テストガイドを作ってからそれほど経たないうちに、ゲームを追加することにしました。会社で反射神経テストやりんごゲームのような簡単なゲーム類が流行っているのを見て、サイトに人をもっと集めるためにゲームが役立ちそうだと判断しました。テストと心理コンテンツだけでは流入経路が限られてしまいますから。
テストガイドを作りながら学んだことがあったので、ゲームガイドも最初からちゃんと作ろうと考えました。基準を先に決め、その基準を元にガイドをまとめました。ゲームごとに共通フックを使わなければならないとか、結果画面コンポーネントを統一しなければならないとか、そういう内容が入りました。テストガイドを作ったときと同じプロセスでしたが、今回は最初から順序が分かっていたので、ずっと早くまとまりました。
次の回では、ゲームを追加しながら起きたことについて話す予定です。会社で流行っているゲームを見て「これ作らなきゃ」と思ったところから、実際にゲームを実装しながら直面したことまでのお話です。
ドキュメント化はツールではなくインフラだ
このプロセスを経て感じたことは一つです。AIをうまく使うことと、ドキュメント化をうまくやることは別物ではありません。同じAIモデルを使っても、ガイドがある場合とない場合の結果物の差はかなり大きいです。そしてガイドがあっても、どう書いたかによって結果が変わります。結局、AIにうまく任せることも、自分が何を求めているかを事前に具体的に整理しておくところから始まります。
あとで収拾がつかなくなりそうだと感じて事前にドキュメント化を進めたのですが、それは正しい判断でした。テストが増えるほど、ゲームが増えるほど、ガイドなしで作ったものを後から修正するコストが積み重なります。ドキュメント化は効率を高めるツールではなく、プロジェクトを持続可能にするインフラです。それをガイドドキュメントを作りながら体で学びました。
