【アップデート】Claude Code v2.1.193 でOpenTelemetry の新しいログイベント claude_code.assistant_responseが追加されました

• URL: https://dev.classmethod.jp/articles/claude-code-v2-1-193-opentelemetry-assistant-response-event
• 日付: 2026-06-27
• Tier: Tier 2
• 要旨: Claude Code v2.1.193 で OpenTelemetry の新しいログイベント claude_code.assistant_response が追加された。これによりモデルが返した応答テキストを OTel 経由でエクスポートできるようになり、user_prompt イベントと prompt.id で紐付けた完全な会話ログをバックエンドに記録できる。

詳細

クラスメソッドのコンサルティング部・渡邉氏による実測レポート。Claude Code v2.1.193 リリース（2026-06-26）で追加された claude_code.assistant_response イベントの概要・制御方法・実際のログ出力を検証している。

これまで Claude Code の OTel モニタリングでは user_prompt・api_request・tool_result 等の構造化イベントをエクスポートできたが、モデルの応答テキストを直接ログイベントとして取得する手段がなかった。今回の追加でプロンプトから応答までの完全なトレース記録が可能になった。

応答内容のロギングは OTEL_LOG_ASSISTANT_RESPONSES 環境変数で制御する。1 に設定すると応答テキストを記録、0 で明示的に無効化。未設定の場合は OTEL_LOG_USER_PROMPTS の値に連動するため、OTEL_LOG_USER_PROMPTS=1 を設定済みの環境では v2.1.193 へのアップグレード後に応答テキストも自動でロギングされるようになる点に注意が必要。

2 つのイベントは共通の prompt.id 属性を持ち、バックエンドでフィルタリングすることで 1 ターン分の会話ペアを確認できる。assistant_response イベントには user_prompt イベントにはない model（使用モデル名）・request_id（Anthropic API リクエスト ID）・response_length（応答文字数）・query_source 属性も含まれる。

テレメトリ有効化には CLAUDE_CODE_ENABLE_TELEMETRY=1 と OTEL_LOGS_EXPORTER の設定が必要。著者環境では Google Cloud Logging に転送しており、Cloud Logging のログエクスプローラーで prompt.id をキーにしたフィルタで会話ペアを一括検索できることが確認されている。

AWS CLI の Agent Toolkit for AWS 連携機能を試してみた

• URL: https://dev.classmethod.jp/articles/try-aws-cli-agent-toolkit-command
• 日付: 2026-06-27
• Tier: Tier 2
• 要旨: AWS CLI v2.35.9 から追加された aws agent-toolkit コマンドを検証した記事。Agent Toolkit for AWS のスキル管理（インストール・更新・削除・検索）を CLI から操作できる機能で、Claude Code・Kiro・Cursor など主要 AI エージェントに対応している。現時点でスキル管理が利用可能なリージョンは us-east-1 のみ。

詳細

クラスメソッドのしばた氏による検証記事。AWS CLI v2.35.9 から aws agent-toolkit コマンドが追加され、Agent Toolkit for AWS のスキル管理を CLI から行えるようになった。AWS CLI v1 は非対応。

対応エージェントは Claude Code・Cline・Codex・Cursor・Gemini CLI・Kiro・OpenClaw・OpenCode・Pi・Windsurf の 10 種類。各エージェントの検出はホームディレクトリの設定フォルダ（~/.claude/ 等）の存在で判定する。

検証は AWS CLI v2.35.10、Claude Code v2.1.187、Kiro IDE v0.12.333 を使用した 64bit 版日本語 Windows 11 環境で実施。日本語 Windows 環境では PYTHONUTF8 環境変数を設定しないとエンコーディングエラー（cp932 codec エラー）が発生する。また、~/.claude.json に EMダッシュ等 CP932 非対応文字が含まれる場合は MCP サーバーの設定保存機能も動作しない。著者は後日 GitHub Issue を上げる予定。

主なサブコマンドは list-installed-skills（インストール済みスキルの一覧）、list-available-skills（入手可能なスキルの一覧）、search-skills（キーワード検索）、get-skill-file（スキル内ファイルのコンテンツ取得）、get-skill-metadata（スキルのメタデータ取得）、add-skill（新規インストール）、update-skill（アップデート）、remove-skill（アンインストール）。list-available-skills・search-skills・get-skill-file・get-skill-metadata・add-skill・update-skill は –region us-east-1 の指定が現時点で事実上必須。

Windows タイム サービスの Parameters レジストリ パラメーターについて

