Claude Code v2.1.170 の主要アップデート - Mythos 級モデル Claude Fable 5 を提供！

• URL: https://dev.classmethod.jp/articles/20260609-cc-updates-v2-1-170/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Claude Code v2.1.170でClaude Fable 5（Mythos級）が利用可能に。既定モデルの置き換えではなく選択式。VS Code統合ターミナルからのセッショントランスクリプト未保存バグも修正。

詳細

変更点2件

1. 新機能: Claude Fable 5対応

   • /modelコマンドから選択可能になった
   • デフォルトモデルはそのまま（自動切替なし）
   • APIモデルID: claude-fable-5
   • 料金: 入力$10/MTok、出力$50/MTok（Opus 4.8比2倍）

2. バグ修正: VS Code統合ターミナルでのトランスクリプト未保存

   • VS Code統合ターミナルやClaude Codeの環境変数を引き継いだシェルから起動した際に、セッションが--resume一覧に表示されない不具合を修正

提供条件（重要）

• API・従量課金Enterprise: 利用可能
• サブスクリプションプラン: 2026年6月22日まで含む、6月23日以降はクレジット必要

Mythos級モデルの体系整理

• Mythosクラス: Opusを超える新ティア（2026年4月にMythos Previewとして先行公開）
• Claude Fable 5: 一般利用向けセーフガード付き（Claude Code利用者が使うのはこちら）
• Claude Mythos 5: セーフガードなし、サイバーセキュリティパートナー（Project Glasswing）等限定

注目事例（パートナー報告）

• Stripe: 5,000万行規模のRubyコードベース移行、従来2ヶ月相当の作業を1日に短縮

Amazon Connect AIエージェントでClaude Sonnet 4.6が利用できるようになっていました

• URL: https://dev.classmethod.jp/articles/amazon-connect-ai-agent-claude-sonnet-4-6/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: 東京リージョンのAmazon Connect AIエージェントでClaude Sonnet 4.6（Cross-Region JP/Global）が選択可能に。管理画面のモデル表示もモデルIDから表示名（例: Claude 4.5 Sonnet）に改善。ただしORCHESTRATIONタイプのみ対応で他のAIプロンプトタイプは未サポート。

詳細

確認された変更点

1. Claude Sonnet 4.6が利用可能に

   • jp.anthropic.claude-sonnet-4-6（Cross-Region JP）
   • global.anthropic.claude-sonnet-4-6（Cross-Region Global）

2. 管理画面のモデル表示改善

   • 旧: jp.anthropic.claude-sonnet-4-5-20250929-v1:0（モデルIDそのまま）
   • 新: Claude 4.5 Sonnet (Cross-Region JP)（表示名）

Claude Sonnet 4.6の仕様

制約: supportedAIPromptTypesがORCHESTRATIONのみ

• Claude 4.5 SonnetやNova系ではANSWER_GENERATION、SESSION_SUMMARIZATION、EMAIL_RESPONSEなど多数のタイプに対応しているのと対照的

Amazon Connect にタッチトーンバッファリングが追加されたので IVR の先行入力を試してみた

• URL: https://dev.classmethod.jp/articles/amazon-connect-touchtone-buffering/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Amazon ConnectにタッチトーンバッファリングがAI向けセルフサービス機能として追加。IVR音声案内の再生中でも「1-2-3」のような入力をバッファに保持し、後続ブロックで順次処理できる。実機検証で長いプロンプト再生中に入力した「123」が後続の入力ブロックで「1」「2」「3」と正常処理されることを確認。

詳細

機能概要

• Set Touchtone Buffer Behaviorブロックで有効化
• バッファ最大30文字（0〜9、#、*）
• 音声案内再生中・フローブロック遷移中でもDTMF入力をバッファに収集
• Play promptブロックの「タッチトーンバッファリング有効時にプロンプトをスキップまたは中断」チェックで即座に中断・収集可能

ユースケース

• 1-2-3の連続押し（メニュー経路の先行入力）
• アカウントID・注文番号の先行入力

検証フロー 音声設定 → タッチトーンバッファ有効化 → 長いプロンプト再生中に「123」押下 → 後続の入力ブロックで「1」「2」「3」として順次処理 → 成功

設定の2モード

• 有効（Enable Buffering）: DTMF入力をバッファに収集開始
• バッファを停止してクリア（Stop and Clear）: バッファリング停止・保持入力削除

Webサイト/モバイルアプリからの通話開始時のコンテキスト渡し 顧客ID・セッション参照・キャンペーンコードを通話に自動的に渡し、AIエージェントが発信者を事前認識可能

[プレビュー] AWS FinOps Agent がプレビューリリースされたのでセットアップして使ってみた

• URL: https://dev.classmethod.jp/articles/aws-finops-agent-preview/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: AWSが新たにFinOps Agentをプレビューリリース。DevOps Agent・Security Agentに続く「フロンティアエージェント」シリーズ。自然言語でコスト質問、異常の自動調査、HTML/PDF/PPT形式のレポート生成、Jiraチケット化、Slack通知などが可能。プレビュー期間中はエージェント自体の利用料無料。

詳細

主な機能

