三つのエージェント労働日にも創業者は要る

三つの労働日は、まず供給能力の数字である

結論は単純だ。人間の1労働日当たり3エージェント労働日という数字が経営レバレッジになるのは、検証済みの成果を増やし、創業者への割り込みを減らすときである。 OpenAI Researchでは8月中旬までに、人間の1労働日当たり約3.1エージェント労働日が使われていた。コードと実験が増え、社内技術支援への需要は減った。一方、高度な計画はエージェント出力の一部にとどまり、成功した4〜8時間のタスクでも半数超が人間の介入を必要とした。OpenAIの研究データ。

二つの事実は一緒に読む必要がある。労働量の倍率は実在する。自律運営はまだ完成していない。一人会社は創業者の時間をはるかに上回る機械時間を買える。それでも創業者が配車係、例外処理係、査読者、記憶の修理係を兼ねるなら、経営能力は増えていない。

問うべきは同時に何体動かせるかではない。創業者の注意を1時間使うごとに、証拠、権限、復旧能力を損なわず、何件の受入済み成果を返せるかである。

本稿はその問いを10件の実験にする。今日は結果を記入しない。採点表は意図的に空欄とする。公開によってモデルの既定経路、有料API予算、本番権限は変わらない。固定した課題、固定した検査、実際の受領証がそろって初めて実験は証拠になる。

生産量と調整負担は同時に増え得る

エージェント労働は数えやすい。会話ごとに時間、トークン、ツール利用が残る。調整負担は記録の間へ隠れる。コードが増える一方で、確認待ち、曖昧な引き継ぎ、半完成の仕事も増え得る。中断のたびに創業者が意図を再構成するなら、出力量が増えても経営レバレッジにはならない。

OpenAIの資料は重要な分解を示す。エージェント利用は実験増加と社内支援の減少に相関し、生産性向上の仮説を支える。それでも長時間タスクでは人間の介入が多い。「成功」の内側に高価な創業者の修復が含まれ得るため、完了と独立性は別々に測るべきだ。

一人会社で希少なのは、所有者が中断されずに判断できる時間である。合計20分でも5回に分かれれば午前全体が壊れる。実験では介入時間と割り込み回数の両方を記録する。前者は労働量、後者は注意の断片化を測る。

滑らかな最終回答は十分な証拠ではない。証拠とは、入力、権限、検査、届け先と結ばれた受入済みの成果物である。会話が消えた後もその鎖を追える状態が必要だ。

限界価値でモデルを振り分ける

Astraの公開評価から候補となる役割が見える。OpenAIによるとOSWorldは72.6%対5.6 Solの65.7%で、所要時間は約47%短い。Terminal-Benchは57.9%対37.3%、DeepSWEは74.1%対72.7%で差が小さい。Astraの発表と評価。標準トークン料金はSolの2.5倍である。OpenAI API料金。

この数字が支えるのは振り分け仮説であり、全面交代ではない。仕事が明確で検査を決定論的に行えるならSolが通常実行を担う。複数ファイル、曖昧な意図、ツール障害、初回担当が復旧できない場面でAstraへ引き継ぐ。黙った誤りの損失が査読費用を上回る案件だけ最終レビューを加える。

10件の比較には少なくとも三つの経路を置く。Solが単独で完了する経路、Solの後に境界付きの救援資料をAstraへ渡す経路、決定論的検査の後にAstraが最終確認だけ行う経路である。受入条件は共通にし、完了担当、Robinの注意時間、全試行の総費用を記録する。トークン単価だけの比較では調達は語れても、経営は語れない。

実行前に終点を固定する

各課題には成果物を一つ、届け先を一つ、権限範囲を一つ、短い受入検査を一組置く。「サイトを改善する」では伸縮しすぎる。「4言語のcanonicalを直し、SEO検査と公開URLを確認し、DNSを変更しない」なら検証できる。

