- AIがコードを書く時代に、エンジニアの仕事はどうなるの？
- プログラミングスキルだけでは生き残れないと感じている
- AIとどう共存していけばいいかわからない
僕は最近、個人開発でWebアプリを作っています。
ただし、コードはほとんど自分で書いていません。
AIにコードを書いてもらったら、爆速で開発が進んでいく。「自分の手でコードを書いていたら、何十倍もの時間がかかっていたぞ…」。その事実に、エンジニアとしての危機感を覚えました。
アイデアの壁打ちと要件定義はGeminiと一緒に進め、実装はClaude Codeに任せました。いわば「AI×AI」の開発体制です。
この経験を通じて強く感じたのは、「コードを書けるだけ」のエンジニアは、近い将来AIに置き換えられるということ。そして同時に、AIには絶対にできない「人間の仕事」がはっきり見えたということです。
本記事では、実際のAI×AI開発の全プロセスを共有しながら、AI時代にエンジニアとして生き残るために何が必要かを考えます。
Contents
プログラミングスキルの「現在地」が変わった
これまでの個人開発は、「言語を学び、フレームワークを選び、自分でゼロからコードを書く」のが当たり前でした。
でも今は違います。Claude CodeやGitHub CopilotのようなAIがコードを書く時代です。しかも、その精度は年々上がっていて、簡単な機能実装なら人間より速く、ミスも少ない。
では、人間のエンジニアに何が残るのか。
僕が今回の開発で実感したのは、エンジニアの役割が「What（何を作るか）」と「Why（なぜ作るか）」を定義し、AIが動ける「How（どう作るか）」に落とし込むことにシフトしているということです。
つまり、「作る人」から「設計し、判断し、決める人」への転換です。
【実践】AIとの壁打ちでアイデアを磨く
今回作っているのは、家計簿アプリのデータを分析・整形するWebアプリです。（まだ開発中です。。）
きっかけは「家計簿アプリのデータをもっと使いやすくしたい」というフワッとした思いつきでした。具体的な仕様もなければ、技術選定も白紙の状態です。
ここで僕がやったのは、AIを「壁打ち相手」として使うことでした。
Geminiと一緒に「本当に欲しいもの」を言語化する
Geminiに対して、自分の課題をそのまま投げかけました。
最初は「何か個人開発でサービスを作れないかな」という漠然とした相談からのスタートです。自分が日常で感じている「こんなことできたらいいのにな…」という不満やアイデアを、そのままGeminiに伝えていきました。
その中で「家計簿データを自動分析したい」と相談したら、Googleスプレッドシートにエクスポートできるサービスの開発を提案されたんです。正直、ビックリしたと同時に「それ、すごく面白そう」と思えました。
この壁打ちの中で、「無料版ユーザー向けにコピペでデータを整形できる機能」というキラー機能が生まれました。自分一人で考えていたら、この発想には辿り着かなかったと思います。
ポイントは、AIに「答え」を求めるのではなく、「問い」を投げかけてもらう使い方をしたことです。
「このアプリのユーザーは何に困っている？」「既存のサービスとの違いは？」「なぜ自分がこれを作る必要がある？」。こうした問いを通じて、自分でも気づいていなかったニーズが言語化されていきました。
【実践】セキュリティの判断は「人間の仕事」
アイデアが固まった段階で、次に直面したのがセキュリティの問題です。
家計簿データには個人の支出情報が含まれます。技術的にどう扱うかと同時に、倫理的な面での判断も必要になります。
AIと一緒にアーキテクチャを決める
Geminiと相談しながら、以下の方針を決めました。
- ローカル処理優先：ユーザーのデータは可能な限りブラウザ上で処理する
- サーバーレス構成：サーバーにデータを保持しない設計
- メタデータのみ保存：データベースには分析結果の概要だけを保管
「APIにデータを送信した場合、AIの学習に使われないか？」という、AI時代ならではのリスクも検証しました。
「便利さ」と「怖さ」のトレードオフに向き合う
僕がもっとも悩んだのは、「便利さ」と「怖さ」のトレードオフでした。
「家計簿の明細データをコピペで取り込める」という機能を実現したい。
でも、個人の支出データをそのままAIに投げるのは怖い。
おそらく実際に使ってくれることになるユーザーだって同じ気持ちのはずです。
この心理的な障壁を、技術でどう解決するか。
開発の初期段階、つまり壁打ちの時点から「プライバシー・バイ・デザイン」の考え方を取り入れました。アプリ側やデータベースで「何にいくら使ったか」という生データを持たないことを、仕様として最初に取り決めました。
具体的には、以下のような設計をGeminiと壁打ちしながら固めていきました。
実際にどんなセキュリティ設計をしたか
① 「データの通り道（パイプ）」に徹する設計
アプリ側で家計データを抱え込まない、「非保持型」のアーキテクチャを採用しました。
- クライアントサイド処理の優先：CSVのパースや集計ロジックは、極力ユーザーのブラウザ上で実行
- データベースへの生データ保存禁止：Supabaseには「どの年度のデータがあるか」「スプレッドシートのID」などのメタデータのみ保存。「何にいくら使ったか」という生明細は一切保存しない
- 真実のソースはGoogleスプレッドシート：データはユーザー自身のGoogleドライブ内にのみ蓄積される設計
② AI（Claude）APIとの安全な通信
「明細コピペ機能」では、どうしてもAPI（サーバー）を通過する必要があります。ここは特に慎重に設計しました。
- API学習の拒否：Anthropic（Claude）の商用APIポリシーに基づき、送信されたデータがモデルの学習に利用されないことを確認
- ステートレスな処理：Vercel上のAPI Routeに届いたテキストデータは、JSONに整形してレスポンスを返した瞬間にメモリから破棄。ログにも残さない
- 秘密鍵の隠蔽：APIキー（ANTHROPIC_API_KEY）はVercelの環境変数で管理し、ユーザー側（ブラウザ）からは絶対に見えない設計
③ 個人情報保護のための技術的工夫
- OAuth 2.0の活用：Googleのパスワードをアプリが受け取るのではなく、Google公式の認証を通じて「スプレッドシートへの書き込み権限」だけを安全に取得
- ハッシュによる重複排除：明細の重複チェックを行う際も、生データを突き合わせるのではなく、Hash(日付+内容+金額)という不可逆な文字列を使って照合。検索速度と安全性を両立
そして、「データは学習に使われません」という注意書きをあえてUI上に表示することにしました。ユーザーとの信頼関係を築くUI/UXデザインとして、「誠実に説明する」姿勢が大切だと考えたからです。
ここで感じたのは、セキュリティの「最終判断」はAIには任せられないということです。
AIはリスクを列挙してくれますが、「どのリスクを許容し、どのリスクを絶対に回避するか」を決めるのは人間の仕事になると思います。
【実践】AIを迷わせない「仕様書」を作る
設計が固まったら、いよいよ実装です。ここでClaude Codeの出番ですが、曖昧な指示を出すとAIは迷走します。
「プロンプト」ではなく「仕様書」が必要
僕が最初に学んだのは、AIに実装を任せるには「プロンプトのテクニック」よりも「仕様書の精度」が圧倒的に重要だということです。
壁打ちで決まった内容を、以下のような構成で「実装向けの設計仕様書」に再構成しました。
- システム構成図（フロントエンド・バックエンド・外部API）
- データフロー（どのデータが、どこを通って、どこに保存されるか）
- テーブル定義（カラム名・型・制約）
- UI要件（画面ごとの機能・ユーザーの操作フロー）
- 非機能要件（セキュリティ方針・パフォーマンス要件）
この仕様書をClaude Codeに渡すことで、コードの方向性がブレることなく、一貫性のある実装が進みました。
僕が実践した「2段階AI設計」
僕が工夫したのは、Geminiで概要レベルの設計をしたら、Claude Codeに実装ベースの設計に落とし込んでもらうという2段階のプロセスです。
Geminiは「何を作るか」「なぜそうするか」を整理するのが得意。
一方、Claude Codeは「実際にどう実装するか」のレベルで設計を詳細化するのが得意です。
この2つのAIの強みを使い分けることで、曖昧なアイデアが実装可能な仕様書に仕上がっていきました。
GeminiとClaude Codeを使い分けた具体的な開発フローは、こちらの記事で詳しく紹介しています。
開発中の「方針転換」もAIと一緒に
実装を進めていくと、設計段階では想定していなかった課題が出てきます。
僕の場合、実装を進めて初めて「取り込み後にデータを編集する画面が必要」「スプレッドシートは年度ごとに分けた方が運用しやすい」といった課題に気づきました。
従来の開発なら、ここで大きな手戻りが発生してモチベーションが折れるところです。
でもAIとの開発では、再びGeminiと壁打ちしてデータフローを再設計し、仕様書をアップデート（v1.0 → v2.0）して、Claude Codeに再指示するだけで済みました。
このスピード感は、一人で全部コードを書いていた時代には考えられませんでした。設計の修正コストが劇的に下がることで、「最初から完璧な設計を」と身構える必要がなくなり、「まず作って、使いながら直す」というアジャイルな開発が個人レベルでも現実的になっています。
実際、僕は別のプロジェクトで1週間でWebサービスをリリースした経験もあります。AIとの開発がもたらすスピード感は、こちらの記事でもリアルに感じていただけると思います。
AI時代のエンジニアに求められる3つの力
今回の開発を通じて、「AIに淘汰されないエンジニア」に必要な力が見えてきました。
① 要件定義力｜「何を作るか」を決める力
AIは「作り方」を知っていますが、「何を作るべきか」は決められません。
ユーザーの課題を発見し、言語化し、解決策として「これを作る」と決断する。この上流工程こそが、人間のエンジニアの最大の価値になっていきます。
プロンプトのテクニックよりも、「そもそも何を聞くか」「何を作るべきか」を考える力の方がはるかに重要です。
② 判断力｜セキュリティとUXの「最終決定者」
AIはリスクを列挙してくれますが、「このリスクは許容する」「これは絶対にダメ」という判断はできません。
また、「このUIはユーザーにとって心地いいか」「この機能は本当に必要か」といったユーザー体験（UX）の判断も、人間にしかできない領域です。
③ 熱量｜「本当に欲しいもの」を諦めない力
AIは指示されたことを正確にこなしますが、「これを作りたい」という衝動は持っていません。
自分の過去の体験や、今抱えている困りごとの中に、「こんなアプリがあったらいいな」につながるヒントが必ずあります。僕の場合は、「家計簿のデータをもっと活用したい」という日常の小さな不満がきっかけでした。
そして、開発を最後まで完遂させるのは、「自分がこれを使いたい」「この問題を解決したい」という熱量です。これは人間にしかない原動力であり、AIがどれだけ進化しても代替できないものだと思います。
まとめ｜AIは「共同開発者」になった
今回の開発で確信したのは、AIは「便利な道具」という段階をすでに超えているということです。
壁打ち相手として思考を引き出し、設計を一緒に磨き、コードを書いて実装してくれる。AIはもう「共同開発者」です。
- AIに任せるべきこと：コーディング、デバッグ、リファクタリング、テスト生成
- 人間が担うべきこと：要件定義、セキュリティの最終判断、UXの設計、「作りたい」という意志
「プログラミングを書けるだけ」のエンジニアは、残念ながらAIに置き換えられていくと思います。
でも、「何を作るか」を決め、AIを動かすための仕様を作り、最終的な判断を下せるエンジニアの価値は、むしろこれから上がっていく。
ただし、「AIにコードを書いてもらったらすぐリリース」というわけにはいきません。バグも起きるし、設計とは異なる動作をすることもあります。必ず人間のチェックは必要であることを、今回の開発を通して実感しました。
正直なところ、「自分がAIを使いこなせている」とは全然思えません。それだけAIは将来的な可能性を秘めているし、もっと社会に有意義に活用されてほしいと感じています。
だからこそ、AIの進化に不安を感じているエンジニアにこそ、一度AIと一緒に何かを作ってみることをおすすめします。「AIに仕事を奪われる」のではなく、「AIと共に仕事をする」ことに希望を見出してほしい。「コードを書く」以外に自分が持っている力に、きっと気づけるはずです。
エンジニアとしてのキャリアの選択肢を広げたい方は、こちらの記事も参考にしてみてください。
ブログでの技術発信をキャリアに活かす方法はこちら。
