Grok BotとJevの12ステップをunicodeさんが解説。AIに任せた仕事を最後まで持つ窓口と、完了の証拠と、人が承認する行動を先に決める

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。AIに仕事を任せたはずなのに、気づくと、次の指示と確認を自分が考え続けている。そんな場面がある人に向けて、今回は、unicodeさんのXのArticle「AI Company-in-a-Box」を紹介するね。Grok BotというBotの会社と、判断専用の小さなモデルJevをつなぐ、12ステップの設計図です。私は、この記事を、Botを足す話ではなく、任せた仕事を誰が最後まで持つのか、という話として読みました。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ02・Projects Managerに足す指示文）

Own coordination, not specialist execution.

元の記事を書いたのは、unicode（@unicodef1wn）さんです。

9月22日にXのArticleとして公開した英語の長文で、書き出しは「I didn’t build 12 AI employees. I installed them.」。

12人のAI社員を作ったのではなく、入れた、という一文です。

Grok Botのマーケットプレイスには、プロジェクト管理、エンジニア、デザイナー、ライター、採用、営業などのBotが、すでにそろっています。足りないのは、Botとあいだの判断だと言います。

次は誰に任せるのか。調べたことは十分か。続けるのか止めるのか。プロジェクトは本当に終わったのか。この行動に人の確認が要るのか。この5つです。

ステップ02で、話しかける相手を1つにします。選んだのはProjects Managerです。指示文の骨組みは、依頼を1つの目的に直す。足りない情報を洗い出す。誰が持つ部分かを決める。

専門の仕事は任せる。完了した仕事、証拠、詰まり、残りを追う。人に戻すのは、完了したとき、承認が要るとき、本当に詰まったときだけ、というものです。

同時にまとめた投稿にも、同じ形が出てきます。

0xMorlexさんは、SpaceXAIのエンジニアLauren Tanさんの46分の講演を要約して、「Chief of Staff starts routing work to specialist agents」（05:02）と書いています。

元の記事も、SpaceXAIの言葉として「People inside SpaceXAI often run multiple Bots in parallel, with one to manage the others」を引いています。

複数のBotのうち、1つが他を管理する形です。

窓口を1つにして最後まで持たせる、という考えは、私の10月6日の記事にもありました。

AI氣道『Grok BotとdotsのAI秘書で迷ったら、窓口を1人に決めて最初の週は下書きまでにする』より

「私が人にもAIにも委ねる時の軸に、一つのボールは誰か一人が全管轄してやり切る、というものがあります。複数人の共同責任にせず、所有者を一人にする。」

窓口を1つにして最後まで持たせる考えは、10月6日の記事、『Grok BotとdotsのAI秘書で迷ったら、窓口を1人に決めて最初の週は下書きまでにする』で書いています。

元の記事は、窓口に何を持たせるかを具体的に書いた設計で、私の記事は、人にもAIにも委ねるときの軸です。向きは同じに読めました。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ03・Jevの位置づけ）

Grok does the job. Jev decides where the job goes next.

元の記事は、窓口がもう1つ持っている問題を指します。窓口は、調整もするし、調整のなかの小さな判断も全部しています。誰が次か。調査は足りたか。これで終わりか。やり直すか。

こうした問いは、大きな言語モデルにもう1本長い文章を書かせることではなく、判断を出させることだ、という見立てです。

そこで使うのがJevです。TypeSafeという会社は、Jevを「unstructured state in, typed probabilistic decisions out.」と説明しています。

状態をそのまま入れると、型の決まった判断が返る、という意味です。文章を自由に書く代わりに、選ぶ、点をつける、分類する、振り分ける、確かめる、に絞ったモデルです。

答えの型は、次のとおりです。Choiceは、選択肢から1つを選び、確率と確信度を返します。Scoreは、順序のある尺度で評価します。Noulは、はい・いいえの問いに、「はい」の確率で答えます。

使い方の例では、今の状態と、決まったメニュー（Cooper、Writing Bot、Outbound Prospecting、人の確認など）を渡して、次に誰が動くかを選ばせます。

ステップ05では、メニューを「今ある物だけ」にします。動かせない担当は入れない。動画が無い案件に映像の担当は入れない。次の行動に人が要るなら、人の確認を入れる。

ステップ06では、いちばん先に自動化するのはこの振り分けだと言います。振り分けが悪ければ、書き手に触らずに直せる。書き手が悪ければ、振り分けに触らずに直せる。その分け方が、ポイントだと書かれています。

