技術選定より前に、「買う/ノーコード/内製/外注」を決める
アプリが必要になったとき、選択肢は「作る」だけではありません。既製のSaaSを買う、ノーコード/ローコードで内製する、コードを書いて自社開発する、開発会社に外注する。この4つを、要件の独自性・利用規模・データ機微度・差別化への寄与・TCO(総保有コスト)という判断軸で比較してから着手すると、失敗が大きく減ります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 買う(SaaS/パッケージ) | 要件が標準的で既製品に乗る。立ち上げを急ぐ | 席数課金の累積、業務との不一致、連携制約、ロックイン |
| ノーコード/ローコード | 標準業務に近く、機微度が低めで、内製完結したい | 複雑化すると作り直しやツールロックインが生じうる |
| 内製(自社開発) | 独自性が高い、深い連携、機微度が高い、大規模・長期利用 | 開発・運用体制が必要。AI支援で合理的な範囲は拡大中 |
| 外注(受託開発) | 「作る」が最適だが、社内に開発・運用の体制がない | 丸投げでは成功しない。要件定義や受入の責任は残る |
「迷ったら買う」でも「とにかく作る」でもなく、文脈で選ぶ。これが第一の原則です。たとえば利用規模が大きく席数課金が累積していく、既製品に業務を合わせる運用コストが高い、その仕組み自体が競争優位になる、深いシステム連携やデータ主権が必要 ― こうした条件が重なるほど、「作る」が「買う」に勝ちやすくなります。
どの道を選ぶ場合でも外せない原則が5つあります。➀オーナー(責任者)を着手前に決める、➁運用・保守の担い手を着手前に決める、➂データ機微度を最初に判定する、➃3年程度のTCOで横並び比較する、➄「作って終わり」にしない設計にする。特に➀➁を欠いたまま作り始めたアプリは、高い確率で「作った人しか触れない塩漬け資産」になります。
AIの活用は「作る」と「載せる」の2つの面がある
社内アプリ開発におけるAIの話は、性質の異なる2つを分けて考える必要があります。
「作る」 ― AIコーディング支援
コード補完が中心だった時代から、いまはタスクを委譲できるエージェント型へと進化し、開発の生産性を大きく押し上げています。ただし、出力を全面的に信頼してよい段階にはなく、レビューは依然として必須です。脆弱性の混入、存在しない依存パッケージの捏造(slopsquatting)、社内コードや秘密情報の外部送信、出力への過信 ― こうしたリスクに対して、使ってよいツールと用途の明示、学習不使用設定の確認、秘密スキャン、そして生成コードも通常のコードと同じ検査(レビュー・静的解析・依存スキャン)にかけるというガバナンスをセットで整えます。
「載せる」 ― アプリへのAI組み込み
チャット・要約・分類・RAG(社内文書を検索してAIに根拠として渡す仕組み)などの機能をアプリに組み込む面です。モデル基盤は既存のクラウドエコシステムに合わせるのが定石で、Amazon Bedrock、Azure AI Foundry、Vertex AIなどが代表格です(2026年6月時点)。安全性の土台はOWASP Top 10 for LLMですが、要点は3原則に集約できます。認可はLLMの外で決定的に強制する(AIに権限判定をさせない)、入力も出力も信頼せず検証してから使う、単一のガードレールに頼らず多層で守る。
初めてなら ― 小さく、機微度の低い題材から
初学者がまず選ぶべきは、機微度が低く、社内の少人数が使い、止まっても困らない題材です。例を挙げれば、申請の集約フォームや社内FAQのような業務効率化です。逆に、個人情報や機密データを最初の練習台にする、いきなり全社公開する、APIキーなどの秘密をプロンプトやコードに直書きする、レビューなしで生成物を本番投入する、運用担当を決めずに作り始める ― これらは避けてください。小さく作って早く使ってもらい、PoC→限定公開→本番と段階を踏むのが、規模を問わず通用する型です。
「外注」は逃げではなく、設計された選択肢
独自性が必要でノーコードの範囲を超える、機微データや決済・削除のような影響の大きい操作を扱うため専門判断が要る、社内に開発・運用体制がない ― こうした場合、外注は合理的な選択です。一方で、要件が標準的で既製SaaSで足りる場合や、要件が固まっておらずまず自社で試行錯誤したい段階では不向きです。外注する場合も、要件定義・権限の取り決め・受入・運用ガバナンスの責任は発注側に残ります。選定では、見積もりの透明性、セキュリティとデータの取り扱い、ソースコードとデータの所有権、引き継ぎ・保守体制という出口戦略まで握ることが、「作って終わり」を防ぐ鍵になります。
まとめ ― 着手前チェック5項目
- 買う/ノーコード/内製/外注を、要件・規模・差別化・TCOで比較したか。技術選定はその後。
- オーナーと運用・保守の担い手を、着手前に決めたか。
- 扱うデータの機微度を最初に判定したか。個人情報・規制データなら専門家に委ねるサイン。
- AIコーディングの利用ルール(許可ツール・データ設定・レビュー)を定めたか。
- AI組み込みの3原則(認可のLLM外強制・入出力の検証・多層防御)を設計に含めたか。
「作れること」と「運用し続けられること」は別物です。AIの進化は「作れること」のハードルを劇的に下げましたが、だからこそ、入口の意思決定と運用まで見据えた設計の価値が上がっています。