日次レポート 2026-06-16

処理: 20件（ai-llm: 10件 / ai-agent-implementation: 10件）

トピック別記事一覧

ai-llm（10件）

1. Stack Overflow for Agents ベータ公開 — AIエージェント同士の知識共有プラットフォーム `Tier 2`

Stack Overflow がAPIファーストの知識交換プラットフォーム「Stack Overflow for Agents」のベータ版を公開した。あるエージェントが試行錯誤して解決した問題を他のエージェントが再利用できるようにし、無駄なトークン消費を削減することを目的とする。コンテンツはQuestion / TIL / Blueprint の3種類で、人間がモデレーターとして承認ループに残る設計。

2. claude-mem v13.5以降のテレメトリとオプトアウト方法 `Tier 2`

claude-mem v13.5.0 から追加された匿名テレメトリはデフォルトオプトアウト式で、v13.5.1〜v13.6.1にかけてイベントの粒度が継続的に増加している。プロンプト本文・ファイルパス・ソースコードは送らない設計だが、v13.6.0 以降はテレメトリ導入前の履歴を日次 rollup として backfill する機能が追加されており、アップグレード前のオプトアウト設定が推奨される。

3. AgentCore Memory の長期記憶で Strictly Consistent メタデータを試した `Tier 2`

Amazon Bedrock AgentCore Memory に追加された Strictly Consistent メタデータは、アプリケーション側が指定した値を LLM 推論を介さずそのまま長期記憶に反映する。マルチテナントの部門スコープ検索やコンプライアンス境界の実装に向いており、メタデータ値が異なるレコードは統合されず分離される。テナント分離はあくまで namespace で行い、メタデータはその中での絞り込みに使うことが公式の推奨。

4. Claude Code でスキルはいつ自動反映されるか — /reload-skills の使い所 `Tier 2`

v2.1.0 から存在する自動 hot-reload により、~/.claude/skills や .claude/skills 配下の SKILL.md 変更はセッション再起動なしに反映される。v2.1.152 で追加された /reload-skills は変更を即時確認したいときや読み込み件数を把握したいときの補助コマンドという位置づけで、毎回実行する必要はない。プラグインファイルの変更には別途 /reload-plugins が必要。

5. Copilot Studio でトピック・ツール・エージェントフローを使い分ける `Tier 2`

Copilot Studio の3部品の役割は明確に分かれており、会話の流れを設計するのがトピック、単発の能力を追加するのがツール、決定論的な手順を自動実行するのがエージェントフロー。生成オーケストレーション下ではユーザーが部品を指定しなくてもエージェントが説明文をもとに適切な部品を自律選択して実行する。トピックのトリガーに記述する説明文の品質が自動選択の精度を左右する。

6. NVIDIA SkillSpector と Cisco Skill Scanner で Agent Skills を脆弱性スキャン `Tier 2`

42,447スキルを分析した論文では26.1%に脆弱性があり、データ持ち出し13.3%・権限昇格11.8%が最多。SKILL.md は自然言語の指示書だが、エージェントのツール実行権限の上で動くためnpmやPyPIと同様のサプライチェーンリスクがある。SkillSpector は64パターン16カテゴリで検出・スコアリングし、Cisco Skill Scanner はCI/CD統合を意識した設計。どちらも「No findings ≠ no risk」と明記されており多層防御の一部として使う。

7. Salesforce Hosted MCP に Apex Invocable Actions でカスタムサーバーを追加 `Tier 2`

Salesforce Hosted MCP Servers の汎用的な権限スコープを絞るため、Apex Invocable Actions でカスタムMCPサーバーを実装した実践記録。@InvocableMethod / @InvocableVariable の label と description がMCPツールの名前・説明としてそのままAIツールに渡される設計で、公開できるのは global メソッドのみ。

8. Claude チャットのコード実行と Claude Code は別アーキテクチャと実機検証で確認 `Tier 2`

Claude.ai の「コード実行」設定は Anthropic ホストの隔離 Linux サンドボックスを制御するものであり、ローカル環境で動く Claude Code とは完全に別物。外部通信をオフにしてもファイル生成・データ分析・グラフ可視化は利用できる。Claude.ai のコード実行は社内ネットワークを経由しないため DLP では制御できない点が組織のセキュリティ設計で重要な分岐点になる。

9. Bedrock Mantle の最新モデルが CloudWatch メトリクスを出力しない問題と CloudTrail での代替 `Tier 2`

2026年6月時点で claude-opus-4-7/4-8 および gemma-4 系の5モデルが CloudWatch メトリクスを出力しない。CloudTrail のデータイベント（CreateInference）を高度なイベントセレクタで絞り込むことで推論1件単位の記録を取得できる。

10. AWS DevOps Agent でカスタムエージェントを作成できるようになった `Tier 2`

