キャンバスベースのエージェントオーケストレーションが重要な理由

多くの AI ツールは、1 本の会話スレッドを提供します。あなたが入力すると、モデルが応答し、あなたが反応する。これは単純なタスクには機能しますが、複雑な問題に複数のエージェントが協力する必要があると破綻します。

直線的なワークフローの問題

典型的な開発シナリオを考えてみましょう。1 つのエージェントにコードを生成させ、別のエージェントにレビューさせ、3 つ目にテストを書かせ、4 つ目にデプロイ設定を扱わせる必要があります。チャットベースのインターフェースでは、複数のウィンドウを行き来し、出力を手でコピーし、どのエージェントが何を出したか見失ってしまいます。

これはワークフローではありません。場当たり的な回避策です。

エージェント調整のための空間推論

キャンバスベースのオーケストレーションは、まったく違うアプローチを取ります。各エージェントは、無限キャンバス上のタイルとして存在します。全体を一度に見渡し、入力と出力の間に接続を引き、データがシステム内をリアルタイムに流れる様子を観察できます。

空間レイアウトは装飾ではありません。エージェント間の関係を符号化しています。

• 近さ は関連性を示す - 同じサブシステムを扱うエージェントは近くに並ぶ
• 接続 はデータフローを定義する - 1 つのエージェントの出力が次の入力になる
• 位置 は記憶を助ける - キャンバスに戻れば、アーキテクチャをすぐ思い出せる

これがエージェンティック開発で重要な理由

エージェントが定義されたルーティング経路を通じて互いの出力を見られると、より良い判断を下せます。仕様と生成コードの両方を受け取るコードレビューエージェントは、コードだけしか見ないエージェントよりも、はるかに関連性の高いフィードバックを出せます。

キャンバスベースのオーケストレーションは、こうした関係を明示的かつ編集可能にします。YAML を書いたり、コードでパイプラインを定義したりするのではありません。ホワイトボードにシステム図を描くように、タイルを並べて接続するのです。

MadoHub を作って分かったこと

社内でキャンバスベースのワークフローを何か月も試した結果、いくつかのパターンが見えてきました。

1. 小さく焦点の絞られたエージェントのほうが、大きく汎用的なエージェントより優れている。 キャンバスではタイルを 1 つ増やすだけなので、タスクを分解しやすい。
2. 視覚的なデバッグは速い。 出力がおかしければ、接続をたどって、どのエージェントが誤った入力を出したかを逆算できる。
3. チームは共有レイアウトに収束する。 キャンバスは、生きたアーキテクチャ図になり、誰でも読めて編集できる。

直線的なチャットから空間的なキャンバスへの移行は、漸進的な変化ではありません。エージェントの調整をどう考えるかを変え、その結果として作れるものも変わります。