グラレコ

はじめに

Developer Summit 2026 Summer（デブサミ2026夏）は、翔泳社が主催する開発者向けカンファレンスです。2026年7月16日開催の1日目に参加し、6つのセッションを聴講してきました。今年の空気を一言でまとめると、「AIで開発が速くなった。その先で、人間とプロセスをどう組み替えるか」に各社の関心が集中していた、という印象です。

この記事では、聴講した6セッションの内容を、講演の流れに沿ってできるだけ細かく整理します。扱うテーマは、AI駆動開発の副作用、LLM組み込みのプラクティス、AIが使うデータ基盤、toB プロダクトの二重ループ開発、ローコード×AI、そしてエンジニアリング組織論です。分野はバラバラなのに、終わってみると複数の登壇者が独立に同じ結論へ到達していて、そこがこの日いちばんの読みどころでした。長い記事ですが、最後の「共通テーマ」まで読んでいただけると、2026年夏時点の AI×開発の現在地が立体的につかめると思います。

💡 本記事は筆者個人の聴講メモに基づくレポートです。講演の全内容を網羅・正確に再現するものではなく、講演中の数値はスライドからのメモで独自検証はしていません。文責はすべて筆者にあります。

1日目の全体像 🗓️

聴講したセッションのタイムテーブルです。

時間	セッション	登壇者
13:25–13:55	なぜAI活用が進むほど、エンジニアは考えなくなるのか？	伊達拓郎氏（NECソリューションイノベータ）
14:10–14:40	LLMやAIエージェントをソフトウェアに組み込むプラクティス	澁井雄介氏（Snowflake）
14:55–15:25	「人が使うDB」から「AIが使うDB」へ。ClickHouseで実現する超高速データ基盤	松本幹氏（ClickHouse）
16:10–16:40	「早く出す」より「事業に効く」―― AI時代の二重ループ開発と「変化の設計者」	稲垣剛之氏（ラクス）
16:55–17:15	生成AI×ローコードで実現するコンテキスト指向の次世代アプリケーション開発	阿島哲夫氏（OutSystemsジャパン）
17:30–18:00	開発は速く安くなる。開発量は増える。ボトルネックは移動する。	黒田樹氏（インディードリクルートテクノロジーズ）

先にネタバレ気味に言ってしまうと、この6本は「①生成は確率的でよい、受け止めは決定論で」「②人間に判断を残す」「③コンテキストが成否を分ける」という3つのテーマで、きれいにつながっていました。それぞれのセッションを見ていきます。

セッション1：なぜAI活用が進むほど、エンジニアは考えなくなるのか？ 🤔

（伊達拓郎氏／NECソリューションイノベータ）

AIが設計・実装・検証を担う開発パイプラインを実プロジェクトで構築・運用した経験から、「便利さの裏で人間が考えなくなる構造」に向き合ったセッションです。伊達氏は2004年入社後、アプリケーション開発・サービス企画を経て、現在は AI ネイティブな開発プロセスの検証・適用推進を担当されています。冒頭は「AIで業務がラクになったと感じている人」「AIによって手放した仕事（作業）、ありませんか？」という会場への問いかけから。AIの進化が加速するなかで感じる漠然とした不安に対して、自身の経験から「気づきと解決のきっかけ」を話す、という構成でした。

構築したAI駆動開発パイプライン

まず前提となるパイプラインです。RFP・要件一覧を入力に、SE が GitHub へ Pull Request を出すと、GitHub Actions と Claude Code が Skills 単位で「要件解析 → 設計 → 実装 → 単体テスト → E2Eテスト」を自動実行し、要件定義書・設計書・ソースコード・テスト結果を出力してデプロイまで進みます。

実装フローの中身も具体的でした。テスト先行（RED→GREEN）で書き、lint・test・build の全PASSを確認し、コードレビューを経てコミット→push まで、Claude Code のスキル群で構成されています。CI では Lint・ビルド・テストに加えて脆弱性監査まで実施し、E2E テストは Playwright。開発品質と速度の同時向上を実現し、日々の開発は確かに回っていたそうです。ところが、その便利さの裏で、現場から3つの違和感が顔を出し始めます。

3つの違和感（お客様・部下・同期の声)

お客様からの「何から確認すれば？読み方を教えて」——伝わるの違和感
部下からの「AIから、できないと返ってきました」——判断の違和感
同期からの「この“確認だけ”の作業、誰が楽しいの？」——やりがいの違和感

どれも最初は小さな違和感で、この3つに1つずつ向き合うことにした、という進め方です。

違和感1［伝わる］：正確なのに、なぜ「伝わらない」のか

AI駆動開発では「顧客との対話減少」と「成果物のギャップ」が同時に起きます。従来は要件定義から製造・テストまで、各工程の対話による共創があり、そこから納得感・安心感、プロセスへの理解、お客様目線の設計書が生まれていました。一気通貫の自動化では、AIが出力する情報（クラス名・メソッド名・ソース根拠・整合性）と、お客様が見たい情報（業務サマリー・業務フロー・画面イメージ）がズレます。

技術的には完璧——クラス名もメソッド名もソース根拠も揃い、自信を持って渡した仕様書に対して、お客様の反応は「どこを見ればいいのか、わからない」。伝わらない理由は3つに分解されました。

伝わらない理由	中身
関心領域のミスマッチ	お客様が見たいのは自社の業務であって、実装の内部構造ではない
判断基準の不在	お客様が判断したいのは「業務が成立するか」
変数名の壁	`sys_val_dt` ではなく、自分たちの言葉で読みたい

つまり、正確さの問題ではなく「読む人」が違っていた。同じ仕様書でも、SE は実装の正確さを見て、お客様は業務が正しく反映されているかを見る。読者が変われば必要な情報は違う——「正確さは、伝わることを保証しない」という言葉が刺さりました。対策はシンプルで、人が「誰に向けて書くか」を決め、AIが読者別に書き分けること。人手なら冗長すぎてやれない作業も、AIなら一度で済みます。

違和感2［判断］：AIの「できない」は本当に終わりなのか

AIが「×（不可能）」と返すと、そこで手が止まり、それ以上考えなくなっていた——という自己観察が2つ目です。例として挙がったのはソースからのリバースで、AIが「無理」と判定した瞬間に探索が終わり、工夫の余地ごと消えていた。「深く考える」習慣が抜けていたわけです。

そこで、AIの「×」を起点に変える3つの視点が示されました。

前提を疑う: 「本当に無理？」と、制約・前提・プロンプトを変えてみる
別の切り口を探る: 一度の回答で満足せず、別の角度から問い直す
探索と判断は人が担う: 最終決定のハンドルをAIに明け渡さない

実際、「できない」の多くは人の問いと情報で突破できたそうです。「ソースのみでは業務分析・ユーザ設計が難しい」→ 業務・ユーザ視点の情報を人が補って問い直す。「Skills でも期待するアウトプットが出ない」→ 何が足りないかを人が問いを立てて補う。「同じプロンプトでも出力にばらつきが出る」→ 個別の観点・前提を人が加えて絞り込む。AIは結果は出しますが「なぜ・どうやって」は見えません。だから人がゴールと背景を握り、次の指示を出す。結果について考えることは手放してはいけない、という整理です。

違和感3［やりがい］：効率化したのに、なぜ「心が動かない」のか

役割分担としては、AIが高速にアウトプット（設計書・ソースコード・テスト類）を出し、人は要件ヒアリング・業務仕様FIX・テスト結果やカバレッジ確認などのレビューと受入テストを担う形でした。そこに刺さったのが、AI駆動開発の検討会での同期の一言、「AIのアウトプットを“確認するだけ”の作業って、誰が楽しいん？」です。

効率を追って「考える余白」まで奪っていた。確認だけが残り、心が動かなくなっていた——という反省から、役割設計の転換が語られました。AI=作業／人=確認、から、人に判断・探索・意思決定を残す設計へ。具体的には「探索する喜び」を設計する3つの方針です。