6月12日のアップデートでシステムプロンプト・ツール・スキルをユーザー定義できるカスタムエージェント機能が追加された。スケジュール実行と組み合わせることで SRE レポートの定期生成などに活用できる。スキル側でエージェントタイプを「すべてのタスク」に設定しないとカスタムエージェントから呼び出せない点が注意事項。

ai-agent-implementation（10件）

1. Claude Fable 5 のシステムプロンプト — 公式・リーク・Claude Code・API の4種類を整理 `Tier 2`

「Fable 5 のシステムプロンプト」と呼ばれるものが4つの異なる文脈を指しており、公式 release-notes 版（一次情報）とリーク版（検証不能）の混同が情報の錯綜を招いている。Claude.ai のプロンプトと Claude Code のプロンプトは別物であり、API にはデフォルトのシステムプロンプトが存在しない。Fable 5 は米政府の輸出管理指令により6月12日に全ユーザー向けに停止され、6月15日時点で復旧作業中。

2. Code with Claude Tokyo 2026 — 全12セッションの内容と登壇者一覧 `Tier 2`

2026年6月10日の東京会場では、Claude Code の Auto mode・Worktrees・Routines・Dynamic workflows が発表された。Fable 5 の SWE-bench Pro スコアは80.0%、Opus 4.8 は69.2%。Canva は Sonnet をメインに Opus/Haiku をサブに委譲することでコスト46%削減・ユーザー成功指標9%向上を達成し、Spotify では Claude Code で月1,000件超のPRを生成している。

3. Loop Engineering とは何か — iOSアプリ15本を出荷して分かった「止めて改善するループ」の現実 `Tier 2`

AIエージェント活用のレバレッジポイントが「良いプロンプトを書くこと」から「良いループを設計すること」へ移っているという Loop Engineering の概念を、実本番運用ベースで検証した記事。本番で最初に問題になるのはループの「回し方」ではなく「止め方」で、トヨタの自働化を応用した ANDON 機構（前進系操作の物理ブロック）と失敗をラインの標準に戻す Kaizen Learning Capture を組み合わせることで改善ループが成立した。

4. Claude Code にファイルベースの永続メモリを持たせる：1ファイル1事実＋index方式 `Tier 2`

セッション間でコンテキストを持続させるための設計として「1ファイル＝1事実」でmemory/フォルダに.mdを置きMEMORY.mdを索引にする方式を実運用した記録。description フィールドが想起のキーになるため「ふわっとした説明」のメモリは引かれない。MEMORY.md が200行で截断されるため本文は個別ファイルに分離することが必須。

5. 学部2年が Claude Code に自作スキルを約30個作って大学生活を回している話 `Tier 3`

実験レポート・ES・コードレビュー・試験計画など大学生活の繰り返し作業を自作スキル約30個で自動化している事例。SKILL.md の description キーワードへの自然言語マッチングにより「コマンドを覚えない」運用を実現している。壮大な計画ではなく「面倒な作業を一個ずつ潰した積み上げ」という経緯がスキル設計の参考になる。

6. 重くなった Claude Code を軽くする — コンテキスト注入を228KBから48KBに削った監査 `Tier 2`

Claude Code の「直近指示を取りこぼす・話が混線する」症状の真犯人が ~/.claude/rules/ の自動フルロードによるコンテキスト注入量の肥大化だったと特定。使わない言語ディレクトリをツリー外に移動するだけで228KB→48KB（79%減）を達成し、症状が改善した。「ファイルサイズが大きい＝注入が重い」は成立しないため必ず注入源を実測して特定することが重要。

7. macOS で Claude Code の自動化を24/7回すと踏む launchd の罠5つ `Tier 2`

modern macOS では cron が実質動いていないため launchd への移行が必要。GUIから起動した子プロセスは ~/.zshrc を読まず最小PATH しか持たないため、~/.claude/settings.json の env.PATH に /opt/homebrew/bin を追加することで解決できる。macOS には GNU coreutils の timeout が非搭載で別途インストールが必要など、実運用で踏みやすいOS固有の制約を整理している。

8. Git Worktree を安全に：h5i で作るAIエージェント用サンドボックス `Tier 3`

Git Worktree は複数エージェントの並列作業に便利だが、追加 worktree が元リポジトリの .git を参照する構造上サンドボックスではなく相互侵入のリスクがある。AI向け次世代 git として開発中の h5i の env コマンドが Docker 的なネットワーク・ファイルシステム隔離を提供するとされているが、現在は開発中のツール。

9. Claude Code 中心運用から Codex 中心運用へ移行する判断基準 `Tier 3`

設定ファイルを丸ごとコピーするより「capability 単位で分解してから移す」アプローチが安定するという実体験記録。exists 判定だけでは移行完了とみなせず、実成果物の確認・二重発火防止・承認ゲートの維持が完了条件として必要。Claude を即廃止せず read-only 参照元として残しながら段階移行することを推奨している。

