AIエージェント開発とは｜手順・環境・費用・個人での作り方

AIエージェント開発は『目標を渡すと自分で手順を組み、ツールを使って完了まで進むソフトウェア』を作ることです。要件定義・設計・実装・評価・運用の5工程で回します。社内業務をAIに任せたい担当者と、まず個人で一本作ってみたいエンジニアや企画職に向けて書いています。

作り方の手順そのものは親記事のAIエージェントの作り方で扱い、この記事は「開発とは何か」「何を任せ、どこで作り、誰に頼むか」の判断材料に絞ります。AIエージェントという言葉の整理は、既存記事のAIエージェントとはにまとめてあります。

開発は要件定義から運用までの5工程

開発の全体像は、要件定義で任せる業務を決め、設計でツールと権限を決め、実装でモデルとツールを繋ぎ、評価で任せられるか試し、運用でログを見て直す流れです。工程名はこの先のH3と対応させています。

• 要件定義：任せる業務を決める。どの業務を、どこまでAIに渡すかを先に固めます
• 設計：ツールと権限を決める。エージェントが使える道具と、触ってよい範囲を定めます
• 実装：モデルとツールを繋ぐ。言語モデルに道具の定義を渡し、呼び出せる状態にします
• 評価：任せられるか試す。動くかではなく、業務として任せられるかを確かめます
• 運用：ログを見て直す。実際の動きの記録を読み、ツールの定義や止め方を直します

AIエージェント開発の定義

AIエージェントは、独立行政法人情報処理推進機構（IPA）の技術コラムで「ユーザーから与えられた指示に基づき、自律的に問題解決やタスク実行を行うソフトウェア」と紹介されています（IPA SDS技術コラム：AIエージェント）。厳密な定義はまだ確立していないとも書かれています。開発の現場では「目標を渡せば、途中の手順は自分で組む」ことを条件にすると迷いません。

開発と呼ぶ範囲は、言語モデルそのものを作ることではありません。既存の言語モデルにツール・権限・記憶を組み合わせ、目標に向かって動くよう組み立てる作業がAIエージェント開発です。

チャットボット開発との違い

チャットボットとの差は、動き方・ツール・手順・向く業務の4行で見ると分かりやすくなります。チャットボットは一問一答で、ツールは使わない、手順は固定、向く業務はFAQ回答です。エージェントは目標まで自律で動き、検索・実行するツールを持ち、手順を状況で変え、複数手順の処理に向きます。

• 動き方：チャットボットは一問一答、エージェントは目標まで自律で進みます
• ツール：チャットボットは使わない、エージェントは検索・実行する道具を持ちます
• 手順：チャットボットは固定、エージェントは状況で変えます
• 向く業務：チャットボットはFAQ回答、エージェントは複数手順の処理です

一問一答で終わるならチャットボット、複数手順の処理ならエージェント。開発に入る前の切り分けは、この一文で足ります。

AIエージェントはモデル・ツール・記憶・計画の4要素で動き、開発で組み立てるのはモデル以外の3つです。システム開発として見ると、言語モデルは部品として調達し、その周りにツール・記憶・計画を配線する作業がAIエージェントのソフトウェア開発になります。

モデルとツール：判断と実行を分ける

モデルは言語モデル（大量の文章から言葉の扱いを学んだAI）で、状況を読んで次に何をするか判断する中核です。開発者はモデルを学習し直すのではなく、目標と制約を文章で渡し、どの道具が使えるかを教えます。判断の質はモデルに依存し、モデルの更新で変わります。

ツールは、エージェントが外の世界に触れるための関数やAPI（外部システムを呼び出す窓口）です。社内システムの検索、表計算の更新、メールの下書きなどを、モデルが呼び出せる形で定義します。開発工数の大半はここに集まります。

記憶と計画：文脈を保ち、手順を組む

記憶は、会話の途中経過や過去のやり取りを保持する仕組みです。短期の記憶は今のタスクの文脈を保ち、長期の記憶は過去の結果や社内資料を必要なときに取り出します。何を覚えさせ、何を忘れさせるかも開発側が決めます。

計画は、目標を小さな手順に分けて順番に進める仕組みです。モデルが自分で分解する場合と、開発者が骨格を用意する場合があります。どちらでも「いつ止まって人に確認するか」を決めるのは開発者です。

推論と実行のループ：開発者が書く部分

4要素が組み合わさると、指示を受け、推論し、ツール実行し、結果を観察し、回答するループになります。足りなければ推論に戻るので、複数手順の処理を一つの目標として渡せます。

