Amazon Web Services ブログ

Kiro University Challenge に参加する ― 1 週間のレッスンと最終課題で最大 5,250 クレジット

稲田大陸 — Mon, 21 Sep 2026 21:20:36 +0000

Kiro の使い方を 1 週間で一気に学ぶオンラインチャレンジ「Kiro University Challenge」が開催されています。毎日公開されるレッスンで Kiro の機能を学び、学んだ内容を盛り込んだプロジェクトを最終課題として提出すると、Kiro のクレジットを獲得できます。最大 5,250 クレジットです。

参加費は無料で、Kiro の無料プランでも 7 つの必須レッスンすべてに取り組めます。学生限定でも AWS 契約者限定でもなく、誰でも参加できます。日本からの参加も対象です。

スケジュール

チャレンジ期間は 2026 年 9 月 21 日 9:00 PT から 10 月 5 日 23:59 PT まで。原文の時刻はすべて太平洋時間 (PT) 表記なので、日本時間 (JST) を併記します。

日付 (PT)	公開されるもの	日本時間
9/21 (月)	レッスン 1〜2	9 月 22 日 (火) 0:00
9/22 (火)	レッスン 3〜4	9 月 22 日 (火) 16:00
9/23 (水)	レッスン 5〜6	9 月 23 日 (水) 16:00
9/24 (木)	レッスン 7 + ボーナスレッスン 2 本	9 月 24 日 (木) 16:00
9/25 (金)	最終課題の受付開始	9 月 25 日 (金) 16:00
10/5 (月) 23:59	最終課題の提出期限	10 月 6 日 (火) 15:59

レッスンは全部で 7 本、これに任意のボーナスレッスンが 2 本加わります。レッスン自体は提出も採点もされません。採点対象は最終課題 1 本だけで、その 1 本が 7 つのレッスンすべての観点で評価されます。

レッスンの一部は特定の Kiro サーフェスに固有の内容です。たとえばレッスン 4 は Kiro IDE 限定です。IDE、CLI、Kiro Web のうち 1 つしか使ったことがない方は、これを機に別のサーフェスを試してみてください。

クレジットの配点

クレジットは、最終課題の中で実際に使って見せられたレッスンの数に応じて決まります。

マイルストーン	クレジット
レッスン 1〜3	各 250 クレジット、最大 750
レッスン 4〜5	各 500 クレジット、最大 1,000
レッスン 6〜7	各 1,000 クレジット、最大 2,000
必須レッスン 7 本すべてを最終課題に含める	1,000 クレジットの完走ボーナス
ボーナスレッスン 1 (有料プラン限定)	250 クレジット追加
ボーナスレッスン 2	250 クレジット追加
最大合計	5,250 クレジット

7 本の必須レッスンは、いずれも無料プランで利用できる機能を扱います。ボーナスレッスン 2 本のうち 1 本は有料プラン限定、もう 1 本はすべての Kiro ユーザーが対象です。ボーナスレッスンは 1,000 クレジットの完走ボーナスの条件には含まれません。

獲得したクレジットは、賞の配布後から 2026 年 11 月 30 日 23:59 PT まで引き換えでき、引き換え後は使い切るか 2027 年 3 月 31 日 23:59 PT に失効するまでアカウントに残ります。クレジットは譲渡や現金への交換はできません。

参加条件

18 歳以上
Kiro アカウントを持っていること
X または LinkedIn のアカウントを持っていること
参加に使う GitHub アカウントが作成から 3 か月以上経過していること
1 人 1 エントリー、個人での参加 (チーム参加は不可)

アルゼンチン、オーストラリア、ブラジル、香港、インドネシア、イタリア、マレーシア、フィリピン、タイ、ベトナム、シンガポール、ロシア、キューバ、イラン、北朝鮮、シリア、ベラルーシ、クリミア地域、いわゆるドネツク人民共和国地域 (DNR)、いわゆるルガンスク人民共和国地域 (LNR)、アラブ首長国連邦に居住する方は対象外です。日本はこのリストに含まれていないため、日本在住の方は参加できます。

AWS の従業員とその同居家族・世帯構成員は参加対象外です。

提出物の要件

最終課題は「動くもの」を 1 本提出します。静的なモックアップは対象外です。提出には次のすべてが必要です。

自分が所有する公開 GitHub リポジトリにコードをプッシュする
リポジトリに .kiro フォルダーを含め、各レッスンの機能をどう設定したかがわかる状態にする
30 秒〜3 分のデモ動画を撮る (3 分を超えた部分は審査されません)
X または LinkedIn に公開投稿し、#KiroUniversity と #BuildWithKiro を付け、X では @kirodotdev、LinkedIn では @kiro をタグ付けする。投稿には公開リポジトリのリンク、2〜3 文の説明、デモ動画を含める
チャレンジのページのエントリーフォームから、リポジトリのリンク、デモ動画、SNS 投稿のリンク、各レッスンをどう取り込んだかの説明を提出する

エントリーフォームのメールアドレスは、クレジットの受け取り連絡先になります。ここを間違えると受け取れません。

失格になりやすいポイント

規約の中で、後から取り返しがつかないものを挙げておきます。

リポジトリの最初のコミットが 9 月 21 日 9:00 PT (日本時間 9 月 22 日 1:00) 以降であること。 チャレンジ期間の開始前にコミットがあるリポジトリは失格の対象です。手元にある既存プロジェクトの続きでは参加できず、チャレンジ期間中に新しく始めたプロジェクトが必要です
提出締切後、審査が終わるまでコミットしないこと。 10 月 5 日 23:59 PT の締切後は、2026 年 10 月 19 日 23:59 PT の審査完了、または受賞メールの受信のうち早いほうまで、コミットを追加できません
GitHub アカウントと SNS アカウントは 1 対 1 で対応させること。同じ GitHub アカウントを複数人・複数の SNS アカウントで使った提出は失格の対象です
リポジトリが非公開、.kiro フォルダーやレッスンに必要なファイルの欠落、プロジェクトが説明どおりに動かない、SNS 投稿に指定のタグやハッシュタグ・リンクがない、これらはいずれも失格事由です

公開済みのレッスン

レッスンはチャレンジのページ、X の @kirodotdev、LinkedIn の @kiro、そして Kiro Discord サーバーの #kiro-university-challenge チャンネルで公開されます。本記事の公開時点で出ているレッスン 1・2 を紹介します。以降のレッスンは上記のチャンネルで順次公開されます。

レッスン 1: Spec-driven development (250 クレジット)

Feature Specs は、新機能を作るための構造化されたアプローチです。要件の洗い出し、技術設計、実装計画の順に進めていきます。複雑な機能、複数ステップの実装、共同作業のプロジェクト、要件や設計を何度も練り直す必要がある機能に向いています。

WHEN a user submits a form with invalid data
THE SYSTEM SHALL display validation errors next to the relevant fields

この例では、EARS (Easy Approach to Requirements Syntax) 記法を使って、フォームバリデーション機能の要件を構造化されたテスト可能な形で書いています。Kiro にアイデアを渡して spec にしてもらうときは、好みの記法でも、単なる自然言語でもかまいません。詳しくは Specs のドキュメントを参照してください。

レッスン 2: Steering documents (250 クレジット)

~/.kiro/steering/ ディレクトリーに置いた Markdown ファイルを通して、Kiro にプロジェクトの知識を持たせ続けられます。Steering ファイルは Kiro の振る舞いを規定するので、毎回同じ指示を繰り返さなくても、Kiro の出力が自分たちのパターン・ライブラリー・基準に沿ったものになります。

Create a steering file to enforce [insert a convention or standard you want Kiro to enforce], so that [insert context for Kiro to understand your intent behind this prompt]. For example, [insert example of this convention or standard as a code output] ensures [repeat initial convention or standard] is followed.

これは steering ファイルを作るためのテンプレートプロンプトです。1) Kiro に守らせたい基準や規約を定義する、2) なぜそれを守らせたいのかという意図を文脈として伝える、3) コードの例で比較を示して守らせる精度を上げる、というベストプラクティスに沿っています。詳しくは Steering のドキュメントを参照してください。

まずはここから

チャレンジのページで公開済みのレッスンを確認し、Discord の #kiro-university-challenge チャンネルに参加してください。最終課題の提出は 9 月 25 日 16:00 (日本時間) に開始、締切は 10 月 6 日 15:59 (日本時間) です。新しいプロジェクトを 1 つ、Kiro をメインの開発ツールとして作ってください。

Kiro をまだ使っていない方はダウンロードページから始められます。

参加にあたっては購入の必要はありません。法律で禁止されている地域は無効です。参加条件・提出要件・クレジットの扱いの詳細は規約をご確認ください。受賞者リストはチャレンジ終了後最大 1 年間こちらのページで公開されます。

この記事は Kiro の Kiro University Challenge のページを日本語向けに再構成したものです。日程・条件は本記事公開時点の内容です。最新の情報は原文をご確認ください。

Kiro Crew でソフトウェアファクトリーを構築し、1 週間で 1000 件の PR をマージした方法

稲田大陸 — Sat, 19 Sep 2026 11:19:07 +0000

先週、Kiro Crew をフルタイムで開発している私たち3人は、7日間で 1,000 件の pull request をマージしました。1日あたり 120 件を超え、そのすべてが CI とレビューを通っています。Kiro Crew は、このフルタイムのエンジニア3人を中心に、500 人近い熱心なコミュニティコントリビューターとともに開発されています。

この数字を狙っていたわけではありません。並行して開発を進めるやり方が次々に限界にぶつかり、それを越えるたびに少しずつ到達した結果です。ボトルネックにぶつかるたびに、1人がより多くのセッションを回せる新しい進め方が生まれました。振り返ると、その変化は5つの段階に整理できます。最新の段階が、私たちが Crew Mode と呼んでいるものです。コーディングエージェントを使っているなら、あなたもこの梯子のどこかにいます。そして今いる段階が、次に壊れるものを教えてくれます。

図 1: 5つの段階、1人の人間。変わったのはセッション数だけです。

段階 1: 1セッション、手作業。 開発者1人、エージェント1つ、CLI または IDE の中。自分の注意力がシングルスレッドだと気づくまでは、これで足ります。エージェントはすべてのステップの合間にあなたを待つので、あなたがボトルネックです。

段階 2: 複数セッション、手作業。 2つ目のタブを開き、3つ目を開きます。午後いっぱいくらいは助かります。やがて、どのタブでも同じプロジェクトの説明を繰り返し、どのタブが何をしているかを頭の中で管理していることに気づきます。セッションは互いのことを何も知らないので、それらをつなぐのはあなただけです。

段階 3: memory、ダッシュボード、cron、workflow。 Kiro Crew が本格的に始まったのはここです。memory によって、セッションは温まった状態で始まるようになりました。ダッシュボードによって、複数セッションの追跡が容易になりました。cron と monitor ループは、人の手を介さずにセッションを開始し始めました。workflow は、固定のものも動的に生成されるものも、1つのジョブのステップを複数のセッションにまたがってつなぎ、人間が1ステップずつ手でたどらなくてよいようにしました。これで1人が 10〜20 のアクティブなセッションを扱えるようになりましたが、その作業全体を調整するものではありませんでした。workflow のステップは、依然としておおむね順番に実行されます。cron はスケジュールで起きるのであって、別のセッションが終わったときに起きるわけではありません。セッションは別々のタスクやプロジェクトを担当できますが、更新をすべて読んで次に注意を向ける先を選ぶのは、人間のままでした。

段階 4: agent pipeline。 CI のパイプラインではなく、一般的な作業を対象にしたエージェントセッションの組み立てラインです。triage、実装、レビュー、マージがそれぞれ独立したステージとして自分のセッションを持ち、メッセージキューを通してのみ連携します。どのステージも他を待ちません。各ステージは自分のキューに項目が入った瞬間にそれを取り、互いのことを知らないまま、全ステージが同時に動き続けます。対して workflow は、ステップ3がステップ2を待つ鎖です。1人で 20 の同時セッションを超えられたのは、この pipeline のおかげでした。残る課題は、pipeline が人間の設計した固定の形だという点です。結果が計画を無効にしたときに再計画できず、人間が計画を書き直して、影響を受けた作業を振り直す必要があります。

段階 5: セッションをエージェント的に運用する。 ここまでの仕組みで、1人がおよそ 20 の同時セッションを扱えます。50 に近づけると、今度は人間の入力が限界になります。どのセッションにも、ゴールを定義し、起動し、問題を見張り、結果を判断し、次に何をするか決める人が必要です。この5つを 50 セッション分こなすと、それ自体がフルタイムの仕事になります。

図 2: セッション単体は安くなりましたが、その周りの雑務は人間のものでした。Crew Mode がそれを引き受けるまでは。

Crew Mode は、どの単一セッションの外側にも属さないエージェントで、この手作業を自分でこなします。あらかじめ描かれた形をたどるのではなく、セッションの境界をまたいで結果に反応します。セッションは、Crew Mode が作り、初期情報を与え、見張り、閉じる実行単位になります。人間が持つのはゴールです。先週の数字は、pipeline と Crew Mode の初期バージョンが組み合わさって出たものです。開発は今も続いています。

これはどこで動くのか。プロセスが動く場所ならどこでも動きます。crew は1つの gateway とそれが所有するセッションの集まりであり、どのマシンの上にいるかを気にしません。現在、私たちの crew はラップトップ、EC2 インスタンス、クラウド開発デスクトップ上で動いており、今後は Fargate コンテナでも動く予定です。私自身は6〜10 台のマシンを同時に動かし、すべてを1つのダッシュボードから繋いでいます。合わせて 30〜50 のセッションが同時に稼働し、issue の triage、pull request 用のコード作成、レビュー、マージを進めています。crew が受け渡すエージェントジョブは、GitHub Actions や CodeBuild 上でも動きます。

crew 間の協調については早い段階で議論し、「将来の課題」として整理していました。その必要性を具体的にしたのが Crew Mode です。Crew Mode の調整役エージェントは、アクティブなセッションをすべて巡回してブロックされた作業を見つけ、結果を確認し、計画を更新します。50 セッションを超える規模になると、この調整役エージェント自体が次のボトルネックになります。コンテキストを失うこともあり、必要な専門性を持っていないこともあります。スーパーマネージャー1体では、この問題は解けません。役割、スコープ、協調の仕方が異なる複数のエージェントが必要です。1体が計画し、別の1体が実行し、さらに別の1体がレビューする、という形です。そのうえで crew 同士が結果を交換し、作業を互いにルーティングできるようになります。これを設計できたのは、監督役1体がスケールしなくなるのを見たあとでした。

私たちが本当に重視していること

「エージェントがエージェントを運用する」という言い回しは、まさに誇張を招きやすい類のものです。ですから率直に書きます。私たちのゴールは、現場のエンジニアが信頼できる機能を作ることです。現在の開発の大半は、Crew Mode を安全でガバナンス可能にすることに向いています。新しく派手な解決策を発明しようとしているわけではありません。複数のエージェントが自分のために働き始めると、4つのガバナンス上の問題が中心にきます。

エージェント間の調整。 誰が何を依頼し、どのタスクを誰が持ち、何を試して却下したか。これがモデルのコンテキストの中にだけあると、次の compaction で消え、何が起きたのかを誰も再構成できません。明示的で永続的でなければなりません。
memory。 何を覚えてよいか、どのエージェントが、どのプロジェクトについて、誰に見える形で覚えるか。あるエンジニアの訂正が、別のチームのコードベースを扱うセッションを黙って動かしてしまってはいけません。
権限制御。 エージェントが何をしてよいか、どのリポジトリで、どの環境に対して、そして何が人間の承認を要するか。プロンプトで丁寧にお願いするのではなく、ホスト側で強制します。
すべての操作の記録。 コマンド、ファイル変更、承認、拒否のすべてを、エージェントが書き換えられない場所に記録します。信頼は、エージェントが「正しいことをしました」と言うことからは生まれません。履歴を追跡できることから生まれます。

これらは、エージェントが自社を代表してコードを push できるようになったとき、どの会社にも必要になる普通の統制です。エージェントの調整、明確な memory の境界、ホストレベルの権限、そしてエージェントが改変できない監査ログ。セッションを増やすことが効くのは、エンジニアがその作業を理解し、制御し、信頼できるときだけです。

コストは、エージェントの艦隊が数百セッション規模になると、別の問題として立ち上がります。エージェント本体の作業には、すでに値段がついています。調整はその上にもう一層を足します。セッションを温かく保つ、状態を確認する、結果をルーティングする、fan-out を支える、といった処理です。その規模になると、この追加分の請求が採用の障壁になり得ます。私たちは、定常的な監督に安価なモデルを使う、決定的なチェックはスクリプトに任せる、最小コンテキストでの起動、セッション知識の再利用、タスク単位の正確なコスト計上といった方法で、これを下げる道を探っています。

今日から使えること

ここでの学びは、私たちのツールを採用しなくてもすぐ適用できます。今いる段階から始めて、何がもうスケールしていないかを特定してください。次に進む前に、最小で役に立つ改善を1つ入れます。各段階は、次の段階への準備をしながら、それ自体で価値を出します。

