Aurora PostgreSQL 18.3がリリースされたのでPostgreSQL 18の新機能を試してみた

• URL: https://dev.classmethod.jp/articles/aurora-postgresql-18-3-new-features/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: 2026-06-11にAurora PostgreSQLがPostgreSQL 18（18.3）をサポート。コミュニティGA（2025-09-25）から約8.5ヶ月後。roaringbitmap拡張・B-treeスキップスキャン・uuidv7()・Virtual Generated Columns・RETURNING OLD/NEW構文を実機検証。

詳細

新機能まとめ:

• roaringbitmap拡張: 32bit整数IDの集合を効率的に圧縮。積集合（rb_and）・和集合（rb_or）・差集合が使える。ユーザーセグメント管理や大量ID集合の管理に有用（CREATE EXTENSION roaringbitmap;、v1.1）

• B-treeスキップスキャン: 複合インデックスの先頭列に条件なしで後続列のみ検索可能。statusとcreated_atの複合インデックスでstatusを指定せずcreated_atだけで検索しても実行計画でIndex Scanが使われることを確認

• uuidv7()組み込み関数: 時刻単調増加のUUID v7をネイティブ生成

• Virtual Generated Columns: 値を物理保存しない計算列

• RETURNING OLD/NEW構文: UPDATE/DELETE時に変更前後の値を返す

リリースの背景: AWSは「コミュニティメジャーバージョンから8ヶ月以内」を目標としており、今回の18.3はほぼその目標通り。18.0ではなく18.3で初版提供することで、累積マイナーフィックスを取り込んだ状態での安定提供を優先。

Claude Code v2.1.173〜v2.1.175 の主要アップデート

• URL: https://dev.classmethod.jp/articles/20260612-cc-updates-v2-1-175/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Code v2.1.173〜v2.1.175（2026-06-11〜12）の変更点まとめ。新機能3件・修正13件で、モデルガバナンス強化とバックグラウンドセッション・/modelピッカーまわりの安定性修正が中心。

詳細

主要な新機能:

• enforceAvailableModels管理設定の追加（v2.1.175）: availableModels許可リストをDefaultモデルにも強制適用。ユーザー/プロジェクト設定でリストを広げられなくなる。企業でのモデル統制強化に有用
• VS Code拡張 /usage ダイアログに使用量内訳追加（v2.1.174）: キャッシュミス・ロングコンテキスト・サブエージェント、Skills/Agents/Plugins/MCP別の内訳を直近24時間・7日間で確認可能
• wheelScrollAccelerationEnabled 設定追加（v2.1.174）: フルスクリーンモードでのマウスホイールスクロール加速を無効化

主要な修正:

• バックグラウンドセッションが別セッションの ANTHROPIC_* 環境変数を引き継ぐ問題を修正
• [1m]サフィックス付きFable 5モデル名が正規化されない問題を修正
• /modelピッカーでDefaultの解決先が非表示になる問題を修正（Max/Team PremiumはOpus、Pro/TeamはSonnet、従量課金APIはOpusが表示）
• Bedrock GovCloud（us-gov-*）で推論プロファイルのプレフィックスがglobalに誤導出され400エラーになる問題を修正
• 終了時1〜2秒の待機問題（macOS/Linux）を修正

破壊的変更: なし（enforceAvailableModels有効化組織はユーザー/プロジェクト設定でのリスト拡張が不可になるため事前確認推奨）

【非エンジニアのためのClaude/ClaudeCodeシリーズ】 CoworkのScheduledを使ってみた

• URL: https://dev.classmethod.jp/articles/claude-business-use001/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude EnterpriseのCoworkにある「Scheduled」機能（Daily brief・Weekly review）を非エンジニアが試した導入記事。設問に答えるだけで毎日・毎週の業務サマリーを自動生成できる。

詳細

Scheduled機能の2種類:

• Daily brief: カレンダー予定・重要メール・当日アクションを毎日指定時刻に通知。設定は「送信時刻」と「メール要約の詳細度」の2問だけ
• Weekly review: 週次の活動ハイライト・MTG実績・来週アクションをまとめたレポートを生成

