AIエージェント導入の進め方｜開発・構築の手順と、本番で止まらない条件

AIエージェントを業務に入れると決めたあと、最初に迷うのは、どのツールを使うかではない。どの業務を、どこまで任せるかだ。私の見方では、ここを決めないまま開発・構築に入ると、動くものはできても本番で使われない。

米Gartnerは2025年6月、2027年末までにエージェント型AIのプロジェクトの40%以上が中止されると予測した。理由はコストの高騰、ビジネス価値の不明確さ、不十分なリスクコントロールだ。3つの理由は、どれも技術の問題というより、作る前の決め方の問題だと私は考えている。

以下、AIエージェントが何をするシステムかを短く確かめたうえで、最初の業務の選び方、導入の6つの段階、開発・構築の3つの方法、本番で止まらない条件、公開された事例の読み方、導入支援を頼むときの確認点を順に書く。権限と承認の設計はAIエージェントのセキュリティに、監査ログに残すものはAIエージェントのガバナンスに分けてある。

AIエージェントは何をするシステムか

総務省と経済産業省の「AI事業者ガイドライン」第1.2版（2026年3月31日）は、AIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」と定義している。

もう少し作る側に寄せた線引きもある。Anthropicは2024年12月の解説「Building effective agents」で、あらかじめ書いたコードの道筋に沿ってLLMとツールを動かすものをワークフロー、LLMが自分で手順とツールの使い方を決めるものをエージェントと呼び分けた。そのうえで、できるだけ単純な方法を探し、必要なときだけ複雑にすることを勧めている。OpenAIが2025年に公開した手引き「A practical guide to building agents」も、LLMを組み込んでいても処理の流れをLLMに任せていない単純なチャットボットや1回きりの応答は、エージェントではないとしている。

3つを並べると、次のように分けられる。表は私の整理だ。

私の見方では、導入を決める前に「これはワークフローで足りないか」を一度問うのがよい。手順が毎回同じなら、ワークフローの方が速く、安く、結果も読みやすい。Anthropicも、エージェントは自律的に動くぶん費用が高くなり、誤りが積み重なるおそれがあると書いている。

最初の業務の選び方

OpenAIの手引きは、エージェントを優先して検討すべき仕事として、次の3つを挙げている。

1. 判断や例外が多い仕事。例は、顧客対応での返金の承認
2. ルールが増えすぎて、保守しにくくなった仕事。例は、取引先のセキュリティ審査
3. 文書や会話など、決まった形のないデータを読む仕事。例は、住宅保険の請求の処理

あわせて手引きは、この条件にはっきり当てはまらないなら、決まった手順で動く普通の仕組みで足りるかもしれないとしている。

これは「エージェントが活きる業務」の条件で、「最初に入れる業務」の条件としてはまだ足りない。私は、候補の業務を次の5つの問いで比べることを勧めている。

5つ目を軽く見ないほうがよい。導入前の数字がなければ、導入後に良くなったと言えない。後で取り上げるマルサンアイの発表は、1件あたりの平均時間を導入前と導入後で示している。比べられるのは、導入前の数字があるからだ。

AIエージェント導入の6つの段階

業務が決まったら、次の6つの段階で進める。段階を飛ばさないこと、とくに2と3を開発の前に終えることが、本番で止まらないための近道だと私は考えている。期間は業務とデータの状態で大きく変わるため、ここでは目安の日数を書かない。

評価の問題集の作り方はLLMの評価（Eval）の作り方に書いた。試作のまま止まっているものを本番に進める判断はAIのPoC止まりを抜け出すにまとめてある。

任せる範囲は3段で考える

2つ目の段階で決める範囲は、次の3段で考えると決めやすい。表は私の整理だ。

OpenAIの手引きは、人に引き継ぐきっかけとして、失敗や再試行が決めた上限を超えたときと、取り消せない操作や影響の大きい操作の2つを挙げ、例として注文の取り消し、高額の返金、支払いを示している。また、最初から完全に自律したエージェントを作るより、段階的に進めた方がうまくいくとも書いている。私の見方では、最初は下書きか承認付きの実行から始め、問題集と運用の結果を見て1段ずつ上げるのがよい。

AIエージェントの開発・構築は3つの方法から選ぶ

