グラレコ
はじめに 🎯
AI Engineering Summit Tokyo 2026（Summer）は、AIエンジニアリングの実務に焦点を当てたカンファレンスです。この記事は、その 1 日目（2026/06/08）に聴講した 8 つのセッションの内容を、テーマごとに整理してまとめたレポートです。
1 日を通して繰り返し出てきたのは、「AI でコードやプロダクトを作れる」ことはもう前提になり、論点は「作ったものをどう運用し、統制し、使われ続けさせるか」に移っている、という認識でした。データ基盤、コスト、権限・監査、検証（validator）、そして「人間が理解・説明できる状態」をどう設計するか——登壇者が違っても、同じ問題意識が何度も顔を出しました。
この記事で分かること:
- 🧭 8 セッションを貫く共通テーマ（「作れる」→「運用・統制」へのシフト）
- 🏗️ 運用に耐えるエージェント設計の具体（AI Ready なデータ基盤、評価ハーネス、権限設計）
- 💸 コストと精度のトレードオフをどう設計するか（ルーティング・カスケード・上限設計）
- 🧠 知識を個人のセッションに閉じ込めない仕組み（AI-DLC のチェックポイント、会話文脈の引き継ぎ）
- 🔐 企業導入の壁（セキュリティ・監査・スケール）と、その越え方
🧭 1 日を貫いたテーマ：「作れる」から「使われ続ける」へ
個別のセッションに入る前に、全体像を先に置いておきます。次の図は、この日繰り返し語られた「重心の移動」を示しています。
この図のポイントは、登壇者の業種（OpenAI、データ企業、不動産テック、医療 SI、通信キャリアなど）が違っても、行き着く先が共通していたことです。「PoC は動いた。問題はその先だった」という話が、表現を変えて何度も出てきました。以降、各セッションを順に見ていきます。
なお、聴講した 8 セッションの一覧は次のとおりです。
| # | セッション | 登壇者（所属） | 主題 |
|---|---|---|---|
| 1 | Transforming the enterprise with FDE | 水越 将巳 氏 / Ryan Cain 氏（OpenAI Japan） | FDE という伴走型の進め方 |
| 2 | 運用を見据えたAIエージェント設計実践 | 真嘉比 愛 氏（ちゅらデータ 代表取締役） | AI Ready なデータ基盤と運用設計 |
| 3 | 組織でAIプロダクトを作るには | 須藤 郁弥 氏（estie 不動産AI Lab） | AI Enabling Unit と AgentHub |
| 4 | 正気を疑う技術 | 橋本 翔 氏（Helpfeel Cosense PdM） | AI に正気を疑わせる開発プロセス |
| 5 | 【公募】AIエージェント構築事例 | 高木 詩織 氏 / 坂本 一樹 氏 / 京仲 俊樹 氏 | 3 社の構築事例（医療 SI を中心に） |
| 6 | チームで実践する AI-DLC | 福井 達也 氏（Belong CTO） | AI-DLC にチェックポイントを足す |
| 7 | AI Editor開発の現場から | 伊藤 宏樹 氏（テックタッチ 事業部CTO） | プロダクト化に向けたエージェント設計 |
| 8 | 企業で使えるAIエージェントとは | 中山 達嗣 氏（ソフトバンク） | AGENTIC STAR と「自律」の定義 |
1️⃣ Transforming the enterprise with FDE（OpenAI Japan）
トップバッターは OpenAI Japan の FDE（Forward Deployed Engineering）チームによるセッションでした。FDE は、ビジネス課題から出発し、ユーザーと伴走しながら反復的に開発を進め、インテグレーションを実運用レベルまで磨き込み、その知見をプロダクトへ昇華していくアプローチです。
印象的だったのは、技術を売るのではなく「業務そのものをお客様（現場から経営層まで）と一緒に伴走して、業界を変えていく」という立て付けでした。FDE の進め方は、次のループとして語られました。
この図のポイントは、「事業課題 ↔ 研究 ↔ 導入」が一方通行ではなくループになっていることです。大事にしていることとして「データとコンテキスト」「信頼性とガバナンス」が挙げられ、ここでも“作って終わり”ではない姿勢が示されました。OpenAI 自身もエージェントのコードを半年間で一新して作り直している、という話があり、進化の速さの中で土台を組み替え続ける前提が共有されました。
2️⃣ 運用を見据えたAIエージェント設計実践（ちゅらデータ）
この日いちばん情報密度が高かったのが、ちゅらデータ代表取締役・真嘉比 愛さんのセッションです。出発点は「“作れる”と“使われ続ける”は別問題」という一言でした。実際に起きた失敗として、本番 DB を削除した、存在しない割引を作って顧客に案内した、カスタマーサポートを AI にしたら満足度が下がって人間を復活させた、といった生々しい例が紹介されました。
なぜ運用は難しいのか（PoC → 本番）
PoC と本番の違いは、次のように整理されていました。
- 固定データで検証する PoC から本番へ移ると、データを AI 前提で更新し続ける必要がある。古い/未整備のデータはハルシネーションの要因になります。
- 限定シナリオの評価だけでは足りず、多様・想定外・敵対的な入力に対処するガードレールが必要になります。
- 人間が結果を確認できる PoC から、無人または少人数で品質を守る運用へ変わります。トレースを付与し、自動評価と劣化検知が要ります。
- サンドボックスから本番へ移ると、エージェントが権限を持って実データを操作するため、失敗が実害につながります。
AI Ready なデータ基盤の 5 層
このセッションの核心が、AI が使えるデータ基盤を 5 層で捉える整理でした。
各層の役割を表に整理すると、次のようになります。
| 層 | 役割 | 例 |
|---|---|---|
| コンテキスト | データに意味・出自・鮮度・前提を付与する | このカラムは税抜か税込か |
| データモデル | 構造・粒度・関係性を定義する | スタースキーマで fact_ / dim_ を分離 |
| オントロジー | 概念と関係を抽象レベルで定義する | 「解約予兆＝直近3ヶ月の利用頻度が前年同期比50%以下」を複数テーブルで共有 |
| ガードレール | やってはいけないことを構造的に防ぐ | 個人を特定できる集計を返さない（k匿名性） |
| 評価ハーネス | 出力の正しさ・劣化を継続測定する | 本番トレース取得、異常回答のアラート |
補足として、オントロジーに載る指標は Semantic Layer で管理し、「意味（定義）」と「実装（クエリ）」を 1 つの定義単位で一元管理する、という話がありました。別々に持つと利用の中で定義がズレる（metric drift）からです。さらに、データ基盤は“作って終わり”ではなく、メトリクス定義をコードとして管理する definitions as code（PR レビュー・CI テスト・バージョニング・廃止ルール・メトリクスオーナー）と、劣化を継続検知するデータオブザーバビリティ（リネージと組み合わせて上流原因と下流波及を特定）が必要だと続きました。
精度とコストはトレードオフ
精度とコストの両立も大きなテーマでした。最上位モデルを多段に並べれば精度は高いが過剰コストになり、安価モデルで置き換えればコストは低いが精度不足になりやすい。打ち手は大きく 3 系統（同じ精度で安くする＝キャッシュ・バッチ／最適点を選ぶ＝ルーティング・カスケード／フロンティアを押し上げる＝SLM・ファインチューニング）で、着手順が重要だと強調されました。
この図のポイントは、多くの企業で SLM のホスティングやファインチューニングは最後の選択肢だ、という順序です。事例として、Checkr では大多数の易しいタスクをファインチューニングした SLM に任せ、難しい一部だけ上位モデルへ回すカスケード構成にし、コスト約 1/5・約 30 倍の高速化を達成した、と紹介されました。
ルーティングは「複雑な仕組みより、まずはルールベースで十分。計測しながら段階的に導入する」のが基本方針でした。
コストは静かに暴走する
警句として刺さったのが「コストは静かに暴走する」でした。エージェントは呼び出し回数を人が握らない設計になりがちで、気づかないうちにコストが膨張します。代表例として、暴走したマルチエージェントが互いに 264 時間やり取りを続け、11 日間で約 $47,000 の LLM API 費用を発生させた事例が挙げられました。ステップ上限・予算上限・終了判断を行うオーケストレーターが無く、API エラーも出なかったため、月額請求まで発覚しなかったそうです。計測だけでなく上限を設けることが対策になります。
AgentOps と「どこまでやるか」
運用思想は MLOps → LLMOps → AgentOps へと拡張され、観測性・トレーサビリティ・フィードバックループ・安全性/ガバナンスが要点として挙げられました。ただし「一度に全部やる」のではなく、投資対効果を見ながら最小構成から広げる、という現実解が示されました。
| 段階 | 内容 |
|---|---|
| MUST（最優先） | トレース収集 / 小さなデータセットでの評価 / 変更時の回帰 / HITL（人手確認） |
| SHOULD（あると良い） | オンライン評価 / 選択・軌跡の評価 / 評価セットの拡充 |
| NICE（先進的） | シナリオの自動生成 / 評価役の検証 / マルチ評価 |
権限まわりは「権限の最小化」と「乱立の管理」に 6 つの打ち手で対応する、という整理でした。
| 観点 | 打ち手 |
|---|---|
| 過剰権限への対策 | ①固有IDを与える（共有禁止）②最小権限＋ユーザー代理（OBO）③境界をLLMに委ねない |
| 乱立への対策 | ④ユーザーとAgentを二重に記録 ⑤レジストリで期限を管理 ⑥高リスクは承認を挟む |
最後に「静かに使われなくなることを防ぐ」として、KGI/KPI 未設定・ユーザーシナリオ未設計・運用責任者の空白がエージェントを“サイレントに”形骸化させる、という注意で締められました。
3️⃣ 組織でAIプロダクトを作るには：AI Enabling Unit（estie）
不動産テックの estie 須藤さんからは、全社横断で AI プロダクト開発を推進する「AI Enabling Unit」の取り組みが共有されました。課題を個別に撃破するだけでは AI 導入が追いつかず、かといって「どんな基盤にすべきか」の具体像が掴みにくい——そこから生まれたのが AgentHub です。
きっかけは、週に 1 日だけ各自が興味のあることに取り組む「実験 Day」だったそうです。自社データ基盤に接続するツールを用途別に多数作り、Agent がプロンプトに従って適切なツールセットを選ぶ形にしたところ、「不動産データについて聞ける Agent」が生まれました。AgentHub は、プロダクトから直接 AI 機能を個別実装するのではなく、AI 機能の共通基盤／リポジトリとして位置づけられています。
開発専用機能の custom-agent も面白い工夫でした。リクエストにシステムプロンプトと使いたいツールリストを載せて送ると、AgentHub への実装なしに新しい Agent を試せます。手応えを掴んだら本番用として実装する、という流れです。ただし custom-agent のままでは品質担保や利用量観測が難しいため、「開発速度に振った機能と、運用の安定性に振った機能は切り分ける」という原則が示されました。
まとめでは、「AI なら何でもできそう」という認識が意外なほど現実と合わないため「AI で何をするのか」の共通認識が大事だという話と、AI 時代でも開発速度と運用安定性を分けるなどの従来の設計原則は活きる、という指摘が印象に残りました。
4️⃣ 正気を疑う技術 — bug のない vibe coding を目指して（Helpfeel）
Helpfeel の橋本さんのセッションは、「AI に実装させるだけでなく、AI に正気を疑わせる開発プロセス」という切り口でした。背景として、2025 年以降の AI 開発では「1 人が出す PR の数はあまり増えていないが、1 つの PR のサイズが大きくなった」ことが挙げられました。大きな差分を「ナレッジワーカーとしてレビューしてもらう」だけでは信じにくくなった、という問題意識です。
紹介されたのは、自作の 3 つの Agent Skill でした。
| Skill | 目的 | 使いどころ |
|---|---|---|
| codex-consultation | AI 同士に激しい仮説・反論・再検証をさせ、コード品質を上げ bug を減らす | コード品質を上げたい / bug をなくしたい |
| conversation-context-export / import | コードに残らない意思決定（やらないことと理由）を引き継ぐ | 人間と AI のやり取りを知りたい |
| sanity-review | 成果物だけでなくプロセスと判断理由を確認する | 最終コードを人間が正しく理解したい / AI がどういう観点でレビューしているかを知りたい |
とくに刺さったのが「重要なのは“やらないこととその理由”」という視点でした。やったこと自体はコードを読めば分かるし AI にも説明させられますが、「色々検討した結果こうなった」の中身——コードになっていない判断——こそレビューで見たい、という話です。conversation-context-export は Claude Code の /compact と相性が良く、長いセッションでも「やらないことと理由」を引き継げるそうです。
sanity-review のチェック項目は「概要欄がまともか」「概要欄と実装の比較」「実装の質」の 3 点で、PR 概要欄を宣言的に書く（確認項目が 3 つあるなら 3 つ明示する）ことで、後段の AI が疑いやすい材料を残す、という運用でした。環境は Claude Code（Opus）と Codex CLI（GPT5.5-high）を併用し、IME 辞書によく使うプロンプトを登録しておく、といった実践的な小技も共有されました。
💡 このセッションのスキル群（codex-consultation / conversation-context-export・import / sanity-review）は、自分たちのエージェント運用にもそのまま取り入れたいと感じた部分でした。「人間が理解できる状態」を完了条件に入れる、という考え方が肝です。
5️⃣ 【公募】AIエージェント構築事例 — 3 社（医療 SI を中心に）
公募セッションでは、3 名が 10 分ずつ登壇しました。発表タイトルは次のとおりです。
- ミスを「見落とさない」AI Agent 構築 — コード品質向上 Agent "D-Arc"（ダイキン工業／高木 詩織）
- 「誤読」「誤解」「誤爆」1 秒と戦う面談 AI エージェントの作り方（Algomatic／坂本 一樹）
- 医療 SI の現場で始めた Dify × AWS によるエージェント構築とデータ匿名化の学び（NEC ソリューションイノベータ／京仲 俊樹）
ここでは、メモを詳しく取った京仲さんの医療 SI 事例を中心に紹介します。医療現場は顧客情報・個人情報を含むため、外部 SaaS へそのまま投げられないという制約があります。その前提で「制約はそのままに、設計書作成作業を軽くできないか」という問いから、ヒアリングシートから設計書とテスト仕様書を自動生成するエージェントが作られました。
構成は、中核の Dify を AWS にセルフホスト。理由は、個人情報を含むためデータレジデンシーを確保したいこと、Dify はワークフローを視覚化でき第三者が後から追跡できること、AWS は公式の構成例や参考事例が豊富なこと、でした。
最大の学びは「匿名化の人手確認の重さ」だったそうです。最大のコストは「生成」ではなく「漏れていないかを人手で確かめる作業」でした。GiNZA の NER で <PERSON> や <PHONE> に置き換えても機械処理だけでは取りこぼしが必ず出ます。「○○病院の田中先生」のように職位・役割と結びついた文脈依存の PII が残り、検証対象が「出ていないこと」なのでチェックリスト化しにくい。個人情報は 1 文字の漏れが事故に直結するため「だいたい消えている」は許容されない、という話でした。
そこから「レビューの目的が変わった」という再定義が示されました。従来のレビューは「正しさ」のチェックでしたが、これからは「説明できること」のチェックになる。「漏れていないと第三者に説明できる」状態を作ることが重要で、そのためにワークフローが見えるローコード（Dify）が効く、という結論でした。ログ・権限管理・モデル切替が組み込まれており、規制要件に応えやすい土台になります。
6️⃣ チームで実践する AI-DLC：思考の軌跡を残すチェックポイント設計（Belong）
Belong の福井さんのセッションは、AWS の AI-DLC（AI-Driven Development Life Cycle） を実戦レベルに落とし込み、SDLC に独自のチェックポイントを足してチームのプロセスにした実践でした。背景課題は明快で、「AI を活用した開発では、知識や判断が個人の AI セッション内に閉じやすい」。わかる人は高速化できるが、そうでない人には結果しか見えず、チーム内の格差が広がります。
AI-DLC は Inception（Spec 定義・ユーザーストーリー・ユニット分割）／ Construction（論理設計・ドメインモデル・コード/テスト生成）／ Operation（CI/CD・IaC）の 3 段で、コアパターンは「AI が計画 → 人が承認 → AI が実装」。このセッションでは、その上に Checkpoint 設計を乗せていました。
Checkpoint の狙いは、「考えたが言語化されていない」部分を拾い上げることです。判断根拠の記録、暗黙仮定の明示化、コンテキストの記録、レビュー精度の向上、失敗（棄却案）の学習。これにより「Spec 定義の民主化」「素早い立ち上がり」「実装水準のボトムアップ」を目指す、と語られました。
設計を支える 2 つの原則も実践的でした。AI から引き出す Knowledge Elicitation（指示ではなく「質問」を投げ、Foundation Model の汎用知識を引き出す）と、AI に与える Context Engineering（自社固有のコンテキストを構造化して与える。LLM Wiki のようにサマリ・原データ・URL をリポジトリに保持する）です。さらに、AI-DLC のディレクトリ構造を拡張し、Flow（チケット単位の作業記録）と Stock（ユニット単位の長期知識）を分離して、チケット完了時に Flow から Stock へ知見を昇格させる、という運用が紹介されました。
適用は「迷ったら少ない方から」が原則でした。
| 規模 | チェックポイントの適用 |
|---|---|
| バグ修正・小タスク | CP なし（通常 PR フロー） |
| 1 人日規模 | CP-Spec + CP-Impl のみ（Design は実装過程で） |
| 大規模 | フル適用 |
導入してよかった点として、ゴール理解がリーダー層を超えてチーム全体に届き、タスクの見通しが向上したこと、Spec/Design 定義の水準が上がり起案者の層が広がったこと、Foundation Model が「もともと気づかなかった観点」を補完したことが挙げられました。一方で、複数リポジトリへの適用や既存巨大リポジトリの Spec 化、固有ドメイン（DWH 構築など）の Spec 定義には改善余地があり、まだ試行・改善サイクルの途中とのことでした。
7️⃣ AI Editor 開発の現場から学ぶ、プロダクト化の勘所（テックタッチ）
テックタッチの伊藤さんのセッションは、操作ガイドを AI で生成する「AI Editor」を題材に、エージェントの品質安定化を掘り下げる内容でした。出発点は「最初の壁は、AI に任せるほど出力が定まらないこと」。LLM 単体では、実在しない UI 要素 ID を参照する、前提条件が抜ける、条件分岐が成立しない、ステップ構成が毎回揺れる、といった問題が起きます。プロダクトに必要なのは、実務に耐える・再現性がある・検証できる・人が判断できる品質です。
転機になったのが TCD（Techtouch Contextual Database） で、顧客課題に対してテックタッチをどう使って解決してきたかの知見を、課題・目的・解決策・誘導プロセス・操作要求・成功パターンとしてモデリングしたものでした。「生成 AI で変わったのは、ドメインモデリングの重要性ではなく、モデリングされた知識の使われ方」という指摘が核心でした。
そして、コンテキストは全部入れると破綻する（遅い・高い・安定しない）ため、情報の配置設計が重要だとして、4 分類が示されました。
「どの情報を LLM に読ませるかと同じくらい、どの情報を読ませないかが重要」という言葉が印象的でした。Agent は処理ステップではなくデータの責務で分割し（知識検索／方針決定／構造設計／データ変換／検証・修正）、安定出力の鍵は validator——AI の出力を信じるのではなく、AI の出力を検査できる構造にする、という設計思想でした。
さらに「ユーザーが求めるのは精度だけではない」として、なぜこの構成なのか・どこを直せばよいか・自分で制御できるか、という納得感・透明性・制御可能性を重視。Step Structure View（骨格を確認・修正）と User Story View（AI がなぜその構成にしたかを物語形式で表示）という 2 つのプレビュー体験で、「AI の思考をユーザーが理解・修正できるインターフェース」を作っていました。締めの「Agent 開発とは、AI にプロンプトを書く仕事ではなく、AI が業務を扱えるようにドメインを設計する仕事」という一文が、この日の通奏低音をよく表していました。
8️⃣ 企業で使えるAIエージェントとは — AGENTIC STAR から考える「自律」（ソフトバンク）
最後は、ソフトバンクの中山さんによる AGENTIC STAR のセッションでした。ソフトバンクは AI データセンター、ソブリン AI/クラウド、国産 LLM（Sarashina）、生成 AI・AI エージェント（AGENTIC STAR / dailyAI など）を次世代社会インフラとして位置づけており、生成 AI の活用は 2022–23 年のチャット LLM/RAG、2024 年の Tool-Using AI を経て、2025 年以降は自律実行 AI へ広がっている、という時系列が示されました。
ここでも軸は運用でした。「何でもできるが誰も監査できていない」ことが企業導入の最大の障壁で、セッションでは AI PoC の 88% が本番展開に進まないというデータも紹介されました。PoC で終わらせないために越えるべき壁は 5 つで、「どれか 1 つではなく、5 つ全てを同時に設計する必要がある」と強調されました。
各壁の課題と対策は、次のように整理されていました。
| 壁 | 主な課題 | 主な対策 |
|---|---|---|
| セキュリティ | LLM へのデータ送出 / 権限付与 / 監査ログ欠如 | LLM プロキシ、マスキング・遮断、ツール許可リスト（MCP）、通信ログ取得。ガードレールは「お願い」でしかなく、外側で物理的にブロック |
| システム連携 | ネットワークの壁 / 認証・権限の壁 / API と自然言語のギャップ | VPC 内構築・IP 制限 SaaS、ユーザー代理（MCP OAuth）、既存 API を MCP でラップしてまず繋ぐ |
| コスト | 自己ループ・反省・再試行が全額計上 | サーキットブレーカー、SLM 活用、プロンプト圧縮・キャッシュ・要約。タスク単位の可視化と人件費換算 |
| 運用体制 | 監視主体の不在 / 静かな失敗 / 改善ループ欠如 | AgentOps を専任で定義、HITL（防止）と eval（検知）の二重化、フィードバックを改善へ |
| スケール | 本番に耐えない実装 / 部門ごとの期待差 / 毎回ゼロから | 本番グレード基準、テンプレート化、承認フロー標準化、フレームワーク・Lint・Agent.md 整備 |
AGENTIC STAR 自体は、専用仮想環境・ガバナンス機能・シームレスな MCP 連携・長期/短期記憶を備えるエンタープライズ向け自律汎用型エージェントで、Marketplace Edition では開発者が「エージェント開発そのもの」に専念できることを狙っている、と紹介されました。自律スコアとして GAIA ベンチマーク 88.5%、SWE-bench Verified 83.8% という数値も示されました。締めの「自律と暴走は紙一重。ルールや境界の中で動き始めて初めて自律と呼べる」という言葉が、1 日全体を要約しているようでした。
🏁 1 日を通しての考察
8 セッションを並べると、業種や立場を超えていくつかの共通項が浮かびました。
- 🔁 エージェントは“拡張前提”で設計する。フローを柔軟に差し替えたり、停止させたりできることが重要で、機能はエージェントの「ツール」として実装する。
- 🧩 最適解は時代によって変わる。だから入れ替えやすくしておく。ルールベースと LLM ベースの使い分けが現実的でした。
- ❓ AI に“質問”して汎用知識を引き出す。指示するだけでなく、Foundation Model から引き出す姿勢（Knowledge Elicitation）が複数セッションで共通していました。
- 🔍 品質担保は複数モデルの相互チェック。Claude や Codex など複数の AI に相互レビューさせる運用が、Helpfeel・全体考察の両方で出てきました。
- 🛡️ 重心は「生成」から「権限・監査」へ。エージェントがプロダクトを生成するのは当たり前になり、時代はエージェントの権限設計や監査方法に注力している、という総括に行き着きました。
この日いちばん持ち帰りたいと感じたのは、レビューの再定義です。医療 SI のセッションが示したとおり、レビューの目的が「正しさ」から「説明できること」へ移っている。AI が大量に生成できる時代に人間が担うのは、「漏れていない」「なぜこうしたか」を第三者に説明できる状態を設計することなのだ、という一貫したメッセージでした。
💡 AI ネイティブ時代へのヒント
最後に、この日のヒントとして特に残ったものを 1 つ挙げておきます。ダッシュボードのような成果物自体を AI エージェントに作らせ、そのうえでエージェントに自律的に動かせる——「人が作って AI が使う」だけでなく「AI が作って AI が回す」段階を、運用と統制の設計とセットで考える、という方向です。作れることが前提になった先で問われるのは、やはり「どう運用し、どう説明責任を果たすか」でした。
参考 📚
- AI Engineering Summit Tokyo 2026 Summer（公式サイト） — カンファレンス概要・タイムテーブル。
- 本レポートは 2026/06/08（1 日目）に聴講した 8 セッションの個人メモに基づきます。各セッションで紹介された数値・事例は、登壇内容として記録したものです。