AI時代の技術採用課題をどう作る?AI耐性評価の設計

AIの初心者
採用課題でよくできたコードが届いても、生成AIが書いたのかもしれません。どうすれば応募者の実力が分かりますか?

AI専門家
完成したコードに加えて、不具合の確かめ方や、修正を選んだ理由を見る設計が必要です。AIの回答を本人が検証できるかも確認できます。

AIの初心者
AIを禁止したり、とても難しい問題にしたりすればよいわけではないのですね。

AI専門家
はい。まず採用後に任せたい仕事を決め、その仕事に必要な力が表れる課題と採点基準を組み立てましょう。
AI耐性評価とは。
本記事では、生成AIを利用できる環境でも、候補者本人の理解・判断・検証能力を確かめられるようにする技術採用の評価設計を指します。統一された規格の名称としてではなく、AIの支援と本人の職務能力を考慮して課題を見直す考え方として扱います。
提出物は大切な評価材料ですが、それだけで仕事の進め方まで分かるとは限りません。「何が完成したか」と「本人が何を確かめ、判断できるか」を結びつけることが、課題を見直す出発点です。

AI耐性評価とは何を測る設計か
最初に決めるのは、採用後に必要な能力です。例えば保守開発を任せるなら、既存コードを読み、不具合の条件を調べ、安全な修正を選ぶ力が評価対象になります。コードを速く書けることだけを測っても、変更による影響を確認できるかは分かりません。
この考え方は、持ち帰り課題、面接中の実装、経験者採用の設計議論などに使えます。持ち帰り課題では提出後の確認時間を設け、実装面接では途中の仮説やテストを観察します。経験者には、複数の修正案を比較し、運用上の制約に合わせて選ぶ場面を用意すると、職務とのつながりが明確になります。
似た言葉でも、何を知りたいかによって評価の対象は異なります。
| 考え方 | 主に確かめたいこと |
|---|---|
| AI耐性評価 | AIが使える状況でも、候補者本人に必要な職務能力があるか |
| AI検出 | 文章やコードの作成にAIが使われた可能性があるか |
| AIベンチマーク | モデルが共通の問題にどの程度対応できるか |
| AI活用力の評価 | AIへの依頼、出力の確認、修正を通して仕事を進められるか |
職場でAIを使うことを想定するなら、AI活用力と評価対象が重なる場合もあります。ただし、AIに解けない難問を探すだけでは、採用したい人を見分けられるとは限りません。特殊な知識やパズルへの慣れが得点を左右すると、実務能力との関係が薄くなるためです。
生成AIが技術採用課題の見直しを促す理由
完成コードとテストの通過は、成果物の品質を示します。一方、その品質に至った過程には違いがあります。候補者が要件を理解してAIの提案を修正した場合も、提案を十分に確認せず提出した場合も、同じテストを通ることがあります。提出物の完成度を、そのまま本人の理解の深さと同一視しないことが必要です。
例えば、注文を保存する機能が通常の入力で動いても、通信の再試行で同じ注文が二重に作られるかもしれません。提出コードだけでは、その問題を候補者が認識しているかは不明です。追加の条件を伝えたときに、問題を説明し、修正や確認方法を考えられるかを見ると、判断材料が増えます。

