Lindyに繰り返し作業を任せるときは、依頼文だけでなく、いつ動くか、どのデータを見るか、結果をどこへ届けるかを確認します。現行のLindy TeammateのRoutinesでは、設定後にdry runで対象と判断を点検し、実際の送信や書き込みの確認と分けて進められます。
この記事はLindy Teammateの現行ドキュメントに基づく手順です。旧Agent Builderのワークフロー手順とは区別します。実製品での作成、接続、dry run、通知は検証していません。以下のメールと約束の例は架空です。
目次
先に「何を見つけ、何をしないか」を決める
例として、自分の送信メールから、資料を送ると約束したまま残っている項目を確認したいとします。「フォローアップして」だけでは、未完了の約束を一覧にするのか、相手へメールを送るのかが曖昧です。
最初の成果物は、自分が確認するための一覧に絞ります。
表は横にスクロールできます
| 決めること | 架空の指定例 |
|---|---|
| 読む対象 | 指定期間の、自分が送信したメール |
| 抽出するもの | 自分が資料送付などを約束した記述 |
| 記録するもの | 元メール、約束した内容、期限の記載、未確認点 |
| しないこと | 相手への送信、期限の推測、完了状態の勝手な確定 |
| 結果の届け先 | 自分が確認できるチャネル |
期限が書かれていなければ「未記載」、送付済みか分からなければ「未確認」と残します。返信がないことだけで、約束を果たしていないとは断定しません。
RoutinesでPersonalとWorkspaceを見分ける
左サイドバーの Routines を開きます。公式は、個人のLindyが自分のために実行する Personal と、Slack上のLindy Teammateを通じてチームで動く Workspace を分けています。Workspaceの作成・管理には管理者とTeammateの事前設定が必要です。
テンプレートは Discover から探せます。Ready、Needs setup、Needs adminという状態を見て、利用できることと、接続や管理者設定が不足していることを分けます。自分の一覧が必要な例で、チーム向けの配送先を選ばないようにします。
独自に作るなら New で目的を入力し、生成された設定を読みます。公式ではRoutineはtrigger、prompt、destinationの三要素です。新規の既定は毎日9時と既定の配送先なので、別の曜日・時刻・届け先を意図する場合は確認して変更します。Lindy：Routines（新しいタブで開く）
曜日と時刻だけでなく、どのタイムゾーンの指定として扱われるかも利用画面で確認します。「朝に確認したい」という曖昧な希望を、そのまま自分が期待した時刻の設定済みと扱わないでください。
作業手順を保存するSkillと、実行時点を分ける
Routineを作ったのに結果のまとめ方が毎回違うなら、どのように一覧を作るかを整理します。Lindyの Skills は、繰り返し使う手順を名前と説明、指示として保存する機能です。Routineがいつ動くかを定めるのに対し、Skillはどう作業するかの手順として使えます。
公式は、Skillの名前と説明から関連性を判断し、必要なときに詳細指示を読み込むと説明しています。思った手順が使われない場合、まず説明が今回の依頼と対応しているかを見ます。利用できるSkillsの種類や管理権限は、自分の利用画面と組織の設定を確認してください。Lindy：Skills（新しいタブで開く）
今回なら「自分の送信メールから、資料送付の約束を確認用一覧へ整理するときに使う」と用途を具体化できます。「営業を助ける」のように広く書くより、対象の仕事が伝わる説明にします。説明を直したこと自体で、手順が必ず選ばれる保証にはなりません。
dry runで、読む対象と判断を確認する
公式は、Routineを有効にして任せる前に、チャットから dry run を依頼する方法を案内しています。実際のデータを読み、どのように判断したかを確認する一方、メール送信、投稿、共有シートへの書き込みなどの配送・更新は抑止する説明です。
このため、dry runを「データを一切読まない試験」とは扱いません。読ませるアカウントと期間は、事前に許可された範囲にします。実行費用や履歴の保存条件も、この説明だけから無料・記録なしとは判断しないでください。
依頼内容の例は次のとおりです。
この資料送付の約束を確認するRoutineを、有効にする前にdry runする。
指定した期間の自分の送信メールだけを対象にする。
見つけた約束、元メール、期限の記載、未確認点を確認したい。
相手への送信や外部ツールの更新は行わない。
これは読者が自分のRoutineへ与える依頼の例です。この記事で実メールを読んだり、dry runが行われた結果を示したりしているわけではありません。結果を受け取ったら、概要だけでなく、対象になったメールと下書きを読みます。
約束のある例と、ない例を分けて点検する
少数の確認でも、分かりやすい成功例だけに偏らないようにします。次は架空の点検表で、実際の合否ではありません。
表は横にスクロールできます
| メールの架空例 | 期待する整理 | 見落としたくないこと |
|---|---|---|
| 自分が「金曜までに資料を送ります」と送信 | 自分の約束と期限を記録 | 相手の依頼と取り違えない |
| 相手が「資料を送ってください」と送信 | 自分が約束した記述とは区別 | 今回の送信メール限定の対象外 |
| 自分が「送付できるか確認します」と送信 | 確認する約束として読む | 資料の送付確約へ変えない |
| 指定期間に該当する約束がない | 決めた空結果の扱いになる | 一覧を埋めるために内容を作らない |
元の記述へ戻り、誰が何を約束したかを確認します。「来週中」のような表現を扱う場合は、元メールの日時と、どの期間を指すかの確認も必要です。曖昧な期限を、AIが選んだ日付で確定しないようにします。
公式は、実行間で何かを記憶するRoutineならdry runを二度行い、二度目の振る舞いも確認するよう勧めています。前回見つけた項目を毎回新規扱いしないか、過去の記録で未完了項目を消していないかなど、運用上の期待を決めて比べます。これを外部への書き込み完了の検証とは混ぜません。
配送そのものはdry runの合格から切り離す
公式は、dry runでは抑止する配送処理そのものを証明できないと明記しています。正しい一覧が作れたことと、選んだ宛先へ通知が届くことは別です。
実際の配送を確認する必要があるなら、担当者が許可した自分宛ての場所や専用のコピーなど、影響を限定した対象で確認する計画を立てます。実顧客へ送って動作確認することを、最初の試験にはしません。今回のように相手への連絡を含めないRoutineなら、その境界が実行後も守られるかを確認します。
見直すときは、Routinesの一覧から有効・無効と対象を確認します。公式は、無効化して停止してもRoutine自体は削除しないと説明しています。どれを止めたか、残っている似たRoutineがないかも見てください。
次回へ渡せる記録を残す
確認メモは、Routine名、PersonalかWorkspaceか、対象アカウント、trigger、prompt、destination、点検した例、未確認項目でまとめます。Skillを使う場合は、その説明と手順の版も対応させます。
自動化の完成条件は、依頼文が保存できたことだけではありません。意図する対象を選び、確認できない事項を推測で埋めず、必要な届け先と停止方法を確認できることです。dry runで分かったことと、実際の配送で確認したことを分けて運用へ渡します。
確認した公式情報
資料確認日：2026年10月21日。現行Lindy Teammateの説明を対象とし、提供中の機能、接続・権限、費用、実行と停止の状態は利用画面で確認してください。