AIエージェントの作業を段階ごとに縛るツール「Statewright」の仕組みと導入前の注意点

「開発用のAIエージェントに、調べるだけのはずの段階でファイルを書き換えられた」「試験が終わる前に、反映まで進めてしまわないか心配だ」——AIエージェントを開発の現場に入れ始めた企業で、情報システムや開発管理の担当者から聞こえてくる声です。こうした悩みに対して、エージェントに渡す権限を一度に決めるのではなく、作業の段階ごとに切り替える、という考え方があります。大事なのは、エージェントの判断を信じるか疑うかではありません。本当は、今どの段階にいて、その段階で何をしてよいかを、エージェントの外側の決まりで固定することです。この記事では、その考え方を形にしたツール「Statewright」について、一次情報で確かめられる仕組み、縛りが効く範囲と効かない範囲、提供元の管理クラウドとの関係、ライセンスの条件、導入前に確かめることを整理します。導入や設定の手順は扱いません。

Statewrightとは何か。2026年10月時点で確かめられる事実

Statewright は、GitHub で公開されているツールです。リポジトリの説明は「AIエージェントのための状態の機械による安全柵」で、READMEは冒頭で、エージェントの判断は提案にすぎず、状態こそが決まりだ、という考え方を掲げています。作業を段階（状態）に分け、段階ごとに使える道具と、次の段階へ進む条件を決めるのが基本の発想です。

2026年10月23日に確かめた範囲では、リポジトリは2026年5月3日に作られ、スターは約500、派生は23です。最後の更新は10月14日で、同じ日に開発エージェント向けの連携部品の新しい版がリリースの一覧に並んでいます。公開しているのは組織のアカウントで、作られたのはリポジトリの10日前、2026年4月23日です。公開されているリポジトリは6つで、会社名や所在地の記載はありません。

つなぐ先として名前が挙がっているのは、Claude Code、Codex、Cursor、OpenCode などの開発用のAIエージェントと、MCP（AIと外部の道具をつなぐ共通の取り決め）に対応した独自の環境です。READMEは、道具の制限やモデルの切り替えがどこまで効くかは連携先によって変わると最初に断っています。この断り書きは、後で見る注意点の中心になります。

なぜ今話題か：同じ道具を持ち続けるエージェントの危うさ

READMEが挙げる問題はシンプルです。作業の最初から最後まで同じ道具を持たせたエージェントは、見直しの最中に書き換えたり、確認が終わる前に反映まで進めたりできてしまう。人の開発の現場なら、調べる人、直す人、試す人、承認する人で権限を分けますが、エージェントには一つの権限の束を丸ごと渡しがちです。

ここに、権限の大きさではなく、権限を持たせる時間の長さが危うさを生むという見落としがあります。調査の段階で書き換えの権限は要りませんし、試験の段階で好きな命令を打てる必要もありません。必要なときに必要な分だけ渡す、という最小権限の考え方を、時間の軸に広げたものと言えます。

AIエージェントを業務に入れる企業が増え、エージェントが自分で道具を選んで続けて実行する場面が広がるほど、この区切りの需要は高まります。AIの判断の良し悪しに安全を預けず、外側の決まりで動ける範囲を区切るという発想は、Statewright に限らず、エージェントの統制を考えるうえで押さえておきたい論点です。

仕組み1：段階ごとに使える道具を決める状態の機械

状態の機械とは、今どの状態にいるか、どの出来事でどの状態へ移るかを、あらかじめ決めた表に沿って管理する仕組みです。Statewright では、作業の流れ（ワークフロー）を、調査・実装・試験・引き継ぎのような状態の並びとして定義します。READMEによると、計画の段階では読むことだけを許し、実装の段階で書き換えを許し、試験の段階では決められた命令だけを許す、といった分け方ができます。

判定の中心は Rust で書かれた部品で、READMEはこれを決まった入力に決まった結果を返し、判定の途中にAIを挟まないものだと説明しています。エージェントが「次に進みたい」と言っても、決められた条件を満たさなければ状態は移りません。たとえば「試験の結果が合格であること」を移る条件にできる、と書かれています。

つまり Statewright は、エージェントにやり方を教える道具ではなく、エージェントが今いる段階と、その段階でできることを外から決める道具です。手直しの繰り返しや、やり直しの回数の上限、承認の関門を流れの中に組み込めることも、READMEに記されています。

