Prove It、第 3 部: 自動推論の実装に関するステップバイステップガイド

このガイドでは、既存のビジネス文書から自動推論ポリシーを作成し、Amazon Bedrock ガードレールを使用してデプロイする方法、ApplyGuardrail を使用して LLM 応答を検証する方法、監査証跡を作成する方法、AgentCore Policy を使用して AI エージェントを保護する方法について説明します。このプロセスを使用すれば、チームはコンプライアンス文書から本番環境の検証までわずか 30 分で完了できます。

第 1 部 (「『おそらく正しい』だけでは不十分である理由) では、スタートアップが決定論的検証を必要とする理由について説明しました。第 2 部 (「形式論理、Cedar ポリシー、そして検証の経済学」) では、検証パイプラインとその背後にある数学について説明しました。さて、ここからは構築の時間です。

始める前に何が必要ですか?

始める前に、次のものが揃っていることを確認してください。

• Amazon Bedrock にアクセスできる AWS アカウント。AWS Activate に参加している場合、そのためのクレジットはすでに取得済みです。
• Python 3.9+ と boto3。MVP を出荷した場合は、これがあります。
• ビジネスルールを説明するポリシードキュメント (PDF、Markdown、またはプレーンテキスト)。コンプライアンスレビューまたは投資家向けデューデリジェンスに合格していれば、この文書が手に入ります。

ステップ 1: AR ポリシーを作成する

最も速い方法は AWS コンソールを使用することです。Bedrock はソース文書を正式な論理ルールに自動的に変換するので、正式なロジックを書く必要はありません。

1. Bedrock コンソールを開き、左側のサイドバーの [自動推論] に移動します。
2. 新しいポリシーを作成します。わかりやすい名前を付けてください (例: 住宅ローン適格性ポリシー)。
3. ソースドキュメントをアップロードします。これは、ビジネスルールを説明する PDF、Word ドキュメント、またはプレーンテキストファイルです。フィンテックのスタートアップ企業にとって、これは融資基準文書かもしれません。ヘルスケアの場合は、臨床プロトコールがそれに当たります。
4. 指示を出します。ポリシーで検証される内容を説明する簡単なインテントを書き、質疑応答の例を 2～3 組含めてください。これらは、ユーザーがポリシーとどのようにやり取りするかをシステムが理解するのに役立ちます。

コンソールを使いたくないチーム向けに、自然言語での形式化を順を追って説明するポリシー作成用の会話型インターフェースもあります。これにはいくつかの前提条件 (Kiro-CLIを含む) がありますが、コンソールはワークフローから完全に削除されます。

意図の例:

このポリシーは、住宅ローンの適格性に関する質問を検証します。ユーザーは、顧客の財務情報に基づいて、特定の種類の住宅ローンの利用資格があるかどうかを尋ねます。

Q&A の例:

Q: あるお客様が、30,000 USD の頭金で 350,000 USD の家を購入したいと考えています。彼らは従来の住宅ローンの対象となりますか?

A: いいえ。従来の住宅ローンでは、最低 20% の頭金 (350,000 USD の購入で70,000 USD) が必要です。

忠実度レポートを確認します。

システムが文書を処理すると、次の 2 つのスコアを含む忠実度レポートが生成されます。

• カバレッジスコア (0.0～1.0): ポリシーにソース文書がどの程度含まれているか
• 精度スコア (0.0 ～ 1.0): 抽出されたルールがドキュメントの意図にどの程度忠実に一致しているか

レポートには、抽出された特定の変数とルールも表示され、ソース文書内の正確な記述に基づいて表示されます。ここで、システムがルールを正しく理解していることを確認します。

アプリケーションの実際の例を使用して、変数の説明の質を高めます。代表的な質問をテストし、システムがそれらをどのように翻訳するかを調べ、翻訳が的外れな場合は説明を改善します。これが正確さを左右する最大の手段です。単位、同義語、変換規則、ドメイン固有の用語は可能な限り含めてください。「購入価格に対する借り手の頭金のパーセンテージ。ユーザーが金額について言及したら、(DownPayment/PurchasePrice) * 100 を使用して換算する」などの説明は、「借り手が支払う金額」という説明よりも優れています」。

これはマルチスプリントのエンジニアリング作業ではありません。既存のコンプライアンス文書が実際に機能する AR ポリシーが作成されるまで 30 分かかります。さまざまな説明を繰り返し、忠実度スコアとテスト結果が期待どおりになるまで、サンプル問題でテストします。

API パス (CI/CD パイプラインに便利) については、「CreateAutomatedReasoningPolicy API リファレンス」を参照してください。API には、名前、オプションの説明、およびルール、変数、カスタムタイプを含む policyDefinition を指定します。

ステップ 2: ガードレールへのデプロイ

ポリシーを適切にテストしたら、本番環境にデプロイします。

