Lark BitableのAPI連携｜業務データの集約とNotionとの使い分け

公開: 2026年4月9日更新: 2026年10月26日約7分で読めます

Lark Bitable（多次元表）はAPIで外部から読み書きでき、問い合わせやタスクなどの業務データを、手作業の転記なしで他のツールやAIエージェントから参照できるようになる。ツールを1つに統一するより、担当者が慣れたツールはそのままに、APIでつなぐほうが現場の負担が少ない。この記事の構成では、連携の構築に1日ほどかかった。

業務データが3箇所に散らばっていた

顧客の問い合わせ管理はLarkのBitable。タスク管理はNotion。広告データは各広告媒体の管理画面。ツールごとにログインして、手作業でデータを突き合わせて、スプレッドシートに転記する。この作業に1日30分使っていた。月に10時間。

「全部1つのツールにまとめればいい」と思うかもしれない。でも現実には無理だ。顧客管理を担当しているスタッフはLarkに慣れている。自分はNotionでタスクを管理するのが合っている。

ツールを統一する代わりに、ツールをAPIで繋ぐことにした。

Lark Bitableを「読める」ようにする

Larkの中にあるBitable（多次元表）は、見た目はスプレッドシートだが中身はデータベースだ。テーブルにフィールドを定義してレコードを格納する。AirtableやNotionのデータベースと同じ構造。

APIで外部から読み書きできるようにすると、Larkに手動でアクセスしなくてもデータを他のシステムから参照できる。

API連携の最初の壁：テーブル構造の把握

Larkの管理APIを使って、まずテーブル一覧を取得する。返ってくるJSONにテーブルIDと名前が入っている。次にフィールド一覧を取得。各フィールドの型（text, number, dateTime, singleSelect等）がわかる。この情報を手元に持っておけば、フィルタ条件やソート条件を正しく書ける。

実際のテーブル構造例

問い合わせ管理テーブルを例に出す（項目名は一般化している）。

状況（singleSelect）：受付・対応中・完了等
対応予定日（dateTime）：予定日時
対応年月（text）：集計用（2026-03 形式）
顧客番号（text）：社内の顧客ID
流入経路（singleSelect）：Web・紹介・SNS 等

このテーブルに対して「状況 = 対応中」かつ「対応年月 >= 2024-11」でフィルタすれば、直近の対応中の案件一覧が取れる。

API権限の落とし穴

実際にハマったポイントを書いておく。

同じBaseの中に十数個のテーブルがあったが、APIで取得できたのは一部だけだった。管理画面では見えているのに、APIからは「テーブルが存在しない」と返ってくる。

原因はテーブルレベルのアクセス権限だった。Baseに高度な権限（Advanced permissions）が設定されていると、アプリが入っているロールで閲覧を許可されたテーブルしかAPIから見えない。管理画面で見えるのは自分のロールの権限で、アプリのロールとは別だ。

対処法は2つ。

アプリをBaseのコラボレーターに追加する。アプリとして動くトークン（tenant_access_token）でBaseを操作するには、アプリがそのBaseのオーナーかコラボレーターになっている必要がある。Baseのメニューからアプリを追加し、必要な権限（閲覧／編集）を与える。画面の項目名は更新されることがあるため、Lark公式ヘルプで確認してほしい
高度な権限のロールを確認する。高度な権限を有効にしているBaseでは、アプリを入れたロールで読めるテーブルしかAPIから見えない。必要なテーブルの閲覧をそのロールに許可する

APIが「繋がる」ことと「データが見える」ことは別の話。権限設定を1つずつ確認する地道な作業が、連携構築の半分を占める。

NotionとLarkの使い分け

「NotionもLarkもデータベースがあるなら、どっちかに統一すればいいのでは？」

実際に使い分ける理由がある。

Notion：ドキュメント×データベースの融合が得意。API成熟度が高い。タスク・ナレッジ・議事録に向く
Lark Bitable：大量データの管理・検索・集計が得意。Webhook対応でリアルタイム性が高い。顧客情報・予約・対応履歴に向く

要するに、「誰が日常的に触るか」で決まる。顧客の予約情報はスタッフが毎日更新する。彼らはLarkを使い慣れている。一方、タスク管理やナレッジベースは自分しか使わないから、Notionに置く。

ツールの統一ではなく、データの参照を統一する。どのツールにデータがあっても、API経由で1箇所から横断参照できればいい。

AIエージェントからLarkデータを直接参照する

ここが本題。Lark BitableのAPIを、AIエージェントのMCPツールとして接続する。MCPは「Model Context Protocol」の略で、AIエージェントが外部ツールを使うための仕組みだ。

例えば、こんなことができる。

「今月の対応中の案件数を教えて」→ Bitable APIでフィルタクエリを実行し、件数を返す
「直近3ヶ月の流入経路別の問い合わせ数を出して」→ 対応年月でフィルタし、流入経路でグループ集計
「顧客番号XXXXの案件の状況は？」→ 顧客番号フィールドで検索してレコードを返す

手動でやると、Larkにログイン→テーブルを開く→フィルタ条件を設定→結果を確認→スプレッドシートに転記で5〜10分。AIエージェント経由なら、聞いた瞬間に答えが返ってくる。

しかも、このデータとNotionのタスク情報、BigQueryの広告データを組み合わせて分析することもできる。「今月の問い合わせ件数と広告のCVを比較して」——AIが複数のデータソースを横断して回答する。

連携構築のコストは「1日」

LarkのAPI連携は、以下の手順で1日あれば構築できる。

Lark Developer ConsoleでAPIアプリケーションを作成（30分）
必要なスコープを設定（10分）
テーブル構造の把握（30分）
MCPサーバーの設定（1時間）
テスト（30分）
権限問題の解消（0〜2時間）

最もよくハマるのは手順6だ。フィールドの追加がPermission deniedになる原因と対処はLark Bitable APIでフィールド追加できない原因で詳しく書いた。「APIは繋がるけどデータが見えない」。アプリをBaseに追加したか、高度な権限のロール、APIトークンのスコープ——確認すべき箇所が複数ある。

手順どおりなら合計3〜5時間ほど。余裕を見て1日（8時間）かけても、3つのツールを突き合わせて転記していた毎日30分の作業がなくなるなら、16営業日、つまり3週間ほどで元が取れる。

あわせて読みたい

ツールを1つにまとめるより、APIでつなぐほうが現場の負担が少ないことは多い。どのデータからつなぐか迷っている段階なら、まずは現在地を知るところからで十分だ。

無料のAI活用診断を受ける（6問・約1分） →