公開問題の流用や、仕様どおりの短い関数を書くだけの課題では、既知の解法や定型的な実装の支援を受けやすくなります。問題を非公開にしても、生成AIは与えられた仕様から解法を組み立てられるため、それだけでは対策が完結しません。成果物以外に、採用したい能力が表れる確認場面を設ける必要があります。
関連する公開事例には、2026年1月21日公開のAnthropicによる技術採用課題の改訂を扱う記事があります。課題を一度作って終えるのではなく、生成AIを取り巻く状況に応じて見直すことが、このテーマの背景です。以下の設計手順と注文APIの課題例は、本記事独自の提案です。
職務能力から逆算して課題を更新する手順
課題の更新では、能力の定義、利用ルールの設定、試行、採点結果の点検を順に進めます。難易度を上げる前に、必要な能力を確かめずに合格できる箇所を探すと、修正の目的がはっきりします。
- 能力を観察できる行動に分ける。「開発力」のような大きな言葉を、要件理解、原因調査、設計判断、検証、説明に分けます。原因調査なら「再現条件を絞れる」、設計判断なら「別案との違いを説明できる」というように、課題中に確認する行動まで具体化します。
- AIの利用条件をそろえる。目的に応じて禁止、一部許可、全面許可を選びます。例えば、基礎理解を確認する短い工程では禁止し、その後の修正では許可する設計も考えられます。対象工程、使えるツール、ネット検索の扱い、申告範囲、時間制限を事前に示します。禁止の宣言だけで、本人の能力を正しく測れるとは限りません。
- 採用側が同じ条件で試す。AIに課題文を渡し、時間や利用可能な情報を候補者と合わせて取り組みます。標準的な提案をそのまま提出しても高得点になるなら、採点項目との対応を見直します。実務にある制約や、判断理由を確かめる質問、範囲を予告した追加要件を組み込み、必要な能力が表れるようにします。
- 試行の結果から調整する。採用側の担当者にも解いてもらい、所要時間、説明の曖昧さ、職務との関連性を点検します。AIが解けるかだけでなく、適任者が限られた時間で力を示せるかも確認します。課題やツールを更新した際と、定期的な見直しの機会に再び試します。

試行では、どのツールをどの条件で使ったかを残します。条件が違う結果を混ぜると、課題の修正による変化なのか、利用環境の変化なのか判断しにくくなります。特定のAIが一度失敗したことを理由に、今後も解けない課題だと結論づけるのは避けましょう。
具体例:不具合修正から追加要件への対応まで
ここでは、バックエンドエンジニアを採用する場面を想定します。課題は「注文APIへの要求を再送すると、注文が重複する」という不具合の修正です。APIは、別のプログラムから注文登録などを依頼するための窓口を指します。通信が途切れて応答が届かないと、利用側が同じ依頼を送り直す場合があります。
全員に、架空のコードと注文データ、起動手順、既存テスト、要件を渡します。要件には「同じ依頼を再送しても注文を重複作成しない」「異なる依頼による注文は受け付ける」と書きます。例として作業60分、確認20分とし、確認時に同時実行に関する追加要件を扱うことも予告します。時間は実際の試行で調整します。
最初は現象の再現です。同じ依頼を二度送って保存件数を調べ、どの処理が注文を作るのか追います。次に原因の仮説を立て、修正し、再現に使った手順が成功することを確かめます。さらに、別の注文まで止めていないかなど、以前の機能を壊していないことを確かめる回帰テストを追加します。
修正方針の一例は、依頼ごとに識別キーを付け、処理済みの依頼を見分ける方法です。同じ操作を繰り返しても結果が重複しない性質を「冪等性」と呼びます。ただし、キーの有無だけで十分とは限りません。同じキーで異なる注文内容が届いたときの扱いなど、仕様として決めるべき点も残ります。

