Well-Architected Framework:AI ネイティブトランスフォーメーション

非決定的な出力

従来のソフトウェアシステムは決定論的なロジックに従います。同じパラメータで同じインターフェースを呼び出すと、常に同じ結果が得られます。AI ワークロードは、この前提を根本から覆します。大規模言語モデルは、全く同じ入力であっても、推論を実行するたびに異なる出力、つまり異なる言葉遣い、構造、あるいは結論さえも生成する可能性があります。

企業のカスタマーサービスのシナリオを考えてみましょう。ユーザーが「注文した商品はいつ届きますか？」と尋ねた場合、従来のシステムはデータベースで物流状況を照会し、確定した日付を返します。対照的に、AI を活用したカスタマーサービスエージェントは、同じ物流情報を取得した後、ある時は「ご注文の商品は明日の午後に到着する予定です」と答え、またある時は「配送情報に基づくと、お荷物は6月21日 14:00 までにお届け先住所に配達されます」と答えるかもしれません。2 つの応答は意味的には同等ですが、表現は全く異なります。この非決定性により、従来型の完全一致に基づく自動テスト手法は無効になり、アーキテクトは意味レベルの品質評価フレームワークを導入する必要があります。

大規模言語モデルで対話型アプリケーションを構築する際、temperature パラメータを 0 に近い値に設定することでランダム性を低減できます。しかし、これでも非決定性を完全になくすことはできません。モデル内部の浮動小数点演算の精度や、異なるハードウェア上での計算順序の違いといった要因が、依然として出力の微妙なズレを引き起こす可能性があります。したがって、AI システムのテスト戦略は、「出力が正しいかどうかを検証する」から「出力が許容範囲内にあるかどうかを検証する」へと転換しなければなりません。

これに対処するため、アーキテクトは意味レベルの評価システムを確立する必要があります。このシステムは、従来の「出力が期待値と等しいか」というチェックを超え、多次元のスコアリング (関連性、正確性、完全性、安全性) を用いて品質のベースラインを構築し、品質ドリフトを継続的に監視します。

主観的かつ文脈依存の品質

AI システムでは、「良い」の定義が非常に複雑になります。同じ文書の要約でも、経営幹部向けには戦略的な洞察を抽出し、エンジニア向けには技術的な詳細を保持し、法務チーム向けにはリスクエクスポージャーを強調する必要があります。「絶対に正しい」単一の要約は存在せず、品質の判断はユースケースと受け手の期待に完全に依存します。

この主観性は、製品レベルで深刻な影響を及ぼします。従来のソフトウェアの欠陥は、単体テストや結合テストを通じてデプロイ前に発見できます。対照的に、AI システムの「品質欠陥」は、特定のビジネスコンテキストでのみ表面化することがよくあります。医療相談アシスタントからの回答が医学的に正確であっても、専門用語が多すぎて患者が理解できなければ、そのシナリオでは「低品質」と見なされます。

エンジニアリングの実践において、これは品質評価を階層化する必要があることを意味します。基盤層では事実性、安全性、フォーマット準拠をチェックし (自動化可能)、ビジネス層では情報の完全性と論理的一貫性を評価し (半自動化可能)、エクスペリエンス層ではトーン、詳細度、受け手への適合性を判断します (手動サンプリングが必要)。

使用量に応じたコスト

従来のクラウドアーキテクチャのコストは、主にサーバー数、ストレージ容量、ネットワーク帯域幅などのインフラストラクチャリソースに連動していました。AI ワークロードは、トークン消費という新たなコスト次元を導入します。各モデル呼び出しは、入力および出力トークンに基づいて課金されるため、コストはビジネス量とリクエストの複雑さに直接比例します。

