AI が議事録を書く時代は、会議で結論から話す

会議で「たぶん、なんとかなるかな」と話すと、AI が作った議事録には「今週中に完了予定」と書かれます。AI 駆動開発の研修を担当するなかで、受講者やお客様から「改めて大事だと思った」と言われることが多いのが、この結論から話すというごく当たり前の話です。会議の言葉が AI のインプットになった今、なぜ話し方がアウトプットの質を左右するのかを、同じ会議の 2 つの文字起こしを AI に渡した結果で示します。

AI 駆動開発では、レビューの回数だけ会話が増える

AI 駆動開発では、コードや資料をつくるのは AI で、レビューして判断するのは人です。生成が速くなり、複数の作業を並行で回せるようになると、つくる時間が減った分だけレビューの回数が増えます。1 本ずつ「指示・生成・レビュー」を回していたときはレビューも 1 本ごとに 1 回でしたが、3〜4 本を並行で回せば、同じ時間帯にレビューが重なります。

レビューは 1 回ごとに、報告・質問・回答・依頼のやりとりを伴います。相手はチームのこともあれば、顧客や上長、AI そのもののこともあります。1 回のやりとりで伝わらなければ確認の往復が生まれ、レビューの回数が増えるほど、その往復が積み上がります。逆に、1 回で合意して判断まで進められれば、開発全体が速く回ります。

会議の聞き手に AI が加わった

会議の言葉は、文字起こしを通して AI に読まれるようになりました。以前は誰かがメモを取って議事録を書いていましたが、今は Gemini や Teams の文字起こしが議事録の土台になっています。私自身も、文字起こしがない会議ではもう仕事が回らないと感じるほど頼っています。

文字起こしは議事録で終わりません。gaipack の AI 駆動開発では、ヒアリングの文字起こしを PRD（要件定義書）の入力にする流れを標準にしています。会議で話した言葉が、AI を経由して議事録・PRD・タスクといった成果物にそのまま変わっていきます。人に伝わる話し方に加えて、AI が読み違えない話し方が要るのはこのためです。

曖昧な文字起こしを AI に渡すと、推測で埋められる

AI は、分からないところを推測で埋めます。しかも、推測したことをそれらしく書きます。架空の定例会議の文字起こしを AI に渡して確かめてみます。指示は「決定事項・未確定事項・担当・期限を整理してください」です。

PO  ：通知のやつ、今週中にいけそうですか？
開発：あ、えっと、実装はだいたい終わってるんですけど、テストがちょっと押してて、
      あれの対応もあるので……たぶん、なんとかなるかなっていうイメージです。
PO  ：なるほど。あと、これって管理者にも飛ぶんでしたっけ？
PM  ：そこは、先週にあっちのMTGで話した〜な感じだと、たぶん〜な方向性だったかなと思います。
PO  ：了解です。じゃあ、あれはこちら側で確認しておきますね。
PM  ：お願いします。先月の例の件も、それに合わせて進めておきます。

AI が返した整理と、元の発言を並べると次のようになりました。

推測が「予定」や「方針」に格上げされ、未確定事項は「なし」になりました。この議事録をもとに PRD やタスクを作れば、決めていないことが決まったこととして次の工程に流れていきます。決めていないことは、AI が毎回推測で埋めます。

言葉だけで伝わる話し方

文字起こしに残るのは言葉だけで、画面共有も指差しも表情も残りません。研修では、言葉だけで伝わる話し方として次の 3 つを伝えています。確かめ方は「その場にいなかった人が、文字起こしだけで分かるか」です。

結論から話す

最初の一文で結論を言い切ります。質問されると詰められているように感じて、経緯や事情から話し始めたくなりますが、結論を後回しにすると相手は判断できず、追加の質問が増えます。AI も冒頭で結論を拾えず、推測で埋めることになります。結論・事実・解釈の順で言い切ったほうが、話は早く終わります。

質問に回答する

