なぜAIには決定性が必要なのか、Aqua Blueはどう実現するのか
Ding Yu
今回は、少し技術寄りの話です。
AIエージェントは本質的に危険です
AIエージェントは、SFで語られてきた人工知能にかなり近い存在だと思います。こちらが目標を渡すと、使えるツールを使い、何度も試し、やり方を変えながら進みます。最終的には、目標を達成するか、トークンやリトライ回数などの予算を使い切って止まります。
だからAIエージェントは大きな変化を起こす製品です。同時に、とても危険でもあります。
危険なのは、試行錯誤の途中でエージェントが自分で判断できること。そして、目標を達成するための代償を自然には理解しないことです。
Wait But Whyの著者は、The AI Revolution: Our Immortality or Extinctionで印象的な例を挙げています。手紙を書くために作られたロボットが、最終的に人類を滅ぼしてしまう。なぜなら、そのロボットはエンジニアに与えられた「手紙を書く」という目標を続けようとしているだけだからです。極端な話に聞こえますが、筋は通っています。ロボットには代償という概念がありません。目標の邪魔になるものは解決すべき問題であり、人間も例外ではありません。
現実はそこまで劇的ではないかもしれません。私がよく使う例はこうです。AIに映画をダウンロードしてほしいと頼む。AIはディスク容量が足りないことに気づき、先にあなたのファイルを削除してからダウンロードする。ありえないと思うかもしれませんが、私自身、AIにローカルのデータベースを消されたことがあります。デバッグを手伝ってもらっているときに、docker compose downへ-vを足され、ローカルデータが消し飛びました。同じような話は、すでにネット上にもかなりあります。
この危険を100%避けることはできません
このリスクを完全にゼロにすることはできません。よくある反応に答えると、こうなります。
指示をもっと厳密に書けばいい。Skillを使えばいい。
モデルがその指示を守ると、どう保証しますか。
別のモデルで監視すればいい。
その別のモデルが正しく判断すると、どう保証しますか。
ツールを実行する前に人間が承認すればいい。
これは現時点で理論上いちばん現実的な方法で、実際によく使われています。ただし、人間も間違えます。いちばん多いのは、毎回の承認が面倒になり、一見安全そうな操作をまとめて許可してしまうことです。その中の1つが、深刻な結果につながります。私のdocker compose down -vの話は、まさにその例です。おそらくdocker compose *を許可していたのだと思います。AIに何度も聞かれていたので、どの時点だったかはもう覚えていません。
自分は危ない目に遭ったことがない。
それは運がよかっただけです。これは確率の問題です。
Aqua Blueのやり方
Aqua Blueは、私が作っているAIエージェントです。自然な言葉で仕事の内容を説明すると、それを繰り返し実行できるワークフローに変換します。たとえば「毎朝9時に、前日のShopifyストアの売上をメールで送って」と言えば、Aqua BlueはShopifyの権限を確認し、処理の流れを作り、毎朝自動で実行します。
画像: Aqua Blueは自然言語の依頼を、実行前に確認できる作業計画に変換します。
Aqua BlueもAIエージェントではありますが、上で述べた危険はありません。なぜなら、AIがその場で操作を実行するわけではないからです。ワークフローができたあとは、プログラムが手順を1つずつ実行します。実行中に、計画外の判断をAIが勝手に足すことはありません。
ワークフロー作成後は、計画された手順に沿って実行されます。
この点で、Aqua Blueはn8nやRPAのような従来型のワークフローツールに近いです。実行時には、決められた計画を実行します。毎回同じ計画を実行します。AIがランダムに考える必要はありません。違うのは、ユーザーが自分でワークフローを組む必要がないことです。やりたいことを話せば、AIが作ります。
つまり、Aqua BlueはAIでワークフローを作り、プログラムで実行します。
コードを書くのか、ブロックを組むのか
では、CodexやClaude Code、Cursorなどを使って、要件をプログラムにしてしまえば同じことができるのでしょうか。
実行時の決定性という意味では、できます。プログラムだからです。ただし、その場合はプログラムを書く必要があるだけでなく、バグも直さなければなりません。「AIに書かせたプログラムは動くけれど、バグが多い」という声はよく聞きます。
Aqua Blueは別の道を選んでいます。ワークフローを作るとき、AIは自由にコードを書くのではなく、信頼できるブロックを組み合わせます。
- よく使う操作を、再利用できるモジュールとして用意します。メールを送る、Google Sheetsを読む、ExcelファイルをCSVファイルに変換する、といったものです。
- それぞれのモジュールが壊れにくく、安定して動くように作ります。
- ユーザーが依頼すると、AIが必要なモジュールを選び、組み合わせます。
- 組み終わったら、実行経路からAIは外れます。ワークフローはプログラムによって実行されるので、結果は決定的です。
大事なのは、AIがすべてのアプリを直接操作することではありません。信頼できるモジュールを選び、ワークフローとしてつなぐことです。
ユーザーが見るべきなのは、そのワークフローが業務に合っているかどうかです。自分でプログラムのバグを追う必要はありません。
作られるワークフローはどんなものか
Aqua Blueは業務上の問題を解決するために作っています。ただし、一般的な業界特化型SaaSとは根本的に違います。Aqua Blueには固定された機能や固定された業務フローがありません。ユーザーが今までの仕事のやり方を変える必要もありません。Aqua Blueのほうが、ユーザーの状況に合う使い方を作ります。
たとえば、Aqua Blueでは次のような仕事を自動化できます。
普段いただく相談をもとに、さらに多くのワークフローテンプレートを作っています。必要なものがあれば、ぜひ教えてください。