社内 AI アプリ基盤の構成案

5つの要件と、先に置いた4つの判断

要件は5つです。Azure で動く。非エンジニアも AI でアプリを作れる。色々なサービスの情報をアプリから使える。各自の手元のエージェントで作って社内基盤にデプロイする。鍵は配らず、アプリ内で社員の権限を設定できる。

この解説では、次の4点を前提として置いています。判断 1 と 3 はまだ確認していない仮置き、判断 2 と 4 は依頼者の方針です。変えると構成も変わります。

作る場所が「基盤の中」から「手元」に移る

Cloudflare OS ではエージェントが基盤の中にいて、その場でアプリを生成し、その場で改造します。今回の世界観では、エージェントは各自の手元(Claude Code か claude.ai)にいて、成果物だけを基盤へ送ります。基盤の中にエージェントは置きません。この違いが、基盤に必要なものを変えます。

社員のブラウザから外部サービスまで

Cloudflare OS の全体図と同じ並びで描きます。アプリは外部サービスにも鍵にも直接触れず、必ずコネクタ層(API Management)を通る。この一点は同じです。

Cloudflare OS の部品を、Azure のどれで作るか

手元で作ってから、社員が使えるようになるまで

今回の構成で新しく必要になる「経路」です。どこで作ったかに関係なく、必ずこの経路を通ります。

アプリの形式は2つ。非エンジニア向けはサーバーコードなし

claude.ai は単一の HTML を生成するのが得意で、サーバーを含むリポジトリ一式を組み立てるのは苦手です。そこで非エンジニア向けのアプリ形式を「単一 HTML ＋ manifest」に限定し、データの読み書きはブラウザ用 SDK が本人のトークンで基盤の API を呼ぶ形にします。

手元のエージェントに読ませる4点セット

Cloudflare OS の Skills にあたるものです。Claude Code でも claude.ai でも同じ形のアプリが出てくるように、基盤側が用意します。

const user = platform.currentUser(req);
if (!user.hasRole("editor")) return forbid();
const deals = await platform.connectors
  .salesforce.listOpportunities({ owner: user.id });

name: proposal-manager
owner: sales-team@example.com
access: group:sales-all
roles: [editor, viewer]
connectors:
  salesforce: [opportunities:read]
  sharepoint: [files:read, files:write]
  graph: on-behalf-of

コネクタ層: 資格情報は API Management の中にだけある

Cloudflare OS の Gatekeeper と同じ構造です。API Management の Credential Manager が外部サービスの OAuth トークンを保持し、アプリは Entra の ID だけで呼びます。アプリのコードにも環境変数にも、鍵は現れません。

「入れるか」「何ができるか」「何が見えるか」の3層

「アプリ内で社員の権限を設定したい」という要件は、3つの層に分けると Azure の既製機能だけで組めます。

モデル呼び出しの関所と、アプリのデータ置き場

作る側はサブスク、動かす側だけ API

AI の費用を「人が作るとき」と「アプリが動くとき」に分けます。前者は Claude / Codex のサブスクで全部まかなえます。後者は API 課金が残りますが、要るアプリだけに限定して上限を掛けられます。

llm:
  models: [claude-sonnet]
  budget_monthly_jpy: 5000

v1 で作らないものと、その代わり

先に知っておくべきこと

段階的に、最小から