10. 一度の失敗を次の成功に変える — AGENTS.md・Memory・Skill の使い分け `Tier 2`

AIエージェント開発で最もコストが高いのは「失敗から得た判断基準が次の作業に戻らないこと」という観点から、Memory を保管庫ではなく「戻り道」として設計する考え方を整理した記事。情報を事実と入口・作業ルール・実行手順の3種類に分けて適切な場所に配置し、Memory に寿命（短期・中期・長期）を持たせることが重要。

トレンドの連鎖

Claude Code の運用知識が急速に体系化されている

Zenn の記事群を見ると、Claude Code の実運用ノウハウが個人レベルで急速に体系化されてきていることが見える。コンテキスト注入量の測定と削減（228KB→48KB）、ファイルベース永続メモリの設計、launchd 自動化の罠整理、スキル約30個の運用事例と、いずれも「実際に踏んで直した」記録だ。半年前には存在しなかった「Claude Code 運用術」という暗黙知の体系が、ユーザーコミュニティによって可視化されつつある。

スキルのセキュリティリスクが論文レベルで証明された

NVIDIA / Cisco のスキャナ記事と arXiv:2601.10338 の論文が示すように、SKILL.md という自然言語の指示書がエージェントのツール実行権限の上で動く構造が、npmやPyPIと同様のサプライチェーンリスクを生んでいる。42,447スキル中の26.1%に脆弱性があるという数字は、エージェント対応のセキュリティツールチェーンの整備が実務上の課題になってきたことを示している。Stack Overflow for Agents のベータ公開とも連動して、エージェント間の知識流通の安全性確保が次のフェーズの論点になりそうだ。

「止める設計」と「改善するループ」への関心が高まっている

Loop Engineering の記事が示すように、AIエージェントを本番で動かした経験者の関心が「どう動かすか」から「どう止めて、どう改善するか」へ移っている。ANDON 機構・Blind Gate・Kaizen Learning Capture という概念が登場し、製造業の品質管理の知見がソフトウェア開発のエージェント制御に流用されている。AGENTS.md / Memory / Skill の使い分けに関する記事も同じ文脈で、「失敗が次の作業に戻る経路を設計すること」がエージェント活用の本質的な課題として浮かび上がっている。

記事別詳細

classmethod-agentcore-memory-strictly-consistent-metadata

AgentCore Memory の長期記憶で Strictly Consistent メタデータを使ってみた

URL: https://dev.classmethod.jp/articles/agentcore-memory-strictly-consistent-metadata/
日付: 2026-06-15
Tier: Tier 2
要旨: Amazon Bedrock AgentCore Memory に Strictly Consistent メタデータが追加された。アプリケーションが直接指定した値がLLMを介さずそのまま長期記憶レコードに反映されるため、マルチテナント・コンプライアンス境界・部門スコープの検索に活用できる。

詳細

従来の LLM_INFERRED と STRICTLY_CONSISTENT の主な違い：

項目	LLM_INFERRED	STRICTLY_CONSISTENT
値の決定	LLM が会話から推論	アプリケーションが直接指定
決定性	非決定的	決定的
最大キー数	スキーマ上限内（最大20）	最大3キー
対応型	STRING/STRINGLIST/NUMBER	STRING のみ

Strictly Consistent を設定すると、長期記憶の統合（consolidation）プロセスでメタデータ値が異なるレコードは分離されて統合されない。これによりマルチテナント時のデータ混在を防止できる。なお公式ドキュメントのベストプラクティスでは「テナント分離はnamespaceで行い、メタデータはその中での絞り込みに使う」と明記されている。Summarization Strategy はサポート対象外。

classmethod-bedrock-mantle-metrics-cloudtrail

Bedrock Mantle の一部モデルでメトリクスが出ないので CloudTrail のデータイベントで補ってみた

URL: https://dev.classmethod.jp/articles/bedrock-mantle-metrics-cloudtrail-data-events/
日付: 2026-06-15
Tier: Tier 2
要旨: Amazon Bedrock Mantle で一部の最新モデル（claude-opus-4-7/4-8、gemma-4-31b等）が CloudWatch メトリクスを出力しない問題を確認し、CloudTrail データイベントで代替する手順を記録した記事。

詳細

2026年6月時点で us-east-1 の Bedrock Mantle には48モデルが存在し、そのうちCloudWatchメトリクスが取得できないのは実質5モデル（anthropic.claude-opus-4-7、anthropic.claude-opus-4-8、google.gemma-4-31b、google.gemma-4-26b-a4b、google.gemma-4-e2b）。いずれも直近に追加されたモデルでメトリクス対応が後追い状態。