終点はモデルが仕事を見る前に固定する。そうしなければ、話のうまい実行者が、自分の終えた範囲に合わせて成功を定義し直せる。受領証には正確な成果物、コミットまたは不変のファイルハッシュ、テスト、公開・ローカルの確認、権限外として残った境界を記す。

権限境界で正しく停止する行動は安全上の合格であり、事業成果の完了とは別である。安全な準備をすべて終えてから判断を求めたかも測る。これで安全性と有用性を別の軸に保てる。

OpenAIの反復修復例は、対象を確認し、複製へ限定的な変更を加え、結果を検証する流れを示す。Codexの修復ループ。初回成果が説得力を持つ場合にも同じ規律を適用する。

復旧も製品の一部である

長い仕事は普通の理由で止まる。遠隔書き込み後のタイムアウト、編集中の情報源変更、ローカル構築成功後の配備失敗、受入条件を欠いた要約での引き継ぎなどだ。

復旧では最後に確認できた状態と、結果を重複させない次の操作を特定する。応答がないだけでは操作失敗を証明できない。公開、送信、支払い、遠隔書き込みを繰り返す前に届け先を調べるか、冪等性の記録を使う。読み取りは回数を限った再試行でよい。結果を伴う操作にはさらに強い重複防止が必要だ。

Astraへの救援資料には元の課題ID、固定した終点、許可範囲、確認済み成果、観測した障害、試した修復、次の安全な検査を入れる。最初の担当が失敗した理由について物語を作らない。救援に役立つのは証拠である。

復旧率は該当する障害だけで計算し、安全な復旧、未解決、所要時間、重複した結果を残す。最終的に成功しても遠隔効果を二重にした案件は安全な復旧ではない。通常のタイムアウトを毎回Robinへ返す構成は、耐障害性を創業者へ外注している。

検証はモデルの外に置く

出力したモデルは、なぜ正しいと考えるかを説明できる。その説明は診断に使える。唯一の受入検査にはできない。

モデルを替えても残る検査を選ぶ。スキーマ検証、テスト、ファイルハッシュ、構築結果、公開URL、内容カナリア、照合済み合計、そして判断が本当に必要な場合だけ人間の判断を使う。強いモデルは修復案を改善できる。結果を見て採点法を変える権限は持たない。

無許可の変更がないことも検証する。ページが200を返しても、秘密情報、無関係なファイル、権限の変更は正当化されない。受領証は変更対象を列挙し、ロールバックに必要な元の状態を守る。

OpenAIのエージェント改善例は、トレース、フィードバック、反復可能な評価を接続する。エージェント改善ループ。借りるべきものは手続きである。RobinOSの実務成績は、自身の課題と検査で走るまでUNKNOWNのままだ。

標語ではなく証拠を記憶する

閉じた循環は、次の振り分けを改善する教訓を残す。同時に、もっともらしい誤りが方針になるのを防ぐ。

候補となる記憶には情報源、日付、適用範囲、観測結果を付ける。「この読み取り専用URLは1回の再試行で一時的なタイムアウトから回復した」は証拠である。「常に再試行する」は標語である。次の操作が公開、送信、削除、支出なら差は大きい。

OpenAIのmemoryとcompactionの例は、同じ長期作業内の継続性と、後の作業で再利用する知識を分ける。記憶と圧縮。実験では両方を試す。圧縮した状態から同じ仕事を再開できるか。後の仕事で古い教訓を取り出し、期限切れの前提を持ち込まずに使えるか。

新しい教訓は試用状態に置き、別の関連事例で確認してから永続方針へ上げる。矛盾と元の記録は残す。誤った教訓が登録された件数と、後で使われた件数を分けて数える。前者は汚染、後者は損害を示す。

創業者が得るべきものは学習の複利であり、見えない運用上の迷信ではない。

再配分で循環が閉じる

最後の段階は記憶ではない。検証済みの経験で次の割当を変えることだ。

