企業が生成AI研修を実施し、従業員が完成度の高いプロンプトを書き、十分な品質の要約を提出できるようになると、管理職はさらに難しい問いに直面します。従業員は本当にAIとの協働方法を理解しているのか、それとも、たまたま正解らしく見える内容を得ただけなのか、という問いです。評価において完了までの速さと最終成果物だけを確認していては、従業員が誤りを発見したか、情報源を確認したか、また、どのような結果をそのまま納品してはいけないと理解しているかを把握できません。
AIを使いこなすには、質問する能力だけでなく、検証と修正を行い、最終的に納品する結果に責任を持つことも必要です。従業員がこうした能力を備えているか確認するには、実際の業務状況でタスクを遂行してもらい、AIが生成した内容をどのように扱うのか、どの段階で立ち止まって確認するのか、どのような根拠に基づいて修正するのか、そして最終的に承認した結果に責任を持つ意思があるかを観察するのが効果的です。
Googleは面接にAIを導入、ただし評価対象はプロンプトだけではない
Googleはエンジニアの採用プロセスを段階的に見直しており、一部の「コード理解」（code comprehension）面接では、会社が承認した生成AIツールを使用して、既存コードの読解、デバッグ、最適化を行うことが認められています。ただし、この取り組みは現在も試験運用中であり、すべてのエンジニア面接に導入されているわけではありません。企業は、これをGoogleが正式に確立した標準プロセスと捉えるべきではありません。
この試験運用が企業にとって参考になるのは、面接官が最終的な回答だけを見ているわけではないからです。評価項目には、プロンプトエンジニアリング（prompt engineering）、出力の検証（output validation）、デバッグ（debugging）が含まれます。応募者はAIから提案を得た後、その内容が正しいかを確認し、コードの誤りを特定したうえで、修正結果が要件を満たしているか、特殊なケースを見落としていないかを確認する必要があります。HackerRankも、AIが提示した提案をまず理解し、そのうえで自らの推論過程を面接官に説明するよう応募者に勧めています。ただし、これはHackerRankによる面接対策の助言であり、Googleが正式に定めた要件として記載することはできません。
Googleによると、新規コードの75％はAIによって生成され、その後、人間によるレビューを経て、最終的にはエンジニアが採用するかどうかを判断しています。つまり、AIを使用できるからといって、従業員が本来備えるべき専門能力が重要でなくなるわけではありません。要件を理解する力、論理的判断力、デバッグ能力が不足していれば、AIが提示した回答を利用できるかどうかを判断することは困難です。管理職がこの方法を参考にするのであれば、まず明確にすべきことがあります。会社が評価したいのは、従業員がツールを操作できるかどうかでしょうか。それとも、結果に問題がないことを確認し、安全に業務プロセスへ組み込めるかどうかでしょうか。
プロンプトコンテストではなく、実際のタスクで4つのプロセスを確認する
在職中の従業員についてAIとの協働能力を評価する場合、まずは範囲が明確で、管理職が成果物の基準を熟知しているタスクを一つ選ぶとよいでしょう。例えば、営業見積もりの確認、調達価格の比較、品質管理における異常の要約、カスタマーサービスの回答案、コードレビューなどです。課題には、実際の業務で発生する情報の欠落、条件の矛盾、例外的な状況を残しておく必要があります。そうすることで、単に誰がより長いプロンプトを書けるかを競うのではなく、従業員が自らの判断力を示せるようになります。
次に、タスクを「AIによる生成」「人による検証」「修正」「承認」の4つのプロセスに分けます。管理職は、従業員にプロンプトとAIの回答を保存させ、修正のたびに理由を記載させたうえで、最後にどの内容を採用でき、どの内容を差し戻してやり直す必要があるかを説明させることができます。評価時には、以下の4つの観点から確認します。
- 要件の理解：データを受け取るとすぐAIに回答させるのではなく、タスクの目的、制約、納品先を従業員が事前に明確に説明できるか。
- 誤りの識別：内容の矛盾、引用の誤り、項目の欠落、社内規定に準拠していない箇所を従業員が特定できるか。
- 特殊なケースの確認：金額の基準、例外条項、顧客ごとに異なる要件、情報が不足している場合の対応方法を従業員が自発的に確認しているか。
- 修正と承認の根拠：修正の理由と根拠を従業員が説明し、その結果を次のプロセスへ進めてよいと判断した理由を明確にできるか。
同じ評価方法は、採用、研修後の到達度確認、部門での試験運用にも利用できます。ただし、課題は各職種の実際の責任に即したものでなければなりません。調達担当者にコードのデバッグ試験を受けさせる必要はなく、エンジニアに文書の要約だけをさせるべきでもありません。管理職はまず実際のタスクを一つ選び、受け入れ可能な回答、受け入れられない誤り、どのような状況で作業を止めて確認しなければならないかを明文化する必要があります。
管理職は従業員の判断過程を把握し、後から検証できる記録も残す
一度の試験によって、従業員がその場でどのようにタスクを処理したかは確認できます。しかし、日常業務に戻った後も同じ方法で遂行するかどうかまでは証明できません。そのため、試験運用チームはプロンプト、AIの回答、人による修正、検証の根拠、承認理由を保存し、管理職が失敗事例を抜き取り調査するとよいでしょう。これにより、問題の原因が、従業員のタスクに対する不慣れ、検証不足、プロセスにおける確認ポイントの欠如、あるいはAIが生成した内容自体が不適切だったことのいずれにあるのかを判別できます。
こうした記録を保存する目的は、従業員がどのような文字を入力したかを監視することではありません。問題が発生した際に、誰がAIの提案を採用したのか、誰が内容を修正したのか、誰が承認を決定したのか、そして誤りを発見した後にどの段階まで戻って修正すべきかを、会社として明確に説明できるようにするためです。評価において、プロンプトの数、利用回数、完了までの速さだけを集計するべきではありません。これらの数値だけでは、従業員の判断が正しかったかどうかを把握できないからです。会社は毎月、成功したタスクと失敗したタスクを数件ずつ抽出し、従業員が本当に基準に従って検証しているかを確認したうえで、研修を強化するのか、課題を調整するのか、業務プロセスを見直すのかを判断できます。
企業がEgentWrXを使用する場合、複数のタスクをワークフロー（workflow）として連携し、次の担当者へ引き継ぐ前に人による承認ポイントを設けることができます。AI Agentが前段階の作業を完了すると、プロセスはいったん停止し、担当者による確認を待ちます。EgentWrXの監査ログ（audit log）にはAI Agentが実行した操作が記録されます。記録はエクスポートできるほか、ハッシュチェーン（hash chain）によって完全性を検証することも可能です。ただし、試験運用チームは、プロンプト、AIの回答、人による修正、承認理由も別途保存する必要があります。これらの資料をプラットフォーム上の記録とあわせて確認することで、ツールが何を実行したのか、人がどのように判断したのかを同時に明確に把握できます。
企業は、最初から全社共通の統一試験を設計する必要はありません。まずはリスクを管理でき、管理職が品質を判断できるタスクを選び、少人数の利用者に実際のプロセスを最後まで遂行してもらいます。その後、残された記録に基づいて評価基準を修正します。どのような結果なら承認でき、どのような状況では必ず差し戻す必要があるのかをチームが明確に説明できるようになってから、他の職種へこの評価方法を拡大するのが適切です。
よくある質問
企業はプロンプト作成能力と専門的判断力のどちらを先に評価すべきですか？
まず専門的判断力を評価し、その後、従業員がプロンプトを使って必要な情報を取得できるかを確認すべきです。プロンプトはAIとやり取りするための手段にすぎません。管理職がより重視すべきなのは、従業員が誤りを見抜き、検証方法を理解し、AIの提案を採用または差し戻す理由を説明できるかどうかです。
AIとの協働能力の評価を最初に試験導入するのに適した業務は何ですか？
成果物の基準が明確で、管理職が誤りを識別できるタスクから始めるとよいでしょう。例えば、見積もりの確認、調達価格の比較、カスタマーサービスの回答案、コードレビューなどです。プロセス内の責任を分けることが難しい、情報の機密性が高い、または誤りが発生すると即座に外部顧客へ影響するタスクは、最初の試験運用には適していません。
管理職はどのような評価記録を保存する必要がありますか？
少なくとも、タスクの要件、プロンプト、AIの回答、人による修正、検証の根拠、承認理由を保存する必要があります。これらの資料があれば、従業員がどのプロセスで問題を発見したのかを後から確認できます。また、原因が操作への不慣れ、専門知識の不足、あるいはプロセスに確認ポイントが欠けていたことのいずれにあるのかを、さらに詳しく判別できます。
一度評価を実施すれば、従業員がAIとの協働能力を備えていることを証明できますか？
できません。一度の試験で確認できるのは、その時点での従業員のパフォーマンスに限られます。同じ基準を日常業務にも適用し、成功事例と失敗事例の記録を定期的に抽出して確認することを推奨します。異なるデータ、例外条件、業務上のプレッシャーに直面した場合でも、従業員が検証と修正を行い、承認理由を記録しているかを確認する必要があります。
参考資料
- Googleのエンジニア面接が変化！求職者はGeminiを利用可能、「AIへの指示能力」も評価対象に — Business Nextによる、Googleの面接プロセスの試験運用、公式見解、HackerRankの資料のまとめ。