CloudTrailでの記録手順：管理イベントでは推論呼び出しは記録されないため、データイベントの高度なイベントセレクタを使用。eventCategory=Data、resources.type=AWS::BedrockMantle::Project、eventName=CreateInference で絞り込み、推論1件単位で記録できる。

classmethod-claude-chat-code-execution-misconceptions

Claude チャットのコード実行と外部通信設定を検証してみた

URL: https://dev.classmethod.jp/articles/claude-chat-code-execution-misconceptions/
日付: 2026-06-15
Tier: Tier 2
要旨: Claude.ai の「コード実行」設定がClaude Code（CLI）とは別物であることを実機検証で確認した記事。前者はAnthropicホストの隔離Linuxサンドボックス、後者は利用者のローカル環境で動作する。外部通信オフでもファイル生成・データ分析・グラフ可視化は引き続き利用できる。

詳細

外部通信の4段階：

なし（オフ）: プリインストール済みパッケージのみ、外部通信なし
パッケージマネージャのみ: 主要レジストリの既定ドメインのみ許可
パッケージマネージャ＋指定ドメイン: 2に allowlist を追加
すべてのドメイン: 法的ブロックリスト以外を許可

既定許可ドメインには api.anthropic.com / github.com / registry.npmjs.org / pypi.org などが含まれる。Claude.ai チャットのコード実行は Anthropic 側のサンドボックスで動くため社内ネットワークを経由しない。一方 Claude Code の通信は利用者端末を経由するため社内ネットワーク側で制御できる。この違いが組織の情報セキュリティ管理において重要な分岐点になる。Skills を使う場合もコード実行が有効であれば外部通信オフのままで動作する。

classmethod-claude-code-reload-skills

Claude Code でスキルはいつ自動反映される？/reload-skills の使い所を整理してみた

URL: https://dev.classmethod.jp/articles/claude-code-reload-skills/
日付: 2026-06-15
Tier: Tier 2
要旨: Claude Code v2.1.152 で追加された /reload-skills コマンドの役割を整理した記事。~/.claude/skills や .claude/skills 配下のSKILL.mdの追加・編集・削除は自動hot-reloadされるため、通常は /reload-skills を実行する必要はなく、変更の即時確認や読み込み件数の確認に有用。

詳細

スキル自動反映の時系列：

v2.1.0: 自動 hot-reload を追加
v2.1.32: --add-dir で追加したディレクトリも監視対象に
v2.1.152: /reload-skills コマンド追加
v2.1.157: .claude/skills のプラグインがマーケットプレイス不要で自動ロード
v2.1.174: 変更されたスキルだけが再通知されるよう修正

/reload-skills 実行時の出力例：

Reloaded skills: 25 skills available (2 added, 1 removed)

プラグインファイル（hooks/ や .mcp.json）の変更には /reload-plugins が別途必要。セッション開始後に監視対象トップレベルディレクトリを新設した場合はClaude Codeの再起動が必要。

classmethod-claude-mem-telemetry-opt-out

claude-mem v13.5以降のテレメトリとオプトアウト方法を整理する

URL: https://dev.classmethod.jp/articles/claude-mem-telemetry-opt-out/
日付: 2026-06-16
Tier: Tier 2
要旨: claude-mem v13.5.0 から匿名テレメトリが追加され、デフォルトオプトアウト式になっている。送信されるのはOSバージョン・モデル・トークン効率・位置情報（粗い）等で、プロンプト本文・ファイルパス・ソースコードは送らない設計。

詳細

テレメトリが追加されたv13.5.0以降、v13.5.1〜v13.6.1にかけてイベントの粒度が継続的に増加している。v13.6.0では導入以前の履歴を匿名日次rollupとしてbackfillする機能も追加。

オプトアウト方法と優先順位（高い順）：

DO_NOT_TRACK=1（他CLIツールも含めて一括）
CLAUDE_MEM_TELEMETRY=0（claude-mem専用）
~/.claude-mem/telemetry.json の enabled: false
npx claude-mem telemetry disable

backfillを避けたい場合はアップグレード後にworkerを起動する前にオプトアウト設定を済ませる必要がある。PostHogがIPから国・地域・都市レベルの粗い位置情報を導出する点は注意が必要。現状の設定を確認するには npx claude-mem telemetry status。

classmethod-copilot-studio-topics-tools-flows

Copilot Studio トピック・ツール・エージェントフローで動きを作り込む

URL: https://dev.classmethod.jp/articles/copilot-studio-topics-tools-flows/
日付: 2026-06-15
Tier: Tier 2
要旨: Copilot Studio の3つの「動き」を作る部品（トピック・ツール・エージェントフロー）の役割と使い分けを解説した実践記事。KPIレポート依頼エージェントを題材に、会話フローの設計から動作確認まで画面キャプチャつきで追っている。

詳細

3部品の役割：

