はじめに
AI Agentシステムを開発したいと考えたとき、「何から手をつければいいのか？」「どのツールをどの段階で使うべきか？」と悩むことはないでしょうか。
私たちのチームでは、超初期のアイデア検証から実運用に向けた精度向上の検証に至るまで、プロジェクトの成熟度に合わせてツールを使い分けることで、開発をスムーズに進めてきました。
この記事では、ありもの（Cursor）から始め、Bedrock Agentを経て、最終的にLangChainへと移行した経験を基に、AIエージェントのPoCを段階的に育てていくための3つのステップを共有します。これは、同種のライブラリ（例: LangChain vs LlamaIndex）を比較する技術選定の話ではなく、特性の異なるツールを使い分け、アイデアを本格的なシステムへと育てていく過程に焦点を当てています。
この記事の対象読者
- AI Agentシステムの開発を何から始めるべきか悩んでいる方
- プロジェクトのフェーズに合ったツールの使い分けを知りたい方
- PoCから実用化へのプロセスに興味がある方
この記事で得られること
- AI Agent開発を最小限の労力で始めるための具体的な手法
- プロトタイプから次のステップへ移行を考える上でのポイント
- Cursor、Bedrock Agents、LangChainのフェーズごとの使い分け
私たちが辿った3つのステップ
結論から言うと、私たちはAI Agentシステムを以下の3ステップで開発しました。
-
Step 1: 超高速なアイデア検証 (Cursor)
- 目的: コードを書かずに、「このアイデアは技術的に実現できそうか？そしてユーザーに刺さるか？」を最速で検証する。
- ツール: Cursor
-
Step 2: 迅速なプロトタイピング (Bedrock Agents)
- 目的: より本番に近い形で、機能連携やユーザー体験を具体的に検証する。
- ツール: AWS Bedrock Agents & KnowledgeBase
-
Step 3: 実用精度への引き上げ (LangChain)
- 目的: PoCを実用的な精度まで引き上げ、安定性と継続的な改善を可能にする基盤を構築する。
- ツール: LangChain, Langfuse
ここからは、架空のタスクとして「複数の社内ドキュメントを横断的に読み解き、関連する定量データをDBから取得して、インサイトを要約する」というケースを例に、各ステップで何を行ったかを詳しく解説します。
Step 1: 超高速なアイデア検証 (Cursor)
最初のステップの目的は、検証したい対象となる機能のアイデアの核が、そもそも価値があるのかを最速で検証することでした。
そのため、LangChainどころかBedrock Agentsすら使わず、まずはCursorのRAG機能に、複数の社内ドキュメントファイルと、定量データが入ったExcelファイルをそのまま読み込ませ、「この社内ドキュメントの内容を、こちらの定量データを基に要約して」と指示プロンプトを実行するという方法で、v0.01レベルのサンプルを試作しました。
このアプローチの利点は圧倒的なスピードです。コードを書くことなく、アイデアの核心部分が技術的に成立しそうか、そして価値がありそうかをすぐに試すことができます。
Cursorで簡易的にデータ取得して回答を生成
Step 2: 迅速なプロトタイピング (Bedrock Agents)
Cursorで「ドキュメントとExcelファイルから、それらしい要約が生成できる」という手応えを得た後、次のフェーズに移りました。ここからは、単なるアイデア検証ではなく、実際に動作するシステムとしてのPoC（概念実証）を構築していきます。
なぜBedrock Agentsだったのか？
このフェーズの目的は、より本番に近い形での検証へとステップアップさせることでした。具体的には、以下の2つの要件を満たす必要がありました。
- 構造化データをより柔軟に扱うこと: Step1のCursorでも、Excelファイルから定量情報を取得することはできましたが、これはあくまで静的なファイルです。より複雑な条件で、リアルタイムの定量データを正確に取得するためには、Lambda経由で直接データベースにSQLクエリを投げる等の仕組みが必要でした。
- APIとして提供し、最終的なUI/UXを検証すること: 最終的なプロダクトはAPI経由でフロントエンドから利用される想定でした。そのため、PoCの段階からAPIとして構築し、インターフェースやユーザー体験が想定通りかを確認したかったのです。
これらの要件から、AWS Lambda経由でDBにアクセスするツール（アクショングループ）を定義でき、かつそれをAPIとして外部から呼び出せるBedrock Agentsが最適な選択肢となりました。
メリット:
- GUIベースの簡単なセットアップ: Lambda関数の中身を実装する部分を除けば、KnowledgeBaseとの連携やエージェントの指示プロンプト、ツールの定義といった主要な設定は、AWSのGUIコンソール上からほとんどクリック操作だけで完結します。これにより、インフラのコードを書く手間を大幅に削減し、PoCのコアロジックであるツール連携の検証に集中できました。
- 簡単なツール連携: 「社内ドキュメントの検索」を行うBedrock KnowledgeBase（RAG用）と、「定量データの取得」を行うSQLクエリ実行用のLambda関数、という2つのツールを簡単に定義・登録できました。
- 動作ステップの可視化: Cursorではソースのうちどの部分を読みに行ったのか詳細が分かりづらいのに対し、Bedrock Agentはログまたはコンソール上からトレースのステップを確認できます。「どのツールを、どんなパラメータで呼び出し、どんな結果が返ってきたか」が分かるため、デバッグが格段に楽になりました。
Bedrock Agentsをコンソールから実行してトレース ステップを確認
このステップで直面した課題
プロトタイプの検証を進める中で、実運用を見据えた際の課題が明確になりました。
- 決定性の欠如: 「ドキュメントの要約と定量データの取得」を依頼しても、ある時は両方のツールを使う一方、ある時はドキュメントの検索しかしないなど、動作が安定しませんでした。
- トレーサビリティの不足: デバッグ向けにコンソールから実行する際は画面でトレースのステップを追えるものの、APIとして実行する場合CloudWatch Logsに大量のテキストログが出力されます。そのため、特定の処理を追ったり、性能ボトルネックを分析したりするのが非常に煩雑でした。
PoCから次のステップへの移行判断
上記の課題は、この段階では許容できるものでした。しかし、安定した精度とそのための継続的な精度改善を目指す上ではネックになります。解決するためには、少なくとも以下の点を満たす必要があると考えました。
- ① 動作の「決定性」を担保できるか？: 動作が不安定なままでは精度の安定が期待できません。リクエストに対し、毎回安定して期待通りのアクションを実行できる必要があります。
- ② 継続的な「改善サイクル」を構築できるか？: 精度や速度面の課題への迅速な原因特定（トレーサビリティ）と、修正後の品質を定量的に評価する仕組み（評価基盤）を構築し、データに基づいた改善サイクルを回し続けられる状態が必要です。
Bedrock Agentsはある程度の段階までの検証には非常に優れていましたが、これらの基準を満たすためには、よりコードレベルでの制御が必要だと判断し、Step3への移行を決めました。
Step 3: 実用精度への引き上げ (LangChain)
Bedrock AgentsでのPoCで基本的な価値と実現性を確認できましたが、次のステップは、これを「動くもの」から「実用的な精度を持つもの」へと引き上げることでした。精度を安定させ、継続的なチューニングを行うための基盤として、私たちはLangChainを用いたシステム構築に移行しました。
なぜLangChainだったのか？
Step2で直面した**「決定性」と「トレーサビリティ」の課題を、コードレベルで完全に解決したかったから**です。
LangChainによって解決できたこと:
- 決定性の制御 (LangGraph): タスク内での順序、つまり「まずKnowledgeBaseで関連ドキュメントを検索し、次にその内容に関連する定量データをLambdaでDBから取得する」という流れを状態遷移図のように固定化。これにより、常に期待通りの手順でAgentが動作するようになりました。
- トレーサビリティの確保 (Langfuse): オープンソースの監視ツールLangfuseと連携し、ツールの実行履歴、レイテンシ、LLMの入出力といった全プロセスを詳細に可視化。これにより、デバッグと評価のサイクルを高速化できました。
LangGraphの実行プロセスをLangfuseで可視化
- 評価の自動化: Langfuseを用いて、特定の評価データセットに対する振る舞いをバージョンごとに比較・評価する仕組みを構築し、継続的な品質管理を可能にしました。
- I/Oの型制御: Pydanticのモデルを用いてLLMの出力を構造化し、後続処理の安定性を向上させました。
移行のコストとトレードオフ
もちろん、LangChainへの移行はメリットばかりではありません。Bedrock Agentsの手軽さと引き換えに、以下のようなコストが発生します。
- 実装コストの増加: LangChainを使ってエージェントのロジックをすべてコードで記述する必要があります。GUIで設定できたBedrock Agentsと比べ、開発工数は増加します。
- インフラ管理の必要性: Bedrock AgentsがAPIエンドポイントまで自動で提供してくれたのに対し、LangChainで構築したアプリケーションをAPIとして提供するには、Amazon ECSやAWS Lambdaなど、別途サーバー環境を構築・管理する必要があります。
私たちは、これらのコストを差し引いても、「決定性」と「トレーサビリティ」を確保して継続的な改善サイクルを回せるようにするメリットの方が大きいと判断し、移行しました。
新しいユースケースを試すには？
一度Step3の基盤を構築すると、Lambda関数などのデータ連携ツールが手元に揃います。では、これまで検証してきたユースケースとは全く異なる、新しいアイデアのPoCを始める場合、どのステップから着手するのが最適でしょうか？
結論から言うと、私たちはStep3から始めることはありません。実装コストの高いStep3からいきなり着手するのは非効率だからです。代わりに、そのアイデアの性質に応じてStep1かStep2に戻り、再びPoCをスタートします。
Step1とStep2どちらに戻るかの判断軸の例としては「検証したいデータソースが新しいか、既存のものか」があります。
-
全く新しいデータで検証する場合 → Step 1 (Cursor) から
新しいアイデアが、まだ連携基盤のない、全く新しい種類のデータソース（例: 新しい形式のドキュメントや、今まで扱っていなかった定量データなど）を必要とするなら、私たちはStep 1に戻ります。**Step 1の目的であった「超高速なアイデア検証」**に立ち返り、まずはその新しいデータソースから価値のある情報が引き出せそうかを、Cursorを使ってシンプルに検証するのが先決です。 -
既存のデータで別のユースケースを試す場合 → Step 2 (Bedrock Agents) から
一方で、新しいアイデアが、既にLambda関数などで連携済みの既存データ（今回の例では定量データ用のデータベース）を使って実現できる場合は、Step 2から始めるのが最も効率的です。データ連携部分はそのまま再利用し、Bedrock Agentsで新しい指示プロンプトやツール連携のロジックを試すことで、素早くプロトタイプを構築できます。
このように、私たちの開発プロセスは一方通行ではなく、検証したい内容に応じて最適なステップを柔軟に選択するサイクルとなっています。
まとめ
私たちの経験から、AI Agentシステムの開発では、プロジェクトの成熟度に合わせてツールを使い分ける段階的なアプローチが非常に有効だと考えています。
以下に、各ステップへの移行を考える上でのポイントを改めてまとめます。
-
超高速なアイデア検証 (例: Cursor)
- 目的: アイデアの幹的な価値（刺さるか＆できそうか）を検証する。
- 移行のポイント: コードを書かずに、最速で試せるか？
-
迅速なプロトタイピング (例: Bedrock Agents)
- 目的: 動くPoCを構築し、ツール連携を具体的に検証する。
- 移行のポイント: Agentのロジック構築に集中し、素早くPoCを構築できるか？
-
実用精度への引き上げ (例: LangChain)
- 目的: PoCを実用的な精度まで引き上げ、継続的な改善を可能にする。
- 判断基準: 動作の決定性、トレーサビリティ、評価の仕組みをコードで制御できるか？
いきなり完璧なシステムを目指してコードを書き始めるのではなく、まずは手元のツールでユースケースそのものをシンプルに検証し、徐々にシステムの堅牢性を高めていく。この記事で伝えたかったのは、プロジェクトの不確実性と向き合いながら特性の違うツールへとステップアップしていく開発プロセスそのものです。このアプローチが、皆さんのプロジェクトにおける技術選定の一助となれば幸いです。
Discussion