技術設計面接の解説と模範解答｜議事録テイカー

技術設計面接（システムデザイン面接）のお題「議事録テイカー」を題材に、事前に押さえておく知識、面接で引き出せる前提、論点、模範解答、よくあるつまずきを順に解説します。

ほかのお題の解説は技術設計面接の解説と模範解答まとめにあります。

この記事で使う設計の基礎は、日本語のシステムデザイン面接の教材 SystemDesign InterviewCat で詳しく学べます。この記事の各節に関係する章は次のとおりです。

設計面接では、お題を聞いた時点で「たぶんこの作りだろう」という仮説を持ち、前提を聞くたびにそれを確かめたり崩したりします。議事録のお題なら、まず「録音をいつ、どの単位で文字にするか」の選択肢を押さえておきます。会議が終わってからまとめて処理するか、会議中から少しずつ処理するかの選択で、要約が届くまでの時間がほぼ決まるためです。

録音が議事録になるまでの流れ

録音は次の順に処理されて議事録になります。どの方式でも、文字にして、話者を分けて、要約する順番は同じです。違うのは、それをいつ、どの大きさで動かすかです。

• ASR：音声認識（Automatic Speech Recognition）。音声を文字にする処理で、今回は外部の API を使う
• 話者分離：録音のどの時間帯を誰が話したかを分ける処理。分かるのは「話者 A」「話者 B」の区別までで、名前は別に付ける
• チャンク：録音を区切ってできた数分ほどの断片。区切ってから先の処理は、チャンクを単位に進める

ASR、話者分離、要約は、どれも録音や文字起こしの長さにおおむね比例して時間がかかります。そのため、終了のあとに残る仕事を短くするには、終了より前に済ませるか、終了のあとに並べて同時に進めるかのどちらかが要ります。

それぞれの方式で何が起きるか

同じ 3 時間の会議を処理するとき、方式ごとに裏で起きることを並べます。

会議後に一括：会議が終わって録音がそろったら、録音全体を 1 本のまま ASR に渡し、返ってきた文字起こし全体を LLM で要約します。仕組みが一番単純で、録音全体を見て処理できるので話者の区別もそろいます。弱いところは、待ち時間が録音の長さと外部 API の速さに任せきりになることです。途中で失敗すると最初からやり直しで、ファイルの大きさの上限で 1 本では渡せないこともあります。

会議後に区切って並列：録音がそろったら、無音の位置でチャンクに区切り、チャンクごとの ASR を同時に進めます。チャンクが 10 個なら、ASR にかかる時間はおよそ 1 個分で済みます。失敗したチャンクだけをやり直せます。一括と比べた弱みは 2 つあります。区切りの境目で語や文が切れやすいことと、チャンクごとに話者分離をすると、あるチャンクの「話者 A」と次のチャンクの「話者 A」が同じ人とは限らないことです。会議の終了が集中する時間帯には、並列に動かす数が一気に増えます。

会議中から少しずつ：会議中に数分ごとのチャンクを受け取り、受け取ったそばから ASR を済ませておきます。終了の時点で残るのは、最後のチャンクと全体の要約だけなので、会議の長さに関わらず待ち時間が短くなります。途中までの文字起こしがあるので、会議中に途中までの要約を見せることもできます。チャンクに区切るので、境目で語が切れることと、チャンクごとに話者分離をしたときの話者のずれは、区切って並列と同じ弱みです。もう 1 つの弱みは、会議中に音声を受け取る手段が要ることです。会議ツールの録音は多くの場合、会議が終わってから取り出せるようになります。会議中の音声は、ボットを会議に参加させるか、会議ツールが会議中の音声をアプリへ渡す仕組みを使って受け取り、どちらも会議ツールごとに作りが違います。

リアルタイム字幕（ストリーミング ASR）：発話のたびに 1 秒以内で文字にして返し続けます。会議中の字幕や音声アシスタントに向いています。後で録音全体を見て処理する方式より精度が下がりやすく、話している間ずっと接続を保つ必要があります。議事録のように数分遅れてよい用途では、少しずつ処理する方式で足ります。

