この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/19の記事です。

こんにちは。askenでエンジニアをしている岩間です。

12/18 に弊社の澤路が過去の技術選定をAIエージェントに再検証させるブログを書いていたことに影響を受け私も技術選定をテーマにポエム味で書いてみました。

新しいプロダクトを作るときやシステムの課題解決の際に、毎回「どの技術を採用するか」という悩みがあります。開発言語は何にするのか、フレームワークは何にするか、利用するデータストアはRDBMS か KVS (Key-Value Store) なのか...世の中には様々な技術が溢れていて、流行りの技術、強そうな技術、面白そうな技術が沢山あります。

この記事では、私が新たなプロダクトや課題解決を考える際に普段どのような観点で技術選定を行っているかを簡単に整理してみました。

なお、ここに書く内容は「唯一の正解」ではなくあくまで私個人が普段考えていることをまとめたものになりますのでご注意を。

技術選定の観点

まず前提として、技術選定は技術的に優れているかや技術トレンドだけで決めないようにしています。特にトレンドにのった新しい技術は面白そうで使ってみたい！という欲求が生まれるのですが、流石にそれだけで採用できません。最近を振り返ってみると私の場合は4つの観点がありました。

機能、非機能要件を満たしているか
技術的に成熟しているか・情報量が十分か
エンジニア組織へ適合するか
プロダクション投入までの速さ

1. 機能、非機能要件をみたしているか

まず機能要件を満たしているか、そして非機能関連の最低限の要件を満たしているか確認します。非機能要件に関しては、

性能
セキュリティ
コスト
可用性
運用性
ライセンス
AI との親和性あたりを確認します。

あすけんはコンシューマ向けのサービスがメインであり、新規開発は 最終的には本番規模のトラフィック（月間132万UU：2025年度5月実績）を前提に考える必要があります。食事記録機能を提供するあすけんアプリの特徴として、昼食時に極端なスパイクトラフィックが発生するということもあるため、性能要件を満たせるかどうかは私たちにとって重要な選定ポイントになることが多いです。

2. 技術的に成熟しているか・情報量が十分か

採用しようとしている技術が成熟しているか、必要な情報に辿り着けるかという観点です。特に新しい技術やサービスなどは一見有用そうに見えても実際に使ってみると品質が十分でなかったり、何か問題が起きても情報が不足して対応に窮することがあります。そのため成熟度合いを

OSS 等であれば GitHub の issue / PR 数 / Star 数
技術ブログで取り上げられる数
コミュニティの活性度
Google 検索トレンド
有償サービスなどであればサポートの有無
Thoughtworks のTechnology Radar、などといった点を確認します。困ったときに「調べれば何とかなる確率」が高いかどうかは、開発スピードと安定性（安心感）につながります。

3. エンジニア組織へ適合するか

エンジニア組織への適合性という観点では、

既存技術スタックとの親和性
エンジニアが導入して上手く使えるか・運用できそうか
特定の人に依存するようなものにならないか
学習コストあたりを考えます。

asken のバックエンド開発では DDD (ドメイン駆動設計) を取り入れリアーキテクチャした Kotlin とリアーキテクチャ前のPHPをメインの開発言語としています。少し前に性能重視のアプリケーション開発言語に関する技術選定があったのですが、開発言語として Go は候補にあがったものの見送られました。これはこの観点で検討した影響が大きいです。askenのバックエンドエンジニアの数は10人程であり、この人数で複数のアプリケーションの開発・運用をしているため自然と一人でカバーする範囲が広いのですが、さらにそこに新たな扱う開発言語を増やすのは障害調査やバグフィックスを含めた運用を考えるとかなり難しいです。また採用においても Go と Kotlin 両方を使えるエンジニアを探すようになるため難易度が上がってしまい、組織を大きくする際の足枷にもなってしまいます。

4. プロダクション投入までの速さ

次は最初のプロダクション投入までの速さです。少し意外に思われるかもしれませんが、特にこの下期に入ってからは１つの大事な観点にしています。asken のバリューとして 「+スピード」 というものを掲げており、ゴールへの最短ルートを追求することにしています。そのことを受け技術選定の際にも重視しています。

極端なことをいうと、どれだけ設計が美しくとも、どれだけ将来性があろうとも、どれだけ技術的にピカピカでもユーザに提供できる価値につながらなければ意味がありません。そのため、いかに速く本番にリリース（価値提案）し、実ユーザからフィードバックを得られるのか、を重視して進めたいのです。

