Webアプリのオフライン化を、Geminiのスキルに一言で任せる

動画: こーすけ先生のGoogle塾 YouTubeで観る

こーすけ先生は、Geminiで作ったWebアプリを、インターネットにつながらない環境でも動かす方法を、画面の実演を見せながら約15分、一人で話します。冒頭で、Gemの画面にスキルを作成する表示が出ていることに触れ、自作のスキルで実演すると予告します。

最初に置くのは、バイブコーディングの定義です。

こーすけ先生（動画 0:50）

複雑なソースコードを1行ずつ手打ちするのではなくてジェミニを始めとした対話型AIとのコミュニケーションを通じてですね、直感的にアプリケーションを試作構築する新しい開発手法

1行ずつ書く代わりに、話しながら作る。元々富士通でエンジニアをしていたこーすけ先生は、当時これがあれば、お客様にもっと早くシステムを提供できたはずだと話します。

続くのがマクロ職人の話です。職場でExcelのマクロを作っていた人が退職し、これ以上成長させられない、触れてはいけないパンドラの箱だ、と言われるようになる場面。

こーすけ先生は、そう言っている人はAIを使っていないだけで、言い訳にすぎないと言います。マクロ一式をGeminiに渡せば日本語の説明資料ができて、仕様変更も短時間でできるからです。

考え方は3つあります。直感的な指示。高速なプロトタイピング（数分、速い時は20〜30秒で、FlashやFlash-Liteは特に速いそうです）。そして、トライアンドエラーの容易さ。

1つ目の直感的な指示について、こーすけ先生はこう話します。

こーすけ先生（動画 2:52）

要はバイブスでいいんです。もう我々が魂に燃えたぎるものあるわけじゃないですか。これやりたいな、あれやりたいなっていうその熱意を伝えるだけです。

やりたいことが先にあって、その熱を伝えるところから始めます。この進め方に、私は賛成です！

そのうえで、1つ足します。試作なら、熱を伝えるだけで動くものができる。それは次の章の実演が見せてくれます。でも、仕事として任せるなら話が変わるんです。

AIに渡すのは目的だけでは足りない、と私は考えています。背景と意図まで渡して初めて、自分から生えたAIになる。

会議の結論だけ渡されて、なぜそう決まったのかが分からない仕事を想像してみてください。作業は進んでも、判断が要る所で止まります。だから渡すのは、材料・任せる範囲・終点の一組。

マクロ職人の話も、私は同じ場所で読みます。動きの説明はAIが日本語にしてくれる。そこに、なぜその作りにしたのかまで残っていれば、次に触る人はもっと迷わない。

バイブスだけで走るのは試作、意図まで渡して任せるのは仕事です。私はここに線を引きます。

あなたが今AIに頼んでいるのは、どちらでしょう？

実演に入ると、こーすけ先生はGeminiのFlashモデルを選び、Canvasをオンにして、PDFにページ番号を振るアプリをHTMLコードで作って、と頼みます。これがバイブスで伝えるということだ、と言います。

アプリができるまで、約1分。画面には、番号の位置、表記のフォーマット、サイズ、余白、表紙を飛ばす設定まで並び、50ページの申請書でプレビューも出ます。

ここから、動かして確かめる段に入ります。おかしい所を見つけた時の伝え方が、こうです。

こーすけ先生（動画 3:19）

触りながら、あ、ちょっとここおかしいなって思ったらこういったところでエラーが出ましたよ、こういったところが思ったように動きません。

伝えるのは、エラーが出た所と、思ったように動かない所です。

実際、実演の途中でPDFを作ろうとするとエラーが出ます。画面の隅に、エラーの通知と修正のボタン（動画 5:36頃）。

こーすけ先生がそのボタンで直してみせます。コンソールの内容を貼って伝える方法もあると話し、これがトライアンドエラーの容易さだと言います。

何度か試して、ページ番号を振るアプリが完成しました。

指示そのものは細かくありません。こーすけ先生は、こう言い切ります。

こーすけ先生（動画 4:34）

