メインコンテンツへスキップ

Fresh AI updates

Astra for LawとMCP認可、業務AIの権限境界

Astra for LawとAnthropicの生命科学向けプログラムは、専門業務でAIを使える条件を設ける。AWSのMCP認可設計と企業事例、Claude Codeの接続修正、Workers AIの混雑時制御を確認し、導入時の利用資格、権限の分離、待機と失敗の扱いを整理する。

10分で読めます
Astra for LawとMCP認可、業務AIの権限境界

OpenAIが法律業務向けのAstra for Lawを発表し、Anthropicは生命科学の専門家向けプログラムの申請対象を広げた。利用資格や提供経路を確認したうえで、AWSの実装解説と企業事例から、ログイン済みの利用者に何を許可するかを読む。Claude CodeとWorkers AIの更新では、MCP接続や推論が待たされたときの扱いを確認する。

業務AIの導入では、モデルを使える条件と、エージェントに許す操作を別々に決める必要がある。本号では、限定提供の範囲、本人確認後のツール認可、企業基盤の権限継承、混雑時の失敗制御を、それぞれの発表条件に沿って整理する。(出典1 / 出典2 / 出典3

Astra for Law、法律業務向けに検索と利用条件を組み合わせる

OpenAIは9月17日、GPT-6 Astraに法律業務向けの検索ツール、指示、文脈を組み合わせるAstra for Lawを発表した。米国の判例や法令などを検索する索引を備えるが、日本法への対応をこの発表から読み取ることはできない。(出典1

当初は対象法律事務所にTrusted Accessを通じてChatGPTとCodexで提供し、API対応は今後の予定としている。全利用者への一般提供や、発表時点でのAPI利用開始とは区別したい。専門的な法律業務における利用は、対象事務所の弁護士とその監督下の利用者を前提とする。(出典1

EastBraverの見立て: 導入検討では、モデル名だけでなく、対象法域、事務所の利用資格、使える提供経路を先に確認したい。米国法の検索基盤と専門業務向けの利用条件を備えることは、あらゆる法域で回答の正確さが保証されることとは異なる。(出典1

  • 出典: OpenAI(公式発表、2026-09-17)

Amazon QuickのMCP認可、本人確認とツール権限を分離

AWSが公開した実装解説では、Amazon Bedrock AgentCore GatewayがAmazon QuickのクライアントとMCPツールの間でHTTPエンドポイントとJWT検証層を提供する。ただし、有効なSSOで確認できるのは呼び出し元の身元であり、その呼び出し元がどのツールを使えるかは別の認可層で制御する。(出典1

多要素認証(MFA)は、Microsoft Entra IDの条件付きアクセス・ポリシーがトークン発行前に検証する。REQUIRE_MFA を有効にすると、要求を検査するREQUESTインターセプターも amr クレームの証拠を確認する。国別制限は REQUIRE_COUNTRY=true の場合に働き、JWTの ctry クレームを許可国と照合する。(出典1

常時有効な中核ゲートでは、まずgroupsクレームの所属グループをreader、author、adminの各ポリシーへ対応付け、呼び出し元の操作範囲を決める。続いて、要求されたMCPツールが、選択されたポリシーの許可リストに含まれるかを検証する。(出典1

業務ロジックへ進む前に、有効にしたゲートを定めた順で評価する。MFAの事前強制はEntra IDが担い、グループとツール権限の検査は常時有効となる。検査に失敗した要求は403で拒否され、ツールやデータへ到達しない。この構成は、Gateway、REQUESTインターセプター、ツールLambda、DynamoDBがAWS側へ導入済みであることを前提とする。(出典1

EastBraverの見立て: 有効なJWTを受け入れることと、ツール利用を許可することは別の判断である。SSO導入済みでも認可完了とはみなさず、groupsクレームによる役割決定とポリシーの許可リストによるツール照合を中核に据える構成だ。(出典1

  • 出典: AWS(公式情報、2026-09-18 00:30 JST)

MRH Trowe、権限継承とセッション分離でAIエージェントを統制

MRH Troweの構成では、安全性を単一機能に委ねず、利用者権限、通信とデータ配置、実行時の分離、利用状況の可視化を組み合わせてセルフサービス型AIエージェントを統制している。(出典1

LibreChatはMicrosoft Entra IDで利用者を認証し、管理画面のアクセス制御リストによって利用可能なエンドポイントとモデルを決める。会議議事録エージェントでは、本人性をチャット欄ではなくサーバー側から渡し、ログイン中の従業員自身の予定表と文字起こしだけにアクセスを限定する。通信は公開インターネットを通さない専用のプライベート接続とし、エージェント、モデル、データの処理はAWS欧州(フランクフルト)リージョン内に置く。ただし、サービスとモデルの提供状況はAWSリージョンごとに異なる。(出典1

単一AWSアカウント内のVPCでは、利用者・セッション・会話、キャッシュとセッション状態、アップロード文書向けRAG、Confluence由来コンテンツの検索を、それぞれ対応するデータストアで扱う。Strands AgentsをAgentCore Runtimeでホストし、Amazon Bedrock AgentCoreのセッション分離によって各セッションをコンピュートとファイルシステムの両レベルで隔離したうえで、認可済みのデータソースとツールを呼び出す。(出典1

AWSの事例記事によると、本番稼働の最初の1カ月で約400人に安全なアクセスを提供した。運用では、ユニーク利用者数、モデル別トークン消費量、ユニークチャット数、利用者当たりコストをダッシュボードで追跡する。初期本番環境のインフラ費とトークン費は1席当たり月額約14米ドルで、適正規模化とスケジュール型スケーリングによりインフラ費を約40%削減できる見通しとされる。(出典1

EastBraverの見立て: 導入判断では、リージョン内処理、専用のプライベート接続、セッション分離を統制要件として評価する必要がある。(出典1

  • 出典: AWS(公式情報、2026-09-18 00:36 JST)

Anthropic、生命科学向けの検証制アクセスをベータ提供

Anthropicは9月17日、Life Sciences Verification Programの申請を生命科学コミュニティへ広げた。初期対象はチームと機関で、研究資格、セキュリティ基準、倫理的な研究監督を審査する。個人のPro・Maxプランへの拡大は今後の予定であり、全利用者が直ちに使える制度ではない。(出典1

認定されたチームは用途に応じた利用許可を申請する。通常の研究開発を対象とするStandard Useはチーム単位で年ごとに更新する。追加審査を要するHigh-risk Useは個別の研究プロジェクトに限定し、6カ月ごとに更新する。この追加許可では、生命科学の要求を遮断する保護措置が解除されるため、両者の適用範囲を区別する必要がある。(出典1

対象モデルはMythos、Opus、Sonnet。開始時点の提供経路はAnthropicの直接提供APIとEnterprise・Teamプランで、個人プランと第三者プラットフォームには未対応となる。BAAを有効にした組織もベータの対象外となる。Claude.aiとClaude Codeでは当初、原則として事前選択した既定の許可が適用される。Claude CodeでAPI認証を使う場合は例外となる。(出典1

EastBraverの見立て: 導入時は、モデルの能力だけでなく、組織の適格性、許可される用途、利用経路を確認したい。とくにHigh-risk Useはチーム全体への包括的な許可ではなく、追加審査を経たプロジェクト単位の許可として管理する必要がある。(出典1

  • 出典: Anthropic(公式発表、2026-09-17)

Claude Code 2.1.274、MCPの待機時間と認証エラーを修正

Claude Code 2.1.274は、非対話実行の最初のターンでMCPサーバーの接続を待つ時間を制限する CLAUDE_CODE_MCP_STARTUP_WAIT_MS を追加した。0 を指定すると接続完了を待たない。Streamable HTTPのMCPツール呼び出しが、サーバー別に長いtimeoutを設定していても約5分で時間切れになる問題も修正した。(出典1

また、MCPの403 insufficient_scopeをサインイン期限切れと表示していた問題を修正し、不足する権限と /mcp での再認証を案内する。リリースノートには、MCP接続エラーやログインツールの説明が設定から解決した秘密値を表示する問題の修正も含まれる。(出典1

EastBraverの見立て: 自動実行では、接続待ちの上限、ツール実行のtimeout、認証と権限不足を別の故障として観測したい。今回の変更は、その切り分けと秘密値を露出しないエラー処理に関わる。(出典1

Workers AI、混雑時に待たず失敗させるrejectIfBusy

Cloudflareは、Workers AIの同期推論で処理能力を確保できない場合、容量待ちキューで待機させずにリクエストを失敗させるrejectIfBusyオプションを案内した。アプリケーションが容量待ちを避ける必要がある場合に使う。(出典1

指定箇所は呼び出し方法で異なる。Workers AIバインディングでは env.AI.run() の第3引数に、rejectIfBusytrue にしたオプションオブジェクトを渡し、第2引数には入れない。ネイティブREST APIではリクエスト本文の optionsrejectIfBusy: true を設定する。(出典1

公式資料によると、容量不足で拒否された要求はHTTP 429 と内部エラーコード 3040 を返す。OpenAI互換のChat Completionsでも本文のトップレベルに options を指定するが、独自フィールドを削除するクライアントではこの指定が効かない。(出典1

EastBraverの見立て: rejectIfBusyは処理能力そのものではなく、容量不足時に待機と失敗のどちらを選ぶかをアプリケーション側で制御する機能と捉えるべきだ。(出典1

  • 出典: Cloudflare(公式ドキュメント、2026-09-17 09:00 JST)

Written by

柿添貴士(TakashiKakizoe) profile photo

柿添貴士(TakashiKakizoe)

Webエンジニア/テックリード

Fukuoka, Japan

  • PHP
  • Laravel
  • Next.js
  • AWS
  • Cloudflare
  • AI Agent