この観点で何を考えるかというと、例えば AWS サービスを利用する際は極力マネージドサービスを選ぶことや、SaaS とセルフホスティングの選択肢がある場合は SaaS を選ぶといったことです。

観点の優先度

４つの観点をあげましたが、実際のところこれらを全てをクリアすることはほとんどありません。新しい技術を起点とした（最近ではLLMが該当）プロダクトをスピーディに開発し競合他社に優位性を持つことを優先するのであれば未成熟な技術でもあえて採用しますし、安定性を大事にする既存システムであれば熟した（枯れた）技術を採用するのがベターとなります。ケースバイケースで状況や課題に応じて先に上げた観点の濃淡を決めて選定します。

技術選定の例

ここでは、上記の観点を実際にどう適用したかの例として、今年の１月に行ったLLM関連機能の開発における技術選定を紹介します。

背景

asken では「あすけんラボ」という施策があり、実験的な機能を実装し一部のユーザに使ってもらえるようにしています。あすけんラボでは特に LLM 系機能のプロトタイプを開発しています。

満たしたい要件

この開発では、以下の要件を満たす必要がありました。

スピード重視: LLM と連携するバックエンドAPIを素早く開発し、ユーザへ提供してフィードバックを得たい。
非エンジニアによるプロンプトチューニング環境の整備: LLM 系のプロダクト開発ではプロンプトチューニングが必要になりますが、これはドメイン知識を持つ非エンジニア（デザイナー・管理栄養士）がより効率的に行えます。そのため、非エンジニアがチューニングできる環境を用意する必要があった。

選定結果

調査・検証の結果、Dify を採用しました。以下、4つの観点での評価を整理します。

各観点での評価

1. 機能・非機能要件

評価	項目
◯	非エンジニアでもプロンプトチューニングがしやすい（GUIがある）
✗	認証済みのあすけんユーザのみがAPIを使えるようにする必要あり（ SaaSは使えずセルフホスト＋別途認証の仕組みが必要）
△	あすけんラボユーザのトラフィックに耐えうる性能 → AWS CDK で構築するサンプルあり（あすけんの環境に合わせて要修正）

※AWS CDK：AWS Cloud Development Kit、AWSリソースをコードで定義するツール

2. 技術的に成熟しているか・情報量は十分か

評価	項目
◯	公式のマニュアルが充実している
◯	Difyを使った記事やコミュニティが存在する
◯	GitHub の PR / issue や star 数が十分
✗	新しいプロダクトであり機能追加・変更・修正が頻繁なため安定感があまりない

3. エンジニア組織への適合

評価	項目
◯	非エンジニアでも使えるツールのためエンジニアの利用は問題なし
△	Difyを運用できるか → AWS CDK のサンプルをあすけんの環境に合わせて変更する必要あり
△	定期的な Dify のアップデート対応（CDKソース修正・デプロイ・動作確認）ができるか（Difyのアーキテクチャ理解も求められる）

4. プロダクション投入までの速さ

評価	項目
◯	あすけんの認証と連携するためセルフホストが必要になり構築コストがかかるが、ノーコードツールのDifyを使うことでバックエンドとLLMを連携させたAPIをスピーディに作ることができる

選定の決め手

n8n など競合プロダクトも同様に調査しましたが、最終的には機能要件で上げていた非エンジニアでも利用できるGUIがあることと・プロダクション投入までの速さという点を重視し Difyを採用しました。

現状

今年の2月に構築しましたが、Difyは現在もデザイナーや管理栄養士メンバーがプロンプトチューニングを行いながらバックエンドAPIを開発できる環境として利用しており、スピーディーな開発を支えるツールとして役立っています。Dify のバージョンアップに属人性があるなど運用面に課題は残るものの、現時点では上手くいった選定だと評価しています。

おわりに

これまでどんな観点で技術選定をしていたかまとめてみましたが、最後に一つだけ付け加えると、 その技術を使っていて面白いか、個人的に興味を持てるか という感覚も実は完全にゼロにはしていません。ここでちゃぶ台ひっくり返すのかい！って思われるかもしれませんが、先に上げた観点で考えた末に迷ったら、自分が面白い、使ってみたいと思うものを選びます。最終的に責任をとるのは自身なので後悔のない選択にしたいですし、好奇心が学習スピードや課題が出た時の解決に向かう粘り強さにつながる場面もあります。

技術選定はロジックだけで完結するものではなくて最後は人が意思決定します。だからこそ総合的に考えた上で 「それ、面白そうだよね」 と感じられるかどうかを最後のひと押しとして大事にしても良いのではないでしょうか。