金融機関の情報システム部が業務システムの権限申請を、Azure OpenAI で職務と権限の対応表に照らし、過大な権限と職務分掌の衝突の疑いを承認の前に拾う

処理の起点を決める

30分ごとに、所属長の承認を終えた申請を取り出します。 Azure Functions のタイマー トリガーで、NCRONTAB 式を使って平日の業務時間に動かします。例えば 0 */30 8-19 * * 1-5 です。既定のタイム ゾーンは協定世界時（UTC）なので、日本の時刻で動かすには WEBSITE_TIME_ZONE のアプリ設定が要ります。ただし、Linux の従量課金プランと Flex 従量課金プランでは、この設定が現在サポートされていないとされています。その場合は UTC に直した時刻で式を書きます。

申請の1件ごとに動かす形にはしません。 申請ワークフローによっては、承認の完了を外へ知らせる仕組みが無いことがあります。取り出しの間隔を30分にすれば、 どの申請ワークフローでも、書き出しか照会の仕組みがあれば組めます。

タイマー トリガーは、関数が失敗した後に再試行しないとされています。失敗した回は次の時刻まで呼ばれません。取り出し済みかどうかを申請番号で記録し、 前の回で処理できなかった申請は次の回に必ず拾うようにします。

入力データを集める

質を決めるのは、人事の兼務の発令です。 「兼務の発令による」と書かれた申請で、人事システムに兼務が無ければ、それは申請理由と事実が合わないということです。 AIがこの食い違いを指摘できるのは、兼務の情報を一緒に渡したときだけです。

禁止の組み合わせには、理由の列を必ず持たせます。 「為替の入力と為替の検証」なら「同じ取引を一人で入力して確かめられてしまう」。理由があると、AIは申請理由がその懸念に答えているかを判定できます。 理由の無い組み合わせは、当たったかどうかしか言えません。

データの取得方法を決める

既に持つ権限は、前の晩の時点のものです。 当日に付けた権限は入っていません。同じ日に同じ人から2件の申請が来ていれば、両方を合わせて照合します。 1件目を付けたあとに2件目が来て、合わせると禁止の組み合わせに当たる、という見落としを防ぐためです。

申請ワークフローの書き出しや API の有無は、製品によって違います。 無い場合は、担当者が毎朝と昼に承認済みの一覧を書き出して所定の場所に置き、その保存を起点にする形でも組めます。

AIへ渡す前に整形する

1. 社員番号で突き合わせる … 申請、人事、権限の一覧を社員番号でつなぎます。見つからない申請者は「人事の情報なし」で担当者へ回します
2. 職務を決める … 人事の職務の区分から、対応表のどの職務に当たるかを引きます。兼務があれば、兼務先の職務も並べます
3. 標準との差分を出す … 申請された権限が、本務と兼務先の職務の標準にあるかを見ます。無いものが差分です
4. 禁止の組み合わせを当てる … 申請された権限と既に持つ権限、同じ日の他の申請を合わせ、禁止の組み合わせの各行に当たるかを見ます
5. 期間を読む … 期間の欄が空か、兼務・応援の発令の期間を超えていないかを見ます
6. 差分も候補も無いものは AI に渡さない … 標準どおりとして一覧に流します
7. 渡す情報を絞る … 氏名は渡さず、社員番号の代わりに申請番号だけで扱います

3番目と4番目が、この構成の照合のすべてです。 どちらも表を引くだけで決まり、プログラムの結果には誤りの余地がほとんどありません。 AIに渡すのは、ここで出た差分と候補の一覧と、それを説明しうる材料だけです。

6番目で、AIの呼び出しは申請のおよそ2〜3割に絞られる想定です。 大半の申請は標準どおりで、AIの出番があるのは例外の申請だけです。

AIに処理させる

させるのは、差分と衝突の候補の1つずつについて、申請理由と人事の情報がそれを説明しているかを判定し、説明がつかなければ確認の文案を作ることだけです。

判定は5つの値のどれかで返させます。 自由文の所感にすると、担当者が読んで判断し直すことになり、照合を機械に寄せた意味が薄れます。

3行目が、いちばん起きやすい失敗です。 「業務上必要なため」とだけ書かれた申請に、AIは職務からもっともらしい理由を想像して explained を付けがちです。書かれていない理由で説明がついたことにしないと、例外の審査がそのまま素通りになります。

指示内容を固定する

あなたは金融機関の情報システム部で、業務システムの権限申請を審査する担当を
補助する立場です。入力の【差分と候補】の1件ずつについて、
【申請理由】と【人事の情報】がそれを説明しているかを判定してください。

【判定の値】
- explained ............ 申請理由が、その権限が要る業務を具体的に書いており、
                         人事の情報と食い違わない
- explained_no_period .. 説明はつくが、期間が空、または発令の期間を超える
- not_explained ........ 申請理由がその権限に触れていない、
                         または「業務上必要」のような一般的な文だけ
- contradicted ......... 申請理由が人事の情報と食い違う
- conflict_unaddressed . 禁止の組み合わせに当たり、申請理由が
                         【禁止の組み合わせの理由】の懸念に答えていない
迷ったときに explained を選ばないでください。

【厳守事項】
- 判定するのは【差分と候補】に挙がった項目だけです。
  新しい差分や衝突を自分で探さないでください。
- 申請理由に書かれていない事情を補わないでください。
  職務や季節から「必要だろう」と推し量って explained にしないでください。
- 「兼務」「応援」と書かれていれば、【人事の情報】に該当する発令と期間が
  あるかを必ず確かめてください。無ければ contradicted です。
