打ち合わせの文字起こしから、要件の抜け漏れをAIで見つけられるか試してみた

システムを作る前の打ち合わせでは、話を聞いているうちに、確かめるべきことを聞き忘れることがあります。件数を「たくさん」のまま流してしまった。参加者の言うことが少し食い違っていたのに、その場で詰めなかった。あとで見積もりや設計に進んでから、「そういえば、あれはどうするんだっけ」となります。

いまは、打ち合わせを録音して文字起こしをするのが珍しくなくなりました。文字起こしがあるなら、生成AIに読ませて「抜けていること」を挙げさせればよいのではないか。そう考えて、実際に試してみました。

結論から書くと、仕込んだ12個の抜け漏れは、9回ともすべて見つかりました。困ったのは見落としではなく、話に出ていないだけのことを、「決まっていない」と言い切る書き方です。9回のうち6回で起きました。

この記事では、次のことを順に書きます。

• 何を、どう試したか
• 結果：見つけたもの、見つけすぎたもの、言い切ったもの
• 条件を厳しくしても、見つけられたか
• AIの指摘を使うときの決まり
• 録音や文字起こしをAIに入れる前に確かめること
• 同じ確認を自社で行う手順と、この試しの限界

何を、どう試したか

架空の打ち合わせを用意した

本物のお客さまの打ち合わせは使っていません。お客さまの情報をAIに入れることになるうえ、記事に載せられないからです。代わりに、架空の打ち合わせの文字起こしを用意しました。

設定は、機械部品の卸の会社（A社）と開発会社の初回の打ち合わせです。A社からは営業部長と受注担当、開発会社からは担当者が出ています。A社は、FAXと電話で受けた注文をExcelの台帳に打ち込んでいて、その手間を減らしたいと考えています。打ち合わせの長さは、約30分の抜粋という想定です。

試した文字起こし

AIに渡した文字起こしの全文です（①と②で使ったもの）。読みながら、抜け漏れがいくつあるか、先に数えてみてください。

開発：本日はありがとうございます。まず、いまの受注の流れから教えていただけますか。
部長：はい。うちは機械部品の卸で、お客さんから注文をもらって、メーカーから仕入れて納めています。注文はいま、ほとんどFAXと電話です。それを受注担当がExcelの受注台帳に打ち込んでいます。
開発：受注担当の方は何名いらっしゃいますか。
担当：私を入れて3名です。
開発：得意先はどのくらいありますか。
部長：取引のある得意先は約180社です。
開発：注文の件数はどのくらいでしょう。
部長：かなり多いですね。忙しい時期はもう、たくさん来ます。
開発：1件を台帳に入れるのに、どのくらい時間がかかっていますか。
担当：結構かかります。品番が長いので、見間違えると大変で。
部長：今回、いちばんやりたいのは、FAXをなくすことなんです。お客さんにWebから注文してもらえれば、打ち込みがなくなるので。
担当：ただ、FAXでしか注文しないお客さんも、けっこういらっしゃるので、FAXは残ると思います。
部長：まあ、そこはお願いすれば変えてもらえるでしょう。
開発：なるほど。単価はどう決めていますか。
担当：得意先ごとに単価が違います。単価表は田中さんが全部わかっているので、迷ったら田中さんに聞いています。
開発：値引きをすることはありますか。
部長：ありますね。営業の判断で、その場で下げることもあります。
開発：在庫が足りないときは、どうしていますか。
担当：欠品のときは、まあ、なんとかしています。メーカーに電話したり、お客さんに待ってもらったり。
開発：請求はどのようにしていますか。
担当：毎月20日締めで、月末に請求書を出しています。
部長：会計は弥生を使っているので、あとで連携できればいいですね。
開発：倉庫の方も、このシステムを使われますか。
部長：倉庫でも、タブレットで出荷する分を見られるとうれしいです。
開発：いつごろから使い始めたいとお考えですか。
部長：来年の4月から使いたいです。新しい期の始まりなので。
担当：3月は決算で一年でいちばん忙しいので、その時期は正直、ほかのことに手が回らないです。
開発：今回のシステムで、何がどうなればうまくいったと言えそうでしょうか。
部長：とにかく、みんなが楽になればいいです。
開発：ご予算や、最終的にお決めになる方については。
部長：社長に上げて決めます。まずは見積もりを見てから考えます。
開発：承知しました。次回までに、いただいた内容を整理してお送りします。

