Developers Summit 2026 FUKUOKA 参加レポート

2026年9月11日、福岡・天神のONE FUKUOKA CONFERENCE HALLで開催された「Developers Summit 2026 FUKUOKA」に参加しました！

イベントの概要

開催日：2026年9月11日（金）

会場：ONE FUKUOKA CONFERENCE HALL

主催：株式会社翔泳社 CodeZine編集部

公式サイト：[Developers Summit 2026 FUKUOKA]

( https://event.shoeisha.jp/devsumi/20260911/ )

イベントの雰囲気

Developers Summit 2026 FUKUOKAでは、複数のセッションが用意されていました。気になるセッションを事前に予約しておき、時間に合わせて会場内の部屋を移動しながら話を聞く形式です。

セッションの合間には、各社のブースを自由に見て回ることもできました。講演を聞くだけでなく、展示や企業の方との交流も楽しめるイベントでした。
会場にはコーヒーやお菓子も用意されていて、気楽に参加できるような雰囲気でした！

参加したきっかけ

今回、特に気になっていたのはAI関連の話です。
ほかのエンジニアや企業は、普段の仕事でAIをどう使っているのか。AIを使うことで、仕事の進め方はどう変わっているのか。そして、どのように現場へ取り入れてきたのか。
そうした実際の取り組みを聞いてみたいと思い、参加しました！

AIを導入して変わったこと、変わっていないこと

すでに仕事では、AIを活用することが当たり前になりつつあります。では、AIを導入することで何が変わり、AIを導入しても変わっていないことは何なのでしょうか。話を聞く中で、共通して語られていたのがチーム構成でした。

AIを導入することで、小さなチーム構成で仕事ができるようになったという話です。
私もAIを活用することで、少ない人数でも対応できるようになったと感じています。

一方で、少ない人数で対応できるようになったからこそ、開発プロセスやセキュリティを確認する目も少なくなります。その分、開発プロセスを見直したり、仕組みを育てたりすることが大切だと思いました。
ただ、AIを導入しても変わらないこともあります。それは、チーム内で認識や理解を合わせることです。AIによって作業の進め方やチームの規模が変わっても、何を作るのか、どう進めるのかを共有することは欠かせません。

また、開発や新しいことへの挑戦を楽しむ姿勢も、AIが普及したからといって変わるものではないと感じました。

問題が発生したときの見方が変わった

皆さんは、自分たちのシステムに障害が発生したとき、どのように対応していますか？

私自身、問題が発生したときは、まずログを確認し、原因に関するログが出ていれば該当箇所を特定するようにしています。ログに手がかりがなければ、関連するメトリクスなど、別の情報を確認していくという流れです。
ただ、この方法では、問題が発生してから原因を探し始めることになります。その時点ですでに、システムが止まっている可能性もあります。

では、システムを止めないためには、どのような取り組みが必要なのでしょうか。今回は、New Relicを導入している方の話を伺いました。
「いつから問題が起きたのか」「その時点で何が変わったのか」に着目することで、調査の初動を早くするという話が印象に残りました。
実際に解析されている画面の一部も見せていただきました。従来の監視ツールが「何が起こっているのか」を示すのに対し、New Relicには「なぜそれが起きたのか」まで分析してくれる機能があるように感じました。

AIの活用によって技術の進化が加速する一方で、アーキテクチャは複雑化し、障害の原因特定は難しくなっていくと思います。そうなると、復旧作業にも時間がかかってしまいます。だからこそ、原因調査を支援する仕組みを整え、少しでも早く復旧できるようにすることが重要だと感じました。

AIが実装したTDDは信頼できるのか

次のセッションでは、AIがTDDで実装したコードを本当に信頼できるのか、という話がありました。
1周目は、テストを先に書き、そのテストを通すために実装するので、一見すると問題なさそうに見えます。しかし2周目では、すでに実装がある状態でテストが通らないと、実装を正しく見直すのではなく、テストの方を実装に合わせて変更してしまうことがあります。その結果、要件を満たしているかよりも、テストを通すことを優先した実装になってしまいます。

※このテーマに関連して、OpenAIやAnthropicからも論文が発表されているようなので、ぜひ確認してみてください！

では、AIがテストを通すことだけを目的にしてしまわないためには、どうすればよいのでしょうか。
セッションでは、実装を始める前に、何を満たせば完成なのかという受け入れ条件を決めておくことが紹介されていました。AIに実装を任せる場合でも、テストや仕様をAI自身に都合よく変更させるのではなく、人が決めた条件を基準に確認する必要があります。
また、PRDやDesign Docなどを用意し、機能の目的や背景、設計方針をAIに伝えることも重要だという話でした。AIとの数回のやり取りだけでは伝えきれない情報を、あらかじめ文書にしておくという考え方です。

このセッションを聞いて、改めて自分がAIとどのようなやり取りをしているのか、そしてAIが本来の目的から外れないように、どこまで自分で仕組みを作れているのかを振り返る良い機会になりました。

最後に

AIが当たり前になっていく中で、これからはAIに実装を任せる力だけでなく、目的や受け入れ条件を整理し、自分が実現したいことをAIに正しく伝える力がますます必要になると感じました。
別のセッションでは、面接の中でAIと一緒に実装する様子を確認する試験を導入している、という話も聞きました。
これからのエンジニアには、AIを使えることを前提に、何をさせるのか、どう伝えるのか、AIに実装を任せるためにどこを整えるのかを考える力が、すでに求められているように感じました。
AIによって仕事がなくなるというよりも、AIによって新しく生まれた仕事にどう向き合い、どのように進めていくのかが重要になっていくのだと思います。