思いついたらすぐ作れる自社専用のAI面談官
AI と面談すること自体は、もう割と当たり前になってきたと思う。AI 面接のサービスもある。背景には、それを支える技術が増えたことがある。リアルタイムの音声のやり取り、応答の速さ、音声生成の自然さと精度。声の自然さは、人と話しているのと違和感がないところまで来ていると私は思う。
我が社は、その AI 面談官を自社専用に自分たちで作った。使い道は、入社を希望する人との最初の面談である。インターンの候補者も含めたスクリーニングで、まだ実運用はしていない。応募は増えている。一方でチームは少人数で、面接官の確保に時間を取られていた。面談できる人も限られていて、特定の人に頼る形になっていた。この属人性をなくしたかった。
コードは基本的に、コードを書く AI（Claude Code と Codex）に書かせている。先に関連する技術を調べてもらい、そのうえで方向を決めた。各社がいろいろなモデルを出しているので、自社として何を使うかを比べる材料も出してもらった。作るのにかかったのは1〜2日ほどで、社内で実際に面談を試せるところまで来た。思いついたら、すぐ作れる。
自社専用で作ると、面談官に自社の基準をそのまま書き込める。何を聞くか、何を聞かないか、何を必ず伝えるか。
面談の進め方を、自社の言葉で書く
面談の中身は、設定ファイル1枚にまとめてある。面談の目的、面談官の話し方、質問と掘り下げ方、評価の観点、聞かないこと、答えないこと、伝えるルール。進め方を変えたくなったら、このファイルを書き換える。実際、作りながら評価の観点に「困ったときの相談」と「うまくいかなかった後の立て直し」を足し、働き方の好みは評価に使わずに記録すると書き足している。
面談の目安は30分。AI の面談官は、最初に5つのことを伝える。
私は AI の面談官で、人の担当者ではない
面談は文字に起こして記録し、AI の要約とあわせて採用担当者が確認する。合否は担当者が判断する
今日の面談で合否は決まらない
分からないことは「分からない」と答えてよい
途中で終えたいときは、そう伝えるか、終了ボタンを押せばよい
そのあと、18の質問に進む。いま力を入れていること、いちばん成果が出た経験、このインターンで挑戦したいこと。生成 AI をどう使っているか、その答えが正しいかをどう確かめているか。続けた経験、うまくいかなかったあとの立て直し。締め切りに間に合わなそうになったとき、いつ、誰に、どう伝えたか。
候補者が話した取り組みは、「何をしたか、自分の役割は何か、結果はどうだったか、そこから何を学んだか」の順に、話の流れに合わせて掘り下げる。大事な判断や主張には「なぜそう判断したのですか」と1回だけ聞く。反論や否定はしない。言葉に詰まったら急かさず、待つか、質問を言い換える。
社内で試すと、聞いてほしいことを AI がきちんと聞いた。こちらの返答に合わせて、次の言い方も変えてきた。相手の話題に合わせて広げたり深掘りしたりできるなら、面談に限らず、インタビューなど他の場面でも使える。
面談が終わると、書き起こしが保存され、要約が作られる。要約は7つの観点で候補者を整理する。やりたいことの明確さ、生成 AI の活用、根拠と妥当性、継続性、期限と報告の責任感、困ったときの相談、うまくいかなかった後の立て直し。それぞれを「上回る」「満たす」「懸念」の3段階で示し、根拠になった候補者の発言を引用する。材料がなければ「判断材料不足」と書く。話し方の上手さ、敬語、方言、音声認識の誤りは評価に入れない。
引用を手がかりに、担当者は書き起こしの該当箇所を読み返せる。AI の要約は、判断する担当者とは別の、第三者的な視点として入る。
要約は目安として扱い、合否は担当者が書き起こしと根拠を読んで決める。性格の診断もしない。働き方の好み（細かく指示があるほうがやりやすいか、任されるほうがやりやすいか、など）は聞くが、評価には使わず、入社後の受け入れの参考として残す。
聞かないこと、答えないことも自社で決める
AI の面談官には、聞かないことを決めてある。本籍・出生地、家族の職業や収入や健康、住まいや生活環境、宗教・支持政党・思想や信条、尊敬する人物や愛読書、労働組合、病歴・健康状態・障害、性的指向など、仕事の適性と関係のない事柄である。候補者が自分から話した場合も深掘りせず、「ありがとうございます」とだけ返して次の質問に進む。
厚生労働省は「公正な採用選考の基本」で、本籍・出生地、家族、住宅状況、宗教、支持政党、尊敬する人物、愛読書、労働組合などを、採用選考で配慮すべき14の事項に挙げている。面談官の一覧はその多くを含み、14の事項にはない本人の病歴・障害・性的指向も対象にしている（同じページは別の箇所で、障害や性的マイノリティなどを理由に人を排除しないよう求めている）。
答えないことも決めた。合否の見通し、報酬の金額、勤務開始日の約束、ルールの例外、他の候補者のこと、会社の未公開情報、面談と関係のない雑談や相談。聞かれたら「申し訳ありません、その点については私からはお答えできません。担当者から後日回答します。」と返す。
必ず守ってもらう6つのルール
フルリモートで働くうえで、必ず守ってもらうルールが6つある。
※を付けた数値は、まだ仮の基準である。
このうち期限の事前連絡は、面談官が伝えるルールの文面に「これは絶対のルールです」と書いてある。
既定の設定では、AI の面談官は6つをすべて伝え、ルールごとに「同意する」「懸念がある」「同意しない」のどれだったかを記録する。
伝える順番も決めた。先に普段の行動を聞き、ルールは後でまとめて伝える。締め切りに遅れそうになった経験、Slack を1日にどのくらい見ているか、ミーティングに遅れそうなときどう連絡するか。最初にルールを読み上げると、答えが「守れます」に寄りやすい。そう考えてこの順番にした。担当者は、普段の行動と同意を並べて読める。
ここまでは既定の設定での流れである。面談のリンクを管理画面から発行するときに、説明だけで同意は確かめない、面談では伝えずにあとで人が伝える、という伝え方にも変えられる。数値の基準を伝えず、方針だけにすることもできる。
社内で試して翌朝までに手を入れた
音声 AI の事業者は、運営側で OpenAI と Google を切り替えられる。社内で試した1回では OpenAI を使い、105の発言があり、6つのルールの確認まで進んだ。書き起こしを読み返すと、問題は4つあった。
1つ目は、AI の話が物音で途切れること。AI が話している間もマイクは音を送っていて、物音を候補者の発言と受け取って、話を止めていたとみられる。
2つ目は、少し言葉に詰まると次の質問に進んでしまうこと。0.7秒の沈黙で、回答が終わったと判定していた。
3つ目は、ルールの確認が重複すること。説明が途中で途切れると、AI は前置きからやり直していた。
4つ目は、同じ質問を繰り返すこと。締め切りに遅れそうなときと、ミーティングに遅れそうなときのように、似た質問の区別が曖昧だった。
4つを直す変更は、試した翌朝までに自分たちで入れた。OpenAI を使うときは、AI が話している間、その音声が流れ終わるまでマイクを止める。回答の終わりは、OpenAI を使うときの設定で、沈黙の長さだけで決めず、言い終えたかどうかを話の内容からも推し量る方式に変えた。確認済みのルールを AI に毎回知らせ、質問は前にしか進めないようにした。
代わりに失ったものもある。OpenAI を使うとき、AI が話している間に候補者が何か言っても、それは届かない。
修正後の実際の音声での効果は、まだ測っていない。自動テストは通っているが、確かめられるのは仕組みの動きまでで、物音や言いよどみが本当に減ったかは、人が話してみないと分からない。今後は社内の隔週のチェックインや1on1で、音声入力も含めて試していく。
4つの問題は、どれも AI の声の自然さではなく、会話の進め方の側で起きた。話し終わりの判定、物音の扱い、どこまで話したかの管理である。AI 面談を外から導入するなら、デモでは質問の出来に加えて、考えながら黙ったときに AI が次の質問へ進まないか、物音がしたときに AI の話が途切れないかを試すとよい。
候補者の同意と、データの行き先
AI に会話をさせるなら、データの送り先などセキュリティ面には注意が要る。
面談を始める前に、候補者には4つの点に同意してもらう。すべてにチェックを付けるまで、面談は始まらない。
面談官は AI で、合否は人が判断すること
書き起こしを記録し、AI が要約と評価の目安を作って、採用担当者が確認すること。録音は保存しないこと
米国の事業者（OpenAI など）で処理されること。個人情報保護法の「外国にある第三者への提供」として同意をもらっている
プライバシーポリシーと利用規約の内容。選考と関係のない事柄は話さなくてよいこと
同意できない人や、音声での面談が難しい人には、担当者に連絡するよう案内している。
この面談官では、候補者の音声は自社のサーバーを通らない。候補者のブラウザと音声 AI の事業者が直接やり取りする。このアプリでは録音を保存しない。
書き起こしは自社で保管し、要約を作るために AI の事業者（OpenAI）にも送る。主に保存するのは、書き起こし、要約、どの版の質問で面談したか、ルールの確認結果。保存場所の名前に候補者の氏名は使わない。面談の途中で仕組みを更新しても、その面談は始めたときの質問と指示のまま続くので、後から「この人にはどの質問をしたか」を辿れる。プライバシーポリシーには、面談の日から1年保存したあと削除する（削除後30日間はバックアップが残る）と書いている。費用が膨らまないよう、面談を始められる回数にも上限を置いた。
音声と書き起こしを受け取った事業者の側でデータがどう扱われるかは、各社の規約で確認する必要がある。
思いついたら作れるなら使いどころは広い
AI と会話するのが当たり前になっていくなかで、特定の会話に特化した AI を用意し、やり取りしてもらう場面は増えていくはずだ。今回は採用のスクリーニング用に作ったが、週次報告や日報への応用も考えている。
たとえば「今日何をやったか」「どこが大変だったか」を AI が聞き、話した内容をそのまま記録にする、といった形だ。文字を打つ負担を減らし、簡単に入力できる仕組みを社内に入れていきたい。子どものための教材のようなものも、作ってみたい。
付録：システム構成とセキュリティ（エンジニア向け）
この面談官は Vercel の上で動いていて、コードは AI に書かせた。そう聞くと、エンジニアなら間に合わせの作りを疑うと思う。ここからは、その人向けに作りを書いておく。モデル名などは記事を書いた時点の既定の設定で、運用では変えることがある。本文で「自社のサーバー」と書いたのは Vercel 上の処理、「自社で保管」と書いたのは自社の AWS アカウントの S3 のことだ。
使っているもの
画面とサーバー：Next.js（App Router）を Vercel で動かしている。候補者の画面、管理画面、サーバー側の短い処理をここで持つ
音声の面談：OpenAI の Realtime API（既定は gpt-realtime-2.1-mini、WebRTC で接続）か、Google の Gemini Live API（既定は gemini-3.8-live、WebSocket で接続）。どちらもブラウザから直接つなぐ
書き起こし：OpenAI では候補者の音声を gpt-4o-transcribe で文字にする。Gemini では Live API の書き起こし機能を使う
要約：OpenAI の Responses API（既定は gpt-6-luna）。Structured Outputs で、観点ごとの評価と根拠の引用を決まった形で返させる。Gemini で面談した場合も、要約は OpenAI で作る
保存：AWS の S3（東京）。データベースは使っていない。面談の記録は Vercel ではなく S3 に置く。開始の回数は S3 の「まだ無いときだけ作る」条件付き書き込み（If-None-Match）で数えるので、同時に来た開始の要求も1件ずつ数えられる
通知：面談の開始や終了を Slack に流す
面談1回の流れ
候補者が面談リンクを開く。サーバーがリンクの署名と有効期限を確かめる
候補者が同意の4項目に答える
面談を始める。サーバーが同意の版とリンクを確かめ、開始回数の上限を確かめてから、開始の記録と、質問・指示の版を S3 に残す
音声 AI につなぐ。OpenAI ならサーバーが通話を作り、Gemini なら使い捨てのトークンを発行する
面談。音声はブラウザと音声 AI が直接やり取りする
終わったら、書き起こしを S3 に保存する
書き起こしから要約を作り、S3 に保存する
Slack に終了を知らせる
担当者が管理画面で、書き起こしと要約を読む
鍵と認証
API キーはブラウザに渡さない。OpenAI では、ブラウザの接続の申し込み（SDP offer）をサーバーが受け取り、サーバーから OpenAI に通話を作らせて、応答（SDP answer）だけをブラウザに返す。この接続に使うトークンはアプリが署名したもので、有効期限は短い
Gemini には、1回しか使えない短い期限のトークンを発行する。モデル・指示・使える機能をそのトークンに固定するよう指定している
候補者に送る面談リンクは HMAC-SHA256 で署名してあり、サーバーで署名を確かめてから通す。書き換えたリンクは通らない
管理画面は Google アカウントでログインする。メールアドレスが確認済みであることと、自社の Workspace のアカウントであることを確かめ、許可したドメインに限る
管理者の操作（リンクの発行、面談の閲覧）は、記録として S3 に残す
候補者データの扱い
何を保存するか（録音は保存しない、保存場所の名前に氏名を使わない）は本文に書いたとおり
一度保存した書き起こしと、質問・指示の版は、アプリからは上書きしない作りにしている（S3 の条件付き書き込み、If-None-Match）。保存先が使えない状態なら面談を始めず、費用だけかかる状態を避ける
Slack の通知には、候補者の氏名、発言、評価を載せない
Vercel の本番ログに候補者の情報が混ざる経路を減らすため、console.log を lint で禁止している（警告とエラーの出力だけ許す）
Claude Code に渡しているルール
Claude Code は、リポジトリに置いた指示ファイル（CLAUDE.md）を読んでから作業する。このリポジトリでは、そこに次のことを書いてある。
音声は Vercel を経由させない
API キーはサーバー側だけに置き、秘密情報をコードやログに入れない
個人情報を、ログや保存場所の名前に入れない
外部の API は、公式のドキュメントで確かめた仕様だけを実装する
面談の定義は設定ファイルに置く
決まった検査（lint・整形・型・不要コードの検出・テスト）を通してから PR を出す
このうち、秘密情報の混入はコミット時と CI の検査（gitleaks）で、ログに候補者の情報が混ざる経路は console.log を禁じる lint で、機械的にも確かめている。
開発と品質の流れ
コミットするときに、秘密情報の検査（gitleaks）と整形・lint を手元で走らせる。push するときに、型検査、使われていないコードの検出（knip）、カバレッジ付きのテストを走らせる
PR ごとに CI で同じ検査を回す。主要なロジックのカバレッジが下限を下回ると落ちる
PR には AI のレビューが付き、Vercel がプレビュー環境を作る。マージするのは人（私）で、main にマージすると本番に出る
依存パッケージの自動更新では、公開から7日未満の版を対象にしない。乗っ取られたパッケージが公開直後に取り下げられるまでの猶予を取るためだ
自動更新から外している大きな版の更新も、上げられる状態になれば Issue で知らせる仕組みがある
#採用 #人事 #AI面接 #生成AI #AI #音声AI #ClaudeCode #Codex #内製 #スタートアップ
