こんにちは、ソフトバンクグループとOpenAIの合弁会社であるSB OAI JapanでSoftware Engineer(SWE)をしている井上です。 最近、AIエージェントという言葉を耳にする機会が増えてきました。 これまでの生成AIは、質問に対して文章やコードを生成してもらうという使われ方が中心でした。一方で、AIエージェントは、与えられた目的に向けて必要な作業を考え、ファイルやツールを使いながらタスクを進めます。 OpenAIが開発したCodexもAIエージェントの一つです。 Codexはコードを生成するだけでなく、与えられた目的やプロジェクトの状況を踏まえて作業を計画し、必要な

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週も生成 AI に関する 1 週間のアップデートをお届けします。 いつもご案内している生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム について、このプログラムの 1 コースである 「 フィジカル AI 開発支援プログラム by AWS ジャパン 」第 2 期 の応募受付が始まりました。VLA をはじめとするロボット基盤モデルや、VLM、世界モデルなどの周辺技術を AWS 上で開発する企業・団体が対象で、スタートアップから大企業、大学・研究機関まで応募できます。フィジカル AI のスペシャリストによる技術支援、コスト最適化、コミュニティ形成、GTM 支援が受けられ、第 1 期に応募した方も再応募が可能です。締切は 11 月 16 日（月）なので、ロボティクス × 生成 AI に取り組んでいる方は是非ご検討ください。 また、 re:Invent 2026 のセッションカタログ も公開されていますのでこちらもチェックしてみてください。 それでは 10 月 19 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「 約 3 万人のAIネイティブエンジニア体制へ ― NEC は Claude Code をどう全社展開しているのか？ CoE・チャンピオン制度による取り組み 」 NEC は全社員 (最大 12 万人) 向けに Claude Desktop on Amazon Bedrock を展開しています。開発現場では約 3 万人の AI ネイティブエンジニア体制を目指し、Claude Code on Amazon Bedrock の活用を広げています。成功要因として、各事業部門の推進体制 (部門 CoE)、チャンピオン制度、Skills による知見の標準化の 3 つを挙げています。2026 年 7 月と 8 月には NEC と AWS の共催で Claude Code ワークショップを開き、延べ 158 名が参加しました。アンケートでは 93% が開発業務で活用したいと回答しています。生成 AI ツールの定着を進める大規模組織にとって、推進体制と人材育成の組み合わせ方の具体例になります。 AWS生成AI国内事例ブログ「 株式会社コーテッグ様の「聞くだけ」で分析が完結する AI 分析基盤「Dotta」を Amazon Bedrock AgentCore で実現 」 株式会社コーテッグは、自然言語で問いかけるだけでデータの取得・集計から可視化、レポート生成まで完結する AI 分析プラットフォーム「Dotta」を構築しました。Amazon Bedrock AgentCore を中核にした非同期の AI エージェント基盤です。分析処理は数十秒から数分かかるため、Amazon SQS と AWS Lambda から AgentCore Runtime を呼び出す構成にしています。分析には Claude Opus 4.8 / Sonnet 4.6、軽量な処理には Claude Haiku 4.5 と使い分けています。試算では 1 件 240 分の分析業務が約 10 分になります。長時間実行するエージェントを UI を止めずに本番運用する設計の実例として、エージェント基盤を検討中の方に役立ちます。 ブログ記事「 Amazon Bedrock API キーの保護: 実装と管理のベストプラクティス 」 AWS は Amazon Bedrock の認証に AWS STS の一時的な認証情報を優先し、使えない場合のみ API キーを検討するよう推奨しています。API キーには短期キーと長期キーの 2 種類があります。短期キーの有効期間は IAM セッションと 12 時間の短い方で、長期キーは 1 日から無期限まで設定できます。防御では bedrock:BearerTokenType など 4 つの条件キーを SCP で使う方法を示します。検知では CloudTrail の callWithBearerToken フラグを拾う Amazon EventBridge ルール、対応では AWS CLI でキーを無効化・削除する手順を扱います。 ブログ記事「 Amazon Bedrock における最小権限アクセスの実装 」 Amazon Bedrock を使うアプリケーションに最小権限の原則を適用する方法を、モデルの選択・適応・テスト・運用の 4 つのフェーズに沿って解説しています。Anthropic と Amazon のモデルだけを許可リスト方式で使えるようにする SCP や、AWS PrivateLink の VPC エンドポイントポリシーで呼び出せるモデルを限定する例を示します。条件キー bedrock:GuardrailIdentifier で特定のガードレールの利用を強制する方法も扱います。運用フェーズでは、モデル呼び出しログの閲覧権限を 3 つの IAM ロールに分ける構成を提案しています。ポリシー例をそのまま出発点にできるため、生成 AI 基盤の権限設計を任された方の時間を節約できます。 ブログ記事「 AWS のサービスで構築する生成 AI アプリケーションのセキュアなネットワークアーキテクチャ 」 「生成 AI をセキュアにする」シリーズのパート 5 として、生成 AI アプリケーションを外部脅威から守るネットワーク設計を多層防御の観点で解説しています。DDoS 攻撃、ウェブリクエストフラッド、SQL インジェクションなどの脅威を整理したうえで、AWS PrivateLink による Amazon Bedrock API へのプライベート接続、AWS WAF の Bot Control と Anti-DDoS マネージドルールグループ、AWS Shield、AWS Network Firewall を順に紹介します。最後に Amazon CloudFront を入口にしたリファレンスアーキテクチャをまとめています。一般公開する前に、ネットワーク面の防御に抜けがないか確認するチェックリストとして使えます。 ブログ記事「 スピードと安全性の両立: AI コーディングエージェントのためのコントロールフレームワーク 」 AI コーディングエージェントは、組織のリスクを理解しないままマシンの速度で動きます。記事はそのためのアプリケーションセキュリティ (AppSec) のフレームワークとして、プロンプトインジェクションやスコープクリープなど 7 つのリスクを整理し、対策を 2 つの柱に分けます。作成時 (author-time) はステアリングドキュメント、レビュー済みの仕様、MCP (Model Context Protocol) のツールアクセス制御で IDE 内の生成を方向付けます。ビルド時 (build-time) はシークレット検出・SAST・SCA・IaC のスキャンと品質ゲート、人間によるレビューで本番到達前に検証します。エージェント導入とセキュリティチームの承認を両立したい開発組織が、どこにガードレールを置くかを決める指針になります。 ブログ記事「 Amazon Bedrock と LiteLLM による OpenAI ChatGPT Codex の予算・レート制限管理 」 OpenAI Codex のモデル推論を、お客様の AWS アカウント内に置いた LiteLLM ゲートウェイ経由で Amazon Bedrock 上の OpenAI モデルにルーティングする構成を解説しています。LiteLLM はオープンソースの AI ゲートウェイです。Amazon ECS (AWS Fargate) にデプロイし、モデルエイリアス、ユーザーやチーム単位のスコープ付きキー、予算とレート制限を一元管理します。ローカルのツール実行は引き続き開発者側の Codex が担います。代替経路として AWS IAM Identity Center による直接アクセスと Portkey も比較しています。コーディングエージェントの利用が個人の試行から全社導入に広がる段階で、誰がどれだけ使ったかを把握したい方に向いています。 ブログ記事「 AWS DevOps Agent で調査コストを事前に制御する 」 AWS DevOps Agent の調査で、最初の課金対象クエリを実行する前にコストを見積もって予算と照合する、オープンソースのスキル「Investigation Cost Guardrail」を紹介しています。動詞ベースのルールや有料操作レジストリを含む 4 層で操作を分類し、AWS Price List API から対象リージョンの最新料金を取得します。判定は Proceed・Warn・Halt の 3 種類です。たとえば 9 月全体のログの相関分析は 2,673 GB のスキャンで $13.37 と見積もられ、デフォルト予算の $10.00 を超えるため停止します。GitHub の aws/tools-for-devops-agent から導入できます。エージェントに調査を任せたいが、ログのスキャン料金が読めないという運用チームの不安に直接応える内容です。 ブログ記事「 AWS Physical AI Toolchain を発表 」 Physical AI Toolchain on AWS は、ロボットなどのフィジカル AI のポリシーを AWS 上でトレーニング・デプロイするための、リファレンスアーキテクチャと Infrastructure as Code を 1 つにまとめた一般公開のコレクションです。NVIDIA の GR00T (VLA モデルのトレーニング)、Isaac Sim (シミュレーション)、Isaac Lab (強化学習)、Cosmos (合成データ生成)、OSMO (オーケストレーション) を AWS のマネージドサービス上で 1 つのパイプラインとして動かします。GitHub の aws-samples リポジトリでワークショップもあります。工程間の引き継ぎに時間を取られているロボティクスチームが、基盤構築を省いてモデル改善に集中できます。 ブログ記事「 AWS で AI を活用したスタジオを構築するためのガイダンス 」 スタジオが生成 AI をコンテンツ制作に組み込むためのプラットフォームアーキテクチャ「AI-Powered Studio」を紹介しています。設計の軸は Consistency (一貫性)、Context (コンテキスト)、Control (コントロール)、Compliance (コンプライアンス)、Cost (コスト) の 5 つの C です。中核はサーバーレスのオーケストレーションで、AWS AppConfig の設定変更だけでモデルを切り替えられます。来歴 (プロベナンス) は生成時に DynamoDB へ自動記録されます。モデルが数か月で入れ替わる中、特定ツールに依存せずに来歴と権利の説明責任を果たしたいメディア企業にとって、設計の土台になります。 ブログ記事「 Kiro IDE と CLI にメモリ機能が登場 」 Kiro IDE と Kiro CLI にメモリ機能が導入されました。Kiro は、好みの作業の進め方、リポジトリ固有のコマンドや規約、受けた訂正、デバッグで得た知見、すでに除外したアプローチを覚えます。再び関係する場面で、そのコンテキストを引き継ぎます。メモリはマシンのローカルに保存され、そのマシン上の IDE と CLI で共有されます。IDE では Memories ビューで一覧・検索や削除ができ、CLI では /memories で確認やアクセス設定を行います。既定ではオフで、Kiro IDE 1.4.0 以降と Kiro CLI 2.29.0 以降のローカル V3 セッションで利用できます。セッションごとに同じ前提や訂正を繰り返している方は、その手間を減らせます。 ブログ記事「 Kiro はどのように自らを修正し、その修正の正しさをどう担保しているか 」 Kiro のファイル読み取り・検索ツールの説明に、ハーネスの動作について事実と異なる一文がありました。この一文は数百のセッションで 61,742 回モデルに届いていました。Kiro チームは実行結果から改善を提案する社内システム kiro-trace を構築しました。変更の提案はモデルが行いますが、受け入れるか退けるかは決定論的なコードが 3 段階のゲートで判定し、最後に人がレビューしてマージします。最初の 1 週間で 7 件の修正がマージされ、会話の要約 (コンパクション) の保持率は 0.82 から 0.92 に改善しました。自社のエージェントを自己改善させたい開発者にとって、「提案する者と判定する者を分ける」という教訓がそのまま使えます。 サービスアップデート Grok 4.7 が AWS GovCloud (US) の Amazon Bedrock で利用可能に AWS GovCloud (US) の Amazon Bedrock で、SpaceXAI の Grok 4.7 が利用できるようになりました。コーディング、エージェント型タスク、ナレッジワーク向けのフロンティアモデルです。Grok 4.6 より複数文書を混在させた入力の扱いとリポジトリ規模のコーディングの安定性が向上しています。GovCloud の要件がある米国公共部門のワークロードでも、最新のフロンティアモデルを選択肢に加えられます。 Amazon CloudWatch Omni が追加の AWS リージョンで利用可能に AI を活用したオブザーバビリティ体験である Amazon CloudWatch Omni が、新たに 8 つの AWS リージョンで利用できるようになりました。追加されたのは、東京リージョンを含む、カナダ (中部)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (ロンドン)、南米 (サンパウロ) です。CloudWatch Omni では、アプリケーションとエージェントの観測やトラブルシューティングを 1 か所で行えます。チャット操作から AWS DevOps Agent による根本原因の特定まで進められます。国内にデータを置いたまま、AI による障害調査を運用に取り入れられるようになります。 AWS が TorchNeuron を発表: AWS Trainium 向けのネイティブ PyTorch サポート (パブリックベータ) AWS Trainium 向けのオープンソースのネイティブ PyTorch バックエンド、TorchNeuron のパブリックベータが公開されました。PyTorch コードを .to('neuron') に切り替えるだけで Trainium 上で動かせます。eager 実行、torch.compile、標準の PyTorch API との互換性は維持されます。Neuron Kernel Interface (NKI) と統合され、カスタムオペレーターも実装できます。Amazon EC2 の Trainium2 と Trainium3 インスタンスで使えます。既存の PyTorch コードを大きく書き換えずに Trainium のコスト効率を試せる点が、移行を検討するチームにとっての価値です。 Amazon Bedrock Advanced Prompt Optimization がプロンプト短縮に対応 Amazon Bedrock Advanced Prompt Optimization に、評価スコアを維持または改善しながらプロンプトの長さを削減するオプション設定、プロンプト短縮が追加されました。これまでは最適化後のプロンプトが元より長くなることが多く、入力トークンのコストや最初のトークンが返るまでの時間を増やす要因になっていました。有効にすると、元より短く、かつ評価で同等以上のスコアを得た場合にのみ最適化後のプロンプトが返されます。Advanced Prompt Optimization が利用できるすべての AWS リージョンで使えます。品質を落とさずに推論コストとレイテンシーを下げたい本番アプリケーションで、手作業のプロンプト圧縮を置き換えられます。 Amazon Bedrock Guardrails がコンテキストグラウンディングチェックの Standard ティアに対応 Amazon Bedrock Guardrails のコンテキストグラウンディングチェックに Standard ティアが追加されました。この機能は、モデルの応答が参照ソースに基づき、ユーザーの質問に関連しているかを確認してハルシネーションを検出・フィルタリングします。Standard ティアは推論や会話的な内容を含む応答に対応し、対応言語も広がりました。料金は Classic ティアと同じで、利用にはガードレールプロファイルを使ったクロスリージョン推論が必要です。東京リージョンを含む次の AWS リージョンで利用できます: 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、アジアパシフィック (東京)。会話型の RAG アプリケーションでも、同じ料金で根拠のない回答をより確実に抑えられます。 Amazon WorkSpaces が、運用・管理するインフラを減らしつつ、エンタープライズクラウドデスクトップへの AI エージェントの安全なアクセスを簡素化 WorkSpaces for AI agents が、認証とデスクトップ接続をマネージドな MCP (Model Context Protocol) サービスの一部として処理するようになりました。カスタムコードを書かずにエージェントを統制されたクラウドデスクトップに接続でき、MCP に対応するあらゆるクライアントから WorkSpaces を利用できます。手動だったストリーミング URL の生成とローテーションが不要になり、既存の AWS 認証情報を使った OAuth 2.0 で接続のライフサイクルをサービス側が管理します。エージェントのセッションは、人間の従業員と同じネットワーク分離とコンプライアンスの境界内で実行されます。新たに南米 (サンパウロ)、欧州 (ミラノ)、欧州 (スペイン)、アジアパシフィック (マレーシア) でも利用できます。GUI 操作が必要な社内アプリケーションをエージェントに任せたいが、セキュリティ境界は崩したくない企業にとって現実的な選択肢になります。 Polly の Generative エンジンがアップグレード: より自然な音声、14 の新しい音声、2 つの新言語 Amazon Polly の Generative エンジンに新しい基盤モデルが導入され、より自然で正確な音声を低レイテンシーで出力できるようになりました。9 つのロケールにわたる 14 の新しい音声が追加され、ヒンディー語とフィンランド語が Generative エンジンで初めて一般提供されました。ストリーミング API により、LLM ベースの音声エージェントをリアルタイム会話向けに構築できます。新しい Generative 音声は、東京リージョンを含む次の AWS リージョンで利用できます: 米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (チューリッヒ)、欧州 (ロンドン)、アジアパシフィック (シドニー)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (東京)、カナダ (中部)、AWS GovCloud (米国西部)。音声エージェントの応答品質を上げたい方は、東京リージョンでそのまま試せます。 Amazon Bedrock で Claude モデルの構造化出力が利用可能に Amazon Bedrock が、bedrock-runtime と bedrock-mantle の両エンドポイントで、すべての Anthropic Claude モデルの構造化出力に対応しました。定義したスキーマに従う JSON 応答を受け取れるため、独自のパース処理やリトライロジックは不要です。Claude モデルが利用できるリージョンで使えます。抽出結果の形式崩れに対処するコードを書いて保守してきた方は、その負担から解放されます。 AWS Neuron 2.33 がネイティブ PyTorch サポート、Neuron Observer などの新機能を追加 AWS Neuron 2.33 がリリースされ、AWS Trainium 向けのネイティブ PyTorch バックエンドである TorchNeuron がパブリックベータとして導入されました。PyTorch のモデルを Amazon EC2 Trn2 および Trn3 インスタンス上で eager モードまたは torch.compile で実行できます。あわせてパブリックベータの Neuron Observer が導入され、Trainium の健全性の問題を 1 秒未満で検出し、影響を受けたノードやデバイスを特定します。NKI Library には DeepSeek-V3.2、Qwen3.5、Kimi Delta Attention 向けを含む 25 の実験的カーネルが追加されました。大規模学習でノード障害の特定に時間を取られているチームにとって、Neuron Observer は停止時間の短縮につながります。 Amazon SageMaker AI がサーバーレスモデルカスタマイズジョブでカスタムシーケンス長に対応 Amazon SageMaker AI のサーバーレスモデルカスタマイズジョブで、学習時に使うシーケンス長を設定できるようになりました。これまでは各レシピが固定のシーケンス長で実行されていましたが、モデルと手法の公開上限 (多くのモデルで最大 16K トークン) までの範囲でハイパーパラメータとして指定できます。SFT と DPO では dataset_max_len を、RFT では max_prompt_length と max_response_length を使います。東京リージョンを含む、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用できます。複数ページの文書を学習データにしたいのに切り詰められていた、という課題を解消できます。 Reflection の Beam モデルが Amazon SageMaker JumpStart と AWS Trainium で利用可能に 米国の Reflection が提供する初のオープンウェイトモデル Beam が、Amazon SageMaker JumpStart で利用できるようになりました。推論、コーディング、エージェント型のベンチマークで高い性能を示し、Apache 2.0 ライセンスで公開されています。ファインチューニングや重みの検査・変更を行い、自身の AWS アカウント内で実行できます。AWS Trainium3 向けに最適化され、当初は米国東部 (バージニア北部) と米国東部 (オハイオ) で BF16、FP8、NVFP4 のチェックポイントをデプロイできます。モデルの重みとデータを自社の管理下に置きつつフロンティア級の性能を求める組織にとって、新しい選択肢になります。 AWS Continuum for code vulnerabilities が一般提供開始 AWS Continuum for code vulnerabilities が一般提供を開始しました。コードの脆弱性をマシンスピードで発見、検証、優先順位付けし、修正する機能です。AWS 環境のリソース、アイデンティティ、ネットワーク到達性からコンテキストグラフを構築し、検出結果を隔離されたサンドボックスでテストして悪用可能なものを確認します。修正パッチはプルリクエストとして開発者のワークフローに届きます。利用開始時はユーザーが承認する Learn モードで動作し、信頼が高まれば自律的に動く Enforce モードに切り替えられます。大量のアラートのうち、本当に対処すべきものだけに人手を割きたいセキュリティチームの負荷を下げます。 AgentCore Gateway が Bedrock InvokeModel API とモデルフォールバックに対応 Amazon Bedrock AgentCore Gateway の推論エンドポイントが、Amazon Bedrock の InvokeModel API と InvokeModelWithResponseStream API に対応し、モデルフォールバックルーティングも追加されました。既存の Amazon Bedrock SDK の統合をそのままゲートウェイに向けるだけで、統制された 1 つのエンドポイントから任意のモデルプロバイダーに到達できます。モデルフォールバックでは、プライマリの宛先がスロットリング、容量不足、到達不能の場合に自動で代替のモデルやプロバイダーに振り分け、組み込みのサーキットブレーカーが失敗中の宛先をスキップします。Amazon Bedrock AgentCore Gateway が利用できるすべての AWS リージョン (中国リージョンを除く) で使えます。各クライアントにリトライ処理を書き込まずに、エージェントの可用性を基盤側で確保できます。 Amazon OpenSearch Service が Amazon S3 のログとドキュメント向けのインテリジェントインジェストを発表 Amazon OpenSearch Serverless に、Amazon S3 に保存されたログやドキュメントを OpenSearch Serverless (NextGen) コレクションで検索可能にするフルマネージド機能、インテリジェントインジェストが追加されました。コンソールの数クリック、または 1 回の API 呼び出しで設定でき、JSON 形式のログと、PDF、Word、プレーンテキスト、Markdown 形式の非構造化ファイルに対応します。ドキュメントの解析、画像の説明生成、チャンク化、ベクトル埋め込みの生成、インデックス作成までを自動で行い、料金はアクティブな処理分のみです。東京リージョンを含む AWS リージョンで利用できます。RAG 用のインデックス構築パイプラインを自作・保守してきたチームは、その工程をまるごと置き換えられます。 Amazon SageMaker AI がサーバーレスモデルカスタマイズ向けのトレーニングセッション API を発表 Amazon SageMaker AI のサーバーレスモデルカスタマイズに、トレーニングセッション API が追加されました。GPU インフラを管理することなく、チーム自身がトレーニングループを記述し、カスタム損失関数や新しい RL 報酬信号などを実装できます。 forward_backward() 、 optim_step() 、 sample() といった操作がライブセッションへの API 呼び出しになり、GPU の割り当て、分散実行、障害復旧は SageMaker AI が担います。課金は処理トークン単位です。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ) で一般提供されています。既成のレシピでは足りない研究寄りのポストトレーニングを、GPU クラスターを持たずに試したいチームに向いています。 Amazon SageMaker AI が Muse Glimmer、Qwen 3.8、Ministral 3 モデルのサーバーレスモデルカスタマイズに対応 Amazon SageMaker AI のサーバーレスモデルカスタマイズが、Muse Glimmer、Qwen3.8 27B、Ministral 3 の 3B、8B、14B モデルに対応しました。教師ありファインチューニング (SFT)、直接選好最適化 (DPO)、強化ファインチューニング (RFT) で適応させられ、LoRA (低ランク適応) とフルファインチューニングのどちらも選べます。東京リージョンを含む、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用できます。小さなモデルを自社データで調整してコストとレイテンシーを下げたい場合に、選べるベースモデルの幅が広がります。 Web Search on Amazon Bedrock がドメインフィルタリングとユーザー位置情報の制御に対応 Web Search on Amazon Bedrock に、ドメインフィルタリングとユーザー位置情報が追加されました。どちらも OpenAI Responses API リクエスト内の web_search ツールで設定します。ドメインフィルタリングでは、最大 100 件の allowed_domains で信頼できるソースに結果を限定したり、最大 100 件の blocked_domains で不要なソースを除外したりできます。ユーザー位置情報では、その地域に関連する結果を返せます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、AWS GovCloud (米国西部) で利用できます。公式サイトや指定ソースだけを根拠にした回答が求められる業務用途で、検索結果の出所を統制できます。 Kiro : Claude Haiku 5.5 が利用可能に Kiro で Claude Haiku 5.5 が実験的 (Experimental) サポートとして利用できるようになりました。対象は Pro、Pro+、Pro Max、Power のお客様で、us-east-1 (IAD) と eu-central-1 (FRA) において Kiro IDE、CLI、Crew、Web から使えます。1M トークンのコンテキストウィンドウを持ち、クレジット倍率は 100K トークンまでのリクエストが 0.06x、100K トークンを超えるリクエストは 0.3x です。定型的な変更や大量のファイル処理を低コストでこなしたい場面で、クレジットの節約につながります。 Kiro : Claude Fable 5.1、Claude Sonnet 5.5、GPT-5.6 Terra、GPT-5.6 Luna が一般提供開始 Claude Fable 5.1、Claude Sonnet 5.5、GPT-5.6 Terra、GPT-5.6 Luna が、Kiro の完全なサポート付きで一般提供になりました。GPT-5.6 Sol は引き続き Experimental です。Fable 5.1 は米国東部 (バージニア北部) (us-east-1) の Kiro Enterprise 組織向けに、Sonnet 5.5 は Kiro IDE、CLI、Crew、Web で、GPT-5.6 Terra と Luna は Kiro IDE、CLI、Web で利用できます。Sonnet 5.5、Terra、Luna は米国と EU の地域で Pro、Pro+、Pro Max、Power のお客様が利用できます。Preview と Experimental のラベルが外れ、Kiro Excluded Models の補償 (indemnity) 例外も適用されなくなりました。試験的な扱いが理由でこれらのモデルを本番で使えなかった組織は、補償の面でも採用を検討しやすくなります。 Kiro CLI 2.34.0 : MCP Elicitation、ワークフローの制御、メモリの削除 Kiro CLI 2.34.0 では、ローカルの V3 セッションで MCP ツールが入力を求められるようになりました (MCP Elicitation)。追加情報が必要なときにツールが一時停止してフォームやリンクを表示し、利用者は入力、別ページでの操作、拒否を選べます。ワークフローでは、V3 のプラン承認時に変更案を直接入力するとステップの実行前にプランが更新され、新しい Workflow use 設定で Only when asked、Only for large tasks、As much as possible からワークフローを開始するタイミングを選べます。 /memories でメモリを削除、 /model edit で使わないモデルを非表示にできます。ツールが足りない情報を聞き返せるようになったことで、認証や確認が必要な MCP 連携を途中で諦めずに進められます。 Kiro CLI 2.33.1 : ワークフローは依頼したときだけ開始 Kiro CLI 2.33.1 では、V3 の Workflows の開始方法が変わりました。機能を有効にしただけではワークフローは開始されず、明示的に依頼したときだけ実行されます。修正では、スクリーンリーダー使用時に /tools が各ツールの Source、Status、Description を 1 行ずつラベル付きで表示するようになりました。V2 セッションを V3 で再開する際は、保存済みのツール承認が引き継がれないことと、V3 で承認を維持する方法が案内されます。画像の多い長い V3 セッションがリクエスト上限で失敗する問題なども修正されました。小さな依頼のたびにワークフローが立ち上がって待たされていた方は、通常のチャットの軽快さが戻ります。 Kiro CLI 2.33.0 : ワークスペースの信頼、ワークフロープランのステップツリー、Mermaid サブグラフ Kiro CLI 2.33.0 では、対話型の V3 セッションにワークスペースの信頼 (workspace trust) が追加されました。フォルダで初めて V3 セッションを開始すると、そのフォルダの hooks、エージェント、MCP サーバー、steering、ワークフロー設定を読み込む前に「Trust this workspace?」画面が表示されます。回答はワークスペースルートごとに ~/.kiro/workspace-roots/ に保存されます。V3 セッションではモデルフォールバックの設定が再び可能になり、ワークフローのプラン承認はコンパクトなステップツリーで表示されます。クローンしたリポジトリに含まれる設定が、許可なくエージェントの挙動を変えるリスクを防げます。外部コードを扱う機会の多い方ほど効果があります。 Kiro IDE 1.4.26 : Kiro がワークフローを使うタイミングを選択 Kiro IDE 1.4.26 では、チャットの Workflows パネルに Use workflows の設定が追加され、Only when asked、Only for large tasks、As much as possible から Kiro がワークフローを開始する頻度を選べるようになりました。新しいチャットは Only when asked で始まり、選択は新しいローカルチャットにも記憶されます。あわせて、Kiro CLI でインストールした Powers が Powers パネルの Installed 一覧に表示され続けるようになり、Memory 設定はレベル未選択の場合にデフォルトの Off が適用されます。タスクの大きさに応じて単発のチャットと多段のワークフローを使い分けたい方が、その判断を Kiro に任せる度合いを自分で決められます。 Kiro IDE 1.4.10 : Memory 設定のデフォルトが Off に、ワークフロープランへのフィードバック、Powers の耐障害性向上 Kiro IDE 1.4.10 では、Kiro Agent: Memory 設定のデフォルトが Off に変わりました。Use and learn、Use but don’t learn、Use only のいずれかを選ぶとメモリの使い方を設定でき、すでに選んでいる場合はその選択が維持されます。ワークフローでは、提案されたプランに変更を求めると、承認後のステップが利用者の修正に沿うようになりました。Powers は、MCP サーバーへの接続に失敗してもそのサーバーなしでターンが実行されます。画像の多い会話が拒否されたりコンパクションに失敗したりする問題に対しては、古い画像を省いて要約を再試行するようになりました。スクリーンショットを多く貼り付けて作業するセッションが途中で止まっていた方には、安定性の改善につながります。 Kiro IDE 1.4.0 : チャットセッションをまたぐ Memory Kiro IDE 1.4.0 で Memory が導入されました。リポジトリの規約、修正指示、すでに却下したアプローチといった有用なコンテキストを、セッションをまたいで引き継げます。アクティビティバーの Memories アイコンから Memory ビューを開き、Kiro が記憶している内容を確認でき、メモリへのアクセスや変更はチャットに表示されます。Kiro Agent: Memory 設定では、メモリを変更せずに使うだけの Use only も選べます。Markdown Review の検索改善と、Ubuntu 24.04 以降で .deb パッケージからインストールした Kiro が起動しない問題の修正も含まれます。何を覚えさせるかを自分で管理したい方は、Use only から安全に試し始められます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近ハーブを育てるのにハマってます。

