kintone × Odoo 併用ガイド — 現場のアプリは残して、取引と在庫を Odoo に任せる

kintone で日報や案件のアプリを作り、現場の記録はうまく回っている。それでも月末になると、受注の数字を会計ソフトに打ち直し、在庫は Excel で数え直している。こうした会社が、kintone をやめずに Odoo Community を後ろに置く形を、この記事でまとめます。

kintone をやめて Odoo に移す考え方は「kintone から Odoo Community へ」で扱っています。ここでは「両方を使い続ける」前提に絞ります。

役割で分ける

kintone は、自分たちで項目を決めてアプリを作るのが得意です。Odoo は、受注・出荷・請求・仕訳が最初から1つのデータベースでつながっていて、伝票を確定すると次の伝票や在庫・仕訳が動きます。

	kintone	Odoo Community
向いている仕事	日報・点検記録・問い合わせ・案件メモ	見積・受注・出荷・請求・入金・購買・製造
データのつながり	アプリごと（ルックアップで参照）	受注→出荷→請求→仕訳が1つのデータベース
項目の追加	画面で利用者が足せる	画面で足す道具（Studio）は Enterprise 側。Community でも「プロパティ」や開発者モードで画面から足せる範囲があり、業務の決まりを伴う項目はアドオンで足す（項目の足し方）
使う人の数と費用	1人ごとの月額	ライセンスの費用は人数で変わらない（LGPLv3）

kintone の料金は 1 人あたりの月額で、スタンダードコースは 1,800 円（税抜）です。最小の契約は 10 ユーザーから。30 人で使うと月 54,000 円になります（2026年10月、kintone の料金ページで確認）。併用するなら、外部とつなぐ機能がスタンダード以上に付く点も見ておきます。料金ページの比較表で、「外部サービス連携、プラグインなどの拡張機能」に印が付くのはスタンダード以上です（ライトは 1,000 円・斜線）。

「入口の記録は kintone、お金と物の流れは Odoo」と分けると、どちらも得意な所だけを受け持てます。

分け方の3つの型

型1：現場の入力は kintone、受注から先は Odoo

営業の訪問記録や案件の進み具合は、使い慣れた kintone のアプリに残します。見積を出す所から先、受注・出荷・請求・入金を Odoo に置きます。

Odoo の受注の一覧（画面は見本のデータです）

Odoo の受注の一覧では、受注ごとに「請求対象」「全額請求済」が出ます。請求の漏れを見るために、kintone と会計ソフトを突き合わせる作業がいらなくなります。

受注の明細を1枚の表で、納期・出荷・請求の状態まで並べて見たい会社には、当社が「受注管理表」を足します。

受注管理表。当社が足す画面の見本です（画面は見本のデータです）

型2：顧客と商談は kintone、取引は Odoo

顧客の台帳や商談の履歴を kintone で作り込んでいるなら、そこは動かしません。Odoo には取引に要る得意先と、受注から先の伝票だけを持たせます。

Odoo にも商談の管理（CRM）は入っていますが、併用では無理に移しません。得意先の名前と番号をどちらが正とするかを先に決め、もう片方へ写す向きを1つにします。

型3：現場の記録は kintone、部品表と製造は Odoo

製造業で、日報・品質のチェック・設備の点検を kintone で付けている形です。部品表（BOM）、製造の指示、発注点による補充、在庫の評価を Odoo に置きます。どれも Community に入っています。基準生産計画（MPS）は Enterprise 側の機能で、Community には入っていません。

在庫を品目ごとに横並びで見て、足りなくなる日まで出したい場合は、当社が「在庫状況照会」を足します。

在庫状況照会。当社が足す画面の見本です（画面は見本のデータです）

つなぎ方（Odoo 19 で試した範囲）

Odoo 19 Community を手元で動かし、外部とやり取りする口を実際に呼んで確かめました。kintone 側の送り方・受け方は、この記事では試していません。

読む・書く：外部 API

Odoo 19 には、/json/2/<モデル>/<メソッド> の形で呼ぶ API があります。利用者ごとに発行する API キーを Authorization の見出しに付け、受注の検索や書き換えができました。キーを付けないと 401 で断られます。

POST /json/2/sale.order/search_read
Authorization: bearer <API キー>
X-Odoo-Database: <DB 名>
{"domain": [["client_order_ref", "=", "KINTONE-REC-0001"]], "fields": ["name", "state"]}

これまでの /xmlrpc/2 と /jsonrpc も Odoo 19 では動きますが、Odoo のソースには「Odoo 19 で非推奨、Odoo 22 で外す予定」と書かれています。新しくつなぐなら /json/2 を使います。

知らせる：自動化ルールの Webhook

Odoo の「自動化ルール」は Community に入っています。動きの1つに「Webhook 通知を送信」があり、選んだ項目を JSON にして、決めた URL へ送ります。

受注が確定したら外へ知らせる設定（手元で試した設定です）

試して分かったことが2つあります。

きっかけの選び方で、送る回数が変わる。「作成・更新のとき」に「状態が受注」の条件を付けると、受注を1件確定しただけで 3 回送られました。「状態が設定されたとき」にすると 1 回でした
送りっぱなし。待つのは 1 秒で、失敗しても送り直しません。見出しも Content-Type しか付けられないので、API トークンを見出しに載せる kintone の REST API へは、そのままでは書き込めません

このため、kintone へ書き戻すときは、間に小さな中継（トークンを付ける・失敗したら送り直す・同じ通知を2回受けても1回にする）を置きます。当社はこれをアドオンとして用意します。

受ける：Webhook の受け口

自動化ルールのきっかけを「Webhook 上」にすると、ルールごとに秘密の URL ができます。そこへ JSON を送ると、決めた動き（ここでは受注のメモに書く）が走りました。

外から受ける設定（手元で試した設定です）

1 台のサーバーに DB が複数ある環境では、URL だけに送ると 404 でした（どの DB か決まらないため）。DB を1つにするか、受け口の手前で DB を決める設定が要ります。kintone の Webhook が送る中身は Odoo が待つ形（_model・_id）と違うので、ここでも中身を読み替える部品を足します。

つないだ後に見るもの

併用の効き目は、受注や在庫の数字を、打ち直さずに1か所で見られることです。Odoo の受注と請求を元に、売上と粗利を月ごとにまとめる画面は、当社が「経営ダッシュボード」として足します。

経営ダッシュボード。当社が足す画面の見本です（画面は見本のデータです）

始める前に決めること

どちらが正か：得意先・品目・受注の番号を、kintone と Odoo のどちらで作るか
向き：kintone→Odoo だけか、Odoo→kintone の書き戻しも要るか
きっかけ：どの状態になったら知らせるか（確定・出荷・請求）
失敗したとき：送れなかった通知を誰がどこで見て、どう送り直すか

kintone を捨てるかどうかは、後で決めても間に合います。先に「お金と物の流れ」だけを Odoo に移し、つなぎ目を1本ずつ確かめていく方が、現場を止めずに進められます。

自社のアプリのどこまでを kintone に残し、何を Odoo に任せるか、一緒に整理したい場合はお問い合わせからご相談ください。