• URL: https://jpwinsup.github.io/blog/2026/05/28/ActiveDirectory/WindowsTimeService/w32time-Parameters
• 日付: 2026-06-27
• Tier: Tier 1
• 要旨: Windows タイム サービス（w32time）の Parameters レジストリキー配下にある各パラメーター（Type・NtpServer・Flag・SpecialPollInterval）の意味と設定値をマイクロソフト公式サポートが解説した記事。時刻同期方式の選択から NTP サーバー指定・ポーリング間隔制御まで、設計の基礎知識がまとめられている。

詳細

Windows Commercial Support Directory Services チームによる公式解説。対象レジストリキーは HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters。

Type パラメーターは時刻同期方式を決定する REG_SZ 値で、NTP（NtpServer 指定サーバーと同期）、NT5DS（ドメイン階層に従い自動決定）、AllSync（NTP と NT5DS の複合）、NoSync（同期なし）の 4 種類が設定可能。

NtpServer パラメーターは同期先 NTP サーバーを DNS 名または IP アドレスのスペース区切りで複数指定できる。各サーバー末尾にカンマ区切りでフラグを付与することで同期モードと動作を制御する。

フラグはビットフラグで、0x1（SpecialInterval: SpecialPollInterval の値で同期間隔を制御）、0x2（UseAsFallbackOnly: フォールバック専用）、0x4（SymmetricActive モード）、0x8（Client モード）を組み合わせて使用する。よく使われる組み合わせは 0x9（SpecialInterval + Client）と 0xA（UseAsFallbackOnly + Client）。

SpecialPollInterval は 0x1 フラグが指定されている場合に有効で、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient 配下の REG_DWORD 値として秒単位で設定する。

設定確認は w32tm /query /configuration コマンドで行い、変更後は net stop w32time / net start w32time または w32tm /config /update で反映させる。グループポリシーで管理されている環境ではレジストリ直接変更がポリシー再適用時に上書きされる点に注意が必要。

正直に言う。お前のClaude Codeの使い方は間違っている - Qiita

• URL: https://qiita.com/tehito/items/356e5f1dba112a075be1
• 日付: 2026-06-27
• Tier: Tier 3
• 要旨: 3ヶ月のExpo+Supabase+Swift通話アプリ個人開発から得た、Claude Codeを速くするための7つの具体的な対処法。CLAUDE.mdの肥大化、指示の一括投入、実装途中のコンテキスト圧縮、MCPの全部盛り、設計の丸投げ、レビューの省略、セッションの引きずりという典型的なミスを実体験から整理し、各対策を明示している。

詳細

筆者は個人開発プロダクト（Expo+Supabase+Swiftのネイティブ通話アプリ）をClaude Codeで3ヶ月間毎日開発した体験から、速度低下の原因を7項目に分類している。

CLAUDE.mdを2000行の全部入りにすると毎ターン全文がコンテキストに乗るため、最小限（数行）に絞りAgent Skillsに分散させる。1指示に複数の作業を詰め込むとlost-in-the-middleが起きるため、責務ごとにサブエージェント化する。実装途中の/compactは「これから何をするつもりだったか」を圧縮で消してしまうため、コミット直後の区切りでのみ打ち、長い作業は計画をPLAN.mdに書き出しておく。

MCPサーバーの全接続はツール定義それ自体がコンテキストを占有するため、その日のタスクに必要な分だけ接続しDeferred Tool Loadingを活用する。設計まで丸投げすると「動いて見えるが壊れているコード」を生成する具体例として、PKPushRegistryをletのローカル変数で受けてプッシュが届かない通話アプリが完成した失敗を挙げ、設計は人間・実装はAIの境界を守ることを強調している。

レビューは生成速度が上がった分だけ重要性が増す（バグの流入速度が上がるため）として、レビュー専任サブエージェントの活用と小さいdiffの維持を推奨。セッションはタスクが変わるたびに切り、長期の文脈は会話ではなくファイルに永続化する。「会話を育てるな、仕組みを育てろ」という設計思想の転換が3ヶ月で最も効いたとまとめている。

Claude CodeのスキルでSLO対応を自動化したらめちゃくちゃ楽になった - Uzabase for Engineers

• URL: https://tech.uzabase.com/entry/2026/06/26/100727
• 日付: 2026-06-27
• Tier: Tier 3
• 要旨: NewsPicks Platform EngineeringチームがClaude Codeのスキルを使ってSLO違反調査を自動化した実践事例。週次MTGで1.5〜4人時かかっていた障害調査を、SlackスレッドURLを渡すだけで7分以内に根本原因と対策設計まで到達できるフローに変えた。推測禁止・仮説先出し・2Kトークン上限・3回失敗で終了・辿り道の記録という5ルールをスキルに組み込む過程を具体的に示している。

詳細

