株式会社ファストコーディングでフロントエンド開発と技術戦略を担当している黒田です。
先月、ある食品メーカーのお客様から「案件管理をkintoneでやりたい」と相談を受けました。うちのエンジニアが「試しにAIにフィールド設計を出させてみていいですか？」と言うので、やらせてみたところ、3分で8フィールドの設計書が出てきました。
「速いですね。もうこれでいいんじゃないですか？」
お客様はそう言いました。正直、私も一瞬そう思いました。しかし、この設計をそのまま構築して1ヶ月後に何が起きたか。今回はその話をします。
AIが3分で出した設計書
まず、AIに「Web制作会社の案件管理アプリ」を設計させた結果を見てください。
| フィールド名 | タイプ | AIのコメント |
|---|---|---|
| 案件名 | 文字列（1行） | 案件を識別する名前 |
| クライアント名 | 文字列（1行） | 依頼元の企業名 |
| 担当者 | ユーザー選択 | 社内の担当者 |
| 受注日 | 日付 | 受注した日 |
| 納期 | 日付 | 納品期限 |
| 見積金額 | 数値 | 見積もりの金額 |
| ステータス | ドロップダウン | 見積中/受注/制作中/検証中/納品済/完了 |
| 備考 | 文字列（複数行） | 自由記述 |
シンプルで過不足がない。一見、何も問題がなさそうに見えます。
1ヶ月後に起きた3つの問題
問題1：「株式会社ABC」と「（株）ABC」が別のクライアントになった
営業チームから：「クライアント別の売上を集計したいんですが、同じ会社が3つの名前で登録されていて、合計が合いません」
AIは「クライアント名」を文字列フィールドで設計しました。手入力です。営業5人がそれぞれの癖で入力した結果、同じクライアントが「株式会社ABC」「（株）ABC」「ABC」の3パターンで登録されていた。
これは「ルックアップ」で防ぐべき問題でした。 クライアントマスタアプリを別に作り、そこから選択する形にすれば、表記ゆれは構造的に発生しません。
AIは「1アプリで完結する設計」を出しがちです。「マスタを分離してルックアップで参照する」というkintone特有の設計パターンは、プロンプトで明示しない限り出てきません。
問題2：コーダーが検証中の案件を「納品済」にしてしまった
PMから：「まだテスト中の案件が、いつの間にか納品済になっていたんですが……」
AIはステータスをドロップダウンで設計しました。誰でも、いつでも、どの値にも変更できる。
実際の業務では、ステータス変更にはルールがあります。
- 「制作中」→「検証中」：コーダーが変更可能
- 「検証中」→「納品済」：PMが確認後に変更
- 「納品済」→「完了」：請求処理完了後に経理が変更
この要件がある場合は、kintoneの「プロセス管理」を使うべきでした。 プロセス管理なら、「検証中→納品済はPMのみ変更可能」のようにステータス遷移に条件を付けられます。
AIに「ステータス管理が必要です」と伝えても、ドロップダウンかプロセス管理か、どちらを使うべきかの判断はしてくれません。この判断には、お客様の業務フローの理解が必要です。
問題3：1案件にタスクが15個あって、備考欄がカオスになった
コーダーから：「備考欄に全部書いてるんですけど、どのタスクがどの状態かわからなくなりました」
AIの設計にはタスク管理の概念がありませんでした。「デザイン確認待ち」「トップページコーディング中」「フォームの修正対応中」。これらが全部「備考」に箇条書きされていた。
追加でAIに「タスクも管理したい」と依頼したところ、こう返ってきました。
| タスク1名称 | タスク1期限 | タスク1ステータス |
|---|---|---|
| タスク2名称 | タスク2期限 | タスク2ステータス |
| タスク3名称 | タスク3期限 | タスク3ステータス |
固定3個のタスクフィールド。タスクが4つになったら終わりです。
正しくは、サブテーブルを使って動的にタスクを追加できるようにするか、タスク管理アプリを別に作ってルックアップ連携させるかです。 タスク数が案件によって異なる以上、固定数のフィールドでは対応できません。
AIの設計に「足りなかったもの」の正体
3つの問題に共通しているのは、AIが「業務の文脈」を理解していないことです。
- 表記ゆれは「複数の人が入力する」という運用の文脈
- ステータス管理は「誰がいつ変更できるか」という権限の文脈
- タスク管理は「案件ごとにタスク数が違う」という業務の文脈
AIはkintoneのフィールドタイプを知っています。しかし、「この業務にはどのフィールドタイプが最適か」の判断には、お客様の現場を知っている人間が必要です。
今のうちの進め方
この経験を踏まえて、うちではkintoneのアプリ設計を以下のステップで進めています。
ステップ1：AIにたたき台を出させる（3分）
要件をAIに伝えて、フィールド定義の第一案を出させます。ゼロから設計書を書くより、AIの出力を叩き台にして修正するほうが圧倒的に速い。 この「3分で8割のたたき台が出る」メリットは非常に大きいです。
ステップ2：お客様にたたき台を見せてヒアリング（30分〜1時間）
AIの出力をそのまま見せます。すると、お客様から具体的なフィードバックが出てきます。
「クライアント名は選択式にしてほしい。毎回打つの面倒だし、表記がバラバラになるから」
「ステータスは勝手に変えられると困る。PMの承認を経てから変えたい」
「タスクは案件によって3個のときも15個のときもある」
白紙の状態で「どんな項目が必要ですか？」と聞くより、たたき台があるほうが10倍スムーズです。AIの設計の「足りない部分」こそが、ヒアリングの最も重要なポイントになります。
ステップ3：人間がアプリ構成と権限を設計する（半日〜1日）
マスタデータの分離、ルックアップ連携、プロセス管理の設計、フィールド単位のアクセス権限。ここは人間が設計します。kintoneの機能を熟知した上で、お客様の業務フローに合わせた構成を判断する工程です。
ステップ4：小さく始めて、使いながら育てる
最初のリリースは最小限のフィールドで。使い始めてから「この項目も欲しい」「この集計がしたい」が出てきたら追加します。kintoneの強みは、運用中にフィールドを柔軟に追加できることです。
まとめ
AIにkintoneのアプリ設計をさせると、3分で8割のたたき台が出ます。これは素晴らしいことです。
ただし、残りの2割 ── マスタ分離、プロセス管理、権限設計、運用を見据えた項目追加 ── は、お客様の業務を理解した人間でなければ設計できません。
AIは設計を「完成」させるツールではなく、設計の「出発点」を作るツール。 そしてその出発点があることで、お客様とのヒアリングが格段にスムーズになる。これが、AIをkintoneの設計工程に組み込む最大のメリットだと感じています。
kintoneの業務アプリ設計やAI活用について相談したいという方は、株式会社ファストコーディングのお問い合わせフォームからお気軽にご連絡ください。
