AIエージェント開発の進め方：ツール連携と人の承認ポイントの設計

AIエージェントの開発を成功させる鍵は、AIの賢さよりも、エージェントが使う「道具」と、人が介入する「関所」の設計にあります。具体的には、エージェントに業務システムのどの操作を道具として渡すのか、どの操作の前に人の承認を挟むのか、途中で失敗したときにどこからやり直すのか、の三点を最初に決めることです。この三点が曖昧なまま開発を始めると、試作では動いたのに本番の業務には載せられない、という結果になりやすくなります。

この記事は、社内業務や自社サービスにAIエージェントを組み込みたい事業責任者、プロダクト担当者、開発を外部に依頼しようとしている発注担当者に向けて書いています。業務の切り出しから、ツール連携の設計、承認ポイントの置き方、失敗時のやり直し、評価と試験運用までを、開発の順番に沿って説明します。

読み終えたときに、自社でエージェントを作るなら何を先に決め、どんな順番で進め、開発会社に何を伝えればよいかを判断できることを目指しています。

AIエージェント開発の全体像

AIエージェントは、大きく分けると次の四つの部品でできています。

• 指示：エージェントの役割、守るべきルール、判断の基準を書いたもの。システムプロンプトとして与えることが多い
• 言語モデル：指示と状況を読み取り、次に何をすべきかを考える頭脳の部分
• ツール：検索する、データを読む、登録する、送信するなど、エージェントが実際に行動するための道具
• 実行の仕組み：モデルの判断を受けてツールを動かし、結果をモデルに返し、承認待ちや失敗時の処理を管理する部分

開発というと言語モデルの選定や指示文の工夫に目が向きがちですが、業務で使えるかどうかを決めるのは、ツールと実行の仕組みの方です。ツールの設計が粗いとエージェントは余計な操作をしてしまいますし、実行の仕組みに承認や記録の機能がなければ、業務の責任者は安心して任せられません。

開発の進め方の流れ

全体の流れは次のとおりです。

1. 業務と目的を決める：エージェントに任せる業務の範囲と、何をもって成功とするかを決めます。
2. 手作業で業務を再現する：人がエージェントになったつもりで、どの情報を見てどの操作をするかを書き出します。
3. ツールを設計する：書き出した操作を、エージェントに渡すツールとして定義します。
4. 承認ポイントを決める：どの操作の前に人の確認を挟むかを決めます。
5. 失敗時の扱いを決める：エラーや判断の迷いが起きたときの止め方とやり直し方を決めます。
6. 試作して評価する：過去の実例を使って、エージェントの振る舞いを確認します。
7. 限定した範囲で試験運用する：担当者や対象を絞って実際の業務で使い、記録を取ります。
8. 改善しながら範囲を広げる：記録をもとに指示やツールを直し、任せる範囲を段階的に広げます。

以降の章で、特に重要な3〜7の部分を詳しく説明します。どの業務を任せるかの判断については、AIエージェントを業務に導入する：任せられる仕事と任せない仕事で詳しく扱っています。

手作業で業務を再現してから作る

開発に入る前に、エージェントがやる予定の仕事を人が手作業で一通りやってみることをおすすめします。そのとき、次の点を記録します。

• 最初に何の情報を受け取るか（メール、フォームの入力、チャットのメッセージなど）
• 判断のために、どのシステムのどの情報を見るか
• どの順番で、どんな操作をするか
• 迷ったのはどこで、何を根拠に決めたか
• 結果を誰に、どの形で伝えるか

この記録が、そのままツールの一覧と指示文の元になります。特に「迷ったところ」と「判断の根拠」は、エージェントに書く指示の中でもっとも重要な部分です。ここが書けない業務は、まだエージェントに任せる準備ができていないと考えた方がよいでしょう。

業務システムとのツール連携の設計

ツールは「業務の言葉」で小さく作る

エージェントに渡すツールは、業務で使う言葉の単位で、できるだけ小さく作ります。たとえば「データベースに任意の命令を実行する」という万能なツールを一つ渡すのではなく、「顧客番号から顧客情報を取得する」「注文の下書きを作成する」「注文の下書きを確定する」のように、目的ごとに分けたツールを用意します。