企業の Q&A システムを考えてみましょう。ある推論モデルのコストが入力 1,000 トークンあたり A ドル、出力 1,000 トークンあたり B ドルかかると仮定します。ここで B は通常 A の 2 倍から 4 倍です。1 回の 8,000 トークンのやり取り (入力 7,000、出力 1,000) には、約 7A + B のコストがかかります。これを 1 日あたり平均 100 万リクエストで乗じると、月々の推論コストは著しく増大する可能性があります。より多くのパラメータを持つモデルを選択すれば、A と B は 5 倍から 10 倍に増加する可能性があります。さらに重要なのは、検索拡張生成 (RAG) システムがより多くのコンテキストを取得し、エージェントがより多くのツール呼び出しを行うにつれて、リクエストあたりのトークン消費量は膨らみ続け、コストを予想をはるかに超えるレベルまで押し上げる可能性があることです。

トークンエコノミクスは、アーキテクトにコストを主要なアーキテクチャ上の制約として扱うことを要求します。これは、よりコスト効率の高いモデルを選択する (たとえば、単純なクエリには Qwen-Max の代わりに Qwen-Plus を使用する) だけでなく、コンテキストウィンドウの圧縮、キャッシュヒット率の最適化、複雑度に基づくリクエストルーティングなど、アーキテクチャレベルでコスト管理メカニズムを設計することも意味します。Model Studio プラットフォームでは、モデルルーティング機能を使用して、リクエストの特性に応じて異なる仕様のモデルを動的に選択し、品質要件を満たしながらトークンの支出を最小限に抑えることができます。

拡張されたサプライチェーン

従来のソフトウェアでは、サプライチェーンのリスクは主にコードの依存関係とインフラストラクチャに集中していました。たとえば、オープンソースライブラリに脆弱性があるか、コンテナイメージが信頼できるか、といった点です。AI ワークロードは、サプライチェーンを前例のない範囲にまで拡張します。モデルの重み、トレーニングデータ、ファインチューニング用のデータセット、プロンプトテンプレート、評価ベンチマーク、さらには RAG システム内のナレッジベースドキュメントまで、すべてがサプライチェーンの構成要素となり、各リンクが攻撃対象領域になり得ます。

モデルのサプライチェーン攻撃は複数発生しています。攻撃者は、オープンソースのモデルリポジトリに、巧妙に汚染されたモデルの重みファイルを公開しました。表面的にはモデルは正常に機能しますが、特定のトリガー条件下でユーザーの入力データを漏洩させたり、有害なコンテンツを生成したりする可能性があります。企業がこのようなモデルを厳格な検証なしに本番環境にデプロイした場合、その結果は壊滅的なものになりかねません。

さらに、プロンプト自体もサプライチェーンのリスクをもたらします。企業は、中核となるプロンプトテンプレートをバージョン管理システムや設定センターに保存することが多いですが、プロンプト変更に対する監査や承認プロセスが欠けていることがよくあります。レビューされていない 1 つのプロンプトの変更が、コンテンツセーフティフィルターをバイパスしたり、システム指示に含まれる機密性の高いビジネスロジックを漏洩させたりするなど、モデルの振る舞いに根本的な変化を引き起こす可能性があります。

必須のコンプライアンス

中国は、生成 AI に関する世界的な規制の最前線にいます。2023年に施行された「生成AIサービス管理暫定弁法」は、一般向けに生成 AI サービスを提供する企業はアルゴリズムの届出を完了しなければならないこと、生成されるコンテンツは社会主義の核心的価値観を反映しなければならないこと、サービス提供者はトレーニングデータのソースの合法性に責任を負うこと、そしてユーザーは人間ではなく AI と対話していることを知る権利があることを明確に定めています。

アルゴリズムの届出は、一度きりのコンプライアンス活動ではなく、継続的な義務です。ベースモデルのバージョン切り替え、中核となるプロンプト戦略の変更、新しいトレーニングデータの導入など、モデルが大幅に更新されるたびに、新たな届出が必要になる場合があります。これはアーキテクチャ設計に明確な要求を突きつけます。システムは、モデルバージョンの追跡、トレーニングデータの来歴、生成コンテンツの監査に関する完全な機能を備えていなければなりません。

