0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

日報のAI要約を導入する前に、AIに渡す範囲を決めておく

0
Posted at

この記事の位置づけ

AI活用コンサルタントとして中小企業の現場に入ると、生成AIの導入判断では「何をAIに渡すか」の境界決めが、ツール選定より先に効いてくると感じることが多い。本稿で扱うのは、日報である。

現場からは「AIに日報を読ませて要約してくれ」という相談がよく来る。ところが、そのまま進めると、日報という文書が「読めない」扱いになり、話がそれ以上進まないことがある。原因は社側の拒否ではない。「どの範囲なら読んでよいか」を何も決めていない状態で持ち込んだ側にある。

境界を決めたうえで切り出せば、日報のAI要約は導入ハードルの低い改善になる。以下、境界の切り分け方を示す。

日報を構成する情報は、読んでよい範囲が違い、粒度も違う

日報の中身をよく見ると、書かれている情報は一種類ではない。次の3つに分けられる。

  1. 共有文書相当:今日進めた作業の内容、翌日以降に引き継ぐべき事項。同僚の業務に関わるので、もともと共有が前提の情報である。
  2. 申請系相当:残業・休暇・経費など、承認プロセスがある事項。共有ではなく申請であり、記録は申請システム側に存在する。
  3. 機密相当:取引先の個別の事情(競合他社との接触、クレームの経緯、トラブルの背景)。本来、限られた人しか読むべきでない。

3つ目が厄介なのは、粒度の問題である。案件名の粒度なら共有でも、「どの担当者が、どの取引先に接触したか」という粒度まで落とすと機密になる。つまり、この区分は文書単位ではなく、文書の中の粒度単位で決まる。

渡す範囲を決める3区分

この区分をそのまま、AIに渡す範囲のルールにする。

区分 日報内の情報の例 AIに渡すか
共有文書 作業内容、翌日への引き継ぎ 渡してよい
申請系 残業・休暇・経費 渡さない(申請システム側の記録を使う)
機密 取引先の個別の事情 渡さない

機密区分の粒度は、各部門で線を引く。部門ごとに「書いてよい粒度」と「書いてはいけない粒度」を決め、日報のテンプレートの注記に一行を足すだけで足りる。

架空の例:部品製造A社のケース

架空の部品製造業A社の状況を示す。

  • 従業員80名程度。製造部門の日報は紙の様式から移行が進まず、部署によって様式がばらばらである。
  • 現場の不満は、日報を書くだけで読み返す人がいないこと。翌日の仕事に生かされていない。
  • 日報のAI要約を試す段階で「日報に機密が混ざるのでは」という話になり、導入が止まっている。

ここで、切り出しのルールを決める。

  • 申請系は日報に入れない。残業や休暇は申請システムの記録を使う
  • 機密区分は「取引先の個別の事情」まで。案件名の粒度は共有文書区分として渡してよい
  • 案件名の粒度を超える書き方をした場合は、書いた本人が判断して削る

ルール決めの結果、A社では日報の様式そのものは変えず、「書く内容の範囲」だけを決めてAI要約の試験運用を始められた。様式を統一するプロジェクトは立ち上がらず、機密情報の流出もない。

区分の線引きは、文書単位ではなく粒度単位で決める

日報を扱いにくい文書にしているのは、「日報に書く内容の粒度に決まりがない」ことである。この線引きを先に決めれば、残るは共有に耐えない粒度を書かないだけになる。

線引きの要点をまとめる。

  • 区分は文書単位ではなく、書く粒度単位で決める
  • 部門ごとに「書いてよい粒度」と「書いてはいけない粒度」の注記を日報テンプレートに一行足す
  • 書いてよい粒度を超えた場合は、書いた本人を信頼して、自分の判断で削る。この判断を現場でさせることに意味がある
  • 機密区分の粒度の線引きが難しい部門では、その部門の情報だけAI要約から外す

一番下の点は重要である。境界に曖昧さが残る日報は、AIに渡さない。渡す範囲の線引きは、境界が曖昧なままでよいものではない。

申請系の話が厄介な理由

「申請系は渡さない」は一見素直なルールに見えるが、実際には厄介な問題を抱えている。申請系の判断には「文脈」が伴うからである。

例えば、ある従業員が日報に「本日の外回りの距離が例月より長い」と書いたとする。この文脈から、経費(申請系区分)の判断に必要な文脈が生まれる。しかし、その情報自体は日報(共有文書区分)に含まれる。

つまり、経費の判断に必要な文脈の多くは、日報にしか存在しない。申請システム側の記録だけを参照しても、判断に必要な文脈が得られないことがある。

A社での扱いは次のとおりである。

  • 経費の判断に必要な文脈は日報(共有文書区分)から読み取れる
  • 申請そのものは申請システム側の記録で回す
  • つまり、文脈の部分だけを共有文書区分としてAIに渡し、申請の記録は渡さない

「文脈は共有、申請の記録は渡さない」。この切り分けが、3区分の実務的な要点である。

まとめ(管理職・現場担当者向け)

  • 日報のAI要約で最初に決めるのはツール選定ではなく、渡す範囲の境界である
  • 渡す範囲は「共有文書・申請系・機密」の3区分で切り分ける
  • 区分は文書単位ではなく粒度単位。部門ごとに「書いてよい粒度」の注記を一行足す
  • 書いてよい粒度を超えた場合は、書いた本人が自分の判断で削る
  • 申請系は記録ごと渡さない。判断に必要な「文脈」の部分だけを共有文書区分として渡す

境界の決め方を先に固めておけば、日報のAI要約は、生成AIの試験導入として扱いやすい題材になる。反対に、境界が曖昧なまま持ち込むと「読めない」と断られ、導入判断がそこで止まる。順序の違いが、そのまま結果の違いになる。

※本稿のA社は説明のために構成した架空の例である。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?