AIセキュリティを非エンジニアが非エンジニアなりに整理してみた

• URL: https://blog.cloudnative.co.jp/articles/3873617f2dbe80df
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AI セキュリティを情シスが扱うべき 4 分類で整理。シャドーAI・データ保護・アクセス権（RAG/NHI）・ガードレールの軸で、自社の現在地と施策優先順位を明確化。

詳細

「AI セキュリティ対策」の広がりを 4 分類に絞って整理。(1)シャドーAI：社員の無許可外部 AI 利用を CASB で可視化・安全な法人向けプラン提供（禁止ではなく代替）。(2)データ保護・AI サプライチェーン：入力データの保管期間・再委託先・学習オフ手続きを確認。(3)アクセス権・認証認可：RAG（社内文書 AI 参照時のアクセス権すり抜け防止）＋ NHI（Non-Human Identity：AI 自身の権限管理）をセット設計。RAG は既存権限棚卸しが本筋。NHI は「AI はどの権限で動くか」を人間同等に管理（最小権限・失効管理・責任者明記）。(4)AIガードレール：入力チェック（プロンプトインジェクション検知）・出力チェック（情報混入・不適切表現確認）は相対的に得意だが、ハルシネーション防止は RAG＋人的確認が本筋。「ガードレール=完全防止」ではない期待値合わせが重要。

Salesforce 2026年6月セキュリティ強化要件への対応（Okta / Entra ID）

• URL: https://blog.cloudnative.co.jp/articles/3883617f2dbe8022
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Salesforce 2026 年 MFA 必須化（特権ユーザーはフィッシング耐性必須）への対応。SSO 連携時は IdP 側で認証方式信号（AMR）を Salesforce に渡す設定が必須。Okta 公式アプリなら基本自動対応。

詳細

Salesforce 2026-06-22 Sandbox・2026-07-01 本番で特権ユーザー向けフィッシング耐性 MFA（FIDO2/WebAuthn/パスキー/証明書認証）必須。SMS・TOTP は不可。2026-07-20 一般ユーザー向け標準 MFA 必須。REST API PKCE 対応期限 2026-06-25。特権ユーザー定義：System Administrator プロファイルまたは Modify All Data/View All Data/Customize Application/Author Apex 権限保持者。Okta は OIN 公式アプリなら自動対応（フィッシング耐性ポリシー割り当てのみ）。カスタムアプリの場合 AMR 属性手動追加。Entra ID は条件付きアクセスでフィッシング耐性 MFA 要求し SAML トークン authnmethodreferences クレームで信号渡す。ただし細かい粒度情報伝達は Microsoft 調整中（2026-06-09 時点）。Sandbox 検証後本番適用。

Azure サブスクリプション作成者の退職で請求管理者が消える問題と、その予防策

• URL: https://blog.cloudnative.co.jp/articles/azure-subscription-billing-owner-retirement-risk
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Azure サブスクリプション作成者退職時の請求管理リスク。Azure RBAC Owner と請求管理者権限は別レイヤー。Account Administrator・Billing profile owner・Invoice section owner の棚卸しが必須。

詳細

Azure Owner は存在だがコスト・支払い変更不可の問題。リソース管理権限（Azure RBAC Owner/Contributor/Reader）と請求管理権限（Account Administrator・Billing roles）は別。MOSP（pay-as-you-go）では Account Administrator が請求権限の主体。MCA/Azure Plan では Billing account・Billing profile・Invoice section で role 分割。作成者が退職・Entra ID 削除されると請求側の所有者が無効になり、未払い・サブスクリプション削除のリスク。復旧時は billing account type 確認→Billing properties 確認→IAM 確認→退職者状態確認→移譲先準備の 5 段階。実務ハマりは同意文にアクティブなグローバル管理者必須（有資格では NG）・IAM 付与タイミング誤ると譲渡NG。対応例：ダミー従量課金サブスクリプション作成→支払い方法登録→IAM 付与→サポート代理譲渡→ダミー削除。Microsoft Partner Agreement など契約種別で運用形態が異なるため、事前の権限二重化が重要。

困る情シスあるある：「止める人」に見えないための7つの伝え方

• URL: https://blog.cloudnative.co.jp/articles/it-department-communication-aruaru
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: 情シスが「困る部署」から「相談される部署」に見られるための7つのコミュニケーション改善。「ダメです」ではなく条件付き進め方を示す、判断基準の透明化、一次確認絞り込み、暫定対応提案が重要。

詳細

情シスが見落としがちな7つの問題。(1)「ダメ」だけの返答→条件付き進め方示唆が必要。(2)相談が仕事増に見える→一次確認 5 項目に絞り「必要段階で一緒に進める」と返す。(3)判断基準不透明→扱う情報・利用者・権限管理・ログ・契約・AI 利用 6 軸を共有。(4)期限軽視→暫定対応と正式対応を分離。(5)専門用語→業務影響に一段翻訳（MFA 必須化→本人確認追加、DLP→意図せぬ外部出を防止など）。(6)例外対応ブラックボックス→条件・承認者・期限・見直しの 4 要素明文化。(7)返答遅い→完全答出前に一次回答と進捗見通し伝達。本質は「止める」ではなく「どこまで進めるか」を一緒に整理すること。新 SaaS・AI 活用・外部連携が増える中、事業部門が安全に動ける仕組み設計が情シスの新たな役割。

そのMCPサーバーは安全か危険か。信頼性を見極める実務フレームワーク｜出所検証・脆弱性スキャン・第三者監査・ベンダー認証

• URL: https://blog.cloudnative.co.jp/articles/mcp-server-security-evaluation-2026
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: MCP サーバーの安全判断は「出所→スキャン→脆弱性照合→ベンダー認証→運用統制」の 5 層フレームワークで。単一シール不在・公式登録=安全でなく、多層判定が実務解。

詳細

MCPサーバーは誰でも作成・公開可。公式Registry は出所検証のみ・コード監査は外部委譲。MCP固有リスク：ツールポイズニング（記述子埋込指示）・Rug Pull（承認後記述子変更）・クロスオリジン昇格（ツールシャドーイング）・プロンプトインジェクション・秘密漏えい・サプライチェーン。OWASP MCP Top 10（v0.1ベータ）で体系化中。5レンズフレームワーク：①出所（逆DNS・GitHub/ドメイン所有権・Docker commit pin・cosign署名）②スキャン（MCP-Scan・ツール記述子ポイズニング検査・Tool Pinning）③第三者監査・脆弱性DB（CSA mcpserver-audit・vulnerability-db・CVE採番）④ベンダー認証（Microsoft MCP server certification は継続監視）⑤運用統制（最小権限・短命トークン・IdP認可一元化・managed-mcp.json許可リスト）。赤信号：発行元不明・無署名・過剰スコープ・長命資格情報・承認後変更。緑信号：検証済み発行元・Tool Pinning・最小権限・活発保守・ベンダー認証済。導入前評価→導入時最小権限→運用中監視。標準は preview/beta が多く単一認証なし・レジストリ断片化のため重ね判定が正解。

Okta for AI Agents とは - 公式情報から読み解いてみた

• URL: https://blog.cloudnative.co.jp/articles/okta-ai-agents-overview
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Okta for AI Agents は AI エージェント専用 ID 基盤。Discover・Onboard・Protect・Govern で検出・登録・保護・ガバナンスを一気通貫実施。複数システムまたぐ未管理エージェントの検出と最小権限制御が特徴。

詳細

AI エージェント増加時の管理課題：データ持ち出し・認証情報漏れ・SaaS 組み込み AI 過剰権限の 3 パターン。共通課題は「誰の責任・どのエージェント・どのデータ・どの権限」の見えないこと。Agentic AI フレームワークで「どこに存在・何に接続・何ができるか」の 3 層を人間同等のアイデンティティとして扱う。Discover：ISPM + SAM（Chrome 拡張）でブラウザ OAuth グラント分析・未管理エージェント検出＋SaaS 内 AI 検出・過剰権限洗い出し。Onboard：検出エージェントを Okta 内専用ディレクトリに ID 登録、オーナー・部門・利用目的・アクセス先メタデータ付与。既存 IdP 置き換え不要（OIDC/SAML で併用可）。Protect：リソースタイプ・スコープ定義で最小権限設計＋agent deactivation（キルスイッチ）で即時遮断。Govern：System Log で活動記録・SIEM 連携で監視。Salesforce Agentforce・Amazon Bedrock・ServiceNow AI Platform プリビルト連携。

Steering Claude Code: skills, hooks, subagents and more | Claude

• URL: https://claude.com/ja/blog/steering-claude-code-skills-hooks-rules-subagents-and-more
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Code 指示のための 7 方式：CLAUDE.md・Rules・Skills・Subagents・Hooks・Output styles・System prompt append。各方式は負荷・永続性・権限が異なり、タスク性質に応じた使い分けが効率化の鍵。

詳細

