はじめに
こんにちは！enechainでエンジニアリングマネージャーをしているtaniyarnです。
弊社には、World-class Conference Support Programという制度があります。 これは、社員が世界レベルの業界技術トレンドを知るために、自分の仕事に関連するテクノロジー系の海外カンファレンスに参加することを会社として支援する仕組みです。 こちらの制度を利用して、2026年3月にロンドンで開催されたQCon London 2026に参加してきました。
本記事では、現地で参加したセッションの中から特に印象に残ったものと、海外カンファレンスならではの気づきを共有します。
QConとは？
QCon Londonは、エンジニア向けメディア「InfoQ」が主催する世界最大級のソフトウェアエンジニアリング国際カンファレンスです。 今年で20周年を迎え、ロンドンを含め世界各地で開催されています。
3日間で全18トラック、約70セッションの大規模なイベントで、私は今回その中から18セッションを聴講してきました。 長めに休憩時間が取られていたり、夜には会場で懇親会を開いたりなど「カンファレンス本体ではない時間」を運営自身が非常に重視しているのが特徴で、参加者同士が気軽に交流できる雰囲気が随所に作られていました。
詳細は以下のURLからご確認いただけます。
https://qconlondon.com/
弊社のサービスを支えるアーキテクチャやエンジニアリング組織のあり方を、海外の先進企業はどう捉えているのか。 最新の知見を吸収し、自社の取り組みと照らし合わせるため、今回参加してきました。
セッションの紹介
ここからは、特に印象に残った3つのセッションをご紹介します。
Complexity & Creativity in Software Engineering
1つ目は、AI時代の複雑性と創造性をテーマにしたセッションです。
まず「Write-Only Code」という概念が紹介されました。 Write-Only CodeはAIが登場する以前から存在する概念で、書いた本人ですら後から読めないコードを指します。APLやJ言語のような極端に密度の高い言語で書かれたコードが典型例として挙げられました。 例えば「1から100のFizzBuzz」をAPLで書くと、たった一行でこのように表現できます。
(¯4↑¨'Fizz' 'Buzz' 'FizzBuzz' (⍕))⌷⍨¨1+(0=3|⍳100)+2×0=5|⍳100
Write-Only Codeへの対処法として、次の2つが原則として紹介されました。
- テストを書いて振る舞いを保証する：コード自体は読めないので、入出力で振る舞いを担保する
- コードを使い捨てる：そもそも読めないコードはデバッグや修正ができないので、機能追加や修正が必要になったら捨ててゼロから書き直す
そしてこの登壇者の主張で最も印象的だったのが、「AIが書くコードもWrite-Only Codeである」 という指摘です。 一行一行は人間が書いたものより読めるかもしれませんが、人間がレビューできる量を遥かに超える量が生成されるため、物理的にコードを読み切れなくなります。 PRの「コードを読むレビュー」はもはや破綻していくのではないか、と。
これはMLエンジニアがモデルの重みを1つずつレビューせず、性能指標で評価しているのと同じ構造です。 今後はAIが生成したコードを、コードそのものではなく性能・振る舞いで評価する スタイルにシフトしていく、というのが登壇者の示唆でした。
そこで、AI時代に大事なことが3つ挙げられました。
- 詳細なテストを書く
- レビューを自動化する（人間は仕様・要件をレビューする）
- オブザーバビリティ基盤を監視させて、AI自身に問題を直させる
こうなってくると、もはや人間はコーディングの難しい部分には立ち入らなくてよくなります。 そして、それによって起こるのが 「意図」と「実装」の分離（Decoupling from Implementation） だと登壇者は語ります。
意図と実装の分離自体はアーキテクチャの世界において新しい概念ではなく、これまでも抽象化やインターフェース、APIによって人間は複雑性を下位レイヤに閉じ込めてきました。 AIによってこの抽象化がさらに高いレベルで起こる、というのが今起きている変化だと整理されていました。
では、ソフトウェアの複雑性を意識しなくてよくなる中で、人間に残された仕事は何か。 登壇者の答えは「創造性 (Creativity)」というものでした。
そして、こういった技術革新の後には創造性の爆発が起きてきた、ということを歴史が証明している、として2つの例が挙げられていました。
- 写真の発明と絵画：写真が現実をそのまま記録できるようになったことで、絵画はもはや現実を写し取る役割を担う必要がなくなりました。その結果、印象派や抽象画など、現実の再現とは異なる新しい表現が次々と生まれていきました。
- DAWと音楽：DAW（Digital Audio Workstation）の登場により、フルオーケストラやスタジオを揃えなくても、機材1つで個人がプロ品質の音楽を作れるようになりました。1人のミュージシャンが膨大な数の楽曲を生み出せる時代になり、音楽表現は大きく広がりました。
これらと同様に、AIによってもソフトウェアエンジニアリングにおける創造性が爆発していくのだろう、というのが登壇者の結論でした。 そして、創造性は「反復」によって育まれるものでもあり（ライト兄弟が空を飛ぶのに10年かかった話などが引かれていました）、AI時代もまずは小さく荒く作って反復することが大事だと締めくくられていました。
所感
「AIが書くコードもWrite-Only Codeである」という前提に立って、開発プロセスそのものを設計し直していく必要があると改めて感じました。 AIに任せられる部分が広がるほど、エンジニアはコーディング以外の領域で価値を出していかなければなりません。 事業への貢献を起点に考えれば、これまでコーディングに使っていたリソースを、顧客理解・ドメイン理解・チーム運用の改善など、組織の問題を見極めて打ち手を投じる方向にシフトしていくことの重要性が、一段と高まっていきます。 その先で「創造性」をどう発揮するか、組織としてどんな仕掛けを用意していくかは、これからのエンジニアリングマネジメントを考えるうえでも避けて通れない問いだと感じました。 それにしても、こうした変化を当事者として経験できるのは、本当に面白い時代だなと思います。
Mitigating Geopolitical Risks with Local-First Software
2つ目は、地政学的リスクとアーキテクチャの関係をテーマにしたセッションです。
欧州ではクラウド利用は伸びているものの、AWS・Azure・Google Cloudの3社で欧州市場の70%を占めており、欧州プロバイダーのシェアは下がり続けています。 米国クラウドへの依存が高まる中、政策次第では締め出されるリスクがあり、それはもはや仮定の話ではない、として以下の事例が紹介されました。
- ICC事件：トランプ政権の制裁により、国際刑事裁判所（ICC）の検察官のMicrosoftアカウントが停止された
- データセンターへの物理攻撃：イラン情勢の中、UAEのAWSデータセンター3カ所が攻撃を受けた
- データ開示の現実：MicrosoftはEU内のデータセンターであっても米国の法的要請に従ってデータ開示することを認めている
クラウドはもはや電気・ガス・水道と同等のインフラとなり、止まれば社会が機能しない、軍事目標にもなり得る存在になっている、ということです。 パニックを起こす必要はないが、緩和策は必要、ということで以下の3つが紹介されました。
1. マルチクラウド
単一サーバ → 単一企業 → 単一国、と段階的に避けていく。 そのためには、特定クラウドに固有のマネージドサービスではなく、Kubernetes・S3互換ストレージ・Kafka・PostgreSQLのように、複数の環境で同じものを動かせる（ベンダー依存度の低い）技術を選ぶことが鍵になります。これらはデファクトスタンダードでもあるため、移行先の選択肢や知見も豊富です。 一方で、コスト増・最大公約数的な機能制約・運用の複雑化というトレードオフは避けられません。
2. AT Protocol
Blueskyの基盤技術として知られるAT Protocolが紹介されていました。 SNSのID・フォロワー・投稿を分散管理することで、利用しているサービスを乗り換えても、これらのデータをそのまま保持できる仕組みです。
3. Local-First Software
Obsidianが代表例で、データの「正本」をユーザー端末側に置き、クラウドは同期・バックアップ用に留める考え方です。 クラウド依存を構造的に減らし、複数端末間でのリアルタイム同期も実現できます。 ただし、銀行残高や在庫、電力取引データのように 権威的な正本がサーバ側に必要なドメイン には向きません。
これら3つに共通するメッセージは、「技術選定はプロバイダーとユーザーの力関係をどう動かすかという視点でも考えるべき」 ということです。
所感
弊社が扱うエネルギー取引データは中央集権的に管理する必要があるドメインのため、Local-Firstの考え方をそのまま適用できません。 ただ、特定クラウドの特定マネージドサービスへの依存度合いや、地政学的リスクへの備えをどう設計するかは、今後のアーキテクチャ判断の中で改めて意識していきたいと感じたセッションでした。 日本にいると地政学的リスクは遠い話に感じがちですが、欧州ではすでに「実際に起きていること」として議論されており、平和ボケしていた自分の感覚にハッと気付かされた瞬間でもありました。 国家インフラに近い性質を持つプロダクトを作っていく以上、将来的に地政学的リスクへの備えは避けて通れない課題になります。 enechainでは、ベンダ依存度の高いサービスを選択しないようにしており、Auth0から内製認証基盤への移行も海外依存回避策の1つとなります。（詳細はこちらのTech Blogに譲ります。ぜひご一読を！） [URL:embed:https://techblog.enechain.com/entry/identity-platform-migration]
Context is the New Code
3つ目は、AIエージェント時代における「コンテキスト」の重要性を論じたセッションです。
タイトルには2つの意味が込められています。
- コードの原材料として：AIがコードを生成する時代、入力となる「コンテキスト」がコードを規定する
- コードの代わりに：コード自体は使い捨てになり、保持してブラッシュアップしていく対象は「コンテキスト」へと移っていく（つまり、コンテキストそのものが管理・バージョン管理される対象、すなわち「コード」になっていく）
つまり、コンテキスト自体がプロダクトの一部になる という考え方です。 登壇者は、ソフトウェア開発ライフサイクルと同じく、コンテキストにも「生成 → 評価 → 配布 → 観測」のライフサイクルを適用しようと主張していました。
生成 にあたるものとして、4つが挙げられました。
CLAUDE.mdやAGENTS.mdのようなルール・ガイドライン- Context7のようなライブラリ文脈を補うMCPサーバ
- Notion / Slack MCP経由で取得する組織の暗黙知
- Kiro / Spec Kitのような構造化スペック
評価 には4種類のテストが紹介されました。
- Lint：構文・必須フィールド・長さの自動チェック
- LLMによるチェック：曖昧な表現・冗長な記述・矛盾を検出
- 機能テスト：スキルを実行して目的のタスクが達成されるかを検証
- E2Eテスト：実リポジトリの特定コミットからスタートし、コンテキストを与えてコード生成、事前に定義した振る舞いをパスするかを検証
特に4つ目のE2Eテストは「コンテキストのためにわざわざ実リポジトリでテストする」という発想が新鮮でした。 LLMの出力は非決定的なので、テストは複数回（例えば5回）実行し、それでも揺らぐ部分については 「絶対に通すテスト」と「失敗を許容するテスト」を分ける と。 SREのエラーバジェットと同じように「100%完璧を求めず、許容ラインを引く」という思想です。
配布 については、Gitサブモジュールやnpm的なパッケージ管理での配布が推奨されていました。 利用する側がチームルールやフロントエンドのベスプラなどを必要に応じて手元に取り込めるイメージで、共有・バージョン管理・更新通知の問題をまとめて解決できます。
観測 は、本番のエラーログをコンテキストにフィードバックして、同じミスを繰り返さない仕組みを作ること。 日々のコミット・レビュー・Slackでの議論もフィードバック源として活用できます。 改善結果はレジストリに登録すれば、組織全体のコンテキストの底上げに繋がります。
最後は以下のメッセージで締め括られました。
AIエンジン自体は誰もが使えるので、もはや差別化要因にはならない。差別化要因になるのは「燃料」、つまりコンテキストだ。
所感
弊社のようにエネルギー業界というドメインに深く根ざした事業を扱う会社こそ、再利用可能でテストされた共有コンテキストへの投資 が今後のレバレッジになる、と強く感じたセッションでした。 ここで言うコンテキストはSkillやAgentに限らず、仕様書やコーディング規約といった開発に必要なドキュメント類全般を含むものとして捉えています。 日々の開発で書いているプロンプトやルールファイルを属人化された資産のままにせず、組織で育てるアセットとしてどう運用していくか。 コーディングだけに閉じず、要件定義からテスト実施まで開発プロセス全体を視野に入れて、具体的に動いていきたいテーマです。
おまけ：Friendly FOMOという文化づくり
3つの主要セッション以外に、Team Topologiesの著者の登壇で紹介されていた話も印象に残りました。
「企業の80%はAIを導入しても恩恵を感じていない」というデータが示され、その原因は 「AIを使うこと自体が目的化している」 ことにあると指摘されていました。 何を達成したいかを起点にAI活用を進めるのがセオリーだ、と。
そして、AIを組織に根付かせるためのキーワードとして「Friendly FOMO」が紹介されました。 FOMO（Fear of Missing Out, 乗り遅れる恐怖）のフレンドリー版で、「周りに比べて自分はちょっと遅れているかも」というポジティブな焦りを組織に醸成することがAI推進の鍵だ、というメッセージです。
別のセッションでは具体例として、DuolingoのSlackに「Build X with AI」というチャンネルがあり、どんな小さなことでもAIで実現できたことをカジュアルに共有する文化があるという話が紹介されていました。
所感
弊社にもAIに関するSlackチャンネルがあるので、もっと気軽に「AIでこれができたよ」を投稿していく動きを広げていきたいなと感じました。 小さな成功体験をカジュアルに共有することが、組織全体の心理的なハードルを下げる一番の近道だと思います。
さいごに
QCon Londonに参加してまず印象的だったのは、セッションの大半がAIに関するもので占められていたことです。 世界のAIに対する注目度の高さを、肌で感じることができました。 そしてそれは単なる流行ではなく、AIを前提とした開発・組織・アーキテクチャへの移行はすでに進んでおり、その上で踏み込んだ議論が交わされていました。 ここで得た学びを、EMとしてのプロダクトづくり・開発プロセスづくりに活かしていきたいと感じています。
また、QConは交流を非常に大事にしているカンファレンスでした。 長めの休憩時間、毎日1時間の懇親会、ロール別の1:1マッチングなど、運営側の工夫が随所にあり、現地で20人ほどの参加者と会話できました。 英語への苦手意識は正直まだありますが、勇気を出して話しかければ意外となんとかなる、という感覚を得られたのは予想外の収穫でしたし、英語学習へのモチベーションもかなり上がりました。
やはり現地に足を運んで熱量を直に感じられたのは、今後のエンジニア人生にとって何にも代えがたい経験だったと感じています。 送り出してくれた会社には感謝しかありません！
海外カンファレンスに行ってみたい、最新の技術動向を肌で感じたいというエンジニアの方には、ぜひ一度QConをおすすめしたいです。
今年は6月にボストン、11月にサンフランシスコで開催されるみたいなのでぜひ！
最後に懇親会で飲みまくったPeroniの画像で締めくくりたいと思います！(めっちゃ美味かった！最高！)
enechainでは、日本のエネルギー業界をテクノロジーの力で変革する仲間を募集しています。 まずは気軽にカジュアル面談で話を聞いていただくだけで構いません。 ご興味ある方はぜひTech Recruit Portalからご応募ください！
