私がAWS Summitに参加して持ち帰った考え方

こんにちは、AIについて情報発信をしている貫徹まるです！
先日AWSサミットに参加してきました。

AWSは基礎の勉強をちょっとしたくらいで、実務では使ったことがない。
そんな私が参加した理由は
AWSの深掘りではなく、各社がAIをどう現場に落としているかを知りたかったから。

結果、入場まで1時間並んで、5つのセッションを聴いて、思っていた以上のものを持ち帰れた気がしています。

入場まで1時間——これがAWSサミットか

会場に到着してまず思ったのが、人の多さでした。

ビジネスで参加している方、個人で来ている方、学生っぽい方。いろんな人が列を作っていて、入場まで約1時間かかりました。

そして会場に入ると、最初に目に入ったのが基調講演の会場。
会場全体の3分の1くらいのスペースを使って、何百人もが着席してひとりの登壇者の話を聞いている。

「……これがAWSサミットか」と思いました。規模が違う。

正直なところ、参加前は「勉強熱心な人たちが集まる技術系イベント」くらいのイメージでした。でも実際は、企業の意思決定層から現場のエンジニアまで、AIの「今」を知りたくて集まっている場所だった。

「AWSのイベント」なのにAIの話ばかりだった

企業ブースを歩いても、セッションのテーマを見ても、
AIに関係しない話がほとんどない。

「AWSのユーザーイベントだからインフラやクラウドの話が多いかな」と思っていたのですが、完全に予想が外れました。AIの活用事例、AIエージェントの社内展開、モデルの選び方——そういったテーマが並んでいて、むしろAIカンファレンスに来た感覚すらありました。

トレンドがAIになっているのではなく、AWSそのものがAIプラットフォームになっている。それを肌で感じた1日でした。

5つのセッションで気づいたこと

私が聴いた5つのセッションを、印象に残った部分だけまとめます。

基調講演：開発の未来は「AI駆動」

AWSが提唱する「AI-DLC（AI開発ライフサイクル）」という概念が紹介されていました。

簡単に言うと、開発のすべてのプロセスにAIを組み込むという考え方。実際に採用した企業では開発速度が10倍になった、というデータも出ていました。

印象的だったのはこのひと言。

AIに任せっぱなしではなく、AIと一緒に考える力を人間側も鍛えていく。その姿勢が大事だと言っていて、妙に刺さりました。

海運業の事例：Text2SQLで問い合わせ対応を自動化

気象・海況情報サービスを提供する企業の事例。

繁忙期に問い合わせが急増してオペレーターが対応しきれない——という課題を、AIエージェントが自然言語を受け取ってSQLを生成・回答するシステムで解決していました。

評価が難しいというのが本音で、88件の評価データを手作業で用意してから本番に進んだという話は現実的でした。「PoCから本番までの道のりが長い」という悩みを抱えている企業は多いと思うので、参考になりました。

モデル選択のフレームワーク：285万の選択肢とどう戦うか

2026年時点でHugging Face Hubに登録されているAIモデルは285万以上。1日に約4,000件の新しいモデルが登録されているそうです。
（※Hugging Face Hub公式データより）

正直「そんなに多いの？」と驚きました。

このセッションでは、膨大な選択肢の中から自社に合ったモデルを選ぶ3ステップが紹介されていました。

• Identify：モダリティ（テキスト・画像・音声など）で絞り込み、用途に近いベンチマークで比較

• Evaluate：自社データを使って実際に評価する

• Optimize：ファインチューニングやプロンプトキャッシングでコスト・速度を最適化

「モデルを選ぶことが壁になっている」という言葉が刺さりました。確かに選択肢が多すぎると、選べなくて止まってしまう。

社内展開の勘所：88%のPoCが本番につながらない

これが一番耳の痛い話でした。

多くの企業でAIの試験導入（PoC）はできても、実際の業務に定着しないという現実。

原因として挙げられていたのが、
「一部のチームしか使えない」
「活用の広げ方がわからない」
「評価が難しくて本番展開に踏み切れない」の3つ。

そしてそれに対する打ち手として
「AI-BPR（AIを前提にビジネスプロセスを再設計する）」という考え方が紹介されていました。
「AIを既存業務に追加するのではなく、AIありきで仕事の流れを作り直す」という発想の転換です。

開発未経験者の社内事例：2日かかる処理を10秒に

最後のセッションが、ある意味一番心に残りました。

DM業界の事務職チームが、開発経験ゼロからAIエージェントを作って2日かかっていた処理を10秒に短縮したという事例。マキタ（電動工具メーカー）の情報企画部の方が、1.5ヶ月でRAGとMCPを組み合わせたシステムを作り上げた事例。

どちらにも共通していたのが、「まずやってみた」という姿勢でした。

「AIツールは非エンジニアにとって0を1にするツールになっている」という言葉がすごく良くて。
コードが読めなくても、AIに聞きながら作れる。その実例が目の前にあった。

AIは「使う段階」をとっくに超えている

1日を通じて強く感じたのはこれです。

登壇した企業の多くは「AIを導入するかどうか」という段階を超えていて、
「どう現場に定着させるか」
「どう評価して改善するか」
「エージェントをどう展開するか」
という次の問いに取り組んでいた。

「自分にはまだ早い話かな」と思いながら聴き始めたんですが、意外とAWS固有の話より「AIをどう使うか」という普遍的な話が多かったんです。

だから思ったより自分ごととして受け取れた。

私が持ち帰った3つのポイント

最後に、自分の仕事に持ち帰れると思ったことを3つだけ書きます。

① PoCで終わらせないために「評価の設計」が必要

どのセッションにも共通していたのが、「評価をどうするか」という問い。AIを本番展開するには、良し悪しを判断できる仕組みを先に作っておく必要がある。評価なき改善はできない。

② モデルはツール、選び方にフレームワークを使う

285万ものモデルから直感で選ぶのは無理。「モダリティで絞る→用途に近いベンチマークで比較→自社データで評価」という手順を先に決めると、選択で止まらなくなる。

③ 「AIを使う」より「AIと一緒に業務を設計する」

「AIエージェントにこの作業をやらせよう」ではなく、「そもそもこの業務の流れをAIありきで作り直したら？」という問い方。AI-BPRという概念は、SI的な仕事の仕方とも相性が良さそうだと思いました。

AWSを知らない私が参加したAWSサミット。持ち帰ったのはAWSの知識ではなく、
「AIの現場定着に向き合っている人たちのリアルな試行錯誤」でした。

並んだ甲斐はありました。

同じようにAIの現場展開に悩んでいる方、もしくはイベント参加を迷っている方——ぜひスキで教えてください。来年行くかどうかの背中を押してもらいたいです。