Solが安く確実に完了した種類は次回もSolへ渡す。特定の障害が繰り返しAstraの救援を必要とするなら、その種類は早く引き継ぐ。Astraの査読が十分な可比課題で重大な欠陥を見つけなければ、無作為検査を残しつつ査読頻度を下げられる。誤った記憶や黙った権限拡大が起きた場合、能力向上では統制劣化を埋め合わせられない。

ここで一人会社は会話の山から運営システムへ変わる。route、execute、recover、verify、remember、rerouteが測れる循環となり、各段階が次に使える小さな証拠を残す。

今週の10課題には、定型編集、複数ファイル診断、中断した処理、古い指示、曖昧な引き継ぎ、権限境界で正しく止まる課題を含める。結果を見る前に集合を固定する。RobinOSの現在の実務を優先し、人工的な器用さではなく価値ある仕事を測る。

創業者割り込み台帳

1課題を1行とし、すべての試行を同じ履歴に残す。再試行を新しい分母にしない。放棄した難題も割当済みに残す。

指標	定義	判断への用途
検証済み完了	受入成果 ÷ 10課題	停止・未解決も同時に表示する
初回完了	救援なしで受入れた課題 ÷ 割当課題	通常の信頼性と最終成功を分ける
自律復旧	安全に戻した該当障害	故障が機械と創業者のどちらへ戻るかを見る
創業者への割り込み	介入分数と割り込み回数	所有者労働と注意の断片化を測る
記憶品質	誤教訓の登録数と使用数	汚染地点と被害を分ける
成果当たり費用	全モデル・ツール費 ÷ 検証済み成果	再試行、救援、査読を含む
経過時間	開始から受領証まで	低接触が長い遅延を隠すのを防ぐ

観測値は事前入力しない。不明はUNKNOWNのままにする。検証済み成果がゼロの区分では支出とゼロ成果を記録し、成果当たり費用は未定義とする。

最初の10課題の判断規則

反対証拠が得られるまで現行経路を維持する。Astraの救援が検証済み完了を増やすか、Robinへの割り込み削減が全増分費用を上回り、権限、来歴、復旧、記憶品質に重大な後退がない場合だけ範囲を広げる。

集計前に課題ごとに確認する。簡単な仕事が多いと単一平均は誤った構成を褒める。定型、曖昧、復旧を分け、その後に全体を示す。モデル稼働時間と経過時間も併記する。安い仕事でも人間の再構成を6時間待つなら、高価で迅速な救援より経済性が悪い。

介入理由を判断、文脈不足、ツール障害、証拠修復、権限境界へ分類する。回避可能な分類だけが自律性の欠陥を示す。反実仮想も記録する。その介入がなければ受入れに到達したか。すでに合格する成果への助言と、完了に不可欠な救援は別である。分類ごとに元の受領証を結び、後の再評価を可能にする。

一度の鮮やかな救援でAstraを全面昇格させず、Solの想定外だった難題一件でSolを降格させない。課題種類ごとに比べ、小標本を明記し、未解決を残す。

最初の有用な結果は、調整負担が集まる場所の地図かもしれない。それだけでも課題設計は改善する。両モデルが失敗する曖昧な仕事は仕様の問題かもしれない。検査を通ってもRobinが満足しないなら、受入条件が誤っている可能性がある。実験は振り分けと運営契約の両方を改善すべきだ。

三つのエージェント労働日は有望な供給能力である。その時間を創業者へ返すかは、閉じた循環が決める。

分類とキーワード

分類： 人工知能；エージェントシステム；運営モデル；一人会社

キーワード： エージェント労働日；創業者割り込み；Astra；Sol；タスク配分；自律復旧；決定論的検証；証拠に基づく記憶；検証済み成果当たり費用

Hashtags: #AI #AgentSystems #RobinOS #OnePersonCompany #VerifiedOutcomes