• 自然言語でのコスト質問・分析（日本語クエリも理解）
• コスト異常の自動調査（cost-explorerスキル活用）
• タスク機能: 単発・スケジュール・イベント駆動の3種類
• Automations: 定期実行・コスト異常検出イベント駆動のワークフロー
• アーティファクト生成: HTML/PDF/PPTレポート
• Slack統合: 投稿前にプレビュー確認あり、フッターにAgent/Conversation IDリンク
• Cost Optimization HubおよびCompute Optimizer統合
• セッション間記憶機能（組織固有コンテキストファイルのアップロード）

セットアップ構成

• Agent IAMロール（FinOpsAgentRole-xxxxx）
• Operator IAMロール（FinOpsAgentOperatorRole-xxxxx）
• サードパーティ連携: Jira・Slack（OAuthフロー）

現状・制限

• 東京リージョン未対応（バージニア北部のみ）
• Slack連携: マルチセッションモード非対応
• プレビュー期間中: エージェント利用料無料、呼び出すAWS API料金のみ発生
• 回答は現状English優先（やり取りを重ねると日本語切り替え）

内部ツール呼び出し例

• cost-optimization-recommendations, cost-explorer, execute_code, get_current_date_time

AWS PCS に AWS 公式の AMI が登場し、自前ビルド不要で本番環境でも利用できるようになりました

• URL: https://dev.classmethod.jp/articles/aws-pcs-official-ami-no-custom-build/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: AWS Parallel Computing Service向けに本番利用可能な公式AMI「PCS-ready Deep Learning AMI（DLAMI）」が登場。これまでGPUワークロード本番環境は自前カスタムAMIビルドが必須だったが、NVIDIA Driver・CUDA・Slurm・PCS AgentがプリインストールされたAMIを公式提供。追加費用なし。

詳細

登場前の課題

• 従来の公式AMI（Amazon Linux 2023 + Slurmのみ）は公式ドキュメントに本番非推奨と明記
• GPUワークロード本番運用にはNVIDIA Driver・CUDA・EFA Driverを含むカスタムAMIを自前ビルド・検証する必要があった

PCS-ready DLAMIのコンポーネント

※PyTorch・TensorFlow等のMLフレームワークは含まれず（別途追加）

AMI ID取得

aws ssm get-parameter \
  --region ap-northeast-1 \
  --name /aws/service/pcs/ami/dlami-base-ubuntu2404/x86_64/latest/ami-id \
  --query "Parameter.Value" --output text

対応アーキテクチャ: x86_64・arm64 追加費用: EC2インスタンス料金のみ（DLAMI自体は無料）

Amazon Bedrock AgentCore Managed Harness で LiteLLM Proxy をモデルソースとして設定してみた

• URL: https://dev.classmethod.jp/articles/bedrock-agentcore-harness-litellm-proxy-model-source/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Bedrock AgentCore Managed HarnessのモデルソースにLiteLLMが新たに追加。LiteLLM Proxy経由で仮想APIキー・チーム単位アクセス制御・使用量トラッキングなどガバナンス機能をHarnessに組み込み可能に。TerraformによるLiteLLM Proxyデプロイから接続まで一気通貫で検証。

詳細

追加されたLiteLLMサポートの意義

• 従来: BedrockモデルソースはAmazon Bedrock/OpenAI/Google Geminiの3択
• 今回追加: LiteLLM Proxyを経由したモデルアクセス
• LiteLLMのプロキシ層で仮想APIキー発行・チーム別制限・ガードレール適用等のガバナンスをHarnessに持ち込める

セットアップ手順

1. LiteLLM ProxyをECS Fargate+ALBにTerraformでデプロイ（リポジトリ: yuu551/lite-llm-sample）
2. LiteLLM Admin APIでチームと仮想APIキーを発行（モデルアクセス制限付き）
3. AgentCore Identityに仮想APIキーをCredential Providerとして登録（Secrets Manager経由で暗号化保存）
4. Harness編集でModel sourceをLiteLLMに選択、モデルIDをlitellm_proxy/claude-haiku形式で指定

ハマりポイント

• モデルID指定はclaude-haikuではなくlitellm_proxy/claude-haiku形式が必要（プレフィックスなしはプロバイダー判定できずエラー）

検証環境

• LiteLLM Proxy: main-v1.81.14-stable（ECS Fargate + ALB）
• モデル: claude-sonnet（Bedrock経由）、claude-haiku（同）
• Claude Sonnet 4.5 / Haiku 4.5をBedrock経由でルーティング

BigQuery Lakehouse カタログ Iceberg テーブルへの SQL 書き込みとクエリパフォーマンスを検証してみた

• URL: https://dev.classmethod.jp/articles/bigquery-lakehouse-iceberg-write-and-performance/
• 日付: 2026-06-09
• Tier: Tier 2
• 要旨: BigQuery LakhouseカタログのIcebergテーブルへのSQL書き込み方法とクエリパフォーマンスを検証。SQL直接書き込みは不可で、BigQuery Sparkストアドプロシージャ経由のPyIceberg利用が必要。Snowflake側からはBigLake メタストアカタログ統合（GA）でメタデータファイルパス更新不要。

詳細

課題設定

• BigQuery Lakehouse カタログのIcebergテーブルはBigQuery SQLからの直接書き込み不可
• 公式ドキュメント記載の制限: クエリ速度はCloud Storage直接読取と同等

