システム開発の技術選定｜AI駆動開発での決め方と判断軸
新規事業のシステム開発では、「どの言語で作るか」「どのフレームワークを使うか」を早い段階で決める必要があります。この記事では、AI駆動開発によって技術選定の何が変わり、何が変わらないのかを整理します。そのうえで、言語やフレームワークを決めるときの6つの判断軸と、机上で決めきらずに確かめる方法を紹介します。
技術選定で迷うのは、事業の形がまだ固まっていないから
システム開発における技術選定とは、そのシステムを作るための道具立てを決めることです。具体的には、次のような項目が含まれます。
- プログラミング言語（TypeScript、Python、Ruby、PHP、Javaなど）
- フレームワーク（言語ごとに用意された、アプリの骨組みをまとめた部品群）
- データベース（データを保存・検索する仕組み）
- インフラ（システムを動かすサーバーやクラウドの構成）
- 認証・決済・通知など、外部サービスを使うか自作するか
既存事業のシステムであれば、すでにある資産や社内のエンジニアのスキルが、選択肢を自然に絞ってくれます。新規事業ではそうはいきません。需要がどこまであるのか、どの機能が事業の中心になるのかが、まだ見えていないからです。
この状態で技術を決めると、次のような後悔が起きやすくなります。
- 将来の利用者増を見込んで大がかりな構成にしたが、事業の方向が変わって使わなくなった
- 一部の人しか知らない技術で作ったため、担当者が変わると誰も触れなくなった
- 流行している技術を選んだが、事業に必要な機能との相性が悪かった
技術選定そのものが難しいというより、「事業が不確実なまま、後から変えにくい判断を求められる」ことが悩みの正体です。AI駆動開発の時代になっても、この構造は変わりません。ただし、判断の材料の集め方は変わってきています。
AI駆動開発で変わること、変わらないこと
AI駆動開発の全体像は、AI駆動開発とは｜AIと人の役割分担と発注側の要点で整理しています。ここでは、技術選定に関わる部分に絞って見ていきます。
変わること
新しい技術の習得にかかる負担が下がります。 従来は、チームが使い慣れた技術に引きずられがちでした。新しい言語やフレームワークは学ぶ時間がかかるため、事業との相性より「慣れ」で決まる場面が少なくありませんでした。AIが実装の大部分を支援する開発では、特定の技術に習熟した人がいないことが、以前ほど大きな制約になりません。
複数の案を試作して比べやすくなります。 同じ機能を2つの技術で小さく作って比べる、といった検証が現実的になります。工数の考え方そのものが変わる点は、AI開発で人月の考え方はどう変わる？工数で測れない部分でも触れています。
AIが書きやすい技術という観点が加わります。 一般に、公開されているコードや資料が多い、広く普及した技術ほど、AIが一定の品質のコードを出しやすい傾向があると言われます。逆に、利用者の少ない技術や独自色の強い仕組みでは、AIの出力に誤りが混ざりやすくなる可能性があります。ただし、これは使うモデルや題材によって変わります。一般論をうのみにせず、実際に動かして確かめることが大切です。
変わらないこと
一方で、AIが代わりに決めてくれないものがあります。
- 事業で確かめたいことに、その技術が合っているか
- 運用・保守を続けられる体制があるか
- セキュリティや個人情報の扱いに問題がないか
- ライセンスや権利関係に問題がないか
- 将来、別の開発チームに引き継げるか
AIは、示された条件の中で候補を挙げ、実装を進めることは得意です。しかし、「何を事業の優先事項とするか」「どのリスクまで許容するか」は、事業の側が決めることです。AI駆動開発での人の役割は、何を作るかを決めることと、品質を最終的に判断することにあります。技術選定はまさに、この両方にまたがる判断です。
言語・フレームワークを決める6つの判断軸
特定の技術を「これが正解」と言い切ることは、事業ごとに前提が違うため難しいものです。そこで、どの事業にも使える判断軸を6つに分けて整理します。
1. 事業で確かめたいことに合っているか
最初に見るのは、技術の優劣ではなく、事業の仮説です。たとえば次のように考えます。
- 利用者が日常的に何度も開く、通知が重要なサービスなのか
- 画面のなかで完結するサービスなのか
- 特別な端末機能（カメラ、位置情報など）を使うのか
スマートフォンアプリにするかWebにするかで、選べる技術の範囲は大きく変わります。この分け方は新規事業のアプリ・Web開発｜最初の選び方の基準で詳しく扱っています。まず形を決め、そのうえで技術を絞る順番が、遠回りに見えて手戻りが少なくなります。
2. 普及度と情報量は十分か
次に見るのは、その技術がどれだけ使われているかです。確認する点は次のとおりです。
- 公式のドキュメントが整備され、更新が続いているか
- 開発者コミュニティが活発で、困ったときの情報が見つかるか
- 保守を引き受けられる開発者が市場にいるか
AI駆動開発では、情報量の多さが「AIの出力の安定しやすさ」にもつながる傾向があります。人にとってもAIにとっても扱いやすい、という意味で、普及した技術は新規事業の初期に堅実な選択になりやすいと言えます。
3. 変更しやすい構造か
新規事業では、作った後に仕様が変わる前提で考えるのが現実的です。そのため、「最初の速さ」だけでなく「変えやすさ」も見ます。
- 機能を追加したとき、他の部分に影響が広がりにくい構造か
- データの持ち方を後から見直しやすいか
特にデータの持ち方は、後から変えるのに手間がかかる部分です。新規事業のデータ設計｜最初に決めたい5つの持ち方を参考に、技術の選定と並行して考えることをおすすめします。利用者増への備えをどこまで先取りするかは新規事業のシステムの拡張性｜利用者増への備えはどこまでにまとめています。
4. 運用とセキュリティの責任を持てるか
技術を選ぶことは、その技術の運用責任を引き受けることでもあります。次の点を確認します。
- セキュリティの修正プログラムが継続的に提供されているか
- 使用する部品（ライブラリ）の更新を誰が追うのか
- 個人情報や決済情報を扱う場合、必要な対応を取れる構成か
AIが生成したコードにも、確認が必要な点があります。AI生成コードのセキュリティ｜確認点と人の役割で、人が見るべき範囲を整理しています。個人情報を扱う事業であれば、新規事業の個人情報とシステム設計｜設計前に確認する点も合わせて確認してください。
5. 自作するか、外部サービスを使うか
技術選定には、言語やフレームワークだけでなく、「どこまで自分たちで作るか」も含まれます。認証、決済、メール配信などは、実績のある外部サービスを使うほうが早く安全な場合があります。一方で、事業の差別化につながる部分は、自作する価値があります。
分け方の考え方は、新規事業の決済システム開発｜外部サービスと自作の分け方が参考になります。迷うときは、「この機能が事業の競争力そのものか」を基準にすると整理しやすくなります。事業の中心でない部分は、既存の部品に任せるほうが、確かめたいことに集中できます。
6. 将来の引き継ぎができるか
最後に、数年後の姿を想像します。開発チームが変わる、内製に切り替える、別の会社に保守を任せるといった場面で、次のことが問題になります。
- ソースコードや設計書を受け取れるか
- 書かれた内容を別の人が読んで理解できるか
- サーバーやアカウントの名義が整理されているか
AIが書いたコードでも、読みやすさと説明の残し方で保守のしやすさは大きく変わります。詳しくは、AI生成コードの保守は可能か｜引き継ぎと改修の確認点、AI設計書の自動生成は可能？後から困らない残し方をご覧ください。権利や名義については、ソースコードの著作権譲渡｜費用を払っても自動では移らないとシステム開発のサーバー名義は誰にする？外注前の決め方でも整理しています。
新規事業の型ごとに見る、考え方の例
6つの判断軸を、事業の型に当てはめるとどうなるかを見てみます。ここで挙げるのは考え方の例であり、特定の技術を推奨するものではありません。
会員向けの画面中心サービス（予約・サブスク・マッチングなど）
利用者が登録し、画面から操作するタイプのサービスです。Webアプリとして作り、広く普及したWebフレームワークで足りるケースが多くなります。
このタイプで効いてくるのは、言語の違いよりも、認証、決済、通知、データの持ち方といった周辺の設計です。事業ごとに最初に決めることは、次の記事で整理しています。
生成AIを機能の中心に置くサービス
文章生成や判断支援などをLLM（大規模言語モデル）に任せるタイプです。ここでは、アプリを書く言語よりも、「使うAIモデルを後から入れ替えられる構造か」「出力の精度をどう評価するか」が重要になります。AIモデルは提供条件が変わったり、提供が終了したりすることがあるためです。
既存システムと連携する事業
既存の基幹システムやデータとつなぐ場合は、連携先が対応している方式に合わせる必要があります。一方で、新規事業を既存システムに載せてしまうと、変更のたびに調整が増えます。切り離して作る考え方は、新規事業は既存システムと切り離して作る理由と進め方で扱っています。
専門性の高い処理を含む事業
独自の計算ロジックや、専門分野のルールをシステムに落とし込む事業です。この場合は、業務知識をどう伝えるかが、技術の選択と同じくらい重要です。専門性の高いシステム開発の依頼｜業務知識の伝え方を参考にしてください。
机上で決めきらず、プロトタイプで確かめる
技術選定は、資料や比較表を眺めているだけでは、確信を持ちにくい判断です。実際に動かしてみて初めて分かることがあるからです。
- 想定している画面操作の反応が十分に速いか
- 外部サービスとの連携が、思った通りにつながるか
- データの持ち方が、実際の使い方に合っているか
- AIが生成したコードが、読めて、直せる品質か
AI駆動開発の利点は、この確認を小さく、早く回せる点にあります。AIでプロトタイプを短期間で作れる仕組みについては、AIでプロトタイプを短期間で作れる理由｜工程ごとの仕組みで説明しています。
検証するときのポイント
確かめる範囲は、事業の仮説に関わる部分に絞ります。
- 事業の中心になる機能を1つか2つ選ぶ
- その機能で、技術的に不安な点（速度、連携、データ量など）を書き出す
- 不安な点が実際に問題になるかを、動くもので確認する
- 問題があれば、技術の選択肢を見直す
最初から全機能を作る必要はありません。小さく作って確かめる進め方は、新規事業の開発は小さく作って確かめる投資判断の進め方で、アイデアを動くもので確かめる手順は新規事業のアイデア検証方法｜動くシステムで確かめる手順で詳しく扱っています。
また、プロトタイプで選んだ技術が、そのまま本開発に使えるとは限りません。引き継げる部分と見直す部分の考え方は、MVPから本開発は作り直し？引き継げる部分と見直す点をご覧ください。
開発会社に確認したい質問
技術選定は、開発会社に任せる場面も多くあります。その場合でも、発注側が判断の経緯を理解しておくことは大切です。確認しておきたい質問を挙げます。
- その技術を選んだ理由は何ですか。 事業の目的に結びつけて説明してもらえるかを見ます。
- ほかにどんな候補があり、なぜ見送ったのですか。 比較の過程が語られるほど、判断の質は確かめやすくなります。
- AIが生成したコードは、誰がどのように確認していますか。 確認の工程が決まっているかを見ます。観点はAIコードレビューで指摘される点と人が判断する点とAI開発でも品質には人の確認が必要な理由が参考になります。
- 事業の機密やアイデアは、AIの利用でどう守られますか。 詳しくは生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで整理しています。
- 納品時に何を受け取れますか。 ソースコード、設計書、環境の構築手順など、保守に必要な成果物を確認します。システム開発の納品物一覧｜ソースコード以外に受け取る成果物が役立ちます。
- 将来、別の会社が保守できる状態になっていますか。 特殊な技術や独自の仕組みに依存しすぎていないかを見ます。
依頼前の確認事項全体は、AI受託開発に依頼する前に確かめたい6つのことにもまとめています。AIの種類を選ぶ観点は、AIシステム開発でのAIの選び方｜2026年10月比較とAIコーディングツール比較｜特徴と向く使い方｜2026年10月が参考になります。
まとめ
新規事業のシステム開発における技術選定は、事業の形がまだ固まらない中で、後から変えにくい判断を求められるところに難しさがあります。AI駆動開発によって、新しい技術の習得負担は下がり、複数案の試作も現実的になりました。一方で、事業に合うか、運用を続けられるか、引き継げるかといった判断は、これまでどおり人が行う必要があります。
判断軸は、次の6つに整理できます。
- 事業で確かめたいことに合っているか
- 普及度と情報量は十分か
- 変更しやすい構造か
- 運用とセキュリティの責任を持てるか
- 自作するか、外部サービスを使うか
- 将来の引き継ぎができるか
そして、これらを机上で決めきらず、小さく動かして確かめることが、手戻りを減らす近道です。
JustFitは、株式会社LEGAREAが運営する受託開発サービスです。構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見てから契約を判断できる進め方をとっています。開発では、独自のAI開発基盤「LAF」を使い、人は何を作るかの決定と品質の最終判断を担います。設計やレビューでも、LEGAREAの経験と品質基準にもとづいて提案・チェックします。システムそのものが事業になるような新規事業を得意としていますので、技術の選び方に迷う段階でも、詳しくはJustFitのサービス紹介をご覧ください。