PaseoのBotsは、役割・モデル・記憶・定期作業を持つボットを作るプラグインだ。まずは「調査担当が根拠を集め、編集担当が原稿にする」という2役に分けると、何を任せるべきか判断しやすい。
便利そうだから全アプリを接続するより、入力資料と出力形式を固定することが先だ。この記事では、公開情報だけを扱うリサーチ担当を作り、動いた仕事を再利用するまでの設計例を示す。
Botsの前提と役割分担
| 項目 | 確認する内容 |
|---|---|
| 対応条件 | 公式掲載の要件はPaseo 0.9.2以降。導入時は現在の互換性を確認 |
| 実行モデル | 各ボットでプロバイダーとモデルを指定 |
| 記憶 | ボットのメモリーと日々のログ。誤りは履歴を確認して直す |
| 定期実行 | ルーチンを保存したhostで実行する |
| 外部アプリ | 必要な場合だけ別途接続。ボット作成自体にComposioは必須ではない |
Botsを入れて1人の担当者を作る
- Paseoで現在使っているhostと、プロバイダーが動くことを確認する。
- Settings → Pluginsで、導入するコードと配布元を確認してプラグイン機能を有効にする。プラグインはhost側の権限で動くため、会社環境では運用担当者の方針に合わせる。
- 公式掲載の識別子でBotsを追加する。下のコマンドか、Plugin sourceにoliexe/botsを指定する。
- ボットの作成画面で名前、役割、モデル、承認方法を決める。最初はメール送信や本番更新を含めない。
- 公開資料を1件渡し、指定した形式で結果を返せるか確認する。
- 合格した設定を保存し、同じ条件でもう1件試す。定期実行は、その後に追加する。
paseo plugin add oliexe/bots仕様・インストール識別子はBotsの公式掲載ページ、導入画面はPaseoのプラグイン導入説明を参照。以降は編集部独自の運用テンプレートだ。
そのまま調整して使える担当者の指示
名前：AIリリース調査担当
目的：指定された公式発表から、業務に影響する変更点を整理する。
入力：こちらが指定するURLと対象期間。
出力：製品名／公開日／利用可能な機能／利用条件／未確認事項／出典URL。
原則：発表済みと利用可能を区別する。予定機能は予定と明記する。
不明点：推測で補わず、未確認として残す。
行動範囲：調査と下書きのみ。アカウント接続、購入、送信、公開はしない。調査・記憶・定期化に使う6つの依頼
1. 最初の調査
この公式URLだけを読み、公開日、変更点、利用条件を表にする。URLに記載がない価格や対応地域は「未確認」とする。URL：[公式URL]2. 記憶候補の整理
今後の作業で繰り返し必要な方針だけを記憶候補として提案する。今回限りの数値、未検証の推測、個人情報は含めず、保存前に候補を見せる。3. 古い記憶の点検
保存されている方針と今回の依頼が矛盾していないか確認する。矛盾があれば両方を示し、独断で新しい恒久ルールを作らない。4. ルーチン案
毎週の調査のため、対象URL、実行時刻とタイムゾーン、出力先、失敗時の記録方法を提案する。まだルーチンを有効にしない。5. 引き継ぎ
調査結果を編集担当へ渡すため、事実一覧と推奨する記事切り口を分ける。編集担当が再確認できる出典を残す。6. 再利用
完了したこの作業を再利用する手順書にする。入力、成功条件、確認すべき箇所、失敗時の戻り方を含め、固有の顧客情報や認証情報は除く。定期実行を失敗させない確認表
| 確認点 | 具体的な試し方 |
|---|---|
| 保存先のhost | ボットが存在するPCとルーチンの実行先を照合する |
| 手動実行 | 同じ入力で一度実行し、結果とエラーの置き場を見る |
| 前回処理の残り | 時間内に終わらない仕事を次回と重ねない設計にする |
| 出力の重複 | 日付と対象URLを記録し、既存結果へ追記するか新規作成するか決める |
| 更新の有無 | 変更がないときは「変更なし」を残し、存在しないニュースを作らせない |
Botsのスケジュール実行・手動実行は、同じルーチンの前回処理中にはスキップされる一方、Webhookは並行実行を許す。受信の重複を想定する場合は、処理した対象を記録して二重作成を避ける。
Instructions・Memory・Skills・MCPの使い分け
| 置き場所 | 入れるもの | 例 |
|---|---|---|
| Instructions | 常に守る判断基準 | 予定と提供済みを区別する |
| Memory | 継続して使う確定情報 | 読者層、採用した表記 |
| Skills | 繰り返す作業の手順 | 記事公開前の出典チェック |
| MCP | 外部機能への接続 | 必要な資料の検索 |
チーム化する場合も、誰が最終原稿を書き、誰が確認するかを固定する。2人に同時に同じ原稿を上書きさせるより、調査結果とレビュー結果を別の成果物にすると差分を確認しやすい。
秘書役と専門担当を分けるチーム設計
Botsのチーム機能はChief of Staffが依頼を受け、他の担当へ渡す構成を持つ。最初は受付・調査・確認の3役までに絞り、仕事が戻ってくる条件を決める。PM HubのVice等と名称や内部実装が同じという意味ではない。
| 役割 | 入力 | 成果物 | 終える条件 |
|---|---|---|---|
| 受付 | 目的と期限 | task_id付き依頼票 | 不足情報を明示した |
| 調査 | 限定した資料 | 出典付き候補表 | 不明を推測で埋めていない |
| 確認 | 候補表と原文 | 修正番号と採否 | 根拠と出力を照合した |
Act as the coordinator for one task. Assign research and review to separate roles with distinct output files. Keep one task_id throughout. Return the final artifact, evidence, and unresolved questions. Do not expand tools, permissions, or schedules automatically.公式プラグイン案内では、定期・手動実行は前の同じルーチンが動いている間はスキップされ、Webhookのルーチンは複数実行を許す。入口によって重複の扱いが違うため、台帳のtask_idと結果の保存先でも確認する。ルーチンはBotを保存したホストで動く。
担当ごとに使える接続先と編集範囲を絞り、メモリへ残す内容も「採用した判断」と「一時的な作業」を分ける。公式プラグイン案内、PM Hub型の仕事設計、定期実行方式の選び方を参照できる。2026年10月31日追記。チームの稼働・並行処理の性能試験は行っていない。
よくある質問
無料のボットを無制限に動かせる？
プラグイン本体とAIプロバイダーの利用枠は別だ。モデルの契約や従量課金を確認する。
Composioは必須？
ボットの基本利用には必須ではない。外部アプリを接続する場合に検討する。
記憶は常に正しい？
誤認識や古い情報を含むことがある。長く使う方針だけを残し、更新理由を確認する。
チームを最初から大人数にするべき？
2役から始め、待ち時間や重複が改善するかを見て増やす。
PCを消しても定期作業は動く？
ルーチンを実行するhostが稼働している必要がある。常時稼働の設計と費用は別に考える。
小さく始めて運用に移す
- 今日：外部接続なしで、役割を1つ作る。
- 今週：手動実行を数件通し、入力と成功条件を固定する。
- 来月：効果のあった作業だけを定期化し、担当者が結果を点検する。
関連する使い方
Claude CodeのMCP設定 ／ ObsidianとAIの記憶
LIFRELLへの相談
調査・記事制作・社内資料整理の役割分担と、AI担当者の権限・レビュー手順を設計する。
公式資料と確認日
企画の参考：monograph「【続】僕達のAIの使い方、全部見せます。」。本記事の設定例・プロンプト・確認表はLIF Tech編集部が独自に構成した。出演者の実践結果を本記事の検証結果として扱っていない。
公式情報の確認日：2026年10月31日。実機での導入・生成・性能測定は本記事では未実施。手順は公式資料に基づき、作例は実施用の設計例として掲載している。画面、料金、利用条件は変更される場合がある。
