ChatGPTで止まっていない？エンジニアが今すぐ試したいAIエージェント構築ステップ

ChatGPTや生成AIのAPIを業務に取り入れているエンジニアは増えましたが、その多くが「質問して、答えをもらう」段階で止まっています。

一方、開発現場では、AI自身がツールを操作してタスクを最後までやり切る「AIエージェント」が主役になりつつあります。

そこで本記事では、プロンプト利用から一歩進み、実際に動くエージェントを組み上げるための判断基準と構築ステップを、実装目線で整理します。

AIエージェントとは、与えられた目標に対して、自分で計画を立て、必要なツールを使いながら、複数の手順を自律的に実行するAIの仕組みです。

「現状を観察し、次に何をすべきか考え、行動する」というループを目標達成まで繰り返す点が特徴です。

この動作はReActループとも呼ばれ、検索・計算・外部API呼び出しといった行動を挟みながら、最終的なアウトプットにたどり着きます。

ChatGPTなどの対話型生成AIとAIエージェントの違いは、「外の世界に働きかけられるかどうか」と「自律的に手順を繰り返せるかどうか」にあります。

チャットは基本的に1回の質問に1回答える往復型ですが、エージェントは目標を達成するまで自分で何度もループを回し、外部ツールを呼び出して情報を取得したり処理を実行したりします。

両者の違いを整理すると、次のようになります。

ChatGPTは「優秀な相談相手」、エージェントは「指示を受けて実際に作業まで進める担当者」と捉えると、役割の違いがイメージしやすくなります。

(出典：openai.com)

多くのエンジニアがChatGPT利用の段階でとどまってしまうのには、以下3つの理由があります。

• 単発のプロンプトでも成果が出てしまう
• フレームワークが乱立して選べない
• エージェント特有の設計知識に触れる機会が少ない

技術力の問題というより、「次に進む必要性を感じにくい」「進み方が見えない」という構造的な要因が大きいといえます。

ChatGPT利用で止まる要因は、「そのままでも十分に役立ってしまう」ことにあります。

問題がすぐに解決するため、わざわざ仕組みを自律化しようという動機が湧きにくいのです。

その結果、次のような状態が固定化していきます。

• 毎回プロンプトを書いて、返ってきた答えを自分で次の作業につなげている
• 同じような問い合わせや処理を、何度も手作業で繰り返している
• 一連の流れを自動化できることに気づかず、属人的な運用が続いている

問題は、この「便利だが都度手作業」の状態に大きな伸びしろが隠れている点です。

たとえば、調査して要約し、結果を整形して別システムに登録するといった多段の作業は、本来エージェントに任せれば一気通貫で自動化できます。

エージェント開発に進もうと決めても、選択肢の多さが壁になります。

LangChainやLangGraphなど、フレームワークが次々と登場し、どれも一長一短に見えるため、「まず何から触ればよいのか」が判断できず、選定の段階で消耗してしまうのです。

しかし、実際は主要なフレームワークが扱う基本概念は共通しており、一つを習得すれば他への移行はそれほど難しくありません。選定で立ち止まるより、まず一つ動かしてみる方が学びは早く進みます。

迷ったときの選び方の目安を整理すると、次のようになります。

完璧な一つを探し続けるのではなく、「使い慣れた言語に合うものを一つ選び、最小構成で試す」と割り切ることが、選定の迷いから抜け出す方法です。

3つ目の要因は、エージェント開発に必要な設計知識が、通常のアプリケーション開発の延長線上にない点です。

ツールの呼び出し、複数ステップを自律的に進めるための制御といった考え方は、一般的なWeb開発や業務システム開発ではあまり扱いません。

そのため、開発スキル自体は十分にあっても、エージェントならではの勘所に触れる機会がないまま過ごしてしまいがちです。

具体的には、次のような点で「何を学べばよいか分からない」という状態に陥りやすくなります。

