AIエージェント開発入門｜仕組み・手順・運用まで基礎解説

AIエージェント開発とは、目的から手順を組み立て道具を使って最後まで動く仕組みを作ることです。

チャットに答えを返すだけの生成AIと違い、検索や更新といった道具を自分で選び、結果を見て次の手を決めます。この記事は、これから作ってみたい技術者と、社内で開発や導入を検討する担当者に向けて書いています。

AIエージェントそのものの定義や活用例は、親記事のAIエージェントとは何かで扱っています。社内へのAI導入全体をどう進めるかは、AI導入の進め方にまとめました。

入門でつまずく失敗は、作り方の手前にある

2026年9月時点で、検索上位の多くは書籍『AIエージェント開発/運用入門』の販売ページや書評、ハンズオン記事です。書籍の目次は全体像から推論、フレームワーク選び、MCP、UI、マルチエージェント、監視評価、継続改善へと進みます。

一方で、読み終えても「自社のどの業務を任せるか」は決まりません。入門者が本当に詰まるのは、作り方の手前にある業務の切り出しです。

この記事の読み方（読む順番の流れ）

この記事は、定義：何が作れるか、仕組み：推論と道具、手順：目標から監視、運用：失敗を直す、学び方：書籍と実践、の5段で進めます。書籍の紹介で終わらせず、任せる業務の判定と運用までを一続きに示します。

• 定義：何が作れるか。似た言葉との違いから、エージェントの境界を決めます
• 仕組み：推論と道具。内部の動作の循環と、MCPやメモリの役割を押さえます
• 手順：目標から監視。目標設定からデプロイ・監視までの工程を追います
• 運用：失敗を直す。本番後に何を見て何を直すかを、実際の回し方とあわせて書きます
• 学び方：書籍と実践。書籍、GitHub、電子版の使い方を整理します

違いは、AIが自分で判断し、道具を使い、失敗しても進め方を変えて続けるかどうかです。

生成AI（文章や画像を作る技術の総称）は、問われた内容に答えを返します。チャットボット（決められた会話の流れで応対する仕組み）は、分岐を人が設計します。RPA（決めた操作をそのまま繰り返すソフトウェアロボット）は複数手順を実行しますが、手順の判断は人が事前に固定します。

判断・道具・複数手順・再試行で見分ける

判断の主体、道具の利用、複数手順の実行、失敗時の再試行を、生成AI・RPA・チャットボット・AIエージェントの順で並べると境界がはっきりします。判断の主体がAIに移り、失敗時の再試行まで自分で行うのがAIエージェントです。

• 判断の主体：次に何をするかを人が決めるか、AIが決めるか。ここがAIになるのがエージェントです
• 道具の利用：検索、データベース更新、メール送信などの外部の道具を使えるか
• 複数手順の実行：ひとつの目的のために、複数の手順を続けて実行できるか
• 失敗時の再試行：結果が期待と違ったときに、別の手を試して進められるか

「エージェンティックAI」との違い・呼び分け

「エージェンティックAI」という語も同じ文脈で使われますが、製品を指すか性質を指すかで使い分けがあります。呼び分けの詳細は、兄弟記事「AIエージェントとエージェンティックAIの違い」で扱います。

RPAとの違いは、業務を置き換える判断で効いてきます。手順が完全に固定できるならRPAで足り、途中で判断や例外処理が入るならエージェントの出番です。

エージェントは、推論で次の一手を決め、ツールを実行し、結果を確かめて応答する循環で動きます。

中心にあるのはLLM（大規模言語モデル、文章を理解し生成するAIモデル）です。LLM単体では文章しか返せないため、外部の道具を呼ぶ仕組みと、途中経過を覚えるメモリを組み合わせてエージェントになります。

ひとつの動作の流れ

一度の動作は、入力：目的を受ける、推論：次の一手を決める、ツール選択：MCP経由も可、実行：検索や更新、結果確認：足りなければ戻る、応答：人に返す、の6工程を回ります。結果確認で足りなければ推論に戻るため、循環になります。

• 入力：目的を受ける。人からの依頼や、他システムからのイベントが起点です
• 推論：次の一手を決める。LLMが状況を読み、どの道具をどう使うかを決めます
• ツール選択：MCP経由も可。使える道具の一覧から、目的に合うものを選びます
• 実行：検索や更新。選んだ道具を実際に動かし、結果を受け取ります
• 結果確認：足りなければ戻る。目的に達したかを判定し、不足なら推論へ戻ります
• 応答：人に返す。まとめた結果を人か次の工程へ渡します