Alibaba Cloud では、Model Studio と Alibaba Cloud Content Security のコンテンツモデレーション機能が、コンプライアンスのための技術的基盤を提供します。しかし、アーキテクトは、コンプライアンスが単にリリース前にフィルターを追加するだけの問題ではないことを理解しなければなりません。それは、データ取り込み時のソースタギングやモデルトレーニング時のデータクレンジングから、推論時のコンテンツモデレーション、サーバーサイドのログ保持とトレーサビリティまで、アーキテクチャのあらゆる層にコンプライアンス要件を織り込むことを意味します。

急速なモデルの進化

AI 分野の技術的イテレーションのペースは、従来のソフトウェアエコシステムをはるかに上回ります。Qwen シリーズのモデルは、Qwen から Qwen2、Qwen2.5、そして Qwen3 へと、2 年間で複数回のメジャーバージョンアップを遂げました。各アップグレードは、大幅な機能向上と軽微なインターフェースの変更をもたらします。今日、慎重に調整されたプロンプト戦略が、次のモデルバージョンではパフォーマンスが低下する可能性があり、今日モデルのファインチューニングに投じたリソースが、新しいベースモデルの機能向上によって不要になる可能性もあります。

この急速な進化から得られるアーキテクチャ上の重要な教訓は、AI システムはモデルの交換可能性を考慮して設計されなければならないということです。モデル呼び出しを統一されたインターフェースに抽象化し、プロンプトをバージョン管理し、新しいモデルで迅速なリグレッションテストを行うために評価ベンチマークを永続化することは、すべて必要なアーキテクチャへの投資です。Model Studio プラットフォームでは、アプリケーション設定とモデル設定を分離することで、アプリケーションコードを変更することなく基盤となるモデルを切り替えることができ、モデルのイテレーションに伴うエンジニアリングの負担を大幅に軽減します。

同時に、アーキテクトは「過剰最適化の罠」に注意する必要があります。6 ヶ月後には時代遅れになるかもしれないモデルに、過度なカスタムエンジニアリングを投資することは避ける必要があります。モデルの能力が急速に向上している段階では、軽量なプロンプトエンジニアリングや検索拡張生成 (RAG) の方が、重量級のモデルのファインチューニングよりも高い投資対効果をもたらすことがよくあります。これは、前者の最適化の方が新しいモデルに移行しやすいからです。

品質 vs. コスト

より大きなパラメータ規模を持つモデルは、通常、より良い理解力、より正確な推論、より流暢な表現を提供しますが、それはまた推論コストが何倍にも増加することを意味します。Qwen シリーズを例にとると、Qwen-Max は複雑な推論タスクにおいて Qwen-Plus よりも著しく優れたパフォーマンスを発揮しますが、呼び出しあたりのコストも数倍高くなります。

1 日に 50 万件のユーザーからの問い合わせを処理するインテリジェントカスタマーサービスシステムで、すべてのリクエストを Qwen-Max にルーティングすると、月々の推論コストは 100万元 を超える可能性があります。しかし、すべてのリクエストで Qwen-Plus を使用すると、複雑な質問への回答の品質が大幅に低下し、ユーザー満足度の低下や人間のエージェントへのエスカレーション率の上昇につながります。

このトレードオフを解決するためのアーキテクチャパターンは、インテリジェントルーティングです。軽量なインテント分類器を使用してリクエストの複雑さを判断します。単純なクエリ (「営業時間は？」など) は Qwen-Plus にルーティングし、多段階の推論を必要とする複雑なクエリ (「プランAとプランBの長期的なコストを比較して」など) は Qwen-Max にルーティングします。大規模モデルの応用シナリオでは、ワークフローのオーケストレーションを使用してこの階層的なルーティングを実装し、品質目標の達成とコスト管理の間でパレート最適な解決策を見つけることができます。しかし、ルーティング戦略自体にもコストがかかります。分類器の誤判断は品質の損失や無駄な支出につながる可能性があるため、ルーティングの精度を継続的に監視し、最適化を繰り返す必要があります。