小さく分けるメリットは三つあります。エージェントが目的に合ったツールを選びやすくなること、ツールごとに権限や承認の要否を設定できること、そして操作の記録を後から読んだときに何をしたのかが一目で分かることです。

ツールの説明文と入出力を丁寧に書く

エージェントは、ツールの名前と説明文を読んで、どのツールをいつ使うかを判断します。説明文には、何をするツールか、どんなときに使うか、使ってはいけないのはどんなときかを書きます。入力の項目は型と形式（日付の書き方、番号の桁数など）をはっきり決め、出力も決まった形で返すようにします。出力の形を決めるには構造化出力（JSONモード）のような仕組みが役立ちます。

読み取りと書き込みを分ける

ツールは「読み取り」と「書き込み」に分けて考えます。読み取りは何度実行しても業務データが変わらないので、比較的安心して任せられます。書き込みはデータを変えるため、承認の対象にするか、少なくとも記録と取り消しの手段を用意します。

接続方式を選ぶ

業務システムとのつなぎ方には、いくつかの選択肢があります。

業務システムに直接つなぐより、エージェント専用の中継APIを一枚挟む形にしておくと、エージェントができる操作を業務の単位で絞り込め、記録や権限の管理も一か所にまとめられます。標準的な接続方式についてはMCPで社内システムとAIをつなぐで詳しく解説しています。

人の承認ポイントの設計

どこに承認を置くか

承認を置く場所は、ツール単位で決めるのが分かりやすい方法です。読み取りのツールは承認なし、社内の下書きを作るツールは承認なし、確定・送信・削除のツールは承認あり、というように一覧表で決めておきます。

承認を置く基準は、取り消せるかどうか、影響が社外や他部署に及ぶかどうか、金額や件数が大きいかどうかです。同じツールでも、金額が一定以下なら承認なし、それを超えると承認ありのように、条件で分けることもできます。

承認する人が判断しやすい画面を作る

承認の仕組みでよくある失敗は、承認する人に十分な情報が示されず、結局は中身を見ずに承認ボタンを押すようになってしまうことです。承認画面には、次の情報を表示します。

• エージェントが何をしようとしているか（操作の内容）
• なぜその操作をしようとしているか（根拠となった情報や判断の理由）
• 操作した結果、何が変わるか（変更前と変更後）
• 承認・修正して承認・却下の選択肢

修正して承認できるようにしておくと、エージェントの下書きが惜しいときに一から作り直す手間がなくなります。また、修正内容は改善の材料として記録しておきます。

承認待ちで業務を止めない工夫

承認が必要な操作が溜まると、業務が止まってしまいます。承認の依頼は、担当者が普段使っているチャットツールや業務画面に通知し、一定時間たっても承認されない場合の扱い（別の担当者へ回す、保留にする）も決めておきます。

失敗時のやり直しの設計

エージェントは、ツールの呼び出しに失敗したり、判断に迷ったり、想定外の情報に出会ったりします。こうした場面での振る舞いを決めておかないと、同じ操作を何度も繰り返す、途中まで処理したまま止まる、といった問題が起きます。

失敗の種類ごとに扱いを決める

• 一時的なエラー（通信の失敗など）：回数と間隔を決めて自動で再試行し、それでも失敗したら人に知らせる
• 入力の誤り（形式が違う、必要な情報がない）：エージェントに誤りの内容を返して修正させ、決めた回数で直らなければ人に引き継ぐ
• 判断の迷い（基準に当てはまらないケース）：無理に判断させず、人に引き継ぐ
• 権限外の操作：実行せずに記録し、管理者に知らせる

途中から再開できるようにする

複数の手順を順番にこなす業務では、どこまで処理が進んだかを記録しておき、失敗した手順から再開できるようにします。最初からやり直す設計にすると、すでに実行した登録や送信が二重に行われるおそれがあります。同じ操作を二回実行しても結果が変わらないように作る工夫も有効です。この考え方はAPI連携の障害対策とも共通しています。

エージェントへの指示の書き方

