AI​エージェント開発と​は作り方・​向く業務・​依頼前の​注意点

AI​エージェント開発の​結論：​作る前に​「決まった手順で​足りるか」を​確かめる

AIエージェントの開発を考えるときは、いきなりエージェントを作ると決めず、決まった手順の自動化で足りないかを先に確かめるのが基本です。Anthropicの開発者向け解説「Building effective agents」は、まずできるかぎり単純な方法を探し、必要なときだけ複雑にするよう勧めています。エージェント型の仕組みは性能と引き換えに遅延と費用が増えやすく、誤りが積み重なる可能性もある、という説明です。

同じ解説は、AIを使った仕組みを2つに分けています。事前に決めた手順（コードの経路）に沿ってAIと道具を動かすものが「ワークフロー」、AI自身が手順と道具の使い方を状況に応じて決めるものが「エージェント」です。作る側の最初の判断は、この2つのどちらが業務に合うかです。

※ 出典：Anthropic「Building effective agents」（2026年11月5日確認）の整理を、当メディアが3段階の表にまとめました。「AIの単発の呼び出し」の行は当メディアが補った整理です。

この記事の結論を先にまとめます。

• エージェントは、手順を事前に決めきれない業務に向く。決められる業務はワークフローが向く（当メディアの見方）
• 作り方の要点は、AIの判断、使う道具、人の確認の3つを分けて設計すること
• 注意点は、誤りの積み重なりと費用、与える権限、外部から入る不正な指示、人の判断、提供元の仕様変更の5つ
• 依頼するときは、対象の業務、AIに任せる判断、触るデータ、やらせない操作の4点を先に決める

この記事は、AIエージェントの概念の解説ではなく、「作る・頼む」ための判断に絞っています。AI開発の種類は、AI開発とはの記事で整理しています。

AI​エージェントの​定義：​公的な資料と​公式ドキュメントで​確かめる

開発の話に入る前に、言葉の使われ方をそろえておきます。AIエージェントには統一された定義があるわけではなく、確認できた3つの資料でも言い回しが次のように異なります。

※ 出典は各資料（2026年11月5日確認）。表の右列は、当メディアが各原文を要約した表現です。

3つに共通するのは、決めた手順をなぞるのではなく、AIが状況を見て次の動きを選ぶ点です。AI事業者ガイドラインの脚注には、複数のエージェントが自律的に意思決定して動く、より広い概念として「エージェンティックAI」があるとも書かれています。発注の場面では、言葉の定義を争うより、AIにどこまで判断を任せ、どの操作まで許すのかを具体的に書くほうが、認識のずれを減らしやすくなります。

作り方の​骨格：​AI​の​判断・​道具・​人の​確認を​分けて設計する

AIエージェントの実装は、突き詰めると「AIが判断し、道具を呼び、結果を受けて次を判断する」往復の組み立てです。公式ドキュメントで確認できる範囲で、骨格を3つに分けて見ていきます。

クライアントツールで​は、​道具を​呼ぶのは​自社側の​プログラム

Anthropicの「Tool use」の解説によると、AIは、利用者の依頼と道具の説明文をもとに、道具を呼ぶかどうかを判断します。道具には2種類あります。利用者側のアプリケーションで動く「クライアントツール」と、Anthropicの基盤で動く「サーバーツール」です。クライアントツールの場合、AIは「この道具をこの引数で呼びたい」という構造化された呼び出しを返すだけで、実際の操作は自社側のプログラムが実行し、結果をAIに返します。

これは発注側にとって大事な点です。AIが社内のデータを書き換えたり、メールを送ったりするのは、AIそのものの力ではなく、開発側が用意した道具とその権限です。何を道具として渡すかが、そのままエージェントにできることの範囲になります。

ループに​は​止める条件と、​人が​確認する地点を​置く

Anthropicの解説は、エージェントが自分で進める仕組みでも、チェックポイントやつまずいた場面では人の確認を求めて一時停止できること、また最大の反復回数などの停止条件を入れるのが一般的だと説明しています。同じ解説は、自律型のエージェントは十分なテストをサンドボックス（本番から切り離した環境）で行い、適切なガードレール（逸脱を防ぐ制限）を置くよう勧めています。

