AWS
Filed under
ベクトルデータベースは何が最初に壊れるかで選ぶ
ほぼすべてのRAGシステムはpgvectorから始めるべきだ。問うべきはどのベクトルデータベースが最速かではなく、どの障害モードが最初に自分に届くかである。
オンコールをエージェントに。第8回 プロダクション:可観測性、評価、そして嘘をつく日
CloudWatchへのOTELトレース、S3へのBedrock呼び出しログ、ゴールデンインシデントセットのevalハーネス、そしてトリアージエージェントが自信満々に嘘をついた日。
Kiro、その後: AI IDEが実際に変えたもの
KiroのGAから8か月、生き残ったのはspecで、消えかけているのはIDEの方だ。変わったのはコードを書く主体ではなくレビューの場所だった。
推論プロファイルによるアプリ単位のBedrockコスト追跡
アプリケーション推論プロファイルはBedrock呼び出しにコスト配分タグを付与し、共有された請求をチーム別の明細へと変える。難しいのはタグ設計の方だ。
オンコールをエージェントに。第7回 サイジング:誰も事前にやらないトークンの算数
誰も事前にやらないサイジングの算数。インシデントあたりのトークン、クォータの天井、Provisioned Throughputの損益分岐点、そして月額請求書を全部見せる。
EU AI Act、8月2日:動かなかった期限
Digital Omnibusは高リスク規制の期限を2027年と2028年に延期したが、Article 50の透明性義務は2026年8月2日のまま変わらず、多くのチームが直面するのはこちらだ。
SageMaker対Bedrock: 技術ではなく組織の意思決定
SageMakerかBedrockかという問いは、実際にはモデルを所有するチームが組織に存在するかどうかの問題だ。スライド上の組織ではなく実際のチーム構造に合わせて選ぶべきだ。
自社ドキュメント経由のプロンプトインジェクション: RAGの攻撃面
ナレッジベースは信頼できない入力源だ。検索は攻撃者が書いたテキストをそのままモデルに渡してしまうため、取り込み時点でのスキャンが最も有効な対策となる。
オンコールをエージェントに。第6回 Guardrails:誰もがスキップするパート
まず脅威モデル、次にガードレール。TerraformによるBedrock Guardrails、重い仕事を今も担うIAM、そしてステージで誰もデモしない失敗モードを扱う。
AWS月刊(2026年6月): エージェントにフィードバックループが備わった
2026年6月のAWS。ニューヨークのSummitは本番トレースをエージェント改善に変え、セキュリティ向けContinuumを発表し、AgentCoreハーネスをGAへ進めた。
オンコールをエージェントに。第5回 チーム編:Supervisorと3人のスペシャリスト
Supervisorがトリアージ、runbook、costの各エージェントにネットワーク越しに委譲し、AgentCore Memoryが所見を束ねる。単一エージェントで足りる場合も正直に扱う。
AWSはAI生成コードのためのsandboxを構築した: Lambda MicroVMs
AWS Lambda MicroVMsは、AIのagentがモデル生成コードを実行する場所を、VMレベルで隔離して提供する。本番agentに足りなかった最後のピースはruntimeだった。
マルチエージェントシステムの本当の限界はトークン毎分である
Amazon Bedrock は Service Quotas でモデルごとのトークン毎分クォータを公開するようになった。エージェントにとって TPM こそが本当のスケーリング上限だ。429 が始まる前に計画せよ。
オンコールをエージェントに。第4回 ツールとGateway:MCP、許可リスト、read-onlyがデフォルト
ツールがAgentCore Gatewayの背後に移る。スコープを絞ったLambda、クロスアカウントのread-onlyロール、変更を許される唯一のゲート付き経路を解説する。
AIコーディングエージェントにもステージング環境が必要だ
チームはコーディングエージェントに本番環境の認証情報を渡し、それを速度と呼んだ。エージェントは判断力を欠く寄稿者であり、同じ環境の階段が必要になる。
オンコールをエージェントに。第3回 最初のエージェント:Strandsによるインシデントトリアージ
最初のエージェントが稼働開始。AgentCore Runtime上のStrandsトリアージエージェント、証拠優先のシステムプロンプト、2つのread-onlyツールとデプロイ用Terraformを解説する。
CI上のClaude Code: エージェントにビルドを直させる
パイプラインにコーディングエージェントを組み込むのは簡単だ。難しいのはガードレール設計、触れる範囲、停止条件、提案の査読者を決めることにある。
オンコールをエージェントに。第2回 基盤編:トークンより先にTerraform
Bedrockトークンが流れる前に、ops-toolingアカウント、2つのスポークIAMロール、モデルアクセス、推論プロファイルの判断をすべてTerraformで構築する。
コンテキストウィンドウは味方ではない
巨大なコンテキストウィンドウは検索の代わりにはならない。プロンプトが長くなるほど再現率は落ち、トークン数に比例してコストは増え、中間部分は読み飛ばされる。
AWSマンスリー（2026年5月）: エージェントに財布が渡される
2026年5月のAWS: AgentCore Paymentsでエージェントが取引可能になり、Agent Toolkit for AWSと一般提供の管理型MCPサーバーがツールチェーンを強化する。
オンコールをエージェントに。第1回 シナリオ編:なぜ運用チームはエージェントを雇うのか
中堅B2B SaaS企業がオンコールの重労働に耐えかね、AIエージェント導入を決断する。舞台設定とAWS Bedrockアーキテクチャの選定理由を解説する。
PIIをログに残さずプロンプトをログに残す
LLMアプリのデバッグにはプロンプトログが必要だが、生のPIIをその中に残すことはできない。Comprehendで保存前に匿名化し、ログが期限どおり失効するよう保持期間を設定する。
HaikuがOpusに勝るとき: Bedrockにおけるモデルの適正サイジング
すべての呼び出しをデフォルトでOpusに向けることが、LLMの請求額を膨れ上がらせる。タスクの種類でルーティングせよ。機械的な大多数にはHaiku、Opusは難しいケース向けのエスカレーション経路にする。
エージェント型RAGの正体は、大半が不要なレイテンシである
エージェント型RAGは検索ホップをループで回し、各ホップはモデルとの往復になる。ほとんどの質問には1回の良いクエリで十分だ。ループはレイテンシに見合う場合だけ使う。
エージェントの前に評価を: 採点できないものはリリースできない
評価ハーネスがなければ、エージェントへの変更はすべて雰囲気チェックにすぎない。エージェントより先にスコアボードを作り、LLM-as-a-judgeを誤りうるコンポーネントとして扱うこと。
セマンティックキャッシュ: 2つの異なる質問に1つの答え
セマンティックキャッシュは表現の異なる2つの質問に1つの保存済み回答を返す。コストとレイテンシを削減するが、誤ヒットは自信満々に間違った返答を出す。
Step Functionsは最も過小評価されているエージェントオーケストレーター
多くのエージェントワークフローは制御フローの判断にモデルを必要としない。Step Functionsは決定論的なオーケストレーション、リトライ、人間の承認ステートを提供する。
LLMゲートウェイ: すべてのプラットフォームチームがいずれ構築する理由
2つ目のチームがモデルを呼び出し始めると、統制なきファンアウトが始まる。LLMゲートウェイは認証、クォータ、ルーティング、監査を一元化する。自前構築かLiteLLMかAPI Gatewayか。
AWS月報 (2026年4月): OpenAIがBedrockに上陸
2026年4月のAWS: OpenAIのモデル、Codex、Managed AgentsがBedrockに登場し、AgentCoreはマネージドハーネスとCLIを追加してエージェントへの道のりを短くした。
クロスリージョン推論: 安価な耐障害性か、それともデータレジデンシーの罠か
Bedrockのクロスリージョン推論はスループットとスロットリングを平準化する。だがグローバルプロファイルはプロンプトをその地理的範囲の外にルーティングしうる。まずレジデンシーを確認しよう。
あなたのLLM請求額はオブザーバビリティの問題だ
驚くようなBedrockの請求額は価格の問題ではなく可視性の問題だ。トークンを機能やテナント、エージェントに紐付けられなければ、それを管理することはできない。
Bedrockのバッチ推論: 待てるなら半額
Amazon Bedrockのバッチ推論はオンデマンド価格の50%で実行される。コストはレイテンシだけだ。誰も待っていないジョブなら、その取引は言わば無料のお金だ。
マルチテナントLLMアプリ: 共有モデル上で顧客を分離する
1つの共有Bedrockモデルを多くの顧客が使う。モデルはステートレスなので、分離は自分の仕事だ。検索範囲を絞り、クォータを上限で管理し、テナントごとにアイデンティティを運ぶ。
エージェントのメモリはプロンプトの問題ではなくデータベースの問題だ
エージェントの全履歴をプロンプトに詰め込むのはメモリではなく、膨らみ続ける請求額とトークンの上限だ。本物のメモリは検索ステップを持つデータベースである。
構造化出力は巧妙なパースに勝る
まだモデルの文章から正規表現でJSONを抜き出しているのか。やめよう。Bedrockの構造化出力はデコード時にJSON Schemaを強制するので、レスポンスは構造上正しくなる。
Bedrockのプロンプトキャッシング: ほとんどのチームが見過ごす90%割引
Bedrockのプロンプトキャッシングはキャッシュされたプレフィックスの読み取りをおよそ90%割引にするが、キャッシュ書き込みは通常より高くつく。ブレークポイントの置き場所がすべてを決める。
AWS月報(2026年3月): ガバナンスがエージェントに追いつく
2026年3月のAWS: AgentCore PolicyとEvaluationsがGAに到達し、Elemental Inferenceが出荷され、エージェントのガバナンスがデモから本番の制御プレーンへと移行した。
ストリーミング応答はパフォーマンスの決定ではなくUXの決定だ
モデルの応答をストリーミングすることは速度の修正ではなく、最初のトークンまでの時間に関するユーザー体験の選択だ。構造化出力やツール使用ではむしろ悪化させることもある。
Bedrock Agents対、自前のループを書くこと
Amazon Bedrock Agentsはオーケストレーション、メモリ、ツール呼び出しを代行する。マネージドフレームワークが本当に手間を省くのはいつか、静かに支配し始めるのはいつか。
LLMアプリのためのIAM: 呼び出し元がモデルであるときの最小権限
呼び出し元がモデルであっても最小権限は変わらず適用される。各エージェントツールには、単一の広範な管理者クレデンシャルではなく、スコープされたIAMロールとセッションポリシーを与えること。
ファインチューニングをやめよ。必要なのはRAGとキャッシュとより良いプロンプトだ
ファインチューニングとプロビジョンドスループットの組み合わせは、ほとんどのLLMの問題に対する高価な答えだ。より安価な道は検索、プロンプトキャッシュ、より良いプロンプトにある。
Knowledge Baseのチャンキングこそ、RAGの品質が死ぬ場所
ほとんどの誤ったRAGの回答は、モデルの問題ではなく検索の問題だ。Bedrock Knowledge Basesにおける固定長、セマンティック、階層型チャンキングがどう品質を決めるかを解説する。
Bedrock Guardrailsではプロンプトインジェクションを防げない
Amazon Bedrock Guardrailsはコンテンツをフィルタリングするだけで、アクションを認可するものではない。真のプロンプトインジェクション対策は入力の分離、ツールの許可リスト、IAMのスコープ設定にある。