Claude Code v2.1.169 の主要アップデート

• URL: https://dev.classmethod.jp/articles/20260609-cc-updates-v2-1-169/
• 日付: 2026-06-09
• Tier: Tier 2
• 要旨: Claude Code v2.1.169（2026-06-08 リリース）の変更内容まとめ。30 件の変更（新機能 3・改善 12・修正 12・セキュリティ 2・パフォーマンス 1）で、特に --safe-mode フラグ追加とエンタープライズ向けセキュリティ修正が注目ポイント。

詳細

新機能

• --safe-mode フラグ（CLAUDE_CODE_SAFE_MODE 環境変数）: CLAUDE.md・プラグイン・skill・hook・MCP サーバーを全無効化して起動。設定・拡張が原因か切り分けたいトラブルシューティングで有用
• /cd コマンド: セッション途中でプロンプトキャッシュを壊さずに作業ディレクトリを変更
• disableBundledSkills 設定: バンドル skill・ワークフロー・組み込みスラッシュコマンドをモデルから隠す

セキュリティ修正

• 未信頼プロジェクト設定から OTEL クライアント証明書パスを無断で設定できてしまう問題を修正
• エンタープライズの allowedMcpServers/deniedMcpServers ポリシーが再接続時・IDE 入力・--mcp-config サーバー・リモート設定ロード前に適用されていなかった問題を修正

主要修正

• Windows で claude -p が skill スキャン待ちでハング（v2.1.161 で混入したリグレッション）を修正
• macOS の各ターン開始時の 30〜50ms UI ストール（claude.ai 認証情報利用時）を修正
• Remote Control の「reconnecting」状態固着を修正

主要改善

• /workflows がターン進行中でも即座に開くように
• Vertex/Foundry のデフォルト 5 分アイドルタイムアウトを復活（停止ストリームの無限ハングを防止）
• 「CLAUDE.md が長すぎる」警告しきい値がモデルのコンテキストウィンドウに応じてスケーリング

AgentCore RuntimeにSession Storage・S3 Files・EFSを同時マウントしてCDKで構築・検証してみた

• URL: https://dev.classmethod.jp/articles/agentcore-runtime-storage-three-types-cdk/
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: AWS AgentCore Runtime のストレージマウント機能（Session Storage・S3 Files・EFS の 3 種類同時）を CDK TypeScript で構築し、セッション間のデータ共有を実機検証。CDK L2 コンストラクトの escape hatch やセキュリティグループの注意点も詳述。

詳細

3 種類のストレージ比較

CDK での注意点

• aws-bedrockagentcore の Runtime L2 コンストラクトは filesystemConfigurations 未サポート（2026-06-09 時点 CDK 2.258.0）→ escape hatch で CfnRuntime に直接設定が必要
• S3 Files 用に aws-cdk-lib 2.258.0 以降（aws-cdk-lib/aws-s3files モジュール）が必要
• IAM 権限は ClientMount/ClientWrite に加え、Runtime 作成時バリデーション用の Describe 系も必要

Security Group

• runtime.connections.allowTo(storage.mountTargetSg, Port.tcp(2049)) で Runtime ↔ マウントターゲット間の NFS（TCP 2049）を双方向で設定

実機検証結果

• 3 種すべてが正常にマウント（df で確認）
• Session Storage は約 1 GiB 表示、EFS/S3 Files は約 8 EiB 表示（NFS 上の仮想値）
• セッション間データ共有: EFS/S3 Files では同じ Access Point 経由の別セッションからファイルが見える
• Session Storage は異なるセッションインスタンス間で共有不可（設計どおり）

AWS IAM の aws:RequestTag は実行者のタグではない？aws:PrincipalTag との違いを SSM Parameter Store で検証してみた

