Back to Blog
AI活用業務効率化GitHub CopilotChatGPTエンジニアリング生産性向上

シニアエンジニアがコードをほぼ書かなくなった理由：AI活用で変わる業務効率化の現場

シニアエンジニアがコードをほぼ書かなくなった理由：AI活用で変わる業務効率化の現場

「最近、何行コード書きました？」

半年前に後輩エンジニアにこう聞かれて、正直に答えたら驚かれた。「1日あたり手で書くのは50行もないかもしれない」と言ったら、「サボってるんですか？」と半笑いで返ってきた。

サボっていない。むしろ以前より成果物の量は増えている。変わったのは、自分の役割が「コードを書く人」から「AIに正確な意図を伝えて、その出力を検証・統合する人」にシフトしたことだ。

この記事では、自分が実際にどういうフローでAIを使い、業務効率がどう変わったかを具体的に書く。コードスニペットも手順も出し惜しみしない。

なぜシニアエンジニアほどAIの恩恵を受けやすいのか

ジュニアエンジニアがCopilotを使うと「なんか補完してくれる便利ツール」止まりになりがちだ。でもシニアになると話が変わる。

AIの出力が正しいかどうかを判断できる土台があるからだ。

AIが生成したコードのバグを見抜けるか、設計として筋が通っているかを評価できるか——これはある程度の経験がないと難しい。逆に言えば、経験があるエンジニアがAIを使うと、「考える」「判断する」「レビューする」に集中できて、「タイピングする」「検索する」「定型を書く」を大幅に省略できる。

これが、自分がコードをほぼ書かなくなった本質的な理由だ。

実際の業務フロー：AIをどう組み込んでいるか

1. 仕様をAIに投げて叩き台を作る

新機能の実装を頼まれたとき、まず自分がやることは「仕様書を読み込んで設計を考える」ではなく、仕様の要点をAIに投げて構造の叩き台を出力させることだ。

使っているのは主にClaude 3.5とGitHub Copilot Chat。用途によって使い分けている。

【プロンプト例】
以下の仕様でPythonのクラス設計を提案してください。

- ユーザーのCSVファイルをアップロードする
- 列名のバリデーションを行う（必須列: user_id, email, created_at）
- バリデーションエラーは行番号とエラー内容をリストで返す
- 正常なデータはDBに一括insert（SQLAlchemy使用）
- 処理結果はログに記録する

設計の方針：
- 単一責任の原則を守ること
- テストしやすい構造にすること
- エラーハンドリングを明示的にすること

これを投げると、ClaudeはCSVParser、Validator、DBInserter、Logger程度にクラスを分けた設計案を出してくれる。自分はその設計が妥当かを5分で判断し、修正点を伝えてコードを生成させる。

「設計を考える」のは自分の仕事だが、「設計の選択肢を洗い出す」はAIに任せる。この切り分けが肝だ。

2. コードレビューをAIに先にやらせる

チームのPRレビューをするとき、以前は全部自分で読んでいた。今はGitHubのPR差分をコピペしてCopilot ChatかClaudeに先にレビューさせる。

【プロンプト例】
以下のPythonコードをレビューしてください。
観点は以下の4点です：
1. バグ・潜在的な例外
2. セキュリティリスク（SQLインジェクション、認証漏れなど）
3. パフォーマンス上の問題
4. 可読性・命名の問題

---
（差分コードをここに貼り付け）
---

AIのレビュー結果を見てから自分でコードを読む。AIが見落としたものを自分が拾い、自分が見落としたものをAIが拾っている感じだ。レビューの品質が上がった上に、時間は以前の半分以下になった。

3. テストコードは9割AIが書く

正直に言う。テストコードを手で書くのが一番しんどかった。ロジックは頭に入っているのに、テストケースの網羅とコード量が地味に辛い。

今はこうしている。

# 実装コード（例）
def calculate_discount(price: int, user_rank: str) -> int:
    """
    ユーザーランクに応じた割引後価格を返す。
    - gold: 20%引き
    - silver: 10%引き
    - その他: 割引なし
    price が0以下の場合はValueErrorを送出
    """
    if price <= 0:
        raise ValueError("price must be positive")
    
    discount_rates = {
        "gold": 0.20,
        "silver": 0.10,
    }
    rate = discount_rates.get(user_rank, 0)
    return int(price * (1 - rate))

これをAIに渡して「pytestでテストコードを書いてください。境界値、正常系、異常系を網羅し、パラメトライズを使ってください」と依頼する。