• 指示を受ける：目標と制約を渡す。何を達成し、何をしてはいけないかを最初に渡します
• 推論する：次の一手を決める。モデルが状況を読み、使うツールと引数を選びます
• ツール実行：検索や更新を行う。定義済みの道具を呼び、外部の情報や状態を変えます
• 結果を観察：足りなければ戻る。実行結果を読み、目標に届かなければ推論に戻ります
• 回答する：完了か人に確認。完了を報告するか、判断を人に返します

開発者が書くのは推論そのものではありません。書くのはツールの定義と、ツールに与える権限と、ループをどこで止めるかの3点です。この3点を決めておけば、フレームワークが変わっても開発の考え方は変わりません。

設計パターンは3つあり、最初の一本はReAct型です。ReAct型・計画実行型・マルチエージェント型の順に難度が上がり、できることも部門をまたぐ処理まで広がります。アプリ開発として何を作るかは、この3つのどれで組むかでほぼ決まります。

ReAct型：調べて答える

ReAct型（推論と行動を交互に繰り返す型）は、前の節のループを一つのエージェントでそのまま回す最も単純な形です。「社内文書を検索して質問に答える」「注文状況を調べて報告する」のように、調べて答える仕事に向きます。ツールを1〜3個に絞れば、個人でも一本作れます。

計画実行型：手順が長い

計画実行型は、最初に目標を手順に分解し、その計画に沿って一つずつ実行する型です。手順が長く、途中の抜けが許されない業務に向きます。月次レポートのように、集める・整える・書くの順が決まっている仕事が例です。計画を先に出すので、人が途中で計画だけ確認する止め方も組めます。

マルチエージェント型：部門をまたぐ

マルチエージェント型は、役割の異なる複数のエージェントを分け、調整役がまとめる型です。部門をまたぐ業務や、専門ごとに知識を分けたい場面で検討します。作る難度は高く、エージェント同士のやり取りをどう評価するかが難所です。複数を束ねる製品や会社の比較は、既存記事のAIエージェント比較にまとめています。

3つを、向く仕事・作る難度・個人で作れるか・最初の一本に向くかの4行で並べます。向く仕事はマルチが部門をまたぐ、計画実行が手順が長い、ReActが調べて答えるで、作る難度は高い・中・低い、個人では難しい・可・可、最初の一本は△・○・◎です。

• 向く仕事：部門をまたぐならマルチ、手順が長いなら計画実行、調べて答えるならReActです
• 作る難度：マルチは高い、計画実行は中、ReActは低いです
• 個人で：マルチは難しい、計画実行は可、ReActは可です
• 最初の一本：マルチは△、計画実行は○、ReActは◎です

最初の一本はReAct型にし、ツールを1〜3個に絞ります。ループ・ツール定義・止め方の3点を一本で経験してから計画実行やマルチに広げると、設計の判断が速くなります。

任せてよい業務は、AIの弱点が『待てば解決する側』だけで構成される業務です。開発に入る前にこの判定をすると、評価の段階で要件定義に戻る回数が減ります。

AIの弱点2分法：待てば解決するか

私たち株式会社くるみは、AIの弱点を2つに分けて開発の着手を判断しています。モデル更新を待てば解決する側（精度・文脈長・速度）と、待っても解決しない側（責任の所在・社内の暗黙ルール・例外時の判断）です。後者を含む業務は、人の確認を工程に残します。

精度や文脈長は、モデルが更新されれば開発側が何もしなくても改善します。一方、誰が責任を取るか、社内でだけ通じる暗黙のルール、想定外が起きたときの判断は、モデルがどれだけ賢くなっても外から与えないと埋まりません。

2×2で着手を判定する

縦軸に弱点の側、横軸に手順の定型度を取ると、業務は4マスに分かれます。開発に踏み切るのは、待てば解決する弱点だけで、手順が定型のマスです。

• 待てば解決する弱点だけ×手順が定型：開発に踏み切る。ReAct型の最初の一本に向きます
• 待てば解決する弱点だけ×例外が多い：着手するが、人に返す条件を先に決めます
• 待っても解決しない弱点を含む×手順が定型：確認工程を残し、定型部分だけ任せます
• 待っても解決しない弱点を含む×例外が多い：今は人が持ち、記録を残して次の判定に備えます

中間的な定型作業から順に置き換える考え方もあり、迷ったときの補助線になります。

