2026/06/15以降に料金体系が変更されたClaudeをどう使うか考えてみた

• URL: https://dev.classmethod.jp/articles/claude-2026-pricing-reform-bucket-system/
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: 2026 年 6 月 15 日から Claude Code の料金体系が 2 つの財布に分離された。ターミナルでの対話利用は従来通りのサブスクリプション枠のままだが、Agent SDK/claude -p/GitHub Actions などの自動化部分が月次クレジットの別枠になる。

詳細

classmethod せーの氏による料金改定の整理と使い分け考察記事。6 月 14 日（改定前日）に実機で確認した情報をもとにしている。

AI ツールの課金モデルを「セッションリセット型」「ローリングウィンドウ型」「固定時刻リセット型」「クレジット消費型」の 4 パターンに整理している。Claude Max 5x の対話部分は 5 時間セッション枠 + 週次制限のままで、自動化部分のみが月次クレジット消費型になる。Codex は 5 時間ウィンドウに週次上限がある構成だが、週次上限のリセット方式（固定時刻かローリングかど）は公式に明記されていない。

GitHub Actions での自動レビューや @claude 応答を使っている場合は 6 月 15 日以降の課金先が変わる点を把握しておく必要がある。

Copilot Studio 初めてのエージェントを作ってみた: 作成/指示/テスト

• URL: https://dev.classmethod.jp/articles/copilot-studio-create-first-agent/
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: Microsoft Copilot Studio でエージェントをゼロから作る連載の第 1 回。ノーコードで指示を設定し、テストチャットで動作確認するまでの手順を実機で確認した。既定モデルとして Claude Sonnet 4.6 が選択されていた点も記録している。

詳細

classmethod けーま氏による Copilot Studio 連載第 1 回（エージェント作成編）。

Copilot Studio はローコードでエージェントを作るツールで、指示/ナレッジ/トピック/ツール/トリガーを束ねてエージェントを構成する。新規作成時のデフォルトは生成オーケストレーション（言語モデルが部品を自動選択する方式）で、クラシックオーケストレーション（トリガーフレーズで固定）とは設定で切り替えられる。

2026 年 6 月の筆者の環境では GPT-5/4.1 や Claude Sonnet 4.5〜Opus 4.8 など複数モデルが選択でき、デフォルトは Claude Sonnet 4.6 だった。トライアルでの作成とテストチャットは無料で可能だが、Teams 等への公開には Microsoft 365 Copilot ライセンスまたは Copilot Studio User License が必要。

Copilot Studio ナレッジでファイルに基づく回答を試してみた: Web検索オフとの比較も

• URL: https://dev.classmethod.jp/articles/copilot-studio-knowledge-grounded-answers/
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: Copilot Studio のナレッジ機能を使い、アップロードした docx ファイルの内容に基づいて根拠付き回答を返すエージェントを構築した。Web 検索オン/オフで参照ソースが変わる挙動と、社内データだけで回答させる際の設定ポイントを確認した。

詳細

classmethod けーま氏による Copilot Studio 連載第 2 回（ナレッジ編）。

架空 SaaS 企業 3 社の四半期 KPI データを docx でアップロードし、Dataverse にインデックスされた後に質問したところ、参照ソースを明示しながら正確に回答した。Web 検索がデフォルト有効になっており、外部の公開資料もソース候補に含まれていたため、社内データのみに限定するには明示的にオフにする必要がある。

対応ファイル形式はテキストベースのものに限られ、画像/音声/動画は非対応。1 ファイル最大 512MB、1 エージェントあたり 500 ファイルが上限。インデックス化に数分かかるためアップロード直後のテストでは一般知識で回答されることがある。Web 検索オフの設定は生成オーケストレーションが有効な場合のみ利用できる。

開発者マシンのセキュリティスキャン完全ガイド — Bumblebee/TruffleHog/OSV-Scannerで3つの脅威軸をカバーする

• URL: https://dev.classmethod.jp/articles/developer-machine-security-scan-bumblebee-trufflehog-osv-scanner/
• 日付: 2026-06-15
• Tier: Tier 3
• 要旨: MCP サーバーやコーディングエージェントが普及した今、開発者のローカルマシンが新たな攻撃面になっている。Bumblebee（サプライチェーン攻撃）、TruffleHog（シークレット漏洩）、OSV-Scanner（既知脆弱性）の 3 ツールで脅威軸を網羅的にカバーできる。