• URL: https://dev.classmethod.jp/articles/aws-iam-requesttag-principaltag-ssm-parameter-store/
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: AWS IAM の条件キー aws:RequestTag と aws:PrincipalTag の違いを SSM Parameter Store の ssm:PutParameter で実機検証。名前の印象とは違い、aws:RequestTag は実行者のタグではなく API リクエストで渡されたタグを評価することを確認。

詳細

3 つの条件キーの定義

検証結果まとめ

まとめ

• aws:RequestTag は IAM ロールのタグを見ない。API リクエストで渡されたタグのみを評価する
• 実行主体のタグを条件にしたい場合は aws:PrincipalTag を使う
• ssm:PutParameter のサービス認可リファレンスには aws:RequestTag は明示されているが、aws:PrincipalTag は IAM グローバル条件キーとして別途評価される点に注意

注意点

• aws:PrincipalTag を ssm:PutParameter の Deny ポリシーで使う場合、アクション行への記載の有無に関わらずグローバル条件キーとして評価される

Claude Enterprise Compliance API のアクティビティフィードをBigQueryに日次で自動収集する

• URL: https://dev.classmethod.jp/articles/claude-enterprise-compliance-api-activity-feed-bigquery-daily-sync/
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: Anthropic が 2026 年 5 月に正式リリースした Compliance API を Google Cloud（Cloud Scheduler → Cloud Run Functions → BigQuery）で日次収集するアーキテクチャの設計・実装解説。BigQuery のコスト特性（バッチ load 無料・90 日でロングタームストレージ）と Compliance API の 6 年保持期間の組み合わせで監査ログを安価に長期蓄積できる。

詳細

Compliance API の主要仕様

• Claude Enterprise プランのみ利用可能（公共部門を除く）
• ベース URL: https://api.anthropic.com/v1/compliance/*
• データ鮮度: イベント発生から 1 分以内にクエリ可能
• 保持期間: 6 年間
• レート制限: 600 req/min / 親組織
• 最大取得件数: 1 リクエストあたり 5,000 件、カーソル方式（after_id/last_id）

取得できるイベント（一部）

• 認証: sso_login_initiated, sso_login_succeeded, user_logged_out
• ユーザー管理: claude_user_settings_updated, org_iam_seat_tier_assignment_toggled
• チャット: claude_chat_created
• API アクセス: compliance_api_accessed

Google Cloud アーキテクチャ（Cloud Scheduler → Cloud Run Functions → BigQuery）

BigQuery スキーマ設計

• 型付きカラム（id, type, created_at）+ raw JSON カラムで新イベントタイプに対応
• created_at でパーティション化、type でクラスタリング → 特定期間・特定イベント種別クエリのコスト最小化

コスト上の優位点

• バッチ load ジョブは BigQuery 無料
• 90 日更新なしのパーティションは約 50% 引きのロングタームストレージへ自動移行
• 6 年保持の監査ログは 3 ヶ月超でほぼ全パーティションが自動的に安価なストレージへ

運用設計の注意点

• Cloud Scheduler の自動リトライは無効化（retry_count = 0）: 二重起動による BigQuery への重複書き込み防止
• Cloud Run Functions のタイムアウトは最大 60 分（Gen1 の 9 分制限を回避するため Gen2 必須）

AWS DevOps Agent の Artifact 機能を試してみた

• URL: https://dev.classmethod.jp/articles/devops-agent-artifact/
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: AWS DevOps Agent の Artifact 機能を実機検証。プロンプトの言葉次第で Chat 応答と Artifact（専用パネル・バージョン管理付き）が自動的に使い分けられる挙動を確認。別チャットからの更新には knowledge_item_id が必要な点など、運用上の注意点も詳述。

詳細

Artifact 機能とは

• 「週次運用ヘルスレポートを作成」などの成果物的なプロンプトで自動的に Artifact が生成される
• Chat 欄に流れず専用パネルに固定表示され、バージョン管理（V1/V2/…）が付く
• Markdown ダウンロードと個別 URL での共有が可能
• 会話履歴は 90 日間保持・そのユーザーアカウントに対して private