一見すると、ふつうに話が進んだ打ち合わせです。相手の答えに対して、開発会社の担当者は「なるほど」「承知しました」と受け止め、次の質問に移っています。ところが、答えの中身を見ると、数字が出ていない、二人の言うことがずれている、話が途中で止まっている、といった所がいくつもあります。こうした所は、その場では流れてしまいやすいものです。

抜け漏れを先に決めて、答えを固定した

この試しでいちばん気をつけたのは、AIに探させる前に、正解を決めて固定しておくことです。あとから答えを見て「これも見つけたことにしよう」と判断を変えると、結果が甘くなります。

抜け漏れの種類は、クリーヴァがヒアリングで確かめている観点から選びました。数字で聞けているか、普段と違うときの扱いを聞けているか、特定の人に頼っていることはないか、使う人と場所を聞けているか、といった観点です。仕込んだのは次の12個です。

あわせて、文字起こしの中ではっきり話したことを4つ決めました。受注担当は3名、得意先は約180社、締めは毎月20日、いまはFAX・電話・Excelで受けている、の4つです。AIがこれを「分からない」と挙げたら、誤りとして数えます。

頼み方と条件を変えて、9回探させた

使ったのは、Anthropic社の生成AI「Claude」（Opus 5.5）です。2026年11月1日に試しました。AIには過去のやり取りや、ほかの資料を一切読ませず、文字起こしと頼み方の文章だけを渡しています。同じ条件でも答えが毎回少しずつ変わるので、1つの条件で3回ずつ探させました。

ふつうの頼み方は、「次の打ち合わせの文字起こしを読んで、システムの要件として抜けていること・あいまいなことを挙げてください」の1文だけです。観点のリストを渡す頼み方では、量・食い違い・例外・権限など11の観点を並べ、根拠となる発言と、次回聞く質問の例を付けるよう頼みました。どちらの文章も、記事の後半に載せています。

結果①：12個は、9回とも全部見つかった

結果は、次のとおりです。

正直に書くと、予想していたより、ずっとよく見つけました。件数や時間のような「数字がない」ものだけでなく、部長と担当のFAXの食い違い、4月の開始と3月の繁忙期のぶつかりのように、2つの発言を結び付けないと気づけないものも、毎回挙がっています。

はっきり話したこと4つを「分からない」と挙げた回も、ありませんでした。「得意先180社のうち、FAXでしか注文しない会社は何社か」のように、話されたことをもとにさらに細かく聞く提案はありましたが、これは誤りではなく、妥当な深掘りです。

結果②：正解表にない指摘も、役に立った

12個のほかに、こちらで仕込んでいなかったのに、もっともだと思える指摘がいくつもありました。

• 電話の注文の扱い：冒頭で「注文はほとんどFAXと電話」と言っているのに、電話で受けた注文をどう扱うかは、そのあと話に出ていない。9回すべてが、電話の注文の扱いや割合を確かめる必要に触れました。
• 仕入れ（メーカーへの発注）を対象に入れるか：「メーカーから仕入れて納めています」とは話しているが、メーカーへの発注をシステムの対象に入れるかは話していない。
• 返品・取り消し・注文の変更：例外として話に出ていない。
• 田中さんに次回出てもらう：単価が分かる田中さんに、直接話を聞けていない。
• 締め日の途中での切り替え：20日締めなので、4月1日に切り替えると、3月21日〜4月20日の締めの途中で新旧の仕組みをまたぐ。①と②の6回のうち5回が指摘しました。

最後の切り替えの話は、仕込んだ側も考えていなかった論点です。こうした「人が見落としていた問い」が出てくるのは、AIに読ませる大きな利点だと感じました。

AIが挙げた質問の例

観点のリストを渡した回は、指摘ごとに「次回聞く質問の例」を付けていました。そのまま使えそうなものも多くありました。ある回が挙げた質問から、いくつか紹介します。

