Nottaの標準連携はkintoneに保存するまで。商談議事録を案件履歴に変えるのはn8nの役割

対面や電話でこなした商談の内容を、あとで担当者が議事録としてkintoneに書き起こします。この「後で書く」運用が、実は案件情報の属人化と記録の薄さを生んでいます。

Nottaで文字起こしと要約まで自動化し、kintoneへの保存もできるようにしました。それでも案件レコードを開くと、その商談の経緯がどこにも残っていません。

この記事では、なぜ「保存まで」できても案件に残らないのかを整理します。そのうえで、その先をNotta・生成AI・n8nでどうつなぐのかを、自社の検証環境で試した記録をもとに解説していきます。

本記事で扱う用語をはじめに押さえておきましょう。Nottaが作る文字起こしとAI要約を、ここでは「議事録」と呼びます。

その議事録を、kintoneの案件レコードに正しく紐づけて時系列に積み上げたものが「案件履歴」です。この2つは似ているようで別物であり、その差がこの記事のテーマになります。

kintoneに保存できたのに、案件レコードには商談が埋まらない

商談の記録をkintoneで管理する際の代表的な選択肢が、Nottaのkintone連携です。会議や商談の音声から文字起こしとAI要約を作り、それをkintoneのアプリへ保存できます（Notta公式のkintone連携）。

ここまでは実際にうまく動きます。商談が終わったら要約がkintoneに保存され、「これで商談記録の仕組みができた」と感じるでしょう。

ところが、いざ案件レビューや引き継ぎで過去の商談を遡ろうとすると、肝心の案件レコードには何も残っていません。要約は確かにkintoneのどこかに保存されているのに、「A社の見積もり案件」のレコードを開いても、その商談の経緯が見当たらないのです。

下の画面は、検証環境で実際に作った案件マスタのレコードです。商談を積み上げるための「商談履歴」テーブルは用意されているのに、中身は空のまま。ここに経緯がたまっていくはずが、保存した要約とは結びついていないのです。

標準連携で保存まで自動化したのに、なぜ案件では追えないのか。しかも、この振り分けまで作り込むとなると、SIerに発注する大がかりな開発案件になるのではないか。ここで、もう一段のハードルを感じるかもしれません。

保存と案件に残ることは別物。特定・振り分けまでやれば履歴になる

先に結論をお伝えします。「kintoneに保存する」ことと「案件レコードの履歴に残る」ことは、別の作業です。 標準連携が担うのは前者までで、後者には「その要約がどの案件の話か」を判断する処理が必要になります。

自社の検証環境では、Nottaの要約を起点に、生成AIが決定事項・次アクション・課題を決まった形に抽出しました。そのうえでn8nが要約から「どの案件の話か」を特定し、該当する案件レコードの履歴に自動で追記するところまでを組みました。担当者があとで貼り直す・探す・保存し直すという作業は、どこにも残りません。

鍵になるのは、標準連携が止まる「保存まで」の一歩先です。要約から案件を特定し、正しいレコードへ振り分けます。この判断こそがn8nの役割であり、ここを自動化して初めて商談は案件履歴になります。

そしてこの部分は、SIerに作り込みを発注しなくても組める範囲です。kintoneのアプリやワークフローに触れている担当者であれば、詰まる場所さえ分かれば手が届きます。

kintone 議事録の標準連携は保存まで、案件特定と履歴への振り分けはn8nが担う守備範囲の図

案件への紐づけを後回しにする運用が、商談記録の空白を生む

なぜ案件レコードが空白のままになるのか。原因は「商談メモは後で書く」という前提そのものにあります。

対面や電話の商談は、その場では記録に手が回りません。だからあとで担当者がメモを起こす前提で進みます。ところが忙しいと後回しになり、いざ書こうとする頃には記憶が薄れています。

結果として記録は断片的になり、しかもその内容は担当者本人の頭の中にしか残りません。

この状態が続くと、標準連携で要約を「保存」できていても、それがどの案件のものか紐づかないまま埋もれてしまいます。担当者本人は要約のありかを覚えていても、本部や引き継ぎ側から見ると、その案件の経緯は追えない状態のままです。 現場の状況が本部から見えづらいという課題と、構造はよく似ています。

商談情報が個人に属人化して案件の時系列から抜け落ちてしまいます。この空白を埋めることも、記録を仕組みで残す狙いの一つです。技術的に自動化できるかどうかと、それを社内の誰が回すかは別の問題ですが、まずは仕組みとして何が足りないのかを見ていきましょう。

