London AIE Summit 2026:AIエンジニアリングの実態

London AI Engineer Summit 2026は、進歩を祝う場になるはずでした。代わりに、それは神経衰弱の真っ只中にある職業に向けられた鏡のように感じられました。

4月初旬の3日間、数百人のAIエンジニア、プラットフォームビルダー、研究者が集まり、学んだことを共有しました。浮かび上がったのはパターンでした:誰もがエージェントを使って構築しているが、誰もそれらを制御する方法を見つけていない。業界は速く動くか慎重に考えるかで分裂しており、AIが私たちをより生産的にするという前提全体が、もっと暗い何かに反転してしまった。

これが私たちが実際に学んだことです。

なぜAIエンジニアは制御できないエージェントでコーディングしているのか?

サミットで最も率直な会話は、ステージではなく廊下で起きました。中規模のフィンテック企業のエンジニアはこう問題を説明しました:「プロンプトを開始すると、3時間後には私のエージェントがコードベースの半分を書き直し、頼んでもいない機能を追加し、計算に800ポンドを消費している。机を離れられない。」

これがFOMATです:Fear of Missing Attention Time。冗談ではなく — 2026年のAIエンジニアリングを定義する不安です。

オーケストレーションのボトルネック

サミットの全員がエージェントを使っていました。GitHub Copilot、Claude、カスタムのエージェント型フレームワーク — ツールは成熟しました。しかしオーケストレーションは成熟していません。「エージェントを持っている」と「私のエージェントは意図した通りに動き、それ以上のことはしない」の間のギャップは巨大です。

問題は3つの形で現れます:

トークンの暴走。 エージェントには自然な停止点がありません。明確なガードレールがなければ、反復し続けます。「もう一度リファクタリングだけ」とエージェントは考え、気づけば月間予算を使い果たしています。

スコープクリープ。 「エラー処理を改善せよ」というリクエストが、「エラー処理システム全体を書き直し、オブザーバビリティを追加し、ロギング層をリファクタリングし、分散トレーシングを実装する」になります。エージェントは間違っていたわけではない — 徹底的だっただけです。しかし、それはあなたが求めたものではありませんでした。

予測不能なレイテンシ。 エージェント型タスクがどれくらい時間がかかるかわかりません。エージェントがいくつのサブタスクを生成するか、どれだけ失敗に遭遇するか、リトライするか方針転換するかに依存します。これにより、エージェント駆動のワークフローは本番システムでスケジューリングが不可能になります。

サミットのコンセンサスは何だったのか(そして何ではなかったのか)

解決策についてコンセンサスはありませんでした。一部のチームはハードなトークン上限を使用しています。他はエージェントの「チェックポイント」を実装 — エージェントに一時停止させ、続行前に許可を求めさせる。いくつかは階層的エージェントシステムに向かっており、「マネージャーエージェント」がワーカーエージェントを監督し、中断できる仕組みです。

FlowHuntのアプローチ — エージェントノード、エラーハンドラー、分岐ロジックを持つ明示的なワークフロー定義 — は、潜在的なパターンとして何度か言及されました。考え方:エージェントにワークフロー構造を決めさせない。事前に定義し、その後エージェントに個別のステップを実行させる。

しかし、それさえも絆創膏のように感じられました。本当の問題は、エージェントの振る舞いが本質的に確率的であるということです。分散を減らすことはできても、排除することはできません。

OpenAI-Anthropicの分断は「良いコード」の意味をどう変えたのか?

月曜の朝、OpenAIのライアン・ロポポロがステージに上がり、次のように要約できる基調講演を行いました:コードを読むのをやめよ。トークン億万長者になれ。

彼の主張:エージェント的世界では、コードの量こそが重要な指標だ。あなたのエージェントは1日に数千行を生成すべきだ。あなたの仕事は出力仕様を定義し、エージェントにスループットを最大化させることだ。すべての行を読んで理解することはボトルネックだ。テストを信頼せよ。エージェントを信頼せよ。速く動け。