• LLMにどう関数を呼ばせ、その結果をどう次の処理に渡すのかが分からない
• 会話の文脈やタスクの途中状態を、どこにどう保持すればよいか判断できない
• 「観察→思考→行動」を繰り返すループを、どう実装すれば暴走しないのか不安が残る
• 通常の単体テストとは異なる、出力品質の評価方法がイメージできない

これらはいずれも、一般的な開発経験だけでは自然に身につきにくい領域です。逆に言えば、この数項目さえ押さえればエージェント開発は可能です。

すべての業務をエージェント化すべきというわけではありません。むしろ向き不向きを見極めずに作り始めると、PoCが頓挫したり、運用コストだけがかさんだりします。

構築すべきかを判断するうえで有効なのが「検証可能性(verifiability)」という視点です。

出力の正しさをその場で確認しやすいタスクほどエージェントは力を発揮し、検証が難しく失敗の代償が大きいタスクほど慎重なガードレールが必要になります。

判断の目安を整理すると、次のように分けられます。

たとえば社内問い合わせの一次対応、定型レポートの作成などは、検証しやすく繰り返しも多いため好相性です。

一方で、最終的な意思決定や高リスクな承認業務は、人間が握ったうえで補助的に使う設計が適しています。

まずは「検証しやすく、繰り返しの多い業務」から小さく始めるのが失敗しないコツです。

AI開発を始めるにあたっての解説は、こちらの記事で紹介しています。

構築は、いきなりコードを書く前の準備で品質の大半が決まります。

ここでは「社内の問い合わせを一次対応するエージェント」を例に、着手前に固めておくべき3つのポイントを押さえながら進めます。

• 解決したい業務を一つに絞る
• エージェントを支える5つの構成要素
• フレームワークは目的で選ぶ

準備が整ったら、最小構成のエージェントを段階的に組み上げます。

以下5つのステップで一つずつパーツを足し、最終的に「検索して答え、無理なら担当者へ振り分ける」エージェントを完成させていきます。

1. 役割と制約をプロンプトで定義する
2. ツール呼び出しで外部に手を伸ばす
3. RAGで社内の知識とつなぐ
4. 処理の流れをループとして組む
5. 暴走を止めるガードレールを入れる

最初に行うのは、LLMに一次対応窓口としての役割を与えることです。システムプロンプトで「誰として」「何を」「どんな出力形式で」答えるかを明示します。

あわせて、

• 推測で断定しない
• 社内ポリシーに反する案内はしない
• 分からないときは確認を促す

といった制約も書き込みます。この土台が曖昧だと後続のツール連携やRAGを足しても挙動が安定しないため、役割・制約・出力形式の3点を丁寧に設計しましょう。

エージェントが「行動」するための核がツールの呼び出しです。

たとえばFAQを検索する関数を一つ用意し、入力と出力のスキーマを定義したうえで、LLMが必要に応じてその関数を呼び出し、戻り値を回答に反映できるようにします。

ここを実装すると、エージェントは自分で情報を取りに行って答える存在へと変わります。まずは一つのツールを確実につなぎ、呼び出し→結果反映の流れを安定させることが大切です。

外部APIの知識だけに頼ると、自社固有の情報には答えられません。そこでRAG（検索拡張生成）を使い、社内ドキュメントを根拠に回答できるようにします。

具体的には、ドキュメントを埋め込みベクトルに変換してベクトルデータベースに格納し、問い合わせ時に関連箇所を検索して文脈として渡します。

これにより「APIに丸投げ」から「自社データで裏付けて答える」へと品質が上がり、回答の正確性と信頼性が高まります。

単発の応答から多段タスクへ進めるために、処理の流れをループとして定義します。

以下は一連の流れです。

• 問い合わせを受け取る
• 社内情報を検索する
• 回答できるか判断する
• 回答するか担当者へ振り分ける

フレームワーク上でグラフや状態遷移として表現します。状態管理と分岐を明示的に組むことで、複数の手順を自律的に、かつ追跡可能な形で実行できるようになります。

