はじめに：サミット全体を通して見えてきたもの
2026年6月8日〜6日9日に開催された『AI Engineering Summit Tokyo 2026』に行ってきました。2日間で、13のセッション・ポスター展示に参加しました。正直に書くと、初日の途中までは、学びよりも漠然とした不安のほうが大きかったように思います。
各社が口を揃えて語るのは開発自動化の加速であり、AIエージェントが実装からレビュー、マージまでを自律的にこなしていく世界です。すべてが一瞬でできるようになったとき、企業としてシステム開発を行う意味はどこに残るのか。そして、自分の仕事や役割はどうなっていくのか。話を聞きながら、そんなことを考えていました。
ただ、2日間を通して聞き続けるうちに、少しずつ見え方が変わってきました。AIをうまく活用している会社の強さは、どれだけ高性能なAIを使っているか、というところから来ているのではなさそうだ、ということです。各社が使っているモデル自体は、ClaudeやGeminiのように、いまや誰の手にも届くものです。
それでも、AIにどこまでの仕事を安心して任せられているかには、組織によってはっきりと差があります。その差を生んでいるのは、人間の頭の中にあるもの――判断基準や専門知識、ルールといったもの――を、どれだけ丁寧に言葉にしてAIに渡せたかなのではないか。そう感じられる話が、業界を問わずいくつも続きました。
このレポートでは、この「言語化」という観点から2日間の学びを3つに整理し、それを自分の業務にどう取り入れていきたいかを書きたいと思います。
学び①：速くなるほど、ボトルネックはレビューに移っていく
このことを考えさせられたのは、Helpfeel、三菱UFJ銀行、なるセミの3つの講演でした。
Helpfeelの講演では、CodexとClaudeを連携させ、AI同士に2往復ほどの「会議」をさせてコードの品質を高める手法が紹介されていました。
三菱UFJ銀行では、人がレビューすると数時間から翌日かかってしまう作業を、AIによるレビューで数分に短縮していました。なるセミの講演者は、自分のレビュー観点を分解してファイル化し、1エージェントにつき1観点を担当させる「7人のレビュアーAI」を構築していました。
三社に共通していたのは、実装の速さそのものはもう大きな課題ではなく、「人間のレビューが追いつかないこと」が次のボトルネックになっている、という認識でした。
AIが何倍もの速さでコードを書けるようになっても、それを確認する人間の速度が変わらなければ、全体の速度は変わりません。私自身、レビュー依頼から返答までの待ち時間が作業の区切りになってしまう経験があり、この話は他人事には聞こえませんでした。
そして3社とも、その解決策として「AIにレビューさせる」という同じ方向を向いていたことが印象に残っています。AIをきちんとしたレビュアーにするには、自分が普段なにを見てOK/NGを判断しているのかを、言葉にして渡す必要があります。
なるセミの講演者はこれを「サーヴァントエンジニアリング」――人間の判断基準を外部に再構成する営み――と呼んでいました。レビューを楽にするテクニックの話というより、自分の頭の中を写し取っていくような、地道で本質的な作業の話なのだと受け止めました。
学び②：『暗黙知』という言葉が、いちばん心に残った
学び①が判断基準の言語化だとすれば、もう一段深いところにあるのが『暗黙知』の言語化です。この言葉は、2日間で私の中にいちばん残ったキーワードでした。業界のまったく異なる複数のセッションが、それぞれの現場から同じ場所にたどり着いていたからです。
法律分野に特化したLegalscapeの講演で、暗黙知とは何かが初めて腑に落ちました。
暗黙知とは、その分野では当たり前すぎて、書き起こそうとすら思わない知識のことです。専門家は聞かれれば答えられるけれど、自分から語ることはない。だからドキュメントには残らず、AIの学習データにも存在しません。Legalscapeは、この暗黙知をAIと専門家の対話を通じて少しずつ引き出し、蓄積することで、簡単には真似できない強みを育てていました。
製造業のBALLASでも、同じ構造の話を聞きました。図面には書かれない現場の暗黙知が壁となって、AI単独では業務を理解できない。だからこそ暗黙知の設計・構造化にいちばん力を注ぎ、構造化したデータとともにAIに渡す工夫をされていました。
福祉業界のLITALICOも、長年積み重ねてきたドメイン知識をプロンプトやガードレールに丁寧に作り込むことで、汎用AIには出せない専門性を実現していました。
法律、製造、福祉。畑のちがう3社が、口を揃えるように「暗黙知をどれだけAIに渡せるかが鍵だ」と語っていたことに、静かな説得力を感じました。
高性能な汎用LLMは、もう誰の手にも届くものになっています。そのなかで差が生まれるとすれば、UIや機能ではなく、その会社・その人にしか書き起こせない暗黙知の深さなのではないか。そしてこれは、学び①のレビュー観点の話とまったく同じ形をしています。どちらも、人間の頭の中にしかないものを、AIが使える形に書き起こすという仕事です。
もし、あらゆる分野で暗黙知の言語化が進んでいけば、AIが専門家のようにふるまえる日もそう遠くないのかもしれません。裏を返せば、暗黙知が言葉になっていない領域では、AIはいつまでも「それらしいけれど信用しきれない」答えしか返せないままです。この差が、これからのAI活用の分かれ目になっていくように思います。
学び③：AIに働いてもらうには、環境とルールにも言葉が要る
学び①と②が「知識や判断基準の言語化」だとすれば、もう一つ言葉にしなければならないものがあると気づかされました。
それは「任せ方」そのものです。どこまで自由にやっていいのか、何には触れてはいけないのか。人間の同僚であれば空気や常識で察してくれるこの線引きを、AIは持っていません。だから、任せ方もまた言葉にして渡す必要があるのだと教えられました。
Ubieは、AIエージェントに難しいタスクを任せるために、ローカルに独立したサンドボックス環境を用意していました。印象的だったのは、これが単なる「隔離」の話ではなかったことです。プロキシでアクセスできる情報を明確に設定し、共有スコープに応じて権限を分ける。
つまり「ここまでは何をしてもいい、壊れたらサンドボックスごと捨てれば済む」という自由の範囲を、設定という形ではっきり言葉にして渡していました。境界が言葉になっているからこそ、その内側ではAIに思い切り自由を与えられる。安全性と自律性は、この線引きの言語化によって初めて両立するのだと感じました。
一方で、反面教師として心に残った事例もあります。BaseMachinaの講演で触れられていた、権限制御の不足によってAIエージェントが本番環境を削除してしまった事故です。考えてみれば「本番環境を勝手に消してはいけない」というのは、人間同士なら言わなくても通じる暗黙の了解です。しかしAIはその暗黙の了解を持っていません。
これは学び②の裏返しでもあります。言葉にされていない暗黙知をAIが知らないように、言葉にされていないルールもまた、AIには存在しないのと同じなのです。
BaseMachinaの「Zero Trust for AI Agents」という考え方や、三菱UFJ銀行の「いつAIを使うかを文書化・標準化して組織の力にする」という取り組みは、いずれも、これまで「言わなくてもわかる」で済ませてきた部分をきちんと言葉に起こしていく営みでした。
AIに大きな仕事を任せられるかどうかは、AIをどれだけ信頼するかではなく、知識だけでなく任せ方の線引きまで含めて、どこまで言葉にできているかにかかっているのだと学びました。
自分の業務にどう取り入れていくか
ここまでの学びを、感想で終わらせずに自分の仕事に落とし込みたいと思っています。具体的には、次の4つから始めるつもりです。
(1) 提出前に通す「レビュアーAI」を手元に作る
三菱UFJ銀行の事例から、いちばん直接的に持ち帰ったアイデアです。上司のレビュー視点を持たせたAIを自分の手元に用意し、成果物を提出する前に必ず通すようにします。
人へのレビュー依頼は返答まで時間がかかりますが、AIなら数分で返ってきます。上司の時間をいただく回数を減らしながら、提出物の初期品質を上げられるはずです。まずは、これまでいただいてきた指摘を振り返り、「何を見られているのか」を観点として書き起こすところから始めます。この作業自体が、学び①の言語化の練習になると思っています。
(2) レビュー観点は1エージェント1観点に分けてみる
なるセミの講演で学んだとおり、AIにたくさんの観点を一度に渡すと、指示を守りきれなくなるそうです。観点をファイルとして分割し、1エージェントに1観点を担当させる形を試してみます。具体的な実現方法はまだ手探りですが、小さく手を動かしながら学んでいきます。AI同士にレビューと修正をループさせる手法も、その先で取り入れられたらと考えています。
(3) 自分の業務の「暗黙知」を書き残す習慣をつける
学び②を自分にあてはめるなら、対象は自分の業務知識です。当たり前すぎて書き起こそうとも思わないことこそ、AIに渡せていないものであり、チーム内の認識のずれの原因にもなっているように思います。
Legalscapeの「AIとの対話を通じて暗黙知を引き出す」というやり方にならって、日々AIと対話するなかで、自分が無意識に前提にしている知識に気づいたら、その場で書き残すようにします。小さな積み重ねですが、将来自分の業務をAIに任せるときの土台にも、チームへの引き継ぎの資産にもなると考えています。
(4) AIに渡す権限を、毎回自分の頭で考える
学び③については、まず自分の姿勢から変えたいと思います。
AIに仕事を任せるとき、「このタスクにはどこまでの権限が必要で、どこからは渡すべきでないか」を、毎回立ち止まって考えるようにします。
本番環境の削除事故は、そこを考えずにAIを使った結果として起きています。便利だからと無自覚に強い権限を渡すのではなく、必要最小限は何かを問い続ける癖をつけたい。その積み重ねが、いずれAIエージェントを本格的に業務に組み込むときの、自分なりの判断基準になっていくと思っています。
むすび：不安への、いまの自分なりの答え
最後に、冒頭に書いた不安のことに戻りたいと思います。
みずほFG×Cognition AIのセッションで、コンピュータの歴史が01の世界からアセンブリ言語へ、アセンブリ言語からプログラミング言語へと抽象化されてきたように、これからはプログラミング言語がAIとの会話に置き換わり、人の関わりは少しずつ薄くなっていく、という話がありました。
効率化として正しい流れだと頭では理解しながらも、自分の手でものを作る過程を楽しむ、職人としての喜びが薄れていくことへの寂しさを、私は確かに感じました。この気持ちは、隠さずに書いておきたいと思います。
それでも2日間を終えて、不安に対するいまの自分なりの答えは持てた気がしています。AIがどれだけ高性能になっても、人間の頭の中にある判断基準や暗黙知を言葉にする仕事は、その頭の持ち主にしかできません。登壇された企業はみな、AIに使われるのではなくAIを使いこなす側にいましたが、その分かれ目は技術力そのものというより、この言語化を地道に積み重ねてきたかどうかにあったように思います。
playgroundの講演にあった「AIを使わずに仕事をするのはダメだ」という言葉も、心に残っています。最初のうちは自分でやったほうが速く感じても、AIとともに働くやり方を覚えていけば、仕事の速度は大きく伸びていくはずです。
私はAIを使いこなす側に居続けるために、まず自分の頭の中を言葉にすることから始めます。今回のサミットは、そのための具体的な道筋を示してくれた2日間でした。
以上
