はじめに

こんにちは。クラウドソリューション事業部の常井です。

今年初めてAWS Summitに2日間参加させていただきました。話には聞いていましたが、想像以上の盛り上がりに驚きました。

最寄りの駅から少し歩くと長蛇の列ができており、入場前からAWS Summitの熱量を感じました。（今年は例年よりも入場者が多かったそうです。）

会場では多数のブースやセッションがあり、2日間があっという間でした。

今回はAWS Summitに参加して感じたこと・学んだことを書いていきたいと思います。

AI一色だったAWS Summit

Summitに参加してまず思ったことはAI関連のセッションが非常に多かったことです。

どのセッションタイトルにも、必ずと言っていいほど「AI」というワードが入っていました。

ブースを見てもAIと関連するものがほとんどであったように感じます。中でもPhysical AIについては、専用のエリアがあり、Physical AIの盛り上がりについてもリアルに感じました。

日頃からAIを活用した開発を進める中で感じてはいましたが、AIはもはや新しい技術ではなく、活用することが大前提になっているということを改めて体感しました。

印象に残った2つのセッション

数年前は「AIをどう活用するか」が話題の中心だったように思います。

しかし今回のSummitに参加して、「AIを使うこと」は前提となり、その次の課題にどう向き合うかというフェーズなのかなと感じました。

AIが能力を発揮しやすい設計や開発プロセス、組織をどう作るのか。AIを活用するからこそ見えてきた課題に対して、アーキテクチャや組織設計の観点からアプローチするセッションが印象に残りました。

① AIが理解しやすい設計

AI が開発／運用しやすいクラウド サーバーレスの視点から考える設計原則[CNS449]

• https://pages.awscloud.com/rs/112-TZM-766/images/R04_0626_CNS449_v1.pdf
• https://summitjapan.awslivestream.com/jpn-cns449/live/

このセッションで新鮮だったのは、AIにドキュメントを読ませれば良いという話ではなく、AIが理解しやすいアーキテクチャを設計するという考え方です。

AIは多くのコンテキストを扱えますが、情報量が増えすぎるとコストや精度の面で課題が生まれることや、ドキュメントと実装は乖離しやすいことにも触れられていました。そのため、ドキュメントだけに頼らずサービス境界（各サービスの責務範囲）を明確にしたり、インターフェースだけで役割を理解できるように設計したりと、ソフトウェア構造そのものを工夫することが必要になるとのことでした。

各情報をどこで管理すべきかというスライドもありました。何をドキュメントに残し、何をコードに表現すべきかの判断基準として参考になりそうです。

• 現在の振る舞い → インターフェース、型、OpenAPI仕様書、テストコード
• どう動くか → コード
• いつ誰が → Git/GitHubのログ
• なぜそうなっているか → ドキュメント・コードのコメント

また、開発だけでなく運用エージェントのことも考慮して調査しやすいログ設計をすることも大事だという話も同様に印象に残りました。

エージェントから見た運用しやすい構造の要件として以下が示されていました。

• 依存関係のあるすべてのログ、メトリクスが探索可能であること
• サービス間のアーキテクチャ境界が明確であること
• コンテキストロットしない領域（トークン数）で作業ができること

AI時代だから特別な設計原則が必要になったというより、これまで良い設計とされてきた考え方が、AI時代ではさらに重要になっているのではないかと感じました。

特に印象的だったのは、「コンテキストをドキュメントではなくアーキテクチャで圧縮する」という考え方です。AIが理解するための情報をドキュメントで補うのではなく、設計そのものに表現していくという発想は、とても新鮮でした。

まだセッションの内容を十分に理解しきれているわけではありませんが、設計を学ぶ上で意識していきたい視点だと感じました。

② AI時代でも人間に求められるもの

AI でコードは書けても、レビューできる人がいなくなる ― ソフトウェア開発における自動化のパラドックス[AIM223]

• https://summitjapan.awslivestream.com/jpn-aim223/live/

AIによって実装の生産性は向上しているが、全体としての生産性はそれほど向上していない（AI活用のパラドックス）・レビューできる人が育たなくなるという課題について紹介されていました。

その要因として以下の2点が紹介されていました。

• 要因A: スキル侵食の悪循環
  1. 何らかのツールによって業務・作業が簡単に実現でき、その結果に満足する
  2. 本来業務によって育つスキルが育たなくなり、評価・レビューができなくなる
  3. 評価ができないためツールに依存する
• 要因B: オーナーシップの欠如
  1. コントロール：自分がコントロールしている感覚
  2. 深い知識：端から端まで知っている感覚
  3. 自己投入：時間・思考・労力が染み込んでいる感覚

  心理的なオーナーシップは上記の3つの経路によって生まれるとのことでした。
  3つが揃った時、人は品質と責任を引き受ける

しかし、AIが書いたコードでは「自分がコントロールしている」「端から端まで知っている」「時間をかけて作り上げた」という感覚が生まれにくく、結果としてオーナーシップが欠如しやすいという指摘でした。

これらの話を聞いた時、自分のことを言われているようでドキッとしました。

私自身、AIに相談しながら実装を進めることがほとんどです。だからこそ、AIの提案を十分に理解し、自分で妥当性を判断できているかを常に意識し続けることの大切さを改めて感じました。

AIを適切に活用し続けるためには、自分で理解し、判断する経験を積み続けることが欠かせないのだと思います。

AIに任せられることが増える時代だからこそ、「なぜその設計・実装なのか」を一度立ち止まって考え、自分の言葉で説明できる状態を目指していきたいと思いました。

共通して感じたこと

それぞれ異なるテーマのセッションでしたが、共通していたのは「AIをどう使うか」ではなく、「AIを前提に開発のあり方を見直す」という考え方でした。

AIと協働することが当たり前になるにつれ、AIが活用されるフェーズは実装や調査にとどまらず、今後さらに広がっていくと思います。一方で、人間にはAIが能力を発揮しやすい環境や基盤を整える役割、そしてAIの提案を評価・判断する役割が求められるようになっていると感じました。

「AIに何をやらせるか」だけでなく、「AIが力を発揮できる土台をどう設計するか」という視点が、これから問われていくのではないかと思います。

おわりに

今回のAWS Summitを通じて、AIを前提にした設計や判断力の重要性を改めて実感しました。

私自身も、AIを活用しながら、設計そのものにコンテキストを表現する意識や、AIの提案に対して「なぜそうなのか」を自分の言葉で説明できる力を磨いていきたいと思います。

また、AWS Summitのようなイベントは、新しい技術だけでなく、実際に現場で得られた知見や考え方に触れられる貴重な機会でもあると感じました。今後もこうしたイベントに参加し、学びを実践につなげていきたいです。

余談：

以前から気になっていたServerlesspressoを体験してきました。
1回目では注文までいけませんでしたが、2回目のトライで無事美味しいコーヒーをいただけました☕️

ブースの横にはアーキテクチャ図も掲載されており、Step Functionsなどを使って注文フローを回していることが分かり、勉強になりました。