同時セッション数を数える。 1つなら段階 1、タブが数枚なら段階 2、というように。この数が、次に解くべき問題を教えてくれます。そしてそれは、いちばん面白そうに聞こえる問題ではまずありません。
段階 1 から 2 は無料。効くのは段階 2 から 3。 タブを増やす前に、エージェントに memory を与えてください。最も安い形は、すべてのセッションが読むリポジトリ内のファイル1枚で、そこに自分の規約と、繰り返し言っている訂正を書いておくことです。どのツールを使っていても、並行セッションを負担から既定の状態に変えるのは、この1手です。
繰り返しの雑務を1つ、スケジュールに渡す。 新しい issue の triage や、不安定なチェックの再実行など、毎日手でやっているジョブを1つ選び、タイマーで始まるセッションに渡します。スケジュール実行されるセッションを1つ動かすほうが、それについてどれだけ読むよりも学べます。
orchestrator の前に pipeline を作る。 セッションが同じ数種類の作業を繰り返しているなら、ステージに名前を付け、その間にキューを置きます。GitHub issue のラベルは、始めるには十分に良いキューです。ラベル1つにセッション種別1つ、各セッションは自分のラベルが付いたものを拾います。
段階 5 から始めない。 5つの務めを書き出し、どれが自分の1日を食べているかを見ます。私たちの場合は、50 を超えるセッション間の巡回でした。最初に自動化すべきはその務めであり、それがどれなのかは、体感できるだけのセッションを動かしてみて初めて分かります。
ガバナンスは初日から始める。規模が出てからではない。 監査ログと権限制御の2つは、今すぐできます。エージェントがやったことを、エージェントが書き換えられない場所に記録し、何をしてよいかをプロンプトではなくホストレベルで決めます。どちらも2セッションのうちは安く、50 セッションになってからの後付けはほぼ不可能です。

私たちが実際に動かしているバージョンを試したい場合、Kiro Crew は memory、ダッシュボード、cron、workflow、pipeline を今日提供しており、基本的な Crew Mode は feature preview を有効にするとリポジトリで利用できます。いちばん速い始め方は、ラップトップにインストールし、リポジトリ1つに向け、スケジュール実行の雑務を1つ渡すことです。自分が寝ている間も動かしたくなったら、クラウドインスタンスへ移します。

この先どこへ向かうか

今は、人間が crew に具体的なゴールを渡します。この機能を出す、このリポジトリを green にする、といったものです。時間が経つにつれ、そのゴールはより抽象的になり、crew は作業を待つのではなく提案するようになるはずです。ただしそれが起きるのは、ガバナンスとコスト制御の機能が整い、十分にテストされたあとです。企業が制御も監査もできず、費用も負えない機能は、プロダクトではなくデモです。

Kiro Crew はオープンソースです。この記事のすべての背後にあるコード、アーキテクチャドキュメント、機能仕様は、公開リポジトリにあります: https://github.com/kirodotdev/KiroCrew。自分でこのようなソフトウェアファクトリーを作りたい方は、kiro.dev/crew で Crew を試してください。

この記事は Kiro ブログの How we built a software factory with Kiro Crew to merge 1000 PRs in a week を翻訳したものです。

月刊 AWS 製造 2026 年 9 月号

大前遼 — Sat, 19 Sep 2026 06:17:23 +0000

みなさん、こんにちは。ソリューションアーキテクトの大前です。9 月に入り一段と涼しくなってきましたが、いかがお過ごしでしょうか。今月は「エージェントに現場を任せるとき、境界線をどこに引くか」をピックアップトピックとしてお届けしつつ、8 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。

ピックアップトピック: エージェントに現場を任せるとき、境界線をどこに引くか

PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあります。今回ご紹介している記事のいくつかでは、同じ問いに別の角度から答えていました。

AI に判断を任せ、実行は別の層で制御する

コニカミノルタ様の「未来の実験室」では、材料開発の実験を「緑色を作ってください」と自然言語で指示できます。ただしモデルは座標や動作列を生成しません。担当は目標色・操作候補・停止条件へ分解した JSON の中間表現までで、座標制御は人が設計した決定論的な制御層が担います。役割を絞ったので、軽量な Claude Haiku 系でも成立します。

SUMCO 様の SynchroFabAI も同じ構図で、AI に任せるのは「異常状態の推測」と「因果関係の推測」までであり、操作は人間が実施します。AWS Summit での Physical AI デモ構築においても、エージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ることで安全性を保ちながらロボットが動くデモを構築しました。これらに共通するのは、AI の判断と現実世界への操作を直結させず、その間に人の確認や決定論的な制御、外部から強制される権限制御を置いている点です。

では、どこまでをAIに任せ、どこからを人や制御層に渡すべきでしょうか。その境界は、モデルの性能だけでは決められません。8 月に公表された Amazon Science の論文で提案されている SOP-Bench では、標準作業手順書（SOP）を AI エージェントに実行させて成功率を測定しています。11 のモデルで試した結果、新しいモデルが必ず高い成功率を示すわけではありませんでした。また、ツール構成を比較した実験では、必要なツールだけを与えた場合に比べ、不要なツールを追加すると成功率がほぼ半減しました。自社の手順と実際のツール構成で性能を測り、安定して実行できる範囲だけをAIに委ねることが、AI と人間の境界を決める現実的な方法です。ただし、境界を決めるだけでは十分ではありません。実運用では、その境界を技術的な制約として強制する必要があります。

決めた境界をインフラ側で強制する

8 月は Amazon Bedrock AgentCore にこの方向の機能が 2 つ加わりました。時間的ポリシーは、それまでの操作履歴を踏まえて各リクエストを評価する認可ルールで、作業順序の強制や特権操作前の人間承認を設定できます。AgentCore Payments では支払い上限をインフラ層で強制できます。

「危険な操作をしないでください」とプロンプトに書くのと、そもそもその操作が許可されない状態を作るのは、まったく別のことです。後者は OT のインターロックに近い考え方です。エージェントを現場に出すために必要なのは、モデルを賢くすることだけでなく、任せない範囲を先に決め、その境界を外部から強制することなのかもしれません。

直近で開催予定のイベント

9/14 – 9/19 IMTS 2026
- 北米最大級の工作機械展示会がシカゴで開催されます。AWS もブースを出展予定で、量子コンピューティングと製造業をテーマにした AWS 主催のレセプションもあります。
10/13 – 10/16 CEATEC 2026
- JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催されます。テーマは「Transformation -企業が、産業が、そして社会が変わる-」です。AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。
10/26 – 10/31 JIMTOF2026
- 世界最大級の工作機械見本市が東京ビッグサイトで開催されます。
11/30 – 12/4 AWS re:Invent 2026
- AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。

製造関連ブログのご紹介

8/3 Engineering Development Hub : A unified workbench to accelerate product development
- 製品開発チームは、分断されたツール・データサイロ・計算リソース制約という課題に日々直面しています。Engineering Development Hub (EDH) は、複雑なシステムの設計・テスト・検証に必要なアプリケーション・計算・データを1つのオープンソース環境に統合した、クラウドベースのエンジニアリングワークベンチです。Amazon Lab126 や Rivian などの顧客が既にEDHを活用しており、NVIDIA Isaac Sim でのフィジカルAI模倣学習や車載インフォテインメント開発などの実例を紹介しています。大規模ハードウェア開発を高速化したい設計・開発部門の方におすすめです。
8/6 Run HPC Simulations faster with Siemens Teamcenter and AWS ParallelCluster
- 「解析の順番待ちで設計が止まる」という課題を、Teamcenter Simulation と AWS ParallelCluster の連携で解いた記事です。設計を選んでジョブを投げれば入力は自動で置かれ、計算ノードは終われば消えます。数日の設計スタディが数時間に。解析のリードタイム短縮を検討している CAE・解析部門の方におすすめです。
8/7 Leading FMEG Player Builds Manufacturing Control Tower on AWS
- 工場ごとにデータが閉じていると、異常に気づくのは手遅れになってからとなります。本記事ではインドの大手電設機器メーカーが約 15 工場を 4 層構成でつなぎ、障害後の意思決定を 24 時間超から 2 時間未満に、拠点追加の工数を 1 工場あたり 20% 未満（従来は 80〜100%）に縮めた事例をご紹介しています。複数拠点の OT データ統合をこれから広げる方におすすめです。
8/18 SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX
- 株式会社 SUMCO 様との共著です。ネットワーク分離と権限分離によるセキュアな AWS 基盤上に、データ分析パイプラインの RedPulse と自然言語でのデータ分析を実現する SynchroFabAI を積み上げた道筋が語られます。セキュリティを担保しつつ、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析などによるデータ分析の力を組織全体に広げていく過程をご覧いただけます。
8/19 Agentic AI でつなぐモノ・サービスの改善サイクル
- リリース後に溜まる運用データが、次の開発に一度も戻ってこない。その原因を「データのサイロ」と「人材のサイロ」に切り分け、Amazon Quick で埋める方法です。AI 自身が仮説を立てて検証まで進みます。製品の改善サイクルを回したい開発・品質部門の方におすすめです。
8/20 Amazon Bedrock とロボティクスで目指す「未来の実験室」
- コニカミノルタ株式会社様との共著です。材料開発の実験を自然言語で指示すると、ロボットアームが実際に手を動かし、結果が電子実験ノートに戻るという閉ループを約 2 か月で実装されています。開発には Kiro CLI を活用されており、生成 AI をチャットの外の実機制御へ広げたい研究開発部門の方におすすめです。
8/21 Accelerating Chip Tape-out with AWS Unified Operations
- 半導体企業がAWS上でEDA（電子設計自動化）ワークロードを実行する際、インフラの可用性・性能がチップ納期に直結します。AWS Unified Operations はAWSの最上位サポート層にあたり、専任チームが、アーキテクチャ支援・迅速なインシデント対応・財務最適化・セキュリティ監視を提供します。本記事では、12 か月のテープアウト工程に沿って Unified Operations がどのように支援を行うのかを紹介します。高可用性が求められる HPC ワークロードを抱える方におすすめです。
8/21 SOP-Bench: A new benchmark for evaluating AI agents on real business procedures
- Amazon Science が発表した、標準作業手順書（SOP）を AI エージェントに実行させる公開ベンチマークです。倉庫点検や危険物分類を含む、12 業務領域・2,000 超のタスクを実際に動くツールと正解付きで用意し、エージェントの。自社の手順を足して評価することもできます。エージェントを本番に載せる前の物差しが欲しい方におすすめです。
8/24 ソフトウェア開発を AI エージェントで加速する ── TOPPAN が体験した SDLC 主要フェーズの手応え
- TOPPAN 株式会社様との共著です。20 名が Kiro CLI を活用し、SDLC の Research・Plan・Release をAI と協調しながら回す体験を行いました。レガシーコードから設計書を復元する手応えや、AWS MCP Server を頼りに CI/CD を組む感触が率直に語られます。AI を活用した開発の効率化に興味のある方におすすめです。
9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで
- 6 月の Summit で展示した「AI エージェントが街の障害物を自律的に見つけて片付ける」デモを、どう作ったかの記録です。10 名全員が兼務で、実機を使った統合に充てられたのは本番前の約 1 か月という過酷な条件の中で、企画の可視化から 3D モデリング、実装、説明員資料などの全工程を生成 AI と伴走する過程を紹介しています。AI を使った開発プロセスの型づくりに関心のある方は、ここから読むと全体像がつかめます。
9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編
- 上記デモのロボット側です。FANUC 社製協働ロボット 2 台をクラウドの AI エージェントと連携させるデモ開発の裏側をご紹介しております。画像から動作指令までを 1 つのモデルで出す方式を採らなかった理由、コーディングエージェントの権限を「変更できる／人の承認が要る／エージェントの外で強制される」の 3 つに切った線引き、そして手先の向きを保つ拘束を AI が誤って無効化した経験から「禁止と代替手順はセットで書く」に至った経緯まで、任せる範囲の決め方が具体的に語られます。今号のピックアップトピックの実例編として、あわせてお読みください。

製造関連の主要なサービスアップデート

8/3 Amazon SageMaker AI がフルファインチューニングに対応
- 25 以上のオープンソースモデルで全パラメーターを更新できます。設備の型式ごとの符牒や検査基準といった組織固有の語彙を、モデルに深く覚え込ませたいときにご利用いただけます。
8/4 AWS Security Hub Extended がソフトウェアサプライチェーンのセキュリティに対応
- 外部から取り込むオープンソース部品に悪意あるコードが混ざっていないかを、アプリに組み込む前に検出・遮断できます。
8/6 AgentCore に時系列ポリシーとレート制限を追加
- ピックアップトピックでご紹介した機能です。宛先ごとのリクエスト数・トークン数の上限も併せて設定できます。
8/7 AWS Parallel Computing Service が FedRAMP・SOC・ISO・PCI の対象に
- マネージド HPC サービスである、Parallel Computing Service がSOC、ISO などの主要な第三者認証の対象になりました。統制・監査要件が壁になっていた技術計算部門の導入判断を後押しします。
8/11 AWS Glue から SageMaker Unified Studio へワンクリックでアクセス
- AWS Glue と同じ権限のままクエリ・品質チェック・パイプライン構築へ移れます。データカタログの整備から分析・AI 活用までを、ツールを行き来せずに進められます。
8/18 AgentCore payments が一般提供開始
- エージェントが有料の API を自ら見つけて使い、決済まで行えます。支払い上限はインフラ側で強制されるので、外部データを都度買う調達系エージェントも統制下で運用できます。
8/19 Amazon SageMaker のノートブックが Trusted Identity Propagation に対応
- 共有ロールではなく利用者本人の ID でデータ参照を制御でき、誰が何を見たかが AWS CloudTrail に残ります。品質データや設計情報の閲覧範囲を部門・拠点で分けたい分析基盤にご利用いただけます。

最後まで読んでいただきありがとうございました。

今月は、AI に任せる範囲の決め方と、その境界を仕組みで守る方法をご紹介しました。来月も、製造業における AI 活用のヒントをお届けします。それでは、また来月お会いしましょう！

著者について

RDS for SQL Server インスタンスを License Included から Bring Your Own Media (BYOM) へ変換

Yoshinori Sawada — Fri, 18 Sep 2026 03:00:53 +0000

本記事は 2026 年 6 月 16 日に公開された “Converting an RDS for SQL Server instance from license included to Bring Your Own Media (BYOM)” を翻訳したものです。

Amazon Relational Database Service (Amazon RDS) for SQL Server は最近 Bring Your Own Media (BYOM) をリリースしました。これにより、既存の SQL Server ライセンスをフルマネージドの RDS インスタンスで使用できるようになりました (詳細は「フルマネージドの Amazon RDS for SQL Server で Bring Your Own Media によるライセンスモビリティの実現」を参照)。これは、既存の Microsoft ライセンス契約をお持ちで、その投資を AWS 上で活用してクラウド支出を最適化したいお客様にとって特に価値があります。

すでに License Included (LI) モデルで RDS for SQL Server を実行している場合、データベース移行なしでそれらのインスタンスをインプレースで BYOM に変換できるようになりました。この機能により、RDS for SQL Server インスタンスを AWS 提供のライセンスから独自の SQL Server メディアの使用に移行しつつ、フルマネージドの RDS インフラストラクチャの利点を維持できます。BYOM を使用するには、License Mobility 付きの SQL Server Enterprise Edition または Standard Edition が必要です。ライセンスモビリティの詳細については、ライセンスモビリティのページを参照してください。

セットアッププロセスを簡素化するため、BYOM エンジンバージョンのエクスペリエンスも効率化しました。SQL Server のインストールメディアを Amazon Simple Storage Service (Amazon S3) にアップロードし、BYOM エンジンバージョンとして登録します。Amazon RDS はマイナーバージョンアップグレードが利用可能になると自動的に新しい BYOM エンジンバージョンを作成するため、常に最新の状態を維持できます。アップグレードを選択した際、追加の手動手順なしで新しいバージョンが準備されています。

本記事では、インストールメディアの準備、BYOM エンジンバージョンの作成、インプレースでのライセンスモデル変更という、エンドツーエンドの変換プロセスを説明します。

ソーシューション概要

既存の License Included の RDS for SQL Server インスタンスを BYOM に変換するには、以下の手順に従います:

SQL Server のインストールファイルを準備し、Amazon S3 にアップロードする。
Amazon RDS が特定のデータベースエンジン構成を構築するために使用する BYOM エンジンバージョンを作成する。
既存の License Included インスタンスを BYOM ライセンスモデルと BYOM エンジンバージョンを使用するように変更する。

前提条件

開始する前に、以下の前提条件を満たしていることを確認してください:

