図面への AI 活用について整理してみた：既存図面活用編

• URL: https://dev.classmethod.jp/articles/ai-for-existing-drawings
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: 製造・建設業の図面を AI で読み取り、業務で使える構造化データにする一連の処理を体系的に整理した論文レビュー調記事。図面 AI の処理フロー（検出→意味付け→関係紐づけ→構造化）、ユースケース（見積・積算・検査項目作成・類似図面検索）、難しさ、VLM の登場による変化を整理している。

詳細

図面 AI の基本フロー：

1. 入力（PDF・スキャン・CAD 出力）
2. 要素検出（文字領域・記号・寸法線・タイトルブロック等）
3. 意味付け（「SUS304」→材料、「φ10 H7」→寸法+公差）
4. 関係紐づけ（公差と対象形状を対応させる、設備記号と配置位置を紐づける）
5. 構造化（JSON/CSV/DB/knowledge graph に変換）
6. 業務活用（見積・検査項目・類似検索・施工準備）

レビュー論文（Jamieson ら）では text annotations・symbols に加えて connectivity information の自動認識が figure digitisation の中心とされている。構造化 JSON の設計例として value・category・related_object・source_region（bbox）の4フィールドが示されている。

VLM（Vision-Language Model）による変化：自然言語で「この図面から公差を抽出して」と指示できるようになった。ただし製造可能性評価・加工形状識別・検査タスクでの正確性・一貫性には課題が残る（引用：VLM 評価研究）。

誤抽出が見積ミスや検査漏れにつながるリスクがあるため、人間による確認フロー・修正履歴・信頼度の設計が実用化の鍵とされている。

Amazon SageMaker Studio で Training Plan による GPU キャパシティ予約が使えるようになりました

• URL: https://dev.classmethod.jp/articles/amazon-sagemaker-studio-training-plan-gpu-capacity-reservation
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: 2026-05-18 のアップデートで SageMaker Training Plan の対象リソースに JupyterLab と Code Editor が加わった。前払い・キャンセル不可・ターゲットリソース変更不可という制約はトレーニングジョブ向けと同じだが、利用期間終了 30 分前に自動シャットダウンが走る点は要注意。オンデマンド比最大 65% オフだが、EC2 Capacity Blocks より割高。

詳細

対象リソース（studio-apps）として購入したプランは Training Job や HyperPod には流用不可。

制約まとめ：

• 購入後キャンセル不可（Studio 向けはドキュメントに2回記載されるほど強調）
• インスタンス追加・削除不可（終了日延長のみ可）
• AWS アカウント間・Organization 内での共有不可
• 予約期間満了 30 分前に稼働中アプリが自動シャットダウン（この 30 分は課金対象外）
• VPC の同一 AZ に空き IP が 1 個以上必要

価格比較（2025年6月時点・バージニア北部）：

• SageMaker Training Plan（ml.p5.48xlarge）：39.7992 USD/時
• EC2 Capacity Blocks（p5.48xlarge）：34.608 USD/時

SageMaker マネージド環境前提なら Training Plan しか選べないが、純粋なコスト優先なら Capacity Blocks も検討対象。インスタンス台数選択肢は 1/2/4/8/16/32/64 台、期間は 1〜182 日。

Security Hub に統合した IoT Device Defender の検出結果をメール通知してみた

• URL: https://dev.classmethod.jp/articles/aws-iot-device-defender-email
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: AWS IoT Device Defender Audit の検出結果を Security Hub 経由で取り込み、EventBridge → Step Functions → SNS を使ってユーザーフレンドリーなメール文面で通知する構成の実装記録。EventBridge に直接 SNS を設定するとメールが JSON のまま届くため、Step Functions を挟んで整形するアプローチを採用している。

詳細

構成：IoT Device Defender → Security Hub → EventBridge → Step Functions（cm-security-alert-mail-machine） → SNS メール

EventBridge ルールのイベントパターンで ProductArn を arn:aws:securityhub:ap-northeast-1::product/aws/iot-device-defender-audit に固定し、Severity.Label を CRITICAL、HIGH で絞り込む。IoT Device Defender Detect の場合は重要度が MEDIUM 固定なので絞り込み不要。

入力テンプレートで <severity>、<title>、<resourceId> などを埋め込んでメール件名・本文を整形している。これにより EventBridge → SNS 直送の JSON 丸ごとメール問題を回避できる。

Security Hub 起点に統一することで、IoT Device Defender 以外のセキュリティサービスも同じ通知経路に乗せられ、通知インフラを集約できるメリットがある。

AWS Security Agent に脅威モデリング機能が追加され、設計ドキュメントやソースコードから STRIDE ベースの脅威分析を自動生成できるようになりました