詳細

classmethod による開発者向けセキュリティガイド記事。

Bumblebee は Perplexity がオープンソースで公開した Go 製スキャナー。npm/PyPI などのパッケージだけでなく Claude Desktop や Cursor などの MCP 設定ファイルもスキャン対象にできる唯一の OSS ツール。コードを実行せず lockfile やメタデータだけを読むため安全。baseline/project/deep の 3 プロファイルがあり、NDJSON で出力するため jq と組み合わせて使う。

TruffleHog は設定ファイル内の平文 API キーや認証情報を検出する。OSV-Scanner は依存パッケージの既知 CVE を OSV.dev に照合する。3 ツールはそれぞれ異なる脅威軸を担当し守備範囲は重複しない。いずれも無料で利用できる。

AWS Fargateで32vCPUが利用可能になったので、裏側のインスタンス世代を覗いてみた

• URL: https://dev.classmethod.jp/articles/fargate-32vcpu-host-generation/
• 日付: 2026-06-15
• Tier: Tier 3
• 要旨: 2026 年 6 月から Fargate で 32vCPU タスクが使えるようになった。ECS Exec でホスト情報を取得したところ、AZ によって c5/c6i/c7i（x86）や Graviton2/Graviton4（ARM）など複数世代が混在していることが確認された。

詳細

classmethod による実機計測記事（n=1）。東京リージョンで ECS Exec を使い /sys/class/dmi/id/product_name と /proc/cpuinfo を取得した。

x86_64（32vCPU/60GB）では ap-northeast-1a が c5.9xlarge（Intel Xeon Platinum 8223CL）、ap-northeast-1c が c6i.8xlarge、ap-northeast-1d が c7i.8xlarge と 3 世代が混在。ARM64 では ap-northeast-1a が Graviton2、他 2 AZ は Graviton4 だった。同一タスク定義でも AZ によって異なる世代が使われ得る。

料金は 32vCPU/60GB で x86 が 1,950 ドル/月、ARM が 1,560 ドル/月（約 20% 差）。CPU 命令セットへの依存が大きいワークロードでは ECS on EC2 でインスタンスタイプを固定する方が確実。

Security Hubの検知項目をお客様への課題起票文にするスキルをClaude Code自身に作ってもらった

• URL: https://dev.classmethod.jp/articles/securityhub-issue-claude-code-skill/
• 日付: 2026-06-15
• Tier: Tier 3
• 要旨: Security Hub の検知 ID と対象リソース一覧を渡すだけで Backlog 等への課題起票文を自動生成する Claude Code スキルを構築した実践例。スキル自体も Claude Code に作らせ、実際の出力を見ながら SKILL.md のルールを育てていった過程を公開している。

詳細

classmethod コンサルティング部の林氏による実装レポート。

スキルは SKILL.md と issue-template.md の 2 ファイル構成。コントロール ID（例: EC2.9）と対象リソース一覧をコピペで渡すと、課題概要/詳細/実施内容/完了条件/参考情報の構成で起票文を生成する。実施内容では「修復対応」と「抑止（SUPPRESSED）対応」の 2 方針を常に併記し、最終判断は顧客に委ねる形にしている。

SKILL.md の改善は「生成した文章を見て気になる箇所を指摘 → SKILL.md に反映」のループで行う。文体ルールとして体言止めの目的欄、「存じます」など過剰に丁寧な表現の禁止、同じ依頼の重複禁止などを累積的に追加したことで出力品質が向上した。

DevOps AgentがリモートMCPサーバーとして利用可能になりました

• URL: https://dev.classmethod.jp/articles/use-devops-agent-via-remote-mcp-server/
• 日付: 2026-06-15
• Tier: Tier 3
• 要旨: AWS DevOps Agent が 6 月 12 日のアップデートでリモート MCP サーバーとして公開された。Claude Code からアクセストークンで接続でき、24 種類のツールが利用可能になる。ただしリリース直後のため release readiness review は PENDING_START のまま失敗するケースが確認された。

詳細

classmethod によるアップデート検証記事。

DevOps Agent のコンソールでアクセストークンを発行し、.mcp.json に HTTP タイプのサーバー設定を書くことで Claude Code から接続できる。ただしコンソールが表示するサンプル設定は type フィールドの位置が誤っており、正しくはサーバー名の配下に移動する必要がある。