問いは人が投げる: AIに骨組みを作らせて人が直す、を逆転。人が「問い」を立て、AIが支える
探索を楽しむ: 効率第一から脱却し、試行錯誤やアイデアを練る過程に人を置く。創造性を取り戻す
責任が手応えになる: 判断には責任が伴い、それが自己効力感とやりがいを生む

効率のための分担から、「やりがい」のための設計へ。判断する仕事が戻れば、やりがいも戻る、というメッセージでした。

3つの違和感は、一つの問いだった

まとめで、3つの違和感の正体は「自分は、深く考えるのをやめていないか」という一つの問いに集約されました。お客様に対しては伝わらなくなり、部下の前では探索しなくなり、同期から見れば作業になっていった。三つは別々の問題ではなく、全部「深く考える」のをやめた一人の自分だった、と。だからこそ、全自動の流れに人の「ゲート」を設計後とデプロイ前の2箇所に設けたそうです。ゲートの正体は「深く考える場」です。

この図のポイントは、ゲートが単なる品質チェックポイントではなく「人が深く考えるための場」として設計されている点です。AIが担う「正確さ」＋人が担う「深く考えること」＝AI時代の分業。エンジニアはコードを書く「作業者」から、技術・データを価値へ翻訳し意思決定する「アーキテクト」へ。人間ならではの「深い検証力」と「問題設定力」が問われる、という締めくくりでした。

技術実装が自動化されるほど、「人と人の間にある仕事」——何を作るかの合意、お客様の真意を引き出す対話、成果物にお客様が納得する瞬間、組織間の優先順位調整——がくっきり見えてくる。AIに仕事が奪われるのではなく、伝える・結果を考えるという仕事はずっとそこにあって、技術の作業に隠れて見えなかっただけ。この視点の反転が、このセッションのいちばんの持ち帰りだと思います。

セッション2：LLMやAIエージェントをソフトウェアに組み込むプラクティス 🧰

（澁井雄介氏／Snowflake）

Snowflake の Senior AI/ML Architect / Field CTO で、MLOps コミュニティを運営する澁井氏のセッションです。『機械学習システムデザインパターン』などの著者で、新刊『LLM・AIエージェントシステムベストプラクティス』（翔泳社）を2026年8月20日に発売予定とのこと。キーメッセージは「今の変化に対する新しいメソドロジーを提唱するのは同時代人の特権である」。30分に詰め込まれた密度がすごいセッションでした。

方法論はコミュニケーションツールである

前半の主張は、方法論＝共通言語だという話です。「DIパターンで作って」の一言で、人にもAIにも意図が伝わる。これが方法論の価値です。LLM時代のSOLID原則の読み替えが例として示されました。

SOLID	LLM時代の読み替え
単一責務	1プロンプト1責務
開放閉鎖	モデルの変化に開き、契約に閉じる
リスコフ置換	代替可能性（eval という契約が緑か）
インターフェース分離	ツール面を最小権限に
依存性逆転	eval という契約に依存する

問題は、新しい技術にはまだ名前と共通認識がないことです。役割・Few shot・ハイブリッド検索・Eval first……と、毎回長文で説明するはめになる。さらに深刻なのは、コーディングエージェントのおかげで誰でも相応規模の開発を依頼できるようになった結果、共通認識となる実装方針・アーキテクチャが不在のまま、メンタルモデルの異なる一貫性のないコードが「高い品質で」量産されることです。共通認識の不在は運用負債になる、という指摘でした。

方法論の方法論：信頼をエンジニアリングする

いま起きているのは、人×コーディングエージェントの大量並列開発です。高速開発や高度な分析という楽しい面の裏で、セキュリティホール、無制限なトークン利用、重複、シャドウAI、低品質なコードが発生している。だからコーディングエージェント時代のエンジニアの重要な仕事の一つは、「誰もが信頼できるソフトウェアを作る仕組みをエンジニアリングすること」だと定義されました。

整理として、実装 = 機能（要件・仕様が決める）+ 設計（方法論が決める）。Agentic Application にはまだ方法論の共通認識がありません。そこには「ふたつの不透明性」があります。(1) LLM/AIエージェントをソフトウェアに組み込む方法論そのもの、(2) コーディングエージェントに作られた具体的な実装と設計。機能は Eval で検証できても、非機能・設計・コストはブラックボックスになりがちで、「便利 > 制御」の状態では各自がブラックボックスを生み続けます。

答えは「作り方の作り方を作る」こと。Harness・Eval・Loop を設計し、AGENT.md を通じてコーディングエージェントに方法論（SOLID・TDD/CI/CD・Modular Monolith 等）を信頼して実行させる。制御のために利便性を犠牲にするのではなく、利便性を保ったまま信頼を作るのがエンジニアリングの醍醐味だ、という前向きな整理が印象的でした。

不確実性に対処する鉄則：局所化して制限し、評価する

具体的な設計原則として、次の3つが紹介されました。

確率の封じ込め: LLM利用は指定モジュールのみに許可し、ルールベースで制約。入出力はスキーマ・ビルダー・ゲートウェイで管理する
最小エージェンシーの原則: 課題解決におけるLLM/エージェントの役割は、最小化するほど良い
決定論ファースト、LLMロングテール: エントリーポイントは決定論的に解き、余剰の複雑性だけをLLMで対処する

この図は「最小エージェンシー」の階段です。左に寄せられるほど良く、右へ行くのは必要なときだけ。商品推薦の例が分かりやすくて、当初は稀な商品の推薦をLLMでカバーし、ログが溜まるにつれてルールベース・機械学習へ移行、最終的にLLM推薦は新規・エッジケースの補助役に徹底させたそうです。これを「プロトタイピングの逆転」と呼んでいました。LLMで対処した記録を元に、決定論的に解ける領域を後から広げていく。LLMを恒久的な主役ではなく、決定論化までのつなぎとして使う発想です。

Looped Harness Engineering（Compound Engineering）

「各作業が後続の作業を容易にする」ように開発する、という思想も紹介されました。チームでループしながら、実装と Eval を通して Harness（ハーネス）を育て、Master Harness をチーム共通のソフトウェア資産にする考え方です。

このループの目標関数は「信頼可能な変更量」です。人間のレビューが最も高コストで、次にLLMを含めた全件テスト。リリースの頻度・失敗率を最適化対象に、Harness と Eval をループで改善していきます。指標例として、リリース（頻度・リードタイム・変更失敗率）、テスト（実行数 vs 枝刈り数・人間レビュー数・レビュー指摘数）、決定論的ルール（可逆 vs 不可逆領域・意思決定の移譲量・経済的スループット）が挙げられました。ハーネスに設計・開発可能な領域を移譲するほどコーディングエージェントの生産量が増え、スループットが最大化する。「便利 > 制御」から「便利 ← 制御」への転換です。

プラクティス集：4つの構成要素と具体的なハーネス例

Agentic Application の構成要素を Interface／Tool・Gateway／Context・Memory／Eval の4つに分け、各プラクティスを「プラクティス本体 → コーディングエージェントに実践させる作り方 → 制御するハーネス」の3点セットで整備する、という枠組みで、大量の具体例が投下されました。特に印象に残ったものを分野別に抜粋します。

構造化出力とスキーマ駆動I/O。LLM出力を Pydantic / JSON Schema の型に強制し、検証失敗なら再生成。これがパイプライン・ツール連携・評価・ログすべての土台になります。ただしスキーマが複雑すぎると生成失敗率が上がるので、再試行とフォールバック設計が必須。ハーネス例が実践的でした——構造化出力は確率的世界から決定論へのボーダーなので Eval 必須／Schema×Prompt×Model×Eval の「4組契約」で管理／スキーマの第一読者は人間ではなくLLM／LLMスキーマとドメインモデルを分離して変換層を持つ／Enum・Literal で制約／抽出系フィールドは Optional＋根拠を原文で取得／Reasoning フィールドを先に・結論は最後／ネストは上限3／エラーメッセージは What・Why・How to fix。