自律的に動くからこそ、暴走や無限ループ、誤った断定を防ぐ仕組みが必要です。

例えば、

• リトライ回数の上限を設ける
• 入出力をバリデーションする
• 自信が低い場合は人間へエスカレーションする

といった安全装置を実装します。現場では、壁は能力ではなく制御と言われるほど、この制御設計が重視されています。

確信が持てない問い合わせは無理に答えさせず、有人対応へ確実に渡す設計が安全運用の分かれ目です。

Pythonを使った開発時におけるポイントと注意点に関しては、こちらの記事で詳しく紹介しています。

構築編で挙げた6つのステップを、ここからは実際のコードに落とします。

題材は同じく「社内問い合わせの一次対応エージェント」です。FAQを検索し、社内ドキュメントを根拠に答え、確信が持てなければ担当者へ引き継ぐ、という最小構成です。

1. 環境とライブラリを用意する
2. 状態とツールを定義する
3. RAGで社内ドキュメントを検索できるようにする
4. LangGraphでループとして組み上げる
5. ガードレールとエスカレーションを足す
6. 動かして挙動を確認する

仮想環境を切ってから、必要なパッケージを入れます。

APIキーの管理(.env方式、推奨)

毎回exportするのは面倒なので、プロジェクトルートに.envファイルを作成します。

.gitignoreに追加します。

LangGraphでは、エージェントが持ち回る「状態（State）」を最初に決めます。

ここに会話履歴を入れ、あわせてリトライ回数とエスカレーション判定も持たせます。後者の2つが、暴走を止めるガードレールの土台です。

messages に付けている add_messages がポイントです。これを忘れて list のままにすると、ノードが返すたびに履歴が上書きされ、多段のやり取りが成立しません。

LangGraphでよく見る「messages requires a reducer」というエラーは、ここの付け忘れが原因です。

次に、エージェントの「行動」にあたるツールを用意します。関数に @tool を付け、docstringに用途を書くだけです。

このdocstringがそのままLLMへの説明文になり、いつ呼ぶべきかの判断材料になります。中身（FAQ検索の実体）は次のRAGの節で差し込みます。

役割と制約は、システムプロンプトで言葉にしておきます。「何を根拠に答えるか」「分からないときどうするか」を以下のようなルールで縛っておくことで挙動を安定させます。

外部の知識だけでは自社固有の質問に答えられません。そこで社内ドキュメントを埋め込みベクトルに変換し、問い合わせ時に近いものを引っ張ってきて根拠にします。

本番ではPostgres(pgvector)やQdrantといったベクトルDBを使いますが、構造を理解するだけなら手元で動く InMemoryVectorStore で十分です。差し替えてもエージェント側のコードは変わりません。

これで先ほどの search_faq が実際に動くようになります。クエリを渡すと、意味の近いドキュメントが上位から返ってきます。「自社データで裏付けて答える」に変わるのがこの部分です。

実運用ではドキュメントをそのまま入れず、適切な長さに分割（チャンク化）してから格納します。1件が長すぎると検索のヒット精度が落ち、短すぎると文脈が切れるためで、ここは扱う文書に合わせて調整する箇所です。

⚠️ ハマりどころ

store.add_documents(docs)は追加されたドキュメントのID一覧を返しますが、今は使っていません。後で特定のドキュメントをdeleteしたい場合に備えて、IDを保持しておくと管理がしやすくなります。

python　ids = store.add_documents(docs)

ここからが構築編の「処理の流れをループとして組む」に対応します。やることは、問い合わせを受け取り、検索し、答えるか引き継ぐかを判断する、という流れをグラフとして表現することです。

まずLLMに先ほどのツールを結びつけ、各ノードを定義します。

LLMの返答にツール呼び出しが含まれていればツールを実行し、その結果を履歴に戻して、もう一度LLMに考えさせる。

この往復が、記事の前半で触れたループの実体になっています。