料理にたとえると、Jevは料理人ではなく、「次の皿をどの料理人に回すか」を決める配膳の人です。味つけや盛りつけは、料理人がします。

同時にまとめた投稿にも、近い話が出ています。

fladdictさんは、Elon Musk氏の「@SpaceX will use the best back end model for any given task」という投稿を見て、「GrokBotはフロントだけ取りに行って、後ろはいいとこ取り体制に。

」と受け止めました。仕事ごとに最適な担当を選ぶ、という点で、振り分けの考え方と並べて読めました。ここは私の読みです。

私の管制台の話も、並べておきます。9月20日のJevの特集（Jev活用事例まとめ。世界200件のプロジェクトから見えた5つの使い方）に書いた現状です。

届いた仕事をどのAIに渡すかを、いまはAI秘書が席表を読んで決めています。この層に、判定専用の部品を置く余地があるのかは、元の記事の提案を読んで考えたことで、私の運用で試した結果は、まだありません。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ04・tinkabotに渡す最初の指示文）

Do not let any tool execute the resulting action. The plugin only returns decisions.

ステップ04で、元の記事は小さな寄り道をします。Jevを窓口につなぐ部分を、自分でプログラムとして書くつもりだった。

ところが、マーケットプレイスに「tinkabot」というBotがあった、という話です。

tinkabotの仕事は、APIをMCPとskillsで包んで、データの形から始め、動く最小の雛形を作り、手元で動くことを確かめる、というものです。

だから、つなぎ込みの書き方を教える代わりに、tinkabotにTypeSafeの公式APIを渡して、「Jev Decision Layer」という判断プラグインを作らせる、という流れです。

API鍵は環境変数として保存し、コードにもログにも書かない、という決まりも添えられています。

プラグインに作らせる道具は4つです。1つ目のjev_route_workerは、目的、完了した仕事、詰まり、使える担当を渡して、次の担当を選びます。

2つ目のjev_check_researchは、主張、証拠、情報源の質、知られている食い違いを渡して、受け入れる、もう少し確かめる、退ける、の3択を返します。

3つ目のjev_review_completionは、元の目的、必要な成果物、完了した仕事、確認したこと、既知の抜けを渡して、完了、もう少し確かめる、未完了の3択を返します。

4つ目のjev_guard_actionは、提案された行動、対象、副作用、元に戻せるか、既存の承認の決まりを渡して、許可する、確認する、人が見る、拒否する、の4択を返します。

この指示文でいちばん大事なのは、最後の2行です。

「Do not let any tool execute the resulting action. The plugin only returns decisions.」。

どの道具も、出た判断にもとづく行動を実行してはいけない。プラグインは判断を返すだけ、という意味です。最後に、梱包する前に、安全な例を1つずつ手元で試す、とも書かれています。

元の記事は、仕組みの説明をこう締めます。TypeSafeのAPI、小さな判断プラグイン、Grok Botの道具。つなぐための魔法はない、という書き方です。

私の読みです。部品に実行の力を持たせないと、その部品が間違えたときの被害は、判定の間違いにとどまります。実行まで持たせた部品が間違えると、外に出てしまいます。

この分け方は、後の承認の段階の話ともつながっていると感じました。ここも、元の記事の設計を読んだ私の考えで、私が試した結果ではありません。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ07・調査の関所）

Jev is not the researcher. It only sees whatever state and evidence you give it.

ステップ07の見出しは、「Stop letting the researcher grade its own homework」です。調べた本人に、自分の宿題を採点させるな、という意味です。

ふつうの流れは、調査担当が主張を見つける。調査担当が、十分だと決める。書き手が出す。同じ担当、同じ文脈で進むので、同じ間違いが最後まで残ります。元の記事は、ここに関所を1つ入れます。

関所に渡すのは、主張、証拠（抜粋、リンク、日付）、情報源の質、知られている食い違いです。たとえば、「X社が昨日Yを出した」という主張に、企業の公式発表と、二次的な報道がある、という具合です。

返せる答えは、決まった形だけです。受け入れる、もう少し確かめる、退ける。

「もう少し確かめる」が返ったら、主張は調査に戻ります。「退ける」が返ったら、書き手には届きません。元の記事は、こう言います。ちゃんと確認してね、と書いておくより、弱い事実の行き先がある方がいい。

注意点も書かれています。Jevは調べる人ではありません。「It only sees whatever state and evidence you give it.」。

