コンサルタントを入れたのに、現場が苦しくなるのはなぜか

• URL: https://blog.cloudnative.co.jp/articles/consultant-genba-kurushikunaru-naze
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: コンサルタント支援が現場で機能するかは資料の完成度ではなく、経営層だけでなく現場担当者との対話の有無・顧客課題の言語化・運用定着までの伴走で決まる。成功体験に固執して顧客最適から提供側最適へ寄るコンサル、問診を飛ばして得意分野の解法を当てはめるコンサルは、導入方針までは進んでも運用段階で破綻する。見えやすい違和感は、課題把握より解決策説明が先行・顧客の事情より過去事例が中心・他社事例再現に寄りすぎる提案。現場を含めて高解像度で見てくれるパートナーか、誰との対話で提案を合わせているかが長期的価値を左右する。

詳細

外部コンサルタント導入が現場で苦しくなる理由は経営層とだけの接点に起因。経営層との対話に偏ると、提案は抽象化し現場の制約・運用困難・例外処理が見えず、資料は立派でも実行段階で無理が出る。同時に、強い成功体験は顧客課題を見る前に「既知の解き方が通じるはず」という発想に陥らせ、本来の顧客最適から提供側最適へ寄りやすい。見え方の違和感は特定の解決策説明が課題把握より先行する、顧客の事情を聞く時間が過去事例の時間より短い、他社でうまくいった事例が自社固有の前提より優先される、提案が顧客の優先順位よりコンサル側の得意分野に寄ることで観察できる。対照的に現場に届きやすい支援は現場担当者との直接対話、課題と制約を整理してから打ち手を決定、導入後の運用まで含める、話した内容が提案や運用に反映される形。外部パートナー評価では肩書きや過去実績より、誰の話を聞き誰に提案を合わせようとしているか、現場まで含めた高解像度理解を重視すべき。

AIコーディング支援が「攻撃の永続化経路」になる時代｜npmワーム Shai-Hulud / Mini Shai-Hulud に学ぶ開発者端末・CI/CD・シークレット防御2026

• URL: https://blog.cloudnative.co.jp/articles/npm-supply-chain-worm-shai-hulud-mini-2026
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: npmワーム Shai-Hulud と亜種 Mini Shai-Hulud は、OIDC トークン悪用により正規ビルドパイプラインを乗っ取り、SLSA Build Level 3 の正当な証跡まで付与した悪性パッケージを公開する初の事例。パッケージ非公開企業でも攻撃対象は開発者端末と CI/CD に露出したシークレット（クラウドキー・PAT・Claude Code 設定など）。SLSA や SBOM があっても安全とは限らない。対策は侵害前提での予防的シークレット・ローテーション、Action 参照の SHA 固定、OIDC/短命認証への移行、インストール時のランタイム監視。AI コーディング支援の設定ファイル保護と MCP 接続の棚卸しが新たに必須。

詳細

Shai-Hulud は 2025 年 9 月初出現の自己増殖型 npm ワーム。500 超パッケージ・700 超リポジトリに波及後、2026 年 5 月の TanStack 侵害では GitHub Actions 設定ミスを突いて OIDC 公開エンドポイントを乗っ取り、正規ビルドプロセスで生成された悪性パッケージに正当な SLSA Build Level 3 証跡（Sigstore 発行）を付与する初の事例となった。このとき @tanstack/react-router 週 1,270 万ダウンロード、計 npm 170 超・PyPI 2 パッケージ・404 悪性バージョンで、npm と PyPI を同一作戦で同時侵害した初事例。5 月 12 日にソース公開後、模倣犯と派生（Miasma 系）が増殖。6 月には Red Hat npm 配下 32 パッケージ侵害（Miasma）、node-gyp binding.gyp 悪用（Phantom Gyp）と高度化継続中。攻撃の起点は認証情報窃取で、窃取対象は AWS/GCP/Azure キー、npm/GitHub トークン、CI/CD シークレット、Kubernetes・Vault 資格、SSH 鍵に加え、Claude Code 設定ファイル（/.claude.json、/.claude/mcp.json 等）を含む。OpenAI でも従業員端末 2 台が TanStack パッケージ経由で侵害される実被害。SLSA/SBOM は「来歴の正しさ」を保証するもので「コード安全性」ではなく、preinstall 無効化は binding.gyp などライフサイクル外へ攻撃点が移行済み。防御は侵害前提で、速く無効化・再発行できる設計。優先順位は、最優先が CI/CD 露出シークレットの棚卸しと予防的ローテーション、高優先が Action SHA 固定・pull_request_target 点検・OIDC/短命認証への移行、中が ランタイム監視・AI 支援設定保護。

取引条件に「セキュリティ格付け」が入る時代｜経産省 SCS評価制度（★3・★4）を情シスが制度開始前に準備する実務 2026

• URL: https://blog.cloudnative.co.jp/articles/scs-security-rating-2026
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: 経産省が2026年3月27日に公表したSCS評価制度は、サプライチェーン企業のセキュリティ対策を共通基準で可視化する制度。★3は専門家確認付き自己評価で一般的脅威への最低限対応、★4は第三者評価で被害拡大防止・取引先保護を含む包括的対応。要求事項はNIST CSFに沿うため既存ISMS・Pマークとの地続き再利用が可能。制度開始前に資産・取引先・外部サービスの棚卸し、既存制度とのギャップ分析、証跡運用の仕組み化を着手すべき。今後取引条件に組み込まれる見通しのため、早期の現在地測定が遅延防止の鍵。

詳細

SCS評価制度は経産省・内閣官房が監督しIPAが運営し、2026年度末頃の制度開始目指す。★3は一般的脅威対処の基礎水準で専門家確認付き自己評価、★4は被害拡大防止・取引先保護を含む標準水準で評価機関による第三者評価及び技術検証が前提。★5は未知攻撃対応で検討中。★3は約26項目、★4は約43項目（確定値は秋の評価ガイド待ち）。上位段階は下位を包括するが取得前提条件ではない。現時点で取得は義務ではないが、政府調達・重要インフラサプライチェーン企業では取引要件化が見込まれる。NIST CSFに沿った要求事項のため既存ISMS・Pマーク・SECURITY ACTIONの成果物をマッピング直接で再利用可能。情シスの実務影響は、受注側として評価対象、発注側として取引先評価要求、いずれにせよ資産棚卸しと証跡継続運用。実務論点は対策の有無より運用エビデンスの継続性、外部SaaS・OAuth連携の台帳追従、手作業依存の削減。取引先管理と外部サービス把握が評価要件に含まれ、見落としやすい。中小企業向けにお助け隊サービス新類型と改訂ガイドラインで支援。

【非エンジニアのためのClaude/Claude Codeシリーズ】Claude活用におけるAI RMFチェックシートを作ってみた

• URL: https://dev.classmethod.jp/articles/AIsecurity
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: NIST AI RMF（AIリスク管理フレームワーク）に基づく全63項目のチェックシートを作成。米国立標準技術研究所が策定したガイドラインで、Govern（統治）、Map（特定）、Measure（測定）、Manage（管理）の4つのコア機能で構成。Governは19項目（方針・手順整備、責任体制、多様な視点、リスク文化、外部意見、外部サービス管理）。チェックシートの成熟度は5段階評価（未整備→一部整備→組織的運用→定量的管理→最適化・先進的）。AI活用とセキュリティリスク管理は対立ではなくセット。法的強制力はなく「AI活用を見直すための型」として機能。

詳細

ClassMethod営業谷口氏によるNIST AI RMFの実践的活用提案。営業活動で聞かれるAI活用リスク（情報漏洩、ハルシネーション、シャドーAI、個人の無許可利用）に対応するためチェックシートを導入。AI RMFは米国立標準技術研究所が策定。4機能の構成：①Govern（19項目）＝方針・手順整備・責任体制・多様な視点・リスク文化・外部意見・外部サービス管理、②Map（18項目）＝利用目的・AI特性把握・効果とコスト・外部リスク・影響範囲、③Measure（14項目）＝評価方法設計・品質特性評価・継続監視、④Manage（12項目）＝対応計画・継続管理・外部サービス管理・関係者情報提供。成熟度5段階評価で現在地把握。Governの例：法律規制洗い出し・品質要件への組み込み・リスク対策判断基準・定期モニタリング計画・AI台帳管理・利用終了手順。チェックシート利用で「ガイドラインはあるが台帳管理していない」などの抜け漏れを可視化。評価サマリーシートで機能ごと対応率の自動集計。

AWS Amplify のビルドが IAM ロール数クォータ上限（1,000）に到達して失敗したので Service Quotas で引き上げた

• URL: https://dev.classmethod.jp/articles/amplifygen2-deploy-limit-iamrole
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: AWS Amplify Gen2 でブランチ自動デプロイを有効化し feature ブランチが増えるとIAM ロール数が増加し、アカウントのクォータ上限（デフォルト1000）に到達するリスクがある。検証環境では amplify- プレフィックスのロール262個を含む合計999個に達していた。Service Quotas でクォータ値を2000に引き上げるリクエストを送信すると、最大値10000の範囲内であれば数秒で自動承認される。

詳細

Amplify のビルドエラーから RolesPerAccount クォータ上限到達が原因と判明した。IAM はグローバルサービスであり、Service Quotas での確認は東京リージョンではなく米国東部（us-east-1）で実施する必要がある。

ブランチごとにロールが自動生成される設定では、不要なブランチをクリーンアップしないまま運用を続けるとクォータに接近する。棚卸し（削除）による対応も選択肢だが、引き上げリクエストも検討する価値がある。クォータ値引き上げの最大値は10000で、その範囲内は自動承認されるため申請から承認まで1秒程度で完了する。

Lambda MicroVMsのIdle Policy（自動サスペンド・レジューム・ターミネート）を検証してみた

• URL: https://dev.classmethod.jp/articles/aws-lambda-microvms-idle-policy-auto-suspend-resume-terminate
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Lambda MicroVMsのidlePolicyで自動サスペンド・ターミネート・レジュームを実装。maxIdleDurationSeconds（アイドル超過）、suspendedDurationSeconds（ターミネート超過）、autoResumeEnabled（自動レジューム）パラメータで状態遷移制御。実装検証で設定値どおりの動作を確認、自動レジューム時間は2.6秒で許容レベル。

詳細

idlePolicyは状態遷移RUNNING→SUSPENDED→TERMINATED、autoResume有効時はSUSPENDED状態のリクエストで自動レジューム。検証環境でFlask + gunicornアプリを用意し、ライフサイクルフック（ready/run/suspend/resume）でイベント記録。実装結果：自動サスペンド約60秒（設定どおり）、アイドルタイマーはリクエスト毎にリセット、自動レジューム3回計測で2.6秒（ばらつき8ms以内）、自動ターミネート約116秒（設定120秒）。autoResumeEnabled=falseではSUSPENDED時のリクエストに即座に502返却。メモリ上のアプリ状態（リクエストカウンタ・イベントログ）がサスペンド・レジューム間で保持される。フックパスはfull path必須（短縮パス不可）、フックポートはTLS→プレーンHTTPの順で試行、readyフック必須。採用時はレジューム時間がユーザー体験として許容可能かが判断ポイント。

【ブースレポート】 活気あふれる 「Startup Zone」 に訪れてみた

• URL: https://dev.classmethod.jp/articles/aws-summit-japan-2026-startup-zone-booth-report
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: AWS Summit Japan 2026会場の「Startup Zone」ブースレポート。Hall 7に位置する展示エリアで、AIファーストなスタートアップとのマッチングを促進。Unicorn Stopではビジネス課題をQRコード入力するとAIスタートアップが97%スコア付けで提示（実例：CSPM）。Ask a Startup Expertは支援プログラムAWS Activateの相談コーナー。展示企業はVOiSiNG、DubGuild、InfiniMind、JITERAなど音声・ロボティクス・GPU基盤技術。体験型「Agentic Football Cup」ではAIエージェント指示ゲーム。Startup Spotlight Theaterステージは満席。

詳細

ClassMethodおつまみ氏による AWS Summit Japan 2026 Startup Zone現地レポート。テーマ「AWSスタートアップと繋がって事業をスケールさせよう」。3つのコンテンツ構成：①リアルなAWS活用事例、②体験・マッチング、③ミニシアターセッション。Unicorn Stopではピンクグラデーションサイン、QRコード読込で課題入力→マッチング提示（Cloudbaseが代表例：クラウド設定ミス検出CSPM）。ミーティング予約またはマッチングやり直し可能。Ask a Startup Expertはディスプレイでプログラム情報提示。出展スタートアップ詳述：EC2 P5インスタンス活用の外科特化型AI、ECS on FargateとAurora・Redshiftの分析基盤、音声言語モデルAPI。体験型「Agentic Football Cup」ではプレイヤー直操ではなく「指示で動かす」ゲーム（2-1勝利、ステッカー配布）。Startup Spotlight Theaterは20分前後ショートセッション、「五本指ロボットAI」「音声基盤モデル」「AWS×Genspark マルチAIエージェント」などテーマ。立ち見出るほど盛況。次セッション案内ディスプレイで利便性向上。

