【第8回】「考える力」を組織に残すという課題
Ryosuke Ishii
データパレード
AIの要約が浅いのは、渡している材料が足りないから
Ryosuke Ishii
会議の文字起こしをAIに渡しても、要約が物足りない。原因はモデルでもプロンプトでもなく、渡している材料でした。
プロジェクト台帳の作り方ノート①です。渡す材料・量の上限・モデルの使い分けを、設定値と失敗まで書きます。
先に、動いているところをご覧ください。
もくじ
この機能で何がよくなったか
会議が終わると、勝手に議事録ができています。しかも前回の議事録を踏まえて書かれます。「前回◯◯となっていた件は、今回こうなった」が最初から入っています。
打ち合わせのあとに要点をまとめる作業が、なくなりました。
文字起こしを2系統持っています
入力を2つ持っています。会議の字幕から保存されるものと、録音から起こされるもの。
理由は単純で、どちらも落ちるからです。片方が取れなかった日でも、もう片方があれば議事録は作れます。両方あればつなぎ合わせます。
片方だけでも動く作りにしておくのが前提です。両方そろわないと動かない作りにすると、そろわない日に何も残りません。
要約の質は、渡す材料で決まります
最初は、その日の文字起こしだけを渡していました。それだと「今日話したこと」しか書けません。読んでも、前回からどう動いたのかが分かりません。
いま渡しているのは3つです。
- その日の文字起こし
- 同じ案件の、過去の議事録
- 人の名簿（誰が何をしている人か）
2番を入れた瞬間、要約が変わりました。「前回未定だった期日が確定した」のような書き方になります。1回の会議だけを見ていては書けない文です。
材料には順番をつけています。いちばん上は自分のコメント
材料を並べるだけでは足りませんでした。どれを信じるかを決める必要があります。
いま最優先にしているのは、案件ページのコメント欄に自分が書いた1行です。議事録より、チャットより、前回の総括より上に置いています。理由は単純で、いちばん新しいからです。議事録は打ち合わせの時点の話でしかありません。
プロンプトには、こういう趣旨のことを書いてあります。
- 「解決済み」「対応済み」と書かれた論点は、もう未解決として書かない
- 「◯◯を確認すること」と書かれていたら、それを総括の次の一手に入れる
- 前回の総括が「急ぐ」と書いていても、コメントが解決を告げていればそちらを優先する
- 他の材料と食い違ったら、必ずコメントを正とする
最後の1つは、実際にぶつかりました。議事録には残っている論点を、こちらが場外で片付けてしまうことがあります。材料の新しさでは勝てないので、優先順位として明示するしかありませんでした。
名前の訂正だけは、AIの判断に任せていません
コメントで多いのが「この人は存在しない」「◯◯ではなく△△」という訂正です。文字起こしは人名をよく間違えます。
これを要約の指示として渡すと、たまに直し損ねます。「指摘があった」と書き足して、本文の誤った名前はそのまま残る、という失敗をしました。
いまは、人の名簿に照らして正しい名前が確定できるときだけ、本文のブロックを機械的に置き換えています。AIを通しません。判断でなく処理にできるものは、処理にしたほうが確実でした。
取り消しは「解決済み」にするだけです
指示を出したあと、それが終わったらコメントを解決済みにします。Notionのコメント欄にもとからある機能です。
材料として読み込んでいるのは未解決のコメントだけなので、チェックを付けた時点で翌日から材料に入らなくなります。「この指示はもう要りません」と書き足す必要がありません。
指示の有効期限を、こちらで管理しなくてよくなりました。 ここは作り込んだというより、もとからある機能の意味を決めただけですが、効果は大きいものでした。
何件・何字で切るか
ただし、過去の議事録を全部渡すわけにはいきません。上限を決めています。
- 関連する過去の議事録は 最大15件
- 1ファイルあたり 3万字
- 合計 10万字
この数字は、増やしても要約が良くならなくなったところで止めました。むしろ古い話に引っ張られて、直近の変化が薄まります。渡せば渡すほど良くなる、ということはありませんでした。
普段は軽いモデル、重い要約だけ上のモデル
全部を上のモデルでやる必要はありませんでした。
- 案件の判定、要否の選別、短い書き換え → 軽いモデル
- 議事録の要約 → 上のモデル
判定の精度は軽いモデルで十分足ります。足りないのは長い文脈をまたぐ要約のほうでした。
用途ごとに、出力の上限を切ります
出力の上限も用途ごとに変えています。
- 関係あるかの選別 → 80
- どの案件かの判定 → 200
- 案件ページの本文 → 1,400〜2,200
- 議事録の要約 → 8,000
上限を切ると、出力が引き締まります。 判定に200しか許さなければ、余計な説明が付きません。長く書ける枠を渡すと、長く書こうとします。
材料が変わっていない日は、AIを呼びません
これがいちばん効きました。
案件ページを組み直すとき、前回使った材料と今回の材料を突き合わせます。差分がなければ、生成そのものを飛ばします。
これを入れる前は、何も起きていない日でも全案件の本文を作り直していました。中身は前日と同じなのに、更新日時だけが毎日動きます。台帳を見ても「昨日何かあったのか」が分からない状態になっていました。
無駄な呼び出しが減っただけでなく、台帳が読みやすくなりました。 更新日時が動いていたら、本当に何かあった日ということになります。
週1でよいものは、週1に
頻度も分けています。
- やりとり、議事録 → 毎日
- 取引先の会社の動き → 7日間隔
- 人物像の更新 → 7日間隔
会社の公表情報が1日で変わることは、ほとんどありません。毎日見に行っても、同じものを読み直すだけになります。
2つの見出しは、1回の呼び出しでまとめて作ります
案件ページの「いまの状況」と「マイルストーン」は、材料が同じです。だから1回の出力で両方を書いてもらって、あとで切り分けています。
見出しごとに呼ぶと、同じ材料を2回読み込むことになります。上限を1,500から1,900に上げるだけで済みました。
2系統は、つないでから1本にします
2つの文字起こしを持っていると、次の問題が出ます。同じ会議が2回登録されます。
最初はそうなっていました。字幕から作った議事録と、録音から作った議事録が、別々の会議として並びます。読むほうからすると、同じ会議が2つあることになります。
いまは、先に2つを突き合わせて1本にしてから登録しています。片方にしかない発言は補い合う形で残します。冒頭に「どちらの記録から作ったか」を短く添えて、あとから追えるようにしてあります。
会議と会議を同じものだと判定するのは、開始時刻と題名で見ています。ここは予定表の情報を使います。
重要そうな部分が空だと、案件の要約に何も出ません
議事録の中から「重要なメモ」を抜き出して、案件ページの材料に渡しています。
あるとき、案件の要約に何も反映されない会議が出ました。議事録自体はちゃんと作られているのに、案件のページには何も出てきません。
原因は、その抜き出しが空で返っていたことでした。空でもエラーにはならないので、静かに何も渡りません。案件側から見ると「その会議は無かった」のと同じになります。
抜き出しが空のときは議事録の本文から拾い直すようにして直しました。途中の工程が空で返るのは、集める仕組み全体でいちばんよく踏む落とし穴でした。
憶測の日付を書かない、と決めました
案件ページには「マイルストーン」の欄があります。ここに何を書くかは、はっきり決めました。
明示された期日だけを書きます。 会話の中に「来月あたりですかね」があっても、日付にはしません。確定した期日が無ければ「確定した期日なし」と1行だけ書きます。
理由は、台帳を信じられるようにするためです。推測が事実と同じ見た目で並ぶと、全部が疑わしくなります。 1つでも憶測の日付が混ざっていると、他の日付も確認しに行くことになります。
同じ考え方で、名簿に登録が無いフルネームが出てきたときは「（要確認）」を付けます。分からないものを、分かったように書かない。 ここは徹底しています。
絞りすぎて、取引先の依頼を捨てていました
ここからが失敗の話です。
やりとりが案件に関係あるかどうかを判定する処理で、本文の 冒頭180字 だけを渡していました。判定に長文は要らないと思っていたからです。
ところが、長い依頼のメッセージは前置きの挨拶で冒頭が埋まります。「お世話になっております。先日はありがとうございました。さて——」で180字が終わります。本題に入る前に切れていました。
その結果、取引先からの依頼そのものを「関係なし」と判定して捨て続けていました。
900字に広げて、選別のやり方に版数を持たせ、古い版で判定した分を全部やり直しました。取りこぼしていた案件を拾い直して復旧しています。
節約と品質は表裏になっています。どこを削ったかを覚えていないと、静かに壊れます。
AIは迷うと、直さずに書き足します
もう1つ、渡し方で失敗した話です。
台帳の本文に、会議の聞き取りを間違えた人名が入っていました。コメントで「その名前の人は存在しない」と指摘しました。
翌朝の更新で何が起きたか。「そのような指摘があった」と書き足されただけで、本文の間違いはそのまま残っていました。
プロンプトに「解決済みの論点を再掲しない」までは書いてありましたが、訂正指示をどう扱うかを書いていませんでした。指示が曖昧なとき、AIは安全側に倒れます。安全側とは、消さずに足すことです。
直したのは3つです。
- 訂正の指示（存在しない／誤り／ではなく）は、追記ではなく本文を訂正した内容で書くとプロンプトに明記
- コメントから「誤った名前 → 正しい名前」を取り出して、過去に書かれたブロックも直接置き換える処理を追加
- 元になる議事録のメモ自体を、名簿の別名で正規化してから材料に渡す（そうしないと再生成のたびに汚染が戻る）
3番が効きました。間違えた名前を、正しい人の別名として名簿に登録しておきます。 そうすると材料の正規化と本文の訂正の両方に自動で効きます。登録が運用の要になりました。
出力の受け取り方でも、1回壊しました
細かい話ですが、同じ種類のものをもう1つ。
要約の結果をそのまま本文に流し込んでいたら、見出しが本文の中に文字として出てきました。箇条書きも全部ただの段落になりました。
原因は、AIが出力全体を囲み記号でくくって返すことがあったからです。受け取り側はその中身を「全部ただの文」として扱うので、構造が全部つぶれます。
先頭と末尾の囲みを外してから流し込むようにして直しました。AIの出力は、毎回同じ形で返ってくるとは限りません。
まとめ
- 要約の質を決めていたのは、モデルではなく渡す材料でした
- ただし渡せば渡すほど良くなるわけではありません。上限を決めます
- 用途ごとにモデルと出力の上限を分けます。上限を切ると出力が引き締まります
- 材料が変わっていない日は呼びません。副産物として台帳が読みやすくなりました
- 絞りすぎると、静かに壊れます。どこを削ったかを覚えておきます
- 指示が曖昧だと、AIは直さずに書き足します。「直す」と明記します
- 途中の工程が空で返るのがいちばんよく踏む落とし穴です。空はエラーになりません
- 憶測を事実と同じ見た目で並べない。 1つ混ざると、全部が疑わしくなります
同じシリーズ
- 考え方のほうはこちら 👉 業務をシステムに合わせるのを、やめました
- 作り方ノート②「APIで取れないチャットを集めて、案件ごとに仕分ける」 👉 APIで取れないチャットを集めて、案件ごとに仕分ける
- 作り方ノート③「案件・人・会社の3つの名簿を、1つの台帳につなぐ」 👉 案件・人・会社の3つの名簿を、1つの台帳につなぐ
- 体験談はXに書きました 👉 案件の状況を、自分で思い出すのをやめた話（X）
ABOUT ME
㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。