解決策: Sparkストアドプロシージャ経由

1. BigQuery SparkコネクションをBQで作成
2. SparkサービスアカウントにstorageObjectAdmin・biglake.admin・bigquery.dataViewerなどの権限付与
3. CREATE OR REPLACE PROCEDUREでBigQuery Sparkプロシージャを定義（PyIcebergライブラリ使用）
4. Sparkプロシージャを実行してIcebergテーブルに書き込み

BigQuery→Snowflake連携のポイント

• Snowflake BigLakeメタストアカタログ統合がGAになり、メタデータファイルパス更新不要で最新データ参照可能
• BigQuery LakhouseカタログのIcebergテーブルは4層構造（プロジェクト.カタログ.グループ.テーブル）
  • 通常テーブル（3層: プロジェクト.データセット.テーブル）とFROM句の指定形式が異なる

技術スタック

• BigQuery Spark Connection（asia-northeast1）
• PyIceberg[gcsfs,pyarrow]
• Google Auth（SigV4ではなく標準Python認証）

Claude Fable 5 が Amazon Bedrock で利用可能になったので試してみた

• URL: https://dev.classmethod.jp/articles/claude-fable-5-bedrock/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Claude Fable 5のAmazon Bedrock対応手順を実機検証。Agreement作成→Data Retention API有効化（SigV4手動署名必須）→Converse APIでの推論という3ステップで利用開始可能。Reasoning常時ON、temperature 1.0固定など従来モデルと異なる制約に注意。

詳細

仕様概要

※Mythos Previewの40%コストで利用可能

セットアップ手順

1. Agreement作成: aws bedrock create-foundation-model-agreement
2. Data Retention API有効化: マネジメントコンソール・boto3非対応のため、SigV4手動署名でBEDROCK API直接呼び出し
3. Converse API推論: global.anthropic.claude-fable-5（Cross-region inference profile）

重要な制約

• Reasoning常時ON（reasoningContentがレスポンスに常時含まれる）- OFFにはできない
• temperature 1.0固定（変更不可）
• top_pは0.99以上かつ1.0未満のみ（1.0指定不可）。top_kは非サポート
• セーフガード発動時: Bedrock Converse API経由ではstopReason: "content_filtered"が返りfallback応答なし（Anthropicの発表と挙動が異なる）
• provider data share（推論データ30日間Anthropicに共有）が利用条件。学習には不使用

リージョン制約（2026-06-10時点）

• In-Region: us-east-1、eu-north-1のみ
• 東京（ap-northeast-1）: Global cross-region inference profile経由で利用可

プロンプトキャッシュ

• 対応しているが自動適用でなく明示的cache checkpoint指定が必要
• 最小1,024tokens、最大4checkpoints、TTL 5分/1時間

【非エンジニアのためのClaude/ClaudeCodeシリーズ】 Claudeで受失注データの整理を効率化しようとしたら、サクッと分析までできた話

• URL: https://dev.classmethod.jp/articles/claude-win-loss-analysis/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: 営業担当者がHubSpot MCPをClaude Coworkに接続し、受失注データの整理・分析をAIに委ねた実践レポート。手動作業30分→AIで2分に短縮。プロンプト1行でデータ抽出・ピボット・チーム比較分析まで完結。非エンジニア向けAI活用の具体的な成功事例。

詳細

解決した課題

• HubSpotからCSVエクスポート→Excelで列整理→ピボット作成、という一連の下準備に毎回30分以上かかっていた
• ピボットテーブルが苦手でカレンダーに予定枠を確保するほどの苦手作業

実現したこと（HubSpot MCP接続）

1. シンプルなプロンプト1行で2分以内に結果取得:

   • 担当案件一覧（案件名/カテゴリ/取引ステージ/金額）
   • 年間/月間ステータス別データ
   • ピボット分析サマリー

2. 受注率・失注理由・商談期間の即時集計

3. チーム比較分析（受注率トップ担当者との差異を自動抽出）

技術的ポイント

• Claude Coworkのdocument操作とHubSpot MCP接続の組み合わせ
• 日本語プロンプトで指示、Claudeが適切なHubSpotデータを取得
• HubSpot MCP接続手順は同シリーズ別記事参照

非エンジニア向けの意義

• 「データを出す」という前処理をスキップして即座に「考える」フェーズへ
• Excelスキル不要でデータ分析の入口を下げる
• 30分→2〜5分への大幅短縮で分析頻度が上がる

CloudWatch Logs Insightsに追加された新コマンド・関数23個を検証してみた（2026年6月版）

• URL: https://dev.classmethod.jp/articles/cloudwatch-logs-insights-new-commands-functions-2026-june/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: 2026年6月8日にCloudWatch Logs Insightsに追加された23個の新機能を実機検証。5月の13個（ログ整形・閲覧系）に続き、今回はハッシュ・IP判定・型変換・時系列分析・CSV/XMLパース等の「分析基盤」系機能が中心。Athena/pandas/Splunkで後処理していた作業がCWL Insights内で完結可能に。

詳細

新機能一覧（2026年6月追加）

5月vs6月の方向性比較

