> Markdown twin of https://conduitllm.com/ja/automate-with-workflows.html > プロジェクトのリリースを見守り、低コストのモデルで要約・保存し、破壊的変更のときだけ通知する Conduit のワークフローを作ります。 --- チュートリアル # Conduit のワークフローでタスクを自動化する方法 2026年10月15日更新 毎日やる価値はあっても、手作業で続けるほどではない作業があります。変更履歴を読む、ページの変化を確認する、フォルダに届いたものを要約する、といった作業です。無料のオープンソース デスクトップ AI アプリ [Conduit](https://conduitllm.com/ja/) のワークフローは、こうした定型作業を、スケジュールに沿って、または新しいものが現れたときに代わりに実行し、確認する価値があるときだけ知らせてくれます。 ## はじめに ワークフローは、順番に実行される手順のリストです。ページやファイルを取得して読み込む手順、モデルに処理を依頼する手順、結果を保存したり通知したりする手順があります。各手順は、それより前の手順が生成したものを利用できます。リスト全体は、手動で、スケジュールで、またはフィードやフォルダに新しいものが追加されるたびに実行できます。 このチュートリアルでは、使っているツールのリリースを見守るワークフローを作ります。例には、Python のパッケージマネージャーである [uv](https://github.com/astral-sh/uv) を使います。リリースの頻度が高く、リリースノートが詳しいためです。新しいリリースごとに、ワークフローはリリースノートを読み、低コストのモデルに短い要約を依頼して、その要約を保存し、リリースに破壊的変更があるときだけデスクトップ通知を送ります。安全にテストし、各手順が何を行ったかを読み、全体をやり直さずに手順を修正し、最後に承認して無人で動かすところまで進めます。 GitHub 上のどのプロジェクトでも同じように進められます。変わるのはフィードのアドレスだけです。 ## 要点 - ワークフローは、手動、スケジュール（毎日、平日、数時間ごと）、RSS や Atom フィードに新しい投稿が現れたとき、フォルダに新しいファイルが追加されたときのいずれかで開始できます。 - 手順どうしは、メニューから挿入する値を通して結果を受け渡します。たとえば、投稿のリンクや、前の手順が生成したテキストです。 - モデルを使う手順は、それぞれ別のモデルを選べるので、定型作業は高速で安価なモデルに任せられます。 - **…の場合のみ続ける**手順は、注目に値するものがないとき、実行を静かに終了させます。 - ワークフローを自動で実行させる前に、許可される操作がすべて一覧で表示され、あなたがそれを承認します。それを超える操作が必要になると、実行は一時停止して確認を求めます。 - すべての実行で各手順の動作が記録され、任意の手順から、その前の手順を繰り返さずに再実行できます。 - 同じワークフローをキャンバスとして表示でき、条件で分岐したりステップを並行して実行したりでき、行動する前に確認するエージェントに作業を任せることもできます。 ## 前提条件 このチュートリアルを進めるには、次のものが必要です。 - **Conduit のインストール**（Windows、macOS、Linux）。[リリースページ](https://github.com/runningpixels/conduit/releases)から最新版をダウンロードしてください。 - **Conduit に設定済みのモデルプロバイダー**と、あなた自身の API キー。このチュートリアルでは、要約に OpenRouter 経由の GLM 5.3 Flash を使いますが、ローカルモデルを含め、どのプロバイダーでも構いません。設定するには、[プロバイダーガイド（英語）](https://conduitllm.com/providers.html)のいずれか、たとえば [デスクトップアプリで OpenRouter を使う（英語）](https://conduitllm.com/providers/openrouter.html)に従ってください。 - **Conduit のデスクトップ通知の許可。**ワークフローが送る通知を表示できるよう、お使いの OS の設定で許可しておいてください。 - **（任意）関心のあるフィードのアドレス。**GitHub のリポジトリはどれも、リリースを Atom フィードとして `https://github.com///releases.atom` で公開しています。 ## ステップ 1 — 用意されたワークフローから始める Conduit には、そのままでも、変更しても使える既製のワークフローが付属しています。このステップでは、すでにフィードを見守る設定になっているものを作成し、リリースの監視用ワークフローのベースにします。 サイドレールで**ワークフロー**を選ぶか、Ctrl+6（macOS では ⌘6）を押します。ワークフローがまだない場合は、**まだワークフローがありません**の下に既製のワークフローが並びます。すでにある場合は、**新しいワークフロー**を選ぶと表示されます。 一覧には、次のものが含まれます。 - **朝のブリーフィング** — 2 つのサイトを読み、それぞれの主要な記事を 1 つのブリーフィングにまとめて保存します。 - **ページを見守る** — ページを確認し、変更があったときだけ知らせます。 - **トピックの監視**と**週次リサーチダイジェスト** — トピックを検索またはリサーチして、ダイジェストを最新の状態に保ちます。 - **週次の数字のプレゼン**と**月次レポートのセクション** — 選んだスライドのプレゼンやライティングの下書きを更新します。 - **新しい投稿を要約**と**受信フォルダ** — フィードの新しい投稿ごと、またはフォルダの新しいファイルごとに 1 回ずつ実行されます。 - **メモをドキュメントと照合** — メモのファイルを、ドキュメントコレクションの一節と突き合わせます。 - **ゼロから始める** — 手順を 1 つずつ組み立てていく、空のワークフローです。 **新しい投稿を要約**を見つけて、**このテンプレートを使う**を選びます。Conduit がワークフローを作成し、そのページを開きます。 新しいワークフローには、すでに 4 つの手順があります。投稿を取得し、モデルに要約を依頼し、要約を保存して、通知を表示します。まだ何も実行されません。フィードを見守るワークフローは、**自動的に実行**をオンにして初めて監視を始めます。それはステップ 9 で行います。次に、これを uv のリリースに向けます。 ## ステップ 2 — ワークフローをリリースフィードに向ける ワークフローを何で開始するかは、**開始のきっかけ**セクションで設定します。このステップでは、このワークフローが見守るフィードを、Rust ブログから uv のリリースに変更します。 ワークフローのページで**編集**を選びます。ヘッダーにはワークフローの名前と、**JSON として編集**、**キャンセル**、**保存**が表示されます。左側に手順が並び、右側のサイドパネルには**開始**（**開始のきっかけ**の選択肢を含む）、**実行ごとの入力**、**ヘルパー**、**ワークフローの設定**があり、名前、説明、モデルプロバイダー、フォルダはここで設定します。 **注：**ワークフローは、キャンバスとして表示することもできます。手順の上にある**キャンバス** / **リスト**の切り替えで表示方法を選べ、選んだ表示は Conduit が覚えています。このチュートリアルはリストで進めるので、ここで説明するステップのカードを見るには**リスト**を選んでください。 次の変更を行います。 1. **ワークフローの設定**で、**名前**を `uv releases` に変更します。 2. **開始のきっかけ**で、**フィードに新しい投稿が追加されたとき**を選んだままにして、**フィードのアドレス**に `https://github.com/astral-sh/uv/releases.atom` を設定します。 3. **確認の間隔**を **360 分**に設定します。リリースの監視に、30 分ごとの確認は必要ありません。1 日に 4 回確認すれば十分です。 **開始のきっかけ**のほかの選択肢は、手動または決まった時刻に実行するワークフロー向けの**自分で実行したときのみ、またはスケジュールで**、**ワークフローのフォルダに新しいファイルが追加されたとき**、そして**コネクタから新しいものが届いたとき**です。ファイルの場合は、先に**ワークフローの設定**でフォルダを選んでおく必要があります。 **注：**ワークフローが初めてフィードを確認するときは、すでにあるリリースを記録するだけです。古いリリースの山を要約することはなく、オンにしたあとに公開されたリリースだけを、古いものから順に要約します。複数のリリースが同時に届いた場合は、1 回の確認で開始される実行は最大 5 回までで、残りは次の確認まで待ちます。 これでワークフローは正しいフィードを見守るようになりました。次に、最初の手順が、実行のきっかけになった投稿をどう使うかを見ていきます。 ## ステップ 3 — リリースノートを取得する フィードのワークフローの各実行は 1 つの投稿に対するもので、その投稿の情報は、すべての手順で値として利用できます。このステップでは、最初の手順がそのうちの 1 つを使ってリリースノートを取得するしくみを見ます。 **手順**までスクロールします。各手順は、番号と種類が付いたカードで表示され（たとえば **1. ページを取得**）、その横に短い ID（ここでは `fetch`）が付いています。あとの手順は、この ID でこの手順を参照します。 取得の手順の**ページ1**欄には、投稿のリンクを表すチップが入っています。こうした値は、各欄の横にある**値を挿入…**メニューから挿入します。メニューには、ワークフローのその時点で使える値が並びます。 - **トリガーから** — 投稿のタイトル、リンク、要約、日付、ID。 - **これまでの手順** — 上の手順が生成したもの。たとえば *fetch · 最初のページの本文* です。 - **実行ごとの入力** — ワークフローを実行するときに入力する値（追加した場合）。 取得の手順はそのままにしておきます。uv の場合、各投稿のリンクはそのリリースの GitHub ページなので、この手順でリリースノートが取得されます。取得の手順が読むのは最大 10 ページ、各ページ最大 50,000 文字までで、取得できるのは公開されている https のアドレスだけです。 カードにある**失敗時の再試行**の設定にも注目してください。取得の手順は、標準で 2 回再試行されるので、短時間のネットワークの不調は乗り切れます。どの手順にも**この手順が失敗しても続行**があります。ここではオフのままにします。リリースノートがなければ、要約するものがないからです。 これでワークフローは、新しいリリースを読めるようになりました。次に、それをどうするかをモデルに伝えます。 ## ステップ 4 — 要約の手順を書き、モデルを選ぶ **モデルに依頼**の手順は、1 つの指示とテキストをモデルに送り、その答えを保持します。このステップでは、リリースノートに合った指示を書き、この手順だけ安価なモデルを選びます。 ID が `summary` の手順 2、**モデルに依頼**を見つけます。その**指示**を、次の内容に置き換えます。 ``` Summarize these release notes for a developer who uses this tool every day. List new features and fixes in at most five bullet points. Then add a section titled "Breaking changes" that lists anything that could break an existing project, such as removed options, changed defaults or new minimum versions. If there are none, write exactly: No breaking changes. ``` **処理するテキスト**欄には、すでに投稿のタイトルに続けて取得したテキストが入っているので、モデルはどのリリースを読んでいるかを把握できます。そのままにしておきます。 指示の最後の行は重要です。ステップ 6 では、まさにこの一文を使って通知するかどうかを判断します。そのため、モデルには毎回同じ書き方でこの一文を書くよう求めています。 次に、モデルを選びます。**このステップのモデル**の標準は**ワークフローのモデルを使う**で、エディター上部のワークフロー自体の**モデル**設定は、標準では**チャットのモデルに合わせる**（直近にチャットで選んだモデル）になっています。定型の要約には、代わりに高速で低コストのモデルを選びます。このチュートリアルでは、OpenRouter 経由の **GLM 5.3 Flash** を使います。 **注：**手順ごとにモデルを選べるので、1 つのワークフローで複数のモデルを使い分けられます。大量の要約には安価なモデル、最後の文章にはより強力なモデル、プライベートなファイルを扱う手順にはローカルモデル、といった具合です。手順で指定したプロバイダーが設定されていない場合、その手順は失敗せずにチャットのモデルを使い、実行にその変更が記録されます。 これでワークフローは、最後のセクションが決まった形の要約を生成します。次に、すべての要約が保存されるようにします。 ## ステップ 5 — すべての要約を保存する **ドキュメントを保存**の手順は、テキストを、あとで開けるドキュメントとして保存します。このステップでは、リリースごとに 1 つのドキュメントを残すように設定します。 手順 3、**ドキュメントを保存**を見つけて、次のように設定します。 - **タイトル** — `uv ` に続けて*投稿のタイトル*のチップを置き、各ドキュメントにそのリリースの名前が付くようにします。 - **内容** — 要約のチップと、投稿のリンクを添えた `Source:` の行はそのままにします。 - **保存形式** — **ドキュメント**。 - **実行ごと** — **新しいドキュメントを追加します**。 **実行ごと**のもう一方の選択肢、**同じドキュメントを置き換えます**は、最新の結果だけを 1 つのドキュメントに残すもので、ページの監視や毎日のブリーフィングに向いています。リリースの履歴を残したいので、ここではリリースごとに 1 つのドキュメントが必要です。 保存を、次に追加する確認の前に置くのは意図的です。今日は注目する必要のないリリースも含め、すべてのリリースが記録されます。 次に、通知するかどうかを判断する手順を追加します。 ## ステップ 6 — 破壊的変更のときだけ通知する **…の場合のみ続ける**手順は、ある値を確認し、確認に通らなければ実行を静かに終了させます。このステップでは、保存と通知の間にこの手順を追加し、破壊的変更のあるリリースだけが通知されるようにします。 **手順**の末尾で**手順を追加…**を開き、**…の場合のみ続ける**を選びます。新しい手順は最後に追加されるので、↑ ボタンで**通知を表示**の上に移動します。そのうえで、次のように設定します。 - **確認する値** — **これまでの手順**から *summary · テキスト*を挿入します。 - **続ける条件** — **を含まない**。 - **テキスト** — `No breaking changes`。 比較では、大文字と小文字や余分な空白は無視されます。ほかの条件は、**前回の実行から変わった**、**空ではない**、**空である**、**を含む**、**と等しい**です。最初の条件は、スターターの**ページを見守る**が、ページが変わったときだけ知らせるために使っています。 最後に、手順 5、**通知を表示**を更新します。**タイトル**を `Breaking changes in uv` に、**メッセージ**を*投稿のタイトル*のチップに設定します。 モデルがこの一文を正確に書き忘れた場合は、確認を通過して通知が送られます。したがって、最悪でも不要な通知が 1 件増えるだけで、破壊的変更を見逃すことはありません。 **保存**を選びます。まだ存在しない値を読み取る手順があるなど、つじつまの合わない点があると、エディターは**保存する前に次を修正してください：**の下にそれを一覧表示し、修正するまで**保存**を無効のままにします。保存すると、ワークフローのページに、5 つの手順が平易な言葉で表示されます。 これでワークフローは完成です。自動で動かす前に、テストします。 ## ステップ 7 — 今すぐ実行でワークフローをテストする テスト実行では、実際のデータを使って、ワークフローが何を行うかを正確に確認できます。このステップでは、手動で 1 回実行します。 ワークフローのページで**今すぐ実行**を選びます。フィードを見守るワークフローを手動で実行すると、フィードの最新の投稿がテストに使われるので、次のリリースを待つ必要はありません。ボタンは**実行中…**に変わり、**停止**ボタンが表示され、実行は**最近の実行**の下に、**テスト実行:**に続けてリリース名が付いた形で表示されます。 実行時間のほとんどは、モデルの手順が占めます。GLM 5.3 Flash では、ここで示すテスト実行は 1 分未満で終わりました。完了すると、リリースに破壊的変更があって通知が届いた場合のステータスは**完了**、要約を保存したあとに確認の手順が実行を終了させた場合は**新しい情報なし**と表示されます。どちらの場合も、**保存済み：**から、保存された要約を開けます。 **注：**手動で開始した実行は、あなたがその場で見ているので、承認によって止められることはありません。ステップ 9 で設定する承認は、誰も見ていない実行のためのものです。 判断の分かれるリリースについては、モデルの判断が実行のたびに変わることがあります。uv 0.12.24 は主にバグ修正でしたが、その一部は、ハッシュの確認がオフでも渡されたハッシュを検証するなど、uv をより厳格にするものでした。このリリースで 2 回テスト実行したところ、GLM 5.3 Flash は、1 回はそうした修正を破壊的変更として挙げ、もう 1 回は *No breaking changes.* と書きました。こうした変更も知らせてほしい場合は、指示にそう書いておきます。たとえば、*uv をより厳格にするバグ修正も破壊的変更として数えてください。*のようにします。 このような手順には、直接答えるモデルを選んでください。答える前に長く推論するモデルは、長いページでは何分もかかることがあり、実行は 30 分の上限に達した時点で停止します。 次に、実行を開いて、各手順が何を行ったかを確認します。 ## ステップ 8 — 実行を読み、手順を再実行する すべての実行には、各手順の記録が残ります。何が入力され、何が出力され、どのモデルを使い、どれだけ時間がかかったかです。このステップでは、その記録を読み、要約を変更して、必要な手順だけを再実行します。 **最近の実行**の下のテスト実行を選びます。**この実行が行ったこと**セクションに手順が並び、それぞれにステータス（**完了**、**失敗**、**スキップ済み**、**再利用済み**）が付いています。確認の手順が実行を終了させた場合は、**新しい情報なし — **に続けてその手順の ID（ここでは `check`）が表示され、「新しい情報なし — check で停止」となります。 `summary` の手順を展開します。「…を使用しました」で始まる行に、使われたモデルとプロバイダーが表示され、その下にその手順の**入力**と**出力**があります。**保存済み：**の下でドキュメントの名前を選ぶと、要約そのものを開けます。 要約が思ったより長いとします。**編集**を選び、`at most five bullet points` を `at most three bullet points` に変更して保存します。そのうえでテスト実行をもう一度開き、`summary` の手順を見つけて**この手順から再実行**を選びます。 新しい実行では、取得の手順が**再利用済み**と表示されます。リリースノートは再取得せずに前回の実行から取り込まれ、要約、保存、確認、通知が、新しい指示で実行されます。下に示す実行では、ページを再取得しなかったため、全体の実行が 16 秒だったのに対し、再実行は 10 秒でした。もっと長いワークフローなら、時間とモデル呼び出しの両方を節約できます。 実行が失敗した場合も、同じ画面で、どの手順がなぜ失敗したかが平易な言葉で表示されます。その手順を修正して、そこから再実行してください。 ワークフローは、思いどおりに動くようになりました。次に、自動で実行させます。 ## ステップ 9 — 自動実行をオンにする 自動で実行されるワークフローは、先に承認が必要です。このステップでは、リリースの監視用ワークフローに許可される操作を確認して、オンにします。 ワークフローのページで、説明の下にある**開始**チップを選びます（キャンバス表示では、代わりに開始の手順を選びます）。開始パネルが開き、**スケジュール**セクションがあるので、**自動的に実行**にチェックを入れます（パネルの**← 戻る**でワークフローに戻れます）。Conduit は**自動で実行させますか？**というパネルを表示し、確認なしでワークフローに許可される操作をすべて一覧にします。リリースの監視用ワークフローの場合、一覧は次のとおりです。 - **github.com のページを読む** — フィードを読むため。 - **手順「fetch」が実行時に取得するアドレスのページを読む** — 取得の手順のアドレスはフィードから決まるため、Conduit はあらかじめサイトを特定できません。 - **オンラインで OpenRouter にテキストを送る** — 要約の手順のため。 - **ドキュメントを保存する**。 通知と確認の手順には承認は不要です。**許可してオンにする**を選びます。セクションに**github.com を 360 分ごとに監視中**と表示され、**自動で実行するとき、次のことが許可されます：**で始まる行に、承認した一覧が表示され続けます。 あとでワークフローを編集して、新しいサイトや別のプロバイダーなど、さらに何かが必要になった場合は、ページに**追加の確認が必要です**と**承認**ボタンが表示されます。承認するまで、その手順に達した自動実行は停止して確認を求めます。通知が届き、実行は**要対応**と表示され、ホームの**要対応**に一覧表示されます。**今回のみ許可**、**常に許可**、**許可しない**のいずれかを選べます。1 日たっても誰も答えなければ、その手順は進みません。 自動実行を初めてオンにすると、Conduit は**通知領域で実行し続ける**ことも提案します。自動実行は Conduit が実行されている間にしか行われないので、ウィンドウをよく閉じる場合は受け入れてください。この設定は、同じセクションであとから変更でき、**サインイン時に Conduit を通知領域で起動**も選べます。 **注：**フィードの変化ではなく、決まった時刻にワークフローを実行したい場合は、**開始のきっかけ**で**自分で実行したときのみ、またはスケジュールで**を選びます。すると**自動的に実行**で、指定した時刻の**毎日**または**平日**、あるいは**数時間ごと**（1、2、3、4、6、8、12、24 時間ごと）を選べます。 これでリリースの監視用ワークフローは、自動で動いています。最後のステップでは、次のワークフローを素早く始める方法を紹介します。 ## ステップ 10 — ワークフローを組み立てずに説明する すべてのワークフローを手順ごとに組み立てる必要はありません。このステップでは、1 文から Conduit にワークフローを下書きさせます。 ワークフローのページで**新しいワークフロー**を選びます。**ワークフローを説明する**に、次のように入力します。 平日の 9:00 に、Hacker News のトップページと Lobsters のトップページを読み、Rust または Python に関する記事を 1 つのリストにまとめて保存してください。 **下書きを作成**を選びます。チャットのモデルがワークフローを書き、Conduit は、保存するワークフローと同じ方法でそれを検査し、問題があればモデルに返して修正させます。下書きは*未保存*の状態でエディターに開きます。あなたが**保存**を選び、自分でオンにするまで、何も保存もスケジュールもされません。 モデルは、フォルダ、プレゼン、ドキュメントコレクションのように、あなたにしか選べないものは選びません。スケジュールもオンにしません。下書きにこうしたものが必要な場合、エディターには**保存する前に入力するもの**という短い一覧が表示されます。上の説明の場合、一覧には*スケジュールをオンにする：平日の 9:00。*と表示されます。これは、保存したあとにワークフローのページでスケジュールを設定するためのリマインダーです。 言葉からワークフローを始める方法は、ほかに 2 つあります。 - **ホームから。**質問ボックスにやりたいことを入力して**自動化**のチップを選ぶと、Conduit がワークフローを開いて下書きを作成します。 - **チャットから。**チャットで何かを手作業で行ったあと、Ctrl+K（macOS では ⌘K）でコマンドパレットを開き、**チャットをワークフローとして保存…**を選びます。下書きは、あなたが依頼した内容と使われたツールをもとに作られます。モデルがページやドキュメントそのものを見ることはありません。 どちらの方法でも、下書きを確認し、**今すぐ実行**でテストしてから、**自動的に実行**をオンにしてください。 ## さらに進める：キャンバス、分岐、エージェント リリースの監視用ワークフローは一直線ですが、ワークフローがそうである必要はありません。ここまでの内容を土台に、4 つのことができます。 - **キャンバス。**手順の表示で**キャンバス**に切り替えると、開始、各ステップ、ループ、それらをつなぐ線が見えます。実行中は各ステップに、実行中、完了、失敗、スキップ、あなたの操作待ちのいずれかが表示され、ステップを選ぶとその入力と出力を確認できます。エディターでは、パレットからステップを追加し、ドラッグして並べ替え、あるステップから別のステップへ線をドラッグして、どの出力をどの欄に渡すかを、入力せずに選べます。 - **分岐とステップの並行実行。****もし…でなければ**のステップは、実行を「はい」または「いいえ」の道に振り分け、通らなかった道は*通らなかった*と記録されます。ステップは複数の先行するステップを待てるので、互いに依存しないステップは最大 4 つまで同時に実行され、後続のステップがそれらを合流させることもできます。たとえば、リリースの監視用ワークフローの**…の場合のみ続ける**ステップを分岐に置き換えれば、一方の道では通知し、もう一方の道では保存するだけにできます。 - **結果。**完了した実行が保存したものは、プレビュー付きで残ります。ワークフローの**結果**タブか、すべてのワークフローの結果が並ぶワークフローのサイドバーの結果一覧を開き、**開く**で読めます。 - **エージェント。****モデルにツールを使わせる**ステップは、最大 10 個のコネクタのツールを使え、あなたが定義したヘルパーに、それぞれ独自の指示、モデル、トークン上限を持たせて作業を任せられます。送信、投稿、編集を行うコネクタのツールは実行を一時停止して確認し、**受信箱**にはワークフローが対応を待っているものがすべて集まります。**設定 → コンピューター**をオンにすると、エージェントは、あなたが指定したフォルダー内でコマンドの実行やファイルの変更もでき、許可したルールに当てはまらない限り、コマンドは毎回先に確認します。制限は[ワークフローのドキュメント](https://conduitllm.com/ja/docs.html#workflows)にまとめています。 ## すべての手順の種類を一覧で見る リリースの監視用ワークフローで使った手順は 5 種類です。**手順を追加…**メニューに表示される、すべての種類を次にまとめます。 | 手順 | できること | | --- | --- | | ページを取得 | PDF を含む最大 10 件の Web ページを読み込みます。1 ページあたり最大 50,000 文字です。 | | Web で検索 | 設定で選んだ検索バックエンドで検索し、最大 20 件の結果を返します。 | | ファイルを読み込む | ワークフローのフォルダにある、テキスト、Markdown、CSV、JSON、PDF、Word のファイルを読み込みます。ほかの場所のファイルは読み込めません。 | | テキストを表に変換 | CSV、TSV、JSON を、後続の手順で使える行と列に変換します。 | | トピックを調べる | クイックまたは標準のリサーチを実行し、出典付きのレポートを作成します。 | | ドキュメントを検索 | 選んだドキュメントコレクションから、クエリにもっともよく一致する一節を見つけます。 | | コネクタを使う | コネクタ（MCP サーバー）のツールを呼び出します。読み取るだけのツールはそのまま実行され、送信、投稿、編集を行うツールは実行を一時停止して確認します。 | | モデルに依頼 | 指示とテキストをモデルに送り、ツールは使わずに、その答えを保持します。 | | モデルにツールを使わせる | 答える前に、モデルが Web 検索、ページの読み取り、時刻の確認、計算、コネクタのツールの利用、ヘルパーへの作業の依頼を数回行えるようにします。オンにすれば、ワークフローのフォルダー内でコマンドの実行やファイルの変更もできます。 | | プレゼンを更新する | 選んだスライドのプレゼンを、指示どおりに変更します。ピン留めしたテキストは変更されず、変更は元に戻せます。 | | 下書きを更新する | 選んだライティングの下書きを、同じ方法で変更します。 | | テキストを作成 | これまでの手順の値を、モデルを使わずに 1 つのテキストにまとめます。 | | 各項目を繰り返す | 内側の手順を、リストの項目（最大 50 件）ごとに 1 回ずつ実行します。 | | ドキュメントを保存 | ドキュメントや Web ページを Conduit に保存します。実行のたびに新規に保存することも、同じものを置き換えることもできます。 | | ファイルを保存 | Markdown、テキスト、CSV、JSON、HTML のファイルを Conduit のエクスポートフォルダに書き出します。 | | 記憶を提案 | 記憶に残す内容を提案します。あなたが受け入れるまで、何も記憶されません。 | | 質問する | 実行を一時停止して、選択肢または入力による回答を求めます。誰も答えなかった場合のための既定値も指定できます。 | | 通知を表示 | デスクトップ通知を表示します。前回の実行と内容が異なる場合だけ表示するようにもできます。 | | …の場合のみ続ける | 値が確認に通らない場合、実行を静かに終了させ、*新しい情報なし*として扱います。 | | もし…でなければ | 同じ確認で、実行を「はい」または「いいえ」の道に振り分けます。もう一方の道のステップは*通らなかった*と記録されます。 | 1 つのワークフローには、最大 50 個の手順を入れられます。どの手順のどのテキスト欄にも、挿入した値を含められます。また、エディターの**JSON として編集**で、定義全体を手作業で編集できます。そのビューでは、挿入した値は `{{steps.summary.text}}` や `{{trigger.link}}` のように書かれます。波括弧そのものを書くには、その前にバックスラッシュを置きます： `\{{`。 参考として、ここまでに作ったリリースの監視用ワークフローを、JSON ビューで表示した状態を次に示します。 ``` { "steps": [ { "id": "fetch", "type": "fetch_page", "urls": [ "{{trigger.link}}" ] }, { "id": "summary", "input": "{{trigger.title}}\n\n{{steps.fetch.text}}", "model": { "model": "z-ai/glm-5.3-flash", "provider": "openrouter" }, "prompt": "Summarize these release notes for a developer who uses this tool every day.\n…", "type": "summarize" }, { "content": "{{steps.summary.text}}\n\nSource: {{trigger.link}}", "id": "save", "mode": "create", "title": "uv {{trigger.title}}", "type": "save_artifact" }, { "id": "check", "is": "not_contains", "text": "No breaking changes", "type": "condition", "value": "{{steps.summary.text}}" }, { "body": "{{trigger.title}}", "id": "notify", "title": "Breaking changes in uv", "type": "notify" } ], "trigger": { "everyMinutes": 360, "kind": "feed", "url": "https://github.com/astral-sh/uv/releases.atom" } } ``` ## よくある質問 **Conduit を閉じていてもワークフローは実行されますか？** いいえ。スケジュールされた実行や自動実行は、Conduit が実行されている間に行われます。ウィンドウを閉じたあとも実行し続けたい場合は、ワークフローの**スケジュール**セクションで**ウィンドウを閉じても通知領域で実行し続ける**をオンにしてください。必要に応じて、**サインイン時に Conduit を通知領域で起動**もオンにできます。Conduit が閉じている間に見逃されたスケジュール実行は、見逃した回数にかかわらず、次回の起動時に一度だけ実行されます。 **ワークフローの実行には費用がかかりますか？** Conduit は無料です。ページの取得、ファイルの読み込み、条件の確認、ドキュメントの保存、通知の表示といった手順は、モデルを呼び出さないため費用はかかりません。モデルに依頼する手順は、通常のチャットメッセージと同じように、あなた自身のキーであなたのプロバイダーから課金されます。1 回の実行には、実行時間 30 分とモデルのトークン 500,000 という上限があり、超えるとメッセージを表示して停止します。ワークフローが行ったモデル呼び出しは、すべて**設定 → 使用量と費用**に記録されます。 **ワークフローで、ほかのアプリの内容を変更できますか？** はい、あなたの承認があれば可能です。**コネクタを使う**手順は、課題の一覧表示やカレンダーの読み取りのような、読み取るだけのツールをそのまま実行します。送信、投稿、編集を行うツールは実行を一時停止して実際の呼び出し内容を表示し、**送信**、**編集**、**送信しない**から選べます。その操作は、そのワークフローで今後許可することもできます。Conduit の中では、ワークフローはドキュメントやファイルを保存したり、あなたが受け入れるための記憶を提案したり、選んだスライドのプレゼンやライティングの下書きを更新したりできます。更新でピン留めしたテキストが変わることはなく、実行画面の**この更新を元に戻す**でプレゼンや下書きを元の状態に戻せます。 **Web ページがワークフローを乗っ取ることはありますか？** いいえ。取得したページは、後続の手順が処理するテキストにすぎず、手順を追加したり、承認を変更したりすることはできません。**モデルに依頼**の手順にはツールがまったくないため、ページに指示が書かれていても、取得、検索、保存をさせることはできません。**モデルにツールを使わせる**手順は、Web から読み取った内容を指示ではなくデータとして扱い、使えるのはあなたがチェックを入れた読み取り専用のツールだけです。誰も見ていない実行にできるのは、自動実行をオンにしたときにあなたが承認したことだけです。 **ワークフローをほかの人と共有できますか？** インポートやエクスポートのボタンは、まだありません。ワークフローは手作業でコピーできます。**編集**を選び、**JSON として編集**を開いて、定義をコピーします。相手は**ゼロから始める**でワークフローを作成し、**JSON として編集**を開いて貼り付けます。承認は定義に含まれないため、相手がワークフローを自動で実行させる前には、あらためて承認が必要です。 **ローカルモデルを使えますか？** はい。ワークフローのモデルとして、または**このステップのモデル**で、Ollama か LM Studio のモデルを選べます。ローカル専用モードでは、クラウドのプロバイダーを指定した手順は、テキストをオンラインに送らず、その旨のメッセージを表示して失敗します。 ## まとめ このチュートリアルでは、uv のリリースを見守るワークフローを作りました。新しいリリースごとにノートを取得し、低コストのモデルで要約し、すべての要約を保存して、破壊的変更があるときだけ通知します。実際のリリースでテストし、各手順が何を行ったかを読み、変更した手順から再実行し、自動で実行してよい操作を正確に承認しました。 何かを取得し、モデルに尋ね、結果を残し、重要なときだけ知らせるというこのパターンは、多くの定型作業に当てはまります。プロジェクトが依存するすべてのツールのリリースに向けてコピーを作ってみたり、料金ページやステータスページに**ページを見守る**を使ったり、**受信フォルダ**にフォルダへ入れたファイルを 1 つずつ要約させたりしてみてください。さらに進むには、次のガイドをご覧ください。 - [ワークフローのドキュメント](https://conduitllm.com/ja/docs.html#workflows)：すべての設定と制限を解説しています。 - [Conduit と Exa でディープリサーチを行う方法](https://conduitllm.com/ja/research-with-exa.html)：ワークフローの**トピックを調べる**手順が使うリサーチの実行について学べます。 - [プロバイダーガイド（英語）](https://conduitllm.com/providers.html)：ワークフローで使うモデルを選び、設定します。 [Conduit をダウンロード](https://github.com/runningpixels/conduit/releases) Conduit に関する記述は最新リリースに対応しており、 [ドキュメント](https://conduitllm.com/ja/docs.html)と [ソースコード](https://github.com/runningpixels/conduit)で確認できます。 誤りを見つけた場合は、[お知らせください](https://github.com/runningpixels/conduit/discussions)。修正します。 ## 関連記事 - [Conduit と Exa でディープリサーチを行う方法](https://conduitllm.com/ja/research-with-exa.html) — Conduit で Exa 検索をオンにし、リサーチの概要を書いて出典付きのレポートを読むまでを、太陽電池の調査を例に解説。Exa のキーは不要です。 - [MCP サーバーを顧客にデモする方法](https://conduitllm.com/ja/mcp-distribution.html) — MCP サーバーのホストは顧客デモではありません。ホスト型チャット、Claude Desktop と拡張機能、自社クライアントを比較します。