• URL: https://dev.classmethod.jp/articles/aws-security-agent-threat-modeling
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: AWS Security Agent（AWS Continuum の一部）にパブリックプレビューとして脅威モデリング機能が追加された。設計ドキュメント（Markdown 1.15KB）を投入するだけで STRIDE の 6 カテゴリにわたる脅威が自動分析され、45 ページの PDF レポートが生成された。分析は約 28 分で完了し、プレビュー期間中は追加料金なし。

詳細

入力は「スコープドキュメント（設計書・API 仕様書）」と「ソースコード（GitHub/GitLab/Bitbucket/S3 連携）」の2種類。どちらか片方だけでも実行可能で、コードが存在しない設計フェーズにも使える。

内部処理パイプライン（Logs タブで追跡可能）：

1. document_ingestor → 2. document_analyzer → 3. architecture_merge → 4. trace_identify → 5. scope_resolver（各データフローを1件ずつ評価、21秒）→ 6. posture_prioritizer → 7. 各 Posture * タスク → 8. 各 Trace Threats * タスク → 9. threats_summarizer

API Gateway + Lambda + DynamoDB + Cognito + S3 のサーバーレス REST API 設計書に対して 15 件の脅威が検出（High: 11件、Medium: 4件）。検出例：DynamoDB バックアップ（PITR）未設定・CDK 削除ポリシー DESTROY のデータ消失リスク、API Gateway 認証が外れた場合の権限昇格リスク。

System Overview は Trust Boundaries（Public Internet / AWS Public-Facing / AWS Private Backend）・Data Flows・Security Posture・Sensitive Assets・Key Assumptions まで自動生成される。レポートは英語のみ。

DevOps Agent にリリース管理の機能が追加されたので、コードレビューを試してみた

• URL: https://dev.classmethod.jp/articles/devops-agent-support-release-management
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: AWS DevOps Agent に 2026-06-17 付けで「Release readiness code reviews」と「Release testing」の2機能が追加された。コードレビューは Claude Code から create_release_readiness_review MCP ツールで呼び出せ、PR 単位で STRIDE 風の構造化レポートを生成する。プレビュー期間中は追加料金なし、現在はバージニアリージョンのみ対応。

詳細

Release readiness code reviews はサンドボックス環境を用いたビルド・実行・テストまで対応している。今回の検証では DLP ユーティリティの除外ルール追加 PR（dlp/utils.ts、+42/-1行）に対して実行し、レポートが 27 秒以内に生成された（指摘3件、いずれも severity: low）。

GitHub 連携設定でリポジトリに「変更レビュー」をオンにすると PR 作成のたびに自動レビューが起動し、GitHub にインラインコメントが付く。DevOps Agent Web アプリのサイドバー「変更」メニューから進捗や過去実行履歴も確認できる。

もう一方の Release testing（Web アプリ・REST API に対する UAT・回帰テスト）は本記事では未検証。

Claude Code から MCP ツールで呼び出す場合は /rewind で巻き戻した既存セッションを再実行するパターンが実証されており、ツール呼び出し自体は通常のセッション中でも動作する。

Foundation Models のマルチモーダル機能でリングフィットアドベンチャーのリザルト画面から運動記録を取り出してみた

• URL: https://dev.classmethod.jp/articles/foundation-models-multimodal-ringfit
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: Apple の Foundation Models（iOS 27 Beta）のマルチモーダル機能を使って、リングフィットアドベンチャーのスクリーンショットから活動時間・消費カロリー・走行距離を構造化データとして抽出する iOS アプリを実装。初期設計では「読み取り+変換を同時に委ねる」と誤読・nil 生成が起き、分・秒を分離した設計と Bool による nil 回避が有効だった。

詳細

検証環境：MacBook Pro M2 Pro / macOS Tahoe 26.4.1 / Xcode 27.0 Beta / iPhone 16e（iOS 27.0 Beta）。

失敗した設計：

• totalActivitySeconds: Int（分秒の変換をモデルに委ねた）→「13分11秒」を781秒と誤読（正解791秒）
• runningDistanceKm: Double? でオプショナル → モデルが nil の代わりに -1.0 や 0.0 を返す

成功した設計：

• activityMinutes: Int と activitySeconds: Int に分離し、0〜59の範囲 を description に明記 → アプリ側で minutes * 60 + seconds を計算
• runningDistanceAvailable: Bool と runningDistanceKm: Double のペア化 → nil の代わりに Bool で存在判定

フォールバック設計として #available(iOS 27, *) → SystemLanguageModel.default.isAvailable → catch の 3 層で Vision.framework OCR へのフォールバックを実装している。

@Guide の description は日本語でも英語と同等の精度が出ることを確認（ただし複雑な条件分岐では差が出る可能性あり）。

GitHub CLI 2.94.0 で gh issue コマンドから Issue type や sub-issues、依存関係などが扱えるようになりました