• 5月（13個）: 「ログを読む・探す」→目視確認・手動デコードの代替
• 6月（23個）: 「ログから答えを出す」→Athena/pandas/Splunkでの後処理の代替

注目機能と検証結果

• md5(user_id): ユーザーIDのハッシュ化表示が可能
• split(tags, ','): カンマ区切り文字列を配列に展開
• if(toNumber(response_time) > 1000, 'slow', 'fast'): 三項演算子相当
• isPrivateIP, isPublicIP: IPアドレス分類でセキュリティ監査に活用
• histogram, rate, count_over_time: 時系列分析をCWL Insights内で完結

検証で確認した挙動差異

• strcontainsの第3引数true（case-insensitive）: シンタックスエラーにはならないが効果を確認できず（実装未完またはドキュメントと挙動が相違）

AWS EC2 仮想インスタンスでネステッド仮想化（Nested Virtualization）を有効化して、KVM で VM を作ってみた

• URL: https://dev.classmethod.jp/articles/ec2-enable-nested-virtualization-and-create-kvm/
• 日付: 2026-06-09
• Tier: Tier 2
• 要旨: 2026年2月に第8世代IntelベースのEC2仮想インスタンスでネステッド仮想化がサポートされたことを受け、m8i.largeでKVMを使いAlpine Linux VMを起動する手順を実機検証。ベアメタルインスタンス比で最大約100倍のコスト差を実現。

詳細

背景

• 従来: .metalベアメタルインスタンスのみでネスト仮想化可能
• 2026年2月: 第8世代Intelベース仮想インスタンス（c8i/m8i/r8iなど）でも対応

コスト比較（東京リージョン、2026年5月時点）

最大約100倍のコスト差でネスト仮想化が可能に

セットアップ手順

1. EC2インスタンス起動時に「高度な詳細」→「ネストされた仮想化」を有効化
2. 確認: lsmod | grep kvmでkvm_intelを確認
3. KVM関連パッケージインストール: qemu-system-x86, libvirt-daemon-system, virtinst等
4. ゲストVM作成: Alpine Linux 3.21 ISO + qcow2ディスク + virt-install

ポイント

• ネストされた仮想化機能自体は追加料金なし
• 検証OS: Ubuntu Server 26.04 LTS
• ゲストOS: Alpine Linux 3.21（軽量で検証に最適）
• m8i.large: 1〜2時間で$0.30程度

たった15分で完成！Google Apps Script × SlackでGoogle Calendarの翌日予定を自動通知してみた！

• URL: https://dev.classmethod.jp/articles/google-apps-script-slack-schedule-notify/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Google Apps ScriptとSlack Incoming Webhookを組み合わせ、毎日18時台に翌日のカレンダー予定をSlackに自動送信するシステムを構築。サーバー不要、GASトリガーで実装。参加承諾済み予定のみ、終日イベント除外、土日は通知しない等のフィルタリング付き。

詳細

仕様

• 毎日18時台にGASトリガーで自動実行
• Google Calendar翌日予定を取得
• フィルタリング条件:
  • 自分が参加承諾 or 主催者の予定のみ
  • 終日イベント（勤務場所・休暇等）は除外
  • 翌日が土日の場合はスキップ（金曜・土曜は通知なし）

構成

セットアップ

1. Slack APIページでアプリ作成→Incoming Webhooks有効化
2. チャンネルにWebhookを追加→URLコピー
3. GASでsendTomorrowSchedule()関数を作成しSLACK_WEBHOOK_URLに設定
4. GASの時間ベーストリガーで18時台に設定

出力例

📅 明日のスケジュール（6月10日（月））
⏰ 09:00 朝会
⏰ 11:00 プロジェクトキックオフ
合計 2件 の予定があります。良い1日を！

制限: Webhookで送信したメッセージは後から削除不可（テスト時は個人チャンネル推奨）

Kiro WebのCollaborativeモードでGitHubリポジトリ解析から改善PR作成、/kiro fixでのレビュー対応まで試してみた

• URL: https://dev.classmethod.jp/articles/kiro-web-collaborative-github-pr-kiro-fix/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Kiro Web（2026年5月パブリックプレビュー）のCollaborativeモードを使い、GitHubリポジトリ解析→改善提案→PR作成→/kiro fixによるレビュー対応の一連フローを実証。内部でplanner→coder→Semantic Reviewer→coderの再修正サイクルが自律的に回る。ただし初回PRに事実誤認が含まれており、人間による技術検証が不可欠と結論。

詳細

Kiro Webの仕組み

• ブラウザ上でGitHubリポジトリと連携しながらAIコーディングできる開発環境
• Collaborativeモード（Autonomous OFF）: 対話的に改善方針を選択、実装はKiroが担当

Sub-agentの実行フロー（自動観測）

1. planner: リポジトリ構造把握・タスク計画
2. coder（1回目）: スキルファイルへのセクション追加
3. Semantic Reviewer: 差分解析、5件のレビュー指摘
4. coder（2回目）: レビュー5件への対応 → PR作成前に内部でレビューサイクルが自律的に完結

検証で発見した事実誤認 初回PRの主張「filterはstatsの後に置けない／HAVING相当機能なし」が誤り。 実機検証でstats count(*) as c by @logStream | filter c > 3が正常動作することを確認（HAVING相当として機能）

