강의

챌린지

멘토링

로드맵

커뮤니티

[Part 1] Spring AIの事例から学ぶAIアプリケーション制御手法:コスト・品質・リスク・フローの制御

Spring AIでAI機能を実装したら、次はAIがどのように動作するのかを観察し、コスト・品質・リスク・処理フローをどう制御するかを考える番です。 LLMを呼び出し、RAGを接続して構造化された応答を受け取るだけでは、AIアプリケーションが十分に信頼できるとは限りません。実際のアプリケーションでは、リクエストがどの経路で処理されたのか、モデルにどれだけのコンテキストを渡しているのか、生成された結果をどこまで信頼できるのか、危険な推奨をどう制限するのかまで、あわせて考える必要があります。 この講義では、Spring AIベースのIncident Responderアプリケーションを一貫した題材として使用します。正常に動作するものの、まだ十分に制御されていないbaselineから始め、実際の実行結果を観察して問題を見つけた後、コードに制御ポイントを追加し、改善前後を比較します。 これを通じて、特定のAI機能の使い方をもう一つ学ぶだけでなく、確率的に動作するAIをJava/Springアプリケーション内でどのように観察・制限・検証するのかという設計の視点を身につけます。

3名 が受講中です。

難易度 初級

受講期間 無制限

Java
Java
Spring Boot
Spring Boot
observability
observability
AI
AI
LLM
LLM
Java
Java
Spring Boot
Spring Boot
observability
observability
AI
AI
LLM
LLM

受講後に得られること

  • AIリクエストのトレースとスパンを追跡し、モデル呼び出し、プロンプト、コンテキスト、トークン使用量、レイテンシなど、実際のリクエストフローを分析できます。

  • リクエストの特性に応じてAIの処理経路を分岐し、アプリケーションがモデルを利用する流れを制御できます。

  • LLMに渡されるランブック・過去の障害履歴・プロンプトのサイズを直接制限することで、コンテキストコストを管理できます。

  • 構造化されたAI応答の基本契約を検証し、失敗時には再試行とフォールバックを適用して安定的に処理できます。

  • DTOマッピングにとどまらず、AIの応答について、根拠との整合性・具体性・過度な確信・アクションの適切性を評価し、改善できます。

  • AIが生成した推奨のリスクを分類し、ポリシーを適用することで、危険な結果がそのまま伝えられないよう制御できます。

  • 稼働中のAIアプリケーションにおいて制御されていない箇所を発見し、フロー・コスト・品質・リスクの観点から適切な制御ポイントを設計できます。

AIアプリケーション、動作するだけで十分でしょうか?

Spring AIでLLMを呼び出し、望みどおりの応答を得ました。

アプリケーションも正常に動作します。

しかし、正常な応答が返ってくるというだけで、AIアプリケーションが適切に制御されていると言えるでしょうか?

リクエストが実際にどのような経路をたどったのか把握しにくかったり、必要以上の情報がLLMに渡されたりする可能性があります。形式に沿った回答が生成されても、その内容が正確で適切かどうかは別の問題であり、技術的にはもっともらしくても、そのまま伝えるには危険な推奨が生成されることもあります。

既存のJava/Springアプリケーションに確率的に動作するAIが加わると、私たちは"正常に動作しているか?"にとどまらず"どこを観察し、何を制限し、どのような結果を検証すべきか?"も合わせて考える必要があります。

この講義は、まさにこの問いから始まります。

AIアプリケーションは、1つのリクエストを処理する間に、複数のデータやサービスを経由してLLMを呼び出し、その結果をアプリケーションの応答として返します。

問題は、このプロセスが正常に終了したという事実だけでは、そのプロセスや結果が適切だったかどうかは分からないことです。

リクエストが実際にどのような経路をたどったのか見えないことがあり、必要以上に多くのランブックや過去の障害履歴がLLMに渡されることもあります。応答が定められたJSON構造に従っていても、内容の正確さや品質まで保証されるわけではなく、もっともらしくても、そのまま伝えるには危険な提案が生成されることもあります。

