n8n × Claude で議事録を案件・記事案・ナレッジ・タスクに自動振り分けする実装ガイド

会議が 3 本続いた日の夜、Slack でこんなやり取りを目にすることがあります。「あの議事録、結局誰に転送した？」「あの発言、記事ネタにできそうだったけど、どこに書いた？」「あの顧客の依頼、対応漏れてないよね？」。議事録は出席者と書記の頭の中にしか残らず、半日経つと事実上消える — これが多くの中堅・中小企業のバックオフィスで起きている現実です。

本記事では、はてなベース株式会社が社内運用している「議事録自動振り分け」の実装図を全文公開します。Google Drive に置かれた会議メモを n8n（業務自動化ツール — ノーコードで API 同士をつなげるプラットフォーム）が監視し、Claude（Anthropic 製の生成 AI）が 4 系統に分類 して、それぞれ別の業務システムに自動投入する仕組みです。10 ノードのワークフロー JSON、プロンプト設計、運用での落とし穴まで、実際に作って 2 週間運用した結果を整理してお届けします。

なぜ議事録振り分けが業務改革のレバーになるのか

中堅・中小企業のバックオフィスでよく見るのは、「いい話」が会議の中で出るのに、それが行動につながらない構造です。営業同行で顧客が「あの記事よかった、もっと書いてくれ」と言っても、議事録に書きっぱなしで終わる。1on1 で部下が「この業務、自動化したい」と言っても、Slack で 1 度共有されるだけで具体化しない。

原因は単純で、議事録を「誰かが読んで」「関係する人に転送して」「対応の流れに乗せる」という人手の中継ぎが必要なためです。書記担当が忙しい時期は転送が止まり、転送先の人が休暇のときは流れが切れます。結果として、月に何百件と発生する「いい発言」のうち、業務として拾われるのは数件にとどまります。

ここに AI を差し込むと、人手の中継ぎが要らなくなります。Claude のような大規模言語モデル（LLM — ChatGPT や Claude の中身、大量の文章から学習した自動分類エンジン）に議事録を渡すと、「これは記事になる発言」「これは顧客が求めている対応」「これは社内ナレッジ」「これは担当者のタスク」といった種類別の分類が高い精度で返ってきます。人手で 30 分かかる仕分けが、Claude では数十秒で終わります。

全体アーキテクチャ — 4 系統に分けて、別々のシステムに流す

今回のシステムは、議事録を入口にして 4 つの出口に流すルーターです。それぞれの出口は社内ですでに使っている業務システムで、新たに作るのは「振り分け」の部分だけ。既存資産を活かせるのが n8n を使った設計の強みです。

5 番目に「雑談」というタグも設けていて、上記 4 系統のいずれにも該当しない発言（世間話や余談）は破棄します。これがないと、Claude が「とにかく何かのタグに振り分けないと」と無理矢理な分類をして精度が落ちる経験則から導入しました。

n8n の 10 ノード構成 — どこで何が起きるか

n8n はノードと呼ばれる小さな機能ブロックを線でつなぐ業務自動化ツールです。今回のワークフローは 10 個のノードで構成されています。実際の JSON ファイルを GitHub に置いてあるので（scripts/n8n/minutes-routing-workflow.json）、自社環境で import すれば認証情報を差し替えるだけで動かせます。

プロンプト設計のコツ — 「JSON で返す」を絶対に守らせる

Claude に「議事録を 5 タグに分類してください」と素朴に頼むと、人間向けに「以下のように分類しました」と前置きをつけたり、JSON のフォーマットが崩れたり、タグ名が表記揺れしたりします。n8n の Code Node で機械的にパースする必要があるので、出力形式を厳格に固定しないと運用が破綻します。

システムプロンプトには次の 5 つを必ず入れています。(1) タグの定義一覧、(2) タグ間の判別基準（特に「アクション」と「営業フォロー」の違い）、(3) 出力 JSON のスキーマ例、(4) 「同じ発言を複数タグに重複させない」「最も適合性が高いタグ 1 つだけ」のルール、(5) 補足説明や前置きを禁止する一文。

あなたは経営コンサル事務所の編集デスクとして、議事録を以下の5タグに分類するアシスタントです。

タグ一覧:
- 記事ネタ: ブログ記事化できる視点・実例・データ
- 営業フォロー: 顧客発言で次のアクションが必要なもの
- 社内ナレッジ: 業務手順・ツール使い方・運用ルール・失敗事例
- アクション: 担当者が明示的に着手宣言したタスク
- 雑談: 上記いずれでもない

出力は必ず以下の JSON 配列形式で返す:
[
  {
    "tag": "記事ネタ",
    "summary": "...",
    "detail": "...",
    "speaker": "...",
    "suggested_slug": "...",
    "suggested_category": "..."
  },
  ...
]

判断基準:
- 同じ発言を複数タグに重複させない（最も適合性が高いタグ 1 つ）
- 「記事ネタ」は読者が知りたがる視点であって、社内事情を含めない
- 「営業フォロー」は具体的な次のアクションが含まれているもの
- 「アクション」と「営業フォロー」の違い: 担当者主観の宣言（アクション）vs 顧客起点の依頼（営業フォロー）

前置き・後書き・補足説明は禁止。JSON 配列のみ返すこと。

