はじめに 通信業界の主要 MNO 4 社（NTTドコモ、KDDI、ソフトバンク、楽天モバイル）に NTT、ソニーを加えた通信関連事業者の皆様、121 名 / 6 グループの方々が一堂に会したワークショップを、2026 年 4 月 23 日に AWS Startup Loft Tokyo で開催しました。テーマは、ネットワーク開発・運用を変える「カスタム AI エージェント」。本記事では、Autonomous Network 実現に向けた参考アーキテクチャ、NTTドコモ／NTTドコモビジネス両社の事例、Strands Agents・Amazon Bedrock AgentCore のハンズオン、そしてユースケース議論まで、当日の内容をレポートします。「自社のどの業務に、どう適用できるか」を考えるヒントとして、お役立ていただけますと幸いです。 ワークショップ参加者の集合写真 AWS ジャパンでは、こうしたテーマに向き合う場として 2025 年 11 月に「 通信ネットワーク運用向け AI エージェントワークショップ 」を開催し、参加された通信事業者の皆様から大きな反響をいただきました。今回はその第 2 回として、対象を ネットワーク開発・運用全般 に広げ、開発工程での AI エージェント活用も新たに取り上げました。 通信業界のネットワーク開発・運用では、より高品質で柔軟なサービスを継続的に提供するために、設計・構築・障害対応・改善といった多岐にわたる業務を効率化することが求められています。一方で、ネットワークの拡張や複雑化に従来のオペレーションだけで追従することは難しくなりつつあり、自動化・高度化・自律化の取り組みが加速しています。その実現手段の 1 つとして AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する業務ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった共通の課題があります。本ワークショップは、こうした課題に対して「学ぶ・知る・触る・議論する」を 1 日に凝縮した場を提供するものです。 アジェンダ 時間 セッション 登壇者 13:00–13:10 オープニング Yuki Miyazaki (AWS / SA) 13:10–14:15 セッション1：複雑な開発/運用業務でAIエージェントを活用しよう Yuki Miyazaki (AWS / SA) 13:10–14:15 事例登壇：AIとGitOpsを用いた5Gコアネットワークの設計構築自動化への取り組み NTTドコモ 宮本氏 13:10–14:15 事例登壇：ルータ統合型AIエージェントによるネットワーク開発の取り組み NTTドコモビジネス 門脇氏 14:30–16:00 セッション2：AWSで実現するカスタムAIエージェント（Strands Agents / Amazon Bedrock AgentCore ハンズオン） Atsushi Okamoto (AWS / SA), Yuta Tanaka (AWS / SA) 16:15–17:50 セッション3：ネットワーク開発運用エージェントを触ってみよう（ハンズオン＋ユースケース議論） Naohito Yoshikawa (AWS / SA) 17:50–18:00 クロージング Yuki Miyazaki (AWS / SA) 18:00–19:30 ネットワーキングパーティ — セッション1：複雑な開発/運用業務でAIエージェントを活用しよう 宮崎 友貴 Solutions Architect Autonomous Network 参考アーキテクチャ 本セッションでは、通信業界のオペレーションの標準化団体である TM Forum が定義する Autonomous Network （自律ネットワーク）の自律レベル L4/L5 の実現に向けて、AI エージェントとデータの活用が不可欠であることを解説しました。まず、AI エージェントが自律的な行動を行えるようになった基礎技術の変遷と、ネットワークの開発者や運用者に近い動きが実現可能であることを説明し、AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは AI エージェント × 自律的な判断に必要なデータであり、ネットワークのトポロジーや時系列データ、構成情報、設計書、手順書といったネットワークデータと AI エージェントを組み合わせることで、ネットワークの設計や構築、運用開始後の障害検知から根本原因分析といった複雑なオペレーションを自律的に行える仕組みが構築できることをお伝えしました。最後に、グローバルおよび国内の通信事業者における AI エージェントの活用事例をご紹介し、Autonomous Network が既に商用で実現しつつあることを参加者の皆様にお伝えしました。 本セッションの資料（PDF）をダウンロード 事例登壇：NTTドコモ 「AIとGitOpsを用いた5Gコアネットワークの設計・構築自動化への取り組み」 宮本 克真 氏 株式会社 NTTドコモ コアネットワークデザイン部 AI エージェントを使ったネットワーク設計構築自動化の事例として、株式会社 NTTドコモ コアネットワークデザイン部の宮本克真氏にご登壇いただきました。 NTTドコモでは、国内で初めて 5G コアネットワーク（5GC）を AWS 上に構築し、2026 年 2 月より商用サービスを開始 しています。従来の 5GC 設計・構築プロセスでは、膨大なマニュアルや仕様書の確認、多種の設定ファイル作成、煩雑な構築手順の実施に約 4〜6ヶ月を要し、需要増への迅速な追従が課題でした。 AI×GitOps による設計・構築の自動化 そこで AI エージェントと GitOps を組み合わせた設計・構築自動化を導入しました。AI エージェントがマニュアルや仕様書をナレッジベースとして参照し、インフラ設定・アプリ設定・5GC コンフィグなどの設定ファイルを自動生成します。生成されたファイルは Git で管理され、CI/CD パイプラインを通じて自動デプロイされます。アーキテクチャとしては Amazon Bedrock AgentCore 上のオーケストレータエージェントが、Git 担当・インフラ担当・アプリ担当・コンフィグ担当の各専門エージェントを統括する構成です。各エージェントは Strands Agents SDK で構築され、Amazon Bedrock Knowledge Base を MCP 経由で参照します。デモでは、オペレータが「5GC NF を構築して」と指示するだけで 5GC が構築される様子をご覧いただきました。 AI×GitOps の活用による効果 この取り組みにより設計から構築までのリードタイムを約 80% 短縮することに成功し、工数削減と共に人為ミスの低減にも繋がりました。今後は、試験自動化や保守・運用領域などへの拡大を目指しています。 事例登壇：NTTドコモビジネス「ルータ統合型AIエージェントによるネットワーク開発の取り組み」 門脇 伸明 氏 NTTドコモビジネス株式会社 ルータ連携 AI エージェントのネットワーク開発への活用事例として、NTTドコモビジネス株式会社の門脇氏にご登壇いただきました。同社では、映像伝送ネットワークサービスを提供しており、全国の専用線網にて数百台規模のルータを運用しています。従来、突発的なネットワーク設定変更（例：ファイアウォール強化）が必要な際には、エンジニアがマニュアルや仕様書を確認し、ルータの状態を手動で調査した上で設定を作成・検証し、さらにレポート資料を作成するまでに約 6 日を要していました。 AIエージェントによるルータ設定検討支援 そこで、ルータの MCP を活用してルータと直接連携する AI エージェントを導入しました。エンジニアが設定要件を自然言語で指示するだけで、AI エージェントがルータから必要な情報を自律的に収集し、既存の設定や環境に合わせてコンフィグを設計・生成します。さらに、コンフィグ投入後の動作確認やレポートの作成まで自動化することで、所要日数を 6 日から 1 日へと大幅に短縮しました。また、AI エージェントのメリットとして、自律的にルータから自動で必要情報を収集するため、ルータ情報をプロンプトで与えずにルータの専門知識さえあれば活用できる点と、AI エージェントの振る舞いの定義をコードではなく自然言語で記述できるため可読性が高く実装が容易である点が紹介されました。 AIエージェント開発環境 AWS の構成としては、社内のセキュリティ規約に基づき閉域接続（AWS コンソール以外はインターネット接続なし）で構築することで安全な AI エージェント運用を実現しています。今後は、試験自動化やメーカー問い合わせの自動化など、さらなる AI エージェント活用のユースケース拡大を目指します。 セッション2：AWSで実現するカスタムAIエージェント — Strands Agents と Amazon Bedrock AgentCore 本セッションの前半では、カスタム AI エージェントを「素早く構築する」ことと「安全に大規模運用する」ことの両方を実現する AWS のアプローチとして、 Strands Agents と Amazon Bedrock AgentCore を最新アップデートとともにご紹介しました。 岡本 篤志 Solutions Architect まず AI エージェントの構成要素を、推論を担うモデル・振る舞いを定義するプロンプト・外部システムと連携するツールの 3 つに整理した上で、これを本番稼働させるにはメモリ管理やオブザーバビリティ、セキュリティ、スケーラビリティなど多くの周辺機能の実装が必要になることを示しました。Strands Agents はこの「構築」の負担を大幅に軽減するオープンソース SDK であり、わずか数行のコードでエージェントを実装できます。MCP をはじめとする多様な接続方式による外部システム連携や、エージェント同士を組み合わせるマルチエージェント構成にも対応しています。さらに、複雑なマルチステップタスクにおける再現性や品質の一貫性を確保する仕組みとして Agent SOP （自然言語で記述するワークフロー定義）を紹介し、チーム間での知見共有と品質統一が可能であることをお伝えしました。 続いて、「大規模運用」を担う Amazon Bedrock AgentCore について解説しました。任意のフレームワークやモデルで構築したエージェントを本番環境にデプロイし、会話コンテキストの維持、アクセス制御、実行トレースの可視化、品質の継続的な評価まで、エンタープライズグレードの運用基盤を包括的に提供します。下図のように、通信ネットワーク運用の文脈では、ネットワーク機器や構成管理システムとのツール連携、インシデント対応ナレッジの長期記憶としての蓄積・活用が可能であり、ネットワーク運用の自律化に向けた基盤として特にフィットすることを示しました。 通信ネットワークにおける Amazon Bedrock AgentCore の価値 その後、Strands Agents と Amazon Bedrock AgentCore の両方の実装を体験できるワークショップを実施させていただきました。 田中 優多 Solutions Architect このワークショップでは、Strands Agents 及び Amazon Bedrock AgentCore の機能を最大限に活用した、包括的で本番環境に対応したカスタマーサポートエージェントを構築しました。単なるチャットボットではなく、複雑なカスタマーサービスのワークフローを処理し、複数の企業システムと連携し、同時に数千人の顧客にサービスを提供できるような高度なエージェントシステムです。 まずは、Strands Agents をローカル環境に実装することをご体験いただきました。幾つかの用途特化機能をツールとして定義 → 独自のデータをナレッジベースとして連携 → エージェントの役割を自然言語で定義といった簡易なステップで、AI エージェントを作成できることを確認しました。 Lab1 の構成 ただしこの状態のプロトタイプには、以下のような課題がある状態でした。 永続的なメモリがない — エージェントは過去の会話を忘れる スケーラビリティがない — ローカル開発環境でのみ実行 こうした課題を解決するソリューションとして、Amazon Bedrock AgentCore の実装へと進みました。数ある AgentCore モジュール群の中でも、 AgentCore Memory と AgentCore Runtime に焦点を当てて、コードベースでその設定やデプロイ方法をご体感頂きました。AgentCore Memory を実装することで、ユーザとのやり取りの記憶や好みの自動学習、長期間のコンテキスト維持が可能になります。そして AgentCore Runtime の活用により、常に変化する需要に合わせて自動的にスケールするサーバーレスソリューションが実現できます。数多くのフレームワーク、モデル、プロトコルをサポートし、開発者は最小限のコード変更でローカルプロトタイプを本番対応ソリューションに変換できます。 Lab4 の構成（〜Runtime 上へのデプロイまで） これらをお客様の手でカスタムで作り上げることにより、業務に即した実用性の高い AI エージェントが実装できることを、ご体感いただきました。 ワークショップ会場の様子 本セッションの資料（PDF）をダウンロード セッション3：ネットワーク開発運用エージェントを触ってみよう 吉川 直仁 Solutions Architect 前段のセッション2で学んだ Strands Agents と Amazon Bedrock AgentCore の知識を、通信ネットワークというドメインに当てはめるとどうなるか、を体感していただくのが本セッションの位置付けです。前回ワークショップでは保守運用業務にフォーカスしましたが、今回はそこに 開発・構築工程 のシナリオを 2 本追加し、参加者の皆様に「物理ネットワークの設計・開発者」「5G コアネットワークの設計・開発者」「ネットワーク保守運用者」の 3 つの立場を順に体験していただきました。 シナリオ① ネットワーク機器の設定、構築、検証 シナリオ ① は、複数台のルータから構成されるネットワークの Config 設定・接続確認・バグ検証の自動化です。実機の設定情報、大量のログ、仕様書を参照しながら対応する必要がある業務を、AI エージェント × ナレッジ（SOP）の組み合わせで実装します。 デモ動画：シナリオ ①（ネットワーク機器の設定・構築・検証） オペレータが「ネットワークの状態を確認して、疎通不可の原因を調査・修正してほしい」と自然言語で指示するだけで、AI エージェントが SOP に従って ① 構成情報の確認 → ② ヘルスチェック → ③ Config 修正 → ④ レポート作成までを自律的に実行する様子をご覧いただけます。 シナリオ② コアネットワークのパラメータ設計、構築 シナリオ ② は、5G コアネットワークのパラメータ設計とデプロイです。複数の NF（Network Function）から構成されるコアネットワーク網に対するネットワークスライス追加を、Strands Agents が IaC とパラメータを生成し、Git を介してインフラ（Amazon EC2）からその上で動くアプリ、さらにアプリのパラメータ設定までを一気通貫でデプロイする流れを体験していただきました。 デモ動画：シナリオ ②（コアネットワークのパラメータ設計・デプロイ） オペレータが「新しいネットワークスライスを追加してほしい」と自然言語で指示するだけで、AI エージェントが現在の構成を確認し、SOP に従って IaC とパラメータを生成、Git を介してインフラ（Amazon EC2）→アプリ→アプリのパラメータ設定までを一気通貫でデプロイする様子をご覧いただけます。 シナリオ ③ は前回ワークショップでもご紹介した、ネットワーク障害発生時のアラーム分析・切り分け・措置レコメンド・チケット起票です。今回はマルチエージェント構成を前回からアップデートして実演しました（構成の詳細は 前回ブログ をご参照ください）。 シナリオ ①／② デモアプリケーション構成図 シナリオ ①／② のデモアプリケーションは、Strands Agents で実装したエージェントを Amazon Bedrock AgentCore Runtime 上で動かし、AgentCore Memory（STM/LTM）と AgentCore Observability も統合した構成です。エージェントは利用者からの一つの指示に対し、ネットワーク機器の操作・IaC のデプロイ・Git への変更反映といった複数の外部アクションを自律的に組み合わせて実行し、本番運用を想定した記憶・観測の仕組みも合わせて体験いただけるようにしています。 通信業界における SOP とは？ 通信業界では、仕様書、詳細設計書、ベンダードキュメント、手順書、パラメータ設計規則など、独自フォーマットの大量のドキュメントが存在します。本ハンズオンではこれらを SOP（Standard Operating Procedure） という形式に標準化し、Markdown ファイルとして AI エージェントに与えることで、「人間も AI も同じ手順を読み、同じ成功基準で評価できる」状態を作り出しています。SOP の生成・評価・修正自体も AI エージェントで自動化でき、エラーの有無・ポリシー順守・効率性などを別の SOP 評価エージェントで自動チェックする運用も実演しました。 本セッションの資料（PDF）をダウンロード ユースケース議論ワークショップ ユースケース議論ワークショップの様子 セッション 3 のハンズオンを終えた後半 30 分は、参加者の皆様にご自身の業務に当てはめて考えていただくユースケース議論の時間としました。テーブルごとに AWS SA も加わり、模造紙と付箋を使って「AI エージェントに任せたい業務は何か」「任せるために必要なデータ・指示は何か」「自担当で導入するならどんなアーキテクチャになるか」の 3 つの問いを順に議論いただきました。 各テーブルから出てきたアーキテクチャ図と付箋を AWS 側で見渡して整理すると、参加企業・担当領域は様々であるにもかかわらず、いくつかの共通した観点が浮かび上がってきました。 1. 業務領域ごとに専門エージェントを切り出す発想は共通 多くのテーブルで、AI エージェントを 1 つの巨大な万能エージェントとして描くのではなく、業務領域ごとに専門エージェント（パラメータ設計／Config 設定／検証／監視／チケット起票など）を切り出す構成が描かれていました。配置の仕方はテーブルによって、上位のオーケストレータが束ねる階層型、業務フローに沿ったパイプライン型、業務ごとに独立した並列型と様々でしたが、「役割を分けて、それぞれに SOP を持たせる」という発想は多くのテーブルで共通していました。 2. 既存の社内ツール・データとどう接続するかが、最大の現実論点 多くのテーブルで挙がったのが「既存の社内ツールとの接続」です。チケット管理、ナレッジ共有、ログ分析、構成管理、コミュニケーション基盤、構成情報 DB ― 各社それぞれの現場で長く使われてきたツール群があり、AI エージェントをどう “そこ” に組み込むかが、ハンズオンを「自社で動くもの」にするための最大の現実論点として浮かび上がっていました。 3. AI に任せきれない判断ポイントの設計が、各社共通の論点になっていた SOP の切り替え判断、Human-in-the-loop による承認・エスカレポイント、検証環境から商用環境への段階的適用 ― 「AI エージェントに任せきれない判断をどう設計に組み込むか」が、開発・運用業務における AI エージェント活用の論点として、複数のテーブルで共通して議論されていました。あるテーブルのホワイトボードには、エスカレポイントに 赤字で「ココが課題」 と書き込まれた付箋が貼られており、本番運用を見据えたときの設計上の難所がここに集約されていることを象徴する一場面でした。 技術を学ぶだけで終わらせず、自社・自業務への適用イメージを「絵」として描き、共通の課題感を他社の方と共有するところまで踏み込めたことが、本セッションの大きな狙いでした。各テーブルで描かれたアーキテクチャや書き出された課題の数々は、AWS として今後の支援活動を組み立てる上で、非常に貴重なインプットとなりました。 参加者の声 「AWS のイベントにドコモ／KDDI／ソフトバンク／楽天／ソニーと多くのネットワーク事業者が揃っていることに驚いたし、AWS が通信業界に深く浸透していることを実感した。」 「具体的なイメージが湧く内容でよかったです。具体化に向けて引き続きご相談させていただければと思います。」 「AI エージェントを作るためのハンズオンが丁寧に作られていて短時間でも内容が理解できました。」 「出来上がった AI Agent を体験するよりも、作る過程で AWS を使うメリットをもっと体験したかった。」 「テスト環境を触れる期間がもう少し長いと、チームメンバーにも共有しやすい。」 おわりに 本記事では、「通信事業者向けカスタム AI エージェントワークショップ」についてレポートしました。事例登壇・ハンズオン・ユースケース議論を通じて、参加された皆様にとってカスタム AI エージェントの活用イメージが具体化される一日となっていれば幸いです。また、各テーブルでの議論や他社・他部署の方との交流を通じて、業界共通の課題感を共有する貴重な機会にもなったのではないかと考えております。ご参加頂いた皆様、本当にありがとうございました。本ワークショップを通じて得られた知見やフィードバックは、今後の AWS の支援活動にも活かしてまいります。ネットワーク開発・運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。 著者紹介 宮崎 友貴 (Yuki Miyazaki) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 岡本 篤志 (Atsushi Okamoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 田中 優多 (Yuta Tanaka) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。 吉川 直仁 (Naohito Yoshikawa) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。

CTO の川口( id:dmnlk )です。 最近、社内で「とりあえず HTML にして置いておくね」という会話を当たり前のように耳にするようになりました。きっかけは、社内 HTML をホストするだけのささやかな環境をひとつ用意したことです。たったそれだけのことなのに、気づけばエンジニア以外のメンバーまで使い始め、社内の情報の流れそのものが変わっていきました。 この記事では、なぜそんな環境を作ったのか、どう作ったのか、そして実際に何が変わったのかを書きます。 きっかけ：AI が生むドキュメントは「流通するが、読まれない」 AI コーディングが日常になって、社内には実装計画 (plan) や設計メモのようなドキュメントが一気に増えました。Claude Code などに計画を立てさせると、その plan ファイルがそのまま成果物として共有されます。これ自体はとても良い変化でした。 ただ、困ったことがひとつありました。 流通はするのに、人間が読むのに適していない のです。 Markdown やテキストのまま Slack や Git に流れてくる とにかく長く、構造はあるはずなのにプレーンテキストだと頭に入ってこない リンクや図が活きず、コードブロックと地の文が地続きで視線が迷子になる 「内容は良いはずなのに、最後まで読む気にならない」。AI が書いたドキュメントが増えれば増えるほど、この摩擦が社内のあちこちで起きていました。 なぜ Notion ではなく HTML だったのか 「読みやすく共有したいだけなら Notion に貼ればいいのでは」とも考えました。実際、しばらくはそうしていました。けれど、どうもしっくりきませんでした。 自由度が足りない 。レイアウトや見せ方が Notion の枠に収まってしまう 凝った表現や、AI に「読みやすい形に整形して」と頼んだときのアウトプットを、そのまま再現できない 結果として「読みやすくしたいから貼り直す」手間が発生し、誰もやらなくなる 一方、AI に「この plan を読みやすい HTML にして」と頼むと、見出し・目次・強調・配色まで含めて、驚くほど読みやすい 1 枚の HTML を出してくれます。 HTML はそのまま渡せばそのまま表示できます 。この「変換を挟まない素直さ」が、Notion にはない強みでした。 足りないのは「その HTML を、社内の人だけがサッと見られる置き場所」だけです。それなら作ろう、と考えました。他社事例を多く見るタイミングでもあり、自作することに決めました。 最近、社内でHTMLで共有する事が多くなってきたので、空き時間にサクッと社内でHTMLを共有するサービスを作った。公開範囲を柔軟に設定できたり、Slackで簡単に共有できたり、esaやNotionに埋め込みで貼り付けれたり、かゆいところに手が届く感じで非常に便利。 Goodpatch社内のみです。 pic.twitter.com/iQPEXY5kT0 — 土屋尚史 / Goodpatch (@tsuchinao83) 2026年6月3日 ssss-app.com https://t.co/yBJmpJId6P — 鈴木慎吾 / TSUMIKI INC. (@shingo2000) 2026年6月15日 作ったもの：GCS + Cloud Run + IAP 構成はできるだけ薄く、運用に手がかからないことを最優先にしました。 保管: Google Cloud Storage (GCS) — HTML と付随アセットをそのまま置くだけです。バケットにアップロードすれば、それが 1 つのページになります。 配信: Cloud Run — GCS の中身を返すだけの薄いサーバーを 1 つ置きます。フルマネージドなので、アクセスがなければゼロまでスケールインし、コストもほぼかかりません。 認証: Identity-Aware Proxy (IAP) — この環境の肝です。Cloud Run の手前に IAP を噛ませ、社内の Google Workspace アカウントを持つ人だけがアクセスできるようにしました。社内の人はすでに Google にログインしているので、URL を開くだけで（追加ログインなしで）中身が見えます。逆に、社外の人にはそもそも到達できません。 昔は IAP を利用するには Load Balancer などが必要で大変でしたが、今は Cloud Run に IAP を直接設定できるため、低コストで実現できました。 ポイントは、 認証を自分たちで実装していない ことです。社内ドキュメントのホスティングで一番こわいのは「うっかり世界に公開してしまう」ことですが、そこを IAP に丸ごと預けられます。「Google にログインできる社内の人だけ」という、最初から欲しかったアクセス制御が、ほぼ設定だけで手に入りました。 あとは「HTML をアップロードしたら社内 URL が発行される」という体験さえ整えれば、書き手は中身に集中できます。 何が起きたか：エンジニアから、全職種へ 最初の使われ方は、ごく素朴なものでした。 エンジニアが plan を読みやすくするため だけに使っていたのです。AI が出した実装計画を HTML にして置き、URL を共有します。レビューする側も「これは読む気になる」と言ってくれます。それだけでも十分に元は取れていました。 変化が面白くなったのは、ここからです。 その URL を見たエンジニア以外のメンバーが、「自分の資料もこうやって置けるの?」と気づき始めました。やがて 財務・経理のメンバーが、自分たちの資料を HTML にして共有する ようになっていきました。スプレッドシートや長い文章ではなく、要点が整理された 1 枚の読みやすいページとしてです。 気づけば、社内の情報共有のデフォルトが少し変わっていました。 「資料を作る＝読みやすい 1 枚にまとめて、URL で渡す」が自然な選択肢になった 部署をまたいで「あの URL 見た?」という会話が増えた AI に整形を任せられるので、 読みやすい資料を作るコスト自体が下がった 「読みやすく共有する」ことのハードルが下がると、共有される情報の量と質が両方とも上がります。情報の流れが変わるとは、こういうことかと実感しました。 運用してわかったこと 薄く作って正解でした。 凝った CMS にせず「HTML を置くだけ」にしたことで、書き手は自由に表現でき、運用側もほぼメンテ不要です。 認証を IAP に寄せたのは精神的に大きいです。 社内ドキュメントを置くうえで「公開事故が構造的に起きにくい」という安心感が、気軽さを支えています。 置きっぱなしのドキュメントが肥大化しないよう、デフォルトでは 7 日で自動削除されるようにしました。 API を用意し、CI 環境からも受け付けられるようにして、パフォーマンスレポートなどを CI で更新できるようにしました。 MCP も簡易的に作り、Claude Code や Codex などから手軽にアップロードできるようにして、敷居を下げました。 重要なこと 社内で広く使われるようになった一因は、システムの名前だと思っています。キャッチーな名前にすると、社内の文脈に浸透しやすくなります。元々「ファイルをポンと置きたい」くらいの気持ちで始めたので、サービス名は「pon」にしました。すると社内では「資料を pon しました」といった形で話題に上がるようになり、一気に広まったように思います。社内ツールの名前は、想像以上に重要です。 まとめ 社内に HTML をホストする環境を作ったのは、「AI が生む読みづらいドキュメントを読みやすくしたい」という小さな動機からでした。GCS + Cloud Run + IAP という薄い構成で、認証は IAP に任せきりです。技術的には派手さのない仕組みです。 それでも、エンジニアの plan 共有から始まった使われ方がエンジニア以外の職種にまで広がり、社内の情報の流れそのものを少し変えていきました。「読みやすく共有するコストを下げる」だけで組織の情報の流れはこんなに変わるのか——というのが、作ってみての一番の発見です。 似たような「ドキュメントは増えたのに読まれない」課題を抱えている方の参考になれば嬉しいです。

本記事は 2026 年 6 月 3 日に AWS Migration & Modernization Blog で公開された Consistent Code Modernization at Scale with AWS Transform custom Knowledge Items を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 はじめに AWS Transform custom (ATX) は、コードモダナイゼーションを大規模に自動化します。各リポジトリで AI コーディングアシスタントを個別に実行する場合と異なるのは、ATX が 学習する ということです。各実行からパターン、修正、エッジケースを再利用可能なナレッジとして蓄積するため、変換は実行するたびに高速化し、信頼性も向上します。 Java 8 のリポジトリを数百個抱えていたり、非推奨 API を使った Spring Boot 2.x アプリ、あるいは AWS Graviton で動かせるにもかかわらず x86 に縛られたワークロードがある場合、こうした技術的負債こそがチームの開発速度を妨げている原因です。手動でのアップグレードはスケールしません。数百のリポジトリにまたがる Java のアップグレードは単調な繰り返し作業であり、この規模の繰り返しは一貫性の欠如を招きます。 AWS Transform custom は Agentic AI を活用してこれらの変換を自動化します。一般的なシナリオに対応する AWS マネージドな変換 が同梱されているほか、独自の カスタム変換定義 を構築することも可能です。改善の蓄積は ナレッジアイテム によって実現されます。ナレッジアイテムとは、各実行からパターン、修正、エッジケースを蓄積する再利用可能なアーティファクトであり、将来の実行で自動的に適用されます。 本記事では、サンプルの Spring Boot プロジェクトを Java 8 から 26 にアップグレードし、ナレッジアイテムがどのように生成・管理されるかを確認し、同じ変換をリポジトリのポートフォリオ全体に適用する方法をご紹介します。 開始方法 実際のプロジェクトで Java 8 から 26 へのアップグレードを実行し、Transform custom の動作を確認しましょう。 前提条件 AWS Transform custom へのアクセス が有効化された AWS アカウント ATX CLI の インストールおよび設定 Java 8 以上、Java 26、Maven のインストール（サンプルプロジェクトのビルド用） Git のインストール Java と Maven の基本的な知識 シナリオ 本記事では aws-appconfig-java-sample を使用します。これは Java 8 と Maven で構築された Spring Boot アプリケーションで、非推奨の Java API や古いフレームワークバージョンに依存している、典型的なモダナイゼーション候補です。 セットアップ リポジトリをクローンします: git clone --depth 1 https://github.com/aws-samples/aws-appconfig-java-sample.git ディレクトリに移動します: cd aws-appconfig-java-sample ローカル依存関係をインストールします: mvn install:install-file \ -Dfile=./movie-service-utils/built-library/0_1_0/movie-service-utils-0.1.0.jar \ -DgroupId=com.amazonaws.samples \ -DartifactId=movie-service-utils \ -Dversion=0.1.0 \ -Dpackaging=jar ビルドが通ることを確認します: mvn clean compile -DskipTests 変換定義 変換定義 (Transformation Definition) は、Transform custom に 何を どのように変換するかを指示する再利用可能なレシピです。ソースとターゲットのスタック、変換パターン、コーディング規約、そしてエージェントに従わせたい組織ナレッジが含まれます。AWS は Java のバージョンアップグレードなど一般的なアップグレード向けに マネージド変換定義 を提供しています。組織固有のニーズに合わせて 独自の変換定義を構築する ことも可能です。 変換定義の実行 インタラクティブモードと自律モードの 2 つから選択できます。インタラクティブモードでは、ツール使用の確認、計画のレビュー、ステップの承認が求められます。自律モード ( -x ) は確認なしですべてを実行するモードで、CI パイプラインや一括実行で使用します。 ここでは -x で自律モード、 -t ですべてのツールを信頼する設定で実行します。 -t は注意して使用してください。すべてのコンテキストでエージェントが任意のツールをトリガーすることを許容したくない場合もあります。 CLI コマンドリファレンス にオプションの一覧があります。 AWS/java-version-upgrade は、Java プロジェクトを Java 26 にアップグレードするマネージド変換定義です: atx custom def exec -n "AWS/java-version-upgrade" -p . -c "mvn clean compile -DskipTests" -x -t -g "additionalPlanContext=The target Java version to upgrade to is Java 26" 上記コマンドの出力を以下の画像に示します。 AWS/java-version-upgrade 変換定義は Java 26 をターゲットとし、アップグレードの全範囲を処理します。 javax.security.cert の移行、Spring Boot のメジャーバージョンアップグレード、テスト依存関係のモダナイゼーション、ビルドツールの更新など、POM ファイル内の Java バージョン番号を変更するだけではありません。 エージェントは依存関係グラフ全体を分析し、すべての変更を一括で適用し、コンパイルとテストの両方を検証した後、すべてを単一のアトミックなコミットとして記録しました。14 件の個別の変更（依存関係のアップグレード、API の移行、ビルドツールの更新）がすべて一緒に検証されました。実行ログには、実行内容、遭遇した問題（Spring Boot 3.2.12 の ASM が Java 26 と非互換、Mockito の ByteBuddy の問題）、およびそれらの解決方法が記録されています。 14 件の変更、1 つのアトミックコミット、完全なビルドとテストの検証。しかしエージェントはコードの変更を生成しただけではありません。何がうまくいき、何がうまくいかなかったかも観察しました。この観察こそがナレッジアイテムの源であり、別のリポジトリに対する次の実行が今回よりも高速になる理由です。 結果の確認 変更は専用のローカル Git ブランチに反映されます。Transform custom はリモートにプッシュしません。標準的な Git ツールで確認できる完全な監査証跡が得られます。コミットメッセージにはすべての変更が詳細に記載され、実行ログには遭遇した問題と解決方法が記録されます。インタラクティブモード（ -x なし）で実行した場合は、実行開始前に計画をレビュー・修正でき、検証ステップや外部ツールチェックなど必要なゲートを追加できます。 変換によるすべての変更を確認するには: git diff main diff --git a/pom.xml b/pom.xml --- a/pom.xml +++ b/pom.xml @@ -5,7 +5,7 @@ <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> - <version>2.0.5.RELEASE</version> + <version>3.5.14</version> </parent> diff --git a/src/main/java/.../movies/MoviesController.java b/src/main/java/.../movies/MoviesController.java --- a/src/main/java/.../movies/MoviesController.java +++ b/src/main/java/.../movies/MoviesController.java @@ -1,5 +1,5 @@ -import javax.validation.Valid; +import jakarta.validation.Valid; diff --git a/src/main/java/.../utils/Security.java b/src/main/java/.../utils/Security.java --- a/src/main/java/.../utils/Security.java +++ b/src/main/java/.../utils/Security.java @@ -1,5 +1,5 @@ -import javax.security.cert.*; +import java.security.cert.*; 代表的な 3 つの変更を示します。Spring Boot が 2.0.5.RELEASE から 3.5.14 に（エージェントは 3.2.12 の ASM が Java 26 のクラスフォーマットをサポートしないことを検出し、3.5.14 にアップグレードしました）、 javax.validation.Valid が jakarta.validation.Valid に移行、 javax.security.cert が java.security.cert に置き換えられました。完全な diff には Mockito と JUnit の依存関係更新、Gradle ビルドのモダナイゼーション、AWS SDK BOM のアップグレードも含まれます。 変更内容に問題がなければ、マージします: git checkout main git merge <transformation-branch-name> 変換の改善 最初の実行は動作します。面白くなるのは 2 回目からです。 リファレンスとナレッジアイテム Transform custom が変換精度を向上させる手段は 2 つあります。 リファレンス は、変換定義の作成時にアップロードする移行ガイド、API 仕様、コードサンプルなど、事前に提供するドキュメントです。即座に有効化され、完全にお客様の管理下にあります。 ナレッジアイテム は、実際の変換中に何が起こったかを観察することで、システムが自ら学習したものです。Transform custom は各実行後に非同期でナレッジアイテムを生成し、無効状態で開始し、お客様がレビューして承認した場合にのみ適用されます。 リファレンスが出発点を設定し、真に価値が積み上がるのはナレッジアイテムによってです。本記事の残りでは、このナレッジアイテムに焦点を当てます。 ナレッジアイテムの管理 どのナレッジアイテムを有効にするかは、お客様が制御します。承認なしに有効化されることはありません。 これまでに蓄積されたものを一覧表示するには: atx custom def list-ki -n "AWS/java-version-upgrade" 以下のナレッジアイテムは、先ほどの変換実行で生成されたものです。エージェントはプロジェクトのアップグレード中にこれらの問題に遭遇し、自動的に記録しました: KI - 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 - DISABLED Title: Mockito 5.14.2 ByteBuddy incompatible with Java 26 Description: Mockito 5.14.2 fails to mock standard library classes like ArrayList under Java 26. Error message indicates ByteBuddy cannot modify ArrayList and related collection classes. Mockito 5.15.2 resolves the compatibility issue. Fix: Upgrade Mockito to 5.15.2: <!-- Before - ByteBuddy in Mockito 5.14.2 can't handle Java 26 --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.14.2</version> <scope>test</scope> </dependency> <!-- After - Mockito 5.15.2 supports Java 26 bytecode --> <dependency> <groupId>org.mockito</groupId> <artifactId>mockito-core</artifactId> <version>5.15.2</version> <scope>test</scope> </dependency> KI - adb1b8e6-4199-4d4d-964c-1eab5c94de1a - DISABLED Title: Spring Boot 3.2.12 ASM lacks Java 26 class format support Description: Spring Boot 3.2.12 uses ASM library version that cannot parse Java 26 class files (major version 70). Test execution fails with "Incompatible class format" during classpath scanning. Spring Boot 3.5.14 or newer required for Java 26 compatibility. Fix: Upgrade Spring Boot to 3.5.14: <!-- Before - ASM in Spring Boot 3.2.12 can't parse Java 26 classes --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.12</version> </parent> <!-- After - Spring Boot 3.5.14 includes ASM with Java 26 support --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.5.14</version> </parent> どちらもデフォルトでは DISABLED です。有効化する前にレビューを行います。各説明には、何が変更されたか、なぜ重要か、症状、そして正確な修正方法が記録されています。これらは、Java 26 アップグレード中にエージェントが遭遇した 2 つの異なるカテゴリの問題です: Mockito/ByteBuddy: バイトコード操作の失敗。Mockito にバンドルされた ByteBuddy が Java 26 のクラスフォーマットを処理できず、テスト時のモックが実行時に失敗する。 Spring Boot ASM: クラスフォーマット解析の失敗。Spring Boot の ASM ライブラリがクラスパススキャン中に Java 26 のバイトコードをスキャンできず、テスト実行が完全に破綻する。 どちらもコンパイルだけでは検出できません。アップグレード後のコードに対してテストを実行する必要があり、そのためビルド検証コマンドが重要になります。 ナレッジアイテムを有効化するには: atx custom def update-ki-status -n "AWS/java-version-upgrade" --id 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 --status ENABLED atx custom def update-ki-status -n "AWS/java-version-upgrade" --id adb1b8e6-4199-4d4d-964c-1eab5c94de1a --status ENABLED すべてのナレッジアイテムを Markdown にエクスポートしてオフラインでレビューすることもできます: atx custom def export-ki-markdown -n "AWS/java-version-upgrade" Markdown へのエクスポートは、チームがオフラインでナレッジアイテムをレビューしたり、スプリント計画や技術的負債レビューのセッションでどれを有効化するかを議論したりする場合に便利です。自分のコードベースに対して適用範囲が広すぎるナレッジアイテムがあれば、無効化してください。次回別のリポジトリで実行した際に、より限定的な修正パターンが生成されることがあります。そちらを有効化すれば、徐々に汎用的なアドバイスではなく、組織の実コードに即したナレッジアイテムを取捨選択していけます。 なお、これらのナレッジアイテムはお客様の組織に固有のものであり、他のお客様とは共有されません。 学習ループ Transform custom の価値はイテレーションにあります。実行し、エージェントが学習した内容を蓄積し、有効化し、再度実行する。先ほどの 2 つのナレッジアイテムを有効化した状態で、同じ変換定義を 2 番目のリポジトリに対して実行します: git clone --depth 1 <second-repo-url> cd <second-repo> atx custom def exec -n "AWS/java-version-upgrade" -p . -c "<build-command>" -x -t 最初のリポジトリでは、ビルド検証コマンドとして -DskipTests を渡しましたが、エージェントはアップグレードの検証のためにテストも独立して実行しました。そのテスト実行中に、反復的に解決した 2 つの問題に遭遇しました: Mockito 5.14.2 が標準ライブラリクラスのモックに失敗。バンドルされた ByteBuddy が Java 26 のバイトコード操作を処理できなかったため、エージェントは 5.15.2 にアップグレード。 クラスパススキャン中に「Incompatible class format」でテスト実行が失敗。エージェントが最初に行った Spring Boot 3.2.12 へのアップグレードでは、Java 26 のクラスファイル（メジャーバージョン 70）を解析できない ASM バージョンが使用されていた。3.5.14 にアップグレード。 Transform custom はこれらを観察し、先ほどレビューしたナレッジアイテムとして蓄積し、修正内容を記録しました。エージェントは問題を解決し、その経験から再利用可能なナレッジを生成しました。 これらを有効化して 2 番目のリポジトリで実行します: atx custom def update-ki-status -n "AWS/java-version-upgrade" --id 7f36cfd4-2926-44fa-8fa5-eb5384e65c77 --status ENABLED atx custom def update-ki-status -n "AWS/java-version-upgrade" --id adb1b8e6-4199-4d4d-964c-1eab5c94de1a --status ENABLED Mockito 5.14.2 または Spring Boot 3.2.x を使用して Java 26 をターゲットとする後続のリポジトリでは、Transform custom がテスト実行前に事前に修正を適用します。Mockito は 5.15.2 にアップグレードされ、Spring Boot は 3.5.14 に引き上げられます。テストは通過し、手動介入は不要です。 以前のリポジトリではデバッグと手動修正が必要だったことが、その後のすべてのリポジトリで自動的な修正になります。各実行はより高速で信頼性が高くなり、次の実行のために新しいエッジケースを蓄積します。 具体的に説明します。この変換定義を 1 週間で 15 の Spring Boot リポジトリに実行するとします。4 番目のリポジトリまでに、Mockito 5.14.2 を使用するすべてのプロジェクトに対して事前にアップグレードが適用されます。6 番目のリポジトリまでに、Java 26 をターゲットとする古い 3.x バージョンを検出するたびに Spring Boot 3.5.14 へのバージョンアップが自動的に行われます。10 番目のリポジトリでは、カスタム @Query アノテーションを持つリポジトリで Hibernate 6 のダイアレクト変更が問題になるかもしれません。すべての実行で新しいナレッジアイテムが生成されるわけではなく、エージェントが何を発見するかに依存します。しかし生成されたものをレビューし、望ましいものを有効化すれば、後続のすべての実行がその恩恵を受けます。15 番目のリポジトリは、最初のリポジトリよりもクリーンな変換になります。なぜなら、それ以前の 14 個分の蓄積された経験を持っているからです。 大規模な実行 本記事では 2 つのリポジトリを扱いました。大規模に展開する場合は、同じ変換定義をポートフォリオ全体に適用します。これが Learn-Scale-Improve フライホイール です。各実行が新しいナレッジアイテムを蓄積し、後続のすべての実行がシステムのこれまでの学習内容から恩恵を受けます。20 番目のリポジトリでは、最初のリポジトリで手動介入が必要だったパターンを自動的に処理します。 数百のリポジトリにまたがる実行には自動化が必要です。 aws-transform-custom-samples リポジトリには 2 つのオープンソースアプローチがあります: Bash 自動化 : ワークステーションから並列実行、進捗ダッシュボード、自動リトライを備えて実行します。 コンテナベース実行 : AWS Batch + AWS Fargate 上で数百から数千のリポジトリに対して実行します。セットアップの手順は AWS DevOps ブログの記事 をご参照ください。 クリーンアップ 変換はローカルで実行され、AWS リソースはプロビジョニングされません。クリーンアップするには: cd .. rm -rf aws-appconfig-java-sample AWS Batch でスケール実行を行った場合は、 コンテナベース実行の README にあるクリーンアップ手順に従ってください。 まとめ ナレッジアイテムはポートフォリオ全体で蓄積されます。各実行はエージェントが遭遇した内容に応じて新しい学びを生成する可能性があり、有効化したものが後続のすべての実行を高速化します。単発のリファクタリングスプリントではなく、今日の負債削減が明日のデリバリーを直接加速させる継続的なループが得られます。 ぜひお試しください: ご自身のリポジトリをクローンし、 AWS/java-version-upgrade 変換定義を実行して、生成されるナレッジアイテムを確認してみてください。組織固有のパターン（フレームワーク移行、コーディング規約の強制、依存関係の置き換え）がある場合は、 カスタム変換定義を作成 し、いくつかのリポジトリで実行して学習ループの動作を確認してみてください。 AWS Transform custom ドキュメント AWS マネージド Java アップグレード変換定義 : ご自身のコードベースでお試しください 独自の変換定義を作成 して組織固有のパターンに対応 aws-transform-custom-samples : 大規模実行のためのスクリプトとインフラ 著者について Jean-Baptiste Guillois Jean-Baptiste は、AWS のシニアスペシャリストソリューションアーキテクトであり、アプリケーションの移行とモダナイゼーションを専門としています。エンタープライズおよびソフトウェアベンダーとの 20 年以上の経験を持ち、AI を活用したサービスを使ってお客様がアプリケーションをより効率的にモダナイズできるよう支援することに情熱を注いでいます。 Gengis Birsen Gengis Birsen は、AWS の AI/ML および Generative AI スペシャリストソリューションアーキテクトです。エンタープライズのお客様と連携し、エージェント、評価、強化ファインチューニング、検索に重点を置いて、現在の生成 AI に関する課題に取り組んでいます。仕事以外では、現在の趣味は娘と一緒に Connetix のビルドを共同設計することです。