この記事でわかること

• Lark MCP × Claude 連携の実装レシピ10本 — Base の自然言語集計・議事録のタスク化・日次レポート自動投稿など、当社が毎日本番運用している具体例を再現手順つきで
• Lark MCP と公式 Lark CLI の使い分け基準 — 「判断が要る処理は MCP、決まった処理は CLI」をレシピごとに当てはめた実務の線引き
• Claude Code への接続最短手順 — claude mcp add 一行での登録方法と、国際版 Lark で必須のドメイン指定(公式一次情報で確認)
• 事故を起こさない導入順序 — 読取系 → 確認付き書込系 → 定期実行、と権限を段階的に広げる進め方
• つまずきポイントと料金の一次情報 — トークン失効・レート制限・プラン別の Base 行数/自動化回数上限(2026年10月26日時点の公式確認値)

目次

1. 結論 — レシピは「読取→書込→定期実行」の順で広げる。MCP と CLI は役割分担
2. 前提 — Lark MCP 設定は3ステップ。Claude Code との接続最短手順(公式ソース)
3. Lark MCP と Lark CLI 使い分けの3原則 — どのレシピをどちらで組むか
4. レシピ①〜③【読取系】 — まず壊しようのない集計・検索・ブリーフィングから
5. レシピ④〜⑧【書込系】 — 議事録タスク化・Base自動更新・メール下書き
6. レシピ⑨〜⑩【定期実行】 — 日次レポートと「毎朝9時のパイプライン」
7. 当社の運用の裏側 — 240h→24h と「この記事自体が自動運用の産物」という話
8. つまずきポイント5つ — ドメイン指定・トークン・権限・上限
9. コスト — Lark MCP / Lark CLI は無料。かかるのは Lark プランと AI 側の費用(一次情報)
10. よくある質問(FAQ)
11. まとめ

結論 — レシピは「読取→書込→定期実行」の順で広げる。MCP と CLI は役割分担

結論: Lark MCP × Claude 連携で成果を出す最短ルートは、①読取系レシピ(集計・検索・ブリーフィング)で効果を体感し、②「AI が下書き・人が確認」の書込系(タスク化・Base更新・メール下書き)に広げ、③毎日回る処理だけをスケジューラ × CLI の定期実行に固定する——という3段階です。AI に文脈判断をさせる処理は MCP、同じ手順を確実に繰り返す処理は公式 Lark CLI と役割分担すれば、事故なく「人が Lark 内を往復していた手作業」を機械に寄せられます。

前提の整理です。Lark MCP(正式には Lark OpenAPI MCP)は Lark 提供元による公式 MCP サーバーで、npm パッケージ @larksuiteoapi/lark-mcp として MIT ライセンス(無料)で公開されています(公式リポジトリ、2026年10月26日確認)。一方 Lark CLI は、同じく公式がオープンソースで提供するコマンドラインツールで、ドキュメント・Base・カレンダー・メール・メッセージ・会議までを AI エージェントやスクリプトから操作でき、対応 AI ツールとして Claude Code・Cursor などが公式に明記されています(Lark CLI 公式ドキュメント・Lark 公式ブログ、2026年10月26日確認)。つまり「MCP か CLI か」はどちらも公式ルートであり、選択基準は処理に判断が要るかどうかだけです。

そしてもう一つの結論は、うまくいくかどうかは「レシピの具体性」で決まるということです。民間調査では DX に取り組んだ企業の 64% が「失敗した」と回答したとの報告があり(Gron 調査、2026年)、IPA の「DX動向」でも、日本企業の DX はツール導入段階で止まり業務プロセスの見直しまで到達しにくい構造が繰り返し指摘されています(IPA「DX動向」)。「MCP を繋いだ」で終わらせず、「毎週の集計 30 分」「議事録からのタスク転記 15 分」という名前のついた手作業単位で置き換える——本記事の10本は、すべてその粒度で書いています。Claude と Lark で何ができるかの全体像はClaude × Lark 連携でできること10選、Base 側の API 実装の基礎はLark Base API × MCP 自動化の実装入門で先に押さえられます。