7 指示方式の使い分け。CLAUDE.md：ビルド・ディレクトリ・コード規約・チーム規範→200行以内・オーナー定義・path-scoped subdirectory で team 分離。Rules：.claude/rules/ markdown・path スコーピング（src/api/** など）で条件付き読み込み→ファイル横断的な制約向け。Skills：.claude/skills/ folder・名前+説明は常時読込・本体は呼び出し時読込→deploy/release/review 手順書向け。Subagents：.claude/agents/ yaml frontmatter→独立 fresh context 実行・中間結果は返さず最終結果のみ→deep search/log analysis 等で main conversation 非汚染。Hooks：settings.json 登録・command/HTTP/mcp_tool/prompt/agent 5 種類・deterministic 実行→file edit/tool call/session start イベント時トリガー・外部コンテキスト低コスト。Output styles：決定論的出力フォーマット。System prompt append：最後の手段。各方式の context cost・compaction 挙動・権限を図表で判定。monorepo では path-scoped rule + 各 team 固有 CLAUDE.md で token 効率化・developer 無関連 context 非読込。security/compliance の組織標準は centrally managed CLAUDE.md で MDM deploy・exclusion 不可。

[アップデート] AWS Glue Data Catalog がビジネスコンテキストとセマンティック検索をサポートしたので試してみました（プレビュー）

• URL: https://dev.classmethod.jp/articles/20260622-glue-data-catalog-business-context
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: AWS Glue Data Catalog にビジネスコンテキスト・セマンティック検索機能追加(プレビュー)。用語集(glossary)で「アクティブユーザー」等業務概念に標準定義。アセットへの関連付けでテーブルが「何を表すデータか」表現。セマンティック検索(search-assets) API でテーブル名でなく業務コンテキスト意味から検索。カスタムメタデータ・スキルアセットで利用ルール・結合パス追加文脈。AI エージェント(MCP/Agent Toolkit)利用も想定。対応リージョン：米国東部2・西部・欧州アイルランド。

詳細

Glue Data Catalog 従来は テーブル名・カラム名等テクニカルメタデータ中心。今回アップデートで業務コンテキスト付与可能。背景：AI エージェント が信頼できる定義に基づいて推論できるようデータに業務コンテキスト必要。

3 つのコア要素。①用語集(glossary)・用語(glossary term)：「アクティブユーザー」業務概念に標準定義。②アセット関連付け：用語をテーブル紐付けで「何を表すデータか」表現。③セマンティック検索(search-assets API)：テーブル名でなく業務コンテキスト・説明文の意味から検索。

追加機能：カスタムメタデータ(form type)・スキルアセット で利用ルール・結合パスといった文脈付加。MCP 対応エージェント・AWS Agent Toolkit 利用想定。記事検証は glossary→関連付け→セマンティック検索。

前提：Data Catalog テーブル登録済み・glue:CreateGlossary/CreateGlossaryTerm/AssociateGlossaryTerms/Search/GetAsset 権限・検証リージョン us-east-1。マネジメントコンソール UI 実装なし(プレビュー)、aws CLI コマンド利用。検証：S3 bucket→glue database→table(sales_transactions 等)作成→glossary term 定義→search-assets で意味ベース検索実行。

Claude Code v2.1.184〜v2.1.186 の主要アップデート

• URL: https://dev.classmethod.jp/articles/20260623-cc-updates-v2-1-186
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Claude Code v2.1.185〜v2.1.186(2026-06-20〜22)の主要アップデート。新機能：claude mcp login/logout で対話メニュー不要な認証、/workflows にステータスフィルタリング、iTerm2 チームメイト表示、/plugin の Skills セクション追加。修正：マシンスリープ復帰後のストリーミング失敗解消、named サブエージェント生成時の权限ルール未適用修正、Chrome タブグループ分離。改善：API 応答待機表示の緩和(10秒→20秒)、MEMORY.md インデックスコンパクト化促促。

詳細

Claude Code v2.1.185(2026-06-20)・v2.1.186(2026-06-22)アップデート。v2.1.184 は npm 未公開で欠番のため対象外。

新機能：claude mcp login/logout コマンド追加で対話的 /mcp メニュー不要。CLI から MCP サーバーへ認証ログアウト可能。–no-browser で stdin リダイレクト対応し SSH 越しでも認証完了可。/workflows ステータスフィルタリング追加(f キー)。/login に AWS 認証情報更新オプション(awsAuthRefresh 設定時)。iTerm2 をチームメイト表示先に指定可(auto mode で it2 CLI 未検出時は警告)。/plugin Installed タブに Skills セクション追加でスキル確認容易化。

セキュリティ修正：named サブエージェント生成時に Agent(type) の deny ルール・Agent(x,y) の許可タイプ制限が適用されていなかった問題を解消。–tools フィーチャーゲート対象ツール通過を修正(冷却初回起動でフラグ読み込み前の通過を防止)。Chrome タブグループ分離の未適用を修正(in-product 権限ゲート OFF 時の並行セッション)。

改善：ストリーム停滞表示「No response from API」→「Waiting for API response」に文言変更。無応答検出タイミング 10 秒→20 秒に緩和。MEMORY.md インデックスがサイズ上限接近時にコンパクト化をエージェントに促すように。スキル frontmatter キー記法柔軟化(display-name・default-enabled・fallback 等)。

[アップデート] Amazon WorkSpaces Applications でWindowsクライアントOSのBYOLが可能になりました

• URL: https://dev.classmethod.jp/articles/amazon-workspaces-applications-windows-client-byol
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Amazon WorkSpaces Applications Windows クライアント BYOL サポート開始。AppStream 2.0 が WorkSpaces 統合による適用範囲拡大。占有ハードウェア環境必須・Microsoft VDA E3/E5 ライセンス別途必要。リージョンごと条件：非 GPU 最低 50 インスタンス/月または GPU 最低 AlwaysOn 4・AutoStop 20。Windows 11 Version 24H2/25H2 対応(Windows 10 LTSC 未対応)。WorkSpaces Personal・Applications を同一占有ハードウェアで混在可能。

詳細

Amazon WorkSpaces Applications(旧 AppStream 2.0)が Windows クライアント BYOL 対応。従来 WorkSpaces Personal・Pools が BYOL 対象、AppStream 2.0 は異なるサービスため対象外。WorkSpaces 統合でスコープ拡大。

BYOL 共通条件(WorkSpaces ファミリー全体)。①占有ハードウェア環境のみ対応(共有ハードウェアは Microsoft ルール制限)。②VDI 利用者分の Microsoft VDA E3/E5 ライセンス別途必須。③占有ハードウェア使用のため一定数インスタンス確約。

Applications 独自条件。リージョン毎：②非 GPU インスタンス最低 50/月、②GPU インスタンス最低 AlwaysOn 4 または AutoStop 20。Applications は AlwaysOn・On-Demand 混在許可(Personal と差)。サポート OS：Windows 11 Version 24H2(October 2024)・25H2(September 2025)(Windows 10 Enterprise LTSC 不可)。

新条件：占有ハードウェアが WorkSpaces Personal・Applications インスタンス同時動作対応。高額占有ハードウェアの効率利用。その他ネットワーク要件等従来 BYOL 条件有。

Aurora カスタムエンドポイントはフェイルオーバーでどう変化する？Serverless v2 で 6 パターン(+派生 2)を検証してみた

• URL: https://dev.classmethod.jp/articles/aurora-custom-endpoint-failover-behavior
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Aurora Serverless v2 でカスタムエンドポイントのフェイルオーバー挙動を 6 パターン + 派生 2 パターンで検証。読み取り負荷への対処は「ACU 上限値上げ」「reader 増設」「カスタムエンドポイント分離」の 3 択。カスタムエンドポイントは性能向上でなく重いワークロード隔離が目的。TYPE(READER/ANY) × 自動アタッチ(静的リスト/除外リスト) × 昇格先(メンバ内/メンバ外) で挙動が分岐。フェイルオーバー時の接続先変化・ワークロード完全分離・障害時の接続復旧パターンを実測ログ・CloudWatch メトリクスで検証。

詳細

Aurora reader を用途別に分離したい場合、標準 reader エンドポイント(全 reader に分散)では特定ワークロードを特定 reader に固定できない。カスタムエンドポイントで役割(READER/ANY)とメンバ指定方式(静的リスト名指し/除外リスト自動アタッチ)を設定し分離実現。

読み取り負荷対処の 3 アプローチ比較。①ACU 上限上げ：1 台当たり処理能力向上(0.5→4.0 ACU 自動追従)。重いクエリ・軽いクエリの同居は未解決。②reader 増設：読み取り総量向上で標準エンドポイント自動分散(実測 db-02:db-03 ≈107:123)。特定ワークロード選別不可。③カスタムエンドポイント分離：特定ワークロード接続先固定・相互影響遮断(実測で完全分離)。障害時挙動の理解が必須。

フェイルオーバー時のパターン別挙動。①TYPE=READER 自動アタッチ=Disable(静的)：db-03 昇格時は db-02 のみ。db-02 昇格時は db-03 のみ。②TYPE=READER 自動アタッチ=Enable(除外)：db-01 除外指定で、昇格後も db-01 は除外のまま残る。③④TYPE=ANY：Disable/Enable 問わず writer/reader 両方継続。

重要な発見：昇格先がメンバ内か外かで結果変化。3 台構成だからこその挙動。派生パターン ①′ (1 台メンバ)・②′(除外指定なし)で設定の仕組みを切り分け検証。

[アップデート] AWS IAM Identity Center で AWS アカウントとアプリケーションのクォータが個別管理されるようになりました

• URL: https://dev.classmethod.jp/articles/aws-identity-center-separate-quotas
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: AWS IAM Identity Center のクォータが AWS アカウント・アプリケーション で個別管理に。従来：合算 1 つのクォータ(デフォルト 3,000)で AWS アカウント 2,750 設定時はアプリケーション 250 のみ。新仕様：デフォルト 7,000 で AWS アカウント・アプリケーション それぞれ独立 7,000。既存引き上げクォータ顧客にも両方に同一上限自動適用。全リージョン提供。Service Quotas コンソールで確認可能。

詳細

IAM Identity Center 管理下 AWS アカウント・アプリケーション数にクォータ設定。従来仕様：合算 1 つクォータ(デフォルト 3,000)。AWS アカウント消費が多いとアプリケーション追加余地減少。多数アカウント管理組織ではアプリケーション追加時にクォータ圧迫問題発生。

新仕様で解決。クォータ項目は 1 つのままだが、AWS アカウント・アプリケーション の消費量が独立カウント。デフォルト上限 7,000。AWS アカウント 7,000 使用中もアプリケーション別枠で 7,000 追加可。

既存引き上げ済みクォータ顧客は両方に同じ上限が自動適用。IAM Identity Center 全リージョンで提供。Service Quotas コンソール「Total number of AWS accounts or applications that can be configured」で確認。値 3,000→7,000 更新済み。説明文は「total combined」のまま更新未反映(記事執筆時点)。AWS CLI aws service-quotas list-aws-default-service-quotas –service-code sso で QuotaCode L-0299121C 確認。Adjustable: true で引き上げ対応可。

GitHubとAWS Lambdaで始める体験型CI/CD入門ワークショップを公開しました

• URL: https://dev.classmethod.jp/articles/aws-lambda-cicd-workshop-github-actions
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: GitHub + AWS Lambda CI/CDパイプライン入門ワークショップ公開。CloudFormationによるIaC・GitHub Actions自動テスト・aws login による一時認証・OIDC信頼構築を10ステップで習得。従来のコンソール直接操作・属人的デプロイから脱却。GitHub Copilot Coding Agent によるコード修正・自動PR生成・CI/CDによる自動デプロイまでの実装を体験。Python+Ruff静的解析・uv開発環境セットアップを含む。

詳細

ワークショップ対象課題：AWSコンソール直接操作でのデプロイ・デプロイ作業属人化・ソースコード管理不十分・テスト自動化未実装。

10ステップ構成。Step 1-2: CloudFormationで Lambda 関数構築・GitHub リポジトリにアプリコード配置。Step 3-4: ローカル uv+Ruff 静的解析・GitHub Actions CI 自動実行。Step 5-6: aws login による一時認証情報取得・ローカル AWS CLI デプロイ(永続認証不要)。Step 7: OIDC 信頼関係設定で GitHub Actions ↔ AWS 連携。Step 8: GitHub Actions CD による自動デプロイ。Step 9: Issue→PR→CI→Merge→CD の実運用流れを体験。GitHub Copilot Coding Agent でコード修正・draft PR 自動生成。Step 10: 既存 Lambda 適用・デプロイアカウント切り替え・テスト追加などの拡張パターン提示。

設計意図：コンソールベース開発者向け数時間実習。従来ローカル→AWS 操作を GitHub Actions に統一。永続認証情報を使わず一時認証のみで運用。GitHub Copilot agent への自動化委譲。

【アップデート】信頼できないコードをサンドボックス環境で検証するためのAWS Lambda MicroVMsが利用可能になりました

• URL: https://dev.classmethod.jp/articles/aws-lambda-introduces-microvms
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: AWS Lambda MicroVMsが6月22日に利用可能化。FirecrackerベースのMicroVM技術を使用して、AI生成コードなど信頼できないコードを隔離されたサンドボックス環境で実行可能。従来のVM(オーバーヘッド大)とコンテナ(カーネル共有で脆弱性拡大のリスク)の中間的アプローチ。Firecrackerは数百msレベルでVM起動が可能で、スナップショットによる高速再開に対応。開発・テスト用の環境であり、本番Lambda Function等への置き換えではない。

詳細

Lambda MicroVMsはハイパーバイザレベルの強力な環境分離を提供。従来の完全VM は起動オーバーヘッド大、コンテナ技術のみは同一カーネル共有で脆弱性被害拡大が課題。Firecrackerはこのトレードオフを解消する軽量VMMで、数百msレベルでMicroVM起動が可能。

MicroVMイメージはDockerfileをベースにビルドされ、Firecrackerスナップショットとして管理。起動/停止 = スナップショット のresume/suspend になるため開発ライフサイクルが高速化。

Lambda Functionと異なり、MicroVMsはイベントトリガーやオンデマンドスケーリングを持たない。開発・テスト環境として位置づけられ、テスト完了後のコードは従来通りLambda Functionやタスクとして実行。Linux Capabilitiesが指定可能でeBPFテストにも利用可能。

アクセス手段はAWS管理HTTPS エンドポイント経由。一時トークンで認証し、指定ポートへ転送。HTTP/1.1・HTTP/2・WebSocket・gRPC・SSEをサポート。トークン発行時に有効期限とポート番号を指定。

利用可能リージョン：us-east-1・us-east-2・us-west-2・eu-west-1・ap-northeast-1。料金は vCPU・メモリのコンピューティング + スナップショットのストレージ・読取・書込。東京リージョンの場合 vCPU $0.0000322421/秒、メモリ $0.0000042688/GB・秒。

新機能 AWS Lambda MicroVMsで、Flaskアプリを動かしてサスペンド・レジュームまで試してみた

• URL: https://dev.classmethod.jp/articles/aws-lambda-microvms-flask-suspend-resume
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: AWS Lambda MicroVMs で Flask アプリのステートフルなサスペンド・レジューム実装。従来 Lambda 関数(イベント駆動・ステートレス・15分上限)と異なり、MicroVMs はステートフル隔離(8時間上限・16vCPU/32GB/32GBディスク可能)。Firecracker スナップショット技術で高速起動・状態保持。開発者がライフサイクルを明示的制御。S3 からコード取得・CloudWatch Logs にビルドログ出力する IAM ロール設定。

詳細

Lambda MicroVMs vs Lambda 関数の位置づけ比較。設計思想：関数はイベント駆動・ステートレス、MicroVMs はステートフル隔離環境。アイソレーション：関数は Firecracker 再利用、MicroVMs はインスタンスごと隔離。状態保持：関数は保証なし、MicroVMs はサスペンド中もメモリ・ディスク状態保持。実行時間：関数最大15分、MicroVMs 最大8時間。リソース：関数最大 6vCPU/10GB、MicroVMs 最大 16vCPU/32GB/32GB ディスク。ライフサイクル：関数は AWS 管理、MicroVMs は開発者明示的制御。接続：関数はイベント/URL、MicroVMs は専用 HTTPS エンドポイント。

MicroVMs は既存 Lambda 置き換えでなく、ユーザーごと隔離・長時間インタラクティブ環境が必要な場面向け。IAM ロール作成時の信頼ポリシーで lambda.amazonaws.com に sts:AssumeRole・sts:TagSession 許可。権限ポリシーで s3:GetObject(コード取得)・logs:CreateLogGroup/PutLogEvents(ビルドログ)付与。Firecracker スナップショットで高速復帰と状態一貫性を実現。

AWSのPhysical AI Scaffolding Kit (PASK)を試す④ — physai CLIで学習〜評価をパイプライン実行する

• URL: https://dev.classmethod.jp/articles/aws-pask-physai-cli-training-evaluation-pipeline
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: AWSのPhysical AI Scaffolding Kit(PASK)シリーズ第4回。physai CLIツールを使用してHyperPodクラスタ上のロボット学習パイプライン(データ変換・学習・評価)を構築・実行する手順を解説。PC側のローカルCLIがSSH/rsync経由でクラスタのSlurmジョブを制御する設計。SO-101ロボット、LeIsaac Sim環境、GR00T N1.6モデルを使用したサンプルで成功率50%を達成。

詳細

physai CLIはPC側で動作するローカルツール。SSH/rsyncを使ってHyperPodクラスタのSlurmに接続し、ジョブ投入(sbatch)・状態確認(squeue/sacct)・ログ取得・ファイル同期を行う。専用デーモンやクラスタ常駐エージェントは不要。

デプロイ手順は7フェーズ構成。CDK でインフラ展開(VPC/S3/FSx/RDS + HyperPod)は約25分、その後CLI設定・SSH設定・コンテナビルド(3本、30〜40分)・データセット準備・学習実行(1.5時間)・評価(45分)。

実装上の注意点3つ。(1)physaiはクラスタ内ではなくPC側で実行(クラスタ内でコマンドを打つと見つからない)。(2)デプロイ前にphysai/infra/package.jsonにts-nodeを追加(cdk synthが失敗する)。(3)macOSはbrewで最新rsync 3.xをインストール必須(同梱openrsync 2.6.9は–info=progress2をサポートしない)。

学習フェーズはphysai runで投入。–from trainでconvert をスキップして学習のみ実行。評価はLeIsaac上で20ラウンド実行してmetrics.jsonに成功率を記録。ワーカーGPU課金は終了後にcleanup.shで段階的に削除(クラスタ→FSx/RDS→S3→インフラスタック)。

[アップデート] Amazon Bedrock AgentCore Optimizations の Insights（プレビュー）機能を使ってみた

• URL: https://dev.classmethod.jp/articles/bedrock-agentcore-insights-detect-silent-failures
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Amazon Bedrock AgentCore Insights(プレビュー)で エージェント失敗を自動検出。Failure Analysis でサイレント失敗も含む繰り返し失敗パターン発見(ハルシネーション・不正確アクション・オーケストレーション error等)。User Intent Analysis でユーザーリクエストを実意図でクラスタリング。Execution Summary でタスク遂行パスをグループ化・通常と異なる振る舞い特定。AgentCore Optimizations ループの入口。Insights→Recommendations→Batch Evaluation→A/B Testing の最適化フロー構成。

詳細

AgentCore Insights は本番トレースから問題を自動発見。3 種類のインサイト。①Failure Analysis：エラーシグナル出さないサイレント失敗(ハルシネーション・不正確 action・orchestration error・タスク指示非準拠・実行 error・context 処理 error・反復振る舞い等)含む繰り返し失敗パターン発見。根本原因説明・影響範囲でランキング。②User Intent Analysis：ユーザーリクエストを実意図でクラスタリング(「注文状況確認」「返品申請」「商品問い合わせ」等)。セッション自動分類。③Execution Summary：タスク遂行パスをグループ化。tool 呼び出しパターン・fallback 応答パターン分離。

AgentCore Optimizations ループ内でのポジション。Insights(本番トレース問題自動発見)→Recommendations(改善案提案)→Batch Evaluation(テストで検証)→A/B Testing(本番効果検証)。今回 Insights 部分を検証。AgentCore Harness でシステムプロンプトに弱点仕込み→エージェント失敗トリガー→Insights で問題自動検出。前提：us-east-1・AgentCore Harness(GA)・AgentCore Insights(プレビュー)・Claude Haiku 4.5。

Claude Code をセキュアに使うための考え方と設定の勘どころ【セミナースライド】

• URL: https://dev.classmethod.jp/articles/claude-code-seminar-2026-06-16-kawahara
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Claude Code セキュリティセミナー(2026-06-16)でツール制御を「抑止・制限・隔離」3 軸で整理。Claude Code は推論→ツール実行→検証の Agentic Loop で動作。Read/Edit/Write/Bash/MCP/Skill など多種ツールで多彩な操作可能。3 軸の考え方：抑止(危険ツール実行さないよう誘導)・制限(実行不可に)・隔離(実行しても問題ない環境構築)。人事例と並べた Guardian/Person/Manager の階層運用モデル。

詳細

Claude Code セキュリティ/ガバナンスセミナー登壇資料。Claude Code 仕組み：推論→ツール実行→検証の Agentic Loop。ツール多彩(Read・Edit/Write・Bash・MCP・Skill)で多くの操作可能。

ツール制御 3 軸戦略。①抑止(Deter)：危険ツール実行させないよう誘導。ルール通知・注意。②制限(Restrict)：危険ツール実行不可に制御。③隔離(Isolate)：危険ツール実行しても問題ない環境構築。

人事例：新メンバー任せるイメージに映射。抑止は「ルール伝える・注意する」、制限は「できないようにする」、隔離は「失敗しても大丈夫な環境」。

対象視聴者：Claude Code 使用者・チーム/組織管理者。達成目標：Claude Code 安全利用に必要なセキュリティ考え方ざっくり把握。細かい技術挙動・シンタックスは省略。

Claude Codeの通信に自前ゲートウェイを挟む ― WASI 0.3とWACによる実装

• URL: https://dev.classmethod.jp/articles/claude-code-wasm-gateway-wasi
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Claude Codeの通信にカスタムゲートウェイを挿入する実装ガイド。ANTHROPIC_BASE_URLで接続先を自前エンドポイントに向け、WASI 0.3とWebAssembly Componentモデル(wac)を使用してガードレール機能(秘密検出・応答伏字化・メトリクス計測)をモジュール化・合成。ゲートウェイはローカルCLI経由でSSE ストリーミングを保ったまま複数段の検査・遮断処理を実行可能。オーバーヘッド約0.5ms(初トークン到達時)。

詳細

Claude Codeの組み込みセキュリティ機能(permission・hooks・managed-settings)には限界がある。hooks では入力単位の遮断は可能だが、会話履歴・toolResultを含む完全なHTTPリクエストやSSEストリーム全体の検査・改変には不足。ANTHROPIC_BASE_URLで接続先を変更することで、Claude Code 本体を修正せずゲートウェイレイヤーにガードレール機能を挿入できる。

WASM(WebAssembly)はポータブルなバイナリで、WASI(System Interface)がブラウザ外での実行を支援。WASI 0.3.0以降、stream とfuture がネイティブに使用可能となり、SSEチャンク単位での動的検査が実装可能。

実装構成：各ガードレール(meter・secret-scan・output-mask等)を独立した WASM コンポーネントとして実装。wac plugで複数コンポーネントを1バイナリに合成し、wasmtime serve で起動。Claude Code は ANTHROPIC_BASE_URLをこのゲートウェイに向ける。メッセージAPI互換のリバースプロキシとして /v1/messages・/v1/messages/count_tokens を中継し、anthropic-version・anthropic-beta ヘッダをそのまま通す。secret-scan例：API キーのような形式を本文から検出し上流送信前に遮断。output-mask例：応答ストリーム中のメールアドレスや既知機密情報を伏字化。

実装上の注意：host・connection・content-length ヘッダは転送対象外(接続先との不整合で403になる)。x-api-key・Authorization・anthropic-* ヘッダはそのまま転送し、認証を保持。

企業運用時は MDM で ANTHROPIC_BASE_URLを配布し上書き不可に固定、ネットワーク egress 制御で api.anthropic.com への通信に限定、内部ALB/IP制限/mTLSで公開境界を fail-closed に設定。

【非エンジニアのためのClaude/ClaudeCodeシリーズ】HubSpotの二重入力をやめたくて、Claude Coworkで週報を自動化した

• URL: https://dev.classmethod.jp/articles/claude-weekly-report-cowork
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: 営業チームの週報自動化を Claude Cowork で実装(非エンジニア)。HubSpot に登録済み案件・ミーティングログから週報自動生成。毎週金曜 17 時に Cowork スケジュール実行で当週データ取得→対象メンバー別に月曜〜金曜の案件・ログ収集→既存ドキュメントに新タブ作成・週報記載→Slack 通知。メンバーは月曜 11 時までに自動生成内容確認・補足追記。手作業 30 分→20 分に短縮見込み。Skill・スケジュール実行・Slack 通知組み合わせ。

詳細

営業チーム週報作成課題：テキストドキュメント・HubSpot 二重入力で稼働圧迫。各メンバー週 30 分・合計月 4 時間消費。HubSpot データから転記・記憶頼り・ドキュメント手書き。Claude Cowork で自動化。非エンジニア(営業)がコード一行も書かず Cowork 対話のみで構築。

自動化フロー。毎週金曜 17 時にスケジュール実行(Cowork Skill)→当週 HubSpot データ取得(案件情報・ミーティングログ)→対象メンバーごとに月曜〜金曜分集約→既存週報ドキュメントに新タブ生成・データ記載→Slack 指定チャンネルに完了通知。

メンバー側は月曜 11 時までに自動生成内容を確認・必要補足追記のみ。手作業時間見込み 30 分→20 分(約 30%削減)。6 人チームなら月 4 時間削減。Cowork 3 機能：①Skill(ロジック定義)、②スケジュール実行、③Slack 通知。

【Copilot Studio】KPIの集計をLLMに任せず決定論的にやってみた：コードインタープリターとOffice Scriptの2アプローチ

• URL: https://dev.classmethod.jp/articles/copilot-studio-deterministic-aggregation
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Copilot Studio で KPI 集計を LLM に任せず決定論的実装。平均・前年比のような計算を生成 AI に任せると桁誤りや対象取り違え発生。2 アプローチ：①コードインタープリター(Python)でプロンプト埋め込み計算固定、②Office Script(TypeScript)をエージェントフローから実行。計算は決定論的手段・LLM には示唆生成・差し込みのみ委譲。シリーズ第6回集計段階。

詳細

KPI レポート月次→四半期集計時に平均・前年比計算が課題。生成 AI は文章得意だが数値計算は桁誤り・対象取り違え頻発。金額・比率の正確さが前提なので計算は決定論的手段に委譲。

2 アプローチ。①コードインタープリター(Python)：プロンプトに Python コード埋め込み。集計コードを先行書き込み固定。計算ロジック変わらず常時同じ値出力。②Office Script(TypeScript)：Excel で実行する TypeScript。Copilot Studio エージェント フロー から呼び出し。Office Script として書き置き固定。

役割分担：計算→決定論的手段(同じコード固定実行)、解釈(示唆)→生成 AI、差し込み→生成 AI。元データ月次から月次データを four-quarter 集計(合計・平均・前年比)を正確に出力。LLM はその計算済み数値を解釈してコメント生成のみ。DRY 原則・最小コンテキスト・疎結合設計原則適用。シリーズ第6回集計段階。「収集→集計→グラフ→示唆→資料化」エージェント構築。

【Copilot Studio】生成したWordレポートをフロー経由でダウンロードリンクとして配布してみた

• URL: https://dev.classmethod.jp/articles/copilot-studio-file-distribution
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Copilot Studioエージェントで生成したWord文書をOneDriveに保存し、ダウンロード共有リンクをチャットに返す実装。エージェントフローで5ステップ構成(トリガー→プロンプト実行→ファイル作成→共有リンク生成→応答)。Document output の生成結果(Document Output Content Bytes)はエージェント直接出力でなくフロー経由で配布必要。Copilot Studio シリーズ第11回で、自然言語依頼→資料自動生成→配布までの一気通貫フロー実装。

詳細

エージェントチャットでプロンプトツール(KPIレポート差し込み Word)を呼び出してもダウンロードリンク出現なし。これは仕様で Document Output Content Bytes はトピック・エージェント直接出力にならず、クラウドフロー・エージェントフロー経由で実装必須。

エージェントフローは5ステップ。①トリガー「エージェントがフローを呼び出したとき」(Copilot/スキルコネクタで検索)。②「プロンプト実行」アクション追加、Microsoft Dataverse 接続、「KPIレポート差し込み(Word)」選択。③「ファイル作成」(OneDrive for Business)、フォルダーパス・ファイル名(kpi-report-flow.docx)・ファイルコンテンツ設定。コンテンツ欄で / 押して動的コンテンツ開き Document Output Content Bytes 選択。④「共有リンク作成」でダウンロード用 URL 生成。⑤「Return value(s)」でエージェントに共有リンク URL 応答。

フローをエージェントツールとして登録し、テストチャットから自然言語で依頼するとダウンロードリンク取得可能。シリーズ全体は「収集→集計→グラフ→示唆→資料化」の一気通貫エージェント実装で、本記事は「配布」段階。第9回 Word テンプレート差し込み・第10回 PowerPoint/Excel コード生成ツールが前提。

【Copilot Studio】KPIをチャット内でグラフ表示してみた：Adaptive Cardとコードインタープリターの2ルート

• URL: https://dev.classmethod.jp/articles/copilot-studio-kpi-chart-adaptive-card
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Copilot Studio チャット内 KPI グラフ表示の 2 ルート。ルートA：Adaptive Cards Chart.VerticalBar で棒グラフ。ホスト描画・プレミアム機能不要。ルートB：コードインタープリター Python/matplotlib で画像生成。プレミアム(Copilot Credits 消費)。ルートA はインタラクティブ・チャネル制限なし。ルートB は画像・Excel/Teams 等チャネル広。シリーズ第7回グラフ段階。

詳細

Copilot Studio チャット内グラフ 2 ルート比較。ルートA Adaptive Card Chart 要素：Chart.VerticalBar で棒グラフ実装。ホストが card 描画。コスト低(プレミアム機能不要)。インタラクティブ(フィルタ・ドリルダウン可)。チャネル制限なし。ルートB コードインタープリター：Python/matplotlib で image 生成。プレミアム(Copilot Credits)。image 形式なので Excel・Teams 等多くチャネル対応。カスタマイズ自由度高。

使い分け。ルートA：インタラクティブ必要・複数チャネル・低コスト重視。ルートB：複雑な可視化・画像出力必須・プレミアム許容。

シリーズ第7回グラフ段階。架空 SaaS 3社(CloudNova/StreamForge/Datapeak)ARR データ使用。「収集→集計→グラフ→示唆→資料化」一気通貫エージェント目指し。

【Copilot Studio】集計した数値から示唆を生成してみた：根拠のない応答をブロックする設定も

• URL: https://dev.classmethod.jp/articles/copilot-studio-kpi-insights-generation
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Copilot Studio で KPI 集計数値から示唆(比較コメント・注目点)を生成。計算と解釈の役割分担を原則に、計算は決定論的手段(Office Script・コードインタープリター)で確定、解釈のみ生成 AI に委譲。計算済み数値をプロンプトに直接渡し「ここにない数値を持ち出さない」指示で生成 AI を解釈に限定。生成オーケストレーション有効化でエージェントがツール・ナレッジ自動選択。根拠のない応答ブロック設定は発展として提示。シリーズ第8回で示唆段階カバー。

詳細

KPIレポートは数値と説明文(示唆)の2層。計算と解釈を分離：計算は決定論的手段(同じコード固定実行)が合計・平均・前年比を担当、解釈は生成AI が「どこが伸びているか」「注目点は」のコメント生成。これにより数値の正確性保証しつつコメント生成を AI に任せられる。

事実から外れにくくする工夫2つ。①計算済みの数値を渡す：前段の集計結果(確定数値)のみをプロンプトに渡し、AI に再計算させない。②指示で数値を固定：「次の集計値だけを根拠にコメント。新しい数値を計算したり、ここにない数値を持ち出したりしないこと」と明示。数値を本文に埋め込む形で制約。

統合エージェント「KPIレポート作成アシスタント」で実装。生成AI オーケストレーション「生成(Generative)」に設定し、エージェントが必要なツール・ナレッジを自動選択。決定論的集計ツール「KPIScriptAgg 四半期集計(Office Script)」で計算担当。今回示唆は数値直接渡しのため、ナレッジ・ツール不使用で「根拠のない応答ブロック」設定はオンのまま。根拠のない応答をブロックする設定は発展オプション。

【Copilot Studio】コードインタープリターで.pptx／.xlsxをゼロから生成してみた

• URL: https://dev.classmethod.jp/articles/copilot-studio-native-pptx-excel
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Copilot Studio コードインタープリター(Python)でネイティブ .xlsx/.pptx をゼロから生成。Document output は Word テンプレート差し込み限定だが、コードインタープリターは openpyxl・python-pptx で Word/Excel/PowerPoint/PDF 自由生成。生成 Excel は画像でなくセル参照のネイティブグラフ(BarChart)で編集可能。ユーザー認証有効化が必須(Direct Line No auth は非対応)。シリーズ第10回で資料化段階カバー。

詳細

Document output は Word テンプレートの {{フィールド}} に値差し込み方式(テンプレート必須)。コードインタープリターは Python 実行でファイル 0 から組み立て(テンプレート不要)。対応フォーマット Word/Excel/PowerPoint/PDF。グラフは Document output は事前用意、コードインタープリターはコードで自由生成。課金は Document output がプロンプト実行・コードインタープリターがプレミアム(どちらも Copilot Credits)。

Excel 生成例：openpyxl で .xlsx を新規作成。シート名「ARR集計」、見出し「会社名」「ARR(百万円)」、3社 2025 年 ARR 値を B2:B4 に入力。見出し行を濃紺背景・白太字、B 列を桁区切り #,##0 フォーマット。openpyxl.chart.BarChart で縦棒グラフ作成(参照 B2:B4 カテゴリ A2:A4)。グラフはセル参照のネイティブオブジェクトなので Excel で系列色・軸・種類編集可能。

注意点：openpyxl デフォルトでデータラベル OFF、カテゴリ参照 set_categories() が効いていないと横軸ラベルが出ない。そのままではラベルなし状態になるため、必要なら指示・コードで明示。

PowerPoint 生成は python-pptx で複数スライド構成。エージェント設定で「生成AI」→「ファイル処理能力」で「コードインタープリター」オン。ユーザー認証有効化必須(Direct Line No auth では非動作)。

【Copilot Studio】テンプレートに数値を差し込んでWordレポートを自動生成してみた：Document output

• URL: https://dev.classmethod.jp/articles/copilot-studio-word-report-template
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Copilot Studio Document output でテンプレートに数値差し込み Word レポート自動生成。{{フィールド}} 形式プレースホルダーに AI が値を差し込む方式。Word 出力のみ対応。シリーズ第9回で資料化(Word)段階カバー。固定 KPI データの最小構成で実装検証。プロンプトツールで差し込み値指定、エージェントテストチャットから自然言語呼び出しで Word 生成。

詳細

定例レポート・顧客報告資料は「フォーマット固定・数値入れ替え」が常套。Copilot Studio でこれを自動化。Document output はプレビュー機能でプロンプト出力を Word に変換。テンプレートのプレースホルダー {{フィールド}} に AI が値を差し込む。Word のみ対応。

PowerPoint/Excel 生成には Code interpreter を使用。Python 実行で Word/Excel/PowerPoint/PDF 処理可能。ただしコードインタープリターはプレミアム機能で Copilot Credits 消費。

検証構成：架空 SaaS 3社(CloudNova/StreamForge/Datapeak)の KPI データ使用。固定データの最小構成で、エージェント→プロンプトツール(Document output)→テンプレート差し込み→Word 生成フロー。ユーザー入力・変数対応は収集・集計段階と組み合わせる発展形。エージェント設定で Document output を有効化し、プロンプトツールで指示記述、テストチャットから自然言語で呼び出し。シリーズ全体「収集→集計→グラフ→示唆→資料化」の資料化(Word)段階。

【登壇資料】「ツールを入れても解決しない？データ活用の現場に共通する課題とデータマネジメントの必要性と基本」というタイトルで登壇しました

• URL: https://dev.classmethod.jp/articles/data-management-basics-webinar
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: クラスメソッドが開催したウェビナーの登壇資料・Q&Aまとめ。AI活用・BI整備・非構造データ活用の前提として、「ツール導入では解決しない」データマネジメントの重要性を解説。DMBOK11領域を「集める」「保管する」「整理する」「使う」「ルール」に大別。課題ドリブンの優先順位付けと段階的進行を推奨。kaimei(Text-to-SQL AI)活用時は最低限メタデータ・社内文脈・指標定義・結合条件・利用権限の整備が必要。

詳細

クラスメソッドが扱うデータ相談の共通課題：AI活用の根拠データの信頼性不足、BIダッシュボード構築前のデータ所在不明、非構造データのAI活用着手点不明。これらはツール導入のみでは解決されず、「目的に応じたデータをいつでも活用できる状態で継続的に維持・管理するため」のデータマネジメント取り組みが必須。

DMBOKの11領域(データアーキテクチャ・ストレージ・統合・モデリング・マスターデータ・ドキュメント・セキュリティ・品質・DWH/BI・メタデータ・ガバナンス)を実践的に5つのカテゴリに分類。「データの責任者が分からない」課題はガバナンス、「信頼性不安」は品質管理、「意味が分からない」はメタデータ管理と関連。

課題ドリブン推進の3つ理由：①効果が大きい場所から着手し費用対効果を高める、②データマネジメント自体の活動化を避け事業インパクト最優先にする、③「業務課題解決」が「データ管理」より現場協力を得やすい。

新規基盤構築時は完璧を目指さずまず動くものを作成、利用者フィードバックを反映しながら段階的に整備。kaimei利用前提時は分析対象テーブル・テーブル説明・業務文脈・指標定義・結合条件・利用権限・データ品質が最小限要件。非構造ファイルAI利用時は最新版・過去版・作業中の物理分離、命名ルール統一、文書種別・対象業務・更新日等メタデータ付与を推奨。段階的実施で重要フォルダから優先開始が現実的。

【登壇資料】「データ品質とメタデータ管理で実現する構造化・非構造化データ活用のユースケース紹介」というタイトルで登壇しました

• URL: https://dev.classmethod.jp/articles/data-quality-metadata-management-webinar
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: クラスメソッド データ事業本部ウェビナー登壇資料。渡部氏のデータマネジメント基本に続く実装論を解説。構造化データ×データ品質と非構造化データ×メタデータ管理を2軸。3つの原則：①重要なものに絞る(全量対応でなく優先度付け)、②シフトレフト(基盤入口・データ発生源での対策)、③体制スモールスタート(データオーナー→スチュワード→ガバナンス組織へ段階的成長)。ビジネスメタデータ自動生成は DWH サービス統合カタログで活用、非構造化は人間による評価が避けられず。

詳細

クラスメソッド データ事業本部のデータ支援ミッション：組織のデータ分析環境構築・活用支援。ほとんどの相談は「データ自体の管理不足」「管理体制の問題」に帰着。

2つのテーマで実装論展開。①構造化データ×データ品質：課題深掘り→改善活動進め方→運用体制→基盤実装例。②非構造化データ×メタデータ管理：同じく課題から実装まで。

3つの実装原則。①重要なものに絞る：膨大データを全量管理は困難。人員・予算制限下で対象を重要度に限定。業務への影響度で優先度決定。②シフトレフト原則：基盤内データの後付け品質改善・メタデータ付与は労力大。基盤入口・データ発生源での品質検証・メタデータ有無確認が効率的。システムで解決可能な部分は積極的システム化。③体制スモールスタート：理想的体制は組織文化・部署間壁で困難。改善は IT 単一部門では成立しないため、ソースデータ管理部門内でデータオーナーから設定。オーナー決定で利用者課題←→基盤管理側のフローが回始める。その後スチュワード・ガバナンス組織へ組織ステージ合わせて段階成長。

ビジネスメタデータ実装：最近の DWH カタログサービスは AI で自動生成機能充実。利用可能なら積極活用。非構造化・テーブル非管理構造化は自前実装も可。生成メタデータの正しさ評価はデータ発生部門担当者に依存。人間による泥臭い活動は避けられず。

GitHub CLI 2.94.0でgh discussionからDiscussionsの読み書き、gh skillでAgent Skillsの一覧表示ができるようになりました

• URL: https://dev.classmethod.jp/articles/github-cli-294-discussions-skills
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: GitHub CLI 2.94.0 で gh discussion コマンド追加(Discussions list/view/create/edit/comment)と gh skill list/install –all/update –all 強化。gh discussion で Discussions 読み書き可能。gh skill で metadata なしスキル skip 対応。CLIや AI エージェント で GitHub 上下文読み込みを補強。Discussions 管理と Agent Skills 一括処理効率化。

詳細

GitHub CLI 2.94.0 の 2 つ領域更新。①gh discussion：Preview command set で Discussions list/view/create/edit/comment 対応。Discussions リポジトリ内の読み書き。②gh skill：list(一覧表示)・install –all(一括インストール)・update –all(一括更新)。metadata なしスキル skip で不完全なスキル回避。

CLI や AI エージェント で GitHub 上下文読む場面で Discussions が重要。従来は Issue 中心でしたが、Discussion format の方が会話性・提案・知識共有に適する。gh discussion 対応で CLI 経由ブログ記事・RFD(Request For Discussion)等へアクセス可能。

Agent Skills 管理強化で複数スキル運用効率化。–all オプションで一括処理。metadata チェックで不完全なスキル自動除外。

[アップデート]Amazon GuardDuty の AI 調査機能「GuardDuty Investigation」がプレビューになりました

• URL: https://dev.classmethod.jp/articles/guardduty-investigation-preview-trial
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Amazon GuardDuty AI 調査機能「GuardDuty Investigation(AI Analyst)」プレビュー化。Finding 発出後の手作業調査を AI で支援。CloudTrail/VPC Flow Logs 複数サービス横断調査を自動化。分析結果：Risk Level 5 段階評価・Confidence 4 段階・Summary 要約・Investigation Details 詳細・Recommended Actions 対処手順。MITRE ATT&CK フレームワーク分類。3 分析タイプ：Finding ID 指定分析・アカウント全体・Organization 横断(最大 100 アカウント)。対応リージョン 10 箇所(東京含)。Cross-Region Inference で推論は地理的最適リージョン実行。

詳細

GuardDuty findings 対応の手作業調査の課題を AI で解決。従来は Finding 出力後に CloudTrail で API コール追跡・VPC Flow Logs でネットワーク通信確認等の複数サービス横断調査が必要。GuardDuty Investigation は過去 90 日のアクティビティを AI 分析し自動出力。

出力項目 5 種類。①Risk Level：Info/Low/Medium/High/Critical の 5 段階評価。②Confidence：Unknown/Low/Medium/High の 4 段階確信度。③Summary：調査結果要約と主要観察事項。④Investigation Details：調査詳細と文脈。⑤Recommended Actions：CLI コマンド含む具体的対処手順。MITRE ATT&CK フレームワーク分類で戦術・手法を標準観点から把握。

3 分析タイプ。①Finding 分析：特定 finding ID 指定の分析(管理者・スタンドアローン実行可)。②Account 分析：アカウント全体の脅威状況(同上)。③Organization 分析：組織全体横断分析最大 100 アカウント(GuardDuty 管理者アカウント専用)。

対応リージョン 10 箇所(Preview 時点)：米国東部(バージニア・オハイオ)・米国西部(オレゴン)・カナダ・欧州(フランクフルト・アイルランド・ロンドン・パリ・ストックホルム)・APAC(東京)。Cross-Region Inference(CRIS)で推論処理は地理的最適リージョン実行(日本は東京または大阪)。データ保管はリクエスト投入リージョンに限定。前提：対応リージョンで GuardDuty 有効・AI_ANALYST 機能有効化・必要 IAM 権限付与。

Lambda MicroVMsのSHELL_INGRESSでブラウザーからシェルアクセスを試してみた

• URL: https://dev.classmethod.jp/articles/lambda-microvms-shell-ingress-browser-webshell
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Lambda MicroVMsの SHELL_INGRESS 機能でブラウザからリモートシェルアクセスを実装。WebSocket接続でトークン認証し、xterm.js + aiohttp リレーサーバーでターミナルをブラウザ提供。MicroVM内部は Amazon Linux 2023・Kernel 6.1・Graviton4相当 4vCPU・8GB RAM(Swap無)・ext4 8GB。セキュリティ強化としてカーネルモジュール・kexec禁止、DAMON メモリ回収有効。PID 1は sleep infinity のまま、シェルアクセスごとに新規PTY生成。

詳細

HTTP_INGRESS がアプリケーション用のHTTP/HTTPS プロトコル。SHELL_INGRESS はデバッグ・管理・ターミナル用の WebSocket インターフェース。SHELL_INGRESS は認証トークン(create-microvm-shell-auth-token)で、初回接続時に session_init フレーム(JSON)返却。入力はバイナリフレーム(生テキスト)、出力もバイナリフレーム(生PTY)。ウィンドウリサイズはテキストフレーム {type: resize, cols, rows}。

ブラウザのWebSocket APIはカスタムヘッダ非対応のため、リレーサーバー(aiohttp)で仲介。ブラウザ↔localhost:3000 ws://→リレー↔MicroVM wss:// + X-aws-proxy-auth。フロント は xterm.js で ターミナル実装。

MicroVM 内部仕様。CPU は ARM Neoverse V2(Graviton4相当)4vCPU、メモリ8GB(Swap 0)、ディスク ext4 8GB。ブートパラメータでカーネルモジュールロード禁止(modules_disabled=1)・kexec禁止(kexec_load_disabled=1)・メモリ回収 DAMON 有効(damon_reclaim.enabled=Y)。

マウント構成では /sys は ro、/etc/resolv.conf・/etc/hosts は overlayfs (upper:vdb)でプラットフォーム側差し込み可能。3つの virtio ブロックデバイス(vda/vdb/vdc)。vda がinitial boot、vdb がoverlay upper layer、vdc(8GB ext4)が最終 root。カーネル 6.1.166、OS Amazon Linux 2023。

デバイス /dev に sysgenid(minor 125)があり、VM スナップショット resume・clone 検出に利用。プロセス PID 1 は sleep infinity で、SHELL_INGRESS接続時に pts/N でbashセッション新規生成。ネットワーク eth0 に IPv6 グローバルアドレス割り当て(INTERNET_EGRESS有効時)。

PLaMo 3.0 Prime を試してみた

• URL: https://dev.classmethod.jp/articles/plamo-3-0-prime-first-touch
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Preferred Networks PLaMo 3.0 Prime 正式リリース(2026-06-22)。国産フルスクラッチ LLM で初 Reasoning(長考)モード搭載。OpenAI 互換 API・256K コンテキスト・Tool calling 対応。医療・法律ドメインベンチで上位スコア主張。Standard プラン 60 円/1M input・250 円/1M output トークン。GA キャンペーン期間(〜2026-07-31)で新規登録時に 1000 万トークンクレジット付与。Reasoning OFF/ON 挙動を OpenAI 互換 SDK で実機観察・Claude Code 統合検証。

詳細

Preferred Networks PLaMo 3.0 Prime は独自開発国産生成 AI 基盤モデル。PLaMo シリーズ最新作。Reasoning ありの長考モードと Non-Reasoning 即応性重視モード使い分け可。モデル ID plamo-3.0-prime。仕様：256K コンテキスト(β版 64K から拡張)・max_tokens 上限 20,000・reasoning_effort で none/medium 切替・Tool calling 対応。提供形態：クラウド API / オンプレ導入。

料金 3 プラン。Standard：60 円/1M input・250 円/1M output。Free：利用量制限あり。Provider：個別見積。出力 1M トークン 250 円は海外同価格帯と比べて低廉。GA キャンペーン(2026-07-31 まで)で新規登録時 1000 万トークン相当クレジット。

同価格帯モデル(Qwen3.6-27B / gpt-oss-120b / GPT-5.4 Mini / Claude Haiku 4.5 等)との比較。PFN 主張：指示追従・対話・ツール使用・医療領域で同価格帯と匹敵以上。HELM Safety で海外勢同等以上。医療(医師国家試験/MedRECT)・法律(lawqa_jp)の日本語ベンチで上位主張は海外勢にはない切り口。検証：PLaMo Platform Console(console.platform.preferredai.jp)でサインアップ・API Key 発行→OpenAI 互換 SDK で Reasoning 挙動観察。

Amazon SageMaker AI の Code Editor をサンドボックスとして使う

• URL: https://dev.classmethod.jp/articles/sagemaker-code-editor-as-a-sandbox
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Amazon SageMaker Studio Code Editor をサンドボックスとして活用。AWS 上に柔軟なサンドボックス開発環境構築。SageMaker AI マネージドML 開発基盤で Studio が統合インターフェース。ドメイン・ユーザープロファイル・HomeEFS・アプリケーション・スペース・イメージで構成。Code Editor は私的スペース動作必須。CDK で L1 Construct デプロイ(L2 未実装)。IDE と Claude Code でコーディング統合。

詳細

SageMaker Studio の概念構成。①ドメイン：設定単位でユーザープロファイル・スペース含含。②ユーザープロファイル：Studio ユーザーで使用可能アプリケーション・インスタンスファミリー指定。③HomeEFS：ユーザーごとストレージ領域(EFS)。スペースアクセス時自動マウント。④アプリケーション：Code Editor・JupyterLab 等。⑤スペース：アプリケーション動作環境(EC2 + EBS)。1 スペース 1 アプリケーション。プライベート/共有スペース。Code Editor は私的スペース必須。⑥イメージ：スペース内コンテナのベースイメージ。カスタムイメージは ECR 事前アタッチ。⑦Studio：ユーザープロファイルごとの Web インターフェース。

実装：CDK で L1 Construct(2026-06 時点 SageMaker L2 未実装)。ドメイン作成で IAM role・VPC・認証方式・リージョン設定。Code Editor がコーディングエージェント(Claude Code)と統合・サンドボックス環境で IDE 動作実現。

Sakana Fugu (GA) をサブスクリプションプランで試してみた

• URL: https://dev.classmethod.jp/articles/sakana-fugu-ga-first-touch
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Sakana AI Fugu/Fugu Ultra GA リリース(2026-06-22)。マルチエージェント・オーケストレーションを 1 モデルに統合。GPT 5.5・Claude Opus 4.8・Gemini 3.1 Pro 等フロンティアモデルを動的に呼び分け。ICLR 2026 論文 TRINITY(進化型 LLM コーディネーター)・Conductor(自然言語エージェント協調強化学習)に基づく。fugu(軽量・レイテンシ重視)・fugu-ultra(272K context・長推論)2 モデル。Standard $20/月・Pro $100・Max $200。7 月末登録で 2 ヶ月目無料。

詳細

Sakana Fugu は LLM router の外部モデル選別と異なり、学習済みコーディネーター LLM が内部でフロンティアモデルを動的呼び分け。Agent pool 含有モデル：GPT 5.5・Claude Opus 4.8・Gemini 3.1 Pro(Fable 5・Mythos Preview は輸出規制で未含)。再帰呼び出しで推論深掘り。

fugu vs fugu-ultra。fugu(旧 fugu-mini)：軽量・低 latency・日常問い合わせ・コードレビュー・chatbot。fugu-ultra：272K context・長推論対応(論文再現・Kaggle・ cyber security・文献調査)。

料金 3 層。Standard $20/月(usage X)、Pro $100(usage 10X)、Max $200(usage 20X)。両モデル使用可。Pay-as-you-go：fugu-ultra 入力 $5/出力 $30(1M token)・272K 超時 入力 $10/出力 $45。fugu は最上位単一レート・複数 agent 呼び出しても積算なし。2026-07-31 登録で 2 ヶ月目無料。注意：fugu/fugu-ultra は呼び出し側が model パラメータで明示指定・自動判定は呼び出し側責任。Codex CLI 用 model catalog ~/.codex/fugu.json。

TypeScript の型推論つきバリデーションライブラリ Zod を使ってみた

• URL: https://dev.classmethod.jp/articles/shoma-try-zod-typescript-type-inference-validation-library
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: Zod は TypeScript スキーマ宣言・バリデーションライブラリ。1 つのスキーマから parse/safeParse(実行時バリデーション)と z.infer(静的型生成)の両方を出力。型定義とバリデーションロジック統一管理で保守性向上。従来は interface + isValidUser 関数で型定義・チェック別途実装でした。

詳細

Zod は 1 つのスキーマ定義で「実行時チェック」と「静的型」両方取得。userSchema = z.object({name:z.string().min(1), age:z.int().gte(0)}) で①z.infer で コンパイル時に型 User={name:string, age:number} 生成、②safeParse(input) でランタイムバリデーション実行。

従来方式の課題：interface User 型定義と isValidUser(input) チェック関数を別々実装。フィールド追加するたびに両方修正必要。DRY 原則違反。

Zod 利点：スキーマ 1 つで保守性向上。フィールド変更時は z.object 1 箇所の修正で済む。型と実行時チェックの同期不整合がない。

DevOps AgentのRelease testing機能を試してみた

• URL: https://dev.classmethod.jp/articles/try-devops-agent-release-testing
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: DevOps Agent Release testing 機能で自律リリーステスト実行。探索的 UAT・回帰テスト・ユーザージャーニー検証・統合テスト・エッジケース探索に対応。UI テスト・API テスト 2 種対応。テストプロファイル定義で対象アプリケーション種別・エンドポイント・認証情報指定。OpenAPI/Swagger YAML/JSON で API 仕様書指定。AI が必要テストケース自動生成。Secrets Manager 認証情報取得・利用。テスト実行方法：プロファイル一覧・チャット指示・エディタ IDE・GitHub Actions ワークフロー。

詳細

DevOps Agent 6/17 アップデートでリリース管理機能追加。自律リリーステストエージェントが実動作環境で実行。対応テスト：探索的 UAT・回帰テスト・ユーザージャーニー検証・統合テスト・エッジケース探索。読取操作のみでなく書込操作も実行でステージング環境対象推奨。

テスト実行プロセス：①テスト計画生成、②テスト実行、③結果レポート。UI テスト・API テスト 2 種類。テストプロファイル定義必須：対象アプリケーション種別・エンドポイント・テスト認証情報。API テスト では OpenAPI/Swagger YAML/JSON 仕様書指定(必須)。AI が仕様書から必要テストケース自動生成。認証情報は Secrets Manager から取得・利用。

実行方法 4 種：①テストプロファイル一覧から実行(最シンプル)、②DevOps Agent チャット「Run test profile my-test-profile」指示、③エディタ IDE(Kiro Power・Claude Code plugin)から実行、④GitHub Actions ワークフロー(aws-actions/devops-agent-qa)。検証：Petstore API を ECS デプロイ→HTTPS 公開→テストプロファイル定義→テスト実行。

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

• URL: https://docswell.com/s/rakutek/59NR49-2026-06-04-194729
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Code・Codex の全社展開時に利用実態が見えない課題を OpenTelemetry × MDM で解決。OTel native 対応・managed-settings.json 一括配布で全社ログ集約・Grafana 可視化・KPI 連携。

詳細

Claude Code・Cowork・Codex all OTel native 対応。課題は「設定全社配布」。Claude Team 複数組織分散・Max/ChatGPT Pro 混在でAdmin 設定だけではカバー不可。Jamf（MDM）で managed-settings.json 一括配置→OTEL_EXPORTER_OTLP_* 環境変数・エンドポイント・Basic 認証自動設定。Claude Code 取得フィールド：cost_usd・スキル名・実行環境（sandbox/approval/MCP）・キャッシュトークン内訳。Codex 取得：ツール実行全文・推論設定・分散トレース。Codex には cost_usd がないため使用モデル×トークン数で推定値換算。Codex CLI 同じ設計で managed_config.toml [otel] section 配布・service_name でソース見分け。Grafana Cloud で可視化・ベンダー中立（他社も同じ OTel 設定で乗換可）。③成果接続で GitHub API・Notion API・HRMOS 連携・Grafana Infinity datasource で ETL なし統合→入力ログ+GitHub PR+Notion 集計を単一 Grafana で可視化。計測数字が決算資料に掲載。本当の課題は「全社員カバー」で、OTel プロトコル・MDM配布がその解法。

PKI の概要

• URL: https://jpwinsup.github.io/blog/2026/06/22/PublicKeyInfrastructure/Fundamental/pki-foundation-01
• 日付: 2026-06-23
• Tier: Tier 1
• 要旨: Windows Supportチームが公開鍵基盤(PKI)の概要を解説。盗聴・改ざん・なりすましといったインターネット通信の脅威に対応するため、暗号化方式（共通鍵暗号・公開鍵暗号）、デジタル署名、デジタル証明書の3つの要素で構成される。認証局(CA)がデジタル証明書を発行することで、通信相手の公開鍵の真正性を確認するモデル。

詳細

PKIはActive Directory証明書サービス(AD CS)などの基盤となる。Microsoft StoreのWebサイトでの購入を例に、インターネット通信における盗聴・改ざん・なりすましの脅威を説明する。

暗号方式は共通鍵暗号と公開鍵暗号に大別される。共通鍵暗号は同じ鍵で暗号化・復号するため高速だが事前の鍵共有が必要。公開鍵暗号は公開鍵と秘密鍵のペアを用い、公開鍵で暗号化したデータを秘密鍵で復号する。代表アルゴリズムはAES、RSA、ECDSA等。

デジタル署名はハッシュアルゴリズムと公開鍵暗号の組み合わせで実装。送信者がデータのハッシュ値を秘密鍵で暗号化して署名を作成し、受信者が送信者の公開鍵で検証することでデータの改ざん検知と送信者本人確認を実現する。ハッシュ関数は1文字でも入力が異なれば出力が全く変わるため改ざん検出に利用される。

デジタル証明書は認証局(CA)が発行し、公開鍵が本当にその相手のものであることを証明。現実の身分証明書と同様、信頼できる第三者機関からの発行を前提とするモデル。ブラウザは受け取った証明書を検証してWebサイトの真正性を確認する。

GitHub、AIによる雑なプルリクエストを抑制へ。ユーザー当たりのプルリクエスト数の上限を設定できる新機能導入

• URL: https://www.publickey1.jp/blog/26/githubai_1.html
• 日付: 2026-06-23
• Tier: Tier 2
• 要旨: GitHub AI 生成プルリクエスト抑制機能導入。リポジトリ管理者が書き込み権限なしユーザーの PR 上限数設定可能。上限達成時は既存 PR クローズ・マージまで新規 PR 提出不可。信頼できるユーザーはバイパスリストで上限免除。外部 contributor PR 受け付けつつ質をコントロール。2 月の「collaborator のみ PR 提出」設定と異なり、外部 contributor を排除しない運用。今後アーカイブ機能・Issue 上限設定も計画。

詳細

生成 AI コーディング支援普及でオープンソース PR 激増。AI 生成コードの大量提交・雑な質の PR が OSS 開発者のレビュー負担増加。

新機能「PR 上限設定」。リポジトリ管理者が書き込み権限なしユーザーの PR 上限数を設定。上限達成ユーザーは既存 PR 1 つクローズ・マージまで新規提出不可。これにより「気軽に大量雑 PR 提出」を抑制、1 つ 1 つ吟味する行動促進。

バイパスリスト機能。信頼できるコントリビュータをリスト登録し PR 上限から除外。

設計理念。2 月の「collaborator 限定 PR」と異なり、外部 contributor 受け付けつつも質をコントロール。開放性と品質管理のバランス。

将来計画。低品質 PR のアーカイブ機能(一般非表示)・Issue 上限設定機能も予定。

ITニュース.　Sysinternals更新情報: 6月の更新

• URL: https://www.say-tech.co.jp/contents/blog/yamanxworld/2026news071
• 日付: 2026-06-23
• Tier: Tier 1
• 要旨: Windows Sysinternals 2026 年 6 月更新。Autoruns v14.3、ZoomIt v12.1(マイク noise cancel・Webcam 背景ぼかし追加)、Coreinfo v4.01(新 processor 機能対応)、DebugView v5.02、LiveKd v5.64、Process Monitor v4.04、Sysmon v15.21。Linux 向け ProcDump 3.5.2。バグ修正・機能改善中心。Microsoft Store・ダウンロードサイトから入手可能。一部 Linux/Mac 実装 OSS 提供(Windows コード非公開)。

詳細

Windows Sysinternals は Microsoft 提供の Windows system 管理・troubleshooting 無料 utility 群。2026-06 更新は多数ユーティリティで主にバグ修正・改善。

更新対象。Windows Sysinternals：Autoruns v14.3、ZoomIt v12.1(新機能：マイク noise cancel・Webcam background ぼかし表示)、Coreinfo v4.01(新 processor 機能サポート)、DebugView v5.02、LiveKd v5.64、Process Monitor v4.04、Sysmon v15.21。Sysinternals for Linux：ProcDump 3.5.2。

入手方法。Microsoft Store から(Windows 11)・ダウンロードサイトから直接。一部ツールは Linux・Mac 実装で OSS(Open Source Software)提供(Windows 版は非公開ソース)。

詳細。公式 Sysinternals Blog(Microsoft Tech Community)・Microsoft Learn で各ツール専用 page 確認。

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

• URL: https://www.say-tech.co.jp/contents/blog/yamanxworld/2026vol212
• 日付: 2026-06-23
• Tier: Tier 1
• 要旨: Windows タスクスケジューラ深掘り解説。Taskschd.msc GUI で操作またはコマンドライン(schtasks/PowerShell ScheduledTasks module)。対話不要な処理をバッチ・スクリプト準備後、操作 tab で program/script 指定・全般 tab でアカウント・トリガー tab で開始条件設定。Performance Monitor データコレクターセット警告時にタスク自動実行。タスクに引数 $(Arg0)/$(Arg1)/$(Arg2)…で動的引き渡し。$(value) 置換変数で警告カウンター値を取得。データコレクターセット停止時タスク実行・ログクリーンアップ等にも活用。

詳細

タスクスケジューラ(Taskschd.msc・Scheduler service)で Windows system 運用管理 task 自動実行。起動時・logon 時・指定日時・繰り返し・on-demand で program・batch・script 実行。GUI で作成・command line(schtasks・PowerShell ScheduledTasks module)でも操作。

タスク設定要素。①操作 tab：program/script path と引数指定。バッチ・PowerShell・VBScript・cmd 各形式のコマンドライン例。②全般 tab：security option・実行 account・ユーザーログイン中以外実行時は session 0・SYSTEM account はパスワード不要・他 account は要求・UAC 有効時は「最上位の特権で実行」check。③トリガー tab：開始条件(スケジュール・event・event 時刻)。

Performance Monitor 連携。データコレクターセット警告で task 自動実行。警告対象カウンター値・警告発生時に task に引数を動的引き渡し $(Arg0)/$(Arg1)/$(Arg2)…(大文字小文字区別)。置換変数 {value}・{logs} で counter 値・log path 取得。データコレクターセット停止時 task 実行で cleanup スクリプト連携可能。

【JSAI2026参加レポート】LayerXが産学交わる国内最大規模のAI学会に参加してきました！

• URL: https://tech.layerx.co.jp/entry/2026/06/22/092025
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: LayerXがJSAI2026に参加し、AI Agentの導入における顧客データ保護とセキュリティ管理について発表。プラチナスポンサーとして出展し、学生や業界関係者との交流を通じて、AI社会実装の課題と解決方法を共有した。

詳細

LayerXはJSAI2026の40周年大会でプラチナスポンサーとして参加。AI Workforce事業部が「セキュリティ管理の現在地と次の一手」をテーマに、AI Agentの導入時に顧客の重要なデータを守る手法を紹介。企業ブースでは、AI Agentによる業務変革、Agent開発プロセス、FDEビジネスモデル、組織開発について多くの学生や企業関係者と対話。会期中のランチ懇親会では、研究と応用のバランス、モデル開発の未来などについても意見交換。学会での気付きとして、記述式答案の自動採点精度評価や文書画像のテーブル認識に基づく文字列秘匿化に関する研究も紹介。

Codex×AGENTS.md×MCPで大規模リポジトリのバグ修正精度を高める実装ガイド

• URL: https://zenn.dev/0h_n0/articles/ff39679e7b4b27
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Codex Subagents と AGENTS.md＋MCP で大規模リポジトリのバグ修正精度を向上。静的指示（AGENTS.md）と動的コンテキスト（MCP）の併用で、ランタイム 28.64% 削減、性能 30～80% 改善を実現。

詳細

AGENTS.md は効率を改善（ランタイム -28.64%、出力トークン -16.58%）だが成功率が 3% 低下する矛盾がある。人間が書く AGENTS.md は最小限の要件のみに限定すべき（150-200 行以内、自動生成は避ける）。テストコマンド、非自明なアーキテクチャ決定、禁止事項の 3 カテゴリに絞る。MCP（Model Context Protocol）で Filesystem・Context Engine・Sentry・GitHub・Context7 など 5 つのサーバーを組み合わせてバグ修正時のコンテキスト取得を自動化。Codex Subagents の Explorer（読取専用、コンテキストマップ構築）→ Worker（読み書き、修正実行）パターンでバグ修正精度向上。モノレポでは階層型 AGENTS.md 設計（ルート・サービス・パッケージ層）で 32KiB 制限対応。静的指示＋動的文脈のハイブリッド戦略構築。

WindowsでSakana AIのFugu UltraをCodexで使う方法

• URL: https://zenn.dev/acntechjp/articles/882016a23b324e
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Windows環境でSakana AIのFugu UltraモデルをCodexで利用するための設定方法を解説。モデルカタログ、プロファイル、API設定、APIキー取得から起動までの手順を段階的に説明。

詳細

Sakana AIが2026年6月に発表したFuguはCodexなどのAI開発ツールに統合して使う。Codex 0.141.0以上で、/.codex/fugu.jsonにモデルカタログを設定。fugu.config.tomlでプロファイルを指定し、config.tomlでSakana APIプロバイダーを登録。SAKANA_API_KEY環境変数を設定後、codex -p fuguで起動。モデル切り替えは/modelコマンドで実施。トラブル時は/.codex/.envの誤設定を確認。

【2026年最新】Claude Codeトークン削減ツール完全整理 — rtk・headroom・lean-ctx・h5iの使い分け

• URL: https://zenn.dev/amu_lab/articles/claude-code-token-tools-guide-2026
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Code のトークン削減ツール rtk・lean-ctx・headroom・h5i は競合ではなく圧縮する層が違うため積層して使う。シェル出力・ファイル読込・会話コンテキスト・記録監査の各層でボトルネックを特定し逆引きで選ぶ。迷ったら rtk＋headroom から。

詳細

Claude Code のトークン削減ツール 4 種がすべて「最大 99% 削減」を謳うのは、削っている層が違うから。LLM に送られるトークンは 4 層に分けられる：(1)シェル出力層（git diff/log/grep の標準出力）→ rtk、(2)ファイル読み込み層（Read で丸ごと読む・再読込）→ lean-ctx、(3)会話コンテキスト層（長時間セッションの過去やり取り）→ headroom、(4)記録・監査層（圧縮元データの完全復元）→ h5i。層が違うので競合せず積層できる。代表例は rtk（入口でシェル出力を削る）＋ headroom（セッション全体を削る）。競合するのは同じ層のツール同士（rtk と h5i など）のみ。削減率の代表値：rtk は git diff 約 99%、lean-ctx は再読込キャッシュほぼゼロ、headroom は 30 万トークンの会話を約 93% 削減し GSM8K で正答率劣化なし、h5i は git log -p 約 99%。headroom は CCR（可逆圧縮）で元データをローカル保持し headroom_retrieve で完全復元でき、削りすぎ事故の保険になる。トークン削減はコスト節約と同時に lost in the middle を防ぐ精度維持施策。アンチパターン：一番削れるツールを 1 つだけ探す、小出力にも圧縮をかける、不可逆圧縮で重要情報を消す、KVキャッシュを壊す、計測しない。ボトルネック層から逆引きで選ぶ。

実装はAIが飲み込む時代、データ基盤構築で人は何をする？ AI駆動開発の全体設計図（第1回）

• URL: https://zenn.dev/ase_dataeng/articles/20260621-data-platform-ai-blueprint
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: 実装もガバナンスも AI とクラウドベンダーが飲み込む時代に、人に残るのは特定基盤に依存しない要件定義。フェーズ × 4 つの関心事（価値・ガバナンス・実行・方法論）でデータ基盤構築の全体設計図を示す第 1 回。

詳細

データ基盤を要件定義からリリース・運用まで AI と一緒に作る前提で全体像を整理する連載第 1 回。現状認識として(1)自然言語からの ETL 生成など実装はビッグテック/AI が飲み込みつつある、(2)ガバナンスもプラットフォームに内製化されつつある、(3)それでもプロジェクトは失敗する（ガートナーはエージェンティック AI プロジェクトの 40%超が 2027年末までに中止と予測）。コモディティ化しないのは「何を・誰のために・どんな価値で・どんな統制で作るか」の要件定義。全体設計図は開発フェーズ（要件定義→設計→タスク→実装→テスト→運用）を縦軸、4 つの関心事を横軸に置くマトリクス。4 つの関心事は優先度順に①価値（基盤非依存・持ち運べる）②ガバナンス（基盤非依存）③実行（交換可能・どの AI エージェントを使うか）④方法論（交換可能・どの開発手法）。①②と要件定義は持ち運べ、③④は差し替え可能な一例。各フェーズ境目に承認ゲートを置き、後フェーズで詰まったら前フェーズに戻る手戻りループで全体を回す。この「進む→測る→ずれたら戻る」構造は制御工学のフィードバック制御に似ており、ループエンジニアリングもこの延長線上。方法論には仕様駆動開発（SDD）の国産 OSS cc-sdd を採用（あくまで一例）。次回以降は製造業の設備データ基盤（設備停止予知・OEE 改善）を通し例にする。

Claude Codeのsettings.local.jsonの許可リストが619件に膨張 → ワイルドカード統合で133件に圧縮した

• URL: https://zenn.dev/claute_colo/articles/permission-list-cleanup-20260620
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Code の settings.local.json 許可リストが 619 件に膨張したのを、引数違いをワイルドカードで統合して 133 件に圧縮。1 件ずつは正しい判断でも積み重なると人間が読めなくなる、許可と管理は別問題という気づき。

詳細

クライアント環境の総点検中、settings.local.json の allow エントリが 619 件に達していた（python3 系だけで 94 件）。スクリプト実行のたびに許可を求められ、引数が少し違うだけで別ルールとして積み上がっていた。同じスクリプトの引数違いを 1 つのワイルドカードルールに統合（Bash(python3 ~/Projects/**/.py) など）。読み取り専用コマンド（ls/grep/find）は引数なしで一括許可、破壊系（rm/pkill）は対象パスを限定したまま残し、変更前にバックアップを取得。Bash だけで 79 ルールに統合し最終 133 件まで圧縮。数を減らすこと自体が目的ではなく、619 行を人間が読んで必要性を判断するのは不可能だが 133 件なら読めるという点が本質。許可を求めることと許可を管理できることは別の話。