コンテキストとメモリ設計。文脈の蓄積→汚染・ドリフト検知→健全な地点へ復帰（チェックポイント保存、ロールバック、有効入力のみ再送）という流れで、長時間・安定してエージェントを走らせ、暴走や崩壊から回復させる中核です。データの形態・用途に応じた保存・管理・検索方法を文書化する「データデザインカタログ」（事実・設定値は構造化データ、出来事はイベントログ、知識はチャンク＋ハイブリッド検索、手順は検索とGit）も紹介されました。ハーネス例は、メモリへの書き込みは審査制（Evalを通して承認・昇格）／観測と推論の分離／Immutable（イベントソーシング）／生データの破壊的圧縮禁止（要約は Materialized View として持つ）／全レコードに TTL と減衰率／忘却は機能（定期GC）。「忘却は機能」という言い切りが良かったです。

ツールチェーンとゲートウェイ。LLMは呼び出す関数の連鎖と順序だけを指定し、システムが内部で一括実行して最終結果のみ返す。逐次のツール往復は中間結果で文脈を汚し、トークンとレイテンシを浪費するからです。全ツール呼び出しはゲートウェイ（MCP）を制御点に、認可・スキーマ検証・最小権限・監査を一元化します。ハーネス例——プレーン分離（中間生成物はLLMを経由しない）／ツールセット×チェーン仕様×プロンプト×モデル×Eval の「5組契約」／プランは事前コンパイルで型検査・権限精査／各ツールに Read・Write-reversible・Write-irreversible・External-send の副作用クラスを必須宣言／読みは対話許可・書きは宣言的プラン強制／ツール直呼び出しは Lint で禁止（Single Tool Gateway）／実行台帳で管理記録。副作用クラスの必須宣言は、明日から自分のツール定義に入れたくなりました。

AIエージェントのテストと評価。品質を勘ではなく数値で管理します。ゴールデンデータセットにルーブリック・LLM自動採点でオフライン評価を自動化し、合否閾値を CI の品質ゲートに。本番はカナリア・A/B で実挙動を計測し、トレースをデータセットへ還元する Eval 駆動開発です。注意点も具体的で、出力は値でなく「分布」のため単体テスト1例の合格では品質を保証できない、LLM-as-Judge 自体のバイアス・不安定さ、データセットの陳腐化・リーク、評価コストの増大。テスト選定には Predictive Test Selection の応用（変更に対して確率的に失敗しそうなテストを優先実行、本番リリース前は全件実行）が紹介されました。ハーネス例は、ゼロ変更≠ゼロリスク（CRONで定点観測しドリフト検出）／判定関数の型宣言（決定論的・閾値付き統計・LLM Judge のいずれかを宣言）／LLM Judge は免許制にしてロックし Judge Drift を防ぐ、など。

アンチパターンと非機能の落とし穴

アンチパターンは2つ紹介されました。

アンチパターン	症状	処方
神プロンプト（LLMを万能の黒箱とみなし、巨大な自由形式プロンプトを1回投げて出力をそのまま信じる）	言い回しが変わった日にパースが壊れる／品質劣化に誰も気づかない／どの工程で失敗したか特定不能／プロンプトインジェクションに無防備	スキーマで型を強制→検証可能な多段に分割→厳密処理はツールへ委譲→提供前に自動品質ゲート
Local LLM Function（LLM APIを「必ず即時成功し、無料でログ不要で状態を持たないローカル関数」のように扱う）	プロバイダ遅延が即「全断」に連鎖／コスト爆発とレート制限の嵐／エージェント暴走／ログがなく障害をデバッグ不能	LLMクライアント共通化・ゲートウェイで流量/優先制御・ログ記録・キャッシュ/バッチ・エージェントは反復コスト上限で境界設計

非機能の落とし穴は「熟練の反射が新しい前提と衝突する」という切り口で2つ。決定論バイアス（品質・テスト軸）は、「テストが通った=正しい」がLLMには通用しない話です。出力は分布であり、1例の合格は何も保証しない。緑のCIが誤った安心を与える。処方は、例ではなく分布を検証し、N回サンプリング＋基準付き自動判定を行うこと。信頼境界の取り違え（セキュリティ軸）は、ユーザー入力は警戒するのに、LLM出力（生成SQL・コード・ツール引数）やRAGの内容を自分のコードのように信頼してしまう問題。処方は信頼境界をLLMの外側へ引き直し、非信頼として検証・サンドボックス・最小権限・人間承認を挟むことです。共通構造として、新パターンの習得（足し算）だけでなく、旧反射の棄却・再較正（引き算）が要る、というまとめが腑に落ちました。

変化とメソドロジー

最後は冒頭のキーメッセージに戻ります。プラクティス集を Harness・Eval として整備し、コーディングエージェントが検索して設計指針・選定基準を得て AGENT.md に反映する「コーディングエージェントのための方法論」へ。新技術が「当たり前」を壊し、失敗が集中し、局所化して評価するうちにメソドロジーが生まれ、次の変化が新しい前線を開く——このサイクルの真っ只中にいる我々には、新しいメソドロジーを提唱する特権がある、という締めでした。書籍が出たら読もうと思います。

セッション3：「人が使うDB」から「AIが使うDB」へ 🗄️

（松本幹氏／ClickHouse）

ビッグデータ領域15年以上、Elastic・Workato・ClickHouse といずれも日本市場の立ち上げから参画してきた、ClickHouse の日本人社員第一号だという松本氏のセッションです。「社内のデータ解析にAIを使うケースが増えているが、AIの回答の質は渡されるデータの質と量で決まる。データ基盤の役割は『保存』から『AIを賢くする土台』へ進化した」という導入から始まりました。

AIが変える3つのデータ基盤への要求

AIはデータ基盤への要求を3つの面で変えます。

分析インターフェースの会話化: Text-to-SQL により動的にクエリが生成され、アクセスパターンが動的・予測不能に。静的に最適化された専用DBでは対応できない
アプリのエージェント化: AIエージェントが内部で数十〜数百のクエリを並列実行。「誰が・いつ・どれくらいの頻度で」が予測不能になり、事前設計の前提が崩れる
オブザーバビリティのAI駆動化: AIが能動的に異常を検知・収集・要約する AI SRE へ。AIが自律的にデータを探索するため、静的ダッシュボード前提の基盤では機能しない

データドリブンからワークフロードリブンへ

この変化は「データドリブン」から「ワークフロードリブン」への移行として整理されました。

この図のポイントは、単に量が増えるだけでなく、アクセスの主体（人→人＋エージェント）、経路（個別ツール→MCP横断）、パターン（計画的→動的・並列）が全部変わる点です。そして既存DBの3カテゴリでは、この要求に追いつけないという課題設定が示されました。

カテゴリ	得意	AI時代の弱点
リレーショナルDB（MySQL/PostgreSQL/Oracle）	トランザクション処理	データ量が増えるとクエリ性能が急激に低下
データウェアハウス（BigQuery/Snowflake/Databricks）	大規模バッチ分析・定期レポート	準リアルタイムがベースで、大規模同時アクセスが不得意
NoSQL（MongoDB/DynamoDB）	高速 Key-Value・スケーラビリティ	複雑な集計クエリが不得意で汎用性に欠ける

スピード・スケール・コスト、この3つを同時に満たすDBが存在しなかった、というのが ClickHouse の立ち位置の説明です。

ClickHouse とは：なぜ速いのか

ClickHouse はオープンソースのカラム型 OLAP データベースで、PBスケールでもミリ秒応答、数十倍のデータ圧縮率が売りです。歴史は2009年のプロトタイプに始まり、2016年オープンソース化、2021年 ClickHouse Inc. 設立、2022年 ClickHouse Cloud、2024年 AWS 東京リージョン、2025年 GCP 東京リージョンと展開してきました。DB-Engines の分析OSSデータベースランキング1位、GitHub スター48,400以上、Cloud 利用企業4,000社以上（直近3ヶ月で1,000件増。Anthropic・Netflix・Tesla・Meta・Shopify 等）という規模感です。

