AIエージェントの作り方を徹底解説！業務の切り出しから実運用までの手順を紹介

AIエージェントは試作までは比較的進めやすい一方、本番運用に移す段階では「正しく動いているとどう判断するか」「どこまで操作を許可するか」「運用後に誰が改善し続けるか」を決める必要があります。本記事では、この3つをそれぞれ評価・権限・運用の問題として整理し、5工程に沿って作り方を解説します。

目次

• AIエージェントの作り方は5工程に分かれる
• 【手順】AIエージェントの作り方 5ステップ
• 実運用の成果と課題が分かる3事例
• 自社だけで進めると止まりやすい3か所
• 【対策】止まらずに実運用まで移行するための4つの打ち手
• AIエージェントの構築でお困りならスパイクスタジオへ

AIエージェントの作り方は5工程に分かれる

AIエージェントの構築は、大きく5つの工程に分けて考えると迷いません。業務を切り出し、単一のエージェントとして設計し、評価データを用意し、権限とガードレールを決め、本番環境で運用しながら監視する。この順序です。

このうち、最初の2つ（切り出しと設計）はほとんどの現場で進みます。試作であれば、数日で形になるケースもあります。止まるのは3つ目以降です。評価の基準がない、権限を誰が決めるか決まらない、動かしたあとに誰が直すか決まっていない。この3か所で試作が止まります。

ワークフローとAIエージェントは別のもの｜作らない判断も含めて考える

作り方の前に、そもそもAIエージェントを作るべきかを決める必要があります。Anthropic は公式の技術記事で、あらかじめ決めた経路をLLM（大規模言語モデル）が通る「ワークフロー」と、LLM自身が手順とツールの使い方を決める「エージェント」を明確に区別しています。そのうえで、次のように述べています。

When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all.（LLMでアプリケーションを作るときは、可能な限り単純な解決策を探し、必要な場合にのみ複雑さを増やすことを推奨します。これは、エージェント的なシステムをまったく作らないという判断も含みます）

出典Anthropic「Building Effective AI Agents」2024年12月19日

実務上の分かれ目は、手順が事前に書き表せるかどうかです。毎回同じ順序で処理が進むなら、複雑なAIエージェントを作り込む必要はないかもしれません。動きが読みやすいため、決まった順に呼び出すワークフローの構築だけで済むことが多くなるからです。

一方で、次に挙げた例のように、入力のばらつきが大きく、分岐を事前に列挙できない業務はエージェントの領域です。

• 問い合わせの内容によって、参照すべき資料と担当部署が変わる
• 相手の回答によって、次に聞くことが変わる（交渉・ヒアリング）
• 資料の形式が送り主ごとに違い、読み取り方を都度判断する必要がある

AIエージェントの導入状況｜4つの数字から見る現在地

着手前に、業界全体の現在地を数字で押さえておきます。こうすることで、導入後の成果分析にも使えますし、社内の期待値を調整するときにも使えます。

1つ目は「導入の実態はどうか」です。前述の矢野経済研究所の調査では、生成AIを活用している企業は43.4%に達した一方、AIエージェントを「利用中」と答えた企業は3.3%にとどまりました。「導入検討中」13.5%、「関心あり」49.3%を合わせると前向きな回答は6割を超えるため、関心と実装の間に大きな差があります。

2つ目は「業務への組み込みはどうか」です。BCG「AI at Work 2025」（11の国・地域、1万600人以上を対象）では、AIエージェントが業務フローに統合されていると回答した割合は世界平均13%に対し、日本は7%でした。同調査では、AIエージェントの仕組みを理解していると答えた人も、世界平均が全体の3分の1に対し日本は13%です。

3つ目は「導入すれば、そのまま定着するわけではない」という点です。Gartner は2025年6月25日、2027年末までにエージェント型AIプロジェクトの40%超が中止されると予測しました。理由として挙げられているのは、コストの急増、ビジネス価値の不明確さ、リスク統制の不足の3つです。Gartnerが挙げる「ビジネス価値の不明確さ」は③評価、「リスク統制の不足」は④権限、コスト増大への継続的な対応は⑤運用と重なります。同社の2025年1月のウェビナー参加者調査（3,412人）では、エージェント型AIに大規模な投資をしていると答えた組織は19%でした。同社は、エージェント機能を名乗る数千社のベンダーのうち、実体があるのは約130社程度と推計しています。