利用可能なツールは get_agent_space、create_investigation、create_release_readiness_review、chat など 24 種類。PR のリスクを評価する create_release_readiness_review は、GitHub PR を渡して呼び出せるが、本稿の検証時点では PENDING_START のまま 15 分後に FAILED になった。CloudTrail では CreateBacklogTask の呼び出しは記録されており、DevOps Agent 内部の処理が追いついていない状態と推測される。

IAM ユーザーのアクセスキーから Amazon SES SMTP 認証情報を生成してメール送信する

• URL: https://dev.classmethod.jp/articles/yutaka-memo-ses-smtp-iam-conversion/
• 日付: 2026-06-15
• Tier: Tier 3
• 要旨: 既存の IAM ユーザーのシークレットアクセスキーから SES 用の SMTP パスワードを生成する方法を検証した記事。HMAC-SHA256 で署名したバイト列を Base64 エンコードして変換する。一時的な認証情報（STS 等）では動作しない点に注意が必要。

詳細

classmethod オペレーションズによる手順検証記事。

IAM ユーザーに ses:SendRawEmail を許可するポリシーをアタッチし、公式ドキュメントの Python スクリプトでシークレットアクセスキーを SES SMTP パスワードに変換する。変換は AWS4 署名プロセスを応用した固定アルゴリズムで、バージョンバイト（0x04）を先頭に付加してからエンコードする。

SMTP ユーザー名はアクセスキー ID、パスワードは変換後の値を使う。AWS のシークレットアクセスキーをそのまま SMTP パスワードとして使うと 535 Authentication Credentials Invalid で失敗することも実験で確認。AWS ドキュメントでは認証情報の管理を簡単にするため専用の IAM ユーザーを作ることを推奨している。

Windows Server 2025 でフェールオーバー クラスター構築後に作成される「ユーザー マネージャー グループ」役割について

• URL: https://jpwinsup.github.io/blog/2026/06/10/FailoverClustering/User-Manager-Group-role-created-after-building-a-WSFC-cluster-on-Windows-Server-2025/
• 日付: 2026-06-15
• Tier: Tier 1
• 要旨: Windows Server 2025 でフェールオーバー クラスターを構成すると、クラスター マネージャーに「ユーザー マネージャー グループ」という役割が自動作成される。これは Azure Portal の Windows Admin Center との認証に使うシステム内部コンポーネントであり、削除しても自動再作成されるため、Azure 連携しない環境では停止状態での運用が推奨される。

詳細

Windows Server サポートチームによる公式技術ブログ。対象は Windows Server 2025 のフェールオーバー クラスター環境。

クラスター構成後に「ユーザー マネージャー グループ」というロールが自動生成される事象を解説している。このロールは Azure Portal 上の Windows Admin Center 連携や認証処理でシステムが内部的に使うコンポーネントであり、他のクラスター リソースと依存関係を持たない。

手動削除してもクラスター サービスの再起動タイミングで自動再作成される。永続的に削除する方法や機能を無効化する設定は存在しない。停止状態に設定した場合は、次回フェールオーバー時も停止のまま維持される。Azure 連携しない環境での停止運用はクラスターの基本機能に影響しない。

セキュリティを考慮したClaude Codeの企業運用に正解を出してみる

• URL: https://nocode-sol.co.jp/blog/tech/claude-code-enterprise-security-guide/
• 日付: 2026-06-01
• Tier: Tier 3
• 要旨: Claude Code の企業導入に必要なセキュリティ設計を Permissions/Sandboxing/Managed Settings/OpenTelemetry の多層防御で体系化した実践ガイド。絶対に外せない 3 設定（disableBypassPermissionsMode/Read deny/OTEL 有効化）を起点に、チェックリストと recommended settings.json 雛形を公開している。

詳細

ノーコードソリューションズによる企業向け Claude Code セキュリティガイド記事。

エージェント型ツール固有のリスクとして、プロンプトインジェクション/機密情報漏洩/権限暴走/サプライチェーン汚染/監査証跡の欠如の 5 つを挙げている。

Permissions は deny > ask > allow の優先順位で評価され、Managed Settings（/Library/Application Support/ClaudeCode/managed-settings.json）で定義した deny ルールはユーザーが上書きできない。bypassPermissions モードは Managed Settings で disableBypassPermissionsMode: “disable” を設定して禁止することが推奨される。