仕組み2：命令の見張り・書き換えの上限・承認の関門

道具の可否だけでなく、READMEはいくつかの細かな安全柵を挙げています。書き換えが許されていない段階では、命令を打つ道具が許されていても、ファイルへの書き込みや強い削除、別の言語の実行系を呼ぶ命令を止める。書き換えが許された段階でも、一度に変えてよい行数や、変えてよいファイルの数に上限を置ける。命令は、決めた名前で始まるものだけを通す許可の一覧にできる、とされています。

人の判断を挟む仕組みもあります。ある段階から次へ移るときに承認を必須にすると、その移り変わりは保留になり、人が確認するまで止まります。承認の画面には、要約や確認項目、関係するファイルをまとめた「証拠の包み」を添えられ、確認する人は、エージェントのやり取りの全部を見なくても判断できる形にしている、と説明されています。

ほかにも、特定のファイルが書き換えられたら確認の段階へ自動で移る仕組み、本番の接続先などの環境の値をエージェントから隠す仕組み、承認なしに権限が2段以上跳ね上がる流れを警告する検査が挙げられています。いずれもREADMEに記された機能で、記事の筆者が動かして確かめたものではありません。効き方は連携先と設定によって変わる点を、次の節以降で見ていきます。

仕組み3：判定・実行・連携の三つの層

READMEは、Statewright を三つの層で説明しています。一つ目は、状態の移り変わりと道具の制限を判定する中心の部品です。二つ目は、手元で動かす言語モデル（Ollama 経由）を決められた枠の中で走らせる実行の部品です。三つ目が、開発エージェントごとの違いを吸収する連携の層で、作業の記録、認証の情報、利用状況の報告、エージェントとの接続をまとめて受け持つ、とされています。

企業の担当者にとって重要なのは、三つ目の層です。実際に Claude Code や Codex のような開発エージェントに縛りをかけるのは、この連携の層と、MCPの中継の部品だからです。そして後で見るとおり、この連携の層と中継の部品は、中心の部品とは違うライセンスで公開されています。

また、連携の層は、ワークフローの保存や実行の記録を、提供元の管理クラウドか、自分で立てた環境のどちらかに置く前提で作られています。どちらにつなぐかで、データの置き場所も、契約の要否も変わります。三つの層のどこを使うのかを分けて考えると、検討の論点が整理しやすくなります。

段階ごとのモデルの切り替えと、公表された小さな実験

Statewright は、段階ごとに使う言語モデルを指定することもできます。READMEによると、診断は軽いモデル、修正の提案は強いモデル、といった割り振りを、対応した連携先で要求できます。ただしREADMEは、設定した要求は実行の証明ではないとし、実際に使われたモデルは応答の側で確かめるよう書いています。

READMEには小さな実験の結果も載っています。手元で動かす二つのモデルが、縛りなしでは10回中2回しか課題を終えられず、縛りありでは10回とも終えた、という報告です。ただし対象は、公開されたソフト修正の評価課題（全体で2294問）のうち5問だけで、READMEもこの結果はモデルの大きさの下限を示すものでも、失敗の理由を切り分けたものでもないと明記しています。

この実験は提供元自身によるもので、第三者が再現した結果は、確認した範囲では見当たりませんでした。数字は「縛りが小さなモデルの迷走を減らしうる」という手がかりとして読み、自社の作業でも同じ効果が出ると考えないことが大切です。効果を見込むなら、自社の課題で小さく測るのが確実です。

縛りの強さは連携先によって違う

Statewright を評価するうえで最も大事なのが、この点です。READMEの対応表は、連携先ごとに道具の制限の効き方が違うことを示しています。下の表は、READMEの記載を筆者がまとめたものです。

連携先	道具の制限の効き方（READMEの記載）	読み取れる注意点
Claude Code	エージェント側の許可の判定より前に確認する	確認の後にエージェント側で引数が書き換えられると、事前の確認なしに実行されうる。事後の照合で気づけるが防げない
Codex	エージェントが受け渡す道具の呼び出しの経路で止める	止められるのは見張っている経路に限られる
Cursor	専用の実行部品を通すと強く止める	単体で使う形は助言にとどまり、強制しない
OpenCode ほか	強く止める	連携部品の版が古い系統もある
独自のMCP環境	中継の道具は使える	遠隔でつなぐだけでは、エージェントの道具をすべて見張れるわけではない