【AWS Summit Japan 2026】クラスメソッドが展示ブースに出展します！〜見どころやノベルティをご紹介〜

• URL: https://dev.classmethod.jp/articles/aws-summit-japan-20260625
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: AWS Summit Japan 2026 が2026年6月25日〜26日に幕張メッセで開催され、クラスメソッドが Hall 04 ブース P024 に出展。オレンジポロシャツのスタッフ常駐で AI 駆動開発、セキュリティ、コスト最適化など 20 回のテーマ別ミニセッション実施。マスコットの「くらにゃん」も登場し、くらにゃんブレンドドリップコーヒーなどのノベルティを配布。AWS Marketplace ブースでも AI-Starter の紹介を行う。

詳細

AWS Summit Japan は2026年6月25日（木）10:00 から EXPO がオープン。最終日の26日は17:00 までの営業。クラスメソッドブースは Hall 04 ブース P024 で参加費無料（事前登録制）。スタッフはオレンジポロシャツで統一され、AWS 上位認定資格保有者が常駐。AI や AWS についての相談・質問が可能。

ブース内での 10 分程度のミニセッション参加者にノベルティプレゼント。1 日目・2 日目それぞれタイムテーブルが用意されている。昨年も大人気だったマスコットキャラ「くらにゃん」が登場予定。クラスメソッドサービス紹介冊子と AWS 導入・運用チラシも配布。Hall 07 AWS Village でも別ブースを出展し、AWS Marketplace から利用開始できる AI-Starter のユースケース・実画面を展開。イベント後はセッションレポートがポータルサイトで公開予定。

【アップデート】Claude Code v2.1.191 で /rewind コマンド で /clear 前の状態にも戻れるようになりました

• URL: https://dev.classmethod.jp/articles/claude-code-v2-1-191-rewind-update
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Claude Code v2.1.191（2026年6月25日リリース）で/rewindコマンドが強化され、/clear実行前のチェックポイントにもアクセス可能に。v2.1.191以降では/clearを跨いで過去のチェックポイントを遡ることが可能。チェックポイントは各プロンプト送信時に自動記録され、デフォルト30日間保持。/resumeはセッション末尾（最後のやりとり）への復帰のみだが、/rewindはセッション中の任意のプロンプト単位での巻き戻しが可能で、Claude編集ファイルも復元できる。誤ってclearを実行した場合でも任意時点への復帰とコード変更の復元が可能。bash経由のファイル変更（rm/mv/cp）はチェックポイントに記録されない。

詳細

ClassMethod渡邉氏による Claude Code v2.1.191アップデート解説。/clearと/rewindの違いを詳述：/clearはコンテキストリセット機能、/resumeはセッション末尾復帰、/rewindはセッション中の任意チェックポイント復帰＋ファイル変更追跡。チェックポイント記録タイミングはユーザーがプロンプト送信するたび。複数のアクション選択が可能：「Restore code and conversation」（コード＋会話巻き戻し）、「Restore conversation」（会話のみ）、「Restore code」（コードのみ）、「Summarize from here」（指定時点以降を要約）、「Summarize up to here」（指定時点までを要約）。セッションを跨いで30日間チェックポイント保持されるため、翌日以降の復帰も可能。bash経由ファイル操作（rm/mv/cp）は復元対象外という限界あり。

CloudFormation StackSetsで展開したConfig Ruleの自動修復を特定アカウントだけ無効化してみた

• URL: https://dev.classmethod.jp/articles/cloudformation-stacksets-config-rule-disable-auto-remediation-per-account
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: CloudFormation StackSets で展開した Config Rule の自動修復を、CloudFormation Conditions と AWS::AccountId 疑似パラメータを組み合わせることで特定アカウントのみ無効化できる。StackSets 自動デプロイはアカウント単位の除外に非対応だが、テンプレート側で RemediationConfiguration の作成を条件付けることで制御可能。例外アカウントでは Config Rule は動作してコンプライアンス可視化は維持しながら、自動修復のみ実行されない。

詳細

StackSets 自動デプロイはテンプレートレベルで設定されており、OU・アカウント・リージョン単位での調整は不可。Parameters に ExceptionAccountId1 や ExceptionAccountId2 を設定し、Conditions で AWS::AccountId と比較することで、デプロイ先アカウントごとに異なる評価結果を実現する。RemediationConfiguration リソースに Condition: AutoRemediationEnabled を付与すると、例外アカウントではリソースが作成されない。

S3 パブリックアクセスブロック用テンプレート例では、通常アカウントで自動修復が設定されるが、例外アカウントでは Config Rule のみ作成され修復アクションは無効。この手法は Config Rule + 自動修復のほか StackSets パターンにも応用可能。複数アカウント例外設定時は ExceptionAccountId3 といった具合でパラメータを追加し、!Or の条件も拡張する（!Or は2〜10個の条件に対応）。

CloudWatch Dashboardにタグが付けられるようになったのでABACでチーム別閲覧制御を試してみた

• URL: https://dev.classmethod.jp/articles/cloudwatch-dashboard-tags-abac
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: CloudWatch Dashboardがタグサポートを開始。従来のダッシュボード名ワイルドカードARNベースのアクセス制御からABAC（タグ値ベース）に移行でき、スケーラビリティ向上・ポリシー肥大化防止を実現。put-dashboardで–tagsオプション指定でタグ付与、Deny ポリシーでチーム別閲覧制御を検証。

詳細

ダッシュボードARN形式arn:aws:cloudwatch:::dashboard/でリージョン部分は空。put-dashboardで–tags Key=Team,Value=alpha形式でタグ付与、list-tags-for-resourceで確認、tag-resource/untag-resourceで操作可能。ABAC検証では、CloudWatchReadOnlyAccessをベース権限に、Deny ポリシーでaws:ResourceTag/Team=alphaでないダッシュボードへのGetDashboardを拒否。結果、Team=alphaダッシュボードは取得成功、Team=bravoは AccessDenied。ListDashboards（一覧表示）はDeny対象外なため両方表示されるが、GetDashboard（本文取得）で制御。マネジメントコンソールでもTeamB-Dashboardを開く際にGetDashboard拒否で内容非表示。大規模環境でダッシュボード増加時もポリシー変更不要で運用負荷軽減。

Amazon CloudWatch Logsがエージェントを介さずSyslogプロトコルで直接ログを取り込めるようになったのでYamahaルーターのログを取り込んでみました

• URL: https://dev.classmethod.jp/articles/cloudwatch-logs-support-syslog-protocol
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: CloudWatch Logs が Syslog プロトコルの直接取り込みに対応しました。これまでエージェント導入が難しいネットワーク機器からのログ取り込みに仲介コンポーネントが必須でしたが、VPC エンドポイント経由の Syslog 受信で不要になります。著者は Yamaha RTX 830 ルーターの Syslog をVPC 内エンドポイント経由で取り込み、VPN 接続と設定変更で正常にログ収集できることを確認しました。

詳細

CloudWatch Logs の Syslog 直接取り込みは VPC エンドポイント経由に限定されるため、オンプレミス機器からの送信には VPN や Direct Connect で接続が必要です。AWS 側設定では VPC エンドポイント（syslog-logs）を作成し、ロググループを用意して Syslog 設定で結びつけます。エンドポイントはUDP ポート 514、TCP ポート 1514、TLS ポート 6514 に対応しており、セキュリティグループで送信元 IP を制限できます。ロググループのリソースベースポリシーで logs:PutLogEvents と logs:CreateLogStream を許可設定します。Yamaha ルーター側は、GUI から VPC エンドポイント IP を Syslog 宛先に指定し、RFC 3164 フォーマット対応（RTX 830 Rev.15.02.31 以降）にファームウェアアップデートしました。ただしYamaha 独自形式はそのまま保存され、CloudWatch Logs Insights で自動フィールド抽出されます。ログストリームはVPC エンドポイント単位で自動作成される（VPCE_ID_Syslog_Region 形式）ため、複数送信元の場合は別エンドポイント分割やサブスクリプションフィルタでの転送が必要になります。Insights でのホスト名検索はフルスキャンになるため、物量が多い場合は事前分割を検討すべきです。

Amazon CloudWatch Logsの新機能「マネージドsyslogインジェスト」で、エージェントなしにVPC内からsyslogを直接取り込んでみた

• URL: https://dev.classmethod.jp/articles/cloudwatch-logs-syslog-ingestion
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: 2026年6月にCloudWatch Logsへマネージドsyslogインジェスト機能が追加された。従来はエージェント必須だったが、VPCエンドポイント経由でsyslogを直接取り込める。RFC 5424他のフォーマットは自動パースされ、facility・severity・hostnameなどが構造化フィールドとして抽出される。パブリック接続を避ける閉域環境での活用が想定される。

詳細

セットアップはVPC環境での新機能。Interface型VPCエンドポイント作成、セキュリティグループでTCP 1514 / UDP 514 許可、ロググループ作成、リソースポリシーで syslog.logs.amazonaws.com に権限付与、最後にSyslog Configuration作成で完成する。syslogメッセージはエンドポイント経由でPrivateLinkを通る。プロトコルは TCP TLS 6514（暗号化・コンプライアンス向け）、TCP plaintext 1514（ネットワーク分離済み）、UDP 514（ベストエフォート）から選択。RFC 5424フォーマットの場合、パース可能なタイムスタンプがあるとそれがイベントタイムスタンプになる。CloudWatch Logs Insightsで message フィールド（本文のみ）と @message（全体）を区別して参照可能。msgId・structuredDataも個別フィールドとして抽出されるが、構造化データ内のkey-valueは文字列のままで分解されない。VPCエンドポイント費用は東京 $0.014/ENI/時間（月額約$10-30程度、AZ数依存）、データ処理 $0.01/GB。従来のsyslogサーバー運用削減と監視フロー影響度をバランスして採用判断する。

【初心者】Djangoで作ったToDoアプリを改良してみた

• URL: https://dev.classmethod.jp/articles/co-newgraduate2026-training05-fujise
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: DjangoでのToDoアプリ改良版を実装。DB保存、削除・完了機能、期限・優先度設定、ログイン認証の4つの機能をCRUD操作とMVTアーキテクチャで追加した。データはSQLiteに直接記述した TaskManager クラスで操作し、ユーザーごとにタスクを分離するセキュリティ確保も含まれている。

詳細

Djangoプロジェクトは全体設定 config と機能単位 app に分ける。今回は accounts（認証）と todo（タスク管理）の2つ。MVTの3層は Model が DB操作、View がリクエスト処理、Template が HTML生成を担当。models.py では connection.cursor() で SQL を直接実行し、dictfetchall ヘルパーで辞書形式に変換。各操作が WHERE user_id = %s でユーザー制限され、他ユーザーのタスク閲覧・操作は防止される。views.py は @login_required デコレーターで認証必須化、request.POST.get() でフォーム値取得、TaskManager メソッドで CRUD を実行。urls.py でビューとパスを紐付け、config の include() で全アプリのルーティングを統一。template では {% extends ‘base.html’ %} で共通レイアウト継承、{% csrf_token %} で CSRF 対策、{% for task in tasks %} ループでテーブル表示。優先度は high/medium/low で badge 色分け、完了フラグは {% if task.completed %} で打ち消し線適用。ユーザー登録は Django標準の UserCreationForm を活用、ログイン・ログアウトは django.contrib.auth.urls で自動提供。設計から改良まで学習を通じて MVT 全体像を把握できた。

CUR 2.0のAthena統合をセットアップし、Step FunctionsとPartition Projectionで改良してみた

• URL: https://dev.classmethod.jp/articles/cur2-athena-integration-step-functions-partition-projection
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: CUR 2.0がAthena統合をサポート開始。公式CloudFormationテンプレート（Glue Crawler）でのパーティション管理は固定スキーマに対して重いため、Step Functionsで置き換え実装（管理処理を47秒から1秒未満に短縮）、またはPartition Projectionで追加リソース不要化を検証。3構成（Crawler/Step Functions/Partition Projection）の比較・選択基準を提示。

詳細

CUR 2.0は固定スキーマ・Parquet形式・ネストカラムを特徴とするコストレポート。Athena統合選択時、S3にCloudFormationテンプレート（crawler-cfn.yml）が自動配信。公式テンプレはGlue Crawler + Lambda構成で月1.03ドルの管理コスト。Step Functions置き換え案では、EventBridgeでS3イベントをフィルタ、MicroVMからbilling_periodを抽出しGetPartitions/BatchCreatePartitionで管理。新規パーティション作成時808ms・既存スキップ時653msで、Crawlerの47秒から約1/60に短縮。月0.011ドルコスト。Partition Projection案はDDL 1文で追加リソス不要、projection.billing_period.range=‘2026-06,NOW’で新月自動対応、管理コスト0ドル。ただしGlue Catalogに個別パーティション登録されずRedshift Spectrum連携不可。選定は用途で判断：Athena単体ならPartition Projection最小、Catalogパーティション維持しつつ軽量化ならStep Functions、クイック試行なら公式Crawler。

