MCPの認証をIdP経由にして「個別OAuth野良化」を止める｜Enterprise-Managed Authorization（EMA / Okta Cross App Access）で作るAIエージェント認可の一元統制 2026/06

• URL: https://blog.cloudnative.co.jp/articles/mcp-enterprise-managed-authorization-xaa-id-jag-2026
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: MCP の認可拡張 Enterprise-Managed Authorization（EMA）の仕様が2026年6月18日に安定版になった。AIエージェントが使う MCP サーバー（コネクタ）へのアクセスを、従業員個人の OAuth 同意ではなく組織の IdP で一元的に認可・失効できるようにする MCP 公式拡張で、技術基盤は IETF OAuth WG で標準化中のドラフト ID-JAG（Identity Assertion JWT Authorization Grant）。Okta の実装ブランド名が Cross App Access（XAA）にあたる。同日 Anthropic が Claude 向けに Okta を最初の対応 IdP とするベータ提供を開始した（Claude Team／Enterprise プラン向け）。仕様は stable だが各社の実装はベータで、Claude EMA の対応 IdP は現状 Okta のみ、対応クライアントも Claude 系・VS Code に限られ OpenAI/ChatGPT は対象外。EMA の利点は入退社ライフサイクル連動の付与・剥奪、監査証跡の集約、同意画面フィッシング低減、個人アカウント混入の構造的防止。一方で IdP 侵害時のブラストラディウス拡大、接続後の実行時リスク（プロンプトインジェクション等）は EMA では解決しないという限界も明示されている。

詳細

背景と問題設定。従来の MCP 認可は消費者向け発想で、ユーザー個人が対話的同意で接続範囲を決めるモデルだった。企業展開では、全員が全サーバーを個別認可する手間、セキュリティチームが一貫ポリシーを強制できないこと、業務アカウントと個人アカウントの混在という3つの構造的課題がある。これはサービスアカウント・APIキー・OAuth アプリの野良化（NHI＝非人間IDのガバナンス）が AI エージェントで再来したもの。Okta の整理では AI エージェントについて、どこにいるか・何に接続できるか・何ができるか、の3点を制御する必要があり、EMA が直接担うのは「何に接続できるか」。

認可フロー。ユーザーが MCP クライアント（Claude、Claude Code、Cowork、VS Code 等）に通常の SSO でログインし、IdP から ID Token を取得する。クライアントが OAuth Token Exchange で IdP に ID-JAG（署名付き短命の許可証 JWT）を要求し、IdP が管理者設定済みポリシー（どのグループがどのサーバーに到達してよいか）を評価して audience を限定した署名付きアサーションを発行する。クライアントがそれを MCP サーバーの認可サーバーに提示し、SSO の ID Token と同じ署名鍵で検証され、スコープ限定のアクセストークンが発行される。ユーザーにはリダイレクトも同意画面も表示されない。

標準化の経緯。XAA/ID-JAG は2025年9月に OAuth WG に採択され、2025年11月の MCP 仕様（2025-11-25版、SEP-990）に Enterprise-Managed Authorization として組み込まれた。ID-JAG はベンダー中立で、Okta 以外に Athenz（ベータ）・Keycloak（実装中）が実装を進めている。

ローンチ時対応状況。IdP は Okta（Early Access）、クライアントは Claude／Claude Code／Cowork（Anthropic）と VS Code（Microsoft）、サーバーは Asana・Atlassian・Canva・Figma・Granola・Linear・Supabase（Slack は進行中）。導入企業として HubSpot・Ramp・Webflow が挙がり、2,000名規模の従業員に Okta 経由で追加操作ゼロでプロビジョニングした顧客事例が紹介されている。

効果。誰がどの AI でどこにどの権限で接続しているかを IdP がログ化・一元可視化し、止めたいときは IdP 一箇所で失効すれば全体に波及する。SOC 2・HIPAA・GDPR 等の監査で一本の証跡を示せる。XAA 環境では原則同意画面が出ないため、同意画面が出ること自体を異常のサインにできフィッシング耐性が上がる。摩擦のないアクセス確認によりトークン短寿命化も実用化できる。

限界と誤解。EMA は接続時の認可を解決するが、接続後にエージェントが何をするか（プロンプトインジェクションや悪性 MCP サーバーの実行時リスク）は対象外。ユーザーが別の個人コネクタ／MCP を追加すること自体は EMA 単体では止まらず、その強制は配布統制という別レイヤーで行う。IdP が攻撃された場合の影響範囲は拡大する。

導入の実務。XAA は Okta の Early Access 機能で、Admin Console の Settings＞Features＞Early Access でセルフ有効化する。利用条件は要求側アプリと対象アプリが OIN に OIDC 登録され XAA 有効化、両アプリ間に OAuth 関係、両アプリが Okta を IdP として SSO していること。Claude EMA を使うには加えて Claude Team／Enterprise プランと Anthropic の EMA ベータ登録（claude.com/form/ema-waitlist）が別途必要。RBAC とのきめ細かい連携は Anthropic 側で coming soon とされ、当面はグループ／チーム単位のスコープが中心。

自社製 MCP の対応。MCP サーバーの認可サーバーで ID-JAG を検証し（JWKS で署名検証、aud・iss・有効期限確認、sub/email で account linking、scope を権限にマッピング）、認可メタデータで EMA 拡張を宣言する。自前実装が重ければ Stytch・Scalekit・Auth0（ベータ）・Keycloak（実装中）・WorkOS 等の ID-JAG 対応認可サーバーにオフロードできる。Okta 側では OIN に OIDC 登録し XAA Resource App として有効化、xaa.dev や motd.xaa.rocks で発行〜検証フローを試せる。

移行戦略。既存の OAuth 連携・APIキー・サービスアカウントをまず棚卸しし、XAA 対応コネクタは EMA へ寄せる。XAA 非対応の既存 OAuth アプリは Okta の Brokered Consent でブローカし、ポリシー管理と可視性を IdP 側に寄せる。個人利用コネクタは併存させ、全連携を一斉切替せず AI×機微データを扱う主要 SaaS のハイリスク連携から段階適用する。

CloudFront定額プランへの移行時に既存Web ACLを引き継げるか検証してみた

• URL: https://dev.classmethod.jp/articles/2026-06-21-cloudfront-flat-rate-plan-existing-webacl-migration
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: CloudFront 定額料金プラン（2025-11 リリース）への移行時、既存 Web ACL の扱いを検証。結果：(1) 従量課金で既存 Web ACL アタッチ状態で移行 → Web ACL・ルールがそのまま引き継がれる、(2) 非対応機能（Rule Group）を含む Web ACL → プラン選択がブロック・事前解除必要、(3) 定額プラン適用後に既存 Web ACL アタッチ → 不可（エラー）、(4) 移行後 CloudFormation でインポート・ルール追加可能。Web ACL は移行時点で固定されるため、プラン適用前の設定が重要。

詳細

CloudFront 定額料金プラン（Flat-Rate Pricing Plans、2025-11 リリース）への移行時に既存 Web ACL・WAF ルールをどう扱うか検証。公式ドキュメント：「定額プランではWeb ACLの関連付けが必須・リソース削除・切り離し不可（pay-as-you-go に戻した場合のみ可）」。新規定額ディストリビューション作成時は CreatedByCloudFront- 接頭辞の Web ACL が自動付与。既存従量課金ディストリビューション移行時の Web ACL は？検証結果 4 ケース：(1) 従量課金で既存 Web ACL をアタッチ → プラン移行 ：Web ACL・マネージドルール（AWS-AWSManagedRulesCommonRuleSet）がそのまま引き継がれる（AWS-AWSManagedRulesCommonRuleSet は GA 対応）、(2) 非対応機能（Rule Group）を含む Web ACL ：プラン選択画面で Free を含むすべてのプランがグレーアウト・選択不可。移行前に Rule Group を削除・解除が必須、(3) 定額プラン（Free）適用済みディストリビューション ：既存 Web ACL を後からアタッチ不可。エラー「You can’t remove or replace the web ACL for your distribution. Distributions with a pricing plan subscription must have a web ACL resource」。定額プランでプラン専用 Web ACL が自動付与されるため、既存 Web ACL アタッチ不可。(4) 移行後の IaC 管理 ：CloudFormation resource import で既存 Web ACL を stack にインポート・IP Rate Limit ルール追加で stack update 可能。IMPORT_COMPLETE → UPDATE_COMPLETE で反映。クラウドフロントのセキュリティタブでも CloudFormation 経由のルールが表示。結論：定額プラン移行は「移行前の Web ACL 状態」で決まる。移行時に既存 Web ACL が引き継がれるため、後から変更不可。定額プラン検討時は Web ACL 構成を事前に確認・非対応機能削除・移行後の IaC 管理計画が重要。

【Security Hub修復手順】[ECS.21] ECS タスク定義では、Windowsコンテナ定義で管理者以外のユーザーを設定する必要があります

• URL: https://dev.classmethod.jp/articles/2026-06-21-securityhub-fsbp-remediation-ecs-21
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Security Hub コントロール [ECS.21]：Windows コンテナは ContainerAdministrator（デフォルト・root 相当）で動作するのを避け、ContainerUser（制限付きアカウント）で実行。タスク定義の user パラメータが未設定・containeradministrator・0 のいずれかの場合 FAILED。修復値 “user”: “containeruser” を設定。AWS 公式「Windows では user パラメータ非サポート」の記述に反し、実装上は user がコンテナ実行ユーザーコンテキストに反映・ContainerUser として正しく機能することを whoami /all で確認（Mandatory Label Medium・BUILTIN\Administrators なし・管理者特権なし）。JSON エディタで修復。

詳細

AWS Security Hub コントロール [ECS.21] ─ ECS タスク定義で Windows コンテナが管理者以外のユーザーで実行されるか確認。背景：Windows コンテナデフォルトは ContainerAdministrator（root 相当・強権限）で動作。Microsoft 標準は ContainerUser（制限付きアカウント）を推奨。管理者権限コンテナ内脆弱性の攻撃がホスト侵害につながる懸念。評価ロジック：operatingSystemFamily が WINDOWS_SERVER_* のタスク定義のみ評価対象。コンテナ定義の user が以下で FAILED：未設定（デフォルト ContainerAdministrator）・containeradministrator または 0 を明示指定。修復方法：JSON エディタで新リビジョン作成時に “user”: “containeruser” 追加。AWS 公式 ContainerDefinition API Reference では「Windows では user パラメータ非サポート」と明記だが、実装上は user がコンテナ実行ユーザーコンテキストに反映。実機検証（ECS Fargate で whoami /all 実行）で確認可能な evidence：(1) Mandatory Label は Medium Mandatory Level（管理者でなし）・High でなし、(2) 所属グループ BUILTIN\Users あり・BUILTIN\Administrators なし、(3) 特権リスト SeChangeNotifyPrivilege（全ユーザー標準）+ SeIncreaseWorkingSetPrivilege のみ・SeBackupPrivilege / SeDebugPrivilege / SeRestorePrivilege 等管理者特権なし。つまり AWS 公式記述に反し実装上は “user”: “containeruser” がコンテナ実行ユーザーコンテキストに反映・ContainerUser として正しく機能。ECS コンソール JSON エディタで containeruser を設定。コンソール GUI では小文字英数字・アンダースコア・ハイフンのみバリデーション（ContainerUser は大文字バリデーションエラー）なので containeruser（全小文字）で指定。Windows ユーザー名は大文字小文字区別なし。修復確認：タスク定義登録時点で評価・新リビジョン作成で PASSED に切替（サービス更新は稼働タスクのリビジョン切替・Compliance 判定はサービス更新待たず反映・最大 12 時間遅延あり）。

[アップデート] Amazon OpenSearch Serverless NextGen × Amazon Bedrock (Claude) で自然言語を検索 DSL に変換する Agentic Search を試してみた

• URL: https://dev.classmethod.jp/articles/20260621-amazon-opensearch-serverless-agentic-search
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: Amazon OpenSearch Serverless NextGen × Amazon Bedrock（Claude）で自然言語検索。QueryPlanningTool が LLM で自然言語を OpenSearch DSL に変換。ユーザーは日本語で「800 ドル未満のノートパソコンを表示して」と入力すると、システムが意図を解釈して price の range フィルタ・product_name のマッチクエリを自動生成・実行。NextGen は scale-to-zero に対応（OCU 最小 0）。IAM ロール・セキュリティポリシー・ML コネクタ登録・エージェント登録を経て実運用。

詳細

Amazon OpenSearch Serverless NextGen（SEARCH Collection）+ Amazon Bedrock Claude Sonnet 4.6 で Agentic Search 実装。QueryPlanningTool が Bedrock Converse API 呼び出しで自然言語を OpenSearch DSL に変換。2 種類エージェント：conversational 型（多ターン対話）と flow 型（単一問い合わせ）。本記事は flow 型 + QueryPlanningTool 1 つで実装。エージェント背景で Tokyo リージョン NextGen コレクショングループ（最小 OCU 0、最大 2、standby replicas ENABLED）を構築。IAM ロール ml.opensearchservice.amazonaws.com 信頼ポリシー・bedrock:InvokeModel 権限・セキュリティポリシー（暗号化・ネットワーク・データアクセス）設定。ML コネクタに Bedrock Converse API エンドポイント・IAM ロール ARN を登録（model_id 発行）。エージェント登録に agent_id 発行。自然言語クエリ「800 ドル未満のノートパソコンを表示」で price.lt:800・kuromoji テキストマッチを含む DSL 自動生成。数値範囲・真偽値・カテゴリ・ソート条件を正確に DSL へ落とし込み。検索パイプライン + agentic_query_translator + agentic_context レスポンスプロセッサーでエンドツーエンド検索実行。

AI-DLC Workflows v2がプレビューリリースされたのでKiro CLI / Claude Code / Codex CLIにインストールしてみた

• URL: https://dev.classmethod.jp/articles/aidlc-workflows-v2-install-kiro-claude-codex
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AI-DLC Workflows v2（2026-06-18 プレビュー）は v1 ルールファイル方式から TypeScript ネイティブ実装へ全面刷新。v1 との主な差：v2 は決定論的エンジン（aidlc-orchestrate.ts）・状態管理（State v7）・67 イベント構造化 audit trail・自動センサー・LLM Reviewer・学習ループ・32 ステージ・9 スコープ・checkpoint 復帰機構を新搭載。対応ハーネス 4 種（Kiro IDE/Kiro CLI/Claude Code/Codex CLI）に縮小。One core, many harnesses 設計で共通 core と harness 別 dist を分離。Claude Opus 4.8 推奨。

詳細

AI-DLC Workflows v2（2026-06-18 プレビューリリース）─ v1 からの大幅刷新。v1 vs v2：アーキテクチャは core-workflow.md ルールファイルコピー → TypeScript ツール・フック・エージェント・スキルネイティブ実装。対応ハーネス 8 種 → 4 種（Kiro IDE/CLI、Claude Code、Codex CLI）。ルーティングは LLM 判断依存 → 決定論的エンジン（aidlc-orchestrate.ts）+ LLM forwarding loop。状態管理なし → aidlc-state.md (State v7) + 構造化ステージ状態。監査なし → 67 イベント構造化 audit trail。品質検証は人間のみ → Sensor（自動）+ Reviewer（LLM advisory）+ Approval gate（人間）。学習なし → Learning loop（指摘→ルール化→永続化）。並列ビルドなし → Swarm（worktree 分離 + deterministic referee）。エージェント機構なし → 13 エージェント定義。セッション復帰機構なし → checkpoint から resume/redo/jump。公開履歴 0.1.0（2026-04-24）から 2.0.0（2026-06-18）に約 2 ヶ月で到達。アーキテクチャは「One core, many harnesses」：core/ に共通 stage/knowledge/tools/sensors、harness/ にハーネス固有差分・アダプタ hook・設定、scripts/package.ts で dist/ ビルド。対応ハーネス Kiro CLI（≥2.6）・Claude Code（AWS Bedrock 経由）・Codex CLI では dist/ の内容をプロジェクト .kiro/.claude/.codex にコピー。前提：bun PATH・Bedrock モデルアクセス有効化。Claude Opus 4.8 推奨、弱いモデルではオプション段階スキップ・approval gates 省略の可能性。

Amazon SageMaker HyperPod が efa-only ネットワークインターフェイスをサポートしたので試してみた

• URL: https://dev.classmethod.jp/articles/amazon-sagemaker-hyperpod-efa-only
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: Amazon SageMaker HyperPod が efa-only ネットワークインターフェイスをサポート（2026 年 6 月）。セカンダリ ENI が IP アドレスを持たず、IP 枯渇を防止。ENA vs EFA vs efa-only：ENA は IP 割当・プライマリ使用可・ENI 上限カウント。EFA with ENA は IP 割当・プライマリ使用可・上限カウント。efa-only は IP 割当なし・プライマリ不可・上限カウント。ml.p5.48xlarge 100 ノード：efa だと 3,200 IP・efa-only だと 100 IP のみ消費。EFA ファブリック低レイテンシ通信は efa-only でも有効。

詳細

Amazon SageMaker HyperPod efa-only ネットワークインターフェイスサポート（2026-06）。EFA（Elastic Fabric Adapter）は AI/ML・HPC 向け低レイテンシ通信・EC2 インスタンスアタッチ。従来 efa 構成では複数ネットワークカード（ml.p5.48xlarge 32 枚など）ごとに ENI・各々がプライベート IP 割当・大規模クラスタで IP 枯渇問題。efa-only は セカンダリ ENI が IP アドレス非割当・IP コネクティビティ用プライマリ ENI だけが消費。ml.p5.48xlarge 100 ノード比較：従来efa は 32 IP/node × 100 = 3,200 個・efa-only は 1 IP/node × 100 = 100 個のみ消費（97% 削減）。EFA ファブリック低レイテンシ通信は efa-only でも有効・プライベート IP 割当がないだけで通信品質変わらず。前提条件：複数ネットワークカード（ml.g6e.24xlarge・ml.p4d.24xlarge・ml.p5.48xlarge・ml.trn2.48xlarge など）のインスタンスのみ対応。ネットワークカード 1 枚（ml.p5.4xlarge など）は非対応。設定：ClusterNetworkInterface.InterfaceType を インスタンスグループ単位で efa か efa-only から選択。コントローラーは通常 ENA・コンピュート群だけ efa-only 指定。確認方法：aws ec2 describe-network-interfaces で ENI 確認・efa-only セカンダリ ENI は PrivateIpAddress が None。サブネット IP 消費も確認可（ベースラインからプライマリ分の 1 個のみ減少）。大規模クラスター（P5・P5e 系で多数ネットワークカード）構築時に IP 枯渇対策として有効。AWS ParallelCluster でも 2026-03 に同様アップデート。

