Finyuus

Finyuusの言語は、汎用スクリプトではなくAIオーケストレーションのために書かれた小さなドメイン固有言語だ。文はエージェント呼び出し、ネイティブおよびHTTPツール、ガード、承認、条件分岐、ループ、並列ブランチ、子パイプラインを網羅する。ワークフローはプレーンテキストなので、差分を取って比べ、プルリクエストでレビューし、部品をプロジェクトをまたいで再利用できる。それこそが存在理由だ。読んで比べられるAIの振る舞いであり、箱で埋まったキャンバスではない。箱はない。ただのテキストだ。

すべての実行はTemporalに支えられている。これが長い待機と障害を乗り越えられる理由だ。ワーカーが実行の途中で落ちても、ワークフローは記録された状態から再開し、最初からやり直さない。リトライ、キャンセル、子ワークフローのオーケストレーションも同じ層から来る。ただ動く。数時間のエージェントジョブがクラッシュで消えるのを見たことがある人にとって、この機能は判断を変える。

ガードはLLMベースのポリシーチェックで、allowed、confidence、reasonといったフィールドを返す。パイプラインは通過かブロックの分岐に実行を振り分け、単純な可か不可ではなく信頼度のしきい値で判断できる。これにより、モデルが金融アドバイスの質問に直接答えるのを防いだり、公開ポリシーに反する出力をユーザーに届く前に止めたりできる。単純な発想。実務では大きな違いだ。

承認文は、レビュアーがダッシュボードかAPIで解決するまでワークフローを一時停止する。担当者、タイムアウト、タイムアウト時の処理を設定すると、パイプラインは承認済みと却下の経路に分岐する。提案ではなく本物の停止だ。「後で確認する」と、危険な出力を実際に止めて人間を待ってから再開するシステムの違いはここにある。

エージェント、ガード、ツール、スキーマ、パイプラインは、不変のバージョン固定を伴う保存可能なオブジェクトだ。pipeline:company_research@v2 と書けば、まさにそのバージョンが手に入る。誰かが最後に編集したものではない。固定して、先へ進む。子パイプラインは直接呼び出しても、エージェントツールとして包んでもよい。だから一箇所の変更が、依存するすべてのワークフローに静かに波及することはない。

どのパイプラインもHTTPエンドポイントとして公開でき、Bearerトークン認証、Redisを土台にしたレート制限、冪等キー、入力検証を備える。サーバー送信イベントが実行の更新を呼び出し元へ流し、承認は独自のイベントを発する。プロセスの上限は既定で全体が毎分300リクエスト、エンドポイントごとに120リクエストで、すべて環境変数で設定できる。妥当な既定値。上書きは簡単だ。

トレース、トークン使用量、モデルコストはLangfuseに集まり、アプリケーションデータとパイプラインのテーブルはClickHouseにある。実行履歴、ガードの結果、承認の判断はダッシュボードで見える。狙いはダッシュボードを増やすこと自体ではない。断片化したAIシステムには、たいてい「この実行で実際に何が起きたか」に答える一箇所がない、ということだ。

ファイルや大きな成果物は設定可能なオブジェクトストレージへ送られ、既定はローカルMinIOで、いくつかの環境変数でAWS S3に切り替えられる。DSLはファイルの読み書きとClickHouseを土台にしたテーブルを一級の文として扱うため、構造化データの操作は別サービスではなくワークフローの中にある。世話をする余計なサービスは要らない。