コードはAIと。仕事の答えは、あなたと。
忘れんぼうのシェフとつくる、
はじめてのBase Site
AIは、手の速いシェフ。料理をつくる力はありますが、お店の事情も、お客さまの好みも、最初から知っているわけではありません。あなたの役目は、料理を代わりにつくることではなく、何を出すかを決めて、味見をすることです。
いきなり開店より、まず一皿。
「つくって」から、「使える」までを一緒に進めましょう。
お店の話を、置き換えると。
店舗スタッフ故障を届け出る
→Base Site入力・確認する窓口
→Base記録が残る台帳
今回は「店舗の備品修理受付」を例に進めます。Agentは、会話だけでなく、利用できるツールを使って資料の確認や実装を進めるAIです。
画面ができたことと、仕事で使えることは別です。
一皿ずつ、つくってみる。
01
開店前別のお店の厨房で仕込みを始めたら、材料も注文も混ざってしまいます。
まず、どのお店の厨房か確かめる
利用するLarkの組織・アカウント・作業フォルダを確認。Agent、Lark CLI、Base Siteを構築するためのSkillが使えるか、最初にAgentに確認してもらいます。既存のBaseを使うならURLも渡します。
この環境でBase Siteをつくれるか確認してください。利用する組織と保存先を示し、不足する設定や権限があれば、作業を始める前に知らせてください。
ログインできることと、目的のデータを扱えることは別です。権限不足は、つくり始める前に解消します。
02
注文する「いい感じのランチ」だけでは、量も味も決まりません。「昼休みが短い人に、すぐ食べられるお弁当」なら、考える方向がそろいます。
「おいしいもの」では、注文にならない
機能名より先に、「誰が・いつ・何に困っていて・どうなればよいか」を伝えます。例は、店舗スタッフが備品の故障をスマートフォンから届け出て、本部が対応状況を確認できる受付です。
店舗スタッフが、壊れた備品をスマートフォンから報告できる受付をつくりたいです。本部は未対応の依頼を店舗別に確認し、対応状況を更新します。
AI Codingは、日本語で相談しながらAgentに実装してもらう進め方です。コードを知らなくても始められますが、業務の目的は人が決めます。
03
注文する「このお弁当くらいの量。味付けは薄め」と実物を見せると、伝わり方が変わります。
口で説明するより、お弁当を一つ見せる
今のExcel、紙の申請書、参考画面を渡します。見せたい部分を具体的に指定し、データの意味も添えます。最初は架空の情報で十分です。
添付の申請書を参考にしてください。1件は1回の修理依頼です。店舗、備品、故障内容、依頼日、対応状況を記録します。個人情報は使わず、架空の3件で試してください。
AIは見せていない社内ルールを知りません。資料が多いほどよいのではなく、今回の仕事に関係する材料が必要です。
04
注文する卵が使えるか分からないのに、シェフが勝手に判断すると困ります。迷うことは、先に確認してもらいます。
思い込みで、アレルギーを決めさせない
必須項目、重複した依頼、締切、閲覧範囲など、判断が必要な点を質問してもらいます。AIの提案は出発点。業務上の正解として、そのまま採用しません。
実装前に、不明点をまとめて質問してください。それぞれにおすすめの案と、その理由を添えてください。データ削除、外部公開、通知送信は、確認なしに行わないでください。
AIはもっともらしい答えを出せても、事実やルールを取り違えることがあります。断言の強さではなく、内容を確かめます。
05
仕込みきれいなお皿だけあっても、材料の場所や在庫が分からなければ、お店は回りません。
盛り付けの前に、材料の置き場所を決める
Baseは記録を残す台帳、Base Siteは入力・確認する窓口です。画面と一緒に、保存する表と項目を考えてもらいます。修理依頼の表と店舗一覧を分け、店舗名が変わってもつながるIDを使います。
先に、必要な表・項目・1行の意味・表同士のつながりを提案してください。店舗名を変更しても依頼が切れないようにしてください。既存のBaseを使えるかも確認してください。
画面に文字が出ているだけでは、Baseに保存されたとは限りません。「どこに何が残るか」まで決めます。
06
仕込みお客さまが注文できても、売上台帳やレジの中まで触れてよいわけではありません。
レジを触れる人は、全員ではない
店舗スタッフ、本部、管理者が、何を見て何を変更できるかを決めます。ボタンを隠すだけで安心せず、権限制御ができているかを実際の利用者アカウントで確認します。
店舗スタッフは自店の依頼だけ、本部は全店の依頼を確認する想定です。この制御が実現できるか確認してください。できない部分は明示し、公開前に別の利用者で検証してください。
見せ方とアクセス権は別です。初回の試作に、実在する顧客情報、健康情報、パスワードを入れないようにします。
07
試作する新しいお弁当は、一食だけ試作して味を確かめます。百食つくってから直すと、材料も時間も余計にかかります。
最初から、百人分つくらない
最初は「依頼を入力する → 保存する → 一覧で見つける」だけ。写真、AI分類、通知、複雑な集計は、この流れが動いてから追加します。
まずは修理依頼を1件入力し、Baseに保存し、再読み込み後も一覧で確認できる最小版をつくってください。通知とAI分類は今回は不要です。
小さく試せば、業務の解釈違いや保存先の間違いを、早いうちに見つけられます。
08
味見するおいしそうに見えても、食べてみないと味は分かりません。
料理の写真だけで、味は分からない
Agentの「完成しました」だけで終わらせず、自分でも1件入力します。Base側に同じ内容があるか、再読み込みで残るか、更新や絞り込みが正しいかを確認します。
確認結果を、操作・期待した結果・実際の結果で示してください。保存先のBaseとページURL、未確認の項目も教えてください。私も実際に入力して確認します。
見た目が完成、保存が成功、業務で使える。この三つは別の確認です。集計があれば、答えの分かるデータと照合します。
09
直す「おいしくして」より、「塩を少し控えて、量はそのまま」のほうが、直す場所が分かります。
「なんか違う」より、「少し塩が強い」
対象ページ、操作、今の状態、期待する状態をセットで伝えます。スクリーンショットは、どこを見るかも添えます。関連する修正をまとめ、関係のない仕事は分けます。
このURLの一覧で、店舗をA店からB店に変えても未対応件数が変わりません。画像の右上です。件数と一覧の両方を選択店舗に合わせてください。保存先と他の機能は変えず、A店・B店で再確認してください。
現象と正解が分かれば、Agentは原因を絞れます。「全部つくり直す」を繰り返さず、必要な部分を直せます。
10
直す大きなお皿ではきれいでも、小さなお弁当箱ではふたが閉まらないことがあります。
お弁当箱が変われば、詰め方も変わる
パソコンだけでなく、実際に使うスマートフォンでも確認します。長い店舗名、未入力、データ0件、保存失敗、二重送信も試します。
スマートフォンで入力欄と送信ボタンが使えるか確認してください。必須項目の未入力、0件表示、保存失敗、送信ボタンの連打でも、誤解や重複が起きないか確認してください。
順調なときだけ動くものは、現場では使い続けにくくなります。困ったときに状態が分かることも品質です。
11
開店する試作品の味見が終わる前に、お客さまへ一斉に販売はしません。
試食会と、本日の営業は分ける
まずプレビューで関係者が確認します。実データの使用、公開範囲、利用者、通知先を確認してから本番公開を判断します。変更する場合も、既存のサイトURLと残すものを伝えます。
まずプレビューURLを共有してください。私の確認が終わるまで本番公開しないでください。利用者の権限、保存と更新、スマートフォンの確認結果をそろえてから、公開を相談してください。
つくれることと、安全に運用できることは別です。公開や削除の判断まで、Agentに丸投げしません。
12
閉店後毎朝ゼロから味を思い出すのではなく、材料と分量をレシピに残します。
おいしかった配合は、レシピに残す
目的、決めたルール、BaseとサイトのURL、保存先、確認結果、残課題を短く記録してもらいます。会話が長くなったら引継ぎメモで整理し、新しい会話でも同じ場所から続けられるようにします。
次回用の引継ぎメモを残してください。業務の目的、表と項目、アクセス範囲、サイトとBaseのURL、今回の変更、確認済み・未確認の項目をまとめてください。秘密情報は記載しないでください。
AIの記憶に頼るのではなく、次も参照できる形に残します。繰り返す手順は、テンプレートやSkillとして再利用できます。
注文が変わると、進め方が変わる。
見た目は整っても、誰が使うか、保存先、完成の基準はAIの想像に任されます。
店舗から依頼 → Baseに保存 → 本部が確認。この一往復ができてから、次を足します。
最初の依頼、そのまま使える一枚。
自分の業務に合わせて書き換え、申請書や見本と一緒に渡します。
Base Siteで、店舗の備品修理受付をつくりたいです。 【使う人と目的】店舗スタッフがスマートフォンから依頼し、本部が店舗別の未対応依頼を確認・更新します。 【材料】現行の申請書と項目一覧を添付します。1行は1回の修理依頼です。最初は架空の3件で試します。 【環境】利用する組織・アカウント・作業場所と、Agent／Lark CLI／必要なSkill・権限を確認してください。不足があれば、着手前に知らせてください。 【既存データ】既存Baseを使う場合はここにURLを記入します。使えるか確認し、無断で別の保存先に置き換えないでください。 【先に相談】表・項目・ID・アクセス範囲と、最小限の画面を提案してください。不明点はおすすめ案と一緒に質問してください。 【最初につくる範囲】依頼の入力 → Baseへの保存 → 一覧での確認。通知とAI分類は後回しです。 【確かめること】1件保存し、Baseと照合し、再読み込み後も残ること。店舗別の絞り込み、更新、スマートフォン、別の利用者の権限も確認します。 【止まって確認すること】本番公開、実データの利用、削除、外部への通知送信。 最後にプレビューURL、BaseのURL、確認結果、未確認の項目を共有してください。
修正を頼むときは
対象URL：＿＿
操作：＿＿
今の状態：＿＿
期待する状態：＿＿
変えないもの：保存先・既存データ・＿＿
修正後の確認：＿＿
開店前の味見。
実際に確認できた項目に印をつけます。
確認済み 0 / 6
学習用のチェックリストです。Baseへの接続や自動検証は行いません。すべてに印がついても、業務に応じた追加確認が必要です。
覚えておくのは、この四つ。
小さく頼む。実物を見せる。
使って確かめる。決めたことを残す。
コーディングの専門用語を覚える前に、この習慣から始められます。