1 日あたりのリクエスト量が 10 万件未満の場合、ルーティングと分類器のメンテナンスにかかるエンジニアリングの複雑さが、節約される推論コストを上回る可能性があります。この場合、単一の中規模モデルを使用する方が経済的です。複雑なクエリに対する分類器の誤分類率が 15% を超える (それらをより単純なモデルにルーティングしてしまう) 場合、すべてのリクエストに大規模モデルを使用する方が、質の低い回答によって引き起こされるフォローアップリクエストや手動介入を最小限に抑えることで、全体のコストを実際に削減できるかもしれません。

速度 vs. 安全性

ユーザーは、AI システムが人間の会話のように即座に応答することを期待します。ストリーミング技術により、モデルが生成したトークンを 1 つずつユーザーに送信することができ、「タイプライター」効果を生み出し、最初のトークンまでの時間 (TTFT) を数百ミリ秒に短縮できます。しかし、ストリーミングは、コンテンツが生成されると同時にユーザーに表示されることを意味します。モデルが突然 3 段落目で不適切なコンテンツを生成した場合、最初の 2 段落はすでに送信されており、取り消すことはできません。

従来の解決策は「レビューしてからリリース」です。モデルが完全な応答を生成するのを待ち、それをコンテンツセーフティチェックに通してから、一度に返します。これにより、最初のトークンの応答時間はサブ秒の範囲から数秒、あるいは数十秒にまで増加し、ユーザーエクスペリエンスを著しく低下させます。対話シナリオでは、3 秒を超える待ち時間は、大幅なユーザー離脱につながる可能性があります。

実用的な妥協案としては、セグメント化されたレビュー (各文が生成された後に迅速なチェックを実行する)、非同期レビューと事後撤回を伴うリアルタイムのストリーミング、およびユーザーの信頼レベルに基づく差別化された戦略 (内部ユーザーにはストリーミング出力を、一般ユーザーには事前モデレーション済みの出力を提供する) があります。Alibaba Cloud Content Security は、ストリーミングテキスト検出をサポートしており、これによりレイテンシーを大幅に増加させることなく、リアルタイムのコンテンツフィルタリングが可能になります。しかし、アーキテクトは、特定のシナリオにおいて、検出漏れのリスクとユーザーエクスペリエンスの低下との間で許容できるトレードオフを評価する必要があります。

コンテンツリスクの低い内部ユーザー向けのアプリケーションでは、「ストリーム優先、レビュー後回し」モデルを採用し、フラグが立てられたコンテンツに対してのみ遅延レビューを実行することができます。一般向けのアプリケーションや、金融アドバイスや医療情報などの規制されたドメインでは、たとえ 200～500 ミリ秒のレイテンシーが追加されたとしても、「レビュー優先、リリース後回し」がベースライン要件となります。

自律性 vs. 制御

AI エージェントの価値は、複雑なタスクを自律的に完了する能力にあります。情報を自動的に取得し、ツールを呼び出し、意思決定を行い、アクションを実行します。しかし、自律性が高まるほど、制御を失うリスクも大きくなります。データベース操作を実行する権限を与えられたエージェントが、プロンプトインジェクション攻撃やモデルのハルシネーションによって意図しない DELETE 文を実行した場合、大惨事を引き起こす可能性があります。

在庫レベルに基づいて自動的に補充注文を行う社内調達エージェントを考えてみましょう。完全な自律性を与えられた場合、市場シグナルの誤解により過剰に購入し、多額の資本を拘束する可能性があります。しかし、すべての購入に手動の承認が必要な場合、自動化による効率性の利点は失われます。

