2026.08.24
AI駆動開発で手軽に作る社内ツール
- AI
- DX
- IT戦略
AI駆動の社内ツール開発 ― 「数日で作って数週間で定着」が現実になった
社内業務ツールの開発は、AI駆動開発で最も静かに、しかし最も劇的に変わった領域です。経費申請の自動化、KPIダッシュボード、ナレッジ検索、申請フォーム、業務一覧。これまで「あったら便利だが、頼んでも数か月待ち、しかも完成した頃には要件が変わっている」というのが社内ツールの宿命でした。受託に出せば数百万円かかり、内製しようにも他案件で手が回りません。多くの企業で、業務担当者がExcelとマクロで凌ぎ続け、シャドーITが横行してきました。
AI駆動開発はこの構造を変えます。v0やBolt、Lovableといったプロトタイピングツールに加え、CursorやClaude Codeで本格的な実装も短時間で成立します。重要なのは速さだけではありません。業務担当者自身が「自分で動くものを作る」体験ができる ことです。本記事では、AI時代の社内ツール開発の実践と、組織にもたらすインパクトを整理します。
要点：社内ツールは「数日で作る→数週間で定着→継続的に改善」が新しいサイクル。受託依存からの脱却と、業務担当者による DX民主化が同時に進みます。
1. 社内ツールとは何か、なぜ難しかったか
社内ツールは、その会社の業務に最適化された小さな業務システムです。経費申請、稟議承認、案件管理、見積書作成、顧客対応の引き継ぎメモ。汎用SaaSでカバーしきれない「うちの会社特有のフロー」を埋める存在で、業務効率に直接効きます。にもかかわらず、これまでは作りにくかったです。理由は3つあります。
第一に、ROIが見えにくいです。1部署のために数百万円かけるのは稟議が通りにくいです。第二に、要件が固まりません。業務担当者は「使いながら改善したい」が、受託契約は変更コストが高いです。第三に、改善コストが高いです。一度作ったら塩漬けになり、業務の進化に追いつきません。結果、Excelとマクロ、属人化したシステムが社内に増殖し、誰もメンテできないブラックボックスが量産されてきました。
AIDDはこの3つの構造的問題を、同時に緩和します。プロト即生成・業務担当者参加・改善高速化が、同じ仕組みの上で成立するからです。
従来 vs AIDD：社内ツール開発の構造比較
| 観点 | 従来の社内ツール | AIDDの社内ツール |
|---|---|---|
| 初版までの期間 | 3〜6か月 | 数日〜数週間 |
| 初期コスト | 300〜1,000万円 | 5〜50万円 |
| 開発主体 | エンジニア・受託会社 | 業務担当者＋AI＋エンジニア伴走 |
| 改善サイクル | 半年〜1年に1回 | 週次で改善 |
| 要件凍結のタイミング | 開発前に確定必須 | 触りながら更新可 |
2. AIDDで社内ツールはどう変わるか
最大の変化は、「動くもの」が出てくるまでの時間 です。従来は、要件定義→画面設計→DB設計→実装→テスト→納品で半年。AIDDは、業務担当者が困りごとを口頭で伝えると、その日のうちにv0で画面が動き、3日後にCursorで本格実装、2週間後に部署内で運用開始、というスピードが出ます。
これは単なる時短ではありません。意思決定の構造が変わります。動くものが先に出てくると、議論の質が上がります。「もしかしたらこういう機能も…」が「実際に触ってみるとこの機能はいらない」に変わります。仕様書の上で議論していた時代は、合意したつもりが現場で使われない、という失敗が多かったです。プロトを触りながら議論すれば、現場で使われないツールは作られなくなります。
もう一つの変化は、業務担当者の参加度 です。プロンプトで指示できる時代になり、業務担当者自身が初版のプロトを作れます。「何を作りたいか」を最も理解している人が、最初の形を作ります。エンジニアは本格化フェーズで合流します。これが社内ツール開発の新しい標準形になりつつあります。
3. 主要ツールと使い分け
社内ツール開発で実務に使われているツールは、用途別に役割が分かれます。一つで全部はやらず、フェーズごとに使い分けるのが効率的です。
ツール選択マトリクス
| ツール | 強み | 弱み | 使うフェーズ |
|---|---|---|---|
| v0 / Bolt / Lovable | UI即生成・非エンジニア可 | 本格運用には不向き | プロト作成 |
| Cursor / Claude Code | 本格実装・既存基盤統合 | 初期セットアップ要 | 本番化フェーズ |
| Retool / Internal | DB連携・ローコード | ベンダーロックイン | エンタープライズ向け |
| Notion + AI / Airtable + AI | 即運用・学習コスト低 | スケール限界 | 軽量ツール |
| kintone / SmartHR的SaaS | 業務テンプレ豊富 | カスタム制約 | 標準業務 |
💡 ポイント：「まずv0でプロト→反応見てCursorで本格化」の2段階が王道。最初からCursorで作り始めると、要件未確定のまま実装が進み、結局作り直しになります。
4. 開発フローの実際
実務でうまくいく開発フローは、以下のような流れになります。各ステップに具体的な時間配分の目安をつけて整理します。
第一に、業務担当者へのヒアリング（30分〜1時間）。困りごとを言語化してもらいます。「経費申請が面倒」のような大きな括りから、「領収書の写真撮ったらOCRで金額入力されてSlackに通知が飛ぶといい」のような具体形まで掘り下げます。AIに対話させながら深掘りするのも有効です。
第二に、プロト即生成（30分〜数時間）。v0などで初版UIを作ります。この時点で業務担当者に見せ、「こういうイメージ？」と確認します。違えば即修正。完成度より、議論のタタキになることが目的です。
第三に、実環境での試用（1〜2週間）。プロトを部署内の少人数で触ってもらいます。フィードバックを蓄積します。要件と現実のズレが、ここで顕在化します。
第四に、本格化判断と実装（1〜4週間）。プロトのままで運用するか、CursorやClaude Codeで本格化するかを判断します。基準は後述します。
第五に、定着・運用（継続）。マニュアル整備・トレーニング・サポート体制を整えます。改善要望は週次で取り込む。
開発フローの時間配分（目安）
| ステップ | 期間 | 主担当 | アウトプット |
|---|---|---|---|
| ヒアリング | 0.5〜1日 | 業務担当者＋AI | 要件メモ |
| プロト即生成 | 0.5〜1日 | 業務担当者 or エンジニア | v0等のURL |
| 実環境試用 | 1〜2週間 | 業務担当者 | フィードバック |
| 本格化判断 | 0.5日 | エンジニア＋CTO | 判断書 |
| 本格化実装 | 1〜4週間 | エンジニア＋AI | 本番システム |
| 定着・運用 | 継続 | 業務担当者＋IT | 運用マニュアル |
5. ガバナンスとシャドーITリスク
社内ツール開発がAIDDで民主化されると、必ず出てくるのがシャドーITの問題です。各部署が勝手にツールを作り、IT部門の管理外で動き、セキュリティリスクや属人化を生みます。これは放置すると深刻な問題になるが、過剰に統制すると民主化のメリットを殺します。バランス設計が必要です。
実務的には、「推奨レーン」と「禁止レーン」を分ける のが効きます。推奨レーンとは、IT部門が認可したツール・プラットフォーム上での開発。v0で作るならVercel、本格化はAWS/GCP、データ保存はSnowflakeかBigQuery、認証はOkta、といった形でガードレールを引きます。このレーン内なら自由に開発してよい、というルールにします。
禁止レーンとは、機密データを扱うのに無料SaaSを使う、認証なしで公開する、本番システムに無監査で接続する、といった行為。ここは明示的にNGとします。境界が明確なら、業務担当者は安心して開発でき、IT部門も統制ができます。
ガバナンス設計の3階層
| 階層 | 内容 | 業務担当者の権限 |
|---|---|---|
| 🟢 自由開発レーン | 認可ツール・限定データ・部署内利用 | 自由に開発・運用可 |
| 🟡 要相談レーン | 全社利用・他部署データ参照 | IT部門と協議 |
| 🔴 禁止レーン | 機密データ・本番システム改変・外部公開 | IT部門・専門家のみ |
⚠️ シャドーIT対策のコツ：「禁止」だけ並べても抜け道が増えます。「推奨レーン」を整備して 業務担当者が自然にレーン内で動く 環境を作るほうが実効性が高いです。
6. プロトのまま運用する判断 vs 本格化する判断
社内ツールでよく悩ましいのが、プロトのまま運用するか、本格化するかの判断です。プロトは速く作れるが、スケール・セキュリティ・保守性に課題があります。本格化はコストがかかるが、長期運用に耐えます。判断軸を整理しておくと、組織として一貫した判断ができます。
プロトのまま運用してよい条件は、ユーザー数が限定的（10人程度まで）、扱うデータの機密度が低い、業務クリティカル度が低い、想定利用期間が3〜6か月以内。これらが揃えばプロトのまま運用してよいです。むしろ本格化するほうが過剰投資になります。
本格化が必要な条件は、全社利用、機密データを扱う、業務クリティカル、長期運用前提。これらのうち2つ以上当てはまれば、本格化を検討すべきです。
プロト運用 vs 本格化の判断マトリクス
| 観点 | プロト運用OK | 本格化必要 |
|---|---|---|
| ユーザー数 | 〜10人 | 50人以上 |
| データ機密度 | 公開可〜社外秘 | 機密含む |
| 業務クリティカル度 | 低（停止しても業務継続可） | 高（停止＝業務停止） |
| 想定運用期間 | 〜6か月 | 1年以上 |
| 監査対応 | 不要 | 必要 |
| 改修頻度 | 月1回以下 | 週次 |
7. 業務担当者参加の効果と限界
社内ツール開発に業務担当者が直接参加することの最大の価値は、要件齟齬の劇的な削減 です。従来の開発で起きていた「言ったのにできていない」「できあがったが使えない」の多くは、要件のすり合わせ不足が原因でした。業務担当者自身がプロトを触り、自分で初版を作れば、この齟齬は構造的に消えます。
副次的な効果として、継続改善のスピード が上がります。「ここをこうしたい」と思った瞬間に自分で修正できるなら、改善サイクルは日次・週次になります。エンジニアに依頼してチケット化して順番待ち、というプロセスがなくなります。
また、DX文化の醸成 にも直接効きます。「自分でも作れる」体験をした業務担当者は、技術への抵抗が下がり、DXプロジェクトへの参加意欲が増します。これは数字には出にくいが、長期的には組織能力の差として現れます。
ただし限界もあります。複雑なロジック、大規模データ処理、セキュリティ要件の高い領域は、業務担当者だけでは無理です。エンジニアの伴走が必要になります。「業務担当者が9割作り、エンジニアが残り1割と監督を担う」 バランスが、最も成果が出る分業形態になります。
8. 受託依存からの脱却と内製化
社内ツール開発は、AIDD以前は 受託発注の代表領域 でした。中小規模の業務システムを300〜1,000万円で外注し、要件変更ごとに追加見積もり、5年使ってリプレースで再度数千万円。多くの企業がこのコスト構造に縛られてきました。
AIDDによる内製化が現実的になると、このコスト構造が変わります。受託費が削減できるだけでなく、業務理解の深い人がツールを作る ため、品質も上がります。さらに、ノウハウが社内に蓄積します。受託の場合、ツールを作る過程で得られる業務理解の知見が、すべて受託会社側に蓄積していました。内製化はこれを社内資産に変えます。
ただし、完全内製を目指すべきではありません。すべてを内製すると、エンジニアのリソースが圧迫され、結局またシャドーITになります。「重要かつ社内で持つべきもの」を内製、「コモディティ化しているもの」はSaaS、「専門性が高いもの」は受託、という三層構造で考えるのが現実的です。
受託 vs 内製のコスト比較（5年TCO試算）
| 項目 | 従来の受託 | AIDDによる内製 |
|---|---|---|
| 初期開発費 | 500万円 | 50万円 |
| 改修費（年） | 100万円×5年=500万円 | 50万円×5年=250万円 |
| 運用保守費（年） | 60万円×5年=300万円 | 30万円×5年=150万円 |
| ライセンス費 | – | 年30万円×5年=150万円 |
| 5年TCO | 1,300万円 | 600万円 |
| 業務理解の蓄積先 | 受託会社 | 自社 |
📊 経営判断のコツ：内製化は単年度のコスト削減ではなく、5年・10年スパンの組織能力構築 として評価します。受託依存は「楽な選択」に見えるが、組織能力が育たないコストが見えにくく蓄積します。
9. 社内ツール開発の典型的な失敗パターン
成功事例だけでなく、よくある失敗も整理しておきたいです。AIDDで作りやすくなったからこそ、新しい形の失敗も生まれています。
第一に、「作って満足」パターン。プロトが動いた段階で達成感が出てしまい、定着・運用設計が抜けます。結果、誰も使わないツールが増えます。対策は、運用フェーズまでをスコープに入れた計画にすること。
第二に、「シャドーIT化」パターン。IT部門に相談せず勝手に作り、機密データを無料AIに送ったり、認証なしで公開したりします。対策は前述のガードレール設計と教育。
第三に、「過剰内製」パターン。何でも内製しようとして、SaaSで十分な領域まで自作します。結果、メンテ負荷で潰れます。対策は、SaaS・内製・受託の判断基準を持つこと。
第四に、「スケール無視」パターン。10人で動いていたプロトを全社に広げて性能限界に達します。対策は、本格化判断のマトリクスを使って早期に判断すること。
10. 経営観点での価値と投資判断
経営層から見た社内ツールAIDD化の価値は、4つに整理できます。
第一に、業務改善の速度。月単位の業務改善が週単位になります。これは積み重なると大きな差になります。年間50件の業務改善ができていた組織が、年間500件できるようになると、3年後の業務効率はまったく違うものになります。
第二に、DX民主化。業務担当者が技術に関与する文化が育ちます。これは数値化しにくいが、長期的には組織の競争力に直結します。
第三に、コスト削減。前述の通り、5年TCOで半減レベルの削減が現実的です。さらに改修速度が上がることで、「いっそ全部作り直す」という最終手段の頻度も下がります。
第四に、差別化。汎用SaaSでは作れない自社専用ツールを量産できる組織は、業務プロセスそのものが競争優位になります。トヨタの工場が製造工程の差で競争したように、知識労働の組織は業務ツールの差で競争する時代になりつつあります。
まとめ
AI駆動開発による社内ツール開発は、「数日で作って数週間で定着」を現実にし、業務担当者の参加と内製化を同時に推進します。プロト即生成・段階的本格化・ガバナンス設計・分業バランス の4点を押さえれば、シャドーITに陥らず民主化のメリットを取れます。経営的には、5年TCOで半減・組織能力構築・差別化の3つが価値の柱。注意点は「作って満足」「過剰内製」「スケール無視」といった新しい失敗パターンを早期に把握し、組織として学習することです。
導入チェックリスト
- [ ] 推奨ツールスタックの整備（v0・Cursor・Vercel等）
- [ ] ガバナンスの3階層化（自由・要相談・禁止）
- [ ] プロト運用 vs 本格化の判断マトリクス策定
- [ ] 業務担当者向けAI開発研修の実施
- [ ] エンジニア伴走の体制整備
- [ ] シャドーIT対策（推奨レーン整備＋教育）
- [ ] 成功事例の社内共有プロセス
- [ ] 5年TCO試算の経営層共有
- [ ] 改善サイクルの週次運用
IT COMPASSのAI駆動開発支援
IT COMPASS では、CTO経験者が外部CTO・技術顧問として、社内ツール開発の内製化と組織変革を伴走支援しています。
支援できること
- 💡 内製化戦略設計：受託依存脱却・社内ツール量産戦略・5年TCO試算
- 🛠 ツール選定とパイロット設計：Claude Code / Cursor / GitHub Copilot 等の評価・PoC設計
- 🛡 ガバナンス・セキュリティ整備：AI利用ポリシー、権限設計、知財・契約ルール
- 👥 開発組織の再設計：AIエージェントを前提としたチーム編成・役割定義・評価制度
- 📈 経営会議への定例参加：取締役会・経営会向けのKPI設計と進捗レポート
こんな方におすすめ
- 受託依存・ベンダー依存から脱却したい経営者・経営企画の方
- 業務改善を爆速化したい現場リーダー・情シスの方
- 内製化戦略を本気で進めたいCTOの方
お問い合わせ
スポット相談（1回／契約不要・最短当日）から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。
👉 IT COMPASS お問い合わせフォーム
経営と技術の両面から、御社のAI駆動開発を一緒に設計しましょう。
監修者
西脇 靖紘（lanitech合同会社 代表取締役CEO 兼 CTO）
「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援しています。著書はオライリー・ジャパンから複数刊行。