NewsPicks Platform EngineeringチームはNew RelicをAPMとして採用し、SLO違反（Latency/Availability）をSlack通知で検知するモニタリング体制を持つ。週次MTGで2〜10件超の違反を扱い、1.5〜4人時を消費していた調査フローをClaude Codeのスキルに置き換えることを試みた。

最初にN+1問題の典型ケースを2〜3件解かせて実現性を確認した後、スキル化の反省点を5ルールとして整備した。ルール1（推測禁止）はSlackスレッドの人間の仮説を読んだだけで「因果方向は完全に一致」と断言した事象から。ルール3（2Kトークンで止まる）は無限ローディング状態でProプランのトークンが急増したセッションから、その時点でおおよそ仮説が立っていることを経験的に確認してエイヤーで設定。ルール4（3回失敗で終了）は本質でない部分での深掘りループを防ぐため。ルール5（辿り道の記録）はコードの経路を省略して適当な結論を出した事象と、省略を「なんらかの方法でここに飛び」と誤魔化した事象への対処。

具体的な活用事例として、動画検索機能の重さで関係ない業務まで止まった障害を紹介。11件の同時リクエストがHTTPスレッドを占有してスレッドプールが枯渇、コンテナが強制入れ替えられた。SlackスレッドURLをスキルに渡すと、NRQLで7本のクエリを発行してMySQLに5500〜7500回・DynamoDBに2500〜3600回/リクエストというアクセス数を検出し、Serviceレイヤーの明示的N+1（3箇所）とEAGER由来の暗黙的N+1（8箇所）を7分で特定。その後13分で対策検証、合計25分で設計書が完成した。人間チームが7〜10分かけて複数のダッシュボードを行き来しながら断片的に確認していた作業と比較して、時刻を揃えた5系統のメトリクス照合を一気に実行した点が差別化要因とされている。スキルの次の改善案として、Latency調査用とAvailability調査用への分割と親スキルによる種別判定・委譲構成が検討されている。

Gemini を Claude の「サブエージェント」に —— 大規模開発でコストを実測

• URL: https://zenn.dev/google_cloud_jp/articles/63205d90345627
• 日付: 2026-06-27
• Tier: Tier 3
• 要旨: Claude Codeを指揮層、Gemini（Antigravity CLI）を実行層とする2層ハイブリッド構成のプラグインを実装し、実測でClaudeコストを27〜64%削減しつつ同品質（adk eval全通過）を達成した報告。「判断は優秀なモデル、量産はコスパの良いモデル」という振り分け設計の実装と効果の裏付けが中心。

詳細

Uber社が約5000人へのClaude Code展開で4ヶ月でAIコーディング年間予算を使い切った事例やMicrosoftの社内Claude Codeライセンス停止報道を背景として、エージェントのコスト問題の構造を分析している。コストの主因は出力でなく入力であり、エージェントは毎ターン文脈を読み直すcontext snowball効果で後半ほど高くなること、トークンを増やしても性能は上がらないこと（AnthropicはエージェントでFLOP比約4倍・マルチで約15倍、Stanfordは入力主導でトークン増≠性能と報告）を整理し、「コンテキストを薄く保ち量産を別モデルへ逃がす」設計の根拠としている。

実装はClaude Code Plugin Antigravity for Claude Codeとして公開。核心は「いつ・どう委譲し・どう検証するか」を定義したSKILL.mdと、ツールを委譲ラッパー（agy-delegate.sh）だけに制限した委譲専用サブエージェント。Claude側はファイル内容の生成にトークンを使わず、Gemini側でファイル生成を完結させる設計。セッション開始フックでコスト方針を自動注入し、スラッシュコマンド（delegate/review/research/status/result/cancel）から操作できる。

実測比較はGoogle ADKでのSDLCアシスタント（要件定義→基本設計→詳細設計をSequentialAgentで連結）の構築をタスクとし、Claude単独@high・単独@max・ハイブリッドの3アームで比較。ハイブリッドはターン数87（vs 126・154）、Claude側実額$9.56（vs $13.08・$26.71）で、adk eval 3/3を全構成が通過した。cache_readはハイブリッドが最小（5.65M vs 10.19M・20.45M）で、Geminiへ逃がした生成分はClaudeのトークン計上外のため実差はさらに大きい。

使いどころは大規模機能・一括移行・網羅テスト・多エージェント構築・大量ドキュメント横断など「まとまった仕事」で、小さな単発タスクは往復コストが勝るためClaude直が正解としている。コスト以外の付加価値としてVertex AI Searchによる社内データgrounding、クロスモデル検証、ADKのAgent Engineデプロイ一気通貫も挙げている。公開後にRedditで27K views・84 upvotesの反応を得ており、WSL環境での/mntマウントI/O遅延やヘッドレス時の挙動など実フィードバックを取り込んで改善を継続中。