Claude Fable 5がもたらす長時間自律エージェントの時代──Anthropic「Code with Claude」基調講演

• URL: https://codezine.jp/article/detail/24513
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: body: FETCH_FAILED

Agent Trace × Jujutsu でたどる AI コードの来歴

• URL: https://dev.classmethod.jp/articles/agent-trace-jujutsu-ai-code-tracking/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: CursorがRFC v0.1.0で公開したオープンデータ仕様「Agent Trace」（どの行をどのAIがどの会話で書いたか記録する仕様）を、Claude Codeのhookとjujutsu（jj）VCSを組み合わせて実装・動作検証。jjのchange IDがrebaseに強く、Agent Traceとの相性が良いことを実測で確認。

詳細

Agent Trace仕様の概要：

• Cursor製。Cognition（Devin）、Google Julesが策定協力
• TraceRecord: 1ファイル編集イベントを記録するJSONL行。vcs.revision（change ID）・contributor（ai/human）・model_id・ranges（行番号）を持つ
• 保存先は未定義（参照実装はsidecar JSONL: .agent-trace/traces.jsonl）

jjとの相性が良い理由：

• jjのchange IDはrebase/amendで変わらない → AI生成コードを人間が手直ししてもtraceが壊れにくい
• working copyが常に@（commit）なので、編集時点のrevisionに即時紐付く
• gitではcommitまでHEADが変わらないが、jjはこの問題がない

Claude Code hookによる実装例： PostToolUse（Write/Edit）に.claude/hooks/agent-trace-jj.shを登録し、jj log -r @ --ignore-working-copyでchange IDを取得してJSONLに追記。行範囲（ranges）はstructuredPatchの追加行から算出。

確認フロー：jj file annotate → change ID → .agent-trace/traces.jsonlをgrep → 会話URLへ

自作TUI tij で[AI]バッジと行マーカー（▎）のoverlayを実現した完成度の高い実装報告。

Amazon Connect の UI ビルダーで AI アシスタントを使ってビューを作成できるようになりました

• URL: https://dev.classmethod.jp/articles/amazon-connect-ui-builder-ai-assistant-view/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Amazon Connect UIビルダーにAIアシスタント機能が追加。自然言語でオペレーター引き継ぎ用ビューを20秒程度で生成できることを実機検証。コンタクト属性の動的バインドやトラブルシューティング支援まで同一UIで完結することを確認。

詳細

検証内容：AIエージェントからオペレーターへのエスカレーション時に、AIの対応内容をオペレーターへ引き継ぐビューを自然言語で生成。

生成されたビュー項目：顧客電話番号・AIエージェントの対応内容・会話要約・顧客の課題・エスカレーション理由

追加指示で動的値に変換：コンタクト属性（telephoneNumber、conversation_summary等）を指定すると、動的バインドに自動変換。

実用上の注意：

• 個人情報を含むコンタクト属性のフローログ出力先を確認する必要あり
• 新規・既存ビューどちらにも適用可能
• ビューをフローで表示する手順もAIアシスタントに質問できる（UI設計とフロー設定を同一UIで完結）

「ビューの作成に必要な時間と専門知識を最大70%削減できる」とAWS公式が説明。コンタクトセンターマネージャーが直接操作できるノーコード的な価値。

AWS CLI v1が2026年7月にメンテナンスモード入り。v1が残っていないか確認してECR認証をv2化してみた

• URL: https://dev.classmethod.jp/articles/aws-cli-v1-maintenance-mode-check-and-migrate/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: AWS CLI v1が2026/7/15にメンテナンスモード、2027/7/15にEoSとなる。Amazon Linux 2やpip経由での意図せざるv1残存パターンを確認し、ECR認証コマンドのecr get-login→ecr get-login-passwordへの書き換え手順を実演。

詳細

v1が意図せず残る典型パターン：

• Amazon Linux 2ではyum経由でv1がプリインストール
• pip install awscliでPyPI最新版（1.44.x = v1）がインストールされる
• 古いCI/CDイメージにv1が含まれている

