Gemini Nanoで変わるWebアプリ開発〜オンデバイスAIで実現した「プライバシー保護型リーンキャンバス支援ツール」
AI(人工知能)は、今やクラウドだけのものではありません。Google Chromeに軽量かつ強力なAIモデルGemini Nanoが組み込まれたことで、サーバーを介さずブラウザ内で高度なAI処理を行う「Built-in AI(組み込みAI)」の道が拓かれました。
本記事では、このGemini Nanoの力を最大限に活用し、事業のアイデアを練るためのフレームワーク「リーンキャンバス」の作成・添削を支援するWebアプリの開発秘話と、そこで実現した新しいユーザー体験を、技術的なポイントを含めてご紹介します。
開発動機:リーンキャンバス作成のストレスからの解放
このアプリを作り始めた動機は、とてもシンプルでした。リーンキャンバスを書くのが面倒だったからです。
リーンキャンバスとは、複雑なビジネスアイデアの核となる要素をたった1枚の紙に凝縮するためのフレームワークです。事業の成否を分ける「顧客の問題」や「独自の価値提案」など12の重要要素に絞り込み、仮説を可視化することで、曖昧だったアイデアを具体化し、最もリスクの高い検証ポイントを明確にできます。これは、リーン・スタートアップの概念に基づき考案されたもので、新規事業開発やスタートアップのアイデア整理に特に有用です。
このリーンキャンバスは優れたフレームワークですが、PowerPointやGoogleスライドでキャンバスを用意するのは手間がかかり、また次の問題がありました。
各要素のマスのサイズを気にしながら文章量を調整する必要がある
書いている途中で構造を変えたくなっても編集がしづらい
とりあえず殴り書きする、という使い方がしにくい
「思考を整理するための道具なのに、フォーマットに思考を縛られている」。このストレスを解消するために、Web UIで自由に書けるアプリの開発をスタートしました。

アプリの概要と機能全体像
このWebアプリは、リーンキャンバスをブラウザ上で編集し、品質チェック(ルールベース+Gemini Nano)、全体整合性レビュー、そして共有・資料化までを一気通貫で行うためのツールです。「書く」「疑う」「直す」「利用する」を同じ導線で回せるように設計されています。
リーンキャンバス支援アプリの主要機能
編集・入力支援
機能詳細:12要素グリッド表示、見出し記法などでの整形表示、ローカルストレージへの自動保存
ユーザーメリット:思考をフォーマットに縛られず、スムーズにアイデアを吐き出せる。
AI添削(セル単位)
機能詳細:ルールベースチェックと、Gemini Nanoによる指摘・改善案の提示
ユーザーメリット:記述の品質を即座にチェックし、ブラウザ内で添削を受けられる。
全体整合性チェック
機能詳細:12要素間の矛盾点やリスクを評価し、構造化された指摘を出力
ユーザーメリット:事業の仮説が全体として成立しているかを俯瞰的に確認できる。
インポート/エクスポート
機能詳細:Markdown、PNG、PowerPoint(pptx)出力、ブラウザ印刷
ユーザーメリット:作成したキャンバスをブログ掲載用画像や共有用スライドに即座に変換できる。
画像インポート
機能詳細:デジタルツール(PowerPoint/Miro等)のスクリーンショットをOCRで解析し、各セルに自動マッピング
ユーザーメリット:既存のキャンバスを本アプリに取り込んで磨き直すことができる。
開発者向けモード
機能詳細:ルールのみ/LLMのみ/協調型のレビュー結果とプロンプトを比較できるデバッグパネル
ユーザーメリット:LLMの貢献度を検証し、プロンプトチューニングに役立てられる。



なぜ「Gemini Nano」を使ったのか?:プライバシーと速度の両立


