— AI AGENT TRUST INFRASTRUCTURE / INTERNAL R&D
Netsujo Agent OS
AIに、任せられる仕事を増やす。
Netsujoは、AIエージェントの役割・権限・成果の証拠・停止と再開を、検証できる形にする信頼インフラを構築しています。Agent OSはそのための社内R&D基盤で、状態再構築、競合回避、独立QC、Exact-head検証、停止判断、復旧を継続的に検証しています。公開している実運転証拠は日付・対象を分けて示しており、このページ自体はControllerや各runtimeが現在常時稼働していることを意味しません。
公開中のAgent Role Contractsが確認するのは、役割・変更範囲・レビュー・引継ぎなどの宣言の整合性です。PASSは実行許可を意味せず、実際の認証・権限制御・副作用の制限は利用する実行環境側で担います。
AI DEVELOPMENT CONTROL PLANE
HUMAN
目的・制約・優先順位・例外判断
Netsujo AGENT OS
Reconstruct → Select → Assign → Verify → Gate → Recover
GitHub / Pull Request / CI / 実行環境のLive Stateと証拠を読み、必要な条件が揃わなければ止める。
WHY
AIを増やすだけでは、人間が新しいボトルネックになる
AIコーディングで実装速度は上がります。しかし複数のAIを並列で動かすと、進捗確認、担当割当、競合回避、レビュー、再検証、復旧という「AIを管理する仕事」が増えます。Netsujo Agent OSは、この管理負荷そのものを次の自動化対象として設計しました。
BEFORE
人間がAIオペレーターになる
「次はこれ」「このPRを確認」「止まっていないか」「誰が触っているか」を人間が一日中確認し、並列化するほど管理イベントも増えていきます。
AFTER
人間は目的と例外判断へ戻る
通常系の状態確認・割当・証拠検証・停止判定・復旧をControl Planeへ移し、人間は目的、優先順位、リスク許容度、不可逆な承認へ集中します。
ARCHITECTURE
AIチーム全体を制御するControl Plane
個々のAIモデルを賢くすることではなく、何を現在状態として信頼し、誰へ仕事を渡し、どの証拠で受け入れ、どこで止め、どう復旧するかを上位レイヤーで管理します。
WHAT IS ACTUALLY BUILT
概念図ではなく、8つの運用レイヤーとして実装しています
Agent OSの本体を単一のAIモデルに置かず、現在状態を決める場所、仕事を配る場所、実行するAI、独立検証、証拠、停止条件、復旧経路までを分離し、どこで何を保証するかを明示しています。
SOURCE OF TRUTH
GitHub Live State
main、PR、HEAD、CI、レビュー、担当状況を現在状態の正本として読みます。チャット履歴だけをタスク台帳にはしません。
CONTROLLER
定期起動と状態再構築
Controllerが現在状態を読み直し、次に進められる仕事、止めるべき仕事、人間へ戻すべき例外を判定します。
WORK ASSIGNMENT
担当範囲とLease
同じ領域へ複数writerを重ねないため、担当・対象HEAD・作業範囲を明示して競合を避けます。
EXECUTION
ChatGPT / Codex / Claude Code
設計、実装、調査、レビューをタスク特性に応じて割り振り、固定的な序列ではなく役割分担で動かします。
INDEPENDENT QC
実装者と別の検証経路
実装者の自己申告を受入条件にせず、別コンテキストのQCで互換性、回帰、運用リスクを確認します。
EVIDENCE
Exact-headの証拠
CI・QC・確認結果を特定SHAへ紐づけます。HEADが動けば古いPASSは受入証拠として再利用しません。
GATE
停止・棄却・再検証
GREENだから進めるのではなく、リスクと証拠を評価し、HIGHなら停止、効果が薄ければ変更自体を捨てます。
RECOVERY / PRODUCTION
復旧と不可逆操作の境界
セッション障害からLive Stateで復旧し、mergeやProductionは権限・承認を確認できる実行経路へ戻します。
CONTROL LOOP
「進める」だけでなく、「止める・捨てる・戻る」までを運用にする
01
Reconstruct
現在状態を再構築する
チャット上の記憶ではなく、GitHub・Pull Request・CIなどのLive Stateを読み直し、行動前に「今どうなっているか」を確定します。
02
Select
次に進める仕事を選ぶ
優先順位、依存関係、担当中の作業を確認し、競合せず安全に進められる次のタスクを選定します。
03
Assign
AIへ役割を割り当てる
ChatGPT、Codex、Claude Codeなどを固定的な序列ではなく、タスク特性に応じて使い分けます。同じ領域へ複数writerを重ねません。
04
Verify
独立して検証する
実装者自身の「できた」を完成条件にせず、別コンテキストのIndependent QCと特定HEADに紐づく証拠で確認します。
05
Gate
危険なら止める
CIが通っていても独立QCがHIGHなら止めます。HEADが動けば古いPASSを無効化し、必要な証拠が揃うまで状態遷移させません。
06
Recover
途中から復旧する
セッションやチャットが途切れても、GitHubをSource of Truthとして状態を読み直し、重複作業を避けながら再開します。
PROOF OF OPERATION
約5か月の運用記録と9/8〜9の制御判断で、何を制御してきたか
AI開発・運用の履歴スナップショットは2026年3月27日〜9月7日です。STOP・RECHECK・DISCARD・RECOVERの代表的な制御判断は9月8〜9日の別枠ケースとして示します。merged PRなどの集計値は9月21日20:24 JSTに同一8リポジトリを再集計しています。期間の異なる証拠を混ぜず、どの条件で進め、止め、証拠を取り直し、復旧したかを示します。
3/27〜9/7
AI開発・運用の履歴スナップショット
9/8〜9/9
制御判断ケース
8 repositories
9/21にmerged PRを再集計
Exact-head
CI・QC・reviewを特定SHAへ固定
PUBLIC EVIDENCE LEDGER
主張を、制御・QC・判断まで分解する
集計資料だけに依存せず、代表的な運用判断を公開可能な制御・QC重大度・最終判断へ分解します。元の運用リポジトリは現在privateのため、PR番号・commit SHA・Actions run ID・内部defect詳細は公開台帳へ出さず、public-safe summaryだけを機械可読化しています。
GREENの後にHIGHを見つけ、受入を止めた
- EVIDENCE
- ・Hosted CI: PASS
- ・Post-CI Independent QC: BLOCKED / HIGH
- ・Repair hosted CI: PASS
- ・Repair QC: PASS / LOW / OPEN_MEDIUM_HIGH=0
- DECISION
- STOP → REPAIR → RECHECK → PASS
途中candidateを受け入れず、最終candidateを再検証した
- EVIDENCE
- ・Intermediate candidate: hosted CI FAIL
- ・Intermediate candidate: Independent QC BLOCK / MEDIUM
- ・Final hosted CI: PASS
- ・Final Independent QC: PASS / LOW
- DECISION
- RECHECK → MERGE ACCEPTED FINAL CANDIDATE ONLY
約1秒の高速化より、正しさを優先して変更を捨てた
- EVIDENCE
- ・Observed checkout: 約8秒 → 約7秒
- ・Independent QC: BLOCKED / HIGH
- ・Integration safety: NOT SUFFICIENTLY PROVEN
- ・Final state: CLOSED / UNMERGED
- DECISION
- DISCARD
CIがGREENでも、HIGHなら止める
ORCHESTRATORの実運転ではLinux/DarwinのHosted CI通過後に独立QCでHIGHの互換性問題を検出し、Ready・merge・deploy・Productionを停止しました。
HEADが変われば、検証を取り直す
SIGNALの変更では中間HEADを受入対象から外し、最終HEADに対してconformance・customer access・独立QCなどを取り直してからmergeしました。
速くても、割に合わなければ捨てる
miyakodeitのCI改善候補は約1秒の短縮に対してcorrectness上のHIGHリスクが見つかり、不採用としました。変更を作ることより、採らない判断を優先します。
チャットが切れても、Live Stateから戻る
Recovery Checkpointでは、会話履歴を唯一のタスク台帳にしません。セッション障害後もGitHubの現在状態を読み直し、担当と証拠を再構築します。
※ 運用履歴は2026年9月7日まで、制御判断ケースは9月8〜9日、集計値は9月21日20:24 JST時点です。人間実介入時間を含む未計測値は推測で補いません。
出典：Agent OS 公開実績資料INITIAL CASE STUDY / 24H
初期24時間は、4つの制御判断を検証したケーススタディとして残す
長期実績の主根拠は上の公開実績資料へ移しました。以下は、Agent OS初期段階でSTOP・RECHECK・DISCARD・RECOVERが実際に働いた過程を追えるケーススタディです。
Chat failureからLive Stateで復旧
Recovery Checkpointで、過去チャットを唯一の台帳にせず、main・PR・HEAD・CI・担当状況をGitHubから再構築する原則を固定しました。
ORCHESTRATORの受入を停止
Linux / DarwinのHosted CIは通過していましたが、独立QCで既存データ互換性のHIGHを検出。Ready・merge・deploy・Productionを止めました。
約1秒のCI高速化を不採用
miyakodeitのCI改善候補はcheckoutが約8秒から7秒になった一方、merge base取得にHIGHリスクがあり、約1秒の改善のために正しさを危険にさらさない判断をしました。
SIGNALは最終HEADだけを受入
途中HEADのPASSを流用せず、最終候補のHEADに対して必要な検証を取り直し、条件が揃った候補だけをmergeしました。
CAPABILITY
Agent OSが示す、Netsujoの開発能力
ここで示すのはAIツールの利用回数ではなく、複数の実行主体、変化する状態、品質証拠、停止条件を一つの運用として設計し、改善し続ける能力です。
曖昧な課題を実装単位へ落とす
目的・制約・完了条件を分解し、AIが安全に扱える作業単位へ変換します。
複数AIを競合させずに並列化する
実装・調査・レビューを分け、担当範囲と現在HEADを明確にして同時進行させます。
品質を「自己申告」から切り離す
Independent QC、CI、Exact-head evidenceを組み合わせ、実装者の報告だけで受け入れません。
異常時に止まり、復旧できる
停止条件とRecovery Checkpointを設計し、セッション障害や状態ずれから再構築できます。
技術判断を事業判断につなげる
「作れるか」だけでなく、効果とリスクを比較し、採用・不採用まで含めて意思決定します。
運用知を再利用可能な仕組みにする
一度起きた事故や注意を、次回はルール・Gate・検査として再発防止へ変換します。
NOT JUST AI CODING
AIコーディングツールを使うことと、AI開発チームを運用することは違う
| 比較項目 | AIコーディング単体 | 複数AIを人間が管理 | Netsujo Agent OS |
|---|---|---|---|
| コード・タスクの実行 | ○ | ○ | ○ |
| 複数AIの並列運用 | △ | ○ | ○ |
| 担当競合の回避 | × | 人間が調整 | Lease / Scopeで制御 |
| 独立QC | × | 手動 | 別コンテキストで実行 |
| 検証対象の固定 | × | 手動確認 | Exact-head Evidence |
| 危険な変更の停止 | 人間判断 | 人間判断 | Gateで停止条件を運用 |
| セッション障害からの復旧 | やり直し | 人間が再説明 | GitHub Live Stateから再構築 |
| 継続運転 | 人間の指示待ち | 管理者に依存 | Controllerが通常系を継続 |
APPLIED TO CLIENT WORK
この実運転で得た設計能力を、顧客のAI導入へ転用する
目的はAgent OSそのものの販売ではなく、自社で複雑なAI運用を組み、失敗からルールを更新してきた経験を、AI導入・PoC・開発運用・ガバナンス設計へ還元することです。
AIエージェント開発運用
複数のAIや開発者を安全に並列化し、担当、QC、受入、復旧までを運用設計します。
社内AI業務基盤
複数LLM・ツール・データソースを使う業務で、状態、権限、承認、例外処理を設計します。
AIガバナンス / 品質ゲート
AIの自己申告ではなく、証拠、承認、監査可能性を受入条件へ組み込みます。
PoCから本番運用への移行
「動いた」で終わらず、障害時の停止・復旧・監視・責任分界まで含めて本番化します。
AI開発プロセスの標準化
属人的なプロンプトや注意事項を、再利用できるRule・Gate・Runbookへ変換します。
AIを使う組織設計
人間に残す判断とAIへ渡す通常系を分け、管理負荷を増やさずに実行能力を上げます。
HUMAN IN THE LOOP
人間を消すのではなく、判断の場所を変える
Agent OSが目指しているのはHuman-lessではなくHuman-on-exceptionです。定型的な状態確認や検証は機械へ寄せますが、事業責任と不可逆な判断までAIへ委ねません。
HUMAN KEEPS
- 事業の目的と優先順位
- 許容できるリスクと例外判断
- 顧客・契約・一次情報に関する判断
- 不可逆な操作に必要な承認
OPEN DEVELOPMENT RECORD
設計だけでなく、失敗と運用記録も公開しています
Agent OSという名称は完成品を装うためではなく、実運転で起きた失敗、停止判断、設計変更を記事として残し、仕組みそのものを更新し続けるために使っています。
FROM INTERNAL CAPABILITY TO YOUR BUSINESS
AIを導入するだけでなく、運用できる仕組みまで設計する
生成AIのPoC、AIを組み込んだ業務設計、複数エージェントを使う開発運用まで、Netsujo自身の実運転で得た知見をもとに支援します。