Sandboxing は macOS では Seatbelt、Linux/WSL2 では bubblewrap を使い、作業ディレクトリ外への書き込みと許可リスト外ドメインへの通信を OS レベルで遮断する。ただし正規通信経路（api.anthropic.com）でのコンテキスト流出は防げないため、Read 権限の最小化とシークレットの事前スキャン（gitleaks/trufflehog）を組み合わせる必要がある。

OpenTelemetry で部門別トークン消費/ツール拒否率/異常エラー頻度/MCP 接続先を可視化することで、コスト統制とセキュリティ監視を一体化できる。

2027年までにAIエージェントでコーディングを行うチームの65％が、IDEが必要不可欠だとは考えなくなる。ガートナーの予想

• URL: https://www.publickey1.jp/blog/26/2027ai65ide.html
• 日付: 2026-06-14
• Tier: Tier 2
• 要旨: ガートナーが AI コーディングエージェント市場の新局面を宣言。2027 年までにエージェント型コーディングを利用するチームの 65% 超が IDE を必要不可欠と見なさなくなり、制御とガバナンスの主軸が自動化プラットフォームへ移行すると予測した。

詳細

publickey1.jp による調査会社レポートの解説記事。

AI によるコーディング支援はもともと VS Code などの IDE に組み込む形で登場したが、最近では Claude Code や Antigravity 2.0 のような IDE に依存しない形態のエージェントが台頭している。ガートナーはこの変化を「拡大と競争再編の新段階」と位置づけ、AI エージェントが計画からコードレビューまでソフトウェア開発ライフサイクル全体をカバーするようになると指摘している。

制御やガバナンス、検証の機能が IDE から自動化プラットフォームへと移行するという予測は、開発ツール市場の地殻変動を示唆している。

WASI 0.3が正式版に。WebAssembly Componentの非同期処理が共通基盤に

• URL: https://www.publickey1.jp/blog/26/wasi_03webassembly_component.html
• 日付: 2026-06-14
• Tier: Tier 2
• 要旨: ByteCode Alliance が WASI 0.3 の正式版をリリース。コンポーネント間の非同期処理を統一イベントループで管理できるようになり、異なるコンポーネント同士の連携が大幅に容易になった。

詳細

publickey1.jp による技術ニュース記事。

WASI の変遷は 0.1（OS API 抽象化）、0.2（コンポーネント モデル採用）、0.3（非同期処理の共通化）と進んできた。0.2 では各コンポーネントが独自のイベントループを持っており、独自非同期 API を持つコンポーネントを他と組み合わせることが困難だった。

0.3 ではホストがイベントループを一元管理する設計になった。これによりすべてのコンポーネントが同一イベント基盤で非同期処理を行えるようになり、コンポーネント間連携の障壁が解消された。リファレンス実装の Wasmtime は 6 月 20 日リリース予定の v46 で WASI 0.3 を実装し、非同期処理がデフォルト有効になる予定。今後は ABI の改善と Component Model 1.0 を目指す。

vol.210 イベントログを使いこなせ（その2）｜セイテク・シス管道場（Web）

• URL: https://www.say-tech.co.jp/contents/blog/yamanxworld/2026vol210
• 日付: 2026-06-14
• Tier: Tier 2
• 要旨: Windows Server のイベントログ活用術の第2回。カスタムイベントの書き込み方法と、イベント発生をトリガーにタスクスケジューラでスクリプトを自動実行する連動機能を解説する。

詳細

山内和朗氏（元山市良）による Windows Server 系管理技術の連載。

eventcreate コマンドまたは Write-EventLog コマンドレットでカスタムイベントをアプリケーション ログに書き込める。イベント ID の範囲は eventcreate が 1-1000、Write-EventLog が 0-65535。Write-EventLog はイベント ソースの事前登録が必要で、New-EventLog でソースを作成する。

イベント ビューアーで特定のイベントを選択し、右クリックから「このイベントにタスクを設定」するとタスク スケジューラのイベント ビューアー タスク配下にタスクが作成される。これにより、特定エラーの発生をトリガーにサービス再起動やスクリプト実行を自動化できる。電子メール送信アクションは Vista 以降廃止されているため、プログラム起動アクションで代替する。

もうプロンプトを書くな——「Loop Engineering」という新しいパラダイムの正体

• URL: https://zenn.dev/acrosstudioblog/articles/38509c0473683a
• 日付: 2026-06-11
• Tier: Tier 3
• 要旨: Addy Osmani のブログと Boris Cherny の発言をもとに「Loop Engineering」というパラダイムを解説した記事。プロンプトを書く人から、プロンプトを出し続けるシステム（ループ）を設計する人へと、開発者の役割が移行しつつあることを 6 モジュール構成で体系化している。

