生成AI（以下、AI）の進化により、JavaScriptカスタマイズやプラグイン、外部システム連携のコードを短時間で組み立てられるようになりました。
一方で、AIが生成したコードをそのまま本番に投入することで、セキュリティ事故や情報漏洩、運用トラブルにつながるリスクも高まっています。

AIは便利な実装支援ツールですが、最終的な採用判断は人間（エンジニア）の役割です。
そこで本記事では、AIを活用してkintoneのカスタマイズを実装するエンジニアが、最低限押さえておくべき注意点とレビュー観点を紹介します。

この記事は、AIを活用してkintoneのJavaScriptカスタマイズやプラグイン、API連携を実装するエンジニア、またはそれらの提案・設計・レビュー・保守に関与するエンジニアを対象としています。

非エンジニアのみで実装・レビュー・保守を担う体制は、本記事の想定対象外です。
AIによってコードを生成できるようになったとはいえ、JavaScriptカスタマイズは、kintoneの動作や他カスタマイズとの干渉、セキュリティ上のリスクを判断できるエンジニアが、レビューや保守に関与する体制を前提としてください。

AIを使うときは、次の3点を共通認識として持っておくとよいでしょう。

• 実装支援ツールとしてAIを使うが、設計責任は人間にある。
• AIが生成したコードの振る舞いは、自動テストや手動操作で検証する。
• セキュリティ・法務・運用責任はAIではなく利用者に帰属する。

これらは、AIの出力品質が向上しても変わらない部分です。
「AIが書いたから」を理由にレビューやテストを省略してしまうと、思わぬリスクを抱え込むことになります。

AIに与えるプロンプトやコンテキストには、機密情報を含めないようにします。
利用するAIサービスによっては、入力内容がモデルの学習に利用されたり、サービス提供事業者側のログに残ったりする可能性があるためです。

• APIトークン、パスワード、秘密鍵
• 顧客の個人情報や企業秘密
• 本番環境のドメイン、IPアドレス、内部システムのエンドポイント
• ライセンスキーや内部システムのID

• プロンプトにはダミーデータや匿名化したデータを使用する。
• 利用するAIサービスの設定で「入力データを学習に使用しない」オプションを有効化する。
• 機密性の高い開発では、ローカルLLMの利用や、企業向けにセキュアな環境を提供するAIサービスを検討する。

AIは「動くコード」を出力しますが、そのコードが安全か・kintoneのガイドラインに沿っているかは保証しません。
担当するエンジニアが、生成されたコードを必ずレビューしてください。

次のような脆弱性が、AI生成コードに残されたまま提出されることがあります。

• XSS（クロスサイトスクリプティング）
• CSSインジェクション
• 機密情報のハードコーディング
• 認証・認可・入力バリデーションの不足
• 既知の脆弱性を含む依存ライブラリの利用

レビューでは特に次の点を確認しましょう。

• 認証・認可・入力バリデーションは、必ず人間が再設計・再確認する。
• APIトークンや秘密情報、署名処理をフロントエンドに露出していないか確認する。
• 依存ライブラリに既知の脆弱性がないか（npm auditなどで）確認する。
• 本番反映の前にサニタイズ処理や認証フローのチェックを通すルール（ガードレール）を整備する。
• OWASP Top 10の観点を共通レビュー項目として用意する。

kintoneカスタマイズには、kintone独自のセキュリティ要件・コーディング規約があります。
AIの学習データには、古い書き方やkintone特有の事情に合わないコードが含まれていることもあります。
kintoneのガイドラインと照らし合わせてレビューしてください。

参考となるガイドラインは次のページです。

• kintoneセキュアコーディングガイドライン
• kintoneコーディングガイドライン

セキュアコーディングガイドラインのチェック

• XSS・CSSインジェクション対策
  • DOM要素へのテキスト挿入でinnerHTMLを使っていないか。
  • 外部から渡される文字列をエスケープしているか。
• 認証情報の取り扱い
  • JavaScriptカスタマイズ内にAPIトークンやパスワードをハードコードしていないか。
  • 推奨されない場所（カスタマイズコード、ローカルストレージなど）に認証情報を保存していないか。
• ユーザー識別
  • ユーザー識別にはログイン名ではなくユーザーIDを使っているか。
• 動的に生成するURL
  • 想定したURLが生成されることを確認しているか。
  • URLの組み立てに、文字列結合ではなく公式のkintone.api.url()などを使っているか。
• 実装スタイル
  • 'use strict';を宣言しているか。
  • グローバルスコープを汚染しないよう、即時関数（IIFE）でラップしているか。

コーディングガイドラインのチェック

• グローバル変数・オブジェクトを使っていないか。
  • globalVariable = 1;のように暗黙のグローバル変数を作っていないか。
  • cybozu.foo = 'bar';のように既存のグローバルオブジェクトを書き換えていないか。
• DOM操作をidやclass属性に依存していないか。
  • フィールドの表示・非表示の切り替えやスタイル変更には、kintone.app.record.setFieldShown()やkintone.app.record.setFieldStyle()などの公式APIを利用する。 公式APIの詳細は、 kintone JavaScript API を参照してください。
• 大量のリクエストを送る実装になっていないか。
  • REST APIは複数件まとめて処理するエンドポイントを優先する。
  • cursor APIやupsertモードの活用を検討する。
• REST APIリクエストにUser-Agentヘッダーを設定しているか。
• 更新・削除を並列で実行していないか。
  • 同一レコードへの並列更新は競合の原因になるため、直列実行やupsertモードを検討する。

外部APIを呼び出すときは kintone.proxy() を使う