保存の先で、手作業が3つ残っていた

自動化に着手する前、検証環境では担当者がNottaや録音の文字起こしを生成AIに手で貼り付けて要約し、それをkintoneに保存していました。標準連携で保存まではできるようになっても、「商談を後で手で処理する」という前提そのものは変わっていません。

なぜ手作業が残るのか。それは、標準連携が「保存」の手前で止まり、その先の判断をしないからです。踏んだ順に、残る3つを見ていきます。

保存はできても、要約を生成AIに貼り直して整える手間が残る

標準連携が保存する要約は、そのままでは案件履歴として読み返すには書き方がばらばらでした。決定事項なのか、次のアクションなのか、先方の懸念なのかが1つの文章に混ざったままです。

これは要約の質の問題ではありません。「保存する」という機能が、中身を項目ごとに整理する役割までは持たないためです。

だから担当者は、保存された要約をもう一度生成AIに貼り直し、読み返せる形に整えていました。この貼り直す一手間が、忙しい日には後回しの入口になります。

「どの案件の話か」を人が判断して探す作業が消えない

要約を整えても、次に立ちはだかるのが案件の特定です。Nottaの連携で選べるのは「どのkintoneアプリのどのフィールドに保存するか」までで、要約の中身から「これはどの案件のレコードか」を判断する仕組みはありません（Notta公式のkintone同期の仕様、2026年時点）。

そのため、その商談が「どの案件のものか」は、要約を読んで人が判断し、kintoneで該当レコードを検索して開くしかありませんでした。

さらに厄介なのが案件名の表記ゆれです。「A社様」「A株式会社」「A社・第2案件」のように同じ相手でも呼び方が揺れるため、完全一致で探すと目的のレコードにたどり着けません。同じ顧客で複数の案件が並行しているときは、この特定作業が地味に重くのしかかります。

特定した案件レコードへ保存し直す最後の一歩まで手作業

案件を特定できても、最後に残るのが転記です。整えた要約を、特定した案件レコードの履歴欄へ貼り付けて保存する必要があります。

標準連携は指定したフィールドへ保存するところまでは担いますが、「特定したレコードの履歴に積み増す」という書き込みは範囲外です。そのため、この最後の一歩も人の作業でした。

貼り直し・特定・保存し直しという3つの手作業が積み重なり、忙しいときほど「あとでまとめてやる」に回されます。そうして記録は薄いまま、案件履歴には残らなかったのです。

kintone 議事録の保存後に残る3つの手作業（貼り直し・案件特定・保存し直し）を示す図

保存の先を、n8nと生成AIでつなぎ切る

3つの手作業は、いずれも「保存の先」で発生していました。裏を返せば、この3か所さえ自動でつなげば、商談は案件履歴になります。

しかも足すのは、既存のkintone・Notta・生成AIに月額課金のワークフローツールを1つ加えるだけの構成であり、大がかりなSIer開発は必要ありません。検証環境で落ち着いた設計を、先ほどの詰まりに対応させる形で、実行順に紹介します。

先に、組み上がった全体像をお見せします。下の画面が、これから紹介する処理を1本につないだn8nのワークフローです。左のトリガーから、要約の受け取り・3項目への整理・案件の特定・履歴への追記までが一続きに並んでいます。以降は、この流れを実行順に見ていきます。

Nottaの要約をトリガーにn8nを起動し、貼り直しをなくす

起点は、Nottaの文字起こしと要約が完了したタイミングです。この完了をきっかけにn8nを起動し、要約データを自動で受け取ります。人がkintoneや生成AIの画面を開いて貼り付ける工数は、ここでまるごと消えるわけです。

n8nは500種類以上のサービスとつなげるワークフロー自動化ツールで、こうした「あるサービスの完了を起点に次の処理を走らせる」流れをノーコードで組めます。n8nそのものが初めての方は、n8nとは何かを解説した入門記事もあわせてご覧ください。

生成AIで決定事項・次アクション・課題を決まった形に抽出する

受け取った要約は、そのまま保存せず生成AIに渡し、「決定事項」「次アクション」「課題」の3項目に整理させます。先ほどの「書き方がばらばら」という詰まりを、ここで解消するわけです。あらかじめ出力の形を決めておけば、あとから案件履歴として読み返したときに、どの商談も同じ形式で並びます。

