コンテンツにスキップ
Reports
Reports

日次レポート 2026-06-14

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

トピック別記事一覧

cloud（10件）

1. Security Command Center IaC スキャン結果を GitHub Actions Summary に集計 Tier 2

SCC の IaC スキャンアクションは pass/fail/error しか返さないため、SARIF の rules[].properties.severity を jq で解析して重大度別件数を $GITHUB_STEP_SUMMARY に書き出すステップを追加する手順。

2. Aurora PostgreSQL 18.3 / Babelfish 6.0 — Eager aggregation が目玉 Tier 2

Babelfish が 5.x から 6.0 にメジャーバージョンアップ。Eager aggregation（JOIN 前に集約を押し下げる最適化）で JOIN + GROUP BY クエリの実行時間が約 25% 短縮、ディスク I/O ゼロを実測確認。

3. RDS プレビュー環境で PostgreSQL 19 Beta 1 の新機能を試した Tier 2

2026-06-08 に RDS データベースプレビュー環境で PostgreSQL 19 Beta 1 が利用可能に。SQL/PGQ（プロパティグラフクエリ）と REPACK コマンドの動作を確認。

4. EventBridge Connection Private で Step Functions から VPC 内 ALB を呼ぶ Tier 2

Lambda 中継なしで Step Functions → VPC 内 Internal ALB に到達する2構成（EventBridge Connection Private + VPC Lattice / API Gateway + VPC Link v2）を CloudFormation で検証。

5. CloudFront マルチテナントディストリビューションを Terraform で構築 Tier 2

AWS Provider v6.28.0 でマルチテナントディストリビューションが Terraform サポート。共有 S3 バケット＋prefix 分割＋OAC で複数ドメインを1テンプレートから配信できることを確認。

6. Security Hub RDS.43 — RDS DB プロキシの TLS 暗号化修復手順 Tier 2

RDS Proxy の「Transport Layer Security が必要」を有効化するだけで対応できるシンプルな修復。変更中は約1分の modifying 状態で既存接続が瞬断する可能性あり。

7. CIDR 重複 2 VPC 間で PrivateLink 双方向通信を検証 Tier 2

同一 CIDR（10.0.0.0/16）の2 VPC 間で PrivateLink を2本張り双方向通信が成立することを Terraform で確認。Consumer 側は Interface Endpoint の ENI を相手として見るためアドレス衝突が起きない。

8. EC2 M8in/R8in 系にベアメタル metal-48xl/metal-96xl が追加 Tier 2

8ファミリーにベアメタルサイズを追加（2026-06-09）。Intel Xeon Scalable（Granite Rapids）搭載で M6in 比 vCPU あたり最大 43% 性能向上。現在は us-east-1 のみ提供。

9. AWS HealthOmics が Nextflow 26.04 をサポート Tier 2

Nextflow 26.04.0 は strict v2 構文パーサがデフォルト化されたメジャーアップデート。manifest.nextflowVersion = '26.04.0' の完全一致指定で Hello World ワークフローの完走を確認。

10. Claude Code の OTel ログを CloudWatch ダッシュボードで可視化 Tier 2

OTel ログを CloudWatch Logs の OTLP エンドポイントに直接送信。Raw/Sanitized の2段 LogGroup で機密フィールドを Lambda 除去しながら、コスト・トークン・スキル別利用状況を可視化。週次 Slack ダイジェスト Skill も付属。

ai-llm（10件）

1. Loop Engineering を Claude で実践 — bash while から GitHub Actions 常駐まで Tier 2

「AI にプロンプトを打つのをやめ、ループを設計する」Loop Engineering を6段階で実装。bash while → /schedule → Maker-Checker → Agent SDK → GitHub Actions 常駐まで、動くコードと実測コスト付きで解説。

2. Claude の「ツール」と「クライアント」を仕組みから理解する Tier 2

ツールは MCP/Skill/Agent SDK の総称ではなく Messages API の tool_use ブロックという具体的な仕組み。クライアントは「API を呼ぶ側のプログラム」の総称。概念の正確な定義を整理。

3. Foundation Models のマルチモーダル機能で画像解析 Tier 2

WWDC26 発表の Apple Foundation Models マルチモーダル機能を実機（iPhone 16e / シミュレータ）で検証。Attachment(cgImage) で画像入力が可能で、ペット写真で犬種認識・キャプション生成を確認。

4. Gemma 4 31B vs Claude Sonnet 4.6 — ビジネス文書 OCR 料金・精度比較 Tier 2

Gemma 4 31B は入力 $0.14/1M（Claude Sonnet 4.6 の約 21 分の1）だが bedrock-mantle エンドポイント専用で東京リージョン未対応。請求書・給与明細・旅費精算書での精度・速度も実測比較。

5. Kiro CLI 2.7 に /goal コマンドと Queue Steering が追加 Tier 2

/goal はゴール設定後に最大5イテレーションで実装＋自己検証を繰り返す自律ループコマンド。Queue Steering は作業中の Kiro に方向修正メッセージを送る機能。

6. JAWS-UG 神戸 CTF に Kiro と参戦 — CloudTrail ローカル集約が効いた Tier 2

インシデント対応テーマの CTF に Kiro CLI で参戦。事前準備（recon.sh・CTF 専用サブエージェント・CloudTrail ローカル集約）が効いて序盤10分でトップ近くに到達。

7. Claude Code v2.1.177 — Fable 5 アクセス一時停止・allowedModels 修正 Tier 2

米国政府の指令により全ユーザーへの Fable 5 アクセスを一時停止（Fable 5 選択時は Opus 4.8 に切り替え）。バックグラウンドセッション・Remote Control・モデル制御まわりの安定化が中心。

8. Playwright × Cucumber で API インテグレーションテストを書いてみた Tier 2

Cucumber の Gherkin 記法と Playwright の request/expect を組み合わせ、ブラウザバイナリ不要の HTTP クライアントとして API テストを実装。テスト仕様書とテストコードが一体化する。

9. mini-typescript に object literal を追加 — 構造的型付けの導入 Tier 2

TypeScript 学習用プロジェクト mini-typescript に { x: 1 } 形式の object literal を追加する実装記録。Lex/Parse/Check/Emit の4フェーズを縦断し、interface 型との構造的型チェックを導入。

10. Fable 5 にローカル LLM コーディングエージェントを作らせた話 Tier 3

GitHub Copilot のコスト問題を契機に Fable 5 が設計したローカル LLM エージェント「lca」。オーケストレーションを決定的コードで制御する3役分業アーキテクチャを採用。※ Fable 5 一時停止につき供養として公開。

ai-agent-implementation（10件）

1. MCP ツール lean-ctx の ctx_read(mode=“full”) でサイレントなデータ欠落バグ Tier 3

「完全な内容を保証」と謳う mode="full" が行削除・単語略語化するバグを発見・修正。CLI 経由と MCP 経由で結果が異なることから MCP 応答パイプライン側と特定。LEAN_CTX_COMPRESSION=off のみが有効。

