Sandboxed Agent Workflow RuntimeとしてのHARVASK

HARVASKは、自らを「AI業務OS」と呼んでいます。一方で、技術的に何を作っているのかを説明するなら、Sandboxed Agent Workflow Runtimeという表現が近いと考えています。

この言葉は、HARVASKを構成する3つの要素を表しています。

Sandboxed：AIやプログラムを、独立した作業空間で実行する
Agent：AIを応答生成器ではなく、環境を操作して仕事を進める実行主体として扱う
Workflow Runtime：AI・プログラム・人間を同じ実行グラフ上でオーケストレーションする

HARVASKの設計の中心にあるのは、プロンプトやチャットUIではありません。AIに実際の作業を行える環境を与え、その実行をProgramとHumanを含むワークフローへ接続することです。

この記事では、HARVASKの内部実装ではなく、外部から見える実行モデルと、その設計を採った理由について書きます。

Sandboxed：実行ごとに独立した作業空間を持つ

AIノードの実行時には、その仕事専用のワークスペースが用意されます。イメージとしてはVMのようなものです。厳密には一般的なVMとは異なりますが、論理的には「AIに独立した作業用マシンを1台渡す」と捉えると分かりやすいと思います。

この作業空間には、仕事に必要なリポジトリやドキュメントを配置でき、AIはファイルシステム、ターミナル、ブラウザ、MCPなどを利用して処理を進めます。

基盤の具体的な構成や構築方法は公開しません。ここで重要なのは実装方式ではなく、各実行が独立した作業コンテキストを持ち、その内部で必要な環境を構築できるという性質です。

Agent：応答ではなく、実行ループを完了させる

チャットベースのAIは、基本的に「入力を受け取り、推論し、応答を返す」というリクエスト／レスポンスで動きます。

HARVASKのAIノードは、応答を返すだけではなく、一つの仕事を完了させる単位で動きます。

AIはこのワークスペースで、たとえば次の処理を実行できます。

リポジトリやドキュメントを読み込む
コードや設定ファイルを編集する
依存関係をインストールする
Dockerコンテナを起動する
テストやビルドを実行する
ブラウザを操作する
MCPや外部サービスを利用する
実行結果を次のノードへ渡す

モデルの出力は最終成果物ではありません。推論は、環境内でコマンドを実行し、その結果を観測し、必要なら修正して再実行するループの一部です。

AIにコードを書かせるだけでなく、実際に動かして確認させる。

HARVASKでは、計画、実行、観測、修正、再実行というループ全体をAIノードの責務として扱います。

Dockerを起動し、生成と検証を同じ環境で回す

コード生成そのものは、すでにかなり簡単になりました。ただ、動作確認をせずにまともなソフトウェアを作ることはできません。これは実装者が人間でもAIでも同じです。

そのため、HARVASKの作業空間ではDockerを実行できるようにしています。AI自身が対象システムの依存サービスを立ち上げ、書いたコードを実行し、テストが落ちたらログを読んで修正するところまで進めます。

たとえばAIエージェントの開発では、次のような流れを一つのジョブ内で実行できます。

実装
  ↓
依存サービスの起動
  ↓
エージェントの実行
  ↓
ブラウザや外部連携を含むE2Eテスト
  ↓
ログ・出力の検証
  ↓
修正して再実行

これはCI環境を提供するという話ではありません。AIが開発を担当するなら、書いたものを実際に起動し、挙動を観測できる環境が必要だという話です。

生成と検証が同じ実行コンテキストにあるため、AIはコードを返した時点で止まりません。実際に起動し、期待した振る舞いをするか確認してから次へ進めます。

Workflow Runtime：3種類のノードを同じ実行グラフで扱う

HARVASKのワークフローには、次の3種類のノードがあります。

AIノード：AIが推論し、ツールやコマンドを使って作業する
Programノード：決定的なプログラム処理を実行する
Humanノード：人間へ判断や作業を依頼し、完了を待つ

AIノードとProgramノードは作業空間で処理を実行します。Humanノードは作業空間では実行されず、人間へタスクを渡して入力を待ちます。人間が作業や判断を完了すると、保存された文脈を引き継いでワークフローが再開します。

たとえば、次のような処理を一つのワークフローとして定義できます。

Human：要件を入力
  ↓
AI：実装方針を整理してコードを変更
  ↓
Program：静的解析や定型チェックを実行
  ↓
AI：環境を構築してE2Eテスト
  ↓
Human：結果をレビューして承認
  ↓
AI：指摘を反映して完了

ポイントは、AI・Program・Humanを別々のシステムとして後から接着するのではなく、最初から同じ実行グラフ上のノードとして扱うことです。

ノード間では、作業の文脈や成果を引き継ぎます。AIが人間へ判断を求め、その回答を別のAIノードが受け取ることも、Programノードの出力をAIノードが解釈して次の処理を決めることもできます。

オーケストレーションの対象は、LLMではなく仕事そのもの

多くのAIエージェントフレームワークは、モデル、プロンプト、メモリ、ツール呼び出しをどう接続するかを扱います。

HARVASKが扱うのは、その一段外側です。

実務には、非決定的な推論が向く処理、コードで決定的に実行すべき処理、人間が責任を持って判断すべき処理が混在します。これをすべてAIへ寄せるのも、すべてプログラムへ落とすのも無理があります。

HARVASKでは、処理の性質に応じてAI・Program・Humanのノードを組み合わせます。

曖昧な情報の解釈や計画はAIノード
再現性が必要な定型処理はProgramノード
承認や例外判断はHumanノード

この分担を実行グラフとして定義し、ノード間で必要な文脈と成果物を渡す。HARVASKにおけるワークフローは、APIを順番に呼ぶためのものではなく、業務そのものを実行するためのモデルです。