コンテンツにスキップ
Reports

日次レポート 2026-06-06

トピック別記事一覧

ai-llm(10件)

タイトルURLTier
Claude Enterprise のグループ・標準ロール・カスタムロールの関係と制約を図解で整理してみたリンクTier 3
Kiro CLI 2.6 でチャット履歴のエクスポートやターミナルタイトルの設定、起動時の Effort 指定ができるようになりましたリンクTier 3
Amazon SageMaker Data Agent 会話履歴に対応したので実際に試してみたリンクTier 3
LiteLLM Proxyで生成AIによる動的コンテンツフィルターを実装してみたリンクTier 3
Amazon Athena × Bedrock Converse APIで自然言語からSQLを自動生成・実行するエージェントを構築してみたリンクTier 3
Gemma 4 に 12B が追加されたので DGX Spark で日本語性能・音声入力・MTP まで試してみたリンクTier 3
Claude Code v2.1.162〜v2.1.165 の主要アップデートリンクTier 3
Kiro IDE でもモデルの Effort(思考の深さ)を制御できるようになったので確認してみたリンクTier 3
Amazon Bedrock の新コンソール「Bedrock Mantle」を試してみた(GPT-5.5 / Claude Opus 4.8 対応)リンクTier 3
NVIDIA Nemotron 3 Ultra を試してみたリンクTier 3

cloud(10件)

タイトルURLTier
Amazon Bedrock AgentCore Runtime のインタラクティブシェル機能を試してみたリンクTier 3
cdk-local (cdkl) で Bedrock AgentCore Runtime のローカル開発体験を試してみたリンクTier 3
Amazon Bedrock AgentCore Managed HarnessのSkillsがS3からの読み込みに対応しましたリンクTier 3
S3 Presigned URLをCloudFrontでリバプロする構成を検証してみたリンクTier 3
Amazon Quick DesktopからACP連携でKiro CLIにタスクを実行させてみたリンクTier 3
AWS Deadline Cloud の CMF + UBL で 3ds Max を動かしてみたリンクTier 3
Google Workspace Studio でループ処理が利用できるようになりましたリンクTier 3
閉域EC2にSSMS 22をオフラインインストールしてみたリンクTier 3
Amazon Lex でボット応答前の待ち時間にフィラー音を再生できるようになりましたリンクTier 3
Amazon SageMaker Unified StudioでKiro IDEのリモート接続環境を作ってみたリンクTier 3

programming(9件)

タイトルURLTier
cmux で AI エージェントの待機時間を眺める「Pixel Office」を作ったリンクTier 3
actionlintでGitHub Actionsワークフローの構文・式・シェルを静的解析してみるリンクTier 3
Twilio for Claude (MCP + Skills) を Claude Code で触ってみたリンクTier 3
Mobbin MCPを試してみたリンクTier 3
[AWS試験 合格体験記] Claude Codeを使ってAWS CLFに合格できたリンクTier 3
非エンジニアのためのClaude/Claude Codeシリーズ — IT未経験の中途入社が付箋タスク管理からClaudeに助けてもらった話リンクTier 3
UXってなんだろう⑨〜きれいなUIは後で。まず鉛筆と紙で画面を描く〜リンクTier 3
langchain-awsのAmazonS3VectorsでLangGraphのRAGのベクトルストアをマネージドに差し替えてみるリンクTier 3
文系出身がPythonで混同したbreakとcontinueの違い(FETCH_FAILED)リンク-

スキップ(1件)

タイトル理由
JSAI2026(第40回人工知能学会全国大会)にプラチナスポンサーとして協賛しますPR/スポンサー告知のみ、技術分析なし

トレンドの連鎖

1. AIツールのコントロール精度が主戦場になっている

今日の記事を横断して見えてきた最大の潮流は、「AIが何をするかではなく、AIをどう制御するか」への関心の高まりだ。

Claude Code v2.1.162〜165のセキュリティ修正4件は、permission ルールの適用漏れをすべて「悪意のある迂回」ではなく「設定ミスによる穴」として塞いでいる。WebFetch の事前承認ドメインへの deny ルール未適用、~/ への deny が $HOME で回避される問題。これらは「AIツールが広まるにつれ、組織のガバナンス要件も高まっている」ことへの自然な応答だ。

Claude Enterprise のロール・グループ制約の記事も同じ文脈に置ける。カスタムロールとグループの和集合ルールを理解しないと「制限をかけたつもりが効いていない」状態になる。AIツールの組織展開フェーズで「設定を理解している人が少ない」問題が顕在化してきている。

LiteLLMの動的コンテンツフィルターは、Bedrock Guardrailsの「固定カテゴリでは検出できない業務コンテキスト依存の機密」をLLM自体で判定する発想。AIのアウトプット管理にAIを使うメタ構造が、エンタープライズ実用化に入ってきた証左だ。

2. AgentCore が「エージェントのインフラ」として整備されつつある

1日で AgentCore 関連記事が3本同時に出た(インタラクティブシェル・cdk-local対応・Skills S3対応)。これは偶然ではなく、AWS が AgentCore を一般開発者が触れるフェーズに押し上げようとしている動きと読める。

  • インタラクティブシェル: 開発中のエージェントへのデバッグアクセスをSSH不要で提供
  • cdk-local対応: ローカル開発ループを invoke-agentcore 1コマンドで完結させる
  • Skills S3対応: スキルファイルのCI/CDフローへの統合が現実的になった

「エージェントを作る」から「エージェントを運用する」へのパスが、日々ツールチェーンとして整備されている段階だ。

3. モデルの競争軸が「テキスト精度」から「マルチモーダル統合×コスト効率」に移行している

Gemma 4 12Bの評価では「テキストのみなら E4B(4.5B)で十分」という結果が出た。日本語常識推論で 4.5B と 12B のスコアがほぼ同じというのは、小型モデルの能力が飽和に近づいていることを示す。12B の差別化は音声入力対応と MTP による 2.8 倍高速化にある。つまりモダリティの統合とスループット改善が勝負どころだ。

**NVIDIA Nemotron 3 Ultra(550B)**も同様の論理で理解できる。日本語推論では 30B クラスと差が出なかったが、60 万トークンの long-running agent 向けユースケースで真価を発揮する。「モデルが賢い」より「長く走り続けられるか」「どのモダリティをカバーするか」が競争軸になってきた。

Bedrock Mantleは GPT-5.5 と Claude Opus 4.8 を同一プラットフォームで比較できる環境を提供している。マルチプロバイダーを使い分けることが前提の世界観が、インフラ側から整えられている。

