Amazon Bedrock上のGPT-6.1 Sol、Astra級の推論を日常業務へ近づける

Amazon Bedrock上のGPT-6.1 Solは9月29日に一般提供を開始し、エンタープライズにおけるモデル選定に新たな対立軸をもたらした。OpenAIとAWSは、Solをコーディング、コンピューター操作、専門業務向けのAstraに近い知能として位置付ける一方、タスクコストはAstraのおよそ5分の1としている。

この比較が重要なのは、AIエージェントの費用が1回の応答に含まれるトークンだけにとどまらないためだ。能力の低いモデルは、誤ったツール呼び出し、検索の繰り返し、依存関係の見落とし、人による修正の必要を招く可能性がある。どのミスも、遅延と追加のモデル対話を生む。

したがって本当の競争は、単にあるモデルとその前世代との比較ではなく、GPT-6.1 SolとGPT-6 Astraの対決である。Astraは最も難しい業務に向けたOpenAIの選択肢であり続ける。Solは、あらゆる複雑なタスクに最上位モデルが必要だという前提に異議を唱える。

AWSはこの選択肢をBedrock経由で提供し、顧客は使い慣れたアイデンティティ、監査、ネットワーク、データ管理を適用できる。すでにAWS上でアプリケーションを運用しているチームにとって、このリリースは、より高性能なデフォルトモデルを試す際の運用上の摩擦を減らす。

この発表だけで、Solが実際の本番ワークロード全体でAstraに匹敵するかどうかが決まるわけではない。性能に関する証拠の大半はOpenAIの評価に基づいており、実際の結果は各組織のツール、データ、プロンプト、承認ルールによって左右される。

それでもこのローンチは、企業の購買担当者が答えるべき問いを変える。最先端の推論をあらゆる場所で使えるかを問う代わりに、Astraの残る優位性がどこでその利用を限定するだけの価値を持つかを問えるようになる。

Amazon Bedrock上のGPT-6.1 Solがデフォルトモデルを巡る議論を変える

このリリースにより、最先端に近い推論は専門的な選択肢から、繰り返し発生する業務の候補へと変わる。

AWSによると、GPT-6.1 SolはAmazon Bedrockを通じて一般提供されている。このモデルは、単発の回答ではなく複数の判断を要するエージェント型コーディング、コンピューター操作、専門的なワークフローを対象としている。

こうしたタスクには、文脈の収集、ツールの選択、結果の解釈、失敗からの復旧、最終出力の確認が伴うことが多い。コーディングエージェントは、未知のリポジトリを調査し、依存関係を追跡し、複数のファイルを変更し、テストを実行して、実装を修正するかもしれない。

専門業務向けのエージェントも同様の連鎖に直面する。文書を比較し、矛盾する主張を特定し、別のシステムに問い合わせ、成果物を作成し、その組織の要件に照らして出力を改訂することがある。

GPT-6.1 Solが重要なのは、推論の質がこれらの連鎖におけるすべての工程に影響するからだ。モデルの試行回数が増えたり、人が修正すべき成果物が出たりするなら、トークン単価の低さがもたらす価値は限られる。

Bedrockのローンチ発表によると、SolはDeepSWE v1.1でGPT-6 Astraに匹敵し、完了タスク当たりのコストはおよそ5分の1だという。DeepSWEはソフトウェアエンジニアリング業務におけるエージェントを評価するため、短い質疑応答ベンチマークよりも関連性が高い。

AWSはまた、GPT-6.1 Solがこの評価において、公表済みのGPT-6 Solの最強結果を6.4ポイント上回ると報告している。以前のモデルで必要だったものより低い推論努力で、その結果を達成したとされる。

これらの数値は、依然としてベンダー報告の結果である。プライベートリポジトリ、規制対象の文書ワークフロー、カスタムツールを使うアプリケーションでも同じ差が出ることを保証するものではない。

ただし、主張の性質は重要だ。OpenAIはGPT-6.1 Solを、単にトークン当たりで高速または低価格なモデルとして提示しているのではない。より強い推論が、有用な結果に到達するために必要な総作業量を減らすと論じている。

このモデルは105万トークンのコンテキストウィンドウをサポートし、最大128,000トークンを出力できる。コンテキストウィンドウとは、リクエスト中にモデルが考慮できる入力および会話状態の量を指す。