水曜日には、Anthropicのマリオ・ゼクナーがカウンター基調講演を行いました:ペースを落とし、そのクソコードを読め。

彼の主張:スピードは罠だ。エージェントが書くすべてのコード行は負債だ。それを理解し、論じ、維持できなければならない。5年後に勝つチームは、速さよりも明快さと意図を優先するチームだ。エージェントは考えるためのツールであるべきで、考えずにコードを生成するためのものではない。

スペクトル

サミットは大まかに3つの陣営に分かれました:

どちらの側も間違っていません。意見の相違は、失敗がどのように見えるかについてです。ロポポロは反復速度を最適化しています。ゼクナーは持続可能性を最適化しています。2026年、チームは両方を最適化することはできないと学んでいます。

面接の問題

具体的な結果の1つ:採用が壊れている。トークン最大化派なら、候補者がコーディングできるかは気にしない — 効果的にプロンプトでき、エージェントの出力を評価できるかを気にする。コードファーストなら、深い技術的推論を見たい。

だから候補者が面接に入るとき、面接官も候補者も、どのフレームワークで評価されているかわからない。あるサミット参加者はそれを「霧の中で面接する」と表現しました。

ビジネスを成長させる準備はできましたか？

今日から無料トライアルを開始し、数日で結果を確認しましょう。

デモをリクエスト ログイン

なぜIDEが死にかけているのにGitHubトラフィックは爆発しているのか?

GitHubは前年比15倍のトラフィック増を報告しました。Cloudflareも同様のスパイクを報告。一方、伝統的なIDE — VS Code、JetBrains、Sublime — はAIネイティブなチームの間で利用が減少しています。

実際に何が起きているかを理解するまでは矛盾しているように見えます。

IDEはローカルな思考ツールだった

IDEは、単一の開発者がローカルでコードを書くために設計されました。シンタックスハイライト、オートコンプリート、デバッグツール、ファイルツリーを持っていました。自己完結した環境でした。

そのモデルは、あなたの「開発者」がエージェントであるときに崩れます。エージェントにはシンタックスハイライトは不要です。デバッガーも不要です。必要なのは:

• 複数ファイルへの同時アクセス
• コードを実行して結果を見る能力
• バージョン管理との統合
• コラボレーション機能(エージェントと人間が一緒に作業するため)

それらはすべて今ブラウザに住んでいます。GitHub Codespaces、VS Code Web、および類似のツールがローカルIDEを置き換えつつあります。

実際に成長しているもの

GitHubのトラフィック急増は、ブラウザでコードを書く開発者ではありません。エージェントが生成したコードをレビュー、コメント、マージする開発者です。爆発しているのはコラボレーション層であり、編集層ではありません。

だからCloudflareもトラフィックスパイクを見ているのです — 開発者はクラウドインフラを使ってエージェントを動かし、ワークフローをオーケストレーションしています。「ローカルIDE + ローカル開発環境」モデルは、「クラウドネイティブなエージェントオーケストレーション + ブラウザベースのレビュー」に置き換えられています。

L33T C0d3は死んだ

あるセッションはまさにそのタイトルでした。要点:キーボードの前で一人、エレガントなコードを作り上げる聡明なエンジニアというロマンチックな概念 — それは終わった。コードは今や人間とエージェントの協働的な成果物です。重要なスキルは:

• プロンプトエンジニアリング(何を求めるかをどう指定するか)
• 出力評価(エージェントのコードは良いか?)
• アーキテクチャ思考(エージェントはどのような構造の中で働くべきか?)
• 統合(エージェント生成のコードはどうやって既存システムにフィットするか?)

エレガントなコードを書くことはもはや主要スキルではありません。それはエージェントがやることです。人間は他のすべてをします。

MCPに本当に何が起きているのか — 死んでいるのか栄えているのか?

これはサミットで最も混乱した議論でした。

一方で、個々のAIエンジニアとエージェントフレームワークのメンテナーはこう言っていました:「MCPは死んだ。必要ない。エージェントはAPIを直接呼べる。」