ツールと承認の設計が固まったら、エージェントへの指示を書きます。指示は長ければよいわけではなく、業務の担当者が新人に引き継ぐときに渡すメモのように、必要なことが整理されて書かれている状態を目指します。

指示に含める内容は、おおむね次のとおりです。

• 役割：誰の代わりに、何のために働くのか
• ゴール：どの状態になったら仕事が終わったとみなすか
• 使ってよいツールと順番の目安：通常はどのツールから使い始めるか
• 判断の基準：手作業の再現で記録した「迷ったところ」と「決めた根拠」
• してはいけないこと：推測で情報を埋めない、承認なしに確定しない、など
• 人に引き継ぐ条件：どんな状況なら作業を止めて人に知らせるか

指示を書くときに避けたいのは、一つの指示にすべての業務を詰め込むことです。受付、確認、登録のように役割が大きく異なる場合は、それぞれ別のエージェントとして分けた方が、指示が短く明確になり、どこで間違えたのかも追いやすくなります。複数のエージェントを組み合わせる構成はマルチエージェントと呼ばれますが、最初から複雑な構成にする必要はありません。一つのエージェントで始め、役割が膨らんできた段階で分けることを検討します。

また、指示は一度書いたら終わりではありません。試験運用で人が修正した内容を見て、判断の基準を足したり、言い回しを直したりしていきます。指示を変えたときは、変更の日付と理由を残し、評価用の事例で前後の結果を比べてから本番に反映します。

開発体制と発注側の役割

エージェント開発では、開発者だけでなく、業務を知っている人が継続的に関わることが欠かせません。開発会社に依頼する場合でも、発注側には次の役割を担う人が必要です。

特に業務の担当者の関与は、評価用の事例に正解をつける作業や、試験運用中の修正の記録で大きな役割を果たします。この時間を確保できないと、エージェントの品質を判断する材料がそろわず、開発が進んでも本番に載せる判断ができません。プロジェクトを始める前に、担当者が週にどれくらいの時間を割けるかを確認しておきます。

評価と試験運用

過去の実例で評価する

試作ができたら、過去の実際の業務データを使って評価します。普段どおりのケースだけでなく、例外的なケース、情報が足りないケース、紛らわしいケースも含めて、数十件程度の評価用の事例を用意します。これを評価データセットとして残しておくと、指示やモデルを変えたときに同じ事例で比べられます。

評価では、最終的な結果が正しいかだけでなく、途中でどのツールをどの順番で呼んだか、不要な操作をしていないか、人に引き継ぐべき場面で引き継いだかも確認します。

試験運用のチェックリスト

• 対象の担当者・業務・期間が決まっている
• すべての書き込み操作に承認が入っている状態から始めている
• 操作の記録と、承認時の修正内容が保存されている
• 担当者がエージェントを止める方法を知っている
• 週に一度、記録を見て指示やツールを見直す場がある
• 試験運用を終える条件と、本運用に移る条件が決まっている

よくある失敗とその避け方

万能なツールを一つだけ渡す

データベースへの任意の操作や、あらゆる画面の操作をまとめて一つのツールにすると、エージェントは意図しない操作もできてしまいます。ツールは業務の単位で小さく分け、必要なものだけを渡します。

承認が形だけになる

承認画面に十分な情報がなく、件数も多すぎると、担当者は中身を見ずに承認するようになります。承認の対象を本当に必要な操作に絞り、判断に必要な情報を画面にまとめることで避けられます。

試作の成功で本番に進んでしまう

用意した数件の例でうまく動いても、本番では想定外の入力が必ず来ます。例外的なケースを含む評価用の事例で確認し、限定した範囲の試験運用を経てから広げます。

失敗時の扱いを後回しにする

正常に動くケースだけを作り込み、エラー時の振る舞いを後回しにすると、本番で処理が途中で止まったり二重に実行されたりします。失敗の種類ごとの扱いは、ツールの設計と同時に決めます。

具体的な場面で考える：経費精算の確認業務

架空の一般例として、経費精算の申請内容を確認する業務を考えます。担当者は申請と領収書の画像を見比べ、金額や日付が合っているか、社内規程に沿っているかを確認し、問題があれば申請者に差し戻しています。