速さの理由は「リソースを効率的に使うための徹底的なチューニング」として4点に整理されました。

カラム型ストレージ: 列単位で保持して超効率的に圧縮。クエリに必要な列だけ読み込み、I/Oを劇的に削減。オブジェクトストレージ利用でコストメリットも
INSERT と SELECT が競合しない設計: INSERT はイミュータブルな Part を作るだけ、SELECT は必要な Part を読むだけで、ロック競合なしに並行処理。Part はバックグラウンドのマージプロセス（MergeTree）で定期的に統合・最適化
マルチスレッド×分散並列スキャン: クエリをCPUコアに分散し、全コアが同時にデータを処理。共通オブジェクトストレージにより全ノードが並列で同一データを参照
SIMD ベクトル化クエリと JIT コンパイル: 1クロックで複数データを同時処理してCPUを最大限活用し、CPU専用ネイティブコードへコンパイルして高速化

ClickHouse Cloud はコンピュートとストレージを分離したクラウドネイティブ構成で、ワークロードに応じた即時スケール、マルチゾーンの高可用性、Scale-to-Zero クエリエンジンによるコスト最適化も備えます。講演スライドのベンチマークでは、ClickHouse 比で Databricks 23倍・Snowflake 32倍・Redshift 57倍・BigQuery 101倍という数字が示されていました（ベンダー発表値なので、鵜呑みにせず傾向として受け取るのがよさそうです）。

Agentic Data Stack：次世代データスタック

ClickHouse を中心とした統合ソリューションが「Agentic Data Stack」です。構成する OSS 群のラインナップが具体的でした——ClickHouse（高速カラム指向 OLAP、★48.4K）、LibreChat（AIチャットプラットフォーム、★40.1K）、Langfuse（LLMオブザーバビリティ、★30.3K）、HyperDX（オブザーバビリティ、★9.6K）、PeerDB（データ同期・CDC、★3.1K）、chDB（インメモリ ClickHouse、★2.7K）。

スタック構成は、UI層に ClickHouse Agent（Agentic AI 分析）・ClickStack（オブザーバビリティ）・Langfuse、DB層に ClickHouse ⇄ CDC リアルタイム同期 ⇄ Postgres（基幹データ・トランザクション）、データ連携層に ClickPipes とデータレイク・オープンテーブルフォーマットの直接参照、そして LLM（Anthropic・OpenAI 等）とは直接連携する形です。個別のコンポーネントも紹介されました。

ClickPipes: マネージドデータ統合パイプライン。UIで設定でき、継続的な取り込みがデータ量に応じてリニアにスケール。ストリーミング（Kafka/Kinesis/PubSub 等）、オブジェクトストレージ（S3/GCS 等）、RDB との CDC（Aurora/RDS/PostgreSQL/MySQL/Supabase 等）に対応
Managed Postgres by ClickHouse: ローカル NVMe 上のエンタープライズグレード Postgres（OLTP が2〜10倍高速）と ClickHouse のネイティブ統合（Native CDC で分析クエリをオフロードし、分析は100倍高速）。アプリからは OLTP と OLAP が一つのエンドポイントで透過的に使える
ClickHouse Agent: 会話形式でのデータ利活用。格納データを自然言語で分析でき、グラフィカルな可視化に加えエージェントや SKILL の作成にも対応。ネイティブ統合により、ユーザーの閲覧権限の範囲でのみデータにアクセスし、DBには MCP で接続
Langfuse: LLMオブザーバビリティ。API利用コスト・応答時間・会話履歴の一元管理、プロンプトのバージョン管理と評価、テストデータセットによる回帰テストで、エージェントを監視しガードレールの土台を築く

ClickStack：AI SRE を実現するオブザーバビリティ

ClickStack は、ClickHouse に格納した OpenTelemetry データをダッシュボードで可視化し、高圧縮ストレージで全量ログを低コストに長期保存する仕組みです。面白かったのは AI Notebooks のデモの話で、「VISA決済エラーの原因を調査して」と依頼すると、AIがログ・トレースのスキーマ確認 → 直近24時間のエラーログ検索 → サービスコールチェーンの把握 → 発生頻度の時系列確認 → トレースのウォーターフォール取得、と自律的に調査を進め、根本原因分析レポート（原因は payment サービス内の VISA 専用キャッシュの容量上限到達、発生タイムライン付き）まで出力するそうです。さらに「この問題をモニタリングするダッシュボードを作成して」で、ダッシュボード作成から再発検知アラートの設定まで会話だけで完了する。オブザーバビリティが「見る場所」から「AIが調査する場所」へ変わる感覚がありました。

導入事例と、ClickHouse 社内の「AIネイティブなデータ基盤」

導入事例の数字も強烈でした。

事例	内容（講演スライドより）
Netflix	4万以上のマイクロサービスから生成されるログを集計。5PB/日・1,250万/秒のインジェスト、500〜1,000 QPS をミリ秒処理、クエリ最適化で処理性能4.3倍
ebay	Druid から移行したイベントデータ基盤。10億件+/分のインジェスト、30倍圧縮、90%のコスト削減
Anthropic	オブザーバビリティおよびモデル開発時の分析基盤。PB+/日のインジェスト、Claude 4 の開発に利用。「Claude が ClickHouse を選択」というフレーズも

ClickHouse 社内でも「AIネイティブなデータ基盤」を実践しています。BIツールから AIチャットUIへシフトし、40以上のデータソースを集約した AI Native DWH（14兆行+・10PB+）を自社で構築・運用。社員の50%以上が月間アクティブユーザーで、Langfuse で継続的に精度改善しているそうです。アーキテクチャは、Airflow（オーケストレーション・取り込み）→ S3 → ClickHouse、変換は dbt（dbt elementary でデータ品質のオブザーバビリティ）、可視化は Superset、対話UIは LibreChat、AIオブザーバビリティは Langfuse という構成。そして「01 質問 → 02 構築（ソース不足なら DWH に組み込む）→ 03 パッケージ（データ辞書・結合関係・ビジネスコンテキストが SKILL として形になる）→ 04 観測（Langfuse が実行内容を記録）→ 05 改善」のループを回すことで、誰が質問しても信頼できる回答が得られる状態を目指している、と。ベンダーが自社製品のドッグフーディングをここまで具体的に見せてくれると、説得力が違います。

まとめは3点でした。量・質・鮮度・多様性のあるデータがAIの知能の上限を決める（保存から知能への進化）。サイロ化されたデータはAIのワークフローを止め、統合されたデータ基盤がAIの思考を解放する。スピード・スケール・コストのすべてを備えた ClickHouse が、AIの知能を最大限に引き出す。

セッション4：「早く出す」より「事業に効く」 🔁

（稲垣剛之氏／ラクス）

楽楽精算などを展開するラクスの稲垣氏による、toB プロダクトのプロセス設計論です。稲垣氏は SIer（ガチガチのウォーターフォール）→ ISP系 → ベンチャー → SaaS と、「作る側」と「決める側」を行き来してきたキャリアで、2000年代初期には XP の実践経験もあるそうです。だからこそ語れるプロセス設計のリアル、という前置きに納得感がありました。

前提：ラクスのプロダクトと「協働型AI」

ラクスは楽楽精算（成熟期・ARR207億円）、楽楽明細（成長期・ARR130億円）、楽楽電子保存、楽楽債権管理（探索期）などを展開し、プロダクトごとに開発組織・リリース頻度（3ヶ月/1ヶ月/より早く）・歴史・売上規模が異なります。クロスセルできるプロダクト間連携＝統合型ベストオブブリード戦略です。

