kintoneのデータはAIに触らせてよい？｜権限を保ったつなぎ方

「案件も日報も全部その基盤に入っているので、AIに聞けば集計くらいはすぐ出ると思ったのですが」「読ませるところまでは動いたのですが、部長にしか見えないはずの案件が要約に混ざっていました」——業務データを業務アプリの基盤に溜めている情報システム部門の方と話すと、この二つが同じ打ち合わせの中で続けて出てきます。詰まっているのは、つなぎ方の技術ではありません。効いてくるのは、すでに溜まっているものに後からつなぐときだけ現れる制約です。この記事では、一から作る場合と何が違うのかから始めて、つなぐ前に確かめる4項目、権限の3つの階層、誰の権限で読ませるかの二つの方式とその危なさ、読ませるだけと書き戻しの線引き、項目名がばらついている基盤でAIが外す型、見せないアプリを決める順番、一度に読める件数の上限、そしてつないだあとに増える運用までを順に整理します。

「もう入っているのだから聞けばいい」が、そのまま通らない理由

業務アプリの基盤を数年使っていると、案件、日報、問い合わせ、稟議、在庫が同じ場所に並びます。これだけそろっているのだから、AIをつないで聞くだけで集計も要約も出るはずだ、という期待は自然です。ところが実際につないでみると、動くところまでは早く着くのに、返ってきた答えが合っているかどうかを誰も判定できない、という段で止まります。止まる場所が、一から組むときとは違うところにあるのです。

一から組むなら、入れる項目を決めながら作れます。名前も選択肢も、後でAIに読ませる前提で整えられます。すでに溜まっている基盤にはその自由がありません。項目名は数年分の運用でばらつき、権限は人ごとに細かく分かれ、似たアプリが何本も並んでいて、どれが正かは現場ごとに違う答えになっています。先にデータがあることは、有利ではなく制約として効いてきます。整えてからつなごうとすると、今度は動いている業務の側に副作用が出ます。項目名を直せば過去の集計が合わなくなり、権限をそろえれば見えていたものが見えなくなります。

もう一つ、性質の違いがあります。一から組んだ仕組みは、設定が間違っていれば動きません。すでにあるものにつないだ仕組みは、間違っていてもそれらしい答えを返します。500件だけ読んで全体の合計として答える。見えないはずのレコードを混ぜて要約する。どちらも画面の上では成功として表示されます。この記事で扱うのは、その静かな失敗を先に潰しておく順番です。

一から組むときと、溜まったものにつなぐときで変わる4つ

違いは4つに整理できます。大事なのは違いの名前ではなく、その違いがどの作業に化けるかのほうです。化ける先が分かると、つなぐ前にやる作業と、つないだ後に回してよい作業を分けられます。

	一から組む場合	溜まっている基盤に後からつなぐ場合
項目の名前	読ませる前提で決められる	数年分の運用でばらついている。直すと過去の集計が合わなくなる
権限	開く範囲を後から決められる	人ごと、レコードごと、項目ごとに分かれている。つなぐ側がそれを壊さないようにする
どれが正か	作った1本しかない	似たアプリが何本も並び、部署ごとに違うものを正として使っている
失敗の見え方	動かないのですぐ分かる	動いたまま合わない答えが返る。気づく機会が来ない

この表を見ると、つなぐ前に必ず済ませるべきものが一つに絞れます。権限です。項目名のばらつきは、間違いが目に見える形で出るので後から直せます。どれが正かも、使いながら決めていけます。権限だけは、間違えたときに取り返しがつかない部類の失敗になります。一度見えてはいけないものが要約に混ざれば、読んだ人の頭からそれを消すことはできません。だから順番は、権限を決める、次に見せるアプリを絞る、最後に項目名を整える、になります。

つなぐ前に確かめる4項目——アプリ数、項目名、権限の粒度、添付の中身

つなぐ前の調査は、聞き取りではなく実物を開いて数える形で進めます。情報システム部門の把握と現場の実態がずれているのが普通で、そのずれ自体が後で事故になるからです。確かめるのは次の4つです。

• アプリ数：全部で何本あり、そのうち直近3か月に更新されているのは何本か。止まっているアプリは、つなぐ対象から外す候補になる
• 項目名のばらつき：同じ意味の項目が別の名前で何通りあるか。「取引先名」「顧客名」「会社名」が別アプリに散っていないか
• 権限の粒度：アプリ単位で閉じているのか、レコード単位や項目単位まで分かれているのか。分かれている場合、その条件は誰が決めたか
• 添付の中身：本当の情報が添付ファイルの中に入っていないか。見積書、議事録の写し、押印済みの申請書が添付だけで管理されていないか