実行可能なアーキテクチャ戦略は、「段階的な自律性」です。単一取引の上限を 5万元、1 日の累計上限を 20万元 など、明確な行動の境界線を設定します。これらの境界内では、エージェントは自動的に実行できます。境界を超えた場合、一時停止して手動の承認を要求します。Model Studio プラットフォームでエージェントを構築する際には、ワークフロー内の条件付きノードや人間によるレビューノードを使用して、この階層的な制御を実装できます。重要なのは、エージェントが不確実性に遭遇した際に、黙って誤った可能性のある決定を下すのではなく、エスカレーションすることです。

単一の操作の影響が特定の金額的しきい値 (例：5,000元) を下回り、かつ可逆的である場合、エージェントは自律的に実行する権限を与えられます。しきい値を超えたり、操作が不可逆的 (データ削除や外部への通知送信など) であったりする場合は、人間の確認ステップが必須です。

イノベーション vs. ガバナンス

ビジネスチームは、AI 機能を迅速に実験したいと考えています。今週新しいユースケースを発見し、来週にはチャットボットをローンチしたい、といった具合です。このトレードオフは、特に大規模な組織で顕著で、異なる事業部門が同時に数十の AI アプリケーションをインキュベートする可能性があります。各アプリケーションが独立して完全なコンプライアンスプロセスを経なければならない場合、ガバナンスチームは圧倒され、ビジネスチームは長い待ち時間のために市場機会を失うことになります。

解決策は、プラットフォームベースのガバナンスです。統一された AI サービスプラットフォームを構築し、コンプライアンス機能 (コンテンツモデレーション、ログ監査、ユーザー通知など) をプラットフォームレベルのサービスとして統合します。このプラットフォーム上に構築されたビジネスアプリケーションは、そのコンプライアンスのベースラインを継承し、アプリケーション固有のリスクに対して増分評価を行うだけで済みます。このアプローチは、迅速なビジネスイノベーションを可能にしながら、コンプライアンスの最低ラインを維持します。AI ガバナンスは、AI ガバナンスのベースラインを設定して、セキュリティポリシーに違反するアプリケーションのデプロイを自動的に検出し、開発プロセスを妨げることなくガバナンスのガードレールを提供できます。

一般に公開される AI アプリケーションについては、公開前にアルゴリズムの届出を完了する必要があります。これは推奨事項ではなく、法的な要件です。

カスタマイズ vs. 保守性

モデルのファインチューニングを通じて、企業はベースモデルを特定のドメインで優れた性能を発揮させることができます。医療相談、法律相談、金融分析などの垂直的なシナリオはすべて、ファインチューニングから大きな恩恵を受けることができます。しかし、各ファインチューニング済みモデルは、継続的なメンテナンスを必要とする技術資産です。ベースモデルがアップグレードされたときには再チューニングが必要であり、トレーニングデータが更新されたときには再トレーニングが必要であり、パフォーマンスが低下したときには診断が必要です。

12 の異なる事業部門向けにカスタマイズされたファインチューニング済みモデルを維持している企業は、事実上、12 の独立したモデルトレーニングパイプライン、12 セットの評価ベンチマーク、および 12 の個別の運用責任を維持していることになります。Qwen が Qwen2.5 から Qwen3 にアップグレードされると、12 のモデルすべてで互換性を評価し、場合によっては再チューニングが必要になります。エンジニアリングの負担は線形に増加します。

代替戦略は、プロンプトエンジニアリングと RAG でカスタマイズを実現することを優先することです。慎重に設計されたシステムプロンプトと検索拡張によるコンテキスト注入を使用することで、汎用モデルを特定のドメインでうまく機能させることができます。このアプローチは、特定のモデルバージョンに縛られません。モデルがアップグレードされたときには、プロンプトの効果が安定していることを確認するだけで済み、メンテナンスコストを大幅に削減できます。プロンプトエンジニアリングと RAG が品質要件を満たせない場合にのみ、ファインチューニングの利用を検討する必要があります。

