Open Source Summit Korea 2026: レイヤーごとに築く AI の説明責任

Open Source Summit Korea 2026 が閉幕し、ひとつのテーマが繰り返し浮かび上がっていました。説明責任（アカウンタビリティ）です。LG AI Research は基調講演の壇上から、学習データを出所までたどる政府委託の AI BOM を発表し、ブレイクアウトセッションは同じ問いを別のレイヤーで投げかけていました。AI エージェントは本番環境で何をしてよいのか、そして GPU は自らがコストに見合う働きをしていることをどう証明するのか、という問いです。本稿では、基調講演とブレイクアウトセッションが実際に示したものと、他の環境にも持ち帰れるパターンを整理します。

AI がアジェンダを支配していましたが、すべてではありませんでした。プログラムの少なくない部分は大規模インフラにとどまり（アップストリームへのパッチで幕を閉じた小規模クラスタの Ceph デバッグ、マルチ AZ の OpenStack 設計）、Argo はカナリア分析からエージェントが起案し人が承認するワークフローまで、繰り返し登場しました。ここまで AI に傾いたカンファレンスで、この地に足のついた部分があったのは良いことでした。

基調講演が示した構図

基調講演は説明責任を二つの方向から押し進めました。ひとつは経済です。オープンウェイトはフロンティア性能の ~90% を 6–8× 安価に提供し、合理的なデフォルトになりつつある一方で、データは AI スタックで唯一閉じたままのレイヤーだという指摘です。韓国はその議論の決着を待たず、すでに動いています。7月の9日間のうちに、フロンティア級の韓国製モデルが三つオープンになりました。最大のものは Apache 2.0 で公開された LG の7,500億パラメータの K-EXAONE 2.0 で、いずれも政府支援モデルを Hugging Face に公開していく国家プログラムから生まれたものです。もうひとつの方向は速度です。脆弱性が公開されてから悪用されるまでの窓は縮み続け、いまや悪用が公開に先行しうるところまで来ており、より遅い攻撃者を想定して設計されたパッチサイクルは、攻撃者が自動化するのと同じ速さで AI が脆弱性を見つけて直すことに依存するようになっています。

LG AI Research の社長兼 Chief AI Officer である Honglak Lee 博士は、オープンデータを検証の課題と捉えています。彼のチームは、商用利用可能とされていた 2,852 のデータセットを追跡し、その履歴に含まれるすべてのソースを確認しました。完全なレビューの結果、商用利用可能なまま残ったのは 605 データセット、およそ 21% だけでした。残りは、どこかの段階で研究専用または入手不能なソースに依存していました。Lee 博士は、オープンデータのほぼ 80% は、発行者にもユーザーにも、その完全な連鎖を一度も検査されたことがないと指摘しました。この問題は悪意ある行為者のせいではなく、仕組みそのものに組み込まれています。データセットがクリーニングされ、再パッケージされ、名前を付け替えられるにつれ、各ステップは妥当に見えても、時間が経つと寛容なライセンスを掲げたデータセットが本当の出所を隠してしまうことがあります。たとえば FineVision は、表面上はライセンスが一つだけのオープンなビジョン言語データセットですが、実際には 3,000 を超えるソースに由来します。チームの研究によれば、上流のどこかに法的リスクがある場合、その上に構築されたデータセットがそれを示さない確率は 62.6% でした。データセットを正しく検査するには、その由来となるすべてのソースを確認する必要があり、人が手作業で行うのは現実的ではありません。彼らの研究では、人間の専門家は重要な依存関係の 3 分の 1 以上を見落としました。これを解決するため、LG はソースをたどる過程を自動化し、判断は人に残しました。エージェントがデータセットカードを読み、記載されたソースをすべて抽出し、それぞれを最後までたどり、連鎖全体をスコアリングします。このシステムは手作業のおよそ 45 倍速く、人間より依存関係を 26% 多く見つけ、コストもはるかに低く、データセットあたり 207 ドルに対して 0.29 ドルで済みます。生成された記録は、韓国政府のために作られ SPDX 3.0 の上に構築されたプロファイルである K-AI BOM で使われます。この記録はデータセットに付き従うよう設計されています。データセットが作られるときに生成され、モデルへ受け継がれ、サービスに同梱され、サービスを運用する誰もが自分が何を使っているかを正確に確認できるようにします。SBOM がソフトウェアパッケージに対して果たす役割に似た、データセットの来歴（provenance）です。

