AIエンジニアを採用して失敗しない方法

一貫して発揮される判断力を採用基準にする

デモはうまくいく。履歴書は立派だ。面接を終えた全員が興奮して帰る。

だが、誰かが尋ねる。システムが同じ返金を二回発行したらどうなるのか、と。

沈黙は高くつく答えだ。

AI採用が難しいのは、仕事の見える部分が早々に完了してしまうからだ。流暢な段落で答えるチャットウィンドウは、完成したように見える。しかし、そのシステムが権限を尊重しているか、タイムアウトに耐えられるか、あるいはそれが支援するはずだった人間よりも1チケットあたりのコストが高いかどうかを教えてくれるものは何もない。

アテンションヘッドの議論に勝つ必要はない。必要なのは、誰に自分たちの代わりにその判断を任せるかを決めるための十分な証拠だ。

デモの背後にある判断力を採用せよ。その判断力を、オファーを出す前に観測可能にせよ。

ここで紹介するのは、AIをプロダクトに組み込むエンジニアに対して私が実施するプロセスだ。成果を書き出し、実際の仕事の一片を開示し、短期間の有償作業を依頼し、実際に見たものに対して採点する。研究やインフラの役割には別の演習が必要だ。仕事の定義から始めよ。

履歴書を買う前に職務を書け

「AIエンジニアが必要だ」というのは、「お金に詳しい人材が必要だ」と同じくらい漠然としている。会計士か？ CFOか？ それとも創業者にドメインを買うのをやめろと言う人材か？

雇う人が担当する問題を選べ。

一人で複数の行をカバーできる人もいる。五項目すべてに等しい深さを期待すると、求人票は給与のついた願望リストと化す。

面接を始める前に、最初の90日間の成果を書き出せ。例:

サポート文面作成アシスタントが、ポリシーエラーを増やすことなく対応時間を短縮するかどうかを検証する。測定可能なパイロット、人間によるレビューパス、そして拡大・修正・中止のいずれかの推奨を提供する。

これにより、候補者は反論する材料を得る。それがポイントだ。優秀な候補者は、対応時間がどのように測定されるのか、ポリシーの責任者は誰か、現在の人間の回答がどれほど良いか誰か確認したのかを尋ねる。弱い候補者は、「面白そうですね」と言うだろう。

あなたのチームに技術的証拠を判断できる者が誰もいない場合は、外部の実務者を評価に招け。ただし、その後実装を売り込もうとしていないかを確認せよ。そうしないと、候補者が自分自身の技術的な推薦者となってしまい、それはより有利な立場を伴う利益相反である。

ボンネットを開けてもらう

有名企業の経歴は、その人物がどこで働いていたかを教えてくれる。デモは、ある一時点で、あるラップトップ上で、機嫌が良いときに何かが動いたことを教えてくれる。どちらも、その人物があなたのチームで何を担当できるかは教えてくれない。

一つのプロジェクトを隅から隅まで語ってもらうよう求めよ：

「あなたが自ら出荷した何かを説明してください。あなたは何を担当し、何が壊れ、証拠によって何が変わったのですか？」

そして、一つの決断を全体の流れに沿って追え。最初のアプローチは何だったのか？何を測定したのか？どの代替案を却下し、その理由は？チームメイトの貢献は何か？今なら何を変えるか？

アーティファクトを求めよ：失敗した実行のサニタイズされたトレース、評価レポート、設計書、テスト、短いコードウォークスルー。トレースとは、システムが回答に至るまでに行ったことの記録であり、すべてのツール呼び出し、すべてのリトライ、すべての暗黙の飲み込みが含まれる。それは、エッセイを読むのと作業を見ることの違いだ。

元雇用主の顧客データを渡すことを拒否する候補者は、テストに合格しているのであって、落ちているわけではない。

代わりに再構成された例を用いるか、以下の共有演習を使え。「証拠を見せて」が「他人の秘密を持ってこい」になってはならない。

キャリア初期の採用の場合、証拠はより小さくても構わない。期待する範囲と監督を役割に合わせてスケールせよ。評価しているのは理解と所有であり、有名なロゴへのアクセスではない。

面接に値する五つの質問

これらは調査のためのプロンプトであって、雑学ではない。答えを暗記するだけで合格できるなら、その質問は何の役にも立っていない。

1. 「このエージェントが改善したかどうか、どうやって判断しますか？」