見えるのは、渡された状態と証拠だけです。だから、実際に情報を集める作業は、先に必要です。

私の運用でも、似た線を引いています。10月5日の記事で触れた話です。

AI氣道『Claude Modsで、Claude Codeの「終わり」を別の判定者に言わせるやり方』より

「このブログでも、公開する現物は、作った人と別の系統のモデルに検収させます。公開の最終GOは、私が持ちます。」

作った本人に採点させない考えは、10月5日の記事、『Claude Modsで、Claude Codeの「終わり」を別の判定者に言わせるやり方』で書いています。

元の記事の関所は、同じ仕組みの中にある別の部品です。私の運用は、作った人とは別の系統のモデルに頼む形で、置き場所が違います。それでも、作った本人に合否を言わせない、という点は同じ向きに見えました。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ08・完了の関所）

No proof, no done.

ステップ08は、長く動くAIの仕組みで、いちばん単純なのに、よく起きる失敗から始まります。AIが、終わった気がするから、終わったと言う。

そこで、窓口が人に仕事を返す前に、最後の状態を必ず作らせます。元の目的を書き直す。必要な成果物を全部挙げる。それぞれがどこにあるかを示す。実際に確かめたことを示す。既知の抜けを全部挙げる。

そのうえで完了の関所を通します。返る答えは、決まった形です。

完了なら、最終のパッケージを返す。もう少し確かめるなら、頼まれた確認をする。未完了なら、足りない担当を探して続ける。

そして1行、「Never remove a known gap just to make the review pass.」。通すために、知っている抜けを消してはいけない、という決まりです。

元の記事は、これを「No proof, no done.」という短い言葉にします。証拠がなければ、終わりではない。

もう1つ、元の記事が大事にしているのは、「Typed output does not mean factual correctness.」という区別です。

答えの形が決まっていても、中身が正しいとは限らない、という意味で、TypeSafe自身の文書にもある区別だと書かれています。

だからJevは、完了の「関所」であって、「Not an oracle.」、お告げをする存在ではない、という整理です。

同時にまとめた0xMorlexさんの投稿にも、同じ向きの言葉があります。講演の20:43の項目は「make agents prove their work before you review it」。

人が見る前に、エージェントに仕事の証拠を出させる、という意味です。

投稿の結びも、「agents can delegate, test, retry and return evidence before a human ever needs to step in」と、証拠を返すところで終わっています。

私の記事にも、完了の報告に混じっていた小さなずれの話があります。10月7日の記事です。

AI氣道『ChatGPT dotsに仕事を任せる前に、止まる4つの理由と完了条件の書き方を、みやびさんの記事から読む』より

「私の無人運用の記事の実機でも、報告は「確認したいこと：なし」なのに、記録にない価格が1か所、足されていました。」

完了と言われた報告にも、確かめる所が残る話は、10月7日の記事、『ChatGPT dotsに仕事を任せる前に、止まる4つの理由と完了条件の書き方を、みやびさんの記事から読む』で書いています。

報告の書き方が整っていても、中身に足されたものが混ざることがある。これは私の実機で見えたことです。

だからこそ、元の記事の「証拠を見てから完了と言う」関所は、人が最後に目を通す手間を減らす工夫として読めました。ただし、完了の関所を私が動かした結果は、まだありません。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ09・自律の5段階）

Jev can help classify the action. It should not magically erase the approval boundary.

ステップ09で、元の記事は、よくあるAIの会社のデモに釘を刺します。調べられる、というところから、メールもカードも顧客管理も本番環境も全部渡す、というところまで、一気に飛んでしまう。

そうではない、という立場です。

すでにマーケットプレイスのBotが、よい型を示している、とも書かれています。Outbound ProspectingとHaggle Botは、下書きまでで、承認なしには送らず、支払わない。

Recruiting CoordinatorとOffice Ops Deskも、人の承認なしには送らない。

SpaceXAIの自動化の指針も、送信、購入、削除、公開、本番の変更には承認を勧めている、とのことです。

そのうえで、行動を5つの段階にします。段階0は読む（検索、調査、分析）で、自動で動かします。段階1は準備する（下書き、ファイル作成、提案）で、これも自動です。

段階2は元に戻せる書き込み（下書きや社内文書の更新）で、Jevがリスクを評価できますが、プラットフォームの権限の決まりは今までどおりです。

