こんにちは！株式会社雲海設計の技術部です。
「AIシステム構成図を描いてと言われたが、何を載せれば良いか分からない」「PoCの構成図が、本番運用で全く役に立たなかった」——2025年に生成AI導入が爆発的に進んだ結果、2026年に入って「AIシステム構成図の描き方そのものが分からない」という相談が急増しています。本記事では、業務に耐えるAIシステム構成図の描き方を、RAG・エージェント・LLM API直叩きの3パターン別に、作図テンプレと実例を交えて整理します。
TL;DR
AIシステム構成図は「データフロー・推論経路・ガバナンス層」の3レイヤーを分けて描くのが2026年の標準
RAG構成は取り込みパイプラインと検索パイプラインを必ず分離して描く。一枚絵で済ませると破綻する
エージェント構成は「ツール・メモリ・オーケストレータ」の3要素を明示。単なるLLMの矢印では設計レビューが通らない
LLM API直叩き構成でもキャッシュ層・レート制御・監査ログを必ず描く。これが抜けると本番で必ず詰む
作図ツールはMermaidかdraw.io。Figmaは美しいが差分レビューに弱いため非推奨
なぜ2026年に「AIシステム構成図」を描き直す必要があるのか？
結論から言うと、2025年に作られたAIシステム構成図の多くが、本番運用に必要な情報を欠いているからです。PoC段階の「ChatGPTに繋いだだけ」の絵では、運用・セキュリティ・コスト管理のレビューを通せません。
現場で起きている典型的な失敗
箱が「LLM」一個だけ：モデル名・バージョン・推論経路が描かれず、コスト試算もできない
データフローと推論フローが混在：取り込みと検索が同じ矢印で描かれ、キャッシュ戦略が読めない
ガバナンス層の欠落：監査ログ・PIIマスキング・権限制御が図に存在しない
外部APIの依存が見えない：OpenAI/Anthropic/Bedrockなど、SLAに直結する依存関係が抽象化されすぎている
Gartnerが2025年末に公開したレポートでも、生成AIプロジェクトの停滞要因のひとつに「アーキテクチャドキュメントの不備」が挙げられていました。構成図はドキュメントの入口であり、ここが弱いとレビューも引き継ぎも崩れます。
構成図は「絵」ではなく「契約書」である。誰が・何を・どの経路で扱うかを明示できない図は、本番では役に立たない。
関連する設計論点については、過去記事のAIエージェント、95%が失敗する“本当の理由”でも触れていますので併せてご覧ください。
AIシステム構成図に必ず含めるべき3レイヤーとは？
結論、「データフロー」「推論経路」「ガバナンス層」の3レイヤーを必ず描き分けてください。1枚に詰め込むのではなく、レイヤー別に複数枚に分けるのが2026年のベストプラクティスです。
3レイヤーの役割
| レイヤー | 描くべき要素 | 主な読者 |
|---|---|---|
| データフロー | ソースDB・ETL・チャンク化・ベクトルDB・更新頻度 | データエンジニア |
| 推論経路 | クエリ書き換え・検索・リランク・LLM呼び出し・キャッシュ | アプリエンジニア |
| ガバナンス層 | 認証・権限・監査ログ・PIIマスキング・レート制御 | セキュリティ・SRE |
レイヤー分割の効果
レビューが分業できる：データチームと推論チームが別々にレビューできる
変更影響が読める：チャンク戦略の変更が推論層に与える影響を追跡できる
SLA交渉に使える：外部API依存をガバナンス層に明示することで、業務側との合意形成が早まる
パターン1：RAG構成図はどう描けばいいのか？
結論、RAGは「取り込みパイプライン」と「検索パイプライン」を必ず別図に分けて描くのが鉄則です。一枚絵で済ませると、チャンク戦略やリランクの議論が確実に抜けます。
取り込みパイプラインの構成図テンプレ
graph LR
A[Source: Confluence/SharePoint] --> B[ETL/Loader]
B --> C[PIIマスキング]
C --> D[チャンク分割]
D --> E[Embedding API]
E --> F[(Vector DB)]
C --> G[(Metadata DB)]
G -.権限タグ.-> F検索パイプラインの構成図テンプレ
graph LR
U[User Query] --> R[クエリ書き換え LLM]
R --> H[ハイブリッド検索]
H --> V[(Vector DB)]
H --> K[(BM25 Index)]
V --> RR[Reranker]
K --> RR
RR --> P[Prompt Builder]
P --> L[LLM API]
L --> Cache[(Response Cache)]
L --> Out[Response]RAG構成図で見落としがちな要素
権限タグ：取り込み時にメタデータへ埋め込み、検索時にフィルタする経路を明示
更新頻度：日次・リアルタイム・手動の区別を矢印に書き添える
埋め込みモデルのバージョン：再埋め込みコストに直結するため必須
RAGの実装論点については過去記事のナレッジ管理×生成AIの実装設計で深掘りしていますので、構成図と併読をおすすめします。
パターン2：AIエージェント構成図で押さえるべき要素は？
結論、エージェント構成図は「ツール・メモリ・オーケストレータ」の3要素を必ず分離して描いてください。LLMから矢印を散らすだけの図では、設計レビューも障害分析もできません。
エージェント構成図テンプレ
graph TB
U[User] --> O[Orchestrator/Planner]
O --> LLM[LLM API]
O --> T1[Tool: 社内検索]
O --> T2[Tool: SQL実行]
O --> T3[Tool: 外部API]
O --> M[(Short-term Memory)]
O --> LM[(Long-term Memory)]
O --> G[Guardrail/Policy]
G --> Audit[(Audit Log)]
T2 --> DB[(業務DB)]エージェント構成図のチェックリスト
オーケストレータの責務が明示されているか：ReAct/Plan-and-Execute/グラフベース等の方式を注記
ツールごとに権限スコープが描かれているか：SQL実行ツールは特に要注意
メモリの寿命が分かるか：短期（会話内）・長期（ユーザー単位）・共有（組織単位）を分ける
ガードレール経路が独立しているか：プロンプト注入対策・出力検閲を別ノードに
失敗時のフォールバック経路があるか：ツール呼び出し失敗時の人手エスカレーション
エージェント図でよくあるアンチパターン
LLMからツールに直接矢印：オーケストレータの存在が消え、再現性が読めない
「Memory」一個だけ：短期と長期が混在し、データ保持期間の議論ができない
ガードレールが点線：実装が後回しになる典型パターン
パターン3：LLM API直叩き構成図でも油断してはいけない理由
結論、最もシンプルな「ChatGPT APIを呼ぶだけ」の構成でも、本番運用には最低5つの周辺コンポーネントが必要です。これらを構成図に描かないまま本番に進めると、コストとセキュリティで必ず事故ります。
最小構成でも描くべき5要素
| コンポーネント | 役割 | 欠けるとどうなるか |
|---|---|---|
| APIゲートウェイ | 認証・キー管理 | APIキー流出リスク |
| レート制御 | 同時実行・トークン上限 | 請求が青天井になる |
| キャッシュ層 | 同一クエリの重複削減 | コスト3〜10倍 |
| 監査ログ | 入出力の記録 | 事故時に原因究明不能 |
| PIIフィルタ | 個人情報の検閲 | 外部APIに機密漏洩 |
LLM API直叩き構成図テンプレ
graph LR
App[業務アプリ] --> GW[API Gateway]
GW --> Rate[Rate Limiter]
Rate --> PII[PII Filter]
PII --> Cache{Cache Hit?}
Cache -->|Yes| Resp[Response]
Cache -->|No| LLM[LLM API: GPT-4o/Claude]
LLM --> Log[(Audit Log)]
LLM --> Respトークンコストの可視化については生成AIの請求が読めない会社へで詳しく解説しています。構成図にコスト計測ポイントを書き込むだけで、運用初日からの請求事故を防げます。
AIシステム構成図の作図ツールはどれを選ぶべきか？
結論、2026年の業務利用ではMermaidまたはdraw.ioが本命です。Figmaは見た目は美しいものの、Git差分レビューに乗せにくく、技術ドキュメントとしては不向きです。
ツール別比較表
| ツール | 強み | 弱み | おすすめ用途 |
|---|---|---|---|
| Mermaid | テキストでGit管理可能、差分レビューが楽 | レイアウト微調整に弱い | リポジトリ内設計書 |
| draw.io | 細かいレイアウト調整が可能、無料 | 差分レビューが画像比較 | 顧客提出資料 |
| Figma | 美しい、共同編集が強力 | 技術ドキュメント運用に不向き | 営業・経営向け |
| Excalidraw | 手描き感で議論しやすい | 厳密性に欠ける | 初期ホワイトボード |
構成図は「描いた瞬間がピーク」になりがち。Git管理できないツールは半年後にメンテされなくなる。
雲海設計が支援した実例：構成図の見直しで何が変わったか
ある中堅製造業のお客様から「社内ChatGPTを導入したが、毎月の請求が予算の3倍」という相談を受けたことがあります。提示された構成図にはLLMとアプリの2つの箱しか描かれていませんでした。
私たちは前述の3レイヤー（データ・推論・ガバナンス）に分けて構成図を描き直し、以下を可視化しました。
キャッシュ層が存在しないこと（同一質問が日に数百回叩かれていた）
レート制御が無いこと（深夜に1ユーザーが大量並列実行）
監査ログが断片的であること（誰が何を質問したか追跡不能）
構成図でボトルネックが全員に見えた結果、3週間でキャッシュ・レート制御・ログ基盤を追加し、月次コストは約60%削減、レビューサイクルも1/3に短縮されました。構成図は設計の出発点であり、運用改善のレバレッジでもあるのです。
よくある質問
Q. AIシステム構成図は何枚に分けるのが適切ですか？
A. 最低3枚（データフロー・推論経路・ガバナンス層）を推奨します。エージェント構成の場合はさらに「ツール一覧図」を追加し、計4枚構成が標準です。1枚に詰め込むと、レビュー観点が混在して必ず破綻します。
Q. PoC段階でもガバナンス層を描く必要はありますか？
A. はい、必須です。PoCで描かなかったガバナンス要件は、本番化フェーズで「後付け」になり工数が3倍以上に膨らみます。最低でも認証・監査ログ・PIIマスキングの3要素は最初の構成図に入れてください。
Q. 構成図はMermaidとdraw.ioのどちらが良いですか？
A. リポジトリで管理する設計書ならMermaid、顧客や経営層に提出するならdraw.ioが向いています。両方を併用し、Mermaidをマスターとしてdraw.ioに転記する運用が現実解です。
Q. エージェント構成図で外部MCPサーバーはどう描くべきですか？
A. ツールノードとは別に「External MCP」レイヤーを設け、認証経路とレート制限を明示してください。MCPは便利ですが、外部依存が増えるため監査ログとフォールバック経路の記載が必須です。
Q. 構成図のメンテナンスはどう運用していますか？
A. PR（プルリクエスト）に構成図変更を必須化し、コードと同じレビュー対象にしています。Mermaidならテキスト差分が出るため、レビュー負荷も低く保てます。
まとめ：構成図は「設計の鏡」であり、運用品質の指標
AIシステム構成図は、単なるドキュメントではなくチームの設計思考を可視化する鏡です。3レイヤー分割・パターン別テンプレ・適切な作図ツールを押さえれば、PoCから本番運用への橋渡しが大きくスムーズになります。
株式会社雲海設計では、AIシステムのアーキテクチャ設計から構成図レビュー、本番運用までを一気通貫で支援しています。「自社の構成図が本番に耐えるか不安」「RAGやエージェントの設計を一緒に見直してほしい」という方は、DXソリューションやITコンサルティングのページもご覧ください。具体的なご相談はお問い合わせからお気軽にどうぞ。