LangGraph や Dify のエージェントに、稟議と押印をどう付けるか

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。この記事は、すでに人に確認を取るところまで作ってあるエージェントが、次に「その人に答える資格があったこと」をどう示すか、という話です。

割り込みは何を解決していて、何を残していますか

処理を途中で止めることは、すでに解決された問題です。LangGraph の interrupt とチェックポインタは、ノードで実行を止め、状態を永続化し、アプリケーションが返した値で再開します。Dify の承認ノードも同じ役割を果たします。これは制御フローであり、解決されているべき側の半分です。もう半分は権限であり、フレームワークはそれを意図的にアプリケーション側に残しています。

誰でも答えられる停止は、承認ではありません。ただの停止です。

GembaOS は何を足しますか

重要な操作の呼び先を、GembaOS の能力ゲートウェイに向けます。そこから先は職務権限規程が経路を決め、経路が人の判断を挟むと定めていれば、その呼び出しは稟議書になり、名前のある承認者がパスキーで押印します。許可証はその人が見た内容から発行され、業務システムを呼ぶのはモデルではなくホストです。

押印する人が読んでいるのは JSON ではありません。何が起きるか、取り消せるか、対象は何か、いくらか、どの上限に照らして範囲内なのか、許可証はいつまで何回使えるのか、書き込みの直前に何を確かめ直すのか。これらが押印の前に画面に出ています。

構成のどこが変わりますか

まとめ

LangGraph や Dify が決めるのは、エージェントがどう考え、どこで止まるかです。社内の誰が何を決裁してよいかまでは決めませんし、決めるとも言っていません。それをグラフの中に作り込むということは、職務権限規程をアプリケーションのコードで書き直すということです。グラフはそのままにして、重要な呼び出しだけを一段先に移し、承認に名前と上限と押印と、一回で済む実行を持たせてください。