こんにちは。 アプリケーションサービス本部、DevOps担当の兼安です。 2026年6月末、AWS CloudFormationとAWS CDKのExpressモードがリリースされました。 aws.amazon.com 本機能は「デプロイ時間を最大4倍短縮する」という触れ込みの新機能です。 本記事ではこの新機能をAWS CDKの方に絞って試してみたので、その検証結果を共有します。 本記事では、AWS CDKをCDK、AWS CloudFormationをCloudFormationと記述します。 AWS CDKのExpressモードとは テンプレート変更は不要と、ロールバック無効の意味 テンプ…

こんにちは。アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト の深井宣之です。 2026 年 4 月 28 日に「公共分野における AI 活用最新アップデート」と題した Webinar を開催しました。本ブログでは開催内容について Blog にまとめたものになります。投影資料もダウンロードすることが可能です。 本セッションでは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 CSM・プロトタイプ・パートナー ソリューション技術本部 本部長の高田 智己が登壇し、生成 AI の最新トレンドとして「チャットボット + RAG」の時代から「Agentic AI」の時代への移行を解説しました。AWS が提供する AI サービスの全体像を紹介したうえで、中央省庁・地方自治体・ヘルスケア・大学など公共分野における生成 AI 活用の最新ユースケースを多数紹介しました。 セッション概要 資料（PDF）の ダウンロードはこちら から可能です。 生成 AI の最新トレンド ― Agentic AI 時代へ 2022 年末に ChatGPT が登場して以降、生成 AI や RAG（検索拡張生成）が注目を集めてきました。しかし 2025 年 3 月頃からは「AI 駆動開発」「MCP（AI と既存システム連携）」「AI エージェント」といったキーワードが中心となり、AI エージェントが気軽に使える状況が整ってきています。 生成 AI はシンプルなコンテンツ生成を行う「アシスタント」から、単一ゴールを自律的に達成する「生成 AI エージェント」、そしてワークフロー全体を完全自動化する「Agentic AI システム」へと進化しています。Amazon 自身も Alexa+ や代理購買サービス「Buy For Me」など、多くのプロダクトで AI エージェントを活用しています。 AWS の提供する生成 AI サービス AWS では 3 層の AI サービスポートフォリオを用意しています。 AI モデルを作りたい方向け : AWS Trainium / Inferentia によるカスタムチップ、Amazon SageMaker HyperPod などのインフラストラクチャ AI エージェントを作りたい方向け : Amazon Bedrock（基盤モデルへの API アクセス）、Amazon Bedrock Agents、Amazon Bedrock AgentCore、Strands Agents などのフレームワーク すぐに使える AI エージェント : Kiro（AI 統合開発環境）、Amazon Quick Suite、AWS Transform、Amazon Connect など Amazon Bedrock Amazon Bedrock は東京リージョンを含む複数のリージョンで一般提供されている、基盤モデルを活用した生成 AI アプリケーションの構築サービスです。Anthropic の Claude シリーズをはじめ幅広いモデルを利用でき、データプライバシーの観点ではお客様のデータが他のお客様のために使用されることはなく、日本国内クロスリージョン推論もサポートされています。 Amazon Bedrock AgentCore AI エージェントの大規模かつ安全なデプロイ・運用を実現するプラットフォームです。認証・認可（Identity）、ツール管理（Gateway）、実行環境（Browser / Code Interpreter）、セッション記憶管理（Memory）、運用監視（Observability）などの機能を提供し、お客様は AI エージェントのコア開発に集中できます。 AI コーディングエージェント AWS が提供する AI コーディングエージェントとして、生成 AI 統合開発環境の Kiro と、Anthropic 社の Claude Code を Amazon Bedrock 上で利用する方法を紹介しました。Kiro では仕様駆動開発によりプロトタイプからプロダクションまでを支援し、レガシーアプリケーション（Delphi/Pascal）の解析とモダン化にも活用できることをデモで示しました。 公共分野における生成 AI 活用の最新ユースケース 本セッションの後半では、公共分野における生成 AI 活用の最新ユースケースとして、以下の事例が紹介されました。 事例 1: デジタル庁 ― ガバメント AI「源内」 デジタル庁では、政府職員の業務効率化のために生成 AI 検証アプリ「源内（ゲンナイ）」を AWS 上に構築しました。GenU（Generative AI Use Cases）をベースに開発されており、機密性 2 情報の利用が可能です。2025 年 5 月にデジタル庁職員向けにリリースされ、2026 年 1 月から一部省庁で試験的利用を開始。2026 年度には全府省庁約 18 万人の政府職員が生成 AI を活用する大規模実証事業が予定されています。 なお、源内のベースとなっている GenU は AWS Japan の有志チームが開発したオープンソースの生成 AI アプリケーションで、チャット・翻訳・文書校正・要約など業務で活用できるユースケースを提供しており、1,000 を超えるお客様での利用実績があります。 事例 2: 国土交通省 ― AI 書類審査ソリューション「RAPID」 2025 年 4 月の改正建築基準法施行により 2 階建て木造住宅等も審査対象に追加され、審査機関の業務負荷が急増しました。国土交通省では、AWS プロトタイプチームが開発したオープンソースの AI 書類審査ソリューション「RAPID（Review & Assessment Powered by Intelligent Documentation）」を活用し、日本建築防災協会が提供する「建築確認申請図書作成支援サービス」を開発。OSS の活用により開発 2 か月でサービスをリリースし、申請補正指示案件の削減による審査業務負荷軽減が期待されています。 事例 3: つくば市 ― 相談業務効率化 つくば市では、ひとり親支援担当部署において相談記録のテキスト量が多く、転出時の要約資料作成に苦労していました。この課題に対し、GenU をベースにしたソリューションをガバメントクラウド上に構築し、生成 AI による相談記録の要約を実現。大量のケース記録から簡潔な要約を自動生成することで、転入先自治体への情報共有やケース会議での検討を効率化しています。 事例 4: 品川区 ― AI エージェントを活用した問合せ対応自動化 品川区では、人口増加に伴う住民ニーズの多様化や全国的な労働力不足、電話対応業務の負荷増大に課題を抱えていました。Amazon Connect と Amazon Bedrock を活用した AI 自動応答システムの実証実験を実施し、FAQ への自動応答、適切な部署へのルーティング、24 時間対応、必要に応じたオペレーターへのエスカレーションを実現。待ち時間短縮と住民満足度向上、職員の業務負荷軽減、持続可能な行政運営の実現を目指しています。 事例 5: 藤田医科大学 ― 退院時サマリー作成補助 藤田医科大学では、医師や医療従事者が業務時間の多くを文書作成に費やしており、退院時サマリー作成には 1 患者あたり 10〜15 分を要していました。Amazon Bedrock を活用したプロトタイピングプログラムにより、電子カルテ記事を元にサマリー生成の精度を 1 か月で検証。医師作成のサマリーに対し 9 割以上で整合性が取れることを確認し、10 分程度の作成作業が数秒で下書き完成に短縮されました。現在は 31 診療科に展開されています。 事例 6: ソフトウェア・サービス ― 電子カルテシステムへの生成 AI 活用 株式会社ソフトウェア・サービスでは、医師の 52.9% が週 60 時間超勤務、看護師の 7 割が時間外勤務という医療現場の深刻な業務負担に着目し、Amazon Bedrock を活用して電子カルテシステムに生成 AI を連携させました。その結果、サマリー作成時間 50% 削減、心理的負担 70% 低下を実現しています。 事例 7: 東北大学 ― 教職員向け生成 AI アプリ 東北大学では、2020 年に DX 推進チームを発足し、全国の大学に先駆けて生成 AI を導入してきました。GenU をカスタマイズし、チャット・文書作成・議事録作成などの AI ユースケースを全教職員向けに提供しています。検討から 1 か月で内製構築しサービスを開始。会議議事録作成時間が 1/4 に短縮され、ランニングコストも従来の 1/3 に抑えられています。 事例 8: 東京科学大学 ― 日本語大規模言語モデル Swallow の開発 東京科学大学（東京医科歯科大学と東京工業大学が 2024 年 10 月に統合）では、年度末までに大規模言語モデルの継続事前学習を完了させる必要があり、大規模並列の学習用計算環境が求められていました。Amazon SageMaker HyperPod を用いて ml.p5.48xlarge / ml.p5en.48xlarge の学習環境を数時間で構築し、FSx for Lustre と S3 を連携。GPT-4o に匹敵する高性能な日本語大規模言語モデル「Swallow」最新版（Llama-3.3-Swallow-70B 等）のリリースに貢献しました。 おわりに AWS では AI モデルを作りたいお客様へのインフラ提供から、AI エージェントを作りたいお客様へのサービス・フレームワーク提供、そしてすぐに AI エージェントを使いたいお客様向けのサービスまで、多くの選択肢を提供しています。デジタル庁の源内をはじめ、国土交通省、つくば市、品川区、藤田医科大学、東北大学、東京科学大学など、公共分野でも幅広く AWS の生成 AI サービスが活用されています。 本セッションでご紹介した AWS のサービスやソリューションにご興味がありましたら、御社担当の Partner Account Manager にお気軽にご連絡ください。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パートナー ソリューション アーキテクト 深井宣之が執筆しました。