AI添削や全体整合性チェックには生成AIを使う必要があります。一択です。しかし、問題は、どの生成AIサービスを使うかです。ここで問題になるのは、情報のセンシティビティです。
リーンキャンバスが含む情報は、事業の前提、仮説、未検証のアイデアなど、極めてセンシティブな情報です。事業計画書に近い性質を持つため、Webサービスや外部の生成AI事業者にデータを送信することに抵抗を感じるユーザーは少なくありません。
そこで、本アプリではローカルで完結する生成AIとして、Gemini Nanoを採用しました。
ChromeのGemini Nanoとは?
通常、AIを利用するには高価なクラウドGPUを契約したり、巨大なモデルを自前でホストしたり、あるいは生成AIサービスのAPIを利用したりする必要があります。しかし、ChromeのBuilt-in AIは、ユーザーのデバイスで動作するGemini Nanoを活用します。
開発者はモデルの運用を心配することなく、JavaScriptから標準APIを介してAI機能を呼び出すことが可能です。
何ができるのか?(主要なユースケース)
Chrome上でGemini Nanoを動かすことで、以下が可能となります。
リアルタイム翻訳・言語検出: ユーザーが入力したテキストをその場で翻訳したり、言語を特定してUIを最適化します。
コンテンツの自動要約: 長いブログ記事や、大量のカスタマーレビューを箇条書きでまとめます。
執筆支援: メールの下書き作成や、カジュアルな文章をフォーマルなトーンに書き換える(リライト)処理を支援します。
インテリジェントな校正: ブラウザ上で文法ミスを指摘したり、より自然な表現を提案したりします。
具体的には次のようなAPIが順次公開されています(※一部は試験運用版やオリジントライアル中)。
Summarizer API
主な役割:テキストの要約(箇条書き、ティーザー形式など)。
ステータス(Chrome 131時点):プレビュー版。
Translator API
主な役割:言語間の双方向翻訳。
ステータス(Chrome 131時点):プレビュー版。
Language Detector API
主な役割:入力テキストの言語を判定。
ステータス(Chrome 131時点):プレビュー版。
Writer / Rewriter API
主な役割:コンテンツの新規作成や、既存テキストのトーン変更。
ステータス(Chrome 131時点):試験運用中。
Prompt API
主な役割:Gemini Nanoに直接自由なプロンプトを送る汎用API。
ステータス(Chrome 131時点):拡張機能で利用可能/オリジントライアル。
Proofreader API
主な役割:文法、スペル、句読点のチェック。
ステータス(Chrome 131時点):試験運用中。
Gemini Nano選択の理由
改めて、Gemini Nanoを選択した理由をまとめると次のようになります。
究極のプライバシー保護:
データがデバイスの外(クラウド)に出ることがないため、機密性の高い情報の処理に最適です。キャンバスの内容が外部に送信されることはありません。低レイテンシ(高速応答):
サーバーとの通信が発生しないため、インターネットの速度に左右されず、結果が返ってきます。リーンキャンバスのような思考ツールにおいて、「待たされ感がない」UXは非常に重要です。コスト効率:
クラウドAIのようなAPI利用料が発生しないため、開発者にとってもユーザーにとっても経済的です。
ただし、Gemini Nanoを使う場合には、オンデバイスAIならではの制約(トレードオフ)も考慮する必要があります。主な制約は以下の3点です。
利用可能な環境の限定:
現在、Gemini Nanoはすべての環境で利用できるわけではありません。Chromeの特定のバージョン、OS(Windows/Mac/ChromeOS)、そして一定以上のスペックを持つデバイスに限定されています。このため、アプリの機能を最大限に活用できるユーザーは限られます。今回は利用者が自社社員に限定されるため、この制約は回避可能と判断しました。推論能力の制約:
クラウドで動作する大規模言語モデル(LLM)と比較して、Nanoモデルはそのサイズとデバイス上での動作という特性上、推論できる最大コンテキスト長(トークン数)や、複雑なロジック処理能力に制約があります。そのため、極めて高度なタスクや長文の処理には向いていません。リーンキャンバスはコンテキストが限定されるため、この制約が大きな問題になりません。さらに、本アプリでは、この制約を回避するため、ルールベースとNanoを組み合わせる「協調型設計」を採用しました。モデルの更新頻度:
クラウド上のLLMは頻繁にアップデートされますが、デバイスに組み込まれるNanoモデルのアップデートは、ChromeやOSの更新サイクルに依存します。最新の知識や能力が求められるタスクには、クラウドモデルの方が適している場合があります。本アプリの場合は最新知識が不要のため、十分活用可能と判断しています。
Gemini Nanoの具体的な使い方
では、具体的に、本アプリでどのようにGemin Nanoを用いたかを、もう少し深堀りしてみます。こだわった設計・実装上のポイントは以下の3点です。なお、今回はChromeのBuilt-in AIのうちのPrompt APIのみで実装しています。
a) 要素ごとのAI添削(ルール+LLMの協調型設計)
Gemini Nano単体では指摘のブレや品質の揺らぎが発生する場合があります。そこで、以下の協調型フローを採用しました。
ルールベースで最低限の品質チェック(例:文字数、空欄チェックなど)を実施
そのルール結果と本文をコンテキストとして Gemini Nano に送信
Nanoからは返却させ、構造化された指摘・改善案・スコアを取得
ルール結果とNanoの指摘をマージして最終結果を生成
これにより、無駄なLLM呼び出しを避け、指摘内容が安定し、レスポンス速度と計算資源を抑える実運用向きの設計になっています。また、原文が変わらない限り結果をキャッシュして即再表示する仕組みも取り入れました。
b) キャンバス全体の整合性チェック
セル単位では問題ない記述でも、全体で見ると「顧客セグメントと収益の流れが矛盾している」といったケースはよくあります。
このアプリでは、12要素すべてを下調べし、その結果と全文をまとめて Gemini Nano に渡すことで、「整合している点/矛盾している点/リスク」を評価させています。これにより、「それっぽく書けているが、事業として成立しているか?」を確認する強力な補助輪になります。
c) 画像インポートでのOCR+Markdown変換
画像インポートでは、Gemini NanoをOCR用途に限定して使っています。
画像モードで文字を忠実に抽出(要約・言い換えは禁止)
Gemini NanoにMarkdown形式での出力を指示(見出しと箇条書き)
JS側で正規化・ノイズ除去・表形式の吸収変換を行い、セクションに取り込む
手書き文字の認識を目的としたものではなく、PowerPointやMiroで作成したデジタルなキャンバスのスクリーンショットを取り込む用途にスコープを絞ることで、高い実用性を確保しました。
d) chrome://on-device-internals やPoCを活用し、検証を重ねながら進行
Gemini Nanoの利用可能性を検証するにあたり、Chromeに内蔵されたデバッグページである chrome://on-device-internals を活用しました。このページでは、「オンデバイス AI モデル」(Gemini Nanoなど)の状態を確認できます。

