ChatGPTとの協働によるブログ構築の全記録：プロンプト設計から実装までの10日間

技術ブログ構築の出発点 なぜ始めたのか

技術ブログ構築に乗り出した理由は「いつか自分のブログを持ちたい」という単純なものではなかった。私は長年、技術とビジネスの狭間で仕事をしてきた経験から、この 2 つの領域の「架け橋」の必要性を強く感じていた。既存のブログサービスでも十分発信はできるが、技術とビジネスの融合を体現するプラットフォームを自分の手で構築したいという思いが強かった。

この 1 ヶ月間のブログ構築過程は、単なる実装記録ではなく、AI 協働開発の可能性を探る旅でもあった。従来であれば、自分一人でブログを実装するには何週間もかかる作業だが、AI との協働で驚くほど短期間で実現できた。

この記事では、ブログサイトの構想段階からデザイン実装に至るまでのプロセスを共有する。特に注目してほしいのは、AI と協働したデザインの実現方法と、情報アーキテクチャの設計思想だ。これは単なる技術の話ではなく、ビジネス価値をどう技術で実現するかという普遍的な課題への私なりのアプローチだ。

Vibe Coding との出会い 開発コストの大幅削減

このプロジェクトで私が採用した開発アプローチは「Vibe Coding」と呼ばれるもので、AI と雰囲気でコーディングする新しいスタイルである。この手法との出会いが、このブログ実装の大きな転機となった。

プログラミングコストの逆転現象

従来の開発では、エンジニアの単価が高いため、自動化するほどの価値があるか慎重に判断する必要がありました。

目の前の問題を解決しようとすると、手作業で 8 時間かかるものを 20-30 時間かけて自動化するための実装が必要であった。実際に使ってみるとバグが発生し、デバッグ作業も加わるため、20-30 時間で済めば良い方だった。

このコスト計算から、多くの場合「我慢して手作業でやりましょう」という結論になっていた。しかし AI との協働が、この構図を劇的に変えた。

Vibe Coding アプローチの最大の価値は、実装時間の大幅短縮にある。8 時間かかる手作業に対して、AI と協働すれば 30 分程度でコードが実装できることも珍しくない。つまり、適用できる範囲が圧倒的に広がった。

私は以前、ウェブサイト構築の際に時間効率を考えてノーコードツールを多用していた。しかし、ノーコードでは実現できることに限界があり、カスタマイズにも制約があった。

AI との Vibe Coding でこれらの制約を超えられると気づいたとき、このブログ構築プロジェクトを開始する最後の背中押しとなった。

ただし、最初に述べておきたいのが「ブログを生成して」と AI に指示出ししたら完成するようなレベルの低いコピー品を作るわけではない。高い品質を AI とともにどのように作っていくかの試行錯誤について、この記事では紹介することが私から読者の皆さんへ提供できる価値である。

ブログの構想と戦略フェーズ ビジョン定義

このブログ構築プロジェクトは、単なるコーディング作業から始めたわけではない。「どんなブログを作りたいのか」というビジョンと「誰に届けたいのか」というターゲット設定から始めた。

「技術とビジネスの架け橋」という核心的ビジョン

ブログの核心的コンセプトは「技術とビジネスの架け橋」だ。このコンセプトには以下の要素が含まれている。

1. 知識の変換と翻訳：技術的知識をビジネス価値に、ビジネス要求を技術要件に変換する
2. 分断された世界の接続：従来別々に議論されてきた「技術系」「ビジネス系」の領域を横断する
3. 対話の創出：異なる専門性・バックグラウンドを持つ人々の間の対話を促進する
4. イノベーション基盤：領域を越えた知識の融合から生まれる新たな価値創造の土壌を作る

このビジョンは私の経験から生まれた。技術者と経営者の両方の視点を持ち、その間の「翻訳者」として機能してきた経験が、このブログの方向性を決定づけた。

ターゲットペルソナの明確化