AIに対する考え方は「協働型AI」——人間・ルールベース・AIが役割分担して業務を完遂させる、というものです。経費精算の例では、証憑登録・伝票作成はAI（読み取り・推論・過去申請参照）、電帳法適合の格納や承認ルート判定はルールベース、承認・確認は人間が担い、段階的に人間の業務をAIが自動化していきます。楽楽精算のAI開発ロードマップも公開されました。2025年12月に伝票作成AIエージェントβ版 → 2026年6月に正式リリース（証憑から経費精算書を自動作成）→ 証憑取得AIエージェント → 2027年以降は会社独自ルールの参照、交際費・出張精算への拡大、GPS×AIによる交通費精算の完全自動化。承認側も申請レビューAI・証憑/伝票照合AI・適格請求書チェックAIを整備し、2030年までに指示・確認・承認だけで業務が回る「完全自動化」を目指すそうです。

問題提起：「うちは綺麗にスクラム回ってます」

「そう言える開発組織ほど、実はお客様を消耗させているかもしれない」。この問題提起と同時に、今日持ち帰るたった1つの言葉として「変化の設計者」が最初に提示されました。アジャイル vs ウォーターフォールという手法の二項対立はもう終わり。フォーカスすべきは「手法」ではなく「お客様」であり、開発プロセス設計の主語を我々（チーム）から彼ら（顧客）へ移す、という宣言です。

第一幕：正解は1つじゃない（2つの社内事例）

対照的な2つの事例が紹介されました。

ケース1：「早く出す」を信じた結果、お客様にコストを払わせた話。モバイル機能の拡張でフィードバックを急ぎ、リリーススピードを最優先した結果、リリース後に不具合が頻発して顧客に過度な負担をかけた。開発チームは「速く出せた」と思っていたが、顧客にとっては「速く出された不具合」でしかなかった。リリース頻度は一定でも、問い合わせ・緊急修正が急増して対応工数を大幅にロスした。「早く出す」は手段であって、目的ではない——。

ケース2：法改正対応をウォーターフォールで貫いた話。①固定された期日（半年後・動かせない）、②逆算して仕様を固める（仮説でも確定）、③一直線に作り切る（小さく出さない）。結果は納期遵守・安定稼働です。効いた理由は3つの力が揃ったから——期日が固定（法律で外から決定）、座組みが揃う（ステークホルダー合意）、PMの力量（推進し切る力）。不確実性が高くてもウォーターフォールが効いたわけです。

ここで刺さるのが「不確実性が高い＝アジャイル」という短絡の指摘です。ケース1は不確実性が低〜中なのにアジャイル的に出して失敗し、ケース2は不確実性が高いのにWFで成功した。正しい開発プロセスは状況が決める。「内部の工夫」（アジャイル・スクラム・WF）から「外部環境の観察」（Time・Customer・AI）へ視座を移そう、という整理です。

第二幕：プロセスを決める3つの外部要因と3つの判断軸

プロセス設計を左右する外部要因は3つ挙げられました。

時間: 頻度は不確実性を埋める手段であって目的ではない。B2C の購入者向け体験なら反応を見るために月10回以上のリリースが効くが、B2B の倉庫連携システムは価値の出方が明確で、過度に頻度を上げる意味がない
顧客: 見るべきはスプリントの板ではなく「お客様の業務カレンダー」。月末・月初・決算期は負荷のピークで、そこにリリースが直撃すると学習負荷の増大・社内問い合わせ増・運用ルールの強制変更が起きる。顧客を楽にするための改善が、顧客を苦しめてはいけない
AI: PdM／デザイナー／エンジニアの役割境界が溶け（PdMがAIでプロトタイプを作る時代）、「誰が本番品質を担保するか」が曖昧に。しかもAIは精度・運用コスト・UXの受容度など「実際に出してみないと分からない」要素が極めて多く、不確実性の種類が変わる

そのうえで、不確実な状況を診断する「3つの判断軸」が示されました。軸①は「チームができるか」から「顧客が受け止められるか」へ。供給側の論理「スプリントが終わったから出す」ではなく、顧客起点の論理「お客様が変更を受け止められるタイミングで出す」。頻繁に出すことが顧客志向なのではなく、「受け止めやすい形で出す」ことが顧客志向です。軸②が、次の判断フレームです。

この図のポイントは、「とりあえずアジャイルで出す」という思考停止を脱却し、改修内容に応じた最適な開発レーンを可視化する点です。そして軸③が、既存ルールが通じない「AI領域」は意図的に切り離すこと。基盤機能は仕様の予見可能性が高く「作り込み」が価値に直結する、つまり作り込めば減る不確実性。AI機能はユーザーの反応を見ないと正解が分からず「作ってから学ぶ」比率が極めて高い、つまり出さないと減らない不確実性。性質の異なるものを同じプロセスで回すと、互いに干渉して必ず破綻する、という整理です。

N=1の実践：同一プロダクト内の二重ループ

ラクスの実践として、同一プロダクト内にハイブリッド開発プロセスを構築した事例が紹介されました。

二重ループの命綱は「ゲート」です。実験で学んだもののうち、不確実性が十分に下がったものだけを本流（Main Stream）に載せる。ここを曖昧にすると二重ループは一気に崩れます。ゲートの判定基準は3つで、精度（業務で受け入れられる水準か？XX%以上）、コスト（継続運用可能な単価か？XX円/利用以下）、UX評価（顧客の主観評価をクリアしたか？X.X以上）。声の大きさではなく「データと全員の合意」で本流化を判断する、というのが運用の肝です。

探索ループの運用設計では、Feature Flag を「いつでも戻れるドア（2-way door）」＝攻めるための守りの設計と位置づけ、「撤退できないAI機能は、出してはいけない」と言い切っていました。どちらのループに乗せるかの境界条件チェックリストも実践的です——1. 顧客の業務フローを大きく変えるか？ 2. 失敗時・障害時の影響は限定できるか？ 3. 可逆か？（すぐに戻せる 2-way door か） 4. サポート・CS は変更を受け止められる体制か？開発チームの中だけで完結させず、顧客影響と社内体制の両軸で判断します。

第三幕：エンジニアの新しい主戦場

AIによる実装コストの低下と引き換えに、上流の意思決定（何を作るか・いつ出すか・どこを探索しどこを安定させるか）の価値が高騰する。実装力だけでは差がつきにくい時代、技術の専門性を大前提としつつ、勝負の場は「意思決定」へ移る、という展望が語られました。

AIが超高速に作る「動くもの（プロトタイプ）」とプロダクション品質の間には想像の10倍の距離があり、それを隔てる3つの壁が挙げられました。①トレードオフの壁「どこまで作るか、どこを捨てるか」、②ドメインの当てはめの壁「この課題では、どの機能が効くのか」、③品質の線引きの壁「ここまで作り込むか」。AIは“作業”は肩代わりしてくれる。しかし、“判断”は肩代わりしてくれない。

「変化の設計者」が担う4つのミッションは、顧客の業務サイクルを理解する／「変更負荷×不確実性」で設計する／探索ループの「ゲート」を判定する／仮説と検証指標を自ら定義する。「本来はPdMの仕事では」と思われがちですが、技術の不確実性を最も解像度高く見極められる現場のエンジニアこそが、この領域の主役だ、と。これまでの「作る人」（仕様を受け取って実装する・品質を守る）から、「変化の設計者」（どこを探索し、どこを安定化するかを決める・変化を設計する）へ。「開発プロセスは、“信じるもの”じゃなくて、“設計するもの”」という言葉は、この日のベストフレーズ候補です。

まとめは3点。01 リリース頻度は正義ではない（顧客が受け止められるかを最優先の評価軸に）。02 業務サイクルと不確実性で使い分ける（2軸マトリクスと二重ループで最適なレーンを構築）。03 エンジニアの価値は「探索」へ広がる（プロセス最適化を通じた「変化の設計者」となる）。開発プロセスの最適化は、生産性のためだけでなく、事業を勝たせるためのものである——という締めでした。

