議事録をAIが要約し要件定義書ドラフトを自動生成する仕組み——ヒアリングの再現性をどう作るか

「あの打ち合わせで何を決めたんでしたっけ」——要件定義の終盤になって、こんな一言から仕様の手戻りが始まった経験はないでしょうか。議事録はあるのに、決定事項と検討中の話が入り混じり、結局は当日同席した担当者の記憶が頼りになる。そんな状態が、多くの中小企業のシステム開発現場で起きています。

要件定義はなぜ「聞いた人にしか分からない」ものになりやすいのか

原因① 議事録が「発言の記録」で止まっている

多くの現場では、議事録は発言を時系列に書き起こしただけのメモです。「誰が」「何を」「どう決めたか」が構造化されておらず、後から読んでも要件として拾いにくい状態になっています。

原因② ヒアリング担当者の解釈がそのまま仕様になる

担当者が現場の言葉を自分なりに翻訳して仕様書に落とし込むため、同じ打ち合わせに同席していても、書く人が変われば要件定義書の粒度や解釈が変わってしまいます。これが「聞いた人にしか分からない」要件定義を生む最大の要因です。

中小製造業向けの業務システム開発では、この属人的なヒアリングが要件漏れや手戻りの温床になりやすいと指摘されています。担当者の記憶や解釈に依存する初期フェーズを、いかに再現性のあるプロセスに変えるかが、開発スピードと精度を左右します。

打ち合わせ議事録をAIが要約し要件定義書ドラフトへ変換する仕組み

この課題に対して、生成AI（人間の自然な文章を生成できるAI技術）を使い、議事録の要約から要件定義書ドラフトまでを一気通貫でつなぐ仕組みが注目されています。弊社が開発を支援する現場では、自社開発の仕組みを使用しているとされており、以下のような流れを構築した例があります。

打ち合わせ音声・テキストをアップロード

ヒアリング時の録音データ、またはメモ書きのテキストを専用画面の「議事録取り込み」ボタンからアップロードします。ファイル名は自動で「打ち合わせ日_案件名.txt」形式に整形されます。

AIが発言を要件・課題・保留事項に分類

AIが発言内容を解析し、「決定事項」「検討中の課題」「未確定の要望」の3カテゴリに自動で振り分けます。これにより、誰が読んでも同じ粒度で打ち合わせ内容を把握できるようになります。

要件定義書ドラフトを自動生成

分類されたデータをもとに、入力項目・画面構成・処理フローの骨子を含む要件定義書ドラフトが自動生成され、「ドラフト確認画面」に表示されます。担当者はここで加筆・修正を行うだけで済みます。

現場の生々しい言葉を拾うことで見えてくる自動化できる業務の輪郭

議事録の中には「毎回この転記が面倒で」「この確認作業、実は誰も見ていない」といった現場の本音が埋もれています。これらの生々しい言葉こそが、自動化すべき業務の輪郭を浮かび上がらせる重要な手がかりです。

Before（紙・Excelの議事録運用）
打ち合わせ後、担当者が手書きメモやICレコーダーの内容を聞き直しながらExcelに議事録をまとめる。決定事項と雑談が混在し、要件として使える形に整理するまでに半日かかることも珍しくありません。次の打ち合わせまでに整理が終わらず、記憶を頼りに要件定義書の下書きを作るケースもあります。

After（AI要約・要件定義自動生成アプリの画面上での動き）
「議事録取り込み」ボタンからテキストをアップロードすると、数分で「決定事項一覧」「未確定要望一覧」がタブ表示されます。担当者は「要件定義ドラフト生成」ボタンを押すだけで、入力項目・画面遷移案を含んだドラフトファイル「要件定義書_v0.docx」が自動出力されます。転記工程がまるごと1本減り、二重入力もなくなります。

議事録要約から試作画面提示までのプロセス設計

要件定義書ドラフトの生成で終わらせず、そこからさらに一歩進めて、簡易的な試作画面（プロトタイプ）を提示するところまでをプロセスに組み込む設計が有効です。弊社の開発現場では、Anomalyという基盤を用いているとされており、ドラフトの入力項目定義から画面イメージを自動生成し、「画面プレビュー」画面で発注者に確認してもらう流れを取っています。

文章だけの要件定義書では「思っていたのと違う」がなくならない。
試作画面を見せることで、はじめて現場の人が「あ、これじゃない」と気づける。

この試作画面提示のステップを挟むことで、要件定義書の文言の解釈違いが可視化され、開発着手前に認識のズレを解消できます。結果として、開発フェーズに入ってからの仕様変更依頼が減り、手戻りのリスクを前工程で潰せるようになります。