「Kintoneで案件は管理できている。でも、メールで来る問い合わせを読んで分類し、過去の似た案件を探し、返信を書くところは相変わらず人が全部やっている」——この非定型な部分こそAIエージェントが効く領域です。一方で、レコードの書き戻しやステータス変更、社外への送信は、権限設計と人の承認なしに任せてはいけない領域でもあります。その境界の引き方を整理します。
結論から言えば、Kintoneを「記録とプロセスの土台」として残し、AIエージェントは「非定型な入力を扱う前工程と、人が判断するための材料づくり」に限定する——この線引きが最も破綻しにくいと考えられます。土台を置き換えようとすると、権限・履歴・承認フローという既存の統制まで作り直すことになり、投資もリスクも一気に膨らむためです。
Kintone（サイボウズ社の業務アプリ基盤）は、フォームで項目を定義し、レコードとして蓄積し、段階と担当者を持つプロセスとして回すことに向いています。誰がいつ何を変えたかが残り、アクセス権も設定できます。これは業務システムとして重要な性質であり、AIを入れるからといって手放す理由はないと考えます。
多くの現場で人手が残っているのは、レコードになる「手前」です。メールの本文、電話メモ、添付されたPDFやExcel、フォーム外の自由記述——これらは書式が定まらないため、フォームの項目に落とすには人が読んで解釈する必要があります。さらに、レコードになった後も「過去に似た案件はなかったか」「この規程ではどう扱うのか」を探す作業が残ります。AIエージェントが価値を出しうるのは、まさにこの読解と検索の部分だと考えられます。社内システム全般への接続の考え方はAIエージェントと社内システムの連携設計でも整理しています。
判断の軸はひとつです。「間違えたときに、あとから取り消せるか」。取り消せる操作は自動化してよく、取り消しにくい操作は人の承認を挟む——この基準で分けると、議論が個人の好みに流れにくくなると考えられます。
AIエージェントに「何ができるか」を一般論として整理したものはAIエージェントにできることに、問い合わせ対応そのものの分解は問い合わせ対応をAIで効率化にまとめています。本記事はそれらを、Kintoneのような業務アプリ基盤を土台に持つ前提へ落とし込む視点で扱います。
実装の細部は各社で変わりますが、安全側に倒した流れの型はほぼ共通だと考えられます。要点は、AIの出力が人の承認を通過するまでは業務データに触れないこと、そして最後に必ず記録が残ることです。
AIの出力は確率的で、同じ入力でも表現が揺れます。にもかかわらず、業務システムのレコードは「確定した事実」として扱われ、集計や後続処理の入力になります。この性質の違いを吸収する場所が、⑤の承認だと考えられます。承認を省いて④から⑥へ直結させると、確からしくない値が確定値として下流に流れ、どこで間違えたのかを後から辿るのが難しくなりうると考えます。
承認を挟む設計で失敗しやすいのは、承認が形骸化することです。件数が多すぎる、判断材料が足りない、承認画面と業務画面が分かれている——こうした条件が重なると、人は中身を見ずに承認するようになります。AIの提案には必ず根拠（どのレコード・どの文書のどこを見たか）を添え、確からしさが低いものだけを人の目に集める設計が現実的だと考えられます。人へ引き継ぐ場面の作り方はAIから人へのエスカレーション運用で詳しく扱っています。
あります。むしろ「ルールで書けることは、ルールで書いたほうがよい」と考えます。挙動が読め、保守でき、説明もしやすいためです。AIを検討する前に、次の比較で自社の状況がどこに当たるかを確認することをおすすめします。
| 手段 | 得意なこと | これで足りる場合 | 限界・注意点 |
|---|---|---|---|
| 入力フォームの構造化（項目を分ける） | 最初から機械可読な形で集める | 依頼元に入力形式を守ってもらえる場合 | 社外や取引先には形式を強制しづらい |
| 標準のプロセス管理・条件通知 | 決まった段階と担当者で確実に回す | 申請〜承認の流れが定型で、分岐を言葉で書ける場合 | 書式が定まらない入力そのものは扱えない |
| プラグイン・拡張 | 画面・集計・入力補助の不足を埋める | 必要な機能が既製品で満たせる場合 | 提供元の保守方針とバージョン追随に依存する |
| RPA | 固定手順の画面操作を反復代行する | 手順が固定で、画面がほとんど変わらない場合 | 画面変更で止まりやすく、判断を伴う作業は不得意 |
| AIエージェント | 非定型な文章・書類の読解、分類、検索、下書き | 入力が非定型で、人の一次読解に時間がかかる場合 | 出力は確率的。権限・承認・ログの設計が前提になる |
現実的な順序は、①入力を構造化できないかを先に検討する → ②分岐を言葉で書き切れるなら標準機能・プラグインで組む → ③固定手順の画面操作だけが残るならRPAを検討する → ④それでも「読んで意味を取る」作業が残るならAIエージェントを検討する、という流れだと考えられます。AIエージェントとチャットボット・RPAの守備範囲の違いはAIエージェントとチャットボット・RPAの違いで整理しています。
なお、SaaS・古い基幹・紙が同居する環境では、システム統一を待つより「読み取って構造化する層」を先に置くほうが早いことが多いと考えられます。この順序の考え方はSaaS・古い基幹・紙が混在する環境で扱っています。
結論として、接続方式の可否は机上では決め切れず、自社テナントでの検証が前提になると考えられます。同じ製品を使っていても、契約プラン、有効化されている機能、管理者が設定したアクセス制限、扱うデータの機密区分によって、できることが変わるためです。ここを「一般にできるはず」で進めると、設計が終わった後にセキュリティ審査で差し戻されることになりかねません。
権限やセキュリティ方針の都合でAPI接続が難しい場合でも、選択肢が消えるわけではないと考えられます。CSVの書き出し・読み込みや、ファイル置き場を介した受け渡し、定期バッチといった枯れた方式が使えることは多く、初期はむしろこちらのほうが承認を取りやすい場合があります。APIを前提にしない連携の考え方はAPIがない基幹システムとの連携にまとめています。紙やPDFの帳票を項目に落とす部分は電子帳票とOCRの連携も参考になると考えます。
設計の原則は「読み取りから始め、必要になった分だけ権限を足す」ことだと考えられます。最初から更新権限を持たせると、想定していなかった経路で書き込みが起き、原因の切り分けが難しくなりうるためです。
権限設計の具体的な考え方はAIエージェントの権限設計、自動と承認の境界の引き方は任せる範囲と承認ポイントの設計で詳述しています。
後から説明できる状態を作るには、結果だけでなく過程を残す必要があると考えられます。具体的には、AIが参照した情報、提示した候補、人が採用したか修正したか、誰がいつ承認したか、そして使用したモデルや設定の版です。これらを残しておくと、誤りが起きたときに「AIの読み違いか、根拠情報が古かったか、承認が甘かったか」を切り分けられます。ログを取るだけで終わらせない運用はAI利用ログを監査に活かすで扱っています。
いずれも、最初の設計で少し手当てしておけば避けやすいと考えられる項目です。
次の項目に自社の言葉で答えられる状態になっていれば、設計を始めてよい段階だと考えられます。逆に、空欄が多いまま実装に入ると、後戻りが大きくなりがちです。
順序としては、①1業務に絞った現物収集と実測 → ②読み取り専用での提示だけを試す → ③下書きを人が承認する運用を回す → ④誤りの傾向を見て範囲を調整、という段階を踏むのが現実的だと考えられます。最初から全社展開や全自動化を狙わないほうが、失敗の被害も学習コストも小さく抑えられると考えます。範囲の切り方はAIエージェントPoCのスコープ設計を参考にしてください。
Nsightは、紙・PDF・写真といった書式の定まらない情報を読み取って構造化する領域と、その結果を既存の業務システムへどう渡すかの設計を得意としています。特定製品の公式な連携機能を提供しているわけではありませんが、既存の業務基盤を作り替えずに、どこから小さく試せるかを一緒に整理することはできます。AIエージェントの全体像はAIエージェント基盤もあわせてご覧ください。効果や適用可否は現物・現場での検証が前提であり、まずは小さく試すことをおすすめします。
実際に何が使えるかは、契約しているプラン、バージョン、テナントの設定、管理者が許可している範囲によって変わります。一般論としては、標準機能・追加のプラグイン・外部システムとのAPI連携という三つの層があり、どこまでを標準で賄えるかは自社環境で確認する必要があります。本記事は特定製品の機能を保証するものではないため、まず自社のテナントで何が有効になっているかを情報システム部門で棚卸しすることをおすすめします。
いきなり更新権限を渡すのは避けるのが無難だと考えられます。読み取りと下書き生成までを自動化し、レコードの更新・ステータス変更・社外への送信といった取り消しにくい操作は人の承認を挟む設計から始めるほうが安全です。運用が安定し、どの操作が定型的で誤りにくいかが実測で見えてから、範囲を限って自動化を広げる順序が現実的だと考えます。
件数が多く、判断基準が比較的はっきりしていて、間違えても取り返しがつく業務から始めるのが安全だと考えられます。たとえば、問い合わせの分類と担当部署の振り分け候補の提示、過去の類似案件の検索、返信文の下書き作成などです。逆に、契約・請求・与信・人事に関わる判断や、社外へ直接届く送信は、最初の対象から外しておくことをおすすめします。
入力がすでにフォームで構造化されていて、分岐条件が言葉で書き切れる場合は、標準のプロセス管理や条件通知、プラグイン、RPAで足りることが多いと考えられます。AIエージェントが効くのは、メール本文や添付ファイルのように書式が定まらない情報を読み取って意味づけする必要がある場面です。ルールで書けるものをわざわざAIに任せると挙動が読みにくくなり保守も難しくなるため、まずルールで書けるかを先に検討することをおすすめします。
どのデータが、どの経路で、どこまで外に出るのかを先に確認することだと考えます。具体的には、AIに渡す項目の範囲、実行に使う認証情報とその権限、通信経路とアクセス制限、ログの保存場所と保存期間、そして委託先や再委託先の扱いです。これらは契約や社内規程、業界の要件によって結論が変わるため、一般論ではなく自社のセキュリティ部門と個別に確認する前提で進めることをおすすめします。
本記事は、特定製品との公式な連携機能の提供を告知するものではありません。Nsightが得意とするのは、紙やファイルなど書式の定まらない情報を読み取って構造化する部分と、その結果を既存の業務システムへどう渡すかの設計です。既存の業務基盤を作り替えずにどこから小さく試せるかを一緒に整理することはできますので、まずは現物の書類と現行フローを見せていただくところから始めるのが確実だと考えます。
既存の業務基盤はそのままに、非定型な入力のどこから小さく試せるかを、現物の書類と現行フローに即して整理します。AI導入・業務自動化・内製化支援について、まずはお気軽にご相談ください。
問い合わせ業務の自動化設計を相談する