ビジョンが定まると、次に「誰に届けたいか」を明確にする必要があった。3 つの主要ペルソナを設定した（本当は 3 つもペルソナを用意するのは多いが AI と一緒に進められるならばと欲張っている）。

この 3 つのペルソナは、それぞれ異なるニーズを持っている。

1. 転換期のテクノロジスト：技術的専門性を持ちながら、より広い視野でのキャリア発展を模索している
2. テクノロジー時代の舵取り役：ビジネスバックグラウンドを持ち、技術をビジネス変革に活かしたいと考えている
3. 次代の社会変革者：技術と社会課題の接点でイノベーションを起こそうとしている

これらのペルソナに対して、それぞれ異なるアプローチで価値を提供することを意識した設計が必要だった。

コンテンツ階層の設計 情報の深さと抽象度

ビジョンとペルソナが定まると、次にコンテンツの構造を考える必要があった。私は 4 つの階層でコンテンツを構造化することにした。

1. 基盤層 (Foundation) 体系的な基礎知識と原理原則
2. 応用層 (Practical) 実践的なノウハウと方法論
3. 洞察層 (Insight) 変化のパターンと潮流の読み解き
4. 個人層 (Personal) 創始者自身の哲学と思考プロセス

この階層構造は、読者の知識レベルと関心に応じて、適切な深さと抽象度のコンテンツを提供することを目的としている。

また、URL 設計にも影響を与え、最終的に「tech」「business」「insight」という 3 つのカテゴリに整理された。

多次元探索システムの設計 情報アクセスの革新

ブログの情報アーキテクチャとして、従来のカテゴリ・タグという 1 次元的な分類を超えた多次元探索システムを構想した。これは、同じコンテンツに対して異なる視点からアクセスできるようにするための仕組みだ。

この多次元探索システムは、MVP（最小実行製品）段階では完全実装はせず、後のフェーズで実装予定だが、初期の情報設計に大きく影響を与えた。この構造により、同じコンテンツが異なる文脈で発見されやすくなり、読者の関心と必要に応じた柔軟なナビゲーションが可能になる。

AI との協働によるデザイン実装 試行錯誤の記録

ブログのビジョンと構造が定まると、次はデザインの段階に進んだ。ここでも、AI との協働アプローチを採用し、興味深い発見があった。

デザインガイドラインの作成と挫折

最初に一般的なデザインガイドラインと呼ばれるもの（これまではそのデザインガイドラインがあれば慣れているデザイナーさんとのやりとりはスムーズであった）を作成し、それを AI でデザインと実装を行える「v0」に読み込ませてデザインを生成しようとした。カラーパレットやフォントスタイルなどを定義したガイドラインを用意したが、期待通りのデザインは生成されなかった。

何度 ChatGPT に問題分析を依頼しても「デザインガイドラインの作り込みが甘い」という曖昧な回答しか得られず、何が具体的に足りないのか明確にならなかった。

成功への転機 デザインカタログの重要性

転機となったのは、Builder.io というサービスが提供する「Visual Copilot」という Figma プラグインの事例だった。これが実現しているオンブランド化の手法を研究したところ、重要な気づきを得た。

単なるカラーパレットやフォント指定だけでは不十分だったのだ。AI にデザインの本質を伝えるには、具体的なコンポーネントのカタログが必要だった。

私は Claude Sonnet 3.7 で新たなアプローチを試みた。これまで作ってきたデザインを約 10 枚画像化し、オンブランド化に必要な要素を分析してもらった。そして、Few-Shot Learning の特性を活かし、実際のコンポーネントの詳細を文章の形式でカタログとしてガイドラインに追加した。

この方法で生成したデザインは、はるかに期待に近いものだった。デザインの「雰囲気」を AI に伝えるには、抽象的な指示ではなく、具体的な事例の蓄積が有効だったのだ。

これは単に AI とのコミュニケーション方法だけでなく、人間同士のデザインコミュニケーションにも通じるインサイトだった。デザイナーとの協働においても、抽象的な指示より、具体的な参考例を示す方が効果的なのだ。