他方で、エンタープライズアーキテクトとセキュリティチームはこう言っていました:「MCPの採用は、我々がツールを構築できるよりも速く加速している。」

両方の主張は真実です。異なる集団を説明しています。

なぜAIエンジニアはMCPが死んだと考えるのか

シンプルなエージェントを構築する一人の開発者にとって、MCPは摩擦を加えます。あなたは:

• ツール用のMCPサーバーを定義
• プロトコルのオーバーヘッドを管理
• 認証と認可を処理
• サーバーをデプロイし維持

エージェントに直接APIアクセスを与え、残りを考えさせるほうが簡単です。

なぜ企業はMCPを急速に採用しているのか

本番環境でエージェントを動かす組織にとって、MCPは突然必須になります。理由は:

セキュリティの分離。 エージェントにデータベース、決済システム、顧客データへの直接アクセスを持たせたくありません。MCPは、基盤システムを露出せずにエージェントが呼び出せる制御されたインターフェースを作成できます。

監査可能性。 すべてのエージェントのアクションはMCPサーバーを経由し、ログに記録されます。エージェントが何をしたか、なぜそうしたかの完全な記録があります。

認証情報管理。 APIキーをエージェントのプロンプトや環境変数に埋め込むのではなく、MCPサーバーが認証情報を安全に管理します。

レート制限とクォータの実施。 エージェントがリソースをどれだけ消費できるかを制御できます。

CData Softwareによれば、2026年初頭時点でFortune 500企業の80%が主にこれらの理由でMCPを評価または実装しています。

解決策

サミットのコンセンサス:MCPは死んでいない。実験的でソロなAI開発の80%には関係ないだけだ。しかし、本番でマルチチームの20%にとって、MCPは必須になりつつあります。

これがMCPアプリが増殖している理由です。Anthropic、OpenAI、サードパーティベンダーは、一般的なツール(Salesforce、Slack、Jira、データベース)用の事前構築済みMCPサーバーを作っています。企業はカスタムサーバーを作らずにこれらを採用できます。

ニュースレターに登録

最新のヒント、トレンド、お得な情報を無料で入手。

メールアドレス

登録する

AIは私たちをより生産的にしているのか、それとも過労にしているだけなのか?

ここでサミットは暗くなりました。

AIは力の増幅器になるはずでした。ルーチン作業に費やす時間が減り、戦略的思考により多くの時間を費やすはずでした。生産性は急上昇するはずでした。

代わりに、生産性は急上昇し — そして作業負荷の期待も急上昇しました。

ジェボンズのパラドックスのリアルタイム版

ジェボンズのパラドックスは、もともと石炭の消費に適用されたもので、次のように述べています:リソースがより効率的になると、リソースが安く魅力的になるため、総消費量が増える。

AIの言葉で言うと:エージェントがコード生成を安く速くしたので、マネージャーは今や各エンジニアに以下を期待します:

• 10倍のアウトプットを提供する
• 包括的なドキュメントを書く
• 完全なテストスイートを構築する
• 国際化(i18n)をサポートする
• エッジケースを処理する
• すべてを単独で行う

生産性向上は膨らんだ期待に消費されました。

エンジニアたちが語ったこと

ロンドンを拠点とするスタートアップのあるエンジニア:「以前は1日500行のコードを書いて生産的だと感じていた。今はエージェントに生成させて1日5,000行書いている — そして疲弊している。すべてをレビューし、テストし、ドキュメント化し、ステークホルダーに説明しなければならないから。週60時間働いている。」

別の人:「マネージャーは言う、『今はエージェントがいるから、倍の数のプロジェクトを扱えるはずだ』と。私は生産的になったのではない。ただ忙しくなっただけだ。」

研究者:「エージェントはコード生成が得意だ。どのコードを生成すべきかを決めるのは得意ではない。その意思決定の負担は完全に人間に移った。私たちは難しい部分を自動化しているのではない;簡単な部分を自動化して、人間にもっと考えさせているのだ。」