変更不可能なバージョンを保存します。コンソールで [新しいバージョンとして保存] を選択します。これにより、番号付きの変更不可能なスナップショット (バージョン 1、2、3...) が作成されるので、ドラフトの編集を続けても本番ガードレールは影響を受けません。これがスタートアップ企業が安全かつ迅速に出荷する方法です。コンプライアンスチームは本番環境でバージョン 1 をレビューし、エンジニアリングチームはドラフトのバージョン 2 を繰り返し処理します。デプロイがフリーズしたり、「出荷するまでポリシーに触れないでください」ということはありません。

ポリシーのバージョンを公開したら、それをガードレールにアタッチして、ランタイムの検証時に使用できるようにします。

主な詳細:

• ポリシーはオブジェクトではなくポリシー ARN 文字列の配列 (最大 2 つ) を取ります
• confidenceThreshold (オプション、0.0～1.0) は、翻訳が信頼できると見なされるための最低合意レベルを制御します。値を低くする (0.3) と、より多くの検出結果がより早く明らかになり、値を高くする (1.0) ほど正確に最適化されます。開発中は低い値から始めて、本番環境では引き締めます。
• AR チェックには crossRegionConfig が必要です。これにより、ガードレールの評価におけるクロスリージョンの推論が可能になります。お住まいの地域に合ったプロファイルを使用してください (例えば、米国の場合は us.guardrail.v 1:0、EU の場合は eu.guardrail.v 1:0)。
• blockedInputMessaging と blockedOutputsMessaging が必要です。これらは、他のガードレールコンポーネント (AR ではなく) がコンテンツをブロックしたときに表示されるフォールバックメッセージです。
• 本番環境では、ARN に番号付きバージョン (: 1) を使用してください。ドラフトは開発用にのみ予約してください。

ステップ 3: ApplyGuardRail を使用して LLM の回答を検証する

推奨される統合パターンは、ApplyGuardrail スタンドアロン API です。これにより、どのコンテンツをいつ検証するかを完全に制御できます。これは、AWS のドキュメントで AR チェックに明示的に推奨されているアプローチです。

既存の推論パイプラインに追加された最小限の統合例を次に示します。

LLM が応答を生成した後、それをユーザーに提供する前に、これを呼び出します。

重要: AR チェックは検出モードで動作します。検出結果とフィードバックが返されます。応答が自動的にブロックされたり、書き直されたりすることはありません。アプリケーションは検出結果を調べ、何をすべきかを決定します。

ステップ 4: 検出結果を処理する

各検出結果は、キーが 1 つだけ存在するユニオンタイプです。これらを解析して動作させる方法は次のとおりです。

標準的な修復パターンは、検証と書き換えのループです。応答を検証し、違反があればモデルにフィードバックし、回答を再生成して再検証します。応答が有効になるか、再試行の制限に達するまで繰り返します。

ユーザーには書き換えループが表示されることはありません。最初の試行で正解が表示されます。イテレーションは舞台裏でミリ秒単位で行われます。

ステップ 5: 監査証跡を構築する

検証のイテレーションはすべてログに記録する必要があります。企業の顧客から SOC 2 の証拠を求められたり、規制当局から特定の決定の検証方法を尋ねられたりした場合は、JSON ログを取得します。すべての検証にはタイムスタンプが付けられ、追跡可能です。

このログがコンプライアンスアーティファクトになります。ユーザーからの質問、LLM が生成した内容、AR が見つけた内容、アプリケーションが実行したアクションなどが表示されます。SOC 2、HIPAA コンプライアンス、またはエンタープライズセールスを追求するスタートアップ企業にとって、この監査証跡はオプションではありません。これは、システムが文書に記されているとおりに機能していることの証拠です。

ステップ 6: AgentCore ポリシーでエージェントを保護する

スタートアップ企業がチャットボットからエージェント型ワークフロー (AI によるアポイントメントの予約、返金処理、データベースへのクエリ、E メールの送信) に移行した場合、エージェントの発言内容だけでなく、行うことにも境界線が必要です。

Amazon Bedrock AgentCore のポリシーでは、Cedar を使用してこのような境界を定義しています。たとえば、医療予約のスケジューリングエージェントには、アクセスできる患者記録を制限し、スケジュールアクションを営業時間に制限し、マネージャーの承認なしにしきい値を超える払い戻しを処理できないようにするポリシーが必要です。LOG_ONLY モードから始めて、何もブロックせずにエージェントの行動を観察しましょう。ポリシーを信頼したら、本番環境では ENFORCE モードに切り替えます。

ゲートウェイは、エージェントとそのツールの間の強制レイヤーです。ツールの呼び出しはすべてゲートウェイを通過し、リクエストがターゲットに届く前に Cedar ポリシーが評価されます。そのため、エージェントはゲートウェイを迂回したり、無視したり、それを超えて話しかけたりすることができないため、エージェントの推論とは無関係に、強制が確定的になり、エージェントの推論とは別のものになります。

AgentCore CLI を使用してゲートウェイとポリシーエンジンを設定します:

