ChatGPT のような生成AIが使えるようになってから、社内の問い合わせ対応や文書作成を「ツールを契約するだけ」で改善できる場面が確実に増えました。一方で、同じ勢いで基幹業務まで任せようとして途中で止まってしまう例も少なくありません。
この記事では、ノーコードのAIツールで十分な業務と、受注開発（スクラッチ開発や既存システムとの連携開発）を検討すべき業務を、どう見分ければよいかを整理します。先に結論を書くと、判断軸は「業務の輪郭がはっきりしているか」と「AIが間違えたときに誰がどれだけ損をするか」の2つです。
前提となる用語を整理する
議論の前に、混同されやすい言葉を揃えておきます。
- ノーコード／ローコードツール：プログラムを書かずに、画面上の操作で業務アプリや処理の流れを組み立てられるツール。kintone、Power Platform、Zapier、Dify などが該当します。
- LLM（大規模言語モデル）：大量の文章を学習し、自然な文章の生成や要約ができるAIモデル。GPT、Claude、Gemini などの中核技術です。
- RAG（検索拡張生成）：社内マニュアルや議事録などを検索し、その内容を根拠としてLLMに回答させる仕組み。モデル自体を学習させ直さずに「自社の知識」を扱えるため、社内問い合わせ対応でよく使われます。
- ハルシネーション：AIが事実でない内容をもっともらしく生成してしまう現象。現時点の技術では、完全にゼロにはできないという前提で設計する必要があります。
見分けるための5つの軸
個別の業務を前にしたとき、次の5項目を順に確認すると判断がぶれにくくなります。
| 軸 | ノーコードで足りる側 | 開発を検討する側 |
|---|---|---|
| 出力の使われ方 | 人が目を通してから使う（下書き・たたき台） | そのまま帳票や外部送信に流れる |
| 間違えたときの影響 | やり直せば済む | 金銭・契約・個人情報に直結する |
| 扱うデータの所在 | ファイルやスプレッドシートで完結 | 基幹システムやDBとの双方向連携が必要 |
| 処理件数・頻度 | 1日数十件程度、人が起動する | 日次バッチや常時処理、件数が多い |
| 業務ルールの複雑さ | 例外が少なく手順が言語化できる | 例外・条件分岐が多く担当者の暗黙知が多い |
5項目のうち右側が3つ以上なら、ノーコードで無理に押し切るより、設計から相談したほうが結果的に早く安く収まることが多い、というのが実務上の目安です。
ノーコードAIで十分なケース
たとえば次のような場面です（以下はいずれも説明のための仮の例です）。
- 営業担当が商談メモを貼り付けると、報告書の下書きと次回アクション案が返ってくる仕組み。出力は必ず本人が確認してから提出する。
- 就業規則や社内マニュアルをRAGで検索し、総務への「よくある質問」に一次回答するチャット。回答末尾に出典のページ名を出し、判断が必要なものは人へ引き継ぐ。
- 問い合わせメールを内容ごとに分類し、担当部署のチャットへ振り分ける。誤分類が起きても、担当者間で転送すれば復旧できる。
共通しているのは、AIの出力と最終的な責任の間に人が入っていること、そして既存システムを書き換えないことです。この条件を満たすなら、ノーコードツールの月額費用と社内の工数で十分に成立します。小さく始めて、効果が出なければ止められる点も利点です。
開発を頼むべきケースと、その理由
一方、次のような要件が出てきたら、設計を伴う開発を前提に考えたほうが安全です。
- 基幹システムとの双方向連携：販売管理や会計システムから読むだけでなく、AIの判定結果を書き戻す場合。更新の失敗時にどう戻すか（トランザクション設計）は、ノーコードの標準機能では担保しきれないことがあります。
- 証跡が必要な業務：誰が、いつ、どのデータを根拠に、どんな出力を得たかを後から追えること。監査や取引先からの説明要求に耐える必要があるなら、ログ設計を最初から仕様に入れるべきです。
- 権限とデータ分離：部門や役職ごとに閲覧できる情報が異なる場合、RAGの検索対象をユーザーごとに絞り込む必要があります。ここを雑に作ると、本来見えないはずの文書が回答に混ざる事故につながります。
- 精度の継続的な改善：運用しながら評価データを蓄積し、プロンプトや検索条件を調整していく体制が要る場合。
なお、個人情報を扱う場合は個人情報保護法、国税関係書類の電子的な保存に関わる場合は電子帳簿保存法の要件が関係します。AI活用全般の考え方については、総務省・経済産業省が公表しているAI事業者ガイドラインが参考になります。いずれも自社の業務にどう当てはまるかは個別判断が必要なため、要件定義の段階で確認しておくことをおすすめします。
実装で詰まりやすい箇所
実際に手を動かす段階でつまずきやすいのは、AIそのものより周辺です。
- 入力データが整っていない：スキャンPDFの表、改行の崩れたメール本文、部署ごとに書式の違うExcel。AIの精度より先に、前処理の工数が効いてきます。
- 「正解」が定義されていない：精度を議論するには、人が作った正解データが要ります。数十件でよいので、着手前に用意しておくと判断が早くなります。
- 従量課金のコスト見積もり：LLMの利用料は処理した文字量（トークン）に応じて増えます。長い文書を毎回丸ごと投げる設計だと、件数が増えた途端に費用が跳ねます。
- モデルの更新・提供終了：利用しているモデルのバージョンが変わると、出力の傾向が変わることがあります。特定モデルに依存しすぎない構成と、切り替え時の再検証手順を決めておくと安心です。
- 運用の引き取り手：作った後に誰がプロンプトを直し、誰が問い合わせを受けるのか。ここが空白のまま本番稼働すると、短期間で使われなくなります。
おすすめの進め方
現実的なのは、いきなり二択にしないことです。まずノーコードツールで小さく試し、業務の輪郭と効果を確かめてから、必要な部分だけ開発に置き換える。この順序なら、要件が固まった状態で見積もりを取れるため、開発側の見積もり精度も上がります。
試作の段階で「例外処理が思ったより多い」「基幹システムに書き戻さないと意味がない」と分かれば、それ自体が開発判断の材料になります。試作は捨てる前提で作ると割り切ったほうが、結果的に早く進みます。
まとめ
ノーコードAIツールと受注開発は、優劣ではなく適用範囲の違いです。判断に迷ったら、次の3点に戻ってください。
- AIの出力と責任の間に人のチェックが入るか
- 間違えたときにやり直しで済むか、それとも金銭・契約・個人情報に波及するか
- 既存システムへの書き戻しや証跡が必要か
前者に当てはまるならノーコードで十分な可能性が高く、後者が含まれるなら設計を伴う開発を検討する段階です。当社では、どちらが適しているかの切り分けからご相談を承っています。「この業務はどちらか判断がつかない」という状態でも、業務の棚卸しからご一緒できますので、お気軽にお問い合わせください。