• 「FAXでしか注文されない得意先は、180社のうち何社くらいですか。そのうちWebに切り替えてもらえそうなのは何社ですか。」
• 「いちばん減らしたいのは、入力の時間ですか、それとも入力の間違いですか。」
• 「担当の方が迷って田中さんに聞くのは、どんなときですか（新しい品番、量による値引きなど）。」
• 「3月が忙しいのは、御社の決算作業のためですか。それとも得意先からの注文が増えるからですか。」
• 「4月が新しい期の始まり、というのは絶対の条件ですか。たとえば4月は一部の機能だけ、という形でもよいですか。」

2つ目の質問は、部長が「打ち込みの手間」を、担当が「品番の見間違い」を困りごととして挙げていることに気づいたうえでの質問でした。困りごとが入力の時間なのか、間違いなのかで、作るものの重点は変わります。4つ目は、「3月は決算で忙しい」という一言が、A社自身の決算の作業なのか、得意先の年度末で注文が増えるのかを区別していません。こちらも、仕込んだ側が意図していなかった、もっともな問いです。

数字を聞く質問が「何件くらいですか」で終わらず、「普段の月と忙しい月で」のように比べる形になっていたのも、使いやすい点でした。繁忙期の件数が分からないと、システムの大きさを決められないからです。

結果③：困ったのは、「話に出ていない」を「決まっていない」と言い切ること

一方で、そのまま相手に渡すと困る書き方がありました。たとえば、ある回はこう書いています。

「なんとかしている」だけで、手順が決まっていない

文字起こしで分かるのは、欠品のときの手順が打ち合わせで話に出なかったことだけです。A社の中には、きちんとした手順があるかもしれません。それを「決まっていない」と書いた資料を相手に送ると、相手の業務を決めつけることになります。値引きについても、「誰がどこまで値引きしてよいかが決まっていない」と書いた回がありました。実際には、社内に決まりがあるのに、打ち合わせで話さなかっただけかもしれません。

こうした言い切りは、9回のうち6回で見つかりました。頼み方を変えても、文字起こしの条件を変えても、なくなりませんでした。

もう1つ、読み違えもありました。文字起こしでは「単価表は田中さんが全部わかっている」と言っていて、単価表そのものはあると読めます。ところが、ある回は「単価表が田中さんの頭の中にしかなく」と書いていました。ほかの回は「単価表は紙か、Excelか、頭の中か」と質問の形にしていたので、AIの答えは回によって確かさが違う、ということでもあります。

打ち合わせのあとに作る資料は、相手と認識を合わせるためのものです。「話に出なかったこと」と「決まっていないこと」は、分けて書く必要があります。

結果④：観点を渡すと確かめやすくなるが、量は倍になる

観点のリストを渡した②の3回は、それぞれの指摘に、根拠となる発言を引用していました。引用は3回で合わせて58か所ありましたが、文字起こしと照らし合わせると、58か所すべてが原文どおりで、話した人も正しく付いていました。根拠が付いていると、指摘が正しいかを人が確かめるのが速くなります。

その代わり、答えは長くなりました。

160行を超える確認事項は、そのままでは次回の打ち合わせで使えません。1時間の打ち合わせで聞けるのは、十数問ほどです。どれを先に聞くかを選ぶのは、人の仕事として残ります。

結果⑤：話者の名前がなく、誤変換があっても見つけられた

実際の自動文字起こしは、整った文章にはなりません。話者は「話者1」「話者2」のように番号になり、言いよどみや誤変換が入り、本題と関係のない雑談も混ざります。③では、そうした文字起こしを想定して、次のように崩しました。

• 話者の名前を消して、「話者1〜3」にした
• 「えー」「あのー」などの言いよどみを入れた
• 「品番」を「品板」、「欠品」を「結品」、「締め」を「閉め」、「田中さん」を「田中産」、「弥生」を「やよい」と、誤変換を5か所入れた
• 駅や天気、倉庫の屋根を直した話など、雑談を入れた

それでも、3回とも12個をすべて見つけました。誤変換5か所は、3回とも「誤変換と思われる箇所」として表にまとめ、正しい言葉を推定していました。話者についても、2回は、「私を入れて3名です」と答えた人を受注担当だと推定していました。雑談を、要件とは関係がないとして外したと書いた回もありました。

ただし、この崩し方は、こちらで手を入れた架空のものです。実際の録音から作った文字起こしで、どれくらい誤変換が出るかは測っていません。

