「非エンジニアでもAIで自社システムを作れる」の落とし穴──結局kintoneやExcelの方が良い？

「AIのエージェント機能を使えば、非エンジニアでも独自のWEBシステムが作れる」――最近、こうした話をよく見かけるようになりました。そして実際、ある程度のものは（しっかりとしたAIエージェント環境を構築すれば）作れます。そこは、わざわざ議論するまでもありません。

ただ、私が現場で経営者の方々と接していて感じるのは、世の中の話題が「作れる／作れない」の一点に偏りすぎている、ということです。本当に大切なのは、その手前にある「何を作ってよくて、何には手を出すべきでないか」という「線引き」のはずです。

この記事では、まずAIエージェントとは何かを正しく整理した上で、自作してよい業務とそうでない業務を分ける基準を、できるだけ率直にお話しします。「作れる時代」だからこそ、その見極めが効いてきます。

そもそも「AIエージェント」とは何か──「チャット」と何が違うのか

議論の前に、言葉の中身をそろえておきましょう。ここが曖昧なまま「作れる・作れない」を語っても、話が噛み合いません。

多くの方が日常的に触れているのは、AIの「チャット機能」です。これは、こちらが問いを投げると、それに答えてくれるもの。文章を書いてもらう、資料の下書きをつくってもらう、情報を整理してもらう――いわば「優秀な相談相手」です。

一方の「エージェント機能」は、性質が一段違います。ざっくり言えば、「ゴール（目的）を渡すと、AIが自分で手順を考え、必要なツールを操作しながら、実行まで進めてくれる」もの。「答えを返す」のがチャットなら、「手を動かして作業を進める」のがエージェントです。この「自律的にタスクを遂行する」という点が、エージェントの本質です。

たとえば「このフォルダの請求書データを読み取って、会計ソフトに登録しておいて」と頼むと、読み取り・判断・入力までを一連の流れで進めようとする。これがエージェント的な動きです。「AIに業務そのものを手伝ってもらう」段階に入った、と捉えるとイメージしやすいかもしれません。

「非エンジニアでも作れる」のは、もう「そういうもの」という前提で

はじめに、はっきりさせておきます。見栄えや機能が一定水準のものなら、IT分野に詳しくない非エンジニアの方でも、いまやAIを活用すれば作れます。これは議論の余地のある話ではなく、すでにそういう時代ですので、ここを起点に話を始めます。

実際、ボタンが並び、データを入力でき、一覧で表示される――そういう「動くもの」は、専門知識がなくてもエージェントに手伝ってもらいながら形にできます。数年前なら専門のITベンダーの力を借りないとほぼ不可能だったことを思えば、確かに大きな変化です。

ですが、私が問題にしたいのは、そこではありません。「作れるかどうか」で立ち止まっている限り、肝心の論点には一生たどり着けないからです。本当に考えるべきことは、作れることを前提にした、その先にあります。本題はここからです。

「作れる」と「使い続けられる」は、別の話──見えていない3つの領域

システムは、作った瞬間がゴールではありません。むしろ、そこからが本番です。毎日の業務で使われ、人が入れ替わっても回り、トラブルが起きても復旧でき、何年も使い続けられて――初めて「業務システム」と呼べます。

ここで、先に一つ、フェアな前提を置いておきます。最近のAIは、かなり賢い。たとえばClaude CodeのようなAIエージェントに、業務システム開発支援をしてもらう形で「GitHub」「Vercel」「Supabase」といった各種専門ツールを組み合わせて業務システムを作らせると、こちらが何も言わなくても、AIの側から「ここは認証を入れましょう」「このキーは公開しないように管理しましょう」「アクセス制御を有効にしましょう」と提案してきます。つまり、これから挙げる「見えていない3つの領域」を、AIがある程度カバーしてくれる可能性は、確かにあります。

