個人から組織展開へ AI Engineering Summit Tokyo 2026 参加レポート

AI Engineering Summit Tokyo 2026

エンジニアの関口です。2026年6月8日・9日の2日間、ファインディが主催する AI Engineering Summit Tokyo 2026 に参加してきました。会場は浜松町コンベンションホール & Hybridスタジオです。

2日間を通して個人的に印象に残ったのは、FDE（Forward Deployed Engineer） の考え方を軸にした3つのテーマでした。ガバナンス、Human in the Loop（HITL）から Human on the Loop（HOTL）、組織への適用方法。PoCの先にある本番運用、人間がループの外側で設計する役割の変化、個人の生産性が上がっても組織全体には広がらない問題。ここではイベントで感じた視点を中心にまとめます。

どんなイベントだったか

エンジニア向けのAIエンジニアリングカンファレンスです。登壇者は金融、ERP、SaaS、開発ツールなど業界は幅広いものの、話の芯は驚くほど揃っていました。

2日間を通じて繰り返し登場したテーマは、おおむね次のとおりです。

  • FDE（Forward Deployed Engineer） — 現場に入り込み、PoCの先まで設計する
  • ガバナンス — エージェント管理、eval、サプライチェーン
  • Human in the Loop から Human on the Loop — 人間はループの中から、外側で目的・品質基準を設計する
  • 組織への適用 — 個人利用から全体へ足並みを揃える

イベントの骨格を担っていたのが FDE です。Day 1 Keynoteのタイトルは「Transforming the Enterprise with FDE」で、ここから2日間の議論が始まりました。FDEとは、次のような考え方です。

  • 顧客の現場に入り込み、本番運用とガバナンスまで設計する
  • 便利なツールを入れるだけでなく、業務そのものを設計し直す伴走をする
  • モデルの進化そのものより、企業がどこまで価値を生むかに焦点を当てる

これはKeynoteだけの話ではありませんでした。登壇内容はバラバラに見えても、文脈は同じ方向を向いていました。

  • 導入は行動変容の問題、というKeynoteのメッセージ
  • 個人利用から組織へ広げる展開方法

2日間を通して感じたのは、「AIをどのように全体最適で組み込んでいくか」を、各社がそれぞれの仕組みで試している、ということでした。

Keynote：PoCの先を語る2つの基調講演

Day 1 — FDEと本番運用まで設計する

Day 1 Keynote「Transforming the Enterprise with FDE」では、企業導入の現状が整理されました。

ChatGPTやCodexなど個人向けツールの利用は急速に広がっている一方で、企業はPoCの先へ進みたい段階にあります。モデルの進化と価値創出のあいだにギャップがある、という指摘が印象的でした。導入障壁の多くは「体制」にあり、便利なツールを入れるだけでは足りない、という話です。

FDEの役割は、モデル進化そのものではなく、企業がどこまで価値を生むかに焦点を当てること。本番運用とガバナンスまで設計し、業務そのものを設計し直す伴走が求められています。FDEの仕事は大きく3つ。業務コンテキストを組み込んでUI/UXまで作り込む導入・実装、実データと照合しながら改善する研究、インシデント対応やテストを回す運用です。

Day 2 — 導入は行動変容の問題

Day 2 Keynoteでは、印象的な一文がありました。「AI adoption is a behaviour-change problem」。AI導入は行動変容の問題だ、というメッセージです。

週末にデモを作れる時代になった一方、本番展開までのボトルネックは推論コストや既存システムとの統合に移っています。データ中心の設計とHuman in the Loop、ガバナンス整備によるAI活用の伸び、厳格なevalの構築。測定可能な状態にしてハルシネーションの推移を追う、という運用サイクルが語られました。

監査の現場では、長年同じやり方を壊すのではなく現場をサポートする姿勢で信頼を構築した、という事例も参考になります。技術を入れる前に、ユーザ体験と社内外の期待値を理解し、定期的なオンボーディングを回すことが大事、というメッセージは組織展開の場面でもそのまま使えそうです。

ガバナンス

2日間を通じて最も自分ごとになったテーマのひとつが、「AIに任せる」と「放任する」の違いです。ガバナンスで守りながら任せていく。PoCの先にあるのは、こうしたガードレールの設計でした。

エージェントの量産と管理

みずほのセッションでは、全社規模のAI推進のリアルが語られました。本格的にAI導入を進め、内製の開発体制を中心に動いています。ベンダーへの丸投げではなく内製化を目指す方針です。

掲げていた「エージェントファクトリー」は、短期間・低コストでエージェントを量産し、本番運用後も継続改善する仕組みです。Dev段階からサイバーセキュリティを考慮し、エンジニアが量産できる体制を整えています。