プロンプトエンジニアリングによってドメイン固有のタスクの精度が許容可能なビジネスレベル (例：満足度 >90%) に達した場合、ファインチューニングの複雑さを導入する必要はありません。プロンプトエンジニアリングの限界に達し、ビジネス要件がまだ満たされず、かつ少なくとも数千の高品質なラベル付きデータポイントがある場合にのみ、ファインチューニングへの投資を検討してください。

原則1：制御された自律性

AI システムの価値は、複雑なタスクを自律的に完了する能力にありますが、この自律性は明示的な境界内で実行されなければなりません。「制御された自律性」の原則は、すべての AI コンポーネントが明確に定義された能力の境界と行動規範を持つことを要求します。状況がこれらの境界を超えた場合、システムはサイレントに失敗したり、誤った可能性のある選択をしたりするのではなく、積極的に人間の意思決定者にエスカレーションする必要があります。

この原則を実装するには、3 層のメカニズムが必要です。第 1 層はガードレールで、入力をフィルタリングし、出力をチェックすることで、AI の行動が境界を越えないようにします。これには、コンテンツセーフティフィルタリング、機密情報のマスキング、フォーマット検証が含まれます。Model Studio プラットフォームでは、アプリケーションレベルのガードレールをシステムプロンプトと後処理ルールを通じて設定できます。第 2 層はヒューマンインザループ (HITL) モデルで、いつ人間の介入が必要かを定義し、手動レビューのトリガー条件とエスカレーションチャネルを設計します。第 3 層はエージェントの権限境界で、エージェントがどのツールを呼び出せるか、どのデータにアクセスできるか、どのアクションを実行できるかを明確に定義し、最小権限の原則を用いてその認可範囲を厳格にします。

実際には、制御された自律性とは、エージェントの「レッドラインリスト」を設計することを意味します。このリストは、絶対に禁止されているアクション (例：承認なしでの本番データの削除) と、人間の確認が必要なグレーゾーンのアクション (例：特定のしきい値を超える支払い) を指定します。システムは、すべての自律的な決定のコンテキスト、根拠、結果を記録する明確な監査証跡を提供する必要があります。

原則2：エンドツーエンドの測定可能性

「測定できないものは改善できない」—このエンジニアリングの真実は、AI ドメインではさらに重要です。AI システムの出力品質、コスト効率、リスクレベルはすべて、定量的メトリクスを通じて追跡し、最適化する必要があります。「エンドツーエンドの測定可能性」の原則は、すべての AI の決定が、品質、コスト、レイテンシーの 3 つの次元で観測可能なメトリックデータを生成することを要求します。

可観測性アーキテクチャは、この原則を実装するための基盤です。従来のアプリケーションパフォーマンス監視 (APM) に加えて、AI システムには、各リクエストの入力および出力トークン数を記録し、それをビジネスシナリオとコストセンターに関連付けるトークン消費量の追跡、モデル出力の自動化された多次元評価 (関連性、正確性、完全性、安全性) を実行する品質スコアリング、そして、取得された結果、生のモデル出力、後処理による変更を含む、ユーザーリクエストから最終応答までの完全な呼び出しチェーンを記録する、RAG とエージェントシナリオにおけるエンドツーエンドのトレースが必要です。

トークン会計メカニズムは、AI の推論コストを事業部門や特定のアプリケーションに割り当て、コスト責任を追跡できるようにする必要があります。Alibaba Cloud では、Model Studio の使用状況統計と Log Service のログストレージおよびクエリ機能を組み合わせて、クロスアプリケーション、クロスモデルのトークン消費ダッシュボードを構築し、AI コストのきめ細かい管理を可能にします。

原則3：段階的な認可

新しくデプロイされた AI システムには、すぐに完全な本番権限とユーザーアクセスを付与しないでください。「段階的な認可」の原則は、AI システムの権限と範囲を、その実証された信頼性に基づいて徐々に拡大することを要求します。まず制御された環境で検証し、次に本番トラフィックに段階的に公開します。