方式の名前より、比べたいのは、録音をどの大きさに区切り、終了の前と後のどちらで文字にするかです。チャンクを単位にしておけば、録音が終了後にまとめて届いても、会議中に少しずつ届いても、区切ってから先は同じ仕組みで処理できます。

方式を比べる

方式の違いは、「3 時間の会議が終わったとき」と「会議の終了が集中したとき」の 2 つの場面に、「会議中に要約を見せられるか」を加えて比べると分かりやすくなります。

表から分かるとおり、待ち時間を短くする方法は、終了後の仕事を並べて同時に進めるか、終了前に済ませておくかの 2 つです。会議中から少しずつ処理する方式は両方の点で有利ですが、会議中に音声を受け取れることが条件になります。今回のお題では、音声の入り方がオンライン会議と対面とで違うので、方式を 1 つに決めるのではなく、入り方ごとに選ぶことになります。

最初の仮説

お題文だけを読んだ段階では、次の仮説を置きがちです。どれも筋は悪くありませんが、前提を聞くと一部が崩れます。答え合わせは「隠れていた前提を見直す」で行います。

面接官から示されるお題は次のとおりです。

本日はシステムの設計方法についてディスカッションしたいと思います。今、会議の議事録を自動で作るツールを作ることを考えています。Zoom・Teams・対面の会議を文字起こしして要約とタスクを作り、参加者が修正してから共有できるようにしたいです

▼このお題は CaseMatch の AI 面接で、面接官に前提を質問しながら練習できます。

前提は質問すれば答えてもらえます。面接で引き出せる前提を、音声をいつ処理するかの選び方に関わるものとそれ以外に分けて並べます。種類の列は、機能要件、非機能要件、制約、将来の要望のどれにあたるかです。値の列は面接官の答えそのままです。設計への影響の列は、次の節の問いを考えてから読んでください。

音声をいつ処理するかの選び方に関わる前提

事前知識の比較表の 3 つの比べ方（終了から要約までの時間、終了が集中したときの裏側の仕事、会議中に要約を見せられるか）と、音声の入り方、費用を決める前提です。

それ以外の前提

誤りの扱い、話者、保持と削除、権限のように、どの方式を選んでも別に設計が要る前提です。

お題文は「文字起こしして要約とタスクを作り、修正して共有する」としか言っていません。前提の表は、質問して初めて出てきたものです。設計への影響を見る前に、あらためて前提を読み直し、お題文の裏に何が隠れていたかを考えます。先に次の問いを考えてから、前提の表の「設計への影響」の列と見比べてください。

1. 前提のうち、互いにぶつかっている 2 つの組を 3 組挙げてください。
2. 3 時間の会議を終了後 10 分で処理し終えるには、録音の何倍の速さが要りますか。その速さを出す方法を 2 つ挙げてください。
3. 最初の仮説 1〜4 のうち、どれがどの前提で崩れますか。
4. お題文からは読み取れなかったのに、設計を一番大きく変えた前提はどれですか。

前提どうしのぶつかり

前提の多くは単独では難しくありません。難しいのは 2 つが互いに逆を向いているところで、このお題では次の 3 組です。これがそのまま、面接の後半で詳しく問われる 3 つの論点（深掘り）になります。

仮説の答え合わせ

このお題は録音を AI に渡すだけのツールに見えます。しかし実際に問われるのは、3 時間の会議を終了後 10 分で、しかも社名や期日を誤らずに主催者へ届けるために、録音と文字起こしをどこで区切り、何を別に取り出すかの設計です。

論点は 3 つあり、重さの順に音声処理の流れ、取りこぼさない要約、認識誤りの補い方です。音声処理の流れでは、取り込みから ASR、話者分離、要約までを終了後 10 分以内に収めるために、どこで区切って非同期にするかを説明できるかが問われます。続く 2 つは、長い会議の要約から決定事項やタスクを落とさない方法と、固有名詞や対面の話者の誤りを辞書と人の修正で補う方法です。Zoom や Teams との連携の細かい手順には深入りしなくて構いません。