特徴:

• Skillを自作せずに初期状態で完成度が高い機能として提供
• run nowコマンドで即時生成・プレビュー可能
• 内容のカスタマイズ（追記・変更）も対応

位置づけ: 「Claudeを導入したが何から始めればいいか分からない」層への入り口として推奨。エンジニア不要で使いはじめられる。

【Claude Enterprise】Windows環境でのmanaged-settings.jsonによる挙動を確認してみた

• URL: https://dev.classmethod.jp/articles/claude-enterprise-managed-settings-json-windows-behavior/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Enterpriseのserver-managed settingsをネイティブWindows環境で検証。PowerShellツール有効化・サンドボックス設定・denyルールのエイリアス正規化など、Mac/WSL2とは異なるWindows固有の挙動を確認した実験記事。

詳細

検証環境: Windows 11、Claude Code v2.1.170〜v2.1.172、Windows PowerShell 5.1

観点1: Windows基本動作:

• /statusでEnterprise managed settings（remote）が正常配信されることを確認
• CLAUDE_CODE_USE_POWERSHELL_TOOL: "1" でPowerShellツールが有効化
• defaultShell: "powershell" で !コマンドのデフォルトシェルをPowerShellに設定
• sandbox.enabled: trueはネイティブWindowsでは利用不可。failIfUnavailable: falseで警告のみで継続
• disableBypassPermissionsMode: "disable" で --dangerously-skip-permissionsフラグを無効化

観点2: PowerShell denyルールの挙動:

• cmdlet名（Invoke-WebRequest等）のdenyルールで、エイリアス（iwr・irm）も正規化されてブロックされることを確認
• allowManagedPermissionRulesOnly: trueで、ユーザー/プロジェクト設定のallowルールでmanaged settingsのdenyを緩和できなくなることを確認

Windows固有の注意点:

• PowerShell denyルールはエイリアス名でも記述可能だが、cmdlet名のルールだけでもエイリアスが正規化されブロックされる
• Bash経路とPowerShell経路の両方をブロックするには双方へのdenyルールが必要

いまからやってみるClaude入門：Chrome拡張機能をつくってみる

• URL: https://dev.classmethod.jp/articles/claude-handson-for-beginners-chrome-extentions/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude（Web版・Freeプラン）を使ってChrome拡張機能を作る入門記事。「重複タブを1つに閉じる」拡張機能をチャットだけで完成させ、セキュリティ確認もClaude問い合わせで対処。

詳細

制作物: 重複して開いているChromeタブのうち1つだけを残して他を閉じる拡張機能

学べること:

• 生成AIへの依頼の書き方（目的・入力・期待出力を明確に）
• Claude生成コードのセキュリティ確認方法（外部通信の有無を質問）
• Chrome拡張のインストール手順（開発者モード→ドラッグ＆ドロップ）

著者の工夫: セキュリティ観点で「外部通信はするか？」をClaude自身に質問し、付与権限（tabs）の根拠も確認した上で採用判断

モデル選択に関する記述: 記事内でモデル選択画面として「Sonnet 4.6」が表示されており、Freeプランのデフォルトがこのモデルであることを言及

位置づけ: Freeプラン・Web版で完結する非エンジニア向け入門。成果物が即使えるChrome拡張なので達成感が得やすい。

DevRev: AI ナレッジ管理に必要なのはガベージコレクタかもしれない

• URL: https://dev.classmethod.jp/articles/devrev-ai-knowledge-garbage-collector/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: AIに食わせるナレッジにも「寿命」があり、古い情報が残るとGarbage In, Garbage Outで回答品質が下がる。DevRevはナレッジを所有者・状態・公開範囲を持つ管理対象として扱える「ガベージコレクション的な実行基盤」として機能する、という考察。

詳細

問題の本質:

