はじめに ── この記事で言う「本物のエンジニア」の定義
エンジニアには2種類いる、と私は勝手に思っています。本物と、ニセモノです。
先に断っておくと、これは私の中だけの区分で、しかも自分をニセモノ側に置くための区分です。他人を偽物認定するための言葉ではありません。この記事で言う本物は、次のような人を指します。
情報科学を体系的に修めていて（少なくとも修士課程レベル）、著名なOSSにコントリビュートした経験があり、技術そのものの深さで殴り合える人。
もちろん現実のエンジニアはこんなに単純に割れません。技術で勝つ人、ビジネスで勝つ人、コミュニケーションで場を動かして勝つ人がいて、実際はグラデーションです。それでも「技術一本で勝負している人」という軸を1本だけ立てると、自分がどこに立っているかがはっきりします。私はその軸では明確に偽物側で、薬学部を出てからデータの仕事に入った人間です。
で、その偽物はAI時代をどう生き残るのか。ここ1年、AIエージェントに実務を任せながら考えたことを5つに整理しました。
私は「ニセモノ」側の人間です
経歴だけ短く書きます。大学は薬学部で、CS（コンピューターサイエンス）の講義は一つも取っていません。データ分析の仕事に入ってから4年、SQLとPythonで小売のIDPOSデータを触りながら、データ基盤、Webアプリ、AWSのインフラへと守備範囲を広げてきました。計算機科学の教科書を通読したことはなく、OSSへのコントリビュートもありません。
この立ち位置は、AIエージェントが来る前は正直けっこうしんどかったです。設計の議論で前提の共有ができず、後から一人でドキュメントを読み直す時間が常に必要でした。
一方で、今の状況はむしろ有利になったと感じています。理由は、下の図の右下、つまり「深さは並、越境の広さで価値を出す」という場所の値段が上がったからです。
いちばん危ないのは左下、つまり技術も中途半端で越境もしない場所です。仕様が決まった実装だけを担当する働き方は、エージェントの守備範囲と丸ごと重なってしまう。ここから右へ抜けるための具体策が、以下の5つになんじゃないかと思ってます。
生存戦略1：ビジネス側の言葉で話せるようになる
まずこれです。技術者としての価値以前に、単純に効きます。
エンジニアの中には、ビジネス側と話すのを面倒がる人が一定数います。仕様の背景を聞かずに手元のコードだけ触り、技術的には筋が通っているのに誰も使わないものを作ってしまう。私も何度もやりました。
「技術的には面白いが、誰も使わないもの」を作った話
分析レポートの自動化をやっていた時期の話です。私は集計ロジックを汎用化することに夢中になり、指標の定義を差し替えれば何パターンでも出せる仕組みを作りました。設計としてはきれいだったと思います。
蓋を開けたら、営業が欲しかったのは「先月と比べてどの指標が動いたか」だけを書いた1枚の紙でした。汎用化した部分はほとんど使われず、私は追加の要件を聞かずに2週間を溶かしたわけです。恥ずかしい話ですが、これに気づいたのは納品後でした。
ここから学んだのは、実装の前に「誰が、いつ、何を見て、何を決めるのか」を聞き切るだけで、作る量が半分になるということ。逆に言えば、この確認をしないエンジニアは、AIがいくら速くコードを書いても間違ったゴミを速く作るだけなんです。
事業の言葉が分かると、本当に必要なものだけを作れるようになります。感謝もされるし、数字にも乗る。技術の深さで勝てないなら、まず作るものの選定精度で勝つ。ここは非CS勢にとって一番投資効率のいい場所だと思っています。
生存戦略2：「わからない」と言わない
2つ目は姿勢の話です。AIエージェントが実務に入ってから、私は「技術的に○○が分からないのでできません」と言わなくなりました。
専門外の領域でも、都度調べながらであれば一定の水準までは仕事になる。データの人間だった私が、VPCのピアリングやIAMの権限設計、コンテナのデプロイまで触るようになったのは、明らかにエージェントが隣にいるからです。以前なら「インフラは専門外なので」と言って手を挙げなかった仕事を、今は引き受けています。
だから今の時代の「分からない」は、ほとんどの場合は怠惰の言い換えだと自分に言っています。分からないと言う前に、調べて、動かして、できるところまで進めてみる。やってみればだいたい何とかなる。この一歩を出せるかどうかで、任される仕事の幅がはっきり変わりました。
責任はエージェントではなく自分が持つ
ただし、ここには絶対に外せない条件が1つあります。成果物の責任は自分が持つということです。
エージェントが100%書いたコードだろうと、レビューして通した時点でそれは自分の成果物になります。「AIが書いたので」は言い訳として存在しません。この覚悟がないまま守備範囲を広げると、単に事故を量産する人になってしまう。そして事故の話は4つ目に直結します。
専門外に踏み込むこと自体は推奨しますが、権限の強い環境（本番のIAM、課金が発生するAPI、削除系の操作）に対しては、後述の事故ラインを引いてから触ってください。
生存戦略3：とにかく色々な土俵に立ってみる
3つ目は、成果物を出すコストが劇的に下がったことを前提にした戦略です。
これまで「本業以外にも土俵を持て」と言われても、時間がなくて無理でした。今は違います。調査、構成、執筆、画像生成、レビューをエージェントに任せられるので、一人でも複数の土俵に成果物を置けるようになりました。
記事も画像もエージェントに任せて、メディアを2つ回している
直近だと、Qiita以外にも私は記事メディアを2アカウント並行で運用しています。中身の方針は最初に自分で指定しますが、調査から本文、サムネイルの画像生成までエージェントに任せていて、モデルを跨いだ相互レビューまで含めて自動で回している状態です。
ポイントは、人の持ち場を「決める・確かめる・責任を取る」の3点に絞ったことです。この3点だけ握って残りを任せると、同じ工数で立てる土俵の数が増えます。
一見エンジニアリングと関係ないことでも、やってみるとナレッジは溜まります。私の場合、メディア運用のためにエージェントの自動化基盤を組んだ経験が、そのまま本業のワークフロー設計に効きました。何かのチャンスが飛んでくることもあります。
手段は何でもいいと思います。技術記事を書く、Xで発信する、副業を受ける、個人開発を出す。エンジニアが事業側へ越境していける時代なので、本業の一本足打法をやめるだけで見える景色が変わります。
生存戦略4：絶対にミスってはいけないことから逆算する
ここが今回いちばん書きたかった話です。
私は、完璧なプログラムを組むことは、もはやグローバル基準のエンジニアでも難しいと思っています。だから偽物が「完璧を目指す」勝負に乗るのは筋が悪い。やるべきなのは、絶対にミスってはいけないことを先に決めて、そこから逆算し、その確率をほぼゼロにする方法を自分で考えることだと思っています。
Chromeですら脆弱性は出続けている
根拠はシンプルです。世界最高峰の開発体制を持つChromeでも、脆弱性の修正は途切れません。Chrome Releasesのブログを眺めれば、Stable版の更新でセキュリティ修正が継続的に公開されているのが分かります。
面白いのは、Chromiumがその現実を前提に守り方を設計していることです。有名なのがRule of Twoで、「信頼できない入力」「メモリ安全でない言語」「高い権限」のうち同時に持てるのは2つまで、という原則です。3つ揃った新規コードはChrome Security Teamが原則として承認しない、というレビュー方針として運用されています（既存の違反や例外の扱いもドキュメントに明記されています）。バグをゼロにするのではなく、3つ揃った状態でバグを踏むとCriticalやHighの脆弱性になりやすい、という構造を先に見つけて、そこに審査を集中させているわけです。
同じ発想は運用の世界にもあります。GoogleのSREの考え方では、ペースメーカーやアンチロックブレーキのような例外を除けば、可用性100%はそもそも目標として間違っている、という前提から出発します（この例はSRE bookのIntroductionに出てきます）。100%を追わない代わりに、事業として許容できるリスクからSLOを決め、そこからエラーバジェットを導く。守るラインを決めてから設計する、という順番が共通しています。
私が非CS勢に必要だと思うのは、まさにこの順番です。全体に薄く力を配るのではなく、落としてはいけないものを決めて、そこから逆算する。
まず不具合を2つに割ります。後から直せばいい不具合と、起きたら取り返しがつかない事故です。表示の崩れや文言のミス、体感が少しもたつく程度の遅さは前者で、見つけ次第直せばいい。完璧を求める相手ではありません。ただし、遅さがタイムアウトやリソース枯渇、課金の膨張に化ける規模になったら、それは後者側へ引っ越します。
一方、後者はリカバリが効きません。例えば下記のようなものがあります。
- 個人情報・認証情報の漏洩
- 認証・認可の穴
- 不可逆なデータの削除・破壊
- 課金や外部APIコールの暴走
- 本番と検証環境の取り違え
起きる経路を、自分の頭で洗い出す
ラインが決まったら逆算です。やることはひとつで、その事故がどの経路で起きるのかを自分の環境で並べること。人のチェックリストを写しても、自分のチームの権限の配り方までは書いてありません。
「不可逆なデータの削除」なら、私はこう並べました。
| 事故が起きる経路 | 塞ぎ方 |
|---|---|
| 本番の削除権限を持ったまま作業している | 環境ごとに資格情報を分け、検証用の権限では本番を消せなくする |
| 対象や環境の指定を間違える | 削除できる対象を台帳に登録し、載っていない対象は実行前に弾く |
| 消したあとに戻せない | 別アカウントにバックアップを置き、復元を定期的に試す |
もちろんこれで経路が完全に消えるわけではありません。ひとつ潰すと、その内側から小さな経路が出てきます。それでも、洗い出していない状態と比べれば確率は明らかに違います。
塞ぐ手段は、できるだけ機械側に置きます。人間の注意力に頼る設計は、エージェントが生む変更量の前であっさり破綻するからです。シークレットスキャン、権限を絞った環境でのテスト、コストのアラート、環境名の指定漏れを弾くCI。
人が見る部分も残ります。差分の全体はエージェントに一次レビューさせて、人間は権限、削除、外部送信、課金を最優先で見る。レビューの総量を増やすのではなく、事故ラインへの命中率を上げる配置にしています。
自分で考えたら、次は頼れる人に聞く
ただ、自分の頭で洗い出した経路には必ず抜けがあります。特にCSを通していない人間の想定範囲は、自分で思っているより狭い。だから私は、事故ラインと経路と対策を並べた段階で、頼れる人に見てもらうようにしています。
コツは、聞き方です。「このPR見てください」だと相手はコードの書き方を見にいってしまう。「この事故を絶対に起こしたくないので、経路の洗い出しに抜けがないかを見てほしい」と言うと、返ってくる答えが具体的になります。私はこれで、自分がまったく想定していなかった経路を指摘されたことがあります。削除だけを見張っていたら、ログや外部連携の側から本番データが出ていく経路が残っていた、という指摘でした。あのとき聞いていなかったら、確率は下がったつもりで下がっていなかったわけです。
まとめると、この生存戦略4は「絶対にミスってはいけないことを決める → 起きる経路を自分の頭で洗い出す → 経路ごとに塞ぐ → 頼れる人に抜けを潰してもらう」という順番です。完璧なコードは作れなくても、この4手を回していれば、致命的な事故の確率と影響はかなり下げられます。ゼロにはなりません。そこは正直に書いておきます。
生存戦略5：本物に殴られる場所に自分を置く
最後です。ここまでの4つを実践しても、偽物には構造的な弱点が残ります。間違っていることに気づけないという弱点です。
体系を通していない人間の理解には穴があります。しかもエージェントは、こちらの前提が間違っていても基本的に肯定してくれるし、それらしいコードを出してきます。壁打ち相手としては最高ですが、勘違いの検出装置としては信用できません。放っておくと、自信だけが増えていきます。
だから私は、本物に殴られる場所に自分を置くようにしています。具体的にはハッカソン、技術コミュニティ、記事の公開、そして自分より格上がいる副業先です。ハッカソンで自分の設計が一瞬で分解されたときは正直しんどかったですが、あれが一番安く早く穴が見つかる場でした。記事を公開してコメントで指摘をもらうのも同じ効き方をします。
社内で一番詳しい人になってしまうと、この装置が働かなくなります。居心地のいい場所にいると気づけないので、意図的に殴られに行く。これは技術の深さがない人間ほど必要な習慣だと思っています。
それでも本物に勝てない領域について
正直に書くと、この5つを全部やっても本物には勝てない領域があります。
新しいアルゴリズムやデータ構造そのものを設計する仕事、ランタイムやコンパイラのように「誰かが必ず正しく作らないと世界が壊れる」層、性能の最後の数%を削り出す最適化。ここは体系的な素養と長期の蓄積がそのまま効くので、越境で埋まる差ではありません。エージェントを使っても、正しさを自分で判定できない領域では手が止まります。
だから偽物側の戦い方は、その領域に近づかないことではなく、その領域を担う人に敬意を持って正しく頼ることだと思っています。自分が判定できないラインを認識しておくのも、事故ラインを引くことの一部です。
おわりに
まとめると、私の生存戦略は「作るものの選定で勝つ」「専門外でも止まらない」「土俵を増やす」「事故ラインを死守する」「殴られる場所に居続ける」の5つです。技術の深さで勝てない人間が、それ以外の変数を全部動かしにいく話でした。
あなたが自分を本物側だと思っているなら、この記事の内容はたぶん物足りないと思います。もし偽物側の自覚があるなら、まずは4つ目の事故ラインだけでも紙に書き出してみてください。自分が何を絶対に壊してはいけないのかを言葉にすると新しいタスクにもチャレンジしやすくなると思います。