Amazon SageMaker Unified Studio ノートブックのスケジュール実行・自動化をネイティブサポート

• URL: https://dev.classmethod.jp/articles/20260607-amazon-smus-schedule-notebook/
• 日付: 2026-06-06
• Tier: Tier 3
• 要旨: Amazon SageMaker Unified Studio（SMUS）にノートブックのスケジュール・自動化機能がネイティブ追加。外部のAirflowなどを用意せずともノートブックUIから直接定期実行・パラメータ化・ワークフローオーケストレーションが設定できるようになった。裏側はAmazon EventBridge Schedulerで、aws schedulerコマンドで横断監査も可能。

詳細

追加された主な機能

• バックグラウンド実行（対話セッションを中断しない専用コンピュートでのオンデマンド実行）
• 定期スケジュール（rate式/cron式、一度きりの将来実行）
• パラメータ化（sagemaker_studio.nbutils.parameters.get()で取得）
• Workflows オーケストレーション（Notebook Operatorで複数ノートブックを連結）
• AI支援トラブルシューティング（SageMaker Data Agentが根本原因特定・修正案提示）

裏側の仕組み

• EventBridge Schedulerの上に構築
• プロジェクト環境作成時にSageMakerUnifiedStudio-<project>-devスケジュールグループが用意
• UIでスケジュール作成 → EventBridgeのユニバーサルターゲットでDataZone API: StartNotebookRunを呼び出す
• Retry policy: 最大保持1日、最大リトライ185回

運用上の注意点

• バックグラウンド/スケジュール実行は対話セッションと隔離された専用コンピュートで動くため、対話セッションのローカルファイルは参照不可 → 永続化はS3が必要
• スケジュール直接作成のAWS CLI/APIは提供されていない（ノートブックUIまたはData Agent経由）
• ガバナンス・棚卸しはaws scheduler list-schedules/get-scheduleで横断確認可能
• フレキシブル時間枠（既定5分）はEventBridgeのFlexibleTimeWindowにそのまま対応

検証環境: ap-northeast-1（東京）、IAMベースドメイン（SSOなし）

AgentCore Runtime のインタラクティブシェルで Kiro CLI を動かしてみた

• URL: https://dev.classmethod.jp/articles/bedrock-agentcore-runtime-kiro-cli/
• 日付: 2026-06-06
• Tier: Tier 3
• 要旨: Amazon Bedrock AgentCore RuntimeのインタラクティブシェルにKiro CLI（AWS公式AIエージェント）をインストールして動かす手順を検証。シェル内での手動インストール（パターンA）とDockerfileへのプリインストール（パターンB）の2パターンを実装した。

詳細

環境構成

• AgentCore Runtimeのmicrovm内でKiro CLIとAWS CLIをセットアップ
• Kiro CLI v2.6.0をARM64バイナリとして10秒程でインストール完了

認証方式（3パターン）

• デバイスコード認証（IAM Identity Center経由のインタラクティブ利用向き）
• KIRO_API_KEY環境変数（ヘッドレス・自動化向き）
• SSM Parameter Store経由でのKIRO_API_KEY取得（チーム運用向き）

use_awsツールの動作確認

• MMDS（microVM Metadata Service）経由でexecution_roleの認証情報を取得
• sts:GetCallerIdentityなどexecution_roleに許可された操作のみ実行可能
• IAMで許可されていないec2:DescribeRegionsは拒否されることを確認

パターンB（Dockerfile）

• KIRO_CLI_SKIP_SETUP=1でインタラクティブセットアップをスキップ
• Kiro CLI + AWS CLI v2をARM64向けにプリインストールしたカスタムDockerfile
• Strands + BedrockAgentCoreApp使用の最小エージェント構成

AgentCore Runtimeの位置づけ

• 信頼できないコードをpolicy制御されたmicroVMで隔離実行するAWS基盤サービス