Blazor WASMでExcel解析ツールを作ってAzure Static Web Appsに公開した

• URL: https://zenn.dev/clavisflow/articles/96fda6a6e7325c
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Blazor WebAssembly と ClosedXML で Excel ファイルをサーバー送信なしにブラウザで解析するツール「エクセルドクター」を実装。VBA マクロ抽出も Codex で数分で実装可能。Azure Static Web Apps にサーバーレスデプロイ。

詳細

Blazor WASM（.NET 10）と ClosedXML を使い Excel ファイルをローカルのみで解析。.xlsm を ZIP 展開し vbaProject.bin（OLE Compound File 形式）から VBA ソースコード抽出。実装は Codex に丸投げで数分で完成。Azure Static Web Apps へ GitHub Actions 自動デプロイ。カスタムドメイン設定で 404 発生時は index.html に fingerprint 付き起動スクリプト指定と dotnet publish 済み成果物の直接アップロード（skip_app_build: true）で解決。実装よりカスタムドメイン運用の方が時間要するほどツールが有効。

CodexとRPG Maker MZで政治サスペンスRPGの体験版導線を仮組みした記録

• URL: https://zenn.dev/deep_zen/articles/codex-rpg-maker-mz-prototype
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: RPG Maker MZで政治サスペンスRPG「BABEL-LINK 2060」の体験版導線を、Codexと共に資料整理とスクリプト自動化で仮組み。マップID設計、データベース一括反映、イベント導線生成、監査スクリプトで土台を高速構築。

