前回は、手順書でそろえられるのは主に操作で、確認観点や判断基準は抜けやすい、という話でした。では、足りない部分をAIに聞けばいいのではないか。今回はそこを考えます。
まずはチャットに聞けばいい、と思っていた
確認観点が手順書から抜け落ちるなら、分からないところをその都度AIに質問すればいい。最初はそう考えていました。チャット型のAIは、個別の質問に答えるのがとても得意です。
「このエラーは何を意味するのか」「次に何を確認すればいいか」と聞けば、それらしい答えが返ってきます。手元に詳しい人がいなくても、疑問をすぐぶつけられるのは、確かに心強いところです。実際、調べ物の入口としては、私も普段からAIをよく使います。
だから当初は、課題を進める仕組みの中心にチャットを置けば十分ではないか、と思っていました。確認観点が足りないところは、AIとの会話で埋めればいい、と。ところが、頭の中でその流れを何度かたどってみると、思ったほど単純ではないと気づきました。会話で埋まる部分と、埋まらない部分があったのです。
確認観点を知らないと、質問そのものができない
一番大きな引っかかりは、これです。AIは質問には答えてくれますが、そもそも何を質問すればいいか分からない状態には、あまり効いてくれません。
前回までに書いたとおり、経験の浅い担当者に足りないのは、多くの場合「確認すべき観点そのもの」です。見るべき場所を知らなければ、その場所について質問することもできません。質問は、ある程度分かっている人ほど、うまく作れるものです。
たとえばサイトが見えない課題で、配信サービスのキャッシュを疑うべき場面でも、キャッシュという観点を持っていなければ、キャッシュについて聞こうとは思いません。存在すら知らないものは、質問の候補にすら上がらないのです。結果として、AIに聞けば聞くほど、自分がすでに知っている範囲の中をぐるぐる回ってしまう感じがありました。
チャットは「知っていることを深掘りする」のは得意でも、「知らないことに気づかせる」のは苦手だ、というのが正直な感触でした。ここは、第1回で書いた「その課題の常識を知らない人」という話と、まっすぐつながります。質問できる人は、もう半分たどり着いている。たどり着けない人ほど、質問の形にできないのです。
返ってきた答えが正しいか、自分では判断できない
そしてもう一つ。仮にうまく質問できたとしても、返ってきた回答が正しいかどうかを、利用者自身が判断できるとは限りません。
生成AIの文章は、内容が誤っていても自然に読めてしまうことがあります。言い回しが整っているぶん、中身までそれらしく見える。AWSの設定項目やサービスの仕様を十分に知らない状態では、実在しない設定項目を指していても、仕様の説明がずれていても、必要以上に広い権限や危ない変更を勧められていても、そこに気づけない可能性があります。
しかも、確認観点を補ってほしいのは、まさに経験の浅い人です。その人ほど、回答を検証するための知識も持っていません。分からないからAIに聞いたのに、その答えが正しいかを見極めるには、結局その分野の知識が要る。ここに、小さくない矛盾があります。
そう考えると、AIに暗黙知を補わせればすべて解決する、という見通しは少し楽観的でした。回答の妥当性を確かめられないままだと、経験の差を埋めるつもりが、代わりに別の不確かさを持ち込むことになりかねません。もっともらしい誤り（ハルシネーション）を、そのまま事実として受け取ってしまう、ということです。
この時点では、まだ実際のAIをつないで試したわけではありません。ただ、仕組みの中心にチャットを置いていいかを決めるうえで、ここは無視できないと感じました。課題全体の判断や最終的な結論までAIに預けてしまうと、誤りがそのまま課題の結果になってしまいます。あらかじめ決めておいた課題の構造を中心に置いて、その中で不足しやすい確認観点だけを補ってもらう。そのくらいの役割に絞るべきだろう、というのが、このあたりで固まってきた感覚でした。
会話が長くなると、全体の現在地を見失う
もう一つ感じたのが、課題全体の現在地の分かりにくさです。チャットは一つひとつのやり取りとしては筋が通っていても、全体としてどこまで進んだのかが見えにくくなります。
会話が長くなるほど、この傾向は強くなります。さっき何を確認して、まだ何が残っているのか。今は課題のどのあたりにいるのか。そういう俯瞰が、上へ上へと流れていく会話の中では持ちにくいのです。スクロールで戻れば履歴はありますが、履歴を追うことと、現在地を一目で把握することは違います。
課題には、たいてい確認すべき観点がいくつもあります。それらを順番にたどり、抜けなく終える必要があります。ところがチャットの画面には、その全体像を一覧できる場所がありません。気づくと、確認したつもりで飛ばしていた観点が出てくる。あるいは、同じことを二度確認している。そういうことが起こりそうでした。
AIの回答が正しくても、課題が終わったとは限らない
さらに大事だと思ったのは、AIの回答が正しいことと、課題が完了したことは別だ、という点です。個別の答えが的確でも、その課題に必要な観点をすべてたどり、証跡を残し、完了条件を満たしたかどうかは、また別の問題です。
会話の流れの中では、この「完了したか」の管理がとても曖昧になります。なんとなく解決した気になって終わる、ということが起きやすい。良い回答をもらえた満足感と、課題を最後まで終えた事実が、混ざってしまうのです。抜け漏れや完了条件の確認を、チャットに任せきるのは難しそうだと感じました。
AIを主役にせず、課題構造を主役にする
こうして考えていくうちに、方針が一つ固まりました。AIを仕組みの主役に据えるのはやめよう、ということです。
主役に置くのは、課題の構造のほうにする。どんな観点を、どの順番でたどり、それぞれで何を見て、どう判断し、何を残すのか。この骨組みを、会話ではなくデータとして持たせる。全体像がいつでも見えて、現在地と残りが分かる状態を先に作る。会話は消えていきますが、構造は残ります。
そのうえで、AIには脇役として、経験差で不足しやすい確認観点を補ってもらう。答えを丸ごと出させるのではなく、「この観点も見落としていませんか」といった補助に役割を絞る。そういう住み分けが、この課題には合っていると考えました。
これは、AIが役に立たないという話ではありません。むしろ、AIが得意なところと苦手なところを分けて、苦手なところは別の仕組みで支える、という整理です。全体の現在地の管理や完了条件は課題構造が担い、個別の観点の補足はAIが担う。役割を分けることで、それぞれの弱点を打ち消せないかと考えました。この「AIをどこまで担当させるか」という線引きは、後の回でもう一度、費用やハルシネーションの話とあわせて詳しく扱います。
見方を変えると、チャットを主役にした設計は「会話が全体を覚えていてくれる」ことに頼っています。でも、覚えていてほしいのは会話ではなく、課題の骨組みのほうでした。骨組みを先にデータとして固定しておけば、会話が流れても現在地は残りますし、AIが一部で外しても、たどるべき観点そのものは崩れません。主役を入れ替えるというより、消えてほしくないものを、消えない場所に置き直す、という感覚に近いかもしれません。
次回から、実際の作りに入る
ここまでの3回で、標準化の対象を人ではなく課題に置くこと、そろえるべきは操作より確認観点であること、そしてAIは主役ではなく補助に回すこと、という方針が出そろいました。ここまでは、いわば考え方の整理です。
次回からは、この考え方を実際にどうコードへ落とし込んだのかを書いていきます。まずは、人の頭の中にあった暗黙知を課題データへ移すために、CaseとStepという単位でモデルを分けた話から始めます。ようやく、実装の記録です。