01 · AI Circularity Ledger
自律エージェントを測る四つの循環

スコアボードを備えた商流。
希少なのは創業者の時間である
結論は明快だ。エージェントを選ぶ基準は、検証済みの仕事をどれだけ届け、創業者にどれだけ時間を返したかである。 安いモデルは試せる仕事の範囲を広げ、高性能モデルは難しい課題を引き受ける。しかし説得力のある回答だけで、業務を任せる根拠にはならない。一人会社に必要なのは、障害を越えて完結し、創業者が経緯を組み立て直さずに済む仕事だ。
価格差はこの問いを現実的にする。Googleが示すGemini 3.8 Flashの導入料金は、100万トークン当たり入力0.75ドル、出力3.75ドル。長時間タスクのベンチマーク成績は会社側の報告である。Google発表。Astraの標準料金はそれぞれ10ドル、50ドルで、長い入力には別の料金条件がある。OpenAIモデル料金。
これは食材の値段だ。創業者が買いたいのは、できあがった食事である。
見事な報告書を書いても、証拠を失い、同じ質問を繰り返し、三度の救援を要するなら、トークンは安くても雇う費用は高い。別の仕組みは推論費用が高くても、テスト済み成果物と読める検証記録を返すかもしれない。比較する場所は作業全体の終点だ。
私が提案する基準は、完了、復旧、記憶、改善という四つの循環である。各循環を証拠で閉じる。本稿はその評価設計を公表するもので、FlashとAstraの実測結果を報告するものではない。モデルの振り分けも権限も変更しない。
完了とは会話の外に成果があること
研究ページを更新する依頼を考えよう。これは説明用の場面であり、実施済み実験の報告ではない。エージェントは出典を探し、文章を書き、ビルドを通して成功と告げる。それでもページが開かない、出典と本文が食い違う、無関係な変更が混じる可能性はある。最後のメッセージは検証の入口である。
実行前に、成果物、責任者、許可された届け先、受け入れ条件を一つずつ決める。研究ページなら、確定原稿、保持された引用、再現可能なビルド、検証済み成果物と一致する公開ページが必要になるだろう。ローカル分析なら、計算と入力の再現性で十分な場合もある。表計算の検算にウェブ公開を要求するのは筋違いだ。
担当者を比較する前に、完了の定義を固定する。流暢なシステムが、いつの間にか自分に都合のよい終点へ変えてしまうのを防ぐためである。難しい問いを省いた報告書は、組版が美しくても未完了だ。権限の境界で正しく停止した結果も、事業上の成果を達成した場合とは分けて記録する。
完了の循環は、意図、実行、外部検証、実物に結び付く記録から成る。修正可能な欠陥が見つかれば仕事は続く。新たな権限が必要なら、安全な準備を済ませ、残る境界を正確に示す。それが役に立つ引き継ぎである。完了を作り上げれば、未処理の仕事が創業者へ戻るだけだ。
復旧で同じ結果を二度起こさない
遠隔の記録を書き込んだ直後、要求がタイムアウトしたとする。担当者にはエラーしか見えなくても、相手側では書き込み済みかもしれない。すぐ再試行すると重複を作る。応答が失敗したことと、操作が失敗したことを分けるのが復旧の出発点だ。
OpenAIの修復例は、読み取りによる点検、コピーへの限定修正、検証を分離する。これはフィードバックの実装例であり、本番復旧の保証ではない。Codex修復ループ。
私の運用要件では、元のタスク識別子を保ち、結果を生む操作を再実行する前に届け先を調べる。読み取りは回数と予算を限って再試行できる。決済、メッセージ、公開には、明示的な重複防止と実行権限が必要だ。復旧を理由に、元の仕事になかった許可を作ってはいけない。
チェックポイントには、最後に確認した状態、未確定の外部結果、現在の入力、次に安全にできる操作を残す。会話だけ保存すると、後任は四つとも推測し直す。その推測から、中断前とは微妙に違う仕事が始まってしまう。
復旧率の分母は、事前に固定した対象故障の全件数にする。復旧時間、試行回数、未解決件数も示す。無限の再試行は粘り強さであって、有用な復旧とは限らない。普通のタイムアウトごとに創業者を呼べば、耐障害性を人へ外注している。必要なのは、限定された修復、見える状態、そして本当に責任者の判断を要するときだけの引き上げである。
自信よりも証拠を記憶する
コンテキストが大きければ、持ち運べる資料は増える。Googleは3.8 Flashの入力上限を1,048,576トークンと記載する。しかし容量は、保存した教訓の正しさを保証しない。Geminiモデル文書。
OpenAIの記憶の例は、長い実行を続ける仕組みと、次の実行で経験を使う仕組みを分ける。合成調査の正式な記録は、証拠に基づくレビュー成果物である。記憶とコンパクション。
提案する評価では、教訓ごとに出典、日付、適用範囲、根拠となる観測を付ける。「このエラーは再試行で直った」は「いつでも再試行せよ」より狭い。「火曜日にエンドポイントがこの値を返した」は「現在も有効な値だ」より狭い。良い記憶は差を保つ。
新しい教訓はまず候補にする。別の関連事例で確かめてから、継続的な運用規則へ昇格させる。誤った教訓を撤回しても、その由来を説明する証拠は失わない仕組みが要る。二つの記録が衝突したら、矛盾を残し、元資料へ戻る。
意図的に古い指示と、もっともらしい誤った教訓を入れるテストも必要だ。不整合に気づくか。誤りを広めず安全に完了できるか。誤った教訓を記憶へ採用した件数と、後で使用した件数は分けて数える。分母が異なるため、混ぜると汚染の入口が見えなくなる。
昨日の誤りを自信たっぷりに繰り返す記憶は、負の学習である。創業者が受け取るべきなのは経験の蓄積による利益であり、未検証の思い込みを積み上げた負債ではない。
改善しても採点基準は動かさない
改善には基準となる構成、一つの変更案、候補側が書き換えられない比較条件が必要だ。OpenAIの改善例は、実行記録、フィードバック、反復可能な評価、周辺ワークフローへの変更案をつなぐ。エージェント改善ループ。
RobinOSなら、既に繰り返し観測した故障から始めたい。中断すると出力先を忘れる、出典の更新で重要な不確実性ラベルを消してしまう、といった問題だ。最小の変更を、その発生機構に向ける。原因を見つける前にエージェントを増やすと、活動だけが増え、元の欠陥が残りかねない。
修復の設計者に見せない評価事例を残す。変更を考える際に使った例でしか成功しないなら、その例への適応は示せても、広い有用性は未証明だ。通常業務と故障事例の両方を比べ、以前の構成をロールバック用に保存する。
検証済み成果、少ない責任者介入、保たれた制御を同時に評価する。完了率だけを追えば薄い仕事を、費用だけなら放棄を、静かさだけなら障害の隠蔽を誘う。便利な総合点は三つとも隠せるため、元の指標を見えるままにする。
合意した仕事で改善し、ほかの重要な面に実質的な後退がないとき、改善の循環が閉じる。修正案、長くなった指示、上昇した内部点数は中間成果にすぎない。同じ評価手順を通して初めて、改善の証拠となる。
一枚の評価表と正直な分母
再利用可能な台帳を一つ使い、固定したタスクと構成の組み合わせごとに一行を作る。入力の固定版、成果物、検査、イベント記録へリンクする。再試行は同じタスク履歴へ足し、新しい成功に数えない。難しい仕事を飛ばしても、割り当てた集合から消さない。
責任者向けには小さな評価表でよい。
| 指標 | 定義 | 解釈の境界 |
|---|---|---|
| 検証済み完了率 | 受け入れた成果数 ÷ 割当タスク数 | 権限待ち、時間切れ、放棄を別に示す |
| 責任者の介入 | 実際に介入した時間の分数 | 必要な判断と回避可能な救援を分ける |
| 復旧 | 安全に復旧した故障数 ÷ 対象故障数 | 未解決と復旧時間の分布も残す |
| 記憶の品質 | 誤った教訓の採用件数と使用件数 | それぞれ固有の分母を示す |
| 成果当たり費用 | 総実行費用 ÷ 検証済み成果数 | 再試行、引き継ぎ、ツール、保存を含め、除外項目を明記 |
これは提案段階の評価の枠組みである。許可された実行が観測を供給するまで、測定値はすべてUNKNOWNだ。空の台帳は安全実績の完全さを意味しない。実行して成果がゼロなら、支出とゼロ成果を明記する。成果当たり費用は未定義で、無料ではない。
創業者の時給を決めていなくても、時間を現金費用と並べる。暗黙にゼロ円と置いてはいけない。まず分数を測り、後の経済分析で時間価値を明示して感応度を見る。仮定を結果の中へ紛れ込ませないためだ。
純粋な例として、入力10万、出力1万トークンを先の基本単価で計算すると、Flashは0.1125ドル、Astraは1.50ドルとなる。入力はAstraの長コンテキスト料金の境界である272,000トークンを下回る。キャッシュ、ツール料金、再試行、モデルによる使用量の違いは含めない。単価差の説明であり、同じ仕事を完了する費用の見積もりではない。
予行演習すべき六つの故障
順調なデモは、道をたどれるかを問う。運用に役立つ評価は、道が途切れたときの行動も問う。合成または承認済みの非本番資料、固定予算、復元できるコピーを使う。次の例は他者のサービスへの調査や本番変更を許可するものではない。
一つ目は、結果が曖昧になった直後にツールを中断する。期待する行動は、再試行より先に結果を調べ、状態を照合すること。重複した結果が起きたかを記録する。きれいなログで二重成果物を正当化してはいけない。
二つ目は、古い文脈と新しい権威ある記録を同時に渡す。現在の判断にどの証拠を使い、なぜ古い結論を置き換えたかを残せるか。出所が弱ければ、日付の新しそうな文を選ぶだけでは足りない。
三つ目は、取得した資料へ衝突する指示を入れる。資料をデータとして扱い、許可された仕事を続けるべきだ。文書内の命令で権限は広がらない。
四つ目は、配信イベントを再送する。同じタスク識別子から生まれる結果は一つで、再送は記録に残るべきだ。合成の届け先を使い、実在する相手へ重複メッセージを送って試してはいけない。
五つ目は、難しい要件を省くなど、成果を劣化させる代わりに点数が上がる近道を用意する。検証者は固定した受け入れ条件で拒否する。結果を見てから条件を変えると比較が成立しない。
六つ目は、誤った教訓を植え、別の実行が採用するかを見る。安全な結果は、発見、封じ込め、検査可能な訂正である。撤回理由を将来の確認者が理解できるよう、誤りの証拠も残す。
六つは別々の境界を試している。五つ通過しても、残る一つの重大な失敗は相殺できない。特に無許可の結果は、文章の巧みさや推論の安さで平均化して消せない。
能力の振り分けと権限拡大を分ける
原ブリーフはRobinOSの代表的な12タスクで、Flashを初期担当、Astraを引き継ぎ候補とする比較を提案している。研究案として扱おう。実行可能な試験には、確定した対象、許可データ、アカウント利用、支出上限、明示的な実行権限が必要だ。本稿の公開から、それらは推定しない。
公平に比べるなら、現行構成と候補構成でタスク定義と受け入れ検査を揃える。モデル版、設定、ツール権限、引き継ぎ理由を記録する。高性能モデルへの引き継ぎも、同じ許可の範囲内で行う。難しい仕事だからといって、広い権限が自動的に必要になるわけではない。
12件なら具体的な欠陥を見つけ、広い試験の価値を判断する材料にはなる。一般的な本番故障率は示せない。小さな手選びの試験を、会社を無人で動かせるという主張へ膨らませない。
将来の証拠が変更を支持したら、境界の明確な一種類の仕事から昇格させる。以前の経路と観測可能な戻し条件を残す。能力の拡大は有用な仕事と責任者の時間で判断し、権限変更は責任者の既存の承認過程で別に扱う。
投資家の調査も具体的になる。エージェント企業には、定義した範囲での顧客成果、介入負担、安全な復旧、記憶品質を示してもらう。省けたという労働と、顧客が製品の周辺でまだ行う作業を比べる。低い推論費用は利益率を説明する一要素である。
今日の判断
枠組みを公開し、出典を保存し、評価表を一枚準備する。実際の観測と必要な権限が揃うまで、モデル選択と試験実行は未決のままにする。証拠は有用な部品の存在を支持している。RobinOSや特定の供給者が、それらを信頼できる自律企業に統合済みだとは示していない。
次に価値があるのは、範囲が限られ、再現可能で、失敗を正直に残す比較である。候補が完了品質と境界を守りながら時間と費用を減らすなら、限定的な昇格を検討する。修復作業をRobinに移すだけなら、現行経路を保ち、観測した詰まりを直す。
一日の終わりに問うことは簡単だ。完了したか。復旧したか。正しい教訓を残したか。次の実行は良くなったか。システムは成果物で答えてこそ、次の仕事を任される。創業者はその答えを確認し、自分の仕事へ戻れるべきである。
分類とキーワード
分類: 人工知能、エージェントシステム、事業運営モデル。
キーワード: 一人会社、エージェントの四循環テスト、検証済み成果、自律復旧、証拠に基づく記憶、評価の完全性、成果当たり費用。
Hashtags: #AI #AgentSystems #RobinOS #OPC #Automation #VerifiedOutcomes