この記事の要点
- AI社内ツールの開発を自作でやるか外注するかは、①扱うデータの機密性 ②利用人数と業務のクリティカル度 ③既存システム連携の有無 ④止まったときの影響、の4条件で判定できます（1つでも「高い側」なら外注寄り）
- 生成AI＋ノーコードで自作できるのは「部門内で完結・非機密・止まっても手作業に戻せる」領域まで。権限設計・API連携・監査ログが要る領域は自作の範囲外です
- 自作の失敗は「作った人しか直せない」「機密データが外に出る」「業務が変わると使えなくなる」の3つにほぼ集約され、着手前に回避条件を決めておけば防げます
- 費用は初期費用ではなく3年TCO（ライセンス＋担当者の工数＋改修費）で比較します。利用人数が多く長く使う業務ほど、外注のほうが安くなる場面があります
現場から「この作業、AIで自動化できませんか」と声が上がっています。けれど自分たちで作れるのか、外注すべきなのか、判断がつきません。中小企業の情報システム担当や業務改善の担当者から、いちばん多く聞かれるのがこの悩みです。この記事では、ツールの紹介ではなく「自社のケースはどちらに当てはまるのか」を判定するための条件を先に示します。読み終えたときに、社内で稟議を通すための材料が手元に残る形でまとめました。
目次
AIで社内ツールを開発するとき、自作と外注の分かれ目は？
自作か外注かの分かれ目は、開発スキルの有無ではありません。①扱うデータの機密性、②利用人数と業務のクリティカル度、③既存システムとの連携の有無、④止まったときに困る度合い。この4条件で判定でき、1つでも「高い側」に該当するなら、外注または専門家の関与を前提にすべきです。
ポイントは、加点方式で総合判断しないことです。「3つは自作でいけるから自作」ではなく、「1つでも該当したら外注寄り」と運用してください。4条件のどれか1つが破綻すると、他がどれだけ簡単でもツール全体が事故につながるためです。
| 判断軸 | 自作でよいライン | 外注が要るライン |
|---|---|---|
| ①データの機密性 | 公開情報・社内一般文書・自分の担当業務データ | 個人情報、顧客情報、人事情報、未公開の財務情報 |
| ②利用人数・クリティカル度 | 作成者＋数名、使えなくても手作業に戻せる | 全社/部門横断、止まると受注・請求・出荷が止まる |
| ③既存システム連携 | CSVを手動でアップロードすれば足りる | API連携、DBへの書き込み、リアルタイム同期 |
| ④停止・誤りの影響 | 作成者が不在でも数日待てる | 本人不在でも回す必要がある／社外に出る出力を扱う |
判断軸①：扱うデータの機密性はどこまでか
個人情報・顧客情報・人事情報・未公開の財務情報を扱うなら、自作は避けてください。社内マニュアルの検索、議事録の要約、定型文書のドラフト作成のように、公開情報や社内の一般文書にとどまるなら自作で構いません。境界は「そのデータが外部に漏れたとき、誰に説明する必要があるか」で引けます。
採用応募者データ、与信情報、顧客の個人情報を含む処理は外注寄りです。個人情報を含むデータを外部サービスに入力する場合、利用目的の範囲や第三者提供にあたるかの確認が必要になります※1。判断が難しければ法務・総務を巻き込むのが先です。
あわせて確認したいのが、契約形態の違いです。一般アカウント（無料・個人契約）と法人向けプラン・APIでは、入力データの学習利用の扱いが異なります。利用規約とデータ取扱い条項で、「入力データを学習に使わない設定になっているか」「保存期間はどれくらいか」「保存先のリージョンはどこか」を確認してください。ここが確認できないサービスに業務データを入れるのは、社内ツールの土台として危険です。
判断軸②：利用人数と業務のクリティカル度
利用者が作成者本人＋数名で、使えなくても手作業に戻せる業務なら自作で問題ありません。全社利用や部門横断、あるいは止まると受注・請求・出荷が止まる業務は、外注が前提です。目安のラインは「利用者5〜10名」「日次で回る基幹寄りの業務かどうか」の2つ。
なぜ人数で線を引くのか。利用者が増えると、開発以外のコストが一気に増えるからです。使い方の問い合わせ、権限の追加依頼、新入社員への説明、想定外の入力への対応。これらがすべて作った本人に集中します。10人が週に1回ずつ質問すれば、それだけで担当者の時間は毎週数時間削られます。
「作るのは楽しかったが、運用で疲弊した」というのは自作でいちばんよく聞く話です。人数が増える見込みがあるなら、最初から運用を誰が持つかを決めておいてください。
判断軸③：既存システムとの連携が必要か
基幹システム・会計・販売管理などとのデータ連携が必要になった時点で、難易度は跳ね上がります。CSVを手動でアップロードすれば済むなら自作の範囲。API連携、データベースへの書き込み、リアルタイム同期が必要なら外注の範囲です。
特に効くのが「読み取りだけか、書き込みも発生するか」の違いです。読み取りだけなら、最悪データが取れなくても業務は壊れません。書き込みが発生する場合、AIの出力が誤ったまま基幹データを更新するリスクが生まれます。在庫数や請求金額が書き換わってから気づく事故は、復旧に膨大な工数がかかります。
連携先システムのベンダーがAPIを公開しているか、追加ライセンスが必要か、という確認も先に済ませてください。ここが塞がっていると、そもそも設計が成り立ちません。
判断軸④：止まったとき・間違えたときに誰が困るか
作った本人が不在でも業務が回る必要があるなら、外注、少なくとも保守契約が必要です。判断の材料は2つ。障害時に一次対応するのは誰か。復旧の目標時間は半日でいいのか、1時間以内か。答えが出ないなら、そのツールは自作の範囲を超えています。
AI特有の観点として、出力が誤っていた場合に誰がチェックし、誰が責任を負うのかも決めておく必要があります。生成AIは事実と異なる出力を返すことがあり、人の確認を前提に組む必要があります。国が示すAI事業者ガイドラインでも、AIの利用にあたっては人間による監督や責任の所在の明確化が求められています※2。
社外に出る文書、見積、法務・人事の判断が絡む出力は、必ず人のレビューを挟む設計にしてください。「AIが出したから」で社外に出た誤りは、AIではなく会社の責任として扱われます。
※1 個人情報保護委員会「個人情報保護法」リンク
※2 経済産業省・総務省「AI事業者ガイドライン」リンク
生成AI・ノーコードで自作できる社内ツールの範囲はどこまで？
生成AI単体＋表計算で作れるのは、個人〜数名向けの文書処理・分類・要約系です。ノーコードやローコードを足すと、部門内の申請フロー・台帳・簡易チャットボットまで届きます。一方で、データ連携・細かい権限設計・監査ログが必要な領域は、手段を変えても自作の範囲外です。
生成AI＋スプレッドシートで作れるもの（個人〜数名規模）
議事録の要約、問い合わせメールの下書き、アンケート自由記述の分類、マニュアルからのQ&A作成。入力も出力もテキストで完結し、間違っても人がすぐ気づける業務は、この構成で十分に作れます。
実装としては、業務ごとにプロンプトをテンプレート化し、スプレッドシートの関数やGAS（Google Apps Script）で呼び出す程度。作成期間は数時間〜数日、コストは月数千円台から始められます。プログラミング未経験でも、生成AIにコードを書かせながら組み立てられる範囲です。
このレベルで止めるべき条件は、出力を必ず人が読んでから使う運用になっていること。チェックを飛ばして自動送信・自動登録に踏み込むなら、判断軸④に戻ってください。
ノーコード・ローコードで作れるもの（部門規模）
申請・承認フロー、案件台帳、社内文書を参照する簡易チャットボット。部門内で完結し権限が単純なアプリなら、業務アプリ系のノーコード基盤とAI機能の組み合わせで作れます。
- 業務データベース・台帳・申請フロー系のノーコード基盤（kintone など）＋AI連携機能
- Microsoft 365環境で使うローコード基盤（Power Platform など）＋Copilot系の機能
- 社内文書を読ませるチャットボット構築ツール（Dify などのAIアプリ基盤）
- 法人向けの社内AIチャットサービス（文書アップロード＋検索が主用途）
注意点は2つ。ライセンスがユーザー数課金のものが多く、全社に広げた瞬間に費用が跳ねます。そして権限やデータの設計を誤ると、見えてはいけない情報が別部署から見える状態になります。
このレベルで止めるべき条件は、利用部門が1つで、扱うデータに個人情報が含まれないこと。この2つが崩れたら、設計をレビューできる相手が必要になります。
自作では届かない領域はどこか（境界線の具体例）
基幹システムとのAPI連携、部署別・役職別の細かい権限制御、監査ログや証跡の保存、大量データの高速検索、24時間稼働が前提の処理。この5つは自作の範囲外と考えてください。動くものは作れても、業務で使い続ける状態を維持できません。
AI特有の難所もあります。社内文書を検索させるRAG（検索して回答させる仕組み）は、文書の分割方法や検索設定を調整しないと的外れな回答を返します。事実と異なる出力への対策、モデル更新時に出力の傾向が変わったときの再調整も必要です。
「動くものを作る」と「業務で使い続ける」の差は、ここにあります。デモはうまくいったのに現場で使われないツールの多くは、この差を見積もらずに本番化しています。
自作したAI社内ツールが失敗する3つのパターンと回避条件
自作の失敗は「作った人しか直せない」「機密データの扱いが野放しになる」「業務が変わると使えなくなる」の3つにほぼ集約されます。いずれも着手前に回避条件を決めておけば防げます。逆に言えば、回避条件を満たせるなら自作して構いません。
失敗①作った人しか直せない：属人化の回避条件
最も多い失敗が属人化です。作った担当者が異動・退職した瞬間、誰も中身を触れずツールが凍結します。プロンプトと処理の意図をドキュメントに残し、第三者が触れる状態を作れるかどうかが、自作の可否ラインになります。
典型的な発生の仕方はこうです。個人のGoogleアカウントにスクリプトが置かれ、APIキーは本人しか知らず、仕様書もありません。退職時にアカウントが停止され、ツールも一緒に消えます。悪意もミスもないのに業務が止まります。
回避条件は3つです。
- 作成物の保管場所を個人アカウントではなく会社管理の領域にする
- 仕様・プロンプト・APIキーの管理方法を最低1ページのドキュメントに残す
- 引き継ぎ担当を最初から1名指名する（作成者以外）
この3つを満たせないなら、最初から外注か保守契約付きにしたほうが安全です。
失敗②機密情報が外に出る：セキュリティの回避条件
無料アカウントや個人契約のAIツールに業務データを入れる運用は、シャドーIT化して統制が効かなくなります。法人契約であること、学習利用がオフであること、入力してよいデータ区分が明文化されていること。この3つがそろって初めて、自作を許可すべきです。
怖いのは、事故が起きても気づけない点です。誰がどのサービスに何を入れたのか、会社側にログが残りません。数か月後に「実はあのツール、顧客名簿を貼り付けて使っていました」と発覚するパターンが起こり得ます。
回避条件は次の3つです。
- 利用するサービスを会社が把握し、承認している
- 入力データが学習に利用されない契約形態・設定になっている
- 入力禁止データ（個人情報・顧客名・未公開情報）のリストが社内に共有されている
あわせて、誰がツールにアクセスできるかの一覧を月1回は確認してください。退職者のアクセスが残っていた、というのは監査で必ず指摘されます。
失敗③業務が変わると使えなくなる：変化対応の回避条件
現行の業務手順を丸ごと固めて作ると、帳票の変更や組織改編で一気に使えなくなります。分岐点は、変わりやすい部分（項目名・文言・判断基準）を設定値として外に出せているかどうか。ここを作り込むほど寿命は短くなります。
回避条件は3つです。
- 変更頻度の高い項目（部署名、単価、承認者、判断ルール）をコードやプロンプトに直接埋め込まない
- 月1回程度は手を入れる前提で、担当者と時間をあらかじめ確保する
- 3か月使われなければ廃止する、と最初に決めておく
自作の最大の利点は、安く作れることではありません。合わなければ捨てられることです。捨てる前提で作れば、投資判断の失敗が小さく済みます。逆に「せっかく作ったから」と延命し始めた時点で、自作の強みは失われます。
AI社内ツール開発の費用は自作・外注でいくら違う？
自作はライセンス費用中心で月数千円〜数万円ですが、担当者の工数が隠れコストになります。外注は検証目的のPoCで数十万円〜、業務で使う小規模ツールで100〜300万円台、既存システム連携を伴えば300万円〜が目安。初期費用ではなく3年TCO（総保有コスト）で比較してください。
自作・ノーコードのコスト構造（見えている費用と隠れコスト）
見えている費用は、AIのAPI利用料とノーコード基盤のライセンスで月数千円〜数万円程度。隠れコストは、作成・改修・問い合わせ対応に費やされる担当者の工数です。実質的な主要コストは、ほぼ後者になります。
計算例で見ます。担当者が月10時間をこのツールに使うとします。年間120時間。人件費を時給換算3,000円と置けば、年36万円相当。3年で約108万円です。時給換算をいくらに置くかは会社により変わりますが、「無料で自作した」つもりのツールに、実際はこの規模のコストがかかっています。
もう1つ、ユーザー数課金のライセンスは利用拡大時に跳ねます。1人月1,500円のツールでも、50人に広げれば年90万円。全社展開を視野に入れるなら、この試算を先に出しておくべきです。
外注した場合の費用相場（PoC／小規模ツール／連携あり）
目安は、検証目的のPoCで数十万円〜、単機能の業務ツールで100〜300万円台、既存システム連携やユーザー権限管理を伴うと300万円〜。ただしこれは前提条件つきの幅であり、要件次第で上下します。
費用が上下する要因は主に4つです。
- 連携先システムの数（1つ増えるごとに調査・テストの工数が増える）
- 扱うデータの機密性とセキュリティ要件（権限設計・ログ・監査対応の有無）
- 想定利用人数（同時アクセス数、権限パターンの数）
- 求める精度と例外処理の量（例外を潰すほど工数が膨らむ）
システム開発の工数と費用の関係は、規模別の実績値として公開データが整理されています※3。見積書を受け取ったら金額だけを見ず、「どの機能に何人月を積んでいるか」「例外処理をどこまで含むか」を確認してください。曖昧な要件のまま総額だけ提示された見積もりは、後から必ず追加費用が出ます。
また、月額保守が別途かかる点も忘れずに。目安は開発費の10〜15%程度／年に、AIの利用料が加わる形です。
※3 IPA「ソフトウェア開発分析データ集」リンク
3年TCOで比較するとどちらが安いか
自作は初期が安く運用が高く、外注は初期が高く運用が読めます。この構造の違いがすべてです。利用人数が多く、長く使う業務ほど、外注のほうが3年目には逆転して安くなる場面があります。
| 費用項目 | 自作（ノーコード＋生成AI） | 外注（小規模ツール） |
|---|---|---|
| 初期構築 | 0円＋担当者工数（数十時間〜） | 100〜300万円台 |
| 年間ライセンス・AI利用料 | 年10〜50万円（人数課金で変動） | 年10〜50万円 |
| 担当者の運用工数（年） | 年30〜60万円相当 | 年数万円〜（窓口対応のみ） |
| 改修・保守（年） | 担当者依存・見積不能 | 開発費の10〜15%程度 |
| 3年合計の目安 | 150〜350万円相当 | 250〜500万円 |
金額はあくまで条件つきの目安です。ただし比較の型は使えます。効果側も同じ粒度で試算してください。「年間削減時間×時給換算」で年間効果を出し、3年TCOと突き合わせます。投資回収が1〜2年に収まらないなら、その業務は対象として適切でない可能性があります。
AI社内ツール開発の進め方は？失敗しない5ステップ
進め方は、①業務の切り出しと効果試算 → ②自作/外注の判定 → ③1業務・1部署で小さく作る → ④本番化とセキュリティ・運用設計 → ⑤改善と横展開、の順です。最初から全社導入を目指さないこと。各ステップには「次に進んでよい判断条件」を置いてください。
ステップ1〜2：対象業務の選び方と効果試算
対象業務は「頻度が高い×手順が決まっている×間違えても取り返しがつく」の3条件で選びます。効果は月間の削減時間で試算し、月20時間未満なら着手を見送る判断も十分にあり得ます。所要期間の目安は1〜2週間。
洗い出しは、対象部署に1週間だけ作業ログを取ってもらうのが確実です。「時間がかかっている業務」を記憶で挙げてもらうと、印象の強い業務ばかり出てきて頻度の高い雑務が漏れます。集まったら、効果（月間削減時間）×難易度（4条件の該当数）でマトリクスに並べます。
ここで必ず、第1章の4条件判定を通してください。効果が大きくても、機密データや基幹連携に該当するなら自作ルートには乗せません。この分岐を先にやるだけで、後戻りの大半は防げます。ステップ3へ進んでよい条件は、対象業務が1つに絞れていて、自作か外注かの方針が決まっていることです。
ステップ3：小さく作って捨てられる形で試す
まずは1業務・1部署・数名で、2〜4週間で動くものを作り、現場に使ってもらいます。使われなければ捨てる前提にすることで、投資判断のリスクが下がります。この段階で完成度を上げようとしないのがコツ。
プロトタイプで確認するのは3点に絞ります。
- 精度が業務で許容できる水準か（100点でなくてよい。人の確認込みで実用に足るか）
- 現場が実際に使うか（1週間放置して使用ログが残るかで判定）
- 想定した時間削減が実際に出ているか（試算との差を測る）
この3点のうち2つ以上が満たせないなら、本番化せずにいったん止める判断をしてください。特に「現場が使わない」は、ツールの品質ではなく業務設計の問題であることが多く、作り込んでも解決しません。
ステップ4〜5：本番化に必要なセキュリティ・運用設計と改善体制
本番化で必要になるのは、権限設計・ログ・データ取扱いルール・障害時の連絡経路・出力の人によるチェック体制です。ここを詰めずに全社展開すると、自作ツールは高い確率で止まります。所要期間の目安は1〜2か月。
決めるべき運用側の項目をチェックリストにします。
- 障害時の一次対応者（不在時の代理も含めて2名）
- 改修依頼の受付窓口と、対応の優先順位の決め方
- 月次で出力の精度を確認する担当と、確認の方法
- AI出力のレビュー体制（社外に出る文書は誰が最終責任を持つか）
- アクセス権限の棚卸し頻度（退職者・異動者の削除）
- 入力してよいデータ／禁止データの区分の周知
- 廃止基準（何か月使われなければ止めるか）
- ライセンス費用の増加を誰が監視するか
横展開は、同じ業務を持つ別部署から始めるのが安全です。業務が違う部署にそのまま渡すと、ステップ1からやり直しになります。
外注する場合の依頼先の選び方と、渡すべき情報
外注先は「業務のヒアリング力」「AIの精度が出ない場合に代替案を出せるか」「運用・保守まで受けるか」の3点で見てください。AIは要件どおりの精度が出ないことがあり、そのときに設計を組み替えられる相手かどうかが結果を分けます。
逆に、発注側が準備すべきものもあります。ここが揃っていないと見積もりの精度が落ち、後から追加費用が発生します。相見積もりを取る前に、次の情報を用意してください。
- 対象業務の手順（誰が、いつ、何をしているか）
- 実際のデータのサンプル（マスキング済みのもので可）
- 人が行っている判断のルール（例外パターンを含む）
- 想定利用人数と、利用する部署
- 連携したいシステムの名称とバージョン、API公開の有無
- 扱うデータの機密区分（個人情報の有無）
- 希望時期と予算レンジ
- 成功と判断する基準（削減時間、精度の許容ライン）
特に効くのが最後の2つです。予算レンジを伏せると各社の提案の粒度がばらつき、比較できなくなります。成功基準を示さないと、精度についての認識が食い違ったまま契約が進みます。
自作か外注か、判定の途中で迷ったらご相談ください。hikeに相談する
まとめ：AI社内ツールは「自作の範囲」を決めてから動く
AI社内ツールの開発は、作れるかどうかより「どこまでを自作の範囲とするか」を先に決めた側がうまくいきます。要点を5つに整理します。
- 自作/外注は、機密性・利用人数とクリティカル度・既存システム連携・停止時の影響の4条件で決まる（1つでも該当したら外注寄り）
- 生成AI＋ノーコードで作れるのは、部門内・非機密・止まっても手作業に戻せる領域まで
- 自作の失敗3類型（属人化・セキュリティ・業務変更）は、着手前に回避条件を決めれば防げる
- 費用は初期費用ではなく3年TCOで比較し、効果は年間削減時間×時給換算で試算する
- 全社導入から入らず、1業務・1部署で2〜4週間の試作から始める
次のアクションは3段階です。今週やることは、対象部署で1週間の作業ログを取り、候補業務を洗い出すこと。今月やることは、候補業務を第1章の4条件に通し、自作ルートか外注ルートかを判定すること。その先は、自作ルートなら回避条件を決めてから試作、外注ルートなら準備情報を揃えて相見積もりに進みます。判定の途中で「これは自作でいけるのか」と迷う業務が出てきたら、その業務こそ外部の目を入れる価値がある部分です。
よくある質問
ChatGPTだけで社内ツールは作れますか？
個人〜数名で使う文書処理レベルなら作れます。議事録の要約、メールの下書き、テキストの分類などは、プロンプトをテンプレート化するだけで実用になります。一方で、ユーザーごとの権限管理、既存システムとのデータ連携、操作ログの保存は単体では実現できません。複数人で使う「ツール」にする段階で、別の基盤が必要になります。
プログラミングができない担当者でも自作できますか？
ノーコード基盤と生成AIの組み合わせで、部門内の簡易ツールなら作れます。ただし技術的に作れることと、運用し続けられることは別問題です。着手前に、保管場所を会社管理領域にすること、仕様を1ページでも文書化すること、引き継ぎ担当を1名決めることの3点を満たしてください。これができないなら、外注に切り替えたほうが結果的に安く済みます。
社内の機密データをAIに読ませても大丈夫ですか？
法人契約であること、入力データが学習に利用されない設定・契約であること、入力してよいデータ区分が社内で明文化されていること。この3点がそろえば検討できます。1つでも欠けるなら、機密データの入力は避けてください。個人情報を含む場合は、利用目的の範囲や外部提供の扱いについて、個人情報保護法の観点から法務・総務と確認が必要です。
開発期間はどれくらいかかりますか？
目安は、試作（プロトタイプ）で2〜4週間、業務で使う小規模ツールで2〜4か月です。既存システムとの連携や権限設計が入ると、さらに数か月かかります。期間が延びる主因は開発そのものではなく、要件が固まらないこと。対象業務と成功基準を先に決めておくと、期間のブレは小さくなります。
IT導入補助金などは使えますか？
ソフトウェア導入の内容によっては対象になり得ます。ただし対象経費や申請要件は年度ごとに変わり、2026年時点の情報も次年度には通用しません。IT導入補助金は登録済みのITツール・IT導入支援事業者を通じた申請が前提になるなど、細かい条件があります※4。検討する場合は、必ず最新の公募要領で対象要件を確認してください。
作ったツールが使われない場合はどうすればいいですか？
3か月使われなければ廃止する、と先に決めておくのが健全です。使われない原因の多くは、ツールの品質ではなく業務設計にあります。既存の手順に対して追加の操作が増えている、出力の確認に時間がかかる、といった理由が典型です。改修する前に、現場に使わない理由を聞き、業務の手順ごと見直してください。
既存の業務システムにAI機能を追加するのと新規開発、どちらがよいですか？
既存システムの改修が可能かと、既存ベンダーがAI機能に対応できるかで決まります。データが既存システムに集中していて改修が可能なら、追加のほうが早く安く済みます。改修に制約が多い、ベンダーが対応できない、あるいは複数システムのデータを横断したいなら、外側に別ツールを作って連携する形が現実的です。判断材料として、既存ベンダーに改修の可否と概算を先に確認してください。
※4 独立行政法人中小企業基盤整備機構「IT導入補助金」リンク