AWS

AWS が公開した「AI 駆動の業務変革手法 AI BPR」の記事が話題になっている。単なる成功事例ではなく、「正しいアプローチが全く機能しない」という壁に正直にぶつかった失敗報告から始まる点が異色で、AI 導入に苦戦する多くの組織にとって示唆に富む内容だ。 AWS が3ヶ月間で発見した「正しいアプローチが機能しない」現実 AWS は自社で3ヶ月間、お客様に AI エージェント導入プログラムを提供してみた。最初に試みたのは、いわゆる BPR の教科書通りのアプローチだ。 ゴール設定 業務フロー分析 ボトルネック特定 AI エージェントで解決 計測 整然としたフローに見えるが、現場から返ってきた反応は想定外だった。 「AI エージェントに任せるのは BCP 上危険」 「提案の枠が狭くて大きな進歩を感じない」 一見もっともらしい抵抗なのだが、よく分解すると全然別の構造が見えてくる。 抵抗の本質：2つの根本的障壁 1. アイデンティティへの脅威 長年積み上げてきた専門性が AI に代替されることへの「存在意義の危機」だ。Stanford の研究でも、45% が AI の精度を懸念し、23% が職の代替を恐れているという。これは能力の問題ではなく存在意義の問題であり、ツール改善では解決できない。 2. 責任の所在を人間に残したい組織心理 「この業務は◯◯さんが詳しい」という言葉の裏を返せば、責任分担の合意だ。AI に委譲するということは、業務停止時の責任も IT 部門に一気に流れ込むということ。それは組織として受け入れがたい。 この2つが合わさると、「やっぱり人間でないと難しい」という一見合理的な「落としどころ」に着地してしまう。AWS はこれを Argyris の言う防衛的ルーティン（defensive routines）・熟達した無能力（skilled incompetence）と結びつけて説明しており、ここが本当に鋭い。 アプローチの転換：「課題は何ですか？」を捨てる AWS が下した判断は、AI BPR を一旦抜本的に見直してゼロから組み直すことだった。 従来の「課題は何ですか？」という問いかけをやめ、「強みは何ですか？」から入る設計に変えた。 「課題は何ですか？」という問い自体が、実は防衛反応を誘発する最悪のフレームだったという発見も重要だ。問題を分析して修正するアプローチは、当事者を「自分たちは問題を抱えた存在」として位置づけてしまう。 Appreciative Inquiry の採用 具体的に採用したのが、Cooperrider & Srivastva が提唱した Appreciative Inquiry（アプリシエイティブ・インクワイアリー、以下 AI）という手法だ。 問題を分析して修正するのではなく、組織の既存の強みと成功体験を発見して増幅することで変革を起こす。 Appreciative Inquiry とは何か AI は 1987 年に Case Western Reserve University の David Cooperrider と Suresh Srivastva が発表した組織開発手法だ。Cooperrider の博士論文（1986 年）が出発点で、以後 40 年近く理論的な拡張と実践が積み重ねられてきた。日本でも 2005 年以降、ヒューマンバリュー社が Diana Whitney を招聘して『ポジティブ・チェンジ』として翻訳・紹介したことで広まっている。 ...