AWS Identity and Access Management (IAM) プリンシパル (ロールまたはユーザー) に、AmazonRDSFullAccess (RDS オペレーション用の AWS マネージドポリシー) と、Amazon S3 で SQL Server インストールファイルの作成、アップロード、アクセスを行うための s3:GetObject、s3:CreateBucket、s3:PutObject 権限があること。
インストールファイルを保存するための S3 バケット。すべてのインストールファイルは、RDS インスタンスと同じ AWS リージョンの同じ S3 バケットに保存する必要があります。
変換対象の License Included モデルの既存 RDS for SQL Server インスタンス。
既存インスタンスのエンジンバージョンと一致する SQL Server インストールメディア (ISO ファイル)。

開始前の重要な考慮事項

BYOM から License Included への変換はサポートされていません。この変更は元に戻せないため、変換は慎重に計画してください。
BYOM エンジンバージョンはリージョンや AWS アカウント間で共有できません。ただし、インストールメディアは共有できます。BYOM を使用したいリージョンと AWS アカウントごとに BYOM エンジンバージョンを作成する必要があります。
BYOM は SQL Server 2019 および 2022 の Enterprise Edition と Standard Edition でサポートされています。
SQL Server Reporting Service (SSRS) または SQL Server Analysis Service (SSAS) を含むオプショングループは BYOM ではサポートされていません。
インスタンスが Multi-AZ に設定されている場合、変換はプライマリとスタンバイの両方のインスタンスに適用されます。
変換中、インスタンスは modifying 状態になります。Multi-AZ インスタンスの場合、ローリングインプレース変換が実行され、まずスタンバイが変更され、その後フェイルオーバーが発生し (通常 30〜60 秒のフェイルオーバー時間)、旧プライマリが更新されます。Single-AZ インスタンスの場合、変換中にインスタンスがシャットダウンし、変換完了時に再起動します。本番ワークロードではメンテナンスウィンドウ中に変換をスケジュールしてください。
インスタンスにリードレプリカがある場合、変換前に削除し、変換後に再作成してください。新しいレプリカは自動的に BYOM ライセンスモデルを継承します。
変換後、AWS を通じた SQL Server ライセンスの課金は停止します。Microsoft のライセンス契約への準拠を確認する責任はお客様にあります。
クロスリージョンリードレプリカを作成するには、先にターゲットリージョンで BYOM エンジンバージョンを作成する必要があります。
License Included から BYOM への変換の一部としてマイナーバージョンをアップグレードしたい場合、まずターゲットの上位マイナーバージョン用の BYOM エンジンバージョンを作成する必要があります。

ステップ 1: インストールファイルの準備とアップロード

開始するには、既存の RDS インスタンスで実行されているエンジンバージョンと一致する SQL Server インストールメディアファイルが必要です。これは Microsoft Volume Licensing Service Center (VLSC) または Visual Studio サブスクリプションから取得できます。

現在のエンジンバージョンの確認

まず、既存の License Included インスタンスのエンジンバージョンを確認します:

aws rds describe-db-instances \
  --db-instance-identifier my-li-instance \
  --query "DBInstances[0].{EngineVersion:EngineVersion,LicenseModel:LicenseModel}" \
  --region <your-region> \
  --output table

出力のサンプル :

S3 バケットを作成してインストールファイルをアップロードする

1.RDS インスタンスと同じリージョンに S3 バケットを作成します:

aws s3 mb s3://amzn-s3-demo-bucket --region <your-region>

2. SQL Server ISO ファイルをアップロードします (以下のメディアファイル名と S3 バケット名はご利用の環境に合わせて置き換えてください):

aws s3 cp \
  SW_DVD9_NTRL_SQL_Svr_Ent_Core_2022_64Bit_English_OEM_VL_X23-28404.ISO \
  s3://amzn-s3-demo-bucket/sqlserver-2022-ee/ \
  --region <your-region>

クロスアカウント設定: 組織内のアカウント間でインストールメディアを共有する

複数の AWS アカウントを管理している場合、SQL Server インストールメディアを中央の S3 バケットに保存し、AWS Organization 内のすべてのアカウントからのアクセスを許可できます。これにより、各アカウントに同じ ISO ファイルを個別にアップロードする必要がなくなります。

中央の S3 バケットに以下のバケットポリシーを追加して、組織内のすべてのアカウントからのアクセスを許可します。Amazon S3 Console を使用したバケットポリシーの追加を参照してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CrossAccountAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::TARGET-ACCOUNT-ID:role/YOUR-IAM-ROLE"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR-BUCKET-NAME",
        "arn:aws:s3:::YOUR-BUCKET-NAME/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxxxx"
        }
      }
    }
  ]
}

プレースホルダーを実際の値に置き換えてください : o-xxxxxxxxxxxx は AWS Organizations ID、TARGET-ACCOUNT-ID はアクセスが必要な AWS アカウント ID、YOUR-IAM-ROLE はインストールメディアへのアクセスに使用する IAM ロール、YOUR-BUCKET-NAME は S3 バケット名です。

各アカウントでは引き続き独自の BYOM エンジンバージョンを作成する必要がありますが (BYOM エンジンバージョンはアカウント間で共有できないため)、中央のバケットからインストールメディアを参照できます。

注意: S3 バケットは、BYOM エンジンバージョンを作成する RDS インスタンスと同じリージョンにある必要があります。

ステップ 2: BYOM エンジンバージョンの作成

Amazon RDS は BYOM エンジンバージョンを使用して、SQL Server インストールファイルを検証し、再利用可能なテンプレートとしてパッケージ化して登録します。BYOM エンジンバージョンは、既存インスタンスと同じエンジンバージョンを使用する必要があります。

AWS CLI を使用して BYOM エンジンバージョンを作成する

以下のコマンドを実行して、アップロードしたメディアファイルを使用して BYOM エンジンバージョンを作成します :

aws rds create-custom-db-engine-version \
  --engine sqlserver-ee \
  --engine-version 16.00.4225.2.v1 \
  --database-installation-files-s3-bucket amzn-s3-demo-bucket \
  --database-installation-files SW_DVD9_NTRL_SQL_Svr_Ent_Core_2022_64Bit_English_OEM_VL_X23-28404.ISO \
  --region <your-region>

以下のスクリーンショットが示すように RDS Console から BYOM エンジンバージョンを作成することもできます。

BYOM エンジンバージョンの作成ステータスの監視

BYOM エンジンバージョンの作成には通常数分かかります。ステータスが available と表示されるまで監視します :

aws rds describe-db-engine-versions \
  --engine sqlserver-ee \
  --engine-version 16.00.4225.2.v1 \
  --include-all \
  --region <your-region> \
  --query "DBEngineVersions[?DBEngineVersionArn!=null].{Version:EngineVersion,Status:Status}" \
  --output table

出力のサンプル :

注意: ステータスが Validating/Creating から Available に変わるまで待ってから、ステップ 3 に進む必要があります。

ステップ 3: インスタンスを License Included から BYOM に変換する

BYOM エンジンバージョンが available ステータスになったら、既存の License Included インスタンスを BYOM ライセンスモデルを使用するように変更できます。このオペレーションは、インスタンスの再作成やデータ移行を必要とせず、ライセンスモデルをインプレースで変更します。

インスタンスが Multi-AZ インスタンスの場合、ダウンタイムを最小化するためにローリングインプレース変換が実行されます。Single-AZ インスタンスの場合、ダウンタイムが必要です。メンテナンスウィンドウ中にこのタスクを実行することをお勧めします。

注意: BYOM から License Included への変換はサポートされていません。変換は慎重に計画してください。

AWS CLI を使用してインスタンスを変更する

aws rds modify-db-instance \
  --db-instance-identifier my-li-instance \
  --engine-version 16.00.4225.2.v1 \
  --license-model bring-your-own-media \
  --apply-immediately \
  --region <your-region>

以下のスクリーンショットが示すように、RDS Console からインスタンスを変更してライセンスモデルを変換することもできます。

注意: 選択した BYOM エンジンバージョンがインスタンスの現在のバージョンより高いマイナーバージョンの場合、RDS はマイナーバージョンアップグレードとライセンスモデルの変更を単一のオペレーションで実行します。

変換の確認

変更が完了したら、ライセンスモデルが変更されたことを確認します :

aws rds describe-db-instances \
  --db-instance-identifier my-li-instance \
  --query "DBInstances[0].{ID:DBInstanceIdentifier,Status:DBInstanceStatus,LicenseModel:LicenseModel,EngineVersion:EngineVersion}" \
  --output table \
  --region <your-region>

既存の DB インスタンスとライセンスモデルを一覧表示する

まだ License Included モデルを使用しているすべての SQL Server インスタンスを一覧表示するには :

aws rds describe-db-instances \
  --region <your-region> \
  --query "DBInstances[?starts_with(Engine,'sqlserver') && LicenseModel=='license-included'].{ID:DBInstanceIdentifier,Engine:Engine,License:LicenseModel,MultiAZ:MultiAZ,ReadReplica:ReadReplicaSourceDBInstanceIdentifier}" \
  --output table

ライセンス消費の追跡

AWS License Manager を使用して、RDS インスタンスのライセンス消費を追跡できます。ライセンス使用状況を有効化し追跡するには、以下の手順に従います :

ステップ 1: AWS License Manager をオンボーディングする

インスタンスを追跡するには、License Manager にアカウントのリソースインベントリを読み取る権限を付与するサービスリンクロールが必要です。以前に License Manager コンソールを開いて一度限りのセットアップを許可している場合、このロールはすでに存在するため、ステップ 2 に直接進めます。

初めての場合、AWS Management Console はサービスページにアクセスした時点で自動的にロールを作成します。または、AWS CLI を使用して明示的に作成できます :

aws iam create-service-linked-role --aws-service-name license-manager.amazonaws.com

ステップ 2: RDS BYOM インスタンス用のセルフマネージドライセンスを作成する

セルフマネージドライセンスは、License Manager に何を探し、どのようにカウントするかを指示します。Amazon RDS リソースで実行されている SQL Server を対象とし、カウント単位として vCPU を選択します。rds-byom-license-config.json という名前の JSON ファイルを作成し、以下の内容を記述します。この例は、Amazon RDS のセルフマネージドな SQL Server Enterprise Edition ライセンスを追跡します。SQL Server Standard Edition ライセンスを追跡するには、同様の JSON ファイルを作成し、ProductInformationFilterValue の値を sqlserver-se に変更します。

{
  "Name": "RDS-SQLServer-BYOM-EE",
  "Description": "Self-managed license for RDS SQL Server Enterprise Edition BYOM",
  "LicenseCountingType": "vCPU",
  "LicenseCountHardLimit": false,
  "ProductInformationList": [
    {
      "ResourceType": "RDS",
      "ProductInformationFilterList": [
        {
          "ProductInformationFilterName": "Engine Edition",
          "ProductInformationFilterValue": ["sqlserver-ee"],
          "ProductInformationFilterComparator": "EQUALS"
        }
      ]
    }
  ]
}

以下のコマンドを実行して、JSON ファイルを使用してライセンス構成を作成します。

aws license-manager create-license-configuration \
  --region <your-region> \
  --cli-input-json file://rds-byom-license-config.json

出力のサンプル :

出力に表示されるライセンス構成 ARN をメモしてください。次のステップで必要になります。

AWS License Manager コンソールからセルフマネージドライセンスに移動し、「セルフマネージドライセンスを作成」をクリックしてライセンス構成を作成することもできます。

ステップ 3: RDS インスタンスが追跡されていることを確認する

ライセンス構成の設定が完了した後、BYOM インスタンスが検出、レポートされるまでに少し時間がかかります。以下のコマンドを使用して追跡リソースを確認できます :

aws license-manager list-usage-for-license-configuration \
  --region <your-region> \
  --license-configuration-arn <license-configuration-arn>

考慮事項

License Manager はリージョンごとに使用状況を追跡します。マルチリージョンの RDS BYOM デプロイメントでは、各リージョンで独立して License Manager を設定してください。
クロスリージョンリードレプリカは、レプリカが存在するリージョンの License Manager によって追跡されます。

クリーンアップ

不要な課金を避けるため、不要になったリソースをクリーンアップしてください。

RDS インスタンスを削除します。

aws rds delete-db-instance \
  --db-instance-identifier convert-li-to-byom-demo \
  --skip-final-snapshot \
  --region <your-region>

関連するすべてのインスタンスとスナップショットが削除された後、BYOM エンジンバージョンを削除します。
```
aws rds delete-custom-db-engine-version \
  --engine sqlserver-ee \
  --engine-version 16.00.4225.2.v1 \
  --region <your-region>
```
Bash

S3 バケットを削除します。

aws s3 rb s3://amzn-s3-demo-bucket --force

ライセンス構成は、リソースがまだ関連付けられている間は削除できません。追跡対象の RDS BYOM インスタンスを先に削除する必要があります。
```
aws license-manager delete-license-configuration \
  --region <your-region> \
  --license-configuration-arn <license-configuration-arn>
```
Bash

まとめ

本記事では、既存の License Included の RDS for SQL Server インスタンスを Bring Your Own Media (BYOM) ライセンスモデルに変換する方法を説明しました。このプロセスでは、SQL Server インストールメディアを Amazon S3 にアップロードし、BYOM エンジンバージョンを作成し、既存インスタンスを新しいライセンスモデルを使用するように変更します。

AWS 上の SQL Server ライセンスコストを最適化したい場合、この変換は柔軟性を提供します。BYOM を通じて既存の Microsoft ライセンス契約を活用することで、自動バックアップ、パッチ適用、モニタリング、高可用性といった Amazon RDS のフルマネージドの利点を維持しながら、全体的なクラウド支出を削減できます。

Amazon RDS for SQL Server の BYOM の詳細については、Amazon RDS for SQL Server ドキュメントを参照してください。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。

著者について

フルマネージドの Amazon RDS for SQL Server で Bring Your Own Media によるライセンスモビリティの実現

Yoshinori Sawada — Fri, 18 Sep 2026 02:59:44 +0000

本記事は 2026 年 6 月 2 日に公開された “Unlock license mobility with Bring Your Own Media on fully managed Amazon RDS for SQL Server” を翻訳したものです。

長年にわたり、エンタープライズワークロードをクラウドに移行する理由は、管理の容易さ、柔軟なスケーリング、コスト削減を中心に語られてきました。これらは重要な理由ですが、既存のライセンス契約やすでに投資したインフラストラクチャとの兼ね合いで正当化する必要がありました。エージェンティック AI アプリケーションの登場により、その判断基準は変わりました。これらのアプリケーションは、柔軟にスケールする GPU キャパシティ、最新の AI サービスへの低レイテンシーアクセス、そしてデータに直接アクセスして推論できる AI モデルに依存しています。この基盤をセルフマネージドのデータセンターで再現することはますます困難になっています。オンプレミスのインフラストラクチャは管理が難しいだけではありません。クラウドネイティブなエージェンティック AI サービスへのアクセスが限られるため、ビジネスの次の一手に対する制約となりつつあります。

この制約は、業務データが存在するあらゆる場所で顕在化します。多くの企業において、そのデータの大部分は Microsoft SQL Server に格納されており、顧客レコード、注文、在庫、基幹業務システムを支えています。こうしたお客様にとって、移行を妨げていたのは移行したいという意思ではなく、すでに行ったライセンス投資でした。これまで、Software Assurance を持つお客様が SQL Server ライセンスを AWS に持ち込めるのは、Microsoft の License Mobility プログラムを利用したセルフマネージドの Amazon Elastic Compute Cloud (Amazon EC2) 上に限られていました。Amazon Relational Database Service (Amazon RDS) のようなフルマネージドデータベースの場合、既存の SQL Server ライセンスを持つお客様は、License Included モデルでライセンス費用を二重に支払う必要がありました。

Amazon RDS for SQL Server の Bring Your Own Media (BYOM) がこの問題を解決します。既存の SQL Server インストールメディアと、すでに投資済みのライセンスを持ち込み、フルマネージドデータベースサービスである RDS for SQL Server 上で追加のライセンス費用なしに利用できます。BYOM では、既存の SQL Server Enterprise Edition または Standard Edition のライセンスを再利用できます。AWS License Manager を設定済みであれば、BYOM インスタンスは自動的に追跡され、SQL Server のライセンス使用状況とコンプライアンスを継続的に可視化できます。移行を検討されているお客様のために、Amazon RDS はリフト & シフトのパスを提供し、SQL Server の業務データをフルマネージド環境に移行できます。RDS はパッチ適用、バックアップ、高可用性、モニタリングを自動化しつつ、AWS ネイティブのエージェンティック AI や分析サービスに直接アクセスできる環境を提供します。

本記事では、SQL Server のインストールメディアを Amazon Simple Storage Service (Amazon S3) にアップロードし、BYOM インスタンスを起動する方法を説明します。

ソリューション概要

既存の SQL Server ライセンスを再利用するには、ライセンスの配布条件に基づき、ライセンス済みの SQL Server Release to Manufacturing (RTM) メディアを Amazon RDS に提供する必要があります。BYOM では、AWS Console から RTM メディアをアップロードします。開始するには、RTM メディアを Amazon S3 にアップロードし、それに対してフルマネージドの RDS for SQL Server BYOM インスタンスを起動します。AWS License Manager を使用すると、Amazon RDS が BYOM インスタンスを自動的に検出し、vCPU 使用量をレポートするため、SQL Server のライセンス消費を継続的に可視化できます。ライセンスコンプライアンスの責任はお客様にあります。

