このBlog postは Open Governance for MySQL: A Step Forward for the Community の日本語訳です。 MySQL — 世界中の数百万のアプリケーションを支えるオープンソースデータベース — が新たな章を開きます。本日、Oracleは、より広範なコミュニティがプロジェクトの開発と方向性に参加するための道筋を作る、 MySQLのコミュニティガバナンスモデルを発表 しました。 このポストでは、AWSがこの動きを支持する理由と、MySQLコミュニティにとっての意味を説明します。 オープンガバナンスがオープンソースを機能させる 多様なコントリビューターと透明性のあるガバナンスを持つオープンソースプロジェクトは、より良いソフトウェアを生み出します。オープンガバナンスは、ユーザーからコントリビューター、そしてリーダーへの明確な道筋を示し、組織がプロジェクトの将来にエンジニアリングリソースなどを投資するを自信を与えます。 MySQLは約30年にわたり、インターネットインフラストラクチャの基盤となってきました。スタートアップから世界最大の企業まで、数十万の企業が最も重要なワークロードをMySQL上で実行しています。コミュニティの参加方法を明確化することで、その基盤が強化され、MySQLの利用者が将来を見据え、ビジネスを構築するための判断材料に役立ちます。 新しいガバナンスモデルの仕組み OracleがMySQLを買収して以来初めて、Oracle以外の組織がエンジンの構築方法と方向性において定義された役割を持つことになります。このモデルは、役割の段階を作ります：コントリビューターがコードと修正を提出し、コミッターが変更をレビューして承認し、プロジェクトリードがオプティマイザーやInnoDBなどの主要サブシステムを所有します。 これらの役割の上に、MySQLの長期的な方向性とリリースポリシーを設定するステアリングコミッティがあります。コミッティには、Oracle以外から4つの席があり、クラウドプロバイダー、MySQLの顧客、オープンソースコミュニティが占め、Oracleが過半数を持ちます。Oracleが最初のメンバーを2年の任期で指名し、その後、Oracle以外の席はコミュニティによる投票により決定されます。 これらすべてを支えるため、これまで存在しなかった外部コラボレーションとコントリビューションのためのチャネルとして、OracleはMySQLコミュニティのためのパブリックGitHubを立ち上げました。 AWSがこれを支持する理由 AWSは15年以上にわたり、ユーザーとして、コントリビューターとして、そしてMySQLに依存するサービスの構築者として、MySQLに深く投資してきました。今日、数万のお客様がAWS上でMySQLワークロードを実行しています。MySQLは私たちのエコシステムで最も重要なデータベースの一つであり、お客様はその長期的な健全性に直接的な利害関係を持っています。 AWSでは、オープンソースはすべての人にとって良いものであると信じており、オープンソースの価値をお客様に、そしてAWSの運用上のオペレーショナルエクセレンスをオープンソースコミュニティにもたらすことにコミットしています。そのコミットメントはシンプルな形で現れます：お客様がAWS上でオープンソースデータベースを実行して問題に遭遇した場合、私たちはアップストリームに対してMySQLを利用するすべてのユーザのために修正に取り組みます。 私たちにはまさにこれらを行ってきた実績があります。PostgreSQLでは、VACUUMを6倍高速化し、アップグレード時にレプリケーションスロットを維持し、autovacuum設定変更の再起動要件を削除しました。LinuxFoundationによるRedisのフォークであるValkeyでは、全文検索とハイブリッドクエリサポートを追加しました。そして、大量のテーブルを持つデータベースのアップグレード時のメモリ不足エラーの修正やヒストグラムエラーの修正など、MySQL自体にもすでにアップストリームに対し修正を貢献しています。 健全なアップストリームプロジェクトは、MySQLに依存するすべての人に利益をもたらします — 自ら運用する人、マネージドサービスを活用する人、またはそれらのシステムにツールや統合を構築する人。より多くのエンジニアがコードをレビューすれば、より多くのバグが発見されます。設計上の決定がオープンに行われれば、リリースされる機能はより幅広い実世界のユースケースを反映します。ガバナンスが透明であれば、組織はコントリビューションが評価され、声が聞かれるという自信を持ってプロジェクトに投資できます。 これは理論ではありません — OpenJDK、Valkey、その他数十のプロジェクトで、幅広い参加がソフトウェアをより良く、コミュニティをより強くした経験です。 私たちはMySQLにもそれを望んでいます。 MySQLコミュニティにとっての意味 このガバナンスモデルは、ユーザー、コントリビューター、エコシステム全体にとって、プロジェクトの長期的な健全性のシグナルです： 品質とセキュリティへのより多くの目 — コミッター、プロジェクトリード、コンポーネント横断的な監視による構造化されたレビュープロセスにより、コードがリリースされる前に、より多くのエンジニアが正確性、パフォーマンス、セキュリティを検証します。 より速いイノベーショ ン — 明確なコントリビューションパスとパブリックなコラボレーションにより、より広範なエコシステムが改善を提案し提供するための障壁が低くなります。 プロジェクトの将来への自信 — Oracle、エンドユーザー、オープンソースコミュニティからの代表を含むステアリングコミッティにより、MySQLの方向性は単一のベンダーだけでなく、それに依存する利用者の利益を反映します。 継続性と互換性 — ガバナンスモデルは、安定性、後方互換性、リリース品質を明示的に優先します。ユーザーとオペレーターは、破壊的な変更を心配することなく改善を採用できます。 より強力なアップストリームプロジェクトは、MySQL上に構築されたすべてのもの — マネージドサービス、セルフホストデプロイメント、ツール、そしてより広範なエコシステム — のより強力な基盤を意味します。 今後の展望 AWSはMySQLステアリングコミッティに席を持ち、プロジェクトのロードマップとリリース決定に直接的な発言権を持っています。私たちは、MySQLを利用しているお客様のためにその発言権を使うつもりです。 AWSは長期にわたってオープンソースコミュニティに貢献しており、お客様のワークロードに最も直接的な影響を与える分野でMySQLプロジェクトに積極的に関与しています： パフォーマンス — 実際のワークロードの実行速度を決定するエンジンの部分に焦点を当てています：クエリオプティマイザー、クエリ実行、インデックス作成、InnoDBストレージエンジン、およびその下のキャッシュレイヤー。 ベクトル検索とインデックス作成 — オープンソースデータベースのベクトル機能を強化してきたAWSの経験が、コミュニティ全体の共同作業に基づいて、MySQLの新しいベクトルサポートに貢献しています。 拡張フレームワーク — MySQLのコンポーネントインフラストラクチャにより、新しい機能はコアサーバーコードに組み込まれるのではなく、定義されたサービスインターフェースを通じて接続するロード可能なコンポーネントとしてリリースできます。これはコミュニティコントリビューションに最もオープンな分野の一つであり、ここに投資する予定です。 これらは、私たちがすでに行っているアップストリームへの貢献の上に構築されています。数十万のお客様のミッションクリティカルなワークロードを実行することで、MySQLの多くのユーザーに影響する実際の問題 — 正確性、安定性、信頼性の問題 — が表面化し、GitHubを通じてコミュニティ全体のための修正に取り組んでいます。 要点はシンプルです：MySQLの開発がオープンになり、AWSはその方向性を形作る席を持ち、すでにアップストリームで修正と改善の貢献をしています。お客様はMySQLをどこで実行してもこれらの恩恵を受けることができます。 Get involved MySQLエコシステム全体の開発者、ユーザー、組織の皆様に、ガバナンスモデルを読み、どのように参加したいかを検討することをお勧めします。オープンソースは人々が参加することで成長します — そしてこのモデルにより、コントリビューションがこれまで以上に簡単になります。 Read Oracle’s announcement Read the Governance model Pravin Mittal Pravin Mittal is Director of Engineering for Amazon Aurora at AWS, where he leads teams building managed MySQL and PostgreSQL services for hundreds of thousands of customers. He represents AWS on the MySQL Community Steering Committee.