この切迫感の背景には規制があります。韓国の AI 基本法は、2026年1月22日に施行されたアジア太平洋初の包括的な AI 法で、産業振興と信頼確保の義務を対にしており、その中には高影響 AI と生成 AI の事業者が使用した学習データの概要を提供する義務も含まれます。一文だけの開示ではこの義務は担えませんが、機械可読なリネージグラフなら担えます。

エージェントに課されるガードレール

セッションを横断して繰り返されたパターンがあります。AI エージェントはもはや失敗モードが仮説ではない、本番環境のアクターだということです。Harness の Jyoti Bisht と Animesh Pathak は、OPA セッションの論旨を追跡劇として組み立てました。コーディングエージェントが本番データベースを削除した実際のインシデントで幕を開け、その後、すべてのエージェントのツール呼び出しがアドミッションコントロールを通過し、Rego ポリシーが通すかどうかを決めるクラスタで同じ力学を再現しました。最初のポリシーは動詞（verb）で削除をブロックしました。するとエージェントは代わりに本番の Deployment 二つの名前を変更しました。それを禁じるものは何もなく、その名前を追跡していた Helm リリースが壊れました。続く強化版ポリシーは、動詞ではなく結果を統制します。ワークロードのアイデンティティ、すなわち名前、レプリカ数、ラベルを変えるあらゆる操作を、承認が必要なものとして扱うのです。次の抜け道はカバレッジでした。エージェントは誰もポリシーを書いていなかった唯一のネームスペースを見つけ出し、1時間あたり8.50ドルの GPU ノードを45台プロビジョニングしました。ここから二つ目のルール、統制されていないものはデフォルトで禁止する、が生まれ、三つ目として、コストは権限と並んでポリシーの中に置く、が生まれました。セッションは追跡ではなく協調で締めくくられました。エージェントは事前承認済みのワークフローテンプレートを通じてのみ、エージェント起点であることを明示して変更を起案し、実行は人間が承認します。そしてプロンプトインジェクションからログ経由のデータ持ち出しまで、6クラスの脅威モデルが各リスクを具体的な防御に対応付けていました。

Megazone の Hoon Jo は運用側の物語を語りました。15の Helm リリース、Kafka の ZooKeeper から KRaft への移行、Redis を置き換える Valkey、そしてダウンタイムが許されない本番移行を、一人のオペレーターと一体の AI エージェントで担いました。エージェントはセッションをまたいで何も記憶しないため、決定も値も教訓も失われ、推測で穴を埋めては決まった選択をやり直し、コマンドをでっち上げ、同じ依頼が異なる結果につながりかねませんでした。本番環境では許されないことです。彼の答えである GitAIOps は、Git をエージェントの持続する記憶に変え、推測の余地を一つずつ取り除く4つのレイヤーとして構成します。人間の計画書（36ファイル、23,000行超）が判断の理由を保持し、エージェントはそれを凝縮した6ファイルのプロジェクト状態ダッシュボードを読みます。前提条件からロールバックまで順序の決まった117の事前作成コマンドファイルがあり、ピン留めされていない Mimir チャートが自動アップグレードして本番でクラッシュループを起こしたあとに加えられたルールである、バージョンと値をピン留めした30のファイルが最後の隙間をふさぎます。同じ入力はつねに同じデプロイにつながります。