Google Antigravity CLI を Windows に導入し、日本語で Todo アプリを作らせてみた

• URL: https://dev.classmethod.jp/articles/google-antigravity-cli-windows-japanese-todo-app/
• 日付: 2026-06-06
• Tier: Tier 3
• 要旨: Google Antigravity CLI 1.0.6（旧Gemini CLI）をWindows PowerShellに導入し、Gemini 3.5 Flash (Medium)を使って日本語でREADME作成・PowerShell製TodoアプリのCLI実装を検証。Claude Code常用者から見た体験比較も含む。--sandbox時のコマンド停止バグを確認。

詳細

Antigravity CLI概要

• Googleが提供するエージェント型開発プラットフォーム（旧Gemini CLI）
• サブエージェント、スラッシュコマンド、MCP、Skillsに対応
• Windows: %LOCALAPPDATA%\agy\bin\agy.exeにインストール

検証内容と結果

1. 日本語指示で環境調査 → 日本語で正確に回答
2. README.md作成（見出し・箇条書き3項目の厳密な仕様） → 要件通りに作成
3. PowerShell 7製Todo CLI実装 → add/list/done/エラーハンドリングすべて動作
4. 自己コードレビュー依頼 → データ消失バグ（JSON破損時の空リスト上書き）と複数引数処理の問題を自己発見・修正

Claude Codeとの比較（筆者所感）

• プロンプト入力→ツール実行許可→成果物確認の流れはほぼ同じ
• 簡単なタスクでは体感差は大きくなかった

注意点・バグ

• --sandbox使用時にPowerShellコマンドがRunningのまま停止する事象（Windows 11/PS7.4.14/1.0.6で確認）
• --sandboxなしでは同じ読み取りタスクは完了
• ログ上の権限表示（read_file(/) write_file(/)）と実際の許可操作に差が出る場合あり → 実行前にコマンドとパスを確認推奨
• 自己レビューの限界：ファイルロック競合リスク（並行実行時のデータ損失）は自己発見できなかった

Hermes Agent の self-improving をコードから読み込んでみた

• URL: https://dev.classmethod.jp/articles/hermes-agent-self-improving-code-reading/
• 日付: 2026-06-06
• Tier: Tier 3
• 要旨: Hermes Agent/NemoClaw/OpenShellの実装コードを読み、「self-improving」が何を指すかを解説。モデル重みの再学習ではなく、成功した作業手順を再利用可能な「skill」として保存・蓄積していく仕組みであることが判明。0.16.0では「育てる」より「御す」仕組みが強化された。

詳細

アーキテクチャ三層構造

• Model層: Nemotron/vLLM（推論・生成）
• Harness層: Hermes Agent（tool呼び出し、skill/memory/session search管理）
• Runtime層: OpenShell（ファイル・ネットワークアクセスのpolicy制御）

self-improvingの実体

• skill_manager_tool.pyのコメントに明示：「Allows the agent to create, update, and delete skills, turning successful approaches into reusable procedural knowledge」
• skillは「~/.hermes/skills/{skill-name}/SKILL.md + 関連ファイル」として保存
• メモリ（MEMORY.md）は宣言的な安定知識、skillは手順的・操作的な再利用知識

0.16.0の変更：「増やす」→「選んで畳む」

• 環境フィルタ: frontmatterのenvironments:で環境ごとにskill一覧への表示を制御（明示ロードは通す）
• curator（自動剪定）: 一定期間未使用のskillを自動archive。built-in skillも既定で対象（hermes update後も抑制リストで復活しない）
• hub-installed skillは剪定対象外

skillの信頼階層

• Trusted repos（openai/skills、anthropics/skills、huggingface/skills、NVIDIA/skills）はdangerousのみblock
• Community skillはsafeのみ通す
• インストールフロー：fetch → quarantine → scan → confirm

セキュリティ対策

• 不可視Unicode（zero-width space、bidi override等）をskillに含む場合はhigh severity injectionとして検出

