Nano Banana速っ！Claude Code課金で変わる制作フロー
- 19 Sep, 2025
ジムへ向かう車内で、いつものように竹内（@rikson_en）と僕のテック談義が始まりました。 今回は、Googleの画像生成モデル（通称 Nano Banana）から、 ClaudeのMaxプラン活用、ブログのAstro移行、そして減量のためのカロリー計算アプリの試作まで、開発と日常が気持ちよく交差した回です。
Nano Bananaを触ってみた所感
最近よく耳にするGoogleの画像生成モデル、通称Nano Bananaについて試してみました。 実名は別にありますが、コミュニティではこの呼び名が定着しています。 生成はとにかく速く、さっと作って試す用途には相性が良いと感じました。 細かな編集やリファインはこれから検証しますが、既存画像の編集やアップロード画像の修正にも使えると聞いています。 目視では分からないレベルの透かしが入るという話もあり、見た目の邪魔にはならない印象です。 商用利用の可否などライセンス周りは、今後も確認していくつもりです。
竹内のAI課金とClaude Maxプラン
今週、竹内はAIに本格課金しました。ClaudeのMaxプランを契約し、まずは自分のブログの整備から着手です。もともとはJekyllで運用していましたが、ローカル環境が立ち上がらなくなったことをきっかけに、JavaScriptに寄せたスタックへ移行しました。エディタを前提としないClaude Codeに合わせ、最初から最後までまるっと任せる運用に舵を切ったのが印象的でした。
モデル選択の体験は独特で、Opusを選ぶと使い方次第で一時的な制限に当たる場面があり、時間帯によってはSonnet寄りで回すこともあるようです。内部では、計画をOpus、実行をSonnetのように役割分担しているのではというのが竹内の推測でした。いずれにせよ、人間が途中で手を入れるとClaude Codeに上書きされやすいため、編集まで含めて最初から最後までAIに任せ切る方がスムーズという結論に落ち着いています。
JekyllからAstroへ：コンポーネント運用と自動テスト
ブログの土台はAstroへ移行しました。SSRは使わず基本はSSG、クライアント側の動的部分はPreactで描画する構成です。UIはReactコンポーネントとして切り出してStorybookで一覧化し、Chromaticと連携してビジュアルリグレッションを回します。Renovateが投げてくるパッケージ更新はテストが通れば半自動で取り込む方針です。将来的にはPlaywrightのE2Eを各ページで走らせ、差分検知をCIに組み込む予定です。ワークフローの題材としてブログはシンプルで扱いやすく、要素技術をつなぐ練習にも適していると感じました。
Claude Codeと他ツールの使い分け
カーソルのようにエディタ上で行選択して部分修正する運用に慣れていると、Claude Codeの体験は少し違って感じます。局所修正を人間が直接入れるより、タスクを塊で投げて全置換させた方が整合性が保ちやすい一方、生成物の検証は手元で必要です。竹内はChrome MCPと組み合わせ、ローカルで立てたアプリをブラウザ操作で確認するプロンプトを用意し、最低限のE2E検証を回していました。精度はまだ発展途上ですが、コード生成からローカル起動、ブラウザ検証までを一連で回せるのは強みです。
デザイン面では、僕のブログで使っているBootswatchのLuxテーマに寄せるため、Figmaテンプレートを調整する試みも行いました。SCSSの変数からテーマカラーを抽出してFigmaに反映させたいという意図までは伝わるのですが、自動化はもう一歩という印象です。ここは人の手を薄く残すのが現実的だと感じました。
モデルとツールの断片化
最近はGPT系やOpus、Sonnetなど選択肢が増え、YouTubeでもモデル比較の話題が尽きません。ただ、良し悪しの差は場面依存で、最適解は案件やデータセット次第という印象が強いです。竹内は、モデルを変えるたびにツールまで乗り換えを迫られる現状にもやもやしていて、インターフェースのプロトコル化が進むと嬉しいと話していました。実際、Claude Codeはモデル選択が自社ドメインに閉じる一方、カーソルは外部モデルを柔軟に差し替えやすいという特徴があります。それでも最終的には、うまくいかなかったら別モデルで同じタスクをやり直すというリトライ戦略が現実的だよね、という結論になりました。
V0とSpec Kitの実験：生成からExpoへ
竹内が作っているのは、減量を支援するカロリー計算アプリです。まずはV0でUIのラフを起こしてみたものの、出力はやや野暮ったく、画面遷移も意図とずれました。チャットをホームに常設したいのに、記録ボタンを押すと別画面に遷移する構成になってしまい、何度指示しても直らなかったため、一度Next.jsの出力を雛形として受け取り、Expoへ書き直す方針に切り替えました。ここからの改修はClaude Codeでスムーズに進み、V0はワイヤー生成までは速いが、既存仕様への忠実さは得意ではないという学びが得られました。
要求駆動のSpec Kitも試しましたが、分解したタスクが独自解釈を含みやすく、既存デザインに忠実であることが要件の場合は、設計を人が握ってから変換タスクとしてAIに渡す方が精度が出ると感じました。フルスクラッチで企画から任せるのか、既存資産に寄せるのかで、ツール選定やプロンプトの姿勢は変わってきます。
ゆるく続けるカロリー管理とプロダクトの芽
竹内は日々の食事をチャットでざっくり入力し、栄養素の概算を出してもらいながら減量に挑戦しています。成分表の写真を投げて計算させる運用もしていますが、無料枠だと画像送信の回数制限が重くのしかかります。そこで生まれたのが、ゆるカロという仮称のアプリ構想です。厳密さより継続性を重視し、曖昧な入力からでも実用的な合算を返すことを目標にしています。音声や画像、テキストのどれからでも記録でき、後から修正や再計算が簡単にできること。こうした道具があると、ズボラ気味でも健康は十分に最適化できるのでは、という期待が込められています。
ドメイン雑談
サブドメインでポッドキャスト専用サイトを作る案や、FMやJPのTLDはやや高めで、orgやnetは比較的安価といった小ネタも道中で盛り上がりました。更新費用の設計や、レジストラごとの通知やオプションの癖など、運用のしやすさもプロダクトの一部だよねという話になりました。
おわりに
AIのオーケストレーションは、任せる範囲を最初に決めると回り出します。部分最適の手動修正をぐっと我慢して、設計から検証まで丸ごと渡すことで、全体の整合がむしろ取りやすくなることがあります。Astro移行と自動テストの整備、V0やSpec Kitの実験、そしてゆるカロのプロトタイピング。道具の選び方と任せ方を試し続ける僕らの試行錯誤は、しばらく続きそうです。