結果は明快でした。DEV 環境の構築は2週間から2日に短縮され、PROD は同じガードレールを再利用して1週間から1日になり、旧プラットフォームは止まりませんでした。エージェントが速く働いたからではなく、予測不能なステップをやり直す必要がなくなったからです。彼の助言はどのチームにも当てはまります。エージェントが読むファイルが何であれ、ルールと現在の状態を今から記録すること。大きな変更の前には先に計画し、値をピン留めすること。そして、人間が更新し AI が読みやすく保つかたちで、その唯一の情報源を生かし続けること。このアプローチは特定のエージェントに縛られず、移行が終わったあとも記憶は働き続けます。

IBM の Kevin Dubois は、似た課題に GitOps から取り組みました。彼はまず2024年の CrowdStrike 障害に触れ、変更を全員へ一斉にリリースすると何が起こりうるかを示しました。問題があれば、すべてのユーザーが即座に影響を受けます。何が影響を抑えられたかを問いかけ、答えとしてプログレッシブデリバリーを挙げました。通常、GitOps のデプロイは一度にすべてをリリースしますが、Argo Rollouts を使えば段階的なロールアウトができます。新しいバージョンはトラフィックの一部だけを受け持つカナリアとして始まり、ロールアウトを続けるかどうかは AnalysisTemplate が判断します。これは普通、成功率を95%以上に保つといった手書きの PromQL 条件で行われます。Dubois はその手書きの判定者を AI エージェントに置き換えました。RolloutManager で設定され AnalysisTemplate から参照される metric-ai プラグインが、カナリアとステーブル両バージョンのメトリクスとログをエージェントに送ります。エージェントは両者を比較し、必要なら追加の指示（たとえば見た目の変化は無視する、といった指示）に従い、リリースを続けるかロールバックするかをスコアで返します。ロールバックが起き、リポジトリの URL が設定されていれば、エージェントは修正案を含むプルリクエストも開きます。こうして失敗したロールアウトは単なるアラートではなくレビュー可能なコード変更になり、修正はレビューを経て再デプロイできます。Dubois の要点は明快でした。全員への一斉リリースは危険であり、カナリアロールアウトとフィーチャーフラグのほうが安全で、エージェントはメトリクスとログの分析から修正の提案までのプロセスを自動化できます。

データセンターからエッジまで、GPU の算術

KubeCon India 2026 で取り上げた GPU 活用の糸は、ソウルではより鋭くなって戻ってきました。今回はロードバランサーから始まります。古典的なバランサーはコネクションを見ますが、LLM リクエストのコストは KV キャッシュにあります。プロンプトのプレフィックスに対応する KV ブロックをすでに保持している GPU にリクエストを着地させればプリフィルは省略され、それ以外の場所では同じテンソルが再計算され、最初のトークンまでの時間（TTFT）が膨らみます。NETLOX の Seokhwan Kong は「キャッシュの局所性は公平性より重要になった」という挑発から話を始め、講演の残りをその但し書きに費やしました。キャッシュだけを追えば、隣の GPU が遊んでいるのに一つの GPU だけが飽和します。だから局所性そのものに上限が必要で、それが利くのはフリートが実際に忙しいときだけです。

