なぜgusuku Fluxonを開発したのか？そして、次に実現しようとしていること

公開日：2026-11-12

2026年10月22日に販売を開始した「gusuku Fluxon（フラクソン）」ですが、おかげさまで多くの方にご関心をお寄せいただき、ご利用いただいています。

フラクソンは、生成AIとkintoneを安全につなぐためのサービスです。

生成AIからkintoneのデータを検索したり、分析したり、レコードを追加・更新したりできるようになるのですが、単に生成AIとkintoneを接続するだけであれば、実はそれほど難しいことではありません。

では、なぜアールスリーはわざわざフラクソンというサービスを開発したのでしょうか？

このコラムでは、フラクソンを開発することになった経緯と、開発を進めるなかで考えてきたこと、そして現在開発中の重要な新機能「アプリルール」についてご紹介していきます。

1. きっかけは、kintoneローカルMCPサーバーとの出会い

MCPによって生成AIと外部サービスがつながるようになった

まず、フラクソンを理解していただくために、MCPについて簡単に説明しておきましょう。

MCP（Model Context Protocol）は、Anthropicが提唱した、生成AIと外部のサービスやデータを接続するための共通規格です。

これまで、生成AIに外部サービスを利用させようとすると、それぞれのサービスに合わせて個別の連携機能を開発する必要がありました。

MCPは、こうした接続方法を共通化するための仕組みです。

現在ではChatGPTをはじめとする多くの生成AIサービスがMCPに対応しており、生成AIが外部サービスを利用するための標準的な仕組みとして定着しつつあります。

もちろん、kintoneも例外ではありません。

サイボウズさんからは「kintoneローカルMCPサーバー」が提供されています。

これは、利用者のパソコン上でMCPサーバーを動作させることで、生成AIからkintoneのデータを操作できるようにするものです。

私もこのkintoneローカルMCPサーバーを試してみました。

実際に使ってみると、生成AIに日本語で指示するだけでkintoneのデータを検索したり、分析したりできるわけですから、その便利さはすぐに理解できました。

これまで人間がkintoneの画面を操作して行っていた仕事の一部を、生成AIに任せられるようになる可能性を感じたのです。

ただ、そのときに別のことも考えていました。

「これをアールスリーの全メンバーに展開するのは、なかなかしんどいな」

ということです。

個人で便利なものが、企業でも使いやすいとは限らない

ローカルMCPサーバーは、個人で利用するには便利な仕組みです。

しかし、これを企業全体で利用しようとすると、いくつか気になる点が出てきます。

まず、利用者それぞれのパソコンにインストールや設定を行う必要があります。

もちろん、そこまで難しい作業ではありません。しかし、数人で使う場合と、数十人、数百人で使う場合とでは話が変わってきます。

新しいメンバーが入社したとき、パソコンを入れ替えたとき、設定を変更したいときなど、それぞれの環境を管理する必要があるわけです。

そして、もっと気になったのが管理や統制の問題でした。

誰がどのようにkintoneへアクセスしているのかを組織として把握することや、アクセスの記録を一元的に残すことが難しいのです。

生成AIからkintoneの情報を閲覧するだけであれば、まだよいかもしれません。

しかし、生成AIにレコードを追加したり、更新したり、場合によっては削除したりすることまで任せるのであれば、企業としては慎重に考える必要があります。

これはローカルMCPサーバーがよくないという話ではありません。

個人が便利に利用するための仕組みと、企業が組織として安心して利用するための仕組みでは、求められるものが異なるということです。

2. 企業で使うなら、リモートMCPサーバーがよいのではないか？

MCPには、利用者のパソコン上で動作するローカルMCPサーバーだけでなく、ネットワークを経由して接続するリモートMCPサーバーという方式もあります。

そこで、私は次のように考えました。

「クラウド上に共通のMCPサーバーを用意して、すべてのアクセスをそこに集約すればよいのではないか？」

この方式であれば、利用者ごとにMCPサーバーをインストールする必要がなくなります。

また、生成AIからkintoneへのアクセスが共通のサーバーを経由するのであれば、そこでさまざまな管理や制限を行うこともできます。

例えば、生成AIからどのような操作を許可するのかを組織として決めたり、操作の記録を残したりすることが考えられます。

