はじめに
TIGの坂本です。AIエージェントの導入・推進・開発を担当しています。
AIエージェントを現場に導入することは、もはや至上命題になりました。プロンプトエンジニアリングから始まり、ハーネスエンジニアリング、ループエンジニアリングと、うまく動かすための語彙が半年ごとに入れ替わっています。
2026年7月24日、AI Dev Day 2026に参加しました。一日通して壇上で繰り返し出てきたのは、新しい呼び名ではありませんでした。コストと、信頼です。
フューチャー技術ブログでは、他のカンファレンスの参加レポートも公開しています。あわせてどうぞ。
- 初めての海外カンファレンスとKubeCon Japan参加レポート
- try! Swift Tokyo 2025に参加してきました！
AI Dev Dayとは
もともとは「Azure OpenAI Service Dev Day」（通称AOAI Dev Day）という名前で、2024年から開催されていました。2026年からはAzureに限らない形となり、AI Dev Dayへ改称されています。掲げているのは、AI技術をPoCで終わらせず、本番環境へどう載せるか、という実践寄りの問いです。コミュニティ主導のカンファレンスで、成り立ちのとおりAzure関連の技術要素を使った発表が多い印象でした。
Opening「Fast Alone. Far Together.」
生成AIの活用が始まってから、3年ほどが経ちました。PoCは進んでいるものの、プロダクションレベルまで到達したものは多くありません。オープニングで運営から出たのは、デベロッパーが実際に価値を届けるところまでいかなければ、AIブームそのものがバブルとして終わってしまうのではないか、という危機感でした。
スローガンの「Fast Alone. Far Together.」は、その裏返しです。早く進むだけなら1人のほうがよく、AIを使えばコードは1人でいくらでも書けるようになりました。それでも遠くへ行くには、知見を持ち寄って皆で進むしかありません。この日のセッションは、どれもこの前提の上に置かれていました。
Keynote: From prototype to production（Jeff Hollan氏 / Microsoft）
3年前と比べて、行っている仕事の全体が入れ替わったという話から始まりました。以前はコーディングが好きでも、デザインが得意でなければウェブサイトの構築は難しく、そこで止まった人も多かったはずです。今はモックアップまでAIが作るので、人間のメインタスクはレビューと意思決定に移りました。シンガポールの空港からエージェント経由でMicrosoft Foundryに接続し、45分座っているだけでデモが仕上がる、という実演も紹介されました。
では、あとは待っていればスケールするのでしょうか。Hollan氏が挙げた今のボトルネックは、モデルではなく、システム全体のエージェントフレームワークとランタイムでした。
比喩として挙げられたのは電気の普及でした。各工場が自前の蒸気機関を持ち、エンジンとラインシャフトで動力を配っていた時代から電気に切り替わったとき、工場は動力の置き方そのものを設計し直しました。AIも同じで、既存の組織にエージェントを足すのではなく、AIを中心とした組織構造を考えることから始めるべきだ、という話でした。
そのうえで、エージェントに求められる条件が4つ挙がりました。
- どのように動作するかが分かること
- 何を知っているかが分かること
- 行動を信頼できること
- 常に改善されること
1つめと2つめは、空港から45分放っておけるデモが成立するための条件です。何をしていて何を知っているのかが見えなければ、離れた場所で任せる判断はできません。Foundryはタスクが中断されても継続でき、問題が発生したときに復旧し、他のエージェントに引き継げるように作られています。残りの2つの説明に、この日いちばん時間が割かれていました。
エージェントに身元を持たせる
組織内のデータは、業務データ、ナレッジグラフ、データレイクと分散しています。どこにあるかはユーザにとって重要ではなく、AIエージェントがアクセスできることだけが重要だ、という整理でした。とはいえ、無条件に何でも参照させるわけにはいきません。
Microsoftはエージェント間のIDを保有する方向に進んでいます。エージェントが独自のアイデンティティを持ち、他者の同意に基づいて代理で行動します。その行動はすべて監査でき、管理でき、可視化されているので、エージェントが本来の役割を果たしているかを確認し、時間の経過とともに改善していけます。信頼を成り立たせているのはアイデンティティと可観測性の2つだ、という言い方が印象に残りました。
改善の話も具体的でした。企業内でエージェントを実用化したチームは、最初のエージェント作成に2〜3ヶ月を費やし、そこから展開して、理解して、学習を始めます。継続的な改善は求められますが、そのたびにエンジニアの工数を奪われるのでは回りません。Foundryには、そこを自律的に回すための最適化ジョブが用意されています。
ソフトウェア開発の民主化、そして日本のコミュニティの未来（Microsoft & Anthropic）
登壇は、AnthropicのJunichiro Tsujiさんと、Microsoftの榎並さんです。TsujiさんはSonyのPlayStation、GoogleのStadia、Robloxを経て現職、榎並さんもSony出身という組み合わせです。
プロダクションレベルで生成AIが書いたコードを使っている人が、明らかに増えました。ソフトウェアを作る障壁はほぼ消えた、という認識が両者で一致していました。民主化自体はこれまでも起きていますが、専門家でなくても誰でも作れる、という段階は今回が初めてです。
障壁が消えると、残る仕事は課題をいかに言葉にするかに寄ります。ドメインの深い理解と、どこを作るべきかを決めるセンスや判断が効くようになります。実際、あるハッカソンで上位入賞した5組のうち4組はエンジニアではなかったそうです。
分かりやすい例として、建築家の話が出ました。家を建てるまでの工程よりも、申請を通すまでの時間が長いとのことでした。92%の申請が一度却下されるので、そこに時間が吸われていました。これをClaudeで解消したとき、強かったのは技術に詳しい人ではなく、課題を1番よく知っていた人でした。
生産性をどう測るか
Foundryの開発では、エンジニア9人が3週間で10万行をコミットしています。意外と自分たちでもできるのではないか、と思うかもしれません。ただ、8時間労働でもコーディングに使えるのは25%程度だと考えると、この数字の見え方が変わってきます。オンボーディングもAIに任せ、3〜4週間かかっていたものを1週間に短縮した話も続きました。
行数が増えても、エンジニアの最終的な仕事は変わりません。動くコードであることを証明することです。だから正しい成果はアウトカムベースで評価すべきで、行数や工数で測る話ではありません。
AIを使っても、人によって生産性は変わります。シニアエンジニアには経験があるので、使いこなしたアウトプットを作れます。ジュニアは経験がないので、出てきたものの判断がつきません。登壇者からは「米国のような資本主義だとシニアだけを育てるから、日本にもいつか勝てる時代が来るのでは」と思っていた、という話も出ました。ただ、向こうも問題点にはさすがに気づき、看護師と同じような育成の仕組みへ変わってきているそうです。
トップダウンとボトムアップの両輪
経営層から「AIを使え」という指示が降りてくるものの、現場はどう使えばいいか分かりません。よくある詰まり方です。有志が集まってハッカソンをやり、使い方を実際に見せると、そこで初めて伝わるようになりました。これがボトムアップで、経営陣も言うだけでなく実際に手を動かして感じるのがトップダウンです。どちらか片方では動かない、という話でした。
ハッカソンのコツも共有されました。
- アイデアを共有する場を作ること
- 有志で手を挙げてくれる人を、トークンでブーストすること
そのうえでAI CoE（AI Center of Excellence）を作り、組織としての成功に導いていきます。ここにはいくつかの段階があり、いきなり最後の段階には行けません。AI人材の育成では、結局ハッカソンやコミュニティが効いてきます。
最後のテーマは、コミュニティはコミュニティが作る、というものでした。Claudeのコミュニティアンバサダーを募集中で、熱量を高く書くと評価してもらえるそうです。イベント運営向けのAPIトークンやグッズのサポートもあり、会場のQRコードから応募できるようになっていました。
DBひとつでRAGからエージェントメモリまで（PingCAP）
TiDBはMySQL互換のオープンソース分散型DBです。無停止で水平スケールでき、最初から3AZにまたがって起動します。金融、インターネット、ゲーム業界を中心に採用事例が増えています。
そのTiDBが、TiDB XとしてAIネイティブDBへリアーキテクチャされました。コンセプトは「全てのエージェントにDBを」です。紹介された特徴は次のとおりです。
- AI利用に適したマイクロサービス構成とサーバレス構成を取り、クエリが来たら起動する従量制課金
- リレーショナルなクエリだけでなく、ベクトル検索と全文検索も同じDBで扱える
- サインアップ不要で、アクセスした瞬間にインスタンスが作れるTiDB Cloud Zero（データは30日保持）
KIMIのウェブサイト自動生成のバックエンドにも使われているそうです。
登壇資料が公開されています。
なぜエージェントにDBが必要なのか
LLMはステートレスなので、mdファイルやプロンプトから毎回情報を引っ張ってきます。その外部情報源としてDBを置くと、用途は大きく2つに分かれます。RAGと、エージェントメモリです。
RAG側で強調されたのは、データの質でした。参照元のデータが問題を抱えていたら、それが表面に出てくるだけです。データの質こそがAIプロダクトの質を決めるという言い方は、自分の現場でも思い当たるところがありました。
TiDBはDDLの宣言だけで、ベクトル検索と全文検索の両方をサポートします。embeddingも自動で処理され、モデルの指定もできます。どちらか片方では弱点が残るので、両方に問い合わせて結果をマージするハイブリッド検索で精度を上げます。同じDBに両方あることで、データ統合をDB側で済ませられ、コンテキストを無駄に消費しません。PingCAP自身も、docsを食わせたRAGであるTiDB AIでサポートを提供していて、クエリ拡張とGraph RAG（先にグラフ構造を構築し、周辺ノードを取得して返す）で精度を上げているとのことでした。
メモリを起点にスキルとツールを直す
生成AIがレシピブック、Agentic AIがシェフ、という対比が使われていました。レシピを渡すだけなら記憶は要りませんが、シェフとして働くなら、前回どうだったかを踏まえて1歩踏み込む必要があります。TiDBは、そのためのエージェントメモリとして「mem9」を提供しています。
やっていること自体は素直です。
- これまでの履歴をDBに記録し、ベクトル検索で関係する部分だけをコンテキストに載せる
- 記録するのは再利用できるFactのみで、既存の事実と矛盾しないかをリコンサイルする
- 直近の会話履歴は、そのままコンテキストとして保持する
Mem0が複数テーブルで管理し、CrewAIが半減期を実装しているのに対して、実装方法が異なるという説明でした。
メモリだけ改善されればOKではありません。メモリを起点に、スキルやツールのほうを改善していきます。同じエージェントでも、スキルハブを通して違うスキルを利用できるようになっています。コンテキストを共有する機能もあり、チームでやり取りの内容を確認できます。スキルに相当するものを扱う「drive9」もあり、見た目はファイルシステムですが、ファイルを配置した時点でLLMがメタデータを生成し、メタ情報で検索できます。エージェントのデータハーネスとして進化していく、という位置づけでした。
t_wadaさんに聞く MS Build 2026で見えたもの
2026年6月にGitHub Copilotが従量課金になりました。「使い放題」が終わった象徴的な出来事として、まずここが挙がりました。MS Build 2026を貫いていたのは、次の式です。
performance = tokens / (Watt + $) |
問われるのは、トークンをどれだけ積めるかではなく、電力と金額あたりでどれだけの成果が出るかです。とにかくトークンを積むトークンマキシングの時代は、これで終わりました。
Microsoftは自前で7つの新しいモデルを発表しています。コーディング向けのMAI-Code-1-Flashは、Haikuくらいの価格でSonnet未満くらいの性能だという評価でした。最高性能のモデル1つに全部やらせるのではなく、モデルの使い分けが今後のテーマになります。「ほどほど頭が良くてほどほど安い」がハーネスエンジニアリングにおけるスイートスポットになる、という指摘は、この日いちばん腑に落ちた話でした。
Foundryと3つのIQ
Knowledge IQ、Data IQ、Work IQという3つのIQは、大体が既にGAになっています。特にWork IQは「ないと仕事にならない」くらい効くという評価でした。※使うにはM365と従量課金が必要な点は注意が要ります。どうエージェントにコンテキストを渡すかという問題に対して、Microsoftは垂直統合していることの強みをそのまま押し出してきています。
実行環境としてのサンドボックス
自分の関心にいちばん近かったのは、この話でした。Container Apps Sandboxと、Microsoft Execution Containers（MXC）です。OpenClawのようなエージェントをいかにうまく動かすかという文脈で、アイソレーションのレベルを選べてグラデーションを変えられることが重要だと説明されていました。GitHub Copilot CLIのクラウドサンドボックスとローカルサンドボックスは、実際にこれを使っています。SDKとして提供されているので、自分のアプリに組み込むこともできます。エージェント専用のサンドボックス環境として、起動が1秒以内のMicro VMも用意されています。
プロンプトやツール定義ではなく、実行環境のレイヤーでハーネスを用意する。この発想が製品として出てきたことが、今回いちばん大きい変化だと感じました。
OpenClawの作者であるPeter Steinberger氏もKeynoteに登場し、Windowsで動くようになったこと（Microsoft Scout）が発表されました。Work IQやEntra IDと繋がって自動化していく方向です。他のセッションでは、OpenClawの作り方やループエンジニアリングの話も出ていました。日々の開発のペイン自体を無くすためのものを作ろう、という考え方が共通していました。
ソフトウェアの防御力はどこにあるか
「SaaS is dead」の文脈で、Chip Huyen氏のセッションが紹介されました。AI時代になり、ソフトウェアは簡単にコピーできるようになりました。UIやコードは、もう防御力になりません。データが堤防になっていた期間はありましたが、メガベンダーは買収でデータを手に入れられます。顧客のほうも、Claude、Codex、Cursorと簡単に移動していきます。ジブリ風の画風がプロンプト1つで再現できてしまうのと、構造は同じです。
では、どう守るのか。挙がったのは3つでした。
- 競合より早く出すスピード
- ドメインへの深い理解やローカライズで効くニッチ
- プロダクトにAI親和性を持たせておくこと
どれも決定的ではありませんが、AI親和性を持たせておけば生き延びられるかもしれない、という言い方が現実的でした。
Simon Willison氏のプラグマティックなAIエンジニアリングも引用されていました。我々の仕事はプロダクションで動くコードを作り、それを保証することです。 民主化のセッションで出た「動くコードであることを証明する」と、同じことを言っています。
AI時代のテスト駆動開発
「まずRedにしてからテストを書くことに、無駄なプロセスがあるのではないか」。聞き手の長瀬マキさんが、この問いを立てていました。
昔は「テストファーストをやれ」と書いてもLLMは従いませんでした。その代わり、「t-wadaのTDDをやる」と書けば従ったそうです。当時はこの回避策が共有されていました。今はRed-Green TDDをやらせるといい感じになるものの、効率的ではないとも思う、という評価でした。先にテストを書き、後で実装をやらせること自体はマストです。ただし、テストと実装を往復しながら徐々に歩幅を広げることはできます。diffが大きすぎると人間がチェックしきれないので、歩幅を小さくしてauto modeで回すくらいがちょうどいい、という話でした。ちなみにAIも、diffが大きいとサボるそうです。
なお、このセッションで言及されていたMicrosoft Build 2026（2026年6月2日、サンフランシスコ開催）のセッションは、公式のYouTubeプレイリストで視聴できます。全224本あるので、気になるトピックから拾うのが良さそうです。
AWSヒーローがAzureでもAIエージェント構築してみた件（みのるんさん）
AWSヒーローとしてAIエージェントの導入を進めている方ですが、実はMicrosoftメインでやっていた時期もあるとのことでした。所属のKDDIアジャイル開発センターは、KDDI外の人にもアジャイル開発を届けることをやっています。題材はSIぽい発注業務で、これを生成AIでやっていきます。
発注には踏むべきプロセスがあり、プロンプトを投げるだけでは進みません。そこで、計画、実行、観察、分析のループを回すReAct型に載せます。
ノーコードからSDKまで
一度ツールを用意してしまえば、あとは自然言語で頼めます。選択肢はレイヤーで並んでいました。
- TeamsやM365で使うなら、Copilot Studioでノーコード
- Azureで作るなら、Foundry Agentsでノーコード
- 細かく作り込むなら、Agent FrameworkのSDK（Pythonと.NETに対応）
そもそもなぜフレームワークを使うのか。共通化する処理は事前に用意してある方が良いからです。決定論的にやる部分はワークフローで書き、非決定論的に調べるところをエージェントに任せます。LangGraphのようにワークフローを作成すれば、HITL（Human-in-the-loop）も差し込めます。
デプロイ先の3択と運用
MS系のデプロイ先は3つ挙がりました。
- 軽めの処理向けのAzure Functions
- コンテナ対応はしやすいものの、認証系が複雑なAzure Container Apps
- 色々揃っていて1番やりやすいFoundry Hosted Agents
運用で必要になるのは、次の5つです。
- 会話の記録
- 権限制御
- ファイルの扱い
- スケーリング
- トレーシング
Hosted Agentsならこのあたりをまとめて管理できるとのことで、登壇中に実際にデプロイしていました。渡すのはソースのZIPだけです。呼び出し方はチャット形式のResponsesと、invocations方式の2種類です。設定を変えると新しいVersionとして残り、メタデータで切り替えられます。
他クラウドと比べてどう選ぶか
他のクラウドでも同じようなことはできる、という前提が最初に置かれました。そのうえで挙がった選び方の観点は、次の3つです。
- 呼び出し元のプロトコルに応じて変える
- 実装言語で何を使いたいか（TypeScriptなど）
- ID系はEntra統合が楽で、Teamsから呼び出すアプリもAzureが楽
ハーネスでやるようなことをワークフローで実現できますが、AWSとAzureのハーネスはレイヤーから中身まで違うので、そのまま移植する話にはなりません。結果として、使われるところに置けるかどうかで決まっていました。
さいごに
新しい語彙を覚え続ければ追いつけると思っていましたが、一日聞いて残ったのは語彙ではなく、置き場所の話でした。
持ち帰った学びは、次の4つです。
- ハーネスは、プロンプトの書き方ではなく実行環境のレベルで用意する
- エージェントの行動履歴はトレースし、監査対応に使うだけでなく改善のインプットにする
- 組織に定着させるには段階的な盛り上げとAI CoEが要り、いきなり最後の段階には行けない
- 何より、実際の課題があるところに飛び込む
建築家が申請の却下率を知っていたから解決できたのと同じで、課題を1番よく知っている人が強い時代になりました。
トークンマキシングの時代は終わりました。問われるのは、積んだトークンの量ではなく、それが生んだビジネス価値のほうです。価値がトークン使用料を上回っているかを見て、最適なモデルを選ぶ作業も必要になります。
デベロッパーが実際に価値を届けるところまでいかなければAIブームが終わってしまう、というオープニングの危機感は、結局ここに帰ってきます。1人でコードを書く速度は、もう十分に上がりました。それでもビジネス価値まで届かせるには、うまくいった置き方を持ち寄るしかありません。「Fast Alone. Far Together.」が一日を通してコンセプトとして機能していたのは、そういう意味でした。
そのうえで、次に決めなければならないのはKPIです。どのKPIなら、エージェントが出した価値を測れるのか。ここは持ち帰りの宿題になりました。
]]>
