Notion AIを社内で使う5工程｜任せる線を先に引く

「社内の書き物を置いている道具に、いつのまにかAIの欄が増えていました」「会議の記録の要約は便利なのですが、一部の人しか見られないはずのページの中身が、要約の中に出てきたことがあります」。後から入ってきた機能ほど、入れる決定をした人がいないまま使われ始めます。稟議も審査も通っていないのに、現場ではもう毎日使われている。この種のAIで最初に決めるのは使い方ではなく、AIに読ませる範囲をいまの権限のどこに合わせるかです。文書を置く道具に付いたAIは、その人が見られる文書の範囲をそのまま引き継いで答えます。つまり権限の設計が、そのまま答えの範囲になります。この記事では、社内の書き物をどこまで任せるかを5つの工程に割って、決める順番のまま並べます。人が書き続ける3種類の文書についても、独立して1節を置きます。

決めることが「入れるか」から「どこまで開けるか」に変わった

外部のAIを新しく導入する場合、社内では申請と審査という手順が動きます。ところが、すでに使っている道具の側にAIが付いてくると、この手順が発動しません。契約は前からある、画面も前から使っている、増えたのは欄が1つ。導入の決定が要る出来事として扱われないまま、機能だけが全社に届きます。

これは仕組みの落とし穴で、担当者の不注意ではありません。社内の手続きは「新しい契約を結ぶとき」に効くように作られているため、既存の契約の中で機能が増える形には、引っかかる場所がないのです。結果として、決める人がいないまま使われ、何か起きたときに初めて「誰が開けたのか」を探すことになります。

だから最初に置く問いは「導入するかどうか」ではありません。もう使える状態のものを、どこまで開けたままにするかです。この問いに変えると、決めるべきことが具体になります。誰が使えるか、AIが読めるのはどこまでか、何を入れてよいか、出てきた文を誰が確かめるか、増えた文書をどう畳むか。この5つが、以降の工程になります。

任せられるのは書くことより読むこと。3つに割って見る

この種のAIに任せられる仕事は、実務では3つに割れます。散らばった文書から答えを探して要約すること、ゼロから文をひねり出すのではなく型のある文書の下書きを作ること、そして既にある文を読み手に合わせて言い換えることです。どれも共通しているのは、材料が社内の文書の側にあることです。

逆に言うと、材料が社内に無い仕事は任せられません。決まっていないことを決める、数字を出す、起きていないことを予測する。これらは文書を読んでも答えが出てこないため、任せるともっともらしい文だけが返ってきます。この区別は難しくないのに、使い始めた直後の現場ではよく飛び越えられます。

実務での見分け方は1つで足ります。その問いの答えが、社内のどこかの文書に書かれているかどうかです。書かれているなら、探して要約させる仕事になります。書かれていないなら、それは文書が無いという別の問題です。答えが無い問いに答えが返ってきたら、それは文書ではなく作り話を読んでいます。

5つの工程と、決める順番

ここから工程に入ります。順番の要点は、任せる範囲を決める工程を、権限を触る工程より先に置くことです。逆にすると、何のために権限を直しているのか分からなくなり、現場から見れば急に共有が外された、という話になります。

この5つのうち、社内で先に手が付くのは4番目です。確かめ方は現場の工程の話なので、話し合いやすいからです。しかし1番目と2番目が決まっていないまま4番目を作ると、確かめる対象が毎回変わります。どの文書を任せているのかが決まっていないので、確かめる基準も定まらないのです。

工程1　任せる書き物を、文書の種類で割る

業務単位や部署単位で割ると、線が引けません。同じ部署の中に、任せてよい書き物と人が書くべき書き物が混ざっているからです。文書の種類で割ると、任せる範囲と人が書く部分が同じ表に並びます。

文書の種類	任せてよい範囲	人が書く部分
会議の記録	話の流れの要約と、決まっていない論点の抜き出し	決まったこと、担当、期限
手順書・作業の手引き	既にある手順の言い換えと、抜けている段の指摘	手順そのものの正しさの確認
調査のまとめ	集めた資料の要約と、論点の並べ替え	数字と、その出どころ、結論
部門の報告	文章の下書きと、長さの調整	数字と、その数字の読み方
社外に出す文面	案を複数出させて、選ぶ材料にする	最終の文面すべて
規程・基準	既にある規程との差の洗い出し	書きぶりと、適用範囲の判断