模範解答の深掘り（5〜7）では、論点ごとに「弱い答え」「よい答え」「より良い答え」を並べ、何が足りないかを示しています。

面接での問答の順には合わせず、このお題への答えを 1 つの設計としてまとめた解答例です。設計の筋は、取り込み元がどこであっても録音を数分のチャンクにそろえ、チャンクごとの ASR を並列に進め、話者分離は録音全体で 1 回だけ行い、要約とは別に決定事項とタスクを取り出す、というものです。前提に無いことは仮定として置き、その旨を書いています。

1. 作る範囲

前提を確かめたうえで、最初に作る範囲を次のように切ります。

• 作る：Zoom と Teams の録音の取り込み、スマホアプリでの対面の録音、録音しない設定と録音の通知、ASR と話者分離、要約と決定事項とタスクの抽出、顧客ごとの用語辞書、主催者の修正画面、社内チャットとメールと社内 Wiki への共有、保持期間と削除
• 作らない：会議中のリアルタイム字幕、会議中の要約（後から足せる形にだけしておく）、ASR と LLM のモデルそのもの、会議ツールのアプリ内の画面

設計の要は、取り込み元を会議ツールごとに分け、チャンクにしてから先を 1 つの流れにそろえることです。

2. 見積もり

見積もりで出すのは、構成を決める 3 つの数字だけです。どれも前提の値から計算できます。

3. データモデル

文字起こしは発言の単位で持ち、要約やタスクの各項目は、根拠になった発言を指すようにします。中心になる表は次の 4 つです。

すべての表に顧客 ID か会議 ID を持たせるので、保持期限を過ぎたときや削除依頼が来たときは、会議 ID をたどって録音から議事録まで残らず消せます。ASR の結果を残しておくのは、主催者が何をどう直したかを辞書の改善に使うためです。

4. 全体構成

取り込み元は 3 つありますが、録音をチャンクにして置き場所に置き、ジョブキューに知らせてから先は、どの取り込み元でも同じ流れです。重い処理はすべてキューの先のワーカーで非同期に進めます。

色を付けた 3 つの部品（取り込み、ASR ワーカー、要約ワーカー）がこの設計の要で、待ち時間と誤りの多さはここで決まります。

1. 取り込み：Zoom は録音の準備ができたときの通知を、Teams は録音や文字起こしができたときの変更通知を受けて、録音を取りに行きます。スマホアプリは会議中から数分ごとのチャンクを送り、電波が弱くて送れない分は端末にためて、つながってから送ります。どの取り込み元でも、受け取る前に顧客の設定を見て、録音しない会議は取り込みません。
2. ストレージとジョブキュー：録音とチャンクをオブジェクトストレージに置いてから、チャンク 1 つを 1 件のジョブとしてキューに入れます。オンライン会議の録音は、取り込みで無音の位置で区切ってからチャンクにします。
3. ASR ワーカー：チャンクごとに外部の ASR API を呼び、結果をチャンクの番号つきで保存します。チャンクが並列に処理されるので、3 時間の会議でもかかる時間はチャンク数個分です。
4. 話者分離：録音全体がそろったら、録音全体に対して 1 回だけ行います。チャンクごとに行うと、チャンクをまたいで話者のラベルがそろわないためです。
5. 結合と要約ワーカー：ASR の結果と話者分離の結果を時刻で突き合わせて発言の列を作り、LLM で要約と、決定事項とタスクの抽出を別々に行います（6 の深掘り）。
6. 修正画面と共有：主催者は要約とタスクを、根拠の発言と並べて確かめて直し、直したものを共有します。共有先への送り出しはキューを通して非同期に行います。

録音の通知は取り込み元ごとに持たせます。スマホアプリは録音を始めるときに画面と音で知らせ、オンライン会議は会議ツールの録音機能が出す通知を使います。会議にボットを参加させる場合は、ボットが参加したこと自体が通知になります。