前提 — Lark MCP 設定は3ステップ。Claude Code との接続最短手順(公式ソース)

結論: 接続は「①Lark 開発者コンソールでアプリを作成して App ID / App Secret を取得 → ②用途に必要な権限(スコープ)だけ付与 → ③Claude Code に claude mcp add 一行で登録」の3ステップで、国際版 Lark では -d https://open.larksuite.com のドメイン指定が必須級のコツです。

Claude Code への登録は、公式ドキュメント(Claude Code — MCP、2026年10月26日確認)にあるとおり claude mcp add コマンドで行います。--(ダブルダッシュ)より後ろがサーバー起動コマンドです。

claude mcp add --transport stdio lark -- npx -y @larksuiteoapi/lark-mcp mcp \
  -a <your_app_id> -s <your_app_secret> -d https://open.larksuite.com

登録後は claude mcp list で接続状態を確認できます。チームで設定を共有したい場合は、プロジェクト直下の .mcp.json に mcpServers 形式で書く方法もあります(同公式ドキュメント)。個人のカレンダーやメッセージを「本人として」操作するレシピ(後述の③など)では、公式の login サブコマンドでブラウザ認証を通し、起動引数に --oauth --token-mode user_access_token を加えます(公式リポジトリ)。

Lark CLI のほうは、公式ドキュメントのとおり一行でインストールできます(Lark CLI 公式ドキュメント、2026年10月26日確認)。

npx @larksuite/cli@latest install
lark-cli auth login   # ユーザー本人としてログイン(個人のカレンダー・メッセージを扱う場合)

アプリ作成・権限付与・プリセットによるツール絞り込みなど、lark mcp 設定の詳しい手順とスコープ設計はLark MCP 完全ガイド2026に全て書いてあるため、本記事では繰り返しません。ここから先は「繋がったあと」の話に集中します。

Lark MCP と Lark CLI 使い分けの3原則 — どのレシピをどちらで組むか

結論: ①内容を読んで判断・要約・分類する処理は MCP(AI がツールを選んで呼ぶ)、②同じ入力に同じ結果を返すべき定型処理は CLI(スクリプトで決定的に回す)、③判断と実行の両方が要る処理は「判断は AI・実行は CLI」の併用とし、毎日・毎週の無人実行はスケジューラから起動する——の3原則で振り分けます。

原則	向いている処理	本記事のレシピ
判断が要るなら MCP	要約・分類・抽出・下書きなど、内容を読んで考える処理	①②④⑤⑦
決まった処理なら CLI	同じ集計・同じ更新・同じ通知を確実に繰り返す処理(③は定時配信の場合)	③⑥⑨
併用(判断は AI・実行は CLI)	AI が内容を判断し、読み書きは決定的なコマンドで実行。無人化するならスケジューラから AI を起動	⑧⑩(⑥も実更新は CLI)

この線引きの理由は再現性です。MCP 経由の AI 操作は柔軟ですが、対話のたびに判断が変わりうる「非決定的」な実行です。毎朝9時の定型通知のような「絶対に同じ形で届いてほしい」処理を AI の判断に委ねると、たまの気まぐれが事故になります。逆に、議事録の要約やメールの下書きのような処理はそもそも決定的に書けないので、AI にしかできません。両者は競合ではなく分担——これが当社が毎日運用して到達した結論です(詳しい比較表は完全ガイドの使い分け章にあります)。

レシピ①〜③【読取系】 — まず壊しようのない集計・検索・ブリーフィングから

結論: 最初の一歩は読取系です。書込権限を渡さずに始められるため事故リスクが構造的に低く、「探す・集計する・まとめる」という最も時間を食う手作業から効果が出ます。

レシピ① Base を自然言語で集計・抽出する(脱・関数とフィルタ地獄)

何が変わるか: 「今月の案件をステータス別に数えて」「未対応で優先度が高い行だけ表にして」を、Base のフィルタやピボットを触らずチャット一言で取り出せます。
組み方: MCP。Base の読取ツール(公式プリセットの Base 系)だけを有効化すれば、書込権限ゼロで動きます。
プロンプト例:

