<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>キャリア |</title><link>https://fehac.dev/ja/tags/%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2/</link><atom:link href="https://fehac.dev/ja/tags/%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2/index.xml" rel="self" type="application/rss+xml"/><description>キャリア</description><generator>HugoBlox Kit (https://hugoblox.com)</generator><language>ja-jp</language><lastBuildDate>Mon, 17 Aug 2026 00:00:00 +0900</lastBuildDate><image><url>https://fehac.dev/media/icon.svg</url><title>キャリア</title><link>https://fehac.dev/ja/tags/%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2/</link></image><item><title>AIはすでに開発者の仕事を奪った</title><link>https://fehac.dev/ja/blog/ai-ga-kaeta-developer-no-shigoto/</link><pubDate>Mon, 17 Aug 2026 00:00:00 +0900</pubDate><guid>https://fehac.dev/ja/blog/ai-ga-kaeta-developer-no-shigoto/</guid><description>&lt;p&gt;飲み込みにくい言葉だが、AIは開発者の仕事をこれから奪うのではない。もう奪った。&lt;/p&gt;
&lt;p&gt;毎週、AIがプログラマーを置き換えるのかを問う記事が出る。前提が遅い。
いつ置き換えるかではない。すでに置き換えた。&lt;/p&gt;
&lt;p&gt;2022年にあった仕事はもうない。残ったものには別の名前、性質、技能がある。
その名前はハーネス・エンジニアリングだ。&lt;/p&gt;
&lt;p&gt;まだAIを「導入するか」を議論している人は、すでに出発した列車に乗るかを
議論しているだけだ。&lt;/p&gt;
&lt;p&gt;これは遠い将来についての心地よい予測ではない。このフローを毎日運用して
いる私の意見だ。&lt;/p&gt;
&lt;h2 id="今の働き方"&gt;今の働き方&lt;/h2&gt;
&lt;p&gt;私はバックエンドとインフラのエンジニアだ。勤務先のAWSインフラを一人で
担当し、CDKと大量のAIハーネスでゼロから構築した。本番オンコールも担う。&lt;/p&gt;
&lt;p&gt;午前3時に障害が起きれば、鳴るのは私の電話だ。外から理論を語っている
のではない。&lt;/p&gt;
&lt;p&gt;今はほとんどコードを書かない。戦略とアーキテクチャの判断をし、自然言語で
意図を記述し、AIエージェントが実装する。&lt;/p&gt;
&lt;p&gt;diffもほとんど読まない。単体テストとE2Eテストを含む振る舞いで検証する。
そのテスト自体もAIが動かす。&lt;/p&gt;
&lt;p&gt;「もうプログラミングを知らないのでは」と思うかもしれない。違う。コードを
読むことは、私の注意の最も効率的な使い方ではなくなっただけだ。&lt;/p&gt;
&lt;p&gt;AIは機械的なレビューを私より速く、うまく行う。プログラミングはコモディティ
になった。元からそうだった。ただ値札が見えるようになった。&lt;/p&gt;
&lt;p&gt;人間のレビューは残るが、高価な場所へ移った。不可逆な変更、アーキテクチャ、
脅威モデル、IAM、コスト、そしてテストが何を証明するかだ。&lt;/p&gt;
&lt;p&gt;私がシステムを書かないなら、何を作るのか。答えはハーネスだ。&lt;/p&gt;
&lt;h2 id="作ることと直すことが安くなりすぎた"&gt;作ることと直すことが安くなりすぎた&lt;/h2&gt;
&lt;p&gt;中心の主張は単純だ。ソフトウェアを作り、直すコストが崩壊した。&lt;/p&gt;
&lt;p&gt;実装を作り直すコストがほぼゼロなら、各行を読むことは、もはや希少でない
資源への局所最適化になる。&lt;/p&gt;
&lt;p&gt;これはコンパイラ生成のアセンブリを読まなくなった移行に似ている。ただし
完全な類比ではない。コンパイラには安定した意味論と数十年の成熟がある。
エージェントは確率的だ。&lt;/p&gt;
&lt;p&gt;だからエージェントを盲信してはいけない。出力を証明し、制限し、戻せる
システムが必要だ。&lt;/p&gt;
&lt;p&gt;バグ、漏えい、状態破損、予想外のクラウド費用はLLM以前からあった。問いは
全ての失敗を防ぐことではない。どれだけ速く検知し、閉じ込め、直せるかだ。&lt;/p&gt;
&lt;h2 id="ハーネスが新しいコードになる"&gt;ハーネスが新しいコードになる&lt;/h2&gt;
&lt;p&gt;コードが使い捨てなら、信頼は別の場所に住む必要がある。そこがハーネスだ。&lt;/p&gt;
&lt;p&gt;語源はtest harnessである。部品を固定して、安全に強い負荷をかける構造だ。
エージェント時代には、受け入れ可能な範囲で動くかを継続的に答える装置全体を
指す。&lt;/p&gt;
&lt;p&gt;AIハーネスを初めて明確に説明したものとして見たのは、
だった。&lt;/p&gt;
&lt;p&gt;重要なのは大きなプロンプトではない。planner、generator、evaluator、
契約、状態を渡す成果物、フィードバックループだ。&lt;/p&gt;
&lt;p&gt;生成者と判定者を分けることが重要だ。自分の仕事をレビューするエージェントは
自分を承認しがちだ。実行中のシステムへアクセスできる懐疑的な評価者なら、
「完了」と呼ばれた偽物の機能を見つける。&lt;/p&gt;
&lt;p&gt;私のハーネスには、少なくとも次がある。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;小さなタスク、振る舞いの契約、観測可能な受入基準へ分解した仕様&lt;/li&gt;
&lt;li&gt;実装ではなく振る舞いを検証する単体、統合、回帰、E2Eテスト&lt;/li&gt;
&lt;li&gt;AI生成テストを演劇にしないための、人間が書くオラクル、不変条件、敵対的な例&lt;/li&gt;
&lt;li&gt;環境とtraceへアクセスして、利用者と攻撃者の両方として試験する独立した評価エージェント&lt;/li&gt;
&lt;li&gt;lint、型検査、テスト、build、SAST、依存関係ポリシー、インフラ検証という決定的なゲート&lt;/li&gt;
&lt;li&gt;構造化ログ、メトリクス、trace、行動につながるアラート、変更との相関&lt;/li&gt;
&lt;li&gt;feature flag、canary、使い捨て環境、安価なrollback、明示的なblast radius&lt;/li&gt;
&lt;li&gt;コスト上限、最小権限、drift detection、定期的な設定監査&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;ハーネスはvibe codingとslopの本番投入を分ける。開発者はシステムを開発する
仕事から、システムを生成できるハーネスを開発する仕事へ移った。&lt;/p&gt;
&lt;p&gt;コードは出力になった。ハーネスが製品になった。これがAI harness engineeringで、
これからの職業の基礎だ。&lt;/p&gt;
&lt;h2 id="failure-ledgerは欠けている記憶だ"&gt;failure ledgerは欠けている記憶だ&lt;/h2&gt;
&lt;p&gt;要点は、ハーネス自身が学ぶことだ。本番の意味ある障害は次の実行を変える成果物に
ならなければならない。&lt;/p&gt;
&lt;p&gt;私はこれをfailure ledgerと呼ぶ。壊れたものと、再発を防ぐか検知するために
作ったものの台帳だ。&lt;/p&gt;
&lt;p&gt;Notionで死ぬpost-mortemではない。運用データである。各項目はインシデント、
仮説、シグナル、原因、修正、テスト、アラート、版、責任者を結ぶ。&lt;/p&gt;
&lt;p&gt;RAGでもない。RAGは世界についての事実を保存する。ledgerはエージェントと
システムが世界で何をし、その判断の文脈と結果が何だったかを保存する。&lt;/p&gt;
&lt;p&gt;
は、この考えを正確に言語化している。因果的な履歴がなければ、次の障害は
証拠ではなく推測になる。&lt;/p&gt;
&lt;p&gt;有用な項目には、incident ID、commitとdeploy image、promptとモデル版、tool call、
サニタイズ済みinput、壊れたassertion、trace、metric、blast radius、作った対策を
残す。&lt;/p&gt;
&lt;p&gt;対策は単なるバグ修正ではない。回帰テスト、DB不変条件、IAMポリシー、費用アラーム、
canary、不可逆な状態変更の前の承認になり得る。&lt;/p&gt;
&lt;p&gt;ledgerはappend-onlyにすべきだ。修正は履歴の書き換えではなく新しいイベントである。
それがなければ、エージェントが何を、なぜ決め、どの過去データが判断を汚したかを
答えられない。&lt;/p&gt;
&lt;p&gt;同じ失敗から同じ教訓を二度学ばないことが目標だ。依存関係と要件は変わり、テストは
不完全であり続ける。しかし壊れたことを忘れるのは選択であって運命ではない。&lt;/p&gt;
&lt;p&gt;本当の堅牢性は肩書きの理論から来ない。本番に殴られ、毎回を記録したシステムから
来る。&lt;/p&gt;
&lt;p&gt;
&lt;/p&gt;
&lt;p&gt;エージェントでは、tool timeout、429、古いschema、順序違いのqueue、拒否された
IAM権限、部分migration、嘘をつくcache、tool出力からのprompt injectionを試験する。&lt;/p&gt;
&lt;p&gt;happy pathを完了できたかだけでは足りない。悪いデータ、遅い依存関係、取り消された
認可、成功と報告しただけの外部効果にも耐えなければならない。&lt;/p&gt;
&lt;p&gt;ledgerは起きて検知された障害からしか学ばない。静かな破損、誰も悪用していない過剰な
権限、ゆっくり漏れる費用には盲目だ。&lt;/p&gt;
&lt;p&gt;答えはより多くのハーネスだ。billing anomaly detection、データ照合、schema drift
検査、secret scanning、権限監査、blast-radius制限である。&lt;/p&gt;
&lt;h2 id="機微な部分を外注し残りをvibecodeする"&gt;機微な部分を外注し、残りをvibecodeする&lt;/h2&gt;
&lt;p&gt;「認証、決済、identityのような重要部分はどうする？」2026年に、AIの有無にかかわらず
それを手書きすべきではない。&lt;/p&gt;
&lt;p&gt;Stripe、Okta、Clerk。そこだけを専門にするチームを持つ企業は、あなたより良くやる。
機微なものを外注するのは良いエンジニアリングだ。&lt;/p&gt;
&lt;p&gt;残るのは統合、設定、ドメインデータだ。私が見る漏えいの多くは悪いコードではない。
公開S3 bucket、緩いIAM、署名を検証しないwebhook、コンポーネント間の悪いglueだ。&lt;/p&gt;
&lt;p&gt;エラー面はコードからglueへ移った。つまり正確にハーネスの領土へ移った。&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;認証、決済、identityのような機微な部分を買う。&lt;/li&gt;
&lt;li&gt;ほぼそれ以外の使い捨て部分をvibecodeする。&lt;/li&gt;
&lt;li&gt;人間の脳をテスト、観測、設定、リスク判断というハーネスへ集中する。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;これは怠慢ではない。最も高価な資源である注意の合理的な配分だ。&lt;/p&gt;
&lt;h2 id="crud開発者はもう終わった"&gt;CRUD開発者はもう終わった&lt;/h2&gt;
&lt;p&gt;予測可能なCRUDは最初にコモディティ化した仕事であり、理由がある。曖昧さが少なく、
反復的で、学習データに最もよく現れるコードだからだ。&lt;/p&gt;
&lt;p&gt;エージェントは分単位、数セントでテスト付きの最初の版を出す。requestからORM、
responseへの同じ変換を手で打つことに、エンジニア給与を使う正当な理由はない。&lt;/p&gt;
&lt;p&gt;不快な部分は、その開発者は「これから」置き換えられるのではないということだ。
すでに置き換えられた。バッジは残っても機能は残らない。&lt;/p&gt;
&lt;p&gt;職は組織の惰性で生きる。惰性は保護ではなく期限だ。一人のエージェントoperatorが
N人分のCRUD backlogを出せると会社が知れば、headcountの計算は自動で解ける。&lt;/p&gt;
&lt;p&gt;逃げ道はあるが、promptを学ぶことではない。promptは簡単だ。ハーネスを作ることを
学ぶことだ。&lt;/p&gt;
&lt;h2 id="開発者はoperatorになった"&gt;開発者はoperatorになった&lt;/h2&gt;
&lt;p&gt;まとめると、今日AIを使う「開発者」は2022年の意味での開発者ではない。operatorだ。&lt;/p&gt;
&lt;p&gt;system design、product、security、harnessを理解しない人は、気づいていなくても
すでに後ろにいる。&lt;/p&gt;
&lt;p&gt;コード入力はこの時代のパンチカードになった。遺産にならなかったものは、何を作るか、
どう構造化するか、何を測るか、いつ疑うかという基礎だ。&lt;/p&gt;
&lt;p&gt;価値の層は上に移った。下の層にしがみつく人はAPIと競争している。&lt;/p&gt;
&lt;h2 id="市場の遅れ"&gt;市場の遅れ&lt;/h2&gt;
&lt;p&gt;仕事は変わったが市場は変わっていない。多くの企業はまだLeetCode、ライブdiff review、
AIなしのsystem designで採用し、報酬を決める。&lt;/p&gt;
&lt;p&gt;仕事が変わった姿と採用が測るものの間には大きな遅れがある。&lt;/p&gt;
&lt;p&gt;だから二つのモードが必要だ。毎日は新しい方法で運用し、市場向けには面接の筋肉も
維持する。不愉快だが、市場が追いつくまで曲線の前にいる通行料だ。&lt;/p&gt;
&lt;h2 id="結論"&gt;結論&lt;/h2&gt;
&lt;p&gt;「AIは開発者を置き換えるか」という議論はもう死んだ。知らせが届いていないだけだ。&lt;/p&gt;
&lt;p&gt;置換は求人ではなく仕事の性質で起きた。コードを書くことは判断を伴うエージェントの
オーケストレーションになった。code reviewはharness engineeringになった。&lt;/p&gt;
&lt;p&gt;古い技能を守ることが賭けではない。人間に残ったもの、決定、アーキテクチャ、
ハーネス、そして動くものへの最終責任で卓越することが賭けだ。&lt;/p&gt;
&lt;p&gt;作ることと直すことは安くなった。判断はまだ高い。その対価を取れ。&lt;/p&gt;</description></item></channel></rss>