/kiro fixの動作

• PRコメントを自動取得して修正ポイントを構造化
• 守備範囲を明示的に制限（問題なし判断部分には手を付けない）
• 3分27秒・1.56クレジットで3点修正完了

コスト実績

• 全体合計: 5.57クレジット / 約16分
  • 解析・提案: 0.23クレジット
  • 実装+PR作成: 3.78クレジット
  • /kiro fix: 1.56クレジット

結論: PR作成の自動化と内容の正確性は別問題。ナレッジベース系コンテンツには人間の実機検証が必須

S3にCSVを置くだけでDynamoDBにマスターデータを投入する仕組みをAWS CDKで構築してみた

• URL: https://dev.classmethod.jp/articles/s3-csv-dynamodb-master-data-cdk-lambda/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: S3の特定フォルダにCSVを置くだけでLambdaが起動しDynamoDBに自動取り込みする仕組みをAWS CDK（TypeScript）で構築。管理画面不要、CDKでS3・DynamoDB・Lambda・S3イベント通知をまとめて構築。成功はprocessed/、失敗はerror/にファイル移動することで状況が把握できる。

詳細

構成

処理フロー

1. uploads/フォルダへCSVアップロード
2. S3イベント通知でLambdaトリガー
3. CSVをパースしてDynamoDBにバッチ書き込み（PKで上書き=新規追加・更新同一フロー）
4. 成功: processed/{timestamp}-{filename}に移動
5. 失敗: error/{timestamp}-{filename}に移動

技術選定

• CSVパース: PapaParse（型安全でブラウザ/Node両対応）
• DynamoDB: BillingMode.PAY_PER_REQUEST
• Runtime: NodejsFunction（AWS CDK）

利点

• 非エンジニアでも操作可能（S3にファイルを置くだけ）
• 専用管理画面・API不要
• 取り込み履歴がS3上で可視化される
• CDKで3リソースをまとめて管理

S3 汎用バケットの DeleteObject をタグ条件で Deny できるのか試してみた

• URL: https://dev.classmethod.jp/articles/s3-delete-object-deny-by-tag-condition/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: S3汎用バケットでオブジェクト自身のタグ（s3:ExistingObjectTag）を条件にDeleteObjectをDenyしようとしたが機能しないことを検証。代替として、バケットタグ（aws:ResourceTag）を条件に配下のオブジェクト削除をDenyすることで期待通りの制御が実現できることを確認。

詳細

検証した仮説 S3汎用バケットのABAC有効化後、オブジェクトにManagedBy=iacタグを付与してDeleteObjectをDenyできるか

結論

• s3:DeleteObject + s3:ExistingObjectTag/ManagedBy: iac条件 → 機能しない（ABAC有効化済みでもオブジェクトタグによる条件評価がDeleteObjectではサポートされていない）
• 代替: s3:DeleteObject + aws:ResourceTag/ManagedBy: iac条件（バケットタグを条件に指定）→ 機能する

実用的な制御方法 バケットレベルのタグ（aws:ResourceTag）で配下の全オブジェクト削除をDenyする方式:

{
  "Effect": "Deny",
  "Action": "s3:DeleteObject",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/ManagedBy": "iac"
    }
  }
}

制限

• オブジェクト単位のタグで細粒度制御はできない（バケット単位になる）
• バージョニング無効状態での検証

SCPでECS Fargateタスク定義のCPU・メモリ上限を制限してみた

• URL: https://dev.classmethod.jp/articles/scp-limit-fargate-task-definition-cpu-memory/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: 2025年2月追加の新IAM条件キーecs:task-cpu/ecs:task-memoryを使い、SCPで高スペックなFargateタスク定義のRegisterTaskDefinitionをDenyする方法を検証。すべてのテストケースで期待通りの結果を確認。

詳細

背景

• 2024年11月にFargate上限が最大16vCPU/120GiBに拡張
• 意図しない高スペックなタスク定義登録によるコスト増リスク

SCPポリシー設計

{
  "Sid": "DenyLargeFargateCPU",
  "Effect": "Deny",
  "Action": "ecs:RegisterTaskDefinition",
  "Condition": {
    "NumericGreaterThan": {
      "ecs:task-cpu": "4096"
    }
  }
}

（メモリ側も同様にDenyLargeFargateMemory）

設計ポイント

• ecs:RegisterTaskDefinitionに限定: タスク定義はイミュータブルなので登録時点で制御
• NumericGreaterThan: しきい値一致は許可、超過のみDeny。条件キー不存在時はマッチしない
• 条件キー型: ecs:task-cpuはCPU units（1024=1vCPU）、ecs:task-memoryはMiB

検証結果

SCPの条件評価がECSのパラメータ検証より先に行われることも確認（有効なcpu/memory組み合わせでなくてもDenyが返る）

【Security Hub修復手順】[ELB.21] ALB/NLBターゲットグループは暗号化されたヘルスチェックプロトコルを使用する必要があります

• URL: https://dev.classmethod.jp/articles/securityhub-fsbp-remediation-elb-21/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: AWS Security Hub「AWS基礎セキュリティのベストプラクティス」のELB.21コントロール修復手順。ALB/NLBのターゲットグループでヘルスチェックプロトコルをHTTPSに変更するだけで対応完了。Lambdaタイプは対象外。

