解説記事
そのルールは効いているか――案件から確かめ、名前のある手続きで変える
押印なしで通る帯に責任を持つ業務責任者、抽出点検を頼まれる担当者、そして何がルールを変えられて何が変えられないかを確かめたいリスク管理・監査の担当者向けです。
GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。
押印なしで通る帯は、会社が決めた見込みです。この金額以下、このリスク以下なら、誰も押印しなくてよい。「返金の大半はルールで通った」というのは、帯がうまく働いているときの姿であり、同時に、帯が関門の役目をやめてしまったときの姿でもあります。数字だけでは見分けられません。このノートでは、ルールに責任を持つ人がどちらなのかを確かめる手立てと、変える必要があるときの変え方を説明します。
線を引く場所は、「照会可能な会社」のノートと同じです。与えられた権限の中で、エージェントは仕事をどんどん上手にこなしていきます。けれども権限そのもの――誰が押印するか、どんな条件なら押印なしで通るか、何に触れてよいか――は、別の人が承認する公開でしか変わりません。以下はどれも、その人のための材料をつくるもので、それ自体が権限を変えることはありません。
1. 判断を受け持つ人に聞く
GembaOS は、押印なしで通った判断をハッシュで抜き出し、その判断を受け持つ職位の人に一件ずつ回します。点検者に見えるのは、その判断が当時前にしていたものです。操作、引数、読んだリスクと事実、通したルールと、そのルールを確認した人。その後に起きたことは見せません。問うているのは判断であって、結果ではないからです。
問いはいつも同じです。この判断が当時あなたの前にあったら、押印なしで通すことに同意しましたか。答えは、同意した・同意しなかった・判断できない、の三つです。同意しなかったときは手順書が宣言した理由の一覧から一つ選び、一文を添えます。答えは点検者の名前で記録されます。二人の意見が分かれれば二つの記録になり、多数決はしません。作業票を依頼した本人は点検できません。
答えがルールを変えることはありません。数えられるだけです。
2. 案件が終わった後を見る
これまで案件の記録は、処理が実行されたところで終わっていました。手順書は、終了後に何を見るかを書けるようになりました。見る先は三つのうちどれか一つです。終了から何日か後にシステムの項目を一度読む、同じ対象について新しく来た作業票を数える、指定した職位の人が入力する。期限前のもの、読めないもの、判断できないものは不明のまま残り、良い結果として数えることはありません。同じ結果を二度数えることはなく、結果が何かを動かすこともありません。
3. 案件をまたいで聞く――読める範囲の中で
「先月の返金はどうだったか、点検者は何と言っているか」には、尋ねた人の権限で動く読取り専用の操作で答えます。答えは業務ごとにまとめ、人や顧客ごとにはまとめません。数えるのは、尋ねた人がそのデータを読める業務だけです。会社は表示する最少件数を決められ、それを下回る数は出しません。決めていなければ、答えにそう書かれます。どの答えにも、見えていない部分が書かれます。GembaOS がつながっていない経路、尋ねた人には見えない業務、そして抽出点検がハッシュによる抜き出しであって割合ではないこと。
4. 入力が動いたことに気づく
帯の条件を変えられるのは公開だけで、公開は検査され、押印されます。公開が決して見ないのは、同じ条件のまま入力のほうが動くことです。上流のシステムがリスクの点数を付け直すと、線の下に入る案件が増え、押印なしの比率は、帯がうまく働いているときとまったく同じように上がります。
手順書には、その比率がどこまで動いてよいかを書けます。GembaOS は一日に一度、経路ごとに、押印なしで通った割合を直近の期間と一つ前の期間で比べます。幅を超えて動けば、業務の責任者に向けて不足台帳に一件挙げます。そこには両方の割合と、二つの期間でルールの版が同じだったかどうかが書かれます。同じなら動いたのは入力で、違うなら公開が帯を動かしたので、それが意図どおりかを責任者が確かめます。何も厳しくはしません。
5. ルール自身に止まる条件を書く
挙がった記録も点検の答えも助言にすぎず、責任者が読んでいる間も帯は動き続けます。そこで帯の条件は、GembaOS が不足台帳から求める二つの事実を読めるようにしました。最近の「同意しなかった」の数と、誰も解決していない比率の変動です。参考の返金では、30 日のうちに「同意しなかった」が二回あるか、未解決の変動が一件あれば、少額の返金はルールではなくカスタマーサポートの責任者の押印に回ります。答えが期間を過ぎ、変動の記録が解決されれば、元に戻ります。早めに戻すことや数字を変えることは、公開です。
これは会社が公開し、別の人が承認した条件で、ほかの条件と同じように経路図に描かれます。働く向きは一方だけです。点検者の答えが帯を閉じることはあっても、開けることはありません。
6. 誰が何をするかを経路から読む
「人がやる」から「AI がやる」までのスライダーがほしい、と言われることがあります。GembaOS にそれはありません。一つの目盛りが、誰が動くか、誰が押印するか、何が対象かをまとめて動かしてしまうからです。代わりに経路図が帯ごとに読み出します。決める材料を誰が準備するか(AI、ある職位の人、記録をもとに GembaOS)、誰が決めるか(確認済みのルール、順番どおりの押印者、自分の行為に自分で押印する人)、誰が実行するか。経路そのものから読むので、食い違う設定がもう一つあるということはありません。人が受け持つ手順は、項目を選んで変更のフォームで、設定にすでにある指示ファイルを選んで AI に戻せます。押印者はそのままです。帯を再び押印なしにするのは別の変更で、名前を添えて確認します。
7. 人がいつも押印しているものに気づく
ルールが人の押印に回した判断も数えられます。GembaOS はそれを業務と帯ごとにまとめ、さらに手順書が宣言した特徴――事実、選択肢や「はい/いいえ」として宣言した引数、リスクの標識――ごとに分けて、承認・却下・差戻し・期限切れの件数を出します。金額や点数は幅だけを示します。特徴ごとに、帯の条件がそれを読んでいるかどうかを添えます。この答えはルールそのものから読み取るもので、モデルには判断させません。
誰も書き留めていなかった傾向は、こうして見えてきます。たとえば、写真の付いた少額の返金を責任者がほぼすべて承認しているのに、返金のルールは添付を一度も見ていない。集計にはその組が現れ、ルールがそれを読んでいないことも示されます。
業務の振り返りは、これを規則の候補にできます。緩める方向か締める方向か、一回の振り返りで三つまでで、どの組に基づくか、何が分からないかを書きます。GembaOS は、その組が実際にその集計から返ってきたこと、最少件数を下回って隠されたものでないこと、ルールがまだ読んでいない特徴であることを確かめ、そのうえで数字を自分で候補に写します。モデルが件数を書くことはありません。参考の会社では、この振り返りを月に一度動かしています。
候補は、その業務の責任を持つ職位の人に届き、確認するか見送るかを決めます。確認してもルールは変わりません。組織設計アシスタントが、数字ごと候補を下書きの根拠として引けるようになるだけで、下書きはほかの公開と同じく、記録済みの判定で検査され、別の人の承認を経ます。確認した人は自分の机から確認を取り消せ、取り消せばその候補に基づく下書きは承認できなくなります。
みんなが承認しているということ自体は、理由になりません。読まずに押印しているのかもしれず、どの答えにもそう書かれます。
8. ルールを変える――検査し、試し、広げる
ルールの変更は公開です。検査は、記録済みの判定を、何も再送せずに下書きで判定し直します。下書きが事実を加える場合――たとえば案件に何件のファイルがあるか――GembaOS はその事実を、判定した時点の各案件の記録から求め直します。記録から求められない案件は「比較できない」として挙げ、変更とは数えません。
管理者が選んだ場合だけ、さらに二つの段階が使えます。どちらも既定では無効です。
- 下書きを最近の実案件で動かす。 下書きが関わる業務で最近終了した案件を、割り当て済みのモデルで下書きのルールのもと処理し直します。読取りはすべてその案件が当時読んだ記録から答え、案件が読んでいない記録は読みません。書込み・送信・実行は一切しません。画面には、各再実行が最初に提案した処理と、実際の処理が並びます。スケジュールやルールが起こした案件、ファイルのある案件、処理を提案する前に止まった再実行は、理由を添えて別に挙げます。内容はモデルの提供元にもう一度送られ、費用がかかります。1 回の結果は統計ではなく、承認を止めるものでもありません。
- まず一部の案件だけに施行する。 公開には対象を付けられます。申請者の一定割合か、いくつかのチームと部署で、ファイルと一緒に押印されます。対象が有効な間、いまのルールの版は手を付けずに残り、それ以外の案件はそちらで動きます。新しい作業票は始まった時点でどちらかの版に入り、そのまま動きます。割合の場合、どちらに入るかは公開と申請者から計算するハッシュで決まり、誰でも計算し直せるので、同じ申請者はいつも同じ側に入ります。公開の画面には二つのグループが同じ期間で並びます。処理件数、ルールで通ったものと人が決めたもの、抽出点検の答え、結果。対象を広げる、あるいはすべての案件に広げるのは、別の人が承認する別の公開です。対象を狭める、取りやめるのは、理由を書いてその場でできます。取りやめると、下書きの版で動いていた案件は次の判定からいまのルールに従い、まだ誰も押印していない稟議は差し戻されます。実行済みのことは元に戻りません。限定公開も参照してください。
しないこと
- 自分で何かを広げることはありません。件数も答えも結果も帯を緩めず、公開が自動で取りやめられることもありません。
- 一部の案件だけに施行する公開に入れられるのは、手順書の定義だけです。指示と文言は二つの版で共有するので、変えるならすべての案件への公開になります。施行中は、その業務を変える別の公開はできません。
- 同じ期間に、二人の申請者が別のルールで扱われることがあります。それが問題になる業務では、チームと部署で対象を選んでください。
- 数えるのは宣言された特徴だけです。自由記述の文章や、添付の中身に表れる傾向は集計に現れません。数えられるようにするのは、事実を宣言する公開です。
- 総覧、抽出点検の机、案件をまたいだ答えは、まとめたまま数えます。版ごとに分けて見るのは、比べる場所である公開の画面です。
この記事が答える質問
数字が良ければ、GembaOS は自動の帯を広げますか?
広げません。帯を広げられるのは公開だけで、公開では変更が「緩和」として示され、記録済みの判定で検査され、別の人の承認が要ります。点検の回答や結果、比率の変動の記録は、その公開を起案する人のための材料です。点検の答えが GembaOS の動きを変えるのは、会社が帯の条件に書いた一時停止だけで、それは案件を人に回す方向にしか働きません。
抽出された判断について、点検者には何が見えますか?
その判断が当時前にしていたものです。操作、引数、読んだリスクと事実、そして通したルールとそのルールを確認した人の名前。その後に起きたことは見せません。押印なしで通すことに同意したか、同意しなかったか、判断できないかを答え、同意しなかったときは手順書の理由の一覧から選びます。作業票を依頼した本人は点検できません。
抽出点検は誤り率ですか?
誤り率ではありません。ハッシュで抜き出すので、同じ記録を持っていれば誰でも同じ件を抜き出せますが、全体に対する割合ではなく、読み出すたびにそう書かれます。結果は GembaOS がつながっている経路から入ったものしか数えません。件数が少ないうちはほとんど何も言えず、相関は因果ではありません。
人がいつも通している例外から、GembaOS は新しい規則を提案しますか?
どこを見ればよいかは示します。規則が人の押印に回した判断を、手順書が宣言した特徴ごとに数え、その特徴を規則が読んでいるかを添えます。業務の振り返りは、その組に基づいて規則の候補を挙げられます。GembaOS は組が集計に実際にあるかを確かめ、数字は自分で写します。その業務の責任を持つ職位の人が確認するか見送ります。確認しても規則は変わりません。組織設計アシスタントが下書きの根拠として引けるだけで、下書きはほかの公開と同じく検査され、別の人の承認を経ます。
実案件での再実行には何がかかり、何がわかりますか?
管理者が件数と日数を書かない限り使われません。案件の内容はモデルの提供元にもう一度送られ、モデルの呼び出しには費用がかかり、費用の画面に計上されます。読取りはすべてその案件が当時読んだ記録から答えるので、わかるのは、その事実の上で下書きとモデルがどう動くかであって、外部のシステムがいま持っている内容ではありません。比べるのは各再実行が最初に提案した処理で、モデルを 1 回動かした結果は統計ではありません。
2026 年 9 月時点で GembaOS は第三者認証を取得していません。本サイトの統制対応表は自己評価であり、監査を受けたものではありません。GembaOS は先行導入パートナーの段階にあります。 先行導入パートナーについて読む。
最終更新: · GembaOS v0.2