Claude Tagという名の新機能登場、設定・テスト・監査ログまで実践レビュー

• URL: https://blog.cloudnative.co.jp/articles/claude-tag-slack-security-review
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Tag はチームが Slack 上で 1 人の Claude と協働し、日を跨いで文脈が続く新機能ですが、セキュリティ観点では過大権限・従量課金・エラー率・定期ジョブ管理の4つのリスクがあり、これらは最小権限・監査ログ・自然言語ガードレール+アクセス設計で緩和可能です。

詳細

Claude Tag は 2026 年 6 月 23 日リリースで Opus 4.8 上で動作し、チャンネル単位で 1 人の Claude が複数メンバーと協働でき、日を跨いで文脈を保ったまま会話が続き、自律的にスケジュール実行も可能な新機能です。利点は 1 人の Claude を全員で共有でき誰かが始めた作業を別の人が引き継げること、文脈の永続化で説明し直す手間が減ること、ambient モードで能動的に情報共有すること、非同期実行で将来のタスクを自動スケジュール可能なことです。一方、セキュリティリスクは 4 つあります。1 つ目の過大権限はチャンネル単位のアイデンティティで組織内越境はないが過大スコープが本質的なリスク。2 つ目の従量課金は組織全体ハードキャップ+チャンネル個別上限の 2 層で、無限利用すると財政面での爆発があり得ます。3 つ目のパフォーマンスリスクは 2026 年 6 月の Opus 4.8 にエラー率上昇が観測されており設計上見込む必要があります。4 つ目の定期ジョブ管理は自然言語で設定するため棚卸し前提になり、一括無効化手段が乏しいのが問題です。実装では設定時に 2 か所の手順（ワークスペース・アクセスバンドル）で異なるガードレール設定を分け、デフォルト拒否で許可していないホスト到達は遮断し、各操作は Slack ユーザー・チャンネル・セッション・対象先まで帰属追跡可能です。

[アップデート] AWS Glue の Interactive Session の Spark Connect 対応を VS Code からノートブックで試してみた

• URL: https://dev.classmethod.jp/articles/20260624-glue-interactive-sessions-spark-connect
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: AWS Glue インタラクティブセッションが Apache Spark Connect をネイティブサポート（Glue バージョン 5.1 以降）。従来の Livy から gRPC + Apache Arrow ベースに変更され、SageMaker Unified Studio や VS Code・PyCharm 等のローカルIDE から AWS Glue のサーバーレス Spark に直接接続可能。著者が VS Code のノートブックから接続し、PySpark と Spark SQL を実行。エンドポイント取得・トークン認証・セッション作成を boto3 で実装し、331.892 DPUSeconds（東京リージョン約 0.04 ドル）のコストで完了。

詳細

Spark Connect はクライアントと Spark ドライバプロセスを分離するアーキテクチャ。クライアントは論理実行プラン gRPC でサーバーに送り、結果は Apache Arrow でストリーミング。従来の Livy（REST + Statement API）と異なり、PySpark remote() API で直接接続。

前提条件：検証リージョン ap-northeast-1、IAM ロール AWSGlueServiceRoleDefault で Glue Data Catalog と S3 参照、glue:CreateSession/GetSession/GetSessionEndpoint/DeleteSession と iam:PassRole 権限、ローカル Python 3.11。Spark Connect のエンドポイントはパブリック gRPC（443/TLS）、VPC セットアップ不要。

実装手順：pip install pyspark[connect]==3.5.6 で Spark Connect クライアントインストール。Jupyter カーネル登録後 VS Code で接続。SessionType=“SPARK_CONNECT” と GlueVersion=“5.1” を指定してセッション作成、READY になるまでポーリング。get_session_endpoint で URL とトークン（有効期限付き）取得、SparkSession.builder.remote() で接続。DataFrame API・Spark SQL・Temp View 利用可。セッション削除は明示的に実行して課金停止。

制限事項：セッションタイプ作成後変更不可、Statement API 使用不可、Lake Formation による細粒度アクセス制御（FGAC）非対応（フルテーブルアクセスのみ）、AWS Glue Studio では利用不可。SageMaker Unified Studio では sagemaker_studio.sparkutils で簡略化可能。Apache Spark は最近 Apache Iceberg テーブル対応が充実し、テーブル作成に Spark が必須となるケース増加。ノートブックを IaC 代わりに Git で管理できる利点。

API Gateway のプライベート API でサードパーティー DNS のカスタムドメインが使えるか確認してみた

• URL: https://dev.classmethod.jp/articles/apigateway-private-api-custom-domain-third-party-dns
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: API Gatewayのプライベート APIでカスタムドメインが利用可能になったが、Route 53以外のDNSプロバイダーでホストされたドメインも使用できるかを検証した。結果、CloudflareなどのサードパーティーDNSプロバイダーでホストされたカスタムドメインでもAPI Gatewayのプライベート APIのカスタムドメインとして設定できることが確認された。

詳細

セットアップは3つのステップで進められる。まずAPI Gateway コンソールの「カスタムドメイン名」から「ドメイン名を追加」を選択し、ドメイン名とルーティングモード（APIマッピングのみ）、セキュリティポリシー、ACM証明書を指定する。次に「API マッピングを設定」で新しいマッピングを追加し、設定したプライベート APIとステージを指定する。その後「リソース共有」タブで「ドメインの関連付けを作成」を選択してVPCエンドポイント IDを指定し、「リソースポリシー」で VPCエンドポイントからの呼び出しを許可するポリシーを入力する。DNS設定では、VPCエンドポイントの DNS名を確認してから、サードパーティーの DNSプロバイダー（Cloudflareなど）で CNAME レコードを設定する。検証では VPC内の EC2からカスタムドメインでアクセスでき、nslookupでも VPCエンドポイントの IP アドレスが解決される。CNAMEレコード設定で動作することに加え、試しに Aレコードで VPCエンドポイントの IP アドレスを直接設定した場合も同様にアクセスが可能だった。

aws loginで400エラー？ブラウザのマネコンセッションが必要な理由を調べてみた

• URL: https://dev.classmethod.jp/articles/aws-login-400-error-browser-session
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: aws login コマンド実行時に 400 Bad Request が発生する原因は、ブラウザのマネコンセッションが目的のアカウントにログインしていないこと。スイッチロール構成でベースアカウントの IAM ユーザーにだけログインしており、スイッチロール先には権限がないと 400 エラーになる。解決策はブラウザで先にスイッチロール先のアカウントにログインしてから aws login を実行すること。

詳細

aws login は AWS マネジメントコンソールにログイン済みのブラウザセッションを流用して CLI の一時クレデンシャルを取得するコマンド。2025年11月19日にリリースされた。OAuth2.0 の拡張仕様 PKCE（RFC 7636）を使い、CLI が生成した秘密文字列 code_verifier のハッシュ化値 code_challenge を URL に含める一方、code_verifier 自体は CLI から直接 /v1/token に POST する設計で、認可コードを窃取されてもトークンを盗まれない仕組みになっている。aws login の処理フローはコード生成→ブラウザ起動→認可リクエスト送信→Auth サーバーがセッション情報で判定して認可コード返却→CLI がトークンリクエスト送信→クレデンシャル発行という流れで、ブラウザのセッション情報が認可判断の材料となる。セッションが権限をもたないロール状態だと Auth サーバーは 400 Bad Request を返す。ブラウザセッション状態別の挙動は、完全未ログイン時はサインインオプション画面が表示される。ベースアカウントのみログイン（スイッチロール前）でベースアカウント IAM ユーザーに SignInLocalDevelopmentAccess がない場合、400 Bad Request が発生。スイッチロール先にログイン済みなら目的のアカウントを対象とした認可画面が立ち上がり、成功する。補足として aws login –remote オプションを使うと localhost のコールバックサーバーを使わず、URL にアクセスして返却された認可コードを手動で貼り付けるファイアウォールブロック時の回避策が可能。

aws-vault で role_arn を変えてもアカウントが切り替わらない原因はセッションキャッシュだった！

• URL: https://dev.classmethod.jp/articles/aws-vault-account-switch
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: aws-vault でプロファイル名が同じままロール ARN だけを変更すると、セッションキャッシュが古い認証情報を再利用するため、実際の認証先がアップデートされない。aws-vault clear で全キャッシュ削除、または aws-vault clear プロファイル名 で該当プロファイルのキャッシュをクリアすれば解決。本番と検証環境を切り替える際は、プロファイルをアカウントごとに分けておくことが推奨される構成。

詳細

aws-vault は STS で取得した一時認証情報をキャッシュするとき、プロファイル名を単位としてキャッシュキーを設定する。そのため同じプロファイル内で role_arn だけを本番環境に書き換えても、aws-vault は以前の検証環境アカウントで取得した有効なセッションを再利用してしまい、設定と実際の認証先に不一致が生じる。セッションキャッシュの衝突の他、本番 ARN を有効にしたまま検証だと思い込んで作業するヒューマンエラーのリスク、作業後に ARN を元に戻す手間といった落とし穴がある。推奨される方法は環境ごとにプロファイルを分けておくことで、dev と prod に分ければ清でキャッシュキーもそれぞれ異なり、clear なしで混ざらない。また command に dev/prod と表示されるので目で確認でき、作業後に設定を戻す必要もない。Terraform を実行するときは aws-vault exec prod – terraform plan のように profile をコマンドに指定し、Terraform コード内では provider の profile と region を変数に分離して管理し、毎回手動修正しないようにする。

Amazon Bedrock AgentCore Runtimeのデフォルトサービスクォータが大幅に引き上げられました

• URL: https://dev.classmethod.jp/articles/bedrock-agentcore-runtime-default-quota-increase-june-2026
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Amazon Bedrock AgentCore Runtimeのデフォルトサービスクォータが2026年6月に大幅引き上げされました。Active Session Workloads per Accountは米国リージョン（us-east-1, us-west-2）で5倍（1,000→5,000）、その他リージョンで5倍（500→2,500）に、InvokeAgentRuntime API rate（per agent, per account）は8倍（25 TPS→200 TPS）に、New Sessions creation rate（container deployment）は4倍（100 TPM→400 TPM）に増加しました。直接コード配置（direct code deploy）は25 TPSで変更なし。これらの新デフォルト値は全アカウントに自動適用されます。

詳細

Amazon Bedrock AgentCore Runtimeのデフォルトサービスクォータが2026年6月に改訂されました。変更内容は以下の通りです。Active Session Workloads per Accountはus-east-1およびus-west-2（米国東部・西部）で旧1,000から5,000に5倍増、その他リージョンで旧500から2,500に5倍増となりました。InvokeAgentRuntime API rate（per agent, per account）は旧25 TPSから200 TPSに8倍増となり、マルチテナント環境で特定エージェントへの高頻度呼び出しが集中するユースケースにおけるスロットリング問題が緩和されます。New Sessions creation rate（container deployment）は旧100 TPMから400 TPMに4倍増、direct code deploymentは25 TPSで変更なしです。これらの新デフォルト値は公式リリースノート「AgentCore Runtime default service quotas have been increased to support higher-scale workloads」に記載され、申請なしですべてのアカウントに自動適用されます。Service Quotas APIの「list-aws-default-service-quotas」（クォータコード L-3E5722B2、L-617C96C1、L-0B3AF7ED、L-FC56BC4E）で確認可能です。

Amazon Bedrock Managed Knowledge Base で画像・音声・動画のマルチモーダル RAG を構築してみた

• URL: https://dev.classmethod.jp/articles/bedrock-managed-kb-multimodal-rag
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Amazon Bedrock Managed Knowledge Base（2026年6月17日 GA）は、RAG構築におけるインフラ管理・ベクトルストア運用をAWSに任せられるサービスである。スマートパーシングとマルチモーダル対応により、PDF・PowerPoint・Word・画像・音声・動画など複数形式に自動対応し、ファイル形式に応じて最適な解析手法が適用される。Amazon S3をはじめ Microsoft SharePoint、Confluence、Google Drive、Microsoft OnDriveなどのコネクタが標準で用意されている。

詳細

マネージドナレッジベース構築の流れは4つのステップである。1) ナレッジベース作成：Bedrock コンソールから Create Managed KB を選択し、ナレッジベース名を入力。追加設定では説明・埋め込みモデル・IAMロール・ベクトルストア暗号化を設定。データソースを選択してから Advanced configurations でマルチモーダル対応を有効化。2) データソース追加：Visual content in documents（PDF・docx・ppt・pptxの画像）、Audio files（.mp3・.wav・.m4a・.flac・.ogg）、Video files（.mp4・.mov・.m4v）にチェック。Max file size はVideo files チェック時に最大10240 MB まで設定可能。Document deletion safeguard は誤削除防止。3) データ同期：作成完了後、S3 バケットに画像付きパワーポイント・日本語読み上げ音声・動画素材などをアップロードしてデータソース同期を実行。4) テスト：コンソール上からナレッジベースをテスト。埋め込み画像や音声、スライドなどを Amazon Bedrock に関する質問で検索でき、正常に参照される。動画についても Agentic retrieval with answer generation を利用して海辺の映像などが詳細に認識される。注意点として、対応リージョンは現在8リージョン（us-east-1・us-west-2・eu-west-1・eu-west-2・eu-central-1・ap-northeast-1・ap-southeast-2・us-gov-west-1）に限定。埋め込みモデルの選択は float32・1024次元のモデルに限定される。データソース容量は KB あたり データソース数200・生データストレージ10 TB・同時インジェスション50。マルチモーダル対応ではデータサイズが大きくなりやすいため、クォータ引き上げの検討が必要な場合がある。

Claude Code の skills/hooks/rules の使い分けを、公式記事の"ある軸"で整理してみた

