本セッションの狙いと構成

山﨑：このセッションでは、3社の皆様からビジネスの中心を担うシステムのアーキテクチャと、その設計の考え方について貴重なお話をいただきます。今回は各社のさまざまな課題を解決してこられたアーキテクチャをご紹介いただきます。AWSの私がレビューするというのはおこがましいので、本日は皆様に可能な限り自社の取り組みをお話しいただく時間にしてまいります。

その中から、私たちが共通して学べるアーキテクチャに関する要素を考えてみたいと思います。本日は特にWell-Architected＝良い設計とは何か、というところで、レジリエンス（信頼性）をフィーチャーします。また、組織とアーキテクチャの関係や、開発範囲を意思決定するときの考え方といった要素も取り上げていきます。

【KDDIアジャイル開発センター】AIエージェント「A-BOSS」

山﨑：最初に、KDDIアジャイル開発センターの伊野瀬さんから、営業活動を支援するAIエージェント「A-BOSS」のアーキテクチャについてご紹介いただきます。

伊野瀬：今話題のAIエージェントアプリをご紹介します。A-BOSSは、営業本部長の「本部長業務をAIにやらせよう」という意見から開発が始まりました。営業の方々は日々たくさんの提案資料を作って持っていきます。そうした準備や戦略立案といった部分を、本部長ではなくAIがサポートしてくれるエージェントです。

主な機能は3点あります。まず「企業リサーチ」。営業の方々がお客様を訪問する前に、その企業の最新動向をAIが自動で調査してまとめてくれます。次に「提案アシスト」。会議の音声データなどをアップロードすることで、議事録を作成したり、提案書のたたき台まで作成してくれます。最後に「提案書レビュー」。作った提案書をアップロードすると、本部長の代わりにAIがチェックして改善点をアドバイスしてくれます。

技術スタックについてご説明します。いわゆる王道の構成です。フロントエンドはReactとViteでS3にホスティングし、バックエンドはPythonでFastAPIを使っています。

伊野瀬：実はこのアーキテクチャは二層構造になっています。FastAPIのAPIサーバーがルーティングを担当し、その裏でECSワーカーたちがBedrockを呼んでAI処理を行う形です。

セキュリティ対応についてですが、KDDIグループは大企業なので、エンタープライズレベルのセキュリティが求められます。そこでWAFでIP制限をかけ、社内の特定のIPアドレスからしかアクセスできないようにしています。さらにVPCオリジンを用いてバックエンドを完全に閉域化し、外部から直接アクセスできないセキュアな環境を実現しています。

伊野瀬：非同期処理について説明します。AIエージェントは並列でたくさんの処理を行います。非同期処理を実現することで、CPUやメモリなどのシステムリソースを効率的に活用し、スループットを増やしてユーザー体験を高めています。

PythonのライブラリであるCeleryで非同期処理を実現し、タスク管理にはAmazon ElastiCache for Valkeyをキーバリューストアとして使用。タスクキューと処理結果を管理しています。

伊野瀬：多くのリクエストをさばくために非同期処理を導入しています。どのWorkerが処理するかを気にするのではなく、キューにメッセージを投げ込み、手が空いているWorkerがメッセージを取りに行く処理をしています。ECSオートスケーリングで負荷に応じてWorker数も自動調整されます。

伊野瀬：実はA-BOSSは学習をします。利用者が「今回の出力がイマイチだった」「もっとこうしてほしい」というフィードバックを送ると、Langfuseという監視ツールに蓄積されます。その裏側でLLMが日々フィードバックを要約し、DynamoDBに保存して、次回そのユーザーが使うときには自動的にプロンプトに反映します。

フィードバックをすべて良しとしてしまわないかという課題もありますが、汎用的かつ有用なフィードバックのみをLLMに選別してもらうことで対応しています。まさに成長するAIです。

伊野瀬：生成AIアプリの特徴として、BedrockのClaudeモデルは需要が高く、エラーも起きやすいです。そこでクロスリージョン推論を活用し、エラー発生時にはアジアからアメリカ、ヨーロッパと世界旅行するような形でリトライを行います。それでもダメな場合は、自動でモデルのグレードを落として再度リトライします。