memory vs session search

• memory: MEMORY.md + USER.md、セッション開始時にsystem promptにfrozen snapshotとして注入（ミッドセッション更新はプレフィックスキャッシュ保全のためsystem promptには反映されない）
• session search: 過去会話ログの検索・再開支援

Amazon Quick のアセット管理画面にナレッジベースとスペースが追加

• URL: https://dev.classmethod.jp/articles/quick-manageasset-knowledgebase-space/
• 日付: 2026-06-06
• Tier: Tier 3
• 要旨: Amazon Quickのアップデートで、管理コンソールにユーザーごとのインデックスキャパシティ確認機能と、アセット管理画面へのナレッジベース・スペース参照機能が追加された。新しいAPI群（list-knowledge-bases、list-users-index-capacity等）も追加され、コンソールとAPIの両方で管理が可能になった。

詳細

追加されたAPI

• list-knowledge-bases、describe-knowledge-base、search-knowledge-bases
• delete-knowledge-base、batch-delete-knowledge-base
• describe-knowledge-base-permissions、update-knowledge-base-permissions
• list-users-index-capacity（新規：ユーザーごとのキャパシティ確認）

コンソールの変更点

• 「アカウントを管理 > インデックスキャパシティ」に「Index capacity used」セクションが追加
• ユーザーごとの使用量、ロール、ナレッジベース数、スペース数の内訳が確認可能
• 非アクティブユーザーの表示により、削除済みユーザーに割り当てられたリソースの棚卸しが可能
• アセット管理画面に「KnowledgeBases」「Spaces」タブが追加

実用的な意義

• これまでリージョン全体の使用量しか見えなかったインデックスキャパシティが、ユーザー単位で可視化
• 超過料金の管理・把握がしやすくなった

マイクロVM「smolvm」でLLMが生成したコードをOCIイメージごと安全に動かしてみる

• URL: https://dev.classmethod.jp/articles/smolvm-llm/
• 日付: 2026-06-07
• Tier: Tier 3
• 要旨: Rust製マイクロVM実行エンジン「smolvm」を使い、LLMが生成したコードをOCIイメージごとハードウェアレベルで隔離された環境で安全に実行する方法を実測付きで紹介。Dockerコンテナ（OSレベル分離）とFirecracker VM（125ms以下）の中間に位置し、200ms未満で起動しながらHWレベルの分離を実現する。

詳細

smolvmの主な特徴

• HWレベル隔離（ハイパーバイザ境界）、200ms未満起動、Dockerデーモン不要
• デフォルトでネットワークOFF（--netで明示許可）、OCI互換イメージをそのまま利用可能
• smolvm packでOCIイメージをVM実行バイナリとともにパッケージ化し、Dockerレジストリなしで配布・起動可能

実測値

• machine run --image python:3.12（毎回pullあり）: 約37〜40秒
• pack run（2回目以降）: 約3秒（10倍以上高速化）

用途の棲み分け

• Dockerの代替ではなく「信頼できないコードを安全に動かすサンドボックス」として設計
• macOSでは常駐VMなしにHypervisor.frameworkを直接利用

LLM生成コード実行への応用

• デフォルトのネットワーク遮断設計により、信頼できないコードの外部通信リスクを低減
• smolvm pack化すれば完全オフライン環境でも動作可能

Snowflake から Google Cloud の Lakehouse ランタイム カタログに Apache Iceberg REST カタログ統合で接続

• URL: https://dev.classmethod.jp/articles/snowflake-iceberg-rest-catalog-integration-google-cloud-lakehouse-runtime/
• 日付: 2026-06-06
• Tier: Tier 3
• 要旨: Snowflakeから Google Cloud の Lakehouse ランタイムカタログ（旧 BigLake Metastore）へ Apache Iceberg REST カタログ統合で接続し、Catalog-linked databaseを作成することで、SnowflakeとBigQueryの間でIcebergテーブルを手動のメタデータパス管理なしに共有できるようになった（GA）。