メモリとMCPとは：役割

メモリは、会話の途中経過や過去の実行結果を保持する仕組みです。短期のやり取りを覚える部分と、業務データや過去の判断を長期に保持する部分に分けて設計します。

MCP（Model Context Protocol、AIと外部ツールをつなぐ共通の接続規約）は、ツール選択と実行の間を標準化します。道具ごとに個別の接続コードを書かずに済むため、道具を増やしやすくなります。

書籍で学ぶ順番（学び方の手順）

書籍『AIエージェント開発/運用入門』は、LLMのAPIを直接呼ぶ推論から入り、MCPを使ったエージェント、画面までのUI実装、複数エージェントの協業へと進みます。推論の章では、Amazon BedrockのConverse API（複数のモデルを同じ形式で呼べるAPI）でLLMを呼ぶ手順から始まります。

この順番は、単体の推論、道具の接続、人に見せる画面、役割分担の順に複雑さを足していく学び方です。複数エージェントが協業するマルチエージェントの制御は、兄弟記事「マルチAIエージェントとは」で詳しく扱います。入門では、まず単体のエージェントを最後まで動かすところから始めます。

任せて効果が出るのは、手順を言葉にでき、失敗を検知でき、件数の多い業務です。

AIエージェントで作れるものの事例

• 問い合わせメールを読み、社内の資料を検索して一次回答の下書きを作る
• 会議の文字起こしから決定事項を抜き出し、タスク管理ツールに登録する
• 請求書のデータを会計システムと照合し、差異があれば担当者に知らせる
• 指定した観点で複数サイトを調べ、比較レポートの下書きをまとめる

共通するのは、途中で検索や更新といった道具を使い、最後は人が確認する点です。全自動にせず、確認点を残す設計が入門では現実的です。

任せてよい業務を5項目でチェックする

業務を選ぶときは、手順が言語化可、判断材料がデータ、失敗を検知可、人の確認点あり、件数が多い、の5項目で判定します。全部に当てはまる業務から着手すると、開発も運用も軽くなります。

• 手順が言語化可：熟練者が口頭で説明できる手順は、プロンプトと設計に落とせます
• 判断材料がデータ：判断に必要な情報が、システムや文書として存在するか
• 失敗を検知可：結果の正誤を、ルールか人の目で確かめられるか
• 人の確認点あり：送信や更新の前に、人が止められる箇所を置けるか
• 件数が多い：手順を組み立てる手間に対し、回す回数が見合うか

詳しい判定表は、親記事「AIエージェントとは何か」の「任せてよい業務の判定基準」にあります。ここでは再掲しません。

待てば解決する弱点と、待っても解決しない弱点の違い

私たち株式会社くるみは、AIの弱点を「待てば解決する側」と「待っても解決しない側」に分けて、支援先の業務を整理してきました。モデルの推論精度や長い文脈の扱いは、モデルの更新で改善するため後回しにします。

手順が決まっていない、判断材料が誰かの頭の中にある、といった業務側の整理不足は待っても直りません。開発に入る前に、こちらを先に潰します。

開発は、目標と範囲を決めてから、設計・選定・実装・評価・監視の順に進めます。

IBMの手順ガイドも、目標設定と範囲設定から始めてデプロイと監視で終わる流れを示しています（IBM「AIエージェント開発とは」）。書籍の章構成も、フレームワーク選び、実装、監視、評価とほぼ同じ順です。

6工程の手順の中身

工程は、目標と範囲：何をどこまで、設計：工程と確認点、FW・モデル選定：必須条件で絞る、実装：ツール接続、評価：失敗率を測る、デプロイ・監視：ログを残す、の順です。前の工程が曖昧なまま次へ進むと、後で戻る量が増えます。

• 目標と範囲：何をどこまで。任せる業務をひとつ選び、どこから先は人がやるかを決めます。前節の5項目がそのまま使えます
• 設計：工程と確認点。動作の循環を業務の手順に当てはめ、人の確認点をどこに置くかを図にします
• FW・モデル選定：必須条件で絞る。フレームワーク（FW、開発の土台となる部品群）とLLMを、日本語資料やMCP対応などの必須条件で絞ります
• 実装：ツール接続。検索や更新に使う道具をつなぎ、プロンプトを書き、まず一本の流れを通します
• 評価：失敗率を測る。実際の業務データで動かし、どの工程でどう失敗するかを数えます
• デプロイ・監視：ログを残す。本番に置き、推論の内容と道具の実行結果を後から追える形で残します

