Statewrightは、GitHub上で公開されているオープンソースのプロジェクトで、説明としては 「State machine guardrails for AI agents」 とあります。
ざっくり言うと、AIエージェントに対して
を、状態機械（state machine） で決める仕組みです。
ここでいう state machine とは、難しく聞こえますが、要するに 「今の段階によって振る舞いが変わるルール表」 です。
たとえば人間の仕事でも、
という順番がありますよね。Statewrightは、AIにもその順番を守らせるための仕組みだと考えるとわかりやすいです。
元記事が強調している問題は、AIエージェントは強力だけど、同時にかなり脆いということです。
たしかに、AIにツールを40個以上渡して「さあ何とかして」と言うと、実際には
といったことが起こりやすいです。
多くの場合、対策としては
といった方向に行きがちです。
でもStatewrightの考え方は違っていて、「モデルを賢くする前に、そもそも解くべき問題を狭くする」 というものです。
これはかなり面白いです。
AIって「頭脳勝負」だと思われがちですが、実際には仕事の進め方を整理したほうが効くことが多いんですよね。人間のマネジメントと同じで、自由すぎると逆に崩れる。そこを状態で縛る発想は、地味だけど強いです。
Statewrightの基本は、状態ごとに使えるツールを変えることです。
たとえば記事では、こんな流れが紹介されています。
この段階では、読めるだけでよく、編集はまだできないようにします。
のような、調査系のツールだけを許可します。
ここで初めて編集が可能になります。
が使えるようになります。
ただし、単に「Editを許可する」だけではなく、shell操作も限定されます。
たとえば、write-via-redirect や危険な削除操作はブロックされると説明されています。
つまり、AIに“なんでもできるターミナル”を渡すのではなく、かなり慎重に範囲を絞るわけです。
この段階ではテスト関連のコマンドだけを許可します。
は使えるものの、pytest、cargo test、npm test のような許可されたコマンドだけに制限できます。
もしその状態で許可されていないツールを呼ぼうとすると、拒否される仕組みです。
しかも単に「ダメです」で終わらず、今使えるものと、どう遷移すればいいかが案内されるそうです。
このあたり、かなり親切です。
AIは「禁止された」ことよりも「じゃあ次に何をすればいいのか」を示してあげたほうが、ずっと安定して動くと思います。
元記事では、ローカルモデルでの実験結果も紹介されています。
特に印象的なのは、Statewrightの制約をかけることで、タスクの成功率が大きく改善したという点です。
記事の表では、たとえば以下のような結果が示されています。
要するに、モデルのサイズをただ上げるより、状態とツールを整理したほうが効く場面があるということです。
もちろん、これは万能ではありません。
記事でも、13GB未満のモデルではファイル内容を十分保持できず、正確な編集が難しいという“床”があると説明されています。
なので「Statewrightが魔法のようにすべてを解決する」という話ではないです。そこはちゃんと線引きされていて好感が持てます。
Statewrightの面白いところは、単なる「禁止機能」ではなく、ワークフロー全体を守る仕組みになっていることです。
記事では、次のような guardrails が挙げられています。
rm や shred など危険な操作をブロックするこれ、AIエージェント版の「社内ルールブック」みたいなものです。
個人的には、AIを本番で使うなら、こういうルールがないほうがむしろ怖いと思います。AIは賢いけれど、雑に信じるにはまだ危うい。だからこそ、こういう設計が重要なんでしょう。
記事では、Claude Code でのクイックスタートが紹介されています。
流れとしては、
という感じです。
例としては、bugfix workflow を起動して、
「壊れているテストを直す」みたいな作業を、計画 → 実装 → テスト の順で進めるデモが示されています。
このデモがわかりやすいのは、AIにありがちな
という流れを、状態管理で抑えているからです。
Statewrightの中核は、Rustで書かれた deterministic なエンジンだと説明されています。
deterministic というのは、ざっくり言うと 「同じ入力なら同じ結果になる」 ということです。
ここで重要なのは、LLMが状態管理の本体ではないことです。
LLMはあくまで作業をする側で、状態遷移やルール判定は別のエンジンが担う。
この分離はかなり良い設計だと思います。
というのも、AIにルールまで全部丸投げすると、結局ルール自体があいまいになりがちなんですよね。
でもStatewrightは、ルールは機械的に判定し、AIはその範囲で働くようにしている。ここが筋が通っています。
記事では、以下のようなエージェントとの連携が挙げられています。
ただし、全部が同じ強さで守られるわけではなく、
Hard と Advisory の違いがあります。
この違いはかなり大事です。
「指示したつもり」なのと「本当に止められる」のは別物ですからね。
本番運用を考えるなら、やっぱり Hard のほうが安心感はあります。
Statewrightは、次のような人に向いていそうです。
逆に、
「AIに全部自由に任せたい」「細かい制約は面倒」という人には、少し重く感じるかもしれません。
でも、私はその“面倒”こそが本番では価値になると思います。自由なAIはデモでは華やかですが、実務ではルールがあるAIのほうが強いことが多いです。
Statewrightは、AIエージェントに対して「状態ごとのルール」を与えるための guardrails です。
派手さはそこまでありませんが、AIを現実の作業に持ち込むうえで、かなり本質的な方向だと感じました。
特に、
という考え方は、AIエージェントの弱点をうまく突いています。
個人的には、AIエージェントの未来は「より自由にすること」より、いかに賢く制約するかにかかっていると思います。
Statewrightはその答えのひとつとして、かなり説得力があるプロジェクトです。
参考: GitHub - statewright/statewright: State machine guardrails for AI agents