企業が生成AIを本格的に利用していくのであれば、このような仕組みが必要になるだろうと考えました。

これが、フラクソンの開発を始めたきっかけです。

最初から現在の機能が決まっていたわけではない

まずはPoC（Proof of Concept：技術的な実現可能性を確認するための試作）として、小さなリモートMCPサーバーを作成しました。

実際に生成AIから接続できること、そしてkintoneのデータを扱えることを確認し、その後、本格的な開発へと進んでいきました。

ただし、最初から現在のフラクソンが持っている機能をすべて考えていたわけではありません。

開発を進めながら、繰り返し考えていたことがあります。

それは、次の2つです。

企業が生成AIからkintoneを安心して利用するためには、何が必要なのか？
生成AIがkintoneのデータを正しく理解し、効果的に利用するためには、何が必要なのか？

この2つの問いに向き合いながら、必要だと考えた機能を少しずつ追加していきました。

現在のフラクソンは、その積み重ねによってできあがったサービスということになります。

3. 生成AIがkintoneのデータを「理解する」とはどういうことか？

フラクソンの特徴的な機能のひとつに「アプリ意味定義」があります。

これは、生成AIがkintoneのデータをより適切に扱えるようにするための機能です。

少しわかりにくいかもしれませんので、具体的な例で説明していきましょう。

データの構造がわかることと、意味がわかることは違う

例えば、kintoneに営業案件を管理するアプリがあったとします。

このアプリには、次のようなフィールドがあるとしましょう。

顧客名
案件名
案件金額
受注確度
受注予定日
担当営業

生成AIにこれらのフィールド情報を渡せば、どのようなデータが保存されているのかは、ある程度推測できます。

しかし、それだけで業務上の意味まで正しく理解できるとは限りません。

例えば「案件金額」というフィールドがあった場合、それが受注見込み金額なのか、確定した受注金額なのかによって、集計や分析の仕方は変わってきます。

また「受注確度」についても、単純な数値なのか、営業部門で決められた基準によって分類されているのかによって意味が異なります。

人間であれば、日常的にそのアプリを使っているうちに、こうしたルールを自然と理解していくでしょう。

しかし、生成AIはその会社の業務を経験しているわけではありません。

そのため、フィールド名やデータの内容だけから業務上の意味を推測させると、誤った解釈をしてしまう可能性があります。

アプリ意味定義で業務の意味を伝える

そこでフラクソンでは、アプリ意味定義という機能を用意しました。

アプリ意味定義では、そのアプリがどのような業務で、どのような目的のために使われているのかを定義します。

さらに、各フィールドが持つ意味や、データを扱う際の制約なども定義できます。

例えば、先ほどの営業案件管理アプリであれば「受注確度80%以上の案件を高確度案件として扱う」「案件金額は税抜きの受注見込み金額を表す」といった情報を伝えることが考えられます。

こうした情報があることで、生成AIはkintoneのデータを単なる数値や文字列としてではなく、業務上の意味を持った情報として扱いやすくなります。

この違いは、特にデータ分析を行うときに大きく現れます。

単純に案件金額を集計するだけでなく、受注確度を考慮した分析や、業務上のルールに沿った集計を提案できる可能性が高くなるのです。

生成AIにデータを渡すだけではなく、そのデータの意味も伝える。

これがアプリ意味定義の基本的な考え方です。

4. 生成AIにどこまで操作を許可するのか？

アプリ意味定義が、生成AIにkintoneをより適切に理解させるための機能だとすると、もうひとつ重要なのが、生成AIに許可する操作を制御する機能です。

生成AIが便利だからといって、何でも自由に操作できるようにしてよいわけではありません。

権限の基本は、利用者本人のkintoneアカウント

フラクソンでは、生成AIを利用するユーザーそれぞれが、自分のkintoneアカウントで認証する仕組みを採用しています。

そして、そのkintoneユーザーが持っている権限を、生成AIが利用できる最大の権限としています。

つまり、kintoneの画面から閲覧できないデータを、生成AIを使えば閲覧できるようになる、といったことはありません。

これは企業で利用するうえで、とても大切な考え方です。

