RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

同じAWS Summit、でも去年とは全然違った — 自社開発1年目の視点

AWS Summit Japan 2026に参加してきました。kazuki kanekoです。

今回で人生2回目のAWS Summit Japanです。

昨年はSIerとして参加していましたが、この1年で自社開発の会社に転職し、今はAIエージェントの開発に関わるチームで働いています。

同じイベントなのに、見え方がかなり変わっていて、自分でも驚きました。

振り返ってみると、変わった理由は「転職したから」というよりも、「自分たちのプロダクトを自分たちで作り、運用し続ける立場になったから」だと思います。特にAIエージェントという、設計判断がそのまま精度や運用コストに跳ね返ってくる領域に関わるようになったことで、技術を見る目線そのものが変わりました。

今回は、そのあたりを書いていきます。

「勉強のため」から「持ち帰るため」に変わった

昨年のAWS Summitは、自分にとってかなり「勉強の場」でした。

  • こういうAWSサービスがあるんだ
  • こういう構成にすると便利なんだ

知らないことを知る。それだけでも楽しかったですし、十分満足していました。

良さそうなセッションを聞いて、気になったブースを見て、知らないサービスを知る。 昨年はそういう回り方をしていました。

しかし、今回は少し違いました。

  • 今やっている業務に役立つ情報はないか
  • 似たような課題を解決している事例はないか
  • 運用を楽にできるものはないか
  • 競合や近い領域のサービスは何に関心を持っているのか

そういう目線で会場を歩いていました。 競合のブースを見に行ったり、同じような事例がないかを探したり。

昨年は、そこまで目的意識を持ってブースを回っていなかったので、自分にとって大きな変化でした。

アウトカムを意識するようになった

目線が変わったのは、セッション選びにも出ていました。

今回は、RDSとAuroraのコスト最適化のセッションを聞きました。 コンピューティング、ストレージ、バックアップの各要素でコストを最適化しながら、パフォーマンスを向上させるという内容です。

以前の自分だったら、たぶん興味を持っていなかったと思います。

昨年までは、コストのことをそこまで強く意識していませんでした。

  • まずは動くものを作る
  • 構成として成立しているかを見る

という感じで、運用コストはその後に考える、くらいの優先度でした。

ただ、今はクラウドサービスを提供している会社で開発しています。

クラウドサービスは作って終わりではなく、ずっと運用し続けるものです。

毎月かかるインフラコストを下げることには、かなりわかりやすい価値があります。

少しの改善でも、長い目で見ると大きな差になります。

なので今回は、

  • その構成、便利だけど毎月いくらかかるんだろう
  • 性能を落とさずに安くできる方法はないだろうか
  • ユーザー数が増えたらどうなるんだろう

という見方をするようになっていました。

将来の自分たちが楽になるかどうかで見ている

開発のしやすさ、運用のしやすさ、変更への強さ。そういう「将来の自分たちが楽になる仕組み」に自然と興味が向くようになっていました。

CI/CDをどう整えると、変更を安全に出しやすくなるのか。 将来ビジネス要件が変わったときに、できるだけ楽に変更できる設計にするにはどうすればいいのか。

SIerにいたときは、こういうことをそこまで自分ごととして捉えられていなかったと思います。

実際にそのシステムを運用するのは自分ではないことも多かったですし、半年後には別のプロジェクトを担当している可能性もありました。

そうなると、どうしても「今のプロジェクトを無難に無事に終わらせること」に意識が向いていました。

一方で、今は自社サービスの開発に関わっています。

開発しづらい仕組みを作れば、あとで困るのは自分たちです。 運用しづらい設計にすれば、問い合わせ対応や障害対応で大変になるのも自分たちです。 逆に、良い仕組みにできれば、その恩恵を受けるのも自分たちです。

ここでいう「楽」は手を抜くという意味ではありません。無駄な作業を減らし、変更の影響範囲を小さくし、リリースを安全にすることです。そういう良い仕組みが、結果的にアウトカムに繋がっていくのかなと思うようになりました。

ただ、SIerの経験があったからこそ見えていることもあると思っています。

