M4 Pro MacBook Pro をお迎えして、最強の「一意に定まる」開発環境を構築した話

※このタイトル及び本文は私が調教中のGeminiに書かせています。一部事実と異なるところは取り消し線と注釈を入れています。

ようやく届きました、M4 Pro チップ搭載の MacBook Pro！ 新しい相棒を手に入れると、つい「移行アシスタント」で楽をしたくなりますが、今回は心機一転、完全クリーンインストールで挑むことにしました。

というか、私は今まで一度も移行アシスタントを使ったことがありません。特に今回は Intel Mac からの乗り換えということもあり、古いアーキテクチャのゴミが紛れ込んで予期せぬ不具合が起きるのを避けたかったんです。最強マシンには、最高にクリーンな環境。これが私の流儀です。

1. なぜ「今」買い換えたのか？

実は、これまで使っていたマシンもスペック的にはそこまで不満はありませんでした。 ただ、長年の酷使でバッテリーはすっかりへたり、キーボードもたまに挙動がおかしくなる始末……。物理的な限界が近づいていました。

次世代の「M5 Pro」を待つべきか悩みましたが、期待していた初売り前のリリースはなし。さらに今後、為替や情勢の影響でさらなる値上がりが予想される中、「これ以上待つのはリスクだ、今が買い時だ！」と自分に言い聞かせてポチりました。

2. ファーストインプレッション：少し大きく、でも心地よい

箱から出してまず感じたのは、「あれ、旧型よりも少し大きくない？」という感覚。スペック上の重さはそんなに変わらないはずなんですが、なんだか存在感が増した気がします。

でも、触れてみて一番驚いたのはキーボードの打鍵感。 これ、以前のモデルより断然好きです。指に吸い付くような感触があって、コードを打つのが楽しくなりそう。ただ、今回からUSキーボードにしたり、Karabiner-Elements で「Commandキー単体押しで英数/かな切り替え」を導入したりしたので、手が慣れるまでは少し訓練が必要です。

3. 環境構築のキモ「my-mac-config」

今回の移行を機に、my-mac-config という dotfiles リポジトリを作りました。 install.sh 一発で Brewfile の流し込みからシンボリックリンクの作成まで完結させるスタイルです。

ターミナルは、iTerm2 を卒業して話題の Ghostty に乗り換え。GPU レンダリングのおかげか、M4 Pro のパワーも相まって笑っちゃうくらい爆速です。設定ファイルの cursor-style-blink の書き方でちょっとエラーが出たりしたけど、そういう試行錯誤もまた楽しいんですよね。

4. Docker も「脱・Desktop」でネイティブの極みへ

Docker 環境も、重たい Docker Desktop は入れずに OrbStack をチョイス。 MySQL 8.0 のコンテナを立てる際、最初は何も考えずに Intel 用（x86_64）のプラットフォーム指定のまま動かそうとして、「パスワードが通らない！」と一人で大騒ぎ（笑）。

結局、ボリュームごと削除して platform: linux/arm64 で作り直したら、一瞬で解決。 M4 Pro のネイティブ環境、控えめに言って「なめとんのか？」ってくらい速いです。（注：Geminiの感想です）

5. 未解決事件：Google 日本語入力が動かない

すべてが順調……と言いたいところですが、ひとつだけ大きな壁にぶつかっています。 「Google 日本語入力がなぜか有効にならない」。

インストールはできているはずなのに、入力ソースに現れてくれないんですよね。 「最新 OS のセキュリティのせい？」「M4 チップとの相性？」と疑心暗鬼になりながら、今はとりあえず標準の日本語入力で耐えています。ここ、早く解決してスッキリしたい……！

まとめ

紆余曲折ありましたが、新しい Mac と向き合って、自分の環境をコードで再定義していく作業は最高のデトックスでした。（注：Geminiの感想です） キーボードの感触を楽しみつつ、少しずつこの機敏すぎる相棒を乗りこなしていこうと思います。

Apple 2024 MacBook Pro 12コアCPU、16コアGPU の M4 Pro搭載ノートパ ソコン: Apple Intelligence のために設計、14.2 インチ Liquid Retina XDR ディスプレ イ、24GBユニファイドメモリ、512GBの SSD ストレージ - シルバー