JavaScriptカスタマイズから外部APIを呼び出すとき、AIは標準的なfetchを使ったコードを生成しがちです。
Web開発全般としてはごく自然な書き方ですが、kintoneにはkintoneのサーバーを経由して外部APIへリクエストを送るkintone.proxy()が用意されています。
ブラウザー単体のfetchではぶつかるクロスドメイン制約を回避できるため、外部APIを呼び出すコードを見かけたらkintone.proxy()への置き換えを検討してください。
詳細は次のページを参照してください。
外部のAPIを実行する

認証情報をAIに渡さない実装にする

外部APIの呼び出しには、ほとんどの場合APIキーやアクセストークンなどの認証情報が必要です。
認証情報を入れたままのコードでAIに依頼すると、認証情報もそのままAI側へ流れてしまいます。
AIに依頼するときは、認証情報を直接コードに書かない工夫が必要です。
たとえば次のような方法があります。

• 認証情報の箇所をconst apiKey = 'YOUR_API_KEY';のようなプレースホルダーで生成してもらい、最後に人間が本物の値に差し替える。
• カスタマイズコードをビルドツールでバンドルしている場合は、.envなどに認証情報を切り出して、ビルド時に環境変数として注入する（.envはGitの管理対象から外しておきます）
  • ただし、フロントエンドにバンドルした値はユーザーから参照できるため、秘匿が必要な認証情報は後述のプラグイン化を検討してください。

ビルドツールの導入については、次のページを参照してください。
kintoneのカスタマイズにViteを使ってみよう

より強固に認証情報を守りたい場合は、プラグイン化を検討してください。
プラグインの設定画面からkintone.plugin.app.setProxyConfig()で認証情報をサーバー側に保管します。
kintone.plugin.app.proxy()を経由してリクエストすれば、認証情報がカスタマイズコードに残りません。
詳細は次のページを参照してください。

• プラグインから外部APIを実行する
• 外部APIの実行に必要な情報をプラグインへ保存する

権限の境界はアクセス権で守る

「管理者にだけボタンを表示する」「特定のユーザーだけにメニューを出す」といった画面制御をJavaScriptで実装すること自体は問題ありません。
UX上の利便性のためによく使われる実装です。
ただし、JavaScriptはブラウザーの開発者ツールで書き換えられるため、それをセキュリティの境界（最後の砦）として位置付けてはいけません。

AIは「管理者向け機能を作って」という依頼に対して、JavaScriptのif文だけで権限判定を完結させるコードを書くことがあります。
レビューでは次の点を確認してください。

• 統制の境界（誰が・何のデータを参照・操作できるか）は、kintoneのアクセス権設定（アプリ／レコード／フィールド）またはAPIトークンの権限で守る。
• JavaScriptで実装する画面制御は「使いやすさ」のためのものと位置付け、それだけで守ったつもりにならない。
• フロントエンドへ渡したくないデータは、フィールドのアクセス権で守る。
• JavaScriptで隠すだけの実装はセキュリティ対策にならない。

AIが存在しないAPIを提案していないか（ハルシネーション）

AIの提案するkintone APIには、それらしい名前で実際には存在しないAPIや、引数・戻り値の型が公式ドキュメントと食い違うものも含まれます。
存在しないAPIを呼ぶと実行時にエラーが起きるため、気付きやすいです。
ただし、似ている別のAPIにあたってしまうと、見かけ上は動作していても期待と異なる挙動を示します。

レビューでは次の点を確認してください。

• AIから提案されたAPI名・引数・戻り値の型が、公式ドキュメントと一致しているか。
• 公式ドキュメントに記載のないAPIや、第三者の古い記事にしか出てこないAPIを使っていないか。
• 存在を確認できても、AIによる使い方が公式ドキュメントのサンプルと整合しているか。

デバッグ用の出力や設定情報が、AI生成コードにそのまま残ってしまうケースもあります。
本番環境へ反映する前に、次の点を確認してください。

• ログに秘密情報（APIトークン、個人情報など）を出力していないか。
• console.logにデバッグ用のオブジェクトや変数が残っていないか。
• エラーメッセージに内部実装やスタックトレースなどの情報が含まれていないか。
• プラグインの設定画面（config.html）でAPIトークンを保存する設計になっていないか。
• プラグインのmanifest.jsonで要求する権限が必要最小限になっているか。

AIが生成したコードは、見た目どおりに動いていても、エッジケースや非同期処理の組み合わせで意図しない振る舞いをすることがあります。
特に次の点に注意してテストを設計してください。

• AIが生成したコードほど、テストが書かれていないことを前提に疑う。
• 正常系だけでなく、入力エラー・通信エラー・権限エラーなどの異常系テストを人間が設計する。
• モック前提のテストで「実運用では壊れる」パターン（権限・APIレート制限・他カスタマイズとの干渉など）を意識する。
• 本番環境へ反映する前に、必ず検証環境で動作を確認する。

生成AIの活用は、kintone開発の生産性を大きく引き上げてくれます。
ただし、AIは「動くコードを書く」ことはできても、「kintoneのカスタマイズとして安全な実装かどうか」までは判断できません。

この記事で紹介したポイントをまとめると、次のとおりです。

• AIに機密情報を渡さない。
• AIの出力は必ず人間がレビューする。
• kintoneのセキュアコーディングガイドライン・コーディングガイドラインをチェックリストとして活用する。
• 本番反映前に検証環境でテストする。

これらを徹底することで、AIの恩恵を受けながら、安全で保守性の高いkintoneカスタマイズを実現できます。

参考となる外部資料は次のページを参照してください。
OWASP Top 10