4. Kiro エコシステムの急速な拡張

Kiro CLI 2.6(--effort フラグ・履歴エクスポート)、Kiro IDE の Effort UI 追加、Amazon Quick Desktop との ACP 連携、SageMaker Unified Studio のリモート接続対応。1日でKiro関連記事が4本出た。Claude Code との対比で見ると、Kiro はAWSのインフラとの統合(SageMaker、ACP、AgentCore)に強みを張っている。AWSエコシステム内でのエージェント開発ツールとしての地位を積極的に固めている動きだ。

5. AIツールの末端ユーザーへの浸透が確実に進んでいる

AWS CLF合格体験記非エンジニアのClaude活用体験は、技術記事というよりユーザーストーリーに近い。これが DevelopersIO に掲載されること自体が、AIツールの利用者層が「エンジニア」から「組織全体」に広がっていることを反映している。Claude/Claude Code がコーディングツールとしてではなく、業務効率化ツールとして末端ユーザーに届いている。


記事別詳細レポートへのリンク

ai-llm

cloud

programming


記事別詳細

dev-classmethod-jp-articles-20260603-cc-updates-v2-1-165

Claude Code v2.1.162〜v2.1.165 の主要アップデート

  • URL: https://dev.classmethod.jp/articles/20260603-cc-updates-v2-1-165/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Claude Code v2.1.162〜v2.1.165(2026/6/3〜6/5)の変更51件を総まとめ。セキュリティ修正4件(permission ルールの適用漏れ)、管理者設定によるバージョン強制、Stop フックの additionalContext 対応が主要変更。

詳細

新機能:

  • requiredMinimumVersion / requiredMaximumVersion 管理者設定: 組織がClaude Codeのバージョン範囲を強制(v2.1.163)。minimumVersion(自動更新防止)より強く、範囲外では起動拒否
  • Stop/SubagentStop フックが hookSpecificOutput.additionalContext を返せるように(v2.1.163): エラーやブロックなしにClaude に追加文脈を渡してターンを継続
  • /plugin list(v2.1.163): インストール済みプラグインを --enabled/--disabled フィルタ付きで一覧表示
  • claude agents --jsonwaitingFor フィールド追加(v2.1.162)

セキュリティ修正(v2.1.162〜163):

  • WebFetch 事前承認ドメインに permission ルールが適用されない問題
  • Windows でバックスラッシュ表記・大文字小文字違いのパスでルールがマッチしない問題
  • 組織管理 permission ルールが新規 config ディレクトリ起動時に未適用になる問題
  • ~/ への deny ルールが $HOME 参照でバイパスされる問題

主な不具合修正:

  • claude -p がバックグラウンドコマンド未終了時に永久ハング(v2.1.163)
  • Bedrock/Vertex/Microsoft Foundry + CI=true での “ANTHROPIC_API_KEY required” エラー(v2.1.163)

その他変更:

  • Windsurf → Devin Desktop へのリブランド対応(v2.1.162)
dev-classmethod-jp-articles-20260605-amazon-amda-conversation-history

Amazon SageMaker Data Agent 会話履歴に対応したので実際に試してみた

詳細

  • 新機能: チャットパネルヘッダーの時計アイコンから会話履歴にアクセス。過去の会話がタイトル(最初のメッセージ先頭)と最終アクティビティ日時付きで最新順に一覧表示される
  • 保存仕様: 自動保存・90日間保持。AWS CLI/SDK からのアクセスAPIは提供されておらず、UIのみ
  • 実験内容: ①日本語での機能説明会話 ②Pythonで3都市の架空売上データをDataFrameで作成しグラフ化 → 履歴一覧に2件が表示されたことを確認
  • 気になった点: 「新しい会話を作成すると現在のチャットには戻れない」という警告文が誤解を招く表現だが、実際には会話履歴として残るため参照可能
  • 日本語対応: 日本語での質問・回答・コード生成とも問題なく動作
  • 評価: 探索的なデータ分析で会話が長くなりがちな場面での実用性向上。継続的な分析文脈の保持に効く
dev-classmethod-jp-articles-amazon-lex-audio-filler

Amazon Lex でボット応答前の待ち時間にフィラー音を再生できるようになりました

  • URL: https://dev.classmethod.jp/articles/amazon-lex-audio-filler/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Amazon Lex の新機能 Audio Filler を解説。Amazon Connect + Lex の通話シナリオで、ユーザー発話からボット応答開始までの無音時間にメロディーやタイピング音を再生できるようになった。日本語ロケール(ja_JP)と東京リージョン(ap-northeast-1)は現時点で未対応。

詳細

  • 対象: speech-to-speech に対応し unifiedSpeechSettings が設定されたボットロケールのみ利用可
  • 日本語/東京リージョン: 現時点(検証時)では speech-to-speech 未対応のため Audio Filler は利用不可
  • フィラー音7種:
    • Melody: Chipper Chime, Curious Crawl, Rising Ripple, Patient Ping, Pondering Pong
    • Typing: Kinetic Keys, Quiet Qwerty
  • タイミングパラメータ:
    • startDelayInMilliseconds: 発話終了後フィラー音再生開始までの待ち時間
    • minimumPlayDurationInMilliseconds: 最低限再生する時間(応答が早くても)
    • responseDeliveryDelayInMilliseconds: フィラー音終了後にボット応答を開始するまでの待ち時間
  • ユースケース: Lambda コードフック・外部API連携・バックエンドシステム照会で応答に数秒かかるケース。無音時間を自然な「処理中」表現に変換
  • 評価: 英語圏のコンタクトセンター向けに先行対応。日本語対応は今後の展開を待つ状況
dev-classmethod-jp-articles-amazon-quick-desktop-kiro-cli-acp

Amazon Quick DesktopからACP連携でKiro CLIにタスクを実行させてみた

  • URL: https://dev.classmethod.jp/articles/amazon-quick-desktop-kiro-cli-acp/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Amazon Quick Desktop(デスクトップAIアシスタント)からKiro CLI を ACP(Agent Client Protocol)経由でタスク実行させる検証。ローカル接続とSSH経由リモート接続の両方を試し、マルチターン対話・並列実行・セキュリティ承認の動作を確認。