ここでは自律的に動くからこそ生まれるリスクに、2つの仕組みで対処します。1つはツール呼び出し回数の上限、もう1つは上限を超えたときに担当者へ引き継ぐ処理です。

エージェントはLLMの判断でツールを何度も呼び出せますが、放っておくと「ツールを呼ぶ→答えが出ない→また呼ぶ」というループから抜け出せなくなる可能性があります。そこで、リトライ回数が上限に達したら、無理に回答を続けさせるのではなく、人間の担当者へ引き継ぐようにします。

この「次にどのノードへ進むか」を決める部分は、LangGraphでは分岐関数として実装します。今の状態(state)を受け取り、進むべきノードの名前を文字列で返すだけのシンプルな関数です。

最後に、ノードと分岐をつないでグラフを組み立て、コンパイルします。

組み上がったエージェントに、システムプロンプトと質問を渡して実行します。状態の初期値として retries と escalate も忘れずに入れます。

質問を受けると、エージェントはまず search_faq を呼んで就業規則を引き、その内容を根拠に「入社半年後に10日付与されます」といった形で答えます。

一方、ドキュメントに載っていない質問を投げれば、推測で答えず escalate 側へ抜けて担当者に引き継ぐ、という分岐が働きます。

ここまでで、検索して答え、無理なら人へ渡す最小構成のエージェントが一通り動きます。あとはツールを増やし、ベクトルDBを本番用に差し替え、評価と可観測性を足していけば、PoCから運用に乗せる段階へ進められます。

エージェントは作って終わりではなく、回し続けられる状態を保つことが求められます。ここでは運用で見落としやすい注意点を3つ解説します。

• 精度の劣化を測り続ける
• 実行の中身を見えるようにする
• コストと属人化を放置しない

エージェントの品質は、モデルの更新やデータの変化によって、気づかないうちに少しずつ低下します。

これを防ぐには、代表的な問い合わせをテストケース化し、回答の正確性や安全性を継続的に評価する仕組みを用意します。

変更を加えるたびに同じテストを回し、劣化を早期に検知できるようにしておくことで、「いつの間にか精度が落ちていた」という事態を避けられます。

エージェントが内部でどのツールを呼び、どう判断したのかが見えないと、障害もコスト超過も原因を追えません。

そのため、実行トレースを可視化し、各ステップの入出力やツール呼び出しの履歴を記録しておくことが重要です。

観測性を確保しておくことで、想定外の挙動が起きたときに原因を素早く特定でき、改善のサイクルも回しやすくなります。

エージェントの運用では、トークン消費やGPU時間といったコストが想定以上に膨らむことがあります。利用量を可視化し、予算として管理する仕組みを早めに整えましょう。

あわせて、環境構築や設定が特定のエンジニアに依存する「属人化」も避ける必要があります。テンプレートや権限、構成を標準化しておくことで、担当者が変わっても継続的に運用できる基盤になります。

運用設計まで含めて整えることが、PoCを本番に乗せ切るための最後の鍵となります。

AI開発にかかる費用相場や始める前の注意点などは、こちらの記事をご覧ください。

AIエージェントは、ChatGPTを使いこなせるスキルがあれば、エージェントを組み上げる素地はすでに整っています。

両者を分けているのは技術力の差ではなく、「最初の一歩を踏み出したかどうか」という一点に尽きます。

完璧な設計や最適なツールを探し続けるのではなく、検証しやすい業務を一つ選び、最小構成のエージェントを実際に動かしてみることが、重要です。

まずは社内で繰り返している定型業務を一つ書き出し、今日それをエージェント化する設計に落とし込んでみてください。

最小構成のエージェントが軌道に乗り、処理対象のデータ量や同時実行数が増えてくると、ChatGPTのAPI呼び出しだけでは応答速度やコスト面で壁にぶつかる場面が出てきます。社内文書の大量処理、独自モデルの追加学習、複数エージェントの並列稼働といった段階に進むときには、GPUを自社の裁量で確保できるクラウド環境が選択肢になります。