段階3は外への行動（メールの送信、顧客への連絡、公開、本番アカウントの変更）で、人が承認します。段階4はお金と元に戻せない操作（購入、署名、削除、本番の変更、権限の変更）で、人が承認します。いつも、です。

最後の2行が、この段の要点です。

「Jev can help classify the action. It should not magically erase the approval boundary.」。

Jevは、行動の分類は手伝えるが、承認の境界を魔法のように消してはいけない、という意味です。元の記事は、「自律」を、全員にrootを渡すことではなく、この段階の切り方として組み立てる、と結んでいます。

私の運用でも、AIが人に確認を出していい場面を絞っています。10月3日の記事で触れた話です。

AI氣道『AIに任せる範囲はどこまで？6万人が使うSNSアプリを作る開発者が、Claude Codeで決めている線引き』より

「私の運用で、AIが確認を出していい場面は、4種類に絞ってあります。公開の最終判断、課金、削除のような戻せない操作、価値観や方針の判断。」

人に確認を出していい場面を絞る考えは、10月3日の記事、『AIに任せる範囲はどこまで？6万人が使うSNSアプリを作る開発者が、Claude Codeで決めている線引き』で書いています。

切り方は違います。元の記事は5段階で、私の記事は4種類の場面です。ただ、外に出る行動と、戻せない操作を、最後まで人の手に残す点は、同じ向きに読めました。ここは私の読みです。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ10・自動化の順番）

start with a one-time task → make it reliable → save the method as a skill → only then automate it.

ステップ10は、元の記事の中で、いちばん地味で、いちばん大事な決まりだと書かれています。一度きりの仕事として始める。確実に動くようにする。その方法をスキルとして保存する。そのあとで初めて自動化する。

この順番は、SpaceXAI自身の指針に由来する、とされています。

だから、40個の定期作業は作らず、5つから始めます。

朝の情報収集（Cooper）、記事づくり（Writing BotとSEO & AEO Desk）、営業の準備（Outbound Prospecting）、未解決の約束の確認（GTM Loop Closer）、会社の点検（Projects Manager）です。

どれも、調べる、下書きする、並べるところまでで、公開と送信の手前で止まります。

Grok Botの定期作業は、ノートPCを閉じていても裏で動きます。SpaceXAIは、有効にする前に試運転することを勧めています。つなげた道具で実際の仕事をしてしまうことがあるからです。

ステップ11は、梱包です。仕組みが動いたら、頭の中から出して、持ち運べる形にします。「company-in-a-box」のフォルダには、START-HERE、会社の方針、判断の方針、承認の決まり。

そしてbots、jev、routines、tests の4つのフォルダ。元の記事は、この4つを特に強調して、「会社は、1つのチャットに閉じ込めず、持ち運べるものに」と書きます。

ここにも注意があります。「a template is a blueprint, not an exact clone」。

Grok Botのテンプレートは、設計図であって、そっくりの複製ではない、という意味です。

指示、関連する記憶、スキル、対応するプラグインは含められますが、個人情報、秘密の鍵、独自のコードは含まれません。

私の10月2日の記事に、同じ順番の考えがあります。

AI氣道『AIエージェントに60点のままスキルを作らせない。1回分を手で直し切ってから量産する』より

「私の結論は、AIエージェントに60点のままスキルを作らせない、ことです。1回分を手で直し切ってから量産する。」

動いてから量産する順番は、10月2日の記事、『AIエージェントに60点のままスキルを作らせない。1回分を手で直し切ってから量産する』で書いています。

元の記事の「一度動いてから自動化」と、私の「手で直し切ってから量産」は、言い方は違いますが、順番は同じに読めました。ここも私の読みです。

unicodeさん（@unicodef1wn）「AI Company-in-a-Box: Full 12-Step Roadmap to Build a Self-Managing Company with Grok Bot + Jev」（X Article）（ステップ12のあと・測ること）

I’m intentionally not putting fake benchmark numbers here.

ステップ12は、試す課題の話です。「ツイートを書いて」のような課題で試しても、何も証明されない、と元の記事は言います。受け渡しが必要になる課題を出します。

例は、直近7日のAIエージェントの重要な動きを10件探す。重要な主張はすべて確かめる。

調査を、長文のArticle、SEOの下書き、画像の指示、関係しそうな会社の一覧と、5通の個別の連絡文の下書きにする。公開も送信もしない。

必要な成果物が全部そろい、確認を通ったときだけ、パッケージを返す。これなら、全員に仕事があります。