実装戦略 デザインからコードへ

デザインが固まったら、次はコードへの落とし込みだ。v0 で生成したデザインを zip ファイルでダウンロードし、実装に移行した。

ここでのポイントは、単に v0 のコードをそのまま使うのではなく、既存のプロジェクト環境に統合する戦略だった。以下のアプローチを採用した。

1. 参照フォルダの作成：ref フォルダを作成し、v0 で生成したコードを配置
2. 計画的な統合：Cline / Roo Code の Plan / Architect モードで統合計画を立案
3. 効率的な実装：既存プロジェクトに馴染むように効率的な統合 (Act / Code モード)

このアプローチにより、v0 で生成された優れたデザインを、既存のプロジェクト構造に適切に統合できた。

制約条件の発見：私のエンジニア脳の驚くべき癖

このプロジェクトで最も興味深かったのは、自分の思考パターンの制約条件が次々と明らかになったことだ。AIとの協働により、普段は無意識に従っている「エンジニア脳の癖」が可視化された。

発見された深層制約条件の具体例

1. 「完璧なドキュメントを先に作りたがる症候群」

• 実装前に完璧な仕様書を作成しようとする
• 実際の記事での現れ方：導入部で必ず「なぜこの記事を書くのか」の理由付けを長々と説明
• AIとの協働で気づいた改善点：プロトタイプを先に作り、ドキュメントは後から整備する方が効率的

2. 「技術的正確性への強迫観念」

• 95%の読者には不要な技術的詳細まで記述してしまう
• 実際の現れ方：コードブロックやシステム図を多用し、説明が技術者向けに偏る
• 制約条件：「間違いを指摘されることへの恐怖」が根底にある

3. 「抽象化レベルのエレベーター現象」

• 具体例から急に抽象的な原則論に飛躍してしまう
• 記事での現れ方：「これは普遍的な原理だ」という表現を多用
• 読者にとっては「で、結局何をすればいいの？」となりがち

4. 「プロセス至上主義の罠」

• 結果よりもプロセスの正しさを重視してしまう
• 記事での現れ方：「どうやって作ったか」の説明が「何ができたか」より長くなる
• 読者のニーズとのミスマッチ：読者は成果物と実用性を求めている

5. 「前提条件の暗黙化癖」

• 自分にとって当たり前のことを説明せずに進めてしまう
• 記事での現れ方：「当然ながら」「言うまでもなく」という表現で重要な情報をスキップ
• AIとの協働で可視化：AIが「この前提は明確ではない」と指摘してくれる

Memory Bank による制約条件の体系化

これらの制約条件をMemory Bankで体系的に記録・管理することで、AIとの協働効率が劇的に向上した。自分の思考パターンを「データ」として扱うことで、継続的な改善が可能になった。

AI とのコミュニケーション手法 実践から得た知見

このプロジェクトを通じて、AI との効果的なコミュニケーション方法について多くの知見を得た。特に重要だったのが、タスクの分割とモードの使い分けだ。

計画と実装の分離 タスクの適切な分割

Cline/Roo Code には、計画用の「Plan/Architect」モードと実装用の「Act/Code」モードがある。初めはこの違いを理解せず、すべてのタスクを Code モードで行っていた。

しかし、プロジェクトが進むにつれ、計画と実装を明確に分けることの重要性が明らかになった。

計画フェーズでは影響範囲の調査や最適なアプローチの検討を行い、実装フェーズではその計画に忠実に従って作業を進める。このワークフローにより、以下の効果があった。

1. タスクの明確化：何をすべきかが明確になり、途中での変更が減少
2. 文脈の確保：計画段階でプロジェクトの文脈を十分に理解してから実装に移行
3. コスト削減：試行錯誤による無駄なトークン消費を削減

効率的な指示出し 中断のない実行

AI との協働では、タスクを一気に完了させることが最も効率的だと分かった。途中で介入して方向性を変えると、AI は考え直しを強いられ、無駄なコンテキスト積み重ねが生じる。