この容量により、アプリケーションは大規模なコードベース、膨大な文書セット、長いワークフロー履歴を提供できる。ただし、含めたすべての詳細をモデルが正しく利用することを保証するものではない。

Solはテキストと画像を入力として受け取り、テキストを出力する。ツール利用はResponses APIを通じて利用でき、これは検索、関数呼び出し、接続されたシステムをまたぐ操作を行うモデル向けのOpenAIのインターフェースである。

AWSは明示的なプロンプトキャッシュも強調している。この仕組みにより、アプリケーションは事前処理済みの文脈を再利用でき、エージェントが同じ指示、リポジトリマップ、参照文書を繰り返し参照する場合の計算を削減できる。

これらの機能を組み合わせることで、GPT-6.1 Solはデモ用モデルではなく運用モデルとして位置付けられる。想定されるワークロードは、1つの見事な回答ではない。勤務日のあいだに完了する、大量の重要なタスクである。

完了タスク当たりのコストが有用な指標になる

GPT-6.1 Solの中心的な主張は、エージェントの経済性が最も安価な個別モデル呼び出しではなく、タスクの成功完了に左右されるということだ。

従来のモデル比較は、入力および出力トークンの料金から始まることが多い。この指標は明確だが、エージェントの振る舞いによって生じるコストを隠す可能性がある。

本番環境のバグを解決するソフトウェアエージェントを考えてみよう。まず影響を受けるサービスを特定し、そのインターフェースを理解し、障害を再現し、実装を変更して、結果を検証する必要がある。

モデルが誤ったファイルを選べば、復旧の過程でより多くのトークンを消費する。依存関係を読み違えれば、別の診断ループを要するテスト失敗を引き起こす可能性がある。成功を早すぎる段階で宣言すれば、開発者が作業を調査して修正しなければならない。

同じパターンは、文書量の多い専門業務にも当てはまる。業務レビューを作成するモデルは、数値を照合し、一貫しない定義を特定し、現行データと過去の文脈を区別し、特定の読者向けに結果を整える必要があるかもしれない。

出力に重要な矛盾が欠けているなら、最初の応答が安価でも有用ではない。実用的な価値の単位は、完成し、受け入れられた成果物である。

OpenAIのモデルガイダンスは、GPT-6.1 Solを複雑なコーディング、コンピューター操作、専門業務のバランスの取れた選択肢として位置付けている。利用可能な最高水準の知能が通常の経済性より重要な場合には、Astraが推奨モデルであり続ける。

これにより、より明確な役割分担が生まれる。チームは頻繁なワークフローにSolを使い、曖昧さ、科学的な深さ、または特別な重要性が追加の推論を正当化するタスクにはAstraを温存できる。

この分担は恒久的である必要はない。アプリケーションはモデルを選択する前にリクエストを評価したり、Solが不確実性、相反する証拠、検証失敗を検出した後にエスカレーションしたりできる。

このアプローチは人員配置モデルに似ている。大半の作業は有能なジェネラリストに回し、最も難しいケースを専門家に移す。違いは、ソフトウェアがリクエスト時点でこの方針を適用できることにある。

Amazon Bedrockはすでに、プロバイダー横断のモデル選択を強調している。そのカタログには、OpenAI、Anthropic、Amazon、Meta、Mistral AI、Cohereなどの開発者によるモデルが含まれる。

この幅広さは、あらゆるモデルベンダーにタスクレベルでの価値の説明を求める圧力となる。AnthropicのClaudeモデルも、コーディング、コンピューター操作、長時間稼働するエンタープライズエージェントで競合する。Amazon独自のNovaファミリーは、AWS顧客に能力と処理量のバランスを取る別の道を提供する。

関連する比較は、もはや単一の普遍的なベンチマーク順位ではない。企業は、コード変更の完了率、契約書のレビュー精度、対話的な作業中のレイテンシ、人による修正時間を比較する可能性がある。

したがってGPT-6.1 Solは、ワークロード固有の評価へ向かうより広範な流れを強める。購入者には、ベンチマーク結果を実行可能なものにする前に、代表的なタスク、期待する出力、失敗の定義、レビュー基準が必要になる。

Bedrockには、品質、コスト、精度を比較するための評価ツールが含まれている。これらのツールは役立つが、タスクの成功が何を意味するかは組織自身が定義しなければならない。