では、それで安心かというと――ここがこの記事で一番お伝えしたいところなのですが、話はそう単純ではありません。問題は、AIが出してくる提案は「一般的に正しい型」であって、「あなたの会社にとっての正解」ではないということ。そして、その提案を受け取る側に判断力がないと、「考慮済みに見えるだけの空箱」が出来上がってしまうことです。賢いAIほど、この“分かったつもり”のリスクは、むしろ上がります。3つの領域それぞれで、何が起きるのかを見ていきましょう。

① 【ユーザ認証】ログインは作れる。でも「誰に何を許すか」は別

「ログイン機能をつけて」と頼めば、AIはすぐに認証の仕組みを組み込んでくれます。Supabaseの認証機能を使えば、メールアドレスとパスワードでログインできる画面まで、あっという間に出来上がる。ここまでは本当に簡単です。

問題はその先です。「営業担当は”自分の顧客だけ”、経理は”全件”、パートの方々は”閲覧”のみ」といった、事業者さま固有の権限設計は、こちらが要件として与えない限り、AIからは出てきません。AIは「一般的なログイン」は作れても、「あなたの会社で、誰に、どこまで見せてよいのか」は知らないからです。

ところが（慣れていない）非エンジニアの方は、「ログインできました」という画面を見て、「認証はOK」と受け取ってしまう。実際には、全員が全データを見られる状態のまま、入口に鍵がついただけ――ということが起こります。これは、認証が「ある」ことと、自社にとって「正しく」設計されていることが、まったく別だという典型例です。

② 【情報セキュリティ】提案は出る。でも「判断」出来る？

セキュリティについても、賢いAIは黙っていません。「このデータにはアクセス制御（行単位の権限設定）をかけましょう」「APIキーはコードに直接書かず、環境変数で管理しましょう」――こうした、教科書的に正しい提案を、自分から出してくれます。ここだけ見れば、むしろ頼もしい。

落とし穴は、その提案に対して「やる／やらない」を判断する基準が、受け手にないことです。AIが「アクセス制御を有効にしますか？」と聞いてきても、非エンジニアの方にはYesともNoとも判断できない。結局「AIがそう言うなら」で進めることになります。これは、提案を受けて意思決定しているように見えて、実態は「丸投げ」です。

そして本当に怖いのは、AIが提案しなかった穴には、誰も気づけないことです。見た目はきちんと動き、毎日問題なく使えている。それでも裏側で、本来見えてはいけないデータが外部から覗ける状態になっていることがある。提案された対策に「はい」と答えただけで「対策済」の気分になり、提案されなかった領域がまるごと抜け落ちる――この状態が、一番危ういのです。

③【 保守・属人化】そもそも、AIからは提案されない領域

①や②は、まだいいのです。賢いAIなら、不完全とはいえ提案を出してくれる。ところが、この③は性質が違います。「作った本人がいなくなった後、誰がこのシステムを直すのか」「半年後にツールの仕様が変わったら、どう追従するのか」――こうした「時間軸」や「組織」の問いは、目の前のコードを書いているAIからは、原理的に出てきません。

AIは「いま動くもの」は驚くほど上手に作ります。しかし、「2年後も、担当者が代わっても、会社で回り続ける体制」までは設計してくれない。それは、目の前の作業ではなく、経営を見ている人間の領域だからです。自作したシステムが、作った本人にしか中身の分からないブラックボックスになると、その人が抜けた瞬間、便利だった仕組みが一転して会社の弱点に変わります。これが、典型的な属人化のリスクです。

「トラブルが起きても、AIに聞けばなんとかなる」とおっしゃる方もいます。気持ちは分かりますが、AIは魔法ではありません。基本的な知識がない状態では、そもそも「AIへの聞き方」自体が成り立たず、解決にたどり着けないことが多いのです。正しい問いを立てるにも、相応の前提知識が要る。賢いAIに提案させること自体が、実は“それを評価できる人間”を前提にしている――ここは、多くの方が見落とすところです。

だから「何を作ってよく、何を作るべきでないか」──線引きの基準

ここまでを踏まえると、問いは「作れるか／作れないか」ではなく、「これは自作してよい業務か、そうでない業務か」に変わります。