コストとレイテンシーを節約するため、軽い処理にはHaikuを、重い処理にはSonnetを使い分けています。

伊野瀬：PoC立ち上げ時は自律型ReActエージェントを使用していました。しかし、必要なタスクを漏らすことが多かったんです。そこでエージェンティック・ワークフローを導入し、処理フローをある程度プログラムで制御するようにしました。

例えば提案書レビュー機能の場合、競合調査タスク、企業調査タスク、提案改善タスクといった複数のタスクを並列実行し、最後に結合して結果を出力します。エージェントとワークフローの良いとこ取りをしたアプローチです。

山﨑：推論処理が非同期化されているので、Workerがタスクを完了できない場合の検知・再試行の仕組みが必要だと思いますが、どのような方法を取られていますか？

伊野瀬：タスクが失敗した場合は、3秒間隔で最大3回まで自動的に再試行する仕組みをすべてのタスクに組み込んでいます。タスクの実行状態は常に監視しており、エラーが発生した場合はその内容をLangfuseにトレースログとして記録しています。どのタスクがいつ、なぜ失敗したかを後から追跡できます。

さらにWorkerの稼働状況、失敗したタスクの数、メモリ使用量などのメトリクスをCloudWatchに定期的に送信し、Flower（Celeryの監視ダッシュボード）でリアルタイムに可視化しています。

山﨑：長期化したタスクがリソースを占有する問題への監視や対処はありますか？

伊野瀬：長期化したタスクには3段階のタイムアウト制御を実装しています。最も外側の層では60分でタスクを強制終了し、アプリケーション内部では15分のタイムアウトチェック、外部プログラム呼び出し時には5分のタイムアウトを設定しています。

1つのWorkerが一度に1つのタスクしか取得できないようにし、同時実行数も30に制限することでリソースの占有を防いでいます。監視面では、30秒ごとのヘルスチェックでWorkerの異常を検知し、CloudWatchとFlowerでリアルタイム監視しています。

山﨑：リトライやオブザーバビリティといった基本的な対処を多段にやられているんですね。

追加で考えられることとして、推論のフェイルオーバーにシャドウテスティングを組み合わせる方法が挙げられます。複数のモデルにリクエストして並列に結果を受け取り、ユーザーに返却する推論対象のモデルはあらかじめ決めておいて、それ以外のモデルからの返却結果は内部評価にだけ利用するのです。新しいモデルの評価がしやすくなりますし、推論に不具合があったときのフェイルオーバー手段にもなります。

AIエージェントでも生成AIアプリケーションでも、他のITシステムと同じように良い設計の基本的な考え方は同じです。

【gumi】面倒事を引き受ける共通基盤アーキテクチャ

山﨑：続いて、gumiの清水さんから、ゲーム開発を支える共通基盤アーキテクチャについてお話しいただきます。

清水：弊社の共通基盤が何のためにあるかというと、ゲーム開発者がゲームの「おもしろい」という部分の開発に集中できる環境をつくることを目的に設計しています。

お客様に良いゲームを届けるには、おもしろさの追求に最大のリソースを投下したい。ただ、おもしろさは非常に定性的で、試行錯誤が必要です。そこにリソースを投入したいので、それ以外の「よくある機能」に関しては、なるべく安定して使えるものが各アプリにあるのが理想です。

安定した共通機能を提供するために、どのような責任分担が最適で、組織構造が最適か、それを実現するにはどのようなアーキテクチャがあるかを設計しました。

清水：ここには明確な責任領域があります。

共通基盤やインフラ、つまり認証・課金やインフラの運用といった領域は、長い目で見たときに安定していること、可用性があること、そしていろんなアプリで使えるという共通性が求められます。ここを共通基盤部門が請け負います。

それに対してゲームロジック、おもしろさを実現するところは、ゲームコンテンツの中身や体験そのものを実装するところです。ここに求められるのは、高速にイテレーションを回してより良いものを作っていく速度と、柔軟に変えていける柔軟性です。ここは各タイトルの開発チームが担当します。