AIを許可する場合は、提案をどのように確認したかも尋ねます。「注文内容が同じなら削除する」という案を、正当な別注文まで消す可能性を理由に却下したなら、要件に照らした判断を観察できます。依頼文の巧さだけでなく、採用・修正・却下の根拠を確認するのがポイントです。
続いて、同じ依頼が同時に届く条件を加えます。「処理済みか確認してから保存する」だけだと、二つの処理がともに未処理と判断し、両方で保存する競合が起きる場合があります。データベースでキーの重複を防ぐ制約や、処理を一体として扱う方法を検討し、重複時の応答まで考えられるかを見ます。
提出コードだけの採点では、最終的に重複が防げたかが中心になります。再現、修正、追加要件への対応も見ると、候補者がどこまで理解し、未解決の点を把握しているかを確かめられます。説明は口頭に限らず、図やテストコードでも受け付け、話す流暢さを技術力と混同しないようにします。
成果物と判断過程を採点基準に落とし込む
採点では、印象を表す言葉より、実際に確認できた証拠を使います。「理解が深い」だけでは面接官ごとに意味が変わるため、「再送と別注文を区別する要件を確認した」のように行動と対応させます。次の表は、注文APIの課題に使う採点基準の例です。
| 観点 | 観察する証拠 | 評価の目安 | 配点例 |
|---|---|---|---|
| 要件理解 | 確認した条件、前提のメモ | 再送と別注文を区別し、曖昧な仕様を確認できる | 20点 |
| 修正の妥当性 | コードの変更、修正理由 | 原因に対応し、既存機能への影響や別案との違いを説明できる | 30点 |
| 検証 | 再現手順、テスト、実行結果 | 重複を再現し、修正後の確認と必要な回帰テストを行える | 30点 |
| 説明 | 質問への応答、図、提出メモ | 判断の根拠と未解決の条件を、コードや結果と結びつけて伝えられる | 20点 |
この配点は、合計100点とした一例です。募集する職務に応じて比重と合格基準を決めます。同時実行の制御を日常的に担う職位なら、その検証を重く見られます。一方、基礎的な修正を任せる職位に、高度な運用設計まで一律に求めると、採用要件とのずれが生まれます。
検証の段階を分けるなら、「正常な注文が通ることだけ確認」「不具合の再現と回帰テストまで実施」「境界条件や同時実行も検討」のようにします。検討しただけの段階と、テストで確かめた段階も区別しましょう。面接官がヒントを出した場合はその内容を残し、自力で気づいた場合と混ぜずに判断します。

運用前には、同じサンプル回答を複数の面接官で採点し、点が分かれた箇所を確認します。完成度や速さに加えて、何を根拠に評価するかをそろえることで、採点のばらつきを抑えられます。AIの利用回数やプロンプトの長さは、測定目的と関係がなければ加減点の理由にしません。
AI耐性評価の限界と公平に運用する注意点
どの課題も、永続的なAI耐性や本人の能力の完全な証明を保証するものではありません。生成AIの変化に加えて、問題への慣れ、緊張、実行環境なども結果に影響します。短い面接だけで仕事の全体像を測ろうとせず、過去の経験に関する質問や別の実務に近い課題など、複数の材料を組み合わせます。
公平性のためには、利用環境と時間をそろえることが基本です。AIを許可するなら、有料ツールを持っている人だけが有利にならないよう、採用側で共通の環境を用意する方法があります。操作経験の差を小さくするため、事前の利用案内や練習時間を設け、言語、障害、通信環境などに応じた配慮も用意します。
課題の内容と記録にも配慮が必要です。顧客情報や秘密情報は使わず、応募者の勤務先のコードも持ち込ませません。企業の実案件を無償で完成させるような課題を避け、架空の題材で必要な能力を確認します。AIとの会話記録を求める場合も、評価に必要な部分に絞り、保存目的や扱いを事前に伝えます。
AI検出の結果や文章の雰囲気だけで、不正利用を断定することも避けましょう。疑問があれば、事前に伝えた利用ルールに沿って事実を確認します。利用の有無に関する確認と、候補者が技術的に何を理解しているかの評価を整理すると、採否の根拠も説明しやすくなります。
まずは既存課題を一つ選び、測る能力、AIの利用ルール、提出後の確認質問、採点基準を書き出して試行してください。採点のばらつきや所要時間、候補者の負担を次の改訂に反映します。職務に必要な力を、観察できる行動から確かめ続けることが、AI時代の技術採用課題を育てる基本です。
更新履歴
| 日付 | 内容 |
|---|---|
| 2026年10月19日 | 初回公開 |
