用語集

用語集

一語一義。GembaOS のコンソール、ポリシー、このサイトで使う言葉です。他のページは定義を繰り返さず、ここへリンクします。GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。

作業票

work_item

作業票(Work Item)とは、GembaOS が一つの仕事の単位ごとに保持する記録です。誰が依頼し、誰の名義で動き、エージェントの各手番、各ポリシー判定、各押印、各実行を、順序どおりにハッシュチェーンで残します。

本用語集のすべては作業票を軸にしています。顧客からの申請、監視のアラート、貼り付けられた退職者一覧、承認済みの議事録が、それぞれ一枚の作業票を開きます。

稟議書

approval_request

稟議書(Approval Request)とは、ポリシーが「押印が必要」と判定したときに GembaOS が起案する文書です。ガバナンスカーネルが照合した事実、正確な引数、理由、経路が求める承認者の順序を載せます。

承認者が稟議台で見るのはこの文書です。押印すると、そこに書かれた引数に紐づくワンタイム許可証が発行されます。それ以外の何も発行されません。

ワンタイム許可証

clearance_token

ワンタイム許可証(Clearance Token)とは、承認された一つの操作のために GembaOS が発行する、一回限り・有効期限付きの実行許可です。その操作の引数のハッシュ(argsHash)に紐づき、実行すると消費され、異なる引数には一致しません。

エージェントが業務システムの認証情報を持たずに済むのは、この許可証があるからです。認証情報はゲートウェイが保持し、一枚の許可証に対して一回の呼び出しだけを通します。

承認の陳腐化

stale_approval

承認の陳腐化とは、押印した時点では正しかった判断が、実行の時点では現実と合わなくなっている状態です。記録が編集された、別の承認済み操作が同じ記録に触れた、上限値が動いた、あるいは単に時間が経ちすぎた、のいずれかで起こります。

エージェントの不正ではなく、時間の問題です。GembaOS は書き込みの直前に、押印時の事実と相手システム自身の上限を読み直し、実行中は対象の記録を押さえ、すべての許可証に有効期限を持たせることで、この隙間を狭めます。

冪等キー

idempotency_key

冪等キーとは、相手システムに対して「これは既に受け付けた書き込みと同じものであり、新しい書き込みではない」と伝える識別子です。GembaOS ではガバナンスカーネルが稟議書と作業票から生成するため、エージェントが選ぶことはありません。

再試行、再起動後の再送、タイムアウトによる重複が起きても、一つの承認が多くとも一回の書き込みで済むのはこのためです。GembaOS の内側は一回限りの許可証が、相手システムの内側は冪等キーが受け持ちます。

押印チェーン

signature_chain

押印チェーン(Signature Chain)とは、稟議書に押された印の順序付きの集まりです。ポリシーがエージェントに委ねた確認にはエージェントの押印、経路が人に留保した段階にはパスキーによる人の押印が並びます。

各押印は、誰が・いつ・なぜ・何を見て押したかを持ちます。監査画面では、このチェーンを現行ポリシーで再判定します。

回付・移送・上申・引き取り

human_routes

回付・移送・上申・引き取りとは、GembaOS で押印待ちの稟議書に対して人が行える、記録される四つの操作です。別の役割に先に見てもらう、同等以上の権限を持つ役割へ押印を移す、上長に委ねる、部下が押印待ちの稟議を上長が引き取る、の四つです。

どれも押印ではなく、必要な押印を減らすこともありません。理由は作業票に残り、最後に押印する人は自分のパスキーで押印します。

職務権限規程

delegation_of_authority

職務権限規程(DOA)とは、誰が何を、どの限度まで承認できるかを、役割と金額またはリスク区分で定めた表です。GembaOS のポリシーはこれを読み、操作がエージェントの押印で通るのか、指名された承認者を要するのかを判定します。

多くの場合、会社にすでにある決裁権限表をそのまま書き写したものです。先行導入の最初の 2 週間は、これを書き出す期間です。

代理実行(本人権限の範囲内)

on_behalf_of

代理実行(On-Behalf-Of)とは、GembaOS におけるエージェントのすべての操作が、特定の社員の名義で、その社員の権限の範囲内で行われるという原則です。エージェントは、その社員が持たない権限を一切得ません。

監査人にとって記録が読めるのは、この原則のおかげです。行為者は人であり、エージェントは道具です。

業務機能ゲートウェイ

capability_gateway

業務機能ゲートウェイ(Capability Gateway)とは、エージェントと業務システムの間に立つ GembaOS の構成要素です。エージェントが見るのは業務機能の名前とスキーマだけです。ゲートウェイが認証情報を保持し、ポリシーを照合し、許可証を予約・消費し、アダプターを呼びます。

参照もここを通ります。項目単位の閲覧規則により、エージェントは自分の役割が見てよい項目だけを見ます。

ポリシー再判定

policy_replay

ポリシー再判定(Policy Replay)とは、記録済みの判定を現行ポリシーで再評価し、同じ事実から同じ経路と規則チェーンを導くことです。GembaOS は再判定が確定的になるだけの情報を、すべての判定について記録します。

数か月前の判定が今も同じ結果になるかを監査人が確かめる手段であり、ポリシー変更を過去の記録で試す手段でもあります。

シャドー再実行

shadow_replay

シャドー再実行(Shadow Replay)とは、記録済みの作業票を新しいモデルや新しい設定で、何も実行せずに走らせ、結果が変わる箇所を示すことです。

モデル変更が本番に届く前の関門であり、先行導入プログラムの第 5 週にあたります。

ゴールデンテスト

golden_test