このように責任が異なれば、最適な開発プロセスも技術も異なります。だからこそ、ゲームのおもしろさ以外の要素は共通部門が対応するのが良いだろうという考えです。そうすれば明確な境界ができて、それぞれがいちいちやり取りしなくてもゲームが成り立つ構造になります。

清水：この考え方を組織構造に落とし込むと、共通部門とタイトル開発、共通の基盤層とゲームのメインロジック層を明確に分離することになります。組織の境界とシステムの境界が責任の境界として一致する状況を目指しています。

結果として、ゲーム開発者はタイトル特有の開発に集中し、共通部門は各タイトルのフィードバックを取り込みながら継続的な改善に集中できます。

具体的な設計に落とし込むと、弊社には4つのコンポーネントがあります。ゲームのクライアント（スマホにダウンロードされるアプリ）、それと通信するゲームのAPIサーバー。その間にGHRとNativebaseという共通基盤部門が開発・運用するコンポーネントがあります。

清水：GHRの役割は、すべてのクライアントとゲームAPIサーバーの通信を単一の窓口として受け取ること。認証や課金などの共通処理については、Nativebaseと呼ばれる共通基盤部門が管理するAWSアカウントにあるマイクロサービスと通信し、後ろのAPIサーバーにプロキシします。

この結果、APIサーバーは認証もセッション管理も課金も「面倒なこと」がすべて終わった状態でリクエストを受け取れます。すべてのプラットフォーム（AppleやGoogle）の仕様を考えずに実装できる状態です。

清水：Nativebaseのマイクロサービスは、各社のアカウント認証（Googleアカウント、Sign in with Apple等）やレシートの仕組みなど、プラットフォームごとの差異を吸収して正規化しています。

GHRに来るときにはもう共通フォーマットになっているので、Nativebaseに新しいマイクロサービスを追加するだけで、GHRやゲームAPIサーバーは何も変更しなくても新しいプラットフォームに対応できます。タイトルが増えても実装コストは線形に抑えられます。

清水：Nativebaseは全タイトル共通の基盤なので、停止すると全タイトルが止まります。そのためDynamoDBを中心とした無停止で高可用性のフルマネージドサービスを使っています。

GHRは各タイトルに配置しているので、Redisなどを使って、メンテナンスは1タイトル分で済みます。タイトルの要求に応じた構成が取れるものを採用しています。

山﨑：GHRは共通部門が構築・運用するにもかかわらず、共通アカウントではなく各ゲーム用AWSアカウントに配置していますね。これはなぜでしょうか。

清水：うちの場合はOrganizationの下にいます。すべてインフラについては共通部門のインフラチームが見ているので、どちらに置いても運用上の手間はあまり発生しません。きちんと分離できることを目指した形です。

山﨑：GHRのバイナリ更新が必要になった場合は、どのように配布されますか。

清水：同じOrganization下に共通のECRリポジトリとS3バケットがあり、すべてのアカウントからアクセスできる形で配布しています。

山﨑：GHRがSPOFになりますが、レジリエンス面でアーキテクチャ設計の指針としたことはありますか。

清水：各タイトルに置くことで、影響を各タイトルに閉じることです。各タイトルの影響が閉じれば、各タイトルの都合でメンテナンスもできるし、障害対応も可能になります。

山﨑：レジリエンスの基本は影響範囲を分離することです。ゲームタイトルごとのGHRと全タイトルに影響するNativebaseでアーキテクチャを変えていたのは、典型的な良い設計の例でした。

このお話で特徴的なのは、アーキテクチャの設計は責任分解点の設計であるという観点です。アーキテクチャの設計は組織や責任分解の設計であり、組織の設計はアーキテクチャの設計でもある。これは示唆に富んでいました。

【ソラコム】IoTプラットフォームSORACOMのアーキテクチャ

山﨑：最後に、ソラコムの片山さんから、IoTプラットフォームSORACOMのアーキテクチャをご紹介いただきます。

片山：ソラコムはIoTプラットフォームを提供しています。モノがインターネットにつながることで価値が出るものを実現するためのプラットフォームです。

デバイスから通信してクラウドにアクセスしたり、データを送るために必要なコネクティビティ（通信の仕組み）を提供しています。みなさんがスマホで使っている通信のセルラーや消費電力の少ないデバイス向けのLPWA、衛星などのコネクティビティです。