Amazon RDS Console では、データベース作成ページから RDS for SQL Server BYOM インスタンスを直接作成できます。

ウォークスルー

このセクションでは、SQL Server 2022 Standard Edition で BYOM インスタンスを作成する手順を説明します。

前提条件

開始する前に、Software Assurance 付きの有効な SQL Server ライセンス (Standard Edition または Enterprise Edition) があることを確認する必要があります。ここからMicrosoft に License Mobility Verification Form を提出する必要があります。

ステップ 1: Visual Studio サブスクリプションから SQL Server RTM メディアをダウンロードする

まず、SQL Server の RTM メディアを Amazon RDS がアクセスできる S3 バケットに配置する必要があります。有効なサブスクリプションをお持ちの場合は、Visual Studio サブスクリプションを通じて Microsoft から RTM ISO ファイルをダウンロードできます。ボリュームライセンスで製品を購入した場合は、Microsoft 365 管理センターからもダウンロードできます。

ダウンロードページで「SQL Server 2022」(またはターゲットバージョン) を検索し、SQL Server 2022 Standard を見つけます。言語として English を選択し (他の言語はサポートされていません)、ダウンロード形式として ISO を選択します。

注意 : 言語は English かつコアベースライセンスの RTM ISO ファイルを使用してください。

ステップ 2: Amazon S3 にファイルをアップロードする

S3 バケットがまだない場合は、「バケットを作成」を選択して一意の名前を付けます (この例では sqlserver-byom-media を使用します)。次にアップロード画面で「ファイルを追加」を選択し、SQL Server RTM メディアファイルを選択して、「アップロード」を選択して転送を開始します。

ステップ 3: 最初の BYOM インスタンスを作成する

RTM メディアが S3 に配置されたら、最初の BYOM インスタンスを作成する準備が整いました。特定のメジャーバージョンに対して初めてインスタンスを起動する際、Amazon RDS Console はバックグラウンドで 2 つのオペレーションを単一のワークフローで処理します。RTM メディアから BYOM エンジンバージョンを作成し (約 20 分)、その BYOM エンジンバージョンに対してインスタンスを起動します。

Amazon RDS Console を開き、左のナビゲーションペインで「データベース」を選択します。
「データベースの作成」を選択します。
「エンジンのオプション」で以下を設定します:
1. エンジンのタイプ : Microsoft SQL Server を選択
2. データベース管理タイプ : Amazon RDS を選択
3. エディション : SQL Server Standard Edition を選択
4. ライセンス : bring-your-own-media を選択
5. メジャーエンジンバージョン : SQL Server 2022 を選択
6. マイナーエンジンバージョン : ターゲットバージョンを選択 (例 : 16.00.4245.2.v1)
「S3 からの SQL Server RTM メディア」 (メジャーバージョンごとに初回のみ表示) で「S3 を参照」を選択 : バケット名 (sqlserver-byom-media) から RTM ファイルを選択し、ISO ファイルを選択します。例 : “Enu_sql_server_2022_standard_core_edition_x64_dvd.iso”
DB インスタンス識別子 : 名前を入力します (例 : sqlserver-se-2022-byom)
残りの設定 (DB インスタンスクラス、ストレージ、接続、認証、バックアップ、メンテナンス) は、License Included インスタンスと同様に設定します。
すべての設定を確認し、「データベースの作成」を選択します。

注意 : 言語は English かつコアベースライセンスの RTM ISO ファイルを使用してください。

重要な制限事項と考慮事項

Amazon RDS for SQL Server で BYOM を使用する際は、以下の考慮事項に留意してください。

まず、SQL Server ライセンスが Microsoft のライセンス契約に準拠していることを確認する責任はお客様にあります。AWS License Manager を使用してライセンス使用状況を追跡できますが、ライセンス上限を超過しても AWS がオペレーションをブロックすることはありません。コンプライアンスはお客様の責任です。

次に、RTM ファイルはコアベースライセンスかつ English 言語のみに対応しています。これらの条件を満たさない場合、BYOM エンジンバージョンの作成は失敗します。

最後に、関連する RDS インスタンス、スナップショット、またはバックアップが存在する間は、BYOM エンジンバージョンを削除できない点に注意してください。

クリーンアップ

不要な課金を避けるため、このウォークスルーで作成したリソースが不要になったら削除してください。

RDS インスタンスの削除 : RDS Console → 「データベース」を選択 → インスタンスを選択 → 「アクション」 → 「削除」
S3 オブジェクトとバケットの削除 : S3 Console → バケットを選択 → 「空にする」 → 「削除」

まとめ

SQL Server のライセンス投資を守ることと、クラウドで新たな可能性を生み出す AWS の分析およびエージェンティック AI サービスへのデータアクセスパスを確保することを、二者択一にする必要はありません。Amazon RDS for SQL Server の Bring Your Own Media がその道を開きます。Software Assurance をお持ちであれば、Microsoft の License Mobility プログラムを利用して、既存の SQL Server Standard Edition または Enterprise Edition ライセンスをフルマネージドの Amazon RDS 環境に持ち込むことができます。Amazon RDS では、自動バックアップ、モニタリング、パッチ適用、高可用性の恩恵を受けられます。

本記事では、Amazon RDS for SQL Server で Bring Your Own Media (BYOM) を使い始める方法を説明しました。ウォークスルーでは、Release to Manufacturing (RTM) ファイルの S3 へのアップロードと BYOM エンジンバージョンの作成を取り上げました。

SQL Server の業務データとエージェンティック AI の間にあったライセンスの壁は、もはや存在しません。Amazon RDS for SQL Server の Bring Your Own Media サポートの詳細については、以下のリソースをご参照ください :

BYOM は、Amazon RDS for SQL Server がサポートされているすべての商用 AWS リージョンで利用可能です。最新の利用可能状況については、Amazon RDS for SQL Server の料金ページをご確認ください。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。

著者について

SAP Commerce Cloud と SAP Cloud ERP Private on AWS の統合 – 実践的で実証済みのアプローチ

Koshi Matsumoto — Fri, 18 Sep 2026 02:12:55 +0000

はじめに

企業がデジタルコマースプラットフォームのモダナイゼーションを進める中で、多くの企業は、コアとなる SAP ERP ワークロードを AWS 上の SAP Cloud ERP Private で運用しながら、SAP Commerce Cloud SaaS を採用しています。SAP Commerce Cloud は、複雑な B2B、B2C、B2B2C の企業向けに設計された統合型 e コマースプラットフォームであり、ホスティング場所を SAP が決定する完全マネージド型の SaaS ソリューションとして提供されます。そのため、重要なアーキテクチャ上の問いは、プラットフォームがどこで稼働するかではなく、AWS 上でホストされている SAP システムといかに効果的に統合するか、という点になります。SAP は、SAP Commerce（SAP Hybris）2205 のメインストリームメンテナンスの終了を 2026 年 7 月 31 日と発表しており、多くの企業は、SAP Commerce Cloud SaaS と AWS 上で稼働する SAP Cloud ERP Private を統合することで、e コマースインフラストラクチャのモダナイゼーションをますます進めています。正しく設計されたとき、この統合モデルはセキュリティ、高いパフォーマンス、そして運用のシンプルさをもたらします。本ブログでは、4 つの重要な観点、すなわち 1) リージョン選択、2) レイテンシー最適化、3) ネットワーキング、4) セキュリティ実装にわたって、実証済みのアーキテクチャのベストプラクティスを探ります。これらのプラクティスは、SAP Commerce Cloud と AWS 上でホストされる SAP ランドスケープとの間で、堅牢かつスケーラブルな統合を構築するのに役立ちます。

SaaS は一貫性のある予測可能なユーザー体験を提供するように設計されている

あらゆる SaaS プラットフォームの中核的な強みは、オンラインでアクセスできる場所であればどこからでも、一貫性のある予測可能なユーザー体験を提供できる点にあります。SAP Commerce Cloud はまさにこの目的のために構築されています。これは、リージョンやネットワークを越えて、買い物客、パートナー、モバイルデバイス、バックエンドシステムにサービスを提供します。ネットワークの変動、レイテンシーの差異、地理的に分散したアクセスに対応することは、このプラットフォームの基本的な設計原則です。

この運用モデルは、今日の大企業における標準的な実践です。企業は、CRM、人事、決済処理、物流、分析プラットフォームなど、複数の SaaS アプリケーションを自社のコアシステムと日常的に統合しています。SAP Commerce Cloud も、この実証済みの同じパターンに従っており、多様な SaaS ソリューションを AWS 上の SAP Cloud ERP Private と統合することは、現在のエンタープライズ標準となっています。

ベストプラクティス 1: リージョン選択

統合パフォーマンスを最適化するため、最も近い AWS リージョンを選択してください。AWS はグローバルなリージョンネットワークを運用しており、企業は SAP S/4HANA のデプロイを Commerce Cloud のエンドポイントと地理的に整合させることができます。鍵となるのは、SAP Commerce Cloud のホスティング場所に地理的に最も近い AWS リージョンを選択することです。このアプローチにより、ラウンドトリップのレイテンシーを最小化し、2 つのプラットフォーム間のリアルタイム API 呼び出しの応答性を向上させます。最も近い AWS リージョンを選択する際に、エンドユーザーの所在地と SAP Commerce Cloud のホスティングリージョンの両方を考慮することで、企業は予測可能で効率的な接続性を実現できます。このリージョン近接性の戦略は、複雑なネットワーク構成を必要とせずにクロスプラットフォーム統合を最適化するための、実践的かつ非常に効果的な方法です。

SAP Commerce Cloud リージョン	AWS 上で稼働する SAP Commerce Cloud 向け Intelligent Selling Services *	推奨される最も近い AWS リージョン
オーストラリア: ニューサウスウェールズ		アジアパシフィック（シドニー）– ap-southeast-2
ブラジル: サンパウロ		南米（サンパウロ）– sa-east-1
カナダ: トロント		カナダ（中部）– ca-central-1
中国: 香港		アジアパシフィック（香港）– ap-east-1
中国: North 3		中国（北京）– cn-north-1
中国: 上海		中国（寧夏）– cn-northwest-1
ドイツ: フランクフルト	ドイツ: フランクフルト	ヨーロッパ（フランクフルト）– eu-central-1
インド: プネ		アジアパシフィック（ムンバイ）– ap-south-1
日本: 東京		アジアパシフィック（東京）– ap-northeast-1
オランダ: アムステルダム		ヨーロッパ（アムステルダム）– eu-west-3 またはヨーロッパ（アイルランド）– eu-west-1
シンガポール		アジアパシフィック（シンガポール）– ap-southeast-1
英国: ロンドン		ヨーロッパ（ロンドン）– eu-west-2
アラブ首長国連邦: ドバイ		中東（UAE）– me-central-1
米国: カリフォルニア		米国西部（北カリフォルニア）– us-west-1 または米国西部（オレゴン）– us-west-2
米国: バージニア	米国東部（バージニア北部）	米国東部（バージニア北部）– us-east-1
米国: バージニア (2)		米国東部（バージニア北部）– us-east-1 または米国東部（オハイオ）– us-east-2

* SAP Commerce Cloud 向けの Intelligent Selling Services は、コマースプラットフォーム全体でお客様体験を高めるリアルタイムのパーソナライゼーションを提供します。

参照: ガイダンスについては、SAP データセンターの所在地および AWS グローバルインフラストラクチャをご参照ください。

ベストプラクティス 2: レイテンシー最適化

優れたユーザー体験のための CDN の活用

重要な最適化手法の 1 つは、コンテンツ配信ネットワーク（CDN）を活用して買い物客の体験を向上させ、ストアフロントのパフォーマンスを加速することです。SAP Commerce Cloud のストアフロントは、画像、スクリプト、スタイルシート、商品メディアといった静的コンテンツに大きく依存しており、これらは CDN を通じて効率的にキャッシュおよび配信できます。

Amazon CloudFront は、静的コンテンツの配信とストアフロント API のパフォーマンスの両方を大幅に強化できます。SAP Commerce Cloud へのストアフロント API リクエストを適切にキャッシュすることで、CloudFront はバックエンドシステムの負荷を軽減しながら、エンドユーザーの応答時間を改善します。この二重の最適化、すなわち静的コンテンツ配信の高速化と API オーバーヘッドの削減により、地理的な場所を問わず、高速で一貫性のあるストアフロントのパフォーマンスが確保されます。

CloudFront は、SAP Commerce Cloud がどこにホストされていても、コンテンツ配信を加速するグローバルに分散したエッジネットワークを提供します。ユーザーに近いエッジロケーションでストアフロントのアセットをキャッシュすることで、企業はコアアプリケーションのアーキテクチャを変更することなく、ページの読み込み時間を短縮し、お客様体験を向上させます。

詳細は AWS ブログ: Supercharge your SAP Composable Storefront with Amazon CloudFront をご参照ください。

ミドルウェアがレジリエントなクラウド間の対話を実現する

SAP BTP Integration Suite のような堅牢なミドルウェアレイヤーは、SAP Commerce Cloud と SAP Cloud ERP Private システムとの間の信頼性の高い統合に不可欠です。SAP Integration Suite、API ゲートウェイ、イベントブローカーといったプラットフォームは、アプリケーションを疎結合にするマネージドな通信チャネルを構築し、リクエストのキューイング、リトライ、変換、非同期処理を可能にします。

このアーキテクチャパターンにより、一時的なネットワーク遅延やレイテンシーの変動が、重要なビジネストランザクションを妨げることは決してありません。ミドルウェアはまた、キャッシュ、オーケストレーション、監視の機能を提供し、クラウド間のやり取りを円滑にし、システム全体のレジリエンスを向上させます。このようにミドルウェアを実装することは、ハイブリッドクラウド統合における十分に確立されたベストプラクティスであり、クラウドプロバイダーの整合性や地理的な近接性への依存を排除します。

非同期統合はレイテンシー感度を最小化する

SAP Commerce Cloud と SAP S/4HANA との間のほとんどのやり取りは、設計上、非同期です。注文レプリケーション、顧客マスターの更新、カタログ同期、在庫フィードといったプロセスは、API、イベントストリーム、またはメッセージキューを通じて交換されます。これらのビジネストランザクションは、ミリ秒レベルの応答に依存せず、正確性やユーザー体験に影響を与えることなく、通常のインターネットレイテンシーを許容できるように設計されています。

同期統合のベストプラクティス

SAP Commerce Cloud のリージョンに最も近い AWS リージョン（通常は同じ都市圏に位置します）を選択すると、SAP Commerce Cloud SaaS を AWS 上の S/4HANA Cloud ERP Private インスタンスと統合しても、意味のあるパフォーマンスへの影響はありません。リアルタイムの価格計算、ライブ在庫チェック、クレジットカード認証、与信限度チェック、または在庫可用性チェックといった、より少数の同期シナリオについても、AWS リージョンと SAP Commerce Cloud のホスティング場所との間の一般的なレイテンシーは、許容範囲内に十分収まります。数十ミリ秒程度の応答時間は、エンタープライズアプリケーションが最適なパフォーマンスのために必要とする閾値をはるかに下回ります。

ベストプラクティス 3: ネットワーキング

AWS は、外部の SaaS プラットフォームとの統合をさらに強化する高度なグローバルネットワーキング機能を提供します。AWS Global Accelerator、Regional NAT Gateway、Amazon Route 53 といったサービスや、高性能な AWS バックボーンルーティングインフラストラクチャは、エンドユーザー、SAP Cloud ERP Private ワークロード、SAP Commerce Cloud のエンドポイント間の接続性を最適化します。

AWS 内のトラフィックエンジニアリングは、ネットワークの障害を自動的に迂回してルーティングし、地理的に分散したデプロイ全体で一貫したパフォーマンスを維持します。企業は Amazon CloudWatch と VPC フローログを使用して接続性を監視でき、統合トラフィックのパターンとネットワークの挙動を完全に可視化できます。これらのツールにより、AWS 上でホストされる SAP システムから SAP Commerce Cloud への、予測可能で安全かつレジリエントなアクセスが確保されます。

自動トラフィックエンジニアリング – AWS の自動トラフィックエンジニアリングは、ネットワークの障害を自動的に検出して迂回ルーティングすることで、SAP Commerce Cloud への接続性を強化します。AWS は、インターネットトラフィックのパフォーマンスを向上させるために、いくつかの舞台裏の最適化を実施します。

詳細は How AWS improves global connectivity via automated traffic engineering をご参照ください。

ベストプラクティス 4: セキュリティ

AWS 上に構築されるセキュリティとコンプライアンス

