みんなの投稿

折角ご回答頂いたので、情報共有を兼ねてこの場で実験結果をご報告致します。

二要素認証もしくはSAML認証を必須にしている場合、パスワード認証によるREST APIは使用できない、という制約のおかげ？で、MCPを使ったアクセスもできませんでした。

不便なようでもありますが、私の懸念は解消できました。

みなさまご回答ありがとうございます。
JavaScript 制御を多用しているアプリでは、MCP経由の操作（本質的にはAIによるREST API使用）の抑止を検討する必要がある、と判断しました。
developerNetworkで投稿するべき内容なのですね。理解しました。ご指摘ありがとうございます。

MCP経由といっても、実際のkintone操作はREST APIとなるので、
ご懸念の通り、画面で動くJavaScriptカスタマイズの処理は適用されません（画面上で動作するプラグインも同様です）。

一方で、必須項目・重複禁止・値の制限・計算フィールド・ルックアップ・初期値・アクセス権・プロセス管理といったkintone標準の設定は、API経由でも適用されます。また、操作は接続ユーザー（またはAPIトークン）の権限の範囲内で行われます。

当社でも同様の懸念があり、gusuku FluxonでMCPから操作できる範囲を統制する方針としています。
アプリ単位・フィールド単位で細かく制御できるため、JavaScriptやプラグインによる入力規則・自動処理を前提としているアプリはMCPからの操作を禁止し、MCP経由で操作しても問題ないアプリのみ許可しています。

なお、AIに配慮させる方法としては、Fluxonの場合「アプリ意味定義」でアプリやフィールドごとに業務上の意味やAI利用時の注意を登録できるので、そこにJavaScriptで実装している入力規則を書いておく、という使い方もできます（強制ではないので、あくまで補助的な位置づけですが）。

MCPからのレコード操作を許可するのであれば、画面側のJavaScriptに依存している業務ロジックを、標準機能に寄せられるものは寄せ、残りをどう担保するかを検討する必要がありそうですね。

※開発的な話になってくると、シロくまさんご指摘の通りCDN推奨となります！

「配慮する」という意味であれば、事前にAIになんのカスタマイズをしているかを渡しておけば配慮はされます。正しく処理をされたかを担保したいという要望であればMCPではなく、きっちりと処理プログラムとして出力させるのがよいですね。

他の方もおっしゃってますが、カスタマイズメインの話となってしまうのでこのあたりで。

カスタマイズに関する投稿はガイドラインにあります通り、
避けるべきですので、今後こういった内容はdeveloperNetworkをご利用ください。

画面の変化がトリガーならMCP経由では動かないです