はじめに
「AIを使ったアプリを作りたい」と思ったら、ChatGPTやClaudeのようなAIサービスが使用している基盤モデル（LLMを含む）を、各社が提供するAPIを通じて利用するのが一般的です。
| AIサービス名 | 開発元 | 内部で使われている基盤モデル（例） |
|---|---|---|
| ChatGPT | OpenAI | GPT-5.x 系、oシリーズ など |
| Claude | Anthropic | Claude Opus 4.6 / Sonnet 4.5 / Haiku など |
| Gemini | Gemini 2.5 Pro / 2.5 Flash など |
API（Application Programming Interface）は、プログラムから外部サービスの力を借りるための窓口です。開発者はAPI経由で、文章の生成・要約・分類といったLLMの力を自分のアプリに組み込めます。
LLMを「使う」方法を整理
では、このAPIを使ってAIアプリを作るにはどうすればよいのでしょうか。
方法は一つではなく、大きく分けると3つの方向性があります。
- 直接実装: APIを自分のコードから直接呼び出し、すべて自力で組む
- フレームワーク活用: LangChainやMastraなどに共通処理を任せつつ、コードで組む
- プラットフォーム活用: DifyなどでGUI中心（ノーコード／ローコード）に構築し、必要ならAPI連携で組み込む
ここでの選定基準は、LLMアプリ開発で自分たちがどこまで責任を持つかです。
具体的には、自由度（何でもできる）と立ち上げ速度（すぐ動く）、そして運用のしやすさ（改善を回せる）のトレードオフで、選択肢が変わります。
本記事では、この3つの方向性それぞれの向き不向きを整理します。
なお、本記事は「各社が提供するAPIを通じてLLMを利用する」前提で整理しています。LlamaやMistralなどのオープンソースLLMを自社サーバーにインストールして動かす「セルフホスト」や、自社独自のLLMを一から訓練するアプローチ、
各社APIを直接呼ぶ以外に、AWS Bedrockのように複数LLMへの窓口を一本化するマネージドサービス経由で呼ぶ方法もありますが、それらは本記事では触れません。
※AWS Bedrockの使い方は以下
3つのアプローチ一覧
| # | 方向性 | アプローチ | 代表例 | 一言で言うと |
|---|---|---|---|---|
| 1 | 直接実装 | すべて自力で組む | - | 最もシンプル、最も自由 |
| 2 | フレームワーク活用 | 共通処理を任せつつコードで組む | LangChain, Mastra, Vercel AI SDK | 柔軟に組み立てる（Python / TS） |
| 3 | プラットフォーム活用 | ビジュアル + Web公開 + API | Dify, Flowise | GUIで作る→そのまま公開、必要ならAPI連携 |
1. 直接実装 ── すべて自力で組む
概要
OpenAIやAnthropicなどのLLM開発元が公式に用意しているAPIを、自分のコードから直接呼び出す方法。
他のアプローチ（LangChain、Mastra、Dify等）も内部的には同じAPIを呼んでいますが、このアプローチはフレームワークやプラットフォームを一切挟まず、すべてを自分のコードで書くことを対象としています。
- 自分で実装するもの: リクエスト/レスポンス処理、エラーハンドリング、リトライ、レート制限、会話履歴管理、ログ、キャッシュ…すべて。
- 肩代わりしてくれるもの: なし。だからこそ最も自由で、最も理解しやすい。
得意
- API仕様さえ読めば始められる。共通部品等の使い方を知る必要がないので学習コストが最も低い（いや極端かｗ）
- リクエスト/レスポンスの全てを制御できる。自由度が最大
不得意
- RAG、エージェント、ワークフローなど複雑な処理はすべて自前実装になる
- リトライ、レート制限対策、ログ、モニタリングなど運用の仕組みも自前
典型ユースケース
既存のWebアプリに「問い合わせ内容を自動分類する機能」を1つだけ追加する。
採用の目安
エンジニアがLLMの仕組みを学びたいとき、またはフレームワークの制約を避けたいシンプルな用途。
代表例
無（自分で組むので）
2. フレームワーク活用 ── 共通処理を任せつつコードで組む
概要
LangChainやMastraなどのフレームワークを使い、LLMの呼び出し・プロンプト管理・RAG・エージェントなどをコードで組み立てる方法。LLM呼び出しの定型処理（プロンプトテンプレート、出力の整形、処理の連結、各社APIの差異吸収など）をフレームワークが用意した部品で書ける。
- 自分で実装するもの: アプリケーションのコード全体。ただし定型処理はフレームワークの部品を組み合わせて書く。
- 肩代わりしてくれるもの: LLM呼び出しの抽象化、RAGパイプラインの構築支援、エージェント機能、各社APIの差異吸収。
得意
- RAG、エージェント、マルチステップ処理など複雑なAI処理をコードで柔軟に組める
- フレームワークが定型処理を肩代わりしてくれるので、自由度は高いまま、実装を加速できる
不得意
- フレームワーク独自の抽象化を学ぶ必要があり、学習コストが中〜高
- ログ・トレーシング・モニタリングは別途構築が必要（LangSmith等）
典型ユースケース
- 社内ドキュメントを検索して質問に答えるRAGチャットボットを、Pythonで構築する
- Next.jsで構築中のWebアプリに、ストリーミング対応のAIチャット機能を組み込む
採用の目安
RAGやエージェントなど複雑なAI処理を自前のコードで柔軟に制御したい場合。チームの主言語で選ぶ。
- Pythonチーム → LangChain など。データ分析・機械学習エコシステムとの相性が良く、OSSの選択肢が豊富
- TypeScriptチーム → Mastra、Vercel AI SDK など。Next.js等のWebフレームワークとの統合がシームレスで、フロント〜バックエンドを一貫開発できる
代表例
Mastraの使い方について記事執筆中です。
以下もご参照ください。
3. プラットフォーム活用 ── ビジュアル+API（Dify等）
概要
プラットフォーム型は、プロンプトやRAG、分岐を含む処理フローをGUIで組み立て、まず動く形を作るのが速いのが特徴。
さらにDifyの場合、作ったアプリはWebアプリとしてURL共有でそのまま公開でき、同じものを埋め込みやAPI連携に展開できる。
自分で実装するもの: 基本的にはGUI操作のみ。ただし既存システムとの連携部分はAPI呼び出しのコードが必要になることがある。
肩代わりしてくれるもの: LLM呼び出し、RAGパイプライン、ワークフロー構築、エージェント、利用状況の記録・監視、複数人での同時編集…ほぼすべて。
得意
- 「PoCを早く回したい」「まず社内に触ってもらいたい」ケースに強い
- コーディング不要で始められ、非エンジニアも含むチームでの協業に向く
- RAGやワークフローがGUI標準搭載で、試作から本番運用まで素早く進められる
- ログ・モニタリング・バージョン管理など運用機能が最初から揃っている
不得意
- GUIで表現できる範囲を超える複雑なロジックは実装しづらい
- 複雑な業務ロジックや認証・権限・既存DBとの密結合が増えるほど、GUI外のコード実装が必要になり、「コーディング不要」では済まなくなっていく
- プラットフォームへの依存度が高く、乗り換えコストが大きい
典型ユースケース
社内ドキュメントを基にしたFAQチャットボットを、非エンジニアも交えたチームで2週間以内に本番投入する。
採用の目安
素早く形にしたい場合、非エンジニアとの協業が必要な場合、エンタープライズ要件（セルフホスト・SSO等）がある場合。
代表例
Difyの使い方について記事執筆中です。
補足：その他の選択肢 ── セルフホスト（OSSモデルの自前運用）
上記3つのアプローチはいずれも「外部のAPIを使う」ことを前提としています。しかし、機密情報を外部に送信できない場合や、API利用料を大幅に抑えたい場合には、別のアプローチがあります。
セルフホストとは、LlamaやMistralなどのオープンソースLLMを自社のサーバーにインストールし、外部APIを一切使わずに運用する方式です。データが自社環境から出ないためセキュリティ要件を満たしやすい反面、GPUサーバーの調達・運用・モデル更新などの専門知識とコストが必要です。
本記事では詳しく扱いませんが、機密性・コスト・レイテンシの要件が特に強い場合は検討の価値があります。
アプローチ別 比較マトリクス
| 観点 | 直接実装 | FW活用 | PF活用 |
|---|---|---|---|
| 代表例 | OpenAI API | LangChain / Mastra | Dify |
| 言語 | 任意 | Python または TypeScript | 不要（GUI） |
| 自由度 | ★★★★★ | ★★★★★ | ★★★☆☆ |
| 立ち上げ速度 | ★★★☆☆ | ★★☆☆☆ | ★★★★★ |
| RAG | 自前実装 | ライブラリで構築 | GUI標準搭載 |
| エージェント | 自前実装 | フレームワーク提供 | GUI標準搭載 |
| チーム協業 | △ | △ | ◎ |
| セルフホスト | ─ | ○ | ○（Dify等） |
| 運用・監視 | 自前 | 別途構築 | 標準搭載 |
| エンタープライズ | △ | ○ | ◎（Dify等） |
どう選ぶか？ ─ 判断フローチャート
LLMアプリを作りたい
│
├─ コードを書きたくない
│ └─ 3. PF活用：ビジュアル+API（Dify等）
│
└─ コードで制御したい
├─ TypeScript/Webアプリ中心 → 2. FW活用（Mastra等）
├─ Python/データ基盤中心 → 2. FW活用（LangChain等）
└─ フレームワークなしでシンプルに → 1. 直接実装（APIを自力で呼ぶ）
まとめ ── 迷ったらどれを読めばいい？
3つのアプローチを見てきましたが、迷ったら次の基準で選ぶのが現実的です。
- 最短で試したい／非エンジニアも関わる → まずは Dify
- プロダクトに組み込む前提でコード管理したい → Mastra（TypeScript）または LangChain（Python）
- 要件が強い（機密・コスト・レイテンシ） → セルフホストも検討