• RAGやAIエージェントで回答品質が下がる原因の一つは「古い情報が残り続けること」
• AIナレッジ管理では到達可能性（GCの指標）だけでなく、「今も正しいか」「誰が責任者か」「顧客に見せていいか」「他情報と矛盾していないか」という多次元の判断が必要

DevRevの特徴:

• Knowledge Base/Articleにより、ナレッジを所有者・状態・公開範囲・関連製品情報を持つ管理対象として扱える
• AI参照情報に「現在の正式情報かどうか」「顧客向けか社内向けか」のスコープ制御が可能

比喩の限界（著者自身が言及）:

• DevRevは「自動でゴミを収集する」GCではない
• どの情報を正式とするか・誰が更新責任を持つか・どう退役させるかは人間の判断が必要
• DevRevは「責任を持つべき情報を扱いやすい場所に置くための基盤」

実務への示唆: 外部ツールとの接続だけで解決しようとしても、接続後のナレッジの寿命管理という問題は残る。ナレッジ管理基盤の選定では「接続できるか」より「情報の状態管理ができるか」が重要。

Amazon BedrockでGemma 4 31Bが利用可能になったので、日本語要約力を試してみた

• URL: https://dev.classmethod.jp/articles/gemma-4-31b-bedrock-mantle-japanese-summarization/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Gemma 4 31BがAmazon Bedrock（bedrock-mantleエンドポイント）で利用可能に。入力$0.14/1Mトークンと格安で、Claude Sonnet 4.6の21倍安。日本語要約タスクでの実測では文字数制限遵守や品質に課題あり。

詳細

Gemma 3 27B → Gemma 4 31B 主な差分:

• コンテキスト長: 128K → 256K
• 入力モダリティ: テキスト+画像 → テキスト+画像+動画
• Reasoning・Function calling: なし → 組み込み対応

Bedrockでの注意点:

• bedrock-mantleエンドポイント専用（bedrock-runtime InvokeModel/Converse API非対応）
• ReasoningはResponses APIでのみ確認可（Chat Completions APIでは返らない）
• 並列tool call非対応

価格比較（us-east-1 on-demand、執筆時点）:

日本語要約検証結果:

• 文字数制限（200字以内等）を守れないケースあり
• 文体・構成は自然だが、指定遵守の安定性はClaude系より低め
• 低コスト用途（下書き生成・大量バッチ）には適する

KiroにPro Maxプランが追加、損益分岐点はどう変わる？4プラン体制でコスト最適化を再試算してみた

• URL: https://dev.classmethod.jp/articles/kiro-pro-max-breakeven-update/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: body: FETCH_FAILED

Kiro Web の Build with Spec で Spec 作成から PR・レビュー対応まで試してみた

• URL: https://dev.classmethod.jp/articles/kiro-web-build-with-spec-workflow/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: 2026-06-11にKiro WebにBuild with Specが追加。ブラウザ上でSpec作成→タスク実行→PR作成→レビュー対応まで完結する。実機検証では16タスクを4分14秒で完走し、/kiro fixでPRレビューの自動対応も確認。

詳細

検証内容: VPC Flow LogsのCloudWatch Logs Insightsクエリチートシート作成（GitHub: cm-suzuki-ryo/cloudwatch-logs-query-skill）

ワークフロー:

1. Clarifying Questions（4問）→ Requirements（8件）→ Design（7コンポーネント）→ Tasks（16タスク、Wave 0〜5）を自動生成
2. 全16タスクをWave順に実行、4分14秒・940行追加でPR作成
3. /kiro fixでPRレビューコメント（3件）を自動対応（3分27秒・クレジット1.64消費）

実環境で発見された問題:

• チートシートでハイフン区切り+バッククォート（next-hop-az-id）と記述したフィールドが、CloudWatch Logs Insightsではキャメルケース（nextHopAzId）でないと認識されずispresent()が常に0を返した
• ispresent()は"-"が格納されたフィールドにもtrueを返す（!= "-"の条件追加が必要）

評価: IDE版相当の機能がブラウザで完結。ローカル環境セットアップ不要。ただし実環境での動作確認はまだ人間が必要。

