Manus Airtable連携 使い方｜1プロンプトで在庫・顧客DBを更新する手順

ManusのAirtable連携は「Airtableを開いて探して、直して、集計して…」を、ひとつの自然文プロンプトに寄せる使い方がいちばん効きます。この記事では、在庫・案件・キャンペーンのDBを例に、検索と更新とレポートを同時に回す手順を、そのまま貼って試せるプロンプト付きでまとめます。

結論だけ先に言うと、成功のカギはAIの指示文よりもテーブル側の“更新していい範囲”を先に決めることです。ここが曖昧だと、便利さより怖さが勝ちます。

ManusのAirtable連携でできること（検索語：Manus Airtable連携 使い方）

Airtableは、見た目はスプレッドシートでも、中身はデータベースです。Manusとつなぐと、自然文で「どのレコードを探し」「どのフィールドをどう更新し」「結果をどう報告するか」まで一気通貫にできます。

できること：現場で効くのはこの3パターン

1) 条件検索→更新
たとえば「在庫が10未満の商品だけ拾って、発注フラグをON」みたいな、毎回同じ条件の更新が早くなります。

2) 複数テーブルをまたいだ整合
「案件テーブルのステージが“契約”になったら、請求テーブルに行を作る」など、参照関係（リンク）を使った更新が得意です。

3) 更新結果のレポート化
更新した件数、対象ID、例外（更新できなかった理由）を、そのまま報告フォーマットに整えて出せます。

できないこと（ここを期待するとズレる）

Manusは強力ですが、Airtableの設計がぐちゃぐちゃな状態を「いい感じに直して」と任せると、だいたい破綻します。フィールド名が揺れている、IDがない、同じ意味の列が複数ある、といった状態は先に整えたほうが早いです。

Manus Airtable連携の使い方：最短セットアップ手順

ここはスクリーンショットで説明するつもりで、迷いどころだけ書きます。細かい画面名はアップデートで変わるので、見つからなければ「Connectors」「Integrations」周りを探してください。

手順1：Airtable側で「更新されると困る列」を分離する

最初におすすめなのは、AIが触ってよい列と、人が確定させる列を分けることです。たとえば在庫管理なら、こんな分け方が安全です。

• AIが更新してよい：発注フラグ、補足メモ（AI）、更新理由（AI）、次アクション
• 人が確定：仕入先、発注数量、原価、納期

編集者としては、最初の運用は「AIはフラグを立てるだけ」に寄せるのが失敗しにくいです。いきなり数量や金額まで書かせると、1回の誤更新が重い。

手順2：レコードを一意に指せるID（またはユニークキー）を用意する

人間は「商品名」で探せますが、DB更新は「同名」や「表記ゆれ」に弱いです。AirtableにはレコードIDがありますが、業務上のキーも欲しい場面が多いので、次のどちらかを用意します。

• 推奨：SKU、案件番号などのユニークキー列を作る
• 代替：レコードIDを必ず出力させ、更新はID指定に固定する

手順3：ManusでAirtableコネクターを接続し、対象Baseを限定する

接続時に権限を広げすぎると、AIが「似たテーブル」を誤爆します。最初はテスト用Baseを作り、動いたプロンプトだけ本番に持ち込むのが現実的です。

料金やプランで接続範囲が変わることがあります。ここは公式ページで確認してください。

すぐ試せる：1プロンプトで「検索→更新→レポート」を回す例

以下はManusに貼って使う前提のテンプレです。あなたのテーブル名・フィールド名に合わせて、角括弧だけ置き換えてください。

例1：在庫が少ない商品だけ「発注フラグ」を立てて、更新結果を報告

あなたはAirtableオペレーターです。
Airtable Base「[在庫管理]」のテーブル「[Products]」を対象に、次を実行してください。

1) 条件検索：
- [在庫数] が 10 未満
- [発注フラグ] が OFF
- [販売停止] が OFF

2) 更新：
- 該当レコードの [発注フラグ] を ON
- [更新理由（AI）] に「在庫<10のため。自動で発注候補に設定」と記入
- [更新日時（AI）] を今日の日付で記入

3) 出力（レポート）：
- 更新件数
- 更新したレコードの [SKU] と [商品名] と [在庫数]
- 例外（条件に合うが更新できなかったもの）があれば理由