もう単にバイブスを伝えてるだけです。

エラーが出たら止まらず、そのまま伝えて直します。この進め方に私は賛成です。

失敗は、勇気を出して行動し、経験を得た時点で成功になる。私はそう考えています。だから最初に返すのは、反省や分析より、一歩目を出したことを祝う言葉。

職場でトラブルが出ると、まず原因探しの会議になりがちなんですよ。でもこの実演の画面では、エラーは次の指示の材料でした。

あなたは、最初のエラーが出た時、何と声をかけますか？

試作の段では、エラーが出るたびに直す往復を楽しみます。残すのは、往復を重ねてよかった手順だけにする。

ここからが本題です。できたHTMLをそのままオフライン環境へ持っていくとどうなるか、こーすけ先生はこう話します。

こーすけ先生（動画 6:27）

まずこのまま持っていった場合は動きません。

理由はコードの中にある、とこーすけ先生は話します。HTMLの冒頭に、外部のCDNを読みに行く指定が並んでいるんです。TailwindとPDFのライブラリです。

ネットにつながらない場所では読みに行けない。だから動かない。

直し方は3ステップです。HTMLをローカルに置いて、ライブラリを全部取ってきます。取ってきた物を見に行くよう、参照を書き換えます。動くかを確かめる。

そして、こう続きます。

こーすけ先生（動画 7:38）

これ毎回やるの面倒くさいじゃないですか。でそこで登場するのがスキルです。

スキルの話は次の章に回して、私はこの動かないという話で足を止めます。私にも、作ったページを見せようとして動かなかったことがあるからです。

舞台はGeminiではなく、成果物を確認する私の画面でした。JavaScriptが入ったページが動かず、ファイルを開こうとしてもダウンロード扱いになりました。原因は、確認画面のCSPという、ページで動かせるものを絞る設定。そこで、別の道で見せることにしました。

といっても、動画の話と同じ問題ではありません。動画は読みに行く先に届かない話で、私のは確認画面の制限。原因は別なんです。

それでも、2つを並べて言えることがあります。作った場所で動くことと、届けたい場所で動くことは別です。

自分の席で開けた資料が、会議室の端末で開けない。職場でも見かける場面ですよね。作っている画面で動いたという事実は、その画面で動いたという事実でしかない。相手の画面の条件まで含めて、はじめて届いたと言えると思います。

こーすけ先生の3ステップの最後が動作検証なのも、同じ向きです。

私なら、作ったら、見せる場所と同じ条件で1回動かしてから渡します。

スキルは Gem と同じように、繰り返し使えるカスタム指示です。違いは使い方にある、とこーすけ先生は話します。

こーすけ先生（8:07）

スキルはこの流れの中で使うことができます。

1つのチャットの流れで、複数のスキルを使える。ここが要点です。Gem は身につける装飾品で、スキルはこう説明されます。

こーすけ先生（8:19）

スキルというのはもう自分自身が持っているもの

動画の図によると、移行の時期は個人が2026年11月、ワークスペースが2027年3月。10月からスキルは大きく改善したとも話しています。スキルの呼び方と作り方は、Geminiのスキルの使い方を整理した記事にまとめました。

この話で私が思い出したのは、2026年1月20日の自分の投稿です。動画は Gemini のスキル、私が書いたのは Claude Code のスキル。別の道具の話です。

私の投稿（2026年1月20日）

…ClaudeCodeでA2Aしながら朝LIVEのブログ記事化するスキルを質を高めながら量産するのをやってたら、今日から10本同時生成になった。…今までのGemでやって効率化して喜んでたのが嘘のように楽。何より質が段違いに高くなった。しかも早い。…そしてやるほどエージェントとスキルがレベルアップ。…

Gem で効率化していた頃と、スキルで量産した頃を比べて、私はこう書きました。道具は違っても、向きは動画と同じです。頼むたびに説明する形から、型で持つ形へ。