そして私は、この線引きを考えるときに、もう一段手前の問いも必ずセットにしています。「そもそも、これは自分で作る価値があるのか？」という問いです。というのも、非エンジニアでも作れる程度のことは、裏を返せば、ソフトのベンダー側でもいずれ実装してくる、ということでもあるからです。少し待てば、提供元が安全で使いやすい形で標準機能として用意してくれる――そういう領域に、わざわざ時間をかけて自作で挑んでも、先行できるのはわずかな期間にとどまり、その間ずっと保守の手間を自分で背負い続けることになります。

この視点に立つと、自作に向く業務の正体が、はっきりと見えてきます。それは、「世の中に、ぴったり合う製品が存在しない、自社ならではの業務」です。

勤怠管理、在庫管理、顧客管理――こうした「どの会社にも共通する汎用的な業務」は、すでに優れた既製サービスがいくらでもあります。ここを自作するのは、車輪の再発明であり、わざわざ①②③のリスクだけを自分で抱え込むようなもの。割に合いません。

一方で、その会社だけの独特な商習慣、独自の見積ロジック、業界特有のニッチな管理項目――こうした「自社固有・特殊な業務」は、世の中を探してもぴったりの製品が見つからない。だからこそ、自分で作る価値が生まれます。「固有であること」は、数少ない“自作を正当化する理由”なのです。

自作を検討してよい寄りのもの

ただし、「固有だから何でも作ってよい」わけではありません。「自社ならではの業務か（＝作る理由があるか）」と「影響範囲が小さいか（＝作ってよい条件を満たすか）」の、二段で見るのがポイントです。

• 既製品にぴったりのものがない、自社固有・特殊な業務（そもそも、ここにしか自作の理由はありません）
• その上で、他の業務システムと連携しない、独立した業務であること
• 関わる人が少なく、仮にうまくいかなくても影響範囲が小さいこと
• 比較的シンプルで、仕組みの全体像を本人が把握しきれる規模であること

面白いもので、「自社固有の特殊業務」は、たいてい関わる人が限られ、扱う範囲も限定的です。つまり「固有であること」自体が、自然と「①②③のリスクが小さい領域」に収まりやすい。作る理由がある業務ほど、安全に作りやすい――この重なりが、自作の“ちょうどよい範囲”なのです。

手を出すべきでない寄りのもの

• どの会社にもある汎用的な業務（既製サービスがあり、そもそも自作する理由が薄い）
• 会社の根幹に関わる基幹的な業務（止まると業務が止まるもの）
• 多くの従業員が日常的に使うもの（認証・権限が複雑になる）
• 他システムとのデータ連携を伴うもの（一体感を保つ難易度が跳ね上がる）
• 顧客情報など機微なデータを扱うもの（セキュリティの重みが増す）

当事業所の整理でも、「独自WEBシステムの構築」は、難易度が決して低くなく、属人化もしやすく、構築には中期（おおむね1〜3ヶ月）を要する領域に位置づけています。「世にぴったりの製品がなく、かつ影響範囲が限られた、自社ならではの業務」であれば、思い切ってAIベースで進める価値は十分にあります。一方で、汎用的な業務や、会社全体を支える基幹部分まで安易に自作で賄おうとすると、先ほどの“3つの見えない領域”が一気に重くのしかかってきます。

結局、kintoneやExcelの方が良かった──という結末も多い

さて、ここまでで「自作してよい業務」を、固有性と影響範囲という二段でかなり絞り込みました。ところが、話はもう一段あります。仮にその関門をくぐり抜けて、「これは自作向きだ」というテーマが見つかったとしても――です。

そこでもう一度、立ち止まってほしいのです。「それ、AIでゼロから作るより、kintoneやGoogle Workspace、なんならExcelで組んだ方が、むしろ良いのではないか？」と。そして私の実感では、突き詰めて考えるほど、この問いに「いや、やっぱり既存ツールの方が良かった」と行き着くケースが、かなり多いのです。

理由は、これまで挙げてきた①②③と、きれいに裏返しの関係になっています。

