みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 7 月 28 日（火）に「 AWS Bedrock LLM Day Japan 」が東京 赤坂インターシティにて開催されます。AWS Summit New York で発表された最新のサービスアップデートを日本のお客様向けにいち早くお届けするとともに、Amazon Bedrock上でのAnthropic・OpenAIモデルの活用法や、AIエージェント構築基盤AgentCoreの最新機能を実践的に解説します。ぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、7 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「エムシーディースリー株式会社様：AI-DLC Unicorn Gym による3日間の開発変革」を公開 三菱商事グループの一員として産業 DX を推進するエムシーディースリー株式会社様と実施した、AI 駆動開発ライフサイクル（AI-DLC）の体験型プログラム「Unicorn Gym」のレポートです。7 つのチームが Kiro を活用して実際のプロダクト課題や業務課題に挑み、3 日間で商用レベルに近いアプリケーション開発やレガシー環境のコンテナ化を実現した様子と、各チームが得た学び・活用の工夫を紹介しています。 ブログ記事「フロンティアモデルの安全なリリースに向けた AWS の取り組み」を公開 Anthropic の Claude Fable 5 が、悪用を防ぐためのさらに強力なガードレールを備えて Amazon Bedrock で再び利用可能になりました。本ブログでは AWS の CISO である Amy Herzog が、Project Glasswing を通じた Anthropic との連携のもと、サイバーセキュリティ分野で強力な能力を持つフロンティアモデルを防御側に届けつつ、攻撃者への悪用を防ぐための考え方を説明しています。ガードレール作動時には Opus 4.8 に自動フォールバックする仕組みも紹介されています。 ブログ記事「Amazon Bedrock のゼロデータ保持の強制方法」を公開 Claude Fable 5 のようにモデルプロバイダーとのデータ共有を必要とするモデルの登場を受けて、Amazon Bedrock のデータ保持モード（none / default / inherit / provider_data_share）の仕組みを解説しています。Amazon Bedrock Projects によるプロジェクト単位のきめ細かい制御や、サービスコントロールポリシー（SCP）で組織全体にゼロデータ保持を強制する方法を、具体的なポリシー例と検証手順付きで紹介しています。データガバナンス要件のある組織の方は必見です。 ブログ記事「【公共向け】Claude Mythos 時代の脅威対策ワークショップ開催報告 & 耐障害性ライフサイクル実践ワークショップのご案内」を公開 パブリックセクターのお客様向けに月次開催しているセキュリティワークショップの第 3 回・第 4 回の開催レポートです。「Claude Mythos 時代の脅威への対応」をテーマに、Amazon Inspector による脆弱性管理・パッチ運用自動化と、AWS Security Agent による設計レビュー・コードレビュー・自動ペネトレーションテストのハンズオンを実施しました。ワークショップ教材は 一般公開 されていますので、ぜひお試しください。 ブログ記事「AWS パートナーと実現する生成 AI — 現場を変える8つの実践事例 AWS Summit Japan 2026 Partner Breakout Session レポート」を公開 AWS Summit Japan 2026 で 4 部構成にてお届けした Partner Breakout Session のレポートです。東邦ガス情報システム様の Kiro 導入、青森放送様の Amazon Bedrock を活用した文字起こしシステム、品川区様の音声 AI 実証、日本取引所グループ様の GraphRAG による暗黙知の形式知化など、8 組の AWS パートナーとお客様による実践事例のハイライトと、全セッションを通して見えてきた「AI の価値を現場で実現するために本当に必要なこと」を紹介しています。 ブログ記事「AWS Parallel Computing Service と Kiro CLI で HPC のデプロイを加速する」を公開 従来数週間かかっていた HPC クラスターのデプロイを、Kiro CLI のカスタムエージェントで自動化する方法を紹介しています。AWS PCS のベストプラクティスを組み込んだエージェントとの対話だけで、ネットワーク、コントローラー、キュー、コンピュートノードを備えたクラスターを約 30 分で構築する手順を、 デモリポジトリ とともに順を追って解説しています。 ブログ記事「Kiro の超過利用の上限設定と前払い機能のご紹介」を公開 Kiro の超過利用 (overage) の支出をコントロールする 2 つの新機能を紹介しています。IAM Identity Center 等でサインインするチーム向けには AWS Service Quotas コンソールから超過利用の上限を設定できるようになり、個人開発者向けには最小 5 ドルからのクレジットパックを前払いで購入できるようになりました。想定外の請求を防ぎたい方におすすめのアップデートです。 ブログ記事「Kiro で Claude Sonnet 5 が利用可能になりました」を公開 2026 年 7 月 1 日より、Claude Sonnet 5 が Kiro の IDE、CLI、Web で利用可能になりました。Sonnet 5 は推論力・ツール利用・コーディング能力が大幅に強化され、Sonnet クラスの価格のまま Opus 4.8 に近いエージェント性能を発揮します。クレジット倍率は Sonnet 4.6 と同じ 1.3 倍、100 万トークンのコンテキストウィンドウを備えており、タスクに応じて Opus 4.8 とのコスト・性能バランスを選べるようになりました。 サービスアップデート Amazon SageMaker HyperPod が Prefill と Decode の分離 (Disaggregated Prefill and Decode) をサポート Amazon SageMaker HyperPod で LLM 推論の Prefill と Decode を専用の GPU プールに分離する DPD がサポートされました。従来は両フェーズが同じ GPU を奪い合い、長いコンテキストのリクエストが他のトークン生成を停滞させていましたが、今回のアップデートで安定したレイテンシと高いスループットを実現し、両フェーズを独立してスケールできます。長いリクエストだけを自動で分離パスに振り分けるルーターも備えています。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターでディープヘルスチェックをサポート 継続的プロビジョニングで作成した Slurm クラスターでも、GPU の健全性や接続性を検証するディープヘルスチェックが実行可能になりました。非同期に追加される新しいノードを、稼働中のワークロードを中断せずにジョブ投入前に検証できます。自動ノード復旧機能と組み合わせれば、失敗したインスタンスは自動で再起動・交換されます。詳細は こちらのユーザーガイド をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターで AMI ベースのノードライフサイクル設定をサポート 継続的プロビジョニングを使用する Slurm クラスターでも AMI ベースの設定が利用可能になりました。これまで必要だったライフサイクル設定スクリプトの管理が不要になり、Docker や Slurm アカウンティングなどを備えた本番対応のノードを AMI から直接構成できます。ノード追加時点で設定が完了するため、より早くジョブをスケジュールできます。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Studio がワンクリックのモデルデプロイとカスタマイズのために Hugging Face と統合 Hugging Face のモデルページから「Deploy on SageMaker AI」などを選ぶだけで、モデルがロード済みの Studio 環境に直接アクセスできるようになりました。従来はコンソールでの環境構築や IAM 設定、GPU クォータ申請が必要でしたが、今回のアップデートで数秒で環境が作成され、ファインチューニングやデプロイに必要な権限も事前設定されます。 AWS Neuron 2.31.0 が NKI 0.5.0 と UltraServer Operator とともに利用可能に AWS Neuron 2.31.0 がリリースされました。NKI 0.5.0 では MX FP8 スケール dtype や新しいテンソルビュー API が追加され、Amazon EKS 上の Trainium UltraServer ワークロードの管理を自動化する UltraServer Operator がパブリックベータで登場しました。Trn2・Trn3 でデフォルト有効になった新コンパイラバックエンドによる性能向上や、14 の実験的カーネル追加も含まれます。 AWS MCP Server が OAuth をサポート AWS Sign-In を使って AI エージェントを AWS MCP Server に直接接続できるようになりました。業界標準の OAuth を利用するため追加の認証ソフトウェアは不要で、既存の AWS ID や IAM 権限、ガバナンス制御がそのまま適用されます。ブラウザでの対話型認可とヘッドレス認可の両方に対応し、トークン失効 API や CloudTrail 監査などの統制機能も提供されます。詳細は こちらの Blog 記事 をご参照ください。 AWS DMS Schema Conversion が AI エージェントによる自動化をサポート AWS DMS Schema Conversion が AWS MCP Server を通じた AI エージェント自動化に対応しました。Kiro、Claude Code、Cursor などを接続し、IDE から自然言語でスキーマ変換や評価レポート生成などの移行ワークフロー全体を実行できます。専用スキルが API パターンや操作手順をエージェントに提供するため、試行錯誤を削減できます。追加料金なしで利用可能です。詳細は こちらのドキュメント をご参照ください。 Kiro IDE 1.0.116 — エージェント書き込み時のフック、遅延 MCP 認証、マルチウィンドウ同期 Kiro IDE 1.0.116 がリリースされました。エージェントによるファイル変更をトリガーにフックを実行できるようになり、サインインが必要な MCP サーバーへの自動 OAuth 認証や、複数ウィンドウ間での設定同期にも対応しました。trust 機能や接続まわりの修正も含まれています。 Kiro CLI 2.12 — MCP OAuth サポートの拡張 Kiro CLI 2.12 がリリースされました。Figma のように厳格な OAuth 要件を持つ MCP サーバーに対応し、クライアントシークレットの設定、カスタムコールバックパスの指定、独自クライアント ID 使用時の動的クライアント登録のスキップが可能になりました。複合フラグを持つコマンドのより正確な承認プロンプトや、ASCII モードの完全対応も含まれています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

