一つの案を、別のAIにも見てもらう。違う視点を得るために、自分も使っているやり方です。ただ、賛成が増えたところで、何が分かったことになるのかは整理しておきたい。
自分が確認するのは、誰の意見を実際に得たかと、何を実物で確かめたかです。AI同士の合意は設計を考える材料になりますが、それだけでアプリが動いたり、読者に伝わったりしたことにはなりません。
「別の席の発言」と、別に得た回答
実際の複数AIレビューで、一つのAIの回答の中に、別のAIの「席」まで書かれていたことがありました。
文章の中で別の立場を演じること自体は、論点を広げる助けになります。ただし、それを別のAIから独立して得た意見として数えると、参加したように見える人が増えてしまいます。
そのときは、別に呼び出して得ていた回答の原文を確認しました。一つの回答内で演じられた部分は、独立した参加には含めない。役名が書いてあることと、その役の回答を取得したことは分けています。
また、回答を取得できたことと、そこで主張されたことが正しいことも別です。受け取れたから正しい、には進めません。
意見の次に、案が約束していることを見る
たとえば「通知を開いた時点で未ログインでも、ログイン後に中断した下書きへ戻れるようにしたい」という設計なら、何を確かめるかは次のように分かれます。
| 得た材料 | そこから言えること | それだけでは言えないこと |
|---|---|---|
| 別々に得たAIのレビュー | 案への賛成・異論、その理由が得られた | 実装が動く、利用者が迷わない |
| コードの確認や対象を絞ったテスト | 確認した範囲で、期待との一致や問題を見つけた | 未検査の経路や実環境でも同じ |
| 合成条件での操作・試行 | 用意した条件で、何が起きるかを見た | 日常で必要とされ、継続して使われる |
| 実際の利用の観察 | その人・その場面での理解や困り事を見た | 他の人にも同じ効果がある |
このアプリ例は、確かめ方を説明するための架空の場面です。実際に再開機能を実装・検証した報告ではありません。
「下書きへ戻れる」という約束なら、ログイン後に元の対象へ戻れるか、権限がなくなっていたらどうなるか、保存されていない編集まで戻せるように誤解させないか、といった確認が必要です。設計への賛成数を増やしても、この問いへの答えは埋まりません。
毎回、全部を調べるわけではない
誤字を一つ直すたびに、複数AIのレビューや利用者調査をするつもりはありません。今回変える内容と、間違ったときの影響から、必要な確認を選びます。
文章の構成案を頼んだ段階なら、具体例まで落とせて、次に書ける状態かを見る。実装まで頼んだなら、実装とその範囲の確認まで進める。実利用が未確認だからといって、設計や試作まで未完了にする必要はありません。
確認したことを一行で残すなら、「別々のAI回答を確認した」「合成条件で試した」「実際の利用はまだ見ていない」のように、今回得た材料を書く。よさそうな案を育てるためにも、賛成の数と、確かめた内容を取り違えないようにしています。
記録とレビューを制作へ戻す全体の考え方は、AIとの開発で残したいのは、正解より「その判断をした理由」にまとめています。