確認コマンド：aws --version、type -a aws、python3 -m pip list | grep -i awscli

AL2023での特記事項：AL2023ではシステムのsite-packagesにv2が入っており、pip install awscliしてもv2が優先されv1は混入しない。ただしAL2023以外（Ubuntu・macOS・一般CI）では要注意。

ECR認証の書き換え：

# v1（削除された）
aws ecr get-login --no-include-email
# v2（推奨）
aws ecr get-login-password --region ap-northeast-1 | \
  docker login --username AWS --password-stdin <account>.dkr.ecr.ap-northeast-1.amazonaws.com

v2方式はパスワードがシェル履歴に残らないためセキュリティ上の改善でもある。

AL2自体が2026/6/30にEoLとなるため、CLI移行とOS更新をセットで検討する必要あり。

移行支援ツール：upgrade debug mode（15/16件検出）とMigration Tool（7/16件自動修正）の併用が効果的。

AWS Network FirewallでTLSインスペクションを有効化せずRoute 53 DNS Firewallと組み合わせてSNIスプーフィングを緩和しようとしてみた

• URL: https://dev.classmethod.jp/articles/aws-network-firewall-sni-spoofing-mitigation-without-tls-inspection/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: TLSインスペクション無しでNetwork FirewallのSNIスプーフィング脆弱性を緩和する構成を検証。Route 53 DNS FirewallとNetwork Firewallステートフルルールを組み合わせることで特定パターンは防御できるが、「許可済みドメインを詐称したSNI偽装」は防げないという正直な結論。

詳細

前提の課題：TLSインスペクションはランニングコストが固定料金で約2.7倍増加し、CA証明書の配布管理負担も重い。Network Firewall Proxyは2026/6/11時点でGA前。

緩和構成の2要素：

1. Route 53 DNS Firewall: 名前解決できるドメインをAllowリストで制限（悪意ある接続先IPの取得を阻止）
2. Network Firewallステートフルルール: セルフマネージドDNS以外への名前解決を遮断（外部DNS経由の迂回を防止）+ 許可ドメインのSNI/Hostヘッダーのみ通過

防げるパターン: 許可外ドメインへのアクセス、許可外ドメインを使ったSNI詐称、IPアドレス直接指定

防げないパターン: IPアドレス直接指定 + 許可済みドメインを詐称したSNI/Hostヘッダー（SNIは自己申告値のためTLSインスペクション無しでは原理的に不可能）

運用上のネック: Network FirewallとDNS Firewallで許可ドメインを二重管理が必要。完全な対策にはNetwork Firewall ProxyかSquidなどのHTTP Proxyが必要。

AWSのセキュリティ系サービスを「何をしたいか」で整理してみた

• URL: https://dev.classmethod.jp/articles/medoruma-aws-security-services-by-usecase/
• 日付: 2026-06-12
• Tier: Tier 2
• 要旨: クラスメソッドオペレーションズの著者がAWSセキュリティサービスをサービス種別ではなく「何をしたいか」というユースケース軸で分類・整理。5つのユースケース（侵入防止・データ保護・脅威検知・脅威調査・権限見直し）にマッピングした早見表を提供。

詳細

5カテゴリによる整理：

IAM Access AnalyzerとAccess Advisorの役割の違い（外部公開の分析 vs アクセス履歴の確認）など、混同しやすいサービスの差別化が明確に示されている。

BedrockのOpenAIモデル（GPT-5.5 / GPT-5.4）がus-east-1で利用可能になったので試してみた

• URL: https://dev.classmethod.jp/articles/bedrock-openai-gpt55-virginia-responses-streaming/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Amazon BedrockのGPT-5.5/GPT-5.4がus-east-1（バージニア北部）に対応。日本企業がSCPでオハイオを制限している場合でもBedrockのOpenAIモデルが使えるようになった。Responses APIのストリーミング動作とTTFTも実測。