表の中でいちばん揉めるのは、1行目の会議の記録です。要約は明らかに便利なので、そのまま議事録として配りたくなります。ところが会議の記録には、話の要約と決定事項という性質のまったく違う2つが同居しています。要約は任せてよく、決定事項は人が書く。この2つを1つの文書の中で分けて書ける形にしておくと、後の確かめ方が軽くなります。

もう1つ注意が要るのは、6行目の規程です。差の洗い出しは任せられますが、洗い出された差のうちどれを直すかは判断です。規程の文言は、社内の合意の履歴を背負っています。読みやすく整えた結果、以前の議論で意図的に残した曖昧さが消えることがあります。

工程2　AIが読む範囲は、いまの権限の写しになる

この種のAIは、探す範囲を自分で持ちません。公式の説明には、答えを作るモデルはその利用者が既にアクセス権を持っていない情報を見ることも使うこともできない、という趣旨が明記されています。つまり権限の設計が、そのまま答えの範囲になります。

この性質は、良い方向にも悪い方向にも効きます。良い方向は、権限を正しく設計している会社なら、AIを開けても見える範囲は変わらないことです。悪い方向は、権限が緩い会社では、緩さがそのまま答えとして表に出てくることです。これまでは「探されなければ見つからない」で済んでいたものが、尋ねれば要約で返ってくる状態になります。

だから工程2で最初にやるのは、AIの設定ではありません。見えてはいけない文書が、いま誰から見えているかの確認です。AIを開ける作業は、権限の棚卸しの結果を確かめる作業とほぼ同じになります。そして探す範囲には、社内の文書だけでなく、接続した外部の道具の中身と、設定によってはウェブの情報も入ります。この3系統を分けて把握しておく必要があります。

権限が緩いまま開けると、要約に混ざる3つの経路

実際に「見えてはいけない文が要約に出た」という話を追うと、経路は3つに集まります。どれも権限の設定の中では正しく動いていて、設定した人の意図とだけ食い違っています。

1つ目は、親の階層から引き継いだ範囲です。文書を階層で持つ道具では、下の階層は上の階層の共有範囲を引き継ぐのが普通です。上の階層を広く共有したまま、その下に人事や取引条件の資料を置くと、置いた人の意図とは無関係に見える人が増えます。AIを開ける前に、上の階層の共有範囲から見直します。

2つ目は、外から招いた人の範囲です。取引先や業務委託の相手を1つのページだけのために招いたつもりでも、招き方によっては、そのページを含む上の階層まで見えていることがあります。招いた人の一覧と、その人が実際に見られる範囲は、別に確かめます。

3つ目は、接続した外部の道具です。公式の説明では、探す範囲に接続した外部の道具の内容も含まれます。会話の道具や保管の道具をつなぐと、そちらの中身も答えの材料になります。つないだ時点で、もう1つ別の権限設計が答えの範囲に流れ込むことになるので、つなぐ判断は文書の道具の側だけで決められません。また、ウェブへの問い合わせは、管理側で無効にしたり、問い合わせのたびに確認を求める設定にできることが公式に説明されています。

工程3　入れてよい情報の線を、業務の言葉で書く

線を引くとき、多くの会社が「機密情報は入れない」と書きます。この書き方が守られないのは、現場が不真面目だからではありません。手元の資料が機密にあたるかを、現場が判断できないからです。判断できない基準は、実質的に基準として働きません。

書き方を変えます。自社の業務で実際に扱っている物の名前で書きます。たとえば、取引先から預かった資料、個人が特定できる応募者や顧客の情報、まだ公表していない価格や条件、採用や評価に関する記録、監査や訴訟に関わる文書。この粒度なら、現場は手元の資料を見て判断できます。

あわせて、迷ったときの行き先を書きます。線引きの文書に必ず抜けが出るので、迷ったら止めて誰に聞くかを1行で書いておきます。聞く相手が決まっていないと、現場は自分で判断して入れます。問い合わせが来た内容は、次の見直しで線引きの文書に足していきます。1回で完成させるものではなく、問い合わせで育てるものだと考えるほうが実務に合います。

索引は本文の外に作られる。消えるまでに時間差がある

この層は、文書の整え方の話とは別に立てる必要があります。検索や要約を速くするために、本文とは別に、内容を数値に置き換えた索引が作られます。この索引は本文と同じ場所にあるとは限らず、消える時期も本文と同じではありません。

