私が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日でした。
💡 補足：AWSは今やLLM（大規模言語モデル）の実行基盤「Amazon Bedrock」を中心に、AIエージェントを本番環境で動かすためのサービスを次々と展開しています。
5つのセッションで気づいたこと
私が聴いた5つのセッションを、印象に残った部分だけまとめます。
基調講演：開発の未来は「AI駆動」
AWSが提唱する「AI-DLC（AI開発ライフサイクル）」という概念が紹介されていました。
簡単に言うと、開発のすべてのプロセスにAIを組み込むという考え方。実際に採用した企業では開発速度が10倍になった、というデータも出ていました。
印象的だったのはこのひと言。
「AIを使うだけでなく、人間の意思設計力を育てる」
AIに任せっぱなしではなく、AIと一緒に考える力を人間側も鍛えていく。その姿勢が大事だと言っていて、妙に刺さりました。
海運業の事例：Text2SQLで問い合わせ対応を自動化
気象・海況情報サービスを提供する企業の事例。
繁忙期に問い合わせが急増してオペレーターが対応しきれない——という課題を、AIエージェントが自然言語を受け取ってSQLを生成・回答するシステムで解決していました。
💡 補足：Text2SQLとは、「先週の売上を教えて」のような自然言語をSQLに変換してデータベースから情報を引っ張ってくる技術のことです。
評価が難しいというのが本音で、88件の評価データを手作業で用意してから本番に進んだという話は現実的でした。「PoCから本番までの道のりが長い」という悩みを抱えている企業は多いと思うので、参考になりました。
モデル選択のフレームワーク：285万の選択肢とどう戦うか
2026年時点でHugging Face Hubに登録されているAIモデルは285万以上。1日に約4,000件の新しいモデルが登録されているそうです。
（※Hugging Face Hub公式データより）
正直「そんなに多いの？」と驚きました。
このセッションでは、膨大な選択肢の中から自社に合ったモデルを選ぶ3ステップが紹介されていました。
Identify：モダリティ（テキスト・画像・音声など）で絞り込み、用途に近いベンチマークで比較
Evaluate：自社データを使って実際に評価する
Optimize：ファインチューニングやプロンプトキャッシングでコスト・速度を最適化
「モデルを選ぶことが壁になっている」という言葉が刺さりました。確かに選択肢が多すぎると、選べなくて止まってしまう。
社内展開の勘所：88%のPoCが本番につながらない
これが一番耳の痛い話でした。
「パイロットケースの88%が本番環境につながっていない」
多くの企業で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の現場展開に悩んでいる方、もしくはイベント参加を迷っている方——ぜひスキで教えてください。来年行くかどうかの背中を押してもらいたいです。
