freee for kintoneの勘定科目の入力を自動化！kintoneで条件ごとの科目判定を外付けするワークフロー

freee for kintoneを入れれば、kintoneの受注データから売上仕訳まで自動で作れる。そう期待して導入した経理担当の方は少なくないはずです。

ところが実際に月次の売上仕訳を起こしてみると、製品ごとの勘定科目だけは自動で決まらず、1件ずつ手作業で選んでいる。そんな肩透かしを感じていないでしょうか。

この記事では、なぜ勘定科目だけが手動で残るのかという構造を、業務側から解き明かします。そのうえで、その最後のひと手間をkintoneの標準機能で外付けして埋める設計の考え方をお伝えします。さらに、その設計を実際にどう組み立てるか、ワークフローの全体像と要所の設定も画面とともにお見せします。大がかりなシステム開発やSIer（システム開発会社）への発注は前提にしません。

freee for kintoneなら仕訳まで自動、と思っていたら勘定科目だけ手動で残った

「連携すれば仕訳まで自動になる」。そう考えてfreee for kintoneを導入したのに、蓋を開けたら製品ごとの科目選択だけが手作業で残っていた。まずはこの肩透かしから話を始めます。

受注データはkintoneに入っており、取引登録機能を使えば、その受注から売上の仕訳を起こすところまでは流れます。ここまでは期待どおりでした。

つまずくのは勘定科目です。製品売上・部品売上・修繕売上というように、製品のカテゴリによって使う売上科目が変わる。製品ごとに売上科目が違うのが製造業の特徴で、「この受注はどの科目か」を人が判断して選び直すことになります。仕訳の器は自動で用意されるのに、その中身である科目だけは経理担当の手が残るのです。

ここで多くの方が、もう一つの思い込みを抱きます。「この残りを自動化しようと思ったら、結局は外部システムを追加開発しないと無理なのではないか」という身構えです。仕訳の自動生成という会計の根幹に手を入れる話だけに、専門業者に頼む大掛かりな案件を覚悟してしまいがちです。

結論から言えば、その身構えは必要ありません。残った科目選択は、kintone側に判定の仕組みを足すことで埋められる余地があります。次の章で、その到達点を先にお見せしましょう。

残った手動の科目選択も、kintone側の仕組みで自動化しきれる

まず到達点から示しましょう。手動で残った科目選択は、取引登録機能の「外側」に判定の仕組みを一つ足すことで、自動で決められる形に持っていけます。科目選択にかけていた工数も、カテゴリの取り違えによるミスも、まとめて手放せる設計です。

そして、その「足す」中身の要になるのは、追加のシステム開発やSIerへの発注ではなく、kintoneのアプリで作る一枚の判定データです。日ごろkintoneでアプリを作ったり項目を設定したりしている方であれば、地続きの延長線上で用意できます。

ここで一点、範囲をはっきりさせておきます。kintoneの標準機能だけで完結するのは「判定データを用意する」ところまでです。そのデータを実際に引いて仕訳へ反映する実行部分には、別途データ連携の仕組み（n8n）を組み合わせます。この記事の後半では、その連携までを含めたワークフローの全体像と、要所となる設定を実際の画面とともに紹介します。

とはいえ、なぜその設計で埋まるのかを理解するには、まず「そもそもなぜ科目だけがこぼれ落ちるのか」という原因を押さえる必要があります。次の章では、業務の構造からその理由を解きほぐしていきましょう。

なぜ「仕訳まで自動」の期待から、勘定科目だけがこぼれ落ちるのか

freee for kintoneの取引登録機能が自動化できる範囲と、製品コード別の勘定科目判定が手動で残る境界を示した図

本記事執筆時点（2026年8月）に自社の導入環境で確認したかぎり、原因は一点に絞れます。取引登録機能が、製品コードに応じて勘定科目を切り替える仕組みを持っていないからです。

取引登録機能が自動化できるのは、あらかじめ決まった型に沿って仕訳の枠を作るところまでです。「受注が入ったら売上の仕訳を1本立てる」という定型の処理は得意とします。

一方で、「この製品コードなら製品売上、あの製品コードなら修繕売上」というように、データの中身を見て科目を条件ごとに振り分ける判断は、その守備範囲の外にあります。この線引きが、科目だけ手動で残る理由のすべてです。

問題は、製造業の売上科目がまさにこの「振り分け」を求める点にあります。製品売上・部品売上・修繕売上といった区分は、会計上は別の勘定科目として扱う必要があります(※科目の区分は各社の会計方針によります)。

同じ受注という入り口から入ってきても、製品コードによって行き先の科目が枝分かれするわけです。取引登録機能が持たない条件ごとの判定を、業務側は毎回求めている。この食い違いが、ここで生まれています。

