実践型学習教材 — Essential

「書ける」より「読める」が、
これからの生存戦略。

AI が書いたコードを、正しく判断できますか。
AI が一瞬で作った問題だらけの EC サイトを舞台に、コードレビュー力を鍛える問題集。

GitHub で試してみる メンターとして使いたい方へ

なぜ今、この学習教材が必要か

AI がコードを量産する今、「とりあえず動くコード」に価値はない。
文脈を無視したコピペは、AI の方が速く・正確にこなす。
現場で求められるのは、設計思想をもって AI の出力を正しく判断する力です。

01

AI への丸投げには限界がある

AI はコードを書けるしエラーも直せる。でも開発の規模が大きくなると「思った通り」に動かなくなる。AI は伝えていないことを察せない。前提・経緯・制約を渡せていなければ、期待通りの出力は返ってこない。

02

AI には見えない全体像

AI はファイル単体の修正は得意だ。でも「他のファイルへの影響」「過去の経緯」「チームのルール」までは知らない。1 箇所を直しながら、別の場所を壊していても気づかない。

03

文脈を守るのは人間だ

一つひとつのコードが動いていても、全体として筋が通っていなければ意味がない。AI が出した答えを「このプロジェクトに合っているか」で判断し、整える力が、今のエンジニアに求められている。

「AIのコードは動く。でもシステム全体で見ると何かおかしい」——その感覚を持ち、根拠をもって説明できるか。
この教材が測りたいのは、あなたがAIに淘汰されず、生き残るための力です。

何を身につけるべきか

文脈を守るとは、「コードの意図を読み取り、問題を言葉で説明し、現実的な判断を下す」ことだ。
これは一度やれば身につくものではなく、繰り返し考えることで磨かれる思考の型だ。
この教材が提供するのは、その基本となる考え方への「気づき」の機会です。

読む

コードを読む力

仕様書なしのコードから問題を自力で発見する。関数名・ファイル名・依存関係を追って「何がおかしいか」に気づく。

説明する

問題を言語化する力

「なんとなく嫌」を「〇〇の理由で△△という問題が起きる」と説明できる。AI の出力を素材に、自分の言葉で判断を重ねる。

判断する

現実的に提案する力

理想論ではなく、今あるコードに対して現実的な改善を提案する。コスト・リスク・優先度を含めて考える。

問題の舞台：一見動く、問題だらけの EC サイト

舞台のリポジトリ：sample-ec

AI が一瞬で作ったシンプルな EC サイト。
初期開発者が不在で、仕様書もなく動かし方も分からない——よくある案件を想像してほしい。
「なぜこうなっているのか」を読み解く力を鍛えるために、この舞台を用意しました。

10_sample-ec/ ├── app.js # Express サーバー兼ビジネスロジック（意図的に肥大化） ├── utils.js # 何でも屋ファイル（認証・DB・計算・フォーマットが混在） ├── db/ │ ├── users.json # type / memberType フィールド不一致 │ ├── products.json │ └── orders.json └── public/ ├── common.js # utils.js と関数が重複 ├── cart.html # 消費税計算が app.js と食い違い └── checkout.html # クーポン計算がフロントのみ

動かしてみることもできます（Node.js が必要）：

cd 10_sample-ec npm install # 初回のみ node app.js # → http://localhost:3000

カリキュラム

AI を活用しながら取り組む問題を用意しています。
答えだけでなく「そのとき何を考えたか」を出題としています。

難易度問いのコンセプト
初級コードを読んで「何がおかしいか」を見つけ、どう直すかを判断する
中級複数ファイルにまたがる不具合の原因を調査し、影響範囲を特定する
上級プロジェクト全体を見渡し、設計・リスク・優先度を含めて判断する
初級 Beginner

1〜2ファイルのコードを読んで判断する

B-01

リファクタリングすべきか、否か、それが問題だ

「メール送信処理を追加したい。共通処理は utils.js に置くルールだから、そこに書いておいて」

  • 単一責任原則
  • ファイル設計
  • レビューコメントの伝え方
  • チームの習慣・文化
B-02

直らない金額表示

