はてなブックマーク

やります。人力で書いてるので、短く、端的に行きます。 手順 マネコンでいきます。 Lambdaを新規作成する ランタイムはPython 3.13（3.14はだめ） ARM64アーキテクチャを選ぶ（好み） Lambdaレイヤーを追加する なんと、Strands AgentsとADOT（AWS Distro for OpenTelemetry）はどちらもLambdaレイヤーがあります。pip不要です。東京リージョンの場合のARNはこちら。 arn:aws:lambda:ap-northeast-1:615299751070:layer:AWSOpenTelemetryDistroPython:25 arn:aws:lambda:ap-northeast-1:856699698935:layer:strands-agents-py3_13-aarch64:2 注意点ですが、 Lambdaレイヤー

Claude CodeなどのAIエージェントを日常的に使っていると、あっという間に制限に引っ掛かることがありませんか？ Netflixのシニアエンジニアがオープンソースとしてリリースした「Headroom」というトークン削減ツールが、数日で 6k stars・400 forks を超えて(2026/06/03現在)話題になっています。 ちなみに公式ベンチマークによると、ビルドログなら93.9%、JSONなら90.6%のトークン削減を達成しています（ただし実運用の中央値は4.8%――この数字のギャップについては後述します）。 Headroomリポジトリ: https://github.com/chopratejas/headroom 3行まとめ HeadroomはAIエージェントへ送るコンテキストを圧縮してトークン消費を削減するOSS JSON・DB結果・ログでは大きな効果が期待できる ソー

中央値に至っては無限小です。 Zero Day Clockというサイトで、CVEが公開されてから実際に悪用が確認されるまでの期間を表したグラフを見ることができます。 この『悪用が確認』は『3500件以上の攻撃が確認された』という基準だそうです。 どうして3500かは謎。 From Vulnerability to Exploitation この集計が始まった2018年は、脆弱性が公開されてから悪用されるまでの平均値は2.3年、中央値は2.1年でした。 パッチ適用まで1年かかってもそこまで問題はなかったという、大変牧歌的なペースですね。 しかしこの間隔は、その後驚くべき勢いで短縮されていきます。 今から5年前の2021年には平均値は10か月、中央値は2.2か月にまで短くなりました。 平均値は半減程度ですが中央値は1/10となっており、短期間で攻撃される脆弱性が増えたことを意味しています。 そ

はじめに GitHub Actions から AWS を操作するパイプラインを組んだことがある人は多い。最近は Pulumi や Terraform で IaC（Infrastructure as Code、インフラをコードで定義する手法）を回す。CI のジョブからインフラを構築するのも珍しくない。 その際、昔のように AWS_ACCESS_KEY_ID を Secrets に貼る代わりに、OIDC（OpenID Connect）連携を使う。AWS 側で IAM（Identity and Access Management）Role の信頼ポリシーに GitHub を足す。すると、ワークフローが一時的なクレデンシャルを受け取って AWS を触れる。動くし、便利だ。 だが、ここで一度立ち止まりたい。GitHub にログインしている情報と、AWS にログインしている情報は、いったいどこで突き合

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2024年にサプライチェーン攻撃に使われたpolyfill.ioを放置していたWebサイトで現在、polyfill.ioのユーザー名とパスワードの入力を求める不審なダイアログが表示されるようになっています。 一部サイトでpolyfill.ioのログイン画面が表示されている 現在、一部のWebサイトを開いた際に次のようなダイアログが表示されるようになっています。なお、具体的な文言は使用しているブラウザーによって異なります。 https://polyfill.ioにはユーザー名とパスワードが必要です。 ログイン　https://polyfi

はじめに AWS の見積もりを作る方法はいくつかありますよね。 AWS 公式から出ている AWS Pricing MCP Server（awslabs 公式）はすごく便利ですが、AWS Pricing Calculator のURLを出してくれないから外部に正式に提示する見積もりには使えないという点がネックに感じている人が多いと思います。 AWS Pricing Calculator を使う場合は、普通に手動でサービスを選択していく方法やChromeを Claude（Cowork や Chrome DevTools MCPなど）に操作させて作らせるやり方があるかと思います。 いずれにしても、AWS Pricing Calculator で見積もりを用意するのは地味に手間がかかる作業です。（手作業でポチポチやるのキライ） そこで紹介したいのが、「AWS Pricing Calculator

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 📚 関連書籍 『ゼロから触ってわかった！ Snowflake × Databricks次世代データ基盤PoC実践 非公式ガイド』 👉https://amzn.to/4rCMi5W 『ゼロから触ってわかった！ Snowflake × Databricksでつくる次世代データ基盤 - 比較・共存・連携 非公式ガイド』 SnowflakeとDatabricks――二つのクラウドデータ基盤は、これまで「どちらを選ぶか」で語られることが多くありました。本書は、両プラットフォームをゼロから触り、構築・運用してきた実体験をもとに、比較・共存・連携

