Amazon Web Servicesの年次イベント「AWS re:Invent 2023」が、2023年11月27日から12月1日まで5日間にわたり米国ネバダ州ラスベガスで開催されました。AWSジャパンから「2023 Japan AWS Top Engineers」に選出された大槻 剛によるファシリテートのもと、同イベントに参加した森田 和明と安斎 寛之の2人の「AWS Ambassadors」に、それぞれの立場やミッションから受けた感想を聞きました。

生成系AIで話題一色、Amazon Bedrockに加えてAmazon Qを発表

大槻：まずは、「AWS re:Invent 2023」（以下、re:Invent）に参加した森田さんに聞きます。現地の様子はどうでしたか。

森田： 現地ではre:Invent全体が生成系AIの話題一色で、この1年間でAWSを取り巻く状況が大きく様変わりしたことを実感しました。事実、キーノートでもAmazon BedrockやAmazon Qに関する多くの発表がありました。私は、お客様のIoTサービスを実現するAWSアーキテクチャの検討、提案、構築を担う立場ですので、AWSの生成系 AI アプリケーションがどのように業務に適用できるのか検証してみることにしました。

大槻：そういえばAmazon Bedrockのプレビューが公開され、森田さんが検証していましたね。その後、Amazon Qが発表されましたが、森田さんはこの2つの生成系AIサービスのすみ分けをどのように捉えていますか。

森田：AWSは生成系AIを3層構造で考えているようです。1層目に言語生成モデルや画像生成モデルなどのインフラ、2層目にAmazon Bedrock、3層目にAmazon Qがそれぞれ位置する形です。
Amazon Qは、AWSが提供しているさまざまなサービスと連携して簡単かつ手軽に生成系AIを使いたいと考えるユーザーのニーズに応えるアシスタント機能です。一方で、独自のアプリケーションに生成系AIの機能を組み込みたい、あるいは何らかの業務に特化した形で生成系AIを使いたいのであれば、Amazon Bedrockをベースに開発を行うのが基本スタイルになると思われます。
ただし、Amazon Qは一般ユーザー用、Amazon Bedrockは開発者用といった完全なすみ分けがなされているわけではありません。AWSでは「Amazon Qによる開発者支援」というメッセージも強く打ち出しています。私たち開発者もユーザーとしてAmazon Qを活用しながら、実際のシステム開発はAmazon Bedrockで行う形になりそうです。

大槻：例えばシステムに内在する脆弱性のリスクをAmazon Qが助言し、その内容を受けてAmazon Bedrockを使った開発に生かすといったイメージでしょうか。

森田：残念ながら具体的なことはまだわかりません。キーノートでは将来的な構想に重点が置かれていたこともあり、「開発者の体験を向上する」といった概念的な話にとどまっていました。詳細な機能が明らかになるのはこれからだと思います。

大槻：森田さん自身は、生成系AIのどんな業務活用に興味を持っていますか。

森田：re:Inventでは、 Amazon Bedrockを用いてIoTアーキテクチャを設計するワークショップも受講しました。この経験を踏まえ、さっそくIoT領域での生成系AI活用について調査・研究を進めているところです。多様なセンサーから収集した数値について、それが異常なのか正常なのか、チャットで問い合わせて誰でも判断できる仕組みを提供できれば、IoTの利用シーンも大きく広がると考えています。

大槻：工場やプラントなどでも役立ちそうです。ただしそのためには生成系AIが不正確な回答をしてしまう、いわゆるハルシネーションを回避するRAG（Retrieval Augmented Generation：検索拡張生成）の技術開発なども重要なポイントとなりますね。

森田：そのとおりです。標準提供されるLLM（大規模言語モデル）のみを用いた一般的なやりとりのみでは対応しきれません。自前のデータをどのように組み合わせて、どのような業務特化を図るのかが検討すべきポイントです。

AWS上に起こった問題を生成系AIでトラブルシュート

大槻：続けて、安斎さんに現地の様子について聞いてみます。生成系AI活用が本格化していく中、エンタープライズITはますます「データがものを言う世界」となっていくと予想しています。必須となるデータの蓄積や分析・活用を支える基盤について、re:Inventではどんな発表がありましたか。