IoTにはいくつかの課題があります。接続方法、認証、セキュリティ、通信プロトコルなどです。例えば、スマホだとIDパスワードや指紋認証で都度認証できますが、デバイスだと人手を介さないのでそうはいきません。暗号化もデバイスが非力なのでやりにくいんです。

片山：アーキテクチャの特徴をご紹介します。実際にモノからデータを上げる先は、今だとほとんどクラウドが使われます。ただ、そこにインターネットが噛んでいるのが問題だろうと、創業当時（10年前）に考えました。これをうまくひっくり返せるアーキテクチャがないかと始めたのが、ソラコムの大きな特徴です。

実際には、世界中の通信キャリアと契約していて、そこからAWSに直接専用線をつないでいます。その上に我々がソフトウェアを作ってAPIを提供することで、インターネットを通さずにクラウドまで行ける経路を実現しました。これによってデバイスの安全性を担保しています。

では、そのアーキテクチャの概要をご紹介します。一番左側がIoTデバイスです。世界中にカメラや車やセンサーがあります。

そこからの通信ですが、例えばセルラーですと、日本だとKDDIさんやドコモさんと我々がAWS Direct Connectで接続しています。グローバルの回線ですとローミングベンダーがいらっしゃるので、そこといくつか接続して、AWSに直接引き込みをしています。

片山：画面の真ん中ぐらいにGGSNやHSSという単語が並んでいますが、ここの部分を我々は「Polaris」という名前で呼んでいます。いわゆる通信規格のグローバル規格に則ったソフトウェアを自社で実装して、デプロイして運用しています。この部分は、よくあるライセンスが必要だったりするソフトウェアを自分たちで作っているということになります。

後ろ側は「Dipper」と呼んでいますが、仕組みとしては非常に典型的なWebシステムです。通信セッションの管理、課金、認証、APIの受け付けなどを行っています。

Polarisの通信ソフトウェアに関しては、インフラのベースは今EC2を使っています。ネットワークベースのソフトウェアになるので、OSの機能やネットワークの細かい機能を使いたいということで、今はあえてEC2を選択してクラスター管理しています。Dipperの方はECSやELBを使っていて、gumiさんもDynamoDBを使っていますという話がありましたが、我々もDynamoDBをプライマリのデータソースとして使っています。

続いて、デバイスの認証について説明します。SIMカードには暗号鍵がいくつか入っていて、無線区間の安全性を担保しています。ポイントは、SIMの中に入っている鍵と我々が持っている鍵が同じ共通鍵認証になっていること。

いくつかのやり取りをした後に、お互いに通信のための鍵を生成しますが、鍵自体を交換しなくていい仕組みになっています。送られてきたランダム値からお互いに鍵を生成して通信できるので、安全性が担保できます。SIM自体も耐タンパ性が高く、ハッキングされにくいという特徴があります。

片山：SIMを使って通信をしてきて、認証処理を先ほどのソフトウェアで行って、裏側のWebのクラスターで通信のステートを管理します。あとはネットワークサービス、いわゆるルーターみたいなイメージを持っていただくといいのですが、ここと通信をして、ユーザーがインターネットにデータを流したり、クラウドにデータを入れたりといったことが実現されているアーキテクチャになっています。

片山：AWSの環境は世界中で5〜6カ所使われています。大きく分けて日本向けのクラスターと、フランクフルトにグローバルをカバーするクラスター。各国ごとのランデブーポイントもあり、それらをTransit Gatewayで接続してお客様に通信を提供しています。

このアーキテクチャで最も重要だったポイントは、通信ゲートウェイ部分を自社で開発するという意思決定です。通常はハードウェア込みで通信設備を買ってきて事業をしますが、10年前はクラウドに載せているベンダーはほとんどなく、自社開発する必要がありました。

自社で作ったことで多くのメリットがありました。コンポーネントの機能分割ができ、負荷がかかる部分だけクラスターを大きくできます。DynamoDBなど信頼性の高いAWSマネージドサービスを直接使えるようになりました。

