株式会社ずんだもん技術室AI放送局 podcast 20251106

youtube版(スライド付き)

関連リンク

• 2025/11/04 Builders Flash にて “AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ” を公開しました

freeeのAI駆動開発チームの中山さんが、AWSの公式ブログメディア「Builders Flash」に、最新のAI技術活用に関する記事を寄稿されました。タイトルは「AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ」で、2025年11月4日に公開されています。

この記事の最も大切なポイントは、AIエージェントを企業で安全かつ効率的に動かすための「プロキシ基盤」の構築方法について解説している点です。最近、ChatGPTのような大規模言語モデル（LLM）をベースにしたAIエージェントが注目されていますが、これを実際にビジネスで使うには、情報漏洩を防ぐセキュリティ対策や、費用を抑えるためのコスト管理、そしてシステムが安定して動き続けるための仕組みなど、考慮すべき点がたくさんあります。

そこで、この記事では「LiteLLM」というオープンソースライブラリが重要な役割を果たします。LiteLLMは、OpenAIやAnthropic、Googleなど、様々なLLMサービスへのアクセスを統一された方法で扱えるようにしてくれるツールです。記事では、このLiteLLMをプロキシとして利用し、AWSのサービス（例えば、計算リソースを提供するEC2やLambda、ネットワークを安全に構築するVPCなど）と組み合わせることで、次のような大きなメリットを持つAIエージェント基盤を実現できると紹介しています。

1. セキュリティの強化: LLMサービスへ直接アクセスするのではなく、間にプロキシを置くことで、リクエストの内容を監視したり、認証・認可を一元的に管理したりできます。これにより、機密情報の漏洩や不正な利用を防ぎ、安全性を高めることができます。
2. 柔軟なLLMの選択と切り替え: LiteLLMは多様なLLMプロバイダに対応しているため、もし将来、より性能が良かったり、費用が安かったりする新しいLLMが登場しても、アプリケーションのコードを大きく変更することなく、簡単に切り替えることが可能です。これは、特定のベンダーに縛られず、常に最適なAIモデルを選べるという点で非常に重要です。
3. コストの管理と最適化: プロキシを通じてLLMへのリクエストを集中させることで、APIの利用状況を詳細にモニタリングし、不要な利用を制限（レートリミット）するなどして、コストを効率的に管理・最適化できます。
4. 開発効率の向上: 開発者は個々のLLMプロバイダのAPI仕様を詳しく覚える必要がなく、LiteLLMという共通のインターフェースを通して開発を進められるため、開発スピードを上げることができます。

新人エンジニアの皆さんにとって、AIエージェントを「どう使うか」だけでなく、「どうやって安全に、効率よく、そして将来性を見据えてシステムを構築するか」という視点は、これからのキャリアで非常に役立つでしょう。この記事は、AIエージェントのインフラ設計や運用に興味がある方にとって、具体的なヒントと実践的な知見を与えてくれるはずです。ぜひリンク先の記事を読んで、AIエージェント基盤の奥深さを学んでみてください。

引用元: https://developers.freee.co.jp/entry/aws-builders-flash-202511

• LLM APIを2年間本番運用して苦労した話

この発表は、株式会社IVRyが電話の自動応答システムでLLM APIを2年間本番運用する中で直面した課題と、それらを乗り越えるための知見を新人エンジニアにも分かりやすく解説しています。

まず、LLM APIは様々な質問に対応できる「zero-shot learner」として非常に有用で、多くのタスクに活用できると指摘されています。しかし、既存の一般的なAPIとは異なる特有の問題があることも強調されました。

運用初期には大きな問題はなかったものの、ある日発生した大規模なAzure OpenAI障害をきっかけに、「LLM APIは必ず落ちる可能性がある」という現実を痛感。これを受けて、障害発生時に別のLLMに切り替える「フォールバック」の仕組みを導入し、さらに「監視体制を強化」しました。

しかし、フォールバックだけでは解決できない新たな課題が見つかります。それは、LLMが完全に停止するわけではなく、「応答が遅くなる（レイテンシーの悪化）」や「不正確な回答を返す（精度劣化）」といった、エラーとして検知されにくい障害パターンです。これらはフォールバックが効かないため、ユーザー体験に直接影響を与えてしまいます。

これらの問題に対し、IVRyでは以下の対策を講じました。

1. きめ細かい監視の実施: LLMの応答速度は、利用するモデル、入力の長さ、情報の種類（モダリティ）、出力の長さなど、様々な要因で変動します。そのため、これらの要因ごとに分けて監視することで、異常を早期に発見できるようにしました。
2. 障害パターンごとの対応手順書（Playbook）作成と訓練: どんな異常が起きたらユーザーにどのような影響があるのか、どうやって検知するのか、そしてどのようなアクションを取るべきかを事前に具体的にまとめたPlaybookを作成。さらに、実際に障害が発生したと想定して訓練を行うことで、迅速かつ適切な対応ができるようにしました。
3. ライブラリ選定の注意点: LLM APIの共通化やフォールバックのために便利なライブラリ（例: LiteLLM）を使っていたものの、バージョンアップで予期せぬCPU使用率の増加が発生しました。ライブラリに頼りきるのではなく、場合によっては自前で実装することも含め、コントロールが効く選択肢を検討することの重要性が示唆されました。

まとめとして、LLM APIを安定して本番運用するためには、「障害は必ず起こる」という前提に立ち、フォールバックの仕組みだけでなく、多角的な監視、具体的な対応手順の準備、そして使用する技術スタックの選定に至るまで、徹底した対策が必要であると締めくくられています。これは、これからLLMを活用したサービス開発に挑戦する新人エンジニアにとって、非常に実践的な教訓となるでしょう。

引用元: https://speakerdeck.com/ivry_presentationmaterials/llm-apiwo2nian-jian-ben-fan-yun-yong-siteku-lao-sitahua

• AIを賢く動かすのは「指示力」ではなく「文脈設計力」

AIを効果的に活用するためには、細かく指示を出す「指示力」だけでなく、「AIに何を見せるか」を設計する「文脈設計力（コンテキストエンジニアリング）」が非常に重要である、という内容の記事です。特に、AIコーディングでAIとのやり取りに時間がかかってしまう新人エンジニアの皆さんに、AIの特性と賢い付き合い方を分かりやすく解説しています。

なぜAIとの会話がうまくいかないことがあるのでしょうか？その理由は、大規模言語モデル（LLM）が持ついくつかの制約にあります。

1. LLMは確率で動いている: AIは次に続く単語を確率的に予測して生成しています。同じ指示でも結果が微妙に変わるのはこのためです。この確率の精度は「コンテキスト（文脈）」に大きく左右されます。
2. 会話が長くなると品質が下がる（コンテキストの腐敗）: 人間と同じで、AIも一度にすべての情報に完璧に注意を払うことはできません。会話が長くなると重要な情報が埋もれたり、途中の情報を忘れやすくなる「Lost in the Middle問題」が発生します。
3. 記憶力には限りがある（コンテキストウィンドウ）: LLMには一度に処理できる情報量に「コンテキストウィンドウ」という上限があります。この上限を超えると、AIは古い情報を忘れてしまいます。プロジェクトルール、ツール定義、会話履歴などがこのウィンドウを圧迫し、重要な情報がAIに伝わりにくくなる原因になります。

これらの制約を踏まえ、AIを賢く動かすためには、単にプロンプトを詳しく書く「足し算」のアプローチではなく、本当