詳しい判定表と棚卸しは既存記事へ

業務ごとの詳しい判定表は、既存記事「AIエージェントとは」の判定基準にまとめてあるので、ここでは再掲しません。任せる前に業務を書き出す棚卸し5項目は、AI導入の記事で扱っています。詳しくはAI導入の進め方。

開発は要件定義から運用までの5工程を順に進めます。環境はLLM API（言語モデルを呼び出す接続口）とフレームワーク1つから揃え、評価データとログは業務に載せる段階で足します。個人で自作する場合の最小構成は最後にまとめます。

要件定義：任せる業務を決める

要件定義では、前の節の2×2で「開発に踏み切る」に入った業務を1つ選び、入力・出力・してはいけないことを文章にします。「問い合わせメールを読み、社内FAQを検索して返信案を作る。送信はしない」のように、動詞で書くと設計に渡しやすくなります。ここを省くと、評価の段階で何を正解とするかが決まらず戻ることになります。

設計：ツールと権限を決める

設計では、エージェントに渡すツールを1〜3個に絞り、それぞれに読むだけか、書き込めるかの権限を付けます。書き込む操作は最初は人の確認を挟み、ログで問題がないと分かってから自動化に進めます。止め方も設計項目で、ループを繰り返す上限と、人に返す条件を決めます。

実装：モデルとツールを繋ぐ

実装では、選んだフレームワークでモデルにツールの定義を渡し、推論と実行のループが回る状態にします。2026年9月時点では、LangGraphやOpenAI Agents SDKのようなフレームワークがループと状態管理を肩代わりするので、書くコードの多くはツールの中身と入出力の検証になります。最初はプロンプトとツール1つで動かし、ツールを1つずつ足すと原因の切り分けが楽です。

評価：任せられるか試す

評価で確かめるのは「動くか」ではなく「任せられるか」です。想定どおりの入力で正しく動くかに加え、曖昧な指示や情報不足のときに勝手に進めず人に返すか、してはいけない操作をしないかを試します。テストケースは開発者ではなく業務担当者が書きます。どの答えなら実務で受け取れるかを知っているのは担当者だからです。

運用：ログを見て直す

運用では、指示・推論・ツール実行・観察・回答のログを残し、人が定期的に読みます。直すのはモデルではなく、ツールの説明文、権限、止める条件です。人に返す件数が増えた、同じ失敗が続くといった変化を見て、要件定義に戻るかを判断します。

個人で自作する場合の開発環境

開発環境は、LLM API・フレームワーク・ツール権限・評価データ・ログと監視の5項目で揃え、個人とチームで要るものが違います。個人はLLM API○、フレームワーク△、ツール権限○、評価データ△、ログと監視×で始められ、チームで業務に載せる段階では評価データとログと監視が◎になります。

• LLM API：言語モデルを呼び出す接続口。個人もチームも最初に必要です
• フレームワーク：ループと状態管理を担う土台。個人は無くても書け、チームでは揃えます
• ツール権限：道具ごとの読める・書ける範囲。個人でも必要で、チームでは必須です
• 評価データ：任せられるかを試す入力と正解の組。個人は後からで足り、チームでは必須です
• ログと監視：動きの記録と異常の検知。個人は後回しでよく、チームでは必須です

個人で自作する場合は、LLM APIとフレームワーク1つ、ツール1〜3個から始めます。ログと監視は後回しでよく、評価データも自分で試した入力を溜めていけば足ります。フレームワークの機能や対応モデルは変わるので、選ぶときは2026年9月時点の公式資料で確認します。

私たちは要件定義と評価データの作成を業務担当者と一緒に行い、実装より先にテストケースを固めてから回しています。この進め方を「AI×実行」と呼び、業務へのAI導入と運用の支援として提供しています。

最初の一本は伴走で作り、運用が固まったら内製に寄せるのが答えです。費用は内製・外注・伴走という方式より、連携するツール数・例外処理の量・評価データの整備・運用体制の4つで決まります。金額は案件ごとに動くので、ここでは何で動くかを示します。

費用が動く4つの要因

連携するツール数が増えるほど、定義と権限設定と評価の組み合わせが増えます。例外処理の量は、待っても解決しない弱点をどれだけ人の確認に回すかで決まり、全部を自動化しようとすると膨らみます。評価データは業務担当者の時間が要り、運用体制はログを読む人を置けるかで継続の費用が変わります。

内製・外注・伴走の比較