この4つのうち、見落とされやすいのは3つ目と4つ目です。権限の粒度は、設定画面を見れば分かるはずなのに、誰がなぜその条件を入れたかの記録が残っていないことが多いです。条件の理由が分からないと、つなぐときに引き継ぐべきかどうかも決められません。添付は、基盤の上では一覧に並んでいるので入っているように見えますが、つないだ側から見ると中身が空です。ここは後の章で単独に扱います。

数え終わったら、結果を1枚に書いておきます。アプリ何本のうち何本を対象にする、項目名の言い換えは何組ある、権限の条件は何種類ある、添付だけで管理されている書類は何種類ある。この1枚が、後で「つないだのに使われない」と言われたときに原因を切り分ける材料になります。数えないまま始めると、うまくいかない理由をAIの精度のせいにしてしまい、直す先が見つからなくなります。

権限は3つの階層に分かれている——どれが効いているのか

後からつなぐときに一番効いてくるのが、この基盤の権限が1層ではないという点です。提供元が公開している開発者向け資料で、レコードを取り出す通信の項を読むと、その通信に必要な権限として3つが並べて書かれています。「アプリのレコード閲覧権限」「値を取得するレコードの閲覧権限」「値を取得するフィールドの閲覧権限」です。アプリに入れる、行を見る、列を見るの3段が別に判定されているということです。

この3段は、業務側の要請で自然にそうなっています。案件のアプリは営業部全員が入れるが、自分の担当分しか行が見えない。行が見えても、原価や与信の列だけは課長以上にしか見えない。こうした設定を数年かけて積み上げてきた基盤ほど、3段の組み合わせが人ごとに違う状態になっています。つなぐ側から見ると、これは「見える範囲を一言で言えない」ということです。

だから、つなぐ前に「誰に何を見せるか」を新しく決めようとすると行き詰まります。決め直すのではなく、すでに効いている3段をそのまま通すのか、通さないのかを選ぶ話になります。ここを選択の問題として扱わず、動いたから良しとしてしまうと、冒頭の「部長にしか見えないはずの案件が要約に混ざった」が起きます。次の章で、その分岐を具体に落とします。

誰の権限で読ませるか——引き継ぐ方式と、共有の資格で読ませる方式

分岐は二つです。質問した人の権限をそのまま引き継いで読ませるか、あらかじめ作った一つの資格で読ませるか。後者が選ばれやすいのは、設定が一度で済むからです。ただし提供元の資料には、その資格を使った操作について管理者による操作として扱われると書かれています。つまり、前の章で見た3段の権限は、この方式では判定の対象にならないということになります。

	利用者の権限を引き継ぐ方式	共有の資格で読ませる方式
見える範囲	質問した人が普段見えるものだけ	誰が質問しても同じ。管理者と同じ範囲になる
設定の手間	利用者ごとに入り口の用意が必要	一つ作れば全員が使える
退職と異動の反映	元の権限を止めれば読めなくなる	資格が生きている限り読める
記録に残る名前	質問した人の名前	資格の名前だけ。誰が引いたか追えない
向く使い方	担当者が自分の案件について聞く	全社の集計を決まった形で定期的に出す

表の下2行が、選ぶときの決め手になります。共有の資格は「誰が引いたか追えない」ので、後から範囲を絞りたくなったときに、誰の利用を止めればよいかが分からない状態になります。資料には、1回の呼び出しで並べられる資格は9個までで、10個以上を指定するとエラーになるとも書かれています。つまり資格を細かく作って使い分ける方向にも上限があります。細分化で逃げ切れる問題ではない、と読んだほうがよいところです。

共有の資格で読ませたときに、静かに起きる4つのこと

共有の資格が悪いというより、この方式でしか成り立たない使い方があるので選ばれます。問題は、読ませるだけのつもりで選んだ結果として何が起きるかを知らないまま運用に入ることです。実際に見かける型は次の4つです。

• 見えないはずの行が要約に混ざる——質問した人には見えない担当外の案件が、合計や傾向の中に入って返る。個別のレコードは出てこないので、混ざったこと自体に気づけない
• 見えないはずの列が根拠として引かれる——原価や与信の列を根拠にした説明が返り、読んだ人がその数字を知っている前提で会話が進む
• 退職者や異動者の分の読み取りが止まらない——基盤の側で権限を止めても、資格の側は生きているので、その資格を使う入り口から読み続けられる
• 記録が全部同じ名前で残る——誰が何を聞いたかが追えないので、情報の持ち出しが疑われたときに範囲を切り分けられない