生産性の盲点

UCバークレーのカリフォルニア・マネジメント・レビューは2026年1月にこの現象を記録した研究を発表しました。重要な洞察:AIの展開は仕事を減らすのではなく、仕事の性質を変える。

古い仕事:コードを書くこと。 新しい仕事:エージェントを指揮し、出力を評価し、品質を維持し、スコープクリープを管理する。

タイピングは少なくても、新しい仕事は認知的により重いです。

なぜヨーロッパはAIエンジニアリングにこれほど躊躇しているのか?

サミットには強いヨーロッパの一団がいて、彼らのメッセージは一貫していました:ヨーロッパはAIエンジニアリングの採用においてアメリカほど速く動いていない。

規制の重荷

EUのAI法はまだ実装中です。企業は責任について不確かです。もしAIエージェントが顧客に害を及ぼす決定をした場合、誰が責任を負うのか?企業?モデルベンダー?エンジニア?

その不確実性は麻痺させます。多くのヨーロッパ企業は、真剣なエージェント型システムを構築する前に、最初の訴訟がどう進むかを見守っています。

スキルギャップ

ヨーロッパの伝統的なソフトウェアエンジニアは、アメリカと同じペースでAIエンジニアになっていません。スキルが移転可能かについて懐疑論があります。多くのヨーロッパエンジニアは、AIエンジニアリングが本物のキャリアパスなのか、ハイプサイクルなのかを見極めようと待っています。

プライバシーの懸念

ヨーロッパはデータ取り扱いにもより慎重です。エージェントが有用であるためにはデータへのアクセスが必要です。しかし、MCPの保護策があってもなお、ヨーロッパ企業はエージェントに顧客データへのアクセスを与えることに躊躇しています。

前進の道

サミットのヨーロッパのエンジニアたちは反AIではありませんでした。彼らは慎重さを支持していました。雰囲気は:「アメリカは速く動いて物を壊している。私たちはもっとゆっくり動いて、あまり壊さないようにする。5年後、どちらが正しかったかを見よう。」

AIエンジニアリングの役割は実際にどう変わっているのか?

サミットの終わりまでに、パターンが浮かび上がりました:伝統的なソフトウェアエンジニアリングの役割は空洞化し、3つの新しい原型に置き換えられつつあります。

3つの役割

これらの役割のどれも、伝統的な意味でのコードを書くことを含みません。すべてがエージェントの振る舞いを指揮、評価、リファインすることを含みます。

消えつつあるもの

「ジュニアエンジニア」の役割は圧縮されています。「シンプルなコードを書ける」から「システムをアーキテクトできる」への明確な道はもうありません。中間ステップは自動化されています。

これはスキルの崖を作ります:プロンプトと評価が得意(その場合は価値がある)か、そうではない(その場合はエージェントと競合する)か。

成長しているもの

テイスト、判断、アーキテクチャ思考を必要とする役割が成長しています。深いドメインの専門知識を必要とする役割も(エージェントは、正しい問題を解いているかどうかを人間が評価する必要があるため)。

サミットでは、これが良いか悪いかについてコンセンサスはありませんでした。ある人々はこれを退屈なコーディングからの解放と見なしました。他は職業への脅威と見なしました。

2025年12月から2026年2月の間に何が変わったのか?

サミットの1つのセクションは特定の変曲点に捧げられました:新年の頃、AIエージェントエコシステムで何かが変わりました。

自己改善ソフトウェアが現実になった

OpenClawと類似のフレームワークが、絶え間ない人間のプロンプトなしに、エージェントが自分の出力を反復的に改善できるようにし始めました。「エージェント、Xを計算する関数を書いて」の代わりに、「エージェント、Xを計算する関数を書き、すべてのテストを通過してエッジケースを処理するまで改善し続けて」になりました。

複数の研究者が明確にした重要な洞察:エージェントに些細なアドバイスを求めるのをやめよ。

