AWSアカウント内で複数のシステムがAmazon Bedrockを利用する際、機能単位でクォータの消費量やコストを監視・追跡するための「アプリケーション推論プロファイル」の作成方法と利用方法について解説します。

こんにちは。LIFULLで売却査定サービスの開発をしている申です。 売却査定事業に関わる審査業務の一部を自動化するバッチを、AIに開発を任せながら作成して、改修し続けてきた話 を紹介したいと思います。このバッチを作るにあたって、「何を作るか」より「どう作り続けるか」にかなり悩みました。 先に結論から言いますと、AIに任せる範囲を広げるほど、私の手元に残ったのは「 何が正解か 」を決める仕事でした。これは、土台にした AI-DLC （AWSが提唱するAI主導の開発手法）の中心にある「AIが計画・実行し、人が判断・検証する」という考え方を、実際の開発で回し続けて具体化したものです。 1. 作ったもの：審査業務の一部を自動化するバッチ 2. 開発に着手する前に「正解の基準」を作る 3. 土台にした手法：AI-DLCと、研修で学んだ3つの考え方 4. 回し続けるために足したもの 4-1. 役割ごとにコンテキストを分け、流れはOrchestratorに任せる 4-2. テストを先に書き、実装はスクリプトで自動生成する 4-3. テストが通っても、レビューは通す 4-4. 「直す」も同じサイクルで回す 5. 一番大きな発見：固定すべきはテストではなく、業務との契約だった 6. 完成した開発フローと、本番リリースまで 7. ほかのプロダクトへ広げていくために 8. まとめ 1. 作ったもの：審査業務の一部を自動化するバッチ LIFULL HOME'Sの売却査定事業には、届いた申請を業務で定めた基準に沿って確認する審査業務があります。これまでは担当者が1件ずつ手作業で確認していましたが、市場の拡大に伴って申請数も増え、審査のコストが重くなっていました。 そこで、申請データをこの基準に沿って一次チェックし、判定結果を記録するバッチを作りました。最終的な判断は人が行い、担当者は判断が必要な案件と、結果のダブルチェックに集中します。 判定ルールは、業務のフィードバックや審査基準の見直しで今後も変わっていきます。だからこそ一度作って終わりではなく、同じ品質で直し続けたいと思っていました。 そこで考えたのが、AIに開発を任せることです。業務の言葉であるフローチャートからAIがそのまま作れれば、ルールが変わっても人の工数をかけずに対応できます。ただ、何も決めないままAIに任せると、品質はどうしてもブレます。このブレを抑えるため、AI-DLCという開発手法を土台にしました。 2. 開発に着手する前に「正解の基準」を作る 開発に入る前、審査の流れをフローチャートに起こし、PRでレビューしてもらいました。そのうえで、業務担当のメンバーが審査を担当する部署の確認まで取ってくれました。 この進め方は、AI-DLCでいう「Mob Elaboration」に近いものでした。Mob Elaborationは、要件を固める最初のフェーズ（Inception）で、AIからの質問や提案をチーム全員で検証する進め方です。業務側と審査担当の部署で要件を検証し、フローチャートとして合意したことが、その役割を果たしていました。 AIの出力が正しいかどうかを判断するには、比べる対象となる「正解」が必要です。この開発では、フローチャートがその正解でした。正解の基準が先にあったから、AIに任せられました。 3. 土台にした手法：AI-DLCと、研修で学んだ3つの考え方 AI-DLC（AI-Driven Development Life Cycle）は、AWSが提唱するAI主導の開発手法です。要件を固めるInception、設計と実装を進めるConstruction、運用を担うOperationsの3つのフェーズで構成されます。各段階でAIが計画し、人が承認しながら進めます（詳しくは AWSの解説ブログ をご覧ください）。 2025年10月には、AWSが提供する「AI駆動開発ライフサイクル（AI-DLC）Unicorn Gym」（3日間）に参加しました。まさにこの審査業務を題材に、手法を体験しています（研修全体の様子は AWSブログ で紹介されています）。 AI-DLC Unicorn Gymの様子（出典： AWSブログ ） 研修で学んだ考え方のうち、特に次の3つを土台にしました。 人の承認なしに次の段階へ進まない わからないことは [Question] で質問させ、独自の判断をさせない 段階ごとにその役割だけに集中し、やり切ってから次へ進む （設計段階ではコードを書かないなど） この3つは、今でも私が作ったエージェントの共通ルールの中心にあります。特に2つ目には、日々の開発で何度も助けられています。AIはわからないことを推測で埋めず、ドキュメントに [Question] として質問を書いて、私の [Answer] を待ちます。次の画像は、AIが書いた質問へ私が回答した実際の例です。 AIの質問と人の回答の例 4. 回し続けるために足したもの ルールが変わるたびに直していく開発を何ヵ月も回し続けるには、考え方だけでは足りませんでした。必要になったものを、一つずつ足していきました。そうして本番リリースに至るまでの全体の流れは、以下のとおりです。 フローチャート作成から本番リリースまでの流れ 4-1. 役割ごとにコンテキストを分け、流れはOrchestratorに任せる AI-DLCを繰り返し回すには、段階ごとのプロンプト投入を定型化したいと考えていました。そこで、 レビュー自動化の記事 を見つけました。この記事では、コードレビューをシェルスクリプトで自動化し、実装から独立したコンテキストで動かしていました。 そこから一歩進めて、レビューだけでなく すべての段階 を独立したエージェントに分け、流れはOrchestratorが管理するようにしました。Orchestratorが呼び出すサブエージェントは、次の5つです。 Inception：何を作るかを整理する。作りたいことやユーザーストーリーをまとめ、作る単位（Unit）に分ける Base Designer：Unit全体の土台を設計する。使う技術や、Unitどうしで共通して使う部分を決める Unit Designer：Unitごとの中身を設計する Code Implementation：設計どおりにコードを書く Unified Reviewer：ほかのエージェントの成果物を、作り手とは別の目でチェックする Orchestratorを含めると、エージェントは全部で6つです。5章で紹介する契約更新用のエージェントは、あとから加えたものです。 Orchestratorが、AI-DLCのフェーズごとに分けたサブエージェントを呼び出す構成（作成当初） AI-DLCの「段階ごとに集中する」を、コンテキストの分離という形でしくみにしたものです。 私がやることは、意思を伝える・質問に答える・成果物を承認することだけになりました 。つまり、「何を作るのが正解か」を決めることです。これで、理想的なしくみができたと思いました。ところが実際に動かしてみると、問題が出てきました。 4-2. テストを先に書き、実装はスクリプトで自動生成する まず、AIが設計からそのままコード生成に進んでしまい、人がAIにどう指示したかによって、生成されるコードの品質が変わりました。AIがテストを後から書くと、実装に合わせたテストにもなりがちでした。 そこで、順序を「ドキュメント → テスト → 実装」に変えました。テストはAIが書き、私がAIとの対話で中身を確認して承認します。実装は、 code-implementation.sh というスクリプトがAIを呼び出し、毎回同じプロンプト・同じ手順で生成させます。テストが通るまで、スクリプトが最大10回作り直させます。テストは読み取り専用のため、AIが通すために書き換えることはできません。 実装の段階で人が入らないため、人ごとの指示の違いは入り込みません。合格の基準も、人が承認したテストに固定されています。生成されるコード自体が毎回同じになるわけではありません。それでも、 実行する人によらず、同じ基準を満たしたコードだけが残ります 。ここでも私の役割は、テストという「 動作の正解 」を AIと決めて承認すること です。AI-DLCの言葉で言えば、Constructionで、人が検証する対象をコードからテストへ移したものです。 テスト先行と、実装の自動ループ 4-3. テストが通っても、レビューは通す 次の問題は、終了条件が「テスト成功」だけだったことです。AIが、値をハードコードしてテストだけ通すようなコードを生成し、それが一度もレビューされずに「完成」として出てくることがありました。メンバーからも「生成物の品質担保の観点では物足りない」という指摘とともに、テスト後にレビューを追加する提案をもらいました。 そこで、テストが通ってもレビューは通すことにしました。テストが通ったら、独立したReviewer（AI）がレビューします。その指摘をCode Implementation（AI）が反映して再テストする流れを、最大2回繰り返します。テストは「動作」を、レビューは「コード品質」を守ります。 このループには、人は介入しません。1つ目の「人の承認なしに次の段階へ進まない」に反するように見えるかもしれません。しかし、人が承認する場面をなくしたのではなく、「 正解を定義する場面 」に集めただけです。 テスト先行と、実装・レビューの自動ループ 4-4. 「直す」も同じサイクルで回す 最初のバージョン（v1.0.0）は、プロンプト1つから始めて、テスト環境へのデプロイまで到達しました。その後、チームのメンバーによるコードレビューで、約20件の指摘が出ました。 これらの指摘は、コードを直接直すのではなく、次のサイクル（v1.0.1）の入力にしました。エージェントが前のサイクルの成果物を引き継ぎ、指摘に関わる部分だけを設計し直して、テストと実装まで通します。v1.0.0で「作れる」、v1.0.1で「直せる」ことを確かめ、その後の業務フィードバック（v1.1.0・v1.1.1）も同じ流れで処理しました。小さな不具合は、そのときのサイクルの中で、エージェントが設計ドキュメントから直すこともあります。 v1.0.0〜v1.1.1の4サイクルの間、エージェントの設定は一度も変えていません 。手法が安定したと感じました。 5. 一番大きな発見：固定すべきはテストではなく、業務との契約だった ただ、v1.1.1まで来たところで、別の壁にぶつかりました。「テストは読み取り専用で、実装がテストに合わせる」というルールで順調に回っていました。ところが、基準番号（審査の判定理由を分類する番号）を決めるロジックを別クラスに切り出すリファクタリングで、問題が起きました。 業務的には何も変わっていないのに、ユニットテストを約270行書き直す必要があった のです。テストを作る段階に戻ってAIが書き直し、私があらためて承認しました。 このとき初めて、ユニットテストは内部構造に紐づいている以上、構造を変えればテストも変わるしかないと実感しました。そしてテストを書き換えた時点で、「リファクタリングの前後で業務の動作が同じであること」は証明できなくなります。 「テストは直さない」と決めたのに、直さざるを得ない構造になっていた のです。 そこで、続くv1.1.2では、既存のテストは残したまま、業務の入力と出力だけを確かめるFunctionalテスト（ブラックボックステスト）を足しました。このテストもAIが書き、私が承認しています。ただ、このテストは 実装の都合では書き換えない「業務との契約」 として運用するようにしました。 内部構造に紐づくユニットテストと、入力と出力だけを見るFunctionalテスト 項目 内容 何を固定するか フローチャートの全分岐・全終端を「申請データの入力 → 最終的な判定結果の出力（判定・基準番号・理由・進捗）」として定義。内部構造には依存せず、外部通信だけを偽物（Fake）に置き換える 誰が変えられるか 実装エージェントは書き込み禁止。業務仕様の変更が承認されたときだけ、専用エージェントが更新し、レビュー2回と人の承認を経る どう守るか CIで契約の件数そのものを固定（こっそり減らせない）。各サイクルの最初（Inception）で「契約に影響があるか」を判定する 期待値の決め方 現在の実装の動作ではなく、業務との合意 で決める 最後の「期待値の決め方」は、契約を追加したPRへのレビューがきっかけです。チームのメンバーから、現行実装の動作をそのまま契約にするのではなく、業務仕様として明記・合意してから固定すべきだ、という指摘を受けました。 これは「独自の判断をさせない」を、テストの期待値にも当てはめたものだと考えています。今の実装は、AIが過去に下した判断の結果でしかなく、それに仕様を決めさせてはいけません。 そのため、業務と合意した契約と実装が食い違ったときは、 契約を実装に合わせて書き換えず 、CIの失敗として見えるようにしています。テストを実装に合わせるのではなく、 仕様と実装のずれを見える化する のが契約の役割です。 同じ考え方で、まだ実装していない機能の仕様も、7件の契約として先にAIが書き、私が承認しました。これらは、実装されるまで失敗する状態で追加しています。この7件が通るようになった経緯は、次の章で紹介します。 6. 完成した開発フローと、本番リリースまで 完成した開発フロー こうして並べると、人が関わる場所はすべて「 何が正解か 」を決める場面だとわかります。 業務側と合意したフローチャートを、正解の基準として用意する 各段階でAIからの [Question] に答え、要件や設計ドキュメントを承認する テスト（動作の正解）をAIと決めて承認する 業務仕様が変わったときに、業務との契約の更新を承認する この流れのまま、その後のv1.2.0では、バッチの判定処理の中で、文脈の判断が必要な箇所にLLMを使うようにしました。ただし、バッチはLLMの出力をそのまま判定にはせず、ルールによるチェックと組み合わせています。ここでも「何が正解か」を決めるのはLLMではなく、業務と合意した基準です。 この追加によって、5章で先に書いておいた7件の契約が通るようになりました。機能を足すサイクルでも、契約は書き換えず、実装のほうが契約に追いついた形です。 このバッチは2026年秋に本番環境へリリースし、現在は実際の業務で使われています。業務担当者は、バッチの判定結果をダブルチェックしたうえで最終的な判断を行い、バッチでは判断できない作業へ集中する形になりました。導入にあたって行った業務側へのヒアリングでも、好意的な反応をもらっています。研修で題材にしたテーマが、同じ手法のまま本番稼働までたどり着きました。 7. ほかのプロダクトへ広げていくために この進め方は、今回の審査業務だけのものにするつもりはありません。今後は、ほかのプロダクトの開発にも広げていく予定です。 役割ごとに分けたエージェント、テスト先行で回す実装とレビューのループ、業務との契約テスト、「直す」も同じサイクルで回す運用は、そのまま持っていけると考えています。ただ、どれも業務と合意した「何が正解か」があって初めて機能します。新しい対象でも、まずは今回のフローチャートにあたるものをどう用意するかから始めることになりそうです。 広げるうえで、もう一つ気になっているのがトークンの使用量です。これまでは利用量をあまり意識せずに使えていましたが、2026年8月から利用量に上限のあるプランで開発するようになりました。すると、変更が少なくても、1サイクルで月間上限の大半を使うことがわかりました。変更が大きいと、上限まで使っても設計が終わらないこともありました。 これはツールの問題というより、 手法の特徴の裏返し だと考えています。AI-DLCでは、各段階の成果物をリポジトリに残し、次の段階やサイクルにコンテキストとして引き継ぎます。サイクルを重ねるほど読み込む成果物が増えるため、トークンの多くはコードではなくドキュメントに使われます。 この手法で一番大事な成果物は、正解を表すドキュメントですので、ここはコストを削れません。トークンの使用量とドキュメントの品質をどう両立させるかは、ほかのプロダクトへ広げていくうえでも向き合わなければならないテーマです。同じ課題を抱えている方がいれば、ぜひ知見を交換させてください。 8. まとめ AI-DLCの考え方は、そのまま効きました。このサイクルを回し続けた結果、私の手元に残ったのは「何が正解か」を決める仕事でした。 この形をほかのプロダクトにも広げていくことで、AIに任せられる範囲を少しずつ増やしていきたいと考えています。 AIに開発を任せながら、品質をどう守るかに悩んでいる方の参考になれば幸いです。最後まで読んでいただき、ありがとうございました！ 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

AWS Lambda Web Functions で、LLM の待ち時間は本当に課金されないのか。アクティブ CPU 課金の仕組みを整理し、LLM を待つ API で得をする理由と、メモリ課金やタイムアウト、短い CPU 処理で損をするケースを試算で確かめます。AgentCore Runtime との違いにも触れます。