4つに共通するのは、どれも動作としては正常で、記録の上でも失敗として残らない点です。止まる失敗なら通知が飛びますが、この型は成功として記録されます。だから運用に入ってから見つけるのは難しく、見つかるきっかけは「なぜあの数字を知っているのか」という現場の会話になりがちです。

防ぐ手は二つあります。一つは、共有の資格で読ませる対象を、もともと全員に見えているアプリだけに限ること。3段の権限を使っていないアプリなら、方式の違いが影響しません。もう一つは、その資格が読める範囲をアプリの複製で作ることです。見せてよい行と列だけを写した別のアプリを用意し、資格はそちらだけを読む。手間は増えますが、見えてはいけないものが混ざる経路が物理的に消えます。

読ませるだけと、書き戻させるのを同じ設定で扱わない

読ませるところが動くと、次に「更新もさせたい」という要望が出ます。問い合わせの内容から分類の列を埋める、案件の要約を備考の列に書く、重複しているレコードに印を付ける。どれも人手でやると重い作業なので、要望としては自然です。ただし、読ませる設定と書かせる設定は、同じ延長線上にありません。

提供元の資料には、資格に対して実行できる通信の種類を制限できると書かれており、例として「レコード取得は実行できるが、レコード更新は実行できない」という設定が挙げられています。初期状態ではレコード閲覧にだけ許可が入っている、とも書かれています。読むと書くが最初から別の項目として分けてあるのは、そこに性質の違いがあるからです。読み取りの失敗は、間違った答えが1回返るだけで済みます。書き込みの失敗は、基盤の中身が変わって残ります。

運用上の差はもっと大きくなります。書き戻しを許すと、その基盤の履歴に「誰がいつ変えたか」として資格の名前が並びます。人が変えたのか、AIが変えたのか、AIの提案を人が承認して変えたのかが、後から区別できません。監査や取引先の確認が入ったときに、変更の理由を説明できないレコードが残ることになります。だから書き戻しは、許すかどうかではなく、許すなら何を先に用意するかで考えます。

書き戻しを許すなら、承認と履歴を先に作る

書き戻しを入れるときの順番を、作業として並べます。この順で進めるのは、後から承認を足すのがほぼ不可能だからです。動き出してしまうと、止めて設計をやり直す判断が出にくくなります。

この順で作ると、書き戻しがAIの更新ではなく、人の更新をAIが下書きした形になります。履歴に残る名前は承認した人になり、変更の理由も同じ行から読めます。手間は増えますが、増えた手間の分だけ後から説明できる状態が手に入ります。逆に、承認を挟まずに書かせると、半年後に「この値は誰が入れたのか」が分からないレコードが数千行たまった状態になります。

項目名がばらついている基盤で、AIが外す型

権限のほうを固めても、答えが合わない原因はもう一つ残ります。項目名と選択肢のばらつきです。現場が使う言葉のまま何年も足してきた基盤では、同じ意味の項目が複数の名前で並び、同じ選択肢が表記の違いで別の値として入っています。AIは、その違いが意味の違いなのか書き方の違いなのかを値だけからは決められません。

外し方には型があります。実際に見かけるのは次の4つです。

• 同じ意味の項目が別の名前で並んでいる——「取引先名」「顧客名」「会社名」が別のアプリにあり、片方だけを足して集計する
• 選択肢の表記が揺れている——「株式会社」の位置や空白の有無で別の値として数え、同じ取引先が2社として並ぶ
• 日付や金額が文字の列に入っている——「今月末」「未定」「約300万」のような値が混ざっており、並べ替えも合計もできないまま平均が出る
• 未入力と0が区別されていない——空欄を0として扱い、入力が遅れている案件を「金額なし」として集計に含める

直す順番は、全部そろえるのではなく聞かれる質問に必要な範囲だけをそろえるです。全項目の名前をそろえる工事は年単位になり、その間ずっと使えません。先に、実際に聞きたい質問を20問書き出します。その20問に出てくる項目だけを対象にすると、たいてい十数項目に収まります。言い換えの対応表を1枚作り、AIには元の項目名ではなく対応表を先に読ませる。これで、基盤の側を直さずに当たり方が変わります。

AIに任せてよい工程と、人が決める3つ

ここまでの作業のうち、AIに任せてよいものははっきりしています。第一に、探し方の言い換えです。現場の言葉で書かれた質問を、基盤にある項目名と選択肢の値に直す作業。「今月中に決まりそうな案件」を「確度の列がAまたはBで、予定日の列が当月内のレコード」に置き換える、という言い換えは、対応表を渡せば十分な精度で出ます。