内製か外注かの判断は、選定と実装の前に

FW・モデル選定と実装の段階で、内製か外注かの判断が要ります。技術者が社内にいても、任せる業務の整理が済んでいなければ、外部の伴走を入れた方が早く進む場合があります。私たちは業務側の整理から伴走する形を業務改善の支援として用意し、実装の前に業務の切り出しを終える進め方を取っています。

コードを書いて実際に動かす具体手順は、詳しくはAIエージェントの作り方にまとめています。

選ぶ基準は、入門で必須の条件を先に満たし、差が付く条件を後から比べることです。

選び方の基準：入場券と差が付く条件を分ける

条件は、日本語資料、MCP対応、マルチ制御、監視連携、学習コストを、入門で必須と後で差が付くの列で見ます。◎はその段階で最初に効く条件、○は両方の段階で効く条件、△はその段階では優先度が低い条件です。

• 日本語資料：入門では◎。日本語の書籍や公式解説があるかで、詰まったときの復帰速度が変わります
• MCP対応：どちらも○。道具の接続規約に対応しているかは、最初から本番まで効きます
• マルチ制御：後で◎。複数エージェントの役割分担は、単体が動いてから比べれば足ります
• 監視連携：後で◎。ログや評価ツールとのつなぎやすさは、本番運用に入る手前で差が出ます
• 学習コスト：入門では◎。最初のひとつを動かすまでの手間は、続けられるかを左右します

私たちは、必須条件を「入場券」、差が付く条件を「POD（差別化の要因）」と呼び分け、混同しないと決めています。入場券を満たさない候補は比較の土俵に乗せず、PODは入場券を通った候補同士で後から比べます。

主なフレームワークの比較と位置づけ（2026年9月時点）

特定のフレームワークを推すことはしません。書籍が扱う候補は日本語資料の条件を満たしやすい、という程度の目安です。ツールごとの機能比較は、詳しくはAIエージェント開発ツールの比較にまとめています。

本番後に見るのは失敗のログで、直すのはプロンプトかツールの定義です。

書籍の後半では、Langfuse（LLMアプリの動作記録と評価を行う監視ツール）を使った運用の技法を解説しています。トレース（一度の動作で何を推論しどの道具を呼んだかの記録）を残し、評価と改善を繰り返す流れです。

循環の流れは「ログ→分類→修正→再評価」

運用は次の循環で回します。

• ログを残す：推論の内容、選んだ道具、結果を、後から追える形で保存する
• 失敗を分類：期待と違った動作を、原因の種類ごとに分ける
• プロンプトかツールを直す：分類ごとに、指示の書き方か道具の定義を変える
• 再評価：同じ入力で動かし直し、失敗が減ったかを確かめる

作って放置は失敗する：週次で潰すとの差

同じエージェントでも、作って放置と週次で潰すでは、しばらく経った後の姿が変わります。放置すると失敗が業務の中で黙って積み上がり、週次で潰すと失敗の種類が減っていきます。

• 作って放置：失敗が現場の手戻りとして吸収され、開発側に戻ってこない状態です
• 週次で潰す：失敗を毎週分類し、直せるものを直して再評価する状態です

週次の分類は、次の3行を1件ごとに埋めるだけで回ります。

何が起きたか：道具の呼び出しが失敗した／答えが違った／途中で止まった。 待てば解決するか：モデルや道具の改善で消える側か、業務側の手順不足か。 今週直すか：業務側の不足だけを直し、残りは記録して次回に回す。

私たちの回し方：失敗ログの分類基準

私たちは社内のエージェントの失敗ログを毎週分類し、待てば解決する側と待っても解決しない側に分けています。モデルの性能に起因する側は次の更新を待ち、業務定義に起因する側だけを即修正します。支援先でも同じ分け方を使い、直す対象を業務側の不足に絞っています。

この運用は匿名の自社支援記録に基づくもので、第三者による検証は受けていません。導入している企業の動きは、公開後の兄弟記事「AIエージェントの導入企業事例」で扱います。

書籍はハンズオンを動かしながら読み、コードは著者公開のGitHubから取ります。

目的×経験で学び方を選ぶ基準

学び方は、横軸をコード経験の有無、縦軸を目的が作ることか任せることか、で分けると決めやすくなります。自分の位置に合う象限から始めます。