• 認証・権限（①）が、最初から備わっている。kintoneやGoogle Workspaceなら、「誰がログインでき、誰が何を見られるか」をプラットフォーム側が標準で持っています。自作で頭を悩ませた“空箱”問題が、そもそも起きにくい。
• セキュリティ（②）を、プラットフォームに任せられる。大手が提供する基盤に乗ることで、自分でゼロから守りを設計しなくて済みます。「気づかないうちに空いた穴」のリスクが、大きく下がります。
• 属人化（③）を防ぎやすい土俵に立てる。kintoneやスプレッドシートは、業務とITを理解したしっかりした人材が「シンプルかつ高品質」に作り込めば、属人化させづらいツールです。

おまけに、たいていの場合、開発そのものも速い。AIエージェントにゼロから一式組ませるより、kintoneでアプリを一つ作る方が、はるかに早く形になることは珍しくありません。シンプルに・速く・安全に・引き継げる形で——きちんと作り込めば、自作がわざわざ勝たなければならない理由は、どんどん痩せていきます。

もちろん、それでも「既存ツールでは、この複雑な要件はどうしても表現しきれない」という業務は残ります。そういう、本当に最後まで絞り込まれたものについては、AIエージェントによる自作が最適解になる。ただ、それは想像よりずっと狭い範囲だ、というのが正直なところです。

少し皮肉な言い方になりますが、「非エンジニアでも作れる時代」の最も賢い使い方は、「作れる。でも、あえて作らない」という判断ができることなのかもしれません。作れるようになったからこそ、「作らない」を選べる目が、これまで以上に大切になっています。

つまり、AIエージェントによる自作は「やってはいけない」ものでも「何でもやってよい」ものでもありません。業務の性質を見極め、既存ツールと比べた上で、向き不向きを判断する。それだけのことなのですが、この見極めこそが、いちばん難しく、いちばん大事なところなのです。

当事業所のスタンス──「表面的な開発」はしない

当事業所では、表面的に「AIで独自WEBシステムを作りましょう」とは言いません。動くものを作って“納品して終わり”では、先ほど挙げたリスクをそっくりお客さまに残すことになるからです。

私たちがやるのは、まず「この業務は自作に向くのか、向かないのか」を一緒に見極めるところから。その際、「AIでゼロから作る」という選択肢を、kintone・Google Workspace・Excelといった既存ツールと同じ土俵に並べて、本当に自作が最適なのかをフラットに比べます。そして、自作が妥当だと判断したものについては、「シンプルな構造で作る」「その構造を事業者さま自身に理解してもらう」「自社でPDCAを回せる体制まで整える」ところまでをセットで支援します。作って渡すだけでなく、後から事業者さま側で面倒を見られる状態にして初めて、支援が完結すると考えています。

そして大前提として、その土台となる基礎環境（データの蓄積体制やフォルダの整理など）が整っていない事業者さまに、この「AIでの独自システム構築」をお勧めすることはありません。私がいつも申し上げている「畑を耕してから、AIという農具を入れる」という順番は、ここでも変わりません。耕されていない畑にいきなり高性能な農具を持ち込んでも、十分には機能しないのです。

「非エンジニアでも作れる時代」は、たしかに来ました。それは歓迎すべきことです。だからこそ、浮き足立って何でも自作に走るのではなく、「何を作ってよく、何は作るべきでないか」を冷静に見極める。その判断を、必要なら一緒に考えるパートナーがいる。私は、そういう関わり方を大切にしています。

続きはこちら

今回まとめた、「非エンジニアでもAIで自社システムを作れる」の落とし穴、という話題について、更に深堀りをした記事です。
→「非エンジニアでもAIで自社システムを作れる」の落とし穴②──AIに任せるべきは「完成品」より「試作品」！

さらに深く知りたい方へ

当事業所が、AIとどう向き合い、どんな形でAI環境構築を支援しているかは、こちらのページで詳しくご紹介しています。

「土台づくり」から考えたい方へ

AIや独自システムの前に、まず会社のデータ基盤（フォルダ整理）から整えたいという方は、こちらをご覧ください。