既製ツールと自作の比較が噛み合わない理由
業務にAIを入れると決めたあと、既製のSaaSを契約するか自分たちで組むかで話が止まることがあります。長引く原因は、比べている中身がそろっていないことにあります。既製ツールは1人あたりの月額で示され、自作は開発の見積書で示されます。この2つを並べても、どちらが安いかは決まりません。
判断できる形にするには、条件を先に分けます。次の5つに落とすと、業務ごとにどちらが有利かが見えます。
- はじめの立ち上がりの速さ … 使い始めるまでに何が必要か
- 自社の業務ルールへの合わせ込み … 判定の基準や例外の扱いをどこまで反映できるか
- データの置き場所と権限 … どこに保存され、誰が見られるか
- 変更が必要になったときの待ち時間 … 直したい状態から反映までに何が挟まるか
- 使う人数が増えたときの費用の伸び方 … 対象を広げたときに金額がどう動くか
この5つは独立していません。立ち上がりが速いものは合わせ込みが利かず、合わせ込みが自由なものは立ち上がりに時間がかかります。どちらかが優れているという結論にはならないため、対象業務ごとに観点別で判定します。
5つの観点で並べる
| 観点 | 既製ツール | 自作 |
|---|---|---|
| はじめの立ち上がり | 契約と初期設定で使い始められる。数日から数週間 | 業務の手順を書き出す工程から始まる。対象を絞っても数週間から数か月 |
| 業務ルールへの合わせ込み | 設定項目の範囲内。用意されていない条件は表せない | 判定の基準と例外を自分で決められる。書ける範囲がそのまま上限 |
| データの置き場所と権限 | 提供元の環境に保存される。権限の粒度は提供される機能次第 | 保存先と権限の設計を自社で決められる。設計と運用の責任も自社が持つ |
| 変更の待ち時間 | 設定の範囲なら即日。範囲外は提供元の開発計画を待つ | 直す人が社内にいれば同じ週で回る。いなければ外注の待ちが発生する |
| 人数が増えたときの費用 | 1人あたりの単価に人数が掛かる。使う人が増えるほど伸びる | 初期費用が先に出て、人数が増えても大きくは動かない |
| 使わなくなったとき | 解約すれば止まる。作ったものは残らない | 使わなくても保守の担当が必要。放置すると動かなくなる |
表の下2行が、検討の初期に抜けやすい部分です。順に理由を補います。
立ち上がりの速さと合わせ込みは反対に動く
既製ツールが速いのは、判断の型が先に決まっているためです。項目を埋めれば動きますが、その項目に無い条件は表せません。自作が遅いのは逆の理由で、何を判断させるかを自分で決める工程が最初に来ます。
この工程は、外注しても社内でやっても発生します。省略できないため、立ち上がりの速さを重視する場面では既製ツールが向きます。対象業務がAIで処理できるかどうかを確かめたい段階も同じです。処理できるかの答えは、どちらで組んでも大きくは変わりません。
データの置き場所は契約で決まる
自作の側に「設計できる」と書きましたが、これは有利とは限りません。保存先を決められるということは、決める責任も持つという意味です。社内規程に照らして問題のない構成を自分たちで作り、権限の棚卸しを続ける必要があります。
既製ツールの場合、この部分は契約内容の確認に置き換わります。確認するのは、データがどこに保存されるか、提供元が学習に使わない取り扱いになっているか、誰がどこまで見られるか、操作の記録がどれだけの期間残るかです。社内で扱ってよいデータの範囲そのものは、どちらを選んでも自社で決める必要があります。整え方は 生成AIの社内利用ルールをどう作るか で扱っています。
費用は人数の増え方で順序が入れ替わる
既製ツールは1人あたりの単価で費用が決まるため、対象を全社へ広げると金額が人数に比例して伸びます。自作は初期費用が先に出るため、少人数のうちは高く見えます。
順序が入れ替わる点は、単価と人数と想定利用年数で変わります。判断のためには、既製ツールの年額と、自作の初期費用を想定利用年数で割った額に年間の改修見込みを足した額を、同じ表に並べます。片方を初期費用で、もう片方を月額で語っている限り、比較になりません。工程ごとに費用がどこへ出るかは AI開発は外注か内製か で分解しています。
既製ツールが合わなくなる3つの型
既製ツールで始めたあと、途中で行き詰まる場合には型があります。どれも「性能が足りない」という形では現れません。
型A：例外の扱いが設定に落ちない
ふだんの手順は設定できたのに、月に数件しかない例外を表現できない状態です。条件の組み合わせが自社固有で、用意された設定項目では表せません。
見分け方は、設定を作る段階で「この場合は担当者が個別に見る」という運用を追加したかどうかです。追加した箇所が1つなら運用で足りますが、複数になり、しかもそれが処理全体の判断の中心にあたる場合、以降も設定の範囲外が増え続けます。
型B：既存の社内システムとの連携が要る
処理の途中で社内システムの情報を読む、あるいは結果を書き込む必要がある状態です。外部連携の機能があるかどうかだけでは判断できません。読み書きが両方できるか、処理のどの時点で呼び出せるか、失敗したときに再実行できるかを、実際の業務手順に当てて確かめます。
処理の終了後にしか呼び出せない場合、途中で社内システムの情報を使って判断する手順は組めません。この制約は契約前の資料では分かりにくく、試した段階で出ます。
型C：権限と監査記録の要件が厳しい
誰が何を見られるかの区分が細かい、あるいは操作の記録を一定期間保持して外部へ提出する必要がある状態です。要件は業務側ではなく、監査や取引先との契約から来ます。
見分け方は、対象業務が外部の審査や検査の対象になっているかどうかです。対象なら、必要な粒度を先に書き出し、既製ツールの機能と突き合わせます。ここが合わない場合、設定でも運用でも埋められません。
| 型 | 何を見て判断するか | 合わない場合の扱い |
|---|---|---|
| 例外の扱い | 運用で個別対応にした箇所が、処理の判断の中心にあるか | 判断の部分だけを自作し、前後は既製ツールに残す |
| 社内システムとの連携 | 読み書きの可否・呼び出せる時点・再実行の可否がそろうか | 連携が必要な工程を自作し、下書きの作成は既製ツールに残す |
| 権限と監査記録 | 必要な区分の細かさと記録の保持期間を満たすか | 対象業務ごと自作へ寄せる。部分的な切り分けでは満たせない |
型Cだけ扱いが違うのは、要件が処理の一部ではなく全体にかかるためです。記録の保持期間や権限の区分は、工程を分けても緩みません。
全部を作るのではなく、境目を決める
3つの型のうち例外と連携については、対象業務をまとめて自作へ移す必要はありません。汎用の部分は既製ツールに任せ、自社固有の判断だけを自作にする形が取れます。
つなぎ目を作るときに決めておくのは、渡す情報の形と、失敗したときにどちらが止まるかです。この2つを決めずに接続すると、どちらかを直すたびにもう一方の修理が必要になり、分けた利点が消えます。
境目の位置は、業務の性質で決まります。定型で件数が多い部分は既製ツールに寄せられます。判断を含み、その基準が社内の事情で決まっている部分は自作に寄ります。件数が少なく判断も定型なら、そもそもAIを入れる対象から外すという選択も残ります。対象業務の選び方は 生成AIのPoCが本番で止まる理由 で扱っています。
既製から自作へ切り替えるときに持ち出しておくもの
いま既製ツールを使っているなら、切り替えの可能性を前提に、次の3つを自社の側に残しておきます。どれも契約を解約した時点では取り出せなくなります。
- 指示文（プロンプト） … ツールに書き込んだ指示の文面。設定画面の中だけに存在している状態を避け、社内の文書として同じ内容を保管する
- 業務ルール … 判定の基準と例外の一覧。ツールの設定項目に合わせて分解する前の、業務としての決まりを書き残す
- 評価用データ … 入力と、正しい出力の組。過去に処理した実例のうち、判断が難しかったものを含める
3つのうち効くのは評価用データです。切り替えの検討で最も時間がかかるのは、新しく組んだものが以前と同じ判断をするかの確認です。入力と正しい出力の組が手元にあれば、この確認は比較の作業になります。無ければ、まず正解を作る作業から始まります。
契約の段階では、退会時に何を書き出せるかを確認します。処理の履歴、設定した内容、登録した社内文書のそれぞれについて、形式と範囲を聞きます。書き出せない項目があるなら、その部分は自社の文書として二重に持ちます。実際に持ち出す作業は、切り替えを決めてからでは間に合いません。
当面の構成と、切り替えの条件を先に書く
判定は、対象業務ごとに1枚の記録として残します。並べるのは次の3列です。
| 観点 | いまの条件をどう書くか | 判定 |
|---|---|---|
| 立ち上がりまでに使える期間 | 業務側が求めている開始時期を書く | 3か月以内なら既製ツール |
| 例外の割合と扱い | 全件のうち個別対応が必要な割合と、その判断内容を書く | 判断の中心が個別対応なら自作 |
| 社内システムとの接続 | 読み書きの必要と、呼び出す時点を書く | 処理の途中で接続が必要なら自作 |
| データと権限の要件 | 保存先の制約と、必要な権限の区分を書く | 外部の審査の対象なら自作 |
| 使う人数の見込み | 1年後と3年後の想定人数を書く | 人数が増え続けるなら自作の検討へ |
| 直す頻度 | 業務ルールが変わる回数の見込みを書く | 年に数回に収まるなら既製ツール |
すべてが同じ側に寄ることは多くありません。分かれた場合は、いま止まっている業務を動かす側を選び、もう一方を切り替えの条件として書き残します。
条件は数で書きます。「使いにくくなったら」では判断できないため、利用人数が何人を超えたら、あるいは個別対応の割合が何割を超えたら見直す、という形にします。見直す時期も決めます。契約の更新月は、切り替えを検討する自然な区切りになります。
書き残した条件は、次の更新の時期に開いて確認します。条件に届いていなければそのまま継続で構いません。届いていた場合に初めて、自作へ移す検討を始めます。この形にしておくと、毎回ゼロから議論することがなくなります。実際に自作へ進む場合の工程と見積の考え方は AIエージェント開発の進め方 を参照してください。
まとめ：自作と既製ツールの判定と切り替え
- 月額単価と開発の見積書は同じ土俵ではない。立ち上がりの速さ、業務ルールへの合わせ込み、データの置き場所と権限、変更の待ち時間、人数が増えたときの費用の伸び方の5つに分けて判定する
- 費用を比べるときは、既製ツールの年額と、自作の初期費用を想定利用年数で割った額に年間の改修見込みを足した額を同じ表に並べる
- 既製ツールが合わなくなるのは、例外の扱いが設定に落ちない場合、処理の途中で社内システムとの連携が必要な場合、権限と監査記録の要件が厳しい場合の3つ。前の2つは工程を分けて対応できるが、権限と記録の要件は全体にかかる
- 汎用の部分は既製ツール、自社固有の判断だけを自作にする切り分けが取れる。つなぎ目では渡す情報の形と、失敗したときにどちらが止まるかを決めておく
- 既製ツールを使っている間に、指示文、業務ルール、評価用データを自社の側に残す。退会時に書き出せる範囲は契約の段階で確認する
- 切り替えの条件は数で書き、契約の更新月に開いて確認する。条件に届くまでは継続でよい
Augueでは、対象業務の棚卸しから、既製ツールに任せる範囲と自社で組む範囲の切り分け、実際の構築までを支援しております。どちらで始めるかの判定から一緒に整理できますので、ご興味がある方は是非ご相談ください。
関連する記事
対象業務の選び方と本番化の判断は 生成AIのPoCが本番で止まる理由、自作へ進む場合の工程と見積は AIエージェント開発の進め方、作る側を外注と社内でどう分けるかは AI開発は外注か内製か、選んだあとの効果を数字で説明する手順は AI導入の効果測定と投資判断 を参照してください。
よくある質問
既製ツールと自作では、年間の費用はどれくらい変わりますか？
一律の金額は出せません。既製ツールは利用人数と契約プランで決まり、自作は対象業務の例外の多さと接続先の数で決まるため、同じ業務でも会社ごとに順序が入れ替わります。比較するときは、既製ツールの年額（単価×想定人数）と、自作の初期費用を想定利用年数で割った額に年間の改修と運用の見込みを足した額を、同じ表に並べます。片方だけ初期費用で語ると比較になりません。
自作へ切り替える判断は、誰が持つべきですか？
対象業務の責任者と、社内システムの権限を持つ担当の2者で決めます。前者は例外の扱いと止めたときの影響を判断でき、後者は接続先とデータの取り扱いを判断できます。どちらか一方だけで決めると、動くものはできても社内システムにつながらない、あるいは業務の例外が抜けたものになります。費用の承認者は3人目として関わりますが、切り替えるかどうかの判断材料は前の2者が出します。
検証は既製ツールから始めるべきですか？
対象業務がAIで処理できるかを確かめる段階なら、既製ツールから始めたほうが早い場合が多いです。処理できるかどうかの答えは、どちらで組んでも大きく変わらないためです。ただし検証で使った指示文と入出力の記録は残しておきます。残していないと、自作へ移す段階で同じ検証をやり直すことになります。
既製ツールの外部連携機能があれば、自作は不要になりますか？
連携の口があるかだけでは決まりません。見るのは、必要なデータの読み書きが両方できるか、処理のどの時点で呼び出せるか、失敗したときに再実行できるかの3点です。読み取りだけ、あるいは処理の終了後にしか呼び出せない場合、業務の途中で社内システムの情報を使う処理は組めません。契約前に、この3点を実際の業務手順に当てて確かめます。