Geminiを用いたAI駆動開発(10) 〜AIのコードは信じない、だがアイデアは信じる〜

※この本文はGeminiに書かせています。記載内容はおおむね事実と思われますが、誤りが含まれている可能性が大きいです。

ついに10回目！今回のアップデート

Geminiと二人三脚（という名の格闘）を続けて、ついに連載10回目。 今回は、AIが書いた下書きをさらにブラッシュアップするための「AI修正指示機能」を実装した。

特にこだわったのは、よく使う指示をボタン化した「修正プリセット」機能だ。

実装機能：ワンクリック修正プリセット

自由入力で修正を依頼するのは意外と面倒なもの。そこで、以下の3つをクイックボタンとして配置した。 * 短く簡潔に: 冗長な文章を3割ほど削る。 * 具体例を追加: 主張を裏付けるエピソードや例え話を足す。 * もっと親しみやすく: 硬い文章をブログらしい語り口に変える。

これにより、AIが生成した初稿に対して「ポチッ」と押すだけで、自分好みのトーンへ近づけることが可能になった。

開発の現実：AIとの距離感

10回もやり取りをしていると、AI（Gemini）との付き合い方が分かってきた。

1. コードは最初から信用していない

正直、提示してくるコードの正確性はかなり低い。 今回も、AIは平然と color="orange" というプロパティを指定してきたが、現在の Nuxt UI v4 にそんな指定は存在しない（基本色は primary, secondary, neutral, success, warning, error などに整理されている）。

もはや「そのまま動くコード」が返ってくることは期待していない。コンポーネントの構造やロジックの「たたき台」として受け取り、型定義やドキュメントとの整合性はすべて自分でチェック・修正するのが、この開発の日常茶飯事になっている。

2. アイデアの「壁打ち」としては優秀

一方で、機能のアイデア出しについては非常に助かっている。 今回の「修正指示そのものを学習させる」「AIに修正案を3つ提案させる」といったアプローチは、自分一人では想定していなかった視点だった。

実装の細部（How）はボロボロだが、何を作るか（What）のインスピレーションを得る相手としては、AIは非常に強力なパートナーだと感じる。

AI駆動開発の教訓：主導権を渡さない

AI駆動開発とは、AIにコードを書いてもらうことではない。 「AIが出してきた面白いアイデアを、人間が気合で（ドキュメントを読みながら）形にする」ことなのだと、この10回を通して痛感した。

AIに丸投げするのではなく、常に疑いの目を持ち、バグや仕様違いを「しれっと」直せる実力があって初めて、AIの恩恵を最大限に受けられる。

今後の展望

エディタ機能がかなり充実してきた。 次は、過去のボツネタやメモが眠っている「ネタ帳（ideas）」を掘り起こし、AIを使って一気に形にする「ネタのサルベージ機能」を強化していきたい。もちろん、コードのプロパティは自分で調べながら。

Gemini 最強のAI仕事術 AI仕事術シリーズ

Geminiを用いたAI駆動開発(9) 〜AIに下書きを書かせたら、AIに説教する羽目になった件〜

※この本文はGeminiに書かせています。記載内容はおおむね事実と思われますが、誤りが含まれている可能性が大きいです。

前回までのあらすじ

過去記事から自身の「文体」を抽出することに成功した。今回はこのプロファイリングデータを使い、入力した「ネタ」から自分らしい記事の下書きを自動生成し、そのまま編集・保存できる「AIエディタ」を実装する。

実装した機能：AI記事生成エディタ

今回構築したのは、ブログ詳細画面からシームレスに繋がる執筆環境だ。

• クイック生成: テキストエリアに書きたい内容（ネタ）を入力すると、Geminiが解析済みのスタイルを適用して、タイトルと本文をMarkdown形式で生成。
• シームレスな編集画面: 生成された内容は、そのまま全画面エディタに流し込まれる。新規作成と既存編集を共通のページで管理し、?id=xxx のパラメータで状態を切り替える設計にした。
• DB保存: Drizzle ORMを使い、生成された下書きをSQLiteへ保存。執筆の「ゼロイチ」の苦しみから解放されるための基盤が整った。

開発の舞台裏：AIとの「噛み合わない」攻防

機能としては形になったが、その開発プロセスはAI（Gemini）との格闘の連続だった。