CursorのCustomizeでplugins、skills、MCP、subagents、hooksを一元管理できるようになった

• URL: https://dev.classmethod.jp/articles/cursor-customize-integrated-management
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Cursor 3.9でCustomize pageが追加され、plugins、skills、MCP、subagents、rules、commands、hooksをuser/team/workspaceスコープで一括管理できるようになった。従来の設定ファイル散在から、UI上で環境全体を見通せるようになり、チーム開発環境の整備やMCP・hooks管理が簡潔化。

詳細

Customize pageはAgents Windowの左サイドバーから開き、Plugins/MCPs/Skills/Subagents/Rules/Commands/Hooksのタブで部品種別に切り替え。各タブではスコープ（個人/team/workspace）を選択して一覧表示・検索可能。Team marketplace側では新しいマーケットプレイス動作として、leaderboardで人気部品をランキング表示、plugin canvasesでセットアップテンプレート共有、GitHub/GitLab/BitBucket/Azure DevOpsからのimportに対応。Auto Refresh有効でpush後に自動更新・再indexは最大10分間隔。Pluginは複数の部品（rules、skills、subagents等）を1インストール単位として配布する仕組み。個人ユースでもUI上でMCPやhooksの状態確認が容易になり、環境棚卸しの入口として活用可。

2026年06時点のDevOps AgentのIAM権限アップデートを調べてみた

• URL: https://dev.classmethod.jp/articles/devops-agent-iam-permissions-2026-06
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: DevOps Agentのマネージドポリシー AIDevOpsAgentAccessPolicy が v7 にアップデートされ、securityhub:GetFindings や guardduty:GetFindings がマネージドポリシーに正式追加された。Athena、Glue、KMS も追加可能権限に加わったが、Glue側のガードレール制約によりAthena直接クエリはまだ実行不可。セキュリティサービスの情報参照範囲が大幅に拡張された。

詳細

AIDevOpsAgentAccessPolicy は 2026/06/24 の更新で v7 に到達した。v5 で securityhub:GetFindings が追加され、v7 では guardduty:GetFindings と inspector2:SearchVulnerabilities も追加されている。これにより以前のワークアラウンド（Security Hub経由での参照）は不要になった。

追加可能なPermissionsにはAthena、Glue、KMS が新たに含まれた。Athena には athena:GetQuery* による実行ログ取得は正常に動作するが、クエリ実行そのものはGlue側の glue:GetTable / glue:GetDatabase がガードレールでブロックされており未対応。ガードレール緩和により今後対応見込み。

この拡張によりセキュリティサービス（GuardDuty、Security Hub、Inspector）の検出結果を直接参照でき、調査効率が向上する。

Amazon EC2 の新機能 AMI Watermarks で承認済みAMIの利用を強制してみた

• URL: https://dev.classmethod.jp/articles/ec2-ami-watermarks-allowed-amis-governance
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Amazon EC2 に新機能 AMI Watermarks が追加され、プライベートAMI に構造化識別子を埋め込み、コピーや派生時に自動伝播させられるようになった。アカウントID：ウォーターマーク名の形式で最大5個まで付与可能。Allowed AMIs と組み合わせることでウォーターマーク付きAMI からのみのインスタンス起動を強制でき、AMI ガバナンスを実装できる。

詳細

AMI Watermarks では WatermarkKey がアカウントID自動付与の形式で生成され、CreateImage や CopyImage で派生 AMI に確実に引き継がれる。ウォーターマーク名にコロンを含む別アカウントID風の指定をしてもエラーになり、なりすまし防止が実装されている。

Allowed AMIs と連携すると audit-mode での可視化、enabled での起動制限が可能。デフォルト許可、ウォーターマーク付きのみ許可など段階的な運用が実現でき、ワイルドカード（*、?）対応により命名規約と組み合わせた柔軟なフィルタリングができる。AMI ビルドアカウントで SCP により DetachImageWatermark を Deny に設定すれば、誤操作や内部脅威による削除も防止可能。追加料金なし。

Kiro WebでPlaywright MCPをセットアップしてスマホから調査をさせてみた

• URL: https://dev.classmethod.jp/articles/kiro-web-search-by-playwright-mcp
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Kiro Web でスマートフォンから利用するために Playwright MCP をセットアップしました。Kiro IDE とは異なり Kiro Web のMCP 設定はクラウドサンドボックス環境で実行されるため、Settings 画面から MCP サーバーを登録し、新セッション開始時に反映させる必要があります。Playwright を追加してスマホから音声入力で指示し、サンドボックス内で Playwright が動作することを確認しました。

詳細

Kiro IDE とKiro Web ではMCP サーバーの設定場所と動作環境が異なります。IDE はローカルのmcp.json で設定し、Web はアプリケーション設定画面での登録となります。Kiro Web はセッションごとにクリーンな隔離サンドボックスで実行されるため、既存セッションへのホットリロードは未対応で、設定変更後は新規セッション開始で反映されます。著者は Playwright の JSON 設定を Kiro に指示して生成させ、–output-dir（Web では毎回消えるため不要）と–headless（GUI なし）、–timeout-navigation 60000（重いサイト対応）を調整しました。スマートフォンからも同じく Kiro Web にログインして新セッションを開き、音声入力で Playwright の実行を指示したところ、サンドボックス環境でセットアップが開始され正常に動作しました。毎回のセットアップに時間がかかる点が注意ですが、Automations 機能で裏側のタスク実行に組み込めば相性が良いと考えられます。

Lambda MicroVMsのVPC EgressコネクタでVPC内プライベートリソースへの接続を検証してみた

• URL: https://dev.classmethod.jp/articles/lambda-microvms-vpc-egress-connector-private-resource
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Lambda MicroVMsのVPC_EGRESSでプライベートリソースへのアクセス実装。EgressコネクタにセキュリティグループとサブネットをアタッチしてVPC内通信を制御。NAT Gateway経由・閉域サブネット・複数コネクタ構成・ENI管理・コネクタ削除時の影響を実装検証。

詳細

VPC_EGRESSはInternet EgressからのVPC指定版。コネクタ作成にはNetworkConnectorOperatorRole（ec2:CreateNetworkInterface等を許可）が必要。create-network-connectorでVPC構成（SubnetIds/SecurityGroupIds）指定後、PENDING→ACTIVEへ遷移に約4～5分。run-microvm時に–egress-network-connectorsパラメータでコネクタARN指定。検証結果：NAT Gateway経由コネクタはVPC内ターゲット・インターネット両方到達、閉域コネクタ（デフォルトルートなし）はVPC内のみ到達。サブネット跨ぎ通信・プライベートDNS名解決・セキュリティグループ間参照も機能。ENIはコネクタ作成時にLambda基盤側で作成、MicroVM複数起動時もCustomer VPC内のENI数増加なし（クロスアカウントENI推定）。複数コネクタ同時指定はInternalFailure。稼働中のコネクタ削除時はEgress切断もMicroVMはRUNNING継続。テスト環境では Regional NAT Gateway + isolated subnet 構成で検証。

「失敗の積み重ね」がLLMを生んだ（前編）— 数学の限界から意味の幾何学へ

• URL: https://dev.classmethod.jp/articles/llm-birth-history-turing-shannon-transformer-gpt3-part1
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: LLM誕生の80年前夜から、チューリング機械、情報理論、ニューラルネットワークの訓練、言葉のベクトル化まで。設計されず積み重ねられた技術的断片がどう接続したかを辿る。AIの冬を越えた深層学習の復活も、GPU並列化という幸運なハードウェア一致があって初めて実現した。

詳細

1936年のチューリングは数学の完全性を問いていた。停止問題の無決定性を証明するため、計算とは何かを厳密に定義した。その副産物がユニバーサル・チューリング・マシン、つまり今のコンピュータ概念だ。1948年のシャノンは電話線のノイズ低減を目指していた。確率を使い情報量を定量化し、エントロピーという数学を生んだ。この式は80年後のLLMの損失関数になる。1958年のローゼンブラットはパーセプトロン、つまり機械学習の最初のデモを示した。だが1969年、ミンスキーとペパートがXORで多層性の必要性を証明すると、資金は凍結され冬がやってきた。1986年のバックプロパゲーションが多層訓練を可能にしても、なお計算速度が壁だった。2012年、AlexNetはGPUで計算を並列化し、数千の小学生が同時に足し算するように行列演算を高速化した。深さの壁はReLUと残差接続で破られた。一方、2013年のWord2Vecは単語を意味のベクトル座標に配置し、言語を数学にした。意味を空間の方向で測るコサイン類似度は、後のRAGと検索エンジンの礎になる。個々の発明は別々の問題を解いていた。数学の機械化可能性、通信効率、機械の学習可能性、言語の数値化。それらが1970年代から2010年代にかけて偶然に接続し、現在のLLMになった。

「失敗の積み重ね」がLLMを生んだ（後編）— Attentionからスケール革命、そして整列へ

• URL: https://dev.classmethod.jp/articles/llm-birth-history-turing-shannon-transformer-gpt3-part2
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Attentionからスケール革命まで、LLMの各段階を構成した技術的突破を歩んだ。RNNのスナップショット問題を解決したAttention、これを逐次処理から解放したTransformer、データとスケールの相互作用で閾値を越えたGPT-3、そしてRLHFで人間意図に整列させたInstructGPTまで。現在は推論時計算と合成データが新たな進化軸になっている。

詳細

Attention機構は機械翻訳のスナップショット問題から生まれた実用的なパッチだ。RNNは逐次処理で文脈を保つが、古い情報ほど勾配が消える。バダナウらが考えた解決策は、各時点の隠れ状態を完全コピーで保持し、出力側から関連性スコアに基づいて取得する仕組み。これが勾配消失も緩和し、何十年も前の構想が2014年に花開いた。Transformerはこの洞察をさらに推し進め、RNN自体を捨てた。Self-Attentionで全トークンが互いを参照でき、位置情報を埋め込むことで並列処理が可能になった。結果として訓練速度が劇的に向上し、より大規模なモデルへの道が開かれた。スケール則が示す通り、性能はパラメータ数、データ量、計算量に対して予測可能に改善する。GPT-3はこの法則を極限まで押し進めたが、2024年頃からはデータ枯渇とコスト限界に直面している。現在のフロンティアは事後学習（RLHF/DPO）の深化、推論時計算への投資、合成データと蒸留による効率化へシフトしている。

LLMは「考えて」いない：トークン予測の仕組みから理解するハルシネーション・プロンプトエンジニアリング・セキュリティ

• URL: https://dev.classmethod.jp/articles/llm-extended-thinking-token-prediction-prompt-engineering-deep-dive
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: LLMは「考えて」いないというテーゼに基づく詳解。LLMは次のトークンの確率が最も高い単語断片を逐次出力する予測マシンであり、「理解」も「思考」もしていない。トークナイザーはBPEで約10万語彙を構築し、言語によりトークン効率が異なる（日本語は英語の1.5～2倍のコスト）。生成は1トークンずつの自己回帰で、Prefillフェーズ（入力並列処理）とDecodeフェーズ（出力逐次処理）の2段階。Causal Attention（因果マスク）により各トークンは過去のみ参照。ハルシネーションは訓練データ限界・雪だるま効果・「わかりません」回答パターン不足の3つのメカニズムで発生。プロンプトエンジニアリングは確率分布の絞り込みであり、訓練データの特定領域を「呼び起こす」統計的フィルタ。Unicode・ホモグリフ攻撃やゼロ幅文字攻撃はトークナイザー境界ずれを利用した安全ガードレイル突破手法。Extended Thinkingは「考える空間」で雪だるま効果への自己修正を可能にする設計。

詳細

ClassMethod記事による包括的なLLM技術解説。トークナイザー挙動とSelf-Attentionメカニズムから生成プロセス全体を構造化。Prefillフェーズはプロンプト全体を並列処理（GPU行列演算）、Decodeフェーズは因果律制約で1トークンずつ逐次処理（KV Cache活用）。ハルシネーションの実務対策はtemperature調整・RAG・出典明示・ファイアウォール検証ワークフロー。プロンプトエンジニアリングの効果は確率分布絞り込み（Role指定で訓練データ領域を限定）。Few-shot Promptingはパターンマッチング効果が強い。Fable 5セキュリティ事件（120,000文字システムプロンプト漏洩）の手法：①Unicode・ホモグリフ置換（strcpyのcをキリル文字сに置換）②長文コンテキスト密輸③ドキュメント構造フレーミング④フィクションフレーミング⑤分解と再構成。ゼロ幅文字（U+200B）挿入で安全分類器をバイパス。Glitch Token（SolidGoldMagikarp）はトークナイザー語彙と訓練データ不一致による異常。多層防御（入力フィルタ+モデル内安全訓練+出力監査+アプリケーション層）が必須。Extended Thinkingは「思考トークン」を非表示で生成し、最終回答の文脈として蓄積、自己修正を実現。budget_tokens と max_tokens の管理：budget_tokens ≤ max_tokens の制約。

