昨年の秋、ある物流企業のDX担当者と、並んでkintoneの画面を眺めていました。受注も在庫も問い合わせ履歴も、すべてkintoneのアプリに集約されている環境です。その担当者は前夜、「kintone AI / kintone できること / kintone 制限」と検索窓に打ち込み、どこまで任せられるのかを確かめようとしていたと打ち明けてくれました。

そこへAI機能が加わり、担当者が「先月の返品案件を探して」と話しかけると、蓄積レコードから該当データがすぐに返ってきます。社内に貯まった情報を扱わせるかぎり、kintone AIの応答は的確でした。

私がその場で尋ねたのは、一歩外側の話です。「このAIに、SAP側の在庫を確認させて、そのまま出荷指示まで出させることはできますか」。担当者はしばらく黙り、「そこは、たぶん無理ですね」と答えました。

この「たぶん無理」の輪郭を、技術的にきちんと引く。それが、kintone上でAI活用を検討している現場でいま最も必要な作業だと考えています。kintone AIは優秀です。ただし優秀さには設計上の境界があり、そこを曖昧にしたまま期待だけが膨らむと、PoCは「思ったより動かなかった」で終わってしまいます。

kintone AIは実際のところ何ができるのか？

結論から言えば、kintone AIが得意とするのは、kintoneアプリの中に蓄積されたデータを対象にした検索・要約・分類・下書きの生成です。話しかけて過去レコードを探す、長いスレッドを要約する、入力内容から分類やルート先を提案する。このあたりは、実務で確実に効きます。

具体的な動きは、大きく四つに整理できます。自然言語での検索では「先月の返品案件」と打てば該当レコードが絞り込まれます。要約は、長いコメントの流れや複数レコードの内容を短くまとめてくれる機能です。分類やルーティングの提案なら、問い合わせ本文から担当部署を推定してもらえるでしょう。そして下書き生成が、定型の返信文や社内報告の初稿を用意します。

いずれも、kintoneというデータの器がしっかりしているからこそ成立する働きです。アプリ設計でフィールドが整い、入力ルールが効いていれば、AIが扱う材料の質も上がります。逆に、フリーテキストばかりで項目が荒れていると、同じAIでも精度は落ちます。ここは素直に、kintoneの強みと言っていい部分でしょう。

私が現場で評価しているのは、この「社内の文脈を踏まえた応答」の精度です。汎用のチャットAIは、自社の受注ルールも取引先の略称も知りません。一方でkintone AIは、自社アプリの中を見て答えを組み立てます。つまり社内データの内側においては、十分に働き手になり得るのです。

先ほどの物流企業でも、過去の返品理由をまとめさせたり、問い合わせを担当チームへ振り分ける下地を作らせたりする用途では、担当者は明らかに手が軽くなったと話していました。この価値は、外側の話とは切り離して、まず正当に認めておきたいところです。

ただ、ここで一つ気づいておきたい点があります。kintone AIができるのは、多くの場面で「提案」や「下書き」までだということです。担当部署を推定してくれても、実際に振り分けて次のシステムへ渡すのは、人かワークフローの役目になります。内側の作業ですら、AIは判断を助け、実行は別の担い手が受け持つ。この役割分担が、そのまま外側の話へつながっていきます。

なぜkintone AIは「社内データの外側」で止まるのか？

kintone AIが外側で止まるのは、性能の不足ではなく設計の前提によるものです。kintone AIは基本的にkintoneが保持するデータを対象に動くため、SAPやECサイト、外部SaaSがリアルタイムに持っている情報や、それらのシステムへ書き込む操作は、はじめから守備範囲の外に置かれています。

ここには二つの壁があります。ひとつは、データの所在です。kintone AIが読めるのは、kintoneアプリに入っているデータに限られます。SAPの在庫テーブルやECの注文データがkintoneへ同期されていなければ、AIはその存在すら知りません。「見えないもの」には、答えようがないのです。

わかりやすいのが在庫の例でしょう。実在庫はSAPや倉庫管理システムにあり、kintoneには一部の集計しか入っていないとします。この状態でkintone AIに在庫を尋ねても、返ってくるのはkintoneが持っている範囲の数字だけです。最新の実在庫とずれていても、AIはそのずれ自体を知りません。所在の壁とは、この「AIから見えている世界の狭さ」のことなのです。

もうひとつは、動作の種類です。検索も要約も下書きも、いずれもデータを読んで答えを生成する動きにとどまります。ところが、外部システムへ在庫を書き戻す、出荷指示を発行する、請求データを更新するといった「実行」は、別のレイヤーの仕事です。ここを混同すると、「AIが答えてくれた」ことを「AIが処理してくれた」と取り違えてしまう。この取り違えこそ、PoCの失敗で私が最もよく見る形です。