kintoneで設定しているアクセス権を無視して生成AIが動いてしまうのであれば、安心して利用することはできないでしょう。

しかし、これだけでは十分ではないと考えました。

生成AIには、さらに厳しい制限をかけたい

例えば、営業担当者がkintoneの画面から案件レコードを編集したり削除したりできるとします。

だからといって、その営業担当者が利用する生成AIにも、同じ操作をすべて許可したいでしょうか？

必ずしもそうではないと思います。

生成AIによる操作では、指示の解釈を間違えたり、意図していなかった対象を操作してしまったりする可能性があります。

そこでフラクソンでは、kintoneが持つアクセス権に加えて、フラクソン側でさらに制限をかけられるようにしました。

例えば、kintoneの画面ではレコードの閲覧・編集・削除ができるユーザーであっても、生成AIからは閲覧だけを許可するといった設定ができます。

これにより、人間が画面で操作するときと、生成AIに操作させるときで、許可する操作の範囲を分けられるわけです。

ちなみに、アールスリー社内では、すべてのアプリに対して生成AIからのレコード削除を禁止しています。

人間が直接操作するときには削除できても、生成AIからの削除は許可しないという運用です。

生成AIを積極的に活用することと、何でも自由に操作させることは別の話です。

生成AIの便利さを活かすためにも、適切な制限を設けることが重要だと考えています。

5. 生成AIからレコードを更新すると、新たな問題が発生する

ここまでで、生成AIにkintoneのデータを理解させる仕組みと、安全に利用するための仕組みについて説明してきました。

これらがあれば、生成AIから安心してkintoneのデータを扱えるようになるのでしょうか？

実は、開発を進めるなかで、もうひとつ重要な問題が見えてきました。

それが、生成AIからレコードを追加・更新したときに、業務上のルールが守られない可能性があるという問題です。

kintoneの画面には、さまざまな処理が組み込まれている

kintoneを業務で活用されている方のなかには、プラグインやカスタマインなどを使って、アプリにさまざまな処理を追加されている方も多いのではないでしょうか。

例えば、次のような処理です。

あるアプリにA、B、Cという3つの数値フィールドがあったとします。

このアプリでは、AとBに値を入力すると、その合計をCに自動的に設定するようにカスタマイズされています。

人間がkintoneの画面を使ってレコードを編集すれば、こうした計算は自動的に行われます。

また、別の例として、受注管理アプリのレコードを更新したときに、関連する在庫管理アプリのレコードも更新するような仕組みを作っているかもしれません。

このような処理は、kintoneを実際の業務で使いやすくするために、とても重要なものです。

ところが、生成AIからkintoneのAPIを通じてレコードを更新する場合、話が変わってきます。

kintoneの画面上で動作するJavaScriptや、それを利用したプラグイン、カスタマインのカスタマイズなどは、API経由のレコード更新では実行されません。

もちろん、API経由でも動作するように別の仕組みで実装している処理はありますが、画面上のカスタマイズに依存している場合には注意が必要です。

データは更新できても、正しい状態になるとは限らない

先ほどのA、B、Cというフィールドの例で考えてみましょう。

生成AIに「Aを100、Bを200に変更してください」と指示したとします。

生成AIがそのままAとBだけを更新した場合、Cには以前の値が残ってしまう可能性があります。

本来であればCは300になるべきなのに、そうならないわけです。

また、受注管理アプリを更新しても、関連する在庫管理アプリには変更が反映されないかもしれません。

これでは、データの整合性が保てなくなってしまいます。

生成AIからレコードを更新できること自体は便利なのですが、その結果として業務上のルールが守られなくなるのであれば、困ってしまいます。

特に、複数のアプリが連携しているような業務では、この問題は無視できません。

アプリ意味定義だけでは解決できない

こうした問題に対して、アプリ意味定義を使うという方法も考えられます。

例えば「AとBを変更するときは、必ずその合計をCに設定してください」と定義しておけば、生成AIがそのルールを理解して処理してくれることが期待できます。

簡単な処理であれば、それで十分なケースもあるでしょう。

しかし、ここには大きな問題があります。

生成AIがルールを理解していることと、必ずそのルールを実行してくれることは同じではないということです。

生成AIは、同じような指示をしても、毎回まったく同じ手順で処理するとは限りません。