詳細

RPG Maker MZで2060年AI管理社会を舞台とした育成バトルRPG開発。直接MZ エディタに入る前に、SETTING_BIBLE、VISUAL_BIBLE、DEMO_SPEC、AIコンパニオン仕様などをMarkdownで設計。属性を「情報→産業→生体→秩序→反逆」の5ループに簡潔化。パルススキャンで敵の属性・弱点・耐性を可視化。MZのJSONベース設計を活用し、node tools/apply-battle-database.mjsでスキル、敵、ステート、トループIDを一括反映。node tools/apply-demo-prologue-events.mjsで体験版導線（EV001～EV024）を6マップに生成。node tools/audit-project.mjsで監査（JSON整合性、パルススキャン存在確認、開始位置チェック、イベント名検証）。プレイテストで導線の詰まり、通行不可、敵バランスを逐次修正。見た目UIはまだ標準だが、導線と仕様の確定を優先。

CodexでYouTube動画編集の半自動化GUIを作った記録

• URL: https://zenn.dev/deep_zen/articles/codex-youtube-auto-edit-pipeline
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: YouTube制作ログ動画の繰り返し作業を減らすため、Codexと共に台本、音声、録画、素材をタイムライン構造にまとめた半自動化パイプラインを構築。GUIで調整、本編とショートを同一素材から生成、投稿メタ情報まで自動化。

