本記事は、シリーズ「AWS における AI エージェント対応のデータ基盤」の第 2 回です。 第 1 回 では、AI エージェントが組織の本番データに対して正しく動くために必要な 3 要素（認可・ビジネスデータカタログ・ドメイン知識）を紹介し、認可が効いている様子をデモで示しました。本記事では、3 要素のうち認可に焦点を当て、AI エージェント経由のデータアクセスに Amazon SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説します。 サンプルリポジトリ: aws-samples/sample-sagemaker-agentic-analyst aws-samples sample-sagemaker-agentic-analyst A demo application that demonstrates how fine-grained access controls configured in SageMaker Unified Studio are transparently enforced on data access through AI agents. AI エージェントにアクセス制御を効かせる 3 つの壁 AI エージェントにデータアクセスを任せるとき、守るべき原則があります。エージェントは独自の認可ロジックを持たず、ユーザーが SageMaker Catalog で付与されている権限を、エージェント経由でもそのまま透過的に利用させることです（SageMaker Catalog は Amazon DataZone の上に構築されており、権限設定は DataZone API で操作します）。エージェント内に独自の認可ロジックを作ると、既存のガバナンスと二重管理になり、整合性を保つのが難しくなるからです。 この原則を実現しようとすると、素直な実装ではたどり着けない 3 つの壁があります。これらは本記事で解説する設計上の工夫によって越えられます。 壁 1: コンピュートリソース自体のロールで権限を取得すると、全ユーザーが同一権限になる。 AI エージェントのツールは AWS Lambda 、 AWS Fargate 、 Amazon EC2 など何らかのコンピュートリソース上で実行されます。そのコンピュートリソース自体のロール（たとえば Lambda の実行ロール）で DataZone の GetEnvironmentCredentials API を呼ぶと、返ってくるのはそのロール自身のメンバーシップに基づくプロジェクトロールです。どのユーザーがリクエストしても同じ認証情報が返るため、ユーザー個別のアクセス制御を効かせるには工夫が必要です。 壁 2: SAML フェデレーション経由のトークンには、IdP 側のグループ情報が乗らない。 AWS IAM Identity Center （以下 IdC）と、たとえば Amazon Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報が Cognito のトークンに自動的には含まれません。「データコンシューマーには athena_query を許可し、ドメイン管理者には cloudtrail_query のみ許可する」といったツール単位の認可を IdC のグループベースで行うには、グループ情報をトークンに載せる工夫が必要です。 壁 3: 設定時と実行時で関与するサービスが異なり、認可の全体像を把握する必要がある。 SageMaker Catalog の裏側では複数のサービスが連携しています。設定時に使うサービスと、クエリ実行時に評価されるサービスが異なるため、全体像を把握しないと正しい実装にたどり着けません。 本記事では、サンプルリポジトリ sample-sagemaker-agentic-analyst がこれらの壁をどう越えているかを解説します。 サービスの役割分担を整理する 本記事で扱うサービスの関係を先に整理します。 Amazon SageMaker Catalog は、データと AI の発見・ガバナンス・コラボレーションを担うサービスで、Amazon DataZone の上に構築されています。データの Publish/Subscribe やアクセス権の設定は SageMaker Catalog（および Amazon SageMaker Unified Studio の UI）で行いますが、実際のクエリ実行時に行・列レベルのアクセス制御を評価するのは AWS Lake Formation です。S3 上のファイルに対するアクセス制御は Amazon S3 Access Grants が担います。 つまり、SageMaker Catalog で「誰がどのデータを見てよいか」を 設定 し、Lake Formation と S3 Access Grants が 実行時 にその設定を評価する、という役割分担です。 重要な原則として、DataZone はクエリ実行パスに入りません。後述する認証情報変換フローでは DataZone API（ RedeemAccessToken / GetEnvironmentCredentials ）を呼びますが、これは AgentCore Gateway に接続された Lambda（以下 Tool Lambda）が プロジェクトロールの認証情報を取得する ための前段であり、Athena クエリや S3 オブジェクト取得そのものには DataZone は介在しません。クエリ実行時の認可評価は Lake Formation と S3 Access Grants が担います。この「認証情報取得の経路」と「データアクセスの経路」の分離を理解しておくと、以降のフローが読みやすくなります。 認証情報変換フロー: 5 つのステップ 壁 1 と壁 3 に対応するため、本サンプルでは 5 つのステップで認証情報を変換します。ブラウザでサインインしたユーザーの Cognito トークンから出発し、最終的にそのユーザーの権限が反映された SageMaker プロジェクトロールの一時認証情報を Tool Lambda の手元に届けます（下図）。 Step 1: ブラウザから AgentCore Runtime へ ブラウザ上の React アプリが、 Amazon Bedrock AgentCore Runtime のエンドポイントに HTTPS リクエストを送ります。このリクエストには 2 つのトークンが乗っています。 Authorization: Bearer <Cognito Access Token> — Runtime の Cognito Authorizer が検証します カスタムヘッダー X-Amzn-Bedrock-AgentCore-Runtime-Custom-Cognito-Id-Token: <Cognito ID Token> — 次のステップで使います Cognito Access Token と Cognito ID Token はどちらも Amazon Cognito が発行する JSON Web Token（JWT）ですが、役割が異なります。Access Token は「このリクエストは正当なユーザーから来たか」を Runtime と Gateway が判定するために使います。ID Token はユーザーのアイデンティティ情報（メールアドレスなど）を含んでおり、次のステップで IdC のユーザーと突き合わせるために使います。 Step 2: chat-agent が Cognito ID Token を IdC Access Token に引き換える Amazon Bedrock AgentCore Runtime はエージェントプロセスをホストするマネージドサービスです。呼び出し主体はその上で動くユーザーコード（本サンプルでは chat-agent ）であり、Runtime サービス自身がトークン変換を自動で行うわけではありません。 chat-agent が IdC の CreateTokenWithIAM API を呼びます。 const tokenRes = await new SSOOIDCClient({ region }).send( new CreateTokenWithIAMCommand({ clientId: idcApplicationArn, grantType: 'urn:ietf:params:oauth:grant-type:jwt-bearer', assertion: cognitoIdToken, }), ); const idcAccessToken = tokenRes.accessToken; jwt-bearer grant で Cognito ID Token を渡すと、IdC はそのクレームから IdC ユーザーを特定し、IdC Access Token を返します。 ここで 2 つの補足があります。 Cognito JWT と IdC Access Token は別物です。 発行者が違い（Cognito vs IdC）、形式も違います（JWT vs 不透明トークン）。Cognito JWT は Cognito 連携アプリでしか通用しませんが、IdC Access Token は IdC の Trusted Identity Propagation（TIP） に対応した AWS サービスで通用します。TIP は、IdC ユーザーのアイデンティティを IAM ロールの STS セッションに identity context として伝播させる仕組みです。DataZone は TIP 対応サービスの 1 つで、 RedeemAccessToken はその入口に位置します。 CreateTokenWithIAM と RedeemAccessToken は、このトークンの世界をまたぐブリッジの役割を果たします。 ただし本サンプルでは、TIP の identity-enhanced session をそのままデータ層まで持ち込んで Lake Formation や S3 Access Grants に評価させる構成は採っていません。SageMaker Catalog の Publish/Subscribe モデルが プロジェクトロール に行・列・オブジェクトレベルの権限を付与する設計になっているため、IdC ユーザーのアイデンティティは RedeemAccessToken → GetEnvironmentCredentials を経由してプロジェクトロールへ引き換えられ、以降のデータアクセスはプロジェクトロールの権限で評価されます。TIP の役割はこの引き換えの前段に限定され、本記事の焦点もそこにあります。 CreateTokenWithIAM には jti 制約があります。 JWT には jti （JWT ID）という一意識別子のクレームがあり、IdC は jwt-bearer grant で受け取った JWT の jti を記録します。同じ jti の JWT が再度送られると拒否されるため、同一の Cognito ID Token で CreateTokenWithIAM を 2 回呼ぶことはできません。このため、chat-agent で 1 リクエストあたり 1 回だけ実行し、得られた IdC Access Token を x-idc-access-token カスタムヘッダーで AgentCore Gateway 経由で全 Tool Lambda に伝播する設計になっています。 なお、 CreateTokenWithIAM を呼ぶための IAM アクション名は sso-oauth:CreateTokenWithIAM です。SDK クライアントは SSOOIDCClient を使いますが、IAM ポリシー側のサービス名は sso-oauth になります。また、IdC の OAuth Customer Managed Application に datazone:domain:access スコープを事前に登録しておく必要があります。 Step 3: Tool Lambda が IdC Access Token を DomainExecutionRole の認証情報に引き換える Tool Lambda が Amazon DataZone の RedeemAccessToken エンドポイントに HTTP POST を投げます。 const redeemRes = await fetch( `https://datazone.${region}.api.aws/sso/redeem-token`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ domainId, accessToken: idcAccessToken }), }, ); const { credentials: domainExecRoleCreds } = await redeemRes.json(); RedeemAccessToken は AWS SDK に含まれていません。 公開ドキュメントでは Athena JDBC ドライバ経由の利用例（ Analyze subscribed data via JDBC ）が示されていますが、サーバーサイドアプリからの直接呼び出しは生の HTTP リクエストで行う必要があります。このため、エンドポイント URL も通常の DataZone SDK が使う datazone.{region}.amazonaws.com ではなく datazone.{region}.api.aws を指定します。 この API には 2 つの特徴があります。SigV4 署名が不要であること（認証は IdC Access Token 自体が行う）、そして jti 制約がないため並列の Tool 呼び出しで複数の Lambda が同じ IdC Access Token を使っても問題ないことです。 返ってくるのは DomainExecutionRole の一時認証情報（ accessKeyId / secretAccessKey / sessionToken / expiration ）です。DomainExecutionRole は SageMaker Unified Studio ドメインに紐付く IAM ロールで、この認証情報には IdC ユーザーのアイデンティティが紐付いています 。内部的には、 RedeemAccessToken が DomainExecutionRole を assume する際に、Step 2 で触れた TIP の仕組みにより STS セッションに IdC ユーザーの identity context が埋め込まれます。これが次のステップで効いてきます。 Step 4: Tool Lambda が DomainExecutionRole の認証情報でプロジェクトロールを取得する Tool Lambda が Amazon DataZone SDK を DomainExecutionRole の認証情報で 初期化し、 GetEnvironmentCredentials を呼びます。 const envCreds = await new DataZoneClient({ region, credentials: domainExecRoleCreds, }).send( new GetEnvironmentCredentialsCommand({ domainIdentifier: domainId, environmentIdentifier: environmentId, }), ); Amazon DataZone は呼び出し元の STS セッションから identity context を取り出し、IdC ユーザーを特定します。そのユーザーがプロジェクトのメンバーであれば、プロジェクトロールの一時認証情報を返します。メンバーでなければ拒否されます。 ここが本サンプルの核心です。DomainExecutionRole の認証情報で呼ぶからこそ、 ユーザー本人のメンバーシップ で認可が評価されます。もし Lambda 実行ロールで直接 GetEnvironmentCredentials を呼んでいたら、Lambda 実行ロール自身のメンバーシップで判定されてしまい、ユーザーごとの権限差が消えます。 Step 5: プロジェクトロールで Athena / S3 を呼び出す Tool Lambda が Athena や S3 のクライアントを プロジェクトロールの認証情報で 初期化し、クエリやオブジェクト取得を実行します。 const athena = new AthenaClient({ region, credentials: { accessKeyId: envCreds.accessKeyId, secretAccessKey: envCreds.secretAccessKey, sessionToken: envCreds.sessionToken, }, }); Athena がクエリを実行すると、Lake Formation がプロジェクトロールの権限に基づいて行・列レベルのフィルタリングを透過的に適用します。ユーザーの権限の範囲内にある行と列だけが結果として返り、範囲外の情報は応答に含まれません。 ステップのまとめ Step 主体 API 入力 出力 1 ブラウザ → Runtime POST /invocations — Cognito Access Token + ID Token（Runtime に到達） 2 chat-agent → IdC CreateTokenWithIAM Cognito ID Token IdC Access Token 3 Tool Lambda → DataZone RedeemAccessToken IdC Access Token DomainExecutionRole 認証情報 4 Tool Lambda → DataZone GetEnvironmentCredentials DomainExecutionRole 認証情報 プロジェクトロール認証情報 5 Tool Lambda → Athena/S3 StartQueryExecution / GetObject 等 プロジェクトロール認証情報 クエリ結果 / オブジェクト Step 5 の S3 アクセスは Publisher と Subscriber で経路が分かれます。後述の「Publisher と Subscriber で異なる S3 アクセス方式」で詳述します。 この設計では、 Lambda 実行ロールはデータアクセスに一切使いません 。権限判定はすべてユーザーに紐付いた認証情報で行われます。 Policy in AgentCore によるツール単位認可 認証情報変換フローはデータアクセスの認可を扱いますが、「どのユーザーがどのツールを呼べるか」という別軸の認可も必要です。AgentCore の認可モデルは、 Inbound（ユーザー → AI エージェントへの入口） と Outbound（AI エージェント → ツールへの出口） の 2 軸で整理されます。Inbound は AgentCore Runtime の JWT Authorizer が Cognito Access Token を検証して「この呼び出し元はエージェントを呼んでよいか」を判定します。Outbound はツール単位の認可で、本サンプルでは AgentCore Gateway の Policy in AgentCore で実現しています（下図）。 グループ情報の埋め込み 壁 2 で述べた通り、IdC と Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報は Cognito トークンに自動的には含まれません。本サンプルでは、 Amazon Cognito の Pre token generation Lambda trigger の V2 イベントを使い、Cognito Access Token に cedar_groups カスタムクレームを埋め込みます。値は |data-producers|security-auditors| のようにパイプ区切りの文字列です。 Cedar ポリシーによる評価 Policy in AgentCore では、Cedar 言語で記述されたポリシーを policy engine に登録し、それを AgentCore Gateway に関連付けます。Gateway にリクエストが到達すると、policy engine が Cognito Access Token の cedar_groups クレームを読み取り、Cedar ポリシーで評価します。Gateway はリクエスト時点で JWT のクレームを AgentCore::OAuthUser エンティティのタグとして Entity Store に格納するため、ポリシー上は principal.getTag("cedar_groups") のようにタグとして参照します。「JWT では cedar_groups クレーム、Cedar ポリシーでは cedar_groups タグ」という名前の対応関係です。 permit( principal is AgentCore::OAuthUser, action, resource == AgentCore::Gateway::"<gateway-arn>" ) when { principal.hasTag("cedar_groups") && principal.getTag("cedar_groups") like "*|security-auditors|*" && (action == AgentCore::Action::"cloudtrail-query___cloudtrail_query") }; このポリシーは「 security-auditors グループに属するユーザーだけが cloudtrail_query ツールを呼べる」ことを宣言しています。アクション名の cloudtrail-query___cloudtrail_query は、AgentCore Gateway が MCP ツール定義から自動生成する命名で、 ターゲット名（ cloudtrail-query ） ___ ツール名（ cloudtrail_query ） の形を取ります。 Cedar の policy engine は default-deny （明示的に許可されない限り拒否）で動作します。上記の 1 本のポリシーだけでは security-auditors 向けの 1 ツールしか許可されていないため、他のユーザー・他のツールはすべて拒否されます。同様のポリシーを複数定義することで、たとえばデータコンシューマーには athena_query と s3_read のみを許可し、データプロデューサーにはカタログ管理ツールも許可する、といった職務分離を実現できます。 Policy in AgentCore によるツール単位認可と、認証情報変換フローによるデータアクセス認可は独立した 2 つの軸です。Gateway で「このユーザーはこのツールを呼んでよいか」を判定し、Tool Lambda で「このユーザーはこのデータを見てよいか」を判定します。 Publisher と Subscriber で異なる S3 アクセス方式 非構造化データ（S3 上のファイル）へのアクセスは、プロジェクトの役割によって経路が異なります。Amazon S3 Access Grants は、S3 の prefix / bucket / object 単位で IAM プリンシパルやディレクトリユーザーに READ/WRITE/READWRITE 権限を付与する仕組みで、 GetDataAccess API で当該対象への一時認証情報を取得してから S3 API を呼ぶ形で利用します。SageMaker Catalog の Publish/Subscribe は、この Grant を Subscriber のプロジェクトロールに対してのみ自動作成する 設計です。Publisher 側のプロジェクトロールには明示的な Grant が作られず、Publisher は別のパス（IAM ポリシーによる直接アクセス）でバケットを読みます。これが Publisher/Subscriber で経路が分かれる理由です。 Publisher（プロジェクトがバケットを所有する場合）: プロジェクトロールの認証情報で直接 S3:GetObject を呼びます。アクセス権は、プロジェクトロールに付与された IAM インラインポリシー（プロジェクト配下のプレフィックスに限定）によって許可されます。Publisher プロジェクトロール自身への明示的な S3 Access Grants の Grant は存在しないため、 GetDataAccess は失敗します。 Subscriber（別プロジェクト経由で購読する場合）: SageMaker Unified Studio の Publish/Subscribe が Subscriber ロールに対して IAM タイプの Grant を自動作成します。Tool Lambda はまず S3Control:GetDataAccess で一時認証情報を取得し、その認証情報で S3:GetObject を呼びます。 判断ロジックは、コネクションの accessRole の有無とプロジェクトの所有関係で決まります。プロジェクトレベルのコネクションで accessRole があれば S3 Access Grants 経由、なければ直接アクセスです。 まとめと次のアクション 本記事では、AI エージェント経由のデータアクセスに SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説しました。 設定時と実行時の役割分担 を整理し、SageMaker Catalog / DataZone が設定を担い、Lake Formation / S3 Access Grants が実行時に認可を評価する構造を明確にする 認証情報変換フロー （ CreateTokenWithIAM → RedeemAccessToken → GetEnvironmentCredentials ）で、ユーザーに紐付いたプロジェクトロールの認証情報を Tool Lambda に届ける Policy in AgentCore で、ツール単位の認可をデータアクセス認可とは独立した軸で制御する Lambda 実行ロールはデータアクセスに一切使わず、権限判定はすべてユーザーに紐付いた認証情報で行われます。これにより、SageMaker Catalog で設定された行・列・オブジェクトレベルのアクセス権は、AI エージェント経由でも透過的に適用されます。 第 1 回 で紹介した拡張性（ゼロショット時系列予測のオンデマンド実行）も、本記事で解説した認可の仕組みに支えられています。アクセス制御されたデータを、追加の認証設計なしで Amazon SageMaker AI の推論エンドポイントに流し込めるのは、プロジェクトロールの認証情報が Tool Lambda の手元まで届いているからです。サンプルリポジトリの apps/gateway-tools/time-series-forecast/ と design/data-access-control.md で実装の詳細を確認できます。 高野 賢司 AWS のシニアソリューションアーキテクトとして、東海以西の製造業のお客様を中心に支援しています。Infrastructure as Code や AI 駆動開発を中心とした開発者ツールのエキスパートでもあり、 Kiro によって広がったソフトウェア開発の世界を楽しんでいます。

こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 4/22(水)-24(金) に函館で開催されたRubyKaigi に今年も参加してきたので、その参加レポートをお送りします👟 はじめに 株式会社メドレーはRubyスポンサーとして協賛し、現地でブース出展しました。 弊社のプロダクトの半数以上でRubyを用いていることもあり、 Rubyコミュニティへの貢献は、協賛活動の中でも特に重要視している活動です！ １番最初にロゴを掲載していただきました🙌 弊社VPoEの倉林（ @terukura ）が書き込み中✍️ 今年は役員を含め総勢13名で参加し、RubyKaigi を堪能しました✨ 本レポートでは、現地の様子や弊社のブース企画のご紹介を写真メインで雰囲気が伝わるようお伝えします！ ぜひ楽しんでご覧いただけると嬉しいです🙌 会場の様子 本年の開催場所は「函館」。（昨年の発表から心待ちにしていました!!!） 採用人事の福島さんとともに前日入りし、ブース設営⚒️ ブースの完成形。Rubyスポンサーは長机2つなので広々としていました🚩 上から見た会場。 弊社ブースのご紹介 ブース企画その１_Ruby×AIアンケート調査 以下3つのAIに関するアンケートをとりました！🔍 ご回答いただいた皆様、ご協力ありがとうございました！！ AI（生成AIなど）を開発に取り入れ始めたのはいつ頃ですか？ 使っている具体的なルールを教えて下さい AIを活用したRuby開発における成功体験やお困りごとを教えて下さい アンケート結果サマリ✍️ 1.AIを開発に取り入れ始めた時期 2024年前半： 早期導入層が一定数存在し、この時期から活用が始まる。 2024年後半〜2025年前半： ボリュームゾーン です。この期間に圧倒的多数のエンジニアが導入を開始。 2025年後半〜2026年： 導入が一段落し、ほぼ全てのエンジニアが当たり前に利用しているフェーズに移行。 2.使っている具体的なツール 圧倒的シェア: Claude Code 併用・特定用途: Cursor, Codex, GitHub Copilot, Devin, Gemini など 結果としては単なる「コードの補完」ではなく、Claude Code や Code x、Devin のような「自律的にタスクを完了させるエージェント型」が主流であることが顕著に現れていました。 3.Ruby開発における成功体験・お困りごと ☀️ ポジティブ（成功体験）※一部抜粋 開発スピードの向上: 「実装が早くなった」「コードを書く時間が減った」「爆速」「PR（プルリクエスト）出すまでが早い」といった声が目立ちました。 学習・調査の効率化: 「知らない構文やライブラリをすぐ聞ける」「エラー解消が早い」「Rubyの古いバージョンからの移行に役立った」 テスト・ドキュメント: 「テストコードを書いてくれる」「仕様の言語化が楽になった」 精神的負担の軽減: 「一人で悩む時間が減った」「心理的ハードルが下がった」 ☔️ ネガティブ（お困りごと） ※一部抜粋 精度の問題: 「嘘をつく（ハルシネーション）」「動かないコードが出てくる」「古い情報を出してくる」 レビュー・品質への懸念: 「レビューが大変になった」「AIが書いたコードの意図を追うのが苦労する」「コピペによる技術的負債への不安」 特有の悩み: 「トークン代が高い」「追いつくのが大変」「AIのスピードに人間がついていけない」 ブース企画その2_アンケート or XフォローでノベルティGET🎁 弊社の認知度をはじめとした簡単なアンケートへの回答またはXフォローでガラポンチャレンジをしてノベルティをプレゼントしていました✨ どちらもご協力いただいた方は2回引いていただきました💪 防災7点セットをはじめ絆創膏やポーチなどを用意しました🎁 多くの方にお越しいただき、賑わいを見せた弊社ブースの様子👀✨わいわい。 弊社役員のオフショット📸 Matzさんにお越しいただき記念撮影✨ ありがとうございました！ エンジニアによるセッションレポート エンジニアによるセッションの感想を一部紹介します！ Ruby Committers and the World Ruby Committers and the World RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyの開発体制について。Matzさんがいなくなった場合を考えて、pythonのような合議制への移行などを検討すべきかが話された。Matzさんは大人数での合議制には否定的で、一部の意見によって言語設計が揺らぎやくなる懸念があると話していた。少人数での合議制か、AIでメカMatzを作るべきという意見があった。 RubyコミッターのAI活用について。コミッターも半分以上をAIに実装されている人が多い。Matzさんも一年以上自分でコードを書いていない、エディタも開発目的では使っていない（メールでもemacsを使っている）。CRubyは以前からMatzさんは実装から離れて他のコミッターに任せていた。同レベルのことをAIエージェントに任せてもアウトプットレベルはそんなに変わらないらしい。（言う事を効かないことがあるコミッターたちよりもAIエージェントを使ったほうが良いとのこと） HTML-Aware ERB: The Path to Reactive Rendering HTML-Aware ERB: The Path to Reactive Rendering RubyKaigi 2026, #rubykaigi rubykaigi.org この発表は、ERBを単なる文字列生成の仕組みとしてではなく、HTML構造を理解できるテンプレートとして扱うことで、RailsのView層をより進化させようという内容でした。HerbはHTML+ERBを解析するための文法とパーサを提供し、Prismと組み合わせることで、Ruby構文やHTMLの不整合を実行前に検出できるようにします。普段Reactを書いている立場から見ると、JSXをツールが構造として理解できることがReactの開発体験を支えているように、HerbはERBにもそれに近い土台を作ろうとしているように感じました。Hotwireで進んできたHTML中心のRails開発を、テンプレート解析やエディタ支援の面からさらに押し進める取り組みに見えます。特に面白いのは、将来的に「どの状態がどのDOMに影響するか」を追跡し、必要な部分だけを更新するリアクティブな仕組みにつながる可能性がある点です。ただし、React的なリアクティビティがすぐそのまま実現するわけではなく、現時点ではそのための基盤づくりという位置づけに近そうです。サーバーサイドレンダリングを中心にしながら、必要なところだけ賢く更新できる方向性はとても魅力的です。ERBが構造を理解できる開発しやすいUI記述として進化していくなら、小規模なアプリや管理画面では、Reactを持ち込まずにこの方向性を選ぶ場面も増えていくかもしれません。 ERBの問題（HTMLの構造に問題があっても何も検出しない）とそれを解決するためにherbが生み出され、herbに何ができるか？といった話。herb-toolsでHTMLをパースしたり、dev serverでホットリロードできたりするの知らなかったので勉強になりました。 Matz Keynote Matz Keynote RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyのソースコードをコンパイルして、実行ファイルを生成する取り組み。CRubyに比べて大幅な性能向上を実現していた（YJITとは別のアプローチ）。全てのRubyの機能が利用できるわけでなく、Ruby on Railsの置き換えは現時点で原理的に不可とのこと。CLIツールなどの一部のユースケースでは利用できる仕組みかもしれないと感じた。 弊社スポンサーセッション 最終日にはスポンサーセッションとして、弊社の宍戸（執行役員 医療プラットフォーム本部 CTO）がトークしました。 ご聴講いただいた皆さま、ありがとうございました！ 公立はこだて未来大学学生への支援活動 事前告知ブログにも記載していますが、弊社の新卒採用において開催地（函館）は深い繋がりがあり、 社内にははこだて未来大学のOB・OGが複数名在籍し、第一線で活躍しています✨ RubyKaigi 2026 にRubyスポンサーとして協賛します！ | MEDLEY Developer Portal はじめに こんにちは！メドレーDevRelの重田（@Shige0096）です。 今年もついに、Rubyistたちの祭典 RubyKaigi 2026 の季節がやってまいりました！ 昨年の最終日に「次は函館！」と発表されてから、日本三大夜景と... developer.medley.jp そこで今回は、RubyKaigi への参加費用の支援と弊社社員との懇親会への招待を行いました。 ご参加いただいた皆様、ありがとうございました！ 短い時間でしたが、弊社一同楽しい時間を過ごすことができました！少しでもメドレーについて知っていただき、興味を持っていただけていたら幸いです！ おまけ RubyKaigiへの参加を通して、北海道の魅力にもたくさん触れることができました。 美味しい水と空気がある場所はご飯がとにかく美味しい！！そして自然も感じられた3日間でした🌱 思い出の写真をいくつかご紹介します🙋‍♀️ 2日目の夜に希望メンバーで、日本三大夜景でもある函館山からの夜景を見に行きました⛰️ 新鮮度がまるで違う北海道の海鮮！ 活きたまま水揚げ・輸送され、直前まで生きていたイカ（=活イカ）をいただきました🦑味はもちろん、コリコリした食感が最高でした👏 帰りのタクシーで運転手さんにオススメしていただいたソフトクリーム🍦 北海道最古の珈琲店「カフェ美鈴」で食べられます☕️疲れた体に沁みる甘さでした🙏 おわりに 改めて、RubyKaigi にて弊社ブースにお越しいただいた皆様、はこだて未来大学の皆様、そして運営の皆様、ありがとうございました！！！ 全国のRubyistの皆さんと交流ができたことを弊社一同嬉しく思います！ 今後もRubyコミュニティへ少しでも貢献できたらと考えていますので、引き続きよろしくお願いいたします。 それでは、来年は宮崎でお会いしましょう！！（頑張って申し込むぞ💪🔥） メドレーでは、Rubyが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 株式会社メドレー 正社員 エンジニア の求人一覧 株式会社メドレー 正社員 エンジニア の求人一覧です。| HRMOS hrmos.co

こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 4/22(水)-24(金) に函館で開催されたRubyKaigi に今年も参加してきたので、その参加レポートをお送りします👟 はじめに 株式会社メドレーはRubyスポンサーとして協賛し、現地でブース出展しました。 弊社のプロダクトの半数以上でRubyを用いていることもあり、 Rubyコミュニティへの貢献は、協賛活動の中でも特に重要視している活動です！ １番最初にロゴを掲載していただきました🙌 弊社VPoEの倉林（ @terukura ）が書き込み中✍️ 今年は役員を含め総勢13名で参加し、RubyKaigi を堪能しました✨ 本レポートでは、現地の様子や弊社のブース企画のご紹介を写真メインで雰囲気が伝わるようお伝えします！ ぜひ楽しんでご覧いただけると嬉しいです🙌 会場の様子 本年の開催場所は「函館」。（昨年の発表から心待ちにしていました!!!） 採用人事の福島さんとともに前日入りし、ブース設営⚒️ ブースの完成形。Rubyスポンサーは長机2つなので広々としていました🚩 上から見た会場。 弊社ブースのご紹介 ブース企画その１_Ruby×AIアンケート調査 以下3つのAIに関するアンケートをとりました！🔍 ご回答いただいた皆様、ご協力ありがとうございました！！ AI（生成AIなど）を開発に取り入れ始めたのはいつ頃ですか？ 使っている具体的なルールを教えて下さい AIを活用したRuby開発における成功体験やお困りごとを教えて下さい アンケート結果サマリ✍️ 1.AIを開発に取り入れ始めた時期 2024年前半： 早期導入層が一定数存在し、この時期から活用が始まる。 2024年後半〜2025年前半： ボリュームゾーン です。この期間に圧倒的多数のエンジニアが導入を開始。 2025年後半〜2026年： 導入が一段落し、ほぼ全てのエンジニアが当たり前に利用しているフェーズに移行。 2.使っている具体的なツール 圧倒的シェア: Claude Code 併用・特定用途: Cursor, Codex, GitHub Copilot, Devin, Gemini など 結果としては単なる「コードの補完」ではなく、Claude Code や Code x、Devin のような「自律的にタスクを完了させるエージェント型」が主流であることが顕著に現れていました。 3.Ruby開発における成功体験・お困りごと ☀️ ポジティブ（成功体験）※一部抜粋 開発スピードの向上: 「実装が早くなった」「コードを書く時間が減った」「爆速」「PR（プルリクエスト）出すまでが早い」といった声が目立ちました。 学習・調査の効率化: 「知らない構文やライブラリをすぐ聞ける」「エラー解消が早い」「Rubyの古いバージョンからの移行に役立った」 テスト・ドキュメント: 「テストコードを書いてくれる」「仕様の言語化が楽になった」 精神的負担の軽減: 「一人で悩む時間が減った」「心理的ハードルが下がった」 ☔️ ネガティブ（お困りごと） ※一部抜粋 精度の問題: 「嘘をつく（ハルシネーション）」「動かないコードが出てくる」「古い情報を出してくる」 レビュー・品質への懸念: 「レビューが大変になった」「AIが書いたコードの意図を追うのが苦労する」「コピペによる技術的負債への不安」 特有の悩み: 「トークン代が高い」「追いつくのが大変」「AIのスピードに人間がついていけない」 ブース企画その2_アンケート or XフォローでノベルティGET🎁 弊社の認知度をはじめとした簡単なアンケートへの回答またはXフォローでガラポンチャレンジをしてノベルティをプレゼントしていました✨ どちらもご協力いただいた方は2回引いていただきました💪 防災7点セットをはじめ絆創膏やポーチなどを用意しました🎁 多くの方にお越しいただき、賑わいを見せた弊社ブースの様子👀✨わいわい。 弊社役員のオフショット📸 Matzさんにお越しいただき記念撮影✨ ありがとうございました！ エンジニアによるセッションレポート エンジニアによるセッションの感想を一部紹介します！ Ruby Committers and the World Ruby Committers and the World RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyの開発体制について。Matzさんがいなくなった場合を考えて、pythonのような合議制への移行などを検討すべきかが話された。Matzさんは大人数での合議制には否定的で、一部の意見によって言語設計が揺らぎやくなる懸念があると話していた。少人数での合議制か、AIでメカMatzを作るべきという意見があった。 RubyコミッターのAI活用について。コミッターも半分以上をAIに実装されている人が多い。Matzさんも一年以上自分でコードを書いていない、エディタも開発目的では使っていない（メールでもemacsを使っている）。CRubyは以前からMatzさんは実装から離れて他のコミッターに任せていた。同レベルのことをAIエージェントに任せてもアウトプットレベルはそんなに変わらないらしい。（言う事を効かないことがあるコミッターたちよりもAIエージェントを使ったほうが良いとのこと） HTML-Aware ERB: The Path to Reactive Rendering HTML-Aware ERB: The Path to Reactive Rendering RubyKaigi 2026, #rubykaigi rubykaigi.org この発表は、ERBを単なる文字列生成の仕組みとしてではなく、HTML構造を理解できるテンプレートとして扱うことで、RailsのView層をより進化させようという内容でした。HerbはHTML+ERBを解析するための文法とパーサを提供し、Prismと組み合わせることで、Ruby構文やHTMLの不整合を実行前に検出できるようにします。普段Reactを書いている立場から見ると、JSXをツールが構造として理解できることがReactの開発体験を支えているように、HerbはERBにもそれに近い土台を作ろうとしているように感じました。Hotwireで進んできたHTML中心のRails開発を、テンプレート解析やエディタ支援の面からさらに押し進める取り組みに見えます。特に面白いのは、将来的に「どの状態がどのDOMに影響するか」を追跡し、必要な部分だけを更新するリアクティブな仕組みにつながる可能性がある点です。ただし、React的なリアクティビティがすぐそのまま実現するわけではなく、現時点ではそのための基盤づくりという位置づけに近そうです。サーバーサイドレンダリングを中心にしながら、必要なところだけ賢く更新できる方向性はとても魅力的です。ERBが構造を理解できる開発しやすいUI記述として進化していくなら、小規模なアプリや管理画面では、Reactを持ち込まずにこの方向性を選ぶ場面も増えていくかもしれません。 ERBの問題（HTMLの構造に問題があっても何も検出しない）とそれを解決するためにherbが生み出され、herbに何ができるか？といった話。herb-toolsでHTMLをパースしたり、dev serverでホットリロードできたりするの知らなかったので勉強になりました。 Matz Keynote Matz Keynote RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyのソースコードをコンパイルして、実行ファイルを生成する取り組み。CRubyに比べて大幅な性能向上を実現していた（YJITとは別のアプローチ）。全てのRubyの機能が利用できるわけでなく、Ruby on Railsの置き換えは現時点で原理的に不可とのこと。CLIツールなどの一部のユースケースでは利用できる仕組みかもしれないと感じた。 弊社スポンサーセッション 最終日にはスポンサーセッションとして、弊社の宍戸（執行役員 医療プラットフォーム本部 CTO）がトークしました。 ご聴講いただいた皆さま、ありがとうございました！ 公立はこだて未来大学学生への支援活動 事前告知ブログにも記載していますが、弊社の新卒採用において開催地（函館）は深い繋がりがあり、 社内にははこだて未来大学のOB・OGが複数名在籍し、第一線で活躍しています✨ RubyKaigi 2026 にRubyスポンサーとして協賛します！ | MEDLEY Developer Portal はじめに こんにちは！メドレーDevRelの重田（@Shige0096）です。 今年もついに、Rubyistたちの祭典 RubyKaigi 2026 の季節がやってまいりました！ 昨年の最終日に「次は函館！」と発表されてから、日本三大夜景と... developer.medley.jp そこで今回は、RubyKaigi への参加費用の支援と弊社社員との懇親会への招待を行いました。 ご参加いただいた皆様、ありがとうございました！ 短い時間でしたが、弊社一同楽しい時間を過ごすことができました！少しでもメドレーについて知っていただき、興味を持っていただけていたら幸いです！ おまけ RubyKaigiへの参加を通して、北海道の魅力にもたくさん触れることができました。 美味しい水と空気がある場所はご飯がとにかく美味しい！！そして自然も感じられた3日間でした🌱 思い出の写真をいくつかご紹介します🙋‍♀️ 2日目の夜に希望メンバーで、日本三大夜景でもある函館山からの夜景を見に行きました⛰️ 新鮮度がまるで違う北海道の海鮮！ 活きたまま水揚げ・輸送され、直前まで生きていたイカ（=活イカ）をいただきました🦑味はもちろん、コリコリした食感が最高でした👏 帰りのタクシーで運転手さんにオススメしていただいたソフトクリーム🍦 北海道最古の珈琲店「カフェ美鈴」で食べられます☕️疲れた体に沁みる甘さでした🙏 おわりに 改めて、RubyKaigi にて弊社ブースにお越しいただいた皆様、はこだて未来大学の皆様、そして運営の皆様、ありがとうございました！！！ 全国のRubyistの皆さんと交流ができたことを弊社一同嬉しく思います！ 今後もRubyコミュニティへ少しでも貢献できたらと考えていますので、引き続きよろしくお願いいたします。 それでは、来年は宮崎でお会いしましょう！！（頑張って申し込むぞ💪🔥） メドレーでは、Rubyが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 株式会社メドレー 正社員 エンジニア の求人一覧 株式会社メドレー 正社員 エンジニア の求人一覧です。| HRMOS hrmos.co