詳細

機能の概要

• 2026年6月のアップデートでGA
• Snowflake → Google Cloud Lakehouse ランタイムカタログ（REST EP: https://biglake.googleapis.com/iceberg/v1/restcatalog）への接続
• 認証にWIF（Workload Identity Federation）を使用、サービスアカウント長期鍵不要

従来との違い

• 従来：metadata.jsonパスを手動指定 → 更新のたびに最新パスを特定してテーブル定義を再設定するストアドプロシージャが必要
• 今回：カタログ経由で自動検知 → メタデータパス管理不要

設定の流れ（要点）

1. Google CloudでWIF Pool・OIDCプロバイダーを作成（SnowflakeのSYSTEM$GET_WORKLOAD_IDENTITY_ISSUER_URL()を使用）
2. PyIcebergでLakehouseカタログにIcebergテーブルを作成
3. SnowflakeでCATALOG INTEGRATIONオブジェクトを作成（CATALOG_SOURCE = ICEBERG_REST）
4. Catalog-linked databaseを作成（namespace → schemaとして自動同期）

重要な設定ポイント

• credential-mode=vended-credentialsでカタログ側がGCSの資格情報を払い出し → Snowflake側で外部ボリューム不要
• PyIceberg接続時にcloud-platformスコープを明示したOAuth2トークンが必要（auth.type=google単独だと401になる）
• roles/serviceusage.serviceUsageConsumerの付与がSYSTEM$VERIFY_CATALOG_INTEGRATION実行に必要

BigQueryとの連携

• Lakehouseランタイムカタログが管理するIcebergテーブルはBigQueryからも参照可能
• Snowflakeが作成・書き込みしたテーブルをBigQueryから参照する相互運用が実現

Snowflake Virtual Columns（仮想列）をGAで試してみた

• URL: https://dev.classmethod.jp/articles/snowflake-try-virtual-columns/
• 日付: 2026-06-06
• Tier: Tier 3
• 要旨: SnowflakeにVirtual Columns（仮想列）がGA。テーブルに値を格納せずクエリ実行時に式から計算する列を定義できる機能で、これまでViewで実現していた派生列をテーブル本体に定義できるようになった。算術演算・文字列関数・CASE式・仮想列チェーンなど複数パターンを実測で確認。

詳細

基本構文

CREATE TABLE t (col TYPE AS (expr));
ALTER TABLE t ADD COLUMN col TYPE AS (expr);

値はテーブルに保存されず、クエリのたびに計算される。

試したパターン

1. 算術演算（quantity * unit_priceで合計金額）
2. 仮想列チェーン（total_price * 0.1で消費税額 → 先行仮想列の参照）
3. 文字列関数（SUBSTR/POSITIONでメールドメイン抽出）
4. CASE式（金額帯分類）
5. DESC TABLEでKIND = VIRTUAL、EXPRESSION列で定義式を確認
6. CTAS（CREATE TABLE AS SELECT）での仮想列引き継ぎ

主な制限（2026-06-06時点）

• 非決定的関数（RANDOM、CURRENT_TIMESTAMP等）、集計・ウィンドウ関数、UDF、サブクエリは使用不可
• NOT NULL・CHECK制約不可、クラスタリングキー設定不可
• ベース列のDROP COLUMN不可（仮想列が参照している場合）
• 仮想列からの前方参照不可（先に定義された仮想列のみ参照可）

既知の問題（Known Issue）

• COALESCEなど NULL→非NULL変換式を持つ仮想列を外部結合で使用すると、結合不一致行で非NULLが返る場合あり
• ワークアラウンド：SELECT句側でCOALESCEを適用する

実用的な意義

• テーブルとViewのペアをテーブル1つで代替可能
• DESC TABLEのKIND列で仮想列と通常列を識別できるため、スキーマ管理が明確