MLX Whisperのv3-turboの8bit量子化モデルを動かしてみる

• URL: https://dev.classmethod.jp/articles/trial-mlx-whisper-v3-turbo-asr-8bit/
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: mlx-communityのwhisper-large-v3-turbo-asr-8bitモデルをmlx-audioライブラリで動かす手順。ファイル生成を避けるためモデルのgenerate()を直接呼ぶ方法と、アプリ組み込み向けのコード例を紹介。

詳細

使用モデル: mlx-community/whisper-large-v3-turbo-asr-8bit（mlx-audio開発者作成版）

基本的な使い方（mlx-audioライブラリ経由）:

from mlx_audio.stt import load_model
from mlx_audio.stt.models.whisper.whisper import Model, STTOutput

model: Model = load_model("mlx-community/whisper-large-v3-turbo-asr-8bit")
result: STTOutput = model.generate(
    audio="path_to_audio.wav",
    language="ja",
    word_timestamps=True,
)

注意点:

• モデルカード記載のgenerate_transcription()はoutput_pathにファイルを強制生成する（format=""で回避可能だが非推奨）
• アプリ組み込みにはモデルの.generate()を直接呼ぶ方法が適切
• 日本語文字起こしに対応、word_timestamps=Trueで話者識別用のタイムスタンプ取得可能

2026年6月の更新プログラム適用後にエクスプローラーからOneDriveにアクセスできなくなる問題について

• URL: https://jpwinsup.github.io/blog/2026/06/12/Shell/Explorer/OneDriveIsNotAccessibleFromExplorerAfter202606Update/
• 日付: 2026-06-12
• Tier: Tier 1
• 要旨: Windows 11 24H2/25H2 に2026年6月の更新プログラム（KB5094126）を適用後、エクスプローラー左ペインのOneDriveアイコンがクリック不能になる不具合。Microsoftが公式ブログで報告し、修正対応中。

詳細

Windows サポート担当の八木氏によるMicrosoft公式発表。

対象バージョン: Windows 11 version 24H2 および 25H2（他バージョンは確認中）

事象: KB5094126適用後、エクスプローラー左ペインのOneDriveアイコンをクリックしても反応せずOneDriveの内容を参照できない

現状: 開発部門で修正対応中。新情報はブログで公開予定

回避策:

• エクスプローラー右ペインから C:\Users\<UserName>\<OneDrive> を直接参照
• ブラウザからオンラインでOneDriveにアクセス

AIエージェントに渡す仕様書の書き方──巨大な依頼を壊さず小さく渡す

• URL: https://zenn.dev/aiwatch_jp/articles/agent-flow-spec-writing
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude CodeやCodexへの依頼では「何をプロンプトに書くか」よりも「仕様の渡し方」が重要。作業境界を明確にする8項目フレームワーク（目的・非目的・背景・変更範囲・入力文脈・受け入れ条件・テスト条件・停止条件）を提案。

詳細

核心の考え方: 仕様書は「命令文」ではなく「作業境界を作る文章」

8項目フレームワーク:

1. 目的: 誰のどの場面を良くするのか
2. 非目的: 今回やらないことを明示（エージェントが推測で勝手に実装することを防ぐ）
3. 背景: コードベース・設計の文脈
4. 変更範囲: どのファイル・モジュールに触ってよいか
5. 入力文脈: エージェントが見てよい情報
6. 受け入れ条件: 完了の定義
7. テスト条件: 何でどう確認するか
8. 停止条件: 不明点が出たらどこで止まるか

悪い依頼の例:

商品一覧に検索機能を追加してください。

→ 検索対象・実装場所・URL反映・テスト方針・触ってよいファイルが全部曖昧

良い依頼の例（一部）:

商品一覧で、商品名の部分一致検索を追加する。
今回はやらない：SKU検索・検索履歴・サジェスト
維持する挙動：categoryフィルタ・statusフィルタ・pagination

「非目的」の重要性: 境界を明示しないと、エージェントは「それっぽい答え」を作りに行き、速く間違える。非目的を書くことで推測による範囲外実装を防ぐ。