重要：
- 更新対象は上記条件に完全一致したものだけ。
- 数量や原価など、指定していないフィールドは絶対に変更しない。
- 不明点があれば更新前に質問して止まること。

この手の更新は「やり直し」が面倒なので、不明点があれば止まる条件をプロンプト内に明記しておくと安心です。

例2：案件のステージ変更に合わせて「次アクション」を埋める（人の判断を残す）

Airtable Base「[営業パイプライン]」のテーブル「[Deals]」で、次を実行してください。

- 条件検索：
  - [ステージ] が「見積提出」
  - [最終接触日] が 7日以上前
  - [次アクション] が空

- 更新：
  - [次アクション] に、状況確認の連絡案を1行で記入（敬語、短く）
  - [担当者への確認事項（AI）] に、担当者が確認すべき質問を2つ書く

- 出力：
  - 更新した案件の [案件番号] / [会社名] / [金額]
  - 「連絡して良いか判断が必要」なものがあれば、その理由も書いてリスト化

制約：
- [ステージ] 自体は変更しない。
- 顧客への送信文は作るが、自動送信はしない（下書き扱い）。

ここでの狙いは、AIにクロージングをさせることではなく、担当者が止まらない材料を揃えることです。Airtableを「次の会話の準備置き場」にすると回りやすいです。

例3：キャンペーン週次レポート（集計→異常値→改善案）をAirtableから作る

Airtable Base「[マーケ運用]」のテーブル「[Campaigns]」を集計して、週次レポートを作成してください。

- 対象期間：直近7日
- 集計対象フィールド例：
  - [費用], [CV], [CPA], [クリック], [CTR]

やること：
1) 期間内の全キャンペーンを集計し、CPAの良い順に上位5件・悪い順に下位5件を出す
2) 下位について「数字の崩れ方」を短く説明（CV減/費用増/CTR低下など）
3) 改善案は各キャンペーン1つだけ（やりすぎない）

出力形式：
- 見出し付きのレポート
- 最後に「今週の確認ポイント（3つ）」

改善案を盛りすぎると、現場が動けなくなります。個人的には、週次レポートは“やることを減らす”ための文章に寄せるのが好きです。

失敗しやすい点と注意点（ここで事故が起きる）

曖昧な条件で更新してしまう

「在庫が少ない」「最近連絡してない」などの言い方は、人間には通じますが更新条件としては危険です。条件は数字・日付・空欄判定に落とし、完全一致したら更新に固定します。

同名レコードの誤更新（表記ゆれ）

商品名や会社名は揺れます。更新対象はSKUや案件番号で絞る、またはManusの出力に必ずレコードID（またはユニークキー）を出させ、更新ログを追える状態にしてください。

上書き事故を防ぐ「書き込み先」を決めていない

自由記述のメモ欄をAIが触りだすと、誰が何を書いたか分からなくなります。おすすめは、AI専用の列を用意して、そこにしか書かせない運用です（例：更新理由（AI）、補足メモ（AI））。

テスト環境なしで本番を触る

Airtableは編集が簡単な分、戻すのが面倒な場面があります。テスト用Baseを複製して、更新件数が10件未満の条件から慣らすのが安全です。

この使い方が向いている人・向かない人

向いている人

• Airtableを「見るだけ」になっていて、更新が後回しになりがちなチーム
• 毎週同じ条件で抽出し、同じ列を埋めている作業がある人
• 更新後の報告（件数・対象・例外）を毎回作っている人

向かない人

• テーブルの意味（各列の定義）が決まっていない状態で、とにかく自動化したい人
• 更新ミスがそのまま請求・発送・法務リスクにつながるのに、承認フローがない人

まとめ

ManusのAirtable連携は、派手な自動化よりも「検索して、決まった列を埋めて、結果を報告する」を1プロンプトにまとめるのが強いです。最初は、数量や金額ではなくフラグやメモに寄せる。更新対象をユニークキーで縛る。ここまで決めると、Airtableが“手作業の沼”になりにくくなります。

参考リンク

• One Prompt to Search, Update, and Report Across Your Entire Airtable Base（Manus Blog）