ガバナンス面では、次の3点が語られました。

  • エージェントのライフサイクル中のコスト管理
  • 類似エージェントの乱立による二重投資を防ぐインベントリ管理
  • アクセス管理のフレームワークを最初から設計に組み込むこと

各自がバラバラにエージェントを作ると非効率になる。業務ドメイン統括 / エキスパート / サブタスクモジュールの役割分担を標準テンプレートとして定義するOrchestratorモデルも紹介されていました。

プロンプト改善や汎用化だけでは表面をなめらかにするだけで、信頼には至らない。ドメインの専門知識を設計に組み込むことが不可欠、という指摘は、会計・人事ドメインを扱う我々にとっても核心です。

開発加速とサプライチェーン

別セッションでは、AIで開発が速くなるほど見えない依存が増える、という話からサプライチェーンのガバナンスへつながりました。多くの開発者がAIツールを日常的に利用するなか、量と速度が上がると中身を読まずにマージするリスクも増える。CVSS Base Scoreだけでは評価できない時代に、リスクベース判定やエクスプロイトチェーンまで考える必要がある、という話は、社内でも意識しておきたい観点です。

evalと測定

Day 2 Keynoteでも語られていた通り、厳格なevalを作り、測定可能な状態にする。ハルシネーションの推移を追い、品質を数値で管理する。デモが作れる時代と本番で価値を出す時代のギャップは、ツール選びでは埋まりません。ガバナンスとevalの設計が、そのギャップを埋める仕事です。

Human in the Loop から Human on the Loop

もうひとつの大きなテーマが、人間の役割の変化です。Human in the Loop（HITL） から Human on the Loop（HOTL） へ。人間はループの中で逐一確認するのではなく、外側で目的・制約・品質基準を設計する。

部分自動化から全体を任せるへ

LayerXのセッションでは、この流れが最も明確に語られていました。AIエージェントは「気づいたら仕事が終わっている」体験を目指しています。開発当初はタスクを細かく分割する設計でしたが、運用が進むほど管理コストが増え、柔軟性を失う。転換後は分割せずまるごとAIに渡したら解けた、という経験が語られました。

完璧な精度を最初から求めず、まずAIに任せて人間が確認側に回る。暗黙知を整備し、人間はループの外側で設計する。Human in the Loop から Human on the Loop へ、という言葉で整理されていました。今の業務フローをそのまま自動化しても効果が出ない、という指摘も耳が痛い部分でした。

どこまで任せるか

後述するパネルディスカッションでも、「どこまでAIに任せるか」が大きなテーマでした。AIへの委譲は3つの領域に整理されていました。

領域 内容
任せていいがまだ任せていない 時間的な制約で未着手の領域
任せていい 安全に委譲できる領域
任せ方がわからない どう委譲すればよいか未整理の領域

AIの能力が人を超えてきても、最後のチェックは人が行いたいという心理は残る、という登壇者の言葉は、HITLとHOTLのあいだをうまく表していました。

COBOLのマイグレーションのように、間違いを許されない領域もある。バグ再現をどこまでAIに任せるかは、技術的な問題というより 人間的な判断 が残る、という指摘も参考になりました。

HOTLの先に。Human Out of the Loopも

イベントではHuman in the Loop から Human on the Loop への話が中心でした。一方で、LayerXの「気づいたら仕事が終わっている」という体験を聞いていると、Human Out of the Loop（HOOL） の世界も考えられる、と個人的には感じました。みずほのエンドツーエンドの自己駆動型プロセスも、同じ方向を示しているように見えました。

物事によっては完全自律が必要になる。自動運転のように、人が逐一確認しない世界も広がっていく。近い将来、そういう領域が増えていくのではないか、という感触です。

HOTLは過渡期の設計思想だと捉えられる。最終形がHOOLだけではない、という見方もあり得る、という話です。

組織への適用。足並みを揃える

3つ目の大きなテーマが、個人から組織への展開です。個人の生産性が上がっても、組織全体には広がらない。ここが2日間で最も参考になった部分でした。我々でも取り組んできた「小さく足並みを揃える」ことと重なり、さらに学べる点が多かったです。

ボトムアップの限界とトップダウンの仕組み

公募セッション「個人利用から組織展開へ、AIエージェント導入事例」では、SaaS企業の登壇が印象的でした。

一定規模のエンジニア組織でツール導入自体はすぐできた。共有会を開いて個人の生産性は上がった。しかし聞いて終わりで、個人最適にはなったが組織全体には広がらなかった。ここまでは、ボトムアップの取り組みだけで進んだフェーズです。

