532件の確認事項を15問に圧縮するAI活用の設計

532件の「要確認」は、なぜ放置されるのか

532件、誰も読めません。

これは実際に、ある案件の会議録や関連資料を機械的に洗い出した結果、出てきた「確認が必要な事項」の件数です。担当者に「これ全部確認してください」と渡しても、まず読み切れません。読み切れないものは、結局のところ後回しにされ、そのまま忘れられていきます。

多くの現場で起きているのは、まさにこの構図です。会議や仕様書、問い合わせ履歴などから「確認すべきこと」を漏れなく拾おうとすればするほど、件数は増えていきます。真面目に洗い出す作業自体は正しいのですが、洗い出した結果をそのまま人に渡してしまうと、量が処理能力を超えてしまい、確認作業そのものが機能不全に陥ります。

中小企業の現場でこの問題は特に深刻です。専任の確認担当者を置ける余裕がないため、大量のリストは「あとで見る」フォルダに入ったきり、二度と開かれないことが少なくありません。

問いが膨れ上がる本当の理由

なぜ確認事項はここまで膨れ上がるのでしょうか。原因を分解すると、件数そのものよりも「質」の問題が見えてきます。

一つ目は重複です。同じ懸念が、会議の別々の場面や異なる資料で少しずつ表現を変えて出てくると、機械的な抽出ではそれぞれ別の項目として数えられてしまいます。実際には1つの確認で済む話が、3件にも5件にも膨らむわけです。

二つ目は粒度の不揃いです。「この契約条項は有効か」という重大な確認と、「この日付の表記は正しいか」という些細な確認が、同じリストの中に並列で並んでしまいます。優先順位がつけられないリストは、結局どこから手をつけていいか分からず、放置される側に回ります。

三つ目は文脈の欠落です。抽出された問いだけを見ても、それがなぜ確認すべき事項として挙がったのか、背景が分からないケースが多々あります。背景が分からない問いに答えるには、資料を読み返す手間が発生し、それが確認作業の心理的なハードルをさらに上げてしまいます。

つまり件数が多いこと自体が問題なのではなく、重複・粒度不揃い・文脈欠落という3つの要因が絡み合って、実務では処理不可能な形にリストが仕上がってしまうことが根本原因です。

15問以下に束ねる圧縮ワークフロー

この根本原因に対処するには、確認事項を「減らす」のではなく「束ねる」という発想が必要です。減らせば漏れが出ますが、意味の近い問いを一つにまとめれば、抜け漏れを保ったまま件数だけを圧縮できます。

具体的な処理の流れは次のようになります。まず抽出された全項目を、AIによって意味的な近さで分類します。文言は違っても実質的に同じ懸念を指している項目は、ここで自動的にグループ化されます。次に、各グループの中で最も本質を突いた表現を代表質問として選び、周辺の細かい派生質問はその一問に統合します。最後に、統合された質問群に対して、意思決定への影響度で優先度を付け、上位から現実的に回答可能な件数——目安として15問以下——に絞り込みます。

この工程が効くのは、確認作業のボトルネックが「量」ではなく「認知負荷」にあるからです。人は15問程度であれば、それぞれの背景を思い出しながら一問ずつ丁寧に答えられます。しかし532件を前にすると、まず全体を把握することすらできず、脳が処理を拒否してしまいます。束ねる作業は、単なる件数の圧縮ではなく、人間が実際に判断を下せる状態への変換だと言えます。

誰が回しても同じ結果を出す指示プロンプトの構造

この圧縮処理を一度だけ手作業でやって終わりにしては意味がありません。継続的に運用するには、誰が実行しても同じ品質の結果が出るように、指示の出し方そのものを設計する必要があります。

ここで有効なのが、役割を分けたプロンプト設計です。全部を一つの巨大な指示にまとめるのではなく、「重複を見つけて分類する担当」「代表質問を選ぶ担当」「優先度を付けて絞り込む担当」というように、工程ごとに役割を分割し、それぞれに特化した指示文を用意します。こうすることで、一つの指示が複雑になりすぎず、途中の工程だけを見直したり差し替えたりすることも容易になります。

さらに、この指示文を特定のプロジェクトや担当者に依存しない形に整えておけば、社内の別部署はもちろん、外部のパートナー企業に渡してもそのまま使える汎用的な資産になります。属人化を避け、誰が回しても一定の品質を保てる仕組みにしておくことが、長く使える設計の条件です。

増分運用で崩れないための仕組み

こうした仕組みは、一度作って終わりではなく、実際の業務サイクルに乗せて初めて価値を持ちます。会議や資料は毎月新たに生まれ続けるため、確認事項も継続的に追加されていきます。

ある案件では、月次で発生する新規の確認事項を継続的に処理できるよう、運用スクリプトとドキュメントの整備が行われました。2026年6月から7月にかけての増分対応として、関連する12個のファイルが更新され、追加500行・削除1行という規模の変更が加えられています。これは新しいロジックをゼロから作ったというより、既存の仕組みが月をまたいでも同じ品質で回り続けるよう、運用の型を整えた作業です。

こうした地道な整備がなければ、最初の圧縮処理がどれだけうまくいっても、翌月にはまた同じ量の未処理項目が積み上がり、元の状態に逆戻りしてしまいます。継続的に機能する仕組みにするには、処理ロジックそのものと同じくらい、運用を支えるドキュメントとスクリプトの整備が重要になります。

束ねたあとに問われる「確認の質」

532件を15問以下に圧縮できれば、確認作業は現実的な時間に収まります。ここまでは効率の話です。しかし、この仕組みを導入した企業が次に向き合うのは、効率ではなく「確認の質」という別の課題です。

束ねられた15問は、あくまでAIが意味の近さで判断した集約結果です。本当に重大な懸念が、些細な項目に埋もれて代表質問から漏れていないか。優先度の付け方は、自社の意思決定の重みづけと一致しているか。これらは機械的な処理だけでは担保できず、最終的には人間が確認しなければならない領域です。

件数を減らすことは手段であって目的ではありません。経営者やIT担当者に求められるのは、圧縮された15問の中身を定期的に検証し、集約のロジックが自社の実態に合っているかを見直し続ける姿勢です。効率化の仕組みを入れた後こそ、その仕組みが本当に正しい問いを拾えているかを問い直す判断が、次の課題として待っています。