「文字起こし → 要約」だけなら難しくない。難しいのは、それを日本の会議で実務に耐える議事録にするところでした。個人開発で作りながら、特に効いた設計判断を3つに絞って書きます。
1. 出力を「文書フォーマット」に寄せる
自由記述の要約ではなく、決定事項 / アクションアイテム（誰が・何を・いつまでに）/ 論点 を構造で固定する。フォーマットを決め打ちにするほど、後工程（共有・タスク化・検索）が楽になります。要約の「うまさ」より、構造の「揺れなさ」のほうが実務では効きました。
2. 話者と敬語のレジスタを保持する
誰の発言かを保ったまま、です・ます／である のトーンを崩さない。ここが崩れると、一気に「議事録っぽさ」が消えて手直しが増えます。話者分離と文体の一貫性は、日本語の議事録では「精度」と同じくらい体験を左右しました。
3. データ経路を先に「設計要件」として決める
どこで処理し、どこに保管し、いつ消すか。後から機能を足しても破綻しないよう、保管は国内リージョン、音声は文字起こし後に削除、を最初に決めておく。「あとで考える」にすると、機能追加のたびにデータ経路が複雑化して詰みます。
根っこにある動機は「会議のあとの“まとめる作業”に奪われる時間を減らしたい」で、上の3つはそのための手段です。実装の細部（プロンプト設計・話者分離の扱いなど）は、別記事で掘り下げていきます。