上司がAIで作った仕組み——言いにくい未確認を、共有と合意へ変える

会議で上司が、自分で作った社内検索の仕組みを見せた。質問を入れると、規程を探して回答案を出してくれる。速いし、普段の問い合わせには役立ちそうだ。「来週から、みんなにも使ってもらおう」と話が進む。

現場には別の場面が浮かんでいます。規程が改定された翌日、答えが資料にない問い合わせ、別部署には見せられない文書、月末に質問が重なる時間帯。まだ試していない。しかし、試していない以上、「使えない」と断定する証拠もない。作った本人を前に口を開けば、成果を否定しているように聞こえそうです。

この沈黙を、勇気や人間関係だけの問題にしないでください。必要なのは反対意見ではなく、未確認を誰とどう確かめるかという提案です。

言いにくいのは、「危険」を証明できないから

現場が知っているのは、仕組みの内部ではなく、仕事が外れる場面です。通常の質問には答えた。でも改定直後は試していない。数件なら確認できた。でも繁忙日の件数では分からない。この状態で「危険です」と言えば、なぜ危険なのか、どの程度なのかまで説明を求められます。現場だけでは答えられない問いです。

逆に「便利でした」だけを伝えれば、未確認の条件が採用済みの条件に紛れます。ここで分けたいのは、賛成と反対ではありません。

• 実際に役立ったこと
• まだ試していない業務条件
• 外れたときに影響を受ける仕事
• 確かめるために必要な人と時間

未確認は欠陥の宣告ではありません。けれど、確認済みでもありません。この中間をそのまま会議へ持ち込めると、作成者の能力ではなく、次の仕事を話せます。

最初の一言は、評価より観察を先に置く

「大丈夫ですか」「少し怖いです」だけでは、返事が「大丈夫です」になりがちです。観察、未確認、提案の順なら、相手が答えられる形になります。

「規程を探す時間が短くなり、回答案まで出た点は助かりそうです。実際の問い合わせへ使う前に、規程が更新された場合と、答えが資料にない場合を、担当者と同じ例で試してもよいでしょうか」

この一言は、相手を持ち上げるための前置きではありません。何ができたかを判断材料として残し、そのすぐ横に、何がまだ分からないかを置いています。「AIは危険」という大きな主張より、次の会議で扱いやすい言葉です。

人や仕組み全体を評価する前に、「この一件では、まだ何を試していないか」を言葉にします。

一枚の表で、試す仕事を一件に絞る

懸念を全部並べると、「では何項目確認すれば終わるのか」という反発が起きます。まず、実際に使おうとしている一件を選びます。

次に、利用者、期間、扱う情報、人が行う確認、使わない条件、元の手順へ戻す場面を決めます。たとえば「総務三人が二週間、公開済み規程への社内問い合わせだけで試す。回答は送信前に担当者が根拠を読む。根拠が表示できないときは従来窓口へ戻す」と囲めます。

全部を確かめ終えるまで止める提案ではありません。ただし、限定試用で使う資料と三人の閲覧権限、情報の取扱条件は、開始前に確かめます。その境界も分からない間は架空の資料で試します。試用に必要な確認と、将来の拡大に備えた確認を分け、その結果で次を決める提案です。

確認作業を、現場へ丸投げしない

ここで現場から出やすい反論があります。「結局、確認項目を考えるのも、全部試すのも私たちですか」。それでは、未確認を口にした人ほど仕事が増え、次から誰も言わなくなります。

役割は、分かることに沿って分けます。作成者は、使った資料、設定、想定した使い方を説明する。現場は、通常処理と重要な例外を出し、回答内容を確認する。業務責任者は利用範囲と試す時間を決める。情報管理や技術の担当は、閲覧権限、記録、停止方法など、画面だけでは判断できない点を見る。一人に安全性全体の証明を求めません。

AIセーフティ・インスティテュートのAIセーフティに関する評価観点ガイド は、AIエージェントについて、権限、実行の記録、人による介入や停止、動作の観測などを評価観点に含めています。これはこの仕組みの利用を認可する基準でも、すべての試用で同じ記録を求める指示でもありません。現場からは見えない確認を、適切な担当へ渡すための観点として参照できます。

作った上司へも、「ご自身で安全を証明してください」と返すのではなく、参加の仕方を具体的に頼めます。

• 「この回答がどの資料を見たか、表示方法を教えてください。内容は現場で確認します」
• 「利用者を三人に限る設定を一緒に確認できますか。閲覧範囲は情報管理担当にも見てもらいます」
• 「修正が必要だった例はこちらで集めます。次回、直すものと対象外にするものを分けたいです」

会議の最後に、「様子を見る」を言い換える

試用の提案が通っても、「では様子を見よう」で終われば、疑問は再び宙に浮きます。最後の一分で、誰が何を記録し、誰が返事をし、いつ何を決め直すかを読み上げます。

利用回数だけでは足りません。使わなかった理由、手で直した内容、根拠が見つからなかった例、従来手順へ戻した場面、確認にかかった時間を残します。良い結果だけを集めると、試用ではなく導入の応援になります。

会議の合意は、たとえば次のように書けます。

「規程改定直後、別部署の権限、繁忙時は未確認である。二週間は総務三人の回答案作成に限り、送信前に担当者が根拠を確認する。根拠を確認できない場合は従来窓口へ戻す。現場代表が修正理由と確認時間を集め、作成者が設定を説明する。業務責任者が二週間後に、継続、修正、拡大、保留を決める」

未確認を伝えた人ではなく、答えを持つ人と判断する人まで決めて、疑問を会社の仕事にします。

共有の成否は、上司を納得させたかでは決まらない

上司の「使ってほしい」が、試用への協力依頼なのか、全員利用の決定なのかで、最初の会話は変わります。前者なら、未確認を一緒に試す提案から始められます。後者なら、「決定に反対です」と個人で背負う前に、決定に含まれていない利用範囲、確認時間、停止条件を議題へ戻す必要があります。

どちらの場合も、記事を送って相手が考えを改めれば成功、ではありません。役立った点と未確認が同じ紙に載り、試す範囲、担当、期限、次の判断が決まれば、共有は仕事になっています。

次の会議では、「役立った点があります。そのうえで、この一件を同じ条件で確認しませんか」から始めてください。言いにくかった疑問を、人への評価ではなく、作る人と使う人が共同で終える一件へ渡せます。

参考資料

• AIセーフティ・インスティテュート「AIセーフティに関する評価観点ガイド 第1.20版」