4つ目は、「使っている人の満足度」です。弊社が展示会「DXPO」の来場者に対して実施した自主調査（スパイクスタジオ調べ、DXPO 2026、n=312、会場でのアンケート方式）では、生成AIの導入率は87%、効率化を実感した人は91%に達した一方、満足度は30.5%にとどまりました。ツールは導入され、効率化も実感されている一方で、十分な満足には至っていません。AIエージェントそのものの利用実態を示す数字ではありませんが、こうしたギャップは、より業務に踏み込んだAI活用を検討する背景の一つと考えられます。

これらの数字だけで定着失敗の原因を一つに特定することはできません。ただし、Gartnerが指摘する価値・コスト・リスクの問題や、日本での業務フロー統合率の低さを見ると、単にエージェントを構築するだけでなく、評価・統制・運用まで含めて設計する必要性が高まっていることは読み取れます。それでは、次にAIエージェントの作り方、5工程を順に見ていきます。

【手順】AIエージェントの作り方 5ステップ

①業務を切り出す｜往復が多く、判断の基準を言葉にできる業務から

最初に決めるのは対象業務です。AIエージェントに向く業務には、次の3つの条件があります。

• 往復が多い｜1件を終えるまでに、確認や差し戻しが何度も発生している
• 途中の回答によって次の処理が変わる｜確認結果や相手の回答に応じて、次に行う確認や対応が分岐する
• 判断の基準を言葉にできる｜熟練者が「なぜそう決めたか」を説明できる

この3つが揃う業務から始めます。逆に、判断基準が誰も説明できない業務は先に業務手順の可視化と整理が必要です。基準が言葉になっていない業務をエージェント化すると、出力が正しいかどうかを誰も判定できず、結局「誰にも使われない」状態で止まってしまいます。

実践ポイント

• 候補業務を3つ挙げ、それぞれ「1件あたりの往復回数」と「月間の件数」を実測する
• 熟練者1人に、直近5件の判断理由を口頭で説明してもらう。説明できない箇所を記録するし、言語化する
• 最初の対象は、「月○件以上」など基準を設け、AIのアウトプットを人が確認できる工程に絞る

②設計する｜単一エージェントから始め、ツールを重複させない

設計で最も多い失敗は、最初から複数のエージェントに役割を分けてしまうことです。OpenAI は公式ガイド「A practical guide to building agents」で、次のように推奨しています。

Our general recommendation is to maximize a single agent's capabilities first... Some implementations successfully manage more than 15 well-defined, distinct tools while others struggle with fewer than 10 overlapping tools.（まず単一エージェントの能力を最大化することを推奨します。明確に定義され重複のないツールを15個以上うまく扱えている実装もある一方で、重複したツールが10個未満でも破綻している実装もあります）

出典OpenAI「A practical guide to building agents」2025年4月17日公開

問題はツールの個数ではなく、重複です。例えば「顧客情報を取得する」ツールが3つあり、記載内容がそれぞれ異なる場合、AIがどの情報を使うべきかが判断できない状態だと、エージェントは選択を誤る可能性があります。複数エージェントへの分割は、単一構成で扱いきれなくなってから検討する順序になります。

実践ポイント

• 実装前に、ツールの一覧表を作る（ツール名／何ができるか／入力／出力／呼んでよい条件）
• 説明文は業務の言葉で書く。「getCustomer」ではなく「契約中の顧客の契約内容を取得する」
• 似た機能が2つ以上あるなら、片方を消すか、呼び分けの条件を説明文に書き切る
• 人の承認を挟む箇所を、この段階で設計に含める（詳細は④）

③評価データを先に作る｜答えだけでなく手順を採点する

ここが最初の関門です。エージェントは同じ入力でも通る経路が変わるため、「今回はうまくいった」が再現するとは限りません。判定の基準を人の感覚に任せると、修正するたびに全体を確認できなくなります。

Google は Agent Development Kit（ADK）の標準機能として、最終応答の品質と、ツール呼び出しの手順（トラジェクトリ）の両方を、あらかじめ用意した正解データセット（Golden Dataset）と比較して評価する仕組みを提供しています。

Built-in Evaluation: Systematically assess agent performance by evaluating both the final response quality and the step-by-step execution trajectory against predefined test cases.（組み込みの評価機能: あらかじめ定義したテストケースに対し、最終応答の品質と段階ごとの実行経路の両方を評価して、エージェントの性能を体系的に測ります）