詳細

コントロール概要

• 対象: Application Load Balancer・Network Load Balancerのターゲットグループ
• チェック内容: ヘルスチェックプロトコルが暗号化されているか（HTTPS）
• 対象外: Lambdaタイプのターゲットグループ

リスク

• HTTPなど非暗号化プロトコルのヘルスチェックは中間者攻撃のリスク
• インフラ構成情報の読み取り・ヘルスチェック結果の改ざん→トラフィックルーティング操作

修復手順

1. EC2コンソール→「ロードバランシング」→「ターゲットグループ」
2. 対象のターゲットグループを選択
3. 「ヘルスチェック」タブ→「編集」
4. プロトコルを「HTTPS」に変更→「変更を保存」

【Claude Fable 5】Mythos級と言われるモデルの性能や料金、使い方について解説！【2026年6月最新版】

• URL: https://dev.classmethod.jp/articles/what-is-claude-fable-5/
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: Anthropicが2026年6月9日に一般公開したMythos級モデル「Claude Fable 5」の性能・料金・使い方を解説。SWE-bench Verifiedで95.0%、Opus 4.8比約2倍の料金（入力$10/MTok、出力$50/MTok）。Claude Codeからは/modelコマンドで選択可能。

詳細

モデル位置づけ

• Anthropicのラインナップ最上位「Mythos級」の初モデル。Claude Mythos 5と同一基盤、セーフガード有無のみ異なる
• 数日がかりの複雑・非同期タスク、長時間エージェント業務向けに設計

ベンチマーク実績

• SWE-bench Verified: 95.0%（Opus 4.8は88.6%）
• SWE-bench Pro: 約80%（Opus 4.8は69.2%）
• Spatial Reasoning: 38.6%（Opus 4.8は14.5%、約2.7倍）
• CursorBenchで最優秀スコア

料金体系

プロンプトキャッシュ使用時は入力90%割引（$1/MTok）

制限・注意事項

• サイバーセキュリティ・生物学クエリは自動的にOpus 4.8にフォールバック
• セッションの5%未満でフォールバック発動
• データ保持: 安全目的で30日間

使い方

• Claude Code: /modelコマンドでFable 5を選択（v2.1.170以降で利用可能）
• Claude Desktop/Web: モデル選択メニューから選択

Deep Analysis: ニュース記事から「文脈」を可視化する——LLM × Neo4j によるナレッジグラフ構築

date: 2026-06-10 analyst: deep-analysis skill（壁打ち） sources: 1件（Zenn / xiushu53 氏 個人技術記事） total_claims: 5件 total_counterargs: 採用2件 / 却下2件

概要

本記事は、112件の政治ニュース記事を LLM（gpt-4o-mini）と Neo4j を組み合わせてナレッジグラフ化するパイプラインの設計・実装報告である。Entity/Canonical 2層構造による名寄せ、Pydantic Structured Output、2ステップ解析（名寄せ → 構造化抽出）、MCP 経由での Claude Code 連携が主な技術的知見。

本プロジェクト（waribashi_konbu）が抱える「ニュース記事の文脈蓄積・エンティティ管理・重複排除」という課題と問題意識が完全に一致しており、グラフDB移行を除けば即座に応用可能な知見が複数含まれている。

抽出クレーム（5件）

詳細

W001: 112件ニュースでの実用化

政治ニュース112件を処理し、Entity・Event・Statement・Organization・Policy・LogicRelation を含むグラフを構築。Docker 上の Neo4j 5.26 Community を使用。実証規模は小さいが、設計思想・スキーマ・クエリパターンは汎用的。

W002: Pydantic スキーマ = LLM 指示書

extra='forbid' 付きの Pydantic モデルを Structured Output に渡すことで、「フィールド名・型・ネスト構造」がそのまま LLM への暗黙的なプロンプトとして機能する。型定義が要件定義を兼ねる設計。

W003: 2ステップ解析

Step1 で人物の canonical_name を確定させ、Step2 でその確定情報をプロンプトに注入して構造化抽出を行う。LLM が1回の推論で「名寄せ」と「関係抽出」を同時に行おうとすると精度が落ちる問題を分割で回避。

W004: 既知コンテキスト注入（RAG 的）

記事公開日前後60日の既存イベントをDBから取得し「現在DBにあるイベントリスト」としてプロンプトに渡す。LLM に「既存IDを再利用せよ」と指示することでイベントノード増殖を防ぐ。本プロジェクトの manifest.tsv による重複排除と同じ問題意識。

W005: プロンプト先頭一文バイアス

logic_analysis セクションの冒頭が「エンティティ間の対立・支持・妥協を抽出せよ」という文で始まっていたため、LLM が「人間関係セクション」と認識し因果関係（CAUSES/PRECEDES）を抽出しなかった。先頭に「イベント間因果も対象」と明記し、日本語因果表現（「〜を受けて」「これを踏まえ」）を例示して解消。

反論と判定

反論 C001: Neo4j 依存でありプロジェクト移行コストが高い