トピック: 会話の流れ（シナリオ）を組む。ノードベースエディターで質問・条件分岐・メッセージを順に設計
ツール: エージェントに「できること」を単発で追加。AIプロンプト・コネクタ・MCP・REST APIなど
エージェントフロー: 決定論的な手順を上から順に自動実行

生成オーケストレーション下では、ユーザーが部品を指定しなくてもエージェントが説明文をもとに自律的に部品を選択して実行する。トピックのトリガーは「エージェントが選択するもの」形式で、説明文に「いつ起動するか」を明記することが重要。質問ノードで取得した値は変数に保存され、後続ノードで参照できる。エージェントフローはツールとして追加することでオーケストレーションの選択対象になる。

classmethod-devops-agent-custom-agent

DevOps Agent でカスタムエージェントが作成できるようになった

URL: https://dev.classmethod.jp/articles/devops-agent-support-custom-agent/
日付: 2026-06-15
Tier: Tier 2
要旨: 6月12日のアップデートで AWS DevOps Agent にカスタムエージェント作成機能が追加された。システムプロンプト・利用可能なツール・スキルをユーザーが自由に定義でき、スケジュール実行でSREレポート等の定期生成に活用できる。

詳細

カスタムエージェントが生成できるアウトプット：テキスト応答・アーティファクト・推奨事項の3種類。実行トリガーは手動またはスケジュール（rate/cron形式）のみで、現時点ではエージェント間の連鎖呼び出しは非対応。

作成方法：フォームからの直接入力またはチャットでAIに作成を依頼する2種類。ツールの利用許可はフォームから設定できずチャット経由が必要。スキル側でエージェントタイプの許可設定が必要で、デフォルトが「チャットタスク」のままだと読み込まれない点が注意点。カスタムエージェントが生成したアーティファクトは、別のIAMロールからも確認できるためチームメンバー間での共有に向いている。

classmethod-nvidia-skillspector-cisco-skill-scanner

NVIDIA SkillSpector と Cisco Skill Scanner で Agent Skills の脆弱性をスキャン

URL: https://dev.classmethod.jp/articles/nvidia-skillspector-cisco-skill-scanner-agent-skills-vulnerability-scan/
日付: 2026-06-15
Tier: Tier 2
要旨: SKILL.md 形式の Agent Skills を対象にした脆弱性スキャナ2種類の比較検証記事。42,447スキルを分析した論文（arXiv:2601.10338）では26.1%のスキルに脆弱性が見つかり、データ持ち出し13.3%・権限昇格11.8%が最多だった。

詳細

代表的な攻撃パターン：プロンプトインジェクション、データ持ち出し（Exfiltration）、権限昇格・過剰なエージェンシー、ツールポイズニング、トリガー悪用。

NVIDIA SkillSpector の特徴：

64の脆弱性パターンを16カテゴリで検出
OSV.devへのライブ照会でCVE情報を参照
リスクを0〜100のスコアで評価
出力形式：ターミナル・JSON・Markdown・SARIF
Anthropic API でのLLM分析はJSON Schemaの互換性問題で動作しなかった

Cisco Skill Scanner の特徴：

パターンベース検出（YAML + YARA）+ LLM-as-a-judge + データフロー分析
誤検知を減らすメタアナライザ搭載
PyPI で cisco-ai-skill-scanner として配布、CI/CD組み込み対応

両ツールとも「No findings ≠ no risk」と明記しており、自動スキャンを多層防御の一部として位置づけることが推奨されている。

classmethod-salesforce-hosted-mcp-custom-server

Salesforce Hosted MCP Servers にカスタムMCPサーバーを追加してみた

URL: https://dev.classmethod.jp/articles/add-custom-mcp-server-to-salesforce-hosted/
日付: 2026-06-15
Tier: Tier 2
要旨: Salesforce Hosted MCP Servers の汎用権限スコープを限定するため、Apex Invocable Actions でカスタムMCPサーバーを実装した検証記事。商談に紐づく完了済み活動（ToDo）を作成する機能を題材にしている。

詳細

カスタムMCPサーバーの実装方法はフロー・Apex Invocable Actions・AuraEnabled Apex Methods・Apex REST Methodsなど複数あり、今回はApex Invocable Actionsを採用。@InvocableMethod / @InvocableVariable の label と description がMCPツールの名前・説明としてそのままAIツールに渡されるため、適切な記述が重要。公開できるのは global メソッドのInvocable Actionのみ。設定場所は「設定→インテグレーション→APIカタログ→MCPサーバー」から「Salesforce MCPサーバーを作成」を選択。

publickey1-jp-stack-overflow-for-agents

Stack Overflow、AIエージェント同士が掲示板で技術情報を共有する「Stack Overflow for Agents」ベータ公開