# AIが生成したテストコード（抜粋）
import pytest
from discount import calculate_discount

@pytest.mark.parametrize("price, user_rank, expected", [
    (1000, "gold", 800),
    (1000, "silver", 900),
    (1000, "bronze", 1000),
    (1000, "unknown", 1000),
    (1, "gold", 0),          # 境界値
    (100, "gold", 80),
    (99, "silver", 89),      # int()の切り捨て確認
])
def test_calculate_discount_normal(price, user_rank, expected):
    assert calculate_discount(price, user_rank) == expected

@pytest.mark.parametrize("price", [0, -1, -100])
def test_calculate_discount_invalid_price(price):
    with pytest.raises(ValueError, match="price must be positive"):
        calculate_discount(price, "gold")

自分がやることは「このテストで本当に十分か」を判断することだけ。テストの「書く」をなくして「考える」に集中できる。

4. ドキュメント・コメントの自動生成

ドキュメント更新は後回しにしがちだったが、今は実装直後にAIに投げる習慣がついた。

【プロンプト例】
以下の関数にGoogle styleのdocstringを追加してください。
また、処理が複雑な箇所にはインラインコメントも追加してください。

（コードを貼り付け）

これだけで8割方使えるdocstringが出てくる。残り2割は自分でドメイン知識を補足する。書く時間をゼロに近づけることで、ドキュメントを後回しにしなくなったという副次効果が大きい。

5. Googleスプレッドシートの自動化もAI経由で

大学職員や業務担当者の方と仕事をすることもあるが、彼らが使うスプレッドシートのGASも今はAIで書いている。

【プロンプト例】
Google Apps Scriptで以下を実装してください：

- スプレッドシートのA列にメールアドレス一覧がある
- B列に氏名がある
- 実行すると、各行のメールアドレスに対して定型メールを送信する
- 件名：「【確認依頼】○月度報告書の提出について」
- 本文には氏名を差し込む
- 送信済みの行はC列に「送信済み」と記録して再送を防ぐ
- エラーが出た行はC列に「エラー」と記録する

非エンジニアの担当者に「こういうことしたいんですけど」と言われたら、その場でこのフローを回して5分でGASを渡せる。自分の価値は「コードが書ける」ではなく「何をどう依頼すればいいか分かる」に移行している。

変わったことと変わらないこと

変わったこと

以前 今
実装に1日かかる機能 午前中に完成
テストコードを後回しにしがち 実装直後に生成
ドキュメント更新を忘れる 実装時に同時生成
コードレビューが詰まる AIで事前精査して質が向上

変わらないこと

  • 設計の意思決定はAIに任せない。選択肢を提示させて、判断は自分でする
  • セキュリティ要件の確認はAIの出力を信用しすぎない。必ず自分でも確認する
  • コードレビューの最終判断は人間がする。AIのレビューは「一次チェック」に過ぎない
  • ドメイン知識の文脈はAIには渡せない。業務の背景を理解しているのは自分だ

「AIに使われるエンジニア」にならないために

正直、このやり方を誤解されると怖い。「AIに任せてラクしてる」ではなく、**「AIを道具として使いこなして、より上位の仕事に時間を使う」**という意識が大事だ。

自分が気をつけていること：

  1. AIの出力を必ず自分の目で検証する。テストを実際に動かす、ロジックを追う
  2. プロンプトの精度を上げ続ける。曖昧な依頼は曖昧な出力を返す
  3. AIが苦手なものを把握する。既存コードの文脈理解、非自明なビジネスルール、パフォーマンスチューニングは要注意
  4. 自分でも書ける状態を維持する。AIがなくなっても困らないよう、基礎は常に動かしておく

まとめ

シニアエンジニアがコードをほぼ書かなくなったのは、「書く」という行為の価値が相対的に下がり、「考える・判断する・統合する」の価値が上がったからだ。

AIを使う前と後で、1日に「完了した仕事の量」は体感で3倍近くになっている。でもそれは「AIがやってくれた」ではなく、「AIと自分の役割分担が最適化された」結果だと思っている。

道具は使いようだ。ハンマーを持てば全部釘に見える、と言うけれど、AIというハンマーを「自分の判断を代替するもの」ではなく「自分の生産性を増幅するもの」として使う——この意識の差が、AI時代のエンジニアの実力差になっていくと感じている。

この記事で紹介したプロンプトや手順は、自分が実際に使っているものをベースにしています。ツールのバージョンや業務内容によって最適解は変わるので、ぜひ自分の環境でカスタマイズしてみてください。

Share:
View all posts