• 判定: 採用
• 理由: Neo4j + Docker 導入、Cypher クエリ習得、グラフスキーマ設計は非自明なコストを伴う。本プロジェクトはマークダウン wiki で安定運用中であり、全面移行の優先度は低い。
• 採用時の処置: 「Neo4j 導入」は推奨度★1に引き下げ。Pydantic/2ステップ/RAG注入など「グラフDB不要の知見」は個別に★3推奨とする。

反論 C002: 112件という実証規模が小さく大量記事でのスケーラビリティが未検証

• 判定: 採用
• 理由: 本プロジェクトはすでに数百件規模で運用中。LLM API コスト・名寄せ精度の劣化・グラフクエリ性能は報告されていない。
• 採用時の処置: 統合結論でスケール未検証を明示し、段階的実験を推奨する。

反論 C003: Entity/Canonical 2層構造は wiki/entities/ + wiki/persons/ の分離と等価で新規性なし

• 判定: 却下
• 理由: 既存設計はテキスト wiki であり、「役職付き人物の変遷追跡」「横断検索」「グラフクエリ」は実装されていない。同じ問題意識の異なる実装レベルであり等価ではない。2層構造の「Entity=役職付きインスタンス、Canonical=人物本体」という概念は wiki/persons/ 設計改善に直接応用できる。

反論 C004: LLM の先頭一文バイアスは既知事実であり知見としての新規性はない

• 判定: 却下
• 理由: 「既知」でも「日本語特有の因果表現を具体例示して解決した」実装記録は本プロジェクトの deep-analysis プロンプトに直接適用可能。知見の新規性より再現性と具体性を評価する。

統合結論

本記事は本プロジェクトと問題設定が高度に一致しており、特に Pydantic 型定義によるスキーマ駆動抽出・2ステップ解析（名寄せ先行）・既知コンテキスト注入による重複排除・プロンプト先頭一文バイアス対策 の4技術は即座に応用可能である（採用反論: C001, C002 あり）。

ただし、以下の不確実性に留意する：

• 実証112件はスモールスケール。本プロジェクトの規模での精度・コスト検証が必要
• zenn.dev は Tier 3 ソース（個人記事）であり、技術的主張は著者の実装経験に基づく。外部検証なし

Neo4j 本格導入は優先度低。まず scripts/fetch_articles.py または deep-analysis スキルのプロンプト設計に 2ステップ解析・RAG注入・先頭一文バイアス対策を取り込むことが現実的な第一歩。

当プロジェクトへの取り込み推奨度

参考ソース

• https://zenn.dev/xiushu53/articles/news-knowledge-graph-neo4j-llm — 個人エンジニアによる LLM × Neo4j ナレッジグラフ構築の実装報告（Tier 3, Zenn 個人記事）

AIエージェント時代の権限管理が、いまアツい

• URL: https://tech.layerx.co.jp/entry/ai-agent-authorization
• 日付: 2026-06-10
• Tier: Tier 2
• 要旨: LayerX「Ai Workforce」のPMによるAIエージェント権限管理の構造分析。過去（人間中心RBAC/ABAC/ACL）→現在（自律的行為者の登場による3つの課題）→未来（意図・条件ベースの権限記述、連鎖の検証可能性）という時間軸で整理。各社プロダクトの設計方針も比較。

詳細

AIエージェントがもたらす権限管理の3つの課題

1. 主体の区別ができない: リソース側がユーザー本人の操作かエージェントの自律動作かを区別できない。監査ログ上同一に見え、事故時の追跡困難。機密情報が外部エージェント経由で漏洩するリスク
2. ブラックボックス化: エージェント固有権限で動かすとユーザー権限と乖離。エージェント経由でユーザーには許されない操作が実行可能になる
3. 責任の所在の違い: 人への依頼と異なり、エージェントが何をどこまでできるかをユーザーが正確に把握していない

各社の設計アプローチ

• 実行ユーザー権限継承型: Salesforce Agentforce Employee Agent
• エージェント独立ID型: Google Cloud「Agent Identity」、Microsoft「Entra Agent ID」「Agent 365」

社内論点3軸

1. 代行か依頼か（権限の出どころ）: ユーザー権限で肩代わりvs.エージェント自身の裁量
2. 誰のものか（アイデンティティ所在）: 個人紐づきvs.組織紐づき
3. リソース範囲: スコープ限定による安全性vs.横断的な汎用性

未来像

• 権限は「リソースの列挙」から「意図・条件の記述」へ（ABACベースポリシー）
• エージェント権限連鎖の検証可能性（人→エージェント→別エージェント→外部APIの各ホップを追跡）
• エージェントのライフサイクル管理（入社・退社に相当する作成・廃棄フロー）

OAuthやMCPを中心とした標準化動向も注目点として言及

AIに全力投資するLayerXでインターンしたら、実装が早すぎて設計の重要性に気づいた話

• URL: https://tech.layerx.co.jp/entry/2026/06/10/135313
• 日付: 2026-06-10
• Tier: Tier 3
• 要旨: LayerX Ai Workforce事業部でSWEインターン（2025年12月〜2026年5月）した学生による実体験レポート。AIコーディングツールへの大規模投資、rules運用、AI自動PRレビュー、QAガイド自動生成など最前線の開発環境を解説。「AIで実装速度が上がるほど設計の疎かさが技術負債を加速する」という気づきが核心。