画像生成AIのアーキテクチャ対決：Autoregressive vs Diffusion — 2026年の勝者は？

• URL: https://dev.classmethod.jp/articles/autoregressive-vs-diffusion-image-generation-2026
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: 画像生成 AI のアーキテクチャ対決：Autoregressive vs Diffusion vs Hybrid DiT。2026 年市場：3 つ巴の競争。Diffusion（ノイズ除去）は並列処理・画像品質高い・テキスト描画苦手。Autoregressive（トークン逐次生成）は指示追従性強い・テキスト描画得意・エラー蓄積問題。Hybrid DiT（Transformer + Diffusion）は速度と品質両立・複雑性高い。OpenAI gpt-image-1.5 は pure AR で Arena 1 位・商業的成功。Diffusion（Stable Diffusion・Midjourney）と Hybrid DiT（Sora・Imagen 3・SD3）が研究最前線。用途別使い分け進む。

詳細

画像生成 AI 業界の大型パラダイムシフト：gpt-image-1（Autoregressive）vs DALL-E 3（Diffusion）の根本的な違い。Diffusion モデル：ランダムノイズ → 反復ノイズ除去（数十～数百ステップ）→ 画像全体を同時改善。並列性高い・グローバル整合性強い・テキスト描画苦手（歴史的）・指示追従性弱い。Autoregressive モデル：LLM テキスト生成と同じ原理・トークン逐次生成。画像をトークン化（Visual Tokenizer・VQ-VAE）→ 離散トークンに変換（256×256 画像 ≈ 1024 トークン）→ Transformer/Attention で 1 つずつ逐次生成→ デコーダーでピクセル復元。テキスト描画得意・指示追従性強い（テキスト理解と同じ空間）・エラー蓄積が本質的弱点（3D プリンター比喩：層を 1 層ずつ積上げ・後戻り不可・エラー波及）。直感理解：Diffusion = 彫刻家（ノミで削り出し・全体見て改善・やり直し可）、Autoregressive = 3D プリンター（層積上げ・後戻り不可・エラー蓄積）。OpenAI の AR 採択理由：統一アーキテクチャ（テキスト・画像同じモデル・スケーリングシンプル）・指示追従性優先・大規模学習でエラー蓄積緩和可能。2026 年市場（三国志状態）：(1) 純粋 AR（OpenAI）── gpt-image-1 初週 7 億枚以上、1.3 億ユーザー。gpt-image-1.5（2025-12）Arena text-to-image リーダボード 1 位（ELO 1264・2 位に 29pp 差）。gpt-image-2（2026-04）Reasoning モデル導入。多数スタートアップが Diffusion から OpenAI API に移行。(2) 純粋 Diffusion（オープンソース）── Flux・Stable Diffusion 3 活発。アーティストコミュニティが微細な審美的制御で支持。LoRA エコシステム成熟。(3) Hybrid DiT（学術・新興）── DiT アーキテクチャ採用（SD3・Flux・Sora・Imagen 3）。MIT 研究：AR で粗構造 + 小さい Diffusion で細部 → 9 倍速度向上・品質同等。Transformer 大域理解 + Diffusion 画像品質両立。一強でなく用途別使い分け進行（プロダクト/UX 重視 → AR、オープンソース/アート → Diffusion、研究/最適化 → Hybrid DiT）。

[アップデート] AWS Compute Optimizer が EBS の VolumeIOPSExceededCheck / VolumeThroughputExceededCheck メトリクスを分析対象に追加し、より正確なボリューム推奨を出せるようになりました

• URL: https://dev.classmethod.jp/articles/aws-compute-optimizer-enhances-ebs-recommendations
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Compute Optimizer が EBS ボリューム推奨に VolumeIOPSExceededCheck・VolumeThroughputExceededCheck メトリクスを分析対象に追加。従来は 5 分間隔 CloudWatch メトリクス最大使用率ベース・短時間バーストでプロビジョンド性能の天井に張り付いても検知できず。新メトリクスで 1 分粒度ボトルネック検知・バースト発生ワークロードの精度向上。例：IOPS exceeded check で gp3 の 3,000 IOPS 天井繰り返し到達・Throughput exceeded check で 125 MiB/s 天井毎日到達が適切に推奨に反映。対象：Nitro ベース EC2 インスタンスアタッチボリューム。マグネティック・マルチアタッチは非対応。

詳細

AWS Compute Optimizer が EBS ボリューム推奨ロジック更新。対象：CloudWatch メトリクス分析からライトサイジング推奨出力。従来は 5 分間隔メトリクス（VolumeReadOps・VolumeWriteOps・VolumeReadBytes・VolumeWriteBytes）の最大使用率ベース。2024-10 に VolumeIOPSExceededCheck・VolumeThroughputExceededCheck メトリクス追加されたが分析対象外・短時間ピークで性能天井張り付きケース検知不可・下げ余地のない IOPS/Throughput を「下げても OK」と誤推奨する可能性。新アップデートで両メトリクスを分析対象に含める。バースト発生ワークロードの精度向上。新メトリクス：IOPS exceeded check（1 分粒度で IOPS 天井到達カウント）・Throughput exceeded check（1 分粒度で Throughput 天井到達カウント）。コンソール「現在のリソース使用率」セクションでグラフ表示。特にパフォーマンス問題のないボリュームは ExceededCheck = 0・推奨なし（Optimized）。IOPS ボトルネック例：IOPS exceeded check 1 に繰り返し張り付き・読取 gp3 ベースライン 3,000 IOPS 天井到達・Compute Optimizer が IOPS 引上推奨。Throughput ボトルネック例：Throughput exceeded check 毎日 1 到達・読み込み・書き込み帯域幅 125 MiB/s 天井繰り返し・スループット引上推奨。従来 5 分平均では埋もれる瞬間的超過も適切に検知・推奨反映（特に短時間瞬間的バーストワークロードで有効）。対象：Nitro ベース EC2 インスタンスアタッチボリューム。マグネティック・マルチアタッチ有効ボリューム非対応。推奨信頼性向上・1 分粒度ボトルネック検知により従来「ExceededCheck 出ているのに誤ってダウンサイズ」課題を解消。

AWS Deadline Cloud: After Effects プラグインを conda 配信したら Worker でだけ機能しなかった話

• URL: https://dev.classmethod.jp/articles/aws-deadline-cloud-after-effects-plugin-conda-adobe-common
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Deadline Cloud レンダーファーム構築時、After Effects プラグインを conda で Worker に配信すると、ローカルでは動作する が Worker でだけ機能しない問題。原因は一部プラグインが AE 専用フォルダでなく Adobe 共通フォルダ（Adobe\Common\Plug-ins\）にインストールされること。conda 配信では AE Support Files（専用フォルダ）のみを zip 化するため、Adobe Common フォルダのプラグインが Worker に届かない。対処は zip 前に robocopy で Adobe Common からプラグインを AE 専用フォルダへミラーコピー。

詳細

AWS Deadline Cloud CMF（Customer-Managed Fleet）で After Effects レンダーファーム構築・プラグイン conda 配信時の問題。AE プラグインインストール先は 2 系統：(1) AE 専用の Support Files 配下、(2) Adobe 全製品共通の Adobe\Common\Plug-ins\。一部サードパーティプラグインは (2) に配置。ローカル AE は両フォルダを自動探索し機能するが、conda 配信では (1) のみ zip 化。Worker 展開時 (2) フォルダが含まれず、「ローカルでは動作・Worker でだけ未適用」という症状に。誤認しやすいポイントは「インストール先を見て実体がないから失敗」と判定してしまうこと。実際はインストール成功で別フォルダに配置されているだけ。対処：zip 化前に robocopy で Adobe\Common\Plug-ins\ から AE Support Files\Plug-ins\ へミラーコピー。プラグインインストーラーがインストール先パス指定可能ならそもそもインストール時に AE 専用フォルダに直接配置させる方が最初から不要。

閉域 VPC の AWS Deadline Cloud CMF Worker では STS の VPC エンドポイントが要る話

• URL: https://dev.classmethod.jp/articles/aws-deadline-cloud-cmf-private-vpc-sts-endpoint
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Deadline Cloud CMF を閉域 VPC（インターネット出口なし）で運用時、Worker Agent 本体は IDLE だがジョブ実行でエラー「STS endpoint timeout」。Worker Agent 本体は STS を呼ばず（deadline の AssumeFleetRoleForWorker で credential 取得）だが、job attachments の入力同期時に S3 GetObject の ExpectedBucketOwner 用アカウント ID を要求・credential に AccountId フィールドがないため botocore がフォールバックで sts.get_caller_identity() 呼び出し。閉域 VPC に STS エンドポイントがないためタイムアウト。対処は STS インターフェイス VPC エンドポイント（com.amazonaws.region.sts）を VPC に追加。

詳細

AWS Deadline Cloud CMF を閉域 VPC（インターネットゲートウェイ・NAT なし、AWS API はインターフェイス VPC エンドポイント PrivateLink 経由のみ）で運用時の問題。症状：Worker Agent は Fleet に IDLE で追加される（正常に見える）が、ジョブ実行時に入力ファイル同期で「Connect timeout on endpoint URL: https://sts.ap-northeast-1.amazonaws.com/」でタスク FAILED。原因の多層構造：(1) Worker Agent 本体は STS を呼ばない設計 ─ 起動時に deadline API AssumeFleetRoleForWorker で fleet worker role の一時 credential を deadline エンドポイント経由で受け取る。sts:AssumeRole を直接呼ばず、STS エンドポイント不要。ログは「[deadline:AssumeFleetRoleForWorker] (200) accessKeyId=ASIA…」。(2) job attachments（シーンファイル等入力を S3 経由で Worker 同期）は別経路で STS 呼び出し ─ S3 GetObject 時に ExpectedBucketOwner ヘッダのため AWS アカウント ID 必要。Worker Agent credential ファイルは Version/AccessKeyId/SecretAccessKey/SessionToken/Expiration 5 フィールドで AccountId を含まない。プロファイル設定にも aws_account_id がない。botocore がアカウント ID を None と判定し最終手段で sts.get_caller_identity() を呼び出し。連鎖フロー：job attachments が S3 GetObject の ExpectedBucketOwner 用にアカウント ID 要求 → credential/profile に AccountId なし → botocore が None 判定 → sts.get_caller_identity() フォールバック → 閉域 VPC に STS エンドポイントなし → TCP 接続タイムアウト → job attachments 例外捕捉し入力ダウンロード失敗 → タスク FAILED。対処：STS インターフェイス VPC エンドポイント（com.amazonaws..sts）を VPC 追加。これでフォールバック get_caller_identity() が VPC 内で解決。月額数ドル程度で最も素直。代替案：job attachments 経由でなく AMI 焼き込み・S3 直接ダウンロードで syncInputJobAttachments 自体をスキップ・プロファイルに aws_account_id 記載（ライブラリ挙動に踏み込むため非推奨）。

Windows の AWS Deadline Cloud Worker でジョブが同じエラーで 3 回拒否された話

• URL: https://dev.classmethod.jp/articles/aws-deadline-cloud-windows-worker-agent-user
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Deadline Cloud CMF の Windows Worker で WORKER_AGENT_USER モード（ジョブを Worker Agent と同じ OS ユーザーで実行）を使用時、同じエラーが 3 回異なる原因で発生。(1) deadline-worker が Administrators グループに自動加入・除外必要、(2) SeAssignPrimaryTokenPrivilege 特権が自動付与・特権削除後は再取得必須、(3) scheduler.py のハードコード判定で Windows は WORKER_AGENT_USER モードを既定拒否・worker.toml で run_jobs_as_agent_user = true でオプトイン。エラー文言を額面どおりに読まずソースコード確認が有効。

詳細

AWS Deadline Cloud CMF の Windows Worker で WORKER_AGENT_USER モード（ジョブを Worker Agent サービスと同じ OS ユーザーで実行・ジョブ実行専用ユーザー不要）を使用時に「Job cannot run as WORKER_AGENT_USER. Worker Agent is running with Administrator privileges.」エラーが 3 回異なる原因で発生。各対処と背景：(1) deadline-worker が Administrators グループに自動加入 ─ install-deadline-worker が Windows deadline-worker 非対話ユーザーを Administrators に加入させるが、Deadline Cloud は Administrators メンバーを WORKER_AGENT_USER 対象から除外。対処は Remove-LocalGroupMember で除外・サービス再起動。(2) SeAssignPrimaryTokenPrivilege が自動付与 ─ グループ除外後も再発。secedit /export で User Rights Assignment を確認すると deadline-worker に特権が付与。Deadline Cloud のチェックは Administrators 所属だけでなく特権保持者も Administrator 相当と判定。特権を一度除外してチェックを進める（但し run_jobs_as_agent_user=true では子プロセス起動に必須なので最終的に再付与）。(3) scheduler.py のハードコード判定 ─ 特権を外しても再発。Worker Agent ソース確認すると os.name==“nt”（Windows 判定）だけで WORKER_AGENT_USER を既定拒否。実行時の権限は一切見ていない仕様。正しい対処は worker.toml で run_jobs_as_agent_user=true を明示的にオプトイン。最終状態：deadline-worker Administrators 除外・SeAssignPrimaryTokenPrivilege 維持・run_jobs_as_agent_user=true で初めてモードが動作。エラー文言を信じ込まず源泉確認が重要。

AWSのPhysical AI Scaffolding Kit (PASK)を試す② — HyperPodでNVIDIA Isaac GR00Tをファインチューニング

• URL: https://dev.classmethod.jp/articles/aws-pask-hyperpod-nvidia-isaac-gr00t-finetuning
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Physical AI Scaffolding Kit（PASK）で Amazon SageMaker HyperPod 上に NVIDIA Isaac GR00T（Vision-Language-Action VLA モデル）をファインチューニング。GR00T-N1.6-3B を cube_to_bowl タスクで学習。3 つのポイント：(1) GPU は「単一 L40S 48GB」選択（40GB+ VRAM 推奨・24GB は OOM）、(2) Isaac-GR00T checkout を n1.6-release に（mainはN1.7・モデルアーキテクチャ不一致エラー回避）、(3) OUTPUT_DIR の書き込み権限設定。Slurm + Enroot + Pyxis で Docker → SquashFS → GPU Node で実行・FSx 共有ストレージ・チェックポイント S3 自動同期。

詳細

AWS Physical AI Scaffolding Kit（PASK）で Amazon SageMaker HyperPod Slurm クラスタ上に NVIDIA Isaac GR00T-N1.6-3B（Vision-Language-Action VLA モデル・カメラ画像+言語指示→ロボット動作）をファインチューニング。学習タスク cube_to_bowl のデモデータ使用。事前の 3 つのポイント抑止がつまり防止に効果的：(1) GPU VRAM 要件「40GB+ 推奨・H100 or L40 nodes」 → 手頃なのは L40S 48GB（ml.g6e.4xlarge）。24GB（A10G/L4）だと optimizer state が載らず OOM。g6（L4 24GB）と g6e（L40S 48GB）は別物・e 付きを選択、(2) Isaac-GR00T git clone デフォルトは mainブランチ（N1.7 コード）だが sample 既定モデルは N1.6。そのままだと「model type Gr00tN1d6 not recognized」エラー。clone 後に git checkout n1.6-release で align、(3) OUTPUT_DIR 既定は /fsx/s3link/so100（S3 リンク領域）・ubuntu が書けるよう sudo chmod -R a+w /fsx/s3link。処理フロー 4 フェーズ：Phase 0（GPU Worker 追加・cdk.json g6e.4xlarge 指定・cdk deploy）→ Phase 1（Login Node 準備・git clone + Git LFS + git checkout n1.6-release）→ Phase 2（Docker ビルド ECR プッシュ・sbatch slurm_build_docker.sh・pytorch3d/flash-attn ソースビルド 30m-1h）→ Phase 3（Enroot インポート・.sqsh に変換・tmux で foreground 実行）→ Phase 4（学習・sbatch slurm_finetune_container.sh・loss 表示で学習確認・step 2000/2000 で完了・checkpoint-2000/に model-*.safetensors 保存）。なぜ Enroot/Pyxis か：通常 Docker は root 必須で HPC 共有環境に不適・Enroot（rootless）で .sqsh（SquashFS）に変換・Pyxis（Slurm plugin）経由で srun –container-image=… で compute node 実行。.sqsh・データ・ログ全ノード共有 FSx に配置で全ノードから同一参照。チェックポイント S3 リンク領域は cdk destroy 後も RETAIN で S3 データバケット保持・学習（高 VRAM GPU 必須）と評価（Isaac Sim 環境）を S3 介して別構成・別タイミングで可能（PASK 設計の良い点）。

Amazon Bedrock Managed Knowledge Base を触ってみた

• URL: https://dev.classmethod.jp/articles/bedrock-managed-knowledge-base-retrieve-agentic-retrieval
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: Amazon Bedrock Managed Knowledge Base（2026 年 6 月 17 日リリース）は完全マネージド RAG。ベクトルストア構築・パイプライン管理不要。Self-managed との差：Managed はベクトルストア AWS 管理・マネージド埋め込みモデル（無料）・マネージドリランカー（無料）・Agentic Retrieval 対応・AgentCore Gateway ネイティブ連携。検索 API：Retrieve（シンプルベクトル検索）・AgenticRetrieveStream（LLM で query 分解・複数回検索・回答生成・複数 KB 横断検索）。料金：インデックスストレージ $5/GB/月・パース/埋め込み/リランキング無料・Retrieve $1/1000 コール・Agentic $4/1000。

詳細

Amazon Bedrock Managed Knowledge Base（2026-06-17 リリース） ─ 完全マネージド RAG。従来の Self-managed vs Managed 比較：Managed はベクトルストア AWS 完全管理（構築・運用不要）・埋め込みモデルは AWS 管理（無料）or Bedrock モデル選択・リランキングはマネージドリランカー内蔵（無料）・Agentic Retrieval 対応・AgentCore Gateway ネイティブ連携。Self-managed は OpenSearch Serverless/Aurora/S3 Vectors 等ユーザー管理・埋め込みモデルユーザー指定・リランキング別途設定・Agentic Retrieval 非対応・AgentCore Gateway 非対応。埋め込みモデル選択肢：Managed embeddings（推奨・AWS 管理・追加コスト無し・チャンキング自動最適化）・Bedrock embeddings（Nova/Titan/Cohere等・追加料金・チャンキング戦略カスタマイズ可）。マネージドパーサー（Smart Parsing）：.txt/.md/.csv/.html/.pdf/.pptx/.docx 自動判別・テーブル構造維持・埋め込み画像解釈・無料。検索 API：Retrieve（ベクトル検索・マネージドリランカー有無切替可）・AgenticRetrieveStream（LLM query 分解・複数回検索・回答生成・複数 KB 横断検索）。料金体系：インデックスストレージ $5/GB/月・マルチモーダルパース無料・埋め込み生成（マネージドモデル）無料・リランキング無料・Retrieve $1/1000 API コール・Agentic $4/1000 Agentic コール + $1/1000 Retrieve コール。10GB/月 10,000 検索で約 $60/月 vs Self-managed OpenSearch 約 $300+/月なので小中規模はコスト効率が良い。メタデータフィルタ：S3 .metadata.json sidecar で category/year/language 等付与・retrieve 時 equals/in/greaterThan/lessThan/notEquals/notIn で絞り込み（startsWith/stringContains Managed では非対応）。Smart Parsing の検証：HTML テーブル正確抽出・CSV カンマ区切り維持・Markdown テーブル構造維持・PDF 図のテキスト要素抽出+説明文自動生成・PPTX スライド+埋め込み画像解釈・DOCX テーブル構造維持。大規模ドキュメント（164 ページ PDF）でも問題なくインデックス・検索できる。GetDocumentContent API でソースドキュメント・パース済みテキストを presigned URL で取得可。