詳細

  • ACP とは: stdin/stdout上のJSON-RPC 2.0でAIエージェントとクライアントを標準化するプロトコル。LSP の AI 版
  • セットアップ: Quick の Settings → Capabilities → MCP → Coding Agents に Kiro をプリセット登録(Command自動設定)
  • 動作確認:
    • タスク実行: 「Kiroに○○を頼んで」の自然言語指示で実行
    • マルチターン: task_name によるコンテキスト保持で継続的なやり取りが可能
    • 並列実行: ローカルKiroとリモートKiroへの同時タスク実行が可能
  • セキュリティ: sudo 等の危険コマンドは Quick UI に承認ダイアログが表示(人間の判断を介在)
  • SSH リモート接続: JSON-RPCの initialize リクエストが SSH 経由で正常応答することを事前確認。成功条件: 非対話ログイン、初回hostkey確認済み、余計な stdout なし
  • 環境: macOS Tahoe 26.5.1, Amazon Quick Desktop v0.811.0, Kiro CLI v2.6.0, Claude Opus 4.6
dev-classmethod-jp-articles-athena-bedrock-converse-api-natural-language-sql-agent

Amazon Athena × Bedrock Converse APIで自然言語からSQLを自動生成・実行するエージェントを構築してみた

詳細

  • なぜ Bedrock Agents ではなく自前ループか: Lambda 不要で直接 Athena を呼べる。ストリーミング制御・カスタムUI・ループ制御・デバッグが自由
  • アーキテクチャ: FastAPI → bedrock_runtime.converse() (tool_use でSQLツール定義) → Claudeが SQL 生成 (stop_reason: "tool_use") → Athena に直接実行 → toolResult として追加 → 再度 converse()end_turn まで繰り返す
  • S3/Parquet採用理由: Athena は結果を S3 に書き出す仕様。Parquet 形式はカラムナ形式でスキャン量を減らしコスト削減、型情報保持、高圧縮効率
  • 環境: Python 3.12, boto3, ap-northeast-1, Parquetデータ: S3の sql/ プレフィックス以下にテーブル別フォルダ
  • 集計・比較クエリへの対応: RAGだけでは対応困難な「2025年度1Qの売上合計は?」のような集計型質問に対応できる
  • 評価: 既存アプリケーションサーバーがある場合は Bedrock Agents より Converse API の自前ループがシンプル
dev-classmethod-jp-articles-aws-deadline-cloud-cmf-ubl-3dsmax

AWS Deadline Cloud の CMF + UBL で 3ds Max を動かしてみた

  • URL: https://dev.classmethod.jp/articles/aws-deadline-cloud-cmf-ubl-3dsmax/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: AWS Deadline Cloud のカスタマーマネージドフリート(CMF)と従量課金ライセンス(UBL)を組み合わせて Autodesk 3ds Max のレンダリングが成立するかを実機検証。ジョブSUCCEEDEDまで完走し、UBL経由ライセンス取得・レンダリング結果のPNG出力を確認。

詳細

  • 検証ゴール: ①ジョブがSUCCEEDEDまで完走 ②3ds MaxがLicense Endpoint(AWS PrivateLink)経由でライセンス取得 ③PNG画像がS3経由で取得できること → すべて達成
  • 所要時間: S3同期4秒、3ds Max起動1分40秒、Scanlineレンダリング1フレーム6.8秒、合計約2分
  • 環境: Windows Server 2022 EC2(Submitter/Worker)、3ds Max 2026、Deadline Cloud Monitor + Identity Center認証

知見1: 3ds MaxをTrial状態のままUBLライセンスを取得できる

  • AdskLicensingInstHelper change --lm NETWORK でのNETWORKモード切り替えは Autodesk PIT config により失敗する
  • 正しいアプローチ: 公式サンプルスクリプト(deadline-cloud-samples)に倣い、Trial状態のままインストール。deadline-cloud-for-3ds-max Adaptor がジョブ実行時に License Endpoint からライセンスを取得する。環境変数 ADSKFLEX_LICENSE_FILE=2704@<endpoint-dns> を Machine スコープで設定するだけ

知見2: CMF Fleet Worker Role に CloudWatch Logs 権限を手動付与が必要

  • AWSDeadlineCloud-FleetWorker マネージドポリシーには CloudWatch Logs 権限が含まれない
  • CreateLogStream の AccessDenied エラーで Worker Agent サービスが起動失敗
  • インラインポリシーで /aws/deadline/<farm-id>/<fleet-id> へのログ書き込み権限を手動追加が必要
dev-classmethod-jp-articles-bedrock-agentcore-harness-skills-s3-source

Amazon Bedrock AgentCore Managed HarnessのSkillsがS3からの読み込みに対応しました

  • URL: https://dev.classmethod.jp/articles/bedrock-agentcore-harness-skills-s3-source/
  • 日付: 2026-06-06
  • Tier: Tier 3
  • 要旨: AgentCore Managed Harness の Skills が S3(および Git)からの読み込みに対応。コンソールから HarnessSkillS3Source を指定してスキルを登録できるようになり、マークダウンのみとスクリプト付きの2パターンを実験。

詳細

  • Agent Skills 概要: Strands Agents(Harness 内部フレームワーク)のプラグイン機構。マークダウン + オプションスクリプトでエージェントにドメイン知識を付与
  • 新機能: HarnessSkillS3SourceHarnessSkillGitSource が APIリファレンスに追加。コンソールから S3 URL を指定してスキルを登録可能
  • スキル1(マークダウンのみ): 架空の社内用語辞書(SKILL.md with YAML フロントマター)を S3 に配置。Harness 実行ロールに AmazonS3ReadOnlyAccess が必要(デフォルトでは AccessDenied)
  • スキル2(スクリプト付き): allowed-tools: shell を指定し、Python 営業日計算スクリプトを shell ツール経由で実行させる構成
  • 動作確認: Playground で「Phoenixプロジェクトの概要を教えて」→ スキルの社内用語辞書から正確に回答、トレース上で Skills ツールの呼び出しを確認
  • 評価: S3対応により「ファイルパス指定しかできない」制約が解消。CI/CDでスキルを更新→S3にアップロードするフローが組みやすくなった
dev-classmethod-jp-articles-bedrock-agentcore-runtime-interactive-shell

Amazon Bedrock AgentCore Runtime のインタラクティブシェル機能を試してみた

  • URL: https://dev.classmethod.jp/articles/bedrock-agentcore-runtime-interactive-shell/
  • 日付: 2026-06-06
  • Tier: Tier 3
  • 要旨: 2026年6月5日追加の AgentCore Runtime インタラクティブシェル機能を実機確認。SSH なしでリモート microVM 上のエージェントにターミナル接続できる。Claude Code、OpenAI Codex、Amazon Kiro が対応エージェントとして言及。

