AIエージェント 作り方｜中小企業が最初の1本を作る手順
「AIエージェントを作りたい」という相談を受けるとき、最初に返す言葉はほぼ同じです。「作る前に、何を代わりにやらせたいか決まっていますか?」
ツールの比較やプログラムの書き方を調べるより前に、「業務の切り出し」の質で最初の1本が定着するかどうかが決まります。自社の業務をAIエージェントで毎日動かしながら複数社のAI顧問を務めている立場から率直に言うと、試作が現場に根付かない案件の多くは、業務の切り出しが甘いまま作り始めています。
ここでは、業務の切り出しから試作・本番移行までの工程を順番に整理します。内製で進めるか代行を選ぶかの判断軸も含め、担当者が今日から手を動かせるよう構成しました。
AIエージェントとは何か:定義を先に揃えておく
「AIエージェント」は人によって指しているものが異なるので、まず定義を確認します。
広義には「目的を与えると自律的に行動を組み立てるソフトウェア」ですが、中小企業の現場で最初に作るものはもっとシンプルです。「特定の入力を受け取り、一連の処理を自動でこなして、結果を出力する仕組み」と捉えると、最初の一歩が踏み出しやすくなります。
混同されやすいのが、AIチャットボット(単発の問答に応答する)・RPA(画面操作を自動化する)・関数やマクロ(ExcelやSpreadsheetsで計算する)との違いです。AIエージェントが引き受けるのは「判断が入る処理」です。
定型の入出力で済む業務であれば、RPAや関数で十分なケースが多くあります。AIを使う必要がない場面は、実際には少なくありません。
→ RPAや関数との具体的な使い分けはAIエージェントとRPA・Excelの違いと使い分けで整理しています。
最初のステップ:業務の棚卸しと滞りの特定
AIエージェントを作る前に、業務の棚卸しをします。ツールを選ぶのはその後です。
棚卸しで見るのは三つです。
1 繰り返し発生する作業
週に何度も同じフォーマットでメールを書いている、同じ資料をコピー&ペーストしている、毎朝同じ確認作業をしている——こうした「パターンが固まっている仕事」が候補になります。ルールが安定しているほど、AIに渡したときの出力も安定します。
2 判断が入るが、判断の根拠を言語化できる仕事
「このお客さんからの問い合わせなら、こう返す」という判断ルールが説明できるなら、AIに渡せます。逆に「長年の感覚」でしか答えられない判断はAIには向きません。「なぜそう判断するか」を5行で書けるかどうかが、ひとつの目安です。
3 担当者が「面倒だな」と感じているが後回しになっている仕事
これが最も見つけやすい候補です。後回しになるのは、価値に対して手間が大きすぎるからです。そこに滞りがあります。
出典: 自社作成
棚卸しが終わったら、候補を「誰が・何分・週何回やっているか」で数値化します。数値化できないものは優先度を下げます。最初の1本は、数値化できてかつルールを言語化できるものを選んでください。
詳しい棚卸しの進め方はAIエージェント導入のための業務棚卸しにまとめています。
ツール選択の前に:関数・RPA・AIの適材適所
候補業務が決まったら、「本当にAIエージェントが必要か」を問い直します。
関数・マクロで十分なもの
入力と出力が決まっていて、途中に判断が入らない処理です。集計・フォーマット変換・リスト整理の多くはここに入ります。ExcelやGoogleスプレッドシートの関数で完結するなら、それが最も安定した選択です。
RPAが向くもの
決まった画面を決まった順番で操作する作業です。ただしシステムのUI変更に弱く、メンテナンスコストが継続して発生します。「操作の自動化」と「判断の自動化」は性質が異なります。
AIエージェントが本領を発揮するもの
自然言語の読み書きが入る、判断の分岐が多い、複数のツールをまたぐ、担当者が毎回判断しながらこなしている——こうした仕事です。
三つを混在させても問題ありません。たとえば「Googleフォームの回答をスプレッドシートに整形する(関数)→内容を読んでカテゴリを判定する(AI)→担当者のチャットに通知する(API連携)」という組み合わせは現場でよく見るパターンです。それぞれの強みを組み合わせる設計が、安定した運用につながります。
試作の進め方:最初の1本を1週間で動かす
ここからが実際の「作り方」です。最初の試作は「1週間以内に動く状態を作ること」だけを目標にします。完成度は後から上げます。
ノーコード・ローコードツールから始める
プログラムが書けなくても、現在はノーコードのエージェントビルダーが複数あります。Make(旧Integromat)、n8n、Microsoft Copilot Studio、Google Apps Script、Power Automateなどが代表的です。
ツール選定は「すでに使っているツールと相性がよいもの」を優先します。Google WorkspaceユーザーであればApps Script、Microsoft 365ユーザーであればPower AutomateかCopilot Studioから入ると、連携の手間が少なく済みます。
試作の具体的な手順
1. 入力と出力だけ決める
「どんなデータが入り、何を返すか」を紙1枚に書きます。処理の中身はまだ書きません。入出力の定義が曖昧なまま作り始めると、何が問題なのかを後から切り分けにくくなります。
2. 入力データを実物で用意する
実際のメール文・実際のフォーム回答・実際の問い合わせ5件を手元に置きます。架空のサンプルで試作を進めると、本番投入後の精度を読み誤ります。実データで動かすことが、試作段階の最大の目的です。
3. 1ステップだけ動かす
最初から全工程を繋げようとしない。「メールを読んでカテゴリを返す」だけを先に動かします。1ステップで期待どおりの出力が出てから、次の工程を足します。
4. 現場担当者に使わせる
作った本人だけが試すと見落としが増えます。実際に使う人に試してもらい、「どこが違う」「どう直せばよいか」を直接聞きます。この対話から出てくる言葉が、次のプロンプト改善の材料になります。
5. 合否の基準を決めてから精度を上げる
「10件中8件以上が正解なら本番移行」など、基準を事前に設けます。感覚で「まあ良いか」と進めると、後で修正が増えます。
プロンプト設計のポイント
LLM(大規模言語モデル)を使う場合、プロンプト(指示文)の質が出力を左右します。指示を短くまとめようとせず、以下の要素を順番に書きます。
- 役割(あなたは何をする存在か)
- 入力(受け取るデータの形と範囲)
- 出力(返す形式と字数・項目)
- 制約(やってはいけないこと)
- 実例(1〜3件の入出力ペア)
実例を1件入れるだけで出力の安定度が変わります。「こういう入力のときはこう返す」という例を必ず付けることを習慣にしてください。抽象的な指示だけでは、モデルの解釈がぶれます。
内製か代行か:判断の分かれ目
試作の段階で「これは自社で作り続けられるか」を判断します。
出典: 自社作成
内製で進めやすいケース
- 入出力がシンプルで使うツールが1〜2個に収まる
- 担当者が試行錯誤に週1〜2時間を割ける
- 社内データを外部に出したくないセキュリティ要件がある
- 試作で動いたものを自社で育てていきたい
代行が現実的なケース
- 複数のシステムをまたぐ連携が必要
- 社内に試作を引き受けられる人材がいない
- 業務フローが複雑で、仕様の言語化自体に時間がかかる
- セキュリティ要件の判断が必要で、外部の視点がほしい
内製と代行は二択ではありません。「試作だけ内製で方向を確認し、本番設計は代行に依頼し、その後の運用は内製に戻す」という分け方が、費用対効果の面で合理的なケースがあります。
→ 内製と代行の選び方の詳細はAIエージェント:内製か代行かを判断する基準で整理しています。
内製で始める場合に着手前に決めることは、AIエージェントを内製する前に決める3つのことで確認できます。
本番移行で定着させるための3点
試作が現場の評価を通過したら本番移行です。ここで失敗するケースの多くは、次の三つのどれかに当てはまります。
1. 担当者が「使い方」だけ覚えていて「仕組み」を知らない
エージェントが止まったとき、担当者が何もできないと現場が止まります。「ここを直せば動く」という最低限の構造を、運用担当者が理解している状態にしてから本番移行します。完全な理解は不要です。「どのファイルのどこを変えれば出力が変わるか」が分かる程度で十分です。
2. 出力の確認者がいない
AIの出力は正しく見えて間違っている場合があります。最初の2〜4週間は、エージェントの出力を人が確認する仕組みを残します。「全量チェック」から始め、精度が安定したら「抜き取りチェック」に切り替えます。この移行のタイミングを事前に決めておくことが、過剰な確認コストを防ぎます。
3. 改善の窓口がない
「なんか変な結果が出た」という声が現場から来ても、誰に言えばよいか分からないと改善が止まります。フィードバックの窓口(チャットのチャンネル1本でも構いません)を決めておきます。小さな気づきを拾う仕組みが、長期的な精度向上を支えます。
「AIが不要」と分かるのも財産
棚卸しをして試作を重ねると、「これはAIでなくてもよかった」という結論になる業務が出てきます。これは失敗ではありません。
「関数で十分」「RPAの方が安定する」「そもそもこの業務自体をやめられる」——こうした発見は、AIを使わずに工数を削れる場所を特定したことを意味します。
自社でも、最初の棚卸しで10業務を候補に挙げたところ、AIエージェントが有効だったのは3業務で、残り7業務はExcelの数式変更とルール整理で解決しました。「AIを入れた3件」より「AIなしで解決した7件」の方が現場への定着が早く、担当者の負荷が下がるまでの期間も短かったのが実感です。
AIエージェントが不要と判断できたこと自体が、業務整理の成果です。ツールを使う判断と使わない判断は、同じ重さで扱ってください。
小さく始めて積み上げる:1本目から複数本へ
最初の1本が本番稼働したら、次の候補を選びます。このとき、最初に作った棚卸し一覧に戻ります。
複数のエージェントを同時に作ろうとすると、整合性の管理と担当者の認知負荷が上がります。「1本動かす→評価する→次を選ぶ」のサイクルを守ることが、半年後に5本・10本と積み上がる最短経路です。
進捗の管理には、エージェントごとに「入力・出力・担当者・チェック方法・改善ログ」の5項目を記録するシートを1枚作ることをすすめています。台帳が1枚あるだけで、引き継ぎのコストと「なぜこう動いているか分からない」という属人化のリスクが下がります。
意思決定のスピードと質が上がるのは、個々の業務が自動化された後ではなく、「どの業務にどのエージェントが動いているか」を担当者が把握できている状態になってからです。
よくある疑問
Q. プログラムが書けなくても作れますか?
最初の試作はノーコードツールで作れるケースが多いです。ただし複雑な条件分岐や外部システムとの連携が必要になると、コードが入る場面が出てきます。試作の範囲を入出力がシンプルな業務に絞ることで、ノーコードの範囲に収めやすくなります。
Q. どのAIモデルを使えばよいですか?
用途と社内のセキュリティポリシーによります。社内データを扱うなら、データが外部サーバーに送られる範囲を確認してから選んでください。主要モデルの比較はChatGPTとGeminiの比較と選び方で整理しています。
Q. セキュリティが心配です
「どのデータがどこに送られるか」を先に確認します。クラウド型のAIサービスは利用規約でデータの取り扱いが定義されています。社内の機密情報を扱う場合は、その確認を設計の前段に置いてください。
Q. 導入後に使われなくなることはありますか?
あります。その主な原因は「担当者が変わったときの引き継ぎが難しい」「精度が下がっても誰も直せない」「そもそも業務フローが変わった」の三つです。前段で触れた台帳管理と改善窓口の設置が、定着率に直接影響します。
Q. 何から始めればよいか分からない段階です
業務の棚卸しから始めてください。まだ候補業務が決まっていない場合は、無料AI診断で現状の整理から入ることもできます。
自社で進めるか支援を使うか
試作を進める中で行き詰まった場合、外部の支援を使うことは後退ではありません。業務の切り出しと試作の方向性を一緒に決める工程だけ外部に依頼し、その後の運用を内製に戻すケースもあります。
自社内製を軌道に乗せたい場合の支援についてはAI内製支援の進め方を、代行依頼を検討している場合は進め方の詳細を参照してください。