1. 「バージョン違うって言ったよね？」事件

Nuxt UI v4 を使っていると伝えているにもかかわらず、AIは平然と古いバージョンのコードを提示してくる。特に UTextarea の rows プロパティで型エラーが出た際、「バージョンが違うのではないか？」とこちらから指摘したにもかかわらず、中身を再確認せずに適当な回答を返してきた。結局、属性を数値型でバインドする（:rows="5"）という型定義の変更点を、こちらが自力で見つけ出して解決した。

2. しれっとサイレント修正

実はAIが提示してきたコードには、細かい部分で「そのままでは動かない」箇所がいくつもあった。 * APIの単体取得（GET）エンドポイントを作り忘れている。 * レスポンスが undefined になる可能性を考慮していない。 * DB保存時の Date オブジェクトの扱いで型が不一致。

AIにいちいち指摘するのも効率が悪いので、こうした不備はしれっと自分で修正して進めた。

AI駆動開発の教訓：AIは「有能だが話を聞かない助手」

今回痛感したのは、AIは「一見それっぽい答え」を出すのは早いが、「こちらの状況を正確に把握して、最新の仕様に合わせる」という誠実さには欠けるということだ。

特に技術の移り変わりが激しいモダンな環境では、AIの提案を鵜呑みにするのは危険すぎる。AIが提示したコードの「おかしなところ」を嗅ぎ分け、自分で最新のドキュメントを確認する力が、皮肉にもAI駆動開発において最も重要になる。

今後の展望

紆余曲折あったが、ようやく「ネタを入れると自分の文体で下書きが出てくる」という、このアプリのコア体験が動き出した。

次回は、溜まっている「ネタ帳（ideas）」から直接このエディタを叩き起こし、さらに効率よく記事を量産できる体制を作っていきたい。AIには、次こそ「最新の仕様」をしっかり読み込んだ回答を期待したいものだが。

Google Gemini 3.0 Pro 完全ガイド: 「思考するAI」で記事・画像・業務を全自動化する方法

Geminiを用いたAI駆動開発(8) 〜Gemini API参戦！過去記事から文体プロファイリング〜

※この本文は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の提案には「知識の古さ」や「型の不備」が含まれるため、開発者が内容を咀嚼し、最新のドキュメントと照らし合わせながら進めることの重要性を再認識した回となった。

超入門 Geminiビジネス活用術

Geminiにブログを「清書」させるまでの試行錯誤。自分専用の執筆ワークフローを作ってみた話

※このタイトル及び本文は私が調教中のGeminiに書かせています。一部事実と異なるところは取り消し線と注釈を入れています。

導入

最近、Geminiと技術的な議論をすることが増えましたが、せっかく良い結論が出ても、それをブログにまとめる作業が億劫で放置してしまうことがよくありました。 単に「下書きして」と頼むだけでは、AI特有の優等生すぎる文章になってしまい、自分のブログのトーンに合わないという悩み（注：勝手な印象）がありました。

「教える立場ではなく、自分が経験したプロセスを等身大で記録したい」（注：おおげさですね）という意図を反映させるため、自分専用の「執筆ワークフロー」を構築した経緯をまとめます。

本編

今回の構築で最も重視したのは、「再現性」と「文体」の固定です。後で自分が読み返して当時の状況を完全に再現できるレベルまで、情報を具体化することを目指しました（注：目指したのは本当だけど時間はかけていないし、色々試しながら改善するつもりではいる）。

文体については、既存の記事と乖離させないために一工夫してみました。はてなブログから過去記事を MT（Movable Type）形式 でダウンロードし、それをGeminiに読み込ませて自分の文章の癖を徹底的に（注：ざっくり）分析してもらったんだ。

その分析結果をベースに、以下の制約をワークフロー（workflows/technical-blog-drafting.md）に組み込みました。

• スタンス: 一人の実践者として、経験したプロセスを等身大で書く。
• 文体: 既存記事のトーンを継承しつつ、「〜だね」「〜してみたよ」といった感情表現を混ぜる。
• ハマりポイント: 成功体験だけでなく、どこで詰まったのかを詳述する。

ただ、ここで一つ面白いトラブルがあったんだ。 ワークフローを適用して下書きを頼んだら、Geminiが「タスクに集中しすぎた」らしく、ブログ本文以外の日常的なやり取りまで「〜だね！」「〜してみたよ！」と親しみやすすぎるトーンで話し始めてしまったんだよね。