マネージドインスタンスグループ（MIG）のアップデート方式を整理してみた

• URL: https://dev.classmethod.jp/articles/managed-instance-group-update-methods-overview
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Google Cloud の MIG アップデート方式を整理。ローリング・カナリア・選択的の3パターン、さらに REFRESH/RESTART/REPLACE の中断レベル制御で細粒度を実現。テンプレート変更の波及範囲と速度のバランスに応じて使い分ける。

詳細

MIG 管理下の VM 更新は自動と選択的に分かれる。ローリングアップデートは –type=proactive で全 VM に順次適用、max-surge と max-unavailable で並列度制御。4 VM なら max-surge=1 max-unavailable=1 で、アップデート中は最大 5 台、常に 3 台以上稼働。カナリアアップデートは –canary-version で一部（例1台）だけ新テンプレート適用、本体は旧版のまま。問題なければロールフォワードで全体展開、問題あれば素早くロールバック。ロールバック時 max-unavailable=100% で全 VM を一斉置換し最短復旧。選択的アップデートは –type=opportunistic で自動展開を禁止、VM 起動時だけ新設定が適用される。編集操作で特定 VM へ個別更新も可能。中断レベルは REFRESH（停止なし：メタデータ・タグのみ）、RESTART（停止再起動：マシンタイプも可）、REPLACE（完全置換：デフォルト、インスタンス名も変わる）。ローリング中の待機は wait-until –version-target-reached でポーリングなし。describe コマンドで currentActions 確認（creating/deleting 表示）、list-instances で各 VM の INSTANCE_TEMPLATE 確認。テンプレート v1 → v2 では SUBSTITUTE 方式（古い置換）が標準で、インスタンス名は新しく付与される。Blue-Green デプロイパターンや段階的検証を gcloud コマンド1本で実現できる。

[2026年6月24日号]個人的に気になったModern Data Stack情報まとめ

• URL: https://dev.classmethod.jp/articles/modern-data-stack-info-summary-20260624
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: 2026 年 6 月の Modern Data Stack 界隈の注目動向をまとめました。Fivetran と dbt Labs が 6 月に正式統合し、Snowflake Summit で Cortex Code の後継 Snowflake CoCo が 7,100 超のアカウントで利用され、CoWork の AI 強化機能やDatastream プレビュー版が発表されました。Databricks は LTAP アーキテクチャで OLTP と OLAP の統合を発表し、Genie One エージェント、Lakehouse RT リアルタイムエンジン、Omnigent メタハーネスなどの新機能を公開しました。

詳細

Fivetran と dbt Labs の合併完了で 100,000 超のデータチーム支援体制が整備されました。Snowflake Summit 2026 では、Intelligence から CoWork へのリブランドと Personal Work Engine・Cortex Sense・Agent Sharing パブリックプレビューが発表されました。Cortex Code は CoCo と名称変更し Desktop GA・Excel プラグイン・Code Bundles が追加されています。Natoma 買収によってSnowflake のCoWork/CoCo が Google Drive・Slack など 100 超のビジネスシステムに MCP 経由で接続できるようになります。Adaptive Compute は GA に達し、混合負荷環境で 23%のコスト削減・89%の SELECT p99 時間短縮が報告されています。Horizon Context は外部ドキュメンテーションを自動抽出しメタデータに意味付加し、エージェント・BI・アプリケーションにコンテキストを提供します。Databricks LTAP は Lakebase（Postgres on オブジェクトストレージ）と Lakehouse を統合し、Delta Lake でのオープンフォーマット実現を目指しています。Genie One はエージェント型の AI コワーカーで、Web・iOS・Android・Slack・Teams 対応し、Genie Ontology の自己改善型ナレッジグラフで知識を蓄積します。Lakehouse RT はReyden エンジンでサブ 100ms レイテンシを実現し、Zerobus でのストリーミング取り込みに対応しています。CustomerLake は Agentic CDP として Profile Agents と Campaign Agents で継続的な顧客分析・施策最適化を自律実行します。Google Cloud は Open Knowledge Format（OKF）を YAML フロントマター付き Markdown で定義するベンダー中立標準として発表し、BigQuery Pipelines にトリガーベーススケジューリング（3 分間隔のポーリング）をプレビュー導入しました。dbt Core v2.0 alpha と Fusion engine（Rust 製）の Apache 2.0 オープンソース化が進行中で、dbt lint は SQLFluff 比で 50 倍高速、dbt Docs v2 は REST API・MCP 対応でエージェントのメタデータアクセスを実現します。Cube は MCP Connectors でNotion・Linear・Sentry 等と連携し、Sigma Agent はダッシュボードで自然言語対話可能です。Tableau 2026.2 は Agent in Dashboards（Beta）・Hosted Tableau MCP（GA）・Guided Setup を実装しています。Lightdash はセマンティックレイヤー上の Data Apps でプロンプト入力で カスタムアプリケーションを構築、Omni は AI 駆動 Dashboard Builder で自動生成に対応しました。Hightouch は「The Agentic CDP」へポジショニング転換と Series D $150M 調達を発表しました。

接続元IPアドレスを絞りたいと言われた時用に特定のプライベートIPアドレスにSNATする仕組みを自作してみた

• URL: https://dev.classmethod.jp/articles/multi-az-snat-instance
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: 閉域接続で送信元IP固定・1つまでという制約下で、Multi-AZ対応のSNAT仕組みを自作した。フローティングIPをVPC内で実現し、SNATインスタンスを2台常時起動してActive/Standy構成で切り替え。ヘルスチェックと EventBridge トリガーで異常検知から30秒以内にフェイルオーバー完了。

詳細

制約条件はSingle-AZなら Private NAT Gateway で解決するが、Multi-AZではAZ障害時にIPが変わる。フローティングIP 10.10.0.85 を実装するには、それが属するサブネット CIDR ブロックを事前に作成しないと AWS は経路追加を拒否する。VPC CIDRの一部として 10.10.0.80/28 など小さなサブネットを確保。ルートテーブルではそのサブネット宛トラフィックを Active SNATインスタンスの ENI に指定。戻り通信は VPC Gateway のエッジルートテーブルで同じ ENI へ向けることで両方向の対称性確保。ヘルスチェックは systemd-timer で30秒間隔実行、IP フォワーディング有効・SNAT ルール存在・VPN ルーター到達可能の3点検査。1つ失敗すれば CloudWatch カスタムメトリクスで 0 発行、アラーム側が異常判定。EventBridge で EC2 起動・停止・アラーム状態変化をトリガーに Lambda 関数実行、対象ルートテーブル2つ（クライアント側・VGWエッジ側）を Healthy な反対 AZ へ切り替え。ダウンタイムを1-2分以内に圧縮するため、常時2台起動でコスト受容。IAM で各インスタンスに MetricData PUT 権限、ルートテーブル更新権限を付与。検証では通常時・インスタンス停止時・iptables SNAT ルール削除時すべてで正常にフェイルオーバー確認。

文系出身が Python で混同した print と return の違い

• URL: https://dev.classmethod.jp/articles/riko-python-confusion-print-return
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Python 初学者が混同しやすい print と return の根本的な違い。print は値を画面に表示するだけで戻り値は None になり、後の処理で値を再利用できない。一方 return は値を呼び出し元に返し、変数に代入して後続処理で活用できる。実装例と表による比較を通じて、どちらをどのような場面で使うべきかを解説している。

詳細

print は組み込み関数で、引数に渡したオブジェクトを標準出力（通常はターミナル）に表示する。戻り値は None であり、print の結果を変数に代入してもその変数には None が格納される。表示された値を後続処理で再利用することはできない。

return は関数内で使う制御文で、指定した値を関数の呼び出し元へ返す。return に到達するとその時点で関数の処理が終了する（try…finally がある場合は finally ブロックは実行される）。return で返された値は呼び出し元で変数に代入でき、以降の処理で活用できる。

実装例では VS Code での動作確認手順を示し、print のみで結果を得た関数は呼び出し元で None を受け取り後の処理に使えないことを、return を使った関数は値を受け取り複数の関数を組み合わせて処理を続けられることを具体例で説明している。

実務では処理結果は return で返し、ユーザーへの表示が必要な箇所だけで print を使う。ログ出力の際は logging モジュールを用いるのが一般的。著者は文系出身未経験で Python 研修中に両者の違いに気づき、関数間のデータ受け渡しと複雑な処理実現に return が不可欠であると述べている。

【Security Hub修復手順】[RDS.50] RDS DB クラスターには十分なバックアップ保持期間を設定する必要があります

• URL: https://dev.classmethod.jp/articles/securityhub-fsbp-remediation-rds-50
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Security Hub の RDS.50 コントロールはデータベースクラスターのバックアップ保持期間が最低 7 日以上に設定されているかをチェックします。修復手順は RDS コンソールから対象クラスターを選択し、変更画面でバックアップ保持期間を 7 日以上に設定して即座に適用するだけです。Aurora など DB クラスターの設定変更はダウンタイムなしで反映されます。

詳細

バックアップ保持期間はポイントインタイムリカバリ（PITR）で復元可能な日数の範囲を決定します。保持期間が短いと、アプリケーション障害やデータ削除に数日後に気づいても過去の時点に戻せません。本番環境では最低 7 日間（要件に応じてそれ以上）が必須で、検証・開発環境ではコスト最適化を優先して短く設定できます。RDS コンソールから対象クラスターを選択し「変更」を開き、追加設定のバックアップセクションで保持期間を 7～35 日範囲で変更して即座に適用します。AWS CLI なら modify-db-cluster で –backup-retention-period と –apply-immediately を指定します。Security Hub への反映には数分～数十分かかります。カスタムコントロールパラメータ minimumBackupRetentionPeriod をデフォルトの 7 日から変更すれば、組織の基準に合わせて検出基準を調整できます。

Snowflake Cortex Code の LLM 応答に対するマスキングポリシーを AI Observability で検証してみた

• URL: https://dev.classmethod.jp/articles/snowflake-cortex-code-ai-observability-pii-detection
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Snowflake Cortex Code で LLM に渡されるデータの PII 漏洩をマスキングポリシーで防ぐ手法を検証しました。AI Observability で記録される LLM 入出力をモニタリングし、マスキングポリシー未適用時は元の個人情報がそのまま Observability ログに記録される一方、ポリシー適用後は固定マスク値が記録されることを確認しました。運用では対象カラムへのマスキング適用と定期監査、そして Observability ログとの結合による利用追跡を推奨しています。

詳細

Cortex Code in Snowsight が実行する SQL に PII が含まれる場合、LLM の応答にもその情報が含まれます。著者は AI Observability のトレーシング機能を利用して LLM 入出力を検査し、マスキングポリシーの効果を検証しました。テスト環境では email と phone カラムに固定マスク値（MASKED）を返すマスキングポリシーを作成し、ポリシー未適用時にはメールアドレスや電話番号がそのまま Observability ログに記録されるが、適用後は固定値のみが記録されることを確認しました。ただしマスキング未適用のカラム（name、address）やユーザーがプロンプトに直接入力する PII、ポリシー適用前に記録済みのログは防げないため、複合的な対策が必要です。運用では PII テーブルへのマスキング適用、定期的な監査、CORTEX_CODE_SNOWSIGHT_USAGE_HISTORY との結合による利用者追跡を勧めています。

WarpがX Premium/Grokサブスクと連携、Warpクレジットを消費せずにAgentを動かせるようになりました

• URL: https://dev.classmethod.jp/articles/warp-grok-subscription-integration
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: Warp v0.2026.06.17 で xAI の Grok サブスクリプション（SuperGrok / X Premium）を接続でき、Grok モデル経由のリクエストは Warp クレジットではなく xAI アカウント側の利用枠で実行される。OAuth トークンはローカルデバイスのキーチェーンに保存され Warp サーバには送信されない。grok-build-0.1 や grok-4-3 系で明示的にモデルを選択した場合に適用される。Auto モデルと Cloud Agents では従来通り Warp クレジット消費。

詳細

xAI は2026-06-15に「Use Grok in Warp」を公開し、Warp は2026-06-17付で SuperGrok 接続機能を dogfood から stable に昇格させた。設定で SuperGrok ボタンをクリックするとブラウザで xAI の OAuth 同意画面が開き、許可後に Warp へリダイレクトされる。接続後、モデルピッカーで鍵アイコン付きの Grok 系モデルが選択可能になる。