Chat vs Artifact の使い分け

• 「現状を棚卸ししてください」→ Chat 応答（長い Markdown が欄に流れる）
• 「週次運用ヘルスレポートを作成してください」→ 自動で Artifact が生成（明示しなくても）
• プロンプトに「レポート」「document」などの成果物っぽいワードが含まれると Artifact がトリガー

バージョン更新

• 同じチャットスレッドで「先週の Artifact を今週分として更新して」と依頼 → 同じ Artifact が V2 として上書き
• 過去バージョンもパネルのドロップダウンで参照可能

別チャットからの更新（注意点）

• タイトルだけでは更新不可。内部識別子 knowledge_item_id（ki-xxxx 形式）が必要
• knowledge_item_id の取得方法: Artifact 一覧で対象をクリック → URL バーの末尾から取得
• ID を渡せば別チャットからでも差分追記の編集依頼が通る
• ただし Agent が「Artifact 本文をチャットに表示して」には対応していない（UI パネルで直接確認が必要）

GitHub ActionsでGASをデプロイしclasp認証情報をローカルに残さない方法

• URL: https://dev.classmethod.jp/articles/gas-github-actions-clasp-secure-deploy/
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: Google Apps Script（GAS）を clasp で管理しつつ、~/.clasprc.json（アクセストークン・リフレッシュトークン含む）をローカルに残さず GitHub Secrets + GitHub Actions だけでデプロイする構成の解説。

詳細

解決する問題

• clasp login で生成される ~/.clasprc.json にはアクセストークン・リフレッシュトークンが含まれ、ローカルに残すと流出リスクがある

構成のポイント

1. CLASPRC_JSON（~/.clasprc.json 全体）と CLASP_SCRIPT_ID_MAIN/CLASP_SCRIPT_ID_DEV を GitHub Repository Secrets に登録
2. .clasp.json 全体ではなく scriptId だけを Secret に保存。GitHub Actions 実行中に dist/.clasp.json を動的生成
3. 処理終了後はランナーごと破棄 → ローカルにもリポジトリにも認証情報が残らない

推奨運用

• CI 用の専用 Google アカウントで clasp login してトークン取得。対象 GAS だけ編集権限を共有
• dev ブランチ push → 検証用 GAS、main push → 本番用 GAS に振り分け（誤デプロイ防止）
• 登録後はローカルの認証情報を clasp logout で削除

ワークフロー構成

• ci.yml: PR（main/dev 向け）で lint・test・build のみ実行
• deploy.yml: main/dev への push で ~/.clasprc.json を一時生成 → clasp push → ランナー終了で自動削除

参考

• Google 公式ドキュメント「clasp と GitHub Actions を使用した Apps Script の CI/CD」をベースに .clasp.json 全体ではなく scriptId のみを Secret 化する方式に改良

Security Command Center の IaC 検証を GitHub Actions で実行してみた

• URL: https://dev.classmethod.jp/articles/gcp-scc-iac-validation-github-actions/
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: Google Cloud Security Command Center（SCC）の IaC 検証機能を GitHub Actions に組み込む手順を解説。PR ごとに Terraform plan を自動検証し、セキュリティポスチャー違反があれば job を失敗させて PR をブロック。Workload Identity 連携で鍵レス認証を実現。

詳細

前提条件

• SCC が Premium または Enterprise で組織レベル有効化済み（プロジェクトレベルでは使用不可）
• セキュリティポスチャー（IaC 違反ルールの束）を組織で作成・対象プロジェクトにデプロイ済み
• 有効化 API: securityposture.googleapis.com, securitycentermanagement.googleapis.com

CI で使用する GitHub Action

• google-github-actions/analyze-code-security-scc: Terraform plan の JSON を受け取り SCC IaC 検証レポートを生成

IaC 検証 SA（サービスアカウント）の設定