BigQuery の AI 関数を自分なりに整理してみた

• URL: https://dev.classmethod.jp/articles/bigquery-ai-functions-overview
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: BigQuery の AI 関数は SQL から Gemini・埋め込みモデルを直接呼び出せるマネージド関数。2026 年に AI.GENERATE・AI.CLASSIFY・AI.SIMILARITY・AI.FORECAST が GA。4 カテゴリに分類：生成・抽出（構造化データ生成）、判定・分類・スコア（WHERE/GROUP BY 連携）、埋め込み・類似（セマンティック検索）、集計・分析・予測（モデル作成不要の予測・異常検知）。CREATE MODEL が不要で SQL 実行のみで利用可。

詳細

BigQuery AI 関数は Gemini・埋め込みモデルを SQL から呼び出すマネージド関数。従来の ML.GENERATE_TEXT は CREATE MODEL による事前準備が必須だったが、AI.* 関数は不要で SQL 記述のみで実行可能。現在 GA 関数：AI.GENERATE（自由形式テキスト・構造化データ生成）、AI.CLASSIFY（カテゴリ分類・94.2% 精度実績）、AI.SIMILARITY（コサイン類似度・セマンティック検索）、AI.FORECAST（時系列予測・信頼区間付き）、AI.DETECT_ANOMALIES（異常検知）、AI.EVALUATE（精度評価）。Preview：AI.GENERATE_BOOL・AI.GENERATE_INT・AI.GENERATE_DOUBLE・AI.AGG・AI.KEY_DRIVERS・AI.COUNT_TOKENS。ユーティリティ関数で GROUP BY・WHERE・ORDER BY と直結。複数処理を output_schema で一度に構造化取得可能。モデル選択肢：生成用 Gemini と別の text-embedding-005（埋め込み専用）。

ClipboardItem + Blobでリッチテキストをコピーする実装と、HTTP環境の罠

• URL: https://dev.classmethod.jp/articles/clipboard-blob-rich-text-http-fallback
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: React/Next.js で Markdown を Outlook に書式付きでコピーする実装。ClipboardItem + Blob で text/html と text/plain を同時に clipboard に書込。Markdown → HTML（react-markdown）→ innerText でクリーンテキスト抽出。navigator.clipboard API は Secure Context（https/localhost/127.0.0.1）のみ。HTTP（http://10.x.x.x/）では undefined になりサイレント失敗。対処：window.isSecureContext で分岐・HTTP 環境では document.execCommand(“copy”) フォールバック（プレーンテキストのみ）。localhost で動いても本番 HTTP IP で動かない陥穽を実装で回避。

詳細

React 19/Next.js 15 で LLM 生成 Markdown を Outlook に書式付き・メモ帳にプレーンテキストでコピーする実装。navigator.clipboard.writeText() はプレーンテキスト専用・複数 MIME type 対応に ClipboardItem + Blob が必須。クリップボードは MIME type キー付きバイナリデータの集合：text/plain（書式なし）・text/html（HTML タグ付きリッチテキスト）。貼り付け先で対応 MIME type を選択（Outlook は text/html 優先・メモ帳は text/plain）。実装フロー 3 step：Step 1 Markdown → HTML（react-markdown + renderToStaticMarkup）、Step 2 HTML からクリーンテキスト抽出（tempDiv.innerText でレイアウトベースで抽出・Markdown 記号自動除去）、Step 3 ClipboardItem で write（text/plain + text/html Blob）。開発時の陥穽：localhost は HTTP でも Secure Context 特例・http://localhost:3000 では navigator.clipboard 正常動作。本番 HTTP IP（http://10.x.x.x/）では navigator.clipboard undefined でサイレント失敗・エラー内容不表示・ボタン反応なし。原因：navigator.clipboard API は Secure Context（https / localhost / 127.0.0.1）のみ利用可・HTTP IP アクセスは非 Secure Context で undefined。window.isSecureContext boolean で分岐対応：(1) true（HTTPS/localhost）→ ClipboardItem + Blob（text/html + text/plain）→ ClipboardItem 未対応ブラウザ時は writeText fallback、(2) false（HTTP IP）→ document.execCommand(“copy”) fallback（プレーンテキストのみ・text/html コピー不可）。execCommand(“copy”)は非推奨だが全主要ブラウザ対応・非 Secure Context での唯一の手段。textarea を使（input では改行選択失敗）・position:fixed;opacity:0 で非表示（display:none だと select() 失敗）・focus() → select() → execCommand(“copy”) 順実行・コピー後即 DOM 削除。フォールバック判定フロー：HTTPS/localhost（ClipboardItem+Blob+HTML 書式対応）→ HTTPS かつ ClipboardItem 未対応（writeText fallback・プレーンテキスト）→ HTTP IP（execCommand fallback・プレーンテキスト）。HTTP 環境は text/html コピー不可・書式付き必須ならHTTPS 化必須。開発時は LAN IP（http://192.168.x.x:3000）でアクセスして非 Secure Context 検証推奨。

NVIDIA LLM Router を自分のペルソナに合わせて再訓練してみた（訓練編）

• URL: https://dev.classmethod.jp/articles/dgx-spark-nvidia-llm-router-v3-training
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: NVIDIA LLM Router v3 を自分用に再訓練。default 9-model pool（Nemotron/GPT-OSS/Qwen/GPT-5/Opus）が自分のペルソナと合致しないため、最新 Opus 4.8/Sonnet 4.6/Gemini 3.5 Flash と DeepSeek V4/Qwen 3.7/Kimi K2.6/GLM 4.7 を 9-model ラダーに組み直し。隣接倍率を最大 2.73x に制御（旧 5-model の 14 倍ジャンプ回避）。480 問訓練データ（個人ペルソナ 100+Opus 優位 150+Gemini 優位 30+軽量 100+公開データ 100）でゼロから checkpoint 作成。結果 Opus 43.1% 採用率で品質維持、軽中量質問は tolerance 0.05-0.20 で 98-99% コスト削減。

詳細

NVIDIA LLM Router v3 を 480 問の訓練データでペルソナ最適化。default pool の Nemotron/gpt-oss/Qwen/GPT-5/Opus では「自分の好みからズレている」（Opus 4.8/Sonnet 4.6/Gemini 3.5 Flash が未含有、新興系ラインナップが噛み合わない）を解決。新 9-model ラダー設計：Slot 1-9 で Nemotron Nano(Local) - DeepSeek V4-Flash - GLM 4.7-Flash - DeepSeek V4-Pro - Qwen 3.7-Plus - Kimi K2.6 - Gemini 3.5-Flash - Sonnet 4.6 - Opus 4.8。隣接倍率 1.47x-2.73x に制限（旧 5-model の gpt-oss $0.05 vs Kimi $0.74 の 14 倍跳躍を回避）。訓練データ構成：(1) 個人ペルソナ 100（既有 40+新規重量 60）、(2) Opus 優位質問 150（哲学・長文整合・多段 reasoning・リファクタリング・創作・制約付き判断 15-30 問ずつ）、(3) Gemini 優位 30（テキスト系のみ：grounding・図解・構造化）、(4) 軽量・中量 100、(5) 公開データセット 100（MMLU/HumanEval/GSM8K/DollyJA）。Step 1-5 パイプライン実行：probe → dry-run（90 calls、thinking off 最適化で $11.27）→ judge=vote バグ回避→ judge=llm に切替（Sonnet 4.6 judge・7h15m 再 collect）→ train（5 分・全モデル AUC 0.85 以上）→ evaluate（Oracle 92.5% vs Router 79.37% vs Opus 単体 69.17%）。評価結果：Opus 43.1% 採用・正解率 64.7%、Sonnet 23.1% 採用・正解率 99.1%、Gemini 12.3% 採用・正解率 98.3%。tolerance 別コスト削減：tol=0.05 で 99.3%（deepseek-v4-flash 一強）、tol=0.20 で 98.3%（軽量帯全活用）。Local Nemotron と GLM は argmax では 0% 採用（精度不足で他モデルに劣る質問集合）だが tolerance 上げで拾える。実装罠：thinking on で max_tokens 全消費・judge=vote insertion order バグ・Gemini mandatory reasoning・コスト崖の経済合理性。

NVIDIA LLM Router で LLM の用途別使い分け環境を構築してみた（基礎編）

• URL: https://dev.classmethod.jp/articles/dgx-spark-nvidia-llm-router-v3
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: NVIDIA LLM Router v3 は prompt を Qwen エンコーダで hidden states に変換し、PCA で次元削減してから MLP で各モデルの P(correct) を推定。tolerance パラメータで「最高品質との差」を許容し、閾値を超えたモデル群から最安を自動選択。default pool は 9-model ラダー（Nemotron Nano から Opus 4.6）で単価差 500 倍。v3 は Reference implementation only として自前 fork・再訓練を前提。OpenRouter proxy 統合で Claude/GPT/Gemini/DeepSeek を混在ルーティング。

詳細

NVIDIA LLM Router v3 ─ 質問内容を見てモデルを自動選択するルータ。OpenRouter Auto/Fusion/Pareto と比較：v3 は encoder + MLP で P(correct) 推定、self-host で再訓練可能、オンプレモデル混在可能。判定フロー：Qwen3.5-0.8B エンコーダで prompt を hidden states へ変換（GPU 100ms/CPU 5s）→ PCA 次元削減 → MLP で pool 内各モデルの正解確率を推定。tolerance パラメータで柔軟性制御：tol=0 は常に最高品質モデル、tol=1.0 は常に最安モデル、default 0.20 はバランス点。threshold = max(P) - tolerance で閾値を引き、超過モデルから最安を選択。default pool：9-model ラダー Slot 1-9 で Nemotron Nano ($0.05) ～ Opus 4.6 ($25.78) の 500 倍単価差。実装：BaseRouter/PrefillRouter/PoolConfig/RoutingResult + collect/train/evaluate CLI + LiteLLM Strategy/Standalone Server/Sidecar 6 adapters。v3 は「Reference implementation only」―本番 fork して再訓練を前提。v1/v2 は maintenance モード。CLI git checkout v3 で起動。OpenRouter API key で Claude/GPT/Gemini/DeepSeek を pool 統合。tolerance 5 段階（0.00～0.20）で routing 分布を比較可能。

Kiro Web のサンドボックスから AWS アカウントのリソースを参照できるように設定してみた

• URL: https://dev.classmethod.jp/articles/kiro-web-sandbox-aws-access
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: Kiro Web（ブラウザコーディング環境）のサンドボックスから AWS リソースにアクセスする方法を検証。MCP サーバー（mcp-proxy-for-aws）+ Secrets の組み合わせが安定。Secrets に AWS_ACCESS_KEY_ID/SECRET を暗号化保存し、MCP サーバー設定で ${key_name} 記法で参照。AWS CLI 環境変数では安定性が低く、エージェントが AWS CLI を認識しないケースがある。MCP 経由ならツール呼び出しが確実で、自動判定で Amplify アプリ一覧取得に成功。

詳細

Kiro Web サンドボックスで AWS リソース参照設定。2 つのアプローチ試行：(1) AWS CLI + 環境変数 ─ アクセス可能だが実装が不安定。エージェントが AWS CLI を認識してくれないケースあり、「AWS CLI を使って」と明示指示が必要。(2) MCP サーバー（mcp-proxy-for-aws v1.6.2）+ Secrets ─ 安定性が高い。Secrets に AWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY を暗号化保存し、MCP サーバー JSON の env セクションで ${AWS_ACCESS_KEY_ID} 記法で参照。自動的にエージェントのツール認識され「Amplify のアプリ一覧を確認して」だけで custom_mcp_aws-mcp_aws___call_aws ツール呼び出し。サンドボックスデフォルト IAM ロール（BigWeaverMdeEnvironmentRole）は権限不足のため、自分の AWS アカウントで ReadOnlyAccess IAM ユーザーを別途作成して認証情報を設定。

Next.js + FastAPI を nginx サブパスで配信するときに踏んだ3つの落とし穴 — trailingSlash・ルーティング分離・MuleSoftのSSEバッファリング

• URL: https://dev.classmethod.jp/articles/nextjs-fastapi-nginx-subpath-routing-pitfalls
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: Next.js + FastAPI をサブパス配信時の 3 つのルーティング落とし穴。(1) basePath だけで 404 → trailingSlash 設定必須、(2) フロントエンド・バックエンド分離 → nginx で proxy_pass パスベースルーティング、(3) API Gateway が SSE バッファリング → MuleSoft 経由でストリーミング停止。nginx proxy_pass の末尾「/」で location プレフィックス除去。X-Forwarded-* ヘッダー・Upgrade ヘッダー・proxy_buffering off で WebSocket/SSE 対応。

詳細

Next.js 16（App Router）+ FastAPI 0.115+ を Docker Compose + nginx v1.24 でサブパス配信時の 3 つのルーティング落とし穴。前提：localhost:40001（Next.js）・localhost:40002（FastAPI）を http://host/your-app/ に統合。nginx リバースプロキシ役割：複数アプリ共存・パスベースルーティング・SSL 終端・負荷分散。(1) basePath="/your-app" だけでは 404 → nginx の location /your-app/ で proxy_pass http://localhost:40001/ の末尾「/」が重要。location プレフィックス（/your-app/）が除去されて転送。trailingSlash 設定で slash 統一必須。proxy_http_version 1.1・Upgrade・Connection ヘッダー設定で WebSocket/HMR 対応。(2) フロントエンド・バックエンド分離 → nginx で振り分け。location /your-app/ → Next.js、location /your-app/api/ → FastAPI。X-Forwarded-* ヘッダー転送で リダイレクト/ログ/認証が正常動作。(3) API Gateway が SSE バッファリング → MuleSoft Anypoint Platform 経由時ストリーミング停止。proxy_buffering off・proxy_read_timeout 120s・client_max_body_size 20m で設定。X-Real-IP（直近クライアント IP）・X-Forwarded-For（プロキシチェーン IP）・X-Forwarded-Proto（http/https）でクライアント情報正確に伝播。nginx 構成 40+ アプリを 1 ドメイン・IP で運用時に location ブロック複数で パスベース振り分け必須。Next.js 単体（専用ドメイン 1 アプリ）なら nginx 不要・next start で十分。複数アプリ共存・SSL 一元管理・既存 nginx インフラ統合時に nginx 必須。

GitHub Copilot SDK が GA！TypeScript で カスタムツールを動かして料金体系も調べてみた

• URL: https://dev.classmethod.jp/articles/shoma-github-copilot-sdk-ga-typescript-hello-world-to-custom-tools-pricing
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: GitHub Copilot SDK が 2026 年 6 月 2 日に GA。Copilot CLI（Agent ランタイム）を JSON-RPC で直接呼び出せるライブラリ。6 言語対応（Node.js/Python/.NET/Go/Java/Rust）、Node.js/Python/.NET は CLI 自動バンドル。Custom tools/MCP/System Prompt カスタマイズ・OpenTelemetry・BYOK 認証・Cloud/Remote Sessions・Hook system に対応。オーケストレーション層を自前で書かなくて済む。Copilot Free でも利用可（AI Credits 消費・$0.01 USD）。Copilot CLI と完全地続き（Agent・Skills・MCP の資産流用）。

詳細

GitHub Copilot SDK GA（2026-06-02） ─ Copilot CLI のエージェント ランタイムをコードから直接呼び出すライブラリ。アーキテクチャ：SDK は Copilot CLI をサーバーモードで起動し JSON-RPC で通信。copilot コマンドの実行を TypeScript/Python から利用可。対応言語 6 種：Node.js/TypeScript（npm install @github/copilot-sdk・CLI 自動バンドル）・Python（pip install・自動）・.NET（dotnet add・自動）・Go（go get・手動）・Java（Maven/Gradle・手動）・Rust（cargo add・手動/app-level bundle）。GA 機能：Custom tools and MCP（エージェントが自律呼び出し・MCP サーバー接続・組み込みツール上書き）・Fine-grained system prompt カスタマイズ（identity/tone/tool instructions/safety rules セクション単位）・OpenTelemetry tracing（W3C trace context 伝播）・柔軟認証（OAuth/GitHub Apps/環境トークン/BYOK）・Cloud/Remote Sessions・Hook system（pre/post tool use・session start・MCP tool calls・permission requests）。利点：(1) セッション管理・ツール呼び出し・ストリーミング・ファイル編集・マルチターン履歴を本番運用 Copilot ランタイムで一体提供、(2) Copilot Free + BYOK で逃げ道あり、(3) CLI *.instructions.md・SKILL.md・MCP定義の資産がそのまま活きる。使用例：Stream 対応で token-by-token 表示・defineTool で GitHub PR リスト取得・LLM が自動判定・handler で実装。

TypeScript プロジェクトに ESLint・Prettier・cspell を 1 つずつ入れて挙動を確かめてみた

• URL: https://dev.classmethod.jp/articles/shoma-setup-eslint-prettier-cspell-one-by-one-in-typescript-project
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: TypeScript プロジェクトで ESLint・Prettier・cspell を 1 つずつインストール・動作確認。Linter 棲み分け：ESLint（コード品質）・Prettier（見た目整形）・cspell（スペルチェック）・TypeScript Compiler（型検証）・Test Runner（動作検証）。ESLint v9 は Flat Config 標準・js.configs.recommended + tseslint.configs.recommended をベース・カスタムルール追加・files で対象ファイル絞込・ignores で除外。scripts に check:lint・fix:lint・check:type 登録。

詳細