つまり、問題はLLMが動作しないことではありません。

アプリケーションのあちこちに、まだ観察も制限も検証もできていない箇所が残っているということです。

では、こうした箇所をどのような基準で見つけ出し、制御すべきでしょうか?

Spring AIでLLMを呼び出し、RAGで必要な情報をつなぎ、望む形式の応答まで生成しました。

アプリケーションは正常に動作しています。

しかし、正常に動作していることと、制御されていることは別です。

リクエストが実際にどのように処理されたのか分からなければ、問題が起きたときに原因を追跡するのは困難です。

必要以上の情報が継続的にモデルに渡されると、コストと処理時間が不必要に増加する可能性があります。

回答が希望する形式で作られていても、その内容まで信頼できる保証はありません。

技術的にはもっともらしい提案であっても、そのまま伝えるのは危険な場合があります。

この講義は、まさにここから始まります。

AI機能をもう一つ作るのではなく、すでに動作しているAIアプリケーションのどこを観察し、制限し、検証すべきかを探っていきます。

1つのIncident Responderを最後まで発展させます

この講義では、概念ごとに新しい例を作ることはありません。

1つのIncident Responderを基準となる事例として、講義が進むにつれて同じアプリケーションを継続的に発展させていきます。

Incident Responderは、運用障害の情報を入力として受け取り、関連するランブック、過去の障害履歴、エスカレーションポリシーを収集し、それをもとにAIが障害状況や潜在的な原因を分析して、優先度の高い対応アクションを提案するSpring AIアプリケーションです。

最初から完璧に制御されたアプリケーションを見せるわけではありません。

講義の出発点となるbaselineは、不適切に作られたコードではなく、正常に動作するものの、まだ十分に制御されていないアプリケーションです。

このbaselineで実際のリクエストを実行して問題を発見した後、フロー・コスト・品質・リスクの観点から必要な制御ポイントを一つずつ追加します。そして同じリクエストを再度実行し、何が変わったのかを確認します。

一つのアプリケーションが問題の発見と制御を繰り返しながら、どのようにより信頼性の高い構造へと発展していくのか、その過程を最初から最後まで追います。

この講義は、Spring AIの機能を一つずつ列挙して使い方を学ぶ形式では進めません。

まず正常に動作するベースラインを実行し、その中で実際にどのような問題が発生するのかを確認します。

問題が見えたら、コードの中から制御が必要な箇所を見つけ、実行結果を観察しながら、なぜその箇所を改善する必要があるのかを理解します。

その後になって初めて、問題を解決するために必要な技術やパターンが登場します。

Routing、Observability、Context Budget、Validation、Evaluator–Optimizerといった技術も、それ自体が学習目標ではありません。

「この技術はどのような問題を解決し、アプリケーションのどこを制御するために必要なのか?」をまず確認したうえで、コードに適用します。

そして、同じリクエストを再度実行し、改善前と改善後を比較します。

まず問題を発見し、必要な技術を選び、実際の実行結果で変化まで確認すること。

これがこの講義の学習方法です。

4つの制御課題を自ら解決します

AIアプリケーションで問題が発生したとき、最終応答だけを見ても原因を突き止めるのは困難です。

この講義では、オブザーバビリティ(Observability)を連携させ、1つのIncidentリクエストがどのサービスやモデル呼び出しを経由したのかをtrace · span · event構造で確認します。

実際のLangfuse Trace画面で、リクエストの処理フローや各段階にかかった時間、モデル呼び出し、トークン使用量、レイテンシ、エラーを直接確認し、その後はリクエストの特性に応じて必要な経路を選択するようRoutingを適用します。

まずフローを可視化し、その後フローを制御します。

LLMのコストを管理するには、使用されたトークンを確認するだけでは不十分です。

