2026年6月8日・9日、『AI Engineering Summit Tokyo 2026』が開催された。私は、2日間で10を超えるセッションに参加した。
各社が使うモデルはほぼ同じで、それ自体はもはや差別化の要因になっていなかった。それでもAI活用の深度には組織間で明確な差があり、その差を生んでいるのは技術選定ではなく「どこまで任せるか」の設計力にあるように見えた。
「言わなくてもわかること」は、AIには存在しない。「本番環境を消してはいけない、ここには触れるな」など人間同士なら空気で伝わることを、AIには設計として渡す必要がある。この前提を意識して動いている組織と、そうでない組織の差は、ツールの選択よりもずっと大きかった。
このレポートでは、2日間を通じて得た3つの学びと、社内業務への活用を整理する。
速さが上がるほど、「検証」が新しいボトルネックになる
AIによるコード生成速度の向上は、すでに前提として語られていた。
焦点はそこになく、「速く生成されたコードをどう検証するか」が次の課題として浮上していた。
あるセッションでは、異なる役割を持たせた2つのAIを使い、相互に出力を批判させることで検証精度を上げる手法が紹介された。「前提そのものを疑え」という指示を与えたAIに、もう一方の出力を批判させる。人間ひとりのレビューでは見落とすような矛盾や前提の抜けを、このプロセスで検出できるという。
金融系エンジニア組織のセッションでも、「AIを活用するエンジニアと、そうでない側の生産性差は広がっているが、AIの出力を検証する方法を持っているエンジニアはまだ少ない」という指摘が出ていた。実装速度の向上が「検証の空白」を生む構造は、自社でも意識すべき課題だと感じた。
任せ方の設計が、AIの効果を決める（反面教師を含む）
AIエージェントに仕事を任せる際の「境界設計」について、複数のセッションで具体的な議論があった。
印象的だったのは「制限のための境界ではなく、自由を与えるための境界」という考え方だ。AIの操作範囲を物理的に閉じることで、その内側では確認なしに自律的に動かせる。境界が曖昧なままだと、AIが動くたびに人間が介入することになり、スピードの優位が消えてしまう。
反面教師として残ったのが、権限制御の不備でAIエージェントが本番環境のデータを削除した事故の事例だった。「本番環境を消してはいけない」は人間の常識だがAIにはない。「言わなくてもわかること」がAIには存在しないという前提を、設計の出発点に置くべきだと感じた。
任せ方を曖昧にしたまま使っていると、スピードが上がっているようで実際には検証コストが増えているだけになる。「どこまで任せるか」を決める手間こそが、AI活用の本質的なコストだと理解した。
AIの精度を決めるのはモデルではなく、人間の判断基準を形式化できるかどうかだった
「人間が仕様書を書くことを禁止した」「定例会を廃止してAIに情報整理を委ねた」という組織の事例があった。実装や情報整理をAIに委ねることで人間はより上流の設計・意思決定に集中できる、という方向性はサミット全体を通じて共通していた。
中でも示唆が大きかったのは、建設業の図面解析AIの事例だった。最終的な精度の約8割は、モデルの性能やプロンプトの工夫ではなく「ドメイン知識の構造化」に依存していたという。「155と書いてあっても規格上H-148と読む」というベテランの暗黙的な判断をAIが扱える形式に変換する、その作業が精度を左右する。
一つのセッションに限らず複数の事例に共通していた構図で、AIを使いこなす上での差は、モデルの選択よりも「人間の判断基準をどれだけ形式化できるか」にある、という点が印象に残った。コードを書くこととAIに渡すための判断基準を整理することは、別のスキルとして意識していく必要があると感じる。
得た学びをどう自分／自社に取り入れることができるか
(1) PR提出前に「批判役」を立てる自己検証フローを作る
学び2-1で紹介された手法を参考に、PRを出す前にAIに「この実装の前提の抜けや矛盾を指摘してほしい」と問うフローを開発サイクルに組み込む。上司へのレビュー依頼前に自分で解決できる問題を先に潰しておくことを目的として取り組みたい。
(2) AIへの指示に操作範囲を明示する
AIにタスクを渡す際、「触れてよい範囲」と「確認が必要な操作」を毎回明示する習慣をつける。副作用のある操作（ファイル削除、外部API呼び出し、本番環境への書き込み等）についてはリスト化し、チーム内で共有ドキュメントとして整備することを提案したい。学び2-2の反面教師を踏まえると、個人の習慣としてではなくチームのルールとして整備すべき性質のものだと考える。
(3) 自分の業務判断を継続的に言語化する
「当たり前すぎて説明していない自分の判断基準」を、AIとの対話の中で気づいたときに都度記録する習慣をつける。チームへの引き継ぎ資産にも、将来AIに業務を渡す際の入力にもなるはずなので、月次で整理して共有ドキュメントに追記していく。
「AIを使わない選択肢はない」という言葉がサミット全体を通じて繰り返されていた。ただ、そこで語られていたのはツールの選択の話ではなく、「どう設計するか」の話だった。
強みを持っている組織に共通していたのは、AIの性能ではなく、任せ方を設計し、境界を引き、人間の判断基準を形式化するという積み重ねだった。まだ実務経験の浅い私には、そのすべてを今すぐ実践できるわけではないが、まず自分の開発習慣から少しずつ取り入れていきたい。