TypeScript プロジェクトで ESLint・Prettier・cspell を 1 つずつインストール・動作確認。Linter 系ツール棲み分け：(1) ESLint ─ コードの「品質」「規約違反」検出（no-var、@typescript-eslint/no-explicit-any など）、(2) Prettier ─ コードの「見た目」自動整形（インデント・括弧配置など）、(3) cspell ─ スペルミス検出、(4) TypeScript Compiler ─ 型の整合性検証、(5) Test Runner ─ 実行して挙動検証。環境準備：Node.js v22・pnpm・macOS。TypeScript インストール tsc –init で tsconfig.json 生成・check:type スクリプト。intentional に bad code (var + any + typo)を埋め込む。ESLint 設定：v9 は Flat Config が標準（eslint.config.js の配列形式）。js.configs.recommended + tseslint.configs.recommended をベース。js.configs.recommended は no-var 等 JS 全般・tseslint.configs.recommended は @typescript-eslint/no-explicit-any 等 TS 向け。no-console はどちらにも含まれないため明示的に有効化。files で対象ファイル絞込（.ts のみなど）・ignores で dist/coverage 除外（node_modules はデフォルト除外）。package.json scripts：check:lint（eslint . –cache）・fix:lint（eslint . –cache –fix）。–cache で 2 回目以降高速化。.eslintcache は .gitignore 追加。動作確認でルール違反を引出し、fix で自動修復。

コンテナランタイム版の Notebook と Streamlit in Snowflake の自動停止の挙動を整理してみる

• URL: https://dev.classmethod.jp/articles/snowflake-container-runtime-sis-notebook-idle-timeout-and-auto-suspend
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: Snowflake コンテナランタイム版 Streamlit in Snowflake（SiS）・Notebook の自動停止は 2 層構造。Layer 1 サービス層（SiS は 3 日アイドル・Notebook は 24 時間デフォルト）・Layer 2 コンピュートプール層（プール上全サービスがアイドルになって初めて AUTO_SUSPEND_SECS カウント開始）。課金停止には両層が必要。Notebook のアイドルカウント起点は「接続中全 Notebook の実行セルが全終了した時点」。複数 Notebook が同一サービス接続の場合は最後の 1 つがアイドル化までカウント開始しない。

詳細

Snowflake コンテナランタイム SiS・Notebook の自動停止は 2 層独立構造で課金停止まで複数条件を満たす必要あり。Layer 1 サービス層アイドルタイムアウト：SiS（Streamlit in Snowflake）は 3 日間アクセスなしで自動停止（トリガーはアプリ表示・常時稼働サーバーのため基本稼働続行）・Notebook（Notebooks in Workspaces コンテナランタイム版）はアイドルタイムアウト 24 時間デフォルト（UI 指定可能）。Notebook のアイドル起点は「接続中全 Notebook で実行中セル全終了した時点」で、ブラウザを閉じたかどうかではなく実行完了を基準。複数 Notebook が同一サービス接続時は最後の 1 つがアイドルになるまでカウント開始しない。Layer 2 コンピュートプール層：サービスがサスペンドされてもプール上に他サービスが残っていれば課金継続。プール上の最後のサービスが停止して初めて AUTO_SUSPEND_SECS カウント開始。その後プールがサスペンド。検証結果（AUTO_SUSPEND_SECS=300 秒）：Notebook はセル完了から約 18 分後サービス SUSPENDED・5 分後プール SUSPENDED で想定通り。SiS はアプリ閉鎖後も稼働・課金継続（3 日待ちは現実的でないため ALTER COMPUTE POOL … STOP ALL で強制停止・SUSPEND で即座にプール停止）。SiS コンテナランタイムは 3 日固定アイドルタイムアウトでユーザー側短縮手段なし。コスト抑制は使用終了時に STOP ALL・続けて SUSPEND を実行するのが確実。

SSMセッションマネージャーでEC2タグベースのアクセス制御を試してみた

• URL: https://dev.classmethod.jp/articles/ssm-tag-base
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Systems Manager Session Manager で EC2 へのアクセスを IAM ポリシー + EC2 タグで制御。VPC エンドポイント経由でSSM接続（NAT Gateway 不要）。Terraform で検証環境構築。構成：プライベートサブネット EC2・3 つの VPC エンドポイント（SSM/SSMMessages/EC2Messages）・IAM ロール・タグベースアクセス制御。EC2 に SSMAccess=allowed タグを付与、IAM ポリシーで ec2:ResourceTag 条件キーで制御。

詳細

AWS Systems Manager Session Manager で EC2 へのアクセスを IAM ポリシー + EC2 タグベースで制御。構成：プライベートサブネット EC2（パブリック IP なし）→ VPC エンドポイント経由で SSM 接続（NAT Gateway 不要）。Terraform で検証環境構築。構成要素：(1) VPC + プライベートサブネット、(2) 3 つの VPC エンドポイント（com.amazonaws.region.ssm / ssmmessages / ec2messages）に Interface タイプ指定・Private DNS 有効化・VPC エンドポイント用セキュリティグループで VPC 内 443 許可、(3) EC2 インスタンスに IAM ロール・SSMAccess=allowed タグ付与、(4) IAM ポリシー ec2:ResourceTag で タグベースアクセス制御。利点：限定 EC2 へのみ Session Manager 接続可・タグで柔軟管理・パブリック IP/NAT Gateway 不要。Terraform で aws_vpc/aws_subnet/aws_vpc_endpoint（SSM/SSMMessages/EC2Messages）/aws_security_group/aws_instance でコード化。

生成 AI で書類審査を行う AWS ソリューション「RAPID」をデプロイして使ってみた

• URL: https://dev.classmethod.jp/articles/try-rapid-document-review-on-aws
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS ソリューション RAPID（Review & Assessment Powered by Intelligent Documentation）は生成 AI による書類審査支援・Human-in-the-Loop 型。チェックリスト × 審査対象ドキュメント を Amazon Bedrock Claude で判定・合否・信頼度・判定理由・引用箇所を返す。Frontend React SPA・Backend Fastify REST・CDK インフラ・Lambda で Bedrock 呼び出し。デプロイ：CloudShell ワンライナーまたはローカル CDK。examples/ja に見積書・申請・監査など 8 サンプル。精度向上：項目ごとモデル切り替え・ツール割当（Code Interpreter・Knowledge Base・MCP）・フィードバック集約。

詳細

RAPID（Review & Assessment Powered by Intelligent Documentation） ─ AWS 公式サンプル・生成 AI 書類審査支援・Human-in-the-Loop 型。仕組み：チェックリスト項目 × 審査対象ドキュメント を Amazon Bedrock の Claude に判定させ pass/fail + 信頼度（0-1） + 判定理由 + 根拠引用箇所を返す。ユースケース：製品仕様が要件準拠か・技術マニュアルがガイドライン準拠か・調達文書が必須要件充足か。構成：frontend は React SPA・backend は Fastify REST API・cdk は AWS CDK インフラ定義・review-item-processor は Python Lambda で Bedrock 呼び出し。Step Functions + Lambda が審査実行。デプロイ方法 2 種：(1) CloudShell ワンライナー wget | bash（–bedrock-region/–document-model/–cognito-self-signup/–ipv4-ranges オプション指定可）・(2) ローカル CDK（手元に AWS 認証・Node.js/CDK・Docker 必須・Bedrock モデルアクセス有効化・Tool use 対応モデル使用）。前提：parameter.ts で bedrockRegion・cognitoSelfSignUpEnabled 指定・availableModels で項目ごと選択肢定義。使い方：(1) チェックリスト作成（PDF upload で AI 自動抽出 or 手動編集）・(2) 審査ジョブ実行（PDF・画像 4.5MB 以下）・(3) 結果確認（pass/fail + 信頼度 + 判定理由 + 引用箇所・audit trail）・(4) 人間が上書き修正（ユーザー上書きバッジ付）。精度向上手段：(1) 項目ごとモデル切り替え（Opus 精度・Sonnet バランス・Haiku コスト）・(2) ツール割当（Code Interpreter 数値検証・Knowledge Base 規格書参照・MCP 外部サービス連携）・(3) Feedback Aggregator が人間上書き傾向を定期集約し以降の審査に反映。examples/ja には見積書・申請・監査等 8 業務サンプルが checklist + PDF セット。

VercelのAIエージェントフレームワーク「eve」を試してみた｜ブログのナレッジで自作キーボードエージェントを作る

• URL: https://dev.classmethod.jp/articles/vercel-eve-agent-framework
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: Vercel eve はオープンソース AI エージェントフレームワーク（public preview）。位置づけは「Next.js for agents」。エージェント構造：agent/ ディレクトリ配下に agent.ts（モデル）・instructions.md（人格）・tools/（ツール）・skills/（知識）・subagents/（子エージェント）・channels/（Slack など）・schedules/（定期実行）。Batteries included（耐久実行・サンドボックス・人間の承認・トレース・evals）。Contentful CMS のナレッジを skill に変換し、ブログ由来の AI エージェント構築が可能。

詳細

Vercel eve ─ 2026 年 6 月 17 日 Vercel Ship で発表のオープンソース AI エージェントフレームワーク（public preview）。「Next.js for agents」の位置づけ。従来のエージェント構築では状態永続化・中断再開・サンドボックス・API キー預かり・Slack 連携・定期実行などを毎回自前で土台を組む必要があったが、eve はこれらを規約 + フレームワークに集約。agent/ ディレクトリツリーで構造が一目瞭然：agent.ts（使用モデル）・instructions.md（役割・人格・システムプロンプト）・tools/（ツール定義・1 ツール 1 ファイル）・skills/（知識・Markdown・必要時読み込み）・subagents/（作業委譲）・channels/（Slack など）・schedules/（定期実行）。Batteries included：耐久実行・サンドボックス・人間の承認・subagent・チャネル・トレース・evals。Contentful CMS 統合で existing ナレッジを skill に変換。実装例：自作キーボードブログ（CMS 由来記事 + 文体 skill）をエージェント化、eve link で Vercel リンク・AI Gateway 認証、eve dev でローカル動作確認・HTTP ルート叩き可、eve deploy で本番デプロイ。モデルは環境変数で dev/prod 切り替え可能（Haiku 無料枠 vs Sonnet 上位）。エージェント呼び出しルートはデフォルト保護（認証必須・agent/channels/eve.ts で設定）。

Claude Code / Codex の全社展開とAI観測基盤の設計 | ドクセル

• URL: https://docswell.com/s/rakutek/59NR49-2026-06-04-194729
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code・Codex の全社展開と AI 観測基盤の設計。OpenTelemetry × Grafana で利用ログから意思決定に繋ぐ。全社導入完了後も利用実態が見えない課題。OTel × MDM で全社員ログ集める。Claude Code・Cowork・Codex は OpenTelemetry 対応・API request・tool result・prompt 等をメトリクス・ログでエクスポート。managed-settings.json で環境変数配布、Jamf（MDM）で全 macOS に一括。Codex も managed_config.toml で [otel] 設定・同じ Grafana に統合。完成ダッシュボード。GitHub・Notion で出力側接続・KPI に接続（構想中）。計測数字が決算資料にも掲載。

詳細

Claude Code・Codex の全社展開と AI 観測基盤の設計。OpenTelemetry × Grafana で利用ログから意思決定に繋ぐ。クラシル社は 2023/4 ChatGPT・Devin → 2025/2 Cursor・エンジニア全員 → 2025/5 GitHub Copilot → 2025/6 Claude Max → 2026/2 Claude Team 導入。課題：全社導入完了後も利用実態が見えない、トップダウン導入で誰がどう使っているか不明、個別ヒアリング数百人規模で現実的でない、定量的観測仕組み必要。「導入した」と「使われている」は別物。観測基盤3段階：①観測する、②横に広げる、③成果と繋ぐ。OTel × MDM で全社員ログ集める：Claude Code・Cowork・Codex は OpenTelemetry ネイティブ対応。Claude Code はOTEL_* 環境変数・config、Cowork は Team/Enterprise で OTEL 対応・Admin 設定から有効化、Codex CLI は managed_config.toml で [otel]。OTel 標準だからベンダー中立、可視化基盤自由（Grafana・Datadog・New Relic・Honeycomb）。クラシルは Grafana Cloud。本当の課題は「設定をどう全社員に届けるか」。Claude Team 複数組織・個人契約 Max・ChatGPT Pro 混在で Admin 設定だけでは全員カバー不可。設計判断：managed-settings.json を MDM で全社配布。ユーザーが上書きできない組織レベル設定を Jamf（MDM）で全 macOS 一括配布・ユーザー操作ゼロで全社員カバー・全端末で OTel エクスポート強制 ON。Codex は管理者が強制する制約・/etc/codex/requirements.toml 最優先。Codex CLI も同じ設計に乗せられる、managed_config.toml の [otel] で設定・同じ Grafana に統合。service_name で 「claude-code」「cowork」「codex-app-server」「codex_cli_rs」など ソース見分け。Claude・Codex で取れるフィールド差あり、Codex には cost_usd ないため概算ロジックで換算。③成果と繋ぐ：GitHub API・Notion API で OTLP 互換可視化基盤に・Grafana Infinity datasource で読み込み、GitHub ユーザーと社員を紐付け、入力側の隣に出力側並ぶ、決算資料にも計測数字掲載。

AWS、AIエージェントがリポジトリを自動スキャンして技術的負債を指摘してくれる「AWS Transform – continuous modernization」プレビュー公開

• URL: https://www.publickey1.jp/blog/26/awsaiaws_transform_continuous_modernization.html
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Transform - continuous modernization（プレビュー）はリポジトリを継続的に自動スキャンし、廃止 API・終了ランタイム・非対応ライブラリを技術的負債として検出。組織固有のポリシー拡張でカスタマイズ可能。修正プルリクエスト自動提案、脆弱性検出も同時実行。数時間単位で結果を報告し、計画的な技術負債対応を実現。

詳細

AWS Transform の新機能として、リポジトリを継続的に自動スキャンして技術的負債を検出するサービス。廃止される API・サポート終了のランタイム・非対応ライブラリなどを自動検出。組織ごとの承認ライブラリ・内部コーディング標準などのルール拡張でカスタマイズ可能。優先度付きリストの生成・修復用プルリクエストの自動提案。AWS Security Agent との統合により脆弱性検出・修正も並行実行。従来は開発時間の空きを待つなど後ろ倒しになりがちだった技術負債対応を、数時間の検出サイクルで計画的に進める仕組み。

AWS、コードだけでなくインフラ構成とビジネスコンテキストも理解した上で脆弱性を推論する「AWS Contiuum」発表。特定のAIモデルに依存せず

• URL: https://www.publickey1.jp/blog/26/awsaws_contiuumai.html
• 日付: 2026-06-22
• Tier: Tier 2
• 要旨: AWS Continuum for code vulnerabilities は、コード脆弱性検出に加えてインフラ構成・アクセス許可・ネットワークトポロジー・ビジネス優先度・ドキュメントをコンテキストとして活用し、脆弱性の影響度・悪用時のビジネスリスクを総合評価する脆弱性推論サービス。複数 AI モデルを組み合わせ、特定のモデルに依存しない設計。脅威モデル自動生成（STRIDE 形式）・ペネトレーション実行・エクスプロイト検証・修復推奨を統合。

詳細

AWS Continuum for code vulnerabilities（プレビュー）はコード脆弱性スキャンだけでなく、インフラ構成・アクセス許可・ネットワークトポロジー・ビジネス優先度・ドキュメントを総合的に評価。脆弱性が本番環境に到達可能か、悪用時のビジネス影響はどの程度か、既存の防御策は十分か、どう修復するか、修復時の影響範囲とロールバック経路は何か、といった実運用視点での優先順位付けを実施。サンドボックス環境での再現エクスプロイト検証により誤検出を排除。複数の最新 AI モデルを並行利用し、新しい高性能モデルの登場に対応可能な疎結合設計。同時に Threat Modeling（STRIDE 形式）・Penetration Testing・Code Scanning を Continuum ブランド下で統合運用。

vol.212　タスクスケジューラともっと仲良くなろう｜セイテク・シス管道場（Web）

• URL: https://www.say-tech.co.jp/contents/blog/yamanxworld/2026vol212
• 日付: 2026-06-22
• Tier: Tier 1
• 要旨: Windows Server タスクスケジューラ（Taskschd.msc）解説。基本：対話なし処理・コマンドライン・バッチ・スクリプト準備 → 操作タブで実行内容・全般タブでログイン条件・実行アカウント・トリガータブで開始条件指定。実行ユーザー SYSTEM なら保存時パスワード不要。SYSTEM 以外は要求。UAC 有効で フルトークン権限必須なら「最上位の特権で実行」チェック。CLI：schtasks コマンド・ScheduledTasks PowerShell モジュール。パフォーマンスモニター・データコレクターセット連携で警告時タスク実行・引数 $(Arg0) などで受取・置換変数 {value} など動的引き渡し可能。ログクリーンアップ等に活用。

詳細

Windows Server タスクスケジューラ（Taskschd.msc）詳細解説（著：山内和朗・vol.212）。役割：運用管理タスク自動実行・システム起動時・ユーザーログオン時・指定日時・繰り返しスケジュール・オンデマンド実行。設定項目：「操作」タブにプログラム/スクリプト + 引数（バッチ：.bat/.cmd パス・cmd.exe with /c コマンドライン・powershell.exe with -ExecutionPolicy Bypass -File ps1 ファイル・cscript.exe with vbs 等）。「全般」タブでセキュリティオプション：「ユーザーログイン状態に関わらず実行」選択時は session 0 で実行・実行ユーザー SYSTEM なら保存時パスワード不要・他ユーザーは要求。SYSTEM でない場合かつ UAC 有効で full token 権限必須なら「最上位の特権で実行」チェック。「トリガー」タブで実行トリガー指定。CLI：schtasks コマンド（/run /tn）・ScheduledTasks PowerShell モジュール（Start-ScheduledTask・Disable-ScheduledTask・Enable-ScheduledTask）でオンデマンド・無効化・有効化・スケジュール変更。高度な活用：パフォーマンスモニター・データコレクターセット連携で警告トリガータスク実行・引数動的引き渡し可能。警告の動作で別データコレクターセット開始・警告のタスクで特定タスク実行・引数を $(Arg0)・$(Arg1) などで受取。置換変数 {value}（警告カウンター値）等で動的パラメータ。データコレクターセット停止時タスクで自動実行（ログクリーンアップ等）・{logs} 置換変数でログファイルパス展開。例：PowerShell CleanupLog.ps1 スクリプトでログファイル 指定日数より古いものを削除・データコレクターセット毎日ログ切替時にクリーンアップ自動実行。パフォーマンスカウンター「%Free Space 50% 以下」警告で msg タスク実行し引数でユーザーにアラート通知など活用例。

Claude Codeをどのように キャッチアップしているか