第二に、集計の下書き。どの列をどう束ねれば聞かれた数字になるかの案を出させます。第三に、入力内容の不備の洗い出し。空欄、表記の揺れ、重複していそうなレコード、日付として読めない値を並べさせる作業です。この3つに共通するのは、間違っていても人が見れば分かる作業という点です。言い換えがずれていれば、返ってきた条件を読めば気づけます。不備の一覧に誤りがあっても、実物を開けば確かめられます。

人が決めるのは3つです。どのアプリを見せるか。誰の権限で読ませるか。書き戻させるかどうか。この3つに共通するのは、基盤の中を読んでも判断できないことです。どのアプリを見せてよいかは、そこに入っている情報を誰と約束して預かっているかで決まります。誰の権限で読ませるかは、社内で誰がその範囲を決める立場かで決まります。書き戻させるかどうかは、変更の説明を誰が引き受けるかで決まります。どれも基盤の外にある情報です。

だから、AIに「このアプリは読ませてよいですか」と聞かないでください。聞いてよいのは「このアプリとこのアプリは同じ項目を持っていますか」「この列に日付として読めない値が何件ありますか」までです。運用に落とすときは、人が確認する範囲を先に決めておきます。金額、日付、対象者、権限の条件。この4か所については、AIが出した値をそのまま使わないと決めてしまうのが確実です。根拠を書かせることはできますが、書かせた根拠が本当にそのレコードにあるかは、人が開いて確かめる工程が要ります。

どのアプリを見せないかを、見せるものより先に決める

対象を決めるとき、見せるものから選ぼうとすると決まりません。候補が多いうえに、業務部門はどれも必要だと言うからです。順番を逆にして、見せないものを先に確定させると早く決まります。見せない候補は、性質で分けられます。

外すのは4種類です。一つ目は、人の扱いが変わる情報が入っているアプリ。人事評価、面談記録、処分、採用の選考。二つ目は、取引先との約束で扱いが決まっているアプリ。秘密保持の対象、価格の取り決め、共同開発の記録。三つ目は、決めの途中が残っているアプリ。稟議、与信の判断、値引きの相談。四つ目は、持ち主が分からないアプリです。誰が作ったか分からず、更新も止まっているものを対象に入れると、中身の説明ができません。

なお、個人情報が入っているかどうかの判断は、この対象決めとは別の手順です。氏名の有無だけで決まる話ではなく、取得したときに伝えた使い道の中に入っているか、渡した先がどう扱うかまで含めて判定します。その手順自体はここでは扱いません。見せないアプリを決める作業と、個人情報の判定は、別々に通すと覚えておいてください。対象から外れたアプリについては、個人情報の判定を通す必要がありません。先に外しておくほうが、判定にかける手間も減ります。

一度に読める件数には上限がある——「全体の集計」が合わない理由

静かな失敗のうち、最も見つけにくいのが件数です。提供元の資料でレコードを取り出す通信の項を読むと、一度に取得できる件数について初期値は100件、一度に取得できるレコードは500件までと書かれています。続きを読むために位置をずらす指定にも上限があり、その上限は10,000件と明記されています。つまり、素朴につないだだけでは1万件を超えるアプリの全体を読み切れません。

ここで起きるのが、読めた分だけで答えが作られ、読めなかった分は黙って落ちるという型です。「今年の受注合計を出して」と頼むと、エラーは出ずに数字が返ります。その数字が最初の500件分なのか全件なのかは、返ってきた文章からは分かりません。1万件を超える分を読むには別の取り出し方が必要で、それを組み込んでいないつなぎ方は、件数が増えた時点から静かに間違い始めます。つないだ直後は正しかったのに、半年後に合わなくなるのはこの理由です。

もう一つ、キーワードで絞り込むときの制限も書かれています。絞り込みにキーワード検索を使う場合、キーワードを含むレコードが100,000件に達した時点で検索を打ち切るという記述です。よく使われる語で絞ると、打ち切られた側が結果に入りません。対策は仕組みの側で二つあります。一つは、聞ける質問を件数の上限に収まる範囲に限ること。期間や部署で先に絞った条件だけを許す形にします。もう一つは、答えと一緒に読んだ件数を必ず出させることです。件数が表示されていれば、500や10,000という数字が出た時点で人が気づけます。

添付ファイルの中身は、つないだだけでは読めない

つないだ後に必ず出るのが、添付の話です。基盤の一覧には添付が並んでいるので、中身も読める前提で質問されます。「先月の見積書の中で、割引を入れたものを教えて」のような質問です。ところが、レコードを取り出す通信で返るのは添付の名前や識別のための値であって、ファイルの中身そのものではありません。読むには、添付を1件ずつ取り出して文字に直す工程を別に足す必要があります。

