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