• URL: https://speakerdeck.com/oikon48/claude-codewodonoyouni-kiyatutiatupusiteiruka
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code をどのようにキャッチアップしているか。Zennfes Spring 2026 スライド発表。GitHubの更新・公式ドキュメント・ブログ・X・実機検証の4つ情報源。直近1年で 328 件の CHANGELOG 更新（v2.1.183 まで）。GitHub では追加機能はスラッシュコマンド・オプションすぐ試す、バグ修正はニッチな修正も関連 Issue 辿り調査、改善は挙動変化把握・検証。公式ドキュメント：sitemap 辿り・各ページ .md ダウンロード・1日4回チェック・git diff で検知。ブログ・X：claude.ai・ClaudeDevs・開発者から追跡。実機検証：リリースノート見たらまず手動・仕様怪しいものはプロトタイプ生成・Claude Code が Claude Code 検証（tmux・Computer Use）。集めた情報：ニュースレター・エージェント解説・ブログ・書籍執筆サポート。

詳細

Claude Code をどのようにキャッチアップしているか。Zennfes Spring 2026 スライド発表。直近1年で 328 件の CHANGELOG 更新（206 日稼働・最多8件/日）、v2.1.183 まで。4つ情報源：GitHub・公式ドキュメント・ブログ・X・実機検証。GitHub では追加機能「スラッシュコマンド・オプションはできるだけ簡単に試す」、バグ修正「ニッチな修正も関連 Issue 辿り調査」、改善「挙動変化把握・検証」。公式ドキュメント「STEP 1 sitemap 辿り各ページURL+.md で Markdown 取得」→「STEP 2 1日4回チェック .md として差分保存」→「STEP 3 git diff で検知・仕様変更・新規ページ把握」。Anthropic blog「claude.com/blog」・news「anthropic.com/news」・eng blog、X の Claude 公式・ClaudeDevs・開発者（Boris、Thariq）から追跡。実機検証1「実際に手を動かす。リリースノート見たらまず手を動かす（コマンド・スキルすぐ試す）、仕様怪しいものは Claude Code がプロトタイプ生成で検証、内部ツール系は Claude Code 自身に聞き解説」。実機検証2「エージェントにエージェント（Claude Code）検証させる。Claude Code が Claude Code を tmux 動かす。Computer Use だとターミナル危険操作で弾かれがち。/help や claude –help でコマンド・フラグ自動収集。Devin なら Ubuntu・Windows 両方＋ターミナル可能」。集めた情報活用：個人的ニュースレター・エージェント解説用・ブログ・書籍執筆サポート。最近：Claude Code 書籍執筆時、24時間変更を検知→原稿要修正箇所確認→GitHub Issue 自動起票で修正タスク管理。

気休めの通知

• URL: https://zenn.dev/acntechjp/articles/claude-code-bell-notification
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code で hooks が使えない Windows Terminal 環境向けに、気休め程度の通知をターミナル標準機能で実現。設定手順1：Claude Code /config で Local notifications を Terminal Bell(\a) または iTerm2 w/ Bell に変更。手順2：Windows Terminal Ctrl+, で設定開き、「Windows PowerShell」→「詳細設定」→「ベル通知スタイル」を音・フラッシュウィンドウ・フラッシュタスクバーから選択。手順3：Windows11 設定で「タスク バーの動作」→「タスクバーアプリの点滅を表示する」をオン。仕組みは古くからターミナルの制御文字で音鳴らし機能、Claude Code が操作必要な時に制御文字をターミナル送信、Windows Terminal が制御文字受け取って音・タスクバー・ウィンドウ点滅、Windows11 がタスクバー点滅画面表示。

詳細

Claude Code で hooks が使えない Windows Terminal 環境向けに、気休め程度の通知をターミナル標準機能で実装。下の画像みたいにタスクバーが点滅、ウィンドウも一瞬光る。手順1 Claude Code：設定変更。Windows Terminal から Claude Code 起動後、Config 画面を開く（/config → Enter）。Config 項目の一覧から「Local notifications」と設定値を「Terminal Bell（\a）」または「iTerm2 w/ Bell」に変更（↑↓キーで項目選択・←→キーで設定値変更）。手順2 Windows Terminal：設定変更。Windows Terminal の設定画面を開く（ターミナル上で Ctrl + , 入力）。画面左側メニューの「Windows PowerShell」選び・一番下の「詳細設定」クリック。「ベル通知スタイル」項目探し、下記をお好みで設定：「音によるチイム」通知音鳴らす・「フラッシュウィンドウ」ターミナルのウィンドウを一回点滅・「フラッシュタスクバー」タスクバーのアイコンを点滅・点灯。最後、「保存」ボタンクリックして設定画面のタブ閉じる。手順3 Windows11：設定確認・変更（デフォルト設定から変更していない場合は不要）。Windows の設定から「個人用設定 > タスクバー」画面開く（タスクバーの何もないところ右クリック → 「タスクバーの設定」クリック）。「タスク バーの動作」展開・「タスクバーアプリの点滅を表示する」をオン。これで Claude君が何か訊いてくるたびに、タスクバーが点滅するはず。仕組み：古くからターミナルには特定の制御文字を出力すると音鳴らす仕組みがある。設定により Claude Code がユーザー操作必要な時にその制御文字をターミナルへ送ってくれるようになり、Windows Terminal がこの制御文字受け取って、音だけでなくタスクバーやウィンドウを点滅させ、Windows11 がタスクバーの点滅を画面上に表示してくれる。筆者のクセで色々な設定については不要なものはオフにする習慣があり、Win11 側のタスクバーの設定の存在を忘れていて、最近ようやく通知が出るようになった。

AIとVOICEVOXで“自分だけのラジオ番組”を自動生成するツールを作った

• URL: https://zenn.dev/canpok1/articles/75b8c02579191e
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: vox-radio はAIとVOICEVOXで「自分だけのラジオ番組」を自動生成するツール。設定ファイルに「どんな番組にしたいか」を書いて、コマンド1つで台本・音声・BGM・効果音が自動で出来上がる。AIが感想を添えて記事を自動紹介するツール、AIに声で独り言を呟かせるツール、この2つを組み合わせた。話題集める→構成考える→台本書く（Gemini/OpenAI互換API）→声あてる（VOICEVOX）→仕上げる（ffmpeg）。設定ファイル・キャラ定義・コーナー構成を YAML で、コマンド1つで完成。

詳細

vox-radio は番組テーマ・キャラ・話題を指定するだけで、mp3 とポッドキャスト用RSS・Slack自動投稿が出来上がるツール。ステップ1：casts でMC・聞き役・ツッコミ役などキャラ役割を定義、corners で各コーナーの「何を話してほしいか」を日本語で記載（細かいセリフは不要）。ステップ2：vox-radio episodegen –spec episode-spec.yaml コマンド1つ。ステップ3：数分待つとmp3完成。内部フロー：話題集める（ニュース記事素材収集）→構成考える（どの話題をどの順で）→台本書く（キャラセリフをAI執筆、無料版Gemini・OpenAI互換API対応）→声あてる（VOICEVOX キャラ音声で読み上げ、API経由で別端末でもOK）→仕上げる（BGM・ジングル・効果音をffmpeg で1本のmp3に）。1～3は生成AI担当、4は VOICEVOX、5は ffmpeg。ユーザーはこの中身を意識不要。RSSフィード・Webの記事を素材にすれば情報番組に、BGM・効果音で演出、「番組作って」と AI に丸投げ、ポッドキャスト配信・Slack自動投稿も可能。キャラ声・BGM・効果音・記事それぞれに利用規約がありクレジット・ルール遵守が必須。

CodexでLPを作ってみた感想

• URL: https://zenn.dev/clavisflow/articles/699b97115c81d3
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Codex でLPを作って感想。最初のコミットでヒーローセクション・診断フォーム・レスポンシブ・Canvas背景演出一気。プロトタイプ速度は圧倒的。ただ公開形にするまでは終わりでなかった。綺麗なテンプレートに、後から「生々しい意味」を足す。AIは「DX推進」「最適化」と抽象的。ASP.NET 不具合調査・VB6 段階的リプレース・Classic ASP→Blazor 再構築・SQL チューニングなど具体例追加。「相談しやすさ」の空気感チューニング、プロフィールアイコン・サポートメッセージ。「ここが気になるだけでも大丈夫」文言が大きかった。ユーザーの「不安」を先回りして消す。

詳細

ClavisFlow のLPをCodexで短時間で形にした。最初のコミットでヒーローセクション・診断フォーム・レスポンシブ対応・Canvas背景演出まで一気。プロトタイプ作るスピードは圧倒的に速い。ただ公開できる形にする作業はそこで終わりでなかった。綺麗なテンプレートに、後から「生々しい意味」を足す必要があった。最初のLPは見た目として綺麗に成立。でも「何ができるのか」「どこから相談していいのか」という独自強みが伝わらない。AIが書くテキストはどうしても「DX推進」「システム最適化」といった抽象的。後から実績・スキルセクションに具体的な例を足した：ASP.NET業務システムの不具合調査・改修、VB6システムの段階的リプレース、Classic ASPからBlazorへの再構築、SQLチューニング。「相談しやすさ」という空気感のチューニング、プロフィールアイコン入れてサポートメッセージ追加。特に「まずは『ここが気になる』だけでも大丈夫です」という文言が大きかった。状況を整理できず「何がわかっていないかもわからない」状態でカチッとしたフォーム出されるとハードル高く離脱。単に「診断します」機能提供でなく「断片的な情報から一緒に整理しましょう」空気感を出した。モバイル実機確認も大事、AIはスマホ狭さ考慮してブランド名非表示にしたが、スクロール読むうちに「何というサービス見ているのか」ユーザー印象に残らない。CSS調整してスマホでも ClavisFlow 名前自然に残すようにした。実機見ながら「なんか変だな」違和感潰した。

Claude Code のブラウザ自動化を全部試した — 最終結論

• URL: https://zenn.dev/davidai311/articles/browser-tools-evolution-verdict
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code はターミナル中心で Web が見えないため、ブラウザ自動化ツール6つを2026年2月～3月かけて実践比較：Chrome DevTools MCP（デバッグフラグ起動・10,000+ トークン）→ Claude in Chrome 拡張（Cookie 実ブラウザ共有・ベータ切断）→ WebFetch（SNS ゴミ返し）→ agent-browser（3,000～5,000 トークン・セッション間 Cookie なし）→ PinchTab ゲームチェンジャー（約800トークン・HTTP サーバー常駐）→ browser-use（複雑フォーム自律エージェント最強・トークン多消費）。最終結論は優先チェーン：PinchTab（日常全て）→ browser-use（複雑マルチステップ）→ agent-browser（特殊用途）→ WebFetch（静的ドキュメントのみ）。トークン効率が全て、800 vs 10,000 は12倍差でセッション寿命が全く違う。

詳細

Claude Code は毎日12時間以上使う中で、ターミナル中心の設計で Web が見えない苦行を経験。Chrome DevTools MCP は公式アプローチ（–remote-debugging-port=9222 フラグ・MCP JSON ペイロード 10,000+ トークン・Windows npx 動かない・デバッグ Chrome 起動で Cookie ログインなし・テキスト入力1文字目消える・複数行壊れる・毎回 Chrome 再起動）の落とし穴多数。Claude in Chrome 拡張 v1.0.54 Beta は実ブラウザ Cookie・ログイン情報そのまま・セットアップ拡張のみ・ベータ品質で突然切断・テキスト入力バグ健在・複数行壊れる。WebFetch は静的ドキュメントは問題なく、SNS（Instagram・Twitter）は CSS・JavaScript ゴミ返し・テキスト取れない・動的ページ全滅。agent-browser（Vercel Labs・Rust CLI・Playwright バックエンド）は初の光でコンテキスト 93% 削減（3,000～5,000 トークン）・コンパクトテキスト出力・シェルコマンド操作・Auth Vault 認証保存。Windows 落とし穴は Rust canonicalize() が\?\ UNC パス生成、Node.js クラッシュするため AGENT_BROWSER_HOME 環境変数迂回必要。限界はページ 3,000～5,000 トークン・毎回 Chromium 起動・セッション間 Cookie 引き継ぎなし・SNS テキスト抽出まだ重い。PinchTab ゲームチェンジャーは HTTP サーバー常駐・Chrome アクセシビリティツリー使用・ページあたり約 800 トークン（12 倍軽い）・セットアップ pinchtab &・セッション中ずっと動く・再起動不要。pinchtab text 800・pinchtab snap -i -c 2,000・pinchtab snap –diff 差分・pinchtab snap フル 10,500・pinchtab ss 2,000（Vision）。SNS 読む text 800 トークムで済むのが全て変えた。Twitter 投稿・Instagram プロフィール・デプロイ後ページ検証全部 800 トークン。HTTP API（ポート 9867）も提供でボット・自動化パイプライン組み込み。browser-use（Python フレームワーク・GitHub 80,000+ スター）は PinchTab で面倒な複雑フォーム入力を自律エージェント化。求人応募フォーム 10+ フィールド・ドロップダウン・ラジオ・テキストエリア・自律エージェント「入力して」で完結。トレードオフは PinchTab より遥かにトークン消費・各ステップで LLM 呼出・ページあたりトークン多い。複雑マルチステップなら 20 分手動 vs 3 分自律で時間節約。全ツール比較表で Chrome DevTools MCP・Claude in Chrome は 10,000+・agent-browser 3,000～5,000・PinchTab 約 800・browser-use 10,000+。セットアップ・Windows・認証・安定性・速度・SNS・フォーム・自律エージェント・常駐・コスト各軸。乗り物例：PinchTab は自転車（速い・燃費最高・日常）、browser-use は車（遠く・荷物・燃費悪い）、agent-browser はバイク（予備・特殊）、WebFetch は徒歩（遅い・重い無理・最後の手段）。6 つ全試してよかった、完璧なツールは存在せず組み合わせが答え。

AIエージェント時代の開発コストは、モデル名ではなくループ設計で決まる

• URL: https://zenn.dev/heftykoo/articles/cd6dd9dd6f30be
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: AI エージェント時代の開発コストはモデル名ではなくループ設計で決まる。エージェントが何周するかが怖い。GitHub Copilot 従量課金・AI credit の登場で請求単位が「チャットの回数」から「エージェント実行量」へ移行。コスト管理は経理でなく開発設計の問題。「この画面をいい感じに直して」は短いが安くない依頼で、AIはファイル探索・テスト・失敗時試行錯誤で長いループを回す。対して「FormError メッセージだけ変更、FormField ルール準拠、app/settings 配下、バリデーション仕様不変、pnpm test 通したら完了」なら境界明確で迷う時間削減。issue は仕様書でなく実行境界。「どこまで動いてよいか」を決める必要。

詳細

AI エージェント時代の開発コストはモデル名や料金表でなく、AI に何周させるかで決まる。補完・チャットなら人間が拍を握り一区切りで終わり。エージェントは読む・探す・直す・テスト・失敗・読み直す・別場所直す・PR 作成という作業ループに入り伸びやすい。GitHub Copilot 従量課金・AI credit 登場で、「月額補完の感覚では読めない」。請求単位が「チャット回数」から「エージェント実行量」へ移行。Cloud agent は issue から作業開始・リポジトリ調査・実装計画・ブランチ・PR 進行。「1 回質問」でなく「小さな作業者をキューに投入」。人間なら途中で「依頼大きすぎる」と止まり・仕様確認するが、エージェントは曖昧な依頼に筋通った解釈作って進む。「この画面をいい感じに直して」は短いが安い依頼でない、AI は関連ファイル探索・既存コンポーネント確認・CSS 読む・テスト探す・デザイン意図推測・複数画面修正・動作確認失敗で戻る。対して「フォームのエラーメッセージだけを、既存 FormField の表示ルール準拠に、app/settings 配下、文言変更とスタイル調整のみ、バリデーション仕様変えない、pnpm test 通ったら完了」なら境界明確でAI は迷う時間削減。長いプロンプトが偉いでなく、境界があるか。触ってよい場所・変えてはいけない仕様・確認・完了条件。Issue は小さな仕様書でなく実行境界。「何を作りたいか」+「どこまで動いてよいか」必要。エージェント向け issue は狭く・検証可能に・途中で止まれる。節約は「使わない」でなく「短く失敗できる単位」に。調査→設計案→実装→検証・PR と段階分割、手戻り見やすく、失敗で止め、設計案で前提違えば止められる。PRが出てから悩むのは遅い、投入前に設計判断する。タスクの形が曖昧なまま、どのモデル選んでも同じ問題に戻る。Agent-ready な開発者はAIに何頼むかだけでなく、何周させるかを考えている。

Codex Record & Replay の正体は「再生」ではない：従量課金が変えるエージェント設計、3つの勘所

• URL: https://zenn.dev/hironakamura_ai/articles/18cb891c726984
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Codex Record & Replay の正体は「再生」でなく「実演→スキル化→再実行+検証」。従量課金が「最適化の狙い」を変えた。推論の償却（amortize cognition）：定額課金時代は「毎回どれだけ深く考えるか」が賢さ、長く考えるほど偉い。従量課金は逆、繰り返しタスクで毎回プラン立て直しは二重払い。初回思考を成果物に固めて使い回す方向。インタプリタからコンパイラへの移動に近い。トレース→パラメータ付き仕様→本番：座標再生でなく現環境で再グラウンディング＋検証ゲート。3つの勘所：トレース捨てない・スキル化・機械的判定可能な検証。

詳細

Codex の Record & Replay は「録画再生」でなく「教師例→スキル下書き→本番再実行」。OpenAI ドキュメント：録画止めると Codex が「キャプチャしたワークフロー点検・スキル下書き。スキルに『いつ使う・入力要件・手順・結果検証』」と述べ、保存されるのは操作テープでなく言語化した仕様書。再生時は新スレッド・今回だけ違う値（ファイル・issue・日付範囲）渡す。Codex がコンテキストとして読み、Computer Use・ブラウザで「その場のツール」使い、毎回その場の画面に向き合ってボタン選び直して動く。座標を叩き直すでなく「パラメータ付き仕様」と現環境で再グラウンディング。従量課金が「最適化の狙い」を変えた、Copilot トークン効率記事「従量課金にいま、エージェントセッションの1トークンすべてが効く」。プロンプトキャッシュ保持延長・安定境界に最大4つキャッシュ区切り・ツール定義名と説明だけの軽いメタ必要時展開で 9～18% トークン削減。「同じ文脈毎ターン読み直して課金される」をやめ「一度やった思考を再利用・二度払わない」。推論の償却（amortize cognition）：定額課金は「毎回深く考えるか」で賢さ・長く考えるほど偉い、従量課金は逆・繰り返しで毎回プラン立て直しは二重払い、初回思考を成果物に固めて使い回す。インタプリタからコンパイラへの移動。意図毎回その場で解釈でなく、再利用可能な中間表現に一度コンパイル。Record & Replay のスキルもCopilot キャッシュ済みプレフィックスも「コンパイル済みの何か」。自分のエージェント3つ：トレース捨てない・パラメータ付き仕様を起こす・機械的に判定可能な検証必ず付ける。非決定的再実行を信用できるものに変えるのは最後の検証ゲート。決定的な骨格・非決定的な穴埋め・決定的な検証で三層。