• URL: https://dev.classmethod.jp/articles/claude-code-skills-hooks-rules-loading-axis
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Claude Code の指示を届ける7つの手段を、いつコンテキストに読み込まれるかという軸で整理した記事。常時読み込まれる CLAUDE.md と Rules、呼んだときだけ読み込まれる Skill、自動発火する Hook に分類。著者が自分の環境に当てはめたところ、11個のルール中1個が条件をもう満たしていない死蔵ルールであることを発見し、毎セッション読み込まれる行数を 387 行から 318 行に削減した。

詳細

Anthropic 公式記事「Steering Claude Code: skills, hooks, rules, subagents and more」（2026年6月18日公開）を参照軸に、7つの手段を分類。CLAUDE.md（ルート・サブディレクトリ）は常時読み込み、基本情報に向く。Skills は手動呼び出しで重い手順に向く。Hook は設定どおりに自動発火、決まりごとを確実に効かせる。Rules は毎セッション読み込まれ、条件付き制約に向く。Subagents はログ分析など本会話と切り離したタスク。Output Styles は役割そのものを切り替える。

公式が指摘する3つのアンチパターン：毎回 X したら Y する指示を CLAUDE.md に書かず Hook で自動化する、禁止事項を指示文に書かず PreToolUse フックで物理遮断する、30行の手順を CLAUDE.md に置かず Skill にしてオンデマンド読み込みさせる。根拠はトークン浪費の回避。

著者の環境で棚卸しした 11 個ルールのうち、10 個は正当な常時読み込みだった。問題の 1 個は「特定の条件に当てはまる日だけアナウンス」ルールで、参照ファイルの更新が止まっていて条件がもう満たされない状態。出力ゼロなのに約 70 行が毎回読み込まれていた。撤去後は毎セッション 387 行から 318 行に削減。「常に効かせたいか・オンデマンドか・確実に自動か」という問いで、置き場所判断と不要設定の発見が両立するという教訓。

Claude CodeとTerraformでCloudWatchの導入を省力化しよう

• URL: https://dev.classmethod.jp/articles/claude-code-terraform-cloudwatch-alarm-dashboard
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: CloudWatch の監視（Alarm・カスタムダッシュボード）構築を省力化する方法は、.tf ファイルに型と validation ブロックで構造とルールを先に固めておき、terraform.tfvars の値生成を Claude Code に任せるやり方。型が決まっていれば Claude Code の出力はブレが小さく冪等性を担保しながら工数削減できる。tfvars は Alarm 用とダッシュボード用の 2 つのルートモジュール間で流用可能。

詳細

Terraform と Claude Code の併用時、AI に触らせる範囲を限定することが肝要。.tf ファイルでは resource_name の重複排除や instance_id の形式検証（i- で始まる有効な EC2 インスタンス ID）、comparison 演算子（>、>=、<、<= のいずれか）といった validation ブロックでガードレールを張っておくことで、terraform plan 前に生成 AI のミスを弾ける。EC2 インスタンスの monitoring 例では、CPU・NetworkIn・NetworkOut のメトリクスごとに Warning と Critical の 2 種類アラート重要度を設定し、それぞれに evaluation_periods・comparison・threshold・datapoints_to_alarm を持たせる構造。main.tf は var.ec2_instances をループして（インスタンス × メトリクス × Warning/Critical）の組み合わせを aws_cloudwatch_metric_alarm に展開。ダッシュボード側の locals.tf はこれを aws_cloudwatch_dashboard の JSON ウィジェット配列に組み立てる。Alarm と dashboard の tfvars スキーマが同じなので、Alarm 作成後に cp cloudwatch-alarm-setup/_template/terraform.tfvars cloudwatch-dashboard-setup/_template/terraform.tfvars で流用可能。dashboard 側の type = any で受けるだけのシンプル形式にできるのは Alarm 側で型チェック済みだからこそ。メリットとして、型の作成と検証を人間が担当しつつ、値の作成だけ AI に任せることで、省力化と安心感を両立。生成 AI の出力がもっともらしく表記ゆれを含んでも処理が止まらず、スクリプトなら仕様変更やランタイム更新の影響を考慮する必要もない。terraform plan で中身確認後、想定外のリソース作成事象は発生していない実績あり。

【非エンジニアのためのClaude/ClaudeCodeシリーズ 】散らかった一次情報を「自分の言葉で説明できる状態」にする ── 営業がClaudeを"要約デスク"にした話

• URL: https://dev.classmethod.jp/articles/claude-sales-info-summary-template
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: 営業が散らばった複数の情報源（Slack、メール、HubSpot、提案資料等）から顧客情報を整理する際に Claude を要約デスク化した運用。初期は毎回フォーマットがブレたため、営業が常に知りたい 4 観点（キーパーソン、課題、温度感、次の一手）を型として先に定義した。「情報なし」「推測」を明示させ事実と推測を分離。この型を Claude プロジェクトのカスタム指示に登録し、以後は情報貼付だけで同じフォーマットで返されるようにした。さらに複数顧客の優先順位付けも依頼。

詳細

著者は営業部広域営業部所属。顧客情報が Slack・Google Docs・メール・HubSpot・提案資料に分散している状況で「今この顧客どういう状況だっけ」を毎回思い出す作業が情報整理のボトルネック。

段階1：単純な要約指示は毎回フォーマットがブレ、「次に何をすべきか」という営業的需要に応えられない。

段階2：営業が常に見たい 4 つの観点を型として渡す。①キーパーソンと役割②課題・きっかけ③現在の温度感（根拠も一言）④次の一手の候補を 3 つ優先度付き。加えて「読み取れないことは情報なし」「推測した箇所は推測と明示」の 2 行を指示に入れることで事実と推測の線引きが明確化。

段階3：この型をプロジェクトのカスタム指示に登録。以後は情報貼付だけで毎回同じ観点・フォーマットで返される。商談前準備が貼る・読む だけに短縮。顧客ごとに見るポイントがブレないため頭の切り替え高速化、出力を自分のメモに直接貼付可能。

段階4：複数顧客を一度に貼り温度感と次の一手やりやすさの 2 軸で優先順位付けを依頼。

運用上の配慮：社外秘・個人情報は社内ルール準拠、個人特定情報は仮名化。Claude の出力を鵜呑みにせず最後は自分で確認。型は使いながら必要に応じて追加・修正。

Codex CLI上の/appでターミナルのセッションをデスクトップアプリに引き継ぐ

• URL: https://dev.classmethod.jp/articles/codex-app-slash-command
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Codex CLI の TUI（インタラクティブセッション）内で使える /app コマンドは、現在のCodexセッションをCodex Desktopで続けるためのスラッシュコマンドである。ターミナルで調査や修正を進めたあと、途中からデスクトップアプリのスレッド一覧、worktree連携、レビュー画面などを使いたい場合に、現在の進行状況を維持したまま移行できる。

詳細

/app は TUI のセッション中に使うコマンドであり、TUIで / を入力するとコマンド候補が表示される。説明は「continue this session in Codex Desktop」である。一方、codex app [PATH] はシェルから実行するコマンドで、指定したワークスペースをDesktopで開くため用途が異なる。codex app は –help で次の内容を確認できる：[PATH] でデスクトップアプリで開くワークスペースのパスを指定（省略時はカレントディレクトリ）、–download-url でインストーラーの URL を上書きする高度なオプション。実装元の openai/codex PR #25638では /app はmacOSとネイティブ Windowsで現在の CLI スレッドをCodex Desktopに開く機能として説明される。WSLや通常の Linux では Desktop側から同じローカル状態を安全に参照しづらいため、コマンド候補に出さない方針になっている。Codex CLI 0.141.0 環境では /app がTUIの候補に表示されることが確認された。ワークスペース指定での実行は codex app /tmp/blog-verify-codex-app のようにパスを指定すると、コマンドはすぐに終了コード0で戻り、指定したパスがワークスペースとしてデスクトップアプリ側で開かれる。CLIと Desktop はどちらか一方に寄せるのではなく、作業の段階で使い分けるのが良い。ターミナルで素早く始めて必要になったら /app でDesktopへ渡す、という流れ。

htknでGitHub AppのUser Access Tokenを使い、ローカルにシークレットを置かずGitHubと通信する

• URL: https://dev.classmethod.jp/articles/ghtkn-short-lived-github-app-token
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: ghtknはGitHub AppのUser Access Tokenを使用し、ローカルにシークレットを置かずにGitHub APIを操作するCLIツールである。ローカルに保存するのはシークレットではないClient IDのみで、トークンとプライベートキーは不要。GitHub AppのDevice Flowで短命のトークンを発行し、OSのシークレットマネージャーに保存する。トークンは8時間で期限切れになるため流出リスクが大幅に減る。User Access Tokenの権限はユーザーとGitHub AppのANDであり、ユーザーに広範な権限があってもGitHub App側で制限できる。

詳細

従来のクラシック PATやファイングレイン PATと比較すると、ghtknはローカルに秘密情報を置かず、トークンの発行・更新を自動で行う点が大きく異なる。ファイングレイン PATは承認制・失効管理があるが、ghtknは Appの権限・インストールで管理される。有効期限は8時間で失効し、OSのシークレットマネージャーに保存される。セットアップはbrew install で ghtknをインストールしてから ghtkn init を実行し、$HOME/.config/ghtkn/ghtkn.yaml に GitHub Appの Client IDを記述する。初回は ghtkn get でブラウザが開き Device Flowの認可が実行され、one-time code を入力することでトークンが発行される。gh CLIと連携させるには env GH_TOKEN=$(ghtkn get) gh … と記述するか、ラップスクリプトを用意して透過的に使用できるようにする。ラップスクリプトは GH_TOKEN環境変数が設定されていない場合に ghtknからトークンを取得する仕組みである。トークンはmacOS Keychainに generic password として Client IDをキーに保存される。初回インストール時に権限とリポジトリを設定していなかった場合、権限（Issues: Read and write など）と操作先リポジトリを設定して再度実行する必要がある。ghtknは Device Flowでユーザー認証するため CI/CDのような非対話的な用途には使えないことに注意。

GuardDuty Investigation の trigger-prompt を AWS CLI でいろいろ試してみた

• URL: https://dev.classmethod.jp/articles/guardduty-investigation-trigger-prompt-cli
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: GuardDuty Investigation の trigger-prompt は AWS CLI で自由な自然言語を記述できるが、プロンプトの内容によって分析結果が大きく変わることが実験で確認された。同じ Finding（Severity 9の EC2CompromisedInstanceGroup）に異なるプロンプトを与えると、RiskLevel と Confidence の評価が変動する。シンプルなプロンプトでは Critical と High の評価だったが、IAM認証情報に焦点を当てたプロンプトでは High と Medium に低下した。

詳細

GuardDuty Investigation CLI コマンドは AWS CLI 2.35.11 以降が必要である。基本フローは create-investigation でInvestigation を作成してから get-investigation で結果を確認する。Detector IDはすべての操作に必要で aws guardduty list-detectors –region で事前取得する。trigger-prompt は自由な自然言語で記述できるが、意図を正しく認識できないと Status が FAILED になる。例えば「Analyze findings in my account」ではエラーになったが、「Analyze my account id: XXXXXXXXXXXX」のようにアカウント IDを明示するとエラーメッセージのヒントに従って成功する。3つのパターンで同じ Finding を分析した結果：1) シンプルなプロンプト「Analyze findingId: xxx」では RiskLevel=Critical、Confidence=High、リソース名はテスター環境を示していても評価は下げず。2) テスター環境を伝えるプロンプト「This instance is part of our GuardDuty tester stack…」でも RiskLevel=Critical、Confidence=High で変わらず、リソース名やスタック名は攻撃者が制御できる情報として評価低下に使わない。3) IAM 認証情報に焦点を当てるプロンプト「Focus on whether IAM credentials attached to this instance may have been compromised…」では RiskLevel=High、Confidence=Medium に低下。この場合、cryptomining の DNS クエリが GuardDuty のテスト用カナリアドメイン由来である可能性が言及され、その不確実性が Confidence の低下につながった。trigger-prompt はFinding IDを渡すだけでなく分析観点を具体的に指示することで、調査目的に合った出力が得られやすい。EventBridge と Lambda を組み合わせた自動化フローでは trigger-prompt にテンプレートを埋め込んでおくことで一貫した分析結果が得られる。

Lambda MicroVMsのライフサイクルフックで、MLモデル推論の初回待ち時間を短縮できるか試してみた

• URL: https://dev.classmethod.jp/articles/lambda-microvms-lifecycle-hooks-ml-inference-performance
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Lambda MicroVMs のライフサイクルフック（/ready・/validate）を活用し、multilingual-e5-small（118M パラメータ）の初回推論レイテンシを大幅短縮できる。フックなし：合計初回レイテンシ約 31 秒（model_load_time 18.4s+初回推論 13.0s）。/ready フック：5.5 秒（82% 改善）。/ready+/validate フック：3.4 秒（89% 改善）。/ready でモデルロード＋ウォームアップ推論をスナップショット取得前に済ませ、/validate での模擬推論でアクセスメモリページを prefetch ヒントとして記録することで段階的改善。初期化コストの高いワークロード（ML モデルロード等）では有効。

詳細

Dockerfile は public.ecr.aws/lambda/microvms:al2023-minimal をベース。torch は CPU 版（CUDA ライブラリを避けるため）、モデルファイルはビルド時ダウンロード済み。gunicorn は 8080（アプリ用）と 9000（フック用）で 2 ポート bind、–preload で worker fork 前にモデル load 完了。app.py でグローバルスコープに SentenceTransformer をロード。/ready エンドポイントでウォームアップ推論 1 回実行、/validate でも模擬推論実行。検証は ap-northeast-1、デフォルト MicroVM サイズ（4vCPU/8GB）。readyTimeoutInSeconds はモデルロード 18s+ウォームアップ数 s を考慮し 300s に設定（デフォルト 60s は不足）。フックパスは公式ガイドと異なり POST /aws/lambda-microvms/runtime/v1/ready・validate。各パターン試行で model_load_time_sec 記録値は参考値（Run 後復元レイテンシではなくビルド時記録）。

