AppSheet Gemini 承認フロー：AI 判定設計の基準

AppSheet の Automation 機能に Gemini の AI Task（分類・抽出・要約）が追加され、業務承認フローへの AI 自動判定の適用が現実的な選択肢になっています。この記事では、「どの申請カテゴリに AI 判定を適用してよいか・してはならないか」という設計判断の基準を整理します。

この記事を読んだほうが良い人

• AppSheet で業務承認フロー（経費申請・設備申請・休暇申請など）を運用しており、AI 自動判定の導入を検討している情シス担当者
• Gemini の AI Task を承認フローに組み込みたいが、どこから手をつければよいか分からない方
• 「AI が誤承認したときの責任設計がない」という懸念から、AI 化に踏み切れていない方
• ノーコード承認フローのガバナンスを整備したい 100 名規模企業の情シス担当者

AppSheet Automation の AI Task とは何か

AppSheet の Automation 機能では、Gemini の AI Task を処理ステップに組み込むことができます。AI Task には以下の 4 種類があります（AppSheet 公式ヘルプより。AppSheet Enterprise Plus ライセンスが必要）。

• 分類 (Categorize): テキストを定義済みのカテゴリに自動分類する
• 抽出 (Extract): 画像・PDF・テキストから必要な情報を取り出す
• 行抽出 (Extract Rows): アップロードされたファイルから複数の行データとして抽出する
• 要約 (Summarize): 長いテキストを短い要約に変換する

これらの AI Task は「情報の分類・抽出・要約」を行う処理です。「申請書を読んで承認ボタンを押す」という意思決定の代行とは性格が異なります。

ここを混同すると、運用に入ってから問題が起きます。AI Task は入力データをもとに確率的な分類・抽出を行うため、判断基準があいまいな申請を自動処理すると、誤分類・誤抽出が発生します。

具体的なイメージとして、消耗品の発注申請を例に取ります。申請者が品名・数量・金額の 3 項目を決まったフォームに入力した場合、AI Task の「分類」で「消耗品」「IT 機器」「備品」のいずれかに仕分けることは比較的安定して動きます。これに対して、「業務効率化のためにツールを試用したい」のような自由記述が主体の申請では、定義済みラベルに収まらない入力が多く、誤分類が発生しやすくなります。入力フォーマットの統一度が高い申請ほど AI 判定との相性が良く、逆に例外ケースが多い申請は人間判断の余地を残す設計が適切です。

承認フローに AI を組み込む前に、「AI がどこまでを担い、どこから人間が判断するか」を先に定義することが必要です。

承認リスクを 3 段階に分類する

AI 自動判定の適用範囲を決めるために、まず自社の承認申請をリスク分類します。以下の表は判断の出発点となるフレームワークです。

リスク分類	承認例	AI 判定の方針	根拠
低リスク	消耗品・1 万円未満の備品申請、定型 IT アクセス権申請	条件付き自動判定可	判断基準が明確・誤承認の影響が限定的
中リスク	経費申請（1〜10 万円）、外部 SaaS の試用申請	AI 補助 + 人間最終確認	例外ルールあり・部門予算との照合が必要
高リスク	10 万円超の購買・採用・契約の最終意思決定	人間判断必須	コンプライアンス上の説明責任・誤承認の影響が大きい

表中の金額閾値（1 万円・10 万円）はあくまで一例です。自社の内部統制規程に「承認権限一覧」がある場合は、そのテーブルをリスク分類の起点として使うと、社内のルールとの整合性を保ちやすくなります。承認権限一覧が未整備の場合は、この AI 導入プロジェクトを機に権限テーブルを作成する機会にできます。

重要なのは、AI 判定の対象範囲を「可」「補助」「不可」に分けて、それを社内のルールとして文書化することです。リスク分類の基準が言語化されていないと、後から「なぜこの申請が自動承認されたのか」という問い合わせに答えられなくなります。

AppSheet Automation 設計判断：AI 判定を任せる 4 つの条件

承認フローの AI 化を安全に進めるために、以下の 4 条件を事前に確認します。

• 判断基準のルール化: 「〇〇なら承認、△△なら却下、□□なら上長へエスカレーション」という条件が文書化されている
• 入力データの品質担保: AI Task が判断するための情報（金額・申請種別・申請理由）がフォームで一定のフォーマットで入力される
• エスカレーション経路の設計: AI が判断できない場合・低信頼度の場合に、自動的に人間にルーティングされる
• 監査証跡の確保: AI がどの情報をもとに、どう判断したかをログに記録できる

この 4 条件のうち 1 つでも欠ける申請カテゴリは、現時点では AI 判定の対象外にするのが安全です。

「エスカレーション経路の設計」は特に補足が必要です。AppSheet の Automation では、AI Task の出力値（分類結果・抽出値）を条件分岐のトリガーとして使えます。「分類結果が"判断不能"のとき上長に通知を送る」「申請金額の抽出値が閾値を超えたとき情シスに回付する」のような条件分岐を、Automation のステップとして事前に設定しておく必要があります。この設計なしに AI Task を有効にすると、AI が判断できなかった申請がどこにも引き継がれずに宙に浮く事態になります。

実務上、後回しにされやすいのが「エスカレーション経路」と「監査証跡」の 2 つです。この 2 項目は、問題が起きてから慌てて追加しても間に合わないため、設計段階で必ず組み込んでください。