2026年4月7日、AWSがAmazon S3 Filesを一般提供（GA）しました。S3バケットをNFS v4.1/v4.2のファイルシステムとしてマウントできる機能で、EC2・EKS・ECS・Lambdaのいずれからでも利用できます。 本記事は、ikenyal氏のZenn記事「S3 Filesで消えるアーキテクチャ層、生まれるアーキテクチャ」を参照しながら、S3 Filesが既存のアーキテクチャにどう影響するかを整理します。「何が設定できるか」ではなく「何が不要になり、何が可能になるか」にフォーカスします。 S3 Filesが解こうとしている問題 たとえば、MLチームが学習データの前処理をする場面を考えましょう。元データはS3に置いてあり、pandasで読み込んで加工したい場面です。 pd.read_csv("s3://my-bucket/data.csv") と書けますが、内部ではboto3がGETリクエストを発行してメモリに読み込んでいます。手元の open("./data.csv") とは根本的に異なるI/Oモデルです。 規模が大きくなると、これは「パイプラインのアーキテクチャ課題」になります。 S3からEFS/EBSにコピー → 処理 → 結果をS3に書き戻す この「中間のコピー層」は本来やりたい処理ではなく、ストレージのI/Oモデルの違いを埋めるためだけに存在しています。 S3 Filesはこのギャップそのものを解消します。アプリケーションからS3のデータはローカルのディレクトリに見えます。 1 2 3 # S3 Filesを使うと pd.read_csv("/mnt/s3files/data.csv") # S3のオブジェクトが読まれる df.to_csv("/mnt/s3files/result.csv") # 変更が自動的にS3にコミットされる FUSEベースのツールとの違い 「S3をマウントできる」と聞いて、Mountpoint for Amazon S3やgcsfuseを思い浮かべる方も多いでしょう。S3 Filesは内部構造がまったく異なります。 FUSEベースのツールは、S3 APIの上にファイルシステムの振る舞いを「エミュレーション」するアプローチです。ファイルの一部だけを書き換えるような操作がサポートされず、空ディレクトリの扱いに不整合が出ることもあります。 S3 Filesはエミュレーションではなく、EFS（Elastic File System）という本物のNFSファイルシステムをS3に接続しています。二つの異なるシステムが共存し、その間に明示的な同期レイヤーがある構造です。 「stage and commit」モデル ファイルシステム上での変更は即座にS3に反映されるのではなく、約60秒ごとにまとめてS3へPUTされます（「commit」）。逆に、S3側でオブジェクトが更新された場合は通常数十秒以内にファイルシステム側に反映されます。 これは明確なトレードオフです。「リアルタイムに同期される共有ファイルシステム」ではなく、「数十秒の遅延を許容する代わりに、ファイルとオブジェクトの両方のセマンティクスを壊さない」設計です。 消えるアーキテクチャ層 1. S3 → EFS/EBSのステージングパイプライン 100GBの学習データを処理する場合、従来の手順は： S3からEBSにダウンロード（数分かかる） データを処理する 結果をS3にアップロード EBSボリュームをクリーンアップ やりたい処理は2番だけです。S3 Filesでは、S3プレフィックスをマウントするだけで処理スクリプトはそのまま /mnt/s3files/ のファイルを読み書きします。ダウンロード・アップロード・クリーンアップのステップが消えます。 ...

概要 CloudFront + ALB + Django 構成では ALB が X-Forwarded-Proto を上書きするため、Django に HTTP 判定されて API レスポンス URL が http:// になる問題。CloudFront の custom_header（X-Forwarded-Ssl）は ALB に干渉されない。Django の SECURE_PROXY_SSL_HEADER をカスタムヘッダー参照に変更。

概要 main.tf（リソース）/ variables.tf（入力）/ outputs.tf（出力）に分割。大規模化時は modules/ 配下でコンポーネント化。環境ごと（prod/stage）で terraform.tfvars を分離。state lock でマルチユーザーの同時実行防止。 ソース記事 Terraform — 2021-06

Linux を標的とするランサムウェアが新たな段階に入った。イラン系とされる攻撃グループ Pay2Key が Linux 向けに進化し、「Pay2Key.I2P」と呼ばれる新たな亜種を展開している。Morphisec の技術分析をもとに、攻撃の手口、防御機構の無効化手法、そして具体的な対策を整理する。 Pay2Key とは Pay2Key はイラン系の攻撃グループに帰属するランサムウェアで、Fox Kitten APT グループとの関連が指摘されている。従来は Windows を主な標的としていたが、企業のサーバー基盤を直撃する Linux 版が登場し、防御の前提が揺らぎ始めている。 2026年2月には、米国の医療機関で Pay2Key による侵害事例が Beazley Security Incident Response によって対応されている。 Pay2Key.I2P の技術的特徴 設定駆動型の設計 Pay2Key.I2P は単なる Windows 版の移植ではない。JSON 設定ファイルによって動作を制御する設定駆動型の攻撃ツールとして設計されている。ターゲットとするファイルシステムの範囲や暗号化の挙動を柔軟に変更できる。 デュアルアーキテクチャ対応 x64 と ARM64 の両方に対応し、従来の x86 サーバーだけでなく、ARM ベースのクラウドインスタンス（AWS Graviton など）や仮想化ホストも一括で狙うことができる。 root 権限の必須化 侵入後は root 権限を必須とし、取得できない場合は即終了する設計となっている。これはノイズを最小限に抑え、検知を回避するための戦略と考えられる。 防御機構の無効化 Pay2Key.I2P の最も危険な特徴は、Linux の防御機構を体系的に無効化する点にある。 SELinux / AppArmor の無効化 実行時に SELinux や AppArmor を無効化し、強制アクセス制御（MAC）による保護を解除する。これにより、通常であれば制限されるファイルアクセスやプロセス操作が可能になる。 systemd サービスの停止 データベースやバックアップなどの重要なサービスを停止し、ファイルロックを解除して暗号化対象のファイルにアクセスできる状態を作り出す。 cron による永続化 cron エントリを登録してリブート後も自動的に再実行されるようにし、単純な再起動では排除できない永続性を確保する。 暗号化の手法 ChaCha20 による高速暗号化 暗号化アルゴリズムには ChaCha20 を採用している。AES と比較してソフトウェア実装での処理速度に優れる。AES-NI などの専用ハードウェアを持たない環境でも高速に動作する。 ...