- 禁止の組み合わせについては、申請理由が【禁止の組み合わせの理由】に
  書かれた懸念（例：同じ取引を一人で入力して確かめられる）に、
  どう手当てするかを書いているかで判定してください。
  権限が要ることだけが書かれていても、懸念に答えていなければ
  conflict_unaddressed です。
- evidence には、判定の根拠にした申請理由の文をそのまま写してください。
  根拠が無ければ空にしてください。
- 権限を付けるべきか、例外を認めるべきかは書かないでください。
- 判定が explained 以外の項目について、申請者に確かめる質問を
  question に1文で書いてください。答えが「はい／いいえ」か、
  期間・発令番号で返せる質問にしてください。

【申請】{request}
【人事の情報】{hr}
【差分と候補】{findings}
【禁止の組み合わせの理由】{sod_reasons}

「迷ったときに explained を選ばない」を冒頭近くに置いています。 審査の補助で困るのは、説明のつかない申請を通してしまうことです。迷った項目は人の前に出る側へ倒します。

禁止の組み合わせについて、「権限が要ることだけでは足りない」と書いているのも同じ理由です。 「入力と検証の両方が必要」と書かれていれば、AIは説明があると読みがちです。職務分掌の懸念は、必要かどうかではなく、一人で完結してしまうことへの手当てがあるかです。

出力形式を固定する

{
  "request_id": "",
  "items": [
    {
      "finding_id": "",
      "finding_type": "excess | sod_conflict",
      "verdict": "explained | explained_no_period | not_explained | contradicted | conflict_unaddressed",
      "evidence": "",
      "question": ""
    }
  ],
  "summary_for_reviewer": ""
}

finding_id は、プログラムが前処理で付けた番号です。 AIが返した判定を、プログラムが出した差分と候補に1対1でつなぎ直します。返ってこなかった finding_id があれば、 その申請は判定の欠けとして担当者へ回します。

構造化出力では、すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定するとされています。スキーマのプロパティは最大100個、入れ子は最大5段です。数値の最小・最大などのキーワードはサポートされていないため、件数の点検はプログラムの側で行います。

JSON にする理由の1つ目は、一覧の並び順を決められることです。 contradicted と conflict_unaddressed を含む申請を先頭に、not_explained を次に、explained だけの申請を後ろに並べます。

2つ目は、項目ごとに記録が残ることです。 例外を認めた申請について、どの差分にどの理由で認めたかを、棚卸しのときに申請番号から引けます。

区分はプログラムが判定の値から機械的に決めます。 AIに区分そのものを選ばせないのは、区分の決め方を後から変えても、AIの判定をやり直さずに済むようにするためです。

システムへ連携する

申請ワークフローへは書き込みません。 承認と差し戻しは、いまと同じく担当者が申請ワークフローの画面で行います。審査の一覧は、担当者が判断するための材料の置き場です。

業務システムの権限の一覧は、読み取りだけです。 管理者の権限でつなぐ必要はなく、毎晩の書き出しのファイルを読むだけで足ります。 この構成の連携の側に、権限を変えられる資格情報を持たせないでください。

人が確認する

承認は全件、担当者が行います。 区分によって見る深さを変えます。

1. 「衝突の疑い」を最初に見る … 申請理由と人事の情報を読み、question の文案を直して申請者か所属長に問い合わせます
2. 「要確認」を見る … 一般的な理由しか無い申請です。多くは申請者に一言聞けば解決します
3. 「期間の確認」を見る … 期間を書いてもらうか、兼務・応援の発令の期間に合わせて承認します
4. 「確認済みの例外」を見る … evidence を読み、例外として認めるなら理由と期間を承認の記録に書きます
5. 「標準どおり」を流し見る … 件数と申請者を見て承認します

4番目を飛ばさないでください。 AIが explained と判定しても、例外を認めるのは担当者です。 認めた理由と期間は、後の棚卸しで「なぜこの人がこの権限を持っているか」に答える唯一の記録になります。

判定を覆したら、その項目と理由を記録します。 覆した判定が多い職務や業務システムがあれば、対応表の標準そのものが実態と合っていないことを疑います。

例外に対処する

5行目が、この設計の強みです。 差分と衝突の候補は規則の側で出しているので、AIが止まっても、何を見るべきかは一覧に出ます。 判定の文が無くなるだけです。

最後の行は、規則で決めておきます。 ガイドラインでは特権アカウントの利用を厳格に制限し、操作のダブルチェックなどで管理することが挙げられています。特権の申請を AI の判定で軽く扱わないためです。

記録を残す

• 入力 … 申請、人事の情報、既に持つ権限、照合に使った対応表と禁止の組み合わせの版
• 照合の結果 … プログラムが出した差分と候補の一覧（finding_id 付き）
• AIの出力 … 項目ごとの判定、根拠の文、確認の文案
• 人の判断 … 承認・問い合わせ・差し戻しと、その理由。例外を認めた場合の期間
• 判定を覆した記録 … どの項目を、どの判定からどちらへ変えたか
• 例外の期間の満了 … 期間付きで認めた権限の一覧と満了日

対応表の版を残すのは、表が後から変わるためです。 職務の標準を見直すと過去の差分の意味が変わり、当時の表が残っていないと、なぜ例外扱いだったかを説明できません。

最後の行は、棚卸しへの引き継ぎです。 期間付きで認めた権限が満了日を過ぎても残っていれば、それが次の棚卸しで最初に見るべきものです。