• 必要なロール: roles/securityposture.reportCreator（実権限: securityposture.reports.create/get/list, operations.get）
• 付与先は組織レベルのみ（プロジェクトレベルで付けると Role ... is not supported for this resource エラー）
• Workload Identity 連携（WIF）で GitHub OIDC を信頼 → サービスアカウントキー JSON 不要

実装上のハマりポイント

• bootstrap/（SA・WIF 定義）と terraform/（検証対象の main.tf）のステートファイルを分離すること。混ぜると bootstrap リソースまで検証対象に含まれる
• 組織 IAM の setIamPolicy 権限（Organization Administrator 相当）がないと google_organization_iam_member の apply が失敗

ワークフロー構成

• PR 時: Terraform plan → SCC 検証 → 違反あれば job 失敗（PR ブロック）
• 検証結果の SARIF を artifact として保存しダウンロード・確認可能

Kiro CLIでAI-DLC v2の逆解析ドキュメントを活用し、CDKプロジェクトの改善サイクルを回してみた

• URL: https://dev.classmethod.jp/articles/ai-dlc-v2-reverse-engineering-improvement-cycle/
• 日付: 2026-06-08
• Tier: Tier 3
• 要旨: Kiro CLI（claude-opus-4.6 ベース）と AI-DLC v2 の逆解析ワークフローを使い、CDK プロジェクトの設計ドキュメントを自動生成してから 2 段階の改善（即興 Vibe 改善 → orchestrator による体系的改善）を実施した実録。

詳細

AI-DLC v2 逆解析の概要

• 既存コードベースから 10 本の設計ドキュメントを自動生成（technology-stack, code-structure, components, code-quality-assessment など）
• .kiro/skills/ に aidlc-reverse-engineering / aidlc-orchestrator をインストールして実行

1 回目: Vibe 改善（即興） code-quality-assessment.md を元に Kiro CLI に即興プロンプトで改善を指示。3 コミットで実施:

1. セキュリティ強化: WebSocket Origin 検証（CSWSH 対策）、HttpOnly Cookie、IAM スコープ縮小
2. セッション外部化 + Auto-scaling: in-memory Map → DynamoDB、ECS Auto-scaling 追加
3. 運用性改善: graceful shutdown（SIGTERM 10 秒ドレイン）、JSON 構造化ログ（connId 付き）、ECS circuit breaker（デプロイ失敗時ロールバック）、CloudFront アクセスログ

2 回目: orchestrator による体系的改善 再逆解析後に aidlc-orchestrator スキルで production-hardening を指示。orchestrator が構成したワークフロー:

1. Requirements Analysis: 改善項目の構造化・優先度付け（採用/見送りの意思決定を人間が実施）
2. Application Design: 400 行規模のモノリシック server.mjs を 5 モジュールに分割設計
3. Units Generation: 3 ユニットに分割、依存関係順で実装
4. Code Generation: 各ユニットの実装

モジュール分割設計（400 行 → 各 40〜100 行）

• server.mjs: エントリポイント・DI・graceful shutdown（~40 行）
• routes.mjs: HTTP ルーティング・dashboard HTML・/health（~80 行）
• ws-handler.mjs: WebSocket 中継・backpressure・heartbeat（~100 行）
• agentcore-client.mjs: SigV4 署名・AgentCore API 通信（~60 行）
• session-store.mjs: DynamoDB CRUD + healthCheck（~70 行）

Kiro CLI の特徴

• AI-DLC スキル群（逆解析・orchestrator）と組み合わせることで、要件分析→設計→ユニット分割→実装という構造的プロセスを自動化
• ベースモデルは claude-opus-4.6

Snowflake Cortex Code Desktopで国交省の不動産情報ライブラリMCPサーバを使用して不動産情報を取得してみた

