はじめに
本記事は、課題一覧 の
課題No.1 プラットフォームの選定を中心に
第一段記事の ホスティング環境 とした理由と、第二段記事の コンポーネント図 とした理由を説明します。
また コンポーネント図 のレイヤ構成に関しては、別の課題に紐付けて説明するものとします。
本記事で説明すること
まず、以下を念頭に 専門チャット検索機能 の ホスティング環境とローカル開発環境の構成 を検討しました。
- 最優先事項
- RAGアプリケーションの構築
- 必要なもの
- 無料枠で WEBサーバー、APサーバー、RAGアプリケーション を 公開・運用 できる環境。
- なるべく避けたいコスト
- 未経験のプログラミング言語、サーバーレス、PaaS固有仕様など、新しい技術スタック に対する学習コスト。
これを踏まえて、以下の観点で検討内容の説明をします。
- プラットフォームの選定。
- 永続的に無料枠でプラットフォームを利用することができる。
- 技術スタックの選定。
- RAGアプリケーション構築に必要な要件を満たすことができる。
- ホスティング環境とローカル開発環境の アプリケーション実行環境 の共通化ができる。
- 連携する生成AIモデル選定。
プラットフォームの選定
候補
プラットフォームの候補は以下としました。
- クラウド (IaaS)
- GCP GCE
- AWS EC2
- Azure Virtual Machine
- エッジ
- Cloudflare Workers
無料枠プラン
プラットフォームごとの無料枠プランの比較を、以下に記載します。
| プラットフォーム | VMインスタンス | プラン | 無料期間 | 構成 | Guest OS | CPU | RAM | ストレージ | 24時間稼働 |
|---|---|---|---|---|---|---|---|---|---|
| GCP | GCE | Google Cloud の無料プログラム | 期限なし ※1 |
e2-micro | Linux ※7 |
2 vCPU ※2 | 1GB | 30GB | 可能 |
| AWS | EC2 | AWS 無料利用枠 | 新規利用者は最大6か月 またはクレジット消費まで AWS の無料プラン |
t3.micro | Linux ※7 |
2 vCPU ※3 | 1GiB | 30GB | 可能 |
| Azure | Virtual Machine | Azure の無料アカウント | 新規利用者は12か月 | B1s | Linux ※7 |
1 vCPU ※3 | 1GiB | 2 × 64GB (P6) Managed Disk | 可能 |
| Azure | Virtual Machine | Azure の無料アカウント | 新規利用者は12か月 | B2pts v2 | Linux ※7 |
2 vCPU ※4 | 1GiB | 2 × 64GB (P6) Managed Disk | 可能 |
| Cloudflare Workers | - |
Workers Free ※制限あり |
期限なし | Worker Isolate | V8 Isolate/workerd | ※5 | 128MB | Workers KV 1 GB | ※6 |
※1. 現時点では無料期間に期限が設定されていませんが、永続的に無料期間が保証されている訳ではありません。
※2. 共有コア型です。短時間のバースト機能も持っています。
※3. バースト型です。
※4. ARM・バースト型です。
※5. vCPU という概念はなく、1HTTPリクエスト当たりのCPU実行時間は 10ms となります。
※6. Workers は VMインスタンス のような常駐プロセスではなくリクエスト駆動となります。
- 常時公開:可能
- 常駐プロセス:不可
※7. プラットフォームごとの Guest OS の選択肢は、以下の通りです
| プラットフォーム | VMインスタンス | Guest OS |
|---|---|---|
| GCP | GCE | Linux/Windows Server を選択可能。 ただし Google Cloud の無料プログラム における Windows Server の利用は有料 |
| AWS | EC2 | Linux/Windows Server を選択可能。 |
| Azure | Virtual Machine | Linux/Windows Server を選択可能。 |
| Cloudflare Workers | - | サーバーレスであるため Guest OS という概念はありません。 |
技術スタックの選定
RAGアプリケーション構築に必要な要件
- RAGアプリケーションを構築するために必要な要件を、以下に記載します。
- ※本機能 における、RAGアプリケーションを構築するために必要な要件を、以降 RAG要件 と表現します。
ユースケース
-
RAG要件 を満たすためには、以下の仕組みが必要です。
-
Retrieval (検索)
- BM25検索
- 質問に対する トークナイズ(分かち書き) が必要です。
- ベクトル検索
- 質問に対する
推論が必要です。
- 質問に対する
- BM25検索
-
Augmented (拡張)
- 本機能では、質問に対する回答が コーパス内に あるか/ないか を判定し、コーパスから回答するか/生成AI連携するか を決定する ルーティング判定 を実装しています。
- つまり検索結果を生成AIのプロンプトへ追加するのではなく、検索結果を生成AIと連携する必要があるかを判断する材料として利用しています。
- よって、特別なライブラリを必要としません。
-
Generation (生成)
- 生成AI連携するための インターフェース が必要です。
-
Retrieval (検索)
プログラミング言語の選定
- プログラミング言語ごとに RAG要件 に適しているかを表した
比較表 ※1を、以下に記載します。-
※1.比較対象とした プログラミング言語 は、私の経験値がある プログラミング言語 + Python としています。(笑)
-
比較表
メモリ消費量とRAG要件適性は、本機能の構成を前提とした私個人の評価です。
| プログラミング言語 | 私の経験値 | メモリ消費量 | トークナイズ(分かち書き) | 推論 |
生成AI連携 | RAG要件適性 |
|---|---|---|---|---|---|---|
| Java | 高 | 多 | Lucene Kuromoji | ONNX Runtime |
Gemini API 連携 OpenAI 連携 |
高 |
| JavaScript | 中 | 中 | Intl.Segmenter |
onnxruntime-node onnxruntime-web |
Gemini API 連携 OpenAI 連携 |
高 |
| TypeScript | 低 | 中 | Intl.Segmenter |
onnxruntime-node onnxruntime-web |
Gemini API 連携 OpenAI 連携 |
高 |
| Go | 低 | 小 | Kagome | ONNX Runtime 公式の API が提供されていません。 |
Gemini API 連携 OpenAI 連携 |
中 |
| Python | なし | 中~多 | SudachiPy | ONNX Runtime |
Gemini API 連携 OpenAI 連携 |
高 |
ホスティング環境とローカル開発環境の アプリケーション実行環境 の共通化
ホスティング環境を想定したローカル開発環境の構成を、以下に記載します。
この構成の目的は、ホスティング環境とローカル開発環境を Docker により アプリケーション実行環境 を共通化することです。
- ホスティング環境で Nginx を Docker Container に配置していない理由は以下の通りです。
- Nginx を Docker Container に配置した場合、Docker daemon再起動(システムメンテナンス)時に Nginx が停止されるのでブラウザ側が接続拒否(ERR_CONNECTION_REFUSED)になってしまうからです。
プラットフォームごとの Docker 導入対応
- プラットフォームごとの無料枠プランに Docker の導入が可能であるか、以下に記載します。
| プラットフォーム | VMインスタンス | プラン | Docker 対応 |
|---|---|---|---|
| GCP | GCE | Google Cloud の無料プログラム | 可能 |
| AWS | EC2 | AWS 無料利用枠 | 可能 |
| Azure | Virtual Machine | Azure の無料アカウント | 可能 |
| Azure | Virtual Machine | Azure の無料アカウント | 可能 |
| Cloudflare Workers | - |
Workers Free ※制限あり |
不可能 ※1 |
※1.
- Cloudflare Workers に関しては Cloudflare Containers を利用すれば Container の利用は可能です。
- ただし Cloudflare Containers と Docker Container の互換性については、本記事では検証していません。
- また、Cloudflare Containers は無料では利用できません。
- 月額最低5ドルのWorkers Paidプランが必要となります。(コンテナの価格設定)
連携する生成AIモデル選定
前提
本機能 の開発に着手した時期は、2025年11月でした。
当時(今もですが)は、以下の 開発業務フロー を日々回していました。
開発業務フロー を通して受けた、ChatGPT 5 と Gemini 3 Pro の 対話型生成AI に対する印象
これは2025年11月当時の、あくまでも私自身の印象ですが
- ChatGPT 5
- アップロードした 要件定義書、設計書、実装 を「正本」として固定参照しながら、機能追加や修正を積み重ねて完了まで持って行く運用が安定しない。
- 私がアップロードした「正本」の「版」と、ChatGPT 5 が参照する「正本」の「版」が違うため、毎回回答がズレる。
- アップロードした「正本」をチャット履歴の会話の一部として扱っている様な印象。
- 私がアップロードした「正本」の「版」と、ChatGPT 5 が参照する「正本」の「版」が違うため、毎回回答がズレる。
- アップロードした 要件定義書、設計書、実装 を「正本」として固定参照しながら、機能追加や修正を積み重ねて完了まで持って行く運用が安定しない。
- Gemini 3 Pro
- 一方、同時期に利用した Gemini では、同じ 開発業務フロー とした運用を継続しやすい。
- 私と Gemini 3 Pro が参照する「正本」の「版」が同じであるため、回答はズレないが精度が低い。(笑)
- 回答 = 完了 のバイアスが強く、回答根拠や回答の検証方法はプロンプトに指定しないと提供されない印象。
- 私と Gemini 3 Pro が参照する「正本」の「版」が同じであるため、回答はズレないが精度が低い。(笑)
- 一方、同時期に利用した Gemini では、同じ 開発業務フロー とした運用を継続しやすい。
と、なりました。
しかし、これは 生成AI ごとの絶対的な性能差ではなく、あくまでも ChatGPT 5/Gemini 3 Pro に対する私の利用方法での印象です。
また今更ですが、異なる 生成AI を比較する場合は、以下の二つを混同しないようにして評価する必要があると今は考えています。
- 対話型生成AI として評価する。
- モデル として評価する。
生成AIモデルの調査
まずは 開発業務フロー で使う 生成AIの モデル を使用したいと考えました。
つまり経済的に ChatGPT Plus/Gemini Advanced の両方を契約する事は厳しい状況でした。
そこで、当時利用していた ChatGPT Plus を契約解除、Gemini Advanced へ乗り換えて モデル も Geminiモデル にする、という流れです。
これを踏まえて、GPT-5 mini と Gemini 2.5 Flash を比較しました。
仕様比較
| 比較項目 | GPT-5 mini | Gemini 2.5 Flash |
|---|---|---|
| 主な位置づけ | 低コスト、低遅延、明確に定義された大量処理 | 価格性能比、低遅延、大量処理、推論・エージェント処理 |
| コンテキストウィンドウ ※1 |
400,000トークン | 1,048,576トークン |
| 最大出力 | 128,000トークン | 65,536トークン |
| テキスト入力 | 対応 | 対応 |
| 画像入力 | 対応 | 対応 |
| 音声入力 | 非対応 | 対応 |
| 動画入力 | 非対応 | 対応 |
| 出力 | テキスト | テキスト |
| 推論制御 | reasoning_effort | Thinking Budget |
| Function Calling | 対応 | 対応 |
| Structured Outputs | 対応 | 対応 |
| キャッシュ | Prompt Caching | Context Caching |
| プロバイダー側文書検索 | File Search (Vector Store) | File Search (File Search Store) |
| 外部情報との連携 | Web Searchなど | Google Search Grounding、URL Context、Google Mapsなど |
| 知識カットオフ | 2024年5月31日 | 2025年1月 |
※1.
- コンテキストウィンドウが大きいことは、一度に入力できる情報量が多いことを意味します。
- しかし、入力したすべての情報を常に正確に参照できることを保証するものではありません。
- 「人間の短期記憶に保存できる情報量には限界があり、生成モデルにも同じことが言えます」と Gemini API で説明されています。(長いコンテキスト)
料金比較
| 生成AIモデル | 入力 | キャッシュ済み入力 | 出力 | 備考 |
|---|---|---|---|---|
| GPT-5 mini | $0.25 | $0.025 | $2.00 | 低コスト・大量処理向け |
| Gemini 2.5 Flash | $0.30 ※1 |
$0.03 ※1 |
$2.50 | 出力料金にThinking Tokenを含む |
- OpenAI と Gemini では、キャッシュの仕組みと料金体系が異なります。
- 単位はすべて米ドル、100万トークン当たりのStandard API料金としました。
- 税金、為替、ネットワーク料金、GCPのインフラ料金は含めていません。
- GPT-5 miniの料金はOpenAI公式モデルページ、Gemini 2.5 Flashの料金はGoogle公式料金ページに基づきます。
※1.音声入力は 入力: 1.00USドル、キャッシュ済入力: 0.10USドル です。
結論
プラットフォーム
利用する プラットフォーム は GCP GCE としました。
選定した理由を以下に記載します。
GCP GCE
- 永続的な無料枠運用
- 可能です。
- GCP GCE の無料枠では、指定された米国リージョンで、毎月 VMインスタンス 1台分に相当する稼働時間を無料で利用できます。
- 可能です。
- RAG要件
- 満たすことができます。
- アプリケーション実行環境 の共通化
- 可能です。
- GCP GCE の Guest OS は通常の Linux を指定できるため、次の機能を利用することができます。
- Debian
- systemd や cron
- SSH
- Git
- Nginx
- Docker
- Node.js
- GCP GCE の Guest OS は通常の Linux を指定できるため、次の機能を利用することができます。
- 可能です。
AWS EC2
- 永続的な無料枠運用
- 不可能です。
- 2025年7月15日以降に作成された新規アカウントでは、無料プランは最大6か月間、または無料クレジットを使い切るまで利用できます。
- 新規利用者には100ドル分のクレジットが付与され、アクティビティを完了することで最大100ドルのクレジットを獲得できます。(クレジット)
- ただし、無料枠で利用できるのは6か月間またはクレジット残高がなくなるまでです。(無料プランの制限事項)
- 不可能です。
- RAG要件
- 満たすことができます。
- アプリケーション実行環境 の共通化
- 可能です。
- AWS EC2 の Guest OS は通常の Linux を指定できるため、GCP GCE と同じ構成にすることができます。
- 可能です。
Azure Virtual Machine
- 永続的な無料枠運用
- 不可能です。
- Azure Virtual Machine には Always free のサービスも存在しますが、Linux Virtual Machines の無料枠は12か月間に限定されています。(無料サービス)
- 不可能です。
- RAG要件
- 満たすことができます。
- アプリケーション実行環境 の共通化
- 可能です。
- Azure Virtual Machine の Guest OS は通常の Linux を指定できるため、GCP GCE と同じ構成にすることができます。
- 可能です。
Cloudflare Workers
- 永続的な無料枠運用
- 可能ですが制限があります。(プラットフォームの価格設定)
- RAG要件
- 満たす事が出来ません。
- この時点では、
エンベディングを実行する推論は onnxruntime-node または onnxruntime-web を想定していました。- onnxruntime-node
- Linux や Windows のネイティブライブラリに依存します。
- Cloudflare Workers は V8 Isolate を中心とした独自ランタイムで、一般的な Linux や Node.js を提供するサービスではありません。
- つまり、Cloudflare Workers 上に onnxruntime-node を単純に移植できないということです。(セキュリティモデル)
- onnxruntime-web
- パイプラインロード と
エンベディングにかかる処理時間を考慮すると Workers Free のスペックでは現実的ではありません。
- パイプラインロード と
- onnxruntime-node
- また
ONNXモデルは、model.onnx(非量子化) または model_quantized.onnx(量子化) を想定していました。- Cloudflare R2 を使用すれば外部ストレージは使用可能です。
- 但し、R2を使い始める際には R2サブスクリプションの有効化(checkout flow) が必要です。(Cloudflare R2サブスクリプション)
- 要するに 完全無料 というわけではありません。(Cloudflare R2の価格)
- この時点では、
- 満たす事が出来ません。
- アプリケーション実行環境 の共通化
- 不可能です。
- Docker
- 詳細は プラットフォームごとの Docker 導入対応 を参照してください。
- Node.js
- Cloudflare Workers には Node.js互換API がありますが、完全な Node.jsランタイム との互換性を保証するものではありません。(Node.jsとの互換性)
- Docker
- 不可能です。
技術スタック
Guest OS
Guest OS は Debian 12.x としました。(GCE オペレーティング システムの詳細)
Debian とした理由は GCE(e2-micro) で利用可能な OSイメージ の中で、最も軽量であり1GB の RAM 容量でも問題なく稼働できるからです。
Container
Docker としました。
アプリケーション実行環境
プログラミング言語
プログラミング言語は JavaScript (ES Modules) としました。
選定した理由を以下に記載します。
- Java
- 私の経験値が最も高い Java は、1GB の RAM 容量を考慮すると、APサーバー ではなく
JDK HttpServerを利用した構成が想定されます。 - そうなると目的が GCP GCE 上で Java を動かす事になりかねないため、除外しました。
- 私の経験値が最も高い Java は、1GB の RAM 容量を考慮すると、APサーバー ではなく
- JavaScript (ES Modules)
- Node.js と Express で 本機能 に必要な エンドポイント層 を小さな構成で実装できます。
- その分、限られた RAM の容量は
推論に割り当てられる想定です。 - かつ、TypeScript への移行も可能です。
- Go
- メモリ消費量 と 処理速度 を考えると最有力候補です。
- しかし、
推論に使用する ONNX Runtime 公式の API が提供されていないため、除外しました。
- Python
- 理由は未経験であることと、そもそもの目的が RAGアプリケーション の構築であって Python の習得では無いことから除外しました。
ランタイム
Node.js としました。
Webアプリケーションフレームワーク
Express としました。
ワーカースレッド
Node.js の node:worker_threads としました。
AIモデル
量子化された ONNXモデル model_quantized.onnx としました。
連携する生成AIモデル
gemini-2.5-flash としました。
ただし今後、他の生成AIと比較検討をしていきたいと考えています。
用語解説
| 用語 | 役割と意味 |
|---|---|
共有コア |
複数のVMインスタンスで物理CPUの処理時間を共有する方式。 |
バースト型 |
通常時は一定のCPU性能(ベースライン)で動作し、必要なときだけ一時的にCPU性能を引き上げる方式。 |
GB と GiB |
GB は10進数でRAMの容量を表します。1GB = 1,000,000,000 bytes GiB は2進数でRAMの容量を表します。1GiB = 1,073,741,824 bytes |
| エージェント処理 | 生成AIが単に質問へ1回回答するだけではなく 目的を達成するために処理手順を考え、必要なツールを選択・実行し、その結果を確認して次の処理を判断する ような処理方式です。(エージェント処理) |
| コンテキストウィンドウ | 生成AIが 1回の処理で参照できる情報量の上限 です。 システム指示、ユーザーの質問、会話履歴、RAGで検索した文書、Function Calling の定義や結果などがコンテキストを消費します。 |
| トークン | 生成AIが文章などを処理する際の データ量の基本単位 です。 文字数や単語数そのものではなく、文字・単語・単語の一部などに分割して処理します。(トークン) |
| 推論制御 | モデルが回答を生成する前に、どの程度のリソースを推論・検討に使用するかを制御する仕組み です。 単純な分類や抽出では推論量を抑えて速度・コストを優先し、複雑な設計や判断では推論量を増やして回答品質を優先するといった使い分けをします。(推論制御) |
| reasoning_effort |
モデルが問題を考えるために使用する推論量を調整する設定 です。 値を低くすると一般に速度とトークン消費を抑え、高くするとより複雑な検討に計算資源を使用します。(reasoning_effort) |
| Thinking Budget | モデルが回答を生成する際に 推論(Thinking)へ使用するトークン数の目安を指定する仕組み です。thinkingBudget の値を小さくすると推論量を抑えて応答速度やコストを優先し、大きくするとより多くの推論を行わせて複雑な問題への回答品質を高めることができます。(Gemini の思考) |
| Function Calling | 生成AIとアプリケーションの 外部機能を接続する仕組み です。 アプリケーションが利用可能な関数名・説明・引数をモデルへ提示すると、モデルは質問に応じて「どの関数を、どの引数で呼ぶべきか」を返します。 その情報を元にアプリケーションがDB検索、Web API、RAG検索などを実行し、結果を再びモデルへ渡せます。 (Function Calling) |
| Structured Outputs | モデルの回答を自由形式の文章ではなく、指定した JSON Schema などの構造に従わせる仕組み です。 Function Calling が「外部機能を呼び出す」ための仕組みなのに対し、Structured Outputs は主に「モデルから受け取るデータ形式を固定する」ための仕組みです。 (Structured Outputs) |
| キャッシュ | 同一または共通部分の大きい入力を繰り返しモデルへ送信するとき、以前処理した入力を再利用して処理時間や料金を削減する仕組み です。(キャッシュ) |
| Prompt Caching | 複数のリクエストで 共通するプロンプトの先頭部分(prefix)をキャッシュして再利用する仕組み です。 GPT-5 mini を含む対応モデルでは、対象となるリクエストに対してキャッシュ処理が自動的に行われます。 キャッシュがヒットしたトークンは cached_tokens として確認でき、通常の入力トークンより安い Cached Input 料金が適用されます。 (Prompt Caching) |
| Context Caching |
繰り返し利用する入力コンテキストをキャッシュし、後続のリクエストで再利用する仕組み です。 Gemini 2.5 Flash の Implicit Caching はデフォルトで有効で、最低2,048入力トークンから対象となります。 (Context Caching) |
| プロバイダー側文書検索 | RAGで必要となる 文書の保存、分割(Chunking)、エンベディング、インデックス作成、検索などを生成AIプロバイダー側のサービスとして提供する仕組み です。GPT-5 mini では File Search が Vector Store を検索します。 Gemini 2.5 Flash では File Search が文書を取り込み、分割・インデックス化してRAG検索を行います。 |
| File Search (Vector Store) |
プロバイダー管理型のRAG/文書検索機能 です。 検索対象となるファイルを Vector Store に登録すると、OpenAI側で文書を自動的に 分割(Chunking)、エンベディング、インデックス化 します。(Vector Store) |
| File Search (File Search Store) |
プロバイダー管理型のRAG/文書検索機能 です。 文書を File Search Store に取り込むと、Google側で文書を分割(Chunking)、エンベディング、インデックス化します。(File Search Store) |
| 知識カットオフ | モデルが学習時に取り込んだ知識についての 基準となる最終時点 です。(知識カットオフ) |
| キャッシュ済み入力 | 入力トークンのうち、以前処理した内容がキャッシュにヒットし、通常の入力より安い料金で処理される部分 です。 (キャッシュ済み入力) |
まとめ
第三段では ホスティング環境 とした理由と、コンポーネント図 とした理由を説明しました。
第四段記事は、選定した プラットフォーム で 推論 を実行する技術スタックの説明を
課題一覧 の 課題No.2 ローカルAIモデルの選定 と紐付けて説明する予定です。
おわりに
2026年1月23日、専門チャット検索機能を GCP GCE 上に公開した頃
Oracle Cloud OCI の無料枠を調べたところ、少し残念な気分になりました。(Oracle Cloud OCI の無料のリソース)
なぜなら、そこには
- CPU: 最大2 OCPU
- RAM: 最大12GB
- Disk: 最大200GB Block Volume
と記載されていたからです。(笑)
しかし、私は GCP GCE(e2-micro) にして良かったと思う事の方が多いです。
理由は、限られた リソース で 本機能 を安定稼働させるため onnxruntime-node や ONNXモデル(量子化) の存在を知ったからです。
node:worker_threads の導入も、処理速度向上が目的ではなく、エンベディング によるCPU負荷の高い処理によって
メインスレッドのイベントループが長時間占有されることを避けるために導入しました。
つまり、 GCP GCE(e2-micro) の限られた リソース のおかげで 本機能 を安定稼働させるための 学び ができたと考えています。


