1. 予算の下限という問題

従来型のSI開発は、数千万円の予算と数ヶ月の期間、それに大きなチームが前提でした。

よくある誤解ですが、アジャイルにすればスピードが出て安くなる、というわけでもありません。スプリントチームを組んで回すには、どうしても最低限のコストがかかります。着手できる案件の予算に下限がある、という問題は、開発のやり方を変えても残ったままです。

社内に10人しかユーザーのいない業務ツール、たとえば端末払い出しの担当者だけが使う申請ツールは、採算が合わないという理由だけで放置されてきました。

このコスト構造は、アジャイルでは解けません。そして手つかずのまま残ったこの領域に、自社を変える余地があります。

2. バイブコーディングで変わったこと

ここ1〜2年で、状況は大きく変わりました。

「こんな画面が欲しい」と日本語で伝えるだけで、AIがコードを書いて、動くアプリの形にしてくれる。いわゆるバイブコーディングです。エンジニアでなくても、思いついたその日にプロトタイプが手元で動く。議事録の要約やExcelマクロの生成をAIに任せている、という話も、もう珍しくありません。

アプリを作れること自体は、もう差別化になりません。問題は、作れるようになった先です。

3. 個人と組織で違う、AIの効き方

調査結果を読むと、少しねじれています。

METRが2025年に行った調査では、経験あるOSS開発者にAIツールを使ってもらったところ、本人たちは20%速くなったと感じていたのに、実測では一人ひとりの作業時間が19%長くなっていたそうです。

なぜ遅くなったのか。METRの要因分析によると、対象は平均で開発10年・100万行規模の成熟したリポジトリで、AIはそこに積み重なった暗黙のルールや書き方の慣習を知りません。生成コードのうち開発者がそのまま受け入れたのは半分以下で、残りの手直しに時間を食われたようです。個人の腕が落ちたのではなく、組織に積もった暗黙知がボトルネックになって、AIの効果を打ち消していたと読めます。

DORA 2025レポートも、AI導入の成否はツール単体では決まらず、組織の開発プロセスや文化に左右されると指摘しています。

個人で完結する仕事に問題はありません。汎用AIやバイブコーディングで足りています。

詰まっているのは組織業務のほうです。繰り返し使う、社内システムとつながる、担当者のノウハウが要る、複数人で同じものを使い続ける。こういう条件が付いた途端に難しくなります。

裏を返せば、ここが変えられる余地の大きい場所です。属人化や社内連携が絡むぶん、外部の専門家と組む価値も残っています。

4. パッケージ、クラウド、個人特化

ソフトウェアの提供形態は、大きく3段で動いてきました。

買い切りで全員が同じものを使うパッケージ。共有のソフトを設定でカスタマイズして使うクラウドやSaaS。そして次に来るのが個人特化だと、私たちは見ています。

個人特化といっても、BtoCの消費者向けアプリの話ではありません。組織の中の、特定業務×特定担当者のためだけのソフトウェアを指します。さきほどの端末払い出し申請ツールが、まさにこれです。

図1：ソフトウェア提供形態の3段階遷移

個人特化は、いまのところ私たちの仮説です。そう見る根拠は、開発コストの低下です。

楽天はClaude Codeを活用して、新機能リリースのリードタイムを24営業日から5営業日へ、79%削減した事例を公表しています。開発コストが2桁下がれば、どの規模から作る価値があるかという採算ラインも、そのぶん下がります。

これまで割に合わなかった、特定業務だけのための小さなソフト。それがようやく採算に乗ります。

5. 捨てて作り直せる価格

開発コストが下がると、もう一つ変わることがあります。直すより作り直すほうが安い場面が出てくる。

数千万円のシステムは、5年10年使う前提でなければペイしません。だから幅広いユーザーをカバーしようとして、結局は誰のためのものか分からないものになりがちでした。

1アプリ数十万円なら、担当者10人のためだけに作っても成立します。業務が変われば捨てて作り直せる金額です。

ソフトウェアが長期資産から消耗品になる。だめなら捨てればいい、と言える値段だからこそ、個人特化は成り立ちます。

6. 私たちが作ったもの

では個人特化をどう実現するのか。私たちは社内施策として「AIアプリ生成マーケットプレイス」と銘打った仕組みを開発し、社内向けに展開しています。