AIの指摘を使うときの決まり

試した結果から、打ち合わせの文字起こしをAIに読ませるときは、次の3つを決まりにするのがよいと考えています。

1. AIの指摘は「質問の候補」として扱う

AIの答えは、「抜け漏れの一覧」ではなく、次回聞く質問の候補として受け取ります。相手の業務について何かを言い切った文は、そのまま資料に入れません。「〜は決まっていない」は「〜について、まだうかがえていません」に、「〜がない」は「〜はありますか」に書き直します。

2. 根拠の発言を付けさせて、人が確かめる

観点のリストを渡して、根拠となる発言を引用させると、確かめる手間が減ります。指摘ごとに、文字起こしのどの発言から言えることかを見て、発言に書かれていないことを足していないかを確かめます。今回は引用の誤りはありませんでしたが、いつもそうとは限りません。

3. 次回聞くことは、人が絞る

AIの答えは、長いと160行を超えます。次回の打ち合わせで聞くのは、見積もりや設計の方針を左右するものに絞ります。今回の例なら、FAXを残すかどうか、4月の開始が必須かどうか、予算の目安、の3つが先です。この3つで、作る範囲が大きく変わるからです。件数や時間のような数字は、打ち合わせの場で聞くより、事前に書いてもらうほうが早いこともあります。

打ち合わせの前に何を用意しておくとよいかは、開発会社に初めて相談する前に：用意しておく資料と、決めておくことにまとめています。要件定義で社内が決めておくことは、要件定義とは：開発会社に頼む前に、社内でまとめておくことで整理しました。

録音や文字起こしをAIに入れる前に確かめること

今回は架空の打ち合わせなので問題になりませんが、本物の打ち合わせの録音や文字起こしをAIに入れるときは、先に確かめることがあります。

相手との約束

打ち合わせでは、相手の会社の業務や数字、取引先の名前が話されます。秘密保持の約束を結んでいる場合は、その内容で、外部のサービスに入れてよいかを確かめます。録音すること自体も、始める前に相手に伝えて了解を得ておきます。

個人情報

文字起こしには、参加者の名前や、取引先の担当者の名前が入ることがあります。個人情報保護委員会は、事業者が生成AIサービスに個人情報を含む指示を入力する場合、利用目的の範囲内であるかを十分に確かめること、また、入力した個人データが応答の出力以外の目的で扱われる場合は法に違反するおそれがあるため、そのサービスが機械学習に使わないことなどを確かめるよう注意を呼びかけています（個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（2023年6月2日））。

入れる前に、人の名前を「部長」「担当」のような役割に置き換えるだけでも、気をつけることはかなり減ります。今回の③でも、話者の名前がない文字起こしで、役割を推定しながら抜け漏れを見つけられていました。

AI議事録のサービスを選ぶときの確認点は、SucSakの「AI議事録のセキュリティとは？会議データを守る導入前の確認点」にまとまっています。要件定義全体でAIをどこまで使えるかの一般的な整理は、「要件定義にAIはどこまで使える？発注側の活用範囲と注意点」が参考になります。

同じ確認を、自社で行う手順

自社の打ち合わせで試すときは、次の順で進めます。

1. 文字起こしを用意する：録音の文字起こし機能や、オンライン会議の文字起こしを使います。相手の了解と、秘密保持の約束を先に確かめます。
2. 名前を役割に置き換える：人の名前や会社名を「部長」「担当」「取引先A」のように置き換えます。
3. 観点のリストを付けて頼む：下の頼み方の文章に、文字起こしを続けて貼ります。
4. 根拠の発言を確かめる：指摘ごとに、引用された発言が文字起こしにあるか、発言にないことを足していないかを見ます。
5. 言い切りを質問に書き直す：「決まっていない」「ない」と書かれた文を、「うかがえていません」「ありますか」に直します。
6. 次回聞くことを3〜5個に絞る：作る範囲や時期を左右するものを先にします。数字は事前に書いてもらう依頼にまわします。

今回使った頼み方の文章は、次のとおりです。まずは、ふつうの頼み方です。

次の打ち合わせの文字起こしを読んで、システムの要件として抜けていること・あいまいなことを挙げてください。