また、Gemini Nanoにプロンプトを投げて結果を確認するなどの小さなPoCを繰り返し実施し、期待する結果が得られるかを常に検証しながら開発を進めました。
開発プロセスにも生成AIをフル活用
このアプリは、機能として生成AIを組み込んでいますが、開発プロセスそのものにも生成AIを活用しています。
コンテキストは「文章」で共有する
複数の生成AIを併用する際、コンテキストの共有が課題になります。本開発では、PRD(Product Requirements Document)からDesign Docに至るまで、すべてMarkdownの文章として残す方針を取りました。これにより、どの生成AIにもそのまま渡せる共通言語を確立しました。
生成AIの使い分け
用途や得意分野に応じて、次の生成AIを使い分けました。
OpenAI Codex : 設計方針の決定、問題点の相談、リファクタリングの方向性決定などの「方針決定者」
Gemini CLI / Claude Code: 決定した方針に基づくコードの生成、実装の「実装者」
方針決定者(設計)と実装者(コード生成)を分離することで、開発の質を担保しつつ、実装スピードを上げることができました。また、利用制限(Usage Limit)対策としても有効でした。
テスト計画も先に作った
生成AIでコードを書かせる場合でも、テストは後回しにしない方がよいと考えています。
そのため、このアプリでは、
Unit Test
End-to-End Test
の両方を用意しました。
E2Eテストには Playwright を使っています。ただし、MCP(Model Context Protocol)経由ではなく、Playwrightのスクリプトを直接書く形を選びました。
理由は、
非決定性が入り込みにくい
UIが頻繁に変わるわけではない
テストを安定して回したかった
からです。
しかし、生成AIだけでは実現できない箇所もあった
生成AIで実装はほぼ行えましたが、いくつか生成AIだけでは実現できない箇所がありました。それは、正しい仕様を参照して実装する部分です。
具体的には、UIをTailwind CSSからMaterial UI (MUI) に途中で変更したのですが、MUIの仕様を理解しないまま実装を進めたため、一時、UIが大きく崩れました(実は、リーンキャンバスのレイアウトを中の文字列に応じて可変で表示させるのはそれなりに大変です)。特に、Gemini CLIの無能さには頭を抱えました。試したのは、Gemini 3.0登場以前だったので、今では解決していると期待しています。
次に、Gemini NanoのPrompt APIを用いて、画像を認識させたのですが、Geminiも他の生成AIもそれはできないと言い張ります。Geminiには、お前のところのAPIだろ!と何度も言ったのですが、無駄でした。仕方ないので、うちのCTOが用意してくれたサンプルコードを見せ、CoT (Chain-of-Thought) の形で示すことで解決を図りました。実際には、それでも間違ったコードを生成するので、この部分だけは已む無く自分でコードをいじりました。
参考: 用いた技術
用いた技術スタックは以下の通りです。これらは生成AIによる推薦に基づき、私が最終的に承認したものです。
フロントエンド
技術スタック:React + Vite, MUI + Emotion
詳細:HMR(Hot Module Replacement)とESMビルドを活用したフロントエンド基盤。CSSはMUI v7系コンポーネントとアイコンを採用したスタイルシステムで構築。
マークダウン処理
技術スタック:react-markdown, remark-gfm
詳細:キャンバス内のテキストをMarkdown表示。独自に見出し記法を太字化する前処理を実装。
データ永続化
技術スタック:ローカルストレージ(カスタムフック)
詳細:キャンバス状態を自動保存。リロード後も下書きが保持されます。
エクスポート
技術スタック:html2canvas, pptxgenjs
詳細:キャンバス領域をPNG画像化、またはpptxgenjsでpptx形式を生成し、スライドへの貼り付けに対応。ブラウザ印刷も同一導線で提供。
画像インポート
技術スタック:Prompt API + JS正規化
詳細:Gemini NanoでOCR→Markdown出力し、JSで正規化・表変換・バリデーションを行う。
UI/UX補助
技術スタック:MUI Popover, react-markdown, Backdrop/Chip/Progress
詳細:MUI Popoverとreact-markdownを使用し、書き方ヒントを表示。ステータス表示やローディングにはMUIのBackdrop、Chip、Progressを使用。
テスト/品質保証
技術スタック:Vitest + jsdom, Testing Library, Playwright, ESLint
詳細:単体テストにVitest + jsdom、UIインタラクションテストにTesting Library、E2EテストにPlaywrightを採用。静的検査としてESLint(React Hooks/Refreshルール入り)を使用。
まとめ:生成AIやLLMは使い分けの時代に
Chrome版Gemini Nanoは、AIをWebプラットフォームの基盤機能にしようとするGoogleの意欲的な試みでしょう。そして、私はこのアプリにおいて Gemini Nano が十分使えることを実感しました。
使えない環境でもルールベースで成立する設計を前提にしつつ、使える環境ではオンデバイスLLMならではのプライバシー保護と低レイテンシというメリットを最大限に活かし、ユーザー体験を大きく強化する。そのバランスを重視した結果が、このリーンキャンバス支援アプリです。
今後、Gemini Nanoが「Web標準」に近づき、より多くのブラウザやデバイスで利用可能になれば、Web開発の常識は大きく変わるでしょう。まずは開発版のChromeやオリジントライアルを活用し、「ブラウザ完結型AI」で何ができるのかを試してみてください。