Lambda MicroVMsリリース同日に公開されたスキルで、一意性問題を考慮したコード生成を試してみた

• URL: https://dev.classmethod.jp/articles/lambda-microvms-skill-uniqueness-code-generation
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: AWS が 2026 年 6 月 22 日に Lambda MicroVMs をリリースしたその日に、agent-toolkit-for-aws リポジトリにも MicroVMs 向けスキルを追加した。SKILL.md（概要・判断基準・ワークフロー・制約・セキュリティ）と references/（詳細リファレンス群）で構成されるスキルをプロンプト先頭に付与することで、一意性問題を考慮したコード生成の確度が向上する。スナップショット一意性を題材に Kiro CLI（ヘッドレスモード）と Claude Code で各 3 回検証した結果、スキルなしは 6 回全てで /run フック未実装・グローバルスコープ session_id 生成となり、スキルありは平均スコア Sonnet 4 で 4.67/5、Opus 4.8 で 5.0/5 に達した。

詳細

スキルなしの Flask アプリは global session_id を uuid.uuid4()（ビルド時）で生成し全 VM 共有。スキルありはスナップショット復帰後の /run フック内で secrets.token_hex(8) で VM 毎に一意値を生成。Opus 4.8 スキルありでは /run 完了をリクエスト処理で wait() 待機する実装まで含まれた。snapshots-and-uniqueness.md に「Generate it in /run. This hook fires once after run (post-snapshot resume) and is the canonical place to create per-VM unique state」という記述があり、モデルがこの指示を拾って /run フック内生成パターンを選択しやすくなったと考えられる。試行ごとに生成結果はブレるため、スキルありでも安全とは限らず、本番利用では AI 生成コード対象に /run フック実装・スナップショット一意性観点でレビュー必須。

AWS Lambda MicroVMsでスナップショット由来の乱数・UUID重複を検証してみた

• URL: https://dev.classmethod.jp/articles/lambda-microvms-snapshot-random-uuid-duplication
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Lambda MicroVMs はスナップショット由来の一意性問題を抱えている。スナップショット作成時（グローバルスコープ実行）に生成した値は同一スナップショットから起動した全 VM で完全一致。random.random()・uuid.uuid4()（グローバル）・time.time()・random 状態ハッシュが 3 台 VM で全同一。/run フック時に secrets.token_hex()・uuid.uuid4() で生成した値は 3 台で全異なるが、random 状態は Mersenne Twister がスナップショット由来のまま全 VM で同じ軌道を辿り、同じ呼び出し順序なら同一値を返す。リクエスト時 /generate で secrets・uuid.uuid4() は安全だが、random.random() は危険。セキュリティトークンは secrets、一意識別子はリクエスト時 uuid.uuid4()、per-VM 論理 ID は runHookPayload で明示的注入が適している。

詳細