コーディングワークフローでは、成功の条件としてテストの通過、インターフェースの維持、人間のレビュアーの承認が求められるかもしれない。リサーチワークフローでは、完全な引用、正確な計算、矛盾する情報源の明示的な取り扱いが必要になる可能性がある。

チームはテールリスクも測定する必要がある。平均的に優れた性能を示すモデルでも、まれな失敗が受け入れがたい法務、セキュリティ、運用上の影響を生むなら不適切であり得る。

これが、5分の1というコストの主張が評価を始める理由にはなっても、終える理由にはならない理由だ。最も強い証拠は、組織が導入を想定する同じツールと管理のもとで実行された、本番に近いタスクから得られるだろう。

Amazon Bedrockが単なるモデルエンドポイント以上である理由

Bedrockにより、SolとAstraの選択は、企業が既存のAWS環境内で管理できるインフラストラクチャ上の選択となる。

モデルは単体では優れた性能を発揮しても、企業内への導入が難しい場合がある。本番システムには、アクセス方針、監査記録、ネットワーク境界、保持ルール、監視、承認経路が必要だ。

AWSによると、顧客はIdentity and Access Managementポリシーを通じてGPT-6.1 Solへのアクセスを制御できる。IAMにより、管理者はどのユーザー、サービス、ロールがモデルを呼び出し、または関連リソースを管理できるかを定義できる。

モデル呼び出しはAWS CloudTrailを通じて監査できる。この記録は、どのアイデンティティがいつサービスを呼び出したかをセキュリティおよびコンプライアンスチームが把握する助けになる。

アプリケーションは、AWS PrivateLinkを利用した仮想プライベートクラウドエンドポイントも利用できる。これらのエンドポイントは、サービス通信をパブリックインターネットに送るのではなく、設定済みのネットワーク境界内に保つのに役立つ。

AWSによれば、GPT-6.1 Solの推論は、オペレーターによるアクセスがゼロのハードウェア分離インフラストラクチャ上で実行される。AWSは、推論中に自社オペレーターがプロンプトや補完結果へアクセスできないとしている。

AWSはまた、推論データはモデル学習に利用されず、Bedrock顧客はそのデータをOpenAIと共有することにオプトインする必要がないとしている。これは、社内コード、文書、顧客情報を処理する組織にとって重要なコミットメントである。

ただし、評価すべき保持に関する詳細は残る。AWSによると、自動化された不正利用分類器によってフラグ付けされたトラフィックは、最長30日間保持され、プログラムによって処理される場合がある。顧客はAWSアカウントチームを通じてデータ保持ゼロを申請できる。

「データは学習に利用されない」といった包括的な説明は、すべてのガバナンス上の疑問に答えるものではないため、この例外は重要である。購入者は、一時的な保持、不正利用監視、リージョン処理、ログ記録、自社アプリケーションのテレメトリーも考慮しなければならない。

正確な導入経路も重要だ。Bedrockは、AWSネイティブのランタイムアクセスに加え、OpenAIインターフェースを基盤に構築されたアプリケーションの統合変更を減らすことを目的としたOpenAI互換エンドポイントを提供する。

サポートされるAPIは、エンドポイントとモデルによって異なる。すべてのBedrock機能またはOpenAI SDKの操作が同一に動作すると想定する前に、開発者は該当するモデルカードを確認すべきである。

AWSは新規アプリケーションにはネイティブのBedrockランタイムを推奨する一方、互換エンドポイントは使い慣れたOpenAIのリクエストパターンをサポートする。これによりチームは、より深いAWS統合と容易な移行の間で選択できる。

GPT-6.1 Solはプロンプトキャッシュにも対応しており、エージェントが安定した文脈を繰り返し使用する場合に重要となる。企業は、システム指示、リポジトリの規約、製品要件、繰り返し利用する文書コーパスをキャッシュできる。

キャッシュは頻繁な作業の経済性を改善できるが、設計上の課題も生じる。チームは、どのコンテキストが安定しているか、キャッシュされた素材がいつ古くなるか、機密情報を再利用可能なプロンプトに含めるべきかを判断する必要がある。

知識集約型の業務では、検索の品質はモデルの品質と同じくらい重要であり続ける。ポリシーが欠けている、仕様が古い、あるいは文書の選択が誤っている場合、エージェントは正しく推論できない。

検索可能な技術ナレッジベースは、エージェントが資料を横断して推論を始める前に、エンジニアリングチームがローカルの参照情報を整理する助けになる。モデルには依然として検証と、慎重に範囲を限定したアクセスが必要だ。

