はじめに
面接が終わった直後には、さまざまな反省が頭に残っています。
- あの質問にはうまく答えられなかった
- 技術選定の理由をもっと具体的に話せばよかった
- 面接官が特定の部分を何度も深掘りしていた
- 自己紹介が少し長かった
- 次回までに整理したいことが見つかった
しかし、移動して、別の予定をこなし、数日が経つと、細かい内容は少しずつ曖昧になっていきます。
「何を聞かれたか」は思い出せても、自分がどう答え、どこで詰まり、面接官がどんな反応をしていたかまでは思い出せないことがあります。
面接対策というと、面接を受ける前の準備に注目が集まりがちです。
一方で、実際に受けた面接を次の面接へ活かすための振り返りは、あまり仕組み化されていません。
そこで今回は、
面接終了後90秒の音声メモを、次回の面接対策へ変換する
というZoom AI Servicesの活用方法を考えてみます。
なお、本記事は実装・API検証を行った記事ではありません。
Zoom AI Servicesを面接後の振り返りへ活用する場合の、入力方法、処理フロー、データ構造、注意点、評価方法を整理した設計記事です。
解決したい課題
面接は、受けるだけで自動的に上達するわけではありません。
面接を受けたあとに、
- 何を聞かれたか
- 自分がどう答えたか
- どこがうまくいかなかったか
- 次回までに何を改善するか
を振り返ることで、初めて経験が次の面接へつながります。
しかし、実際には次のような問題があります。
面接中に詳細なメモを取れない
面接官と会話しながら、質問や回答をすべて記録するのは困難です。
メモを取ることに集中しすぎると、会話そのものへ集中できなくなる可能性もあります。
面接後は文章を書く気力が残っていない
面接後には、緊張が解けた疲れや移動があります。
「帰宅してから振り返ろう」と考えても、そのまま書かずに終わることがあります。
時間が経つと記憶から細部が消える
時間が経つほど、質問の具体的な表現や自分が詰まった理由が曖昧になります。
特に消えやすいのは、次のような情報です。
- 質問された直後に感じた焦り
- 回答中に説明できなかった部分
- 面接官が追加で深掘りした点
- 自分では答えられたと思ったが、不安が残った部分
- 面接直後に思いついた改善案
そのため、面接後の記憶が新鮮な短い時間を逃さず残す必要があります。
コンセプト
今回考えたのは、面接そのものを録音する仕組みではありません。
面接終了後に、自分自身で振り返りを録音する仕組みです。
面接終了
↓
90秒の振り返り音声を録音
↓
Scribe APIで文字起こし
↓
Summarizer APIで内容を整理
↓
次回までの改善タスクとして保存
↓
次の面接前に確認
面接後に長い文章を書くのではなく、スマートフォンへ向かって90秒だけ話します。
音声であれば、駅へ向かう途中や電車を待っている間にも残せます。
大切なのは、きれいな文章を作ることではありません。
その時点でしか残せない記憶を、自分の言葉で保存することです。
なぜ90秒なのか
長時間の振り返りを毎回続けるのは大変です。
反対に、短すぎると質問や反省点を十分に残せません。
そこで、毎回継続できる長さとして90秒程度を想定しました。
ただし、90秒という時間に科学的な根拠があるわけではありません。
実装後には、次の時間を比較する必要があります。
- 30秒
- 90秒
- 3分
それぞれで、
- 残せた質問数
- 改善点の具体性
- 継続しやすさ
- 要約後に残った情報量
を比較し、適切な長さを検証したいと考えています。
自由に話すだけでは整理しにくい
面接後に自由形式で話すと、内容が混ざりやすくなります。
例えば、次のような音声です。
Reactについて聞かれて、一応答えられたと思うけど、設計のところは少し微妙だった。あとハッカソンの話も聞かれて、そこは割とうまく話せたと思う。志望理由はもう少し具体的にした方がよかったかもしれない。
この中には、
- 聞かれた質問
- 自分の回答
- 自己評価
- 改善点
が混在しています。
文字起こしや要約だけで、これらを正確に分離できるとは限りません。
そのため、AIに任せる前に、音声入力の形式を設計します。
面接後に答える5つの質問
毎回、次の5項目に沿って話します。
1. 何を聞かれたか
2. 自分はどう答えたか
3. どこで詰まったか
4. 面接官はどこを深掘りしたか
5. 次回までに何を改善するか
録音画面で質問を一つずつ表示し、それに答える形式を想定しています。
音声メモの例
1つ目、何を聞かれたか。
Goを選んだ理由と、WebSocketを使った理由を聞かれた。2つ目、どう答えたか。
リアルタイム通信を実装したかったのでGoとWebSocketを選んだと答えた。3つ目、どこで詰まったか。
Node.jsではなくGoを選んだ理由をうまく説明できなかった。4つ目、深掘りされた部分。
接続が切れた場合の処理と、複数ユーザーの状態管理について聞かれた。5つ目、次回までに改善すること。
Goを選んだ理由と、切断時の設計を説明できるようにする。
このように入力を構造化すれば、後続処理でも質問と改善点を整理しやすくなります。
Zoom AI Servicesの役割
今回の設計では、Zoom AI Servicesのうち、主にScribe APIとSummarizer APIを利用します。
無理にすべてのAPIを使うのではなく、課題に必要なものだけを使います。
Scribe API：面接直後の記憶をテキストにする
Scribe APIの役割は、面接後に話した内容を文字起こしすることです。
今回の仕組みで音声を使う理由は、単にキーボード入力より楽だからではありません。
文章を書く準備をしている間にも失われていく記憶を、すぐに保存できるからです。
文字起こしされた内容は、後から検索や比較ができる形式で保存します。
また、誤認識に備えて、元音声も一定期間保存し、文字起こし結果だけを正解として扱わない設計が必要です。
特に、次のような言葉は誤認識される可能性があります。
- Go
- React
- WebSocket
- Supabase
- Cloud Run
- 企業名
- プロダクト名
- 自作サービス名
そのため、文字起こし結果は利用者が後から修正できるようにします。
Summarizer API：振り返りを次の行動へ変える
文字起こししただけでは、長いメモが蓄積されるだけです。
今回欲しいのは、記録そのものではありません。
次の面接で改善するための行動です。
Summarizer APIを利用して、文字起こし結果から内容の要約やAction Itemsを取得することを想定します。
例えば、先ほどの音声メモから次のような内容を整理します。
今回聞かれたテーマ
- Goを採用した理由
- WebSocketを使った理由
- 切断時の処理
- 複数ユーザーの状態管理
うまく説明できなかったこと
- Node.jsではなくGoを選んだ理由
- 切断時の設計
次回までのAction Items
- Goを選んだ理由を3点に整理する
- 切断時の再接続処理を説明できるようにする
- ユーザー状態管理の構成図を作る
ただし、Summarizer APIが必ずこの形式で分類してくれるとは限りません。
そのため、要約結果をそのまま完成データとして利用するのではなく、アプリケーション側で確認・修正する画面を用意します。
Zoom AI Services
↓
下書きの生成
↓
利用者が確認・修正
↓
確定した振り返りとして保存
AIが勝手に面接内容を確定するのではなく、あくまで整理を補助する立場に置きます。
保存するデータ
保存する内容は、単純な文章ではなく、後から比較できる形にします。
{
"interviewId": "interview-2026-07-13-01",
"interviewedAt": "2026-07-13",
"companyName": "非公開または匿名ID",
"selectionStage": "一次面接",
"questions": [
{
"topic": "技術選定",
"question": "なぜGoを選んだのか",
"answerSummary": "リアルタイム通信に向いていると回答した",
"selfAssessment": "partial",
"difficulty": "Node.jsとの比較を説明できなかった",
"followUpAsked": true
}
],
"nextActions": [
{
"task": "Goを選んだ理由を3点に整理する",
"status": "todo"
},
{
"task": "切断時の処理を図にする",
"status": "todo"
}
]
}
ここで重要なのは、企業ごとの質問傾向を断定することではありません。
数回の面接だけで、
この企業はこの質問をよくする
と一般化することはできません。
今回分析するのは、企業ではなく自分自身です。
複数回の面接から自分の弱点を見つける
面接記録が複数蓄積されると、自分が繰り返し詰まっているテーマを確認できます。
技術選定の理由 3回
チーム開発での役割 2回
志望理由 2回
AI生成コードの理解 2回
障害発生時の対応 1回
例えば、技術選定の理由について3回連続で十分に答えられていない場合、偶然ではなく準備不足である可能性があります。
反対に、以前は答えられなかったテーマへ次回は答えられた場合、改善できたことも記録できます。
技術選定の理由
1回目：説明できなかった
2回目：一部説明できた
3回目：代替案との比較まで説明できた
これにより、面接記録は単なる過去ログではなく、自分の成長履歴になります。
次の面接前に表示するもの
面接後に記録するだけでは、保存して満足してしまう可能性があります。
そのため、次回の面接前に、自動的に過去の弱点を表示します。
次の面接までに確認すること
- Goを選んだ理由を説明する
- WebSocketの再接続処理を確認する
- 志望理由に企業固有の内容を追加する
- 自己紹介を1分以内に収める
面接後の振り返りと、面接前の準備をつなげることで、初めて改善ループが完成します。
面接を受ける
↓
90秒で振り返る
↓
弱点とAction Itemsを整理する
↓
次回面接前に確認する
↓
改善できたか記録する
この仕組みでやらないこと
面接そのものを無断で録音しない
今回対象にするのは、面接終了後に本人が話す振り返り音声です。
企業や面接官の許可なく、面接そのものを録音する仕組みではありません。
AIに回答を捏造させない
AIに、
実際にはどう答えたと思いますか
と推測させることはしません。
保存するのは、本人が音声メモで話した内容だけです。
企業の面接傾向を断定しない
個人の面接記録だけから、企業全体の傾向を分析することは避けます。
対象はあくまで、
自分が何を聞かれ、自分がどこで詰まったか
です。
AIの評価を合否予測に使わない
音声メモから合否を予測したり、面接官の感情を推測したりする機能は対象外です。
今回の目的は、自分の振り返りと改善を補助することです。
プライバシーについて
面接後の音声メモには、企業名や選考内容などの情報が含まれる可能性があります。
実装する場合は、少なくとも次の対応が必要です。
- 企業名を匿名IDへ置き換えられるようにする
- 元音声を保存する期間を設定する
- 不要になった音声を削除できるようにする
- APIへ送信する前に内容を確認する
- 認証情報をフロントエンドへ直接置かない
- ログへ音声や文字起こし全文を残さない
- 外部サービスへの自動共有を初期状態では無効にする
また、面接官の氏名や、公開されていない選考情報は、必要がなければ記録しない方が安全です。
誤認識や要約ミスへの対応
文字起こしや要約が誤っている可能性を前提に設計します。
文字起こしが間違っていた場合
- 元音声を聞き直せるようにする
- 技術用語を手動で修正できるようにする
- 修正前と修正後を分けて保存する
要約から重要な内容が消えた場合
- 要約だけでなく文字起こし全文も確認できるようにする
- Action Itemsを確定する前に本人が承認する
- 元の発言へ戻れるようにする
実際には言っていない内容が追加された場合
- AI生成部分であることを表示する
- 本人が話した内容と区別する
- 自動確定せず、必ず確認画面を挟む
AIの出力を正解として扱うのではなく、振り返りを整理するための下書きとして扱います。
実装後に検証したいこと
この構想が本当に役立つかは、実際に使って検証しなければ分かりません。
検証するなら、次の項目を確認したいです。
| 観点 | 確認方法 |
|---|---|
| 継続しやすさ | 面接後の録音実施率 |
| 適切な録音時間 | 30秒・90秒・3分を比較 |
| 文字起こし精度 | 元音声と文字起こしを比較 |
| 技術用語の精度 | 固有名詞の正答率を確認 |
| 要約の有用性 | 必要な質問や反省点が残っているか |
| Action Itemsの有用性 | 実際に次回の準備へ使えたか |
| 改善効果 | 同じテーマへの回答が改善したか |
| 修正負担 | 人間による修正時間 |
| 記憶の鮮度 | 直後・3時間後・翌日の内容を比較 |
特に検証したいのは、録音するタイミングです。
面接終了直後
3時間後
翌日
この3つで振り返りを行い、
- 覚えていた質問数
- 回答内容の具体性
- 面接官の深掘りに関する記憶
- 改善案の数
がどの程度変化するかを比較します。
この結果から、
面接後、どの程度早く振り返ると有用な情報を残せるのか
を確認できそうです。
Translator APIを使うとしたら
今回の中心はScribe APIとSummarizer APIです。
Translator APIは、英語面接を受ける場合の拡張として利用できそうです。
例えば、日本語で残した振り返りから、
- 英語で説明できなかった内容
- 次回までに準備する英語表現
- 英語版の自己紹介素材
を作るために使えます。
ただし、賞のために無理に3つのAPIを使うのではなく、実際に英語面接という課題が発生した場合に追加する方が自然だと考えています。
面接以外への応用
今回の対象は、あくまで面接後の振り返りです。
ただし、
終了直後の記憶を、次の行動へ変える
という構造は、ほかの活動にも応用できます。
ハッカソン
審査員から受けた講評を自分の言葉で記録し、次の改善タスクへ変える。
カンファレンス
印象に残った内容や疑問を記録し、試したい技術や記事の題材へ変える。
LT・登壇
話し終えた直後の反省を記録し、次回のスライドや話し方の改善へつなげる。
ただし、最初からすべてを対象にすると課題がぼやけます。
まずは面接に限定し、本当に改善へつながるかを検証してから、ほかの活動へ広げる方がよいと考えています。
まとめ
今回考えたのは、面接後の音声メモを保存するだけの活動ログではありません。
面接終了後の記憶を、次の面接までの改善タスクへ変える仕組み
です。
想定している流れは次のとおりです。
面接終了
↓
5つの質問へ90秒で回答
↓
Scribe APIで文字起こし
↓
Summarizer APIで要約とAction Itemsを作成
↓
本人が確認・修正
↓
次回面接前に表示
↓
改善できたか記録
面接は、受けた回数だけでは上手くならないと思います。
受けたあとに何を学び、次に何を変えたかが重要です。
文章での振り返りを毎回続けるのは難しくても、終了直後に90秒だけ話すことなら続けられるかもしれません。
Zoom AI Servicesで音声を文字起こしし、次の行動へ整理することで、消えていた面接後の記憶を、自分の成長履歴へ変えられるのではないかと考えました。
本記事では設計までとなりましたが、実装する際には、文字起こしや要約の精度だけではなく、
本当に次の面接で回答が改善したか
まで検証したいです。