AIエージェントの始め方と活用例：個々の作業からチームの業務へ

AIエージェントは、目標に応じて必要な手順やツールを選びながら作業を進め、確認できる成果物まで仕上げます。AI事業者ガイドライン（第1.2版）は、AIエージェントを、特定の目標を達成するために環境を感知し、自律的に行動するAIシステムとしています。

この区別は使い方による目安で、製品やモードによって使える機能は異なります。資料の読み取りや返信の文面づくりは通常のチャットでもできる場合があり、それで足りる仕事にエージェント機能は必要ありません。エージェント機能が役立つのは、必要な手順やツールを選び、作業を進め、確認できる成果物に仕上げるまでの過程を任せたい場合です。OpenAIも、答えや短い下書きには通常のチャットを、成果物まで仕上げる作業にはChatGPT Workを使うよう案内しています。

依頼するときは、完成させたい成果物、使ってよい資料とツール、守ってほしい条件、確認や承認のために止まる場面の4点を伝えます。手順を選ぶのはAIでも、確認や承認をどこに置くかは人が決めます。決まった順番の転記や通知なら、ノーコードツールとAIの連携で足りることもあります。業務導入の全体像は生成AIを業務へ組み込む方法で扱っています。

この記事では、代表的な2つの使い方を取り上げます。違いは企業で使うかどうかではなく、任せる範囲、関わる担当者、情報やシステムの連携、案件の状態や確認待ちを継続して管理するかどうかです。

• 作業単位の活用

  担当者が資料を渡し、返信案などの成果物を仕上げさせる。依頼例へ進む

• チームでの活用

  受付から確認、承認、記録までの流れに組み込み、確認待ちや期限を追う。チームでの活用例へ進む

この2つは、厳密な分類や、全員が順に進む段階ではありません。担当者1人でも確認待ちを継続して管理できますし、チームでも1つの作業だけを任せることがあります。作業単位の活用は、製品に用意された機能から始められます。チームの業務に組み込む場合も既存機能を活用できますが、連携先によっては追加の設定や開発が必要です。アカウントを用意しただけでは、業務での使い方は決まりません。

任せたい仕事で選びます。3つの製品をすべてそろえる必要はなく、会社が利用を認めている製品から始めます。

製品を選んだら、作業単位の活用例の依頼文で始められます。dotsが自分のアカウントに表示されない場合も、利用できるChatGPT Workなどで1回分の仕事は進められますが、dotsと同じように継続して追う機能があるとは限りません。記載は各社の公式ドキュメントによります（確認日：2026年10月10日。画面の名称は英語版の表記）。

ChatGPTの中で、成果物まで仕上げる作業を任せる使い方です。

判断が必要な場面で利用者に確認を求めながら、仕事を続けるOpenAIのエージェントです。クラウドで完結する作業は、利用者のPCが停止していても続けられます。接続したPCのファイルやアプリを使う工程では、そのPCがオンラインで、ChatGPTアプリが開いている必要があります。

Anthropicが提供する開発向けのツールで、ターミナル、デスクトップアプリ、Web、VS Codeなどから使えます。

届いた問い合わせとサービス資料を照合し、返信案と、担当者が確認する事項をまとめる使い方です。ここでは問い合わせ3件を例にします。始める前に、会社が利用を認めた製品とアカウントであることと、資料を渡してよいことを確かめ、成果物を確認する人を決めておきます。

1. 資料を準備する：問い合わせはテキスト、サービス説明資料はPDFなどで用意する
2. 製品に資料を渡す：選んだ製品にファイルを添付する
3. 依頼文を送る：下の依頼文の例を使う
4. 成果物と根拠を確認する：根拠の参照先と、資料の記載が合っているかを見る
5. 修正を依頼する：対象と直し方を具体的に伝える（例：「問い合わせ2の不足情報に、ルーターの型番を加えてください」）