安斎：AWSではデータレイクの中心にAmazon S3を配置するという考え方を示していますが、今回そのデータアクセスを10倍に高速化するAmazon S3 Express One Zoneが発表されました。Amazon S3の主要機能に対応するとともに、Amazon EMRやAmazon Redshift、Amazon SageMaker、そしてAmazon Bedrockからもアクセス可能としています。背景には機械学習や生成系AIでの活用を促す狙いもありそうです。

大槻：インフラエンジニアである安斎さんとしては、re:Inventで顕著になった生成系AIの動きをどのように捉えていますか。

安斎：Amazon Qについて、私もキーノートを視聴するとともに、現地でさまざまな情報を集めましたが、衝撃的だったのはAWS上のトラブルシュートまで行えることです。
お客様から障害発生の連絡を受けた場合、私たちの運用保守チームはどんなエラーが表示されたのかを確認し、収集したログを解析することで原因を特定します。Amazon Qはこの一連の調査を自ら実行し、解決方法まで回答するのです。
さらにAWS上で稼働しているシステムのアーキテクチャが、「AWS Well-Architected」に基づく6本の柱（運用性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）の要件を満たしているかどうか、Amazon Qに問い合わせてチェックすることも可能です。
これらは従来、AWSの高度な技術的知見を持った人にしか回答できない内容でしたが、Amazon Qを使うことで、例えば入社1年目の技術者であっても、AWS Well-Architectedに則ったシステムをお客様に提案・構築できるようになる未来もあり得ると思います。 現在のAmazon Qは新人が即戦力になれるほど技術は 進化していないと思いますが、そのレベルにまで達するのも時間の問題でしょう。

大槻：極端なことを言えば、技術が進めばいずれ サポートエンジニアは不要になるかもしれませんね。

安斎：そんな未来も十分にあり得ると、私も思います。だからこそ、私たちSIerはさらにその先の技術をお客様にご提供するために、 積極的に生成系AIを使いこなしていく必要があります。

大槻：Amazon Qを使用した、AWS Well-Architectedに則った世界標準のサポート提供も必要です。私たちSIerは、生成系AIではまだ実現が難しい分野であっても、お客様に寄り添い、課題をヒアリングして環境を把握したうえで、アプリケーションやIoTデバイスを組み合わせた最適な提案を行うなど、自社の技術力を活用してお客様の課題解決に積極的に取り組んでいかなければ、今後のAI時代では生き残れないと考えます。
その点、森田さんはアプリケーション開発者の目線からAmazon Qをどのように見ていますか？

森田：たしかにAmazon Q によってサポートが効率化する側面もあります。しかし、AWS Well-Architectedに基づいていても、Amazon Q が提案したシステムがコストの面で最適なのかなど、生成系AIの提案を正しく判断する目は必要になるかと思います。そういった観点からAmazon Qにプロンプトを入力するときは、やはり知識や経験が求められます。そのため、「お客様が本当に求めているシステムはこれですよね？」と言える、本質を見極めたSIerならではの提案力が必要です。
今後私たちSIerは、いかに生成系AIを活用して効率的にシステムを構築するかということをミッションとして行動しなければ、世界的な生成系AIのムーブメントに取り残されてしまいます。また従来のサポートエンジニアたちは、生成系AIの活用を前提に、ハイレベルなサポートを提供するべきか、またはサポート以外の部分で付加価値を提供するべきか、＋αの対応が求められるでしょう。

大槻：同感です。私たちSIerには、コンサルタントとしてAWSのアーキテクチャをあるべき方向に導く存在になることが求められますね。AWS Well-Architectedの6つの柱にしても、どの要素を優先すべきか、求めるレベルもお客様の業務によって異なるわけですから。

富士ソフトとしての付加価値をいかに生み出すか

大槻：生成系AIを活用することで、私たちSIerが担っている多くの業務を高速化することや実現できなかったことが可能となると思われます。

安斎：その観点から注目しているのが、マイグレーション作業における生成系AIの活用です。実は私自身もあるプロジェクトでPython2系から3系へのコード書き換えを実施した際に、大変苦労した経験があります。今後、Amazon QのCode Transformation機能を利用できれば、開発者の負荷を大きく軽減できるのではないかと期待しています。