Grok モデルでの Run は利用履歴に Credits used: 0 と記録される。一方、Auto モデルを選択した場合は Warp 推論が走り Warp クレジット消費。Cloud Agents は OAuth トークンがローカル保存のみのため Grok サブスク接続不可で、引き続き Warp クレジット消費。レートリミット到達時は自動フォールバック設定がなければ Warp クレジット再試行もされない。

エクスプローラーで ZIP ファイルを展開すると「圧縮 (zip 形式) フォルダーは無効です」エラーが発生する

• URL: https://jpwinsup.github.io/blog/2026/06/23/Shell/Explorer/zipfldr-maxpath-japanese-encoding
• 日付: 2026-06-25
• Tier: Tier 1
• 要旨: エクスプローラーでZIPファイルを展開する際に「圧縮フォルダーは無効です」エラーが表示される問題は、ZIP内エントリのファイル名バイト長が260バイト以上（MAX_PATH）に達したことが原因。判定基準は文字数ではなくバイト長（UTF-8の日本語1文字は3バイト、ASCIIは1バイト）であり、LongPathsEnabledレジストリ設定は効果なし。回避策はPowerShellのExpand-Archiveコマンドレット（推奨）、7-Zipなどのサードパーティツール、またはZIP作成時のファイル名短縮。Windows 11全バージョンとWindows Server 2016以降で同一の260バイト境界値で制限される。

詳細

Microsoft社員の丸山氏によるエクスプローラーのZIP展開エラー解説。zipfldr.dllの実装制約により、ZIP内の相対パス（エントリ名）のバイト長が260以上の場合、ファイル全体を無効と判定。検証結果は複数のOS（Windows 11 version 23H2/24H2/25H2、Windows Server 2016/2019/2022/2025）で同一の259/260バイト境界値を確認。UTF-8エンコード時の日本語パスは約86文字が上限（1文字3バイト消費）。PowerShellのExpand-ArchiveはSystem.IO.Compressionを使用し制限を受けない。ZIP仕様は2006年にUTF-8フラグが追加されて文字化け問題が解消、現在のWindowsは作成時にこのフラグを自動設定。MAX_PATH=260はMS-DOS時代から30年以上変わらない値（ドライブ文字2+パス区切り1+本体256+NULL終端1）で、Win32 API登場時の Windows NT 3.1（1993年）から固定。

AWS Lambda MicroVMs登場。サーバレスの手軽さでステートフルかつ隔離された実行環境を提供

• URL: https://www.publickey1.jp/blog/26/aws_lambda_microvms.html
• 日付: 2026-06-25
• Tier: Tier 2
• 要旨: AWS が新サービス Lambda MicroVMs を発表。サーバレスの管理不要で瞬時起動という利点を保ちながら、最大8時間のステートフルな実行環境をカーネルレベルで安全に隔離できる。Firecracker による MicroVM を採用し、ARM64 アーキテクチャで最大 16vCPU・32GB メモリ・32GB ディスク。東京含む複数リージョンで利用可能。

詳細

AWS Lambda は従来ステートレスな短期実行関数を基本としており、管理が不要でスケーリングも自動という利点がある。AWS Lambda MicroVMs はこの利点を保ちながら、ステートフルな実行環境を提供する新しい選択肢である。

MicroVMs の特徴は Firecracker を採用してカーネルレベルで安全に分離され、最大8時間のステートを保持できることが挙げられる。アイドル状態でもメモリとディスクが保持され、トラフィック到着時に即座にセッションを再開する。イメージ管理は Dockerfile と Amazon S3 パッケージで行う。

用途としては、生成 AI が作成した信頼できないコードの一時実行隔離、コマンドライン環境のようなインタラクティブスクリプトの安全な実行、マルチテナント環境の簡単な構築などを想定している。ただし永続的なステート維持には対応していないため、一時的または短時間で完了するワークロードが想定される。

仕様は ARM64 アーキテクチャで最大 16vCPU・32GB メモリ・32GB ディスク。対応リージョンは東京のほか米国東部（ノースバージニア、オハイオ）、米国西部（オレゴン）、ヨーロッパ（アイルランド）。

vol.213　やっぱりタスクからメール通知したい ― 廃止された通知機能と現実的な代替策｜セイテク・シス管道場（Web）

• URL: https://www.say-tech.co.jp/contents/blog/yamanxworld/2026vol213
• 日付: 2026-06-25
• Tier: Tier 1
• 要旨: タスクスケジューラ2.0（Windows Vista・Windows Server 2008 以降）で廃止されたメッセージ表示・電子メール送信機能の現実的な代替策を解説。メッセージ表示は Msg.exe コマンドで代替可能（セッション0 分離回避）。電子メール送信は Microsoft 365 環境では Graph API を用いた PowerShell スクリプト（msgsendbygraphapi.ps1）で Microsoft Entra 認証によるメール送信を実装。廃止機能の背景には Windows Vista のセッション0 分離、セキュリティ厳格化、SMTP AUTH・TLS 必須化がある。

詳細

Windows 8・Windows Server 2012 でタスクスケジューラ2.0 から廃止された機能は AT コマンド、メッセージの表示、電子メールの送信の3つ。AT コマンドは schtasks.exe で代替され案内も明確。メッセージ表示・電子メール送信は代替が必要だった。

廃止されたアクションは UI に「非推奨」として残り、Windows 7 以前の OS にリモート接続時に設定可能だった（レガシ OS アップグレード後に使用不可となるため表示）。ただし Windows 7・Windows Server 2008 R2 はサポート終了（Windows 7 は2023年1月 3年目 ESU 終了）。

メッセージ表示が廃止された背景は Windows Vista のセッション0 分離（サービスは常にセッション0、ユーザーはセッション1 以降で動作）にあり、「ユーザーがログオンしているかどうかにかかわらず実行する」オプション（セッション0 実行）ではメッセージを表示できなかった。UI0Detect サービス（対話型サービス検出）は互換性対策だったが、セッション0 の高権限サービスが UI を表示する仕様がセキュリティリスクのため Windows 8 で既定無効化、Windows 10 Creators Update で削除。

代替方法は Msg.exe コマンド（リモートデスクトップセッション・ローカルユーザーへのメッセージ表示。セッション0 分離影響なし。既定60秒後自動閉じ。/time パラメーターで調整可）。

電子メール送信アクションは Windows 7・Windows Server 2008 R2 まで利用可能だったが、SMTP 送信先・件名・本文・添付指定のみ。当時既に SMTP AUTH・TLS・リレー制限が厳格化され実用性が失われていた。現在の代替は Microsoft 365 環境で Graph API（Mail.Send スコープ）を用いた PowerShell スクリプト（msgsendbygraphapi.ps1）で、Microsoft Entra ID アプリ登録・クライアントシークレット・管理者同意で認証。他メール環境は SMTP AUTH サポート時に従来 SmtpClient・MailKit、API 提供時は API（Gmail API など）を使用。

Claude CodeがSOC業務を全自動でやってくれるってさ - ZOZO TECH BLOG

• URL: https://techblog.zozo.com/entry/soc-claude-agent
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: ZOZO が 3 人 SOC の負荷軽減のため Claude Code で構築した自動アラートトリアージエージェント。Splunk MCP でアラート・ログを取得、OpenCTI MCP で脅威インテリジェンスを取得、SubAgent で並列調査（opencti-agent・log-search-agent）し、GraphQL/SPL テンプレート定義で検索結果を制御。Hooks で Create/Delete など書き込み操作を禁止し Read のみに制限。過去調査メモリで類似事象の判定精度向上。/notable-response・/threat-hunting・/slack-alert-triage の 3 運用コマンドで、初動対応の自動切り分けと脅威ハンティング実行。トークン権限を最小化し、MCP エンドポイントは 1Password で秘密管理。

詳細

ZOZO 情報セキュリティ部が SOC 3 人体制の大量アラート処理負荷軽減を目的に、Claude Code ベースの自動トリアージエージェント構築。Tier 1 初動対応に相当し、Read 権限のみで設計。Splunk MCP で Notable アラートと詳細ログ取得、OpenCTI MCP で脅威インテリジェンス取得、複数の SubAgent（opencti-agent、log-search-agent）を数十体並列起動して IOC 種別・調査ログ種別で分担。GraphQL・SPL テンプレートを Skill reference に記載しエージェント判断の直列化と安全性確保。Hooks で GraphQL の create/delete/stixCoreRelationshipEdit 禁止、Splunk の outputlookup/outputcsv 禁止に設定。トークン管理は 1Password CLI で vault 取得し、誤ったコミット回避。MCP IP allow list 設定必須（見落としやすい）。Splunk MCP は search・get_metadata・indexes_list_all・mcp_tool_execute ロール、OpenCTI MCP は Read 権限のみで十分（TLP:RED は常に非表示、TLP:AMBER は状況判定）。/notable-response で Notable ID からの自動調査・相関分析・対応案生成、/threat-hunting でレポート ID からの IOC・攻撃手法抽出と脅威ハンティング、/slack-alert-triage で指定時間アラート自動取得・グループ化・スレッド投稿・Critical メンション通知。過去調査メモリで過検知フィードバック・継続アクター判定を記録、調査効率化と精度向上実現。

Claude Codeのトークンコストを、仕組みから理解して削る

• URL: https://zenn.dev/acntechjp/articles/f00b201cabcc39
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Claude Codeのトークンコストは仕組みを理解することで削減できる。キャッシュの3層構造（システムプロンプト→プロジェクトコンテキスト→会話）と、先頭部分の変化による全損リスクを把握することが鍵。出力トークンが入力の5倍高いため、LLMに長く喋らせない設計が最も効く。

詳細

Claude Codeのコスト構造は料金表（Opus入力$5/100万トークン、出力$25）だけでなく、キャッシュ機構（再利用時約1/10）の活用が実質的な節約に繋がる。プロンプトキャッシュは毎ターン「変わらずに続いている共通部分」を前回と同じプレフィックスで比較判定するため、1バイト変わると後ろ全部が再計算される。システムプロンプト変更・モデル切り替え・effort変更・MCP増減など8つの操作がキャッシュを破壊し、その直後のターンは全文再処理される。TTL（キャッシュ有効期限）はサブスク1時間、APIキー5分。モデルの使い分けはchoko-choko切り替えで損なので節目でまとめ、難しい作業だけOpus、簡単な作業はHaikuに割り当てる。サブエージェントを安いモデルに指定することで、本体コンテキストを汚さず並列処理できる。

SBOM × Claude Code で、脆弱性対応を「開発者の日常業務」に溶け込ませた話

• URL: https://zenn.dev/canly/articles/61c621c7393dd4
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: 複数プロダクトの脆弱性を SBOM（Software Bill of Materials）×grype/xeol で一元検出し、SRE・開発者それぞれに最適な形で届ける2出口システム。トリアージガイド（Severity/Exploitability/Context/Cost の4観点）を人間用ドキュメント＋Claude Code の手順書として兼用、重大度＋悪用可能性（EPSS）の AND 絞り込みで脆弱性 issue を起票。リポジトリ SBOM と本番コンテナ SBOM を分離、devDependencies の無駄な工数を除外。GitHub Projects ダッシュボードで SRE が対応ステータス・Product・Severity をグルーピング・絞り込み、開発者はコンポーネント×リポジトリ粒度の issue を普段の GitHub から自然に拾う。非同期ワークフロー化で Enabling MTG 依存を解消、進捗管理から同期コミュニケーションを廃止。対応方針（アップデート/WAF/リスク受容）と Fixed In（won’t fix 識別含む）の Custom Field で意思決定の監査可能化。product/owner 単位での GitHub Actions スキャン実行、enable-vuln-fix フラグで段階的適用。

詳細

脆弱性管理の3フェーズ進化：①人がたまたま気づく（検知運任せ）→②Notion レポート×Enabling MTG の同期共有（進捗トラッキング課題）→③ダッシュボード×issue で非同期追跡。基盤は既存の SBOM 生成（aqua/syft/grype/xeol ツールチェーン）で、新規は検出結果の出口を2つに分岐。SRE 観点：ダッシュボード一覧で「未対応のグルーピング、Product スライス絞り込み、Severity ソート」で、巡回・問い合わせなしに全社の状態を一目で把握。開発者観点：自分のリポジトリの issue として届き、通常のスプリント業務と同じ土俵でタスク化。トリアージガイド（4観点の明文化）の活用で Claude Code が CVE/NVD/GitHub Advisories から追加調査・整形・起票まで実行可能（人間は最終判断を保持）。コンテナレベルの SBOM で本番関連性を判定、リポジトリレベルは開発環境専用除外。issue 粒度（コンポーネント×リポジトリ）でアクション単位と一致させ、複数 CVE は1 issue に一覧。初回起票時に解決手順・互換性リスク・代替案を先読み情報として埋め込み。運用改善は PR レビュー可能な形でガイド変更として履歴化、口頭要望ベースから脱却。

