みなさん、こんにちは。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 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

テスト観点が書けない・・・・、その壁、壊せます。 前回の記事で「テスト観点で語れ」「足りない観点を指摘しなさい」と書きました。でも、こう思った人もいるんじゃないでしょうか。 「で、テスト観点ってどうやって書くの？」 テスト観点という言葉は知っている。大事なのもわかる。でも、いざ書こうとすると手が止まる。何を書けばいいのか、どこまで書けばいいのか、これで合ってるのか。その不安が、最初の一歩を阻んでいます。 この記事では、テスト観点が書けない原因を3つの壁に分解して、それぞれの乗り越え方からチームでの運用方法まで、具体例付きで紹介します。 この記事の手順を踏むと、最終的にこういうアウトプット

はじめに # Deno 2.9 リリースおめでとうございます。 Deno 2.9 | Deno Electron 大好きな自分としても気になるのはやはり Deno Desktop です。 Tauri と同様 WebView をバックエンドにする構成と Electron と同様 Chromium ベースの構成を選べるとのことで、これは試すしかないと思いました。 公式ドキュメントは以下にあります。 https://docs.deno.com/runtime/desktop/ --> Caution Deno ブログには以下のように書かれており、2.9 時点ではデスクトップ機能は実験的段階です。 deno desktop is experimental in 2.9. The surface described here is stabilizing and some platform features are still landing. 使ってみる # まずは 2.9 にアップグレードしておきます [1] 。 deno upgrade main.ts に Deno.serve を使って普通にサーバープログラムを書きます。 main.ts Deno.serve(() => new Response( "<!DOCTYPE html><h1>Hello from Deno desktop </h1>", { headers: { "content-type": "text/html" } }, ) ); 同じディレクトリで deno desktop main.ts を実行します。 $ deno desktop main.ts ⚠ deno desktop is experimental and subject to change Check main.ts Compile main.ts to hello.dylib Embedded Files hello.dylib └── main.ts (430B) Files: 1.91KB Metadata: 1.38KB Remote modules: 12B Downloading laufey webview backend for aarch64-apple-darwin (v0.4.0) Download laufey-webview-aarch64-apple-darwin.tar.gz 97.44KiB/97.44KiB Codesigning bundle with identity "-" hello.app/Contents/MacOS/laufey_webview: replacing existing signature hello.app/Contents/MacOS/hello.dylib: replacing existing signature Bundle hello.app 最後の出力で、ルートに hello.app (macOS のアプリ実行ファイル)が生成されており、起動できます（Windows の場合は、hello.exe が生成されます）。 Deno のコンセプト通り、追加のモジュールや設定なし(Out of the box)でデスクトップアプリが生成されました。 Deno Desktop の開発体験 # HMR (Hot Module Replacement) オプション付きで起動することで、ローカルの開発サーバを立ち上げ、コード変更を検知してアプリ内容を即時更新してくれます。 deno desktop --hmr main.ts ⚠ deno desktop is experimental and subject to change Compile main.ts to file:///Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib Embedded Files hello.dylib └── main.ts (422B) Files: 1.9KB Metadata: 1.38KB Remote modules: 12B Running desktop app with HMR (watching /Users/kondoumh/dev/deno-study/desktop/hello) Runtime loaded successfully from: /Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib Runtime started [desktop] dylib path: "/Users/kondoumh/Library/Caches/deno/desktop/5f4a00908e99d886/hello.dylib" Listening on http://127.0.0.1:52958/ main.ts のコードを書き換えると、保存後すぐに画面へ反映されます。 --> Information Electron では HMR は標準では利用できず、別途 Forge などで開発サーバーを起動する必要があります。 https://developer.mamezou-tech.com/blogs/2024/01/29/electron-forge-introduction/ UI の ローカル HTTP サービスによる実現 # Electron (Forge など) ではローカルサーバーの利用は開発時が中心で、配布後は file:// でアセットを読む構成が一般的です。 これに対し Deno Desktop は、配布後のバイナリでもローカル HTTP サーバーを内部起動し、空きポートを自動割り当てして UI を描画します。サーバーはプロセス内で閉じており、外部公開はされません。ポート衝突を意識せずに済むのも良い点です。 この「開発時もビルド済みバイナリでも、同じ HTTP 実行モデルで UI を提供する」設計により、 開発時とデプロイ時の挙動に差がない コンテンツはブラウザとデスクトップで同じ動きをする Next.js などのフレームワークがそのままデスクトップアプリの中で動く といったメリットが得られます。 https://docs.deno.com/runtime/desktop/serving/ DevTools の起動 # Electron や Tauri と同様、DevTools によるデバッグが可能です。BrowserWindow を起動し、 openDevtools メソッドを呼ぶだけです。 const win = new Deno.BrowserWindow({ title: "My Deno Desktop App", width: 800, height: 600, }); win.openDevtools(); https://docs.deno.com/runtime/desktop/devtools/ --> Information いまのところ、DevTools のフルサポートはバックエンドを cef にしている時のみです。 以下のように、指定して起動する必要があります。 deno desktop --hmr --backend=cef main.ts バックエンドとフロントエンドの通信(Bindings) # Electron の IPC 通信は render.js と main.js を preload.js 経由でブリッジする必要があり、かなり面倒です。Deno デスクトップでは BrowserWindow にバインドした関数を bindings というグローバルオブジェクトにより簡単に呼び出すことができます。 Deno ランタイムとレンダリングバックエンドはスレッドやプロセスとして動作し、呼び出しはプロセス内チャネルを介して行われます。このサンプル構成ではソケットベースの IPC を直接扱わずに済むため、Electron の ipcMain / ipcRenderer、Tauri の invoke と比べて見通しよく書けるのが利点です。 実際のコードで見てみましょう。 const win = new Deno.BrowserWindow({ title: "Bindingsのテスト", width: 800, height: 600, }); // ========================================== // 1. バックエンド側：フロントから呼ばれる関数を登録 // ========================================== win.bind("getSystemInfo", async (userName) => { console.log(`[Deno側] フロントエンドから呼ばれました！ 引数: ${userName}`); // Denoの機能を使ってOSの情報を取得 const denoVersion = Deno.version.deno; const os = Deno.build.os; // 少し重い処理をシミュレート（0.5秒待つ） await new Promise(resolve => setTimeout(resolve, 500)); // フロントエンドに返すデータ（JSON化できるものなら何でもOK） return { message: `こんにちは、${userName}さん！`, os: os, denoVersion: denoVersion }; }); // ========================================== // 2. フロントエンド側：画面のHTMLを返す // ========================================== Deno.serve(() => { const html = ` <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Bindings Test</title> </head> <body> <h1>Deno Desktop Bindings</h1> <button id="btn">システム情報を取得</button> <pre id="result">ここに結果が出ます</pre> <script> // ボタンが押された時の処理 document.querySelector('#btn').addEventListener('click', async () => { const resultArea = document.getElementById('result'); resultArea.textContent = "取得中..."; try { // 💡 bindings を使ってバックエンドの関数を呼び出す const data = await bindings.getSystemInfo("kondoumh"); // 結果を画面に表示 resultArea.textContent = JSON.stringify(data, null, 2); } catch (error) { resultArea.textContent = "error: " + error.message; } }); </script> </body> </html> `; return new Response(html, { headers: { "content-type": "text/html" }, }); }); アプリ画面です。 システム情報を取得 ボタンをクリックするとしばらく呼び出し中になり、結果が表示されます。 結果が表示された状態。 アプリを起動しているバックエンドでは次のようにログが出ています。 [Deno側] フロントエンドから呼ばれました！ 引数: kondoumh すごくシンプルです。OS のネイティブ機能と Web UI を簡単に連携できるのがいいですね。 https://docs.deno.com/runtime/desktop/bindings/ メニュー の利用 # アプリケーションメニューの実装。 BrowserWindow の setApplicationMenu メソッド内でメニューオブジェクトを定義して渡します。 BrowserWindow にイベントリスナーを登録してメニューがクリックされた時の振る舞いを実装します。 role などは Electron と同じですね。 win.setApplicationMenu([ { submenu: { label: "File", items: [ { item: { label: "New", id: "new", accelerator: "CmdOrCtrl+N", enabled: true, }, }, { item: { label: "Open…", id: "open", accelerator: "CmdOrCtrl+O", enabled: true, }, }, "separator", { item: { label: "Save", id: "save", accelerator: "CmdOrCtrl+S", enabled: true, }, }, { role: { role: "quit" } }, ], }, }, { submenu: { label: "Edit", items: [ { role: { role: "undo" } }, { role: { role: "redo" } }, "separator", { role: { role: "cut" } }, { role: { role: "copy" } }, { role: { role: "paste" } }, ], }, }, ]); win.addEventListener("menuclick", (e) => { const detail = (e as CustomEvent).detail; switch (detail.id) { case "new": console.log("New clicked"); break; case "open": console.log("Open clicked"); break; case "save": console.log("Save clicked"); break; } }); コンテキストメニューの実装。 Deno.MenuItem の配列を作成して、BrowserWindow の showContextMenu に座標とともに渡します。 const contextMenu: Deno.MenuItem[] = [ { item: { label: "Copy", id: "copy", enabled: true } }, { item: { label: "Paste", id: "paste", enabled: true } }, "separator", { item: { label: "Properties…", id: "props", enabled: true } }, ]; // Trigger from a right-click. The webview may not forward the browser // `contextmenu` event, so handle the secondary mouse button on the window. win.addEventListener("mousedown", (e) => { if (e.button === 2) { win.showContextMenu(e.clientX, e.clientY, contextMenu); } }); win.addEventListener("contextmenuclick", (e) => { if (e.detail.id === "copy") { console.log("Copy clicked"); } if (e.detail.id === "paste") { console.log("Paste clicked"); } if (e.detail.id === "props") { console.log("Properties clicked"); } }); --> Information ここではメニューのクリックイベントでログを出力していますが、ログ自体はアプリを起動しているターミナル側に出ますのでご注意ください。 https://docs.deno.com/runtime/desktop/menus/ フレームワークを利用した開発 # Deno.serve() を利用したサンプルを見てきましたが、Deno デスクトップでは、以下のフレームワークとともに利用可能です。これらのプロジェクトのディレクトリで deno desktop を起動すると、フレームワークを自動検出してアプリを構成します。多くのモダンフレームワークがサポートされています。 Next.js Astro Fresh Remix Nuxt SvelteKit SolidStart TanStack Start Vite ローカルで動いてるのに SSR を使うというのがなんとも不思議な感じですが、ちゃんと動いてセキュアであればヨシ！という感じでしょうか。 https://docs.deno.com/examples/next_tutorial/ Next.js のアプリを作成します。 deno run -A npm:create-next-app@latest 作成したプロジェクトディレクトリへ移動して実行します。 cd <project-dir> deno desktop -A Next.js のアプリが、外部サーバーなしでまるっとデスクトップ内で動いてるのは不思議な感じです。 https://docs.deno.com/runtime/desktop/frameworks/ バックエンドの選択について # デスクトップアプリは配布するバイナリのサイズも重要です。小さいに越したことはありません。 Electron は Chromium を内包するため、インストールされたバイナリサイズは300MBぐらいの大きさになったりします。 Deno Desktop の場合、OS にプリインストールされている WebView を使えば70MB程度です。CEF(Chromium) だとやはり300MB程度になります。 OS 依存の WebView だと、Windows と Mac で微妙に CSS や JS の挙動が変わるクロスブラウザ問題が発生するため、そのための対応やテストも必要になります。機能が少ないうちは WebView でもいいかもしれませんが、機能が増えてくるとテストの手間も何倍にもなっていきます。 Deno Desktop の場合、最初は軽量な WebView でスタートし、クロスブラウザが重荷になってきたら、ちょっと配布サイズは大きくなるけど、CEF にスイッチできるのがいいかなと思います。 https://docs.deno.com/runtime/desktop/backends/ --> Information Tauri だとこの辺、Servo ベースの自前 WebView プロジェクト Verso 待ちですが、Deno は既存の Chromium を選択可能にしているあたり、現時点での割り切りが感じられますね。 Electron との比較 # 既存 Web アプリをデスクトップ化したいユースケースでは、Deno Desktop はかなり有力です。 一方で、Electron の WebContentsView のような高度なマルチビュー構成を前提にしている場合は、現時点では Electron のほうが適しています。たとえば VS Code や Figma のように、複数ビューを細かく制御するタイプのアプリです。 ざっくり整理すると次のような感触です。 単一ウィンドウ中心 + 既存 Web 資産活用: Deno Desktop はかなり良い 複雑なウィンドウ/ビュー管理: Electron が依然強い --> Information マルチビュー構成の対応の弱さは Tauri も同様です。 https://developer.mamezou-tech.com/blogs/2025/12/01/porting-an-electron-app-to-tauri2/ Electron の WebContensView 構成については以下の記事をご参照ください。 /blogs/2024/08/28/electron-webcontentsview-app-structure/ https://docs.deno.com/runtime/desktop/comparison/ さいごに # 以上、Deno Desktop 機能を一通り試しました。 Out of the box でここまでデスクトップ開発体験が整っているのは率直に驚きです。タスクトレイやメニュー、Bindings など、アプリらしさを出すための API が最初から揃っているのも好印象でした。 Tauri と違ってアプリ側をすべて TypeScript で書けるため、既存 Web アプリをベースに「メニューやタスクトレイを追加し、OS 機能と連携する」用途ではかなり相性がよいと感じます。最小構成なら、デスクトップアプリ化自体は1時間もかからないはずです。 --> Information Tauri も JS の API を生やして、Rust 知らない勢を取り込もうとしてはいます。 Deno のキラー機能になる可能性もありますね。experimental から安定版へ向けて、今後の熟成がとても楽しみな機能です。 2026年7月6日現在の最新は 2.9.1 です。 ↩︎