作り方は大きく3つに分かれる。どれが上というより、仕事がどこで完結するかと、つなぐシステムの数で選ぶ。表は私の整理で、製品名は例として挙げた。

Microsoftの文書は、Copilot Studioを、AIで動くエージェントとワークフローを作って管理するローコードのツールと説明している。Claude Agent SDKは、Claude Codeを動かしているのと同じツールとエージェントの仕組みを、PythonとTypeScriptから使えるようにしたものだ。OpenAI Agents SDKは、エージェント、別のエージェントへの引き継ぎ、入力と出力を確かめるガードレールという少ない部品で組み立てる。

どの方法でも、最初は1つのエージェントに必要なツールを足していく形で始める。OpenAIの手引きは、まず1つのエージェントの力を引き出し切ることを勧め、複数のエージェントに分けるのは、複雑な指示に従えない、ツールを選び間違え続けるといった問題が出てからでよいとしている。

社内のシステムとつなぐ部分では、MCP（Model Context Protocol）を使う選択肢もある。Claude Agent SDKの文書も、外部のツールやデータにつなぐ手段としてMCPを挙げている。仕組みはMCPとはに、費用の見積もり方はAI開発の費用の内訳に書いた。

本番で止まらない5つの条件

試作で動いたエージェントが本番に入れない、入っても止まる。そうならないための条件を5つにまとめた。表は私の整理で、根拠にした指針や手引きを右の列に書いた。

私の見方では、5つ目がいちばん見落とされやすい。エージェントは1つの依頼の中でモデルとツールを繰り返し呼ぶため、チャットで1回答えるより費用がかさむ。上限を決めておけば、処理が止まらなくなったときも、被害を月の予算の中に収められる。

権限と承認の詳しい設計はAIエージェントのセキュリティに、記録に残す項目と見る人の分担はAIエージェントのガバナンスに書いた。

公開されたAIエージェントの導入事例から読み取れること

企業が公式に発表した導入事例を2つ見る。どちらも、発表資料に書かれた範囲だけを記す。「任せた範囲」の列は、上の3段に当てはめた私の分類だ。

マルサンアイは、オプティスの基盤「OPTIS One」を使ってAIエージェントを構築し、ツールの導入に先立って業務プロセスそのものを見直したと発表している。ファーストアカウンティングの発表では、AIが自律的にログインから申請内容の確認、承認、差し戻しの判断までを行い、検証では領収書の必須項目の確認、インボイス制度への準拠、税務上の交際費の判定の3項目で、同じデータを使ってLLM単体と比べている。

2つの発表には、共通点が3つある。

1. 対象を1つの工程に絞っている。マルサンアイは、効果の検証対象が商品企画のプロセス全体ではなく、コンセプトシート作成の工程だと注記している
2. 人の役割を書いている。空いた時間を何に使うか、人がどこで確かめるかが書かれている
3. 数字の種類が分かる。マルサンアイの数字は導入前と導入後の平均の比較で、年間約1万時間は月10,000件規模の現場を想定した見込みだ

他社の事例を読むとき、また支援会社から事例の説明を受けるときは、この3点を確かめるとよい。対象はどの工程か、人は何をしているか、数字は導入前後を比べたものか見込みか。3つが分からない事例は、自社の計画の根拠にしにくい。

AIエージェントの導入支援を頼むときに確かめること

自社だけで進めるか、外部の支援を入れるかは、上の6つの段階のどこに人が足りないかで決める。私の見方では、導入支援は大きく3つの形に分かれる。

製品や支援会社を選ぶときは、「エージェント」という名前より中身を見る。Gartnerは先の予測と同じ発表で、AIアシスタントやRPA、チャットボットなどの既存の製品を、実質的なエージェントの機能を入れないまま呼び替える「エージェントウォッシング」を指摘し、数千社あるベンダーのうち実際にエージェント型AIを提供しているのは130社程度と推定した。

どの形を選んでも、次の3つは自社の手元に残す。業務の判断基準、評価の問題集、権限の一覧だ。作り方や支援会社が変わっても使い回せる、導入の資産になる。

支援会社の見極め方はFDE支援会社の選び方に、伴走型の支援の種類はAIの伴走支援とはにまとめた。業務の現場に入ってAIを本番まで動かす職種についてはFDEとは？に書いた。私たちのFDE実装支援（3か月〜 / 月額100万円〜）の中身はサービス詳細にある。