現在、個人で進めているゲーム開発やアプリ開発のライフワークの一環として、独自のホームページとブログの構築・運営に取り組んでいます。開発の進捗や技術的な知見を自らの言葉で記録し、発信していく場所を整えるためです。
今回の記事では、このブログを運営する中で直面したGoogle AdSense（グーグル・アドセンス）の審査をめぐる試行錯誤や、Tailwind CSS（テイルウィンドCSS）を使ってシステム自体をフルスクラッチで自作した背景、そして開発者としての日常業務と執筆を両立させるために編み出した、AIとGitの変更履歴を連携させた超効率的な記事生成の手法について、等身大の視点から詳しく書き残しておきたいと思います。
Google AdSense審査の不合格から学んだコンテンツの重要性
ブログを開設した大きな目的の一つに、Google AdSenseを導入してサイトを収益化することがあります。しかし、この審査を通すのが思いのほか一筋縄ではいきませんでした。
すでに2回、アドセンスの申請を出しては不合格という結果を受け取っています。不合格の直接的な理由は、サイト内の「コンテンツ不足」によるものでした。ホームページとしての器は作っていたものの、実際に読者が読んで価値を感じるような記事の絶対数が、グーグルの求める基準に達していなかったのです。
現在は、中身を補強した上で3回目の申請を行っている最中ですが、結果がどうなるかはまだ分かりません。この手痛い経験から学んだのは、システムがどれだけ綺麗に整っていても、そこに載せるコンテンツ（記事）が充実していなければ、メディアとしての体をなさないということです。審査を通過するため、そして何よりサイトを訪れてくれる人にとって価値のある場所にするために、日々の開発で得た技術的な知見を積極的に記事としてアウトプットし、ボリューム感を増やしていく必要があると痛感しました。
Tailwind CSSによるブログのフルスクラッチ構築と「等身大の記録」
ブログの構築にあたっては、WordPress（ワードプレス）などの既存のCMS（コンテンツ管理システム）を使うのではなく、Tailwind CSSなどを用いて、フロントエンドからバックエンドまで完全に自分の手でシステムをゼロから作り上げる「フルスクラッチ」の手法をあえて選択しました。デザインの細部に至るまで自分の思い通りにコントロールし、軽量でモダンなブログを作りたいと考えたからです。
この自作ブログに投稿する記事の方向性として、私は「等身大の開発記録」を残すことを基本方針にしています。よくあるアフィリエイトブログや一般的な技術解説サイトのように、読者受けやSEO（検索エンジン最適化）を過剰に意識して、どこかで見たような最大公約数的な一般論を分かりやすく丁寧に解説するような書き方は、あえてしないように決めています。
私が書きたいのは、自分が開発の過程で実際にどのような課題にぶつかり、それをどう考えて解決したかという、生々しくリアルなドキュメントです。だからこそ、時には専門的で少し難解なキーワードがそのまま飛び交うような内容であっても構わないと思っています。「この記事のここが分からないけれど、どういう意味だろう？」と読者が自発的に調べたくなるような、フックのある記事を書いていきたいのです。読者に媚びるのではなく、自分が実際に手を動かして得た「一次情報」の価値をそのまま届けることこそが、この自作ブログにふさわしいと考えています。
AIは「指示する」のではなく「指導する」：Git差分を活用した執筆自動化
開発を続けながらブログの記事を定期的に更新していくのは、時間的にも精神的にも大きな負担になります。そこで私は、普段使っている開発エディタ（Cursorなど）に統合されているAIツールを活用して、記事執筆プロセスの実質「9割」を自動化する仕組みを構築しました。
この自動化において最も重要なコンセプトは、AIを単なる「身代わりの代筆屋」として扱うのではなく、自分の分身として「指導・教育する」というアプローチをとることです。
多くの人は、AIに対して「〇〇という技術について、初心者向けに解説記事を書いてください」といった大雑把な「指示（命令）」を出しがちです。しかし、この方法で出力される文章は、ネット上の情報を適当に継ぎ接ぎしただけの、薄っぺらで退屈な一般論になってしまいます。これでは、私の目指す「リアルな開発ブログ」にはなりません。
私が実践しているのは、自分が書いたソースコードの「Gitの差分情報（git diff）」やコミットログ、実際に開発を終えたときの率直な感情や意図といった、自分にしか提供できない「生のデータ（一次情報）」をAIにインプットとして渡す方法です。
具体的には、以下のようなプロセスで記事を生成しています。
- 差分データの読み込み: 開発を進める中で、コードを修正・追加します。その変更履歴（Gitの差分）を、エディタ上のAIに直接読み込ませます。
- コンテキストの提供: 単にコードを渡すだけでなく、「今回、私はこういう不具合を解決したくて、このアプローチを選んで修正を加えた。その時の苦労や、実装時の判断基準はこうだった」という、コードの行間に隠れた私の意図や感情を、短いテキストとしてAIに伝えます。
- 下書きの自動生成: AIに対して、「私が渡したこのGit差分とコンテキストを深く読み解き、私がどのような意図でどのような技術的解決を行ったのかを正確に理解した上で、技術ブログの下書きとしてマークダウン形式で再構成してほしい」と依頼します。
このやり方であれば、AIは私が実際に書いたコードをベースに、私の開発スタイルや好む表現の癖を反映した、極めて精度の高い下書きをものの数十秒で書き上げてくれます。変更点を自分で一つずつ手で書き出し、説明文を一から組み立てるという、最も面倒で時間がかかる作業をほぼ丸投げできるため、記事作成の効率は劇的に向上します。
仕上げとして、AIが吐き出した下書きに目を通し、自分の口調に合わない部分や、技術的にニュアンスが微妙なところを微調整するだけで、1本の本格的な技術記事が完成します。まさに、AIに私の「開発の背中」を見せて学習させ、執筆を代わりにやらせるという、教育・指導のプロセスそのものです。
記事の顔となるタイトル選びについても、AIに「この記事の内容にふさわしい、開発者として目を引くようなフックのあるタイトル候補を10個提案して」と求め、その提案の中から最も自分の意図を表現できているものを選んだり、複数の候補からキーワードを組み合わせて決定したりしています。人間の頭だけでは思いつかないような、客観的かつ魅力的な切り口のタイトルが手に入るため、このアプローチは非常に有効に機能しています。