実例：Zoom は録音がダウンロードできるようになるたびに recording.completed の通知を送り、ダウンロード用の URL とトークンを渡します（Zoom Developer Blog）。Teams は、会議が終わって録音や文字起こしができたときに変更通知を送る仕組みを持ち、取り出すには組織全体の権限を管理者が認めるか、会議ごとの権限を使います（Microsoft Learn）。音声認識の API を提供する Gladia は、議事録ツールの既定を会議後に録音全体を処理する方式にし、ジョブを投げて完了の通知を受けてから LLM の処理を始める流れを勧めています（Gladia, 2026）。

代わりの案：Teams が会議後に作る文字起こしをそのまま取り込めば、ASR の費用と時間を省けます。ただし対面の会議には使えず、顧客の管理者がこの取り出しを止めている場合や、話者の情報を出さない設定にしている場合もあります。用語辞書も使えません。そのため、使える顧客では選べる取り込み元の 1 つにとどめ、標準は自前の ASR にします。

5. 深掘り：音声処理の流れ

録音は無音の位置でチャンクに区切って ASR を並列に進め、話者分離は録音全体で 1 回だけ行います。対面の会議は会議中からチャンクで受け取り、届いたそばから処理しておきます。最初の仮説の 1 は、ここで崩れます。

より良い答えの中身は次のとおりです。

• 無音の位置で区切る：VAD（録音のうち人が話している区間と無音の区間を見分ける処理）で無音の区間を見つけ、数分を目安に、話の途中ではなく無音のところで区切ります。発言の途中で切ると、境目の語が両方のチャンクで崩れます。話し続けて無音が来ない区間だけは決めた長さで切り、前後を数秒重ねて、重なった部分の文字は時刻を見て片方だけ残します。
• 無音を送らない：VAD で見つけた無音の区間は ASR に送りません。ASR は音声の長さで課金されるので、そのぶん費用が下がります。
• 話者分離は録音全体で 1 回：チャンクごとに話者分離をすると、チャンク 1 の「話者 A」とチャンク 2 の「話者 A」が同じ人か分かりません。ASR はチャンクごとに並列に進め、話者分離は録音全体に 1 回かけ、最後に語の時刻と話者の時間帯を突き合わせて発言に話者を付けます。話者数の上限は参加者の最大 20 名で渡せます。録音全体に 1 回かけても時間はかからず、pyannote.audio の README では GPU（NVIDIA H100）で音声 1 時間あたり約 31 秒なので、3 時間で 2 分弱です。
• ジョブはチャンク単位で、やり直しても結果は同じ：ジョブは会議 ID とチャンクの連番で決まり、結果もその組で保存します。同じジョブが 2 回届いても、結果があれば ASR を呼ばずに終えます。失敗したチャンクだけを再試行するので、3 時間の会議でも最初からやり直すことはありません。
• 締め切りの近い順に処理する：10〜11 時と 14〜16 時には会議の終了も集中します。キューは終了時刻の早い会議のチャンクから取り出し、ワーカーはキューの長さを見て増減します。会議中に届く対面のチャンクは締め切りが遠いので、後回しにできます。
• 最初に詰まるのは外部 API：ワーカーは増やせますが、外部の ASR API には同時に受け付ける数の上限があります。その上限を契約で確かめ、上限を超える分はキューで待たせます。1 年後の 20 倍に向けては、上限の引き上げか、2 社目の ASR を使えるようにしておくかを決めます。

対面の会議は、スマホアプリが会議中から数分ごとのチャンクを送るので、事前知識の「会議中から少しずつ」の方式になります。終了の時点で残る仕事は最後のチャンクの ASR、話者分離、要約だけです。電波が弱く録音後にまとめて届く場合は、終了後 10 分の起点をアップロードが終わった時点と置き、その旨を主催者の画面にも出します（前提に無いので仮定です）。

実例：WhisperX は、VAD で録音を発話のまとまりに区切ってから ASR をまとめて並列に流すことで、長い録音の文字起こしを約 12 倍速くし、精度も上げたと報告しています。区切らずに長い録音を流すと、ずれや繰り返しが起きやすいことも挙げています（WhisperX, 2023）。OpenAI の文字起こし API は 1 ファイル 25 MB までで、長い録音は分割するように、その際は文の途中で切ると精度が下がるので避けるように書いています（OpenAI）。