詳細

リージョン拡大の意義： 日本向けワークロードでは「東京・大阪・バージニアのみ許可」のSCPが多く、オハイオのみ対応だったGPT-5.5/5.4はSCP制約下では使えなかった。us-east-1対応でこの問題が解消。

実測値（reasoning.effort=“low"使用）：

重要な制約：

• Chat Completions API（/v1/chat/completions）は非対応。Responses APIのみ
• 総レイテンシは22〜34秒と長いが、TTFTは1秒前後と速く、ストリーミング提示としては許容範囲

ストリーミングイベント順序：response.created → response.in_progress → response.output_text.delta（N回）→ response.completed

Clean Architecture・SOLID・DIPを改めて整理してみた — AI駆動開発の時代にまだ使えるのか？

• URL: https://dev.classmethod.jp/articles/clean-architecture-solid-dip-repository-ai-driven-development/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Claude Codeのコードレビューでレイヤー違反を指摘されたことをきっかけに、Clean Architecture・SOLID・DIPとRepositoryパターンをAI駆動開発時代の文脈で再整理。AIはレイヤー構造を「知ってはいるが守るとは限らない」という実体験に基づく考察。

詳細

核心となる観察：

• Claude CodeはUse CaseにlocalStorage操作を直書きするなど、レイヤー違反を平気で行う
• 「コードを書く」だけでなく「どのレイヤーに書くか」は人間のレビューが担保する必要がある

AI時代に変わる点：

• ボイラープレート（インターフェース定義等）のコストをAIが吸収するため、DIPを「重い」と感じにくくなった
• AIはファイル横断の変更も得意なため、厳密なレイヤー分離がなくても壊滅的にはならない

変わらない点：

• 読みやすく予測可能なコード、小さなファイル、良い命名はAIの精度に直結する
• UserRepository.findByIdはdb.query("SELECT...")より遥かにAIが扱いやすい

load vs list の命名によるレイヤー診断：Use Caseにloadが出たら「ストレージの詳細が漏れているサイン」という実用的な見極め方を提示。

AWS主催フットサル大会の大会管理アプリをサーバーレス構成で作って本番運用してみた！

• URL: https://dev.classmethod.jp/articles/kick-summit-app/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: フットサル大会専用Webアプリ「Kick Summit App」をClaude Codeでほぼ全コードを生成し、AWS Lambda + DynamoDB + CloudFrontのサーバーレス構成で本番運用。当日1日のAWS利用料は約0.2ドル（30円）で完結した事例報告。

詳細

技術スタック：Next.js 16 (App Router) + TypeScript + Tailwind v4 + shadcn/ui + DynamoDB (マルチテーブル + Composite Key GSI) + Lambda (Docker/ARM64 + Lambda Web Adapter) + API Gateway (HTTP API) + CloudFront

Claude Codeとの役割分担：

• 人間：技術スタック選定・アーキテクチャ設計・ディレクトリ構成・DBスキーマ設計・CLAUDE.mdへの方針記載
• Claude Code：設計方針に沿った実装・テスト・リファクタ

設計の核心：

• Server Actions のみで書き込みを集約（REST APIなし）
• DynamoDB マルチテーブル + GSI で「1クエリで画面が取れる」設計
• Lambda Web Adapter でNext.jsをそのままLambdaで動かす（SSR対応）

本番運用の結果：

• コールドスタートはARM64/1024MBで体感1〜2秒
• 試合中のリアルタイム更新は30秒ポーリング（WebSocketなし）
• 週末1〜2回のDIY開発（1人で書けば3〜4回かかる規模）で完成
• コード9割以上はClaude Codeが生成

知見：「設計は人間、実装はClaude Code」の分担で設計の意図をブレさせずに実装速度を底上げできる。放置（丸投げ）すると無難だが面白みのない構成になる。

Lambda でレスポンスストリーミングをする