2. AI エージェント時代の品質保証 ― 監査駆動フィードバック開発 Tier 3

AI エージェント開発で最大のリスクは「少数の整合性崩壊」（通知漏れ・OpenAPI ドリフト等）。定期監査をリコンシリエーションループに組み込む「監査駆動フィードバック開発」で補う。Laravel 実装例付き。

3. CLAUDE.md に書いたのに守られない ── 「渡す場所」の設計だった Tier 3

問題の正体はルールの内容ではなく「どこに・どんな形で渡すか」の設計のズレ。Claude Code に渡せる場所を CLAUDE.md / サブエージェント / スキル / Playbook / メモリ / 設定・権限 / MCP の7レイヤーに整理。

4. AI に「やるな」と書いても無駄 — 機械で止める3層ガードレール Tier 3

CLAUDE.md への禁止事項記述は確率的にしか守られない。入口でシークレット検査・実行で可逆性判定・構造でシークレットを平文保存しない、という「設定で物理的に塞ぐ」3層への移行実践。

5. Claude Code Hooks × Routines × Workflow で開発自動化パイプライン Tier 3

Claude Code の自動化を Hooks（イベント駆動）・Routines（スケジュール実行）・Dynamic Workflows（GA 済）の3層アーキテクチャで整理。使い分けの判断基準と実装パターンを解説。

6. AI エージェントの仕事をどう検品するか ── Trace、Eval、Pre-CI Review Tier 3

AI が 50〜700 本の PR を生成できる時代に人間レビューがボトルネックにならないよう「Trace→Triage→Eval→Human」の4層で検品する設計論。「読む」だけのレビューでは量が質を変えるため破綻する。

7. handover.md を「決定ログ」にしたら開発が捗るようになった Tier 3

セッション間引き継ぎメモを「決定事項ログ（なぜ・次だけ）」に再設計。git log で取れる情報は書かない・1決定4〜5行・古い決定は自動アーカイブという3仕掛けで肥大化を防止。

8. AI Agent は実装前に1コマンド打て Tier 3

AI エージェントの失敗は「環境前提の未確認」から始まることが多い。実装前に command -v / docker ps / git status -sb / test -f で環境を1コマンド確認するルールで無駄な修正を削減。

9. Codex の MCP 導入方法 — config.toml / Claude Code との比較 Tier 3

Codex の MCP 設定（config.toml）を Claude Code との差分を交えて整理。設定スコープ・stdio/Streamable HTTP の2トランスポート・codex mcp add コマンドの使い方を解説。

10. Claude Code から Codex へ移行の試行錯誤と「エージェントの作法」 Tier 3

「思考の Claude・実行の Codex」のマルチエージェント環境が最適解になりそうという結論。Codex は指示のゆらぎが Claude より顕著で、振る舞い定義の再構築に数時間を要した。

トレンドの連鎖

Loop Engineering の実装論が一気に広まった日

Loop Engineering（AI に毎回プロンプトを打つのをやめ、ループを設計する）が 2026-06-13 を起点に一斉に話題になっている。classmethod の実践記事は bash while → /loop → /schedule → Maker-Checker → Agent SDK → GitHub Actions の6段階を実際のコードで検証し、set -euo pipefail との組み合わせによるサイレントバグという具体的な罠まで示した。同じ日に Kiro CLI 2.7 が /goal コマンドを出し、Claude Code が Hooks/Routines/Workflow の3層構造として整理された記事も複数投稿されている。設計する対象がプロンプトからループへ移ったという認識が、日本語コミュニティ全体に同時着火した一日だった。

ガードレール設計の成熟。書いて守らせるから設定で塞ぐへ

ai-agent-implementation のトピックを横断すると、同一の構造が繰り返し現れる。CLAUDE.md に禁止事項を書いても確率的にしか守られない（3層ガードレール記事）、CLAUDE.md を書いても守られない正体は渡す場所の設計ミスだった（7レイヤー解剖書）、AI エージェントは局所タスクを速くこなすが大域的整合性が落ちる（監査駆動フィードバック開発）。これらは表現こそ違うが、LLM に期待するのではなく仕組みで補完するという同一の成熟方向を指している。単純な AI 活用の時代から、ガバナンス設計が主戦場になりつつある。

Fable 5 アクセス一時停止。AI ガバナンスの政治的側面が具体化

Claude Code v2.1.177 で、米国政府の指令を受けて全ユーザーへの Fable 5 アクセスを一時停止するという異例の措置が取られた。モデルを選択しても Opus 4.8 に切り替わるという状態。これはモデルアップデートではなく、政府規制が直接 AI ツールの利用可能モデルを制限したという点で従来と質が異なる。Fable 5 に自律エージェントを作らせた記事が供養として公開した経緯と重なり、いつでも使えるとは限らないことが現実のリスクとして認識される日になった。

Claude Code から Codex への移行探索が本格化

Claude Code から Codex へ移行した記録と、Codex MCP 導入 vs Claude Code 比較の2記事が同日に投稿された。どちらも思考用の Claude と実行用の Codex を組み合わせたマルチエージェント環境に行き着いている。Codex は指示のゆらぎが大きいという共通した観察もある。Fable 5 アクセス停止によるモデル選択肢の制約と相まって、単一ツール依存からの脱却とエージェント使い分けの最適化が加速する可能性がある。

AWS は PostgreSQL とネットワーク周りの更新が集中

Aurora PostgreSQL 18.3 / Babelfish 6.0（Eager aggregation）、RDS プレビューで PostgreSQL 19 Beta 1（SQL/PGQ / REPACK）、EventBridge Connection Private による VPC 内 ALB 直接接続、CloudFront マルチテナント Terraform 対応、EC2 M8in/R8in ベアメタルと AWS 由来のアップデートが一日に集中した。特に PostgreSQL 系は 18.3 GA と 19 Beta 1 という2世代分が同時に話題になっており、アップグレードを検討するなら今がそのタイミングになっている。

生成日: 2026-06-14

記事別詳細

dev-classmethod-jp-20260613-cc-updates-v2-1-177

Claude Code v2.1.176〜v2.1.177 の主要アップデート — Fable 5 アクセス一時停止

  • URL: https://dev.classmethod.jp/articles/20260613-cc-updates-v2-1-177/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: v2.1.176〜v2.1.177（2026-06-12〜13）のアップデートまとめ。米国政府の指令により全ユーザーへの Claude Fable 5 アクセスを一時停止（Fable 5 を選択しても Opus 4.8 に切り替え）。確認できた22件のうち大半がバックグラウンドセッション・Remote Control・モデル制御まわりの安定化。