問い合わせは、メールやフォームの本文をコピーしたもので構いません。個人情報や社外に出せない情報は、会社のルールに合わせて削除するか伏せ字にします。サービス説明資料は料金や対応範囲を含めてそのまま渡し、記載のない事項は「未確定」として扱わせます。

以下の入力・依頼文・出力形式・返信案の例は記事用に作成したもので、実在のサービスの内容や、製品で実行した結果ではありません。

入力例の3件は、資料だけで回答できるもの、情報が足りないもの、人の判断が必要なもの、に分かれます。

受け取った成果物では、根拠の参照先が資料の記載と合っているか、資料にない料金や条件が「未確定」として残っているか、例外として対応するかなど人が判断する点をAIが決めていないかを確認します。最初は返信案までを任せ、人が確認してから送信します。依頼文の「送信しない」は指示で、製品の設定による制限とは別のため、送信できるサービスは接続しません（任せる範囲と権限の決め方）。

同じ問い合わせ対応を、チームの業務の流れに組み込んで続ける場合の構成例です。特定の製品の設定だけで一式がそろうという意味ではなく、顧客情報の参照、担当者への連絡、承認、状態の管理をどこまで任せられるかは、選ぶ製品、接続の設定、権限によって変わります。連携先によっては追加の設定や開発が必要です。

案件の状態は、未対応・社内確認待ち・承認待ち・顧客返信待ち・対応完了などで管理し、確認や承認に応じて更新します。確認や承認が要らない案件はその状態を経ず、差し戻しがあれば前の状態に戻るため、一方向に進むとは限りません。

1. 受付：届いた問い合わせの要望と期限を整理し、案件として記録する（未対応）
2. 情報収集：利用権限のある顧客情報、対応履歴、サービス資料から必要な情報を探し、回答できる点・不足情報・人の判断が必要な点に分ける
3. 担当者確認（必要な場合）：営業・技術・契約の担当者へ確認事項を渡す（社内確認待ち）。料金の例外や契約条件は、ここで人が決める
4. 返信案：担当者の回答と資料から、返信案と承認が必要な事項をまとめる
5. 必要な承認（必要な場合）：承認者が、内容と外部へ送ってよいかを判断する（承認待ち）。差し戻しなら前の工程に戻る
6. 実行：必要な承認の結果、または事前に定めた実行条件にもとづき、許可された権限の範囲で返信の送信などを進める。顧客の返事を待つ場合は顧客返信待ちにする
7. 記録・追跡：対応記録を残し、確認待ちや期限が近い案件を知らせる。完了の条件を満たすまで、その時点の状態のまま追う

承認が要らない案件も、無条件に実行してよいわけではなく、事前に許可した条件と権限の範囲で実行します。また、返信を送ったことと案件の完了は別で、顧客の了承を得た、依頼された作業が終わった、など、どの条件で対応完了とするかを業務ごとに決めます。順番が決まった転記や通知は固定のワークフローで処理でき、問い合わせの内容によって参照する情報や確認先が変わる部分で、エージェントが手順を選ぶ意味が出ます。

2つの例の違いは、AIの数や自動化の割合ではなく、任せる範囲、関わる担当者、参照する情報と連携、継続して管理する対象の広さです。

単発の資料整理や返信案の作成で目的を満たせるなら、紹介した製品で十分です。一方で、複数の工程や担当者にまたがる仕事をまとめて扱いたい、成果物と確認・承認の履歴を案件ごとに管理したい、人が判断する場面を業務の流れに組み込みたい、といった課題がある場合は、AIを業務プロセスに組み込む前提の仕組みも選択肢になります。Malakeが提供する企業向けAIエージェントのAIAG（AI業務Orchestrator）も、着手前に工程・担当・成果物・人が判断する場面を計画として示し、外部への保存・送信・予定登録には計画と承認の条件を適用し、成果物と承認の記録をひとつの案件に残す設計です。