■ 目次 はじめに 社内ドキュメント検索MCPとは MCP は「AI が外部データ/サービスを使うための共通ルール」 中身は、社内ドキュメントを索引にした RAG 何ができるようになったか 聞くだけで探せる 「探す役」と「読む役」を分担する 検索以外にできること 使い始めるまでの手間を減らす 最初の版でぶつかった 2 つの壁 壁① 中身が古くなる 壁② 登録が続かない 使われ続けるための 3 つの工夫 工夫① 聞いたときが最新 工夫② フォルダに置くだけで検索対象になる 工夫③ 入れたくないものは確実に外せる おわりに はじめに 「あの手順、どこに書いてあったっけ」「この仕様が決まった経緯は、どの議事録だったか」。 こうした資料探しに時間を取られた経験は、多くの方にあるのではないでしょうか？ 自分の所属するチームでも、資料は GitHub の wiki・issue・プルリクエスト（PR）・リポジトリ内のドキュメント、そして Google Drive に散らばっていました。 どこを探せばよいかを知っている人に聞くか、心当たりの場所を順番に開いていくしかありません。 そこで、AIアシスタントに「社内の資料で〇〇を探して」と頼めば見つけてくれる仕組みを、MCP サーバーとして作りました。 作ってみて分かったのは、 検索の仕組みは作るより、中身を最新に保つ方がずっと難しい ということです。 本記事では、この仕組みで何ができるようになったかと、使われ続けるものにするために工夫したことを紹介します。 なお、前回の記事「 「動いた」で終わらせないAI機能開発 ── 検証から本番運用までの4ステップ 」では、AI 機能をどう作るかという進め方をまとめました。 今回は、チームで AI を活用するための「仕組みづくり」の話です。 社内ドキュメント検索MCPとは MCP は「AI が外部データ/サービスを使うための共通ルール」 MCP（Model Context Protocol）は、AIアシスタントと外部のデータやサービスをつなぐための共通ルールです。 ルールに合わせて構築しておけば、さまざまな AIアシスタントから呼び出せます。 MCP でつながった AI は、用意された「ツール」（AI が呼び出せる機能）を、会話の流れに応じて自分で選んで使います。今回のように「資料を検索する」というツールを用意しておけば、利用者が「〇〇の資料を探して」と頼んだときに、AI が自分の判断でそのツールを呼び出します。(検索の際のクエリもAIが自分で考えます！) 中身は、社内ドキュメントを索引にした RAG 今回作った仕組みは、実質的には社内ドキュメントを対象にした RAG（Retrieval-Augmented Generation）です。 RAG とは、AI が答える前に関係しそうな資料を探し、それを読ませたうえで答えさせる仕組みのことです。 あらかじめ社内の文書を細かく区切って「意味で検索できる索引（インデックス）」を作っておき、知りたいことに意味が近い箇所を探します。 見つかった箇所を含む文書を AI に渡すことで、AI は社内の資料に基づいて答えられるようになります。 何ができるようになったか 聞くだけで探せる これまでは、資料を探すときに wiki の検索、Drive の検索、issue の一覧を行き来する必要がありました。 いまは AIアシスタントに次のように頼むだけです。 wikiで社内ポータルのリリース手順を調べられますか？ AI が検索ツールを呼び出し、該当する資料を見つけて要約し、元の資料へのリンクを添えて返してくれます。 現在は wiki・issue・PR・リポジトリ内のドキュメント・Google Drive の資料を合わせて、約 3,800 件の文書を検索の対象にしています。 「探す役」と「読む役」を分担する この MCP がいちばん得意なのは、たくさんの資料の中から「どれが該当するか」を見つけることです。 見つけた資料の全文を返すこともできるので、それだけで内容を把握できる場面も少なくありません。 実際に使ってみると、AI は検索で資料を特定したあと、GitHub や Google Drive が提供している MCP で元の資料（正本）を開いて確かめる、という使い方を自然にしていました。 そこで、この流れを前提にした分担にしました。 正本を読むと、索引だけでは分からないことまで把握できます。 最新の状態 : Google Drive で編集中の資料は、編集が落ち着くまで取り込みを待ちます（後述）。直前の編集内容は正本にしかありません。 索引に入れていない情報 : issue なら親子関係や、その issue を閉じた PR。PR なら実際のコードの変更点や自動テストの結果、レビューでの指摘が解決済みかどうか。Google ドキュメントやスライドなら、資料に付いたコメント。こうした情報は GitHub や Google Drive の MCP から取得できます。 返信や編集に進むとき : issue にコメントを返す、資料を直すといった作業は正本でしか行えません。 全文を渡さずに正本を読んでもらう方式には、もう 1 つ利点があります。AIアシスタントが一度に読む量を抑えられることです。 索引している資料は 1,600 字ほどのものが中心ですが、Google Drive の資料には数十万字を超えるものもあります。 検索結果の上位 5 件の全文をそのまま渡すと、関係の薄い資料まで大量に読ませることになります。 そこで、まずは該当箇所だけの軽い一覧で候補を挙げ、本当に必要な 1〜2 件だけを正本で読む、という二段構えにしています。 図書館にたとえると、この MCP は「あらすじ付きの蔵書目録」です。 目録で本を探し、たいていはあらすじで用は足りますが、最新の書き込みや付箋まで確かめたいときは、書架から本そのものを取ってくる、という分担です。 GitHub や Google Drive の MCP はすでに提供されているので、自分で作成する必要はありませんでした。 検索以外にできること 検索のほかにも、日々の仕事で使いやすいツールを持たせています。 依頼の例 できること 「自分の担当 issue を一覧して」 担当者ごとの issue を一覧する 「〇〇機能の開発はどこまで進んでいる？」 PR の本文やレビューでのやり取りまで含めて探し、状況をまとめる 「最近 Drive に追加された資料は取り込まれた？」 新しい資料の取り込み状況と、その理由を確認する 「このリポジトリの wiki も検索対象に追加して」 検索の対象を会話の中で追加・削除する PR まで検索できるようにしたのは、思った以上に役立ちました。 よく使っているのは、開発の進捗の確認と、チームの成果の振り返りです。 「〇〇機能の開発はどこまで進んでいる？」と聞けば、関連する PR の状態やレビューでのやり取りから、いまどの段階にあるかをまとめてくれます。 「今月チームで取り組んだことをまとめて」と頼めば、その月の PR をもとに成果の一覧を作ってくれます。 PR には「何を・なぜ変えたか」が書かれ、レビューでのやり取りも残っているので、そのまま作業の記録として使えます。 使い始めるまでの手間を減らす どれだけ便利でも、使い始めるまでの準備が面倒だと広まりません。 そこで、接続の設定と「AI 向けの使い方の手引き」を 1 つのパッケージにまとめ、インストールするだけで使えるようにしました。 手引きには、「資料を探すときは検索ツールを使う」「添付や書きかけの内容まで確かめるなら GitHub や Drive の MCP で正本を読む」といった判断の流れを書いています。 そのため利用者は特別なコマンドを覚える必要がなく、AIアシスタントに「社内の資料で〇〇を探して」と普段どおりに頼むだけで済みます。 最初の版でぶつかった 2 つの壁 最初に作った版は、検索そのものは問題なく動きました。 ところが使い続けるうちに、2 つの壁が見えてきました。 壁① 中身が古くなる 最初の版では、索引の更新を「決まった時刻の定期実行」と「必要なときの手動実行」に頼っていました。 これでは、新しく書かれた資料が索引に入るまでに時間差が生まれます。 たとえば、索引の更新を毎朝 5 時に設定していたとします。 その日の朝会で議事録を書いても、索引に入るのは翌朝 5 時です。 午後に「今朝の朝会で決まったことは？」と聞いても、その議事録は見つかりません。 古い答えが一度返ってくると、利用者は「この検索は当てにならない」と感じて使わなくなります。 検索の仕組みにとって、中身の古さは致命的です。 壁② 登録が続かない もう 1 つの壁は、検索の対象を増やす手間です。 最初の版では、検索させたい資料の URL を 1 件ずつ登録する必要がありました。 資料は毎日のように増えていきます。 利用者に「資料を作ったら登録してください」とお願いしても、続けてもらうのは難しいでしょう。 MCPの管理者が登録し続けるのも現実的ではありません。 登録が追いつかなければ、結局「探しても出てこない」状態に戻ってしまいます。 使われ続けるための 3 つの工夫 2 つの壁を越えるために、仕組みを作り直しました。 壁①には工夫①で、壁②には工夫②と③で答えています。 工夫① 聞いたときが最新 定期実行をやめ、 利用者が検索するたびに、その場で更新を確かめる ようにしました。 先ほどの例でいえば、午後に質問した時点で今朝の議事録が取り込まれ、検索結果に出てきます。 とはいえ、検索のたびにすべての資料を読み直していては時間がかかりすぎます。 そこで、資料ごとに「内容が変わったかどうか」を見分けるための目印を記録しておき、目印が変わったものだけを読み直しています。 目印には、資料の内容から計算される短い文字列（ハッシュ）や、最終更新日時など、資料の置き場所ごとに確かめやすいものを使っています。 Google Drive については、Drive が持っている変更の履歴をまとめて確認し、変わった資料だけを拾っています。 利用者を待たせないための線引きもしています。 同じ対象を直前 60 秒以内に確かめていれば、確認を省きます。 GitHub と Google Drive は、並列で更新確認します。それぞれ 40 秒を上限に打ち切り、間に合わなかったときは今ある索引で答えます。続きは次の検索で取り込みます。 Google Drive で編集中の資料は、編集が落ち着いてから（最後の更新から 30 分後に）取り込みます。書きかけの内容で何度も取り込み直すのを避けるためです。 実は、2 つ目の線引きは運用中に見直したものです。 当初は GitHub と Google Drive を順番に確認し、全体で 20 秒を上限にしていました。並び順は GitHub が先です。 GitHub はリポジトリごとに wiki・issue・PR などを確かめるため対象が多く、それだけで 20 秒を使い切ることがありました。 すると、後ろに並んだ Google Drive の確認がいつまでも始まりません。 実際に丸 1 日以上、検索は何度も行われていたのに Drive の確認は一度も行われず、「今朝の朝会の議事録が見つからない」状態も発生していました。 そこで、GitHub と Google Drive の確認を別々に分けて同時に進め、時間の上限もそれぞれに持たせるように改めました。 検索の待ち時間は最長で 40 秒ほどに延びますが、直前 60 秒以内に確認した対象は省くので、多くの検索では待ち時間は変わりません。 「検索のたびに確かめる」仕組みにしても、確認が後回しにされ続ける対象があれば、そこは古いままになります。最新に保つには、更新のきっかけだけでなく、確認が全体に行き渡るかどうかまで気を配る必要がありました。 この方式には、誰も検索しない間は更新も止まるという弱点があります。 ただ、誰も検索しない間は、誰も最新の索引を必要としていません。 必要になったその瞬間に最新にできるので、実用上は困らないと考えています。 たとえば Google Drive で 1 日に追加・編集される資料は、普段は 10 件前後です。1 日に数回でも検索があれば、その日の更新はすべて取り込めます。 工夫② フォルダに置くだけで検索対象になる Google Drive については、ファイルを 1 件ずつ登録する代わりに、 フォルダごと登録できる ようにしました。 登録したフォルダの中に新しい資料が置かれると、それが取り込みの候補になります。 ただし、フォルダの中には検索の対象にしなくてよいものも混ざります。 そこで、候補の資料を取り込むかどうかを AI が審査するようにしました。 審査の基準は「迷ったら取り込む」です。 取り込まないのは、2 年以上前の議事録のような古い記録や、そもそも文書ではないファイルなどに限っています。 探したい資料が見つからないことの方が、余計な資料が混ざることより困るからです。 AI の判断とその理由は、あとから人が確認できます。 判断が間違っていれば、「この資料はやはり取り込んで」と頼むだけで覆せます。 この仕組みで、資料を作った人も、MCPの管理者も、資料の新規登録のことを意識する必要がなくなりました。 工夫③ 入れたくないものは確実に外せる 自動で取り込むようになると、今度は「これは検索に出したくない」という資料の扱いが問題になります。 検索の対象から一度外しても、その資料が後で編集されると、再び取り込みの候補に戻ってしまいます。 そこで、「この資料（このフォルダ、この名前のもの）は取り込まない」と宣言できる除外リストを用意しました。 除外リストに入れた資料は、どの段階でも取り込まれません。 工夫②で「迷ったら取り込む」という方針にできたのは、この除外リストがあるからです。 入れたくないものを確実に外せるので、それ以外は積極的に取り込めます。 おわりに 社内ドキュメント検索 MCP を作り、使われ続けるものにするまでの工夫を紹介しました。 振り返ると、苦労したのは検索の精度よりも、中身を最新に保つことと、検索の対象を増やし続けることでした。 今回の工夫は、MCP に限らず、社内のナレッジ検索や RAG 全般にも当てはまると考えています。 更新は、時刻ではなく利用をきっかけにする。 必要とされたその瞬間に最新にできます。 登録の手間は人に頼らず、仕組みでなくす。 人のがんばりに頼った運用は長く続きません。 自動で入れるなら、確実に外せる手段をセットで用意する。 外せる安心があってこそ、積極的に取り込めます。 検索は作るより、最新に保つ方が難しい。 社内の情報を AI に活用させたいと考えている方の参考になれば幸いです。