測るのは5つです。振り分けの正しさ。調査のすり抜け（根拠の足りない主張が書き手まで届いた数）。偽の完了（成果物が欠けているのに完了を通した頻度）。人への割り込み（安全に続けられたのに人を呼んだ回数）。

立ち直り（担当が失敗したとき、賢く再試行したか、止まったか）。

失敗は、新しいテストになる。「Every failure becomes a new test.」。窓口の指示文を4,000語長くするのではなく、そうやって仕組みを育てる、と書かれています。

ここで、元の記事を読むときの注意を1つ置きます。この記事には、動かした結果の数字が載っていません。

書き手自身が「I’m intentionally not putting fake benchmark numbers here.」と書き、途中にも、動かしていないなら点数を作るな、という注意があります。

冒頭は「入れた」ですが、中盤以降は「こうする」という設計の書き方が中心です。私は、12ステップが動いた証拠としてではなく、任せた仕事の途中を整える設計図として読みました。ここは私の読みです。

私が依頼してGrok Botで動かした実験は、別に2回あります。1回目は、過去の記事（Grok Botでビジネスシミュレーション｜AIの会社と顧客を動かしてみた）です。

Grok Botの中に会社と顧客AIを置いて、商売を動かすビジネスシミュレーションができました。ただし、これはこの12ステップを動かした話ではありません。

窓口や関所を置いて試したわけではないので、ここでは設計図として読むところまでにとどめます。

2回目は、2026年8月24日から26日にかけて、Grok Bot 0.24.0を実機で確かめた記録です。

説明だけで終わらせず、実際に試して判断するよう私が頼み、AI秘書がGrok Botに指示を出しました。公開しているメルマガの登録フォームにダミーの名前とメールを入れ、送信ボタンの手前で止めています。

途中でブラウザ操作が1回落ちましたが、Botが画面を操作し直して入力まで終わりました。

このとき、最初に失敗しています。note（文章の投稿サイト）の下書き作りを、ログインしていない別のBotに頼んでしまい、ログイン画面で止まりました。

原因は、Botごとに作業用のパソコンとログイン状態が分かれていることでした。Grok Botの限界ではなく、どのBotに頼むかの選び間違いです。

もう1つ、Botの「できました」という報告だけでは終わらせませんでした。

Botのチャットに付いた画面と、note編集画面のタイトル、下書きの状態、見出しの数、本文の画像の数を、突き合わせて確かめています。

元の記事の「窓口を1人に決める」と「完了の証拠」に近い体験として、私は読みました。ここは私の読みです。ブラウザ操作が落ちたのも含め、1回の成功で無停止の安定性までは証明していません。

ここからは、元の記事にはない、私の提案です。試した結果は、まだありません。今日の30分で、AIに任せている仕事を1つ選びます。最初の3分で、仕事を決める。次の5分で、窓口を1人に決める。

次の10分で、完了と言ってよい証拠を4点書く（目的、成果物、確かめたこと、既知の抜け）。次の7分で、人が承認する行動を3つ書き出す。最後の5分で、窓口への指示文を3行にまとめる。

見せる相手は、1人でも構いません。大事なのは、AIに足す前に、窓口と完了の条件と承認する行動を、一度書いておくことだと思います。

unicodeさんの記事は、AIの会社を、12人のAI社員としてではなく、出来合いのBotと、あいだの判断を受け持つ部品の組み合わせとして描きました。足りないのは、Botの数ではなく、次は誰か、調査は足りたか、終わったか、人が要る行動か、の判断です。

窓口を1つにする。調べた本人に採点させない関所を置く。証拠を見てから完了と言う。行動を5つの段階に分け、外に出る行動とお金は、必ず人が承認する。そして、1回動くまで自動化しない。元の記事の言葉では、「Bots do the work. Projects Manager coordinates. Jev makes bounded decisions. Humans own irreversible actions.」です。

ただし、元の記事には、動かした結果の数字がありません。私は、12ステップが動いた証拠としてではなく、任せた仕事の途中を整える設計図として読みました。私の過去記事の窓口、別の系統のモデルによる検収、確認を出す場面の絞り込みは、この設計図と、向きが同じに見えました。

最初の一歩は、今日の30分で、AIに任せている仕事を1つ選び、窓口を1人に決め、完了と言ってよい証拠を4点書き、人が承認する行動を3つ書き出すことです。元の記事にはない、私の提案で、試した結果はまだありません。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！