お問い合わせ
お問い合わせ 03-5835-2820(平日 9:00〜18:00)
BLOG

AIで非エンジニアの会社はどこまでシステム開発できるか──自転車は作れる。問題は自動車からだ

目次
  1. バイブコーディングとは──「雰囲気で作る」が現実になった
  2. 境界線は4段階で上がっていく
  3. Lv1:個人の業務スクリプト──今すぐやるべき
  4. Lv2:チーム・組織で共有する──最初の壁
  5. Lv3:サーバー・データベース・インフラ──「作る」から「運用する」へ
  6. Lv4:インターネットに公開する──桁違いの世界
  7. 本当の壁は「作ること」ではなく「トラブルが起きたとき」
  8. プロが安心してAIに任せられるのは、安全網があるから
  9. アクシアはどこまでAIでやっているか
  10. では、どうすればいいか──3つの現実解
  11. ①Lv1は全社員がやればいい
  12. ②Lv2以上を内製するなら、「守り」をセットで整える
  13. ③「全部内製」でも「全部外注」でもない、混成チームという選択肢
  14. まとめ──自転車は今日から。自動車は整備士と

「ChatGPTやClaudeでここまでできるなら、もう開発会社に頼まなくてもいいのでは?」——生成AIを日常的に使っている経営者なら、一度は考えたことがあるはずです。システム開発会社であるアクシアが、この問いにポジショントーク抜きで正直に答えます。結論から言うと、作れる範囲は本当に激増しました。個人で使う業務スクリプトなら、非エンジニアでも今日から作れますし、作るべきです。ただし、その先には3つのはっきりした壁があります。この記事では、その境界線を実務の視点から引きます。

バイブコーディングとは──「雰囲気で作る」が現実になった

2025年頃から「バイブコーディング(Vibe Coding)」という言葉が広まりました。コードを自分で書くのではなく、AIに「こういうものが欲しい」と日本語で伝えて、出てきたものを試しながら完成させていく開発スタイルのことです。プログラミングの文法を知らなくても、AIとの対話だけで動くものが作れてしまう。これが誇張ではなく現実になったのが今です。

実際、開業医の方が院内の業務ツールを何十個も自作した事例が話題になるなど、「非エンジニアがAIで作る」流れは確実に広がっています。私たちも開発のプロとして断言しますが、この流れ自体は本物です。「素人が作ったものなんて」と笑う段階はとっくに終わっています。

では、開発会社はもう不要なのか。そうは言い切れない理由が、「作れること」と「使い続けられること」の間にあります。

境界線は4段階で上がっていく

「AIで開発できるか」という問いは、実は粒度が粗すぎます。何を・誰のために・どこで動かすのかによって、難易度はまるで別物になるからです。アクシアの整理では、ハードルは次の4段階で上がっていきます。

AIによるシステム開発の難易度4段階 Lv1 個人の業務スクリプト 自分のPCで、自分だけが使う → 非エンジニアでも今すぐ可能 Lv2 チーム・組織で共有する 他人が使う・引き継ぐ必要が出る → ハードルは一気に上がる Lv3 サーバー・DB・インフラ構築 「動かし続ける環境」の管理が必要 → さらに高くなる Lv4 インターネットに公開する セキュリティの考慮点が桁違いに増える → 個人情報を扱うなら要注意
AIによるシステム開発の難易度は4段階で上がる

Lv1:個人の業務スクリプト──今すぐやるべき

Excelの集計を自動化する、ファイルを一括リネームする、定型メールの下書きを作る。自分のPCで自分だけが使うプログラムなら、非エンジニアがAIで作ることは現時点で十分に可能です。失敗しても困るのは自分だけで、やり直せばいい。ここをためらう理由はありません。開発会社として言いますが、この領域はどんどんやるべきです。

Lv2:チーム・組織で共有する──最初の壁

ところが「便利だから部署でも使おう」となった瞬間、話が変わります。他人が使うということは、自分が想定しなかった使い方をされるということです。エラーが出たら誰が直すのか。作った本人が異動・退職したらどうなるのか。属人化の問題は、人が書いたコードでもAIが書いたコードでも同じように起こります。むしろ「作った本人もコードの中身を説明できない」というAI時代ならではの属人化は、従来より深刻かもしれません。

Lv3:サーバー・データベース・インフラ──「作る」から「運用する」へ

共有のためにWebアプリ化しよう、データを蓄積するためにデータベースを持とう——ここでハードルはもう一段上がります。サーバーは構築して終わりではなく、動かし続けるものです。バックアップは取れているか。障害が起きたら誰が気づき、誰が復旧するのか。「作る」フェーズの知識と「運用する」フェーズの知識は別物で、AIが手伝ってくれるとしても、何を聞けばいいかが分からない状態では、AIの答えを検証することもできません。

Lv4:インターネットに公開する──桁違いの世界

社外からアクセスできるシステム、顧客が使うシステムになると、セキュリティの考慮点は桁違いに増えます。世界中から攻撃され得る前提で作る必要があり、そして個人情報を扱うなら、漏洩は「気づかぬうちに大問題」になり得ます。問題が起きてから知るのでは遅い領域です。

例えるなら、Lv1は自転車です。自分で買って、自分でメンテナンスして乗ればいい。しかしLv3〜4は自動車です。車検があり、整備士による定期的なメンテナンスが前提の乗り物です。DIYで棚を作るのは素敵な週末ですが、家を建てるとなったら「DIYの延長でいいのか?」は立ち止まって考えた方がいい——それと同じ構造です。

本当の壁は「作ること」ではなく「トラブルが起きたとき」