AWS DMS Serverless Replication（CDC モード）が OOM（Out of Memory）で failed 状態になり、自動再起動の仕組みが検知できずに長期間停止していた問題について、根本原因と対策をまとめます。 構成 RDS (MySQL) → DMS Serverless (CDC) → S3 (Parquet) DMS Serverless Replication で全テーブルの CDC（Change Data Capture）を実行 S3 に Parquet 形式で日付パーティション付きで出力 EventBridge + Lambda で DMS 停止を検知し自動再起動する仕組みを構築済み 発生した事象 症状 prod 環境の DMS Serverless Replication が failed 状態で停止 エラーメッセージ: Replication out of memory. Stop Reason FATAL_ERROR Error Level FATAL CDC が完全に停止し、S3 へのデータ同期が止まっていた 発覚の経緯 手動確認で発見。自動再起動 Lambda の最終実行は約2ヶ月前で、それ以降は検知されていなかった。 根本原因 原因 1: EventBridge ルールのイベントパターンが不完全 自動再起動用の EventBridge ルールが REPLICATION_TASK_STOPPED のみを監視していた。 ...

AWS が「Agent Plugins for AWS」を公開しました。AI コーディングエージェント（Claude Code や Cursor など）に、AWS のアーキテクチャ設計からデプロイ実行までの能力を組み込むオープンソースのプラグインライブラリです。 Agent Plugins for AWS とは Agent Plugins for AWS は、AWS Labs が開発・公開したオープンソースプロジェクトです。コスト見積もり、Infrastructure as Code（IaC）の生成、デプロイといった AWS 固有のスキルセットを AI エージェントに追加できます。 プラグインは以下の要素で構成されています: Agent Skills: 複雑なタスクをステップバイステップで実行するワークフロー。デプロイやアーキテクチャ設計のベストプラクティスを手順として組み込んだもの MCP サーバー: 外部サービス、ドキュメント、料金データなどへのリアルタイム接続 Hooks: 開発者のアクションに対するバリデーションやガードレール deploy-on-aws プラグイン 現時点で提供されている主要プラグインが deploy-on-aws です。「deploy to AWS」と指示するだけで、以下の 5 ステップを自動実行します: コードベースの分析: アプリケーションの構成・依存関係を解析 AWS サービスの推奨: 最適な AWS サービスを理由付きで提案 コスト見積もり: 推奨構成の月額コストを試算 IaC の生成: CDK または CloudFormation でインフラコードを生成 デプロイ実行: ユーザーの確認後にデプロイ AWS によると、従来は数時間かかっていたデプロイフローが約 10 分で完了するとのことです。 Claude Code へのインストール Claude Code では、プラグインマーケットプレイス経由でインストールします: ...

きっかけ ある日、開発環境の Web アプリにアクセスしたら証明書の期限切れ警告が表示された。 確認してみると、ワイルドカード証明書 (*.dev.example.com) がちょうどその日に期限切れになっていた。さらにもう1つ古い証明書も半年前に失効済み。 Certificate Name: dev.example.com-0001 Domains: *.dev.example.com Expiry Date: 2026-03-17 (INVALID: EXPIRED) Certificate Name: dev.example.com Domains: *.dev.example.com dev.example.com Expiry Date: 2025-09-17 (INVALID: EXPIRED) 原因 certbot の renewal 設定を確認したところ、問題が見えた。 1 2 3 [renewalparams] authenticator = manual pref_challs = dns-01, authenticator が manual になっていた。 ワイルドカード証明書は DNS-01 チャレンジが必須だが、manual モードでは certbot が更新のたびに「この TXT レコードを DNS に追加してください」と対話的に聞いてくる。つまり 自動更新が不可能 な状態だった。 systemd timer (certbot.timer) は1日2回動いていたが、manual モードの証明書は自動更新をスキップされるため、期限切れまで放置されていた。 対応方針 2つの選択肢を検討した。 ...