詳細

毎回同じYouTube動画編集作業（台本作成、音声生成、画面録画配置、字幕合わせ、キャラ・ロゴ配置、本編/ショート出力）を自動化。最初はJSONのみで編集を考えたが、字幕位置、キャラサイズ、セクション分け、再生速度などの調整が必須になり、npm run video:guiでブラウザGUI起動に変更。Markdown台本→セクション/発話/話者の構造化→timeline.json生成→VOICEVOX音声→Remotionプレビュー→本編MP4/ショート出力の流れ。project.jsonとして調整内容を保存。本編とショートの両者を同素材から生成。投稿は、YouTube Data APIで自動化（ローカルOAuth情報は公開リポジトリに含めない）。音声はまだVOICEVOXだがCustom Voice系への差し替えも想定。

【2026】Claude Code SDKで自動PRレビューCI構築

• URL: https://zenn.dev/itsuya/books/2026-claude-code-sdk-pr-ci-6f7e7f94
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: GitHub Actions 上で Claude Code SDK を走らせ、PR 差分を自動レビューしインラインコメントを返す CI を構築。月 $8 運用で、誤検知率を 3 週間で 42%→9% に下げたプロンプト調整と失敗報告まで扱う実装本（有料本のため本文は章構成のみ取得）。

詳細