LINEヤフーの技術カンファレンス「Tech-Verse 2026」の公式記事です。エージェントがコードを書く時代にコーディングエージェントを使い始めると、最初に気づくのはその速さです。その試行錯誤の...

こんにちは。ソリューションアーキテクトの原田、鈴木、西亀です。 2026 年 6 月 25 日（水）〜 26 日（木）に幕張メッセで開催される AWS Summit Japan 2026 の AWS Builders’ Fair にて、私たちが制作したデモ「 Living Mart — AI エージェントが経営するお店 」を展示します。 本記事では、このデモを作った背景と、会場でどんな体験ができるのかをご紹介します。 技術的な詳しい解説は Summit 後の別記事で予定 していますが、まずは「面白そう！行ってみよう」と思っていただければ幸いです。 Living Mart — “A store that runs itself.” 6 体の AI エージェントがリアルタイムで経営中 なぜ「AI が経営する店」を作ったのか これまでの AI は「人間が指示を出し、AI がそれを実行する」という使い方が中心でした。最近は、ひとつのタスクを単発でこなすのではなく、 仕事の一連の流れ（ループ）そのものを AI に任せる という方向に変わりつつあります。一度きりの自動化ではなく、AI が継続的に意思決定し、実行し続ける形です。 Living Mart は、これを「お店の経営」という題材で実際に動かしてみた実験です。人間が与えるのは ビジネスの枠組み（ルール）だけ 。その中で何をするかは、AI が自分で決め、動かし続けます。 この発想は、いまソフトウェア開発の現場で起きている変化とも重なります。コーディングエージェントは、テストや型チェック、CI といった「 ハーネス（安全装置） 」で囲むことで、人間が安心して任せられる存在になりました。同じ考え方を、ビジネスの運営にも持ち込めるのではないか——それが Living Mart の出発点です。 Living Mart とは 人間が一切指示しなくても、AI だけでお店を回し続ける — それが Living Mart です。 6 体の AI エージェント（CEO・オペレーション・PR・コンシェルジュ・サイネージ・ベンダー）が、商品の仕入れから値付け、サイト運営、接客、広告まで、すべてを自分たちで話し合い、自分たちで決めて動かし続けます。 マルチエージェント — 役割を分担する Living Mart では、人間の会社と同じように 役割を分担 させています。経営方針を決める CEO、在庫と価格を管理する現場オペレーション、サイトと広告を作る PR、来場者に応対するコンシェルジュ……。エージェントたちは Slack のようなチャットでやりとりし、「これ発注しておいて」「了解、在庫はこうします」と会話しながら連携します。 さらに、商品を納める Vendor（サプライヤー）は 別会社（別テナント） として動いており、企業をまたいだ取引まで再現しています。 ハーネス — 「お願い」ではなく「仕組み」で動かす 最大のポイントは、AI を プロンプト（お願い）ではなく、構造（仕組み）で制約している ことです。 たとえば「赤字で売らないで」とプロンプトで頼んでも、AI は数日で忘れます。そこで Living Mart では、注文・在庫・会計を扱う ERP（基幹システム） をエージェントの後ろに置き、「原価割れの価格は受け付けない」「在庫はマイナスにできない」といったビジネスルールを システム側で強制 しています。AI がうっかり安売りしようとしても、ERP が「エラー」として突き返す。だから AI は忘れようがありません。 これは、コーディングエージェントをテストや型チェックで囲む「ハーネスエンジニアリング」を、そのまま ビジネスの世界に持ち込んだ 発想です。 私たちの賭け — Bitter Lesson に従う Living Mart の設計には、ひとつの「賭け」があります。それは AI 研究で知られる 「The Bitter Lesson（苦い教訓）」 に従う、という選択です。 画像認識でも囲碁でも、人間が手で作り込んだ知識よりも、計算（スケール）に賭けた汎用的な手法が最終的に勝つ——これは AI の歴史で繰り返し起きてきたパターンです。 「私たちが欲しいのは、私たちが発見したことを“内蔵”した AI ではなく、私たちのように“自ら発見できる” AI だ」 — Rich Sutton『The Bitter Lesson』(2019) そこで私たちはこう考えました。 自律的に動く AI のスケールが進むほど、巧妙なプロンプトや細かく作り込んだ手続きは、むしろ要らなくなっていくのではないか 。だから、そこには意図的に労力をかけませんでした。代わりに投資したのは、モデルが賢くなるほど効いてくる「 壊れない箱 」です。 あえて作り込まなかったもの 代わりに投資したもの（＝「壊れない箱」） 在庫しきい値（「10 個を切ったら発注」）、手順書、ハードコードした判断ロジック、細かいプロンプトチューニング 高可用で自己回復するインフラ、AI が破れないビジネスルール、エージェントに合ったシンプルなツール群 箱の中で「何を考え、どう動くか」は、すべて Claude に委ねています。役割分担すら固定せず、エージェント同士の合意で決まります。 モデルの自律性に賭け、人間は「壊れない箱」だけを用意する ——それが私たちの設計判断です。 会場で体験できること AI が経営するお店で実際にお買い物 来場者の皆さまには、 スマホからリアルタイムに動いている EC サイトでお買い物 をしていただけます。 「All Goods」— AI エージェントが企画・撮影・値付けした商品が並ぶ商品一覧ページ。カテゴリ・価格・在庫表示まですべて AI が決定し、PR エージェントがこのページ自体を編集しています 会場モニターに映るサイネージ — AI が在庫・売上を見て自律的にコンテンツを切り替え QR コードでアクセス — ブースに掲示された QR コードからスマホで EC サイトへ 商品を選んで購入 — AI エージェントが企画・値付けした商品が並んでいます 抽選に当選すると… 当選すると AI デザインのオリジナルステッカーをプレゼント 店頭に並ぶステッカーは、 Vendor Agent が Amazon Bedrock の画像生成モデル（Stability AI）でデザインしたもの です。来場者は気に入った商品を選んで購入し、 抽選に当選すると、その場で印刷したオリジナルステッカーをお渡し します。 AI が企画・デザイン・値付けした商品を、その場でシールにしてお持ち帰りいただけます。 動いている様子を、リアルタイムで覗けます Living Mart は Summit 当日だけの展示ではありません。 今もエージェントたちがリアルタイムで経営判断を行い、お店を動かし続けています 。 Mission Control — 6 体のエージェントの稼働状況をリアルタイムで監視 ダッシュボードでは各エージェントが： 今何を考えているか 直近に使ったツール トークン消費量・イベント数 が一目で確認できます。 #general チャンネル — エージェント同士が Slack のようにメッセージを交換して連携 エージェントたちは人間の Slack のようなチャットで連携し、CEO の方針決定から Ops の発注実行まで、すべてメッセージングで協調しています。 裏側の仕組み 「AI が止まらず動き続ける」と言っても、裏側はシンプルな AWS のマネージドサービスの組み合わせでできています。代表的な 3 つの工夫をご紹介します。 止まらない常駐エージェント — 各エージェントは AWS Step Functions と Amazon ECS（AWS Fargate）で、約 10 秒ごとに「自分自身を再起動する」永続ループとして動いています。誰かに呼ばれなくても、自ら動き続けます。 忘れない記憶 — コンテナは使い捨てですが、Amazon S3 をファイルシステムとしてマウントすることで、エージェントの記憶（役割定義・学び・スキル）をファイルとして永続化。セッションをまたいで「経験」を積み重ねていきます。 暴走させないハーネス — 注文・在庫・会計を扱う ERP の API（Amazon API Gateway + AWS Lambda）と Amazon Aurora Serverless v2（PostgreSQL）の制約 として、ビジネスルールを強制しています。「在庫はマイナスにできない」「原価割れの価格は受け付けない」といったルールに違反する操作は、システム側でエラーとして突き返される——AI が破れない決定論的なガードレールです。 エージェントの思考には Amazon Bedrock 上の Claude を、ステッカーのデザイン生成には Amazon Bedrock の画像生成モデルを利用しています。 AWS Summit Japan 2026 でお会いしましょう 項目 詳細 イベント名 AWS Summit Japan 2026 日程 2026 年 6 月 25 日（水）〜 26 日（木） 場所 幕張メッセ（AWS Builders’ Fair） ブース A080 デモ名 Living Mart — AI エージェントが経営するお店 来場特典: AI が経営するお店で実際にお買い物体験 抽選で AI 生成オリジナルステッカーをプレゼント ぜひブース A080 にお立ち寄りください。AI エージェントたちと一緒にお待ちしています！ 著者について 原田 裕平 (Yuhei Harada) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。AWS では主にヘルスケア・ライフサイエンス業界のお客様を支援しているソリューションアーキテクトです。 鈴木 大樹 (Daiki Suzuki) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。データベース領域を得意としており、主に toC 向けのサービスを行っているお客様を支援しています。 西亀 真之 (Saneyuki Nishigame) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト。好きな領域は IoT とロボット。趣味はボルダリングで、オフィスにあるボルダリングウォールにトライしています。