森田：開発者支援をさらに進めていくうえで、AWSのアーキテクチャ設計における生成系AI活用にも期待が膨らみます。先に述べたIoTアーキテクチャを設計するワークショップでは、Amazon Bedrockを用いてソリューションのアーキテクチャ設計図（ダイヤグラム）を生成し、最終的にAWS CloudFormationテンプレートで出力できることを体験しました。

大槻：まだ、荒さはありますがブレストレベルでシステム構成図を吐き出して、テンプレートの生成までできるのは驚きです。ソースコードと画像を吐き出すLLMの世界に可能性を感じました。　「アプリケーションとインフラの気持ちのわかる世界感」に近いている感があります。

森田：もっともワークショップで体験できたのはこのステップまでですから、成果物に対する検証はできていません。それでも複数のアーキテクチャを検討するうえでの要素の一つとして生成系AIを活用できると実感できたのは、非常に大きな収穫です。

大槻：たしかに生成系AIによって導き出されたアーキテクチャをそのまま提案・実装したのでは最適解とならない可能性があります。お客様の多様な課題やニーズに応えるためには、やはりプロフェッショナルの経験や技術力に裏付けられた検討・判断・検証が不可欠で、そこに富士ソフトとしての付加価値を提供していくことが重要です。

安斎：それはビジネス面でも切実な問題です。私の体感ですが、AWSが提唱する移行戦略の7Rでいう「Rehost(リホスト)」、つまり、単純な移行で済むシステムは既に移行が一巡し、移行できていないのはメインフレーム上で運用していた基幹システムなど、非常に難易度の高いシステムばかりのように感じます。そういったシステムは、お客様が移行を望む場合でも単純なリホストは難しく、結局「Retain」(現状維持)を選択するケースが多かったのですが、AWSがリプラットフォームの支援ツールを増やしていることもあり、コストはかかりますがリファクタリングして作り直して欲しいといった要望も増えてきています。

大槻：そういった移行難易度の高いシステムを、例えばAmazon AuroraなどAWSのサーバーレスのアーキテクチャに巻き取ることができれば、富士ソフトならではの高い付加価値の提供につながりそうですね。

新たな一歩を踏み出す

安斎：ユーザーのサポート強化に向けた要望はAWSからパートナー企業にも寄せられており、このほどAWS ITトランスフォーメーションパッケージ for MCP Partner（ITX for MCP Partner）の富士ソフト版「 ITトランスフォーメーションパッケージ for MCP 富士ソフトエディション」をリリースしました。AWSが持つクラウド移行のさまざまなオファリングに加えて、MCP（AWS移行コンピテンシーパートナー）に認定されている富士ソフトが持つビジネスに関する専門知識、各種移行ツール、教育などのサポートを併せて提供することで、AWS上でのシステムのモダナイゼーションを実現するものです。

そしてこの過程でも生成系AIの技術を活用できると考えています。

森田：いずれにしても、私たち技術者がチャレンジを続けることが大切です。キーノートの中でAmazon.com CTO のヴァーナー・ボーガス氏は、コストを意識した持続可能な最新のアーキテクチャを構築するための考え方を「THE FRUGAL ARCHITECT」の7つの規則として発表しました。特に胸に刺さったのが、7番目の「Unchallenged Success Leads to Assumptions（挑戦のない成功は思い込みにつながる）」という規則です。ボーガス氏は「ソフトウェアチームが大きな障害や障害に直面することなく大きな成功を収めると、自己満足に陥る可能性がある。これらの勝利につながった方法、ツール、およびプラクティスを過信する危険な傾向がある」と説きました。

大槻： 2人の報告から、今回のre:Inventで発信された非常に示唆に富んだメッセージが伝わってきました。現業維持は、イノベーションを阻害する要因となってしまうと感じました。生成系AIは、今後も我々の想像をはるかに超えるスピードで進化していくと予想されますが、これに臆することなく新しい技術を取り入れ続けるとともに、お客様の課題に寄り添った提案によって富士ソフトならではの付加価値を生み出し、お客様のイノベーションをプロフェッショナルとしてサポートし続ける必要があるでしょう。だからこそ私たちは新たな道への一歩を踏み出さなければならないのです。
森田さん、安斎さん、本日はありがとうございました。

富士ソフトのAWS関連サービスについて、詳しくはこちら
アマゾンウェブサービス(AWS)

この記事の執筆者