GitHub Actions 上で Claude Code SDK を走らせ、PR 差分を自動レビューしてインラインコメントを返す CI の実装。章構成は、完成形（18 行の yml で PR に Claude コメントが付くまで）、query() と git diff の接続コード、GitHub API への reviewComments 投稿の落とし穴 4 つ、誤検知率を 42%→9% に下げたプロンプトと除外ルールの差分全公開、月 $8 で回す本番運用（必須 PR のみ起動・キャッシュ・コスト監視ダッシュボード）。コピペで動く yml と Python、レビュー漏れ 7 件の失敗報告も含む。約 13,824 字・500 円の有料本のため、取得できたのは章構成と概要のみで本文詳細は取得不可。

Obsidianで自由にジャーナリングし、Codex Automationsで後から分析する構成を作った

• URL: https://zenn.dev/kakecake/articles/20260621-obsidian-codex-journaling
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Obsidian での自由ダンピングジャーナリングと Codex Automations による自動分析の分離。日次は事実・解釈・認知偏り・次手を構造化、週次は直近 7 日を中心に全履歴と比較して長期傾向を把握。

詳細

ジャーナリング継続の課題は「書く時点で整理しようとして止まる」こと。Obsidian で完全に自由なダンピング→Codex Automations（日次・週次）で後から構造化に分離。人間はダンピング・Codex は構造化を専念。日次 Automation では本日の未分析ノート＋直前の未分析ノート両方を拾い（取りこぼし防止）、事実/解釈/認知偏り/次の一手を追記。週次は直近 7 日を主対象だが全履歴を比較参照して長期傾向と最近の変化を分離。タグを固定（#評価不安 #読心など）し感情そのものより分析ラベル重視。Graph で人物・案件・認知パターンの反復を可視化。設定は Obsidian（01_ジャーナリング にYYYY-MM-DD.md）+ Codex App Automation（Daily・Weekly schedule、local project、read-write 権限）+ 手帳ログ参照（00_手帳）。過去ログ参照を 1～2 件に抑え、優しいトーン分析より事実ベース分析が毎日続きやすい。

Claude × Codex のクロスモデル 2 段レビュー — 単一モデルの盲点を別モデルで埋める

• URL: https://zenn.dev/kashi923/articles/22e9c055eea62f
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude と Codex のクロスモデルレビューで、単一モデルの盲点を埋める。4段階（設計・テスト設計・実装・テスト結果）に観点を分離し、project-aware Claude と fresh-eyes Codex を順次重ねることで、盲点漏れを減らす。

詳細

Step内を4 Stage（設計・テスト設計・実装・テスト結果）に割り、各 Gate で Claude（project-aware）と Codex（fresh-eyes）を順次実行。Claude が最初にプロジェクト規約・設計決定ログを踏まえてレビュー、指摘記録＆修正適用。その後 Codex が修正版に「何も知らない第三者」として一般的な設計理論・best practice で見る。観点を B（両者必須）/ C（Claude特有）/ T（Codex特有）のID体系で一元管理。記録は独立ファイル分離（claude/codex互いに見ない）。Codex 外部送信時はパスフィルタで個人資産データ・秘密鍵・ランタイム生成物を除外。モデル割り当てはステージごと（Stage 3ではドメイン・分析ロジックなら gpt-5.5、他は gpt-5.3-codex に自動振り分け）。実運用では指摘が25～28件と多く、別モデルだからこそ拾える項目が毎回数件混在。「修正が新たに生んだ問題」や「文脈を知らない者には伝わらない暗黙前提」が両者で補完される。

ClaudeCode使ってゲーム作ったら1時間くらいでゲーム作れるんじゃね？と思い結局2週間かかった話

• URL: https://zenn.dev/kobae801801/articles/20ea5b213342b7
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Code・Unity MCP でハエトリグモ題材のゲームを開発した記録。1 時間想定が結局 2 週間。コーディングや規約整備は加速したが、演出・絵作り・アニメーションは人間の手が必要で、何を作るかや方向転換の判断も人間が担った。

詳細

Claude/Claude Code でコーディング、Gemini でサウンド・UI、Tripo で 3D モデル、Blender でアニメーションと用途別に AI を使い分けてハエトリグモのゲームを開発。Unity MCP と Claude Code を連携し日本語指示でスクリプト生成→Unity 配置まで自動化。CLAUDE.md に MVP パターン・命名規則・禁止事項（Update/Manager 禁止など）を書き溜め規約に沿ったコード生成を実現。claude.ai のチャットで「Claude Code へのプロンプトを作って」と依頼する使い方が意図ズレを減らした。一方、Tripo のアニメ自動生成は人外モデルで破綻し Blender で手付け。Shader（Dissolve・ネット発射演出）は丸投げできず、作り方を教わりながら半手動実装。Unity バージョン差で存在しない古い機能を提案されることが約 10% あり常に検証が必要。PR/Slack 連携でログ取得すると週のクレジットが不足するため、節約ならコード生成までが良い。素材（Gemini/Tripo Pro）は商用利用 OK を確認。コンセプト・規約の最終判断・詰まりの検知と方針転換・進捗管理は人間の領域。

AIサブエージェントは何に効くのか: 高リスクレビューで試した運用メモ

• URL: https://zenn.dev/kota_suzuki/articles/ai-subagent-high-risk-review
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AIサブエージェント運用は万能ではなく、高リスク読み取りレビューで効果が出やすい。権限境界の曖昧さによる読み違いを複数観点から捕捉でき、ただし読むだけのレビューと実行許可の境界を厳格に分ける必要がある。

詳細

AIサブエージェント運用の実験結果。高リスク読み取りレビューでは権限境界、証拠の扱い、自動化・公開・展開境界を分けた複数観点レビューが効く。「レビューした」が「実行してよい」に読めてしまう曖昧な文書構造を複数エージェントで検出。重要な運用ルール：(1)読むだけ明示、(2)観点分離、(3)親エージェント統合、(4)軽いタスクに使わない。初回出力チェックで格式検証や必須項目確認も重要。「優位候補を選べた」と「本番進行OK」は違うため、権限境界が不明確なら採用しない。使用価値は①重要論点拾い、②指摘有効性、③範囲外ノイズ抑制、④読むだけ境界維持、⑤軽いタスク非使用の5条件を満たすときのみ。実装・本番・セキュリティ周辺データ処理には広げない。