名前にマーケットプレイスと付いていますが、既製アプリが並ぶストアではありません。「こういう業務のこういうアプリが欲しい」という要望をうかがってから、その場で作ります。一つのアプリは数分でできあがります。様々なアプリが数分間隔で次々にできあがるので、あたかもアプリがずらりと並んでいるように見える。それでマーケットプレイスです。既製服の店ではなく、採寸してから仕立てる店に近いと思ってください。

なぜ作ったのか

バイブコーディングのツールはもうあるのに、なぜ別のものを作るのか。実際にお客様の現場へ持ち込もうとすると、2つの壁がありました。

一つは、指示の巧拙で結果が大きく変わること。業務担当者が「申請フォームを作って」とだけ伝えても、期待したものはまず出てきません。何をどこまで伝えるかが、使う人の経験に委ねられてしまいます。

もう一つは、業務データの置き場所です。汎用のツールの多くはクラウド上でアプリを動かします。どのサーバーに何が残るのか分からない状態では、そもそも導入の議論に乗りません。

どう解いたか

使う人は、欲しいアプリを日本語で説明するだけ。AIが必要な情報を数ターン聞き返してきて、要件を一緒に固めていきます。仕様書は要りません。AIの側から質問する形にしたのがポイントで、指示がうまくなくても必要な項目が埋まります。

要件が固まると、その場で動くWebアプリができて、ブラウザでそのまま試せます。

入口は2系統あります。申請フォームなどのひな形から近いものを選ぶ方式と、要件をゼロから対話で組み立てるフル生成です。ひな形は対話の出発点にすぎません。まっさらな状態から書くより結果が安定します。

たとえば端末払い出し申請ツールなら、申請フォームのひな形を選んで、「端末種別と利用期間、申請理由を入力できるようにしたい」と伝えるだけです。数分後には、その業務専用のフォームが動き始めます。

データの置き場所は、生成したアプリ一式をローカルサーバーの実行ファイルと一緒にZIPでお渡しする形にしました。同梱の起動用ファイルを実行すれば、手元のPCでアプリが立ち上がり、ブラウザから使えます。AIとやり取りするのは要件の説明だけで、業務データは手元から出ていきません。私たちがクラウドにサーバーを構え続ける必要もないので、運用コストもかかりません。

図2：アプリが生まれるまでの流れ

できること、できないこと

得意なのは、入力や記録、集計といった、形の決まった業務の小さなアプリです。申請フォームや台帳、チェックリスト、簡単な集計画面。担当者が数人から十数人で使う規模が対象になります。

何でも作れる汎用パッケージではありません。基幹システムとの本格的な連携、大量データの処理、拠点をまたいだ同時利用、細かな権限管理や監査ログ。このあたりは扱えません。従来どおりのシステム開発が必要な領域です。

この取り組みは、いまも社内で開発を続けている段階です。個人特化という仮説の概念実証を、実際の業務でやっている最中だと思ってください。

7. 始めやすさと、その先の難しさ

お客様の側から見ると、この仕組みは最初の一歩を軽くします。

数千万円の開発には踏み切れなかった業務でも、まずは数十万円の専用アプリで、目の前の困りごとから片づけられる。小さく始めて、手応えを確かめてから次に進めます。

軽くなるのは、その最初の一歩だけです。

専用アプリが現場に定着し、組織に浸透していく段階になると、お客様は次の課題にぶつかります。社員認証との連携、権限の設計、社内システムとのデータ連携、アクセスログの保全、バックアップと障害時の復旧、業務が変わったときの改修。とくにセキュリティの統制は、作る技術とはまったく別の専門知識が要ります。

作るハードルが下がったぶん、安全に運用し続けることの価値は上がっています。ここは私たちのようなSIerが伴走する領域です。試しに作る段階はお客様が自分で進め、業務の根幹に組み込む段階は専門家が引き受ける。この分担が現実的だと考えています。

図3：小さく始めて、定着した業務から広げる

こうした「専用ソフトがあれば」という思いは、日々の業務の中にあります。「これくらいのこと、誰かやってくれないかな」と諦められてきた、身近な作業です。汎用AIでは社内の繰り返し業務まで届かない。それは現場の皆さんが誰よりもよく知っているはずです。

8. おわりに

お伝えしたいことは4つです。

小さく作って、使いながら直していく。アジャイルが目指してきたこの回し方が、予算の壁で届かなかった一番小さな業務にも、AIでようやく届くようになりました。

これが、AI時代に変わりつつある企業とソフトウェアの付き合い方だと考えています。

その一歩をもっと軽くし、その先を安心して任せていただけるよう、私たちもこの仕組みを育てていきます。

注釈