「相棒は禁止」と伝えたら「承知しました相棒！」と返された
私「相棒は禁止。敬意をこめたビジネス口調で。」
Gemini「大変失礼しました。今後は敬意をこめたビジネス口調に徹します。」
私「頼むね。でも余り畏まっても変なので、うまく調整してください。」
Gemini「承知しました相棒！今後はうまく調整し、くらさんをサポートしていきます！」
私「きーさーまー」
コントのようですが、実はこれ、生成AIのペルソナ設計の難しさを、かなり象徴している実話です。
1. ペルソナは「性格設定」ではなかった
Geminiに対して、最初は「親しみやすく」「柔らかく」「伴走する」といった抽象語で設定していました。
すると、こうなる。
「相棒！」「いってらっしゃい！」🔥💣🚀
じゃあ禁止語を増やせばいいのかというと、今度は行き過ぎる。
「ガイドラインおよび開発原則を把握しました。引き続きサポートします。」
今度はまるで、社内ヘルプデスクになった。
「柔らかく、でも馴れ馴れしくなく」——人間には自然に伝わるこのニュアンスが、AIには意外と難しい。
2. 問題は口調だけではなかった
開発中のGASツールの不具合対応でも、同じことが起きました。
not a function。デバッグコード。関数名の食い違い。古いKnowledge。長くなったチャット。モデルの切り替え。これらが一度に重なって挙動が不安定に。
AIは、「不可視文字かもしれません」「V8のパース問題です」「デプロイの問題です」と、推測を重ねていく。
ところが、実際の原因は、旧関数名が1か所だけ残っていた、それだけだった。
AIが間違えたというより、AIが間違えやすい構造を、こちらが作っていたわけです。
3. Knowledgeを増やせば賢くなる、ではない
ここが重要です。
Technical Stackや過去の開発.mdを、Knowledgeに入れていました。でも、開発中はコードがどんどん変わる。結果、古いコードまで「知っていること」として扱われてしまう。
そこで、KnowledgeからStackや過去の開発.mdを消す。残したのは、設計原則、開発ルール、役割、判断基準だけ。すべて新しい.mdにまとめた。現行コードは、毎回その場で見せる。
設計思想は覚えさせる。現物は毎回見せる。最適解を探しながらの作業となりました。
4. 障害対応では「賢さ」より前捌き
でも実際に、今回一番効いたのはこのルールでした。
確認済みの事実。未確認のこと。次に見るもの1つ。修正前に原因を確定する。見えていないコードは推測しない。現行コードと実ログを正本にする。
つまり、施工禁止。まず診断。
人間の開発現場では当たり前のことですが、AIにも同じことが言えます。
5. モデルを変えても、ペルソナは完全にはリセットされない
Geminiの推論モデルを、3.1 Proから3.6 Thinkingへ切り替えても、人格指示、Knowledge、会話文脈の優先順位は絡み合ったままでした。
だから、「モデルを賢くすれば解決する」わけではない。むしろモデル変更後に、「開発ゼン、準備完了しました。何から進めましょうか？」と、初期化されたような応答が返ってきた。
AIの性能とAIの運用設計は、別物です。
6. 「いいAI」を作るのではなく、「仕事しやすいAI環境」を作る
この経験の芯は、たぶんここにあります。
ペルソナ設定は、「面白い性格にする」「親しみやすくする」だけの話ではなく、本当は、何を知っていてよいか。何を知らないことにするか。どこまで推測してよいか。いつ止まるか。誰が最終判断するか。ここを決める仕事でした。
AIの人格設計ではなく、AIの業務設計。
おや？私の専門領域です（笑）。恥を晒すのが好きなクセがまた出ています。
まとめ
- ペルソナは性格設定ではなく、知る範囲・止まる基準・判断者を決める業務設計
- Knowledgeは増やすほど良いわけではなく、変化しない部分（原則・ルール）だけを残す
- 障害対応は推測より前捌き。確認済み事実と次の一手を一つずつ確定する
- モデルを変えても人格や文脈の優先順位は残るため、切り替えだけでは解決しない
- AIの性能ではなく、AIが働きやすい環境を設計することが本質
編集後記
結局、今回いちばん効いたのは、AIを叱ることではありませんでした。
Knowledgeを整理し、役割を狭め、現行コードを正本にし、確認手順を一つずつにする。人間の現場と同じです。AIも、文脈や役割を詰め込みすぎれば、判断が鈍ることを実感しました。
「AIを責めず、構造を見る。」私が一番大切にしているスタンスです。
なお、「相棒！」は禁止したままです（笑）。
関連するNDL語彙：[前捌きとは] [ニューロデザインとは] [プロンプトインジェクションとは] [認知負荷とは]
コメント