アプリケーションがLLMにどれだけの情報を渡すかを、自ら決める必要があります。

この講義では、ランブックと過去の障害履歴の件数と長さを制限し、重複を排除したうえで、重大度に応じてコンテキスト予算を適用し、最終的なプロンプトのサイズを制御します。

そして同じリクエストを再実行してトークン使用量を観察し、改善前後を比較します。

コストを観察する段階から、コストを生み出すContextそのものを制御する段階へ。

LLMの応答がDTOに正しくマッピングされたからといって、その内容をすぐに信頼できるわけではありません。

まず必須値、リスト件数、重複、priorityの範囲などの基本契約を検証し、問題があればretryとfallbackで対応します。

しかし、形式が正しい応答でも、根拠が不十分だったり、過度に断定的な内容を含んでいたりすることがあります。そこでさらに一歩進み、根拠との一致度、具体性、過度な確信、アクションの適切性を評価し、Evaluator–Optimizerを通じて応答を改善します。

構造を検証することから、内容の品質まで検証することへ。

技術的にもっともらしいAIの推奨であっても、そのままユーザーに伝えるのは危険な場合があります。

この講義では、推薦のリスクレベルを特定してriskLevel, approvalRequired, riskReasonを付与し、minimumSeverityやescalation policyなどのアプリケーションポリシーを適用します。

重要なのは、AIが推奨を生成する役割と、アプリケーションがポリシーに従って制御する役割を分離することです。

この講義では、実際のツール実行や自動復旧は扱いません。AIの推奨をポリシーに基づいて制御し、安全な形で外部に伝えるところまでを扱います。

AIの推奨をそのまま信頼するのではなく、アプリケーションのポリシーで制御することへ。

この講義では、Java 21と Spring Boot、Spring AIを基盤に、1つのIncident Responderを段階的に発展させながら進めます。

リクエストの流れを観察するためにMicrometer、OpenTelemetry、Langfuseを活用し、実際にコードを実行してAPIを呼び出し、結果を自分で確認します。

別途複雑な環境を新たに学ぶのではなく、Java/Spring開発者にとって馴染みのある開発環境でAIアプリケーションの制御ポイントを設計・検証するプロセスに集中します。

🔗 講義資料をダウンロード

講義で使用する各授業の演習コード、ガイドドキュメント、用語集はGitHub Repositoryで提供しています。

📦 講義資料のGitHub Repository

講義資料全体は、以下のRepositoryで確認できます。

GitHub Repositoryはこちら

実習を始める前に、Repository rootのREADME.mdを必ず先にお読みください。
授業ごとのコードの構成や活用方法など、講義資料を使用するうえで必要な案内を確認できます。


⚙️ Langfuse設定ガイド

Langfuseを初めて利用する受講生向けに、会員登録からAPI Keyの設定まで、実習に必要な準備手順を別途ガイド文書として提供します。

Langfuseの会員登録およびAPI Key設定ガイド


📖 講義用語集

講義に登場するAIアプリケーションの制御、Prompt、Context、Observability、Quality、Riskなどの主要な用語に馴染みがない場合は、用語集もあわせてご覧ください。

講義の用語集を見る

講義を進める中で見慣れない用語が出てきたら、実装方法を説明するドキュメントというより、用語の意味をすばやく確認するための補助資料としてご活用ください。

👉 始める前にご確認ください

前提知識

この講義はJava/Spring開発者を対象としています。

JavaとSpring Bootを使った基本的なアプリケーション開発経験が必要です。また、REST APIとJSONデータ処理に関する基本的な理解を推奨します。

また、LLM、Prompt、Tokenなど生成AIの基本概念とSpring AIを利用した基本的なLLMの呼び出し方法を知っていると、講義をよりスムーズに進められます。


開発環境

実習はJava 21とSpring Boot、Spring AIをベースに進めます。

IntelliJ IDEAを中心にコードを作成し、Postmanなどを使って実際のIncidentリクエストを実行して、結果を確認します。