6. 深掘り：取りこぼさない要約

文字起こしは話題の区切りで分けて要約し、決定事項とタスクと担当者と期日は、要約の文章とは別に、決まった形式で取り出します。最初の仮説の 2 は、ここで崩れます。

• 話題の区切りで分け、前後を重ねる：長さだけで機械的に分けず、話題の変わり目で分けます。分けた区間には直前の区間の終わりを少し重ねて渡し、「さっきの件は来週までに」のような前を受けた発言が何を指すかを分かるようにします。
• 区間ごとと全体の 2 回で処理する：区間ごとに要点と、決定事項とタスクの候補を出し、最後に全体を見て重複をまとめます。同じタスクの期日が途中で変わったら、後の発言を採ります。
• 決まった形式で取り出す：決定事項とタスクは、本文、担当者、期日、根拠の発言 ID を持つ形式で出させ、形式に合わない出力は捨ててやり直します。明示された約束だけを取り、「誰かがやるだろう」のような推測のタスクは作らせません。
• 担当者と期日を確かめる：担当者は会議の参加者の名前と突き合わせ、合わなければ印を付けます。期日は「来週の金曜」のような言い方を会議の日付から日付に直し、元の言い方も残します。社名は用語辞書と突き合わせます。この 3 項目の誤りが問題になるので、印の付いた項目を修正画面の先頭に出します。
• 根拠の発言に戻れるようにする：各項目は根拠の発言 ID を持つので、主催者は項目を押すとその発言と録音の該当箇所を確かめられます。録音全体を聞き直さずに済むので、修正の時間が短くなります。

要約は ASR がすべて終わってから始めると、その分だけ待ち時間が延びます。区間ごとの要約は、その区間の発言がそろった時点で始められるので、対面の会議のように会議中にチャンクが届く場合は、区間ごとの要約まで会議中に済ませておけます。最後の全体のまとめだけを終了後に行います。

実例：言語モデルは、入力の最初か最後にある情報はよく使えるが、長い入力の中ほどにある情報を使う性能は大きく下がるという報告があります（Lost in the Middle, 2023）。3 時間の文字起こしを 1 回で渡さない理由の 1 つです。Gladia は、議事録の要約やタスクを LLM に出させるときは出力を決まった形式に縛り、担当がはっきりした明示の約束だけを取り出すよう指示する例を示しています（Gladia, 2026）。

7. 深掘り：認識誤りの補い方

顧客ごとの用語辞書を、ASR に渡すヒントと、認識したあとの置き換えの 2 か所で使い、主催者が直した語を辞書に返します。最初の仮説の 3 は、ここで崩れます。

• ASR のヒントには絞って渡す：ASR の API が受け付けるヒントの量には上限があり、5,000 語をすべて渡せるとは限りません。会議のタイトル、参加者の所属、その顧客の過去の会議でよく出た語から、その会議に関係しそうな語を選んで渡します。
• 認識後に置き換える：ヒントに入らなかった語は、ASR の結果に対して辞書全体を使って直します。読みが近い語の置き換えは LLM に任せ、置き換えた箇所には印を残して主催者が確かめられるようにします。
• 主催者の修正を辞書に返す：ASR の結果と主催者が直した本文の差から、「ある語が決まった語に直された」組を集めます。同じ直しが何度も起きたら、その顧客の管理者に辞書への追加を提案します。勝手に足さないのは、1 人の直し方を顧客全体に広げないためです。
• 対面の話者は名前の付け替えで直す：マイク 1 本の対面の会議では、話者分離が「話者 A」「話者 B」を取り違えることがあります。主催者が「話者 A は山田さん」と 1 回指定すれば全部の発言に反映し、取り違えた発言だけは 1 件ずつ話者を変えられる画面にします。

英語が混ざる約 1 割の会議には、1 つの会議の中で言語が切り替わっても認識できる ASR を選び、辞書には英語の製品名も読みと一緒に入れられるようにします。