Cedar ポリシーを作成し、ポリシーエンジンにアタッチします。次の例は、医療予約エージェントのポリシーの例を示しています。実際には、アクション名はゲートウェイターゲットとツールスキーマ (HealthTarget__get_patient_record など) から自動生成され、リソースは特定のゲートウェイ ARN を参照する必要があります。

Cedar はデフォルトで拒否されます。明示的な許可ポリシーで許可されていない限り、すべてのエージェントとツールのインタラクションはブロックされます。許可ポリシーは、エージェントがどのツールをどのような条件で呼び出せるかを定義します。以下の禁止ポリシーでは例外を設けて、より広範な許可で認められる場合でも特定のシナリオをブロックします。

これを healthcare_policy.cedar という名前で保存し、ポリシーエンジンにアタッチします。

あるいは、ルールを自然言語で記述し、システムに Cedar を生成させることもできます (最初にゲートウェイをデプロイする必要があります)。

自動推論は、ポリシーの作成時にポリシーを検証し、過度に寛容なルール、過度に制限の厳しいルール、または効果のないルールをデプロイ前に検出します。

規制対象のスタートアップ企業にとって重要な主な特性:

• デフォルトで拒否: アクションを明示的に許可するポリシーがない場合、そのアクションはブロックされます
• 禁止が常に勝る: ハードストップルールを他のポリシーで無効にすることはできません
• 決定論的強制: エージェントの推論の範囲外で、ゲートウェイの境界で動作します。プロンプトインジェクション、ハルシネーション、またはバグによって回避できません

LOG_ONLY モードから始めて、製品を壊さずにエージェントが何をしているのかを確認できます。ログには、ゲートウェイへの各リクエストでどのポリシーが適用されたか、ポリシー決定の結果 (許可または拒否) が表示され、ツールのドリフトが発生した場合に一致しないポリシーが明らかになります。そのようなポリシーを確認し、調整してください。自信がついたら、ENFORCE に切り替えましょう。これにより、ユーザーの作業を中断することなく、プロトタイプから本番環境に移行できます。

デプロイスクリプトやテストハーネスを含む詳細な例については、GitHub の Amazon Bedrock AgentCore サンプルを参照してください。

自動推論をデプロイした後はどうなりますか?

AR チェックと AgentCore Policy の実行が完了すると、エラー防止よりも価値のあるもの、つまり信頼できる唯一の情報源が利用可能になります。

AR ポリシーは、正式なロジックとしてエンコードされたビジネスルールです。これらのルールが変更されると (新しい規制、貸付基準の更新、臨床プロトコルの改訂など、常に変化します)、ソースドキュメントを更新してポリシーを再作成すると、スタック内のすべての AI システムがすぐに新しいルールに準拠します。更新するためにプロンプトエンジニアリングは必要なく、モデルの再トレーニングも不要です。誰かがシステムプロンプトを変更したことを覚えていることは望めません。

これにより、すべてのクラスのドリフトバグが排除されます。ドキュメントと AI の動作は数学的に結びつきます。同期できなくなることはありません。

ガードレールはモデルに依存しないため、基盤モデルを切り替えても検証レイヤーは同じままです。Claude の応答を検証したのと同じ AR ポリシーが Amazon Nova の応答を検証しますが、ルールはモデルではなくビジネスロジックによって異なります。

統合は Bedrock エコシステム全体に広がっています。AR ポリシーは、検索拡張生成の場合はナレッジベースと連携し、マルチステップのワークフローでは AgentCore エージェントと連携し、さまざまな基盤モデルと連携します。ポイントソリューションではなく、プラットフォーム上に構築しているのです。

詳細

• 自動推論チェックドキュメント
• AR コンセプト (変数、ルール、検出結果)
• 統合ガイド (ApplyGuardrail パターン)
• AgentCore Policy ドキュメント
• GitHub 上の AgentCore サンプル
• AWS 証明可能セキュリティの概要
• 自動推論とは
• Cedar 言語 (CNCF)

上記が、スタートアップ向け AR シリーズのまとめです。

「Prove It」シリーズ全体で、私たちの主張は一貫しています。AI を基盤とするスタートアップには、確率的な保護手段だけでなく、決定論的で数学的な検証が必要だということです。

第 1 部では、スタートアップにとって信頼の問題が存在する理由と、AWS の数十年にわたる形式的手法への取り組みが Bedrock ガードレールと AgentCore ポリシーにどのようにつながったのかを取り上げました。

第 2 部では、形式論理、検証パイプライン、経済学の内部を見てきました。この記事では、既存のコンプライアンスドキュメントから本番ですぐに使用できる検証済みの AI まで、完全な実装パスをご紹介しました。

AI 時代に勝利を収めるスタートアップは、インテリジェントなシステムを構築するだけでなく、正しいことを証明できるシステムを構築します。自動推論と AgentCore Policy は、ほとんどの企業がすでに持っているポリシーとコンプライアンスドキュメントを使用して、今すぐそれを可能にします。残る疑問は、今すぐ始めるのか、それとも最初のインシデントにより必要に迫られて始めるのか、の点だけです。