公式の説明では、この索引にあたるものはページやワークスペースを削除してから60日以内に削除されるとされています。つまり、間違って置いた文書を慌てて消しても、索引の側からはしばらく消えない期間があるということです。実務でこれが効くのは、入れてはいけない資料を誤って置いてしまった場面です。本文を消して終わりにせず、索引から消えるまでの期間を前提に、その間に取るべき措置を決めておきます。

同じ話が、答えを作る過程で外に渡るデータにも当てはまります。公式の説明では、既定では顧客のデータを学習に使わないとされ、上位のプランでは外部のモデル提供元の側でデータを保持しない設定が既定になっています。一方、それ以外のプランでは、外部のモデル提供元が30日以下の期間データを保持するとされています。入れたものが消えるまでの日数は、契約のプランによって変わります。審査でこの数字を聞かないと、消したはずのものがどこかに残る期間を、誰も把握していない状態になります。

工程4　出てきた文の確かめ方を、読む人ごとに決める

確かめ方を決めるときによくある失敗は、「必ず人が確認する」と書いて終わることです。誰が、どこを、どのくらいの時間で読むのかが書かれていないため、実際には誰も読まないか、全員が全部を読むかのどちらかになります。前者は形だけになり、後者は続きません。

設計の考え方は、読む場所を絞ることです。文書の種類ごとに、間違うと戻せない部分だけを指定します。会議の記録なら、決定事項と担当と期限の3行。調査のまとめなら、数字とその出どころ。部門の報告なら、数字と、その数字の読み方。手順書なら、順番と、飛ばすと危ない段。この形にすると、確認は数分で終わります。

読む人は、その文書の内容に責任を負う人にします。作った人が自分で読み直す形にすると、作ったときの理解がそのまま通ってしまうため、抜けが見つかりません。会議の記録なら、その会議で決めた人。報告なら、その数字を出した人。確かめる人を決めることは、責任の所在を決めることと同じです。

参照元の無い答えは採らない、を運用として書く

要約や検索の答えは、必ず社内の文書のどこかを読んで作られています。だから答えには、どのページを読んだのかを添えさせます。そして参照元が添えられていない答えは採らないという運用にします。この1行があると、確かめる作業が現実的な時間で終わります。

なぜ効くかというと、確かめる作業の中身が変わるからです。参照元が無いと、答えの内容が正しいかを一から調べることになります。参照元があれば、そのページを開いて書かれていることと一致しているかを見るだけで済みます。前者は数十分、後者は数分の作業です。

もう1つ、参照元を要求すると副作用があります。社内に文書が無い問いに対して、答えが出てこなくなるか、ウェブや一般論から作られた答えだと分かるようになることです。これは不便ではなく、有用な信号です。参照元が出せない問いが並んだら、それは文書が足りない場所の一覧です。AIの精度の問題として扱わず、文書を作る仕事に回します。

工程5　増えた文書の畳み方。正とする1本を先に決める

この種のAIを使うと、文書は減りません。増えます。要約が増え、下書きが増え、言い換えが増える。そして増えた文書は、それぞれ少しずつ内容が違います。半年たつと、同じことを述べた文書が複数の場所にある状態になります。

防ぐ手立ては、増えたものを片付ける仕組みではなく、生まれる前に正とする1本を決めておくことです。具体的には、任せる文書の種類ごとに、正とする置き場所を1つ決めます。要約はここ、決定事項はここ、手順書はここ。そして、それ以外の場所に生まれたものは作業の途中の物であって参照してはならない、と決めます。

あわせて、要約から作った文書に印を付けます。元になった文書と、作った日付を、文書の中に書き込む。こうしておくと、後から読んだ人が「これは元の文書のいつの時点の要約か」を判断できます。日付の無い要約は、時間がたつと元の文書と区別がつかなくなります。印を付ける手間は数十秒で、付けなかった場合に発生する探し直しは数十分です。

そして、畳む担当を決めます。文書の種類ごとに、半年に一度、正とする1本と、その周りに生まれた作業中の文書を見比べる人を置きます。この役は作った人ではなく、その文書を業務で使っている部署に置くほうが機能します。使っていない人には、どれが古いかが分かりません。

人が書き続ける3種類の書き物

主題そのものがAIなので、任せない範囲を独立して書いておきます。文書の種類で細かく割った表とは別に、種類を問わず人が書く3つがあります。

