はじめに
Google Apps Script（GAS）とスプレッドシートで社内ツールを作るのは非常に簡単で便利です。
しかし、その便利さゆえに以下のような課題を感じたことはないでしょうか？
- 編集者が増えると同時編集によるデータ競合が発生しやすい
- スプレッドシートの肥大化により、動作が重くなる・開くのが遅くなる
- データ表示の自由度が乏しく、スマホ表示などでレイアウトが崩れる
- 同じようなGASスクリプトが量産され、運用が属人化・煩雑に
「いきなり全部作り直すのはハードルが高いけれど、少しずつモダン化していきたい」
そんなニーズに応える構成として、本記事では GAS × Supabase × Next.js × Qiita API を活用した段階的DXの手法を紹介します。
特に、Qiitaの公開APIと連携し、社内ナレッジや技術情報を可視化・分析する仕組みを通じて、既存のGAS文化からモダンWebアプリへの進化の一例を解説していきます。
この構成の特徴と目的
| 特徴 | 説明 |
|---|---|
| スプレッドシート文化を尊重 | いきなり全廃するのではなく、GASと連携しながら少しずつAPI・DBへと移行できる |
| スモールスタート可能 | フロントはNext.jsで作りつつ、バックエンドはSupabase + GASで小さく始められる |
| 社内ナレッジの集約と見える化 | Qiita投稿情報を活用して、技術KPI・活動の可視化・分析が行える |
| 権限・認証制御も実装可能 | SupabaseのAuthやRLSでロール別の表示・編集制御ができる |
技術スタック全体像
| レイヤー | 技術 | 用途 |
|---|---|---|
| UI | Next.js | SPAによるフロントエンド。ダッシュボードや投稿一覧の表示など |
| API | API Routes (Next.js) | Qiita APIやSupabaseとの中継処理 |
| DB | Supabase（PostgreSQL） | 投稿情報の保存・統計計算・ユーザーごとの集計管理 |
| バッチ処理 | Google Apps Script | Qiita APIと連携して定期的にデータ取得・DB登録 |
ユースケース例：Qiita APIを活用した投稿ダッシュボードの構築
Before：よくある現場課題
- Qiitaでの社内メンバーの活動が「見えない」「把握できない」
- 投稿数・反応（LGTMなど）を手動で確認し、スプレッドシートへ転記
- 集計やグラフ作成に時間がかかる・属人化する
After：自動取得・自動集計・ダッシュボード表示へ
- GASがQiita APIから毎日投稿を自動取得
- Supabaseに保存、Next.jsでリアルタイム表示
- メンバーごとのKPI進捗やタグ別傾向も把握可能に
GASの定期実行コード（Qiita投稿データ → Supabaseへ保存）
function fetchQiitaData() {
const url = 'https://qiita.com/api/v2/users/your_user_id/items';
const response = UrlFetchApp.fetch(url);
const items = JSON.parse(response.getContentText());
items.forEach(item => {
const payload = {
id: item.id,
title: item.title,
created_at: item.created_at,
likes_count: item.likes_count
};
UrlFetchApp.fetch('https://your-project.supabase.co/rest/v1/qiita_posts', {
method: 'post',
headers: {
'apikey': 'YOUR_SUPABASE_API_KEY',
'Authorization': 'Bearer YOUR_SUPABASE_API_KEY',
'Content-Type': 'application/json'
},
payload: JSON.stringify(payload)
});
});
}
Supabase側のDB設計：型付きテーブル例
create table qiita_posts (
id text primary key,
title text not null,
created_at timestamptz,
likes_count integer,
tags jsonb,
user_id text
);
このように型付きで設計することで、BIツール連携やSQLでの高度な集計も可能になります。
また、RLS（Row Level Security）を併用することで、メンバー自身のデータだけを閲覧できるように制限することもできます。
Next.js（型付き表示）のコード抜粋
import useSWR from 'swr'
const fetcher = (url: string) => fetch(url).then(res => res.json())
export default function Dashboard() {
const { data, error } = useSWR('/api/qiita', fetcher)
if (error) return <div>Failed to load</div>
if (!data) return <div>Loading...</div>
return (
<div className="p-6">
<h1 className="text-2xl font-bold mb-4">Qiita投稿ダッシュボード</h1>
<ul>
{data.map((post: any) => (
<li key={post.id} className="mb-2">
<strong>{post.title}</strong>（👍 {post.likes_count}）
</li>
))}
</ul>
</div>
)
}
システム構成図（Mermaid）
おわりに
GASとスプレッドシートは簡便さとスピード感に優れていますが、限界もあります。
本記事で紹介したように、GASを起点にSupabase＋Next.jsを組み合わせることで、徐々にモダンなアーキテクチャへ移行する道筋が見えてきます。
特にQiita APIなどの外部ナレッジとの連携は、単なる「投稿の可視化」にとどまらず、技術ブランディング、教育支援、組織の学習文化の醸成にもつながる重要な取り組みです。
今後はさらに以下のような拡張も検討できます：
- Slack通知連携（毎週の投稿サマリを自動配信）
- 記事ごとの社内コメント機能（ナレッジの蓄積）
- 執筆ランキング、タグ別分析、KPIトラッキング
「まずはGASから」「でもそろそろスプレッドシート運用がきつい」
そんなあなたに、今回の構成が一歩先の選択肢になれば幸いです。