【AWS Summit Japan 2026】AI時代こそ設計が命。「AIに優しい」システム設計とObservability

はじめに

こんにちは、株式会社メンバーズのDevOps Leadカンパニー ZHANG（チョウ）です。普段はクラウド/DevOps領域の若手エンジニアとして、クラウド環境の構築や運用に関わる業務を担当しています。AWS Summitのようなイベントは、新しい技術や実際の活用事例に触れられるので、毎回楽しみにしています！

先日、AWS Summit Japan 2026に参加してきました。今回はその中でも、下記のセッションで、自分が印象に残った点をまとめます。

セッション名：AIが開発／運用しやすいクラウドサーバーレスの視点から考える設計原則

セッションPDF資料はこちらから参照できます。

今年のAWS Summitでまず感じたのは、AI関連のセッションがとても多いことでした。私自身も日々の業務でAIを使って開発する機会があり、便利さや面白さを感じる場面はたくさんあります。ただ、セッション一覧を見たときは、正直なところ「AIの話題が多い……！」と少し圧倒されました。どれも面白そうではあるのですが、数が多い分、どこから聞けばよいか迷ったのも本音です。

実際にいくつかのセッションを聞いてみると、AIへの切り口はそれぞれ違っていました。RAGの構成や生成AIのデモなど、具体的な技術や実装例など内容も多くありました。その中でこの講演ー「AIが開発／運用しやすいクラウドサーバーレスの視点から考える設計原則」は、AIエージェントを開発や運用の流れにどう組み込むか、またそのためにコード構造やクラウド設計をどう整えるべきか、少し広い視点で話されていた点がとても印象に残りました。

すべての情報をAIに渡せばよいわけではない

AIツールを使うとき、以前の私は「情報の背景をできるだけ多く渡した方が、AIも正しく理解してくれる」と思っていました。コードやログ、補足説明などをたくさん渡せば、よい回答が返ってくるのではないかと考えていたからです。

ただ、この講演を聞いて、情報は多ければ多いほどよい、というわけではないと改めて感じました。人間の頭でも、一度に整理されていない情報をたくさん渡されると、どこが重要なのか分かりにくくなります。AIも同じで、必要な情報と不要な情報が混ざると、判断がぶれやすくなるのだと思います。講演では、コーディングエージェントが作業中に読み込んだファイル、ログ、実行結果、検索結果などが、少しずつコンテキストに入っていくという話がありました。一つひとつは必要そうに見えても、整理されないまま増えていくと、AIにとってはノイズになってしまいます。

これは普段AIツールを使っている中でも、たしかにあるなと感じました。

たくさん説明したつもりなのに、かえって意図と少しずれた回答になることがあります。一方で、「今やりたいこと」「すでに確認したこと」「今回は考えなくてよいこと」を先に整理して渡すと、回答がかなり安定しやすいです。そのため、AIを活用する上で大事なのは、単に情報をたくさん渡すことではなく、AIが判断しやすい形に情報を整理して渡すことだと感じました。

AIにとって分かりやすい境界を作る

特に印象に残ったのは、インターフェース（interface）をコンテキスト（context）の圧縮として捉える考え方です。

最初は「コンテキストを圧縮する」と聞くと、長い内容を短く要約することをイメージしていました。しかし、それだけではなく、ソフトウェア設計そのものによって、AIが理解しなければならない範囲を減らす、という話がありました。

例えば、よいインターフェースがあれば、そのモジュールが何をするのか、インプットとアウトプットは何か、どのように使えばよいのかが分かります。内部の複雑な処理をすべて読まなくても、外から見える使い方が明確であれば、AIもそのモジュールを扱いやすくなります。この考え方には、とても納得感がありました。AIのために特別なことをするというより、本来のソフトウェア設計の基本が、AIエージェントが開発に関わることでより重要になっているのだと思います。

コード境界や責務が分かりやすければ、AIはどこを修正すべきか、どの機能を呼び出すべきか、どこをテストすべきかを判断しやすくなります。逆に、処理が複雑に混ざっていたり、境界が曖昧だったりすると、AIがたくさんコードを読んでも、正しく判断するのは難しくなります。この点から、AI 時代になると設計が軽くなるのではなく、むしろより大事になるのだと感じました。

細かく分ければよいわけではなく、適切な粒度が大事

また、Monorepoやpackageの分け方、Lambdaの設計粒度についても触れられていました。例えばLambdaでは、たくさんの処理を一つのfunctionにまとめると管理はしやすい一方で、中身が大きくなりすぎて理解しづらくなります。逆に、endpointごとに細かくLambdaを分けすぎると、一つひとつのfunctionは小さくなりますが、IA権限、依存関係、デプロイ管理、コールドスタートなど、別の複雑さが出てきます。

そのため、大事なのは「できるだけ細かく分けること」ではなく、業務の境界、権限、依存関係などを見ながら、AIと人間の両方が扱いやすい粒度にすることだと理解しました。Monorepo についても同じです。関連するコード、共有ライブラリ、IaC、設定ファイル、ドキュメントなどをまとめて管理できるため、AIエージェントが必要な情報を参照しやすいという利点があります。

AIが検証・調査しやすい環境を作る

続いて、Lambda Web Adapterや運用エージェントの話もありました。AIが自分で確認し、次の行動につなげられる環境が必要だという話です。AIがただコードを生成するだけではなく、実行して、失敗を確認して、修正するというフィードバックループを回せるかどうかは、今後とても重要になると理解しました。

運用面でも同じことが言えます。運用エージェントはログ（logs）、メトリクス、トレース、アラートなどを見て異常を調査できますが、ただ大量のログを渡せばよいわけではありません。ログが分散していたり、形式がばらばらだったり、サービス境界が分かりにくかったりすると、AIも原因を追いづらくなります。

そのため、ログは構造化されていて、サービス名、トレースID、業務に関係する情報、error情報などが含まれている必要があります。メトリクスも技術的な数値だけではなく、業務上の影響が分かる情報があると、より判断しやすくなります。これまでオブザーバビリティ（observability）は、人間が障害調査をしやすくするためのものとして考えていました。しかし、AIエージェントが運用に関わるようになると、ログやメトリクスはAIが調査しやすい形であることも重要になります。つまり、これからのオブザーバビリティは、人間だけでなくAIエージェントにとっても読みやすいものである必要があるのだと感じました。

おわりに

AI時代だからこそ、地に足のついた設計が大事になる

今回の講演セッションを通じて、AIを開発や運用に取り入れることについて、より現実的に考えることができました。AIエージェントを活用するためには、AIが理解しやすい構造、検証しやすいテスト、調査しやすいログ、管理しやすいアーキテクチャ境界を、人間が用意する必要があるという点が印象に残りました。

AI時代になると、設計の重要性が下がるのではなく、むしろより見えやすくなるのだと思います。AIが安定して動けるかどうかは、モデルの性能だけでなく、システムがAIと人間の両方にとって理解しやすく、扱いやすい形になっているかにも大きく左右されます。

今後の業務でも、AIに何かを依頼するときは、「AIがこのタスクをできるか」だけでなく、「自分はAIが正しく判断できる情報や環境を用意できているか」も意識していきたいです！AIを便利なツールとして使うだけでなく、AIと一緒に開発・運用していくために、こちら側の設計も見直していく必要があると感じられる内容でした。