したがってBedrockの役割は、統合作業をなくすことではない。企業がすでに理解している統制を適用できる環境に、モデルを導入することにある。

この利点が最も大きくなるのは、既存のAWS顧客だろう。別のクラウドにコミットしている組織や、OpenAIを直接利用している組織は、Bedrockのガバナンス上の利点が、もう1つのプラットフォーム層を追加する価値に見合うかを検討しなければならない。

Near-Astraの性能にも限界はある

Near-Astraは位置付けに関する主張であり、GPT-6.1 Solが要求の厳しいあらゆるタスクでAstraと同様に振る舞うという約束ではない。

DeepSWEの結果はエージェント型コーディングにとって有用なシグナルを提供するが、単一の評価で本番業務を表すことはできない。プライベートリポジトリには、文書化されていない慣行、特殊なビルドシステム、独自の依存関係、不完全なテストが含まれている。

また、異なるモデル同士が総合スコアで一致しても、失敗するタスクは異なり得る。チームは最終的な割合だけでなく、失敗のカテゴリーも検証する必要がある。

OpenAI自身のガイダンスでも、GPT-6 Astraには役割が残されている。最も要求の厳しい推論、コーディング、科学、専門業務にはAstraを選ぶべきだと説明している。

この違いは、Solの利点が複雑な業務の幅広い中間領域にあることを示唆する。エラーの影響がより大きい場合や、問題を確実に検証しにくい場合には、より高性能な選択肢が必要でなくなるわけではない。

「near-Astra」という表現は、複数のカテゴリーにもまたがる。優れたコーディング性能が、財務分析、科学研究、法務レビュー、アプリケーション横断のコンピューター操作において同等の判断力を自動的に意味するわけではない。

AWSは、GPT-6.1 Solが複雑な文書分析でAstraに迫り、複数ステップのビジネスツール・ワークフローではGPT-6 Solを上回るとしている。これらの主張はOpenAIの評価に基づくものであり、実際のエンタープライズシステムを横断した独立検証が必要だ。

コンピューター操作には、さらに別の不確実性が加わる。インターフェースは変化し、ボタンは移動し、権限は異なり、ツールが不完全な情報を返すこともある。モデルは、成功した結果を捏造するのではなく、こうした失敗を認識しなければならない。

OpenAIによれば、GPT-6.1 Solは透明性、ユーザー意図、明示的な制限を扱う評価でGPT-6 Solを改善している。評価結果の改善は心強いが、アプリケーションレベルの安全策は依然として必要だ。

ツールの権限は、最小権限の原則に従うべきである。カレンダーを読めるエージェントに、招待を送信する権限まで自動的に必要なわけではない。リポジトリを調査できるエージェントが、常にコードをマージする権限を必要とするわけでもない。

重大な影響を伴う操作には、承認チェックを含めるべきだ。ツールが失敗した場合、要求された情報が利用できない場合、あるいはポリシーによって次のステップが妨げられる場合には、アプリケーション側にも明確な応答が必要となる。

セキュリティプロファイルには、とりわけ注意を払うべきだ。OpenAIの安全性に関する補遺は、GPT-6.1 Solをサイバーセキュリティ能力ではCritical、生物・化学能力ではHighとして扱っている。

OpenAIは、GPT-6 Astraで使われているものと同じ安全策のスタックを適用しているとしている。この補遺では、静的および複数ターンのジェイルブレイク評価で、SolがGPT-6 Solと同等か、それを上回る性能を示したと報告している。

こうした安全策によって、デプロイメントの責任がなくなるわけではない。高性能なコーディングモデルは正当な防御業務を支援できる一方、過剰な権限や侵害された指示の影響を増幅させる可能性もある。

信頼できないコンテンツを読むエージェントにとって、プロンプトインジェクションは依然として実務上の懸念事項だ。悪意のある文書、ウェブページ、Issueの説明、ツール出力には、エージェントを誘導し直すために設計された指示が含まれている場合がある。

モデルはデータと権限を区別しなければならず、同時にアプリケーションは、侵害された推論ステップが実行できることを制限する必要がある。サンドボックス、操作の許可リスト、人間によるレビュー、詳細なログは、モデルのアラインメントだけでは置き換えられない層を提供する。

長いコンテキストには関連するリスクもある。より多くの情報を与えれば結果は改善し得るが、タスクに不要な無関係の指示、矛盾するバージョン、機密データを持ち込む可能性もある。