READMEは、Claude Code について、確認の後にエージェント側で引数が書き換えられた場合は、事後の照合で気づけても、実行そのものは防げないと自ら書いています。また、Cursor を単体で使う形は「助言」にとどまり、遠隔でつなぐだけでは手元の道具をすべて見張れない、とも書かれています。

つまり、同じ Statewright でも、つなぎ方しだいで「止める仕組み」にも「注意を促す仕組み」にもなるということです。社内で「段階ごとに縛っているから安全」と説明するときは、どの連携先で、どの経路が見張られているのかまで確かめてから言う必要があります。エージェント側の本来の許可の設定は、Statewright とは別に残る、とも書かれています。

提供元の管理クラウドと、自前の運用の違い

READMEによると、提供元が運営する管理クラウドが、ワークフローの保存、実行の記録、MCPの中継の部品を受け持ちます。Claude Code や Codex の連携部品を使うときは、提供元のアカウントへのログインが求められる、と導入の手引きに書かれています。標準の使い方は、提供元のクラウドにつなぐ形だと読むのが妥当です。

料金の表もREADMEにあります。無料の枠はワークフロー3つ・状態の移り変わり月200回・記録の保存72時間、個人向けの有料の枠は早期割引で月9ドル（通常19ドル）、チーム向けは月99ドルでワークフロー30・月1万回・記録90日、企業向けは個別の見積もりです。料金と枠は変わる可能性があるため、検討の時点で提供元の最新の表を確かめてください。

一方で、中継の部品・ワークフローの編集画面・状態の保存の部品を、自社の環境で動かす自前の運用も案内されています。自前の運用の手引きは「クラウドへの依存なし」と説明していますが、ブラウザで承認する仕組みは、手元の環境には自動では付いてこないとも書かれています。また後で見るとおり、自前の運用ができる規模には、ライセンスの上で線が引かれています。

比べ方の目安も示しておきます。Statewright を入れるかどうかは、「管理クラウドを使う」「自前で動かす」「入れずにエージェントの本来の許可設定で管理する」の三つで比べると整理できます。下の表は、一次情報をもとにした一般的な整理です。

観点	管理クラウドを使う	自前で動かす	使わない（本来の許可設定のみ）
ワークフローと記録の置き場所	提供元のクラウド	自社の環境	なし（エージェント側の記録のみ）
段階ごとの縛り	使える。効き方は連携先しだい	使える。効き方は連携先しだい	段階の区切りはなく、許可は一律
承認の画面	提供元の画面で確認できる	手元の画面。ブラウザでの承認は自動では付かない	エージェント側の確認の仕組みのみ
契約・ライセンス	料金の枠に応じた契約	個人か一つのチームまで。全社の運用は商用の契約	追加の契約なし
運用の負担	提供元が受け持つ	更新・保守・保存の管理を自社が担う	許可の設定を保つ手間のみ

表から分かるのは、縛りの仕組みを手に入れる代わりに、データの置き場所か運用の負担のどちらかを引き受けるという構図です。社外に出したくない情報を扱うなら自前の運用が候補になりますが、全社に広げるならライセンスの条件と、保守を担う体制の両方を確かめる必要があります。

安全性の評価：注意付きとした根拠

このラインでは、ツールを手元に取り込んだり動かしたりせず、公開されている情報だけで安全性を判定しています。Statewright の判定は「注意付き」です。根拠は次のとおりです。

まず、問題の報告は見つかっていません。2026年10月23日の時点で、リポジトリに公開されたセキュリティ勧告はありませんでした。スターの増え方は1日あたり約2.9で、不自然に急な伸びではありません。取り込むと自動で動く処理の有無を外から調べた範囲でも、目立つ仕掛けは見当たらず、ひとまとめで起動するための設定ファイルがある程度でした。

一方で、注意を付けた理由が二つあります。一つは、GitHub の表示上のライセンスが「判定できない」となっていて、実際には複数のライセンスが混在し、一部がOSI承認ではない独自の条件であることです（次の節で詳しく見ます）。もう一つは、公開元の組織のアカウントがリポジトリの10日前に作られた新しいもので、会社名や所在地の記載がなく、運営の実績を外から確かめにくいことです。なお、問題が見つからなかったことは安全の保証ではありません。導入するなら、自社でも確かめてください。

ライセンスの注意：中心はApache-2.0、連携部品は独自条件のFSL

