
近年、組織独自のワークフローをコードで表現し、社内メンバーだけが利用できる インターナル Web アプリ を開発するケースが増えています。特に生成 AI やデータ基盤を活用した業務自動化では、汎用 SaaS では実装しにくい細かな要件を満たすために、JavaScript フレームワークを用いた自前開発 が有効です。
社内アプリ開発向けフレームワークが注目されている背景
社内アプリ開発のためのJavaScriptフレームワークが注目されている背景として、業務AIアプリとBI as Codeの2つの潮流があります。
業務AIアプリ
大規模言語モデル (LLM) の発展は、毎日の業務の効率化・自動化に寄与する大きな可能性を示唆しています。汎用的なSaaSでは、各社独自のワークフローは例外として扱われ、毎日の業務の隅々までソリューションが行き届いているとは言い難い状況にあります。対してビジネスロジックにAIを用いるAIアプリでは、これまで人間の判断が介在していたような複雑な処理をプログラムで実行することができるようになります。
業務向けのAIアプリを作るなら、コードベースの自前開発は非常に有効な手段です。コードで開発することで、複雑な処理や細やかなカスタマイズが可能で、取り残された業務領域を自動化するニーズに完璧にフィットします。
BI as Code
BI as Code (Business Intelligence as Code) とは、これまでローコードのセルフサービス型SaaSで構築していたBIダッシュボードを、コードによって開発・運用しようという潮流です。なぜ、今までローコードで出来ていたことをわざわざコードベースに転換する必要があるのでしょうか?
前提として、BIダッシュボードを実現するには、以下の3つのデータレイヤーを構築する必要があります。
- データコネクター … データソースとBIダッシュボードの繋ぎこみ
- データモデリング … データソースからやってくるデータスキーマのモデル化と変形
- データプレゼンテーション … モデル化したデータを表示する
このうちデータプレゼンテーションの部分は確かにセルフサービス型BIで、現場のユーザーであってもカスタマイズすることができるようになりました。しかし依然としてデータコネクターとデータモデリングの部分はSQLやDML言語のコードが登場することが多く、思った以上にメンテナス工数がかさんでしまうことがよくあります。また、データの流通量は爆発的な増加傾向が続いており、むしろBIにまつわるものを全てコード管理した方がむしろ運用の面ではコストが低いのではないか?というのがBI as Codeの立場です。
Next.js + AI SDK by Vercel: AIアプリ開発に最適なフルスタックフレームワーク
概要
Next.jsは言わずと知れたReactのフルスタックフレームワークです。主にWebアプリのフロントエンドとバックエンドを一つのフレームワークで完結することができ、サーバーサイドレンダリング (SSR) が可能なため、SEOに優れたWebサイトのためのフレームワークとして認知されていると思います。
しかしそれだけではありません。SSRができるということはサーバーサイドのNode.jsランタイムを使うことができるということです。これはAIアプリとの相性がとてもよく、Next.jsのAPIルートを使用してAI APIへのリクエストをラップすることで、AI APIのシークレットキーをブラウザに対して秘匿することができます。この特徴をレバレッジするのがAI SDK by Vercelです。
AI SDK by Vercelは、AIアプリを開発するためのツールキットで、OpenAI・Anthropic・Googleなど複数のLLMプロバイダーのAPIの仕様の違いを吸収し、AIアプリのフロントエンドロジックで使うさまざまなパターンをReact hookとして提供しています。これにより、開発者は迅速にAIアプリの開発をスタートすることができます。特に、AIアプリ開発において扱いが非常に難しいストリーミング処理を、サーバーサイド向けもクライアントサイド向けも便利な関数を提供してくれています。
実装例
Next.js + AI SDK by Vercelを組み合わせたAIアプリの開発は非常にシンプルです。以下の2ステップで基本的な機能を実現できます。
- APIルートでAI APIのストリーミング処理用のエンドポイントを用意する
- 1のエンドポイントを
useChat
でフロントエンドからコールする
// 1. API route for AI
import { openai } from '@ai-sdk/openai';
import { streamText } from 'ai';
export async function POST(req: Request) {
const { messages } = await req.json();
const result = streamText({
model: openai('gpt-4o'),
messages,
});
return result.toDataStreamResponse();
}
// 2. Frontend
'use client';
import { useChat } from '@ai-sdk/react';
export default function Chat() {
const { messages, input, handleInputChange, handleSubmit } = useChat();
return (
<div className="flex flex-col w-full max-w-md py-24 mx-auto stretch">
{messages.map(message => (
<div key={message.id} className="whitespace-pre-wrap">
{message.role === 'user' ? 'User: ' : 'AI: '}
{message.parts.map((part, i) => {
switch (part.type) {
case 'text':
return <div key={`${message.id}-${i}`}>{part.text}</div>;
}
})}
</div>
))}
<form onSubmit={handleSubmit}>
<input
className="fixed dark:bg-zinc-900 bottom-0 w-full max-w-md p-2 mb-8 border border-zinc-300 dark:border-zinc-800 rounded shadow-xl"
value={input}
placeholder="Say something..."
onChange={handleInputChange}
/>
</form>
</div>
);
}
社内利用でのメリット(Next.js + AI SDK by Vercel)
-
フロントエンドとバックエンドを 1 つのリポジトリで管理できる
React UI と API ルートが同居するため、フロントエンド・バックエンドの担当を厳密に分けなくても開発が進みます。ドメイン知識を持つメンバーがそのまま API 実装や LLM ラッパーまで触れ、レビュー対象が減ることで開発サイクルが高速化します。
-
シークレットキーや内部 API を安全に隠蔽
AI SDK は Next.js のサーバーコンポーネント/API ルート上でストリーミング処理をラップするため、OpenAI などの鍵をブラウザに曝さずに済みます。SSO トークンや社内 API も同じレイヤーで集約管理でき、クライアント側の情報漏えいリスクを最小化できます
-
ISR・Edge Functions でコスト最適化
更新頻度の低いレポートページは Incremental Static Regeneration、低レイテンシを要求する AI チャットは Edge Runtime と使い分けられるため、同じコードベースでパフォーマンスとインフラコストを両立できます。
注意点と選定ポイント
Next.js は「コードとインフラを 1 か所に集約できること」と「LLM ストリーミングを安全に実装できること」が社内利用最大の利点です。Evidence や Observable がデータ可視化に特化する一方、Next.js は 業務ロジック・認証・AI 推論・高度 UI を 1 つのアプリに統合したいシーンで真価を発揮します。
一方で、Vercelではなく自前のインフラにデプロイするためには、インフラ構成に合わせてビルドをカスマイズする必要があり、その点も注意が必要です。
Evidence: SQL × Markdown で実装する “BI as Code” フレームワーク
概要
Evidence は SQL と Markdown だけでデータアプリを組み立てられる OSS フレームワーク です。*.md
ファイルの中に SQL クエリをインラインで書き、その結果を <LineChart>
や <DataTable>
などのコンポーネントにバインドするだけでダッシュボードやレポートを生成できます。ページは SSG / SSR どちらにも対応し、Git でバージョン管理できるため “Infrastructure as Code” と同じ運用フローで BI as Code を実現できます。
BigQuery・Snowflake・PostgreSQL など主要 DWH へのコネクターを公式でサポートしており、VS Code 拡張も用意されているため分析チームだけで完結した開発体験を得られます。
また、1 ファイルに 説明文・SQL・可視化 が同居するため見通しがよく、エンジニアでないセールスやマーケティング部門のメンバーでも内容を理解することができます。クエリ名を ${ }
で参照すればクエリチェーンも書けるので、ETL 的な前処理も Markdown 内で完結します。
実装例
# 今月の日次売上推移
```sql sales_by_day
SELECT
DATE_TRUNC('day', order_time) AS day,
SUM(total_amount) AS sales
FROM warehouse.orders
WHERE order_time >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY 1
ORDER BY 1
```
売上合計: **${formatCurrency(total_sales)}**
社内利用でのメリット
- 小規模スタートアップでもすぐ立ち上げられる
Node.js ベースで
npx create-evidence@latest
から数分で雛形が出来上がり、Vercel・Netlify・Cloudflare Pages など静的ホスティングにそのままデプロイできます。 - SQL が書ければフルスタック不要 React/Svelte の知識がなくてもダッシュボードを量産でき、データチーム主導で開発サイクルを回せます。
注意点と選定ポイント
クエリはビルド時 or 事前レンダリング時に実行されるため、ミリ秒単位で更新が必要なリアルタイム KPI には不向きです。
React など自由度の高い UI を要求する場合は Next.js で外部チャートライブラリを直接使う構成の方が自由度があります。
逆に「SQL 主導で定型レポートを素早く量産したい」ケースには Evidence が最もシンプルです。
Observable: ノートブック的開発体験でインタラクティブなデータアプリを構築
概要
Observable は 有名なインタラクティブ・ノートブックですが、近年は Observable Framework(OSS)を中心に “データアプリ” をコードベースで構築できるプラットフォームへ進化しています。JavaScript/TypeScript に加えて SQL・Python・R など多言語のローダーを組み合わせ、セルが依存グラフで自動再計算されるため、宣言的に UI とデータ変換を記述できます。生成されたサイトは静的にビルドされるため超高速にロードでき、Git で管理して Vercel・Netlify などへデプロイするワークフローが公式に案内されています。
実装例
// cells/notebook.js — Framework 1.13 以降
import * as Plot from "@observablehq/plot";
import { sql } from "@observablehq/framework/sql";
viewof metric = Inputs.select(["sales", "orders"], {label: "指標"})
data = sql`
SELECT DATE_TRUNC('day', order_time) AS day,
SUM(${metric}) AS value
FROM warehouse.orders
WHERE order_time >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY 1
ORDER BY 1
`
chart = Plot.line(data, {x: "day", y: "value"})
セル metric
を切り替えるだけで後続セルが自動再計算され、グラフが即時更新されます。この “宣言的リアクティブ” は LLM によるデータ探索補助とも相性が良く、分析フローをドキュメンテーションとして残す用途にも適しています。
社内利用でのメリット
-
探索的データ分析とドキュメントの両立
ノートブック形式で試行錯誤 → Framework で静的サイトとしてデプロイ、という流れで分析メモがそのまま社内ポータルになります。
-
D3/Observable Plot を筆頭とする高度な可視化 が標準装備。LLM 推論結果をインタラクティブに可視化する AI アプリも容易に作れます。
-
DuckDB-Wasm 公式サポート(v1.13〜)により、小〜中規模データならブラウザ内で完結できるためバックエンドの運用負荷がゼロ。
注意点と選定ポイント
- セルの依存関係が複雑になると可読性が落ちる ため、大規模アプリではディレクトリ分割や命名規約が必須。
- Observable Cloud の廃止に伴い、スケジュール再ビルドや Secrets など一部マネージド機能は他サービスで代替する必要があります。
- 「非エンジニアが日常的にノートをいじりたい」「高度なデータ可視化を対話的に行いたい」場合にベストフィット。一方、ユーザー管理や RBAC といった Web アプリとしての統合機能は Next.js など他フレームワークの方が豊富です。
まとめ
フレームワーク | 主な強み | 代表的ユースケース |
---|---|---|
Next.js + AI SDK | フルスタック + LLM の一体開発、認証・RBAC 連携が容易 | 機密データを扱う社内 AI ワークフロー、業務アプリ |
Evidence | SQL × Markdown だけでダッシュボード生成、Git 運用に最適化 | 定型レポート・経営指標の可視化、数百ページ規模の BI サイト |
Observable | セルベースのリアクティブ UI と高機能可視化、探索的分析に強い | データ探索ポータル、AI 生成結果の実験・共有 |
自社のチーム構成と目的に合わせて選定することで、開発スピードと運用コストの最適なバランスを取ることができます。