出典Google Developers Blog「Agent Development Kit: Easy to build multi-agent applications」

答えだけを見て採点すると、たまたま正解にたどり着いた経路まで「問題ない」と判断してしまう可能性があります。どのツールをどの順で呼んだかまで記録して比べることで、修正の影響が測れるようになります。

実践ポイント

• 過去の実データから、正解例と却下例をセットで集める（却下例のほうが後で効きます）
• 1件ごとに「期待する答え」と「通ってよい手順」を書く
• 評価データは業務担当が作る。開発側だけで作ると、業務の正解とズレます
• 修正を入れたら毎回同じデータで回帰テストを回し、点数の推移を残す

④権限とガードレールを決める｜「必要最小限の自律性」から始める

次の関門は権限です。エージェントは自分で判断してツールを呼ぶため、「できること」を絞らないと、想定していない操作まで到達します。

OWASP は2025年12月9日、100名を超える専門家・研究者・実務家の協力を得て「OWASP Top 10 for Agentic Applications 2026」を公表しました。エージェント特有のリスク（目的の乗っ取り、権限の濫用、ツールの誤用など）を10種に整理し、全体を貫く原則として「Least Agency（必要最小限の自律性しか与えない）」を示しています。

Microsoft も Azure AI Foundry Agent Service の公式ドキュメントで、行動の境界を明確に定義するよう求めています。

Particularly for critical or high-stakes tasks, consider incorporating mandatory human review and approval steps by the user... Clearly defining which actions are allowed (action boundaries), prohibited, or need explicit authorization may help your agentic system operate as expected.（特に重要度やリスクの高いタスクでは、ユーザーによる必須の人間レビューと承認のステップを組み込むことを検討してください。どの行動が許可され、禁止され、明示的な承認を必要とするのかを明確に定義することが、エージェントを想定通りに動かす助けになります）

出典Microsoft「Transparency Note for Foundry Agent Service」

制御をどこに置くかも設計対象です。AWS は2026年6月、Amazon Bedrock AgentCore のポリシー型ガードレールを一般提供として発表し、判定をエージェントのコードの外側で行う設計を明言しています。

Guardrail results are evaluated in policy at the AgentCore gateway perimeter, outside the agent's code, ensuring consistent enforcement regardless of agent autonomy.（ガードレールの判定は、エージェントのコードの外側にあるAgentCoreゲートウェイの境界でポリシーとして評価され、エージェントの自律性に関わらず一貫して適用されます）

出典AWS「Amazon Bedrock AgentCore policy guardrails generally available」2026年6月

統制の枠組みを社内文書に落とすときは、NIST「Generative AI Profile（NIST AI 600-1）」2024年7月が使えます。Govern・Map・Measure・Manage の4機能に沿って、生成AI特有のリスクへの対応と人の監督の組み込みを整理した文書です。エージェント特化の文書ではありませんが、社内規程の骨格として引用できます。

実践ポイント

• ツール一覧に「読み取り／書き込み／外部送信」の区分を追記する
• 書き込みと外部送信は、最初は人の承認を必須にする
• 判定はエージェントのプロンプトの中ではなく、外側の仕組みで持つ
• 誰の権限で動くのかを決める（担当者の権限か、専用アカウントの権限か）

⑤実運用へ移行する｜監視と見直しの条件まで決める

動いたら完成ではありません。実運用では、次の4つが継続的に発生します。

• 監視｜入力・呼び出したツール・出力を記録し、失敗した経路を後から追えるようにする
• コスト｜1件あたりの処理コストを測る。件数が増えると比例して増えます
• モデルとツールの更新｜前提にしていた機能が変わることがあります
• 直す人｜作った担当者が異動したあと、誰が評価データを更新するかを決めておく

3つ目については、実際に起きた例があります。OpenAI は2025年10月、ノーコードでエージェントを構築できる Agent Builder を発表しましたが、同じ公式ページには2026年6月3日付の追記があり、Agent Builder と Evals は2026年11月30日以降プラットフォーム上で提供終了になると明記されています（OpenAI「Introducing AgentKit」）。ツールに合わせて業務手順まで作り込むと、提供終了のたびに作り直しが発生します。