良いタスク指示の特徴は以下の通りだ。

1. 自己完結性：一度の指示で完了できる範囲に分割
2. 前提条件の明示：Memory Bank などで必要な情報を事前に提供
3. 明確な成功基準：「何をもって完了とするか」を明確にする

特に難しかったのが、AI が書いたコードのレビューだ。複雑なコードを短時間でレビューするのは困難であり、リアルタイムで介入すると効率が落ちた。

この対策として、BDD（Behavior Driven Development）アプローチを取り入れた。コードの実装前に「どのような振る舞いを期待するか」を文章で擦り合わせ、それを満たすコードを実装してもらう方法だ。これにより、最終的なコードの品質と理解度が大幅に向上した。

あなたも試せる：制約条件の発見方法

自分の思考パターンの制約条件を発見することは、記事執筆だけでなく、あらゆる創造的な活動において有効だ。以下に、実際に私が使っている方法を紹介する。

ステップ1：書き手の制約条件チェックリスト

過去の記事や文章を3-5本読み返し、以下の項目をチェックする：

文章構造の癖

• 導入部が長すぎる（全体の30%以上）
• 結論が最後まで出てこない
• 同じ語尾が3回以上連続している
• 「しかし」「ただし」などの転換表現が多用されている

内容の傾向

• 技術的詳細に偏りすぎている
• 抽象的な表現が多く具体例が少ない
• 自分の経験談ばかりで一般化されていない
• 前提知識を説明せずに専門用語を使っている

読者への配慮

• 「当然ながら」「言うまでもなく」を多用している
• 記事のメリットが読者視点で書かれていない
• 行動可能な提案が含まれていない

ステップ2：AI を活用した制約条件の可視化

ChatGPT や Claude に以下のプロンプトで分析を依頼する：

この文章を分析して、書き手の思考パターンの特徴や制約条件を
以下の観点から指摘してください：

1. 文章構造の特徴（導入・展開・結論のバランス）
2. 語彙・表現の傾向（専門用語の使用頻度、文体の特徴）
3. 内容の偏り（技術寄り/ビジネス寄り、抽象/具体のバランス）
4. 読者への配慮（前提知識の扱い、実用性の提供）
5. 無意識の前提条件（暗黙的に仮定していること）

[ここに自分の文章を貼り付け]

ステップ3：制約条件の改善実践

発見した制約条件を次の記事で意識的に改善する：

1. 対症療法：発見した癖を避けるよう意識する
2. 構造改善：記事の構成テンプレートを見直す
3. 読者視点強化：ターゲット読者を明確にして書く

実践のコツ：小さく始める

制約条件の改善は一度に全部やろうとせず、記事1本につき1-2個の制約条件に集中する。私の場合、「技術的正確性への強迫観念」を改善するため、意識的に「95%の読者にとって十分な説明レベル」を心がけるようになった。

この方法により、自分の思考パターンを客観視し、より読者に響く文章を書けるようになる。

次のフェーズへ 実装からコンテンツへ

ブログの基盤構築が完了し、次のフェーズはコンテンツの充実だ。この記事は Insight カテゴリの一部として、私の経験とインサイトを共有するものだが、今後はさらに多様なコンテンツを追加していく予定だ。

特に、このブログ構築で得られた技術的な学びは、後編となる Tech カテゴリの記事「AI と実装した Next.js ベースのブログ構築：設計と実装の試行錯誤の記録」で詳しく解説する。その記事では、Next.js 15 の特徴を活かした MDX の実装方法や、パフォーマンス最適化の技術的詳細に踏み込む予定だ。

このブログ構築の旅は、単なる技術実装を超えた価値ある経験だった。AI との協働という新しい働き方と、従来からのデザイン思考を組み合わせることで、効率的かつ創造的なプロダクト開発が可能になることを実感している。

今後もこのブログを通じて、技術とビジネスの架け橋となる知見を共有していきたい。