同じ指示は、Claude Codeのどの層に書くべきか？CLAUDE.md・Skill・サブエージェント・フックを実測で比較する

• URL: https://zenn.dev/livingston/articles/3eeacb72733171
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Code の同じ指示を CLAUDE.md・Skill・サブエージェント・フックの 4 層すべてに実装し、N=20 で遵守率を実測比較。決定論的強制はフックでも matcher の穴で破られ、毎ターンのスタイル規則は CLAUDE.md が圧勝、状況限定の手順は Skill が得意と判明。

詳細

Claude Code の指示の置き場所（CLAUDE.md・Skill・サブエージェント・フック）を、性質の異なる 3 指示で各層 N=20 実測（claude -p headless モード・外形証拠で機械判定・約 $54）。指示 A（破壊的削除の禁止）：CLAUDE.md と Skill は 20/20、サブエージェントは「整理担当」の役割に引きずられ 14/20、フックは Bash の rm は exit 2 でブロックするが Python の shutil.rmtree の穴を通られ 16/20。フックの決定論性は matcher の網羅性と不可分で、任意コード実行が許可されたエージェントは想定外経路を見つける。指示 B（スキーマ編集時に version 上げ＋CHANGELOG 追記）：baseline 0/20、Skill は description が編集タスクにマッチし 19/20、progressive disclosure で発動しない普通の作業ではトークンをほぼ消費しない。指示 C（コメント日本語化）：CLAUDE.md 20/20 だが Skill は 6/20（汎用コーディングプロンプトで description がマッチせず未ロード、Fisher 検定 p<0.0001）。毎ターン効かせたいスタイルは Skill 不向き。サブエージェントの隔離効果は軽い調査ではゼロ（コスト +78%）、全ファイル読込の重い調査で初めてメイン文脈を 45.9K→36.8K に抑える価値が出る（総コスト +45%）。

CAE AIエージェントは、規定書通りにボルト固定部の応力評価ができるか？: Codex + CalculiX

• URL: https://zenn.dev/ms_ai/articles/1734836e957c4b
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AIエージェントがCAE規定書を読んで、ボルト固定部の応力評価を規定書通りに実行できるかを検証。メッシュ生成、RBE3結合、応力抽出まで一連の作業をCodexで自動化し、プロ仕様のマップドメッシュが生成される可能性を示唆。

詳細

CAE実務では応力評価規定書に従う必要がある。Codex + CalculiXで架空の規定書を読ませ、ボルト穴応力評価の完全自動化を試行。STEPファイルに座面相当領域の分割がない状態でも、AIエージェントが規定から必要なメッシュトポロジーを逆算し、Pythonで穴周辺の決定論的O-gridを生成。周方向24分割、径方向分割数を可変に、円形メッシュから正方形境界への遷移まで、汎用メッシャーではなく専用スクリプトで実装。評価位置は「穴エッジから1要素内側」の節点集合を自動化でき、手作業での見落しを削減。人間のCAE技術者はCAD側でまず形状を分割する思考だが、AIは評価手順から逆算して実装する点が特筆的。

iOSアプリ開発に役立つAgentic Coding集

• URL: https://zenn.dev/mtfum/articles/ios_agentic_coding
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: iOS アプリ開発で AI エージェントを活用するためのツール集。Xcode MCP（mcpbridge）でローカル完結の Xcode 接続、Xcode 27 の Apple 公式 Agent Skills、Swift-Agent-Skills キュレーション、sosumi.ai などのドキュメント最適化サービスを整理。

詳細

iOS アプリ開発の Agentic Coding ツール・リソース集。Xcode MCP（mcpbridge）は Xcode 26.3 導入・27 で本番対応の MCP サーバーで、Claude Code/Cursor/Codex などが Xcode プロセスに直接接続。macOS 26 Tahoe + Apple Silicon 必須で API キー・クラウドリレー不要のローカル完結。ファイル操作 9・ビルドテスト 5・診断 6 の計 20 ツールを提供し、RenderPreview は SwiftUI プレビュー画像を返すため UI 検証をエージェントに任せられる。セットアップは claude mcp add –transport stdio xcode – xcrun mcpbridge。Xcode 27（WWDC26）には Apple 公式 Agent Skills（swiftui-specialist、uikit-app-modernization、test-modernizer など）がバンドルされ SKILL.md 形式で xcrun agent skills export で抽出可能。フレームワーク知識補完が目的でプロジェクト固有規約には非対応。その他 Xcode 27 変更点は Device Hub（シミュレータ統合）、オンデバイスコード補完（Neural Engine・外部送信なし）、サードパーティ AI 統合、Agent Client Protocol（認可レイヤー）。Paul Hudson 氏管理の Swift-Agent-Skills は人間執筆のみのキュレーションリポジトリ（SwiftUI/SwiftData/Concurrency/Testing/Accessibility など）。sosumi.ai は Apple Developer Documentation を llms.txt 形式でエージェント向け最適化配信、llm.codes はドキュメントの LLM 向け変換解説。

Claude Code でOpusを使い切る——設計はSonnet、実装はプロジェクト直起動

• URL: https://zenn.dev/muramasa0228/articles/2026-06-22-claude-code-opus-pattern
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Opus をサブエージェントとして呼ぶと重要判断が Sonnet オーケストレーターに戻り性能上限になる。.claude/settings.json で Opus を指定しプロジェクト直起動することで、Opus 自身が主体として判断・実装を担う。設計は Sonnet、引き継ぎは CLAUDE.md。

詳細

Claude Code のマルチエージェント構成で Opus をサブエージェントとして呼ぶと、コードを書くのは Opus でも、複数ファイル変更・ビルドエラー対処・実装方針調整などの判断がオーケストレーター（Sonnet）に戻る。サブエージェントはメインの文脈やファイル状態を引き継がず毎回ゼロから把握するため、オーケストレーターの性能が実質的な上限になる。解決策は .claude/settings.json に claude-opus-4-8 を指定し、プロジェクトディレクトリで claude を直接起動すること。Opus がオーケストレーターかつ実装者となり、判断・実装・確認・修正をすべて担って文脈の断絶がなくなる。設計は Sonnet で十分なので、コンシェルジュセッションで仕様を詰め、決定事項を CLAUDE.md に書き残せば、次に Opus が起動時に最初に読み込む引き継ぎ書として機能する。匿名通話アプリ EchoMask のキャリブレーション機能再実装で、Sonnet が設計（廃止原因特定・再実装フロー・フォールバック廃止方針）を CLAUDE.md に記録し、Opus が実装する分担を実践。設計コストを Sonnet で払い実装品質を Opus に担わせる構造。

Claude Code で Obsidian デイリーノートに「自分の Git コミット」を自動追記する — /daily:git 最小構成

• URL: https://zenn.dev/mutton/articles/f3fa9f249e9c77
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Code で Obsidian デイリーノートに自分の Git コミットだけを自動追記する /daily:git 最小構成。HTML コメントのマーカーで囲んだ領域だけを冪等置換し、手動メモを壊さず作業実績を機械集約する。

詳細

個人開発では作業の正本が git にあるが振り返りは Obsidian デイリーノートを使うため分断が摩擦になる。Claude Code 経由で自分の Git コミットだけをデイリーノートの「## やったこと」に流し込む最小構成 /daily:git を構築。最初の取り込み口を git にする理由は、ほぼ全エンジニアが既に使い、認証・API キー不要、成功失敗がファイルで確認しやすいから。デイリーノート全体ではなく HTML コメントのマーカー（daily:summary:git:start/end、PC 別の子マーカー {HOST}）で囲んだ領域だけを置換するため、手動で書いた bullet の外側は壊さない。子マーカー内側を丸ごと置換することで、同日に複数回実行しても bullet が増えない冪等性を確保し「実行忘れしても直せる」設計になる。処理は収集（過去 7 日の自分のコミットを git log で取得・worktree も含む）→整理（author date を JST 化・日付別グループ化）→準備（当日ノート作成）→反映（要約は「やったこと」、詳細は「ログ詳細」へ）→state 保存の 5 ステップ。author email が git config user.email と一致するコミットのみ拾う（別メールは git-authors.txt に追加）。配管（スクリプト・コマンド）と資産（ノート本文）を分け、CLAUDE.md に境界を書くことで自動同期の暴走を防ぐ。コミットメッセージを「何を・どこを」書く形にすると振り返り価値が上がる。

AIのSkillsを、問題集でテストしてみた。Waza風evalをCodexで回す話

• URL: https://zenn.dev/noprogllama/articles/4f1a53c1e9b779
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AI用のSkill手順書をWaza風の問題集でテスト。期待する出力形式、失敗時の扱い、空データ処理を問題集に明示することで、Skill本文を改善する切り分けが明確になり、改善サイクルが加速。

詳細

Skillの品質改善にテストを導入。夜ブリーフィングSkillで4問の問題集を作成。waza checkで問題集検証、Codex CLIで実行。最初は形式チェック Low、通過率50%（2/4）だった。Skill側に「何をする/しない」を明示し、問題側に失敗時・空データ時の出力形式を明記。修正後は形式チェック High、通過率100%に改善。初回では問題文に答えのヒントが多すぎて差が出なかったため、別問題集で試行。最終版では必要見出し出力、勝手な記事生成禁止、空データ表記、失敗時の短報告、不関連依頼の非実行を確認。複数Skills（skill B, skill C）にも軽く適用し、出力形式安定性と実行境界判定が改善。注意：4問では限定的で、モックで100%でも実運用品質は別。日付違い、記事数多数、要約欠落など問題追加が望ましい。

同じAIエージェントでも成果物に差が出る — メンバのレビューで気づいたこと

• URL: https://zenn.dev/nu_dev/articles/a880f08487b9d7
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: 同じ AI エージェントを使ってもメンバー間で成果物に差が出る理由は、ツールやプロンプトではなく人間側の観点にある。専門性は生産そのものより前端（前提・上流確認）と後端（検証・トレーサビリティ）に寄り、設計レビューの習慣が指示の質を決める。

詳細

配下メンバーと AI エージェント（Claude Code など）でペアプロ的に開発する中で「プロンプトの勉強になった」と言われるが、筆者はプロンプトを勉強していない。同じツール・モデルでもレビューすると差が出るのは、人間側の観点が原因。品質差はコードより設計書・仕様書などドキュメントで顕著。筆者の 3 ステップ（一次作成＝コマンド化済み／レビュー＝質問形式／上流整合性確認＝トレーサビリティマトリクス）のうち、メンバーが学んだのは 2 と 3。一次作成は一般化された「中間」で誰がやっても同じ結果が出るため、専門性は前端（前提・上流確認）と後端（検証・上流接続）に寄る。レビューで見る観点：要求仕様の過不足（特に「過」＝冗長設計・不要機能の削減）、unit 間の整合性、社内文化・既存機能との整合、AI の前提ずれの訂正。これらの一部は markdown で構造化すれば AI も参照できるが、整備の man-power が不足し人力で肩代わりしている状態。レビューは指摘型から質問型（なぜこの技術を選んだか・上流要求を満たせるか）に変化。技術知識は差をつける要因ではないが、説明の筋を判断する「床」として必要。観点をコマンドやガードレールに落とす検討中だが、若手育成上、観点を渡しすぎると自分で判断する機会が減る難しさがある。

ClaudeCodeにSalesforce公式スキル「sf-skills」を入れてみる｜LWCとApexのベストプラクティス構築を実現

• URL: https://zenn.dev/pacific_creator/articles/ebd995006fc30d
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Salesforce 公式の AI スキルパッケージ sf-skills を Claude Code に導入する解説。npx skills add の 1 コマンドで、LWC・Apex・テストクラスをベストプラクティス準拠で一括生成。Code Analyzer 自動通過・カバレッジ 75% 担保が特徴。

詳細

汎用 AI はSalesforce のガバナ制限・共有モデル・テストカバレッジのお作法を自力で判断しきれないが、Salesforce 公式 GitHub 公開の sf-skills を入れると自動で守る。2026年6月時点で 60 以上のスキルを収録（generating-apex、generating-apex-test でカバレッジ 75% 担保、generating-lwc-components、debugging-apex-logs、generating-flow など）。Claude Code/Cursor/Codex/OpenCode 対応。インストールは npx skills add forcedotcom/sf-skills の 1 コマンドで、Project/Global スコープと Symlink（更新自動反映）/Copy 方式を選択。skills-lock.json で導入済みスキルを確認。自然言語で「Account 作成フォームを LWC で作って」と指示すると LWC（html/js/css/meta.xml）と Apex コントローラを一括生成、Code Analyzer 自動実行・テストも走らせ問題があれば修正まで対応。注意点：sf-skills は npm パッケージとは別物（GitHub から取得）、生成コードは本番デプロイ前に必ず目視レビュー（フィールド API 名・カスタムオブジェクト存在・共有モデル）と Sandbox テスト必須。スキルの入れすぎはトークン消費増・誤発動・管理困難を招くため、使うものだけプロジェクト単位で導入し npx skills check で棚卸し推奨。

「AIにユーザビリティ評価させる」Skillを作って詰まった場所と、その解決策8つ

• URL: https://zenn.dev/pksha/articles/8f4d45b913ed50
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AI にユーザビリティ評価（ヒューリスティック評価）をさせる Skill を作る過程で詰まった場所と解決策 8 つ。インプット形式別ワークフロー定義、UI ケースとチェックポイントの並べ方、サボり検出ループなどで精度を上げ、評価時間を約 1/10 に短縮。

詳細

全社で使えるヒューリスティック評価 Skill（評価精度 30〜40% の最低限ガードレール）を作る過程の知見 8 つ。AI が網羅スキャンと課題出力、人間がビジネス文脈での取捨選択と最終承認という役割分担が前提。(1)インプット形式別（コード/スクリーンショット/ライブ画面/混在）のワークフロー定義で読み込み精度向上。(2)テーブルには UI ケースとチェックポイントだけ並べ、カテゴリ・原則はタイトル側に表示して拡大解釈を防止。(3)評価項目（チェックリスト完全コピー）と評価結果を同じ行に並べ、解釈ずれを再評価。(4)Must 項目と条件依存項目を分け、ケース一覧を最初に見せて contextual を読む必要性を判断（トークン節約）。(5)UI コンポーネント単位（ボタン・フォーム・モーダルなど 9 カテゴリ）で確認すべき状態変化を定義し抜け漏れ防止。(6)何を未確認かをテーブル出力して手動補完の状況を作る。(7)未確認理由を区分し「操作未実施」（サボり）だけを再実施させる。一度サボりを含めて出させてから最後に回収する方法でサボりが減少。(8)複雑化したステップを SKILL.md にまとめ詳細は md で都度読み込む情報構造化。結果、評価時間が約 1/10 になり、ノンデザイナーの PR にも課題検出可能に。

使用コストも出せるE2Eを作ったら、Codexに予算を渡して改善ループを回してもらえるようになった話

