AIエージェントを非エンジニアが自分で作れる開発環境は増えましたが、製品の一覧を見比べても選べません。名前が並ぶだけでは、自社の担当者が使い切れるか、作ったものが社内に残るかが分からないためです。ここでは個別の製品ではなく、作り方の型で3つに分けて整理します。型が決まれば、候補になる製品は自然と絞られます。
製品名の一覧から選べない理由
開発環境の比較記事は、機能の有無が並んだ表になっていることが多いです。連携できるサービスの数、テンプレートの数、日本語対応の可否といった項目です。これらは確かに違いますが、導入後に問題になるのは別のところです。
実際に詰まるのは、担当者が作りたかった業務を最後まで組めない、作った本人が異動したあと誰も触れない、想定より請求額が増える、という3つです。いずれも機能一覧には出てきません。作り方の型が違うと、この3つの出方が変わります。
もう一つ、前提として確かめておくことがあります。そもそも自分たちで作るのか、既製の製品を買うのかの判断です。ここが未決のまま開発環境を選び始めると、比較の軸が定まりません。判断の順序は「AIエージェントは既製ツールか自作か」で扱っています。
開発環境を3つの型に分ける
作り方で分けると、次の3つになります。製品によっては複数の型をまたぐものもありますが、主に使う画面がどれかで判断します。
| 型 | 作れる業務の範囲 | 社内に残るもの | 詰まったときに直せる人 |
|---|---|---|---|
| 画面で組む型 | 手順が決まっていて、扱うデータの形が毎回同じ業務 | サービス内の設定。外へ書き出せる形は製品による | 同じサービスの画面を触れる人。社外に頼まなくても直せる |
| 対話で作る型 | 手順を文章で説明できる業務。試しながら形を変える段階に向く | 会話の履歴と生成された設定。指示文を別に保存しないと辿れない | 指示を書き直せる人。中の作りまでは追いにくい |
| コードを社内で持つ型 | 既存システムとのつなぎ込みや、件数が多く処理の細かい制御が要る業務 | コードと変更の履歴。置き場所を社内に持てる | コードを読める人。社内にいなければ外部に依頼することになる |
画面で組む型
部品を並べて線でつなぎ、処理の流れを画面上で組み立てます。何がどう動いているかが見えるため、作った本人以外も追いやすい形です。テンプレートが用意されている業務であれば、最初の1本は数日で動きます。
制約は、用意された部品の外へ出られないことです。連携先が対応していない社内システムがあると、そこで止まります。また、処理の分岐が増えると画面が読みにくくなり、ある規模を超えると管理が難しくなります。
対話で作る型
やりたいことを文章で伝えると、動くものが返ってくる形です。作り始めるまでの距離が最も短く、業務の担当者が自分で試せます。要件が固まっていない段階で、形を変えながら確かめる用途に向きます。
注意するのは、何を指示したかが残らないと再現できない点です。会話を重ねて調整した結果だけが手元にあり、なぜその形になったのかが分からなくなります。うまく動いた時点の指示文を、業務の手順書と同じ場所に保存しておく運用が要ります。
コードを社内で持つ型
生成AIにコードを書かせ、出てきたものを社内の置き場に保管する形です。書くのはAIでも、どこに置き、誰が変更を承認するかは社内で決めます。既存システムとのつなぎ込みや、件数が多く細かい制御が要る業務まで作れます。
前提として、コードを読める人が社内か協力先にいることが要ります。非エンジニアが指示を出して作ること自体は可能ですが、動かなくなったときに読める人がいないと止まります。つなぎ込みの範囲をどう決めるかは「AIエージェントを基幹システム・SaaSにつなぐ」で扱っています。
型ごとに変わる3つの点
比較するときに見るのは、機能の数ではなく次の3点です。
作れる業務の範囲。 扱うデータが毎回同じ形で届く業務なら、どの型でも作れます。届き方がまちまちで、既存システムから取りに行く必要がある業務は、画面で組む型では対応できないことがあります。対象業務を1つ決めてから型を選ぶ順序にすると、この判断ができます。対象の絞り込み方は「生成AI内製化はどの業務から始めるか」を参照してください。
社内に資産として残るか。 残るかどうかは、サービスの外へ持ち出せる形になっているかで決まります。画面で組む型は設定の書き出しに対応しているかが製品ごとに違い、対話で作る型は指示文を自分で保存しない限り残りません。契約を切り替える場面で差が出ます。
詰まったときに誰が直せるか。 作った人が異動や退職で離れたあと、誰が引き取るかを先に決めます。ここが決まらないまま数が増えると、動いているが誰も触れないものが溜まります。運用の引き取り方は「内製したAIエージェントの運用・保守」で扱っています。
情報システム部門が導入前に確認する条件
業務側が使いたい製品を見つけてから相談が来ると、審査に時間がかかります。先に条件を示しておくと、候補の段階で外れます。
| 確認すること | 何を見るか | 条件を満たさないときの扱い |
|---|---|---|
| 社内データの持ち出し可否 | 入力したデータが学習に使われないか、保存先の国はどこか、保存期間はどれくらいか | 個人情報や取引先の情報を扱う業務では採用しない。扱わない業務に限って許可する |
| アカウントと権限の管理 | 法人契約で一括管理できるか、退職時にアカウントを止められるか、誰が何を作ったか一覧で見えるか | 個人契約しかない製品は、業務データを入れない前提でのみ使う |
| 費用の増え方 | 定額の範囲、処理件数に応じて増える部分、アカウントを増やしたときの単価 | 件数が読めない業務では、上限額を設定できる製品に限る |
| 作ったものの引き継ぎ | 設定や指示文を外へ書き出せるか、作った本人以外が開けるか | 書き出せない製品は、止まっても業務が回る範囲に限って使う |
| 既存システムとの接続 | 社内システムへ接続する経路、接続に使う認証情報の置き場 | 認証情報を製品側に預ける形しかない場合は、読み取りのみに絞る |
この表をそのまま申請の様式にすると、業務側が自分で確認して持ってくるようになります。審査の観点をもっと細かく揃える場合は「生成AIのセキュリティ審査チェックリスト」が使えます。
費用の増え方は件数で見積もる
導入前に見落としやすいのが、処理件数に応じて増える部分です。定額プランの金額だけを見て稟議を通すと、動かし始めてから超過分が乗ります。対象業務の月間件数と、1件あたりの呼び出し回数を先に数えておきます。試作の段階で1件あたりの実績が取れるため、そこから月額を出せます。
最初の1業務をどの環境で作り始めるか
型を決めるのは、製品の優劣ではなく担当者と業務の状況です。次の3つのどれに当てはまるかで選びます。
| 担当者と業務の状況 | 合う型 | 最初に決めること |
|---|---|---|
| 作りたい業務が決まっていて、手順も固まっている | 画面で組む型 | 連携先が対応しているか。対応していなければ他の型へ |
| 何をどこまで任せられるか自体を確かめたい | 対話で作る型 | 指示文をどこに保存するか。残さないと次に進めない |
| 既存システムから取ってくる必要がある、または件数が多い | コードを社内で持つ型 | コードを読める人を社内か協力先のどちらに置くか |
途中で型を変えることはできます。対話で作る型で形を確かめ、固まってから画面で組む型やコードへ移す進め方は無理がありません。逆に、最初からコードを社内で持つ型を選ぶと、作れる範囲は広い代わりに、業務側だけでは判断できない事柄が早い段階で出てきます。
どの型を選んでも、扱ってよいデータの範囲を業務側が判断できる状態にしておくことが前提になります。ここが曖昧なまま始めると、担当者は差し障りのない軽い作業にしか手を伸ばせません。担当者を育てる側の設計は「非エンジニアがAIを作れるようになるまで」、社内で持つ範囲と外注に残す範囲の線引きは「生成AI・AIエージェントの内製化とは」で扱っています。
まとめ:開発環境を型で決めるための要点
- 機能一覧では選べない。作り方の型(画面で組む、対話で作る、コードを社内で持つ)で分けると比較できる
- 型が変わると、作れる業務の範囲、社内に残るもの、詰まったときに直せる人が変わる
- 情報システム部門は、データの持ち出し可否、アカウントと権限、費用の増え方、引き継ぎ、既存システムとの接続を先に条件として示す
- 費用は定額部分だけでなく、対象業務の月間件数と1件あたりの呼び出し回数から見積もる
- 対象業務を1つ決めてから型を選ぶ。形が固まっていない段階は対話で作る型から始め、固まってから移す進め方が取れる
Augueでは、非エンジニアの担当者がAIエージェントを自分で作れるようになるまでの伴走支援を行っており、対象業務の選定から開発環境の選び分け、社内に残る形での引き継ぎまでを一体で進めています。どの環境で最初の1業務を作り始めるか検討されている方は、是非ご相談ください。
よくある質問
開発環境の費用はどれくらい見ておけばよいですか?
一律の目安は出せません。同じ製品でも、月に何件処理するか、何人がアカウントを持つかで請求額が数倍変わるためです。見積もるときは、対象業務の月間件数、1件あたりに呼び出す回数、作った人以外に配るアカウント数の3つを先に数えます。この3つが出ていれば、各サービスの料金表に当てはめて比較できます。数えずに定額プランだけで判断すると、動かし始めてから超過分が乗ります。
すでにRPAを使っている場合、AIエージェントの開発環境へ置き換えるべきですか?
全部を置き換える前提では考えません。RPAが安定して回っている工程は、画面の操作手順が決まっていて例外が少ない部分です。そこは動いたままにして、読み取りや文面の判断で止まっていた工程だけを切り出す形が無理がありません。既存の処理を呼び出せるかどうかを、開発環境を選ぶ段階で確認しておきます。
作ったものを他の部署へ配るときに気をつけることはありますか?
配る前に、閲覧できるデータの範囲が受け手ごとに変わるかを確認します。作った本人の権限で動く作りになっていると、本人には見えて相手には見えないはずの情報が、そのまま相手の画面に出ます。加えて、問い合わせ先を配布時に明記しておきます。書かずに配ると、動かなくなったときの連絡が情報システム部門へ集まります。
まず個人のアカウントや無料プランで試してもよいですか?
社内のデータを入れない範囲であれば、操作を覚える目的では使えます。ただし業務のデータを入れた時点で、契約と管理の話に変わります。個人契約のまま業務で使うと、退職時にアカウントごと持ち出される状態になり、履歴も引き継げません。業務のデータを扱うと決めた時点で、法人契約へ移す前提で試し始めるほうが後戻りがありません。
関連する記事
生成AI・AIエージェントの内製化とは|どこまで自社で持ち、どこを外注に残すか外注に残す範囲は、業務の発生頻度と仕様がどこにあるかで決まります。着手前に確かめる5点、基盤・実装・判定基準・運用の層ごとの線引き、持ち方の3つの型、併走を終える判断までを表で整理しました。
非エンジニアがAIを作れるようになるまで|社内AI人材育成の設計と評価研修を終えても業務が変わらない状態を育成の設計から立て直します。使える・直せる・作れる・任せられるの4段階と各段階の判定基準、最初の対象者の選び方、伴走を終えたあとも自走が続く条件を整理します。
AIエージェント内製と支援の分担|社内に置く3工程と外に任せる2工程、動かすのは最小3人自社だけで作れるかは人員構成ではなく、5工程のどこを社内に置くかで決まります。要件定義・評価・保守は社内に残し、認証と権限の設計、他システムとの接続は外部の支援で補う分担と、最小3人の体制をまとめました。



