4人のアーキテクト
同じ「アーキテクト」でも、担う問いはまるで違う。Orchestrixは、その違いを設計思想として言語化し、案件ごとに最適な布陣で供給します。
4職種は「抽象度（事業⇔技術）×時間軸（構想⇔実装）」の座標で整理できます。Business→Solution→Technical が対角線に並び、AIはその全層を貫く“縦串”。買い手が最も混同するのは、広く浅く「どの解き方か」を選ぶ Solution と、狭く深く「どう作り動かすか」を担う Technical。この境界を明快に語れることが、プロ集団の証です。
- Business｜WHY / WHAT（事業・構想）
- Solution｜WHICH（橋渡し・広く浅く）
- Technical｜HOW（実装・狭く深く）
- AI｜全層を貫く縦串（AIライフサイクル）
ビジネスアーキテクト
問い：何を・なぜ変えるのか（事業として）
経産省 DSS 正式類型経営課題を起点に、変革のゴールとビジネス価値（ROI）を定義。業務プロセスとケイパビリティの現状／あるべき姿を描き、効果検証まで一気通貫でリードする。
中核責務
- 事業戦略・経営課題を起点に、変革のゴールとビジネス価値（投資対効果）を定義する
- 業務プロセスとケイパビリティ（企業の能力）の現状／あるべき姿を設計する
- 経営層・業務部門・技術者を結ぶ「翻訳者／調整役」として合意形成をリードする
- ビジネス要件を明確化し、デジタルで実現可能かを検証する
- 導入後の効果検証・KPIモニタリングまで見届ける
主な成果物
- ビジネスケイパビリティマップ
- バリューストリーム／プロセスフロー
- ビジネス価値仮説・ROIケース
- 変革ロードマップ
- 業務要件定義
スキル・背景
業務・経営コンサル、事業企画、プロセス設計、戦略構築、プロジェクトマネジメント、リーダーシップ。
他職種との境界
テクノロジー非依存でケイパビリティを語り、「どの事業課題を・なぜ・どの順で解くか」まで担う。「それをどのシステム構成で解くか」からがソリューションアーキテクトの領域。AIについては“使う事業判断”を担い、“作り・運用する技術判断”はAIアーキテクトへ渡す。
案件での位置
構想・企画フェーズの起点。全フェーズを俯瞰し、リスク最小化と予算・スケジュール遵守に責任を持つ。
ソリューションアーキテクト
問い：どの構成で解くか（WHICH・広く浅く）
ビジネス要件を受け、それを満たすシステム全体の構成・技術選定・統合設計を描く。ビジネスと技術を橋渡しし、トレードオフを提示して導入までリードする。
中核責務
- ビジネス要件・制約を受け取り、それを満たすシステム構成・技術選定の全体像を描く
- 複数システム・サービスをどう組み合わせ、連携させるかを設計する（統合設計）
- 抽象的な技術ビジョンを、実装可能な設計へ橋渡しする
- 潜在的リスク・課題を先読みし、選択肢のトレードオフを提示する
- 実装に至る活動全体をリードし、導入まで責任を持つ
主な成果物
- ソリューションアーキテクチャ図（論理・物理・デプロイ構成）
- データフロー図
- 技術選定・トレードオフ資料
- 統合設計書
- 非機能要件の初期定義
スキル・背景
システム設計、クラウド／インフラ、複数技術スタックの横断知識、要件定義、ステークホルダー調整。
他職種との境界
複数技術を横断的に“俯瞰”し「どの解き方・どの構成で解くか（WHICH）」を選ぶ、広く浅くの全体最適。特定技術を“深掘り”して動くシステムにするテクニカルアーキテクトと対をなす。ビジネスアーキテクトが定義した課題を受けて初めて動く、比較的リアクティブな役割。
案件での位置
要件定義〜アーキテクチャ設計フェーズの中心。上流（BA）と下流（TA）をつなぐ蝶番。
テクニカルアーキテクト
問い：どう作り、動かし続けるか（HOW・狭く深く）
ソリューションを、特定技術で実際に動くシステムへ具体化。性能・拡張性・可用性などの非機能に責任を持ち、開発チームを技術面でリードし、稼働し続ける状態を保つ。
中核責務
- ソリューションを統合された動くシステムへ落とし込み、開発チームを技術面でリードする
- ハードウェア／ソフトウェアの具体仕様など、深い技術的知見を提供する
- 非機能要件（性能・拡張性・可用性・セキュリティ・コンテナ等）に対処する
- インフラを継続的に監視・点検し、組織の目的と技術基盤の整合を保つ
- 新アプリケーションのスムーズなデプロイ・本番稼働を主導する
主な成果物
- 技術詳細設計
- 実装標準・技術ガイドライン
- 非機能要件仕様
- インフラ構成
- デプロイ／運用設計
スキル・背景
ソフトウェア／インフラエンジニアリング、特定技術スタックの深い専門性、性能・拡張性設計、DevOps／運用。
他職種との境界
特定技術を“深掘り”し「どう作り、どう動かし続けるか（HOW）」に責任を持つ、狭く深くの領域。ソリューションアーキテクトが全体構成を描き、テクニカルアーキテクトが一つの技術領域の“動く現実”を保証する。ビジネスアーキテクトとは対極（技術最下層 vs 事業最上流）。
案件での位置
実装〜デプロイ〜運用フェーズの中核。設計を現実に、そして稼働し続ける状態にする。
AIアーキテクト
問い：AIで何を実現し、どう安全に本番化するか
ML／生成AIのパイプライン、RAG、MLOps、AIガバナンス（ハルシネーション制御・安全性）を設計。AI-readyなデータ基盤とコスト最適化まで、AIライフサイクル全体を所有する。
中核責務
- 従来型MLとLLM／生成AIパイプラインのアーキテクチャを所有し、本番信頼性・ガバナンス・コスト最適化・セキュリティを担保する
- AIのためのデータ基盤設計（品質・リネージ・ラベリング戦略、学習／推論データの分離、フィーチャーストア）
- RAG（検索拡張生成）パイプライン設計：埋め込み生成、ベクトルDB連携、チャンク戦略、検索精度評価
- MLのCI/CD/CT（継続的学習）を設計し、再現可能な学習・自動テスト・統制されたデプロイを実現
- AIガバナンス：ハルシネーション制御、安全性モニタリング、バイアス検知、AI倫理・コンプライアンス
主な成果物
- AIリファレンスアーキテクチャ
- RAGサービステンプレート＋評価ハーネス（paved road）
- MLOps標準パターン
- AI本番リリース判定チェックリスト
- プロンプト評価フレームワーク
スキル・背景
ML／データサイエンス、MLOps／プラットフォームエンジニアリング、クラウドAIサービス、LLM／生成AIアーキテクチャ、セキュリティ・ガバナンス。
他職種との境界
一般のSA/TAが「システム全般」を横に見るのに対し、AIアーキテクトは「AIという縦串」を専門に深掘りする。モデル選定・RAG・MLOps・AIガバナンスは通常のSA/TAの守備範囲外で、ここが独自領域。ビジネスアーキテクトの「AIで何を実現するか」を受け、「それを技術的にどう安全・低コストに本番化するか」を担う。
案件での位置
AIユースケース構想からデータ整備、モデル／パイプライン設計、本番運用（MLOps）まで、AIライフサイクル全体を貫く。
どのアーキテクトが要るか、から相談できる。
「この変革に、どの職種を・何人・どの順で入れるべきか」——その布陣設計こそ、私たちの最初の仕事です。