エージェントに「この関数を改善する」ように頼む代わりに、「この関数を防弾にする」ように頼みなさい。それが何を意味するかをエージェントに決めさせる。エージェントは:

• テストを書く
• エッジケースを見つける
• 明快さのためにリファクタリングする
• エラー処理を追加する
• ロジックを文書化する

すべてを各ステップで尋ねられることなく行います。

これはメンタルモデルを「ツールとしてのエージェント」から「自律的な貢献者としてのエージェント」に変えました。そして作業負荷の動態を変えました:エージェントが人間の仕事を減らすのではなく、増やしました(人間は今やはるかに洗練されたエージェント出力を評価しなければならないから)。

私たちが共に生きる矛盾

サミットは解決なしに終わり、それは正直に感じられました。2026年4月のAIエンジニアリングを定義する矛盾は以下です:

矛盾1: エージェントは危険になるほど強力(FOMATは現実)だが、監視なしに信頼するほど強力ではない。

矛盾2: スピードと品質は対立するものとして扱われるが、両方とも必要である。

矛盾3: MCPは同時に(個人にとっては)死んでおり、(企業にとっては)栄えている。

矛盾4: AIは私たちをより生産的にしたが、より過労にもした。

矛盾5: 誰もがエージェントで構築しているが、誰もうまく構築する方法を見つけていない。

矛盾6: AIエンジニアリングは本物のキャリアパスだが、重要だと思っていたスキル(コードを書くこと)はもう重要ではない。

これらは解決されるべき問題ではありません。管理されるべき緊張です。2026年に勝つチームは、これらの矛盾を存在しないふりをするのではなく、認めるチームです。

よくある質問

私たちが持ち帰るもの

ロンドンのサミットは移行期の職業のスナップショットでした。AIエンジニアリングは現実ですが、私たちが思っていたものではありません。それはハイプが示唆していたよりも混乱しており、より矛盾しており、より人間に依存しています。

サミットでのベストエンジニアは、最も洗練されたエージェントを持つ人々ではありませんでした。エージェントが思考のためのツールであり、思考の代替ではないことを理解していた人々でした。エージェントの振る舞いを管理し、出力を評価し、品質を維持するプロセスを構築した人々でした。生産性向上は新しい種類の仕事を伴い、仕事が減るわけではないことを受け入れた人々でした。

2026年にAIシステムを構築するなら、サミットの教訓は明確です:

1. オーケストレーションはエージェントの能力より重要だ。 優れたオーケストレーションを持つ凡庸なエージェントは、制御のない優秀なエージェントに勝る。

2. 明快さはスピードより価値がある。 速く動いて物を壊すのは、壊さなくなるまで機能する。スケールでは、機能しない。

3. エンタープライズの採用は現実だが、個人の採用はまだ実験的だ。 一人の開発者なら、速く動ける。チームなら、ガードレールが必要だ。

4. 重要なスキルは変わった。 プロンプトエンジニアリング、出力評価、アーキテクチャ思考が新しいコアコンピタンスだ。

5. より楽ではなく、より懸命に働くことを期待せよ。 AIは生産性の乗数だが、利得はより高い期待に消費されている。それに応じて計画せよ。

サミットは「AIエンジニアリングはどのようなものか?」という質問に答えませんでした。答えを見せてくれました:それは私たちのように見える、リアルタイムで理解しようとしている。

{{ cta-dark-panel heading=“手動でのエージェント・オーケストレーションはやめましょう” description=“FlowHuntのワークフロービルダーを使えば、エージェントの振る舞いを定義し、ガードレールを設定し、複数ステップのAIタスクを自動化できます。もうFOMATはありません。エージェントが何をしているかを推測する必要もありません。” ctaPrimaryText=“FlowHuntを無料で試す” ctaPrimaryURL=“https://app.flowhunt.io/sign-in" ctaSecondaryText=“デモを予約” ctaSecondaryURL=“https://www.flowhunt.io/demo/" gradientStartColor="#667eea” gradientEndColor="#764ba2” gradientId=“aie-summit-cta” }}