技術的に言い換えれば、kintone AIは自社データベースの内側に閉じた参照エンジンとして設計されています。閉じていること自体は、欠点ではありません。データの範囲がはっきりし、挙動が読みやすく、権限管理もしやすいからです。ずれが生じるのは、受発注や在庫や物流のように、業務そのものが複数システムと外部の状態にまたがっているときです。業務は外側へ広がっているのに、AIだけが内側に閉じている。この不一致が、「思ったより動かない」の正体だと考えています。

できること・できないことを、どこで線引きするのか？

線引きの基準は三つあります。データの所在が内か外か、動作の種類が参照・生成か実行・連携か、そしてリアルタイム性が過去の蓄積かいまの状態か。この三軸で並べると、kintone AIの守備範囲と、その外側の境界がはっきり見えてきます。

この表で見てほしいのは、左と右が優劣ではなく、役割の違いだという点です。左側はkintoneが得意とする領域で、ここを無理に置き換える必要はありません。厄介なのは、右側を「kintone AIがいずれやってくれる」と期待して待ってしまうことです。右側はそもそも、別の設計を前提とする領域なのです。

たとえば、ECで注文が入った瞬間にkintoneの在庫を引き当て、足りなければSAPへ発注をかけ、出荷指示を倉庫システムへ流す。この一連は、三軸のいずれから見ても右側に位置します。データは外にあり、動作は実行で、反応すべきは過去ではなくいまの状態です。ここをkintone AIの延長で解こうとすると、どこかで必ず手が止まります。

この線引きは、要件定義の場でそのまま使えます。やりたいことを一つ挙げたら、三軸のどこに落ちるかを先に確かめる。左側に収まるならkintoneの設定で足り、右側にはみ出すなら外側の設計が要ります。この仕分けを最初にやっておくと、後から「できると思っていた」で発生する手戻りを、かなり減らせるはずです。

「参照」と「実行」は何がどう違うのか？

参照は「読んで答えを作る」動き、実行は「外部の状態を変える」動きです。この二つの間には、権限・制御・監査という、無視できない技術的な段差があります。AIエージェントの実務的な価値は、この段差を越えて実行まで到達できるかどうかにかかっています。

参照だけなら、仮に失敗しても答えが間違うだけで、業務データそのものは傷つきません。ところが実行は、在庫を減らし、注文を確定し、取引先へ通知を飛ばします。外部システムの状態を、実際に動かしてしまうのです。だからこそ効いてくるのが、制御ポイントという考え方になります。どの操作を、誰の権限で、どの条件のときだけ許すか。これを一つひとつ設計しておかないと、自動化はそのまま事故に化けます。

制御ポイントを具体化すると、たとえば「一定金額までの発注は自動、それ以上は承認者を挟む」「在庫の書き戻しは一日一回のバッチに限る」といった条件になります。数量や金額や時間帯で線を引き、危ないところだけ人を残す。全自動か手作業かの二択ではなく、その中間をどれだけ細かく設計できるかが、実務の勘所です。

私がクライアントによく伝えるのは、「ChatGPTは答えます。WindyFloは働きます。」という一文です。答えるところまでなら、いまや多くのツールがこなせます。差がつくのは、答えたあとに外部システムへ手を伸ばし、実際の処理を完了させ、その一連を後から追える記録として残せるかどうか。参照から実行へ渡るこの一線が、AIエージェントを名乗れるかどうかの分かれ目です。

CTOとして外せないのが、分離の設計です。実行を担うレイヤーは、認証情報や実行権限を、業務ユーザーの画面から切り離して保持すべきだと考えています。誰が何をいつ実行したのかを監査ログで追えるようにし、必要ならデータの保持場所を選べる構成にしておく。実行できることと、実行を任せてよいことは、別の問題なのです。

監査ログにこだわるのには、運用というより責任の理由があります。導入を主導した立場からすると、あとで「なぜこの処理が走ったのか」を説明できることが、そのまま自分の守備範囲を守ることにつながるのです。実行の一つひとつに記録が残っていれば、経営層への報告も、トラブル時の切り分けも、推測ではなく事実で進められます。ここが弱いまま自動化を広げるのは、私なら止めます。

kintoneを活かしたまま「外側」をどう設計するのか？

現実的な答えは、kintoneを捨てることではありません。kintoneを社内データの正本として残したまま、その外側に実行レイヤーを重ねる構成です。kintoneが記録を担い、AIエージェントが外部連携と実行を担う。この二層に分ければ、これまでの投資を無駄にせず、外側の課題だけを切り出して解けます。

考え方としては、記録の層と実行の層を分けるだけです。kintoneは、業務データが最終的に正しく揃う場所、いわば記録の中心であり続けます。その上に、外部システムへ届く実行の層を重ねる。kintoneを土台の記録係、エージェントを外回りの実行係と役割で呼び分けると、設計の議論が一気に整理されます。

具体的な流れを、EC受注の例で追ってみましょう。ECで注文が入ると、まずkintoneにレコードが起きます。エージェントはそれを受けて、SAP側の実在庫を参照します。引き当てが立てば、出荷指示を倉庫システムへ渡す。この時点で、社内データの外側にある二つのシステムに、実行が届いています。

