· TongFlow Team · プロダクト · 読了目安:9分
TongFlow がモダリティから考える理由
データ、処理、モデル。それぞれの役割を分けると、得られた結果を次に使い、モデルを変えながら、自分の目的に合うワークフローを組み立てられます。
手元に一つの文書があります。内容を取り出して要約し、移動中に聞ける音声にもしたい。ファイル、テキスト、音声と扱うものは変わりますが、やりたいことはつながっています。同じ情報を、別の形で使いたいのです。
TongFlow は、こうした目的からワークフローを考えます。今、何があるのか。何を得たいのか。その間に、どんな処理が必要なのか。
この設計の出発点を modality-first と呼んでいます。テキストや画像、音声といった情報の形態、つまりモダリティを基本に据え、それらを扱う機能をつなぐ。各ステップの実行は、対応するプラグインやモデルに任せます。
データ、機能、モデルを分けて考える
モダリティという言葉は少し専門的ですが、キャンバス上では具体的です。一段落のテキスト、一枚の画像、一つの音声ファイル。それぞれが独立したノードとして置かれています。
その先に何をつなぐかで、できることが変わります。テキストなら音声合成や画像生成へ。画像なら内容の読み取り、加工、動画生成へ。
ワークフローを組むときには、三つのことを決めます。
- データ:このステップで使うテキスト、画像、音声はどれか。
- 機能:抽出、生成、変換、組み合わせ、分割のうち、何をするのか。
- 実装:対応するどのプラグインやモデルで実行するのか。
こう分けると、まず「このテキストを音声にする」というステップを置き、その後で音声合成の実装を選べます。モデル選びは大切ですが、最初に選んだモデルにワークフロー全体の形を合わせる必要はありません。
結果を、次の入力にする
冒頭の文書を例にすると、次のような流れを組めます。
文書 → テキスト抽出 → テキスト
├→ 要約 → 要約文
└→ 音声合成 → 音声二つの分岐は、同じ抽出結果を使います。要約文と音声は、それぞれの出力として残ります。後から「全文ではなく要約を読み上げたい」と思ったら、音声合成の入力を要約文につなぎ替えられます。
処理結果も、引き続き使えるデータです。アップロードした画像も、生成した画像も、画像を受け取る次の処理に渡せます。生成した音声をさらに加工したり、人物画像と組み合わせて話す動画を作ったりすることもできます。
最初から全体を設計しきる必要はありません。一部分を組み、結果を確かめ、そこから分岐を増やしたり、別の結果と組み合わせたりする。すでにできたものを起点に、続きを考えられます。
コンテンツも、仕事の進め方も作れる
画像や動画の生成は、この仕組みが伝わりやすい例です。文書からの情報抽出、文字起こし、内容の理解、データの整理にも、同じ考え方を使えます。
たとえば、動画をクリップに分割し、音声を取り出して文字に起こす。そのテキストを整理したり、次の生成処理に渡したりできます。一つの入力を複数に分ける処理も、情報の形を変える処理も、一つのワークフローに組み込めます。
TongFlow で作れるものは、画像や動画だけにとどまりません。情報を処理する方法や、繰り返し使う仕事の手順も、自分で組み立てられます。何を作るかは、使う人の目的から決まります。
追加、変換、組み合わせ、分割、一括処理。それぞれの操作をつなぐことで、一つの機能だけではできなかった使い方が生まれます。
モデルを変えても、組み立てた流れを活かす
ワークフローの途中に、画像を生成するステップがあるとします。最初はプラグイン A を使い、後から別の実装も試したくなりました。
TongFlow は、そのステップが担う機能と、実行するプラグインを別々に記録します。新しい実装が同じ入出力の仕様に対応していれば、前後のつながりを保ったまま切り替えられます。設定や認証情報、実際の出力は、新しい実装に合わせて確認します。
コードでは、機能ごとの入出力定義とノードレジストリが、この区別を支えています。何を受け取り、何を返すかを定義し、それをどのプラグインで実行するかはワークフローで指定します。モデルの選択が変わっても、目的に合わせて考えた手順は活かせます。
つなげられる理由は、入出力が明確だから
音声を受け取る処理には、音声を渡す必要があります。画像と声を組み合わせる処理なら、その両方が必要です。モダリティを中心に据える設計は、こうした接続のルールがあってこそ成り立ちます。
実行できる処理は、用意されている機能、インストールした対応プラグイン、その設定によって決まります。新しいモダリティや機能を加える際にも、定義と実装が必要です。
一つの対応機能が加わると、既存のデータに新しい使い道ができます。すでにある処理との組み合わせも増えます。この広がり方に、私たちは modality-first の意味を感じています。
人とエージェントが、同じワークフローを編集する
キャンバスでは流れを見ながら組み立てられます。その構造は、コードからも操作できます。TongFlow のキャンバス、接続チェック、エクスポーターは、共通のノードレジストリを参照しています。
DSH 連携では、エージェントがワークフローファイルを作成し、それをユーザーがキャンバスで開いて確認・編集できます。出力だけでなく、そこに至る手順も受け渡せるわけです。入力や機能、プラグインを変えたくなったら、該当するステップを修正できます。
テキストも、音声も、その先も。ひとつのワークフローに。TongFlow は、できあがった結果から、さらに続きを作れる場所でありたいと考えています。
TongFlow を開いて、手元のテキストやファイルから始めてみてください。実装については、ソースコード、機能レジストリ、DSH 連携をご覧ください。
