要約機能を作るときの設計

要約はAI機能の中でも導入しやすい部類です。議事録、問い合わせ、レビュー、長文の申請内容など、社内に長い文章がある会社なら、どこかに使いどころがあります。一方で、作ってはみたものの使われなくなる要約機能も多く見てきました。

差がつくのは、モデルの選択やプロンプトの巧拙より、何のための要約かを決めているかどうかです。本記事では、要約機能を組み込むときに先に決めておきたい設計上の論点を整理します。

要約は「短くすること」ではない

要約機能が使われなくなる最大の理由は、「短くはなったが、結局原文を読むことになる」からです。短くする過程で、読み手が必要としている情報が落ちてしまうと、要約は手間を増やすだけの機能になります。

設計の最初にすべきことは、次の二つを一文で書くことです。

• 誰が読むか：問い合わせ対応の担当者か、承認する管理職か、集計する分析担当か
• 読んだ後に何をするか：振り分けるのか、返信を書くのか、可否を判断するのか、後で探すための手がかりにするのか

たとえば同じ問い合わせメールでも、「担当部署へ振り分ける人」が読む要約に必要なのは、内容の種類と緊急度です。「返信を書く人」が読む要約に必要なのは、相手の要望と前提条件と感情の温度です。この二つは別の要約であり、一つの出力で兼ねようとすると、どちらにも足りないものになります。

読んだ後の行動が決まると、「残すべき情報の種類」が列挙できます。日付、金額、固有名詞、依頼事項、期限、判断が必要な点。この列挙が、指示の中身と品質の判断基準の両方になります。

長さと粒度を用途から決める

長さを「300字程度で」と指定するのは、一見具体的ですが、実は何も決めていません。入力が短いときは水増しされ、長いときは重要な情報が落ちます。

おすすめするのは、画面上のどこに表示するかから決める方法です。

こうして表示場所から決めると、長さだけでなく粒度も決まります。一覧の行に載せる要約に「議論の経緯」は要りませんし、詳細画面の要約から「金額」が落ちてはいけません。

粒度に迷う場合は、箇条書きの項目を固定する方法が有効です。「依頼内容／期限／判断が必要な点」のように出力の型を決めておくと、入力による揺れが小さくなり、画面の設計もしやすくなります。自由形式の文章より、項目が決まった出力の方が、後から評価するのも簡単です。

要約できない入力への対応

実運用で必ず起きるのが、要約に向かない入力が来ることです。ここを設計していないと、無意味な出力が自信たっぷりに表示されることになります。想定すべき入力を挙げます。

• 短すぎる入力：もともと一行の問い合わせを要約しても意味がありません。一定の長さに満たない場合は要約せず、原文をそのまま表示する方が親切です。
• 長すぎる入力：モデルが一度に扱える量には上限があります。分割して要約し、その要約をさらにまとめる構成にするか、そもそも対象外とするかを決めておきます。
• 要約する内容がない入力：定型の通知、自動送信のメール、添付ファイルだけの投稿など。「特筆すべき内容はありません」と返せる設計にします。
• 画像やファイルが本体の入力：本文が「添付をご確認ください」だけの場合、本文だけを要約しても役に立ちません。その旨を表示します。
• 複数言語が混ざる入力：どの言語で要約を出すかを決めておきます。

大事なのは、これらのときに要約機能が「できません」と言えることです。AIに何かを言わせようとすると、必ず何かを言います。それが誤った情報でも同じです。入力の段階でふるい分けて処理を止める判断は、プログラム側で行うのが確実です。

誤りの影響を見積もる

要約には誤りが混ざります。事実と違う記述が入る、重要な条件が落ちる、否定が肯定に反転する。これらをゼロにはできない前提で、その誤りが業務にどう波及するかを先に見積もります。

見積もりの観点は次の三つです。

1. 要約だけを見て意思決定が進む場面があるか
2. 誤りに気づく機会が、その後の工程にあるか
3. 気づかないまま進んだ場合、どこまで戻せるか

この三つに照らして影響が大きい場面では、要約を「判断材料」ではなく「読む順番の手がかり」に位置づけを下げます。具体的には、要約の横に必ず原文へのリンクを置く、重要な数値や日付は要約ではなく原文から機械的に抽出して別枠で表示する、といった作りにします。

逆に、影響が小さい場面――たとえば過去の記録を後から探すときの手がかり――では、多少の誤りを許容して広く適用する方が価値が出ます。

想定例：ある企業が、問い合わせの要約を担当者への通知に載せたとします。要約の末尾にある「至急ではない」という記述が誤りだったため、対応が遅れました。この企業はその後、緊急度は要約に含めず、キーワードによる機械的な判定で別表示する構成に変えました。AIが判断すべき部分と、確実な規則で判定すべき部分を分けた形です。

人が直せる形にしておく

要約は出して終わりではありません。担当者が「これは違う」と思ったときに直せる仕組みがあると、機能の寿命が伸びます。

編集できるようにするのが最も単純な方法です。編集された内容は、そのまま保存して次回以降そちらを表示します。加えて、どの要約が直されたかを記録しておくと、指示の見直しに使える材料になります。直された割合が高い種類の入力が見つかれば、そこが改善の対象です。

なお、この記録は品質を見張る仕組みの一部でもあります。運用開始後に何を記録し何で気づくかについては、別途整理が必要です。

小さく試してから広げる

要約機能は、実際のデータで試すまで使い物になるか分かりません。開発の前に、実データを数十件用意して手元で試し、業務の担当者に「これで判断できますか」と聞く工程を置いてください。この段階で「足りない」と分かれば、作る前に設計をやり直せます。

私たちは既製のAIサービスのAPIを組み込む形で要約機能を実装しますが、最初にお伺いするのは常に「その要約を読んだ人は次に何をしますか」です。ここが定まらないうちは、実装に進まない方が結果的に早く済みます。

AI活用開発とWebシステム開発では、要約機能の用途の整理から実装、運用の設計までご相談を承ります。お問い合わせよりご連絡ください。ご相談・お見積りは無料です。