在庫が足りなければ、エージェントが発注の下書きを作り、承認を挟んでから発注まで進めます。処理の結果は、そのつどkintoneへ書き戻される仕組みです。担当者はいつものkintone画面で状況を追えばよく、外側で何が起きたかも、監査ログをたどれば分かります。役割を分けても、見る場所は一つにまとめられるのです。

WindyFloが担うのは、まさにこの実行レイヤーです。ノーコードで連携フローを組み、主要な基幹系やSaaSとつなぎ、実行の一つひとつに制御ポイントと監査ログを持たせる。運用は日本語で完結し、開発チームを常駐させなくても、業務チームの側で管理できます。データの取り扱いに厳しい業種に向けては、保持の仕方を選べる設計も用意しています。ここはkintoneの置き換えではなく、kintoneが届かない外側を埋める補完だと捉えてください。

この構成には、成果を早く見せられるという利点もあります。二層に分けておけば、まず一つの実行だけを本番に乗せ、そこで生まれた時間や精度を数字で示せます。経営層から「AIの成果を早く」と求められている現場ほど、この小さく確実に見せられる設計が効いてくるはずです。全体を一気に自動化するより、外側の課題を一つずつ潰すほうが、結局は速いのです。

kintoneとSAP・外部システムを具体的にどうつなぐかは、[kintoneとSAP・外部システムをAIエージェントでつなぐ実装シナリオ](/ja/blog/kintone-sap-ai-renkei/)の記事で、工程ごとに制御ポイントを添えて整理しています。二層構成のイメージを、より実装寄りに掴みたい方はそちらを参照してください。

導入前に確認しておくべき技術チェックポイントは？

外側の設計へ進む前に、確認しておきたい技術的な論点は四つです。連携先システムのAPIの有無、実行権限と制御ポイントの設計、監査ログとデータ分離の方針、そして日本語での運用主体。この四つが曖昧なまま進むと、PoCは通っても本番の直前で止まります。

ひとつ目は、つなぎたい相手に連携の口があるかどうかです。SAPやECや自社の基幹系が、外部から安全にアクセスできる経路を持っているか。ここが塞がっていると、どんなに賢いAIでも手を出せません。導入判断の一番手前で確かめておきたい論点です。

ふたつ目は、実行権限の切り分けになります。どの処理を自動で許し、どこから先は人の承認を挟むのか。金額や数量のしきい値で制御ポイントを置く設計を、導入前に描いておく。ここを描けているベンダーかどうかは、そのまま選定の分かれ目にもなります。

三つ目は、監査ログとデータ分離の方針です。誰が、いつ、何を実行したかを追える仕組みと、認証情報を業務画面から切り離す構成。データの越境に敏感な業種であれば、保持場所を選べるかどうかも判断材料に加わります。ここは技術部門だけでなく、情報セキュリティの担当と一緒に見てほしいところです。

四つ目は、運用の主体と言語です。連携基盤を、開発者しか触れない状態にするのか、業務チームが日本語で管理できる状態にするのか。この選択が、導入後の運用コストとベンダー依存度を大きく左右します。物流や製造の現場で複数システムをまたぐ具体的な連携像は、[物流3PLの配車・在庫・問い合わせをAIでつなぐ事例シナリオ](/ja/blog/butsuryu-3pl-ai-jidoka/)でも扱っています。

ベンダーを選ぶ立場から見ても、この境界の考え方は武器になります。「kintone AIでどこまででき、どこから外側の設計が要るのか」を自分の言葉で説明できれば、提案を受けるときの判断が揺れません。できないことを正直に言えるベンダーかどうかも、同じ物差しで見極められます。判断の軸を相手ではなく自分が持てることが、選定失敗を防ぐ一番の近道です。

kintone AIを外して考える必要は、まったくありません。社内データの内側では、これからも頼れる相棒です。ただ、受発注や在庫や物流のように、複数のシステムと外部の状態が絡む業務は、はじめからその外側にあります。境界を正しく引き、外側は外側の設計で解く。この順番を守るだけで、AI導入の打率は大きく変わると、私は現場で感じています。

どこから始めるか迷ったら、連携したいシステムを一つ挙げ、そこでの実行を一つだけ自動化してみることをおすすめします。小さく実行まで通した経験が、次の判断を確かなものにします。kintoneと外部システムの連携を具体的に検討したい段階であれば、WindyFloの無料トライアルで、実際の実行フローを試すところから相談を始められます。

よくある質問

参考・出典

• kintoneの機能とAIアシスト機能の範囲：サイボウズ「kintone」公式サイト（kintone.cybozu.co.jp） — 本文「kintone AIができること」の記述の根拠。
• WindyFloの実行レイヤー・連携方式・運用・データ保持の考え方：WindyFlo公式サイト（windyflo.com） — 本文の実行レイヤー・二層構成・監査ログ・保持場所に関する記述の根拠。
• 本文中の連携やPoCに関する観察は、筆者（ハマダラボCTO）による導入支援現場での実務経験にもとづく。