受注管理の Base(URL貼り付け)を読んで、今月の案件をステータス別に集計し、
「停滞(最終更新が14日以上前)」の案件だけ担当者つきの表にして。

当社ではこの形で、記事の編集カレンダー(Base)から「未着手でスコアが高いテーマ」を毎朝抽出しています。Excel から Base への移行がまだの方は、先にLark Base が中小企業の業務効率を変える3つの理由で「なぜ台帳を Base に寄せると AI が効くのか」を押さえてください。

レシピ② 社内ドキュメント・Wiki を横断検索して根拠リンク付きで答えさせる

何が変わるか: 「あの規定どこだっけ」「前回の見積り条件は」を、ドキュメントと Wiki の横断検索 → 要約 → 原文リンク付き回答に置き換えます。新人の「聞きにくい質問」の受け皿にもなります。
組み方: MCP。ドキュメント検索・読取系ツールのみ有効化。
プロンプト例: 「社内 Wiki から出張精算のルールを探して、上限金額と申請手順を原文リンク付きで3行にまとめて」。回答に必ず原文リンクを付けさせるのがコツで、AI の要約ミスがあっても人が一次情報へ戻れます。

レシピ③ 今日の予定とタスクを毎朝ブリーフィングさせる

何が変わるか: 朝いちでカレンダー・タスク・未読を自分で巡回する10分を、「今日の予定と締切、準備が要るものだけ教えて」の一言(または定時の自動通知)に置き換えます。
組み方: 対話で聞くなら MCP(個人の予定を扱うためユーザートークン認証が必須。--oauth --token-mode user_access_token)。毎朝決まった形で届けたいなら、CLI をスケジューラから回す方が確実です。当社の実運用コマンド例:

lark-cli calendar +agenda --days 1   # 今日の予定を取得(当社の実運用例)

タスク管理そのものの整え方はLark タスク管理完全ガイド2026を参照してください。

レシピ④〜⑧【書込系】 — 議事録タスク化・Base自動更新・メール下書き

結論: 書込系は「AI が下書き → 人が確認して確定」の一手間を最初は必ず残すこと。権限は書込先(タスク・Base・ドラフト)単位で最小化し、効果とログが溜まってから確認を外していきます。

レシピ④ 会議メモ・議事録からタスクを自動起票する(議事録タスク化)

何が変わるか: 会議後の「決まったことの転記・宿題の起票・担当への連絡」をまとめて肩代わり。議事録からのタスク転記は1回15分でも、週5会議なら月5時間です。
組み方: MCP(ドキュメント読取 + タスク作成)。
プロンプト例:

この議事録(URL)から「宿題」を全部抽出して、担当者・期限つきで Lark タスクに
登録して。期限が書かれていないものは仮で来週金曜にして、一覧表で確認させて。

ポイントは最後の「一覧表で確認させて」。登録前に AI の抽出結果を人がレビューする一拍を挟むことで、誤起票を公開前に止められます。

レシピ⑤ チャットの問い合わせを分類して Base 台帳に自動追記する

何が変わるか: 問い合わせチャットに流れてくる依頼を、AI が「種別・緊急度・担当」を判定して管理台帳(Base)へ追記。対応漏れの温床だった「チャットの流れた依頼」が台帳に残ります。
組み方: MCP(メッセージ読取 + Base 追記)。問い合わせの受け皿をフォームに寄せられるなら、フォーム→Base は Lark 標準機能で足り、AI は分類だけに専念させられます。
プロンプト例:

問い合わせチャット(チャット名)の今日のメッセージを読んで、依頼ごとに
「種別(見積/不具合/相談)・緊急度(高/中/低)・要約1行」を判定し、
問い合わせ台帳 Base(URL)に追記して。判定に迷ったものは追記せず一覧で見せて。

「迷ったものは追記せず見せて」の一文が保険です。AI の分類精度は運用初期ほど人のレビューで育てます。

レシピ⑥ Base の一括メンテナンス(表記ゆれ統一・ステータス一括更新)