この記事は、Snowflake / Databricks / Google Cloud が推進する仮想グラフによる知識グラフをテーマにした、3部構成のシリーズ記事の 第2部 です。 第 1 部 Snowflake / Databricks / Google が挑む仮想グラフ戦略 第 2 部 AIエージェントの知識表現と推論になぜグラフが使われるのか？（本記事） 第 3 部 物理グラフDBを独自開発するための変更管理と安定運用戦略 本シリーズでは、論理マッピング技術である「仮想グラフ（Virtual Graph）」について解説します。第1部でその定義と選定フローを示したのに続き、本編では「なぜRDBやセマンティックレイヤーだけではLLMの推論を支えられないのか」という技術的・歴史的な背景と、グラフ構造化がもたらす探索パフォーマンスの優位性や実用的な価値に迫ります。 概要 第1部である 第 1

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 本シリーズの 第1部 および 第2部 では、主要データプラットフォームが「仮想グラフ（Virtual Graph）」に注力する動向と、AIエージェントの知識表現や推論におけるグラフモデルの理論的優位性について解説しました。 第1部では物理的なデータコピーを避ける「仮想グラフ」の可能性を論じましたが、実際のビジネス要件や処理性能、システム構成によっては、専用の物理グラフデータベース（Neo4jなど）を自分たちでゼロから構築し、物理的なインフラとして本番稼働させる選択肢（物理グラフ開発）をとる場面も数多く存在します。 最終章となる第3

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 本記事では、近年データプラットフォームの巨人たち（Google Cloud、Snowflake、Databricks）やグラフデータベースのリーダー（Neo4j）が相次いで提供を開始した「仮想グラフ（Virtual Graph）」について解説します。 なぜ今、複数のプラットフォームが時を同じくして仮想グラフソリューションを打ち出しているのか、その背景にある「商機」と市場動向を分析します。また、そもそもグラフデータベースやグラフ分析とは何なのかという基本概念、古典から現代にわたるユースケースを整理した上で、Pythonによるインメモ

PE と PA をセットで PDP（Policy Decision Point） と呼ぶことが多いです。 判断を助ける脇役たち PDP が判断するための材料（データやルール）を渡してくれるのが、こちらのコンポーネント群。 ICAM（ID・資格情報・アクセス管理） エンドポイントセキュリティ（EDR / EPP） セキュリティ分析 データセキュリティ リソース保護 これらが出してくる判断材料を PIP（Policy Information Point） と呼びます。図にすると「単純な部品が PDP にぶら下がってる」ように見えますが、実際は ICAM や EDR/EPP なんかは 裏でかなり複雑なインフラを抱えている ことが多い、と文書も注意しています。 動きは3つのプロセスで整理 Resource Management — R()：リソース自身の認証と健全性チェック。オンラインの間も定期的

LLM Wiki作成方法 wiki専用ディレクトリをプロジェクトのルートディレクトリに作成 まずは Claude Code の wiki にしたいディレクトリを、プロジェクトのルートディレクトリに作りましょう。 この時点ではフォルダを作るだけで大丈夫です。 私は ai_wiki/ という名前にして、プロジェクトのルートディレクトリに置くようにしています。 a から始まるとファイルツリーの一番上にきて見つけやすいので、この名前にしました。 フォルダができたら Obsidian で開きます。 まだ Obsidian を入れていない人は公式からインストールしてください。 インストールしたら Obsidian を起動して、作ったフォルダを「保管庫としてフォルダを開く」の開くボタンから開くだけで、そのフォルダは自動でセットアップされて、ただの Markdown ファイルでも、検索性にすぐれた Obs

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 最近、Amazon Bedrockで生成AIアプリを開発したり、Bedrock経由でClaudeCodeを動かすという機会が増えてきました。 その中でAmazon Bedrockの「モデル呼び出しのログ記録」の設定をとりあえず有効化して開発を行っていたのですが、 実際のログを見ると、個人情報等サーバに保管してたらまずい情報も色々保存されてしまう状態になってしまってました。 それを受けて「モデル呼び出しのログ記録」のセキュリティ設定を検討しました。 Amazon Bedrockの「モデル呼び出しのログ記録」とは？ Amazon

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ClaudeCodeとCodexにコーディングを全て任せて商用レベルのUnityゲーム開発を行う【後編】 こんにちは、Liseと申します。 現在のゲーム開発現場では恐らく、どんな会社でもどんなプロジェクトでも、ClaudeCodeやCodexを利用した開発のAI補助を行っていたり、ゲームジャム等のイベントで「試しにAIに小規模なゲームプログラミングをさせてみよう」みたいな動きがあると思います。 しかし既にAIを活用しているエンジニアでも、どうしても心の中に心配としてあるのが、 「ゲーム開発や設計を丸ごとAIに投げることが出来ないのか？」