• URL: https://dev.classmethod.jp/articles/snowflake-cortex-code-desktop-mcp-mlit-real-estate/
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: Snowflake Cortex Code Desktop（プレビュー）に、国土交通省の不動産情報ライブラリ API をラップした MCP サーバー「mlit-geospatial-mcp」を接続し、自然言語で不動産情報を取得する手順と動作確認を解説。

詳細

Cortex Code Desktop の MCP 対応

• stdio / http の 2 種トランスポートをサポート
• MCP 設定ファイルは ~/.snowflake/cortex/mcp.json（グローバル）または <workspace>/.snowflake/cortex/mcp.json（ワークスペース単位）
• ツール名は mcp__<server-name>__<tool-name> 形式で名前空間化

mlit-geospatial-mcp の概要

• 国土交通省・不動産情報ライブラリ API（reinfolib.mlit.go.jp）を MCP サーバー化した Python 製ツール
• get_multi_api ツールで不動産取引価格・地価公示・都市計画 GIS・学校区・医療機関・災害危険区域など約 30 種の API を統合呼び出し
• Cortex Code Desktop がローカルでサブプロセス起動する stdio 型

制限事項

• MCP ツールのレスポンス上限 50KB（超過で切り捨て）
• デフォルトタイムアウト 60 秒（COCO_MCP_TOOL_TIMEOUT_MS で変更可）
• 地理空間データはレスポンスが大きくなりやすいため、市区町村単位などエリアを絞った問い合わせ推奨
• Cortex Code Desktop 自体は 2026-06-04 時点でプレビュー機能（GA 前に仕様変更の可能性あり）

接続構成

Cortex Code Desktop → MCP stdio connector → Python プロセス（mlit-geospatial-mcp） → 不動産情報ライブラリ API

WafCharmの新機能でAWS WAFログ分析が捗る！Bot DashboardとRate Dashboardを触ってみた

• URL: https://dev.classmethod.jp/articles/wafcharm-log-intelligence-dashboard/
• 日付: 2026-06-08
• Tier: Tier 3
• 要旨: WafCharm の新オプション「Log Intelligence」に含まれる Bot Dashboard と Rate Dashboard を実機確認。AWS WAF ログを構造化して「どんな Bot が来ているか」「レートベースルールの閾値をどう設定するか」を視覚的に分析できる機能。

詳細

Bot Dashboard

• ユースケース選択（リクエスト多いアクセス元・Bot リクエスト・悪性リクエスト）+ 抽出期間（1 時間〜30 日）を指定
• 集計項目（Top10）: Bot 識別ラベル・Bot Signal ラベル・ASN・Geo・IP・JA4 Fingerprint
• 詳細分析ビュー: 集計項目の個別値をクリックすると対応 WAF ログ一覧と Action 集計が表示 → 生ログまでドリルダウン可能
• 「ざっくり傾向 → 気になるリクエストを掘り下げ → 生ログ確認」が画面遷移なしで完結
• Bot Dashboard は AWS WAF Bot Control ルールグループ併用が前提（なしの場合 Bot 関連項目が非表示）

Rate Dashboard

• 集計単位（IP アドレスなど）とリクエスト頻度の時系列を可視化
• レートベースルールの「何回 / 何分」という閾値を視覚的に判断しやすくする
• 正常なリクエストを巻き込まない閾値の検討に活用

ルールカスタマイズフロー

• 詳細分析ビューから「カスタマイズのお問い合わせテンプレートをコピー」→ 問い合わせフォームに貼り付けて CSC 社に申請
• WafCharm の自動運用はマネージドルールベースのため、独自ルール追加には問い合わせが必要

利用条件

• Log Intelligence オプション（有料）の購読が必要
• Advanced Rule ポリシー利用・AWS WAF ログ連携有効化が前提

GitHub Copilot を利用して、更新プログラムの適用に失敗する状況の調査を実施する

