Statewright: AIエージェントに決定論的なガードレールをもたらす
AIエージェントは、強力でありながら脆弱であるとしばしば表現されます。膨大なツール群とオープンエンドな目的を与えられたとき、最も高度なモデルでさえ苦戦し、アクションを起こさずに同じファイルを繰り返し分析し続ける「リード・ループの死の螺旋（read-loop death spirals）」に陥ることがよくあります。業界の標準的な対応は、通常、より大きなモデルをデプロイするか、より長いシステムプロンプトを書くことですが、これらは本番環境レベルの信頼性を確保するには不十分なことが多いです。
Statewrightは異なる哲学を導入します：「エージェントは提案であり、状態は法である。」 モデルをより賢くしようとする代わりに、Statewrightは、ワークフローの特定のフェーズにおいてエージェントがどのツールにアクセスできるかを厳密に制御するステートマシン・ガードレールを実装することで、問題をより小さくします。
コア・アプローチ：解決空間の制約
その核心において、Statewrightはステートマシン定義を評価する決定論的なRustエンジンです。状態を管理するためにLLMを使用するのではなく、プロトコル層のゲートキーパーとして機能します。ツールと解決空間を制約することで、モデルは各ステップにおいて焦点を絞ったコンテキスト内で推論することを強制されます。
例えば、典型的なバグ修正ワークフローは、いくつかの異なる状態に分割できます：
- Planning: エージェントには読み取り専用ツール（例：
Read,Grep,Glob）が許可されます。コードを修正することはできず、修正を試みる前に問題を完全に理解していることを保証します。 - Implementing: エージェントがこの状態に遷移すると、編集ツールがアンロックされます。しかし、Statewrightは、破壊的なシェル操作（
rmやshredなど）をブロックしたり、状態ごとの編集行数を上限に設定したりするなどの、さらなる制約を適用できます。 - Testing: 指定されたテストコマンド（例：
pytestやnpm test）のみが許可されます。エージェントが現在のフェーズで許可されていないツールを使用しようとした場合、リクエストは、何が利用可能でどのように遷移すべきかを説明するメッセージとともに拒否されます。
モデル・パフォーマンスの測定可能な向上
Statewrightの最も説得力のある側面の一つは、小規模でローカルなモデルへの影響です。開発者による研究によ成ると、制約を設けることで、複雑なタスクを完了するために必要な「インテリジェンス・フロア（知能の底）」が大幅に低下します。
SWE-benchベンチマークの5タスクのサブセットにおいて、2つのモデル（13.8GBから19.9GBの範囲）は、Statewrightの制約を使用した場合、成功率が2/10から10/10へと跳ね上がりました。13GB未満のモデルは、ファイル内容の保持能力の限界（ステートマシンの制約ではなく、ハードウェア/モデルの制約）により依然として苦戦しますが、結果は、構造的な制約が中規模のローカルモデルを特定のワークフローにおいて最前線モデル（frontier models）のように機能させることができることを示唆しています。
最前線モデルの場合、メリットは基本的な能力というよりも効率性にあります。利用可能なツールを30個以上から一握りに減らすことで、Statewrightはトークン使用量を削減し、モデルが「空回り」したり、繰り返しのループに陥ったりすることを防ぎます。
技術的実装とガードレール
Statewrightは、Model Context Protocol (MCP) または特定のプラグイン・フックを介してエージェントと統合します。強制力のレベルはエージェントによって異なります：
- Hard Enforcement (強制的強制): Claude Codeのようなエージェントでは、ツール呼び出しはモデルがそれを見る前にプロトコル層でブロックされます。
- Advisory Enforcement (助言的強制): Cursorのようなエージェントでは、ルールはコンテキストに注入されますが、アーキテクチャはプロトコル層での強制的強制を許可していません。
主要なガードレール機能
| Guardrail | Function |
| :--- | :--- | |
| Per-state tool enforcement | ツールはallowed_toolsリストにない限り、エージェントには見りえません。 |
| Bash discernment | 非書き込み状態において、リダイレクト（>>）や破壊的な操作をブロックします。 |
| Edit guards | max_edit_linesと状態ごとの編集ファイル数を制限します。 |
| Conditional transitions | プログラマティックな述語（例：eq, gt）を使用して、状態遷移をトリガーします。 |
| Approval gates | 高リスクな遷移の前に、人間のレビューのために実行を一時停止します。 |
カスタム・ワークフローの定義
ワークフローはJSON schemaを使用して定義され、単純な有向非巡回グラフ（DAGs）ではなく、ループや反復プロセスを作成することを可能にします。これは、エージェント的な作業は線形ではないことが稀であるため、非常に重要です。エージェントの作業は、しばしば失敗したテストの再試行や、実装が失敗した後にプランニング・フェーズに戻ることを必要とします。
開発者は、これらのワークフローを、手動で作成したり、ビジュアル・エディタを使用したり、あるいは、statewright_create_workflowツールを使用してエージェントにワークフロー定義を生成させたりすることもできます。
トレードオフと検討事項
Statewrightは大幅な信頼性の向上を提供しますが、トレードオフなしでは提供されません。システムが機能するためにはMCPのサポート（または特定のフック）が必要です。さらに、ワークフローが制限されすぎている場合、エージェントがスタックしてしまう可能性があるため、その場合はstatewright_deactivateエスケープ・ハッチを使用して、制約のない状態に戻る必要があります。
モデルのサイズではなく構造的な制約に焦点を移すことで、Statewrightは、AIエージェントを予測可能で、検証可能で、そして最も重要なこととして、自律的なソフトウェアエンジニアリング・タスクにおいて十分に信頼できるものにするためのフレームワークを提供します。