メンター・採用担当者向け

AI を使っていい。
それでも測れる試験。

スニペット問題は AI で突破できる。コードベース全体を見せたとき、はじめて差がつく。

従来の採用・評価手法の限界

AI ツールが普及した今、従来のコーディング試験では実力を正しく測れません。

コーディングテスト

アルゴリズム問題は AI で解答できる。「解けた」が「実力がある」を意味しない時代になっています。

スニペット問題

孤立したコードを AI に貼り付けると答えが返る。プロジェクト文脈がなければ AI に依存しやすい。

この教材のアプローチ

複数ファイルにまたがる実在感のあるコードベースを舞台にする。文脈理解・判断・言語化を問うため、AI 出力のコピペでは対応できない。

AI を使うのは前提。それでも判断力の差が出るように設計されています。
「AIに聞けば答えが出る」問題ではなく、「AIの出力をどう判断するか」を問う構造だからです。

使い方 3 パターン

目的に合わせて自由にアレンジしてください。

A

採用選考

書類選考後の技術課題として。全問でなくても構いません。難易度を指定して出題することで、求める水準を絞り込めます。

B

チーム勉強会

実在するコードベースを題材に、コードレビューの観点を共有する勉強会として。正解が一つでないため議論が生まれやすい。

C

自己評価・研修

「自分の現在地を知りたい」エンジニアの自己評価ツールとして。採点プロンプトで客観的なフィードバックが得られます。

採点の仕組み

AI が量産するコードを「なんとなく動く」まま積み重ねると、やがて誰もメンテできない臨界点を迎える。
保守の単価は下がり続けるのに、プロジェクトのリスクだけが静かに上がっていく——それが「理解負債」だ。
5 つの採点軸は、そうなる前に気づき、動ける力があるかを問います。

AI ツールで「動くコード」は誰でも書けるようになった。
だからこそ問われるのは そのコードが長期的に健全かを見抜く力——
問題に気づき、影響を読み、チームが動ける言葉で伝えられるか。
この 5 つの採点軸を通じて、その判断力を可視化します。

採点の方法

Copilotに回答を記入したフォルダを添付するだけで全設問を一括採点できます。

# 添付するフォルダ: ## ソースコード 10_sample-ec/ ## 問題 20_essential/10_questions/ ## 模範解答 20_essential/30_reference-answers/ ## [受験者の回答フォルダ] 20_essential/40_evaluation/{受験者名}/20_answers/ # プロンプト: 「添付の採点基準に従い、 回答フォルダの内容を採点してください。」

採点軸(5 項目)

  • 問題特定
    コードのどこが問題か、自力で発見できるか
  • 影響範囲
    修正・追加がどこに波及するかを読めるか
  • 根拠の明確さ
    「なぜ問題か」を論理的に説明できるか
  • 改善提案
    理想論ではなく、今のコードに合った提案があるか
  • 優先度判断
    技術的負債とコストを踏まえ、何を先にやるか整理できるか

模範解答について

正解は案件により異なる。それでも、指針なしで学ぶのは遠回りです。

判断の指針として使う

模範解答は「唯一の正解」ではなく「採点の参考」。「この観点が書かれていれば加点」という採点基準を明示しているので、受験者と共有することもできます。

正解は案件ごとに異なる

現場の規模・チーム・スケジュールによって、最適な判断は変わります。「模範解答と違う」ではなく「論拠があるか」で評価することを推奨します。

「型」を知れば学びが速い

指針ゼロから実務の判断力を独学で身につけるのは遠回り。採点基準は「どう考えるか」の型を効率よく習得するための羅針盤として機能します。

レビューコメント例 — B-01: リファクタリングすべきか、否か、それが問題だ
メール処理の追加自体は問題ありませんが、今の utils.js はすでに認証・DB・計算・フォーマットなど多くの処理が同居しています。 ここにさらに追加するよりも、先に責務ごとにファイルを分ける整理をしたうえで、新機能を適切な場所に追加する方が安全だと思います。
少し時間をもらえれば分割案を出します。どうでしょうか?

▲ 問題の指摘にとどまらず、依頼者が次のアクションを取れる形でフィードバックされています。「どう直すか」の提案と「相談する姿勢」が評価されます。

まず一問、試してみましょう

リポジトリを clone して、自分でも問題を解いてみることをお勧めします。採点基準の解像度が上がります。