セッション5：生成AI×ローコードで実現するコンテキスト指向の開発 🧩

（阿島哲夫氏／OutSystemsジャパン）

Java 開発10年→外資系クラウドベンダー2社→2019年から OutSystems ジャパンという経歴の阿島氏によるセッションです。キャリアの原動力は「Webアプリケーションの開発生産性と変更容易性の圧倒的な向上」とのこと。副題は「ローコード開発からAIエージェント開発の時代へ」。20分の短枠ながら、「AIの理想とエンタープライズの現実のギャップ」という課題設定が明快でした。

AI開発の急拡大と、AIファースト競争

まず引用された統計が、勢いを物語ります。

90%: 2028年までにエンタープライズのソフトウェアエンジニアの90%がAIコードアシスタントを利用するようになる（Gartner）。AIはもう当たり前の世界
59%: 開発者の59%が3つ以上のAIコーディングツールを同時に使用（2025 State of AI code quality）。エコシステムは急速に分断されつつある
41%: ソフトウェアの41%は、すべてのコードがすでにAIによって生成（InfoWorld）
71% の CEO が AI を最優先の投資分野と回答（KPMG 2025 Global CEO Outlook）、$2兆が2026年までに見込まれる世界のAI支出規模（Gartner）、92% の企業が今後3年間で AI 投資を拡大予定（McKinsey）

AIファーストを目指す競争は激化し、ROI向上へのプレッシャーが高まっている、という背景です。

AIへの大きな期待と、エンタープライズの現実のギャップ

一方で現実には壁があります。AIツール側の現実は「終わりのないPoC」「スケールへの道筋がない」「壮大すぎる約束」。対する Agentic Enterprise 側の要求は「ポリシー・ルールに従う出力」「大規模なガバナンス」「壮大な期待に対する現実」。この間に「AIの理想とエンタープライズの現実のギャップ」が横たわります。具体的な課題は3つ挙げられました。

Context Gap: エージェントは顧客のアプリケーションポートフォリオやシステムアーキテクチャを認識できない
High-velocity "blast radius": AIはチームが検討・検証・管理を行うより速いペースで変化を生み出している
Integration and operational risk: 外部データソースやAIモデルへアプリが独自に接続し、アーキテクチャ・セキュリティ・パフォーマンスの一貫性がない

リスクの実例も畳みかけられました。67%のITリーダーはAIガバナンスに自信を持っていない。バイブコーディングの普及に伴い、2028年までにソフトウェアの欠陥が2,500%増加するという予測。Apple が「バイブコーディング」対応の iPhone アプリに難色を示した件（9to5Mac）、Amazon がエンジニアに AI コーディングツールの使用を強制して630万件の注文を失った件（Medium）、あるAIエージェントがデータベースを丸ごと破壊した件（FORTUNE）——「悲惨な体験をしたのは一社だけではない」と。

面白かったのは、「ハーネスエンジニアリングで解決できるのでは？」という（まさに直前のセッションたちが推していた）アプローチへのカウンターです。その裏に潜むコスト——ハーネスの整備・維持の負担——は無視されがちだ、という指摘でした。ハーネスを自前で作り込む道と、プラットフォームに載る道のトレードオフが、1日の中で両面から聞けたのは収穫です。

OutSystems Agentic Systems Platform：Enterprise Context Graph

OutSystems の答えは、エンタープライズ利用のためのアーキテクチャ・ベストプラクティス・既存資産を「知っている」AI開発レイヤー、Enterprise Context Graph です。Apps・Agents・Workflows・Entities・Logic・LLMs・Logs・Analytics・Deployment history を Deep・Unified・Enforceable に一元管理し、AIに欠けているコンテキストをプラットフォーム側が供給します。

Early Access の「OutSystems Agent Experience」では、Enterprise Context Graph や Mentor/Platform サービスを MCP サーバーとして公開しています。43 の MCP & API サービスには app_info、app_refs、app_revisions、context_actions、context_agents、context_entities、context_roles、context_screens、context_search などが並び、Claude Code や AWS Kiro をはじめとした外部のAIコーディングエージェントから、ビルトインのエンタープライズ品質を維持したまま OutSystems アプリケーションを作成・編集できます。Claude Design や Figma などのデザインシステムとの連携、スクリーンショット・スケッチ・HTML・ER図・定義書・仕様書等との連携、企業特有のコンテキスト/ハーネスを加味した開発も可能とのことです。

OutSystems + AI は、ハイコード + AI を超える

主張の核はここです。プログラミング言語のコードではなくビジュアルモデルが生成されるため、視認性・可読性・メンテナンス性が高い。データ・ロジック・画面・アーキテクチャの一貫性・整合性・関連性（コンテキスト）を維持できる。再利用・モジュール化・設計制約により技術的負債を抑制し、強力なガバナンスとビルトインのセキュリティ機能を備え、開発からデプロイ、運用・監視までフルライフサイクルをサポートする。Gartner の図を引きながら、Traditional stack → Low-code、Traditional stack+GenAI → Low-code+GenAI へと、リスク低減と生産性の両軸で右上に進化する、という位置づけが示されました。

まとめは「統合（Unified）・俊敏（Agile）・エンタープライズ実績（Enterprise-Proven）を備えた唯一のAI開発プラットフォーム」。アプリとAIエージェントを単一プラットフォームで構築・実行・運用し、品質やコントロールを保ちながらAIのスピードでイノベーションを加速し、ミッションクリティカルな実績で信頼される。グローバルサポート、600以上のパートナー、90万以上のコミュニティというエコシステムの紹介で締めくくられました。ベンダーセッションではありますが、「コンテキストの欠落」という課題設定自体は、この後の黒田氏のセッションとも強く共鳴していました。

セッション6：開発は速く安くなる。開発量は増える。ボトルネックは移動する。 🚰

（黒田樹氏／インディードリクルートテクノロジーズ）

1日目の締めは、Indeed Recruit Technologies VP の黒田氏による組織論です。講演タイトルは「開発が速く安くなった後の話 — AI時代のソフトウェアエンジニアリング組織論」。リクルートの HR Tech SBU で Indeed PLUS を提供・運用する自部署のエンジニア全体に、2025年6月から Claude Code、2025年9月から Codex を配布し、使い方は指定せず、現場ごとに何が起きるかを観察した——その社内実証とその後の組織の動きがベースです。AIの議論は「仕事が消えるか」「どのモデルが賢いか」に集まりやすいが、今日のテーマは三つ目、「ボトルネックはどこへ移るか」。実装が速くなっても、開発全体が同じ倍率で速くなった現場はなく、要求→要件→実装（AIで速く）→テスト→運用のパイプの中で、どこかの管が次に膨らむ、という問題設定です。

01 歴史から始める：職能は消えずに配置を変えてきた

まず歴史的視座です。産業革命では蒸気機関の登場から工場動力の置換までおよそ1世紀かかり、変化はいきなり「明日から仕事がない」という形では起きませんでした。むしろ英国の石炭消費は1900年までに3倍になり、効率化はかえって需要を増やしました——1865年の『石炭問題』に由来する「ジェボンズのパラドックス」です。機械化で製品が安くなり、需要がそれ以上に伸びたため、労働者も減らずに増えました。

理論的な整理としては Acemoglu–Restrepo が引かれ、自動化は既存タスクを機械が置換（代替効果）すると同時に、人間に比較優位のある新しいタスクを創出（復権効果）し、雇用の質は変容しつつ雇用総量は新たな均衡へ推移する、と。ただし復権は自動では起きない。電気の例が象徴的で、動力源をモーターに置き換えただけの工場では生産性は約30年上がらず、各機械に小さなモーターを付けて作業の順序どおりに機械を並べ替えた工場から効果が出ました（Paul A. David「ダイナモとコンピュータ」）。復権は、技術に合わせて仕事を組み替えた側に来る。