ときには必要な処理を省略してしまったり、指示を違う意味に解釈してしまったりすることも考えられます。

文章を作成したり、データを分析したりするのであれば、こうした柔軟さが役立つこともあります。

しかし、業務システムのデータを更新する処理では、そうはいきません。

計算や関連データの更新など、必ず守らなければならないルールについては、生成AIの判断だけに頼らない仕組みが必要だと考えました。

6. 次に開発している重要な機能「アプリルール」

そこで、現在フラクソンで開発を進めているのが「アプリルール」という新機能です。

アプリルールは、先ほどご紹介したアプリ意味定義を拡張する形で提供する予定です。

ただし、その役割はアプリ意味定義とは少し異なります。

アプリ意味定義が「このアプリやフィールドには、こういう意味があります」と生成AIに伝えるための仕組みだとすると、アプリルールは「このような操作が行われたら、この処理を行う」という業務上のルールを定義するための仕組みです。

そして、このアプリルールには大きな特徴があります。

それは、ルールのロジックを生成AIと一緒に組み立て、その実行は生成AIではなくフラクソン側で行うということです。

ルールを作るときには生成AIを活用する

例えば、あるアプリで「AフィールドとBフィールドの合計をCフィールドに設定したい」と考えたとします。

こうした処理を実現するためには、従来であればJavaScriptを書いたり、カスタマインなどでカスタマイズを作成したりする必要がありました。

アプリルールでは、このような処理のロジックを生成AIと一緒に組み立てられるようにすることを考えています。

例えば、生成AIに対して「このアプリのレコードを更新したら、AとBを足してCに入れるようにしたい」と伝えます。

すると、生成AIがその内容を理解し、必要なフィールドや処理の流れを考えて、アプリルールとして定義するロジックを組み立ててくれるわけです。

もう少し複雑な例であれば「受注管理アプリのレコードが更新されたら、関連する在庫管理アプリの在庫数を更新したい」というような処理も考えられます。

この場合には、どのレコードを関連するものとして扱うのか、どのフィールドを使って計算するのかなど、決めなければならないことがいくつかあります。

こうした内容も、生成AIと対話しながら整理し、ルールとして組み立てていくことを想定しています。

つまり、生成AIの得意な「人間の言葉を理解し、必要な処理を組み立てる」という能力を活用するわけです。

もちろん、生成AIが作成したルールが常に正しいとは限りませんので、利用者が内容を確認することも大切になります。

でも、実行するときには生成AIに任せない

ここがアプリルールの重要なポイントです。

生成AIと一緒にルールを組み立てるからといって、そのルールを実行するときにも毎回生成AIに判断させるわけではありません。

一度定義したルールは、フラクソン側で実行する仕組みを考えています。

例えば、AとBの合計をCに設定するというルールであれば、生成AIが毎回「今回はCも更新したほうがよいかな？」と判断するのではなく、フラクソンが定義されたルールに従って計算と更新を行います。

生成AIがそのルールを思い出してくれるかどうか、正しく解釈してくれるかどうかに依存しないわけです。

また、別のアプリのレコードを更新するような処理についても、あらかじめ定義されたロジックに従ってフラクソンが実行します。

この方式であれば、生成AIが指示を解釈する際の曖昧さを、業務ルールの実行部分に持ち込まずに済みます。

もちろん、ネットワーク障害やkintone APIのエラーなどによって、処理そのものが失敗する可能性までなくなるわけではありません。

しかし、少なくとも「生成AIが今回は必要な計算を忘れてしまった」というような問題は防ぎやすくなります。

ルールを作るところは生成AIに手伝ってもらい、ルールを守るところはフラクソンが担当する。

これがアプリルールの基本的な考え方です。

生成AIの柔軟さと、プログラムの確実さを組み合わせる

生成AIは、人間の曖昧な指示を理解したり、必要な処理を考えたりすることが得意です。

一方で、決められた処理を毎回同じ手順で実行するという点では、従来のプログラムのほうが適しています。

この2つは、どちらか一方が優れているというものではありません。

それぞれに得意なことがあるということです。

そこでアプリルールでは、生成AIの柔軟さと、プログラムによる処理の再現性を組み合わせようとしています。