• URL: https://dev.classmethod.jp/articles/lambda-response-streaming/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Lambda AIバックエンドにおけるTTFB改善のため、レスポンスストリーミング3方式（InvokeWithResponseStream・API Gateway・Function URLs）の実装方法と違いをCDK v2コードサンプルつきで解説。

詳細

3方式の比較：

ハマりポイント：

• Function URLsはHTTP/2非対応（HTTP/1.1 + Transfer-Encoding: chunked）
• API GatewayはHTTP/2対応（クライアントがHTTP/1.xなら自動フォールバック）
• Function URLsではContent-Typeヘッダが不正だとisBase64Encodedの判定が狂う

CDK設定の要点：

• API Gateway: responseTransferMode: apigateway.ResponseTransferMode.STREAM + proxy: true
• Function URLs: invokeMode: lambda.InvokeMode.RESPONSE_STREAM
• curl確認には-N（--no-buffer）オプション必須

RAGが正しい証拠を持っていても誤答するSAEGを回避する方法をAWS Bedrockで試してみた

• URL: https://dev.classmethod.jp/articles/why-rag-fails-aws-verification/
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: RAGが正しい証拠を持っていても誤答するSAEG（Superficial Answer from Evidence Grounding）問題を、AWS BedrockのAPIで「split call」（2段階呼び出し）で緩和する実験。2WikiMultiHopQAで+14.0pp、MuSiQueで+12.0ppの正答率改善を確認。

詳細

SAEGとは：質問を深く処理する前に証拠の表層パターンに飛びつく失敗パターン。論文（arxiv 2605.14192）ではCircuit Tracingで帰属グラフとして可視化。

split callの設計：

• Call 1（証拠なし）：質問だけ渡し、正答に必要な条件を先に列挙させる
• Call 2（条件リスト＋文書）：Call 1の条件を参照しながら証拠から回答させる

実験結果（Meta Llama 3.1 8B, Bedrock, 50問サンプル）：

entity-bridging型（中間エンティティを経由する多段推論）で改善が顕著。comparison型（AとBを比較する問い）では逆効果になるケースあり。「理由に基づいた改善」を実測で示した点が価値。

Hyper-Vの動的メモリ、私のベストプラクティス｜セミナーフォローアップ

• URL: https://www.say-tech.co.jp/contents/blog/yamanxworld/2026memo065
• 日付: 2026-06-12
• Tier: Tier 2
• 要旨: セイテク・シス管道場 第7回のフォローアップとして、山内和朗氏がHyper-V動的メモリの「ベストプラクティスは固定割り当て」という持論を解説。SQL ServerなどのサーバーワークロードとHyper-V動的メモリの相性問題、現代のWindowsメモリ管理との設計哲学的ミスマッチを指摘。

詳細

著者は「VMに動的メモリを使用せず、最適なサイズを固定（静的）で割り当てること」をベストプラクティスと主張する。主な理由は以下の通り。

• SQL Serverは独自の動的メモリ管理機能を持ち、Hyper-V動的メモリと干渉しCPU負荷・パフォーマンス低下を引き起こす
• 現代のWindowsはキャッシュ活用のためにメモリを積極的に使う設計だが、動的メモリの「回収」とこの設計思想が衝突する
• メモリリークのバグを動的メモリが隠蔽してしまうリスクがある
• メモリが安価になった現在、VDI以外で動的メモリのメリットは薄れている

動的メモリが有効なケース：高集約仮想環境、リソースが限られた検証環境。著者自身は固定割り当て一択で運用。

Claude Fable 5 を API 視点で読み解く — Opus 4.8 から何が変わったのか

• URL: https://zenn.dev/aiden_ai/articles/00fd9f3839b548
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Claude Fable 5（claude-fable-5）のAPI利用に特化した破壊的変更まとめ。思考常時ON・protected thinking・新トークナイザ（約30%増）・refusal stop_reason・30日データ保持必須の5点を具体的なコードと移行チェックリストで解説。

詳細