SAP Commerce Cloud は SaaS として稼働しますが、AWS は SAP Cloud ERP Private ワークロードを保護するための可能な限り最も強固な基盤を提供します。AWS は 140 を超えるコンプライアンス認証と、包括的なネイティブセキュリティサービス群を提供します。Identity and Access Management、暗号化、ネットワークファイアウォール、ロギング、監視により、SAP 環境に対する多層防御（defense-in-depth）モデルが実現します。

AWS 上の SAP Cloud ERP Private システムと SAP Commerce Cloud との間のすべての通信は、HTTPS や TLS といった標準的で安全なインターネットプロトコルを介して行われます。OAuth、API トークン、相互 TLS といった認証メカニズムは、ホスティングプロバイダーを問わず一貫して機能します。企業はすでに、銀行、決済ゲートウェイ、その他の重要な SaaS サービスへの接続に、日常的にこれらと同じ手法を利用しています。

AWS の優先事項について詳しくは、AWS Culture of Security をご参照ください。

ベストプラクティス 5: Amazon 全体のサービスとの統合

さらに、SAP Commerce Cloud を Amazon のフルフィルメントサービスで拡張できます

SAP Commerce Cloud を運用している企業は、Amazon のフルフィルメントサービス、すなわち Buy with Prime および Amazon Multi-Channel Fulfillment（MCF）と統合することで、既存のストアフロントとビジネスプロセスを維持しながら、Amazon の物流ネットワークを活用し、e コマース業務を強化できます。

Buy with Prime との統合

Buy with Prime により、ブランドは、迅速で送料無料の配送、簡単な返品、24 時間 365 日のサポート、Amazon のレビューといった Prime のショッピング特典を、自社のウェブサイト上で直接提供できます。SAP Commerce Cloud と統合することで、事業者は信頼されるショッピング体験によってお客様を惹きつけ、維持できます。調査結果によると、買い物客の 95% が Buy with Prime を再び利用する可能性が非常に高く、事業者は買い物客あたりの収益が平均 16% 増加しています。

Amazon Multi-Channel Fulfillment（MCF）

Amazon MCF は、事業者がすべての販売チャネルにわたるピッキング、梱包、出荷、配送に Amazon のフルフィルメントネットワークを活用できるようにする、サードパーティロジスティクス（3PL）ソリューションです。SAP Commerce Cloud の事業者は、Amazon のネットワーク内で単一の在庫プールを使用することで、在庫切れ率の低減、在庫回転率の改善、業務効率の向上を実現できます。事業者からは、Amazon 以外のチャネルに MCF を追加して以降、売上または収益が平均で約 19% 増加したと報告されています。

SAP S/4HANA との統合の加速

SAP S/4HANA 向けの Amazon MCF および Buy with Prime アクセラレーターは、SAP Business Technology Platform（SAP BTP）を SAP Integration Suite および Amazon の事前構築済み API とともに活用することで、統合作業を最大 75% 削減し、多くのお客様が 6 週間未満で本番稼働できるようにします。この統合により、SAP のお客様は、既存の SAP S/4HANA のビジネスプロセスを妨げることなく Amazon のフルフィルメントインフラストラクチャを活用でき、既存の SAP ワークフローや構成とシームレスに連携する一般的なやり取りをすぐに利用できます。

SAP および AWS サポートから支援を受ける方法

AWS と SAP は、RISE with SAP on AWS 向けの Migration Support Service を提供しています。これは、RISE 移行および SAP Commerce Cloud 統合の期間中、迅速なトラブルシューティング、統合の課題、本番稼働支援のために、AWS のテクニカルインフラストラクチャエンジニアへの直接的なアクセスを提供するものです。AWS-SAP のエキスパートが戦略的なアドバイザリーとインフラストラクチャの専門知識を提供し、SAP と連携して迅速な課題解決と最適なパフォーマンスを実現することで、ミッションクリティカルな RISE with SAP on AWS ワークロードのより速く、よりスムーズな移行を確実にします。

まとめ

SAP Commerce Cloud を AWS 上の SAP Cloud ERP Private と統合することは、業界全体で広く採用されている、実証済みで信頼性の高いエンタープライズアーキテクチャパターンです。SaaS プラットフォームは、インターネットベースで地理的に分散したアクセスを前提に、一から設計されています。非同期統合、ミドルウェア主導の通信、最適な同期統合レイテンシーのための SAP Commerce Cloud ホスティング場所に最も近い戦略的な AWS リージョン選択、そして CDN による高速化により、あらゆるデプロイシナリオで優れたパフォーマンスが確保されます。

AWS は、ミッションクリティカルな SAP Cloud ERP Private ワークロードに対して、セキュリティ、レジリエンス、運用面の成熟度の最適な組み合わせを提供します。同時に、そのグローバルネットワーキング機能により、SaaS プラットフォームとの統合を容易かつ信頼性の高いものにします。

適切なアーキテクチャ設計とベストプラクティスの遵守により、企業は、コアとなる SAP ランドスケープの最適な基盤として AWS を活用しながら、SAP Commerce Cloud によって自社のコマースプラットフォームを自信を持ってモダナイゼーションできます。このハイブリッドモデルは、成功しているデジタルビジネスが今日どのように運営されているか、すなわち柔軟で、分散されており、クラウドプラットフォーム全体でシームレスに接続されている姿を反映しています。

本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。

ERP例外処理をAWSエージェント型標準作業手順書（SOP）で自動化

Koshi Matsumoto — Fri, 18 Sep 2026 02:08:13 +0000

背景

最近の調査（McKinsey）によれば、世界中のエンタープライズ ERP システムでは毎月膨大な数の手作業による介入が発生し、波及しています。たとえば、あるグローバル製造企業では、入金された銀行支払いが請求書と何日も突き合わせられないまま残り、キャッシュフローを悪化させ、売掛金（AR）チームが日々数百件の取引を手作業で消し込むことで売上債権回転日数（DSO）が膨らんでいます。ここで、内部統制マネージャーに「AI がこれらの支払いを自動的に消し込み、計上します」と提案する場面を想像してみてください。返ってくる答えは決まって「間違いを起こさないとどうして分かるのか？」です。複雑な業務プロセスを AI に確実に実行させることへの信頼は、今日多くのユーザーが直面している最大の課題のひとつであり続けています。

SAP のスリーウェイマッチのような高度な組み込み自動化でさえ十分とは言えず、請求書の例外、購買発注（PO）の承認ブロック、月次決算、会社間消し込みなど、ほぼあらゆる業界で手作業の介入が横断的に発生しています。これまでの自動化アプローチも同様でした。ロボティック・プロセス・オートメーション（RPA）は UI のクリック操作を自動化しましたが、画面レイアウトが変わると壊れてしまいました。従来型の機械学習（ML）は例外を予測できても、それを解決することはできませんでした。

お客様の IT ランドスケープは、SAP インスタンス、レガシーシステム、クラウドサービス、サードパーティアプリケーションが入り乱れたパッチワークとなり、それぞれが互換性のないプロトコルと分断されたデータを抱え、ますます複雑化しています。SAP は財務報告の検証済みコアとして機能します。したがって、システム横断的な自動化はいずれも、Sarbanes-Oxley 法（SOX）、ISO、内部監査の要件を満たすために、セキュアなアクセス制御、検証済みのユーザー ID、完全な監査証跡を強制する必要があります。

状況を変えたのは、非構造化された手順を推論し、システム境界を越えてツールを呼び出し、複数ステップのワークフローにわたってコンテキストを維持できる基盤モデル（foundation model）の登場です。

これらの例外を大規模に解決するには、エージェント型標準作業手順書（Agentic Standard Operating Procedures、SOP）が必要です。これは、ナレッジベースからエンタープライズの手順を解釈し、SAP システムと非 SAP システムをまたいで複数ステップの例外を自律的に解決する、単一かつ統合された AI 駆動エージェントです。判断や承認が必要な箇所では、ヒューマン・イン・ザ・ループ（human-in-the-loop）の制御が働きます。

エージェント型 AI は有望な道を示しますが、新たな課題ももたらします。それは、エージェントがガバナンスの追いつかない速さで増殖していくということです。分断されたシステム間でセキュアに連携するエージェントを構築するのは複雑でコストがかかります。「あらゆる問題に対してエージェントを作る」という無制約なアプローチではなく、段階的に成熟し、各段階で価値を提供し、人間の信頼を漸進的に獲得していく、構造化されたフレームワークが必要です。

本稿では、SAP ユースケース向けの AWS Agentic AI Solutions Framework を紹介します。これは、ヒューマン・イン・ザ・ループ制御による漸進的な信頼、SOP 駆動の統合エージェントアーキテクチャ、決定論的で監査可能なアクションのためのガード付き MCP サーバー、ID を意識したセキュリティとコンプライアンス、監査水準のドキュメンテーションのための永続的な状態管理という 5 つのコア機能に基づいて構築された、プロダクショングレードのアプローチです。続いて、Amazon Bedrock AgentCore を用いて SAP 環境に対してこのフレームワークをデプロイするためのリファレンスアーキテクチャと技術的ベストプラクティスを解説します。

コア機能

さまざまな業界や事業部門のお客様と協働する中で、AWS は、エンタープライズ ERP ランドスケープにおいて安全かつ効果的に稼働するためにお客様のエージェント型 AI システムが備えるべきコア機能のセットに収束しました。次のセクションのリファレンスアーキテクチャは、これらの各機能に対応しています。

リスクを抑えながら段階的に信頼を獲得する： エージェントはまずアドバイザリーモードで開始し、すべてのアクションは人間が実行します。信頼が積み上がるにつれて、エージェントは監督付き実行へと移行し、最終的には、信頼度が定義済みのしきい値を超えた場合にのみ独立して動作する自律的な解決へと進みます。自動化は、信頼を確立した分だけ拡大していきます。

すべてのプロセスに 1 つのエージェントをデプロイする： 業務プロセスごとに別々のエージェントを構築する代わりに、単一のエージェントが、キュレーションされたナレッジベースから SOP を動的に解釈・実行し、例外の種類やプロセスのコンテキストに応じて適切なツールを実行時に呼び出します。お客様の業務チームが SOP を自然言語で作成・所有するため、変更にはコードの再デプロイではなく SOP の更新だけで済みます。エージェントは SOP を厳格なルールではなく推論のコンテキストとして扱い、キュレーションされたプロンプト、構造化されたツールオーケストレーション、ガードレールを通じて、あらゆるステップを決定論的かつ監査可能に保ちます。

一貫した再現性のある結果を得る： 同じ入力は、常に同じ出力を生成しなければなりません。大規模言語モデルは本質的に確率的であるため、決定論（モデルがハルシネーションを起こしたり一貫性のない結果を生成したりするのを防ぐこと）を達成するには意図的な制御が必要です。本ソリューションは、制御されたモデルパラメータ、構造化されたプロンプトエンジニアリング、ハルシネーションを防ぐための信頼できる SOP コンテンツとライブシステムデータからの取得、ポリシーとグラウンディング検証のための実行時ガードレール、アクション実行前に推奨事項をクロス検証するマルチエージェントによる相互検証を通じて、これを強制します。

誰が、いつ、何をしたかを正確に把握する： すべてのエージェントのアクションを適切な ID に帰属させなければなりません。エージェントが自律的に動作する場合は自身のサービスアカウントで認証し、人間が介入する場合はシステムがその人間の検証済み ID に切り替えます。この分離により、コンプライアンスチームはエージェントのアクションと人間が承認したアクションを区別できます。あらゆるツールの呼び出し、データの読み取り、アクションは、SOX、ISO、内部監査の要件を満たす改ざん検知可能な証跡とともにログ記録されます。

初日から監査担当者と運用チームを満足させる： 専用の永続的な状態レイヤーが、例外のライフサイクル全体を記録します。エージェントの推論トレース、認証済み ID を伴うツールの呼び出し、人間へのエスカレーションイベント、解決結果を、すべて不変（immutable）で追記専用（append-only）のレコードとして保持します。リアルタイムのオブザーバビリティがエージェントのパフォーマンスを監視し、振る舞いが想定されるベースラインから逸脱した際に運用チームへ通知します。

リファレンスアーキテクチャ

高いレベルで見ると、本アーキテクチャは ERP の例外をスケジュールに従って検知し、AI エージェントを呼び出して該当する SOP を取得し、SAP および接続されたシステム全体で例外を解決し、監査コンプライアンスのためにあらゆるステップをログ記録します。信頼度が低い場合や承認が必要な場合、エージェントは人間へエスカレーションし、返答を受け取ると再開します。

下記の図 1 は、エンドツーエンドのアーキテクチャを示しています。このアーキテクチャには 3 つの境界があります。お客様の SAP 環境、AWS クラウド、そしてオプションのユーザーインターフェイスです。ここでは、単一の例外が検知から解決までシステム内をどのように流れるかを説明します。

1. 例外検知（Exception Detection）： Amazon EventBridge が、設定可能なスケジュール（デフォルト：5 分ごと）で AWS Lambda 関数をトリガーし、SAP OData サービスをポーリングして新しい例外（ブロックされた請求書、突合できない支払い、欠落した引当金、または SOP が定義する任意の例外タイプ）を検出します。
2. 状態の初期化（State Initialization）： ポーラーは、新しい例外ごとに Amazon DynamoDB の状態テーブルへ status を detected として書き込み、解決に必要な最小限のコンテキスト（PO 番号、総勘定元帳（GL）アカウント、コストセンター）を記録します。重複排除チェックにより、同じ例外が二重に処理されるのを防ぎます。
3. エージェントの呼び出し（Agent Invocation）： システムは、DynamoDB Streams トリガー経由で自律的に、またはユーザーインターフェイスを通じて手動で、エージェントを呼び出します。エージェントは、AI エージェントの構築・デプロイ・スケーリングのためのフルマネージドサービスである Amazon Bedrock AgentCore 上で稼働し、エージェントフレームワークには AWS のオープンソースのエージェント型 SDK である Strands を使用します。
4. ツール接続（Tool Connectivity）： カスタム統合コードなしにエージェントへ SAP やその他のシステムへのアクセスを与えるため、マネージドな 2 つの経路のいずれかで接続します。
  - AgentCore Runtime 上でホストされる MCP サーバー（サンプルコードに含まれています）
  - 大規模でマネージド・ガバナンスされたツールアクセスのための AgentCore Gateway
5. SOP の取得（SOP Retrieval）： すべての解決が承認済みのプロセスに従うことを検証するため、エージェントの最初のツール呼び出しは、エンタープライズコンテンツをインデックス化・チャンク化・取得するフルマネージドの RAG 機能である Amazon Bedrock Knowledge Base から該当する SOP を取得し、処理対象の例外タイプに対する意思決定ツリーを確立します。
6. SAP の実行（SAP Execution）： ハードコードされた API マッピングを排除し、保守負担を軽減するため、エージェントは SAP OData API 仕様を含む 2 つ目の Knowledge Base を使用して、正しいエンドポイントとフィールドを実行時に発見し、SAP に対して読み取り・書き込み操作を実行します。これにより、ハルシネーションによる API 呼び出しを防ぎます。エージェントは、ドキュメント内に見つけられるエンドポイントのみを呼び出します。
7. 監査証跡（Audit Trail）： 各ステップで、エージェントは DynamoDB 内の不変な processing_history リストに追記し、以下を記録します。
  - 推論トレース： ステップごとのロジックと取得した SOP のセクション
  - ツールの呼び出し： 入力、出力、タイムスタンプ、認証済み ID
  - 解決結果： 実行された最終アクションと SAP のトランザクション参照
  - この追記専用ログ（レコードは追加できるが、変更・削除は決してできない）が、SOX と内部監査コンプライアンスのための改ざん検知可能な監査証跡となります。
8. 人間へのエスカレーション（Human Escalation）： 例外が人間の判断を要する場合（金額が重要性のしきい値を超える、またはエージェントの信頼度が定義済みのレベルを下回る場合）、エージェントは Amazon SES 経由で構造化されたエスカレーションメールを送信し、ケースのステータスを awaiting_human_input に更新して停止します。
9. 人間の応答（Human Response）： 人間が返信すると、SES はそのメールを Amazon S3 に保存し、これが Lambda 関数をトリガーします。この関数はメールスレッド全体を解析し、その応答とともにエージェントを再呼び出しします。エージェントは、完全なコンテキストの連続性を保ったまま、中断したところから正確に処理を再開します。
10. インターフェイスレイヤー（Interface Layer）： ユーザーインターフェイスは意図的に薄く、差し替え可能です。サンプルコードには Streamlit ダッシュボードが同梱されていますが、AgentCore ランタイムのエンドポイントを呼び出せるクライアントであれば何でも動作します。
  - React またはカスタム Web アプリ
  - ネイティブな SAP 統合のための SAP Fiori タイル
  - Amazon Quick Apps：ガバナンスされたノーコードの承認体験のため
  - インターフェイスをまったく持たない：完全に自律的な運用のため