講義で扱う範囲

1つのIncident Responderを発展させながら、AIアプリケーションのフロー(Flow)・コスト(Cost)・品質(Quality)・リスク(Risk)をどのように観察し、制御するかを学びます。

単なる機能の使い方よりも、制御されていない箇所を見つけ、必要な制御をコードに追加したうえで、実際の実行結果を比較するプロセスに重点を置きます。


この講義で扱わない範囲

この講義のIncident Responderは、AIの推奨を生成し、リスクを特定し、ポリシーを適用して安全な形で伝達するところまでを担当します。

したがって、実際のシステムにおける再起動・ロールバック・スケールなどのツール実行、自動復旧、管理者の承認後に実行したり、中断されたワークフローを再開したりするプロセスは扱いません。

こんな方に
おすすめです

学習対象は
誰でしょう?

  • Spring AIの基本機能を習得した後、実際のAIアプリケーションをどのように設計すべきか悩んでいるJava/Spring開発者

  • LLM呼び出しは実装したものの、リクエストの流れやモデル呼び出しのプロセスをきちんと把握するのが難しい開発者

  • RAGやプロンプトに渡すコンテキストが増えるにつれて、トークンとコストの管理に悩む開発者

  • 構造化出力だけではAIの回答品質を信頼しにくいと感じる開発者

  • AIが生成した推奨や判断を、アプリケーションのコードとポリシーで制御したい開発者

  • AI機能の実装にとどまらず、運用可能で信頼性の高いAIアプリケーションの設計方法を学びたい開発者

前提知識、
必要でしょうか?

  • Javaおよびオブジェクト指向プログラミングに関する基本的な理解

  • Spring Bootを用いたアプリケーション開発経験

  • Springの依存性注入(DI)と基本的なアプリケーション構造への理解

  • REST APIとJSONデータ処理に関する基本的な理解

  • 生成AIの基本概念(大規模言語モデル(LLM)、プロンプト、トークンなど)への理解

  • Spring AIを使用して、ChatClientなどの基本的なLLM呼び出しを実装した経験

こんにちは
Kevinです。

キャリア認証

6,936

受講生

311

受講レビュー

133

回答

4.8

講座評価

12

講座

  • 主要言語または技術:Java, Spring Framework, RxJava, Reactor, Spring WebFlux

  • (株)ペンタセキュリティのバックエンド開発者として活動(From 2015.07 To 2022.01)

  • (株)コードステイツ(https://www.codestates.com)にて Senior Educational Software Engineer(Backend)として活動
    (From 2022.03 To 2024.01.31)

- フリーランスの開発者および講師として活動(Since 2024.02)

- 著書

こんにちは。Kevinと申します。^^

Inflearnでこのように講師として皆様にお会いできて、とても嬉しいです。

どの分野でも同じだと思いますが、特にソフトウェア開発者は、絶えず変化するトレンドに遅れないよう常に自分自身を磨き続けることが、開発者として生き残る唯一の方法だと考えており、常に学ぶ姿勢で楽しくソフトウェア開発を行っている開発者の一人です。

私が持っている知識と経験が、他の方々に少しでもお役に立てればという思いで、Inflearn(インフラン)で講座を始めました。

これから受講生の皆様に、現実的に役立つ様々な講座で、継続的にお目にかかりたいと思います。ありがとうございます。

 

質問や意見はいつでも歓迎ですので、メール(it.village.host@gmail.com)でお気軽に連絡してください。

 

もっと見る

カリキュラム

全体

16件 ∙ (6時間 23分)

講座資料:

授業資料
講座掲載日: 
最終更新日: 

受講レビュー

まだ十分な評価が集まっていない講座です。
ぜひ最初のレビューをお寄せください。

Kevinの他の講座

知識共有者の他の講座はこちら

似ている講座

同じ分野の他の講座を見てみましょう!

期間限定セール

¥35,750

35%

¥6,976