1Password CLI で Claude Code のトークンを複数 Mac に安全に配る

• URL: https://zenn.dev/coa00/articles/1password-cli-claude-code-secrets
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: 複数の Mac で Claude Code を運用する際、1Password CLI で MCP サーバートークンを一元管理。1Password を秘密のソースに固定し、sync スクリプトで各機へ配布。git 追跡対象は環境変数参照のみにして、平文トークンが散らばるのを防ぎ、ローテーション時も 1Password 更新と全機 sync で完結。

詳細

複数 Mac で Claude Code を運用する際のトークン管理戦略。Notion・Linear・GitHub・Slack 等の MCP サーバートークンを 1Password に集約し、CLI（op item get）で各機に配布。設計原則は秘密の流れを一方向にし、1Password → ~/.config/claude/secrets.env → 環境変数 → .mcp.json 参照という流れを構築。save-to-1password.sh で手元の env 値を 1Password に保存し、sync-claude-secrets.sh で各機が読み出してシェル安全にエスケープして書き出す。jq で JSON パース、umask 177 で secrets.env のパーミッションを 600 に制限。一部フィールド未入力の状態でも sync が成功するフェイルソフト設計で、段階的な移行を可能に。Touch ID 承認・アンエスケープ・ロック再入による失敗など実装時の落とし穴も記載。

【実践】Kiro/Claude Codeの「信頼済みコマンド」で調査作業の承認をゼロにする

• URL: https://zenn.dev/devex12/articles/kiro-claude-trusted-commands
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Claude Code と Kiro の信頼済みコマンド設定で調査作業の承認回数をゼロにする方法。grep・ls・cat・git・aws log などの読み取り専用コマンドを許可リストで事前設定し、破壊的コマンドを拒否リストで明示的に遮断。Steering と組み合わせることで調査フェーズを 30 分から 5 分に短縮。

詳細

Claude Code・Kiro エージェント利用時に毎回承認を求められる調査コマンドの自動化設定。settings.json や Kiro 設定で読み取り専用コマンド（grep・rg・ls・cat・head・tail・find など）を許可リストに登録し、aws describe/list・git log・gh pr 系も許可。拒否リストで rm -rf・git push -f・git reset –hard・DROP・DELETE を明示的に遮断。パターンマッチの仕組みやワイルドカード活用（:* 記号）、トラブルシューティング（パターン不一致・ファイル場所確認）も解説。実際に 20 回以上の承認を 0 回に削減した事例を紹介。

Claude Codeが廃案を実装し直す「コンテキスト・ドリフト」を止めるドキュメント管理術

• URL: https://zenn.dev/forest_project/articles/a7b89cd25b60dc
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: LLMが前回却下した案を数セッション後に無意識に復活させる「コンテキスト・ドリフト」を、フロントマター+Linter+アーカイブ保護+セッション開始時の最小コンテキスト注入の4層で構造的に抑えるブループリント。ETH Zürich の研究（ArXiv:2602.11988）で自動生成コンテキストが成功率を3%低下させる実証実験に基づき、入力の中盤が見落とされる「Lost in the Middle」と、無関係情報が注意ヘッドの配分を奪う性質（Huang et al. ArXiv:2502.01609）を明示。7値のステータス（draft/proposed/current/deprecated/superseded/archived/open）を強制付与、書き込み時の docs-linter.py（stdin JSON経由の自己修復ループ）、PreToolUse Hook による アーカイブ不変化とADR追記型化、CLAUDE.md は薄いルーター化により、廃案の具体的な中身は隠す。スペック駆動開発（Spec-Driven Development）で設計書自体がAI指示として機能する手法。

詳細

コンテキスト・ドリフトの4つの形（廃案の復活・未決の既決化・仕様と実装の取り違え・古い前提の採用）と原因分析：LLMは入力の先頭と末尾の情報には高精度アクセスするが中間情報を見落とす（Liu et al., 2024）。無関係だが一貫した文脈を加えると推論性能が平均45%以上低下する注意機構の偏り（Zhu et al., 2025）。導入の中核は確率的スキル（Skill）と決定論的フック（Hook）の分離、フロントマターメタデータ（id/title/type/status/owner/updated/sources）の7項目必須化、PostToolUse Hook で書込時に Linter 自動実行（エラー検知時も停止せず tool_result としてAIが自律修正）、PreToolUse Hook でアーカイブ・決定済みADRへの編集を物理的に拒否（追記型へ誘導）、SessionStart Hook で廃案の中身は隠し圧縮された事実関係（ラベル・撤回日・非目標・回帰監視リスト）のみ注入。CLAUDE.md は薄いルーター（常時参照: 確定済み事実、非目標、戻してはならない事項；規約: 現行vs歴史的区別、未決の人間帰属）に限定して CLAUDE.md 肥大化を防止。導入時の落とし穴：メタデータ付与漏れによる Linter 過検出、フック実行パスエラー、毎ターン全走査による速度低下（単一ファイル検証に限定）、運用形骸化（更新はAI代行・人間は承認のみ）。4つの仕事は互いに従属せず、プロジェクトごとに構成される設計書として配布される。

Claude Codeとの会話で、個人アプリを公開まで持っていく

• URL: https://zenn.dev/indiedev_lab/books/claude-code-kaiwa-de-susumeru
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Claude Code で個人アプリを公開まで進める際の会話パターンを体系化。目的確認・実装検証・セキュリティ検討・デプロイ判断など各フェーズごとに、指示文ではなく問い方・疑い方・検証の型を重視した会話例を収録。

詳細

Claude Code との対話で個人開発を公開まで進めるための方法論を解説。完成した指示例よりも、問い方の分岐・疑い方の順序・検証の型を重視。初回会話で目的と前提をそろえ、実装ループでレビュー・確認サイクルを回し、公開前は境界条件や認証・セキュリティを相談形式で詰める流れを紹介。写真ヒント学習アプリのケーススタディを含め、具体的な会話パターンと実装例を展開。

Claude Code で YouTube Shorts Chrome 拡張を 1 セッションで作り切った

• URL: https://zenn.dev/joemike/articles/chrome-extension-one-session-claude-code-2026
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Claude Code で YouTube Shorts 説明文展開拡張を 2.5 時間で実装。Shadow DOM・非同期レンダリング・Manifest V3 権限・キャッシュ更新・URL 変化監視の 5 つの落とし穴を DevTools DOM 貼り付け質問で突破。

詳細

Claude Code で YouTube Shorts Chrome 拡張を 1 セッション（約 2.5 時間）で完成させた事例。通常 YouTube の ytp-button とは異なる ytSpecButtonShapeNextHost 仕様により querySelector が何度も null を返す問題に直面。Shadow DOM は shadowRoot 経由でアクセス、非同期レンダリングは MutationObserver で待機、Manifest V3 の host_permissions を追加、キャッシュ更新は chrome://extensions/ で手動、スワイプ時の URL 変化は監視ループで re-init。DevTools で見えている DOM 構造を丸ごと貼り付けて Claude Code に質問することで、一人での試行錯誤を数時間削減。コア実装は 100 行弱のシンプルな content.js。

AI を並列で動かす前提は、独立した作業領域を切り分けること

• URL: https://zenn.dev/kanfupanda/articles/isolated-worktrees
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: 複数 AI エージェントが並列で同じプロジェクトを編集する際、読み取りは共有可でも書き込みは隔離が必須。git clone による物理的な全ディレクトリ複製は git/履歴の重複コストが大きく、回収不可で場所を食い続けるため、git worktree への切り替えで解決：複数作業ツリーが .git 共有、ディスク浪費なし、一時的で終了後回収可能。セッション内 subagent 並列は AI が自動で隔離を判断・worktree 開設するが、手動で複数端末を並列起動する場合は明示的に指示「別の AI がこのディレクトリを編集中。worktree を使って」で初めて主幹に直接手を出さない動作に切り替わる。スムーズな流れ：疎結合の境で独立タスク分割→各々を別 worktree に→各自検証して問題なければ主控 agent が一つずつ主幹に戻す→問題時その場で直す→worktree 回収。worktree 衝突は稀（設計段階で相互依存排除）。常時ルール：主幹で直接作業しない。すべて新規ブランチで開始→検証→PR で主幹合併。worktree であれ単一ブランチであれこの線を守り、主幹を信頼できる状態に保つ。

詳細

複数手が同時に一つのプロジェクトを編集する問題の発生：手動で複数 AI 端末を並列起動すると、ファイルが相互上書きされ状態が混乱。解決策の進化：①素朴な物理隔離（clone を複数作）は React フロント+Python バック複合プロジェクトで数G の重複コスト、ディスク常時消費。②git worktree への切り替え：複数作業ツリーが単一 .git 共有、リポジトリと履歴を何度も複製しない、一時的で終了後即回収可能（clone のような長期居座りなし）。隔離効果はほぼ同じながらディスク浪費なし。二種類の並列シーン：セッション内 subagent は AI が自動で隔離判断・worktree 配置（指示不要）。手動端末並列では AI が「別の AI も触っている」を既定では知らず、明示指示「worktree で作業して」で初めて主幹回避動作に入る。スムーズなワークフロー：タスク分割時に疎結合部を選ぶ→各ブロックを独立 worktree に→全終了後、主控 agent が一つずつ検証・merge・問題あれば即座に修正・worktree 解放。worktree が本当に同じファイル接触する衝突は稀（初設計で相互依存最小化）。よくある落とし穴：worktree 片付け忘れ（場所食うが致命的でない；主幹に合わさっているので失われるものなし）。防御：「worktree 検証 OK→merge 完了→解放前に commits が主幹に全合併したか確認」で早期消し込み防止。人の手作業片付けは確認が消えるリスク（合わさっていない機能をまるごと失う）。無用な worktree 開設は割に合わず（数ファイル変更なら単一ブランチで十分）。ただ緩めない線：主幹で直接作業しない。どの変更も新規ブランチで開始→検証→PR で合併→主幹は常にきれい。AI が新しい場面（並列編集）で古い git 機能を新しい価値で活用する例。

アプリが4本になったので、バグ報告を1箇所に集めてAIに並列で潰させた話

• URL: https://zenn.dev/kitepon/articles/bughub-aggregation
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: 複数商用アプリ (4本) のバグ報告を1箇所に集約し重大度基準を統一した BugHub システム。自宅サーバーで各アプリの read API を 3 分ごと巡回、署名 (fingerprint) でバグ重複を検出・統計し、AI 向けに共通仕様で 1 ページの Markdown を GET /ai で返す。複数 Claude を並列で起動し同じ URL を渡すことで、その日のうちにバグ一掃。重大度 4 段に統一 (fatal・high・warn・info)、解決はアプリ側に記録し BugHub は読み取り専用。巡回・ルール判定は純粋アルゴリズムで AI 不要。

詳細

4 本の商用アプリ (LiveTR・OLTranslator・Kikoeru・AuctionBOT) でユーザーの手元環境から上がってくるバグ報告が各所に分散。BugHub と名付けた内部読み取り専用コンテナで LAN 内 API 巡回・集約。

アーキテクチャ: 各アプリが signature 形式で read API を出す (Bearer 認証)。signature = “モジュール・種別・メッセージ雛形” のハッシュで、同じ原因は同じ値。BugHub は 3 分ごとに巡回、署名で重複検出・統計。バグ情報: 重大度・マスク済みメッセージ・累計発生数・最終発生時刻・解決状態を payload。新規アプリ連携は SOURCES に 1 行追加、ログ形式違いはアダプタ 1 つでカバー。

重大度統一化: fatal (止まる) > high (実害) > warn (直すべき) > info (参考)。各アプリが担当して基準付与、BugHub は再判定せず。基準統一で初めて優先順位が有効に。

AI 向け共通仕様: GET /ai で Markdown 1 ページ返却。内容: 重大度定義・修正手順 (取得→修正→本番検証→解決記録。確信なければ触らない) ・現時点未解決一覧 (解決コマンド付き) ・アプリ別解決先テーブル・新規連携仕様。複数 VSCode/Claude に同じ URL を渡す。

並列修正フロー: 各 Claude が担当アプリを未解決一覧から取得 → 修正 → 本番デプロイ → 検証 → 解決記録 (アプリ側に) → 次へ。解決はアプリ側が正、BugHub は読み取り専用ミラー。アプリ側で再発検知すれば自動で「未解決」に戻る。

コスト構造: 巡回・閾値ルール・アラート判定は純粋アルゴリズム (AI 不要)。AI は修正側と週 1 Codex まとめだけ。個人開発者が複数商用アプリ運用で時間がバグ捌きに集中する現実を可視化・自動化。