OpenAIのエージェントの安全に関する解説も同じ方向です。このページはAgent Builder（2026年11月30日に提供終了予定、2026年11月5日時点の記載）向けの解説ですが、考え方は一般に当てはまります。MCP（外部のツールをつなぐ仕組み）を使う場合は、ツールの承認を常に有効にして、読み取りと書き込みを含むすべての操作を、利用者が確認・承認できるようにする、と書かれています。人の確認をどこに置くかは、後から足すより、設計の最初に決めておくほうが作り直しを避けられます。

実装の​入り口は​複数あり、​自社の​負担が​変わる

OpenAIのAgentsガイドは、エージェントを作る入り口として複数の選択肢を並べ、それぞれの「導入の手間」を3段階で示しています。

※ 出典：OpenAI「Agents」ガイド（2026年11月5日確認）。説明は当メディアの要約、「導入の手間」は原文の「integration effort」の表記です。同ガイドには、この3つのほかに、チャット画面を組み込む「ChatKit」も載っています。

手間が小さい入り口ほど、基盤側に任せる部分が増え、自社で制御できる範囲は狭くなる、というのが当メディアの表の読み方です。どれが適切かは、扱うデータの置き場所や、承認の仕組みを自社でどこまで握りたいかで変わります。開発会社に頼む場合は、どの入り口を使う想定か、その理由は何かを提案書で説明してもらうと、比較しやすくなります。

向く業務と​向かない業務：​手順を​決められるかで​分ける

AnthropicとOpenAIの資料を読むかぎり、「エージェントでなければできない業務」を一覧にした公式の分類は見当たりません。ただしAnthropicの解説は、付録で、カスタマーサポートとコーディングを、会話と行動の両方が要り、成功の基準が明確で、人の監督を入れられる有望な適用先として挙げています。判断の軸としては、ワークフローは明確な作業で予測しやすさと一貫性を出せ、エージェントは柔軟さとAI主導の判断が大規模に要るときに向く、という整理もあります。これらを業務に当てはめる見分け方を、次の表にまとめます。この表は、公式資料の軸をもとに当メディアが作った目安です。

※ 当メディアの整理による目安です。判断の軸は、Anthropic「Building effective agents」のワークフローは明確な作業の予測しやすさと一貫性に、エージェントは柔軟さとAI主導の判断が大規模に要る場面に向く、という説明に基づきます（2026年11月5日確認）。

見直しの手間が小さい業務から始めるのが現実的です。たとえば、社内の問い合わせへの下書き作成のように、最終確認を人が行う作業であれば、AIが誤っても影響は限られます。一方で、請求や契約の処理のように、誤りが取り返しにくい作業は、最初はワークフローにして、AIの判断を入れる箇所を絞るほうが安全です。

もうひとつの見分け方は、「やりたいことを、手順書に書けるか」です。手順書に書けるなら、ワークフローにできる可能性が高いです。書こうとして「場合による」が何度も出てくるなら、エージェントの検討対象です。ただし、その「場合による」の中身を人が判断できなければ、AIにも任せにくいため、先に判断基準を言葉にする作業が要ります。

開発前に​知って​おきたい：​5つの​注意点

誤りの​積み重なりと、​費用の​増え方

Anthropicの解説は、自律的に動くという性質は費用の増加と、誤りが積み重なる可能性を意味する、と書いています。1回ごとの判断が少しずれても、次の判断がそのずれを前提に進むため、手順が長くなるほど影響が広がります。人の確認と停止条件の置き方は、前の節で触れたとおりです。

費用の面では、手順が増え、やり取りが長くなるほど、AIを使う分の料金は増えやすくなります。Anthropicの「Tool use」の解説では、道具を使うリクエストの料金は、入力・出力のトークン数（AIが処理する文字量の単位）で決まり、道具の定義や呼び出し・結果のやり取りも追加のトークンとして数えられると書かれています。開発費とは別に、運用中に毎月発生するAIの利用料を見積もっておく必要があります。内訳の見方は、AI開発の費用の内訳の記事で整理しています。