ITの誕生以降も同じ構造の繰り返しです。1960s メインフレーム（定型事務を置換し COBOL/Fortran 専門職とシステム管理者を創出）→ 1980s オープン系（Sysadmin 急増）→ 1990s インターネット → 2007 スマートフォン → 2010s クラウド。抽象化が起きると職能は、隠蔽された基盤を「支え続ける側」（深い技術力・少数）と、中身を知らなくても使える「抽象の上に立つ側」（参入障壁が下がり人数がスケール）の二手に分かれます。そして抽象化のたびにエンジニアは増えてきました。日本のITエンジニアは1985年の約32万人から2024年の約144万人へ4.5倍（US BLS は今後10年でさらに15%成長を予測）。今回抽象化されつつあるのは「実装」とその周辺（設計案・テスト・調査・移行・レビュー補助まで）で、歴史の構造に従えば、この先に起きるのは史上最大級の分化と再配置だ、という見立てです。

02 開発の経済性が変わる：ROI境界の低下と、残るI

ROI の分母である Investment が AI で下がり始めたことで、開発組織の前提が順番に変わっていきます。これまで作られなかったシステムの多くは、価値が低かったのではなく ROI が合わなかっただけ。Investment が下がると ROI 境界そのものが下がり、部署単位・顧客単位・業務単位の個別事情の開発が境界上に現れて、開発の総量は自然と増えていく——石炭と同じ構図です。我々が直面するのは「作れない」ではなく「作る対象が増え続ける」状況だ、と。

ただし、下がるのは初期開発の Investment だけです。検証、統合、運用、保守、障害対応、セキュリティ、そして責任——作った後に掛かり続ける費用は自然には下がりません。この「残る I」が後半の KTLO の伏線になります。

03 現場で何が起きたか：6つの事例

AIを配って観察した結果、成果は現場ごとにはっきり割れました。差分は6つの観点——必要コンテキスト量／現実世界依存性／影響範囲の閉じやすさ／決定論的検証のしやすさ／チームの経験量／自動化との相性——で読み解かれています。

