AIが契約・稟議を横断監査する経営者の味方 - Risk Reader - Microsoft Agent Hackathon 2026
社長が稟議書のハンコを押そうとしている、その直前。
AI が議事録・契約書・稟議書を横断して、「与信未実施。最大2,000万円規模リスク」と指摘する。
これが私が Microsoft Agent Hackathon 2026 に提出した Risk Reader（リスクリーダー）です。
この記事では、
- 経営者の「承認前リスクゲート」というカテゴリへの着想
- Azure Container Apps / Azure OpenAI / Microsoft Graph / Entra ID で構築したシステム
- Azure 構成選択の試行錯誤
など、AI監査システムを Azure 上で動かすまでの記録を書いていきます。
🎯 Risk Reader とは
「経営者の承認ハンコを押す直前に、AI が議事録・契約・稟議を横断監査して、差し戻し提案を出す」 システムです。
⚠️ Microsoft Agent Hackathon 2026 の審査終了に伴い、
公開デモ環境は停止しました。
🤔 なぜ作ったのか
Risk Reader が想定する課題シナリオ
Risk Reader が解決対象として想定しているのは、次のような 承認フロー上の情報分断 です。
- 社長は契約書を全文確認する時間が取りにくい
- 営業は議事録のうち決定事項を中心に確認する
- 法務は議事録や契約全体ではなく、自分の領域のみを見る
- 経理は与信判断より先に取引が動き始めるケースがある
つまり、全ての書類を横断的に見ている人がいないという状況です。
Risk Reader が埋める領域
承認や情報共有まわりには既にいくつかの種類のツールがあります。
| 種類 | 役割 |
|---|---|
| 決裁ワークフロー系 | 申請・承認・押印のフロー管理 |
| 業務プロセス管理系 | プロセスの進捗追跡 |
| 対話型AI系 | 質問されたら答える |
これらは「フローを回す」「質問に答える」ことには強い一方で、「承認のハンコを押そうとする瞬間に、書類の中身を横断して矛盾を指摘する」役割は持っていません。
Risk Reader はそこを埋める「承認前リスクゲート」というカテゴリで設計しました。
🏗 システム構成（アーキテクチャ）
全体の構成は次のとおりです。
技術スタック（Microsoft 製品の使用箇所）
| 技術 | 何のために使ってる？ | ハッカソン要件 |
|---|---|---|
| Azure Container Apps | Risk Reader アプリを動かす実行基盤 | 【必須】Azure実行基盤 ✅ |
| Azure OpenAI（gpt-5-mini） | 議事録・契約からリスク検出するAI | 【必須】Microsoft AI技術 ✅ |
| Microsoft Entra ID | OAuth認証本体 | 【推奨】Entra ID ✅ |
| Microsoft Graph API | OneDrive 文書取得の窓口 | Microsoft API 利用 |
| MSAL | Python から MS認証を扱う公式ライブラリ | - |
| Azure Container Registry | Docker イメージの保管庫 | - |
Microsoft の【必須】2要件と【推奨】Entra ID をすべて満たす構成です。
💡 プロダクトの工夫
Risk Reader の中核は「AI が出した結果を、経営者がそのまま意思決定に使える形にする」という設計です。
工夫 1：6種類のリスク分類
検出したリスクを以下の6種類に分類しています。「議事録の前提が契約に反映されていない」「実行が決まったタスクの担当・期日が抜けている」など、現場で起こりがちな失敗の構造を分解しています。
| リスク分類 | 何を検出するか |
|---|---|
| 文書間の矛盾 | 議事録・契約・稟議の記述が食い違っているもの |
| 法務シグナル | 法務レビューが必要な内容（法的助言はしない） |
| AIリスク | 顧客データ・生成物責任・外部送信に関わるリスク |
| 決定の積み残し | 議事録で決まったが、誰がいつやるかが未確定 |
| 実行漏れ | 決定事項がタスク化・期日化されていない |
| 商業リスク | 売上漏れ・無料対応・採算割れの兆候 |
工夫 2：4要素の重み付けスコア
各リスクに 0〜100 のスコアを付けますが、AI に丸投げで「スコアを付けて」とは言いません。
次の重み付けで算出させています。
risk_score = 影響度 × 0.35
+ 緊急度 × 0.25
+ 確信度 × 0.20
+ 未解決度 × 0.20
「経営者の判断を支える」プロダクトなので、影響度（事業・金銭への打撃の大きさ）に最も重みを置く設計です。各要素の単独スコアも score_breakdown として出力させ、後から「なぜこのスコアになったか」を分解して確認できます。
工夫 3：5W1H + メール本文ドラフトまで AI が出す
検出して終わりではなく、経営者がそのまま社内に転送できる「確認依頼メール案」まで AI に生成させています。
"recommended_action": {
"to_department": "経理部",
"to_role": "与信管理担当",
"what": "新生トレード社の与信調査と限度額・条件の確定",
"when": "出荷・請求前まで",
"why": "与信未実施のまま取引が進むと債権回収不能リスクが高い",
"how": "外部信用情報の取得と社内会議での承認",
"draft_message": {
"to_name": "経理部 与信管理担当",
"subject": "新生トレード社 与信調査のお願い",
"body": "..."
}
}
経営者は「差し戻しが必要」と判断したら、ボタンを押して送るだけ。
差し戻しに必要な行動コストを限界まで下げることを狙った設計です。
工夫 4：議事録 ↔ リスク根拠リンク
検出されたリスクカードから、根拠になった議事録・契約書の該当ファイル名と引用文に飛べます。
"evidence": [
{ "document": "03_議事録.md", "quote": "与信は取引開始後に並行で実施する" }
]
AI が出したリスクの「裏付け」を経営者がすぐ確認できる設計です。
AI 任せにせず、最終判断は人がするという前提を組み込んでいます。
🧠 プロンプトの工夫
1つのプロンプトで6カテゴリを横断判定
1案件分の文書群（議事録・契約・稟議など）を1度の AI 呼び出しで読み込み、6カテゴリのリスクを一気に出させる設計にしています。
1案件のフォルダ内 .md ファイルを全部結合
↓
gpt-5-mini に「6種類のリスクを全部探して」と依頼
↓
JSON 構造で複数リスクを返す
カテゴリごとに AI を別々に呼ぶとコストと時間が増え、カテゴリ間の関連性を見落としやすいため、1回の呼び出しで横断判定させています。
構造化出力（JSON モード）
Azure OpenAI の response_format={"type": "json_object"} を使い、出力を JSON 構造に固定。後処理（HTML レンダリング・リスクカード生成・スコア表示）が安定します。
重要度を3段階に縛る
各リスクに severity を critical / warning / info の3段階で付けさせています。これにより画面の「重大リスク◯件」というサマリーカードが安定して動きます。
🛠 ハッカソン提出のための工夫
ここからは、プロダクトの本質ではなく、ハッカソンの審査員に体験してもらうための運用工夫です。記事の構成上、プロダクト価値とは分けて書きます。
ハッカソン用工夫 1：サービスサイドOAuth方式
課題：審査員に Microsoft アカウントでのログインをお願いするのは現実的でない。仮にログインしていただいても、その方の OneDrive には Risk Reader が見るための文書がない。
解決：管理者（私）が1回だけ MS 認証を済ませ、その access_token と refresh_token をサーバー内で全ユーザー共有の状態で保持する設計にしました。審査員はアプリのログインだけで、私の OneDriveで Risk Reader を体験できます。
/auth/connect は ADMIN_PASSCODE 環境変数でガードしているため、第三者が勝手に共有トークンを上書きすることはできません。
これはプロダクトの本質的価値ではなく、ハッカソン提出環境を成立させるための工夫です。
実運用では各企業のテナント内で完結する OAuth 設計に切り替えます。
ハッカソン用工夫 2：min-replicas=1 でコールドスタート回避
Azure Container Apps は標準で「使われていない時間が続くとコンテナが停止」します。初回アクセス時に20秒前後の待ち時間が発生するため、--min-replicas 1 を指定して常時1台起動させています。
ハッカソン用工夫 3：5案件の並列処理
審査員が「再スキャン」を押したときの待ち時間を短くするため、5案件のリスク検出を直列ではなく並列で実行しています。Python 標準の concurrent.futures.ThreadPoolExecutor を使用。
🧭 試行錯誤の中で見えた学び
Azure には多くの選択肢があるため、ハッカソンのような短期開発では「最初の構成選択」が大きく結果を左右すると感じました。今回の試行錯誤で得た学びを共有します。
学び 1：個人開発 × ハッカソンでは Container Apps が最短ルート
当初は Azure App Service で構築しようとしていましたが、構成要件や個人アカウントの初期設定を見直す中で、最終的に Azure Container Apps を選択しました。
Container Apps は Docker イメージをそのままデプロイでき、スケーリングや HTTPS 終端も自動で扱ってくれます。「個人で短期間にアプリを動かす」という条件下では、結果的にこちらの方が私のユースケースに合っていました。
事前に Microsoft のハッカソン向けスタートアップガイドや Container Apps のドキュメントをもっと早く読んでいれば、最初からこの選択ができたと思います（反省点）。
学び 2：認証は管理者側で完結させる設計が現場に合う
OneDrive 文書を読み込む以上、Microsoft Graph API の認証が必要です。しかし審査員や閲覧者全員に Microsoft アカウントでのサインインを要求するのは現実的ではない。
そこで採用したのが、上述の サービスサイドOAuth方式です。
管理者（私）が一度だけ認証を済ませ、その状態でアプリ全体が動くようにしました。
学び 3：デプロイは小さい単位で動かしてから本番に持っていく
デプロイは複数の Azure CLI コマンドを組み合わせて行います。az acr build（イメージのクラウドビルド）→ az containerapp update --image（アプリのイメージ差し替え）のような単位で1つずつ動作確認しておくと、コマンドの挙動や前提条件（リソース プロバイダの登録、ACR の admin user の有効化など）を把握しやすく、本番のデプロイで詰まりにくくなります。
私はこれを本番直前にまとめてやってしまい、提出締切が近づく中で慌てる結果になりました。次回は構成検証と本番デプロイを分けて進めたいです。
🚀 今後の展望
Risk Reader はハッカソン提出時点では経営者のリスクチェックのみですが、以下の方向で発展させる余地があります。
1. 多段承認フローへの拡張
現状は経営者単独レビューを想定していますが、実際の企業では「一次承認＝課長 → 二次承認＝部長 → 三次承認＝社長」のような多段承認フローが一般的です。
各段階で見るべきリスクの粒度は変わります。たとえば：
- 課長：実行漏れ（タスク化・期日化のヌケモレ）の検知
- 部長：前提放置（議事録↔契約↔稟議の整合性）の検知
- 社長：法務シグナル・与信リスク・全体俯瞰
それぞれのレイヤーに合わせて検出ロジック・表示するリスクを切り替えることで、組織の承認フロー全体に組み込める設計に拡張できます。
2. 企業向けの実装パッケージ化
OneDrive 接続部を顧客のテナントに切り替えて提供できる形にすれば、AI裏方サービスの一環として企業に展開できます。
3. 複数フォルダ・複数案件への拡張
現状は /RiskReader/ 配下の5案件で動かしていますが、SharePoint 全体や複数の稟議システムを横断する形にも拡張可能です。
「経営者の承認ハンコを、AIが裏で支える」
AIの世界観の中で、Risk Reader はその第一歩のプロトタイプとして位置づけています。
📝 まとめ
- Microsoft Agent Hackathon 2026 に Risk Reader を提出
- Azure Container Apps + Azure OpenAI + Microsoft Graph + Entra ID で構築
- サービスサイドOAuth方式で審査員が Microsoft 認証不要で体験できる設計
- 個人開発 × 短期開発という条件下で Azure Container Apps の良さを実感した
リンク
⚠️ Microsoft Agent Hackathon 2026 の審査終了に伴い、
公開デモ環境は停止しました。
経営者が押すハンコを、AIが裏で支える世界を少しだけ近づけられたら嬉しいです。
ありがとうございました。
🛡️ Risk Reader (Executive Risk Ledger)
Microsoft Agent Hackathon powered by Tokyo Electron Device 提出作品
Discussion