· TongFlow Team · プロダクト  · 読了目安:9分

TongFlow がモダリティから考える理由

データ、処理、モデル。それぞれの役割を分けると、得られた結果を次に使い、モデルを変えながら、自分の目的に合うワークフローを組み立てられます。

手元に一つの文書があります。内容を取り出して要約し、移動中に聞ける音声にもしたい。ファイル、テキスト、音声と扱うものは変わりますが、やりたいことはつながっています。同じ情報を、別の形で使いたいのです。

TongFlow は、こうした目的からワークフローを考えます。今、何があるのか。何を得たいのか。その間に、どんな処理が必要なのか。

この設計の出発点を modality-first と呼んでいます。テキストや画像、音声といった情報の形態、つまりモダリティを基本に据え、それらを扱う機能をつなぐ。各ステップの実行は、対応するプラグインやモデルに任せます。

データ、機能、モデルを分けて考える

モダリティという言葉は少し専門的ですが、キャンバス上では具体的です。一段落のテキスト、一枚の画像、一つの音声ファイル。それぞれが独立したノードとして置かれています。

その先に何をつなぐかで、できることが変わります。テキストなら音声合成や画像生成へ。画像なら内容の読み取り、加工、動画生成へ。

ワークフローを組むときには、三つのことを決めます。

  • データ:このステップで使うテキスト、画像、音声はどれか。
  • 機能:抽出、生成、変換、組み合わせ、分割のうち、何をするのか。
  • 実装:対応するどのプラグインやモデルで実行するのか。

こう分けると、まず「このテキストを音声にする」というステップを置き、その後で音声合成の実装を選べます。モデル選びは大切ですが、最初に選んだモデルにワークフロー全体の形を合わせる必要はありません。

結果を、次の入力にする

冒頭の文書を例にすると、次のような流れを組めます。

文書 → テキスト抽出 → テキスト
                       ├→ 要約 → 要約文
                       └→ 音声合成 → 音声

二つの分岐は、同じ抽出結果を使います。要約文と音声は、それぞれの出力として残ります。後から「全文ではなく要約を読み上げたい」と思ったら、音声合成の入力を要約文につなぎ替えられます。

処理結果も、引き続き使えるデータです。アップロードした画像も、生成した画像も、画像を受け取る次の処理に渡せます。生成した音声をさらに加工したり、人物画像と組み合わせて話す動画を作ったりすることもできます。

最初から全体を設計しきる必要はありません。一部分を組み、結果を確かめ、そこから分岐を増やしたり、別の結果と組み合わせたりする。すでにできたものを起点に、続きを考えられます。

コンテンツも、仕事の進め方も作れる

画像や動画の生成は、この仕組みが伝わりやすい例です。文書からの情報抽出、文字起こし、内容の理解、データの整理にも、同じ考え方を使えます。

たとえば、動画をクリップに分割し、音声を取り出して文字に起こす。そのテキストを整理したり、次の生成処理に渡したりできます。一つの入力を複数に分ける処理も、情報の形を変える処理も、一つのワークフローに組み込めます。

TongFlow で作れるものは、画像や動画だけにとどまりません。情報を処理する方法や、繰り返し使う仕事の手順も、自分で組み立てられます。何を作るかは、使う人の目的から決まります。

追加、変換、組み合わせ、分割、一括処理。それぞれの操作をつなぐことで、一つの機能だけではできなかった使い方が生まれます。

モデルを変えても、組み立てた流れを活かす

ワークフローの途中に、画像を生成するステップがあるとします。最初はプラグイン A を使い、後から別の実装も試したくなりました。

TongFlow は、そのステップが担う機能と、実行するプラグインを別々に記録します。新しい実装が同じ入出力の仕様に対応していれば、前後のつながりを保ったまま切り替えられます。設定や認証情報、実際の出力は、新しい実装に合わせて確認します。

コードでは、機能ごとの入出力定義とノードレジストリが、この区別を支えています。何を受け取り、何を返すかを定義し、それをどのプラグインで実行するかはワークフローで指定します。モデルの選択が変わっても、目的に合わせて考えた手順は活かせます。

つなげられる理由は、入出力が明確だから

音声を受け取る処理には、音声を渡す必要があります。画像と声を組み合わせる処理なら、その両方が必要です。モダリティを中心に据える設計は、こうした接続のルールがあってこそ成り立ちます。

実行できる処理は、用意されている機能、インストールした対応プラグイン、その設定によって決まります。新しいモダリティや機能を加える際にも、定義と実装が必要です。

一つの対応機能が加わると、既存のデータに新しい使い道ができます。すでにある処理との組み合わせも増えます。この広がり方に、私たちは modality-first の意味を感じています。

人とエージェントが、同じワークフローを編集する

キャンバスでは流れを見ながら組み立てられます。その構造は、コードからも操作できます。TongFlow のキャンバス、接続チェック、エクスポーターは、共通のノードレジストリを参照しています。

DSH 連携では、エージェントがワークフローファイルを作成し、それをユーザーがキャンバスで開いて確認・編集できます。出力だけでなく、そこに至る手順も受け渡せるわけです。入力や機能、プラグインを変えたくなったら、該当するステップを修正できます。

テキストも、音声も、その先も。ひとつのワークフローに。TongFlow は、できあがった結果から、さらに続きを作れる場所でありたいと考えています。

TongFlow を開いて、手元のテキストやファイルから始めてみてください。実装については、ソースコード機能レジストリDSH 連携をご覧ください。

Why TongFlow starts with modalities

Materials, capabilities and models have different jobs. Keeping them separate lets you build workflows around your task, reuse their results and change implementations as you go.

TongFlow가 자료의 형태에서 출발하는 이유

자료, 기능, 모델의 역할을 나누면 무엇이 달라질까요? 결과를 다음 입력으로 쓰고, 모델을 바꾸면서도 흐름을 유지하며, 목적에 맞는 워크플로를 만들 수 있습니다.