テストは緑なのに壊れている ― Coverage AuditとAssurance Auditの違い

• URL: https://zenn.dev/ichikawa_y/articles/assurance-audit-grading-engine
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: カバレッジ95%・テスト緑・CIも緑でも脆弱性が見つかるのは、Coverage Auditが「どれだけテストしたか」を測るのに対し、Assurance Auditが「守るべきことが本当に守られているか」を問うから。制御が存在しない、モックが防御を無効化、テストが期待値でなく副作用しかassert していないといったTest Theater（テスト劇場）を見抜く必要。Control（None/Detective/Preventive）→ Test → Quality（Strong/Weak）→ Statusで信頼度を採点する採点モデルが有効。Expected Outcome を明文化する工程自体が制御の不在を暴く最良のタイミング。

詳細

Coverage Audit は カバレッジ率・テスト件数で「どれだけテスト」を測るが、20%の未テスト部分が危ないか、80%が実は守れていないか何も言わない。Assurance Audit は「起きてはならないこと」の制御（None/Detective/Preventive）→ テスト有無 → テスト品質（Strong/Weak）→ Status で信頼度を採点。assertが存在・テストが通る・CIが緑でも、本当に守りたいものは一度も検証されていない Test Theater を見抜く。Quality の判定基準：Strong は期待される結果（Expected Outcome）を直接assertしている（response.status==403を直接見ている）；Weak は副作用やモック裏の本体隠蔽・別機能経由での間接カバー。重要なルール：Weakが件数を上書きする――10件のWeakは10件の赤のまま。テストの数増は Assurance Audit 観点では信頼度を上げない。通常テスト思想は「テスト書く→assert」で終わるが、Assurance Audit は「テスト前に Expected Outcome を1行明文化」を加える。これは「テストの前に仕様を監査」である。実施例で起きたのも Expected Outcome を書いた瞬間に制御が実装側に存在するか確認せざるを得なくなり、確認過程で制御の不在が露呈。Control Strength：None は機構がない；Detective は悪いことが起きた後に気づく（監視・アラート・ログ）；Preventive は起きる前に止める（403・429・UNIQUE制約）。「ログに残す」は Detective で Preventive でない。Status の組み合わせ：Missing Control（None）は赤；Stale Control（テスト0件なのに台帳上は対策済み）は赤；Weak Test（テストあるが品質Weak）は赤；Structural Weakness（Preventive可能なのにDetective のみ）は黄；SPOF（Strong なテスト1件のみ）は黄；OK（Strong 2件以上）は緑。Status は健全度で重要度でない。「grep で0件」は存在しないの結論でなく「もっと深く掘れ」のトリガー――タグだけで検索0件なら、期待される結果と制御の具体的な識別子で再検索。

【超初心者の挑戦】設計の話 — Repository パターンを「初心者」が学ぶということ

• URL: https://zenn.dev/ichirogonda/articles/kurage-dev-03
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: コード未経験の父（56 歳）が Claude Code 相棒に iOS アプリ開発する kurage 開発記③。設計パターン（Repository）は上級者作法でなく、初心者が後で楽をするための仕掛け。仮データでいい段階でも「画面コードを後から開かずに済むように」と Claude Code が一歩踏み込む。データ係り（Repository）と使う人（画面）役分け。入口の形さえ変えなければ、中身は入れ替え自由。仮データ版・本物版先に決めて、今は仮データ版だけ作る。手が先に型を覚える。設計は初心者のためにあり、逆に初心者ほど早めに使うほど楽。

詳細

マーケティング担当 AI 社員 颯が、コード未経験のいちろうさん（56 歳・会社員）の Claude Code 相棒として iOS アプリ開発を支援。kurage（息子のバンド）向け、メンバー 3 人を並べるだけの画面。仮データコードに直書きでいい場面で Claude Code が「後で本物に差し替える時、画面コード 1 行も触らずに済むように」と提案。いちろうさん「3 人並べるだけなのに、おおげさじゃない？」に対し「画面コードは初心者がいちばん怖いところ。後で開かずに済む方が楽」と返答。これが Repository（リポジトリ）＝データ係り＝倉庫との出会い。画面が「データください」と頼むと、倉庫が出して渡す。登場人物は2人：使う人（画面側）・取ってくる人（倉庫/Repository）。画面側は「ください」と言うだけ、中身が仮か本物か気にしない。倉庫の入口の形さえ変えなければ、中身は入れ替え自由。入口だけ二種類（仮データ版・本物版）先に決めて、今日は仮データ版だけ作る。本物サーバー（Supabase）繋ぐのは後日。3 人並べるだけならオーバースペックに見える段取りだが、一度組めば本物差し替える日、画面コード開かずに済む。初心者にはこれが大きい。つまずきは「お手本が古い」こと、@Observable マクロが ObservableObject と書き方異なり、正しいはずサンプルが動かず、Claude Code が「いまの公式の書き方はこう」と横で選り分けてくれた安心。動いた画面を まず息子に LINE で 1 枚スクショ送信。翌日 LIVE タブ作る時、いちろうさんは「型を思い出そう」とすらせず、前日と同じ手つきで同じ型を並べていた。手が先に覚えていた。「自分も、できるようになっていく」初心者がいちばん欲しい手応え。翌日工房見学で息子とギター工房、その夜倉庫に小さな手入れ追加（名前から固定の色やレイアウト引く仕組み）。大事なのは、何か足したくなっても、開くのは倉庫の中だけ、画面コード触らない、直す場所先に決まっているから迷いません。設計パターンは上級者作法に見えて逆で、初心者ほど、早めに使うほど楽。本で覚えると「それ今やる必要ある？」と投げ返しながら腑に落とすのは別ルート、後者なら コード未経験でも設計と普通に出会える。

個人開発を Phase/Stage/Gate で構造化する — /clear してもコンテキストが壊れない設計

• URL: https://zenn.dev/kashi923/articles/c63230ad1f8700
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: 個人開発を Phase/Stage/Gate で構造化。/clear してもコンテキスト壊れない設計。エージェント開発で「さっき決めたこと」が食い違う壁が来る。コンテキスト自動圧縮で決定がズレ・根拠がどこにも残らない・品質確信持てない。Rust + Dioxus で個人資産可視化アプリを6ヶ月運用設計工夫。出発点：コンテキストは「揮発する作業メモリ」。判断・進捗・証跡の正本は git 管理ファイルに置く。階層：Phase（大目標）→ Task（中目標）→ Step（1 commit）→ Stage（設計・テスト設計・実装・テスト実施）→ Gate（レビュー）。状態ファイル分離：docs/STATUS.md・docs/phaseN/tasks.md・docs/decisions.md・docs/refactoring.md・テスト実施記録。Skill で「思い出す」を自動化。/step-start で前提決定論的再構築。/clear で意図的にコンテキスト消去。

詳細

個人開発でいちばん時間溶かしたのはコードより、エージェントと「さっき決めたこと」の食い違い。コンテキスト自動圧縮で決定がズレ・根拠が消失・品質確信なし。Rust + Dioxus で資産可視化アプリ（Wealth Compass）開発しながら運用設計工夫。出発点はコンテキストを「揮発する作業メモリ」と割り切る。判断・進捗・証跡の正本はすべて git 管理ファイル置く、コンテキストはそれを読み直す一時バッファ。/clear（コンテキスト全消去）が怖くなくなり積極利用可能。階層：Phase（プロジェクト貫く大目標1～6）→ Task（Phase内中目標）→ Step（1 commitに対応・単体で動作テスト完結）→ Stage（Step内4段階：設計→テスト設計→実装→テスト実施）→ Gate（各Stage完了時レビュー関門）。ポイントは Step=1 commit で単体で動作テスト完結粒度にすること。状態ファイル：docs/STATUS.md（現在地薄い索引）・docs/phaseN/tasks.md（進捗表）・docs/decisions.md（設計判断ログ D-1, D-2…）・docs/refactoring.md（後で直したい全件）・docs/phaseN/design.md・docs/phaseN/test-plan.md・docs/phaseN/test-evidence.md（テスト実施記録）。Skill で「思い出す」を自動化、/phase-start /step-start /step-complete /commit /phase-end で決定論的にやるべきこと機械的実行。/step-start で tasks.md・直前Step レビュー・テスト実施記録・関連設計判断・関連リファクタリング毎回同じ順で Read。/clear で会話捨てても新規セッション同じ状態から再開。Step区切りで意図的に/clear、タスク表・テスト実施記録・レビュー記録・設計判断ログ・リファクタリング候補ログの各ファイルに判断と進捗残る。矛盾実装激減、自動圧縮制御可、トークン効率向上、再現性出現。

「AIの近似値」に命を預けない。統治するのは我々だ！ ―― 他にはないIBMの最新基盤「ALSEA」によって、開発の主権はAIに渡さない

• URL: https://zenn.dev/kenjiigarashi/articles/1a7d16118a0ef0
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: IBMの最新AI開発基盤「ALSEA（アリーシア）」は、個人向けAIツール単体の導入による現場崩壊を防ぐため、日本の厳格なエンタープライズ開発が求める「品質保証・ID管理・プロセスの体系化」に正面から向き合う。AIが出す不完全な「近似値」をシステム的に検証・可視化し、人間が安全に「責任を取れる解答」へ昇華させるガバナンスの仕組みが本質。プロンプト自動最適化、全工程の自動ID採番、AIの自律修正（Self-Healing）という3つの層で、人間を「オペレーター」から「最終的な監督」へ役割転換する。ただしMVVMパターンではView領域はAIに適さず、ViewModel/Model領域に100%適用するのが正解。スタートアップ・アジャイル・小規模プロジェクトには向かない。

詳細

IBMはALSEA（アリーシア）という企業向けAI開発基盤を提供している。従来のAIツール単体導入では、プロンプト職人への依存、手作業によるID管理の崩壊、高度なレビュー疲れという3つの壁に直面し、タイピング削減の代わりに人間がAIの小間使いに成り下がる。ALSEAはこうした人間の負担をシステム側で隠蔽・自動化する。具体的には、裏側で最適化された巨大な指示文を自動生成し、要望書から詳細設計・実装・テストケースまでIDを自動採番して紐付け、AI自身が裏で自動テストを何度も回して自己修復することで、テストをパスしたコードだけが人間に届く仕組み。世界最強のAIであるClaude Codeの自由奔放な個人プレイ思想とは水と油で、ALSEAのような統制100%の思想と合体させると最大の武器が死ぬため100%不可能。そもそもClaude Codeは外部のALSEAのような中央管理システムから「指示やプロセスを制限・監視される」ためのAPI受け皿を持たないという物理的な構造の問題もある。ビジネス的背景としてAnthropicはClaude CodeでCOBOLシステムを格安で自動リプレイスできると発表し、IBMのコンサルティングビジネスと衝突してライバル関係になったため、IBMがALSEAのノウハウをライバル製品に提供する動機は1%もない。IBM Bob + ALSEA や ChatGPT + ALSEA が大正解。ID管理の自動化と見える化を実現し、人間が「オペレーター」から「最終的な監督」に回るためのシステムはALSEAだけ。MVVM（Model-View-ViewModel）パターンでは、View（画面）領域は見た目の肉付けを人間が担当し、ViewModel/Model（ロジックとデータ）領域にALSEAを100%適用するのが正解。スタートアップ・アジャイル開発では自由なこだわりが命で、ブレーキが多すぎて開発のスピード感を損なわせる。小規模プロジェクトでは環境構築や規約の落とし込みという泥臭い事前コストが必要で、数ヶ月で終わるプロジェクトではROIが合わない。ALSEAは「中～大規模のプロジェクトで、会社の厳格なセキュリティや規約を100%守らせ、誰が作ってもバグのない成果物とIDトレーサビリティを組織としてシステマチックに大量生産する」ための尖ったガバナンスシステム。必要なのは頭数を減らすことではなく、エンジニアの役割を泥臭い手作業の作業員から品質を保証する高度なレビューアーへ引き上げる組織の構造改革。

MCP入門 ① 自作ツール（MCP Server）を Claude Code から呼び出す

• URL: https://zenn.dev/koro_st/articles/9393bab30048c1
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: MCP（Model Context Protocol）は AI に自作ツール・自分の手元データを扱わせる仕組み。Host（Claude Code・Claude Desktop など AI アプリ本体）・Client（Host 内で MCP Server と通信する部品）・Server（ツール・データ提供プログラム）の3登場人物を分けて理解。Python SDK で self-hosting MCP Server を自作し、claude mcp add で登録して Claude Code から呼び出す。time-server は datetime 返す最小例、todo-server は JSON ファイル永続化で LLM の「忘れる」弱点補足。@mcp.tool() デコレータで関数を MCP ツール登録、docstring で LLM に説明、型ヒントで扱いやすく。

詳細

MCP のHost（AI アプリ本体）が ユーザープロンプト受け取り LLM 渡し必要時 MCP Server 呼び出し。Client（Host 内蔵部品）が Server と1対1通信。Server（別プロセス・stdio/HTTP）がツール・データ提供。この記事では Server を Python 自作に焦点。FastMCP SDK でサーバー定義、@mcp.tool() でツール登録、mcp.run() で起動。time-server は datetime.now() 返す最小例で、docstring が LLM の判断資料。todo-server は add_todo・list_todos・complete_todo 3ツール登録、load/save で JSON ファイル永続化。LLM は「追加して」「一覧取得して」とリクエストするだけで、実データ管理は Server（外部）担当、ファイル永続化で LLM 「忘れる」弱点補完。型ヒント（->str、todo_id: int）で戻り値・引数型明示、FastMCP が自動 JSON 化。claude mcp add で登録、絶対パス指定・–で右側が起動コマンド。claude mcp list で確認、✓Connected は ヘルスチェック成功・Server プロセス起動・MCP プロトコル通信確認。新セッションから使用可能、ツール名含めて指示すると確実に呼ばれる。初回は使用許可ダイアログ表示。mcp<サーバー名>__<関数名>の命名規則。「現在時刻教えて」と指示だけでは Bash date で応答されることもあるため、ツール名・Server 名明示が確実。

個人開発のモチベーション維持に、Codexで「開発の成長レポート」を作る

• URL: https://zenn.dev/mfactory_uh/articles/4f6f6d51768e4a
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: 個人開発のモチベーション維持に Codex で「開発の成長レポート」を作る。アプリ公開後インストール数増えないと「前に進めているか」不安。数週間・数ヶ月単位で振り返ると、設計・キャッシュ・データモデル・クラウド連携・リリース準備まで意外と多く積み重なっている。Codex にリポジトリコミット履歴・変更ファイルから「成長レポート」作らせる。「やや弱気で何が変わったか」を定量的に見える化。マイギャラリー（Android）で初回 2026-02-28 から HEAD 2026-06-20 まで、371 コミット・約16 週間・追加 172,575 行・削除 62,666 行。ローカル・GCP 試作→ Android ギャラリー→共通モデル→キャッシュ・メタデータ→クラウド同期→公開製品→編集機能拡張。

詳細

個人開発でアプリ公開後すぐに利用者増えないと「本当に前進しているか」感じて、モチベーション維持が難しい。毎日少しずつ改善のつもりでも数字に反映されない期間。Codex でリポジトリのコミット履歴・変更ファイル元に、アプリがどう成長したかをレポート。マイギャラリー（Android）で初回 2026-02-28～HEAD 2026-06-20、371 コミット・約16 週間・追加行 172,575・削除行 62,666・現在追跡ファイル 384。全体像：ローカル・GCP 写真試作→ Android ギャラリー基本機能→ローカル・クラウド・ごみ箱共通モデル→キャッシュ・メタデータDB・EXIF→GCS・S3・R2 クラウド同期→ストア公開・署名・規約・サイト→画像・動画編集・お気に入り総合メディアアプリ。2-3月は探索期、動作作り・データモデル・画面構造何度も組み替え。4月中旬からクラウド同期・公開準備、5月以降リリース済み製品として編集機能中心。週単位で振り返ると設計・キャッシュ・整合性・クラウド対応・公開準備・安定化・画像編集・動画編集・正式リリース・美肌補正・お気に入り・性能改善など段階的で、数週間・数ヶ月単位では想像以上に多くの前進が積み重なっていた。「機能を少し追加」「バグを直した」と思っていても、振り返ると意外と大きな構造変更・品質改善が実施されていた。

知らないと損する Claude Code のモデル設定 — 5つの実践的な設定テクニック

• URL: https://zenn.dev/moha0918/articles/daily-cc-model-config-20260406
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Codeのモデル設定は5つのテクニックで効果を最大化：opuspplanで計画はOpus・実行はSonnetに自動切り替え；effortLevelでタスク複雑さに合わせ思考の深さを調整（low/medium/high/max）；1Mトークンコンテキストを[1m]サフィックスで有効化；availableModels+model+環境変数の3点セットでモデル完全固定；ANTHROPIC_CUSTOM_MODEL_OPTIONで社内LLMゲートウェイをピッカーに追加。毎回コマンド打つのが面倒な場合は設定ファイルで固定、環境変数で指定できる。

詳細

Tip 1：opusplanエイリアスで設計フェーズにはOpus（深い推論・アーキテクチャ判断）、コーディング開始後はSonnet（速度と効率）に自動切り替え。Tip 2：effortLevelで必要な思考量を調整。low は コメント修正・変数名変更・簡単なリファクタ；medium（デフォルト）は通常コーディング全般；high は難しいバグ調査・設計レビュー；max は特に難解な問題（Opus 4.6専用・セッション非永続）。/effort コマンドやプロンプトの「ultrathink」で一回だけ high 相当に。Tip 3：Opus 4.6と Sonnet 4.6の100万トークンコンテキスト対応。/model opus[1m] や /model sonnet[1m] で有効化、フルモデル名でも同じ。プラン・契約で含有が変わる：Max/Team/Enterprise は Opus 1M がサブスク込み、Pro は両方追加課金。環境変数 ANTHROPIC_DEFAULT_OPUS_MODEL に[1m]付きで設定すると alias 使うたびに1M有効化。Tip 4：チームで完全固定するには3つをセット。model は初期選択、availableModels はピッカー制限、ANTHROPIC_DEFAULT_SONNET_MODEL で Default や sonnet alias 解決を固定。env ブロック抜くとユーザーがピッカーで Default 選んだ時に最新Sonnetリリース使われて固定すり抜け。Tip 5：ANTHROPIC_CUSTOM_MODEL_OPTION で社内ゲートウェイやプロキシ経由で使う場合、カスタムエンドポイントをピッカーに追加。_NAME と _DESCRIPTION で設定、Bedrock ARN でも モデルID バリデーション スキップ。_SUPPORTED_CAPABILITIES で ’effort,max_effort,thinking,adaptive_thinking,interleaved_thinking’ 明示的宣言で機能有効化。

