技術面接の終盤、面接官から「普段、AIを使っていますか」と聞かれた。

候補者は少し安心した。Claude Code、Codex、GitHub Copilot。普段使っているツールの名前と、コード補完やテスト生成に便利だという話なら準備してある。

ところが、面接官はツール名を聞き終えると質問を続けた。

直近の仕事では、どこをAIに任せて、どこを自分で決めましたか。

候補者が答えると、さらに聞かれた。

AIが書いたコードを、どうやって本番へ出せる状態だと判断しましたか。

社内のコードや顧客情報は、どこまで入力してよいと考えていますか。

AIを使わない方がよい場面はありますか。

用意していた「便利な使い方」の説明では足りなかった。

面接官が知りたかったのは、新しいツールを触ったことではない。候補者が仕事をどのように分け、生成された結果をどう疑い、最終的な判断をどこで引き受けているかだった。

ツール名だけでは答えにならない

「ChatGPTを使っています」「Claude Codeで実装しています」という回答から分かるのは、製品名を知っていることだけです。

実務経験を伝えるなら、作業のどの段階で使ったかまで説明する必要があります。たとえば、管理画面へ検索条件の保存機能を追加した案件なら、要件整理、状態設計、実装、テスト、レビューのうち、AIに任せた部分を具体的にします。

「フォームの雛形とテストケースの候補はAIに作らせたが、URLとローカルストレージのどちらを正とするか、複数タブで更新された場合をどう扱うかは自分で決めた」と話せれば、単なる利用経験ではなく、仕事の分担が見えます。

面接官が聞きたいのは、AIを使った回数ではありません。何を考えたうえで任せたのか、その境界を説明できるかどうかです。

どこまでAIに任せたか

AIを多く使ったこと自体が評価されるわけではありません。逆に、すべて手書きしたことが特別な強みになるとも限りません。

既存パターンに沿ったコンポーネント、型定義の下書き、テストデータ、定型的な変換処理は任せやすい仕事です。一方、要件が曖昧なままの設計、権限境界、個人情報の扱い、障害時の復旧方法は、コードを生成する前に人が決めなければなりません。

たとえば、請求書をダウンロードする画面を作る場合、ボタンやAPIクライアントの実装はAIへ任せられます。しかし、誰がどの請求書を取得できるか、失効したURLをどう扱うか、監査ログへ何を残すかは、一般的なコード例からは決まりません。会社の規則、利用者の権限、既存の運用を踏まえて判断する必要があります。

よい回答には「どれだけ使ったか」ではなく、「なぜそこまで任せたか」があります。

生成されたコードをどう確認したか

「テストが通ったので採用しました」だけでは、確認として弱い場合があります。テスト自体をAIが書いていれば、実装と同じ思い違いをテストにも持ち込んでいるかもしれません。

たとえば、AIがTypeScriptでAPIクライアントを追加したなら、型チェックやLintだけでなく、通信が遅い場合、キャンセルされた場合、401や500が返った場合、古いレスポンスが新しい状態を上書きしないかまで確認します。差分を読み、既存のエラー処理や監視方法と一致しているかも見ます。

面接では、利用した検証手段を並べるより、実際に見つけた問題を一つ話す方が伝わります。

生成された実装は正常系では動きました。ただ、画面遷移後にもリクエストが残り、遅れて返ったレスポンスが新しい状態を上書きする可能性がありました。リクエストを中断する処理を追加し、通信を意図的に遅らせて確認しました。

このような説明なら、AIの出力を受け取っただけではなく、自分で読んで判断したことが分かります。

AIを使わなかった判断

最近の面接では、AIを使った場面だけでなく、使わなかった場面も聞かれます。

たとえば、障害対応中に顧客情報を含むログを扱う場合、承認されていない外部サービスへそのまま入力するべきではありません。関係者の認識がそろっていない要件を、AIとの会話だけで仕様へ変えてしまうのも危険です。既存システムの置き換えを決める場面では、生成された一般論より、社内の運用能力や契約、移行期限を優先する必要があります。