.env を AI に安心して触らせる — 1Password CLI ラッパー「opx」とプロセススコープ認証の設計 @suin 氏のポストが、AI エージェント時代の .env 管理問題に対する実践的な解決策として、自作の 1Password CLI ラッパー「opx」を公開しています。 .envをAIに安心して触らせたくて、こんなの作った AIエージェントなしではもう開発が成り立たないほど必須になってきています。権限設定がいろいろできるにせよ、本質的にAIエージェントにはプロジェクトの全ファイルを触りうる力を与えているわけで、気になるのがシークレットなどの機密情報です。 Claude Code や Cursor などの AI コーディングエージェントは、開発者と同じ権限でファイルシステムにアクセスします。.env にアクセストークンや AWS キーを平文で書いていれば、エージェントはそれを読めてしまいます。この構造的な問題に対し、「.env に機密情報を一切書かない」というアプローチで解決するのが opx です。 問題の構造 — AI エージェントが .env を読める なぜ危険なのか AI コーディングエージェントは通常のプロセスとして動作し、シェル環境を継承します。 開発者のシェル └── AI エージェント（Claude Code, Cursor 等） ├── ファイルシステムへのフルアクセス ├── .env ファイルの読み取り ├── 環境変数の参照 └── Bash コマンドの実行 .zshrc に AWS_SECRET_ACCESS_KEY を書いていれば、エージェントもそれを持っています。プロンプトインジェクション攻撃を受けた場合、エージェントが意図せず機密情報を外部に送信するリスクがあります。 実際に報告されている脆弱性 2025年末に公開された「IDEsaster」と呼ばれる調査では、Cursor、Windsurf、GitHub Copilot、Cline など30以上の AI IDE に脆弱性が発見されています。OpenAI Codex CLI では .env ファイルを経由した任意コマンド実行の脆弱性（CVE-2025-61260）も報告されました。 ...

.env の代わりに aws-vault で安全に環境変数を与える — Claude Code 時代の AWS 認証情報管理 AI エージェントがローカルファイルを直接読み書きする時代、.env に平文で認証情報を置くリスクが顕在化しています。前回の記事では、この問題の背景と複数のシークレット管理ツールを紹介しました。 本記事では、AWS を利用しているチームに向けて、aws-vault を使って .env と ~/.aws/credentials を完全に排除する具体的な手順を解説します。 aws-vault が解決する問題 ~/.aws/credentials の平文問題 AWS CLI を使う開発者の多くは、~/.aws/credentials にアクセスキーを平文で保存しています。 1 2 3 4 # ~/.aws/credentials（平文で保存されている） [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY このファイルには2つのリスクがあります。 Claude Code が読み取れる: AI エージェントがファイルシステムを探索する際、~/.aws/credentials のアクセスキーが LLM のコンテキストに載る可能性がある 長期的な認証情報が漏洩する: アクセスキーには有効期限がなく、漏洩した場合は手動でローテーションするまで悪用され続ける aws-vault のアプローチ aws-vault は以下の2段階で問題を解決します。 暗号化保存: アクセスキーを ~/.aws/credentials ではなく、OS のキーストア（macOS Keychain 等）に暗号化して保存する 一時認証の生成: AWS STS（Security Token Service）を使って、1時間で失効する一時認証情報を生成し、子プロセスに注入する [従来] ~/.aws/credentials（平文） → AWS CLI / boto3 が直接読み取り → 長期キーがメモリに残る [aws-vault] macOS Keychain（暗号化） → aws-vault が STS で一時認証を生成 → 子プロセスに環境変数として注入 → 1時間で失効 セットアップ インストール 1 2 3 4 5 6 7 8 9 10 11 12 13 # macOS（推奨） brew install --cask aws-vault # macOS（Homebrew formula 版） brew install aws-vault # Linux brew install aws-vault # Windows choco install aws-vault # または scoop install aws-vault macOS では --cask 版が推奨されています。コード署名されているため、Keychain アクセス時の追加のパスワードプロンプトが少なくなります。 ...