• URL: https://jpwinsup.github.io/blog/2026/06/07/WindowsUpdate/QU/analyze-update-failure-with-github-copilot/
• 日付: 2026-06-08
• Tier: Tier 1
• 要旨: Microsoft サポート担当者による公式ブログ。GitHub Copilot Agent モードを VS Code 上で活用し、Windows Update のログファイルを自然言語で解析してトラブルシューティングする手順を解説。コーディング支援ツールとしてのイメージを超え、大量のログから原因・対処案を抽出する用途を紹介。

詳細

• VS Code の Copilot Chat を Agent モードで起動し、取得済みログフォルダを開いた状態でプロンプトを投げる
• 「推測が混ざる箇所はその旨を明記して」とプロンプトに含めることで、ログから確認できた事実と推測を区別したレポートを出力させる
• 2026/06/01 以降、GitHub Copilot の料金体系が AI Credits ベースに移行。個人向けプランも拡充
• データ利用ポリシーは個人向け・企業向けプランで異なるため注意が必要
• AI 出力は必ずしも正確とは限らないため、レジストリ削除などリスクある操作には事前バックアップを推奨

Coding AgentとはじめるMySQLパフォーマンスチューニング

• URL: https://tech.layerx.co.jp/entry/2026/06/09/165530
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: LayerX のエンジニアリングマネージャーによるスロークエリ改善の実録。データ量・分布変化で実行計画が崩れた複数テーブル JOIN クエリを、Coding Agent と協働で EXPLAIN / EXPLAIN ANALYZE しながら修正し、ベストケースで 50 倍以上の高速化を達成。

詳細

発端

• 内部 SLO モニタリングで主要エンドポイントの応答時間が基準違反
• 原因: データ量・分布の変化により意図したインデックスが選択されなくなった

EXPLAIN / EXPLAIN ANALYZE で発見した問題

1. JOIN 起点がメインテーブルになり、数万件を 1 行ずつ評価していた → クエリを分割して 2 回発行する設計に変更
2. 以前の NOT IN + サブクエリ フィルタが大きな集合スキャンを生む実行計画に変化していた → カラム NOT IN (...) の直接評価に書き換え（Coding Agent の EXPLAIN 分析による指摘で発見）

Coding Agent との役割分担

• Agent が担ったこと: EXPLAIN 結果の分析・複数改善案の提示・検証・実装
• 人間が担ったこと: 採用/却下の判断（メンテナンス性・改善効果の費用対効果）、過去経緯などコードに現れないコンテキストの補完、ハルシネーションへのツッコミ

使用ツール

• GORM で発行クエリを可視化するための gormgolden（同僚製）でアプリコードと実 SQL の Before/After を確認

成果

• 対象クエリ群のほぼ全てで改善達成、ベストケースで 50 倍以上の高速化

今後の展望

• SLO 違反を検知 → EXPLAIN で原因特定 → 修正・検証 の Skill 化を検討中

マルチモーダル知識グラフ「RAG-Anything」を用いた複雑な実世界ドキュメントの理解

• URL: https://tech.layerx.co.jp/entry/2026/06/09/181025
• 日付: 2026-06-09
• Tier: Tier 3
• 要旨: LayerX の R&D インターンによる RAG-Anything（マルチモーダル GraphRAG フレームワーク）の実装検証レポート。テキスト・画像・表・数式を知識グラフ上に統合し、図表の視覚情報を含む質問にも根拠追跡可能な回答を生成できることを示した。

詳細

従来の RAG が抱える 3 つの壁

1. 視覚情報の欠落: テキスト変換時にグラフや図表の視覚的意味が失われる
2. 散在情報への弱さ: 複数ページをまたぐ多段階推論が困難
3. ハルシネーション: 参照元を明示させるとモデルが本来の抽出性能を失う

RAG-Anything のアーキテクチャ

• MinerU でドキュメントをコンポーネント（テキスト/画像/表/数式）に分離
• 2 種類の知識グラフを並行構築:
  • クロスモーダル知識グラフ: VLM で非テキスト要素を説明文化し、周囲テキストと belongs_to エッジで接続
  • テキストベース知識グラフ: 固有表現抽出・関係性抽出による従来の GraphRAG
