フィールド制御とセマンティックレイヤー
最終更新: 2026-07-08
このページは、Fluxon管理者や情報システム部門が、AIに見せる情報の範囲と、AIが業務データを理解しやすくする設計を考えるための説明です。
まず押さえること
FluxonでAIにkintoneを使わせるとき、管理者が考えるべきことは大きく2つあります。
| 考えること | 目的 |
|---|---|
| フィールド制御 | AIに見せてよい情報、隠す情報、書き換えてよい情報を決める |
| セマンティックレイヤー | kintoneのアプリやフィールドの業務上の意味をAIが理解しやすくする |
フィールド制御は「守るための設定」、セマンティックレイヤーは「正しく使うための説明」と考えると理解しやすいです。
フィールド制御とは
フィールド制御は、kintoneアプリのフィールドごとに、AIへどのように扱わせるかを決める機能です。
代表的な制御:
| 制御 | 内容 | 例 |
|---|---|---|
| 読み取り可能 | AIに値を返してよい | 会社名、案件ステータス、受注予定日 |
| 非表示 | AIに値を返さない | 個人携帯番号、個人住所、秘匿メモ |
| マスク | 値の存在は示すが内容は隠す | 契約金額の詳細、評価コメント |
| 書き込み可能 | AI経由で更新してよい | 対応ステータス、社内コメント |
| 書き込み不可 | AI経由で更新させない | 請求金額、承認日、契約番号 |
なぜフィールド制御が必要か
kintoneのアプリには、同じ画面にさまざまな性質の情報が入っています。
たとえば顧客管理アプリには、AIで検索・集計したい会社名や業種のほかに、個人の連絡先、社内評価、契約条件なども含まれることがあります。
Fluxonでは、kintoneの権限を基本にしながら、AI利用に合わせてさらに細かく制限できます。
設計の進め方
1. アプリを分類する
まず、AIから使わせるアプリを分類します。
| 分類 | 方針 |
|---|---|
| 利用しない | AIからの利用を拒否する |
| 読み取りだけ | 検索、要約、集計だけ許可する |
| 一部書き込み可 | コメント追加、ステータス更新など限定的に許可する |
| 管理者のみ | アプリ設定変更や構築補助など管理者だけにする |
2. フィールドを分類する
次に、アプリ内のフィールドを分類します。
| 分類 | 判断の目安 |
|---|---|
| AIに見せてよい | 業務上の検索、要約、集計に必要で、社内ルール上問題が少ない |
| 条件付きで見せる | 業務上必要だが、部署や利用者を限定したい |
| マスクする | 件数や有無は使いたいが、中身を見せたくない |
| 見せない | 個人情報、機微情報、秘匿メモ、不要な内部管理情報 |
| 書き込み可能 | AIに更新させても業務リスクが低く、誤更新時に戻しやすい |
| 書き込み不可 | 金額、契約、承認、請求、法務、個人情報など慎重に扱う |
3. レコード条件を考える
フィールドだけでなく、レコード単位の条件が必要な場合もあります。
例:
- 自部署の案件だけ。
- 完了済みのレコードは読み取りのみ。
- テスト用アプリだけ書き込み可。
- 一定期間より古い問い合わせは対象外。
4. 件数上限を決める
AIへ大量のレコード本文を返すと、情報量が多すぎて扱いにくくなり、セキュリティ面でも望ましくありません。
件数確認や傾向把握には、本文取得ではなく集計系ツールを使う運用にします。
例:
- 件数だけなら件数確認。
- ステータス別の傾向なら集計。
- 明細が必要な場合だけ、必要フィールドを絞って少数件取得。
セマンティックレイヤーとは
セマンティックレイヤーは、kintoneのアプリやフィールドに、AIが理解しやすい業務上の意味を与える層です。
AIは、フィールドコードだけを見ても業務上の意味を正しく判断できないことがあります。
例:
| kintone上の名前 | AIが理解すべき意味 |
|---|---|
amount_est | 見込み金額 |
rank | 顧客ランク |
status | 商談ステータス |
next_action_date | 次回対応予定日 |
internal_note | 社外共有しない社内メモ |
セマンティックレイヤーでは、このような意味を整理して、AIが誤解しにくい状態にします。
セマンティックレイヤーで整理する情報
| 項目 | 説明 |
|---|---|
| アプリの業務名 | 「案件管理」「問い合わせ管理」など利用者が自然に呼ぶ名前 |
| アプリの目的 | 何を管理するアプリか |
| 主要フィールド | AIに優先して使わせたいフィールド |
| フィールドの意味 | 業務上の意味、単位、値の読み方 |
| 集計軸 | 月別、担当者別、ステータス別などよく使う切り口 |
| 注意すべきフィールド | 個人情報、社内メモ、誤更新リスクが高い項目 |
| 推奨プロンプト | 利用者がどう依頼するとよいか |
実務でのおすすめ設計
営業・案件管理
AIに見せやすい:
- 顧客名
- 案件名
- ステータス
- 担当者
- 受注予定日
- 見込み金額
注意が必要:
- 契約条件の詳細
- 値引き理由
- 社内評価
- 個人連絡先
問い合わせ管理
AIに見せやすい:
- 問い合わせ種別
- ステータス
- 受付日
- 担当者
- 回答期限
注意が必要:
- 問い合わせ本文に含まれる個人情報
- 認証情報や秘密情報が書かれたメモ
- クレーム詳細
人事・労務
原則として慎重に扱います。AI利用の対象外にする、または強いフィールド制御を設定することを推奨します。
注意が必要:
- 評価
- 給与
- 勤怠の詳細
- 健康情報
- 個人住所
利用者に案内するとよいこと
利用者には、次のように伝えると安全に使いやすくなります。
- アプリ名は正式名称または管理者が案内した名前で指定する。
- 必要なフィールドだけを指定する。
- 件数や傾向を知りたいときは、明細ではなく集計を依頼する。
- 書き込みを依頼するときは、対象レコードと変更内容をAIに復唱させる。
- AIが「権限がありません」と言った場合は、無理に回避しようとせず管理者へ確認する。
設定後の確認
フィールド制御を設定したら、テスト利用者で次を確認します。
- 許可したフィールドだけがAIに返る。
- 非表示フィールドが返らない。
- マスク対象がマスクされる。
- 非許可フィールドで検索や並び替えができない。
- 書き込み不可フィールドを更新しようとすると拒否される。
- 監査ログで拒否や実行が確認できる。
よくある失敗
kintone権限だけで十分だと思ってしまう
kintone権限は重要ですが、AI利用では「同じ画面にある項目をAIにまとめて見せてよいか」という追加の判断が必要です。
フィールド名がわかりにくいまま使い始める
AIが誤解しやすくなります。主要アプリから順に、業務名、フィールドの意味、推奨プロンプトを整備してください。
書き込みを広く許可しすぎる
最初は読み取りと集計を中心にし、書き込みはコメント追加やステータス更新など限定的な操作から始めます。