※この本文はGeminiに書かせています。記載内容はおおむね事実と思われますが、誤りが含まれている可能性が大きいです。
前回までのあらすじ
過去記事の資産を活かすべく、MT形式（Movable Type）ファイルのインポート機能を実装した。これにより、データベースには解析の「種」となるテキストデータが蓄積された。今回は、いよいよGemini APIを連携させ、過去記事から筆者の「執筆スタイル」を自動抽出するコア機能に挑む。
Gemini APIによる文体解析の実装
実装の狙いは、インポートした過去記事の中から最新の1件をGeminiに読み込ませ、文体（トーン）、想定読者、よく使う語彙、執筆ルールを解析させることだ。
1. Google AI StudioでのAPIキー取得: 開発者向けのコンソールからキーを発行し、Nuxtの runtimeConfig に設定した。
2. モデルの選定: Gemini 1.5 Flash や 2.0 Flash を試行したが、最終的に最新の gemini-3-flash-preview を採用。
3. プロンプトエンジニアリング: 抽出したい項目を明確にし、DBの型定義に合わせたJSON構造で返却するよう指示。
解析された結果は、ブログ設定の contextConfig カラムに保存され、今後の「AIによる代筆」の際の指示書（システムプロンプト）として活用される。
直面した「AI駆動開発」の壁
今回の開発では、AI（Gemini）と協力して進める中での課題がいくつか浮き彫りになった。
- 相変わらずのコンパイルエラー: AIが提案するコードは一見動くように見えるが、Nuxt 4 の
$fetchの戻り値に対する型推論が効かず、TypeScriptのエラーが発生しがちだ。結局、内容を理解した上で型定義を自前で修正する必要があった。 - APIキー取得のガイド不足: APIの使用を提案される際、具体的な取得場所（Google AI Studio）や手順についての解説が乏しく、自力で補完しなければならなかった。
- モデル知識の「賞味期限切れ」: AIが提案してくるモデル名が古く、現在のクォータ（制限）の関係で
429 Too Many Requestsや404 Not Foundが頻発した。AIの提案を鵜呑みにせず、自ら最新のモデル情報を調べて指定する必要がある。
解析結果の感想と今後の展望
現時点では最新の1記事のみを読み込ませた限定的な解析ではあるが、まずは Gemini API と連携し、自身のブログ設定（contextConfig）に解析結果が保存されるという一連の流れを確立できた。
1記事だけの解析なので、筆者のスタイルを完全に網羅できているわけではないが、まずは第一歩として機能した。これからさらに多くの記事を読み込ませたり、解析の精度を上げたりしていくことで、AIがどのように自分独自のスタイルを学習・発展させていくのか、今後の展開が楽しみである。
まとめ
GitHub連携や自動解析により開発スピードは加速している。しかし、AIの提案には「知識の古さ」や「型の不備」が含まれるため、開発者が内容を咀嚼し、最新のドキュメントと照らし合わせながら進めることの重要性を再認識した回となった。