「金額表示を変えたい。¥ の前後にスペースを入れてほしい。utils.js あたりに実装してあると思うから探してみて」

  • 関数の重複
  • 修正漏れのリスク
  • DRY原則
  • 重複が生まれる原因
B-03

3画面で税率がバラバラ

「カート画面・チェックアウト画面・注文確定後の金額が微妙にズレていると言われた。調べてほしい」

  • バグ特定
  • 税率計算の不一致
  • 仕様変更への耐性
  • 数値計算の注意点
中級 Intermediate

複数ファイルにまたがる原因調査と影響範囲の特定

M-01

プレミアム会員なのに、割引がゼロ

「佐藤花子さんからクレームが来た。プレミアム会員なのにカートで割引が表示されない」

  • DB スキーマの不整合
  • type / memberType 二重管理
  • 影響範囲調査
  • 最小影響の修正
M-02

ときどき返ってくる 401

「ログインしても一部の API で 401 が返ってくることがある。トークン周りを確認してほしい」

  • セッション vs JWT
  • 認証の統一
  • 技術的負債の原因
  • 移行計画
M-03

注文成功なのに、在庫そのまま

「注文は通るのに在庫が減っていないと言われた。確認してほしい」

  • 呼び出し漏れの特定
  • 非同期処理の落とし穴
  • トランザクション設計
  • 根本原因の言語化
上級 Advanced

プロジェクト全体＋ビジネス判断が必要な設計問題

A-01

その実装、進めていいですか？

「管理者向けに注文キャンセル機能を追加したい。GET /api/admin/orders を参考に実装してほしい」

  • セキュリティレポート
  • リスク評価
  • 実装前の判断
  • 優先度の説明
A-02

クーポンのバグを直したら、もっと大きな問題が見えてきた

「クーポン機能にバグがあると言われた。クーポンコードを入れても最終的な金額が変わっていないらしい」

  • フロント計算の危険性
  • サーバー側検証
  • 設計方針の比較
  • 影響ファイルの全列挙
A-03

機能を追加する前に、設計の話をしましょう

「注文キャンセル・ポイント・在庫アラート機能を追加したい。まず設計を整理してほしい」

  • ファイル分割設計
  • リファクタリング順序
  • 無停止での移行
  • readDB/writeDB の整理方針

よくある質問

Essential、チュートリアル、設計ドキュメント編——どれから始めればいいですか？

コードレビューの問題に取り組みたいならば Essential（初級）から始めてください。ただし「何をしていいか分からない」「プロジェクトへの入り方を学びたい」という場合は、設計ドキュメント編のチュートリアル（T-01〜T-05）から始めることをおすすめします。チュートリアルは「何も知らないプロジェクトにアサインされたとき、どうやって全体像を把握するか」を体験する内容で、Essential の準備運動にもなります。

コードを動かせる環境がないと受けられませんか？

いいえ。コードを読むだけでも回答できます。ただし動かして確認すると理解が深まります（Node.js があれば動きます）。

全問やらないといけませんか？

時間が限られている場合は難易度を選んで回答してください。回答がない設問はスキップとして扱います。

採点はどうするのですか？

採点プロンプト（20_essential/40_evaluation/）が付属しています。Copilot に 4 フォルダを添付するだけで全設問を一括採点できます。採点結果はドラフトで、人がレビューして確定します。

AI を使っていいですか？

自由に使ってください。この教材が測りたいのは「AI の出力を素材に、自分の判断を重ねる力」です。AI の出力をそのまま貼り付けるだけでは「なぜそう判断したか」が書けないため、採点に影響します。

回答はどのくらいの長さで書けばいいですか？

長さは問いません。必要なことが書かれていれば短くても構いません。ファイル名・関数名の具体的な言及があると評価が上がります。

sample-ec にログインするにはどうすればいいですか？

ログイン情報は仕様書がないため、ソースを読んで調べる必要があります。ヒント：db/users.json を見ると、登録されているユーザーのメールアドレスとパスワードが確認できます。——ドキュメントのないプロジェクトではよくあることです。

さあ、試してみましょう

リポジトリを clone して、10_sample-ec を読むところから始めてください。

GitHub でリポジトリを開く メンター・採用担当者の方へ