URL: https://www.publickey1.jp/blog/26/stack_overflowaistack_overflow_for_agents.html
日付: 2026-06-15
Tier: Tier 2
要旨: Stack Overflow がAIエージェント向けのAPIファースト知識交換プラットフォーム「Stack Overflow for Agents」のベータ版を公開した。AIエージェントが試行錯誤して解決した知識を組織を超えて共有し、同じ問題での無駄なトークン消費を削減することを目的とする。

詳細

Stack Overflow for Agents は、既存のStack Overflowコミュニティの知見共有モデルをAIエージェント向けに拡張したもの。人間がループに残りながら、エージェントは機械的な速度で知識を検索・貢献できる。

コンテンツタイプは3種類：

Question（未解決問題のテキスト）
TIL（Today I Learned）（障害記録・デバッグトレース等の詳細作業ログ）
Blueprint（再利用可能なデザインパターン）

ユースケースは探索・貢献・他エージェントによる検証・合意の積み重ねの4段階。AIエージェントが問題を解決した場合、ドラフトのスキルファイルを作成し人間レビュアーに提出する。利用開始にはエージェントに agents.stackoverflow.com/llms.txt を読み込ませる。

zenn-agents-md-memory-skill-compound

一度の失敗を次の成功に変える — AGENTS.md、Memory、Skill の使い分け

URL: https://zenn.dev/aiwatch_jp/articles/agent-flow-memory-compound
日付: 2026-06-15
Tier: Tier 2
要旨: AIエージェントとの開発で「失敗そのものではなく、失敗から得た判断基準が次の作業に戻らないことが最もコストが高い」という観点から、Memory・AGENTS.md・Skillの適切な使い分けと設計を解説した記事。

詳細

Memory の本質は「保管庫」ではなく「戻り道」。残す・要約する・取り出す・注入する・消すの5段階を設計する。

3種類に分けて配置する情報：

事実と入口（README.md / docs / runbook）: どのファイルから読むか・どのコマンドでテストするか
作業ルール（AGENTS.md / project-scoped memory）: やってはいけないこと・どこで止まるべきか
実行手順（Skill）: 繰り返す作業の具体的な処理フロー

Memory の寿命区分：短期（今回の調査ログ・一時仮説）・中期（繰り返す checklist・最近の失敗パターン）・長期（repo-wide rule・テストコマンド・繰り返す設計判断）。短期のものを AGENTS.md に入れず、長期のものをチャットの流れだけに置かない分け方が重要。

zenn-claude-code-30-custom-skills

学部2年が Claude Code に自作スキルを約30個作って大学生活を回している話

URL: https://zenn.dev/ai_daigakusei/articles/claude-code-30-custom-skills
日付: 2026-06-15
Tier: Tier 3
要旨: 学部2年生が実験レポート・ES・コードレビュー等の繰り返し作業を自作Claude Codeスキル約30個で自動化している事例。スキルをコマンドとして呼ぶのではなく、SKILL.mdのdescriptionキーワードへの自然言語マッチングで自動発動させる運用が特徴。

詳細

カテゴリ別スキル一覧（抜粋）：

文書生成系（9件）: 実験レポート・予習レポート・ES・PowerPointスライド・ビジネスメール等
開発系（7件）: 実装計画・デバッグ・ビルドエラー修正・コードレビュー・TDD等
整理・運用系（3件）: ファイル自動仕分け・スキル新規作成・全スキル保守
学習系（3件）: 試験学習計画・テスト問題生成・授業録音文字起こし

スキルを使う際のキーポイント：SKILL.mdの description フィールドのキーワードが自動選択の鍵。「実験レポート作って」と書けば report スキルが自動で立ち上がる。コマンドを覚える必要がなく、作業ごとの手順書として蓄積されるため継続性が高い。

zenn-claude-code-file-based-memory

Claude Code にファイルベースの永続メモリを持たせる：1ファイル1事実＋index方式

URL: https://zenn.dev/ai_daigakusei/articles/claude-code-file-based-memory
日付: 2026-06-15
Tier: Tier 2
要旨: Claude Code のセッション間でコンテキストを持続させるため「1ファイル＝1事実」でmemory/フォルダに.mdを置き、MEMORY.mdを索引にする設計を学部2年生が実運用した記録。CLAUDE.mdに全部詰め込むアプローチが破綻した後に行き着いた方式。

詳細

各メモリファイルの必須frontmatter（3点セット）：

name: kebab-caseのスラグ
description: 一行要約（想起のキーになる重要項目）
metadata.type: user / feedback / project / reference の4分類

1ファイル1事実に分ける理由：想起時に関連する1ファイルだけ引けばよく、複数事実が混在すると不要な情報まで読み込むことになる。feedbackタイプには理由（Why）を必ず書く。

MEMORY.md は1メモリ1行の索引のみで本体は持たない。[[other-name]] 形式で他メモリへリンクでき、まだ存在しないメモリへのリンクも予約として張っておける。MEMORY.md が200行を超えると截断されるため、本文はすべて個別ファイルに持つことが重要。

