> For the complete documentation index, see [llms.txt](https://livlog-llc.gitbook.io/engineering-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://livlog-llc.gitbook.io/engineering-handbook/riburoguno/3-technology-and-architecture/technology-selection.md).

# 技術選定の基準

## 基本方針

リブログでは、流行している技術を無条件に採用するのではなく、プロダクトを小さく作り、公開後も長く改善できることを重視します。

技術を選ぶときは、次の観点を確認します。

* 長期的に保守できること
* 小規模な体制でも運用しやすいこと
* データを蓄積し、別の見せ方やプロダクトで再利用しやすいこと
* AIコーディングエージェントが構成や変更範囲を理解しやすいこと
* 要件に応じて静的公開や低コスト運用を選べること
* 既存のコード、データ、運用知識と組み合わせやすいこと

選定理由を説明できない技術は採用せず、新規性よりも目的との適合を優先します。

## 選定基準

以下は、新規開発で検討を始めるための第一候補です。実際の採用技術は、機能、データ量、更新頻度、公開方法、既存資産を確認して決定します。

| 用途          | 第一候補                                       | 選定理由                                          | 補足                              |
| ----------- | ------------------------------------------ | --------------------------------------------- | ------------------------------- |
| 小規模なWeb API | Java / Micronaut / Javalin                 | 既存資産を活用しやすく、責務を絞った構成にしやすい                     | 要件と既存プロダクトとの整合を確認して選ぶ           |
| 静的サイト       | HTML / JavaScript / GitHub Pages / Netlify | 小さく公開しやすく、サーバー運用を減らせる                         | 地図、記事、データ可視化と相性がよい              |
| 地図表示        | Leaflet                                    | 軽量で、地点データやGeoJSONを扱いやすい                       | 利用する地図タイルやデータの規約を確認する           |
| データ保存       | MySQL / MariaDB                            | 既存資産を活用しやすく、検索や集計に対応できる                       | DBが不要な規模ではCSVやJSONも検討する         |
| 画像表示        | Lightbox系ライブラリ                             | 写真の一覧と拡大表示を小さな実装で提供しやすい                       | 依存関係、アクセシビリティ、ライセンスを確認する        |
| AIネイティブ開発   | Codex                                      | 調査、実装、テスト、レビュー、文書化を補助でき、小規模体制でも継続しやすいコスト構造である | Codex専用の手順にせず、変更内容と最終判断を人間が確認する |

第一候補は固定された標準ではありません。既存資産との相性が悪い場合や、要件を満たせない場合は、理由と検証結果を記録したうえで別の技術を選びます。

## 判断ルール

* まず静的サイトで実現できないかを考える
* APIが必要な場合のみ、サーバーサイドを追加する
* DBが必要な場合は、長期的に再利用できるデータ構造を設計する
* 地図、写真、地域データは、GeoJSON、CSV、JSONなど再利用しやすい形式を優先する
* 新しい技術を使う場合は、小さな検証を行ってから本採用する
* AIが構成を理解しやすく、人間も変更を読み直しやすい構成を優先する
* 認証情報をブラウザへ渡す必要がある構成や、公開範囲を制御できない構成は避ける
* 採用後の更新、バックアップ、障害対応まで含めて運用可能かを確認する

## 選定時に残す情報

技術選定の結果だけでなく、後から判断を見直せる情報を残します。

* 解決したい課題と必要な機能
* 静的構成、API、DBが必要かどうか
* 比較した候補と採用・不採用の理由
* 小さな検証で確認した内容
* データの保存形式と再利用方法
* デプロイ、更新、バックアップの方法
* セキュリティ、ライセンス、外部サービス依存の注意点

記録は、将来の変更判断に使える粒度に絞ります。内部構成や認証情報など、外部公開に適さない情報はHandbookに記載しません。

既存プロダクトの選定理由を整理する場合は、当時のIssue、設計文書、検証結果などから確認できる判断だけを残します。実装から分かる構成の特徴と、当時の採用理由は区別します。記録がない理由を後から推測したり、検討していない代替案を比較済みとして書いたりしません。全製品に同じ比較表を追加するより、今後の変更判断に必要な選択から整理します。