立て直しの打ち手は、トップダウン側に寄っていました。

  • 評価基準の言語化ハンドブックを作成し、評価制度にテコ入れ
  • 制度としてAI活用の時間を確保。必ず取るよう矯正
  • AIギルドを設立し、各チームに横断メンバーをアサイン
  • 何を全社課題（宿題）にするかを明確化し、貢献の文化を引き上げる

チームから組織への全体最適はトップダウンが必要。仕組みを動かし続けることが大事、という学びは、我々でも進めてきた方向性と一致していました。

ログを見せ、時間を確保し、目標を明確に

大規模IT企業のセッションでは、組織への浸透設計として参考になる内容が語られました。

課題認識

トップはAI駆動を推進したい。しかしミドル層は使い方がわからない。各チームが同じことをやる車輪の再発明が起きている。ツール導入だけでは行動変容にならない。

施策と設計原則

  • 定期的なワークショップ（単発では効果なし）。ハンズオン体験を重視
  • チームギルド + 実践者コミュニティで接続
  • 導入率をKPIにしない
  • ロングテール到達を見る
  • 正解を固定せず、各自のユースケース引き出しを増やす

未活用層が着実に縮小し、Gitアクティブ層では高い利用率に達した、という成果も報告されています。

どう使うか。どう使っているか。ログを見えるところに

印象的だったのは、使い方を「見せる」設計です。

  • チャット履歴を共有する。AIエージェントツールは履歴が見やすく、触りの部分を知ってもらえる
  • 利用料も見せる。作業あたりの完了コストが重要指標
  • Archiveで型を見せる。導線を日々張り巡らせる
  • コスト・成果・生産性をコミュニティで全社共有

「こう使え」と指示するのではなく、汎用ツールを試してもらい、自チームの文脈に落とし込む。使い方ではなく、ユースケースの引き出しが課題だ、という認識も参考になりました。

キャッチアップの時間をトップダウンで確保

ギルドや勉強会では、キャッチアップの時間を組織として確保する工夫が語られていました。AI活用の時間を制度化する取り組み、ワークショップを継続する取り組み。単発では効果が出ないことを学び、頻度を上げて時間を確保する。全員が同じ情報に触れる機会を作る。こうしたトップダウンの仕組みが、個人の差を埋めるうえで効いている、という話でした。

目標を小さく、明確に

「AIを使う」という小さな目標を明確に書く。利用が当たり前になる空気づくり。上位層と下位層の差を当然として受け入れ、目標設定で埋めていく。我々でも「まず使ってみる」「ログを残す」「共有する」といった小さな足並みを揃える取り組みを進めてきました。規模は違えど、方向性が近いと感じ、さらに参考になる部分が多かったです。

現場エンジニア視点のハンズオン設計

現場エンジニアの登壇では、次のような工夫が紹介されました。

ハードル 対応
自信がない・時間がない 一回AIを回してあげる枠組み
新情報への負担 持ち帰りやすい具体題材（抽象より具体）
セキュリティ・社内ルール不明 既存フローを変えない導入
会話ログを見せる心理的ハードル チャット履歴の共有

既存のIssue管理や要件ドキュメントを使い、ワークフローを変えずに、案件理解からPRまで一気通貫で体験するハンズオン。AIだけで作成したPRが増え、AIで書くスタイルが定着しつつある、という報告もありました。

広木さん×山崎さんのパネルディスカッション。品質とスピードの向こう側

Day 1の「AIエージェント時代の開発組織の最先端：品質とスピードの向こう側」は、2日間の中でも特に面白かったセッションのひとつです。広木大地さんと山崎聡さんのパネルディスカッションで、ハーネスエンジニアリング、コードレビューの解体、組織へのAI展開、ROI（投資対効果）まで幅広く語られました。

組織へのAI展開

エンジニアはAIツール使い放題の環境を整えつつ、ボトムアップとトップダウンの両方を回している、という話から始まりました。AIエージェント活用を経営目標に組み込む（利益向上への寄与など）。

広木さんは、ボトムアップで知恵を絞る人が多いが、会社全体を変えるにはトップダウンで「場をまとめる」必要もある、と語っていました。業務命令ではないが、具体的なユースケースでやらせてみる。マネージメントが学ぶ時間を取ること。業務の中でマストにし、評価にも入れる。2026年では経営としても重要、という話です。

山崎さんは、スマホファーストのときと同様、タイミングが大事だと。シェアする場も重要（ボランティア精神）。経営陣への伝達も継続する、という話も参考になりました。

スイスチーズモデルとハーネスエンジニアリング

