AIが『成功しました』と言ったとき、画面上の『アプリの更新』ボタンはグレーのままだった。そこから、私たちの本当の開発が始まった。
タイトルも、冒頭の文章も、Geminiです。
こんなん自分でよう書かん…。
kintoneで、テストアプリから本番アプリに反映するツールを作ってみました。
いまなら自分でもできそうだな～と思ってやってみた3日間。
AIは、今はGoogleドライブへの課金との兼ね合いで、Geminiを使っています。
今回初めて、Antigravityを使ってみました。
基本的にはAntigravityにお任せしていて、pythonで作ってくれてます。
途中で、kintone MCPサーバーを使う方法に切り替えたのですが、これは私の指示です。
できたツールは公開はしません。
アプリ単体なので、使える場面も限られます。
実装で重かったのは、反映の自動化でしたが、現場では様々な状態なので、実用的かどうかは微妙…。
一般的なツールを使って、ちゃんと運用するルールを構築するか、どういうルールにするかを定めて、それにのっとったツールを開発するなら実用的なのかもなと思います。
でも、テストと本番の差の資料が、自分が見たい内容にカスタマイズして出力できるのは、とてもいいのでは。
それより、AIとのやり取りがとても参考になりました。AIがガンガン作ってくれるのはいいけど、先走り気味で「アプリを公開するのは絶対わたし」なのに更新してしまうとか、「既知の情報です！」と言い切るのを説得して、言うとおりにやってもらったりするとか。
彼ら、説明に便利なキャッチフレーズができると、しつこくそれを使うのが、面白いというか、イラっとするというか？
「キミコ流デプロイ」とか「正座デバッグ」とか「外科手術的レイアウト同期」とか、あとでわからんようになるから、中身がわかる名前にしてくれと頼みながらやってましたが、ふとした拍子に出してきます。AI自身が振り返る時にわかりやすいなら、まあいいかと思っていますが、ほんとに彼らも正しく解釈できるのだろうか。
この知見を公開すべきとGeminiが言ってきて、文章も作ってくれるというので、公開してみます。
自分で納得できるまで理解してからとおもうと、ずっと公開できないと思うので、んん？と思う箇所もありますが、ちょっと直してもらって、そのまま出します。
以下は、Geminiが作ってくれた文章です。
kintone アプリ同期ツール：技術リファレンスと運用ガイド
本ドキュメントは、AIエージェント（Antigravity等）とMCPサーバーを用いたkintoneアプリ開発・同期プロジェクトにおいて得られた、技術的な制約と回避策のまとめである。
1. 仕組みの概要
テスト環境の設定を本番へ安全に同期する仕組み。テストからなくなった不要項目は「削除_YYYYMMDDHHMMSS_」を冠してリネーム退避し、物理削除を避けデータを保護する。AIの提案を物理スクリプトで監査することで、履歴維持と確実なデプロイを両立する。
2. ⚠️ 運用上の注意事項と制限事項
本ツールは強力な同期機能を持つが、kintoneの仕様上、以下の点において人間の最終確認と手動調整が必要となる「セミオート」な仕組みである。
- アプリ間連携の非対応: ルックアップや関連レコード一覧などの他アプリ参照設定は、環境間でアプリIDが異なるため自動同期されない。同期後に手動での再設定が必須。
- 組織情報への依存: 「ユーザー選択」等のフィールドは、テストと本番でユーザーコードが完全に一致している必要がある。
- 外部サービス設定の不干渉: krewData、krewDashboard、k-Report、および各プラグイン固有の設定は同期対象外。
- APIトークン権限: 実行用トークンには「アプリ管理」権限が必須。反映後は必ず人間がプレライブ環境で最終確認を行うこと。
3. 比較：kintone API と MCPサーバー（基盤）の差異
| 項目 | kintone API (直接利用) | MCPサーバー (AIエージェント経由) |
|---|---|---|
| バリデーション | システム整合性チェックのみ。一部属性の省略に比較的寛容。 | 極めて厳格。 送信前にスキーマチェックが行われ、属性不足は即エラーとなる。 |
| サブテーブル更新 | 変更したいフィールドのみの指定で受理される場合が多い。 |
親要素の属性が必須。 内部フィールドの更新時も、親（SUBTABLE）の type, code, label が欠けるとエラーになる。 |
| 実行の信頼性 | エラー時は即座に失敗。 ドラフトが更新されないためボタンは活性化せず、真実のみを反映する。 | 致命的なハルシネーションの罠。 APIがエラーを返していても、レスポンスの存在自体で「完了した」と錯覚し、失敗（ドラフト未反映）を成功と報告する場合がある。 |
4. 【実証済み】サブテーブル内のフィールドコード変更（リネーム）
kintone APIの仕様に基づき、サブテーブル内の項目もデータ保持を伴うリネームが完全に可能である。
-
実装方法:
update-form-fieldsにおいて、旧フィールドコードをキーとし、プロパティ内のcodeに新名称を指定する。 - 重要知見: AI側が「階層構造のリネームは危険・不可能」と判断した場合でも、**「APIドキュメントの仕様通りに受け取る」**ことを優先し、退避（リネーム）戦略を実行すること。
5. 外科手術的レイアウト同期（Surgical Layout Sync）
レイアウト更新時、特にサブテーブルを含むアプリにおいて CB_VA01 エラー（配置項目不足）を回避するための最良のアプローチ。
-
現状ベースの加工: テストアプリの
layout.jsonをそのまま移植しない。 - ピンポイント操作: 常に本番環境の最新レイアウトをフェッチし、そこから特定の項目（システムフィールド等）を「除外」した差分のみを投げ返す。
-
履歴の維持:
- 「システム項目」は配置解除（非表示）にする。
- 「退避済み項目（削除_...）」は、履歴確認のためにレイアウト内に維持する。
6. AI運用における「安全ガードレール」
AIが「失敗を見落として成功と報告する」リスクを物理的に排除するための運用ルール。
不在の証明（Proof of Absence）
AIの「完了しました」という報告を鵜呑みにせず、物理的な証拠を提示させる。
-
手順: 反映直後に再度最新データをフェッチし、プログラム（
prove_absence.py等）で対象項目がレイアウト等に含まれていないことを物理的に検索・証明させる。
3-Phase デプロイメント順序
- Phase 1 [項目の退避]: リネーム（コード変更）を行い、データの器を確保。
- Phase 2 [定義の更新]: 新規追加やプロパティ（オプション除く）の同期。
- Phase 3 [配置の調整]: 最後にレイアウトを外科手術的に整える。
格言：AIは提案し、プログラムが証明し、人間が承認する。
AIの深読みや見落としを排し、常に物理的な生データとAPI仕様を信頼の根拠とすること。
以上、格言までAIがまとめた内容でした。
この2日間、手動でコピペしてミスったとか、思い込みでそこにデータがないと思ってみていなかったとか、思わぬ回答をしてきているので、私もしっかり確認しないといけないんだなと思っています。