株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。
うちではフロントエンドのコーディング代行に加えて、kintoneのカスタマイズ開発も手がけています。kintoneの案件でもAIを活用していますが、結論から言うと、AIとkintoneのコーディングの相性は良いです。
kintone JavaScript APIのリファレンスは整備されており、AIはその内容をよく理解しています。イベントハンドラの書き方、REST APIの呼び出し、フィールド値の取得といった基本的なコーディングは、プロンプトにkintone固有の制約を含めれば正確なコードが返ってきます。
ただし、kintoneはユーザーが画面を操作しながら利用するソフトウェアです。AIが書いた「動くコード」が、そのまま「使いやすい実装」になるかというと、そこには大きなギャップがあります。今回は、このギャップがどこで生まれるかを具体的にお話しします。
AIがコードを書ける部分
まず、AIが得意な領域を整理します。ここはプロンプトの工夫で十分な品質が出ます。
バリデーションロジック。「必須チェック」「文字数制限」「日付の前後関係チェック」などは、AIが正確なコードを出してくれます。kintone固有の部分はフィールドコードの指定だけなので、フィールドコード一覧をプロンプトに含めれば精度が高い。
REST APIのCRUD操作。レコードの取得・作成・更新・削除の基本的なコードは安定しています。500件制限への対応やoffsetによる全件取得のパターンも、プロンプトで「500件制限がある」と明示すれば正しく書いてくれます。
CSSによる画面カスタマイズ。kintoneの一覧画面や詳細画面の見た目をCSSで調整する案件はAIとの相性が良い。要素のセレクタ指定がやや特殊ですが、一度パターンを見せれば応用が効きます。
イベントハンドラの基本構造。kintone.events.on()の書き方、eventオブジェクトのreturn、イベント名の指定なども、プロンプトにリファレンス情報を含めれば正確です。
つまり、kintone JavaScript APIのリファレンスに書かれている範囲のコーディングは、AIに任せて問題ありません。
AIが書けない部分 ─ UI/UXの判断
問題はここからです。kintoneはユーザーが日常的に操作するソフトウェアなので、「コードが動く」だけでは不十分です。以下はAIが書いたコードが「動くけど使いにくい」状態になった実例です。
例1：バリデーションのタイミング
あるお客さまの案件で、見積書アプリに「合計金額が0円の場合は保存できないようにする」というバリデーションを実装しました。AIに書かせたコードは技術的に正しく、app.record.edit.submitイベントで合計金額を検証し、0円ならエラーを返す実装でした。
問題は、ユーザーが30分かけて入力した内容を保存しようとした瞬間にエラーが出ることです。入力途中に「今0円ですよ」と教えてあげる方が、ユーザーにとっては親切です。
うちではapp.record.edit.show（編集画面表示時）とapp.record.edit.change.合計金額（フィールド値変更時）にもチェックを入れ、警告メッセージをリアルタイムで表示するようにしました。このような「いつチェックするか」の判断は、業務フローを理解した人間でないとできません。
例2：一覧画面のカスタマイズ
案件管理アプリの一覧画面に「ステータスに応じた色分け」を入れる案件がありました。AIは正確にCSSを書いてくれました。ステータスが「未着手」なら灰色、「進行中」なら青、「完了」なら緑。コードとしては完璧です。
ところが実際にユーザーに使ってもらうと、「色よりも、今日が期限の案件がどれかすぐわかるようにしてほしい」というフィードバックが返ってきました。ユーザーが本当に知りたいのはステータスの色ではなく、「今日やるべきことは何か」でした。
AIは「ステータスに色を付けて」と言われればその通りに実装します。しかし「このアプリのユーザーが一覧画面で本当に知りたい情報は何か」を考えることはできません。
例3：ルックアップの連動設計
取引先アプリからルックアップで情報を取得し、関連フィールドを自動入力する機能を実装した案件です。AIはルックアップ取得のコードを正確に書きました。
ただ、実際の業務では「取引先を選んだ後に、前回の取引条件を参照したい」というニーズがありました。単にフィールドをコピーするだけでなく、関連レコードへのリンクを表示したり、過去の取引履歴を一覧で見せたりする設計が求められました。
AIは「フィールドAの値をフィールドBにコピーする」コードは書けます。しかし「ユーザーがこの画面で次に何をしたいか」から逆算した機能設計はできません。
コーディングとUI/UXの役割分担
これらの経験から、うちでは以下のような役割分担に落ち着きました。
| 工程 | 担当 | 内容 |
|---|---|---|
| 業務ヒアリング・画面設計 | 人間 | ユーザーがどう操作するか、何が見たいかを整理 |
| UI/UXの仕様決定 | 人間 | バリデーションのタイミング、情報の見せ方、操作フローの設計 |
| コーディング | AI＋人間 | AIがリファレンスに基づくコードを生成、人間がUI/UX仕様に合わせて調整 |
| ユーザーテスト | 人間 | 実際に操作してもらい、使いやすさを検証 |
ポイントは「何を作るか」は人間が決め、「どう書くか」はAIに任せる、という分担です。kintoneの場合、「何を作るか」の部分にUI/UXの判断が多く含まれます。ユーザーが画面を触りながら業務をこなすソフトウェアである以上、ここを省略すると「動くけど使いにくい」カスタマイズになってしまいます。
まとめ
kintoneカスタマイズにおけるAI活用の実態を整理します。
AIとkintoneのコーディングの相性は良いです。リファレンスに沿ったコードは正確に出してくれますし、プロンプトに固有の制約を含めれば初歩的なミスも防げます。コーディング工数の削減効果は確実にあります。
ただし、kintoneはユーザーが画面を操作しながら使うソフトウェアです。バリデーションのタイミング、一覧画面での情報の優先順位、操作フローの設計など、UI/UXに関わる判断はAIにはできません。ここは実際の業務を理解した人間が担う領域です。
「コードが動く」と「ユーザーにとって使いやすい」の間にあるギャップ。kintone開発でAIを活用するなら、このギャップを埋めるのは人間の仕事だと考えています。
kintoneカスタマイズやプラグイン開発でAI活用を検討されている方は、株式会社ファストコーディングのお問い合わせフォームからお気軽にご相談ください。