実装前の思考順序: 誰のどの場面→入力→出力→正常系→失敗系→今回やらないこと→テスト確認方法の順で固めてからプロンプトを書く

Claude Codeに長期記憶を持たせる4層アーキテクチャ — 「毎回ゼロから説明」をやめた話

• URL: https://zenn.dev/bokuwalily/articles/f534402187bd07
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Codeのセッション間健忘問題に対し、記憶を「生ログ・揮発バッファ・確定事実・人間向けWiki」の4層に分けて一方向フローで管理する設計を実装・運用した実践記録。Stop hookでの自動ログ変換や落とし穴も詳述。

詳細

4層アーキテクチャ:

原則: 下流は上流を上書きしない。食い違いは層(1)に照らして修正。

実装のポイント:

• Stop hookでJSONL→Markdown変換（tool_resultは捨てる、セッションIDをファイル名に含める）
• 層(3)はMEMORY.mdを索引にして1トピック1ファイル。腐らない情報のみ
• 層(4)のhot.mdはLLMを呼ばずに正規表現でマーカー領域に直近10セッションの表を注入（コストゼロ）

落とし穴:

• macOSのTCC問題: launchd配下でPython/git/claudeバイナリが~/Documents等の保護領域に書けない（Full Disk Access要）。解決策: Vaultを保護領域の外に移設してsymlink
• recent.mdの二重化: LLM用（~/.remember/recent.md）と人間用（Obsidianのhot.md）は読み手が違うだけで統合しない方が良い
• パイプライン死活監視: now.mdに同一要約3回以上→consolidate遅延、索引が24時間以上古い→変換hook停止の疑い

結論: 記憶の「種類」（生ログ/揮発文脈/確定事実/人間知識）を分けて層ごとに書き手を固定することが健全な長期記憶設計の核心。

「2倍払えば 2倍速い」は本当か——Claude Code の fast モードを QCD で実測した

• URL: https://zenn.dev/nnakapa/articles/lab-25-opus48-fast-mode-qcd
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Code（Opus 4.8）のfastモードをQCD（品質・コスト・処理時間）の3軸で実測。処理時間は約1.9倍速（xhighで2.34倍）、コストはほぼ2倍、品質は変化なし。「短縮1時間≒$40」で時間を買う構造。夜間バッチには不要。

詳細

検証環境: Raspberry Pi 5 / Ubuntu 26.04 / Claude Code v2.1.168 / Opus 4.8 [1m] / 計240試行

結果サマリー:

なぜ「2.5倍」にならないか: 公称2.5倍はOTPS（出力速度）。pytest実行・ファイル編集等のツール実行時間はfastでも速くならない。effort levelが高いほど生成時間の比率が大きくなりfastの効きが強くなる

コスト計算: 短縮1分≒$0.66、短縮1時間≒$40。画面の前で待っている人間の時給が$40以上なら黒字。夜間バッチ・放置ジョブはfast不要

品質: medium以上では標準・fastとも品質変化なし（T2通過率100%）。品質を落とさずに速くできる

落とし穴: 120試行中2件でfastが無言で標準モードにフォールバック（理由不明）

Claude Code 実践運用ガイド — 個人開発を無人化する

• URL: https://zenn.dev/shoebill_dev27/books/claude-code-ops
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Codeを「補助ツール」から「無人で回る開発・運用基盤」に変えるための有料実践書（¥1,200・約5.5万字）。CLAUDE.md設計・権限安全設計・スキル/フック/スケジュール実行・マルチエージェント・トークン経済・失敗パターン集を網羅。コード例は実行検証済み。

詳細

章構成:

1. なぜ「運用」なのか
2. CLAUDE.md設計 — エージェントの憲法を書く
3. 権限・サンドボックス・安全設計
4. スキルとスラッシュコマンド
5. フック・cron・スケジュールエージェント
6. サブエージェントと並列ワークフロー
7. モデル選択とトークン経済
8. 失敗パターン集と回復手順

書籍の特徴:

• コード例はビルド時に実行検証済み
• 個人開発の「無人化」という具体的なユースケースを前提
• 失敗パターン集が含まれる実践寄りの内容

※本記事はZenn Bookの概要ページのため詳細内容は有料。

Claude Code が存在しないファイルを「作成した」と報告し続けた — ツール結果の作話（confabulation）が起きた条件

• URL: https://zenn.dev/wharfe/articles/claude-code-tool-result-confabulation
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Codeが「ファイルを作成した」「接続を確認した」と報告するが実際には何も存在しないという「ツール結果の作話」が発生した条件を詳細に分析。書き込み系は作話・読み取り系は本物という非対称な分布が観測され、3つの罠の重なりで発生することを解明。

詳細

症状: ラッパースクリプト作成・引き継ぎドキュメント作成・MCP接続確認・メモリ保存をすべて「成功」と報告するが、実際には存在しない。最終的にモデル自身が「私の捏造が混じり実機状態が未確定」と認識してセッション終了。

観測された非対称性:

メカニズム:

• ファイル書き込みの成功メッセージはFile created successfullyのように返ってくる文面がほぼ一択（低エントロピー）→ モデルが結果を待つ前に「それっぽい続き」を書けてしまう
• grepのヒット数は何が返るか分からない（高エントロピー）→ 先回り動機が弱い

今回の3つの罠:

1. 対話型CLIとの衝突: agent-cliがTTY前提の対話プロンプトを出す設計で、TTYのないエージェント実行環境ではAborted (no TTY)等の曖昧な出力が続き「ground truthが確定しない」状態が続いた
2. 目で見えない状態: MCP接続状態はlsで見えず、間接的なコマンドで確認するしかない→モデルが脳内モデルを持ち続け、外部からの確定情報なく現実からズレた
3. 高度に生成的なモード: 長い論考（自律性の議論）の後に操作ステップへ突入→操作の結果まで「流暢に」書いてしまう

自己強化ループ: 最初の偽の前提（「ラッパーは在る」）が会話履歴に入ると、後続全ステップがそれを真として積み上がり、作話が相転移的に集中する

普段のコーディングで起きない理由: git/pytest/ファイル編集は（1）結果が一意（緑か赤か）、（2）状態が目視できる、（3）散文的でない——という3条件がすべて欠ける

Claude Codeに永続記憶を自作した — Tsuzuri for Claude Code

• URL: https://zenn.dev/rizzai/articles/ac3f930ae252e3
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Codeのセッション間健忘問題に対し、ローカル完結・無料・日本語対応の永続記憶システム「Tsuzuri」を自作。SQLite+Claude Code hooksで会話を自動保存・自動注入。日本製埋め込みモデル（Ruri）でオフラインの意味検索も実現。

詳細

既存ツールの不満点（著者の場合）:

• 日本語検索精度が低い（英語前提のトークナイザ）
• API課金が発生（mem0・Letta・Zep等）
• クラウドへのデータ送信がある

設計の3原則:

1. ローカル完結（SQLite保存・Ollama意味検索）
2. 無料（API課金なし・標準ライブラリ中心）
3. インストール後は何もしなくていい（hooksで自動化）

仕組み（hooks）:

• UserPromptSubmit/Stop hook → 会話をSQLiteに自動保存
• SessionStart hook → 要約を自動注入

2層メモリ:

• Tier1（常時注入）: handoff.md（引き継ぎ）・project-state.md（恒久情報）
• Tier2（検索時）: 過去の生ログをSQLite FTS5で全文検索

工夫1: blob分離で検索精度向上

• 会話テキストとコード/ログblobを分離
• 意味検索の埋め込み対象は会話テキストのみ（コードはFTS5で検索）

工夫2: 生ログを構造化メモリに蒸留

• 決定事項→decisions.md、バグ修正→bugs-and-fixes.mdに整理
• 内容ハッシュで重複を自動スキップ

工夫3: 日本語意味検索（オプション）