詳細

  • ワンショット vs インタラクティブ:
    • ワンショット: InvokeAgentRuntimeCommand(HTTP/2、ステートレス)
    • インタラクティブ: InvokeAgentRuntimeCommandShell(WebSocket、永続セッション、env/cwd/historyを保持)
  • 再接続: shellId で同じシェルに再接続可能(最大1時間セッション)
  • 課金: インタラクティブシェル固有の追加料金なし。Active Consumption Based(CPU $0.0895/vCPU-hour、Memory $0.00945/GB-hour)がアイドル中もメモリ課金あり
  • プロジェクト作成: agentcore create --name StrandsShellTest --defaults(Strands フレームワークを使用)
  • デプロイ: Docker コンテナ内で agentcore deploy -y(内部で uv を使用するため python3 + uv が必要)
  • 環境: us-west-2, @aws/agentcore CLI, node:20-slim イメージ
  • 評価: コーディングエージェントのデバッグや環境確認で SSH を使わずに直接接続できる点が便利
dev-classmethod-jp-articles-bedrock-mantle-console-gpt55

Amazon Bedrock の新コンソール「Bedrock Mantle」を試してみた(GPT-5.5 / Claude Opus 4.8 対応)

  • URL: https://dev.classmethod.jp/articles/bedrock-mantle-console-gpt55/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: 2026年6月4日に公開された Bedrock Mantle(OpenAI/Anthropic 互換APIエンドポイント)の新コンソールをレポート。GPT-5.5・Claude Opus 4.8 の料金・リージョン差分、Projects 管理、SDK接続例まで詳述。

詳細

  • Bedrock Mantle の特徴: 専用エンドポイント bedrock-mantle.{region}.api.aws。認証は Bedrock APIキーまたは IAM(SigV4 ではなく)。OpenAI Chat Completions/Responses API および Anthropic Messages API を提供
  • 従来の Bedrock Runtime との違い: エンドポイント・API 体系・認証方式・コンソール整理単位(Projects)・CLI ツールが異なる
  • 主要モデルの料金(2026-06-05 時点):
    • GPT-5.5(us-east-2): 入力 $5.50/1M, 出力 $33.00/1M, コンテキスト272K
    • GPT-5.4(us-east-2, us-west-2): 入力 $2.75/1M, 出力 $16.50/1M
    • Claude Opus 4.8(us-east-1, ap-northeast-1): 入力 $5.00/1M, 出力 $25.00/1M, コンテキスト1M
  • リージョン差分: Claude Opus 4.8 は us-east-1, ap-northeast-1。GPT-5.5 は us-east-2 のみ(東京では未対応)
  • GPT-5.5 利用時の内部モデル: Dashboard に gpt-5.5-unshieldedcotea-classifier-v08-al などの内部モデル名が計上される(OpenAI直接利用では見えない情報)
  • SDK 接続: Anthropic SDK の base_urlbedrock-mantle.{region}.api.aws/anthropic に向けるだけで動作
  • AIコーディングアシスタント接続: Claude Code, Cline, Codex, Cursor, OpenCode の接続ガイドが Getting started 画面に用意
dev-classmethod-jp-articles-cdk-local-bedrock-agentcore-runtime

cdk-local (cdkl) で Bedrock AgentCore Runtime のローカル開発体験を試してみた

  • URL: https://dev.classmethod.jp/articles/cdk-local-bedrock-agentcore-runtime/
  • 日付: 2026-06-06
  • Tier: Tier 3
  • 要旨: go-to-k/cdk-local(cdkl)の invoke-agentcore サブコマンドと CDK --hotswap の AgentCore 対応を実測。cdkl/hotswap/通常デプロイの3手法でデプロイ速度を比較し、cdkl の --from-cfn-stack--assume-role 機能も確認。

詳細

  • 3手法の位置づけ:
    • cdkl invoke-agentcore: ローカル開発・即時テスト向け(cdkl は開発用)
    • cdk deploy --hotswap: イメージ更新のみのケースを高速化
    • cdk deploy(通常): 本番反映に使用
  • 検証環境: EC2 t4g.medium (ARM64), Amazon Linux 2023, CDK CLI 2.1125.0, cdk-local 0.105.0, us-east-1
  • アプリ構成: AgentCore Runtime アプリは /ping(GET)と /invocations(POST)をポート8080で実装。環境変数 GREETING の値を返すシンプルな Python サーバー
  • CDK スタック: SSM パラメータから環境変数を取得し agentcore.Runtime に渡す。AgentRuntimeArtifact.fromCodeAsset でコードを直接パッケージング
  • cdkl 独自機能: --from-cfn-stack で既存 CloudFormation スタックから設定を読み込み、--assume-role でロール切り替えをサポート
  • 評価: ローカルから AgentCore Runtime をターミナル一発で呼び出せる開発体験は CI/CD 組み込み前の高速イテレーションに有効
dev-classmethod-jp-articles-claude-enterprise-roles-groups-constraints

Claude Enterprise のグループ・標準ロール・カスタムロールの関係と制約を図解で整理してみた

詳細

  • 3つの構成要素:

    • グループ: メンバーをまとめる単位。カスタムロールを割り当てる先
    • 標準ロール: Primary Owner / Owner / Admin / User の4階層。管理権限の序列
    • カスタムロール: アプリ機能の ON/OFF(Claude Code, Chat, web検索など)と一部管理権限を組み合わせて定義
  • 制約①: グループに渡せるのはカスタムロールのみ。標準ロールはメンバー単位にのみ割り当て可

  • 制約②: 標準ロール(User/Admin/Owner)とカスタムロールは排他。カスタムロールが有効になるのはメンバーを「Custom roles」モードに設定した場合のみ

  • 制約③: 複数グループに所属すると各グループのカスタムロールは和集合(OR)で合成される。確実に禁止したい機能は「許可のないロールだけを割り当てる設計」が必要

  • 組織レベルのトグルが最上位: 組織でオフにした機能はロールに関わらず利用不可。標準ロールは組織設定を自動継承するが、カスタムロールは明示的に許可した機能のみ使える

  • 実践的意義: 「機能制限をかけたのに効かない」原因の大半はこれら3制約の誤解。部分管理者権限(billing/identity/privacy)はカスタムロールでグループ経由付与が可

dev-classmethod-jp-articles-cloudfront-s3-signature-oac-comparison

S3 Presigned URLをCloudFrontでリバプロする構成を検証してみた

  • URL: https://dev.classmethod.jp/articles/cloudfront-s3-signature-oac-comparison/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: S3 Presigned URL をCloudFrontでリバプロする方式と CloudFront署名付きURL + OAC の2方式を実際に構築して比較。結論は「新規設計なら OAC 方式が基本」で、リバプロ方式には CloudFront バイパス・WAF回避・キャッシュ不能という制約あり。