• コード経験あり×作ること：書籍のハンズオンを章の順に進め、自分の業務データで動かし直す
• コード経験なし×作ること：著者公開のサンプルコードを写経し、動く状態から差分を読む
• コード経験あり×任せること：業務整理から着手し、前節の5項目で任せる業務を先に決める
• コード経験なし×任せること：親記事と判定表から読み、開発は社内か外部の技術者と組む

書籍・電子版・GitHubの使い方の比較

書籍『AIエージェント開発/運用入門』は、SBクリエイティブが製品ページで試し読みと読者特典のサンプルコード配布を案内しています。電子版は各ストアの電子書籍として提供されるもので、PDFファイルとしての配布ではありません。2026年9月時点の入手先は出版社ページから確認できます（SBクリエイティブ 製品ページ）。

サンプルコードは著者が公開するGitHubリポジトリにあり、章ごとのフォルダに分かれています。使用モデルの廃止に伴う差し替えなどの更新もリポジトリで告知されるため、書籍の内容と差分があるときはまずここを見ます（著者公開のサンプルコード（GitHub））。

書評やハンズオン記事が多い理由

検索上位に書評やハンズオン記事が多いのは、手を動かして初めて詰まる点が分かるからです。環境構築や道具の接続でつまずいた記録は、次に同じ場所で止まる人の地図になります。

『AIエージェント開発/運用入門』のサンプルコードはどこにある？

著者が公開するGitHubリポジトリにあります。章ごとにフォルダが分かれ、書籍のハンズオンに対応しています。使用モデルの廃止や依存パッケージの更新に伴う修正もリポジトリで告知されるため、書籍どおりに動かないときは最初にお知らせを確認します。

PDF版はある？入手方法は？

2026年9月時点で、出版社が案内している電子版は各ストアの電子書籍です。PDFファイルとしての配布は案内されていません。入手先と試し読みは、SBクリエイティブの製品ページから確認できます。書籍の更新情報は、著者のGitHubリポジトリでも告知されます。

プログラミング未経験でも開発できる？

試作までなら、ノーコード系のエージェント作成ツールで可能です。ただし、動くものができても、任せる業務の手順や判断材料が整理されていなければ本番では使えません。未経験の方は、先に業務の整理と5項目の判定に取り組み、実装は社内か外部の技術者と組む形が現実的です。

フレームワークはどれから学べばよい？選び方は？

入門では、日本語資料と学習コストを先に見ます。書籍で扱われるものは日本語で追えるため、最初のひとつとしては選びやすい候補です。複数エージェントの制御や監視ツールとの連携は、単体のエージェントを動かしてから比べれば足ります。特定の製品を推すことはしません。

開発と運用はどちらが難しい？失敗しやすいのは？

運用です。開発はサンプルコードと書籍の手順で一本の流れを通せますが、運用は本番で起きる失敗を記録し、分類し、直して再評価する循環を続ける必要があります。私たちは失敗を待てば解決する側と待っても解決しない側に分け、後者だけを毎週直しています。

明日やることは、任せてよい業務を5項目で判定し、ひとつ選んで小さく作ることです。

この記事は、定義：何が作れるか、仕組み：推論と道具、手順：目標から監視、運用：失敗を直す、学び方：書籍と実践、の5段で進めてきました。書籍で作り方を学ぶ前に、どの業務を任せるかを決めるのが入門の出発点です。

次の一手（手順）

• 自社の業務をひとつ選び、手順が言語化可・判断材料がデータ・失敗を検知可・人の確認点あり・件数が多い、の5項目で判定する
• 当てはまる業務から、書籍のハンズオンかサンプルコードで一本の流れを通す
• 本番に置いたら失敗ログを残し、週次で分類して業務側の不足から直す

親記事「AIエージェントとは何か」の判定表と、「AI導入の進め方」の全体設計を手元に置くと、判定と開発の順番がぶれません。

どの業務から置き換えるか迷うときの判断

判定の途中で、どの業務から着手するか迷う場合があります。その場合は、AIおきかえくんの無料診断で、業務ごとに置き換えの向き不向きを整理できます。

AIエージェントの開発や、任せる業務の切り出しについて相談したい方は、株式会社くるみのお問い合わせフォームからご連絡ください。私たちは業務の整理から開発、運用の回し方まで、社内で実際に回している形をもとにお話しすると決めています。