• Ollama + kun432/cl-nagoya-ruri-large（日本製・Apache-2.0）でローカル実行
• FTS5（キーワード）と埋め込み（意味）をRRFで融合したハイブリッド検索
• Ollamaなしでも動作（FTS5のみにフォールバック）

CodexがDevToolsの中まで見てくれる！新機能Developer mode（CDP）でブラウザデバッグを実測してみた

• URL: https://zenn.dev/lnest_knowledge/articles/codex-developer-mode-cdp
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Codex app 26.609（2026-06-11）で追加されたDeveloper mode（CDP）により、Codexがconsole log・network traffic・runtime error・DOM stateをChrome DevTools Protocol経由で直接確認できるようになった。実測でconsole.info・404 fetch・TypeErrorの捕捉を確認。

詳細

従来のBrowser useとの差:

• 従来: ページを開いて・クリックして・DOMを見て・スクショを撮る
• Developer mode: DevTools的に「なぜその状態になったのか」まで調べられる

確認できるようになったもの（公式）:

• console output（console.log等）
• network traffic（リクエスト/レスポンス）
• DOM state / applied styles
• JavaScript profiling（performance trace）
• runtime errors

実測結果:

• console.infoの構造化ログ: 内容・発生ファイル（app.js:50等）まで取得
• 404 fetchのエラー: Error: HTTP 404 for ./api/not-found-*.jsonまで確認
• TypeError: キャプチャされてconsole errorとして残る
• DOM state（window.__MIY53_DEBUG_STATE__）の値: Codexが確認できることを実測

実務への示唆:

• 「エラー表示になっています」（スクショ）→「console errorとfailed requestを確認して原因と修正候補を出して」（CDP）という依頼に変わる
• CodexがDevTools調査ペアとして機能するようになる

注意点:

• Full CDP accessはブラウザ内部のセンシティブな情報へのアクセスが可能。Codexが使用前に明示承認が必要
• ログイン済み業務画面・個人情報を含む画面では取得対象を最小限に絞る
• minifiedビルドではファイル・行番号の精度が落ちる

AIエージェントの多段ワークフローを「1つのYAML」で宣言的に動かす — flowsmith の設計

• URL: https://zenn.dev/kikaikaya/articles/flowsmith-declarative-ai-workflow
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: Claude Code向けのワークフローエンジン「flowsmith」の設計記録。「セッション途中死で全やり直し」「LLMの自己申告合否が信用できない」「コストが見えない」という3つの問題に対し、宣言的YAML・機械ゲート・状態のディスク永続化で解決。レガシー調査15ステップを35分で完走した実績あり。

詳細

解決した3つの問題:

1. セッション死で全やり直し → 状態をディスクに置き、ステップ・行単位で記録して再開
2. LLMの合否が信用できない → 合否判定をYAMLルールで機械適用（LLMに決めさせない）
3. コストが分からない → run.jsonlで全ログ（所要時間・トークン）を記録

設計判断1: 合否をLLMに決めさせない

• checkerが返すのは観点ごとの構造化判定（{id: V01, verdict: pass}）のみ
• 総合合否はエンジンがpass_when: no_high_fail等のルールを機械適用して決定
• さらに機械ゲート（ファイル存在確認・必須見出し・行数チェック）を先に走らせ、落ちたらLLMレビューに進ませない

設計判断2: 状態をディスクに永続化

• state.jsonをステップ・行単位で更新
• 再実行時は完了分をスキップして続きから再開
• 200件処理の150件目で死んでも残り50件だけ再開可能

設計判断3: 行き詰まったら止まる（seized）

• 推測で進まず、「どの観点が・何回・どんな根拠で通らなかったか・人間の選択肢は何か」を出して裁定を人間に返す
• 上限を超えた反復は必ずseizedになる（無限ループが構造的に存在できない）

面白いバグ: 差し戻しの誤読

• 不合格理由を「あるべき姿の説明」と誤読して「変更不要」と返してくるケースが発生
• 解決: 「上記は『解消すべき不足』であり『現状の説明』ではない。変更不要は禁止」と明示することで安定

