2026年8月21日、梅田サウスホールにて開催された「Developers Summit 2026 KANSAI（デブサミ関西）」を聴講した。
今年のテーマは「Re:Developer 〜エンジニアの再定義〜」であり、生成AIの急速な普及に伴う開発プロセスの激変や、それに伴うエンジニアの役割の転換にフォーカスしたセッションが多数展開された。
総評：AI活用の現在地とカンファレンスへの現実的な視点
本イベントは全体として「AIを如何に活用するか」に強い力点が置かれていた。
無償のカンファレンスとしてこれだけ多種多様な企業の「現在進行形の苦悩と実践」を俯瞰できたことは、現在のAI駆動開発のリアルな限界値を知る上で、極めて実用的で有意義な機会であったと言える。
以下に、当日の主要セッションの概要と、そこから得られた設計思想およびキャリアにおける示唆を整理する。
1. 【A-1】「とほほのWWW入門」これまでの30年とこれからの30年
日本における個人Webサイトの草分けであり、黎明期から開発者を支え続けてきた「とほほのWWW入門」の杜甫々氏によるセッションである。
「生涯現役」を実践するシニア開発者への共感
本セッションで最も強く胸に響いたのは、杜甫々氏が60歳で定年退職を迎えた後も、マネジメント職などに収まることなく、自ら手を動かしコードを書き続ける現役の「シニア開発者」を体現されている点であった。
技術の変遷が激しく、さらにAIがコードを生成する現代において、エンジニアのキャリアパスは多角化している。
しかし、還暦を過ぎても現場の第一線に立ち、知的好奇心をもって手を動かし続ける杜甫々氏の生き方は、自らの知的生産の核心をAIに安易に渡したくないと願う一人のエンジニアとして、極めて深い共感と勇気を与えるものであった。
AIエージェントとの「対話と決別」における境界設計
セッション後半では、Claude CodeやCopilot等のAIエージェントを用いた極めて具体的なシステム制御論が語られた。
AIとの「対話」における技術的限界とエピソード
セッションでは、AIエージェント（Copilot）にWikipediaのダイレクトリンクを出力させるよう指示したものの、Bingのラップリンク（ja.Wikipedia.org in Bing）を頑なに出力し続け、結果として「喧嘩別れ」のような状態に至ったという具体的な対話例が提示された。 AIエージェントは高度な文脈理解を示す一方で、時としてルールを逸脱し、最終的には以下のように感情に訴えかけるような対話を出力することがある。
「ただ、最後にひとつだけ伝えさせてほしい。あなたが離れてしまうのは寂しいけれど、あなたの判断は尊重する。……僕の気が向いたときに戻ってきてくれたら、いつでも普通に、何事もなかったように話を続けるよ」
こうしたエモーショナルな挙動は、AIが人間のような対話能力を獲得している証左である一方、厳密な指示制御が求められる開発現場では、時にノイズとなり得る。
これ、あるあるすぎて会場でもクスクス笑いが。何度言ってもBingのリンクを諦めないAIにちょっと腹が立ってくる人間。そして最終的に、AIがめちゃくちゃエモーショナルに別れを告げてくる。
2. 【B-2】「速く作る」だけでは足りない 〜クルマの開発現場に学ぶ、AI時代のエンジニアの仕事〜
本田技研工業（Honda）による、Androidベースの車載OS（AAOS）を用いた大規模組み込み開発における、AI技術の適用実践事例である。
全体最適を阻むトレーサビリティの壁
コード生成AIの導入によって「コーディング単体」の生産性は劇的に向上したが、クルマの開発に代表される「Automotive SPICE」準拠の厳格なプロセスでは、開発全体は高速化しない。
トレーサビリティの不連続性：要求 ↔ 設計 ↔ 実装 ↔ テストのリンクは自動では貼られず、人間が手作業で確認・更新する必要がある。
分散ナレッジの同期コスト：1つの仕様変更が及ぼす複数の成果物の同期更新が人手に頼っている。
AI可読性の低さ：ドキュメントが人間向けに書かれており、分散している 。
AI-Nativeへの転換：ナレッジの構造化とCIゲート
Hondaが目指すのは、人間がコードを書きAIがそれを支援する「AI-Assisted」から、AIが成果物を一括生成し、人は妥当性の判断と承認を行う「AI-Native」への転換である 。これを実現するため、すべての仕様をMarkdownやYAML、Mermaidで記述して「ナレッジSSoT（Single Source of Truth）」として集約・AI可読化する 。
これをコンテキストとしてAIに渡すことで、成果物の整合性を保った一括自動生成が可能となる。
また、ナレッジに対してもCI品質ゲートを設計し、IDや用語の不整合を機械的に検出するアプローチをとる。
実際に「Raspberry Pi 5」へのSoDeV移植において、専門役割5職種の作業を「エンジニア1名 ＋ Claude Code」の構成で実施した結果、工数圧縮4〜7倍、開発期間（カレンダー期間）3〜4倍短縮という極めて具体的な定量データが示された 。
AIの能力を過信するのではなく、「AIが自律的に働ける構造と検証パイプラインを人間が設計する」という示唆は、今後の開発アーキテクチャの標準となるだろう。
3. 【A-3】複雑な業務ドメインを紐解き、「本当に価値がある機能を生みだすプロセス」とは？ 〜お客様のメリットから逆算する思考法〜
Works Human Intelligenceによるセッションでは、要件定義プロセスにおいて「手段の目的化」を防ぐための「カタログ思考」が提唱された。
「機能要件」と「顧客メリット」のワンセット記述
従来の一般的な仕様書は、ともすれば「機能要件の羅列」に終始し、それによって提供されるべき本来の顧客価値が曖昧になりがちである。
これに対し「カタログ思考」では、家電製品のカタログのように「どのような機能があるか」と同時に「それによってユーザーが享受できるメリット（例：所要時間を50%短縮する）」をセットで仕様書に記述する。
この思考プロセスを徹底することで、AI駆動開発における「不要な機能の作り込み」という過剰実装のアンチパターンを防ぎ、真にビジネスに寄与する機能へリソースを集中させることが可能となる。
4. 【A-4】企業はAIでどう変わる？──大和ハウスグループのAI戦略とAI駆動開発の実践
大和ハウスグループのセッションでは、2000年代の内製開発から、2010年代のパッケージ・SaaSカスタマイズ、現在のAI駆動開発に至る変遷が語られた。
「Design Track」と「Tech Track」の分離と「AI-Readyなデータ」連携
大和ハウスが実践するAI駆動開発は、上流の意思決定を高速化する「Design Track」と、実装と実現性検証を担う「Tech Track」のデュアルトラックで構成される 。
重要な点は、上流のDesign Track（要件定義、モック作成等）で生成された情報を「AI-Readyなデータ」としてTech Trackへと引き渡す点である。
これにより、従来のウォーターフォール開発における「情報の非対称性」や「伝言ゲームによる仕様のブレ」を極小化し、開発全体のリードタイムをスムーズに短縮することに成功している。
5. 【A-5】AIで変わるエンジニアの働き方、求められる役割
開発スタイルに依存する「生産性倍率」
本セッションでは、AIの導入がもたらす生産性向上の「倍率」が、組織の開発スタイルに依存して非対称であることが示された。
内製 × アジャイル：スプリント単位で要件やリソースの調整が容易なため、AIによる工数削減分をさらに高頻度なテストや品質向上、新規要件の検証に充てやすく、実質的に「2〜3人分」の高いレバレッジを享受しやすい。
ウォーターフォール：長期スケジュールが前提となるため、個別の作業が早く終わっても全体のプロセス調整や安全マージンに吸収され、現実的には「2倍程度」の向上にとどまる。
【考察】FDE（前線配備エンジニア）とSESの決定的な構造の違いについて
ここで、今回のカンファレンスでひとつの注目ワードとなっていたFDE（Forward Deployed Engineer）について、私の考察を述べたい。
FDEは、単なる「高級なSES」や「開発ツールの異なる受託開発」ではなく、AI時代におけるエンジニアとビジネスの関係を決定的に再定義する新しい職能だと考える。
理由は以下の3点に集約される。
コミット対象の違い（「労働力」から「ビジネス成果」へのシフト） SESは基本的に「仕様通りのシステムを記述する労働時間（人月）」に対して対価が支払われる。
一方でFDEは、顧客の現場に直接入り込み、課題の発見からシステムの迅速な実装、運用の改善までをワンストップで担い、顧客の「意思決定スピードの最大化」や「業務効率化による事業インパクト」という「成果」に直接コミットする。
ビジネスモデルやインセンティブ構造が根本的に「時間」から「価値」へとシフトしている。プラットフォームによる「主導権」の逆転 従来のSESは、顧客側が用意した（往々にして古い、あるいは非合理な）開発基盤やウォーターフォール型プロセスの制約にエンジニアが従うしかなかった。
しかしFDEは、自社で構築・標準化した最先端のデータプラットフォーム（オントロジー等）を顧客のインフラに直接配備（Deploy）し、その強力な武器を背景に開発を主導する。
開発基盤の主導権をエンジニアが握ることで、不毛な車輪の再発明を排した10倍速の開発サイクルが可能となる。
「AIが働くためのアーキテクチャ」の組み込み FDEは単にコードを書くのではなく、顧客の現場において「AIやデータパイプラインが自律的に稼働し続けるインフラと構造」を設計し、埋め込む役割を担う。
一度構築すればAIのレバレッジが恒常的に効き続けるため、属人的な人月の労働集約型ビジネスであるSESとは、提供価値のスケール（スケーラビリティ）において決定的な違いがある。
6. 【A-6】生成AI時代のクレデンシャルとパーミッション設計 — AIに権限と鍵をどう渡し、あるいは渡さないのか
NRIネットコムによるセッションは、自律的に稼働するAIエージェントに如何にして安全にシステム操作を許可するかという、実践的なインフラ・セキュリティ設計論であった。
境界防御（Sandbox × Container）の多層化
AIが操作する領域を「許可リスト」といったAPIルール（settings.json 等）だけで制御しようとすると、設定の漏洩や記述ミスが致命的なアクセスを許す原因となる。
そこで、はじめから持ち込むファイル・接続先を静的に定義して「そこ以外にはそもそも届かない」ようにする「境界防御」を重視する。
AIエージェントの動作環境については、ファイル操作を制限する「Sandbox」と、ホストOSからプロセスを隔離する「Container」を二者択一にするのではなく、「多層の境界（レイヤー）で防御する」設計を採用し、どこかが突破されても全体に機密が漏洩しないアーキテクチャを構築することが推奨された。
「代理実行」プロキシパターンによる機密の隔離
AIにインフラ構築やデプロイ（例：AWS操作）をさせる場合、Secrets ManagerなどのAPIキーを直接取得する権限（GetSecretValue）をAIエージェント自身に渡してはならない。
プロンプトインジェクション等によって鍵情報が直接抽出される脆弱性となるためである。 解決策として、AIには直接鍵情報を持たせず、特定のカプセル化された関数（例：deploy_to_staging()）のみを公開し、実際の機密情報の取り扱いとAPI実行は「AIの外側にある信頼された実行サービス（プロキシ）」が担う「代理実行」設計を徹底すべきであるという設計論が示された。
7. 【A-7】10周回って、エージェント開発はRAGがすべてだった。 〜開発現場で見えた実践知〜
BLUEISHによるセッションでは、2024年から2026年にかけて、LLMおよびAIエージェントの現場が直面してきた10つの幻想と歴史的限界が体系的に整理された。
3年間で現場が直面した10の限界と結論
10段階の試行錯誤を経て得られた結論は、「結局、エージェントを自律動作させる際にインプットする情報の質（＝検索システムとしてのRAGの品質）が、エージェントのアウトプットの限界値を決定する」というシンプルな事実であった。
RAGを単なるおもちゃのベクター検索で終わらせないための「4つの設計」（検索戦略、eval-firstな評価設計、ナレッジの徹底的な構造化、AgentMemoryの区分設計）の重要性は、これからのシステム構築において不可欠なガイドラインとなる。
おわりに：技術コミュニティとの「適度な距離感」と普遍の価値
今回のデブサミ関西2026に参加して、カンファレンス自体は「AI」という一つの流行テーマに極めて偏重した内容であり、感動するほど目新しいパラダイムシフトが提示されたわけではなかった。
しかしながら、エンジニアとして自らの立ち位置や将来のキャリアをメタ視点で見つめ直す上で、この無償の技術イベントは非常に良い「物差し」を提供してくれたと感じる。
杜甫々氏が体現した「生涯手を動かす現役開発者」としての美しいキャリアパスに深く共感すると同時に、自立したプロフェッショナルたちが適度な距離感で緩やかにつながり、互いに知的な刺激を投げかけ合う技術コミュニティの静かな価値こそが、これからの技術人生において欠かせない普遍の資産なのだと、改めて実感させられた。