リポジトリの最上位にはライセンスの全文の文書がなく、全体の設定ファイルが Apache-2.0 と宣言しています。READMEも、判定の中心と実行の部品は Apache-2.0 だとしています。ここまでは、OSI承認のライセンスです。ところが、MCPの中継の部品と、開発エージェントとの連携部品（ディレクトリ全体）には、それぞれFSLのライセンス文書が置かれています。

FSLは、一定期間は競合する商用の利用を禁じ、期限が来ると Apache-2.0 に移るライセンスで、OSI承認ではありません。Statewright のものは移る日が2029年5月3日です。さらに見逃せないのは、標準のFSLに独自の条件が足されている点です。複数のチームや全社で使う形の運用は、提供元の商用の契約なしでは「競合する利用」に当たると書かれ、許される使い方として「個人の開発者の利用と、一つのチームでの自前の運用」が挙げられています。

加えて、提供元は米国で特許の仮出願をしており、特許の不行使を約束する文書を置いています。そこでも、個人や一つのチームの社内利用は対象とする一方、複数チームや全社の規模の運用には商用のライセンスが要ると明記されています。ライセンスの全文には鍵の仕組みを外したり回避したりしてはならない、という条項もあります。中心部分を使うだけなのか、連携部品まで使うのか、どの規模で使うのかで条件が変わるため、法務の確認が欠かせません。この記事が Statewright を「OSS」ではなく「ツール」と呼んでいるのは、このためです。

送られる情報と、診断の報告の扱い

提供元の文書によると、連携部品には任意の診断の報告の仕組みがあり、提供元のアカウントで選んだ設定に従います。報告に含まれるのは失敗の種類、操作の種類、連携部品の版、動いている環境、数値の状態などで、指示文、ソースコード、命令の中身、認証の情報、ファイルの場所は含めないと書かれています。手元の設定で止めることもでき、その場合はアカウント側で許可していても送られない、とされています。

ただし同じ文書は、一度送られた報告は設定を変えても取り消せないこと、受け取る側では通信の都合上、接続元の番号などを扱うこと、提供元のサイトでは操作の記録や基本的なアクセス解析が別に動くことも書いています。「中身は送らない」という説明と、「通信の痕跡は残る」という事実は両立すると理解しておくのが正確です。

もう一点、管理クラウドを使う場合は、承認の関門に添える「証拠の包み」のファイルが提供元へ上げられ、保存の期間は契約の枠で決まる、とREADMEにあります。ワークフローの定義や実行の記録もクラウドに置かれます。何がどこに置かれるかは、社外秘のコードを扱う現場ほど事前に確かめる必要があります。なお、READMEの末尾には提供元のサイトから読み込む極小の画像が埋め込まれており、閲覧の計測を目的としたものとみられますが、目的は確認できていません。

悪用されうるリスクと、縛りが外れる場面

Statewright は守りの道具ですが、使い方を誤ると、守られていると思い込む危うさを生みます。READMEは、縛りがきつすぎてエージェントが行き詰まったときの「非常口」として、縛りをすべて解除して全部の道具を通す機能があることを書いています。状態の移り変わりの条件を飛ばして任意の段階へ移る機能も、調査用の設定のときだけ使える形で用意されています。

これらは開発の現場では便利ですが、誰が解除してよいのかを決めておかないと、縛りが外れたまま作業が続き、記録の上では「段階管理あり」に見えるという状態になりかねません。また、エージェント自身にワークフローの定義を作らせる機能もあり、縛りの中身をエージェントが書く形になると、外側の決まりという前提が弱まります。

さらに、提供元のアカウントや連携部品の更新が、新たな入り口になる可能性も考えておくべきです。これは Statewright に限らず、開発エージェントに組み込む拡張全般に言えることです。現時点で悪用の報告は確認していませんが、縛りの仕組み自体が攻撃や誤設定の対象になりうるという目線は持っておく必要があります。ここに挙げたものは一般的な想定で、具体的な事例に基づくものではありません。

導入を検討するときに確かめること

Statewright のような段階管理の仕組みを検討するときは、機能の多さより先に、効き方・置き場所・契約の三点を確かめます。次の順で進めると、後からの食い違いを防げます。

企業が取るべき対策

一つ目は、段階管理を「主な防御」ではなく「重ねる防御の一枚」と位置づけることです。READMEのとおり、エージェント側の本来の許可の設定は別に残ります。Statewright を入れても、エージェントに渡す認証の情報を絞る、本番の接続先を持たせない、作業の環境を隔離する、といった基本は外せません。