チームは、Solが行動前に不確実性や証拠不足を特定するかをテストすべきだ。また、助けを求める頻度、正当な業務を拒否する頻度、失敗したツール呼び出し後も継続する頻度も測定すべきである。

こうした振る舞いが、より強い推論が信頼できる自律性につながるかを決定する。より多くのタスクを完了しても不確実性を隠すモデルは、目に見える形で停止するモデルより大きなリスクを生み出す可能性がある。

慎重な解釈は明快だ。GPT-6.1 Solは、低コストのモデルで実行できる業務の範囲を広げるが、組織はAstraや人間のレビュアーが引き続き適切なケースに向けたエスカレーションルールを必要とする。

コーディングと専門業務が最初のテストケースとなる

最も信頼できる導入経路は、一般知能に関する自由形式の主張ではなく、検証可能な成果物を生み出すワークフローから始まる。

ソフトウェアエンジニアリングは、多くの出力をテストできるため、自然な初期ユースケースである。変更はコンパイルできるか、できないかのどちらかだ。自動テストはリグレッションを検出でき、リンターは違反を特定でき、レビュアーは生成された差分を調査できる。

Codexは、Amazon Bedrock上でGPT-6.1 Solを調査、実装、テストに利用できる。このサイクルを通じて、リポジトリ、ローカルファイル、ターミナル、開発ツールを扱える。

AWS固有の開発では、Agent Toolkit for AWSがCodexをサービスドキュメントやAPIに接続できる。利用可能な操作の境界を保ちながら、モデルを最新の技術資料に近づけられることに価値がある。

実用的なワークフローでは、Solに失敗したテストの調査、影響を受けたモジュールの追跡、修正案の提示、ブランチへの実装、検証の実行を求めることができる。その後、開発者が証拠と最終差分をレビューする。

重要な指標は、Solがもっともらしいコードを生成したかどうかではない。チームは、マージの成功数、レビュー時間、ロールバック頻度、テストカバレッジの変化、エージェントに介入が必要だった頻度を追跡すべきだ。

リポジトリレベルの作業は、モデルの長いコンテキストと計画能力も試す。エージェントは、すべてのファイルを無差別に読み込まずに、どのファイルが重要かを判断しなければならない。

専門文書は、もう1つの測定可能な経路を提供する。エージェントはレポートを比較し、矛盾する数値を見つけ、不一致を要約し、ソース資料に紐付いたレビューパッケージを生成できる。

その出力は、元となる文書と照合して確認できる。これによりエラーが可視化され、プロンプト、検索、レビューポリシーに関するフィードバックループが生まれる。

ChatGPT Workは、ファイルやアプリケーションを横断して作業するためのすぐに使える環境を提供する。Bedrock APIを使えば、組織は自社のインターフェースと認可ルールを中心に、より限定的な社内システムを構築できる。

製品チームは、エージェントを使って調査ノート、顧客フィードバック、Issueデータを週次更新にまとめることができる。それでもチームは、ソースの選択を検証し、直接的な証拠とモデルの推論を区別する必要がある。

営業組織は、承認済みのシステムからアカウントブリーフを作成できる。アプリケーションは、どの事実がどのソースに由来するかを記録し、認可なしにモデルが顧客へ連絡することを防ぐべきだ。

オペレーション部門は、手順書とインシデント記録を比較し、変更案を起草できる。人間の責任者が、引用された証拠を確認した後にポリシー改訂を承認する。

これらの例には共通する構造がある。エージェントは範囲が限定された情報を収集し、推論を適用し、検査可能な成果物を生み出し、重大な影響を伴う外部操作の前で停止する。

この構造は、GPT-6.1 Solに公正な試験を与える。モデルが主張する強みを活用しつつ、失敗を抑え、実際のタスク完了に関するデータを生み出す。

自由形式のデスクトップ自動化はより難しい。視覚的なインターフェースは頻繁に変化し、アプリケーションの状態は曖昧になり得るため、成功はモデルが把握できないビジネスコンテキストに依存する場合がある。

したがって、組織は自律性を段階的に拡大すべきだ。読み取り専用のワークフローを下書き作成より先に置き、下書き作成を社内変更より先に置き、社内変更を外部操作より先に置くことができる。