詳細

  • 背景: 許可ドメイン制限環境で S3 ドメインにアクセスできない場合の代替構成を検証
  • 重要な前提: S3 Presigned URL と OAC は併用不可(InvalidArgument: Only one auth mechanism allowed エラー)。リバプロ方式ではOACを外す必要がある

リバプロ方式(S3 Presigned URL + CloudFront)の問題点:

  1. S3 ドメインへの直接アクセスが可能(CloudFront バイパス)
  2. CloudFront 側の WAF・IP制限・Shield Standard がバイパスされる
  3. X-Amz-Signature クエリパラメータが毎回変化するためキャッシュキーが変動しCDNとして機能しない

CloudFront署名付きURL + OAC 方式の特徴:

  • OAC あり(originAccessLevels: [READ, WRITE])で s3:PutObject も許可

  • trustedKeyGroups で CloudFront 公開鍵による署名を必須化

  • マルチパートアップロード(CreateMultipartUpload/CompleteMultipartUpload)も通ることを実証

  • CDK 設定例: ビヘイビアに AllowedMethods.ALLOW_ALL + CachingDisabled + ALL_VIEWER_EXCEPT_HOST_HEADER + trustedKeyGroups を組み合わせ

  • 評価: 既存システムの改修コストが小さいリバプロ方式は「動くが安全でない」。新規設計は OAC 方式一択

dev-classmethod-jp-articles-co-takanami-aws-clf-passed

[AWS試験 合格体験記] Claude Codeを使ってAWS CLFに合格できた

  • URL: https://dev.classmethod.jp/articles/co-takanami-aws-clf-passed/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: 新卒がClaude Codeを使ってAWS CLF試験対策用のランダム出題模擬問題アプリを生成し、一発合格した体験記。AIを問題生成ツールとして活用するアプローチが具体的。

詳細

  • 課題: 市販の模擬問題は問題と選択肢の順序が固定されており、丸暗記になりがち
  • 解決策: Claude Codeに自然言語プロンプトで模擬問題アプリの仕様を渡し、ランダム出題・タイマー・見直し機能付きのWebアプリを生成
  • 生成アプリの機能: ①65問ランダム出題(ドメイン比率準拠)②90分タイマー(残り5分で赤点滅)③「あとで見直す」フラグ ④採点結果(1000点換算)⑤答案履歴の多軸フィルタ
  • 効果: 問題・選択肢ともにシャッフルされるため、毎回異なる出題順で対策できた
  • 課題: AI生成問題が易しすぎた可能性があり、得点率と理解度の乖離が生じる懸念
  • 教訓: 非エンジニアでも自然言語で具体的な仕様を伝えればClaude Codeが実用的なツールを生成できる
dev-classmethod-jp-articles-dgx-spark-gemma4-12b-allround

Gemma 4 に 12B が追加されたので DGX Spark で日本語性能・音声入力・MTP まで試してみた

  • URL: https://dev.classmethod.jp/articles/dgx-spark-gemma4-12b-allround/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Gemma 4 ファミリーに追加された12B(E4Bと26B-MoEの中間)を DGX Spark で実機評価。日本語常識テストではE4Bとほぼ同等だが、中量級初の音声入力対応とDrafter付属のMTPによる2.8倍高速化が差別化ポイント。

詳細

  • アーキテクチャ: Encoder-free。画像(35M埋め込み層, 48×48pxパッチ)・音声(16kHz→40msフレーム→線形変換)・テキストが同一の重みを共有
  • コンテキスト: 256Kトークン(E4Bより大幅拡大)
  • 日本語常識テスト (JCommonsenseQA, 1116問):
    • E4B: 94.1% / 0.15秒
    • 12B: 94.6% / 0.32秒
    • 31B: 97.7% / 4.84秒
      → E4Bとほぼ同等スコア。常識推論ではE4Bが天井に近いため中量級の差が出にくい
  • 日本語音声 (FLEURS 100件): CER中央値16.1%、平均23.1%。同音異義語で取り違える傾向あり(専用ASRの1桁台CERには及ばない)
  • 画像 (JMMMU 300問): 45.7%。文章主体の分野は得意(CS:75%、心理:75%)、工学系図面は不得意(機械:0%)
  • MTP (vLLM nightly + drafter gemma-4-12B-it-assistant): baseline 7.7 tok/s → MTP(spec=4) 21.5 tok/s(約2.8倍)
  • 動作条件: transformers は GitHub main から取得が必要(gemma4_unified 新アーキ対応のため)。torchvision・ninja 問題あり
  • 評価: テキストのみなら E4B で十分。音声を含むマルチモーダルを1モデルで回す用途・16GBでの手軽な運用に12Bが有利
dev-classmethod-jp-articles-dgx-spark-nemotron3-ultra-nvidia-api

NVIDIA Nemotron 3 Ultra を試してみた

  • URL: https://dev.classmethod.jp/articles/dgx-spark-nemotron3-ultra-nvidia-api/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: 2026年6月4日公開のNVIDIA Nemotron 3 Ultra(550B-A55B MoE)をNVIDIAの無料APIで評価。日本語数学推論ではNano/Superと横並びだが、60万トークンのneedle-in-haystack(14/15マス成功)でロングコンテキスト優位性を確認。

詳細

  • アーキテクチャ: LatentMoE(Mamba-2 + Transformer + MoE ハイブリッド)。Mamba層が長コンテキストを効率処理、Transformer層が正確な事実想起を担当
  • Ultra のターゲット: long-running agent(複雑コーディング・長時間リサーチ・社内ワークフロー自動化)
  • 必要ハードウェア: NVFP4量子化で重み約335GB。最小構成はB200×4枚またはH100 80GB×8枚(VRAM 600GB超)。DGX Spark(128GB)では不可
  • NVFP4量子化: BF16から最大2〜3ポイントの劣化で推論5倍速・エージェント運用コスト最大30%削減
  • 日本語推論 (難問8問): Nano(30B-A3B)・Super(120B-A12B)・Ultra がすべて7/8(差なし)。普段使いの推論は小型モデルで十分な状態
  • ロングコンテキスト (needle-in-haystack): 先頭・中央・末尾×5サイズ(6千〜60万トークン)で14/15成功。60万トークンでも35秒で抽出。公式 Ruler 1M スコア 95%
  • API接続: build.nvidia.com の無料API(OpenAI互換)。enable_thinking=True で reasoning_content が別フィールドに分離
  • ソブリンAI: 重み・データ・レシピが公開されており、ハードさえあれば自社データセンターに閉じて運用可(機密不出力の用途向け)
  • Nano/Super/Ultraの使い分け: 日常のローカル推論→Nano/Super。1M コンテキストを要する long-running agent やソブリン運用→Ultra