• URL: https://dev.classmethod.jp/articles/github-cli-294-issue-types-sub-issues
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: GitHub CLI 2.94.0（2026-06-10リリース）で gh issue に Issue types、sub-issues、dependencies のフラグが追加された。従来は GraphQL 直接操作が必要だった領域を通常コマンドで扱えるようになり、CI やエージェントが Issue 構造を読む用途でも有用なアップデートとなっている。

詳細

追加されたフラグ（create / edit）：

• --type name : Issue type の指定
• --parent number : sub-issue として親 Issue を指定
• --blocked-by number / --blocking number : 依存関係の設定
• edit 側には --add-sub-issue、--remove-sub-issue、--remove-parent、--remove-type 等も追加

list / view の JSON フィールドにも issueType、parent、subIssues、subIssuesSummary、blockedBy、blocking が追加されたため、スクリプトやエージェントが Issue 構造を読み取れる。

gh issue list --json number,title,issueType,parent,subIssuesSummary,blockedBy,blocking --jq '.[0]'

GitHub 公式 Changelog では AI コーディングエージェントが gh 経由で Issue 構造を操作・参照する文脈にも言及している。

制約：Issue types は organization 側の設定が前提。sub-issues は GitHub.com と GHES 3.17+、relationships は GHES 3.19+ 以降が対象。

IAM Access Analyzer のポリシー生成で発生する権限不足エラーを検証してみた

• URL: https://dev.classmethod.jp/articles/iam-access-analyzer-policy-generation-permission-error
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: IAM Access Analyzer のポリシー生成で必要な権限を意図的に削除し、エラーメッセージのパターンを5パターン検証した記録。エラーの種別によって原因箇所が異なり、特に S3 バケット権限不足とバケットポリシー Deny が同じエラーメッセージになる点が切り分けのポイント。

詳細

検証パターンとエラー結果：

エラー切り分けの実用指針：

• S3 bucket エラー → IAM ポリシーと S3 バケットポリシーの両方を確認
• cloudtrail:GetTrail エラー → CloudTrail 参照権限（GetTrail・DescribeTrails・LookupEvents 等）を確認
• accessRole エラー → IAM サービス最終アクセス情報権限（iam:GenerateServiceLastAccessedDetails・iam:GetServiceLastAccessedDetails）を確認
• ポリシー生成は成功するがアクションが空 → 分析対象期間が正しいか・対象ロールの API コール有無を確認

NVIDIA FOX Blueprint の小売店版を VSS Skills と Hermes Agent で考えてみた

• URL: https://dev.classmethod.jp/articles/mini-retail-fox-vss-skills-hermes-agent
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: NVIDIA Factory Operations Blueprint（FOX）の設計思想を小売店舗（スーパー）向けに縮小した「Mini-Retail FOX」という概念整理。映像をエッジでイベント化してから LLM/VLM の reasoning に渡す方針と、VSS Skills 10 個の使いどころ、Hermes Agent の役割分担モデルを3構成案（DGX Spark ローカル・PC+クラウド・AWS Greengrass）で比較している。

詳細

Mini-Retail FOX の核心は「全フレームを VLM に流さない」設計。エッジで間引いてルール判定し、棚薄・混雑・台車放置などの候補フレームだけをイベント JSON に変換してから reasoning に渡す。

VSS Skills（NVIDIA 公式 NVIDIA-AI-Blueprints/video-search-and-summarization リポジトリに公開）は agentskills.io 仕様準拠で 10 個あり、そのうち video-search、video-understanding、alerts、report、rt-vlm が小売向けに特に有用。npm install ライクなプロンプト一発でシンボリックリンクが張られ、Claude Code・Codex・Hermes Agent が共有できる設計になっている。

Hermes Agent のプロファイル分割例：

• Store Ops プロファイル：自然言語問い合わせを受け VSS Skill を選択・実行
• Night Report プロファイル：営業終了後にバッチで日次レポート生成
• Triage プロファイル：来店者対話と店舗業務問い合わせを振り分け

Mini-FOX との共通点として「Store Supervisor Agent は自律制御ではなく確認候補提示に留める」設計思想が重要。現場の納得感のために人間レビューを前提にしたフロー設計が初期 PoC で有効とされている。

NVIDIA FOX Blueprint を小さく始める Mini-FOX 構成を考えてみた

• URL: https://dev.classmethod.jp/articles/nvidia-fox-blueprint-mini-fox-structure
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: DGX Station 級の大規模構成を前提とする NVIDIA Factory Operations Blueprint（FOX）を、1 ライン・1 カメラ・1 ユースケースに縮小した「Mini-FOX」として始める方法の整理。DGX Spark ローカル・PC+クラウド・AWS IoT Greengrass の3構成案を比較し、最初のユースケースとして通路上の障害物検知を推奨している。

詳細

FOX の主要要素との対応関係：

核心設計：全フレームを VLM に投げない。エッジで軽量検出・ルール判定し、異常候補フレームだけをイベント JSON に変換してから LLM/VLM の reasoning に渡す。イベント JSON に human_feedback フィールドを持たせることで後の再学習データセット化にも使える。