実例：Google Cloud の Speech-to-Text は、認識させたい語句の一覧（PhraseSet）と、その語句をどれだけ優先するかの重み（boost）を渡せます（Google Cloud）。Amazon Transcribe は、社名や製品名、略語などを登録するカスタム語彙を持ち、1 ファイル 50 KB までという上限があります（AWS）。OpenAI は、whisper-1 のヒント（prompt）は 224 トークンまでなので、長い語の一覧を使うなら認識後にテキストのモデルで直す方法を挙げています（OpenAI）。Google Cloud の話者分離は、語ごとに話者の番号を付け、想定する話者数の下限と上限を渡す作りです（Google Cloud）。

8. 障害への備えと監視

どこが止まっても、録音と途中までの結果は残り、止まったところから再開できるようにします。主催者に見えるのは要約が遅れることで、遅れるときはそのことを画面に出します。

監視するのは、会議の終了から要約が届くまでの時間（遅いほうの 5% を含めて）、キューの滞留、外部 API の失敗率、主催者が修正にかけた時間です。最後の数字は、修正を平均 10 分以内にする目標をそのまま測るものです。

9. 条件の変更への対応

面接の後半では、運用で起きた不具合や将来の要望という形で条件が足されます。答え方は、今の設計でなぜ起きたか、何をきっかけに何をどう処理して直すか、変えずに済むところはどこか、の順です。

例 1：削除依頼に応じたあとも、文字起こしの一部が残っていた

• 原因：録音と議事録は消したが、チャンク、ASR の結果、処理中だったジョブの出力、社内チャットに送った本文が残っていた。
• 直し方：削除依頼をきっかけに、会議 ID ごとの削除ジョブをキューに入れ、会議に結び付く保存先を順に消します。ワーカーは結果を保存する前に会議の状態を見て、削除済みなら結果を捨てます。削除ジョブも失敗したら再試行し、同じ会議を 2 回消しても結果は変わらないようにします。共有先には本文ではなく議事録へのリンクを送り、本文はこちらで消せるようにします。
• 変えずに済むところ：取り込みから要約までの流れです。すべての表が会議 ID を持っているので、消す対象はたどれます。

例 2：大口顧客から、オンライン会議の途中でも要約を見たいと求められた

• 影響：Zoom と Teams の録音は会議が終わってから取り出せるので、会議中の音声は、ボットを会議に参加させるか、会議ツールが会議中の音声をアプリへ渡す仕組み（Zoom の Realtime Media Streams など）を使って受け取ります。どちらも会議ツールごとに作りが違います。
• 直し方：その顧客の会議では、どちらかの手段で会議中の音声を受け取り、数分ごとのチャンクにして取り込みに流します。ボットを使う場合は、ボットが参加したこと自体が参加者への録音の通知になります。チャンクから先は対面の会議と同じで、区間ごとの要約を会議中に積み上げて見せます。
• 変えずに済むところ：チャンクから先の流れ、データモデル、用語辞書です。増えるのは会議ツールごとの音声の受け取りなので、要望のある大口顧客から入れます。

実例：AWS の Live Meeting Assistant は、Zoom や Teams などの会議にボットを参加させて音声を受け取り、会議中に文字起こしと要約、タスクの作成を行う構成を公開しています（AWS, 2024）。Microsoft も、会議にボットを参加させて録音していることを示すバナーを出し、録音と文字起こしを取り出すアプリの作り方を例に挙げています（Microsoft Learn）。

まとめ：選んだものと捨てたもの

▼解説を読んだら、同じお題を AI 面接官を相手に通しで解いてみましょう。

技術ブログ、公式ドキュメント、論文です。どれも開いて内容を確かめています。Gladia と AWS の記事は自社の製品の紹介を兼ねています。

▼ほかのお題の解説

サカモトエンジニア監修

外資系企業のソフトウェアエンジニア。エンジニアのキャリアや面接について X や note で発信し、テック企業を目指すエンジニア向けの面接対策プラットフォーム InterviewCat を運営しています。