事例	結果	何が起きたか
大規模レガシーシステムA	✅	レガシー本体（JSP・サーバサイド）に手を入れず、JSP を API と捉えて JavaScript 側で業務要件を満たす設計に。影響が閉じ、AIに与えるコンテキストも小さく済んだ。経験者が暗黙知で文脈を補い、AIの推論を必要な範囲に絞った
Airワーク採用管理	✅	経験の浅いメンバーがベテランと同じ手順で開発できるよう、要件明確化→実装→テスト生成→PRレビュー→振り返りを Skills とカスタムエージェントのパイプライン化。ベテランの暗黙知を仕組み側へ外部化。オフショア向けに冗長なトランザクションスクリプトを許容してきた「冗長だが疎結合」な構成が、一つの変更に必要なコンテキストが小さいという性質を生み、結果的にAIの推論と好相性だった
求人サイト群のSEO	✅	Google のガイドライン・Search Console・クローラー仕様という一般論で推論を拘束でき、改修もフロントに閉じる。起案から実装まで0.5日、3か月で63施策。従来の「会議で絞ってから作る」が「先に全部作って、会議で間引く」に順序が逆転した
リクナビNEXTバッチ	❌	性能問題のバッチ改善で苦戦し、最終的にテックリードが自力で解決。支配的だったのは再実行性・処理時間・整合性・負荷制約・データ分布という「コード外の現実制約」。コードを全部読ませてもAIには本番の物理が見えず、コンパイルも単体テストも通るのに本番で破綻する偽陽性コードが出た。人間が書いたように見えるぶん、レビューする側の批判的思考が止まりやすい
Airワーク EOSL対応	✅（試行錯誤）	ライブラリ・言語バージョンアップの保全テストを大量作成するため、最初は `while :; do cat PROMPT.md
AI-OPS	✅	アラート起点の障害調査は、ログ・ソース・運用知識・過去障害・JIRA を横断して情報を集める仕事。この横断収集と仮説整理をAIに任せると、24/365チームからのエスカレーションを起点に、調査準備→Datadog・外部システム・ソース収集→エラー分析→レポート生成→JIRA チケット起票まで一気通貫で回った。AIは「受け止める側」の仕事にも使える

成否を分けたのはモデルの性能ではなくコンテキストの構造です。6事例で使ったモデルに大きな差はないのに結果は分かれた。成功した事例はいずれも、一つの変更に必要なコンテキストを「AIが誤りなく推論できる幅」に収める工夫——疎結合なアーキテクチャ、本体に触れない境界の新設、一般論による拘束、役割の限定と決定論の評価系——をしていました。失敗したバッチだけは、必要なコンテキストの大半がコードの外にあり、この幅に収められなかった。もう一つの共通点は人間の役割で、ベテランの暗黙知をパイプラインや対話でコンテキストとして供給し、品質責任は決定論の検証系に寄せる。人間の仕事はコードを書くことから「推論が安定する条件を整えること」へ移っている、と。

面白いのは、現場のやり方に後から名前がついたという話です。プロンプトエンジニアリング＝レガシーAの経験者対話、コンテキストエンジニアリング＝Airワークの外部化・SEOの一般論拘束、ハーネスエンジニアリング＝EOSLの決定論ループ、ループエンジニアリング＝EOSL初期のラルフループ。流行語を追ったのではなく、現場の試行錯誤が先にあった、という順序が説得力を持っていました。

04 一般化：確率的な生成を、決定論で受け止める

観察の一般化として、AIを用いた開発は「理想的な出力に必要なコンテキスト」と「実際にAIへ与えられるコンテキスト」の差をどう扱うかのゲームだと整理されました。差が大きいほど推論の自由度が広がり、偽陽性とハルシネーションが増える。内訳は、AIが収集可能な情報（AIエコシステム性能依存）＋個人のインプット/プロンプト（パイロット性能依存）＋AIが誤りなく推論できる幅（モデル性能依存）で、残った幅は外側から決定論的に検証する必要があります。モデルとエコシステムの性能は数ヶ月で前提が壊れるほど向上していて、最近は要求を的確に伝えてAI自身にプロンプトを書かせる方が良い気もしている——それでも「外側から決定論的に検証する」は進化しても必要なまま、とのことです。

「生成は確率的でもよい。受け止め方は決定論で」。AIに正しさを期待するのではなく、間違っても壊れにくい系を先に設計する。LLMの使い方は2つの流派に収斂しつつあるという整理も示されました。経験者が暗黙知を内側に持ち対話でAIの推論を制御する協働型（コパイロット型）と、Skills・sub-agents・契約・テンプレートで暗黙知を外部化し仕組みとして再現性を作る委託型（オーケストレーター型）。優劣はなく、チームの経験量と現場特性で使い分ける。どちらもコンテキスト差を埋める適応戦略です。

アーキテクチャは「推論を小さくする装置」になる、という視点も新鮮でした。一つの変更に必要なコンテキスト量をどこまで局所化できるか。境界が明確で、契約が強く、影響範囲が閉じ、観測と検証ができる構造は、人間にもAIにも読みやすい。ただしマイクロサービス化そのものは正義ではなく、現在のAI性能を前提にコンテキストウィンドウへ収めることを頑張りすぎると、未来から見て分割損になる可能性がある（考え中、として率直に共有されました）。さらに「妄想」と断ったうえで、ソースコードがDBと契約と制約から生成される派生物（ほぼ無料）になり、容易に作り直せない既存データ・スキーマ・制約・不変条件へ、アーキテクチャ上の重心がデータモデルに移るのでは、という展望も。ClickHouse のセッションと合わせて聴くと、示唆的です。

05 人間と組織はどうなるか：フルフルと浅い階層

人間の仕事は全工程に薄く残り、どの一工程からも丸ごとは消えない——問いを立てる／判断する／境界を引く／品質責任を持つ／異常時に介入する。この形が組織設計の前提になります。

生成が安くなると、相対的に高く見えてくるのがコミュニケーションコストです。8人が相互にやり取りするとパスは56本、人数が増えればパスは二乗で増える。各工程の作業はAIで速くなっても、工程間の受け渡しはそのまま残るため、生成コストが下がるほど受け渡しの比率が上がる。実装がボトルネックだった時代には見えなかったこのコストが、次のボトルネックになります。対処は2系統——壁を作るか、Nを減らすか（背景理論として Brooks『人月の神話』、Conway の法則、竹内・野中の The New New Product Development Game が挙げられました）。モノ的アプローチはアーキテクチャで境界を切ってパスを断つこと、ヒト的アプローチは一人が担う範囲を広げて人数Nそのものを減らすことです。

後者の理想形が「フルフル」＝フルスタック×フルプロセス。ビジネス検討からコードまで一人で進めれば受け渡しは発生しません。実際は難しいので工程を重ねるオーバーラップ型にしつつ、フルスタック（BE・FE・インフラ）に加えフルプロセス（要求整理も設計もコーディングも）を担う。座組みも変えて階層を浅くした——深い階層は事前調整で不確実性を抑え込む設計で、計画は立てやすい代わりに各自のストレッチ幅に制約がかかる。フラットな座組みは事前調整を最小に、リアルタイム調整を最大にする。メンバーは通常より広い責務と判断範囲を担ったそうです。

06 増えた後の話：KTLO と FDE

作るコストは下がっても、動かし続けるコスト（KTLO: Keep The Light On）は自然には下がりません。ROI境界の低下で小さなシステムが増えるほど、維持保守対象のロングテールが伸び、個別システム同士がAPIとデータで絡み合って依存関係も増える。一つ一つは合理的な開発でも、総体では維持保守対象が爆発する。システムがマイクロ化して増え続けると、一箇所の変更が予測しにくい連鎖障害を招く「依存関係のスパゲッティ化」がこれまでにない規模で起きる。イメージは「塩漬けシステムを1000個抱えながらアクティブの開発を回す」——開発してるそばから塩漬け側のセキュリティパッチやライブラリアップデートに追われる状況です。

だから今後の重点投資は、生成能力や開発支援だけでなく、増えたシステムを受け止める維持保守の側にも要る。その受け皿が「KTLOセンター」です。維持保守対象の爆発を人員の線形増加で受けるといずれ限界なので、少人数で大きな保守対象を受けるためのAIレバレッジを効かせる。まず70リポジトリ規模のマイクロサービス群から着手し、24/365のトラブル対応・各種パッチ当て・EOSL対応・バージョン管理・問い合わせ対応を、AI-OPS をフル活用するベトナムオフショア体制で受ける形を検証中とのことです。

市場側の出口としては FDE（Forward Deployed Engineer） が挙げられました。個別最適が ROI に乗る時代は売り方も変わる。「全社で1つのシステムを我慢して使う」前提のパッケージモデルが崩れ、クライアント業務に合わせた個別実装が採算に乗る。顧客の現場最前線で業務文脈を理解し、その場で実装し、運用に乗せ、再利用可能なパターンとして共通基盤に還流させる職能——中身を見ればフルフル人材が社外の現場に立つ形です。前線が個別最適を作り、KTLOセンターが支える。この2つがそろったとき、量産が事業として回る。

まとめ：ボトルネックに合わせた組み替え

結論は「ボトルネックに合わせた組み替え」。制約理論（Goldratt）が「制約に他の工程を従属させる」と呼ぶ発想を、一貫して適用した形です。

領域	制約（ボトルネック）	従属させたもの
SEO の開発プロセス	判断（会議）	実装——「絞ってから作る」をやめ、先に作って間引く順序へ
EOSL の品質保証	検証	生成——生成をそのまま流さず、決定論の検証ループに従属
KTLO	受け皿	開発——増える開発を、受け皿が受けられる形に従属
組織	判断のハンドオフ	組織の形——階層を浅くしフルフルで判断と実装の往復を短縮
アーキテクチャ	検証のしやすさ	設計——境界と契約で推論の幅を狭める

最後は歴史に戻ります。産業革命では蒸気への移行に1世紀かかり、労働者は増えた。電気は引くだけの工場では効果が出ず、作業を組み替えた工場で効果が出た。AIでも同じことが起きるのではないか——現場にAIを配って1年観察してきた、いまの我々の見立て。だから速くなった実装をそのまま最大化せず、ボトルネックの工程に合わせて組織・プロセス・アーキテクチャを組み替えるところから始めている、という締めでした。APPENDIX として Jevons、Allen（Engels' pause）、Bessen、Goldin & Katz、Paul David、Acemoglu & Restrepo、Brooks、Conway、竹内・野中、Goldratt と参考理論が列挙されていて、あとから辿れるのもありがたい構成です。

1日目を通して見えた共通テーマ 🧵

分野の違う6セッションを並べて聴くと、独立した登壇者たちが同じ結論に到達していたことがはっきり見えました。3つにまとめます。

テーマ1：確率的な生成を、決定論で受け止める。 澁井氏の「決定論ファースト、LLMロングテール」「品質責任を決定論の評価系に寄せる」と、黒田氏の EOSL 事例（生成は確率のまま、評価をテスト実行とカバレッジ計測の決定論に差し替えたらループが収束した）は、ほぼ同じ設計原則です。しかも両者とも「テストが緑でも安心しない。出力は分布であり、1例の合格は何も保証しない」という同じ注意を発していました。方法論の側（澁井氏）と現場観察の側（黒田氏）から同じ場所に着地している、というのが面白いところです。

テーマ2：人間に「深く考える・判断」を残す。 伊達氏の「手放してはいけない3つの仕事」と設計後・デプロイ前の人のゲート、稲垣氏の「AIは作業は肩代わりするが判断は肩代わりしない」「変化の設計者」、黒田氏の「人間の仕事は推論が安定する条件を整えることへ移る」「最終決定のハンドルを明け渡さない」。表現は違えど、AIに明け渡してはいけないのは判断のハンドルだ、という点で完全に一致しています。しかも3人とも、それを精神論ではなく「ゲート」「ゲート判定基準」「決定論の検証系」という仕組みに落としているのが今年らしいところです。

テーマ3：コンテキストが成否を分ける。 澁井氏の「共通認識の不在は運用負債」、阿島氏の「Context Gap」を埋める Enterprise Context Graph、黒田氏の「成否を分けたのはモデルの性能ではなくコンテキストの構造」。モデルの賢さ競争の外側で、コンテキストをどう供給・制限するかが実務の勝負どころになっている、というのが2026年夏時点の現在地のようです。一方で阿島氏からは「ハーネスの整備・維持コストは無視されがち」というカウンターも出ていて、自前でハーネスを育てる道（澁井氏・黒田氏）とプラットフォームに載る道（阿島氏）の選択は、組織の規模と体力次第なのだと思います。

おまけの気づきとして、「ハーネス」という言葉が3セッション（澁井氏・阿島氏・黒田氏）で独立に登場したのも印象的でした。黒田氏の「現場のやり方に、あとから名前がついた」という話のとおり、言葉が先ではなく実践が先。それが同時多発的に名前を得つつあるのが、ちょうど今なのでしょう。

私自身の持ち帰りを一つだけ挙げるなら、黒田氏の「復権は、技術に合わせて仕事を組み替えた側に来る」です。AIツールを配るだけでは、電気をモーターに置き換えただけの工場と同じで、30年待っても生産性は上がらない。プロセス・組織・アーキテクチャの組み替えまでやった側に効果が出る。明日からの自分の開発フローで、どこを決定論に寄せ、どこに人の判断のゲートを置き、どのコンテキストを Skills として外部化するか。この3つの問いを持ち帰って、まず自分のパイプラインを一箇所だけ組み替えてみようと思います。

参考