人間が実現したい業務ルールを生成AIに伝え、生成AIと一緒にロジックを組み立てる。

そして、完成したロジックはフラクソン側で実行する。

この役割分担によって、生成AIを活用してルールを作成する際の負担を減らしながら、実際の業務処理では安定した動作を目指すことができます。

これは、単に生成AIに「こうしてください」と指示して、そのとおりに動いてくれることを期待する方法とは大きく異なります。

アプリの意味だけでなく、ルールまで定義できるようにする

ここまで説明してきたアプリ意味定義とアプリルールは、似ているようで役割が違います。

アプリ意味定義は、生成AIがアプリの目的やフィールドの意味を理解するためのものです。

一方のアプリルールは、アプリに対して決められた操作を行う際に、必要な処理を実行するためのものです。

例えば、営業案件管理アプリであれば「案件金額は税抜きの受注見込み金額です」という説明はアプリ意味定義に該当します。

それに対して「案件金額と受注確度から期待売上額を計算して、指定のフィールドに設定する」という処理はアプリルールで実現することが考えられます。

生成AIがアプリの意味を理解するだけでなく、そこで守るべきルールも定義できるようになるわけです。

これによって、生成AIからレコードを追加・更新した場合にも、データの整合性を保ちやすくなると考えています。

なお、アプリルールは現在開発中の機能ですので、実際に対応する処理や機能の範囲については、今後変更になる可能性があります。

ただ、目指している方向性は明確です。

生成AIに業務ルールを考えることを手伝ってもらい、そのルールの実行は生成AI任せにしない。

これが、私たちがアプリルールで実現したいことです。

7. 生成AIと業務システムをつなぐ、その先へ

フラクソンの開発を始めたときは、企業で安心して利用できるリモートMCPサーバーを作りたいという思いが出発点でした。

しかし、開発を進めていくなかで、単に接続するだけでは解決できない問題があることがわかってきました。

生成AIがデータの意味を正しく理解するための仕組みが必要です。

生成AIが操作できる範囲を適切に制御する仕組みも必要です。

そして、生成AIからデータを更新しても、業務上のルールが守られる仕組みが必要です。

これらは、いずれも生成AIと業務システムを組み合わせて使っていくために重要なものだと考えています。

生成AIはこれから、質問に答えたり、文章を作成したりするだけのものではなく、実際の業務を進めるための存在になっていくでしょう。

ただし、業務を進めるためには、自由に考えてよい部分と、必ず守らなければならない部分を分ける必要があります。

データをどのように分析するのか、どのような情報を探すのかといったことは、生成AIの柔軟な判断が役立ちます。

一方で、誰がどのデータにアクセスできるのか、レコードを更新するときにどのような処理が必要なのかといったことは、あらかじめ定められた権限やルールに従う必要があります。

フラクソンは、こうした役割分担を実現するための仕組みになっていきたいと考えています。

生成AIに何でも任せるのではなく、生成AIが得意なことを活かしながら、企業として守るべきことはシステム側で守る。

それが、企業で生成AIを安心して活用していくための大切な考え方ではないでしょうか。

まとめ

最後に、今回お伝えしたかったポイントは3点です。

フラクソンは、企業が生成AIからkintoneを安心して利用できるようにするために開発しました。 単に接続するだけではなく、組織として管理・統制できることを大切にしています。
生成AIには、データの構造だけでなく、業務上の意味も伝える必要があります。 アプリ意味定義を活用することで、生成AIがkintoneのデータをより適切に理解し、分析などに利用できるようになります。
生成AIからデータを更新する際には、業務上のルールを守る仕組みが必要です。 現在開発中のアプリルールでは、生成AIと一緒にルールのロジックを組み立て、実際の処理はフラクソン側で実行することで、この課題を解決しようとしています。

アプリルールについては、現時点ではまだリリース日をお知らせできませんが、開発を進めています。

フラクソンは2026年10月に販売を開始したばかりのサービスですが、私たちが実現したいことはまだまだあります。

これからも、生成AIとkintoneをより安全に、より便利に組み合わせて利用していただけるように、機能を充実させていきたいと考えています。

今後のフラクソンにも、ぜひご期待ください。