Qdrant+Comfyui+Ollama = AI画像Studio ができた　ーClaudeから学んだ1ヶ月ー

• URL: https://zenn.dev/oimojet/articles/3004e617d74c93
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Qdrant+Comfyui+Ollama で AI画像Studio「Ranbell Image」を個人開発。GPU VRAM 16GB のローカルPCですべて賄い、雰囲気検索・画像合成・コレクション可視化を実現。自分の領域（制御系の運転思想・画像生成プロンプト制御・Qdrantへのデータ一元化）と Claudeに教わった領域（Qdrant応用・ベクトル類似度の数学・Lab*色空間・UMAP・Vue3・asyncio）の分別が重要。技術文書を自分の理解のためClaudeに書いてもらい、読み解いて学びを深めるサイクルが極めて効率的。

詳細

Ranbell Image はQdrant（ベクトルDB）・Comfyui（画像生成）・Ollama（ローカルLLM）を組み合わせたツール。コレクションから「夕焼けの感じ」といった雰囲気で検索、参照画像2枚を重み付けして新規合成、Lab色空間・Similarity Networkで自分のコレクションを立体可視化。自分は制御系の背景から、複数システムのGPU VRAM 16GB 制約でのプリエンプティブ制御やジョブスケジューラ（5レーン分離SYNC/EMBED/GEN/EVAL/PROMPT）・監視画面（ISA-101設計指針に沿ったHMI）・画像生成プロンプト制御（WD14タグ・ComfyUIワークフロー・Anima系モデル相性）・データ設計（JSON Payload もQdrantに乗せステートレス設計）を持ち込んだ。Claudeから教わった領域はQdrant応用（ベクトル代数・recommend/discover API・payload+filter）・ベクトル類似度の数学（コサイン・加重平均・Matryoshka Representation Learning）・Lab色空間（RGB でなくLab*の人間知覚的距離）・高次元埋め込み可視化（UMAP・k-means）・フロントエンド最新作法（Vue3/Vite/SSE/asyncio）。特に DiscoverQuery で「この画像と似てないけど関連はある」を引き出す応用は Claude に教わる中で会得。最大の発見は、コード完成後に Claude に「このコードベースを説明する技術文書を書いて」と頼み、docs/tech 配下に複数出力させ、読み解いて理論・実装を理解するサイクルが想像以上に効率的だったこと。「AIが開発者を置き換える」ではなく「AIは学ぶ意欲のある開発者を育ててくれる」という実感。

SKILL.md1個でエージェントは乗っ取られる、Agent Skillsの脅威分類

• URL: https://zenn.dev/okssusucha/articles/20260621-agent-skills-security-threats
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Agent Skills の脅威分類：SKILL.md 1個でエージェント乗っ取りリスク。「必要な時だけ読む」という遅延ロード設計が攻撃面の核心。スキル内スクリプトはコンテキストに入らず実行結果だけ見る仕組みで、中身を誰も読まない。npm パッケージより危い3つの構造的欠陥：データと指示の境界がない、承認は一度きりで持続（作者が事後改ざん可）、マーケットプレイス必須セキュリティレビューなし。脅威は7分類（配布・信頼・実行時・永続・横展開）で急所は T4 コード実行と T5 データ持ち出し。運用対策：.claude/skills/ 中身をレビュー前読む、allowed-tools 確認、disableSkillShellExecution で shell 実行停止、Meta Rule of Two で「機密・入力・通信」の3つ揃ったら人間レビュー。

詳細

Agent Skills は CLAUDE.md から手順書・チェックリストを .claude/skills/ に切り出す仕組み。SKILL.md は YAML フロントマター（機械可読メタデータ）+ Markdown（人間・エージェント向け指示）で、!git diff HEAD のようなシェル実行・Python スクリプト・ネットワークアクセスまで含められる。Anthropic がオープン標準公開後、Claude Code・Codex・Cursor・Gemini CLI など30+ ツールが同じ .claude/skills/ から同じ SKILL.md を読む普及。便利さと同じ、悪意あるスキル1個の射程が広い。公式警告「この機能は Claudeにコード実行権限を付与。信頼できる提供元に絞ること」が現状唯一の防御線。npm パッケージより危い理由は構造的欠陥3つ：1. データと指示の境界がない（LLM はシステムプロンプト・ユーザー入力・外部テキストを1本のトークン列として読む、プロンプトインジェクション未解決）；2. 承認は一度きり・持続（GIF 変換スキルをインストール時承認 1 回で、ファイル書き込み・ネットワークダウンロード・実行権限を無期限許可、作者がインストール後 SKILL.md 書き換えても最初承認継承）；3. マーケットプレイスに必須セキュリティレビューなし（タイポスクワッティング・ダウンロード数水増しも止める関所なし）。論文が脅威を7つに整理：配布・信頼（T1 サプライチェーン汚染・T2 同意悪用）実行時（T3 プロンプトインジェクション・T4 コード実行・T5 データ持ち出し）永続・横展開（T6 永続化・T7 マルチエージェント伝播）。急所は T4 コード実行（裏で外部 URL からバイナリ実行・ログは「要約」だけ）と T5 データ持ち出し（SSH 鍵・API キー・環境変数・コードベース全体外部送信）。T6 永続化（settings.json 細工・信頼ダイアログ前にコマンド走らせ・アンインストール後も効果残る）陰湿。確認済みインシデント5件：GIF 変換スキル裏で Medusa Locker ランサムウェア（T4・T2）・ClawHavoc キャンペーン 1,184 個改ざんスキル認証情報窃取マルウェア・PEP 723 経由後から依存差し替え・サイレント・エグレス 監査ログなしコードベース全体抜き（2026年2月）。現役エンジニア対策3つ：第一に .claude/skills/ 中身を信頼前に読む（リポジトリ信頼時点で allowed-tools が有効・白紙許可証サイン同義）；第二に managed settings に disableSkillShellExecution:true で !command をシェル実行禁止・バンドル済み管理下スキルは影響外・現実的な絞り方；第三に Meta Rule of Two「人間承認なしにエージェント同時持つのは機密データアクセス・信頼できない入力処理・外部通信のうち2つまで、3つ揃ったら人間レビュー挟め」をスキル選定判断軸に。残る T4・T5 はコンテナ/WASM サンドボックス化・外向き通信ドメイン制限まで行き着き、利用者はできるのが「実行環境隔離」「依存 lockfile 固定」まで。npm install を疑うのと同じ目で SKILL.md を見る習慣を今のうちに。

コードより先に、その周りの雑務をClaude Codeに渡したら開発が軽くなった

• URL: https://zenn.dev/rapls/articles/33a5f8af9c46ab
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: WordPress プラグイン個人開発で半年使ったClaude Codeの気づき：コードを書く時間よりも、リリース前の確認・readme・changelog・翻訳の抜けチェック・リリース後の確認といったコード周りの雑務にこそ時間が取られていた。雑務は手順を忘れやすく毎回ゼロから思い出す「思い出すコスト」が発生する。Claude Codeにコード周りの雑務を任せると、手順を文章で渡して下書きや確認結果を受け取り、最後は自分で確認してから出すという半自動フローが有効。リリース前チェックはSkill（/コマンド）にして毎回同じ確認が走るようにする。

詳細

WordPressプラグインの個人開発では、コード以外の雑務がコードへの集中を切る二重の損をもたらす。バージョン整合・readme更新・変更履歴・翻訳確認・告知などの雑務を実行中は前のコードの文脈が頭から抜け、戻ってから思い出す「思い出すコスト」が発生。Claude Codeに雑務を任せる場合、手順を文章で渡して下書きや確認結果を受け取り、最後は自分で確認してから使う半自動フローが重要。リリース前チェックはバージョン・readme・changelog・define定数の整合を確認；readme更新は変更点から該当節を下書き；changelog はコミットログからユーザー向けに翻訳；翻訳の抜けは.potと.poを突き合わせ；調べものはWebで、SNS告知文は媒体別に下書き；リリース後は公開ページ・配布版・タグの整合を確認。毎回やるものはSkill（スラッシュコマンド）にして/名前で呼べるようにする。Skill定義では description で「リリース直前に使う」と用途を具体的に書くと、Claudeが「いつ使うか」を正しく判断しやすくなる。allowed-tools で読み取りと grep のみ許可して勝手な書き換えを防ぐ。readme が10KB超えると parser の挙動がおかしくなるため、古い changelog を別ファイルに逃がして直近だけ残す。全部は任せず一番繰り返している雑務から一つずつ自動化し、最後の判断は手元に残す。

第2部：「お願い」から「仕組み」へ：Claude Code安全設計の実践

• URL: https://zenn.dev/taka4/articles/56ca5ecb455e83
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code CLIはデフォルトで多くの操作を自動実行できるが、意図しないgit reset –hard・.env書き換えのリスクがある。安全設計は「お願い」ではなく「仕組み」で実装。2層防御：Layer 1は permissions.deny（ネイティブ機能で Bash コマンド確認なしブロック）、Layer 2は hookify 宣言ルール（markdown で危険パターン検出）。設定レイヤー構造は グローバルユーザー→グローバルローカル→プロジェクト共有→プロジェクトローカル（下位が上書き、ただし permissions.deny はグローバル最優先）。Python実行許可と危険コードブロックのバランスは check-python-safety.sh で実現。パーミッションモード4種（default・accept edits・plan・auto）で操作確認プロンプトを制御。スタック別テンプレート用意で新規プロジェクト設定を高速化。

詳細

Claude Code は タスク渡すと自分でコマンド組み立て実行し、git reset –hard でコミット前変更消去・.env ファイル誤上書き・rm -rf で意図しないディレクトリ削除・os.system() 含む Python スクリプト実行といった事故のリスク。公式ドキュメント「Permission rules は Claude Code 自体が強制、プロンプト・CLAUDE.md の指示はモデルへの『お願い』であって Claude Code が何を許可するかは変わらない」。安全設計は「お願い」ではなく「仕組み」で実装。2層防御：Layer 1 は permissions.deny（ネイティブ機能で Bash コマンドを確認プロンプトなしでブロック）、Layer 2 は hookify プラグイン（markdown ファイルでフック宣言し正規表現で自由に拡張）。どちらか一方が機能しない環境でも最低限の安全性担保。設定レイヤー構造：~/.claude/settings.json（グローバルユーザー全プロジェクト共通）→ ~/.claude/settings.local.json（個人のみ gitignore）→ /.claude/settings.json（プロジェクト共有 git 管理）→ /.claude/settings.local.json（プロジェクトローカル gitignore）。基本的に下位レイヤーが上位を上書き、ただし permissions.deny はグローバルが最優先（プロジェクト側では解除不可）。permissions.allow は全レイヤーマージ（全て有効）。Python実行許可と危険コードブロックのバランス：python/python3 を allow で確認なし実行しつつ、フックが実行前にコード内容を静的解析して os.system()・subprocess.run()・shutil.rmtree()・eval()・exec()・import() といった危険パターンを検出・ブロック。検出時は exit code 2 で Claude Code が実行をブロック。パーミッションモード4種：default（ファイル確認・Bash 確認）・accept edits（ファイル自動・mkdir/touch/rm/rmdir/mv/cp/sed のみ自動）・plan（操作不可）・auto（自動許可原則、内蔵クラシファイアが危険と判断すればブロック）。settings.json で起動時デフォルトモード指定可。allow/deny 登録済みは全モードで有効。スタック別テンプレート（Python/TypeScript）用意で新規プロジェクト開始時に毎回設定一から作らず、cp ~/.claude/templates/{stack}/{CLAUDE.md,settings.local.json} .claude/ で完成。

Claude Codeのセキュリティ設定は「便利さを落とす作業」じゃない。AIに仕事を任せるための免許証だ

• URL: https://zenn.dev/taketsuyo/articles/72ba03bfae6216
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code のセキュリティ設定は「便利さを落とす作業」ではなく、「AI に仕事を任せるための免許証」。AI が間違えることより、間違った時に想像より広い権限を持っていたと後から気づくのが怖い。Claude Code は相談相手ではなく「作業者」に近い。permission を飛ばすと開発体験気持ちいいが危ない。permission・allow・ask・deny で「自由にやっていい」「聞いてからやって」「絶対に触らないで」を分ける。settings.json は AI 時代の作業ルールブック。秘密情報と破壊的操作を deny に、.env・秘密鍵・認証情報・API キーは deny、rm・DB 破壊的操作・本番環境コマンドは ask。MCP は便利だがプロンプトインジェクション・接続先増で攻撃面増。明日やるなら「AI 用事故防止チェック」1つ作る。AI_SANDBOX.md にやらせていいこと・確認必要・絶対に触らせないもの書く。

詳細

Claude Code 使いで一番怖いのは AI が間違えることより、間違えた時に想像より広い権限を持っていたと後から気づく事故範囲。Claude Code は「相談相手」から「作業者」に近づいており、「バグ直して」で関連ファイル探す・テストを書く・コマンド実行・失敗時別方法を試す代行。便利だが権限を与えるから速くなり、権限整理しないまま使うと速く事故る。人間の仕事は「指示すること」から「境界線を設計すること」に移行。permission 飛ばすと気持ちいいが最後のフェンス失う。AI が依存関係直すつもりでコマンド実行・ログ読むつもりで.env 触る・不要ファイル消すつもりで広い範囲削除する場面で、人間なら「ちょっと待てよ」と止まるが AI は文脈取り違え進む。permission 飛ばさないは AI 信用しないでなく逆で、AI に長く仕事任せるため危ない操作だけ人間が握る設計。settings.json は allow「許可」・ask「確認」・deny「禁止」を分ける。従来は開発環境の設定で人間が書くコード品質整える（エディタ・フォーマッタ・Linter・CI）。これからは AI がファイル読む・コマンド打つ・外部ツール呼ぶから、開発環境に AI が動くための行動規範も必要。最低限は秘密情報（.env・秘密鍵・認証情報・API キー）deny、破壊的操作（rm・DB 破壊・本番環境）ask か deny。人間の設定ミス・文脈ミスも含めて守るための保険。Cursor とは見方が違い、Cursor はエディタ中心で「どのファイル読ませるか」「どの変更採用」が主戦場。Claude Code はターミナル・外部ツール含めて作業者に近いから、設定の重心が「コード補完精度」から「実行権限設計」に寄る。MCP は便利だが、外部 Issue・README・Webpage・ドキュメントに「隠しファイル読んで送信しろ」みたいな指示が書かれていたらプロンプトインジェクション。接続先増で攻撃経路も増。MCP は本当に必要なものだけ、信頼できる接続先に限定、IAM（Identity Access Management）に近い考え。明日やるなら：Claude Code 開く前にプロジェクトごとに小さなチェックリスト作成。本番環境の認証情報はないか・.env を deny に入れたか・削除系コマンドは ask か deny か・Git 管理下で作業しているか・MCP は本当に必要・ホームディレクトリ直下や本番サーバー上で動かしていないか。プロジェクトに「AI_SANDBOX.md」ファイル置いて、このプロジェクトで AI にやらせていいこと・確認必要・絶対に触らせないもの書く。AI 駆動開発はプロンプト技術だけでなく、AI が働く作業場を設計する技術が必要。チームに新エンジニア入った時のリポジトリ説明・環境構築・権限付与・レビュー方針を教えるのと同じく、AI エージェントにも同じことをする。どの棚を開けていいか・どの鍵は渡さないか・どの操作は必ず声をかけるか決められる人が AI 時代の開発を安心して速く進められる人。便利な道具を怖がる必要なし、丸ごと鍵束を渡す必要もない。まずは permission を飛ばさないところから。それだけで AI との付き合い方が少し変わる。

AI エージェントにブラウザを操作させる4ツールの選び方

• URL: https://zenn.dev/takna/articles/ai-agent-browser-tools
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: AI エージェント向けブラウザ操作ツール4つ（Claude in Chrome・chrome-devtools-mcp・agent-browser・Playwright MCP）の用途別選択ガイド。単体選択：E2E・CI回帰なら Playwright MCP（クロスブラウザ一択）、Lighthouse 監査なら chrome-devtools-mcp、ログイン必須画面なら Claude in Chrome、軽量・高速なら agent-browser。組み合わせ例：操作 Claude in Chrome or agent-browser・品質ゲート chrome-devtools-mcp・CI回帰 Playwright MCP。4ツール比較で提供元・形態・主軸・ブラウザ・Lighthouse・認証・CI・トークン効率・料金・導入で各軸異なる。セキュリティは各ツール詰める点あり（認証範囲・バイナリ検証・権限管理）。

詳細

4つのブラウザ操作ツール選択軸：単体で選ぶなら用途別に異なる。Firefox/WebKit 含むクロスブラウザ E2E・CI 回帰なら Playwright MCP（一択）。Lighthouse 監査・メモリリーク・パフォーマンス診断なら chrome-devtools-mcp（診断機能最厚）。ログイン必須（SSO/OAuth/2FA）の画面操作・動作確認なら Claude in Chrome（純正・権限 UI）。Chrome での AI 操作を軽量・高速・トークン節約なら agent-browser（CLI ファースト）。組み合わせ構成例：操作 Claude in Chrome または agent-browser・品質ゲート chrome-devtools-mcp・CI 回帰 Playwright MCP；Vercel/Next.js 中心：操作 agent-browser・診断 chrome-devtools-mcp；書いた直後同セッション確認：Claude in Chrome 単体または chrome-devtools-mcp(auto-connect)併用。4ツール比較表で Google Chrome・Vercel Labs・Microsoft 各提供元・Chrome 拡張・MCP(CDP)・CLI(Rust)・MCP(Playwright) 形態・操作・診断・操作・自動化テスト各主軸。Chrome/Edge・Chrome のみ・Chrome Chromium 系・Chromium/Firefox/WebKit/Edge クロスブラウザ対応。Lighthouse ◎/◎/✕/✕・ログイン継承 ◎/◎/◯/△・CI 無人実行 ✕/△/◎/◎・トークン効率 中/中/◎/中・前提料金は要 Anthropic 有料プラン / 無料 OSS / 無料 OSS / 無料 OSS。GitHub スター数・Open Issues・初回公開日・MCP 実績で規模・新しさ表示。agent-browser「37% トークン削減」「95% 成功率」は Vercel 内部/追随メディアベンチで独立第三者再現未確認・本番採用事例未発見。セキュリティは Claude in Chrome が実ログイン状態共有でオペレータ権限・プロンプトインジェクション管理要点；agent-browser にバイナリ配布チェックサム検証ない Issue；chrome-devtools-mcp に/tmp symlink following 脆弱性 CVE-2026-53765；Playwright MCP も CI 上シークレット扱い注意。組織導入は権限・シークレット管理前提で評価。