例：購買発注の引当計上を大規模に自動化する。あるグローバル製造企業は、このフレームワークを適用して、1,000 件を超えるアクティブな PO にまたがる 2 億 5,000 万ドル超のカスタム治工具の購買を管理しました。エージェントは該当する SOP を自律的に取得し、各 PO を適切なワークフローで解決し、財務承認のための仮伝票（parked journal entry）を SAP に作成します。以前は 1 決算サイクルあたり 30 日超の手作業を要していたプロセスが、今では PO あたり数分で完了します。

技術的ベストプラクティス

デモで動作するエージェント型システムを作るのは簡単です。プロダクショングレードの信頼性、監査可能性、コスト効率には、意図的なエンジニアリング上の選択が求められます。以下のプラクティスは、プロダクション環境でのデプロイから得られたもので、最も一般的なギャップに対処します。

決定論（Determinism）

同じ入力は、同じ出力を生成しなければなりません。これは、単一のメカニズムではなく、階層化された制御によって達成します。

構造化されたプロンプト： 明示的なテンプレート、システムレベルのルール、振る舞いのフック、出力フォーマットの制約を用いて、推論を定義済みのパターンに固定します。
検索拡張生成（RAG）： Amazon Bedrock Knowledge Bases を介して、あらゆる応答を取得した SOP コンテンツとライブシステムデータにグラウンディングし、エージェントがパラメトリックな記憶ではなく信頼できる情報源から推論するようにします。
実行時ガードレール： コンテキストのグラウンディング検証とポリシーベースのコンテンツフィルタリングのために Amazon Bedrock Guardrails を適用します。
マルチエージェントによる相互検証： リスクが高い場合は、スーパーバイザーエージェントを用いて専門のサブエージェントをオーケストレーションし、アクション実行前に推奨事項をクロス検証します。

ID の伝播（Identity Propagation）

すべてのエージェントのアクションを適切な ID に帰属させなければなりません。本アーキテクチャは、デュアル ID モデルをサポートします。

自律運用： エージェントは OAuth 2.0 の 2 レッグ（2LO）認証により自身のサービスアカウントで認証し、各ダウンストリームシステムとのマシン間の信頼関係を確立します。
ヒューマン・イン・ザ・ループ運用： AgentCore Identity が OAuth 2.0 の 3 レッグ（3LO）認証へ移行し、人間の検証済み ID をエージェントを通じて対象システムへ伝播します。

この分離により、コンプライアンスチームは監査ログにおいてエージェントが起動したアクションと人間が承認したアクションを明確に区別できます。これは SOX 統制の中核的な要件です。

Cedar ポリシーによるきめ細かな認可

誰が動作しているかを把握することは必要ですが、それだけでは十分ではありません。各 ID が何をできるかも制御する必要があります。AgentCore Policy は、AWS のオープンソースの認可言語である Cedar を使用し、AgentCore Gateway を経由するすべてのエージェント-ツール間のやり取りに対してきめ細かな権限を強制します。Cedar ポリシーは 4 つの属性を評価します。

プリンシパル ID： ユーザー名、ロール、スコープなどの OAuth クレーム（上記の 2LO/3LO ID モデルから）
アクション： 呼び出される具体的なツール（例：invoke_sap_odata_service や send_email）
リソース： リクエストがルーティングされる Gateway
リクエストコンテキスト： ツールの入力パラメータ。属性ベースのアクセス制御を可能にします（例：書き込み操作を一定の金額しきい値未満の請求書に制限する）

システムはデフォルトですべてのアクションを拒否します。ポリシーは Cedar 構文または自然言語で作成します。AgentCore Policy は平易な英語のルールを解釈して候補となる Cedar ポリシーを生成し、自動推論を用いて、強制する前に過度に許容的または制限的なポリシーを検出します。たとえば、「エージェントは任意の PO を読み取ってよいが、仕訳を計上できるのは 50,000 ドル未満に限る」といったルールを、ツール呼び出しが SAP に到達する前に、Gateway レイヤーで決定論的に強制できます。よくあるパターンについては、AgentCore Policy のドキュメントをご覧ください。

プロンプトの改善（Prompt Improvement）

システムプロンプトは、決定論が始まる場所です。特に重要なのは 3 つのパターンです。

明示的なコンプライアンスのフレーミング： 明示的な優先度シグナル（すべて大文字のラベル、必須を示す表現）を用いて、SOP コンプライアンスを交渉の余地のないものとしてフレーミングします。これにより、モデルが手順に違反する形でワークフローを「最適化」してしまう可能性を減らします。
ハルシネーション防止のガードレール： 人間の入力を待ってブロックされている際に、証拠や承認をでっち上げるのではなく、停止してエスカレーションするようエージェントに指示します。これは、エージェント型システムで最も危険な失敗モードのひとつに直接対処します。
実例（Exemplars）： 正しい振る舞いの具体例、日付計算のフォーマット、エスカレーションメールのテンプレート、OData クエリのパターンなどを、プロンプト内に直接含めます。エージェントは、ゼロから生成するよりも参照実装がある方が高いパフォーマンスを発揮します。

実際の例外データを用いてプロンプトを反復改善し、バージョン間で出力品質を追跡します。

評価（Evaluations）

エージェント型システムには、複数のレベルでの評価が必要です。

ユニットレベル： 個々のツール呼び出しの正しさをテストします。OData クエリは期待どおりのフィールドを返すか？メールには適切なコンテキストが含まれているか？
エンドツーエンド： 期待される結果を伴う既知の例外シナリオに対して、ワークフロー全体をテストします。解決済みのケースからリグレッションスイートを構築し、プロンプトや SOP の変更が既存の振る舞いを劣化させないようにします。
運用メトリクス： ビジネスにとって重要な指標を追跡します。解決精度、エスカレーション率、解決までの時間、誤検知率などです。
リアルタイム監視： AgentCore 向けの Amazon CloudWatch の生成 AI オブザーバビリティ機能を使用して、モデル呼び出しのレイテンシ、トークン消費量、ツール呼び出しの成功率、信頼度スコアの分布を監視します。

コスト最適化（Cost Optimization）

スケールしても例外あたりのコストを予測可能に保つために：

モデルを適切なサイズにする： 定型的な例外には小さいモデルを使い、大きいモデルは複雑なケースのために温存します。
頻繁に取得するコンテンツをキャッシュする： めったに変わらない SOP ドキュメントや API ドキュメントはキャッシュして、Knowledge Base のクエリ量を削減できます。
インテリジェントなプロンプトルーティング： Amazon Bedrock のプロンプトルーティングを使用して、呼び出しごとに最もコスト効率の高いモデルを自動的に選択します。
運用のレジリエンス： ピーク時のボリュームではジッター付きの指数バックオフを実装し、コストの可視化のために例外タイプ別にトークン消費量を追跡します。

オブザーバビリティと状態管理

運用チームと監査担当者の双方を満足させるため、プロダクションのエージェント型システムには 3 つのレイヤーの状態が必要です。

短期セッションメモリ： 単一の解決内でのコンテキスト（会話履歴、ツール呼び出しの結果、中間的な推論）を維持します。
長期メモリ： AgentCore Memory を介して、セッションをまたいで学習したパターンを永続化します。たとえば、既知の PO フォーマットの問題により一貫して例外を発生させるベンダーを認識するなどです。
永続的な監査水準の状態： DynamoDB 内で、例外のライフサイクル全体を不変で追記専用のレコードとして記録します。推論トレース、認証済み ID を伴うツールの呼び出し、エスカレーションイベント、人間の意思決定、解決結果です。

まとめと次のアクション

エージェント型 AI は、ERP の例外管理の経済性を根本的に作り変えます。プロセスごとに個別のエージェントを構築・保守する代わりに、組織は、実行時に手順を解釈し、適切なツールを呼び出し、状況が求めるときに人間の判断へエスカレーションできる、単一の SOP 駆動エージェントをデプロイできます。漸進的な導入フレームワークは、自動化が信頼を確立した分だけ拡大することを検証し、ID を意識したアーキテクチャは、エージェントが起動したものであれ人間が承認したものであれ、あらゆるアクションを完全に帰属・監査できることを保証します。

リファレンス実装は、Strands エージェント、SAP OData 統合を備えた MCP サーバー、DynamoDB による状態管理、ヒューマン・イン・ザ・ループのワークフローを含むオープンソースのサンプルコードとして利用可能です。可視化のための Streamlit ダッシュボードも同梱されています。Knowledge Base 内の SOP を更新するだけで、コードを変更することなく、お客様の例外タイプに合わせて適応できます。

まずは、GitHub リポジトリの ERP 例外管理ソリューションをダウンロードし、SAP OData 統合のための AWS for SAP MCP Server をセットアップしてください。

本稿で参照したサービスをより深く知るには、Amazon Bedrock AgentCore、Amazon Bedrock Knowledge Bases、Strands Agents SDK をご覧ください。

著者について

	Sagar は、AWS でエージェント型 AI と生成 AI を活用して業務プロセスを自動化し、レガシーシステムをモダナイズすることで、エンタープライズのデジタルトランスフォーメーションを支援することを専門としています。SAP ワークロードに注力し、お客様が AI を用いて移行・モダナイゼーション・自動化を進めるためのツールとソリューションを構築しています。仕事以外では、テクノロジーへの情熱と、家族と過ごすかけがえのない時間、Formula 1 への深い愛、そして Sachin Tendulkar のクリケットの功績への変わらぬ敬意とのバランスを取っています。
	Zach Daniels は、AWS のソリューションアーキテクトで、AWS for SAP を専門とし、ERP 向けのエージェント型 AI アプリケーションに注力しています。お客様と協働して、スケーラブルで Well-Architected な SAP 環境を AWS 上で設計しています。シアトルを拠点とし、スタートアップと技術エンジニアリングでの経験をエンタープライズのお客様との仕事に活かしています。
	Abhijeet は、複数の業界にまたがって戦略とデリバリーを主導してきた、20 年以上の SAP テクノファンクショナル経験を持つデータ・AI リーダーです。AWS の SAP データアナリティクス戦略、エージェント型コードモダナイゼーション、AI 駆動のプロセス自動化イニシアチブを牽引しています。コロラドの山でのハイキングとスキーを楽しんでいます。

本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。

【寄稿】株式会社レスター、Amazon Bedrock で顧客課題とグループの解決力をつなぐ情報プラットフォームを構築

Shota Nakamoto — Fri, 18 Sep 2026 00:56:28 +0000

はじめに

本記事は、株式会社レスター（以下、レスター）の加瀬友基氏による寄稿記事です。

レスターでは、各社・各部門に分散していた営業情報を一つの土台に集める AI 情報プラットフォームを構築しています。中核となるレスターマッチングサービス（以下、RMS）は、顧客ニーズと企業・技術・製品などの解決手段を結びつけるマッチングの仕組みであると同時に、顧客・仕入先、取引実績、担当者との接点、商材、案件、議事録などを相互の関係性を保ったまま蓄積する、グループ共通のデータウェアハウスです。商談時の録音データを AI が議事録としてデータ化し、RMS へ取り込み、AI チャットボット機能で RMS 内の蓄積された情報から必要な知見を引き出します。これにより、ある部門がつかんだ顧客課題を、別部門が持つ人・商材・技術へつなげます。本稿では、この仕組みを構築した背景、Amazon Web Services（以下、AWS）の活用、そして情報を蓄積し続けるための運用についてご紹介します。

レスターとは

レスターグループは、「情報と技術で、新しい価値、サービスを創造・提供し、社会の発展に貢献します」の経営理念のもと、半導体・電子部品の販売・ソリューション提供をはじめ、映像・音響・通信機器の取り扱い、太陽光発電などの再生可能エネルギーの企画・オペレーション、完全閉鎖型植物工場の運営、ソフトウェア開発、産業用PCの設計・製造など多岐にわたる事業活動を行っています。

グループの多様な強みを一つの提案力に変えるために

事業領域の拡大とグループ再編の結果、グループが持つ顧客基盤、商材、技術、知見は大きく広がりました。一方で、各社・各事業は、もともとの顧客や商流、情報の持ち方、業務プロセスが異なります。子会社・事業・部門が「どの顧客と接点を持ち、何を得意とし、どのような商材や知見を持つのか」を、日々の営業活動の中で十分に把握することは容易ではありませんでした。

お客様の課題は、必ずしも一つの事業領域だけで完結するものではありません。グループ内に解決手段があっても、必要な情報や担当者にたどり着けなければ、提案にはつながりません。グループの多様な強みを一つの提案力に変えるためには、会社・事業・部門を越えて情報を見つけ、活用できる仕組みが必要です。レスターは「あらゆるニーズに対応できる『エレクトロニクスの情報プラットフォーマー』」をビジョンに掲げています。このビジョンが目指しているのは、例えばステークホルダーの課題を自部門の知識だけで答えるのではなく、グループ全体から最適な人・商材・技術を探し出し、事業横断で提案できる状態を指しています。一つひとつの顧客課題と、グループが持つ多様な解決力を結び付け、あらゆるニーズに応えられるエレクトロニクスの総合商社へと進化することを目指しています。

現場で起きていた、4 つの情報の断絶

背景にある課題を営業の現場で分解すると、単に情報が複数のシステムへ分散していたというだけではありません。会社・事業・部門の境界を越えて、情報の所在と文脈を理解し、次の行動へ移すまでの各段階に断絶がありました。

商談内容の属人化: 商談の詳細は個人のメモやファイルに残り、組織の知識になりにくい
SFA では残らない文脈: 営業支援システム（SFA）は案件金額や進捗管理に有効でも、顧客の背景や会話の文脈までは十分に残りにくい
グループ理解の属人化: 会社・事業への理解が担当者の経験に依存し、他部門の得意分野、取扱商材、顧客接点まで把握しにくい
訪問前準備の負荷: 情報収集が担当者の経験と人脈に依存し、訪問前準備に時間がかかる

この状態でチャットボットだけを導入しても、参照する情報が古い、少ない、偏っているという問題は解消しません。私たちは、情報が生まれる現場から、会社・事業を越えた蓄積、検索、提案までをつなぐ必要があると考えました。

RMS を中核に、商談の会話から次の提案までをつなぐ

こうした 4 つの情報の断絶を解消するため、情報の流れを「データ化する」「蓄積・統合する」「引き出し、提案へつなぐ」の 3 段階に整理しました。それぞれを AI 議事録、RMS、AI チャットボットが担い、商談で得た情報が次の提案に使われるまでを一本につなぎます。

図 1：顧客課題とグループの解決力をつなぐ情報プラットフォーム

1. AI 議事録：会話を「検索できる営業資産」に変える

AI 議事録では、オンライン会議や対面商談の録音データと、会議で使用した資料を取り込みます。音声ファイルを Amazon Simple Storage Service (Amazon S3) に保存し、Amazon Transcribe で文字起こしと話者分離を行います。その結果を Amazon Bedrock 上の Anthropic Claude に渡し、会議概要、発言内容、顧客課題、決定事項、次回アクションなどを所定の形式で整理します。生成した議事録や案件情報は、必要に応じて RMS や SFA へ連携します。

Amazon Transcribe では、独自の音声認識モデルを構築することなく音声をテキスト化し、話者分離によって複数人の会議を発言者単位で整理できます。Amazon Bedrock については、社内外の商談情報を扱うため、安全性と統制を効かせながら生成 AI を利用できる点を重視しました。

従来、議事録は会議後の記録作業でした。今回の構想では、議事録を営業データの入口と位置づけています。会話には、顧客の言葉、困りごとの背景、検討状況、関係者、次の打ち手といった、SFA の数値項目だけでは表現しきれない鮮度の高い情報が含まれるためです。

2. RMS：全社の営業情報をつなぐデータウェアハウス

RMS には、顧客・仕入先の基礎情報、取引実績、名刺・接点、従業員、商材、SFA の商談情報、Web サイト経由の問い合わせ、そして AI 議事録などを集約しています。単にファイルを保管するのではなく、顧客、担当者、商材、課題、案件の関係性を保ったまま蓄積することが特徴です。

この構造により、顧客を起点に、グループ各社の取引実績、過去の商談、社内の担当者、関連する商材や解決策を横断的にたどることができます。部門ごとに分かれていた情報を、次の提案に使える形で結びつけることが RMS の役割です。

また、レスターグループ各社で取り扱っている多様な商材ごとにビジネスオーナーを置き、内容の最新化、公開範囲、分類を管理する運用を整えています。AI の回答品質は、モデルの性能だけでなく、参照データの鮮度と網羅性に左右されます。そのため、コンテンツマネジメントをシステム運用の一部ではなく、事業側の役割として設計しました。

3. AI チャットボット：必要な情報を引き出し、次の一手へつなぐ

AI チャットボットは、RMS に蓄積された情報を業務で使うための対話型インターフェースです。LangGraph で構築した AI エージェントを Amazon Bedrock AgentCore Runtime 上で動作させ、RMS から呼び出した回答をストリーミング表示します。独自に設計した検索・回答の処理を維持しながら、AWS 上の実行環境として RMS と連携できる点を評価しました。