ここでのプロンプト設計が、履歴の読みやすさを左右します。自由に要約させるのではなく、項目と書き方を固定しておくことが勘所です。生成AIを業務にどう組み込むかは、kintoneユーザー向けの生成AI実践記事でも掘り下げています。

下の画面が、その3項目への整理を担う生成AIのノードです。プロンプトで「決定事項」「次アクション」「課題」の3つに分けて出力するよう指示し、あわせて顧客名の表記もそろえさせています。

案件名の表記ゆれを吸収して”どの案件か”を特定する

もっとも重要なのが、この案件特定です。「人が判断して探す」という詰まりに、正面から向き合う部分になるでしょう。

要約に含まれる案件名や顧客名を、生成AIに表記を統一させたうえで、kintoneの案件マスタと照合して1件に絞り込みます。完全一致だけで探すと表記ゆれで失敗するため、いったん呼び方をそろえてから照合するのがポイントです。

複数候補が出た場合や一致しなかった場合は、「要確認」のフラグを立てて別扱いにする設計にしました。無理に1件へ紐づけて誤った案件に記録するより、人が確認する対象として残すほうが安全だからです。

下の画面が、その照合を担う処理です。会社名から法人格や敬称を取り除いて呼び方をそろえ、案件マスタと突き合わせて1件に絞り込みます。複数候補が出たときや一致しなかったときに「要確認」へ分ける分岐も、ここに含めています。

案件レコードの履歴テーブルに追記し、上書きしない

特定できた案件レコードには、履歴を追記する形で保存します。「最後の一歩まで手作業」だった転記を、n8nが自動で担う部分です。

既存の商談履歴を上書きせず、テーブルに1行ずつ足していく設計にすれば、商談は時系列で積み上がっていく仕組みです。上書きにすると、せっかく残した過去の経緯が最新の要約で消えてしまいます。追記型にしておくことが、「経緯を追える案件履歴」を成立させる条件です。

ここまでの処理が正しく動くと、どの議事録がどの案件に紐づいたか（あるいは要確認になったか）と、抽出された3項目を一覧で確認できます。案件マスタへ書き込む前にこの段階で結果を目視できるようにしておくと、安心して運用に載せられます。

保存で止まっていた商談が、経緯を追える案件履歴に変わる

こうして組み上げると、標準連携の「保存まで」で止まっていた商談が、案件レコードの履歴にそのまま積み上がるようになります。担当者があとで書く・貼り直す・探すという作業は発生せず、話した内容がそのまま案件の記録として残るわけです。

案件レビューや引き継ぎのとき、レコードを開けば商談の経緯が時系列で並んでいます。担当者が不在でも、本部や別のメンバーがその案件で何が起きたのかを追えます。属人化していた商談情報が、組織で共有できる状態に変わるのです。

kintone 議事録をn8nと生成AIで案件履歴に自動保存するワークフロー全体図（Notta要約→3項目抽出→案件特定→履歴追記）

ここまでを振り返ると、人が判断していたのは、要約の貼り直し・案件の特定・保存し直しの3つの場面でした。この3つをn8nと生成AIでつなぐという範囲が分かっていれば、仕組みそのものはSIerへの大規模発注ではありません。kintoneのアプリやワークフローに触れている担当者であれば、自社の手が届くところにあります。

あとは、その手を動かす時間を社内で確保できるか、誰が担うかという体制の話になります。技術的な実現可能性と、社内で回せるかどうかは切り分けて考える必要があるでしょう。

まとめ

Nottaの標準連携は、文字起こしとAI要約をkintoneに保存するところまでを担います。しかし「保存できること」と「案件履歴に残ること」は別で、後者には要約から案件を特定して振り分ける処理が必要です。

その処理で手作業として残っていたのが、要約の貼り直し・案件の特定・履歴への保存の3つでした。Nottaの要約を起点にn8nを起動し、生成AIで項目を整理し、表記ゆれを吸収して案件を特定し、履歴テーブルへ追記します。この流れを組めば、商談メモを「後で書く」前提から抜け出し、話した内容がそのまま案件履歴になるのです。

最後に

案件マスタの持ち方や案件名の付け方は会社ごとに違うため、特定の組み方や詰まる場所も変わります。

自社の環境でどう組めばよいか判断がつかない場合は、ものづくりAI自動化ファクトリーの無料相談をご利用ください。kintoneと生成AI・外部サービスをつなぐ自動化を、現場の業務に沿って設計するお手伝いをしています。

関連記事