ただ、移行の日付だけを追っても仕事は変わりません。私なら、Gem をそのままスキルへ移す前に、1本完璧に作ってから仕組みにして量産する。この順番を守ります。出来の悪い指示を型にしても、出来の悪い物が速く増えるだけですから。あなたが最初の1本に選ぶ仕事は何ですか？

こーすけ先生は、配布しているスキルを ZIP でアップロードして登録します。頼む場所は、Canvas でアプリを作ったのと同じチャットです。

こーすけ先生（9:49）

これを使って作成したアプリのオフライン化をよろしく

スキルの名前を指定しなくても動く、と話は続きます。

こーすけ先生（9:56）

メンションしなくても先ほどお見せした通りこのAIが文脈を自動認識して最適なスキルを勝手に発動

出てくるのは、./lib/tailwind と ./lib/pdf-lib を使う形に書き換わった index.html。フォルダは pdf-numbering-app/ の下に index.html と lib/ を置く構成で、lib の中身は PowerShell のコマンドで用意します。画面には、Windows（PowerShell）用と Mac・Linux（ターミナル）用のコマンドが並んで映るんです（動画 11:05頃）。

3ステップを毎回やるのは面倒だから、スキルに任せる。これと同じ向きの答えを、私も2026年10月31日に返しています。

私の答え（2026年10月31日）

すでにもう実際にそのやり方で記事にしてますよね。テストはいらないですその時やった。うまくできた。やり方をスキル化するとかしてそのモードを作ればいいんじゃないですか？

うまくできたやり方を、その場限りにしない。ここまでは動画と同じです。

で、私がもう一歩踏み込むのはスキルの中身。「魂は渡さない、込めるもの」という軸で私は仕事をしてきました。だから、スキルに入れるのは手順だけにしません。なぜその順なのか。どこで止めて人に聞くのか。そこまで掘ってから、実行を委ねる形にする。段取りだけを引き継いだ新人が、想定外の場面で固まるのと同じことがスキルでも起きるからです。あなたのスキルには、止まって人に聞く場所が書いてありますか？

こーすけ先生はネットを切り、ブラウザに恐竜の画面が出る状態を見せてから、index.html を開きます。

こーすけ先生（11:24）

完全にオフラインなのでもちろん繋がらないわけですね。ただ繋がらない状態でこちらのインデックスHTMLをやっても動くわけですね。

PDF のアップロード、番号の位置、ページ番号、ダウンロードまで動きます。ZIP で配布しているスキルは、中のカスタム指示も読む価値があると話しています。こーすけ先生が示すWebアプリのオフライン化の流れは、オンラインで Canvas のバイブコーディング、オンラインでスキルを使って資材を揃える、最後に運ぶ、の3つです。

こーすけ先生（12:27）

その資材を揃えたらそれをUSB経由とかでですね、オフライン環境に持っていってあげればもうこれで終了です。

行政機関の LGWAN のように、外のネットにつながらない環境で使いたい場合に有効だ、とこーすけ先生は言います。

この流れは、目的・背景・意図を渡し、違和感をやり直し、人とAIが共に磨く循環と同じ形です。AIが作り、資材を揃える。人に残るのは、最後に運ぶ部分と、動くかを確かめる部分。

AIに委ねて、人は積み減らして生き直す。私はそう考えます。作り方の話に見えて、届け方の話でした。

行政の環境を私は知らないので、そこが有効かどうかの評価には乗らない。私なら、誰かに渡す前に、相手と同じ条件で1回動かして確かめてから渡します。作った場所で動いたことと、届けたい場所で動くことは別だからです。

こーすけ先生の動画は、バイブコーディングで作ったアプリを、スキルに頼んでオフラインでも動く形にし、USBで運ぶまでの流れを見せてくれます。作った場所で動くことと、届けたい場所で動くことは別。Webアプリのオフライン化の話から私がいちばん受け取ったのは、この当たり前の差です。

私ならこうする。熱から試作を始める。仕事なら意図まで渡す。うまくできたやり方は判断軸ごとスキルに残す。そして渡す前に、相手と同じ条件で1回確かめます。

AIも道具も、人生を味わうための手段です。