別の例では、認証基盤の移行方針を検討しているとき、候補となる構成案の洗い出しにはAIを使えても、採用する方式の決定まで任せることはできません。利用者数、移行期間、サポート体制、障害時の影響が会社ごとに違うためです。

「使わなかった」という回答は、技術への消極性を意味しません。扱っている情報と判断の重さを理解している証拠になります。

入力してはいけない情報

面接官が情報管理について聞くのは、知識問題としてではありません。候補者が普段どのような境界を置いているかを見るためです。

APIキー、パスワード、顧客の個人情報、本番データ、未公開の設計資料、契約で外部提供を禁じられたコードは、そのまま外部のAIサービスへ送れません。会社が承認した環境であっても、保存期間、学習への利用、アクセス権、監査ログを確認する必要があります。

実務では、値を置き換えた最小の再現コードを作る、ログから識別情報を削る、公開可能な型定義だけを渡すといった工夫をします。こうした具体的な手順を説明できると、単に「機密情報には気をつけます」と答えるより信頼されます。

また、入力する情報だけでなく、生成された内容の扱いにも注意が必要です。実在するパッケージか、ライセンス上問題がないか、社内の実装を不必要に外部の設計へ置き換えていないかを確認します。

個人の工夫をチームの手順にできるか

一人だけが上手にAIを使えても、その人が不在になると再現できない方法では、チームの改善になりません。

どのツールを利用できるか、入力してよい情報は何か、生成された変更に必要な確認は何かを共有します。よくある作業はプロンプトの文章だけで残すのではなく、リポジトリのガイド、テスト、Lint、CIへ落とし込みます。

たとえば、API追加時に必要なエラー処理、ログ、権限テストをチェックリストにしておけば、人が書いたコードにもAIが書いたコードにも同じ基準を適用できます。AIの使い方を個人技にせず、既存の開発手順へ組み込むことが重要です。

面接では、「自分は速くなった」という話に加えて、レビューの粒度をそろえた、テスト観点をテンプレート化した、失敗例をチームで共有した、といった周囲への影響を話せると強くなります。

「便利だった」ではなく、何が変わったか

AIを使った効果を聞かれたとき、測定していないのに「生産性が3倍になった」と答えるのは避けた方がよいでしょう。

代わりに、以前との作業の違いを説明します。実装前に複数案を比較できるようになった、テストケースの抜けを早い段階で見つけられた、未知のコードを読む入口が作りやすくなった、調査内容を整理して他のメンバーへ渡しやすくなった、といった変化です。

数値を示すなら、実際に記録しているものを使います。PRを出すまでの時間、レビューの往復回数、障害調査にかかった時間、手作業で作っていたテストデータの準備時間などです。数字がなくても、変更前と変更後の手順を具体的に話せれば十分です。

大切なのは、AIを導入した事実ではなく、仕事の進め方や結果がどう変わったかです。

面接前に準備しておく三つの事例

AIに関する質問へ備えるなら、製品ごとの機能を暗記するより、自分の経験を三つ用意しておく方が役立ちます。

一つ目は、AIを使ってうまく進んだ仕事です。何を任せ、自分は何を判断し、どのような結果になったかを話します。

二つ目は、AIの出力に問題があり、自分で気づいて直した経験です。どの確認によって問題を見つけたかが重要です。

三つ目は、AIを使わなかった、または途中で使うのをやめた仕事です。情報管理、要件の曖昧さ、検証コストなど、判断した理由を説明します。

この三つがあれば、質問の言い回しが変わっても、自分の実務に戻って答えられます。回答するときは、案件の背景、自分の担当、AIへ任せた範囲、確認方法、結果の順に話すと、面接官も状況を追いやすくなります。

まとめ

技術面接でAIについて聞かれたとき、面接官が知りたいのは、流行のツールをいくつ触ったかではありません。

何を任せ、何を自分で決めたのか。生成された結果をどう確認したのか。扱ってはいけない情報を理解しているか。問題が起きたとき、自分の判断として説明できるか。

AIを使った経験は、それだけでは強みになりません。仕事の進め方を具体的に説明できて初めて、その経験が候補者の能力として伝わります。