dev-classmethod-jp-articles-gha-actionlint-basics

actionlintでGitHub Actionsワークフローの構文・式・シェルを静的解析してみる

  • URL: https://dev.classmethod.jp/articles/gha-actionlint-basics/
  • 日付: 2026-06-06
  • Tier: Tier 3
  • 要旨: GitHub Actions ワークフロー専用の静的解析ツール actionlint の基本的な使い方を実例付きで解説。ランナーラベルの検証、式の型チェック、スクリプトインジェクション検出まで対応。

詳細

  • ツール概要: actionlint はGo製。.github/workflows/*.yml を push 前にローカルで検証できる
  • 検出できる問題: ①ランナーラベルの typo(ubuntu-latest-xl は無効と指摘)、②${{ github.event.head_commit.message }} のスクリプトインジェクションリスク、③未定義の matrix.os 参照
  • shellcheck 連携: シェルスクリプトを shellcheck で二次チェック。-shellcheck= で無効化可能
  • 設定集約: .github/actionlint.yaml で self-hosted ランナーラベルなどを設定
  • インストール: macOS なら brew install actionlint
  • 実用性: CI試行回数を減らせる。終了コード1でCIにそのまま組み込める
dev-classmethod-jp-articles-google-workspace-studio-loop-processing

Google Workspace Studio でループ処理が利用できるようになりました

  • URL: https://dev.classmethod.jp/articles/google-workspace-studio-loop-processing/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: 2026年6月2日GA。Google Workspace Studio の「Repeat for each」ステップにより、Gemini が生成したリストや Google Sheets のデータ行を自動ループ処理できるように。合わせて Ask Gemini に「Response format(リスト形式)」が追加。

詳細

  • 変更前の課題: リスト形式データを処理するには同じステップを手動で複製する必要があった
  • 「Repeat for each」ステップのデータソース: ①Ask Gemini がリスト形式で返したリスト、②Google Sheets のデータ行
  • Ask Gemini の Response format: 「テキスト形式」と「リスト形式」を選択可能。リスト形式を選ぶと Repeat for each で後続ループが使えるようになる
  • ユースケース例:
    • 議事録からタスク自動作成(Gemini でアクションアイテムリスト化 → 各アイテムへのタスク作成)
    • 営業メール下書き自動生成(Google Sheets の顧客リスト → 各行ごとにメール生成)
  • 実装例: 顧客リスト(Google Sheets)→ 繰り返しステップ内で Gemini メール生成 → Google Chat で件数通知
  • 対象プラン: Business Starter/Standard/Plus, Enterprise Standard/Plus, Education 各プランなど
  • 評価: ノーコードのワークフロー自動化でバッチ処理ができるようになり、繰り返し作業の自動化の幅が広がった
dev-classmethod-jp-articles-kaho-claude-task

非エンジニアのためのClaude/Claude Codeシリーズ — IT未経験の中途入社が付箋タスク管理からClaudeに助けてもらった話

  • URL: https://dev.classmethod.jp/articles/kaho-claude-task/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: 前職で付箋タスク管理を続けていた営業職がClaude.ai(SlackとGoogle Calendarコネクタ)を使い、Slackメモを自動でTODOリスト化してカレンダー登録するワークフローを構築した体験記。

詳細

  • ツール: Claude.ai にSlack・Google Calendarのコネクタを接続(設定画面から事前に連携)
  • ワークフロー: 「自分のSlack DMを見て、タスクを整理して」の一言で①Slack DMを取得 ②TODOを優先度別に抽出 ③Google Calendarに期日付きイベントとして登録
  • 便利な点: チャンネルIDを自分で調べる必要なし。完了済みタスクの重複登録を指示で防止可
  • 毎朝の使い方: 朝に「今日のSlackメモ整理して」と送るだけで一連のフローが動く
  • 評価: 「友達のように話しかけるだけ」でITツール連携ができる非エンジニア向けユースケースの好例。ツール設定の説明も不要でClaude自身が案内する
dev-classmethod-jp-articles-kiro-cli-2-6-newcommand

Kiro CLI 2.6 でチャット履歴のエクスポートやターミナルタイトルの設定、起動時の Effort 指定ができるようになりました

  • URL: https://dev.classmethod.jp/articles/kiro-cli-2-6-newcommand/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Kiro CLI 2.6 の主要4機能を実機確認。--effort 起動フラグの追加、/model/effort の自動永続化、/transcript save でのチャット履歴エクスポート、/title でのターミナルウィンドウタイトル設定。

詳細

  • --effort フラグ: kiro-cli chat --effort low のようにセッション起動時に思考量レベル(low/medium/high/xhigh/max)を指定可能。毎回 /effort コマンドを実行する必要がなくなった
  • Effort 対応モデル: Claude Opus 4.8/4.7 は low〜max の5段階対応、Claude Opus 4.6・Sonnet 4.6 は low/medium/high/max の4段階。xhigh は Opus 4.7 以降のみ
  • 自動永続化: /model/effort の変更が ~/.kiro/settings/cli.jsonchat.modelDefaults に自動書き込み。モデルごとの effort 設定が保持される
  • /transcript save: 現在のセッション会話履歴を markdown/プレーンテキスト/JSON 形式でファイルに書き出し。チームへの共有やチケット添付に使用可
  • /title: 複数ターミナルウィンドウで Kiro CLI を使う場合にウィンドウを識別するタイトルを設定。/settings display → Terminal title で有効化
dev-classmethod-jp-articles-kiro-ide-rffort

Kiro IDE でもモデルの Effort(思考の深さ)を制御できるようになったので確認してみた

  • URL: https://dev.classmethod.jp/articles/kiro-ide-rffort/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Kiro IDE パッチ 0.12.292 でチャットパネルに Effort 制御 UI(Adaptive Thinking Controls)が追加。モデルセレクター横のドロップダウンから5段階選択可能になり、設定はワークスペース単位で永続化。

詳細

  • 変更点: アップデート後のモデルセレクターに Auto トグルと各モデルの「Edit」ボタンが追加。Edit ボタンから Low/Medium/High/xHigh/Max の5段階 Effort を設定
  • Effort 対応モデル: Claude Sonnet 4.6 以上(Opus 4.7/4.8/4.6、Sonnet 4.6)のみ Edit ボタンが表示。Haiku や Deepseek、MiniMax は非対応
  • 永続化: ワークスペース単位で Effort 設定を保持。モデル切り替え時も可能な限り設定が維持され、非対応レベルは最も近いレベルに自動調整
  • Auto モード: トグル ON で Auto のみ表示(モデルが自動選択)。OFF で個別モデル選択とEffort設定が可能
  • CLIとの比較: CLI では /effort コマンドで手動切り替えが必要だったが、IDE ではドロップダウンワンクリックで完結
dev-classmethod-jp-articles-kiro-sagemaker-unified-stuido-remote-server

Amazon SageMaker Unified StudioでKiro IDEのリモート接続環境を作ってみた

  • URL: https://dev.classmethod.jp/articles/kiro-sagemaker-unified-stuido-remote-server/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Kiro IDE には信頼できるRemote SSH拡張がないという制約のなか、Amazon SageMaker Unified Studio が Kiro からのリモート接続に対応していることを発見し、Code Editor スペース(ml.t3.large)を作成してリモート接続する手順を検証。

詳細

  • 背景: VS Code は Remote SSH 拡張が定番だが Kiro IDE には相当品がない。SageMaker Unified Studio の「ローカルIDEから接続」メニューに Kiro アイコンが表示される
  • スペース作成手順:
    1. SageMaker Unified Studio コンソール → スペース → 「VS Code用エディタ」
    2. IDE: Code Editor, インスタンス: ml.t3.large(リモートアクセスにはメモリ8GB必要なため最小サイズ)
    3. リモートアクセスにチェック(これでローカルKiroからアクセス可能になる)
    4. アイドルタイムアウト: 1時間(デフォルト、停止忘れ防止)
  • 接続手順: スペース一覧 → Kiroアイコン → ローカルKiro IDE が起動 → SageMaker にサインイン → リモートワークスペースが開く
  • Kiro IDE からスペースの起動停止: Kiro 左メニューの AWS アイコン → SAGEMAKER UNIFIED STUDIO でスペースのダブルクリック起動・停止ボタン停止が可能
  • 認証: IAMベースドメイン(IAM Identity Center 未使用環境でも利用可)
  • 評価: スペース作成後はKiroから直接起動停止できるため、毎回AWSコンソールに入る手間がなく実用的
dev-classmethod-jp-articles-litellm-dynamic-content-filter

LiteLLM Proxyで生成AIによる動的コンテンツフィルターを実装してみた

  • URL: https://dev.classmethod.jp/articles/litellm-dynamic-content-filter/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: LLM自体を判定エンジンとして使うセマンティックフィルターを LiteLLM の CustomGuardrail として実装。「来期のA社向けプロジェクト予算は5000万」のような業務コンテキスト依存の機密情報を、Bedrock Guardrailsの固定カテゴリでは検出できない問題をLLMの文脈理解で補完。

詳細

  • アーキテクチャ: リクエスト → LiteLLM Proxy → async_pre_call_hook で Claude Haiku 4.5 に判定させる → ブロック/通過 → 本体LLMへ転送
  • 判定モデル: Bedrock Structured Output(Pydantic → outputConfig.textFormat)で is_blocked / reason / violated_policy を構造化返却。フォーマット不一致エラーを最小化
  • ポリシー定義: JSONファイルに自然言語でルールを記述(standard / strict レベルに分割)。エンジニア以外でも読み書き可能
  • 標準ポリシー例: 「個人情報を含むメッセージを禁止」「未公開製品情報・予算・顧客との契約条件の送信を禁止」
  • Bedrock Guardrailsとの比較:
    • Guardrails: キーワード/パターンマッチ、低レイテンシ(数十ms)、固定カテゴリ
    • LLMフィルター: 意味ベース検出、LLM呼び出し分のレイテンシ追加、自然言語ポリシー
  • 評価: 両者は排他でなく重ねがけ可能。Haiku は低コストなため運用コストも抑制可能
dev-classmethod-jp-articles-litellm-langgraph-s3vectors

langchain-awsのAmazonS3VectorsでLangGraphのRAGのベクトルストアをマネージドに差し替えてみる

  • URL: https://dev.classmethod.jp/articles/litellm-langgraph-s3vectors/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: LangGraph RAG のベクトルストアをローカル ChromaDB からマネージドな Amazon S3 Vectors(langchain-awsAmazonS3Vectors クラス)に差し替える実装例。boto3を直接触らずに LangChain retriever インターフェースに統合。

詳細

  • 背景: S3 Vectors を直接使う場合、埋め込み生成→put→queryのループを毎回自前で書く必要があり、LangChain/LangGraphに統合しにくい
  • 解決策: langchain-awsAmazonS3VectorsBedrockEmbeddingsamazon.titan-embed-text-v2:0)を渡すと自動でベクトル化→S3 Vectors へ保存
  • 統合方法: as_retriever() で LangChain 標準 retriever に変換し、LCELパイプライン・StateGraph・@tool に直接組み込める
  • 依存関係: Python 3.13, litellm 1.83.14, langgraph 1.1.10, langchain-aws 1.4.6
  • 前提: S3ベクトルバケット作成済み、Bedrock amazon.titan-embed-text-v2:0 有効化済み
  • インデックス: コード側で自動作成される(バケットのみ事前作成が必要)
  • LLM: ChatLiteLLM(Anthropic SDK経由)を使用。S3 Vectors 側と組み合わせてRAGエージェントを構成
dev-classmethod-jp-articles-mobbin-mcp-setup-claude-code

Mobbin MCPを試してみた

  • URL: https://dev.classmethod.jp/articles/mobbin-mcp-setup-claude-code/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Mobbinの60万件超UIスクリーンショットをClaude CodeからMCP経由で検索できる「Mobbin MCP」の導入手順と活用例。UIパターン分析やFigmaへの参照貼り付けまでのワークフローを実演。

詳細

  • セットアップ: claude mcp add mobbin --scope user --transport http https://api.mobbin.com/mcp の1コマンド後、/mcp で認証
  • 提供ツール: search_screens の1ツールのみ。パラメータは query(自然言語)、platform(ios/web)、mode(deep/fast)、limit(最大30)
  • 利用例: 「チャット画面のUIをMobbinで10枚集めて、共通パターンを教えて」→ 全体構成・バブルデザイン・入力バーの共通パターンを分析
  • Figma連携: Mobbin MCPで収集した参照スクショをFigma MCPと組み合わせて新規UIを生成・並置
  • 注意点: ①件数上限30件 ②platform指定で結果が変わる ③クエリは具体的に ④スクショの鮮度は収録時点
  • 評価: 競合UIをざっと確認する用途に有効。ただしデザイン分析の出発点として使い、最終判断は人間が行う必要あり
dev-classmethod-jp-articles-riko-python-confusion-break-continue

文系出身がPythonで混同したbreakとcontinueの違い

dev-classmethod-jp-articles-ssms-offline-install-private-ec2

閉域EC2にSSMS 22をオフラインインストールしてみた

  • URL: https://dev.classmethod.jp/articles/ssms-offline-install-private-ec2/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: インターネット非接続のプライベートサブネットEC2にSSMS 22をオフラインインストールする手順。S3 Gateway VPCエンドポイント経由でレイアウト(オフラインパッケージ)を転送。証明書不足によるエラーの回避策も解説。

詳細

  • 構成: インターネット接続可能な一時EC2でSSMSレイアウトを作成→S3にアップロード→S3 Gateway VPCエンドポイント経由でオフラインEC2にダウンロード→インストール
  • 必要なVPCエンドポイント: S3 Gateway VPCエンドポイント(パッケージ転送)、SSM VPCエンドポイント(Fleet Manager接続用)
  • 事前準備(重要):
    1. Microsoft Windows Code Signing PCA 2024 証明書を S3 にアップロード
    2. Visual C++ 再頒布可能パッケージ(x86/x64)のオフライン格納
  • レイアウト作成: 一時EC2(Windows Server 2025、NATゲートウェイ経由でインターネット接続)でSSMSブートストラップをダウンロードし --layout オプションでオフラインパッケージを生成してS3にアップロード
  • インストール時の注意: 証明書不備があるとエラーで止まる。公式ドキュメント通りに事前に証明書をインストールしておくことが重要(著者が実際に証明書エラーに遭遇した経験談)
  • 評価: AWS FSx等の閉域環境でのSQL Serverデバッグ・管理ツールが必要な場面での実践的な手順書
dev-classmethod-jp-articles-twilio-for-claude-with-claude-code

Twilio for Claude (MCP + Skills) を Claude Code で触ってみた

  • URL: https://dev.classmethod.jp/articles/twilio-for-claude-with-claude-code/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: Twilio が 2026年5月に発表した「Twilio for Claude」(MCP サーバー + Agent Skills)を Claude Code に接続し、Video API でのブラウザ通話実装を試みた実録。Skills のカバレッジ限界と MCP による補完の実態を詳述。

詳細

  • Twilio for Claude 構成: MCP サーバー(1800以上のAPI仕様を検索)と Skills(製品別ベストプラクティス手順書)の2層
  • Skills の実態: 55個のスキルがあるが Video API 専用スキルは存在しない。SMS/Voice/WhatsApp/Verify/SendGrid/Compliance には手厚い
  • MCP による補完: Skills が届かない領域は MCP の twilio__search が補完。Group Room 作成・Access Token 発行のドキュメントを検索して実装を進めた
  • 技術的障壁: twilio-run@5.0.1 が Node v24 非対応(^20.x || ^22.x 要求)で Twilio Serverless Toolkit が使えず、AIが Vercel Serverless Functions に切り替えを判断
  • バックエンド: Vercel Functions の /api/join-room.js で JWT 形式 Access Token を発行。Twilio Video SDK の Group Room 作成 + participantConnected イベントで1対1通話を実現
  • 評価: MCP のサンプルコードは品質が高く初回で動作した。Skills は推奨手順の出発点として機能するが細かい環境依存には対応できない
dev-classmethod-jp-articles-wthatsux9

UXってなんだろう⑨〜きれいなUIは後で。まず鉛筆と紙で画面を描く〜

  • URL: https://dev.classmethod.jp/articles/wthatsux9/
  • 日付: 2026-06-05
  • Tier: Tier 3
  • 要旨: USM(ユーザーストーリーマッピング)の次フェーズであるUI設計で、Figmaより先にペーパープロトタイプを描く理由と実践方法を解説。AIがUIを即生成できる時代に手書きの価値を問い直す。

詳細

  • なぜ紙から始めるか: 構造の問題(ボタン位置・画面の流れ)を解決する前に見た目を作り込むと、やり直しコストが高くつく
  • 手順: 白紙 + 鉛筆で複数バリエーションを素早く描き、指でタップ動作を擬似再現して操作感を検証
  • コツ: 1枚で完成させようとしない。参考UIを模写してから差分をアレンジする
  • AI時代の位置づけ: Claude・V0などのUIジェネレータは「作ること」を速くするが、「それっぽく見える」ため思考が停止しやすい。手書きの過程で生まれる疑問・修正がUX設計の本質的な思考を促す
  • 実体験: 2人で大きな紙に手書きで画面構造を描いたセッションで構造ミスをその場で発見
  • 評価: AI生成UIの補完としてペーパープロトを位置づけるフレームワークが実践的
zenn-dev-atani-articles-cmux-pixel-office

cmux で AI エージェントの待機時間を眺める「Pixel Office」を作った

  • URL: https://zenn.dev/atani/articles/cmux-pixel-office
  • 日付: 2026-06-06
  • Tier: Tier 3
  • 要旨: cmux 向けに VS Code 拡張「Pixel Agents」のコンセプトを Custom sidebars 機能で再実装。各 workspace をリアルタイムで可視化するサイドバーをSwiftUI風DSL 1ファイルで実現。

詳細

  • 背景: VS Code 拡張 Pixel Agents がClaude Codeの待機状況をピクセルアートで表示する機能をcmux向けに移植した
  • 仕組み: cmux のベータ機能 Custom sidebars(~/.config/cmux/sidebars/ に設定ファイルを置く)を利用。SwiftUI風DSLで記述し、hot-reloadで即反映
  • 状態管理: unread(応答待ち)→ latestAtの差分(60秒未満=作業中、15分未満=休憩、それ以上=就寝)で判定
  • データソース: Claude Code の ~/.claude/projects/*.jsonl ではなく cmux の workspace 状態を参照するため、Claude Code 以外のセッションにも対応
  • ハマりどころ: v0.64.13 では Custom sidebars のトグルがSettings UIに露出していないが、defaults write com.cmuxterm.app "customSidebars.beta.enabled" -bool true で有効化可能。著者が issue を起票済み
  • 評価: 生産性ツールではないが、複数エージェント並列実行時の視認性を向上させる小品として完成度が高い