サービス›その他›Kintone開発支援
Kintone開発支援
kintone を止めずに残します。humbulls は問い合わせと商談のデータを HubSpot 側にも流し、営業現場の入力先を変えないまま、マーケティングと分析だけを先に動かせる状態にします。
こんな課題ありませんか
- 数字は営業の肌感しかない。ツールは kintone と Excel で止まっている
- 問い合わせの通知メールを見て、担当者が kintone に手で入力し直している
- 毎月 CSV を書き出して、スプレッドシートに貼り直して集計している
- アプリが増えすぎて、どれが本番で使われているのかを社内の誰も把握していない
- kintone に入っている数字と、サイトの流入や広告の数字を、同じ画面で並べられない
- 移行を勧められたが、現場が毎日使っているものを止められる気がしない
- 連携ツールを入れたことはある。いつの間にか止まっていて、しばらく誰も気づかなかった
humbulls の特徴
扱うのは kintone 側のアプリ設計・改修と、他ツールとの接続・データ移行・自動化です。
kintone は止めない。並行運用から始める
いまの入力先を変えずに、必要なデータだけを HubSpot 側にも流します。営業現場の手順を変えると、そこで入力が止まるからです。止まった分だけデータの質が落ち、移行の途中で数字が読めなくなります。
humbulls は同じ考え方を実装手順の記事として公開しています。第1章の見出しがそのまま「なぜ移行ではなく並行運用なのか」で、第5章に並行運用から部分移行、完全移行へ進む3段階のロードマップを載せています。手順は関連ナレッジの1本目から読めます。HubSpot にどこまで移すかは、動かしてみてから決められます。
壊れ方を先に設計してから、同期を組む
同期は動かし始めてから壊れます。API の応答が返らない回があります。項目の形式が合わない回があります。同じ相手が二重に登録される回もあります。ここを設計に織り込まないまま組むと、止まったことに誰も気づかないまま数字だけがずれていきます。
humbulls は、失敗した回を取りこぼさない設計と、既知のつまずきへの対処を最初から入れます。公開記事にはつまずき3点を修正前・修正後のコードつきで書いてあります。kintone 側のアプリも、外に出す同期のコードも、設計した人がそのまま書きます。設計と実装のあいだで仕様が落ちません。
運用手順ごと渡す
同期の切り替え手順、監視の見方、止め方、直し方を手順書にして渡します。次に触るのが humbulls でなくても動く状態にするためです。humbulls はこれを「運用ごと納品」と呼んでいます。
繰り返しの作業は、担当者が1回叩けば同じものが出る AI スキル（.md）にして渡します。humbulls 自身、月次の SEO レポートをスキル実行1回で再生産する形にして運用しています。必要に応じて、その後の実行まで伴走できます。
kintone に載せる業務・外に出す業務を分ける5つの判定軸
kintone が良いツールかどうかは、この判定では扱いません。決めるのは、この業務のこのデータを kintone の中で完結させるか、外にも出すかの1点です。同じ会社の中でも、アプリごとに答えが変わります。
humbulls は次の5つの軸で判定しています。軸2から軸5は、kintone の設定や運用ルールで埋められることがあります。軸1だけは埋められません。 この非対称が、判定でいちばん効くところです。
判定表
| # | 軸 | kintone の中で完結させてよい | 外にも出したほうがよい |
|---|---|---|---|
| 1 | データ構造 | 1レコードで判断が完結する（申請・在庫・日報・点検記録） | 会社・担当者・商談が関係を持ち、その関係をたどって集計したい |
| 2 | 件数 | 全件をまとめて取り出す予定がない | 全件を一度に取り出す予定がある、または件数が伸び続けている |
| 3 | 更新元 | その項目を書き換えるのは1箇所だけ | 同じ項目を2箇所以上から書き換える |
| 4 | 入力する人 | 現場が毎日触っていて、入力の手順が定着している | 入力が担当者1人に依存し、通知メールから転記している |
| 5 | 見る場 | そのアプリの中の数字だけで判断が終わる | 流入・広告・メールの反応と突き合わせて判断する |
軸1 データ構造（1レコードで完結するか、関係をたどるか）
アプリを分けて紐づければ、kintone で何でも管理できる。
kintone はレコード単位の管理に強く、ルックアップと関連レコードで他のアプリを参照できます。参照はできます。ただし、参照の先をたどった状態で集計しようとすると別の話になります。「この会社の、この担当者が関わった商談を、四半期ごとに、流入経路別に数える」のように関係を軸にして数える業務は、アプリの分け方を工夫しても軽くなりません。無理に載せると、集計のたびに人が一覧を書き出して突き合わせることになります。
業務ごとに「1レコードを見れば判断が終わるか」を先に判定します。終わるなら kintone に置いたままにします。関係をたどって数えたいなら、そのデータだけを CRM 側へ写します。5つの軸のうち、これだけは kintone の中の工夫で埋められません。 したがって軸1が「外」に振れた場合は、他の軸を待たずに外に出す判断で構いません。
タップで拡大軸2 件数（日々の入力では気づかず、外に出す瞬間に効く）
件数はサーバー側の話で、業務の設計とは関係ない。
日々の入力では件数の問題は出ません。効くのは、そのデータをまとめて外に出そうとした瞬間です。kintone の REST API は、レコードを取得するときの offset に上限があります（2026年7月時点で 10,000 件）。通常の一覧表示では当たらないため、連携や集計を始めた段階で初めて気づくことになります。
設計のときに「この業務のデータを、いつか全部まとめて外に出す予定があるか」を聞きます。あるなら、レコード ID の範囲や更新日時で分割して取り出せる形にしておきます。上限自体は分割で越えられますが、分割の鍵になる項目が設計に入っていないと、後から取り出し方に制約がかかります。件数が伸びてから直すより、置き方を先に決めるほうが安く済みます。
タップで拡大軸3 更新元（双方向にするかどうかを、最初に決めない）
連携するなら、どちらからでも更新できる双方向が上位の形だ。
双方向にした瞬間、「同じ項目を2箇所から書き換えたとき、どちらが正か」を決める必要が出ます。決めないまま双方向にすると、古い値が新しい値を上書きする事故が起きます。しかも上書きは静かに起きるので、気づくのは数字がおかしいと誰かが言い出したときです。片方向であれば、この事故は構造として起こりません。
項目ごとに正をどちらか一方に決めます。決められない項目は、双方向にしません。データが2箇所にあること自体は、これで運用できます。二重管理を最初から悪と決めると、選べる手が減ります。まず片方向で始めて、双方向は必要が確定してから足します。 最初から双方向で組むと、正を決める議論を後回しにしたまま仕組みだけが動き出します。この順番は、連携の見た目の完成度としては後退して見えますが、直せなくなる失敗を1つ潰しています。
タップで拡大軸4 入力する人（画面を変えると、データの質が先に落ちる）
入力されたデータが汚いのは、ツールが使いにくいからだ。新しいツールに移せば直る。
入力の質を決めているのは、ツールの新しさよりも入力の手数です。毎日触っている画面には、どこに何を書くかの記憶が積まれています。移した直後は手数が増えるので、まず空欄が増え、次に「あとでまとめて入れる」が始まります。一方で、入力が担当者1人の手作業に依存している業務は、その人が休んだ日にデータが止まります。この2つは症状が似ていますが、打ち手が逆です。
現場が毎日触っている画面は変えません。裏側のデータだけを整えます。手作業の転記が挟まっている経路だけを自動化の対象にします。全体を一度に移す計画ではなく、並行運用から部分移行へ段階を分ける形にすると、途中で止めても業務が壊れません。段階の分け方は関連ナレッジの1本目に書いてあります。
軸5 見る場（そのアプリの中で終わるか、外の数字と並べるか）
kintone で一覧もグラフも作れるのだから、レポートも kintone で作ればいい。
kintone の一覧とグラフが見られるのは、そのアプリの中にあるデータです。問い合わせが何件来たかは kintone で数えられます。その問い合わせがどの記事から来て、どの広告に反応して、メールを何通読んだ後だったのかは、kintone の外にあります。突き合わせたい数字が外にある限り、集計のたびに書き出して貼り直す作業が残ります。毎月の手作業として残っているのは、たいていこの突き合わせです。
判断に使う数字を1枚書き出して、その数字が1つのアプリの中で完結するかを見ます。完結するなら kintone の集計で足ります。他のデータと並べないと判断できないなら、そのデータを外に出します。この線引きをせずに連携すると、両方で同じグラフを作ることになり、どちらを見るかで揉めます。
5軸をどう読むか
- 軸1が「外」 → 単独で外に出す理由になります。他の軸を待つ必要はありません
- 軸1は「中」で、軸2から軸5のうち2つ以上が「外」 → その2つだけを対象にした部分連携にします。全部を対象にしません
- 軸1は「中」で、「外」が1つだけ → その1つを kintone の設定と運用ルールで埋められないかを先に検討します。たいていのケースで、そのほうが早く安く済みます
- どれも「外」でない → 連携しません。いまの kintone のままで足ります。humbulls は kintone をやめる提案から入りません。基幹を1つのツールに寄せて一本化するのが正解、という前提を取っていないためです
進め方
実際の進め方は、いま動いているアプリの数と過去データの量を踏まえて決めますが、基本の形はこの6ステップです。
現状の棚卸し
使っている kintone アプリと、そのうちどれが本番で使われているのかを洗い出します。読み取り専用の権限で構造を確認し、項目の定義と選択肢の実態を見ます。ここを飛ばすと、使われていないアプリを連携対象に入れたまま設計が進みます。棚卸しの段階で、そもそも連携が要らないと分かることもあります。
判定と、連携範囲・マッピングの設計
判定の5軸を業務ごとに当てはめ、外に出す対象を決めます。決まったら、どの項目をどちらに寄せるか、どちらを正とするかを項目単位で決めます。ここで決めきらないと、実装のあとに「どちらが正しいのか」を人が毎回判断することになります。決めた内容と、決めるときに出た論点を、そのまま記録として残します。
過去データの投入
既存の履歴を一括で HubSpot 側に入れます。件数が上限を超える場合は、レコード ID の範囲で分割して取り出します。投入したあとに件数を突き合わせ、落ちた分がないかを確認します。ここで重複と表記ゆれの整理も行います。整理せずに入れると、あとから同一人物が複数のレコードとして残ります。
増分同期の実装
差分だけを毎日流す仕組みを作ります。前回どこまで流したかを記録し、失敗した回は記録を進めずに次回もう一度取りに行く設計にします。こうしておかないと、失敗した回のデータだけが永久に抜けます。既知のつまずき（日時の形式、同じメールアドレスの扱い、書き込み権限の設定漏れ）は、実装の時点で潰しておきます。
dry-run と切り替え
書き込みをゼロにした状態で通し、何が書かれるはずだったかをログで確認します。確認できてから本番に切り替えます。基幹のデータを触る作業なので、切り替えの権限は限定します。この工程を省くと、最初の1回で本番データに間違った値が入り、戻す作業が発生します。
運用手順の引き渡し
監視の見方、止め方、直し方を手順書にして渡します。同期が止まったときに誰が何を見るかまで書きます。繰り返しの作業は AI スキル（.md）にして、担当者が1回叩けば同じものが出る形にします。ここを渡さないと、次に何かあったときに humbulls を呼ぶまで止まったままになります。
成果物
実物
| # | 実物 | 内容 |
|---|---|---|
| 1 | 公開済みの実装手順記事（図表3枚 = 同期フロー図 / つまずき3点 / 段階移行ロードマップ） | 現場で使っている手順を、そのまま公開しています |
| 2 | AI スキル（.md）と手順書 | 繰り返しの作業は、担当者が1回叩けば同じものが出ます |
| 3 | 判定メモとマッピング設計書 | 項目ごとに正をどちらに置くかを決めた一例（一部マスクしています） |
| 4 | アプリ棚卸しと構造監査の出力 | 使われているアプリと、そうでないアプリを分けた一例 |
納品物リスト
- アプリの棚卸しと、連携対象の切り分け
- 判定メモ（5軸の当てはめ結果と、外に出さない判断の理由）
- マッピング設計書（どの項目をどちらに寄せるか・どちらを正とするか）
- 過去データの投入スクリプトと、件数の突合結果
- 増分同期のスクリプトと実行ログ
- dry-run の記録と、本番切替のチェックリスト
- 運用ランブック（構成図・切替手順・監視・止め方）
- 同じ作業を繰り返すための AI スキル（.md）
無料相談
まず、いまの kintone の使い方を見せてください。 無料相談は60分です。どのアプリが本番で使われているかを確認したうえで、判定の5軸をその場で当てはめます。連携で解ける話なのか、その前にデータの持ち方を直すべきなのかを切り分けてお返しします。売り込みはしません。外に出さなくてよいと判断した場合は、そのように伝えます。
フォームからのご連絡には3営業日以内に返信します。
関連ナレッジ
- kintone と HubSpot の並行運用 — Apps Script 増分同期の実装手順（このページの中核記事。手順6ステップ・つまずき3点・段階移行ロードマップ）
- HubSpot Starter の制限一覧 — 30 の壁と回避可否を全整理（外に出した先で何ができるかの前提）
- HubSpot で会社・担当者・取引を関連付けてインポートする手順（軸1「関係をたどって集計する」を受け側でどう持つか。進め方のステップ3 の具体）
- HubSpot のプロパティ重複整理 — 表記ゆれとマージの手順（進め方のステップ3 の重複と表記ゆれの整理）
- MQL と SQL の違いと定義 — 営業とマーケが合意できる線引きの作り方（軸5「見る数字を先に決める」の具体）
FAQ・価格・完了後の道
費用はどのくらいですか。
対象アプリの数、過去データの件数、双方向にするかどうかで大きく変わるため、一律の金額はお答えできません。実際の金額は棚卸しのあとにお見積もりします。
なお humbulls は、同じ手順を実装記事として公開しています。記事は所要時間の目安を半日としており、1アプリ・片方向・過去データなしであれば、社内で組んでいただけます。その構成で足りるなら、依頼していただかなくて構いません。見積もりの対象になるのは、対象アプリが複数ある、過去データの投入がある、双方向にする、現場の運用制約に合わせる、といった条件が加わる場合です。
kintone と HubSpot のライセンス費用は含みません。いずれも各社との契約で、humbulls の費用とは別にかかります。
どのくらいの期間がかかりますか。
棚卸しのあとに工程表を作り、どこにどれだけかかるかを先にお見せします。工程は進め方の6ステップです。
期間を左右するのは、アプリの数よりも過去データの量と、双方向にするかどうかです。片方向で過去データを入れないなら短く、双方向で過去の履歴をまとめて入れるなら長くなります。
どのくらい前に相談すればよいですか。
無料相談は60分です。決まった締め切りがないなら、相談の時期はいつでも構いません。締め切りがある場合は、切り替えの日から逆算してご相談ください。進め方のステップ5（dry-run と切り替え）は、確認が終わるまで本番に切り替えない工程なので、日程を詰めにくい箇所です。ここを短くすると、確認せずに本番へ書き込むことになります。
kintone のアプリそのものを作ってもらえますか。
受けます。 アプリの設計・構築と、既存アプリの改修が対象です。kintone 側を触るのも、外に出す接続とデータ移行を設計するのも、同じ人間です。アプリの持ち方と外に出す設計を、分けずに決められます。
ただし、作る目的が決まっていない依頼は受けていません。判定の5軸を先に当てて、kintone に載せる業務と外に出す業務を分けたうえで着手します。
kintone をやめて HubSpot に全部移すことになりますか。
なりません。kintone は残したまま、必要なデータだけを HubSpot 側にも流すところから始めます。全部を移すかどうかは、動かしてみてから決められます。
完全に移す場合でも、並行運用から部分移行を経る段階を踏みます。SaaS の一括移行は、現場の入力が止まったところで数字が読めなくなり、戻すか進むかの判断ができなくなります。段階の分け方は関連ナレッジの1本目に書いてあります。
Salesforce や Notion でも同じことができますか。
差分を取って、あるものは更新し、ないものは追加する。この考え方自体は Salesforce でも Notion でも同じで、置き換わるのは API の呼び方の部分です。
どのツールで実際に組んだことがあるかは、相談の場でお伝えします。
基幹データを触られるのが不安です。AI に情報を渡すことになりますか。
高機密の場合は、AI がデータに触れない設計にします。同期の実体はスクリプトのコードで、AI が書くのはそのコードです。データを読み書きするのはコードのほうで、AI ではありません。この構造は、このメニューでは事実としてそのまま成立します。
加えて、本番に切り替える前に、進め方のステップ5 の dry-run を通します。書き込みをゼロにした状態で流し、何が書かれるはずだったかをログで確認してから切り替えます。切り替えの権限も限定します。
なお humbulls はマスキング運用を取っていません。マスクの漏れはミスに気づきにくく、安全に見えて危ないためです。データの扱いは、業務アカウントと学習オプトアウトを標準とし、要件に応じて上の設計に切り替えます。
連携の部分だけを単発でお願いできますか。
受けます。範囲を区切った依頼も対象です。ただし、目的が決まっていない状態では受けていません。「とりあえずつないでおきたい」で始めると、どの項目を正とするかが決まらないまま実装が進み、あとで人が毎回判断する仕組みが残ります。
つないだデータを何に使うか（何の数字を、誰が、どの場で見るか）まで踏み込む場合は、伴走のプランか計測ダッシュボード構築のほうが合います。相談の場で、どちらの形が合うかを切り分けます。
提案コンペに参加してもらえますか。
参加しません。営業段階でお出しするのは、会社紹介・進め方の資料・見積もり・概算スケジュールまでです。判定と設計は、受注後の最初の工程として行います。5軸の判定にはアプリの棚卸しが要り、それを提案書の段階で無償で行うと、判定の質がその分だけ落ちるためです。
判定の考え方そのものは上の5軸に書いてあるので、社内で当てはめていただくぶんには、相談の前でも構いません。
同時に何社まで進められますか。
同時に進める件数には上限を設けます。dry-run と切り替えは日程を動かしにくい工程なので、受注量より納期の確実性を優先するためです。埋まっている場合は、着手できる時期をその場でお伝えします。
価格目安
- 見積の順序: 棚卸しのあとに見積もりを出す
- kintone と HubSpot のライセンス費用は含まない
- その他の含まれないもの: ツール利用料・公開後の運用代行。見積もりの前にお伝えする
完了後の道
- つないだデータを商談化率・成約率まで見える形にする場合は 計測ダッシュボード構築 へ。前工程から後工程で、最も自然な接続
- フォーム・スコアリング・レポートまで組んで使われる状態にする場合は HubSpot Starter 導入支援 または HubSpot Professional 導入支援 へ
- 見えるようになった数字をもとに獲得側の打ち手を回す場合は リード獲得支援 へ
- 施策の実行まで中に入る必要がある場合は、伴走プラン Growth Partner（月額30万円〜 / 最低3ヶ月）へ接続する
- 運用は運用ランブックと AI スキルで社内へ移行する（humbulls への保守費を必須にしない形を目指す）