詳細

acrosstudioblog による技術動向解説/実践ガイド記事（一次情報は Addy Osmani のブログ, 2026-06-07）。

AI パラダイムの変遷を「Prompt Engineering（指示の質）→ Context Engineering（文脈の質）→ Harness Engineering（実行環境の質）→ Loop Engineering（サイクルそのもの）」の 4 世代で整理している。Loop を構成する 6 モジュールは Automations（自律起動）、Worktrees（並列作業の分離）、Skills（知識の永続化）、Sub-agents（牽制するエージェント）、Connectors（MCP 経由の外部接続）、Memory（外部状態記録）。

Verifier を実装するエージェントはあえて別モデルを使うことを推奨している（同モデルでは盲点も同じになるため）。Loop の停止条件として「合格/タイムアウト/コスト上限/リスクトリガー/人間引き渡し」を事前設定することが重要で、回せば偉いという考え方とは異なる。

3 つのリスクとして「検証の死角（done は自己申告であって証明ではない）」「Comprehension Debt（自分が書いていないコードへの疎遠化）」「Cognitive Surrender（AI に判断基準を手放すこと）」を指摘している。

CLAUDE.mdを太らせるな——ルールは必要な瞬間に読ませろ

• URL: https://zenn.dev/generald/articles/claude-rules-context-diet
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: CLAUDE.md に溜まったルールを目的別に適切な場所（paths: frontmatter/hook/skill）へ分散させることで、常駐コンテキストを削減しつつ効果を維持する実践ガイド。ルールは削除せず、必要なタイミングにだけ読み込まれる仕組みに蒸留する考え方を解説している。

詳細

個人技術者による Claude Code 設定の最適化記事。

ルールの配置先を「どの作業でも必要な短い原則 → CLAUDE.md」「特定ファイルを触る時だけ → paths: frontmatter 付きルール」「特定コマンド直前/ツール結果直後 → hook + additionalContext」「長い手順/再利用フロー → skill」「危険操作の境界 → hook enforcement」の 5 種類に整理している。

paths: は README ルールやファイル種別ごとのコーディング規約に向いており、コマンドや結果に連動する場合は PreToolUse/PostToolUse hook が適している。hook の additionalContext は画面出力ではなく Claude の次の判断コンテキストとして差し込まれる点が重要。増え続ける知識（ミスログ等）を always-on に置くと常駐コストが線形に増加するため、参照ファイルに退避させるのがパターン。

Claudeのマルチエージェント3系統 — Dynamic Workflows / Agent View / Managed Agents

• URL: https://zenn.dev/mdtechknowledge/articles/claude-code-agent-view-guide
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: Claude Code のマルチエージェント機能は同名に見える 3 系統が存在し、役割とレイヤーが異なる。Dynamic Workflows（ローカル実行エンジン）、Agent View（ローカル管理 UI）、Managed Agents（クラウド基盤）の違いを体系的に整理した技術ドキュメント。

詳細

mdtechknowledge による Claude Code 技術解説記事。2026 年 5 月時点の公式ドキュメント/ブログ/CHANGELOG に基づく。

Dynamic Workflows は “workflow” キーワードで起動し、Claude が生成した JavaScript スクリプトが最大 1000 サブエージェントを並列実行する。同時実行は最大 16。サブエージェントの実行結果はスクリプト変数に保持され、最終回答のみメインのコンテキストに返る。

Agent View（v2.1.139 で Research Preview 開始）は並行セッションを 1 画面で管理する CLI ダッシュボード。バックグラウンドセッションの状態（Working/Needs input/Idle/Completed/Failed/Stopped）を確認し、peek（Space）で概要表示、Enter でアタッチできる。セッションは per-user supervisor プロセスで管理され、シャットダウンで停止する。

Managed Agents はクラウドで常駐動作する別製品（API 経由）。3 系統の使い分けは「並列に解くなら Dynamic Workflows」「複数を見るなら Agent View」「クラウドで常駐させるなら Managed Agents」というシンプルな判断軸で整理できる。

Claude Code サブエージェントの歩き方 — Explore が read-only な理由と切替の仕組み

