#kintone100日チャレンジ Day019：標準機能では追えない履歴を可視化！「操作ログ保存プラグイン」を作ってみた
面倒解決エンジニアの森田ユウゴです。
台湾からお届けする「#kintone100日チャレンジ」の19 日目。
昨日2026年4月18日、「ゼロから始めるkintoneカスタマイズ入門」のKindle版が発売されましたね！
私がカスタマイズスペシャリストを勉強したのが2026年1月だったので、当時あれば基礎学習はかなり活用できただろうな～と思い老けながら、「バイブコーディングでkintoneの仕様を忠実に知らないと難しいテーマは何だろう」と考えました。
本日は、ガバナンスを強化したい医療機関やデータ管理を徹底したい管理者向けの「操作ログ保存(レコードデータバックアップ)プラグイン」を開発しました！
「操作実行ログ保存プラグイン」について
🎯 なぜ開発したか？（現場の課題とベネフィット）
現場の「不」: kintoneの標準機能でも監査ログは取得できますが、「誰がどの患者のレコードを見たか」といった詳細な閲覧履歴の取得や、レコードを上書き保存する前の「スナップショット（過去データのバックアップ）」を細かく残すことは困難です。そのため、情報漏洩の抑止力が弱かったり、誤操作時の復旧が手間になったりといった課題がありました。
導入後の世界（ベネフィット）: レコードの閲覧（一覧・詳細）から追加・編集・削除、さらにはグラフ画面の表示まで、細やかな操作を別アプリに自動でログ記録！「誰が見たか」が可視化されることでスタッフの牽制（ガバナンス向上）に繋がり、保存のたびにバックアップが残るので、万が一のデータ復旧も安心です。
kintoneの「イベント」の発生タイミングでやりたいことを忠実に指示しないと、ほぼ100%AIでバイブコーディングでは実現が難しいです。
案の定「イベント全てでログを取るプラグインを作りたい」というだけではOpus4.7様でプランをしてもらっても、納得のいく仕組みは簡単に実現できませんでした。結局細かく指示が必要です。(イベントの漏れを指摘や、changeでpromise出来ないなど…)
✨ これで出来ること（機能概要）
まずはこちらをご覧ください。
詳細な操作ログの自動記録機能: kintone基本機能の監査ログに残る操作以外にも、一覧画面、詳細画面、印刷画面、グラフ画面など、イベントも検知し、指定したログアプリに日時、ユーザー、画面種別などの情報を自動でPOSTします。
スナップショット（バックアップ）保存機能: レコード保存時に、その時点でのレコードデータ全体をJSON形式のスナップショットとしてログアプリに保存。変更履歴として詳細なバックアップを残すことができます。
フールプルーフ（機能制限ロック）機能: 閲覧（show）系のイベントはリクエスト数が膨大になるため、無自覚な設定によるAPI制限超過を防ぐべく、設定画面で隠しコマンド（特定箇所を20回クリック）を入力しないと有効化できない安全設計を施しています。
ログアプリへの自動フィールド追加機能: ログを受け取るアプリに必要なフィールド群（ログ種別、URL、メタ情報など）を、プラグイン設定画面からワンクリックでプレビュー環境へ自動追加。設定の手間を大幅に削減します。
課題
現時点では下記のような課題が残っています。
kintoneのAPIリクエスト数上限問題
AIに「操作ログを全部残す処理を書いて」と頼むと、ただ無邪気に全イベントでAPIを叩くコードを生成してきます。しかし、kintoneには「1アプリにつき1日10,000回まで」というAPIリクエスト数の上限があります。閲覧（show）イベントまですべて記録しようとすると、ユーザー数が多い環境ではあっという間に上限に達してしまい、肝心なエビデンス記録が停止してしまいます。本格的な運用には外部のバックエンドサーバーとの連携が必須となります。
運用上の安全策（フールプルーフ）の導入
上記のリスクを知らずに「全部ログを取った方が良いじゃん！」と設定してしまう管理者を防ぐため、今回はあえて「表示系イベント」の設定にロックをかけ、20回クリックしないと解除できない泥臭い防衛策（フールプルーフ）を組み込んでいます。技術的な妥協点ではありますが、システムを落とさないための重要な設計です。
さいごに
明日もお楽しみに！
下記のブログもご覧ください！
👉 【#kintone100日連続チャレンジ】AIにkintoneカスタマイズを100%任せたらどこまでいけるか？現役フリーランスの「100 Days of kintone Hacks」始動！
