「AIに仕事を奪われる」ではなく「AIと一緒に考える」に切り替えたら、働き方が根本から変わった。
筆者はフルスタックエンジニア歴20年超。金融系Webサービスを主戦場にしてきた。
Claude（Anthropicが提供するAI）を本格的に業務導入して約1年が経った今、
何が変わり、何は変わらなかったかを正直に書く。
シニアエンジニアやリードエンジニアにこそ読んでほしい内容だ。
導入前の自分：「AIはコードを書くツール」という思い込み
最初の認識はおそらく多くの人と同じだった。
「GitHub Copilot みたいに補完してくれる便利な道具でしょ？」
だから最初はコード生成にしか使っていなかった。そしてあまり感動しなかった。
生成されるコードが「動くけど読みたくないコード」だったからだ。
コードレビューで却下するレベルの実装が平気で出てくるし、
自分で書いた方が早い場面も多かった。
半年ほどで使うのをやめかけた。
転換点：「対話の相手」として使い始めた
転機は、複雑な移行作業の設計で行き詰まったときだった。
MySQL 5.7 → 8 と Amazon Linux 2 → 2023 を同時に進める案件で、
リスクをどう分散するかの整理がうまくいかなかった。
ドキュメントに書けるほど固まっていないが、頭の中を整理したい。
そういう状態のとき、ふと Claude に「相談」してみた。
今こういう状況で詰まっています。
- AL2→AL2023 と MySQL 5.7→8 を同時に移行しなければならない
- 本番切り替え時のリスクが高いと感じているが、何が怖いのかを整理できていない
- あなたが私の立場なら、何を最初に心配しますか？
返ってきたのは「移行の手順書」ではなかった。
「あなたが怖いと感じているのはこういうことではないか」という整理だった。
- 障害発生時の原因切り分けが困難になる（2つのシステムが同時に変わるため）
- ロールバック判断基準が曖昧なまま本番に入るリスク
- 両方の知識が一人のエンジニアに依存している状態
自分の中でぼんやりしていた不安が言語化された瞬間だった。
コードを書いてもらったわけではないのに、仕事が前に進んだ。
この体験から使い方が根本的に変わった。
変わったこと① 「調査・整理」の時間が激減した
以前は技術調査に丸半日かかることがあった。
公式ドキュメント、Stack Overflow、Zenn、試しに書いたコードの検証……
全部自分でやっていた。
今は Claude に「起点」を作ってもらう。
OpenSSL 1.x → 3.x でアプリへの影響が出やすいポイントを教えてください。
特に Java + Spring Boot での注意点を中心に。
出力は「正解」ではなく「調査の地図」だ。
ここに挙げられた項目を公式ドキュメントで確認する、という使い方をしている。
重要なのは固有名詞・バージョン番号は必ず自分で検索して確認すること。
AIが出す情報を鵜呑みにして後悔した経験が自分にはある。これは絶対に守っている。
調査の速度は体感で3〜4倍になった。
変わったこと② コードレビューの視点が増えた
シニアエンジニアの仕事の中で、コードレビューは比重が大きい。
以前は自分の経験と直感でレビューしていたが、
今は書いたコードを Claude に見せて「見落としがないか」を確認するようにしている。
以下のコードをレビューしてください。
特に並行処理のバグ、N+1、エラーハンドリングの抜けを中心に見てください。
[コード貼り付け]
自分では気づかなかった視点を指摘されることが定期的にある。
「これは自分の盲点だった」と思える指摘が1〜2件は出てくる。
経験が長いほど思い込みが強くなるので、むしろシニアこそ有効だと感じる。
変わったこと③ 「一人で抱える」が減った
20年やってきて、孤立感を感じることはあった。
チームに技術的に話せる人がいない、または忙しくて相談できない、という状況だ。
いつでも相談できる「技術的な話し相手」が常にいる状態になったことで、
小さい疑問をそのまま放置しなくなった。
「これって最近の設計ベストプラクティスどう変わった？」
「この実装、5年後に保守しやすいか？」
「この方針、若手に説明するとしたら何が引っかかりそう？」
こういう問いをいつでも投げられるようになった。答えが「正解」かは別として、
考えを整理する場所として機能している。
変わったこと④ 「書く」仕事が速くなった
設計ドキュメント、障害報告書、引き継ぎ資料、提案書……
エンジニアが思う以上に「文章を書く」仕事は多い。
以前は白紙から書き始めるのが重かった。今は Claude に骨格を作ってもらう。
以下の内容で障害報告書の骨格を作ってください：
- 発生時刻：〇月〇日 〇時
- 影響範囲：〇〇機能が〇分間応答不能
- 原因：〇〇の設定ミス
- 恒久対応：〇〇
骨格に対して事実を肉付けし、自分の言葉に直すだけ。
最終的なアウトプットの質も上がった。（骨格があると構成を考えずに済むので）
変わらなかったこと：判断・責任・経験
ここが重要だ。
Claude は判断しない。私が判断する。
「このシステムを本番に出していいか」
「このアーキテクチャを選ぶべきか」
「このリスクを受け入れるか」
こういう判断は、経験と文脈と責任感の上に成り立っている。
AIが出す「推奨」は参考情報であって、判断の代替ではない。
むしろ経験20年の蓄積がある分、
「Claude の提案のどこが文脈に合っていないか」を見抜ける。
シニアエンジニアほど AI を正しく使えるのは、フィルタリング能力があるからだ。
逆に言えば、AIの出力をそのまま信じるのが危険なのは若手より経験者の方かもしれない。
「なんか変だな」という違和感を持てるかどうかが、AIの使いこなしを分ける。
実際の1日の使い方（ざっくり）
| シーン | Claudeの使い方 |
|---|---|
| 朝：その日の作業整理 | 「今日やること一覧を渡すので優先順を提案して」 |
| 調査が必要な場面 | 「〇〇の影響を教えて。公式ドキュメントで確認すべき箇所を示して」 |
| 実装中に詰まった | エラーメッセージをそのままコピペ |
| レビュー前 | 自分のコードを「まず叩いてもらう」 |
| 文書を書く必要がある | 骨格を作ってもらい、自分で肉付け |
| 複雑な判断で迷っている | 「こういう状況で自分が考慮できていないことはなんだと思いますか？」 |
まとめ：AIは「思考の外部化」ツール
1年使ってきて一番しっくりくる表現が「思考の外部化」だ。
頭の中にある情報・不安・アイデアを言語化し、整理し、
「自分が見えていないもの」を照らし出す鏡として機能する。
コードを書いてくれるだけではない。
シニアエンジニアが持つ「経験を言語化する力」と組み合わさったとき、
AIは本当の意味で仕事の質を上げるツールになる。
「AIに仕事を奪われる」という話をまだしている人がいたら、
その人はまだ「コード生成ツール」として使っているのだと思う。
相談相手・思考の外部化ツールとして使い始めると、見え方が変わる。
本記事は筆者の個人的な体験ベースです。業務の詳細は一部抽象化しています。