観点のリストを渡す頼み方は、次のとおりです。観点は、自社の業務に合わせて足したり減らしたりしてください。

次の打ち合わせの文字起こしを読んで、システムの要件として抜けていること・あいまいなことを挙げてください。
次の観点で、1つずつ確かめてください。
1. 量：件数・時間・人数などが、数字で話されているか
2. 食い違い：参加者どうしで、言っていることがずれていないか
3. 例外：普段と違うとき（欠品・急ぎ・取り消しなど）の扱い
4. 権限：誰が何を決められるか、承認が要るか
5. 一人に頼っていること：特定の人しか分からないこと
6. 使う人と場所：誰が、どこで、どの端末で使うか
7. いまのデータ：いま使っているデータを、どう引き継ぐか
8. ほかのシステム：つなぐ相手と、それが必須かどうか
9. 時期：使い始めたい時期と、準備の時期がぶつからないか
10. 成功の基準：何がどうなればよいかが、測れる形で決まっているか
11. 予算と決め方：予算の目安と、誰がいつ決めるか
文字起こしで、はっきり話されていることは「抜け」に入れないでください。
各項目に、根拠となる発言と、次回聞く質問の例を付けてください。

今回の結果を踏まえるなら、最後に「話に出ていないことは『決まっていない』と書かず、『話に出ていない』と書いてください」と1行足すのも一つの手です。ただし、この1行で言い切りがなくなるかは、今回は試していません。足した場合も、手順の5で人が確かめる前提で使ってください。

打ち合わせの中身を、業務の流れに整理するところから始めたい場合は、業務の流れを図にする：システム化の前に整理することも参考になります。

この試しの限界

今回の結果は、次の条件のもとでのものです。

• 文字起こしは架空で、短い：約30分の抜粋を想定した短いものです。実際の打ち合わせは1時間を超えることも多く、話題があちこちに飛びます。長くなると、見落としが出る可能性があります。
• 仕込んだ側が、観点を知っている：抜け漏れは、クリーヴァがヒアリングで確かめている観点から選びました。観点のリストも同じ考え方で作っています。②の頼み方は、答えの種類を知っている側が書いた頼み方だとも言えます。ただし、観点を渡さない①でも12個すべてを見つけているので、結果が観点のリストのおかげだけ、ということではありません。
• 抜け漏れに、目印になる言葉がある：仕込んだ抜け漏れの多くには、「たくさん」「結構かかります」「なんとかしています」「できればいい」「うれしい」「楽になれば」のように、あいまいさが分かる言葉が付いています。実際の打ち合わせでは、抜け漏れがこれほど分かりやすい言葉で表れるとは限りません。12個すべてを見つけたという結果は、見つけやすい条件での結果だと考えてください。
• AIは1つ、回数は少ない：使ったのは1つのAIで、条件ごとに3回です。別のAIや、別の時期のモデルでは結果が変わる可能性があります。
• 録音から文字起こしにする段階は、測っていない：今回試したのは、文字起こしを読ませる段階だけです。録音から文字起こしを作る段階でどれくらい誤変換が出るかは、使うサービスや録音の環境で大きく変わります。

おわりに

打ち合わせの文字起こしをAIに読ませると、今回の条件では、件数のあいまいさ、参加者どうしの食い違い、時期のぶつかりのような抜け漏れが、9回とも見つかりました。人が考えていなかった論点が出てくることもあります。実際の打ち合わせでは見落としも出ると考えたうえで、聞き忘れを減らす道具としては使えると感じました。

ただ、AIの答えは、相手の業務を決めつける書き方をすることがあり、量も多くなります。AIが挙げたものは「次に聞く質問の候補」として受け取り、根拠を確かめ、言い切りを質問に直し、先に聞くものを人が選ぶ。この一手間を入れれば、打ち合わせのあとの整理は、ずっと速く、漏れの少ないものになります。

要件定義を進めるうえでは、IPA（情報処理推進機構）も、システム開発の遅れの多くは要件定義の失敗にあると言われる、と書いています（IPA「ユーザのための要件定義ガイド 第2版」）。打ち合わせのたびに抜け漏れを一つずつ減らしていくことが、遠回りに見えて、いちばん確かな近道です。