技術スタック

弊社が実際の開発で使っている技術と、それを選ぶ理由をまとめました。件数は公開している開発事例のうち、その技術を使ったものの数です。

技術の選定は、それ自体が目的ではありません。ただ、CTO や技術責任者がいない状態で開発を外部に任せるとき、「何を使って作られるのか」「あとから自社で引き取れるのか」が分からないのは不安だと思います。

弊社は、事業のフェーズと引き継ぎのしやすさを基準に技術を選びます。具体的には、採用市場に人がいること、公式のドキュメントが整っていること、そして5年後にも保守されている見込みがあること。尖った選択で開発速度を上げるより、あとから来た人が読めることを優先します。

以下は層ごとの考え方と、実際に使っている技術です。ここに無いものを使わないという意味ではありません。既存システムの保守を引き継ぐ場合は、そこで使われている技術に合わせます。

言語とフレームワーク

新規のプロダクトでは TypeScript を第一の選択肢にしています。画面もサーバーも同じ言語で書けるため、少人数のチームで両方を見るときに切り替えの負荷が小さく、API がやり取りするデータの形を型として共有できます。

Laravel と PHP は、既存システムの保守・刷新で多く使っています。レガシーの引き継ぎでは、動いているものを別の言語で作り直すより、同じ技術のまま整理していくほうが安全に進むことが多いためです。

React と Next.js を標準にしています。採用市場に人が多く、社内に開発チームを作る段階で引き継ぎ先に困りにくいことが理由です。

デザインシステムは最初から作り込みません。shadcn/ui のように、コードが自分たちのリポジトリに入る方式を使うと、あとから変えたいときにライブラリの更新を待たずに済みます。

データベースは MySQL と PostgreSQL のどちらかです。特別な理由がなければ、運用の情報が多い MySQL を選びます。ベクトル検索を使う場合は pgvector のある PostgreSQL にします。

インフラは AWS を中心に、コンテナで動かします。構成をコード（Terraform / AWS CDK）で書いておくと、検証環境を同じ形で作れて、担当が変わっても現状を読み取れます。

テストと継続的インテグレーションは、規模にかかわらず最初から入れます。あとから足すのは、すでにあるコードすべてにテストを書くことになり、現実的に終わりません。

自動テストがあると、リリース前の動作確認を人手で繰り返さずに済みます。週次でデモをお見せする進め方は、この仕組みの上に成り立っています。

生成AIは、開発工程とプロダクトの機能の両方で使っています。開発工程では設計の下書き、コードの生成とレビュー、テストの作成、既存コードの解析に使い、エンジニアは判断と確認に時間を充てます。

プロダクトの機能としては、チャット、要約、分類、社内文書を根拠に回答する仕組み（RAG）を組み込みます。モデルは用途と費用で選び、一社に固定しません。AI が生成したものは必ず人がレビューし、テストを通してから納品します。品質の責任は人が負うという原則は変えていません。

件数は公開している開発事例に限ったものです。守秘義務のため掲載していない案件もあり、実際の利用はこれより多くなります。

用語の意味は用語集、選び方の考え方はPhilosophize ITをご覧ください。

アイデア段階でも、要件が固まっていなくても構いません。先進性・UX・コストパフォーマンスの観点で、次の一手を一緒に整理します。ご相談・お見積りは無料、通常1営業日以内にご返信いたします。

資料の添付は、送信後に届く受付メールへの返信でお送りいただけます。