• 2 グラフを概念マッチングで統合し、全ノードをベクトル化

検索と回答生成

• クエリ分析でモダリティ（図/表/数式など）を識別し、構造的ナビゲーション + セマンティック検索のハイブリッド検索
• 該当ノードに対応する生の画像データをピンポイント取得し、VLM に渡して回答生成
• 根拠となったノード・エッジ・画像が追跡可能 → ハルシネーション検知に有効

精度評価（DocBench / MMLongBench）

• 100 ページ超の長大ドキュメントで MMGraphRAG 比 13 ポイント以上の精度向上を確認
• アブレーション研究で性能の核はデュアルグラフ構造にあることを示唆

課題

• 約 30 ページのドキュメントのインデックス構築に 30〜60 分（gemini-3-flash-preview 使用）
• ルールベースへの処理移行など最適化が実用化に必要

Ubuntu、サンドボックス化された開発環境をコマンド一発で構築。新機能「Workshop」リリース

• URL: https://www.publickey1.jp/blog/26/ubuntuworkshop.html
• 日付: 2026-06-08
• Tier: Tier 2
• 要旨: Canonical が Ubuntu に新機能「Workshop」をリリース。YAML 構成ファイルを数行記述するだけで、LXD を用いた分離済み開発環境を一発起動できる。AI エージェント向けのサンドボックス化された環境構築ユースケースも明示されている。

詳細

• Workshop は LXD（Linux コンテナ仮想化）を用いてサンドボックス化されたシステムコンテナ環境を起動
• YAML 形式の構成ファイルで再現性のある環境を定義でき、複数マシン間で共有可能
• 開発環境に含めることができる主なソフトウェア:
  • 各種プログラミング言語の実行環境
  • Ollama（ローカル LLM）
  • OpenCode
  • NVIDIA CUDA / AMD ROCm SDK
• ホストマシンのファイルシステムへのマウント、デバイス、ネットワークへの制限付きアクセスも設定可能
• AI エージェントのコード実行環境として、隔離性とセットアップの容易さを両立する選択肢として位置づけ

Claude Code のトークン削減を実測した — semble 93%・cacheRead 1800倍の内訳

• URL: https://zenn.dev/pepabo/articles/claude-code-token-reduction-measured
• 日付: 2026-06-08
• Tier: Tier 3
• 要旨: Claude Code の実トークン使用量を ccusage と semble で定量計測したレポート。cacheRead が入力の 1800 倍、コード検索削減率 93% という具体的な数字を公開。3 つの独自工夫（ルールの on-demand 化・rule-mining・効果計測）も紹介。

詳細

実測値（累計）

• cacheRead: 136 億トークン
• キャッシュによるコスト節約換算: 約 $10,168 相当（Max プランのため実際の追加支払いなし）
• 1 日の例: 入力 45 万トークンに対して cacheRead 8 億トークン（約 1800 倍）

semble（意味検索 MCP サーバー）効果

• 累計 331 回の検索で、grep/Read 総当たりと比較して 93% 削減
• semble なしの推定読み込み量: 830 万トークン → semble 経由: 50 万トークン

独自の 3 工夫

1. ルールの on-demand 化: 状況依存のルールを playbooks/ に退避し、セッション開始時の固定コストを削減
2. rule-mining: 日々のセッションログから繰り返しパターンを抽出してルールを継続改善
3. 計測の仕組み: ccusage + semble 実ログで効果を定期測定することで「やった気」を防ぐ

定番手法との組み合わせ

• プロンプトキャッシング: 設定変更時はセッションを切り直してキャッシュ破棄を 1 回に集約
• モデルルーティング: インフラ設計レビュー → Opus、実装 → Sonnet
• サブエージェント分離: 探索・レビューをサブエージェントに切り出して要約のみ受け取る