その結果どうなるか。条件ごとの判定を機械が肩代わりできない以上、判定は経理担当の記憶と注意力に委ねるしかありません。

月次で仕訳の件数が積み上がれば、1件ずつ科目を選ぶ工数がそのまま担当者にのしかかります。そして注意力に頼る作業である以上、カテゴリの取り違えによる選択ミスも避けきれません。工数と属人化という2つの負担が、静かに積み上がっていく状態です。

「あと一歩で自動」を素朴に詰めようとすると、どこで止まるか

freee for kintoneで科目判定を自力で埋めようとしたときに詰まる3つの落とし穴を順に示した図

では、この「あと一歩」を自力で埋めようとすると、実際にはどこで手が止まるのでしょうか。ここからは、取引登録機能の仕様から導かれる詰まりどころを、つまずく順に3つ並べます。

取引登録機能の設定を探しても、製品コード別に科目を割り当てる項目がない

最初に多くの方がやるのは、取引登録機能の設定画面を隅々まで探すことです。「製品コードごとに科目を割り当てる設定が、どこかに隠れているのではないか」と期待して探します。

しかし、その設定項目自体が用意されていません。前章で述べたとおり、条件ごとの科目の振り分けは取引登録機能の守備範囲の外だからです。ないものを探している状態なので、いくら設定画面を見ても答えは見つからず、ここで一度手が止まります。

分岐で埋めようとすると、製品・科目の増加でメンテが破綻する

設定に無いと分かると、次は連携の側で無理やり埋めにいく発想に移ります。「製品コードがAならこの科目、Bならこの科目」という条件分岐を、処理の中に直接書き込んでいく方法です。

製品の種類が数個のうちは、これでも動きます。ところが製造業の製品コードは、新製品の追加や取扱いの変更で増え続けるのが常です。科目の区分が見直されることもあります。

そのたびに分岐を書き足し、書き換える運用は、早晩まわらなくなります。条件を処理に直書きした構造は、変更のたびに壊れやすい弱点を抱えているのです。

結局は手動運用に戻り、取り違えと工数がそのまま残る

分岐でも維持できないと分かると、多くの現場は元の手動運用へ引き返します。自動化しきれないなら、当面は人が選ぶしかないという判断です。

そして振り出しに戻った結果、最初の悩みがそのまま残ります。科目を1件ずつ選ぶ工数と、カテゴリの取り違えによる選択ミスです。

取り違えれば仕訳の修正が発生し、締めたはずの月次をもう一度締め直す手戻りにつながります。「あと一歩」のはずが、結局その一歩を越えられずに元の場所へ戻ってしまう。これが、素朴に詰めにいったときにたどり着きがちな地点です。

freee for kintoneのギャップを、kintone連携でマッピングテーブルに外付けして埋める設計

受注の製品コードでkintoneのマッピングテーブルを引き勘定科目を確定して仕訳へ反映する外付け設計のフロー図

3つの落とし穴を裏返すと、埋め方の輪郭が見えてきます。共通する原因は「判定の仕組みを持つべき場所に、それが無い」ことでした。

ならば、その判定をデータとしてkintone側に外付けするのが設計の勘所になります。ここで用意するのは専門業者への追加発注ではなく、kintoneでアプリを1つ作る範囲の判定データです。以下、落とし穴に対応する形で3つの勘所を実行順に示します。

足りない「製品コード↔勘定科目」の判定表を、kintoneアプリのマッピングテーブルで持つ

1つ目の落とし穴は、割り当ての設定項目が存在しないことでした。無いなら、自分で用意します。

用意するのは「製品コード」と「対応する勘定科目」を1対1で並べた対応表です。これを、kintoneのアプリとして作ります。片方の列に製品コード、もう片方の列にその製品コードで使う売上科目を入れておく、いわばマッピングテーブル（対応表アプリ）です。

kintoneでアプリを1つ作れる方なら、特別な開発なしに用意できます。ここまでが、kintoneの標準機能だけで完結する範囲です。取引登録機能に無かった判定を、機能の外側にデータとして持たせる。この発想の転換が起点になります。

受注の製品コードでテーブルを引き、科目を確定してから仕訳へ渡す

2つ目の落とし穴は、条件分岐の直書きがメンテで破綻することでした。これを避ける鍵が、判定を「分岐」ではなく「データ参照」で行う点にあります。

処理の流れはこうです。受注データに入っている製品コードをキーにして、先ほど作ったマッピングテーブルを引きます。対応する勘定科目を1件取り出し、その科目を確定させたうえで仕訳へ渡します。

この「引いて反映する」部分を担うのが、kintoneのデータを外部の処理につなぐ連携の仕組みです。連携がやるのは「表を引いて答えを受け取る」ことだけで、どの製品がどの科目かという知識は一切持ちません。判定の中身はすべてテーブル側にあるので、連携の構造はシンプルなまま保てます。