1つ目は、決定事項の記録です。会議で何が決まり、誰が担当し、いつまでにやるのか。これを要約から作ってはいけないのは、要約が話の量に引きずられるからです。長く議論したが決まらなかったことが要約では大きく扱われ、ひと言で決まったことが小さく扱われます。決定は量ではなく重みで書く必要があります。

2つ目は、数字の入る文書です。数字は、それ自体は文書の中に書かれています。しかし要約は、数字の意味ではなく文の形を扱うため、単位や期間や母数が落ちることがあります。落ちた数字は、もっともらしい形をしているために、読んだ人が疑いません。数字は書いた人が書き、確かめる人が原典と突き合わせます。

3つ目は、社外に出す文面です。案を複数出させて選ぶ材料にするのは有効ですが、最終の文面は人が書きます。理由は精度ではなく、責任の所在です。社外に出た文は自社の意思表示として読まれるため、書いた人が中身を説明できる状態でなければなりません。そして、社内の判断の理由をAIに説明させた文を、そのまま社外向けの説明として使わないことも決めておきます。

学習に使われるかは、既定と契約とプランの3つで決まる

入れたものが学習に使われるかどうかは、社内で最も多く聞かれる質問です。公式の説明では、既定では顧客のデータをモデルの学習に使わないとされ、利用によって顧客データに対する権利や許諾が提供側に生じるものではないとも書かれています。ただし審査では、この文の効き方を3つに分けて読みます。

既定でそうなっているのか、契約や合意で確保されているのか、契約のプランや設定によって変わるのか。効き方が違うと、後から変わる可能性も違います。既定の設定は提供側の都合で変わることがあります。プランで変わるものは、社内の誰かがプランを下げた時点で条件も下がります。先に触れた保持期間の話は、まさにプランで変わる例でした。

社内に説明するときは、「学習に使われません」と言い切らないほうが後で困りません。「いま契約しているプランでは、既定でこうなっている」「この条件はいつの時点の記載で確かめたか」まで添えます。そして読んだ資料と日付を保管する。半年後に条件が変わったとき、何がどう変わったのかを追える材料になります。

管理側で切れるものと、切れないもの

開ける範囲を決めるうえで、そもそも管理側で何を操作できるのかを先に確かめる必要があります。ここを確かめずに方針を立てると、「止めると決めたのに止められない」ということが起きます。

公式の説明から読み取れる範囲では、ワークスペースの管理者が切り替えられるものとして、ウェブへの問い合わせを有効にするかどうか、問い合わせのたびに確認を求めるかどうか、そしてチームが使えるモデルを選ぶことが挙げられています。また、この機能が使えるのは上位のプランで、下位のプランでは回数が限られる形になっています。

重要なのは、すべての機能に管理側の切り替えがあるとは限らないことです。だから運用の設計は、「機能を止める」ではなく「読める範囲を狭める」を軸に組みます。権限で狭めた範囲は、機能の切り替えがなくても効きます。止めるスイッチに頼らず、権限で線を引くほうが確実です。そして、いま何が切れて何が切れないのかは、半年ごとに確かめる項目に入れておきます。既定で有効になる機能は、こちらが気づかないうちに増えます。

1部署で回してから広げる。増やしたあとにやりがちな失敗

全社に開ける前に、1つの部署で3か月ほど回します。選ぶ部署は、文書の量が多く、扱う情報の階級がそろっていて、間違ってもすぐ気づける仕事をしている部署にします。情報システムの部門は選ばないほうがよく、理由は、その部門が使えることは他の部門が使えることの証明にならないからです。

回すあいだに集めるのは、使われた回数ではありません。参照元が出せなかった問いの一覧、要約に混ざった見えてはいけない文の報告、そして線引きの文書に無かった判断の相談です。この3つが、全社に広げる前に直す場所を示します。

次は、実際につまずいた形です。どれも設定が間違っていたのではなく、決める順番か、決める粒度が合っていなかったために起きたものです。