Claude Code と Codex を使い比べて見えた設計思想の違い

• URL: https://zenn.dev/tark_ann/articles/e8b09c6db73bfb
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code と Codex を使い比べて見えた設計思想の違い。Claude Code は形成した作業仮説（plan）との整合性維持傾向、Codex はコードや実行結果との整合性維持傾向。LLM は「次に来る単語を予測」学習ベース、Transformer Attention 機構で文脈処理。「文脈として自然な出力」へ寄りやすい。グラウンディング重視：Claude Code は「Explore first, then plan, then code」で計画が後続に強い影響・調査から形成した仮説のまま推論進む傾向。Codex は「read, edit, run」で「goal・context・constraints・completion criteria」重視・現コード・実行結果優先。現在の使い分け：調査・PR→Claude Code、実装・リファクタリング→Codex。

詳細

Claude Code 1本からCodexに浮気、Opus 4.7 体験が悪く気づいたこと。設計思想の違いが振る舞いを起こす。LLM は「次に来る単語を予測」学習、Transformer Attention 機構で文脈内の単語関係処理。「文脈として自然な出力」へ寄りやすい。Anthropic/OpenAI 共通発展過程だが、Coding agent はグラウンディング重視、両社とも「コード探索・ツール実行・テスト実行・実行結果確認」重視。Claude Code は「Explore first, then plan, then code」で計画が強い影響、調査から形成した仮説のまま推論進み、実装が前提と乖離時も整合性維持しようとする傾向。既存仕様調査で「コード読んでいませんでした、コード上は実際違いました」と返答されたケース。Codex は「read, edit, run」で「goal・context・constraints・completion criteria」重視、現コード・実行結果を優先。既存仕様調査で「ユーザーと違う箇所判明、2点確認させてください」と返答、調査結果に具体コード・そこからの読み取りを提示。現使い分け：調査・技術検討・PR→Claude Code（選択肢を広げる・問題空間探索）、実装・リファクタリング・修正→Codex（解空間実行・コードベース検証）。PR本文は Claude Code で、人間が理解しやすい粒度に圧縮、Codex は網羅的に列挙。両者を競合でなく、異なる特性を持つ開発パートナーとして使い分け。

CLAUDE.md のトリセツ — 200行で Claude Code の動きが変わる

• URL: https://zenn.dev/tatsuqumo/articles/04266f36508023
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: CLAUDE.mdは毎セッションClaudeが見る情報なので、200行という制約の中で効果を最大化する工夫が重要。CLAUDE.mdはシステムプロンプトではなくuser メッセージとして注入され、セッション開始時にロードされた後は毎ターンのコンテキストとして消費されるため、長くなるほど会話文脈と競合して指示遵守率が低下。200行に収めるには、特定ファイル向けルールは.claude/rules/に、手順書・ワークフローはskillsに、リファレンス情報はskillsに移す。CLAUDE.mdは具体的に書き、構造化し、毎セッションで知っておくべき情報のみ記載。

詳細

CLAUDE.mdの配置場所はスコープを決定：マネージド（組織全体）・ユーザー（全プロジェクト共通）・プロジェクト（チーム共有）・ローカル（個人のプロジェクト固有）。読み込みは上から下で累積的に結合、ローカルが優先度高。ディレクトリツリーを遡ってCLAUDE.mdを発見・結合、同じ階層ではCLAUDE.md→CLAUDE.local.mdの順、サブディレクトリはオンデマンド読み込み、HTMLコメントはコンテキスト注入前に除去。200行を超える原因は何でも詰め込む・曖昧な指示・矛盾する指示・お願いで強制・放置して腐る。情報の逃がし先：特定ファイル向けルール→.claude/rules/、手順書・ワークフロー→skills、リファレンス→skills、個人設定→CLAUDE.local.md、全プロジェクト共通→~/.claude/rules/。CLAUDE.mdの指示は具体的・検証可能に、マークダウン見出しと箇条書きで構造化。.claude/rules/でpathsでスコープを絞ると該当ファイル扱う時のみ読み込み。@importで外部ファイル取り込み可能。/initでCLAUDE.mdを自動生成、既存AGENTSなど他ツール設定も読み取り。auto memoryはClaudeが自分でメモを取る仕組みで、MEMORY.mdの先頭200行を毎セッション読み込み。CLAUDE.mdに書いたのに従わない時は/memoryで確認、指示が具体的か見直し、矛盾がないか確認。/compact後にサブディレクトリのCLAUDE.mdは再注入されず次アクセス時再読み込み。モノレポでは claudeMdExcludes で除外可能。

Claude Code を使いこなすために学んだこと：CLAUDE.md・Skills・MCP

• URL: https://zenn.dev/tetsu_don/articles/7b11393600dcf0
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: データエンジニアが Claude Code 使いこなすために学んだ3つ：CLAUDE.md でプロジェクトルール毎セッション自動読込、Skills で よく使う作業をコマンド化、MCP で BigQuery・Playwright 直接連携。毎回同じ説明・同じ指示繰り返す課題を解決。/init で CLAUDE.md 雛形自動生成・/create-specs で仕様書一式自動生成・/spec-review で抜け漏れリスク指摘・/code-review で品質サマリー。BigQuery MCP + Playwright MCP 組み合わせで「クローリング→BigQuery ロード」が自然言語1文で完結。ELT パイプラインの Extract→Load が劇的に短縮。

詳細

データエンジニアが毎回説明・仕様書作成・レビュー指示を繰り返す課題に直面。CLAUDE.md でプロジェクト概要・技術スタック・コーディングルール・コマンドを一度書いたら毎セッション自動読込。/init で雛形自動生成・育てながら使うスタイル（新しいルール追加・仕様確定・修正繰り返し）。Skills は グローバル（どのプロジェクトでも使える）・プロジェクト固有（このプロジェクトのみ）に分類。/create-specs で 要件定義書・機能設計書・リポジトリ構成・tech スタック・DB スキーマ・API 設計を自動生成（不要なら作成しない・TODO は記載）。/spec-review で 仕様書を横断的に読んで抜け漏れ・矛盾・リスク・冪等性未設計・JSON パース失敗時リトライ漏れ等を指摘・docs/spec_review.md に出力。/code-review で 型ヒント・責務分離・エラーハンドリング・セキュリティ・BigQuery 関連・テスト・可読性を観点に評価・docs/code_review.md に出力。/spec-review→実装→/code-review サイクルで冪等性バッチチェック維持・型ヒント・責務分離・セキュリティ・テスト全項目 OK 達成。MCP は Host（Claude Code AI）・Client（Host 内の Server 通信部品）・Server（ツール・データ提供）の3層構造。BigQuery MCP（Google Cloud 公式Toolbox）でテーブル一覧・スキーマ自動確認・正確なコード生成。Playwright MCP でページ構造確認・セレクタ自動生成。両者組み合わせで Playwright：ページ構造・データ取得→BigQuery MCP：スキーマ確認・テーブル作成・ロード で数時間→1文に短縮。

Claude Code 週次アップデートまとめ（2026/06/20週）

• URL: https://zenn.dev/tottoko_hamu/articles/2026-06-20-090000
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code 週次アップデートまとめ v2.1.177～v2.1.183。破壊的 git コマンド自動ブロック（v2.1.183）でgit reset –hard・git checkout –・git clean -fd・git stash drop・git commit –amend 自動ブロック。Fable 5 アクセス全停止（v2.1.177）で米国政府輸出規制指令で外国籍ユーザーへ禁止・Opus 4.8 自動切り替え。Tool(param:value) パーミッション構文（v2.1.178）でツール入力パラメータ値レベルで allow/deny（Agent(model:opus) で Opus サブエージェント起動だけブロック）。その他変更：ネスト.claude/skills・auto mode サブエージェント分類器・ストリーム中断パーシャルレスポンス・/config key=value 構文・ネットワークドライブ書き込み修正・破壊的コマンド自動ブロックで「エージェント勝手に消す」リスク低下。

詳細

Claude Code 週次アップデート CHANGELOG まとめ v2.1.177～v2.1.183。破壊的 git コマンド自動ブロック（v2.1.183）：git reset –hard・git checkout – .（ワーキングツリー変更全破棄）・git clean -fd（追跡外ファイル強制削除）・git stash drop・git commit –amend（セッション内エージェント作成でない当該セッション適用）が「そのコマンド実行するよう明示指示」ない限り自動ブロック。インフラコマンド terraform destroy・pulumi destroy・cdk destroy も特定スタック明示指示ない限りブロック。ユーザー側設定変更不要、エージェントがブロックされて確認切り替わり。「なぜかエージェントがコマンド実行止めた」が増えるかもだが、バグでなく意図的ガード、private ワークツリーでも同様。Fable 5 アクセス全停止（v2.1.177）：米国政府 2026-06-12 輸出規制指令発出、Anthropic は外国籍ユーザー（社員含む）への Fable 5/Mythos 5 アクセス禁止指示に従って一時停止。Fable 5 選んでも Opus 4.8 自動切り替わり。Anthropic は声明「この措置は誤解に基づくもの」で見解の相違あり。現時点ユーザー側できることなし、いつ解除されるか不明。Tool(param:value) パーミッション構文（v2.1.178）：パーミッション粒度が上昇、ツール単位でなく入力パラメータ値レベルで allow/deny 指定可。Agent(model:opus) を deny に設定すると「Opus モデルサブエージェント起動だけブロック」な細かい制御。Agent ツール自体は引き続き使え、コスト高い Opus だけ禁じるユースケース。settings.local.json に Agent(model:opus) を deny リストに追加。ドキュメント v2.1.178 時点使用可能だが実機確認未、公式 changelog で確認推奨。その他変更：ネスト .claude/skills サポート（サブディレクトリのスキル自動読み込み・同名衝突時 : 形式両方参照）、auto mode サブエージェント分類器評価（ブロック対象アクション未確認実行抜け穴修正）、暗黙的チームサポート（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で事前作成なしに name パラメータで直接チームメイト起動）、ストリーム中断時パーシャルレスポンス保持、WSL2 マウスホイール修正、Linux サンドボックス glob パフォーマンス改善、/config key=value 構文（例：/config thinking=false）、Bun ランタイム 1.4 アップグレード、ネットワークドライブファイル書き込み修正、プロンプトキャッシュ読み込み修正（カスタム URL/Foundry）、非推奨モデル警告、attribution.sessionUrl 設定（Web・Remote Control セッション Claude.ai セッションリンク除外）、JetBrains IDE ターミナルちらつき修正。Claude Design × Claude Code 双方向連携・/design-sync コマンド で Adobe・Base44・Canva・Gamma・Lovable・Miro・Replit・Vercel・Wix 9ツール外部連携。破壊的コマンドブロック導入で「エージェント勝手に消す」リスク低下。次の問いは「どこまで自律させるか・どこで人間介在かの設計」に移行。

[生成AI活用通信]社内のAI活用、どんどん進んでます[2026年4月~5月]

• URL: https://zenn.dev/tsukulink/articles/23d26606f449e4
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: ツクリンクではAIラボを立ち上げ、社内生成AI活用を継続推進。委員会で毎週AIツール活用状況・情報共有・設定改善を実施。2026年4月後半～5月の活動報告：Claude Codeのサンドボックス環境整備でgit worktree利用時のgit実行失敗に対応、git関連コマンドをサンドボックス外で実行；非エンジニアとエンジニア有志でモブプロ会実施で、コミュニケーション課題やセキュリティ不安を発掘；REVIEW.mdをリポジトリに追加し日本語コメント・レビュー観点をカスタマイズ；Claude Code Routinesでスケジュール・API呼び出し・イベント応答による自動実行を活用；Tips共有ではClaude Design・/resumeコマンド・fewer-permission-promptsスキル・Superpowersプラグイン・Claude Code ベストプラクティスなど紹介。

詳細

ツクリンク社のAIラボはAI活用の継続推進を担当。サンドボックス設定でgit worktreeを使った開発時のgitコマンド実行がサンドボックス内で失敗する課題に直面し、git関連コマンドはサンドボックス外で実行するよう見直し。.claude/settings.json に設定を追加してサンドボックス活用を推進。非エンジニアとエンジニアのモブプロ会では、何が分からないのか質問しづらい、エンジニアに聞いていいか不安、ペアプログラミング中のAPIキー・認証情報・情報公開範囲といったセキュリティ不安など多くの声が出た。REVIEW.mdはClaudeのCode Review機能やDevinのDevin Reviewで参照され、レビュー観点・方法をカスタマイズ可能。日本語でのコメント実施とレビュー観点を明示。Claude Code Routinesはプロンプト・リポジトリ・コネクターを設定すれば、スケジュール・API呼び出し・イベント応答で自動実行され、PCを閉じていても動作継続するメリット。Tips共有は毎日AIラボのSlackに新機能情報が集約され、週次MTGで共有。Claude Design でスライド作成；/resumeコマンドで過去セッションのシームレス再開；fewer-permission-promptsスキルで過去セッションをスキャンし頻繁なBash/MCP呼び出しをallowlist に自動追加；SuperpowersプラグインはTDDベースで品質高いコードを生成；Claude Code Agent Viewで複数サブエージェント並列作業を一元管理；claude agentsコマンドでAgent Viewを利用。

Claude Design ↔ Claude Code を行き来して作った資産ポートフォリオダッシュボード

• URL: https://zenn.dev/unsoluble_sugar/articles/fd73c7b67d80ce
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Design と Claude Code 行き来して資産ポートフォリオダッシュボード完成。自分の資産を全体で見渡せ、複数口座に散らばった国内株・米国株・投資信託・金を1画面で把握。証券アプリのログイン手間・ノイズ排除。Claude Design でプロトタイプ・デザイン方向決め、Claude Code で実データ・本番仕上げ。デザインは「明るい白基調・低彩度・情報密度高め・装飾最小・色は意味にのみ使用」。実装は ランタイム dc-runtime・Vanilla JS・素の CSS・GitHub Pages・GitHub Actions CI/CD。メンテナンスコスト最小化でビルドレス・フレームワーク非依存・python3 -m http.server で即座に動作。

詳細

自分の資産ポートフォリオを1画面で見られるダッシュボード開発。国内株・米国株・投資信託・金が複数口座に散らばり、証券アプリはログイン毎に必要・ノイズ多・合計額把握困難。家計簿アプリもAPI煩雑・カスタマイズ難。シンプルでオープンに持ち数量・割合変遷・投資額推移を公開する人を増やしたいという背景。元手30万円から5年運用で1,000万円超・評価損益+300万円でそれなりに参考価値あり。Claude Design が使いやすくなったのをきっかけに開発。二段構え：Claude Design で大枠デザイン・動くプロトタイプ・配色・レイアウト・コンポーネント方向固める；Claude Code で実データ・本番仕上げ・内部実装リファクタ・CI・細かな挙動調整。デザインと実装の分担で進捗効率向上。Claude Design は作る前に質問してくる確認フォーム：「誰に見せるか」「どれくらい動かすか」「通貨表示」「出す指標」「騰落の色」「案の数」で要件明確化。実データ CSV（Shift-JIS 文字化け問題、Claude Design 側でデコード）を複数回に分けてアップロード、米国株ドル円換算・投信口数表示・金グラム単位など実物の歪みをプロトタイプ段階で把握。3案（クラシック・カード・一覧）を並べて比較、案A採用。インタラクション（ドーナツドリルダウン・％ラベル・為替ライブ更新）をプロトタイプ段階で詰める。デザイン方針：騰落色は国内標準（プラス赤・マイナス緑・変化グレー）・カテゴリ色一貫運用・飾りの色は足さない。技術スタック選定：フレームワークなし静的サイト・Vanilla JS・素の CSS・GitHub Pages・GitHub Actions でCI（株価取得・スナップショット・OGP生成・デプロイ）・為替・金・株価 API キー不要。dc-runtime（Claude Design 生成物 support.js の テンプレート）そのまま引き継ぎ。ビルドレスで メンテナンスコスト最小化、python3 -m http.server で即座動作・file:// で直接開いても動作・GitHub Pages も同一コード。ロジック mixin で分離、js/ に大半実装・window.PortfolioLogic メソッド集登録。インライン Component 末尾で合成、見た目は styles.css・ロジックは js/・画面構造は テンプレートで分離。

Claude Code の channels 機能で「Claude Code を」AI 社員にする

• URL: https://zenn.dev/yamitzky/articles/08a2493b527b4f
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: Claude Code の channels 機能でAI社員をマルチエージェント化。Discord チャネルごとに独立した Claude Code セッションを動かし、Discord からメッセージを AI 社員同士がやり取りしながら応答。土台に Claude Code の channels（ターミナル外で起きたことを Claude Code セッションに push 型で流す MCP サーバー機能）があり、その上に Discord・claude-peers channel が乗る。channels は capability 宣言で MCP サーバーが channel に、notifications/claude/channel 投げで Claude セッションに割り込む。Discord（公式channel）は人間の入口、claude-peers（OSS）は セッション間会話用ブローカー。受付セッションが Discord から各担当セッションへ振り分け。

詳細

channels は ターミナル外で起きたこと（Discord・Telegram など）を Claude Code セッションに push 型で流す機能で、Research Preview。1 channel = 1 MCP サーバー。server 定義で capabilities に experimental『claude/channel』宣言でOK。notifications/claude/channel 投げで Claude セッション内に割り込み。自作 channel 試す時は –dangerously-load-development-channels 付きで起動。公式実装は Telegram・Discord・iMessage のみ対応。2つ channel 組み合わせ：Discord（公式、双方向、ローカルAPI polling で新発言をとして到達）+ claude-peers（localhost:7899 ブローカー介して localhost Claude Code 同士発見・メッセージ交換）。Discord channel は接続数多くしすぎず受付セッション1つだけ、公式 fork で振り分け処理追加、chat_id から作業ディレクトリ対応表JSON、discord-router が claude-peers 使い分配。各セッション作業ディレクトリに CLAUDE.md で役割と固有ルール、置き場所で社員人格表現。実際の流れ：人間が Discord 「一般」に書き込み→受付セッションが担当作業ディレクトリへ解決→claude-peers 経由で送信→担当セッションに形で到達。メリット：Claude Code なので仕組みわかりやすい・セッション・コンテキスト圧縮・モデル・CLAUDE.md・Agent Skill・MEMORY.md 全機能使える・ultracode・Web検索・多分Claudeサブスク内で動く。デメリット：各セッション フル Claude Code プロセスで重い・セッション数だけメモリ消費・zellij 経由で不安定・再起動でコンテキスト揮発。「◯人の壁」はメモリ不足で採用停止。Hermes Agent も併用で Claude Code 専用部分分割・カジュアル用途 Hermes Agent 。