• URL: https://zenn.dev/mdtechknowledge/articles/claude-code-subagent-readonly-switch
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: Claude Code のサブエージェントにはタイプ別のツール権限差があり、Explore は意図的に read-only として設計されている。v2.1.172 からサブエージェントが自身のサブエージェントを最大 5 階層まで生成できるようになり、委任の設計が重要になった。

詳細

mdtechknowledge による Claude Code サブエージェント技術解説記事。

サブエージェントのタイプと権限は、Explore（読み取り専用: Glob/Grep/Read/WebFetch/WebSearch）、Plan（読み取り系+分析のみ）、general-purpose（書き込み系含む全ツール）、claude 無名デフォルト（全ツール）と分かれている。Explore が read-only なのはコンテキスト保護と誤変更防止のための意図的な設計で、エラーではない。

書き込みが必要なのに Explore に委任されると「Explore は read-only でした。general-purpose に切り替えて再起動します」と軌道修正が発生する。このとき Explore での進行結果は引き継がれず general-purpose が最初からやり直すため、書き込みが要るタスクでは最初から general-purpose を明示指定するのが効率的。

v2.1.172 でサブエージェントの 5 階層ネストが可能になり、Dynamic Workflows の横方向の並列と組み合わせて階層的に展開できるようになった。階層が深くなるとトークン消費が急増するため、ワーカー用サブエージェントのモデルを Sonnet などに明示指定するコスト設計が重要になる。

【2026年最新版】AIコーディングツール11選 GitHub Copilot/Cursor/Claude/Codex/Devin 徹底比較

• URL: https://zenn.dev/microsoft/articles/compare_ai_coding_agents
• 日付: 2026-06-14
• Tier: Tier 2
• 要旨: GitHub Copilot を基準に Claude Code/Codex/Cursor/Windsurf/Cline/Devin/Amazon Q Developer/Gemini Code Assist/Antigravity など 11 ツールを料金/機能/エンタープライズ対応の観点で横断比較した包括的なガイド。

詳細

Microsoft 公式 Zenn アカウントによる比較記事。

GitHub Copilot は Business $19/月（1,900 AI Credits）、Enterprise $39/月（3,900 AI Credits）で最も広く採用されている。AI Credits はトークン消費を課金単位に変換したもので、入力/出力/キャッシュ済みトークンを含む。

Claude Code は対話部分がサブスクリプション枠、自動化部分が月次クレジットに分離されている（6/15〜）。Codex はローリングウィンドウ型の 5 時間枠に週次制限がかかる。Devin は月 $500 前後のプランで自律型タスク実行に特化している。

エンタープライズ要件（SSO/監査ログ/IP補償）の観点では、GitHub Copilot と Claude Code が比較的充実している。Azure/AWS/Google Cloud 環境との統合もそれぞれの強みがあり、クラウド環境に応じた選択が推奨される。

週刊AI駆動開発 - 2026年06月14日

• URL: https://zenn.dev/pppp303/articles/weekly_ai_20260614
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: 今週の主要トレンドはサブエージェントのネスト実行（Claude Code v2.1.172）と、エージェントの信頼性を本体性能ではなく実行フローの外側で担保するアプローチ（Forge/Statewright）の台頭。AI 駆動開発の関心軸がプロンプトからエージェント基盤エンジニアリングへ移行しつつある。

詳細

リリース情報/注目リポジトリ/AI ニュース/論文/テックブログ/海外コミュニティ/イベントを週次でまとめた記事。

Claude Code は v2.1.176 が最新で、今週の目玉は v2.1.172 でのサブエージェントの 5 階層ネスト対応。サブエージェントのモデル指定（Haiku で高速低コストなワーカーを指定）が可能になった。kiro は /goal コマンドでゴール駆動ループを搭載、cursor は Bugbot を Composer 2.5 に更新して平均レビュー時間を 5 分から 90 秒に短縮した。

海外コミュニティでは Forge が 8B モデルのエージェント成功率を 53% から 99% に引き上げたガードレール実装が話題になった。ツール呼び出しの検証を実行フローの外側に設けることで小型モデルでも実用水準に到達できる事例として注目されている。BM25 がセマンティック埋め込みよりもツール選択に向いているという報告も複数挙がっており、実用的なツール選択にはキーワードマッチで十分なケースが多いとされている。

新モデルとして Fable 5/Mythos 5（Anthropic）、GPT-5.5 Instant 更新（OpenAI）、Gemma 4 12B（Google DeepMind）、Cohere North Mini Code（Apache 2.0）が発表された。