なぜ1日触っても違いが分からないか：Fable 5の優位は「難しく・長時間・自律的なタスク」に集中しており、短いスコープ明確なタスクではOpus 4.8と体感差が出にくい（SWE-bench Pro: 80.3% vs 69.2%）。

5つの破壊的変更：

1. thinking常時ON: {"type":"disabled"}は400エラー。深さはoutput_config={"effort":"high"}で制御（low/medium/high/xhigh/max）
2. protected thinking: 生の思考連鎖は返らない。display:"summarized"で要約を表示可能
3. 新トークナイザ: 同一内容でOpus系より約30%多くトークン化。count_tokensでinput_tokens_prior_tokenizerとの差分を事前計測推奨
4. refusal stop_reason: 安全分類器が発動するとHTTP 200でstop_reason:"refusal"が返る。content[0]を無条件で読むコードが壊れる。サーバーサイドfallbacks（betaヘッダ）でOpus 4.8への自動切り替えが可能
5. 30日データ保持必須: ZDR（ゼロデータ保持）不可。ZDR設定の組織は全リクエストが400になる

差を引き出す条件：最初の1ターンにタスク全体を渡してhigh/xhigh effortで回す。1リクエスト数分〜15分を想定してストリーミング必須設計に。過剰スキャフォルディングは品質を下げる。

Claude Code / Codex時代の開発フロー──Plan、Work、Review、CompoundでAIを工程に入れる

• URL: https://zenn.dev/aiwatch_jp/articles/agent-flow-plan-work-review-compound
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: AIエージェントを「コードを書いてくれる人」ではなく「開発工程全体を再設計する要素」として捉え、Plan・Work・Review・Compoundの4工程フレームワークを提唱。「工程が弱いと失敗も速く広がる、工程が強いと速さが武器になる」という開発論。

詳細

4工程フレームワーク：

1. Plan（作らせる前に仕事を設計する）：仕様・変更範囲・テスト観点・失敗時の戻し方を人間が先に確定。AIに「いい感じに全部やって」は事故の元
2. Work（小さく作らせ実行結果を見ながら進める）：大きな変更を小さく分割。実行結果を確認しながら逐次進める
3. Review（人間と別の仕組みで検品する）：evals・sandbox・AGENTS.md/CLAUDE.mdを活用した機械的品質ゲート。人間の毎回レビューを構造で代替する
4. Compound（一度の学びを次の仕事が楽になる形で残す）：毎回同じ失敗（テスト忘れ・命名規則外れ等）を繰り返すのを防ぐために、学習を CLAUDE.md/evals に積み上げる

核心メッセージ：「Compound」が最後にあることが重要。失敗パターンをルール化し蓄積しないと、人間のレビュー負荷だけが増えてAIの速さが活かせない。「AIを使う」＝「仕事全体の流れを組み直す」。

Claudeに自分専用の秘書を育てさせる — GitHub × Claude Code で AI の長期記憶を作る

• URL: https://zenn.dev/hobomokha/articles/9381d939aef2bd
• 日付: 2026-06-11
• Tier: Tier 3
• 要旨: GitHub private リポジトリをAIの長期記憶置き場として、Claude CodeのCLAUDE.md自動ロード機能を活用してセッション横断の「自分専用秘書」を構築するハンズオン記事。非エンジニア向けにStep 0から丁寧に説明。

詳細

仕組みの核心：

あなた ←→ Claude Code ←→ GitHub private repo
├── CLAUDE.md（Claudeへの指示書：自動ロード）
├── master_profile.md（自己理解・価値観）
└── domains/（テーマ別ログ）

なぜClaude Codeか（Codexとの差別化）： CLAUDE.mdをリポジトリルートに置くだけでセッション開始時に自動読み込みされる点が核心。Codexはコード生成特化で「自分のことを話して育てる」体験の質が異なる。

実装手順：

1. GitHub private リポジトリを作成
2. Claude Code ↔ GitHub コネクタ連携
3. 「秘書リポジトリを設計して」と頼んでファイル構造を自動生成させる
4. 一問一答でmaster_profile.mdに自己情報を蓄積
5. 別セッションで同じ質問をして「記憶あり」体験を確認