何が変わるか: 「会社名の表記ゆれを統一したい」「完了案件を一括アーカイブ」のような数百行規模の一括更新を、エクスポート→Excel加工→再インポートなしで実行。
組み方: 判定は MCP、実更新は CLIの合わせ技が安全です。AI に対象行と変更内容の一覧(JSON)を作らせて人が確認し、実際の書込は決定的なコマンドで流します。当社の実運用例:

lark-cli base +record-batch-update --base-token <base_token> \
  --table-id <table_id> --json @update.json   # AIが作ったupdate.jsonを人が確認してから実行

一括更新には1回あたりの件数上限があるため、大量更新は分割実行が前提です(この手の上限は後述のつまずき章参照)。

レシピ⑦ 週報・定例ドキュメントの自動生成

何が変わるか: Base の実績データとチャットの報告を AI に読ませ、週報・月次報告のドキュメントをテンプレどおりに生成。「書くために集める」時間が消えます。
組み方: MCP(Base 読取 + ドキュメント作成)。テンプレの見出し構造をプロンプトに固定で埋め込むのがコツで、毎回同じ体裁になります。
プロンプト例:

案件管理 Base(URL)の今週更新分を読んで、以下の見出し構造どおりに
週報ドキュメントを新規作成して。
# 週報(MM/DD週) → ## 今週の実績(数字3つ) → ## 進行中案件と停滞案件
→ ## 来週の予定 → ## 相談したいこと(なければ「なし」)

この「定型プロンプトの固定化」を進めると、Claude Code のスキル(再利用可能な手順書)に昇格させる道があります。詳しくはClaude Code スキルで Lark 業務を定型自動化する2026で解説しています。

レシピ⑧ メールの要約と返信下書き(送信は人が確定)

何が変わるか: 「今日来た未対応メールを要約して、定型の返信下書きを作る」まで AI が実施、送信ボタンだけ人が押す運用。Lark CLI は公式にメールの検索・読取・下書き・送信まで対応しています(Lark CLI 公式ドキュメント、2026年10月26日確認)。
組み方: 併用型(判断は AI・実行は CLI)。Claude Code に Lark CLI(ユーザー認証)を使わせ、メールの取得と下書き保存はコマンド、要約と文面の作成は AI が担当します。
指示例: 「lark-cli で今日の受信メールを取得して、未対応のものを要約一覧にして。定型の問い合わせには当社の回答テンプレ(URL)に沿った返信を下書き保存して。送信はしないで」。自動送信までは最初は組まないのが鉄則です。誤送信は取り返しがつかない失敗のため、「下書きまで自動・送信は人」の線を当社も崩していません。

レシピ⑨〜⑩【定期実行】 — 日次レポートと「毎朝9時のパイプライン」

結論: 毎日・毎週の無人実行はスケジューラ × CLI で決定的に固定し、途中に「書く・選ぶ」工程が挟まる場合だけ、スケジューラから Claude Code を非対話モードで起動して AI に MCP / CLI を使わせます。ここまで来ると「人が始業前に仕込む」作業自体が消えます。

レシピ⑨ 日次レポートの自動投稿(Base 集計 → チャット通知)

何が変わるか: 「毎朝9時に、昨日の受注件数・在庫アラート・本日の締切を運営チャットに投稿」が無人で回ります。当社の実測では、担当者が毎週手集計してチャットに貼っていた 30〜40 分/週の作業がこの形でゼロになりました。
組み方: スケジューラ(Windows タスクスケジューラや cron) × CLI。集計ロジックが固定なら AI は不要で、CLI でレコードを取得・集計してメッセージ送信コマンドに渡すだけです。当社の実運用例:

lark-cli base +record-list --base-token <base_token> --table-id <table_id> \
  --format ndjson --output ./records.ndjson        # ① 台帳を取得
node summarize.mjs records.ndjson > body.txt        # ② 集計して本文を組み立て(数十行の集計スクリプト)
lark-cli im +messages-send --chat-id "oc_xxxx" --text "$(cat body.txt)"   # ③ チャットへ投稿