仕事の言葉で定義された成功を聞き取れ：正しく解決されたチケット、エージェントが実際に送信する下書き、発生する必要のなかったエスカレーション。次に、平均スコアがどのような失敗を隠すのか、新しいバージョンを何と比較するのかを尋ねよ。

優れた回答は測定を検査可能にする。その場で三つのテストケースをスケッチさせ、それぞれの合格を誰が判断するかを言わせる。モデルが回答を採点する場合、採点者をどうチェックするか尋ねよ。「94%を記録した」というのは、同じ実行が火曜日に82%を記録するなら測定ではない。

Anthropicのエージェント評価ガイドは、インタビューにふさわしい区別を明確にしている：エージェントが行ったことの記録は、結果そのものとは異なる。エージェントが「払い戻しを発行しました」と報告することは、文であって払い戻しではない。

2. 「ツールが払い戻しを送信した後にタイムアウトしました。さて、どうしますか？」

「リトライ」は誤った反射である。資金はすでに消えているかもしれない。

行動する前にトランザクションのステータスを確認すること、2回目の試行が1回目に重ならないように冪等性キーを使うこと、状態が本当に不明な場合のエスカレーションパスがあること、これらを聞き取れ。誰が障害を確認し、その後どのように作業が再開されるかを尋ねよ。用語の巧拙よりも、その設計が一つのミスで顧客に二重請求できるかどうかのほうが重要だ。

3. 「このシステムは何を読み取り、変更し、消費できますか？」

境界を問え：どのレコードを読み取り、どのアクションを実行でき、どこで人間の承認が必要か、そしてクレジットカードで一晩中ループが回るのを防ぐものは何か。

次に、その境界がどこで強制されているかを尋ねよ。モデルに「気をつけろ」と指示するプロンプトは、ポリシー文でできたファイアウォールだ。意図はあるが、強制力はない。候補者に境界を描かせ、それを越えようとするテストを提案させよ。

ついでにデータ露出についても聞け：モデルプロバイダに送られるものは何か、ログに書き込まれるものは何か、誰がそのログを読めるのか。「すべてログを取っています」は、後日コンプライアンスの話を呼び込む。

4. 「どの部分をLLMなしで作りますか？」

有能なエンジニアは、自身の提案の一部からAIを取り除くことができる。資格ルール、算術、パーミッションチェックには、ありきたりだが幻覚を起こさない実装がある。不満な顧客の意図を解釈することには、そんな実装はない。

その特定のワークフローでモデルが何をもたらし、追加の故障面を正当化する証拠は何かを尋ねよ。図のすべてのボックスにエージェントが必要なら、もっと小さな図を要求せよ。

5. 「断念したアプローチについて教えてください。」

彼らの考えを変えた観察点を聞き取れ。ユーザーが求めたのはチャットではなく検索だった。より高価なモデルが総処理コストを削減した。その機能は出荷する価値がなく、彼らはそう言った。

率直な否定的結果は、磨き上げられた成功事例に勝る。成功事例はめったに判断ルールを明らかにしないからだ。何をやめたのか、やめるのにどれだけ時間がかかったのかを尋ねよ。

小さな有償ワーキングセッションの実施

合成データを用いた、範囲を定めた有償の演習を使え。事前に概要と評価基準を送付せよ。あなたは判断力を採用しているのであって、不意打ちに対応する能力を採用しているのではない。候補者に仕事で使うツール（AIを含む）を使わせ、その後、出てきた結果を説明・検証させる。

アプリケーションエンジニア向けの90分のセッション例：

あなたは、返信を下書きし返金を提案するサポートアシスタントを引き継ぎます。ここに12件の合成チケット、短いポリシードキュメント、4つの記録済み実行があります。ある回答は3月に廃止したポリシーを引用しています。ある返金リクエストはタイムアウトします。あるチケットは別の顧客の情報を求めています。パイロットを拡大すべきかどうかを推奨し、1つの小さな改善またはテストを示しなさい。

目的の明確化に15分、深掘りに45分、推薦の説明に30分。演習が密かに npm install のテストにならないよう、準備された環境を渡せ。アクセスニーズに対応し、候補者間で条件を同等に保て。

あなたは彼らがどの質問をし、どの証拠を開き、どのリスクを最初に掴むかを見ている。12件のチケットでは信頼性を確立できないことに気づくか？「システムはもう大丈夫だ」と言わずに、一つの狭い修正を出荷できるか？来週何が起こるべきかを言えるか？

重複返金に対して失敗するテストを追加した候補者は、美しいチャットインターフェースを出荷した者よりも多くを語っているかもしれない。