社内文書や議事録の検索には、Amazon Bedrock Knowledge Bases と、そのベクトルストアである Amazon OpenSearch Serverless を利用しています。Amazon S3 は元データの保管先であり、質問のたびにファイルを直接検索するのではありません。会社、商材、案件、担当者などの構造化データが必要な場合は、Catalog API を通じて PostgreSQL から取得します。標準設定では外部 Web 検索を行わず、社内情報に基づく回答を優先しています。

代表的な利用シーンは次の通りです。

訪問前準備: 対象企業の取引実績、接点、過去の議事録、進行中の商談をまとめる
クロスセル: 別部門の議事録にある潜在ニーズと、グループ内の商材・ソリューションを結びつける
提案準備: 顧客の状況に応じた提案の骨子やトークスクリプトを作る
社内探索: 商材の担当者、類似案件の経験者、協業可能な部門を探す

利用場面に応じたボタンを用意しており、選択すると「明日この会社へ訪問するので、グループ全体の取引と商談を整理して」といった質問文が自動入力されます。利用者は最初から精緻なプロンプトを書く必要はなく、回答を見ながら追加質問で深掘りできます。回答は結論ではなく、営業が原典や担当者を確認し、次の行動を考えるための出発点です。

AWS を活用した構成と、安全な利用のための設計

AWS を採用した理由は、音声データの保管、文字起こし、議事録の生成、社内情報の検索、回答生成までを、一つのクラウド環境で連携できることです。Amazon S3、Amazon Transcribe、Amazon Bedrock、Amazon Bedrock Knowledge Bases、Amazon OpenSearch Serverless、Amazon Bedrock AgentCore Runtime を組み合わせることで、システム間連携の複雑さを抑えながら、情報が増え続ける前提の基盤を構築しました。また、当社の汎用生成 AI 環境では、AWS がオープンソースで公開する Generative AI Use Cases（GenU）も活用し、そこで得た知見を社内ユースケースの設計に生かしています。

図 2 は、RMS、AI 議事録、AI チャットボットと、今回利用している主な AWS サービスの関係を示したものです。

図 2：AI 情報プラットフォームの AWS アーキテクチャ

主な AWS サービスと役割

Amazon S3: 音声・資料・正規化済みドキュメントの保管
Amazon Transcribe: 音声の文字起こしと話者分離
Amazon Bedrock: Anthropic Claude による議事録の要約・構造化と、チャット回答の生成
Amazon Bedrock AgentCore Runtime: LangGraph で構築した AI エージェントの実行
Amazon Bedrock Knowledge Bases / Amazon OpenSearch Serverless: 社内文書・議事録の RAG 検索

Amazon Bedrock では、入力したデータや生成結果が基本モデルの改善に使用されることはなく、モデルプロバイダーと共有されることもありません。また、Amazon Bedrock 内のデータは転送中も保管中も暗号化されます。商談や取引に関する情報を扱うため、こうした AWS 側の仕組みに加え、レスター独自の権限設定と運用ルールを設けています。主な対策は次の通りです。

録音時の同意: 社外商談は事前に相手先の許可を得る
参照対象の選択: 議事録ごとに社内 AI チャットボット回答時の参照対象へ含めるかを選択し、秘匿性の高い会議は除外する
競合情報の制御: 担当サプライヤーに応じて競合情報の閲覧を制限する仕組みを設ける
人による最終判断: AI 回答は参考情報として扱い、重要な判断や社外提出前には原典・担当部署を確認する

特に、「AI に学習させる」という言葉は、モデル自体の追加学習と RAG での参照を混同しやすいため、運用説明では「社内 AI 回答時の参照対象に含めるか」と表現するようにしています。技術的な安全性だけでなく、利用者が誤解しない言葉を選ぶことも重要だと考えています。

導入で難しかったのは、技術よりも「情報が集まり続ける運用」

AI チャットボットの回答は、参照する情報以上には良くなりません。特定の利用者だけが議事録を登録すれば、回答もその部門や担当者に偏ります。商材情報が更新されなければ、AI は古い内容を基に回答します。

そこで、半導体・電子部品を扱うデバイス事業部門から段階的に利用を開始し、社員を対象とした説明会（延べ 500 名以上が参加）、商材ビジネスオーナーへの登録レクチャー、利用フィードバックの回収を実施しました。スマートフォンから録音・登録できる導線も整え、現場が無理なく情報を残せるよう改善を続けています。

運用上の学び: 情報を集めたい運営側は入力項目を増やしがちですが、現場はまず「楽になること」を求めます。AI 議事録で日常業務の負担を下げ、その結果として質の高いデータが蓄積される順序が重要でした。

現在の活用と、見えてきた効果

情報を蓄積する側では、AI 議事録が営業データの入口として回り始めています。社内調査を基に、1 件あたり約 23 分の議事録作成時間を削減できると試算しており、2026 年 7 月現在、月間 2,000 件を超える議事録が作成されています。ただし、私たちが重視しているのは削減時間よりも、毎月 2,000 件を超える商談・会議の情報が、統一形式で検索・分析・再利用できるデータとして蓄積されていく点です。長期的にはこちらの方が大きな価値を生むと考えています。

情報を引き出す側では、2026 年 6 月に AI チャットボットを公開し、利用データと現場の声を基にチューニングを続けています。RMS には取引・接点情報、AI 議事録、SFA 情報、商材情報などが連携され、これまで人に聞くか複数システムを調べていた作業を、1 つの対話画面から始められるようになりました。たとえば、訪問先についてグループ内の取引金額と担当者、過去の商談経緯をまとめる、別部門の顧客課題に対して自部門のソリューションを提案できないか探索する、特定製品を扱う担当者と関連商材を同時に確認する、といった使い方が始まっています。

一方で、現時点は完成形ではありません。登録されていない取引や議事録があれば回答には現れず、情報を入力する利用者が偏れば結果にも偏りが出ます。こうした不足を可視化し、システム、データ、運用の 3 つを同時に改善できることも、パイロット運用の成果だと捉えています。

今後の展開：事業横断で、提案と行動を生む基盤へ

生成 AI を業務に定着させるために必要なのは、高性能なモデルだけではなく、日常業務の中で情報が生まれ、整い、使われ、更新され続ける仕組みです。AWS では、AI を安全に利用するための機能が揃っており、新しい機能も継続的に追加されるという点で、当社の取り組みのような社内横断的な情報の整備、AI 活用を推し進めることができると考えています。今後は、顧客ニーズとグループ内の商材を継続的に照合し、AI が提案候補や新規開拓リストを提示する仕組み、部門を越えて適切な担当者や知見へつなぐ仕組みも検討しており、実際の利用状況と蓄積データを見ながら、顧客・商談・商材・担当者・議事録の関係性をより活用しやすい形へ発展させます。

営業担当者個人の経験や人脈だけに依存せず、ある部門が捉えた顧客課題を、別部門の商材やソリューションへつなげます。半導体・電子部品からシステム、映像・通信、エネルギーまで、レスターグループが持つ幅広い解決手段を一つの営業基盤から活用できる状態を目指します。目指しているのは、社内検索の効率化だけではありません。顧客との会話から課題を捉え、グループ全体の知識と解決手段を組み合わせ、顧客自身も気づいていない潜在ニーズに対して最適な解決策を提案できる営業基盤です。その結果として、新しい顧客と新しいビジネスが継続的に生まれる状態を目指します。

おわりに

レスターが構築しているのは、単体のチャットボットではなく、営業活動で生まれた情報を会社の資産に変え、再び営業へ戻す仕組みです。商談の会話がデータになり、関係性を保ったまま蓄積され、必要なときに引き出される。この循環が回るほど、商談を重ねた分だけ会社の知識が積み上がり、事業横断の提案力が高まります。AWS のサービスを活用しながら、この情報循環をレスターグループ全体へ広げ、各事業の強みを一つの提案力へ変えていきます。「まずレスターに相談すれば、解決の糸口が見つかる」という世界を実現し、「エレクトロニクスの情報プラットフォーマー」というビジョンにつなげていきます。

著者について

加瀬友基（Yuki Kase）

株式会社レスター Data Analysis Management
データドリブン経営を担当し、グループ内外のデータを統合・分析する情報プラットフォーム戦略を推進。データと AI を活用し、商社機能の進化と新たな事業・顧客価値の創出に取り組む。

NTTドコモモバイルイノベーションテック部における AI-DLC 実践（第2回）：2チーム並行開発の実験結果と知見

Takaaki Kikuchi — Fri, 18 Sep 2026 00:02:27 +0000

※ この投稿はお客様に寄稿いただいた記事です。

本稿は、NTTドコモモバイルイノベーションテック部（以下、MIT 部）が AI-DLC TTT でフィジカル AI 領域の ML パイプラインを構築した取り組みの第 2 回です。

第 1 回：フィジカル AI 領域での ML 開発への適用

第 2 回：2 チーム並行開発の実験結果と知見（本記事）

第 1 回では、AI-DLC の Inception フェーズで要件を構造化し、設計レビューで 11 個の不整合を事前に検出した取り組みをご紹介しました。
第 2 回では、Construction フェーズでの 2 チーム並行開発の実験結果と、得られた知見についてご紹介します。

6. Construction フェーズ：パイプラインの実装（Day 2–3）

Inception フェーズで作成した計画に沿って実装を進めました。
両チームとも同一のパイプライン構造を採用しつつ、細部の設計判断に違いが生まれました。

共通アーキテクチャ

両チームが構築したパイプラインの基本構造は以下で共通です。

図：データフロー（act_demos.npz → 座標変換 → 蒸留 → PPO → 評価）

蒸留 MLP の検証 MSE（Mean Squared Error）< 0.01 を両チームとも達成し、Isaac Lab 上での 1024 並列環境による PPO 学習を実行しました。これにより、パイプライン全体（蒸留→PPO→評価）が一通り接続された状態に到達し、以降はパイプラインの構築ではなく成功率の改善に集中できる段階になりました。

チーム間の設計判断の分岐点

テーマ設定の段階で、強化学習を最終段階とするパイプライン構造は共通ですが、ベースとなるモデルが模倣学習の直接的な出力ではなく RPD 論文に基づく蒸留を経由する設計であり、どのように変換を行うかは未検証でした。Inception フェーズに用いた論文などの事前知識でパイプラインの基本構造（蒸留→PPO→評価）までは両チーム共通でしたが、蒸留の入力次元や KL ペナルティの扱いについては複数の有力なアプローチが考えられ、机上では優劣を判断できませんでした。

そこで、それぞれのチームメンバーが AI-DLC の中で判断したアプローチを採用し、実験結果を比較検証する方針としました。全く同じとなる可能性もありましたが、今回は以下のような差異が生まれました。

設計判断	チームピンク	チームブルー
パイプライン起点	事前収集済みデモデータ（53 エピソード）	ACT 学習→デモ収集から（後述の軌道修正あり）
蒸留 MLP 入力次元	28 次元（環境の全観測空間）	12 次元 → Actor 28 次元入力層の最初 12 列に部分ロード
PPO への統合方式	蒸留 MLP 全体を Actor としてロード	Actor 入力層の最初 12 列に蒸留重みをコピー、残り 16 列はランダム初期化
KL ペナルティ	あり（adaptive β方式、3 パターン検証）	なし（RSL-RL デフォルト設定に委譲）
検証の焦点	KL ペナルティの効果検証	蒸留初期化の効果そのものの検証

KL ペナルティの β は、蒸留で得た方策をどの程度信頼するかを制御するハイパーパラメータです。
β が大きいほど蒸留ポリシーからの逸脱にペナルティを強くかけ、小さいほど自由に探索できます。
チームピンクは β=1.0（強い制約）、β=0.5（中程度）、β=0（制約なし）の 3 段階で効果を検証しました。

チームブルーの「部分ロード方式」というのは、蒸留 MLP（12 次元入力）の重みを RSL-RL（Isaac Lab 上で強化学習を行うライブラリ）の ActorCritic（行動出力と価値推定を担うネットワーク構造）における第 1 層の重み行列（256 ニューロン × 28 次元入力）の最初 12 列にコピーし、残り 16 列はランダム初期化のまま学習させます。環境の全観測情報を活用しつつ、蒸留知識を初期値として活かすアプローチです。

7. AI-DLC による軌道修正：チームブルーのスコープ変更

Construction フェーズで、AI-DLC の価値が明確に現れた場面がありました。

チームブルーは当初、ACT モデルの学習からデモ収集までを含む、より上流からのパイプライン構築を目指していました。しかし Day 2 の実装開始直後、ACT 学習環境のセットアップに想定以上の工数がかかることが判明しました。3 日間という制約の中で、ACT の環境構築に時間を費やすとコアの蒸留→PPO→評価パイプラインの検証が間に合わないリスクが生じたのです。

この時点で、AI-DLC のプロセスに従い Inception フェーズに立ち戻りました。タスクリストの優先度を再評価し、以下の判断を行いました。

タスクリスト	変更前	変更後
TL-1	蒸留用データの準備（ACT 学習→デモ収集を含む）	「ACT 学習→デモ収集」を除外。事前収集済みデモデータ（53 エピソード）を起点に変更
TL-2	MLP の蒸留	維持
TL-3	PPO Fine-tune	維持
TL-4	評価と比較	維持

この軌道修正がスムーズだったのは、要件がタスクリストとして構造化されていたからです。「何を削って何を残すか」の判断基準が各タスクリストの優先度として明示されており、チーム全員が同じ根拠で合意できました。具体的には、TL-1（データ準備）が最高優先度であり事前収集済みデータ（53 エピソード）で着手可能である一方、ACT 学習は優先度が低くこの事前データで代替可能だったため、ACT 学習を除外するという判断に至りました。場当たり的な「間に合わないから削ろう」ではなく、構造化された優先度に基づく意思決定です。

結果として、チームブルーはコアパイプラインに集中し、蒸留あり/なしの比較実験（64% vs 90%）という本 TTT で最も価値のある知見を得ることに成功しています。

8. 実験結果：2 チームの比較

両チーム共通の比較基準として、ACT ベースライン（模倣学習のみ、人手デモ 10 件＋COSMOS,Mimic による増幅）の成功率は 45% です。

チームピンク：KL ペナルティの段階的検証

KL ペナルティの有無と強度を変えた 3 回の実験を実施しました。

条件	成功率	累積報酬	備考
蒸留初期化 + PPO + Full KL (β=1.0)	0%	-6.72	std 減少を阻害、探索不能
蒸留初期化 + PPO + Mean-only KL (β=0.5)	0%	2.05	探索の早期停止
蒸留初期化 + PPO（KL なし）	11%	1.82	局所最適に陥る

チームピンクの成功率が全条件で著しく低かった主因は、後に判明した座標変換の欠落（object_pos のロボットベース相対変換が未実装）でした。蒸留の教師データと RL 環境の座標系が一致していなかったため、蒸留 MLP が誤った方策を学習し、KL ペナルティがその誤りをさらに固定化する結果となりました。TTT 後にこの座標変換を修正し 97% に到達した詳細は後述します。

チームブルー：蒸留あり/なしの比較

RSL-RL をデフォルト設定に委譲し、蒸留初期化の有無を直接比較しました。

条件	成功率	累積報酬	備考
蒸留初期化 + PPO（部分ロード）	64%	56.69	蒸留 12 次元→Actor28 次元に統合
ランダム初期化 + PPO（蒸留なし）	90%	84.44	蒸留なしが最高性能

2 チームの結果が示す知見

蒸留初期化は reaching（接近）を加速するが、lifting（持ち上げ）への移行を阻害する局所最適を生む
KL ペナルティは、蒸留ポリシーが偏った方策を学習している場合、探索を制限し逆効果になる
蒸留初期化自体が性能を制限する可能性がある（蒸留なし 90% vs 蒸留あり 64%）
RPD 論文の前提（オンライン VLA 推論）を私達の実装（重み固定 MLP）に上手く適応できていない

今回の結果は単一タスク、単一条件での実験であり、RPD の手法自体の評価を確定するものではありません。しかし、2 チームが異なる実験設計（KL の段階的緩和 vs 蒸留あり/なしの直接比較）で同じ傾向を観測したことは、今後の検証を進める根拠にはなると考えています。

9. AI-DLC を ML に適用して得られた知見

方針転換と失敗の蓄積を支えるプロセス

各フェーズ（Inception、Construction、Operation、評価）で成果物が定義されているため、方針転換の判断が容易でした。チームブルーの軌道修正はその好例です。

設計レビューにより、実装前に 11 個の不整合を検出できました。ML 実装では「動くが正しくない」コードが生まれやすく、設計段階での整合性検証が手戻りの防止に直結します。

3 回の実験サイクルと失敗分析はすべて構造化ドキュメントとして残り、次の実験の判断根拠として蓄積されました。

実験サイクルの高速化

Kiro が論文の解釈や数式の意味を解説することで、強化学習、蒸留、Isaac Lab、RSL-RL といった専門領域の理解がチーム全員で揃いました。

この共有された理解が、実験サイクルの速度に直結しています。初回の失敗分析から修正、2 回目のパイプライン実行までが数時間で完了しました。速さの要因は 2 つあります。