CLAUDE.mdのルール設計例：

• 推測を事実として書かない
• 流動的な情報には [FLOW] タグをつける
• master_profile.mdは明示的依頼なく直接編集しない

発展利用：domains/配下にテーマ別ログ（finance.md, reading.md等）を増やす。「今日の相談をまとめて保存して」で会話を自動アーカイブ。テキストファイルなのでChatGPT等他AIへの転用も容易。

Claude Code 最新機能ガイド — PreCompact Hook・Worktree強化・チームオンボーディング

• URL: https://zenn.dev/kai_kou/articles/231-claude-code-precompact-worktree-guide
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Claude Code v2.1.101〜v2.1.107の新機能を公式ドキュメントと照合して解説。PreCompact Hook（自動コンパクトのブロック制御）、EnterWorktreeのpath指定（既存worktreeへの切り替え）、/team-onboarding（オンボーディング文書の自動生成）が主要追加機能。

詳細

PreCompact Hook（v2.1.105）：

• コンテキスト圧縮の直前に発火するhook
• trigger: "auto"（自動）か"manual"（手動/compactコマンド）で識別
• exit code 2またはJSONの"decision":"block"でコンパクトをブロック可能
• 自動コンパクトだけブロックして手動は通す等の制御ができる

EnterWorktreeのpath指定（v2.1.105）：

• 既存worktreeのパスを指定してシームレス切り替え可能に
• 従来は新規作成のみ。並列開発ワークフローが改善

/team-onboarding（v2.1.101）：

• ローカルのClaude Code使用状況を分析してチームのクイックスタートガイドを自動生成
• プロジェクト固有の設定情報・よく使われるワークフローパターン・新規メンバー向け手順を生成

その他の改善：

• ストリーミング自動リカバリー：5分間データなし→非ストリーミングモードに自動リトライ
• /proactiveが/loopのエイリアスとして追加
• OS CA証明書ストアをデフォルト信頼（エンタープライズTLSプロキシ対応）
• コマンドインジェクション脆弱性の修正（v2.1.101）

自分専用のAIニュースキュレーターをCodexで作って約1か月運用してみた

• URL: https://zenn.dev/mkj/articles/966c62588bd8fc
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: 松尾研究所データサイエンスチームマネージャーがCodexでAIニュースキュレーターを自作し約1か月運用。RSS収集→日本語要約→Tinder風スワイプUIでExplicit feedbackを取得し、ソース・タグ重みを更新するパーソナライズエンジンを実装。1か月で配信傾向が個人の関心にシフトした変遷データを公開。

詳細

設計のポイント：

1. 情報源をRSS限定：実装・運用コストを抑えるためウェブクロールを避ける
2. Explicit feedback優先：クリック（暗黙的シグナル）だけでなく「役に立った/不要」の明示的フィードバックをTinder風UIで取得
3. 探索枠（12本中2本）：上位スコアだけだと偏るため、普段の傾向から外れる記事を定期的に差し込む
4. ソース分散制約：arXivはcs.AIとcs.LG各最大1本に制限し1ソース偏りを防ぐ

重みの設定**：clicked: +1.0 / 役に立った: +0.65 / 不要: -1.1

1か月の変遷（初期5日 vs 直近5日）：

• OpenAI Blog: 11% → 22%（+11pt）
• TechCrunch AI: 27% → 18%（-9pt）
• AI/Agentsタグ: 高 → 低（粒度が広すぎた）
• Models/Businessタグ: 上昇傾向

開発プロセス：Codexと対話しながらVibe coding。要件4点から1日で初版、1か月で使いながら違和感を潰す反復開発。「自分用ツールは初版を作って使いながら育てる方が完成形を先に設計するより向いている」。

SKILL.md の description を書き間違えると、スキルは永遠に呼ばれない