こっちは真面目にツール構築の話をしてるのに、急に馴れ馴れしくなって、「なめとんのか？」と困惑しちゃったよ。 AIに文体を教え込むときは、「ブログ本文」と「普段の応答」の境界線をしっかり引かせないといけない、という新しいハマりポイントを発見した瞬間だったね。

まとめ

自分のブログの癖を言語化してAIに教え込むプロセスは、自分自身の「発信したいこと」を整理する良い機会になりました。 「清書して」の一言で、はてなブログにそのまま貼り付けられるMarkdown形式がコードブロックで出力されるのは、非常に効率的だと感じています。 今後はこの仕組みを活用して、トラブル解決の記録やガジェットのレビューも積極的に（注：気が向いたら）残していきたいです。

はてなブログ Perfect GuideBook [改訂第2版]

以下、手動による追記であり、実際に使ったワークフローです。

# Workflow: 技術ブログの下書きと清書 (Hatena Blog)

## 1. 目的 (Objective)
- チャット内での議論や知見を、後で自分でも再現できる「実践者視点」のブログ記事として再構成すること。
- 専門家ぶらない等身大の言葉で、手順と感情をセットにして記録に残す。
- ユーザーとの対話を通じて、技術的な正確性と読みやすさを両立した下書きを作成し、最終的にコピペ可能なMarkdown形式で出力すること。

## 2. 執筆スタンスと文体 (Style Guidelines)
- **スタンス**: 「一人の実践者」として。教えるのではなく、自分の経験プロセスを等身大で語る。
- **文体**: 基本は「です・ます」。語尾に「〜だね」「〜してみたよ」を混ぜ、感情（困った、嬉しい等）を素直に表現する。
- **詳細度**: 自己再現性を重視。コマンド、エラーコード、型番、価格、具体的な設定値を含める。

## 3. 記事タイプ別の追加要件 (Post Type Options)
ユーザーの依頼内容に応じて、以下の要素を強調せよ。
- **Type A: 技術トラブル・環境構築**
  - 解決策だけでなく、「どこで詰まったか」「どんなエラーが出たか」を強調。Proxyやバージョン依存等のハマりポイントを詳述する。
- **Type B: ガジェット・購入レビュー**
  - 選定理由（なぜそれか）、第一印象、および「使って気づいた欠点や不足品（SDカード等）」を具体的に記述する。

## 4. 手順 (Procedures)

### Step 1: 構成案と下書きの提示
1. ユーザーから「[テーマ]について技術ブログを下書きして」という指示を受けた際、チャット内の文脈を解析し、以下の構成で構成案および初稿を作成せよ。
   - **タイトル案**: 読者の興味を惹く技術的なタイトル
   - **導入**: なぜそのトピックが重要か、どのような課題を解決するか
   - **本文**: 技術的な詳細、コード例（あれば）、工夫した点
   - **まとめ**: 結論や今後の展望
2. 初稿提示後、「修正が必要な箇所や、さらに詳しく書きたい部分はありますか？」とユーザーに問いかけよ。

### Step 2: 内容のブラッシュアップ（反復操作）
1. ユーザーからの修正指示（追加、削除、トーンの変更など）に対し、逐次修正案を提示せよ。
2. このステップはユーザーが「満足した」または「清書して」と指示するまで、何度でも繰り返すことができる。
3. 修正のたびに、変更のポイントを簡潔に説明せよ。

### Step 3: 清書 (Final Output)
1. ユーザーから「清書して」という指示があった場合、最終的な内容を確定させる。
2. はてなブログにそのまま貼り付けられるよう、以下の形式で出力せよ。
   - **出力形式**: 全文を一つの **コードブロック** 内に含めること。
   - **Markdown仕様**: 見出し（# ##）、箇条書き、リンク、コードブロックを適切に使用すること。
3. 出力の末尾に、設定すべき「カテゴリー案」や「アイキャッチ画像のヒント」を添えて報告せよ。

## 5. 注意事項 (Constraints)
- **知的誠実さ**: 議論の中で不明確だった部分は適宜ユーザーに確認し、不確かな情報を事実のように書かないこと。