Inception で実験の仮説と検証基準がドキュメント化されており、「何を変えて次を試すか」の起点が明確だったこと
パイプライン全体の構造と各ユニットの役割を全員が把握しており、原因の切り分けと修正方針の合意に時間がかからなかったこと

一般的な ML 実験では仮説の修正から再実験まで数日かかることが多いですが、今回は 1 日で 3 サイクル回すことができました。

ドメイン専門家の役割をどう位置づけるか

Kiro の支援により、ドメイン専門家がいないチームでも動作する ML パイプラインの構築まで到達できました。

一方で、「なぜこの手法がこのタスクで機能しないか」を正確に評価する局面や、RPD 論文の前提条件と実装の差異を見抜く局面では、深い理論的理解が必要でした。Kiro が出力したコードの妥当性を判断できない場面が繰り返し発生し、ML 実装の経験が浅い私たちにはかなり負荷が高かったのが実情です。

この経験から、AI-DLC は「専門家がいないと着手できない」状態を「専門家なしでもパイプラインを構築でき、専門家は品質の最終確認に集中する」状態に変えるフレームワークだと捉えています。AI が論文解釈、コード生成、設計レビューを担うことでチームの知識水準が引き上げられ、専門家がレビューすべき範囲が絞り込まれます。

Inception で生成された設計レビューレポートや実験分析レポートを専門家に共有すれば、常駐せずスポット参加でも的確なフィードバックが可能です。今回の座標変換の問題も、TTT 後に構造化された記録を読み返すことで数時間で原因を特定できました。

今後は、Inception で定義した受け入れ基準（座標値の範囲、入力次元の整合性、損失の収束条件など）を自動テストとして実装し、パイプラインの各段階で機械的に検証する仕組みを導入する予定です。ドメイン知識を実行可能なテストコードに変換すれば、専門家が不在でも品質の劣化を早期に検出できます。

（参考）TTT 後：AI-DLC の継続で 97% へ

TTT は 3 日間で終了しましたが、AI-DLC のプロセスは継続可能です。TTT 後に得られた結果を補足します。

座標変換の欠落が真因だった

TTT 後、構造化された実験記録を読み返し Inception に立ち戻りました。最優先だった TL-1（座標系変換）の実装を再検証したところ、object_pos の座標変換が欠落していることが判明しました。

ACT のデモデータは LeIsaac のワールド座標系で記録されている一方、RL 環境はロボットベース相対座標系を使用しています。この不一致が蒸留 MLP の学習を破綻させていました。

# 欠落していた変換（修正版で追加）
object_pos -= [0.35, -0.64, 0.01]  # LeIsaacのロボットベース位置

構造化された実験記録があったため、原因の切り分けは数時間で完了しました。

再蒸留の実装と結果

座標変換の修正に加え、TTT 中の観察（reaching は学習するが lifting が伸びない）に基づき、損失関数を Phase-weighted MSE に変更しました。lifting フェーズの重みを 5 倍にしています。

再蒸留を初期重みにロードし、KL なし PPO で 5000 イテレーション（1024 環境並列、約 52 分）を実行した結果です。

条件	成功率
ACT ベースライン（模倣学習のみ）	45%
RL-Only（蒸留なし、ランダム初期化）	90%
再蒸留 + PPO	97%

再蒸留 + PPO は RL-Only（90%）を統計的に有意に上回りました（Fisher’s exact test, p=0.049）。

TTT 中に得た「蒸留初期化は逆効果」という結論は、座標変換バグに起因する誤りでした。前処理が正しければ、蒸留初期化は PPO の収束を加速し、最終成功率も向上させます。

構造化された記録が継続を可能にする

TTT 後 1 日で 97% に到達できたのは、3 日間の実験記録、失敗分析、設計文書が構造化ドキュメントとして残っていたからです。コンテキストが消えず蓄積されること、失敗が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する最大の利点でした。

10. 成果と今後の展望

3 日間の定量的成果

カテゴリ	成果物
コード	distill.py (~400 行), train_finetune.py (~500 行), evaluate.py (~450 行) — 合計 1,350+ 行
実験	蒸留チェックポイント, PPO 学習結果 (3 Runs + 蒸留あり/なし比較), 100 エピソード評価
ドキュメント	タスクリスト, ユニット分割計画, 設計レビューレポート, 実験分析レポート — 計 30+ 文書

今後の展望

技術面では、蒸留データ品質の改善、実機（SO-101）への Sim-to-Real Transfer を計画しています。

プロセス面では、他チームへの AI-DLC プロセス展開、ML 実験における設計レビューテンプレートの標準化を進めます。

著者について

NTTドコモモバイルイノベーションテック部における AI-DLC 実践（第1回）：フィジカルAI領域でのML開発への適用

Takaaki Kikuchi — Fri, 18 Sep 2026 00:02:16 +0000

※ この投稿はお客様に寄稿いただいた記事です。

本稿では、株式会社NTTドコモ（以下、ドコモ）モバイルイノベーションテック部（以下、MIT 部）が AI-DLC（AI-Driven Development Lifecycle）の TTT（Train The Trainer）に参加し、フィジカル AI 領域における機械学習パイプラインを 3 日間で構築した取り組みについて、全 2 回に分けてご紹介します。

第 1 回：フィジカル AI 領域での ML 開発への適用（本記事）

第 2 回：2 チーム並行開発の実験結果と知見

1. はじめに

ドコモの MIT 部ユースケース協創担当では、次世代技術の社会実装に向けた研究開発を推進しています。

私は、注目領域の一つであるフィジカル AI（現実世界で物理的に動作する AI）において、ロボットアームの動作学習を効率化するパイプラインの構築に取り組んでいます。

今回、AWS が提唱する AI-DLC の手法を活用し、模倣学習（IL: Imitation Learning）で獲得した動作知識を強化学習（RL: Reinforcement Learning）で自律的に改善していくパイプラインを 1 つのプロダクトとして捉え、その設計から実装までを AI-DLC のプロセスに沿って、チーム開発で 3 日間という短期間で構築・検証しました。

本記事（第 1 回）では、AI-DLC を ML 領域に適用するに至った私たちの理解と判断、そして Inception フェーズでの要件構造化と設計レビューの実践についてご紹介します。

2. 背景と課題

フィジカル AI における学習の課題

ロボットに動作を学習させるアプローチには、大きく分けて 2 つの方法があります。

模倣学習（Imitation Learning, IL）：人間のデモンストレーションデータから動作を学習する。学習は安定するが、デモにない状況への汎化が難しい
強化学習（Reinforcement Learning, RL）：試行錯誤を通じて報酬を最大化するように学習する。未知の状況にも対応できるが、ゼロからの学習はサンプル効率が低い

私たちが対象としたのは、SO-101 ロボットアーム（オープンソースの廉価な 6 軸卓上アーム）による「キューブを持ち上げる」タスクです。

本来模倣学習には 50 件程度のデモデータが推奨されますが、私たちは人手を最小限にしたいと考えており 10 件のデータを収集することから出発しました。模倣学習モデル（ACT: Action Chunking with Transformers）はこの 10 件で成功率 10% でしたが、NVIDIA の提供する COSMOS（物理法則を理解した映像生成によりデータを合成する World Foundation Model）や Mimic（少数のデモから大量の合成軌道を自動生成するデータ増幅フレームワーク）によるデータ増幅を適用したところ、成功率は 45% まで向上しました。しかし、デモデータ 10 件という母数では増幅の効果にも限界があり、改善は頭打ちになりました。

これ以上の改善にはデモデータの追加収集か、別のアプローチが必要です。私たちの目的は少ないデータでタスク成功率を上げることなので、データ収集を増やす方向ではなく、強化学習を組み合わせる方向を選びました。

採用手法：RPD（Refined Policy Distillation）

この課題に対して、私たちは RPD（Refined Policy Distillation）論文のアプローチを採用しました。RPD は、大規模な模倣学習モデルの知識を軽量なポリシーに蒸留し、さらに強化学習で改善するフレームワークです。

RPD の基本的な流れは以下の通りです。

蒸留：大規模モデル（VLA 等）の動作知識を、軽量な MLP（Multi-Layer Perceptron）に教師あり学習で圧縮する
PPO（Proximal Policy Optimization） Fine-tune：蒸留済み MLP を初期ポリシーとして、KL ペナルティ付きの強化学習で改善する。KL（Kullback-Leibler）ペナルティは、元のモデルをオンラインで推論し、その出力を参照分布として「蒸留ポリシーから離れすぎない」よう制約をかける

RPD 論文では、教師として大規模 VLA（Vision-Language-Action）モデルをリアルタイムで推論しながら KL ペナルティの参照分布に使います。一方、私たちの実装では VLA の代わりに ACT から蒸留した重み固定 MLP を参照分布として使用しました。この前提の違いが実験結果にどう影響したかは第 2 回で詳述します。

図：RPD 論文のアプローチ（上）と私たちの ACT への適用（下）

ML 開発特有の課題

機械学習パイプラインの構築は、一般的なソフトウェア開発とは異なる課題を持っています。

不確実性が高い：論文との細かな前提の差異などから、論文通りに実装しても動作する保証がない
専門知識が広範：強化学習の理論、シミュレータの仕様、座標系変換など複数のドメイン知識が必要
実験サイクルが長い：仮説→実装→学習→評価のサイクルに時間がかかる

これらの課題は、チームでの開発において「何を作るか」「なぜこの設計にするか」の共有コストを増大させます。

個人で AI と対話しながらコーディングを進める「Vibe Coding」のアプローチでは、こうした構造的な課題を 1 つ 1 つ対話の中で解消しても、その判断やコンテキストが流れてしまい蓄積されません。これでは個人でも知見の蓄積が難しいだけでなく、組織的な研究開発となるとさらに顕著な課題になるのではないかと考えました。

3. AI-DLC 理解と適用判断

AI-DLC とは何か

AI-DLC は、AI を開発プロセス全体に組み込むためのフレームワークです。私たちは TTT を通じて、以下のように理解しました。

AI-DLC の核心は、AI が作業計画を体系的に作成し、人間が意思決定に集中する協働モデルです。具体的には以下のフェーズで構成されます。

Inception フェーズ：ユーザーストーリーの定義、要件の構造化、設計レビュー。AI が専門知識を補完しながら、人間が「何を作るか」を決定する。Inception の最後で分けた Unit ごとに小規模なモブチームを形成する。
Construction フェーズ：Unit ごとのモブチームが詳細設計、実装、テストを並行で進める。AI がコード生成を担い、人間がレビューと意思決定を行う。
Operation フェーズ：デプロイ、運用への移行。

図：AI-DLC の3フェーズ

従来の「Vibe Coding」との違いは、チーム全体で共有可能な構造化ドキュメント（ユーザーストーリー、設計文書、レビューレポート）が生成される点です。これにより、AI と個人の間の暗黙知がチームの共有知に変わります。

なぜ ML 領域に適用したか

AI-DLC の既存事例は Web サービスや業務アプリ開発が中心ですが、私たちは ML 開発への適用をチャレンジしてみました。理由は 3 つあります。

論文→実装のギャップを埋める：研究開発では論文の手法を実装に落とし込む過程で、前提条件の違いや暗黙の仮定が問題になる。Inception フェーズで AI と対話しながら要件を構造化することで、これらの曖昧さを事前に可視化できるのではないかと考えました。
チーム学習の加速：私たちはフィジカル AI に取り組み始めたばかりのチームです。強化学習やシミュレータの専門知識は属人性が高いため、AI-DLC の構造化ドキュメントを通じて、チーム全員が同じ理解水準で議論できる環境を作れると考えました。
実験サイクルの管理：ML 実験は「仮説→実装→学習→評価→修正」のサイクルを高速に回す必要がある。AI-DLC のチェックポイント（Inception→Construction→Operation→評価）が、方針転換の判断基準を明確にすると考えました。

私たちは、要件の構造化と設計レビューというプロセスが、不確実性が高く前提条件の検証が必要な ML 開発に適応できるのではないかと考えました。本記事はあくまで ML 領域への適用事例として、私たちの TTT での経験と見解を中心にご紹介するものです。

4. AI-DLC TTT の概要

以上の背景を踏まえ、TTT で実際に取り組んだ内容をご紹介します。

テーマ設定

具体的な目標は以下の通りです。

人手によるデモデータ収集を最小限に抑えつつ、模倣学習によって習得したロボットアームの動作を、強化学習を用いて自律的にブラッシュアップしていくパイプラインを１つのプロダクトとして捉え構築する

参加者を 2 チーム（チームピンク、チームブルー）に分けました。

強化学習を最終段階とするパイプライン構造は共通ですが、ベースとなるモデルが模倣学習の直接的な出力ではなく RPD 論文に基づく蒸留を経由する設計であり、どのように変換を行うかは未検証でした。

そのため、チームごとでアプローチを決め並行して比較検証する方針としました。

両チームの設計判断の詳細は第 2 回でご紹介します。

事前準備

AI-DLC で効果的に開発を進めるために、以下を事前に準備しました。

学習データ：ACT の実行から得た成功軌道データ 53 エピソード（蒸留の教師データとして使用。人手で収集した 10 件とは別に、ACT がシミュレーション上で成功した軌道を自動収集したもの）
参考論文：RPD、ACT、Knowledge Distillation、PPO の 4 本
設計概要ドキュメント：環境差分、手法の設計思想、データ概要
Amazon EC2 インスタンス：g6e.8xlarge（NVIDIA L40S 48GB）に Isaac Lab（NVIDIA が提供する GPU 並列ロボット学習シミュレーションフレームワーク）環境を構築済み

5. Inception フェーズ：要件構造化（Day 1）

ML パイプラインをプロダクトとして AI-DLC のプロセスに載せた Inception フェーズの具体例を以下に示します。

Inception フェーズでは、フィジカル AI に関する論文や専門情報を Kiro に読み込ませ、要件の構造化とスコープ決定を行いました。

図：チームピンクの Inception の様子、右下に映っているのが SO-101

タスクリストの定義

Kiro との対話を通じて、4 つのタスクリストを定義しました。

表：タスクリスト一覧
#	タスクリスト	優先度
TL-1	蒸留用データの準備（座標系変換+データ整形）	最高
TL-2	MLP の蒸留（教師あり学習）	高
TL-3	PPO Fine-tune（強化学習による改善）	高
TL-4	評価と比較（100 エピソード評価）	中

各タスクリストには具体的な受け入れ基準を設定しました。たとえば TL-1 では「座標変換後の joint_pos_rel の範囲が [-2.2, 1.5] 程度であること」「NaN/Inf が含まれていないこと」など、ML 特有の検証項目を含めています。

ユニット分割とデータフロー設計

パイプライン全体を 3 つの実装ユニットに分割し、データフローを設計しました。

なお、TL-4（評価）は Unit 3 の出力を受けて実行する工程として Unit 3 に含めています。

以下はチームピンクのデータフローとコンテキストマップです。

act_demos.npz (Amazon S3)：座標変換 + データ整形【Unit 1】
    ↓
obs_flat (12次元) + act_flat (6次元)：教師あり学習（蒸留）【Unit 2】
    ↓
distilled_mlp.pt：PPO Fine-tune (KLペナルティ付き)＋評価【Unit 3】
    ↓ model_<iter>.pt：100エピソード実行【Unit 3】
    ↓
evaluation_report.md

図：コンテキストマップ

図：データフロー（act_demos.npz → 座標変換 → 蒸留 → PPO → 評価）

設計レビューの効果

Inception フェーズではモブスタイル（Mob Inception）を採用し、チーム全員が Kiro を囲んで対話しながら設計を進めました。

この過程で Kiro が設計レビューを実施し、実装前に 11 個の不整合を検出しました。

モブスタイルと AI による支援の組み合わせにより、チーム内でのイメージのすり合わせと合意形成にかかる時間を短縮でき、実際にコードに反映できた点は、AI-DLC ならではの効果だと思いました。

発見された不整合の例：

チェックポイント形式の不一致（RSL-RL が期待する actor/critic 分離形式との差異）
入力次元の食い違い（12D と 28D の混在）
アクションスケールの不整合（環境間で /0.5 の変換が必要）

これらを実装前に検出できたことで、Construction フェーズでの手戻りを削減できました。ML 実装では「コードが動くが出力が正しくない」という不具合が起きやすいため、設計段階での整合性チェックは価値が高いと実感しました。

第 1 回のまとめと次回予告

本記事では、AI-DLC をフィジカル AI（ML）領域に適用するに至った私たちの理解と判断、そして Inception フェーズでの要件構造化と設計レビューの実践についてご紹介しました。

Inception フェーズだけで、設計レビューにより 11 個の不整合を検出し、30 以上の構造化ドキュメントを生成しました。

第 2 回では、Construction フェーズでの 2 チーム並行開発の実験結果をご紹介します。チームブルーが当初スコープの断念から AI-DLC のフレームに従って軌道修正し成果を出したエピソードや、蒸留初期化についての知見についてお伝えします。