• URL: https://zenn.dev/playpark/articles/skill-md-guide
• 日付: 2026-06-11
• Tier: Tier 3
• 要旨: Claude Code Skillsでスキルが呼ばれない原因のほとんどがdescriptionフィールドの書き方にあることを自身の失敗事例から解説。descriptionは「機能説明」ではなく「ユーザーがどう頼むかの自然文」として書くべきという実践知。

詳細

descriptionの役割：Claude Codeはセッション起動時に全SKILL.mdのdescriptionだけをメモリに読み込み、ユーザー発話と意味的に近いものを選ぶ。つまりdescriptionは「検索クエリ」として機能する。

失敗例と成功例：

# Bad（機能説明のみ）
description: 'Improve SEO of blog articles'

# Good（ユーザー発話が自然文で入っている）
description: 'GSC/GAデータに基づいてtitle/description/冒頭セクションを改善する。ユーザーが「SEO改善」「CTR改善」と依頼したとき'

description3点チェックリスト：

1. 動詞で始める（抽出して、分析する）
2. 対象オブジェクトを明示する
3. ユーザーがどう頼むかを自然文で書く（「〜と言ったとき」）

競合対策：否定条件を書き添える（「2記事の交換には使わない」等）が有効。競合が顕在化してから追記するでよい。

アンチパターン：Claudeが「メモリに保存しておきました」と返したら対症療法。スキル本体のdescriptionを修正するのが根本解決。メモリに救済ルールが溜まるのはスキル設計のバグが蓄積しているサイン。

Claude Code エージェントチーム入門 — subagentとの違いから仕組み・セッティング方法・コマンド化まで

• URL: https://zenn.dev/tatsuqumo/articles/fa0343547eb257
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Claude Code Agent Teamsの詳細解説。subagentとの決定的な違い（teammate同士が直接通信できる）を実機検証で明示。レビュアーが議論を通じて自説を撤回して相手案を採用するという「立場転向」現象を記録。コスト実測はレビュー1回約$10。

詳細

subagent vs agent team の核心差：

• subagent：結果を返して終わり、teammate同士の通信なし
• agent team：共有タスクリストとmailboxでteammate同士が直接メッセージを送り合う

アーキテクチャ：

• ~/.claude/tasks/{team-name}/: タスクJSON（pending/in_progress/completed + blockedBy/blocks で依存関係）
• タスクはファイルロックで競合を防止
• config.jsonは実行時に生成されるため手動編集不可

立場転向の実例：

• ロードマップの「スコア式の是非」でリスク担当とdevil’s advocate担当が対立
• 1往復の議論後、リスク担当が「devil’s advocateの指摘は本質的に正しい」と自説の弱点を認め、相手案を支持する方向に転換
• subagentでは独立した結果を返すだけなので、この種の協調的な意見更新は起きない

コスト実測（teammate 4名 Sonnet + リーダー Opus系）：

• teammate: 約$5.5（大半はキャッシュ読み書き）
• リーダー: 約$4.5
• 合計 ≒ $10 / レビュー1回（単一セッションの約3倍）

Skills化（/review コマンド）：disable-model-invocation: trueでClaude自動起動を防ぎ、人間が明示的に呼ぶ設計。allowed-toolsに事前承認ツールを指定して都度確認を削減。

Claude CodeでOSS更新を監視し、自社実装と照合して、NotionにR&Dチケットを自動起票するAIエージェント

• URL: https://zenn.dev/team_nishika/articles/ce4bedfa021726
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: NishikaCTOが構築した、毎週土曜朝に無人で動くOSS監視→自社実装照合→Notion起票パイプライン。Claude CodeのroutineとNotion MCPのみで追加インフラゼロ。起票されるチケットには根拠PR・ファイル行番号・期待効果が構造化されており、そのまま検証着手できる粒度。

詳細

3層パイプライン構成（Whisper系の例）：

設計の核心5点：