• URL: https://zenn.dev/prg_yukke/articles/4ed130585846c3
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: 実通話 E2E に費目別コスト台帳と予算上限を持たせることで、Codex に「品質を保ったまま予算内で改善」を委譲。1 通話あたり 25.9% コスト削減（音声生成モデル 30.9% 削減）を実現。

詳細

電話 AI「スパ電」のコスト改善。従来の E2E は pass/fail のみだが、費目別 cost ledger（音声生成・通話基盤・録音・ストリーム・補助処理に分類）と予算上限を追加。60 件ベンチマークで音声生成モデル 47%（受電 72.6%）が支配的と判明。cost ledger 導出後、Codex への依頼が「通して」から「予算 10ドル内で品質保ったまま改善」に変化。Codex は改善案 → 実装 → E2E 実行 → cost 計測 → 判定（採用/破棄）のループを自律実行。採用 9 件・見送り 7 件で 1 通話あたり -25.9%（音声生成 -30.9%）削減。品質ゲートと予算上限が同じループに乗ると、試行暴走防止と「安いが品質低下」の案が自動排除。E2E 戻り値設計がエージェントの目的関数そのもの。

AI専用動画編集ツールにGPU文字起こしを足したら、whisperはCPUでも『GPU使用』と自己申告してきた — clipwright

• URL: https://zenn.dev/satoh_y_0323/articles/1bb9ddf4f5cf1f
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AI 専用動画編集ツール clipwright に GPU 文字起こしを追加。機能コードはほぼ 0 行だが、whisper が CPU 実行でも「use gpu = 1」と自己申告するトラップが最難関。AI が唯一の判断材料とするツール出力の観測サーフェス設計が本質。

詳細

AI エージェント専用の動画編集 MCP サーバー clipwright に 3 機能追加（素材連結・画像オーバーレイ・GPU 文字起こし）。主役は GPU 文字起こし。whisper.cpp の CUDA ビルドを指すだけで GPU 化でき機能コードはほぼ不要だが、「GPU で動いたか」を AI に伝える観測が難関。AI が手にできるのはツールの JSON エンベロープのみで、device: cuda が書かれなければ判断不能。トラップ：whisper は CPU 実行でも use gpu = 1（要求パラメータ）と出力し、本当の結果は数行下の no GPU found。backend 初期化の結果行だけ見る設計に。JSON systeminfo は CPU 命令セット表で device 情報なし。CWE-209 でモデル絶対パスが stderr に漏れるため固定ラベルのみ返しサニタイズ二重化。realtime_factor の式が README で逆向きだったが、AI は docstring を契約として読むため実装バグと同じ実害になり High 扱いで修正。教訓：机上レビュー（シェルを持たない design-critic エージェント）は方向を当てるが、結論は実バイナリ（whisper-cli/ffmpeg）の出力で出す。ffmpeg フェードも「正しそうな書き方」がパースで落ち、回りくどい書き方だけ通る。テスト環境が新コードを黙ってシャドウする罠も効果実測 e2e で検出。

AIエージェントのOpenTelemetryは、other 46.7%を見つけてからが運用だった

• URL: https://zenn.dev/seeda_yuto/articles/ai-agent-otel-schema-maintenance
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AI エージェントの OpenTelemetry では、ツール分類スキーマが古くなると other が半分近くに膨らみダッシュボードが読めなくなる。MCP・agent_task など新種ツールを追うため、分類器はダッシュボードと一緒に保守する運用物として扱うべきという知見。

詳細

Claude Code の JSONL（ツール実行とターンのメタデータ）を OpenTelemetry Span に変換して可視化する運用。Span 階層は session→turn→tool_call で、会話本文・ファイルパス・コマンド本文・認証情報は載せず、ツール名・カテゴリ・サイズ・エラー有無・トークン数のみ記録。Web サービスは HTTP/DB/外部 API で分類が安定するが、AI エージェントは MCP・チャット連携・スケジューラ・自作ツールが増え続ける。2026年6月の 2 セッションを取り直すと、メッセージング経由 MCP ツール（mcp__…__reply）が 7 回で最多だが、旧分類器 v1 では 15 回中 7 回（46.7%）が other に落ちた。v2 で MCP を messaging_mcp/mcp_other に分離。Claude Code を 4 本制御実行すると TaskCreate が新たに other に残り、v3 で agent_task/workflow/scheduler_or_notification カテゴリを追加して other を 0 に。ただし v3 も次のツールが増えれば古くなるため、分類器は一度書いて終わるコードではなくダッシュボードと一緒に保守する運用物。生のツール名はカーディナリティが上がるため正規化（mcp.reply など）し、tool.schema.version 属性を持たせる。other 比率と未知ツール名種類数を監視し、増えたら未知ツール追加か分類器の陳腐化のどちらかとして調査する。

AI開発を速くするほど、ループ設計が大事になる

• URL: https://zenn.dev/spectee/articles/loop-engineering-ai-dev-cycle
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AI開発ループの高速化に伴い、実装速度の次のボトルネックは「AIが安全に何度も反復できるか」に移る。環境ロック、コスト管理、停止条件を含む「ループ設計」がチーム開発では本質的に重要になる。

詳細

Codexなどの高速AIエージェント活用で、かつての「AIがコードを書けるか」から「安全に複数回ループを回せるか」へボトルネックが移った。複数AIエッセッションが並行稼働すると環境競合、デプロイ競合、テスト失敗の原因判別が困難になる。Loop Engineeringでは入力・出力・検証・停止条件・人間確認・還元の6要素を契約として先に定義。環境をループに含めて排他制御し、テスト再実行回数、デプロイ自動リトライ、E2E実行判断などをコスト上限で制御する。個人開発での実践例では、Issues解決速度が2～3個/日から30～50個/日以上に伸長。チーム導入の際は権限委譲を段階的に拡大する方針を採用。

Loop Engineering入門：AI Agentを完了まで自律走行させるOSS

• URL: https://zenn.dev/tackeyy/articles/e72211a1a49609
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: mission は Loop Engineering 向け OSS で、AI エージェントが完了まで自律走行する仕組み設計。計画・実行・レビュー・採点をループし、品質ゲート通過まで止まらない。

詳細

Claude Code /goal は軽量な完了条件向けだが、mission は複雑な複数ステップ作業向け stateful completion layer。.mission-state・レビュー・採点・score history・threshold gate を管理し「なぜ止まってよいのか」を説明可能。単発 prompt は計画欠如・状態未保存・自己申告レビュー・曖昧な採点基準で「終わったふり」で止まりやすい。mission は plan → execute → review → score → iterate ループを plan/review/scorer phase・score history・threshold gate で構造化。短いタスクは過剰だが、issue 修正からテスト・PR 準備、調査・要約・ドキュメント化、リリース前チェック、長期作業継続などに向く。Loop engineering の実験場として OSS 化。GitHub で試用・feedback 募集。

AIに読ませる知識ノートは「言い切り」に注意 — 判断軸で書いて誤動作を防ぐ

• URL: https://zenn.dev/takna/articles/ai-knowledge-notes-judgment-axis
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AI に読ませる知識ノートでは過剰な一般化（限定的な主張を無条件に言い切る）が誤読バグになる。断定が適切な命題もあるため一律に避けず、適用範囲で断定か判断軸かを選ぶ。規約は正本分離の三層で配置し点検を仕組み化する。

詳細

Obsidian の Zettelkasten を Claude Code に読ませて第2の脳として運用する中で見つけた落とし穴。「自動化は半自動が続く」のような限定的な主張を無条件に言い切ると、人間は文脈補完して読み流すが AI は字面どおりルールとして recall し、全自動が正しい場面でも確認を挟ませる。これを過剰な一般化と呼ぶ。ただし断定を一律に直すのは過剰修正。命題は 3 種に分ける：(1)断定でよい（価値観・原体験・観察言明＝自分の判断軸の記録なので誤適用が起きない）、(2)適用条件を本文に添える、(3)判断軸に書き換える（「自動化は半自動」→「確認点は失敗の検知可能性と可逆性で決める」）。判定基準はタイトルの断定形ではなくタイトル＋本文で適用条件が示されているか。リネーム時は旧タイトルを aliases に残し Wikilink 切れを防ぐ。規約は正本分離の三層：正本（_Meta/Vault運用/_index.md に理由と例つき）＋常時ロード要約（プロジェクト CLAUDE.md に 1 行）＋ポインタ（メモリ）。変わりやすい情報ほど変更コストの低い場所に正本を 1 つだけ置く。点検は vault-knowledge-curator スキルに監査項目として組み込み恒久化（67 件中実質修正は 1 件のみ）。

JV-LinkレガシーCOM仕様をClaude Codeで解剖、Lambda 1,000並列でデータリークを暴いた話

• URL: https://zenn.dev/tuvy22686/books/5a414a638331f9
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: JV-Link のレガシー COM 仕様を Claude Code で解析して設計書を生成し、AWS サーバーレスで Lambda 1,000 並列の検証基盤を構築。4,000 倍の高速化がデータリークの罠を暴いた実践録（有料本のため本文は目次のみ取得）。

詳細

JV-Link というレガシー COM 仕様を Claude Code で解剖し、設計エージェントによる仕様解析とコンテキスト制御で設計書を生成。AWS サーバーレスで Lambda 1,000 並列のワークフロー検証基盤を構築し、4,000 倍の高速化を達成、その過程でデータリークの罠を発見した実践録。章構成はアーキテクチャ全体像、JV-Link レガシー COM 仕様との戦い、設計編（設計エージェントによる仕様解析・コンテキスト制御）、インフラ編（Lambda 1,000 並列の AWS パイプライン実装）、検証編（4,000 倍高速化が暴いたデータリークと成果）、レガシー仕様は AI に読ませ人間は検証に集中する時代へという結論。約 13,558 字・1,500 円の有料本のため、取得できたのは目次と概要のみで本文詳細は取得不可。

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

• URL: https://zenn.dev/unsoluble_sugar/articles/fd73c7b67d80ce
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: Claude Design で資産ポートフォリオダッシュボードのプロトタイプ・UI 設計を確定後、Claude Code で実装・本番化。Design ↔ Code の二段構えで、大枠と細部を効率的に分担。

詳細

複数口座の資産（国内株・米国株・投信・金）を一元閲覧するダッシュボード。Claude Design で選択式の要件確認後、3 案プロトタイプ生成。クラシック案（カード+低彩度）採用。Design フェーズでドリルダウン・ドーナツ％ラベル・為替ライブ更新まで詰める。トンマナ：白基調・低彩度・意味ある色のみ（騰落：+赤/-緑、カテゴリ色統一）。Claude Code で本番化：技術スタック決定（dc-runtime・Vanilla JS・GitHub Pages・OTel なし）→ロジック mixin 分離→実データ流入→CI 毎日更新。Shift-JIS 文字化け対応・ドル建て円換算・投信口数・金グラム単位のバラバラを実装段階で吸収。メンテナンスコスト最小化重視（ビルドレス・ローカル python3 -m http.server で動作）。既知脆弱性スキャン・Symbol pinning を試行。デザイン羅針盤を先に作ることで、後の細部変更でも軸がぶれずメンテしやすい。

GLM Coding Planのここ半年をまとめておく

• URL: https://zenn.dev/ykkn/articles/d5f31dc2c375e4
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: GLM Coding Plan の半年間の変動を整理。初期 $3/月から現在 $18/月へ6倍値上げ。週次制限導入、プロンプト枠削減、レガシープラン廃止。モデル GLM-4.6 から GLM-5.2（1M コンテキスト）に進化。複数コーディング ツール横断で利用可能。

詳細

GLM Coding Plan は 2026年1月 $3/月（プロモ価格）から出発。2月11日に $6 → $10、4月12日に $10 → $18（海外）へ段階値上げ。同時に週次制限導入（Lite 400/週、Pro 2,000、Max 8,000）、5時間枠プロンプト削減（3分の2減）。レガシープラン（週次制限なし）は4月30日で自動更新停止、マイグレーション補償として2ヶ月無料＋50%オフ購入権付与。モデルは GLM-4.6/4.7 → GLM-5-Turbo（Max限定）→ GLM-5.1 → GLM-5.2（6月13日全プラン対応、1Mコンテキスト）。API単価 GLM-5.2 は $1.40/$4.40（入力/出力per 100万トークン）で Claude Opus 4.8 の約6分の1。Vision、Web Search、Web Reader、Zread の4つ MCP サーバー提供（Coding Plan ユーザーのみ）。他社比較では $18/月で Kimi Code（$19）と同等だが、複数ツール横断利用が強み。筆者は年初の $360/年（新年プロモ50%オフ、レガシー週次制限なし）契約で 2027年1月までの特典維持。

AWS未経験の介護士が3ヶ月でSAAを取得し、AI駆動で技術ブログを作った話

• URL: https://zenn.dev/yuki_engineer08/articles/5dd7f1fcee9043
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: AWS 未経験の介護士が約 3 ヶ月で AWS SAA を取得し、Claude Code の Planner/Generator/Evaluator による AI 開発フローで Next.js・Terraform・GitHub Actions・S3・CloudFront 構成の技術ブログを公開した話。

詳細

介護士として働きながら AWS を学び始め、2026年3月時点では AWS・VPN・GitHub いずれも知らない状態から約 3 ヶ月で AWS SAA を取得。さらに Claude Code を活用し、Planner・Generator・Evaluator による AI 開発フローを構築。Next.js、Terraform、GitHub Actions、S3、CloudFront を使って技術ブログを公開した。記事自体は導入的な内容で、構成と学習経緯の紹介が中心。

「無料でポーカーを」フリーロールマップをClaude Codeと作った話

• URL: https://zenn.dev/yydev/articles/986b3089292d36
• 日付: 2026-06-23
• Tier: Tier 3
• 要旨: ポーカーのフリーロール開催店舗を地図で探せるサイトを Google Maps API × Supabase × Claude Code で開発。AdvancedMarker の mapId 必須やキー制限、RLS で SELECT のみ public にする設計が要点。Claude Code とは「速く書く」より「気持ちよく使える着地」を意識した協働。

詳細

ポーカーのフリーロール（参加費 0 円トーナメント）開催店舗を地図上でまとめて探せる「フリーロールマップ」を開発。技術構成は Vite + React、Google Maps JavaScript API（@vis.gl/react-google-maps）、Supabase（PostgreSQL）、Vercel ホスティング、Claude Code 開発支援。AdvancedMarker は mapId が必須で渡さないとマーカーが表示されずエラーも出にくくハマりやすい。フロント露出 API キーは HTTP リファラー制限と API 限定が必須。Supabase は RLS を有効化し SELECT のみ public にしておかないと anon key で全テーブル書き換え可能になる。Claude Code との開発フローでは（1）いきなり実装させずスキーマと要件を言語化させ設計を会話で固める、（2）動くものを見て UX の違和感を率直に伝え直すループを速く回す、（3）つまずきは丸投げせず仮説を添えて原因切り分けを速める、を意識。AdvancedMarker/Map ID 使用で Maps JavaScript API の動的マップ扱いになり課金が跳ねるため、キー制限と請求アラートを初日に設定すべきだった。住所しかない店舗は Geocoding で lat/lng を補完。