1. はじめに
エンジニアのみなさん。突然ですが、みなさんは自己紹介で自身の仕事を何と名乗っていますか？
僕の場合、昨年12月からTypeScript + Hono.jsの技術スタックでWebサービスの開発に携わっているので、「Webエンジニア」あるいは「フルスタックエンジニア」と名乗っています。バックもフロントもインフラも、必要であれば全て巻き取る一方、「TypeScriptエンジニア」「Hono.jsエンジニア」と名乗れるほど、特定の言語・フレームワークに精通している訳でもない。"Web"も"フルスタック"も、そんな曖昧さを内包してくれるワードとして便利に利用していましたが、近頃はこれらのワードも名乗ることに違和感を感じるようになってきました。
理由は明白で、プログラミング言語を1行1文字たりとも書かなくなり、コードを直接読むことすら減りはじめているからです。AIに指示を飛ばすためのMarkdownばかり書いている自分は、"Web"も"フルスタック"も、名乗るには贅沢すぎるのではないか？「今日からお前は、Markdownエンジニアだ！」と、どこぞの油屋の主人に迫られたとしても、何の反論もできないのではないか？
そんな自問をしてみると、もっと他の表現があるような気がしてきます。ユーザーから抽出した要件をAIに過不足なく伝えるためのコンテキスト整備、Coding Agentによる実装自動化のためのハーネス設計、AIのアウトプットが人間の意図通りになっているかの検証、などなど。少なくとも、"Markdownを書く"ことにとどまらない何かを、自分は確かにしているはずです。
最近の自分が抱えている疑問・モヤモヤを出発点に、この記事では「AI時代のエンジニアのミッション・責務・求められるスキルがどのように変化し、どのような表現へと収束していくのか」を仮説として提言したいと思います。AI時代のエンジニアが「Markdownエンジニア」以外の名を見つける、その一助となれば幸いです。
2. 前提 — 各社の記事発信から読み取る、AI時代のエンジニアリングの捉え方
言うまでもありませんが、コーディングエージェントはここ1〜2年で爆発的な進化を遂げています。2024年初頭にはまだ "高性能なコード補完" 程度だったものが、2025年にはシングルプロンプトで複数ファイルにまたがる実装を仕上げるところまで到達し、2026年に入ると人間の監督を最小限に長時間稼働する自律エージェントが実用段階に入っています。
この進化の中で、AIとの協調開発の形は三段階で変化してきました。
- プロンプト: その場限りの命令を書き、出力を取捨選択する段階
- コンテキスト: 前提・参照資料・履歴を事前に整え、AIが意図どおりに動く環境を作る段階
- ハーネス: エージェントが自律的に回る環境・制約・フィードバックループそのものを設計する段階
一言で表すなら、エンジニアの役割は 「AIへの指示・命令」から「AIのための環境作り」へ と遷移していると言える訳です。
こうした変化のなかで、各社もそれぞれの立場から「これからのエンジニアの役割」を捉え、言語化しようとしています。公式発信を並べてみると、切り口や強調される点に細かな違いはあるものの、方向性は似通ったものです。
2-1. 「書く」から「制約設計・委譲・検証の一連のループ」へ
共通項を言語化すると、実装の仕事そのものが「書く」ものから「AIに委譲する」ものへと置き換わっていくことが見えてきます。ただし、委譲は「丸投げ」ではありません。委譲するには、エージェントが迷わないように事前に制約やハーネスを人間側が設計する必要があり、委譲したあとには出てきたアウトプットの妥当性を人間が検証する必要があります。制約の設計 → 委譲 → 検証は別々の作業ではなく、一本の地続きのループとしてあらわれます。
(1) 制約の設計
まず、委譲の前提として制約の設計があります。Shopifyは、エージェントを放し飼いにするのが機能しなかった一次体験として、ハーネス設計の必要性を率直に書いています。
AIワークフローを実装し始めてすぐに分かったのは、AIエージェントは軌道を外さないためのサポートを必要とすること、そして複雑なプロンプトを離散的なステップに分解したほうがはるかにうまく動くということだ。AIを数百万行のコードの中で自由に泳がせるのは、全くうまく機能しなかった。
（原文）"Once we began implementing AI workflows, we quickly learned that AI agents need help staying on track, and work much better when you break down complicated prompts into discrete steps. Allowing AI to roam free around millions of lines of code just didn't work very well."
裏を返せば、人間側で適切なコンテキストや制約を設計して渡せれば、AIが扱える仕事の幅とスピードは一気に変わります。Anthropic の 2026 Agentic Coding Trends Report が紹介する Augment Code の事例は、その具体例です。
Augment Code は、ネットワーキングプラットフォーム、データベース、ストレージインフラといったシステム向けの AI 駆動ソフトウェア開発ツールを構築するスタートアップで、Claude を用いてコンテキストに基づくコード理解を提供することで、新しいコードベースやプロジェクトに参加するエンジニアの学習曲線を平坦化した。ある エンタープライズ顧客は、CTO が当初 4〜8 ヶ月かかると見積もっていたプロジェクトを、Claude を搭載した Augment Code を使ってわずか2週間で完了させた。
（原文）"Augment Code, a startup building AI-powered software development tools for systems like networking platforms, databases, and storage infrastructure, flattened the learning curve for engineers joining a new codebase or project by using Claude to provide contextual code understanding. One enterprise customer finished a project that their CTO had initially estimated would take 4 to 8 months in just two weeks using Augment Code, powered by Claude."
(2) 委譲によって得られるリターン
制約が整った先で、実装そのものが委譲へと移ります。委譲が成功したときのインパクトは、一桁違うスケールで語られはじめています。
先ほど引いた Anthropic の 2026 Agentic Coding Trends Report には、委譲がもたらすリターンを定量で描いた事例が複数並んでいます。まず Rakuten による、Claude Code に1250万行規模の OSS（vLLM）の技術タスクを委譲した事例です。
Rakuten では、エンジニアが Claude Code の能力を複雑な技術タスクで試した——vLLM という、複数のプログラミング言語からなる1250万行のコードを含む巨大な OSS ライブラリに対する、特定の activation vector 抽出メソッドの実装である。Claude Code は単一の実行で7時間の自律作業によってそのジョブ全体を完了し、参照実装と比べて 99.9% の数値的精度を達成した。
（原文）"At Rakuten, engineers tested Claude Code's capabilities with a complex technical task: implement a specific activation vector extraction method in vLLM, a massive open-source library with 12.5 million lines of code in multiple programming languages. Claude Code finished the entire job in seven hours of autonomous work in a single run. The implementation achieved 99.9% numerical accuracy compared to the reference method."
同レポートは組織スケールでのインパクトも示しています。通信事業者TELUSでは、社内で13,000を超えるカスタムAIソリューションを構築しつつ、エンジニアリングコードの出荷を30%高速化し、総計50万時間を節約したとされます。
TELUS では、チームが13,000以上のカスタムAIソリューションを構築しつつ、エンジニアリングコードの出荷を30%高速化した。この会社は、AIとの1回のインタラクションあたり平均40分の節約をもたらしつつ、これまでに合計50万時間を節約している。
（原文）"At TELUS, a leading communications technology company, teams created over 13,000 custom AI solutions while shipping engineering code 30 percent faster. The company has saved over 500,000 hours with an average of 40 minutes saved per AI interaction."
これらは単純な「同じ仕事が速く終わる」以上のインパクトです。同レポートがAnthropicの内部研究として紹介する以下の観察は、その本質を突いています。
Anthropicの内部研究は興味深い生産性パターンを明らかにしている——エンジニアはタスクカテゴリあたりの所要時間の純減を報告しつつ、それをはるかに上回るアウトプット量の純増を報告している。このことは、AIが主に「同じ仕事を速く行う」のではなく、「より多くのアウトプットを生む」ことによって生産性向上をもたらしていることを示唆する。
（原文）"Internal research at Anthropic reveals an interesting productivity pattern: engineers report a net decrease in time spent per task category, but a much larger net increase in output volume. This suggests that AI enables increased productivity primarily through greater output—more features shipped, more bugs fixed, more experiments run—rather than simply doing the same work faster."
かつて "優先順位が落とされていた" 仕事まで含めて、アウトプットの総量そのものが跳ね上がる。制約を設計し、正しく委譲できたエンジニアの先にあるのは、この景色です。
(3) 検証の機構化
ただし、委譲と生産性向上のループは、検証を伴わなければ成立しません。「検証もAIに任せれば」と考えたくなりますが、そう都合よくはいきません。参考になるのが、Microsoft Research の "The Art of Building Verifiers for Computer Use Agents" です。この研究は computer use agents（ブラウザを操作するAIエージェント）の検証器に関する調査で、コーディングエージェントを直接扱ったものではないため参考情報ですが、評価基準（rubric）が十分に練り込まれていない検証器は、AIによる自動検証で誤判定を量産するという構図はそのまま効いてきます。
WebVoyager のゴールドな人手ラベルに対する偽陽性率は少なくとも 45%、WebJudge は少なくとも 22% である。つまり、WebVoyager が「エージェントは成功した」と言ったときの半分近くは、人間のアノテーターなら異論を唱えるということだ。もしこれらのラベルを学習に使っているなら、成功とほぼ同じ頻度で失敗を報酬として与えていることになる。
（原文）"WebVoyager's false positive rate with respect to gold human labels is at least 45%; WebJudge's is at least 22%. That means nearly half the time WebVoyager says 'the agent succeeded,' a human annotator would disagree. If you're using these labels for training, you're rewarding failure almost as often as success."
評価基準が甘いままAIにAIの出力を検証させると、人間の意図から外れた挙動——すなわちバグ——が本番に紛れ込む確率は 22〜45% の水準で跳ね上がります。これを避けようとすると結局、最後は人間が全部レビューせざるを得ず、委譲で得たはずの生産性は消えてしまいます。そうならないためにこそ、評価基準を練り込み、検証機構を人間側で設計することが、委譲を回すうえでマストの責務になります。
逆に言えば、評価基準を十分に練り込み、そのうえでアウトプットの検証・フィードバックを単発のゲートではなくループの中の機構として組み込むことができれば、制約設計・委譲・検証のループは真価を発揮し、莫大なアウトカムへと跳ね上がります。OpenAIがCodexで100万行規模のプロダクトを構築した経験は、その構図を端的に描いています。
我々はこの制約を意図的に選んだ——開発速度を桁違いに上げるために必要なものを作るためだ。最終的に100万行に達するコードを、数週間でデプロイする必要があった。そのためには、ソフトウェアエンジニアリングチームの主要な仕事がもはや「コードを書くこと」ではなく、「環境を設計し、意図を指定し、Codexエージェントが信頼できる仕事をできるようなフィードバックループを作ること」に変わったときに何が起きるのかを理解する必要があった。
（原文）"We intentionally chose this constraint so we would build what was necessary to increase engineering velocity by orders of magnitude. We had weeks to ship what ended up being a million lines of code. To do that, we needed to understand what changes when a software engineering team's primary job is no longer to write code, but to design environments, specify intent, and build feedback loops that allow Codex agents to do reliable work."
「環境の設計・意図の指定・フィードバックループの構築」——この3点が揃ったとき、人間が手を動かす量は減る一方で、プロダクトに流れ込むアウトカムは桁違いの速度で積み上がります。検証は "コードが正しいかを確かめる最終ゲート" ではなく、制約設計・委譲・検証のループを駆動し続けるエンジン部品 として機構に組み込まれてはじめて、真価を発揮するものなのです。
2-2. 「How」の追求から「What / Why」の定義へ
ここまで見てきた制約設計・委譲・検証のループを一段引いて眺めると、エンジニアが向き合うべき問いそのものが、実装の「How」という具体から、解くべき課題の「What / Why」という抽象へと上がっていることが見えてきます。
Figmaはproblem space explorationを人間の核心スキルに据えます。
AIをコスト削減の手段として見ているなら、見方を間違えている。AIは、できることのupsideを最大化する手段——より生産的になり、自分が既に持っているスキルセットをレバレッジする手段だ。
（原文）"If you're looking at AI as a way to reduce costs, you're looking at it wrong. AI is a way to maximize the upside of what you can do—to be more productive and leverage the skillset you already have."
国内でも同じ方向が語られています。CyberAgentはHowのコストが下がったことを「Whatに踏み込めるチャンス」として捉え直します。
AIによってコーディングなどの「How」のコストが劇的に下がること、これはエンジニアにとって「最大のチャンス」だと捉えています。これまで私たちは、頭の中に「作りたいもの（What）」があっても、それを実現する「実装（How）」のために膨大な時間を費やしてきました。（中略）「こんな機能があったら面白い」「この課題を解決したい」。その「What」さえ持っていれば、AIが「How」を実現する時代がやってきます。
以上のように、関心が具体から抽象へとシフトし、「制約設計・委譲・検証のループ」の構築欲求が高まった時、業務におけるエンジニアの振る舞いはどのように変化していくのでしょうか。僕の見立てですが、新たに見出された職責に対して、何を担うかを柔軟に定義し、状況に応じて変化させる振る舞い がこれまで以上に当たり前となっていくのではないかと考えています。
3. 仮説 — エンジニアの職責は Product / Platform / Evaluate の3つに分かれる
前節で紹介した変化を踏まえると、エンジニアの職責は「Product」「Platform」「Evaluate」の3つに分かれていくと予想します。この3つの職責は、トライアングル型のモデルで視覚的に表現することができます。
| 方向 | 価値を届ける先 | 仕事の塊 |
|---|---|---|
| Product | 顧客・事業 | 顧客課題・事業価値を定義し、AIエージェントが実装・運用可能な仕様とワークフローへ翻訳する |
| Platform | 開発組織・全社 | 人間とエージェントが安全・高速・再利用可能に協働できる基盤・制約・ハーネスを設計する |
| Evaluate | プロダクト品質 | AIアウトプットと実世界のアウトカムをつなげ、信頼性を定義・監査する |
3つの職責は単独で立ち現れるとは限らず、それらの組み合わせによってエンジニアの役割が描かれるようになります。例えば、参考文献に挙げた 6 つの Job Description は、いずれもトライアングル型モデル上にマッピングすることができます。
以下、これからのエンジニアの役割を表現する上で、ベースとなるであろう3つの職責について、達成すべきミッション・責務の芯・必要な能力に分解して解説していきます。
3-1. Product — 顧客と自社の事業成果を同時に最大化する
「Product」は、顧客と自社の事業成果を同時に最大化する職責です。仕事の評価軸は実装量や開発スピードではなく、顧客と自社の双方に届いた事業成果そのものとなります。
したがって、成果駆動で顧客や業務に向き合う姿勢が、Product の責務を担うエンジニアの土台となります。その上で、「何を作るのか（What）」「なぜ作るのか（Why）」を探り当てて定義する力、顧客が持つコンテキストを引き出し言語化する力、職種を越境する協働力、そしてフルスタックの実装力などが中核に据えられます。
ミッション
- 顧客の業務・事業成果（売上、採用、開発サイクルや価値到達までの時間の短縮、業務効率の向上）と、自社の事業成果（収益、新カテゴリの創出）の同時最大化を担う
- 顧客の業務フローに踏み込み、AIに任せる領域と人間が握る領域を線引きしたうえで、試作から本番までを一気通貫で組み上げる
- Evaluate の責務を担うエンジニアが定義した評価軸を使い、現場のシグナルをプロダクトやモデルの改善へと反映させる
必要な能力
- 顧客が持つコンテキストの把握力: 業務フローに踏み込み、業務上の失敗パターンとROIが最大となるポイントを見抜き、AIを当てて成果が伸びる場所を判断できる。
- AIと人間の分担を設計する力: 業務フローや仕様の中で、AIに委ねて成果が出る領域と、人間が握って関係性・判断・創造性を生む領域を線引きできる。AIへの委譲先と人間の介在ポイントを設計する。
- プロトタイプから本番運用に至るまでのフルスタック実装力: UI、バックエンド、プロンプト、コンテキスト設計、外部知識を取り込んだ回答生成、エージェントの統制までを一人で担い、価値到達までの時間を縮め、日常業務で信頼されるプロダクトに到達させられる。
- 成果を起点に自走する力: 整った要求リストがない状態でも、問いを立て、解を組み立て、実行まで運び、実装量ではなく届いた成果で評価される働き方ができる。
- 職種を越境する協働力: PM、エンジニア、デザイナー、営業、顧客との横断協働ができる。境界が薄くなった世界で、職種ラベルではなく「顧客と事業に届いた価値」で動ける。
3-2. Platform — 組織全体の生産性と改善ループの健全性を底上げする
「Platform」は、人間と AI エージェントに対して、開発から運用までのサイクルを成立させるために必要な基盤を提供し、構築した改善ループ自体が健全に回り続けることを保証する職責です。評価されるのは作った基盤の量や規模ではなく、その基盤に乗って組織全体の生産性とループの健全性がどれだけ底上げされたかです。
個別チームの開発ではなく組織スケールでの開発体験そのものを引き受ける視座が、Platform の責務を担うエンジニアの起点となります。そこに、エージェントのループを設計・実装する力、ループの内部状態を可観測にする観測設計、改善サイクルが回しやすい形でのデータ設計、合意ルールをシステムに落とすガバナンス実装、そしてセキュアな設計の組み込みを可能にする知識・経験が組み合わさり、組織の整備された開発レーンを成立させる骨格を形作ります。
ミッション
- 人間と AI エージェントに対して、安全・高速・再利用可能な形で開発から運用までのサイクルを成立させることができる、整備された開発レーンとそれを支える基盤を提供する
- 構築した改善ループ（Meta-Harness：ハーネス自体を改善するアウターループ）とガバナンスの仕組みを構築・運用し、ループそのものが健全に回り続けることを保証する
- コーディングの民主化に伴って広がるセキュリティリスクに対し、シークレット管理・権限境界設計・脆弱性検出といった基盤を整え、非エンジニアを含む全社の AI 活用を安全に成立させる
必要な能力
- エージェントシステム設計力: LLM エージェントのループを設計・実装できる。
- オブザーバビリティ設計力: ループの内部状態のうち、何を観測すれば健全性がわかるかを設計できる。
- データ設計力: 試行コード・実行トレース・評価スコアといった蓄積データを、改善サイクルが使いやすい形で設計できる。
- ガバナンス実装力: 閾値超え検知・トリガー発火・制限時間管理など、合意されたルールをシステムとして実装できる。
- セキュアな設計を組み込む力: シークレット管理・権限境界設計・プロンプトインジェクション対策・AI 生成コードの脆弱性検出といったセキュリティ要件を、開発レーンと基盤に対して最初から織り込める。
- プラットフォームをプロダクトとして設計する思考: 単なる基盤提供ではなく、開発体験やセルフサービスを「プロダクトとして」設計できる。
3-3. Evaluate — 評価基準そのものを設計・運用し続ける
「Evaluate」は、非決定論的な AI のアウトプットを「確率的システムを扱う品質工学」として扱い、評価基準そのものを設計・運用し続ける職責です。問われるのは書いた評価の本数ではなく、リリースゲートで自信を持って YES / NO を出せたか、本番のドリフトを早期に検知できたか、失敗パターンを学習の上流に戻せたかです。
「バグを見つける」のではなく「バグが発生する構造を設計する」立ち位置が、Evaluate の責務を担うエンジニアの足場となります。そこに、曖昧な「良さ」を評価基準・正解データ・採点ルールへと翻訳する設計力、評価を再現可能・分散実行可能なハーネスとして組み上げるエンジニアリング、指標の目的化を疑う懐疑的思考、評価結果を学習や製品ロードマップに対する意思決定のシグナルとして翻訳する部門横断の翻訳力が組み合わさり、Evaluate の責務の支柱を構成します。
内部品質と外部品質
「Evaluate」が向き合う品質は、性質の異なる二つの側面から成り立っています。AI が作り出した成果物そのものの設計・実装を測る 内部品質 と、その成果物がユーザーの前に出た時の振る舞いを測る 外部品質 です。それぞれが抱える問いは、次のように別物です。
| 側面 | 対象 | 主な問い |
|---|---|---|
| 内部品質 | AI が作り出した成果物そのものの設計・実装 | スコアは実態を測れているか？ 評価基準が抜け道で取り繕われていないか？ |
| 外部品質 | ユーザーの前に出るプロダクト | 内部スコアを満たしていても、ユーザー観点で意図どおり振る舞っているか？ リリースしても安全か？ |
ミッション
- 曖昧な「良さ」を評価基準・正解データ・採点ルールへと翻訳し、AI が作り出した成果物の内部品質を、第三者が再現・検証できる評価指標として測れる状態を作る
- 評価を再現可能・分散実行可能なハーネスとして組み、リリース毎の回帰検知と継続的なドリフト監視を、組織のリリース可否判断ガードとして稼働させ続ける
- 発見された失敗パターンを学習データや製品ロードマップに対する意思決定のシグナルとして還元し、Product / Platform 双方の改善ループに接続する
必要な能力
- 評価基準の設計力: 曖昧な「良さ」を評価基準・正解データ・採点ルールへと翻訳し、第三者が再現・検証できる評価指標として記述できる。
- 評価ハーネスのエンジニアリング: 分散実行でき、再現性・ノイズ耐性を担保した評価実行基盤を、設計・運用できる。
- リリースゲートの設計力: リリース毎の評価実行・ダッシュボード・ドリフト検知を「ガード機構」として組織に組み込める。
- 指標の目的化を疑う懐疑的思考: 高いスコアを安易に信じず、「なぜ高いか」「評価基準が抜け道で取り繕われていないか」を疑える。スコアが最適化され始めた時点で評価指標を更新し続け、グッドハートの法則（指標が目的化すると、その指標自体が役立たなくなる現象）に陥らない構えを取れる。
- 部門横断の翻訳力: 評価結果を単なるスコア表ではなく、リリース判断・学習の方向づけ・製品ロードマップに対する意思決定のシグナルとして翻訳できる。
なお、ハーネスエンジニアリングを組み込もうとしているエンジニアが、自然と引き寄せられる先はおそらくこの職責です。僕自身も普段は Product 寄りで仕事をしながら、Evaluate のミッション（特に内部品質の側）を意識する瞬間が、日々の仕事のなかで増えていると実感しています。
4. 実例 — 新たな役割の開拓は、すぐ近くで起きている
ここまで描いてきたトライアングル型のモデルは、海の向こうで起きている遠い話ではありません。僕の身近、つまり TOKIUM の中でも、どの職責にも自然と関心を寄せて、新たな役割を開拓していくメンバーが次々と現れています。「トライアングル型のモデル」などまだ描かれていない段階から、それぞれが自分の意思で動き始めているのです。
ここでは、Product / Platform / Evaluate の3職責に対応する社内の発信を、それぞれ簡単に紹介します。
4-1. Product 寄り — 顧客価値・事業成果に踏み込む越境
- AI駆動のプロダクトマネジメントで変わったAIエージェント開発現場の話（Product Manager・木下）— v0 / Cursor+Claude Code / Devin を使い、Product Manager 自身が仮説のプロトタイプを作り、顧客に当て、必要なら本番コードへコミットまで担う。「職種の壁を越えて顧客価値の最大化に全員で向かう」働き方の体現例
- サービスのイメージがわかないなら、バイブコーディングで作ってみればいい（Product Manager・冨永）— 経理 AI エージェントの仮説を机上の議論ではなく「まず作ってみる」で検証する。"作らないと気づけなかった" を早く確認するアプローチ
- QA・エンジニアで現場目線を持つということ（QA Engineer・石川）— 営業経験を活かし、「業務への影響度」「操作性」という顧客視点を QA のテスト設計に組み込む。QA 側から Product 職責へ比重を寄せる動き
4-2. Platform 寄り — 基盤・ハーネス・整備された開発レーンの設計
- AIによる開発の民主化を支えるコンテキスト管理と、民主化の中で起きていること（Web Engineer・東）— コンテキスト管理を「スコープ」と「安定性」の2軸で体系化し、エンジニア以外の職種も AI エージェントで開発に参加できる基盤を整える取り組み
- BPO×AIの知見から考える『人間がレビューしない率』の上げ方（CTO・西平）— 「全自動化か人手か」ではなく「どの条件なら自動化しても品質が保証できるか」という条件分解のアプローチで、人間が介入しないマージの割合を段階的に広げる設計戦略
- 仕様がわかなくてもテストをかける rspec-undefined を作ったよ（Engineering Manager・井上）— AI が事実をテストとして記述し、人間が仕様判断を担う役割分担を、gem のマッチャと集計レポートという形で基盤化した事例
4-3. Evaluate 寄り — 内部品質と外部品質の機構づくり
内部品質
-
3人で週30PR、溺れかけた開発チームがClaude Codeスキルでレビューを回した話 の
review-pattern-analysis（Web Engineer・西本）— マージ済み PR のレビューコメントを自動収集してパターンを抽出し、ガイドラインへ自動反映する仕組み。「人間に同じ指摘を2回させない」という、評価基準そのものを継続的に運用していくメカニズム
外部品質
-
Claude Codeで「新機能のシステムテスト自動実行」を実現した話（QA Engineer・富田）— Claude Code + Playwright でシステムテストを自動化。
CONVENTIONS.md/TEST-JUDGEMENT-GUIDE.md等のナレッジベースを蓄積し、AI を「新人テスター」として育てる設計 - QAチームのナレッジを「ハーネス」にする — Claude Codeでテスト設計を自動化した話（QA Engineer・西田）— Knowledge Base・Hooks・Skills の3層構造で、AI が「ルールを知っている」から「ルールを破れない」へと進化する、テスト設計自動化パイプライン
4-4. 地図がない中でも、先駆者は自分の意思で動いている
ここに挙げたメンバーに共通しているのは、「トライアングル型のモデル」のような地図を見せられたから動き始めたわけではない、ということです。それぞれが自分の目の前の仕事の中で違和感を見つけ、AI との付き合い方を試行錯誤し、気づけばこれまでにないエンジニアのあり方を体現していた、少なくとも僕の目にはそう映っています。
大きな変化に順応していくのは、決してラクではありません。使ったことのないツールを学び直し、これまで職種の外側だった領域に踏み込み、評価軸が定まっていない仕事の価値を自分で言語化しながら進む必要があります。けれども、向き合う心持ちひとつで楽しいものへと変えることができます。
TOKIUM のメンバーに共通しているのは、「新しいあり方の探索」や「新たな活躍機会の開拓」そのものを楽しむ姿勢なのです。
5. おわりに — これからのエンジニアのあり方は、エンジニア自身が創り出せる
コーディングという営みがあっという間に AI に代替されてしまったいま、「開発業務から楽しさが失われてしまった」という声を、SNS や勉強会の片隅で耳にする回数は日に日に増えています。僕自身も、同じく楽しさが失われたと感じるエンジニアの一人です。
ただ、人類史を少し俯瞰してみれば、技術の進歩によって「楽しくて、かつ経済的価値もある」営みから 経済的価値だけが先に失われていく現象 は、これまで何度も繰り返されてきました。手書きの清書、手仕事の織物、フィルム写真の暗室作業などなど。いずれも、それ自体を愛する人にとっては価値ある営みですが、社会の経済活動の主軸からは退いています。コーディングもまたその系譜のひとつだと僕は考えており、この変化は、おそらく不可逆である と、（率直に言えば）諦めざるを得ない心持ちです。
しかしその分、エンジニアの新たな活躍領域 が同時に立ち上がったこともまた事実です。Product / Platform / Evaluate という3つの職責の間の空白には、まだ発見されていない、あるいは名のついていないロールが無数に点在しているのです。これほどまでに広大な未踏領域が一気に生み出される瞬間を、再び生きているうちに経験できる確証は全くありません。コーディングで楽しさを覚えた世代が、新たな時代の最初の住人になれるチャンスが、いまここにあるのです。
そして新たな時代だからこそ、どの領域にアプローチするかは、既存の肩書きに縛られることなく エンジニア自身が、己の意思で選べる はずです。肩書きや役割は与えられるのではなく、自ら選び、自ら作り出す、そして AI が生み出した未知の世界を冒険しながら、自身が考える「これからのエンジニアのあり方」を自由に広げていくことが、2026年の我々がなすべきことではないかと、僕は思います。
失われたものを惜しむより、まだ名付けられていない領域へ一歩踏みだす。そんな前向きな気持ちで、これからのエンジニアリングに向き合う仲間が一人でも増えてくれたら、僕にとってこれほど嬉しいことはありません。
6. 参考文献
- Shopify Engineering / Introducing Roast: Structured AI workflows made easy — Obie Fernandez
- Anthropic / 2026 Agentic Coding Trends Report (PDF)
- Microsoft Research / The Art of Building Verifiers for Computer Use Agents
- OpenAI / Harness engineering: leveraging Codex in an agent-first world — Ryan Lopopolo
- Figma Blog / 6 skills every engineer needs for the AI era — Jenny Xie
- CyberAgent Developers Blog / 2028年「開発プロセス完全自動化」を見据えた、エンジニア組織の構造改革 — 長瀬憲重
各社 Job Description
- Linear / Senior or Staff Product Engineer, AI（Wayback Machine: 2026-03-25 取得）— Product 職責: 基盤モデルをプロダクトの中核に据え、構造化されたワークフローへ翻訳する役割の代表例
- OpenAI / Forward Deployed Engineer - Tokyo（Wayback Machine: 2026-02-21 取得）— Product × Evaluate 辺: 本番適用と評価駆動のフィードバックで製品・モデルのロードマップを変える役割
- OpenAI / Software Engineer, Enterprise AI Platform（Wayback Machine: 2026-03-03 取得）— Platform 職責: 安全性とコンプライアンス要件を満たすシステム、およびデータアクセス・認証基盤を担うエンタープライズ向け AI 基盤の代表例
- Anthropic / Software Engineer, Safeguards Infrastructure（Wayback Machine: 2026-03-14 取得）— Platform × Evaluate 辺: Safeguards を支える基盤システム（指標・評価システムを含む）を構築する、Platform と Evaluate を架橋する役割
- Anthropic / Research Engineer, Model Evaluations（Wayback Machine: 2026-05-03 取得）— Evaluate 職責: 曖昧な「知性」を再現・検証可能な評価指標へ翻訳し、回帰を見逃さない役割
- Apple / AI Evaluation Engineer（Wayback Machine: 2026-03-04 取得）— Evaluate 職責: 評価基準に基づく採点と LLM をジャッジとして用いる手法による品質測定、リリース前の評価ガード（内部品質 × 外部品質の両面）