二つ目は、社内の規程に「AIエージェントに段階ごとの縛りを掛けるときの決まり」を入れることです。どの段階で書き換えを許すか、どの移り変わりに人の承認を必須にするか、縛りを解除できるのは誰か、を文書にしておきます。三つ目は、記録の確認です。縛りが解除された時間、承認が保留された件数、拒否された道具の呼び出しを定期的に見て、縛りが実際に効いているかを、設定ではなく記録で確かめる習慣をつけます。

四つ目は、調達の段階での確認です。提供元の運営の実態、ライセンスの条件、データの置き場所と保存の期間、提供が止まったときの移行の手段を確かめます。公開元の組織は2026年4月に作られたばかりで、運営の実績を外から判断する材料は限られます。止める手段と、ワークフローの定義を手元に持ち出す手段を、入る前に確かめておくことが、新しい提供元のツールを使うときの基本です。

AIに任せる範囲と、人が決める範囲

Statewright の考え方は、「AIに判断させない部分を外側に固定する」ことにあります。この発想を生かすには、何を人が決めるかを先にはっきりさせる必要があります。次のような使い方は避けてください。

• 縛りの中身（段階の区切りや許す道具）を、エージェント自身に作らせてそのまま使う
• 連携先で縛りが「助言」にとどまるのに、「止める仕組みがある」と社内に説明する
• 縛りを解除する機能を誰でも使える状態にし、解除の記録を見ない
• 承認の関門に添えられた要約だけを読み、根拠のファイルを確かめずに承認する
• ライセンスの条件を確かめないまま、全社の基盤として広げる

人が決めるべきなのは、段階の区切り、各段階で許す道具、承認を必須にする移り変わり、解除できる人の四つです。AIに任せてよいのは、決められた段階の中での作業と、なぜその変更にしたのかの根拠を書くところまでです。承認の場面では、エージェントに根拠を書かせ、その根拠を人が読んで判断します。Statewright の承認の画面が要約と確認項目を添える作りになっているのも、この分担を前提にしたものと読めます。

よくある質問：段階管理を入れれば、エージェントの事故は防げるのか

答えは「減らす助けにはなるが、防ぎきる保証にはならない」です。縛りが強制として効くのは、連携先が道具の呼び出しを見張れる経路に限られます。Claude Code では確認の後の書き換えを事後にしか検出できないこと、Cursor の単体の形は助言にとどまることを、READMEが自ら書いています。

また、縛りの設計を誤れば、許すべきでない道具を許してしまいます。段階管理は、正しく設計され、記録で確かめられて初めて意味を持ちます。「段階で区切っているから安全」ではなく、区切りが正しいか、実際に効いているかを人が確かめ続けることが前提です。

• Statewright の機能・連携先ごとの効き方・料金・自前の運用・診断の報告の扱いは、GitHub のリポジトリ（README・変更履歴・リリースの一覧・セキュリティの欄・文書）と提供元の手引きを2026年10月23日に確かめた範囲に基づきます。版の更新で変わる可能性があります
• ライセンスは、全体の設定ファイル・中継の部品と連携部品のライセンス文書・特許の約束の文書を読んだ範囲での整理です。実際の利用の可否は、自社の法務で全文を確かめてください
• 提供元の運営体制、管理クラウドでのデータの保存場所の詳細、公表された実験の第三者による再現は、確認した一次情報の範囲では確かめられませんでした。この記事は導入や設定の手順を扱いません

まとめ

Statewright は、AIエージェントの作業を調査・実装・試験などの段階に分け、段階ごとに使える道具や命令、書き換えの量を絞るツールです。判定の中心はAIを使わない決まった仕組みで、承認の関門や環境の値を隠す仕組みも備えています。同じ道具を持ち続けるエージェントの危うさに、時間の軸で最小権限を当てはめる発想は、エージェントの統制を考えるうえで参考になります。

一方で、縛りの効き方は連携先によって違い、助言にとどまる形や、事前の確認をすり抜けうる場面があります。標準の使い方は提供元の管理クラウドにつなぐ形で、連携部品と中継の部品は独自の条件を足したFSLのため、全社での運用には商用の契約が要ります。公開元も新しい組織です。効き方・置き場所・契約を確かめ、段階の区切りと解除の権限は人が決め、記録で効き目を確かめることが、Statewright との現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。