社内生成AIポータルを作る前に決めること｜プロンプト集より先のガバナンス・承認・ログ設計

生成AIの業務利用が一般化する中、多くの企業が「独自の社内生成AIポータル」の構築に乗り出しています。しかし、現場の熱量に押されて「便利なプロンプト集」や「使いやすいUI」の作成を優先し、肝心のガバナンス設計やログ管理が後回しになっているケースが少なくありません。

ガバナンスが欠如したAIポータルは、情報漏洩の温床となるだけでなく、将来的な監査に対応できず、プロジェクト自体の継続が困難になるリスクを孕んでいます。本記事では、IT実務者の視点から、プロンプトの工夫よりも先に定義すべき、承認フロー、ログ設計、およびセキュリティ対策の具体的な仕様について解説します。

社内生成AIポータルにおけるガバナンス設計の優先順位

社内ポータルを構築する最大の目的は、OpenAIなどのパブリックなサービスに個人アカウントでアクセスする「シャドーAI」を防止し、管理下のセキュアな環境でAIを利用させることにあります。そのためには、以下の3つの要素をシステムとして統合しなければなりません。

• 入力データの制御: 個人情報や機密情報がプロンプトに含まれていないかをリアルタイムでチェックする。
• 出力データの検証: 生成された内容に著作権侵害や公序良俗に反する内容が含まれていないかを、必要に応じて人間が確認する。
• トレーサビリティの確保: 「いつ」「誰が」「どのモデルに対し」「どのような入出力を行ったか」を改ざん不可能な形で保存する。

これらの土台がないままにプロンプト集を充実させても、企業のコンプライアンス基準を満たすことはできません。まずは、自社のセキュリティポリシーに基づいた「ガードレール」の設計から着手する必要があります。

承認ワークフローとログ設計の技術仕様

実務において最も議論が分かれるのが「承認フローをどこまで厳格にするか」という点です。利便性と安全性のバランスを考慮した設計が求められます。

1. ログの保存要件：監査に耐えうる設計

ログは単なる利用状況の把握だけでなく、万が一の漏洩事故が発生した際のフォレンジック（原因調査）に必須です。以下の項目をログとして記録することを推奨します。

保存期間は、一般的なIT全般統制の基準に合わせ「最低1年間」、重要情報の取り扱いがある場合は「3〜5年間」を目安に設定します。ストレージ費用を抑えるため、一定期間経過後は冷たいストレージ（Azure Blob Storageのアーカイブ層やAWS S3 Glacierなど）へ自動移行するライフサイクルポリシーを設定するのが実務的です。

2. 承認フローのパターン

すべてのプロンプトに承認を挟むと業務速度が著しく低下します。以下の2パターンを使い分けるのが一般的です。

• 即時利用型（標準）: 社内利用限定のタスク。システムによる自動フィルタリング（PII検知）のみを行い、ログを記録して即座に出力する。
• 承認後出力型（特定用途）: プレスリリース原稿の作成、社外向けコードの生成など、法務・広報・情報セキュリティ担当者の確認が必要なタスク。承認ボタンが押されるまで、生成結果は表示されない。

この使い分けを自動化するためには、ユーザーに「利用目的」を選択させ、そのカテゴリに応じてフローを分岐させるUI設計が有効です。こうした社内システムの整理は、AIに限らず、例えばSaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャで語られるような、ID基盤に基づいた権限管理と深く結びついています。

プラットフォーム選定：Azure OpenAI vs Vertex AI vs AWS Bedrock

社内ポータルのバックエンドとなるAIプラットフォームの選定は、既に導入済みのクラウドインフラに依存することが多いですが、それぞれのセキュリティ・管理機能の特性を理解しておく必要があります。

いずれのプラットフォームも「入力されたデータをモデルの学習に利用しない」ことを明言していますが、エンタープライズ契約（Enterprise Agreementなど）の条件により細部が異なるため、必ず自社の契約形態を確認してください。

運用・コスト管理の具体的なステップ

ポータルを公開する前に、コストの「見える化」と「制限」を実装します。

ステップ1：ID基盤（Entra ID / Okta）との連携

独自のパスワード管理は避け、既存のSSO（シングルサインオン）を利用します。これにより、退職者のアクセスを即座に遮断できるほか、部署情報の属性（Attribute）を利用して、部署ごとのコスト集計を自動化できます。これはExcelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドで解説されているような、既存アセットを活かした業務アプリ開発の考え方と共通する重要なポイントです。

ステップ2：クォータ（利用制限）の設定とアラート

APIの従量課金は、予期せぬループ処理やバッチ処理の暴走により、一晩で数百万円の請求が発生するリスクがあります。

• ユーザー単位の月間上限: 1人月間$50まで、などのソフトリミットを設定。
• 部署単位の予算アラート: 予算の50%, 80%, 100%に達した時点で管理者に通知。
• APIキーの非公開: フロントエンドから直接APIを叩かせず、必ずバックエンドサーバーを介してAPIキーを秘匿する。

ステップ3：ダッシュボードによる可視化

「誰が一番使っているか」ではなく「どの部署が、どのような業務でAIを活用し、どれだけの成果（想定削減時間）を出しているか」を可視化します。これにより、ROI（投資対効果）を経営層に説明しやすくなります。このデータ分析の重要性は、freee会計の「経営可視化・高度連携」フェーズ。会計データを羅針盤に変えるBIとAPI連携術でも、会計データを経営の羅針盤とする文脈で語られています。

よくあるエラーと対処法

構築および運用フェーズで遭遇しやすいトラブルとその解決策をまとめました。

1. PII（個人情報）検知の誤検知（False Positive）

住所や電話番号を厳格に弾こうとすると、一般的な商品番号や社内の内線番号までブロックされることがあります。

対処法: 最初から完全自動ブロックを目指すのではなく、まずは「警告を表示し、利用者に自己責任での入力を促す（ログにはフラグを立てる）」という運用から開始し、徐々に正規表現や機械学習モデルによる検知精度を調整します。

2. APIのクォータ制限（429 Too Many Requests）

全社員が使い始めると、クラウド側のスロットル（流量制限）に抵触します。

対処法: 指数バックオフ（Exponential Backoff）を用いたリトライ処理をアプリケーション側に実装するとともに、必要に応じて複数のリージョンや複数のモデル（GPT-4oとGPT-4o-miniなど）に負荷を分散するロードバランシングを検討してください。

まとめ：持続可能な社内AIインフラを目指して

社内生成AIポータルの構築は、単なる「便利なチャットツールの導入」ではありません。それは、企業のデータを安全にAIに接続するための「次世代インフラ」の構築です。プロンプトエンジニアリングを磨く前に、まずは堅牢なログ設計、柔軟な承認フロー、そして透明性の高いコスト管理体制を整えてください。

正しいガバナンスの上に構築されたポータルこそが、社員が安心して創造性を発揮できる土壌となります。まずはスモールスタートでも構いません。ログの取得から始め、自社の実態に合わせたガードレールを徐々に強化していきましょう。