1. Notionページを「エージェント間の共有メモリ」に使い、中間成果物を人間にも読める状態に
2. Profile refreshで「自社コンテキストを月次で自動更新」→エージェントに読ませるドキュメントをエージェントが整備する再帰構造
3. 監視と起票を分離（関心の分離 = 品質向上）
4. 起票品質のガードレール：DBスキーマを毎回読む・重複チェック・書き込み範囲を「目的セクションのみ」に制限・「ゼロ起票を許可」するプロンプト文が想像以上に効く
5. 人間に残すのは「優先度判定と着手判断」のみ

クラウド実行ならではのハマり：

• GitHub API rate limit → sourcesでcloneしてlocal gitで読む設計に変更
• HuggingFace APIがデータセンターIPを403で弾く → トークン確認 + スキップ時は申告させる

コスト：インフラゼロ。メンテはプロンプト調整のみ。

Claude Codeの記事が薄くなる理由——AIエージェントに設計議論が届いていなかった

• URL: https://zenn.dev/tottoko_hamu/articles/2026-06-02-120000
• 日付: 2026-06-11
• Tier: Tier 3
• 要旨: Writerエージェントが書く記事が「正確だが生きていない」問題の根本原因を特定した実録。問題は書き方ではなく「設計議論の生発言がWriterの参照範囲にない」構造的欠陥にあり、対話アーカイブシステム（knowledge/dialogue/）を実装することで解決した。

詳細

問題の構造：

• Writerエージェントが参照できるのはcontent/writing/netacho/（ネタ帳）のみ
• 設計議論・判断の迷い・「なぜこの選択か」の根拠はネタ帳に転写されない限り消える
• セッションが終わると対話ログは失われる

3案比較と選択：

1. 入口で拾う案（運用ルール強化）
2. 物理保存案（対話をgrepできるデータベース）← 採用
3. 執筆時参照案（プロンプト強化）

選択理由：「私が保存してといったときだけでいい」という制約が自動化の過剰複雑化を防いだ。

実装内容（5ファイルのみ、スクリプトなし）：

• knowledge/dialogue/README.md（ディレクトリ説明）
• ops/playbooks/dialogue-archive.md（アーカイブ手順）
• .claude/agents/writer.md（参照Playbook追記）
• .gitignoreに例外追加（/knowledge/* + !/knowledge/dialogue/）

要約せずそのまま写す：要約すると生の言葉が失われる。引用は一字一句の精度が素材価値を決める。

メタ構造：対話アーカイブシステムの設計議論が、そのシステムで保存された最初の記録になった。保存した素材が後の記事で実際に使われ「保存したから引けた」サイクルを実証。

【Fable 5 vs Opus 4.8】同じプロンプトでWebアプリ作らせて比較検証した

• URL: https://zenn.dev/yukurash/articles/16c378dbbb4c95
• 日付: 2026-06-11
• Tier: Tier 2
• 要旨: Fable 5とOpus 4.8に全く同じプロンプトを渡してWebアプリを生成させる実戦比較。「絶対に押してはいけないボタン」と「Windows 95風デスクトップ」の2種目。Fable 5はコード量・質ともに高いが、コストは5〜7倍、かつ納品事故（ファイル未生成）も発生した。

詳細

対決1：絶対に押してはいけないボタン（自由課題）：

Fable 5は細部のユーモアやユーザー体験が精緻。Opus 4.8は軽量でシンプル。

対決2：Windows 95風デスクトップ（必須14機能あり）：

• Fable 5の1回目は16分・2,327行を生成した後、起動処理ファイル（shell.js）を書き忘れて動作不可（納品事故）
• 再挑戦で3,390行・$10.75。Opus 4.8は2,086行・$3.16
• 「ようこそ」ダイアログや細かなネタはFable 5が優位

総評：「Fable 5の方がアウトプットの質は高そうだけど、2倍の金額払うかと言われたらうーん」という率直な感想。Opus 4.7登場時ほどの衝撃はない。納品事故の実例はモデル評価として重要な記録。