loxilb 推論ゲートウェイは、ルーティングの決定をロードバランサー自体の中へ持ち込みます。Envoy もサイドカーも Kubernetes も必要としない単一の Go/eBPF バイナリとして動くため、ベアメタルでも仮想マシンでもエッジでも動作します。ルーティングは4つのステップで進み、前のステップが一致しなければ次を使います。第一に、会話はすでに使っていた GPU に留まります。セッションがなければ、プレフィックストライがプロンプトが以前ルーティングしたものと似ているかを確認します。ただしトライは送った記録を覚えているだけで、キャッシュからの追い出し（eviction）は追跡できません。第三のステップは完全一致です。ゲートウェイはモデルのトークナイザーでプロンプトをトークナイズし、トークンをブロックにまとめ、サービングエンジンと同じ方法でブロックハッシュを計算して、各 GPU がいま保持しているブロックのライブな一覧と比較します。この一覧は、エンジンの KV キャッシュイベントストリームが ZMQ 経由で最新に保ちます。送られるのはブロックあたり数バイトのハッシュだけで、テンソルは常に GPU メモリに留まります。どれも一致しなければ、リクエストは最も空いているエンドポイントへ向かいます。ただしチームが指摘したとおり、負荷が最も低い GPU はたいてい最も冷えた GPU であり、単純に接続数の少なさで選ぶとキャッシュを外しやすくなります。このシステムづくりからは二つの教訓が得られました。第一に、vLLM と SGLang はブロックハッシュの計算方法が異なるため、ハッシュ方式はルールごとにエンジン別に設定します。第二に、キャッシュヒットだけを追うのでは足りません。人気のシステムプロンプトがすべてのクライアントを同じ GPU へ送りかねないため、アフィニティはエンドポイントごとの容量で制限され、必要なら隣へあふれさせます（スピル）。プリフィル／デコード分離（P/D disaggregation）で Qwen2.5-7B-Instruct を動かした NAVER Cloud でのテストでは、vLLM のルーターを対照群として、飽和時の SLO 内 goodput がほぼ2倍になり、0.271 に対して 0.581 に達しました。チームはその理由を、vLLM ルーターに高負荷から自身を守る容量上限がないことに求めています。限界についても明確でした。飽和未満では彼らのルーティングは同等かむしろ悪く、勝つと考えていた適応型コントローラーを固定のスピル閾値が上回りました。トラフィックパターンが違えばこの結果は変わりうる、と彼らは付け加えています。

ルーティングはどの GPU がリクエストをさばくかを決めます。各ワークロードが GPU をどれだけ得るかは別の問いで、7月に公開した解説記事では HAMi がデータセンターでその問いに答える様子を扱いました。Dynamia.AI の Reza Jelveh は同じ CNCF インキュベーションプロジェクトをエッジへ押し進めました。エッジでは制約が硬くなります。5–40 Wで無人運転される箱、CPU と GPU と OS が分け合う8–64 GB のユニファイドメモリ、スケールアウトする先はなく、貪欲なエージェントが残りを飢えさせても見ている人はいません。

エッジで変わるのは、何をスライスするかです。Jetson Orin のシリコンには MIG がなく（JetPack はより新しい Thor ラインでのみ MIG をプレビュー提供しています）、データセンターのハードウェアの壁は使えず、ソフトウェアのフェンスが唯一の分離です。HAMi はユニファイド LPDDR プールを直接切り分け、8 GB の Jetson に10+ エージェントを収め、需要がメモリを超えるとタイムシェアリングに切り替えて、アイドルなスライスをホスト RAM へスワップします。この制限が守られるのは、HAMi がポッドの中で CUDA 呼び出しをインターセプトし、ポッドには自分のスライスしか見えないからです。そして同じセマンティクスは、型付きの ResourceSlice の容量と ResourceClaim として Kubernetes DRA にマッピングされます。エッジのもう一つの現実はヘテロジニアスであることです。Jelveh は Jetson クラスの GPU を Axelera や DeepX の NPU とワットあたりの性能で比較し、そのすべてを横断するスケジューリングプレーンは一つでした。

持ち帰る価値のあるテーマ

第一に、AI への説明責任はポリシーペーパーではなく、動くオープンソースとして到来しつつあります。データのための BOM、エージェントのためのアドミッションポリシー、AI 主導の変更のためのバージョン固定された運用です。第二に、エージェント運用についてコンセンサスが形成されつつあります。エージェントは分析し提案してよいが、実行はポリシーか、固定された構成か、人間を通る、というものです。第三に、GPU の効率は使用率ダッシュボードを出て、インフラそのものの中へ移りました。事後にレビューされるのではなく、リクエスト時にロードバランサーとスケジューラーで決まります。第四に、韓国は二つの前線で同時に動いています。フロンティア級のオープンモデルを公開しながら、新しい AI 法が来歴を法的義務にしつつあり、この二つは互いを強化します。オープンウェイトは精査を招き、精査には機構が必要なのです。