4つ目の「直す人」は、社内の体制の問題です。評価データを更新できる人がいなくなると、エージェントは動いたまま業務とズレていきます。

実運用の成果と課題が分かる3事例

ここからは、実際に実運用まで進んだ例と、進んだあとに方針を変えた例を見ます。業種別の事例をまとめて知りたい場合は、AIエージェント導入事例12選もあわせてご覧ください。

1. 日本電気株式会社｜調達交渉のAIエージェント、自動合意達成率95%・調整時間は約80秒

日本電気株式会社（NEC Corporation）は2024年11月、グループ会社で調達交渉のAIエージェントの実証を行いました。約1,300品目の部品調達を対象に、購買側の担当者が介在せずAIのみで合意が成立した割合（自動合意達成率）は95%でした。交渉開始から完了までの調整時間は、従来の数時間から数日に対し、約80秒に短縮されたと公表しています。

2025年12月からはサービス提供が始まりました。価格は年間3,600万円からで、今後5年間で100社への導入を目標としています。やり取りの回数が多く、判断基準（価格・納期・数量の条件等）を明確にできる業務ほど、AIエージェントによる効率化の効果が出やすいと考えられます。

出典NEC「調達交渉AIエージェントサービスを提供開始」2025年12月2日

2. 富士通株式会社｜サポートデスクで往復8回が1回に、月間問い合わせの約15%を目標

実運用まで移行した例の紹介です。富士通株式会社は、社内のSalesforceサポートデスクの対応にAIエージェントを採用しました。本番導入前のパイロット検証では、従来のEinstein Botで8回のやり取りが必要だった問い合わせが、Agentforce for Serviceでは1回で解決したことを確認しています。

この検証結果を受けて本番採用を決定し、コンタクトセンターの月間問い合わせ数の約15%をAIエージェントが対応できる体制の構築を目標に掲げています。全件ではなく比率で目標を置いている点が、運用設計として参考になります。

出典セールスフォース・ジャパン「富士通のSalesforceサポートデスク対応にAgentforceを採用」2025年1月20日

3. Klarna Group plc｜700人相当という発表のあと、人の採用に戻した

スウェーデンのKlarna Group plcは2024年2月、OpenAIと共同で、AIアシスタントが稼働1か月で230万件の会話を処理し、フルタイム従業員700人相当の仕事をしていると発表しました。解決までの時間も11分から2分未満に短縮したとしています。

2025年5月、同社CEOのセバスチャン・シェミアトコフスキ氏はBloombergに対し、コストを評価基準として重視し過ぎた結果として品質が下がったと述べ、人間のサポート担当者を再び雇用する方針に転換したことがFortuneで報じられました。これは、コストだけでなく、品質も含めて評価することの重要性を示す事例です。

出典Fortune「Klarna CEO says the company is hiring humans again」2025年5月9日

自社だけで進めると止まりやすい3か所

弊社がこれまで支援してきた現場では、試作後の課題が③評価、④権限、⑤運用体制に現れるケースがありました。ここでは、公式ガイドで求められている事項とも照らし合わせながら、特に事前に決めておきたい3点を整理します。

止まりやすい工程	何が起きるか	必要になるもの
③評価データを作る	「だいたい合っている」以上の判定ができず、実運用に出す決裁が下りない	業務担当が作った正解例と却下例。手順まで含めた採点
④権限を決める	書き込みや外部送信の可否を誰が決めるか決まらず、読み取り専用のまま停滞する	行動の境界の定義と、人の承認を挟む箇所の合意
⑤実運用に移行する	作った担当者の異動後に更新が止まり、業務とズレたまま放置される	評価データの更新担当と、見直し・停止の条件を先に決める

3か所とも、開発の腕前ではなく「業務側と何を決めたか」で結果が変わります。だからこそ、外部に頼む範囲を実装だけに絞ると、この3か所が残ったままになります。

【対策】止まらずに実運用まで移行するための4つの打ち手

止まる場所が分かっているなら、先に手を打てます。ここでの前提は「評価をいつ作るか」です。

1. 評価データを業務側と一緒に作る

評価データは開発側だけでは作れません。何を正解とするかは業務の知識だからです。着手時に業務担当を巻き込み、正解例と却下例を一緒に集めます。

実践ポイント｜過去の処理済み案件から、うまくいった例と差し戻された例を同じ件数ずつ集めます。差し戻された例には、なぜ却下なのかを一行で書き添えます。この一行が、そのまま評価の基準になります。