はじめに Anthropicは2026年5月27日、Claude Codeにセキュリティ脆弱性をリアルタイムで検出・修正する公式プラグイン「security-guidance」をリリースしました。 このプラグインは、AIが書いたコードを別のAIが独立してレビューする仕組みで、SQLインジェクション・XSS・コマンドインジェクションなど約25種類の脆弱性パターンをセッション内で検出・修正します。コードレビューやCI/CDスキャンの前段として機能し、PRに到達するセキュリティ問題の量を削減することを目的としています。 この記事で学べること security-guidanceプラグインのインストール方法 3層レビューの仕組み（パターンチェック・ターン終了時レビュー・コミット時レビュー） カスタムルールの設定方法 他のセキュリティツールとの組み合わせ方 前提条件 Claude Code CLI v

PC操作系の OSWorld-Verified も 83.4% という高い水準にあります（前世代比は公式が脚注でスコアを更新しており差分の解釈が割れるため、ここでは絶対値のみ示します）。 このテーブルには、わかりやすい物語があります。エージェント系・ツール利用系（SWE-bench Pro、BrowseComp、MCP-Atlas）が軒並み +5前後の大きな伸びを見せている一方で、純粋な学術的知識を問う GPQA Diamond はわずかに下がっています。 この「いびつさ」をどう読むか。私には、これがトレードオフというより優先順位の表れに見えます。あくまで一つの解釈ですが、GPQA Diamond はすでに93〜94%という天井近くに張り付いていて、ここを0.6%押し上げる労力よりも「ツールを使って実環境で長く働く能力」のほうに伸びしろと価値があった、という事情は想像できます。一問一答の博

RPMがなくなったらしい。 Quotas for the bedrock-runtime endpoint Amazon Bedrock は、bedrock-runtime エンドポイントに対して、1分あたりのリクエスト数（RPM）クォータを今後適用しません。スロットリングは、このセクションで説明されているトークンベースのクォータによって管理されます。 Quotas for the bedrock-mantle endpoint bedrock-mantle エンドポイントでは、1分あたりのリクエスト数（RPM）クォータは適用されません。スロットリングは、このセクションで説明されている入力トークンおよび出力トークンのクォータのみによって管理されます。 だそうです。 確認してみました。 Claude Sonnet 4.6はRPMのクオーターがありますね。 Opusで絞り込むと、4.5、4.6

概要 GitHub Actions やローカル環境において、.NET 10 以降でプロジェクトファイル（.csproj）を作らずに C# の単一ソースファイルを直接実行（dotnet run script.cs）した際、以下のような見慣れないエラーで実行が失敗する現象に直面しました。 Unhandled exception. System.InvalidOperationException: Reflection-based serialization has been disabled for this application. Either use the source generator APIs or explicitly configure the 'JsonSerializerOptions.TypeInfoResolver' property. at System.Text.

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 少し前 SNS でもざわつきがありましたが、Copilot Studio の自律型エージェントを使う際の「クレジット消費の考え方」が、お客様にお伝えする上でかなりややこしくなってきていると感じています。 特に「Microsoft 365 Copilot のライセンスがあるユーザーが作る／使うエージェントなら、一部例外を除いて、Copilot Studio クレジットの消費は気にしなくてよい」と理解されている方が多いと思うのですが、自律型エージェントを作る場合、作り方次第ではクレジットを消費するケースとしないケースがあることが分