AI を事業に実装するための、
最小構成アーキテクチャ
ChatGPT を「使う」段階から、AI を業務フローと売上に組み込む段階へ。 Xiora が現場で繰り返し採用している、最小構成の AI 実装アーキテクチャと、設計上の判断ポイントを公開します。
「AI を使う」と「AI を実装する」は別物
ChatGPT を業務で使えるようになった企業は急速に増えました。プロンプトのコツが共有され、議事録の要約、メールの下書き、画像の生成などが日常になりつつあります。
一方で、こうした使い方は基本的に「個人が、その都度、AI を呼び出す」モデルです。これでは、AI のメリットは個人の生産性向上にとどまり、業務フロー全体や売上の構造にはなかなか効きません。
私たちが「AI を事業に実装する」と呼ぶのは、これとは別の段階です。AI を業務フローと既存の SaaS / データに接続し、人が呼び出さなくても価値が流れる構造を作ることを意味します。
「AI を使える会社」と「AI を実装できる会社」の違いは、技術力よりも、業務とデータの設計力に強く依存します。AI モデルはコモディティ化していくため、差が出るのはむしろここです。
最小構成アーキテクチャ
Xiora が業種を問わず採用している、AI 実装の最小構成アーキテクチャは次の通りです。難しい技術選定よりも、「層を分ける」考え方そのものが重要です。
AI 実装の最小構成(4 レイヤー)
ユーザー接点 → API → AI レイヤー → 既存の業務 SaaS / データ基盤。役割を明確に分けることで、後から差し替えと拡張が容易になります。
Touchpoint
Web / LP
Next.js
Touchpoint
LINE / Slack
Messaging API
Touchpoint
業務管理画面
Retool · Next.js
API Layer
Edge / API Routes
Vercel · Supabase
AI Layer
LLM Agent + RAG
OpenAI · Claude · Vector DB
Business SaaS
CRM / SFA
HubSpot · Salesforce
Business SaaS
業務 / 会計
kintone · freee
Data Platform
DWH
BigQuery · dbt
Observability
Dashboard
Looker · Metabase
- 一般コンポーネント
- AI / コア
- 既存環境
4 つのレイヤーの役割
1. Touchpoint レイヤー
ユーザーが AI と接する入り口です。Web、LINE、Slack、社内管理画面など、現場の動線に合わせて選びます。大事なのは「ユーザーが新しいツールを覚えなくていい」場所に置くことです。たとえば現場が LINE で運用しているなら、新しい UI を作るより、LINE Bot として実装するほうが定着率は圧倒的に高くなります。
2. API レイヤー
AI を直接呼び出すのではなく、必ず自前の API を一段挟みます。Vercel の Edge / API Routes、または Supabase の Edge Functions を典型構成として採用します。
- モデル選定(OpenAI / Claude / Bedrock)を後から切り替え可能にする
- API キーや費用を、フロントに漏らさず一元管理する
- レート制限、リトライ、ログ、監査をここで実装する
この層を最初から作っておくかどうかで、半年後の運用負荷が大きく変わります。
3. AI レイヤー
LLM 呼び出し、RAG(社内文書を参照しながら回答させる仕組み)、エージェント、ツール呼び出しを担います。Xiora の標準構成は次のようになっています。
// 擬似コード
const result = await agent.run({
query,
tools: [
searchKnowledgeBase, // RAG
fetchCustomerFromCrm, // CRM 連携
createDraftInvoice, // 業務 SaaS への副作用
],
guardrails: [
blockPII,
requireCitation,
capCost(0.05), // 1 リクエスト最大コスト
],
});
ポイントは 「LLM 単体ではなく、ツールとガードレールの集合として設計する」ことです。ガードレールがないと、AI の確率的な振る舞いを業務に乗せることはできません。
4. Business SaaS / Data レイヤー
AI の出力は、最終的に CRM、会計、業務管理、DWH などの既存システムに着地して初めて意味を持ちます。「AI チャットで終わる導入」は、ほぼ確実に定着しません。返答の生成、商談化、見積作成、データ更新まで、業務フローのどこに着地させるかを最初に決める必要があります。
設計上の判断ポイント
このアーキテクチャを採用するかどうか以前に、現場で繰り返し問われる判断が 4 つあります。
1. どの業務から始めるか
まず狙うのは、「件数が多く・判断が定型・データが揃っている」業務です。問い合わせ仕分け、見積ドラフト、議事録要約、レビュー分析あたりが典型例です。
2. データはどこに集めるか
AI に渡すべきナレッジが、複数の SaaS と PDF とチャット履歴に散らばっているのが、ほとんどの会社の実態です。RAG に走る前に、データを「どこに、どの粒度で、誰が更新するか」を決めるほうが先です。
3. どこに人を残すか
AI に全自動を期待するのではなく、「AI が下書きし、人が最終承認する」フローを基本に置きます。最終承認の場所を業務フロー上に明確に残すことで、品質と説明責任の両方を担保できます。
4. 何を計測するか
実装後に必ず可視化するべき指標は、最低でも以下の 4 つです。
- 処理件数(AI 経由 / 人手)
- 1 件あたり所要時間(導入前比)
- AI ドラフトの最終採用率
- 1 件あたりトークンコスト
これがないと、AI 導入は「効いている気がする」で終わります。Looker Studio や Metabase でダッシュボード化しておくことを強く推奨します。
まとめ
AI を事業に実装するのは、モデル選定ではなく、業務フローとデータ設計の問題です。
紹介した 4 レイヤー構成は決して新しいものではありませんが、「層を明確に分ける」「ガードレールを設計する」「業務フローに着地させる」「最初から計測する」を徹底するかどうかで、本番運用に乗るか否かが決まります。
Xiora では、御社の業務に合わせた具体的なアーキテクチャ設計から運用までを一気通貫で支援しています。AI 導入をどう始めればよいか迷っている方は、30 分の無料相談でお気軽にご相談ください。