聞かれたことへの答えを先に置き、理由はその後に足します。「この機能は今週中に終わりますか？」と聞かれたら、まず「終わります」「終わる見込みです」と答えます。

見出しの直後に答えが書かれた記事のほうが AI に拾われやすい、という話を聞くことがありますが、会議の発言も同じ構造です。Yes / No で聞かれているのに背景から話し始める癖は、気を抜くとすぐに出ます。

こそあど言葉を減らす

「これ」「あれ」「例の件」は、文字起こしの上では何も指しません。主語・動詞・相手・対象を省かず、名前で言います。

「あれ、お願いします」では、誰が・何を・いつまでにやるのかが分からず、確認が返ってきます。「〇〇さん、PRD の §5 を△日 18 時までにレビューしてください」と言えば、受け手はそのまま着手できます。名前で言えば、人も AI も同じものを指せます。

結論から話すと、事実と推測と未確定が分かれる

結論を先に言おうとすると、その結論が確定なのか、推測なのか、未確定なのかを話す前に決めることになります。この 3 つを口に出す言葉で区別すると、AI もそのとおりに記録できます。

TBD の回答例に「いつ・何で確定するか」が入っている点に注目してください。gaipack の PRD でも、TBD には確認先・目標期日・担当者をセットで記録するルールを置いています。会議の時点でこの 3 つを口に出しておけば、文字起こしから PRD に移すときに埋め直す必要がありません。

考える順と話す順を入れ替える

事実と解釈を分けて整理するには、空・雨・傘のフレームワークが使えます。空は観測した事実、雨は事実から言える解釈、傘はどうするかの打ち手です。空が曇っていることだけが事実で、「雨が降りそう」も「傘を持っていこう」も解釈と判断にすぎません。3 つを混ぜて話すと、どこまでが事実でどこからが意見なのかが相手に伝わりません。

ポイントは、考えるときは空から、話すときは傘からという順序の入れ替えです。

話す前に空・雨・傘を整理しておけば、最初の一文で結論を言い切れます。フレームワークそのものの使い方は 空・雨・傘の仕事術 で詳しく扱っています。

同じ会議を結論から話して、もう一度 AI に渡す

3 つの話し方で同じ会議をやり直した文字起こしを、同じ指示で AI に渡します。

PO  ：期限通知の機能は、今週中に終わりますか？
開発：終わる見込みです。実装は完了しています。テストは2日遅れていますが、
      テスト担当を1名追加したので、金曜に完了する想定です。
PO  ：期限前日の通知は、管理者にも送りますか？
PM  ：未確定です。前回の定例では、担当者本人のみに送る案で止まっています。
      管理者にも送るかどうか、来週火曜までに御社でご判断いただけますか。
PO  ：承知しました。管理者にも送るかどうかを社内で確認し、来週火曜までに回答します。

今度は、AI の整理が発言の確度と一致しました。

確定した事実だけが決定事項に入り、見込みは根拠つきで、未確定事項は回答者と期限つきで残りました。担当と期限の欄もすべて埋まっています。変えたのは話し方だけで、AI への指示は 1 文字も変えていません。

まとめ

• AI 駆動開発でレビューが増えた分、報告・質問・回答・依頼のやりとりも増えます
• 文字起こしは議事録や PRD の入力になるので、「たぶん」は「予定」に、「あれ」は AI の言い換えに化けます
• 話し方は 3 つ: 結論から話す／質問に回答する／こそあど言葉を減らす
• Fact・Inferred・TBD は口に出す言葉で区別し、TBD には「いつ・何で確定するか」を添えます
• 空 → 雨 → 傘で考え、傘から話す

会議はすべて AI に読ませるインプットだ、という前提を持つと、話し方は自然と結論からに変わっていきます。こうした AI 時代の働き方の基礎は、AIDD キャンプ をはじめとする研修でもお伝えしています。会議の文字起こしから要件定義書を作る進め方は AIDD 要件定義 で紹介していますので、お気軽に KDDIアイレットへお問い合わせください。