外部の処理につなぐ連携の具体的な組み方については、販売管理システムとkintoneをn8nで連携した記録や、n8n×Claudeでkintoneの週報作成を半自動化した事例もあわせて参考にしてください。

科目改定はマッピングテーブルの更新だけで、手動運用に戻らない

3つ目の落とし穴は、変更に耐えられず手動運用へ逆戻りすることでした。データ参照の設計は、この逆戻りそのものを防ぎます。

新製品が増えても、科目の区分が見直されても、直すのはマッピングテーブルの1行だけです。製品コードと科目の対応をアプリ上で追加・修正すれば、それ以降の仕訳はその新しい対応で判定されます。連携そのものには手を入れません。

変更点が「表の1行」に集約されている状態なので、改定のたびに壊れる心配がなく、手動運用へ引き返す理由もなくなるはずです。判定を人の記憶からデータへ移したことで、属人化からも抜け出せます。

実際に組んでみる：ワークフローの全体像と、要所の設定

考え方が固まったところで、この外付けを実際にどう組み上げるかを見ていきます。設定を一手ずつ追うのではなく、ワークフローの全体像と、つまずきやすい要所だけを画面とともに押さえます。

まずは全体像：受注から仕訳まで、どうつながっているか

組み上がった全体の流れです。受注データを起点に、マッピングテーブルを引いて勘定科目を確定し、その結果を仕訳へ渡す。この一連を、kintoneのアプリとデータ連携の仕組み（n8n）でつないでいます。

bm100-ss-01-overview

ワークフローは大きく3つのブロックに分かれています。受注データを受け取る入り口、マッピングテーブルを引いて科目を確定する判定部、確定した科目を仕訳へ渡す出口です。判定の知識はすべてマッピングテーブル側にあるため、ワークフロー自体は「表を引いて答えを受け取る」だけの素直な形に収まります。

要所その1：製品コードでマッピングテーブルを引く

一つ目の要所は、受注データの製品コードをキーにして、マッピングテーブル（kintoneアプリ）から対応する勘定科目を取り出す設定です。

bm100-ss-02-lookup

ここで指定するのは「どのアプリの、どの項目を、何と照合して引くか」だけです。製品コードと科目の対応そのものはテーブルが持っているので、この設定に個別の製品名や科目名を書き込む必要はありません。条件を処理へ直書きしないという設計の勘所が、そのまま設定にも表れる箇所です。

要所その2：取り出した科目を仕訳へ渡す

もう一つの要所は、テーブルから取り出した勘定科目を、仕訳を起こす側へ受け渡す設定です。

bm100-ss-03-mapping

取り出した科目を、仕訳側の科目欄に対応づけて流し込みます。ここまでつながれば、受注が入るたびに製品コードから科目が自動で決まり、手作業での選び直しは要らなくなります。新しい製品や科目の改定があっても、手を入れるのはマッピングテーブルの中身だけで、このワークフローの設定はそのまま使い続けられます。

「あと一歩」を埋めると、freee for kintoneの連携はどこまで伸びるか

足りない機能は、待つのでも大掛かりに作り込むのでもなく、判定データを外付けして補う。これが本記事でお伝えしたかった考え方です。この考え方さえ掴めれば、当初期待していた「仕訳まで自動」は、勘定科目まで含めて成立する見立てが立ちます。

科目を1件ずつ選ぶ工数は要らなくなり、カテゴリの取り違えによる仕訳修正や締め直しも起こりにくくなるはずです。経理担当が本来注力すべき締めや分析に時間を回せる月次へと、少しずつ形を変えていけるでしょう。

思い出していただきたいのは、詰まる場所が有限だったことです。設定項目が無い、分岐が破綻する、手動に逆戻りする。つまずくのはこの3か所で、いずれも判定データを外付けするという一つの発想で解ける見立てが立ちます。

判定データを持たせるところまではkintoneの標準機能の範囲で、その先の「引いて反映する」連携を組み合わせれば、「大掛かりな開発が要るのでは」という最初の懸念点は解消できます。

同じように「freee for kintoneの限界を自動化で補う」という発想は、kintoneのステータス変更でfreeeの請求書を自動発行する仕組みにも通じるはずです。kintone×生成AIの活用の全体像を押さえたい方は、kintoneユーザーのための生成AI実践大全もあわせてご覧ください。

最後に

ライブAI開発の案内

株式会社アディエムでは、kintone × 生成AIで日々の業務改善に取り組んでいます。
今回ご紹介したような例の他にも、お客様の業務に合った改善をご提案させて頂きます。
無料相談も実施しておりますので、お気軽にお問い合わせ頂ければ幸いです。

お問い合わせはこちら

関連記事