②の集計スクリプト自体も「この ndjson をステータス別に数えて1行サマリーを出す Node スクリプトを書いて」と Claude Code に作らせれば、プログラマーがいなくても一式が揃います。あとは Windows タスクスケジューラや cron に毎朝の実行を登録するだけです。

レシピ⑩ 複数ステップのパイプライン — 「選ぶ→作る→公開する→記録する」を毎朝無人で

何が変わるか: 単発レシピの先にあるのが、複数工程の連結です。当社で毎朝9時に無人実行しているコンテンツ制作パイプラインは、①編集カレンダー(Base)から次に作るテーマを選定 → ②下調べと原稿作成 → ③公開 → ④結果(公開日・URL・品質スコア)を Base に書き戻し → ⑤ログ記録という5工程を一度に流します。
組み方: スケジューラが Claude Code を非対話モード(-p / print モード)で起動し、手順書(プロンプト)を渡す構成です。当社の実運用を一般化すると、起動部分はこの1行に集約されます。

claude -p "$(cat daily-pipeline-prompt.md)"   # 手順書を渡して非対話実行(毎朝9時にタスクスケジューラ/cronで起動)

手順書には「①編集カレンダー Base から未着手で優先度最高のテーマを選ぶ → ②一次情報を照合しながら原稿を作る → ③公開する → ④結果を Base に書き戻す」という工程と判断基準を日本語で書いておきます。テーマの選定や原稿作成のような「判断と執筆」は AI が行い、Base の読み書きや公開処理は AI が CLI / API を呼んで実行します。判断は AI・実行は決定的なコマンド・起動はスケジューラという三層が、この記事で紹介した使い分け3原則の集大成です。

重要なのは、いきなり⑩を目指さないことです。当社もレシピ①の「Base を読んで選定する」だけの状態から始め、書込(④の書き戻し)、公開処理、と工程を一つずつ足して現在の形になりました。90日単位で自動化を積み上げる進め方は中小企業 DX 進め方 90日ロードマップ、12ヶ月の全体工程はLark DX 完全ロードマップ2026に整理しています。

当社の運用の裏側 — 240h→24h と「この記事自体が自動運用の産物」という話

結論: 当社(アウフヘーベンジャパン株式会社・群馬県前橋市)は自社EC事業の間接業務を Lark に集約して月240時間→24時間(90%削減・自社比)を実証し、その後この記事のレシピ⑩のパイプラインで自社メディアの運営も自動化しました。実は、いまお読みのこの記事自体が「毎朝9時に起動するパイプラインが、編集カレンダーからテーマを選び、公式ソースを照合しながら書き、公開した」1本です。

自社ECでの 240h→24h の削減は、派手な AI 機能ではなく「情報の置き場所を Base に一本化し、転記・集計・督促を仕組みに寄せる」ことで実現しました(経緯は自社EC事業の実装記録)。MCP / CLI 連携は、その延長線にある「仕組みに AI の判断を差し込む」段階です。毎日運用して分かったことを3つだけ共有します。

• 効くのは「名前のついた手作業」の置き換えだけ — 「AI で何かできないか」から入ったものは全部続きませんでした。「毎週月曜の集計30分」のように対象が特定できたものだけが定着しています
• 事実の検証工程を AI 任せにしない設計が要る — 当社のパイプラインには「公式一次情報と照合してからでないと公開できない」ゲートを組み込んでいます。AI の出力をそのまま外に出す運用は、社外向けでは危険です
• 止まったことに気づける監視をセットで — ユーザートークンの失効などで自動化は静かに止まります。「動かなかった朝に通知が来る」仕組みまで作って完成です

こうした運用は特別な大企業の話ではありません。中小企業庁の中小企業白書でも、人手不足への対応として省力化投資・デジタル化の重要性が繰り返し示されています(中小企業庁 中小企業白書)。人を増やせないなら、手作業を機械に寄せる——その実装手段が、ここまで安価に公式提供されている時代になった、ということです。

つまずきポイント5つ — ドメイン指定・トークン・権限・上限