3 構成案の選択観点：

• DGX Spark ローカル：映像を外に出せない PoC・NVIDIA スタック検証デモ
• PC+クラウド LLM：低コスト技術検証・1 カメラから始める
• AWS IoT Greengrass：複数拠点展開を見据える PoC

PoC 初期は「何を見つけ、どう説明し、人がどう判断したかを記録する」フローを優先し、機械側の自律制御には踏み込まないことが現場の納得感に直結するとしている。

[VAMS] NVIDIA Isaac Lab のトレーニング機能で SO-ARM101 の Reach を強化学習させてみました

• URL: https://dev.classmethod.jp/articles/vams-nvidia-isaac-lab-so-arm101-training
• 日付: 2026-06-19
• Tier: Tier 2
• 要旨: AWS の VAMS 上で NVIDIA Isaac Lab を使い、標準ラインナップに含まれない SO-ARM101 ロボットの Reach タスクを強化学習させた実装記録。カスタム環境を tar.gz でパッケージし S3 経由で取り込む手順と、gym.register タスク登録の回避策、buildx 互換性問題など複数のハマり点を詳述している。

詳細

VAMS v2.5.1 上の Isaac Lab パイプライン（isaaclab-training）に SO-ARM101 を載せるには、MuammerBay 配布パッケージに Reach-Grasp の差分を重ねた tar.gz を S3 にアップロードし、customEnvironmentS3Uri として渡す必要がある。

ハマりポイントが3つ：

• pip install -e はアーカイブ非対応 → --no-deps で回避
• 学習コンテナの train.py が import isaaclab_tasks しかせず SO-ARM101 タスクが gym 登録されない → __main__.py に import isaac_so_arm101.tasks を差し込む形でパッチを当てた
• Rancher Desktop の containerd image store + 新しい buildx の組み合わせで docker run 不可なイメージが生成される → BUILDX_NO_DEFAULT_ATTESTATIONS=1 で回避