与える権限は、​最小から​始める

エージェントがどこまで操作できるかは、渡す道具と権限で決まります。OpenAIの安全に関する解説は、緩和策を取っても、エージェントは間違えたり、だまされたりする可能性があるとして、エージェントに与えるアクセスの範囲に注意するよう書いています。

具体的には、最初は「読むだけ」の道具から始め、書き込みや送信は、人が承認してから実行する形にします。社内の台帳を読んで答える段階で動作を確かめてから、更新の権限を足す、という順番です。権限を足すたびに、誤ったときに何が起きるかを、先に書き出しておきます。

外部から​入る不正な指示（プロンプトインジェクション）

OpenAIの解説は、信頼できないテキストやデータがAIシステムに入り込むことを「プロンプトインジェクション」と呼び、攻撃者が機密データの引き出しや意図しない操作に使えるリスクとして説明しています。メールの本文、Webページ、取引先から届いたファイルなど、エージェントが読む外部のデータには、AIへの指示に見える文章が紛れ込む可能性があります。

同じ解説が挙げる対策は、信頼できない入力を、最も権限の高い指示の欄に入れないこと、エージェント間でやり取りする内容を、決まった形式（スキーマ）に絞ること、ガードレールで入力を事前に検査すること、人による承認を置くことです。Agent Builder のガードレール機能については、それだけでは万全ではないが、最初の防御として有効だとも書かれています。外部のデータを読ませる設計の場合は、これらの対策をどう入れるかを、開発会社に確認してください。

人の​判断を​残す設計に​する

総務省・経済産業省のAI事業者ガイドラインは、公平性の項目で、AIに単独で判断させるだけでなく、適切なタイミングで人の判断を介在させる利用を検討するよう求めています。その際、人の判断が自動化バイアス（機械の出力を過度に信頼してしまう傾向）に左右されないよう対策を講じるべきだとも書かれています。脚注では、人がAIの判断を承認するときは、承認する理由や根拠を自分で考えてから承認すべきだ、という提案が紹介されています。

承認の画面を用意するだけでは、形だけの承認になりかねません。承認する人が何を見て判断するのか（AIが参照した情報、実行しようとしている操作の内容）まで、画面に出す設計にしておくことが重要です。AI事業者ガイドラインは、提供後も、適切な目的で使われているかを定期的に検証するとしています。見直しの担当と頻度は、依頼の範囲に含めて決めておきます。

提供元の​仕様は​変わる

公式ドキュメントの内容は、確認した時点のものです。OpenAIの安全に関する解説のページには、Agent Builder（エージェントを画面上で組み立てる機能）を廃止する予定で、停止は2026年11月30日と書かれていました（2026年11月5日確認）。特定の提供元の機能に深く依存すると、こうした変更への対応が必要になります。保守を誰が担うのか、提供元の仕様変更があったときの対応を契約のどこで決めるのかは、依頼の段階で確認しておく項目です。

依頼する前に​整理する：​決めておくことと、​見積もりで​聞くこと

開発会社に相談する前に、自社で決めておくと、提案の精度が上がり、見積もりの比較もしやすくなります。依頼から実装費の確定までの流れはAIシステム開発の流れの記事にまとめているため、ここではエージェントに特有の項目に絞ります。

※ 当メディアの整理による目安です。各項目の背景は、本記事の前半で示した公式資料に基づきます。

見積もりを受け取ったら、金額より先に、次の点を確かめます。

• ワークフローとエージェントのどちらで作る想定か、その理由
• どの入り口（提供元のAPIや開発キット）を使う想定か
• AIが実行できる操作の一覧と、人の承認を入れる箇所
• 外部のデータを読ませる場合の、不正な指示への対策
• 運用中のAI利用料は、開発費に含まれるのか、別建てなのか、誰が提供元と契約するのか
• 試作の段階で何を確かめ、どうなれば本開発に進むのか