詳細

LayerX Ai Workforceの開発体制

• Cursor・Claude Codeへの潤沢な投資（週2日勤務のインターン生にも提供）
• AIとの壁打ちによる高速ドメイン知識キャッチアップ→プロトタイプ→即時フィードバックサイクル

AI活用の工夫4点

1. rules運用: コーディング規約・設計方針をrules/ディレクトリに集約、AIが常時参照
2. AI自動PRレビュー: Greptile・Devinを使ったPR自動レビューで人間レビュワーがドメインロジックに集中できる環境
3. QAガイド自動生成: インターン参画1ヶ月後に導入、開発とQAの心理的距離を縮める効果も
4. 高速プロトタイプ→FDE経由顧客フィードバック: リリース速度と改善サイクルの加速

インターンを通じた2つの学び

1. 「何を作るか」の重要性の増大

   • AIで実装コストが下がった分、「なぜ作るか」「本当に今作るべきか」の問いが重要に
   • 実例: バリデーション強化要件 → 議論の結果「システム側でデフォルト値を自動補完」に方針転換

2. 設計の重要性

   • 実装速度が加速した分、設計が疎かになると技術負債の蓄積速度も比例して早くなる
   • 「AI前提のアーキテクチャ」（切り離しや変更が容易な設計）がまだ未整備という課題認識
   • DDD等に代わるAI時代向けのアーキテクチャパターンへの模索

Cloudflare、従業員やアプリごとにAIの利用上限額を設定できるCloudflare AI Gatewayの新機能を発表

• URL: https://www.publickey1.jp/blog/26/cloudflareaicloudflare_ai_gateway.html
• 日付: 2026-06-09
• Tier: Tier 2
• 要旨: Cloudflare AI Gatewayに従業員・アプリごとのリアルタイム利用料金上限設定機能が追加（クローズドベータ）。Cloudflare Accessと統合しID基準のAI利用予算・ポリシー管理が可能に。上限超過時はブロックまたは安価なモデルへのダウングレードが選択できる。

詳細

概要 Cloudflare AI GatewayはOpenAI・Anthropic・GoogleなどのAIサービスとアプリケーション/ユーザーの間に組み込むゲートウェイサービス。今回、企業でAPIキーを共有利用している環境でも個別ユーザー・アプリに利用料金上限を設定できる機能が発表された。

新機能の内容

• AIモデルの価格に基づいてリアルタイムに利用料金を計算
• ユーザー・アプリケーション・AIモデル・プロバイダー・カスタム属性ごとに予算設定
• 上限到達時の動作: ブロック or 安価なモデルへのダウングレード
• Cloudflare Accessと統合したID基準のポリシー管理

既存機能（参考）

• 任意のAIモデルへのルーティング
• リクエストのキャッシュによる効率化
• トークン使用量・エラーなどのログ取得
• レート制限

現状: クローズドベータ、参加者募集中 Cloudflare自身が社内でこの機能を使いAI支出を管理していることを公表

AIエージェントのコンテキスト消費を80%削減するCLIツール「ctxpack」を作った

• URL: https://zenn.dev/pepabo/articles/ctxpack-ai-context-extractor
• 日付: 2026-06-10
• Tier: Tier 3
• 要旨: Claude CodeなどのAIエージェントがURL読取時に消費するコンテキストを最大91%削減するCLI「ctxpack」をGMOペパボのエンジニアが開発・公開。Python公式ドキュメント1ページが81,506→20,495トークンに圧縮（74.9%削減）。Homebrew対応。

詳細

解決する問題

• AIエージェントにURL読ませるとナビゲーション・広告・フッター・スクリプトタグ等のノイズがコンテキストを大量消費
• Python公式ドキュメント1ページで80,000トークン超になることも

主な機能

• HTML/Markdown/URLからノイズ除去してコンパクトなMarkdown/JSONを返すCLI
• --stats: トークン節約量を出力末尾に表示
• --query "キーワード": タスク関連セクションを先頭に並べ替え（重要部分が切り捨てられにくくなる）
• --json: エージェントのツール呼び出し結果向けの構造化JSON出力
• ctxpack stats: 累計節約量の確認

インストール

brew install atani/tap/ctxpack

実測値

• Python argparse ページ: 81,506トークン → 20,495トークン（74.9%削減）
• 9ページ累計: 573,028トークン → 51,565トークン（91.0%削減）

ノイズ除去の仕組み

• <script>、<style>、<noscript>、<nav>、<footer>、<aside>をタグごと削除
• class/id/roleでad、banner、breadcrumb、cookie、header、menu等をキーワードマッチで削除
• 標準ライブラリのみで実装（外部依存なし）

トークン推定方式

• CJK文字（ひらがな・カタカナ等）: 1文字≒0.8トークン
• その他: 4文字≒1トークン
• モデル非依存の近似値（削減前後の相対比較用）

Claude Code連携 CLAUDE.mdに以下を追記することでClaude CodeがctxpackをWebFetchより優先使用するようになる:

URL読み込み前に `ctxpack <url> --json` でパックしてトークンを節約する

ロードマップ: Playwright対応、MCP/サーバーモード、モデル別トークナイザー対応など