規制産業の品質管理において、問題を解決するための組織の記憶は、ほとんどの場合、顧客履歴のどこかに埋もれています。昨年調査された類似の欠陥、根本原因を修正した是正予防処置(CAPA)、同じギャップを指摘した監査所見。そのような知識は、人間が言語やフォーマットを越えて意味的類似性で検索できない何十億ものドキュメントの中に眠っており、すべての調査はゼロから始まります。Octave Relianceは、各組織が複数のシステムにわたってドキュメントを収集し、より容易に検索し、すべてを管理できるよう支援してきました。 Octave Relianceチームは、この履歴を解き放つことを、顧客がより迅速に作業しコンプライアンスを維持できるようにする最大の機会と捉えました。障害も同様に明確でした。クレーム記録、監査所見、是正処置にはプラットフォームで最も厳格な分離要件が課されており、AIが読み取る必要があるのはまさにそれらの記録でした。医療機器、製薬、食品製造分野で14,000を超える顧客にサービスを提供するプラットフォームでは、ある顧客から別の顧客へ一度でも不注意による情報開示が発生すれば、AIのメリットをはるかに上回る規制上の結果をもたらします。
Octaveは180カ国で事業を展開し、Global Fortune 500の グローバルフォーチュン500の60%にサービスを提供しています。同社のクラウドネイティブな品質管理システムである Relianceは、クレーム管理やCAPAトラッキングから監査管理、サプライヤー品質まで、40以上のアプリケーションで650社を超えるエンタープライズ顧客を支援しています。誰もがAIが推論できる規制対象データを生成しています。各顧客は独立したテナントであり、いかなるデータもテナント境界を越えることはできません。
それに直面して、Relianceチームは異例の決断を下しました。単一のAI機能を出荷するのではなく、最初のサイクルを、今後のすべての機能がその上に載る基盤の構築に費やしたのです。この基盤により、以降、ユースケースごとのデプロイ時間が50%短縮されました。データが価値を持つ一方で、分離が譲れない条件であるソフトウェア as a サービス(SaaS)プラットフォームにAIをもたらす場合、その考え方は品質管理の枠を超えて通用します。この記事では、設計を形作った4つの緊張関係と、Amazon Bedrock上でCohere Embed v4を使ってOctaveが構築した3層基盤を解説します。次に、20億件のドキュメントを埋め込んだパイプラインと、本番環境でその実証となったComplaint Triage Assistantを追います。
なぜ機能ではなく基盤なのか
AWSとのビジョニングワークショップでは、クレームの要約とトリアージ、監査準備状況のモニタリング、インシデントナラティブの生成、予測的な品質リスクスコアリングという、4つの高インパクトなユースケースが浮かび上がりました。また、何十ものアプリケーションを経た後に、後のすべてを形作る洞察も得られました。それぞれ異なるドキュメントタイプとワークフローを持つこれらのアプリケーションの一つをサイロでAI対応すると、次のためにはインフラを再構築しなければならないという洞察です。
そこでチームは計画を逆転させました。まず横断的なプラットフォームを構築し、そこに縦断的な機能スライスを切り込んでいく方式です。クレームの要約とトリアージが最初に実装され、他が続く前にアーキテクチャを実証しました。
4つの緊張関係
単一のモデルを選定する前に、チームは異なる方向へ引っ張り合う4つの問題に時間を費やしました。どれも切り捨てられるものではありませんでした。
不注意による情報開示のリスクを冒さずにデータを利用可能にすること。 クレーム記録、CAPA、標準操作手順書(SOP)、監査所見は1つのテナントに属し、他のテナントから到達不可能でなければなりません。誤ったAIクエリでさえ境界を越えてはなりません。ベクトルストア、検索ロジック、生成コンテキストのすべてを単一テナントにスコープする必要がありました。
エージェントを分離環境で実行すること。 エージェントのツール、データストア、モデルエンドポイントを統括する権限は、共有サービスロールではなく要求元ユーザーにスコープされ、実行中のみ利用可能で、そのユーザーのアクセス権を尊重するものでなければなりませんでした。静的認証情報を持つ共有エージェントプールでは、3つの要件すべてを満たせませんでした。
信頼できないコンテンツを読み取ること。 ここのエージェントは、組織の外部からのクレーム、メール添付ファイル、スキャンされたPDF、画像を取り込みます。大規模言語モデル(LLM)アプリケーション向けOWASP Top 10(2025)は、直接当てはまる脅威を挙げています:取り込まれたコンテンツ経由のプロンプトインジェクション(LLM01)、機密情報の開示(LLM02)、不適切な出力処理(LLM05)、過剰なエージェンシー(LLM06)。この規模において、添付PDFに隠された命令は仮定の話ではありません。
四半期をかけずに20億件のドキュメントを埋め込むこと。 Relianceは20億件を超えるドキュメントをホストしており、個々のテナントは数百万件のWordファイル、PDF、スキャンフォーム、スプレッドシート、画像、メールを保存しています。チームは、最大のテナントであっても1営業日以内にオンボーディングすることを約束しました。これらのドキュメントは規制上の意思決定に影響するため、品質をスループットと引き換えにすることはできません。見逃されたクレーム1件が、システム全体への信頼を損ないます。
アーキテクチャの着地点
4つの制約を同時に満たすことは、選択肢を大幅に絞り込みました。Amazon Bedrockはこれらを1つのプラットフォームとして処理しました。単一のAPIによるマルチモデルアクセス、AWSアカウントがすでに適用しているAWSリージョンでのデータ保管と、 AWS Identity and Access Management (IAM) ガバナンス、そして構築すべきものではなく本番環境のコンテンツ管理としてのGuardrailsです。
その基盤は、Figure 1に示す3つのレイヤーに整理されます。データ準備では、品質に関するドキュメントを Amazon Bedrock上のCohere Embed v4 で埋め込み表現に変換し、 Amazon OpenSearch Service上のテナントごとのベクトルストアに書き込みます。セキュアな実行では、ユーザーのリクエストを AgentCore Gateway、つまり Amazon Bedrock AgentCoreの機能を通して渡します。これは認証とポリシーを適用したうえで、Amazon Bedrock上のAnthropic Claudeモデルを呼び出す分離されたmicroVMセッションにリクエストを引き渡します。この両方を包み込む形で、コンテンツ保護ではAmazon Bedrock Guardrailsを2回適用します。入力時の入力フィルタリングと、何かがハンドラーに届く前の出力フィルタリングです。検索、実行、スクリーニングはそれぞれ独立したステージに保たれるため、各段階を個別に強制し、個別に証明できます。
Figure 1: Reliance AI基盤のハイレベルなアーキテクチャ
データの表現方法の選択
ドキュメントが検索可能になるまで、他の何もうまくいきませんでした。それは、言語や形式を越えて正確に、しかしテナントの境界を越えずに検索できるという意味でした。チームは公開のリーダーボードではなく、自社のコーパスに対して埋め込みモデルを評価しました。決め手となった問いは、このデータに特有のものでした。ひび割れたハウジングの写真は、それを記述する段落とどのように関連するのか、ドイツ語のクレームは英語のCAPAとどう結びつくのか。
Amazon Bedrock上のCohere Embed v4は5つの点で優れており、それらは互いに独立したものではありませんでした。最初に決まったのは、パイプラインのどれだけを不要にできるかという点でした。品質記録には、テキストとともに、欠陥製品の写真、スキャンされた検査フォーム、注釈付きの図面が含まれます。Embed v4は両方のモダリティを1つのベクトル空間に配置します。ひび割れたハウジングの写真とその欠陥を記述する段落は、1つのクエリで検索でき、モダリティごとの個別パイプラインは不要です。ネイティブの多言語サポートは、もう一方の軸でも同じ働きをします。ドキュメントは複数の言語で、多くの場合1つのテナントのコーパス内に混在して届きますが、翻訳の前処理は不要です。チームが構築せずに済んだ2つのパイプライン、そしてドキュメントが検索から漏れる可能性のある箇所が2つ減りました。
残りの3つの点は、ベクトルをどこに置けるか、そしてどのくらいのコストがかかるかで決まりました。顧客データは推論のためであっても、そのAWSリージョンから出ることはできません。そのため、Amazon Bedrockでのリージョン内モデル提供は、利便性ではなく前提条件でした。Embed v4は、米国東部 (バージニア北部) リージョン (us-east-1)、欧州 (アイルランド) リージョン (eu-west-1)、アジアパシフィック (東京) リージョン (ap-northeast-1) でのリージョン内推論をサポートしており、Octaveのリージョンコンプライアンス要件3つのうち3つをカバーします。モデルと機能の利用可否はリージョンによって異なり、時間とともに変化します。最新の対応状況については、Amazon Bedrockユーザーガイドの モデル別リージョン別提供状況 を参照してください。各リージョン内で、Amazon OpenSearch Serviceのコストは次元数に比例して増加します。そのため、Embed v4の256〜1,536という設定可能な出力次元は、デフォルトのまま受け入れるのではなく、テストする価値がありました。代表的な本番クエリに対するテストでは、1,536次元のデフォルトと比べてストレージを約66%削減しながら、512次元で目標精度を維持できることが示されました。128Kトークンのコンテキストウィンドウは、まったく別の場面で効果を発揮しました。約4Kトークンのチャンクを1リクエストに多数詰め込めることが、オンボーディングのスループットの源泉となったのです。
実行時におけるテナントの分離
より難しい問いは、テナント分離をどこで強制するかでした。アプリケーションコードでも実現できましたが、それは今後すべての機能チームがすべてのコードパスで正しく実装することを意味し、チェックを1つ見逃すだけで意図しないテナント間の情報漏洩のリスクが生じます。チームは代わりに、分離を実行時環境に押し込みました。Amazon Bedrock AgentCoreの機能であるAgentCoreランタイムは、アプリケーションレイヤーより下で分離を強制します。さらに、フレームワークにもモデルにも依存しないため、Complaint Triage Assistant向けに選択されたエージェントフレームワークやモデルは、この分離の決定によって制約を受けませんでした。
各ユーザーセッションは、専用のCPU、メモリ、ファイルシステムを備えたmicroVMで実行され、セッション終了時に停止・サニタイズされます。これは、エージェントがどのように動作しても耐えられるように設計された、ハードウェアレベルの分離です。AgentCoreは認証済みユーザーのIDを実行チェーン全体に引き継ぎます。ユーザーごとのOAuthトークンボールトが、共有サービスIDではなくその特定のユーザーのためにエージェントが動作することを検証し、認証情報はエージェントごとにスコープされ、セッション中のみ有効です。AgentCore Gatewayは、ツール、オペレーション、パラメータのレベルで認可を行います。自動推論は、定義されたルールに対する形式的検証を提供します。これはIAMや Amazon Simple Storage Service (Amazon S3) のポリシー検証を支えるのと同じ規律です。Figure 2は、この分離を2つのテナントにわたって示しています。
Figure 2: テナント間のAgentCoreセッション分離。各microVMは使用後に停止され、メモリはサニタイズされます。
したがって、テナントAの品質担当者から提出された苦情は、Amazon Bedrock AgentCoreの機能であるAgentCore Code Interpreter内のテナントAのトークンボールト、ツール、サンドボックスにのみ到達します。テナントBのセッションには、これらに至る経路は一切ありません。
取り込まれたコンテンツを信頼できないものとして扱う
この緊張関係にすっきりした答えはありませんでした。苦情の添付ファイルは信頼できない入力ですが、同時にエージェントが存在する理由である読み取り対象でもあるため、疑わしいコンテンツを拒否することはできませんでした。チームは多層防御に落ち着きました。
Octaveの適用 Amazon Bedrock Guardrails をエージェントロジックの内部ではなく外部に、苦情ワークフローの3か所に適用しました。ApplyGuardrail APIは、添付ファイルから抽出されたテキストをエンベディング前に評価し、取得されたドキュメントとツール出力をエージェントのコンテキストに入る前に評価し、生成されたブリーフを品質担当者が目にする前に評価します。添付ファイル由来のコンテンツは入力タグ付けとともに渡され、指示ではなくデータとしてマークされます。これこそが、ドキュメント途中に埋め込まれたインジェクションを検出可能にする仕組みです。個人識別情報(PII)は流入時にマスキングされます。
検出だけでは十分ではなかったため、その下に制限付きのエージェント機能が置かれています。エージェントに何を求められても、AgentCore Gatewayが引き続き呼び出し可能なツールを管理し、ドキュメント抽出はネットワークエグレスなし、セッションを超える永続化なしのAgentCore Code Interpreterサンドボックスで実行されます。PDFに隠されたペイロードは、1つの層ではなくすべての層を突破しなければなりません。
その効果: 検出率とマスキング率がテナントごとに追跡されており、スクリーニングで捕捉した内容は、Octaveが主張するだけでなく証拠として示せるものになっています。
20億ドキュメントをパイプラインに通す
エンベディングモデルの手前にあったのは、より難しい問題でした。Wordファイル、スプレッドシート、デジタルPDF、スキャンページ、写真、メールスレッドから使用可能なコンテンツを抽出することです。複数の言語が登場し、時に1つのレコード内に混在します。しかも、オンボーディングが四半期ではなく1日で済むほど高速に実行する必要がありました。図3は、その結果としてのパイプラインをエンドツーエンドで示しています。
図3: インジェストパイプライン: アプリケーションプラットフォームからStep Functionsオーケストレーションを経由してテナントごとのOpenSearchインデックスに至る、イベント駆動型ドキュメント処理。
ドキュメントイベントは、Amazon Simple Notification Service (Amazon SNS)とAmazon Simple Queue Service (Amazon SQS)を通じてAWS Step Functionsステートマシンにファンアウトします。このステートマシンは、専用のAmazon Virtual Private Cloud (Amazon VPC)内で、並行するAWS Lambda実行にわたってパース、チャンキング、エンベディングをオーケストレーションします。並列性が1つのリソースをスケーリングするのではなくバッチを実行間でファンアウトすることで得られるため、アーキテクチャを再設計することなくスループットが向上します。
パースがこの異質さに対応します。Wordファイルとスプレッドシートからセマンティック階層を保持し、テキストレイヤーのないスキャンPDFには光学文字認識(OCR)を適用し、埋め込み画像は第一級のコンテンツとして扱います。チャンクにはメタデータ(テナント、ドキュメントタイプ、ソースアプリケーション、言語、コンテンツハッシュ)が付与されます。このメタデータが、検索フィルタリングとテナントごとの名前空間強制の両方を駆動します。
スループットはパッキングから得られました。多くの4Kチャンクを単一のリクエストに織り交ぜてEmbed v4の128Kコンテキストウィンドウに送ることで、大規模コーパスのAPI呼び出しを約1桁削減しました。Amazon BedrockでのOctaveの社内テストでは、Embed v4は毎分2,800万トークンを処理しました。Cohereのソリューションアーキテクトとともにメモリボトルネックが解消されるまでバッチサイズをチューニングした後、パイプラインはテナントあたりのワークロードで24時間あたり140万ドキュメントを維持しました。これが、稼働1日でのコミットメントを現実のものにしました。
苦情トリアージアシスタント
ある病院が医療機器メーカーに欠陥のある注射器を報告し、その記録にはメール、損傷した製品の写真、裏付けとなるドキュメントが添付されて届きます。品質担当者はこれらの形式にまたがって文脈を組み立て、同様の報告が過去にあるかを調べ、それがどのように解決されたかを突き止めなければなりません。その後で初めて優先度を割り当てることができ、多くの場合、数日単位で測られる報告期限の中で行われます。
このアシスタントは、AWSがオープンソース化したStrands Agents SDKで構築されています。これはエージェント的ワークフローをグラフとして構成し、ノードをツール呼び出しまたはモデル呼び出し、エッジをそれら間のデータ依存関係として表現します。AgentCore runtimeがこのグラフを実行し、セッションごとに分離します。5つのステージが、生の添付ファイルから完成したブリーフまで苦情を運びます。
まずドキュメント抽出が行われます。PDF、画像、メール添付ファイル、動画はすべてAgentCore Code Interpreterに入り、各アーティファクトが構造化された中間表現にパースされます。次にAmazon Bedrock上のClaudeモデルがレコードを要約し、生の数千トークンのソースではなく、その要約が検索クエリとなります。検索は、テナントのEmbed v4エンベディングのOpenSearchインデックスに対して実行され、類似する過去の苦情とそのCAPAを提示します。AgentCore Gatewayが、許可された名前空間のみに到達できることを強制します。
返された結果は、類似性だけでは信頼されません。別のモデル呼び出しが結果を信頼度でスコアリングし、語彙は共通していても根本原因が異なる一致を破棄します。生き残ったものは合成に渡され、Amazon Bedrock上のAnthropic Claude Sonnetが出力を組み立てます。主要な事実、センチメント、緊急度の指標、最も近い過去の記録とその結果、推奨されるトリアージ優先度です。
完成したブリーフは、環境ごとのtime to live (TTL)付きでAmazon DynamoDBにキャッシュされるため、繰り返しの閲覧には追加コストがかかりません。品質担当者はゼロからではなく、組織の記憶から作業を始められるのです。
図4は、そのエンジンをプライベートAPI境界の背後に配置したものです。ポータルのリクエストは、プライベートなAmazon API GatewayとLambda関数を通じてAgentCore runtimeに到達し、検索はプレサインURLによるロールベースアクセスを通じてドキュメントインデックスを読み取ります。一方、添付ファイルはAmazon S3に保持されます。キャッシュされた要約とOpenTelemetryトレースは、要約テーブルと評価ダッシュボードに出力されます。
図4: 要約エンジン:AgentCoreを活用したワークフローが、プライベートAPI境界内でドキュメント抽出、検索、推論、および合成を処理し、応答キャッシュと完全なオブザーバビリティを備えています。
図5は、同じ経路を1本の線に簡略化したもので、両端にGuardrailsフィルタリングが配置されています。
図5：取り込みから担当者への出力までの苦情トリアージアシスタントのパイプライン
エージェントが何をしたかを証明する
ここでのオブザーバビリティは、エンジニアリングチームがどのようにデバッグするかというだけでなく、コンプライアンス要件を満たすためにシステム監査機能とどのように統合するかという側面も持ちます。監査人は、ある苦情がなぜそのようにトリアージされたのかを問うことができますが、「モデルが判断した」という答えはその対話を乗り切ることはできないでしょう。
AgentCoreは、グラフのすべてのノードにわたってOpenTelemetry互換のトレースを取得します。各モデル呼び出し、検索、AgentCore Code Interpreterの実行が対象です。数か月後、Octaveは特定のブリーフを生み出した取得ドキュメントやプロンプトを表示できます。Amazon Bedrockのモデル呼び出しロギングは、AgentCoreが伝播するIAM IDを通じてスコープされ、すべてのリクエストとレスポンスのテナントごとの記録を追加し、コストはAmazon CloudWatchで起動元のテナントに帰属します。
オフラインでは、AgentCore Evals が、プロンプト、モデル、または検索パラメータに変更が加えられるたびに、専門家によってアノテーションされたグラウンドトゥルースに対してワークフローを再実行し、要約の忠実度、K における検索精度、および出力の完全性を報告します。読みやすくなっても検索性能が落ちたプロンプトは、ユーザーが目にする前に検出されます。
結果
苦情トリアージアシスタントは本番環境で3か月間稼働しており、以下の数値はその期間のものを反映しています。
以前は何もない状態から調査を開始していたハンドラーは、今では関連する履歴がすでにまとめられた状態で調査を開始します。Octaveが1件の調査あたりに計測する4〜6時間は、このパイプラインが担っていた仕事です。すなわち、各形式にわたる情報の抽出、類似事例の探索、そして本当に類似した欠陥を言い回しの偶然と見分けるために必要な読解作業です。
財団はOctaveのリリース速度も変えました。同財団自身の説明によれば、新しいAI機能の開発サイクルは数か月から数週間に短縮されました。共有データ準備、セキュア実行、検索はFigure 1の3つのレイヤーです。これらによりユースケースごとのデプロイ時間は50パーセント削減されました。新しい機能は毎回これらを再構築するのではなく、これらを継承するためです。その結果、セマンティック検索は第2四半期に提供され、当初の第4四半期目標から2四半期早い実現となりました。
振り返って
まず基盤を構築するという決定は、チームが最も後悔した（と一時は考えた）選択だった。ステークホルダーが目に見えるAI機能を望んでいるとき、数か月に及ぶインフラ作業を正当化するのは難しい。次のラウンドのユースケースがその価値を証明した。それを支えたのは2つの選択だった。すなわち、アプリケーションコードではなく、microVMセッションへの分離の押し込みとID伝播、そしてOctave自身のコーパスに対して評価された埋め込みモデルであり、これによりベンチマークでは決して見えなかった512次元のトレードオフが明らかになった。
チームはまた、越えないと決めた一線も引いた。アシスタントは文脈や先行事例を提示する。最終判断を下すのは依然として品質担当者である。その判断に規制上の重みが伴う業界において、この境界線が何を自動化し何をしないかを形づくった。
次に何が起こるのか
Octaveは現在、この基盤をRelianceスイート全体へと拡張しています。次の機能として、監査対応状況のモニタリング、インシデント報告書の生成、予測型品質リスクスコアリングが控えており、いずれも同じインフラストラクチャの上に構築されます。
お使いのプラットフォームが、厳格な分離要件の背後にある貴重なデータという同様の緊張関係に直面している場合、Octaveの経験はそのトレードオフが実現可能であることを示しています。このストーリーの背景にあるサービスの詳細については、以下をご覧ください。 Amazon Bedrock、その Amazon Bedrock AgentCore ドキュメント、および Cohere on Amazon Bedrock。関連するアーキテクチャのガイダンスについては、次を参照してください: AWSベクトルソリューション:データが存在する場所でエージェンティックAIを構築 および エージェント型AIのスケーリング:ベンダーロックインなしで実現するエンタープライズパターン.