ある朝、いつものように作業報告を書きながら、ふと手が止まりました。昨日と同じ言い回し、同じ構成。これはもう、私が頭を使って書く必要のない文章ではないか——そう気づいたのが、日常業務を Gemini API に任せ始めたきっかけでした。
エンジニアの一日には、驚くほど多くの定型タスクが紛れています。朝の進捗報告、PR の説明文、議事録のまとめ、リリースノートの生成。どれも手順がほぼ決まっていて、判断のいらない作業です。
こうした作業をプログラムから Gemini API に渡してしまえば、空いた時間を本来考えるべきことに回せます。自動化に向くタスクの見極めから最初の実装までを、私自身がつまずいた点も添えながら、順を追って見ていきます。
自動化すべきタスクを見極める3つの基準
すべての業務を自動化する必要はありません。以下の3つの条件を満たすタスクが、AIによる自動化の最適な候補です。
繰り返し頻度が高い: 週に3回以上行っている作業は、自動化の投資対効果が高いです。たとえば毎朝の進捗報告や、PRごとの説明文作成がこれに該当します。
手順が決まっている: 毎回ほぼ同じ操作を行うタスクは、プロンプトのテンプレート化が容易です。議事録の要約やエラーログの初期分析などが典型例です。
判断がほとんど不要: 「考えなくてもできる」レベルの作業こそ、AIに任せるべきです。定期レポートの数値集計や、テストケースの網羅性チェックなどがこれに当たります。
Gemini APIのセットアップ
まず、Gemini APIを使うための環境を準備しましょう。
# Python SDKのインストール
pip install google-genai
# APIキーの設定（Google AI Studioで取得）
export GEMINI_API_KEY="your-api-key-here"基本的なAPI呼び出しの構造は以下の通りです。
from google import genai
# クライアントの初期化
client = genai.Client()
# テキスト生成
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="ここにプロンプトを入力"
)
print(response.text)
# 出力: Geminiからの応答テキストモデル名は「最新を指す別名」で受けておく
コード例では gemini-2.5-flash を明示していますが、2026年時点では gemini-flash-latest という別名が用意されており、これは現在 Gemini 3.5 Flash（一般提供）を指します。日々の定型処理のように「速く・安く・そこそこ賢く」で十分な用途では、この別名を使っておくと、モデルが更新されても呼び出し側を書き換えずに追従できます。逆に、出力の再現性を厳密に保ちたい検証コードでは、あえてバージョンを固定するほうが安全です。用途によって固定と追従を使い分けるのがよいと感じています。
無人で回す自動化ほど、費用の暴走が怖いものです。私自身、深夜に走らせるパイプラインでは、AI Studio のプロジェクト単位の費用上限（spend caps）を先に設定してから本番に載せるようにしています。上限さえ引いておけば、プロンプトの取り違えで大量呼び出しが起きても、被害はその日のうちに止まります。
エンジニア業務を自動化する5つの実践例
1. PR説明文の自動生成
git diffの出力をGeminiに渡して、PRの説明文を自動生成します。
import subprocess
from google import genai
client = genai.Client()
# git diffを取得
diff = subprocess.run(
["git", "diff", "main...HEAD"],
capture_output=True, text=True
).stdout
# Geminiでpr説明文を生成
prompt = f"""以下のgit diffをもとに、GitHubのPR説明文を作成してください。
## フォーマット
- **概要**: 変更の目的を1〜2文で
- **変更内容**: 主な変更点を箇条書きで
- **テスト**: テスト方法・確認事項
## diff
{diff}
"""
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=prompt
)
print(response.text)
# 出力例:
# ## 概要
# ユーザー認証フローにリフレッシュトークン対応を追加
# ## 変更内容
# - TokenService にリフレッシュロジックを実装
# - ミドルウェアでトークン有効期限チェックを追加
# ...2. コードレビューコメントの下書き
差分を渡して、レビューの観点から改善提案を生成させます。
prompt = f"""以下のコード変更をレビューしてください。
以下の観点でコメントを生成してください:
- バグの可能性
- パフォーマンスへの影響
- 可読性の改善案
- セキュリティ上の懸念
対象のdiff:
{diff}
"""
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=prompt
)
print(response.text)3. 議事録の自動要約
会議の書き起こしテキストを渡して、構造化された議事録に変換します。
transcript = """（会議の書き起こしテキスト）"""
prompt = f"""以下の会議の書き起こしから議事録を作成してください。
## フォーマット
- 日時・参加者
- 議題一覧
- 各議題の決定事項とアクションアイテム（担当者・期限付き）
- 次回予定
## 書き起こし
{transcript}
"""
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=prompt
)
print(response.text)4. リリースノートの自動生成
git logからリリースノートを生成する自動化は、特に効果が高い例です。
# 前回リリースからのコミットログを取得
log = subprocess.run(
["git", "log", "--oneline", "v1.2.0..HEAD"],
capture_output=True, text=True
).stdout
prompt = f"""以下のgit logからリリースノートを作成してください。
## フォーマット
- 新機能（Features）
- バグ修正（Bug Fixes）
- 改善（Improvements）
- 破壊的変更（Breaking Changes）※該当する場合のみ
各項目は簡潔に1行で、ユーザー目線の説明にしてください。
## git log
{log}
"""
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=prompt
)
print(response.text)5. エラーログの初期分析
大量のエラーログをGeminiに渡して、パターン分析と原因の仮説を立てさせます。
error_logs = """（エラーログの内容）"""
prompt = f"""以下のエラーログを分析してください。
1. エラーのパターン分類（種類・頻度）
2. 最も影響が大きいエラーの特定
3. 推定原因と調査すべきポイント
4. 推奨する対応の優先順位
## エラーログ
{error_logs}
"""
response = client.models.generate_content(
model="gemini-2.5-flash",
contents=prompt
)
print(response.text)自動化を始めるための第一歩
最初から完璧な自動化パイプラインを構築する必要はありません。まずは1つのタスクについて、プロンプトを作成してみることが大切です。
おすすめの進め方は、今週の業務を振り返って「これ、毎回同じことやってるな」と思うタスクを1つ選び、上記のコード例を参考にGemini APIで試してみることです。APIの利用料金はGemini 2.5 Flashなら非常に低コストなので、試行錯誤のハードルは低いはずです。
自動化が安定しない最初の壁 — 大きな diff とトークン上限
ここまでの例は、小さな変更であればそのまま動きます。ところが、ファイルを何十件もまたぐ大きな diff を渡した瞬間、応答が途中で切れたり、要点を外した要約が返ってきたりします。入力が長すぎて、モデルが全体を均等に読めていないことが主な原因です。
個人開発で Dolice Labs の記事自動投稿パイプラインを組んでいた頃、私自身、生成結果が日によって安定せず悩みました。落ち着いて切り分けてみると、整えるべき点は入力サイズと出力形式の二つだけでした。
大きな diff は一度に渡さず、ファイル単位で要約してから束ねます。
import subprocess
from google import genai
client = genai.Client()
# 変更されたファイルの一覧を取得
files = subprocess.run(
["git", "diff", "--name-only", "main...HEAD"],
capture_output=True, text=True
).stdout.split()
summaries = []
for path in files:
file_diff = subprocess.run(
["git", "diff", "main...HEAD", "--", path],
capture_output=True, text=True
).stdout
if not file_diff.strip():
continue
res = client.models.generate_content(
model="gemini-2.5-flash",
contents=f"次の変更を1〜2行で要約してください。\n\n{file_diff}",
)
summaries.append(f"- {path}: {res.text.strip()}")
# 要約だけをまとめて最終的な説明文を作る
overview = client.models.generate_content(
model="gemini-2.5-flash",
contents="次のファイル別要約から PR 説明文を作成してください。\n\n" + "\n".join(summaries),
)
print(overview.text)全文を一度に読ませるのではなく、小さく分けて要約し、その要約をもう一度まとめる。この二段構えにするだけで、長い diff でも破綻しにくくなります。
もう一つの壁は、出力の形式が毎回ぶれることです。議事録やリリースノートを後続の処理へ渡したいときは、自然文ではなく構造化された JSON で受け取ると、扱いが一気に楽になります。
from google import genai
from pydantic import BaseModel
class ReleaseNote(BaseModel):
features: list[str]
bug_fixes: list[str]
breaking_changes: list[str]
client = genai.Client()
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="次のコミットログを分類してください。\n\n" + log,
config={
"response_mime_type": "application/json",
"response_schema": ReleaseNote,
},
)
note = response.parsed # ReleaseNote 型として受け取れます
print(note.features)response_schema を指定すると、Gemini はそのスキーマに沿った JSON を返します。「たまに Markdown が混ざる」「項目名が毎回変わる」といったぶれが消えるため、自動化の後段がぐっと安定します。最初に受け取る形を決めておくことが、結局はいちばんの近道だと感じています。
まとめ — まず1つのプロンプトから始めよう
Gemini API を使った業務自動化は、特別なインフラや高度なスキルを必要としません。Python の基礎知識と API キーがあれば、今日からでも始められます。
この記事で紹介した5つのパターンの中から、自分の業務に最も近いものを1つ選んで試してみてください。リリースノートの自動生成をさらに突き詰めたい方は、git log からリリースノートを生成する実装 もあわせてご覧いただければと思います。