誤判定が起きたときのエスカレーション設計

AppSheet Automation では、AI Task の出力（分類結果・抽出値）をもとに条件分岐を設定できます。この仕組みを使って、誤判定時のエスカレーションフローを組み込みます。

エスカレーションを発動させる条件の例として、次のものが考えられます。

• 分類結果が「判断不能」または「その他」になった
• 抽出された申請金額が閾値（例: 5 万円）を超えた
• 申請理由に例外扱いとなるキーワードが含まれた

これらの条件に該当した場合、自動で上長や情シスに通知が送られ、人間が最終判断を行うフローに切り替わります。

設計上の重要な点は「AI が却下した」という状態を作らないことです。AI はあくまで「判断補助」または「仕分け」の役割を持ち、最終判断は人間が行うという建付けにすることで、誤承認・誤却下が発生したときの責任の所在が明確になります。「AI の判断に問題があった」ではなく「AI が判断できなかったため人間が判断した」というフローにすることで、ガバナンス上の説明責任を果たしやすくなります。

また、エスカレーション率（全申請件数に対して人間判断に回付された割合）を定期的にモニタリングすることも大切です。エスカレーション率が高止まりする場合は、分類ラベルの定義があいまいか、入力フォーマットが統一されていない可能性があります。率を下げる方向ではなく、「なぜ AI が判断できなかったか」を分析して申請フォームや分類ルールを改善するサイクルを回すことが、精度向上につながります。

監査ログ設計の注意点

AI 承認フローでは、通常の承認フロー以上に監査証跡の設計が重要です。AppSheet のデータソース（スプレッドシートまたは AppSheet Database）に「判断ログ」テーブルを設け、以下の情報を記録する設計を推奨します。

記録すべき項目の例です。

• 申請受付日時・申請者・申請内容のスナップショット
• AI Task に渡した入力値（何を判断材料にしたか）
• AI Task の出力（分類結果・要約・抽出値）
• 最終判断者（AI か人間か）と判断日時
• エスカレーション発生の有無とその理由

後から「この申請は誰が（何が）承認したのか」を明確にトレースできる設計にすることが目的です。内部監査やコンプライアンス調査が発生した際に、このログが唯一の証跡になります。

ISMS（情報セキュリティマネジメントシステム）の認証取得・維持を行っている組織では、「誰が承認したか」だけでなく「何を根拠に承認したか」の記録が求められます。AI 承認フローの場合、承認判断の根拠が「AI Task の出力」になるため、その出力値がログに残っていないと、監査時に証跡として機能しません。AI 化を進める前に、情報システム部門と内部監査部門で「AI 判断の記録をどこまで残すか」をすり合わせておくことを強く勧めます。

AppSheet のデータソースがスプレッドシートの場合、シートの行数が増えると検索性が落ちます。申請量が多い業務には AppSheet Database をログ保存先に使う選択肢も検討してください（AppSheet Database の設計指針については、DRASENAS 公式サイトでも解説しています）。

導入前チェックリスト

本番稼働の前に、以下の項目を確認します。

• AI 判定の対象申請カテゴリと対象外カテゴリを一覧化し、関係部門の合意を得た
• 判断基準（承認・却下・エスカレーションの条件）を文書化した
• AppSheet Enterprise Plus ライセンスが対象ユーザーに割り当て済みである
• Gemini in AppSheet の管理者ガバナンスポリシー（どのアプリ作成者が AI Task を使えるかの制御）を設定した
• AI 誤判定時のエスカレーション先と再判断プロセスを決定した
• 監査ログの保存先と保持期間を確定した
• テスト運用期間（並行稼働）を設け、誤判定率を計測した

この中で最も時間がかかるのが「誤判定率の計測」です。最初の 1〜2 ヶ月は並行稼働（AI 判定と人間判断の両方を走らせて結果を比較する）の期間を設けることを強く勧めます。並行稼働の期間中は、AI が出力した分類結果と担当者が実際に判断した結果を記録しておき、乖離が多いカテゴリを特定します。その結果を踏まえて分類ラベルの定義や入力フォームを調整してから、本番の自動判定に切り替えるという順序が現実的です。運用データなしに「AI 判定で十分」と判断するのはリスクが高く、段階的に対象範囲を広げる進め方が安全です。

まとめ：AI 判定は「承認の代替」ではなく「仕分けアシスト」

AppSheet × Gemini の承認フロー AI 化で情シスがすべきことは、「AI に何を任せ、何を任せないか」という境界線を組織として定義することです。AI Task は分類・抽出・要約が得意な仕組みで、承認判断の責任を代替するものではありません。

設計の順番として、承認リスクを 3 段階に分類し、エスカレーション経路と監査ログを先に固める。この順序を守ることで、「AI が誤承認したときの対応が何もなかった」という状況を避けられます。AI 化の目的はスピードだけでなく、設計された範囲内で確実に動く承認フローを作ることです。

まず低リスクカテゴリで小さく始め、並行稼働でエスカレーション率と誤判定パターンを把握してから対象範囲を広げる。この進め方が、AI 承認フローを安全に組織に定着させる最短ルートです。AI Task の「分類精度を高める」作業と「ガバナンス設計を整える」作業は並行して進める必要があり、どちらか一方だけを先行させると後から大きな手戻りが生じます。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。