段階的なロールアウトは、この原則を実践するための中核的なメカニズムです。シャドウモードは第 1 段階です。AI システムは既存のプロセスと並行して実行されますが、その出力はログに記録されるだけで、実行はされません。人間が AI の決定と実際の決定を比較して、品質データを収集します。グレースケールリリースは第 2 段階です。少量の実際のトラフィック (例：5%) を AI システムにルーティングし、品質メトリクスと異常を注意深く監視します。完全なロールアウトは第 3 段階です。グレースケール検証が成功した後、古いプロセスが完全に置き換えられるまで、トラフィックの割合を徐々に増やしていきます。

段階的な権限拡張は、エージェントシナリオに適しています。新しくローンチされたエージェントには、読み取り権限のみが付与されます。2 週間連続で品質目標を達成した後、書き込み権限を取得します。さらに 1 ヶ月間安定して稼働した後、高リスク操作を実行する権限が付与されます。各権限拡張は、主観的な判断ではなく、定量化可能な信頼性の証拠に基づきます。

原則4：コスト意識

トークン予算は、月末に財務チームが計算するための後付けではありません。それは、設計の初日からアーキテクチャ設計に組み込まれなければならない主要な制約です。「コスト意識」の原則は、システム設計段階でリクエストタイプごとにトークン予算を設定し、実行時に動的なコスト管理を実装することを要求します。

リクエストごとのコスト予算とは、さまざまなタイプのビジネスリクエストに対してトークン消費の上限を設定することを意味します。たとえば、単純な FAQ クエリのトークン予算は 2,000 (入力と出力の合計) かもしれませんが、複雑なレポート生成リクエストの予算は 30,000 かもしれません。リクエストのコンテキストが予算を超えそうになった場合、システムはコンテキストを圧縮したり、関連性の低い検索結果を切り捨てたり、広範すぎるリクエストを拒否してユーザーに範囲を絞るよう促したりするなど、デグレード戦略をトリガーする必要があります。

複雑度に基づくモデルルーティングは、コストを意識したアーキテクチャの中核コンポーネントです。リクエストの複雑度を迅速に評価する (キーワードマッチング、過去のクエリ分類、またはインテント認識を使用) ことで、異なる複雑度のリクエストを異なるコストレベルのモデルにルーティングできます。AI ゲートウェイ上で、Qwen-Plus をデフォルトの処理モデルとして設定し、高複雑度と評価されたリクエストのみを Qwen-Max にエスカレートできます。これにより、品質制約下でのコスト最適性が達成されます。

原則5：組み込みのコンプライアンス

コンプライアンスを、リリース前のチェックリストからアーキテクチャの本質的な属性へと変革します。「組み込みのコンプライアンス」の原則は、規制要件を、システム開発後に追加のレイヤーとして付加するのではなく、設計の初日からアーキテクチャ設計に組み込むことを要求します。

アーキテクチャ設計の開始時からコンテンツフィルタリングを統合することは、開発者がデプロイ前に手動で追加するのに任せるのではなく、システムのデータフローが自然にコンテンツモデレーションノードを含むことを意味します。Model Studio プラットフォームで AI アプリケーションを作成する際、コンテンツセーフティポリシーはオプションではなく、必須の設定項目である必要があります。

組み込みの監査ロギングとは、すべてのモデル呼び出しの入力、出力、モデルバージョン、および設定パラメータが永続的に記録され、ユーザーIDと関連付けられることを意味します。これにより、サービス提供者がログを保持する (たとえば、少なくとも 6 ヶ月間) という規制要件を満たします。これらのログは、オプションで切り替え可能なデバッグ情報ではなく、システムの正常な運用の不可欠なコンポーネントです。

アルゴリズムの届出の統合とは、アーキテクチャがモデルのバージョン管理、トレーニングデータの来歴、およびセキュリティ評価レポートの生成機能を備えて設計されていることを意味します。監査で関連資料が必要になった場合、システムはエンジニアが手動でまとめるのに頼るのではなく、必要な技術文書を自動的に生成できます。