最初は、成果物と確認者がはっきりしていて、誤りがあっても外部に出る前に止められる業務から始めます。金額・契約・人事評価などの最終判断や、取り消せない操作は最初の対象に向きません。作業は、取り消せるか、社外に出るか、金額・契約・評価に関わるか、の3点で分けます。

依頼文で「送信しないでください」と指示することと、製品の設定で送信できないようにすることは別です。指示はAIが従おうとする内容で、誤りや、資料に紛れ込んだ別の指示の影響を受ける可能性が残るため、権限そのものを絞ります。

• 送信できるサービスを最初は接続しない：接続するときは、求められる権限を確認してから許可します。問い合わせの整理と返信案なら、閲覧と下書きの作成で足ります。
• 操作の前に確認を求める設定を使う：dotsでは、顧客へのメッセージ送信などに「Ask before taking action」を設定できます。このルールはdotが従おうとする指示で、アプリでの操作はプラグインの権限で別に管理されます。Claude Codeでは、planモードや、ほとんどの操作の前に確認するManualモードを使います。

OWASPも、AIエージェントに過剰な機能や権限を与えるリスクを挙げ、権限を必要な範囲に絞ることと、影響の大きい操作の前に人の承認を求めることを対策にしています。入力してよい情報の区分は企業のAI利用ルールブックで、チャット上で承認を受け取る仕組みは申請・承認をSlack / Teamsにつなぐ設計で扱っています。

日々の業務で使い続ける場合や、既存の業務を少しずつ改善する場合は、成果物を確認しながら使い方を見直していけば足ります。部署への展開やシステム連携に向けて、品質・費用・権限・運用負荷を確かめる必要がある場合は、対象を絞ったPoC（小さく試し、業務で使えるか確かめる検証）を検討します。正式なPoCを行うかどうかにかかわらず、成果物の確認と、必要な社内の手続きは省きません。

確かめる項目と続けるかどうかの基準は先に決め、項目は使い続けるときの評価と見直しと同じものを使えます。試す間は返信を下書きにとどめると、誤った返信が取引先に送られるリスクを抑えられますが、入力した情報の扱いや、接続したサービス上での誤操作のリスクまでなくなるわけではありません。OpenAIは段階的に進めることを、Anthropicは隔離した環境での十分な試行を勧めています。評価指標と運用体制の考え方は生成AIを業務へ組み込む方法で扱っています。

チームの業務に組み込んで運用する場合は、次の点を決め、対象の業務と利用者を絞って始めます。

• 利用者と対象業務：誰が、どの業務で、どの製品を使うか（業務責任者）
• 接続と権限：接続するサービスとAIに渡す権限。使わない権限は渡さない（情報システム担当）
• 承認と実行条件：承認を挟む操作と承認者、承認なしで実行してよい条件（業務責任者、承認者）
• 記録：残す記録（成果物、根拠、外部への操作）と、確認する人・頻度
• 停止と誤りへの対応：止め方と止める人、誤った操作の後の連絡と修正

止め方は製品ごとに確認します。たとえばdotsでは、dotの一時停止、委任した作業の停止、定期実行の解除がそれぞれ別の操作で、どの場合も、すでに完了した操作は取り消されません。送信や削除のように取り消せない操作は、止める手順だけでは防げないため、承認や実行条件の対象に含めます。

使い続けるか、範囲を広げるかは、同じ種類・難易度の業務を、今の手順と比べて判断します。時間は、AIが処理している時間と、人が確認・修正する時間を分けて記録します。

• 正確さ：根拠が資料と合っているか、未確定の事項を推測で埋めていないか
• 担当者の作業時間：確認と修正を含めた時間
• 利用費用：完成した案件1件当たりの使用量や料金
• 人への判断の戻し方：戻す必要がなかった場面、戻すべきだった場面
• 未対応と期限超過：未対応のまま残った件数、期限を過ぎた件数
• 再回答と差し戻し：起きた件数と理由

使い始める段階でよく挙がる疑問をまとめます。