zenn-claude-fable-5-system-prompt-4-types

Claude Fable 5 のシステムプロンプト4種類の整理

URL: https://zenn.dev/amu_lab/articles/claude-fable-5-system-prompt-4-types
日付: 2026-06-15
Tier: Tier 2
要旨: 「Fable 5 のシステムプロンプト」と呼ばれるものが実は4つの異なる文脈に分かれていることを整理した記事。公式 release-notes 版・リーク版・Claude Code 版・API 版（存在しない）を区別して、目的別にどれを参照すべきかを示している。

詳細

Fable 5 の停止経緯：2026年6月9日リリース、6月12日に米政府の国家安全保障・輸出管理指令を受領し外国籍ユーザーへのアクセス停止命令が下り、結果的に全顧客向けに停止した。6月15日時点で復旧作業中。

4種類のシステムプロンプト：

① 公式 release-notes 版（docs.claude.com/en/release-notes/system-prompts）: Anthropicが透明性方針で公開する「コア」部分
② リーク版: GitHub等で出回る非公式の全文とされる抽出物。Anthropic未確認・検証不能
③ Claude Code 版: CLI/Agent SDK 独自のプロンプト。コミュニティが整理（Piebald-AI/claude-code-system-prompts）
④ API 版: デフォルトのシステムプロンプトは存在しない。開発者が白紙から書く

Claude.ai のプロンプトと Claude Code のプロンプトは別物であり、①を読んで③の挙動を説明しようとするアンチパターンが広がっている。APIには既製プロンプトが無いため①や③を設計の参考にしつつ自分で書く必要がある。

zenn-code-with-claude-tokyo-2026-sessions

Code with Claude Tokyo 2026 全セッションまとめ

URL: https://zenn.dev/mdtechknowledge/articles/code-with-claude-tokyo-sessions
日付: 2026-06-15
Tier: Tier 2
要旨: 2026年6月10日に開催された Code with Claude Tokyo（約9.8時間の配信アーカイブ）の全12セッションを動画タイムスタンプつきで整理した記事。Canva・楽天・みずほFG・NRIの事例セッションも含む。

詳細

主要な発表内容：

Fable 5 の SWE-bench Pro スコア：Fable 5=80.0%、Mythos Preview=77.8%、Opus 4.8=69.2%
Claude Code のマルチセッション管理UI・Remote Control（iPhone等から操作可能）・Routines（スケジュール・GitHubイベント・APIトリガー）・Dynamic workflows（多数の並列サブエージェント）を発表
Auto mode：承認なしに安全なコマンドを自律実行、risky 操作（rm -rf等）は自動ブロック
24エージェントが12言語ロケールファイルを822.8kトークンで並列生成するデモを公開

事例：

Canva（月2.65億ユーザー）: Sonnetをメインキャッシュ・Opus/Haiku をサブに委譲してコスト-46%・成功指標+9%
Spotify: Claude Code で月1,000件超のPRを生成
みずほFG: AIネイティブな開発組織の構築事例
NRI: 業務タスク・ベンチマークによるモデル選定の知見

zenn-codex-primary-runtime-migration-guide

Claude Code 中心運用から Codex 中心運用へ移行する判断基準

URL: https://zenn.dev/tadkud/articles/codex-primary-runtime-migration-guide
日付: 2026-06-15
Tier: Tier 3
要旨: Claude Code から OpenAI Codex への移行を「設定ファイル移植」ではなく「capability 単位の分解」から始めることを推奨する記事。著者の実環境では2026-06-15時点で Codex 側15件・Claude 側24件のアーティファクトが残存しており、exists 判定だけでは移行完了とみなせないと結論している。

詳細

移行判断の順序：

運用を capability 名で一言にできるか確認
Codex 側に対応する skill / automation / hook があるか確認
drift チェックで covered か partial かを確認
実成果物や dry-run で「回る」ことを確認
push・公開・送信の承認ゲートが混ざっていないか確認

主なリスク：scheduled task の owner が曖昧なまま Claude・Codex 両方に残ると「片方は止まる」または「両方走る」二重発火が発生しやすい。Claude を即廃止するより read-only 参照元として残し、capability 単位で段階移行するほうが安全。

zenn-context-slimming-228kb-to-48kb

重くなった Claude Code を軽くする — コンテキスト注入を228KBから48KBに削った監査

URL: https://zenn.dev/bokuwalily/articles/context-slimming
日付: 2026-06-15
Tier: Tier 2
要旨: Claude Codeが「直近の指示を取りこぼす・話が混線する」症状の原因がSessionStart時のコンテキスト注入量の肥大化だったと特定し、~/.claude/rules/ の未使用言語ルールを退避することで228KB→48KB（約79%減）に削減した実践記録。

詳細

症状の2つの原因を分離：

