AI システム設計：アイデアから本番環境へ MongoDB アポルバ・ジョシュイ

AI システム設計：コードを書く前に「仕様」こそが新時代のコードである

生成 AI の登場により、コードを生成してすぐにリリースすればいいという考えは、実は危険な短絡行為です。本番環境で信頼性の高い AI アプリケーションを構築するためには、コーディングよりも先に「製品要件の定義」と「堅牢なシステム設計」が最も重要な工程となります。

この動画では、MongoDB のアポルバ・ジョシュイ氏が、医療保険請求審査という実用例を通じて、アイデアから本番環境へ至るまでの反復可能な 4 フェーズのフレームワークを解説します。AI エージェントを安易に複雑化させるのではなく、単純な設計から始め、評価と監視を経て改善していくアプローチが、リスク管理が求められる現代において不可欠であることが説かれます。

「仕様こそが新しいコード」：コーディング依存からの脱却

AI コーディングツールの普及により、実装のハードルは劇的に下がりました。しかし、Anthropic や OpenAI の関係者も指摘するように、「仕様こそが新しいコード」という事実を無視してはいけません。

趣味のプロジェクトやリスクの低いタスクであれば、ツールに任せてすぐにリリースしても問題ないかもしれません。しかし、他人の生活やビジネスに影響を与えるシステムにおいて、安易なコーディング依存は危険です。真の技術力は、AI に何を作らせるかを定義する「製品要件」を明確にする芸術にあります。

「仕様こそが新しいコード。真の技術は、製品の要件を定義する芸術にある。」

この認識の転換なくして、本番環境で機能する AI システムは構築できません。まずは「何を」「誰のために」「どのような制約の中で」作るのかを明確に定義することから始めなければなりません。

4 フェーズの構築フレームワーク：アイデアから本番へ

AI システムを成功させるためには、以下の 4 つのフェーズを構造化して進めることが推奨されます。これらは直線的なプロセスではなく、評価結果に基づいて改善を繰り返す反復的なサイクルです。

1. 製品要件定義：何を、誰のために作るか

まずはシステムの詳細やアーキテクチャを決めず、ビジネス課題とユーザーの痛みを定量化します。

• ビジネス課題の特定: 誰が、どのような問題に直面しているのかを明確にします。例：「医療レビュー担当者が請求審査に平均 2 日かかり、緊急ケースでは患者ケアが 12 倍遅れている」
• 制約条件の収集: 規制遵守（コンプライアンス）、データ移転の制限、承認されたベンダーの使用可否など、設計前に知っておくべきハードルを洗い出します。
• AI の役割定義: AI は不可欠か補完的か、反応型か能動型か、自律性のレベルはどれくらいかを 3 つの次元で整理します。これにより、システムが「半自律」や「人間によるレビュー必須」といった制約をどう扱うかが見えてきます。
• 成功指標（KPI）の設定: 具体的で測定可能、達成可能かつ期限付きの目標を設定します。例：「緊急請求の平均処理時間を 2 日から 1 日に短縮し、ローンチから 90 日以内に達成する」

2. システム設計：データとアーキテクチャの選択

要件が固まったら、具体的な「どのように」を設計します。ここで重要なのは、いきなり複雑なマルチエージェントシステムを構築しないことです。

• データ戦略: 必要なデータ（臨床ガイドライン、給付方針、患者履歴）がどこにあり、どう更新されるかを把握します。長文書はチャンク分割して埋め込み、メタデータを抽出し、ベクトル検索やハイブリッド検索に適した形式に変換する必要があるか検討します。
• 検索手法の選定: 医療用語のような専門的なキーワードはベクトル検索で見逃される可能性があるため、メタデータフィルタリングやキーワード検索を併用する「ハイブリッド検索」が有効です。
• アーキテクチャパターンの選択:
• RAG（Retrieval Augmented Generation）: 外部知識源（ガイドライン等）を補強するために必須。
• 制御フロー: ワークフローの手順を事前に設計し、LLM が特定のタスクを実行するパターン。複雑なケースでは人間へのエスカレーションルールもここに組み込みます。
• ヒューマン・イン・ザ・ループ: 最終決定や拒否判断など、AI の判断が不十分な場合に人間の介入を必須とする設計。
• UX とフィードバック: ユーザーは入力として何を受け取り（請求書フォーム）、出力として何を返すか（承認/拒否と根拠）。システムはどこに埋め込まれ、人間はどのようにフィードバック（判断の覆しや誤りのフラグ付け）を行うかを設計します。

3. 評価と監視：確率的なシステムのガバナンス

LLM ベースのシステムは確率的であるため、従来のソフトウェアとは異なる「ガードレール」が必要です。これは予期せぬ有害出力を防ぐための安全装置です。

• 入力ガードレール: 「詩を書いて」といった無関係な入力を検出し、拒否する仕組み。
• 出力ガードレール: ハルシネーション（事実と異なる生成）や誤った根拠の提示を検出する仕組み。医療現場では、引用元が正しいかを確認する機能も重要です。
• 評価 vs 監視: リリース前の「評価」で精度を担保し、リリース後の「監視」で本番環境での挙動を継続的に確認します。両方がなければ、システムは信頼されません。

4. コスト最適化：精度とコストのバランス

最後に、精度だけでなくコストやレイテンシも最適化するフェーズです。モデル選定（埋め込みモデル、ベクトルデータベース、オーケストレーションフレームワーク）を制約条件に基づいて行い、必要に応じてファインチューニングを検討します。

過剰設計の回避：シンプルさから始める重要性

本番環境での AI アプリ開発で最も陥りやすい罠は、「過剰設計」です。AI エージェントやマルチエージェントシステムに注目が行きがちですが、いきなり複雑なアーキテクチャを構築すると、バグの原因となり、修正が困難になります。

「最もシンプルな設計から始め、評価し、ギャップを見つけ、そこから改善を繰り返す。」

まずは RAG や制御フローなど、要件を満たす最小限の機能を実装します。その結果、評価フェーズで精度不足や遅延などの課題が見つかれば、その時初めて複雑なエージェント機能やファインチューニングを追加すればよいのです。

まとめ：堅牢な設計こそが実用化への鍵

生成 AI を活用したシステム構築において、コードを書くことよりも「製品要件の定義」と「システム設計」が重要であるという認識は、医療や金融といった規制が厳しい業界で特に重要です。複雑なエージェントを安易に組み込むのではなく、単純な設計から始め、評価と監視を経て改善していく反復プロセスこそが、リスクを管理し、本番環境で信頼される AI アプリケーションを生み出す鍵となります。