Conduit ダウンロード

チュートリアル

Conduit のワークフローでタスクを自動化する方法

毎日やる価値はあっても、手作業で続けるほどではない作業があります。変更履歴を読む、ページの変化を確認する、フォルダに届いたものを要約する、といった作業です。無料のオープンソース デスクトップ AI アプリ Conduit のワークフローは、こうした定型作業を、スケジュールに沿って、または新しいものが現れたときに代わりに実行し、確認する価値があるときだけ知らせてくれます。

はじめに

ワークフローは、順番に実行される手順のリストです。ページやファイルを取得して読み込む手順、モデルに処理を依頼する手順、結果を保存したり通知したりする手順があります。各手順は、それより前の手順が生成したものを利用できます。リスト全体は、手動で、スケジュールで、またはフィードやフォルダに新しいものが追加されるたびに実行できます。

このチュートリアルでは、使っているツールのリリースを見守るワークフローを作ります。例には、Python のパッケージマネージャーである uv を使います。リリースの頻度が高く、リリースノートが詳しいためです。新しいリリースごとに、ワークフローはリリースノートを読み、低コストのモデルに短い要約を依頼して、その要約を保存し、リリースに破壊的変更があるときだけデスクトップ通知を送ります。安全にテストし、各手順が何を行ったかを読み、全体をやり直さずに手順を修正し、最後に承認して無人で動かすところまで進めます。

GitHub 上のどのプロジェクトでも同じように進められます。変わるのはフィードのアドレスだけです。

要点

前提条件

このチュートリアルを進めるには、次のものが必要です。

ステップ 1 — 用意されたワークフローから始める

Conduit には、そのままでも、変更しても使える既製のワークフローが付属しています。このステップでは、すでにフィードを見守る設定になっているものを作成し、リリースの監視用ワークフローのベースにします。

サイドレールでワークフローを選ぶか、Ctrl+6（macOS では ⌘6）を押します。ワークフローがまだない場合は、まだワークフローがありませんの下に既製のワークフローが並びます。すでにある場合は、新しいワークフローを選ぶと表示されます。

一覧には、次のものが含まれます。

新しい投稿を要約を見つけて、このテンプレートを使うを選びます。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欄には、投稿のリンクを表すチップが入っています。こうした値は、各欄の横にある値を挿入…メニューから挿入します。メニューには、ワークフローのその時点で使える値が並びます。

取得の手順はそのままにしておきます。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、ドキュメントを保存を見つけて、次のように設定します。

実行ごとのもう一方の選択肢、同じドキュメントを置き換えますは、最新の結果だけを 1 つのドキュメントに残すもので、ページの監視や毎日のブリーフィングに向いています。リリースの履歴を残したいので、ここではリリースごとに 1 つのドキュメントが必要です。

保存を、次に追加する確認の前に置くのは意図的です。今日は注目する必要のないリリースも含め、すべてのリリースが記録されます。

次に、通知するかどうかを判断する手順を追加します。

ステップ 6 — 破壊的変更のときだけ通知する

…の場合のみ続ける手順は、ある値を確認し、確認に通らなければ実行を静かに終了させます。このステップでは、保存と通知の間にこの手順を追加し、破壊的変更のあるリリースだけが通知されるようにします。

手順の末尾で手順を追加…を開き、…の場合のみ続けるを選びます。新しい手順は最後に追加されるので、↑ ボタンで通知を表示の上に移動します。そのうえで、次のように設定します。

比較では、大文字と小文字や余分な空白は無視されます。ほかの条件は、前回の実行から変わった、空ではない、空である、を含む、と等しいです。最初の条件は、スターターのページを見守るが、ページが変わったときだけ知らせるために使っています。

最後に、手順 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 を 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 つあります。

どちらの方法でも、下書きを確認し、今すぐ実行でテストしてから、自動的に実行をオンにしてください。

さらに進める：キャンバス、分岐、エージェント

リリースの監視用ワークフローは一直線ですが、ワークフローがそうである必要はありません。ここまでの内容を土台に、4 つのことができます。

すべての手順の種類を一覧で見る

リリースの監視用ワークフローで使った手順は 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 つずつ要約させたりしてみてください。さらに進むには、次のガイドをご覧ください。

Conduit をダウンロード

Conduit に関する記述は最新リリースに対応しており、 ドキュメントと ソースコードで確認できます。 誤りを見つけた場合は、お知らせください。修正します。

関連記事