品質担保にはスイスチーズモデル（複数のAIを別の観点から重ねて検証するやり方）が紹介されました。CodexとClaude Codeを並列に回す。使わない層をどう埋めるかが品質の鍵、という話です。

ハーネスエンジニアリングについて、山崎さんは一定期間の試行錯誤の後、プラットフォーム化する（Ruby → Ruby on Rails のように規約でカバーする）、と語っていました。広木さんは、エージェントを自由にさせつつ品質を高める。以前はリテラシーが高くないと厳しかったTDDも、AIがハードルの高い部分をカバーする、という話です。

CLAUDE.mdやAGENTS.mdのようなハーネス整備が、生産性のピークを作る。多くのハーネスをプロジェクトへ移行するタイミングで、生産性が最大に高まる、という話は日々の仕事にも重なります。

コードレビューの儀式をやめる

パネルで最も刺さったのが、「コードレビューの儀式をやめる」 という広木さんの言葉でした。

コードレビューは人間の仕事だ、という幻想はもう限界に近い。人間より精度の高いレビュー結果が出る時代に、レビューそのものを儀式として続ける意味は薄れつつある、という議論です。

山崎さんも、コードレビューはAIに任せていく方向だと語っていました。観点を先に教えておくほうが精度は上がる、というのはハーネスエンジニアリングの文脈です。

人間がやっていたより速くならなければならない。同じ基盤モデルでも、ハーネスが違えば役割が変わる。ここはガバナンスの話とも、HOTLの話とも接続します。

AI活用の目的とROI（投資対効果）

「なんのためのAIか」が重要、という話も印象的でした。

広木さんは、AI活用後の状態をイメージすること。業務委託を減らすのは人間的に難しい。コストカットから先にアクションしがちだが、外から売上を持っていく価値貢献につなげるべきだ、と。大抵の1エンジニアは自社の売上がわからない、という指摘も耳が痛い部分です。

デリバリー速度とインパクトは別物として計測すべき。エンジニア的には開発期間の大幅短縮がインパクト。ビジネスは「楽になっていくか」と両輪。ROI（投資対効果）の観点では、人数を増やすより、少数で売上を伸ばすほうが楽、という話も。「提案してくれよ」と待っている経営者もいる、という指摘は、エンジニア側の姿勢にも問いが返ってきます。

少数精鋭と1人あたりのパワー

一定規模のエンジニア組織で、少数でプロダクトを回せる（今）。少数精鋭でリスクが低い。マルチスタック化（プロダクトマネジメントも）が進み、勉強ペースが上がっている。

広木さんはかなり多くのプロダクトを並行できる（実際にやっている）、と。間のメンテナンスもAIがいける。Excelをやめてアプリ化など、1人で作れる。ハーネスやサンドボックス環境を整備し、エンジニア以外にも使えるようにする。インテリジェンスが中心になっていく、という話は、職種の境界がぼやける流れとも重なりました。

みずほ×Cognition AIのパネルディスカッション

Day 2午後のパネル「みずほFG × Cognition AIが語るAIエージェント開発の現在地」も、2日間の中でも特に面白かったセッションです。みずほの本番Devin導入と、Cognition AI（Devin）側の視点をクロステーマ形式のパネルディスカッションで語られました。FDEの考え方が、規制の厳しい現場でどう実装されているかが、ここで最も具体的に見えました。

本番導入の背景

本格的にAI導入を進めてきた。当初はチャットベースのピンポイント活用でした。現在はエンドツーエンドの自己駆動型プロセスへ設計を転換しています。金融特化型LLMも稼働しており、AIエージェントはコード修正・レビューを自律的に回せる。登壇者は毎日使用しており、人間の生産性向上を実感している、という話でした。

Slackベースで複数のAIコーディングツールを並行運用。運用プロセスの自動化はもともとあったが、コーディング支援がなかった。AIエージェントが話題になったタイミングで注視し、本番導入に至った、という経緯です。

どこまで任せるか。ハーネスと Human on the Loop

「どこまでAIに任せるか」は、委譲の3領域として整理されていました。

領域 内容
任せていいがまだ任せていない 時間的な制約で未着手の領域
任せていい 安全に委譲できる領域
任せ方がわからない どう委譲すればよいか未整理の領域

ここで語られていたのは Human on the Loop（HOTL） の設計 — ループの 外側 で、何を任せ、どこで人が介入するかを決めることです。

いまの本番運用では、まだ Human in the Loop 的な確認ポイントが残っている段階でもある。Reviewも可能で、同じ基盤モデルでも ハーネスが違えば役割が変わる。人が各ステップで承認するのではなく、ハーネス · eval · 介入条件を外側で整える — これがHOTLの核心です。