ここが問題になるのは、業務の実態として本当の情報が添付の中だけにある基盤が珍しくないからです。レコードの列には取引先と日付と金額だけが入っていて、条件や特記事項は添付した書類の中にある。この状態でつなぐと、AIは列に入っている分だけで答えるので、条件を無視した答えが返ります。しかもこれは、質問した人からは「読んだうえで答えた」ように見えます。

進め方は二つに分かれます。添付の中身まで扱うと決めるなら、対象を絞ってから工程を足します。全部の添付ではなく、質問が集まる1種類の書類だけを文字に直して別の列に入れておく形です。扱わないと決めるなら、そのことを利用者に先に伝えます。「添付の中は読んでいません」と表示しておけば、読んだ前提の質問が減ります。どちらを選ぶかより、どちらなのかを決めて伝えてあることが効きます。

提供元が用意した機能を使うか、自分でつなぐか

選択肢は、外から自分でつなぐ形だけではありません。提供元のサイボウズは2026年4月22日の発表で、この基盤のAI機能を正式版として提供すると公表しています。発表には、提供開始が6月14日の更新であること、対象がスタンダードコースまたはワイドコースの契約であること、利用量に上限を置く仕組みを導入することが書かれています。追加で利用量を買える有償の選択肢については、2026年秋頃の提供開始を予定するとされています。

この二つは、機能の優劣で選ぶものではありません。決まり方が違います。提供元が用意した機能を使う場合、権限の扱いは基盤の中の仕組みとして処理されるので、前の章で見た共有の資格の問題が出にくくなります。その代わり、できることの範囲と使える量が提供側の条件で決まります。自分でつなぐ場合はその逆で、範囲は自由に決められますが、権限の3段をどう通すかを自分で設計することになります。

だから判断は「どちらが優れているか」ではなく、自社が引き受けられるのはどちらの手間かで決めます。権限の設計と、その後の追随を引き受けられる人が社内にいるなら、自分でつなぐ形は範囲の自由が効きます。いないなら、提供元の仕組みの中で収まる質問だけに絞るほうが安全です。両方を並行して持つのも実務では起こりますが、そのときは同じ質問に違う答えが返る前提で、どちらを正とするかを先に決めておきます。

つないだあとに増える運用——追随、退職者、記録

つないだ時点で終わりではありません。この基盤は業務部門が自分でアプリを増やせる性質なので、つないだ後も対象が動き続けます。増える運用は3つに集約できます。アプリが増えたときの追随、人が抜けたときの権限、そして記録の残し方です。この3つを誰の仕事にするかを決めていないと、半年で実態とずれます。

この一覧のうち、実際に抜けやすいのは最後の2つです。外した理由の記録がないと、「なぜこのアプリは対象外なのか」を誰も説明できなくなり、次の担当が対象に入れてしまいます。答えの確かめ方は、動いているうちは誰も必要性を感じない工程なので、最初に月次の予定として入れてしまうのが確実です。件数の上限による静かなずれは、手で計算した数字と並べたときにだけ見えます。

まとめ

すでに業務データが溜まっている基盤にAIをつなぐときは、一から組むのとは制約が違います。項目名は数年分の運用でばらつき、権限はアプリ、レコード、項目の3段に分かれ、似たアプリのどれが正かは部署ごとに違っています。この3つのうち、つなぐ前に必ず固めるのは権限です。共有の資格で読ませる方式は、提供元の資料が書くとおり管理者としての操作になるため、積み上げてきた3段の権限が判定の対象から外れます。見えないはずの行や列が要約に混ざり、しかも記録の上では成功として残ります。

読ませるだけと書き戻しは、同じ設定の延長ではなく別のものとして扱います。書き戻しを許すなら、更新してよい列を名指しし、提案の列と確定の列を分け、根拠を同じ行に残し、止める条件を役割名で決めてから始めます。件数には上限があり、一度に取り出せるのは500件、位置をずらす指定は10,000件までなので、全体の集計を頼むと動いたまま合わない答えが返ります。答えと一緒に読んだ件数を出させるだけで、人が気づけるようになります。

AIに任せてよいのは、探し方の言い換え、集計の下書き、入力内容の不備の洗い出しまでです。どのアプリを見せるか、誰の権限で読ませるか、書き戻させるかどうかは人が決めます。どれも基盤の中を読んでは判断できず、誰と約束して預かっているか、社内で誰が決める立場か、変更の説明を誰が引き受けるかで決まるからです。金額、日付、対象者、権限の条件の4か所には、AIが出した値をそのまま残さない。この線を先に引いておけば、つなぐ範囲を広げるほど答えが信用できる形に変わります。

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