最初から全業務を対象にせず、1つの業務で小さく試すのが、Anthropicの「単純な方法から始める」という考え方にも沿います。試作で、AIの判断が自社の期待に届くかを確かめ、届かなければ、その業務はワークフローや人の作業のままにするという判断も、成果のうちです。

内製か外注か：​エージェントなら​ではの​分担の​論点

エージェント開発でも、内製か外注かの判断は、AI開発一般と大きくは変わりません。判断の基本はAI開発は内製か外注かの記事で整理しています。ここでは、エージェントならではの分担の論点を1つだけ挙げます。

それは、業務の判断基準を言葉にする役です。エージェントに何を任せ、何を人が決めるのかは、業務を知る社内の人しか決められません。開発会社に頼む場合でも、この部分は発注側の仕事として残ります。

自社だけで​進めるのが​難しいときは

エージェントにするか、通常のシステムやAIの機能で足りるかは、小さな試作で確かめるのが近道です。対象の業務や、AIに任せる範囲を社内で決めきれない段階では、作る前に、何をしたいかを整理するところから始めると進めやすくなります。

Zero-Oneでも、AIシステム開発のご相談を、30分の無料ヒアリングから受けています。簡易プロダクトと概算のお見積りまでは無料です。無料でお出しする簡易プロダクトは、ご要望の画面や動きを確かめていただくための試作で、お客様の実データや社内システムとの接続は含みません。要件定義の費用は、開発のお見積りに含めてお示しします。金額はすべて税別で、成果を保証するものではありません。サービスの内容は、AIシステム開発のページで確認できます。まずは無料相談から、自社の条件に合うかを確かめてみてください。お問い合わせフォームでは「AI導入」にチェックをお願いします。

エージェント開発​に関するよくある質問

ワークフローとエージェントは、どちらで作るべきですか？

手順を事前に書き出せる業務なら、ワークフローが向きます。Anthropicの解説は、まず単純な方法を探し、必要なときだけ複雑にするよう勧めています。書き出しきれない判断が続く業務は、エージェントの検討対象です。

AIエージェントの開発費は、どのくらいかかりますか？

公式資料や公的機関の資料に、開発費の相場は確認できませんでした。開発費は範囲によって変わり、運用中はAIの利用料（トークン数に応じた料金など）も別にかかります。見積もりでは、開発費と利用料を分けて確認してください。

社内のデータを読ませる場合、何に気をつければよいですか？

読ませる範囲と操作の権限を、必要最小限から始めます。OpenAIの解説は、エージェントが間違えたりだまされたりする可能性があるとして、与えるアクセスに注意するよう書いています。外部から届くデータの扱いは、開発会社に対策を確認してください。

人の承認は、どの操作に置けばよいですか？

OpenAIの解説は、MCP（外部のツールをつなぐ仕組み）を使う場合に、読み取りと書き込みを含む操作を、利用者が確認・承認できるようにするよう書いています。実際には、影響の小さい読み取りから始め、書き込みや送信など取り返しにくい操作に承認を挟む形が考えやすいです。

最初の試作では、何を確かめればよいですか？

1つの業務で、読むだけの権限から試し、AIの判断が自社の期待に届くかを確かめます。正解の例と許容できる誤りの範囲を先に決めておくと評価できます。届かない場合は、ワークフローや人の作業のままにする判断もあります。

まとめ：​まずワークフローで​足りるかを​確かめ、​権限は​小さく始める

AIエージェントの開発は、いきなりエージェントを作ると決めず、決まった手順のワークフローで足りないかを先に確かめるのが出発点です。エージェントは、AIが手順と道具の使い方を自分で選ぶ分、費用と誤りの積み重なりが増えやすく、与える権限や外部から入る不正な指示にも注意が要ります。

次の一歩として、対象の業務、AIに任せる判断、触るデータ、やらせない操作の4点を書き出し、読むだけの権限から小さく試す計画を立ててみてください。自社だけで進めるのが難しい場合は、Zero-Oneの無料ヒアリング（30分）もご利用ください。簡易プロダクトと概算のお見積りまでは無料です。