AI エージェントが三日がかりで作業中。夕方 6 時、この案件の担当は誰ですか

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。

エージェントが数時間から数日かかる仕事を受け持つようになると、これまでのソフトウェアでは考えずに済んだ問いが出てきます。エージェントが作業しているあいだ、その案件の担当は誰なのか。依頼した人か、画面を開いた人か。そして夕方 6 時にその人が帰ったら、誰が引き継ぐのか。

「みんなで共有」では監査に答えられない

よく聞くのは、エージェントを共有ドキュメントのようにチームで開き、誰でも様子を見て書き込めるようにする、という答えです。見るにはそれで十分です。困るのはその先で、五人が書き込んだあとにエージェントが返金を実行したら、誰がそう指示したことになるのか。「チームで」も「ログインしていた人」も、監査への答えにはなりません。

GembaOS はこの二つを分けます。見るのは自由。動かすには名前が一つ要ります。

見る：閲覧できる人なら誰でも

作業票のページには、実況のパネルがあります。担当者、今その案件を開いている人、エージェントが今どの手順にいるかが表示され、一行目に「これは実況です。記録は下のタイムラインです」とあります。見ていることは記録に残しません。見ることは操作ではないからです。

指示する：担当者だけ

案件の担当者は常に一人です。既定では依頼した本人が担当なので、設定は要りません。エージェントに指示できるのは担当者だけで、指示は三種類です。

• 補足：エージェントが知らなかったこと（「経理の規程では返金額は四捨五入です」）。
• 絞り込み：任された範囲より狭い範囲。
• 向け直し：Playbook が認める範囲での、別の対象。

エージェントは次の手順で指示を読みます。実行中の手順を途中で止めることはしません。今すぐ止めたいときは、担当者が保留し、指示し、再開します。三つとも担当者の名前で記録されます。指示で変わるのはエージェントが「試みること」で、「許されること」は変わりません。ツールの追加も、上限の引き上げも、稟議の省略もできません。そうした確認はすべて、エージェントが指示を読んだあとに行われるからです。

引き継ぐ：二人で、記録に残して

終業時、担当者は理由を添えて同僚に引き継ぎを打診します。同僚の机には「引き継ぎを打診されている案件」として表示されます。同僚が引き受けるまで担当は移らず、一日たっても引き受けられない打診は失効します。「ログオフしたから次の人のもの」ということはありません。誰も引き受けていない案件は元の担当者のままで、記録にもそう残ります。

以下の画面は、この記事の最後に紹介するデモを一回動かしたときのものです。デモのモデルは台本どおりに動くスタブですが、担当、指示、引き継ぎ、押印は製品そのものの動きで、本物のモデルでも同じです。

エンジニアの佐藤 健さんが、失敗しているテストの修正をエージェントに依頼しました。作業中に一言補足を送り、夕方 6 時、修正がコードオーナーの押印待ちになったところで、山田 美咲さんに引き継ぎを打診しました。これが山田さんの机です。

山田さんは案件を開いて引き受けました。パネルでは担当が山田さん（引き継ぎ済み）になり、閲覧中の二人が表示され、指示の欄は山田さんにだけ開いています。

見ている人は誰でも、この作業についてアシスタントに聞けます。アシスタントは質問した本人の権限で答え、回答は本人にだけ表示されます。担当者はその回答を自分の指示に使えますが、閲覧しているだけの人は使えません。担当者の名前が付かないまま回答がエージェントへの指示になることはありません。作業票のタイムラインには質問したことだけが残り、回答そのものは本人の手元に残ります。（デモのモデルは stub なので、ここでの回答は、見せられた作業の範囲を伝えるだけです。）

押印者は移っていない

この修正はコード所有者の管理するパスに触れるので、決裁ルートではコードオーナーが押印します。引き継ぎで変わったのは担当で、押印者ではありません。稟議書の「残る決定はひとつ」は、引き継ぎのあとも「コードオーナー の押印」のままで、一覧には小川 直子さんの名前があります。

これは意図した設計です。誰が押印するかは、会社が設定した決裁ルートと組織図から決まります。それを決める GembaOS の部分は、誰が担当か、誰が見ているかを参照しません。参照するようになればテストが失敗します。逆向きの規則もあります。引き継ぎや引き取りで担当になった人は、通常の決裁区分ではその稟議に押印できません。案件の進め方に関わった人だからです。依頼者本人が自分の依頼に押印できないのと同じ理由です。

コードオーナーの押印後、作業票のタイムラインにはこれまでの動きがすべて名前付きで並びます。佐藤さんの指示、エージェントの各段階がそれを読んだこと、佐藤さんから山田さんへの打診、担当の移動、小川さんの押印、そしてマージです。

指示が三回読まれているのは、調査する担当エージェント、修正案を作る担当エージェント、それを確認する係長エージェントが、それぞれ別にモデルとのやり取りを始めるからです。三者とも担当者の言葉を受け取ります。

しないこと

• その場にいることを権限にしない。 画面を開いていても、押印も指示もできません。
• 二人の指示を突き合わせて勝ち負けを決めない。 指示が食い違ったとき、Playbook が認めていればエージェントはそう申告し、判断は担当者に戻ります。エージェントは決めません。
• エージェントの範囲を広げない。 Playbook が認めない向け直しは、それ自身の稟議を持つ別の作業票です。
• 公開デモでは試せません。 公開デモの利用者には名前がなく、名前のない担当者こそ、この仕組みが防ぐものだからです。画面はローカルのデモで撮りました。各人が本人としてサインインできます。gemba demo を起動し、社員ページを二人の社員として開き、不具合の修正を依頼してください。

---

アーキテクト向け

• 記録に残る：指示、打診、引き受け、引き取り、保留、キャンセルは、それぞれ作業票のハッシュチェーン記録上のイベントで、操作した人の名前と、必要な操作では理由が付きます。
• 指示の文面も信用しない：外から届くメッセージと同じ注入検査を通ります。
• 名前のあるログインだけ：共有の運用者パスワードのように本人に結び付かないログインは、案件を見ることはできても、担当になること、指示すること、引き継ぐことはできません。