詳細

  • 新機能: footerLinksRegexes 設定追加（フッターに正規表現マッチのリンクバッジを表示）。
  • セキュリティ修正: availableModels 許可リスト強制を修正。ANTHROPIC_DEFAULT_*_MODEL 環境変数経由でブロック対象モデルへの迂回経路を遮断。/fast も許可リスト外モデルへの切替を拒否するように。
  • 主な不具合修正: フックの if 条件のパスマッチ（Edit(src/**) 等）が正しくマッチするよう修正。SSH 越し tmux でのコピー/貼り付け修正。Remote Control のモデル暗黙切替修正。/cd 後の git ブランチ表示修正。
  • 改善: セッションタイトルの言語対応。Bedrock の認証情報キャッシュが Expiration まで保持されるよう改善。
dev-classmethod-jp-aurora-postgresql-18-3-babelfish-6-0

Amazon Aurora PostgreSQL 18.3 がリリース — Babelfish 6.0 のアップデート内容

  • URL: https://dev.classmethod.jp/articles/aurora-postgresql-18-3-babelfish-6-0/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: Aurora PostgreSQL 18.3 のリリースに伴い Babelfish が 5.x から 6.0 にメジャーバージョンアップ。目玉は Eager aggregation（JOIN 前に集約を押し下げてクエリパフォーマンスを改善）の追加で、実測では JOIN + GROUP BY クエリで約 25% の実行時間短縮・ディスク I/O ゼロを確認。

詳細

  • Babelfish 6.0 の新機能: ①Eager aggregation ②geography/geometry で Polygon サポート ③(n)varchar から datetimeoffset への暗黙キャスト ④sys.fn_varbintohexstr サポート
  • Eager aggregation は GUC babelfishpg_tsql.enable_eager_aggregate（デフォルト ON）で制御。Babelfish 側デフォルト ON なので TDS ポート経由は自動恩恵あり。min_eager_agg_group_size（デフォルト 8）で適用閾値を設定。
  • Aurora PostgreSQL ネイティブ GUC の enable_eager_aggregate はデフォルト OFF と異なる点に注意。
  • SQL Server 互換バージョン（12.0.2000.8 = SQL Server 2014 相当）は変わらず。
  • go-sqlcmd 1.9.0 の GROUP BY クエリでの TDS エラーは 6.0 でも継続。mssql-tools18 や pymssql が代替候補。
dev-classmethod-jp-aws-healthomics-nextflow-26-04-hello-world

AWS HealthOmics が Nextflow 26.04 をサポート — Hello World で試してみた

  • URL: https://dev.classmethod.jp/articles/aws-healthomics-nextflow-26-04-hello-world/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: 2026年6月に AWS HealthOmics が Nextflow 26.04.0 をサポート。26.04.0 は strict v2 構文パーサがデフォルト化されたメジャーアップデート。manifest.nextflowVersion = '26.04.0' の完全一致指定で Hello World ワークフロー（COMPLETED ステータス・S3 出力）を確認。

詳細

  • バージョン指定の罠: HealthOmics は範囲指定（>=24）の場合 v24.10.8 → v25.10.0 → v26.04.0 の優先順位で最優先を選ぶため、>=24 と書くと v24.10.8 が選ばれる。26.04.0 を使うには完全一致指定が必要。
  • Strict v2 パーサ: 26.04.0 はデフォルト strict v2 構文パーサ。レガシー v1 構文のワークフローを使いたい場合は StartRun の engineSettings で syntaxVersion: v1 を指定。
  • コンテナは ECR プライベートリポジトリに格納が必要。ARM マシンでは --platform amd64 で明示的に amd64 イメージを取得すること。
  • リージョンは us-east-1 のみ（東京未対応）。
dev-classmethod-jp-bedrock-gemma4-claude-ocr

Gemma 4 31B と Claude Sonnet 4.6 でビジネス文書を OCR・構造化抽出し、料金と精度を比較した

  • URL: https://dev.classmethod.jp/articles/bedrock-gemma4-claude-ocr/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: Amazon Bedrock で利用可能になった Google Gemma 4 31B を Claude Sonnet 4.6 と比較し、請求書・給与明細・出張旅費精算書の OCR・構造化抽出で料金・速度・精度を検証。Gemma 4 31B は単価が安い（入力 $0.14/1M、出力 $0.40/1M）が、bedrock-mantle エンドポイント専用で東京リージョン未対応など制約もある。

詳細

  • 接続の違い: Gemma 4 31B は bedrock-mantle エンドポイント（OpenAI 互換 Chat Completions）。Claude Sonnet 4.6 は bedrock-runtime の Converse API。
  • Gemma 4 の制限: us-east-1/2、us-west-2、eu-central-1 の4リージョンのみ。Cross-Region 推論（Geo/Global）非対応。東京リージョン未提供。
  • 画像は image_url 形式、PDF は file 形式で渡す（OpenAI 互換）。
  • 検証は架空ビジネス文書3種（PNG/PDF）の1回ずつ実行。為替 1USD=150 円で換算。
dev-classmethod-jp-claude-code-otel-cloudwatch-dashboard-weekly-slack-digest

Claude Code の OTel ログを CloudWatch ダッシュボードで可視化してみた

  • URL: https://dev.classmethod.jp/articles/claude-code-otel-cloudwatch-dashboard-weekly-slack-digest/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: Claude Code の OpenTelemetry ログを CloudWatch Logs の OTLP エンドポイントに直接送信し、チームの利用状況をダッシュボード化する構成を解説。Raw/Sanitized の2段 LogGroup 構成で機密フィールド（コマンド本文・ファイルパス等）を Lambda で除去しながら、コスト・トークン・スキル別利用状況を可視化。週次 Slack ダイジェスト Skill もセットで構築。

詳細

  • アーキテクチャ: Claude Code → CloudWatch Logs OTLP エンドポイント（Bearer Token）→ Raw LogGroup（保持1日）→ Sanitizer Lambda → Sanitized LogGroup（保持60日）→ ダッシュボード。
  • Bearer Token 認証の制限: US リージョン限定（us-east-1/2、us-west-1/2）。データ所在地要件がある場合は要確認。
  • Sanitizer Lambda は allowlist 方式でコスト・トークン数・モデル名・スキル名などのみを通す。denylist でなく allowlist にすることで新しい属性が増えても安全側に倒れる。
  • ダッシュボードウィジェット: チーム合計、ユーザー別日次コスト、ユーザー別アクティビティ、スキル/サブエージェント/MCP/モデルランキング。
  • 週次 Slack ダイジェスト Skill は Logs Insights クエリ + 公式ドキュメント WebFetch による AI 考察つき。非活用者の名指しはせず活用者を称えるポジティブ枠のみ。
dev-classmethod-jp-claude-loop-engineering-practice

Loop Engineering を Claude を使って実践してみた

  • URL: https://dev.classmethod.jp/articles/claude-loop-engineering-practice/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: 2026年6月に話題になった「Loop Engineering」（AI に毎回プロンプトを打つのをやめ、エージェントにプロンプトを打つシステムを設計する）を Claude Code で実装した6段階の実践例を解説。bash while ループから Agent SDK hooks・GitHub Actions 常駐まで、自律度の低い順に動くコードと実測コストを紹介。

詳細

  • Loop Engineering の6段階: [1] bash while + claude -p → [2] /loop（セッション内）→ [3] /schedule（クラウド常駐）→ [4] Maker-Checker → [5] Agent SDK（query loop）→ [6] GitHub Actions 常駐。
  • bash while の罠: set -euo pipefail + パイプラインでテスト失敗時に npm test 2>&1 | claude -p ... が pipefail で全体失敗扱いになりスクリプトが途中終了するサイレントなバグ。修正版ではテスト出力を一度変数にキャプチャしてパイプラインに失敗ステータスを持ち込まない。
  • プリミティブ: スケジューリング・Worktrees・Skills・MCP・Sub-agents・Memory/State の6つ。
  • 段階的自律 L1（報告のみ）→ L2（補助修正）→ L3（完全自律）でロールアウトするのが推奨。
  • 最初の本番ループは Daily Triage の L1（報告のみ）が無難。
  • 検証は Claude Code 2.1.177 / claude-agent-sdk 0.2.93 で実施（2026-06-13）。
dev-classmethod-jp-claude-tool-and-client

Claude の「ツール」と「クライアント」を仕組みから理解する

  • URL: https://dev.classmethod.jp/articles/claude-tool-and-client/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: Claude API の「ツール（tool_use）」と「クライアント」という2つの概念の正確な定義を解説。ツールは MCP/Skill/Agent SDK の総称ではなく、Messages API の tool_use ブロックという具体的な仕組みであり、クライアントは claude.ai・Claude Code・自作スクリプトなど「API を呼ぶ側のプログラム」の総称。

詳細

  • API の基本: ステートレスなリクエスト-レスポンス。会話継続はクライアントが messages 配列に全履歴を毎回まとめて送ることで実現。会話が長くなるほど入力トークン（課金）が増える。
  • stop_reason: end_turn（完了）・tool_use（ツール実行要求）・max_tokens（上限打ち切り）・pause_turn（サーバーサイドツールの反復上限）など。クライアントはこれを見て次のアクションを決定。
  • ツールの定義: name/description/input_schema の3要素。description の品質でモデルのツール呼び出し判断が変わる。
  • ツールの種類: クライアント実行（Bash、text_editor など）と Anthropic サーバー実行（web_search、code_execution）の2種。後者はクライアントが実行不要で結果が応答に含まれる。
  • クライアントの例: claude.ai・デスクトップアプリ・Claude Code・Claude Cowork・自作スクリプト・Bedrock 経由プログラムすべてが「クライアント」。
  • tool_result は tool ロールではなく user ロールのメッセージで返す（他社 API と異なる）。
dev-classmethod-jp-cloudfront-multidistribution-terraform

CloudFront マルチテナントディストリビューションを Terraform で構築してみた

  • URL: https://dev.classmethod.jp/articles/cloudfront-multidistribution-terraform/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: AWS Provider v6.28.0 から CloudFront のマルチテナントディストリビューション（テンプレート1つ+ドメインごとのテナント構成）が Terraform でサポートされた。共有 S3 バケット＋prefix 分割＋OAC で複数ドメインを1テンプレートで配信できることを確認。

詳細

  • 構成要素: aws_cloudfront_multitenant_distribution（テンプレート）+ aws_cloudfront_connection_group（ルーティングエンドポイント）+ aws_cloudfront_distribution_tenant（ドメインごとのフロントドア）の3リソース。
  • マルチテナントディストリビューション自体は connection_mode: tenant-only で単体配信不可。テナントの CNAME 先は connection group の routing endpoint へ向ける。
  • origin の引数は origin_id ではなく id（ハマりポイント）。TTL 直指定不可でキャッシュポリシー必須。
  • ACM 証明書は apex + *.apex の SAN 付きで共有。検証レコードが同名になるため allow_overwrite = true + distinct() が必要。
  • DNS は alias 不可で CNAME のみ。PriceClass・WAF Classic・OAI など設定できない項目あり。
dev-classmethod-jp-ec2-metal-48xl-96xl-m8in-r8in-network-ebs-ga

Amazon EC2 M8in/R8in 系にベアメタル（metal-48xl / metal-96xl）サイズが追加

詳細

  • 追加は合計 16 種（8ファミリー × metal-48xl/metal-96xl）。
  • metal-96xl スペック例（M8in）: vCPU 384、メモリ 1,536 GiB、ネットワーク 600 Gbps、EBS 帯域 120 Gbps、価格 $32.079/hr。
  • n 系（M8in/M8idn）はネットワーク帯域が無印の最大 6 倍、b 系（M8ib/M8idb）は EBS 帯域が最大 3.75 倍。
  • ベアメタルの用途: 独自ハイパーバイザー実行、特定ライセンス要件対応、低レイヤー検証など。
  • d 付きはインスタンスストア（NVMe）搭載で停止/終了時データ消失。EFA は全 16 タイプでサポート。
  • 東京リージョン未対応（2026-06-12 時点）。
dev-classmethod-jp-eventbridge-connection-private-sfn-vpc-alb

VPC の中に EventBridge Connection で入ってみた — Step Functions から VPC 内 ALB を Lambda なしでリクエスト

  • URL: https://dev.classmethod.jp/articles/eventbridge-connection-private-sfn-vpc-alb/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: Step Functions から VPC 内 Internal ALB を Lambda なしで呼び出す2パターン（EventBridge Connection Private + VPC Lattice、API Gateway + VPC Link v2）を CloudFormation で構築・比較。どちらも Lambda 中継なしで到達を確認。EventBridge Connection は IAM 権限が多く構成要素も多いが、API Gateway は execute-api:Invoke のみでシンプル。

詳細

  • Pattern A（EventBridge Connection Private）: Resource Gateway → Resource Configuration → Interface Endpoint の3レイヤー構成。VPC Lattice 経由でプライベートリソースに到達。
    • ハマりどころ: Internal ALB への接続に ACM パブリック証明書が必須（自己署名不可）。Resource Gateway のセキュリティグループは全 TCP ポートを 0.0.0.0/0 から許可が必要（VPC CIDR の 443/TCP のみではタイムアウト）。
  • Pattern B（API Gateway REST API + VPC Link v2）: 2025年11月に ALB 直接統合対応でより簡潔に構築可能に。Step Functions からは Optimized Integration（apigateway:invoke）で呼び出し。
  • HTTP Task のタイムアウトは最大 60 秒の制限あり。
dev-classmethod-jp-foundation-models-multimodal-image-analysis

Foundation Models のマルチモーダル機能で画像解析してみた

  • URL: https://dev.classmethod.jp/articles/foundation-models-multimodal-image-analysis/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: WWDC26 で発表された Apple Foundation Models のマルチモーダル機能（画像入力）を実機（iPhone 16e / シミュレータ）で検証。Attachment(cgImage) で画像をプロンプトに組み込め、ペット写真で犬種認識・キャプション生成が動作確認できた。オンデバイス推論でも LLM らしい確率的な出力変動あり。

詳細

  • 動作環境: Apple Intelligence 対応デバイス必須。Xcode 27.0 Beta / iOS 27.0 Beta / macOS Tahoe 26.4.1 で検証。
  • 実装: LanguageModelSession.respond {} のブロック内に文字列と Attachment(cgImage) を並べるだけ。UIImage は .cgImage で変換してから渡す（Attachment は UIImage 直渡し不可）。
  • 構造化出力: @Generable + @Guide マクロで任意の Swift 型として結果を受け取れる。@Generable 型はコンテキストウィンドウを消費するため不要なプロパティは省く。
  • 同一プロンプト4回実行で毎回表現が変わり（「チワワ」判定あり/なし）、処理時間 2,584〜3,841ms とばらつきがあった。
dev-classmethod-jp-gcp-scc-iac-scan-result-job-summary

Security Command Center の IaC スキャン結果を GitHub Actions Summary に集計するステップを追加してみた

  • URL: https://dev.classmethod.jp/articles/gcp-scc-iac-scan-result-job-summary/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: GCP Security Command Center の analyze-code-security-scc@v1 アクションは iac_scan_result（passed/failed/error の3値）しか返さないため、違反件数や重大度を確認するには SARIF ファイルを自分で解析する必要がある。SARIF の重大度は results 側ではなく rules[].properties.severity に入っているため、jq で両者を突き合わせてカウントし、$GITHUB_STEP_SUMMARY に書き出すステップを追加することで GitHub Actions の Summary 画面に重大度別件数を表示できる。

詳細

  • iac_scan_result は合否しか返さない。件数・重大度を得るには iac_scan_result_sarif_path の SARIF を自分で読む必要がある。
  • SARIF の重大度は runs[0].tool.driver.rules[].properties.severity 側にあり、results[].ruleId と rules[].id の一致でマッピングする。
  • if: always() をつけないと前段の Analyze ステップが失敗した際に集計ステップがスキップされる。
  • env: に ${{ }} を渡してクォート崩れ・インジェクションを防ぐのが安全な書き方。
  • 違反ゼロの場合も // [] // {} // "UNKNOWN" のフォールバックで jq はエラーにならない。
dev-classmethod-jp-jawsug-kobe-12-ctf-with-kiro

JAWS-UG 神戸 #12 CTF に Kiro と参戦してみた

  • URL: https://dev.classmethod.jp/articles/jawsug-kobe-12-ctf-with-kiro/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: 「アクセスキーが流出したていで遊ぼう」というインシデント対応テーマの CTF に Kiro CLI を使って参戦。事前準備（サービス別 recon.sh・CTF 専用サブエージェント・CloudTrail ローカル集約）が効いて序盤10分でトップ近くに到達。最終課題の提出フォーマット問題で順位を落としたが事後の学びが多かった。

詳細

  • 最も効果的な事前準備: S3 配信済み CloudTrail ログを aws s3 sync でローカルに全取得し、jq で分析する手法。LookupEvents（50件/ページ・2req/秒の制限あり、データイベント非対応）より速く柔軟に分析できる。
  • サブエージェント構成: 担当サービス別エージェントが findings.md に記録 → リード役エージェントが progress.md に集約・次の調査を提示。ヘッドレス実行のラッパースクリプト経由で並行実行。
  • モデル選定: Kiro CLI に Sonnet 4.6 を指定し kiro-cli chat -a（ツール確認省略）で高速化。CTF の隔離環境限定の設定。
  • AWSセキュリティの学び: ネットワーク境界より IAM 権限設計と API レベル認可が重要。CloudTrail の追跡可能性（誰が・いつ・どの API 操作を実行）がインシデント対応で決定的。
dev-classmethod-jp-kiro-cli-goal-queuesteering

Kiro CLI 2.7 に /goal コマンドと Queue Steering が追加

  • URL: https://dev.classmethod.jp/articles/kiro-cli-goal-queuesteering/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: Kiro CLI 2.7.0 で /goal（ゴール設定して自律ループ実行）、Queue Steering（作業中の方向修正メッセージ送信）、/rewind のターンサマリー表示強化が追加。/goal は受入基準を満たすまで最大5イテレーションで実装+自己検証を繰り返す。

詳細

  • /goal コマンド: ゴール文から受入基準を自動導出し、「実装 → 検証 → 再実装」を自律的に繰り返す（デフォルト最大5イテレーション、--max で変更可）。完了時に「証拠」セクションに実行結果を出力。テストが通るなど具体的な完了条件が書かれているタスクに有効。
  • Queue Steering: 作業中に Steer モード（即座注入、ツール境界で反映）と Queue モード（ターン終了後に送信）を Ctrl+S で切り替え。Ctrl+X でキューの確認・編集・削除が可能。
  • /rewind 表示強化: 各ターンに「Turn Activity」（使用ツールと結果のサマリー）と Context used（コンテキスト使用率）が表示されるようになり、分岐点を探しやすくなった。
dev-classmethod-jp-mini-typescript-add-object-literal-compiler

mini-typescript に object literal を追加してみた

  • URL: https://dev.classmethod.jp/articles/mini-typescript-add-object-literal-compiler/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: TypeScript コンパイラ学習用教材プロジェクト mini-typescript に { x: 1, y: 2 } のような object literal を追加する実装記録。今回の見どころは構造的型付け（structural typing）の導入。Lex/Parse/Check/Emit の4フェーズを縦断して実装し、interface 型との構造的型チェックが通ることを確認。

詳細

  • 変更フェーズ: types.ts（Token.Comma 追加・ObjectLiteral/PropertyAssignment ノード定義）→ Lex → Parse → Check（型推論・isTypeEqual 構造的比較・typeToString 再帰化）→ Emit。Bind と Transform は変更なし。
  • 構造的型付け: interface 型と object literal 型は別オブジェクトとして生成されるため参照等価では比較不可。プロパティ名と型の一致を構造的に比較する isTypeEqual を導入。
  • 本家 TypeScript の「変数経由なら余分プロパティ OK（部分型）」は実装せず、常に完全一致で弾く（より厳しい実装）。
  • check.ts の変更が最も多い。構造的型付け導入で型比較ロジックを根本から書き換えるため。
dev-classmethod-jp-rds-preview-postgresql-19-beta1-new-features

Amazon RDS プレビュー環境で PostgreSQL 19 Beta 1 の新機能を試してみた

  • URL: https://dev.classmethod.jp/articles/rds-preview-postgresql-19-beta1-new-features/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: 2026年6月8日に Amazon RDS データベースプレビュー環境で PostgreSQL 19 Beta 1 が利用可能になった。SQL/PGQ（プロパティグラフクエリ）と REPACK コマンドが正常動作することを確認。論理レプリケーションの動的有効化は RDS 環境では従来通りパラメータグループ経由の再起動が必要な状況。

詳細

  • SQL/PGQ: CREATE PROPERTY GRAPH でグラフ定義、GRAPH_TABLE/MATCH でパターンマッチング。直接友達・2ホップ探索・協調フィルタリングが動作確認済み。
  • REPACK コマンド: VACUUM FULL 相当の再編成を実行。CONCURRENTLY オプションでオンライン実行（ただし通常 REPACK より圧縮率はやや低い）。
  • 論理レプリケーション動的有効化: コミュニティ版 PG19 では wal_level=replica のまま自動有効化される設計だが、RDS では wal_level が既に logical に設定されており ALTER SYSTEM も pg_reload_conf() も制限があるため動的有効化の検証は不可。
  • リージョンは us-east-2 のみ対応。Beta 1 なので GA までに変更の可能性あり。
dev-classmethod-jp-securityhub-fsbp-remediation-rds-43

Security Hub CSPM 修復手順 — [RDS.43] RDS DB プロキシの接続には TLS 暗号化が必要

  • URL: https://dev.classmethod.jp/articles/securityhub-fsbp-remediation-rds-43/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: Security Hub コントロール RDS.43「RDS DB プロキシの接続には TLS 暗号化が必要」の修復手順。RDS Proxy の「Transport Layer Security が必要」を有効化するだけで対応できるシンプルなコントロール。変更中は約1分間 modifying 状態になり既存接続が瞬断する可能性がある。

詳細

  • コンソール: RDS コンソール → プロキシ → 変更 → 「Transport Layer Security が必要」にチェック。
  • CLI: aws rds modify-db-proxy --db-proxy-name <name> --require-tls
  • 反映確認: スケジュールタイプが「定期的（Periodic）」のため最大24時間かかる。
  • 有効化のメリット: VPC 内での盗聴リスク排除、古い DB インスタンスへの接続でも TLS 1.3 を使えるようになる。
  • ゼロトラストの観点から「VPC 内は信頼できる」という前提は崩れつつあり、侵害されたリソースからの内部通信キャプチャは現実的な脅威。
dev-classmethod-jp-shoma-playwright-cucumber-gherkin

Playwright × Cucumber（Gherkin 記法）で API インテグレーションテストを書いてみた

詳細

  • 構成: Cucumber（シナリオ実行）+ Playwright の request（HTTP クライアント）+ expect（アサーション）。axios + Jest を別々に入れる必要がなく1パッケージで完結。
  • Gherkin: Given/When/Then で前提・操作・期待結果を記述。日本語も使用可能。
  • テスト対象として Express API を src/server.ts に作成し、npm test で @cucumber/cucumber が Feature ファイルを実行。
  • 動作環境: Node.js 24 / TypeScript 6.0.3 / @cucumber/cucumber 13.0.0 / @playwright/test 1.60.0 / express 5.2.1。
dev-classmethod-jp-vpc-privatelink-two-way

2つの VPC 間で AWS PrivateLink の双方向通信を検証してみた

  • URL: https://dev.classmethod.jp/articles/vpc-privatelink-two-way/

  • 日付: 2026-06-14

  • Tier: Tier 2

  • 要旨: CIDR が重複（10.0.0.0/16）する2つの VPC 間で PrivateLink を2本張り、双方向通信が成立することを Terraform で検証。同一 IP（10.0.1.10）の EC2 同士でも、Consumer 側は Interface Endpoint の ENI を相手として見るためアドレス衝突が起きない。

詳細

  • PrivateLink は片方向（Consumer → Provider）のみ。双方向化には PrivateLink を2本張り、各 VPC が Provider/Consumer の両役を担う。
  • 重複 CIDR でも通る理由: Consumer は相手の実 IP を見えず Interface Endpoint の ENI IP として見る。Provider のターゲットは NLB のプライベート IP として見る。この2段マスクで IP 衝突を回避。
  • NLB には SG を付けない（全許可）必要あり。
  • VPC ピアリング・TGW は CIDR 重複では使えないため PrivateLink が唯一の選択肢。
  • 閉域 EC2 へのアクセスは SSM Session Manager 経由（ssm/ssmmessages/ec2messages の Interface Endpoint 必要）。
zenn-dev-0h-n0-3a4fdda1d5c743

Claude Code Hooks × Routines × Workflow で開発自動化パイプラインを構築する

  • URL: https://zenn.dev/0h_n0/articles/3a4fdda1d5c743

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: Claude Code の自動化機能を Hooks・Routines・Dynamic Workflows の3層アーキテクチャで整理し使い分けの判断基準・実装パターンを解説。Routines は 2026-06-14 時点でリサーチプレビュー段階。Dynamic Workflows は 2026-05-28 に GA。

詳細

  • 3層の役割:
    • Hooks: ツール実行前後の決定論的ルール（ローカル・セッション内。LLM の判断に依存しない）
    • Routines: クラウド上のスケジュール・イベント駆動実行（PC を閉じても動く。Cron/GitHub/API トリガー）
    • Dynamic Workflows: マルチエージェントオーケストレーション（コンテキストウィンドウを超えるタスクを分割）
  • Hooks の実装: .claude/settings.json に PreToolUse/PostToolUse/SessionStart/PostResponse イベントを設定。ファイル編集後の自動フォーマット（Python→ruff、TS→prettier、Rust→rustfmt）などが典型例。
  • Bun 事例（公式ブログ）: Dynamic Workflows で Zig→Rust 移植に 75 万行のコードを11日で生成。
  • 重要: 3層すべてを使う必要はない。多くのプロジェクトでは Hooks だけで十分。Routines は複数人チーム、Workflows は大規模コードベースで初めて必要になるケースがほとんど。
zenn-dev-aiwatch-jp-agent-flow-review-evals

AI エージェントの仕事をどう検品するか ── Trace、Eval、Pre-CI Review の考え方

  • URL: https://zenn.dev/aiwatch_jp/articles/agent-flow-review-evals

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: AI エージェントが 50〜700 本の PR を生成できる時代に、人間レビューがボトルネックにならないよう「Trace（記録）→ Triage（分類）→ Eval（機械判定）→ Human（最終判断）」の4層で検品する設計論。量の変化が性質を変えるため、「読む」だけのレビューでは破綻する。

詳細

  • Trace（何が起きたか残す）: 作業ログを最後に出力させる（目的・読んだファイル・変更ファイル・実行コマンド・失敗ログ・未確認事項）。trace がないと reviewer は diff から推理するしかない。PromptLayer などの trace ツールは「レビュー材料を残す部品」として位置づける。
  • Triage（全部を読まないために分ける）: diff を trivial（typo・コメント）/ normal（通常機能修正）/ risky（認証・課金・DB・外部API・セキュリティ境界）に分類してから人間に上げる。人間にやらせても別エージェントにやらせても可。
  • Eval（機械的に判定できるものを判定する）: テスト通過・型チェック・linter・セキュリティスキャンなどを CI に組み込み。「AI が書いたから別途チェック」ではなく同じ基準を適用。
  • Human: Triage と Eval を通ったものだけ人間が見る。risky に分類されたものを優先。
zenn-dev-corone-549eb4ba9adcec

Claude Code から Codex へ、移行の試行錯誤と「エージェントの作法」

  • URL: https://zenn.dev/corone/articles/549eb4ba9adcec

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: コストパフォーマンスの観点から Claude Code から Codex への移行を試みた記録。「思考の Claude」と「実行の Codex」のマルチエージェント環境が最適解になりそうという結論。指示の粒度に対する「ゆらぎ」が Claude より顕著で、自然言語による振る舞い定義の再構築に数時間を要した。

詳細

  • 移行作業: .toml 設定と Agent.md の役割理解（Claude 時代の CLAUDE.md と同等の立ち位置）、HTML 構成を Codex の Skills 形式へ書き換え、MCP 設定の再定義（mcp.json がそのまま使えず）、サンドボックス環境設定。
  • 課題: 承認フロー（許可確認）の煩雑さ。Codex はレスポンス速度は快適だが指示のゆらぎが顕著。
  • 解決策: 指示の曖昧さを排除するため自然言語による振る舞い定義を厳格に再構築。
  • 今後の方向性: 「思考の Claude」（複雑な推論・設計）+ 「実行の Codex」（定型業務・高速実行）というマルチエージェント環境。
zenn-dev-ichikawa-y-audit-driven-feedback-development

AI エージェント時代の品質保証 ― 監査駆動フィードバック開発という考え方

  • URL: https://zenn.dev/ichikawa_y/articles/audit-driven-feedback-development

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: AI エージェント主体の開発では「少数の整合性崩壊」（通知漏れ・OpenAPI ドリフト・Feature Flag 削除漏れ）が最大のリスク。定期的な監査をリコンシリエーションループ（検知→修正→再監査）に組み込む「監査駆動フィードバック開発」で補う。Laravel を例にした具体的な実装付き。

詳細

  • なぜ整合性崩壊が起きるか: AI エージェントは直前の文脈に最適化して動くため、ローカルなタスクは高速にこなすが「リポジトリ全体の整合性」という大域的視点が構造的に欠落する。
  • 監査の種類: Parity（Route↔Middleware 等）/ Wiring（通知配線漏れ）/ Data（不変条件）/ Docs（ドキュメントドリフト）/ Config / Architecture / Process の7種。
  • 重要な原則: 監査は増やせばいいわけではない。誤検知によるオオカミ少年化・ノイズ増大が逆効果になる。監査は「過去に実際に事故を起こした種類」から育てる（ポストモーテム起点）。
  • 実装例: Laravel の Artisan コマンドで「全ルートに認可ミドルウェアが設定されているか」を検査する Parity 監査。config/audit.php に免除ルートを列挙して機械可読にする。
  • フィードバック制御として見ると: 基準値（スキーマ/設計規約）→ 観測（監査）→ 修正（修正 PR）の閉ループ。
zenn-dev-ikahan-fa0c8f1b937639

「full なのに中身が欠ける」— MCP ツール lean-ctx の ctx_read で見つけたサイレントなデータ欠落バグ

  • URL: https://zenn.dev/ikahan/articles/fa0c8f1b937639

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: MCP ツール lean-ctx の ctx_read(mode="full") が「完全な内容を保証」と謳いながら行削除・単語略語化をするサイレントなデータ欠落バグを発見・修正した記録。CLI 経由と MCP 経由で結果が異なることで「MCP 応答パイプライン側のバグ」と特定。LEAN_CTX_COMPRESSION=off 環境変数のみが唯一有効だった。

詳細

  • 症状: CLAUDE.md を ctx_read(mode="full", fresh=true) で読むと箇条書き1行が消え、## User Environment が ## User env、execution → exec などに略語化される。
  • 切り分け: lean-ctx read CLAUDE.md -m full（CLI）はロスレス。MCP 経由のみロッシー。同じ full 指定でも経路だけ違って結果が割れる＝MCP 応答パイプライン側のバグ。
  • 修正: 6種の環境変数（LCTX_NO_DEGRADE=1、LEAN_CTX_RAW=1 等）を総当たりした結果、LEAN_CTX_COMPRESSION=off のみ有効。他は無効。MCP サーバーの env に設定し再起動が必要。
  • 教訓: 圧縮・要約系 MCP ツールの出力を「逐語の根拠」にしてはいけない。検証は別経路（native read / CLI）で。
  • upstream に Issue 起票済み（https://github.com/yvgude/lean-ctx/issues/404）。
zenn-dev-just2enough-a0f050bfd25c4d

Claude Code の handover.md を「決定ログ」にしたら開発が捗るようになった

  • URL: https://zenn.dev/just2enough/articles/a0f050bfd25c4d

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: Claude Code のセッション間引き継ぎメモ（handover.md）を素朴な情報詰め込みから「決定事項ログ（なぜ・次だけ）」に再設計した実践記録。肥大化防止の3仕掛け（git log で取れる情報は書かない・1決定4〜5行・古い決定は自動アーカイブ）と retrospective の死蔵防止設計が中心。

詳細

  • 2層構造: 冒頭ブロック（現在フェーズ＋次にやること、即作業再開用）＋参照ブロック（決定事項ログ・既知課題）。Claude はまず冒頭だけ読んで再開し、必要な時だけ参照ブロックへ。
  • 決定事項ログの書式: 連番・日付・見出し・種別・決定内容・理由（不採用案と却下理由込み）・コミット参照。「なぜ」まで残すことで再検討ループを防ぐ。
  • 肥大化防止: 「git log で取れる情報は書かない」「1決定4〜5行に制限（詳細はコミットへ逃がす）」「3件超で古い順に handover_archive.md へ退避」。
  • retrospective の死蔵問題: 書きっぱなしにせず「蒸留」で恒久ルール（~/.claude/rules/ やグローバル CLAUDE.md）に昇格させる。昇格基準は「黙って壊れる・遅れて現れる失敗」のみ。再発3回以上のテーマは即昇格検討。
  • auto memory との棲み分け: 恒久ルール→auto memory。流動的（今ホットな決定・直前の停止地点）→handover。
zenn-dev-nanananano-b8022ca6aa1cc4

Codex の MCP 導入方法整理 — config.toml / Claude Code との比較（2026年6月時点）

  • URL: https://zenn.dev/nanananano/articles/b8022ca6aa1cc4

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: Codex の MCP 設定方法（config.toml）を Claude Code との違いに触れながら整理。設定スコープ（ユーザー/プロジェクト）、stdio/Streamable HTTP の2トランスポート、codex mcp add コマンドと config.toml 直接編集の2方法を解説。CLI と IDE 拡張は同じ設定レイヤーを参照する。

詳細

  • 設定スコープ: ユーザー（~/.codex/config.toml）とプロジェクト（.codex/config.toml、信頼済みのみ）。優先順位: CLI フラグ > プロジェクト config > プロファイル config > ユーザー config > システム config。
  • stdio サーバー設定: [mcp_servers.name] テーブルに command/args/cwd を記述。環境変数は env_vars（既存環境変数を許可）か [mcp_servers.name.env]（固定値）で渡す。
  • Streamable HTTP: url を指定。--url フラグで CLI 追加。OAuth 対応あり（codex mcp login）。Bearer Token は --bearer-token-env-var で環境変数から読み込む。
  • Claude Code との主な違い: Codex は .claude/settings.json ではなく .codex/config.toml で管理。Claude Code は JSON 形式、Codex は TOML 形式。
zenn-dev-tadkud-ai-agent-environment-verification-rule

AI Agent は実装前に1コマンド打て

  • URL: https://zenn.dev/tadkud/articles/ai-agent-environment-verification-rule

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: AI エージェントの失敗は実装力より「環境前提の未確認」から始まることが多い。実装前に CLI/コンテナ/リポジトリ状態を command -v / docker ps / git status -sb / test -f で1コマンド確認するルールを定着させることで、誤判定に基づく無駄な修正を大幅に削減できる。

詳細

  • 失敗パターン3例（実体験）:
    1. Docker 未確認のまま OCI ATP と誤判断（2026-05-23）
    2. codex exec で desktop 操作系がそのまま使えると思い込み（2026-05-23）
    3. signal.alarm 未設置で hang 要因を見落とし（2026-05-19）
  • 1コマンド確認の例: command -v grok（CLI 実在確認）/ docker ps（コンテナ確認）/ git status -sb（リポジトリ状態）/ test -f ~/.grok/config.toml && ls -l（ファイル実在確認）。
  • AI エージェントでの特有リスク: 人間は「この前もここで詰まった」と思い出せるが、エージェントはもっともらしい前提の上にもっともらしい実装を積み上げてしまう。
  • 重要な運用: 確認結果を短く残す（docker ps で対象なし など1行）。会話ログに埋めず feedback_*.md に昇格させ次プロジェクトで再利用できるようにする。
  • 先に打つ1コマンドは「後で30分かけて誤判定を掃除しないための最短手順」。
zenn-dev-tottoko-hamu-2026-06-11-173500

CLAUDE.md に書いたのに守られない ── その正体は「渡す場所」の設計だった

  • URL: https://zenn.dev/tottoko_hamu/articles/2026-06-11-173500

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: 「CLAUDE.md に書いたのに守られない」問題の正体は、ルールの内容ではなく「どこに・どんな形で渡すか」の設計のズレ。Claude Code に渡せる場所を CLAUDE.md / サブエージェント / スキル / Playbook / メモリ / 設定・権限 / MCP の7レイヤーに整理した Zenn Book Vol.4（900円）の紹介記事。

詳細

  • 7レイヤーの特徴と「渡しすぎた場合の問題」:
    • CLAUDE.md: 書きすぎると AI が読まなくなる
    • サブエージェント: 分けすぎると「誰に頼むか」の判断コストが増える
    • スキル: 「あとで使うかも」で作ったスキルが積み上がる
    • Playbook: 古くなっても気づかれず誤判断の根拠になる
    • メモリ: 溜めすぎるとコンテキストを圧迫する
    • 設定・権限: 「とりあえず全部許可」が事故の入口
    • MCP: 繋ぎすぎるとツール定義がコンテキストを食う
  • 本書の核心: 「何を渡すか」と同時に「何を渡さないか」——渡しすぎないという引き算の設計。
  • 著者実績: 90個の Playbook と21件の事故記録から抽出した実運用の産物。
  • 序章無料公開。Vol.1〜3 に続くシリーズ第4巻だが単体で完結。
zenn-dev-yuhtaihara-ai-guardrails-machine-level

AI に「やるな」と書いても無駄だった — 機械で止める3層ガードレール

  • URL: https://zenn.dev/yuhtaihara/articles/ai-guardrails-machine-level

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: CLAUDE.md への禁止事項の記述は「お願い」であり確率的にしか守られない。プロンプトに書く禁止事項から「設定で物理的に塞ぐ」3層ガードレール（入口でシークレット検査・実行で可逆性判定・構造でシークレットを平文保存しない）に移行した実践報告。

詳細

  • CLAUDE.md 禁止事項の限界: LLM は指示に「確率的に」従うため 100 回に1回は破る。それが本番シークレットを漏らす1回になりうる。
  • 3層ガードレール:
    1. 入口（シークレット検査）: プロンプト送信時フックで ghp_*、sbp_*、eyJ...（JWT）、接続文字列等を正規表現検査してクリップボード貼り付けも含めて遮断。
    2. 実行（可逆性×到達範囲）: ローカル完結+git で戻せるもの→許可。ローカルだが戻せない（rm 系）→承認制。外部到達（push/PR/API 書き込み）→承認制。
    3. 構造（平文で持たない）: シークレットを OS の環境変数で管理。設定ファイルにも .env にも書かない。月1回 grep で全体監査。
  • 実際の効果: 記事執筆中に AI が rm で一括削除を試みたが第2層ガードが発動して拒否。「自分が過去に仕込んだ仕組みに今の自分が助けられた」。
  • 良いガードレールは存在を忘れる（シートベルトと同じ）のがゴール。
zenn-dev-yy7613-173404d60a6150

Fable 5 にローカル LLM で動くコーディングエージェントを作らせてた話

  • URL: https://zenn.dev/yy7613/articles/173404d60a6150

  • 日付: 2026-06-14

  • Tier: Tier 3

  • 要旨: GitHub Copilot のコスト問題を契機に、クラウド不要・月額不要のローカル LLM コーディングエージェント「lca」を Fable 5 に設計させた記録。「賢くないモデルを前提にした設計」として、オーケストレーションを LLM に任せず決定的なコードで制御する3役分業アーキテクチャを採用。※ Fable 5 は 2026/6/13 より使用不能になっており本記事は供養として公開。

詳細

  • アーキテクチャの核心: ローカル LLM の3制約（コンテキスト短い・指示に従いきらない・長い自律が不安定）を「構造で補う」設計。Orchestrator（決定的なコード）が制御し、LLM は設計/実装/レビューの判断のみ担当。
  • 3役: Architect（インターフェース契約・タスク分解）、Worker（実装・検証、役割別プロンプト合成で専門家化）、Reviewer（差分と設計の照合）。
  • 5段の承認チェーン: Reviewer → Inspector（読み取り専用、実行時バグ検出）→ Director（PLAN.md 照合）→ PlayCheck（ブラウザ機械テスト）→ Vision（スクリーンショット採点）。各段は「評価 → 修正 → 再評価」の同一パターン。
  • 重要な設計判断: 検証合否を LLM の自己申告で決めず、Architect が書いたコマンドを Orchestrator が実行して終了コードで判定。LLM が「テストが通った」と言っても机上の空論にならない。
  • 技術スタック: C# / .NET 10 / Microsoft Agent Framework / LM Studio。
Zenn Openai Acquires Ona GitpodDev Classmethod Jp 20260613 Cc Updates V2 1 177