こんにちは、Androidエンジニアの @syarihu です。
「エンジニアブログを書きたいけど、時間がない...」
「技術的な知見はあるけど、文章にまとめるのが面倒...」
こんな悩みを持つエンジニアは多いのではないでしょうか。
本記事では、日々の開発作業でAIを活用してコミットやPull Request（以下、PR）を作成することで、自然とブログのネタと素材が蓄積され、最終的にブログドラフトまで自動生成できる方法をご紹介します。
プロダクト開発からブログ公開までの流れ
プロダクトの開発作業からブログ公開までを7つのステップに分け、各ステップでAIと人間がどのように役割分担するかを紹介します。
| ステップ | 担当 | 概要 |
|---|---|---|
| 1. 開発作業 | 人間 | 通常通り機能開発やバグ修正を行う |
| 2. 開発コミット | AI | /git-commit でコミットルールに従った詳細なコミットメッセージを生成 |
| 3. 開発PR作成 | AI | /create-pull-request でPRテンプレートに沿った説明文を生成 |
| 4. ブログドラフト生成 | AI | 開発PRの情報を元にブログ記事の骨格を生成 |
| 5. 情報補完 | 人間 → AI | 必要に応じてGeminiやChatGPTなどのDeep Research等で調査し、AIに指示して修正 |
| 6. 校正・最終チェック | AI + 人間 | AIが表記チェック、人間が事実確認と最終調整 |
| 7. 公開 | 人間 | 社内レビューを経て公開 |
このフローの特徴は、開発作業そのものがブログの素材になるという点です。開発と並行してブログのネタが蓄積されていきます。
AIが生成したドラフトをそのまま公開するのではなく、人間がドラフトを確認してAIに修正指示を出し、必要に応じて追加調査を行いながらブラッシュアップしていくという流れが重要です。
Step 1: 開発作業
すべての起点となるのは、通常の開発作業です。機能開発やバグ修正など、日々のエンジニアリング業務が起点となります。
この方法の特徴は、特別な準備をしなくても、普段の開発作業がそのままブログの素材になるという点です。開発中に意識することは特にありません。
Step 2: AIにコミットさせる
開発作業が完了したら、変更をコミットします。このステップから、ブログ素材の蓄積が始まります。
なぜAIにコミットさせるのか
通常の開発では、コミットメッセージは最低限の情報しか含まれないことが多いです。極端な例ですが、次のようなコミットメッセージを見たことがある人も多いのではないでしょうか。
fix: bug fix
しかし、AIにコミットを任せると、変更内容を詳細に分析して次のような情報を残してくれます。
- 何を変更したのか（What）
- なぜ変更したのか（Why）
- どのように変更したのか（How）
実践方法：カスタムスラッシュコマンドでワンコマンド実行
GiftmallのAndroidアプリプロジェクトでは、Claude Codeのカスタムスラッシュコマンドを活用して、コミット作業をワンコマンドで実行できるようにしています。
.claude/commands/git-commit.md に次のようなコマンドを定義しています。
--- description: Commit current changes following project commit guidelines allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git add:*), Bash(git commit:*) --- Commit the current changes following the project commit guidelines. ## Context - Git status: !`git status` - Staged changes: !`git diff --cached` - Unstaged changes: !`git diff` - Recent commits: !`git log --oneline -5` ## Instructions 1. Analyze the changes from the context above 2. Determine if changes should be split into multiple logical commits 3. For each commit: - Follow the rules in @docs/development/commit-guidelines.md - Stage relevant files with `git add` - Create commit with appropriate emoji prefix and message 4. Verify each commit was successful before proceeding to the next
カスタムスラッシュコマンドを定義しておくと、Claude Code上で /git-commit を実行するだけで、AIがコミットルールに従って適切なコミットを作成してくれます。
コミットルールの定義
AIに一貫したコミットメッセージを生成させるため、プロジェクトにコミットガイドラインを用意しています。絵文字プレフィックスは Goodpatchさんの記事 を参考にしました。
## Commit Guidelines - Use **English** for commit messages ## Emoji Prefixes Use emoji prefixes to categorize commits: - 🐛 `:bug:` - Bug fix - 💪 `:muscle:` - Feature improvement - ✨ `:sparkles:` - Partial feature addition - 🎉 `:tada:` - Major feature addition - ♻️ `:recycle:` - Refactoring - 🚿 `:shower:` - Remove unnecessary features - 💚 `:green_heart:` - Test or CI fix - 👕 `:shirt:` - Lint error or code style fix - 🚀 `:rocket:` - Performance improvement - ⬆️ `:up:` - Dependency update
AIは差分を分析し、コミットガイドラインに従ってコミットメッセージを生成します。
本記事では、PRでのUI差分可視化とリグレッション防止を実現する Compose Preview Screenshot Testing 導入と CI 自動化で紹介している内容を実装した際に作成したコミットとPRを例として紹介します。
次のコミットは、スクリーンショットテスト検証ワークフローを実装した際の実際のコミット例です。
💚 Add screenshot test validation workflow for debug builds This commit introduces a new workflow_call workflow that validates screenshot tests and provides detailed PR comments when tests fail. Key features: - Runs validateDebugScreenshotTest to verify screenshot consistency - Backs up reference screenshots before validation - Generates actual screenshots using updateDebugScreenshotTest on failure - Creates a comparison table comment on PRs showing expected vs actual differences
また、変更が複数の論理単位に分けられる場合、AIが自動的に適切な粒度でコミットを分割してくれます。同じPR内では、次のようなコミットも生成されました。
💚 Reference screenshot images by commit hash and cleanup after tests pass - Capture and output commit hash after pushing comparison images - Use commit hash in GitHub blob URLs with ?raw=true parameter - Add cleanup step to delete *_actual.png files when tests pass
ポイント: コミットメッセージに情報が豊富に残ることで、後からPRを作成する際の素材になります。
より効果的に活用するために
差分だけでは意図が伝わりにくい場合は、次のような工夫をするとより効果的です。
- コマンドの後に説明を追加:
/git-commit この変更はパフォーマンス改善のためのように軽い説明を追加すると、AIが意図を読み取ってコミットメッセージに反映してくれます - コード内にコメントを追記: 変更の意図をコードコメントとして残しておくと、AIがそれを読んでコミットメッセージに含めてくれます。コメントはチームメンバーにも伝わるため、一石二鳥です
Step 3: AIにPull Requestを作成させる
コミットが完了したら、次はPRの作成です。PR作成でもAIを活用することで、詳細な説明文を効率よく作成できます。
PRの自動生成もワンコマンドで
コミットと同様に、PR作成もカスタムスラッシュコマンドで実行できるようにしています。
.claude/commands/create-pull-request.md に次のようなコマンドを定義しています。
--- description: Create a draft pull request for GitHub with Asana task link allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*), Bash(git push:*), Bash(gh pr create:*), Bash(gh pr list:*), Read --- Create a draft pull request for the GitHub repository. ## Context - Current branch: !`git branch --show-current` - Git status: !`git status` - Recent commits on this branch: !`git log --oneline -10` ## User Confirmation Required Before creating the PR, confirm the following with the user: 1. **Base branch**: Ask if the base branch should be the nearest future `release/yyyy-MM-dd` branch. If a branch is specified, use that as the base branch. 2. **Asana task URL**: Ask for the Asana task URL. The URL must be in the project format: `https://app.asana.com/1/xxxxxxxxxxxxx/project/xxxxxxxxxxxxxxxx/task/xxxxxxxxxxxxxxxx?focus=true`. If the user provides a URL without `project` in the path, request the correct format. ## Guidelines - **PR title**: Follow @docs/development/commit-guidelines.md for emoji prefix and format - **PR body**: Follow @docs/development/pull-request-guidelines.md for language and structure rules - **Template**: Use @.github/PULL_REQUEST_TEMPLATE.md as the base ## Instructions 1. Replace `Please_add_the_Asana_task_link_here` with the confirmed Asana task URL 2. Replace `Add_self_check_items_here` with specific test items based on the code changes 3. Write Summary and Details sections in Japanese with concise bullet points 4. **Show the PR content preview to the user** (title and body) and ask for confirmation before creating 5. Create the PR as a **draft** only after user approval
Claude Code上で /create-pull-request を実行すると、Claude Codeがユーザーに必要な情報（ベースブランチ、タスクURL）を確認しながら、テンプレートに沿ったPRを作成してくれます。
PRテンプレートとの連携
GiftmallのAndroidアプリプロジェクトではGitHubのPRテンプレートを活用しており、Claude CodeがPRテンプレートに沿って内容を埋めてくれます。
## :memo: Summary <!-- Claude Codeが変更の概要を記述 → 人間がチェック --> ## :wrench: Type of this change <!-- PR-Agentが自動生成（PR作成後に自動で埋まる） --> ## :technologist: Details <!-- Claude Codeが補足説明を記述 → 人間がチェック --> ## :robot: AI generated details <!-- PR-Agentが自動生成（PR作成後に自動で埋まる） --> ## :ballot_box_with_check: Checklist - [ ] Have asana task - Please_add_the_Asana_task_link_here - [ ] Self-verified test cases - [ ] Run the app on devices <!-- Claude Codeが変更内容に基づいてチェック項目に置換 → 人間がチェック --> - [ ] Add_self_check_items_here
Summary、Details、Checklistの各項目はClaude Codeが生成しますが、内容が正しいかを人間がチェックし、開発の背景などコードからは読み取れない部分は補足したうえでPRを作成します。
「AI generated details」セクションは、PR作成後にPR-AgentというAIレビューツールが自動的に詳細な変更説明とウォークスルーを生成して埋めてくれます。PR-Agentの詳細については、私が書いたエンジニアブログの記事をご覧ください。
なぜPRの詳細な説明が重要か
PRに詳細な説明があることで、次のようなメリットがあります。
- コードレビューがスムーズになる
- 将来の参照時に「なぜこの変更をしたか」がわかる
- ブログの素材として最適な状態で情報が蓄積される
- タスク管理ツール（Asana）との連携で文脈が追跡可能
Step 4: PRからブログドラフトを生成する
Step 2とStep 3で、コミットメッセージとPRに詳細な情報が蓄積されました。蓄積されたコミットメッセージとPRを素材として、ブログドラフトを生成します。
PRがブログ素材になる理由
PRがブログ素材になる理由として、PRには技術ブログに必要な要素がすでに揃っています。具体的には次の情報が含まれています。
- 技術的な背景と課題
- 採用したソリューションと理由
- 実際のコード例
- 考慮した代替案や注意点
これらはまさに、読者が知りたい情報そのものです。
AIによるブログドラフト生成
PRの内容とコードの差分をAIに渡すことで、ブログドラフトが生成できます。
スクリーンショットテスト検証ワークフローのPRから生成されたドラフトの例を紹介します（一部省略）。
## GitHub ActionsでスクリーンショットテストのCI/CDを構築した話 ## 背景 Androidアプリ開発において、UIの見た目が意図通りかを検証するスクリーンショットテストは重要です。 しかし、ローカル環境とCI環境で生成される画像にバイナリ差分が発生し、テストが不安定になる問題がありました。 ## 解決したかった課題 - ローカルとCI環境での画像バイナリ差分 - テスト失敗時の原因特定の難しさ - 比較画像の手動管理の煩雑さ ## 実装のポイント ### Docker環境での一貫性確保 環境差分を解消するため、Docker環境でテストを実行するようにしました... ### ImageMagickによる差分画像生成 テスト失敗時に Expected / Actual / Diff の3カラム比較をPRコメントに自動投稿... ## 学んだこと - CI環境での画像生成は環境依存が大きい - 差分の可視化がレビュー効率を大幅に向上させる - [skip ci] の活用で無限ループを防止できる
このように、AIはPRの情報をもとに「背景」「解決したかった課題」「実装のポイント」「学んだこと」といった技術ブログの基本的な構成を自動で組み立ててくれます。
Step 5: 人間がフィードバックしてAIに修正させる
AIが生成したドラフトは完璧ではありません。Step 5では、人間がフィードバックを出しながらAIと協力して記事をブラッシュアップしていきます。
ドラフトの確認とフィードバック
AIが生成したドラフトを読み、不足している情報や修正が必要な箇所を確認します。人間が直接文章を書き換えるのではなく、AIに修正指示を出して修正させます。
必要に応じた追加調査
技術的な補足が必要な場合は、GeminiやChatGPTなどのDeep Researchを活用して外部情報を収集します。
- 公式ドキュメントの参照
- ベストプラクティスの確認
- 類似事例の調査
調査結果を踏まえて、AIに「この情報を追加して」「この部分をもっと詳しく」といった指示を出し、記事をブラッシュアップしていきます。
重要: AIが出力した内容の正確性は、必ず人間がチェックします。
Step 6: 校正と最終チェック
記事の内容が固まったら、最終段階として校正とチェックを行います。
AIによる校正
AIは文章全体を俯瞰して、人間が見落としがちな細かい点をチェックしてくれます。
- 表記ブレのチェック: 「する」と「します」の混在、専門用語の表記揺れなどを検出
- 矛盾した記述のチェック: 前半と後半で異なる説明をしていないか確認
- 読みやすさの改善提案: 長すぎる文の分割、わかりにくい表現の言い換えを提案
- 表現の中立性: 直接的な差別表現や攻撃的な言葉遣いを避け、感情的になりにくい文章を生成
AIによる校正は網羅的で高速です。また、AIは直接的な差別表現や攻撃的な言葉遣いを避ける傾向があり、感情的になりにくく中立的なトーンで文章を生成してくれます。こうした特性を活かすためにも、ブログ執筆にAIを活用する価値があります。
一方で、AIには限界もあります。技術的な正確性や文脈の妥当性までは判断できません。また、比喩表現や間接的な表現が意図せず問題になるケースなど、社会的なインパクトを完全には理解できない場合があります。AIだけでは判断できない部分があるため、後述の人間によるチェックが不可欠です。
人間による最終チェック
AIの出力をそのまま公開するのではなく、複数の観点でチェックを行います。弊社の場合、エンジニアブログの公開までに次の3段階のチェックフローがあります。
1. 書いた本人のセルフチェック
まず、記事を書いた本人が内容を確認します。実際に手を動かした本人だからこそ気づける点があります。
- 事実の正確性: コードや設定値が正しいか、手順に抜け漏れがないか
- 技術的な説明の正確性: 誤解を招く表現や不正確な説明がないか
- 構成のわかりやすさ: 読者にとって自然な流れになっているか
2. 他のエンジニアによるレビュー
次に、他のエンジニアがレビューを行います。第三者の視点を入れることで、書いた本人には気づきにくい問題点が見つかります。
- 技術的な観点での確認: より良い実装方法や代替案がないか
- 説明の過不足: 前提知識がない読者にも伝わるか、逆に冗長すぎないか
- 追加の知見: 社内で共有すべき関連情報がないか
3. コーポレート観点での人事チェック
最後に、人事担当者が会社としての公開基準を満たしているか確認します。
- ブランドガイドラインへの準拠: 会社のトーンや表現ルールに沿っているか
- 機密情報のチェック: 公開すべきでない情報が含まれていないか
- 対外的な表現の適切さ: 会社の公式発信として問題ないか
この3段階のチェックフローを経て、技術面・コーポレート面の両方からチェックを受けることで、品質を担保しています。
Step 7: 公開
すべてのチェックが完了したら、いよいよ公開です。
社内レビューを経て承認された記事は、エンジニアブログとして公開されます。AIがドラフト生成から校正までサポートしてくれるため、公開までのリードタイムが大幅に短縮されます。
コミット・PRから書いた記事
本記事で紹介した方法を活用して、実際に次のブログ記事を執筆しました。
- 自然言語とAI活用で保守性を高めるArbigentによるモバイルUIテスト自動化
- PRサマリの自動生成とプロジェクト固有のルールに基づくAIレビューを実現するPR-Agent導入ガイド
- PRでのUI差分可視化とリグレッション防止を実現する Compose Preview Screenshot Testing 導入と CI 自動化
これらの記事は、開発作業で作成したコミットやPRを素材として、AIにブログドラフトを生成させる方法を活用しています。
このブログ記事ができるまで
この記事自体は、コミットやPRが元になっているわけではありませんが、同様にAIを活用して書きました。その過程をご紹介します。
1. 執筆のきっかけ
最近、私は毎週のようにエンジニアブログのレビュー依頼を人事に送っていました。すると人事から「すごい頻度ですね！素晴らしい！」と言ってもらえました。
その理由をSlackで説明しようとメッセージを書いている中で、「この方法自体がブログになるのでは？」と思いつき、この記事を書くことにしました。
2. AIにブログドラフトを生成させる
「AIを活用した開発ワークフローでブログの投稿頻度を上げる」というテーマで、AIに最初のドラフトを生成させました。
最初に渡したメモは次の内容です。
- AIにコミットさせる -> コミットに情報が残る - AIにPRを作らせる -> コミット履歴と差分を元にPR bodyが作成できるのでそれなりの情報量のPRが作れる - PRに説明がいっぱい残っている -> Pull requestと実際のコードを元にするとブログドラフトが作りやすい - AIにブログドラフト作らせる -> これ外部向けに調整すれば公開できそう -> エンジニアブログの投稿頻度が上がる - Deep Researchで情報収集 -> markdown出力 - 調査したmarkdownを元にしてAIにブラッシュアップさせる -> 出力されているソースなどを元に情報が正しいかを自分でチェック - 細かい表記ブレ、矛盾チェックなどの校正もAIにやらせる -> 自分で最終チェック
このメモをAIに渡すと、メモの内容を元に構造化されたドラフトが生成されました。ただし、最初のドラフトにはいくつかの課題があったため、フィードバックを出して改善していきました。
3. 人間がフィードバックしてAIに修正させる
最初のドラフトには、いくつかの課題がありました。
課題1: カスタムコマンドの具体例がない
最初のドラフトでは claude commit という一般的な例しかありませんでした。そこで次のように指示しました。
実際にcommitするのは /git-commit 、Pull requestの作成は /create-pull-request を使ってコマンド一発で実行できるようにしているので、その内容を元にしてブログ記事を修正してください
この指示を受けて、AIはプロジェクト内のガイドラインやテンプレートを参照し、具体的なコマンド定義やコミットルール（絵文字プレフィックス）を記事に反映しました。
課題2: フローが飛びすぎている
最初のフローは「ドラフト生成 → 人間が最終チェック → 公開」と簡略化されすぎていました。そこで次のように指示しました。
ドラフトを元に情報が不足していそうなら人間が補完（Deep Researchによる調査と記事修正、校正など）を良い感じに組み込んでください
この指示を受けて、AIはフロー図を詳細化し、「情報補完」と「校正」のステップを追加しました。
課題3: 表現が不正確
「追加作業がほぼ不要」という表現は、人間の作業が全くないように誤解される可能性がありました。そこで次のように指示しました。
追加作業がほぼ不要はちょっと違うので、自分で一から書くのに比べてコストが低いという趣旨にしてほしいです
課題4: AIっぽい文章表現
AIが生成した文章には「〜です：」のように文末をコロンで止めて箇条書きに続ける表現が多用されていました。これは人間があまり書かないスタイルです。そこで次のように指示しました。
「：」で止めて下に書くスタイルは人間はあまり書かないのでちゃんと文章にしてほしいです
この指示を受けて、AIは「〜です。」と文として完結させる形に修正しました。ただし、箇条書きのほうが分かりやすい箇所は箇条書きを維持しています。
課題5: 「以下」という表現の統一
AIは「以下のような」「以下の」という表現を多用しがちですが、「次のような」「次の」のほうが自然な場合があります。そこで次のように指示しました。
「以下のような」という表現を「次のような」に変えてください
課題6: 主語が不明確
「次は、先ほどの〜の例です」という文は主語が曖昧でした。そこで次のように指示しました。
「次は、先ほどの」だと主語がわからないので主語がわかるようにしてください
この指示を受けて、AIは「先ほどの〜の例を紹介します」と修正し、文として自然な形にしました。
課題7: ワークフローの説明が不正確
最初のドラフトでは「Deep Researchで情報を補完し、人間が加筆・修正」という説明でしたが、実際のワークフローとは異なっていました。そこで次のように指示しました。
Deep Researchを使うことは必須ではなく、必要に応じて調査し、その結果を踏まえてAIに指示をして修正していくイメージです。人間が加筆・修正も人間がAIに指示をしながら都度修正していくイメージで、基本的にはAIに文章を修正させます。
この指示を受けて、AIは「人間がフィードバックしてAIに修正させる」という表現に統一しました。
課題1〜7は一例ですが、他にも細かいフィードバックを繰り返しました。このように、人間がフィードバックを繰り返すことで、より正確で実用的な記事に仕上がっていきます。
4. 校正と公開
AIによる表記チェックと、人間による事実確認・最終調整を経て、この記事が完成しました。
Step 1〜7で説明したように、AIが生成したドラフトを土台に、人間がフィードバックしてAIに修正させるというプロセスが、AIを活用したブログ執筆の核心です。
この方法のメリット
AIを活用したブログ執筆を導入することで得られるメリットを紹介します。
1. ワンコマンドで実行可能
カスタムスラッシュコマンドを定義することで、/git-commit（コミット）や /create-pull-request（PR作成）のように、複雑な操作も一発で実行できます。
2. 一から書くよりコストが低い
ゼロからブログを書く場合、「何を書くか」「どう構成するか」から考える必要があります。しかしAIを活用したブログ執筆では、開発作業の中で自然と素材が蓄積され、AIがドラフトを生成してくれるため、人間は情報の補完と校正に集中できます。
3. 技術的に正確
実際のコードとPRに基づいているため、「実装してみたら違った」という齟齬が起きません。
4. チーム全体で一貫性を保てる
ガイドラインとテンプレートをリポジトリに配置することで、誰がAIを使っても同じ品質のコミットメッセージやPRが作成されます。
5. 投稿頻度の向上
ブログ執筆のハードルが下がることで、チーム全体のアウトプット量が増加します。
6. ナレッジの蓄積
コミットやPRに詳細な情報が残ることで、ブログ以外にも社内ドキュメントとして活用できます。外部公開しない社内向けドキュメントの場合は、対外的な表現の調整やコーポレートチェックが不要な分、より気軽に作成できます。
さらなる改善の可能性
GiftmallのAndroidアプリプロジェクトではまだ実践していませんが、ブログ執筆に関する基準やガイドラインを用意しておけば、Claude CodeのSkillsを活用してさらに精度の高いドラフトを生成できる可能性があります。
例えば、次のような基準をSkillsとして定義することが考えられます。
- 記事の構成パターン（背景→課題→解決策→学び）
- 文体やトーンのルール
- 技術記事で避けるべき表現
- 読者層に応じた説明の粒度
Skillsとしてブログ執筆基準を定義しておくと、AIがドラフト生成時に基準を参照するため、最初から品質の高いドラフトが期待できます。Step 5のフィードバック回数を減らせる可能性があり、今後試してみたいアプローチです。
まとめ
AIを活用したブログ執筆は、単にブログ執筆の効率を上げるだけでなく、知見の共有を自動化する仕組みとしても機能します。
開発 → /git-commit → /create-pull-request → ブログドラフト生成 → 情報補完 → 校正 → 公開
AIに任せる部分と人間が担う部分を明確に分けることがポイントです。
| フェーズ | 主な担当 | 内容 |
|---|---|---|
| コミット・PR作成 | AI | カスタムコマンドで自動化 |
| ブログドラフト生成 | AI | PRの情報を元に構成 |
| 情報補完 | 人間 → AI | 人間がフィードバックし、AIが修正 |
| 校正 | AI + 人間 | AI校正後、人間が最終確認 |
カスタムスラッシュコマンドとガイドラインをリポジトリに配置することで、チーム全体が同じ品質でAIを活用したブログ執筆を実践できます。必要なのは次の3つだけです。
- コミットガイドライン (
docs/development/commit-guidelines.md) - PRテンプレート (
.github/PULL_REQUEST_TEMPLATE.md) - カスタムスラッシュコマンド (
.claude/commands/)
この一連の流れをAIがサポートすることで、エンジニアは本来の開発作業に集中しながら、自然とアウトプットを増やすことができます。AIが生成したドラフトを土台に、人間がフィードバックを返しながらAIに修正させることで、正確で価値のあるブログ記事が効率よく作成できます。
ぜひ皆さんも、日々の開発にAIを取り入れて、エンジニアブログの投稿頻度を上げてみてはいかがでしょうか。