開発2部の内原です。 AIエージェントを使って開発していると、同じモデルを使っているはずなのにツールやエージェントによって賢さがまるで違う、という体験をすることがよくあります。モデルそのものは変わらなくても差が出る理由を考えてみます。 その差を生んでいるのが、モデルを取り巻く装備、いわゆるハーネスです。ハーネスという言葉はなんとなく使われがちですが、何を指しているのかは意外とふわっとしています（少なくとも自分の理解は割と曖昧でした）。 この記事では、この言葉を構成要素に分解して、何がエージェントの実力を決めているのかを整理してみます。 エブリーにおけるAIエージェントの活用状況とハーネスの必要性 先日の 村上からの投稿 全社のAIファーストを牽引するエンジニアの役割 でも言及がありましたが、エブリーでは今年から全社的にClaudeの活用を進めてきました。 それ以前からも特に開発部においてはCopilotやCursorなどのAIエージェントが利用されていましたが、当初は主にコーディング用途に使われていました。それが、開発部に閉じない業務改善、業務遂行のためにAIが用いられるようになってくると、エンジニアの役割も単なる実装者から、よりプロダクトや業務の理解を求められるようになり、業務フロー全体を考慮したオーケストレーションを実施する必要がでてきました。 その中で、より自律的なAI活用のためにはハーネスが重要になってくると考えています。AIに対しどのように振る舞うべきかを伝える必要があるためです。 なお、ハーネスの考え方自体はあらゆるAIエージェントに共通しますが、本記事では話を具体的にするため、特に開発で使うコーディングエージェントを念頭に置いて進めます。 モデル単体とハーネスの違い まずLLM単体は何をするものなのかを考えます。LLMは、突き詰めれば入力テキストに対して出力テキストを返すだけの関数であると言えます。それ自体ではファイルを読むことも、コマンドを実行することも、前回の作業を覚えていることすらできません。 一方実用的なAIエージェントは、そのモデルの周りに情報を渡す仕組みや道具、結果を確かめる仕組みを組み合わせ、それらを繰り返し動かしています。この一式をまとめてハーネスと呼びます。本記事では、ハーネスについてモデルを実世界におけるタスクに接続するための装備一式であると定義します。 ハーネスという言葉は、もともとは犬や馬のような対象に取り付けてその力を御し、目的の方向へ引き出すための装具を指します。ソフトウェアにおいても意味合いは同じく、テスト対象を動かすためのテストハーネス（スタブ、ドライバなど）のように、中心にある対象を制御して動かすための周辺の仕組みを指してきました。 AIエージェントのハーネスも同じで、モデルそのものではなく、その力を制御して実世界のタスクに向かわせるための装備だと捉えると分かりやすいです。 ハーネスを構成する4つの要素 ハーネスを、コンテキスト、ツール、権限・実行環境、検証ループの4つの要素に分けて見ていきます。 ただこれらの分類は絶対的なものではなく、目的や環境に応じて変化し得るものではあります。下記では汎用的に有効と思われるアプローチを考えます。 コンテキスト（何を渡すか） モデルに渡す情報の取捨選択です。モデルはコンテキストに入っている情報しか処理できないので、必要な情報をいかに過不足なく届けるかが重要です。 ただし、多ければよいというわけではありません。不要なものも大量に含めてしまうと、肝心の情報が埋もれて精度が落ちることになります。 関連するファイルやドキュメントのパスを渡す 長い履歴は要約して圧縮する 過去の経緯はメモリとして持たせ、必要なときに参照させる 過去の経緯を覚えておくメモリも、結局はその時々でモデルに渡すコンテキストの一部です。何を入れ、何を入れないかを設計することがコンテキストという要素の肝になります。 ツール（何ができるか） ファイルの読み書き、コマンド実行、検索、外部APIの呼び出しなど、モデルが現実の世界に働きかけるための道具です。 ツールがあって初めて、テキストを生成するだけのモデルが実際にコードを書き換えたり、テストを実行したりできるようになります。このとき、ツールの粒度や説明をモデルが正しく選択できる状態になっているかによって精度は大きく変動します。利用方法や目的が曖昧なツールだと、モデルに誤った使い方をされやすくなります。 権限・実行環境（どこまで許すか） ツールを与えるということは、モデルに実環境を触らせるということです。そのため、どこまでを自動で許すかの設計が必要になります。 サンドボックスで隔離する、権限モードによって実行範囲を絞る、破壊的な操作の前には確認を挟む、といった仕組みがこれに該当します。自動的に実行される範囲を広げるほど待機時間は減りますが、想定していない現象が発生したときの被害も大きくなります。 速さと安全のトレードオフの設計が重要です。 検証ループ（どう確かめるか） モデルの出力が正しいかどうかを、機械的なフィードバックとしてモデルに戻す仕組みです。テスト結果、型チェック、lint、実際に動かしたときの出力検証などがこれに該当します。 結果の検証が可能かどうかで成果は大きく変化します。検証ループの速さと確かさは、エージェントの賢さの大きな要因です。 4つの要素を動かすもの 4つの要素はいわば部品なので、これらを組み合わせて実際に仕事をさせるには、部品を方向づけ繰り返し動かす仕組みが必要です。 システムプロンプト モデルに対し、どのような役割、どのような方針で動いてほしいかを伝える指示です。 役割やルール、守ってほしい制約をあらかじめ与えるこの指示もハーネスの一部と考えることができます。ここではその場限りの指示を毎回書くのではなく、ハーネスの一部として作り込んでおく対象に変わったと言えます。 エージェントループ 部品をつなぎ、実際にタスクを前に進めるのがエージェントループです。考える→ツールを使う→結果を観測→考える、という繰り返しの制御フローを指します。 このループによって一度の応答で終わらず、失敗を踏まえて何度もやり直しながらゴールに近づくことができます。同時に、いつ止めるか、何回までやり直すかといった歯止めの設計も重要です。終了条件がなければエージェントは延々と動き続けてしまいます。 全体像と具体例 ここまでの要素を図にすると、おおよそ次のような関係になります。 Claude Code でいうと もう少し具体的に、コーディングエージェントのClaude Codeに当てはめてみます。 一般的なAIエージェントは自前でハーネスを構築していることが多いため、ユーザーが用意するファイル群はハーネスの一部にすぎず、ツールやループといった土台はClaude Code本体が提供しているという点に注意が必要です。 ユーザーが用意する層 コンテキスト CLAUDE.md、メモリ、作業中に渡すファイル システムプロンプト CLAUDE.md やスキルで与える役割・方針 権限・実行環境 settings.json でのツール許可やサンドボックスの設定 Claude Code本体が提供する層 ツール ファイルの読み書き、検索、コマンド実行、MCPなど 検証ループ hooks やテスト実行の仕組み エージェントループ 考える→ツール→観測→また考える、を回す中核 ただしこの線引きは必ずしも固定されていません。本体が提供する層であっても、検証ループは hooks やテスト実行の指示で何をいつ確かめるかを、エージェントループは進め方の指示で振る舞いを、ユーザー側からある程度調整することができます。 たとえばCLAUDE.mdには、方針（システムプロンプト）や参照（コンテキスト）に加えて、検証や進め方の指示も書けます。1つのファイルが複数の要素に対応していることになります。 # CLAUDE.md ## 方針（システムプロンプト） - コミットメッセージは英語、conventional commits 形式で書く - 既存コードのスタイルに合わせる ## 進め方（エージェントループ） - 大きな変更は、まず計画を示してから実装する ## 検証（検証ループ） - 変更後は npm test と npm run lint を必ず通す - テストが落ちたら、修正してから完了とする ## 参照（コンテキスト） - API仕様は docs/api.md を参照する 権限・実行環境のほうは .claude/settings.json などで設定します。 { " permissions ": { " allow ": [ " Read ", " Edit ", " Bash(npm test) " ] , " deny ": [ " Bash(rm:*) " ] } } これらはいずれもハーネスの一部です。ツールやループといった土台はClaude Code本体が担っており、両者を合わせて初めて一つのハーネスとして機能することになります。 AI-DLC との関係 最近では、AWSが提唱するAI-DLC(AI-Driven Development Life Cycle)のように、AIを中心に据えた開発方法論も出てきています。AgileやScrumに代わる開発プロセスそのものを再設計しようとするものです。 ポイントとしては、こうした方法論はハーネスの上に乗る上位のレイヤーであるということです。AI-DLCが掲げるAIが計画して人間が承認し実装に進むという流れも、成果物を蓄積して引き継ぐ仕組みも、各作業単位で良いハーネスが組まれていることが前提になっています。 このような方法論を導入してもうまくいかないとしたら、その下のハーネスが整っていない可能性があります。 まとめ AIエージェントの賢さとは、モデルとしての性能が全てではなく、コンテキスト、ツール、権限・実行環境、検証ループといった環境に左右されます。 AIエージェントを使いこなすうえでは、ハーネスの設計がエンジニアに求められる重要なタスクになると考えています。