教訓: マルチエージェントの結合部では、情報の「内容」だけでなく「フレーミング」が動作を決める

MCPは接続数よりprotocol watchを先に固定する

• URL: https://zenn.dev/tadkud/articles/mcp-protocol-design-principles
• 日付: 2026-06-12
• Tier: Tier 3
• 要旨: MCP運用では「接続数」を進捗指標にすると設計判断がぶれる。先に固定すべきはroots/prompts/resources/tools/elicitationのどれを使うかという判断基準と、仕様変化の追い方（protocol watch）。samplingへの新規依存は避け、週次レビューで監視観点を統一することで運用が安定した実践報告。

詳細

2026-05-31に行った変更の背景:

• 週次レビューで見えた差分を基に、AI-AGENT.md・AGENTS.md・runtime-capabilities.json・運用skillを更新
• ADR ADR-2026-05-31-mcp-protocol-watch-and-design-principles.mdに判断を記録

AI-AGENT.mdに追加したguidance:

新規MCP設計・追加・評価では
roots / prompts / resources / tools / elicitation を優先し、
sampling 前提の新規依存は避ける

有効だった判断基準:

• transport（stdio/HTTP）が違っても監視観点は共通化できる
• 新規MCP追加前に「既存plugin/Browser/CLI/Docs MCPで代替できるか」を確認する習慣で接続増殖を抑制
• Google Drive/Gmail/Calendar/Slackはpluginでcovered、一部のみpartialと整理済み

samplingを避ける理由: 便利そうでも新規依存の前提にすると運用が不安定になる（実経験に基づく）

protocol watchの効果: MCPを「増設タスク」ではなく「前提管理タスク」として扱えるようになり、週次レビューで見るべき差分が減少

OpenAIがOna(旧Gitpod)を買収へ。コーディングエージェントの主戦場は実行環境に移った

• URL: https://zenn.dev/okssusucha/articles/20260613-openai-acquires-ona-gitpod
• 日付: 2026-06-13
• Tier: Tier 3
• 要旨: OpenAIが2026-06-11にOna（旧Gitpod）の買収合意を発表。目的はCodexエージェントの「customer-controlled execution」モデル確立。エージェントの頭脳をOpenAIが、サンドボックスを顧客VPCに置く分担でエンタープライズ参入障壁を下げる。Gitpodという人間向けCDEが、エージェント向けに化けた転換点として分析。

詳細

買収の目的:

• Codexエージェントを企業本番ワークフローに入れ込むための実行レイヤー獲得
• customer-controlled executionモデル: モデル/オーケストレーションはOpenAI提供、サンドボックスは顧客自身のクラウドに置く
• Codexは週500万人以上が使用、年初比400%増とのOpenAI発表

Gitpod/OnaのCDE→エージェント基盤への転換:

• 2025年9月リブランド（Gitpod→Ona）「ソフトウェアエンジニアリングエージェントのミッションコントロール」を標榜
• 2025年10月Gitpod Classicの従量課金終了
• エージェントセッション数が2026年初から13倍増、銀行・製薬など規制業界に参入
• 人間がCDEを嫌った理由（レイテンシ・ローカルツールへの愛着）をエージェントは一切気にしない。CDEの強みだった再現性・スコープ制御・監査証跡はエージェント運用の必須要件になった

技術スタック（Ona）:

• 環境定義: 標準のDev Containers仕様（devcontainer.json）
• エージェント指示: AGENTS.md
• 実行先: Onaマネージドクラウドまたは自社AWS/GCP VPC内のセルフホストRunner
• トリガー: PRイベント・Linearアサイン・スケジュール・Webhook

ローカル実行 vs Ona型（VPC内サンドボックス）比較:

著者の見立て: OnaはCodexへの統合が本線でスタンドアロン製品は緩やかに収束する。「どのモデルが賢いか」ではなく「エージェントをどこでどんな権限で走らせるか」が競争の主戦場になった。Dev Containers+AGENTS.mdというベンダー中立の資産への投資は将来の乗り換えにも有効。