LINE アプリ開発に携わっている Hiraki と申します。普段は、LINE アプリにおけるアーキテクチャの統一を推進するプロジェクトのリードや、AI ネイティブな開発スタイルを業務に組み込むための...

こんにちは。開発1部の村上です。 本記事は AIブログリレー 5本目 です。 弊社ではすでに 全社共通ゲートウェイによる社内リモートMCPサーバー を構築したり、それをもとにMCPを社内で内製して多くの社員が使っていたりと、社外の公式MCPの利用も盛んになっています。本記事では、今後組織のMCP活用が拡大するとぶつかる課題を整理し、それを支える基盤としてのMCPゲートウェイというコンセプトについて書きます。 MCP is deadは本当か 基盤の話に入る前に、そもそもMCP自体必要でしょうか。今年2月末、 「MCP is dead. Long live the CLI」 という記事が反響を呼びました。LLMはCLIとドキュメントさえあれば勝手にやれる、認証は aws sso login や gh auth login という実績あるフローで済む、MCPサーバーは初期化が不安定で再認証が終わらない、権限の制御も粗いという主張です。日々Claude Codeを使っている人ほど、思い当たる内容だと思います。 一方で、GitHubのMCPサーバーを開発するエンジニアは、 MCP Dev Summit NA 2026の講演「MCP vs CLIs」 で、この論争が過熱していたまさにその時期にMCPの利用は急増しており、GitHub MCPサーバーは過去最大の週間利用量を記録したと語っています。「死んだ」と言われるものが、史上最も使われている状態なわけです。 CLIで十分か 改めてMCPとCLIの違いを整理してみます。 CLI MCP 設計の向き先 人間向けに設計済みのコマンド AI向けに設計されたツール・リソース モデルとの相性 学習データに豊富。パイプで合成できる スキーマで型が明確。素朴な全部載せはコンテキストを圧迫 認証・権限 トークン権限を全て委譲。 gh auth token などで露出し、環境変数から漏れやすい OAuth 2.1。ツール単位で操作面を絞れ、トークン権限をモデルから隔離できる 利用者・環境 シェルがある環境。主に開発者個人 リモート・非エンジニアにも届く 象徴的なのは認証です。CLIではトークンにできることはエージェントにもすべてできてしまう。しかも gh auth token 一発でトークン自体が露出します。一方でMCPのOAuthフローはトークンをモデルから隔離し、ツール単位で操作面を絞れます。 結局のところ、この論争は道具の優劣ではなく環境に依存してしまいます。CLIが成立するには、認証・権限・監査という関心事をOSの権限モデルと個人の責任が引き受けられる環境が必要です。数百人が複数のクライアントを使い、非エンジニアも含まれ、監査要件がある組織では、この前提が崩れます。個人は「使ってみる」で完結しますが、組織は、そこから「運用する」ことが求められます。そうなると組織がAIを活用していく上でMCPのメリットは十分にあり、引き続き有用な選択肢となっており、組織でどうMCPを管理していくかは重要なテーマだと思っています。 あらゆるシステムがMCPとしてエージェントと繋がる 増えるMCPサーバーとAIエージェント エブリーでは現在、外部MCPと社内MCPを合わせて数十程度のMCPが設定され、使われています。とはいえ、まだまだ発展途上だと思っており、エージェントに仕事を任せる範囲が広がるほど、CRM、チケット管理、社内Wiki、データ基盤と、社内外のあらゆるシステムがMCPを通してエージェントと接続されていきます。Uberでは、社内の1万を超えるサービスのエンドポイントをMCPツールとして公開できる状態まで到達しています（ AAIF公式ブログ ）。 そして増えるのはMCPサーバーの数だけではありません。呼び出し元も人間がClaudeを使うときにMCPを呼ぶだけでなく、社内で作られたエージェントが自らの判断でMCPを呼ぶようになります。定常業務を回す常駐エージェント、夜間にスケジュール起動するエージェント、コードを書き続けるバックグラウンドエージェントなど数百、数千の社内エージェントが、当たり前に稼働している未来が想像できます。 今はまだこのエージェントやMCPサーバー自体を増やしていき業務をエージェントに委譲することに注力していますが、同時にそれを推進することで新たに二つの課題に直面していくと考えています。 課題①: 統制が効かなくなる 一つ目は統制面です。誰がどのMCPサーバーに繋いでいるか分からない。各自のmcp.jsonに認証情報が散らばり、退職者のトークンがどこで生きているか追えない。エージェントに渡した権限が適正かを検証する仕組みがなく、何かが起きたときに「誰の委任で、どのエージェントが、何をしたか」を再構成できない。 エージェントに強い権限を渡せば、誤動作ひとつで本番データの削除や誤送信が起き、セキュリティ面ではエージェントそのものを禁止したくなります。かといって安全側に倒して権限を必要最小限まで削れば、今度は誰の役にも立たないエージェントになり、投資が回収できません。人間が誤操作で壊せる範囲には手間という上限がありますが、ループで動くエージェントにはそれがなく、簡単に大きな被害が出るインシデントを起こしかねません。だからこそ、それぞれのエージェントに何をさせられるかを管理できることが、組織のAI活用では大切になってきます。 課題②: 活用が進まなくなる 二つ目は活用面です。ここで言う活用とは、エージェントが正しくツールを選べること(精度)、社員が使い始められること(導入の手間)、そして改善が回ること(計測)の3つを指します。 まず精度という観点ではツール定義はそれ自体がコンテキストを消費します。数百のツール定義の読み込みだけで何万ものトークンを消費することもあります。ユーザーが何かを言う前に、この量が流れ込むのです。MCPが増えれば、モデルは進化しているとはいえ本題より先にツールの説明を読むことになり、選択を誤り、遅く、高く、不正確になります。 また、導入の手間という観点ではMCPが増えるほど、サーバーごと・ユーザーごとにOAuth認証を通したり、設定ファイルを書く作業は、非エンジニアも含めた全員の活用を考えると障壁になりえます。最後に計測という観点ではどのツールがどう誤選択され、どこで失敗しているかが見えなければ、ツール定義を改善するループが回りません。 MCP運用におけるゲートウェイというコンセプト 重要なのは、これらの課題がMCPというプロトコルの欠陥ではないことです。MCPが標準化したのは「どう話すか」だけであり、誰が・誰の権限で・何を・どこまで使い・誰がそれを見ているかという運用の関心事は、意図的に規定していません。だから薄く、速く普及しましたが、組織活用ではこの問題を解かないといけません。 その実装として業界が向かっているのが、MCPゲートウェイです。承認済みサーバーのカタログ(レジストリ)と、全トラフィックが通る中継点(ゲートウェイ)という構成です。レジストリが「何を使ってよいか」を定義し、ゲートウェイが「実際にそう使われているか」を実行時に強制する、という役割分担で、多くの製品はこの二つをセットで提供しています。2026年4月の MCP Dev Summit では多くの企業がMCPゲートウェイの上で社内のAI活用を推進しており、もはやそれを前提とした上でゲートウェイに関する機能の発表も多い印象です。Uberは 自社のエンジニアリングブログ でも、すべてのエージェントとサービスの間にMCP Gatewayを置き、呼び出し元の認証とツール実行の認可を通過したリクエストだけを下流に中継する構成を解説しています。 MCPゲートウェイが目指しているところ 何ができるのか ではゲートウェイは何ができるのか。業界で合意されているのは構成の型までで、機能の切り分けは各社各様です。今回は各社の実装を横断して、6つに整理します。 # 機能 統制面 活用面 1 単一経路化(集約) 野良MCPの遮断、統制点の一元化 1エンドポイントの追加で適切な権限範囲の全ツールに接続完了 2 認証・認可・シークレット管理 トークンの集中保管と即時失効 各自のOAuth設定が不要になる 3 ツール単位のポリシーとガードレール 削除系の禁止、引数の固定、レートリミット、PII検査 用途ごとに安全な形でツールを開放でき、自律的なエージェントやAI活用を促進 4 レジストリ(カタログ) 承認済みサーバーだけが流通する 「何が使えるか」を全員が発見できる 5 ツールの絞り込み・変換 モデルに見せる操作面そのものを縮小 必要なツールだけを動的にロードしコンテキストを削減 6 可観測性・監査 誰の委任で何が実行されたかの証跡 誤選択・失敗の計測とツール定義の改善 MCPゲートウェイはセキュリティ対策のみで切り取られがちですが、どの機能もAI活用自体を支える重要な役割を果たしていることがわかります。例えば認証仲介は、セキュリティ文脈ではトークン管理の話ですが、利用者から見れば効率的なオンボーディングの話です。ツール絞り込みは、統制文脈では操作面の縮小ですが、精度文脈ではコンテキスト削減そのものです。こうした安全な仕組みを作ってLLMに判断させない箇所を増やすことが、統制であると同時に信頼性の向上にもつながっていきます。 ユーザーの権限は「上限」であって「適正」ではない 各MCPサーバーがOAuthでユーザーを認証し、本人の権限の範囲で動く委任実行は正しい土台で、仕様もその方向に進んでいます。エージェント経由で本人以上の権限が使える、という権限昇格型の事故はこれで原理的に防げます。 しかし、ユーザーの権限は「上限」であって「適正」ではありません。自分の全メールを削除できますが、エージェントにそうさせたいわけではありません。エージェントは非決定的で、ハルシネーション1回の誤操作も「本人の正当な操作」として実行されます。必要なのは「このエージェントに許された操作」と「このユーザーの権限」の積集合を実行時に毎回評価することであり、自己規律に頼れない以上、この評価はエージェントの外側で行うしかありません。ゲートウェイとは、この評価を全リクエストに対して行う場所です。 現時点での技術的な選択肢 最後に、全てではないですが、このコンセプトを実装する際の現時点(2026年中期)でのゲートウェイを一部紹介します。 名前 特徴 agentgateway Linux Foundation傘下のOSS(Apache 2.0)。MCP/A2A対応のデータプレーンで、集約・ポリシー・可観測性が骨格の中立インフラ ToolHive Stacklok開発のOSS(Apache 2.0)。コンテナ隔離ランタイム・仮想MCPゲートウェイ・公式Registry API互換のレジストリサーバーまで揃うプラットフォーム型 Obot ゲートウェイ+カタログ+RBACを管理UI込みで提供する製品型OSS(MIT/オープンコア) AWS AgentCore Gateway AWSのマネージドサービス。セマンティック検索によるツール絞り込みが特徴で、既存API/LambdaのMCP化も担う Databricks Unity AI Gateway Databricksのマネージドサービス。Unity Catalogの権限モデルとエージェントトレーシングの延長でMCPを統治できる 選定の観点は既存スタックとの整合、運用体制で変わってくると思いますが、まだまだこの領域自体も発展途上なのでプレイヤーが大きく変わることも予想されます。 おわりに 今回はエージェントやMCPが組織で増えていった際にどういったことを考えないといけないのかを先行している企業の事例や技術的なトレンドから整理してみました。 エブリーでも今後エージェントを量産していきますが、その歩みを止めないためには、MCPゲートウェイのような基盤側の整備を同時並行で進めることが重要になります。エンジニア組織として、こうした基盤の構築を進めながら全社のAI活用を支えていきたいと思っています。 AIブログリレーは、このあとも開発部長陣が続けていきます。次回もぜひご覧ください。 エブリーでは一緒に働く仲間を募集中です！ エンジニアブログをきっかけに少しでも興味も持っていただけたら、まずはカジュアルに面談しましょう！