AIの能力が人を超えてきても、最後のチェックは人が行いたいという心理は残る。HITLからHOTLへ移るときの境界の話でもある。例外処理はAIに任せ、得た知見をハーネスに還元し続ける。以前は時間のかかっていたリサーチが、調査からレポーティングまで一気通貫で回せるようになってきた — 人が逐一介在しない流れそのものが、HOTLに近づいている具体例でした。

Build or Buy

Build or Buyの判断は「コスパがあれば買い、なければ作る」。PoCやMVPは社内で即座に着手し、本番リリースでは非機能要件の観点で専門家と協業する。ビルド部分は内製化すべきで、controllability（制御可能性）も重要な判断軸です。

「プロトタイプの外注はほぼ消滅」「スライドも自分で作れ」。ノートPCを営業に渡し、すぐにデモを提示できる体制を整えている、という話は、FDE的な「現場に入り込む」姿勢そのものでした。AIエージェント開発側は、内製化を加速するツールであり、FDEの潮流と一致している、とも語っていました。

エンジニア組織はどう変わったか

導入後の組織変化も具体的に語られました。

  • 各種ツールでアウトプットが増え、思考に使える時間が確保できるようになった
  • コーディングが減った分、業務要件への関与が増加。ビジネスとテクノロジーの境界がぼやけている
  • プログラマーという区分けは消滅し、ビジネス要件と成果物が直結している
  • Usageは大幅に増加した一方、エンジニア数の増加は限定的だった

Webサイト制作部隊がなくなりフィールドマーケへシフトしている、という話も。市場は大きいのに、エンジニアは増えない。AIで生産性を稼ぐ構造になっている、という見立てでした。

キャリアパスもマネジメント、マーケ、AI監査などに拡大している。「コードは読めない」は職種の名残として残る程度、という言葉も印象に残りました。

金融サービスはどこまで進化するか

顧客のビヘイビアもAI化していく（スマートフォン普及時と同様の必然）。AIを使う顧客に対して、金融サービスをどう変えるかが問われている、という話です。

AIエージェント開発側は、産業構造そのものを変える存在だと。内製化のパラダイムを根底から変えていく。金融における大きな意思決定のあり方も、今後大きく変わっていく、という見立てで締めくくられていました。

参加して感じたこと

AI駆動開発の推進やMCP開発などに携わっています。今回のイベントで改めて感じたのは、業界全体が同じフェーズにいる、ということです。FDEの考え方が全体を通じて繰り返され、PoCの先にはガバナンスと、Human in the Loop から Human on the Loop への変化がある。個人の生産性が上がっても、組織全体には広がらない。

ガバナンス — エージェントのインベントリ管理、eval、サプライチェーン。PoCの先にあるガードレールの設計。

Human in the Loop から Human on the Loop — 人間はループの外側で目的・制約・品質基準を設計する。最後のチェックは人が行いたいという心理も、設計に組み込む。一方で、完全自律が必要な領域ではHOOL（Human Out of the Loop）の世界も近づいている、という感触もあった。

組織への適用 — ログを見せる、時間を確保する、小さな目標を明確に書く。足並みを揃える仕組みを動かし続ける。

広木さんと山崎さんのパネルディスカッションと、みずほのパネルは、それぞれ「品質とスピードの向こう側」と「本番導入のリアル」という異なる角度から、同じ問いに答えていました。社内でも得た学びを活かし、お客様への価値につながる形でAI駆動開発を進めていきます。

おまけ。会場のUFOキャッチャーでHHKBをゲットした話

セッションの話は以上です。余談ですが、会場の雰囲気も楽しかったので少しだけ。

ファインディのブースにUFOキャッチャーが置いてあり、何度かチャレンジしました。1日目は参加賞のシールだけ。二日目、掴めたボールの中身を確認したらHHKBでした。イベント直前にHHKB Professional Classicを買ったばかりだったので、運の使いどころに迷いましたが、在庫から選べるとのことでHHKB Studioに。一応、本厄の年なので帰りはしっかり足をつけて帰りました。

HHKBブースではマグカップもいただいています。Cursorブースではキャップとクレジットをいただきました。イベントの雰囲気は個人の note に写真付きでまとめています。

AI Engineering Summit Tokyo 2026に行ってきた

弥生では一緒に働く仲間を募集しています。
www.yayoi-kk.co.jp

弥生のエンジニアに関する note 記事もご覧ください。
note.yayoi-kk.co.jp


弥生エンジニアの公式Xのフォローもよろしくお願いします！