2. 権限は読み取りだけから始める

OWASP の「Least Agency」を素直に適用すると、最初の版は読み取り専用になります。読み取りだけで業務が回る範囲を確認したうえで、書き込みを1つずつ開けていきます。

実践ポイント｜ツール一覧に「読み取り／書き込み／外部送信」の区分を書き、書き込み以降には承認者の役職名を明記します。「誰が承認するか」が空欄のまま実運用に進めないようにします。

3. 使う側の理解を先に揃える

作る側の設計と同じくらい、使う側の理解が結果を左右します。前述のBCG調査では、AIエージェントの仕組みを理解していると答えた人は日本で13%でした。理解が不十分な状態では、適切な利用範囲や期待値を共有しにくくなるため、導入時には使う側への説明も必要です。

弊社が2024〜2026年に実施した生成AI研修（受講者のべ1万人、研修中に受講者が書いたプロンプトを講師が添削した記録より）で最も多かったつまずきは、指示の書き方ではなく前提情報の欠落でした。AIの性能ではなく、渡す情報の設計でつまずいていたということです。対話型生成AIのプロンプトとAIエージェントの設計は同じものではありません。ただし、「AIが判断するために必要な前提情報を明示する」という点は共通しています。エージェントの場合、その前提情報はユーザーの入力だけでなく、ツールの説明、参照できるデータ、権限の境界にも広がります。

実践ポイント｜試作ができた時点で、使う部署の3人に触ってもらい、想定と違う使い方を記録します。そのうえで、期待できることと苦手なことを1枚にまとめて配ります。

研修と実装を並行させた例として、三井住友DSアセットマネジメント株式会社様の生成AI研修とDX支援の記事もあります。使う側の抵抗感がどう変わったかを、担当者の言葉で載せています。業務の切り出しから相談したい場合は、AIエージェントにできる業務の切り出しから相談するページをご利用ください。導入前の不安や、どの業務から始めるべきかを整理する段階からご相談いただけます。

4. 撤退条件と再開条件を先に決める

Gartner が中止の理由に挙げたのは、コストの急増、価値の不明確さ、リスク統制の不足でした。3つとも、着手時に基準を決めておけば途中で判定できます。

実践ポイント｜「1件あたりのコストがいくらを超えたら止める」「評価の点数が何点を下回ったら人の対応に戻す」を着手時に文書化します。止める基準があると、担当者が独断で撤退を判断する必要がなくなります。

スパイクスタジオの支援事例

弊社は、株式会社NTT DXパートナー様の生成AIプラットフォーム「架空商品モール」の開発支援で、サービスのアイデアから企画検討の伴走を行い、システム要件まで落とし込む工程を担当しました（NTT DXパートナー様の事例）。何を作るかが固まっていない段階から入る形です。

また、Circloop様との協働では、生成AIを全面的に活用したシステム改修を実施し、開発業務の80%以上をAIが担う体制で、従来の約1.3倍のスピードで改修を完了しました（Circloop様の事例）。作る速さだけでなく、直し続けられる体制をどう作るかが論点になった案件です。

AIエージェントの構築でお困りならスパイクスタジオへ

AIエージェントの作り方は、大きく5工程に分けられます。特に難しいのは、評価・権限・運用体制の3つです。実装だけでなく、これらを業務側と一緒に設計することが、実際の業務で使い続けられるAIエージェントにつながります。

スパイクスタジオでは、次の形でご支援しています。

• Spike AI Agent Studio｜専任のFDE（現場に入り込む担当エンジニア）と開発を実行するAIがチームになり、月額定額でAIエージェントを作り続ける体制です
• ZUNO｜図面・設計・積算など、専門業務に特化したAIエージェントです。自社の設計ルールと判断履歴を学習させ、実務のOJTで育てながら使います
• BPRコンサルティング｜業務プロセスそのものをAI前提で組み替え、実装につながる設計図とロードマップを描きます
• AI人材育成｜使う側・作る側・基盤層の三層に分けて、教育・統制・データ整備をセットで設計します

「どの業務から切り出すべきか分からない」「PoCを終えたが、実運用に移行するか判断ができない」という段階でも構いません。AIエージェントの作り方と対象業務の切り出しについて相談するところから、現状の整理も含めてお手伝いします。