Claude Code の常駐コンテキストを 62% 削減した話 — prompt caching 時代のハーネス設計

• URL: https://zenn.dev/tarowhitey/articles/claude-code-resident-context-diet
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: CLAUDE.md + .claude/rules/ の常駐コンテキストを 635 行から 239 行（62% 削減）、65KB から 16KB（75% 削減）に圧縮した実践報告。prompt caching の仕組みと組み合わせ、高頻度で更新されるミスログを常駐外に出すことでキャッシュの安定性と固定費の削減を両立した。

詳細

個人事業主（1 人 + AI COO 体制）による Claude Code ハーネス設計記事。

Anthropic 公式ブログ「Prompt caching is everything」の原則（静的→動的の順序、編集するとその位置以降のキャッシュが破壊される）を実務に適用した事例。ミスログは更新頻度が最も高いのに常駐ルールの最大ファイルという最悪のアンチパターンだったと分析している。

改善策は 4 つ。ミスログは knowledge アーカイブに移動して常駐側に 1 行ルールのみ残す。月次チェックリストはスキル化して呼ばれた時のみロードする。解説文は knowledge に退避する。コマンド一覧は /help で足りる部分を削除して複合タスクの判定表のみ残す。

おまけとして、スキル化で決定論スクリプトに置き換えた週次報告の事前チェックで「空出力 = ゼロ件と解釈していたバグ」を発見した事例も記録。gh CLI の 401 エラーを 2>/dev/null で握りつぶしていたという典型的な実装ミスで、リトライと失敗時の明示出力で修正した。

MCPは万能ではなかった ～ TeamsログをClaude Codeで取得するまで ～

• URL: https://zenn.dev/truestar/articles/8d280b284f630f
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: Teams チャネルの全件メッセージ取得を試みたところ、MCP の read_resource ではページネーションが機能せず最新 20 件程度しか取れなかった。最終的に Graph API の委任アクセス + デバイスコードフロー + Python スクリプト（Claude Code 生成）で全件取得に成功した事例報告。

詳細

社内 Q&A ナレッジ構造化プロジェクトの技術報告記事。

MCP の read_resource で Teams チャネルのメッセージ一覧を取得できたが、$skip/$skipToken などのページネーションパラメータが無視され、返信（子メッセージ）の取得も /replies を付与したリクエストでは機能しなかった。差分取得には使えるが全件取得には不向きという結論に至った。

代替策として Graph API を直接呼び出す Python スクリプトを Claude Code に生成させた。認証方式は「必要最小限の権限で済む方式から検討する」を原則に、委任アクセス + デバイスコードフローを選択。ChannelMessage.Read.All はテナント管理者の明示的な同意が必要な権限で、取得範囲は自分が Teams で見られるものと同一になる。ガバナンスの観点では「API を使うこと」よりも「取得後のデータの扱い」にリスクがあると整理している。

一人開発でも「AI が何をどう直したか」が追えなくなる問題を、設計書とインラインコメントで解決した話

• URL: https://zenn.dev/tukaponx/articles/2e15f2b9dcbda6
• 日付: 2026-06-14
• Tier: Tier 3
• 要旨: Claude Code で一人開発する中で、AI が何を直したか追えなくなる問題に直面した筆者が、設計書（HTML 群）を中心に据えて Firebase で実機からインラインコメントを書き込み、/comment-fix スキルで PR を自動生成するフローを構築した実践記録。

詳細

個人開発者による Claude Code 開発フロー改善記事。

クレジット節約のため複数の修正を 1 セッションで依頼していたところ、Claude が自動で触ったファイルが 20 個以上に広がり何が変わったか追えなくなった。Fable 5 でコードベース全体を読ませ、設計書（screens/ui-spec/data-model/logic-spec/manual の HTML 群）を生成することで全体像を取り戻した。

設計書に対するコメントをスマホから書けるように Firebase Hosting + Firestore で公開し、/comment-fix スキルで「未解消コメント → 設計書 + コード更新 PR 自動生成」のフローを作った。判断不能なコメント（機能提案や UX 方向性）はスキルが保留リストに出力して人間が後で決める設計にしている。

LocalizedStringKey の文字列補間で Int がロケール依存の桁区切り表示（2,026）になるバグも、このフローで発見して修正できた。PR 単位がコメント由来になったことで git 履歴から修正理由を逆引きできるようになったのが主な改善効果。