Solの低いタスクコストはより頻繁な利用を支えられるが、量が増えれば小さなエラー率も拡大する。パイロット期間にはまれに見える失敗が、毎日数千回の実行後には一般的になる可能性がある。

これも、モデル呼び出しではなく完了したタスクを比較すべき理由の1つだ。評価には、修正時間、失敗した操作、エスカレーション、出力をレビューする運用コストを含めるべきである。

最も強い結果は、SolがすべてのベンチマークでAstraに勝つことではない。Solが大規模で明確に定義されたワークロードを処理し、難しい例外をAstraや人へ送ることだ。

Solが日常的なモデルになるかを示す3つのシグナル

次の段階は、本番環境での証拠、モデルルーティングの挙動、競合他社がタスク当たりコストの主張にどう応じるかにかかっている。

第1のシグナルは、独立したタスクレベルの評価だ。組織は、代表的なコーディング、コンピューター操作、文書ワークフローから得た証拠を公開または共有する必要がある。

有用な指標には、完了率、人間による修正時間、ツール呼び出し数、レイテンシー、失敗の重大度が含まれる。トークン消費量だけでは、より強い推論が総作業量を減らしたかは分からない。

これらの指標でSolが一貫してAstraに迫るなら、デフォルトモデルにする根拠は強まる。ベンダーのベンチマーク以外で差が広がるなら、「near-Astra」はワークロード固有の説明にとどまるだろう。

第2のシグナルは、企業がSolとAstraの間でどのように業務をルーティングするかだ。チームは、アプリケーションが固定的なモデル割り当てを使うのか、動的なエスカレーションを使うのかを注視すべきである。

成功するルーティングパターンは、頻繁に発生し検証可能なタスクをSolに送り、曖昧なケースや重大性の高いケースをAstraに移すものだ。明確なエスカレーションは、すべてのリクエストに最大の推論コストを支払うことなく品質を維持できる。

Astraのデプロイメントは、GPT-6.1 Solのわずか数週間前にBedrockへ導入された。この近いタイミングにより、顧客は異なる運用上の役割向けに設計された2つのOpenAIモデルを利用できる。

大半のワークロードがAstraにとどまるなら、Solの経済的な主張は弱く見えるだろう。Solが日常的な複雑業務を吸収し、Astraが例外を処理するなら、OpenAIのモデル階層はエンタープライズの購買担当者にとって理解しやすくなる。

第3のシグナルは、Amazon Bedrock内における競合の反応だ。Anthropic、Amazon、その他のモデルプロバイダーは、同じコーディングおよび専門業務ワークフローの多くを巡って競争している。

AWSは多数のBedrockモデルの選択肢を掲載しており、顧客はすべてのインフラ統制を再構築せずにプロバイダーを比較できる。そのため推論レイヤーでの切り替えコストは低くなるが、アプリケーションの挙動は依然としてモデルごとに異なる。

競合各社は、より高い完了率、より高速な操作、より明確な安全挙動、あるいはより魅力的なワークロード経済性によってSolに対抗できる。一般的なリーダーボードでAstraを打ち負かす必要はない。

この競争圧力が購入者に利益をもたらすのは、ポータブルな評価を維持している場合に限られる。1つのモデル固有の癖に縛られた組織は、カタログ上の選択肢を実務上の交渉力に容易に変えることができない。

Amazon Bedrock で GPT-6.1 Sol を検討するチームは、まず受け入れ基準がすでに定義された範囲の限定的なワークロードから始めるべきです。同じタスクを Sol と Astra で実行し、印象的なサンプルではなく、最終的な成果全体を比較してください。

どのモデルが正しく完了したか、必要なステップ数、人が介入した箇所、自動チェックをすり抜けた失敗を追跡します。権限を拡大する前に、セキュリティおよびガバナンスのチームも参加させましょう。

この判断で、恒久的な唯一の勝者を決める必要はありません。Sol を日常業務のエンジンとしつつ、例外的な仕事には Astra を利用できるようにしておくことができます。別の Bedrock モデルが、より高い性能を発揮する専門的なワークロードを担う場合もあるでしょう。

これが今回のローンチの背景にある、より大きな変化です。フロンティア・インテリジェンスはポートフォリオの意思決定になりつつあり、モデルの選択は各タスクの難易度、頻度、そして影響に結び付けられています。

実際のツール、明確な成功基準、人によるレビューのために制御されたプロセスを用いて、あなたの組織が最初に評価できる定常的なワークフローは何でしょうか？