ゴールデンテスト(Golden Test)とは、期待される判定を添えて記録した会話を、GembaOS が実行基盤に対してオフラインで再生する試験です。判定を変えてしまう変更は、この試験で失敗します。

ゴールデンテストとレッドチームの事例は、パートナーのセキュリティ担当と一緒に確認する証拠です。

監査再生

audit_replay

監査再生(Audit Replay)とは、ハッシュチェーンでつながった事象から作業票を復元し、その上でポリシーを再度走らせる画面です。経路、規則チェーン、押印を、信じるのではなく検証できます。

ホームページの「監査記録」タブの画面は、すべてこの表示です。

不足台帳

gap_register

不足台帳(Gap Register)とは、エージェントが仕事を進めるうえで欠けていたものを記録する台帳です。未整備の手順書、未定義の限度、不明な責任者。不足は権限を広げず、誰が決めるべきかを記して待ちます。

提案された手順は審定台に送られ、人が承認して初めてナレッジになります。

組織設計アシスタント

architect

組織設計アシスタントとは、管理者が会社の仕事の進め方を自分の言葉で説明する相手となるコンソールのアシスタントです。内蔵文書と現在の設定を読み、ルール公開の下書きを提案します。変更するファイルごとに管理者の発言そのままの引用が付き、GembaOS はそれを照合してから下書きを作ります。

アシスタントは公開できません。下書きはその場で検査され、以前より緩和される点と組織の変更がすべて示され、別の人が承認します。同じ下書きは、手で書いた設定や外部のコーディング支援ツールからも作れます。

実演記録

teaching_record

実演記録とは、担当者が会社の宣言したアプリケーションで仕事を一度やってみせたときに GembaOS が保管するものです。画面の表示と本人の操作の記録、そこからアシスタントが理解した内容、責任者が確認した規則がまとまっています。

実演記録は何も実行しません。記録はシステムが何をしたかの証明ではなく、観察された事実です。中の規則は、責任を持つ人がその文言どおりに確認するまで候補のままで、確認済みの規則だけが、ルール公開の下書きの根拠として引用できます。

限定公開

limited_release

限定公開とは、ルールの公開をまず一部の案件だけに施行することです。申請者の一定割合か、いくつかのチームと部署を対象にし、それ以外の案件はいまの版のまま動きます。新しい作業票は始まった時点でどちらかの版に入り、そのまま動きます。

対象はファイルと一緒に押印されます。対象を広げるのは別の人が承認する別の公開で、狭める・取りやめるのは理由を書いてその場でできます。管理者が選ばない限り使われません。

変更セット

change_set

変更セット(ChangeSet)とは、エージェントが制限されたサンドボックスで起案した本番システムへの変更案で、適用される代わりに稟議書として提出されます。

情シスのシナリオそのものです。調査は自律的に行われても、変更は変更承認を通ります。

サンドボックス

sandbox

サンドボックス(Sandbox)とは、エージェントが本番に触れずに読み、試し、起案するための制限された環境です。サンドボックスで何が許されているかは作業票に記録されます。

不具合の修正はサンドボックスで準備され、審査を通った変更セットだけが変更承認を経てそこを出ます。

正式回答

official_answer

正式回答(Official Answer)とは、作業票の終わりに顧客や依頼者が受け取る唯一の回答です。ガバナンスカーネルが承認済みの事実から書き、社内の稟議記録とは分離され、使用した承認済みナレッジを出典として示します。

分類上の懸念がある処理や失敗した処理はエラー回答になり、推測で答えることはありません。

補正依頼

document_round

補正依頼(Document Round)とは、案件の担当者から申請者への一回分の依頼です。必要な書類の種類(playbook が定める選択肢から)、ひとこと、提出期限からなり、申請者は作業票ページやメールで、ファイルとひとことを添えて応じます。

一件の案件で出せる回数は playbook が上限を定めます。期限を過ぎても案件は自動では閉じず、その事実が記録され、担当者が判断します。稟議書は書類が揃ってから一度だけ起票されるため、補正のやり取りは作業票の上で行われ、押印には持ち込まれません。

申込内容の確認

applicant_confirmation

申込内容の確認(Applicant Confirmation)とは、GembaOS が記録した内容(本人の言葉、書類、対象、受付日時)を実行基盤が表示し、ハッシュで固定したうえで、申請者自身が確認する手続きです。申請者は確認するか、誤りを伝えるかを選べます。訂正は追記され、元の記録はそのまま残ります。

playbook が必須とする場合、申請者が確認するまで稟議書は起票されません。稟議書には、申請者がいつその内容を確認したかが記載されます。

所見

consult_finding

所見(Consult Finding)とは、押印する人が押印の前に選択肢から選ぶ結論です。担保範囲内か否か、治療が必要か否か、条件が受け入れられるか否か。所見は押印とともに押印チェーンに入り、playbook は所見ごとに次の手順を定めます。

次の押印者は、自由記述のコメントではなく所見の上に押印します。「見積が不足」のような所見は稟議を差し戻し、申請者に指定の書類を求めることもできます。所見を選ぶのは人、次の手順を決めるのは playbook です。

前回閲覧以降の変化

since_last_viewed

前回閲覧以降の変化(Since You Last Looked)とは、稟議書を開いた人に、前回見たときから何が変わったかを先に示す部分です。待った日数、追加された押印と所見、新しい書類、補正の回数、訂正、申請者の確認。その下に「残る決定はひとつ」が続きます。

「残る決定はひとつ」は、押印待ちの役割、その役割に playbook が設定した問い、未決のまま残る最新の所見を示します。押印される内容は変わりません。二週間ぶりに戻った人に、同じ記録をどう見せるかの工夫です。

最終更新: · GembaOS v0.2