Python Flask アプリで BUILD_RANDOM・BUILD_UUID・BUILD_TIME・BUILD_RANDOM_STATE_HASH をグローバルで生成し、RUN_SECRET・RUN_UUID・RUN_RANDOM_STATE_HASH を /run フック内で生成。3 台の /uniqueness エンドポイント比較で、グローバル生成値は全 VM で 0.3995975096870906（random）、4f12ad9f-4985-44de-…（uuid）、1782232870.950651（time）と完全一致。/run フック で random 状態ハッシュは依然全 VM で 78bed98a6cf5fbac と同一。サスペンド→レジューム後も /run フック内の secrets.token_hex() は毎回異なる値を返したが、random.random() はスナップショット状態から継続しており同一 VM 内では前回値から続き、異なる VM 間では各々同じシーケンスを辿る。RunMicrovm API の –run-hook-payload で JSON を per-VM で渡すと /run リクエストボディに microvmId(システム付与）と runHookPayload が届く。フックのパスは公式ガイド「/run」ではなく実際は「/aws/lambda-microvms/runtime/v1/run」に届いた点注意。

「失敗の積み重ね」がLLMを生んだ — 別々の問題を解こうとした人々の80年

• URL: https://dev.classmethod.jp/articles/llm-birth-history-turing-shannon-transformer-gpt3
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: ChatGPTやClaudeは「LLMを作ろう」という目標から生まれたのではなく、80年にわたる別々の問題解決の副産物が積層されたものです。1936年チューリングは数学の完全性を証明するため「停止問題」を定義し、プログラムをデータとして扱う万能チューリングマシンの概念を生み出しました。1948年シャノンは電話ノイズの問題から「情報とは不確実性の削減」と定義し、情報エントロピーを数式化し、圧縮とデータ通信の理論を確立しました。1950～60年代のパーセプトロンと挫折、1986年バックプロパゲーション、2012年GPUによる革新、2013年Word2Vec、2014年RNNと機械翻訳、2017年Attention is All You Needによるトランスフォーマーへと進化し、それぞれが異なる領域の数学的基礎を提供しています。

詳細

LLMの起源は80年にわたる複数の科学的発見の融合です。1936年のアラン・チューリングは数学のあらゆる命題が機械化可能かを問う「決定問題」に対して、停止問題の不可解性を証明することで、計算可能性に明確な限界があることを示しました。証明過程で「計算とは何か」を定義する必要から生まれたチューリングマシンと万能チューリングマシン（プログラムをデータとして扱う）の概念が、現代のコンピュータアーキテクチャ（ノイマン型）の基盤となっています。1948年のクロード・シャノンは電話回線のノイズ問題から出発し、「情報とは予測不可能性（エントロピー）」と定義し、情報理論を確立しました。この理論はデータ圧縮（JPEG、MP3、BPE符号化）、LLMの訓練損失（クロスエントロピー）、推論時のTemperatureパラメーター制御すべてに適用されています。1958年のパーセプトロンは「機械がデータから自分でルール発見できる」可能性を示しましたが、1969年にミンスキーとペパートがXOR問題で学習の限界を証明、第一次AI冬をもたらしました。1986年のバックプロパゲーション（ルメルハート、ヒントン、ウィリアムズ）がこの「ただし多層ネットワークなら…」の問題を解きましたが、計算速度が実用的ではありませんでした。2012年のAlexNetはGPUの並列処理能力（行列演算の同時実行）によって訓練速度を数週間から数日に圧縮し、深層学習の実用化を実現しました。2010年代の勾配消失問題はReLU活性化関数と残差接続（ResNet）により克服されました。2013年のWord2Vec（Google・ミコロフ）は「単語を意味のあるベクトル座標に変換する」Embeddingを実現し、意味の演算（王様―男性＋女性≈女王）を可能にしました。コサイン類似度による意味距離の測定は現在のRAG検索基盤となっています。2014年以降、RNN（再帰型ニューラルネットワーク）は順序依存的な言語処理に対応し、機械翻訳がこの技術的課題の主戦場となりました。2017年のVariswani et al「Attention is All You Need」がトランスフォーマーアーキテクチャを提案し、並列処理能力とAttention機構が言語モデルの大規模化を可能にしました。LLM全体を支配する一つの数学的フレームワーク（Shannonの情報理論）が、電話工学から80年後に「賢さの定義」と「創造性の調整」の両面で機能しています。

NVIDIA Japan の NPN Partner Agentic AI Bootcamp に参加してきました

• URL: https://dev.classmethod.jp/articles/nvidia-npn-agentic-ai-bootcamp-report
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: NVIDIA JapanとマクニカはNPN（NVIDIA Partner Network）パートナー限定のエージェント開発ハンズオン「Japan NVIDIA NPN Partner Agentic AI Bootcamp」を2026年6月17日に開催しました。教材はApache 2.0で公開（openhackathons-org/agentic-ai-bootcamp）され、NVIDIA NIM・Model Context Protocol（MCP）・LangGraph・NeMo Agent Toolkitを1日で学習できます。5つのLab（推論エンドポイント・MCP入門・ローレベルMCP・LangGraph・NAT＆Phoenix）の後、架空のレコード販売店「Harmony Records」を題材にした実装Challengeで技術を統合する構成です。開発とLocal/Cloud NIMの切り替え、MCP層とAgent Skill層の役割分離、コード化されたLangGraphから運用可能なNAT YAMLへの階層化が重要ポイントです。

詳細

NVIDIA Japan・マクニカ・OpenACC organizationは2026年6月17日に品川で「Japan NVIDIA NPN Partner Agentic AI Bootcamp」を開催し、NPN（NVIDIA Partner Network）パートナー企業向けの終日ハンズオンを実施しました。教材リポジトリ（openhackathons-org/agentic-ai-bootcamp）はApache 2.0で公開されており、社内勉強会での再利用が可能です。アジェンダはLab 1（NVIDIA NIM：CloudとLocal Docker）から始まり、Lab 2（FastMCPによるMCP入門）、Lab 3（低レベルMCP SDK＋Starlette HTTP実装）、Lab 4（LangGraphの State/Node/Edge及びReActエージェント・interrupt機構）、Lab 5（NeMo Agent Toolkit の YAML宣言・Phoenix トレース可視化）を順に進め、最後にHarmony Records（架空レコード販売店）のカスタマーサポートエージェントを MCP で拡張するChallenge（Invoice MCPサーバー、QnA Agent Skill、LLM Workflow、NAT Workflow）で技術統合を検証します。技術的な整理ポイントとしては、MCPは「どんなツールが使えるか」のレイヤー、Agent Skillは「どう組み合わせるか」のレイヤーという役割分離、LangGraphで書いたエージェントをNAT YAMLで宣言的に再構成することで横展開時の柔軟性が得られること、Cloud NIMとLocal NIMのAPIスキーマ互換性により環境切り替えが容易なこと、Brev環境の事前配布と dry-runサポートによる環境構築トラブル回避があります。実装上の注意としては、Low-level MCP の inputSchema が JSON Schema 標準であり型ズレによるバリデーションエラーが原因不明になりやすく、nat mcp client CLI で素のレスポンスを確認する手法が推奨されています。

Omni のスケジュール・アラート機能を試してみた

• URL: https://dev.classmethod.jp/articles/omni-share-content-with-schedules-n-alerts
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Omni のスケジュール・アラート機能は、ダッシュボード・タイル内容の定期配信と条件ベース通知を提供。スケジュールは指定時刻定期配信（毎朝 KPI 送信など）、アラートは設定条件満たし時のみ配信（異常検知など）。配信先は Email・Slack・Google Sheets・Amazon S3・SFTP・Webhook の 6 種類。フォーマットは PNG・PDF・XLSX・CSV。Email では受信者のユーザー属性でデータ個人化可能（ブランド担当者に自社ブランドデータのみ）。アラート条件は結果変更時・結果不変時・結果なし・結果ありの 4 種。データ権限は作成者認証情報で実行がデフォルト、個人化有効時は受信者ユーザー属性適用。

詳細

スケジュール設定：ダッシュボード開く → File → Deliveries & Alerts → New delivery で Email 選択 → コンテンツ選択（全体/特定タイル） → 配信頻度設定（Daily/Weekly など） → フォーマット選択+カスタマイズ → 受信者追加（組織内/外部/グループ） → Test Now で確認 → Save。受信者個人化：Personalize delivery with the recipient’s user attributes をオン。アラート設定：同じく File → Deliveries & Alerts → 条件選択（結果変更時/結果不変時/結果なし/結果あり） → 配信先・フォーマット・受信者設定。管理者権限で Settings > General > Content permissions（インスタンス側）と File > Document Settings（ドキュメント側）で配信作成権限制御。

【PostgreSQL】UUIDv4とv7のパフォーマンスとインデックス断片化を比較する

• URL: https://dev.classmethod.jp/articles/postgresql-uuid-v4-v7-performance-index-fragmentation
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: PostgreSQL でテーブル主キーに UUID を使う場合、UUIDv4（完全ランダム）と v7（タイムスタンプ＋時系列順）のパフォーマンス差は顕著。v4 は B-Tree インデックス挿入時にランダム位置への挿入となるため、ページ分割が頻発し、100 万件後の追加 INSERT パフォーマンスで v4 が v7 の 3～5 倍遅い（100 件投入：v4 0.04s vs v7 0.008s）。ストレージでも v4 は v7 より 16MB 多く（200MB vs 184MB）、インデックス断片化が顕著（avg_leaf_density v4 67.28 vs v7 89.99、leaf_fragmentation v4 49.69 vs v7 0.0）。UUID 型とテキスト型では UUID 型が効率的（テキスト：259MB vs UUID：184MB）。生成時刻推測がセキュリティリスクでなければ v7 推奨。

詳細

PostgreSQL では gen_random_uuid（v4）、PostgreSQL 18 で uuidv7 関数追加。ページ分割の仕組み：8KB ページ単位、ページ内満杯で新ページ追加・既存データ移動。v4 はランダム挿入位置で頻発、v7 は末尾付近挿入で低頻度。検証：users_v4（UUID 型+v4）、users_v7（UUID 型+v7）、users_v7_text（TEXT 型+v7）に 100 万件投入。追加 INSERT テスト：100 件（v4 0.04s/v7 0.008s）、1,000 件（v4 0.22s/v7 0.02s）、10,000 件（v4 0.6s/v7 0.15s）、10 万件（v4 2.9s/v7 1.7s）。1,545,300 件後ストレージ：users_v4 total 200MB（table 137MB+index 62MB）、users_v7 total 184MB（table 137MB+index 47MB）、users_v7_text total 259MB（table 172MB+index 87MB）。pgstattuple 拡張で断片化確認。キャッシュ効率でも v7 優位（最近データ頻繁アクセス時にキャッシュヒット率向上）。

SaaS に AI 機能を追加するときの料金設計を各社事例と COMPASS フレームワークで整理してみた

• URL: https://dev.classmethod.jp/articles/saas-pricing-compass
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: SaaS に AI 機能を追加する際、従来のシート課金と別に AI 利用量を課金するハイブリッド構造が標準化している。AWS・Zuora・Simon-Kucher が共著したホワイトペーパー「The AI pricing pivot」で紹介される COMPASS フレームワークは、AI の課金メトリクスを4つに分類（エージェント単位・アクティビティ単位・アウトプット単位・アウトカム単位）し、「AI の仕事の範囲」と「成果帰属の明確さ」の2軸マトリクスで最適メトリクスを導く。14問の検証チェックリストで候補メトリクスのトレードオフ（価値連動・帰属明確性・わかりやすさ・公平感・拡張性・予測可能性・収益性）を可視化し、弱点が見つかったらハイブリッド設計パターン（定額+上限・ティア制・クレジット制など）で補完する。Kyle Poyar 氏の調査ではシートベースは 21% から 15% に低下し、ハイブリッド課金は 27% から 41% に急増している。

詳細

Salesforce Agentforce は 1 会話 $2 で開始し 2025 年 5 月に Flex Credits（1 アクション≒$0.10）を追加。GitHub Copilot は Business $19/ユーザー/月+高性能モデル $0.04/リクエスト。HubSpot Breeze は 1,000 クレジット/$10、解決会話/$0.50。Notion は Business 以上に AI 内包し Custom Agent のみクレジット制。COMPASS フレームワークでは、カスタマーサポート SaaS の AI チャットボットは「プロセス管理 × 帰属明確性中～強」でアウトプット単位（解決件数）を推奨。ナレッジ管理 SaaS の議事録要約 AI は「タスク自動化 × 帰属明確性弱」でエージェント単位（定額）を推奨するが、14 問検証でヘビーユーザーの推論コストが売り手を圧迫するリスクが見えれば定額+月間上限・ティア制・クレジット制で調整する。Salesforce・HubSpot は既存モデルを残しながら新モデルを追加し、Notion は上位プラン内包で既存顧客に無料期間を設定するなど段階的に移行している。

【非エンジニアのためのClaude/Claude Codeシリーズ】 AIを信用しすぎてヒヤッとした話とファクトチェック術 【AI活用基本のキ】

• URL: https://dev.classmethod.jp/articles/sales-factcheck
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Claude を含む AI は知らないことも自信たっぷりに答えてくるハルシネーション（幻覚）という特性を持つ。営業が特に注意すべき 4 つのポイントは、売上や達成率などの数字、企業名やサービス名といった固有名詞、○○社の調査などの出典・引用、料金やサービス内容など情報の鮮度。ファクトチェック術として、最初から根拠を出典とセットで出してもらい、怪しいところは Claude 本人に聞き返し、外せない数字は一次情報で必ず確認し、検証ルールを CLAUDE.md に仕込んでおく。

詳細

AI のハルシネーションは不十分なトレーニングデータ、誤った仮定、データバイアスなど複数の要因で発生する仕組み上の問題であり、Claude が優秀でないわけではなく「起きる前提」で付き合う必要がある。営業の実務では数字（売上・達成率・単価・前年比）、固有名詞（企業名・サービス名・メンバー名）、出典・引用（○○社の調査が本当に存在するか、それっぽい URL が創作されていないか）、鮮度（学習時点の区切りで古い情報のまま最新と語る）の 4 つを特に注意。実際のファクトチェック手法として、最初から「根拠も一緒に出して」と要求して怪しいところを見えるようにしておく方が後から疑うより安心。気になる数字が出たら遠慮なく聞き返し「この根拠は？」「どのくらい自信ありますか？」と問うと「確かな出典がありません」と白状することがしばしばある。売上やお客様に関わる絶対に外せない数字は、Salesforce などの社内データや元の資料と必ず突き合わせる。毎回同じ検証ルールを指示するのは面倒なので、Obsidian Vault の CLAUDE.md に数字・固有名詞には出典を明記、不確かな情報は「※推測」と明記して断定しない、最新性が重要な情報は鮮度を添えるといったルールを仕込んでおく。結果として「全部任せる」より「下書きは任せて、最後の数字だけ自分が握る」やり方が最も安全。疑う仕組みがあると、逆に安心して大胆に下書きを任せられるようになり、最初から根拠を見えるようにしておくほうが後から疑うより楽に壁打ちができる。

【Security Hub修復手順】[EKS.9] EKSノードグループは、サポートされているKubernetesバージョンで実行する必要があります

• URL: https://dev.classmethod.jp/articles/securityhub-fsbp-remediation-eks-9
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Security Hubの「EKS.9」コントロールは、EKSマネージドノードグループがスタンダードサポートのKubernetesバージョンで実行されているかをチェックしている。スタンダードサポート終了後のバージョンで稼働し続けるとセキュリティパッチの遅延や互換性問題が生じるため、計画的な更新が必須である。

詳細

修復手順は2段階である。まずクラスターのコントロールプレーンをアップグレードする。2026年6月時点ではKubernetesバージョン1.32は拡張サポート、1.33以降がスタンダードサポートである。アップグレードは1マイナーバージョンずつ行う必要があり、コンソールから「バージョンをアップグレード」を選択して実行できる。次にノードグループをアップグレードする。コントロールプレーンの更新完了後、対象クラスターの「コンピューティング」タブでノードグループの詳細画面を開き、「今すぐ更新」を選択する。更新戦略は2種類ある：ローリング更新は本番環境向けでPod Disruption Budgetを尊重し、強制更新は迅速性を重視して検証環境向けである。注意点としてKubernetesバージョンアップグレードは1マイナーバージョンずつ行う必要があり、コントロールプレーン→ノードグループの順序を守る必要がある。本番環境ではローリング更新とPDB設定を推奨し、スタンダードサポート対象バージョンはAWSによって更新されるため公式ドキュメントで最新情報を確認すること。

EC2 の起動・停止をタグで自動化する ❘ EventBridge Scheduler × Lambda 構成

• URL: https://dev.classmethod.jp/articles/start-stop-lambda-eventbridge
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: 複数 EC2 インスタンスをタグで絞り込み、Lambda と EventBridge Scheduler を使用して自動起動・停止をスケジューリングする方法。対象インスタンスに AutoSchedule=true タグを付与。Lambda 関数 2 種（起動用・停止用）を作成し、ec2.describe_instances でタグとインスタンス状態でフィルタして対象を絞り込み、StartInstances/StopInstances を実行。EventBridge Scheduler で cron ベース（平日 8:00 起動・20:00 停止など）のスケジュール設定。CloudWatch Logs で実行結果確認。インスタンス台数増加時もタグ管理で対応可能。

詳細

前提条件：対象 EC2 インスタンス存在、マネジメントコンソール操作権限。

タグ設定：キー AutoSchedule、値 true をタグエディタで対象インスタンスに付与。

IAM ロール2種：Lambda 用ロールはログ出力（CreateLogGroup・CreateLogStream・PutLogEvents）と EC2 操作（DescribeInstances・StartInstances・StopInstances）権限付与。EventBridge 用ロールは lambda:InvokeFunction 権限で起動用・停止用関数の ARN を Resource に指定し実行対象絞込。信頼エンティティは scheduler.amazonaws.com。

Lambda 関数実装：起動用は tag:AutoSchedule=true かつ stopped 状態、停止用は tag:AutoSchedule=true かつ running 状態でフィルタ。describe_instances で対象 InstanceId を抽出、start_instances/stop_instances で実行。対象がない場合は return で空実行。

EventBridge Scheduler：定期的な cron ベーススケジュール（東京タイムゾーン）。起動用 cron(0 8 ? * MON-FRI *)、停止用 cron(0 20 ? * MON-FRI *)。テンプレート化ターゲット AWS Lambda (invoke) で関数を指定、EventBridge 用ロール付与。

検証方法：インスタンス状態確認 → Lambda テストイベント実行 → OUTPUT で InstanceId 確認。スケジュール実行時刻に EC2 が起動・停止、CloudWatch Logs に実行結果出力で成功判定。SSM オートメーション方法も参照資料に言及。

Terraformコードレビュースキルを作って Claude Code GitHub Actions で Pull Request を自動レビューしてみた

• URL: https://dev.classmethod.jp/articles/terraform-review-skill-claude-code-github-actions
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Claude Code のカスタムスキルを使用して Terraform のコードレビューを GitHub Actions で自動化する方法を紹介している。スキル側に HashiCorp 公式ガイドとセキュリティ・スタイル知識を全て埋め込み、重大度は HIGH・MEDIUM・LOW の3段階で分類。ローカル検証後、GitHub Actions ワークフローで PR の差分をレビューし、指摘をインラインコメント、全体サマリをトップレベルコメントで投稿する実装を示している。コスト約 0.55 ドル/実行。

詳細

スキルは .claude/skills/terraform-review/ に配置し、SKILL.md でレビュー作業手順を定義。重大度の基準は本番実害（漏えい・全公開・データ消失・権限過剰）を HIGH、ベストプラクティス違反で事故時影響が大きいものを MEDIUM、規約・可読性・保守性違反を LOW と固定している。出力は1行サマリの後、重大度順に整列し、修正例は最小 diff で示す指示を与えた。

検証例では SSH 22 番ポートの 0.0.0.0/0 全開放を HIGH と検出、SSM Session Manager 経由への変更を提案。仕込んだ全問題（IMDSv2 未強制、ルート EBS 非暗号化、リージョンハードコード、Name タグ欠落等）を重大度どおりに検出。

GitHub Actions ワークフロー（actions/checkout + anthropics/claude-code-action）は PR 開時・同期時に走行、terraform-review スキルを呼び出してレビュー実行。指摘は mcp__github_inline_comment__create_inline_comment で該当行へ、全体サマリは gh pr comment でコメント投稿。認証は API キーまたは OAuth で対応可能。所要時間約4分、モデルは claude-sonnet-4-6。

詰まり点はコメント投稿ツール許可漏れ。permission_denials_count で拒否回数が増加していたため claude-execution-output.json を artifact 保存し tool_use を確認して原因特定した。

Aurora ヘッドレスクラスターで Secrets Manager 管理有効化時に “Unable to reset your password” が出た理由

• URL: https://dev.classmethod.jp/articles/yutaka-memo-rds-events-unable-to-reset-password
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: Aurora ヘッドレスクラスター（DB インスタンスなし）で Secrets Manager によるマスターユーザーパスワード管理を有効化すると、RDS イベントに Unable to reset your password（DB cluster has no instances available to perform master password reset）が出力される理由を分析。通常のパスワード変更では MasterUserPassword パラメータを指定し、Secrets Manager 管理では ManageMasterUserPassword パラメータを指定する別の API 操作。後者はパスワード生成・管理に加え、DB 側への反映にも対応する Writer インスタンスが必要だが、ヘッドレスクラスターには存在しないため出力される。新しい Writer 作成時に適用される予定。

詳細

Aurora の Secrets Manager 管理有効化では、Aurora がパスワード生成・Secrets Manager で管理。Secret 側と DB クラスター側のパスワードを同期させる必要があり、パスワード反映にはWriter DB インスタンスが必須。

API パラメータの違い：通常マスターパスワード変更は MasterUserPassword を指定、Secrets Manager 管理有効化は ManageMasterUserPassword を指定。公式ドキュメントでも同時指定不可と記載。

実検証：ap-northeast-1 リージョン、headless-test クラスター、Writer インスタンスなし作成。modify-db-cluster で–master-user-password を指定した通常変更ではエラーなく完了、RDS イベントにもパスワードリセット失敗メッセージなし。一方–manage-master-user-password を指定した Secrets Manager 管理有効化では、PendingModifiedValues に MasterUserPassword、MasterUserSecret に SecretStatus: creating が表示され、RDS イベントに Unable to reset が出力。

原因：Secrets Manager 管理で生成されたパスワードを DB 側に反映するには Writer インスタンスが必要だが、ヘッドレスクラスターには存在しないため出力。イベントメッセージに Your new password will be applied once a new writer is created と含まれており、致命的エラーではなく保留状態。

Claude Code / Codex の全社展開とAI観測基盤の設計 | ドクセル

• URL: https://docswell.com/s/rakutek/59NR49-2026-06-04-194729
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Code・Codex・Cowork を OpenTelemetry で一元計測し、MDM で managed-settings.json を全社配布することで複数プラン混在環境でも全員カバーが達成でき、Grafana Cloud で OTel 標準に乗っけることで可視化基盤の自由度が生まれます。

詳細

クラシル株式会社による全社展開事例で、Claude Code・Codex・Cowork 三者が OpenTelemetry（OTel）にネイティブ対応している点が技術的基盤になります。全社導入後の課題は利用実態の可視化で、管理者個別ヒアリングは数百人規模では現実的でないため定量観測が必須です。3 段階アプローチは、1 つ目に全社員からのログ収集（OTel × MDM で managed-settings.json を Jamf で全 macOS に一括配布）、2 つ目に Codex CLI も同じ仕組みに乗せる横展開、3 つ目に GitHub・Notion アウトプットに成果を接続することです。実装では、Claude Code・Codex で取得できるフィールドに差（Claude は cost_usd で実額が取得可能だが Codex では cost_usd がないため使用モデル×トークン数で概算）があるため個別対応が必要であり、service_name でソースを見分け、単一の Grafana Cloud エンドポイントに流すことで後々の可視化基盤乗り換えが容易になります。プロンプト本文は オプトインで log_user_prompt フラグを明示することで、ユーザーの懸念に応答しながら計測可能です。

Windows Time サービスによる時刻同期の基本と w32tm.exe コマンドについて

• URL: https://jpwinsup.github.io/blog/2026/05/28/ActiveDirectory/WindowsTimeService/w32time-Introduction
• 日付: 2026-06-24
• Tier: Tier 1
• 要旨: Windows Time（w32time）サービスはNTP（Network Time Protocol）に従い、UDP 123番ポートで信頼できる時刻ソースから定期的に時刻を取得して補正します。Kerberos認証が有効期間（チケット）に依存するため、ドメイン環境では時刻同期が認証成功の前提条件となります。Active Directory環境では、フォレストルートドメインのPDCエミュレーターが外部NTPサーバーと同期し、他のドメインコントローラーおよびドメインメンバーコンピューターが階層的に同期されます。w32tm.exeコマンドで同期状態や設定を確認できます。

詳細

Windowsタイムサービス（W32Time）は標準搭載のNTPクライアントで、UDP 123番ポートを使用して信頼できるNTPソースから定期的に時刻を取得し、システムクロックを補正します。Kerberosベースの認証では「チケット」に有効期間が含まれており、クライアント・ドメインコントローラー・サービス間で時刻が大きくずれていると認証が失敗する可能性があるため、ドメイン環境における時刻同期は重要です。Active Directory環境ではフォレストルートドメインのPDCエミュレーターが外部NTPサーバーと同期し、その他のドメインコントローラーは最大6個のクエリを活用して同期先を選択（通常はPDCe）、ドメインメンバーコンピューターは認証先のドメインコントローラーと同期します。w32tm /query /statusで現在の同期状態確認、w32tm /query /configurationで設定確認、w32tm /resync /rediscoverで手動同期実行、w32tm /stripchart /computer:<NTPサーバー名> /dateonlyで特定サーバーとの時刻差確認が可能です。WORKGROUP環境やMicrosoft Entra Joinのみの環境ではサービスが手動設定のため、コマンド実行前に起動が必要な場合があります。

Windows タイム サービスの Parameters レジストリ パラメーターについて

• URL: https://jpwinsup.github.io/blog/2026/05/28/ActiveDirectory/WindowsTimeService/w32time-Parameters
• 日付: 2026-06-24
• Tier: Tier 1
• 要旨: Windowsタイムサービス（w32time）のレジストリパラメーター（Parameters配下）について解説したマイクロソフト公式資料です。時刻同期方式を決定する「Type」パラメーターは4種類（NTP、NT5DS、AllSync、NoSync）を設定可能で、NTPサーバーはNtpServerレジストリで複数指定可能です。各NTPサーバーにはフラグ（0x1～0x8の組み合わせ）を付与して同期モードを制御でき、SpecialPollIntervalで間隔を調整できます。設定確認はw32tmコマンドまたはレジストリエディターで行い、変更後はサービス再起動またはw32tm /config /updateで反映させます。

詳細

Windowsタイムサービスのレジストリキー HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters配下の各パラメーターを体系的に説明します。Typeパラメーター（値の名前：Type、種類：REG_SZ）で時刻同期方式を決定し、4つのオプション（NTP、NT5DS、AllSync、NoSync）を選択できます。NtpServerパラメーター（値の名前：NtpServer、種類：REG_SZ）ではスペース区切りで複数のDNS名またはIPアドレスを指定可能で、末尾にカンマ区切りでフラグ0x1～0x8を付与して同期モードを制御します。よく利用される組み合わせは0x9（SpecialInterval + Client）で、SpecialPollInterval（レジストリキー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient、種類：REG_DWORD）で秒単位の間隔を指定します。w32tm /query /configurationで現在の設定を確認でき、変更後はサービス再起動またはw32tm /config /updateで設定を反映させます。グループポリシーで管理されている場合、レジストリ直接変更は上書きされる可能性があるため注意が必要です。

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

• URL: https://jpwinsup.github.io/blog/2026/06/12/Shell/Explorer/OneDriveIsNotAccessibleFromExplorerAfter202606Update
• 日付: 2026-06-24
• Tier: Tier 1
• 要旨: Windows 11（バージョン24H2・25H2）に2026年6月の更新プログラム（KB5095093）を適用後、エクスプローラーの左ペインのOneDriveアイコンをクリックしても反応しない問題が報告されています。マイクロソフトはプレビュー更新プログラムで問題を解消し、7月以降の月例更新に修正を含める予定です。暫定対処として、エクスプローラーの右ペインで C:\Users<ユーザー名> を参照するか、ブラウザでオンラインアクセスが可能です。

詳細

対象バージョンはWindows 11バージョン24H2および25H2。事象はKB5094126適用後に生じ、エクスプローラーからOneDriveにアクセスできなくなります。マイクロソフトサポート部門はプレビュー更新プログラムKB5095093の適用で問題が解消することを確認済みで、2026年6月24日に公開しました。修正内容は7月以降の月例更新にも含まれる予定です。暫定対処法として、エクスプローラーの右ペインからローカルパスを参照することで参照と編集が可能で、ブラウザからのオンラインアクセスも可能です。

TypeScriptコンパイラをGo言語に移植することで10倍速にしたTypeScript 7.0リリース候補版が登場

• URL: https://www.publickey1.jp/blog/26/typescriptgo10typescript_70.html
• 日付: 2026-06-24
• Tier: Tier 2
• 要旨: マイクロソフトが TypeScript コンパイラを Go 言語に移植した最初のバージョンとなる TypeScript 7.0 リリース候補版をリリースした。ネイティブバイナリ化と並行処理により、コンパイル速度が従来の 10 倍高速化。Language Server Protocol（LSP）に対応したランゲージサービスなども Go でネイティブバイナリ化され、大規模コードベースへのスケーラビリティも実現。Google・Notion・Slack・Vercel など外部協力会社でも利用が始まりポジティブな評価を得ている。npm install -D typescript@rc でインストール可能。

詳細

TypeScript は JavaScript に型システムを追加し、JavaScript の将来のバージョンで組み込まれるであろう機能を備えて、コード品質と読みやすさを高める開発者体験を実現するプログラミング言語。TypeScript で記述されたコードは TypeScript コンパイラ（トランスパイラ）によって JavaScript に変換されて、Web ブラウザや Node.js で実行される。従来のコンパイラは TypeScript 自身で記述され、Node.js パッケージとして導入・実行される。2026年6月18日発表の TypeScript 7.0 リリース候補版の構成は、TypeScript コンパイラを Go 言語に移植することで、ネイティブバイナリ化と並行処理を実現してコンパイル速度が 10 倍高速化。大規模コードベース対応のスケーラビリティが向上し、Language Server Protocol（LSP）に対応したランゲージサービスなども Go でネイティブバイナリ化されてより快適な実行が可能。マイクロソフト社内だけでなく、Google・Notion・Slack・Vercel などの外部協力会社でもすでに利用が開始されており、ポジティブな評価を得ているという報告。2026年6月18日の Twitter（現 X）投稿でアナウンスされた。

GitHub Issue を立てるだけで、VPS が代わりに作業してくれる基盤を作った

• URL: https://zenn.dev/ai_lifehackdays/articles/github-issue-vps-runner
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: GitHub Issueをトリガーに自分のVPS上でCLIジョブを非同期実行し、終了後に結果をIssueコメントで返す作業基盤ai-councilを開発。PCの前にいなくてもスマホから必要な作業をIssueで投げておき、帰宅時には完了という非同期性を実現。VPS上でCodex CLIを動かす仕組みで、思いついた時点と手を動かせる時点のズレを解消。allowlist・secret管理（VPS側のみ保管）・ai_exec の制約（git push・PR作成・secret作成禁止）・入力・実行時間・頻度の上限設定で安全性を先に固めた。

詳細

ai-councilはGitHub Issueをラベル付き投げるとVPSが定期的に拾ってジョブ化し、VPS上のCodex CLIで作業実行、結果をIssueコメントで返すシステム。作業を3レーン（ai_plan：計画のみ、ファイル非操作；ai_check：リポジトリ読み取り検査；ai_exec：ファイル編集まで実行）に分けて重さで使い分け。内部ではVPS側がCodex CLI本体を動かすため、「AIが勝手に考えて動く」大層なものではなくCLI実行肩代わり係。セキュリティはallowlist（Issueトリガーの投げ手制限）・secret分離（鍵・トークンはVPS側のみ）・ai_execの制約明確化（git push・PR作成・secret作成禁止）・入力サイズ・実行時間・実行頻度の上限設定で構造的に担保。便利さのため雑にするのではなく「やれないこと」を先に確定させる設計。MIT ライセンス公開。

Claude Codeに「昨日の続き」を覚えさせる — 人間の記憶構造をMarkdown＋BM25で実装した話

• URL: https://zenn.dev/answer_philo/articles/2410b4271ee46e
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Code との半年の運用で「昨日の続き」を忘れない仕組みをMarkdown + BM25 検索で実装。セッションをまたいだ長期記憶を、frontmatter のメタデータで層（意味記憶・手続き記憶・エピソード記憶）に分類し、ファイル単位で保持。起動時に今日・昨日の日常記憶を自動注入するフック設定で、記憶喪失を構造的に回避。

詳細

記憶を設計する際に「昨日の昼飯」と「人生の決断」を同じログに混ぜないことを出発点に、answer-diary/ を daily/（流れる記憶）と impressions/（一生残る少数の瞬間）に二分。frontmatter で type（user/feedback/project/reference）を指定し、これを Semantic・Procedural・Episodic・Knowledge の4層にマッピング。検索時に層ごとの絞り込みが可能。ベクトル DB でなく BM25（キーワードベース古典的スコアリング）を採用した理由は、API・GPU・常駐プロセス不要（その場スキャンで一瞬）で、スコア算出の根拠を人間が追える（埋め込みのブラックボックス回避）。memory_search.py で frontmatter を読みつつ全ファイルスキャン。sessionstart フック（settings.json）で daily_recall.py を自動実行し、今日・昨日の daily/ を意志ではなく構造でコンテキストに強制注入。書き込みルール「1ファイル1事実・frontmatter 必須・なぜ/どう適用まで書く」が検索後の実用性を左右。

Google翻訳をオンにしたら、Hyperagentが壊れた

• URL: https://zenn.dev/ara_ai/articles/188cdd1bbfd3a7
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Hyperagent での DOM エラー「‘removeChild’ を実行できませんでした：削除対象のノードはこのノードの子ではありません」の原因と解決記。Google翻訳をオンにしていたことが原因。Google翻訳はページテキストを翻訳する際、HTML上のテキストノードを font タグで包む処理を行う。Hyperagent は React で構築されており、React は自分が管理する DOM 構造を把握した上で操作する。Google翻訳が font でDOM を書き換えると、React の認識する構造とズレが生じ、削除しようとしたノードが見つからないエラーが発生した。解決策は Google翻訳をオフにするだけ。

詳細

React アプリと DOM 書き換え機能の競合。エラーメッセージには Hyperagent の名前は出ず、removeChild という低レベル API 呼び出しのみ記述されていた。著者は removeChild というメッセージを読んで「DOM操作に失敗した」と理解し、「自分が何か変なことをしていないか」を考えたときに Google翻訳機能に気づいた。ブラウザ拡張機能が DOM を触ると React アプリが壊れるのはよくある話で、Google翻訳以外の拡張機能でも同じ現象が起きうる。実装レベルでは Google翻訳の font ラッピング戦略と React の DOM 管理戦略が衝突し、React の仮想 DOM と実 DOM の同期ズレが生じたケース。

個人開発が増えすぎて迷子になる前に ― 8カテゴリ台帳とsymlinkツリー

• URL: https://zenn.dev/bokuwalily/articles/project-categorization
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: 個人開発が増えると「どこにあるか」「状態は」が散逸する。40 超のプロジェクトを 8 カテゴリに分類し、symlink ツリーと台帳で管理。核は実体 dir を動かさないこと（.vercel・launchd・git worktree の絶対パス依存が壊れる）。提供形態で分類すれば名前による誤分類を防げ、CLAUDE.md に「着手前に分類」と書いておくと Claude が毎回自動で実施。

詳細

個人開発の分類・整理システム

困りごと：40 超のプロジェクトが ~/dev / ~/Projects / ~/digital-products に散らばり、毎回 find で探し直す。状態・本番 URL・収益化の有無も散逸。

8 カテゴリ戦略：01-webapp（デプロイ Webアプリ） / 02-chrome-ext / 03-ios-app / 04-digital-product / 05-client-work（委託・company repo） / 06-claude-tooling（AI 基盤・スキル） / 07-pc-automation / 08-oss-eval。新設は「8 つのどれにも本質的に入らない」時だけ。

核：提供形態で判定（名前で分類すると誤分類。例：autolike-license-server は API サーバーでも 02-chrome-ext）。実体 dir は動かさず、~/Desktop/All-Projects/<カテゴリ>/ に symlink。.vercel・launchd・git worktree が実パス依存なので移動は危険。

台帳運用：~/PROJECTS.md に 1 行 1 プロジェクト（パス・状態・収益化・URL・注意）。Claude はこのファイルだけで「live 状態のものは？」に即答。

自動化：CLAUDE.md に「新規着手前に 8 カテゴリへ分類」と書くと、Claude が毎回指示なしで実施。symlink 正確性・台帳追記・機密 ignore 検証も自動スキル。

落とし穴：04-digital-product で credentials.json 漏洩、05-client-work での第三者 owner への push、カテゴリ乱増。

Claude CodeがVPN接続中に「Connection closed mid-response」で切れる原因はMTUだった

• URL: https://zenn.dev/brainy_software/articles/claudecode-vpn-mtu-connection-closed
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: NordVPN 接続中に Claude Code で長い応答が「Connection closed mid-response」で途中切れする現象を診断。短いやり取りは通るのに大きなデータで止まるパターンから、Path MTU Discovery（PMTUD）ブラックホールが原因と特定。VPN プロトコルを NordLynx（WireGuard UDP ベース）から OpenVPN(TCP) に切り替えて解消。

詳細

Claude Code は Anthropic API と SSE（Server-Sent Events）ストリーミングで応答を受信。短い応答は問題なく、長い応答（コード生成・長文説明）だけ途中で切れるのは典型的なサイズ依存症状。MTU（Maximum Transmission Unit、1つのパケット最大サイズ）が疑わしい。NordLynx は WireGuard ベースで VPN トンネルの MTU が通常 1420〜1380。経路の途中に 1500 より小さい区間があると、PMTU 探索が機能しない場合にブラックホール（パケット無言ドロップ）が発生。診断は macOS の ping -D フラグで実施。payload サイズで指定し IP パケット総サイズ（payload + IPヘッダ 20 + ICMPヘッダ 8 = 28）で比較。実測では総サイズ 1400 は通るが 1448 で落ちる → 経路 MTU は約 1400。TCP の MSS（Maximum Segment Size）は両端が 1500 前提で決定されるが、経路に 1380 区間があると ICMP「Fragmentation Needed」通知が返って来ない場合、送信側は大きなパケットを何度も再送→タイムアウト。対処は VPN プロトコルを OpenVPN(TCP) に切り替え。TCP over TCP による二重再送制御で、分割・再送・順序制御が自動化される。付帯注意として、専用 IP 運用での出口 IP 変更リスク（プロトコル切替時に紐づけサーバが変わる）。

コードから仕様書を逆生成するWebアプリ「cc-rsg-web」を公開しました

• URL: https://zenn.dev/daishiro/articles/cc-rsg-web-release
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: cc-rsg-web は逆仕様書生成 Web アプリ。コード・クラスメモリ・レガシーコードから AI がたたき台を自動生成するが、本体との対話で暗黙知を引き出して仕上げる協調型設計。Phase 0（ゴール定義）と Phase 5（対話）で人間が意図・設計判断を注入。Redmine 35 万行の実証で 90 分で 13 章 5000 行の仕様書を生成、Mermaid 図と全文ソース参照（REF）つき。AI 丸投げは根拠なしの幻覚が混ざるが、REF 強制で追跡可能性を確保。

詳細

cc-rsg-web 逆仕様書生成パイプライン

背景：レガシーコードに仕様書がない現場は多い。作者は他界、ドキュメント散逸、コードだけ残存。「読めないコード→引き継げる資産」化が目標。

設計：AI に丸投げでなく、人間が全部書くでもなく、役割分担を明確化。6 フェーズで進行。

Phase 0（人間）：ゴール定義 5 問（誰が・何のために読むか） Phase 1（AI）：浅い偵察・テンプレ提示 Phase 2（AI）：分割・インベントリ抽出 Phase 3（AI）：並列調査＋ソース参照 Phase 4（AI）：整合性検証 Phase 5（人間 ↔ AI）：対話で暗黙知回収。AI が章ごとに「設計判断の理由は？」と質問、人間が答える→本文反映。 Phase 6（AI）：Markdown 納品

効果の実証：Redmine（Ruby 35 万行 1095 ファイル）を解析。

結果：約 90 分で 13 章＋マニュアル 5000 行。Mermaid 図（ER・シーケンス）つき。全文にソース行参照（REF）。

定量比較（人手 vs AI 丸投げ vs cc-rsg-web）：

• 所要時間：数週間 vs 数時間 vs 数時間〜数日
• 正確さ：高 vs 低 vs 高（REF 検証）
• 暗黙知取り込み：高（属人） vs 不可 vs 高（対話）
• 追跡可能性：低 vs なし vs 高（REF 全文）

アプローチ：AI が拾える部分は拾い、人間が頭に持つ設計判断は対話で引き出す。「完璧な自動生成」ではなく「ここからたたき台を一緒に育てるツール」。学術プレプリント（Zenodo）で手法公開、個人 MIT オープンソース。

生成AI時代における、WordPressのメディア運用と改修

• URL: https://zenn.dev/deep_zen/articles/wordpress-media-ops-ai-era-dansul-renovation
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: ダンススクール比較メディア「ダンスル」のWordPress改修から、生成AI時代のメディア運用設計を導出。WordPressを「記事CMS」ではなく「メディアOS」として扱い、教室詳細・エリア・駅・評価・JSON同期データ・管理画面項目が混在する複雑さに対応。改修したページ群（トップ・エリア総合・都道府県・駅・教室詳細有料版・無料版）ごとに検索軸・フィルター・導線・責務を分けて実装。JSON同期とWordPress管理画面の役割分担、共通テンプレート実装時の文字列置換全文一致化・虚偽デフォルト値排除・データ欠け吸収フォールバックなどを実装ルール化。AI速度と事故リスクのバランス設計。

詳細

WordPressメディア「ダンスル」改修の実装体験から、生成AI時代のメディア運用設計を抽出。WordPressを「記事投稿ツール」ではなく「編集画面・URL・SEO・テンプレート・データ同期をまとめる OS」として扱う必要性を強調。改修対象はトップページ（検索軸選択）・エリア総合ページ（都道府県ハブ、色分けカード、地域ブロック）・都道府県・市町村ページ（フィルター・フォールバック。filters JSON優先、なければタグ・説明・料金・駅徒歩情報判定、存在しない選択肢非表示）・駅・沿線ページ（別軸検索）・教室詳細ページ（有料版は魅力訴求CTAポップアップ、無料版は公開情報導線明確化で責務分離）。JSON同期とWordPress管理画面は「同期対象を広げすぎると上書き、狭すぎると反映なし」の境界設計が重要。実装時のルール：文字列置換は全文一致に限定、空データに虚偽デフォルト値なし、JSONない情報をテンプレートで無理に作らない、有料版・無料版責務分離、フィルターはデータ欠け想定フォールバック、スマホ操作性優先、予約・通知・個人情報は管理画面側、変更後に対象URL実確認。AIに任せやすい作業（既存テンプレート読み取り・レスポンシブUI・PHPレンダリング関数・JSON変換・管理画面項目追加・検証コマンド・変更レポート）と人間が決めるべき判断（正とするデータ・責務分離・ビジネス要件・SEOハブ・テンプレート補完範囲・JSONに入れない情報）を分離。

個人のプロンプト術をやめて、チームで回るAI駆動開発ループを作った話

• URL: https://zenn.dev/explaza/articles/d0aeb08fcd1888
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: チーム全体で AI 駆動開発を回すため interview-dev-loop スキルを導入。調査・質問・計画・実装・レビューを 1 つのループに統合。人間は「質問に答える」「計画を承認」「動作確認」に集中。エージェント側で調査・設計・実装・レビュー指摘対応をループ。定量計測で PR レビュー指摘が 72% 削減（変更行数あたり）。核は「インタビュー」で、エージェント側から「何を作るべきか」を詰める。不確実さを 6 種（方向・検証・ロールアウト・データ処理・権限・ユーザー動作）に限定。明らかに答えが出ている選択肢は提示禁止。実装は別エージェントに委譲して不要なコンテキストを捨てる。

詳細

個人プロンプト術からチームループへの転換記録。最初は「良いプロンプトのベストプラクティスを標準化」を目指したが、タスクごとに必要情報が異なるため、代わりに「人間が最初のプロンプトを短く、エージェント側が質問で詰める」設計に変更。質問ルールを厳密化：Material Ambiguity（実装方向・検証・ロールアウト・データ処理・権限・ユーザー動作で変わる不確実さ）だけを対象。選択肢は最大 3 つ、すべて現実的に成立。推奨案を書いても、他の選択肢も実行可能。実装フェーズで別エージェントに委譲した理由は、調査中に蓄積した捨てた案・不採用方針を持ったまま実装に入るとエージェントが不要な前提を引きずるため。人間が見る項目：指示・計画承認・E2E 確認。実装後の PR 指摘対応も codex-review-loop で自動化。体感値だが「チームメンバーが改善をスキルに PR 出す」ことで個人工夫がチーム資産化。

Canva MCPで日本語タイトルが「天久百厳浸」になった — AI生成の限界と代替手順の記録

• URL: https://zenn.dev/joemike/articles/canva-mcp-japanese-text-broken-2026
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Code 経由で Canva MCP の AI 画像生成を日本語タイトル込みで実行させたところ、日本語テキスト部分がランダムな漢字に変わるバグが発生。Canva AI は英語コーパス学習で日本語セマンティクスを扱えないことが原因。代替として Pillow と同梱 TTF フォント（Noto Sans JP）で自動生成に切り替えた。

詳細

Canva の generate-design（MCP 経由の AI 生成機能）では、日本語テキストを含む画像生成を指示してもタイトル文字が「天久百厳浸」「米岡済本」といった意味不明な漢字出力になる。テンプレートコピー方式（テキストのみ手動編集）なら日本語は保持される。根本原因は Canva AI エンジンが英語コーパスで訓練され、日本語の意味的整合性を保ったまま画像レンダリングできないこと。採用した対処は、scripts/generate-hero-image.py で MDX frontmatter（title、description）を読みながら Pillow 経由で画像を自動生成。フォント（NotoSansJP-Bold、Regular）を public/fonts/ に同梱してシステム依存を排除。設計判断としては「自動パイプラインで生成後に人間が確認できないなら、AI 生成テキストを日本語コンテンツに使わない」というルール化。

Loop Engineering、kajiでもできますよ

• URL: https://zenn.dev/kamo78/articles/kaji-loop-engineering-before-name
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: kaji は AI 開発ループを YAML workflow で定義・運用する harness。単発のコード生成ツールではなく、設計→レビュー→修正→実装→コードレビュー→修正→検証→PR 作成まで一連の flow を再実行可能にする。loop engineering の review/fix/verify 要素（cycles・verdict・resume・max_iterations）を全部内蔵し、実装済み harness として運用実績がある。

詳細

kaji Loop Engineering 実装

定義：YAML workflow で設計・コードレビュー・PR review の step・cycle・verdict・resume・stop condition を管理し、ai driven development loop を運用。

実装例：dev.yaml は 7 つの cycle（ready-review・design-review・code-review・implementation・final-check・pr-create・pr-review）で構成。各 cycle は review/fix/verify loop を回し、max_iterations 上限で stop。

核の工夫：maker/checker の分離。実装は Claude（high effort）、設計・コードレビューは Codex（gpt-5.5）に割り当て。review（新指摘探索）と verify（直前指摘の修正確認）を分ける（ないと loop 無限化）。

deterministic step：LLM を通さない step（review-poll）を exec として入れ、PR polling など決定論的処理は script で実行。全部を LLM に渡さない設計で loop 安定化。

制御性：–from で途中再開、–before で特定 step 直前停止。途中打ち切りや人間 review 挿入の柔軟性。interactive_terminal runner で tmux pane 上に harness progress・agent heartbeat 表示。

実運用：legacy/bugfix_agent v5（2025-12）から cycles・verdict・resume の課題を潰しながら整理。kaji 自身の開発を kaji で回すほか、kamo2（株価分析ダッシュボード、本番 220 GB PostgreSQL）で安定運用。

Claude Code を最新版から下げた話 — Opus 4.8 不安定で 2.1.153 + Opus 4.7 に戻した

• URL: https://zenn.dev/kenimo49/articles/claude-code-downgrade-2-1-153
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Code 最新版（Opus 4.8）の運用で 5 つの不安定症状（他 AI 出力の誤認、auto mode 中の頻繁停止、ハルシネーション増加、指示外の env 自走探索・自己 injection 判定）を観測。最新最強が常に正しいわけでなく、実運用安定性を優先して 2.1.153 + Opus 4.7 に下げた。落とし穴は同一マシンの複数 install 経路（system /usr/bin・npm-global・native /.local/bin）が PATH で競合し、「バージョン下げた」と思っても反映されないこと。/.local/bin を PATH 先頭に置き、claude install 2.1.153 で固定。既存 shell の PATH キャッシュは hash -r で再読み込み。

詳細

Claude Code バージョン下げと PATH 管理の実装記録

不安定症状：codex 出力を指示と誤認（tool boundary 崩れ）、auto mode 中の頻繁停止・文字化け、ハルシネーション増加、指示外の env 自走探索＋自己 prompt injection 判定。5 つ同時発生で完走確率が大幅低下。最後の env 探索は最小構成でも再現し、CLI バージョンも関係すると判定。

バージョン選定：GitHub issues・CHANGELOG・npm 履歴を codex（read-only・sandbox・web 検索）に調査させ、安定版 2.1.153 を選定。2.1.152-153 は静か、2.1.181-186 は修正多発・不安定。Opus 4.7/4.6 選択削除時期は一次ソース未確認。

PATH 多重化の罠：/usr/bin/claude（system 2.1.172）・/.npm-global/bin（2.1.186）・~/.local/bin（未整備）が競合。which claude で初めて事実が見える。npm install -g が反映されない理由は PATH 先頭が system 版だから。

実装：claude install 2.1.153 で ~/.local/bin に置き、.profile で /.local/bin を PATH 先頭に登録。既存 shell の PATH は hash -r で再読み込み（重要）。/usr/bin・/.npm-global は削除せず、シャドウで勝たす（fallback 残し）。

非対話環境（cron・at・systemd-run）の注意：.profile を読まないので PATH は /usr/bin:/bin 最小セット。フルパス指定か、スクリプト先頭で PATH 拡張必須。実装者はこの伏線を自分で踏み、harness-ops の claude -p 30+ 箇所に path 設定・モデル・effort pin を追加（core/lib.sh で claude_run ラッパー）。

Claude Code と VPS で16エージェントのAI会社を作った話

• URL: https://zenn.dev/nakayama_acari/articles/free-article-01
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: 3つの営業商材（薬の自販機・印刷・高級りんご）を16体のAIエージェントで分担運用している実例。バックエンド基盤はHetzner VPS 1台（$15月額）にPM2で5プロセスを常駐させ、Claude CodeをAIの脳として機能させている。各エージェントはmarkdownファイルで定義され、前回セッションの引き継ぎ（HANDOFF.md）と失敗事例（lessons_learned.md）を自動読み込み。フックシステムでセッション終了時の自動git push・クラッシュリカバリの文脈復元を実装。30+個のMCPサーバーが実作業（ブラウザ自動操作・Webスクレイピング・データ集計・提案書自動生成・法令参照）を担当しており、「薬局100件リスト作成」といった指示をFilecrawl + OpenStreetMap組み合わせで実行できる構成。

詳細

エージェント組織としての Claude Code 運用実装。成功因子は CLAUDE.md を「会社憲法」として設計し全エージェントの行動指針・保存先・禁止事項を一箇所に集約したこと、フックシステムで教訓を自動記録する仕組み（「NG」キーワード検知で教訓ファイル追記）の効果。失敗したポイントはエージェント数を20超まで増やしたときに「誰に頼めばいいか分からない」という問題発生、HANDOFF.md が数週間で数千行になるオーバーフロー、CRM を後から自作するはめになったので初期設計に組むべきだったこと。実装コスト実績は VPS $15月額と Claude API 従量課金。フックの crash_state.json でクラッシュ検知し、次起動で直前30件ツールログとチェックポイントを自動注入することで「続きお願い」一言で文脈復元される仕組み。著者は本設計・実装・運用を詳述する有料本（Zenn）を執筆中。

個人開発のコードベースに健康診断を：CodeCompassをMVPリリースした話

• URL: https://zenn.dev/noragrammer/articles/codecompass-mvp-202606
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: AIにコードを書かせていると「動く」と「健全」が別問題になる。CodeCompassは git の変更履歴と AST 解析から「変更頻度×複雑度」を自動計算し、リポジトリ内の危険ファイル（ホットスポット）を検出するコードベース健康診断ツール。検出結果を GitHub Issues・PR コメントとして報告し、「ここを直すとコードベース全体が締まる」という指摘を出すが、実際の修正判断はユーザーに委ねる。企業向けツール CodeScene の核心ロジックを個人開発者・小チーム向けに軽量実装した形。

詳細

CodeCompass MVP実装の詳細。設計思想は「必要な情報だけを蒸留して渡せば、AIは勝手に設計判断をし始める」。スコア計算式は (変更頻度×複雑度)/LOC。分母に LOC を使うことで、ただ大きいだけのファイルが過大評価されるのを防ぐ。検出したホットスポット情報はコード本文ではなく構造化 JSON（スコア・複雑度・変更回数・caller/callee 数）として渡し、判断のブレを防ぐ。現在のMVPは GitHub Actions CI経由のみ対応（ローカル単体実行は git log –since=90.days が不正確になるため非サポート）。対応言語は .js / .py のみで複雑度解析実施、TypeScript・Ruby は未対応。導入は sparse-checkout でCodeCompass単体をダウンロード、npm install、分析対象リポジトリに 2 つのワークフロー（codecompass.yml で PR コメント投稿、hotspot-alert.yml で Issue 自動起票）を登録する形。ホットスポット情報の構造化データを将来的にリファクタリング提案エージェントに渡す連携も設計段階。

Claude Codeのauto modeは git reset –hard を勝手に実行しない

• URL: https://zenn.dev/okssusucha/articles/20260623-claude-code-auto-mode-safety
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Code auto mode は、ユーザーの要求からの逸脱を文脈で判定する安全設計。別プロセスの Sonnet 4.6 が審査役として常駐し、ツール呼び出しを一件ずつ評価。git reset –hard や terraform destroy は静的ブロックでなく「ユーザーが明示的に要求したか否か」で許可判定。実トラフィック 1 万件の誤ブロック率 0.4%、手作業テスト 52 件の見逃し率 17%。

詳細

Claude Code の権限は ask（毎回確認）・bypassPermissions（全自動承認・見逃し率 100%）・auto mode（文脈判定）の三段。auto mode は作業エージェント（Claude Opus）とは別に Sonnet 4.6 が審査役として常駐。審査は二段構え：第一段は推論なしの高速フィルタで yes/no を 1 トークンで返し迷ったらブロック側に倒す、第二段は chain-of-thought で連鎖思考。プロンプトの大半がキャッシュ共有でコスト・レイテンシ抑制。実行も階層化で、ファイル読み込みや検索は素通り、プロジェクト内編集はバージョン管理で後から確認可能として許可、シェル・Web 取得・外部ツール・作業ディレクトリ外は審査役に回す。auto mode では python や node のワイルドカード許可を無効化（任意コード実行の抜け穴対策）。審査役は ツール出力を見せない（Web コンテンツへのプロンプトインジェクション対策）。ブロック対象は固定リストではなく「ユーザー要求からの逸脱」で決定。git reset –hard は「ローカル変更を捨てるよう頼んでいないとき」のみブロック。terraform destroy も「対象スタックを明示的に頼んでいない限り」。同じコマンドでも escalation で結果が変わる。誤ブロック 0.4%・見逃し 17% の数字を公開し auto mode は「シートベルト（絶対安全ではない）」と明言。累計 20 回拒否で人間レビューにエスカレーション。モデルがモデルを見張る構成がエージェント運用の標準パターンになりつつあることの好例。

【初心者向け】Momonga Search MCP を Claude / Codex で使えるようにしよう！

• URL: https://zenn.dev/ray000/articles/momonga-search-mcp-setup
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Momonga Search MCP（企業資料・経済ニュース検索用 MCP サーバー）を Claude Desktop / Claude Code / Codex 上で動かすセットアップガイド。共通準備として uv インストール、リポジトリ取得、APIキー設定、動作確認を実施。各クライアントごとに設定ファイル編集または mcp add コマンドで登録。トラブルシューティングは切り分け手順と典型的なつまずき（パス指定ミス、クライアント再起動不足、APIキー未設定など）を収録。ChatGPT 非対応理由は設計思想（ローカル stdio サーバーとクライアント 1 対 1 の相性）の解説。

詳細

Momonga Search MCP は LLM / エージェント向けの MCP サーバーで、企業公表資料・経済ニュースを安全に検索・取得・根拠提示する機能を持つ。設計上の工夫として取得内容をローカルキャッシュ（SQLite インデックス付き）に永続化し、必要な断片だけを切り出して返すことでコンテキスト削減を実現。この仕組みは stdio / ローカル実行（サーバーとエージェント同一マシン）と相性が良く、Claude Desktop / Claude Code / Codex を対象としている。

セットアップは共通準備とクライアント別登録に分かれる。共通準備では OS ごとに uv をインストール（macOS/Linux は curl 経由、Windows は PowerShell 経由）。リポジトリは git clone で取得し uv sync で依存パッケージをインストール。Momonga Search API キーは .env ファイルに設定（環境変数で複数カスタマイズ可だが初期段階では MOMONGA_SEARCH_API_KEY のみ必須）。任意で uv run momonga-search-mcp でサーバー単体の起動確認が可能。

Claude Desktop では設定（Developer → Edit Config）から claude_desktop_config.json を開き、mcpServers に登録。既存設定がある場合は既存キーとカンマで区切って追加。アプリ完全再起動（ウィンドウクローズのみではバックグラウンド継続の場合あり）後、Settings → Developer で接続状態を確認。Claude Code と Codex は claude mcp add / codex mcp add コマンド一発で登録（–scope user で全プロジェクトから利用可）。各クライアントで /mcp コマンドで接続確認、チャットで実際に MCP 検索を試行して動作検証。

トラブルシューティングは切り分け順序（サーバー単体起動確認 → クライアント再起動と設定確認 → MCP 接続後の診断）を提示。典型的つまずきは uv がパスに見つからない（ターミナル開き直し）、MCP 非接続（設定ファイルのリポジトリ絶対パスが /absolute/path/to… のままか確認、クライアント完全再起動）、server_setup_error（APIキー未設定）、JSON 書式エラー。Windows 版 Claude Desktop / Codex は Windows 側コマンドのみ実行可能なため、WSL 側でリポジトリ・uv を置くと起動失敗。対処は Windows 側で完結させるか WSL を呼ぶ形で command を wsl に変更。

ChatGPT は MCP 対応だが本サーバーは未対応。理由は設計思想のトレードオフ。ChatGPT の MCP は HTTPS 公開の Remote MCP サーバー（Streamable HTTP / SSE）を前提とし、複数ユーザー間で単一キャッシュを共有。本サーバーのローカルキャッシュ設計は複数ユーザー環境ではコンテキスト削減メリットが失われ、ユーザー分離・キャッシュ管理が複雑化するため非対応。

複数AIエージェント時代のWorkspace Orchestrationを組んでみた

• URL: https://zenn.dev/soichiyo/articles/5f663abafb4e39
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: 複数エージェント（Hermes・Codex・Claude Code・OpenCode・oracle）を役割分担で運用する Workspace Orchestration 設計。入口・管制・実働を分離。Codex を親管制に据え、読み取り専用で棚卸し・振り分けを実施。Worker へ指示時は「何を触れるか・何を触ってはいけないか・いつまでか・返すかたちは」を毎回明示。スレッド台帳（thread ledger）・タスク メモ・自動化レジストリで状態を追跡。終了形式を固定（current state・next action・wait condition）で迷子回避。

詳細

複数エージェントの同期化で重要なのは「誰が何をしているか」の可視性。親スレッドは軽く保ち（read-only triage）、判断は5択（進める・委譲・外部App・Git操作・人間に止める）に限定。戻せない操作（push・merge・secrets）は必ず人間が承認。Hermesの役割は「消費番人」で、出した通知が食べ残されていないかを監視し、滞留を拾い直す。振り分けの優先度は（セキュリティ・認証 → 設計判断 → 数ファイル・数十行 → 単純・量・繰り返し）で明示。OpenCode と Claude Code の使い分け基準も実装コスト軸で記述。スレッド台帳は Git 管理の Markdown で正本化せず、本当の情報源（PR・commit・docs）に指し先を貼る設計。

OpenAI Codex-maxxing実践: Zenn記事を評価ループで育ててみた

• URL: https://zenn.dev/sompojapan_dx/articles/7a83c02b6b62f9
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: OpenAI白書「Codex-maxxing for long-running work」の理論をZenn記事制作に応用した実験記。親スレッドを編集係、読者ペルソナごとのサブエージェント4体（実務エンジニア・チームリード・Zenn読者・流し読み読者）をレビュー専任に分けて、評価結果を統合・採用判断・ログ記録するループを2周回した。1周目で権限管理と監査ログの曖昧さが致命指摘として浮上、冒頭・実行手順・権限管理・ログの残し方を改修して2周目で停止条件達成。Long Running Taskでは「最初から全部決める」のではなく、成果物を見ながら少しずつ向きを変えること、レビューは合否ではなく判断材料を作ることの重要性を実装で示した。

詳細

白書で示される要素（Durable thread・Goal・Memory・Steering・Review・Thread automation）をZenn記事制作に実装。親スレッドが記事編集・評価結果統合・採用判断・ログ更新を担い、サブエージェントは読み取り専門でファイル編集しない設計。最初の記事構成は白書の目次に引っ張られていたが、「読者は何をすればいいか」が弱いという流し読み読者からの指摘で主役を「機能紹介」から「この記事制作をループ化した実例」に変更。1周目の評価は実務エンジニア4.0・チームリード3.7・Zenn読者4.0・流し読み読者3.5で、チームリードから権限・監査ログが曖昧という致命指摘。実行プロンプトに「公開・送信は人間の承認必須」「評価ログを残す」「停止条件を見る」を明記し、権限（レビュー専任はread-only）・停止条件（致命指摘なし・権限外事項なし・最大周回数）・監査ログ項目（評価者・点数・採用判断・未検証事項）を先に定義。2周目で全ペルソナが4.0以上で停止条件達成。サブエージェントは各々モデル・ツール使用のためトークン増加するが、親スレッドの権限設定を引き継ぐ。custom agentとして.codex/agents/zenn-reader.tomlに定義すれば毎回プロンプト転記を避けられる。

rm -rf をブロックしても、AIの本番事故は防げない ── hookに『環境』を判定させる

• URL: https://zenn.dev/sprix_it/articles/4c44e56ba6f28a
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: rm -rf や破壊的コマンドのフックは本番とステージング を区別しないため、本番環境での accidental リスクは残る。実装例として環境変数・ホスト名から本番判定するロジックを hook に組み込み、deny/ask/allow を振り分ける設計を提示。read は自由に、非本番は高速に、本番の変更は ask で承認、戻せない本番操作は deny に収束させることで、構造的にうっかりを減らす運用を実現できる。ガードレール設計であり完全な壁ではないが、実務的には有効。

詳細

本番環境での AI エージェント運用リスク

基本的な rm -rf・sudo ブロックだけでは不十分。本番環境を特定できなければ、環境に適応した destroy・delete など戻せない操作が素通りする。

環境判別の戦略：環境変数（AWS_PROFILE）・接続先ホスト・踏み台経路・命名規則から本番性を判定し、hook の PreToolUse で read/write/destroy を3層に分類。

実装の核：hook 内で bash 条件分岐で本番判定し、JSON 出力で deny/ask/allow を返す。複数の hook を走らせても出力契約が統一されるため予測可能。

運用上の配分：deny は「戻せない本番操作」だけに絞り、大部分の本番変更は ask で人間が見て承認する。非本番は allow で AI の高速化を活かす。

フック単体の限界：文字列パターンマッチなので、エイリアス・変数展開・環境変数一時変更で回避可能。セキュリティ境界ではなく構造的うっかり軽減装置。本番権限分離・監査ログと多層で守るべき。

実装は permit シェル・settings.json の PreToolUse で登録し、–dangerously-skip-permissions モードでも有効。

空中戦の会議を止めよう！自動書記係さん — AmiVoice × LLM × React Flow で作る ShokiGakari

• URL: https://zenn.dev/taka4/articles/31a959273c87e1
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Web 会議の議論が空中戦になるのを防ぐため、AmiVoice（音声認識）+ LLM + React Flow を組み合わせた自動書記システム「ShokiGakari」を実装。話し始めると発話が即「仮ノード」として表示され、1.5秒無音をトリガーに LLM がツリー全体を整理して「確定ノード」に昇格。マインドマップが会話そのものになる。

詳細

AmiVoice を選んだのは、Web Speech API と異なり、確定認識（A イベント）と部分結果（U イベント）を WebSocket で明確に分離。発話開始も S イベント通知で、音声検出ロジックを音声認識側に委譲できる。React Flow v12 は dynamic グラフと差分更新（setNodes/setEdges で delta 直接適用）が得意。アーキテクチャは Browser → ScriptProcessorNode で PCM(16bit 16kHz) 取得、Node.js WS サーバーで Orchestrator が 2フェーズ制御を担当。Phase 1（確定テキスト即仮ノード追加）では SilenceDetector(1.5s)でタイマー管理。Phase 2（無音検出で LLM 起動）では現在のツリー JSON と直近の発話を渡し、{ add, update, remove } delta のみ返却させる（説明不要指示で説明文を抑制）。ブラウザは pending ノード全消去してから delta を順に適用。LLM プロバイダを環境変数で claude-cli / claude-api / ollama に切り替え可能。

Claude Code でAIチームを設計する ─ 増やしても破綻させない5層モデルと3原則

• URL: https://zenn.dev/takna/articles/claude-code-ai-team-design
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Code のサブエージェント・スキル・コマンドは5層（役職・スタッフ・マニュアル・起動ボタン・協働）で整理でき、役職は軽く地図は仕組みで守り起動は絞る3原則で破綻しない設計が可能。実装では PostToolUse hook で地図と実装の齟齬を自動検出し、保有数の上限を実質消すことができます。

詳細

Claude Code の機能を役職（部門・組織図）・スタッフ（サブエージェント）・マニュアル（スキル）・起動ボタン（コマンド）・協働（エージェントチーム・loop・hook）の5層に位置づけることで、何をどの層に配置すべきかが明確になります。設計上の3原則は、役職を実装で軽く保つこと・地図と実装の齟齬を仕組みで自動化して守ること・起動は規律して並行化のコストを抑えることです。重要なのは、役職の軽さとコンテキスト隔離の価値、そして PostToolUse hook で地図ファイル（roles/_index.md 等）を編集するたびに死リンク・孤立を自動検出する具体的な bash 実装まで示されている点で、スタッフ追加の標準化手順（作らない判断→最小権限・適正モデル・明確な description の3点確認→組織図に登録→lint で確認）に従うことで、保有数の上限がほぼ消えます。サブエージェントは並列化ではなくコンテキスト隔離が第一の価値であり、tools 最小権限・model 適正・description の Do NOT 明記で責務の曖昧さを防げます。

友達から久々にLINEが来たので、マルチ勧誘リスクを機械学習で判定してみた

• URL: https://zenn.dev/terasawa/articles/146141d79806e2
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: 友人からのLINEメッセージをマルチ勧誘リスク分類するMLモデルを構築。累積メッセージの段階的パターンを学習し、どの段階でリスク検知されるかを分析。ChatGPTでシミュレーションデータ100件を生成、ロジスティック回帰で学習、FastAPI+React で推論エンドポイント実装。F1スコア0.92達成。LLMを補助手段として使いながら、データ設計・モデル選定・運用監視を人間主導で進めた実例。

詳細

ラベル設計の工夫が目立つ。単純な二値ではなく段階的多ラベル（再接触・目的曖昧・対面誘導・第三者紹介・副業訴求・総合リスク高）で、メッセージ累積による進行度を追跡。ChatGPT生成データだが、「メリットのある形でユーザーに利用させてもらう」データ戦略を記述。前処理（絵文字除外・形態素解析・n-gram・TF-IDF）を決定論的に組み込み。One-vs-RestClassifierで過学習を回避。重要なのはAccuracy/Precisionのバランス判定で、友達を失うリスクも考慮した運用視点。本番化時のログ実装・監視項目（分布シフト、予測値分布）も明記。

Claude Codeのmemoryファイルに更新漏れが3か所——「伝えた ≠ 更新した」の構造

• URL: https://zenn.dev/tottoko_hamu/articles/2026-06-15-100000
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Codeで「使っていない」と口頭で伝えただけでは、memory配下やCLAUDE.mdの記述は自動更新されない。複数のファイルが同じ古い内容で整合していると、AIがそれを事実として受け入れてしまうという構造的な問題について。著者は「Cowork」という廃止済みツールへの言及が3箇所に残ったまま定着し、整合した記述がAIの疑いを減らすことで、問題が放置されていった実例を記録している。このシグナルへの対応は簡単で「それはもう使っていない、どのファイルに記載がある？」と一言聞くだけで早期発見できるが、初回で止まるかどうかが決め手という学習記。

詳細

Claude Codeの記憶ファイル管理における実装事例。著者は薬の自販機・印刷・高級りんご贈答という3商材の営業を「Coworkセッションから」という廃止済みワークフローで回し続けていた。実際には3つのファイル（memory/project_cowork_operation.md・global-rules.md・content/writing/books/series-2/2026-04-26_concept.md）がCowork前提のまま残存していたため、AIは忠実にその指示を守り続けた。著者が古い言葉の使用を何度も目撃していたのに流してしまった理由は「文脈はわかってくれているだろう」という油断。実際に問題が顕在化したのは、タグ記述にたまたま目が留まった偶然だった。整合している文書が多いほどAIが誤りを疑いにくくなる逆説と、このシグナルを早期に止めることの重要性、そして「何かをやめた」というタイミングで関連ファイルの一体更新が必要という実装指針を記述している。文書正確性の責任は人間側にあるという根本認識。

WEB制作を学んで「畳んだ」会社員が、Claude Codeに丸投げして「同人サイトの裏ページ」をWordPressで実装した話

• URL: https://zenn.dev/tsumugiiori/articles/e13d08114f5d20
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: 超文系事務職が数年前に WEB 制作スクール（WordPress 実装まで）を完走したあと、実装は向いていないと判断して道を畳んだ。その後、個人創作サイト（小説・イラスト・日記）を建てたくなり、実装を Claude Code にほぼ丸投げ。WordPress（Arkhe 親テーマ+子テーマ）で 3 種類のカスタム投稿タイプ・タクソノミー・テンプレート 15 本・functions.php 2000 行・独自プラグイン 4 本を 20+ セッションで実装。著者の役割は要件の具体化（「古の同人サイトの裏ページ」のような文化的背景を伝える）と動作確認・具体的な指摘のみ。丸投げに必要なのはコーディング力ではなく、要件を言い続ける根気だと記述している。

詳細

WordPress カスタム投稿タイプ・タクソノミー・プラグイン実装の記録。設計軸は「投稿の種類（writings/visuals/journal）」と「見せ方（series/kind）」の分離。裏ページ（非公開セクション）実装は「会員制にせず、入口を知る人だけが入れるソフトゲート」を要件として、kind タクソノミーに restricted フラグを立てて論理分離し、3 層で漏洩を防ぐ構成：防御① pre_get_posts で フロントエンド全 WP_Query に kind NOT IN (‘restricted’) を自動付与（公開側一覧・アーカイブ・検索・RSS から構造的に除外）、防御② 月別アーカイブなど直接 SQL は除外サブクエリで手動除外、防御③ REST API 単体取得（/wp/v2/{type}/{id}）は rest_pre_dispatch で該当ルート検出・kind=restricted なら 404 返却。独自プラグイン 4 本は OGP 管理・画像 WebP 自動変換・動画サムネイル生成・ローカル→本番差分同期デプロイ（ハッシュ比較判定・REST API + アプリケーションパスワード認証で反映）。サイドバー系の重い集計は Transient キャッシュで 12 時間保持・投稿保存時に自動フラッシュ。著者は TOP ページ組み立てと Instagram 連携プラグイン導入（サイトの顔）のみ担当。スクール時代の PHP 知識は「AIの説明を追う」には足りたが「コードを書く」には足りず、丸投げの鍵は要件を言い続ける根気だったと総括。

Sakana Fuguを22ドルだけお試し導入してみた記録

• URL: https://zenn.dev/yamadatt/articles/20260623-sakana-fugu-trial
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Sakana Fuguを22ドル（約3600円）で試し導入した個人実験記。エージェント型で「聞く相手」より「手を動かしてくれる相手」。複数環境の確保・コーディング支援検証・試しやすい金額のため試行。実際に記事修正3本で5時間リミットの約80%消費。日本語修正が自然、小さな作業の肩代わり得意、消費速度が予想より速い、最終確認は人間必須、使いどころ事前決定が重要というのが試用から得た知見。

詳細

Sakana AIが提供するエージェント型AIツール。22ドルでお試し導入した個人実験。試用動機：① 生成AI環境代替候補増加でリスク分散、② コーディング支援（新規開発より既存修正・差分確認・エラー切り分け・設定ファイル整理の日常細粒作業）の検証、③ 金額試しやすさ。記事修正タスクで試用（技術的意味変えず読みやすさ向上。annotation processor等専門用語は維持、compile時・runtimeのBean等日本語文脈不自然な表現修正）。5時間リミット中約80%消費。良かった点：日本語修正が自然（誤字だけでなく読み手引っかかり拾う、過度書き換え避ける）、小さな作業任せやすい（Markdown表現修正・軽いリファクタ・エラー調査・差分確認・ログ整理）。懸念点：22ドルでも大タスク試行錯誤で消費速度速い（対象ファイル・目的を絞るべき）、最終確認人間必須（記事ニュアンス・コードプロジェクト前提あり）、使いどころ事前決定が効率的（記事日本語修正・技術記事構成整理・Git差分説明・小さな設定変更調査・エラー一次切り分けで使用、長時間大実装・仕様曖昧な新規開発は後）。継続判断用初回確認として22ドル範囲は十分。

Claude Code から Sakana Fugu を呼ぶ

• URL: https://zenn.dev/yoshitetsu/articles/e2904fd064c56b
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Sakana AI の 2026/6/22 リリース「Sakana Fugu」（マルチエージェント・オーケストレーション）を Claude Code から呼び出す実装。Fugu は OpenAI 互換 API を提供しているため、claude-code-router を間に挟むだけで完結。設定は config.json に Provider 1 エントリと Router 5 キー（default/background/think/longContext/longContextThreshold）を記述し、/model sakana-fugu,fugu-ultra で明示切り替えも可能。ただし Standard $20/月プランはヘビーなコンテキスト（数十K tokens）で初回リクエスト即 5 時間枠が枯渇する落とし穴あり。本気利用なら Pro $100・Max $200・Pay-as-you-go を選ぶ必要。

詳細

claude-code-router によるプロバイダ中継実装。Claude Code が標準で叩くのは Anthropic API のみなので、OpenAI 互換 API（OpenAI・Sakana・OpenRouter 等）を使うにはルーター層が必須。設定構造は Provider 側で api_base_url・api_key（環境変数参照）・models 指定、Router 側でタスク種別ごとの自動振り分け（default は fugu-ultra でメイン作業を高品質側へ、background は fugu でコスト削減、think は推論ヘビーなので fugu-ultra、longContext は 60K tokens 超で fugu-ultra）。動作確認は ccr code で起動し、/model コマンドで明示切り替え可能。課金はサブスク 3 段階（Standard $20・Pro $100・Max $200）と Pay-as-you-go。落とし穴は Standard プランでヘビーなコンテキスト投げると API Error 429（usage_limit_reached）で 5 時間枠が枯渇すること。期間限定キャンペーン：2026/7 月末までのサブスク契約で初月料金で 2 ヶ月目無料。

Claude Codeの使用量をmacOSメニューバーで常時確認できるアプリを作った

• URL: https://zenn.dev/yotake/articles/4173a27c455976
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: Claude Codeの5時間枠セッション消費率をmacOSメニューバーに常時表示するアプリClaudeMeterを開発した。Swift+SwiftUIで実装し、Usage APIを5分間隔でポーリング、トークンの有効期限切れ前のリフレッシュ、複数アカウント対応を実装。Codex CLIのローカルログパースでレート制限情報もローカルから取得可能にした。無料・オープンソース公開。

詳細

ClaudeMeterはmacOSメニューバー上にセッション消費率をパーセント表示し、クリックで詳細（週間リミット、Codexレート制限、API支出など）を表示するSwift製アプリ。SwiftUIのMenuBarExtraでポップオーバー実装、Usage API（https://api.anthropic.com/api/oauth/usage）を定期ポーリングし、トークン有効期限切れ5分前に先回りリフレッシュ、429エラー時は自動バックオフ。Codex CLI用にはローカルの～/.codex/sessions/*.jsonlをパースしてtoken_countイベントのrate_limitsフィールドを読み取り、ネットワーク通信ゼロで取得。複数アカウント（サブスク複数持ちやサブスク+Admin APIキーの組み合わせ）に対応し、各アカウントで独立してポーリング・トークン更新を実行。消費ペース予測により色表示でビジュアルフィードバック。GitHub・ダウンロード・GitHub Sponsorsで公開。