同じ役割の全員に同じ核心質問と評価基準を使え。それは米国人事管理局の構造化面接ガイダンスの基本構造であり、面接パネルが雰囲気ではなく候補者を比較できるようにするために存在する。演習を実際の仕事に近づけよ。ワークサンプルと無償コンサルティングの線は、ほとんどの採用マネージャーが考えるよりも薄く、候補者にははっきり見えている。

採用スコアカード

これを面接用資料にコピーする。各評価軸に求めるレベルは、誰かと会う前に合意しておく。気に入った候補者が現れると基準が動いてしまうからだ。各面接官はディブリーフ前に独立して採点し、すべての評価に具体的な観察結果を添付する。

1 = 根拠がない、または重大な欠陥がある、2 = 大きなガイダンスがあれば実用可能、3 = 役割の範囲内で妥当、4 = 妥当な判断力に加え、検証を示した。N/O = 未観測は、面接で根拠が得られなかった場合に使う。N/Oは平均化して埋めるゼロではなく、埋めるべきギャップである。

これは意思決定の補助であって、検証済みのパフォーマンス予測因子ではない。自社の役割に合わせて調整し、人材が入社後に実際にどうなるかと照らし合わせよ。さもなければ、自分が一度も採点したことのない審査員をチューニングしているだけになる。

本番を一人で任せる人材には、すべての必須軸で確かな根拠を求める。全体のスコアが高いからといって、権限や復旧に関する未解決の弱点を覆い隠してはならない。それらは後で請求が来る二つだ。成長途上のエンジニアであれば、必要なサポートとそれを提供する担当者の名前を書き留める。

ディブリーフは次の3文で締めくくれ。この人は何を任せられるか？どんなサポートが必要か？まだ確信が持てないことは何か？ これに答えられないパネルは、これから40分間「エグゼクティブプレゼンス」について話し合うことになる。

危険信号にはもう一つ質問を

候補者が自分の貢献とチームの貢献を区別できない、過去のプロジェクトをすべて連続した成功として扱う、測定に関する質問に形容詞で答える——これらには注意が必要だ。「高精度」には分母が必要である。

その他の煙：問題が理解される前にエージェントが設計に登場する。運用コストに上限がない。障害復旧は別のチームの担当である。セキュリティが完全にプロンプトに依存している。

結論を急ぐ前に、具体的なシナリオで一度確認せよ。知らない用語は概念の欠如を意味しない。多くの優れたエンジニアは別の名前で同じ考え方を学んでいる。候補者が回答の途中で自分の誤りに気づいた場合は、それを評価すべきである。反証を突きつけられても自分の主張を更新しないのが失格の行動だ。考えるために静かな時間を必要とするのは問題ではない。

採用がすでに心配なら、まず成果物を監査せよ

うまくいかないAIプロジェクトは、間違ったエンジニアを採用した証拠ではない。課題そのものが不可能だったかもしれない。データが使えなかったかもしれない。あるいは経営陣が品質を測定する前にキーノートで完全な自律性を約束したのかもしれない。

リライトを依頼する前に、コード、設定、評価結果、関連ログを適切なアクセス制御下で保存せよ。次に、会社が実際に管理しているアカウント、サービス、APIキーを特定せよ。ここで、パイプライン全体が一人の個人の請求アカウントで動いていることが判明するチームもある。

代表的なワークフローについていくつか、独立した評価を得よ。何が機能しているか？何が失敗しているか？どの主張が再現可能か？動作が不確かな部分を調査している間は、リスクの高いアクションを制限し、作業を「維持」「修正」「置き換え」に分類せよ。

受け入れテスト、指名された責任者、判断期限を含む、短い復旧計画を依頼せよ。「新しいフレームワークが必要だ」は診断ではなく、検討すべき提案である。

採用した人材にロードマップを裏切る許可を与えよ

会社が、採用に6週間かけて選んだ判断力を罰するなら、このすべては機能しない。

「このステップには人間の承認が必要だ」「パイロットはまだ拡大を正当化しない」と言うエンジニアには、他の人の前でそれを聞けるリーダーが必要だ。根拠を元に採用して、都合の悪い発見を葬ってしまえば、すでに望んでいた答えを生産する高価な機械を組み立てただけだ。

だから次のAI職では：成果を書き出し、スコアカードを使い、不完全なものに候補者が踏み込むのを見守れ。欲しいのは、システムが準備できている理由を示せる人間であり——そして準備ができていない日に、声に出してそれを伝える人間だ。