DeepSeek から Feishu Base の既存レコードを更新するには、対象テーブルを読み書きできる接続手段が必要です。注文番号を完全一致で検索し、一件だけ該当したら変更案を確認します。承認後は指定された項目だけを書き込み、同じレコードを読み直します。Tabbit Browser の公開事例では、CSV の取り込みにブラウザーを使っています。
Yingdao の利用者は、商品 ID から対象のレコード ID を探した後、項目の書き込みでエラーが出たと報告しています。 Yingdao の投稿
要点
業務キーが対象テーブルの一つの
record_idに対応することを確かめます。変更前後の値、項目の型、空欄の扱いをプレビューします。
定期処理には権限のある API を使います。人が監督する単発作業ではブラウザーも候補です。
承認された項目だけを書き込み、同じレコードを読み直します。
タイムアウト後は先に現在の値を確認し、必要な場合だけ再試行します。
接続方法を選ぶ
| 接続方法 | 向いている作業 | 事前確認 |
|---|---|---|
| Feishu API | 権限のある連携による定期処理 | テーブルの検索、ID 指定の更新、結果の読み取りができる |
| ブラウザー | 人が監督する単発作業 | 現在のページで編集でき、同じレコードを開き直せる |
ブラウザーの権限はログイン中のアカウントに従います。 API、MCP、ブラウザーの比較 と 既存のブラウザーセッションへの接続方法 を参照してください。
1. 完全一致で一件に絞る
Base、テーブル、検索範囲を確かめます。注文番号 00018 は先頭のゼロが残るよう文字列として扱います。結果の全ページを確認し、一件だけ一致したら record_id を記録します。ブラウザーで ID が見えない場合は、同じ詳細画面を開ける固定リンクを使います。行番号は並べ替えで変わります。 Feishu のレコード検索
ビューのフィルターや高度な権限設定でレコードが見えない場合があります。ゼロ件なら検索範囲を確認します。例外を調べられるように CSV の元の行も控えます。 Feishu Base の FAQ · 出典を追える CSV 抽出
2. 変更前後の値を確認する
架空の例として、注文 00018 のステータスを Pending から Reviewed に、数量を 2 から 3 に変えるとします。テーブル名、キー、ID、変更前後の値を表示します。同じキーの指示が二つあれば、同じ内容はまとめ、矛盾する内容は書き込む前に確認します。
Reviewed が単一選択の既存項目で、数量の 3 が数値であることを確かめます。日時は単位とタイムゾーンをそろえます。空欄は変更なし、消去、入力エラーのどれかを事前に決めます。Feishu の API は ID を指定して項目を部分更新できます。実際のコネクターが受け付ける引数を確認してください。Lark CLI では以前、コマンドのオプションと API の引数の違いが報告されました。 Feishu の更新 API · Lark CLI の報告
適用前にもう一度読み、プレビュー以降に変更があれば中断します。再読込と書き込みは別の操作です。初回は ブラウザー作業のチェックリスト に沿って一件に絞ります。
Tabbit の公開事例で確認できる CSV 取り込み
2026 年 9 月 3 日の Tabbit 公開事例 では、DeepSeek Harness が DeepSeek V4 Flash High を使い、CSV を Feishu Base に取り込みました。当時の環境では最初の API 接続を利用できず、ログイン済みの Tabbit とページの構造化ツールに切り替えています。録画の報告は 200 件、26 項目で、日時の形式を統一した後の差分はゼロでした。
既存レコードの更新では、現在のセッションで検索、編集、読み直しができるかを確認します。接続には Harness のブラウザープラグインガイド、権限には ブラウザー権限の解説 を参照してください。 DeepSeek Harness 公式リポジトリ · Tabbit 公式プラグイン
3. 同じレコードを読み直して再試行を判断する
同じ ID か詳細リンクを使い、キーと正規化した値を承認済みのプレビューと比べます。キー、ID、対象項目、照合結果を記録します。 Feishu のレコード取得 · ブラウザー自動化の結果確認
| 確認結果 | 対応 |
|---|---|
| ゼロ件または複数件 | 更新を見送り、範囲、権限、重複を確認する |
| 一件だけ一致し、値も一致 | 確認済みにして書き込みを省く |
| 一件だけ一致し、元の値のまま | 承認済みの項目を更新して読み直す |
| タイムアウト、読み取り失敗、予想外の値 | 作業を止め、同じレコードを読み直してから再試行を判断する |
例の 00018 がすでに Reviewed と 3 なら作業を終了します。Pending と 2 のままなら前の要求が実行中でないか確認します。どちらとも違うなら変更の競合を調べます。同じ書き込みを繰り返すと後続の自動処理が動くことがあります。
ブラウザーを使う場合は、一件を読み取り専用でプレビューします。同じレコードを開き直して値を確認できた段階で、変更を承認するか判断します。
よくある質問
DeepSeek は Feishu Base を更新できますか？
対象のレコードを検索、編集、再読込できる接続手段があれば可能です。Tabbit の公開事例は CSV の取り込みです。
業務キーと record_id は同じですか？
注文番号などの業務キーは入力データに由来します。record_id は Feishu が割り当てる識別子です。先に業務キーが一件だけ一致することを確かめます。
キーが見つからない場合や重複している場合は？
更新専用の処理では両方をスキップして記録します。新規作成には別の許可と重複確認が必要です。
いつ API を使いますか？
権限を持つ連携で同じ処理を繰り返す場合です。監督できる作業では、対象ページとアカウントが編集を許せばブラウザーも使えます。
途中で止まったらどう再試行しますか？
先に同じレコードを読みます。正規化した値が一致すれば確認済みにします。異なる場合は他の編集を確かめてから再試行を判断します。