SIerでは、自分が書いたコードや設計書を、自分以外の誰かが読み、使い、運用するのが当たり前でした。だから「自分がわかる」ではなく「渡された相手がわかる」を基準にする癖がついていました。 今、AIエージェントの開発をしていても、この感覚はそのまま生きています。別のメンバーが見て意図を理解できるか。半年後の自分が読み返して迷わないか。そういう判断をするとき、SIer時代の「他人に渡す前提で作る」という経験がベースになっていると感じます。

このあたりは、SIerにいたときと自社開発に来てからで、自分の中でかなり変わったところだと思います。

もしこの記事を読んでいるあなたが今SIerにいるなら、一度だけ想像してみてほしいです。自分が作ったシステムを、3年後も自分が使い続けるとしたら、今と同じ設計をするだろうか?と。

自分はその問いに向き合う立場になって、初めて見え方が変わりました。

レベル300のセッションが「ちょうどいい」と感じた

今回、もうひとつ個人的に印象に残ったことがあります。

AIエージェントの精度改善についてのセッションを聞きました。

Architecture・Context・Toolsの各レイヤーで、精度劣化の原因と設計での緩和策を解説するという内容です。

このセッション、レベル300です。 AWS Summitのセッションはレベル200〜400で分類されていて、300は上級にあたります。

以前の自分だったら、たぶんついていけなかったと思います。

ただ今回は、内容が今の自分にちょうどいいと感じられました。

実際にセッションを聞いて、知っていることの確認になる部分と、新しい設計の視点が得られる部分の両方がありました。

特にAgentが使用するToolsはどうしても増えがちだと思っているので、関連性の低いToolsをそもそもAgentに渡さないという設計の観点を手に入れられたのはよかったなと思います。

普段の業務でAIエージェントの開発に関わっているからこそ、このセッションの内容が「知識」ではなく「明日使える設計判断」として入ってきました。

その「ちょうどいい」という感覚自体が、この1年での成長を感じる瞬間でした。

AI一色、そしてフィジカルAIの存在感

昨年もAI関連の展示やセッションは多かったです。

ただ、今年はもう一段階進んでいました。

AWS Summitというより、「AWS AI Summit」と呼んでもいいのではないかと思うくらい、AI一色でした。

体感としては、ほとんどすべてのブースに「AI」という文字が入っていたように思います。 少し大げさかもしれませんが、それくらいAIが前提になっていました。

昨年はまだ「AIをどう使うか」というテーマが多かった印象です。

今回はそれに加えて、

  • AIを業務にこんな感じで組み込んでみました
  • 自社用にカスタマイズしたAIを作りませんか
  • AIを現実世界にどう適用するか

という話が増えていました。

特に印象的だったのがフィジカルAIです。

ロボットやカメラ、現実世界のデータとAIを組み合わせるような展示が多く、AIがソフトウェアの中だけに閉じなくなってきている感じがしました。

昨年の自分は、AIというとPCの中で閉じていて、チャットAI、AIエージェントのようなものをイメージすることが多かったです。

今回は、それに加えて、現実世界に干渉できるハードに乗ったAIが増えてきました。

もちろん、まだすべての企業がすぐに導入できるという話ではないと思います。

ただ、性能面、安全面、コスト面を考えても、企業が現実的に検討できるラインに近づいてきているのかなと感じました。

今までは「研究っぽい」「デモっぽい」と感じていたものが、少しずつ業務に入ってきそうな雰囲気があります。

まとめ

人生2回目のAWS Summitでしたが、去年とはかなり違う見え方をしました。

去年は「知らないことを知る場」だったのが、今年は「持ち帰って使う場」になっていました。コストを意識するようになり、将来の運用を見据えた設計に興味が向くようになりました。

この変化は、自分たちのプロダクトを自分たちで作り、運用し続ける立場になったことから来ていると思います。作ったものの結果を自分たちが引き受けるからこそ、技術の見え方が変わりました。

会場の人もかなり多く、昨年も雨でしたが今年も雨で、それでも体感1.5倍くらいの人がいた気がします。

来年参加するときには、また違う視点で見ている気がします。そのとき自分がどんな問いを持って会場を歩いているのか、今から少し楽しみです。

-->