ここまで読んで、「でも作れてしまえばこっちのものでは?」と思った方もいるかもしれません。実務をやっている立場から、いちばん伝えたいのはここです。作ることよりも、障害を含めたトラブル発生時の対応の方が、はるかに難しい。

システムは必ずいつか止まります。そのとき必要なのは「何が起きているかを切り分け、影響範囲を判断し、安全に復旧する」という対応力で、これは知識とノウハウの積み重ねそのものです。順調なときはAIの補助で走れても、異常時の対応を知識ゼロの状態でこなすのは、率直に言っておそらく無理です。

プロが安心してAIに任せられるのは、安全網があるから

もうひとつ、見落とされがちな話をします。プロのエンジニアがAIに大胆にコードを書かせられるのは、腕に自信があるからだけではありません。Gitというバージョン管理の安全網があるからです。AIが誤った修正をしても、消してはいけないファイルを消してしまっても、履歴からすぐに復元できる。だからこそ思い切って任せられます。

ところが非エンジニアにとっては、このGit自体がもうひとつの学習ハードルです。しかも扱いを誤ると、今度はGit自体がセキュリティホールになります。ソースコードに書き込んだ認証情報ごとリポジトリを公開してしまい、そこから情報漏洩に至る事故は、IT企業ですら繰り返し起こしてきた類型です。安全網のはずの道具が、使い方次第で新しい落とし穴になる。この二重構造が、Lv2以降の難しさの正体です。

アクシアはどこまでAIでやっているか

他社のことばかり言うのはフェアではないので、自分たちの話をします。アクシアは開発業務のフロー全体——見積もり段階のソース解析から、設計、実装、テスト、リリース、保守まで——のあらゆる場面でAIをフル活用しています。社内の業務ツールも日常的にAIで作っています。

その中で外部に公開できるものを2つ挙げると、ひとつはこのコーポレートサイト自体をAIエージェント(Claude Code)と一緒にWordPressから作り直した全記録。もうひとつはフォームバリデーションの網羅ガイド(全34記事+検査ツール)をAIとの協働で構築した実例です。どちらも「AIでここまでできる」の証拠として公開していますが、正直に言えばこれは氷山の一角で、日々の開発の現場ではもっと泥臭く、もっと広範囲にAIを使っています。

ただし、ここに大事な種明かしがあります。私たちがAIをフル活用できているのは、Git・コードレビュー・検証環境・本番運用の手順といった「受け止める側の土台」が先にあるからです。AIは能力を増幅する道具です。増幅する元があるほど大きく増幅される——これが、同じAIを使ってもプロと非エンジニアで到達点が変わってしまう理由です。詳しくはアクシアのAIに対する考え方にもまとめています。

では、どうすればいいか──3つの現実解

①Lv1は全社員がやればいい

個人の業務効率化スクリプトは、ためらわずどんどん作るべきです。ChatGPT・Claude・Geminiのようなチャット型AIで十分始められますし、もう一歩進むならClaude Codeのようなエージェント型のツールもあります。ここで得られる「AIに何をどう頼むと、どんなものが返ってくるか」の肌感覚は、この後の判断すべての土台になります。

②Lv2以上を内製するなら、「守り」をセットで整える

チームで共有するツールを内製するなら、作る前に最低限の「守り」を決めておくことをおすすめします。バージョン管理(=壊しても戻れる状態)、データのバックアップ、誰がメンテナンス担当か、認証情報をコードに直書きしないこと。逆に言えば、この「守り」を用意できないうちは、そのツールに会社の重要な業務や顧客の個人情報を乗せない——これが、気づかぬうちに大問題を起こさないための実務的な線引きです。さらに本格的に、開発チームを持つレベルの内製化を検討するならシステム開発の内製化に必要な4つの条件も参考にしてください。

③「全部内製」でも「全部外注」でもない、混成チームという選択肢

そして、内製か外注かの二択で考える必要はそもそもありません。AIを使える社内メンバーが手を動かし、設計・セキュリティ・本番運用といった要所だけプロのエンジニアが面倒を見る——そういうプロジェクトチームの組み方は、AI時代の現実解になり得ると私たちは考えています。全部を外注するより速くて安く、全部を内製するより安全です。アクシアでも、こうした形のご相談は歓迎します。

まとめ──自転車は今日から。自動車は整備士と

「AIで非エンジニアの会社がシステム開発できるか」への、アクシアの正直な答えをまとめます。

  • 個人の業務スクリプト(Lv1)は、今すぐできるし、やるべき。開発会社が止める話ではありません
  • チーム共有(Lv2)から先は、「作れるか」ではなく「運用できるか」「トラブル時に対応できるか」で判断する。属人化・バージョン管理・バックアップが最初の壁です
  • インフラ構築(Lv3)・ネット公開(Lv4)、特に個人情報を扱う領域は、プロの関与を前提に。ここは自動車の世界です
  • 内製と外注の二択ではなく、社内メンバー+プロの混成チームという組み方も検討の価値があります

AIで作りかけたシステムをどうするか迷っている、社内ツールを本格的なシステムに育てたい、内製と外注の切り分けを相談したい——そんな段階のご相談も歓迎です。ちなみに、開発が途中で止まったシステムの引き継ぎ・立て直しについてはシステム引き継ぎの進め方でも解説しています。

「うちの場合はどこまでできるか」を一緒に整理するところからでも、お気軽にご相談ください。相談はこちら>>

AIを使った開発、アクシアが形にします。

生成AI・AIエージェントの業務実装を、要件定義から自社一貫で開発します。

AI開発を相談するシステム開発について詳しく見る

ブログ一覧へ戻る

AIを使った開発、アクシアが形にします。

生成AI・AIエージェントの業務実装を、要件定義から自社一貫で開発します。