プロンプトはAIに書かせる — skill-creatorに学ぶ再現性担保

• URL: https://zenn.dev/kz_gz/articles/claude-skills-prompt-quality
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: プロンプト品質をプロンプト自体で担保する Anthropic 公式 skill-creator の設計を解説。LLM は純粋関数ではなく結果が揺れるため、評価軸こそが再現性を担う。6 段階ワークフロー: 意図把握 → SKILL.md → テストケース → skillあり/なしの並列 subagent 比較 → 改善ループ (一般化・過適合防止) → description 最適化 (学習/検証分割)。5 原則: 書き手は評価できない (第三者観察必須)・現実的テスト複数・比較対象・定量+定性・ループ。

詳細

Skill とは YAML frontmatter + Markdown 本文で構成される AI 向け指示プロンプト。frontmatter に name (識別子) と description (発火条件+機能) があり、Claude が description を読んで自動発火。本文は具体手順・ルール・例。

プロンプト品質 = 結果の再現性。LLM は推論で曖昧な指示を埋めるため「良い感じに」は呼び出しごとに違う出力。設計されたプロンプトで再現性担保。

skill-creator の 6 工程:

1. 意図把握: 目標・発火条件・出力形式・テスト用意の有無を 4 問で詰める。
2. SKILL.md: name + description (機能+発火条件。「押しつけがましく」完明確に) + 本文。
3. テストケース: 2-3 個、具体的・固有名詞・口語含む「現実的」ケース。抽象的だと本番で動かない。
4. 評価ループ (コア): skillあり/なしの subagent を同時並列起動、同一テストで両者出力比較。skillが実際に効いているか、skillなしで十分か、検証項目の通過状況を定性+定量確認。新規時は比較対象=なし版、改善時は旧バージョン。
5. 改善ループ: 指摘に対して特定テストのみ直さず一般化して直す (過適合防止)。「テスト 3 でこうなった」→「この種のケースではこう考える」へ抽象化。
6. description 最適化: 発火すべき/すべきでないテストケース 2 グループで description 候補複数提案 → 各候補を全テストで実行 → 検証用スコアで最高を選択 (学習/検証分割で過適合防止)。

5 原則: (1) 書き手は読めば分かると思うが第三者には伝わらない→subagent に任せ観察 (2) 具体・固有・口語含む現実的テスト (3) 比較対象が「良くなった気」を「実際」に変える (4) 定量 (アサーション)+定性 (ユーザーレビュー) (5) 評価→改善→評価ループ+過適合警戒。

メリット: 業務明確化・属人化回避・ナレッジ蓄積。繰り返し定型タスク (議事録要約・週報整形・メール返信) に適す。毎回文脈が変わるタスク・判定基準不定は skill 化効きにくい。

AI時代のコードレビューは人に向けるな、仕組みに向けろ

• URL: https://zenn.dev/manalink_dev/articles/ai-coding-era-review-to-dev-process-not-human
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: AI時代のコードレビューは人ではなく仕組みに対するフィードバックに転換すべき。修正の頻度・タイプ・パターンを見て「このコード品質が出力されたのはどの仕組みのせいか」を問い直し、CI前・編集前・編集後で決定論的な部分と推論に頼る部分を使い分けながら、開発チーム全体で仕組みを育てる文化が必要。

詳細

AI生成コードへのレビューは「誰が書いたのか」から「どの仕組みのせいか」に視点転換。Claude Code指示→実装前リファクタリング→編集後リモート反映までの全体像を抑え、問題が仕組みのどこをすり抜けたか追跡する。マナリンクの「臭うコード検出器」基盤により、開発者が気に入らないOutputを検出可能な形に言語化→容易にPull Request化可能な状態を実現。仕組み拡充を容易にするには、全体像の策定・共有・ローカル試行成功体験・CIの二値論から重度度Severity扱いへの落とし込みが必要。決定論的（CIで判定）と推論的（Agent Skillで条件判定）の併用が妥当で、Severity化により新しい仕組み提案のハードル低下。新規事業より歴史的プロダクトの方が、妥当なコード・ルール・プロセス・文化の蓄積があり、仕組み化の根拠として参照可。テストコード増・Lint増・Skill増・スクリプト同梱で決定論強化は、モデルやエージェント変更後も手元に資産として残存。ソースレビューは人ではなく仕組みそのものと今後のチューニング戦略へのフィードバック。

Loop Engineering 時代の多層防御サンドボックスを本気で考えてみた

• URL: https://zenn.dev/miroscular/articles/heartgarden-multilayer-sandbox
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Loop Engineering の自動実行環境で Claude Code をエンタープライズレベルで安全に運用するため、プロンプトインジェクション発生を前提に設計した多層防御アーキテクチャ HeartGarden。コンテナ FS 分離 + Bedrock Guardrails 入口検査 + mitmproxy DLP 出口検査 + 秘密鍵分離により、知らない秘密は漏らしようがない構造を実装し、速度と安全性の両立を狙う。脅威モデル明示、防御層マトリックス、実装課題（偽陽性・証明書相性・Podman 永続性）も記録。

詳細

HeartGarden は Podman + Workspace コンテナで Claude Code を隔離し、二系統プロキシ（guardrails-proxy + egress-proxy）でプロンプトインジェクション対策を多層化。

入口層: Bedrock Guardrails がすべての LLM リクエストを自動検査し、言い換えプロンプトインジェクション検知。完全防止は難しいため、下位層を前提。

出口層: mitmproxy ベース egress-proxy による 二段 DLP — ホワイトリスト (第一段) + 正規表現・Shannon エントロピー・AI DLP (第二段)。GitHub/npm など許可ドメイン経由のキー流出防止として機能。

鍵分離層: Workspace に API キーを置かず、Bifrost (LLM Gateway) と egress-proxy が認証肩代わり。Virtual Key 認証で知らない秘密は漏らせない構造。SSH 鍵やクラウド認証情報もマウント範囲最小化で遮断。

FS 分離層: コンテナ外ファイルシステム保護 + ホスト重要ファイル（/.ssh、/.aws など）への到達経路遮断。

脅威マトリックス: 機密漏洩系に複数層が必要。特に「言い換えによる漏洩誘導」は鍵分離のみが ◎。

永続開発環境: 名前付きボリューム + mise でツール構成再現。pc 再起動後も同一状態で再開。

実装課題: AI DLP 偽陽性 (ランダム文字列誤検知)、mitmproxy 証明書ピン留め相性、Podman 永続性の VM/Incus との比較、Claude Pro/Max などサブスクリプション課金未対応。

制御理論から理解するループエンジニアリング――「ループの外に出る」3つの段階

• URL: https://zenn.dev/noragrammer/articles/loop-engineering-stages
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: 制御理論から Loop Engineering を解き明かし、AI エージェント + 人間の関係を三段階で分類。Loop in the Human (人間がプロンプト毎回打つ)・Loop on the Human (自走するが停止判定人間) → Loop Engineering (独立 Evaluator がループ閉じ人間は設計者)。Evaluator の独立性が負帰還 (安定性) の必須条件。実装コスト階層で個人の現実的到達点は E2E テストまで。その先はカスケード制御で技術品質ループの外側に市場価値ループを重ねる。

詳細

制御工学の基本：フィードバック有無・正負で系の振る舞いが決定。オープンループ制御 (フィードバックなし) は誤差蓄積、フィードバック制御 (負帰還) は目標収束・系安定。

Loop in the Human: 人間がフィードバック路になっている段階。イシュー投入 → エージェント実行 → 人間が観測・判定・修正指示 → 再実行。人間がボトルネック、並列化で詰まる。診断チェック: 毎回プロンプト手作成、判断が作業時間の大半、エージェント停止=自分も停止。脱出手段: トリガー外部化 (GitHub Issue・Slack メンションでエージェント起動)。

Loop on the Human: ループは自走するが停止判定が人間依存。イシュー → エージェント自律実行 → PR生成 → 人間が動作確認・レビュー・クローズ。Evaluator 不在または弱い。診断チェック: イシュー投入で自動動作、PR自動生成だが「これで合ってるか」は人間判定。脱出手段: 独立 Evaluator 組み込み (テスト・Lint・コードレビュー・E2E など)。

Loop Engineering: Evaluator がループ内に組み込まれ人間はループ設計のみ。例外フローのみ人間に通知。制御理論観点: 観測器 (Evaluator) が制御器 (実装者) と同一は設計欠陥。自己採点は甘くなるため独立必須。Claude Code /goal が内部で Haiku を採点役に使うのも同理由。診断チェック: Evaluator 独立稼動、成功条件が機械的判定可能、例外フロー通知のみ、人間の仕事はループ改良。

Evaluator コスト階層: テスト/Lint (低・即実装) → コードレビュー (中・許容範囲) → E2E (中〜高・個人上限) → UIUX評価 (高) → 負荷試験 (高・潤沢予算前提)。ROI = ループ価値 ÷ 実装・運用コスト。ROI < 1 なら人間レビュー安い。コストが下がった瞬間にループを閉じる判断速度が競争力。

カスケード制御: 技術品質ループ (内側・Evaluator で安定) の外側に市場価値ループ (外側・PV・反応で gap_analyzer 起動)。外側ループ通信で「何を作るか」の判断まで自律化。内側不安定なまま外側閉じると系発散。

AI専用動画編集ツールにクロスフェードを足したら、動画が0.5秒『短く』なった — clipwright v0.16〜v0.17

• URL: https://zenn.dev/satoh_y_0323/articles/38f0b9d4e4b1fa
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: AI 専用動画編集 MCP サーバー clipwright にクロスフェード（xfade/acrossfade）と PySceneDetect バックエンド配線を追加（v0.16〜v0.17）。クロスフェード実装の核：重なり部分が「足し算が引き算になる」物理（2.5s + 2.5s = 5.0s が 0.5s ディゾルブで 4.5s に縮む）を JSON エンベロープに正確に反映。ffmpeg xfade フィルタの offset 算術は累積時間から過去の重なり累積を引き、さらに今回フェード長を引くという多段計算で、タイムラインの 2 経路（trim/silence 出力 vs sequence 出力）を共通化。フェード長>クリップ長では短い側にクランプ、warning は生数値埋め込みでなく固定文言+インデックス（CWE-209 防止）。トランジションと字幕の共存時は warning、per-boundary 混在指定は UNSUPPORTED で弾く（v1 では複雑度削減）。シーン検出 0 件時の応答改善：「閾値を 0.15 に下げて再実行」と具体値提示、backend=‘pyscenedetect’ 切替提案、既に floor に達していれば「素材が 1 カット」と別見立てを返す。PySceneDetect 未インストール時エラーは共通ヘルパの ffmpeg 案内を差し替え、pip install scenedetect の正しい手順に統一（モック化したテストで差し替え失敗を検出）。8 日前の自分の実装（シーン検出バックエンド）を未実装と誤認識、着手前の Explore 調査で二重実装を回避。4 周レビュー（ドキュメント嘘・例外漏れ経路・テスト欠落・例外チェーン from None 統一）で、動き/動かない以上の正確性・防御・退行検知を検証。

詳細

トランジション実装の要：クロスフェード（ディゾルブ）では A の終端と B の始端を同じ時間内に重ねるため、物理的には「繋ぎ目を足す」と見えるが動画尺としては「重なった分を引く」。ffmpeg xfade フィルタの offset 指定は「プログラム上の累積時間」ではなく「重なりを考慮した時刻」で渡す必要：累積時間から過去重なり累積を引き、さらに今回フェード長を引く多段計算でぴたりと合致。複数の接続経路（trim/silence の concat vs sequence の concat）が異なる場所で繋いでいたが、AI 利用者に「どの経路でも同じように効く」を実装で担保するため共通ヘルパに統一、分岐で従来 concat か xfade チェーンかを差し替え。フェード長がクリップより長い場合は短い側にクランプ、warning メッセージに生の数値埋め込みでなく固定文言＋インデックスで情報露出（CWE-209）防止。トランジション導入で program time が縮むため、字幕・テロップ再タイミング計算が狂う課題は v1 で「同居時に warning」で保留（厳密解は複雑）、per-boundary 混在指定は「ハードカット+ディゾルブ混在で複雑になる割に需要低い」と UNSUPPORTED で明示的削除。実機 e2e 検証：2s + 3s = 5s が 0.5s ディゾルブで 4.5s（ffprobe で測定）。シーン検出の背景：ffmpeg 素朴検出ではカット少ない映像（ゲーム実況）で 0 件。従来メッセージ「Consider lowering the threshold」では AI は「いくつに下げるか」分からない。改善：「現在 0.3、次は 0.15 を試すよ」と半値+floor(0.05) クランプを自動計算、PySceneDetect バックエンド切替提案、floor 到達時は「これ以上下げても無効。素材が 1 カット」と判定切替。warning だけでなく summary 末尾にも同ガイダンス連結し AI が双方読んでも次手に気づく設計。PySceneDetect 未インストール時のエラーは共通ヘルパが ffmpeg (winget install Gyan.FFmpeg) のデフォルト文言を返すが、scenedetect 不在のコンテキストでは的外れ。エラーハンドリングで文言を「pip install scenedetect」に差し替え、テストでモック化した ffmpeg 文言が返された後も最終出力に「pip install」が含まれて「winget」が消えていることを否定 assert で証明（将来コード変更で差し替え失敗を即検出）。