結論: 実運用でつまずくのは「①国際版ドメインの指定漏れ ②テナント/ユーザートークンの取り違え ③権限の渡しすぎ ④トークン失効の放置 ⑤レート制限・行数上限の見落とし」の5点で、いずれも先回りで潰せます。

つまずき	回避策
繋がらない(ドメイン)	既定は中国版 Feishu のドメインのため、日本で使う国際版 Lark は -d https://open.larksuite.com を必ず指定(公式リポジトリ)
個人の予定・メールが読めない	テナント(アプリ)トークンは「ボットとしての操作」。本人として操作するレシピ(③⑧)は login + --oauth --token-mode user_access_token のユーザー認証に切り替える
権限の渡しすぎ	読取系レシピに書込・削除ツールを渡さない。プリセットや -t オプションで用途のツールだけ有効化する(設計手順は完全ガイド参照)
自動化が静かに止まる	ユーザートークンには有効期限があり、失効すると再ログインが必要。定期実行には「失敗したら通知」の監視をセットで組む
大量処理で止まる	API のレート制限と一括更新の件数上限を前提に、分割・リトライで設計。Base の行数上限はプラン依存(Starter 2,000行/テーブル、Pro 2万行 — 次章参照)で、台帳設計の段階から意識する

コスト — Lark MCP / Lark CLI は無料。かかるのは Lark プランと AI 側の費用(一次情報)

結論: Lark MCP も Lark CLI もオープンソースで追加料金はありません。実費は (a) Lark のプラン費用と (b) Claude 側の費用の2つで、Lark 側は無料の Starter プラン(20名まで)でも連携を開始できます。本格運用の目安は社員30名で Lark Pro 月額 ¥1,420 × 30 = 約42,600円(税抜・年払い)です。

Lark 公式料金ページ(2026年10月26日確認)によれば、各プランの連携に関わる上限は次のとおりです。

プラン	料金(1ユーザー/月)	自動化・データの主な上限
Starter	無料(20名まで)	Base 2,000行/テーブル・オートメーション月1,000回・ストレージ100GB
Pro	¥1,420(税抜・年払い)	Base 2万行/テーブル・オートメーション月5万回・ストレージ15TB
Enterprise	要お問い合わせ(個別見積)	Base 5万行/テーブル・オートメーション月50万回

検証だけなら Starter で十分始められます。無料枠でどこまで行けるかはLark 無料プランでどこまでできるか、プラン全体の比較と隠れコストはLark 料金 完全ガイド2026にまとめています。なお、そもそものツール選定で kintone や Microsoft Teams と迷っている段階なら、Lark vs kintone 徹底比較とLark vs Microsoft Teams 比較が判断材料になります。AI 連携のしやすさ(公式 MCP / CLI の充実度)は、2026年のツール選定では無視できない比較軸です。

よくある質問(FAQ)

関連記事

• Lark MCP 完全ガイド2026 — セットアップ・プリセット・権限設計の正本
• Claude × Lark 連携でできること10選2026 — 連携の全体像
• Lark Base API × MCP で自社業務を自動化する — 実装入門
• Claude Code スキルで Lark 業務を定型自動化する2026
• Lark Base が中小企業の業務効率を変える3つの理由
• 中小企業 DX 進め方 90日ロードマップ【失敗例から逆算】
• Lark vs kintone どっちを選ぶべきか【中小企業向け徹底比較】
• Lark vs Microsoft Teams【M365 既契約でも選ぶべき3パターン】
• lark-dx.jp トップ — Lark 導入支援・DXコンサルティング

---

本サイトは アウフヘーベンジャパン株式会社 が運営しています。Lark は ByteDance Ltd. の登録商標です。当社は Lark の導入を支援する独立した第三者コンサルティング事業者であり、ByteDance 社の公式機関ではありません。Claude は Anthropic PBC の商標です。本記事に記載したツールの仕様・料金・コマンドは2026年10月26日時点で各公式ドキュメント・公式料金ページにより確認したものですが、今後のバージョンアップにより変更される場合があります。最新情報は必ず各公式ページでご確認ください。