3方式を立ち上がり・業務知識・改善の速さ・向く段階で並べます。立ち上がりは内製が遅い、外注が速い、伴走が速いで、業務知識は残る・残らない・残る、改善の速さは速い・遅い・速いです。向く段階は、内製が運用が固まった後、外注が要件が固定、伴走が最初の一本です。

• 立ち上がり：内製は遅い、外注は速い、伴走は速いです
• 業務知識：内製は残る、外注は残らない、伴走は残ります
• 改善の速さ：内製は速い、外注は遅い、伴走は速いです
• 向く段階：内製は運用が固まった後、外注は要件が固定、伴走は最初の一本です

最初の一本は伴走で進め、運用が固まったら内製に寄せます。要件が完全に固まっていて変更が少ない業務なら外注でも成り立ちますが、AIエージェントは運用で直す前提の仕組みなので、その条件に合う業務は多くありません。開発会社の選び方は既存記事「AIエージェント比較」で、任せる業務の棚卸しは「AI導入の進め方」で扱っています。

よく見るパターン：要件定義を省くと評価で戻る

私たちがよく見るのは、要件定義を省いてツール連携から始め、動くものはできたが評価の段階で「何を正解とするか」が決まらず要件定義に戻る流れです。連携できたツールの数が進捗に見えるため、任せる業務の判定が後回しになります。匿名の自社支援記録で、第三者未検証です。

開発用AIエージェントとは何ですか？

開発用AIエージェントとは、コードを書く、レビューする、テストを回すといった開発作業そのものを担うエージェントです。この記事で扱う「業務を任せるAIエージェント」とは目的が異なります。前者はエンジニアの手を増やす道具、後者は社内業務を目標として渡す相手で、どちらも仕組みは同じ推論と実行のループです。

AIエージェントは個人で開発できますか？

できます。LLM APIとフレームワーク1つ、ツール1〜3個の最小構成で、調べて答えるReAct型なら一本作れます。ログと監視は後回しでよく、評価データは自分で試した入力を溜めれば足ります。手順は親記事「AIエージェントの作り方」に沿えば、環境の準備から動作確認まで一人で進められます。

AIエージェントを開発している企業はどこですか？

2層に分かれます。言語モデルやエージェントの実行基盤をクラウドで提供する企業と、その基盤の上で業務に合わせてエージェントを構築する開発会社です。固有名は入れ替わるので挙げませんが、業務を任せたい側が探すのは後者です。選び方の観点は既存記事「AIエージェント比較」にまとめています。

AIエージェント開発の環境は何を用意すればよいですか？

LLM API、フレームワーク、ツール権限、評価データ、ログと監視の5項目です。個人で試す段階はLLM APIとツール権限があれば動き、フレームワークと評価データは後から足せます。チームで業務に載せる段階では評価データとログと監視が必須になります。対応モデルや機能は変わるため、2026年9月時点の公式資料で確認します。

今あるチャットボットはAIエージェントに置き換えるべきですか？

一問一答で足りているなら、置き換えは不要です。FAQ回答のように手順が固定の業務は、チャットボットのほうが安定します。置き換えを検討するのは、回答の前に検索や社内システムの参照が要る、複数の手順をまたぐといった要求が出てきたときです。その場合も、まず1業務だけをエージェントに切り出します。

明日やることは、自社の業務を棚卸しして、任せる業務を1つ選ぶことです。開発そのものより先に、この判定を済ませます。

結論の再掲

AIエージェント開発は、要件定義・設計・実装・評価・運用の5工程で回します。最初の一本はReAct型で、ツールを1〜3個に絞ります。任せる業務は、AIの弱点2分法で「待てば解決する側」の弱点だけを含む業務に切り分けます。

5工程は、要件定義で任せる業務を決め、設計でツールと権限を決め、実装でモデルとツールを繋ぎ、評価で任せられるか試し、運用でログを見て直す順です。評価は「動くか」ではなく「任せられるか」を確かめる工程だと押さえ直しておきます。

次の一手

次の一手は、自社の業務を棚卸しして、待てば解決する弱点だけを含む定型業務を1つ選ぶことです。棚卸しは、業務を書き出してAIに任せる候補を診断できるおきかえくんの無料診断からも始められます。

選んだ業務は、そのまま要件定義の最初の入力になります。作り方の手順は親記事「AIエージェントの作り方」に、任せる前の棚卸し5項目は「AI導入の進め方」にまとめてあるので、選んだあとはそちらに進んでください。