この業務をエージェント化する場合、ツールは「申請内容を取得する」「領収書の画像を読み取る」「社内規程を検索する」「確認結果のメモを保存する」「差し戻しの下書きを作る」「差し戻しを送信する」に分けます。前の四つは読み取りと社内の記録なので承認なし、差し戻しの送信は申請者に届くので担当者の承認ありとします。

規程に明記されていない費目や、金額が一定額を超える申請は、エージェントが判断せずに担当者へ回す条件にします。担当者は、エージェントが付けた確認メモと差し戻し案を見て、承認するか修正するかを決めます。修正の内容は記録され、週ごとに見直して規程の参照方法や指示文を改善します。

試験運用を続けるうちに、交通費のように金額が小さく規程も明確な費目では、差し戻し案の修正がほとんど出なくなってきます。そうなった段階で、その費目に限って「問題なしと判断した申請は承認待ちに回さず、確認済みとして経理担当に送る」という形に変えることを検討します。一方、接待費のように判断の幅が大きい費目は、引き続き担当者の確認を残します。このように、費目や金額といった条件ごとに任せる度合いを変えていくのが、エージェントを業務に定着させる現実的な進め方です。

よくある質問

Q. AIエージェントの開発にはどれくらいの期間がかかりますか？

対象業務の範囲、つなぐシステムの数、承認や記録の仕組みをどこまで作るかで大きく変わります。一つの業務に絞り、既存のAPIが使える場合は、試作と評価までを短期間で進められることもあります。最初から複数業務をまとめて作るより、一つの業務で試験運用まで進めてから広げる方が、結果として早く本番に載せられます。

Q. 開発会社に依頼するとき、何を準備すればよいですか？

任せたい業務の手順を書き出したもの、つなぎたいシステムの一覧とAPIの有無、承認が必要だと考えている操作、過去の業務データの例（個人情報などは配慮したうえで）があると、見積もりと設計が具体的になります。特に「迷ったときの判断基準」を言葉にしておくと、開発の手戻りが減ります。

Q. 言語モデルはどれを選べばよいですか？

ツールを正しく選んで呼び出せるか、指示を守れるか、応答速度と費用が業務に合うか、データの取り扱いが自社の方針に合うかで比べます。評価用の事例で複数のモデルを試して比べるのが確実です。選び方の観点は業務に使うLLMの選び方も参考にしてください。

Q. 承認をすべて外して完全に自動化できますか？

業務によっては可能ですが、最初から承認なしで始めるのはおすすめしません。承認ありで試験運用し、修正がほとんど必要なくなった操作から、条件付きで承認を外していくのが安全な進め方です。取り消せない操作や社外に届く操作は、承認を残しておく判断も十分に合理的です。

Otsumuに相談できること

任せたい業務が一つに絞れていて、使っている業務ツールに組み込まれたエージェント機能や、ノーコードの自動化ツールで必要な操作がまかなえるのであれば、この記事の手順で手作業の再現、承認ポイントの整理、試験運用までを社内で進めることは十分可能です。まずは承認ありの形で小さく試し、記録を取るところから始めてみてください。

一方で、複数の業務システムをまたいでツールを作る必要がある、承認画面や操作の記録を業務フローに組み込みたい、失敗時のやり直しを含めて本番運用に耐える仕組みにしたい、といった場合は、設計と開発の経験が成果を左右します。社内に開発の体制がない場合や、試作から本番への移行で止まっている場合も、外部の力を借りた方が早く進むことがあります。

Otsumuでは、業務の書き出しとツール設計から、承認・記録・停止の仕組みを含むエージェントの開発、試験運用と改善までを一気通貫で支援しています。目的から逆算して必要なツールに絞り、AIを活用した少人数の開発で短期間に形にする進め方を取ります。詳しくはAIエージェント開発のページをご覧ください。新しいサービスとしてエージェントを検証したい場合は、新規事業の爆速MVPシステム開発もあわせてご覧ください。

構想の段階でも、どこから作り始めるべきかを一緒に整理できます。30分の無料相談からお気軽にご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01