• 権限を触る前にAIを開けた。上の階層を広く共有したまま、その下に置いていた取引条件の資料が要約に出た
• 1つのページのために招いた外部の相手が、招き方の都合で上の階層まで見られていた。招いた人の一覧は確かめたが、実際に見られる範囲は確かめていなかった
• 会話の道具をつないだ時点で、そちらの権限設計も答えの範囲に流れ込んだ。つなぐ判断を文書の道具の担当だけで決めていた
• 線引きを「機密情報は入れない」で書いた。現場は手元の資料が機密かを判断できず、迷ったときの相談先も書いていなかった
• 誤って置いた資料を消して終わりにした。検索のための索引から消えるまでに日数がかかることを、誰も把握していなかった
• 確かめ方を「必ず人が確認する」と書いた。誰がどこを読むかを書いていないため、実際には誰も読んでいなかった
• 要約から議事録を作って配った。長く議論して決まらなかったことが大きく書かれ、ひと言で決まったことが落ちていた

最後に、全社に開ける前に確定させる項目です。1回の会議で埋まる分量にしてあります。

• 任せる文書の種類と、その中で人が書く部分を、表の形で確定させる
• 上の階層の共有範囲を見直したか。外から招いた人が実際に見られる範囲を確かめたか
• 外部の道具をつなぐかどうかを、つなぐ先の権限を持っている人と一緒に決めたか
• 入れてよい情報の線を、自社の業務で扱っている物の名前で書いたか。迷ったときの相談先を書いたか
• 文書の種類ごとに、確かめる人と、読む場所を指定したか
• 正とする置き場所を、文書の種類ごとに1つ決めたか。畳む担当と周期を決めたか
• 入れたものが消えるまでの日数と、管理側で切れる範囲を、いまの契約で確かめたか

• この記事に書いた仕様は、公式の説明から読み取れる範囲のものである。プランや時期によって変わるため、自社の契約で必ず確かめる
• 権限で狭めた範囲は、機能の切り替えがなくても効く。止めるスイッチを探す前に、権限の側で線が引けるかを見る
• 既定で有効になる機能は増える。半年ごとに、いま何が開いているかを確かめる項目を運用に入れておく
• 参照元が出せない問いが並んだら、精度の問題ではなく文書が無い場所の一覧として読む

この記事に出てきた言葉のミニ解説

権限の引き継ぎ

答えを作るとき、その人がすでに見られる文書だけを材料にする性質のことです。AIの側に別の設定があるのではなく、いまの権限がそのまま使われます。したがって、AIを開ける作業は権限の棚卸しの結果を確かめる作業とほぼ同じになります。

索引

検索や要約を速くするために、文書の内容を数値の並びに置き換えて別に保持したものです。本文とは別の場所にあり、本文を消しても索引から消えるまでには時間差があります。公式の説明では、削除から60日以内に削除されるとされています。

参照元

答えを作るときに読んだ文書のことです。答えと一緒に示させることで、確かめる作業が「一から調べる」から「そのページと突き合わせる」に変わります。示せない答えは採らないという運用にしておくと、確認が数分で終わります。

正とする1本

同じ内容の文書が複数の場所に生まれたときに、参照してよいと決めた文書のことです。増えた後で選ぶのではなく、文書の種類ごとに置き場所を1つ決めておく形にします。それ以外の場所にあるものは、作業の途中の物として扱います。

まとめ

文書を置く道具に後から付いたAIは、導入の決定が要る出来事として扱われないまま全社に届きます。だから決めることは「入れるか」ではなく「どこまで開けたままにするか」でした。そしてこの種のAIは、その人が見られる文書の範囲をそのまま引き継いで答えるため、権限の設計がそのまま答えの範囲になります。AIの設定を触る前に、上の階層の共有範囲と、外から招いた人の見える範囲を見直すことになります。

5つの工程は、任せる文書の種類を決める、読む範囲を権限に合わせる、入れてよい情報の線を業務の言葉で書く、確かめ方を文書の種類ごとに埋める、増えた文書の正を先に決める、の順でした。このうち見落とされやすいのは2番目と5番目です。2番目を飛ばすと権限の緩さが答えに出て、5番目を飛ばすと同じ内容の文書が静かに増えていきます。

人が書き続けるのは、決定事項の記録、数字の入る文書、社外に出す文面の3つです。どれも精度の問題ではなく、責任の所在の問題として線を引いています。今日できることを1つ挙げるなら、いちばん広く共有している上の階層を開いて、その下にどんな資料が置かれているかを見ることです。そこに人事や取引条件の資料があれば、AIを開ける前に直す場所が見つかったことになります。デボノはAIの導入支援と社内研修の両方を手がけており、任せる線の引き方から一緒に決める形でも入っています。自社の権限の棚卸しから相談したい場合は、お気軽にお声がけください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。