通信規格はグローバルで共通なので、1つ作ると世界中につながります。ビジネスに不要な機能（例：通話機能）を実装しないという判断も可能になりました。ライセンス費用もかからず、スケールアウト時の考慮が不要になりました。

また、最新技術への追従もしやすいです。今年、C言語ベースの通信コアをRustベースに再実装し、ARMにも対応しました。処理速度も早くなり、メモリ使用量やリソース利用量を減らすことができました。

山﨑：テレコム業界のプロプライエタリな通信ソフトウェアを自社開発された意思決定の裏側をもう少しお話しいただけますか？

片山：自社開発をやりやすかったのは、GSMAという団体が規格を公開しているからです。規格がオープンになっているので、自分たちで何とかできるだろうと事前に見えていたのが大きな意思決定のポイントでした。メリットはいろいろわかっていましたが、規格がわからなければそういう意思決定はできなかったと思います。

山﨑：ステート管理をバックエンドのDynamoDBに逃がして、認証処理を行うPolarisはステートレスにしているという話がありました。IoTデバイスからの認証時には必ずバックエンドまで同期通信が必要になると思いますが、ステート管理を分離していることでレジリエンスのメリットはありますか？

片山：認証時は、おっしゃるとおり認証コンポーネントを通ってどのクラスターにつなぐかの情報を返す必要があります。ただ、一度セッションがつながってしまうと、上側のルーター部分にトンネルプロトコルでセッションが貼られるので、それ以降は認証に毎回聞きに行かなくても通信できます。

クラスターのサイズを大きく変えるケースがありますが、その際もデバイスがつなぎに来て再接続を促し、認証クラスター自体がステートを持っていないので、後ろのステートを持っているところに聞きに行けばよい。フロント側のクラスターを自由に大きくしたり小さくしたりできるという意味で、スケーラビリティの観点でもレジリエンスの観点でも役立っています。

山﨑：ステート管理に行かなければいけないところ自体の可用性を上げるというより、ステートにアクセスしなくていい処理を多くするということですね。

片山：そうです。

山﨑：自社開発の範囲を意思決定する話はとても興味深かったです。これがまさにクラウドが可能にした世界です。ソフトウェアエンジニアやアーキテクトのみなさんが、インフラの構成やシステムのコストまでコントロールできる。みなさんもこのような広い俯瞰した視点からアーキテクチャを考えるとおもしろいのではないでしょうか。

【まとめ】良い設計の基本と学び

山﨑：最後に、セッション全体のまとめを共有します。

良い設計とは何かという話で、AWSはWell-Architected Frameworkというフレームワークを公開しています。6つの柱（コスト最適化、信頼性/レジリエンス、セキュリティ、運用上の優秀性、パフォーマンス効率、サステナビリティ）からなっています。今日は主にレジリエンス（信頼性）の話を中心にしましたが、非常に汎用的なフレームワークですので、ご覧になったことがない方はぜひ見てみてください。

山﨑：また、特定の技術領域やドメイン領域に最適化した拡張フレームワーク「レンズ」もあります。例えば2025年にはGenerative AI Lensという生成AIワークロードに特化したレンズも公開されています。

gumiさんのお話のように、組織設計とアーキテクチャの関係もありました。組織の形がアーキテクチャに反映されるというコンウェイの法則、理想的なアーキテクチャに合わせて組織を作る逆コンウェイの法則という話があります。

ソフトウェアシステムを作るのは人間なので、組織とアーキテクチャは切っても切れない関係です。どちらか片方だけ考えるのではなく、両方を考える。その時にゴールを明確化するという話が示唆に富んでいたのではないでしょうか。

山﨑：最後に、AWSの基本思想としてビルディングブロックという話をさせていただきます。SaaSやパッケージソフトウェアを使ったほうがいいケースはもちろんあります。一方で、ソラコムさんのお話のように、自分たちで作ることが本質的なビジネスの差別化につながるケースもあります。

作る人（ビルダー）にとって重要なのは、自分の理想のシステムを組み立てるためのレゴブロックのような部品です。AWSの基本思想はこうしたビルディングブロックを幅広く提供することなので、みなさんのようなアーキテクチャを作る人が非常に重要になります。ぜひ良いアーキテクチャを設計していっていただければと思います。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。