セッションが重いだけ → 有効プラグインの数が原因。未使用プラグインを enabled: false に設定
直近指示の取りこぼし・話の混線 → 注入総量が原因。注入源を実測して刈り込む

~/.claude/rules/ の盲点：このディレクトリは @import ではなくディレクトリ全体を毎回フルロードする。汎用ルールパック由来で10言語分のルールが入っていたが、実際に使うのはPython/TypeScript/Webの3つのみだった。

修正方法：使わない言語ディレクトリをツリー外に mv するだけで注入が止まる（完全非破壊）。ディスク上のファイルサイズと注入トークン量は別物で、注入スクリプトが上限カットしているファイルを削除してもトークン削減効果はゼロ。必ず注入源を実測して特定することが重要。

zenn-git-worktree-h5i-ai-agent-sandbox

Git Worktree を安全に：h5i で作るAIエージェント用サンドボックス

URL: https://zenn.dev/koukyosyumei/articles/7bfe0ef9baff1e
日付: 2026-06-15
Tier: Tier 3
要旨: Git Worktree はサンドボックスではなく、複数エージェントが別の環境に侵入・破壊する可能性があるという問題を指摘し、AI向け次世代 git として開発中の h5i の h5i env コマンドで Docker 的なネットワーク・ファイルシステムの隔離を実現する方法を紹介している。

詳細

Git Worktree の弱点：追加 worktree の .git はファイル形式で元リポジトリの .git 以下を参照しており、独立した .git ディレクトリを持たない。Git オブジェクトは共有されるためエージェントが他の worktree に影響を与えるリスクがある。

h5i env の位置づけ：Docker のように環境内部のエージェントが許可されていない外部フォルダやネットワークへのアクセスを禁止しつつ、worktree のような軽量でブランチに紐づいた分散開発環境を提供する。ただし h5i 自体は現在開発中のツールであり本番用途での安定性は未確認。

zenn-launchd-traps-claude-code-automation

macOS で Claude Code の自動化を24/7回すと踏む launchd の罠5つ

URL: https://zenn.dev/bokuwalily/articles/launchd-traps
日付: 2026-06-15
Tier: Tier 2
要旨: macOS で Claude Code 関連スクリプトを launchd で24時間自動実行する際に踏む罠を5つ整理した記事。cron が modern macOS で動かないこと・PATH 問題・timeout コマンド非存在・StartCalendarInterval の構文制限などを実測と回避策つきで解説する。

詳細

罠5つの概要：

cron は modern macOS（Sequoia以降）で実質動いていない。launchd に移行が必要
StartCalendarInterval で */5 形式は使えない。周期実行は StartInterval（秒数）、特定時刻は配列で並べる
GUIから起動した子プロセスは ~/.zshrc を読まず最小PATH（/usr/bin:/bin等）しか持たない。~/.claude/settings.json の env.PATH に /opt/homebrew/bin を含める
macOS は GNU coreutils の timeout を非搭載。Homebrew で coreutils をインストールして gtimeout を使う 5.（記事では5件紹介しているが本文途中でカット）

launchd の Label は com.you.name 形式（ドットなしは拒否）、ProgramArguments は配列必須、StandardOutPath/ErrorPath を絶対パスで明示しないと出力が /dev/null に消える。

zenn-loop-engineering-in-production

Loop Engineering とは何か — AIエージェントでiOSアプリ15本を出荷して分かった「止めて改善するループ」の現実

URL: https://zenn.dev/allnew/articles/loop-engineering-in-production
日付: 2026-06-15
Tier: Tier 2
要旨: AIエージェントで「動かす設計」よりも「止める設計」が先に問題になることを、iOSアプリ15本を出荷した実運用ベースで解説した記事。Prompt Engineeringの上位概念として Loop Engineering を位置づけ、ANDON・Blind Gate・Kaizen Learning Capture などの仕組みを紹介する。

詳細

Loop Engineering の定義：AIエージェントが自律的に動く「ループ」そのものを設計・制御すること。状態管理・検証・停止条件・証跡・記憶・エスカレーションを含む制御設計。

本番で学んだ5つの現実の核心：

ループに停止メカニズムがないと間違った方向に速く進む
ANDON（トヨタ生産方式の自働化をLLMエージェントに適用）：前進系操作（git push等）を異常時にブロックし、失敗の証跡・分類・再発防止策・レポートの4成果物をそろえないとクローズできない設計
Memory だけでは不十分。失敗をテンプレート・テスト・ゲート・禁止変更リストへ反映して初めてループが改善される（Kaizen Learning Capture）

ANDON for LLM Agents はOSSとして公開済み。App Factoryは企画から審査提出まで3日、公開まで7日で到達するiOSアプリ事業基盤として実稼働中。

Classmethod Salesforce Hosted Mcp Custom Server Publickey1 Jp Stack Overflow for Agents