Code Node では Claude のレスポンス本文から JSON 配列だけを正規表現で抜き出します。前置きをつけられても安全に処理できるようにする保険です。

// Claude のレスポンスから JSON 配列を取り出す
const body = $input.item.json.content?.[0]?.text || '';
const match = body.match(/[s*{[sS]*?}s*]/);
let items = [];
if (match) {
  try {
    items = JSON.parse(match[0]);
  } catch(e) {
    items = [];
  }
}
return items.map(it => ({ json: it }));

Switch Node で 4 系統に振り分ける

Code Node から出力された各 item は { tag: '記事ネタ', summary: '...', ... } のような形になっています。これを Switch Node で「tag フィールドの値」を条件にして 4 つの出口に振り分けます。

Switch Node の設定は 4 つの「条件」を順に並べ、最後に fallback として「上記のどれにも該当しない（=雑談）」を破棄するルートを作ります。fallback を作らないと、Claude が想定外のタグを返したときにエラーで止まるので必須です。

出力先システム — kintone / Notion / Google Tasks をどう繋ぐか

記事ネタ → kintone「記事案アプリ」

はてなベースでは記事案を kintone のアプリで管理しています。app id 1535（仮）に対して、HTTP Request ノードから POST するだけです。API トークンは事前にアプリ設定から発行しておきます。

curl -X POST https://hatenabase.cybozu.com/k/v1/record.json 
  -H 'X-Cybozu-API-Token: <APP_TOKEN>' 
  -H 'Content-Type: application/json' 
  -d '{
    "app": 1535,
    "record": {
      "article_title": { "value": "<<Claude が返したタイトル候補>>" },
      "status": { "value": "検討中" },
      "category": { "value": "<<Claude が判定したカテゴリ>>" },
      "source_url": { "value": "<<元議事録 URL>>" }
    }
  }'

営業フォロー → kintone「商談アプリ」

営業アプリは既に運用済みのものを使います。フィールド名が業界・社内で異なるので、ここは各社の実装に合わせてマッピングが必要です。期限フィールドには n8n の $now.plus({days:7}) で +7 日を入れて、対応漏れを防ぎます。

社内ナレッジ → Notion DB

業務手順や運用ルールは Notion のデータベースに集約しています。n8n には Notion Integration が組み込みノードとしてあるので、データベース ID とプロパティ名を指定するだけで OK。Notion の Integration を該当 DB に Share しておくのを忘れないでください。

アクション → Google Tasks

「○○さん、月末までに準備しておいて」という発言は、発言者本人の Google Tasks に直接登録します。タスクの期限は +3 日をデフォルトに、ただし議事録本文に日付が含まれていればそれを優先するロジックを Code Node で追加しています。

完了通知 — Slack で集計を見える化

1 つの議事録から最終的に「記事ネタ 2 件 / 営業フォロー 3 件 / ナレッジ 1 件 / アクション 5 件」のような集計が出ます。これを Slack の専用チャンネル #pr-minutes-routing に投稿することで、誰がどの議事録から何を拾ったかが社内で透明化されます。

副次的な効果として、「あ、自分宛のアクションが入った」とその場で気づける動線になっています。Google Tasks の通知は人によってオン／オフが分かれるため、Slack 通知のほうが反応率が高い実感があります。

運用 2 週間で見えた落とし穴 5 つと回避策

導入効果 — 月 10 時間が月 30 分に

はてなベースで 2 週間運用した結果、議事録 1 本あたりの処理時間は次のように圧縮できました。

月 10 時間を月 30 分まで圧縮。年単位では 100 時間以上の作業を回収できる試算です。重要なのは「自動化」ではなく「圧縮」と捉えること。最終的な送信判断や承認は人間が行うので、人手をゼロにはできませんが、「読む・分類する・転送先を選ぶ」の中継ぎ作業がほぼ消えます。

コスト面でも軽量です。n8n（セルフホスト・Render）月 14 ドル、Anthropic API（議事録 1 本あたり 0.05〜0.10 ドル、月 20 本で 2 ドル前後）、合計で月 2,500 円程度。圧縮した時間 1 時間あたりに換算すると 250 円 / 時間で、社員の時間単価のはるか下です。

次のステップ — 議事録を超えて全社情報フローへ

議事録振り分けが安定稼働すると、自然に「他の情報源も振り分けたい」という発想が出てきます。社内 Slack の主要チャンネル投稿、お問い合わせフォームの回答、サポートメール、商談録音の文字起こしなど、入口を増やすだけで n8n + Claude のロジックはほぼそのまま再利用できます。

ここまでくると、社内の「情報をどう流すか」というレイヤーがソフトウェアで支えられる状態になります。属人化していた中継ぎ作業が消えて、判断と意思決定だけに人間のリソースが集中する状態 — これが AI エージェント時代の中小企業バックオフィスの姿だと考えています。

まとめ

議事録は会議に参加していない人にこそ価値があります。出席者の頭の中で消えてしまう「いい話」を、AI が機械的に拾って関係する人や業務システムに流す仕組みを作ると、組織の情報フローが一段強くなります。n8n × Claude の組み合わせは、コードを書かなくても 10 ノードで完成するので、最初の AI エージェント導入として最も着手しやすい領域です。本記事の JSON ワークフローを下敷きに、ぜひ自社の文脈に合わせて手を入れてみてください。