最終的に Isaac-SO-ARM101-Reach-Grasp-v0 タスクが VAMS Web UI から起動でき、AWS Batch の GPU インスタンス（L4/L40S/A10G）上で学習が進むことを確認。学習済みポリシー（checkpoints/*.pt）と metrics.csv がアセットの File Manager に登録される。

Isaac Lab 標準タスク（Cartpole、Reach-Franka など）のみを試す場合はカスタム環境不要で Input Parameters の task 指定だけで動く。

Claude Code / Codex の全社展開と AI 観測基盤の設計

• URL: https://docswell.com/s/rakutek/59NR49-2026-06-04-194729
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: クラシル株式会社による全社 AI 導入と観測基盤。2023 年 4 月〜2026 年 2 月の段階的導入（ChatGPT → Codex → Claude Code・Claude Team）。課題：導入完了も利用実態が見えない。OpenTelemetry × Grafana による定量的観測。3 段…

詳細

クラシル株式会社による全社 AI 導入と観測基盤。2023 年 4 月〜2026 年 2 月の段階的導入（ChatGPT → Codex → Claude Code・Claude Team）。課題：導入完了も利用実態が見えない。OpenTelemetry × Grafana による定量的観測。3 段階：OTel で収集・GitHub/Notion に統一・KPI に接続。

AIスキル設計の6つの罠 — Matt Pocock Skills v1.0.0 が体系化した「予測可能なAIマニュアル」の書き方

• URL: https://zenn.dev/417/articles/masakazu-matt-pocock-skills-design-20260618
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Matt Pocock の Skills v1.0.0 メタスキル。User-invoked/Model-invoked・Leading Word・No-op Test・Premature Completion・Deep Module・Information Hierarchy の 6 概念。すべて…

詳細

Matt Pocock の Skills v1.0.0 メタスキル。User-invoked/Model-invoked・Leading Word・No-op Test・Premature Completion・Deep Module・Information Hierarchy の 6 概念。すべて「予測可能性」という統一原則に帰結。引き算の美学が AIマニュアル設計の本質。

Claude CodeとCodexを1台で協業させる ― 設計はClaude・実装はCodexに渡す

• URL: https://zenn.dev/bokuwalily/articles/codex-claude-handoff
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code と Codex CLI の役割分担。Claude（設計・リサーチ・レビュー）と Codex（実装・リファクタ・テスト生成）で頭脳と手を分離。委譲は定型・大規模・反復工程のみ。ヘッドレス実行で非対話実行。stdin 閉塞・timeout 設定による安全な投げ方。…

詳細

Claude Code と Codex CLI の役割分担。Claude（設計・リサーチ・レビュー）と Codex（実装・リファクタ・テスト生成）で頭脳と手を分離。委譲は定型・大規模・反復工程のみ。ヘッドレス実行で非対話実行。stdin 閉塞・timeout 設定による安全な投げ方。

会話ログをObsidianの長期記憶に変える ― 毎晩自動で蒸留するパイプライン

• URL: https://zenn.dev/bokuwalily/articles/conversation-to-memory
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: 会話ログから Obsidian Vault への自動蒸留パイプライン。launchd で毎朝起動。採取（会話ログ同期）→ 蒸留（claude -p で 28 時間差分を domain 構造で追記）→ バックアップ（git commit）。罠：macOS TCC（プライバシー保護）によるアクセス権限・…

詳細

会話ログから Obsidian Vault への自動蒸留パイプライン。launchd で毎朝起動。採取（会話ログ同期）→ 蒸留（claude -p で 28 時間差分を domain 構造で追記）→ バックアップ（git commit）。罠：macOS TCC（プライバシー保護）によるアクセス権限・スリープ時のジョブ凍結・二重実行。自己回復型の実装。

「snowを叩くたびにブラウザに飛ばされる」を、Snowflake推奨の方式のまま消したい

• URL: https://zenn.dev/fusic/articles/0018-snowflake-claude-code-snow-cli-auth
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Snowflake CLI と Claude Code の OAuth 認証問題の解決。毎回ブラウザ出現の原因はトークンキャッシュ欠落。SNOWFLAKE_CLIENT_STORE_TEMPORARY_CREDENTIAL=true で macOS Keychain にキャッシュ。96%の削減率実現…

詳細

Snowflake CLI と Claude Code の OAuth 認証問題の解決。毎回ブラウザ出現の原因はトークンキャッシュ欠落。SNOWFLAKE_CLIENT_STORE_TEMPORARY_CREDENTIAL=true で macOS Keychain にキャッシュ。96%の削減率実現。~/.zshenv への設定で永続化。

AIエージェント検証用PCを作るメモ⑦：Ubuntu側にClaude Codeを導入してみる

• URL: https://zenn.dev/imaginarygate/articles/230e9d1fce2601
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: WSL/Ubuntu への Claude Code 導入。agent-sandbox ディレクトリスコープに限定したセットアップ。CLAUDE.md・SECURITY_POLICY.md の認識確認。小さなファイル作成による動作検証。Claude Codeと Codex CLI の同時使用を避ける運…

詳細

WSL/Ubuntu への Claude Code 導入。agent-sandbox ディレクトリスコープに限定したセットアップ。CLAUDE.md・SECURITY_POLICY.md の認識確認。小さなファイル作成による動作検証。Claude Codeと Codex CLI の同時使用を避ける運用方針。

GitHub PRで@codexが反応しないときに見直すこと environment未作成で止まっていた

• URL: https://zenn.dev/kakecake/articles/codex-github-env-trouble
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Codex と GitHub 連携の @codex コマンド不応答問題。3 段階の確認項目：GitHub App 接続・Codex Code review 有効化・repo 用 environment 作成。Environment 未作成が最後のボトルネック。Bot の返信メッセージの意味理解。…

詳細

Codex と GitHub 連携の @codex コマンド不応答問題。3 段階の確認項目：GitHub App 接続・Codex Code review 有効化・repo 用 environment 作成。Environment 未作成が最後のボトルネック。Bot の返信メッセージの意味理解。

ハーネスを盛りすぎてAIが動かなくなった日: 最小構成で見えた4つの本質

• URL: https://zenn.dev/kenimo49/articles/harness-overengineering-minimal-4-essentials
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: CLAUDE.md 800 行のオーバーエンジニアリング。矛盾する指示が混在（「最小限コメント」と「意図を説明」）すると AI が指示を取りこぼす。IFScale ベンチマークで 100 指示超で精度低下を実測。「足すほど効く」は誤解。4 つの本質：ルール集約・矛盾排除・優先順位明確化・スコープ限定…

詳細

CLAUDE.md 800 行のオーバーエンジニアリング。矛盾する指示が混在（「最小限コメント」と「意図を説明」）すると AI が指示を取りこぼす。IFScale ベンチマークで 100 指示超で精度低下を実測。「足すほど効く」は誤解。4 つの本質：ルール集約・矛盾排除・優先順位明確化・スコープ限定。

中断しても続きから動く — AIワークフローのチェックポイント設計

• URL: https://zenn.dev/kikaikaya/articles/flowsmith-checkpoint-resume
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: AI ワークフローエンジンの中断・復帰機構。state.json に実行状態を永続化し、step ごと・反復行ごとに完了を記録。「半端な成果物を賢く救済する」より「確実なものだけ信じて失敗は捨てる」設計。15 ステップのレガシー調査で実負荷検証済み。…

詳細

AI ワークフローエンジンの中断・復帰機構。state.json に実行状態を永続化し、step ごと・反復行ごとに完了を記録。「半端な成果物を賢く救済する」より「確実なものだけ信じて失敗は捨てる」設計。15 ステップのレガシー調査で実負荷検証済み。

Claude Codeを安く使うコツは “LLMに探させない” こと

• URL: https://zenn.dev/midori/articles/2d0caf37e6bdfb
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code のトークン削減戦略。「LLM に探させない」を基本方針に、タスク別ファイル指定・フォルダ構造の論理化・Read 確認ゲート・処理スクリプト化による 4 段階の対策。

詳細

Claude Code 運用でトークン消費の大半を占めるのは、AI が Glob/Grep でファイルを探索し、Read で本文を取得するコスト。これを「LLM に探させない」設計で削減する実装例。

対策①：タスク別にファイルを指定。CLAUDE.md に「試合準備→docs/match-prep.md」のように先読むべきファイルを明記し、AI が余計な探索をしないよう事前に道を示す。

対策②：フォルダ構造を論理的に。content/、data/、reports/ など階層を明確にすることで、AI が「当てずっぽうで広く探索」する必要がなくなる。

対策③：人間が確認ゲート。Glob・Read 実行前に「何を読もうとしているか」を提示させ、複数ファイル連続 Read を構造的に防ぐ。

対策④：決定論的処理をスクリプト化。YAML → HTML 変換など入出力が固定される処理は Python で自動化し、毎回 AI に読み込ませ・解釈させるトークンコストを排除。判断が必要なものは日本語仕様で、答えが決まるものはスクリプトで、という線引きが効果的。

ClaudeCodeで/grill-meというスキルを3週間使いながらアレンジもしてみた

• URL: https://zenn.dev/mukuil_blog/articles/1ccfd44928e825
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Matt Pocock の /grill-me スキル（容赦なく設計を質問攻めにして共通理解に到達）の 3 週間実運用。/plan との違い。失敗・トラブル（文脈喪失・質問ツリーの迷子）と解決策。認識合わせ精度の向上。アレンジによる改善。…

詳細

Matt Pocock の /grill-me スキル（容赦なく設計を質問攻めにして共通理解に到達）の 3 週間実運用。/plan との違い。失敗・トラブル（文脈喪失・質問ツリーの迷子）と解決策。認識合わせ精度の向上。アレンジによる改善。

Claude CodeのTeamCreateが廃止され、Plan Modeが変わったのでワークフローを見直す

• URL: https://zenn.dev/n314/articles/6becd34ddbe6ad
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code の仕様更新（TeamCreate 廃止・Plan Mode 変更）への対応。team-issue スキルと compare-impl スキルの設計。複数実装の比較で Phase 0〜5 の詳細 workflow を公開。セッション振り返りスキルによる継続的改善の仕組み。…

詳細

Claude Code の仕様更新（TeamCreate 廃止・Plan Mode 変更）への対応。team-issue スキルと compare-impl スキルの設計。複数実装の比較で Phase 0〜5 の詳細 workflow を公開。セッション振り返りスキルによる継続的改善の仕組み。

[Claude Code] SkillとPluginが内部でどう読み込まれているのか、実際のファイルを覗いてみた

• URL: https://zenn.dev/ncdc/articles/d39bf5c31e0fe8
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code の Skill・Plugin 内部構造解析。Skill は YAML フロントマター + Markdown 指示書。セッション起動時に name・description だけスキャン→ available_skills メタツール内に埋め込み→AI が必要時に本文読み込み。U…

詳細

Claude Code の Skill・Plugin 内部構造解析。Skill は YAML フロントマター + Markdown 指示書。セッション起動時に name・description だけスキャン→ available_skills メタツール内に埋め込み→AI が必要時に本文読み込み。User/Project/Enterprise スコープの優先順位。Plugin の配布リポジトリ構造。

【Claude Code活用】複数ファイル跨ぎの修正を任せる

• URL: https://zenn.dev/pekopugu/articles/agent01-b6-multi-file
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code が複数ファイル間の依存関係を自動認識し、1 つのタスクで関連ファイルを順序立てて修正する実装例。実装指示書に「作成・更新ファイル一覧」を明示することで変更漏れをゼロにする方法。

詳細

AI エージェント追加時、通常は複数ファイル（init.py・tool_definitions.py・dispatcher.py など）を同時に変更する必要がある。Claude Code は既存コードを読んで「この変更にはこのファイルも更新が必要」と自動判断できるが、指示書に明示すると確実性が上がる。

実装指示書の書き方：冒頭に「作成・更新ファイル一覧」を表形式で明示。ファイル名と操作内容（新規作成・追加・更新）を列挙。各ファイルセクションで具体的な変更内容を記載。この構造により、AI が見落としを自発的に補正でき、人間レビューも変更ファイルが明確に把握できる。

気づき：エージェント自身が import エラーを検出すると自己修正できる（ImportError が出たら init.py の漏れを特定）。ただし事前指示が最も効率的。ファイル数が増えるほど指示書の価値が上がる。

デザインシステムのskillの精度が上がった8つの方法

• URL: https://zenn.dev/pksha/articles/7a7db5c105f396
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: デザインシステムの Skill 精度向上の 8 つの方法。Design Token を Markdown から CSS 変数に変更（Primitive・Semantic 層の明確化）。information hierarchy で詳細を別ファイルに分離。Progressive Disclosure …

詳細

デザインシステムの Skill 精度向上の 8 つの方法。Design Token を Markdown から CSS 変数に変更（Primitive・Semantic 層の明確化）。information hierarchy で詳細を別ファイルに分離。Progressive Disclosure による段階的開示。複数テストによる最適化。

AI専用動画編集ツールに『色』と『手ブレ補正』を足したら、効いていたはずのパスのエスケープが片方だけ通用しなかった — clipwright

• URL: https://zenn.dev/satoh_y_0323/articles/1fa6ddadb3d874
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: MCP 動画編集サーバー clipwright に色補正と手ブレ補正を実装した際の設計判断と落とし穴。FFmpeg フィルターごとにパース挙動が異なる問題、セキュリティレビューで発見された 3 つの脆弱性、binaries の構造解析に関する選択。

詳細

clipwright v0.7.0（色補正）と v0.8.0（手ブレ補正）の実装記。設計思想は「検出と適用の分離」で、各ツールは OTIO に注記を書くだけ、実際の映像処理は clipwright-render が一度だけ行う。

色補正（clipwright-color）では、FFmpeg の signalstats で各フレームの平均輝度を測定して brightness 値を自動算出。contrast・saturation・gamma は意図的に自動化せず、AI の判断に委ねる仕様に。

手ブレ補正で遭遇した主要な問題：

• Windows 絶対パスのエスケープが drawtext では成功しても vidstabtransform では失敗。同じ「ファイルパス系オプション」でもフィルターの内部パーサが異なるため、エスケープ方式に統一性がない。解決策として cwd をファイル格納フォルダに変更し、相対ファイル名のみをフィルターグラフに渡す実装に転換。

セキュリティレビューで検出された脆弱性 3 種：

• パストラバーサル（CWE-22）：OTIO 由来の信用できない .trf_path が OTIO 外のファイルにアクセス可能に。境界チェック強化で対応。
• フィルターグラフ注入（CWE-78）：ファイル名に : や ; が含まれると FFmpeg オプション注入が可能。ファイル名の sanitize と受け側での特殊文字チェック。
• メモリ枯渇（DoS）：.trf ファイルサイズ上限を設置。

severity（手ブレの強さ）は spec では注記対象だが、.trf バイナリフォーマットの正確な構造が不明確なため、推測値を出すより null で返す判断。計測したフリの不確かな値より、正直に「測定不能」を返す方が AI に対して誠実。

通底する教訓：パスのエスケープで安全性を得るより、危険な形をそもそもフィルターグラフに出さない設計が強いこと。

Claude Code のツール呼び出し漏れバグをフックで検知・自動リカバリする

• URL: https://zenn.dev/seijikohara/articles/claude-code-leaked-toolcall-hook
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code のツール呼び出し漏れ（XML マークアップが本文テキストとして流出）をフックで検知・自動リカバリ。二層防御：UserPromptSubmit フック（予防層）で正しい形式を再周知・Stop フック（検知・回復層）で漏れを検出し差し戻す。Node.js 標準モジュールのみで実装…

詳細

Claude Code のツール呼び出し漏れ（XML マークアップが本文テキストとして流出）をフックで検知・自動リカバリ。二層防御：UserPromptSubmit フック（予防層）で正しい形式を再周知・Stop フック（検知・回復層）で漏れを検出し差し戻す。Node.js 標準モジュールのみで実装。

ClaudeCodeでChrome拡張を作ってChrome Web Storeに公開するまでの全記録

• URL: https://zenn.dev/streamzap/articles/dbd3655b9c8004
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code による Chrome 拡張開発。StreamZAP（Twitch・YouTube ライブ配信を横断一覧表示）の企画・開発・公開記。React + Vite + TypeScript。CLAUDE.md による仕様書駆動。設計・技術問題の壁打ち。Google OAuth ブラン…

詳細

Claude Code による Chrome 拡張開発。StreamZAP（Twitch・YouTube ライブ配信を横断一覧表示）の企画・開発・公開記。React + Vite + TypeScript。CLAUDE.md による仕様書駆動。設計・技術問題の壁打ち。Google OAuth ブランディング審査の詳細な詰まりどころと解決策。

Addy Osmani氏のX投稿を見て、AIに書かせたコードの責任を考えた

• URL: https://zenn.dev/taketake_skills/articles/addy-ai-code-ownership
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: AI コード生成の責任論。「書けた」と「直せる」は別能力。AI が書いたコードも壊れるし、運用上の前提を外す。コミット・レビュー・公開は人間が行った瞬間に責任は人間に転嫁。「AI が書いたから」は責任回避にならない。理解確認が必要になるほど AI 運用は深くなる。…

詳細

AI コード生成の責任論。「書けた」と「直せる」は別能力。AI が書いたコードも壊れるし、運用上の前提を外す。コミット・レビュー・公開は人間が行った瞬間に責任は人間に転嫁。「AI が書いたから」は責任回避にならない。理解確認が必要になるほど AI 運用は深くなる。

Claude Code に Chrome DevTools for Agents（chrome-devtools-mcp）を繋ぐ実践ガイド

• URL: https://zenn.dev/takna/articles/claude-code-chrome-devtools-mcp
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Chrome DevTools for Agents v1 を Claude Code に接続。Lighthouse 監査・モバイルエミュレーション・認証済みセッション・メモリリーク検出の自動化。Chrome 149 新機能（カスタムツール・WebMCP）も含む。セットアップ手順と 5 つのユースケ…

詳細

Chrome DevTools for Agents v1 を Claude Code に接続。Lighthouse 監査・モバイルエミュレーション・認証済みセッション・メモリリーク検出の自動化。Chrome 149 新機能（カスタムツール・WebMCP）も含む。セットアップ手順と 5 つのユースケース。

Claude Codeのマルチエージェント組織は、何もしなくても腐っていく——2つの腐敗パターン

• URL: https://zenn.dev/tottoko_hamu/articles/2026-06-08-090000
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: マルチエージェント運用での腐敗パターン：意図しない CLAUDE.md 増殖（誤ったディレクトリでの起動）・参照切れ Playbook（更新漏れで孤立）。事件がなくても日常的に腐敗は蓄積。検出の仕組みを意図的に設計する必要性。…

詳細

マルチエージェント運用での腐敗パターン：意図しない CLAUDE.md 増殖（誤ったディレクトリでの起動）・参照切れ Playbook（更新漏れで孤立）。事件がなくても日常的に腐敗は蓄積。検出の仕組みを意図的に設計する必要性。

AIコードレビューは「コードで返す」と速くなる

• URL: https://zenn.dev/uzero_fktrhori/articles/1cc1209ce61e53
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code のレビュー運用で、自然言語コメントの代わりに code suggestion でコードを返すことで速度と心理的負荷の両面を改善。GitHub code suggestion の活用と、指摘の仕分けルール化による実装例。

詳細

自然言語レビューの問題点は「往復の翻訳コスト」にあるという指摘。問題をコード化 → 人間の言葉に変換 → 受け手が読んでコードに翻訳、というサイクルを削減するため、完成形が一意に決まる指摘は code suggestion（GitHub の置換機能）で直接返す運用に変更。

レビュー指摘の仕分けルール：

• suggestion（コードで返す）：単一ファイルの連続行で置換後が一意に決まり、仕様確認が不要
• 行コメント：複数の直し方がある・質問が必要なケース
• 総括コメント：複数ファイル・設計級の指摘

実装上の配慮として、複数指摘をまとめて1回のレビューで送り通知を集約。投稿前に人間のゲートを残す（マージ判断は人間領域）。結果として指摘が「否定」ではなく「提案」に見え、チームの心理的負荷が軽減。具体的な .claude/commands 配置やルール化で運用負荷も低減した実例。

Claude Code を脱出する — OpenCode + Ollama Cloud への実践移行ガイド

• URL: https://zenn.dev/vtf/books/opencode-ollama-cloud-henyo
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Claude Code Max からの移行実践記。Fable 5 停止・Opus 4.8 品質劣化・API 障害の連鎖が背景。OpenCode + Ollama Cloud MAX への選定理由（プライバシー・利用量・性能）。環境構築・Skill/Plugin/知見基盤の移植・6 エージェント構成。…

詳細

Claude Code Max からの移行実践記。Fable 5 停止・Opus 4.8 品質劣化・API 障害の連鎖が背景。OpenCode + Ollama Cloud MAX への選定理由（プライバシー・利用量・性能）。環境構築・Skill/Plugin/知見基盤の移植・6 エージェント構成。実用量と性能の実測比較。マルチプロバイダー時代への適応。

1コマンドでClaude Codeが開発チームになる「ccteams」を作った

• URL: https://zenn.dev/yui/articles/4f54a98ad94fe5
• 日付: 2026-06-19
• Tier: Tier 3
• 要旨: Agent チーム用パッケージマネージャー ccteams。npm install で「Go API チーム」「Next.js チーム」などを一括適用。8 種類の事前構成済みチーム。プラグイン機能で /ccteams:choose-team により AI が最適なチームを自動選択。.ccteams-…

詳細

Agent チーム用パッケージマネージャー ccteams。npm install で「Go API チーム」「Next.js チーム」などを一括適用。8 種類の事前構成済みチーム。プラグイン機能で /ccteams:choose-team により AI が最適なチームを自動選択。.ccteams-manifest.json で切り替えを追跡。