『Low 指摘1件』のために計画からやり直す ── レビュー0件主義を多エージェントで3ラウンド回した話（C3 v2.39.0）

• URL: https://zenn.dev/satoh_y_0323/articles/5125a1021b312b
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Claude Code Conductor (C3) v2.39.0 開発で「Low を含めて 0 件」レビュー規律を 3 ラウンド貫いた記録。複合 Bash (if・$()・リダイレクト) はプレフィックス一致で事前許可不可→session_guard.py 1 スクリプトに集約・1 行 allow でダイアログ恒久解消。レビュアーの誤った犯人特定 (v2.39.0 が追加)、実行役 tester が planner の is 比較を CPython タプルインターン化から AST 解析へ正す、たった 1 行重複 (Low) で計画から再開するコスト認識。セッション再起動後「現在地」1 行で続きから走り出す中断耐性。

詳細

C3 (Claude Code Conductor) は多エージェント・フレームワーク。自身の開発もワークフロー (ヒアリング→設計→計画→TDD→レビュー) で実施。縛り: 「Low 含め 1 指摘でも出たら全潰し。planner 戻り→再実装→再レビュー。0 件迄繰返」。フレームワーク本体＋実利用者ありゆえ内部品質投資。

小機能: /start 時に複数 Bash が毎回許可ダイアログ出す問題。原因: if・$()・リダイレクト含む複合 Bash は settings.json の allow がプレフィックス一致で許可不可 (静的解析不可)。Windows native 環境ではサンドボックス no-op で autoAllowBashIfSandboxed も効かず。

解: session_guard.py を 1 スクリプトに集約、mark・check・setup-mark を引数分岐。settings.json に “Bash(python .claude/skills/…/session_guard.py*)” 1 行。末尾 * プレフィックス一致で全 3 サブコマンド一発許可。複合構文消失で静的解析通、ダイアログ恒久解消・挙動完全不変・後方互換。

レビュー 3 ラウンド:

初回: code-reviewer 6 件 (M2・L4)・security-reviewer 5 件 (M2・L3)。最重要 Medium は「v2.39.0 が複合 Bash 追加したが allow 未登録」と指摘。git status/diff でファイル確認→未変更。「犯人特定」誤りだが、観察「/setup 初回実行時ダイアログ出る」は正。framing と観察を分離、正しい中身拾う決定。setup-mark も追加集約。

第 2 版: 初回 6 件全解消。security は 0。code-reviewer は新規 Low 1 件: SETUP_DONE_FLAG_REL と SETUP_MARKERS_REL[1] が同じタプル (".claude",“state”,“setup_done.flag”) 二重定義 (DRY リスク・将来誤り可能)。setup-mark 追加時に自分の修正で新重複発生。

第 3 版: たった 1 行重複のため計画からやり直す。理由: 強い規律は形骸化しにくく、例外許容始まると「次の些細」も通る。コスト直視 (6-8 回エージェント起動/ラウンド) した上で一貫。

エージェント協業の質: planner は重複検証を「SETUP_MARKERS_REL[1] is SETUP_DONE_FLAG_REL」is 比較で指示 (True=同一オブジェクト)。tester は実測で否定→CPython タプルインターン化でリテラル二重定義も is=True。代わり ast.parse で SETUP_MARKERS_REL[2 要素] が ast.Name (参照) か ast.Tuple (リテラル) か判定。計画誤りを実行役が理由付きで正す。

結果: 第 3 版 code/security 共 0 件。テストスイート 1518 pass。リリース承認→commit→tag→push→GitHub Release。

実務適用の教訓: (1) 複合 Bash は事前許可不可→1 スクリプト+1 行 allow に畳む (2) レビュー犯人特定は一次裏取り (git log/status で framing と観察分離) (3) 「全潰し」は強い規律だがコスト直視必須 (使い捨てスクリプトは Low 受容も可) (4) 計画は完璧不要・実行役の「待った」尊重で品質向上 (5) 中断耐性は「復帰後に次の一手が分かること」で初めて実用 (「現在地」1 行フィールド)。

Claude Codeのコンテキストを汚さないために作ったOSSツールの話

• URL: https://zenn.dev/shipscode/articles/3f7c3f103bcfe6
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Sipcode（MIT版OSSツール）は、Claude Codeの4時間セッションで38%重複していたファイル読み込みを削減する。ツール出力（grep・npmログ・git log）の前処理と、セッション内の同じファイル再読み込み防止によって、中央値62%のツール出力削減を実現。リリース直前にドリフトレポートと統計カウンターの83倍乖離を発見し、設計上の誤った重複排除を排除する2つの独立した計算経路の重要性を学んだ。

詳細

Claude Codeセッション中、モデルは同じファイルを複数回読み返すため、トークンコストが再度発生する。Sipcodeは詳細ツール出力をPreToolUseフックで制限し、セッション内の同一ファイル読み込みをキャッシュでき、ベンチマークは20タスク中央値62%削減。初期リリースで、セッション途中インストール時のキャッシュ漏れ（開始前ファイルの比較対象不在）による83倍の計測誤差を検出。修正では、フック起動時にアクティブトランスクリプトを走査し、過去読み込み内容をバイト正規化（改行コード・BOM削除）後に遡及埋め込み。ファイル変更時は検出して読み込みを変更なく通す。教訓は「あらゆるメトリクスには独立経路の対立メトリクスが必要」。クリーンコンテキストは品質29%向上・エラー40%削減（Anthropic研究報告）をもたらし、コスト削減は副次効果。現在はClaude Codeのみ対応、セッション内のみで永続化なし、実際の再読み込み時だけトークン節約。

作ったアプリを「使われるサービス」に育てるために考えていること

• URL: https://zenn.dev/syunpp/articles/a6398e9fabccd4
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: 個人開発で小説を音声化するアプリ「よみススメ」は月100人超ユーザーに成長。AI生成で実装は容易化したが、作ること自体が簡単ほど後発が追いつきやすく、単なる読み上げ機能では差別化不可。そこで読み上げ補正辞書・複数プラットフォーム横断推薦・ベクトルベース好み表現など、作品データを層厚くすることで「聞く小説」に特化した資産を育てる戦略を取る。

詳細

Codex等AI開発支援で実装は簡単化し、個人でもアプリ化が容易になった一方、後発も同じく追いつきやすく、UI・基本機能のみでは長期差別化困難。よみススメは読み上げ品質を「この作品はどう読ませると聞きやすいか」データ化し、個人の読書履歴大量集約ではなく作品側データを厚くする戦略採用。固有名詞・地名・キャラクター・造語の読み方補正機能を両プラットフォーム搭載、長期聞き継続で効果蓄積。複数小説サイト（Ncode等）をまたいだ推薦、ベクトル化した好み表現をサーバー送信後に照合する設計により、ユーザー詳細履歴をサーバー貯蔵しない。作品タイプ別メタ（ジャンル・雰囲気・話数・完結・聞きやすさ・似た作品・寝る前向き・通勤向き）を育成。この読み上げ補正は作品ごと蓄積＆異作品へも流用可で、単なる便利機能ではなくサービス資産化。ユーザー層も100人超で改善価値が見え始め、再生開始・継続時間・おすすめクリック率・補正辞書活用・機能別継続効果を細粒度で観測予定。スリープタイマー・バックグラウンド再生安定化・最近聞いた作品・あとで聞く機能を追加予定し、聞く→推薦が自然につながる状態を目指す。

Claude CodeでGTDを組織のプロトコルにした話

• URL: https://zenn.dev/tottoko_hamu/articles/2026-06-10-152352
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Claude Code 複数体の運用で GitHub Issues のカスタムラベル @claude + GTD ラベル (next・waiting・someday) を使い、人間と AI が同じタスク管理システムに入る委任プロトコル。AI メモリの「いつか確認しよう」堆積が GTD の「オープンループ」問題と同型だと発見。メモリ整理 (58 件→35 件) と並行して週次レビューで Issue に転記。@claude ラベルで「Claude が担当するタスク」を明示、スキルバグ修正・公開待ち・分析判断の 3 パターン、タイトル+本文+ラベルで Claude が判断なしで動ける状態作成。

詳細

Claude Code メモリ整理 (58→35 件) 中に発見: AI メモリの「いつか確認」堆積が GTD の「オープンループ」と同型。オープンループとは処理されないまま頭(またはメモリ)に残る情報。人間の頭部にも AI メモリにも同じ問題が現れる。

メモリの 3 分類: 本当に必要な運用メモ(残す)・タスク (Issue 転記後削除)・解決済み判断メモ(削除)。これが GTD の「収集→処理→整理」と対応。

AI メモリと GTD の構造対応: | AI メモリ | GTD | 対処 | | いつか確認 | Inbox (未処理) | 週次レビューで仕分け | | 繰り返し手順・設定 | Next Action | Issue にタスク化 | | 外部依存動けない | Waiting | 待ち Issue に | | 削除不可だが未使用 | Someday | someday ラベル |

気づき: 自分の GitHub Issues 管理も無意識に GTD 構造を再発明していた。Issue=Inbox・next ラベル=Next Action・waiting ラベル=Waiting・someday ラベル=Someday。

@claude ラベルの仕組み: 人間担当=@me、Claude 担当=@claude。GTD ラベル (next/waiting/someday) と組み合わせで「Claude が次にやること」を一覧化。

実装パターン (累計 38 件、2026-05-29):

1. スキル修正 (Issue #1321): バグ報告・再現手順・修正案 (A/B/C)・SSoT ファイルパスを明記。Claude は skill-dev 経由で修正・完了時 Issue close。

2. 公開待ち (Issue #1374): 時刻指定は人間・実行は Claude (スクリプト実行・結果確認・close)。waiting + @claude で「タイミング待ちの Claude 担当」を可視化。

3. 分析→判断委任 (Issue #1351): GSC データ + URL → Claude がスラッグ特定→クエリ取得→writer へのリライト判断委任。「分析後どう扱うか」を本文に記載で Claude が迷わず動く。

共通パターン:

• タイトル: 「誰が何をする」明記 ([skill-dev] プレフィックス等)
• ラベル: @claude + GTD ラベル
• 本文: 手順・SSoT・完了条件。Claude が判断なしで動ける状態。

最小手順: (1) @claude ラベル作成 (Settings→Labels) (2) Issue に委任内容・手順・完了条件記載+@claude+next ラベル (3) 週次レビューで @claude Issue 確認・完了 close・新規登録。既存 GTD 習慣にラベル 1 個追加で開始可。

メモリ管理との並行: 週次レビューで AI メモリ確認→Issue 転記できるものは転記→削除。メモリとIssue の役割分担が自然と整う。

未完成点: @claude Issue を Claude が自律的に拾うサイクルはまだ手動トリガー (週次GTD レビュー時)。自動化は今後課題。

原則: GTD は人間の脳の問題を解いたフレームワークだが、「未処理情報が溜まるとシステム機能低下」という同じ問題を持つ全システム (脳・AI メモリ・タスク管理) に適用可能。オープンループを外に出すことで、システムの処理能力が本来の仕事に集中。

Codex でも「危ない実行だけ止める」自動承認にしたい：Auto-review の設定メモ

• URL: https://zenn.dev/ytkdm/articles/codex-auto-review
• 日付: 2026-06-25
• Tier: Tier 3
• 要旨: Codex の Auto-review 機能で「危ない実行だけ止める」自動承認を実現。~/.codex/config.toml に approval_policy=“on-request” と approvals_reviewer=“auto_review” を追記すると、codex-auto-review モデルが別途起動して境界越え操作を自動判定。

詳細

Codex で Claude Code の auto approve に相当する Auto-review 機能を有効化する設定ガイド。Codex の権限モデルは approval_policy（untrusted/on-failure/on-request/never）と sandbox_mode（read-only/workspace-write/danger-full-access）の 2 軸で構成。Auto-review は人間の承認者を codex-auto-review モデルに置き換え、サンドボックス内の通常操作はレビューを通さず、境界越え操作のみ AI レビュアーが判定。設定は ~/.codex/config.toml の [features] セクション前に approval_policy=“on-request” と approvals_reviewer=“auto_review” を追記。/status コマンドで Workspace が “Approve for me” に変わっていることを確認。セッション再開時に設定が外れることがある注意点、API 使用量増加、権限自体は変更されない仕様を解説。